解读一下这个https://x.com/poteto/status/2097732320606507506

回复 joye： 这篇是 Lauren（@poteto，前 Cursor/Meta，现 xAI 做 gb）写的《The Complete Guide to pstack Pt. 2》。如果说第一篇讲的是怎么让 ca 自证（verification），这篇讲的就是怎么管一个写代码比你强的 ca——她靠这套方法在 8 月单月合了 2462 个 PR 到生产环境。 核心主线就一句：别搞抽象的 Plan Mode，用上下文对齐意图，用代码和原型代替文档做规划。 具体拆成四个关键机制： 1. 怎么喂上下文、对齐心智模型（防跑偏） 现在的头部模型写代码比人强，死扣实现细节的微操反而限制它，但放手又容易因为意图不清或缺上下文翻车。她的做法是“引出（draw out）”而不是硬灌： 一是间接提示（indirect prompt）：比如读完 Slack 报错先别改代码，让 ca 用自己的大白话重述底层问题。这能逼它压缩噪音、第一时间暴露理解偏差，还避免你先入为主带偏它。 二是 /teach（底层调 /how 和 /why）：/how 用 Grok 这类快模型并发探查跨目录的运行机制；/why 去并发扒 Git 历史、PR 评论、Linear、Notion、Slack、Datadog 和 Sentry，搞清楚当年为什么写成这样。有意思的是，让 ca 讲明白来龙去脉不仅是为了让人看懂，更是在逼 ca 自己读代码拿证据，别张嘴瞎编。 三是 /recall：跨会话捞历史聊天记录，不用每次开新窗口都重新攒上下文。 2. 怎么定义目标（逆向工作法） 她反对现在很多 harness 的 Plan Mode，因为往往过度指定实现细节，却漏了真正的目标。她推崇用 Readme 驱动开发：先写教程和用法（从调用方体验倒推架构）。为此她专门做了个 /technical-writing skill，用 Diataxis 框架把文档严格拆成教程、操作指南、API 参考、设计解释四类，再加 /unslop 去 AI 味。写出来的文档既是人看的说明，也是 ca 检验自己产出的明确靶子。 3. 怎么规划方案（用代码和原型，别空想） 她点出两个常见败招：直接接受 ca 给的第一个方案；或者在抽象计划上反复脑补对抗（这会让 ca 幻觉出根本不存在的理论风险和过度防御）。 她的解法是用并发原型代替纸面讨论： 一是 Prototyping playbook：在 /poteto-mode 下按需加载（省 token）。做功能或修 bug 时同时跑两三个临时方案，配合第一篇讲的 /control-app 自动操作界面、截图录屏、测耗时，拿真实跑出来的证据比选。 二是 /architect：针对大改动的五步闭环。先用 /how 和 /why 摸清现状；再进架构竞技场，跨不同模型家族并发跑多个 runner，只写调用端草图、核心类型和函数签名；接着用异构模型的 cross-judge 按严格标准评审合成；然后填真实逻辑；最后如果在实现里发现到处要打补丁或被迫用 any 强转，说明架构错了，直接全扔掉重来。 4. 什么时候才写执行计划 只有设计靠原型验证定稿后，才把设计转成战术执行计划。计划里的每一步都绑定了实跑验证（光过单测不算完，必须真跑起来验证），写成小而独立的 PR 逐个合入，做完就把临时计划文件从仓库删掉，不留垃圾。 最有意思的洞察其实在结尾：很多人爱用 Plan Mode 写长篇大论的计划，本质上是在买心理安慰，制造“我和 agent 干了很多活”的进度幻觉。在代码成本极低的现在，多写几个可丢弃的 prototype 跑通验证，比在 markdown 里改八百遍设计文档管用得多。