分步拆解大需求：先设计接口、再实现类、最后写测试，别让 AI 一次生成全部

一、问题的本质：为什么"一次生成全部"必然失败

先看一个真实场景。你把这样一段需求丢给 AI："做一个支持多租户的任务管理系统，要有任务分配、状态流转、权限控制、通知提醒、审计日志。"几秒后，AI 返回了 800 行代码，包含实体类、服务类、控制器、几个工具函数。你复制进项目，编译——报错。修完编译错误，运行——空指针。再修，发现权限逻辑根本没实现，通知模块调用了不存在的方法。两个小时后，你删掉了其中 70% 的代码，自己重写。

这不是 AI 能力不行，而是任务粒度和验证方式同时失控。需求越大，AI 需要"猜"的隐含约束越多：命名规范、异常处理策略、依赖注入方式、数据校验时机、并发模型……每一个猜测点都是一次潜在的偏离。而当你拿到 800 行代码时，你没有任何中间检查点，只能整体验收——这等价于把验证成本堆到了最后。

1.1 大需求的三重不确定性

笔者认为，把大需求直接交给 AI，会同时引入三种不确定性，它们相互叠加，导致失败概率呈乘性放大而非加性增长。

不确定性类型	具体表现	后果
语义不确定性	需求本身模糊，AI 自由发挥	实现与预期偏离，返工
结构不确定性	模块边界、依赖方向未定	耦合严重，无法单测
验证不确定性	没有中间检查点，只能整体验收	错误定位成本极高

假设每一类不确定性导致返工的概率是 30%，三类叠加后"一次通过"的概率约为 0.7³ ≈ 34%。也就是说，三分之二的概率你需要重来。这个估算虽为简化模型（模拟数据，仅用于说明量级），但它揭示的方向是确定的：不确定性会乘性累积。

1.2 研究证据：LLM 长上下文生成的可靠性衰减

这一直觉有实证支撑。2023 年斯坦福大学等机构提出的"Lost in the Middle"研究（Liu et al., 2023）发现，当关键信息位于长上下文的中部时，模型检索和利用该信息的准确率显著下降，呈 U 形曲线。2024 年多篇关于长代码生成的评测（如 RepoBench、LongCodeBench 相关工作）也指出，随着生成目标代码长度增加，模型在跨函数一致性、变量作用域、依赖调用上的错误率明显上升。

本文评述：这些研究共同指向一个工程结论——不要指望模型在一次生成中维持全局一致性。与其对抗这个特性，不如顺应它：把大任务切成小任务，让每次生成都落在模型"注意力最集中、上下文最短、验证最容易"的区间内。这正是分步拆解的科学依据，而非经验之谈。

1.3 一个反直觉的观察

很多工程师的第一反应是"那我给 AI 更详细的提示不就行了？"实践中，超长提示往往带来新问题：模型会忽略部分指令、指令之间相互冲突、关键约束被淹没在细节里。2024 年关于指令遵循（Instruction Following）的研究（如 IFEval 及相关工作）显示，当单条提示包含的约束数量超过一定阈值后，模型的约束满足率会下降。

核心洞察：提示的"信息量"不等于"可控性"。真正提升可控性的，是把一次大提示拆成多次小提示，每次只解决一个可验证的子问题。这就是本文主线——契约先行三段式拆解——的出发点。

二、理论根基：认知负荷、契约式设计与 TDD 的三重支撑

分步拆解不是拍脑袋的土办法，它背后有三条成熟的理论脉络。理解它们，才能把"凭感觉拆"升级为"有依据地拆"。

2.1 认知负荷理论：人和 AI 都怕"信息过载"

John Sweller 于 1988 年提出的认知负荷理论（Cognitive Load Theory）把工作记忆的负担分为三类：内在负荷（任务本身的复杂度）、外在负荷（呈现方式带来的额外负担）、相关负荷（用于构建图式的有效负担）。核心结论是：工作记忆容量有限，外在负荷应尽量降低，把容量留给相关负荷。

本文评述：虽然该理论原本描述人类认知，但笔者认为它对 LLM 同样有隐喻价值。模型的上下文窗口和注意力机制，在功能上类似"工作记忆"——容量有限、易受干扰。大需求一次性输入，相当于把内在负荷和外在负荷同时拉满，模型没有余力去构建正确的"代码图式"。分步拆解，本质是降低单次任务的外在负荷，让模型把能力集中在当前子问题上。

2.2 契约式设计：把"应该怎样"写成"必须怎样"

