AI 当编程搭档

写代码是 AI 帮助最明显的场景之一——它能在几秒钟内写出你要查半小时文档才能写对的调用，能把一段乱七八糟的脚本整理清楚，能在你完全陌生的语言里给你一个能跑的起点。但它也是风险最不对称的场景：一篇有问题的文章会被读者当场质疑，一段有问题的代码可以安静地跑三个月，然后在最不合适的时候出事。这一节要认真讲 Vibe Coding（凭感觉编程——不细读生成的代码、跑通了就往下走）的真实收益与真实代价，讲清一个反直觉的结论：最危险的不是它写出跑不起来的代码，而是它写出「跑得通、看着对、但你不理解」的代码。跑不通的代码会当场报错，看着对的代码要等到上线之后才咬人。本节复用前面章节的地基：Agent 的自主权边界见 § 11.1，工具调用的本质见 § 11.2，注入与权限的乘法关系见 § 13.5。

先说清楚 Vibe Coding 是什么，以及它的收益是真的

Vibe Coding 这个词近两年流行起来，指的是一种工作方式：你用自然语言描述你想要什么，让模型生成代码，你不逐行读，跑一下，看结果对不对，不对就再让它改。循环往复，直到跑出你想要的东西。说白了就是「凭感觉编程」——你判断的依据是运行结果给你的感觉，不是对代码的理解。

这一节不打算贬低它，因为它的收益是真实的，而且在某些场景下大得离谱：

• 一次性脚本你要把一个文件夹里三百个 Excel 表按某个规则合并，跑完就删。这种代码不需要维护、不需要别人读、错了重跑一遍就行。在这里花时间读懂代码是纯浪费。
• 陌生语言或陌生框架的起步你会 Python 但要写一段 Rust，或者第一次碰某个前端框架。有一个能跑的起点，比读三小时文档快得多。相当于去一个陌生城市，先打车到市中心，再自己走——总比从机场开始研究公交线路快。
• 探索性验证你想知道某个想法可不可行，需要一个粗糙的原型。这时候代码质量完全不重要，重要的是尽快知道答案。
• 重复性改造把一百个函数从一种写法改成另一种写法。这类活人做得慢还容易漏，它做得又快又整齐——但改完必须跑全量测试。
• 查用法「这个库的这个函数怎么调、参数是什么意思」。比翻文档快，而且它会直接给你一个上下文匹配的例子。注意这类回答要当线索用——版本对不对得自己确认，因为库的接口会变（§ 13.1 的告诫在这里同样适用）。

这五类的共同特征值得点出来：代码的生命周期短、错误后果可控、不需要别人接手维护。本质上就是一次性餐具——用完就扔，不必讲究材质。

但反过来看，这也就划出了 Vibe Coding 的边界：一旦代码要长期存在、要被别人读、要处理真实用户的数据、要在线上跑，那些被跳过的检查就会一个一个变成账单。

为什么「跑通了」是一个这么弱的标准

这是本节最要紧的一段。「跑通了」这个信号弱在哪儿？弱在它只覆盖了你测试时用的那一条路径。

打个比方：你买了一辆二手车，试驾了十分钟，在小区周边平路上开了两圈，一切正常。这十分钟没有测到的东西包括：上高速会不会抖、下雨天雨刮器行不行、空调制冷够不够、连续爬坡水温会不会高、后备箱漏不漏水、以及最要紧的——刹车片还剩多厚。试驾成功只证明「在这十分钟的条件下它能动」。

代码里对应的清单是这样的。下面每一条都是「跑通了但仍然有问题」的典型形态：

这张表里最值得警惕的不是某一条，而是它们的共同结构：全部都在「功能正确」之外，全部都在开发环境里沉默，全部都在真实条件下才出现。

而 Vibe Coding 的验收方式——跑一下看结果——恰好只覆盖「功能正确」这一项。这不是说这种方式没用，是说它的覆盖面必须被清楚地知道。相当于体检只查了身高体重，报告上的数字都对，但你不能因此说身体没问题。

一张分级表：什么代码可以凭感觉，什么必须读懂

与其争论「该不该 Vibe Coding」，不如给一张分级表。判断标准是两个问题：错了会有什么后果？谁将来要读它？

这张表的用法很简单：动手之前先给自己写的这段代码定个级。定完级，做什么就清楚了。

