当开发依赖AI生成的黑箱代码在多租户SaaS系统中引爆故障，当技术债以AI的速度积累，产品经理该如何在效率与风险间找到平衡？

        本文通过真实案例剖析AI编程的隐形陷阱，并提供一套从源头治理的解决方案，帮助团队在AI时代守住代码质量的底线。———— / BEGIN / ————

        平台上有不少文章在讨论“产品经理要不要用AI写PRD”，但我今天想聊的，是另一个更隐蔽也更棘手的问题：当你的开发在用AI写代码，而你对代码质量开始失控时，该怎么办？

        需要说明的是，这不是在否定AI编程工具，更不是在指责所有用AI的开发——

        大多数开发使用AI是理性的、有判断力的。但作为产品经理，我在日常协作中观察到了一些值得警惕的现象，想分享出来，和大家一起探讨。

        “又延期了。”这已经是这个版本第三次调整上线时间了。

        原因说起来有点讽刺——一个开发用AI写了段代码，单租户跑得挺顺，一上线就被多租户的真实流量打垮，整个服务停了一上午。

        那个开发事后自己也说不清代码的核心逻辑是什么。他只是把需求“喂”给了AI，代码能跑通，就提交了。

        这是一个运行了多年的SaaS老系统，代码库里塞满了十年来的业务逻辑和“特殊处理”。

        而AI编程工具，正在悄悄变成一个陷阱——看起来能提效，实际上正在往老系统里埋下一颗又一颗定时炸弹。

        作为产品经理，我对最终结果负责，却无法直接控制代码的生产过程。

        眼睁睁看着质量下滑、节奏被打乱，却有一种又着急又使不上力的感觉。

        根源在哪？不是AI不行，而是我们从来没有从源头上为它划定边界。

        0→1的浪漫与1→n的现实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使用规则：第二步：给开发者设门槛使用AI之前，开发人员应该能够回答几个问题：这段代码的核心逻辑是什么？

        （能不能用一句话讲清楚）它和我们现有的业务规则怎么对应的？

        （对应需求文档哪一条）如果数据量变成现在的10倍，它会出问题吗？

        （有没有考虑边界）多个人同时用，它会冲突吗？（有没有并发隐患）如果这段代码出问题，最坏情况是什么？

        （能不能承受）如果一个开发答不上来，说明他可能没有真正理解这段代码在干什么。

        这个清单不需要技术多深，但需要动脑子。第三步：让理解“被看见”建议开发在提交AI生成的代码时，加注释写清楚“为什么这么写”：这个注释的价值在于：倒逼开发去理解代码；让审查者能验证理解是否正确；让未来的维护者能看懂这段代码。

        第四步：用事故推动制度当AI代码出了问题，不做简单归咎，而是追问：这段代码属于哪个等级？

        当时的规则允许用AI吗？如果允许，开发有没有认真思考过那几个核心问题？

        如果不允许，为什么还会出现在代码里？这个过程不是为了追责，而是为了让制度本身不断迭代，也让所有人意识到：AI代码出问题，值得被认真追溯，而不是悄悄修复就完事。

        特别提醒：如果你身处弱矩阵团队，产品经理话语权有限，以上制度听起来很理想，但在弱矩阵组织（如产品经理无考核权、技术团队相对独立）中，你可能无法直接推动。

        这时候可以尝试：借力：将风险包装成“线上故障隐患”或“客户投诉风险”，用业务视角说服技术负责人或上级。

        找同盟：联合测试负责人、质量架构师，他们同样深受AI代码不可控之苦。

        小切口试点：选择一两个靠谱的开发，在非核心模块试行分级规则，用实际效果证明价值。

        向上管理：用一次真实事故（哪怕是预发环境的）作为案例，让管理层意识到“不设规则的长期成本”。

        不要试图一步到位建立完整制度，哪怕只推动一条“AI代码必须加注释”的小规则，也是进展。

        结语：AI是副驾驶，不是代驾回到那个让我思考这个问题的最初场景：那个导致停摆的开发，后来怎么样了呢？

        问题修复后，没有人追究根源，没有人反思流程，只是把这个故障当作一次“意外”。

        然后，下一段AI代码，下一个开发，下一次延期，正在来的路上。

        这就是为什么我要写这篇文章。AI编程工具确实强大，但它不会让一个糟糕的流程变好，反而会加速它变得更糟。

        在老系统里，每一行AI生成的、无人理解的代码，都是在给未来的自己埋雷。

        我们需要的不是更聪明的AI，而是更清醒的人。AI可以写代码，但理解代码、承担责任、把控质量的，必须是人。

        毕竟，代码可以AI写，但事故不能AI背。———— / E N D / ————本文来自公众号：雨柒 作者：雨柒