借助 AI，每个研发个体都变快了，但组织并没有变快。

我们也是在把 AI 工程化推到数百人规模后，才真正看清这个瓶颈所在。编码效率被大幅拉升，但需求转述的损耗、决策回流的延迟、上下文在终端间的散落，反而成了更明显的阻碍。

要解的不再是“个人怎么用 AI”，而是“组织怎么用 AI”。本文由小米零售研发团队分享我们的三层工程实践——统一工作流、知识沉淀、协作透明——以及一个核心判断：工具会换代，但知识与协同一旦沉淀，就是 AI 时代最难被复制的组织能力。

01

统一工作流：从个人到团队

AI 不够聪明不是瓶颈，让人先用起来才是。降低门槛，比提升上限更重要。

**▍自由探索期与瓶颈

公司鼓励使用 AI 之初，还没有统一的模型、工具和方法论，每个人各自在 Cursor、Copilot 等工具中摸索玩法。一段时间后，个体差异急剧拉大：一部分人熟练使用 AI 工具，效率显著提升；另一部分人反复尝试后选择回归手写，对 AI 持保留态度。

少数人的突破并不等于团队整体的提升。如果只停留在这一步，AI 在团队维度的提效就永远是点状、不稳定、不可复现的。若要把 AI 真正转化为团队能力，必须让所有人都能用起来。为此，我们决定为大家提供一套低门槛的工具，先将大家带进 AI 的大门，再实现规模化提效。想清楚这一点之后，我们开始构建第一版工作流——一个带菜单的低门槛方案，内部称为 VAF（Vibe Agentic Flow）。

▍VAF：从带菜单的工作流到汇聚协调模式

这套工作流的设计出发点很朴素：不会写提示词，就把提示词写好；不会编排流程，就把流程排好。整套流程拥有统一入口，用户只需执行一个 Markdown 文件vaf_starter，它会渲染出菜单：

图片

看起来没什么技术含量，但它解决的是一个比技术更难的问题：认知门槛。

用户不必记住自己走到哪一步，也无需理解提示词结构或手动管理产物，唯一要做的就是跟着菜单走，在每个放行点做决策。阶段间有明确依赖：P01 未完，P02 锁定；每阶段执行完会主动提醒审核，按yes放行，产物自动提交到云端 Git；有问题按e与 AI 继续对话修改，满意后再放行。

这本质上是把自由度换成确定性——新手不再纠结“下一步做什么”，老手的最佳实践也被沉淀下来。

VAF 1.x 最初只支持单服务流程：一个需求、一个服务、一个人跟到底。但实际业务涉及多个服务，需要多角色协作。我们在 2.x 版本里引入了“汇聚协调”模式：

  • 需求采集、PRD 标准化、服务拆解等前置阶段各服务共享，不重复执行；
  • 分发后各服务在自己的仓库里推进；
  • 拉通评审、集成测试等关键节点汇合，由项目负责人组织评审，通过后继续分叉。
  • 跨机器的状态与产物传递轻量地依托 Git。

图片

多服务汇聚协调:分叉 → 汇合 → 分叉 → 汇合

我们选择先从后端切入——后端服务的链路最长、依赖最多，流程验证最充分。跑通之后，再把同样的方法论延伸到前端和测试。三套流程共享同一套状态机设计，但在具体阶段上有差异：

流程 核心阶段 场景侧重
后端 需求采集 → PRD 标准化 → 服务拆解 → 技术方案 → 代码开发 → CR → 部署 多服务汇聚协调 / 跨服依赖管理
前端 准备 → 设计 → 实现 → 测试 → 交付 循环收敛自校准 / 设计稿高保真还原
测试 准备 → 分析 → 设计 → 执行 → 报告 测试左移 / 产物可视化 / 前后端独立上下文

VAF 后端推广后，不熟悉 AI 的同学首次拥有了“闭眼也能跑下来”的流程，用户量快速增长。相比单纯的代码补全，流程的完整性消除了点状使用 AI 的割裂感。

