Vide coding 的一些经验分享
发布时间：
目录
我是怎么理解大模型的？
现在基本可以说，绝大多数程序员都已经在用 AI 写代码了。 不管是 Copilot、Codex 还是别的工具，大家多少都试过。
而且使用路径几乎一模一样。
一开始，大家都会让 AI 去写一个最基础的函数、实现一段简单逻辑。 然后发现：哇，amazing。
接着，胆子大一点的同学就开始上强度了： 让它写一大段业务逻辑、帮忙重构代码、甚至改老系统。
然后—— 翻车了。
这时候评论区就会开始出现那句话：
“AI 也不过如此。”
但说实话，我一直觉得这里面有点误会。 不是 AI 突然不行了，而是我们一开始对它的理解就不太对。
如果一定要打个比方的话，我更愿意把大模型当成：
一个有专业技能，但理解能力偏弱的小孩
它会写代码， 会用设计模式， 会看 API 文档， 但它并不真的“懂”你的业务场景。
- 所以你给它的信息越少，它就越容易开始“瞎扯”； 你给它的上下文越完整，它反而越专业。
- 很多人觉得 AI 不好用，本质上是因为： 我们对它的期望，已经超过了我们给它的输入质量。
我平时是怎么用 Codex 的？
我现在基本不会把 AI 当成一个“随叫随写代码的工具”， 而是更像在玩一种角色扮演。
简单说就是：
- 我来当 Spec
- AI 当 Designer + Coder
第一阶段：先别急着写代码
不管是新项目，还是一个相对完整的需求，我第一步做的事情都很简单：
- 👉 把背景说清楚，而且越细越好
包括但不限于：
- 为什么要做这件事
- 业务边界在哪
- 已知的限制条件
- 参考资料、已有实现、历史决策
这个阶段，我希望 AI 输出的不是代码， 而是一份设计文档，里面至少要有：
- 模块怎么拆
- 模块之间怎么交互
- 哪些地方可能要改现有逻辑
- 哪些点是风险点
而且这个过程一定不是一轮就结束的。 大模型的思考方式和人不一样， 所以第一轮 review 非常重要，你得主动去纠偏。
从设计到代码：一定要分阶段
设计稳定之后，才进入写代码阶段。
这一步我反而不会追求“一次写完”，而是：
- 根据 design 生成类图
- 按模块、按步骤实现
- 每一部分都可以单独验证
一个很关键的点是： 第一步生成的 design 信息一定要保留住。
然后让 AI 做一件事：
帮我规划这个需求的实现步骤
比如：
- 哪一部分先做
- 哪一部分依赖前置结果
- 哪些地方要写 UT / SCT / MT
不同公司有不同的编译命令、测试方式， 这些东西理论上都可以直接告诉 AI。
这个阶段，你真正需要做的事情其实只有一件： review 逻辑。
因为这时候的代码，本质上还是初稿阶段， 目标只是：基本功能正确。
真正拉开差距的，其实是 Code Review
代码能跑，并不代表可以放心交付。
在 Code Review 这一关，我基本不会让 AI“自由发挥”， 而是一定会给它一个模板。
不管你叫它：
- Clean Code checklist
- Review rules
- 公司内部 coding 规范
本质都是一样的： 👉 把主观感觉，变成明确的检查项
我会直接让 AI：
- 对照规则逐条检查
- 标明代码位置
- 说明为什么是问题
- 区分「必须改 / 可选优化」
但有一句话我会说得非常明确：
AI 干活，人永远是最后的守门员。
AI 更像是一个“筛子”， 帮你把问题暴露出来， 但最终哪些要改、改到什么程度，一定是人来决定。
最后一关：DFMEA
等代码写完、测完、review 完， 如果是偏业务、偏生产的系统，我还会加一层：DFMEA。
这一轮关注点已经不太一样了。
前面的 review 更多是：
- 代码结构
- 逻辑正确性
- 设计合理性
而 DFMEA 看的是：
- 在业务视角下，有没有“不常见但致命”的场景
很多公司都会有一份 DFMEA checklist， 里面的东西往往都非常业务强相关，而且：
- 不是 common sense
- 基本都是“以前踩过坑”
这时候 AI 反而特别适合干这件事：
- design
- 当前代码
- DFMEA checklist
三样一起给它， 让它从业务风险角度做最后一次扫描。
当然，这一轮依然一样： AI 不是裁判，人还是最后拍板的人。
一个我挺期待的远景
最后说点偏未来的想法。
现在很多项目里，其实已经有：
- docs/ 目录
- 模块说明
- 业务背景介绍
如果这些东西是认真维护的，那以后其实可以这样用 AI：
新需求来了，直接告诉 AI：
- 现有模块是什么
- 业务背景是什么
- 需要改哪些地方
改完之后，再让 AI：
- 更新文档
- 标记版本变化
- 记录设计演进原因
到那一步，AI 就不只是“写代码的工具”， 而是一个理解你代码和业务历史的参与者。
写在最后
我一直觉得：
- AI Coding 难用 很多时候不是 AI 不行
- 而是我们还在用“写脚本”的方式 去要求它完成“工程系统”的事情
如果你愿意：
- 把上下文给够
- 把规则说清
- 把校验前移
- 把人放在最后一关
那 AI，至少在 coding 这件事上， 已经比很多人想象得更稳，也更可控了。