AI Coding 越强，我越不敢让它随便写代码

AI Coding 越强，我越不敢让它随便写代码

最近几个月，我大量使用 AI Coding。

它确实很强。

以前需要写两天的功能，现在几个小时就能做完；不熟悉的技术栈，也能边问边写；一个人带着几个 Agent，表面上真的可以干过去一个小团队的活。

但用得越多，我反而越警惕。

因为我逐渐意识到：

AI Coding 最大的风险，不是它写不出代码，而是它可以快速写出大量没人真正理解的代码。

代码能运行，测试能通过，页面看起来也没问题。

可你并不知道，它在里面埋了什么。

更可怕的是，你甚至没有时间知道。

AI 写得越快，人越容易失去控制

现在使用 AI Coding，最常见的流程是：

把需求扔给 Agent；

让它读取项目；

自动修改代码；

运行测试；

发现报错；

继续修复；

最后告诉你：任务已完成。

整个过程看起来极其顺滑。

十几分钟后，几十个文件被修改，上千行代码被生成。

这时候，你会认真逐行 Review 吗？

大概率不会。

你通常只是打开页面看一眼，发现功能正常；再跑一下测试，发现没有报错；最后看一下 Git Diff，觉得好像也没什么大问题。

然后提交。

问题就在这里。

AI 五分钟可以生成两千行代码，人不可能用五分钟理解两千行代码。

所谓“AI 写代码，人负责 Review”，在现实中往往只是一个美好的说法。

最后的 Review 很容易退化成：

能不能运行；

页面对不对；

测试能不能通过；

有没有明显错误。

至于它的抽象是否合理、模块边界是否正确、未来是否能够扩展，往往根本来不及判断。

结果就是：

代码是 AI 写的，Bug 是人查的；

架构是 AI 改的，事故是人扛的；

AI 十分钟完成任务，人两天收拾残局。

AI 可以写出正确的代码，也可以写出错误的系统

软件开发最难的，从来不是把某个功能写出来。

真正困难的是：

这段代码应该放在哪里？

这个能力该不该抽象？

这个模块是否应该依赖另一个模块？

今天为了方便增加的逻辑，会不会成为未来的包袱？

这些问题没有标准答案。

它们依赖业务背景、历史架构、团队经验，以及对未来变化的判断。

AI 很擅长回答“这个功能怎么实现”。

但它很难真正理解：

为什么这个系统过去是这样设计的；

哪些地方看起来奇怪，却不能轻易改；

哪些代码看起来重复，实际上是在隔离业务风险；

哪些设计短期不优雅，却是为了长期稳定。

这也是为什么，我很难相信微信、抖音、快手这类超级 App，可以把需求直接交给 AI，然后完全依赖生成代码持续演进。

这些系统背后有大量隐性约束：

高并发、灰度发布、历史兼容、数据一致性、容灾、客户端碎片化，以及无数次线上事故留下来的经验。

这些东西不是写一份需求文档、补几句 Prompt，AI 就能完全理解的。

AI 能学习通用最佳实践，却很难天然理解一家公司的特殊性。

而真正决定大型系统稳定性的，恰恰不是通用知识，而是这些特殊性。

所谓“古法编程”，不是拒绝 AI

我说古法编程依然重要，并不是说程序员必须重新手敲每一行代码。

真正应该保留的，是人对系统的理解和控制权。

核心架构、底层框架、关键数据模型、安全边界、稳定性机制，这些地方仍然应该由人主导。

因为底层框架最重要的作用，不只是提供功能。

它还要约束后来的人不能乱写。

好的架构会通过接口、类型、模块边界、测试和发布流程，把正确的工程判断固化下来。

它不是让开发者拥有无限自由。

而是让错误的实现方式变得更难。

未来 AI 可以生成大量业务代码，但系统骨架必须有人真正懂。

AI 可以负责盖楼，但地基、承重墙和消防标准，不能让它临场发挥。

裁掉程序员，换成 Token，未必真的省钱

AI Coding 还有一个经常被忽视的问题：Token 也是钱。

改一句文案、调一个颜色、挪一个按钮，人可能几分钟就能完成。

但 Agent 可能会：

