分享技术见解、生活感悟和成长历程
前几天，团队有人给我提了个 skill 的变更。 我盯着看了半天。 逻辑写得很细，挑不出什么毛病。当我想要点击合并的那一刻，心里有个声音：这条优化，到底有没有用，我说不清了。 😅 以前不是这样的。 9 个 skill 的简单日子 我刚搞这个工作流那会儿，一共 9 个 skill，对应 9 个关键研发节点。 那时候加东西很简单。没有现成的内容，谁想往 skill 里塞一段逻辑，直接写进去就行。也不需要评估——那时候是"有"和"没有"的区别。从 0 到 1，加进去就一定有用，谁都看得见。 后来 skill 从 9 个变成了 69 个。 数量多了是一方面，更要
最近这几天，我又开始焦虑了。 原因是，我突然意识到一件事。 已经有一阵子，没人反馈 Zeus 的问题了。 Zeus 是我们团队做的一套 AI Coding 工具体系。 说白了，就是想让 AI 把"写代码"这件事，从头到尾接过去。 用了两个多月，大家从一开始的别扭、吐槽、不信任，慢慢变成了—— 用得挺顺。 顺到，没人抱怨了。 按理说，这是天大的好事。 可那一刻，我心里咯噔一下。 因为"没人提问题"，有两种可能：一种是真的没问题了，另一种是，大家已经看不见问题了。 我估计，是后者。 浮在水面上的，是看得见的成绩 这半年，团队是真的变样了。 Zeus、Zeus
最近 Loop Engineering 在持续刷屏。 公众号在刷，各种群里在讨论，我也看了好几篇文章。 每篇都有道理——五个组件、目标定义、古德哈特定律，逻辑很清晰，我都信了。 但看完之后有点空。 我的工作流该怎么 Loop 化？从哪起手？搭出来以后长什么样？ 没一篇说清楚。 所以想聊聊我自己的理解，以及我们实际在做的事——我们团队搭了个叫 Talos 的系统，算是目前我见过最接近"生产级 Loop Engineering"的垂类实践。 Loop 其实只有两种形态 在我看来，Loop Engineering 这件事，放长了看只有两个终点。 第一个是通用智能 AI。 它足够强
前面几篇，聊了团队怎么搭 AI 工作流、怎么建知识库。 今天聊聊 AI 在 PRD 编写和质量保障上，我们做了些什么。 其实这块从一开始就在工作流里。只是在开始的MVP版本里，核心全压在开发环节。 等大家真用起来，一个问题立马浮出水面： PRD 质量一般，工作流出来的技术方案，质量自然也上不去。 道理特别朴素：垃圾进，垃圾出。 源头的 PRD 含糊，后面 AI 再能干，也只是替你把这份含糊"发扬光大"。 所以我决定还是要治理一下这个源头。 第一步：先给 PRD 做个体检 我做的第一件事，是一个 PRD 质量检测 skill。 注意，它不碰业务逻辑，只做"规范层&q
做团队 AI 工作流，第一个把我卡住的问题，不是技术。 而是——到底该用开源的，还是自己造一套？ 说实话，我一开始也很犹豫。 毕竟"自己造轮子"这四个字，听着就不太聪明。 所以动手之前，我特意花了不少时间，认真研究了一圈现成的方案：BMAD、OpenSpec、SuperPowers、SpecKit…… 一个个看下来，我的第一感受是：真优雅。 👏 设计思路清晰，工程化也讲究，看得出背后都是高手。 可越往深里看，我越发现：它们再好，也不是为我们这种团队设计的。 所以，最终我还是决定做我们自己的工作流。 三个绕不过去的坎 具体说，是三个坎，每一个都硌得慌。 第一个，它们几乎都是冲
AI Coding 时代最大的护城河，不是模型，不是 Agent，也不是工作流。 而是知识库。 这是我折腾了一整年 AI Coding，到最后才慢慢看明白的事。 可一开始，我和大多数人一样，劲儿全使在另一个地方——工作流。 怎么把写 PRD、出方案、写代码、生成测试串成一条链路，让 AI 一步步往下跑。 工作流跑通了，下一个问题马上冒出来—— AI 跑这些命令的时候，到底读什么？ 光给它代码，不够。 于是所有人又一窝蜂去搞知识库。研发在搞，产品在搞，业务也在搞。 可搞着搞着我发现一件事：几乎没人能说清，知识库到底该是什么。 先说说，知识库不该是什么 很多人理解的知识库，是"把代码翻
去年开始，团队里每个人都用上 AI 写代码了。 按理说，效率该起飞了。 可折腾了大半年，我才慢慢看清：每个人都明显变强了，但团队的合力却没跟着强起来。 会用 AI 的人，效率飞涨。 用得浅的人，被甩在后面。 几十个开发，几十套打法——各自的 prompt 习惯、各自的提示词、各自摸索出的一套方法。 这本来不是坏事。 坏就坏在，大家的产出开始对不上了。 同一个功能，不同人让 AI 写出来的代码，风格能差出十万八千里。 某个同事摸到一个好用的技巧，群里截图一发，热闹两句，然后就沉底了。 下一个新人进来，还是从零开始踩。 文档呢？散在各个服务的 README 里，或者干脆躺在某个人的电脑里。 遇到跨