站在今天往回看，AI 编程这件事已经走过了“能写代码就行”的阶段，真正拉开差距的，其实是交付的可靠性和可追溯性。很多团队都在用自然语言描述需求、让 Agent 改文件、然后人眼看个 diff 就合并，听起来挺顺溜，但实际跑起来，坑一个接一个地冒出来——改 A 漏 B、联调才发现、同一需求翻来覆去讲好几遍、PR 能合但心里没底……这些痛点的根因其实不难归结：Agent 不知道系统长什么样，团队没有可复用的规格和任务依据，书面签收和自动化验收都缺位。
这套方法并不是从“企业治理办公室”里酝酿出来的。它的起点，其实很有个人色彩：一方面是预算有限，必须把每个 token 的价值榨到最大；另一方面是在团队里养成的习惯——需求拆分、Code Review、合并前 CI、书面留痕，这些一旦形成肌肉记忆，哪怕回到个人项目，也不会因为没人兜底就丢掉。日常主力是 Cursor Pro 的 Auto 模式，模型档次参差，输出风格飘忽不定，根本不指望每一次都靠“最强模型”来救场，而是要让不同档次的模型，在同一套框架里，产出可预期、可验收的结果。
两条线叠在一起，方向就明确了：上下文贵，不能整仓塞进 Prompt，那就给 Agent 一张“地图”，让它少读无关文件；模型输出不稳定、脾气难捉，那就把意图、成果、验收写进任务单，不完全依赖模型的临场发挥；一个人也要能说清楚“做完了”，那就用签收加 CI 来定义完成，而不是凭感觉。工具会变，但意图、成果、验收这三样东西不会变——这套方法不绑任何品牌，也正因为如此，才值得认真讲清楚。
为什么“会写代码”不等于“能交付”
TDD 没有过时，Code Review 没有过时，CI 也没有过时。AI 加入之后，真正缺的是两样东西：面向 Agent 的结构化上下文，和面向人的协作纪律。这才是 AI Coding 治理要补的短板——不是再发明一套敏捷方法论，而是让“告知、约束、验证”这三个步骤，在 AI 的场景下变得可执行。
很多团队习惯了“自然语言描述需求 -> Agent 改文件 -> 人眼看 diff -> 合并”这条流水线，问题恰恰出在这里：Agent 不知道系统结构，没有可复用的规格和任务依据，缺少书面签收与自动化验收，对话一长、账单就高，整仓塞给模型，无关文件太多。说白了，AI 并没有自动补齐工程纪律，它只是把传统工程里的薄弱环节放大了。
两条轨：结构与过程
技术图谱：让 Agent 先看地图再动手
技术图谱是个很直观的东西——模块关系、数据流向、契约清单，一张图就能把系统长什么样讲清楚。它要回答的核心问题其实就三个：系统长什么样？这次改动该从哪个入口看起？可能影响哪些模块、接口和测试？
举个例子，一条多模块 API 的主链路，从左到右是请求方向，方块标注的是入口名称，不是实现细节。主图不画满细节，每一个方块对应一篇子图，子图里单独展开内部步骤、依赖和测试锚点。Agent 拿到任务后，先在主图上定位到要改的模块，然后只打开对应的子图做关联性分析，不必把主图、所有子图和整仓目录一次性塞进 Prompt。这样做的效果很直接：主图定入口与边界，子图定这次改动的纵深，从“要改的那一格”钻进去，比从仓库根目录乱翻快得多，也更不容易漏关联。
图谱由人来维护，由脚本导出，如果暂时没有导出脚本，手动维护一张接口清单表格也可以，后续再自动化。初期不用追求完美，先画一张主图加一条子图，再逐步补全。关键改动可以用对照验证来评估“读图方式”是否值得推广。图谱解决的核心问题就是“别漂”——减少幻觉和漏改，它不替代写测试，也不是银弹。
协作流程：让协作可签收、可合并
协作流程是一套工程化的外壳，核心是规格驱动开发式的阶段流程与任务单纪律。它的骨架大致是这样：需求澄清 -> 任务审核 -> 实现 -> 自检 -> [合并前 CI 全绿？] ->（否，回到实现）-> 审查签收 -> 合并。每个阶段谁来做、怎么做，后续可以展开，但这篇先把骨架交代清楚。
和日常研发概念对应起来看就很容易理解：需求或规格这里，强调写清楚验收和非范围；Code Review 这里，强调书面审查落盘，终审就是可以结束任务；CI 这里，强调合并前必须全绿，不是“聊过了就算”；TDD 和单测这里，关键路径要先能失败再改实现，策略写在任务单里。协作流程解决的核心问题就是“别乱合并”——过程可追溯，不替代技术图谱。
叠放：缺一条都会“差点意思”
只有流程没有图谱，知道怎么审、怎么测，但仍然可能改错范围、漏掉依赖；只有图谱没有流程，知道改哪里、影响谁，但可能没有签收、没有 CI 就合并了。推荐的做法是叠放：同一轮需求里，任务单同时引用规格、图谱入口和测试策略；审查签收前，对照审查记录、CI 结果和实验结论来落锤。两条轨合在一起，才算是完整的交付闭环。
一轮交付怎样算“做完”
这个问题值得认真回答。一轮可闭环的交付，至少包含三个要素。意图：要达成什么、不做什么，这里对应需求或规格加边界。成果：可合并的代码、配置、文档、规则变更。验收：测试通过、CI 通过、审查签收、关键结论可追溯。
举个例子，给登录加图片验证码这个小需求。意图很明确：支持图片验证码防暴力破解，不影响已有信息登录。成果就是 login 增加校验、新增 captcha、配置 captcha_ttl=300、api.yaml 更新。验收标准也很清楚：单测 TestLoginWithCaptcha 通过，错误验证码的 curl 请求返回 401，CI 全绿，审查签收完成。研发功能和基础设施改造用的是同一套骨架，差别只在意图来自产品需求还是技术专题，验收证据里有没有额外的对照实验报告。
还可以加一个可选的第四步：闭环之后把教训蒸馏成半页以内的经验卡片或团队 Skill，服务下一轮同类任务。比如“缓存失效坑：改 A 必须清 B 缓存”，一句话教训就够了。不替代图谱，也不替代任务单。
与 TDD、Code Review、DevOps 的关系
TDD 仍然负责“行为对不对”，协作流程负责“这次改动有没有测试策略、敢不敢合并”。Code Review 这边，协作流程把“聊过”变成可检索的审查记录，图谱让 Reviewer 更快看清影响面。CI/CD 是自动化验收的硬背压，Agent 的自检不能代替流水线。Prompt、Rules、Skills 偏向个人与项目习惯，协作流程加图谱更偏向团队可审计的交付。它们可以叠加，但要避免两套冲突的流程。
适合谁、不适合谁
这套方法更适合多模块后端或全栈项目，依赖关系复杂；团队已经上了 PR 和 CI，希望 AI 改动可审计；也愿意维护一份活图谱，不必一步到位，可以从一条核心链路开始。暂时不强调的场景是一次性脚本、单文件作业，以及没有 CI、没有书面 Review 习惯的小团队——这类团队应该先补自动化验收，再谈 AI 规模化。
诚实地说，这套方法在已建模的图谱和有限范围的对照评测上验证过，不能直接宣称任意仓库、任意语言开箱即用。换模型、换仓库时，应该重新建立对照测试与评测记录，再谈指标。图谱与流程能降低风险、提高可预测性，但不保证零事故。如果团队还没有 CI，可以先定合并前必须手动跑的命令作为手动门禁，写在任务单里，再逐步补流水线。
最小起步
如果真想试一试，可以按这几步走。第一步，选一条核心链路，比如问答 API、登录、入库，画进技术图谱，接入导出校验，PR 改图时 CI 提醒。第二步，写第一份任务单，复制模板改标题和清单即可。第三步，定合并前必跑命令，比如 lint、test、build，写进仓库说明。第四步，跑通一轮：需求 -> 审核 -> 实现 -> 自检 -> CI 全绿 -> 审查签收 -> 合并。第五步，闭环后写一张经验卡片，放在仓库的 docs/experience 下或者个人笔记里都行。
任务单模板可以直接用。比如增加验证码登录这个需求，验收清单包括正确验证码能登录、错误验证码返回 401、验证码 5 分钟过期；失败路径包括验证码为空返回 400、验证码已过期返回 400；测试策略里必测两个单测，不适用性能压测；图谱入口指向子图；合并前命令是 lint、test、build。这个模板可以直接复制，改成自己项目的内容就好。
结语
AI Coding 的竞争力，越来越来自“上下文工程加工程纪律”，而不是多背几条 Prompt。图谱给的是空间结构，含子图，省上下文；协作流程给的是时间与责任，任务单加 CI 闸门。二者在“可闭环交付”这里汇合，最终以机器验收加人签收来落锤。可选的经验沉淀可以反哺下一轮子图阅读，但不替代图谱与协作流程。
图谱让 Agent 像熟路司机一样看导航，协作流程让团队像有交接单的工班一样交棒。两者叠好，一轮需求才能从“聊完了”变成“做完了，且说得清依据”——这才是 AI 时代研发治理该瞄准的状态。
