用原则名来转向

pstack 自带 24 条原则，每条都是一个单独的 skill。每个多步任务开始时，/poteto-mode 都会读一遍原则索引，用上这个任务触发的那几条，并在回复里点名用到的每条原则，说明它改变了哪个决定。

原则不用你去调用。你用的是它们的名字，拿来给 agent 指方向。每个名字背后都是一条完整的规则，agent 已经读过。所以一个短语改起方向来，比一大段指示还准。

转向的实际用法

比如 agent 正打算在三个已有的适配器旁边，再硬塞一个新的：

use subtract before you add. delete the obsolete adapters first, then design what's left.

比如它因为构建通过了，就说任务成功：

apply prove it works. run the real import flow and show me the written records.

比如两个并行的尝试正要往同一个分支里写：

separate before serializing shared state. give each attempt its own worktree, no locks.

这些短语管用，是因为背后的规则很具体。agent 仍然得在回复里说明，这条规则改变了哪个决定。如果引用了原则，背后却没有对应的决定，那就说明它只是报了个名字，并没有真正用上。

核心原则决定做多少，以及什么时候该重新考虑设计：

Laziness Protocol 优先删代码，优先选能解决问题的最小改动。
Foundational Thinking 先定下核心数据结构，再写逻辑。
Redesign from First Principles 接入新需求时，就当它从第一天起就在。
Attack the Premise 两个或更多修复都失败时，先写下这些修复共有的前提，直接检验它，再做下一次修复。
Subtract Before You Add 先减掉累赘，再往上加东西。
Minimize Reader Load 压平读者得记在脑子里的那些层次和隐藏状态。
Outcome-Oriented Execution 重写时直奔目标设计，不去保留用完就扔的兼容状态。
Experience First 用户得到的结果优先，实现上的方便靠后。
Exhaust the Design Space 没有先例可循时，做两三个互相竞争的原型。
Build the Lever 写出能完成或证明这项工作的脚本，让审查者能重跑。agent 老是拿手做同一件事时，让它写出自己希望手里有的那个工具或 skill。某一步每次都能用脚本做成一样，就用脚本，把 agent 留给要判断的地方。

架构原则决定状态、校验和兼容逻辑放在哪里：

验证原则规定什么才算证明：

Prove It Works 验证真实产物，不拿替代品充数。
Fix Root Causes 改代码之前，先复现问题，追到根因。
Sequence Work into Verifiable Units 每个小单元都以一次检查收尾，然后才开始下一个。
Test Behavior, Not Implementation 断言代码使用者能观察到的结果。这样行为出问题时测试会失败，只改内部实现时测试仍能通过。
Explain the Number 测出一个数字后，先说清是什么在限制它，再排除它其实测到了别的东西，然后才轮到有人相信或汇报它。/benchmark-checklist 把它落成七个问题，答案都要从真实跑出来的结果里来。

委派原则让并行工作不至于乱套：

还有一条元原则：

Encode Lessons in Structure 同一条建议你说过两遍，就把它变成 lint、检查或脚本。/correct 把这条用到整个仓库，见把它变成你的。

这份列表不用背。现在扫一眼就行。等哪天你发现 agent 在做的事，本来报一个这里的名字就能拦住，再回来看。这些名字就是这么记牢的。