兄弟们，最近几个月，说是“vibe coding”的时代也不夸张。我身边不少团队，包括我自己在内，都在用 AI 辅助的方式赶进度：写需求、补测试、生成 CRUD、调样式，AI 全都包了。你可能会说，这不是效率神器吗？但等到真要上线、要 review、要排查线上问题的时候，大家的表情都凝固了——那一段段看起来没什么毛病、跑起来也挺正常的代码，到底是怎么工作的？如果它出了问题，我改哪里？如果它依赖了某个隐藏状态，我碰一下会不会炸？
这就是“代码黑盒”的真实处境。AI 帮你把代码写完了，但它没有把“为什么这么写”的意图一起交付给你。你接手的是一个能跑、但你不完全懂的系统。这篇文章要聊的，就是 vibe coding 之后，我们这些开发同学到底应该做哪几件事，才能把黑盒重新变回白盒。内容不绕弯子，全是实操层面的动作：从盘点黑盒范围、补测试、做静态分析，到渐进式重构和问题排查。适合正在用 AI 写代码、但心里隐约知道“这代码我不能一直不懂”的开发者，也适合团队里刚经历过一波 AI 高产、马上要做代码治理的同学们。
1. 先搞清楚你的黑盒有多大
1.1 黑盒是怎么形成的：vibe coding 的天然产物
理解黑盒之前，先得理解 vibe coding 这类工作方式的底层逻辑。你用自然语言描述需求，AI 生成代码，你验证“好像能跑”，然后提交。这个过程里，人和代码之间的关系发生了本质变化：以前是我们写代码，思路全在脑子里；现在是 AI 写代码，思路在模型权重里。结果就是，代码的“设计意图”严重缺失。
AI 生成代码有几个天然倾向，我观察下来非常明显。
第一，局部正确，全局混乱。AI 擅长让单个函数看起来逻辑完整，但函数之间的调用关系、数据流向、依赖边界，它并不关心。你让它生成一个订单模块，它会很贴心地给你写订单创建、订单查询、订单关闭三个接口，但三个接口相互之间怎么共享状态、谁负责事务、谁清理过期数据，往往一团乱麻。
第二，极度缺乏防御性编程。AI 生成代码的目标是“满足 prompt 描述的行为”，不是“应对所有异常”。所以你翻 AI 写的代码，经常会看到裸奔的取值操作——obj.a.b.c 一路点下去，没人判空；read 文件没有 finally 关闭；发请求没有 timeout。这些在 demo 场景全都能跑，但在生产环境都是暗雷。
第三，重复远大于复用。AI 没有全局记忆，同一个项目里你在两个地方让 AI 生成两个功能，它大概率会生成两份很像但又不完全一样的代码。改了一个 bug，另一个还在。
这三个特征叠加起来，就是黑盒：你不知道边界在哪，不知道隐患在哪，也不知道哪份代码和哪份代码是“双胞胎”。所以治理黑盒的第一步，不是急着改代码，而是先搞清楚它有多大、长什么样。
1.2 黑盒盘点：别急着改代码，先做一次“面积测绘”
面对一坨 AI 生成代码，我强烈建议先做一次“黑盒面积测绘”，不是凭感觉，而是用工具和操作把范围圈出来。
第一步，拉 git 历史，识别 AI 提交的特征。AI 辅助写代码的提交信息通常有固定套路，比如“Implement feature X”、“fix: minor issue”、“refactor: improve readability”这种万能句式。你可以先git log --oneline --stat把所有近期提交过一遍，把 commit message 明显是 AI 风格的提交标出来，再git diff看一眼改动规模。如果某个提交一次性新增了上千行，那基本可以断定是 AI 主力输出，这块区域就是黑盒候选区。
第二步，看依赖图。这个太重要了。我常用的做法是跑 dependency-cruiser 或者 CodeScene 这类工具，把模块之间的依赖关系画出来。画完之后你会立刻发现，某些模块的扇入特别高——就是说很多人依赖它，但它的实现是 AI 生成的，没人真正看懂。这种模块是黑盒里的重灾区，一旦出问题，波及面巨大。
第三步，统计 AI 代码占比。这事操作上很难 100% 精确，但你不需要精确，你只需要相对值。可以从几个维度估算：新增文件数、跨模块 import 数、TODO/FIXME 注释占比、函数平均行数。函数平均行数超过 50 行的函数，大概率藏着多语义混在一起的问题——AI 特别容易这么干，一个 generateReport 函数里既查库、又算统计、还发通知，清清楚楚的一件事被揉成一团。
测绘完，你会拿到一张“黑盒地图”。接下来就是排优先级，不用全处理，但得知道先处理哪个。
1.3 优先级矩阵：先处理哪些黑盒
黑盒不是把所有代码重写一遍，时间和风险都不允许。我自己用的是“风险 × 变更频率”的优先级矩阵。
风险维度看三件事：这个模块挂了会不会影响线上核心链路？它是否处理资金、用户隐私、数据一致性这类高敏感数据？它有没有外联依赖，比如第三方 API、数据库、消息队列？
变更频率维度看另外三件事：这个模块最近有没有频繁改来改去？它是不是多个功能都要动的公共依赖？它有没有连带的测试在频繁失败？
两个维度交叉下来，你会得到四类：高风险高变更的第一优先，高风险低变更的第二优先，低风险高变更的第三优先，低风险低变更的可以先放着。这样做的好处是目标明确，不会陷入“AI 写的代码我全都要重写”的绝望感——那种心态只会让你直接放弃治理。
我实际处理过一个案例：团队里有个内部工具站，AI 生成的一个用户登录模块，每天被十几个功能调用。函数写得又长又绕，会话状态管理还用了两个全局变量。按矩阵排，它就是那个必须最先处理的高风险高变更模块。后来我们花了两个迭代周，测试补上、逻辑拆开、全局变量干掉，整个站的稳定性肉眼可见地上升。
搞定范围和优先级，才是真正动手的开始。
2. 用测试当撬棍，把黑盒撬出一条缝
2.1 测试前置：先补行为测试，别急着补单元测试
很多人拿到黑盒代码，第一反应是“我要重写它”。我的建议完全相反——先别动实现，先补行为测试。行为测试也叫特征测试，核心思路是：把代码当前的行为用测试固化成一套“快照”，确认它跑出来的结果是稳定的。这样后续无论你是重构、修 bug、还是拆模块，都有一个安全网兜底。
具体做法很简单。挑一个黑盒函数，准备一组输入，记录它现在的输出值，写进测试断言里。比如一段 AI 生成的订单折扣计算函数，不管你觉得它逻辑对不对，先用几个典型输入把输出固化下来。这里的关键是“当前行为优先于正确行为”：你先记录它现在怎么表现，分析它还会不会出问题，而不是一上来就按你脑中的“正确逻辑”改。因为改早了，万一 AI 代码里某些行为是其他模块依赖的，你顺手一改，整个链路就炸了。
补行为测试有顺序讲究。按我之前排的优先级矩阵来：先补高风险的，再补高频变更的。高风险模块的行为测试优先级永远最高。补测试本身不要追求 100% 覆盖率，抓住三条主线就够用了：正常路径、异常路径、边界条件。
正常路径就是主流程能跑通；异常路径是传入非法参数、依赖服务挂掉、数据为空；边界条件是极限值、空数组、超大数字、超时场景。这三条线跑下来，黑盒在你眼里已经从一团迷雾变成了一个具体的身影，你大概知道它会干什么、怕什么。
2.2 用测试反向“审讯”代码：它到底干了什么
补完行为测试，接下来是理解黑盒最有效的一步：用测试反向审讯代码。这个思路很多人想不到，但它极其好用。
具体操作是，你写一个小测试，调用黑盒函数并打印中间状态——注意不只是最终返回值，还有它修改过的外部状态、依赖对象的调用次数、出入参的细节——然后运行测试，观察输出。这本质上是给黑盒装上各种仪表盘，让它自己暴露行为。
我举一个真实的例子。我接手过一段 AI 生成的 Python 代码，作用是把一批 CSV 文件同步到数据库。表面上看起来功能正常，但我写了个测试打印每次同步前后的缓存内容，立刻发现了一个隐蔽问题：这个函数每次同步前都会清空一个全局缓存变量，但清空之后如果同步失败，缓存就永远为空了。下次再同步时就拿不到增量数据。这个行为在没有测试观测的情况下，可能要等线上数据异常才能暴露。测试一跑，黑盒的“内脏”就摊开在你面前了。
写这种测试的时候要带上“恶意”：试探它不设防的地方，给它无效输入、给它并发请求、给它超大 payload，观察它的反应。这个阶段你不需要写优雅的断言框架，用最简单的 print 甚至临时 console.log 都行。目标不是留下长期测试，而是短期快速理解。理解了，后续再决定哪些行为测试要转正为长期回归测试。
2.3 测试工具选型与覆盖策略
工具选型，不用整花活，按语言生态选主流就行。JavaScript/TypeScript 这边，Vitest 和 Jest 二选一，测试运行和断言都够用，覆盖率用 Vitest 自带的 coverage 功能，底层是 v8 或 istanbul。Python 就用 pytest，覆盖率用 coverage.py。Go 的标准库 testing 已经够稳，覆盖率用自带的 -coverprofile。
工具归工具，这里我想重点泼一盆冷水：覆盖率数字是骗人的。行覆盖率高不代表行为覆盖率高。AI 生成的代码普遍有一个特征——单行代码逻辑密度高，一行里塞了多个副作用。这种情况下，即使行覆盖率 90%，你真正测到的行为可能只有 50%。比如一行代码if user and (user.role in roles or user.is_admin) and cache.get(user.id):里面藏了四个条件分支，行覆盖只告诉你这行执行过，没告诉你有几个分支没走到。
所以我的建议是，补测时看分支覆盖率而不是行覆盖率。V8 和 Istanbul 都支持分支覆盖率统计，pytest-cov 也有 branch 选项。你的目标是把高风险模块的分支覆盖率打到 70% 以上。达不到没关系，那个没覆盖到的分支就是你后续要重点人工检查的地方——它往往是 AI 藏在角落里的行为盲区。
测试撬开黑盒之后，下一步是用工具和走读做一次全面体检。
3. 静态分析与走读：给黑盒做一次体检
3.1 静态分析工具：质量红绿灯
行为测试帮你看懂黑盒“现在做了什么”，静态分析则帮你看懂黑盒“整体健不健康”。这俩是不同维度，不能互相替代。
静态分析工具我分三个层级来选。第一层是 lint 规则，ESLint 和 Pylint 这类，抓的是代码规范问题——未使用变量、隐式类型转换、过深嵌套、可疑的分号用法。AI 生成的代码经常在这里栽跟头，比如报错“Expected catch”或“unnecessary 'await'”之类的，你表面看不出来，但 lint 会直接标红。上线前把这些红标清干净，能避免大量低级 bug。
第二层是复杂度度量工具。SonarQube 或 CodeClimate 可以算圈复杂度、认知复杂度、重复代码率。AI 生成代码的圈复杂度往往高得吓人，一个函数三四十行嵌套五层 if，认知负担极大。Sonar 里有个“Code Smell”指标，我通常要求高风险模块的 Code Smell 数量清零，做不到就拆函数。
第三层是安全与数据流分析。CodeQL、Semgrep、Bandit 这类工具能追踪数据流，发现“用户输入 → 危险函数”的污染路径。这一层对黑盒尤其重要，因为 AI 生成的代码经常无条件信任输入数据，甚至会把外部输入直接拼进 SQL 或命令里。这种问题靠人眼翻代码很难发现，但 Semgrep 一条规则就能扫出来。
静态分析工具输出的是一份问题清单，但它不会告诉你“哪里最重要”。所以下一步需要人工走读来釜底抽薪。
3.2 人工走读的“聚焦点”：高危模块优先
人工走读不是把黑盒代码从头到尾读一遍，那样既低效又容易走神。我建议按聚焦点来读，每个聚焦点专门查一类问题。
第一个聚焦点是 IO 边界。文件读写、网络请求、数据库操作，这些地方是资源泄漏和异常吞没的重灾区。AI 生成代码里最常见的就是 requests.get 开了连接不关、文件 open 没有 finally、数据库连接拿到就忘。走读时看到 IO，先问三个问题：连接关不关？超时设没设？异常怎么处理？
第二个聚焦点是状态变更。全局变量、缓存、数据库写操作，这些是黑盒里最危险的存在。AI 生成的代码特别喜欢搞隐式状态，某函数读了一个外部变量，另一个函数默默改了这个变量，两个函数之间没有明确的调用关系，但运行时互相影响。走读时看到全局变量或跨函数共享的一个对象，就要重点标记。
第三个聚焦点是并发和异步。如果黑盒代码里面有异步回调、线程池、任务队列，就要特别小心竞态条件。AI 经常不考虑并发场景，比如先读后写不做原子操作、异步回调里直接改共享变量。这种问题在测试环境单线程跑完全正常，一上生产就偶发崩。
走读的时候，手里拿一支笔（或者开一个白板），一边读一边画调用关系图和关键数据流。画图不追求规范，主要让自己看清谁调谁、数据怎么流。我觉得，人工走读的价值不是发现所有 bug，而是建立你对黑盒的“心理模型”——以后出问题，你脑子里能立刻浮现出它大概在哪个环节挂了。
3.3 让 AI 自己解释？可以，但要带证据
既然代码是 AI 写的，那让 AI 自己解释是不是最高效？这事我干过很多次，有效，但必须带证据验证。
我的做法是直接问：“请逐行解释这段代码的逻辑，并指出它可能存在的三个风险点。”AI 给出的解释往往相当流利，看起来头头是道。但这里有个致命陷阱：AI 的流利程度与准确性不挂钩。它可能基于自己的训练知识猜测代码意图，猜错了一样能编出一个自洽的故事。如果你没有预先建立自己的理解，就很容易被它的解释带到沟里。
所以我的结论是：AI 解释只能作为线索，不能作为结论。收到解释之后，你要做两步验证。第一步，对照你刚才走读时画的调用关系图和数据流图，看 AI 说的和实际代码路径一致不一致。第二步，拿 AI 指出的风险点去跑你写的那些边界测试，看问题是否真的存在。我遇到过几次 AI 一本正经地指出了一个“风险”，但那个风险实际不存在的情况；也遇到过它根本没提某个风险，结果我测试一测就炸的情况。
简单说，AI 解释的角色是“保安”，帮你快速找到可疑方向，但最终你要自己动手核实现场。黑盒化是 AI 生成的，白盒化只能靠你的工程判断。
工具体检和走读之后，你对黑盒已经有相当程度的理解了。这时候才轮到重构。
4. 渐进式重构：一步步把黑盒拆成白盒
4.1 夹缝手术：先做不改变行为的小重构
黑盒代码的重构，最忌讳的就是“推倒重来”。AI 生成的代码再乱，也是经过测试验证过行为的。你一推倒，行为就变了，新的 bug 可能比旧 bug 还多。所以我的路线是渐进式重构，先做不改变可观测行为的小手术。
第一步是改名。把 AI 起的那些模糊的函数名、变量名替换成能真实表达语义的名字。AI 特别喜欢起 generateData、processInfo、handleClick 这种万事通名字。改名不改变行为，但能大幅降低你“猜它在干什么”的认知成本。注意在整个项目里全局搜索引用，用 IDE 的 rename 功能，不要手工替换。
第二步是提取函数。把之前“单函数多语义”的臃肿函数拆成多个语义单一的小函数。提取的关键是保持行为不变，拆之前和拆之后跑同一套测试，确保输出一致。我之前拆过一个链上风控函数，从一个 200 行的单一函数拆成了 7 个 20-30 行的小函数。拆完再看逻辑，每一步干什么一目了然。这步操作风险很低，因为提取操作大多可以通过 IDE 自动完成，不会改变函数调用关系。
第三步是删除死代码。AI 生成代码时经常留下一些“看着有用但没人调”的函数和分支。删死代码也会带来一点点风险：有些代码看似没被调用，但可能通过反射、钩子、配置注入的方式被隐式调用。所以删除之前，先全局搜索引用，确认没有动态调用路径。
这些夹缝手术做完，黑盒的整体结构已经从“一团乱麻”变成“有脉络”，但行为本身还没被加固。下一步要做的，是把行为用契约钉死。
4.2 用契约把行为钉死：类型、断言、守卫
黑盒代码最怕的就是“行为飘忽”——同一个函数，传不同的类型、不同的数据，走完全不同的路径，你很难预测。解决办法是引入契约层，把输入输出边界卡死。
类型系统是第一层契约。如果是 TypeScript 项目，把 strict 模式打开，给 AI 生成的函数补上明确的参数类型和返回类型。你不需要一次完成，可以按模块逐步迁移。Python 项目可以用 type hint，Go 项目本身类型就强，但也需要检查 AI 是否用了 interface{} 逃逸类型约束。类型系统能编译期干掉一大批“传错参数导致运行期爆炸”的问题。
运行时校验是第二层契约。AI 生成的代码经常对一个进来的 JSON 对象直接点属性，完全不校验结构。用 zod（TS）或 pydantic（Python）在校验层把输入数据 shape 卡死，就能把“脏数据漂到业务逻辑深处”的概率降到最低。我曾经处理过一个 AI 生成的支付回调处理函数，没有加 schema 校验，上游回调里少传一个字段，代码直接抛 typeError 把整个 worker 打崩。加了校验之后，先验格式再走业务逻辑，这类问题基本绝迹。
断言是第三层契约。在关键函数入口和出口加上防御性断言，不让错误状态继续传播。写断言的时候有个原则——断言的是“这时它绝不应该发生的条件”，例如“余额不能为负”、“事务完成后连接必须关闭”。
契约层的核心价值不只是防 bug，更关键的是它让黑盒代码的“行为边界”变得可预期。当你把输入输出约束清楚了，黑盒其实已经黑不了了——你知道它吐出来的一定符合某种形状，进来时也必须是某种形状。
4.3 拆模块边界：一次只拆一层
契约加固完成之后，才是真正能安全动大手术的时候——拆模块。这一步的目标是把 AI 生成的那些“黏糊糊”的模块依赖关系理顺。
我先说一个原则：一次只拆一层。比如 A 模块里面直接调用了 B 模块的内部方法，你要做的不是一次性把 A 和 B 全拆开，而是先在 A 和 B 之间加一层接口。这层接口可以是一个抽象类、一个函数句柄或者一个独立的 service 对象。加了这层之后，A 不再直接依赖 B 的内部实现，而是依赖接口。这样即使 B 后续被重构，只要接口不变，A 就安全。
这种思路借鉴的是 Strangler Fig 模式（绞杀者模式）——不一次性推翻，而是在旧系统旁边慢慢长出新结构，让旧结构逐步被取代。AI 项目里尤其适用。比如某个 AI 生成的模块内部耦合了大量全局状态，你直接改很难，但你可以先加一个独立的配置管理服务，把那些全局变量统一收编，再慢慢迁移调用方。
每拆一层，跑一遍全量测试（包括之前补的行为测试和契约校验），确认绿了再继续下一步。如果哪个环节红了，立刻定位是行为真的变了还是测试断言本身有问题，不要试图蒙混过关。
拆模块的核心逻辑是：“先用结构和契约圈住行为，再逐步释放复杂度”。等你拆到模块边界清晰、依赖方向单一、每个函数职责明确的时候，黑盒就已经完全转白了。
当然，理论和实操总有距离。最后分享一些我实际踩坑的记录，可能会帮你少走弯路。
5. 黑盒代码的常见坑与排查实录
5.1 常见问题速查表
AI 生成黑盒代码的问题有很强的共性，我整理了一张速查表，按频率排序，你遇到疑难杂症时先对照这张表自查。
| 症状 | 常见根因 | 排查方向 |
|---|---|---|
| 线上 CPU 持续飙高 | 循环没有推进条件或递归无终止 | 查 while/for 循环体是否更新了循环变量，查递归基线条件 |
| 内存涨涨涨 | 连接/文件/句柄未关闭，或缓存无淘汰机制 | 搜 open/getClient/createPool 等创建资源点，看 release/close 路径 |
| 偶发数据不一致 | 共享可变对象被多个异步回调同时修改 | 查全局对象、闭包共享变量，加日志记录每次写入的来源 |
| 接口时快时慢 | 隐式串行请求或超时设置不合理 | 看是否每个请求都新建连接，查 timeout 参数 |
| 功能对但结果不对 | AI 把你没要求的分支也实现了 | 走读 if/else 分支，用行为测试打印实际输出路径 |
| 诡异报错：undefined is not a function | 入参结构校验缺失，AI 代码直接点深层属性 | 用 schema 校验入参，查第三方接口的返回结构 |
这张表最大的价值不是给你答案，而是告诉你“先把注意力放哪里”。黑盒问题千奇百怪，但绝大多数都落在资源管理、状态污染、条件分支这三个大坑里。
5.2 排查黑盒的实用武器
真上了生产，黑盒代码出问题的时候往往是半夜，你没有从容走读的时间，得有一套快速定位的武器库。
第一个武器是二进制注释法：把代码按功能分成几段，用注释临时屏蔽一段，跑一遍测试或请求，看问题还在不在。这种二分治的方法能在五分钟内把嫌疑范围缩小到一段代码。AI 生成的代码很适合这种玩法，因为它本来功能分段就不清晰，你刚好借这个机会理清分段边界。
第二个武器是 git bisect。AI 提交的代码经常一提交就是一堆功能，问题到底在哪个提交引入的，人眼很难找。git bisect 是一个二分查找命令，它会自动帮你定位到“第一次引入问题”的那个提交。这个方法能直接解决“昨天还是好的，今天怎么就挂了”的千古难题。
第三个武器是增强日志。黑盒代码最缺的就是日志，AI 不会自动给你加上完整的上下文日志。排查问题时，在关键路径上加临时日志，打印一下入参、出参、耗时、异常堆栈，然后复现问题。日志打完，分析完，一定要把临时日志清理掉，不然日志量会把磁盘撑爆。
武器不是越多越好，关键是“每次只用最合适的那一个”。排查黑盒的核心思路永远是：缩小范围、复现问题、定位根因、补上回归测试。顺序不能乱，一乱就容易陷入“改一处、坏一处、再改回”的循环。
5.3 踩坑记录：AI 代码的三个经典现场
我在实际工作中处理过不少 AI 代码引发的生产事故，拿三个最经典的出来给大家当反面教材。
第一个是死循环事故。一次线上服务 CPU 被打满，排查发现是一段 AI 生成的 Python 后台任务。它写了个while not is_time_to_stop():的循环，但循环体里根本没有更新任何会改变is_time_to_stop()返回值的状态变量。这段代码在人眼走读时真的很隐蔽，逻辑写成“判断后睡眠”，但判断条件永不变化，就死循环了。我们后来用 py-spy dump 出线程栈才定位到。这个教训就是：看 AI 生成的回调函数、循环体，务必检查“推进条件”。
第二个是连接池泄漏事故。AI 生成的爬虫任务代码，用 requests 库每次请求都初始化一个新的 Session 对象。看起来网络请求都能正常返回，但 Session 底层创建的连接池从不释放，跑了大概一周，内存暴涨到 OOM。这个问题的奇葩之处在于——单次请求看起来性能还挺好，只是资源全埋在临时对象里了。排查方式也是靠内存分析工具 htop 和 pympler 一起用，才定位到连接池上。从那以后，我给团队定了规矩：AI 生成的代码如果涉及创建连接、客户端、上下文管理器，必须人工审查资源释放路径。
第三个是全局状态事故。AI 生成的一个用户画像模块，用一个全局 dict 做缓存。测试环境单用户跑，完全没问题。上线后并发一上来，多个进程同时去写这个 dict，数据互相覆盖、脏读频发。更坑的是，AI 代码里还用了if key not in cache:这种“先读后写”的非原子操作，竞态窗口极大。这个问题的排查花了整整两天，因为错误是偶发的、不是必现的，各种日志看起来都是正常的。最后是用并发压测脚本，加多线程反复调用并打印中间状态，才锁定到全局缓存上。
这些案例不是 AI 不行，而是我们“没有对 AI 生成的代码做工程化兜底”。vibe coding 的本质是把体力活外包给 AI，但“工程质量”这份脑力活，永远得自己扛。
最后说点个人的体会。踩过这些坑之后，我现在习惯给每个 vibe coding 模块设一个“毕业标准”：行为测试补上、分支覆盖过 70%、静态分析主要告警清零、人工走读确认关键路径、契约校验已加固。达不到标准，这模块就算“没写完”，不能合入主分支。听起来繁琐，但其实也就是多花两三天。相比于线上事故之后熬夜排查、通宵救火，这点成本简直太过划算了。
所以，如果你现在正接手一堆 AI 生成的代码，心里发虚是正常的。不用害怕，也不用急着推翻重来。按照今天的思路：先测绘黑盒地图，用测试把它撬开，用静态分析和走读做体检，再用渐进式重构一步步拆白，最后用一套排查工具兜底。每个步骤都不需要你变成天才，只需要你踏踏实实做一轮工程治理。等这套流程走完，你会发现自己对项目的掌控感，比 vibe coding 之前还强。那种“代码虽然是 AI 写的，但我比它还懂它”的感觉，确实值得体验一下。