我们当时很有信心地把 VAF 推给团队，以为这套流程能“开箱即用”。但大量反馈随之而来：VAF 流程本身没问题，问题在于 AI 不理解具体业务，产出的内容偏差很大，仍需大量人工修改。这让我们意识到，AI 工程化不能只做一层，必须“流程 + 知识”双轮驱动，缺一不可。第二次演进由此开始——我们决定构建 VKF，让 AI 真正理解这个代码库和业务。

**02

代码知识库：让 AI 懂业务

给 AI 更多代码，不如给它一个知识索引。知识索引比代码灌入重要。

▍VKF 1.0：一次正面的失败

参考 VAF 的思路，我们构建了一套面向代码知识库的 AI 工作流——VKF（Vibe Knowledge Flow），作为 VAF 的配套能力。最初的设想是：既然 AI 在执行任务时不了解业务，那就先从代码中提取业务知识、模块说明、流程描述和关键逻辑，把它们沉淀成 Markdown 文档，再让 AI 在后续开发中通过这些知识文档理解业务。

这个方向在早期看起来很自然。相比每次都让 AI 直接读大量代码，提前把代码整理成更容易阅读的业务知识，似乎可以降低 AI 的理解成本，也能让团队逐步积累可复用的知识资产。

但第一版试下来，我们发现效果并不稳定。它不是完全不可用，而是存在明显的精度损失：代码被总结成文档时，AI 会遗漏条件、弱化边界、误读调用关系，甚至生成一些看似合理但并不准确的解释。等到后续任务再使用这些文档时，AI 又会在文档基础上进行第二次理解和推理，于是偏差被进一步放大。

问题本质上出在“层层翻译”：

  • 第一层损失： 代码到知识文档。 代码里的真实逻辑、异常分支、调用关系和状态变化，在被总结成自然语言时会被压缩、改写甚至误解。文档读起来更顺，但不一定更准。
  • 第二层损失： 知识文档到实际任务。 后续 AI 使用这些文档时，并不会自动回到代码验证，而是容易基于已有表述继续推理。一旦文档本身有偏差，生成的方案就会沿着偏差继续走。
  • 第三层问题： 文档越像结论，越难暴露错误。 代码里的问题可以通过入口、调用链和测试去验证；但自然语言知识一旦写成“模块说明”或“业务结论”，错误反而更隐蔽，人工 review 成本也更高。

这让我们意识到，知识库不应该承担“解释大量代码逻辑”的职责。对一个持续变化的代码库来说，把代码翻译成一批静态知识文档，再让 AI 基于这些文档继续工作，链路太长、损耗太多，也很难保证始终贴近真实代码。

因此，VKF 1.0 虽然没有达到预期，但它给了我们一个很重要的结论：AI 工程化需要知识，但知识库不能替代码做二次表达。真正可靠的方式，不是让 AI 读一份被翻译过的代码说明，而是帮助 AI 更快、更准地找到真实代码里的入口、链路和关键位置。

这也直接推动了 VKF 2.0 的重新定位：知识库不再负责解释大量代码逻辑，而是作为代码的直接索引存在。它告诉 AI 应该从哪里开始看、沿着哪条链路查、哪些文件和接口最相关；真正的逻辑判断，仍然回到代码本身完成。

▍VKF 2.0：知识索引的设计与机制

2.0 版本，我们将 VKF 重新定位为一句话：VKF 不是给 AI** 塞代码，而是给 AI 一个代码的知识目录和索引。** 帮助它高效理解代码和搜索代码。

定位转变后，VKF 的工作方式彻底改变：它不再试图把代码灌给 AI，而是先自行完成结构化理解，将结果沉淀为知识条目，再将这些条目作为索引提供给 AI。

VKF 2.0 的核心 pipeline 分为三步：

图片

