ESC
↑↓ 选择↵ 打开esc 关闭⌘K 唤起
← Home NO.18
第 18 期 · AGENT 工程 · 收录于 2026 年 8 月 15 日

氛围编程硬件

N
Naval
视频 13:53 原文约 1.5 万字 预计阅读 23 分钟 来源视频 ↗ 中英对照全文
双人对谈 · 本期速读电台 00:00 / 35:52
TL;DR · 三句话
  1. AI 彻底改变了软硬件工程师的分工:软件工程师搭架构,硬件工程师 vibe code(凭手感让 AI 写代码、自己不必精通编程)自己那部分——Boom Supersonic 靠这套,把"光是分析一片涡轮叶片就要 1 个工程师整整 1 天、而一台发动机有上千片"的死活,变成"2 个工程师设计一整台喷气发动机、改一下叶片形状就能实时看到气动和结构结果"。 → 详细
  2. 中国全力押注开源模型(把模型权重免费公开、任何人可下载自用),因为它的本钱在硬件和供应链——逻辑是"只要我能按需把软件生成出来,相对硅谷在软件上的劣势就消失了";但任何要推进前沿(做别人没做过的最难的事)的活,仍只能靠最好的 coding 模型,现在全世界就 2-3 个,中国不在其列。 → 详细
  3. 人正在退到验证者(verifier,不亲手做、只负责检查并为结果背书的人)的位置:律师、工程师、运营的旧职能都转成"为整个技术栈背书"——"这大致是对的,我愿意签字,出了问题我撑你";而且从 0 到 1 造个软件出来很容易,真正难的是 1000 天之后它还安不安全、还有没有人愿意继续投入维护→ 详细
01

开场金句回放(软件篇精华,t000-t004)

  • 工程师该被怎么评判:标准不是单看一件产出,而是"你有没有造出那座能产出 B→Z 这些成倍输出的工厂"(producing the factory that will produce multiplicative outputs B through Z)。差距"甚至不止 10 倍,而是 100 倍、1000 倍,而且一向如此"(it always has been)。 → 详细
  • 模型已追平你:"在一个领域里,Claude 或 ChatGPT 基本上跟你做得一样好。"(as good as you are in a domain) → 详细
  • 心法"浪费 token、省时间"(token 可粗看作"模型读写的每一个词"):原话"just waste tokens, save time"——别管 token 是输入还是输出,"只看自己的时间和最终产出。模型再贵也比雇个人便宜太多(way cheaper than a human)"。 → 详细
  • 模型"毕业"了:"它们以前是 junior engineer(需人盯的初级),现在是 principal engineer(最资深、能定方向那档)。" → 详细
  • 有 agent 不再卡壳:"现在有了 agent,你基本上再也不会卡住了(you just don't get stuck anymore),挺神奇的。" → 详细
02

Naval 的两个引子

  • Naval 抛全场大问题:"纯软件已经死了吗?"(Is pure software dead?)——潜台词:软件谁都能让 AI 生成时,纯做软件还有没有壁垒,价值会不会往硬件这种"AI 还碰不到的实物"转移。随即点名 Blake:"你在 Boom Supersonic 是怎么把这些东西用起来的?"——把话题从抽象拉到一个真造超音速飞机的人身上。 → 详细
03

Boom 的起点:把硬件工程工作流「变成软件」

  • Blake 开宗明义:这件事彻底改变了软硬件工程师的角色(completely changes the role of software and hardware developers)。Boom 从第一天起就想把大量传统硬件工程的工作流"变成软件"。 → 详细
  • 现状有多糟(理解后面所有结论的关键背景):Blake 专门停下来给外行解释——很多硬件工程是"在工程师笔记本上的 Excel 表格里、各自孤岛作业"完成的;那些表格复杂到里面写着 VBScript 代码(Excel 里的宏脚本语言,本质就是编程)。"这其实全都是软件,但大家却不当它是软件"——没有版本控制(source control,记录每次改动、能回退、能多人协作的机制),没有自动化测试。要把活从气动工程师(管空气怎么流过机翼/叶片)交接给结构工程师(管零件受力会不会变形断裂),是手动的——"靠一封邮件发个表格,简直像在 90 年代一样,糟透了"(it's the 1990s, it's terrible)。 → 详细
  • Boom 早期就动手造一批"类似软件框架"的东西,想让硬件流程自动化、可复用、把迭代成本降下来。但"进展很慢"(slowgoing),卡点很具体:永远招不到、也养不起足够多的软件工程师(we could never afford enough software engineers)——这正是 AI 后来解的那个结。 → 详细
04

