信任曲线：Verification、PStack 与 Dune

核心类比：管人与管 agent 同构。不信任下属 → 微管；不信任 agent → 紧盯每个输出，无法并行到几十上百。

问题： 资深工程师看到 agent 自信幻觉、第 N 次「找到 smoking gun」却找错，信任崩掉。信任不足时，你只能重度 in-loop：盯每个输出、手写提示。此时开 100 个 agent 没有意义——你连 1 个都不信。

Lauren 的曲线（非科学，是个人旅程）：

1. 低信任 / 高 in-loop： 少量 agent；你是瓶颈。
2. 爬坡： verification、skill、观察失败并编码。
3. 高信任 / 可并行： cloud agents 接信号；甚至 auto-merge；人在 main 上抽样。

她展示贡献曲线与信任上升同向：加入首月摸索；随后加速。口述：上月约 1000 个 PR；当月才 12 日已近 800。质量质疑合理；答案是「把 agent 设对」，不是否认质疑。

定义：让 agent 真实运行应用——跑代码、采 CPU/heap、开 iOS 模拟器、按用户路径操作——并自验结果。

它不保证「好代码」，但推动「正确代码」。这是信任的一大步。没有它，你就是 verifier：写完 → 你开本地 → 贴截图/日志 → 它再猜。无法并行。

Agents window（Glass）故事

• 入职本想进 cloud agents；因 React 背景被拉去支援即将上线的 agents window（内部代号 Glass）。
• 首周：自己看 Chrome DevTools flame graph；agent 看截图也自信乱指。
• 第一批 skill：Control Glass——教 agent 用 CDP 等程序化控制 UI、取证。代码本身不神秘；agent 也能帮你写类似 skill。

Feature map：有手还要有地图

能开应用仍不够。用户说「左侧栏卡」「PR tab 坏了」，agent 不知道功能在 UI 哪、怎么点到。于是乱逛，verification 形同虚设。

Feature map 写入：如何到达各功能、快捷键、CDP 选择器用的 DOM 属性等。有了地图，连含糊报告或一张截图也能映射到功能点。

Cursor 内部 Slack 反馈频道质量常很低。有地图后，agent 才能把低质信号变成可复现路径。

PSAC / PStack 里有 create verification skill 与 maintain verification skill：探索代码生成初始地图，并持续更新。

命名：P = Potato，对标 YC CEO Gary Tan 的 GStack（同姓无关，故意玩梗）。从未一开始就「做框架」；是 skill 堆出来的。

增量路径：

1. Control Glass（能跑、能点、能取证）
2. HAL：早期紧盯时发现——agent 自信归因，tool call 却没读本该读的代码 → 不信任爆发。管理类比：新员工会写码但无业务上下文，要用流程教。HAL 类 skill：停止幻觉、去搜代码、多用 sub-agent、禁止瞎猜。
3. Skill = Markdown，却能编码大量指令；用高质量前缀把生成拉到更「聪明」的模式（推特所谓换 latent space 的白话版）。

维护问题：改了 skill，怎么知道没变差？

• Eval ≈ agent 的单元测试。 不必神级框架；可自建。
• Eval playbook： 拉起子 agent 跑设定任务；尽量不让其知道「正在被评」（避免应试行为）。
• 可对多模型跑同一矩阵，看 skill 在常用模型上的表现。
• 产出分数 → 可循环到「全 10 分」；可用另一模型当 judge，降低同一模型自评偏置。

机制与 verification 同族：没有可观察分数，就无法 hill-climb。

本地自检稳定后：

• Slack 等信号进来 → cloud agent 开自己的电脑跑 Cursor → 用同一套 control skill 复现 → 回 PR。
• 团队与公司都受益；但仍是旅程。低信任区跳到「成千云端 agent」= 极贵且无效。

主持复述路径，Lauren 确认：verification → 本地信任 → 云端自主接单 →（她已到达的）auto-merge + 在 main 抽样。插件可加速，但不要盲信她或盲装 PStack；应 fork、改成自己的工程标准。

行业争议：该不该重写？入职看到代码常想推倒。Agent 时代前多劝别重写；Lauren 为强约束式重构做辩护，尤其针对 greenfield vibe code。

观察：大厂问题变成人人的问题。大厂用框架、约定、凭证限制，服务「团队里能力边界更宽的人」；在 agent 时代，这些护栏同样限制 agent 胡闹。Brownfield 若已有护栏，agent 已能干不少。

Greenfield 风险最大也机会最大： GrokBot 很快 vibe 出来；人几乎不读代码。无护栏时，agent 每次走最方便捷径 → 代码库螺旋失控（「有机架构」失控版）。

她为 GrokBot 迁入新架构投入极高（口述合计约 600+ PR）。代价是 token 与时间；换来：几乎不再看代码、半夜不必怕性能回退合入、PM/设计/GTM 也能加功能。写 GrokBot 代码「很烦」（约束多）；烦人由 agent 承受。

