ARTICLE · 1280523
程序代码:AI “屎山”比人类屎山更大,如何做到改得动、验得了、回得去
QUOTE
开发能力没有捷径：只有亲手解决过自己带来的问题，它才会真正长出来。
— AI 把「生成」的成本打到了地板上，也把「负责」的成本抬到了天花板上
本文约 3400 字 · 阅读约 9 分钟
做了二十年系统建设与运维，最头疼两件事情，一是写程序说明文档，其次是看别人的代码，随着AI辅助编程的功能越来越强大，大部分代码都不用手写了，文档不用手写了，但AI生成的代码也看不完了，系统上线后有问题怎么办呢？这个问题还是只有请教AI。
聊完的结论整理成了这篇文章，外加一份可以直接放进代码仓库的规范文档。先说结论：写代码这件事，确实正在被 AI 接管；但成本没有消失，它转移到了两个更贵的地方——判断，与运维。
本文看点
01
四类对象的真实替代率：代码量越少，替代率反而越低
02
AI 生成代码的三个结构性风险
03
一套可落地的规范：五个阶段，五个关口
01
DATA
先看一组数字：四类应用的真实替代率
把开发对象按 AI 能接管的比例排一下，会得到一个反直觉的结论：代码量越少的对象，AI 的替代率反而越低。
网站 / 企业应用约 80%
小程序约 65%
Agent 应用约 55%
Skill / 提示词工程约 30%
网站最接近全自动，剩下的 20% 集中在权限、支付、性能这些工程问题上。小程序的瓶颈在平台侧：包体积、审核、支付资质——这些知识不在模型的权重里。Agent 应用的代码量很小，但设计密度极高：工具边界怎么切、失败怎么重试，本质是系统设计问题。
而 Skill 几乎不写代码，替代率却最低。一条含糊的指令，会让模型在边界用例上系统性跑偏——指令质量的差距可以放大到十倍，而这种缺陷只能靠人构造用例来暴露。
「真正的门槛不是会不会写，而是能不能在 30 秒内判断一段代码是否可信。」
这个能力没有捷径：只有亲手写过、亲手修过自己引入的并发 bug，它才会真正长出来。
02
STRUCTURE
AI 屎山与人类屎山，不是同一种东西
— 人类屎山是有考古线索的废墟，AI 屎山是无意图的产物
写得再乱的人类代码，也残留着信息：命名习惯、注释、提交历史、同事脑中的模糊记忆。AI 生成的代码是模式匹配的结果——每一行局部都正确，但不存在一个全局的「为什么」。没有作者可问，提交记录只有一行feat: add helper。
更关键的第二点：错误是同质化的。人类的 bug 各有各的错法，通常是局部故障；AI 的偏差是系统性的——同一种错误用法，会在同一个项目里重复两百次。你在 A 处补了边界判断，B、C、D 处同样的漏洞还在，局部修复因此失去意义。
第三点最少被谈起：生成成本降下来之后，没有人在脑内跑通过这个系统。系统的「心智模型」从团队里消失了，而这恰恰是运维最依赖的东西。
03
ARCHITECTURE
决定系统能否运维的，不是代码可读性
这是最需要修正的直觉。真正决定一个系统能不能运维的，是三个能力——它们都不依赖代码可读性。
01
改得动
能定位到要改的那一块，且改动是隔离的
02
验得了
改完几分钟能确认行为没坏
03
回得去
30 秒内回到上一个已知良好状态
一个代码优雅但部署即全量、无测试、无日志的系统，运维难度远高于一个代码糟糕但能灰度、能回滚、有完整链路追踪的系统。所以应对的方向不是「把代码变好读」，而是把 AI 生成物当第三方依赖对待：窄接口、成体系的契约测试、锁定的版本。这三条成立，不可读就不再是致命的。
04
ENGINEERING
规范要写给 AI 读，不只写给人读
传统规范放在 Wiki 里没人看。AI 时代的规范，必须以规则文件的形式（AGENTS.md、.rules/）和代码放在一起，在生成时自动注入上下文。几条最值钱的条款：
生成前四件套
每次生成必须给出目标行为、边界条件、禁改文件清单、验收方式；单次净增不超过 400 行、涉及不超过 3 个文件。「优化一下这个项目」这类宽泛指令，直接驳回。
四条禁止项
禁止复制式扩展（复制函数改一份，是软件难维护的主要机制）；禁止静默降级（空 catch、默认值掩盖错误）；禁止过度防御（为不可能的分支写兜底）；禁止推测式抽象（为「将来可能」预留的扩展点，一律删除）。
审查四问法
审查只问四件事：爆炸半径多大？依赖哪些隐含假设？失败路径是什么？删掉会怎样？触及权限、资金、数据迁移的 A 级变更，禁止 AI 独立完成。
架构第一目标：可抛弃性
AI 让重写成本降了一个数量级，「重构优于重写」的传统权衡已经反转。任何单个模块，都应该能在一个人一天的工作量内被扔掉重写——模块足够小、接口契约稳定、状态全部外置。
一个 20 万行的系统永远无法重写；20 个一万行的系统，坏哪个扔哪个。
— 可抛弃的模块粒度：每个模块都能在一天内被换掉，而系统不受伤
05
DELIVERY
落地：五个阶段，五个关口
规范失败的原因几乎从不是条款写错，而是没有卡点、没有主人、没有节拍、没有证据。
判断标准只有一句话：找不到「不遵守会发生什么」的条款，就不是规范，只是建议。
需求阶段 —— 把约束写进输入
每个需求过「非功能三问」：可用性目标、回滚要求、可观测要求，逐项书面回答；同时标注红线——是否触及权限、资金、数据迁移。这一阶段成本最低、收益最高。
设计阶段 —— 把边界与契约定死
模块边界图、故障域图、数据流向图三图齐备才排期；接口契约先定后写。目的不是画得好看，而是把无法自动检查的东西，提前变成可以检查的。
开发阶段 —— 用卡点改变日常行为
合并卡点是整套规范里唯一高频生效的位置：意图块、行数、契约测试、依赖锁定、静默降级，五项检查逐项过。检查项超过五个就会被绕过——宁可只留真正能拦住事故的。
测试阶段 —— 留下可验证的行为证据
没人读代码之后，测试是唯一的行为规格。跨模块契约测试必须由人定义；覆盖率高而契约测试缺失的系统，比覆盖率低而有契约测试的系统危险得多。
运维阶段 —— 把退路准备好
变更分级、灰度开关、回滚演练。其中季度模块重写演练是唯一无法伪造的检验：随机抽一个模块，验证能否一天内重写。跳过一次，制度即失效。
全部节拍压下来，项目经理每周投入不超过 2 小时。如果某个节拍需要超出这个量才能维持，说明设计有问题——应当减项，而不是加人。
∞
THE END
结语
运维难题确实会出现，但终局不是行业整体失控，而是产生一批「运维化石」——缓慢冻结、无人敢碰、最终用绞杀者模式逐步替换的系统。未来运维工作的重心，会从「维护系统」转向设计故障域与替换路径。
最后一句判断：现在没必要手写全部代码，但极其有必要手写关键的那 10%。这 10% 决定了剩下 90% 是资产，还是负债。
DOCS
完整规范文档 · 免费获取
《AI 辅助开发的系统可维护性规范》
3 条元规则19 项条款23 张落地表格
含开发规范 / 设计规范 / 运维操作规范 / 项目经理五阶段任务计划
长按识别二维码打开云文档，或点击文末「阅读原文」
docs.qq.com/doc/DREpuR21tbXRtQVpT
本文观点经与系统建设、架构演进、运维管理方向的一线从业者讨论整理文档由 AI 辅助排版生成，内容经人工审校
我是 DianLake — 键盘还在，编码不停。
如果你觉得今天这篇有收获，欢迎 关注、点赞、转发三连，我们下篇见。