而且要注意 L4 的判断标准和前四级不一样：前四级关心的是「代码好不好」，L4 关心的是「错了能不能撤回」。打个比方：切菜切歪了可以再切一刀，但盐放多了没法从汤里捞出来。凡是属于「盐放多了」这一类的操作，谨慎的重点不在手法，在下手之前那一秒。这一点 § 11.1 讲 Agent 选型时说过一条同源的原则：给 Agent 的自主权，应当正好等于「它出错时你能承受的损失」。

代码审查清单：AI 生成的代码要专门查这九项

下面这份清单是针对 AI 生成代码的，不是通用代码审查。它挑的是模型生成时最常出问题的地方——这些地方通常不是「写错了」，而是「写成了最常见的那种写法，而你的场景需要另一种」。

你可以自己逐项检查，也可以把清单交给模型让它自审（但要注意后一种做法的局限，下面会说）：

【AI 生成代码 · 九项审查】

1. 异常路径：网络失败、文件不存在、返回空、超时——
   这四种情况分别会发生什么？会静默继续还是会报错？
2. 边界输入：空、0 条、1 条、极大量、重复项、
   含特殊字符——各自表现如何？
3. 硬编码：有没有把密钥、路径、URL、账号、
   魔法数字直接写在代码里？
4. 输入校验：所有来自外部的输入（用户、文件、接口）
   有没有校验？拼接进 SQL / 命令行 / 路径了吗？
5. 权限范围：这段代码需要的最小权限是什么？
   它实际拿到的权限是什么？两者差多少？
6. 资源释放：打开的文件、连接、锁，
   在出异常时也会被关掉吗？
7. 依赖：引入了哪些库？版本是什么？
   有没有引入我不需要的重型依赖？
8. 语义核对：需求里的每个限定词——
   「本月」含不含最后一天？「大于」还是「大于等于」？
   「去重」按哪个字段去重？
9. 沉默的失败：有没有 catch 住异常之后什么都不做的地方？
   有没有把错误当正常值返回的地方？

九项里第 8 项和第 9 项最值得展开，因为它们最容易被漏。

第 8 项「语义核对」。模型出错最常见的方式不是语法错、不是逻辑错，是把你的需求理解成了另一个合理的意思。打个比方：你跟装修师傅说「这面墙全刷白」，他把踢脚线也刷了——他没做错，是「全」这个字有两种理解。代码里的同类例子极多：「最近七天」是含今天还是不含、「排序」是升还是降、「更新」是覆盖还是合并。这类错误的特点是代码完全正确地执行了一个错误的需求，所以任何测试都测不出来——因为测试也是按同一个误解写的。

第 9 项「沉默的失败」。这是所有问题里最难查的一类。它长这样：程序捕获了一个错误，然后什么都不做，继续往下跑。结果是：程序没崩、没报错、给出了一个结果，而这个结果是错的。

相当于体温计电池快没电了，它不提示，就给你显示 36.5——你以为没发烧。一个会大声报错的程序远比一个悄悄给错答案的程序安全。所以审查这一项时的具体动作是：搜一遍代码里所有捕获异常的地方，逐个确认「这里发生错误时，我能知道吗」。

关于「让模型自审」的局限，必须说清楚：让它检查自己生成的代码是有价值的，但不能当成独立验证。原因和 § 14.2 quiz 里讲的一样——同一个模型的两次输出不构成独立验证，它审自己的代码时，那些「因为它就是这么理解需求的」而产生的错误，它同样看不出来。说白了：让抄错题的人自己检查抄得对不对，他会照着自己抄的那份再念一遍。更有效的做法是把「需求原文」和「生成的代码」一起给它，让它回答「这段代码与需求有哪几处不一致」——把参照物换成需求，而不是它自己的理解。

提问方式决定代码质量：五条具体改法

很多人抱怨「它写的代码不行」，其实问题在需求描述。这一段给五条能立刻改善结果的具体改法，每条都是 § 10 章原则的应用。

