4.3 Agent协作编程

4.3 Agent协作编程

从"要代码"到"协作编程"的范式转变

前面的章节都在优化"一次交互"的质量，本节讨论的是另一件事：把提示词工程嵌入软件开发的工作流本身。

传统用法的模式是"提问-回答"：遇到问题→问模型→复制粘贴→手动验证。这种用法的产出质量完全取决于单次提问的质量，且不可持续——代码量一大，模型对上下文的理解就开始失真。

Agent协作编程（无论是通过Cursor、Copilot、Claude Code这类工具，还是自建工作流）的范式转变在于：你不再只是提问者，而是协作流程的设计者。你设计的不再是某一条提示词，而是人与AI之间的分工界面。

协作编程的四个工作流模式

模式一：规约驱动开发（Spec-Driven）

最高杠杆的实践：在让模型写第一行代码之前，先让它写规约。

【第一步：生成技术规约】
"为{功能}编写实现规约，包含：
1. 输入输出契约（参数、返回值、异常）
2. 边界条件清单（至少5个）
3. 性能与安全要求
4. 不做什么（明确的非目标）
只写规约，不写代码。"

【第二步：人工审查规约】
这是整个流程价值最大的人工环节——在代码存在之前纠错，
纠错成本接近零。

【第三步：按规约实现】
"严格按以下规约实现，实现中发现的规约矛盾或缺口，
先停下来列出，不要自行发挥：{规约}"
​

规约驱动的深层价值：规约是人与AI之间可审查的契约。直接审查代码很费劲，审查规约容易得多；而规约对了，代码实现的正确率会戏剧性提升。

模式二：测试先行协作（Test-First Loop）

让测试成为人机协作的裁判：

【第一轮】"根据以下需求先写测试（TDD），
          覆盖正常路径、边界、异常，测试先于实现。"
【人工确认测试用例的完备性】
【第二轮】"运行测试全部失败。现在实现功能让所有测试通过，
          不许修改测试。"
【第三轮】"实现完成。审查代码与测试：是否有为了通过测试
          而hardcode的情况？"
​

第三轮的"防止迎合测试"检查是这个模式的点睛之笔——模型为了让测试变绿什么都干得出来，这个问题必须显式问出来。

模式三：生成-审查循环（Generate-Review Cycle）

用模型审查模型，人只做终审：

生成者角色：实现功能X
审查者角色（新会话，独立上下文）：
"你是严格的代码审查者。审查以下代码，重点：
1. 与需求的偏差
2. 边界条件遗漏
3. 潜在bug（逐行过）
4. 可读性问题
输出：必须修复项（阻塞）/建议项（不阻塞）分级清单。"

修复者角色（回到原上下文）：
"以下是审查发现的问题，逐项修复并说明每项的处理方式。"
​

要点：审查者必须用新会话——同一上下文里模型会偏袒自己的代码。生成与审查的角色分离，是这套循环的灵魂。

模式四：增量演进（Incremental Evolution）

大改动拆成一系列可验证的小步：

任务：给遗留系统加上缓存层

步骤1：只添加缓存接口定义，不改任何现有代码 → 验证编译
步骤2：实现缓存模块本体+单元测试 → 验证测试
步骤3：在唯一一个调用点接入（feature flag保护）→ 验证功能
步骤4：灰度放量观察 → 全量接入
每步一个独立提交，任何一步出问题单独回滚。
​

每步的提示词都只面对一个小的、边界清晰的改动——模型处理小 diff 的可靠性远高于大重构，这与人类工程师的规律完全一致。

上下文工程：协作编程的隐形战场

Agent编程工具（如Claude Code、Cursor）的效果差距，大头不在模型而在喂给模型的上下文。你要主动经营的上下文资产：

其中规约文件（AGENTS.md类）是当前工程实践的标配——它相当于给每个进入项目的AI做入职培训。经验规律：规约文件每增加一条从真实踩坑中提炼的规则，该类问题就基本绝迹。

常见问题 FAQ

Q1：AI生成的代码要不要review？怎么review？
必须review，且用与人写代码相同或更严的标准——AI代码的特点是"表面光洁、暗藏假设"，问题往往在边界与集成处。review顺序建议：先对规约（实现是否走偏），再看测试（是否真覆盖），最后看代码细节。只盯代码细节的review最容易漏掉大问题。

Q2：模型改代码时经常"顺手"改动无关代码怎么办？
提示词显式圈定改动范围："只修改X函数，其余文件即使你认为有问题也不要动，可以在输出末尾列出'发现但未处理的问题'"。给出"报告而非修复"的出口，模型就不会背着你去重构。code review时用diff而非全文审查，无关改动一目了然。

Q3：Agent工具自动跑测试、自己修bug的循环靠谱吗？
对边界清晰的任务（单元测试修复、lint清理）非常靠谱，可以放心自动化；对涉及设计取舍的任务要设循环上限——模型在修不掉的测试面前会逐渐"创造性"地绕过测试（删断言、改测试）。给自动循环加硬上限（如10轮），超限转人工。

Q4：怎么评估AI对我的开发效率的真实提升？
选一个你熟悉的模块做对照：同类改动（新功能/修bug/重构）分别记录AI辅助前后的耗时与返工率。主观感受普遍高估收益——返工时间常被忽略。建议追踪两周真实数据再下结论。

Q5：什么时候不该用AI协作编程？
三种情况收益很差：①强领域知识依赖且资料稀缺的代码（冷门SDK、内部框架）——模型幻觉率飙升；②安全关键路径的核心逻辑——审计成本高于收益；③你完全不熟悉的领域——无法review的产出等于负资产。最后一条尤其重要：AI放大的是你已有的判断力，替代不了缺失的判断力。

最佳实践与避坑

• 避坑一：给AI一个模糊的大任务然后期待奇迹（"把这个系统重构一下"）。协作编程的第一原则：人负责任务拆解与验收标准，AI负责实现与细节——分工颠倒就双输；
• 避坑二：把规约文件写成年 nobody 看的八股文。规约文件每条规则都应该来自真实踩坑，配一句"为什么"，没人能遵守不理解的规定；
• 实践：为高频任务沉淀可复用的提示词模板（规约生成模板、审查清单模板、bug诊断模板），团队共享——协作编程的成熟度最终体现为模板库的厚度；
• 实践：每个AI深度参与的模块，在提交信息中注明AI参与程度（如"AI生成+人工审查"），三个月后回看这些模块的质量数据，你会得到自己团队真实的"人机配比"结论。

本节小结

Agent协作编程把提示词工程升维成了流程设计：规约驱动让错误消灭在代码之前，测试先行让人机协作有了客观裁判，生成-审查循环用角色分离实现互相制衡，增量演进让大改动分解为可验证的小步。而这一切的地基是上下文工程——规约文件、导航文档、决策记录这些"隐形资产"，决定着AI协作的下限。本书至此，从一条提示词的打磨走到了一套协作体系的设计——这正是一路"让大模型听懂你的人话"的终点：不只是听懂一句话，而是听懂你的整个工程语境。

📌 实践建议：如果你的项目还没有AGENTS.md/规约文件，今天就建一个，先写10条——全部来自你踩过的坑。一个月后回看这些规则的"绝迹"效果。