前面几篇已经把控制逻辑说清楚了：

• prompt 负责轻任务
• Harness 负责边界和验收
• state 负责记住当前进展
• current_task.md 负责定义这一轮具体做什么；
• revision_log.md 负责记录为什么这么改
• open_issues.md 负责保存暂时不能解决的问题
• project_map.md 负责保存长期项目认知。

这一篇不再重复这些控制逻辑，
而是回答一个更实际的问题：

这些东西应该怎么摆，AI 和人类才都看得清楚？

这就是工作台要解决的事。

---

1. 工作台不是控制器，而是信息布局

Harness 讲的是：

• 能做什么
• 不能做什么
• 怎么验收
• 失败后怎么办

工作台讲的是：

• 这些信息放哪
• Agent先看什么
• 代码、状态、反馈怎么分开
• 人类怎样快速接管
• 哪些信息应该显示成界面

一句话：

Harness 负责控制，工作台负责摆放和呈现。

---

2. 一个程序工作台应该分成四块

以购物车程序为例，工作台可以分成四块：

2.1 项目认知区

放长期稳定的信息：

• 项目目标
• 主文件
• 关键约束
• 读文件顺序
• 架构边界

对应：

• project_map.md

这一块的作用，是让 Agent 先知道“这个项目是什么”。

它不负责描述本轮具体任务，而是保存长期认知。

---

2.2 当前任务区

放这一轮具体要做什么：

• 本轮目标
• 允许修改的文件
• 禁止碰的范围
• 验收条件
• 需要人工确认的事项

对应：

• current_task.md

这一块的作用，是让 Agent 先知道“这轮该干什么”。

它比项目地图更短、更具体，也更临时。任务完成后，它可以被替换、归档或更新。

---

2.3 代码与验证区

放真正要改的内容：

• 业务代码
• 测试代码
• 局部 diff
• 测试输出
• 验证结果

在购物车程序里，通常就是：

• checkout/service.py
• tests/test_checkout.py

这一块是 Agent 真正动手的地方。它应该尽量干净，不要塞太多状态说明和历史解释。

---

2.4 反馈区

放修改后的结果：

• 为什么这么改
• 改了什么
• 哪些测试通过
• 哪些问题还没解决
• 下一轮从哪里接

对应：

• revision_log.md
• open_issues.md

这一块的作用，是让下一轮不会重新猜。

---

3. 为什么不能把所有东西堆在一起？

因为一堆在一起，系统就会开始混。

问题一：任务和日志混在一起

current_task.md 说的是“现在要做什么”。
revision_log.md 说的是“已经做过什么”。
如果混在一起，Agent 可能把历史任务误认为当前任务，也可能把旧的候选方向当成新的执行授权。

问题二：代码和状态混在一起

代码文件应该表达程序逻辑。
状态文件应该表达任务边界和项目认知。
如果把临时说明、修改计划、验收备注都塞进代码附近，Agent 可能把说明当逻辑，把备注当需求，最后改出一堆范围外内容。

问题三：人类视图和执行层混在一起

人类想快速知道：

• 当前做到哪了
• 这轮为什么这么改
• 哪些问题还开着
• 下一步是否安全

Agent 执行时需要的是：

• 允许范围
• 目标文件
• 验收条件
• 失败处理方式

这两类信息相关，但不应该混成同一个权威来源。
所以工作台的第一原则是：
每一块只负责一种职责。

所以工作台的第一原则是：

每一块只负责一种职责。

---

4. 购物车程序里的工作台可以怎么摆？

还是用空购物车结算修复来举例。

这次任务是：空购物车结算时，不应该返回 500，而应该返回稳定的 400 错误，并带上错误码 EMPTY_CART。
一个工作台可以这样摆。

左侧：项目认知

显示：

text

项目：购物车结算服务
主文件：checkout/service.py
测试入口：tests/test_checkout.py
长期约束：支付模块不能在本轮重构
当前阶段：局部 bug fix

来源：

project_map.md

中间：代码编辑区

显示：

checkout/service.py
tests/test_checkout.py

这一块是 Agent 真正修改的地方。
它应该保持干净，围绕当前任务展开，不要塞入长期讨论和历史备忘。

右侧：反馈区

显示：

revision_log.md
open_issues.md

这里记录：

• 这轮为什么改
• 哪些测试通过
• 是否留下架构问题
• 下一轮该怎么看

顶部或底部：验收状态

显示：

空购物车是否返回 400
错误码是否为 EMPTY_CART
正常购物车是否仍然通过
是否修改了禁止文件
是否需要人工确认

这一块可以来自测试结果，也可以来自任务验收清单。

---

5. Agent 编程需要三块屏幕

传统编程主要围绕代码编辑器展开。

有了 Agent 以后，程序员实际面对的是三块屏幕。

第一块是对话框。
它承载本轮意图、临时解释、确认和人工判断。人通过对话框告诉 Agent 要做什么，也在这里决定是否扩大范围、暂停或继续。

