AI Coding 跑顺了,真正的难关才开始
刘宇帅最近这几天，我又开始焦虑了。
原因是，我突然意识到一件事。
已经有一阵子，没人反馈 Zeus 的问题了。
Zeus 是我们团队做的一套 AI Coding 工具体系。
说白了，就是想让 AI 把"写代码"这件事，从头到尾接过去。
用了两个多月，大家从一开始的别扭、吐槽、不信任，慢慢变成了——
用得挺顺。
顺到，没人抱怨了。
按理说，这是天大的好事。
可那一刻，我心里咯噔一下。
因为"没人提问题"，有两种可能：一种是真的没问题了，另一种是，大家已经看不见问题了。
我估计，是后者。
浮在水面上的，是看得见的成绩
这半年，团队是真的变样了。
Zeus、Zeus Studio、Zeus Talos，我们叫它"三件套"。
在它们的加持下，研发这一段的效率，肉眼可见地上来了。
其中 Talos 这条云端的路已经跑通了，简单需求能整条链路自动跑下来。
像项目知识库的定期更新、Zeus 的需求统计这些活儿，现在已经完全交给 Talos 在云端自己干了，没人盯着。
这些拿出去说，都挺好看。
但我心里很清楚——
这些，只是开胃菜。
水面之下，我们想去的地方还很深
我们想要的，从来不是"AI 帮忙写代码"。
是端到端。
是让 AI 接管一个需求的全流程：从最开始的 BRD、PRD，到技术研发、验收上线，再到线上问题的监控和解决，一条龙。
是相当一部分需求，能在云端自动化交付，人基本不用碰。
是整个产研的效率，成倍成倍地翻。
对着这个目标回头看，现在这点成绩，真的不算什么。
我们离想去的地方，还隔着一片深水区。
深水区里，沉着三个还没解决的问题
第一个问题：产品几乎没提效。
不是产品不努力，是介入的时间太晚了。
很多事，等产品下场的时候，已经来不及在源头上帮 AI 把方向定准。
第二个问题：测试提效，也不明显。
测试用例的编写，AI 帮了大忙，这块是真快。
可用例的执行，目前大部分还是人在做。
接口测试脚本、自动化工程测试，覆盖的范围还很小。
写得快，跑得慢，整体就快不起来。
你看，研发这一段通了，可前面的产品、后面的测试还堵着。
水管中间通了，进水口和出水口卡着，水流照样上不来。
第三个问题，最隐蔽，也最让我睡不着——
研发这边太"通畅"了，通畅到没人再挑刺。
这就是开头那件让我心里咯噔的事。
用了两个多月，大家顺手了，习惯了，也就不再觉得哪儿有问题了。
可问题真的没了吗？
不是。是我们进了深水区，那些问题沉到了水底，大家看不见了。
没有了刺耳的反馈，Zeus 就断了往前进化的燃料。
接下来这两个月，怎么打
6、7 月，我给团队定的主攻方向，是先把产品和测试这两头补上。
靠的是两件事。
第一件，补齐知识库。
这事特别容易被忽视。
很多业务知识，代码里根本就不存在。
它在老员工的脑子里，在某次会议的口头约定里，在一个谁都没写下来的"默认规则"里。
AI 不知道这些。
它写 PRD、写代码的时候，缺了这些信息，产出的东西就是空中楼阁——看着对，落地全是坑。
知识库不补，AI 再聪明，也是在猜。
第二件，打磨 skill。
Zeus 里有六十多个 skill。
它不是"写个周报"那种小工具的堆叠。
我们的目标是：这一整套 skill，配上知识库，能扛下我们所有类型的业务需求。
可现实是，skill 在不同的需求、不同的业务方向上，表现差异很大。
这个需求跑得漂亮，换个方向就拉胯。
得一个一个去调，去喂，去磨。
这里头，PRD 是最重要的一环。
产研流程里常说"左移"——就是把问题，尽量在最开始的环节就澄清干净。
可我们现在的真实情况是，交付的 PRD 里很多信息是缺的，全靠研发在做技术方案的时候去补。
虽然 PRD 也已经在用 skill 生成了，但 AI 理解"现状是什么、要改什么"的能力，还是偏弱。
PRD 怎么组织、写到什么质量、用什么方式表达，全都还有很大空间。
问题在源头没说清，后面每一步，都得替它擦屁股。
至于研发——
不能因为它"通畅"了，就把它放一边。
恰恰相反，越通畅，越要主动深潜。
不是等问题自己冒出来，而是自己钻到水底下，把那些被"顺手"盖住的问题，一个个抠出来，再把效果和效率往上抬一个台阶。
写在最后
带团队这些年，我越来越觉得。
做工具也好，做事也好，最怕的从来不是一堆问题摆在面前。
最怕的是——
有一天，大家都觉得，没什么问题了。
那你，打算怎么在"一切都好"的时候，找到下一个该解决的问题？🌊
刘宇帅
非著名程序员，全栈开发工程师，长期专注系统开发与架构设计。
提示
功能待开通！
相关文章
从个人提速到团队提效：我们这半年的AI Coding工程化实践
去年开始，团队里每个人都用上 AI 写代码了。 按理说，效率该起飞了。 可折腾了大半年，我才慢慢看清：每个人都明显变强了，但团队的合力却没跟着强起来。 会用 AI 的人，效率飞涨。 用得浅的人，被甩在后面。 几十个开发，几十套打法——各自的 prompt 习惯、各自的提示词、各自摸索出的一套方法。 这本来不是坏事。 坏就坏在，大家的产出开始对不上了。 同一个功能，不同人让 AI 写出来的代码，风格能差出十万八千里。 某个同事摸到一个好用的技巧，群里截图一发，热闹两句，然后就沉底了。 下一个新人进来，还是从零开始踩。 文档呢？散在各个服务的 README 里，或者干脆躺在某个人的电脑里。 遇到跨
AI Coding 搞了一年,我才认准真正的护城河是知识库
AI Coding 时代最大的护城河，不是模型，不是 Agent，也不是工作流。 而是知识库。 这是我折腾了一整年 AI Coding，到最后才慢慢看明白的事。 可一开始，我和大多数人一样，劲儿全使在另一个地方——工作流。 怎么把写 PRD、出方案、写代码、生成测试串成一条链路，让 AI 一步步往下跑。 工作流跑通了，下一个问题马上冒出来—— AI 跑这些命令的时候，到底读什么？ 光给它代码，不够。 于是所有人又一窝蜂去搞知识库。研发在搞，产品在搞，业务也在搞。 可搞着搞着我发现一件事：几乎没人能说清，知识库到底该是什么。 先说说，知识库不该是什么 很多人理解的知识库，是"把代码翻
AI工作流跑不起来，问题可能出在PRD
前面几篇，聊了团队怎么搭 AI 工作流、怎么建知识库。 今天聊聊 AI 在 PRD 编写和质量保障上，我们做了些什么。 其实这块从一开始就在工作流里。只是在开始的MVP版本里，核心全压在开发环节。 等大家真用起来，一个问题立马浮出水面： PRD 质量一般，工作流出来的技术方案，质量自然也上不去。 道理特别朴素：垃圾进，垃圾出。 源头的 PRD 含糊，后面 AI 再能干，也只是替你把这份含糊"发扬光大"。 所以我决定还是要治理一下这个源头。 第一步：先给 PRD 做个体检 我做的第一件事，是一个 PRD 质量检测 skill。 注意，它不碰业务逻辑，只做"规范层&q
大家都在说工作流，那我们到底是用开源的呢，还是定制自己的呢？
做团队 AI 工作流，第一个把我卡住的问题，不是技术。 而是——到底该用开源的，还是自己造一套？ 说实话，我一开始也很犹豫。 毕竟"自己造轮子"这四个字，听着就不太聪明。 所以动手之前，我特意花了不少时间，认真研究了一圈现成的方案：BMAD、OpenSpec、SuperPowers、SpecKit…… 一个个看下来，我的第一感受是：真优雅。 👏 设计思路清晰，工程化也讲究，看得出背后都是高手。 可越往深里看，我越发现：它们再好，也不是为我们这种团队设计的。 所以，最终我还是决定做我们自己的工作流。 三个绕不过去的坎 具体说，是三个坎，每一个都硌得慌。 第一个，它们几乎都是冲
Loop Engineering：每篇文章都在讲，但没人告诉你怎么搭
最近 Loop Engineering 在持续刷屏。 公众号在刷，各种群里在讨论，我也看了好几篇文章。 每篇都有道理——五个组件、目标定义、古德哈特定律，逻辑很清晰，我都信了。 但看完之后有点空。 我的工作流该怎么 Loop 化？从哪起手？搭出来以后长什么样？ 没一篇说清楚。 所以想聊聊我自己的理解，以及我们实际在做的事——我们团队搭了个叫 Talos 的系统，算是目前我见过最接近"生产级 Loop Engineering"的垂类实践。 Loop 其实只有两种形态 在我看来，Loop Engineering 这件事，放长了看只有两个终点。 第一个是通用智能 AI。 它足够强