2026-04-10 07:53
扫码打开虎嗅APP
本文来自微信公众号： 人人都是产品经理 ，作者：雨柒
平台上有不少文章在讨论“产品经理要不要用AI写PRD”，但我今天想聊的，是另一个更隐蔽也更棘手的问题：当你的开发在用AI写代码，而你对代码质量开始失控时，该怎么办？
需要说明的是，这不是在否定AI编程工具，更不是在指责所有用AI的开发——大多数开发使用AI是理性的、有判断力的。但作为产品经理，我在日常协作中观察到了一些值得警惕的现象，想分享出来，和大家一起探讨。
“又延期了。”
这已经是这个版本第三次调整上线时间了。原因说起来有点讽刺——一个开发用AI写了段代码，单租户跑得挺顺，一上线就被多租户的真实流量打垮，整个服务停了一上午。
那个开发事后自己也说不清代码的核心逻辑是什么。他只是把需求“喂”给了AI，代码能跑通，就提交了。
这是一个运行了多年的SaaS老系统，代码库里塞满了十年来的业务逻辑和“特殊处理”。而AI编程工具，正在悄悄变成一个陷阱——看起来能提效，实际上正在往老系统里埋下一颗又一颗定时炸弹。
作为产品经理，我对最终结果负责，却无法直接控制代码的生产过程。眼睁睁看着质量下滑、节奏被打乱，却有一种又着急又使不上力的感觉。
根源在哪？不是AI不行，而是我们从来没有从源头上为它划定边界。
AI编程工具的宣传语总是很动人：十分钟生成一个完整模块，代码质量堪比高级工程师。但很少有人告诉你，这些案例大多来自“从零开始”的项目。
在0→1的场景下，AI确实很强大。没有历史包袱，没有复杂的业务逻辑嵌套，没有十年前的遗留代码需要兼容。AI可以在白纸上画出漂亮的图案。
但SaaS B端的老系统是什么样？
代码库里既有架构师留下的优雅设计，也有实习生留下的“屎山”
业务逻辑经过无数次迭代，充满了针对特定客户场景的“特殊处理”
多租户架构下，数据隔离、并发控制、资源竞争处处是坑
无数个“为什么这样写”的答案，藏在离职同事的脑海里
这样的系统，不是一个能用“标准答案”应对的考场，而是一个充满“例外”的复杂生态。AI的训练数据来自通用场景，它不知道你们公司那张表里的某个字段为什么不能为空，也不理解那个看似无用的判断是为了修补三年前的一次线上故障。
AI给出的，永远是“平均的业务逻辑”，而不是“你们公司特有的业务逻辑”。
部分依赖AI开发的代码，在刚提交时看起来一切正常。功能跑通了，测试用例过了，顺利上线了。所有人都觉得“效率真高”。
但问题往往在几周或几个月后集中爆发。
1.代码变成黑箱
传统开发中，代码是我们自己写的，每一行都是思考的结果。遇到问题，我们知道从哪里下手排查。
AI生成的代码则不同。它可能用了一种你不熟悉的写法，调用了一个晦涩的API，采用了一种你没见过的设计模式。当出现Bug时，开发者可能自己都看不懂这段代码——只能把错误信息再扔回给AI，让AI自己改自己写的代码。
这是一个“递归噩梦”：AI写→人跑→报错→人把报错给AI→AI改→人再跑→循环往复。表面上看起来在“调试”，实际上是在消耗时间。
2.修改成本飙升
老系统的特点是：代码是写给人看的，偶尔才给机器跑。当一段代码没人真正理解时，后续的每一次修改都像拆雷。
我见过一个功能，AI写完后运行正常。三个月后，产品需要在这个基础上加一个小需求。开发研究了两天，不敢动那部分AI生成的代码——因为看不懂逻辑是怎么串联的，不知道改了这处会不会让另一处崩溃。最终，他选择“重写”，白白浪费了时间。
3.多租户延时爆炸
最可怕的问题，是在上线后才暴露的。
前面提到的那个“停摆一上午”的案例就是典型：AI写的代码在单租户、低负载下毫无问题。但当多个租户同时使用，数据量激增，并发请求涌来时，那个没有考虑资源竞争、没有做边界检查、没有处理缓存的代码，就像一颗埋在系统深处的定时炸弹。
这种问题，功能测试根本测不出来。只有真实的生产环境，才能让它“爆炸”。
很多人会说：出了问题改不就行了？
问题在于，在老系统中，这种“单点解决”的方式，正在积累更大的技术债。
每一次用AI生成代码然后发现问题、再生成、再发现问题，都是在增加系统的混乱度。代码库变得越来越难以理解，维护成本越来越高，新人接手越来越困难。
更可怕的是，如果团队习惯了这种模式，可能会出现能力空心化：开发人员不再需要理解业务逻辑、不再需要思考代码结构、不再需要掌握调试技巧——反正AI会写、会改、会解释。
但当AI真的遇到AI无法解决的问题时，团队可能已经没有人能站出来了。
经历了多次“延期-返工-故障”的循环后，我开始思考：问题出在哪里？
不是AI不能用，而是我们没有给AI的使用划定边界。就像你不会让实习生去改核心账务系统一样，你也不能让AI去处理那些对业务至关重要的逻辑。
作为产品经理，我在推动团队建立一套“源头治理”的规则。核心思路是：在代码被写出来之前，就把风险拦住。
第一步：给代码分等级
把系统里的功能按业务影响划分等级，不同等级对应不同的AI使用规则：
第二步：给开发者设门槛
使用AI之前，开发人员应该能够回答几个问题：
这段代码的核心逻辑是什么？（能不能用一句话讲清楚）
它和我们现有的业务规则怎么对应的？（对应需求文档哪一条）
如果数据量变成现在的10倍，它会出问题吗？（有没有考虑边界）
多个人同时用，它会冲突吗？（有没有并发隐患）
如果这段代码出问题，最坏情况是什么？（能不能承受）
如果一个开发答不上来，说明他可能没有真正理解这段代码在干什么。这个清单不需要技术多深，但需要动脑子。
第三步：让理解“被看见”
建议开发在提交AI生成的代码时，加注释写清楚“为什么这么写”：
这个注释的价值在于：倒逼开发去理解代码；让审查者能验证理解是否正确；让未来的维护者能看懂这段代码。
第四步：用事故推动制度
当AI代码出了问题，不做简单归咎，而是追问：
这段代码属于哪个等级？当时的规则允许用AI吗？
如果允许，开发有没有认真思考过那几个核心问题？
如果不允许，为什么还会出现在代码里？
这个过程不是为了追责，而是为了让制度本身不断迭代，也让所有人意识到：AI代码出问题，值得被认真追溯，而不是悄悄修复就完事。
特别提醒：如果你身处弱矩阵团队，产品经理话语权有限，以上制度听起来很理想，但在弱矩阵组织（如产品经理无考核权、技术团队相对独立）中，你可能无法直接推动。这时候可以尝试：
借力：将风险包装成“线上故障隐患”或“客户投诉风险”，用业务视角说服技术负责人或上级。
找同盟：联合测试负责人、质量架构师，他们同样深受AI代码不可控之苦。
小切口试点：选择一两个靠谱的开发，在非核心模块试行分级规则，用实际效果证明价值。
向上管理：用一次真实事故（哪怕是预发环境的）作为案例，让管理层意识到“不设规则的长期成本”。
不要试图一步到位建立完整制度，哪怕只推动一条“AI代码必须加注释”的小规则，也是进展。
回到那个让我思考这个问题的最初场景：那个导致停摆的开发，后来怎么样了呢？
问题修复后，没有人追究根源，没有人反思流程，只是把这个故障当作一次“意外”。然后，下一段AI代码，下一个开发，下一次延期，正在来的路上。
这就是为什么我要写这篇文章。
AI编程工具确实强大，但它不会让一个糟糕的流程变好，反而会加速它变得更糟。在老系统里，每一行AI生成的、无人理解的代码，都是在给未来的自己埋雷。
我们需要的不是更聪明的AI，而是更清醒的人。AI可以写代码，但理解代码、承担责任、把控质量的，必须是人。
毕竟，代码可以AI写，但事故不能AI背。
