AI 与软件 · 判断权的转移

软件正在被AI杀死

从不想看代码，到已经看不懂：程序员可能在失去工作之前，先失去判断力。

Archi  ·  2026年11月 5 日  ·  阅读约 9 分钟

先 说 结 论

我的判断：AI 不只在降低软件开发门槛，也在改变专业人员的工作习惯。当生成速度超过理解速度，审核就可能退化为功能验收；当这种习惯长期延续，人类保留的也许只是批准上线的按钮，而不是决定软件如何运转的能力。以下是一条风险推演，不是已经被证明的必然结局。

我越来越担心，AI 最先改变软件行业的方式，不是让程序员突然失业，而是让程序员慢慢不再像程序员那样工作。

不再追问一段逻辑为什么放在这里，不再关心两个模块为什么互相牵扯，也不再愿意为了一个看不见的边界条件，把刚刚生成的几千行代码重新读一遍。

界面打开了，按钮能点，演示通过。然后进入下一轮。

软件当然没有消失。恰恰相反，它会更多，生成得更快，也更便宜。我说它正在被 AI 杀死，指的是另一件事：让软件成为可理解、可维护、可追责工程的那套人类控制机制，可能正在被一点点掏空。

早期讨论 AI 编程时，有一套很令人安心的分工：AI 负责写代码，专业人员负责架构、审核和兜底。工具再强，人总得坐在驾驶位上。

这套分工并没有错，但它藏着三个条件：人有时间审，有能力审，而且真有权力因为审不明白而拒绝上线。

少一个，所谓“人类把关”都可能只是流程图上的一个方框。

一开始，你会逐行看。后来，你先看改了哪些文件。再后来，你让 AI 总结改动，再让它回答“有没有问题”。

最后，阅读代码这件事，被“看看页面，再跑一下测试”替代。

我认为真正的瓶颈，不是 AI 能不能再多写一点，而是团队愿意为理解已经写出的东西，支付多少时间。

如果生成速度上去了，需求量、改动量也跟着上去，省下的时间又被立刻投入更多需求，审核就会成为最容易被压缩的一环。

这时最危险的，不是有人宣布取消软件工程，而是没人宣布，验收标准却已经换了。

这不是说功能不重要。功能当然重要。问题在于，眼前功能只是软件的一部分，不是软件的全部。

一个页面上显示“提交成功”，不能说明重复点击不会重复执行；正常请求通过，也不能说明越权访问会被拦住。系统没有报错，更不能说明它做对了事。

同样，解耦不是为了让代码看起来漂亮。它的价��，是改一处时影响可控，是出了问题能够隔离，是系统能继续演进而不是每次都押上整条链路。

专业判断也包括不过度设计。一个临时脚本不需要照着大型平台建设。真正的退化，是连“这里值得多做一点，那里可以省掉”的权衡也不再做。

职业敏感性，不是一张毕业证，也不是工龄自动发放的补贴。

看到一次调用，想到超时；看到一次重试，想到重复执行；看到一张表，想到数据增长后会怎样。这些反应，来自长期设计、排错和承担后果。

如果实现交给 AI，排错交给 AI，连“这个改动为什么正确”的解释也交给 AI，人就可能越来越少经历形成这些反应的过程。

这不是说少手写几行代码就会退化。真正需要区分的是：外包重复劳动，还是连形成理解的过程一起外包。

Anthropic 在2026年1月公布的一项随机对照研究，招募了52名主要为初级的软件工程师，让他们学习陌生的 Python 库 Trio。任务后的测验中，AI 辅助组平均50%，手写组67%，差了17个百分点。[1]

AI 组平均完成得稍快，但耗时差异没有达到统计显著。两组在调试题上的差距最大。这比“AI 会不会写代码”更值得警惕：完成任务，并不意味着获得了监督结果的能力。[1]

同一研究还发现，主动追问概念、要求解释、自己解决问题的使用者，保留了更好的理解。这些使用模式并非随机分配，不能直接当作因果结论，但它提示了一个值得继续检验的可能：理解程度的差异，或许不只与是否使用 AI 有关，也与使用方式有关。[1]

2025年微软研究院等作者对319名知识工作者的调查，也发现更高的 AI 信心与更少的批判性思考相关。注意，这是自我报告的相关性，不是“AI 导致大脑退化”的证明。[2]

一个非技术人员对 AI 说：“帮我做个系统。”系统生成了，他打开试一遍，再把不满意的地方说出来。

