任务拆解的三层模型

为什么需要一个模型

没有框架的拆解就像凭感觉写代码——有时候碰巧拆对了，更多时候要么遗漏关键步骤，要么拆得太粗导致 Claude 还是在猜你的意图。

我自己摸索了一段时间后，总结出一个简单但好用的拆解框架：目标层 → 步骤层 → 验证层。 这三层不是什么高深理论，本质上就是回答三个问题：做完了长什么样？分几步走？每一步怎么确认做对了？

第一层：目标层——做完之后，世界有什么不同？

目标层要回答的核心问题是：做完这件事之后，你能用什么方式判断它「做到了」？

[反例] "重构 auth 模块"
[正例] "auth 模块拆分为 login / register / token 三个独立服务，
    现有 API 接口不变，所有测试通过"

上面两种写法的差别在哪？第一种只描述了动作（重构），第二种描述了结果（三个独立服务 + 接口不变 + 测试通过）。描述结果的好处是它天然可验证——做完后你能明确判断「做到了」还是「没做到」，不需要靠主观感受。

我发现一个简单的检验方法：如果你的目标描述里出现了「优化」「改进」「完善」这类词，通常意味着还不够具体。试着加上数字或者明确的完成条件。

第二层：步骤层——具体分几步走？

目标定清楚了，接下来拆步骤。继续用 auth 重构的例子：

1. 分析现有 auth 模块的依赖关系
2. 创建 login 服务，迁移登录逻辑
3. 创建 register 服务，迁移注册逻辑
4. 创建 token 服务，迁移 token 管理
5. 更新路由层，指向新服务
6. 运行测试，修复失败用例

这里有一个很重要的操作建议：每一步对应一次独立的 Claude Code 对话。 不要试图在一个 prompt 里把所有步骤塞进去。一来上下文会很快被撑满，二来 Claude 在长对话后期的表现会明显下降。分开对话，每次聚焦一件事，反而更高效。

第三层：验证层——怎么确认做对了？

步骤拆好了还不够，你得知道每一步怎么验证。这一层很多人会忽略，觉得「做完跑一下不就行了」。但如果等到最后才验证，出了问题你根本不知道是哪一步引入的。

步骤	验证方式
分析依赖	输出依赖图，人工确认
迁移 login	login 相关测试全部通过
迁移 register	register 相关测试全部通过
迁移 token	token 相关测试全部通过
更新路由	全量测试通过 + 手动 API 测试

有一次我在做一个数据库迁移项目时偷懒，连续跑了三步才去验证，结果发现第一步的字段映射就有问题，后面两步全白做了。从那以后我养成了一个习惯：每完成一步就验证，验证通过就 commit。这样出问题的时候能精确回退到上一个好的状态，而不是从头来过。

三层模型不是什么银弹，但它能帮你在动手之前多想三十秒。这三十秒的思考，经常能省下后面三十分钟的返工。