构建AI原生公司
- 一Dan Shipper（Every 联合创始人兼 CEO）开场就声明自己手里没有「AI 原生公司打法（playbook）」这种现成框架——因为「这套打法现在正在被发明出来」（the playbook is actually being invented right now），他和在座每个人都在同时摸索；他能给的只是「来自未来的快讯」（dispatches from the future）。他坚信「90% 工程师用 AI」和「100% 工程师用 AI」之间存在 10 倍的差距，因为只要还有 10% 的人用传统工程方式，整个组织就「不得不整个往那个旧世界靠回去」（you sort of have to lean all the way back over into that world），反而被这 10% 拖住、做不了 AI 原生才能做的事。 → 详细
- 二Every 是一个「探索可能性的实验室」（a little bit of a lab for what's possible）：15 个人撑起 6 个业务单元、4 款软件产品，99% 的代码由 AI agent 写（没人手写代码），每款 app 由单个开发者独立构建与维护；过去 6 个月 MRR 连续两位数增长、7000+ 付费用户、10 万+ 免费用户，而总融资只有约 100 万美元——极度「省钱」（capital-light）。 → 详细
- 三他们把这种新编程方式命名为 compounding engineering（复利式工程）：一个 plan（规划）→ delegate（委派）→ assess（评估）→ codify（沉淀） 的四步循环，目标是让「每做一个功能都让下一个功能更容易做」（区别于传统工程里每个功能都让下一个更难做）。把这套做透，会催生一连串「不那么显而易见的二阶效应」（non-obvious second order effects）：demo culture、隐性代码共享、不必统一技术栈、新人首日即产出、跨产品互提 PR、连管理者乃至 CEO 都能提交代码。 → 详细
没有现成打法，只有「来自未来的快讯」
- Dan 是当天最后一位讲者，开场自嘲「站在我和大家的晚餐或者酒局之间的就是我了」，还插科打诨缓和气氛（刷推特看到「有人说大家都搬去旧金山了」、现场人这么多让他意外、一句「我他妈太爱纽约了」引来全场笑声）。进入正题他坦言：这场本该讲「怎么搭一套构建 AI-native 公司的 playbook」，但他没有这套现成打法——因为「这套打法现在正在被发明出来」（the playbook is actually being invented right now），不光 Every 在摸索，「今天在座的各位也都在做这件事」，所以他明确不想用「我手握所有答案、来给你们讲框架方法论」的姿态分享。他的立场：在「刚开始学着用 AI 做工程、建公司」这个起步阶段，最有价值的是把各公司内部的亲身经历拿出来、协作把打法摸出来（collaboratively figure out the playbook together）；他能给的「最好的东西」就是「来自未来的快讯」（dispatches from the future）——不是带回一套地图，而是带回几张「前线明信片」，告诉你他先走一步看到了什么。 → 详细
90% vs 100%：工程师用 AI 的「10x 差异」
- 他注意到的第一件大事：一家 90% 工程师用 AI 的公司，和一家 100% 工程师都用 AI 的公司之间，确实存在一个「巨大的、10 倍的差距」（a huge... 10x difference），两者「完全不一样」（totally different）。这里的「用 AI 做工程」通俗讲就是：不再自己一行行敲代码，而是把活儿交给 coding agent 去写。他点明自己「知道这一点，是因为这就是我们在 Every 的做法」，并说这「彻底改变了我们这样一家小公司能做到的事」（totally transformed what we are able to do as a small company）。 → 详细
- 关键机制是一种「被旧世界拽回去」的效应：哪怕你公司里只有 10% 的人还在用更传统的工程方式，你「就不得不整个往那个旧世界靠回去」（you sort of have to lean all the way back over into that world）。这就会拦住你，让你没法去做那些「如果所有人都不用一直盯着代码编辑器敲字」（not typing into a code editor all the time）时本来可以做的事。换句话说，组织的协作方式会被最「传统」的那一小撮人锁定在旧范式里——这是个全有或全无的临界点，不是线性的：差的不是那 10% 的人没用 AI，而是这 10% 把另外 90% 也一并拖回了旧世界。演讲收尾时他又把这条作为第一点郑重重申：当 AI 采用率拉到 100% 时，做事的方式会有 10 倍的差别。 → 详细
Every 的具体数字（实验室画像）
- 他自我定位是把 Every 当成一个「探索可能性的实验室」（a little bit of a lab for what's possible）。公司结构：6 个业务单元（business units），运营 4 款软件产品，全公司只有 15 个人——他自己都说这「挺疯狂的」（kind of crazy）。 → 详细
- 他强调这些产品不是玩具（not toys）：过去 6 个月每个月的 MRR（月度经常性收入）都是两位数增长（grown MRR by double digits every month for the last 6 months）；有超过 7000 个付费订阅用户、超过 10 万个免费订阅用户。而且这一切是以一种「非常省钱」（capital-light）的方式做到的——总共只融了大概 100 万美元。对一家做了 4 款付费产品、还在双位数增长的公司来说，百万美元的总融资是极小的数目，这正是他想让听众记住的反差。 → 详细
- 对这场听众「特别重要」的一点：Every 99% 的代码是 AI agent 写的——他连说三遍强调「没有人手写代码，根本没人在写代码」（no one is handwriting code. No one is writing code at all）。工具上是「Claude Code、Codex、Droid 这些」，「你喜欢哪个 coding agent 就用哪个」（coding agent of your choice）。另一条对这种团队规模「特别关键」的事实：每一款 app 都是由一个开发者单枪匹马（single developer）做出来的，他再次形容「这很疯狂」。 → 详细
单个开发者维护复杂生产应用（产品举例）
- Kora：一款 AI 邮件管理 app（an assistant for your email）。Dan 现场演示了它的界面：左边会把所有进来的邮件都做个总结，让你「用这种方式来读邮件」（这就是他本人的收件箱长的样子）；右边是一个可以问答的邮件助手，他举的例子是问它「我今天的 AI engineer 演讲是什么时候」（when's my AI engineer talk today），助手「就直接把答案给我了」。这个产品「主要是一个工程师做出来的」，只有「一两个外包（contractors）在某些地方搭了把手」，但「基本上几乎全是一个人做的」。 → 详细
- Monologue：一款语音转文字（speech-to-text）app，他类比为「有点像 Super Whisper 或者 Whisper Flow」（两款知名的语音输入工具）。同样是「一个人做的，几千个用户」；他很喜欢它，称这是个「做得特别漂亮的 app」，而且「一点也不简单，挺复杂的，里面有很多东西」（it's not simple. It's complicated）。Spiral 这款 app 也一样——「你能看到它体量很大」，同样「就一个工程师」。他用这几个例子坐实「单个开发者也能扛起一款复杂生产级产品」并非吹嘘。 → 详细
- 他强调这些「几年前是不可能做到的，哪怕在一年前也不可能」。而那个「大变化」——「我们现在都还在追赶它」——是「从 Claude Code 开始的」：这种「终端式的 UI（terminal UI）把代码编辑器给干掉了」（gets rid of the code editor），真正把人推到了一个「我们在把任务委派给这些 agent」的状态（delegating tasks to these agents），从而「能并行地干活，做到比平时多得多的事」。所谓「终端式 UI 干掉代码编辑器」，通俗说就是：你不再在编辑器里逐行写代码，而是在命令行里用大白话下指令、让 agent 替你改代码。 → 详细
并行作业与「便宜的代码」解锁实验
- 他特意「点明」之所以能快很多，是因为可以并行处理多个功能和 bug（work on multiple features and bugs in parallel）。他主动回应了推特上那个「vibe coder 段子」：说这类人「开了四个窗格（panes），但其实根本没在干活」。Dan 承认「你确实可以那么混」（you can do it that way），但他很清楚确有工程师——「因为他们就在 Every 上班」——是「真的在同时高效地用着四个 agent 窗格干活」（productively using four panes of agents at the same time）。这一点「很大程度上促成了一个开发者能独立构建并运营一款生产级应用」。（注：vibe coding 指几乎只靠自然语言指挥 AI 写代码、自己不深究实现细节的做法；「四个窗格」即同时开四个 agent 各干一摊。） → 详细
- 另一个「特别重要、很大的解锁」是「代码很便宜」（code is cheap）：正因为生成代码的成本极低，你可以「拿那些有风险的点子去做原型」（prototype risky ideas），从而「做比平时多得多的实验」（more experiments than you would ordinarily）。而这又让你「取得多得多的进展」，因为「『试一下某件事』的**启动成本（starting energy）低太多了」。他给了个生动的画面：你只要随口说一句「去把这个做了，去给我想做的这个大重构（big refactor）**做点调研」，然后「就可以去忙别的了」（go off and do something else）——他评价「这是一件特别大的事」。打个比方：以前试一个想法像要先搭脚手架才能动工，现在像随手按个开关，所以你敢于多按几次、试更野的点子。 → 详细
从 memo culture 转向 demo culture
- 他「特别喜欢、在组织内部注意到」的一件有意思的事：Every「正在更多地转向一种 demo culture（演示文化）」。对比一下旧路径——以前你要是想做个什么东西，「你可能得写一份 memo、做一个 deck，或者去说服一帮人『花时间在这上面是个好主意』」（convince a bunch of people that it was a good idea to spend time on）。也就是说，过去一个想法要先过「文档 + 汇报 + 说服」这道关，才轮得到动手——而这一关本身就会筛掉大量「不好用 PPT 讲清楚、但其实值得一试」的点子。 → 详细
- 而现在，因为「你能在几个小时里 vibe code 出一个能大致展示你想做的东西的原型」，它就「让你可以直接展示给所有人看」——用能跑的 demo 代替了 PPT 和备忘录。Dan 认为变成 demo culture 之后，「能去做一些更『怪』的东西」（weirder things）——他特别点出那是一种「只有你能亲手感受到它的时候才会冒出来」的点子（you only get if you can feel it）：很多想法在文档里论证不出好坏，只有做成能点的东西、亲手摸过才判断得了。他评价这「真的很棒」，但也明确把它和后面更深的「工程基本单元」之变区分开——demo culture 只是基础的生产力解锁，还只是开胃菜，真正的大变化在下一节。 → 详细
新的工程基本单元：往技术栈上「挪一层」到英文
- 他指出，「不只是这种基础的生产力解锁」——AI、以及「我们使用它的方式」，已经促使他们「发明出了一整套全新的工程基本单元和流程」（an entirely new set of engineering primitives and processes）。他判断在座各位「也都开始这么做了」，且「大家其实是从不同角度逼近同一批东西」（approaching the same things from different angles），其中很多「确实呼应了过去的工程流程」（echo engineering processes from the past），但他认为把它「点明」很有价值。（「工程基本单元/primitives」可理解为搭工程这座房子的「砖块」——AI 时代砖块本身换了。） → 详细
- 他抛出的核心隐喻是「在技术栈上往上挪一层」（moving up a level of the stack）：编程正「从 Python、JavaScript 这些脚本语言往上挪，挪到了『英文』这一层」（from Python and JavaScript and scripting languages up into English）。也就是说，自然语言（英文）正在变成新的「编程语言」——你对 agent 说的话，就是新的源代码，而底下用什么语言、什么框架实现，反而退居其次。这是个会连带改写一整套协作方式的转变：当源代码变成英文，「沟通需求」和「写代码」之间那道墙就塌了。他们给这套新编程方式起的名字就是 compounding engineering（复利式工程）——下一节专门拆它。 → 详细
Compounding Engineering 是什么：四步循环
- 核心定义（他原话的对照）：在传统工程里，「每做一个功能，都会让下一个功能更难做」（each feature makes the next feature harder to build）；而在 compounding engineering 里，「你的目标是确保每做一个功能，都让下一个功能更容易做」（each feature makes the next feature easier to build）。「compounding（复利）」一词正是借金融里「利滚利」的意象——每次工作不只交付当下这个功能，还把经验「存」进系统、让后续越做越省力。他们「是在一个**循环（loop）**里做到这件事的」。 → 详细
- 这个循环有四步。① plan（规划）：他说「如果你今天一直在场、一直在认真听，你就知道跟 agent 协作时，做一份非常非常详细的计划有多重要」——所以「大家应该都在做这件事」。② delegate（委派）：「就是直接让 agent 去把它做了」，这个「大家也都在做」。③ assess（评估）：判断「agent 干的活到底好不好」，他一口气列了「海量的办法」——「有测试（tests）、有亲自试用（trying it）、有让 agent 自己去搞清楚、有 code review、有 agent code review，各种各样的招数」。 → 详细
- 第四步 codify（沉淀）是 Dan 眼里「最有意思的一步」，他直接称它是「那个最值钱的一步」（the money step）：你把「规划阶段、委派阶段、评估阶段里学到的一切，全都复利式地沉淀回 prompt 里」，具体写进「你的 Claude MD 文件、你的 sub-agent、你的 slash command」，「然后你就开始打造出这么一个库（library）」。本质动作是：把你和所有工程师在「找 bug、修计划、委派工作」过程中积累的那些「只可意会的隐性知识」（tacit knowledge），「全都收集起来，变成一套显式的 prompt 集合（explicit collection of prompts），可以铺给你整个组织用」。（Claude MD = 项目里给 AI 看的说明书；sub-agent = 专门干某类活的子 agent；slash command = 预存好的一键指令——三者都是把经验固化进工具的载体。） → 详细
- 他补充：当你把 codify「做得特别好」时，会冒出「很多特别有意思的二阶效应（second order effects）」——这些效应「还没被很好地理解、也没被经常拿出来谈」。他猜「有些人其实已经看到这些了，但可能还需要再往前推一把才能真正显现出来」；而对另一些人，这「或许是个有意思的切入点，能让你组织里更多人愿意去 100% 地用上这些工具」——也就是说，把二阶好处摆出来，本身就是说服团队全员上车的钩子。下面四条就是他点出的二阶效应。 → 详细
二阶效应之一：隐性代码共享与不必统一技术栈
- 第一个二阶效应：隐性代码共享（tacit code sharing）变得容易得多。Every「有好几款产品」常需在不同技术栈上实现相似的东西（他举例「团队 teams 功能」「某种 OAuth」）。以前共享代码得先「抽象成一个库」让别人下载、否则就「当面聊」；有了 agent，「你只要把 Claude Code 实例指向旁边那位开发者的 repo」，就能学到他构建那个功能「走过的整个流程」，再用你自己的栈「重新实现一遍」——共享的不是代码本身而是「怎么做出来的过程」，这正是「隐性」之义。由此引出反直觉选择：Every「到现在都还没被迫统一到某套技术栈或语言上」，反而让每人「自己挑最顺手的」，因为「AI 让这些东西之间的转译变得容易多了」——传统上「统一技术栈」是为降协作摩擦，AI 把这块摩擦消解了。 → 详细
二阶效应之二：新人首日产出 + 专家自由职业者「DJ 式」插入
- 第二个二阶效应：「新员工第一天就能产出」（new hires are productive on their first day）。机制是你已把摸索出的东西（「怎么搭开发环境」「一个好的 commit 长什么样」）攒进 Claude MD / Cursor / Codex 文件，新人一来，「agent 直接就把他们的本地环境搭好，还知道怎么写一个好的 PR」——过去要靠老员工带、口口相传的上手套路，被固化成文件、新人一来就继承全套。这也利于雇专家级自由职业者（expert freelancers）：「总有那么一个人特别擅长某一件具体的事」，你可以「请他来一天专门搞定那件事」。Dan 的妙喻——这「有点像一个 DJ，能上来给一首歌加几个小节（a couple bars）」，随时「插进来帮一手」（just sort of drop in）。他强调换作以前「这种协作基本搞不起来，因为启动成本太高了（the startup cost is too high）」，现在因为环境、规范、上下文都已被 codify，专家不用花半天熟悉项目就能直接出活。 → 详细
二阶效应之三：跨产品互提 PR，甚至预想让用户提 PR
- 第三个二阶效应：「Every 内部的开发者会给别的产品提交代码」。背景是内部「跑着四款产品，每个人都在用所有这些产品」（everybody uses all the products）。碰到 bug、或「一个小到让人膈应、想顺手改掉的体验问题」（他用了 paper cut／纸割伤这个生动比喻），他们「往往就直接给那个产品的负责人提一个 PR」——因为现在太简单了：拉下代码仓库，自己琢磨，或「干脆让 Claude 或 Codex 去搞清楚该怎么修」。他评价这让「跨产品协作轻松太多了」，并抛出更大胆的设想（speculative）：未来几年「你甚至能在一定程度上让用户也这么干」——碰到 bug，「你可以让你自己的小 agent 把它修好，然后以 PR 的形式提交上来」，他形容这是「一种很奇特的开源玩法」（a weird open source thing）。也就是说，未来用户不再只「报 bug」，而可能直接「带着修好的补丁来」。 → 详细
二阶效应之四（Dan 最爱）：管理者甚至 CEO 也能提交代码
- 「最后一点是我最喜欢的」——但他也直言「它同时也是某些开发者的噩梦（horror），某种程度上可能也是我们团队的噩梦」——那就是「管理者也能提交代码」（managers can commit code）。条件是「只要你懂技术，哪怕是 CEO 也行」。他诚实地承认自己「本来是没什么理由去提交代码的」：理由很硬——「我们有四款产品、15 个人、增长又特别快，我手上还有一堆别的事要忙」；但「我确实可以，而且过去这几个月我真的往生产环境提交过代码」（committed production code over the last couple months）。 → 详细
- 背后的机制是：AI 让工程师能在「注意力被打碎」的状态下工作（work with fractured attention）。他对比道——以前「你可能需要一整块三四个小时的专注时间（a 3 or 4 hour block of focus time）才能做成点什么」；但有了 Claude Code，「你可以刚开完会就说：『嘿，我想让你去查一下这个 bug。』然后就去忙别的，回来时手上已经有了一个方案，或者一个找到根因的修复（root cause fix），接着你就能提一个 PR」。他特意泼了点冷水保持诚实：「这并不轻松，也不是什么魔法（not magic），但它确实是可行的」。他把这定性为「一种全新的思路——管理者该如何与他们亲手做的产品打交道」。对管理者而言，这意味着不必为了写代码而牺牲整块时间，可以把零碎的会议间隙也变成有产出的时间。 → 详细
总结与对未来组织的预测
他做了三点总结：① 拉到 100% AI 采用率会有 10 倍差异；② 「从我们目前看到的情况，单个工程师应该就能构建并维护一款复杂的生产级产品」（a single engineer should be able to build and maintain a complex production product）；③ 这就是 compounding engineering，它「真正起作用的地方，是让每一个功能都更容易做出来，进而催生出一堆并不那么显而易见的二阶效应，让整个组织协作起来都更顺畅」。最后他用一句带「先知感」的话收束：「旧金山很多人还不知道这件事，所以你们是第一批听到的」（many people in San Francisco don't know this yet... you're the first to hear it）——把现场观众定位为最早接触这套「未来组织形态」的人，呼应全场「来自未来的快讯」这一主轴。 → 详细
本场没有 lightning round（闪电问答环节）；收尾是一段产品/公司介绍。Dan 把 Every 定位为「你站在 AI 最前沿所需要的唯一一份订阅」（the only subscription you need to stay at the edge of AI），官网在 every.to。Every 做三件事：ideas（思想）/ apps（产品）/ training（培训）——ideas 这边有「一份关于 AI 的日报（daily newsletter）」，且「每当有新模型/新产品发布都会评测」；apps 这边就是前面演示的 Kora / Monologue / Spiral 等「打包在一起」；training 这边「为大公司做培训和咨询，帮他们用好 AI」。最关键的商业设计是「这一切全部打包进一份订阅里，所以你一个价格就能拿到全部」（everything for one price）。 → 详细
官网：every.to（Every 联合创始人兼 CEO Dan Shipper）。 → 详细
这一期对你高度相关——几乎是为你的处境量身定做的。Dan 用 15 个人撑 6 个业务单元、99% 代码交给 agent、单个开发者扛一款生产级产品，回答的正是你天天在练的同一个命题：一个人怎么靠 AI 把"多线作战"从负担变成杠杆。下面按你正在跑的项目分组，只挑真能落地的。
🧩 本人单兵公司 / 你的精力这条元约束
怎么做的：Every 全公司 15 个人，却跑 6 个业务单元、4 款付费软件，过去 6 个月 MRR 连续两位数增长、7000+ 付费用户，而总融资只有 约 100 万美元——Dan 反复强调这是"极度省钱（capital-light）"。更狠的是每一款 app 都由单个开发者独立构建并维护，99% 代码无人手写。他把这套能力的临界点说得很硬：90% 用 AI 和 100% 用 AI 之间是 10 倍差距，因为只要还有 10% 的人用老办法，"整个组织就不得不往那个旧世界靠回去"，被那一小撮人锁死在旧范式里——这是全有或全无，不是线性递增。 你可以怎么做：这就是你"一人扛正职 + 多副业"那条元约束的活样板，而且是好消息——它证明你手里那一摊（StockHelp、小红书号、第二大脑、两条 agent 链路）在 AI 全采用下是一个人可管理的规模，不是妄念。把"10 倍差距来自全有或全无"这条直接套到你身上：你最大的漏不是哪个项目做得不够好，而是还有几成的活你在用旧办法手做（手写小红书选题、手翻盘点、手敲 StockHelp 脚本）。这周给自己做一次"AI 采用率体检"——把每个项目本周的活分成"已交给 agent / 还在手做"两栏，挑一项采用率最低的,逼它往 100% 推一步。
怎么做的：解锁这一切的底层是"代码很便宜（code is cheap）"——生成成本趋近于零后，你敢"拿有风险的点子去做原型，做比平时多得多的实验"，因为"'试一下'的启动成本（starting energy）低太多了"。Dan 的画面是：随口说一句"去给这个大重构做点调研",然后就去忙别的，回来时方案已经在手。 你可以怎么做：你最稀缺的从来不是想法，是敢不敢花精力去试——而"启动成本"正是精力这条元约束的咽喉。把"先做份完整方案/说服自己值不值"这道你惯有的前置关，换成"先让 agent 草一个能跑/能看的版本，再决定要不要投入"。具体到 StockHelp Phase 2 的信号逻辑、小红书的封面 A/B：别再纠结"这个值不值得做",直接丢给 agent 出原型,用能摸到的东西来判断,而不是用脑补。
🏭 Holdwell ERP（多-Agent PRD 工厂）
怎么做的：Every 给这套新编程方式起名 compounding engineering（复利式工程）,核心是一个 plan（规划）→ delegate（委派）→ assess（评估）→ codify（沉淀） 的四步循环,目标是"每做一个功能都让下一个功能更容易做"——和传统工程"每个功能都让下一个更难"正相反。Dan 说第四步 codify 是"那个最值钱的一步（the money step）":把规划、委派、评估里学到的一切"复利式地沉淀回 prompt",写进 Claude MD 文件、sub-agent、slash command,逐渐攒出一个"库",把工程师脑子里"只可意会的隐性知识（tacit knowledge)"变成"一套显式的 prompt 集合,可以铺给整个组织用"。 你可以怎么做：你的 PRD 工厂(三驾马车 + 六步碰撞协议)其实已经是 plan→delegate→assess 的形态,但你卡的恰恰是它的"复利性"——你担心的碰撞纪律是否真执行、真人评审意见回炉是否闭环,本质都是经验没有沉淀回系统、做完一轮下一轮没更省力。把 Dan 的"codify 是最值钱的一步"当成诊断:每跑完一个工单,问一句"这次评审/这次踩坑,有没有变成下一次自动生效的约束?"——如果没有,你做的还是传统工程(每个 PRD 让下一个更难),不是复利工程。这周挑一个最近真人评审里暴露过的漏点,把那次的教训写回对应 agent 的定义(
.Codex/agents/*.toml)或协议约束里,让它下次自动拦住,而不是靠人记得。怎么做的：Dan 把这套的本质讲成"在技术栈上往上挪一层"——编程"从 Python、JavaScript 往上挪到了'英文'这一层","你对 agent 说的话,就是新的源代码"。同时他诚实地泼冷水:assess(评估)那一步他列了"海量办法"——测试、亲自试用、code review、agent code review,各种招数堆上去才敢信 agent 的产出。 你可以怎么做：这正面回应你"跨线对齐"的痛——既然新源代码是英文,那六条产品线共认的那套"标准库"(实体定义、领域词典、状态机)就是你整条链路的地基,它对不齐,三个角色和六条线就各写各的方言。把它当成第一优先级捋,因为它是复利效应的本金。另外把 Dan 那句"评估要堆海量办法"接到你的碰撞环节上:三驾马车互看、各交三件(补强/修正/第 3 案)本身就是 agent 互审;他清单里的测试、亲自试用提示你还能在真人评审前再加一道机器可判的检查,正好帮"评审意见回炉"闭环。
🎨 app_incubator(7-Agent 造 App 链路)
怎么做的：Every 一个工程师就能扛起 Kora(AI 邮件助手)、Monologue(语音转文字)、Spiral 这种"一点也不简单、挺复杂、里面有很多东西"的生产级 app。Dan 点名这个"大变化"是"从 Claude Code 开始的"——"终端式 UI 把代码编辑器干掉了",把人真正推到"委派任务给 agent、并行干活"的状态;并强调确有工程师"真的在同时高效用着四个 agent 窗格"(不是 vibe coder 段子里那种开四个窗格其实没干活)。 你可以怎么做：你的 7-Agent 链路想达到的就是这个终局——单人/单链路产出一款完整 app。Dan 的样本帮你校准野心:这条路是真的(单个开发者维护复杂生产应用已被坐实),所以你"把'该做什么'前移到 agent"的方向没错,继续推。具体借一招:他的并行不是噱头,是"四个窗格各干一摊"的真并行——审视你链路里哪几步其实可以并行而你还在串行等(设计稿生成、组件实现、文案,未必要排队),让 agent 分窗格同时跑。
怎么做的：Dan"特别喜欢"的一个组织变化是从 memo culture 转向 demo culture(演示文化):以前一个想法要先"写 memo、做 deck、说服一帮人",现在"几小时 vibe code 出一个能跑的原型,直接展示给所有人看"。他说这能做出"更怪的东西"——那种"只有你能亲手感受到它的时候才会冒出来"的点子。 你可以怎么做：你 app_incubator 的痛点写着"激活/首屏体验"——而首屏体验恰恰是 Dan 说的"只有你能摸到它才判断得出来"的东西,光看设计稿和 PRD 判断不了。把"先评审再做"在激活环节倒过来:让 agent 先 vibe 出几版能点的首屏 demo,你用手指头点过去凭手感选,而不是在文档里论证哪版好。
🧭 Chief of Staff apps(决策外脑)
- 怎么做的：codify 那一步的灵魂是——把"只可意会的隐性知识"系统性地"收集起来,变成一套显式的、可复用、可铺给全组织的 prompt 集合"。Dan 强调这不只是省事,它催生的二阶效应里有一条是"新员工第一天就能产出":因为"怎么搭环境、一个好的 commit 长什么样"早就 codify 进文件,新人一来就继承全套。 你可以怎么做：你的 CoS 做的就是同一件事的"决策版"——把你 2021 年写下的产品价值观、五本书提炼的操作系统(判断力>努力、问该不该做先于做多快、每周留一天思考)这些你自己的隐性原则,固化成会在你眼前自动复现的显式提示。Dan 给了你一个质量标尺:好的 codify 让"新人首日产出"——对到 CoS,就是几个月后的你(忘了当初为什么定某条原则)能不能"首日产出"地直接用上。这周回看 CoS:有没有哪条你常踩的决策坑(比如又陷进"做多快"而忘了先问"该不该做"),还没被写成一条会主动弹给你的提示?把它补上,这就是你的 money step。
📚 Personal Thinking(这本第二大脑)
- 怎么做的：compounding engineering 的整套打法,本质是一套"让经验越用越省力"的摄入与沉淀纪律——做完一件事不止交付结果,还把过程"存"进系统。 你可以怎么做：你这本知识库的痛点是"摄入 SOP、信噪比"——而你正在用的 wiifm / video-to-text 技能链,本身就是 codify 的实践(把"读一期视频该问什么"固化成可复跑的 skill)。Dan 这一期是个正反馈:你的方向对了。可借的下一步是把"codify 是最值钱的一步"这条标准用回你自己的 SOP——每收一期内容,不止存档,问一句"这次提炼有没有让下一次提炼更省力"(模板更准了?闸门更利了?),让你的第二大脑也"复利"起来。
💰 顺带·对你的投资 / StockHelp
- 怎么做的：Every 是"15 人 / 100 万美元融资 / 4 款付费产品 / 双位数增长"的极致 capital-light 样本;Dan 还展示了"用 AI 大幅压低单位经济成本"如何让一门生意的人效曲线整个换挡。 你可以怎么做：你是价值投资者,这一期是一面镜子,提醒你重估"软件公司护城河"的口径:当 99% 代码 agent 写、单个开发者维护生产应用成为可能,过去"工程团队规模/人才壁垒"这类护城河正在贬值,而"分发、品牌、数据、网络效应"的权重在上升。下次你在 Futu 看一家 SaaS/软件标的,顺手问一句:它的护城河是不是正被'代码变便宜'侵蚀? 这是 StockHelp 选股逻辑里值得新增的一道审视——别再用"团队多强"给软件公司估高分。
更深三个角度
🔄 该反着用:Dan 的语境是一群全职工程师的公司——他能"把 Claude Code 指向旁边同事的 repo"学整个流程、能请专家"DJ 式插一天"、能让开发者跨产品互提 PR,全靠身边有人、有多条并行的 repo。你是单兵,这些"人与人之间"的二阶效应你大多用不上。对你正确的借鉴是把它反过来朝内做:你没有"旁边的同事",但你有"几个月前的自己留下的 repo 和笔记"——把"指向同事 repo 学流程"换成"让 agent 读你旧项目的做法、迁移到新项目";把"专家 DJ 插一天"换成"为某类一次性硬活,临时起一个专精 sub-agent 进来插一手"。
⚡ 和你现在做法冲突:Dan 说 Every"到现在都没被迫统一技术栈/语言,让每个人挑最顺手的,转译交给 AI"——这跟你做 Holdwell PRD 工厂时拼命想"统一标准、强流程"的本能是顶着来的。他的主张是:AI 把"统一"原本要解决的协作摩擦消解了,所以强行统一反而是多余的成本。这里有真张力,值得你停一下:你那套三驾马车 + 固定六步碰撞协议,有多少"统一"是真在降摩擦,有多少只是旧时代"为统一而统一"的惯性?——这个我不替你下结论,但 Dan 至少给了你一个"先别急着统一、让 agent 去转译"的反命题去验。
🪞 对你的镜子:Dan 那句"管理者甚至 CEO 也能提交代码,只要你懂技术",外加"AI 让你能在注意力被打碎(fractured attention)的状态下工作,不再需要一整块三四小时专注"——这话照见的正是你。你一直把"单兵多线、精力是元约束"当成限制;但他说的是,AI 恰恰让"零碎的会议间隙、被打断的注意力"第一次能变成有产出的时间。换个框定:你不是"精力不够所以只能做少",而是你这种碎片化的多线状态,在 AI 时代第一次成了一种可行的工作形态——前提是你真把活委派出去。
One Human Company 新号（2026-07 回填）
这一期简直是为你新立的「一人公司 build-in-public」号量身定做的——Dan Shipper 讲的 Every（15 人撑 6 业务 4 产品、99% 代码 AI 写、单人维护、总融资才 100 万美元）就是你 drizzle tech 想成为的样子，而他这场"来自未来的快讯"本身就是一次教科书级的 build-in-public。三条能直接落地。
1. "单个开发者能构建并维护一款复杂生产级产品"——你号北极星的最强证据，也是第一个 App 的复盘框架
- 怎么做的：Dan 反复坐实一件事：Every 每一款 app（Kora 邮件助手、Monologue 语音转文字、Spiral）"都是一个开发者单枪匹马做出来的"，"一点也不简单、挺复杂、里面有很多东西"；99% 代码没人手写，工具是"Claude Code、Codex、Droid，你喜欢哪个 coding agent 就用哪个"。整套是"极度省钱（capital-light）"——4 款付费产品、双位数增长，总共只融了约 100 万美元。
- 你可以怎么做：这条给你 A/C 类复盘一个现成参照系。候选标题：「Dan Shipper 说'单个开发者能扛一款复杂生产级 App'，我一个人 + drizzle tech 造第一个 App，进度和翻车都摊给你看」。你拿 drizzle tech 验的正是这句在"我这个 1 人 + 9+1 Agent"配置下成不成立——真实进度到哪、哪块被单人瓶颈卡住、烧了多少钱。这同时是你号最该反复讲的定位证据：一人公司不是行为艺术，是 Every 已经证过的可行规模。弹药库闸门稳过——全篇靠你的真实进度和账，删了就没了。
2. "codify 是最值钱的一步"——你 B 支柱（AI 员工管理）最独占的内容矿，可抄物现成
- 怎么做的：Every 把新编程方式命名为 compounding engineering（复利式工程），一个 plan→delegate→assess→codify 的四步循环，目标是"每做一个功能都让下一个功能更容易做"（传统工程正相反）。Dan 说第四步 codify 是"那个最值钱的一步（the money step）"：把规划、委派、评估里学到的一切"复利式地沉淀回 prompt"，写进 Claude MD 文件、sub-agent、slash command，逐渐攒出一个"库"，把工程师脑子里"只可意会的隐性知识"变成"一套显式的、可铺给全组织的 prompt 集合"。
- 你可以怎么做：这是 B 支柱（AI 员工的岗位说明书/绩效/返工）最独占的一篇。候选标题：「大佬说给 AI 员工'沉淀经验'是最值钱的一步，我把 drizzle tech 一次返工写成了永久生效的岗位说明书」。你拿 drizzle tech 验的是：某个 Agent 这次踩的坑/你这次的修法，有没有被 codify 成下次自动生效的 prompt/skill——没有，你做的就是"每个 App 让下一个更难"的传统工程。可抄物直接放你 codify 出来的那条 skill/slash command 或"岗位说明书模板"。诚实反驳留一句：codify 也有成本，哪些经验值得沉淀、哪些是一次性的别硬存。
3. Every = ideas/apps/training 打包一份订阅——你 build-in-public 一人公司的商业化镜子
- 怎么做的：Dan 把 Every 定位成"你站在 AI 最前沿唯一需要的一份订阅"，做三件事打包卖：ideas（一份 AI 日报 + 新模型评测）、apps（Kora/Monologue/Spiral 等产品）、training（给大公司做 AI 培训咨询）——关键商业设计是"这一切全部打包进一份订阅，一个价格拿到全部"。而他这场演讲本身——不端"我手握答案"的架子、只带回"前线明信片"——就是 build-in-public 的姿态。
- 你可以怎么做：这条价值在办号而非选题。Every 就是"内容（判断/日报）+ 产品（App）+ 培训"三合一的一人公司变现范本，正好对上你"小红书吃判断、Twitter 吃管线、底牌是 drizzle tech 造 App"的三条腿。把它当你号的中长期镜子：你现在 Phase 0 攒存稿只是"ideas"这条腿，Every 提醒你另外两条腿（apps 的真实产品、training/咨询）迟早要接上，而"一份订阅打包"是把它们缝成一门生意的方式。近处能做的：学 Dan 那种"来自未来的快讯"姿态——build-in-public 的可信度来自"我先走一步、把看到的诚实带回来"，而不是"我来教你"，这正好焊死你号"不做保姆级教程"的红线。
所以呢
可迁移思维模型:
- 【耐用】复利工程 = 每做一件事都让下一件更省力。这是金融"利滚利"搬到工作上的硬模型,跟具体工具无关——judge 你任何一个项目是否健康,就看"做完这一轮,下一轮是更省力还是更费力"。会一直成立。
- 【耐用】100% vs 90% 的 10 倍差距(全有或全无的临界):很多收益不是线性累加,而是"差最后一口气就被旧范式拽回去"。适用范围远超 AI——任何你"做了一半的自动化/纪律"都可能因为那 10% 没做透而拿不到 10 倍。
- 【会过期】"99% 代码 agent 写、单人维护生产 app"这些具体数字与"Claude Code 干掉编辑器"的工具形态:是 2025 年这个时点的"未来快讯",模型/工具半年就会迭代,别把数字当常量,当方向看。
判断更新:你原本可能觉得"一人多线 = 注意力不够 = 只能浅做"。这一期该把它更新成:碎片化注意力在 AI 时代不是缺陷,是新工作形态;真正的瓶颈从"专注时长"转移到了"你有没有把活真委派出去 + 有没有把经验 codify 成会复利的资产"。
这周一个赌注:给你采用率最低的一个项目(很可能是 StockHelp 的手敲脚本,或小红书的手做选题/盘点)做一次 codify——把你这周手做的某一类活,固化成一条会自动复用的 prompt / skill / slash command,让下一次它自己跑。一周后只问一个问题:下一次做这件事,是不是真的更省力了? 这就是 Dan 说的 money step,小处先验它一次。