从个人提速到团队提效：我们这半年的AI Coding工程化实践

去年开始，团队里每个人都用上 AI 写代码了。

按理说，效率该起飞了。

可折腾了大半年，我才慢慢看清：每个人都明显变强了，但团队的合力却没跟着强起来。

会用 AI 的人，效率飞涨。

用得浅的人，被甩在后面。

几十个开发，几十套打法——各自的 prompt 习惯、各自的提示词、各自摸索出的一套方法。

这本来不是坏事。

坏就坏在，大家的产出开始对不上了。

同一个功能，不同人让 AI 写出来的代码，风格能差出十万八千里。

某个同事摸到一个好用的技巧，群里截图一发，热闹两句，然后就沉底了。

下一个新人进来，还是从零开始踩。

文档呢？散在各个服务的 README 里，或者干脆躺在某个人的电脑里。

遇到跨服务的需求更尴尬——没有共享通路，只能把好几个服务的代码全 copy 进一个目录，给 AI 凑一个"伪工作空间"，将就着用。

AI 把人和人之间的差距拉大了，团队的合力反而被稀释了。

把"怎么用 AI"变成标准动作

所以我们决定做一件事：把"团队怎么用 AI"，变成一套统一的标准动作。

一开始没想那么大，就是一套工作流配置。

每个开发场景对应一个命令，每个命令写清楚：什么时候触发、分几步走、产出什么。

50 多个命令，从写 PRD、出方案、写代码、生成测试，到上线、复盘，全链路每个环节都有专属命令。

重点不是命令多，而是它们彼此咬合，形成一套体系。

"初始化需求"开一个工作空间，"出方案"读这个空间生成技术方案，"写代码"照着方案实施，"生成测试方案"再根据代码变更自动补上……

一条完整的链路。

谁来跑、用哪个 AI 工具，产出的风格都一样。

团队用 AI 这件事，第一次有了共同语言。

给 AI 一份团队的知识库

工作流跑起来，马上撞上第二个问题：AI 跑命令的时候，到底读什么？

光给代码不够。

AI 得真正"理解"这个系统——这个字段为什么这么设计、这条限制是哪次线上事故留下的、这几个服务之间到底怎么调……

这些东西，只装在团队成员的脑子里。

于是我们建了一套知识库，包含以下几部分：单个服务的规范、业务域的视图、跨服务的系统架构、架构和开发规范等。

每一层都能自动扫代码生成。

但自动扫描只能扒出结构，扒不出业务知识。所以还得加两条人工通路：

一是主动补全。把那些"不成文的规矩"手写进知识库，AI 跑命令时就读得到。

二是纠错反哺。通过 AGENTS.md 规则约束开发过程中的所有环节，当我们纠正 PRD 问题、技术方案问题或者修复 BUG 的时候，都会把问题记录下来，需求上线后会再反哺回知识库。

下次再碰同类问题，它就不会在同一个坑里栽第二次。

工作流是 AI 的手脚，知识库是 AI 的记忆。少一个都不行。

把需求，做成一个独立的空间

还有一个问题，我们想了很久才理顺：多服务的需求，到底怎么管？

大多数团队的知识库，是挂在单个服务底下的——每个服务一套 README、一套文档、一套规范。

单服务需求时很顺。

可一旦碰上跨三四个服务的需求，就抓瞎了：AI 只能在一个服务的上下文里打转，看不见全局，出来的方案缺胳膊少腿。

于是我们设计了一套新的需求管理方式。

每个需求，是一个独立的工作空间。

PRD、技术方案、测试方案、中间产物——这个需求所有的"事"，全堆在一个地方，不会再丢三落四。

工作空间下面，挂着这个需求涉及的每一个服务。

一个服务一个分支，全收在这个空间里。

Agent 实施的时候，能同时看见所有服务，跨服务的改动一次性做完——不用来回切窗口、不用反复粘贴上下文。

这个设计还顺手解决了另一件事：配合全栈，效率是成倍涨的。

我们一直在往全栈走——后端能上手前端，前端也能改服务端。

放在以前，一个跨端需求要前后端分头开发、来回对齐。

现在一个人带着 AI，客户端、H5、后端几个服务，能一口气全做完。

相关代码全在一处，AI 一次看全，一次改完。

个人能力的跃升，再叠上工作流的组织方式——这两样合在一起，才是真正的效率杠杆。

