这期直接命中三件事：app_incubator（最重，几乎是逐帧对撞）、一人公司账号、Holdwell 的 PRD 工厂。投资看板、家居号、Chief of Staff 这次真沾不上边，略过不硬掰。
app_incubator · 你的 7-Agent 造 App 链路
把 design.md 当视觉地基，而不是把风格写在 prompt 里
- 怎么做的：Peter 全流程的视觉真源只有一份 markdown。他把参考应用的几张截图粘进 Claude Code，配一条 prompt 生成 design.md，里面是设计原则加配色、字体、间距的简单建议，还有一条审美硬约束——"界面要保持安静，让封面海报去承担色彩"。之后每一步（出设计稿、写 spec、建 app）都是拿这份文件往下传，而不是每次重新描述"我想要什么风格"。他反复讲的因果是：正因为喂了真实截图，它才有机会产出贴合你想要的规范，而不是一眼假的紫色垃圾风。
- 你可以怎么做：你已经有一个从参考素材提炼设计系统的技能在做同一件事，而且做得比他重得多（7 层契约、三层 token、深浅两套）。所以真正值得抄的不是产出物，是传递链——去确认你那条 7-Agent 链路里，design.md 是不是每一个下游 agent 的强制输入，还是"第一个 agent 用完就躺在文件夹里"。这周挑一个已经跑过的项目，把设计 agent 到构建 agent 之间的交接内容翻出来，数一下 design.md 被引用了几次。答案如果是一次，那你有的是一份文档，不是一条地基。
三合一的 spec，和组件库这条保险丝
- 怎么做的：他把产品需求、设计规范、技术方案压进同一份 HTML，分产品、设计、技术三个 tab。设计那栏里必须有一份组件库，理由是他自己踩过的坑："以前不带组件库直接做 app，AI 就开始自由发挥、造出一堆奇奇怪怪的组件，整个 app 越看越乱。"而且组件库要随着界面增加持续更新，不是一次性产物。技术那栏里必须有数据表结构，理由是数据库一旦上生产就极难改。
- 你可以怎么做：这正好补上你"设计稿即工程强制契约"最薄的那半块——契约管住了页面长什么样，但没管住组件会不会发散。给 app_incubator 加一条硬产出：设计 agent 每出一批界面，必须回写一份组件清单（名字、用途、有哪些变体）；构建 agent 只允许用清单里的组件，要造新组件必须先申请入库。这一条对"越做越乱"的压制力，比再多画十张界面都大。
让 agent 先反问，再动手
- 怎么做的：Peter 最喜欢 Claude Design 的一点，是提交需求后它不直接开工，而是先抛一串澄清问题——范例展示谁的品味、两个变体各探索什么方向、页面放哪些板块、要不要深色版、文案要多真实。他的评价是"这些问题真的能帮我把设计要求想透"。到了第六步他把这招复制到了构建阶段，起手 prompt 就是"动手之前告诉我你有什么疑问、有哪些含糊的地方需要我澄清"，因为"你要默认一定存在你自己还没想清楚的模糊地带"。
- 你可以怎么做：这就是你想要的"把该做什么前移到 agent"，而且实现成本低得离谱——不需要 agent 更聪明，只需要在每个 agent 的第一句话里强制一轮反问。给设计 agent 和构建 agent 各加一段开场契约：先输出 5–7 个澄清问题、等人答完再开工。你现在卡着的"激活/首屏体验做不做、做到什么程度"，恰恰是这类该由 agent 问你、而不是你想清楚了才敢喂给它的问题。
一人公司账号 · build-in-public
一期现成的验证体选题，而且供血正好对上你的缺口
- 怎么做的：Peter 这套是完整可复现的六步，每步都有可抄物——起手 prompt 原文、design.md、三 tab 的 spec.html、导出 zip 的交接方式。更难得的是他把真实代价全抖了：Claude Design 那步"又多迭代了好几轮"、构建阶段"对话还是很长的，不可能一把梭"、成品做了几个小时"肯定还有 bug"、AI 自己估三周实际三十分钟。他视频末尾还直接问观众想不想看更多真实流程"而不是追着最新模型吹的视频"——这说明这个位置有明确的需求缺口，而你的 build-in-public 定位刚好站在缺口上。
- 你可以怎么做：这是"大佬说 X 我试了"的标准弹药，动作也很具体——拿 drizzle tech 手上一个真实小项目跑一遍 Peter 六步法，和你现在的 7-Agent 链路做同题对照，记三个数：总耗时、返工轮数、花了多少钱。标题往"Peter Yang 说做 App 别开 Figma，我让我的 7 个 Agent 跟他跑了同一道题"上靠。然后过一遍你的弹药库闸门：**把你的判断和实测数字删掉之后，这篇还剩什么？**如果只剩六步法复述，那就是没过闸门，必须补上对照数据和你的结论。
Holdwell 的多-Agent PRD 工厂
"人必须真的读一遍"就是真人评审的执行点
- 怎么做的：Peter 把 spec 做成 HTML 的动机，明说了就是让人读得进去，并且两次强调：必须逐条读完、给反馈、确认所有需求说得通，再让它去出设计稿，"不然你就是在白烧 token"。他把成本讲得很直白——越往后改越贵，最贵的是数据库建好之后。
- 你可以怎么做：你担心真人评审走过场、意见回不了炉，症结通常不是规则不够多，而是没有一个环节逼人真的读。可以把评审的通过条件从"评审通过"改成一件可验证的小事：必须有人在文档上留下若干条具体修改意见（"同意"不算）才算过。另外 Peter 给了个更省力的信号——把文档改成人愿意读的形态，本身就是治理手段。你那套碰撞协议的产出如果还是一长条 markdown，考虑给最关键的两三个环节做一版单页可扫的形态，读完成本降下来，读的人才会真读。
贵的东西要在便宜的时候定死
- 怎么做的：他的技术栏必须有数据表结构（数据库上生产后极难改），设计栏必须有组件库（没有它 AI 会造杂牌组件）。两条是同一个逻辑：在只有 HTML 文件的阶段，把后面最难改的东西先定下来。
- 你可以怎么做：这直接对上你六条产品线的跨线对齐难题。共享实体定义不是"有空再补"的活，它决定后面所有 PRD 会不会各说各话。先做最小版就行：把 ERP 里跨线出现频率最高的 5–8 个实体（订单、SKU、库存、客户之类）各写一段"有哪些字段、有哪些状态、谁能改"，作为三驾马车的强制引用源。共享定义不会自己长出来，但补 8 个实体是一个下午的事。
更深三角度
该反着用
Peter 的语境是"做给自己用、不用考虑赚钱、几小时上线"，所以他明说"如果是当生意做，我会花多得多的时间去调研"。你不是他——你每跑一个项目都同时在给一人公司攒资产和内容。所以他跳过的那一步（商业机会验证）恰恰是你要保留的。反过来，他花力气最多的那一步该反着来：他是一张张手改，一个一个删胶囊标签、删还没做的关注按钮、亲手改 slogan，靠的是个人品味逐张过。你有 7 个 agent，就不该每次都手工挑刺，而该把这些挑刺沉淀成设计 agent 的检查清单——禁止自作聪明的文案、未实现的功能不许出现在界面上、留白优先于信息密度。他只能靠品味，你可以靠规则批量执行，这是你的结构性优势，别浪费在手改上。
和你现在做法冲突
你的地基假设是"设计稿即工程强制契约"，配着 Figma 的接口——设计在前、代码在后、设计稿是唯一真源、信息单向流。Peter 这套有三处顶着它：① 他压根不开 Figma，视觉真源是一份文本 design.md，Claude Design 只是探索容器，导出的 HTML 是快照而不是权威；② 他把 spec 和设计合成一份文件，而不是两条并行的链路；③ 最尖锐的一条——他要求 AI 在代码里改产品时反向更新 plan 和 design 文件，也就是承认设计稿会被实现反噬，契约是双向同步的，不是单向强制的。你现在的强制契约如果不允许回写，跑久了大概率会出现一种典型状态：代码是对的、设计稿是旧的、契约还在假装自己是真源。这个张力怎么解我不替你下结论，但至少值得测一次：让构建 agent 在实现偏离设计稿时必须二选一——要么退回改实现，要么回写改设计稿，不许沉默通过。
对你的镜子
你把 Figma 当契约的载体，Peter 把设计工具当探索的容器。他真正的契约其实不是任何一种文件格式，而是"有一个人必须坐下来把它读完"——所以他才费劲把 spec 做成 HTML。顺着这个看：你的 7-Agent 链路越顺滑，人被迫读的位置就越少。哪天它出问题，多半不是某个 agent 不够聪明，而是整条链路上已经没有一个"必须读完才能过"的关口了。
所以呢
可迁移思维模型
- 【耐用】贵的东西要在便宜的时候定：组件库、数据表结构、导航结构，都在只有 HTML 文件的阶段定死；等数据库建起来再改，成本是数量级的差别。这条跟工具无关，五年后照样成立。
- 【耐用】视觉先于文字降歧义：先出两张高保真界面再写文档，比先写文档再画图更容易让所有人（包括 AI）对齐"这到底是个什么产品"。你写 PRD、写小红书选题卡、甚至给 agent 下任务，都能用这个顺序。
- 【耐用】先发散再收敛：一次要两个变体、并且明确指定它们各探索什么方向（他这次指定的是"横排为主 vs 网格编辑风"），比让 AI 直接给一个"最好的"有用得多——因为"最好的"没有对照物，你无从判断。
- 【会过期】Claude Design 的具体交互（澄清问题、三种反馈方式）、z.sh 这个站、"用 Opus 别用 Fable 省 token"、behindthecraft 上卖的那个 skill——半年内都可能变，别写进你的 SOP 正文，放附录。
判断更新
你原来大概会默认"AI 做设计的瓶颈是模型的审美"。这期给的反例是：瓶颈是输入的确定性。同一个模型，喂一份带硬约束的 design.md、答完七个澄清问题、再给一份带组件库的 spec，出来的东西和一句话丢过去，完全是两个物种。所以你在 app_incubator 上该加的投入方向是"让 agent 拿到更确定的输入"，不是"等更强的模型"。
这周一个赌注
拿 drizzle tech 手上任意一个还没开工的小 App，全程不开 Figma，只用「design.md + 三 tab 的 spec + 组件库清单」跑到可运行，全程记耗时和返工轮数。赢了，你手上就有一期带真实数字的验证体选题，同时验证了 Figma 到底是你链路里的必需品还是路径依赖；输了，你也拿到一份"为什么我的链路必须有 Figma"的硬证据。这两个答案里的任何一个，都比继续两边都留着、谁也没验证过要值钱。