• 改法一：先给约束，再给需求大多数人只说要什么，不说环境。而环境决定了一半的实现方式。要给的东西：语言与版本、运行环境（哪个操作系统、有没有网络）、能不能装新依赖、数据规模量级、性能要求、错误时希望怎么处理。最后那一项最常被漏，而它直接决定第 9 项审查会不会出问题——你不说，它默认会选一种「让程序继续跑下去」的写法。
• 改法二：把「怎么算对」写成可判定的例子不要说「按合理规则去重」，要说「输入这三行，应该输出这两行」。其实就是 § 10.2 讲的 few-shot 换到代码场景：给示例比给形容词有效得多。而且这些例子可以直接变成测试用例——一举两得。
• 改法三：明确要求它列出假设加一句：「写代码之前，先列出你为了写这段代码而做的所有假设，尤其是我没说清的地方你是怎么补的。列完等我确认再写。」这一条能拦住绝大多数第 8 项（语义误解）的问题，因为误解在它写代码之前就被摆到了明面上。相当于装修师傅动工前先跟你确认「踢脚线要不要一起刷」。
• 改法四：小步走，不要一次要一整个功能一次给它一个几十行能说清的任务，跑通、读懂、再往下。一次要五百行，你不会读，它错在哪你也定位不了。打个比方：搬家不要一次抱五个箱子，看不见脚下的台阶。
• 改法五：要求它解释而不是只给代码加一句：「代码之后，用三条说清：① 这段代码在什么情况下会出错；② 你考虑过但没采用的另一种实现是什么、为什么不采用；③ 这段代码的性能瓶颈在哪一行。」第 ② 条特别有价值——它逼着模型把取舍显式化，而取舍恰恰是代码里最重要、最不容易从代码本身看出来的信息。

这五条里如果只用一条，用改法三。因为它把最难发现的一类错误（需求被理解成另一个意思）从「事后排查」变成了「事前确认」，成本几乎为零，收益极高。

用 Agent 写代码：多出来的那层风险

现在很多编程工具已经不只是「生成一段代码给你」，而是能自己读文件、自己改多处、自己跑命令、自己看报错再改——这就是 § 11.1 讲的 Agent（智能体）。这带来了很大的便利，也带来了一层新的风险，必须单独讲。

第一层多出来的风险：它的动作是有副作用的。§ 11.2 讲过一个很重要的澄清：模型压根没有手，它只是写了一张格式规整的纸条，真正执行的是外面那套系统。这意味着风险的大小不取决于模型有多聪明，取决于你给外面那套系统开了多大的权限。

相当于你给一个新来的实习生一串钥匙。他很勤快、很聪明、也很想帮忙。但如果那串钥匙里有财务室和机房的，那么他任何一次善意的误操作，后果都由钥匙的范围决定，而不是由他的善意决定。这个类比 § 13.5 用过，那一节的结论在这里直接适用。

第二层多出来的风险：pass^k 问题。§ 11.1 讲过一个很硬的数学事实：如果单步成功率是 0.95，连续八步全对的概率只有 0.66。一个「95 分」的 Agent 在连续八步的任务上是不及格的——这就是「演示惊艳、上线出事」的全部数学原因。

写代码这件事恰恰是典型的多步任务：读需求 → 找到相关文件 → 改动 → 跑测试 → 看报错 → 再改 → 提交。每一步都有出错概率，而错误会往下传。说白了：一条七道工序的流水线，每道工序合格率 95%，最后成品合格率只有七成。

第三层，也是最容易被忽略的：间接注入。§ 13.5 讲过这个攻击面，它在编程 Agent 上格外要紧。因为编程 Agent 会读很多东西：issue 描述、依赖库的说明文档、网页上的报错解答、别人提交的代码注释。而这些内容里可以藏着指令。

§ 13.5 引过 Anthropic 官方文档的原话：某些情况下模型会照做内容里发现的指令，即使它与用户的指令冲突。官方给的建议是「隔离」——把模型与敏感数据和敏感操作隔开，而不是承诺修好它。

落到编程场景的具体做法：

最后一行值得强调一下，因为它是唯一一条能从数学上提高可靠性的做法。其实就是：与其求每道工序都做到 99%，不如把工序拆成三段、每段做完检一次——检验点把错误的传播截断了。

一个具体的例子：看着完全没问题的三十行代码

把上面所有内容落到一个具体场景上。假设你要写一段代码：读一个用户上传的 CSV 文件，把里面的订单金额汇总，写进数据库。模型给了你一段三十行的代码，你跑了，用自己造的十行测试数据，结果完全正确。