Bertrand Meyer 在 1986 年提出契约式设计（Design by Contract, DbC），并集成进 Eiffel 语言。其核心是三要素：前置条件（precondition，调用方必须满足）、后置条件（postcondition，被调方必须保证）、不变式（invariant，始终成立）。契约明确了"谁负责什么"，一旦违反立即失败，而不是悄悄产生错误结果。

本文评述：DbC 与 AI 协作的契合点在于——契约是"可验证的接口"。当你让 AI 先写接口（含前置/后置条件），你就获得了一个明确的验收标准。AI 后续的实现只要满足契约即可，你无需逐行审查实现细节。这把"审查代码"变成了"验证契约"，验证成本大幅下降。这也是本文把"先设计接口"放在第一步的理论依据。

2.3 测试驱动开发：用测试锁定行为

Kent Beck 在 1990 年代末推广的 TDD，遵循"红—绿—重构"循环：先写一个失败的测试（红），再写最少代码让它通过（绿），最后重构。TDD 的价值不在于"测试多"，而在于测试先行迫使你明确接口和行为。

本文评述：把 TDD 与 AI 结合，会产生一个有趣的化学反应。传统 TDD 中，人写测试、人写实现；AI 协作下，可以演化为"人定契约与测试、AI 写实现"。测试成为人与 AI 之间的可执行合同：AI 的实现只要通过测试，就达到了最低验收标准。这比"让 AI 自己说写完了"可靠得多。

理论	提出者/年代	对本文方法的贡献
认知负荷理论	Sweller, 1988	解释为何要拆小任务
契约式设计	Meyer, 1986	提供接口即契约的思想
测试驱动开发	Beck, 1990s	提供行为锁定的手段

三、主线方法论：契约先行的三段式拆解框架

把三条理论拧成一股绳，就得到本文的核心框架。它只有三步，但每一步都有明确的产出物和验收标准。

这条主线的独创性在于：它把"验证"从最后一步前移到了每一步。接口阶段用编译验证，实现阶段用契约验证，测试阶段用断言验证。AI 的每一次输出都有对应的"检查点"，而不是等到最后才发现跑不起来。

3.1 为什么是这个顺序，而不是别的顺序

有人会问：为什么不先写测试（经典 TDD 是测试先行）？为什么不是"先写实现再补接口"？

笔者认为，在 AI 协作场景下，"接口 → 实现 → 测试"的顺序有其特殊合理性。原因有三：

1. 接口是人与 AI 的"共同语言"。接口是需求的最小可执行表达，先对齐接口，等于先对齐了双方对需求的理解。测试先行在纯人工 TDD 中可行，但让 AI 先写测试，它可能写出"符合自己理解"的测试，反而固化错误理解。
2. 接口提供编译级验证。接口写错，编译不过，立即发现。这是成本最低的验证手段。
3. 实现依赖接口，测试依赖两者。顺序符合依赖方向，避免返工。

当然，这不是教条。对于行为复杂、边界密集的模块（如计费、状态机），可以在接口之后、实现之前先补测试，形成"接口 → 测试 → 实现"的变体。核心不变的是：每一步都要有可验证的产出。

四、第一阶段：设计接口——把需求翻译成契约

接口阶段的目标只有一个：把模糊的自然语言需求，翻译成机器可检查的契约。这一步做扎实，后面两步会顺很多。

4.1 从需求到接口的四步翻译法

拿到大需求后，不要急着让 AI 写代码。先做四件事：

第一步：识别名词，提取领域实体。需求里的名词往往是实体或值对象。以"多租户任务管理系统"为例，名词有：租户、任务、用户、角色、通知、日志。这些就是候选的领域模型。

第二步：识别动词，提取行为接口。需求里的动词往往是方法。"任务分配"→ assignTask，"状态流转"→ transitionStatus，"权限控制"→ checkPermission，"通知提醒"→ notify，"审计日志"→ audit。每个动词对应一个或一组接口方法。

第三步：为每个方法定义输入输出与约束。这是契约的核心。输入是什么类型？输出是什么？什么情况下抛异常？什么情况下返回空？并发下是否安全？

第四步：确定模块边界与依赖方向。哪些接口属于同一模块？模块之间谁依赖谁？依赖必须是单向的（依赖倒置原则），否则无法独立测试。

4.2 接口契约的模板

一个合格的接口契约，应该包含以下字段。下面用 Java 风格伪代码示意，其他语言可类比。

