鸟

鸟窝

代码在发臭：一个能"闻"出坏味道的 AI 技能，我拿它扫了最新的开源代码

<blockquote> 「任何傻瓜都能写出计算机能懂的代码。好的程序员写出人能懂的代码。」——Martin Fowler </blockquote> 你有没有过这种感觉：打开一个文件，还没读懂逻辑，先皱起了眉头。说不上哪儿错了，但就是觉得"不对劲"。 这种"不对劲",有个专门的名字——代码坏味道（Code Smell）。 <img src="/2026/07/04/ai-skill-sniffs-out-code-smells/image-20260703065726678.png" class=""> 它不是 bug，代码跑得好好的；它也不是编译错误，测试全绿。它只是一种表面的征兆，暗示底下可能藏着更深的问题。就像厨房里飘来一丝馊味，东西还没坏透，但你知道该去冰箱里翻一翻了。 这篇文章讲三件事：这个词是怎么来的、坏味道到底有哪几类、以及——我怎么用一个 AI 技能，把一个真实开源项目的核心代码"闻"了个遍。 <hr>

2026/7/4

百度网络监控工具开源第四弹：evr — 构造 VXLAN 探测

这是百度网络监控工具 nettools 开源系列的第四篇。前三篇分别介绍了 bitflip/baize（UDP 丢包与改包检测工具和Agent）、lidar（TCP SYN 端口可达性探测），它们解决的都是「服务器之间」「点到点」的探测问题——前提是：探测机和被探测对象，至少有一端在我们手里。 但有一类设备，我们既无法在它上面装 agent，也没法在它对面的机房里放一台探测机。这就是今天的主角 evr 要解决的困境。 这也是我更深入的了解网络包的构造，把网络探测玩出花了来，对我的网络编程的功力大增的一个很好的场景。 <blockquote> 项目地址：<a href="https://github.com/baidu/nettools">https://github.com/baidu/nettools</a> 文档：<a href="https://nettools.rpcx.io/">https://nettools.rpcx.io</a> </blockquote> <h2 id="一、evr-探测的困境：探测机进不去客户机房"><a href="#一、evr-探测的困境：探测机进不去客户机房" class="headerlink" title="一、evr 探测的困境：探测机进不去客户机房"></a>一、evr 探测的困境：探测机进不去客户机房</h2>先说一个真实的场景。 百度有大量的云客户，我们提供的 EVR（Edge Virtual Router，边缘虚拟路由器） 设备作为客户侧网络接入百度云网络的边界节点。EVR 往上连百度的骨干/城域网络，往下连客户自己的虚拟网络（VXLAN overlay）。 <blockquote> EVR - 边缘虚拟路由器，通常用于在虚拟化环境中实现路由功能。EVR 位于网络的边缘，用于连接内部网络和外部网络（如客户机房）。 </blockquote> 现在问题来了：我们需要监控「百度网络 → EVR」这一段链路的健康度——有没有丢包、延迟多大、有没有改包。按照前几个工具的套路，我们的方案应该是： <ul> <li>在 EVR 设备上装个 agent？—— 不行。EVR 是网络设备/客户侧设备，我们没有权限往里塞监控程序。</li> <li>在 EVR 对面（客户机房内）放一台探测机，做点到点探测？—— 更不行。那是客户的机房，正常情况我们不可能在客户的物理环境里申请一台探测机常驻。</li> </ul> lidar 那一套「发 SYN，靠对端内核 TCP 协议栈自动回 SYN-ACK/RST」的思路，在这里也不灵——EVR 不是一台服务器，它不会帮你跑 TCP 协议栈三次握手，或者说不允许我们高频的探测。 <figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 </pre></td><td class="code"><pre> 百度侧边缘设备 ┌──────────┐ ┌──────────────────────┐ │ 探测机 │ ───── ??? ─────► │ EVR 设备 │ │ (我们的) │ │ (装不了 agent) │ └──────────┘ │ 对面也放不了探测机 │ └──────────────────────┘ </pre></td></tr></table></figure> <img src="/2026/06/30/baidu-network-monitor-evr-vxlan-probe/image-20260630042946520.png" class=""> 困境的本质是：被探测对象不可控，且它对面也无法部署探测机。 我们需要一个 「单边」 就能完成的探测方案——只在百度侧放一台机器，让 EVR 设备自己「帮我们把包送回来」。 答案藏在 EVR 设备的工作原理里：它是一个 VXLAN VTEP（VXLAN Tunnel End Point）。而 VTEP 有一个非常好用的特性——它会忠实地按照内层 IP 头转发解封后的内层帧。这就给了我们「构造一个会被反射回来的 VXLAN 包」的可能。 要理解这个技巧，得先看懂 VXLAN 的包结构。

