月合 2000 PR：米其林厨房与 Agent 友好仓库

时间轴按论证块，不伪造精确秒点。

主张： 若把 agent 的环境设得足够好，产出可像个人或团队级「软件工厂」——更高质量、更高速率。

但她立刻改口： 不喜欢 software factory。更贴的是 Michelin kitchen：

• 技术工作仍有创造性，不是流水线量产。
• Agent 时代你可能不再亲自「切菜」，但仍对最终菜品负责。
• 编制（line cook / sous chef / dishwasher 比例）、设备、训练，决定能不能稳定出菜。

入职约 6 个月前（Cursor，并入 SpaceX AI 之前）：无现成 agent skill。任务是支援 agents window（IDE 替代方向）性能。PR 落地极快，她无法判断是否在回归。日常：Chrome DevTools、performance trace、heap snapshot——极度手工。

挫折点：「我们有 agent，我在干什么？」于是做 verification skill：让 agent 自己跑应用、采 trace、找热点，并对着指标 hill climb。

她强调：从未以「每月 2000 PR」为目标。技能、工具、仓库改造事后都归到同一主题——trust：自己是瓶颈；要把工程师知识灌进 agent 队，停止处处挡路。

早期阶段特征：

• 每个会话都要 babysit、纠偏。
• 人不在，事情停或做错。
• 想跳到约 100 个 agent / cloud agents，但信任不足 → 结果是 slop PR、回归、bug。

正确性定义：功能是否做了你要的事（结账按钮是否真结账）。Verification 给经验证据。它不自动等于性能品味或代码质量——后者要另铺 skill。

第一款 skill：Control Glass（经 CDP 跑 agents window 并取证）。迭代后固定两块：

1. CLI（放在 skill 目录内）

   • 目标：可重复跑应用、采证据、对照性能门槛。
   • 禁止每个 session 现场造脚本（不一致、费上下文）。
   • 要持续投资，覆盖真实用例。

2. Feature map（她命名；像 sitemap 的物化记忆）

   • 触发：Slack 来一张含糊截图 + 三个问号；agent 能跑应用却不懂用户指哪。
   • 内容：有哪些功能、如何到达、快捷键、点哪个 DOM、功能做什么。
   • 存在 skill 目录；有自动化维护。
   • 与 CLI 组合后：既能控应用，也能理解内外用户请求。

结果：verification 变成团队关键基础设施，持续维护。

Verification → 正确性。高质量还要：调试、做功能、做原型等 playbook。PStack（Potato Stack）是她的 skill 集合；资深工程师应共建团队 skill 库。与 verification 叠用：既证明做对，也证明做得像样；并可收集真实性能遥测。

她给出连续统。推荐投资顺序：越硬越优先。

只靠文风与人肉评论 = 流程大洞。人审适合发现缺口，不适合当唯一执法。

Dune = GrokBot 的 agent 友好客户端框架。灵感来自 agents window 性能坑。核心原则：

Agent 爱抄近路 → 把容易走的路设计成正确的路。

对人可能「很烦、很锁」；对上下文很少的 agent（以及设计/PM/CEO 驾驶的 agent）反而合适。

反模式病毒与禁注释

小 workaround 或「解释性注释」会被 agent 复制；几天到几周可变成默认模式。更糟：agent 用注释合理化「为什么不修根因，只打补丁」。Dune 禁止代码注释，挡住这条传播路径。

Gardener（园丁）角色

每个团队需要有人早期识别杂草/虫害（反模式），在扩散前掐掉。Dune 三原则：

1. 删已有技术债（减少可复制坏样板）。
2. 单一铺好的路（blessed path）：一事一法；CI/lint 引导走上它。
3. 见坏模式先写 lint 止血——不必总能立刻清完；先停止扩散，再让 agent 清理。

心智模型：保持仓库处于「你乐见 agent 复制」的状态。

结构例子

• Feature 共置单目录；entry point（类似路由）；transcript cards；host（VM）与 client 分离。
• Electron：main 与 renderer 严禁混用（agents window 曾把慢代码误导入 renderer）。
• 渲染预算：60 FPS → 每帧约 16ms；120 FPS → 约 8ms。用 import 依赖图硬执行边界。