把基座，装进一个顺手的工作台

我们把这套工作流 + 知识库叫做基座，基座跑通之后，体验上的问题冒出来了。

同时跟三个需求，IDE 窗口切来切去一团乱。在传统的 IDE 里代码编辑器还是主角，占了主窗口的绝大部分空间。而我们就只能在一个狭小的空间里执行命令和切换文件目录。

还有就是 50 多个命令名，根本记不住……

于是我们做了一个桌面工作台，一个 macOS 客户端，定位是 AI 时代更友好的产研工作台。

一个核心想法：多需求方便切换，一个需求一个面板，一个面板里包含需求需要的所有内容。

我们还做了个类似灵动岛的通知层——AI 要申请敏感操作，悬浮卡片全局飘出来，按几个快捷键就处理了，不抢焦点。

让确定性高的活，自己跑

再往后，又发现一件事：很多简单需求，压根不需要人盯着。

改个文案、修个小 bug、补个字段——本质就是跑一套命令。

人坐那儿等，跑完瞄一眼，没问题就推。

这段时间，纯属浪费。

所以我们做了个云端自动执行器，常驻在服务器上。

它盯着任务系统里命中规则的需求，自动跑工作流：出方案、写代码、推代码、生成 MR。

全自动到 MR 为止，最后合入永远交给人拍板。

也不是非得全自动——可以只让它做某一段，也可以全程放手。

它拿不准的时候，往飞书群发个消息找人来定夺。

云端跑的是也同一套命令——本地能跑通，服务器才跑得通，不维护两套实现。

回头看这条路

回头看，这条路其实走得很清楚：

第一步，各自单兵作战，能力参差，合力很弱。

第二步，统一工作流 + 知识库 + 需求工作空间，立起共识层。

第三步，桌面工作台，解决多需求并行和但需求统一面板的体验问题。

第四步，云端自动执行，把确定性高的活交给机器。

每一步，都是在收拾上一步留下的烂摊子。

每一步收尾，又冒出新问题，逼出下一步。

当前最大的一个问题：复杂需求的生成质量不高

中小型需求 AI 跑得不错，可一旦跨多个服务、还带时序依赖，输出质量就肉眼可见地往下掉。

一个跨十几个服务的方案，人工 review 完往往得返工四成以上才能落地。

我们专门去分下了一下，问题主要出在：技术方案的细节不够，甚至干脆丢了。

但奇怪的是，中小型需求没这毛病，只有大需求才会犯。

我们还特意做了个对照——把一个大需求人工拆成好几个小需求分开跑，结果每个小需求的质量都还不错。

所以我们怀疑，根子还是在上下文过大：盘子一大，AI 一次性扛不住这么多细节，就开始顾此失彼、丢三落四。

现在已经在试 SubAgent 的模式来解这个问题——主 Agent 只管设计和验收，子 Agent 各自闷头干活。

目前还在测试中……

往后的方向就一句话：把大问题切小。

要么按服务拆开，各自出一份方案、人工逐个确认，再聚到一起对齐；要么多个子 Agent 并行去啃各自那块，主 Agent 不下场写细节，专管整体设计和最后验收。

最后

AI 时代，什么都变得太快了。

今天还觉得趁手的东西，过半年回头看，可能就过时了。

我甚至很清楚——我们现在吭哧吭哧搭起来的这套工作流，未来某一天大概率是会被淘汰的。

模型越来越强，今天要靠几十个命令、靠流程一步步兜住的事，明天也许它自己就能搞明白了。

到那天，工作流可能就没用了。

但我越来越笃定一件事：知识库不会。

不管模型强到什么程度，它都不会凭空知道——你这个字段为什么这么设计、这条限制是哪次线上事故换来的、这几个服务之间到底藏着什么默契。

这些东西，是团队一砖一瓦垒出来的认知，是只属于你们自己的上下文。

模型是公共的，知识库是你们私有的。

工具会换，模型会迭代，可这份沉淀，永远是团队最宝贵的资产。

所以越往后我越觉得，怎么定义知识库、怎么把它持续维护好，才是这件事里最值得花力气的主题。

工作流是术，会过时；知识库是底子，越攒越厚。

关于我们这套知识库到底怎么生成、怎么维护、怎么让它自己越长越壮——后面有空，再细讲一下。