2026/6/30

我把775篇收藏塞进4MB向量库：一个比Karpathy Wiki更能"翻箱底"的RAG skill

我把 775 篇收藏的文章塞进一个 4MB 的向量库，然后问它："我都收藏过哪些关于 loop engineering 的资料？"三秒钟，它把散在六七篇文章里的观点拼成一段答案，每条都带出处。 <img src="/2026/06/29/chao-rag-wiki-personal-knowledge-base/image-20260629054807094.png" class=""> 这不是什么 SaaS 产品，是我自己写的一个 skill，叫 <code>chao-rag-wiki</code>。今天聊聊它，顺便聊聊它背后那个问题：知识库越攒越大，你到底怎么"读"它? 得先从 Karpathy 的一个想法说起。 <hr>

2026/6/29

Go 语言技能：AI 时代的 Go 开发工具链

<blockquote> "Clear is better than clever." 清晰胜于聪明。 —— Rob Pike, Go Proverbs </blockquote> 第 23 章把重构讲完了。嗅坏味道、套 Fowler 手法、小步施工、每步测试，这套东西对 Java、Python、Go 一视同仁。但真到 Go 上手你会发现，Fowler 的目录够不着 Go 的好几层脾气。一段能跑的 Go 代码，可能还停在 Go 1.10 的写法，不地道；可能并发原语用错了，race detector 一开就红，不安全；也可能分配没控住，cache line 在 false sharing，不快。这些坏味道扫不出来，是 Go 二十年攒下来、只有老手才摸得到的门道。 门道都散在各处。Dave Cheney 的高性能工作坊讲一套，dgryski 的 go-perfbook 讲一套，《Go 并发编程实战》讲一套，Go 团队的 modernize 分析又讲一套，再加上无数生产事故换来的风格约定。以前你得一本书一本书读、一个 pprof 一个 pprof 啃。现在有人把这些蒸成一个 Skill，Agent 调一下就能用。 本章介绍五个 Go 专属的 Skill，正好覆盖 Go 工程的四个面：现代化（<code>/modern-go</code>）、性能（<code>chao-go-perf</code>）、并发（<code>chao-go-sync</code>）、风格（<code>go-style-guide</code>），外加一个把这几样打包、还顺带做了效果评估的全家桶（<code>cc-skills-golang</code>）。前三个是本书作者 smallnest 写的，对，写这本书的人和写这些 Skill 的人是同一个；后两个分别来自 madflojo（Benjamin Cane）和 samber。

2026/6/28

重构：AI 时代的代码进化

<blockquote> 「Any fool can write code that a computer can understand. Good programmers write code that humans can understand.」 任何傻瓜都能写出计算机能看懂的代码。好程序员写的是人能看懂的代码。 —— Martin Fowler </blockquote> 第 22 章解决了「人怎么读懂 AI 写的代码」，用 UML 把代码画成图。 读懂之后呢？你打开 AI 生成的代码，能跑，但是一团乱麻：一个方法三百行，一个类管了八件事，同样的逻辑复制了五遍。这时候怎么办？ 重构。 这件事本身不新鲜，Martin Fowler 1999 年就把它写成了一本书。变的是执行者。以前是人对着那本书一处一处手动改，现在是 AI 对着同一本书的目录自动改，人退到后面审查 diff。

2026/6/28

UML 新用途：让 AI 理解你生成的代码

