最近，我又完成了一次接近“全 Vibe Coding”的尝试。

在这个项目里，我只负责需求和最终结果：

  • 不看代码；
  • 不看目录结构；
  • 不持续理解内部架构；
  • 让 AI 自己实现、修复 Bug 和调整设计。

这正是我之前一直在尝试的方向：如果代码和内部架构可以由 AI 快速重写，人是否可以只掌握需求、契约、风险与最终验收？

但这次实践再次暴露了一个问题。

它不是某个功能没有实现，也不是某条测试没有通过，而是整个系统在几天内沿着一个逐渐错误的结构继续生长，而我直到问题已经变得明显以后才介入。

一个最初合理、后来逐渐错误的文件

项目早期需要多个 EXE 交换状态。

AI 选择了一个简单方案：使用同一个文本文件作为交互媒介。各个 EXE 从文件中读取状态，也把自己的状态写回文件。

在最初阶段，这个设计可能是合理的：

  • EXE 数量少；
  • 状态简单；
  • 并发要求不高；
  • 不需要复杂的一致性；
  • 实现速度快；
  • 能够尽快验证产品方向。

但之后需求不断细化，新的功能和 Bug 持续出现。越来越多的 EXE 开始依赖这个文件，越来越多的状态需要被读写，冲突也开始频繁发生。

AI 对每一次问题都进行了修复：

  • 增加等待；
  • 增加重试；
  • 调整读写顺序；
  • 增加特殊判断；
  • 增加兼容逻辑；
  • 在已有机制上继续缝补。

每一次修复可能都能让当前问题暂时消失，但系统的底层方向没有被重新审视。

直到四五天后我主动介入，才发现这些 Bug 的共同根因并不在某一段代码，而在于：

这个文本文件已经从一个简单的状态载体，逐渐变成了所有 EXE 的通信、同步和协调中心。

最初适合快速验证的设计，已经不适合后来增长出来的需求。

问题不只是 AI 选错了架构。

更重要的是：在架构成立的前提已经逐渐失效之后，AI 仍然把每一次新冲突理解为一个孤立 Bug，并继续在原有路径上修复。

系统在局部上不断恢复可用，在整体上却越来越难以维护。

前三次思考还缺少了什么

在之前的实践中，我的认识经历了几次变化。

最开始，我尝试不再掌握全部架构，只掌握：

  • 产品应该表现成什么样；
  • 哪些行为必须成立；
  • 哪些数据不能丢失；
  • 哪些风险不能接受；
  • AI 是否有权修改某项契约。

内部实现则交给 AI。

之后，在自动化测试框架的设计中，我进一步区分了 AI 与确定性流程：

  • AI 负责理解、泛化、分析和提出建议；
  • 传统自动化负责执行、断言、记录和复现；
  • Harness 负责持续产生可观察、可定位的证据。

再后来，我发现契约本身也会膨胀，于是继续拆分：

  • 人维护产品承诺与不可接受的风险；
  • AI 和工具维护当前机器现实；
  • Harness 维护证据；
  • Git、Issue、日志和生产数据维护历史。

这些方向仍然成立。

但共享文本文件的经历说明，其中还缺少一个问题：

即使人掌握正确性与风险，如果人完全无法看见系统正在形成什么结构，也可能无法及时意识到自己应该介入。

测试可以告诉我当前行为失败了。

Observer 可以告诉我某个 EXE 没有得到正确状态。

日志可以告诉我文件读写发生冲突。

但这些证据并不会自然告诉我：多个看似独立的 Bug，其实都围绕同一个逐渐膨胀的协调机制发生。

这不是单纯的测试覆盖问题，而是架构认知出现了延迟。

AI 自己 Review 架构是否足够

一种自然的改进方式是：让 AI 更频繁地 Review 自己的架构。

例如每次需求变化后，让另一个 Agent 检查：

  • 当前设计是否仍然适用；
  • 是否出现新的共享状态；
  • 是否有模块承担了过多职责；
  • 是否应该停止修补并进行重构。

这可能有帮助。

但我目前仍然不认为它足以成为唯一方案。

