七个ClaudeCode智能体造应用

这期是你整本知识库里最贴近你两条主线的一期：Gabor 干的事，几乎就是你 app_incubator「7-Agent 造 App 链路」和 Holdwell「多-Agent PRD 工厂」的真人实拍版。他不是在讲理论，而是把「一整家软件公司复刻成一队专门 agent、PM 当总指挥」从头跑了一遍，连翻车都没剪。所以下面给得很实——能直接对到你正在配的角色、正在搭的契约、正在卡的关。

🏗️ app_incubator（7-Agent 造 App 链路）—— 直接对口，照着抄

1 · 「设计稿即工程强制契约」他用一条铁律落了地：每张前端工单必须附 Figma 截图

• 怎么做的：Gabor 把这点强调到「我怎么强调都不为过」。他让 system analyst 把设计拆成「小颗粒」前端工单时，每张工单都钉一张 Figma 截图、精确到屏幕的某一块区域（演示里点开工单直接跳到 Figma 选中的那块）。他把不这么做的后果讲得很形象——「如果你不加截图，agent 就会做出那种典型的『一看就是 AI 做的』app，黑紫配色、一眼 AI 范儿，而不是你 Figma 里设计的样子。」更狠的是他还演示了反例：设计阶段他偷懒没走工单、直接把整份 spec 丢给 agent，结果「context 太大、中间发生压缩、细节丢了」，最直观的证据是「我连一个橙色元素都没看到」——调色板根本没被用上。
• 你可以怎么做：你的「设计稿即工程强制契约」目前是个原则，他给了你执行点——别让契约停在「应该参照设计稿」，而是做成「没有截图/Figma 链接的前端工单，agent 不许开工」这种硬门。具体两步：①在你的工单模板里把「Figma 截图/帧链接」设成必填字段；②给造 App 链路加一道 gate——开发 agent 拿到工单先校验有没有视觉锚点，没有就打回 system-analyst 角色补。他的翻车案例就是你的反向测试用例：一旦允许「整包 spec 直灌」，压缩就会偷偷吃掉你的设计细节。

2 · 把「该做什么」前移——他靠一个 System Analyst agent 当唯一中枢

• 怎么做的：Gabor 反复说「我用得最重要的一个就是 system analyst agent」，因为它既出文档、又出开发工单，两条产出都归它，所以整套协作都围着它转（主持人直接叫它「system analyst agent 网络」）。它的 prompt 有两条你会想抄的设计：①「先问问题、别急着写」——「有些 LLM 特别爱立刻开始写，所以我告诉它别开始写、先问」；②「一次只问一个问题」——「它一上来甩 25 个问题你会招架不住，一次问一个对话就线性多了」，prompt 原话是「请一次只问一个，因为问太多我可能招架不住」。还有一条边界设定：「这是你唯一能用的空间和看板，别通过 MCP 碰任何其他项目。」
• 你可以怎么做：你一直想把「该做什么」从人前移到 agent——他给了最省力的落点：让你链路里那个对接需求的角色既产出规格、又产出工单，并强制它「先澄清、一次一问」。把这两条写进该角色的系统提示，你的激活/首屏需求就不会是你一次性想全、而是 agent 一问一答帮你逼出来。那条「只能碰这一个项目」的边界，对你接 Figma/Chrome/Notion 多个 MCP 的链路尤其值钱——给每个 agent 圈死它能动的资源范围，防止它在你真实账号里乱伸手。

3 · 用「小颗粒工单 + 聚焦上下文」替代「一个大 prompt 出成品」

• 怎么做的：全片总纲就一句——专业化 > 通用化，小颗粒工单配聚焦的 agent 上下文。每个 agent 只吃自己那摊的小上下文（前端只看前端工单、CTO 只管架构），而不是让一个 agent 抱着整个项目。他对「一个 prompt 一步出成品」的 vibe coding 旗帜鲜明反对，引了 Reddit 那句戳中他的话：「vibe coding 不过是给没法维护的低质量源代码换了个马甲。」
• 你可以怎么做：这正面回答了你「把该做什么前移到 agent」的设计哲学——前移不等于让一个全能 agent 大包大揽，而是把活切碎、每个 agent 只在自己窄上下文里做决策。你的 7-Agent 分工本就是这个方向，他的证据让你更敢往「角色更专、单 agent 上下文更小」走，而不是图省事合并角色。

🏭 Codex Holdwell ERP work（多-Agent PRD 工厂 / 三驾马车 · 碰撞协议 · 真人评审）—— 你的痛点他几乎逐条命中