<blockquote> 「A picture is worth a thousand words. A diagram is worth ten thousand lines of code.」 一图胜千言。一张图胜万行代码。 </blockquote> 第 13 章解决了一个问题：AI 写代码容易，读代码难。Understand-Anything 用知识图谱让 AI 理解现有代码。 反过来——代码写完了，作为人类你怎么理解它？毕竟，线上出了故障你还等着你背锅呢。 我前一段看到一句箴言："𝐲𝐨𝐮 𝐜𝐚𝐧 𝐨𝐮𝐭𝐬𝐨𝐮𝐫𝐜𝐞 𝐲𝐨𝐮𝐫 𝐭𝐡𝐢𝐧𝐤𝐢𝐧𝐠, 𝐛𝐮𝐭 𝐲𝐨𝐮 𝐜𝐚𝐧𝐧𝐨𝐭 𝐨𝐮𝐭𝐬𝐨𝐮𝐫𝐜𝐞 𝐲𝐨𝐮𝐫 𝐮𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝𝐢𝐧𝐠"，翻译过来就是"你可以外包你的思考(给AI),但是你不能外包你的理解"。这句话被 Andrej Karpathy 多次引用，以至于大家认为是他说的，其实是kache说的： <img src="/images/image-20260604094614868.png"> 这句话非常有哲理。Dex Horthy 在 2025 AI Engineer 大会上独立提出了："Don't outsource the thinking" / "AI cannot replace thinking, it can only amplify the thinking you have done."，但是今年你看， AI已经外包了我们的思考，你只需说出的你需求，智能体就能帮助你生生成你要的程序，但是 AI 没有办法帮我们理解啊。 我最近就遇到了这样的困惑：我通过goal workflow很快的实现了一个大模型训推任务智能诊断系统，全是AI帮我生成的，但是在联调的前一个星期，我心虚了。 因为我知道，联调和上线的时候，必然有一些问题，比如当时的设计有些模糊的地方，设计上有gap, 实现上也难免有bug。如果我对生成的代码不熟悉，联调的时候出故障我都不知道啥原因咋修复，可能当时还得重新捋代码才能慢慢找根因，太影响联调的同学了。未来上线以后出现问题，想快速修复就更不可能了。 所以我专门花了两天时间，建了几个卡片，就为了学习代码理解代码。 那我是通过什么方式去理解AI生成的代码的呢？ 答案藏在一个用了二十多年的老工具里：UML。区别只有一点：以前的 UML 是人画给团队的，现在是 AI 画给你的。十四种图，从类结构到部署拓扑，从序列交互到状态变迁。AI 生成代码，AI 再画图解释代码——你读图就够了。 为此，我专门创建了一个Skill，用来生成UML的十四种代码和架构图、流程图以及泳道图。此skill的介绍：<a href="https://goal.rpcx.io/index_cn.html#step-diagram%EF%BC%8C">https://goal.rpcx.io/index_cn.html#step-diagram，</a> 也集成到了goal workflow套件中了。 本章分两部分：第一部分过一遍 UML 十四种正式图形，外加三种 UML 规范没有但实际很常用的图。第二部分介绍 insight-diagram——一个在 goal.rpcx.io 上发布的 Skill，给任意代码库自动生成全套 UML 图、架构图和流程图。

2026/6/28

Understand-Anything：代码知识图谱

<blockquote> "The goal isn't a graph that wows you with how complex your codebase is — it's a graph that quietly teaches you how every piece fits together." 目标不是一张让你惊叹「代码库真复杂」的图——是一张默默教你每个部分如何协作的图。 ——Yuxiang Lin, Understand-Anything 作者, 2026 年 </blockquote> Skills 拆能力。Spec 写合约。Ralph Loop 循环到对。gstack 角色覆盖。Goal Workflow 串流水线。autoresearch 全自动闭环。官方插件注入领域知识。每一章都在回答同一件事：让 AI 写出更好的代码。 本章不教 AI 写代码——教 AI 读懂已有的代码。 Understand-Anything 是目前「代码理解」方向上最成熟的开源项目：48.4K Stars，15 个 AI Agent 平台支持，最新版本 v2.7.3。作者 Yuxiang Lin。装上之后，Agent 不再靠 grep 和逐文件阅读理解代码库——先查知识图谱。 <img src="/images/image-20260601161740269.png">

2026/6/28

Anthropic 官方插件：AI Agent 的领域知识插件

