pstack 0.15.6 → 0.15.9：这四个小版本，其实都在做同一件事

少靠 Agent 记住规则，多让流程、架构和代码库本身把错误挡住。

pstack 这轮更得很快。

从 0.15.6 到 0.15.9，四个小版本几乎连着来。单独看，每一版都不像什么“大更新”：加一个 skill，改一下 /architect，调整一下性能 playbook。

但把四个版本放在一起看，方向其实特别统一。

它们都在解决同一个问题：

Agent 会犯错，而且光靠“提醒它别犯”没什么用。

所以这轮 pstack 做的事情，不是继续往 prompt 里塞规则，而是一步步把正确性往更底层推。

0.15.6 先问：你测出来的数字到底靠不靠谱？

0.15.7 再问：同一个错误为什么还要让人纠正第二次？

0.15.8 接着问：如果 Agent 只看了一个文件，架构能不能保证它仍然走对路？

到了 0.15.9，连性能优化的思考顺序也被重新收紧：别一上来就想着怎么优化，先问这件事到底需不需要做。

这几版放在一起，比单看 changelog 有意思得多。

---

0.15.6：你测出了一个数字，然后呢？

0.15.6 里我觉得最值得看的，是新增的 Explain the Number 原则，以及 /benchmark-checklist。

做性能优化的时候，Agent 很容易给你一个看起来很有说服力的结论：

优化后快了 37%。

问题是，37% 这个数字本身几乎什么都证明不了。

请求是不是有一部分直接报错了，所以反而更快？

真正想测的代码到底有没有执行？

一边是不是 release build，另一边还跑着 debug 配置？

是不是缓存命中了？

是不是 load generator 自己先跑满了？

甚至还有一个很朴素的问题：

为什么不是快两倍？

这也是新版 benchmark checklist 里的第一问。

如果一个改动让性能提升了 30%，那剩下的时间到底卡在哪里？

CPU？锁？磁盘？网络？数据库？还是压测端自己？

如果这些都说不清，其实就说明一件事：

你有一个数字，但你还不知道这个数字在描述什么。

所以 0.15.6 开始要求 Agent 在汇报 benchmark 之前，把 limiter 找出来，并把几个最容易让测试结果失真的因素一个个排掉。

它会检查两边有没有按生产方式调优，有没有错误请求，结果能不能重复，跑出来的差距是不是大过自然波动，以及这个 micro benchmark 对用户真正等待的端到端路径到底有没有意义。

还有一个特别容易被忽略的问题：

被计时的工作到底真的发生了吗？

生成器没人消费、Promise 没有 await、结果被优化器直接丢掉、请求实际上超时了，这些情况一样可以跑出一个“很漂亮”的数字。

所以 0.15.6 并不是单纯多加了一套性能测试 checklist。

它实际上是在给 Agent 增加一条很重要的约束：

数字不是证据。解释得通的数字才是。

这一版里还有一些看起来不大、但实际很有影响的调整。

比如子 Agent 现在默认倾向于新开一个，而不是一直 resume 旧的上下文。只有手里还握着本地修改、dev server、simulator 之类状态的时候，才有必要继续复用。

长期运行的 autopilot 也改成明确使用 /loop 1h 做每小时审计，不再靠 Agent 自己“记得过一会儿回来检查”。

PR 的格式也进一步收紧，开始要求用真正的 ## 标题把 Why、What changed、Scope、Blast Radius、Verification 这些内容分开；如果运行环境本身已经提供 PR 工具，也优先走内置工具，而不是一律自己调 CLI。

还有 TypeScript 的例子，也从“手工判断一遍之后再 as”换成了 schema-first 的写法。

这些东西表面上分散，其实都是一个意思：

别相信“看起来做完了”，让系统自己留下可以验证的证据。

---

0.15.7：别再让人纠正同一个错误

0.15.7 新增了一个我很喜欢的 skill：

/correct

它处理的是一个用 Agent 写代码的人基本都遇到过的问题。

你跟 Agent 说：