一个程序员对 AI 说：“按需求实现。”系统生成了，他打开试一遍，再把不满意的地方说出来。

如果两个人都不理解内部实现，也无法独立判断边界，区别还剩多少？

当然，专业背景仍然可能让后者更会定义需求、更会设计测试、更会定位问题。这些差异并不会凭空消失。

但如果这些能力也长期闲置，专业人员在这个工作环节中，就会逐渐接近普通使用者：都在描述意图，都在观察结果，都在等待下一次生成。

过去，用户说“我觉得不对”，工程师能够追到原因。未来最令我担心的画面，是工程师也只能把“我觉得不对”转述给 AI。

这种距离可能从两端同时拉开。

一端，人少看、少改、少追问，对系统的理解不再持续更新。另一端，代码仍在不断生成，依赖仍在增加，实现仍在被一轮轮重写。

AI 并不天然制造烂代码。如果没人约束，它可能快速扩张；如果边界清楚，它也可以帮助精简和重构。关键是：谁还能判断，这次究竟发生了哪一种？

于是我担心的终点，并不是 AI 设计出某种人类智力无法理解的神秘语言。更现实的情况是：代码原则上可读，但规模、变更频率和理解成本，超过了团队愿意支付的预算。

技术上能够看懂，组织里却没有人真正懂。

出了问题，先让 AI 解释；解释听不明白，再让 AI 简化；修复完成，再让 AI 审核。人看到了越来越友好的说明，却未必更接近真实系统。

再换一个模型审核，当然可能发现问题。但“换了模型”不能自动等于独立证据。两个模型可能共享相似盲点，也可能围绕同一份错误前提给出一致答案。

这里必须回应一个反驳：程序员早就不逐条检查机器码了，为什么未来不能不看 AI 生成的代码？

我同意。软件工程从来不是要求一个人理解每个底层细节。编译器、数据库、框架，本来就是建立在抽象和分工之上的。

区别不在于“谁写”，也不在于“每一行是否都看过”。区别在于：被隐藏的实现，是否有可信的契约、独立验证的手段，以及出了问题后的接管路径。

成熟工具也有缺陷，但我们可以通过接口约束、测试、观测、版本管理和责任分工，建立有限而可检查的信任。AI 生成的软件，同样需要这套东西，而不是仅凭一段自信解释过关。

所以我并不认为，工程质量必然消失。有一种可能，是越来越多工程检查被自动化，人类把注意力移向需求契约、系统风险和验证机制。

那是软件工程升级，不是软件工程死亡。

可如果团队只拿走生成速度，却不建设验证能力，还不断削减理解系统的人，就会走向相反的道路：开发门槛降了，真正控制系统的门槛却越来越高。

这才是我想表达的完整判断：如果这条路径持续下去，程序员不会等到某一天收到通知，才突然失去对软件的主导。

交接可能发生在每一次“先别看了，能用就行”里。

先是不愿意审，再是审不完；然后是不熟悉，最后是即使给了时间，也已经无法有效判断。人还坐在研发岗位上，但“人类最终审核”的承诺，已经失去了支撑。

要打断它，关键不是要求每个程序员恢复手写一切，而是保留三件事：定义何为正确的人，独立证明结果的手段，以及证据不足时真正停止发布的权力。

需要读的关键路径，就必须有人读；可以自动验证的边界，就把标准放到实现之前；出了事要能停、能退、能追到原因，而不是只会追加一句提示词。

如果连这些也全交给 AI，谁来区分“AI 确实做对了”，和“AI 只是成功说服了你”？

软件不会因为没人理解它，就立刻停止运行。它可能照常更新，功能越来越多，发布越来越快。

只是到了那一步，开发做什么、怎么做、出了问题怎么修，事实上都得听 AI 的。责任留给人，解释权交给机器。

最近一次，你真的审过代码吗？

不是看 AI 的总结，也不是确认页面能跑：最近一次，你独立解释一个关键改动为什么正确，是什么时候？如果你带团队，也可以把这个问题带到下一次评审：我们的“人类把关”，究竟是一种能力，还是一个签字动作？

观点评论 · 2026年11月 5 日。场景为说明机制而构造，非特定团队调查；职业能力长期退化与最终控制权转移是条件性推演，不是研究已证明的结论。[1] Anthropic：How AI assistance impacts the formation of coding skills（2026-01-29）[2] Microsoft Research 等：The Impact of Generative AI on Critical Thinking（CHI 2025）

小良哥 · 看清 AI，少走弯路