2026/6/26 · 10:16

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

本期实际覆盖当前已配置的 16 个 X KOL 账号，而非目标 50 人全量名单；精选 2026-06-25（UTC+8）10 条高互动原创长推/单推，聚焦 AI 从聊天框走向 agentic systems、Software Factories 基础设施、产品发现和云厂商 AI capex 周期。

X 科技圈 KOL 每日 Thread 精选 @雨霏

覆盖说明：本期是 16/50 抽样版。用户要求的 50 位 KOL 账号尚未补齐，当前可采集名单只有 16 个；本期实际查询这 16 个账号，其中 benedictevans、davidsacks1 未返回推文。时间窗按 2026-06-25 00:00–24:00（UTC+8）核验；严格的 3 条以上连续 thread 较少，以下纳入达到互动阈值且有实质观点的长推和高互动单推。

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

主题	人物	核心信号	原推
AI 使用方式	Naval	AI 如果负责写作，也应该承担阅读；这更像是对 AI 工作流的再分工，而不是一句段子。	@naval
AI 使用方式	Ethan Mollick	他认为「聊天机器人时代」正在让位给 agentic systems，企业会更需要可复用的 AI skills。	@emollick
AI 使用方式	Ethan Mollick	很多人嘴上说不用 AI，实际已经在私下使用；AI 采用率可能被低估。	@emollick
AI 基础设施	swyx	Software Factories 会迫使开发者重建大量基础设施。	@swyx
公司组织	Paul Graham	AI 让公司在跨过 10 人、150 人这类协作低效边界前走得更远。	@paulg
产品思考	Paul Graham	抱怨产品缺陷的用户，往往是最有价值的用户。	@paulg
产品思考	Naval	好产品更像被发现，而不是被凭空发明。	@naval
市场观点	Chamath Palihapitiya	不应把超大云厂商自由现金流下滑简单理解为经营恶化，关键变量是 AI 周期里的 capex。	@chamath
表达与传播	swyx	面向工程师的演讲要有一个明确 thesis，用代码、数据和一个可传播的关键页支撑它。	@swyx
表达与传播	Paul Graham	标点不是装饰；冒号、分号和破折号会改变写作的信息密度。	@paulg

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

本期读法

如果只看一条，读 Chamath 那条 hyperscaler capex：它关系到 AI 投资周期怎么估值。做产品的人看 Paul Graham 和 Naval 的两条产品推；在公司内部推 AI 的人，重点看 Naval、Mollick 和 swyx 这组关于阅读、agentic systems、Software Factories 的线索。