AI 辅助写代码时，把提示词拆小、把结果验真：一个可复用的工作流

AI 辅助写代码，真正省时间的不是一次生成多少行，而是能不能把任务讲清楚、把结果验明白。如果提示词含糊，生成结果往往也要反复返工；如果结果不校验，小问题会一路藏到联调和上线。下面是一个可以直接套用的工作流，核心只有两句话：提示词拆小，验收做实。

一、先写清目标，再开口让 AI 写代码

动手之前，先用一两句话回答四个问题：要解决什么问题、输入是什么、输出应该长什么样、哪些情况算失败。

例如，不要只说“帮我写一个解析函数”，而要说清楚：输入是一段文本还是一个文件，字段有哪些，异常输入怎么处理，返回类型是列表还是字典，失败时是抛异常还是返回空值。目标越具体，AI 猜测的空间就越小，后续修改的成本也越低。

二、把大任务拆成三类小任务

一个常见的拆法是：先定接口，再写核心逻辑，最后补测试和边界处理。

1. 接口层：函数名、参数、返回值、异常约定，先定下来不动。
2. 核心逻辑：只做一件事，例如解析、计算或转换，不要顺手把日志、缓存和校验全塞进同一个函数。
3. 校验层：正常输入、空输入、超长输入、非法格式，至少各准备一个用例。

每次只交给 AI 一个小任务，改动范围小，出了问题也容易定位。一次让 AI 改十几个文件，表面上很快，实际上 review 和回滚都会变难。

三、给提示词一个固定结构

可以按“背景、输入、输出、约束、验收”五段来写：

• 背景：这段代码用在什么场景，调用方是谁。
• 输入：数据类型、字段含义、是否可能为空。
• 输出：返回结构、排序规则、精度要求。
• 约束：不要引入新依赖，不要改动已有公开接口，遵循项目现有风格。
• 验收：给出两三个具体用例，包括一个边界用例。

固定结构的好处是：换任务时不用重新想措辞，团队成员之间也可以互相 review 提示词本身。提示词同样是工程资产，值得放进文档或注释里说明关键决策。

四、结果校验做四道关

拿到生成结果后，不要直接提交，至少过四道关：

1. 能跑吗：先运行，再看样式。能通过编译和现有测试是最基本的要求。
2. 边界对吗：空值、零值、最大值、重复数据、异常字符，这些地方最容易出错。
3. 改动范围合理吗：打开 diff 逐行看，只接受和本次任务有关的改动，不相关的“顺手优化”要单独处理。
4. 有没有引入新风险：是否出现硬编码密钥、明文密码、不安全的拼接、未做权限判断的接口。凡是涉及密钥和凭证的内容，一律不要贴进提示词。

如果某一步校验失败，不要直接说“再改改”，而要把失败用例和期望结果贴回去，让 AI 在明确的失败点上修正。

五、一个可直接套用的检查清单

提交代码之前，对照清单自查一次：

• 需求是否只做了一件事，有没有偷偷扩大范围。
• 正常用例和边界用例是否都跑过。
• diff 是否逐行看过，注释和命名是否说得清。
• 有没有新增依赖，有没有留下调试代码和临时文件。
• 如果别人接手这段代码，能不能只看函数签名和注释就理解用途。

把这个清单固定下来，AI 辅助的收益才会稳定：写得快不是目标，改得少、返工少才是。先把任务拆小，再把结果验真，代码质量才不会被生成速度掩盖。