企业官网建设流程全解析

AI 写代码能提速，但不能替开发者承担理解、测试、审查和生产责任。
原文链接：AI 小老六

不能理解的代码，不该提交

AI 写代码最快的地方，也是最危险的地方：它能在你还没想清楚边界条件之前，先给出一大段看起来完整的实现。

变量名像真的，结构像真的，注释也像真的。运行一下，可能还能过几个简单用例。

问题通常藏在下一层：异常路径、状态同步、权限边界、并发时序、历史数据兼容、框架版本差异。等这些问题冒出来，最初省下的十几分钟会被一点点收回去。

工程师最后还是要面对那个老问题：

这段代码为什么能工作？

如果答不上来，就不该合进去。

图：AI 生成代码进入主干前，仍需要人类理解与审查。

库函数和 AI 生成代码不是一类东西

开发者每天都在信任抽象。

调用排序函数时，不会去读排序算法的每一行实现；使用数据库驱动时，也不会每次检查网络协议细节。现代软件工程正是建立在这种信任之上。

但这种信任不是凭空来的。

一个成熟库通常有维护者、版本历史、测试套件、真实用户、issue 记录和发布流程。它出过错，也修过错。它的边界被很多人踩过，文档里往往写着哪些情况能用、哪些情况别用。

LLM 生成代码没有这些沉淀。它更像是一个临时写出的候选补丁。

也许质量很好，也许刚好错在最不容易发现的地方。它没有被生产流量锤过，没有被不同环境折腾过，也没有天然继承某个库的信誉。

把 LLM 输出当成熟抽象来信任，是类别错误。

图：成熟抽象来自长期验证，生成式代码只是候选补丁。

速度收益会被理解成本吃掉

AI 编程效率常被包装成“十倍提升”。实际体验经常更复杂。

它能很快生成第一版，这没问题。真正花时间的是后面的确认：

如果这些工作本来就要做，AI 省下的只是打字时间。

而打字在软件开发里，从来不是最贵的部分。

更麻烦的是，AI 生成的代码会制造一种错觉：东西已经完成了。人脑看到完整结构后，很容易降低警惕。

审查一段“看起来能跑”的陌生代码，比从头写一段自己理解的代码更累，因为你要先拆掉它营造出来的确定感。

最差的情况是让 AI 修 AI

当生成的代码出错时，很多人会做一个自然动作：把错误再丢给模型，让它修。

有时它能修好。有时它只是换一种方式错。

于是问题从一个变成两个：原来的 bug 还没完全理解，新的补丁又引入了新的假设。

这不是模型不能用，而是工作流有问题。让同一个不稳定来源不断修改自己生成的结果，很容易把调试变成猜谜。

每一轮输出都增加了表面积，却不一定增加理解。

更稳的做法是把LLM 编程工具当成辅助工具，而不是责任主体。

它可以提出思路，可以生成测试草稿，可以解释报错，可以列出可能原因，可以帮你写机械重复的样板代码。

但最终补丁必须回到人的理解里：

• 为什么这样改
• 覆盖了哪些路径
• 没覆盖哪些路径
• 失败时会怎样

AI 代码进入生产前，需要过人类的门

团队使用 AI 编程，最好先把规则说清楚。

1. 1. ​生成代码和手写代码一样接受审查​。不能因为它来自工具，就跳过设计讨论、测试和 code review。
2. 2. ​提交者必须能解释每个关键分支​。解释不了，就继续读，或者删掉重写。
3. 3. ​AI 更适合低风险、高约束的任务​。比如迁移格式、补测试、改 API 调用、生成样板、写脚本。
4. 4. ​测试要比以前更重要​。AI 生成代码最大的麻烦不是一定会错，而是错得很像对。

高风险核心逻辑可以用 AI 辅助分析，但不要把最终判断交出去。

没有测试，审查者只能靠阅读和直觉；有测试，至少能把一部分信任落到可重复的证据上。

图：AI 代码进入生产前，需要经过审查、测试和责任确认。

真正的问题不是会不会用 AI，而是愿不愿意负责

AI 编程不会消失。

它已经足够好，能在很多场景里节省时间；也足够危险，能在很多场景里制造返工。

成熟的态度不是拒绝，也不是盲信。更像是把它放回工程系统里：有输入约束，有审查，有测试，有回滚，有责任人。

代码不是因为生成速度快才值得提交。

代码值得提交，是因为负责它的人理解它、验证它，并愿意在它出问题时修它。

这条线不能让给任何工具。

推荐阅读

LLM 写代码的新风险：不是写错，而是差一点就好

AI 生成 PR 正在刷爆开源项目：GitHub 贡献信号为什么失灵了

AI Skill 市场的安全账：为什么说 Skill Registry 本质上是新的供应链入口

LLM 编程提速之后，为什么你反而更难想清楚问题

AI 编程争论变味了：为什么反 AI 情绪开始走向怀旧化