“这里不要这么写。”

它改了。

过一阵子换了一个 Agent，又这么写。

你再提醒一次。

传统的处理办法通常是去 AGENTS.md、rules 或 prompt 里面再补一句：

“以后禁止这样做。”

然后希望下一个 Agent 能看见、能记住、还能正确理解。

/correct 的思路完全不是这样。

它的逻辑是：

如果同一种错误已经需要人纠正第二次，那就说明这个问题不应该继续靠提醒解决。

它会去看最近的 commit、revert、review comment、Agent instruction，以及代码里那些解释 workaround 的注释，把这些反复出现的问题归成“错误类别”。

同一类问题出现两次，就值得处理。

然后它开始往更底层修。

优先级最高的不是加文档，而是改架构。

如果同一个状态有两个模块都能写，就让它只剩一个 owner。

如果同一件事情有两条实现路径，就保留一条，把另一条删掉。

如果某个 internal module 不该被外面用，就让那个 import 根本无法通过。

如果两份列表每次都要人工同步，就改成只维护一个 source of truth，其他地方自动生成。

架构实在解决不了，再往类型系统里塞约束。

类型也挡不住，再做 lint 或 CI。

然后才是测试。

最后实在属于人的判断，才写进文档或者 Agent rule。

这套顺序其实很关键。

因为每往前一层，正确性对 Agent “记得规则”的依赖就更少一点。

而且 /correct 还有一个我觉得特别对的要求：

新增的检查不能只证明自己能跑，而要拿一个过去真实发生过的错误来证明它真的能挡住。

以前发生过的坏改动，拿回来跑。

新规则应该让它失败。

这才算真的补上了。

最后，/correct 还要求在 Agent instruction 里维护一张“规则对应什么 enforcement”的表。

哪条靠架构保证，哪条靠 type，哪条靠 lint，哪条靠 test，一眼能看到。

如果一条规则明明已经写在文档里，Agent 还是第二次犯了，那答案也很明确：

不是再把那句话加粗一遍。

而是说明这条规则还没有真正被系统执行。

---

0.15.8：架构不仅要给人看懂，还得扛得住 Agent

0.15.8 没有新增一个很显眼的 slash command。

它主要改的是 /architect。

但如果刚看完 0.15.7 的 /correct，这一版其实很好理解。

因为它开始把“Agent 会怎么改代码”直接当成架构设计的一部分。

以前我们评估一个架构，通常会看这些东西：

模块边界清不清楚，职责有没有分开，接口是不是足够小，状态放得合不合理。

现在 pstack 又加了一个更现实的假设：

下一个来改这段代码的人，很可能是一个只看了局部文件的 Agent。

它不会天然知道整个系统为什么这么设计。

它大概率会做三件事：

打开几个相关文件。

复制最近的例子。

走那条最容易编译通过的路。

所以新版 /architect 在筛选设计方案的时候，开始多问一个问题：

如果贡献者只看到了一个文件，这个文件里看起来最顺手的改法，对整个 repo 来说还是正确的吗？

这次因此新增了几类很典型的 architecture red flags。

第一种是 split ownership。

同一份状态有多个模块都能写。

对一个熟悉项目的人来说，也许知道“正常应该改 A，不要碰 B”。

但 Agent 不知道。

它看见 B 也能写，就会直接写。

第二种是 two ways to do one task。

同一件事有两套 API、两套 helper、两条路径。

人可能知道哪条是新的，哪条已经废弃。

Agent 更可能复制自己先搜到的那个。

于是旧路径永远有人继续用。

第三种是 importable internals。

你嘴上说某个文件是 internal，但外部其实照样能 import。

那对 Agent 来说，这就不是 internal。

它只知道：

这条路能编译。

最后一种是 hand-synced list。

两个地方保存同一份列表，新增一个项目时要两边一起改。

这种设计几乎就是在等 Agent 漏掉其中一处。

所以 0.15.8 给的答案也很直接：

一个状态，一个 owner。