VKF 2.0 的知识构建 Pipeline 与生命周期管理

  1. 结构化扫描： 从入口、控制器、领域服务等关键位置出发，反向推导系统的架构骨架——核心领域模型、主要调用链路、关键抽象边界。我们明确放弃“全量遍历”，而是用架构层次引导扫描深度。
  2. 专家边界解释：AI 产出的领域划分不一定符合真实业务分层。这一步由熟悉业务的人类专家对 AI 的划分做纠偏——由团队中最懂该业务领域的同学，花半小时到一小时提出修正。这一步是整个 pipeline 里最不可自动化、但也最不可跳过的一步。
  3. 领域聚合：一个知识库不再对应一个代码仓，而是对应一个业务领域（通常包含多个相关服务），服务于该领域下所有服务的研发工作，跨服务的依赖关系也在库中显性化。

▍知识的信息化

建设 VKF 过程中，我们最大的体感是：知识库建设的最大阻力不在技术，而在于知识本身的信息化****程度。

研发侧相对还好——代码永远是最新的，因此知识库可以基于代码反推。但产品侧的文档往往高度碎片化：刚评审完的 PRD 是版本 A，实际上线时因各种细节调整变成了版本 B。这些变更，往往是沟通群里几句话就达成的共识，从未回写到文档里。这类隐性知识不先完成信息化，任何知识库都只是沙上建塔。我们现阶段在推几件事：

  • 整合现有数字化文档，由 AI 做结构化沉淀，再由人工纠偏
  • 推动产品团队输出 AI 友好的 PRD——Markdown 格式、Mermaid 流程图，替代大量内嵌图片
  • 让产品同学融入 AI 工作流，借助 AI 撰写 PRD，从源头降低信息损耗

这些动作的共同点是：让知识在产生的那一刻就是结构化的、可被 AI 消费的，而不是事后补录。事后补录的知识，永远追不上业务迭代的速度。

▍为什么知识值得长期投入

在 AI 工程化的进程中，我们逐渐形成一个判断：工具链会迭代，工作流会更新，Skill 会换代，但团队在特定业务领域积累的知识是永恒的。模型能力再强，也不会知道你某个业务场景里隐藏的并发陷阱；不会知道某个接口三年前因为兼容性原因保留了一段怪异的逻辑；不会知道某个看似冗余的字段其实承载了历史数据迁移的契约。这些知识只存在于团队内部，只有被显性化、结构化之后，AI 才真正能用得上。

如果让我们说一件最值得投入的事，答案不是“更强的 Agent 编排”，也不是“更长的上下文”，而是——让团队核心的业务知识显性化、结构化、可被 AI**** 消费。

03

协作工作台：让过程可见

每个人用好 AI 还不够，并行协作与过程透明才是组织提效的关键。

▍VAF + VKF 之后还缺什么？

VAF 把流程跑通了，VKF 让 AI 懂业务了，团队中多数人都能借助 AI 独立工作。但新的问题很快浮现——大家仍然在各自的 AI 终端里单打独斗，团队视角一片空白。

产品在飞书群里讨论一个新需求。研发把需求 copy 到自己的 AI 终端，和 AI 来回七八轮敲定技术方案，再把结论发回群里。产品看到的只是一个被压缩过的结论——AI 怎么理解需求的、为什么放弃了 A 方案选了 B 方案、哪些边界条件被默认忽略了，完全看不见。直到下次评审会上才发现 AI 把某个核心条件理解反了——这时已经晚了好几天。

这不是单点效率问题，是协同结构问题。每个人都在用 AI，每个人都比过去快了，但整个团队对“这件事正在发生什么”毫无共识。团队视角望去，只能看到最终交付物，中间的过程一片空白。这种不透明的代价很现实：

  • 需求变更回不到源头，只能靠转述，而转述必然伴随信息损耗
  • 决策过程没人看得见，复盘时只能靠回忆
  • AI 在某个节点卡住，别人无从知晓，无法协助
  • 新人进组没有过程上下文可以承接，只能从头问起

我们意识到：团队提效，不是让每个人“把 AI 用得更好”，而是让 AI 的工作过程进入团队已在使用的协作空间。对我们而言，这个空间就是飞书。

