核心结论
复杂任务能否稳定产出,取决于五层工程机制是否同时到位——上下文管理、需求对齐、开发引导、结果验收、流程固化;而不取决于换用更强的模型。
这五层构成一个自上而下的闭环:
上下文管理(让 AI 始终在能力最强的区间执行) → 需求对齐(先确认做的是对的事) → 开发引导(用对的方式把事做出来) → 结果验收(用客观方法证明做对了) → 流程固化(让这次的成功可以被复用)
验收不通过就回退到开发引导阶段重来,通过则提交代码并沉淀经验。跑得越多,流程越顺,输出也越稳。以下按这五层展开,每层先给结论,再给支撑该结论的做法,操作示例以 Claude Code 为主。
为什么小任务稳,复杂任务不稳?
先回答一个前置问题。小任务之所以输出稳定,是因为整个任务能装进模型"注意力最集中、判断力最强"的那个区间(以下称"聪明区")——目标清楚、上下文干净、一步就能验证对错。复杂任务不稳定,本质上不是模型能力不够,而是这五件事至少有一件失守了:
- 上下文被无关信息稀释,AI 已经不在聪明区里工作;
- 没人确认过"要做的是不是对的事",AI 在错误假设上狂奔;
- 开发计划按层铺开(先做完一整层再做下一层),做到最后才发现某一层不符合需求,返工成本极高;
- 没有客观标准判断"做完了"不等于"做对了";
- 每次都是从零开始摸索,同样的坑反复踩。
下面五层,分别针对这五个失守点给出解法。
一、上下文管理:让 AI 始终在"聪明区"执行
结论:上下文不是越长越好,管理的目标是在有限注意力下持续提供最关键的信息。做到这一点靠四件事——控制有效占用、实时监控占用、分层组织规则、阶段清零。
1. 控制有效占用 个人经验是把占用控制在 40% 以内作为警戒线,但这只是经验参考,并非有公开数据支撑的行业标准,不同模型和任务下实际边界会有差异。比数字更可靠的判断信号是:任务目标、已定决策、验收标准这些关键信息,是不是一眼还能看到——需要翻回很远才能找回来,说明该处理了。
2. 实时监控,及时压缩或重置
- 用
/context随时查看占用构成——大头往往是读过的文件和命令输出,而非对话本身; - 用
/statusline把占比常驻状态栏; - 到自然断点主动
/compact,并附保留指令,例如:"保留接口约定、验收标准和未完成任务,丢掉调试过程"; - 方向错了先回退再重写(Esc Esc /
/rewind),不要在错误状态上追加纠正——追加会把错误一起留在上下文里。同一问题连续纠正两次仍未解决,就不要试第三次,直接/clear重写提示词; - 在
CLAUDE.md里写好压缩保留指令,因为自动压缩触发时,往往正是上下文最满、判断力最弱的时候。
3. 分层组织规则,按需加载
CLAUDE.md 主文件只保留项目概览、规则索引、每条规则的触发条件;细节拆到独立文件,索引写成"什么场景读哪个文件"(如:改数据库 → 读 docs/db-rules.md)。必须每次都发生的硬约束(提交前跑测试、危险命令拦截)不要只写文档——写进 hooks 才是确定性,写文档只是建议。
4. 阶段清零,靠文档续接
复杂任务分阶段执行时,当前阶段完成后主动清零上下文,靠引用独立文档继续下一阶段。清零前先"存档"——进度写进 docs、代码提交到 git,这是清零的安全绳。之后新开会话,一句话续接:"读 docs/<需求名>-对齐文档.md,从任务 3 继续"。这份续接文档从哪来,是下一层"需求对齐"要解决的问题。
二、需求对齐:先确认"做的是对的事"
结论:需求对齐是为了避免 AI 在没搞清真实意图前就开发。做法是把规则固化进系统提示词——每次收到任务,先结合现有代码分析合理性、找冲突,有歧义就用 3–5 个问题确认,最后整理成文档。
1. 对齐什么 收到任务先做一轮代码调研,产出两张清单:冲突点(需求与现状矛盾的地方)、待确认项(不确认就会选错方向的隐含假设)。有冲突先确认,不带错误假设往下做。
2. 怎么对齐 存在歧义时一次性提 3–5 个关键问题,而不是边做边猜。格式上做到"有选项、有推荐":
【问题 2/4】新老用户表怎么切换?
A. 保持双写,新表先只读(推荐:回滚成本最低)
B. 直接切到新表并删除旧表(最快,但出错没有退路)
C. 双写 + 灰度开关(最稳,实现成本最高)
能从代码里查到答案的不要问用户;只问会改变实现方向的分叉。用户答不上来或答案矛盾的问题,不要替用户拍板——转为"待验证假设"写进文档、标注风险点,在最小可验证环节优先验证掉。
3. 对齐产物
整理成一份独立文档放进 docs:
docs/<需求名>-对齐文档.md
## 目标:一句话说清要什么
## 现状与冲突:任务与现有代码结合分析的结论
## 关键决策:3–5 个问题的确认结果(含未采纳方案及原因,含待验证假设)
## 任务拆解与依赖顺序:按最小可验证粒度逐条列
## 验收标准:每条任务的客观验证方式(命令 / 数据对照)
这份文档既是"阶段清零"的续接入口,也是下一层"开发引导"的直接输入。
三、开发引导:用对的方式把事做出来
结论:需求对齐只解决了"做什么",开发引导解决"怎么做"。做法是三步——先摸清代码边界,再用垂直切片(曳光弹)方式设计开发计划,最后用红绿开发驱动执行,并把这套动作固化成可复用的 skill。
1. 先摸清代码边界 拿到需求对齐产出的文档后,不要直接开写,先让 Agent 结合现有代码分析一遍:这次改动实际涉及哪些模块、哪些文件、依赖链路延伸到哪里。目的是划清"这次要动的边界"——边界不清,轻则漏改关联代码,重则误伤边界外的无关模块,后续验收时才发现改动范围本身就错了。
2. 用曳光弹方式设计开发计划,而不是按层铺开 AI 擅长按层完成任务:先把数据层全部写完,再统一做业务层,最后做 UI 层。这种做法有一个共同的隐患——每一层做完都验证不了实际效果,只有等最后拼装起来才知道对不对;一旦某一层的实现方向本身就不符合需求,前面投入的工作量全部要返工,浪费的不只是时间,还有已经产生的上下文和判断成本。
解法是把开发计划设计成垂直切片,也就是"曳光弹开发模式"——曳光弹打出去弹道可见,能立刻看到打偏了没有,而不是打完一整梭子弹才发现方向错了。具体做法:把任务拆成从入口到落库的最小闭环单元,先打通一条又窄又完整的链路,验证方向正确后再横向复制到下一条,而不是先把某一层的工作量全部吃完。这一步的产物,就是一份按垂直切片排好顺序的开发计划,直接对应对齐文档里的"任务拆解与依赖顺序"。
3. 结合红绿开发执行,并固化成 skill 有了垂直切片的开发计划,执行时按红绿开发(TDD)推进:每个切片先写一个失败的测试(红),再写实现让它通过(绿),之后重构;每个循环只驱动一个最小行为。
实操上,这一步通常伴随一次上下文清零:把红绿开发这套标准动作固化成一个 skill,清空当前上下文后,将"需求对齐文档"(阶段一产物)与"开发计划文档"(本阶段产物)一并导入,让 Agent 在干净的上下文里、按固定的 skill 流程逐个切片开发——既避免了上下文里堆积无关调试信息,也保证每次开发都遵循同一套动作,不依赖临场发挥。
所有切片开发完成后,即进入下一层——结果验收,对整体功能做全流程测试。
四、结果验收:确认"真的做对了"
结论:必须给 AI 一个可以客观验证是否通过的方法,且验证者要独立于开发者本人。开发引导阶段产出的是通过测试的代码切片,结果验收阶段要做的,是站在全功能、全流程的视角,用多方法交叉验证、独立 Agent 审查、复现优先的方式,确认整体确实做对了。
1. 多方法交叉验证
数据对不对必须用多种方法验证。例如采集内存使用数据,开发完成后要再用 adb dump memory 拿一份数据做对比,两者一致才能确定可用。如果结果对不上,不要默认以某一方为准去"消除分歧",而要当成新疑点:先确认两种方法测的是不是同一口径(采样时间点、单位、统计范围),排除口径问题后仍有差异,再引入第三种独立方法或人工核实。开工前先回答:"这个功能'对'的证据是什么?"——优先选能拿到客观数据的验证方式,而非"看起来能跑"。
2. 独立 Agent 审查 让 Agent 审查自己开发的功能,答案往往是满意的,所以要新开一个干净上下文的子代理,喂给它任务目标与验收标准、本次 diff、相关文档:
你是独立审查者,不要复述代码。输入:任务目标、验收标准、本次 diff。
逐条核对验收标准是否真的满足,每项给出证据;
找出:漏改的调用方、未覆盖的边界、以及"不可能失败"的测试。
输出:不通过项清单(每项附证据与复现方式);通过项只列一行。
另一个廉价有效的抽查:故意把实现改坏一处,看测试会不会变红——不会红的测试等于没有测试。审查 Agent 自己也可能判断错误,所以它给出的"通过"结论最好也用抽查再验证一次,而非当作绝对可靠的终点。
3. bug 修复从复现开始 全流程测试中发现 bug 时,Agent 往往不会从根因上解决,而是只在表层修复。为避免这种情况,"可复现"是修改的准入门槛:先构造最小复现(能稳定触发,只凭阅读代码"看出原因"不算数)→ 两向验证根因(消除它问题消失、恢复它问题再现,两个方向都成立才算真实根因)→ 复现用例留下来做回归,由红转绿才算修完。复现不了的 bug 先别动手,改完也无法证明改对了。若验收发现问题,回退到"开发引导"阶段重新走一遍垂直切片,而不是在当前实现上直接打补丁。
五、流程固化:让成功经验可复用
结论:把上述流程固化成可复用机制——验证通过就提交、出错就沉淀、用 workflow 编排全流程,复杂任务的稳定输出才能一次次复现。
1. git 管理:验证通过必须提交 按最小任务提交,一个最小可验证任务验收通过就提交一次,回退点越密出错代价越小;提交信息写清"做了什么 + 怎么验证的";每次清零或阶段收尾前先提交——它是清零的安全绳,也是出错时唯一可靠的回退路径。出错时就近回退到最近一次"绿灯"提交重来,不要在错误上打补丁。
2. 错误经验沉淀 AI 出问题时,需要人或 Agent 主动总结记录,用于后续避免类似问题——这一步目前更多依赖主动引导,而非系统自动完成。两个触发点:同一坑连续第二次出现、每次 bug 修完(尤其根因不显然时)。用四要素记法:触发条件、错误做法、正确做法、怎么检测——缺了"怎么检测",下次照样发现不了。记进 Claude Code 记忆或项目规则文件,新任务开工前让 agent 先查一遍。
3. workflow 编排 整条链路:
对齐 → 开发引导(摸边界+曳光弹计划) → 开发执行(红绿开发) → 验证 → 提交 → 沉淀
↑ │
└─ 不通过 ─────┘(回退重开发,直到通过)
落地步骤:先把流程文档化,每一步产物明确(对齐产出文档、开发引导产出切片化开发计划、开发执行产出通过测试的代码、验证产出证据、提交产出回退点);再把步骤交给 workflow,每个阶段对应一个 agent 职责,"验证不通过 → 回退开发"写成显式分支;不必一次到位,先固化最痛的一段(通常是"开发 → 验证 → 提交"),跑顺了再串下一段,每跑一轮把新踩的失败模式回填进记忆和流程。
落地清单
上下文管理
- ▢ 新任务开工前先
/context看占比;信息开始翻找困难就在最近断点处理(40% 仅作参考) - ▢
/statusline常驻占比 - ▢ 自然断点主动
/compact,附保留指令 - ▢ 走错方向先回退重写;同一问题连续纠正两次仍不对,
/clear重写 - ▢
CLAUDE.md只放概览+索引+触发条件,细节按需加载 - ▢ 硬约束搬进 hooks
- ▢ 阶段收尾:进度写 docs + 代码提交 git,再清零续接
需求对齐
- ▢ 收到任务先调研:冲突点 + 待确认项两张清单
- ▢ 有歧义一次提 3–5 个问题,带选项、推荐项、理由
- ▢ 只问会改变方向的分叉,能查代码的自己查
- ▢ 用户答不上来的转为"待验证假设",不替用户拍板
- ▢ 对齐结论、依赖顺序、验收标准落成 docs 文档
开发引导
- ▢ 开发前先让 Agent 结合现有代码摸清本次改动的边界
- ▢ 开发计划按垂直切片(曳光弹)设计,不按层铺开
- ▢ 每个切片从入口打通到落库,跑通一条再复制下一条
- ▢ 把红绿开发固化成 skill,清零上下文后导入对齐文档+开发计划文档再开始
- ▢ 每个切片:先写失败测试(红)→ 实现通过(绿)→ 重构
结果验收
- ▢ 开工前先定"怎么证明它对",优先客观数据对照
- ▢ 多方法结果不一致:先查口径,再排查问题方,不擅自取舍
- ▢ 能自动化的验证写成脚本/测试
- ▢ 独立子代理审查:目标+验收标准+diff → 带证据的问题清单
- ▢ 抽查测试有效性:改坏实现应变红;独立审查结论也要复核
- ▢ bug 修改三步:稳定复现 → 两向验证根因 → 复现用例红转绿
- ▢ 验收不通过:回退到开发引导阶段重做,不在当前实现上打补丁
流程固化
- ▢ 最小任务验收通过就提交,信息写"做了什么+怎么验证"
- ▢ 每次清零、阶段收尾前先提交
- ▢ 同一坑第二次出现:按四要素记入记忆
- ▢ 新任务开工前先查一遍记忆
- ▢ 流程画成带回退的链路,先固化最痛的一段再逐步扩展
结语
小任务靠模型能力就能完成,复杂任务的稳定性则要靠工程化流程。上下文管理让 AI 在聪明区执行,需求对齐保证做对的事,开发引导保证用对的方式把事做出来,结果验收用客观方法证明做对了,流程固化让一次成功变成每次可复用。五层构成闭环:验收不通过就回退到开发引导阶段,通过则提交并沉淀经验;流程越用越顺,输出也越来越稳。
