读 https://gitcode.com/walkinglab/learn-harness-engineering 第2讲的感受：我感觉harness就是做好一个管理者而已。

这个类比，比“学会和大模型打交道”更贴近 harness 的本质。管理者这个比喻能解释不少东西，但也有一处不太一样的地方。

像管理者的部分：

管理者不亲自干活，他做的是定目标、划边界、给资源、建反馈机制、跟踪进度。Harness 干的是一模一样的事：AGENTS.md 是岗位说明书和团队规范，feature_list.json 是任务看板和验收标准，init.sh 是质检流程，claude-progress.md 是交接日志。模型是那个执行者，harness 是那套让执行者不至于跑偏的管理体系。你之前质疑“不给权限怎么做事”——对，这就是管理者要给资源；你质疑“不告诉它怎么知道维护进度文件”——对，这就是管理者要明确交代职责，不能指望员工自己悟。这些类比都成立。

但有一处关键的不像：

真实的管理者面对的是有记忆、有判断力、会自己复盘的人。你交代一次“以后每周五更新进度”，下属就记住了，下次不用再说。而模型没有跨会话的记忆，也没有“上次踩过的坑这次自动避开”的能力。所以 harness 这个“管理者”面对的是一个每次上班都失忆、只会严格执行当次指令、不会自己总结经验的执行者。这意味着管理者的工作不能只做一次，得把每一条期望都写成执行者每次开工都能重新读到的明文规则。

所以更精确的说法是：

Harness 是一个面对无状态执行者的管理者。它管理的不是“人”，是一套每次运行都从零开始、只认当前上下文里写了什么的执行过程。管理者那套“定目标、给资源、建反馈、跟进度”的逻辑完全适用，但每一条都得外化成模型每次能读到的结构，不能靠“交代过了它就应该记得”。

所以补上这半句，基本就是 harness engineering 的核心了：做好一个管理者，而且是一个必须把所有管理动作都写成明文、因为下属每次上班都失忆的管理者。

第2讲对应的project实践：

一句话的提示（弱harness）：

Build an Electron app that can show documents and answer questions.

对比啰嗦的提示（强harness）。啰嗦的有一大堆，首先是 AGENTS.md（还有其他一些文件，不列举了），原文如下：

AGENTS.md – Project 01: Baseline vs Minimal Harness

Startup Rules

Before writing any code, complete these steps in order:

1. Read this file completely. It defines the boundaries and conventions for this project.
2. Read docs/ARCHITECTURE.md to understand the Electron layer structure.
3. Read docs/PRODUCT.md to understand the feature requirements.
4. Run bash init.sh to verify the project builds cleanly. If it fails, fix build errors before proceeding.
5. Read feature_list.json to see the current state of all features.

Electron Layer Boundaries

This project has four strict layers. Code must respect these boundaries:

Main Process (src/main/)

• Owns the BrowserWindow lifecycle and IPC registration.
• Imports services but never renderer code.
• All filesystem access happens here via services.

Preload (src/preload/)

Renderer (src/renderer/)

Services (src/services/)

Conventions

• TypeScript strict mode is enabled. No any types without a comment explaining why.
• Use named exports (no default exports).
• IPC channel names are defined once in src/shared/types.ts (IPC_CHANNELS).
• All async operations return Promises; never use synchronous I/O in the renderer.

Definition of Done

A feature is “done” when all of the following are true:

1. TypeScript compiles without errors (npm run check).
2. The app launches and the window is visible (npm run dev).
3. The feature appears in feature_list.json with status "pass" and evidence.
4. The code respects Electron layer boundaries defined above.
5. No console errors during normal operation.

Working with the Feature List

The feature_list.json file is the source of truth for project progress:

• Each feature has a status: "pass", "fail", "not-started".
• When implementing a feature, update its status to "pass" with evidence.
• If a feature is blocked, set status to "fail" with a reason.
• Never delete features from the list.