不过换个角度来看，这件事也未必全是缺点。AI编程真正带来的改变，或许并不是机器终于能写出毫无瑕疵的代码，而是第一版代码的获取成本变得极其低廉。当代码可以快速生成、快速运行、快速修改、甚至快速推倒重来时，第一版代码就没必要像宝贝一样供着了。

过去，程序员写代码好比砌墙，每一块砖都得小心翼翼；现在，AI让一部分代码更像是白板上的草稿，先画出来再说，错了擦掉就好。这其实是在AI编码时代值得重新审视的一个变化：代码正在从长期资产，慢慢变成一部分可消耗的草稿。这不是说质量标准降低了，而是工作方式变了，团队需要清楚地区分验证阶段和交付阶段。

“能跑就行”为什么以前是贬义词

传统软件工程里，“能跑就行”可不是什么好词儿。

这通常意味着没有设计、没有测试、不管边界、不处理异常、更不考虑长期维护。今天为了赶进度糊弄出来的临时代码，明天说不定就成了谁都不敢碰的祖传老账。一个功能表面上跑通了，后面需求稍微动一动，就可能牵一发而动全身。

所以过去的工程文化一直在强调代码质量。代码不仅要能运行，还要可读、可维护、可扩展、可测试。因为代码不是写完就完事了，它迟早要被别人读、被新需求改、被线上问题反复拷打、被时间不断折磨。

这也就解释了为什么程序员对烂代码那么敏感。烂代码最可怕的地方，不是它今天跑不了，而是它明明跑得欢，却没人知道它为什么能跑，更没人敢拍胸脯说明改了以后它还能不能跑。

在这种大背景下，“能跑就行”当然是贬义，代表的是短视、粗糙和技术债。

但AI编码出现之后，这个判断开始变得微妙了。因为过去写一版代码的成本太高，人花了半天时间写完，自然舍不得删；而现在，如果AI生成了一段不合适的代码，完全可以让它重来一遍。这并不是说代码质量不重要了，而是说：第一版代码的意义，真的变了。

AI把初稿的成本打了下来

AI编码最直接的本事，不是生成完美代码，而是快速搞出一个能跑的版本。

以前开发一个功能，流程大致是：理解需求、设计方案、写代码、调试、联调、测试、修改。每一步都得消耗工程师的时间，所以大家都会尽量在动手前想清楚，避免返工。

可AI把这个节奏完全改了。现在很多低风险功能，可以换成这样的流程：描述需求、生成代码、跑起来看看效果、修改提示词、重构或者重写。过去很多争论只能在会议室里靠嘴解决，现在可以先搞一个能跑的版本，把问题直接摆到桌面上。

这意味着，代码初稿的成本被大幅拉低了。当初稿足够便宜的时候，第一版代码的目标就不一定非要是长期可维护，而是尽快制造反馈。它可以把一个抽象的想法，快速变成可点击、可运行、可测试的东西。产品看流程，测试找边界，业务确认规则，开发判断复杂度——一切都清晰起来。

举个例子，一个后台管理页面到底要不要增加批量操作功能？以前产品、开发、测试可能要讨论半天。现在呢？先让AI写一个粗糙版本，跑起来给大家看看。看完之后，团队可能立刻发现：这个交互根本不适合批量操作，或者这个字段必须增加校验，甚至这个流程应该拆成两步走。

这时候，AI代码的价值并不在于它写得多优雅，而在于它让问题提前暴露出来。所以，“能跑就行”在AI编码时代可以被重新定义：它不再是上线标准，而是验证标准。

代码草稿化，到底值在哪

这里需要引入一个概念：代码草稿化。

所谓代码草稿化，不是说所有代码都不重要了，也不是说可以放弃工程质量。它指的是：一部分代码的生命周期正在缩短，它们的主要价值不在于长期存在，而在于快速验证、快速试错、快速被替换。

典型的场景包括：产品原型、内部工具、自动化测试脚本、数据处理脚本、Mock服务、活动页、后台CRUD、一次性迁移工具、小型独立模块，等等。

这些代码过去也得人认真写，因为人力成本摆在那里。哪怕只是一个临时脚本，也得有人花时间写、调、改。久而久之，很多临时代码被保留下来，甚至变成了生产链路的一部分。

但AI让这类代码的命运变了。它们可以快速生成，也可以快速废弃。