4 · 你的「碰撞协议纪律怎么强制」，他用「写代码前全员评审、各出一审视角」补上了

• 怎么做的：写任何代码之前，Gabor 坚持「让整个团队都来发表意见」。理由讲得很白——「每个 agent 角色不同：一个管可维护性，一个管隐私设置到位……所以在真正写代码前，让它们每一个都在开发工单里贡献自己的视角。」演示里他一口气点名五个角色各盯一摊：designer 查截图与信息量、tester/test-architect 保测试与回归覆盖、code-maintainability 盯命名与注释、product-council 查数据只存设备端。评审是「卡在写代码前」这个硬节点上发生的，不是事后补。
• 你可以怎么做：你的三驾马车和碰撞环节都在，缺的是「纪律的强制执行点」——他给的答案是把评审焊死在「生成最终交付物之前的那一道关」：在进入④合成定稿之前，让 UX 与 tech 各自在工单上交齐碰撞三件（补强/修正/第 3 案），没集齐就不许过。他的「全员各出视角」就是你碰撞环节的运行时形态——你已经定义了角色，他示范了怎么让碰撞变成一道过不去就堵住的门，而不是一份没人读的 checklist。

5 · 你的「跨线对齐」，他用 System Analyst「映射依赖关系」给了做法

• 怎么做的：system analyst agent 的核心职责之一是把依赖关系（哪件事必须先于哪件事做完）妥善记录。因为 MCP 没权限建真 sprint，他变通用「标签 tag」把工单标成 sprint one / two 来表达顺序，理由是「做软件有依赖关系，得确保有些东西先做完别的才能开始」。规格本身也写得极结构化——Confluence 里一棵完整空间树（产品概览 / 技术架构 / AI Agent 规格 / 屏幕与 UX / 数据隐私 / 用量限流），AI agent 规格甚至细到「①接收查询 → ②向量化 → ③检索 → 评估置信度 → 退到情境手册 → 兜底在线搜索」一条条可执行步骤。
• 你可以怎么做：你六条产品线强耦合、跨线实体依赖没人显式画出来，他给了**「谁来画、画成什么形状」：让你那个对接需求的中枢角色（product-manager），在出工单的同时显式产出一张实体/依赖图**（A 必须先于 B），就像他用 tag 标 sprint 顺序那样。他那棵 Confluence 空间树可以直接当你跨线知识底座的目录骨架范本——先把空间树立起来，agent 往里填，跨线就有了共同语言。

6 · 你的「agent 产出缺可观测/可验证」，他给了「observer mode + 翻车 bug 当演示故事」这套打法

• 怎么做的：Gabor 在 app 里加了 observer mode——打开能看到后台搭了什么、知识库有哪些、用了多少 token、延迟多少，专为「给别人演示、走一遍后台怎么运作」而设计。他还主动记录自己挖出的 bug当演示素材：评分系统分不清单复数（penalties vs penalty、boarding vs board）+ 阈值太严，导致没命中正确章节。他特意留着这个故事，因为「讲这个 bug 怎么影响真实用户体验，是一个很好的演示故事」。
• 你可以怎么做：你的 agent 产出缺「可观测/可验证」——他的思路是把过程本身做成可展示的证据链：①给你的 PRD 工厂加一个「observer 视图」，记录碰撞协议每一步 agent 做了什么决策、卡在哪、消耗多少（AG 工单目录就是现成挂载点）；②把翻车的案例（比如独立初稿被互看的、评审意见没回炉导致的返工）专门留档当「故事」，而不是修完就删。Gabor 证明：一个带前后对比的真实 bug 故事，比一句「跑通了」有说服力得多——这就是你要的可验证证据的形态。

7 · 你的「跨线对齐」，他的镜子：消灭人类团队的责任推诿