/**
 * 任务分配服务契约
 * 前置条件：taskId 非空且对应任务存在；assigneeId 非空且是租户内有效用户
 * 后置条件：任务负责人变更为 assigneeId；状态从 PENDING 变为 ASSIGNED；
 *           生成一条审计日志；向 assignee 发送通知
 * 异常：TaskNotFound / UserNotInTenant / IllegalStateTransition
 * 并发：同一 taskId 的并发分配需串行化（乐观锁或分布式锁）
 */
public interface TaskAssignmentService {
    AssignmentResult assign(String tenantId, String taskId, String assigneeId, String operatorId);
}

本文评述：注意契约里写了"并发：需串行化"。这类非功能性约束，恰恰是 AI 最容易忽略、也最容易埋雷的地方。把非功能约束显式写进契约，是分步拆解相对"直接生成"的关键增量。否则 AI 会给你一个单线程下正确、并发下崩溃的实现。

4.3 让 AI 参与接口设计的正确姿势

接口阶段可以也应该让 AI 参与，但角色是"候选生成器"而非"决策者"。推荐流程：

1. 你先用四步翻译法列出实体、行为、约束的草稿。
2. 把草稿给 AI，让它"补充遗漏的边界情况和异常场景"。
3. 你审查 AI 的补充，决定采纳哪些。
4. 让 AI 把最终契约写成接口代码。
5. 编译，确保接口本身无语法错误、依赖方向正确。

这个流程的关键是人负责"决定"，AI 负责"枚举"。AI 擅长穷举可能性，人不擅长；人擅长判断取舍，AI 不擅长。分工明确，效率最高。

4.4 接口阶段的验收清单

检查项	通过标准
可编译	接口代码无语法错误，依赖可解析
职责单一	每个接口只描述一类行为
契约完整	前置/后置/异常/并发均有说明
依赖单向	无循环依赖，可 mock
命名一致	符合项目既有命名规范

关于接口设计原则，可参考 Martin Fowler 的契约式设计与接口设计相关文章，以及 Oracle 官方的Java 接口教程。

五、第二阶段：实现类——在契约约束下填充逻辑

接口定稿后，实现阶段就变成了"填空题"：在既定签名和契约下，填充方法体。这一步 AI 的产出质量会显著提升，因为边界已经清晰。

5.1 一次只实现一个接口

这是最重要的一条纪律。不要一次让 AI 实现所有接口。正确做法是：把接口列表逐个喂给 AI，每次只实现一个，实现完立即做契约检查（能否编译、是否满足前置后置条件），通过后再进行下一个。

为什么？因为接口之间可能存在隐含依赖。一次性实现全部，AI 可能为了"让代码跑通"而擅自修改某个接口的签名，破坏契约。逐个实现时，你可以在每次产出后检查"签名有没有被改动"，一旦改动立即纠正。

5.2 实现阶段的提示结构

给 AI 的实现提示，建议包含以下要素，缺一不可：

【任务】实现 TaskAssignmentService 接口
【约束】
  - 不得修改接口签名
  - 使用项目既有的 Result<T> 包装返回值
  - 异常统一抛 BusinessException，错误码见 ErrorCode 枚举
  - 并发控制使用 Redis 分布式锁，key 格式 task:lock:{taskId}
【上下文】
  - 相关类：TaskRepository, UserRepository, AuditService, NotifyService
  - 数据模型：Task 含 status 字段，枚举 TaskStatus
【输出要求】
  - 只输出实现类代码，不输出解释
  - 每个 public 方法上方写一行注释说明满足哪条契约

本文评述：注意"不得修改接口签名"这条约束。AI 有强烈的"让代码自洽"倾向，当它发现接口设计不合理时，会倾向于偷偷改掉。显式禁止，能有效抑制这种行为。如果确实需要改接口，应该回到第一阶段，而不是在实现阶段偷偷改。

5.3 处理 AI 的"过度实现"

实践中常见另一个问题：AI 会实现接口里没要求的方法，或者加入大量"防御性代码"。比如接口只要求 assign，它顺手实现了 reassign、unassign，还加了缓存、重试、熔断。

这些代码未必错，但会带来两个问题：一是增加审查负担，二是可能引入未经验证的依赖。处理方式是在提示中明确"只实现接口声明的方法，不添加额外 public 方法"。如果 AI 确实发现了值得补充的能力，让它单独列出来，由你决定是否纳入下一轮接口设计。

5.4 实现阶段的验证手段

实现完成后，在写正式测试之前，可以先做几项低成本验证：