它跑通了。现在按九项清单过一遍，会发现什么？

• 异常路径文件里有一行金额是空的，或者写成了「1,200」带逗号。它可能把这一行当成 0 处理并继续——汇总结果就少了一笔，而且没有任何提示。这就是第 9 项「沉默的失败」：结果错了，程序没错。
• 边界输入你测了十行。真实文件可能有五十万行——它写的是一次性读进内存的方式，五十万行会把内存吃满。相当于用一个洗菜盆接一整缸水。
• 语义核对「汇总金额」——退款的负数算不算？重复提交的订单算一次还是两次？不同币种要不要分开？这三个问题你如果没说，它一定按最常见的理解做了选择，而它选的可能不是你要的。
• 输入校验CSV 是用户上传的——这是外部输入。文件名会不会被用来拼路径（有人可以传一个带路径符号的文件名跳到别的目录）？内容会不会被拼进 SQL？「用户上传」这四个字应该让所有涉及它的代码都升到 L3 级。
• 资源释放中途报错时，打开的文件和数据库连接会被关掉吗？跑一次没事，一天跑一千次就会把连接耗尽。
• 写入的原子性如果写到第五百条时失败了，前面四百九十九条怎么办？留在库里，还是全部撤回？这个问题不问清，你会得到一个半写完的数据库——打个比方：转账扣了钱但没到账。

这六条里没有一条是「代码写错了」。每一条都是「代码正确地实现了一个没被说清的需求」。而这恰恰是本节最想传达的：AI 写代码的主要风险不在它的能力，在需求与验收的模糊地带。

所以最有效的改进往往不是换个更强的模型，而是把改法三用上：让它先列出假设。上面六条里至少有四条会在那份假设清单里冒出来，而那时候改的成本是一句话。

初学者的特殊处境：它会不会让你永远学不会

这一段专门写给正在学编程的人，因为这个处境和熟练开发者完全不同，不能套用同一套建议。

熟练开发者用 AI 生成代码，风险是「漏检查」；初学者用 AI 生成代码，风险是「学不会」。这是两个性质不同的问题。

为什么？因为编程这件事有个特点：能力主要来自「自己写出来、跑错了、找到原因、改对」这个循环，而不是来自读懂正确的代码。

打个比方：学游泳的人的能力不是从看教学视频里长出来的，是从「呛了几口水、发现自己头抬得太高、下次调整」里长出来的。而 AI 生成代码这个动作，恰好把「跑错了、找原因」这一环整个抽掉了。

但这不等于初学者不该用它——那个建议不现实，也不合理。正确的做法是把它用在循环的不同位置上：

这张表里最值得记住的是第一行和第三行。

第一行「看不懂报错」是 AI 对初学者最大的善举。因为报错信息是编程里最陡的一道门槛——它们通常很长、有大量无关的堆栈信息、用词晦涩。很多人放弃学编程就是死在这一步：不是不会写，是看不懂错在哪，于是完全卡住。而这道门槛现在几乎被移平了。但要坚持一点：让它解释报错，不要让它改代码。解释报错是在帮你补一项能力，替你改代码是在替你跳过这项能力。

第三行「写完了让它挑错但不替你改」是最有效的成长方式。它的效果甚至超过找一位真人师傅——因为真人不会有耐心逐行看你写的每一段练习代码，而它会。其实就是你有了一个随时在线、永远不嫌你烦、专门盯着挑错的搭档，而这在过去是极稀缺的资源。

还有一个具体的自测办法值得推荐，可以叫「合上再写一遍」：AI 给了你一段代码，你读懂之后，关掉它，凭理解自己重新写一遍。写出来跑通了，说明你真懂；写不出来，说明你只是读懂了。这个动作和 § 14.1 的费曼式追问是同一件事——把「输入」转成「输出」，检验立刻就诚实了。

一个容易被忽略的长期风险：你会看不出代码写得差

这一段讲的是最缓慢、也最难自察的一种损失。它不发生在某一次提交上，发生在几个月的时间尺度上。

现象是这样的：你用得越顺手，读代码就读得越粗。因为大部分时候它写得挺好，你扫一眼、觉得没问题、跑通了、提交。这个流程每天重复几十次，而每一次都在削弱一件事：你对「这段代码写得好不好」的判断力。

