6类代码场景分层：不同代码，不同 AI 打法

不是所有代码都适合让 AI 批量生成。按任务类型匹配 AI 协作策略，每类有具体执行步骤和提交前自查清单。

判断方法

接到一个开发任务，先问三个问题：

1. 这个代码要活多久？—— 一个 sprint 就扔，还是长期维护？
2. 出错了影响多大？—— 一个文件，还是整个系统？
3. 能不能自动验证对错？—— 测试能机器判断，还是必须人看？

六种策略总览

策略一：快速原型

什么时候用：不确定怎么做、需要先跑起来验证思路、代码不会进入生产。

特征：代码命短、无 Spec、不需要长期维护。

具体执行步骤：

1. 用自然语言描述目标。直接告诉 AI 要什么效果，不写 Spec。"帮我搭一个页面，左边是列表右边是详情，点列表项刷新右侧。"
2. 快速迭代。跑起来 → 看效果 → 不满意 → 告诉 AI 改哪里。一个对话窗口完成。
3. 扔掉或重写。原型验证完，要么扔掉，要么基于原型中跑通的逻辑写正式 Spec，用策略二或三重新实现。不要直接把原型代码合入主干。

提交前自查：

• 这个代码不会进入生产分支
• 关键交互路径跑通了
• 如果需要保留，已决定用哪份原型逻辑写正式 Spec

策略二：批量生成

什么时候用：模式成熟、有 Spec、可自动验证、爆炸半径小。

特征：代码是"标准化产出"，人定义输入，AI 执行，测试把关。

具体执行步骤：

1. 写 Spec。包含接口契约（路径、参数、返回值、错误码）和数据模型（字段、约束）。
2. 写 Prompt 时引用约束文件。把 Spec 内容和项目治理文件（AGENTS.md）中的技术栈约束和红线规则一并放入。
3. 让 AI 同时生成代码和测试。代码 + 测试一起产出，确保测试先行覆盖正常路径和至少一条异常路径。
4. 跑自动化验证。编译、Lint、测试全部通过后，人工抽检三个点：字段名和 Spec 一致吗？接口路径一致吗？异常处理有没有？

提交前自查：

• Spec 定义了接口契约和数据模型
• Prompt 包含了 Spec 内容和项目约束
• CI 全部通过（编译 + Lint + 测试）
• 人工抽查了字段名、接口路径、异常处理三项
• PR 不超过 300 行

策略三：人写骨架 + AI 填充

什么时候用：核心逻辑复杂、业务规则隐含、出错代价大。

特征：人决定代码走向，AI 在明确边界内补充细节。

具体执行步骤：

1. 人写骨架。不是空文件，是带关键逻辑的伪代码或接口定义：核心方法签名、关键分支的注释、状态转移条件。这决定了代码走向。
2. 用注释标记 AI 填充区。骨架里标记 // TODO: AI 填充 — 边界值处理，// AI 禁止修改 — 核心逻辑已确认。让 AI 知道哪里能动、哪里绝对不能碰。
3. 让 AI 补充边界内容。AI 擅长的事：补充异常分支、生成关联的辅助方法、补齐边缘值处理。
4. Review 只看一件事：AI 有没有越界。核心看骨架部分是否被 AI 改动了，AI 补充的边界处理有没有遗漏。

提交前自查：

• 核心逻辑的走向是人决定的
• 代码中标注了 AI 可修改和不可修改的区域
• 至少一个同事理解了核心逻辑
• AI 补充的部分有对应测试

策略四：诊断定位

什么时候用：出问题了、不知道为什么、需要定位根因。

特征：AI 是分析助手，不是代码生成器。核心是"帮我看问题在哪"，不是"帮我写代码修"。

具体执行步骤：

1. 给 AI 喂上下文。粘贴错误堆栈、相关日志、出问题的接口路径。加上出问题时的大致时间范围和影响范围。
2. 让 AI 提出假设。不直接让 AI 改代码，先让 AI 列出"可能是哪些原因"，给出排查优先级。
3. 人验证假设。按 AI 列出的优先级逐一排查——查数据库、看调用链、看最近的部署记录。每排除一个假设，反馈给 AI，让它修正推理。
4. 找到根因后，按实际类型选策略。根因是简单逻辑错误 → 策略二（写 Spec 让 AI 生成修复）；根因是核心逻辑问题 → 策略三（人写骨架 AI 补）；根因需要跨模块改动 → 策略六（审慎修改）。

提交前自查：

• 根因已定位并通过人验证（不是 AI 猜的）
• 修复方案已根据根因类型选择了对应策略
• 修复代码附带了测试，覆盖了本次触发场景
• 如果是线上事故，已确认影响范围并通知受影响方

策略五：安全重构

什么时候用：改结构不改行为、消除技术债、提升可读性。

特征：有测试兜底，目标是"改完之后行为完全不变"。比策略六轻——不需要影响面分析，因为行为不改变。

具体执行步骤：

1. 确认有测试安全网。如果现有代码没有测试，先让 AI 生成特征测试（只测当前实际行为，不管对不对）。跑一遍确认全部通过。
2. 小步改，每步跑测试。改一个点 → 跑全部测试 → 通过 → 提交。每次改动控制在 30 行以内。任何一个测试失败，立刻回滚到上一个提交点。
3. 不改行为。不管代码当前的逻辑对不对，重构阶段只改结构。发现了 Bug 需要修？记下来，重构完后用策略二或六单独修。
4. AI 做机械重复，人做判断。比如"把这个文件里所有 getXxx()改成 xxx()"——AI 执行，人确认。但"这个类拆不拆、往哪拆"——人判断。

提交前自查：

• 改动前测试全部通过
• 改动后测试全部通过
• 每次改动不超过 30 行，且独立提交
• 没有同时修 Bug（Bug 修复另开 PR）
• 知道回到哪个 commit 可以完整回滚

策略六：审慎修改

什么时候用：爆炸半径不确定、改动可能牵动多处、回滚成本高。

特征：先搞清楚"动了这会影响到什么"，再小步改、步步验证。

具体执行步骤：

1. 影响面分析。用 IDE 的 Find Usages 找出所有依赖方。导出调用链列表，按影响级别分类（核心路径/非核心路径/无影响）。公共模块改动这一步不能跳。
2. 建立安全网。改动前先补特征测试。运行现有测试套件，确认全部通过。如果是热修复，先基于当前生产版本创建分支。
3. 小范围改，立即验证。改一个点 → 跑全部测试 → 通过 → 提交。每次改动控制在 50 行以内。出问题立刻回到上一个提交点。
4. 从底层改起。涉及多个文件的，按依赖顺序从最底层开始。每改完一层跑一次全量测试。全量通过再改下一层。
5. 通知依赖方。公共模块改动，在改动前通知所有调用方。改动后确认调用方的自动化测试也通过。自己跑过不代表别人也 OK。

提交前自查：

• 影响面分析已完成，所有依赖方已确认或通知
• 改动前测试套件全部通过
• 每次改动不超过 50 行，且独立提交
• 涉及公共模块的，调用方测试也已确认通过
• 回滚方案可用（知道回到哪个 commit）

快速判断表