<blockquote> "The decisive result came not from the model alone, but from the harness around it." 决定成败的不仅是模型本身，更是其配套的外围系统。 ——Anthropic Harness Engineering Team </blockquote> 第 2 章讲了 Skills 系统——Matt Pocock 的工程哲学：一个 Markdown 文件定义一种行为，小而可组合。第 6 章讲了 superpowers——社区级 Skills 库，十四个 Skill 覆盖十四个场景。 Anthropic 自己为 Claude Code 开发了 13 个官方插件。截至 2026 年 5 月，全部放在 Claude Code 仓库的 <code>plugins/</code> 目录下。和社区 Skills 不同，这些插件是 Anthropic 工程师为 Claude Code 构建的第一方工具——通过 <code>/plugin</code> 安装，深度集成到 hooks、agents、skills 三层基础设施中。 安装。 所有 13 个插件通过同一命令安装： <figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>/plugin install code-review </pre></td></tr></table></figure> <code>/plugin install <name></code> 从 Anthropic 官方源拉取插件，注册斜杠命令、hooks 和 Agent。<code>/plugin marketplace add</code> 可添加第三方源。安装后插件在 <code>~/.claude/plugins/</code> 下，可手动编辑配置。

2026/6/28

agent-skills：用生产级工程纪律武装 AI Agent

<blockquote> "Process over prose — workflows over reference." 流程重于文字，工作流重于参考。 ——addyosmani/agent-skills README </blockquote> 第 15 章讲 Compound Engineering 让每一轮工作沉淀知识，下一轮起点更高。第 14 章讲 improve 让强模型做审计、弱模型做执行。两章都在回答"怎么让 Agent 做正确的事"。 本章要回答一个更前置的问题：Agent 知道什么是正确的事吗？ 回答这个问题的人叫 Addy Osmani。 <img src="/images/image-20260620105908917.png"> 如果你写过前端，大概率读过他的书。他在 Google Chrome 领导开发者体验工程团队近 14 年，主导了 Chrome DevTools、Lighthouse、PageSpeed Insights、Core Web Vitals 等工具和标准的建设。2026 年转任 Google Cloud AI 总监，负责 Gemini、Vertex AI 和 Agent Development Kit。著有《Learning JavaScript Design Patterns》《Leading Effective Engineering Teams》，博客名篇《The Cost of JavaScript》从 2017 年到 2023 年持续更新了七年，几乎定义了 web 性能优化的讨论框架。他在前端工程和 web 性能领域的影响力，塑造了一整代前端开发者的工程实践。 2026 年初，他的注意力从"人怎么写更好的代码"转向了"AI 怎么写更好的代码"。2 月 15 日，他开源了 agent-skills，定位一句话："Production-grade engineering skills for AI coding agents"——把资深工程师的工作流、质量门禁和最佳实践，编码为 Agent 不可绕过的结构化约束。 到 6 月，近 60K star。 但这不只是又一个爆款开源项目。Osmani 在这个项目里做的事，和他过去十年做的事一模一样：把隐性的工程知识显式化。《Learning JavaScript Design Patterns》是把资深工程师脑子里的设计模式写成可学习的目录。Chrome DevTools 的文档是把调试技巧写成可操作的步骤。agent-skills 是把工程纪律写成 Agent 无法自我说服跳过的约束。 用 AI 写代码的人都会碰到一种熟悉的挫败感。Agent 接到任务，跳过规格直接敲代码。你说"先写测试"，它说"好的"，然后继续敲代码。你说"这里需要安全检查"，它说"明白"，然后加了一行 <code>// TODO: add auth</code>。你说"代码能简化一下吗"，它说"当然"，然后把三个函数合并成一个更长的函数。 Agent 不是不听话。它是真的不知道什么叫"先写测试""安全检查""简化代码"。这些是资深工程师花了好多年才内化的纪律，而 Agent 的默认行为是用最短路径把代码写出来，能跑就行。其他的都不在它的输出分布里。 agent-skills 要反转的就是这件事。它所有的设计决策，从七阶段生命周期到反合理化表到验证门禁，都指向同一个目标：让 Agent 像资深工程师一样工作。不是写代码更快，是不跳过那些让代码值得写的东西。

2026/6/28

Compound Engineering：让每一份工作都让下一份更容易

