这期是近期相关度最高的一期之一，而且几乎是逐条命中。原因很简单：Jason 用 Codex 搭出来的东西，和你手上已经在跑的四五个项目是同一形态的不同版本——他有 chief of staff，你有 Chief of Staff apps；他有 vault，你有这本第二大脑；他有 skill 库和 ultra goal，你有三驾马车碰撞协议的 PRD 工厂和 7-Agent 造 App 链路。区别在于：他的那套已经在一个真实工作日里跑通了，你的几套有的刚跑起来、有的还停在设计层。
（顺带一句查重：库里第 87 期是同一个频道、同一个产品，但那期是 Codex 产品经理 Rohan Varma 的视角——讲"为什么这么设计"；这期是团队内部工程师的视角——讲"一整天到底怎么用"。两期互补，一个给你产品判断，一个给你操作细节。）
对你的 Chief of Staff apps（宪法驱动的个人决策外脑）
① 一条置顶线程 + heartbeat，就是一个能跑起来的幕僚长
- 怎么做的：Jason 的 chief of staff 不是一个 app，是一条置顶的长期线程 + 一个每天 9/13/17 点触发的定时任务。它读完全部 Slack、Twitter 私信、未回邮件、Linear 看板，然后给一个"当下都在发生什么"的全景。冷启动只用一句话："把这条线程变成一个 heartbeat，我要你去查我的邮件、我的 Slack、我的 Linear……告诉我该优先处理什么。"之后所有能力都是一次抱怨换一条长出来的：没带链接 → 加链接；事情多了 → 接 Linear；再往后 → 预起草回复；再往后 → 自动值机发登机牌。
- 你可以怎么做：你的 CoS 目前的痛点是"软教练质量、跨域守门、季度回望"——本质是它不主动、要你去找它。抄这个形态：给 CoS 加一条每天固定时间的心跳，输入源换成你自己的（当天日历、Personal Thinking 里
20_想法库/ 的新条目、几个项目的 git 变更、上周未收口的决策），输出固定成一屏"今天该优先处理什么 + 哪条决定该拿宪法照一照"。第一版只要能生成那一屏就算成功，别设计完整体系。
② 幕僚长要不要动手，是逐条谈判出来的，不是一次性授权
- 怎么做的：Jason 对"能不能替我发出去"分得极细：写代码那条线可以全自动（PR 测试全绿 → 自动私信 Andrew）；但 chief of staff 那条"一次要读 40 封邮件、上百条 Slack 消息，这种场景我希望处理得更精准、更克制一点"。他的原话点破了关键——"要是第一天我就让它自己收尾，我肯定心里发虚；但现在，因为我知道这是我主动要求的，而且它做得没问题，我就更有底气"。
- 你可以怎么做：你的 CoS 宪法里可以直接加一条"授权阶梯"：默认只读只建议 → 某类动作连续 N 次你都原样采纳 → 才升级为自动执行。这比一开始就纠结"要不要让 AI 替我做决定"务实得多，也天然解决"跨域守门"——守门的不是规则，是这条动作还没爬到该有的授权层级。
对你的 Codex Holdwell ERP work 多-Agent PRD 工厂（三驾马车 + 碰撞协议）
① 「可验证的成功标准」就是你碰撞协议缺的那半句
- 怎么做的：Jason 的
goal.md 不写"做个超酷的打鼓 app"，写的是"我要你用 computer use 打开这个 app，上传这个 YouTube 视频，再把数据取出来"，附测试歌和视频 ID。他的规矩是："在你做到这件事之前，就得一直干下去。" goal 是验收动作，不是形容词。
- 你可以怎么做：你的 PRD 工厂当前的悬念是碰撞协议的纪律是否真被执行、agent 产出可不可验证——症结正是每个环节的通过条件是人读一眼觉得可以，而不是一个 agent 能自己跑一遍判定真假。挑流程里最容易放水的那一道（多半是碰撞环节：补强/修正/第 3 案三件是真交齐了，还是交回三段客气话），把它的通过条件重写成一句可执行的验证：比如"每条碰撞意见必须指到对方初稿的具体章节和具体断言，指不出就算没交"。改完这一道就够了，比再加新角色更值钱。
② self-improve：让 skill 从自己的历史 session 里学，而不是靠你回忆
- 怎么做的：他四个月前做了个 skill 叫 self-improve，三步——看哪些 skill 被调用得最多 → 把这些 skill 的 session 全读一遍 → 告诉我有没有反复出现的反馈。最漂亮的战果是 Slack skill 自己发现了"每次都要人工回一句办好了"这个反复动作，然后把它吃进去了。他还会让 Codex 看"过去 400 次 session 里哪些 skill 从来没被用过"来做减法。
- 你可以怎么做：你三驾马车的 agent 定义（
.Codex/agents/*.toml）现在靠你自己回忆哪条不好用。给工厂加一个"自省"环节：定期扫 _agent-runs/ 里最近的工单记录，回答两个问题——哪几条定义里的指令从来没被真正遵守过（该删）、哪几处你每次都要人工补同一句话（该把那句话写进 agent 定义）。你的真人评审意见回炉天然产生大量"人工补话"记录，那就是最好的语料。
③ 打包成 plugin，才谈得上"整个 PM 团队都在用"
- 怎么做的：skill 只是 plugin 的一块拼图；要分享给团队，就把 write / slack / email 三个 skill 打成一个叫 better writing 的 plugin，连 MCP server 和脚本一起。
- 你可以怎么做：你的工厂要走出"只有你自己在用"，一个隐藏门槛是别人装不上你的东西。把 PRD 工厂里最独立的一小块（比如"澄清一问一答"或"真人评审意见回炉"）单独打成一个可直接安装的包，找一个同事装上跑一次真实需求——这才是可观测的落地证据，比再加新角色有用。
对你的 app_incubator（7-Agent 造 App 链路）
① goal / plan / worklog 三件套 + 「别自己写 goal」
- 怎么做的：
goal.md 写可验证的成功标准，plan.md 写实现细节（"用 React、两个标签页、这几种技术；不会用就去读文档"），worklog 是写给人看的——因为有上下文压缩，他不可能读每条消息，日志让他一眼看出"卡在这个权限问题上了"。而且他说了句反直觉的："如果你想定出好的 goal，那就别自己写 goal"——把成功标准描述清楚，让 Codex 自己定目标，"效果通常好得多"。goal 单独存成文件的理由也很实在：任务还在跑的时候可以直接改文件，范围扩大了不用重启。
- 你可以怎么做：你的 7-Agent 链路已经有"设计稿即工程强制契约"，但缺的正是这三件套里的后两件。给每条造 App 任务固定产出三个文件，其中 worklog 只服务一件事——让你事后知道 agent 卡在哪、你的链路哪一环最脆。这正好回答你"把『该做什么』前移到 agent"那个痛点：前移的抓手不是更长的 prompt，是让 agent 自己写 goal、你只审 goal。
② 长时任务不是"跑六小时"，是"养大"
- 怎么做的：他主动泼冷水——"那种『我让它朝一个目标跑了六小时』的演示当然很酷，但更关键的其实是，这些东西你可以随着时间一点点养大"。他的打鼓 app 是一周长出来的，每学一个新概念就加一条功能。
- 你可以怎么做：你的造 App 链路一直在追求"一条链路端到端产出成品"。这条提醒你换个成功定义：不是一次跑通，而是第 N 次跑的时候比第 N-1 次少一次人工介入。把这个当成 app_incubator 的核心指标，比"有没有跑完"更能推动它进化。
对你的 Personal Thinking（这本第二大脑）
① 他的 vault，就是你这本库的"给 agent 用"版本
- 怎么做的：Jason 只有一个项目叫 vault，全是 markdown，分目录放：项目 / 人 / 各种笔记 / 每日笔记 / 我的偏好。关键那句是——"其实我很少真的去打开 Obsidian，它主要是给我的 agent 当上下文用。" 而且它在 GitHub 上，换机器"直接把 repo 拉下来就能接着干"。溢出的内容一律落盘：觉得重要就让模型存进 notes 目录。
- 你可以怎么做：你这本库已经有主题骨架、MOC、原子笔记，唯独缺他那两个目录——人和我的偏好。「人」目录（同事、合作方、你在意的博主，各自一页：他关心什么、你跟他的历史）会立刻让 CoS 和 PRD 工厂的输出变具体；「偏好」目录（你怎么写东西、你讨厌什么、你的决策口味）就是所有 skill 的公共前置上下文，现在这些散在各个 skill 里重复了 N 遍。
② 一条置顶长线程 = 一个工作区，而不是每次开新会话
- 怎么做的：他后台没有几百条线程，"几乎所有东西都只是一条 pinned 线程"，靠 compaction 撑住时间跨度；额外的活不给主线程做，而是起 sub agent。
- 你可以怎么做：你的摄入 SOP 目前是"每来一份内容开一轮新对话"，跨主题串联全靠你事后手动做。试着给几个长期主题（比如"AI 产品"、"个人杠杆"）各留一条常驻线程，新内容进来先喂给对应线程，让它自己回答"这跟你库里已有的哪几条冲突/补充"。串联这件事本来就该由一条有记忆的线程来做，不是由你。
对你的 onehuman_company（一人公司 build-in-public）
① 「像我一样写」skill 家族 = 你的 solo-editor 该长的样子
- 怎么做的：write me 的做法简单到扫兴——"用 Slack connector 把我过去一周发的 Slack 消息读一遍，然后做一个 skill，总结出我说话的方式"。然后加分层（对外 vs 对内、对高管 vs 对同事），铺开成 email me / tweet me / 语音转博客 / 视频转 video essay。而且"大部分都是 Codex 写的。我真正要做的，其实只是把这些参照样本指给它看"。skill 会长胖，所以他还会让 Codex 看过去 400 次 session 做减法、建议合并。
- 你可以怎么做：你已经有 de-ai-flavor 这套去 AI 腔的规则库，但那是通用规则；缺的是你本人的语料样本。让 solo-editor 去读你已发布的小红书文案 + 你在这本库里写的判断段落，自己生成一份"momorain 语气 skill"，并且按你两个号分层（一人公司偏冷静复盘 / 家居号偏生活口吻）。你只负责指样本，别自己写规则——这是他效率的真正来源。
② 这一整期本身就是一条现成的"验证体"选题
- 怎么做的：他的每条能力都不是设计出来的，是"一次抱怨换一条"攒出来的；他还特意说"这些都是我一点点攒出来的小功能，绝不是开箱即得的"。
- 你可以怎么做：这期能过你的弹药库闸门——因为删掉你的实测它就不成立。可做的选题：「OpenAI 工程师的 chief of staff 我照抄了一版，跑了两周」，写清你接了哪几个源、第一版输出有多难看、你加了哪三条偏好、现在替你省下什么。这是标准的"大佬说 X 我试了"，而且天然有截图和产能账。另一条：「AI 员工管理成本账」支柱可以直接接他那句"日常一律 medium，只有造东西才开 ultra"——你手上有 9+1 个 agent，档位怎么配、一个月差多少钱，这是别人没写过的实账。
③ 「我不把自己当管理者」是一条可以直接引的观点
- 怎么做的："OpenAI 里人人都很拼。那什么让你脱颖而出？是你真在意东西做得好不好，在意它最后能带来什么结果。"他给自建 app 定的成功标准全是外部结果——我打鼓有没有进步、别人能不能用上、能不能攒起一个小社区。
- 你可以怎么做：这是你 build-in-public 那条线最缺的一段话。你现在讲"一个人开公司"容易讲成流程展示，而他这句给了你更硬的框：衡量的不是我管了几个 agent，而是这些 agent 最后交付了什么结果。可以直接把它变成你的"观点短评"支柱的一篇。
对你的 xiaohongshu_momorain（家居号）
「想有品味，你得先去吃」对着你的选题矿池
- 怎么做的：面对"写代码被解决了，人该练什么"，他的答案是"想有品味，你得先去吃"——审美是消费出来的；另一半是"对现成的东西感到不满意、然后去学那套词汇和说法"。他反对的是笼统反馈："如果你只是连着说 20 遍『做得更好点』，那很难判断这么干到底能不能出好结果。"
- 你可以怎么做：你的档案只盘了 16/218 的选题矿池，卡点很可能不是产能而是没吃够。把"盘矿池"从"整理"改成"吃"：每周固定看 20 篇同赛道爆款，只做一件事——写下你具体不喜欢它哪一点（不是"不够好"，是"封面标题字太多"、"前三秒没给出结论"）。这些"不喜欢的具体化"就是你封面标签和标题的原材料，也正是你"PM 思维这张牌"该打的地方。
对你的 StockHelp（价值投资看板）
关联偏弱，只写两条真沾边的，不硬掰。
- 怎么做的：一是浏览器那条——Codex 内置浏览器能做 OAuth 登录、能带 cookie，还能同时开多个标签页；他买东西时不是要一份 markdown 结论，而是"把每个商品都单独开一个标签页"，人回来读完直接决策。二是 heartbeat 那条：一个定时任务把散在各处的信息收成一屏全景。
- 你可以怎么做：StockHelp 的 Phase 2/3 打算做信号和通知，形态上就是 heartbeat——收盘后跑一次，输出一屏"今天哪几只越过了你的估值线"。而"多标签页"那招更适合你的看板之后那一步：当某只越线，让它把年报、最近财报电话会、几篇多空观点各开一个标签页，你端着咖啡回来一次读完再决定。至于用 AI 直接交易——片中 Jason 和 Peter 都明确表示信不过，你的价值投资纪律更没理由破这个例。
对你本人的精力与聚焦
- 怎么做的：他的整套系统只有一个 vault、一条主要的 chief of staff 线程、一个默认档位（medium），加上"想起来就顺手清一次"的减法习惯——包括让 AI 找出 400 次 session 里从没被用过的 skill 直接删掉。
- 你可以怎么做：你的元约束是精力和聚焦，而你手上是七八个项目、十几个 skill、多个 agent 阵列。这期最该抄的不是他加了什么，是他减掉什么。给自己排一次同样的自查：过去一个月，你哪几个 skill / 哪个项目一次都没真正被调用过？先删掉或冻结，再谈新增。
更深三角度
该反着用
- 他在 OpenAI，工具就是自家产品、有内部访问、一条战线专职深挖，所以他能承受"攒 400 次 session 再回头清理"的路径。你是一人扛正职加多个副业，反过来正确的做法是在 skill 还只有 3 个的时候就定好合并与淘汰规则，别等长成家族再治理——他清理的成本是一句话，你的成本是一个周末。
- 他说"skill 大部分是 Codex 写的，我只指样本"。你的 PRD 工厂那几份 agent 定义是自己精雕的。这里成本结构完全相反：他的稀缺资源是判断，你的稀缺资源是时间。所以你更该反着来——凡是能靠"指几个样本 + 让 agent 自己写"的地方，就别再手写规则了。
- 他默认 medium、只有造东西才开高档位。你更容易全程开满档位。反过来做：给自己定一条"默认低档，只有明确要造东西才升档"的规矩，省下的不只是钱，是等待时间。
和你现在做法冲突
- 最直接的一条：你的 app_incubator 把"设计稿即工程强制契约"当地基，接了 Figma MCP；Jason 说贴参考图那套"在 5.5 那会儿更有必要"，到 5.6"前端出来的效果已经足够好"，他只说一句"用 Tailwind 和 shadcn/ui"。这两个判断正面撞车。张力在于：他做的是自用工具（没有品牌一致性要求），你做的是要复用设计系统的产品线——但如果他是对的，你那条契约就从"必须"降级成"品牌一致性时才必须"，这个结论值得你亲自试一次再定，别替自己回答。
- 第二条：你在第二大脑里精心做主题骨架、MOC、原子笔记、双链；Jason 说"我很少真的去打开 Obsidian，它主要是给我的 agent 当上下文用"。这逼你回答一个不太舒服的问题——你这本库里有多少结构是为人看的，多少是为 agent 用的？ 如果实际读者主要是 agent，那"好看的组织"可能正在消耗你本就稀缺的精力。
- 第三条：你的 Chief of Staff 定位是"把你写过的原则放回你眼前"——本质是只读；Jason 的幕僚长直接改 Linear 工单、值机、发短信——它会写。你一直没跨过这条线，可能是对的（决策不该外包），也可能只是没试过。至少可以先在"低风险的写"上试：让它替你归档、改状态、建草稿。
对你的镜子
- 他那句"这些都是我一点点攒出来的小功能，绝不是开箱即得的"，配上"跑六小时的演示很酷，但更关键的是这些东西可以随着时间一点点养大"——正好照见你多个项目的共同卡点：你在等一次把架构设计对，而他在等第一百次抱怨。你的 PRD 工厂、造 App 链路、CoS，缺的都不是更完整的设计，是一条已经在跑、每天被你骂一句然后改一点的最小版本。
- 第二面镜子更锋利：他说"我从不指望 AI 第一步就把我的问题解决掉，因为我也不指望别人能猜到我想要什么——除非我自己是真的想清楚了"。当你觉得某个 agent 输出不行的时候，先问一句：这次我是真想清楚了，还是只是又说了一遍"做得更好点"？
所以呢
可迁移思维模型
- 【耐用】目标 = 可验证的完成条件，不是任务描述。 "在你做到这件事之前，就得一直干下去"——这句话能用在 agent、外包、下属和你自己身上，十年不过期。
- 【耐用】用 agent 像招人第一天：讲背景、给反馈、允许它慢慢变。对应的推论是"永远别指望一次写好一个 skill"。
- 【耐用】想有品味先得去吃 + 把不满意说成话。 AI 越强，这条越值钱——因为它是唯一不能外包的一步。
- 【耐用】一条有记忆的长线程 = 一个工作区，优于每次开新会话。这是上下文管理的通用姿势，不绑定任何一家产品。
- 【会过期】Sol medium 是好默认、5.6 前端已经不用贴参考图、plugin 目录刚开放提交、computer use 还不敢让它下单结账、Codex 正从桌面搬到云端——这些都是这个月的事实，半年后大概率不成立，引用时记得标时间。
判断更新
- 把你对"我的 agent 队列缺什么"的诊断从"缺编排"改成"缺可验证的完成条件"。你已经有三驾马车、有碰撞协议的六步流程，唯独每一步的"做完了没有"还是靠人眼判断——这才是碰撞纪律难保真、评审意见回炉难闭环的同一个根因。
这周一个赌注
- 挑 PRD 工厂或 app_incubator 里正在跑的一个真实任务，做两件事：① 把它的目标改写成一条能被 agent 自己执行一遍来判定真假的
goal.md（必须包含一个具体的验证动作和一份测试输入）；② 不许你自己写这个 goal——把成功标准描述给 agent，让它自己产出 goal，你只审。跑完记录一条：这次人工介入了几次。下次的唯一目标是比这次少一次。