这期表面在聊"造飞机、造脑机接口",跟你八竿子打不着。但它真正讲的是一种新分工范式——"懂系统的人搭架构,懂领域的人 vibe code 自己那块,最后由人做验证者背书"——而这套范式恰好就是你 app_incubator 和 Holdwell PRD 工厂正在做的事,只不过这帮人已经在真刀真枪的硬件上验证过了一遍。再加上 Max 那段中国押注开源的产业判断,对你的价值投资也是现成的镜头。相关度高,分三块给你。
🛠️ app_incubator(7-Agent 造 App 链路)
1. "架构 vs vibe code" 的分工,正好是你多-Agent 该有的骨架
- 怎么做的:Blake 说 Boom 现在的模式是——软件工程师负责搭架构(因为他们懂系统、懂算法、懂"关注点分离",即把复杂系统切成各管一摊、互不缠绕的模块),然后硬件工程师拿自己的领域理解去 vibe code 自己那一块。结果是涡轮叶片那种"以前一个工程师一天只能算一片、一台发动机上千片"的死活,变成"两个工程师设计一整台喷气发动机,改个叶片形状实时看到气动和结构结果"。关键不是"AI 会写代码",而是架构层和领域层被干净地分开了——架构师不需要懂叶片,叶片专家不需要懂软件工程。
- 你可以怎么做:你的 7 个 agent 现在的痛点是"激活/首屏体验"和"把该做什么前移到 agent"。照这套,你该问的是:你的链路里谁是那个'搭架构'的 agent,谁是'vibe code 自己那块'的 agent?设计稿即工程契约这条线,本质就是 Blake 说的"架构师定关注点分离"——那张 Figma 稿就是架构。下一步落到具体:挑一个真实 App 需求,明确标出"架构决策"(信息架构、数据流、模块边界)由哪个 agent 一次性钉死,"实现填充"(某个页面、某个组件)交给下游 agent 凭领域手感去填——别让一个 agent 既定架构又写实现,那正是 Boom 以前"孤岛 Excel"的翻版。
2. "人是验证者、敢签字而非读每一行" —— 你的激活体验该绑这个
- 怎么做的:Guillermo 把"读懂代码"重新定义了。他说软件工程最大的问题是"堆积如山的垃圾代码(slop)最后变成一个 PR",多到根本读不完。他的替代标准不是"我读了每一行",而是"我对理解这个 PR 的后果负责签字",或者"我写了测试框架、仿真、证明、类型检查器,所以即便不逐行读,我也有信心担保它上生产环境安全"。落点是 Naval 收束那句——"人正在变成验证者(verifier):这大致是对的,我愿意背书,出问题我撑你。"
- 你可以怎么做:你想把"该做什么"前移到 agent,那对应的人侧动作就是把人的角色从"审每一步"压缩到"在关键 gate 签字背书"。具体:在你的造 App 链路里,别指望用户逐屏审 agent 产出(那就是读不完的 PR),而是设计几个明确的"签字点"——比如"设计契约确认""核心数据流确认""上线前确认"——每个点给用户一个可背书的摘要 + 自动检查结果(agent 自己跑的校验/预览),用户只需说"这个我认、出问题我担"。这正是把首屏从"看不懂的一堆东西"变成"几个我敢签字的决策"。
3. "0 到 1 容易,1000 天难" —— 给你的产品观补一刀
- 怎么做的:Guillermo 最锋利的一句——"从 0 到 1 造软件非常容易,但想想 1000 天之后呢?它安全吗?测试过吗?是生产级的吗?性能好吗?你还有没有动力继续投 token 维护它在线上跑?"他点破:AI 让"造出来"变易,但真正的成本黑洞在长期维护。
- 你可以怎么做:你的 agent 链路擅长"从 0 到 1 吐出一个 App",但这句提醒你——demo 跑通不等于产品成立。下一步可以给链路加一个常被略过的产出物:"day-1000 清单"(这个 App 谁来维护、靠什么自动测试守住质量、依赖会不会烂掉)。哪怕只是让生成 App 时顺手带一份"可维护性自检",也比交付一个三个月后没人敢动的黑盒强。
🏭 Codex Holdwell ERP work(PRD 工厂 + 跨线对齐)
1. "Excel 里其实全是软件,但没人当它是软件" —— 你六条产品线的共享定义没人当"软件"管,正是这个病
- 怎么做的:Blake 停下来给外行解释硬件工程现状——很多活是"在工程师笔记本的 Excel 表格里、各自孤岛作业"完成的,表格复杂到里面写着 VBScript 代码(Excel 的宏脚本,本质就是编程)。他一针见血:"这其实全都是软件,但大家却不当它是软件——没有版本控制、没有自动化测试。"交接靠"一封邮件发个表格,像在 90 年代一样"。
- 你可以怎么做:你 ERP 的痛点里有"跨线对齐"——六条产品线强耦合、跨线联动频繁。Blake 这话就是诊断书:你那些散在各条产品线 PRD 里、口口相传的业务实体定义和字段约定,其实早就是"软件"了,只是没被当成有版本、有单一事实源的东西管起来——这正是跨线对不齐的根因。下一步不是再写文档,而是把最常被跨线引用的几个核心实体/术语沉淀成一份所有 agent 都读的单一事实源,把"邮件发 Excel"式的口头对齐变成"三驾马车读同一份定义"。定义收拢一块,跨线联动就少撕一块。
2. "企业软件的剧变:通用工具卖不动了,你随时把要的东西编出来" —— 反过来想,对你是利好
- 怎么做的:Blake 抛出"企业软件最大的剧变"——"再也没有哪家做硬件协作工具的初创公司能卖给你任何东西了,因为你在内部随时就把需要的东西直接编出来了"。连电子表格也"快完了",因为"表格成功只是因为以前没人能做定制软件"。
- 你可以怎么做:你做的 PRD 工厂本身就是一套"内部定制软件能力"。这条印证了你方向对——当定制软件成本趋近于零,'买一套通用 PRD 工具'的价值就在塌,而'自己长出一套贴合 Holdwell 业务的 agent 工厂'的价值在涨。这给你"agent 产出的可观测/可验证"这个痛点一个论证角度:你不是在重复造轮子,你是在做"通用工具永远给不了的、贴着自家业务的那块定制能力"——要证明这套工厂的价值时,不妨直接拿"这件事买不到现成工具、只能自己编"的具体场景说话。
3. "gate = 签字背书点" —— 你的真人评审闭环,可以照验证者模型设计
- 怎么做的:同样是上面那套"验证者 / 签字"机制——人不再保证"我读懂每一行",而是保证"我对后果负责、出事我兜得住",靠的是测试框架、评估器(自动判断输出对不对的程序)这些不靠人眼的机制来撑信心。
- 你可以怎么做:你 ERP 当前的痛点里有"真人评审意见回炉的闭环"和"agent 产出的可观测/可验证"。这套给你一个可落地的评审形态:PRD 流程每个环节的把关,不该是"人肉读完所有产出",而该是"一个负责人在自动校验通过的前提下签字背书"。把三驾马车碰撞后的真人评审做成"评估器 + 人签字"的组合——机器能判的检查自动跑(这就是 Guillermo 说的 evaluator/type checker),人只在"我愿意为这一版定稿背书"这一下做强制确认。评审意见回不了炉,往往是因为没人敢/没法签字;给签字配上自动证据,评审才有牙齿。
📈 投资视角 · StockHelp / 价值投资
1. "没有前沿编码模型,就没有自我改进;在生成软件上落后,就在生成一切上落后" —— 一条现成的产业护城河论断
- 怎么做的:Max 给出全场最锋利的国家级判断——"没有顶尖的前沿编码模型,你就没有自我改进的能力",因为硬件流水线每一环都需要生成软件,所以"在生成软件上落后,就会在生成一切上落后"。而 Guillermo 用 Vercel AI 网关(几乎每个 app/agent 调模型都过它,看得到真实用量)的数据佐证:"开放模型确实有用量,但顶端被前沿智能严重占据"——真要推进前沿,"全世界基本就两三个模型"。
- 你可以怎么做:你是找"卓越生意 + 护城河"的价值投资者。这给你一个判断 AI 公司护城河深浅的尺子:别被"开源/便宜/榜单分数"迷惑,问的是"这家是不是那 2-3 个能定义前沿、并因此具备'自我改进飞轮'的玩家之一"。Guillermo 还补了个反直觉点——"智能是纯粹的好东西,理性选择是永远用最聪明的那个",所以这个市场天然滑向"垄断或寡头垄断"。对 StockHelp 选股逻辑:前沿大模型层可能是个"赢家通吃、寡头格局"的赛道,这种结构对头部是极强护城河、对追赶者是估值陷阱——把"是否处于那 2-3 名"作为一条能力圈内的硬判据。
2. "中国押注开源是因为硬件是长板、软件是短板" —— 一条产业格局的母题
- 怎么做的:Max 拆解中国全押开源模型的算盘——"它有硬件优势(复杂的供应链和元器件链),逻辑是'只要我能按需生成软件,相对硅谷的劣势就不存在了'"——即用开源 AI 补软件这块唯一短板。他还点出"所有开源的分量都来自中国"(因为 OpenAI 不 open、Grok 落后一两代、Google 没真竞争力、Anthropic 几乎没开源模型),这"更大程度上帮的是它们自己的工厂和硬件创业者"。
- 你可以怎么做:你做美股/港股价值投资,这是一张理解"中美 AI + 硬件"产业地图的高质量底图。它提示你一个可长期跟踪的母题:"开源模型 + 中国硬件供应链"这个组合,会系统性抬升哪些公司的竞争力(中国制造、硬件代工、机器人、智能硬件),又会侵蚀谁的护城河(卖通用企业软件工具的)。不必急着下注,但可以在你的能力圈里把"谁拥有'复杂供应链'这种 AI 也难替代的实物长板"列成一个观察清单——Max 说得很清楚,"软件终究需要手,AI 比我们聪明但造不出实物就是实实在在的边界",能造实物的环节,护城河反而更稳。
🔄 更深三个角度
该反着用:这帮人是"资源足、要推进前沿、愿意为最聪明的模型付任何代价"的玩家(Guillermo 说他往里灌"资本、代码、人力、营销",所以每次都要最聪明的那个)。你正相反——你是一个人扛多线、精力是最稀缺资源的副业者。所以"永远用最贵最聪明的模型、不计成本反复跑"这条对你要反过来:你该学的是 Guillermo 那个 caveat——"合理成本和性能下的前沿智能在规模化场景很能打",客服、浏览器自动化这类活用 Gemini/便宜模型就够。只在你真正要"推进前沿"的那一两件事上(比如你最该 all-in 的那个编码下注)才上最强模型,其余一律省。把"不计成本"翻译成你的语境,就是"分清哪件事配得上最贵的那一发"。
和你现在做法冲突:你的 PRD 工厂和第二大脑都信奉"把流程写厚、定义清晰、人能读懂每一步"(三驾马车碰撞协议、原子笔记)。但 Guillermo 描绘的新世界是"坦然接受一切都是 spaghetti code、我们并不完全理解它,靠评估器给信心、靠人在出事时兜底"。这跟你"凡事都要可读、可追溯"的本能直接顶。张力在这——当产出量大到人读不完时,你是继续追求"读懂每一行",还是转向"我敢签字 + 自动证据兜底"?不替你下结论,但这个矛盾值得你在 ERP 真人评审的设计上认真坐下来想:你的评审到底要"人读完"还是"人背书"。
对你的镜子:你一直纠结"该 all-in 哪个编码下注、不公平优势在哪"。这期给你一面镜子——真正稀缺的不再是"会造东西"(0 到 1 谁都行了),而是"愿意为某件事背书、并撑到 1000 天之后"。你同时推 7 条线、精力摊薄,恰恰意味着你给每件事的"背书浓度"都不够。也许你的不公平优势不在"再多造一个东西",而在敢对哪一件事说"这个我签字,出问题我撑到底、养它一千天"——那件你真愿意背书的,才是你该 all-in 的下注。
One Human Company 新号(2026-07 回填)
这期讲硬件 vibe coding,表面跟你号八竿子打不着,但中间那条"人正在变成验证者"的主线,恰好是你「一人公司 build-in-public」号最该讲清的身份问题——一个只有 1 个人类的公司,那个人类到底在干什么。
1. "人正在变成验证者(verifier)"——这就是你一人公司里唯一人类的岗位说明书
- 怎么做的:全场收在一句话上——"人正在变成验证者:这大致是对的,我愿意背书,出了问题我撑你。"Guillermo 把"读懂代码"重新定义成"敢签字":软件工程最大的问题是"堆积如山的垃圾代码(slop)变成一个读不完的 PR",人不再保证"我读了每一行",而是保证"我对这个 PR 的后果负责签字"、靠测试框架/评估器这些自动机制撑信心。他还补一刀被严重低估的点:"从 0 到 1 造软件非常容易,但想想 1000 天之后——它还安全、可维护吗?你还有没有动力投 token 养着它?"
- 你可以怎么做:这是一条现成的 C 类「大佬说 X 我试了」,且直击你号的独占身份。候选标题:「大佬说'AI 时代人退为验证者',我在 drizzle tech 当了三个月唯一人类,说说这活到底是什么」。你拿 drizzle tech 验的是:当 9+1 个 Agent 把 App 造出来,你这个唯一的人类的活是不是真的从"手做"塌缩成了"签字背书"——你给什么产出签过字、靠什么(测试?预览?评估 Agent?)敢签、哪次签错了栽跟头。这同时喂 B 支柱(人怎么给 AI 产出验收)。诚实反驳(弹药库闸门要的):把 Guillermo"0→1 易、1000 天难"接上——你第一个 App demo 跑通不等于产品成立,验证者这活最难的不是签字、是签完还得撑它一千天,你现在扛不扛得住。
🧭 所以呢
可迁移思维模型
- 【耐用】架构 / 领域 / 验证三层分工:懂系统的人搭架构 → 懂领域的人填实现 → 人做验证者签字背书。这套不依赖具体模型代次,AI 再强它都成立,可以直接焊进 app_incubator 和 ERP 工厂的角色设计。
- 【耐用】"0 到 1 容易,1000 天难":永远把"造出来"和"养得活"分开估值——无论看自己的产品,还是看投资标的(一家公司的真护城河也在"1000 天后还在不在")。
- 【会过期】"全世界只有 2-3 个前沿编码模型、中国不在其列":这是 2025 年底的快照,模型格局变得极快,明年大概率不一样。当判据用可以("是否处于头部"),但别把"具体哪几家"当常量。
判断更新
- 旧判断:把"该做什么前移到 agent"主要当成"让 agent 更主动、更聪明"。
- 新判断:它的另一半是人侧的重构——把人从"审每一步"压缩到"在几个 gate 签字背书"。前移 agent 能力 + 后撤人到验证者,是同一件事的两面。app_incubator 的激活体验和 ERP 的评审环节,都该按这个双向重构来设计。
这周一个赌注
挑 app_incubator 一个真实 App 需求,只做一件事:把链路里的人侧交互重画成"3 个签字点 + 每点一份可背书摘要"(设计契约 / 核心数据流 / 上线前),每点配上 agent 自己跑出的一个自动检查结果。验证一个假设——当首屏从"看不懂的一堆产出"变成"几个我敢签字的决策"时,激活体验是不是就顺了。一周内能看出这条路对不对。