• 怎么做的：Gabor 说这套体系最让他舒服的，是消灭了真人团队里那种没完没了的责任推诿——「以前总有扯皮：这一步谁做？这个『如果就』谁定义？边界情况谁想？『不，那是 system owner 的活』『不，那是 PM 的活』『不，那是 developer 的活』。这正是我喜欢它的地方。」因为每个 agent 角色边界是写死在 prompt 里的，扯皮没了生存空间。
• 你可以怎么做：你卡在「跨线对齐」——他这句是面镜子：当职责边界是显式写进定义文件的，对齐就从「开会吵谁该管」退化成「读一遍各自的 charter」。三驾马车的边界已经写死在 .Codex/agents/*.toml 里，跨线之所以还难对齐，可能正因为六条产品线之间的边界没写到「一看就知道这事归谁」的颗粒度。先把每条产品线「归谁管、上游是谁下游是谁」用一句话钉死——对齐成本会塌下来。

📈 StockHelp（投资视角）—— 一条可迁移的「时效护栏」

8 · 他给 RAG 答案加了一条「标注资料源可能过时」的护栏

• 怎么做的：Gabor 的冰球规则 app 检索旧资料（Reddit 讨论）时，prompt 里钉了一条时效护栏——「每当你引用这样一段旧讨论时，一定要给用户标注：这是更早时期的资料，规则可能已经变了。」检索还设了三级瀑布（规则手册→情境手册→兜底联网），且能一路回溯到原始 PDF 第几条。
• 你可以怎么做：StockHelp 里你看 PE / 5 年分位 / 基本面比率，数据的「新鲜度」恰恰是价值投资的命门——一个用了三个月前财报的估值会骗你。把他这条护栏迁过来：看板上每个指标显式标注数据日期 + 是否可能过时（财报滞后、TTM 截止日），别让一个看起来精确的公允价掩盖了它基于陈旧输入。这跟你的「安全边际」心态同源——先怀疑输入的时效，再信结论。

🔭 更深三角度

🔄 该反着用 · 他的「凌晨四点熬一个月调 agent」不是你该抄的 Gabor「每天熬到凌晨四五点泡在 Claude Code 里」打磨这套配置，周末轻松干到凌晨四点。他是单点突破、用时间换熟练度。但你的元约束是精力与聚焦本身就是最稀缺资源——你同时扛正职 + app_incubator + Holdwell + StockHelp + 小红书。正确的借鉴是反过来：不是投入海量夜晚去配齐 21 个 agent，而是先只配 3-4 个最关键角色（system-analyst 中枢 + 一个评审角色 + 一个执行），把链路跑通一次，再增量加。他能熬是因为他只攻一个 app；你不能熬是因为你有六条线——所以你要的是「最小可跑的角色集」，不是「最全的角色集」。

⚡ 和你现在做法冲突 · 「定义阶段才是真正的投入，写代码是最短的一段」 Gabor 和主持人都被一个反直觉结论击中：写代码反而是最短的一段——「一旦工单建好，前后端就几个提示，app 就有了。定义阶段才是真正的投入……这恰恰是大多数 PM 被卡住的地方。」这跟「重 agent 编排、把力气花在让 agent 多干活」的本能相左。张力在于：你在 Holdwell 把大量设计投入放在了碰撞协议的流程编排和角色协作上，而他说真正决定产出质量的是最前面那段「把规格问透、把骨架打好」（你的①澄清环节）。点出这个张力——你的工厂如果前端定义不扎实，后面三驾马车编排得再漂亮，也只是把一份烂 spec 高效地变成烂产品。（不替你下结论，但值得你自检：你的力气配比，是更像「定义重、编排轻」还是反过来？）

🪞 对你的镜子 · 「不让 agent 对应真实角色，AI slop 就更多」 Gabor 那句「如果你不让这些 agent 去对应真实的角色，你得到的 AI 垃圾内容就会更多」，是对你两个项目的同一面镜子。你 app_incubator 的 7 个 agent、Holdwell 的三驾马车，价值不在「数量」而在「每个角色是否真的对应一个现实里存在、职责清晰的岗位」。你纠结过编号、纠结过角色多少——他提醒你：衡量标准是「这个 agent 像不像一个你真会雇的人」，不是「我配了几个 agent」。屏幕上 21 个还是 7 个不重要，重要的是每个都立得住一个真实岗位。

One Human Company 新号（2026-07 回填）

1 · 他就是「你的同行」：一个 PM 把整家软件公司复刻成一队 agent——天然的 C 类对照选题

• 怎么做的：Gabor（Google PM）把 system analyst 当唯一中枢、二十来个专门化 agent 各管一摊（设计、测试、可维护性、隐私……），核心论点是「专业化 > 通用化」「不让 agent 对应真实角色，AI 垃圾内容就会更多」，且演示全程连翻车都没剪（评分系统分不清 penalties/penalty 的 bug 他特意留着当故事讲）。这套结构和你 drizzle tech 的 9+1 角色几乎同构，只是他更碎、你更精。
• 你可以怎么做：直接选题化成 C 类：「Google PM 用 21 个 agent 开软件公司，我用 9+1：逐岗对照后我没抄的三件事」——拿 drizzle tech 验：把他的角色表和你的 9+1 摆一起对照，试着按他的思路拆出 1-2 个更碎的角色（比如把测试拆成 tester + test-architect）跑一个真实环节，晒返工率和 token 账有没有变化，判断收在「角色数不是越多越好，一人公司的角色上限是你自己的审阅带宽」。可抄物：两家「AI 公司组织架构图」对照。闸门自检：对照实测和取舍判断都是我的，能过。

2 · 「每张前端工单必须钉 Figma 截图，否则出黑紫 AI 风」——一条可掐表复核的大佬铁律

• 怎么做的：Gabor 说这条「怎么强调都不为过」：没截图，agent 就做出「黑紫配色、一眼 AI 范儿」的 app；他还亲演了反例——整包 spec 直灌导致 context 压缩、「连一个橙色元素都没看到」。
• 你可以怎么做：C 类候选：「大佬说没设计截图 AI 就出『黑紫风』，我在 drizzle tech 做了 A/B：同一个页面带图 vs 不带图」——两次产出截图并排放，肉眼可判、传播性强，我的判断收在这条铁律在你链路里值不值得写成硬门。可抄物：一张「AI 开工前检查卡」（视觉锚点/依赖/验收三项）。这是 A 支柱（造 App 决策复盘）里最容易出图的题。

3 · 办号的镜子：他的「翻车留档当演示故事」就是你 B 支柱的内容生产纪律

• 怎么做的：Gabor 主动把自己挖出的 bug 记录下来当素材，因为「讲这个 bug 怎么影响真实用户体验，是一个很好的演示故事」；还给 app 加 observer mode 专供别人围观后台。
• 你可以怎么做：把这条焊进你的存稿期工作流——drizzle tech 每次翻车、返工、账单异常，当场记进一个「翻车台账」，修完不删；你 B 支柱（AI 员工翻车/返工/成本账）的存稿弹药就从这里长出来，而不是事后回忆硬凑。他证明了：带前后对比的真实翻车故事，比「跑通了」的成功宣告更有内容价值——这恰好也是收藏率逻辑：别人收藏的是你的事故复盘，不是你的喜报。

💡 所以呢

可迁移思维模型

• 【耐用】建筑师比喻：盖房子别只跟一个工人说「给我三室两卫」，要找一个「手下有完整团队的建筑师」并把需求说清。对应铁律——「好规格 → 好产品；烂规格 → 不及格产品」。这是跨 AI 工具、跨年份都不会过时的母模型，你 app_incubator 和 Holdwell 的全部价值，本质都建在「前期把规格/契约搭扎实」这一条上。
• 【耐用】专业化 > 通用化（小颗粒工单 + 聚焦上下文）：与其一个全能 agent 抱着整个项目，不如把活切碎、每个 agent 只吃窄上下文。这条会比任何具体工具活得久。
• 【会过期】具体工具栈与配额数字：Flutter+Firebase+Vertex、$200/月套餐、「两个 agent 并行才用 10% 配额」、「自主跑 6 分钟+」「半小时到一小时很容易」——这些是 2025 末的快照，模型一迭代就变。连 Gabor 自己都演示了这种易变性：dispatch 他「两周前还觉得绝了，现在又变脆弱了」。别把这期的配额/时长数字当常量写进你的设计假设。

判断更新 这期应该把你对「多-Agent 造东西」的判断从「一个值得探索的方向」推进到「一个已被真人端到端跑通、且方法论可直接抄的成熟范式」。尤其三件事从「我以为要自己摸索」变成「有现成答案」：①评审纪律怎么强制执行 = 焊在「定稿之前的全员评审」这道关上；②设计契约怎么落地 = 每张工单钉视觉截图、否则不开工；③跨线地基怎么填 = 让中枢角色顺手产出依赖图 + 用一棵空间树当骨架。

这周一个赌注 挑 app_incubator，只做一件事：给你的造 App 链路加一道「视觉锚点强制门」——在工单模板里把「Figma 截图/帧链接」设成必填，并让开发 agent 在开工前校验、缺了就打回。这是这期里最小、最确定、回报最直接的一改（Gabor 用一个亲身翻车案例证明了它的价值），一个晚上能落地，且立刻能验证：下次跑链路时，agent 产出是不是不再是「黑紫一眼 AI 范儿」。赌注小、信号强——正好符合你「先跑通最小角色集、别一上来配全套」的精力纪律。