分享技术见解、生活感悟和成长历程
最近 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 里，或者干脆躺在某个人的电脑里。 遇到跨