我见过两次事故，都和 AI 有关，但都不是 AI 的错。
第一次：它为了让一条集成测试通过，把幂等校验删了。测试绿了，上线两周后重复扣款。第二次：有人把客户的真实数据库结构贴进对话框，问它怎么优化索引——问题解决了，数据也出去了。
两次的根因是同一件事：用了 AI，但没有配套的规矩。工具给了你十倍的手速，你却还在用一倍的谨慎。这篇给三样能直接抄走的东西：任务书怎么写、产出怎么验、红线在哪。
一、任务书：把需求写成一份工程单
AI 不是读不懂人话，是读不懂你没说出口的东西。它不知道你的约束、不敢猜你的边界、也不清楚哪些地方能动。你抱怨「它理解错了」，多数时候是你没说。
七要素
| 要素 | 解决什么问题 | 不写的后果 |
|---|---|---|
| 目标 | 到底要什么 | 它自己发挥，方向跑偏 |
| 现有架构 | 复用什么、别重复造 | 新建一堆你已有的东西 |
| 约束 | 不能引入什么、必须用什么 | 随手加依赖，版本对不上 |
| 安全要求 | 哪些校验必须保留 | 为了跑通测试把校验删了 |
| 范围边界 | 哪些文件、哪些模块不碰 | 顺手改了不该改的地方 |
| 验收标准 | 怎样算做完 | 它自己定义「做完了」 |
| 审批点 | 什么时候停下来等你 | 一路改到底，攒出三千行 diff |
可以直接抄的模板
目标：一句话说清要什么。
现状：现在是怎么做的，相关代码在哪。
约束：
- 复用现有的 XX，不要新建
- 不要引入新依赖（或：只允许引入 XX）
- 保持对外接口行为不变
安全要求：
- 必须保留 XX 校验
- 涉及权限的地方要走 XX 工具类
范围：
- 只改这几个文件 / 只改这个模块
- 不要动 XX（原因：正在下线 / 有其他人在改）
验收：
- 补上这三种情况的测试：A、B、C
- 全量测试必须通过
- 提交前跑一遍 XX 命令
流程：
- 先读仓库，给我方案，我确认后再动手
- 在我确认之前，不要修改数据库结构这不是什么「提示词技巧」，这就是一份合格的工程任务单。你写给新同事也会这么写，只是平时对 AI 偷懒了——因为它看起来什么都知道。
二、评审清单：重点看减号行
新手最容易浪费时间的地方，是逐行读 AI 生成的代码。三千行 diff 你读不完，也不该读。按这个顺序来，十分钟能过一遍：
- 先看改动文件清单。范围不对，直接打回重做，不用往下看。
- 过滤 diff 里的删除行。这是重中之重：被删掉的校验、被注释掉的分支、被放宽的异常捕获、被改成 TODO 的失败处理。为了跑通测试而删掉挡路的东西，是 agent 的经典动作。
- 查新增依赖是否真实存在。模型编造包名和函数名是常态。编译不过还算走运，怕的是真有个同名包但完全不是你要的东西。
- 看边界条件。空值、超时、并发、重复请求、部分失败——它默认写 happy path。
- 检查事务与幂等。这两处它改错的概率高，后果又严重。
- 看它有没有破坏分层。为了省事把业务逻辑塞进 Controller，是最常见的「架构不合身」。
- 测试用例是谁定的。让 AI 写测试再自己跑通，等于让学生自己出题自己判分。测试用例必须由你定。
- 跑一遍全量测试，而不是只跑它改的那几个。
- 问自己一个问题：半年后我愿意维护这段代码吗？
三、怎么看出它在胡说
三种典型症状：
- 编造依赖和 API。给出一个不存在的包名、一个从没有过的重载。查证方式很简单：让它给出官方文档链接，或者你直接
grep一遍仓库和依赖树。 - 用过时的写法。它学到的知识有截止点，而你的项目用的是新版本。凡是涉及框架版本的建议，都要对着你实际的依赖版本核一遍。
- 自信的错误。这是最麻烦的——它不会说「我不确定」，而是用非常笃定的语气给出一个错的结论。凡是它给出的、你没法立刻验证的事实性结论（配置项含义、参数默认值、某个行为的表现），一律当成待验证假设。
一个实用的习惯：让它在回答里带上依据——「这个结论来自哪份文档 / 哪段代码 / 哪次命令输出」。给不出依据的，多半是编的。这个要求比反复追问「你确定吗」有用得多，因为它不会因为你问三遍就改口。
四、四条安全红线
红线一：密钥和凭据，绝不进对话
API Key、数据库密码、私钥、token、内部地址——一律不进对话框、不进上下文、不截图粘贴。真需要它连数据库，给一套脱敏的结构和假数据。
红线二：真实数据先脱敏
生产环境的数据结构、客户的核心报表逻辑、含个人信息的内容，进 AI 之前必须过一道人肉脱敏。这一步一开始觉得麻烦，时间长了能省掉无数沟通成本和后悔。
红线三：客户项目用团队批准的工具
不要自己在客户项目上装没经过评估的插件。涉及代码出境的，优先选支持私有化部署、或明确承诺数据不用于训练的方案。这不是技术问题，是合同问题。
红线四：产出的许可证要看一眼
AI 生成的代码可能和训练数据里的片段高度相似。对商业交付项目，尤其是要交付源码的，许可证风险要提前和客户说清楚——这在软著登记和验收环节都可能被问到。
五、团队里的三条规矩
个人怎么方便怎么来，团队必须有硬规矩。建议最少定这三条：
- 敏感内容进 AI 之前必须人肉脱敏，工具可以各用各的，这条不能有例外。
- AI 产出的代码必须有人工评审才能合并，评审重点按上面的清单走，不是扫一眼就过。
- 每个仓库维护一份项目说明文件，约定、命令、以及「不要碰」的清单写进去，随项目演进更新。
最后一句：AI 让你的手变快了十倍，你的谨慎也必须跟上十倍，否则省下来的时间会以另一种方式还回去。这两次事故，都是十几秒的操作，加上几周的收拾。
备忘
- 事故根因通常是「用了 AI 但没配套规矩」，不是 AI 本身。
- 任务书七要素：目标、现有架构、约束、安全要求、范围边界、验收标准、审批点。
- 范围边界和审批点最容易被省，也最容易出事。
- 评审顺序：改动清单 → 删除行 → 新增依赖真实性 → 边界条件 → 事务与幂等 → 分层 → 谁定的测试 → 全量测试 → 半年后愿不愿意维护。
- 删除行是重灾区：被删的校验、被注释的分支、被放宽的异常捕获、改成 TODO 的失败处理。
- 测试用例必须由你定，不能让它自己出题自己判分。
- 识别胡说：编造依赖、过时写法、自信的错误。让它给出依据，给不出多半是编的；别靠反复追问「你确定吗」。
- 四条红线：密钥不进对话、真实数据先脱敏、客户项目只用批准的工具、产出许可证要看。
- 团队三条规矩：敏感内容人肉脱敏、AI 产出必须人工评审、每仓维护项目说明文件。
一起聊聊