• 编译验证：确保实现类能编译，且没有改动接口。
• 签名比对：用 diff 工具对比实现前后的接口文件，确认零改动。
• 静态检查：跑一遍项目的 lint 规则，捕获明显的坏味道。
• 依赖检查：确认实现类只依赖契约中声明的组件，没有引入意外依赖。

六、第三阶段：写测试——用可执行断言锁定行为

测试阶段是整条主线的"兜底"。接口和实现都可能出错，但测试一旦通过，至少说明行为符合预期。这里的测试不只是"补作业"，而是人与 AI 之间的可执行合同。

6.1 测试的三个层次

针对 AI 生成的实现，测试应覆盖三个层次，优先级从高到低：

层次	验证内容	示例
契约测试	前置/后置条件是否满足	传入空 taskId 应抛异常
行为测试	正常路径结果是否正确	分配后任务负责人变更
边界测试	极端输入、并发、异常	同一任务并发分配只成功一次

6.2 让 AI 写测试的正确方式

让 AI 写测试，有一个陷阱：它会写出"迎合实现"的测试，而不是"检验契约"的测试。比如实现里有个 bug，AI 的测试可能刚好绕过了这个 bug。

规避方法是：给 AI 的测试提示里，只给契约，不给实现。让它基于契约推导测试用例，而不是基于实现反推。这样测试才能真正起到"独立验证"的作用。

【任务】为 TaskAssignmentService 编写单元测试
【输入】仅提供接口契约（前置/后置/异常/并发说明），不提供实现代码
【要求】
  - 使用 JUnit 5 + Mockito
  - 覆盖：正常分配、任务不存在、用户不在租户内、非法状态流转、并发分配
  - 每个测试方法名用 should_xxx_when_yyy 格式
  - 断言要具体，避免 assertNotNull 这类弱断言
【输出】测试类代码

6.3 变异测试：检验测试本身的质量

测试写完就够了吗？不一定。测试可能覆盖率很高，但断言很弱，抓不住 bug。这时可以引入变异测试（Mutation Testing）：工具自动修改实现代码（如把 > 改成 >=），看测试是否能捕获。捕获率越高，测试质量越好。

常用工具：Java 的 PIT（Pitest）、JavaScript 的 Stryker、Python 的 mutmut。2023—2024 年有多篇研究探讨用 LLM 辅助生成变异体或评估测试质量，例如关于 LLM 用于测试预言（test oracle）生成的工作。本文评述：变异测试与 AI 协作是天然搭配——AI 快速生成测试，变异测试快速评估测试质量，形成闭环。

6.4 测试阶段的常见坑

• 过度 mock：把被测逻辑也 mock 掉了，测试变成"验证 mock 调用次数"，没有真实价值。
• 弱断言：只断言不抛异常，不断言结果内容。
• 依赖外部状态：测试依赖数据库、网络，导致不可重复。
• 忽略并发测试：契约里写了并发要求，测试却没覆盖。

七、工具链与提示模板：把方法固化为流程

方法要落地，必须变成可复用的流程和模板。这一节给出具体的工具选型与提示模板。

7.1 工具链推荐

环节	工具	用途
接口设计	OpenAPI / Protobuf / 语言原生 interface	定义契约
AI 协作	GitHub Copilot / Cursor / Claude Code / 通义灵码	生成与补全
契约检查	ArchUnit / dependency-cruiser	验证依赖方向
测试	JUnit / pytest / Jest	行为验证
变异测试	PIT / Stryker / mutmut	评估测试质量

关于 Copilot 的工程化使用，可参考 GitHub 官方文档 GitHub Copilot Docs；关于 Cursor 的规则文件用法，见 Cursor Rules。视频教程方面，可参考 freeCodeCamp 的 TDD 入门 与 契约测试 讲解。

7.2 三段式提示模板

把三个阶段的提示固化成模板，每次直接套用，能显著降低沟通成本。

模板 A · 接口设计：

需求：{一句话描述}
请输出：
1. 领域实体清单（含字段与类型）
2. 行为接口清单（含方法签名）
3. 每个方法的契约（前置/后置/异常/并发）
4. 模块依赖图（文字描述方向）
约束：不得引入需求未提及的实体；接口粒度以"一个方法只做一件事"为准。

模板 B · 类实现：

接口：{粘贴接口代码}
上下文类：{列出可用的依赖类}
约束：
  - 不得修改接口签名
  - 只实现接口声明的方法
  - 异常类型：{指定}
  - 并发策略：{指定}