<blockquote> "Each unit of engineering work should make subsequent units easier — not harder." 每一个工程工作单元都应该让后续单元更容易，而不是更难。 ——everyinc/compound-engineering-plugin README </blockquote> 第 14 章讲 improve 把计划当作产品，让强模型做判断、弱模型做执行。省了 token。但还有一个问题没回答：省下来的 token 和时间，有没有让你的下一次工作起点更高？ 大部分 AI 编程工具解决的是"这一次"。帮你写代码，跑测试，合 PR。会话结束，上下文消失。下次开新会话，Agent 从零开始重新理解这个项目。构建命令是什么来着？那个奇怪的约定是因为什么历史事故？上次修那个 bug 踩了什么坑？全忘了。Agent 学到的东西，在你关掉终端的那一刻归零。 Compound Engineering 要反转的就是这件事。核心主张不是"让 Agent 这次做得更好"，是"让 Agent 下次起点更高"。每一轮工作结束时，把学到的东西沉淀回知识库，变成下一轮 Agent 启动时自动读到的上下文。用复利的方式做工程。 这个想法来自 Every 公司（Every.to），由 @kieranklaassen 和 @tmchow 维护。他们把这套方法论打包成 compound-engineering-plugin，MIT 开源，GitHub 18.3K+ star，随插件提供 37 个 skills 和 51 个 agents。支持的编码工具覆盖 Claude Code、Cursor、Codex、GitHub Copilot、Factory Droid、Qwen Code、OpenCode、Pi、Gemini、Kiro，几乎你能叫出名字的都在。

2026/6/28

improve：用强模型审计、让弱模型执行的"计划即产品"工作流

<blockquote> "The plan is the product." 计划才是产品。 ——shadcn/improve README </blockquote> shadcn 是谁，不用多介绍。他创建的 shadcn/ui 是 GitHub 上 Star 数最高的 React 组件库之一，11 万+，几乎凭一己之力改变了前端组件库的交付范式——不是"装一个 npm 包"，是"把源码拷进你的项目，你拥有它，你改它，你对它负责"。这种对控制权和所有权的执念，是他所有作品的设计 DNA。 2026 年 6 月，他在这个 DNA 上又加了一层——开源了一个叫 improve 的 Agent Skill。一周之内，5000+ star。 improve 做的事情，说穿了就是一句话：用最贵的模型读代码库、找问题、写执行计划，用最便宜的模型照着计划敲代码。它自己不碰源码，产出只有一种东西——计划。 这个分工背后是一笔所有用 AI 写代码的人都在付、但很少认真算过的账。用 Opus 读代码库、找 bug、排优先级，值。用 Opus 敲每一行代码、跑每一个测试、写每一句 commit message，不值。但现在的 AI 编程工具不管这些——你给它们什么模型，它们就全程用什么模型。预算好的团队手动切模型——研究阶段用 Opus，实现了切 Sonnet，跑测试了再切 Haiku。切来切去，时间都花在模型下拉菜单上了。 improve 把这个手动切换内建成了自动分工：强模型只负责判断。执行扔给最便宜的、够用的模型。

2026/6/28

GSD Core：对抗上下文腐化的阶段循环引擎

<blockquote> "Claude Code is powerful. GSD Core makes it reliable." Claude Code 很强大。GSD Core 让它变得可靠。 ——open-gsd/gsd-core README </blockquote> 第 12 章给了 Loop Engineering 一个很大的愿景：你不再提示 Agent，而是设计提示 Agent 的循环。但那一章停在原理层，讲的是五个原语加一个状态记忆。把这些原语落成一套能直接安装、有明确文件结构、带 67 个命令的工程系统，是另一回事。 GSD Core 就是这样一套系统。它不发明新的 Agent，也不取代 Claude Code，而是套在你已有的运行时上面，把讨论、规划、执行、验证、交付这五步，固化成每个里程碑都要重复一遍的流水线。它想回答的不是"Agent 能不能写代码"，这个早就不是问题了，而是一个更隐蔽的问题：为什么 Agent 在小任务上表现惊艳，一接手大项目就开始胡言乱语？ 这个问题有名字，叫上下文腐化（Context Rot）。本章讲 GSD Core 怎么把对抗上下文腐化当成第一性原则，用阶段循环、子智能体、持久化工件这三样东西，把一个容易漂移的编码 Agent 变成靠得住的工程伙伴。

2026/6/28

