坚决打击吹牛逼
1.3K posts









introducing pi-dynamic-workflows This is probably going to be a bigger token burner than pi-goal, BUT, dynamic workflows is the first implementation of subagents that i don't hate, mainly because it's "code mode" for subagents. agent writes a js-based workflow DSL into a dedicated tool, engine parses the workflow code and runs it. the dsl implements some primitives for the agent (agent(), parallel(), pipeline(), phase() and log()) to keep it as simple as possible. now available in @badlogicgames pi! pi install npm:pi-dynamic-workflows




原本是重度 Claude Code 用户,在加入 Cursor 面试前从未用过 Cursor,这就是 @poteto,一起看看她是怎么使用 Cursor 的? lauren 认为:作为开发者,我们不应该过度沉迷于 "并行跑多个 agent" 的表象,但真正的瓶颈是验证。 从 Claude Code 到 Cursor 的转变 lauren 原本是重度 Claude Code 用户,在加入 Cursor 面试前从未用过 Cursor。她观察到三件事改变了她的判断: · 多模型协同的自然化:Opus 写前端、Codex 写系统,可同会话内切换甚至生成不同模型的子 agent。"多模型对抗式 review"在 GUI 中变得不再笨拙。 · Compaction 的速度:cc 中她需"持续警觉"上下文用量;Cursor 中她"基本不再看"。压缩后模型不会变笨。 · GUI > TUI 的潜力:在 Cursor 内置浏览器中直接打开应用、用 Design Mode 修改,让她意识到专用 UI 能让 agentic coding 更有效——CLI 把人本身变成了编排者。 关键洞察:Latent Demand(潜在需求) 引用 @bcherny 的产品哲学: 把产品做得足够可被"滥用",然后观察用户怎么滥用它,再为这种滥用建造产品。 她的判断是:CC 用户大量自建 orchestrator 工具的现象,正是 latent demand 的暴露——CLI 让人成为编排者,所以人们不停在外面包一层。 但她认为业界的方向走偏了:"在 GUI 里跑多个 CLI"完全没抓到要点。真正应该做的是建立对 agent 的信任。 Agent ≈ 失忆症且智商不在线的新员工 · 他们有能力但愚蠢,且高度可教 · 不会真的"学到"任何新东西,每次都从零开始 · 但可以通过 rules / skills / tools / 长期记忆近似出"经验积累" · 失败模式不是缺陷,而是教学机会 她作为前工程经理的视角点出了关键:没有严谨验证时,agent 会谄媚地写出你要的任何代码,而且写得飞快。 朴素的并行只是在加速生产 slop。 pstack:把工程严谨度封装成 skill 她开源了自己日常使用的技能集 pstack,核心机制是 /poteto-mode——一个高阶元技能,会根据任务自动选择合适的 playbook。 github.com/cursor/plugins… 设计哲学: · 目标不是 LOC 最大化,而是以最少代码换取最大影响 · 把资深工程师的方法论显式化(例如:调试 = 在问题空间中二分搜索) · 现成的 playbook 覆盖:技能编写与评估、自主工作、Bug 修复、特性开发、视觉一致性、原型对比 pstack 是模型无关的,但在 Cursor 这种多模型工具中收益最大——很多 skill 显式利用了不同模型的长短板。 Benny:通往"软件暗工厂"的雏形 后半段揭示更大的图景:当 pstack 让"一发入魂"成为常态后,反馈环本身也能被自动化。 Benny 是她构建的内部自动化 bot 链: 1. Triage(分诊):看图片/视频,主动追问复现步骤——因为没有清晰的 repro,agent 只能猜。 2. 跨源调查:代码、git 历史、Slack 关于同 bug 的讨论、Notion 中的产品设计决策(是 bug 还是 feature?)。 3. 建单后:另一个 Benny 通过 /orchestrate 接手,递归 spawn agent。 4. Computer Use 复现:Cloud Agent 在云端跑 Cursor 本身,用 CDP 等协议操作桌面,演示 bug 是否真实存在。 5. 修复 + 验证:性能问题会自动抓前后 CPU trace 和堆快照;子 worker 录制前后对比视频;最终一个 worker 开 PR,描述里附上视频。 最深的命题:信任的剂量决定自动化的边界 除非你能信任一个 agent 端到端地拥有一个问题(包括验证环节),否则你无法自动化你的流程。 也就是说: · 信任 ↑ → 可委派的问题 ↑ → 自动化范围 ↑ · 信任未到位 + 强行并行 = token 浪费 + slop 注入 这把"agent 编排"从工程问题重新定义为信任工程问题。pstack 是一个杠杆——它通过把工程深度灌注给 agent,抬升信任的下限,从而让更多东西可以放进自动化流水线。






