前面几篇已经把控制逻辑说清楚了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.pytests/test_checkout.py这一块是 Agent 真正动手的地方。它应该尽量干净不要塞太多状态说明和历史解释。2.4 反馈区放修改后的结果为什么这么改改了什么哪些测试通过哪些问题还没解决下一轮从哪里接对应revision_log.mdopen_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.mdtask:-current_task.mdcode:-checkout/service.py-tests/test_checkout.pyfeedback:-revision_log.md-open_issues.mdreview:-acceptance summary这个模板的重点不是 YAML而是它表达了一个很简单的事实认知单独放任务单独放代码单独放反馈单独放验收单独放7. Dashboard 是工作台的只读视图当项目还小的时候人直接打开这些 md 文件就够了。但项目变长以后人类会遇到一个新问题每次都打开四五个文件才能知道现在做到哪了很累也容易漏。这时可以给工作台加一个 Dashboard。Dashboard 不是新的状态文件。Dashboard 是从状态文件生成出来的只读界面。project_map.md current_task.md revision_log.md open_issues.md ↓ DashboardDashboard 可以显示当前任务修复空购物车结算错误 允许范围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。下一章我会继续讲程序项目里的完整任务流怎么从地图、任务、修改、验证一直走到可提交状态。