读取项目结构；

搜索相关文件；

扫描大量代码；

分析依赖关系；

修改代码；

运行测试；

读取日志；

继续修复。

最终只是改了一句话，却绕着整个代码库跑了一圈。

很多人觉得 AI 比程序员便宜，是因为只看见了模型账单，没有看见完整成本。

完整成本还包括：

写 Prompt 的时间；

等待 Agent 执行的时间；

人工 Review 的时间；

AI 改错之后返工的时间；

代码失控后的维护成本；

以及团队逐渐失去系统理解后的长期成本。

程序员每天的工作也不只有 Coding。

他们还要理解业务、沟通需求、设计方案、处理线上故障、协调系统和承担责任。

所以，减少程序员、增加 Token，并不是一道简单的替换题。

更可能出现的结果是：

人少了，代码更多了，剩下的人更累了。

以前，一个程序员维护自己写的代码。

以后，一个程序员同时指挥多个 Agent，审查大量陌生代码，处理多个 Agent 并行制造的问题，还要为最终结果负责。

这未必叫降本增效。

也可能只是把风险集中到了更少的人身上。

不是每个需求，都配得上启动一个 Agent

AI Coding 时代，最缺的可能不是模型能力，而是成本意识。

不是每个需求都值得扫描整个代码库。

不是每个 Bug 都需要启动最强模型。

不是每次修改都需要几十万 Token 的上下文。

改文案，可以直接改。

改样式，可以限定文件范围。

明确的小问题，可以使用更小的模型。

重复性工作，可以交给脚本和规则。

只有真正需要理解复杂上下文的问题，才值得让 Agent 深度介入。

能用搜索替换解决的问题，就不要先让 AI 阅读人生。

未来真正成熟的 AI Coding，不应该是“什么都交给 Agent”。

而应该像管理云服务器一样管理模型：

任务要分级；

上下文要限制；

调用次数要限制；

Token 要有预算；

模型要做路由；

失败到一定程度必须停止；

高风险修改必须由人接管。

无脑使用 AI，不叫先进。

只是缺少治理。

我们得到了效率，却可能失去了能力

AI Coding 最大的价值当然是效率。

以前几天完成的事情，现在几小时就能完成。

以前不敢做的产品，现在很快就可以做出原型。

但我越来越想问一个问题：

产品做得更多了，代码生成得更快了，Token 烧得更多了，可人和组织到底沉淀了什么？

过去，程序员通过设计、编码、调试和排查问题，逐渐形成对业务和系统的理解。

现在，很多过程被 AI 直接跳过了。

人拿到了结果，却没有经历推导。

久而久之，代码库越来越大，真正理解代码的人却越来越少。

每次遇到问题，团队都让 AI 重新扫描、重新理解、重新推理。

Token 用完之后，能力并没有留下。

这意味着企业购买的只是一次性答案，而不是长期能力。

效率可以带来短期产出。

但只有沉淀，才能形成长期竞争力。

AI Coding 越强，人越不能放弃“古法编程”

大量使用 AI Coding 之后，我形成了三个判断。

第一，古法编程不会消失。

核心架构、底层框架和高稳定性系统，仍然需要人真正理解并亲自控制。

第二，程序员不能简单地被 Token 替代。

AI 可以替代部分编码工作，却不能自动替代判断、协作、责任和经验。

第三，每一次 Token 消耗，都应该留下东西。

它应该沉淀成代码、测试、规范、框架、文档或者组织知识。

否则，Token 消耗得越多，可能只是返工得越快。

我并不反对 AI Coding。

相反，未来不会使用 AI Coding 的程序员，很可能会失去竞争力。

但完全依赖 AI Coding，逐渐失去独立判断和系统理解能力的人，也一样会失去竞争力。

真正合理的分工应该是：

人负责判断方向、设计边界、建立约束和承担责任。

AI 负责在边界之内高速执行。

AI Coding 越强，人越不能放弃对系统的理解。

因为未来真正稀缺的，不是写代码的能力。

而是在所有人都能快速生成代码之后，仍然有人知道：

什么代码值得生成，什么代码根本不该出现；什么效率是生产力，什么效率只是在加速浪费。