AI 对架构的判断仍然受限于：

  • 它是否理解某项兼容性真正有多重要；
  • 它是否知道未来需求可能怎样变化；
  • 它是否正确理解了产品约束；
  • 它是否在根据现有实现合理化已有设计；
  • 它是否与实现 Agent 共享了同样的盲区。

即使增加多个 Reviewer，也不能保证 AI 一定能够提前判断某个设计已经不再合理。

很多时候，真正触发人类警觉的可能仍然是经验：

修复了 A Bug，为什么突然又出现了 B Bug？

或者：

为什么这个区域最近总是在修改？

又或者：

为什么一个看起来很小的需求，现在会影响这么多功能？

这些直觉暂时很难完全交给 AI。

所以我开始考虑另一个方向：不是要求 AI 自动判断所有架构问题，而是让人在需要介入时，能够非常快速地重新理解当前架构。

从持续掌握，转向随时恢复掌握

传统软件开发里，开发者通常通过亲手编写代码，持续维护一个关于系统的心智模型。

因为经历了每一次修改，所以能够大致知道：

  • 模块之间如何连接；
  • 数据如何流动；
  • 某个设计为什么存在；
  • 一个改动可能影响哪里。

但在 Vibe Coding 下，AI 的实现速度可能远远超过人的认知吞吐量。

要求开发者实时跟上全部结构变化，最终可能意味着：AI 虽然加快了编码，却没有真正降低人的工作量。人只是从亲自写代码，变成了不断追赶 AI 产生的代码。

因此，我现在更倾向于另一个目标：

人不再持续掌握完整架构，但系统必须保证人能够在需要时快速恢复局部掌握。

这两者差别很大。

我平时可以不知道某个模块内部经过了多少次重构，也不需要了解每一个类为什么存在。

但是当 A Bug 修复后出现 B Bug，我应该能够快速回答：

  • 两个 Bug 分别经过了哪些区域；
  • 它们是否共享某个节点或状态；
  • 相关区域最近发生过哪些结构变化；
  • 新增了哪些依赖、读写者或兼容层；
  • 当前的数据流和控制流究竟是什么；
  • 如果继续深入，应该从哪里开始看。

这需要的不是一份静态架构文档，而是一张持续跟随代码变化的大型结构图。

这张图不是架构裁判，而是系统坐标系

我并不期待这张图自动告诉我：

  • 哪个模块最重要；
  • 哪个设计一定错误；
  • 哪个区域必须立即重构；
  • 当前架构还能支撑多少未来需求。

这些判断仍然可能需要人的经验、产品理解和风险意识。

结构图首先需要回答的是：

系统现在是什么形状，某个问题发生在哪里，它与周围什么东西连接？

因此，它更像一套坐标系统。

当开发者的警觉性被异常触发后，可以沿着这套坐标快速进入相关区域，而不需要重新阅读整个项目。

一张真正适合 Vibe Coding 的结构图，可能需要具备几个特点。

1. 从系统级结构开始

最顶层优先展示：

  • EXE、进程和服务；
  • 主要功能模块；
  • 文件、数据库、配置与共享状态；
  • HTTP、Pipe、Socket、消息和文件等通信通道；
  • 外部设备与外部系统。

而不是一开始就展示所有类和函数。

2. 支持逐层放大

它应该像地图一样工作：

  • 系统级：有哪些程序、服务和存储；
  • 进程级：某个 EXE 内有哪些主要模块；
  • 功能级：某条业务流程经过哪些组件；
  • 文件级：最终由哪些类和函数实现。

开发者只展开当前怀疑的区域。

3. 保持空间位置稳定

如果每次 AI 修改代码以后，整张图都重新排列，开发者就无法形成任何视觉记忆。

所以同一个模块应该尽量保持原来的位置，新模块在相关区域附近出现，模块移动、拆分和消失也应该留下可追踪的变化。

长期使用后，开发者应该逐渐形成一种“系统地理感”。

4. 能够比较时间和版本

只看当前架构是不够的。

真正重要的问题经常是：

从 A Bug 被修复，到 B Bug 出现之间，这个区域发生了什么？