新分工:软件工程师搭架构,硬件工程师 vibe code

  • 现在 Boom 进入一种"令人震撼的、完全不同的模式"(mind-blowingly different model):软件工程师负责搭架构(create the architectures),因为他们懂系统、懂算法、懂"关注点分离"(division of concerns——把复杂系统切成各管一摊、互不缠绕的模块);然后硬件工程师拿自己对硬件工程的理解,去 vibe code 自己那一块(the hardware engineers can vibe code their pieces)。结果是"小团队的生产力变得截然不同"。 → 详细
  • 涡轮叶片案例(把"为什么以前慢"讲透):拿设计一片涡轮叶片(喷气发动机里高速旋转、像扇叶的核心零件)举例——叶片"冷的时候是一个形状,运转起来会变热、会变大",所以你必须让气动设计和结构设计同时适配它的冷态形状和热态形状,还得"在冷态和热态之间换算、在结构和气动之间换算"(convert between cold and hot, between structures and aerodynamics)。 → 详细
  • 以前的死活有多死:原话——"这一项分析,一片叶片就要一个工程师干一整天(one engineer one day for one blade),而一台喷气发动机里有上千片叶片(a thousand blades in a jet engine),所以你根本做不了多少。" 现在的反转:靠软件人才与硬件人才的结合,Boom"真的做出了解决方案"——"你可以改叶片几何形状,实时看到结构和气动的结果"(change blade geometry, see in real time the structures and aerodynamics results)。于是"两个工程师就能设计出一整台喷气发动机"(two engineers to design an entire jet engine),Blake 形容这"跟以前完全是天壤之别"(wildly different)。关键不在"AI 会写代码",而在架构层和领域层被干净地分开了:架构师不必懂叶片,叶片专家不必懂软件工程。 → 详细
05

