Initializer + Coding Agent
初始化 Agent 搭环境、编码 Agent 增量推进，双角色 Harness 设计
本页解决的问题
先给结论「Initializer + Coding Agent」要解决的关键问题是什么？
初始化 Agent 搭环境、编码 Agent 增量推进，双角色 Harness 设计
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
- 创建
init.sh脚本搭建开发环境 - 写
claude-progress.txt进度文件 - 把用户的高级提示展开成详细的功能清单（JSON 格式）
- 做第一次 git commit，确保仓库状态干净
- 读 progress 文件，了解当前状态
- 一次只做一个功能
- 完成后更新 progress 文件
- git commit 并写清楚做了什么
一种验证有效的做法是用 JSON 格式来记录功能清单，Markdown 不适合这个用途。原因是：模型更不容易错误修改结构化的 JSON，而 Markdown 容易被模型顺手重写。
- 1 每次完成一个功能后，代码处于可合并状态：没有半成品、没有语法错误
- 2 Git commit 提供回滚点：如果下一轮搞坏了什么，可以回到上一个干净状态
- 3 Progress 文件提供上下文：新 Agent 不用猜做到哪了，直接读文件就知道
- 4 上下文窗口不会溢出：每轮只需关注一个功能的上下文，不会积累到爆
Agent 容易以为做完了却没有端到端验证。它说「实现了登录功能」，但实际上按钮根本点不动。解决方案：
要真正打开浏览器、点击按钮、验证结果，光有单元测试还不够。让 Agent 用 Puppeteer / Playwright 写 E2E 测试，作为功能是否真正"passes"的判定标准。
「双角色解决方案」如何改变一次回答
「一种验证有效的做法是用 JSON 格式 来记录功能清单，Markdown 不适合这个用途。原因是：模型更不容易错误修改结构化的 JSON，而 Markdown 容易被模型顺手重写」说明，模型处理的不是我们眼中的“字数”，而是一段段 Token。Token 的切分方式会影响输入长度、上下文能放下多少内容，以及一次请求要花多少计算。
长度、信息量和上下文不是一回事
当「Agent 容易以为做完了却没有端到端验证。它说「实现了登录功能」，但实际上按钮根本点不动。解决方案」变长时，先要分清三件事：文字被切成多少 Token、哪些内容真正参与当前判断、以及旧内容是否已经超出上下文窗口。删掉重复说明通常比单纯把窗口开得更大更有效。
- 写 claude-progress.txt 进度文件
- 把用户的高级提示展开成详细的功能清单（JSON 格式）
- 做第一次 git commit，确保仓库状态干净
先保留会改变判断的内容
可以用「Agent 容易以为做完了却没有端到端验证。它说「实现了登录功能」，但实际上按钮根本点不动。解决方案」做一次对照：保留同样的问题，分别删掉重复背景、压缩格式和移除无关历史，比较答案质量、延迟与 Token 数量。
从「双角色解决方案」走到「功能清单的设计」
「双角色解决方案」先把问题落在「两个 Agent，明确分工 只跑第一轮 Initializer Agent 负责从零到有：搭环境、定计划、做第一次提交 创建 init.sh 脚本搭建开发环境 写 claude-progress.txt 进度文件 把用户的高级提示展开成详细的功能清单（JSON 格式） 做第一次 git commit，确保仓库状态干净 每轮都跑 Coding Agent 负责从有到多：逐个功能实现，持续推进 读 progress 文件…」上；到了「功能清单的设计」，讨论继续推进到「一种验证有效的做法是用 JSON 格式 来记录功能清单，Markdown 不适合这个用途。原因是：模型更不容易错误修改结构化的 JSON，而 Markdown 容易被模型顺手重写」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
处理长文本时，先保留会改变结论的内容，再决定如何压缩格式和历史；上下文更长只有在新增信息真正有用时才值得付出代价。
- 「双角色解决方案」：两个 Agent，明确分工 只跑第一轮 Initializer Agent 负责从零到有：搭环境、定计划、做第一次提交 创建 init.sh 脚本搭建开发环境 写 claude-progress.txt 进度文件 把用户的高级提示展开成详细的功能清单（JSON 格式） 做第一次 git commit，确保仓库状态干净 每轮都跑 Coding Agent 负责从有到多：逐个功能实现，持续推进 读 progress 文件…
- 「功能清单的设计」：一种验证有效的做法是用 JSON 格式 来记录功能清单，Markdown 不适合这个用途。原因是：模型更不容易错误修改结构化的 JSON，而 Markdown 容易被模型顺手重写
- 「最后的要点」：2 Git commit 提供回滚点：如果下一轮搞坏了什么，可以回到上一个干净状态
最后的「最后的要点」把讨论落到「2 Git commit 提供回滚点：如果下一轮搞坏了什么，可以回到上一个干净状态」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。