这一期对你是高相关。 你正在干的就是 Karpathy 这一整集在讲的事——不再亲手写代码、而是「向一群 agent 表达意图让它显化」。你那个三驾马车 + 碰撞协议的 PRD 工厂、7-Agent 造 App 链路,本质上就是他口中的 program.md:把一个组织(你的 PM 流程、你的造 app 流程)写成一组定义文件,描述所有角色和它们怎么连。所以下面给得厚一点,因为他踩过的坑、想清楚的东西,你大概率正好要用上。
🏭 Codex Holdwell ERP work(PRD 工厂 / 多-Agent)—— 这一期的正中靶心
1 · 「研究组织即代码」就是你的工厂在做的事,而且它可以被调优
- 怎么做的:Karpathy 的核心命题是「每一个研究组织都是由一个 program.md 来描述的——一组 markdown 文件,描述所有的角色以及整个系统是怎么连接起来的」。一旦组织变成代码,就可以像调代码一样调它:「也许他们早上少开几次站会,因为站会没用」「一个组织可以非常敢于冒险,一个组织可以保守一些」。他甚至想搞个比赛——让不同的人写不同的 program.md,同样硬件上看谁提升最大,再把这些数据喂回模型「写一个更好的 program.md」,并断言「我们肯定会得到更好的东西,不可能得不到吧」。
- 你可以怎么做:你的三驾马车 + 碰撞协议流程图(agent 定义就躺在
.Codex/agents/ 里),就是你的 program.md。但你现在是把它当「设定」在维护,不是当「可被实验的代码」在跑。把它显式当代码看,意味着两件事:① 给每一版流程图打上版本号和一句「这版赌的是什么」(比如「这版砍掉一轮碰撞,赌的是提速不掉质量」);② 准备一两条客观判据(PRD 返工率、评审轮次、评审意见回炉率),让你能像 A/B 一样比「砍了某个环节的 program」对「没砍的」。你档案里那个「碰撞纪律看不见、agent 产出难验证」的痛点,正是因为流程还没被当成可度量的代码——先给它装上判据,再谈优化。
2 · 「把自己从瓶颈里移出去」,单循环先于并行
- 怎么做的:auto research 的全部动机是一句推文——「要把这些工具的价值榨到最大,你必须把自己从瓶颈位置上挪开,不能一直在那儿等着提示下一步,得把自己挪到外面去,把事情安排成完全自主」。接口因此极简到三件:「这是一个目标,这是一个指标,这是你能做和不能做的边界,然后开跑。」他强调这先是「一个单一的循环」跑通宵,才谈并行;而且诚实承认并行化「还没找到一个简单得『咔哒』一下就成立的方案」,至今没满意答案。
- 你可以怎么做:你的工厂天然是多-Agent 并行的野心,但 Karpathy 的纪律是反过来的——先把单条链路做到「安排一次、按下开始、它自己跑完一个完整 PRD」再说并行。具体到你的碰撞协议:与其在每一步流转处都亲自坐镇,不如先挑一条链路,把它的输入收敛成他那三件套(一个目标 = 这个需求要解决什么、一个指标 = 怎么算这版 PRD 合格、一组边界 = agent 不许碰哪些东西/必须遵哪些契约),让它从澄清到出稿端到端自动跑通一次。你现在多半还坐在循环里手动接力(碰撞完一轮再喂下一轮)——那正是他说的「你那是在拖累系统」。
3 · auto research 找出他亲手调二十年都漏的超参 = 给「该不该做」装客观判据
- 怎么做的:他做研究二十年、「这个模型训练过成千上万次」,自认调得相当好了;让 auto research 跑一个通宵,回来给了他自己没看到的调参——「我确实忘了 value embedding 上的 weight decay,而且 Adam betas 调得不够充分,这些东西会联合相互作用」。前提硬约束是:「这种情况下是有客观判据的」,并且「如果你没法评估,你就没法对它做 auto research」。
- 你可以怎么做:你的碰撞环节(补强/修正/第 3 案)和真人评审就是一组「判据」,但它现在靠人脑和 LLM 执行、所以会漂。把其中能客观化的检查先抽出来做成 agent 能自动跑的(比如「引用的实体口径是否与产品线现状一致」「跨线字段命名是否对齐」这类是非题),让一个 agent 通宵把所有在途 PRD 过一遍、列出违例清单——这正是「评审意见回炉闭环」的解法:能自动评估的检查,就该变成强制关口,而不是评审会上靠人记得提。不能客观评估的部分(产品判断、取舍)才留给你。这条直接对上他那句边界:可验证→上轨道自动跑,不可验证→留给人。
4 · 跨线对齐还没有做实的共享口径,正是「单一栽培 vs 物种分化」的镜子
- 怎么做的:Karpathy 观察实验室在「打造一个单一栽培式的模型,把一切全塞进参数里」,但他主张要预期「更多物种分化」——「你不需要那种无所不知的神谕,你可以让它分化,放到一个特定任务上」,换来「小得多、仍有认知内核、但专精后更高效」的模型。阻碍之一是「操控这些大脑的科学还没成熟」「还得足够便宜才值得」。
- 你可以怎么做:你的三驾马车分工,对应的就是「物种分化」——每个角色是一个专精 agent,而不是指望一个万能 agent 啥都干。但分化要成立,前提是有一个共享的「认知内核」让它们对齐,而你六条强耦合的产品线之间,这层共享口径正是跨线对齐痛点的核心。agent 各说各话、跨线对不齐时,该先查的就是这里:没有共享的实体口径,三个专家就是三个孤岛。优先级排序上,把共享口径做实应该排在给流程加码之前——他这一期反复强调的就是「先有共同的开放底座,分化才健康」。
📱 app_incubator(7-Agent 造 App / 设计稿即契约)
1 · 「把『该做什么』前移到 agent」正好撞上他说 LLM 最差的两件事
- 怎么做的:他点名 agent 在两类「软」任务上最差——「拿捏微妙之处:我心里到底想要什么、我的意图是什么」,以及「什么时候该问澄清性的问题」。原因是 RL 只在「可验证、有奖励信号」的东西上改进模型,软任务没奖励信号就卡住。结果是「你要么在轨道上、是超级智能那套电路的一部分;要么不在轨道上、跑出了可验证的领域,然后一切突然变得漫无目的、东游西荡」。
- 你可以怎么做:你档案里 app_incubator 的痛点正是「把『该做什么』前移到 agent」——但 Karpathy 的证据说明,「揣摩用户到底想要什么」恰恰是 agent 现在最弱的环节,硬把它前移会让 agent「meander(东游西荡)」。务实的做法是:别让 agent 去猜「该做什么」,而是把它逼回「可验证」的轨道——你那个「设计稿即工程强制契约」就是天然的轨道,Figma 稿是客观判据,agent 照着实现是可验证的。所以前移的不该是「判断该做什么」,而该是「在动手前强制 agent 问澄清问题 / 比对设计契约」。把「何时问澄清问题」做成 agent 的硬规则,比指望它自己学会揣摩你强得多。
2 · 软件过度生产 + 临时软件 = 重新校准你造的「app」该长什么样
- 怎么做的:他的「软件过度生产」论很激进——智能家居那些 app「从某种意义上根本就不该存在,难道不应该只有 API、让 agent 直接去用吗」;终局是「替你临时生成、用完即弃的软件(ephemeral software)……Claude 有一台机器,它会把事情搞定,它只是把 UI 呈现给你,你就在那儿说说话」。客户也变了:「不再是人类,而是代表人类行动的 agent」。
- 你可以怎么做:你在造 App 链路,但他在质疑「独立 app」这个形态本身。这不是要你停掉 app_incubator,而是一面镜子:问一句「我让 agent 造出来的这个 app,是『人要学一套新 UI 的传统 app』,还是『一个自然语言入口 + 后面 agent 调 API 把事办了』?」你的「激活/首屏体验」痛点,在他的框架里可能根本是个伪命题——如果终局是临时软件,首屏的价值就从「教会用户用」变成「让用户开口说话」。至少在下一个 app 选题时,把「这功能值不值得做成常驻 app,还是该是一次性生成的临时界面」当成一道前置筛子。
🧠 本人 / 职业精力(你的元约束:聚焦与精力最稀缺)
1 · token 吞吐量焦虑的反面——你的稀缺资源不是 token,是注意力
- 怎么做的:Karpathy 把瓶颈一路上移:从 flops 到 tokens,最后「是我自己成了那个约束条件(I'm the binding constraint)」。他的操作纪律是把订阅额度全用满、多 agent 并行,「当我还有订阅额度剩下时我会紧张,那只意味着我没把 token 吞吐量拉满」。
- 你可以怎么做:⚠️ 这一条你该反着用(见下「该反着用」)。但有用的内核是「找到真正的约束条件」:他作为全职研究者、目标单一,约束是 token;而你一个人同时扛正职 + 6 个副业,你的 binding constraint 从来不是 token、是注意力和聚焦。所以对你而言「把 token 吞吐量拉满 = 同时开一堆 agent」恰恰是错的方向——那会榨干你最稀缺的东西(在多个 agent 间切换、判断、纠错的注意力)。正确的迁移是:像他逼问「我的约束是什么」一样,每周那「留一天思考」时问自己「这周真正卡住我的是什么」,然后只对那一个瓶颈下注,而不是把所有副业的 agent 全开起来。
2 · 「智能体做不到的那几个比特」就是你该 all-in 的地方
- 怎么做的:他让 agent 重写 micro GPT 那 200 行,「它做不到(it can't do it)……它只是想不出来这个解,但完全能领会、能理解为什么要这么做。所以我的贡献大概就是这么几个比特(these few bits)」。收尾金句几乎是一条职业策略:「智能体做不到的事,现在就是你的工作。智能体做得到的事,它们大概能比你做得更好,或者很快就会。所以你应该有策略地去想,到底该把时间花在什么上面。」
- 你可以怎么做:这直接对上你档案里「该 all-in 哪个编码下注、不公平优势」那个问题。把你 6 个副业 + 正职平铺开,对每件事问一句他的判据:「这件事,agent 现在能做到吗?」凡是 agent 已经能干得跟你一样好的(写常规代码、做标准总结、套模板),就该交出去、不再是你时间该花的地方;你该 all-in 的,是那几个「agent 想不出来、但你能想出来、它一看就懂」的比特——比如你那套 program.md 的架构本身、你的产品判断、你 5 个项目之间的跨域串联。你的不公平优势不是『会用 agent』(人人很快都会),而是你能设计出别人 agent 想不到的那几个比特。
3 · 「skill issue」心态:赋能但也上瘾,注意它对你是双刃
- 怎么做的:他把一切归因到「skill issue(技术不到位)」——「做不成不是能力不在,是你还没找到把能力串起来的办法」,并坦白这心态「很赋能也很上瘾」,还有社交焦虑面:「我看到推特上一大堆人在做各种事,我必须在最前沿,否则我会极其紧张。」
- 你可以怎么做:这心态对你是双刃。好的一面:你那些项目卡住时,默认归因「是我还没把 agent 调对」而非「这事做不成」,会让你持续往前。但他自己都点破的陷阱——「这东西是无限的」「我必须在最前沿否则极其紧张」——对一个精力是元约束的人是危险的:无限的领域 + FOMO,正是把你注意力榨干的配方。把它当镜子:当你发现自己在追「推特上每个人都在玩的新玩法」时,回到你的元约束问一句「这是我该聚焦的那 1%,还是会白费的 99%」。
📈 StockHelp / 投资视角(命中商业模式与估值,所以接一下)
1 · Jevons 悖论 + ATM 案例——给你的「需求弹性」直觉
- 怎么做的:他解释工程岗为何不减反增,用的是 Jevons 悖论 + ATM 经典案例:「过去软件稀缺、太贵,所以需求不多;门槛一降,你会遇上杰文斯悖论——需求反而上升。」「当年担心 ATM 会取代柜员,实际它让经营银行网点便宜很多,于是有了更多网点、更多柜员。」
- 你可以怎么做:这是个【耐用】的估值心智模型,直接喂给你看美股/港股的能力圈。当 AI 让某个生意的「单位成本」暴跌时,第一反应别急着判「这行要完」——先问 Jevons:成本降了会不会把总需求做大(像 ATM 之于网点)?这决定你把一家公司看成「被 AI 取代的输家」还是「被 AI 放大的赢家」。可以挑你 watchlist 里 1-2 家「AI 既可能取代、也可能放大」的公司,用这个框架各写三行多空,逼自己分清。
2 · 开源稳定落后 6-8 个月 + 「集成胜过单模型」——AI 公司的护城河该怎么看
- 怎么做的:他给开源落后曲线:「从 18 个月到现在 6-8 个月」,并判断这是「误打误撞落到的好格局」,理由是机器学习里「集成(ensemble)永远比任何单个模型好,所以我希望房间里有更多前沿实验室,不希望两三个人关起门做决定」。他还观察到「即便闭源这边最近反而更中心化了,因为很多领跑者不一定是真正顶尖梯队」。
- 你可以怎么做:作为价值投资者,这给你一把看「AI 护城河」的尺子——闭源前沿的领先只是 6-8 个月的滴流缓冲,不是永久护城河。评估任何「靠模型领先」的公司时,把这条当默认怀疑:领先会被开源稳定追到 6-8 个月内,真正的护城河得在模型之外(分发、数据、客户绑定、转换成本)。这正好呼应你「找卓越生意 + 安全边际」的原则——别把暂时的模型领先错当成可持久的竞争优势去给高估值。
🔁 更深三角度
- 该反着用:Karpathy 是全职、目标单一、资源充足的研究者,「把 token 吞吐量拉满 / 同时开十个 agent / 必须在最前沿」对他成立——因为他的瓶颈真是 token。你是一个人扛正职 + 6 副业、精力是元约束的人,照搬「全开并行、追每个新玩法」会直接烧穿你最稀缺的注意力。正确的借鉴是反过来:他找到约束是 token 所以拉满 token;你找到约束是聚焦,所以该收敛 agent 数量、单线程跑透一条,而不是平铺十个。
- 和你现在做法冲突:你在建多-Agent 工厂、7-Agent 链路,本能是「加角色、加并行」;而他这一期最反直觉的纪律是「单循环先跑通再谈并行」,连他自己并行化都「还没找到满意方案」。这跟你「多环节碰撞、同时铺多 agent」的倾向是直接冲突的——张力在这儿,结论你自己下:是先收敛到一条链路做出闭环证据,还是继续铺宽?
- 对你的镜子:你一直在想「该把我自己放在工厂的哪个角色里」;他这一期把答案翻了过来——你的价值不是当工厂里某个 agent,而是当那个写 program.md 的人。「我的贡献就是 agent 想不出来、但一看就懂的那几个比特。」你的不公平优势,不在执行链路里的任何一环,而在你能设计出别人 agent 想不到的那套连接方式本身。
One Human Company 新号(2026-07 回填)
1 · A/B 支柱王牌:「组织即代码」——你的一人公司本来就是一组 markdown 文件
- 怎么做的:Karpathy 的命题是「每一个研究组织都是由一个 program.md 来描述的——一组 markdown 文件,描述所有角色以及整个系统怎么连接」。组织一旦变成代码就能被调优:「也许少开几次站会,因为站会没用」「一个组织可以敢冒险、一个可以保守」,他还想办比赛让不同人写 program.md 看谁跑分高,再喂回模型「写一个更好的 program.md」。
- 你可以怎么做:drizzle tech 的 9+1 角色流水线就是一个活的 program.md——这是你 B 支柱里最独占、别人抄不走的素材。候选标题:《我的公司没有组织架构图,只有一个 markdown 文件(全文公开)》——把角色定义、连接方式、这个月改过的三处「组织代码」和改动前后的产出差异写出来。可抄物就是那份脱敏后的 program.md 模板,标题和封面直接承诺「文末可复制」。闸门自检:文件是你的、改动记录是你的、判断是你的——满分通过。
2 · C 类验证体(带诚实反驳):「平铺十个 agent、额度没用完要紧张」——我试了,结论是一人公司别学
- 怎么做的:Karpathy 的纪律是把 token 吞吐量拉满:「当我还有订阅额度剩下时我会紧张」,标杆是 Peter Steinberg 一块屏幕平铺十来个 Codex agent、每个跑 20 分钟来回派活;用「宏操作」以整个功能为单位并行推进。但他也承认瓶颈最后变成「我自己成了约束条件」,且并行化「还没找到简单得咔哒一下就成立的方案」。
- 你可以怎么做:这是你 C 支柱要求的「含诚实反驳」的标准样本。候选标题:《Karpathy 说订阅额度没用完就该紧张,我并行开了 8 个 agent 一周:账单翻了 3 倍,产出没有》——你在 drizzle tech 实测「并行拉满 vs 单链路跑透」两种模式的返工率、你自己的切换损耗和 API 账单,最后给判断:他全职单目标所以约束是 token,一人公司约束是老板的注意力,所以该反着用。可抄物:一张「什么时候值得并行」的三问卡。有实测有反驳,闸门稳过。
3 · D 类立场句现成:「一切都是 skill issue」——既是金句也是你要警惕的毒
- 怎么做的:Karpathy 把一切归因「做不成是技术不到位,不是能力不够——能力在那儿,你还没找到把它串起来的办法」,并坦白这心态「很赋能也很上瘾」,副作用是 FOMO:「我看到推特上一大堆人在做各种事,我必须在最前沿,否则我会极其紧张。」
- 你可以怎么做:一篇 D 类短评,立场句可以直接立:「'一切都是 skill issue'是 AI 时代最赋能也最坑一人公司的一句话。」——前半讲它怎么救你(每次 agent 翻车先改 prompt 别弃坑,配你的真实返工例子),后半讲它怎么坑你(无限游戏 + FOMO 恰好烧掉一人公司唯一的稀缺资源),立场可反驳、有你的翻车佐证。注意控量:D 类只占 20%,这篇和上面那篇反驳体别挤在同一周发,避免号显得「专怼大佬」——你的主菜永远是 A/B 的实测记录。
🧩 所以呢
- 可迁移思维模型:
- 【耐用】组织即代码(program.md):任何重复的协作流程(你的 PRD 工厂、造 app 链路、甚至你自己一周的工作流)都可以写成一组 markdown、被版本化、被实验、被优化。这条不依赖具体模型,会一直成立。
- 【耐用】「几个比特」职业策略:把任何工作拆成「agent 已能做到的」和「agent 做不到、但能理解的」,时间只投后者。模型越强,前一堆越大,但「设计那几个比特」这件事的价值反而越高。
- 【耐用】Jevons / 需求弹性:成本暴跌 ≠ 需求消失,常常相反。看生意、看岗位都适用。
- 【会过期】具体数字:「开源落后 6-8 个月」「亲手写码 20/80」「auto research 还没法并行」这些是 2026 年初的快照,几个月就会变;别把它们当常数,要当「当下坐标」。
- 判断更新:你原本大概默认「多-Agent = 角色越多越好、越并行越强」。这一期该把它修正为「先有跨线共享口径(实体词典)+ 单链路闭环证据,再谈扩角色和并行」——Karpathy 这个比你领先得多的人,并行化都还没跑通、还在先把单循环做对。你那层还没做实的跨线共享口径和还难以验证的 agent 产出,不是「以后补」的债,是「现在就卡住一切」的根。
- 这周一个赌注:在你的 Holdwell PRD 工厂里,挑一条产品线的真实需求,把它的入口改造成 Karpathy 的三件套——一个目标 + 一个客观指标(这版 PRD 怎么算合格)+ 一组 agent 边界,然后让它端到端自动跑完整个碰撞流程,你只在最后看结果、不中途接力。跑完记一条:哪一步它「meander 跑偏了」、哪一步它「在轨道上移山倒海」。这一条赌注同时验证了三件事——你的流程能不能被当代码跑、哪些检查能客观化成强制关口、以及你到底该把自己从循环的哪个位置移出去。