企业软件的剧变:协作工具和电子表格都「完了」

  • 顺着 Naval 的复述("你们让软件工程师为其余工程师打造工具和架构"),Blake 抛出更大的判断:"这在我看来是企业软件最大的剧变"(the cataclysm of enterprise software)——"再也没有哪家做硬件协作工具的初创公司能卖给你任何东西了",因为"你在内部随时就把你需要的东西直接编出来了"(you're just coding the right things that you need at any given time)。换句话说:当定制软件的成本趋近于零,"卖通用工具"这门生意的地基就塌了。 → 详细
  • 连电子表格也快完了(even spreadsheets are kind of cooked):Blake 给出原因——"电子表格之所以成功,是因为以前没人能做定制软件,而最接近定制软件的东西,就是一张塞满了 VBScript 函数的表格"。如今 AI 能直接生成定制软件,这个"替代品"的存在理由也就没了。他个人现身说法:"我已经几乎完全从 Excel 转到了 Python 模型,在那里我能真正做出可信的仿真(believable simulations of things)"——Python 是通用编程语言,比 Excel 能表达复杂得多、可信得多的物理模型。 → 详细
06

下一个前沿:AI 生成 step 文件与 PCB 布局

  • Blake 给一个带时间点的预判:有件"AI 还没触及、但我认为一年之内、很可能就在 2026 年内会实现"的事会"非常非常激动人心"——"现在它能生成软件,但很快它就能生成 step 文件和 PCB 布局了"(step 文件是机械设计通用的 3D 模型交换格式,工厂照它加工实体零件;PCB 布局是印刷电路板上元器件怎么摆、走线怎么连的设计图——一个代表机械、一个代表电子)。等 AI 真正搞定机械工程和电气工程时,"那将是我们还没见过的另一番天地,会非常非常酷"。 → 详细
07

对硬件小公司是大利好,可能完全 agentic

  • Max 接过硬件话题:这"对所有那些做小玩意儿、做零部件的小公司是个大利好"——它们以前"软件写得很烂,因为做不出好软件",而"现在它们能做出足够好的软件了"(good enough software)。更激进的设想:那软件甚至"可能根本不是给人用的前端界面"(may not even be a human front end),而是"完全 agentic 的、给 agent 调用的",人"只用语音跟它对话就能控制硬件"。连"你在 Amazon 上随手买来、想在某个慵懒周六下午鼓捣的那些零碎小玩意儿"配的烂软件,"也在很快变得好很多"。 → 详细
08

中国为何押注开源模型

  • Max 给出首要原因:中国全力押注开源,是因为它"有硬件上的优势——非常复杂的供应链和元器件链"(hardware superiority, very complex supply chains and component chains)。算盘是——原话"嘿,只要我能按需生成软件,那我相对硅谷的这个劣势就不存在了"(if I can just generate software on demand, I don't have this disadvantage anymore against Silicon Valley)。即:硬件本是中国长板、软件是短板,开源 AI 恰好补软件这块短板。 → 详细
  • 其它原因:Max 补这不是唯一动机——"它们也是因为落后",在做"蒸馏模型"(用强模型的输出去训练自己的小模型、低成本逼近强模型)、在追赶、在协作共享资源。而且"中国政府一向有这样的传统:去资助那些能带动整个生态发展的项目,尤其在有网络效应的行业里"。 → 详细
  • "讽刺"之处——为什么开源全是中国在做:Max 说"讽刺的是,他们之所以全在做开源,是因为 OpenAI 并不 open",然后逐家点评:Grok(马斯克 xAI)"会发布模型,但落后一两代";Google "有一些本地模型,但没什么真正有竞争力的";Anthropic"据我所知——我甚至都不知道他们有什么开源模型"。结论:"所以所有开源的分量都来自中国"(all the open source heft is coming from China),这"帮了我们所有硬件创业者,但更大程度上帮的是它们自己的硬件创业者、工厂等等"。 → 详细
  • 核心论断(全场最锋利的一句):"没有顶尖的前沿编码模型,你就没有自我改进的能力(without great frontier coding models, you don't have self-improvement)。"推到国家层面:硬件流水线每一环都需要生成软件,所以"如果你在生成软件的能力上落后了,你就会在生成一切的能力上落后"(if you fall behind on your ability to generate software, you fall behind on the ability to generate everything)。最后他好奇地反问在场两人——"你们用中国模型吗?你们认识任何用中国模型的人吗?"——直接引出下一段 Guillermo 的长篇回应。 → 详细
09

Guillermo 回应:永远要最聪明的模型

  • Guillermo 用"昨晚饭桌上的争论"开场:有人主张——"你 97% 的事都会用 DeepSeek,因为它太便宜了;如果你需要更高的智能,你就把同一个问题反复跑很多遍;只有最高难度的任务才会用 OpenAI、Anthropic 这些模型"(DeepSeek 是中国开源大模型,以极低成本著称;"反复跑同一问题"想用"多跑几次取最优"弥补单次智能不足)。 → 详细
  • 他不同意,理由很硬:"智能是一种纯粹的好东西,你永远想要更多"(intelligence is an unalloyed good, you always want more)。关键洞察——"这些模型出错的时候,你是察觉不到的(when these models make a mistake, you don't know it),但它又总是比真人更便宜、更实时",所以理性选择就是"一直用现有最聪明的那个模型"。他坦承代价:这"不一定是好消息",因为会把 AI 推向"垄断或寡头垄断"。为什么宁可用最聪明的:因为他要往里灌的杠杆太大——"资本、代码、人力、还有市场营销",所以"我希望每一次都做出正确的决策"。一个很真实的细节:两个模型都给答案时,"很多时候我其实并不知道哪个才是对的",所以"如果我知道一个模型聪明一点,我就采用它的答案,最终我会干脆不再去问那个我认为比较笨的模型了"。 → 详细
  • AI 网关数据佐证(AI gateway,Vercel 用来集中转发所有应用/agent 对各家模型调用的中间层,因此看得到真实用量分布):Guillermo 说"基本上每个应用、每个 agent 都会经过它",所以"开放模型肯定是有使用量的,但顶端被前沿智能严重占据"(the top is heavily dominated by the frontier intelligence)。 → 详细
  • 一个重要的 caveat(附带说明):"合理的成本和性能下的前沿智能,在规模化场景里真的很能打"(slaps at scale)。例子——"大家对 Gemini 不怎么兴奋",但它在"合适的性能成本组合下其实超级聪明",而且"对很多任务——除了 coding 之外——它们是最好的模型,是最好的工业级量产模型"(the best industrial production models)。这类活包括客服任务浏览器自动化(让 AI 像人一样点网页、填表单),"那种场景我永远会放一个 Gemini 模型,这类活我也会考虑中国模型"。但前沿是另一回事:原话——"任何时候只要我是要去推进前沿,你就需要最好的那个 coding 模型,而那现在基本上就是两三个模型的事,中国模型肯定不在其列"。这正面回答了 Max 的反问:日常量产可用便宜/中国模型,真要做最难的事,只有头部那 2-3 个。 → 详细
10

Max 的垂直整合与极端紧迫感

  • Naval 点名引出话题:"Max,你在往极致的垂直整合和极端紧迫感方向猛推,要不要聊聊?"(垂直整合指把上下游环节都自己干、不外包)。Max 的总原则其实是"能买就买":他特意澄清"我们其实总是更愿意去买"(preference would always be to buy)——只要有供应商好价格供货。例如 PCB 就不自己做,因为"那些基本上是白菜价,你可以从亚洲不限量地买"。 → 详细
  • 那为什么还要垂直整合:因为"我们的产品越接近成为一整块共价键合的物质,它就越好"(a single block of covalently bonded matter——共价键合是原子间最强的化学结合,比喻产品越像"浑然一体的一块"而非"拼出来的"),好处是"功耗更低、体积更小、性能更高、寿命更长"。问题在于"有些元器件根本买不到"。要"真正能在'把买来的现成件拼在一起'之外去创新"——而"光靠拼现成件其实非常非常受限"——"你就得自己去把它学会、自己去做,这体现出来就是垂直整合"。最硬核的具体动作:Science Corp"在东海岸自有一家专属的 MEMS foundry(微机电代工厂)","是我们买下来的,因为实在没有别的办法去做我们想做的那种封装和组装"。 → 详细
  • AI 在公司内部最大的影响竟然在"监管"(反直觉):Max 说"讽刺的是,我们在公司内部看到 AI 最大的影响之一,是在和监管机构打交道这块"。比如要迭代某产品时"可能有成千上万条 ISO 标准适用"(ISO 是国际标准化组织,医疗器械要符合海量强制标准),到底"必须遵守哪些?然后把这条线索一路追下去"。这事"以前你得跟着一整个监管和质量团队忙好几个月",而"现在 AI 基本上就直接知道了"。 → 详细
  • 但软件终究"需要手"(本片对 AI 边界最清醒的一句):说到"外科手术项目、或者 MEMS FAB(晶圆厂)"这类东西时 Max 强调——"软件归根结底还是需要'手'(the software still needs hands)。它会比我们更聪明,但如果它造不出实物,那就是实实在在的边界(if it can't make things, those are real real boundaries)。"他们的应对:给代工厂和很多部门都做了"仪器化和数据化"(instrumented),这样模型一变强,效果"应该会很快直接体现在我们正在做的细胞工程、正在开发的材料科学这类事情上"。 → 详细
11

律师类比:基础活消失,junior 被提拔

  • Guillermo 现身说法:"我已经有挺久没找律师起草一份基础的法律文件了"——"不再找律师要 NDA(保密协议)、要这个协议、签那个、查这个了,所有这些基础法律活儿也都没了"。"法律就是 spaghetti code"这个老笑话:"法律就像意大利面条式代码(缠成一团、互相纠缠、谁也理不清的烂代码):一套非常复杂的'代码'硬要用英文写出来,这边这段跟那边那段相互矛盾,又得塞进另一处,而且根本没有真正的 API"(模块间约定好的清晰接口,法律条文之间没有这种干净接口)。 → 详细
  • 对称的"提拔/被裁"叙事:"junior engineer 基本上被提拔成了 senior engineer,而 junior engineering 这类活则被 agent 接管了。"同理看律师:你"可以说'初级律师助理(paralegal)刚被裁了',也可以说'paralegal 刚被提拔成了 senior lawyer,现在可以把时间花在真正思考法律上'"——同一件事,悲观和乐观两种讲法。 → 详细
  • 深层类比——你信的是"权威背书"而非"逐字核对":"你永远不知道律师往这些文件里塞了什么,你就是信任他们。"你对律师说"能看看这份文件吗?靠不靠谱?帮我做下 red line 修订吗?(在合同上标出要改的地方)"——说到底,"你在和律师的关系里看重的,就是他们是一个可信赖的权威:他们上过法学院,把自己的声誉押在了上面"。 → 详细
12

最大问题:堆积如山的「垃圾代码」与「签字背书」机制

  • Guillermo 把律师类比落到软件上:"今天软件工程最大的问题,是堆积如山的'垃圾代码'最后变成一个 PR"(slop 指 AI 大量生成、质量参差的内容;PR 是 pull request,开发者提交、等人审核合并的一批代码改动)。配一个 Twitter 怀旧 meme:"想当年我们会逐行读完一个 PR 的每一行代码"——言下之意现在代码多到根本读不完。 → 详细
  • 他给出的替代标准——把"读懂"重新定义为"敢签字":在基础设施领域,他要工程师能说"我理解它",但"这不一定意味着你读了 PR 的每一行";你需要能说"我对理解这个 PR 的后果负责签字"(I am signing off on understanding the consequences of this PR),或者"我写了测试框架、仿真、证明、类型检查器等等,所以即便不逐行读,我也有信心签字担保它上生产环境会是安全的"(这些都是不靠人眼、而靠自动机制去保证代码正确的工具)。 → 详细
  • 一种可能的新世界:原话——"存在一种可能的世界,我们坦然接受'一切都会是 spaghetti code、我们并不完全理解它',但我们去写各种评估器(evaluator,自动判断输出对不对的程序)来给我们信心",然后依靠"像基础设施生产工程师这样的人来拍板'好,我没问题,可以推到 prod'"(prod 是真实用户在用的线上系统)——因为"如果你的系统宕了,总会有人被呼叫到(被 page、被自动告警叫醒去救火)"。也就是说:人不再保证"我读懂了每一行",而是保证"出事我兜得住"。 → 详细
  • 被严重低估的一点——0 到 1 容易,1000 天难:原话——"从 0 到 1 创造软件其实非常容易,但想想 1000 天之后呢?"(creating software is really easy 0 to 1, but think about a thousand days from now)连珠炮式追问:"它安全吗?经过测试了吗?是生产级的吗?性能好吗?而你还有没有动力继续把所有这些 token 都投进去、维护它在 prod 上的运行?"(are you still motivated to invest all of those tokens in maintaining it in prod)——点破了"AI 让造软件变易"背后真正的成本黑洞:长期维护。 → 详细
13

收束:人正在变成「验证者」

  • 全场收在一句概括上:"人正在变成验证者(verifier),对吧?"(humans are becoming verifiers)。嘉宾点出一个闭环逻辑——"我们训练这些模型靠的就是优质的验证数据,而现在我们需要人来做验证者":人提供的"对/错判断"既是训练 AI 的燃料,也是 AI 时代人剩下的核心岗位。落点很具体:"人的很多旧职能——律师、工程师、运营人员——都转向了去验证整个技术栈",去说那句贯穿全场的话——"嗯,这个大致是对的,我大致愿意背书,如果出了问题我会支持你"(this is roughly correct, I'll roughly stand behind it, and I'll support you if it goes wrong)。 → 详细

  • "我评判你作为一个工程师的方式,是看你有没有造出那座能产出 B→Z 这些成倍输出的工厂——这甚至不止 10 倍,而是 100 倍、1000 倍,而且一向如此。" —— 嘉宾(开场金句)

  • "尽管浪费 token,省时间就行……这些模型再贵,也还是比雇个人便宜太多了。" —— 嘉宾(开场金句)

  • "硬件工程师可以 vibe code 自己那部分,软件工程师搭架构——小团队的生产力截然不同。" —— Blake Scholl

  • "一片叶片的这一项分析就要一个工程师干一整天,而一台发动机有上千片叶片……现在两个工程师就能设计一整台喷气发动机。" —— Blake Scholl

  • "气动工程师交给结构工程师靠邮件发个表格,简直像在 90 年代一样,糟透了。" —— Blake Scholl

  • "很快 AI 就能生成 step 文件和 PCB 布局了……那将是我们还没见过的另一番天地。" —— Blake Scholl

  • "没有顶尖的前沿编码模型,你就没有自我改进的能力;在生成软件上落后,就会在生成一切上落后。" —— Max Hodak

  • "软件终究需要'手'——它会比我们更聪明,但如果它造不出实物,那就是实实在在的边界。" —— Max Hodak

  • "智能是一种纯粹的好东西,你永远想要更多……而且模型出错时你察觉不到。" —— Guillermo Rauch

  • "从 0 到 1 造软件非常容易,但想想 1000 天之后——它还安全、可维护吗?你还有动力投 token 养着它吗?" —— Guillermo Rauch

  • "人正在变成验证者(verifier)——这大致是对的,我愿意背书,出了问题我撑你。" —— 嘉宾(收束)

  • 本片无独立 lightning round(闪电问答)环节,亦无嘉宾联系方式。

  • 在场四人身份:Naval(主持)、Blake Scholl(Boom Supersonic,超音速客机)、Max Hodak(Science Corp,脑机接口/植入式医疗)、Guillermo Rauch(Vercel,前端云平台,基础设施视角发言多为其本人)。

  • 姊妹篇(同一场对话的软件视角):../17_Naval_浪费Token省时间/Waste Tokens, Save Time_总结报告.md

🎯 于你何益 为你定制 · 非通用结论

这期表面在聊"造飞机、造脑机接口",跟你八竿子打不着。但它真正讲的是一种新分工范式——"懂系统的人搭架构,懂领域的人 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 自己跑出的一个自动检查结果。验证一个假设——当首屏从"看不懂的一堆产出"变成"几个我敢签字的决策"时,激活体验是不是就顺了。一周内能看出这条路对不对。

接着读