一件事情，一条正式路径。

Internal 就真的不能从外面 import。

重复列表就从一个源头生成。

这版让我觉得比较有意思的地方，是它把“Agent-friendly”这个词往前推进了一步。

真正对 Agent 友好的代码库，不是写了最多 Agent 文档的代码库。

而是：

Agent 即使只看到了局部，也很难做出一个局部合理、全局错误的修改。

---

0.15.9：性能优化别先想技巧，先想能不能不做

到了 0.15.9，改动又回到了性能流程。

之前 Perf issue playbook 里有八类性能优化策略。

Elimination、Caching、Batching、Lazy evaluation、Scheduling……

Agent 会根据 trace 去找适合的策略。

0.15.9 把这一块砍得很干净。

现在变成七句话，而且要求按顺序想：

Don’t do it.

能不做，就别做。

Do it, but don’t do it again.

必须做，也别重复做。

Do it less.

能少做一点，就少做一点。

Do it later.

不必现在做，就往后放。

Do it when they’re not looking.

别把工作塞在用户正在等的路径上。

Do it concurrently.

能并行就并行。

Do it cheaper.

最后，才是想办法把这件事本身做得更便宜。

这个顺序比具体有哪些优化技巧更重要。

因为 Agent 一看到 hot path，很容易直接掉进“怎么把这段代码变快”的思路里。

然后开始换算法、搞缓存、加并行、改数据结构。

但最便宜的优化往往根本不是“把它做快”。

而是：

为什么要做？

如果整个操作可以删掉，就不用优化。

如果只是重复执行，就别重复。

如果只需要做一小部分，就别全做。

如果用户现在根本没在等它，就把它挪出去。

直到这些都不够，再去碰“怎么把同样的工作做得更快”。

新版 Hillclimb 也开始借用这套顺序来排列 hypothesis。

所以现在 pstack 的性能流程，两头都加上了约束。

开始之前：

别急着优化，先判断这份工作要不要存在。

结束之后：

别急着相信数字，先解释清楚这个数字为什么成立。

这两个变化其实是连着的。

---

把四个版本放在一起看

这四个版本单独看都不算大。

但连起来以后，pstack 最近在做什么就很清楚了。

0.15.6 开始约束“证据”。

0.15.7 开始把人的纠正变成代码库里的硬约束。

0.15.8 开始让架构本身考虑 Agent 的局部视角。

0.15.9 又把优化顺序从“找技巧”改成“先消灭没必要的工作”。

它们有一个共同点：

都在减少对 Agent 自觉性的依赖。

Agent 记得看文档当然很好。

Agent 记得按约定调用正确 API 也很好。

Agent 每次 benchmark 都主动怀疑自己的数字更好。

但工程系统不能建立在“它这次应该会记得”上。

真正可靠的做法，是把这些东西逐渐往下沉。

能用架构解决，就不要靠规则。

能用类型解决，就不要靠提醒。

能让 lint 直接报错，就不要等 review 才发现。

能自动生成，就不要让两个文件靠人同步。

能验证，就不要凭感觉相信结果。

这也是我觉得这轮 0.15.6 → 0.15.9 最值得关注的地方。

pstack 越来越不像“一堆让 Agent 更会写代码的 Skills”。

它更像是在做一套 Agent 工程的约束系统。

目标不是让 Agent 永远不犯错。

这个目标本身就不现实。

真正能做的，是让系统里的错误越来越难发生，发生以后越来越容易被发现，发现以后又能把这次教训固化到下一次。

换句话说：

不是要求下一个 Agent 更聪明一点。

而是让下一个 Agent 就算没那么聪明，也更难把事情做错。

---

如果你是第一次接触 pstack，可以先从中文站的入门路径开始，不用一上来把所有 skill 都看完。pstack 本身更像一套有角色、有流程、有验证机制的 Agent 工程工作流，核心不是“让 AI 多写代码”，而是少写、写对，并让每一步都能验证。

pstack 中文站： https://pstack.ganhai.cloud/