为什么值得单独写
这篇文章讨论的是 AI 在真实工程流程里的用法。重点不是把提示词写得玄乎，而是让它在需求、编码、测试、排障这些环节里产生可验证的结果。
AI 很适合补充边界用例，但它也容易测试实现细节。要让它围绕业务规则和失败路径写测试。
把目标、上下文、限制和验收方式写清楚。 这类经验有一个共同点：不要只追求“能跑”，还要能解释为什么这么做、边界在哪里、后续谁来维护。
判断标准
一个 AI 工作流是否靠谱，不能只看回答是否顺眼，而要看它能不能稳定地产出可复核材料。好的流程会留下上下文、约束、决策理由和验证结果；差的流程通常只有一段看似完整的答案，出了问题没人知道从哪里回退。
项目里的例子
比如让 AI 生成一个功能实现时，不要只给一句“帮我做搜索”。更好的输入是：当前页面路径、数据结构、已有筛选逻辑、不能改动的文件、希望保留的交互，以及验收命令。这样它输出的内容更像一个可执行补丁，而不是一份泛泛建议。
落地步骤
- 先准备上下文材料，不要让 AI 猜项目现状。
- 明确输出格式，让结果能直接进入评审或执行。
- 要求它列风险和验证命令，避免只给结论。
- 把产出放回本地环境或团队流程里复核。
参考片段
请按成功、空值、权限不足、网络失败四类补测试，不要 mock 业务规则本身。容易忽略的细节
- 把 AI 的解释当成事实，没有验证。
- 一次让它改太多文件，导致复核成本失控。
- 输入信息里混入敏感数据或未脱敏日志。
验收方式
- 能用一句话说清楚它解决的具体问题。
- 有可执行的验证命令、页面路径或检查清单。
- 对失败、空数据和边界输入有明确处理。
- 后续维护者不用读完整上下文也能接着改。
技术方案的价值不在于看起来高级，而在于下一次遇到相似问题时，团队能更快、更稳地复用它。