pigo 是一个类似pi coding agent的ai coding agent，使用Go语言开发。
你可以通过下面的命令安装它:
1 | curl -fsSL https://raw.githubusercontent.com/smallnest/pigo/master/install.sh | sh |
在配置文件配置（推荐），或者命令行中输入参数也可以：
尝试了它的功能，你一定好奇，这样一个功能完备的ai coding agent是怎么快速开发出来的？
开发这个项目主要有两个目的，而且这两个目的都达到了：
所以本文想从这两个方面分享从零开发这个项目的经验，同学可以各取所取，从不同的关注点了解这个过程。
继 prompt engineering、context engineering、harness engineering、loop engineering 之后，2026 年 7 月又冒出来一个新词：graph engineering（图工程）。
X 上照例吵成一团：有人说这是又一次新瓶装旧酒的炒作，"图"根本不是什么新东西；有人说循环（loop）已经过时，图才是 Agent 编排的终极形态。towards_AI 那篇《这该死的图工程到底是什么》给了一个很克制的判断：
There is no new product called Graph. And loops are not going anywhere.
loops versus graphs is the wrong argument. Graphs have loops.
这篇文章分三部分：先讲清楚图工程到底是什么（历史、概念、理论），再介绍一个把图工程做成可用工具的 skill —— goal-workflow 里的 /graph，最后拿我自己正在跑的一个真实项目 pigo，看看 /graph 跑起来到底长什么样、产出什么东西。
有人问我 superpowers 和 Matt 的 skills 哪个更好？这问题不好答。在我看来两者没有谁明显压过谁，就像你争论少林、峨眉、青城、武当哪家功夫最强，各人有各人的判断。
但也不能光和稀泥。下面我挑了四个生成 SPEC/PRD 的技能，把它们的功能摆到一起比一比——不为分个高下，只想看清各自的脾气。
其中 prd 是我参考 ralph loop skill 改造的一个需求文档生成技能。
| Skill | 来源 |
|---|---|
| brainstorming | obra/superpowers |
| grill-with-docs | mattpocock/skills |
| wayfinder | mattpocock/skills |
| prd | smallnest/goal-workflow |
TypeScript 名师 Matt Pocock 开源了一套 Claude Code Skills（https://github.com/mattpocock/skills）。据他在 X（Twitter）上的说明，这套 skills 的核心是 5 个命令串起来的一条主线：
/grill-with-docs → /to-spec → /to-tickets → /implement → /code-review
即：先把想法拷问清楚 → 写成规范 → 拆成卡片 → 动手实现 → 双轴评审。
这套 skills 的问题在于文档跟不上功能，很多人拿到手不知道怎么用。我此前也搭过一套类似流程，并用这套 skills 开发了一个 Go 版本的 pi agent（https://github.com/smallnest/pigo ，仓库里的 issues 都是这套 skill 生成的），因此对它的运作有一定了解。本文介绍这套流程。
安装命令：
1 | npx skills add mattpocock/skills |
「任何傻瓜都能写出计算机能懂的代码。好的程序员写出人能懂的代码。」——Martin Fowler
你有没有过这种感觉：打开一个文件，还没读懂逻辑，先皱起了眉头。说不上哪儿错了，但就是觉得"不对劲"。
这种"不对劲",有个专门的名字——代码坏味道（Code Smell）。
它不是 bug，代码跑得好好的；它也不是编译错误，测试全绿。它只是一种表面的征兆，暗示底下可能藏着更深的问题。就像厨房里飘来一丝馊味，东西还没坏透，但你知道该去冰箱里翻一翻了。
这篇文章讲三件事：这个词是怎么来的、坏味道到底有哪几类、以及——我怎么用一个 AI 技能，把一个真实开源项目的核心代码"闻"了个遍。
这是百度网络监控工具 nettools 开源系列的第四篇。前三篇分别介绍了 bitflip/baize（UDP 丢包与改包检测工具和Agent）、lidar（TCP SYN 端口可达性探测），它们解决的都是「服务器之间」「点到点」的探测问题——前提是：探测机和被探测对象，至少有一端在我们手里。
但有一类设备，我们既无法在它上面装 agent，也没法在它对面的机房里放一台探测机。这就是今天的主角 evr 要解决的困境。
这也是我更深入的了解网络包的构造，把网络探测玩出花了来，对我的网络编程的功力大增的一个很好的场景。
项目地址：https://github.com/baidu/nettools
文档：https://nettools.rpcx.io
先说一个真实的场景。
百度有大量的云客户，我们提供的 EVR（Edge Virtual Router，边缘虚拟路由器） 设备作为客户侧网络接入百度云网络的边界节点。EVR 往上连百度的骨干/城域网络，往下连客户自己的虚拟网络（VXLAN overlay）。
EVR - 边缘虚拟路由器，通常用于在虚拟化环境中实现路由功能。EVR 位于网络的边缘，用于连接内部网络和外部网络（如客户机房）。
现在问题来了：我们需要监控「百度网络 → EVR」这一段链路的健康度——有没有丢包、延迟多大、有没有改包。按照前几个工具的套路，我们的方案应该是：
lidar 那一套「发 SYN，靠对端内核 TCP 协议栈自动回 SYN-ACK/RST」的思路，在这里也不灵——EVR 不是一台服务器，它不会帮你跑 TCP 协议栈三次握手，或者说不允许我们高频的探测。
1 | 百度侧 边缘设备 |
困境的本质是：被探测对象不可控，且它对面也无法部署探测机。 我们需要一个 「单边」 就能完成的探测方案——只在百度侧放一台机器，让 EVR 设备自己「帮我们把包送回来」。
答案藏在 EVR 设备的工作原理里：它是一个 VXLAN VTEP（VXLAN Tunnel End Point）。而 VTEP 有一个非常好用的特性——它会忠实地按照内层 IP 头转发解封后的内层帧。这就给了我们「构造一个会被反射回来的 VXLAN 包」的可能。
要理解这个技巧，得先看懂 VXLAN 的包结构。
我把 775 篇收藏的文章塞进一个 4MB 的向量库，然后问它："我都收藏过哪些关于 loop engineering 的资料？"三秒钟，它把散在六七篇文章里的观点拼成一段答案，每条都带出处。
这不是什么 SaaS 产品，是我自己写的一个 skill，叫 chao-rag-wiki。今天聊聊它，顺便聊聊它背后那个问题：知识库越攒越大，你到底怎么"读"它?
得先从 Karpathy 的一个想法说起。
一千万条文档向量，用 float32 存要占 31 GB 内存。turbovec 把它压进 4 GB，搜起来还比 FAISS 快。
第一眼像是吹牛。它其实是 Google Research 一篇论文（TurboQuant）的工程落地，作者 Ryan Codrai 用 Rust 实现，配了 Python 绑定。下面先讲清楚它解决什么问题、为什么能做到这个效果，再上手跑一遍。
项目地址：https://github.com/RyanCodrai/turbovec
"Clear is better than clever."
清晰胜于聪明。
—— Rob Pike, Go Proverbs
第 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 工程的四个面：现代化（/modern-go）、性能（chao-go-perf）、并发（chao-go-sync）、风格（go-style-guide），外加一个把这几样打包、还顺带做了效果评估的全家桶（cc-skills-golang）。前三个是本书作者 smallnest 写的，对，写这本书的人和写这些 Skill 的人是同一个；后两个分别来自 madflojo（Benjamin Cane）和 samber。