Dune：让最短路径等于正确路径

约束分层（强 → 弱）：

1. 架构与约定（agent 爱复制现有模式）——最强。
2. CI / lint / 编译诊断——硬红。
3. Bugbot 规则、skills、文风指南——偏软；可忘、可不稳定。只靠软层，代码库迟早崩。

技术栈选择也影响信任：如 Rust 编译器严，通过编译本身提供信心（仍要管住 unsafe）。

其他口味例子：她甚至倾向 禁止代码注释——观察显示 agent 注释常描述过时历史，反而有害。用更硬的结构与命名代替软注释。

产品侧问题：工程速度飙升后，产品和其他职能跟得上吗？

Lauren：GrokBot 之前，Cursor 工具链（agents window / CLI / IDE）偏 power user，知识工作能做但不舒服。GrokBot 界面像 iMessage，给 agent 起名、按「人」编排：

• 销售：一客户一 agent
• PM：汇总 Lauren 昨夜改动的 agent
• PM/设计直接修 bug 提 PR；她抽查常直接 stamp——说明 Dune 约束在替专家把关

这与推文「多 bot 组队」叙事一致：重点是可编排的身份化 agent + 熟悉界面，而不只是聊天补全。

前置：重构与加约束很烧 token。若未来代码主要由 agent 写，目标是保持精干，而不是长成万人工程组织的协调税。

工程领导的权衡：雇人做护栏，还是花 token 把仓库设成「最笨的 agent 也能做好」？她认为到达后者后，一般模型也能写得很好，红利外溢到整队。宣布 Grok 4.6：更强且称与 4.5 同价位推理成本，落在成本-智能 Pareto 上。

1. 管 agent 与管人很像：不信任就只能微管，放大不了。
2. 不信任一个 agent 的输出时，不要妄想开一百个。
3. 我现在让 agent 自动合入；今早约 20 个 PR 已在 main。
4. 工具箱里最重要的 skill 是 verification：真跑、真验。
5. 没有 verification，你就是瓶颈，谈不上并行。
6. 能控 UI 还不够；没有 feature map，agent 找不到功能。
7. PStack 不是一次性设计出来的；是对着失败模式一个个堆 skill。
8. 它自信下结论，却没读相关代码——这种幻觉最伤信任。
9. Skill 是 Markdown，却能把模型拉进更高质量的行为模式。
10. Eval 是 agent 的单元测试；改 skill 必须能回归。
11. 本地信任之前，不要上云开上千 agent 烧钱。
12. AI slop 之前先有 human slop；大厂护栏本就是为能力不齐的团队准备的。
13. Greenfield vibe code 无护栏时，捷径会让仓库螺旋失控。
14. 我把 GrokBot 迁到新架构花了极多 PR/token，才换来几乎不看代码。
15. 在 GrokBot 写代码很烦；让 agent 去烦，人去收约束红利。
16. 最短路径原则：agent 爱抄近路，就把正确做法变成近路。
17. 只靠 rules/skills/文风，代码库迟早变垃圾；要硬强制。
18. 人在 review 里反复纠正，应落成 lint/CI，而不是永远口头说教。
19. GrokBot 是非技术同事的 Cursor 时刻。
20. 信任曲线没有捷径；fork 我的 skill，建成你自己的标准。

1. 先做 verification skill（含真跑与取证）。 做对：你离开后它仍能迭代，而不是停住等截图。
2. 补 feature map，并设维护 skill。 做对：含糊 bug/截图能映射到可点击路径。
3. 观察失败 → 立刻写成 skill（如 HAL）。 做对：同类「自信不读代码」下降。
4. 为 skill 建 eval，改完就跑。 做对：你能说出分数，而不是「感觉更好」。
5. 本地信任后再接云端信号。 做对：Slack/工单能自动变 PR，且你敢抽查而不是全盘重做。
6. 不要在低信任区并行爆炸。 做对：token 花在自检环与约束，不花在盲刷云端会话。
7. Greenfield 尽早加硬约束，或接受受控重写。 做对：捷径与正确路径重合；新人/agent 少发明旁路。
8. 约束分层：架构 > CI 硬红 > 软规则。 做对：仅靠 Markdown 规则的比例下降。
9. 把重复 PR 评论变成 lint。 做对：同类评论从 review 里消失。
10. 鼓励原子 PR，便于回滚与审计。 做对：出问题能定位到小变更，而不是巨型杂烩。
11. 让非工程角色用更合适的界面（如 GrokBot）接入同一套护栏。 做对：PM/设计 PR 可抽查通过，不必你重写。

先给 agent 手、眼与地图，再用 skill/eval 与硬 CI 把捷径焊成正道。信任爬上来之前，不要用云端并行假装生产力。