Loop Engineering：从提示 Agent 到设计循环

<blockquote> "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." 你不应该再提示编码 Agent 了。你应该设计循环来提示你的 Agent。 ——Peter Steinberger, 2026 年 6 月 7 日 </blockquote> 第 10 章搭了 Agent 的运行环境——hooks、权限、沙箱、配置继承。第 11 章用 Kanban 管多个 Agent 的并行编排。但有一个更根本的问题还没回答：每次都是你在提示 Agent。你打字，它回话，你再打字。你不在，它就不动。 2026 年 6 月，两条推文把这个矛盾推到了台前。Peter Steinberger（OpenClaw 作者）的那句话在 48 小时内获得 220 万次浏览。几天后，Boris Cherny（Anthropic Claude Code 负责人）在 WorkOS 的 Acquired Unplugged 活动上说了几乎同样的话："I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." <img src="/images/image-20260609032530128.png"> 全网炸了。但没人说得清"loop"到底是什么。有人说是 Ralph Loop 的翻版，有人说是"戴了顶帽子的 cron job"，有人说"prompt engineering 已死"。一周之内，Reddit、Hacker News、X 上的讨论翻了几十页，最诚实的回答是 Matthew Berman 那句："Nobody knows but him and Boris." Addy Osmani 随即发表了长文"Loop Engineering"，给了这个概念第一个完整的拆解。本章基于 Osmani 的框架，结合 Boris Cherny 的实践、Geoffrey Huntley 的 Ralph Loop 思想、以及 AlphaSignal 的四条件测试，回答三个问题：Loop Engineering 是什么？它和前十一章的方法论什么关系？你真的需要它吗？

2026/6/28

Kanban：用看板编排 AI Agent 项目

<blockquote> "You don't write the code anymore. You move the cards." 你不写代码了。你移动卡片。 ——leodavinci1, kanbots 作者 </blockquote> Skills 封装能力。Spec 写合约。Ralph Loop 循环到对。gstack 角色覆盖。Goal Workflow 流水线串联。autoresearch 全自动闭环。这些方法论解决的都是"一个 Agent 怎么做事"。 真实场景从来不是一个 Agent。是多个 Agent 同时跑在不同的 worktree 里，多张卡片分布在多块板子上，你不盯就没人在盯。 Kanban 管的就是这个局面。管 Agent。

2026/6/28

Harness Engineering：AI Agent 的工程实践

<blockquote> "The decisive result came not from the model alone, but from the harness around it." 决定成败的不仅是模型本身，更是其配套的外围系统。 ——Anthropic Harness Engineering Team </blockquote> Skill 封装能力。Spec 写规格。Ralph Loop 自己跑到对。gstack 用角色覆盖质量。Goal Workflow 串成七步流水线。autoresearch 全自动从 Issue 到合入。 这些方法论都在 Claude Code 之上运行。但 Claude Code 自己怎么造出来的？它调工具、读文件、写代码、执行 Bash——每一步都可能出错、可能越权、可能陷入死循环。谁在管这些？ Harness Engineering 回答的就是这个问题。不是"怎么用 Agent"，是"怎么造 Agent"。本章拆开 Claude Code 的引擎盖，看它的 hooks、settings.json、权限模型、沙箱、可观测性怎么拼在一起，把一个大语言模型变成可安全交付的产品。

2026/6/28

方法论对比与融合

<blockquote> "小孩子才做选择题，成年人当然全都要" ——网络梗 </blockquote> 前八章覆盖了七条路线。 Pocock Skills 拆能力。OpenSpec 写规格。Ralph Loop 自己循环到对。gstack 用角色覆盖质量。superpowers 让 Agent 替你选工具。autoresearch 一口气自动到合入。Goal Workflow 串成七步，每步等你说过。 每条路都能走通。真实项目从来不只走一条。Ralph Loop 做实现，谁来审查？gstack 走流程，需求从哪来？autoresearch 全自动跑，Issue 谁拆的？ 贪吃蛇案例已经验证了这一点。第 5 章 gstack 走了七个 Sprint 阶段，手工推着走，约两小时。第 6 章 superpowers 后台监听关键词，你答了五个设计问题，约五分钟。第 7 章 autoresearch 你写了一个 Issue，约三分钟，然后等结果。第 8 章 Goal Workflow 每步确认一下，从 PRD 到上线，约八分钟。 同一个贪吃蛇，同一个产出，四种交互模式。 本章把七条路摊开，看它们怎么拼。

