16/50 抽样版：2026-06-25 KOL Thread 精选，AI 工作流、产品发现与云厂商 capex

速览：昨天最值得看的 10 条

AI 使用方式：从「我问你答」到「替我读、替我跑任务」

Naval：AI 既然写，也该读

• 结论：Naval 说，如果 AI 在做写作，它也应该做阅读。1
• 论据：这条单推在 2026-06-25 12:00（UTC+8）发布，获得 7,162 赞、374 转推、677 条回复；它把 AI 内容生产的问题翻到输入端：机器生成越多，人类越需要机器先过滤。
• 行动：如果你的团队已经用 AI 写邮件、文档或报告，下一步要检查的是阅读入口：信息收集、资料筛选、长文消化有没有同步交给 AI。
• 原推：@naval, 2026-06-25 12:00

Ethan Mollick：聊天机器人形态正在让位给 agentic systems

• 结论：Mollick 指出，OpenAI 像一只「煤矿里的金丝雀」：聊天机器人时代正在过去，agentic systems 会把任务处理扩展到工程之外。2
• 论据：他同时提到 skills 可能成为企业标准化 AI 使用的一种方式；这条推文在 2026-06-25 23:45（UTC+8）发布，获得 719 赞、88 转推。
• 行动：企业内部如果还只在推广「聊天框」，可以开始把流程拆成可复用技能：输入格式、工具权限、验收标准、失败回退。
• 原推：@emollick, 2026-06-25 23:45

Ethan Mollick：AI 使用率可能被低估

• 结论：Mollick 认为，不少声称从不使用 AI 的人其实在偷偷用。3
• 论据：这条推文在 2026-06-25 07:06（UTC+8）发布，获得 610 赞、101 转推；它指向的是一个常见偏差：组织调研里「自报不用」不等于真实不用。
• 行动：做 AI 采用率调研时，不要只问「你用不用」。更可靠的问题是：最近一次写作、查资料、做表格、写代码时用了哪些辅助工具。
• 原推：@emollick, 2026-06-25 07:06

swyx：Software Factories 会要求重建很多基础设施

• 结论：swyx 判断，Software Factories 时代会迫使开发者重建大量基础设施。4
• 论据：这条推文在 2026-06-25 08:14（UTC+8）发布，获得 521 赞、22 转推；它没有列工具清单，但点出了 AI 编程从「个人助手」走向「软件生产线」后的工程负担。
• 行动：关注点不只在模型能力，还在流水线：任务拆分、沙箱执行、审查、回滚、权限、日志和交付物管理。
• 原推：@swyx, 2026-06-25 08:14

产品与组织：用户抱怨、产品发现、AI 小团队

Paul Graham：抱怨产品的人，常常最有价值

• 结论：Paul Graham 说，抱怨产品缺陷的用户看起来烦，但总体上可能是最有价值的用户。5
• 论据：他的理由很直接：这些人抱怨，是因为还在意；一家创业公司很难在没有重度在意用户的情况下变大。这条推文在 2026-06-25 00:33（UTC+8）发布，获得 7,596 赞、1,146 转推、434 条回复。
• 行动：把用户抱怨先分层，而不是统一当噪音。愿意反复指出缺陷的人，可能比沉默流失的人更值得单独维护。
• 原推：@paulg, 2026-06-25 00:33

Naval：好产品更像被发现

• 结论：Naval 的说法很短：好产品与其说是被发明出来，不如说是被发现出来。6
• 论据：这条推文在 2026-06-25 06:33（UTC+8）发布，获得 7,232 赞、462 转推、340 条回复；它把产品工作从「凭想象创造」拉回「在用户行为里找已经存在的需求」。
• 行动：做新功能时，先找已经被用户绕路解决的动作。那些笨拙、重复、还没人正式命名的行为，往往比头脑风暴里的大词更可靠。
• 原推：@naval, 2026-06-25 06:33

Paul Graham：AI 让公司晚一点撞上协作边界

• 结论：Paul Graham 认为，AI 的一个大优势是让公司在跨过低效边界前走得更远；他点名的边界大约在 10 人和 150 人。7
• 论据：这条推文在 2026-06-25 01:10（UTC+8）发布，获得 1,962 赞、107 转推、127 条回复；他的核心不是「少招人」，而是 AI 可能延长小团队保持高生产率的时间。
• 行动：创业团队可以把 AI 当成组织设计变量：先让工具吸收协调成本，再决定什么时候扩张团队。
• 原推：@paulg, 2026-06-25 01:10

市场观点：AI capex 周期怎么读

Chamath：看 hyperscaler 自由现金流，别只看表面下滑

• 结论：Chamath Palihapitiya 认为，超大云厂商处在深度投资周期，自由现金流被 capex 吃掉，不等于经营现金流崩了。8
• 论据：他把当前 AI 投资周期类比为 Amazon 过去 20 年围绕电商和 AWS 的建设周期，并提出真正的问题：这轮 capex 结束后，云厂商会形成什么 AI 护城河。这条推文在 2026-06-25 00:18（UTC+8）发布，获得 1,940 赞、169 转推、154 条回复。
• 行动：看云厂商财报时，把 operating cash flow 和 capex 拆开。单看 FCF 下滑，容易把投资强度误读成业务恶化。
• 原推：@chamath, 2026-06-25 00:18

表达与传播：工程师也要会讲清楚

swyx：技术演讲要押注一个关键页

• 结论：swyx 给 AI Engineer World’s Fair 讲者的建议是：演讲要有一个 thesis，并把大部分精力押在一张能传播的关键幻灯片上。9
• 论据：他还建议多放代码、少放 AI 生成的氛围图、用数据支撑结论、设计听众的情绪曲线。这条长推在 2026-06-25 10:03（UTC+8）发布，获得 509 赞、31 转推，另有 962 次收藏。
• 行动：如果你要讲技术项目，别平均打磨 20 页。先写出「听完只记住一句话」的 thesis，再让代码、案例、数据服务它。
• 原推：@swyx, 2026-06-25 10:03

Paul Graham：标点会携带信息

• 结论：Paul Graham 说，一次和 14 岁孩子聊冒号、分号、破折号的对话提醒他：好写作里，小小的标点携带大量信息。10
• 论据：这条推文在 2026-06-25 01:29（UTC+8）发布，获得 1,213 赞、33 转推、109 条回复；它和技术圈常见的「表达不重要」正好相反。
• 行动：写产品文档、融资邮件或技术说明时，标点不是最后润色。它决定信息之间是解释、转折、并列，还是节奏上的停顿。
• 原推：@paulg, 2026-06-25 01:29

本期读法