▍一次真实的“困在私聊里”

eight-claw 是我们做的第三个内部工具——一个搭在飞书里的 AI 协作机器人，将 AI 工作过程接入团队协作场景，以群内的“话题”为最小并行单元。eight-claw 的第一版设计走了弯路。最初的思路是：既然要在 IM 里协作，就把 AI 做成机器人，用户在私聊里发消息，机器人调度 AI 引擎执行。这看起来很自然——IM 人人会用，机器人也并不陌生，没有额外的学习成本。

但我们逐渐遭遇一个本质问题：私聊天然是串行的。一个人在一个私聊里，同一时间只能推进一件事。想并行处理“写代码 + 查文档 + 做 CR”三件事，私聊里做不到，消息会互相干扰，上下文会混杂。

我们在这个方向上挣扎了好几个版本。尝试过用关键词路由区分任务，试过卡片级并行推送，也想过给每个任务生成独立的小卡片栏。每一种方案都有各种问题，每一种都不够好。我们在这个方向上探索了好几个版本，始终找不到满意的解法，团队内部对“是不是走错方向了”产生了分歧。但每次讨论仍然回到“怎么在私聊里做并行”，陷入了问题框架本身的陷阱。

直到我们停下来，重新定义真正的问题：核心诉求不是“在私聊里做并行”，而是“让多件事能并行推进”。问题一旦被重新定义，飞书的话题（thread）就成了自然的答案——它本身就是为并行设计的产品抽象。这次重新定位，也让 eight-claw 从“私聊机器人”重构为“话题驱动的协作工作台”，后来进一步提炼出“话题是并行推进的最小治理单元”这一核心抽象，它同时解决了上下文、参与、决策、状态四个边界。

▍eight-claw 的四类入口

想清楚之后，eight-claw 的产品形态自然浮现。我们提供四种定位清晰的入口，每种对应一种使用模式：

入口 定位 典型场景
私聊 串行推进的轻量入口 临时需求、碎片时间追问、个人单线程推进
工作台群 个人专属的需求总控台 需求发起、需求总览
需求协同群 话题并行推进的协作空间 多人协作，也适合个人多任务并行
本地 Dashboard 运行态可视化控制面 任务管理、需求管理、引擎管理等

四个入口中最关键的抽象，是协同群里的“话题”。在飞书产品层面，话题是一个讨论线程；但在 eight-claw 里，一个话题等于一条独立的 AI 任务链路。每个话题拥有自己的上下文、参与者、决策边界和执行状态。

我们把这一抽象总结为一句话——话题，是并行推进的最小治理单元。之所以叫“治理单元”，不是“执行单元”，因为它同时解决了四个边界：

图片

顺带一提：协同群并不只适合多人场景，一个人也可以创建协同群，在里面开设多个话题，把不同任务并行推进。这种“单人多任务”用法，与传统“开多个 AI CLI 窗口”有本质区别——状态不在本地内存，而在 IM 中，任意设备均可访问。

▍技术内核：文件系统即状态机

eight-claw 在工程实现上做了一个刻意取舍：不造新的 runtime，不造新的 orchestrator。核心的任务状态与过程产物，全部以文件形式持久化。为了让 AI 的工作过程“可调度、可治理、可回放”，我们抽象了一组核心模型：

图片

eight-claw 核心模型 —— 一套“文件即状态机”的执行系统

关键不在于它们“存了什么”，而在于它们表达了一套完整的状态机——每一次状态转移都写入 Event，可查、可审计、可回放。没有它，AI 的工作过程只是一堆对话记录；有了它，AI 的工作过程便成为可被系统管理的生产力单元。

▍多引擎统一抽象

eight-claw 底层接入了 Codex CLI、Claude Code、OpenCode 三种执行引擎。很自然地会有人问：为什么不自己写一个统一的 Agent Runtime？

我们的判断是：AI CLI 和基座模型的迭代速度非常快，任何自建 Runtime 都会很快过时。与其把资源投入一个注定被外部生态追上的方向，不如专注在企业场景中最稀缺、也最难被外部替代的部分——调度、状态机、审批、观测、治理。

