一句话定义：AI 代码脆弱性（Code Fragility）是指当智能体（agent）以远高于人类的速度生成并提交代码时，整个代码库在可维护性、可验证性和回滚成本上集体退化的一种现象：单次改动看起来都没问题，合在一起却越来越难改、难验、难退。
先打个比方。在墙上挂东西，用一颗膨胀螺丝很稳；但如果图快，每样东西都用免钉胶一贴，十分钟挂满一整面墙，看上去也很整齐。问题在以后：想换一幅画，得先弄清哪块胶连着哪块；想拆掉一件，可能顺手撕下一片墙皮；想退回上周的样子，发现根本分不清哪些胶是那时候粘的。AI 代码脆弱性就是代码库被贴满了“免钉胶”。
三个变脆方向。
*可维护性*：智能体倾向在局部“让它跑起来”，于是同一个工具函数被实现了三四遍，命名各写各的，配置散落在多处。单看每处都合理，合起来没人说得清哪个是权威版本。
*可验证性*：代码和测试往往一次性产出，测试容易变成“对现有实现的说明书”，而不是对需求的检验。改动后测试全绿，只说明实现和行为自洽，不说明它还对。
*回滚成本*：这是最容易被忽略的一项。一次提交横跨十几个文件、顺手格式化、顺手改了个依赖，出问题时无法只回退那一处，只能整块回滚，连带把别人的改动一起撤掉。
和技术债、理解债的区别。技术债（Tech Debt）是有意识借的未来成本，你知道欠了什么；理解债（Comprehension Debt）说的是人脑与代码之间的差距，代码超出了团队能讲清楚的范围；而代码脆弱性是系统层面的物理属性，直接体现在“改一下要动多少”和“退一步要退多远”上。
| 主要来源 | 典型症状 | 怎么缓解 | |
|---|---|---|---|
| 技术债 | 明知故犯的取舍 | 知道哪里脏，有账本 | 排期偿还 |
| 理解债 | 代码增长快于人理解 | 没人敢动核心模块 | 讲清、写清、减少黑箱 |
| 代码脆弱性 | 高频、大粒度的自动生成与提交 | 改动牵连广，难以单独回滚 | 限制改动半径，保留可拆分的提交 |
实际意义。对从业者，最实用的一条是把“能不能单独回滚”写进验收清单：一次生成只动一个可命名的范围，格式化和重构不夹带在功能改动里；定期做“删掉一个功能”的演练，看它牵连多少地方。对普通职场人，这意味着软件资产的折旧逻辑变了：代码行数不再是产出，能被安全修改和撤回的部分才是。工具与平台的具体能力以官方页面为准。