复杂任务为什么难

先说结论：复杂任务难的不是写代码，是下面四件事。

• 需求模糊：说需求的人自己都没想清楚。“文档核验要留痕”，留什么痕？按什么查？入口放哪？全要靠推。
• 代码陌生：改的不是自己写的代码库，路由注册在哪、DAO 怎么组织、有没有现成的组件，一无所知。
• 链路长：一个需求横跨后端服务、管理后台、上层服务三个仓库，联调对不上是常态。
• 步骤多：建表、写记录、加接口、做页面、上层同步，十几步里漏掉任何一步，都要返工。

过去我处理复杂任务靠"经验 + 加班"：经验让我少踩坑，加班补上流程损耗。现在我用 Claude Code 的 workflow 跑，发现上面四类复杂度可以分别拆掉。

一、需求模糊？先探索，再一次一个问题

需求模糊是复杂任务的第一个坑，也是最贵的坑：设计错了，后面全白做。

我的做法是两段式：先让 AI 探索代码，再让它一次只问一个问题。

拿最近一个"核验记录"需求举例。AI 先翻了两个仓库，带回几个关键事实：文档表上已经有"核验状态"字段，核验逻辑集中在文档服务的一个方法里，前端代码里已经有现成的下拉加载 hook。这些事实直接改变了设计：记录表和状态字段是两回事，但很多人第一版会把它们混在一起。

然后进入提问环节，一次一个问题：

我：核验记录存哪些字段？ AI：除了核验人和核验时间，要不要存版本号？这决定表结构。 我：先只存核验人和核验时间。 AI：好。那列表按数据集 ID 过滤、分页返回，对吗？

每个答案都在修正下一个问题。一次抛十个问题，AI 只能靠猜排优先级，猜错一半就得返工。模糊需求最怕的不是问得少，而是问得乱。

二、代码陌生？子代理并行探索

复杂任务往往意味着大型代码库。让主会话把每个文件都读一遍，上下文直接爆炸；不让它读，问的问题全是空对空。

我用子代理解决：只读的探索型子代理，各自负责一个方向，跑完只把结论带回来。

还是那个需求。两个仓库，我开了两个子代理并行：

• 一个查后端：核验逻辑在哪个方法里？用什么 ORM？表结构长什么样？
• 一个查前端：数据管理页面结构？有没有现成的分页/下拉加载组件？

主会话的上下文只收到两条结论，干净利落。复杂任务拆给子代理，等于给主会话外挂了好几个只读大脑。

三、步骤多？用 spec 锚定，用计划兜底

十几步的任务，光靠"记住"一定会漏。我的流程里有两个强制环节：

第一步，设计获批后写 spec 文档。表结构、接口定义、前端改动点、上层同步点全部落盘。这份文档是后续所有工作的锚点：代码评审不再对着记忆逐条想，而是对着 spec 逐条核对。

第二步，用计划技能把设计翻译成有序任务。先改什么、后改什么、每个任务做完怎么验证，都拆成文件级清单。执行阶段照着走，不会顾此失彼。

复杂任务最怕的不是步子慢，而是做完了发现做的是另一个需求。spec 就是防这件事的。

四、链路长？add-dir 多项目，一个会话挂三个仓库

跨仓库任务的真正成本不在写代码，在于两边对不上：前端叫 page 后端叫 current，接口路径差一个斜杠，联调半天。

Claude Code 的 add-dir 可以把多个项目目录加进同一个会话，三个仓库的上下文同时可见。字段名、接口路径、分页参数在计划阶段就定死，代码照着写就行，联调成本趋近于零。

以前这种需求：拉群 → 各自开工 → 联调发现对不上 → 返工。现在：一个会话、一份 spec、三份代码同时改。

五、改错返工？hooks 门禁 + 验证闭环

复杂任务最容易在最后一步翻车：改完了、自测过了，忘了检查脱敏、忘了跑构建、忘了验证线上。

我的解法是 hooks：把检查前置到事件本身。比如写文件前必须声明事实（这个文件被谁引用、里面有没有敏感内容），执行破坏性命令前必须给出回滚方案。检查不是"记得就做"，而是流程的必经环节，不做就卡住。

收尾阶段再加一道验证：构建无错误、线上返回 200、关键内容比对通过，才算完成。质量不是最后检查出来的，是流程逼出来的。

我的工作流时间线

一个复杂任务在我这里是这样的节奏（示意）：

flowchart LR
    T1["探索 + 脑暴"] --> T2["方案 + spec"] --> T3["实施计划"] --> T4["执行三仓"] --> T5["评审 · 验证 · 部署"]

对比以前的节奏：需求评审会一轮、文档两轮、联调两轮、返工一轮，光流程损耗就吃掉一半时间。

收尾

复杂任务的复杂度分布大概是这样：需求 > 链路 > 步骤 > 代码。Claude Code 的 workflow 没有任何魔法，它只是把"该问的、该查的、该记的、该验的"变成了流程的默认动作，让 AI 和人的精力都集中在真正难的地方。

真正快的不是写代码那一下，而是不返工。

封面图：jurvetson / Flickr · CC BY 2.0