这带来一个心态上的转变：人类程序员会珍惜自己熬夜写出来的代码，但不会太珍惜AI五分钟生成的代码。正是因为不珍惜，才更容易删除、重写和重构。

这件事反而很有价值。过去很多技术债，不是因为没人知道代码烂，而是因为大家舍不得改，或者不敢改。代码已经跑在线上，谁知道里面藏了多少隐性依赖。改它风险太大，不改又越来越沉重。

但如果一个模块从一开始就被设计成可替换的，边界清楚，测试充分，那么内部实现就没那么神圣了。AI生成的第一版不好，可以换第二版；第二版结构不清晰，可以让AI帮忙重构；需求变了，就重新生成。

这时候，代码不再是纪念碑，更像是草稿纸。草稿不是垃圾。草稿的价值，是让想法尽快落地，让问题尽早暴露。真正危险的，不是草稿本身，而是把草稿当成成品直接上线，且没有任何测试、审查和边界保护。

草稿化，更需要质量护栏

这也是最容易误解的地方。

说AI代码可以是草稿，并不意味着AI写完能跑就直接上线。恰恰相反，AI编码越快，质量护栏就越重要。

因为AI代码有一个典型问题：它很容易满足happy path，却常常遗漏异常路径。它能把正常输入、正常流程、正常返回写得像模像样，但在权限校验、并发冲突、数据一致性、错误处理、安全攻击面这些地方，经常靠不住。

所以，我们需要区分不同阶段的质量要求。

也就是说，AI代码可以从草稿开始，但不能以草稿状态结束。“能跑就行”只能用在低风险、早期验证、影响面可控的场景里。越是靠近钱、权限、数据、合规和基础设施，就越不能只追求“能跑”。

支付、账务、权限、风控、加密、交易、基础设施、高并发一致性逻辑——这些地方绝对不能把AI代码当草稿随便上线。因为这些代码一旦出错，代价可不是重写一下那么简单，而是资金损失、数据泄漏、系统故障或者安全事故。

所以，AI编码时代真正合理的流程应该是：AI生成草稿 → 跑通流程 → 补充测试 → 暴露问题 → 重构实现 → 人工审查 → 工程化合入。这才是代码草稿化的正确打开方式。

程序员的价值，正转向驾驭反馈系统

如果代码初稿变得这么便宜，程序员的价值会不会下降？

换个角度看，这个担忧可能没太大必要，但价值确实在转移。

过去，程序员的主要价值在于把需求翻译成代码。谁能更快、更准确地写出实现，谁就更有价值。

到了AI编码时代，这部分能力会被稀释。因为AI可以快速生成大量代码，甚至能根据错误信息不断修改。但AI仍然不知道什么代码值得写、什么边界必须守、什么风险不能碰、什么实现应该删掉重来。

所以，人的价值会转向几个更关键的方向：定义清楚需求、拆分合理模块、设计系统边界、编写有效测试、判断风险等级、审查安全问题、决定哪些代码该保留、哪些该删除、判断什么时候从草稿阶段进入工程化阶段。

对测试开发来说，这个变化尤其明显。很多测试辅助工具、数据构造脚本、接口验证脚本、Mock服务、自动化用例，本来就不是核心业务资产。AI可以快速生成一个能跑的版本，测试开发再补充断言、异常用例、边界条件和稳定性保障。

这会让测试开发的工作更偏向反馈系统设计，而不是单纯写脚本。

未来优秀的程序员，可能不是那个最会一行一行手写代码的人，而是那个最会驾驭反馈循环的人。他知道什么时候让AI快速试错，什么时候必须停下来做设计；知道哪些代码可以草稿化，哪些代码必须工程化；知道如何用测试、审查和监控，把一个粗糙的实现一步步逼近可靠系统。

所以，“能跑就行”在AI编码时代，不应该被理解成放弃质量，而应该被理解成一种新的起点。先让想法跑起来，再用测试、重构和工程规范去筛选它、修正它、淘汰它。

过去，差代码最可怕的地方是没人敢改；现在，如果代码由AI快速生成，模块边界清晰，测试反馈充分，它反而可以随时被推倒重来。

代码正在从纪念碑变成草稿纸。真正重要的，不是第一版代码有多漂亮，而是团队有没有能力快速发现问题，并且有勇气把它重写。