输出：仅实现类代码，每个 public 方法上方注释对应契约条目。

模板 C · 测试生成：

契约：{粘贴契约，不含实现}
测试框架：{JUnit5 + Mockito / pytest / Jest}
覆盖要求：正常路径、边界、异常、并发
命名规范：should_xxx_when_yyy
输出：测试类代码，断言需具体。

八、度量与反模式：如何判断拆解是否有效

方法好不好，要用数据说话。这一节给出可操作的度量指标和需要警惕的反模式。

8.1 四个核心度量指标

指标	定义	健康区间（经验值）
首次通过率	AI 产出无需修改即通过检查的比例	接口阶段 >70%
契约漂移率	实现阶段接口被改动的比例	应接近 0
变异杀死率	变异测试中测试捕获变异的比例	>60% 较健康
返工轮次	单个模块从接口到测试通过的平均轮次	<3 轮

需要说明：上述区间为笔者基于团队实践的经验值（模拟数据，仅供参考），并非普适标准。不同语言、不同项目复杂度下会有差异，建议先建立自己的基线，再看趋势变化。

8.2 六种典型反模式

1. 大爆炸式生成：又把整个需求丢给 AI 了。回到第一步。
2. 契约形式化：接口写了，但只写签名不写约束，等于没写。
3. 实现阶段改接口：发现接口不合理就偷偷改，破坏了契约的稳定性。
4. 测试迎合实现：把实现代码也给 AI 写测试，测试变成实现的镜像。
5. 跳过验证：AI 说"已完成"就信了，不编译、不测试。
6. 过度拆分：把方法拆到只有一行，接口数量爆炸，维护成本反而上升。

本文评述：第六种反模式尤其值得警惕。拆分的目的是降低不确定性，不是追求"小"本身。如果一个接口的契约清晰、实现简单，就没必要再拆。判断标准是"能否独立验证"，而非"代码行数"。

九、前沿预判：从"人拆 AI 写"到"AI 自拆人验"

当前主流范式是"人拆解、AI 生成、人验证"。随着 Agent 技术发展，这个范式正在演化。

9.1 Agent 化的自动拆解

2024—2025 年，多个研究团队探索让 LLM Agent 自主完成"规划—分解—执行—验证"循环。例如关于软件工程 Agent 的综述（如 SWE-Agent、AutoCodeRover 相关工作）显示，Agent 能根据测试反馈自动定位并修复 bug。这类系统的核心机制，正是本文强调的"用测试作为反馈信号"。

本文评述：Agent 化并不意味着"人不用拆了"。恰恰相反，Agent 的拆解质量取决于它能否获得清晰的验证信号。如果项目本身没有契约、没有测试，Agent 的自动拆解也会迷失方向。所以本文方法的长期价值，是为未来的自动化协作"铺好轨道"。

9.2 形式化验证与 AI 的结合

另一个前沿方向是把形式化方法引入 AI 生成流程。例如用不变量（invariant）和断言（assertion）作为生成约束，或用 SMT 求解器验证生成代码是否满足规格。2023 年以来，已有研究尝试用 LLM 生成形式化规格，再用验证器检查实现。

本文评述：这条路理论优美，但工程落地门槛高。对大多数团队而言，先把"接口契约 + 单元测试"这套轻量级验证做扎实，收益远大于追求形式化。形式化是方向，但不是当下的起点。

9.3 一个可检验的预测

笔者认为，未来两到三年内，主流 IDE 的 AI 插件会内置"分步协作模式"：自动识别大需求，提示用户先确认接口，再逐段生成实现，最后自动补测试。这个预测基于当前的工程痛点和技术趋势，可被后续产品演进检验。

十、结语：把不确定性关进契约的笼子

回到开头那个场景。如果换一种做法：先花二十分钟和 AI 一起梳理实体、行为、契约，定稿接口；然后逐个接口实现，每次编译检查；最后基于契约写测试。整个过程可能多花一小时，但你会得到一套边界清晰、可测试、可维护的代码，而不是一堆需要推倒重来的半成品。

本文的核心主张可以浓缩成一句话：AI 编程的核心矛盾不是生成能力，而是验证成本；分步拆解的本质，是把验证成本从"事后调试"前移到"事前契约"。

接口是契约，实现是履约，测试是验收。三步走完，AI 的产出就从"不可信的黑盒"变成了"可验证的交付物"。这不是限制 AI 的能力，而是给它一条能走稳的路。