这就是章总览页提到的自动化偏差（automation bias）——说白了就是机器帮你做得越久越好，你就越不检查它。

相当于长期依赖导航开车的人，在熟悉的城市里也会失去方向感。不是导航把方向感拿走了，是你太久没用它，它自己退化了。

这件事有两个后果，第二个更麻烦：

• 后果一：你的检查会越来越流于形式从「逐行读」退化成「扫一眼结构」，再退化成「看跑通了就行」。这个退化过程没有任何提示信号——因为每一步都只退了一点点，而且大部分时候确实没出事。
• 后果二：你会失去「这里不对劲」这种直觉有经验的开发者读到某段代码时会有一种说不清的不安——某个变量名不太对、某个判断的顺序有点怪、某处该有的检查不在。这种直觉是从大量阅读与踩坑里长出来的，而它是发现深层问题的主要手段。而这种直觉一旦退化，你会失去的不是「读代码的速度」，是「发现别人和机器都没发现的问题」的能力。

对策不是少用，而是刻意保留一部分自己写。几条很具体的做法：

一是「核心逻辑自己写」。项目里那几段真正体现业务判断的代码，自己写。周边的、样板性的、重复性的，交给它。其实就是厨师会亲自掌握火候和调味，但不必自己去洗菜切葱。

二是定期做一次「不用 AI 的练习」。比如每周挑一个小任务，全程自己写、自己查文档、自己调错。这个动作的作用不是产出代码，是维持那条肌肉不萎缩。打个比方：平时坐电梯没问题，但每周爬一次楼梯，腿就不会废。

三是养成「读完先预测」的习惯。拿到它写的代码，在跑之前先自己判断一句：「如果输入是空的，这段会怎么样」。然后跑一下验证你的判断对不对。这个动作只花十秒，但它同时做了两件事——检查了代码，也检验了你的理解。本质上就是把「验收代码」和「训练自己」合成了同一个动作。

把谨慎做成习惯，而不是做成负担

读到这里，你可能会打起另一个算盘：「九项清单、五级分级、三层风险，这么多条，我哪有时间每条都做？」这个担心是真实的，而且如果不处理，它会导致一个更糟的结果——你把所有检查当成一件需要动员意志力的大事，于是干脆一件都不做，退回纯 Vibe Coding。

正确的姿势是把它降成成本极低的习惯，而不是每次都要走完整个流程。关键原则只有一句：把检查的重心放在「后果最大的那几处」，而不是平均用力。这一点跟很多生活场景是同一个道理。

收到一件快递，你不会把整个箱子拆开逐层查验——你会先看外包装有没有破损、是不是易碎品、需要冷藏的里面放了冰袋没有，剩下的你信任配送过程。去菜市场买肉，你会挑那几样今天就要下锅的，仔细看新鲜不新鲜——你不会把整个摊位的货都验一遍。不是「不需要认真」，是每个环节承担的风险不同，认真该花在风险最高的地方。

代码也一样。把上面的几张工具表翻译成三个优先级就够了：

• 第一优先级：凡是 L3、L4 的代码，那几件硬动作一样都不能省权限最小化、干跑、人工确认、回滚方案。相当于大额转账前再核对一遍收款人——这不会多花你三十秒，但出错时省下的是银行级别的麻烦。这一档没有商量的余地，因为「省事」的代价是「不可逆」。
• 第二优先级：凡是处理真实数据的代码，至少查异常路径和边界输入两样这是九项清单里最常出事的两个点，也是最容易用一句话问清的：「如果输入是空的、超时的、带特殊字符的，会发生什么？」相当于去医院，分诊护士永远先问的那几句——不是问了就绝对安全，是这几句的成本最低、覆盖面最广。
• 第三优先级：其余的一次性代码，向 L0 看齐——跑通前先备份这一条一个人一个月能省下成百上千次事故，因为它把所有的一次性错误都变成了「大不了重跑」。其实就是你先把原文件复制一份挪到另一个文件夹再动手，多花两秒，占的也只是多一个硬盘位置。

这三条加起来，每次动手前多花的不过是两三分钟，却把九成以上的真实损失拦在了门外。最怕的从来不是你不懂哪一条检查，而是「想全做觉得累、于是全不做发飘」——降成三级默认动作之后，谨慎就不再是一道需要每次动员自己的工序，而是一组闭着眼也能完成的惯性。