主题不是「必须用 Dune」，而是：自建 agent 友好框架，把部落知识从人审评论抽进仓库记忆。

GrokBot 擅长 outer loop：接 Slack、DataDog、Sentry、PlanetScale 等，汇总后决策。有人叫 company brain；她认为不必神化——agent 本来就会用工具。

机制：

• GrokBot routines：订阅 Slack 线程、Sentry 告警等，自动触发。
• 自动拉起 cloud agents。
• 再叠加 Cursor automations / SDK，复用同一套 agent 基建做更复杂任务。

仓库 + rules + skills 与外环复利：自动复现 bug、自动开 PR，价值落到整队。她再次划掉 software factory，改称个人 mission control kitchen。

每当你发现自己在纠正 agent，按此顺序选最有效的一层：

1. 改仓库 / 架构 / 数据结构 → 让该错误范畴上不可能。
2. 加静态分析（lint / CI）。
3. 再叠 rules、Bugbot、skills。
4. 并用质量向 skill 教「如何像好工程师工作」。

做完后，你信任的是环境，agent 才能「自由」。她说这不是秘密，是大量苦工；GrokBot 仓库是她亲投下的例子。联系：X @potato（带 e）。

1. 上月合入约 2000 个生产 PR；能力来自「我不在时仍可信」。
2. 不喜欢 software factory；更像米其林厨房——你仍对最终菜品负责。
3. 早期性能工作全靠人手 DevTools；我才是瓶颈。
4. Verification：让 agent 自己跑、自己采证、对着指标往上爬。
5. 1–5 个 agent 的 babysit 阶段最难爬出；无信任勿开 100 个。
6. 无信任的云端并行 = slop PR 与回归。
7. Verification 有光谱：CDP skill 可走很远；形式化仍难。
8. Control Glass 要固定 CLI，不要每个会话重写脚本。
9. Feature map 是物化记忆；否则模糊截图只能瞎猜。
10. 正确性 ≠ 质量；PStack 教像工程师一样工作。
11. 仓库是最佳记忆；agent 默认扩展所见模式。
12. 重复犯错 → lint；更好 → 让错误变得不可能。
13. 只靠 style guide 人审，在高 PR 速率下会垮。
14. Agent 爱捷径 → 把捷径设计成正道（Dune）。
15. 反模式像病毒；注释可变成「不修根因」的借口，故禁注释。
16. 团队需要园丁：先止血（lint），再清理。
17. 把部落知识从评论区抽进框架，让仓库成为可复制的好快照。
18. GrokBot 做外环：routines 订阅信号并拉起 cloud agents。
19. 不需要神话公司大脑；接好工具就会用。
20. 纠偏时优先让错误不可能，而不是再写一条软规则。

1. 把 verification 建成带 CLI 的 skill。 做对：不同 agent 取证路径一致，不再现场造脚本。
2. 加 feature map + 自动维护。 做对：含糊截图能变成可复现路径。
3. 正确性与质量分开投资。 做对：有 verification 证据，也有工程 playbook（如 PStack）。
4. 按五层从上到下加固。 做对：重复人审评论下降；同类错误变 CI 红或根本写不出来。
5. 见反模式先写 lint 止血。 做对：坏样板停止扩散，再安排清理 PR。
6. 设计单一铺好路径。 做对：新 agent / 非工程驾驶者也默认走上同一结构。
7. 审视「无害」模式（如注释）是否在被复制成敷衍。 做对：合理化补丁的借口变少。
8. 指定园丁职责（人可轮值）。 做对：杂草在早期被发现，而不是月后成林。
9. 用 GrokBot routines 接外环，再踢 cloud agents。 做对：Slack/Sentry 类信号减少人手渡船。
10. 纠偏时先问能否让错误不可能。 做对：规则文件不必无限变长，仓库形状在替你执法。

先建可自检的厨房（verification + 硬仓库），再接外环自动上菜。2000 PR 是信任与环境的结果，不是把聊天窗开到 2000 个。