「AI 辅助测试编写流程」这种开发任务，AI 很容易显得很能干。它能马上给代码，甚至解释得头头是道。但真正让我放心的，从来不是回答，而是后面的 diff 和测试。
我会让 GitHub Copilot、ChatGPT、Claude 各站一段：先读现有代码，再补局部实现，再看风险。「辅助测试编写」不能只靠一段生成结果，项目里的命名、测试和旧约定都要进来。
这话听起来有点扫兴。但「AI 辅助测试编写流程」如果一开始不扫兴，后面通常会很累。
先读仓库脾气
做「AI 辅助测试编写流程」之前，我会先找三处相似实现。这个动作有点慢，但能让 AI 少写那种“看起来正确、风格完全不贴项目”的代码。
我会先把「辅助测试编写」的成功标准写得窄一点。不是“做得更好”，而是让谁更快判断、让哪一步少返工、让哪份材料能继续被用。
把不能碰的地方写清楚
材料不用多，但要真实。围绕「辅助测试编写」，我会把已有素材、不能编的事实、还没确认的地方放在一起。AI 看到的东西越具体，它越不容易装得很懂。
提示词我会写得很像工单：背景、材料、限制、输出给谁、哪些地方必须标成不确定。写「辅助测试编写」时，这种笨办法比“请你专业地分析”更耐用。
我会顺手给 AI 一个很短的用例清单，让它别只补顺风局：
{
"cases": [
{ "name": "正常输入", "expect": "返回结果" },
{ "name": "空值边界", "expect": "给出提示" },
{ "name": "重复提交", "expect": "保持幂等" }
]
}
助手不要包办
我会把「辅助测试编写」里的工具分得很窄。不是为了显得流程专业，是为了出问题时知道该改哪一段。GitHub Copilot 适合贴着编辑器补函数、样板代码和测试片段。它适合小步补，不适合替你定方案。ChatGPT 我会放在拆需求、列验收、解释错误日志的位置。它适合把模糊问题先拆成几条可检查的线。Claude 更适合读长上下文、审查方案和整理迁移风险。它不是来替你点“通过”的，是帮你把遗漏摊出来。这样看起来慢一点，可交接时会少很多含糊话。
我不太相信一次就能把「辅助测试编写」设计完整。先让工具做中间版本，人来删、改、确认，再把有效部分留下。
测试是最后一句话
复核「辅助测试编写」时，我不会只看它顺不顺。我要看 diff、测试、命名、复用和无关文件改动。有一项说不清，就先别把它当成完成。
还有个容易忽略的小坑：别在文章里写死 GitHub Copilot、ChatGPT、Claude 的实时价格、套餐额度或地区可用性。这些东西变得太快。写清它们在「辅助测试编写」里的位置，就够了。
可以先拿「辅助测试编写」里的一个小改动试。限制文件范围，写清验收命令，改完马上跑测试。它如果连小 diff 都解释不清，就别让它继续扩大范围。
我还会在 辅助测试编写 旁边写一行：别让 AI 帮你省掉读代码的时间。它可以少写样板，可以提醒遗漏，但项目里的旧约定、测试习惯和命名方式，还是要自己看一遍。看过之后再让它动手，结果会稳很多。
跑完以后，我只记三件事：哪里真的省了时间，哪里让人更糊涂，哪里必须早点交给人判断。「辅助测试编写」能留下这些记录，就已经不是一次性生成了。