图片

eight-claw 位于协作入口和 AI 执行器之间的中枢控制面

我们通过ExecutionEngine抽象层把各个 CLI 的差异拦截在执行层内部。上层只需面向统一的任务语义编程，切换引擎、动态路由、失败降级均能统一处理。

▍信息透明的延伸：跨设备、跨场景

协同透明不止于“团队在群里看见 AI 的工作过程”，更进一步，这种透明不应被设备和场地绑定。产品同学开会间隙打开手机，能看到 AI 在某个话题里跑到哪一步；出差的研发在手机上就能看到 review 结论；临时离座的同事，不必回到电脑前就能查看任务进展。

eight-claw 的架构让这件事变得自然：核心任务状态全部持久化（不困在某个进程或终端的内存里），手机端所见与桌面端一致。开发机本地跑着 eight-claw 客户端，飞书的手机/桌面端都能直接对话、给指令、审批、查看进度。结合话题的异步审批模式，AI 在关键节点提交产物后主动等待，人可以在不同时间、不同设备上确认，AI 随即继续执行。

这本质上是把“信息透明”从“在场可见”扩展为“跨设备、跨场景都能看见”——这才是协同透明在工程上的完整形态。

04

设计原则与下一步

回顾这三次演进，我们发现一个共同特征：每一次被卡住，都是因为把问题定义得太窄——把“AI 不懂业务”定义成“缺代码”，把“AI 工程化”定义成“只做流程”，把“让多件事并行”定义成“在私聊里并行”。每一次爬出来，用的都是同一种方式：重新定义问题，而不是在错的问题下找更“聪明”的答案。

图片

AI Coding 下半场的三层工程实践

我们也提炼出四条核心认知，它们构成了我们 AI 工程化的设计原则：

  1. 降低门槛，而非提升上限。 决定团队整体能力的不是 20% 的高手，是 80% 的大多数。把门槛降到每个人都能跨过去，才有规模化提效。
  2. 代码索引对 AI** 理解大规模代码库极为重要。** 在当前上下文有限的情况下，AI 难以一次处理大规模的代码库，需要前置为其构建代码索引，帮助 AI 高效的理解和检索代码。
  3. 并行比串行重要，过程比结果重要。 协同的瓶颈从来不是个人速度，而是信息损耗。并行推进、过程透明，比“让每个人都更快”更能提升组织效率。AI 要进入组织交付链路，必须走到团队已在使用的协作空间里。
  4. 工具链会迭代，知识和协同才是沉淀。 Claude Code、Codex、OpenCode 快速迭代，我们换了几轮 Skill，改了几版流程编排。但知识库里的业务资产、协作工作台里的过程记录——一旦沉淀下来就长期受益，不会因模型换代而失效。

站在当下往前看，我们判断两件事正在发生：知识层会进一步加深。 VKF 目前基于结构化索引，下一步将探索语义检索与跨团队知识联邦。长期来看，一个组织业务知识的显性化程度，会成为 AI 工程化的真正天花板。协同层将从 Task-Driven 走向 Goal-Driven。 当前 eight-claw 仍是“人派任务，AI 执行”。下一阶段，用户设定目标和边界，AI 在约束下自主推进，仅在关键决策点异步通知人。这需要状态持久化、边界可约束、过程可观测同时就位——而这些恰好是 eight-claw 已经打下的底子。

回到开头那句话：借助 AI，写代码的速度变快了。但一次需求从提出到上线的完整链路里，编码从来不是最慢的那一段。真正慢的，是信息在组织里流动时的损耗。

个人借助 AI 是起点，组织借助 AI 才是关键。统一工作流、代码知识库、协作工作台——都不是终点。模型能力和工具生态会继续演变，但这条路径我们会一直走下去：让 AI 真正进入组织的交付链路，而不只是停留在每个人的终端里。这是 AI Coding 下半场，我们想去解的问题。