先说结论
我让 AI 自主编程跑了 8 个多小时，Token 消耗仅 0.3%，产出的代码质量稳定、无明显缺陷。
秘诀是三点：
- 先写文档，再写代码——用 Claude Code 做任务拆解和方案设计，形成完整的执行文档
- 主从式 Agent 结构——一个”指挥官”负责决策，多个”士兵”负责执行
- 利用计费差异——把执行工作交给按请求次数收费的 GitHub Copilot，而不是按 Token 收费的模型
这套流程打磨了一个多月，核心思想是：人负责定义”做什么”，AI 负责搞定”怎么做”。
核心概念
什么是文档编程？
文档编程 = 在写代码之前，先让 AI 把方案写成文档。
打个比方：你请了一支装修队，你不会直接说”把房子装好”就走人。你会先确认设计方案、材料清单、施工顺序。文档编程就是这个”确认方案”的过程——只不过方案也是 AI 帮你写的，你只需要审核。
什么是主从式 Agent 结构？
主从式（Coordinator-Worker）是一种常见的分工模式：
- 主 Agent（Coordinator）：负责理解需求、拆分任务、分配工作、做决策。类比：项目经理
- 从 Agent（Worker）：负责执行具体任务。类比：开发工程师
在我的方案里：
- 主 Agent = Claude Code（擅长理解、规划、推理）
- 从 Agent = GitHub Copilot（擅长快速生成代码，且按请求计费，成本极低）
什么是 Context Engineering？
Context Engineering（上下文工程）是指精心组织和管理 AI 的输入信息，让它在正确的时间拿到正确的上下文。
类比：你让一个新同事接手项目，你需要告诉他项目背景、当前进度、代码规范、已知问题。如果信息给得不全，他就会瞎写；如果信息太多太杂，他会被淹没。Context Engineering 就是在”信息太少”和”信息太多”之间找到平衡。
系统架构
整个系统的执行流程如下：
┌─────────────────────────────────────────────────────┐
│ 人：定义需求 │
│ ↓ │
│ Claude Code（主 Agent）： │
│ ├─ 理解需求 → 拆分任务 → 写入 TASKS.md │
│ ├─ 设计方案 → 写入执行文档 │
│ └─ 启动执行流程 │
│ ↓ │
│ GitHub Copilot（从 Agent 集群）： │
│ ├─ Explore Agent：探索代码、收集信息 │
│ ├─ Code Agent：执行编码任务 │
│ ├─ Review Agent：完成后做 Code Review │
│ ├─ Repair Agent：根据 Review 结果修复问题 │
│ └─ Experience Agent：沉淀本轮经验 │
│ ↓ │
│ CURSOR.md 记录进度，循环直到所有任务完成 │
└─────────────────────────────────────────────────────┘过程管理靠两个文件：
- TASKS.md：任务清单，管”做什么”
- CURSOR.md：执行进度，管”做到哪了”
这两个文件就像接力赛的交接棒——每个 Agent 完成自己的部分后，更新文件，下一个 Agent 读取后继续执行。全程不需要人介入。
实际执行效果
代码质量
每轮任务完成后会自动触发 2～3 轮 Code Review（代码审查），发现问题就修复，逐步收敛。最终产出的代码：
- 无明显缺陷
- 覆盖了一些额外的性能优化场景
- 风格统一、符合规范
成本数据
- 总运行时间：8+ 小时
- Token 消耗：仅 0.3%（因为执行层用的是 Copilot，按请求次数计费）
- 等效结论：这种模式下，Copilot 的额度几乎用不完
耗时分布（最大的问题）
分析整个 8 小时的执行过程：
| 活动类型 | 占比 | 说明 |
|---|---|---|
| 真正写代码 | 48.7% | Agent 在执行编码任务 |
| Review + Fix + Recheck | 51.3% | 质量闭环：审查、修复、验证 |
超过一半的时间花在了”检查和修复”上，而不是”写代码”上。
为什么质量闭环这么耗时？
这是主从式 Agent 做复杂 Context Engineering 的必然代价。
原因是：每完成一个阶段（Phase），Agent 进入下一阶段时需要重建上下文。具体来说：
- 重新加载相关代码文件
- 读取上一轮的 Review 结果
- 加载项目规范和约束
- 同步 TASKS.md 和 CURSOR.md 的最新状态
这就像一个人每天早上到公司，要先花 30 分钟回顾昨天做了什么、今天要做什么，才能开始干活。Agent 也一样——每次”换挡”都有启动成本。
类比：如果你把一个大任务交给 5 个人接力完成，每个人接手时都要花时间”看看前面的人做了什么”。人越多、交接越频繁，这个开销就越大。
优化方向
目前看到两条可行的路径：
路径一：压缩执行链路
把文档驱动的流程逐步固化为代码逻辑。
比如：Review 的检查项、Fix 的修复模式，如果是重复出现的，就做成自动化规则，不需要每次让 Agent 从头推理。
类比：新手厨师每道菜都要看菜谱，但熟练之后，常做的菜凭肌肉记忆就能搞定。
路径二：优化 Context 切换效率
- 增量更新：只加载上一阶段变化的部分，不重新加载全部
- 差异加载：只传递 diff，不传递完整文件
- 状态缓存：把已确认的中间结果缓存起来，避免重复计算
类比：每天上班不用重新看整本项目文档，只看”今日更新”就够了。
不过坦白说，再往下优化，边际收益已经不高了——8 小时跑完一个大需求，成本几乎为零，这个 ROI 已经很不错了。
常见误区
误区一：“AI 自主编程 = 完全不用管”
不是。人需要做的是：定义需求 + 审核方案 + 验收结果。中间的执行过程确实不需要管，但前后两端离不开人。
误区二：“跑得越快越好”
速度不是第一优先级。这套方案追求的是无人值守下的质量稳定性。宁可多跑几轮 Review 让代码更健壮，也不要为了快而跳过质量检查。
误区三：“任何任务都适合这套流程”
不是。这套流程适合大需求、多文件、多步骤的场景。如果只是改个 bug 或加个小功能，直接让 AI 写就行，不需要走完整流程。
误区四：“按请求计费 = 免费”
Copilot 的确按请求计费且额度很高，但如果任务拆分不合理（比如一个 Agent 反复重试失败），也会浪费请求次数。好的任务拆分是前提。
总结
| 要素 | 做法 | 效果 |
|---|---|---|
| 方案设计 | Claude Code 做文档编程 | AI 不会跑偏 |
| 任务执行 | Copilot 按文档执行 | 成本极低（0.3%） |
| 质量保障 | 自动 Review + Fix 循环 | 代码稳定无缺陷 |
| 进度管理 | TASKS.md + CURSOR.md | 全程可追踪 |
一句话总结：让贵的模型做决策，让便宜的模型做执行，用文档把两者串起来。
FAQ
Q：为什么用 Claude Code 做主 Agent 而不是 Copilot？
因为主 Agent 需要强推理能力——理解复杂需求、做架构决策、拆分任务。Claude Code 在这方面表现更好。而 Copilot 擅长在明确指令下快速生成代码，适合做执行层。
Q：TASKS.md 和 CURSOR.md 是什么格式？
就是普通的 Markdown 文件。TASKS.md 是一个 checklist（任务清单），CURSOR.md 记录当前执行到哪一步、上一步的结果是什么。格式不重要，关键是让 Agent 能读懂。
Q：如果 Agent 执行中出错了怎么办？
系统内置了 Repair Agent。如果 Review 发现问题，Repair Agent 会尝试修复。如果修复失败超过阈值，会暂停并等待人工介入。
Q：这套方案的学习成本高吗？
前期需要投入时间设计执行流程和文档模板（大约 1-2 周迭代）。但一旦跑通，后续每个需求只需要”定义需求 → 启动 → 验收”三步。
Q：8 小时是不是太久了？
看场景。如果是需要人盯着的 8 小时，确实太久。但这是无人值守的 8 小时——晚上启动，早上看结果。相当于免费多了一个”夜班程序员”。