AI 编程最大的问题之一，是同一句“修这个 bug”，今天和明天可能跑出两种完全不同的过程。一次它先读测试，一次它直接改代码；一次会写计划，一次把计划省了；一次跑验证，一次嘴上说完成。
Archon 的思路很直接：不要把工程流程交给模型临场发挥，而是把计划、实现、测试、review、审批和 PR 创建写成工作流。模型负责每个阶段里的智能动作，流程负责约束它不能跳步。
先从一个小工作流开始
Archon 把 AI 编程流程写成 YAML。你可以把它理解成“GitHub Actions 给人类工程流程做的事，现在轮到 AI coding”。一个最小版本不需要复杂，先把四个节点跑通：计划、实现、测试、复查。
nodes:
- id: plan
prompt: "Explore the codebase and write an implementation plan."
- id: implement
depends_on: [plan]
loop:
prompt: "Implement the next planned task and update progress."
until: ALL_TASKS_COMPLETE
fresh_context: true
- id: test
depends_on: [implement]
bash: "bun run test"
- id: review
depends_on: [test]
prompt: "Review the diff against the plan and fix issues."真正关键的是 fresh_context 和 bash 这种混搭。需要判断的地方交给模型，需要确定性的地方交给命令。测试是否通过，不应该由 Agent 自己“感觉差不多”；能用脚本验证，就让脚本说话。
哪些任务值得上 Archon
不是所有小改动都要写 workflow。改个 typo，直接让 Agent 处理就行。Archon 更适合那些重复出现、容易漏步骤、需要团队一致性的流程：新增功能、数据库迁移、组件重构、安全修复、PR 生成、发布前检查。
如果团队已经有 code review 模板、测试矩阵、发布清单，就可以把这些规则逐步塞进 Archon。它的价值不是让模型更聪明，而是让模型每次都按同一套工程纪律走。
人类审批不要省
很多 AI 工作流工具喜欢把“全自动”放在最前面，Archon 真正值得用的地方反而是人工闸门。复杂改动到 review 节点时，应该让 Agent 解释 diff、列出风险、等待人类确认，再进入 PR 或部署阶段。
- id: approve
depends_on: [review]
loop:
prompt: "Present the changes and address human feedback."
until: APPROVED
interactive: true这能避免一个常见事故：Agent 为了完成任务，把测试改到能通过，把边界条件删掉，最后看起来绿了，其实逻辑已经歪了。AI coding 的生产化，不是让人消失，而是让人只出现在最该出现的节点。
Archon 适合被当成团队级“AI 编程操作手册”。把经验写进 workflow，后面的每一次执行才有可能稳定复现。