2026/6/28

Goal Workflow：目标驱动的研发闭环

<blockquote> "你只需描述功能想法，剩下的交给工作流。" ——smallnest, Goal Workflow 作者, 2026 年 5月 </blockquote> 三条路。gstack 覆盖从需求到交付，但你得手动驱动每个阶段。superpowers 覆盖从设计到代码，但止步于开发分支。autoresearch 覆盖从 Issue 到合入，但它假设 Issue 已经存在。每条路都只解了一段。 实际项目不是这样的。实际项目从一句"我想做一个东西"开始。然后你要搞清楚它是什么、设计它怎么做、拆成小块、逐块实现、审查代码、记录决策、最后合入上线。七个动作，缺一个就是断点。每个断点都是你手动接续的地方。 Goal Workflow 做的事就是把这些断点接上。不是做一个更强的 /goal 命令。是做一条流水线——七个斜杠命令，首尾相连，从 PRD 到上线。

2026/6/28

autoresearch：全自动化软件开发

<blockquote> 「你只需负责喝茶和睡觉。一觉醒来，Features 全自动高质量的实现了。」 ——smallnest, autoresearch 作者, 2026 年 </blockquote> gstack 是人驱动流程，二十三个角色在七个 Sprint 阶段中协作。superpowers 是 Agent 驱动流程，十四个 Skill 自动触发，子 Agent 分工实现。两条路，一个共同点：人类仍然在循环中。gstack 需要你在每个阶段运行命令。superpowers 需要你在设计批准时确认方案。 autoresearch 把这个共同点也推倒了。 它的目标一句话就能说清楚：从 Issue 到合入，全程不需要人。你写好 Issue，Agent 自己实现、自己审查、自己修复、自己提 PR、自己合入、自己关 Issue。你喝茶。你睡觉。醒来看到一排绿色的 merged。 Karpathy 的 autoresearch 思想在软件工程领域落地了——82K Stars 的 ML 研究自动化项目，被 smallnest 适配成了通用的全自动开发工具。

2026/6/28

superpowers 技能框架：Agent 能力增强

<blockquote> "The agent checks for relevant skills before any task. Mandatory workflows, not suggestions." Agent 在执行任何任务之前，先检查自己有没有对应的技能。这些是强制工作流，不是建议。 ——Jesse Vincent, Superpowers 作者, 2025 年 </blockquote> gstack 用二十三个角色和七个 Sprint 阶段构建流程驱动的虚拟工程团队。CEO 审方向，工程经理锁架构，QA 测功能，安全官审漏洞——每个角色在固定阶段做固定的事。 superpowers 走相反的路。 superpowers 不定义任何角色。不强制任何 Sprint 阶段。它只做一件事：给你十四个 Skill，让 Agent 自己在合适的时机调用合适的那个。不靠流程锁住质量——靠每个 Skill 足够好用，Agent 自己愿意用它们。 201K+ Stars。当你不信任流程、只信任工具时，AI 软件工程能做多大——这个数字就是答案。

2026/6/28

gstack 方法论：虚拟工程团队

<blockquote> "I basically operate as an engineering manager for a fleet of temporary models." 我本质上是一个工程经理，管理一支临时工模型大军。 ——Garry Tan, Y Combinator 总裁 & CEO, 2026 年 </blockquote> Skill 是能力单元——一个 Markdown 文件定义一种行为。Spec 是合约，定义"做成什么样才算对"。Ralph Loop 是执行引擎，"做不到就继续做"。三者构成闭环：Skill 提供方法，Spec 提供标准，Ralph Loop 提供执行力。 但它们都隐含了同一个假设：你只有一个 Agent。 把这个假设推倒。如果你可以同时拥有二十三个 Agent，每个被赋予一个不同的专家角色——有人负责产品思考，有人负责架构设计，有人负责代码审查，有人负责质量测试，有人负责安全审计，有人负责发布部署——并且它们按照一个严格的 Sprint 流程协作。会发生什么？ gstack 回答这个问题。它是一个虚拟工程团队的操作系统。

2026/6/28