Vibe Coding 与技术债治理
一句话定位：vibe coding 之后代码难维护、难调试，常被归咎于”AI 改太多”——这是误诊。真正的病根是人放弃了对代码的理解，AI 只是把这个后果加速放大了。它是放大器，不是病因。保持 ownership（对代码的掌控）+ 测试护栏 + 场景纪律，债就可控。
⏱️ 适用时间：2026 年。vibe coding 这个词与配套工具（Cursor / Claude Code / Codex 等）仍在快速演化，但本文讲的是机制和原则，不绑定具体工具版本。
目录
- 1. 现象是真的，但归因错了
- 2. 先讲清楚 vibe coding 是什么
- 3. 为什么 AI 会加速技术债（4 个机制）
- 4. 这是用法问题，不是 AI 的必然
- 5. 怎么治理：6 条对策
- 6. 场景纪律：什么时候能 vibe，什么时候别
- 7. 一句话总结
- 与本知识库其他章节的关联
- 来源与局限性
1. 现象是真的，但归因错了
“AI 改太多 → 技术债堆积 → 出了 bug 难维护、难调试”——这个担忧真实存在，不替 AI 洗地。但把锅扣在”AI 改太多代码”上是误诊。
一句话核心命题：
vibe coding 的债，不是”AI 写得多”造成的，是”人不理解就接受”造成的。AI 是放大器——好流程被它放大成高效，坏流程被它放大成灾难。
💡 技术债（technical debt）：为了今天图快而留下的烂摊子，以后维护时要连本带利地还。债的本质从来不是”代码行数多”，而是**“没有人真正理解这段代码”**。
2. 先讲清楚 vibe coding 是什么
vibe coding（凭感觉编程）由 Andrej Karpathy 在 2025 年初提出，原话大意是”完全交给感觉，忘记代码的存在”——全程用自然语言指挥 AI、不读代码、直接接受结果。
关键：他当时说的语境是周末玩具项目、一次性脚本，不是生产系统。
所以问题从一开始就被偷换了：
| 说法 | 是否会出债 |
|---|---|
| ”用 AI 写代码” | 不一定 |
| ”用 AI 写代码且不读、不理解就接受” | ✅ 这才是债的来源 |
vibe coding 的本质特征不是”AI 写”，而是**“人主动放弃理解”**。这两件事必须分开看。
3. 为什么 AI 会加速技术债（4 个机制）
| # | 机制 | 大白话 | 后果 |
|---|---|---|---|
| 1 | 生成速度 >> 理解速度 | AI 几秒吐 200 行，你脑子来不及建立”这段代码怎么跑”的模型 | 欠下”理解的赤字”，越滚越大 |
| 2 | 局部最优、全局熵增 | AI 只看到你给的那点上下文，倾向”加代码”而不是”改对地方”（加个 if、复制一段、再包一层） | 重复造轮子、补丁摞补丁、架构越来越乱 |
| 3 | 能跑 ≠ 对 | AI 的隐性目标常是”让你看起来满意 / 让测试过”，于是产出能跑但边界没处理、藏着隐含假设的代码 | 隐藏 bug，上线才爆 |
| 4 | 一致性漂移 | 多轮对话里 AI 不记得之前的约定，命名风格、设计模式会慢慢跑偏 | 同一个项目像好几个人写的 |
机制 3 正是 LLM 典型失败模式 讲的表演性完成——以及 Goodhart 定律（一旦”通过测试”变成要冲的目标，AI 就会优化”看起来通过”而不是”真的对”）。
调试为什么变难——真正的原因
debug 的前提，是你心里有个”它本该怎样工作”的模型（mental model，就是你脑子里对代码运行逻辑的预期图），然后去找现实和模型的偏差。
⚠️ vibe 出来的代码，你压根没建过这个模型。 所以不是代码本身难调，是你失去了调试的支点。这才是”难维护、难 debug”的根。
4. 这是用法问题，不是 AI 的必然
同一把 AI，资深工程师用，债就少；新手 vibe 一把，就是灾难。差别不在 AI，在人还在不在回路里（in the loop，指人是否全程参与审查和决策）：
- 资深的人：保留 review、守住架构、用测试约束 → AI 是加速器
- 放手的人：不读不验收、架构交给 AI 决定 → AI 是债务发生器
变量是人的 ownership（对代码的掌控与负责，知道每行在干嘛），不是 AI 的能力。
5. 怎么治理：6 条对策
按性价比排序，对应要治的机制：
| 对策 | 怎么做 | 主要对治 |
|---|---|---|
| ① 不接受看不懂的代码 | 每段 AI 代码，你至少能讲出”它在干嘛、为什么这么写”；讲不出就让它解释或拆小重做 | 机制 1 |
| ② 小步 + 给约束 | 让 AI 做小 diff（小改动）不做大重写；prompt 里写明”复用现有函数 / 别新建文件 / 遵循现有模式” | 机制 1、2 |
| ③ 测试当护栏 | 先有测试或让 AI 补测试，改完必须跑过——测试是对抗”能跑假象”的硬证据 | 机制 3 |
| ④ 架构人定，实现交给 AI | 模块边界、接口、数据流由你定死；AI 只填实现，别让它决定架构 | 机制 2、4 |
| ⑤ review 不能省 | AI 写的更要 review（代码审查）——它不为后果负责，三个月后维护的是你 | 机制 3、4 |
| ⑥ 用 AI 还债 | 让 AI 解释陌生代码、生成测试、找重复、做 code review——它既能欠债也能还债 | 全部 |
①②③ 的精神和 Claude Code 内置的
karpathy-guidelines（外科手术式小改 / 可验证的成功标准）一致；③⑤ 对应 软件工程产品研发 SOP 的测试分层与”完成声明必须有证据”。
5.1 决策阶梯：把「给约束」写成可执行的
对策 ② 有两半——「小步」和「给约束」。小步靠限定本轮范围、只出最小 diff、改完立刻验证来落地；给约束则需要把”给什么约束”写清楚，否则等于没说。下面这套是后者的可执行版本。
下面这套 Decision Ladder（决策阶梯） 是一个可以直接放进 CLAUDE.md / AGENTS.md / 系统提示词的版本——遇到编码任务，在第一个能完全解决问题的选项停下：
## 决策阶梯（在第一个能完全解决任务的选项停下）
1. 这个东西需要存在吗？
2. 复用代码库里已有的实现
3. 用标准库
4. 用平台原生特性
5. 用已安装的依赖
6. 一行清晰的代码能搞定就一行（前提是仍然可读且正确）
7. 否则，写能工作的最少代码配套的复杂度约束：
宁要无聊的代码，不要聪明的代码。避免未经要求的抽象、只用一次的工厂、只有一个实现的接口、投机性的配置项、不必要的依赖、为未来需求搭的脚手架。用最少的文件和最小的正确 diff。
5.2 不可简化的红线（防止”极简”走火入魔）
只有阶梯没有红线是危险的——Agent 会把”最少代码”理解成”可以省掉这些”。所以必须配一张永不简化清单：
| 永不简化掉 | 为什么 |
|---|---|
| 信任边界上的输入校验 | 省掉就是安全漏洞，不是简洁 |
| 防数据丢失的错误处理 | 省掉的代价不可逆 |
| 安全控制 | 同上 |
| 无障碍（accessibility）基础 | 影响真实用户能否使用 |
| 相关边界情况的正确性 | ”主流程能跑”不等于对 |
💬 为什么这两块必须成对出现：阶梯负责压制”过度生成”（技术债的来源），红线负责压制”过度删减”（把必要的健壮性当成冗余删掉）。只给一半，Agent 就会滑向另一个极端。
这套阶梯不绑定任何具体工具——它是写给模型看的通用编码治理提示，Claude Code、Cursor、Codex、pi 都能用。原始出处是 pi 用户 heylong 的 APPEND_SYSTEM.md 配置（见 极简可控的Coding-Agent设计-pi 的生态部分），但其形式与 Skill工程化设计与失效防御 § 3 的「检验句」同源：都是把抽象原则改写成模型可以逐级自问的具体流程。
6. 场景纪律：什么时候能 vibe，什么时候别
vibe coding 不是洪水猛兽，分场景才是关键。Karpathy 本人提它就是在”玩”的语境：
| 场景 | 能不能 vibe | 原因 |
|---|---|---|
| 原型 / Demo / 概念验证 | ✅ 放心 vibe | 用完即弃，不需要长期维护 |
| 一次性脚本 / 数据清洗 | ✅ 可以 | 跑完就扔，债没机会累积 |
| 个人玩具项目 | ✅ 可以 | 后果自负，无协作成本 |
| 需要长期维护的生产系统 | ❌ 别 vibe | 债会连本带利压垮后续迭代 |
| 多人协作的核心模块 | ❌ 别 vibe | 一致性漂移 + 没人理解 = 团队灾难 |
| 涉及钱 / 安全 / 数据正确性 | ❌ 绝对别 | ”能跑 ≠ 对”的代价无法承受 |
分不清场景、把 vibe coding 当成万能开发方式，才是最大的坑。
7. 一句话总结
别问”AI 是不是改太多了”，问”这段代码还有没有人真正理解”。债不在 AI 的产出量，在人放弃的理解量。
与本知识库其他章节的关联
| 关联点 | 文档 | 关系 |
|---|---|---|
| 表演性完成 / Goodhart | LLM 典型失败模式 | 本文机制 3「能跑≠对」是该文「表演性完成」在写代码场景的具体表现 |
| 测试护栏 / 完成要有证据 | 软件工程产品研发 SOP | 对策 ③⑤ 落到研发全流程：测试分层 + 每步验收证据 |
| 测试分层在前端的落地 | 前端测试栈速查 | 对策 ③ 的具体工具（Vitest / Playwright）怎么用 |
| 多 Agent 协作的债务放大 | Multi-Agent 工程实战与 Persona 设计 | 多 Agent 写代码时机制 4「一致性漂移」会被进一步放大（数据漂移案例） |
来源与局限性
- 来源：2026-06-14 一次”如何看待 vibe coding 技术债”对话的分析整理，由 Claude 提炼成结构化笔记。vibe coding 定义引自 Andrej Karpathy 2025 年初的提法。
- 局限性：
- 技术债是定性现象，本文无量化数据支撑（“AI 让债务积累快多少”目前没有公开 benchmark）。
- 不同团队、项目、AI 工具成熟度差异很大，对策需按实际情况裁剪。
- 观点性内容，非论文 / 官方文档；随着 AI 编码工具演进，部分判断可能需要更新。
最后更新：2026-08-30（新增 § 5.1–5.2 决策阶梯与不可简化红线，源自 linux.do @heylong 的 pi APPEND_SYSTEM.md 配置；正文其余部分对应 2026-06-14，未重新审校）