第二块是 Dashboard。
它显示项目状态：当前任务、允许范围、禁止范围、最近修改、开放问题、验收结果和安全下一步。Dashboard 不替代状态文件，只把状态文件里的信息显示出来。

第三块是程序。
它包括源代码、测试、配置、diff 和运行结果。这里是真正发生修改和验证的地方。

这三块屏幕对应三种职责：

对话框     → 意图与协商
Dashboard  → 状态与方向
程序       → 修改与验证

Agent 编程的问题，很多时候不是 Agent 不会写代码，而是这三块屏幕混在一起：

• 对话框里堆满长期状态；
• 代码区里塞进临时说明；
• 人类看不到当前任务和开放问题；
• Agent 不知道哪些状态是权威来源。

所以工作台的意义，就是把三块屏幕分清楚。

对话框负责说清这一次。
Dashboard 负责看清现在。
程序区负责改对东西。

6. 一个最小的程序工作台模板

如果压缩成最小结构，可以这样理解：

workspace:
  map:
    - project_map.md
  task:
    - current_task.md
  code:
    - checkout/service.py
    - tests/test_checkout.py
  feedback:
    - revision_log.md
    - open_issues.md
  review:
    - acceptance summary

这个模板的重点不是 YAML，
而是它表达了一个很简单的事实：

• 认知单独放
• 任务单独放
• 代码单独放
• 反馈单独放
• 验收单独放

---

7. Dashboard 是工作台的只读视图

当项目还小的时候，人直接打开这些 md 文件就够了。

但项目变长以后，人类会遇到一个新问题：每次都打开四五个文件，才能知道现在做到哪了，很累，也容易漏。

这时可以给工作台加一个 Dashboard。

Dashboard 不是新的状态文件。Dashboard 是从状态文件生成出来的只读界面。

project_map.md
current_task.md
revision_log.md
open_issues.md
        ↓
Dashboard

Dashboard 可以显示：

当前任务：修复空购物车结算错误
允许范围：checkout/service.py, tests/test_checkout.py
禁止范围：payment/**, cart/model.py
最近转移：新增 EMPTY_CART 回归测试
开放问题：是否应把非空购物车规则上移到 domain model
验收状态：checkout suite passed
安全下一步：记录架构问题，不在本轮重构

它的作用是让人快速看清当前状态。

但 Dashboard 不能替代 md。

如果 Dashboard 和 current_task.md 冲突，以 current_task.md 为准。
如果 Dashboard 和 open_issues.md 冲突，以 open_issues.md 为准。
如果要关闭问题，仍然要更新 open_issues.md。
如果要扩大任务范围，仍然要修改 current_task.md。

一句话：

md 是状态源，Dashboard 是只读视图。

8. 先做只读 Dashboard

第一版 Dashboard 应该只读。

它只显示状态，不写回状态。

它可以做：

• 显示当前任务；
• 显示允许和禁止范围；
• 显示最近一次修改；
• 显示开放问题；
• 显示验收结果；
• 提示安全下一步。

它暂时不做：

• 不关闭 issue；
• 不修改 current task；
• 不扩大 allowlist；
• 不写 revision log；
• 不触发提交。

写回状态属于更高风险动作，需要单独任务、权限边界和验收规则。

所以最稳的路径是：

第一步：md 状态文件
第二步：只读 Dashboard
第三步：受控写回

不要一开始就把 Dashboard 做成能改状态的控制台。

9. 工作台为什么能帮助收敛？

因为它让每一轮都更清楚。

没有工作台的时候，Agent 容易这样跑：

改一点
看一点
再猜一点
顺手多改一点
最后边界越来越乱

有了工作台以后，流程会更稳：

先读项目地图
再读当前任务
只改允许范围内的代码
看测试和验收
把结果写回状态
下一轮继续

工作台不直接让 Agent 更聪明，但它让 Agent 更不容易把信息看串。

---

10. 人类为什么也需要工作台？

因为人类不只想看结果，
还想知道：

现在走到哪了
这轮为什么这么改
哪些问题还在
下一轮准备做什么
当前结果是否可以相信

如果没有工作台，人类就只能翻文件、看 diff、猜上下文。
那样很费力，也不稳定。

所以工作台还有一个很重要的作用：

让人类能快速接管，也能快速继续。

Dashboard 则是这个目标的进一步延伸：它把工作台里的关键状态显示成一个更容易看的界面。

---

11. 本章小结

工作台的核心不是界面，而是信息分层。

以购物车程序为例，Agent 的基本流程是：

• 先看项目认知
• 再看当前任务
• 只改允许范围内的代码
• 运行测试和验收
• 把结果写回日志和问题清单

Harness 负责控制动作，工作台负责摆放信息，Dashboard 负责只读呈现。

状态留在 md，视图交给 Dashboard。

下一章，我会继续讲：程序项目里的完整任务流，怎么从地图、任务、修改、验证，一直走到可提交状态。