因此需要能够比较：

  • 某个需求开始前；
  • AI 完成实现后；
  • A Bug 修复前后；
  • B Bug 出现时；
  • 两个 Git 版本之间的结构差异。

新增、删除或变化的节点和连接应该被清楚标出。

5. Bug、测试和 Commit 能够落到图上

点击一个 Bug、失败测试或 AI 任务时，图上应该能够高亮：

  • 修改过的区域；
  • 相关调用链和数据流；
  • 测试实际经过的路径；
  • 异常发生的位置；
  • 多个问题共同经过的节点。

这样，人可以直接看见 A Bug 和 B Bug 是否可能存在共同的结构原因。

6. AI 只解释当前选中的局部区域

AI 在这里仍然有价值。

但它不需要先替人判断整张图哪里最危险，而是在开发者选中一个区域后帮助：

  • 总结该区域的职责；
  • 解释连接为什么存在；
  • 整理最近的相关修改；
  • 还原某条状态流；
  • 找出可能遗漏的调用方；
  • 建议下一步应该查看什么证据。

也就是说，先由人决定关注哪里，再由 AI 帮助快速恢复理解。

Human Re-entry：让人重新进入架构

我暂时把这种能力称为 Human Re-entry。

它的目标不是让人持续 Review 所有 AI 代码，而是缩短下面这段时间：

从“我感觉这里可能不对”，到“我已经理解这个局部结构，可以作出判断”。

传统项目里，这个过程可能依赖开发者长期积累的记忆。

在全 Vibe Coding 项目里，这种记忆可能已经不存在，所以必须由工具帮助重新构建。

因此，结构图真正需要优化的指标可能不是“自动发现了多少架构问题”，而是：

  • 人需要多久才能定位相关区域；
  • 需要打开多少文件才能理解一条链路；
  • 能否看见多个 Bug 的共同节点；
  • 能否还原某个结构是怎样逐步形成的；
  • 能否在几分钟内决定继续修补还是重新设计。

AI Sentry：同一套系统也可以提高 AI 的警觉性

当结构图、Bug、测试、Commit 和运行记录已经连接起来以后，它也可以成为 AI Review 的基础。

但这时 AI Review 不再是一个完全独立的尝试，而是这套架构观测系统上的派生能力。

系统可以先用相对确定的信号发现值得关注的区域，例如：

  • 同一条路径在一段时间内关联了多个缺陷；
  • 同一个节点被连续高频修改；
  • 修复一个问题后，相邻路径快速出现新的回归；
  • 某个共享资源的读写者持续增加；
  • 一个很小的需求开始影响越来越大的范围；
  • 同一模块不断增加 retry、fallback、lock 和兼容分支。

这些信号并不能证明架构已经错误。

它们只需要表达：

这里可能值得重新看一眼。

达到默认阈值后，系统可以把一个有限的局部子图交给 AI，包括：

  • 最近相关的需求；
  • 几次 Bug 与修复；
  • 结构变化时间线；
  • 相关测试和运行证据；
  • 当前节点与周边节点的关系。

然后让 AI 回答更有限的问题：

  • 这些问题是否可能共享结构性原因；
  • 当前机制是否承担了越来越多职责；
  • 最近的修复是在消除根因，还是继续增加补丁；
  • 还缺少什么证据；
  • 是否值得由人介入检查。

我暂时把这种能力称为 AI Sentry。

它不是架构裁判，而是一个基于结构和历史进行守望的观察者。

同一套系统，两种介入方式

走到这里以后，我最初的两个方向实际上开始合并。

第一种方式是人主动介入：

  1. 人发现 Bug、回归或异常模式；
  2. 打开结构图；
  3. 定位相关区域；
  4. 恢复局部理解；
  5. 判断继续修补还是要求 AI 重构。

第二种方式是系统主动提醒：

  1. 系统持续记录结构变化与缺陷关联；
  2. 某些信号达到阈值；
  3. AI 对局部子图进行重点分析；
  4. 在图上标记值得关注的区域；
  5. 人决定是否真正介入。

两种方式共用同一个基础：

  • 当前系统结构；
  • 结构随时间的变化；
  • Bug、测试和 Commit；
  • 运行时证据；
  • 局部查询与解释能力。

