当AI项目突破玩具级规模，复杂度管理便成为生死线。本文作者以9.88万行代码的monorepo实践为样本，揭示工程控制论与看板化管理如何解决非线性开发难题——从误差分类到工况分离，从噪声过滤到延迟监控，一套对抗复杂度的黄金标准正在成型。

一、我最近在做什么

最近我在准备开源一套“如何上好 AI 课”的经验体系，也因此重新开始手搓一批项目。做到现在，项目代码量已经达到 9.88 万行。这基本已经不是“玩具项目”阶段，而是进入了一个典型的中大型 monorepo体量，而且还远远没到最终完成态。

这意味着，接下来真正拉开差距的，不再只是“我能不能写出来”，而是：

• 我能不能持续推进？
• 我能不能稳定迭代？
• 我能不能在复杂度上升时，依然保持低摩擦协作与低损耗决策？

二、真正的问题，从来不是“会不会写代码”

随着项目复杂度越来越高，文档管理、代码管理、项目迭代都会进入井喷期。

我经常遇到的一个真实问题是：今天的工作被打断之后，第二天很难“无摩擦”地重新进入项目状态。

很多人会说： 现在不是已经有 AI 了吗？为什么还会有工作摩擦？

我的答案是：因为真实项目不是线性的。

一方面，我会主动把项目拆成多个模块，让它们独立维护、独立开发。 这会显著提升系统的可扩展性，但同时也会带来更多的状态切换成本。

另一方面，一个项目从需求定义 → 方案选型 → 开发落地 → 测试验收，从来都不是一条没有回头路的流程。

我很可能在后一个节点发现的问题，会直接推翻前一个节点的判断。

所以，AI 可以提升效率，但不能替我消灭复杂度。

真正决定我的项目是否可持续推进的，是我有没有建立一套能对抗复杂度的管理机制。

三、我的解法：引入两套核心方法

我在开发过程中，逐步引入了两个核心方法：

第一套，是用工程控制论的原则，构建不同阶段的标准。

第二套，是把这些标准在测试验收阶段看板化。

换句话说：先让项目“有标准”，再让项目“可观察”。

四、方法一：用工程控制论，给 AI 项目建立闭环

很多 AI 项目一开始的问题，不是“模型不够强”，而是系统没有被当作系统来设计。

如果你只盯着“它答得对不对”，你看到的只是结果；但如果你从控制论视角看项目，你会开始关注输入、状态、反馈、扰动和约束。

我现在会要求自己至少做下面 10 件事：

1）画出 AI 系统闭环图

把系统拆成：输入、状态、输出、反馈、扰动、约束。只有闭环画出来，你才知道问题是出在提示词、上下文、检索、记忆还是执行链路。

2）定义 5 个核心指标

我会重点看这五项：成功率耗时成本稳定性用户修正次数

因为对 AI 系统来说，“答对”只是最低标准，真正的产品质量来自整体运行质量。

3）给失败案例做误差分类

不要只写一句“答错了”。要继续追问：是理解偏差、检索偏差、记忆污染、工具调用错误，还是上下文窗口退化？只有误差被分类，优化才有抓手。

4）给上下文、记忆、检索加噪声过滤层

AI 项目做到后面，最怕的不是没信息，而是脏信息太多。上下文污染、过时记忆、低质量检索结果，都会导致系统逐渐偏航。

5）固定复盘周期

复盘不能靠心情。如果复盘是“想到才做”，那它大概率永远排在更紧急的任务后面。所以我会把复盘当成系统动作，而不是个人意志。

6）分离不同工况

不要拿一个平均分掩盖所有问题。同一个 AI 系统，在高频短任务、长链路任务、多轮交互任务中的表现可能完全不同。工况不分离，结论一定失真。

7）小步升级

每次只改 1 到 2 个主要变量。否则一旦结果变好或变坏，你根本不知道影响来自哪里。

8）允许探索，但必须设置边界

AI 项目需要探索机制，否则永远不会进化；但探索必须有安全边界和回退机制，否则系统会因为“过度创新”而失控。

9）监控延迟，不只监控准确率

很多项目只盯准确率，最后做出一个“很准但没人想用”的系统。用户对体验的感知，往往从延迟开始。

10）让 AI 不只是回答问题，而是修正流程

真正成熟的 AI 系统，不该只是“回答器”，而应该逐步具备根据反馈调整自身流程的能力。

五、方法二：把测试验收流程做成看板，而不是做成记忆游戏

真正让我工作摩擦明显下降的，不是写了更多文档，而是把验收过程做成了看板式管理。

因为项目一旦复杂起来，最怕的就是：事情在推进，但状态不可见；任务在流转，但责任不清晰；问题被发现了，但没有进入稳定闭环。

所以我会把测试验收阶段拆成四块固定看板：

六、我的四段式验收看板

自动化测试验收

这是第一层过滤网。目标不是证明系统“很强”，而是先证明它没那么容易坏。自动化测试解决的是底层稳定性问题，让明显错误不要流入后续环节。

内部演示

这是第二层验证。内部演示的价值，不在于“展示成果”，而在于用演示逼迫自己回答三个问题：这个东西到底解决了什么问题？这个流程是否足够顺滑？这个方案是否真的能被别人理解和复用？

很多设计在自己脑中成立，一演示就会暴露断点。

小范围测试

这是第三层校准。在这个阶段，重点不是“追求完美”，而是收集真实使用反馈。因为你会发现，很多在开发阶段看起来合理的设计，在真实用户手里会被迅速击穿。这一步，本质上是在做现实世界扰动注入。

公网生产

这是第四层落地。只有走到公网生产，系统才真正进入完整工况。你会看到性能压力、异常输入、边缘场景、长期稳定性这些问题一起出现。

这也是为什么我越来越相信：一个 AI 项目的成熟，不是看它能不能跑起来，而是看它能不能被持续运营。

七、为什么“看板式管理”特别适合 Vibe coding

Vibe coding 常常给人一种误解：好像只要节奏对了、感觉对了、AI 配合顺了，项目就会自然长出来。但我的体感恰恰相反：

越是依赖创造力和快速迭代的开发方式，越需要强结构化的项目管理。

因为 Vibe coding 的优势在于高流动性，问题也恰恰出在高流动性。如果没有一个明确的看板系统去承接这些流动的想法、任务、结论与回退动作，那么灵感最终只会变成碎片。所以对我来说，看板不是“行政工具”，而是降低认知切换成本的外部大脑。它至少解决了三件事：让我知道项目此刻处于什么状态；让我知道下一步最该做什么；让我在任务中断后，能快速恢复上下文。

而这三件事，恰恰就是复杂 AI 项目最容易失控的地方。

八、我的一个阶段性判断

当项目规模还小的时候，个人能力可以覆盖一切。但当项目进入中大型 monorepo 区间后，项目管理本身就已经变成产品能力的一部分。

这个阶段，真正重要的不是“再多写一点”，而是：

• 如何让复杂度被看见；
• 如何让迭代有节奏；
• 如何让反馈能闭环；
• 如何让项目从“依赖个人推进”，变成“依赖系统推进”。

这也是我最近越来越坚定的一件事：

AI 项目的核心竞争力，最终不是模型接得多快，而是系统管理做得多稳。

九、结语

如果你也在做 AI 项目，并且已经进入多模块、多阶段、多反馈回路的开发状态，请尽早做一件事：把项目从“靠感觉推进”，升级为“靠看板和闭环推进”。

为什么？

因为当系统足够复杂时，感觉会失效，只有工程秩序才是真正可靠的生产力。

所以我的建议很简单——建立你的秩序，哪怕从一张看板、一个复盘闭环开始。