AI编程思考2
AI 编程越用到后面，越会发现真正的瓶颈通常不是“模型够不够强”，而是两个更基础的问题：
- 你能不能把问题描述清楚。
- 你能不能把结果验收清楚。
如果这两个问题没解决，模型越强，往往只是越快地产生更多看起来正确、实际上不可用的代码。反过来，只要描述足够清晰、验收足够具体，即使不是最强模型，也能稳定产出可用结果。
1. 如何清楚地描述问题
很多人说自己“不会写 prompt”，本质上往往不是不会写提示词，而是没有把任务定义清楚。对 AI 来说，模糊的问题只会得到模糊的实现。
1.1 先说目标，不要先说方案
一个常见误区是，一上来就告诉 AI “你帮我这样改、那样改”。但如果方案本身就不成熟，AI 只会忠实地执行错误方案。
更好的方式是先描述：
- 背景是什么。
- 目标是什么。
- 现在遇到的具体问题是什么。
- 哪些东西不能改。
比如不要说：
“帮我把这个接口改成异步的。”
而可以说：
“这个接口现在平均耗时 4 秒，主要卡在第三方调用。目标是把用户请求响应时间降到 500ms 内，但不能影响最终一致性，也不能修改现有 API 返回结构。”
前者是在给实现指令，后者是在定义问题。对于复杂任务，定义问题比指定实现更重要。
1.2 给足上下文，但只给相关上下文
AI 不是天然懂你的项目，它需要上下文才能做对事。但上下文也不是越多越好，太多无关信息反而会污染判断。
我一般会把上下文拆成四类：
- 业务上下文：这段代码在整个系统里负责什么。
- 技术上下文：使用什么语言、框架、目录约定。
- 局部上下文：相关文件、函数、接口、报错信息。
- 约束上下文：哪些地方不能动，兼容性要求是什么。
经验是：给 AI 看“完成任务所必需的最小上下文”。如果任务只是修一个 handler，就不要把整个仓库历史、无关日志、几十个文件一股脑塞进去。
1.3 把“做好”翻译成可执行标准
“帮我优化一下”“帮我重构得更优雅”“帮我提高代码质量”这类话，人都很难理解一致，AI 更不可能理解一致。
要把抽象目标翻译成具体标准，例如：
- 重构后 API 行为不变。
- 保持数据库 schema 不变。
- 新增单元测试覆盖正常路径和异常路径。
go test ./...必须通过。- 时间复杂度从 O(n²) 降到 O(n)。
一句话：少用形容词，多用可验证条件。
1.4 给示例，往往比解释十句话更有效
示例是非常高效的沟通方式。你给一个输入输出示例，AI 往往立刻就知道你要什么。
适合给示例的场景包括：
- 返回 JSON 的结构。
- SQL 或 DSL 的写法。
- 新代码需要遵循的风格。
- 单测应该覆盖的用例。
尤其在“按现有风格扩展”这个场景里，一个参考实现胜过大量抽象描述。
1.5 先让 AI 复述，再开始写代码
对于稍复杂的任务，我很少第一句就让 AI 直接写。我更常用的流程是：
- 先描述目标与约束。
- 让 AI 复述它的理解。
- 让 AI 给出实现计划。
- 我确认方向后，再让它开始改。
这样做的价值很大：如果 AI 理解偏了，最好在写代码前就发现，而不是等它改了十几个文件之后再返工。
2. 如何验收 AI 代码
AI 编程最大的风险，不是它不会写代码，而是它会写出“看起来像对的代码”。因此，验收能力比生成能力更重要。
2.1 不要用“看起来不错”验收代码
AI 写出来的代码通常可读性不差，结构甚至比很多人手写的还整齐。但“整齐”不等于“正确”。
验收时至少要看三层：
- 功能是否满足最初目标。
- 约束是否被遵守。
- 改动范围是否失控。
也就是说，不能只看代码本身，还要对照最初定义的 Done 条件来检查。
2.2 把验收尽量工程化
最稳定的验收方式，不是人工盯着聊天记录，而是把验收标准外化成工程信号：
- 单元测试。
- 集成测试。
- lint。
- type check。
- e2e / smoke test。
- benchmark。
只要这些检查可以自动执行，AI 就有机会形成“修改 → 运行验证 → 继续修正”的闭环。没有这些信号，AI 只能靠猜。
所以一个很现实的结论是：不是 AI 需要测试，而是用了 AI 之后，你更需要测试。
2.3 用 spec 约束“做什么”，用 CI 验证“做成没有”
我越来越倾向于把 AI 编程拆成两个层次：
- 用 spec 定义需求、边界、验收标准。
- 用 CI / test 验证实现是否满足 spec。
spec 解决的是“我们到底要什么”，CI 解决的是“这次提交是否达标”。
两者缺一不可。只有 spec 没有自动验证，容易停留在文档层；只有 CI 没有清晰 spec，测试通过也可能只是测了错误目标。
2.4 把 AI 当同事审，而不是当工具信
一个很有用的心态是：把 AI 的产出当成同事提的 PR。
这意味着你要重点检查：
- 有没有误解业务。
- 有没有偷偷引入额外抽象。
- 有没有改到不该改的文件。
- 有没有把异常路径、边界条件漏掉。
- 有没有为了“通过测试”写出投机实现。
AI 的代码可以很快，但 review 不能省。
2.5 最终验收要落到真实场景
测试和 CI 很重要，但最后仍然要回到真实使用场景。尤其是以下类型的问题，光靠静态检查很难发现：
- 页面交互是否顺手。
- 接口联调时序是否正确。
- 日志、监控、报错信息是否足够可运维。
- 性能在真实数据量下是否达标。
所以我会把验收分成两层：
- 第一层是自动化验收，让机器快速兜底。
- 第二层是场景化验收，让人确认结果真的可用。
3. 一套实用工作流
如果让我把 AI 编程总结成一句操作建议，那就是：
先把问题写清楚，再把验收写清楚，最后才让 AI 动手。
一个简单但很好用的模板是：
- 背景：现在是什么情况。
- 目标：要解决什么问题。
- 约束：哪些行为、接口、文件不能变。
- 验收：什么条件下算完成。
- 示例：给 1 到 2 个输入输出或参考实现。
- 执行：让 AI 先出 plan，再改代码。
- 验证：跑 test、lint、CI，再做人工 review。
这个流程听起来朴素，但它本质上是在把 AI 编程从“碰运气”变成“工程化协作”。
4. 小结
AI 编程真正稀缺的，不是“生成代码”的能力，而是两种更高阶的能力：
- 把问题描述清楚的能力。
- 把结果验收清楚的能力。
前者决定 AI 会不会朝着正确方向努力，后者决定你能不能把 AI 产出安全地合进工程。
所以与其持续研究“怎么写神奇 prompt”，不如优先训练两件事：
- 用清晰语言定义任务。
- 用工程化方式定义验收标准。
当这两件事做扎实之后，AI 才会真正从“写代码的玩具”变成“能进入生产流程的工程助手”。