所以最终可能只需要一个方向：

建立一套同时供人和 AI 使用的架构观测系统。

人使用它来快速恢复理解。

AI 使用它来提高警觉性。

不需要一个抽象的架构健康分数

我目前并不希望系统简单地给出：

  • 架构健康度 72 分；
  • 当前模块高风险；
  • 建议立即重构。

这种结论太容易掩盖真实信息，也容易让开发者产生虚假的确定感。

更有价值的可能是一组可以直接检查的事实：

Camera Discovery 链路最近 8 天修改了 6 次；其中 4 次经过 status.txt；该文件写入者从 1 个增加到 4 个；修复 A 后出现的 B、C 两个回归也经过这里。

人看到这些信息以后，可以自行判断是否需要进入结构图继续调查。

AI 也可以基于这些事实提出假设，但它的结论不应该覆盖事实本身。

一个尽可能克制的第一版

如果真的开始实现，我认为第一版不需要成为一个通用的软件架构平台。

它甚至可以只服务当前最熟悉的场景：一个包含多个 C# EXE、Windows Service、设备和本地状态的项目。

第一版只需要识别：

  • Project、EXE、Service；
  • 主要模块；
  • 文件、配置和数据库；
  • HTTP、Pipe、Socket 等通信关系；
  • 每个共享资源的读取者和写入者；
  • Git 版本之间的结构变化；
  • Bug、测试和 Commit 关联的区域。

然后提供：

  1. 一张稳定、可下钻的大型结构图；
  2. 两个版本之间的结构 Diff；
  3. 从 Bug 或测试跳转到相关子图；
  4. 选中局部区域后让 AI 进行解释；
  5. 根据简单阈值产生关注提醒。

它暂时不需要：

  • 自动决定架构好坏；
  • 支持所有语言和框架；
  • 生成完整架构文档；
  • 自动修改所有契约；
  • 用多个 Agent 对整个项目进行持续争论。

最重要的验证标准只有一个：

如果重新回放共享文本文件项目的历史，这套系统能否在 A Bug 修复后出现 B Bug 时，让我在几分钟内看见它们共同经过 status.txt，并理解这个文件已经从简单状态载体演变成通信枢纽？

如果能做到，它就已经开始解决真正的问题。

下一阶段需要继续验证的问题

这仍然只是一个新的方向，而不是最终答案。

接下来真正需要验证的可能包括：

  1. 自动生成的结构图是否足够准确，还是会产生新的错误认知；
  2. 图在持续变化时能否保持稳定的空间位置和节点身份；
  3. 如何把 Bug、测试、Commit 与具体结构区域可靠关联；
  4. 静态分析无法发现的动态调用和跨进程关系如何补充；
  5. 一张足够大的图如何避免最终变成无法阅读的“毛线团”；
  6. 默认阈值是否会产生过多误报和告警疲劳；
  7. AI 对局部子图的解释是否真的比直接阅读代码更快；
  8. 这套系统是否能够显著降低人重新取得架构理解所需的时间；
  9. 当人介入并要求重构后，图是否能够帮助验证结构是否真的得到改善；
  10. 最终哪些信息需要长期保存，哪些解释应该只在查询时即时生成。

目前的结论

经过这次实践，我不再认为选择只有两个：

  • 要么持续理解 AI 生成的全部架构；
  • 要么完全放弃架构，只看最终测试结果。

中间可能存在第三种状态：

人平时不需要跟上全部架构变化，但系统持续维护一张可以被查询、比较和下钻的机器现实地图；当异常触发人的警觉，或者结构信号达到阈值时，人和 AI 都能够基于这张地图重新进入相关区域。

这并没有让人重新接管所有实现。

它只是保留了一条重新取得理解的通道。

所以，Vibe Coding 下一阶段需要解决的，也许不是怎样让人永远跟得上 AI，而是：

当 AI 的开发速度已经超过人的认知速度以后，怎样让系统仍然保持可重新理解。

人不再持续拥有全部架构。

但人必须能够在真正需要的时候，随时恢复掌握。