Skip to content

pstack 拆解 10 · 委托与元 ​

一个人加一个模型,产出有限。想放大,就要让它委托、并行、长跑。而上下文、人的带宽、以及同一个错不该犯第二次,是三个硬约束。

这一篇讲这三条。

guard-the-context-window ​

守护上下文窗口的背后是一个资源判断:上下文是一种稀缺、且在一次会话里不可再生的资源。它不是"记性差一点",上下文一旦被填满、被压缩,推理质量就真的下降,而压缩本身还会引入失真。它和 minimize-reader-load 是同一件事的两面:那个说的是人的脑子,这个说的是模型的窗口,两者的约束是同构的。做法上就是两条:把大负载赶出去,让 subagent 读完几十个文件只回结论;把高频的小东西内联进来,模板和引用放进 skill 文件,不要每次重新读一遍。一句话,凡是会重复付出的成本,都要在架构上摊平。

它有一句判据:上下文窗口是有限的,而且在一次会话里不可再生。每个 token 都要对得起它的成本。

它的做法有三条,其中前两条看起来相反,其实互补。

隔离大负载。 冗长的输出、截图、大文档,路由给 subagent 去读。主上下文拿的是摘要,不是原始数据。举个具体的:你要在一处几十个文件里找一段逻辑,正确的做法是派一个 subagent 去读完那几十个文件,只把结论带回来,而不是让那几十个文件的原文都留在主线程里。

经常用的内容保持内联。 每次调用都要用的模板和引用,要放在 skill 文件里,不要放在一个每次都要单独读一遍的文件里。这一条和上一条不矛盾。上一条说"别把一次性的大东西留在主线程",这一条说"高频的小东西别每次都重新读一次"。凡是会重复付出的成本,一次内联就摊平了。

给阶段定尺寸,给范围设上限。 每个阶段动几个文件,给一次运行多少 turn,把各种机制本身的开销也算进去。一个阶段划得太大,做完之前就把窗口填满了。

never-block-on-the-human ​

不在人这里阻塞的背后是一条关于自主的边界线。人是在异步监督的,每一次等待许可都会让流水线停下,让人成为整个系统的瓶颈;而代码修改大多可逆、可复审,一个错误的决定通常比一次阻塞便宜。所以它把自主度的分界线画在可逆性上,不是重要性:可逆的自己做,不可逆的(force-push、部署、删数据、给客户发消息)才停下来问。很多人正好画反了,在可逆的事情上反复请示,在不可逆的事情上自作主张。这条原则要和"让系统自愈"一起用:发现一个问题,记下来、下一轮修掉,而不是当场停下来等拍板。

它有一句判据:人在异步监督,agent 必须保持不阻塞。

它的做法。

先做再呈现。 不要问"我要不要做 X",去做 X,解释为什么。

让系统自愈。 发现一个问题,记下来,下一轮修掉它,不要当场停下来等人拍板。

边界要划清,因为这条原则被滥用会把事情搞砸。

  • 不可逆的动作仍然要确认:force-push、删生产数据、给客户发消息。
  • 可逆的动作不要阻塞:写代码、编辑笔记、拆任务。
  • 产品方向来自人。执行不该阻塞。

encode-lessons-in-structure ​

把教训编码进结构的背后是一个关于约束的判断:机制优先于意图。一句需要被注意到、记住、然后照做的指令,是最弱的约束,因为它依赖人的配合;而一条 lint、一个类型、一个脚本,是不需要任何人配合就生效的。当多个机制都能用时,选最强的那个,因为有一条很准的经验:agent 会照抄周围代码已有的样子,一个更弱的守卫本身会变成下一个模板,错误会顺着模板继续复制。这也是一条反馈回路:每一次被纠正,都要在某个结构里闭合,而不是停在一次懊悔。在仓库尺度上,/correct 就是这条原则的实现。

它有一句判据:把反复出现的修正编码进机制(工具、代码、元数据、自动化),而不是加更多文字。

它的做法。

当你发现自己在第二次写同一条指令时,问一句:这能变成一条 lint 规则、一个元数据标志、一个运行时检查,或者一个脚本吗?能,就编码它,然后把那句指令删掉。不能(因为它需要判断),就把指令写得更醒目,并且附上一个失败模式的例子。

选最强的机制。 顺序是:一个无法被表达出来的状态,编译不过;然后是 lint 或禁用的 API,让 CI 失败;然后是提供一个规范的 helper;最后才是运行时检查。

推论。 如果修复是结构性的,就只用结构性修复。当你在写指令时,你处理的是症状,不是病。

它背后是一个完整的反馈循环。

  • 捕获每一次修正。人介入的时候,或者测试失败的时候,判断它是一次性的,还是一个模式。
  • 路由到正确的层。一次性的进笔记,重复出现的进 skill 或 lint,系统性的进原则。
  • 闭合循环。不要只是记下来,现在就应用,或者建一个具体可做的 todo。

它也有三个典型反模式,值得对着检查自己。

  • 承认但不记录。"我会注意的"不会留下来。
  • 记录但不路由。一条关于"应该有个 lint 规则"的笔记,在这条 lint 规则真的被实现之前,是浪费的。
  • 修一个实例而不泛化。修好了这一处,把重复的模式完好无损地留在原地。

/reflect 在会话尺度上做同一件事:从一次会话里挖出教训,路由到 skill 的编辑。/automate-me 则把这条原则用在你自身上,从你的历史里长出你自己的规则。

参考 ​

原文都在 pstack 上游仓库(cursor/plugins):