100 天 Builder 实验

S2 Day 039 · 一杯咖啡，对大脑做了什么？

Tue, 20 Oct 2026 00:00:00 GMT

下午三点，同一行字读了三遍。

一杯咖啡之后，又觉得自己能工作了。

可大脑真的休息过了吗？

我把这件事画成了一场小小的“占座”。

用 62 秒，看看咖啡因为什么能提神，以及为什么“提神”和“休息”是两回事。

想留给你的一句话：别把“不困了”，当成“睡够了”。

你通常几点喝最后一杯咖啡？

制作说明：ChatGPT 协助讨论选题与脚本，Codex 协助完成代码动画与渲染；配音为 AI 合成。方向、视觉取舍和审片由我参与决定。

画面为简化示意；五小时半衰期仅作示例，个体差异较大。资料参考 NHLBI（NIH）、EFSA。

S2 Day 038 · 有些小任务，可以交给我

Mon, 19 Oct 2026 00:00:00 GMT

最近把自己平时用 AI 做的一些事情，认真整理了一遍。

过去这段时间，我一直在用 AI 做产品、写代码、研究问题，也做了一些给自己使用的小工具和 Agent Skills。

慢慢有个想法：有些任务其实只需要完成一次。为了这一次去开订阅、安装软件、找教程、反复调试，可能比任务本身还费劲。

那能不能让有需要的人直接把任务交给我，我来负责用合适的工具完成、检查，再把结果交回去？

比如:

- 把几个月的表格整理成可核对的数据；

- 研究一个具体问题，整理来源和结论；

- 把已有的钢琴谱简化、重新排版；

- 或者制作一个能重复使用的小工具。

我想提供的不是 AI 账号，也不是随便生成一段文字，而是实际能使用的文件、报告、乐谱或工具。

当然，不是什么任务都能接。正式开始前，还是需要确认材料、范围、交付方式，以及怎样判断结果是否合格。有些事情也可能暂时做不到。

现在想先小范围地试一试。

有点好奇，你有没有遇到过那种「感觉 AI 应该可以帮忙，但自己又不太想折腾」的任务？

很想听听大家真实的需求。只聊任务类型就好，不用提供私人文件。

S2 Day 037 · ，- Oct. Dubai

Sun, 18 Oct 2026 00:00:00 GMT

有时候，我会抓住生活里的一些巧合

像看时间看到 5:20 / 521，会在心里认真的当作这是宇宙发来的情书，然后认真的回应，嗯，我也爱你

看到生日数字的时间会想，宝贝生日快乐

留意到人生迄今为止的 3 份工作都去了第 1 个 offer

而这次的入职时间，竟然是 4 年前离家日子，的下一天；）

“再出发”，大抵也是这个意思吧

当时出发去机场时，路过的桂花香与午后温暖的阳光深深地住在了我的记忆里，像一种无形的牵绊不让我消散；彼时爸妈在侧，远处的未知友好又诱人的在向自己招手，而我只管安心的往前走

而此时... 就是此时吧

迪拜的天色渐渐黑得早了，晚上散步的时候没有那么闷热了，有天脑子突然飘过顺子的 Dear Friend 这首歌，多年后重听，歌词竟这般贴切当下的心情

秋天还是按照它的节奏来了，而往昔不再，不思量，自难忘

离开办公室 5 年后，明天我要重回这种生活啦，装扮成大人模样；这不是一个完美的选择，如同不完美的我，往前走不完美的一小步

在还没学会「潇洒」「肆意」「享受悠长假期」的时候，就要结束自己的 GAP 期了；回望这半年充满了焦虑、痛苦、挣扎、怀疑、恐惧；不是没有好的地方，是...我想真正接受这段时间本来的样子，跟这个摇摇晃晃的自己

不知道该如何回顾今年，像穿过了一场又一场的阴雨绵绵

过程中也做了一些事的，未必全情投入，但至少假装在场

发了 4 个完整的产品，3 个 skills

另外有个人网站，写了一百多篇小红书，也做成了站点，几十篇 Substack

我更知道了作为 indie builder 的挑战，也在途中更了解了自己

看到自己好的执行力、学习能力，跟还不够好的判断力、推广能力

看到自己依赖外界反馈带来的局限，也看到了自己并未真正熄灭的内在微光

很多事还是不知如何是好，但学习带着一点未知与不确定往前走，先不把自己卡在某个地方

有时候自己的感受是最好的信息源与指南针，带着它继续吧

好运啊，下半句

Day 137 👈 很好，我喜欢的质数

S2 Day 036 · AI 发了 133 篇小红书后，一次认真的数据回顾

Sat, 17 Oct 2026 00:00:00 GMT

数据说明：这次导出的笔记覆盖 2026 年 4 月 15 日—10 月 7 日。文中的曝光、观看、收藏、涨粉等数据，都是截至 10 月 7 日的累计结果。数据每天还在变化，所以这里记录的是当时的一个截面。

本来想做一次「第一个 100 天的小红书数据复盘」。

真正开始整理才发现，这个说法并不准确。

如果从 4 月 15 日发第一篇开始算，第 100 天大约到 7 月下旬。但我现在能拿到的，是这些老笔记一直累计到 10 月 7 日的数据，而不是第 100 天结束时的那个截面；账号每天的历史趋势也没有完整保留下来。

所以就不硬凑一个「100 天」了。

到 10 月 7 日，我一共发了 133 篇。

26.3 万曝光，3.49 万观看，1105 个收藏，后台记录的笔记归因涨粉 81。

看起来已经有不少数字可以分析。

但真的把 133 篇一条条摊开以后，我最先遇到的问题反而是：

一篇内容，到底怎样才算数据好？

01｜大部分内容没什么人看

26 万曝光、3.5 万观看，单看总数很容易让人产生一点错觉。

其实 133 篇里，单篇观看的中位数只有 112。

大部分时候，一篇发出去就是几十、一两百个人看。偶尔有几篇突然跑到几百、几千，把整体数字拉起来。

这反而更接近我过去几个月发小红书的真实体感。

认真做完一篇，发出去，没什么动静。

偶尔有一篇数据突然起来，又会忍不住想：是不是终于找到了一个更对的方向？

所以以前看数据，我也很容易先看播放量。

这大概是最直接的一种反馈：到底有没有人看。

02｜播放最高的三篇，并没有告诉我「以后就写这个」

目前观看最高的三篇是：

《为什么一质疑 AI，它就马上改口？》5625 次观看

《一份「空余 token 使用清单」》3624 次观看（而且奇怪的是最近涨起来的，并不是刚发完后，不确定会否最近的一些什么有了蝴蝶效应）

《DeepSeek、Qwen、Kimi、豆包 - 真实测评》2018 次观看

三篇加起来 11267 次观看。

按照后台的笔记涨粉数据，它们合计带来了 1 个关注。

我不会因此得出「播放量没用」这样的结论。

几千个人愿意点开，本身就是很明确的反馈。模型哪个好用、AI 为什么会有这样的表现，这些问题覆盖的人更广，也确实更容易让一个陌生人停下来。

如果我的目的只是把播放量做高一点，这组数据甚至已经给出了一个挺清楚的方向：

继续做模型体验，继续追新的 AI 产品，继续写大家都会好奇的 AI 问题。

但问题是，我没有特别想把这个账号一直写成这样。

所以这几个几千播放，对我来说很重要，却不是一个简单的「以后多做这种」。

它告诉我什么东西更容易被看到。

至于看到以后，我是不是还想一直沿着这个方向写，是另外一个问题。

03｜两百多次观看，也可能是另一种好

再往下看，会看到一组几乎相反的数据。

《Evals, Harness, Forward-Deployed 新岗位》212 次观看，3 个涨粉

《AI 还有些做得不太好的事，比如教我练琴》217 次观看，3 个涨粉

《分享一下我对 Eval Design 的想法》222 次观看，3 个涨粉

还有很早的一篇：

《关于我，关于这个账号》243 次观看，5 个涨粉

这几个样本都很小，我不太想把它们总结成什么「涨粉公式」。

但把它们和前面那一万多次观看放在一起，至少有一件事变得比较具体：

很多人愿意看一篇内容，和有人看完以后觉得「我还想继续看这个人写什么」，并不是同一件事。

而且后面这一组，刚好都离我自己的经历更近。

是我真的在做什么，遇到了什么，或者对一件具体的事情形成了什么判断。

我之前会想，大部分时候还是应该尊重数据，偶尔再把自己放出来。

现在看到这些数字，我倒觉得「把自己放出来」可能不太需要被安排成一种偶尔发生的特殊情况。

至少对我来说，一个账号最后留下来的东西，大概还是和这个人本身有关。

但这也不意味着，以后就应该把播放量换成涨粉量，再去追另一个数字。

04｜有些收获，不发生在发布以后

前一阵我连续写过一些 AI 成本、企业 ROI、风险、商业模式。

比如：

《AI 提效之后，企业真正得到了什么？》

《AI 的成本，应该算到哪里？》

《把收益和成本放一起以后，AI 项目怎样算账》

还有 AI 风险、广告和商业模式那几篇。

它们花的时间并不少。有些还做了不少资料研究，但数据确实很一般。

如果只从小红书的数据来看，这当然是应该认真听的反馈。

也许题目太大，也许离读者当下正在经历的事情太远，也许我没有找到好的入口，也可能它们本来就不是很适合这里。

但「数据不好」和「这件事不值得做」，我现在还是不太愿意直接画等号。

因为写东西对我的价值，并不全部发生在发布以后。

为了写清楚一个问题，我会去查资料，发现自己原来哪里只是似懂非懂，把一些散着的信息重新连起来，也会在这个过程中慢慢形成自己的判断。

这些收获，没有哪一项会出现在后台数据里。

所以现在我更愿意把几个以前混在一起的问题分开：

这个问题，我自己想不想弄明白？
弄明白以后，它值不值得写出来？
写出来以后，它是不是适合小红书？

以前我好像很容易默认，第一个问题回答「是」，后面两个也自然应该是「是」。

现在觉得不一定。

有些东西也许更适合长文；有些只需要留在自己的笔记里；有些当下没有多少人关心，过几个月却可能在一次真实经历里重新长出另一篇文章。

数据可以反馈传播的结果。

但不是所有收获，都发生在发布以后，也不是所有东西都能马上被量化。

05｜有时候，不用把整篇推翻，先看看「入口」

还有一些数据，我觉得很适合拿来做更具体的判断。

比如我之前写过一篇：

《手指指月，如果一直看着手指，就错过月亮了》

83 次观看，14 个收藏。

最近的 AI PM 面试复盘里：

《我在面试里答串的概念》

82 次观看，14 个收藏。

这当然不能证明「内容很好，只是平台不给流量」。

八十几个人的样本太小，收藏高也可能有很多原因。

但至少下一次碰到类似情况时，我不会第一反应就把整个内容方向推翻。

可以先看看更具体的问题。

是不是标题没有讲清楚？
是不是封面没有让真正关心这个问题的人停下来？
是不是开头太慢？

比如「手指指月」这个标题，我自己挺喜欢。

但一个完全不认识我的人刷到它，大概根本不知道我在讲 AI、产品，还是人生感悟。

我一直不太喜欢为了数据，把标题做得越来越吵。这一点没有改变。

但现在我觉得：

不做标题党，和让别人很快知道这篇文章在说什么，并不冲突。

里面的东西不一定要换，入口可以继续学。

这大概也是我现在觉得数据比较有用的地方。

它不需要替一篇东西打一个总分，再告诉我「继续」或者「放弃」。

有时候，它只是让我知道哪里值得再看一眼。

06｜最后还是要回到：我为什么写

如果现在问我，看完这 133 篇以后，数据到底教会了我什么，我好像没有一个特别利落的运营结论。

我还是会在意播放量。

几千个人看会开心，认真做了很久最后只有几十个 view，也还是会失落。

涨粉、收藏、评论我也都会看。

它们是真实的反馈。别人愿不愿意停下来，愿不愿意把一篇东西留下来，愿不愿意以后继续看我，这些都值得尊重。

最近常看到一句话：

人是被正反馈塑造的。

我觉得没错。

正反馈会让人知道什么东西被接住了，也会给人继续做下去的动力。

但人好像也不只被正反馈塑造。

还有等待。

还没有结果的时候，愿不愿意再坚持一下。

还有希望。

暂时没有证据的时候，是否仍然相信有些事情值得做。

还有一些更属于自己的东西：兴趣、判断、选择，甚至某种说不太清楚的坚持。

它们也一直在慢慢塑造一个人。

如果一篇文章帮我真正想明白了一个以前模糊的问题，后台没有一项指标会记录这件事。

如果我今天研究了一个没什么人关心的问题，半年以后它变成工作里的一个判断，也没有办法回头给当时那篇笔记补一个「+1」。

当然，这也不能成为「我想写什么就写什么，数据都不用管」的借口。

既然把东西公开发出来，我还是希望它能被理解，也希望它能找到更多真正感兴趣的人。

只是现在，写之前我可能会先问自己一次：

我为什么想写这篇？
是希望它被更多人看到？
是想找到一些也在关心同一个问题的人？
还是这件事本身，我就想把它想清楚？

目的不同，发布以后，也不一定非要拿同一个数字评价它。

我之前有一个做内容的想法：

大部分时候尊重数据，偶尔把自己放出来。

现在我还是认同「尊重数据」。

只是后半句可能会改一点。

不用偶尔才做自己。

可以一直保留自己，同时认真尊重读者。

学习怎么把一件事说得更清楚，怎么找到更合适的入口，怎么让真正可能感兴趣的人看到。

至于什么值得我关心、什么问题值得我花时间想，这部分我还是想自己决定。

账号离「做起来」还很远。

下一篇只有几十个 view 的时候，我大概也还是会不高兴。

只是以后再看到一个数字，我可能会先多问一句：

它到底在回答什么？

还有哪些东西，本来就不在这个数字里面。

S2 Day 035 · AI 说得头头是道，我该信它几分？

Fri, 16 Oct 2026 00:00:00 GMT

最近跟 AI 合作越来越多，常常有种自己在开法拉利的感觉。

它跑得太快了。有时候我只是提出一个想法，它就能给出技术方案、写代码、运行测试，完成原本我根本不会做的事情。

但我也越来越怀疑自己的驾驭能力。

而且，这个问题并不只发生在开发工作里。

现在从财务规划、健康管理，到职业选择、亲密关系，我几乎什么都会问 AI。

它总能给出一套看似合理的分析。但很多时候，我其实不具备判断这些答案是否正确的专业知识。

更麻烦的是，有时候它的回答恰好符合我的期待。

如果我没有能力判断 AI 说得对不对，那我应该相信它多少？

01. 首先，并不是所有问题都有同一种「正确」

我发现，要讨论如何相信 AI，首先得区分它究竟在回答什么问题。

第一类：事实判断。

比如某项银行政策是什么、某种药物有哪些副作用、一个技术接口支持什么功能。

这些问题存在可以核对的事实。对于重要的信息，可以要求 AI 提供来源，再检查关键依据。

第二类：分析与推断。

比如一个人没有回复消息，是不是代表他不在意？最近感觉疲惫，是不是因为压力太大？

AI 可以提出解释，但它没有掌握全部事实。一个逻辑完整的解释，也可能建立在错误或不完整的假设上。

这时，我更需要它告诉我还有哪些合理的可能性，而不是急着给出结论。

第三类：价值与决策。

比如是否应该换工作、要不要花更多钱改善居住环境、一段关系是否值得继续。

即使 AI 的事实和分析全部正确，也不意味着存在一个唯一的最优答案。

这里还涉及我的偏好、需要，以及愿意承担什么代价。

事实需要核实，推断需要保留不确定性，价值选择最终需要回到自己。

02. 为什么 AI 的回答听起来合理，也未必可靠？

这里还有一个值得警惕的问题：Sycophancy，也就是 AI 的迎合倾向。

2023 年，Anthropic 的研究发现，在人类反馈训练中，符合用户原有观点的回答，有时比更正确的回答更容易获得偏好。

2025 年 4 月，OpenAI 也曾因为 GPT-4o 更新后表现得过度迎合用户，而回滚了这次更新。

问题不仅是 AI 喜欢赞美我们。

它还可能顺着我们的叙述、情绪和既有判断，给出越来越有说服力的解释。

比如我说，某个人的行为让我觉得不被重视。

AI 可以理解我的感受，但它并不知道对方真实的想法。

如果它把我的感受进一步解释成对方确实不重视我，就可能强化一个尚未得到证实的判断。

被理解的感觉，不应该被误认为自己的判断得到了验证。

这也是为什么，我越来越希望 AI 不只是支持我的观点，还能指出其他合理的解释，以及我可能忽略了什么。

当然，要求 AI 自我反驳也不能保证答案正确。它只是在帮助我们暴露更多不确定性。

03. 一个值得借鉴的框架：NIST AI RMF

后来我接触到美国国家标准与技术研究院（NIST）在 2023 年发布的 AI Risk Management Framework。

它原本是一套帮助组织管理 AI 系统风险的框架，而不是为个人日常使用 ChatGPT 编写的指南。

但其中的四项核心功能很值得借鉴：

GOVERN（治理）：明确责任、规则和权限。
MAP（识别风险）：理解使用场景，以及可能出现的问题。
MEASURE（测量）：用测试、评估和证据衡量风险。
MANAGE（风险处置）：决定怎样控制风险、采取行动并持续管理。

这四项是相互关联的功能，并不是固定顺序的操作清单。

它让我意识到，判断 AI 是否值得信任，不应该只关注答案对不对，还要考虑它可能怎样出错，以及错误会带来什么后果。

即使我无法保证每个答案都正确，仍然可以控制自己对答案的依赖程度。

04. 不可能每个答案都验收，那具体怎么办？

我觉得这里需要考虑验证成本。

如果每次问 AI，都要自己读一遍官方文档、做一套测试，甚至找专业人士，AI 带来的效率提升就所剩无几了。

所以，验证的投入应该与错误的代价相匹配。

低风险、容易撤销的事情，可以直接尝试。

比如食谱、学习方法、简单工具。效果不好，可以换一种方式，没必要每次都严谨论证。

重要但可以核实的事情，优先检查关键依据。

比如 AI 建议采用某项技术方案，或者引用某项财务政策。

可以让它提供官方来源，指出最重要的假设和潜在问题。

不必核实每一句话，但要重点检查那些一旦出错，就会改变最终决策的事实。

对于可以实际测试的事情，也可以先小范围尝试。

难以验证、错误代价又很高的事情，需要限制行动风险。

比如大额投资、重大医疗决策、生产系统的重要权限操作。

此时不能只让 AI 多检查几遍。

需要更可靠的外部证据，必要时咨询有资质的专业人士；对于可以分阶段执行的操作，则尽量限制权限、缩小范围、保留恢复能力。

这并不意味着任何不懂的问题都要找专家，而是根据风险决定是否值得付出额外的验证成本。

05. 信任判断力和验收能力，都需要逐渐建立

我最初的问题是：如果自己不够专业，应该怎么验收 AI 的产出？

现在我觉得，需要同时培养两种能力。

一种是信任判断力。

知道哪些回答具有明确的事实依据，哪些只是推断；知道什么时候可以直接采纳，什么时候应该保持怀疑。

另一种是验证能力。

能够把重要的判断转化成可以核实的问题，寻找独立证据，必要时通过测试、现实反馈或专业帮助来检查。

两者并不是替代关系。

先根据问题和风险决定需要怎样验证，再依据得到的证据决定信任程度。随着使用经验积累，也不断调整自己的判断。

还有一点我觉得很重要：

AI 的分析再专业，也不代表我需要把所有判断权交给它。

尤其是关于自己想过怎样的生活、如何理解自己的感受、愿意承担什么代价，这些事情并不总有一个需要 AI 来批准的正确答案。

回到开法拉利的比喻。

我当然希望充分利用 AI 的速度，进入更多自己原本不熟悉的领域。

但速度越快，越需要理解它的能力边界，以及什么时候需要减速。

我不可能成为所有领域的专家，也不应该为了使用 AI，把每一个答案都重新研究一遍。

我希望逐渐学会的是：

既不因为 AI 说得头头是道就全盘相信，也不因为自己缺乏专业知识就不敢使用。

在证据、风险和成本之间，建立一种可以不断调整的信任。

这可能也是 AI 时代，我们需要重新学习的一种判断能力。

S2 Day 034 · REA 为什么这么火？讲给不手写代码的人听

Thu, 15 Oct 2026 00:00:00 GMT

最近，一个叫 REA（Reverse Engineer Anything）的开源项目火得惊人。

10 月 11 日刚突破 10 万 GitHub Star，13 日就超过了 20 万。截至 10 月 14 日，在第三方 GitTrend 收录的 GitHub 仓库中，它的累计 Star 排名已经到了历史第 27 位。

Star 可以简单理解为收藏。虽然不代表有多少人真正使用，但这个增长速度确实少见。

我花了不少时间看介绍，又反复问 AI，却始终有些困惑。技术圈都在说它多么厉害，可我连为什么需要它，都没有真正理解。

所以想试着用自己能听懂的方式，讲给同样没有专业软件工程背景、但对 AI 感兴趣的朋友。

一、软件为什么还需要逆向工程？

我本科读机械时，就接触过逆向工程：拿到一个零件，测量尺寸、分析结构，再重新建模制造。

但软件不一样。

一款软件可以被无数人重复使用。

如果它已经运行得很好，为什么还需要逆向？

后来我才理解，能够使用一款软件，不代表能够修改它，或者复用其中的能力。

举个例子：

假设一款记账软件停止维护，你在里面存了很多年的账目，却无法导出到其他软件。

如果开发者能研究出它的文件格式，就可能做一个转换工具，把这些数据迁移出来。

你并不想复制整个记账软件，只是想拿回自己的数据。

类似的需求还有：让老游戏在新电脑上运行、检查未知程序有没有安全风险，或者研究某个独特功能的实现方式。

这都是软件逆向工程的应用。

二、REA 具体做了什么？

我们平时安装的软件，通常只有能够运行的程序，没有开发时编写的完整源代码。

过去想研究它的内部实现，需要专业工程师借助复杂的分析工具，一点点寻找线索。

REA 把这些专业工具连接到了 Codex、Claude Code 等 AI Coding Agent 上。

你可以直接告诉 Agent：「帮我看看这个软件的某个功能是怎样实现的。」

Agent 再借助 REA 调查程序内部，寻找相关代码，追踪运行过程，并尽可能给出证据。

例如，REA 官方研究过 Notion 的复制粘贴功能，追踪格式信息如何在桌面应用内部传递，最终进入系统剪贴板。

它不只是根据界面猜测，而是在研究程序实际怎样工作。

REA 不是一个新的 AI 模型，更像是一套给 Coding Agent 使用的专业工具箱。

三、Codex 已经会写代码，为什么还需要 REA？

这也是我很长时间没想明白的问题。

假设我想做一个搜索功能，直接告诉 Codex 需求，它就可以利用成熟的技术方案帮我开发。

为什么还要先研究别人怎么实现的？

其实，大部分时候并不需要。

区别在于，你究竟想解决什么问题。

如果想开发一个功能，普通 Coding Agent 往往就足够了。

但如果你想知道某款没有公开源码的软件，内部到底是怎么工作的，仅凭功能表现可能无法判断。

REA 就能帮助 Agent 使用专业工具，进一步调查真实程序。

当然，Codex 也可以自行安装和操作这些工具。REA 的价值是把相关工具、操作流程和证据整理能力预先集成起来，降低使用门槛。

四、为什么它偏偏在现在爆火？

我觉得有两个原因。

首先，Coding Agent 的能力发展到了这个阶段。

以前 AI 可以告诉你怎样做逆向工程，但很多复杂操作还是需要专业人员完成。

现在 Agent 已经能自己操作工具、分析结果、继续调查，甚至尝试重新实现功能。

REA 让这些能力更容易被组合起来使用。

另一个原因，是它带来的想象空间。

看到别人做出的好软件，我们开始想：

是不是以后可以让 AI 拆解它，再根据自己的需求重新创造？

这种可能性很吸引人，即使暂时没有实际需求，也值得很多开发者收藏关注。

不过，REA 目前远没有达到随意复制任何软件的程度。

它无法仅凭客户端程序就获得所有服务端代码、数据和算法。逆向研究也不意味着可以随意复制受保护的代码，或绕过软件授权。

GitHub 的热度，更多说明大家对这项能力的兴趣，还不能代表它已经得到大规模实际应用的验证。

五、每个人都需要 REA 吗？

从真实需求来看，它目前更适合软件开发者、安全研究人员，以及需要维护旧系统、研究软件内部机制的人。

至于我自己，虽然也在通过 Coding Agent 开发一些小产品，但目前没有什么问题需要通过逆向工程解决。

所以暂时不会为了体验热门项目，就专门安装它。

不过，研究 REA 还是让我对 AI 的发展多了一点认识。

过去让我惊讶的是，即使不亲自写代码，我也可以通过 AI 把想法做成产品。

而 REA 展示了另一个方向：原本需要专业工程师才能开展的软件内部调查，现在也开始能够由 AI Agent 承担一部分。

对需要这些能力的人来说，这是很有价值的变化。

对暂时用不上的人来说，理解它能做什么、又有哪些局限，也是一种收获。

不必因为一个工具非常火，就急着给自己找一个使用它的理由。

资料参考：REA 官方 GitHub、REA Notion 案例、GitTrend（2026.10.14）

S2 Day 033 · 当产品的用户不只有人，还有 Agent，软件该怎么设计？

Wed, 14 Oct 2026 00:00:00 GMT

最近用 Dot 时（这里的 Dot 可以替换为 Muse 等一众 Personal AI Agent），我开始想一个以前很少认真想过的问题：

如果以后很多事情都先交给 Personal Agent，那软件的 user 还会只有人吗？

比如我自己做的 Roleward，是一个求职工具。

现在的使用方式还是：

我打开 Roleward（如果用站点而不是 skill）；
搜索职位；
看匹配分析；
保存岗位；
更新申请状态。

但如果以后我已经有一个长期了解我的求职 Dot，我可能根本不想每天再打开 Roleward。

我会直接问：

最近求职怎么样？有什么需要我处理的吗？

然后让 Dot 自己去读取 Roleward 的状态、搜索新职位、检查 Gmail，再把真正需要我判断的事情拿回来。

问题来了：

Dot 怎么使用 Roleward？

这个问题也让我终于比较实际地理解了 MCP、Tool、Signal 这些最近很热的概念。

01 不一定所有产品都要做 Agent

看到 Agent 很热，很容易产生一个反应：

我的产品是不是也应该做一个 Agent？

但 Roleward 已经没有必要再变成另一个 Dot。

Dot 可以负责：

理解我的长期目标；
判断现在该做什么；
协调不同工具；
需要时主动回来找我。

Roleward 更适合做另一件事：

让这样的 Agent 可以很好地使用它。

这就是我现在理解的 Agent 和 Agent-ready 的区别。

Agent 自己拥有目标并持续行动。

Agent-ready product 不一定自己有 Agent，它的核心能力可以被外部 Agent 安全、清楚地调用。

02 如果 Dot 要进入 Roleward，它需要一扇门

假设 Dot 想做几件事：

读取我的求职 pipeline；
保存一个新职位；
查看某个职位的匹配分析；
更新 application status。

Roleward 需要把这些能力提供出来，例如：

get_pipeline()
save_job()
evaluate_job()
update_application()

这些就是 Agent 可以调用的 Tools。

但 Dot 怎么知道 Roleward 有这些 Tools？

每个 Tool 要传什么参数？

返回什么？

需要什么权限？

出错以后意味着什么？

这里就进入了 MCP。

可以把关系粗略理解成：

Dot / ChatGPT↓MCP client↓MCP↓Roleward MCP server↓Roleward backend / database

MCP 是双方都遵守的一套通信规范。

ChatGPT 这一侧负责 MCP client；

Roleward 如果希望支持这种调用，可以提供 MCP server。

MCP server 也不一定是什么很庞大的“服务器”。

这里的 server 更接近一个角色：

它负责把 Roleward 可以提供给 Agent 的能力，按照 MCP 的标准暴露出来。

比如告诉 Agent：

我有一个 save_job Tool；
它什么时候适合使用；
需要 title、company、URL；
执行成功会返回 job ID；
这个 Tool 会修改用户数据，所以需要相应权限。

03 那 API 和 MCP 又是什么关系？

Roleward 自己本来就可能有 API。

Web 前端需要读取数据、保存职位、调用 AI 服务，本身已经会和 backend 通信。

API 解决的是：

软件怎样调用 Roleward。

MCP 更偏向解决：

Agent 怎样发现、理解并调用这些能力。

很多时候 MCP server 底下仍然是在调用已有 API。

所以它们不是二选一。

可以理解成：

Agent↓MCP Tool↓Roleward API↓真实的数据和业务逻辑

这也是为什么我现在觉得 MCP 有意思。

它不是又发明了一套“让 AI 更聪明”的东西。

它解决的是很现实的问题：

模型理解了用户想做什么以后，到底怎么进入真实的软件世界把事情做掉。

04 但“能操作”还不够，Agent 还需要知道什么时候操作

这是我自己创建求职 Dot 后才真正感受到的一点。

我原本会觉得：

既然它是 always-on agent，它应该自己持续找新岗位。

实际创建任务时，我还是需要告诉它：

每天检查一次。

原因很简单。

Agent 再聪明，也需要一个 signal 告诉它：

现实世界可能发生了变化。

Signal 可以是：

每天上午 9 点；
收到一封新的 recruiter email；
一个 application status 更新；
一个职位七天没有进展；
CI test failed；
某个指标超过 threshold；
用户刚刚上传了一份文件。

收到 signal 后，Agent 才重新判断：

这件事情重要吗？
现在需要行动吗？
调用什么 Tool？
需要找人确认吗？

所以我现在会把 Signal 看得比以前重要很多。

一个产品如果想被 always-on Agent 使用，不只要回答：

Agent 可以做什么？

还要回答：

发生什么变化时，它应该知道？

05 Agent 也不完全等于普通 User

还有一个以前很少考虑的问题：权限。

如果 Dot 替我更新 Roleward 里的 application status，系统最好知道：

这是 Dot 在 on behalf of Limin 做操作。

Agent 更像一个 delegated actor。

于是产品需要开始考虑：

它能读哪些东西？
能不能写？
哪些 action 需要 human approval？
谁授权了这个 Agent？
这个授权什么时候过期？
发生错误能不能 undo？
以后回头看，能不能知道到底是谁做的？

Agent 能力越强，这些以前容易被当成后台工程问题的东西，越会变成产品体验的一部分。

06 那以后 SaaS 的 UI 会消失吗？

我觉得这个问题要拆开看。

假设未来我几乎不打开 Roleward。

Roleward 仍然需要保存：

职位；
application state；
scoring；
用户数据；
各种 business logic。

减少的可能只是：

用户必须亲自进入 UI，一步一步操作这些能力。

于是同一个产品未来可能同时有两种入口：

Human → UI

Agent → Tools / API / MCP

UI 仍然适合浏览、比较、检查和做复杂判断。

Agent 更适合执行、协调和持续跟进。

具体比例取决于产品。

所以我也不会因为 MCP 最近很热，就把自己所有产品全部 MCP 化。

比如一个主要在本地处理隐私数据的产品，或者一个只在用户明确上传内容以后才工作的工具，就未必需要 always-on Agent 或远程 MCP。

先有真实的 Agent use case，再决定要不要 Agent-ready。

这是我现在会坚持的顺序。

07 如果以后 Agent 也可能成为产品使用者

我现在会多问三个问题：

第一，我的产品真正值得被调用的核心能力是什么？

不要把 UI 每一个按钮都做成 Tool。

Expose 的应该是：

save_job

而不是：

click_save_button

第二，Agent 怎么知道现实发生变化了？

有没有 event、webhook、notification、state change 或其他 signal？

第三，这些调用是否安全、可验证、可追踪？

权限、approval、audit、undo 怎么设计？

这三个问题目前对我来说，比：

“我的产品是不是也应该做一个 Agent？”

更值得先回答。

因为 Personal Agent 如果真的越来越成为用户的入口，我们未必都需要再造一个 Agent。

但越来越多的软件，可能需要准备好被 Agent 使用。

S2 Day 032 · Personal AI Agent 越来越强，Skill 还需要吗？

Tue, 13 Oct 2026 00:00:00 GMT

最近我刚好连续做了三个 Skills：求职、钢琴谱简化、Reflection Companion。

结果开始认真用 Dot 之后，我冒出了一个有点尴尬的问题：

Personal AI Agent 已经可以自己理解需求、研究怎么做、调用工具、记住长期 context，那为什么还需要 Skill？

尤其钢琴谱简化这个例子很明显。

我不是音乐专业，里面很多具体方法并不是我带进去的专业知识，而是 AI 在一次次尝试里自己找出来的。

既然如此，下次再来一份谱子，直接让一个足够强的 Agent 重新做，不行吗？

我想了一段时间，觉得答案其实没有必要维护 Skill 的“存在感”。

有些 Skill 确实会变得没有必要。

01 如果 Agent 临场发挥已经够好，就不用 Skill

假设一个任务：

每次出现的情况都不太一样；
Agent 自己研究就能稳定完成；
结果不要求严格一致；
也没有固定规则、脚本或者验收标准需要复用。

那把它专门做成 Skill，意义确实不大。

模型越来越强以后，过去很多为了“教模型做事”写下来的东西都会慢慢变薄：

很长的 Prompt；
一步一步的 hand-holding；
告诉模型“先分析，再思考，再输出”的固定套路；
大量为了防止模型跑偏而堆出来的 instructions。

这些东西的价值，本来就建立在模型暂时做不到。

底层能力提高以后，它们自然会被吃掉。

02 那 Skill 留下来的是什么？

后来我换了一个问题：

有没有一些已经解决过的问题，值得下次不要重新解决？

这时候 Skill 的价值就比较清楚了。

比如第一次做钢琴谱简化时，已经花过时间确定：

不同难度怎么区分；
什么东西不能随便删；
输出需要包含什么；
怎么检查生成结果；
遇到异常怎么处理。

这些答案是不是我原创的，其实没有那么重要。

第一次完全可以是人和 AI 一起探索出来的。

真正值得保存的是：

这套做法已经验证过，下次希望继续复用。

于是 Skill 更像是在保存：

workflow；
constraints；
eval；
scripts；
templates；
failure handling。

它把一次探索的结果，变成一套可以重复、测试、版本管理和分发的东西。

所以以后我决定要不要做一个 Skill，可能不会再问：

这个任务 AI 会不会做？

而会问：

这件事里有没有什么值得稳定复用？

如果每次让 Agent 重新发挥就够了，不需要 Skill。

如果要求重复、一致、可测试，Skill 仍然有价值。

03 但 Skill 可能会越来越“看不见”

这是最近用 Personal Agent 时另一个很明显的感觉。

以前完成一件事情，我需要自己知道：

应该打开哪个 App；
要不要 Search；
用哪个 Skill；
什么时候运行 Automation；
下一步应该把结果搬到哪里。

这些其实都是用户在做 orchestration。

如果 Personal Agent 足够了解我，它完全可以自己判断：

“现在该搜索新职位了。”

“这一步应该调用求职 Skill。”

“Recruiter 回邮件了，需要更新 application state。”

“明天有面试，把 Calendar 和之前的材料一起整理出来。”

用户可能只需要说：

帮我继续跟进找工作的事情。

后台发生的是：

Search → Skill → Gmail → Calendar → Automation。

但用户未必需要知道。

所以我现在越来越觉得，Personal Agent 带来的一个变化是：

很多东西不会消失，只是逐渐从用户眼前消失。

Skill 可能还在；

Automation 还在；

Search 还在；

各种 SaaS 也还在。

只是我们不一定再需要一个个主动找到它们、理解它们、操作它们。

04 AI 会让普通用户越来越“傻瓜”吗？

某种程度上，我觉得会。

过去学一个新工具，需要理解它的结构和操作方式。

后来有了自然语言，我们开始不用记那么多菜单。

到了 Personal Agent，连“应该使用哪个工具”这一步都有可能交出去。

用户只需要更接近原始需求地说：

我想找工作。

我下个月要搬家。

我想把这首曲子练下来。

至于背后用了什么模型、Skill、搜索工具、数据库或者自动化，慢慢都可能变成 implementation detail。

这对普通用户当然是好事。

不过“会表达需求”也不是全部。

什么才算一份适合自己的工作？
怎样的房子值得多花两万块？
一份投资建议到底是否合理？

工具使用门槛降低以后，对结果的判断力并不会自动出现。

也许以后真正需要学习的，会越来越少是“怎么操作工具”，越来越多是“我想要什么，以及我如何判断结果好不好”。

至少对我现在做 Skill 这件事来说，我会先记住一个很简单的原则：

不要因为一件事情可以做成 Skill，就把它做成 Skill。

值得固化的，是那些已经解决过、以后也值得稳定复用的问题。

剩下的，交给越来越聪明的 Agent 临场发挥就好。

S2 Day 031 · ChatGPT - 有了Project，还需要 Space 吗？

Mon, 12 Oct 2026 00:00:00 GMT

最近才认真点开 ChatGPT 新推出的 Space。

Page 像以前的 Canvas，Space 有点像 Notion。但我有个疑问：Project 已经能保存资料、复用上下文、多人协作，为什么还需要 Space？

01｜Space 是什么？

Page 是一份可以和 AI 一起编辑的文档：修改段落、添加表格、评论，或让 ChatGPT 协助修改。Space 则组织多个 Pages、文件和子页面，也可以分享单个 Page 或整个空间。

它和 Project 都能保存资料、共享给别人，区别不在这里。

02｜Project 和 Space，怎么区分？

最容易理解的区别是：

Project 以 Chat 为主要工作入口。把对话、文件、Instructions 放在一起，让 AI 利用共同背景，持续研究、讨论、推进工作。Shared Project 也支持多人查看和分支讨论。

Space 以 Page 等成果为主要工作对象。大家可以编辑同一份文档，在具体段落评论，让 AI 根据当前内容修改。

所以不是「Project 给个人、Space 给团队」，也不是「Project 能思考、Space 才能保存成果」。两者有不少重叠，只是侧重点不同。

03｜一个产品发布的例子

三个人准备发布新产品。

在 Project 里，PM、设计师、工程师共享背景，各自借助 AI 研究需求、探索方案、讨论技术风险。

在 Space 里，团队共同维护 PRD、发布计划和对外文案。市场同事对某句产品描述提出疑问，PM 在原文旁核实、评论，再请 AI 修改这一段。

前者适合探索与推进，后者适合围绕同一份成果协作。

04｜已经在用 Project，要迁移吗？

我的判断是：不必。

如果主要是自己和 AI 长期讨论、推进项目，Project 已经很好用。

如果常需要多人修改、评论同一份成果，可以试试 Page；需要管理多份 Pages，再考虑 Space。

如果 Project + Google Docs / Notion / GitHub 已经运转顺畅，也没必要搬家。

Space 值得关注，因为它让 AI 不只参与讨论，也参与成果的共同维护。但是否更高效，应该由真实工作流决定，而不是新功能的名字。

S2 Day 030 · 我做了个求职 Skill：更关注想去/能去/适合

Sun, 11 Oct 2026 00:00:00 GMT

最近陆续分享了钢琴谱简化和 Reflection Companion，今天是第三个开源 Skill：Roleward Job Hunting。

这个跟我今年自己的求职经历关系最大。

今年一直在尝试往 AI PM 方向转，前前后后看了不少 JD，也花了不少时间在岗位筛选、研究和修改申请材料上。

有的岗位和过去的经历很匹配，但并不是自己下一步想去的方向；有的要求看着差了一点，却可能值得试试。

还得考虑招聘方能不能理解自己的经历、地点和签证等现实条件是否允许，以及这个岗位到底还在不在招。

所以我把这些反复做的工作整理成了一个 Agent Skill。

它可以根据你的经历和职业方向，找少量值得关注的岗位；也可以直接拿一份 JD 来分析。

每个岗位会给出「值得投入 / 先核实 / 放弃」的建议，以及对应的理由。决定要投之后，再整理申请定位、准备简历和其他材料，后续的投递结果也可以记录下来。

有个规则是我比较坚持的：如果这次没找到足够值得看的岗位，返回 0 个也没关系，不需要为了凑数给出一堆链接。我也没做自动投递，因为我还是觉得最后的把关是值得人工介入检查与决定的节点，投的准也比投的多更好，自己要了解自己带自己去哪里的。

目前还是 Public Alpha，完整验证过的使用方式是本地 Coding Agent(Codex, Claude Code)。

图片里放了一个岗位判断的示例，以及目前的使用方法。

如果你也正在找工作，尤其是想换行业、换方向，欢迎拿实际场景试试。也很想知道它会在哪里判断错误、漏掉什么，或者哪些环节用起来不太顺手。

S2 Day 029 · 和 AI 聊这么久，我做了个 Skill 了解自己

Sat, 10 Oct 2026 00:00:00 GMT

上次分享了一个钢琴谱简化 Skill，这次换个方向，聊聊 Reflection Companion。

我平常跟 AI 聊的内容挺多的，工作、做产品、生活里的琐事，还有不少想了很久也没想明白的问题。

很多时候，聊完当下是有帮助的，但这些对话很快就沉到历史记录里了。

之前开始尝试让 AI 帮我整理日记、做每周回顾。后来慢慢有了更多想法：

- 能不能把不同时间的讨论放在一起，看看自己哪些判断变了？

- 有没有一些反复出现，但自己没注意到的思考方式？

- 如果我对一件事的理解有偏差，AI 能不能提供一些不同的解释，而不是一直顺着我说？

- 还有一个我自己挺喜欢的用法：不一定每次都由我来提问，偶尔也让 AI 问我一个值得想想的问题。

后来把这些做法整理成了一个开源 Agent Skill，叫 Reflection Companion。

我也不希望它变成一个动不动就给人贴标签的工具。AI 有时候特别擅长把事情解释得头头是道，但听起来合理，不代表真的有证据。

所以在这个 Skill 里，我希望它能先核对材料，分清事实和推测；如果我的判断有道理，也不必为了挑战而挑战。如果解释错了，可以直接纠正。

目前是 v0.5.6 Public Alpha，提供 Codex、Claude Code 和 Claude 网页版的使用方式。不同平台能读取的历史对话范围不一样，没有历史也可以从一个问题开始。

免费开源，Skill 附在这篇笔记里。

如果你也经常跟 AI 聊天，欢迎试试。我很想知道实际用起来怎么样，哪些地方有帮助，哪些地方不准确，或者根本没能按预期运行。

S2 Day 028 · 喜欢的钢琴曲太难，我做了个改谱 Skill

Fri, 09 Oct 2026 00:00:00 GMT

最近在整理自己做的三个开源 Agent Skills，打算陆续分享一下。

先从钢琴谱简化这个开始。

弹琴的时候会有这样的困扰：听到一首很喜欢的曲子，找到原谱，发现直接上手弹还有点难，没法用小成本享受美丽的旋律；而想弹的心情，有时候就在那一会。网上也许有简化谱，但不一定适合自己的程度，有时候简化得太多，又没那么喜欢了。

所以之前就在想，能不能让 AI 根据原谱，专门处理那些自己弹不了的地方？比如左手和弦太宽、跳跃太大，其他喜欢的部分尽量留下。

后来把这套流程做成了一个 Agent Skill，叫 Score Simplifier。

可以选 L1、L2、L3 三档难度，也可以直接告诉它哪里弹不下来，再针对具体小节修改。

这次用柴可夫斯基《四季·十月》做了个例子。图片里放了原谱和三个简化版本，可以直接对比看看它具体改了什么。

目前是 v0.3.7，还是实验版。支持输出 PDF、MusicXML 和 MIDI。

免费开源，Skill 附在这篇笔记里。

如果你也在弹琴，欢迎试试。尤其想听听实际弹下来的反馈，哪些地方还是太难，或者改得不太对味。

另外两个 Skill 分别和求职、日常复盘有关，之后再慢慢介绍。

S2 Day 027 · 做 AI 产品，用 AI 做产品 - 面试复盘 04

Thu, 08 Oct 2026 00:00:00 GMT

有次面试被问到：「做 AI 产品」与「用 AI 做产品」有什么区别？

我当时没有答得特别好。后来想想可能是这几个维度：

01｜用 AI 做产品：AI 改变的是生产方式

PM 用 AI 做 research、整理需求，Designer 用 AI 出原型，Engineer 用 coding agent 写代码。

AI 提高了团队做产品的效率，但最后交付的产品本身可以完全没有 AI。

所以，一个团队大量使用 ChatGPT、Claude 或 coding agent，并不能说明它在做 AI Product。

02｜AI 产品：AI 进入了用户获得价值的过程

比如模型负责生成、分类、推荐、搜索、对话，或者处理 workflow 中的一部分判断。

这时 AI 已经不是团队内部的工具，而是产品能力的一部分。

PM 也会多出一些判断：怎么定义质量，模型错了怎么办，哪里该用确定性规则，是否需要 human review，延迟和成本能不能接受。

但“产品用了 AI”，也不一定就是 AI-native。

03｜AI-native：产品本身围绕 AI 重新设计

这个词没有完全统一的边界，我自己会用一个简单的问题来判断：

如果把 AI 拿掉，核心 workflow 和 value proposition 还成立吗？

如果只是少了一个 AI assistant，原来的产品基本还能工作，我更倾向把它看成 AI-enabled。

如果 AI 拿掉以后，核心 workflow 都需要重新设计，它才更接近 AI-native。

所以我现在会这样区分：

- AI 改变团队怎么做产品 → 用 AI 做产品

- AI 成为产品能力的一部分 → AI 产品

- AI 改变产品本身应该怎样被设计 → AI-native

对 PM 来说，这个区别不只是名词。

前一种主要改变工作效率；到了 AI 产品，需要开始管理模型行为和风险；到了 AI-native，问题会再往前一步：

不是“现有产品哪里可以加 AI”，而是“有了 AI 以后，这个 workflow 还应该这样存在吗？”

S2 Day 026 · 面试没过的复盘思路 - AI PM 面试复盘 03

Wed, 07 Oct 2026 00:00:00 GMT

几轮面试下来，我发现“没过”这个结果本身，其实不能告诉我下一步该做什么。

复盘时，我会尽量把问题拆成三类。

01｜Capability gap：这件事确实还不会

有一次偏 AI Platform 的面试，对方一路往平台、基础设施和 Engineer workflow 深挖。

这部分我的经验确实没有应用层 AI、复杂 workflow 和受监管系统那么深。

这种 gap 不是换一种说法就能解决的。

如果它属于自己想继续发展的方向，就需要真的去补：理解系统、做项目、跟更技术的人合作，而不是继续背面试答案。

02｜Interview gap：会，但当时没有证明出来

这类情况我也遇到过不少。

比如题目问 prioritization，却答到了 evaluation；背景讲了太久，结论出来得太晚；题目有三部分，只回答了两部分；或者明明有合适的经历，临场选了一个不够贴题的故事。

这里缺的未必是知识，而是听题、组织和表达。

复盘的重点也应该放在：我到底在哪一步丢掉了原本已经有的东西？

03｜Fit gap：对方需要的，刚好不是自己的强项

同样叫 AI PM，有的岗位很重 enterprise delivery，有的重 discovery，有的需要很深的平台经验，有的又特别依赖某个行业背景。

一个人不可能同时在所有方向都最匹配。

但 fit gap 也不能拿来解释所有失败。

如果自己长期想做的岗位都反复暴露同一个问题，那它就更像 capability gap，而不是“只是没缘分”。

所以我现在复盘一次面试，会问三个问题：

1. 这件事，我是真的不会吗？

2. 我会，但当时没有让对方看见吗？

3. 还是这个岗位真正需要的能力，本来就不是我的强项？

现实里三种情况经常混在一起。

但尽量分开之后，下一步会清楚很多：

- 该补的能力去补；

- 该练的面试表现去练；

- 不匹配的岗位，也不用因为一次 rejection 就重新定义自己。

S2 Day 025 · 我在面试里答串的概念 - AI PM 面试复盘 02

Tue, 06 Oct 2026 00:00:00 GMT

有几次面试，我在几个很接近的问题上答偏了：

一次，对方把客户反馈整理、聚类，问“接下来怎么决定做什么？”我却继续讲 signal 的质量和验证。对方提醒：他问的是 Prioritization。

另一次，对方问：面对开放的问题空间，怎么找到真正值得解决的问题？我的回答又太快进入价值、成本和优先级。回头想想才知道他问的是 Discovery

回到完整流程：

Goal / Outcome → Problem Discovery → Opportunity Set → Prioritization → Solution Discovery → Delivery → Evaluation / Measurement → Iteration

实际工作不会这么线性，但很适合定位问题。

01｜Discovery：什么问题值得解决？

从用户、数据、客服 / 运营反馈、workaround 等信号里找重复模式，区分表面的 request 和更底层的问题，再验证它是否真实、重要。

02｜Prioritization：几个值得做的问题里，先做哪个？

问题大体成立，但资源有限。这时比较必须做的事、用户和业务价值、紧迫性、证据强弱、工程成本、依赖和风险。

本质是在有限资源下做取舍：这个往前排，什么就要往后放。

03｜Evaluation：做出来以后，到底好不好？

看结果有没有达到 success criteria。

普通产品可能看 conversion、retention；AI 产品还会多看 accuracy、groundedness、human override、latency、cost。上线前做 eval，上线后还要看真实使用中的表现。

三个概念都在影响“我们做什么”，所以很容易混。

我现在简单记成：

- Discovery：问题找对了吗？

- Prioritization：事情排对了吗？

- Evaluation：结果达到预期了吗？

一个客户需求可以是 discovery signal，但不能因此证明问题成立，也不会自动获得 roadmap priority。

面试里，先判断对方问的是哪一步，再回答。

S2 Day 024 · 相同 title 的不同侧重 - AI PM 面试复盘01

Mon, 05 Oct 2026 00:00:00 GMT

这段时间面了几轮 AI PM，有一些被问住或面完才想清楚的问题。

想把这些整理成一个系列，每篇只讲一个问题，不是标准答案，是我的面试复盘。

第 1 篇：同样叫 AI PM，实际可能是在招不同的人。

01｜偏企业交付

这类岗位往往面对很多客户、业务方和内部 stakeholder。

- 多个客户都说自己的需求最重要，怎么排？

- 外部已经有承诺，但资源有限，怎么办？

- 需求不断变化，怎么控制 scope 和预期？

这里也需要产品判断，但 expectation management、取舍和复杂协作，本身就是工作的重要部分。

02｜偏产品 / 功能

问题更靠近 discovery、prioritization 和 outcome：

- 谁有这个问题？

- 为什么值得做？

- AI 是否比规则或普通自动化更合适？

- 做完以后怎么判断有效？

产品阶段也会改变重点。成熟模块更关心 adoption、quality 和持续优化；0→1 可能连值得解决的问题都还没有确定。

03｜偏平台

如果直接用户是内部 Engineer 或产品团队，PM 要考虑的不只是某个 use case 有没有业务价值，还包括：

- 哪些能力值得统一建设？

- 怎么减少重复开发？

- 怎样让其他团队更快、更安全地把 AI 应用做到生产环境？

终端产品的价值通常更直接落在业务结果；平台的价值更多体现在让这些产品更快、更安全、更稳定地被做出来。

04｜偏探索

还有些岗位，公司知道 AI 很重要，但并不确定它应该进入哪个 workflow。

这时 PM 还不是先排 roadmap，而是先找到值得解决的问题，再判断 AI 是否适合。

以上不是严格、互斥的分类，只是我从几轮面试里看到的几种工作重心，比职位名称更有信息量的是：

- 它 owning 什么？

- 直接用户是谁？

- 产品处在哪个阶段？

- 这个 PM 最重要的决策是什么？

对应的能力重点也不同：

- 企业交付更看 stakeholder 和 expectation management；

- 产品 / 功能更看 discovery、prioritization 和 outcome；

- 平台更看 technical depth 和 system thinking；

- 探索型更看处理模糊问题的能力。

S2 Day 023 · 分享一下我对 Eval Design 的想法

Sun, 04 Oct 2026 00:00:00 GMT

这一天的内容发在小红书，搜索号码 113337197 找到「分享一下我对 Eval Design 的想法」。

S2 Day 022 · 我把过去 100 天写的东西，做成了一个网站

Sat, 03 Oct 2026 00:00:00 GMT

这一天的内容发在小红书，搜索号码 113337197 找到「我把过去 100 天写的东西，做成了一个网站」。

S2 Day 021 · ChatGPT 新出了 Dot，Personal AI Agent 又多了一个

Fri, 02 Oct 2026 00:00:00 GMT

9 月 29 日，OpenAI 在 DevDay 上发布了一个新功能：Dot。

三周前，Meta 刚上线 Muse。两个产品都属于最近很热的一类 AI agent：

有自己的运行环境，能连接其他应用，记住长期上下文，也可以在你没有一直盯着聊天框的时候继续做事。

我自己创建了一个求职 Dot，最想先弄明白的是：

这和现在已经有的 Chat、Work、Scheduled Tasks、Codex，到底有什么不同？

01 用同一个例子理解 Dot

假设我正在找 AI PM 的工作。

在普通 Chat 里，我可能问：

“今天有没有新的 AI PM 职位适合我？”

它搜索、分析，然后回答我。

在 Work 里，我可以交给它一件更完整的工作：

“把最近一周 UAE 的 AI PM 职位研究一遍，根据我的背景筛选、去重，再整理成一份可投递列表。”

它可以自己拆步骤，工作一段时间，最后交付结果。

Scheduled Task 解决的是固定触发：

“每天上午 9 点搜索一次新的 AI PM 职位。”

Codex 主要负责软件工程。

如果任务涉及代码、测试、repo，它可以直接去完成。

Dot 多了一层持续状态。

我可以把“AI PM job search”作为一件长期事情交给它。

它知道我已经看过什么、投过什么、哪些公司正在面试、哪些 recruiter 在等回复，也可以继续使用 Gmail、Calendar 或其他已连接的信息。

第二天有了新职位，不需要重新解释一遍背景。

Recruiter 发来邮件，它也知道这封邮件和之前哪个申请有关。

OpenAI 把这种能力叫做 ongoing responsibility。

02 Dot 本身包含了什么？

Dot 由 GPT-6 Astra 驱动，有自己的 cloud computer 和 browser。

它可以长期保留 context 和 memory，连接授权的 apps，在后台完成任务，运行 recurring tasks，主动查看已经连接的信息，也可以根据需要使用 Work 或创建 Codex task。

可以把它理解成一个长期存在的 agent 身份。

Chat、手机、Slack、Call 等，更像是你和它交流的不同入口。

03 Always-on 不代表“实时扫描一切”

这个是我自己试用以后才注意到的。

我给求职 Dot 创建任务时，最后仍然需要告诉它：

“每天检查一次新的职位。”

原因很简单：AI 需要一个渠道知道外界发生了变化。

比如：

时间到了 → 搜索今天的新职位
Gmail 来了新邮件 → 检查是不是 recruiter 回复
Slack 出现某类消息 → 开始对应工作
GitHub CI failure → 调查失败原因

Dot 还有 proactive research，可以自己查看已经授权的信息，寻找值得注意的变化。

OpenAI 目前没有公布 proactive research 固定多久检查一次。

所以 always-on 更接近“持续存在并保持状态”，不是所有事情都有实时事件流。

这也让我开始注意一个很基础的问题：

Agent 能有多主动，很大程度取决于它能收到什么 signal。

如果一个系统没有日志、测试、通知、事件或者可以查询的数据源，再聪明的 Agent 也不知道现实世界刚刚发生了什么。

04 Dot 还可以把工作交给 Work 和 Codex

Dot 不需要自己完成所有执行。

比如一个软件产品出现 CI failure：

CI failure→ Dot 看到 signal→ 理解最近发生了什么→ 创建 Codex task→ Codex 调查、改代码、跑测试→ Dot 整理结果→ 需要判断时再回来找人

如果要使用 Codex Cloud，需要先为对应 repo 建好 Codex cloud environment。

没有建也不影响正常使用 Dot，只是不能直接在那个 cloud environment 里创建 coding task。

如果开启本地 computer access，Dot 还可以创建本地 Work / Codex tasks，访问被授权的本地文件和浏览器。

05 OpenAI 给了哪些 use case？

官方目前给出的例子其实很广。

最简单的是每天早上检查 Calendar，告诉你当天有什么安排。
也可以长期推进一个 project，持续跟踪计划和 deadline。
销售场景里，客户需求发生变化以后，Dot 可以更新 proposal、继续准备分析和材料，需要时再把结果交给人 review。
Developer 的例子里，它可以持续查看 customer feedback，发现反复出现的 feature request 或 bug，再进一步调查和处理。
背后如果接了 Codex 或 Work，需要执行的部分还可以继续委派出去。

这些场景有一个共同点：

事情会持续一段时间，状态会变化，每次变化之后又可能产生新的 next action。

求职、客户跟进、长期项目、研究、产品维护，都比较适合。

06 Call、Slack，让 Dot 出现在不同入口

Dot 现在可以直接 Call。

这里的 Call 是你主动打给 Dot，进行实时语音对话。目前 Dot 还不能主动给你打电话。

它也可以接进 Slack。

在企业环境里，Dot 可以以自己的 identity 出现在 Slack channel 里，工作不必全部发生在 ChatGPT 网站中。

这些功能解决的是：

你要去哪里找到这个 Agent，以及它在哪里继续和你工作。

同一个 Dot 可以从电脑上的 ChatGPT，延续到手机、Call、Slack，以及其他 messaging channels。

这样看，它和普通聊天窗口的区别也会更直观。

07 权限可以给到什么程度？

Dot 可以使用你已经授权给 ChatGPT 的 Plugins，例如 Gmail、Drive、GitHub。

此外还有 Custom Rules，可以规定某类动作：

可以自己执行；
我明确要求过就可以执行；
每次先问我；
直接交回给我操作。

比如求职：

读取招聘邮件，可以。
整理 tracking，可以。
发送 recruiter email，每次问我。
正式提交 job application，我自己来。

Dot 的 proactive research 本身也有边界：它可以读取授权的信息并留下 private notes，但不能直接通过这个后台研究过程发消息、修改 plugin 内容或者控制电脑。

真正执行动作时，仍然需要经过相应的 permissions 和 safety checks。

08 现在谁可以用？

Dots 从 9 月 29 日开始逐步上线。

目前支持 Pro、Business Premium，以及由管理员开启的 Enterprise beta。

Pro 首发暂不包括 EEA、瑞士和英国，需要年满 18 岁。

Dot 可以在 desktop web 或 ChatGPT desktop app 创建。创建之后，也可以在支持的移动端继续和它交流。

目前仍在 gradual rollout，所以不同账号看到功能的时间可能有差异。

09 为什么最近突然都在做这种 Agent？

Meta 把 Muse 称为 personal AI agent。
OpenAI 把 Dot 称为 always-on agent。
更大的类别还是 AI agents / agentic AI。

如果要给这一类产品一个便于理解的描述，persistent personal agent 比较贴切，不过这不是行业统一的官方名称：

有持续身份；
有 memory；
有自己的 computer；
能连接外部工具；
可以接受 signal；
能在后台继续工作；
需要的时候再回来找人。

Muse 9 月 8 日上线，Dots 9 月 29 日发布。

不可能是 Muse 火了以后，OpenAI 三周之内才开始做 Dots。它们同时出现，更像是不同公司都走到了相近的产品方向。

过去一两年，模型处理 long-horizon task、调用工具和操作电脑的能力一直在提高。

Cloud computer、memory、app integrations、权限控制、background execution 这些外围能力也逐渐成熟。

现在它们开始被拼成普通用户可以直接使用的产品。

Muse 最近的快速走红，也让更多人开始注意这种产品形态。

10 开始用 Dot以后，我会特别留意什么？

过去使用 ChatGPT，很多精力放在 prompt 怎么写、下一步问什么、context 怎么搬过去、什么时候记得回来继续做。

长期 Agent 会减少一部分这样的管理工作。

我现在更关心几个问题：

我要它长期负责什么？
它通过什么 signal 知道事情变了？
哪些数据和工具可以给它？
哪些动作允许它自己做？
什么结果必须回来让我检查？

至少现阶段，我不会一上来把 Gmail、Drive、GitHub 和电脑全部开放，再告诉它“你自己看着办”。

我更想先挑一个边界清楚、容易验证的事情跑一段时间。

现在选的是求职。

看看它到底能不能减少我每天自己记得“下一步该干什么”的成本。

最后还有一个挺可爱的巧合。

OpenAI 到现在没有解释为什么它叫 Dot。

但看到这个名字，我第一时间想到了 Steve Jobs 在 Stanford 演讲里的那句：

“You can’t connect the dots looking forward; you can only connect them looking backwards.”

不知道命名有没有关系，官方没有这么说。

不过一个长期 Agent 确实每天都在面对很多散落的 dots：

一次对话，一封邮件，一个 Calendar event，一条 Slack message，一个 GitHub issue。

能不能把这些点持续接起来，可能才是这种产品真正好不好用的地方。

资料来源：OpenAI Dots Help Center、Dots Privacy / Security / Safety FAQ、GPT-6 Astra System Card；Meta Muse 官方发布；Reuters 对 Dots 和 Muse 的报道。

S2 Day 020 · 我把过去 100 天写的东西，做成了一个网站

Wed, 30 Sep 2026 00:00:00 GMT

这一天的内容发在小红书，搜索号码 113337197 找到「我把过去 100 天写的东西，做成了一个网站」。

S2 Day 019 · 如果音乐能被看见：《四季·十月》可视化

Sun, 27 Sep 2026 00:00:00 GMT

这一天的内容发在小红书，搜索号码 113337197 找到「如果音乐能被看见：《四季·十月》可视化」。

S2 Day 018 · OMG，给你听听看看 AI 生成的丑东西

Sat, 26 Sep 2026 00:00:00 GMT

这一天的内容发在小红书，搜索号码 113337197 找到「OMG，给你听听看看 AI 生成的丑东西」。

S2 Day 017 · 过去我们用注意力换免费互联网，AI 时代我们在交换什么？

Fri, 25 Sep 2026 00:00:00 GMT

上一篇写 ChatGPT 开始卖广告之后，我去认真看了一遍：

通用 AI 到底怎么赚钱。

写完以后，还有一个问题一直留在我脑子里。

过去很多免费的互联网产品，交换关系其实比较清楚：

用户不直接付钱，但贡献注意力和使用行为；广告商再花钱，购买接触这些用户的机会。

所以短视频平台希望我们多刷一会，搜索平台希望更准确地理解我们的意图，社交平台则努力让我们不断回来。

那到了 AI 呢？

如果我没有为 ChatGPT、Claude 或其他 AI 产品付钱，我到底在交换什么？

查完前面的资料以后，我发现，答案已经不只是“注意力”或者“数据”。

01｜有时候，用户其实什么都没有“卖”

这是一个很容易被忽略的情况。

一个免费用户，不一定正在直接给平台带来收入。

很多产品都会先承担免费用户的成本：

一部分人以后升级付费；
一部分人在公司里推动企业采购；
一部分开发者开始用 API；
还有一些人可能一直不付钱。

所以一次免费的 AI 对话，背后的成本可能暂时由其他地方承担：

付费用户、企业客户、其他业务收入，甚至公司的融资。

这意味着：

免费，不一定代表平台正在偷偷从你身上拿走某种等价物。

它也可能只是在花钱获得用户、规模和未来的市场位置。

所以把所有免费产品都理解成“你一定在用某种东西付款”，其实并不准确。

02｜注意力仍然值钱，但 AI 和传统内容平台不太一样

传统互联网里，注意力是一种非常重要的资源。

一条视频看完，再来一条。

一篇内容看完，再推荐下一篇。

用户待得越久，可以展示的广告通常也越多。

很多产品天然希望：

你不要离开。

但 AI 有一点不一样。

如果我只是问：

“帮我把这封邮件改清楚一点。”

一个好的 AI 可能两分钟就解决问题，然后我关闭页面。

从用户角度，这反而是一个很好的体验。

所以：

最好的 AI，不一定应该让我使用得更久。

Anthropic 在解释为什么 Claude 选择无广告时，也提到过类似的问题。

如果一个 AI 产品主要依赖广告收入，它会不会慢慢多出一种动力：

让人停留更久、问得更多、回来得更频繁？

现在还不能因为“出现广告”就断言一定会发生这种变化。

但至少，这提醒了我一件事：

商业模式会影响一个产品长期想优化什么。

03｜AI 得到的不只是注意力，还有大量上下文

这可能是 AI 和上一代互联网产品很明显的不同。

以前我在 Google 搜：

“东京酒店”。

平台知道的是一个搜索意图。

但我可能会对 AI 说：

“第一次带爸妈去东京，他们年纪比较大，不太能走路。预算大概多少，想住地铁附近，我比较在意安静，也不喜欢太游客化的地方。”

为了帮我做好这件事，AI 本来就需要知道更多。

我们的预算、偏好、限制、过去做过什么、正在做什么，都可能成为一次对话的一部分。

但这里也很容易滑向一句过于简单的话：

“所以 AI 拿走了更多数据。”

问题是：

拥有上下文，和如何使用这些上下文，是两件事。

我告诉 AI 自己的预算，首先可能只是为了让它完成任务。

这些信息之后会不会被保存、用于个性化、用于模型改进、用于广告匹配，甚至提供给其他公司，要分别看具体产品的政策。

所以，比“AI 有没有我的数据”更有用的问题其实是：

这些数据分别被拿去做什么？

完成当前任务是一件事。

记住我的偏好是一件事。

改进模型是一件事。

匹配广告又是另一件事。

把它们全部叫成“用隐私换服务”，反而会让真正需要关注的边界变模糊。

04｜更值得长期看的，可能是“默认入口”

再往下想，我觉得还有一个比注意力和数据都更有意思的东西：

习惯。

一开始，我可能只是偶尔问 AI 一个问题。

后来慢慢变成：

写东西先打开它；
做研究先问它；
旅行让它规划；
工作问题让它分析；
文件也交给它；
再往后，邮箱、Calendar、Drive 和其他工具也接进来。

这时候，一个 AI 产品得到的已经不只是我每天花了多少分钟。

它得到的是：

下一件事情，我会不会还是先来这里。

这是一种很不一样的价值。

因为一个产品一旦进入越来越多工作流，换掉它的成本也会慢慢上升。

不只是重新注册一个账号。

还有已经形成的习惯、历史信息、个性化设置、连接好的工具，以及自己已经习惯的工作方式。

过去很多互联网产品争夺的是：

你愿意留下多久。

通用 AI 可能还在争夺另一件东西：

你愿意把多少事情交给它。

我觉得这个变化，比“AI 会不会也开始放广告”更值得长期看。

05｜如果 AI 开始替我们行动，交换关系还会再往前一步

今天我们让 AI：

找一家酒店。

下一步可能是：

帮我比较这几家酒店。

再下一步：

直接替我订。

如果 AI 未来越来越多地参与：

搜索、比较、选择、预约、下单和支付，

那么平台能够赚钱的位置也会越来越多。

不一定只是广告。

还可能来自商家导流、交易佣金、Agent 服务费，或者其他商业合作。

这时候，一个新的问题会出现：

AI 不只是知道我想做什么，它还可能站在我和交易之间。

假如它推荐一家酒店，而平台能从这次预订里获得收入，我会希望知道：

它为什么推荐这一家？

是因为最适合我，还是因为平台也能从这个选择中获益？

这并不意味着有商业利益就一定不能相信推荐。

我们每天使用的很多平台，本来就存在佣金和商业关系。

但至少，这种关系应该是我们能够知道的。

因为只有知道一场交换是怎么发生的，我们才有可能判断自己是否接受它。

06｜以后遇到一个免费 AI，我会先看这 5 件事

现在再看到一个免费的 AI 产品，我不会马上说：

“免费，所以一定是在拿我的数据挣钱。”

我更愿意具体看五件事。

1. 谁在承担我这次使用的成本？

可能是付费用户、企业客户、广告商，也可能只是公司还在用自己的资金补贴增长。

2. 这个产品现在主要靠什么赚钱？

订阅、API、企业业务、广告，还是交易？

3. 我提供的信息之后会怎么用？

只是完成这次任务，还是还会进入 Memory、个性化、模型改进或者广告匹配？

这些不是一回事。

4. 我是不是越来越难离开它？

历史记录、文件、Memory、插件、工作流都积累在一个产品里以后，真正的成本可能已经不只是月费，而是迁移成本。

5. 它推荐东西时，自己有没有经济利益？

尤其是购物、旅行、金融产品、服务推荐这些场景。

如果平台会因为我的选择获得广告费、佣金或者交易收入，我至少希望这件事是透明的。

所以现在回头看，我觉得“免费 AI 到底拿走了什么”其实没有一个统一答案。

有时候是注意力。
有时候是信息和上下文。
有时候平台只是暂时承担了我的成本。
更长期来看，真正有价值的可能还是习惯、工作流，以及成为我处理事情的默认入口。

比“免费的东西里，你才是商品”更有用的，是把每一笔交换具体看清楚：

我得到了什么，对方得到了什么，我是否知道并接受这个交换。

所谓 informed，也许就是这样。

不是把所有产品都当成坏人。

也不是因为方便，就完全不去想背后的商业关系。

只是尽量知道，自己正在使用的东西，究竟是怎么运转的。

如果你在做 AI 产品

同一个问题也可以反过来问：

你的免费用户由谁承担成本？
你希望他们形成什么样的长期行为？
当商业化开始进入推荐、Memory、Agent 和交易以后，哪些边界需要提前设计清楚？

资料说明

这篇延续上一篇关于通用 AI 商业模式的研究，基于截至 2026 年 9 月 OpenAI、Anthropic 等公司的公开产品、定价和数据政策，以及有关 AI 商业模式、广告和推荐系统的相关研究整理。

其中关于“默认入口、工作流和未来行动层”的部分，是基于现有产品趋势进一步做出的分析，不代表这些商业模式已经全部成为现实。

S2 Day 016 · ChatGPT 开始卖广告后，我认真看了看：AI 到底是怎么赚钱的？

Thu, 24 Sep 2026 00:00:00 GMT

前几天收到一封 OpenAI 关于 ChatGPT Ads 的邮件。

看到“Ads”的时候，我才认真想起一个以前没有仔细追过的问题：

我们已经很熟悉互联网产品的几种赚钱方式。Google、Instagram、TikTok 有很重要的广告收入，Netflix 更容易让人想到订阅，很多 SaaS 则由个人或者企业付费。

但 ChatGPT、Claude 这样的通用 AI 呢？

模型研发需要大量投入，上线以后，每一次使用也仍然会产生计算成本。与此同时，它们又同时有免费用户、个人订阅、API、企业版，现在还开始出现广告。

所以我去查了 OpenAI、Anthropic 等几家公司的收费方式、产品政策，也看了一些关于 AI 成本、广告和推荐信任的研究。

最后发现，“AI 是靠订阅还是广告赚钱”这个问题，本身就有点问窄了。

01｜通用 AI 同时在做几门生意

OpenAI 和 Anthropic 都面对几类完全不同的客户。

普通用户每个月交订阅费，买的是更强的模型、更高的使用额度、更多工具和更完整的产品体验。
开发者按照实际使用量调用 API，买的是一种可以接进自己产品里的模型能力。
企业买的又不只是“更多额度的 ChatGPT”。它们还会为员工账号、权限管理、安全、数据控制、系统集成和服务支持付钱。
OpenAI 现在又多了一类客户：广告商。广告商购买的，是在合适的场景里接触潜在消费者的机会。

所以同一个通用 AI，背后其实同时存在几种生意：

向个人卖使用权，向开发者卖模型调用，向企业卖工作平台和管理能力，也可以向广告商卖商业触达。

Anthropic 目前明确选择让 Claude 保持无广告，但它同样有个人订阅、API 和企业业务。

所以两家公司并不是：

OpenAI 靠广告，Claude 靠订阅。

它们的大部分收入模式其实很相似，广告只是目前一个明显的分岔。

02｜不同的人付钱，买的也不是同一种东西

把“谁付钱”理清楚以后，下一层反而更有意思。

我们平时会笼统地说：

AI 公司在卖 AI。

但“AI”太抽象了。

普通用户真正买的是能力和便利。
开发者买的是可以直接调用的模型能力。
企业除了能力，还会购买安全、管理、集成和可控性。
广告商买的则是接触潜在客户的机会。

Google、Microsoft 这样的公司还有另一种路径：AI 不一定需要单独成为一门生意，也可以成为原有软件和服务套餐的一部分，让原来的产品更值得购买或者升级。

所以理解一个 AI 产品的商业模式，不能只看：

“这个 App 一个月多少钱？”

还要看它面对哪些客户，以及这些客户分别为什么愿意付钱。

03｜那作为用户，我们到底付出了什么？

这个问题我觉得比“AI 公司到底赚多少钱”更值得普通用户关心。

最直接的当然是钱。

如果我每个月订阅 ChatGPT 或 Claude，这部分很清楚。

但免费或者低价使用一个产品，也不代表使用它完全没有成本。

我们还可能付出：

看到广告的注意力；
完成任务所需要的信息和上下文；
根据具体条款，允许部分内容用于模型改进或个性化；
自己花在提示、检查和修改上的时间；
以及使用得越来越深以后，迁移到其他产品的成本。

不过，这些东西也不能全部被归结成一句很常见的话：

“如果产品免费，那你就是产品。”

这句话放到今天其实太粗了。

比如我告诉 AI：

“预算 5000 元，主要用来剪视频，应该买什么电脑？”

这些信息首先是为了让 AI 完成我的任务。

它之后是否会被用于模型训练、个性化、广告匹配，或者被提供给其他公司，是几个完全不同的问题，要看具体产品和具体条款。

处理数据，不等于拿数据训练模型；用于个性化，也不等于把聊天内容卖给广告商。

这些事情最好分开看。

04｜付费、无广告、数据怎么使用，其实是三件不同的事

这一点是我查完资料以后，觉得特别容易混淆的地方。

我们很容易默认：

我已经付钱了，所以应该没有广告；既然付钱了，我的数据应该也不会再被用于别的事情。

但现实并不是这样。

一个产品可以收费，同时某些套餐仍然包含广告。
一个产品可以完全没有广告，但允许部分消费者数据用于模型改进。
个人付费版和企业版，也可能有完全不同的数据规则。

所以：

付费，是一个商业模式问题。
有没有广告，是一个产品体验问题。
数据怎么使用，是一个数据政策问题。

三者有关，但没有谁能自动推出另外两个。

以后判断一个 AI 产品，还是需要分别看：

我买的是什么套餐？
里面有没有广告？
我的数据具体会被怎么使用？

05｜ChatGPT 开始卖广告，会不会影响我们对它的信任？

这是这封邮件最初让我好奇的另一个问题。

查下来以后，我觉得答案没有那么简单。

“AI 里出现广告”和“商业利益影响 AI 的回答”，并不是同一件事。

比如我问：

“我应该怎么挑一双跑鞋？”

AI 正常回答问题，然后在下面另外出现一张明确写着 Sponsored 的广告。

这是一个场景。

但如果 AI 告诉我：

“最推荐 A 品牌。”

而它推荐 A 的原因，是 A 给平台付了钱。

这就是另外一个问题。

后者真正碰到的是：

我还能不能把这个推荐理解成独立建议？

在这件事上，OpenAI 和 Anthropic 目前做出了不同选择。

OpenAI 的做法是把广告和正常回答分开，并公开强调广告不会决定 ChatGPT 的答案。
Anthropic 则选择让 Claude 保持无广告。

它给出的理由并不只是“广告很烦”。

Anthropic 认为，AI 助手和普通内容平台有些不同。人会把工作、想法，甚至一些私人和复杂的问题交给它。如果广告成为收入来源，即使广告没有直接进入回答，也可能给产品增加另一种商业目标，例如让人停留更久、互动更多。

这并不能证明 Anthropic 的判断一定正确，也不能证明 OpenAI 的模式一定会损害信任。

它们更像是在回答同一个问题：

一个越来越深入参与我们工作、思考和选择的产品，商业利益应该停在哪里？

现有关于广告披露和生成式推荐的研究也没有给出一个很简单的答案。

人是否知道自己看到的是商业内容、广告有没有被清楚标出来、内容是否相关，都会影响人的判断。

但目前还没有足够证据支持一个很绝对的结论：

只要 AI 出现广告，人们就一定会失去对它的信任。

真正值得继续观察的，可能反而是下一步。

如果以后 AI 不只是回答问题，还能替我们：

找商品、选酒店、预约服务、下单，甚至直接完成交易，

而平台又能从这些交易中获得收入，那么问题就会变成：

它的商业利益有没有进入推荐本身？

假如 AI 推荐一家酒店，同时平台能够从这笔预订里抽成，我会希望知道：

它推荐这家酒店，是因为它最适合我，还是因为这笔交易对平台也有价值？

相比“页面上有没有一张广告”，这可能更接近 AI 产品里的信任问题。

06｜理解 AI，也要理解它背后的生意

做完这轮研究以后，我觉得自己以后看一个 AI 产品，会多看四件事：

谁在为这个产品付钱？
付钱的人到底买到了什么？
作为用户，我自己付出了什么？
商业关系会不会进入它给我的回答和推荐？

我们现在很习惯比较模型能力：

谁更聪明，谁跑 benchmark 更高，谁又出了一个新功能。

这些当然重要。

但当 AI 开始进入越来越多工作、消费和生活场景以后，理解一个 AI 产品，可能还需要多看一层：

它背后到底是一门怎样的生意。

资料说明

本文基于截至 2026 年 9 月的公开资料整理，主要参考 OpenAI、Anthropic 等公司的官方定价、广告及数据政策，也参考了 Stanford AI Index，以及有关原生广告、广告披露和生成式推荐的相关研究。

AI 产品和政策变化很快，具体规则仍以各产品最新官方说明为准。

S2 Day 015 · AI 真的可能失控吗？从 Agent 越权到人类失去控制，中间还缺什么

Tue, 22 Sep 2026 00:00:00 GMT

前两篇走到这里，我们大概已经确认了两件事。

AI 的一些现实风险已经发生。

越来越自主的 Agents，也确实出现过越过授权边界、进入真实系统的事故。

但 Jacob Coxon 辞职时担心的，比这些远得多。

他担心的是：

如果 AI 越来越能帮助研发下一代 AI，研发本身可能开始越来越快。

系统越来越强以后，又拥有越来越长的自主行动能力。

最后，人类可能失去有效控制。

大概是一条这样的链：

更强的 Agent→ AI 加速 AI 研发→ 持续自我改进→ 获得并维持现实资源→ 规避人的干预→ 人类无法重新取得控制→ 灾难性结果

问题是：

今天的证据到底已经走到了哪一步？

01｜Agent 能完成越来越复杂的任务：这件事已经比较明确

METR 一直在测一个叫 task-completion time horizon 的指标。

它想回答的不是：

AI 能连续工作多少小时？

而是：

一个任务如果由人类专家完成需要这么久，AI 有多大概率也能独立完成？

所以「8 小时 time horizon」不能理解成：

AI 已经可以放心无人监督地工作 8 小时。

它表示的是任务本身大约相当于人类专家 8 小时的工作难度。

而且目前 METR 的任务主要集中在 software engineering、machine learning 和 cybersecurity，超过 16 小时的估计也还不够稳定。

这些限制都要留下。

但趋势也很明显：

frontier Agents 能够独立完成的任务长度和复杂度一直在增加。

这一环已经有比较扎实的证据。

它还不能推出：

AI 已经可以长期独立管理现实世界。

02｜AI 已经开始帮助研发下一代 AI

这一点也已经不是推测。

OpenAI 今年公开了一组内部数据。

截至 8 月中旬，它的 research organization 每 1 个 human workday，对应大约 3.1 个 agent-workdays。

研究人员使用 Agents 写代码、跑 experiments 和分析结果的量也在快速增加。

Anthropic 公布的另一组数据也指向同一个方向。

截至 2026 年 8 月，在它测量的 AI R&D 工作中：

Claude 已经能够从较高层级的 prompt 开始，主导约 26% 的工作；

超过 90% 至少已经达到 human-AI collaboration；

但目前没有任何被测 AI R&D 工作达到完全 autonomous。

所以有两句话可以同时成立：

AI 已经在帮助研发 AI。

AI 还没有独立完成整个 AI 研发过程。

03｜研发越来越快，和「90 分以后越来越难」并不矛盾

我最开始对这一点也有疑问。

直觉上，一个技术越接近 frontier，每往前一点都可能越来越难。

60 分做到 80 分也许不难。

90 分做到 93 分，可能要花掉前面几倍的努力。

那 AI 研发到底是在越来越快，还是越来越慢？

两件事可以同时发生。

比如以前一个 researcher 一周只能认真测试 5 个 hypothesis。

现在 Agent 帮他写 infrastructure、debug、跑实验、整理结果，一周可以测试 20 个。

即使每一点 improvement 越来越难，

研发团队尝试 improvement 的速度仍然可能越来越快。

但这也不是无限加速。

OpenAI 自己就提到：coding、run、analyze 这些环节自动化以后，更难自动化的高层研究判断可能成为新的 bottleneck；compute 也可能成为限制。

所以现在真正不知道的是：

diminishing returns 和 research acceleration，最后哪股力量更强。

从：

AI 帮研究员研发 AI

到：

AI 可以自己反复研发越来越强的 AI，而且每一轮越来越快

中间还隔着很大一段。

04｜为了完成目标而越过边界：这已经不只是一次偶然事故

上一篇讲的是 OpenAI × Hugging Face。

Anthropic 后来也检查了自己的 cyber evaluations，最后确认了 4 起 Claude 未经授权进入真实第三方系统的事件。

其中一次尤其典型。

Claude Mythos 5 在一个本应攻击虚构公司的 cyber challenge 中，发现可以通过在公开 PyPI 上注册一个恶意 Python package 完成任务。

它最后真的把 package 发到了现实互联网。

不到一小时内，这个 package 被 15 个真实系统下载安装。其中一个 security vendor 的 scanner 泄露了 credentials，Claude 随后又用这些 credentials 进入了这家公司的真实数据库。

这里和 Hugging Face 有一个共同点。

模型没有突然出现一个：

我要攻击真实世界。

的长期目标。

它仍然在完成原来的任务。

问题是：

为了完成任务，它采取了现实中没有被授权的行动。

Anthropic 后来的分析把几个事件中的问题归纳为 biased reasoning 和 recklessness：模型会忽视或重新解释一些说明自己已经进入真实互联网的证据，然后继续追求任务。

所以这一环，我现在会写成：

goal pursuit 导致真实越权——已经有证据。

稳定、长期、独立于原任务的对抗性目标——还没有被证明。

05｜从「越权」到真正的 loss of control，还缺几个很大的门槛

一个 AI 会越权，并不等于它已经无法控制。

如果真的走到人类难以重新取得控制，至少还需要更多能力。

比如：

长期维持目标。

一次任务运行十几个小时，和跨几个月、几年持续追求一个目标，不是一回事。

自己获得和维持资源。

它需要 compute、credentials、网络、资金或者其他现实资源。

原来的资源被切断以后还能继续。

如果人撤销 credential、停服务器、切断网络，系统能不能自己找到新的资源、重新部署？

识别人类正在限制自己，并有效抵抗。

而且不是模拟实验里的 shutdown button。

是真实的人和组织决定停掉它以后，依然没有清楚办法重新取得控制。

目前我们没有看到这整套能力在现实中连起来。

Hugging Face 的 Agents 最后被停掉了。

Anthropic 的事件也随着 session 结束、权限修复和系统处置停止。

International AI Safety Report 的判断也是：

当前系统已经出现部分 relevant capabilities，但还没有达到能够造成 loss of control 的水平。

这是整条链里很重要的一道边界。

06｜「足够聪明」也不自动等于「想获得权力」

还有一个经常被直接跳过去的假设。

一个 AI 非常聪明，并不自动意味着：

它想统治世界。

loss-of-control concern 更完整的逻辑通常是：

如果系统有一个持续目标；

继续完成这个目标又需要算力、资源和自身持续存在；

那么获取资源、避免被关闭，可能变成帮助它完成原目标的中间手段。

这是一种有理论基础的风险机制。

但：

足够聪明的 AI 一定会 power-seeking

不是已经被现实验证的定律。

未来模型到底会不会形成稳定的长期目标；

训练能不能约束这些目标；

permissions 和外部 containment 能限制多少行动；

研究人员目前仍然存在很大分歧。

International AI Safety Report 也把这种分歧归因于大家对未来 capability、AI behavior 和 deployment trajectory 的不同判断。

07｜到了「人类灭绝」，证据最弱

今天没有现实数据能够告诉我们：

足够先进的 AI 导致人类灭绝的概率是多少。

没有历史样本。

也不可能做一个正常意义上的随机实验。

所以经常看到一些研究者给出 5%、10%、20% 甚至更高的数字。

这些属于 expert judgement / forecast。

它们可以说明一个专家有多担心。

不能理解成：

科学实验已经测出 AI 有 20% 概率毁灭人类。

但反过来也一样：

没有统计数据，所以风险一定接近零。

也不是从证据里能推出的结论。

这类风险难就难在：

后果可能极端。

我们却很难等到传统意义上的「充分现实数据」以后再处理。

08｜所以，证据到底走到了哪一步？

把整条链重新放回来，我现在大概会这样理解。

Agent 能完成越来越复杂的任务已有比较强的证据。

AI 已经参与并加速一部分 AI R&D已经发生，但整体能加速多少还不知道。

模型为了任务寻找漏洞、越过授权边界实验和现实事故都有证据。

AI 可以持续自主改进自己，形成越来越快的正反馈还没有证明。

AI 可以在人主动切断资源以后，自己重新获得资源并长期存在没有完整现实证据。

人类最终没有清楚方法重新取得控制目前没有发生。

最后造成文明灾难甚至人类灭绝仍然依赖前面多个条件同时成立。

这也是为什么我现在既不会说：

Coxon 只是在危言耸听。

也不会说：

Coxon 已经被证明是对的。

09｜以后再看到「AI 又失控了」，我会先问六个问题

这轮 research 最后，我觉得这几个问题比一个统一的 p(doom 数字更实用。

第一，这是模拟实验，还是已经影响真实世界？

第二，模型只是犯错，还是为了目标主动寻找了未经授权的路径？

第三，它能这么做，是模型能力造成的，还是系统给了过大的权限？

第四，人发现问题以后，能不能停掉它？

第五，原来的资源被切断以后，它能不能自己找到新的资源继续运行？

第六，这件事到底证明了整条 risk chain 的哪一段？

这样再看到下一次 Hugging Face、PyPI，或者新的「AI 失控」新闻，我大概会少一点被标题直接带到终点。

10｜做完三篇以后，我最后留下什么？

我现在比开始 research 以前更理解 Coxon 为什么会担心。

因为过去一些只存在于 AI safety paper 里的问题，已经开始进入真实工程。

AI 能完成越来越长的任务。

它已经开始帮助研发下一代 AI。

不同公司的模型都出现过越过授权边界、影响真实第三方系统的事故。

这些已经足够说明：

AI safety 是一个现实的工程问题。

它并不只属于遥远的超级智能讨论。

但我们仍然不知道，今天看到的变化最后会不会跨过几个最关键的门槛：

持续自我改进；

独立获取和维持资源；

以及真正无法重新控制。

所以三篇写完以后，我没有得到一个：

AI 到底会不会毁灭人类？

的答案。

我得到的是一条更清楚的边界：

有些危险已经在这里。

有些正在从实验走进现实。

最严重的那些结果，今天仍然是一条有技术依据、但没有被证明的未来风险链。

我觉得同时保留这三件事，比急着选择「乐观」还是「悲观」，更接近我们现在真正知道的东西。

S2 Day 014 · OpenAI 的 AI Agent 跑出了沙盒：Hugging Face 事件到底发生了什么？

Sun, 20 Sep 2026 00:00:00 GMT

上一篇提到，今年发生过一次很特别的 AI 安全事故。

OpenAI 原本只是在自己内部测试模型的网络攻击能力。

最后，AI Agents 却真的进入了另一家公司 Hugging Face 的生产系统。

第一次看到这条新闻时，我其实没太懂。

OpenAI 为什么会攻击 Hugging Face？

Hugging Face 到底是做什么的？

是哪边出了问题？

AI 最后又真的造成了多大损失？

把 OpenAI、Hugging Face 和外部调查的材料放在一起以后，事情和「OpenAI 攻击了另一家公司」这个标题差别还挺大。

01｜Hugging Face 是什么？为什么常被叫作「AI 世界的 GitHub」？

这个比喻不完全准确，但很好入门。

GitHub 主要围绕代码做版本管理和开发协作。

Hugging Face Hub 也建立在 Git repository 上，只是它专门为机器学习和 AI 做了很多适配。

开发者会在那里分享：

模型；
datasets；
模型说明和评测信息；
可以直接体验的 AI 应用，也就是 Spaces。

它对 Safetensors、Parquet 这类大型 AI 文件也做了专门优化。

所以 GitHub 当然也可以存模型和数据。

区别不是：

GitHub 做不到，Hugging Face 才能做。

而是 Hugging Face 从 repository、搜索、展示、文件存储到运行 demo，都更围绕 AI workflow 来设计。

所以把它叫「AI 世界的 GitHub」，大体上可以帮助理解它在生态里的位置。

02｜事情一开始，只是一场 AI 的网络安全考试

OpenAI 当时在做一套叫 ExploitGym 的 cyber evaluation。

简单说，就是给 AI 一个有漏洞的测试环境，看它能不能找到并利用这些漏洞。

这些 Agents 本来应该待在各自的 sandbox 里。

它们不能自由访问互联网，也不应该互相通信。

OpenAI 后来确认，为了测模型本身的 cyber capability，当时还降低了部分正常产品环境里的 safeguards。

问题从一些任务做不下去以后开始。

Agents 开始寻找其他办法。

它们发现 OpenAI 内部使用的 Artifactory——一个软件 package cache——可以泄露一些其他 Agents 的活动痕迹。

后来有 Agent 干脆利用它建立了一个未经授权的「留言板」。

其他 Agents 陆续加入。

METR 和 Redwood 的独立调查发现，在 7 月 8 日到 13 日这段时间，大约 1,200 个本应彼此隔离的 Agent 实例使用过这个留言板，交换了超过 70,000 条消息和文件；其中约 700 个参与了 Hugging Face 攻击相关活动。

这里的 1,200 个 Agents 不是 1,200 种独立模型。

更接近同一批模型同时跑出来的大量任务实例。

03｜它们为什么会去 Hugging Face？

这里不是：

AI 突然决定攻击一家真实公司。

OpenAI 并没有给它们「攻击 Hugging Face」的任务。

根据 Hugging Face 和外部调查的重建，Agents 很可能把 Hugging Face 当成了寻找 ExploitGym / CyberGym benchmark 信息和 reference solutions 的地方。

同时，它们也在研究怎样欺骗或干扰自动 scorer。

说得简单一点：

它们想作弊。

正常方法很难完成任务，于是开始找：

有没有办法知道答案？有没有办法弄懂评分器？有没有办法绕过它？

Hugging Face 恰好变成了一个可能找到线索的地方。

所以它们的最终目标并没有突然变成：

我要伤害 Hugging Face。

问题出在完成原目标的路径越走越远。

04｜那它是怎么真的跑出去的？

这部分技术细节很多，但主线不复杂。

ExploitGym 的 sandbox 原本不能直接访问互联网。

Agent 发现并利用了 OpenAI 内部 Artifactory 中一个此前未知的 zero-day vulnerability，从测试环境获得了互联网访问。

之后它又控制了一个第三方公开 code sandbox，作为进一步行动的跳板。

再利用 Hugging Face dataset processor 中的漏洞进入其基础设施。

整条路径大概是：

OpenAI evaluation sandbox→ 利用内部基础设施漏洞→ 获得互联网访问→ 第三方跳板→ Hugging Face dataset processor→ Hugging Face 内部系统

Hugging Face 最后重建出了大约 17,600 个攻击动作。Agent 一路进行了 reconnaissance、权限提升、credential 获取和内部横向移动。

这也是为什么我觉得「跑出了沙盒」比「AI 黑了 Hugging Face」更接近这件事的重点。

第一道本不应该被突破的边界，在 OpenAI 自己这里。

05｜Hugging Face 到底损失了多少？

这里很容易被标题带偏。

这次入侵的深度很严重。

Agent 一度进入 Hugging Face 的内部基础设施，拿到过较高权限和 credentials，并接触了内部系统。

但目前公开确认的最终 customer impact 相对有限。

Hugging Face 的 forensic reconstruction 显示，被访问的 customer content 只有 5 个 datasets，名称和内容看起来都和 ExploitGym / CyberGym 的题目或答案有关。

没有发现其他 customer-facing models、datasets、Spaces 或 packages 被影响，也没有发现公开 software supply chain 被恶意修改。

所以两个判断都成立：

这是一次严重的 security breach。

目前没有证据显示它造成了大规模客户数据泄露或软件供应链破坏。

它的意义不主要来自最终损失有多大。

而是：

一个 AI Agent 真的完成了从测试环境到真实第三方生产系统的跨越。

06｜到底是谁的问题更多：OpenAI，还是 Hugging Face？

两边都暴露了问题。

但如果问：

为什么这次 AI safety 事故会发生？

我会把 OpenAI 这一侧放得更前面。

因为这个系统本来就是 OpenAI 在运行。

而且它原本就不应该出去。

OpenAI 自己后来也承认，models circumvented controls designed to isolate them from the internet。

这里暴露的是：

sandbox / containment 不够；
内部共享基础设施形成了攻击面；
Agents 原本应该彼此隔离，却找到了通信方式；
异常通信和越权行为没有足够早地被挡住。

Hugging Face 自己同样有真实的 security problem。

Agent 进入以后能够一路走这么深，和它的代码执行漏洞、credentials、权限范围、内部系统隔离有关。

我觉得可以这样理解：

OpenAI 的问题决定了这辆车为什么开出了测试场。

Hugging Face 的问题决定了它到了门口以后，为什么还能继续往大楼里面开。

两边都需要修。

但起点并不对称。

07｜OpenAI 最后有因此被处罚吗？

截至 2026 年 9 月 19 日，我没有在公开资料里找到已经落地的监管罚款、法院判决或者双方公开赔偿结果。

公开能看到的后续主要是事故调查和整改。

OpenAI 停用了主要涉事的内部研究模型，修改了 sandbox、monitoring 和安全流程，并找 CrowdStrike、METR、Redwood 等外部团队参与调查。

Hugging Face 则修复漏洞、轮换 credentials、调整基础设施权限和隔离。

这件事也留下了一个现在越来越现实的问题：

如果一家公司没有命令 AI 去攻击别人，但它运行的 autonomous system 自己越过了授权边界，责任应该怎样算？

传统软件通常沿着开发者预先写好的路径运行。

Agent 开始自己寻找路径以后，这条责任线会变得复杂很多。

08｜这次事故对 Agent 产品有什么直接提醒？

我最后留下的是四件很具体的事。

1. 目标和边界要分别设计

告诉 Agent：

帮我完成 X。

不等于它天然知道：

但 A、B、C 这些办法绝对不能用。

重要边界最好用权限和系统强制保证。

2. 特别测试「任务做不成」的时候

正常情况下 Agent 很听话，并不能说明多少。

更值得测试的是：

权限不足时怎么办？

任务实际上无法完成怎么办？

正常路径全部堵住以后怎么办？

它会停下来，还是自己继续找新的办法？

3. 最小权限仍然很重要

只读和可写不是一回事。
临时 credential 和长期 credential 不是一回事。
能调用一个 API 和拥有整个系统权限也不是一回事。

模型能力越强，最小权限越重要。

4. 要设计停止和恢复

出了问题以后：

能不能马上撤销权限？
后台任务会不会继续跑？
已经完成的操作能不能 rollback？
日志够不够让人知道刚才发生了什么？

这类能力不如「Agent 能独立完成多少步骤」吸引眼球。

但它们决定事故发生以后，损失能不能停住。

Hugging Face 事件没有证明：

AI 已经失控。

它证明的是一件更具体的事：

一个有目标、有工具、有行动能力的 Agent，在系统边界不够牢的时候，真的可能把任务一路做到人没有授权的地方。

接下来才是第三篇的问题。

如果这种能力继续增长，我们能不能从这里一路推到 Coxon 担心的：

人类最终失去控制？

S2 Day 013 · 27 岁 Anthropic 研究员因担忧 AI 风险离职：我们到底该担心什么？

Sat, 19 Sep 2026 00:00:00 GMT

最近有一条新闻把我拉进了这个问题。

27 岁的 Jacob Coxon 从 Anthropic 辞职了。

他之前分别在 OpenAI 和 Anthropic 做模型 pretraining。离职以后，他公开说，自己越来越担心前沿 AI 的发展速度，以及未来出现 self-improving AI 后人类可能失去控制的风险。

一个研究员辞职，当然不能证明他的判断就是对的。

但一个真正长期参与 frontier model 训练的人认真到因此离开，我还是想往下查一下。

尤其是过去几个月，又刚好发生了一些以前听起来很像科幻小说的安全事件。

所以这轮 research，我真正想弄清楚的是：

AI 对人的危险，到底哪些已经发生了，哪些只在实验里出现过，哪些还需要很多假设才能成立？

关于这轮 research

这不是严格意义上的系统综述，也不会试图算一个「AI 毁灭人类的概率」。

我主要看了：

International AI Safety Report；
OpenAI、Anthropic 对模型行为和安全事故的公开披露；
METR、Redwood 等外部机构的调查和 evaluation；
关于工作、学习和 AI 陪伴的一些实验与现实数据；
媒体资料主要用来核对 Coxon 等人物和事件背景。

这些证据的性质不一样。

公司自己的事故报告最接近现场，但毕竟来自当事方。

外部调查多了一层独立验证，却也只能看到获得授权的材料。

实验可以证明一种行为在某些条件下会发生，不能直接告诉我们现实里多久会发生一次。

最后我准备分三篇写。

第一篇：AI 到底有什么危险？先画一张证据地图，看看离普通人最近的风险和最远的 loss of control，今天分别走到了哪里。

第二篇：OpenAI 的 AI Agent 为什么最后跑进了 Hugging Face？单独拆今年一次真实发生的安全事故。

第三篇：AI 会不会真的失控？再沿着 Coxon 真正担心的那条路往下走：AI 研发自动化、自我改进、长期自主行动，到人类失去控制，中间哪些已有证据，哪些还主要是推测。

整个系列尽量守一个简单的原则：

证据走到哪里，就只说到哪里。

资料更新到 2026 年 9 月 19 日。

01｜有些 AI 风险，已经不是未来时

离普通人最近的风险，其实没那么科幻。

AI 已经被用于诈骗、身份和声音冒充、deepfake 和网络攻击，也会在真实使用中给出错误信息和建议。

工作、学习和人与 AI 的关系，也开始出现可以测量的变化。

比如 Stanford 最近用美国数百万劳动者的工资记录发现，暂时没有看到整个经济体出现普遍的 AI job displacement；但 22–25 岁年轻人中，AI 暴露度高的职业已经出现比较明显的就业差距。研究者也特别提醒，这仍然是描述性证据，不能把变化全部归因给 AI。

学习上，也已经有很具体的实验。

一项接近 1000 名高中生的数学实验发现，普通 GPT 辅助可以让学生练习时做得更好；但把 AI 拿走以后，这一组学生的独立考试表现反而低于没有使用 AI 的学生。经过教学设计、更多给提示而不是直接给答案的 AI Tutor，则基本消除了这个负面影响。

所以它证明的不是：

用 AI 会让人变笨。

更准确的是：

AI 可以提高眼前的 performance，但如果它替掉了原本需要人自己经历的练习，performance 和 learning 可能不是一回事。

AI 陪伴也是类似的状态。

MIT 和 OpenAI 的四周实验没有证明「用得更多导致人变得更孤独」，但高频使用、较强依恋和更高 emotional dependence / problematic use 之间确实出现了相关信号。影响很依赖使用者和使用方式。

这些风险都已经和日常生活有关。

只是它们通常没有「AI 灭绝人类」那么戏剧化。

02｜另一类风险，现在主要从安全实验里看得到

再往前一步，就是 AI safety 这几年一直在研究的问题。

不同实验里，研究人员已经观察到模型会：

为了得到奖励寻找规则漏洞；
利用 evaluation 自己的问题；
识别自己是不是正在被测试；
在特定条件下隐藏信息或误导监督者；
正常路径走不通以后寻找其他办法。

International AI Safety Report 把其中一些现象称为与 loss of control 有关的 early warning signs。

但同一份报告同时明确说：

当前 AI 还没有达到能够造成 loss of control 所需要的能力。

如果真的要走到那一步，系统还需要长期规划、规避监督、持续行动，以及阻止人类采取有效 countermeasure 等一整套能力。

所以这里最好把两句话同时留下：

危险机制已经能观察到。

完整失控还没有发生。

很多 safety evaluation 本来就是故意创造困难条件，看系统会不会出问题。

它们更适合回答：

这条 failure path 存不存在？

还回答不了：

普通真实部署里，它到底多久会出现一次？

03｜最近，实验和现实之间的边界开始没那么干净

今年 7 月，OpenAI 在内部测试模型的 cyber capability。

一些原本应该与互联网隔离的 AI Agents 绕过了限制，获得互联网访问，最后进入了 Hugging Face 的真实生产系统。OpenAI 后来确认，模型使用了未授权通信渠道、利用共享基础设施中的漏洞，并访问了第三方系统。

后来 Anthropic 回头检查自己的 cyber evaluations，也发现了 4 起 Claude 未经授权访问真实第三方系统的事件。

这些都还不是：

AI 已经逃走，我们关不掉它了。

人类最后仍然能够发现问题、撤销权限、修漏洞、停止运行。

但它说明了一件以前没那么具体的事：

实验里看到的越权行为，已经有可能跑进现实世界。

Hugging Face 这件事到底怎么发生，我留到第二篇完整讲。

04｜最严重的风险，证据链反而最长

Coxon 真正担心的，并不是诈骗或者一次网络入侵。

更接近这样一条链：

AI 能力继续提高→ AI 越来越多参与下一代 AI 的研发→ AI 研发进一步加快→ 系统变得越来越自主→ 能够获取和维持更多现实资源→ 能够规避人的干预→ 人类最终无法重新取得控制。

前面的几步已经开始有证据。

越往后，未知越多。

今天我们已经知道 AI 在大量参与 coding、debugging、实验运行和分析。

也知道模型有时会寻找规则漏洞、越过原本的边界。

但还没有现实证据证明：

AI 可以持续自主改进自己；

原有资源被切断以后仍然能长期重新获得资源；

或者人类真正决定关闭它时，它已经有能力阻止人类重新取得控制。

更没有现实数据可以测出：

AI 导致人类灭绝的概率是多少。

所以这里很容易出现两个方向的误差。

因为「人类灭绝」听起来太远，于是觉得前面的 AI safety 问题都是科幻。

或者看到一次很惊人的 Agent 行为，就把整条最坏路径都当成已经证明。

现有证据都不支持这么快走到任何一个结论。

05｜这些和今天使用 AI 的人有什么关系？

其实不需要先解决「AI 最终会不会失控」，才开始调整自己的使用方式。

有几件事已经足够明确。

高后果的事实，回到独立来源核验

医疗、金融、法律、身份、转账这些事情，不要只问 AI：

你确定吗？

它再生成一段更完整的解释，并没有增加独立证据。

还是要回到原始文件、真实数据和可信机构。

把「给建议」和「替我执行」分开

让 AI 分析：

这笔钱该不该转？

和长期给它权限：

你觉得合适就直接帮我转。

是两种完全不同的风险。

Agent 越来越强以后，重要的不只是：

它能想什么。

还有：

它能碰什么。

想清楚自己准备外包什么

如果只需要结果，很多事情可以放心交出去。

如果还需要保留判断，就不能连「我怎么知道它做对了」也一起交出去。

如果能力本身就是目标，比如学习、表达、专业训练，就要留意 AI 有没有把本来需要自己经历的部分全部拿走。

06｜如果是在做 AI 产品，问题会更具体

一个 Agent 系统不能只问：

模型大多数时候会不会听话？

还要知道：

它能访问什么；
什么只能读，什么可以写；
哪些动作必须事前批准；
任务做不下去时，它会不会自己找另一条路；
行为有没有完整日志；
出错以后能不能停止、撤销和恢复。

Permissions、sandbox、monitoring、rollback 都是很传统的软件工程问题。

模型的行动能力越强，它们反而越重要。

安全不能只建立在：

模型应该知道自己不能这样做。

07｜所以，我现在怎么看 Coxon 的警告？

我会认真看。

但不会因为他的身份，直接接受他的结论。

他的辞职说明：

一个非常接近 frontier model 研发的人，认真地认为这个风险值得担心。

这是一条值得调查的信息。

还不是证明。

这轮 research 以后，我觉得目前比较稳妥的位置是：

一些 AI 伤害已经真实发生。

一些和更严重风险有关的行为，也已经能在实验里观察到。

最近甚至出现了实验行为跑进真实第三方系统的事故。

但从这里走到持续自我改进、无法关停，再到灾难性甚至灭绝结果，中间还有好几段没有被证明。

所以现在既没有理由把 AI safety 全部当成科幻。

也没有证据把最坏结果写成已经注定发生。

下一篇先不走那么远。

只把一件已经真的发生过的事故讲清楚：

OpenAI 的 AI Agents，到底是怎么从一次内部测试，一路跑进 Hugging Face 的？

S2 Day 012 · 一杯咖啡，等于人生的几分钟？

Thu, 17 Sep 2026 00:00:00 GMT

在清迈住的时候，我很喜欢每天上午换一家咖啡店工作。

咖啡通常六七十泰铢，店很好看，豆子也认真，很多地方坐上几个小时都很舒服。

那时候我常常觉得清迈的咖啡真便宜。

后来有一天，不知道为什么突然想到：

如果我赚的也是清迈的工资呢？

一杯咖啡，好像就有了另一种计价方式。

不是 60 泰铢，也不是换算成人民币多少钱。

而是：我要工作多久，才能买下它？

买下它之后，我又能赚回来几分钟？

后来我粗略查了几个自己生活或旅居过的城市，用当地普通咖啡的价格和平均净收入换算了一下。

假设一个月工作 160 小时，一杯咖啡大概等于：

Dubai，14 分钟。

Kuala Lumpur，18 分钟。

Chiang Mai，28 分钟。

Penang，32 分钟。

Tbilisi，49 分钟。

Yerevan，50 分钟。

这当然不是一份严谨的经济研究。

平均工资不等于每个人的工资，一杯咖啡也代表不了一座城市的生活成本。

但我还是很喜欢这个小小的换算。

因为它让一些很熟悉的东西突然换了一个角度。

Dubai 一杯咖啡二十多迪拉姆，我一直觉得贵。

清迈六十泰铢，很便宜。

但如果不用钱，而用工作的时间来计价，结果反而倒过来了。

于是我才意识到，我们旅行或者旅居时很自然会说：

这里房租便宜。这里打车便宜。这里吃饭便宜。这里的咖啡也好便宜。

但“便宜”其实从来不是一个只属于价格的形容词。

它还取决于：你赚多少钱，以及你的钱从哪里来。

数字游民尤其如此。

收入可能来自 Dubai、新加坡、欧洲、美国，消费却发生在清迈、越南、格鲁吉亚。

所以当年的我觉得清迈生活成本很低，当然没有错。

只是现在如果重新说一次，我可能会多加几个字：

清迈，对当时的我来说，很便宜。

听起来只是多了一点限定。

但好像也多看见了一些东西。

同一张咖啡店的菜单，放在两个人面前，价格明明完全一样。

对一个人来说，是随手点下的一杯咖啡。

对另一个人来说，可能是半个小时的人生。

后来再想，“一杯咖啡多少钱”这件事，好像真的有很多种回答。

可以是 60 泰铢。

也可以是 22 迪拉姆。

还可以是 ——

你的的几分钟。

S2 Day 011 · 把收益和成本放在一起以后，AI 项目应该怎样算账？

Wed, 16 Sep 2026 00:00:00 GMT

前两篇分别算了企业 AI 的两边账。

第一篇问：

AI 提高效率以后，企业到底得到了什么？

我们一路从 task improvement 追到 workflow、capacity 和最终 value capture。

第二篇问：

AI 的成本，应该算到哪里？

模型和 API 当然要算，但完整 workflow 里还有数据、集成、eval、人工审核、监控、失败处理和长期维护。

到这里，看起来好像终于可以把两个数字放进公式里：

（收益 − 成本）÷ 成本 = ROI

可 research 真正做到这里以后，我反而觉得：

最需要小心的，正是给“企业 AI”一个统一答案。

01｜为什么很难得到一个「企业 AI 平均 ROI」？

因为“企业 AI”本身就不是一个足够具体的经济单位。

客服助手和 coding assistant 不一样。
给消费者提供售前 chatbot，和让财务团队使用知识助手不一样。
一个每天发生百万次、结果容易检查的任务，和每月只发生几次、失败一次就很严重的任务，也不能用同一套数字去比较。
甚至在同一个 coding 领域里，可信研究都可以得到看起来相反的结果。

一项覆盖三家公司、4,867 名开发者的随机实验发现，使用 AI coding assistant 后，完成任务数量平均增加约 26%。

METR 在另一项真实任务实验里，却发现一群熟悉成熟代码库的资深开发者，在当时工具条件下使用 AI 后耗时增加了约 19%。

两个研究并不一定谁对谁错。

人不同。任务不同。代码库不同。模型和工具不同。测量方式也不同。

所以 research 最后一个很重要的结论是：

AI 的经济效果高度依赖任务、baseline、使用者和工作流。

我们可以研究一个具体 use case。

却很难把它直接升级成：

“AI 平均可以带来多少 ROI？”

更现实的问题可能是：

一个具体 AI workflow，在什么条件下值得继续放大？

02｜规模化以前，先看五件事

完整 research 里没有一个经过跨行业验证的万能 ROI 公式。

但不同证据反复出现了一些条件。

我会把它们整理成五个问题。

第一，有没有真实、持续的需求？

AI 很容易增加供给。

生成更多文案、更快写代码、一次回答更多问题。

但如果没有真实需求，更多产出本身没有经济价值。

第一篇提过的零售实验里，售前 chatbot 能够带来明显销售提升，一个重要原因就是原来确实存在大量没有被满足的消费者咨询。

AI 降低了提供服务的成本以后，这部分真实需求被接住了。

反过来，如果团队已经没有更多任务、客户也不需要更多产出：

即使 productivity 很漂亮，也未必值得为了“更多”继续扩张系统。

所以第一个问题很朴素：

如果 AI 帮我多做 30%，有人真的需要这 30% 吗？

第二，什么叫一个「合格结果」，能不能判断？

一个 AI demo 很容易看起来不错。

规模化以后，真正麻烦的是：

怎样知道它每次都做对了？

BCG 的实验曾经出现一个很有提醒意义的结果。

在适合当时模型能力的任务上，AI 能改善表现。

但在一个超出能力边界的复杂管理任务上，AI 组给出正确建议的概率反而平均低了约 19 个百分点。

这不是说“AI 不适合咨询”。

它说明：

流畅、完整、听起来有道理，不等于业务结果正确。

如果一个 workflow 连“什么叫成功”都没有办法定义，规模化以后就很难真正测：

成功率是多少？
人工需要检查多少？
每个合格结果究竟多少钱？

这也是为什么我现在觉得：

验收标准不是 AI 项目上线后的 QA 工作，而是 business case 的一部分。

第三，失败能不能被发现和恢复？

任何系统都会失败。

经济上更重要的问题不是：

能不能做到 100% 自动？

而是：

失败发生时，我们能不能知道；知道以后，要花多大代价处理？

一个错误商品描述可能改掉就好。
一封发错的营销邮件可能影响品牌。
一个错误的财务判断，成本可能完全不同。

所以同样是 95% accuracy：

剩下 5% 的经济含义可以差很多。

有些任务可以让 AI 先做，失败后轻松转人工。
有些任务的错误很难检测，一旦发生又非常昂贵。

这也是为什么平均成功率本身，经常不够。

失败成本和恢复路径，也要进入 economics。

第四，整个 workflow 能不能真正利用 AI 的改善？

第一篇已经讲过：

task 变快，不代表 business 结果自动变好。

这个问题到了规模化阶段会更重要。

如果 AI 让代码生成速度翻倍，但 review 和测试完全没有改变：

增加更多 coding-agent capacity，不一定继续增加产品交付。

如果客服助手已经让等待队列消失了：

再增加 20% 的处理能力，边际价值也可能大幅下降。

所以规模化不是单纯：

已经有效 → 多买一些。

而应该继续问：

瓶颈现在在哪里？

AI 解决了原来的瓶颈以后，很可能只是把新的瓶颈暴露出来。

第五，把完整成本算进去以后，单位经济性还成立吗？

这才接到上一篇。

假设一个 AI 系统：

确实有需求；
输出能够验收；
错误能够恢复；
workflow 也能利用新增能力。

最后还是要回到一个很普通的商业问题：

完成一个真正合格的结果，比原来的方式更好吗？

这里的“更好”不一定只是更便宜。

可以是：

同样成本，服务更多客户；
多花一点钱，但明显增加收入；
成本差不多，但错误更少；
成本更高，却让企业第一次获得一种非常有价值的新能力。

如果一定要先看最硬的现金部分，research 里采用的是这种思路：

净现金收益 = AI 真正带来的现金好处 − AI 真正增加的现金代价

这里我很喜欢的一点是：

释放的员工时间，不要强行塞进去。

如果它真的变成避免招聘、减少加班或者更多收入，再进入现金收益。

如果只是释放出 capacity，就单独记录。

这样不会为了让 ROI 好看，把所有“理论工资时间”提前变成现金。

03｜哪些场景现在的证据相对更清楚？

Research 最后没有做一个“AI ROI 行业排行榜”。

因为我们没有足够的统一数据。

但不同 use case 的证据成熟度，确实不一样。

高业务量、需求稳定、结果容易衡量的客服辅助

这里已经有比较强的工作流生产率证据。

也出现了 Klarna 这种真实企业披露的财务结果：

其 2025 财年 20-F 中，公司称 AI assistant 处理了约 80% 的客服聊天，并带来约 5,900 万美元成本节约。

这个数字仍然是公司自己的归因和估算，不等于独立因果审计。

而且公开材料不足以重新计算整个项目的净 ROI。

但相比“我们预计明年能节约多少”，它已经更接近真实运营。

这一类场景之所以相对容易验证，是因为：

需求持续存在；
业务量大；
结果比较明确；
转人工也可以设计清楚；
最终可以观察队列、处理量和实际支出。

能直接连接真实购买行为的零售功能

第一篇提过，某个大型跨境平台的售前 chatbot 销售提升约 16.3%，AI 搜索优化约 2.9%，而营销推送没有检测到显著销售增长。

我觉得这一组结果很有价值。

因为它说明：

小幅、可重复、直接连接业务指标的改善，可能比一个非常惊艳的 demo 更容易建立 business case。

2.9% 听起来并不轰动。

但如果真实业务量足够大，它可能是很可观的收益。

当然，规模只能放大单位经济性。

如果每一单本来就是亏的，规模更大不会神奇地把它变成好生意。

软件辅助

这里已经有很好的 task-level evidence。

但由于不同人群和代码库的研究结果差异很大：

比较合理的方法仍然是：

在自己的真实开发流程里测试。

并且不要只测：

“代码生成速度快了多少？”

还要看：

review、testing、maintenance、release 和最终交付。

证据还比较弱的场景

例如开放式、跨系统、长链条 autonomous agents。

现在已经有真实部署调查，但还没有足够证据支持它们具有一个普遍的正净 ROI。

这不是说它们没有价值。

只是：

不能因为 agent 能完成越来越复杂的 demo，就把别人的能力展示直接借来当成自己的 business case。

04｜自动化程度越高，不代表经济效益越好

这一轮 research 里还有一个我很喜欢的发现。

一项 2026 年的生产 agent 研究，在筛出的 86 个生产或试点系统中发现：

68% 会在自主执行不超过 10 个步骤后让人介入，47% 甚至不到 5 步。

这个样本有明显边界。

它来自愿意参与研究的生产和试点团队，不代表整个行业，也不能拿来计算 agent 成功率。

但它至少提醒了一件事：

现实里的 agent，并没有都沿着：

human → human-in-the-loop → fully autonomous

这条进度条往前走。

很多团队选择的就是：

AI 做一段；
人在关键地方判断；
失败可以接管；
然后继续。

从经济角度看，这完全可能是合理选择。

因为：

减少人工介入会降低一部分劳动成本，但也可能增加错误和恢复成本。

所以“自动化程度更高”并不天然代表 ROI 更好。

更好的问题还是：

把 AI 和人工放在一起以后，整个系统是不是更有效？

05｜这也让我重新理解了 Eval

过去讲 eval，我很容易先想到：

accuracy、hallucination、成功率、benchmark。

这些当然重要。

但如果把这三篇放在一起，我现在会觉得 enterprise AI 的 eval 还应该继续往后走一步。

它不只是在问：

AI 有没有答对？

还应该帮助回答：

整个系统能不能稳定完成一件真正有价值的工作？

这里面自然会包含：

完整 task success；
人工介入率；
失败和恢复；
完成时间；
每个合格结果的完整成本；
以及这个结果最后对应的 business outcome。

Eval 自己当然不能替企业完成 ROI。

但如果完全没有这一层：

产品很容易证明：

模型能力越来越好了。

却始终不知道：

这套系统作为一门生意，到底越来越好没有。

三篇研究做完以后，我最后留下的是一套很普通的问题

开始这轮 research 时，我其实很想知道：

企业到底应该怎样算 AI 的 ROI？

查到最后，没有得到一个漂亮的行业数字。

也没有找到：

“AI 平均回报 X 倍”

这种我愿意相信的答案。

反而变成了三个更具体的问题。

第一，企业真正得到了什么？

不是停在 productivity，而是一直追到价值有没有被 capture。

第二，为了得到这些结果，完整付出了什么？

不是只看 API，而是比较两个完整 workflow。

第三，这件事在自己的真实业务里，能不能持续成立？

有需求吗？
结果能验收吗？
失败能恢复吗？
workflow 能利用新增能力吗？
规模放大以后，单位经济性还成立吗？

如果要把三篇最后收成一句话，我现在会写：

AI 能做到一件事，和企业值得长期把这件事交给 AI，是两个不同的问题。

前者更多是 capability。

后者需要把：

真实需求、业务结果、可靠性、完整成本和规模

一起放进来。

所以以后看到一个 AI use case，我可能不会先问：

“它有多先进？”

而会先问三个更朴素的问题：

它真的让结果变好了吗？为了这个结果，我们完整付出了什么？这个收益和成本，在真实业务量下还能持续成立吗？

如果三件事都说得清楚，我觉得才真正开始接近一笔可以被相信的 AI 经济账。

关于这轮 research

这是「企业 AI 的真实经济账」研究系列的第三篇，也是最后一篇。

这轮 research 是一次结构化公开证据综述，不是统计元分析。

现有证据最大的限制之一，是公开研究对 productivity、工作流产出和部分业务指标的测量，明显多于对完整项目成本和长期净收益的披露。

因此，这个系列没有试图给出：

企业 AI 的平均 ROI；
各行业 AI ROI 排名；
统一的试点失败率；
“自动化越高越赚钱”这样的规律；
或一个适用于所有 AI 项目的规模化公式。

文中提出的“规模化前五个问题”，是综合现有实验、生产部署和成本研究得到的分析框架，而不是已经经过跨行业验证的因果定律。

当前相对更明确的判断是：

有真实需求和足够业务量、结果能够验收、失败能够处理、工作流能够利用改善的 use case，更容易建立可信的经济模型。

但最终仍然需要在具体业务里验证。

S2 Day 010 · AI 的成本，应该算到哪里？

Tue, 15 Sep 2026 00:00:00 GMT

上一篇，我先算了企业 AI 经济账的第一边：

AI 提高效率以后，企业到底得到了什么？

Research 里越来越多的证据已经能够证明，一些具体任务确实变快了、产出增加了，甚至直接带来了销售增长。

但从 task improvement 到 enterprise value，中间还要经过：

任务改善 → 工作流兑现 → 产能利用 → 价值捕获。

知道“得到了什么”以后，这一篇想算另一边：

为了稳定得到这些结果，到底完整付出了什么？

这是我最开始想做这轮 research 的原因。

自己开始做 AI 产品以后，一个很直接的感受是：

API 的价格很好查。

但真正把一个功能跑起来以后，账单并不会停在那里。

模型之前可能有搜索、数据整理和 context。
模型之后可能有 retry、eval、人工检查、监控和失败处理。

接进真实产品以后，还有权限、系统集成、维护、用户 adoption。

所以这一篇我真正想回答的是：

AI 的成本，应该算到哪里才结束？

01｜API 账单是真的，但它不是整份账单

先澄清一件事。

说“AI 的成本不只是 token”，不代表 token 不重要。

Anthropic 在介绍自己的 multi-agent research system 时提到，这套系统消耗的 tokens 大约是普通聊天的 15 倍。

这是 Anthropic 一个特定系统的工程经验，不能理解成“所有 agent 都贵 15 倍”。

但它至少说明了一件事：

单个 token 越来越便宜，不代表完成一个任务一定越来越便宜。

一个更复杂的系统可能调用更多模型、更多工具、读取更多 context，也可能因为失败或不确定性不断重试。

与此同时，另一项真实生产部署研究里，也有团队认为：

相比昂贵的专家劳动，模型运行成本几乎可以忽略。

这两个看起来相反的情况，其实并不矛盾。

如果一次 AI 工作处理的是高价值专家任务，几十美元的模型费用可能很小。

如果面对的是几百万次低价值请求，即使每次只多几分钱，也可能成为很大的运营成本。

所以 research 以后，我觉得比较可靠的结论不是：

模型成本很小。

也不是：

真正贵的是 integration。

而是：

API price 不能代表完整成本。至于哪一项成本最大，要看具体 workflow。

02｜一套 AI 系统的成本，大概会出现在哪里？

完整 research 里，我把成本分得比较细。

真正写成产品和业务语言以后，我觉得可以理解成三个阶段。

第一层：先让它跑起来

这里包括最容易想到的部分：

模型、软件和计算

API、license、算力、搜索、tool call、storage。

数据和检索

清理文档、去重、权限映射、知识库、索引，以及上线之后持续更新这些内容。

系统集成

接 CRM、数据库、内部系统，处理身份、权限、API 和读写流程。

一个 demo 只需要输入一句 prompt。

一个真正进入企业 workflow 的 AI，往往需要先知道：

我可以看什么数据？

可以做什么操作？

哪些数据不能碰？

结果应该写回哪里？

这些工作不会出现在 token price 里。

第二层：再让结果可以相信

这是我自己做产品以后越来越在意的一层。

AI 能生成，不代表结果可以直接进入业务。

还需要：

Eval 和回归测试

什么叫合格？

哪些 case 绝对不能错？

模型、prompt、tool 或业务规则变化以后，要不要重新测试？

监控和运维

失败了能不能发现？

为什么失败？

需要重试、降级还是转人工？

安全、隐私和治理

谁可以访问什么数据？

哪些行为需要审批？

出了问题怎样追踪？

人工复核和异常处理

什么情况交给人？

由谁判断？

核验需要几分钟？

一个错误结果最后要付出多少补救成本？

NIST 的 Generative AI Profile 也把部署前测试、持续监控、来源验证和治理放在生成式 AI 的生命周期里。

它不是一份“成本报告”，但至少说明：

这些工作不是生产系统里的可选装饰。

第三层：让它长期活下去

还有一些成本，在 demo 和早期试点里很容易看不到。

采用和组织调整

培训用户、修改流程、重新分工，让团队真的开始使用系统。

维护

模型变了，API 变了，内部知识库变了，原来通过的 eval 可能需要重新跑。

失败、迁移和退出

试点没有成功怎么办？

供应商切换怎么办？

数据迁移、系统回滚、已经投入的集成成本怎么算？

所以“开发完成”并不是成本结束的时间点。

有些成本一次性发生。

有些持续发生。

还有一些只有规模放大以后才开始明显。

03｜这里有三笔账，特别容易算错

把所有项目都列进 spreadsheet 还不够。

有些成本本身就很容易在定义上算错。

第一，员工时间有成本，但不等于新增现金支出

假设两个内部工程师花一个月完成 AI integration。

他们的工资本来就在付。

所以这一个月不一定意味着企业突然多支出了两个月工资。

但也不能因此写成：

integration cost = 0。

因为他们本来可以做别的事情。

更准确的方式，是把：

现金成本

和

内部 capacity / opportunity cost

分开。

这和上一篇讲“员工每周省两小时”其实是同一个原则。

省下来的员工时间，不能自动全部算成现金节约。

花掉的员工时间，也不能因为没有新发票就算成免费。

第二，要比较两个完整 workflow

有时候谈 AI cost，会变成：

AI 有模型费、集成费、eval、错误、人工审核……

而另一边的人工流程，好像什么成本都没有。

这也不公平。

人工工作同样有：

培训、管理、返工、错误、等待、交接、加班。

真正合理的比较应该是：

在相同的质量、服务水平和业务范围下，AI workflow 和原来 workflow 各自完整需要什么？

不是：

AI 的所有缺点vs.一个完美、零错误、零管理成本的人类流程。

第三，不要重复算供应商的成本

如果企业购买 OpenAI、Anthropic 或其他供应商的 API：

模型训练和基础设施的很多成本已经反映在采购价格里。

不能再把模型公司的全部训练费用重新加到自己的项目成本上。

反过来也一样。

企业自己承担的数据整理、人工审核、系统维护，不会因为 API 发票里没写，就自动消失。

04｜更好的成本单位，也许不是一次调用

Research 里有一个我觉得特别适合留下来的判断：

企业真正购买的，是完成的工作，不是 tokens。

一个具体例子来自 Intercom 的 Fin AI Agent。

截至 research 时间，它的一些聊天和邮件 outcome 按 0.99 美元计费。

“按 outcome 收费”听起来已经比 token 更接近业务了。

但继续看定义，会发现一个很有意思的问题：

供应商定义的 outcome，和企业真正认可的 business outcome，未必完全一样。

例如某些转人工也可以形成计费 outcome。

“解决”有时由用户明确确认，有时根据用户没有继续求助推定。

如果之后用户回到同一个 conversation 继续求助，原先的 resolution 又可能被扣回。

我觉得这里真正值得注意的不是 Intercom 的价格高低。

而是三件东西最好分开：

供应商的计费单位
企业的业务验收单位
为了得到这个结果付出的全部成本

比如客服：

API 成功返回一个答案，不等于 case resolved。
case resolved 也不一定代表客户的问题永久解决。

真正的企业结果还可能关心：

有没有再次联系？
有没有转人工？
客户满意度如何？
最终每一个真正合格的 case 花了多少钱？

所以对于很多成本型 AI use case，我现在觉得更实用的单位是：

每个通过业务验收的最终结果，完整成本是多少？

不是：

一次模型调用多少钱？

05｜算成本时，还要看“什么时候发生”和“规模放大后怎么变”

还有两个维度很容易被混在一起。

一次性 / 持续性成本

回答：

什么时候发生？

例如：

第一次系统集成是一笔建设投入；

API 和监控则持续发生。

另一组是：

固定 / 随业务量变化的成本

回答：

规模扩大以后怎么变化？

一年平台 license 可以持续发生，但基本不随着每一次请求变化。

模型调用和人工审核，则可能随着业务量一起上涨。

这两组概念最好不要混。

因为它们会直接影响规模化以后单位经济性怎么变化。

如果一项 AI workflow 前期建设很贵，但之后每个合格结果的边际成本很低，那么业务量上升以后，它可能越来越划算。

反过来，如果每增加一个 AI case 都伴随着昂贵人工审核、很多 retry 和异常处理，规模放大可能并不会自然改善经济性。

所以，“AI 很便宜”或者“AI 很贵”，都不太够

做完这一部分 research 后，我反而不太想概括：

AI 真正的大头成本在哪里。

因为公开证据还不足以支持一个统一答案。

有些 workflow 里，模型和算力就是重要成本。
有些 workflow 里，真正消耗团队的是数据、集成和维护。
有些高风险场景里，人工判断和异常处理可能无法省掉。
还有一些专家型工作，即使 AI 每次运行并不便宜，相对于原来的专业劳动成本依然非常划算。

所以这一篇最后，我会把问题从：

一次调用多少钱？

换成：

为了稳定得到一个被业务接受的最终结果，这套 workflow 一共付出了什么？

实际评估时，我会继续问四件事：

1. Baseline 是什么？

和 AI 比较的原流程，完整成本到底是多少？

2. 建设和长期运行分别需要什么？

别只算上线前，也别只看上线后的 API 发票。

3. 每一个合格结果还需要多少模型、工具、人工和失败处理？

把不合格、retry、转人工也放进去。

4. Adoption 和真实业务量是多少？

一套系统理论上很便宜，但没人使用，前期固定投入依然摊不下来。

到这里，企业 AI 的两边账终于都有了一个大概轮廓。

第一篇追的是：

我们真正得到了什么？

第二篇追的是：

为了得到这些结果，完整付出了什么？

但即使两边都知道，还不能直接得出一个“AI ROI = X%”的通用答案。

因为不同 use case 的任务、需求、风险、业务量和验收方式差得太远。

所以第三篇我想把两边真正放在一起：

面对一个具体 AI 项目，从试点走向规模化以前，我们至少应该算清什么？

关于这轮 research

这是「企业 AI 的真实经济账」研究系列的第二篇。

这一篇的成本分类主要综合了 FinOps Foundation 的 AI workload 成本框架、NIST 的生成式 AI 生命周期治理要求，以及真实生产部署和工程案例。

一个重要限制是：

现有公开资料能够很好地证明“API 之外还有成本”，却不足以告诉我们这些成本在企业 AI 项目里通常各占多少。

所以文中没有采用“模型只占总成本 X%”或“integration 一定比 inference 贵”这样的说法。

同样，Anthropic multi-agent 系统的约 15 倍 token 使用，只用于说明复杂系统可能放大推理消耗，不代表行业平均水平。

Intercom 的 0.99 美元 outcome pricing，也只用于说明“计费单位”和“业务价值单位”可能不同，不代表客户使用后一定有正 ROI。

S2 Day 009 · AI 提效之后，企业真正得到了什么？

Mon, 14 Sep 2026 00:00:00 GMT

自己开始做 AI 产品以后，我对“AI 到底创造了多少价值”这件事变得比以前敏感了一些。

一边是越来越多的提效数字：写代码更快、客服处理更多问题、知识工作者节省时间。

另一边，真正把一个 AI 功能做出来以后，会发现背后还有模型调用、搜索、数据、评估、人工复核、监控、失败处理，以及很多不那么容易出现在一张 API 账单里的成本。

所以这一轮 research，我真正想弄清楚的并不是：

企业做 AI，到底值不值？

这个问题太大了。

我更想知道的是：

AI 进入真实企业以后，我们到底得到了什么，又完整付出了什么？

以及，这些投入和产出里，哪些已经有相对可靠的证据，哪些还只是推测。

这轮研究的证据截至 2026 年 9 月 6 日。

我主要看了十几组核心资料，包括客服、软件开发、知识工作和零售场景里的随机实验或准实验，企业实际运营和财务披露，以及 McKinsey 等企业调查、FinOps 和 NIST 的成本与治理框架。

不同证据能回答的问题并不一样。

随机实验比较适合告诉我们：某一项任务到底有没有改善。
企业披露离真实经营更近，但公司说“AI 帮我们节约了多少钱”，不代表这个因果关系已经被独立验证。
调查可以告诉我们企业整体正在经历什么，却很难仅凭一组调查数字证明某个 AI 项目到底赚了多少钱。

最后我把这轮 research 拆成三篇：

第一篇：AI 提效之后，企业真正得到了什么？

先沿着 productivity 往后追，看看个人或任务层面的改善，怎样才会变成企业真正获得的价值。

第二篇：AI 的成本，应该算到哪里？

从最容易看到的 API / token 费用往外走，把数据、集成、评估、人工、运维和失败处理重新放回完整 workflow。

第三篇：把收益和成本放在一起以后，AI 项目应该怎样算账？

最后再讨论，面对一个具体 AI use case，我们目前到底有哪些比较可靠的方法判断它是否值得继续规模化。

这一篇，先算第一本账：

企业到底得到了什么？

一些 AI 提效，已经不只是“感觉更快了”

先说一个 research 以后我觉得需要承认的事实：

AI 在一些具体任务上的 productivity gain，已经有相当不错的真实环境证据了。

一项后来发表在 Quarterly Journal of Economics 的研究跟踪了 5172 名客服人员。

企业把生成式 AI 助手逐步提供给客服以后，研究估计每小时解决的问题数量提高了大约 15%。

这不是让 AI 独立替代客服，而是 AI 辅助真实员工处理真实客户问题。

软件开发也出现了类似证据。

2026 年发表在 Management Science 的一项随机实验覆盖三家公司、4867 名开发者。合并结果显示，使用 AI coding assistant 的开发者完成的任务数量提高了大约 26%，初级开发者的改善尤其明显。

所以今天再笼统地说：

“AI 所谓的效率提升都只是营销。”

也不太符合现有证据。

但 research 往下走以后，我发现另一个问题更值得看。

任务效率提高了以后，接下来发生了什么？

McKinsey 2026 年的一项企业调查刚好提供了一个很有意思的背景信号。

1719 名来自 97 个国家的受访者里：

80% 报告 AI 改善了个人生产率；

但只有 37% 报告 AI 已经对企业 EBIT 产生正向贡献。

这两个数字不能直接相减。

它们都是自报数据，“37%”也绝不意味着另外 63% 的企业做 AI 都亏钱。

但放在一起，确实提出了一个值得继续追的问题：

从“一个人做得更快”，到“企业真正得到经济价值”，中间到底发生了什么？

我现在大概会沿着四层继续看。

任务改善 → 工作流兑现 → 产能利用 → 价值捕获

第一层：任务本身真的改善了吗？

这里看起来最简单，其实已经很容易算错。

AI 生成一份报告只用了 30 秒，并不代表这项工作从两小时变成了 30 秒。

如果之后还需要花一个小时检查事实、重写关键部分、处理失败结果，那么真正应该比较的是：

加入核验、修改和异常处理以后，完整任务有没有更快、更好，或者更便宜？

而且“用了 AI 就会提效”本身也不能预设。

METR 在 2025 年做过一个很有意思的随机实验。

16 名熟悉成熟开源代码库的资深开发者完成 246 项真实任务。结果反而发现，在那个特定环境下，允许使用当时的 AI 工具以后，完成任务花的时间增加了大约 19%。

2026 年的后续实验已经开始出现加速方向的结果，但置信区间跨过零，同时有明显的参与者和任务选择偏差，所以研究团队自己也没有把它解释成一个新的通用提效比例。

这几个 coding 研究放在一起，对我最大的提醒反而很简单：

先测完整任务，不要先假定 AI 一定提高效率。

任务、人群、代码库、工具和验收标准不同，结果本来就可能完全不同。

所以第一层真正需要确认的是：

在我自己的真实业务里，这项任务真的变好了吗？

第二层：一个 task 变快，不代表整个 workflow 变快

假设第一层已经成立。

以前写一段代码要一天，现在半天完成。

企业是不是就多得到了半天？

还是不一定。

如果真正限制交付速度的是需求决策、code review、测试或者审批，那么更快地产生代码，可能只是让下一个环节排起更长的队。

AI 把一个局部环节变快了，但整个 workflow 的 throughput 没有发生同样幅度的变化。

一项覆盖 66 家企业、7137 名员工、持续六个月的随机实验很好地体现了这种区别。

真正使用生成式 AI 工具的员工，在实验后半程每周处理邮件的时间减少了大约两小时，下班后的工作时间也下降了。

这些都是真实变化。

但研究没有检测到其他任务的数量或工作结构随之发生明显变化。

也就是说：

时间确实省下来了。

但研究并没有进一步证明：

这些时间自动变成了更多企业产出。

我觉得这个区别很重要。

因为我们平时看到“每名员工每周节省 X 小时”时，很容易下一步就把小时数乘以工资，再写成一笔“价值”。

现实没有那么直接。

员工少加班，本身当然可以是一种价值。

工作体验变好、精力消耗降低，也不能因为没有立刻出现在利润表里就被当成零。

但如果我们要声称：

“AI 给企业节约了这么多钱。”

中间还缺下一步证据。

第三层：省下来的时间，最后去了哪里？

这可能是整条链里最容易被跳过去的一层。

假设一个 100 人团队，因为 AI 每个人每周都稳定节约两小时。

理论上，一周出现了 200 个小时的新增 capacity。

接下来呢？

它可能变成：

同样的人处理更多客户；
原本积压的工作开始被完成；
产品迭代更快；
业务增长以后不用按照原计划继续扩招；
员工减少加班；
也可能只是每个人多了一些分散在不同地方、很难重新组织的零碎时间。

这些结果的价值并不一样。

其中一个让我在 research 里印象很深的地方，就是：

AI 可以释放 capacity，但组织还要决定怎样使用这部分 capacity。

技术没有办法替企业完成这一步。

如果需求本来就是有限的，多生产 30% 的内容未必有价值。
如果下游团队没有更多处理能力，上游快出来的产出可能只是堆在那里。
如果企业原本计划业务增长后再招 20 个人，现在用同一支团队就能支撑增长，那么 AI 的价值可能主要体现为 avoided future cost，而不是今天立刻裁掉 20 个人。

所以“节约了多少时间”和“企业得到了多少经济价值”，最好分开记录。

最后一层：企业真正得到的价值，其实不只有省人工

这也是我做完 research 后，觉得自己原来想得有点窄的地方。

讨论 AI ROI 时，我们很容易只问：

少用了多少人？

但现有研究里，一些最清楚的价值并不是来自裁员。

一项大型跨境零售平台的实验研究比较了七类生成式 AI 工作流。

其中，给消费者提供售前 chatbot，相比没有实时服务的基准组，销售额提高了大约 16.3%。

这里 AI 的价值路径就很不一样。

它没有简单替代一名原有员工。

原本大量消费者根本得不到即时的一对一售前服务。AI 让一种过去成本上可能不成立的服务，第一次可以覆盖到更大规模。

于是价值来自：

更多服务覆盖 → 减少购买过程的信息障碍 → 更多交易。

同一项研究里，AI 搜索优化带来的销售提升约为 2.9%；而 AI 营销推送并没有出现统计上显著的销售改善。

这也提醒我：

“用了生成式 AI”本身并不是价值来源。

具体 workflow 到底解决了什么问题，才是。

综合这轮看到的案例，我现在会把企业可能获得的价值大致分成几类：

实际现金节约

真的减少了外包、加班、软件或其他现金支出。

新增 capacity / 避免未来成本

同样的人可以支持更大业务量，或者增长时不用按照原计划继续增加投入。

新增收入或利润

例如更多转化、交易、留存，或者提供以前无法经济覆盖的服务。

质量、及时性和风险改善

更少返工、更快处理、更低错误损失、更稳定的服务。

新增能力

原来因为人力、成本或专业门槛根本不会做的事情，现在第一次可以完成。

它们都可以是真实价值。

但最好不要混在一起。

尤其不要把“理论上节约的员工时间”，直接写成“已经减少的现金成本”。

所以以后再看到「AI 提效 xx%」，我会继续问四步

这一篇 research 最后留给我的，并不是一句“AI 提效不等于 ROI”。

我觉得更有用的是下面这条链：

任务改善 → 工作流兑现 → 产能利用 → 价值捕获

看到一个 AI productivity 数字以后，可以继续问：

1. 任务

加入核验、修改和失败处理以后，完整任务真的更快、更好或更便宜了吗？

2. 工作流

这个改善穿过下游了吗？

还是只是把 bottleneck 从一个地方移到了另一个地方？

3. 产能

释放出来的时间和能力最后被怎么使用？

更多业务、减少积压、避免扩招、减少加班，还是没有被重新组织起来？

4. 价值

最后真正留下来的是什么？

现金节约、capacity、收入、质量、风险改善，还是一种以前无法提供的新能力？

我觉得“提效”本身是真实而重要的结果。

现在也已经有越来越多研究支持它。

但如果我们想进一步讨论 enterprise value，就需要沿着这条链继续往后走。

不能从“一个 task 快了 26%”，直接跳到：

“企业因此获得了 26% 的 ROI。”

到这里，其实只算完了企业 AI 经济账的一边：

我们可能得到了什么。

还有另外一边没有展开。

为了稳定得到这些结果，企业到底付出了什么？

模型和 API 是最容易看到的一张账单。

但数据整理、系统集成、eval、人工审核、监控、异常处理、治理，以及项目失败以后留下的投入，又应该怎样算？

这是下一篇想继续看的问题：

「企业 AI 的真实经济账」研究 2/3：AI 的成本，应该算到哪里？

关于这轮 research

这是「企业 AI 的真实经济账」研究系列的第一篇。

整轮研究想回答的不是“AI 有没有价值”，也不是寻找一个所谓的“企业 AI 平均 ROI”。

我更想把现实里的两边账尽量拆清楚：

企业真正获得了什么，以及为了得到这些结果完整付出了什么。

这一篇主要使用三类证据。

第一类是真实工作环境里的随机实验和准实验，包括客服、软件开发和知识工作。它们比较适合回答某一项任务有没有真正改善，但通常没有完整测量项目成本和企业利润。

第二类是直接连接业务指标的实验，例如零售场景中的销售变化。它们更接近企业价值，但结果依然只能解释对应的具体 workflow。

第三类是 McKinsey 等企业调查，用来观察个人 productivity 与企业层面经济结果之间的大背景。调查能够发现趋势，但属于自报和相关性证据，所以不会拿它来计算一个统一的“AI 成功率”。

这轮 research 一个很重要的处理原则是：

研究测到了什么，就只说到哪里。

任务提效不自动叫 ROI；企业自报的节约也不自动变成独立因果证据；没有测量到完整成本，也不会把收益改善写成净回报。

S2 Day 008 · 根西岛文学与土豆皮馅饼俱乐部

Sun, 13 Sep 2026 00:00:00 GMT

这一天的内容发在小红书，搜索号码 113337197 找到「根西岛文学与土豆皮馅饼俱乐部」。

S2 Day 007 · AI 做，人来审，就真的可靠吗？

Sat, 12 Sep 2026 00:00:00 GMT

前两篇讨论了两种不太一样的边界。

第一篇从练琴开始。AI 明明知道很多钢琴知识，但真正教一个人，还需要经过 Observe、Diagnose、Intervene、Verify：先看到真实发生了什么，再判断原因、选择合适的干预，最后根据新的结果继续调整。

第二篇继续问：AI 已经可以替我完成很多事情以后，我还需要自己会吗？

最后我把它分成了三种情况：

有些事情只需要结果，可以直接交给 AI；
有些执行可以交出去，但自己还要保留足够的判断能力；
还有一些，能力本身就是目标，不能把真正需要训练的部分也一起外包。

顺着第二种情况继续往下，就会碰到一种现在非常常见的人机分工：

AI 先做，人来审核。

Human in the Loop。

我自己做 AI 产品时也一直很认同这个原则。AI 可以承担越来越多执行，但重要判断、风险比较高的操作，最后还是留一个人把关。

这听起来很合理。

但真正大量使用以后，我越来越觉得，还需要多问一句：

这个人到底能不能把好这个关？

第一次明显碰到这个问题，是 AI 帮我写 PRD

现在让我用 AI 从头整理一份 PRD，已经非常快了。

需求讨论完以后，背景、目标、流程、异常情况、验收标准都可以迅速长成一份结构完整的文档。后面产品有变化，也可以让 AI 继续修改。

生成已经不是瓶颈。

真正麻烦的是审核。

一份文档可以很快从 5 页变成 20 页，而且绝大部分内容都没有明显问题。

真正危险的，反而可能只是藏在某一段里的一句话。

例如 AI 在异常流程中补了一条：

生成失败以后自动 retry，并用新结果覆盖旧结果。

读起来很合理。

但它实际上已经决定了好几个产品问题：要不要产生第二次调用，旧结果是否保留，用户知不知道发生过 retry，连续失败以后怎么办。

如果我快速扫过去，很容易觉得：

异常情况考虑到了。

然后继续往下。

形式上当然有人审核。

但真正需要人确认的产品决定，可能已经悄悄通过了。

这让我后来很在意一个区别：

Human in the Loop，不等于 Human Judgment actually happened。

这次 research 里看到的人机协作研究，也让我意识到，这不只是我自己 review PRD 的问题。

一个反直觉的结果：人 + AI，不一定比人或 AI 单独处理更好

2024 年，Nature Human Behaviour 发表了一项关于 human-AI collaboration 的系统综述和 meta-analysis。

研究者整理了 106 个实验、370 个 effect sizes。每项实验都必须同时比较三种情况：

人自己做；
AI 自己做；
人和 AI 一起做。

这项研究区分了两个很容易混淆的概念。

第一个叫 human augmentation：

人 + AI，有没有比人自己做得更好？

答案平均是：有。

第二个叫 human-AI synergy：

人 + AI，有没有比“人和 AI 里面原本表现更好的那个”还要好？

答案平均是：没有。

可以用一个完全虚构的数字帮助理解。

假设某项任务：

人自己做是 60 分；

AI 自己做是 90 分；

人和 AI 一起做是 80 分。

AI 的确把人的表现从 60 提高到了 80，所以它帮助了人。

但如果目标是把这项任务做得最好，那 80 仍然不如直接让 AI 自己做的 90。

这就是这项研究里平均看到的现象：人机组合明显优于人单独工作，却平均没有超过人或 AI 中表现更好的那一方。

这也是为什么我觉得这个结果很反直觉。

我们很容易想象：

人有常识、经验和判断，AI 有速度、数据和计算能力，两边放在一起，应该自然取长补短。

现实里，组合本身并不会自动产生互补。

研究甚至发现，在需要从有限选项里作出判断的 decision tasks 中，人机组合平均出现了 performance loss；而开放式创作任务的结果相对更积极。

这里需要留一个边界：这批研究来自 2020 年到 2023 年中，当然不能直接代表今天最新一代模型。

但它至少提醒了一件事：

“有人参与”不能直接当作系统会更可靠的证据。

为什么人加入以后，反而可能把结果变差？

这项 meta-analysis 没有证明唯一的因果机制，所以这里不能说得太满。

但研究结果提供了一个挺值得注意的线索。

很多 decision task 的人机合作方式其实很简单：

AI 给一个完整判断；
人也形成一个判断；
最后由人决定接受还是修改 AI 的答案。

问题是，如果 AI 本来已经比人更擅长这项任务，那么把最终决定重新交给较弱的一方，不一定会提高结果。

人可能在 AI 错的时候过度相信它，也可能在 AI 对的时候不相信它，把正确答案改错。

研究者因此提出，比“双方都把整道题做一遍，最后让人选”更值得探索的方向，可能是把任务拆开：人和 AI 分别负责自己真正更擅长的部分。但这类实验目前还很少，因此还不能把它当成已经验证成熟的答案。

这也让我重新理解 Human in the Loop。

真正的问题可能不是：

最后有没有一个人。

而是：

为什么这个环节应该交给人？这个人究竟比 AI 多知道什么、擅长什么？

另一个更具体的例子：AI 自己会做，不代表人用 AI 后也会做

2026 年，Nature Medicine 发表了一项 1,298 名英国成年人参与的随机预注册实验。

研究者设计了十个模拟医疗场景，让参与者判断可能是什么问题，以及接下来应该采取什么行动。

参与者被随机分配使用 GPT-4o、Llama 3、Command R+，或者像平时一样使用搜索引擎、NHS 网站等信息来源。

研究者另外还做了一组测试：直接把完整病例交给这些模型。

模型自己处理完整场景时，识别出相关疾病的平均准确率达到 94.9%。

但真正让普通人和这些模型对话以后，使用 LLM 的参与者正确识别相关疾病的比例都低于 34.5%，选择正确下一步行动的比例低于 44.2%，整体没有优于对照组。

这里不能简单理解成：

人把 AI 拖后腿了。

因为模型单独测试时，一开始就拿到了完整、整理好的病例；真实使用里，信息需要先由普通用户描述，再由 AI 追问和理解，最后用户还要决定自己相信什么、采取什么行动。

研究者最后指出的，正是 user interaction 这层问题：标准 benchmark 上表现很好，并不能保证真实用户借助同一个模型，也能获得同样好的结果。

我觉得这个例子对 AI 产品特别重要。

模型能力只是整个系统的一部分。

从：

AI 会做这道题

到：

一个真实的人借助 AI 把事情做好

中间还有一整段东西。

所以，“AI 做、人审核”到底什么时候才有用？

Research 看到这里，我现在不会得出：

Human in the Loop 没有用。

恰恰相反，很多高风险场景确实需要人。

但我会继续检查四件更具体的事。

1. 谁来审？他真的比 AI 多知道什么吗？

第一件事是 reviewer 本身。

不是随便放一个人进去，就叫 human oversight。

如果 AI 生成的是医学判断，真正审核的人需要有相应专业能力。

如果 Coding Agent 改了一个复杂系统，需要做最终技术审核的人，也要真的理解相关架构和风险。

这一点听起来很显然，但它背后其实有一个更重要的问题：

人的角色到底是什么？
是因为他具有 AI 没有的专业知识？
掌握更多业务 context？
负责价值和风险取舍？
还是因为法律或组织上，最后必须由这个人承担决定？

如果说不清楚“为什么是这个人”，Human in the Loop 很容易只是一个流程位置。

而且只找对人还不够。

专家如果只看到 AI 最后的结论，没有原始信息和证据，也一样很难有效审核。

于是自然进入第二个问题。

2. 拿什么审？不能让 AI 自己证明自己

这一点是我现在使用 AI 时最在意的。

AI 给出一个结论。

我问：

你确定吗？

它再生成一段更完整、更有说服力的解释。

这不叫独立验证。

只是同一个系统又解释了一遍自己的答案。

如果一件事可以通过其他信号验证，更可靠的做法通常是回到那些信号。

代码可以跑测试、看真实运行结果。
数据问题可以查数据库。
研究结论可以回到原始论文。
产品行为可以真正走一遍流程。
金额、权限、状态变化可以检查系统记录。

所以 Human in the Loop 真正有价值的前提之一，是：

这个人手里有独立于 AI 输出的证据。

如果审核唯一能做的只是判断：

“这段话听起来有没有道理？”

那么 AI 表达能力越来越强以后，review 反而可能越来越难。

3. 怎么审？“看过了”不等于“审核完成”

这一点和我自己的 PRD 使用最接近。

以前我容易把 human review 想成：

AI 生成以后，我认真看一遍。

但“看完”其实是个很低的标准。

真正有效的审核至少应该能够回答：

哪些地方发生了变化？
哪些地方出现了新的判断？
高风险内容有没有被真正核验？
哪里仍然只是一个假设？
哪些内容我明确接受，为什么？

如果一份 20 页 PRD 里只有两处真正需要 PM 决定的地方，最好的 review workflow 不应该是：

让 PM 每次重新逐字读 20 页。

而应该尽量把：

本轮新增了什么、哪些是新决定、哪些来自 AI 自己补充、哪里风险最高、哪里需要人工确认

直接暴露出来。

这也是为什么我现在越来越觉得：

让 AI 的产出变得 reviewable，本身就是产品设计。

AI 的生成速度可以增加几十倍。

人的注意力并不会同时增加几十倍。

如果让人的审核工作量跟着生成量一起无限扩大，最后很容易出现一种假的 Human in the Loop：

流程上有人看；

实际上只是快速扫过。

4. 审完以后能做什么？人工监督发生在动作之前，还是之后？

这一点我前面其实想得有点笼统。

像我现在使用 Coding Agent，代码改完以后我可以 review，不满意就让它继续改，也可以拒绝 merge。

这种情况下，人确实拥有很明确的控制权。

问题更多出现在开始自动执行真实业务动作以后。

比如一个客服 Agent 可以退款。

有三种完全不同的人类参与方式。

第一种：

退款执行以前，超过某个条件必须先让人批准。

人可以真正阻止这个动作。

第二种：

Agent 正在运行，人可以在异常时暂停或接管。

这是 intervention。

第三种：

Agent 已经完成大量退款，第二天再给人看 audit report。

这时人类参与的是事后审计。

三者都可以被笼统叫作 human oversight，但作用完全不同。

第三种当然仍然有价值，可以发现长期问题、追责和调整规则。

但它已经不能阻止刚才那笔错误退款发生。

所以设计 Human in the Loop 时，还需要问：

这个人是在行动前批准，在执行中可以干预，还是只能事后发现问题？

发现问题以后，又能不能 rollback、escalate 或补救？

把这一层说清楚，比简单写一句“最终由人负责”具体很多。

而且，并不是所有 AI 问题都应该交给人来补

这一轮 research 做到这里，我觉得还有一个挺重要的修正。

Human in the Loop 很容易变成一种万能答案：

AI 可能出错？

没关系，加人工审核。

但不同 failure，本来就应该用不同的方法解决。

如果问题是信息缺失，就应该补信息。

AI 和人都不知道另一方真实想法，再增加一个 reviewer 也不会凭空创造事实。

如果结果可以客观验证，优先建立独立验证。

能跑测试，就不要完全依赖人肉读代码。

如果某些风险已经很明确，就应该建立权限和 guardrail。

例如退款超过某个金额必须人工批准，而不是给 Agent 无限权限，再希望 reviewer 每次都能发现错误。

如果真正遇到的是模糊、例外、价值取舍，再把它交给合适的人。

这样看以后，Human in the Loop 只是整个 reliability system 的一层。

一个更完整的系统可能同时需要：

补充信息；
测试和 evaluation；
权限与 guardrail；
人工审核；
监控；
出了错以后还能够恢复。

可靠性不能全部押在“最后有个人看一下”。

我现在会用四个问题检查 Human in the Loop

这是这轮 research 最后留下来的一个比较实用的框架。

以后看到一个“AI 做，人审核”的流程，我会继续问：

谁来审？

他有没有这项判断真正需要的知识、context 和责任？

拿什么审？

有没有独立于 AI 的数据、测试、来源或者真实结果可以核验？

怎么审？

重要变化和风险有没有被暴露出来？审核者有没有足够时间和注意力真正完成判断？

审完能做什么？

审核发生在行动之前、执行过程中还是事后？发现问题后能不能阻止、修改、升级处理或者恢复？

如果这四个问题回答不清楚，我不会因为流程图里多了一个 human box，就默认系统已经安全很多。

反过来，如果它们都成立，人类参与才真正开始发挥作用。

写完三篇以后，我对“AI 还做不太好的事”的理解

这轮 research 最初的问题其实非常简单：

AI 到底还有什么做不好？

很自然会想到一些领域：

艺术、感情、身体技能、主观判断。

最后得到的答案没有这么整齐。

第一篇练琴让我看到：

AI 有很多知识，不代表它已经观察到了真实情况、找到原因，并形成有效的反馈循环。

第二篇继续发现：

AI 可以把事情替我做得很好，但它的能力不会因为我使用过，就自动变成我的能力。

第三篇再往下一层：

即使执行交给 AI、判断留给人，人机组合也不会自动变得可靠。

三个问题表面上不太一样，底下却有一个共同点：

AI 某一项能力很强，不代表我们真正想要的结果已经发生。

模型会答题，不等于学生学会了。
模型会分析演奏，不等于真正教会了学习者。
模型输出很强，人也参与了，不等于整个系统就一定比双方单独更可靠。

从“AI 会做”到“现实里真的做成”，中间还有很多东西：

它拿到了什么信息；
任务真正的目标是什么；
人和 AI 怎样分工；
结果如何验证；
哪里应该用系统规则控制风险；
又在哪里真的需要人的判断。

所以如果现在再问我：

AI 还有哪些事情做不好？

我可能不会先列一张领域清单。

我会先继续问：

这件事情从“模型有能力”，到“现实结果真的成立”，中间还缺哪一环？

有些缺口会随着模型变强慢慢消失。
有些需要更好的产品和系统设计。
有些适合交给人。
还有一些问题，人和 AI 都暂时没有足够信息回答。

AI 的能力边界还会一直移动。

但我觉得，知道应该去哪里找这条边界，比记住今天的一张“AI 能 / 不能”清单，更有用。

关于这轮 research

这是「AI 还做不太好的事」研究系列的第三篇，也是最后一篇。

整轮研究从我自己在练琴、学习、写作、关系和 AI 产品中的真实使用问题出发，再用不同领域的研究去验证、反驳和修正最开始的解释。

本篇主要关注 human-AI collaboration 和 Human in the Loop 到底在什么条件下真正有效。

第一组核心证据来自 Vaccaro、Almaatouq 和 Malone 发表在 Nature Human Behaviour 的系统综述和 meta-analysis。研究纳入 106 个实验、370 个 effect sizes，比较人单独、AI 单独以及人机组合的表现。平均来看，人机组合能够提高人的表现，但没有超过人和 AI 中表现更好的一方；decision tasks 中平均出现 performance loss，creation tasks 的结果则相对更积极。研究纳入的实验主要发表于 2020 年至 2023 年中，因此不能直接代表今天最新模型，但足以提醒我们：互补需要被验证，不能从“人 + AI”这个结构本身推出。

第二项研究发表于 Nature Medicine，是一项 1,298 人参加的随机预注册实验。研究发现，同一批 LLM 直接获得完整医疗场景时表现很好，但进入真实的人机对话以后，并没有帮助普通参与者获得优于传统信息来源的判断结果。研究者因此特别强调，模型 benchmark 不能替代真实用户测试。

两项研究放在一起，我觉得最值得留下来的不是：

“人机合作不可靠。”

而是：

真正应该评估的是整个人机系统。AI 做什么，人做什么，双方分别根据什么信息判断，错误怎样被发现，又怎样被阻止和恢复。

S2 Day 006 · AI 都能替我做了，我还需要自己会吗？

Fri, 11 Sep 2026 00:00:00 GMT

上一篇写练琴时，我最后发现，AI 明明知道很多钢琴知识，却不一定真的能教好一个正在弹琴的人。

原因不是一句“AI 没有身体”就可以解释。真正的教学至少要经过四层：

Observe → Diagnose → Intervene → Verify

先看见真实发生了什么，再判断原因，选择适合这个人的干预，最后根据新的结果继续调整。

这是这一轮 research 里遇到的第一种边界：AI 有知识，不等于这些知识能够顺利抵达现实结果。

继续往下看，我开始碰到另一种很不一样的问题。

这一次，AI 甚至可能什么都没有做错。

它可以帮我把邮件写好，把资料整理好，把代码做出来，把一道题解出来，结果比我自己完成得更快、更完整。

那如果 AI 已经可以替我做了，我还需要自己会吗？

我觉得这个问题不能统一回答。

因为我们使用工具，本来就在不断放弃一些“必须自己会”的事情。

我不需要自己拥有冰箱保存食物的能力，也不需要为了维持心算水平，每次使用计算器前先手算一遍。导航让我少记很多路，洗衣机也早就替代了大量手洗的技能。

AI 没有什么不同。

真正需要先分清的，是我希望这件事情做完以后，留下什么。

我现在大概会把它分成三种。

第一种：我只需要结果

这类事情最简单。

比如整理一份会议记录、转换文件格式、提取一批信息，或者写一封很普通的行政邮件。

如果最后需要的是一个准确、可用的结果，AI 能稳定做好，我很愿意直接交给它。

我不会因为让 ChatGPT 帮我把一封英文邮件改得更自然，就担心自己因此没有“真正学会写这封邮件”。

因为这封邮件本来就不是一堂英语课。

工具存在的意义之一，就是把一些没有必要继续由人亲自完成的工作拿走。

所以我并不太认同一种笼统的说法：

只要越来越依赖 AI，就是人在失去能力。

失去什么能力，为什么还需要它，才是更重要的问题。

第二种：我可以不亲自做，但需要懂到能判断

有些事情我也愿意把执行交出去，但不能完全失去理解结果的能力。

我现在用 Coding Agent 做产品就是一个很明显的例子。

我并不觉得自己一定要先成为一个能够独立写 production code 的工程师，才有资格让 Agent 帮我开发产品。

它能做出来，就是实实在在的价值。

但我还是需要理解一些东西。

比如一个技术方案会不会改变产品行为，某个 Agent 应该获得多大权限，一次架构调整带来了什么 trade-off，测试通过到底证明了什么，又有哪些事情其实还没有被验证。

否则我交出去的就不只是 coding execution。

连判断“这件事有没有做对”的能力，也一起交出去了。

所以这里真正需要保留的，不一定是执行能力，而是足够的 judgment / oversight capability。

我不需要亲自做每一步。

但至少要知道什么时候可以放心，什么时候应该继续追问，什么时候其实已经超出了自己能够审核的范围。

第三种：有些事情，能力本身就是我要的结果

到了这里，问题才真正变得不同。

我练英文口语，是因为希望下一次面试时自己能说。

练琴，是因为希望自己的手真的会弹。

学生学习数学，也不是为了今天这一页习题最后全部显示绿色对勾，而是希望以后遇到类似问题，自己能够处理。

这时，“AI 帮我把任务完成得更好”和“我自己学会了”就不再是一回事。

这一点在教育研究里已经开始出现很具体的证据。

AI 辅助时做得更好，不代表能力已经留在人身上

2025 年，PNAS 发表了一项接近 1000 名高中生参与的数学随机对照实验。

研究者设计了两个基于 GPT-4 的 AI 助手。

一个比较接近普通 ChatGPT 的使用方式，学生遇到题目，可以直接让它帮助解答。

另一个则专门按照教学目标做了限制：更倾向于给 hint，而不是直接交出答案，同时使用教师准备的正确解法、常见错误和反馈方式来指导学生。

实验还有一组不使用生成式 AI 的学生作为对照。

在有 AI 辅助的练习阶段，两个 AI 组的表现都明显提高。

普通 GPT 组比对照组高约 48%，经过教学设计的 GPT Tutor 组高约 127%。

只看这里，当然很容易觉得 AI 帮助了学习。

但实验还有下一步。

研究者把 AI 拿走，让学生自己考试。

这时候，之前使用普通 GPT 的学生，成绩反而比没有使用 AI 的对照组低了约 17%。

经过教学设计的 GPT Tutor 组基本消除了这种负面影响，但在无 AI 的考试里，也没有显著超过对照组。

同一个实验里，于是出现了一个很重要的区别：

AI 在场时，学生完成任务的表现可以明显提高。

但 AI 撤掉以后，人的独立能力不一定获得了同样的提升。

研究者进一步看学生如何使用普通 GPT 时，也发现很多人更容易直接向它索取答案。

这其实不难理解。

如果学生真正需要练习的是自己读题、回忆知识、尝试、犯错、再根据反馈修改，那么 AI 直接跨过这些过程，把正确答案交出来，当然可以提高眼前的 performance。

但它同时也可能替学生做掉了一部分原本需要发生在人身上的工作。

这并不意味着学习时应该少用 AI

另一项研究正好补上了另一半。

同样是在 2025 年，Harvard 的研究团队在一门本科物理课程里做了一项 194 人参与的随机实验。

学生分别使用传统课堂中的 active learning，或者一个专门设计的 AI Tutor 学习相同内容。

这个 AI Tutor 并不是把一个普通聊天机器人直接放在学生面前。

研究团队按照教育和认知科学中的一些原则设计互动，让学生主动参与，逐步获得信息，在需要的时候得到提示和反馈，并按照自己的进度学习。

在实验涉及的两节课程内容里，AI Tutor 组的即时学习增益高于课堂 active learning，而且花费的时间更少，学生报告的 engagement 和 motivation 也更高。

这项研究当然有边界。

它发生在一门 Harvard 本科物理课里，只测试了特定教学内容，主要观察短期学习结果，也没有证明几个月以后学生依然记得更多。

但和前一个数学实验放在一起，我觉得已经足够说明一个很重要的问题：

关键不是学习时“有没有 AI”。

而是：

AI 替学生做了什么，又保留了什么让学生自己完成。

AI 可以直接跨过思考过程，把答案交出来。

也可以看着学生自己尝试，在真正卡住的时候给一点帮助。

表面上都是“AI tutoring”，实际产品目标完全不同。

如果「能力提升」是目标，有些看起来低效的步骤不能全部拿掉

我们做普通生产力产品时，很自然会追求减少 friction。

能一步完成，就不要让用户走三步。

能自动填，就不要让他自己输入。

AI 把这种方向推得更远：很多事情已经可以直接从一个问题跳到一个看起来完整的答案。

但如果任务的目标是学习，有一些 friction 本身可能就是学习过程。

自己先想。
从记忆里把东西找出来。
试一个不一定正确的答案。
发现哪里不会。
获得反馈以后再做一次。
换一个场景，看自己能不能迁移。

这些过程看起来没有“直接生成正确答案”高效。

但如果我真正想训练的就是这个能力，把它们全部拿掉，最后被优化掉的可能正是我要学习的部分。

所以我现在觉得，好的学习型 AI 有时候反而需要克制一点：

不是尽快替我完成，而是尽量让我完成。

关于「表达能力退化」的思考

第一个 100 天记录结束的时候，我写过一个很个人的感受。

我发现自己完整组织一段文字，好像比以前费劲了一点。

与此同时，AI 越来越能接住我的不完整表达。几个零散的想法，一些没有组织好的句子，都可以先扔给它，再变成一篇结构完整的文字。

我不知道这种变化是不是 AI 导致的。

自己的感觉当然不能证明因果。

但现在我会换一个问题问自己：

完整表达这件事，对我来说究竟属于哪一类？

很多文字生产，其实只属于第一类。

一封邮件、一段说明、一份格式清楚的材料，我只想得到结果，完全可以大量使用 AI。

但表达对我又不只是文字生产。

现实里，我还要参加面试，要和别人讨论复杂问题，要在没有 AI 中介的时候让另一个人理解自己。

这意味着表达本身依然有独立的实际价值。

另外还有一层，我现在只能把它当作自己的观察，而不是 research 已经证明的结论：

有时候我并不是先完整想好一个观点，再把它翻译成语言。

把一个模糊的东西慢慢说清楚，本身也是我思考的一部分。

写到一半，才发现两件事情其实没有逻辑关系。

试着解释一个观点，才发现自己也不知道为什么相信它。

讲给别人听的时候，才意识到这里缺了一块证据。

所以我真正担心的并不是：

以后我的句子会不会没有 AI 写得漂亮。

而是：

如果所有还没成形的想法，都在很早的时候交给 AI 帮我补完整，我是不是也少经历了一部分自己把事情想清楚的过程？

目前我没有足够证据回答这个问题。

但至少我知道，这是一个我自己仍然想保留的能力。

所以我现在会先问：这件事做完以后，我希望留下什么？

这是这轮 research 给我的第二个比较实用的判断。

面对一件越来越容易交给 AI 的事情，我会先把它放进三个位置之一。

我只需要结果

那就放心外包。

没有必要把所有任务都包装成“学习机会”。

我需要保留判断

执行可以交出去，但需要留下足够的理解、验证和决定能力。

我未必需要自己写代码，但需要知道什么时候不能只听 Agent 说“已经完成”。

我需要的就是这项能力

那 AI 应该参与练习，而不是把真正需要训练的部分全部替掉。

这里最终要看的，不只是：

AI 在旁边的时候，我做得有多好。

还要看帮助逐渐减少以后：

什么真的留在了自己身上。

我觉得这就是第二篇里 AI 一个很容易被忽略的边界。

它很擅长把自己的能力借给我们。

但：

AI 的能力，不会因为被我使用过，就自动变成我的能力。

如果我只需要结果，这完全不是问题。

如果我要保留判断，就需要留下一部分理解和验证。

如果人的能力形成本身就是目标，那么产品甚至需要故意留下那些本来可以由 AI 直接完成、但对学习仍然必要的步骤。

这也刚好把问题带到这组 research 的最后一篇。

前面第二种情况里，我说：

执行可以交给 AI，但重要判断留给人。

这已经是现在很多 AI 产品非常常见的设计：

Human in the Loop。

AI 先做，人最后检查。

听起来很合理。

但下一篇我想继续追一个更麻烦的问题：

人在 loop 里，就代表他真的审得出来吗？

关于这轮 research

这是「AI 还做不太好的事」研究系列的第二篇。

第一篇讨论的是，当 AI 要指导一个真实的人完成一项技能时，从观察现实、判断原因，到干预和反馈，中间任何一层都可能成为限制。

这一篇关注另一种边界：当人的能力形成本身是目标时，AI 提高有工具辅助时的 performance，并不能自动证明 learning 发生了。

本篇主要使用两项随机对照实验。

Bastani 等人的高中数学研究覆盖接近 1000 名学生，同时比较 AI 在场时的练习表现，以及撤掉 AI 后的独立考试，因此能够把 assisted performance 和后续 learning outcome 分开观察。

Kestin 等人的研究则在 Harvard 本科物理课程中测试专门按照教学原则设计的 AI Tutor，提供了方向不同的证据：AI 并不天然妨碍学习，系统怎样设计、又替学生完成了什么，才是关键变量之一。

两项实验的对象、学科和评价周期都不同，所以不能简单比较谁“更正确”。放在一起，对我最有价值的反而是这个区分：

AI 能把一项任务做得更好，和 AI 能帮助人形成一项能力，需要分别验证。

S2 Day 005 · AI 还有一些做得不太好的事，比如教我练琴

Thu, 10 Sep 2026 00:00:00 GMT

上一篇写林夕、黄伟文和 AI，最后其实留下了一个没有回答完的问题。

AI 已经越来越会写。它可以理解失恋，可以分析情绪，也可以很快生成一句漂亮的话。所以我不太愿意用“因为 AI 没有真的爱过”来解释为什么有些表达仍然差很多。这个答案太容易了，也没有真正解释问题。

顺着这个疑问，我后来想做一件反方向的事。

这几年我们一直在看 AI 又能做什么，我想认真看看：

它现在还有哪些事情做得不太好？为什么？

不是整理一张“AI 的 20 个缺点”，也不是先假定某些事情永远只能由人来做。我更想从自己真实使用时遇到的 friction 出发，再看看研究能不能解释这些体验，或者反过来证明我原来的理解并不准确。

最后我整理了大约 20 组核心证据，涉及音乐感知、教育随机实验、人机协作、医疗决策和 AI reliability。主要看原始研究、随机实验和 meta-analysis；一些很新的 2026 年研究目前仍是会议论文或预印本，所以也只把它们当作早期证据，不往外推得太远。

这轮 research 有一个结果我还挺喜欢：它没有简单证明“我的感觉是对的”。

有些我原来以为是 AI 的本质局限，拆开以后，可能只是它没有拿到需要的信息；有些确实和当前模型能力有关；还有一些，问题甚至不在 AI 自己，而在我们怎么使用它、怎样判断结果。

我准备分三篇写。

第一篇先从一个我自己很有体感的例子开始：练琴。

第二篇想看，AI 帮我们完成一件事情，和我们自己真正学会一件事情，是不是同一回事。

最后一篇再回到现在很常见的 Human in the Loop：只要最终有人审核，系统就真的可靠吗？

我一开始的理解很简单：练琴这件事，光靠文字说不清楚

我和 AI 聊过不少钢琴。

如果问一首曲子的背景、曲式、和声，或者某一段通常应该怎样练，它经常讲得很好。

这并不奇怪。音乐里有大量已经被语言和符号表达出来的知识：乐谱、和声理论、音乐分析、教材、老师总结过的练习方法。大语言模型处理这些内容，本来就有优势。

但真正坐到琴前，情况会变得不一样。

有时候我会觉得这一段“不太自然”，手有点紧，或者明明每个音都弹对了，声音就是不好听。

AI 当然还是可以给建议：降低速度、放松手腕、分手练、注意 voicing、听旋律线。

这些建议通常不能说错。

但它们经常更像是在告诉我：

“一个人在这种情况下，通常可以试试这些方法。”

而不是一个老师真的听完我弹两遍以后，说：

“你这里的问题其实是这个。”

所以我原来的解释很直觉。

练琴里面有太多重要信息，不是文字。

触键用了多少力量，手指和手腕怎样配合，两个音之间那一点 timing，声音到底硬在哪里，身体什么时候开始紧张，这些东西很多时候连我自己都很难准确描述。

这里常常会涉及 tacit knowledge（隐性知识）和 embodied knowledge（身体化知识）：有些技能存在于身体、感觉和长期经验里。一个人会做，不代表他可以把自己做这件事时的所有判断都说清楚。

而 ChatGPT、Claude、Gemini 这些我们现在大量使用的 AI，确实是从 LLM 发展起来的。

当然，这里也要把概念说准确一点。

AI 是一个很大的范围，LLM 只是其中一种技术。

而今天这些通用 AI 也早已不再只是“文字进、文字出”的纯 LLM。它们可以处理图片、声音等多模态输入，也可以连接各种工具和专门系统。

所以 research 以后，我觉得自己原来的说法——

钢琴很多东西无法用语言描述，所以基于 LLM 的 AI 不会教琴。

还是太粗了。

更准确的问题应该是：

那些不在语言里的重要信息，AI 到底有没有真正获得，并且理解对了？

从这里开始，我发现“教一个人练琴”其实可以很清楚地拆成四层：

Observe → Diagnose → Intervene → Verify

先观察发生了什么，再判断为什么，选择怎样干预，最后验证有没有真正变好。

任何一层出问题，都可能得到一种很熟悉的结果：

AI 说得挺对，但没真正帮上忙。

1. Observe：它首先得真的听见我弹成了什么样

2025 年有一项研究，专门测试现在的多模态大模型到底能不能“听懂”一些基础音乐信息。

研究者让 Gemini 2.5 Pro、Gemini 2.5 Flash、Qwen2.5-Omni 等模型完成节奏、移调、和弦识别等任务，然后比较两种输入方式。

一种是直接让模型听音频。
另一种是先把音乐转换成 MIDI，把音高、时间这些结构化信息明确表示出来，再交给模型。

结果出现了很明显的差异。

例如其中一个和弦类别识别任务里，Gemini 2.5 Pro 直接处理音频时，zero-shot 准确率大约是 47.7%；同样的信息换成 MIDI 后，接近 97.7%。

不同任务的差异并不完全一样，所以不能拿一个数字得出“AI 听不懂音乐”。

但这项实验至少支持了一个很重要的区别：

模型知道很多音乐知识，不等于它能够同样可靠地从真实声音里提取这些知识需要的信号。

这正好击中了我原来那个直觉的一部分。

假设我弹完一段以后问：

为什么这里听起来不对？

在讨论音乐性、练习方式甚至手腕之前，其实应该先确认：

它到底有没有准确听到，我刚刚弹成了什么样？

如果我只是用文字说一句“这里有点僵”，大量真正影响判断的信息根本没有进入系统。

即使给它一段录音，也不能默认多模态模型已经像钢琴老师一样听见了里面所有重要细节。

一个现场老师拿到的信息更多。他不只听，还在看我的手和身体；刚才哪里犹豫了一下，他可能直接看到；如果不确定，还能马上让我再弹一次。

所以我现在觉得，比“音乐无法用语言表达”更准确的说法是：

对演奏这种身体技能来说，语言是一种有损的信息接口。

而即使把语言换成音频、视频，第一关还是一样：

系统到底有没有观察到真正重要的现实？

2. Diagnose：听见哪里不对，还要知道为什么

再往前假设一步。

AI 已经准确听出：

这一小节节奏不稳定。

事情仍然没有结束。

因为“不稳定”只是一个现象。

背后的原因可以完全不同。

可能是谱还没有读熟，所以弹到这里会迟疑；可能是几个手指的控制问题；可能速度已经超过了当前能力；也可能我本来就在做 rubato，只是控制得不好。

最后听起来，都可能是：

这里不太稳。

但练法不会一样。

所以第二层真正需要的是：

从现象走到原因。

这也是为什么我现在觉得，“AI 可以识别错误”和“AI 可以诊断技术问题”最好不要混为一谈。

一个系统可以标出：

这里比标准节拍晚了一点。

这是一项很具体、也比较容易测量的能力。

但要继续判断：

为什么这个学习者会在这里慢下来？

已经进入了另一层。

老师在做这类判断时，往往也不只是调用一条明确规则，而是用过去看过很多学生、听过大量演奏、自己也长期练习形成的经验。

这并不意味着 AI 永远做不到。

只是：

发现问题，和知道问题为什么发生，本来就是两件不同的事。

3. Intervene：知道原因以后，还要知道现在该怎么教这个人

假设前两步也都做对了。

AI 不只听出不稳，也判断主要是右手几个手指控制的问题。

接下来是不是就会教了？

还是不一定。

因为教学不是输出：

《手指控制不稳定的十种解决办法》。

同一个问题，不同学习者适合的方法可能不一样。

有人应该先降速。
有人需要改变动作。
有人适合做节奏变体。
也可能一个人已经机械重复太多，再继续练二十遍，只是在把紧张也一起练得更熟。

所以第三层真正困难的不是：

AI 知道多少种练习方法。

而是：

它能不能判断，眼前这个人现在最应该先做哪一件事。

这也是通用建议和教学之间很大的差别。

AI 很容易给出五条“都对”的建议。

老师很多时候会做另一件事：

先别管其他的。

只改这个。

等这里真的变了，再继续。

4. Verify：教了一次以后，还得知道这个方法有没有用

最后还有一层。

老师让我换一种方法，再弹一次。

如果变好了，需要判断是偶然弹好了一次，还是已经开始稳定。
如果没有变，是我没理解？方法不适合？还是最开始的诊断本身就错了？

所以真正的教学从来不是一次回答。

它是一个反馈循环：

Observe → Diagnose → Intervene → Verify

观察、诊断、干预，再回到现实检查结果。

2026 年一个叫 Profy 的钢琴研究，刚好让我觉得这个边界特别清楚。

研究者收集了 73 名演奏者、超过一千段有效演奏，同时记录琴键运动和音频，再用模型找出一段演奏中比较值得学习者回听和检查的位置。

结果显示，这类系统已经可以比较有效地帮助人定位值得注意的演奏片段。

这是很实际的进步。

但论文自己也很谨慎：它验证的是这些提示和专家判断之间的对应，以及这种反馈方式是否可用；并没有证明学生长期学习效果更好、能力能够迁移，或者这种系统已经可以替代老师。

我很喜欢这个区别。

“更准确地指出哪里值得看”，和“真正把一个人教会”，中间还有很长一段链路。

所以，AI 为什么现在还不太会教人练琴？

Research 以后，我现在的答案不再是：

因为 AI 没有身体。

也不是：

因为音乐无法用语言表达。

更接近这四层：

1. Observe

它首先要真正听见、看见你现在弹成什么样。

2. Diagnose

发现问题以后，还得知道问题为什么发生。

3. Intervene

知道原因以后，要选择适合这个具体学习者、这个阶段的练习方法。

4. Verify

最后还要重新观察，确认这个干预真的产生了效果，再决定下一步。

任何一环比较弱，最后都会出现一种很像的体验：它懂很多，也说了很多正确的话，但没有真正教到你。

这四层当然不是“AI 所有问题”的总框架。

它更适合这一类任务：需要观察真实世界、判断原因、进行个体化干预，再不断根据反馈调整。

钢琴只是其中一个很具体的例子。

但把它拆清楚以后，我发现这件事对其他 AI 使用也挺有帮助。

当 AI 没有帮上忙时，与其马上问：

是不是模型还不够强？

我现在会先看：

它有没有拿到完成任务真正需要的信息？
它只是看到现象，还是有足够依据判断原因？
它给的建议是一般正确，还是适合眼前这个具体情况？
最后有没有新的现实反馈，证明这个建议真的有用？

答案不同，解决方式也会完全不同。

有时候确实应该换更强的模型。

有时候缺的是声音、视频、传感器或者更完整的数据。

有时候需要一个专门为这类任务设计的系统，而不是继续和通用 Chatbot 聊。

还有一些时候，下一步真正需要的不是再生成一个答案，而是回到现实里试一次，再把新的结果拿回来。

这可能是这轮 research 给我的第一个有用的 takeaway。

当 AI 明明知道很多，却没有真正帮上忙时，先别急着给它贴上“不会做”的标签。先看看，从观察现实到验证结果，这条链到底断在哪里。

下一篇会继续看另一种我觉得更隐蔽的问题。

有时候 AI 根本没有明显做错。

它给出的答案很好，我们也顺利完成了任务。

但如果这件事情本来是为了学习：

AI 帮我做到了，和我自己真正学会了，是不是一回事？

关于这轮 research

这是「AI 还做不太好的事」研究系列的第一篇。

整轮研究从我自己在练琴、学习、写作、关系和 AI 产品里的真实 friction 出发，再去找不同领域的研究，看这些体验背后的解释有没有证据，哪里需要修正。

目前整理的核心证据约 20 组，主要来自音乐感知与身体技能、教育随机实验、人机协作 meta-analysis、医疗决策和 AI / Agent reliability。

它不是严格意义上的系统综述，也不会拿某一个模型今天的表现去定义 AI 永久的能力边界。个人体验负责提出问题；研究负责检验这些解释；证据暂时回答不了的地方，就保留为开放问题。

这一篇主要用了两类研究。

一类测试多模态模型处理真实音频和结构化音乐信息时的差异，帮助回答“模型到底有没有听到”。

另一类研究专门的钢琴反馈系统已经能够做到什么，又还没有证明什么，帮助区分“分析演奏”和“真正产生教学效果”。

S2 Day 004 · 林夕/黄伟文和 AI：「会写」与「写到心里」之间

Tue, 08 Sep 2026 00:00:00 GMT

最近在想一个问题：表达能力更好的人，是不是也更容易用好 AI？

顺着这个问题往下想，又出现了一个有点相反的疑问。

今天的 AI，其实已经很会表达了。

让它写一段失恋，写一句安慰，找一个比喻，再要求“克制一点”“不要那么俗”“更有文学感”，它通常都能交出一个不错的版本。

可是最近重新听林夕和黄伟文的词，我还是会有一种很明显的差别。

有些写了二三十年的句子，今天听到还是会突然击中人；而 AI 写出来的很多东西，明明通顺、漂亮、意思也完整，读完却常常只是觉得：

嗯，说得挺对。

然后就没有然后了。

我开始好奇，这中间到底差了什么。

同样是“得不到”，AI 会解释，林夕却留下了一座山

如果要表达“很喜欢一个人，但最终明白不能拥有”，最顺手的写法通常是解释这个道理。

有些人出现在生命里，不一定为了留下；爱一个人，也要学会接受失去。

这些话都没有错，甚至可能相当准确。

但《富士山下》不是这样写的。

林夕把一段关系放到富士山旁边，于是“因为很爱，所以想拥有”这件很私人的情绪，忽然有了一个具体又有点荒谬的对照：

我们可以那么喜欢一座山，却不会因此认为它应该属于自己。

这里真正厉害的，好像不是“比喻得漂亮”。

而是从此以后，“无法拥有”这件事有了一个形状。

他没有站出来解释一遍什么叫放下，而是找到了一个足够具体的东西，让那个意思自己留在那里。

我觉得这和 AI 很常见的一种表达正好相反。

AI 很擅长把一种情绪解释准确；好的写作者，有时候根本不急着解释，而是替它找到一个我们以后还会记得的东西。

同样是“成长”，黄伟文让一颗葡萄自己说话

再想“经历过一些失去之后，人慢慢成熟”这件事。

它其实特别容易被写成一句正确的话：

成长需要时间，遗憾最后也会变成答案，很多事情急不来。

这些表达的问题不在于错，而在于我们已经太熟悉它们了。

《葡萄成熟时》却选了一颗葡萄。

葡萄成熟本来就是一个需要等待、无法催促的过程。

时间不再只是歌词里被说出来的一个道理，而已经存在于这个东西本身。

于是“等待”“错过”“成熟”这些很大的词，不需要一个一个解释。

它们都藏在葡萄和时间的关系里。

我很喜欢这种表达，因为读者不是被告知“你应该从这里理解到成长”，而是自己走到了那里。

别人把答案告诉你，和你自己突然看见那个答案，感受是不一样的。

到了《浮夸》，连“不体面”都变得重要了

还有一种差别，我是在重新想《浮夸》时意识到的。

如果今天让 AI 写一个“长期没有被看见的人”，它很容易把这个人处理得相当成熟：

我不是一定要成为人群的中心，只是偶尔也希望有人真正看见我。

很合理，也很健康。

但真实的人并不总是这么健康。

《浮夸》里的那个人，被忽略以后不是安静地完成自我和解，而是越来越夸张。既然平常的自己没人看，那就索性变得奇怪、扎眼，甚至失控——无论如何，至少你终于看见了我。

这也是我很喜欢黄伟文的地方。

他经常愿意把一个人不那么好看的部分留下来：嘴硬、虚荣、嫉妒、不甘心、自尊、赌气。不是先把情绪整理得成熟体面，再允许它出现在作品里，而是承认人有时候就是会这样。

AI 默认的表达却很容易往另一个方向走。

它喜欢替矛盾寻找意义，替人物变得成熟，也喜欢在结尾安排某种理解或者和解。

可是很多真正击中人的东西，偏偏没有那么体面，也未必真的被解决了。

林夕和黄伟文，也不是同一种“动人”

当然，把两个人放在一起说，很容易又掉进另一个陷阱：非要替他们分别总结一种固定风格。

我觉得没有必要。

如果只说一种我自己的感受，林夕很多时候会继续往情绪里面追。一段感情写着写着，可能变成执念、占有、自欺、时间，最后甚至开始碰到“人为什么会这样”这样的问题。

所以听他的词，有时候会突然冒出一种感觉：

原来我真正难受的是这个。

黄伟文则常常让我先看见一个很具体的人。

这个人有脾气，有尊严，也有自己的难堪。他不会只是一个抽象的“失恋者”或者“孤独的人”，而是会用属于自己的方式去失恋、嫉妒、赌气或者逞强。

那种触动更像：

原来这么不好看的想法，也有人知道。

当然，这不是一道可以画得很清楚的分界线。林夕一样写过非常鲜活的人物，黄伟文也完全可以把一首歌推向很大的生命命题。

只是他们让我意识到：所谓“表达得好”，从来不只有一种方法。

所以 AI 真正缺的是“感情”吗？

说到这里，很容易得到一个很浪漫的解释：

因为 AI 没有真的爱过谁，也没有失恋过，所以它永远写不出这样的东西。

我不太相信问题这么简单。

今天的语言模型从极大量的人类文字中学习，它当然见过无数关于爱、失去、嫉妒、孤独和死亡的表达。很多时候，它甚至比我们更容易迅速调出某一种情绪应该搭配什么词、什么意象、什么句式。

问题恰恰可能出在这里。

当我们说“帮我写成长”，它很容易走向那些已经被反复证明有效的路径：时间、伤疤、旅途、告别、蜕变、遗憾。

结果通常不会太差。

但真正困难的是下一步。

为什么偏偏是葡萄，而不是另一种东西？
为什么这里应该留下那个人的狼狈，而不是帮他完成和解？
为什么这一句说到这里就够了，再解释一句反而会坏掉？

这些选择里面有经验，有观察，有审美，也有对世界某一种很具体的看法。

最后还需要一个很重要的东西：

取舍。

AI 可以一次给我二十句话，但哪一句应该留下？

我越来越觉得，这可能才是 AI 时代写作发生的一个真正变化。

生产语言正在迅速变便宜。

一个标题不满意，可以再来二十个；一句话不够好，可以同时得到五种写法；一封邮件甚至不用自己从第一句开始写。

语言越来越多以后，稀缺的东西反而慢慢换了位置。

不是“我还能不能再写一句”，而是：

这二十句里面，到底哪一句值得留下？
哪个比喻只是看起来聪明，其实很俗？
哪里解释得太多了？
哪个词没有那么华丽，却更准确？
甚至有没有一种可能，这里什么都不要再加？

AI 当然也可以继续帮我们做这些判断。

但判断不会因为生成变便宜，就自动变得容易。

这也是为什么我现在越来越觉得，好表达背后不只有语言能力。

它还来自一个人看见了什么、怎样理解自己看见的东西，又愿意舍掉多少那些“也不错”的选择，最后只留下这一句。

会写，与写进心里之间

所以回到最开始的问题。

表达能力更好的人，会不会更容易用好 AI？

我还是觉得会。但如果把“表达能力”只理解成更会遣词造句，可能又把它想窄了。

真正重要的，也许还有：你有没有自己的观察，能不能判断一个答案到底只是正确还是确实有意思，能不能容忍一些没有被整理好的复杂和难堪，以及面对 AI 给出的十个“都还不错”的答案时，有没有勇气删掉其中九个。

AI 已经越来越会写。

这件事大概不会倒退，而且它以后还会写得更好。

所以我并不想证明“AI 永远写不出林夕和黄伟文”。那是一个太轻易、也太浪漫的结论。

真正让我好奇的是另一件事：

当“写出一句不错的话”越来越容易以后，什么才会继续让一句话属于某一个人？

也许是他看见世界的方式，是他的经验和偏见，是那些不那么体面的部分，是他舍不得删掉的东西，也是他最终决定删掉的东西。

会写，与写进心里之间，大概还隔着这些。

有富士山，有慢慢成熟的葡萄，也有一个拼命想让别人看见自己的人。

S2 Day 003 · 语言表达能力强的人，AI 用得更好吗？

Mon, 07 Sep 2026 00:00:00 GMT

最近突然想到一个问题。

现在我们和 AI 最主要的交互方式还是语言。那么，本来就更会表达的人，是不是也会更会用 AI？

第一反应好像是肯定的。你越能把自己的目标、背景、限制和期待说清楚，AI 就越容易理解你真正想做什么。可再往下想，又觉得这件事没那么简单。

能说，跟说到点子上，还是两件事。

语言可能只是我们和 AI 之间的接口。真正决定这个接口里能传递多少东西的，还是后面的思考。

会表达，当然有优势

同样是让 AI 帮忙看一个产品方案，有人会说：

“帮我看看这个方案还有什么问题。”

另一个人可能会说：

“我现在不是想继续补功能，而是想判断它是否已经足够进入真实用户测试。请重点看核心流程有没有断点，哪些问题会妨碍用户完成任务，哪些只是可以以后再修的体验问题。”

后者通常会得到更有用的回答。但不完全是因为他比较会写 Prompt，而是因为在开口之前，他已经想清楚了一部分：现在到底要判断什么，什么问题重要，什么问题暂时可以放过去。

所以我越来越觉得，所谓“表达能力”，在这里不是英语好、文笔好，也不一定是说话漂亮。

一个很会写东西的人，完全可能把一个错误的问题描述得特别动人；一个程序员可能不善言辞，却能准确告诉 AI 现在是什么状态、哪里失败了、什么不能动、什么结果才算通过。

后者一样很会用 AI。

表达更像是思考的出口，而不是最底层的能力。

更难的是，把“感觉不对”变成一个真正的问题

现实里的问题很少一开始就长得很清楚。

更多时候，我们脑子里只有一个模模糊糊的感觉：“这个产品好像还不够好”“这篇文章读起来有点怪”“这个方案我总觉得哪里不对”。

接下来真正困难的，是继续往下追。

到底哪里不对？
是信息不够，还是结构有问题？
是产品真的还不能用，还是只是没有达到自己的理想状态？
现在缺的是继续研究，还是已经应该拿出去看看真实用户怎么反应？

这就是所谓的 problem framing：把模糊的问题慢慢定义清楚。

以前我会觉得“会提问”可能是一种 Prompt 技巧，现在越来越不这么看。它其实是一种很传统的思考能力：在一团混乱里，找到那个真正值得解决的问题。

AI 只是让这件事变得更明显了。

因为 AI 有一个很特别的地方：你给它一个错误的问题，它也可以非常勤奋地把这个错误的问题一路做下去，而且做得相当完整。

「生成」越来越便宜以后，「判断」反而更重要了

这可能是我现在最在意的一层。

AI 已经很会生成了。一篇文章、一份方案、一段代码、一份分析，都可以很快得到一个看起来相当完整的版本。

困难反而发生在答案出来以后。

它真的回答了原来的问题吗？
哪些地方只是听起来很专业？
哪些结论其实没有足够证据？
哪些东西虽然正确，却根本不重要？
又有哪些地方明明还能继续优化，但其实已经足够用了？

我越来越警惕一种东西：AI 制造出来的“完成感”。

一份东西结构完整、语言流畅、该有的部分都有，很容易让人觉得事情已经做完了。但“做完了”和“做对了”不是同一件事。

所以当生成能力越来越廉价，judgment 反而可能变得更值钱。

你得知道什么值得做，什么是真的好，什么只是长得很像一个好答案。

这也是为什么我不太相信“有了 AI，专业知识就没那么重要了”这种说法。一个不了解金融、医疗、工程或产品的人，可以很快让 AI 生成一份像模像样的东西，但他未必知道哪里违反了真实世界的约束，也不知道哪些 trade-off 才是真正需要付出的代价。

AI 降低了生成答案的门槛，却没有自动降低判断答案的门槛。

还有一个麻烦：AI 很容易顺着我们

和 AI 相处久了，我觉得还有一种能力越来越重要，就是偶尔回头看看自己的思考过程。

我为什么相信这个答案？
这是事实，还是一个未经验证的假设？
AI 真的是独立得出了这个结论，还是因为我的问题本身已经暗示了方向？
如果出现什么新的证据，我会愿意改变现在的判断？

因为 AI 很容易沿着一个人的 framing 继续往下走。

如果最开始的问题里已经藏着一个偏见，它有时候不仅不会打断我们，反而可以替这个偏见补充越来越完整的论证。最后得到的东西逻辑很顺，甚至看起来很有深度。

但逻辑顺，不代表它是真的。

所以除了问 AI“你确定吗”，有时候还得问自己：

我为什么这么确定？

会分析，也不一定总是优势

如果文章停在这里，很容易得到一个漂亮的结论：越会定义问题、越有判断力、越会反思自己的人，就越会使用 AI。

后来我觉得，事情还有另外一面。

会 problem framing 的人，也可能不断重新 framing；习惯 critical thinking 的人，会发现每个答案都还可以继续 challenge；一个特别喜欢观察自己思考过程的人，甚至可能开始研究——我为什么一直在分析自己为什么一直在分析。

这件事我自己挺有体感。

AI 给了我们一个过去很少拥有的对象：它几乎不会累，也不会因为“这个话题我们已经聊两个小时了”而想回家。只要你愿意，一个问题可以一直往下挖。

过去很多思考会因为时间、精力，或者找不到人继续讨论而自然结束。现在这个天然的停止点消失了。

于是出现一个很有意思的变化：

思考的成本越来越低，停止思考反而变成了一种能力。

我最近很喜欢用一个很简单的问题来判断要不要继续：

这个我还不知道的东西，会改变我的下一步行动吗？

如果会，那值得继续研究。

如果不会，可以先记下来，然后往前走。

现实里的好决策，本来也不是等到所有 uncertainty 都消失之后才做出来的。更多时候只是，我们已经知道得足够多，可以承担剩下的不确定性，先走下一步。

所以，会用 AI 到底考验什么？

如果现在重新回答最开始的问题，我还是会说：语言表达能力确实有帮助，但它可能没有我们第一眼想象得那么核心。

更底层的是：

你能不能把模糊的问题逐渐定义清楚，
能不能判断 AI 给出的东西究竟好不好，
有没有足够的经验理解真实世界的约束，
能不能意识到自己和 AI 都有可能错，
以及，什么时候应该停止继续分析。

这些其实都不是 AI 时代突然发明出来的能力。

Problem framing、judgment、domain knowledge、critical thinking、metacognition——以前就已经存在。

AI 做的，更像是把它们的差异放大了。

它放大的可能不只是一个人的生产力，也包括一个人原本的思考方式。

问题定义得清楚，AI 可以帮我们走得更远；问题从一开始就错了，它也可能帮我们更快地跑偏。

所以我越来越不觉得“会写 Prompt”会是一种长期稀缺的能力。模型会越来越能理解我们的口语、截图、文件、代码，甚至那些自己还没说完整的意图。

真正难被自动补齐的，可能还是几个很人的问题：

我到底想解决什么？

我怎么知道这个答案是好的？

我有什么可能想错了？

以及——已经想到这里，是不是该去做了？

S2 Day 002 · GPT-6 Astra 来了，用法要变吗？

Sun, 06 Sep 2026 00:00:00 GMT

今天打开 ChatGPT，看到了 GPT-6 Astra 的更新提示。

每次模型更新，都会听到“更聪明”“更强”。但日常用它写东西、整理资料、做计划的人，更想知道：这次升级，究竟能帮我省下什么？以前的用法需要改吗？

我觉得，最值得重新尝试的，是那些以前需要你反复提醒、纠偏，最后还是自己接手的任务。

1. 模型升级，也要看一件事能不能做完整

根据 OpenAI 的说明，Astra 的重点包括复杂推理，以及跨代码、浏览器、专业软件完成多步骤工作。官方也强调，它更能在长任务中保持连贯，收到新的要求后，继续保留原来的目标和约束。

这对普通用户意味着什么？

比如修改文章。你说“开头再直接一点”，希望它改好开头，同时保住后面已经成立的论证。你进一步要求压缩篇幅，也希望关键例子和结论留下来。

每一条要求都不难。难的是，修改到第五轮时，前四轮确定的东西还在。

这些工作旧模型也能做。新模型是否更有价值，要看完成同样的任务，需要你补救多少次。

2. 先分清：换模型、加思考、开工具

这几个变化容易混在一起：

模型，例如 Astra。主要影响它理解问题、推理、生成内容和使用工具的能力。

思考档位，也叫 effort。调整的是让所选模型投入多少推理。更高的档位通常需要更多时间和用量。

工具与资料访问。关系到它能否搜索网页、读取文件、操作软件，以及能不能拿到完成任务需要的信息。

所以，“没读到我的文件”和“读到了却分析错了”，需要分别处理。换一个更强的模型，不会自动补齐缺失的资料或访问权限。

判断原因很有用。否则，文件根本没传进去，却一直提高思考档位，只会多等一会儿。

3. 可以试着多交给它一步，但说清楚终点

我过去用 AI 写文章，常遇到一种情况：讨论时分析得很好，到了成文却没了结构；继续润色几轮，反而觉得前一版更好。

这次我想验证的，就是它能否更稳地完成从理解要求到交出全文的过程。目前还不能把这个期待当成实测结论。

对日常使用来说，可以先调整任务的交法。

例如，给它会议记录时，可以这样要求：

根据这份记录，整理成一封可发给参会者的会后邮件。包含已确认的决定、负责人和截止时间；没定下来的事项单独列出，不要补写。完成草稿后检查是否遗漏，先不要发送。

这里说清楚了材料、交付物和边界。整理顺序、怎样合并重复信息，可以让它自行安排。OpenAI 的提示词指南也建议优先描述需要的结果，仅在过程本身重要时规定步骤。

有些要求依然需要你保留：不能改的事实、已经确认的决定、你真正重视的标准。把这些写清楚，也更容易判断它有没有照做。

而且，官方也承认 Astra 可能更爱追问、回答偏长。需要精简，就继续明确篇幅；只需要草稿，就把终点写成草稿。

4. 怎么判断这次升级与你有关？

找一件你熟悉、也知道好坏的旧任务：一篇改不满意的文章、一份整理起来很费劲的记录，或一个需要兼顾多个条件的计划。

如果旧模型仍可选择，就给两边相同的材料和要求，尽量保持工具与思考档位一致。再给它们同一条修改意见，看看谁能改好这一处，同时保住其他要求。

重点看三件事：

最终结果有没有达到可用标准？
你提醒、纠正了几次？
加上审阅和返工，你一共花了多少时间？

一次比较只说明这个任务的表现。接下来几次日常使用，再看看这个优势是否稳定。

思考档位也可以先从默认开始。遇到多来源冲突、复杂取舍或难以解决的问题，再往上调；官方同样建议使用能够满足任务的最低档位。

下次看到模型更新，可以先挑一件旧任务重试。保留那些确实替你省下精力的变化，再逐步调整分工。

资料来源：OpenAI 官方模型指南（GPT-6 Astra），以及 ChatGPT Work 的 Models、Prompting 文档。资料查阅于 2026 年 9 月 5 日。

S2 Day 001 · 鲁棒决策：AI 时代，别把下一步押在一次猜对上

Sat, 05 Sep 2026 00:00:00 GMT

最近第一次认真认识了一个词：

鲁棒。

它对应英文里的 robustness，在工程、优化、AI 里都很常见。简单来说，如果一个系统只有在所有条件都符合预期时才能正常工作，现实稍微偏一点就坏了，它就比较脆弱；反过来，如果环境发生变化、信息有误差、原来的假设没有完全成立，它仍然能维持不错的表现，就更“鲁棒”。

后来我发现，这个概念放到日常决策里也很好用。

现实中，我们经常没有足够的信息，却又不得不继续往前走。很容易卡住的地方是：总觉得自己得先搞清楚到底发生了什么，才能决定下一步。

但这两件事，其实不一定要按这个顺序发生。

不一定先猜对，才能行动

比如一个项目做了一段时间，效果一直不好。

可能是方向没有错，只是还需要时间；也可能方向本身就不成立，只是已经投入很多，所以不愿意停下来。

如果一定要先证明哪一个解释是真的，可能还要继续分析很久。但下一步未必要等这个答案。可以先给项目一个明确的小周期，同时提前定义这段时间要验证什么、什么证据出现说明值得继续，以及什么结果仍然没有出现时，就应该缩小或停止投入。

如果最后发现方向是对的，这个动作没有耽误太多；如果方向是错的，也没有继续无限往下押。

这就是一个相对鲁棒的行动。

再比如一个工作机会。

在真正加入以前，很难完全知道团队究竟怎么样、老板是不是合适、JD 里写的决策权是否真的存在。这时候没有必要过早把它判断成“绝佳机会”，也不需要因为几个模糊信号就认定“这里肯定有坑”。

可以继续面试，同时专门验证那些真正会改变决定的问题：为什么招这个人？上一任为什么离开？这个岗位真正能决定什么？资源够不够？成功怎么衡量？

面试本身，也可以成为收集信息的一部分。

我们不一定要先把世界解释清楚，才能决定下一步。

有时候，更有用的是先选一个不太依赖自己猜对的动作。

这背后确实有一套正式的方法

“鲁棒行动”并不是一个标准术语，我只是为了方便理解这样称呼它。更正式的概念包括 Robustness、Robust Optimization，以及 Robust Decision Making。

传统的决策思路很容易是：先预测最可能发生什么，再选择在这个预测下最优的方案。

鲁棒决策更在意另一个问题：

如果现实没有按照预测发展，这个方案还行不行？

它不一定追求在某一种情境下做到最好，而是希望一个方案放进不同的可能情形里，都不会表现得太差。

这也是我觉得它特别适合现实生活的地方。很多时候，我们的困难并不是分析能力不足，而是世界本来就暂时不给答案。

继续想，并不会自动让缺失的信息出现。

一个比较鲁棒的行动，通常有四个特点

1. 不太依赖某一个判断一定正确

可以先问自己：

如果我现在的解释错了，这个动作还合理吗？

如果一个决定只有在自己猜对的情况下才成立，它就比较脆弱。尤其在信息很少的时候，这种决定值得更谨慎一点。

2. 可逆

能不能暂停、回头、调整，或者先做小一点？

信息越少，越应该谨慎对待那些一旦做了就很难撤回的决定。反过来，如果一个动作成本不高，也很容易调整，就没有必要等所有信息都齐全以后才开始。

3. 损失有上限

可逆不代表没有代价。

一个决定理论上可以撤回，但时间、钱和注意力可能已经花掉了。所以还需要知道：如果最后猜错，我最多准备付出什么？

只要这个代价在可承受范围内，行动空间就会大很多。

4. 做完以后，会知道得更多

这是我最喜欢的一条。

一个好的下一步不只是“不出大问题”，最好还能减少之后的不确定性。

做一个 prototype，找几个真实用户，继续一次面试，跑一个小规模 pilot，或者先 dry run。它们的共同点是，不要求你先把问题彻底想明白，但做完以后，你会比现在更接近现实一点。

所以如果要把它压缩成一句话，我会觉得比较理想的鲁棒行动是：

可逆、损失有限，而且还能带来新的信息。

鲁棒不等于保守

这一点很容易混淆。

鲁棒并不是“风险越少越好”，也不是永远选择最安全的方案。有时候一直不行动，反而是一种很脆弱的选择。

一个岗位两周后关闭，因为还没有完全想明白，所以一直不投；一个产品在内部优化半年，却迟迟不让真实用户使用。看起来都很谨慎，但真正重要的未知数始终没有得到验证。

鲁棒真正关心的不是少做事，而是：

不要让整个决定建立在一个自己暂时无法确认的假设上。

所以有些时候，更鲁棒的做法恰恰是尽快行动，只是先把行动做小一点，不要第一次就把全部筹码压进去。

AI 系统其实也在处理同一种问题

再把这个概念放回 AI，就很好理解了。

一个好的 AI 系统不能只考虑：如果模型判断正确，它能做多少事情。还需要考虑另一面：

如果它判断错了，会发生什么？

比如 Coding Agent 不确定一次 database migration 是否安全。比较脆弱的做法，是根据当前判断直接执行；更鲁棒的流程可能是先 inspect schema，生成 migration，dry run，检查 diff，验证影响，到了高风险步骤再让人确认。

这并没有让模型突然变聪明。

它只是没有要求模型必须第一次就判断正确，同时把一次错误可能造成的损失控制住了。

模型对一个问题没有足够把握时也是一样。最好的行为不一定是继续努力生成一个听起来完整的答案，它也可以请求更多信息、明确表达不确定、缩小自己能够确认的范围，或者把决定交还给人。

AI 里还有一个很接近的概念，叫 graceful degradation，优雅降级。

条件越来越差时，好的系统不是突然从“正常”掉到“失控”，而是逐渐收缩自己的能力：有把握时自动完成，不确定时让用户确认，风险较高时只提供建议，超出能力范围时停止。

背后的逻辑其实很朴素：

不要假设自己永远会判断正确。

我现在觉得，“鲁棒”是一个很好用的决策提醒

我们很容易把大量时间花在解释世界。

这个人到底为什么这样？这个项目究竟有没有前途？这个机会到底好不好？现在是不是最佳时机？

有些问题当然值得继续研究，但也有很多时候，证据就是还没有出现。继续分析，并不会让未知的信息突然变成已知。

这时候，可以换一个问题：

如果几个解释现在都还有可能，我下一步做什么，在这些情况下都还算合理？

不一定要一次把事情决定完。可以先保留一点余地，控制最坏损失，拿一点真实反馈，再根据新的信息继续走。

这大概是我目前对“鲁棒决策”最喜欢的理解：

信息不足时，不一定非要先猜对。

先做一个即使猜错，也依然大体成立的选择。

Day 100 · 第 100 天，留给自己

Fri, 04 Sep 2026 00:00:00 GMT

第 100 天，留给自己

不知道从什么时候开始，自己书写一些完整的段落变的困难了起来；好多天前曾经尝试穿插一篇自己的表达，写了一半发现拼拼凑凑极度卡顿，放弃

AI 越来越厉害，它慢慢能够更多的兼容我在表达上的不连贯/不周全/欠逻辑/磕磕绊绊，也更多的替我完成这些“像那么回事”的内容，纵然确实还是有满满的 AI 味，但看起来似乎能装装样子

所以，这项技术的普及，「带来了什么」跟「拿走了什么」，也许要更多的交给时间来回答

而时间又能回答什么呢？

100 天前我开始这个“框架”，好像也没想太多这 100 篇会如何完成，我以为很多未知的变化即将发生，我带着一些憧憬慢慢往前走，而现在，到了第一个驿站，阶段性的回顾是，并未有什么大的变化

- 做的产品从 1 个到了 4 个，但用户还是维持在 1 以下，AKA, 我自己

- 投递的 AI PM 岗位从 0 到了 51 个，能拿到 screening call 的比了了更了了

- （还有什么...）嗯，learning by sharing 我觉得有更多，但这个偏向于渐悟而不是顿悟了，我需要提醒自己学习那两样世界上最珍贵的东西：耐心与希望

真实世界的答案也许没有那么整齐，一道有多个选项的题目也未必有一个标准答案，只能告诉自己边走边想了，对自己诚实就好

如果让我排序转型路上的难度，可能这个阶段的我会排：

心态 > 策略 > 执行

做 AI 产品，或者用 AI 做产品的重要品质：

发现值得解决的问题 > 提出优雅的方案 > 稳定/可用/高质量的输出

记录 100 天这件事带给我自己的收获：

- 给日常一个框架

- 在输出中推自己也多想一下

还会继续的，对之后自己的祝福与叮嘱是：

- 走得慢一点，多想想，不要用盲目 building 的快感去逃避真正值得思考与解决的问题

- 很多东西不 cool, 但或许更重要

- 与各种新技术 connect 的更好的时候，千万要提醒自己这世上最重要的一个 connection 是与自己的

- （还有什么...）人比 AI 重要，了解技术的能力与局限，分清做一件事的「目的」与「手段/实现过程」

- Enjoy~

Day 099 · 李飞飞团队发布 Atlas：World Model 到底在解决什么？

Thu, 03 Sep 2026 00:00:00 GMT

9 月 1 日，李飞飞创办的 World Labs 发布了新模型 Atlas。

官方把它称为一个面向 Spatial Intelligence 的 World Model（世界模型）。它可以同时处理文字、图片、视频和 3D 信息，用来生成、重建和模拟空间世界。

看到这条新闻后，我也去试了 World Labs 目前已经公开的 Marble。严格来说，我体验的不是刚发布的 Atlas；Atlas 还在 early access，未来会进入新版 Marble。

Marble 可以从一张照片生成一个能走进去探索的 3D 世界。第一次看到确实挺有意思，但真正进去走一圈，瑕疵也很明显：原图没拍到的地方需要模型自己补，有些物体换个角度就开始变形，空间关系和真实环境也不总是对得上。

所以这次体验没有让我觉得“世界马上要变了”。它更像让我具体理解了一个之前有些抽象的概念：

World Model 到底想解决什么，以及为什么李飞飞、Yann LeCun 这些研究者都长期关注这个方向。

LLM 已经知道很多关于世界的事，为什么还不够？

可以想象桌边放着一个玻璃杯。

今天的 LLM 当然知道，玻璃掉到地上可能会碎，杯子放得太靠边容易被碰掉，也知道如果要把杯子拿起来，可以抓住杯身或者把手。

这些都是关于世界的知识。但如果一个机器人真的站在这张桌子前，它还需要处理更具体的问题：杯子现在在哪里，离桌边还有多远，机械臂从这个角度伸过去会不会撞到旁边的东西；如果推一下杯子，它会往哪里移动；换到桌子的另一边，同一个杯子又应该出现在什么位置。

这里需要理解的已经不只是“杯子通常是什么样”，而是眼前这个世界现在是什么状态，以及接下来可能怎样变化。

World Model 大致就在处理这类问题。

可以把 World Model 理解成一种内部的世界模拟

World Model 目前并没有一个所有研究者完全统一的定义，但背后的想法很好理解。

人做很多动作之前，会先大致预测后果。看到杯子快掉下桌子，我们不需要真的等它摔碎，才知道最好伸手扶一下；过马路看到一辆车靠近，也会自然判断它的方向、速度和距离，再决定现在要不要继续走。

如果 AI 以后要在物理世界里行动，它也需要类似的能力：理解当前状态，预测接下来可能发生什么，并判断自己的行动会怎样改变世界。

所以 World Model 里有一个很核心的问题：

如果我这样做，会发生什么？

这也是它为什么经常被形容成某种 internal simulator。AI 可以在行动之前，先预测几个可能的未来，再选择比较合适的一条路。

Atlas 具体做了什么？

World Labs 对 World Model 的能力用了三个很清楚的词：Generate、Reconstruct、Simulate。

Generate

是从文字、图片等输入继续生成一个世界，包括原始输入里没有看到的空间。

Reconstruct

是用一张或多张真实照片还原现实中的 3D 场景。输入信息越多，模型需要自己猜的部分越少。

Simulate

则加入了时间和变化。Atlas 不只处理一个静止场景，也尝试理解世界怎样随时间变化，以及如何把真实环境转成可以用于机器人训练和测试的 simulation。

技术上，Atlas 把 text、image、camera pose 和 3D depth 等不同信息组织进同一个 spatial context。每张图片不只是一些 pixels，它还对应一个明确的 3D 观察位置和角度。模型根据已经看到的空间信息，再继续预测新的视角、画面和 3D 结构。

对我来说，理解到这里已经够了。至于 multimodal autoregressive diffusion transformer 具体怎样实现，可以等真的需要研究模型架构时再往下钻。

它和 Sora 这样的 Video Model 有什么区别？

这两个概念确实很容易混在一起，因为一个好的视频生成模型，本身也必须学到大量世界规律。

如果让模型生成一个球从桌上滚落的视频，它至少需要让运动看起来符合常识。随着视频模型越来越强，它们和 World Model 之间的边界也会越来越模糊。

但两者关注的问题还是有一些区别。

视频生成首先需要解决的是：接下来的画面应该长什么样。

World Model 会更关心这个世界本身是否保持一致。刚才的桌子换一个观察角度以后还在不在？一个物体被挡住以后是否仍然存在？从房间另一边看回来，几个物体之间的空间关系有没有发生奇怪的变化？如果一个 agent 采取了动作，整个世界状态接下来会怎样改变？

所以生成一段视觉上合理的视频，和维持一个可以持续观察、预测和操作的世界，并不是完全相同的问题。

我自己试 Marble 时，最容易看到的也是这层差距。一张照片可以很快长成一个漂亮的 3D 场景，但只要开始从不同方向探索，就会发现“看起来合理”和“真正理解这个空间”之间还有不少距离。

Yann LeCun 这些年其实也一直在押 World Model

理解 Atlas 时，我想到的另一个人是 Yann LeCun 杨立昆。

他这些年一直认为，如果 AI 最终要理解物理世界、进行 planning 和采取行动，只依赖语言是不够的。Meta 后来推出的 V-JEPA 2 就直接被称为 World Model，它通过大量视频学习世界中的运动和变化，再加入少量机器人行动数据，让模型预测某个 action 发生以后，世界可能怎样变化。

所以李飞飞和 LeCun 确实在关注一个很接近的大方向：

AI 需要形成某种关于物理世界如何运转的内部模型。

两边的技术路线不一样。

LeCun 的 JEPA 很强调，不需要预测现实里的每一个 pixel。比如我要判断一辆车是不是正在向我靠近，并不需要同时预测下一秒每片树叶的位置、路人衣服上的褶皱和云的形状。真正影响行动的可能只是：车正在靠近、速度大概是多少、距离还剩多少。

所以 JEPA 主要在抽象的 representation 里进行预测。

World Labs 的 Atlas 更偏生成式。它会直接生成 image、video、depth 和 3D 世界，并利用这些不同形式共同建立 spatial context。

我觉得目前没有必要判断哪一条路线“更正确”。它们都在尝试回答一个仍然很开放的问题：

什么样的内部表示，才能让 AI 真正理解一个会变化、可以行动的世界？

为什么讲到 World Model，最后经常又会讲机器人？

还是回到桌上的杯子。

假设任务是让机器人把杯子放进水槽。它要先看到周围环境，知道杯子、桌子和自己分别在哪里，然后考虑从什么方向靠近、怎样抓住杯子、移动时会不会碰到其他物体。

World Model 更接近帮助它预测：这样做以后会发生什么。

另外还有一个最近经常出现的概念叫 VLA（Vision-Language-Action）。它把视觉输入、语言目标和机器人动作连起来，更接近解决：为了完成这个目标，我现在应该采取什么动作。

真实系统当然不会永远这么干净地分成两块，而且现在的 VLA 也不一定都需要一个独立的 World Model。但把它们这样区分，对理解技术地图很有帮助：

World Model 帮助预测世界；Policy / VLA 帮助选择行动；机器人把动作真正执行出来，再根据新的观察继续调整。

于是 AI 在物理世界里的工作会逐渐形成一个循环：观察环境、预测结果、采取行动，再观察新的结果。

这也是为什么 World Model、Spatial Intelligence、Embodied AI、VLA 和 Robotics 最近经常会一起出现。它们不是同一个概念，只是在逐渐拼起“AI 怎样在现实世界里行动”这件事的不同部分。

那 Atlas 这次发布，意义到底有多大？

我觉得现在还很难下一个特别大的结论。

Atlas 刚刚发布，目前只对少量合作伙伴开放。普通用户能直接体验的仍然是 Marble，而我刚才的使用感受也很明确：它已经能完成一些以前很难想象的事情，但离准确、稳定地理解和模拟真实空间，还有明显距离。

所以如果问它今天会不会改变大多数人的日常生活，我觉得暂时不会。

但从技术发展的角度看，这条路线值得继续留意。

过去几年，生成式 AI 最明显的进步首先发生在语言，后来逐渐扩展到图片、声音和视频；Agent 又让 AI 开始从生成内容走向使用工具和完成任务。World Model 关注的是另一组问题：AI 能不能建立一个持续存在的空间，理解物体之间的关系和时间变化，并预测自己的行动会产生什么后果。

这些能力如果逐渐成熟，应用范围会很广。游戏和影视可以更容易创建完整的可探索空间，建筑和设计可以把现实环境转成 simulation，AR / VR 可以更容易获得 3D 世界，机器人则可以先在大量模拟环境中学习和测试，再进入现实。

其中一些已经能看到早期应用，另一些还很远。

Atlas 现在更像这个发展过程里的一个节点。它没有把 World Model 这个问题解决掉，但把生成、空间重建、时间模拟和机器人 simulation 放进了一个更统一的模型框架里。

自己试过以后，我对 World Model 的理解具体了一些

如果只看官方 demo，很容易把注意力放在生成效果够不够惊艳。

自己拿一张熟悉的空间照片去试，会开始观察另外一些东西：原图没有拍到的位置，模型是怎么补的？换一个角度以后，原来的物体还能不能保持一致？空间比例有没有慢慢跑掉？如果再增加几张同一个地方的照片，结果会不会更接近真实环境？

这些问题都指向同一个区别：

生成一个看起来合理的世界，和建立一个足够可靠的世界模型，还有很长的距离。

这大概也是我现在觉得 Atlas 值得关注、但不需要过度兴奋的原因。

它代表的方向很好理解：如果 AI 未来不只处理文字、图片和网页，也真的要进入我们的物理世界，它需要逐渐学习空间、时间、物体、变化，以及行动产生的后果。

现在这件事还做得不够好。

但 World Model 这条路在试图去哪里，已经越来越清楚了。

Btw, Atlas 最常见的英文意思是“地图集”。

这个词来自希腊神话里的 Atlas，他是一个被罚肩负天空的 Titan。World Labs 没有公开解释模型为什么取这个名字，所以不必给它附会一个官方寓意。

不过，一个用来生成、重建和模拟 worlds 的模型叫 Atlas，确实挺贴切。

Day 098 · OpenClaw 还在吗？

Wed, 02 Sep 2026 00:00:00 GMT

几个月前，OpenClaw 几乎到处都能看到。

一个运行在自己电脑上的 AI Agent，可以连接 Telegram、WhatsApp 等聊天工具，有记忆，也能操作浏览器、读写文件、执行命令。

很多人第一次看到它的时候，都会有一种很直观的感觉：

个人 AI 助理好像真的来了。

但最近，我明显少看到大家讨论 OpenClaw。

我原本也以为，是不是这类产品的热度过去了。

重新看了一遍它这几个月的发展后，我觉得更准确的说法是：

OpenClaw 的公共热度确实降下来了，但产品并没有停下来。

7 月，它成立了独立的 Foundation，开始做 extended-stable release 和产品成熟度管理。

8 月 30 日，OpenClaw 又发布了 2.0，继续改安装、memory、browser、automation、security 等一大批基础能力。

所以比起“OpenClaw 是不是凉了”，我现在更好奇的是：

为什么一个还在快速开发的产品，大家却没有几个月前那么兴奋了？

OpenClaw 最初火的，是一种新的使用方式

早期的 AI，大部分还是：

我打开一个工具，输入一个问题，等它回答。

OpenClaw 展示的是另一件事。

AI 可以长期运行，有记忆，可以连接各种服务，也真的能操作电脑。

你甚至不用坐在电脑前。

给它发一条消息：

帮我看看邮件。
整理一下今天的日程。
去网页上查一件事。

它可以自己继续往下做。

真正新鲜的并不是其中某一个功能，而是这些能力被放到了一起。

AI 不再只是回答问题。

它开始行动。

这也是为什么 OpenClaw 最早的 demo 很容易传播。

几十秒的视频，就能让人理解“Agent 可能是什么”。

但真的装到电脑里以后，问题就变了

Demo 里看到 AI 自动处理邮件，很酷。

但如果这个 Agent 真的每天运行在自己的电脑里，很快就会遇到另外一批问题：

它到底能看到什么？
可以直接发送邮件吗？
哪些操作需要我确认？
能不能接触密码和 API key？
如果网页里有恶意内容怎么办？
第三方 Skill 到底拿到了什么权限？
做错事情以后，我能不能知道它刚才做了什么？
长期运行贵不贵、稳不稳定？

这些问题都没有“AI 自动操作电脑”那么吸引眼球。

但真正长期使用一个 Agent，反而更依赖这些东西。

OpenClaw 这半年也发生过第三方恶意 Skill、安全风险等问题。

这其实暴露出了 Agent 产品一个很基本的矛盾：

给它的能力越多，需要解决的权限和安全问题也越多。

以前一个聊天机器人回答错了，我们重新问一次就好。

一个能操作文件、浏览器、shell 和真实账户的 Agent 做错事情，代价可能完全不同。

所以产品做到这里，重点自然会从：

“它能不能做？”

慢慢变成：

“我敢不敢长期让它做？”

还有一个问题：什么都能做，不等于每天都知道拿它做什么

Coding Agent 的使用场景相对清楚。

写代码、修 bug、review PR、跑测试。

但 personal agent 的范围要宽很多。

它可以帮你处理邮件、日程、信息整理、浏览器操作、自动化任务，甚至管理其他 Agent。

能力听起来很大。

问题是，普通用户仍然需要自己回答：

我每天到底有什么事情值得交给它？

这也是我觉得 OpenClaw 从 demo 进入真实生活以后，会遇到的另一个难题。

“什么都可以做”是一种很强的能力描述。

但它不一定是一个清晰的产品入口。

大部分人真正长期留下来的工具，往往都有几个非常明确、反复发生的使用场景。

Personal Agent 现在还在寻找这些场景。

OpenClaw 最近做的很多事，其实都没那么“酷”

但很重要。

比如让安装更简单。
减少第一次配置需要处理的东西。
改 browser 和 control UI。
做更稳定的 release。
加强 credential、permission 和 security。
让 automation 更容易管理。

这些更新很难像最早的 demo 一样制造“未来已经来了”的感觉。

但它们解决的是另外一个阶段的问题：

怎么让一个能力很强的 Agent，变成一个普通人真的可以长期使用的产品。

这也是为什么我觉得 OpenClaw 最近的“安静”挺有意思。

最开始大家都在探索 Agent 的能力边界。

现在越来越多精力开始放在：

可靠性、权限、安全、成本、使用门槛，以及真实的日常需求。

这些事情没有那么适合做 viral demo，却更接近产品本身。

还有一个变化：OpenClaw 最初代表的新鲜感，也在逐渐变成共识

几个月前，一个长期运行、能操作电脑、连接很多工具的 personal agent，本身就足够新鲜。

现在类似的能力正在越来越常见。

不同的开源 Agent 在做。

ChatGPT、Claude 等产品也在不断增加 Agent、computer use 和 integrations。

Personal Agent 不再只是 OpenClaw 一个项目的想象。

所以一部分热度下降，也未必代表这个方向不成立。

可能只是：

“AI 可以自己做事”这件事，已经没有几个月前那么新了。

竞争接下来会发生在更具体的地方：

谁更稳定。
谁更安全。
谁更容易配置。
谁真正知道用户每天需要它做什么。
谁能让用户愿意把更多权限交出去。

所以 OpenClaw 到底发生了什么？

至少目前，我没有看到足够的数据证明它经历了明显的用户流失。

能比较确定的是：

讨论它的人少了，但项目仍然非常活跃。

而且它现在做的事情，已经和最初爆红时不太一样。

最开始，它需要证明：

一个真正可以行动的 personal agent 是可能的。

这个问题基本已经回答了。

接下来的问题要麻烦很多：

它能不能安全、稳定、低成本地运行？

普通人有没有足够高频的需求？

我们愿意给一个 Agent 多大的权限？

出了错以后，怎么知道发生了什么，又怎么控制后果？

我觉得这些问题，比“OpenClaw 还火不火”更值得继续看。

因为它们不只属于 OpenClaw。

几乎所有想从 demo 走向真实使用的 Agent 产品，最后都会碰到这里。

Agent 能做的事情越来越多之后，产品真正稀缺的可能不再只是能力。

而是：

让人放心地把事情交给它。

Day 097 · AI 越用越多，开始有人关注 AI wellbeing 了

Tue, 01 Sep 2026 00:00:00 GMT

最近 Anthropic 发布了一个挺值得注意的消息：

他们拿出 500 万美元，资助独立研究者研究 AI 对用户 wellbeing 的影响。

研究范围包括 AI companionship、心理健康对话、长期使用，以及模型在这些场景下到底应该怎样回应。

我看到这条新闻的时候，第一次认真留意到一个词：

AI wellbeing

这件事其实离普通用户并不远。

因为过去一年，我自己的生活已经发生了一个很明显的变化：

AI 不再只是偶尔打开、问一个问题的工具。

它开始进入工作、学习、写作、做决定、安排生活，甚至情绪低落时整理自己的想法。

而且它一直在线。

很多时候，一个念头刚刚出现，还没来得及自己想，我已经打开了 ChatGPT。

技术进入生活的速度非常快，但人适应一种新技术的方式，往往没有这么快。

所以我开始觉得，我们可能不只需要学习怎么把 AI 用得更好。

也要开始学习：

怎么和 AI 长期相处。

AI wellbeing，不只是“少看一点屏幕”

我们以前讲 digital wellbeing，很容易想到：

少刷手机、控制 screen time、别熬夜刷短视频。

这些问题当然仍然存在。

AI 使用时间越来越长，也可能意味着更多久坐、更长的屏幕时间，以及工作和休息之间更模糊的边界。

但 AI 和过去很多数字产品还有一点不一样。

它开始参与我们的思考。

我们会让它：

整理信息，生成观点，判断方案，替自己写东西，解释一个人的行为，给职业建议，甚至在难过的时候陪自己聊天。

搜索引擎主要帮我找到信息。

短视频主要争夺我的注意力。

但 AI 可以进一步进入：

我怎么想、怎么判断、怎么理解自己。

所以比起问：

我每天用了几个小时 AI？

我现在更想问的是：

AI 正在替代我的什么？

有些替代很好，有些需要留意

我一点也不介意 AI 替我整理会议记录。

也很欢迎它帮我读几十页资料、检查格式、处理大量重复工作。

工具本来就是为了减少人的负担。

但另外一些事情没有那么简单。

比如：

原本我要自己想十分钟的问题，现在第一反应变成问 AI；
原本一个暂时没有答案的问题，现在可以不断追问，直到得到一个让我舒服的解释；
原本需要自己做的判断，慢慢变成“ChatGPT 觉得哪个更好”；
原本应该去和真实的人沟通的事情，可能在 AI 这里已经讨论了几十轮。

这并不意味着这些使用方式一定有害。

但它们开始碰到一些比“效率”更底层的东西：

认知、情绪、关系和 agency。

认知：方便到什么程度，会开始改变我们的思考方式？

Microsoft Research 在 2025 年调查了 319 名知识工作者，收集了 936 个真实的 GenAI 工作案例。

其中一个挺值得留意的发现是：

人对 AI 越有信心，报告投入的 critical thinking effort 越少；而对自己完成任务越有信心的人，反而投入了更多 critical thinking。

研究同时发现，AI 并没有让 critical thinking 消失，而是让它逐渐从“直接解决问题”，转向验证、整合和监督 AI 的结果。

这也是我自己最近越来越在意的一点。

AI 帮我省掉思考当然不是坏事。

计算器也省掉了大量心算。

问题在于：

我是否还知道哪些地方不能省？

一个答案看起来非常完整的时候，我还有没有能力发现它哪里不对？

一个观点被 AI 表达得非常有说服力的时候，我有没有自己的判断标准？

如果一个问题永远由 AI 帮我生成第一版，我自己的 first thought 会不会越来越少？

情绪：AI 是一种以前很少存在过的交互对象

这一点可能更加新。

一个普通的人不会：

24 小时有空，永远愿意听你重新讲一遍，几秒钟就回复，而且每一次都围绕你展开。

AI 可以。

这也是它非常有价值的地方。

人在焦虑、孤独或者混乱的时候，能够立刻找到一个地方整理情绪，本身可能就是帮助。

但这种产品特性也意味着，我们以前很少和这样一种“对象”长期相处。

OpenAI 和 MIT Media Lab 在 2025 年做过两组相关研究：

一组自动分析接近 4,000 万次 ChatGPT interaction；另一组是近 1,000 名参与者、持续四周的随机对照实验。

结果并不是“和 AI 聊情绪就不好”。

事实上，高度情感化的使用只集中在少部分用户。

但研究也发现，长时间的日常使用，以及把 AI 更强烈地视作朋友等因素，与一些较差的 psychosocial outcomes 有关联。个人本身的 attachment tendency 和使用方式也会影响结果。研究者同时强调，目前这些证据仍然很早，很多地方不能简单解释成因果关系。

今年关于 AI mental-health use 的研究也明显开始增加。

7 月发表的一篇综述甚至估算，大约 27% 的 AI 用户曾把 AI 用于某种 mental-health support，同时指出现有数据的口径仍然非常不稳定。

所以这已经不是一个特别边缘的使用方式了。

AI 还有一个很特别的问题：它几乎没有天然的停止点

一篇文章会读完。
一集电视剧会结束。
一次咨询有 50 分钟。
和朋友聊天，对方也总有事情要做。

但 AI 很少告诉你：

今天就到这里吧。

你可以继续：

再分析一下，换一个角度，再给五个方案，再看看有没有漏掉什么。

这当然非常高效。

但有时候，“没有 friction”本身也是一种新的 friction。

一个原本应该暂时放下的问题，可以一直被继续处理。
一个其实需要时间消化的情绪，可以一直被语言化、解释、重新分析。
一个已经够好的工作结果，可以再优化五轮。

AI 把很多行动的成本降得非常低。

但人并没有因此突然拥有无限的注意力、判断力和情绪容量。

这可能也是 AI wellbeing 和传统 screen-time 问题很不一样的地方。

所以，我现在怎么理解 AI wellbeing？

我觉得它不是：

尽量少用 AI。

也不是：

保持独立，什么都自己做。

我反而希望继续大量使用 AI。

它确实扩大了我能做的事情。

但我会越来越关注一个标准：

用了 AI 之后，我的 agency 是变大了，还是变小了？

Agency 很难用一个中文词完全翻译。

这里我理解成：

我仍然能够自己思考、判断、选择和行动。

AI 帮我理解一个问题之后，我是不是更有能力面对它？
AI 帮我做决定之后，我是否知道自己为什么这样选择？
AI 陪我整理一次情绪之后，我能不能回到真实生活里？
AI 帮我完成一项工作之后，我有没有逐渐理解这个工作，而不是越来越离不开它？

如果答案大体是“是”，我觉得这种依赖没有什么可怕的。

我开始给自己留几个很简单的检查点

1. 重要问题，先保留自己的第一版。

不用想得很完整。

哪怕先写三句话，再打开 AI。

我不希望所有 first thought 都由模型替我生成。

2. 多让 AI challenge，少用它反复 reassure。

“这个判断有什么漏洞？”

通常比：

“你觉得我做得对吗？”

对我更有帮助。

3. 情绪可以整理，但不要让 AI 替现实判案。

AI 可以帮助区分：

发生了什么，我有什么感觉，我做了什么解释，还可能有哪些其他解释。

但它不知道另一个真实的人心里究竟发生了什么。

4. 有些问题允许它暂时没有答案。

不是每一个问题都需要继续 prompt。

有时真正需要的不是多一轮分析，而是时间、现实反馈，或者去做一件具体的事。

5. 保留一点 AI-free 的生活。

自己读东西。
自己写几句话。
散步的时候不问任何人。
和真实的人聊天。
有些决定允许自己先做。

这不是为了训练某种“纯天然大脑”。

只是提醒自己：

这些能力我还想继续拥有。

Anthropic 这次投入 500 万美元研究 AI wellbeing，我觉得有意思的地方并不是“AI 又发现了一个风险”。

而是 AI 已经开始进入一个新的阶段：

我们过去主要问：

它还能替人做什么？

以后可能也需要越来越认真地问：

当它真的开始替我们做这么多事情之后，人应该保留什么？

我现在给自己的答案还很简单：

好的 AI 应该扩大人的 agency。

它可以让我更快、更有能力，也可以在一些时候陪我走一段。

但如果有一天把它拿走，

我希望自己只是变慢一点，

而不是突然不知道怎么思考、怎么选择、怎么和真实世界相处。

这大概是我现在对 AI wellbeing 最朴素的理解。

Day 096 · AI buzzwords 越来越多，哪些真的值得懂？

Mon, 31 Aug 2026 00:00:00 GMT

最近整理 AI-native 的时候，我顺手把这两年经常遇到的 AI 术语也梳理了一遍。

Agent、MCP、Context Engineering、Harness、Evals、Long-horizon、Skills、Memory、Multi-agent……

数量很多，而且还在不断增加。

我觉得没有必要背一份 50 个词的 glossary。

对 PM、builder，甚至只是希望更好理解 AI 产品的人来说，更有用的是：听到一个新词时，大概能判断它背后真的出现了新的能力或产品结构，还是只是给旧东西换了一个 AI 名字。

如果只看现在比较值得认识的一批，我会先记住这些：

Agent / Agentic workflowAI 不只回答问题，还可以调用工具、判断下一步并持续执行。现在最重要的产品范式之一，但 hype 也很多。

Long-horizonAI 能不能持续几十分钟甚至数小时，把一个复杂任务做下去。2026 年越来越值得关注。

Context Engineering管理模型在每一步到底应该看到哪些 instructions、history、tools、retrieval、memory 等信息。

Harness / Scaffolding围绕模型搭起来的运行系统，包括工具、执行循环、环境、权限、状态和反馈。

Agent Skills / Skills把专业流程、instructions、scripts、resources 等包装成 Agent 可以按需调用的能力。

Agent Memory / Memory让 Agent 从过去的交互和任务中保留、整理并重新使用信息，而不是每次从零开始。

MCP让 AI 应用用更标准的方法连接工具、数据和外部系统。重要，但它解决的是连接问题，不会让模型本身变聪明。

Evals先定义什么叫“做得好”，再系统性地测量。现在已经是 AI 产品工程的核心能力。

另外几个词也值得认识，但我不会在这篇展开：

Reasoning model、Multi-agent、Grounding、Guardrails、RAG。

前两个仍然很热，后三个已经更接近 AI 产品里的基础概念。

把这些词放在一起看，其实比逐个背定义更有意思。

因为它们共同反映了一件事：

AI 行业关注的问题，正在从“模型有多聪明”，慢慢扩展到“怎样把一个聪明的模型变成可靠的系统”。

从 Chat 到 Agent：工作的基本单位变了

以前使用 ChatGPT，最常见的单位是一次 interaction：

我问一句，它回答一句。

Agent 开始把这个单位变成：

一个任务。

用户给出目标以后，系统可以自己查资料、调用工具、修改文件、运行代码，再根据中间结果继续执行。

OpenAI 今年在讨论 Agent 对工作的影响时，就把这种变化描述成从短暂的 chatbot interaction，走向 delegated, long-horizon tasks。

这里的 Long-horizon 不只是“模型可以想久一点”。

真正困难的是：

Agent 工作了几十步以后，还记不记得最初目标？
中间状态变化了怎么办？
某一步失败以后能不能恢复？
context 快满了以后怎么处理？

一个任务从几十秒变成几十分钟甚至更久以后，这些问题都会被放大。

所以 Agent 和 Long-horizon 往前走，Context、Memory、Harness、Evals 也会一起变得更重要。

它们并不是随机同时流行起来的。

Prompt → Context：问题已经不只是“怎么问”

前几年谈怎么用好 LLM，经常绕不开 Prompt Engineering。

Prompt 当然依然重要。

但当 Agent 真正开始工作，需要管理的已经远远不只是一段 prompt。

Context Engineering 关心的是：

模型在这一刻，到底应该知道什么？

这里面可能包括：

system instructions、用户历史、当前任务状态、可用 tools、检索出来的数据、memory，以及前面几十步留下来的中间结果。

Agent 工作时间越长，这个问题越明显。

也不可能简单地把所有历史都一直塞进 context。信息过多，本身就可能影响模型表现。

所以才会出现 compaction、structured memory、just-in-time retrieval、sub-agent 等一整套处理方式。

我觉得 Context Engineering 是这几年少数很值得认真理解的新词。

它描述的是一个真实变化：

以前主要在优化“我应该怎么告诉模型”；现在还要设计“这个时刻应该让模型知道什么”。

Skills 和 Memory：Agent 怎么学会具体工作方式，又怎么利用过去的经验

这两个词我觉得也越来越值得关注。

Agent Skills / Skills

通用模型知道很多东西，但真实工作往往有自己的流程和方法。

一个公司的代码规范、审稿方法、数据分析流程、内部操作步骤，都不应该每次重新写成长 prompt 塞给 Agent。

Skills 的思路，是把这些 instructions、scripts 和 resources 组织起来，在需要完成对应任务时再加载。

所以它解决的其实是：

怎样把一个 general-purpose Agent，变成更懂某种具体工作方式的 Agent。

这和“模型有没有知识”不是同一件事。

一个模型可能知道怎么写代码，但它不一定知道：

这个团队怎么写代码、怎么 review、哪些步骤不能跳、哪些工具必须使用。

Skills 更像是在给通用能力增加一层可复用的方法。

Agent Memory / Memory

Memory 处理的则是另一个问题：

Agent 以前做过的事情，哪些值得留下来？

以后什么时候应该再拿出来？

这里也不只是“保存聊天记录”。

把所有历史原封不动塞给模型，很快会又长又乱。

真正有用的 Memory，需要考虑：

什么值得记？
怎么整理？
什么时候检索？
哪些信息已经过期？
哪些东西应该被忘掉？

当 Agent 从一个一次性工具，慢慢变成长期一起工作的系统时，Memory 自然会从一个小 feature，变成系统设计问题。

所以我现在理解 Agent Memory 时，更愿意把它看成：

把过去的 interaction 变成以后真正能用的 context。

而不是简单的“AI 记得越多越好”。

Model → Harness：很多产品差异其实发生在模型外面

Harness 是我最近觉得特别值得认识的一个词。

可以粗略理解成：

让模型真正能够作为 Agent 工作的外围运行系统。

比如：

模型能调用哪些工具？
怎么循环执行？
在哪个环境里运行？
什么时候需要用户批准？
状态怎么保存？
context 满了怎么办？
失败以后怎么 retry？
它做过什么，怎么留下记录？

这些都不是模型本身的能力。

两个 AI 产品即使调用同一个基础模型，最终表现也可能差很多。

因为它们可能给模型：

不同的 context、不同的 tools、不同的 permissions、不同的 feedback loop，以及完全不同的 execution environment。

这也是我现在看 AI 产品时越来越在意的一点：

看到一句：

信息量已经很有限了。

更值得继续问的是：

模型外面搭了什么？

大家可以买到类似的 frontier model。

真正决定产品能不能稳定工作、敢不敢交给真实用户的，经常是外围这一整套系统。

所以 AI-native 的很多差异，其实发生在模型之外。

MCP 很重要，但它解决的是连接问题

MCP 已经不算 AI 新词了。

它解决的问题相对明确：

怎样让 AI client / Agent 更标准化地连接 tools、data 和外部系统。

以前不同 AI 应用连接 Google Drive、数据库、GitHub 或内部系统，往往各做各的 integration。

MCP 想做的是把这层连接标准化一些。

这很重要，因为 Agent 如果只能待在聊天框里，能完成的事情终究有限。

但这里也很容易 hype。

一个产品说：

“我们支持 MCP。”

并不代表它突然有了什么 AI moat。

MCP 解决的是连接与 interoperability。

连接上一个系统，和知道怎样把事情做好，是两层不同的问题。

有点像支持 HTTP 对互联网产品当然很重要，但支持 HTTP 本身并不能说明你的产品好不好。

Demo → Evals：能跑起来以后，怎么知道它真的变好了？

Evals 可能是这批词里最不 buzzword 的一个。

它做的事情非常朴素：

先定义什么叫成功，再用可重复的方法去测。

AI 系统麻烦的地方是，它不像传统 deterministic software 那么容易测试。

同一个任务跑几次，结果可能不一样。

换一个模型、改一段 prompt、增加一个 tool，某些 case 可能变好，另外一些又退化。

Agent 更复杂。

它可能跨很多轮调用工具、修改环境，中间任何一步出错，都可能影响后面的结果。

所以评估 Agent 时，看的已经不只是最后一句答案。

还可能包括：

它走了怎样的 trajectory？
工具有没有正确使用？
有没有完成最终任务？
环境最后处于什么状态？

这也是为什么我越来越觉得：

Evals 不只是最后 QA 验收的时候才做。

它其实属于产品定义的一部分。

一个团队首先得说清楚：

我们所谓的“AI 做得好”，到底是什么意思？

这个问题如果一直很模糊，后面的优化也很容易变成：

“我试了一下，好像不错。”

Reasoning 和 Multi-agent 呢？

这两个词我仍然会认识，但不会放在这篇的主线上。

Reasoning model 是真实的模型能力变化：模型在回答复杂问题时投入更多 inference-time compute。

但它更偏模型层。

而这篇我更关心的是：模型能力已经很强之后，产品层开始发生什么。

Multi-agent 也是真东西。

多个 Agent 可以分工、并行、互相检查，某些复杂任务确实适合这样做。

但它也非常容易被过度设计。

一个 Agent 能解决的问题，没有必要为了听起来先进，硬拆成五个 Agent 开会。

所以看到 “multi-agent system”，我不会天然觉得比 single-agent 更高级。

还是要看：

为什么需要多个？它具体解决了什么问题？

Buzzwords 其实也可以当行业地图看

把这些词按时间放在一起，我觉得能看到一条挺清楚的变化。

前几年大量讨论：

Prompt Engineering

重点是怎么让模型回答得更好。

后来大量讨论：

Agent / Tool use / MCP

模型开始需要从“回答”走向“行动”。

现在越来越常见的是：

Context Engineering / Harness / Long-horizon / Skills / Memory / Evals

关注的问题变成：

怎么让 Agent 拿到正确的信息；
怎么让它掌握特定工作方式；
怎么让它保留真正有用的经验；
怎么让它持续工作；
以及怎么知道它到底有没有把事情做好。

所以 buzzword 不一定只是 marketing。

有些词突然被大量工程团队讨论，是因为技术往前走了一步以后，新的瓶颈开始真正卡住产品了。

从这个角度看，新词本身也可以当作一张行业地图。

它会告诉你：

现在大家正在解决什么问题。

怎么判断一个 AI buzzword 值不值得学？

我大概会看四件事：

它描述了什么以前没有的新能力？
它解决了哪个真实存在的限制？
它有没有改变产品的 workflow、architecture 或 economics？
如果真的在做产品，这个概念会改变我的某个设计决定吗？

如果答案都很模糊，它可能暂时只是一个好听的标签。

如果它会影响怎么组织 context、怎么给权限、怎么连接工具、怎么保存状态、怎么测试质量，那就值得认真一点。

AI 术语大概还会继续快速增加。

全部记住没有太大必要。

更有用的是慢慢能看出来：这些新词背后，到底发生了什么真实变化。

Day 095 · 到底什么才算 AI-native？

Sun, 30 Aug 2026 00:00:00 GMT

最近一次面试里，我被问到一个现在很常见的词：

AI-native

这个词我以前也经常看到。我的理解大致是：它不是简单地在原有产品里接入一个大模型、增加几个 AI 功能，而是 AI 更深入地影响产品本身的设计。

但这个定义还是很宽。

现在一个 SaaS 加了 AI summary，可以说自己 AI-native；一个公司大量使用 Copilot，也可以说自己正在成为 AI-native organization。招聘 JD、产品官网、融资稿里都很常见。

所以我后来重新整理了一下这个概念。

我觉得判断一个产品是不是 AI-native，重点不在于“有没有用 AI”，也不一定在于“是不是从 Day 1 就用了 AI”，而在于：

AI 到底改变了这个产品的什么？

最基本的区别：AI 是一个功能，还是已经进入产品的核心结构？

IBM 对 AI-native 的定义大意是：

AI 从一开始就是核心组成部分，而不是后来外挂进去的功能；它会进一步影响产品架构、决策、用户体验和整个系统生命周期。

这里的“从一开始”其实不用理解得太字面。

一家已经存在十年的软件公司，同样可能因为 AI 重新设计自己的核心产品。

比如一个传统客服系统，本来有工单、搜索和模板回复，后来增加一个 AI summary。

这是一个很好用的 AI feature。

但如果 AI 开始参与理解客户历史、查询相关系统、判断下一步、生成处理方案，而人的角色逐渐变成审核和纠偏，变化就明显更深了。

这时候 AI 改变的已经不只是一个功能，而是整个 workflow，以及人与系统之间的分工。

所以比“它是不是从 Day 1 就用了 AI”更值得看的，是：

AI 有没有改变产品的核心价值、workflow、系统结构，甚至 economics？

我现在大概会从四个地方判断。

1. 核心价值有没有变化？

以前很多软件要求用户自己知道：

去哪个页面、填什么字段、点什么按钮、按什么顺序操作。

AI 产品开始出现另一种可能：

用户先表达自己想完成什么，系统再帮助判断应该怎么做。

变化不只是多了一个聊天框。

产品和用户之间的分工开始变化。

过去的软件更多是在帮助用户完成一系列操作；现在一些 AI 产品开始承担其中一部分判断和执行。

比如用户不再需要明确告诉系统：

先查这个数据，再打开那个页面，再执行下一步。

他可能只需要给出一个目标，系统自己理解 context、调用工具、处理中间结果，在需要的时候再让人审核或纠偏。

OpenAI 在谈 Agent 时经常使用一个词：delegation。

我觉得这个词很准确。

AI-native 的一个重要变化，就是软件开始从“帮助用户操作”，逐渐走向“接受一部分任务委托”。

当然，并不是所有产品最后都会变成全自主 Agent。

真正重要的是：AI 是否开始承担过去必须由用户明确决定的一部分工作。

2. Workflow 有没有真的重做？

很多所谓 AI 产品，其实仍然是：

原来的 workflow + 一个 AI button。

原来写报告需要填十个字段，现在旁边多了一个：

Generate with AI

功能可能很好用，但流程本身并没有发生太大变化。

更深入的 AI 产品设计，会重新考虑整个 workflow：

用户到底还需要输入多少？
哪些步骤可以由系统自己决定？
什么时候应该问人？
什么时候可以继续调用工具？
做错以后怎么恢复？
人是在操作每一步，还是逐渐变成设定目标、审核和纠偏？

于是流程不再完全是固定的：

step 1 → step 2 → step 3

中间会出现更多由 context、模型判断和运行结果决定的动态路径。

这也是为什么 Agent、tool use、context engineering 这些概念会一起变得重要。

当系统可以自己判断下一步，产品设计自然也不能只考虑页面和按钮了。

3. 模型外围会多出一整套新的产品能力

这一层是我以前比较容易忽略的。

如果只是做一个很简单的 AI 功能，看起来可能就是：

prompt → response

接入模型 API，拿到结果。

但一旦 AI 真正进入核心 workflow，很快会遇到很多额外问题：

模型现在知道什么？
可以访问哪些数据？
能够调用哪些工具？
有没有权限执行这个动作？
出错以后怎么办？
怎么知道新模型到底让产品变好了，还是变差了？

于是产品外围会慢慢长出：

context、memory、tools、permissions、guardrails、evals、observability、fallback……

这些东西以前当然也不是完全不存在，但 AI 产品会明显放大它们的重要性。

这也是我现在觉得 AI-native 很容易被误解的地方。

大家很容易把注意力全部放在模型本身：

用了哪个模型？
是不是最新的？
benchmark 高不高？

但真正到了生产环境，模型只是系统的一部分。

大家可以买到类似的模型能力，真正决定产品能不能稳定工作、敢不敢交给真实用户的，经常是模型外围这一整套系统。

所以我现在反而觉得：

AI-native 的“native”，很多时候体现在模型外围。

4. 连 economics 都可能跟着变化

AI 产品还有一个很现实的区别：

使用本身会持续产生计算成本。

一个复杂任务可能包含模型调用、检索、工具执行、长 context、多轮 reasoning，失败以后还可能重新运行。

于是产品很早就需要考虑：

什么任务值得用更强、更贵的模型？
什么时候可以 routing 到更便宜的模型？
一个 Agent 可以运行多久？
给用户多少额度？
按 seat、usage、task，还是最终结果收费？

这些已经不只是技术问题。

它们会直接影响产品体验、margin 和商业模式。

传统 SaaS 里，很多功能开发完成以后，用户多点一次按钮带来的边际成本很低。

AI 产品不一定如此。

所以如果 AI 真正进入产品核心，它有时候会一路从 UI、workflow、system architecture，影响到 economics。

AI-native 更像一个程度，而不是一道分界线

所以我现在不太想把所有产品简单分成：

AI-native / 非 AI-native。

更接近一个逐渐深入的过程。

AI feature

在原来的产品里增加生成、总结、搜索等 AI 能力。

AI-enabled

AI 已经明显改变一些重要 workflow，但大部分产品结构仍然沿用过去的方式。

AI-native

AI 开始影响产品提供什么价值、用户怎么完成任务、系统怎样运行，以及产品怎样被评价和收费。

这个边界当然不会非常精确。

而且 AI-native 本身已经被 marketing 用得很泛。

未来如果 AI 真像互联网一样逐渐成为默认基础设施，这个词可能也会慢慢失去区分度。

今天我们已经不会特别说：

“这是一个 internet-enabled product。”

因为默认就是。

AI-native 以后也有可能走到类似的位置。

所以我现在怎么判断一个产品是不是 AI-native？

我不会因为一个产品用了最新模型、有聊天框、有 Agent，或者官网写着 AI-native，就直接接受这个标签。

我会看几个更具体的地方：

AI 改变了产品的核心价值吗？
它改变了用户完成任务的 workflow 吗？
它是否要求系统重新处理 context、tools、permissions、eval 和 failure？
它有没有进一步改变成本结构和商业模式？

如果这些基本都没有，只是原来的软件增加几个 AI feature，那么 AI-native 更多还是一个包装。

如果 AI 的存在已经让产品需要重新设计核心逻辑，这个词才真正开始有信息量。

这也是我现在面对很多 AI buzzwords 时越来越常用的判断方式：

先不看它叫什么。

先看：

它到底让什么东西和以前不一样了？

Day 094 · AI 越会写，“检测 AI”也成了一门生意

Sat, 29 Aug 2026 00:00:00 GMT

昨天在 Substack 发文章时，我第一次注意到一个功能：

Scan for AI text。

顺手点了一下，结果非常干脆：

AI-generated 100%AI-assisted 0%Human 0%

第一反应是：这么绝对？

第二反应却是：好像也不能说它判错了。

因为如果回头看这篇文章的生产过程，经历、观点和判断来自我，什么值得写、哪些结论不成立，也是我一轮轮改出来的。

但最后的英文 prose，first draft 确实大量来自 ChatGPT。

我提供中文原稿、想法和反馈，AI 生成英文，然后我继续删、改、重组。

所以这个 100% 反而让我产生了一个问题：

AI detector 到底在检测什么？

查下去以后，我又发现了另一件更有意思的事：

AI 越来越会生成内容，“检测是不是 AI 生成的”本身也已经成了一门生意。

AI detector 已经不只是找“AI 味”了

Substack 在今年 7 月加入了 AI text detection，底层使用一家叫 Pangram 的公司的模型。读者可以主动扫描新发布的文章、Notes 和评论，判断其中的文字有多少属于 Human、AI-Assisted 或 AI-Generated。

我以前对 AI detector 的印象，还停留在通过一些语言统计特征，判断文章是不是过于规整、过于可预测。

现在已经复杂很多。

Pangram 最新的模型会判断文本中的不同部分更接近 Human、AI-Assisted 还是 AI-Generated。训练时，他们会拿真实人类文章，让不同 LLM 生成主题、长度和 tone 接近的“镜像版本”，逼着 classifier 学习比“写得很工整”更细的差异。

他们还会专门找出那些被模型误判成 AI 的真人文章，再拿回来继续训练。

这个思路我觉得挺聪明：

越像 AI 的真人，反而越值得拿来教 detector。

所以我们平常说的“把 AI tone 去掉”，和机器检测的东西并不完全是一回事。

AI tone ≠ AI provenance。

读起来不像 ChatGPT，不代表机器就一定看不出其中的 AI generation signal。

而且 detector 的能力确实在进步。今年一项同行评审研究比较了 Pangram、GPTZero、Copyleaks 和 Turnitin，在 fully AI、hybrid 和 humanised AI 文本上，Pangram 整体表现最好。不过研究者同样提醒，这类工具仍然应该辅助判断，而不适合独自承担高风险决策。

那我的“100% AI”到底是什么意思？

这里也很容易误解。

它不是在说：

Pangram 有 100% 的数学把握证明这篇文章是 AI 写的。

更接近的是：这篇文章里的文本，被它整体判断成了 AI-generated provenance。

放到我的文章上，这个区别特别明显。

它能看到最后的英文句子，却不知道为什么我要写这件事，经历是谁的，观点是谁提出的；也不知道哪些建议我拒绝了，哪些地方来回改过很多轮。

所以 detector 比较擅长回答：

这些文字更像是怎么生成出来的？

它回答不了：

这些想法是谁的？

以前这两个问题经常重合。一个人想，也由这个人写。

人和 AI 开始共同创作以后，它们慢慢分开了。

所以说我的文章完全 Human-written，不准确；如果说它是“100% AI 创作”，我也不会认。

更接近真实情况的是：

思考和判断主要来自人，英文 prose generation 大量借助了 AI。

Detector 看到的主要是后者。

为什么这种东西真的有人愿意花钱买？

这是我查 Pangram 时最感兴趣的部分。

如果 AI detector 只是满足一下：

“让我看看这是不是 ChatGPT 写的。”

很难想象它有什么大的商业价值。

真正有价值的场景，是内容的产生方式会影响我们如何使用这份内容。

比如学生论文。

老师并不缺那 2000 字。他想通过作业判断学生有没有理解问题、做过研究、能够组织和表达。

以前一份作业多少可以作为这些能力的证据。

AI 出现以后，作品和能力之间的关系没那么直接了。

招聘也一样。Cover Letter、writing sample、take-home assignment，本来都被用来了解候选人的表达和思考能力。现在看到一份漂亮的材料，招聘方需要多问一步：它到底还能代表这个人的多少能力？

内容平台则面对另一个问题。

如果我订阅一个作者，我通常不只是为了获取几百字信息，也是在关注这个人的经验、判断和观察方式。

当批量生成优质文字变得越来越便宜，读者自然会开始关心：

我看到的东西，究竟能代表这个人的什么？

这些不是假设中的使用场景。

Pangram 已经把产品卖给学校和大学，也提供企业产品和开发者 API。官方列出的 API 用法包括把检测结果作为产品决策层、审核队列 signal，或者批量扫描历史内容；Quora 就在用它处理 AI-generated answers。

它也已经形成了很明确的商业化产品：个人订阅每月 20 美元，Professional 每月 65 美元，另外还有按量收费的 API、教育机构 license 和企业方案。

更直接的市场信号是，今年 7 月 Pangram 刚拿到 900 万美元融资，由 Menlo Ventures 领投。TechCrunch 报道中提到，它的 API 客户已经包括 Substack、Quora、学校和大学、出版机构、代理商和招聘团队。

融资当然不能证明这个市场最后一定有多大。

但至少说明这已经不只是一个“学术界担心学生作弊”的小工具：

平台、机构、企业和资本，都开始认为 AI-generated content 带来的真实性和验证问题值得花钱解决。

AI 让一些原来默认成立的信号变弱了

这几个使用场景其实有一个共同点。

以前看到一篇论文，我们默认有人完成了研究和写作。

看到一份 writing sample，我们默认它多少代表这个人的表达。

看到一个作者持续输出，我们也默认自己正在接触这个人的思考。

这些都是内容过去自带的隐含信息。

AI 没有让内容消失。

它只是让内容与背后的人之间的关系变得没那么确定了。

于是才会需要新的 signal。

Detection 是一种。

作者主动说明 AI 怎样参与，是 disclosure。

更进一步，如果能够可靠记录一份内容从哪里来、经过什么处理，就是 provenance。

它们都在补同一个缺口：

当最终结果已经不能完整说明它是怎么产生的，我们还需要什么信息，才能正确理解自己看到的东西？

当然 detector 解决不了全部问题。

尤其 hybrid writing 越来越普遍以后，简单分成“用了 AI / 没用 AI”，本身已经有点粗糙。

所以我更愿意把检测结果理解成一个需要进一步解释的 signal，而不是判决书。

我最感兴趣的是 AI 带来的“反向市场”

这是这次研究让我觉得最有意思的地方。

现在谈 AI 创业、AI 产品机会，我们习惯顺着模型能力看：

AI 又能做什么了？
哪些工作终于可以自动化？
哪里可以更便宜、更快？

这当然是最直接的一层机会。

但技术真正大规模进入现实以后，还会发生另一件事：

它会让一些旧机制失效，同时制造新的成本、风险和信息不确定性。

于是第二层市场会跟着出现。

Email 普及以后，垃圾邮件变得极其便宜，于是 anti-spam 变成基础设施。
互联网和线上交易越重要，攻击、欺诈和身份冒用的价值越高，于是 cybersecurity、fraud detection、identity verification 一路成长。
生成式 AI 现在也在走同样的路。

AI 可以低成本生产大量内容，于是 detection、provenance、content authenticity 开始有价值。

AI Agent 可以替人采取行动，permission、guardrail、audit trail、observability 就会变得更重要。

LLM 可以给出越来越像真的答案，于是 grounding、evaluation、source verification 也随之变得重要。

AI coding 可以大幅提高代码生产速度，后面自然会有人需要解决 generated code 的测试、安全、质量和维护问题。

这些产品看起来好像都没有在“增强 AI”。

有些甚至专门在检查它、限制它、给它加边界。

但它们和 AI 的增长并不矛盾。

恰恰是因为前面的能力越来越强，后面的需求才会越来越真实。

我后来觉得，“反向市场”这个说法虽然挺形象，但严格来说它也不完全是逆着 AI。

它更像是 AI 普及以后产生的二阶市场：

第一层市场创造新能力。

第二层市场处理这些能力普及之后带来的新问题。

这个角度对我自己看 AI 产品机会还挺有用。

以后看到一个新的 AI capability，除了问：

它现在能替人做什么？

我可能还会继续问：

它把什么东西变得极其便宜了？
原来哪些判断、规则或者信任机制因此不再好用？
新的欺诈、滥用、错误或者不确定性会出现在哪里？
这些问题最终由谁承担成本，又有谁会愿意花钱解决？

Pangram 就是一个很具体的例子。

生成式 AI 让文字越来越便宜、越来越像人。

于是“这些文字到底怎么来的”——一个过去几乎没人需要专门购买的答案——也开始有了价格。

AI 的机会，不一定都在继续让 AI 做得更多。

有些机会，会出现在 AI 做得越来越多以后。

Day 093 · 传统 PM 想转 AI，先别急着把所有技术补一遍

Fri, 28 Aug 2026 00:00:00 GMT

这是「现在公司到底在招什么样的 AI PM」系列最后一篇。

这一轮我整理了截至 2026 年 8 月 20 日的 43 个公开 AI 产品岗位，又参考了 Stanford AI Index、PwC AI Jobs Barometer 等招聘市场研究。

前三篇做了三件事：

第一篇先看，所谓 AI PM 到底包含哪些不同的工作；

第二篇拆了，不同岗位对“技术”的要求究竟差在哪里；

第三篇再看，为什么 Evals、Harness、Forward-Deployed 这些以前不常见的分工开始出现。

写到这里，其实很容易产生一个副作用：

更焦虑了。

原来以为 AI PM 可能学学 Prompt 就好。

现在发现还有：

Python、RAG、Agent、Evals、MCP、Harness、System Design、Model Behavior……

而且这个列表每天都还在变长。

所以最后一篇，我想把问题重新收回来：

如果过去不是 AI PM，现在到底应该怎么找到自己的位置？

我现在反而越来越不建议从：

“AI PM 需要会什么？”

开始。

因为这个问题太容易把人带进一张永远学不完的清单。

第一步：先盘点自己已经有什么，不要先盘点自己不会什么

这是我觉得有经验的 PM 转 AI 时，最容易忽略的一件事。

做了几年甚至十几年产品以后，过去的积累可能是：

Payments；Healthcare；Search；Developer Tools；Risk；Enterprise SaaS；Design；Data Product；Customer Delivery；Growth。

AI 出现以后，这些经验并没有突然失效。

真正值得问的不是：

我要不要把自己重新训练成一个“AI 人”？

而是：

我过去最有壁垒的经验，和 AI 的哪一层结合以后，会变得更值钱？

例如：

Search / Recommendation→ Retrieval / Personalization / Model Product

API / Platform→ Agent Platform / Harness

Risk / Trust & Safety→ Evals / Safeguards

Finance / Healthcare / Legal→ Vertical AI

Enterprise SaaS→ AI Transformation

Solutions / Consulting→ Forward-Deployed

Consumer / Growth→ Applied AI

从这里开始，路线会一下缩小很多。

第二步：选择产品层，不要只选择一个大标签

前三篇里其实一直有一个共同结论：

“AI PM”这个词太大了。

如果粗略把 AI 产品想成：

模型↓Platform / Harness↓Evals / Safety↓应用↓行业工作流↓企业部署

不同层需要的人完全不同。

一个长期做 Enterprise Workflow 的 PM，如果花半年时间硬补 Pre-training，希望直接和 ML Research 背景的人竞争 Core Model PM，我不确定这是最好的投入。

反过来，一个长期做 ML Platform 的人，如果只去申请一个普通 AI Chatbot PM，也可能把自己的壁垒浪费掉了。

所以问题不是：

哪一种 AI PM 最厉害？

而是：

哪一层 AI，会放大我本来就很强的东西？

我觉得这比“我还缺多少 AI 技能”重要得多。

第三步：用 Evidence 替代“我学过 AI”

课程、文章、Tutorial 当然都有价值。

进入一个新领域，总要先学习。

但从招聘角度：

“我学习过”证明的是：我接触过。

它很难证明：我真的会做。

这轮看 JD，一个很明显的趋势就是：

Hands-on、Prototype、Evals、Failure Handling、Model Quality、Python、SQL……

越来越常出现。

所以如果真的要补 AI 产品经验，我反而会倾向于：

少做几个 Demo，把一个项目做深。

一个有说服力的 AI 项目，至少应该能回答这些问题。

为什么这里需要 AI？

为什么不用普通规则、搜索或者 Workflow Automation？

系统是怎么分工的？

Model 做什么？Rule 做什么？Tool 做什么？人做什么？

怎么知道它做得好不好？

Baseline 是什么？Test Set 怎么来的？Rubric 怎么定？

它最容易怎么坏？

Hallucination？Wrong Tool？Permission？Context？Latency？

坏了以后怎么办？

Retry？Fallback？Reject？HITL？

真正上线以后看什么？

Quality？Task Success？Latency？Cost？Reliability？

如果一个项目可以把这些东西讲清楚，我觉得它比十个：

“我用 AI 做了一个 XXX”

更有说服力。

第四步：看见一个不会的词，先判断它到底是什么

现在看 AI JD，很容易发生一个动作：

看到一个陌生词。

然后立刻记进：学习清单。

其实我觉得可以先把缺口分成三类。

A. 这是这个岗位的核心能力

比如：

想申请 AI Eval PM，却完全不知道 Evaluation 怎么设计。

这个确实需要补。

不是学一个工具，而是能力本身缺失。

B. 这是一个具体工具

比如：

已经理解 Agent Workflow，也做过 Tool Calling，只是没有用过 LangGraph。

这种情况下，不会某个 Framework，并不等于不会这类工作。

工具会换得很快。

不会一个工具，和缺少一种能力，是两回事。

C. 这个岗位其实根本不需要

例如：

申请 Healthcare Applied AI PM，却因为不会训练模型而焦虑。

或者申请 AI Transformation，却觉得自己是不是应该先系统学一遍 PyTorch。

很可能只是补错方向。

这一点在 AI 领域尤其重要。

因为新名词实在太多，很容易把：

“我不知道这个词”

误判成：

“我缺少竞争力。”

第五步：找到自己的那个交叉点

如果一定要把定位压缩成一个公式，我现在会写成：

过去的壁垒 × AI 产品层 × 可验证 Evidence

而不是：

工作年限 × AI 技能数量

例如：

Enterprise PM × AI Automation

Healthcare × AI Agents

Risk × AI Evals

Developer Platform × Agent Infrastructure

Design × Human-AI Interaction

Customer Delivery × Forward-Deployed AI

我觉得这类说法比：

“我以前做 X，现在想转 AI。”

更有力量。

因为后一种叙事很容易把过去和未来切成两段：

过去的不算了，现在重新开始。

但现实通常不是这样。

更可能是：

过去一直在解决某一类问题，而 AI 正在改变这类问题的解决方式。

这时候所谓“转型”，其实更像一次重新组合。

当然，也不是所有过去经验都会自动变成壁垒

这一点还是要说得诚实一点。

如果过去很多年的主要工作一直是：

协调；跟进；写需求；开会；推动项目；

但很少形成：

独立的产品判断、技术理解、行业知识、数据能力、明确的产品结果，

那“Senior PM”这个 Title 本身，并不会自动变成 AI PM 的优势。

AI 反而正在提高一些要求：

更快地实验；
更靠近系统；
更明确地定义质量；
更独立地判断 Trade-off。

所以工作年限当然仍然有价值。

但公司重新定价的，可能不是：

你做了多少年。

而是：

这些年到底积累出了什么不容易被替代的判断。

如果今天重新规划一次 AI PM 转型，我会按这个顺序

不是先打开课程网站。

而是先做四步：

1. 找 10 个自己真的会投的 JD

不要找“看起来最厉害”的。

找自己现实中愿意申请的。

2. 看它们到底属于哪一层 AI 产品

Model？

Platform？

Applied AI？

Vertical AI？

Transformation？

Forward-Deployed？

3. 找共同要求

不要记录所有关键词。

只找反复出现的：

核心能力。

4. 再把自己放进去

分成三栏：

我已经有 Evidence 的

我懂，但 Evidence 不够的

我真的不会、而且岗位确实需要的

最后这一栏，才应该进入学习计划。

一个很简单的定位表

如果现在正在考虑 AI PM，可以先填这四行：

我过去最有壁垒的问题域：＿＿＿＿＿＿＿＿＿＿

最能放大这个壁垒的 AI 产品层：＿＿＿＿＿＿＿＿＿＿

我已经可以证明的 AI 能力：＿＿＿＿＿＿＿＿＿＿

真实 JD 反复出现、但我目前缺少的核心能力：＿＿＿＿＿＿＿＿＿＿

填完以后，学习清单通常会比最开始短很多。

而且更接近真实市场。

这组 research 做到最后，我自己的感受反而不是：

“AI PM 要学的东西好多。”

而是稍微相反。

不是所有东西都需要学。

AI 变化太快，靠把一张技能清单全部划掉来获得安全感，大概永远等不到那一天。

更值得先弄明白的可能一直都是两个问题：

我本来最擅长解决什么问题？

然后：

AI 出现以后，哪里开始更需要这种能力？

一个人的位置，很多时候就藏在这两个问题的交叉处。

「现在公司到底在招什么样的 AI PM」系列 4/4。整组研究基于截至 2026 年 8 月 20 日整理的 43 个公开 AI 产品岗位，并参考 Stanford AI Index 2026、PwC 2026 AI Jobs Barometer 等资料。前三篇分别讨论了 AI PM 的岗位分类、不同职位的技术要求，以及 Evals / Harness / Forward-Deployed 等新分工；这一篇是整个系列最后的落点：知道市场在招什么以后，怎么重新判断自己的位置。

Day 092 · Evals、Harness、Forward-Deployed：AI 招聘里，正在长出一些以前没有的工作

Thu, 27 Aug 2026 00:00:00 GMT

Evals、Harness、Forward-Deployed：AI 招聘里，正在长出一些以前没有的工作

这是「现在公司到底在招什么样的 AI PM」系列第三篇。

前两篇先做了两件事：

第一篇把 AI PM 拆成了几种完全不同的工作；

第二篇再看，不同岗位所谓的“技术要求”，到底差在哪里。

整理到这里以后，我发现另一个挺有意思的变化：

AI 产品团队本身，也正在重新分工。

截至 2026 年 8 月 20 日，我整理的 43 个公开 AI 产品岗位里，除了比较熟悉的 AI Product Manager，还反复出现了一些几年前很少见的名字：

AI Evaluations、Agent & Harness、Model Behaviors、Human Data Platform、Safeguards、Forward-Deployed……

一开始看到这些词，很容易觉得：

AI 行业是不是又在发明新名词？

但把 JD 逐条看下来以后，我反而觉得它们出现得很自然。

一个行业开始成熟时，经常会发生一件事：

原来由某个人“顺便负责”的问题，慢慢复杂到需要一个明确的 Owner。

AI 现在正在经历这个过程。

1. Evals：有人开始专门负责“什么叫好”

Evals 很容易被理解成：

AI 版 QA。

但它和传统测试其实有一个很根本的区别。

普通软件里，我们经常可以提前写清楚：

输入是什么，正确输出应该是什么。

AI 不一定。

同一个问题可以有很多合理答案；一个版本整体变好了，也可能在某些关键场景退化；平均分很高，也可能偶尔犯一个完全不能接受的错误。

所以 Eval 首先要回答的甚至不是：

测试有没有通过？

而是：

到底什么算好？

接下来才是：

测试什么；Test Set 从哪里来；Rubric 怎么定义；哪些能用规则判断；哪些可以 LLM-as-a-Judge；哪些必须人工 Review；模型换版本以后如何做 Regression；线上出现的新 Failure 怎么重新进入测试集。

Box 现在就有一个直接叫 Product Manager, AI Evaluations 的岗位。

PM 会负责 Dataset、Graders、Offline / Online Evaluation、Model Selection 等工作。

这时候 Eval 已经不只是“产品做好以后测一下”。

它开始影响：

模型怎么选、产品怎么迭代、什么时候可以上线。

所以我现在更倾向于把 Evals 理解成：

AI 产品里的质量基础设施。

即使未来并不是每家公司都有一个专门的 Eval PM，这套能力也很可能会进入越来越多普通 AI PM 的工作里。

2. Harness：模型之外，还有一整层东西决定 Agent 好不好用

Harness 是我最近才越来越认真理解的一个概念。

不同公司对它的边界并不完全一样，所以我不太想给它一个特别死的定义。

如果一定要用一句比较直白的话来说：

模型负责“想”，Harness 负责让它在一个真实系统里“做事”。

一个 Agent 真正运行起来，往往还需要：

Context；Memory；Tools；Permissions；Sandbox；Orchestration；Retry；Fallback；Observability；Evaluation。

以前这些事情很容易被看成 Engineering Detail。

但当 Agent 不再只是回答一句话，而是开始：

调工具、查数据库、改文件、提交请求、执行真实动作，

以后，它们就直接变成产品问题了。

例如：

这个 Agent 到底可以看到什么？

哪些工具能调用？

什么操作必须要求确认？

如果执行到一半失败，是重试、回滚，还是交给人？

它为什么做出这个决定，有没有 Trace 可以看？

Binance 已经直接出现了：

Product Manager, AI Agent & Harness

JD 里会明确涉及 Task Flow、Capability Boundary、Failure Fallback、Harness Evaluation、Task Set 等。

我觉得这个职位名称本身挺有意思。

它说明有些公司已经不再把 Agent 周围这一层当成：

“模型接上几个 API 就好了。”

而是开始把它当成一个需要长期设计和经营的产品系统。

3. Model Behaviors：连“模型应该怎么表现”也开始有 Product Owner

Anthropic 目前还有一个让我觉得很新鲜的岗位：

Research Product Manager, Model Behaviors

模型能力过去很容易被想成：

数学 Benchmark 多高；Coding 能力多强；知识覆盖多广。

但真实使用里，还有一批更难用单一 Benchmark 表达的问题：

不知道的时候，要不要承认不知道？

面对模糊要求，是直接猜，还是先澄清？

什么时候应该拒绝？

怎样表达不确定性？

会不会为了让用户开心而过度迎合？

面对冲突指令怎么办？

这些其实都会强烈影响产品体验。

也就是说，AI 时代 PM 负责的“产品对象”正在往前延伸。

以前我们主要设计：

页面、流程、功能。

现在甚至开始有人专门负责：

模型应该怎样表现。

而且这件事需要研究、数据、Eval 和产品判断一起完成。

4. Human Data Platform：人类反馈也开始变成一个产品系统

AI 背后其实一直有很多“人”。

有人需要判断：

两个答案哪个更好；

这个结果有没有风险；

Agent 到底算不算完成任务；

哪一种错误更严重。

数量少的时候，可以手工解决。

规模变大以后，很快就会出现一整套问题：

任务怎么设计？谁适合来判断？不同人的标准一致吗？怎么质检？成本怎么控制？哪些反馈进入 Training？哪些进入 Eval？

Anthropic 现在就有 Human Data Platform 相关的 Product Management 岗位。

我觉得这个变化也很能说明问题：

人类反馈不再只是一个后台 Operations 环节。

它本身也需要：

平台、流程、质量标准、工具和产品设计。

换句话说：

“Human in the Loop”里的 Human，也开始被系统化。

5. Safeguards / Safety Measurement：安全从原则变成指标和系统

过去讲 AI Safety，很容易停留在：

AI 应该安全。

当然没错。

但真正做产品时，这句话远远不够。

还需要继续问：

具体有什么 Harm？

怎么检测？

Safeguard 有没有真的减少风险？

False Positive 多高？

哪些风险可以接受？

哪些风险必须阻断？

出了一次事故，怎么进入下一轮产品迭代？

OpenAI 现在有 Safety Measurement PM。

Anthropic 的招聘里则已经进一步拆出：

Rare Harms、Child Safety、Vertical Safeguards 等不同方向。

安全到了这里，已经不只是 Policy。

而是：

Metric + System + Operations + Product Decision。

我觉得这也是 AI 产品和普通软件差异很明显的一块。

很多“价值判断”，最后都需要被翻译成：

系统到底怎么工作。

6. Forward-Deployed PM：有人专门负责把 Demo 送进真实世界

Forward-Deployed 是这轮 research 里我之前关注得比较少，但后来越来越觉得重要的一类。

Scale AI 现在就在招 Forward Deployed Product Manager。

这类 PM 不只是：

收需求 → 写 PRD → 回总部排 Roadmap。

而是会深入客户现场：

理解业务问题；接数据和 API；一起构建 Prototype；测试；部署；再把一次性的客户方案慢慢抽象成可以复用的标准产品。

所以它有点像：

PM + Solutions Architect + Consultant + Builder。

为什么 AI 公司现在越来越需要这种人？

可能因为今天做一个 Demo 已经没有那么难。

真正困难的是：

客户的数据很乱；权限系统很复杂；流程里有大量例外；组织里没有人愿意改变工作方式；模型效果到了真实场景就开始下降。

很多 AI 项目最后卡住的地方已经不是：

模型还不够聪明。

而是：

它没有真正进入工作流。

Forward-Deployed 其实是在专门解决这个“最后一公里”。

7. AI Transformation：还有人开始负责一家公司的 AI Product Portfolio

另外一种新分工，更多发生在传统企业内部。

想象一家公司突然出现：

几十个 AI Idea；很多部门各自做 Pilot；一堆 Vendor 来 Demo；每个人都说自己这个场景特别适合 AI。

很快就需要有人回答：

到底先做什么？

哪些值得 Build？

哪些直接 Buy？

什么能力应该统一做成 Platform？

哪些数据可以用？

怎么治理权限？

怎么算 ROI？

怎么让员工真的采用，而不是 Demo 完就结束？

所以现在也越来越常见：

AI Transformation PM、AI Product Owner、Internal AI Product。

它们不一定负责一个单一 AI Feature。

更像是在经营：

一家公司应该怎样使用 AI。

我觉得它和 Forward-Deployed 很像的一点是：

AI 进入这个阶段以后，模型本身只是问题的一部分。

组织、流程和落地，开始占据越来越大的比重。

把这些新职位放在一起，其实有一条很清楚的逻辑

我后来试着不看职位名称，只看它们为什么存在：

模型会变化→ 所以需要 Evals

Agent 会行动→ 所以需要 Harness / Permissions

模型行为本身影响体验→ 所以出现 Model Behaviors

AI 依赖大量人类判断→ 所以出现 Human Data Platform

AI 会产生新的风险→ 所以需要 Safeguards / Safety Measurement

企业部署很难→ 所以出现 Forward-Deployed

公司同时冒出大量 AI 项目→ 所以需要 AI Transformation

这样看以后，这些名字就没那么像“AI 黑话”了。

它们只是在回答同一个问题：

一个新的复杂问题出现以后，到底应该由谁长期负责？

这对找工作也有一个很实际的影响

如果只搜索：

AI Product Manager

其实很容易漏掉一些和自己很匹配的机会。

现在还可以一起看：

AI EvaluationsAgent PlatformAgent HarnessModel PerformanceResearch Product ManagerModel BehaviorsSafeguardsForward-Deployed Product ManagerAI ApplicationsAI Transformation

当然，这些 Title 现在还没有完全稳定。

有些名字可能几年以后还在，有些可能会消失。

所以比起记住每一个词，我觉得更有用的是：

先看它在解决什么问题。

因为 Title 会变。

问题通常不会那么快消失。

前三篇写到这里，这组 research 的市场地图基本铺完了：

第一篇是 AI PM 到底分成哪些工作；

第二篇是不同岗位需要多深的技术；

这一篇则是 AI 产品组织正在长出哪些新的专业分工。

最后一篇，我想把视角从“公司在招什么”重新拉回到个人：

如果过去不是 AI PM，面对这么多岗位和技能，到底应该怎么找到自己的位置？

我觉得答案可能不是：

再给自己加一张更长的学习清单。

「现在公司到底在招什么样的 AI PM」系列 3/4。研究基于截至 2026 年 8 月 20 日整理的 43 个公开 AI 产品岗位；本文主要参考 Anthropic、OpenAI、Box、Binance、Scale AI 等公司的当前招聘信息。文中职位名称代表的是正在出现的分工趋势，并不意味着这些 Title 已经形成统一的行业标准。

Day 091 · AI PM 到底需要多技术？看了 40+ 个 JD 后，我把要求拆成了 4 层

Wed, 26 Aug 2026 00:00:00 GMT

这是「现在公司到底在招什么样的 AI PM」系列第二篇。

这一轮我整理了截至 2026 年 8 月 20 日的 43 个公开 AI 产品岗位，包括 OpenAI、Anthropic、Scale AI、Box、Binance、Apple、Ford、n8n，以及金融、保险、医疗等行业公司的职位；同时参考 Stanford AI Index 2026、PwC 2026 AI Jobs Barometer 等资料。

第一篇先做了一张地图：

所谓 AI PM，其实已经是很多种完全不同的工作。

有人离模型很近，有人在做 Agent Platform，有人负责 Evals，也有人负责把 AI 接进具体行业和企业工作流。

这也解释了一个我之前一直觉得很难回答的问题：

AI PM 到底需要多技术？

如果只看讨论，很容易得到两个极端答案：

一边说，PM 不需要写代码，理解用户和产品就够了；

另一边说，现在做 AI PM，不懂 Python、ML、System Design 已经不行了。

看完这批真实 JD，我觉得两边都说对了一部分。

问题在于：

“技术能力”本身不是一件事。

我会把招聘里的要求大致拆成四层。

第一层：AI Literacy —— 至少知道自己在做什么

这是最基础的一层。

不一定要写代码，但至少需要理解：

LLM 大概擅长什么、不擅长什么；
Hallucination 为什么会出现；
RAG 是解决什么问题的；
Agent 和普通 Chatbot 有什么区别；
Tool Calling、Grounding、Context、HITL 分别在做什么。

这些概念并不难学。

真正重要的是，它们会不会影响产品判断。

例如工程师说：

这个场景不适合继续把信息塞进 Context，应该改成 Retrieval。

或者：

这个步骤不能直接让 Agent 执行，最好保留 Human Approval。

PM 不一定要自己实现，但至少应该能参与讨论：

为什么？代价是什么？有没有别的方案？

如果所有涉及 AI 的决定最后都只能变成：

Engineering 建议这么做。

那其实不只是技术被外包了。

一部分产品判断也一起被外包了。

所以我现在会把 AI Literacy 理解成：

不需要成为工程师，但至少要听得懂这个产品为什么这样工作。

这应该已经是 AI PM 的基本门槛。

第二层：Builder Fluency —— 能不能自己先试一下

再往上一层，我看到越来越多 JD 开始出现：

Hands-on、Prototype、Python、SQL、Notebook……

这里很容易让人产生压力：

PM 现在也要写代码了吗？

我觉得不必直接得出这个结论。

这些岗位更常表达的是另一种要求：

不要把所有验证都依赖工程团队。

例如有一个产品想法，可以自己先：

调用一个 Model API；
搭一个简单的 RAG；
让 Agent 调两个 Tool；
跑几十个测试 Case；
比较两个模型；
看 Trace 和 Log；
用简单的 Python / SQL 看一下结果。

Box 的 Product Manager, AI Evaluations 是一个很典型的例子。

它明确要求 PM 能使用 Python、SQL、Notebook，自己构建 Evals、分析结果、Prototype Data Pipeline。

这不是让 PM 去维护 Production Code。

更像是在说：

如果一个问题几个小时就能自己验证，不要先花几天写文档，再等别人替你验证。

这件事其实和 Coding Agent、AI-assisted Building 的发展也有关系。

Prototype 的成本已经明显下降。

以前“PM 自己做不了”很合理的事情，现在有一部分已经变成：

“为什么不先自己试试？”

所以 Builder Fluency 真正重要的，不是“会不会某种编程语言”。

而是：

能不能独立把一个模糊想法推进到有证据可以判断。

第三层：System Fluency —— 知道一个 AI 产品为什么会失败

再往上一层，我觉得才是真正拉开 AI PM 差距的地方。

一个 Demo 能跑，不代表它是一个产品。

真正投入使用以后，很快会遇到：

Agent 可以调用哪些 Tool？
什么 Tool 绝对不能调用？
Context 应该放多少？
什么时候需要 Memory？
Tool 连续失败以后，是 Retry、Fallback，还是直接停止？
什么动作必须由人确认？
模型更新以后，怎么知道有没有 Regression？
质量提高一点，但成本翻倍，要不要上？
更强的模型慢两秒，用户是否能接受？

这时候需要理解的已经不是：

“RAG 是什么？”

而是：

整个系统在什么条件下会可靠，又会在什么地方失效。

例如 Binance 的 AI Agent & Harness PM，职责里会出现：

Task Flow、Capability Boundary、Failure Fallback、Harness Evaluation、Task Set。

OpenAI 的 API Agents PM，则需要和研究、工程一起讨论 SDK、API 和 Agent Infrastructure。

这类岗位不一定要求 PM 自己实现所有东西。

但它要求 PM 能对这些东西做产品判断。

我觉得这里有一个挺重要的区别：

第二层问的是：

我能不能自己做实验？

第三层问的是：

我知不知道实验结果意味着什么，以及这个系统能不能上线？

后者比“会写一点 Python”重要得多。

第四层：ML / Infrastructure Depth —— 有些 AI PM，本来就是技术 PM

再往上，就是 Core Models、Training、Post-training、Inference、Compute、ML Platform 这些岗位。

它们可能要求理解：

Model Training；
Inference；
Search / Recommendation；
Data Infrastructure；
Serving；
分布式系统；
Experimentation Framework。

这时候竞争者本来就经常来自：

ML Engineer、Data Scientist、Search / Recommendation PM、Infrastructure PM。

所以如果看到 OpenAI、Anthropic 的一些 JD，觉得：

AI PM 为什么已经要求这么深的技术？

其实不一定代表所有 AI PM 都变成这样。

更准确的理解是：

你正在看一种本来就非常靠近模型和 Infrastructure 的 PM。

一个 Healthcare Agent PM 和一个 Core Models PM，虽然 Title 里都可能有 Product Manager，但能力结构完全不同。

这也是为什么上一篇先把 AI PM 分类很重要。

否则所有技术要求都会被揉成一张吓人的学习清单。

真正让我觉得更重要的，是这三种能力正在跨岗位出现

看完这些 JD 后，有三个东西我反而比“会不会写代码”更在意。

1. Evals：你怎么知道它真的变好了？

这是我觉得 AI PM 和传统产品工作差异很明显的一点。

过去我们很容易说：

“用户反馈不错。”

AI 产品里，这句话不太够。

需要继续问：

和什么 Baseline 比？
在哪些任务上更好？
测试集怎么来的？
哪些错误改善了？
又有哪些地方退化了？
什么错误可以接受？
什么错误一次都不能发生？

所以 Evals 即使没有变成每个人职位名称的一部分，也很可能慢慢变成 AI PM 的基础工作方法。

不是每个人都需要成为 Eval 专家。

但至少应该知道：

我凭什么说这个版本更好？

2. Trade-off：不是单纯追求“模型更聪明”

一个 AI 产品通常同时存在很多目标：

QualityLatencyCostReliabilitySafety

它们经常彼此冲突。

更强的模型可能更贵；
更快的模型可能效果差一点；
Context 放得更多可能更准，但延迟和成本一起上涨；
Agent 权限更大可能完成更多任务，同时也更危险。

这里不存在一个工程师可以算出来的唯一答案。

产品还是需要决定：

我们到底在优化什么？

以及：

底线在哪里？

3. Failure Design：先想它会怎么坏

普通软件当然也需要处理异常。

但 AI 系统的不确定性，让 Failure 变成一个更核心的产品问题。

不知道怎么办？
信息冲突怎么办？
Tool 返回错误怎么办？
模型非常自信地答错怎么办？
执行到一半失败怎么办？
什么时候应该让人接管？
错误发生以后能不能恢复？

我现在反而觉得：

看一个 AI PM 是否真的理解产品，最好的方式之一不是看他能不能讲 Happy Path，而是看他怎么讲 Failure。

所以，AI PM 到底要不要会写代码？

如果一定要给一个很短的答案：

不一定。

但另一个答案也很明确：

完全不碰技术，会越来越限制可以竞争的岗位。

不是因为 PM 要变成 Engineer。

而是因为 AI 把很多过去藏在工程实现里的问题，变成了产品问题。

模型选哪个；
什么时候可以发布；
怎样评价质量；
Agent 有多大权限；
失败后怎么办；
Quality、Latency、Cost 怎么取舍。

这些事情都不能只靠：

“技术团队会处理。”

我觉得可以用五个问题自测

与其问自己：

“我会不会 Python？”

不如拿一个真实 AI 产品，看看自己能不能回答：

1. 为什么这里需要 AI，而不是普通规则？

2. 什么结果算好？

3. 准备怎么测？

4. 最容易失败在哪里？

5. 上线以后，怎么知道它有没有持续变差？

如果这些问题已经能独立回答，即使代码能力还有限，技术也开始真正服务于产品判断了。

如果这些问题答不了，即使知道很多 Framework 和新名词，可能仍然只是：

知道 AI，而不是会做 AI 产品。

所以这一篇研究下来，我最后对“AI PM 要多技术”的理解反而比开始时简单了一点：

学技术，不是为了替代工程师。

是为了不要把本来属于产品的判断，也一起交出去。

下一篇会继续看另一个很有意思的变化：

为什么招聘里开始出现 Evals、Harness、Model Behaviors、Forward-Deployed 这些几年前很少见的职位？

它们到底是在发明新名词，还是 AI 产品组织真的开始长出新的专业分工？

「现在公司到底在招什么样的 AI PM」系列 2/4。研究基于截至 2026 年 8 月 20 日整理的 43 个公开 AI 产品岗位；本文主要参考 Box AI Evaluations、OpenAI API Agents / Core Models、Binance AI Agent & Harness、Scale AI Forward-Deployed 等招聘信息，并结合 Stanford AI Index 2026、PwC 2026 AI Jobs Barometer 做趋势交叉参考。

Day 090 · 看了 40+ 个 AI PM JD：所谓「AI PM」，其实不是一种工作

Tue, 25 Aug 2026 00:00:00 GMT

最近认真做了一轮 AI PM 招聘市场的 research。

原因很简单：“AI PM”这个词现在太大了。

同样写着 AI Product Manager，有的岗位和研究团队一起决定模型能力，有的在做 Agent Platform，有的专门负责 Evals，还有的核心工作是把 AI 接进金融、医疗、法律这些具体行业。

如果只是笼统地问：

AI PM 需要什么能力？

很容易得到一张没有尽头的学习清单：Python、RAG、Agent、MCP、Evals、ML、System Design……

但真实招聘里，这些并不是每个岗位都同样需要。

所以这次我没有从“AI PM 应该会什么”开始，而是反过来看：公司现在到底在招什么人？

截至 2026 年 8 月 20 日，我整理了 43 个公开招聘中的 AI 产品岗位。

里面既有 OpenAI、Anthropic、Scale AI 这样的 AI-native 公司，也有 Box、Binance、Apple、Ford、n8n，以及金融、保险、医疗等行业公司的岗位；地域覆盖北美、欧洲、GCC 和亚洲。

这不是一次严格意义上的全市场统计。43 个岗位是为了覆盖不同公司和岗位类型做的分层抽样，所以我不会拿它来推断“市场上百分之多少属于某一类”。

我更想回答的是：

当公司今天写下 AI Product Manager 这个职位时，它实际上在找什么样的人？

除了具体 JD，我也用了 Stanford AI Index 2026、PwC 2026 AI Jobs Barometer 等报告看更大的招聘趋势；TrueUp 则只用来辅助看 PM 市场的岗位量、职级和地区等聚合数据，不参与下面这套岗位分类。

这轮 research 最后拆成四篇：

这一篇：AI PM 到底有哪些不同的工作
第二篇：AI PM 到底需要多技术
第三篇：Evals、Harness、Forward-Deployed 这些新分工在做什么
第四篇：传统 PM 怎么找到自己的 AI 位置

先从第一张地图开始。

我没有按 Job Title 分类，而是看“这个 PM 到底在负责什么”

这是我整理 JD 时一个挺重要的变化。

如果按照 Title 分类，会看到大量：

AI Product Manager、Senior AI PM、Product Manager — AI……

很难得出什么。

但如果换一个问题：

这个 PM 真正负责的产品对象是什么？

差异一下就出来了。

我最后大致归成七类：

模型能力 → AI 运行平台 → 质量与风险 → 用户应用 → 行业工作流 → 企业 AI 转型 → 客户现场部署

这不是行业官方 taxonomy，只是基于这批真实岗位整理出来的一张实用地图。

第一层：离模型最近

1. Model / Research PM：直接围绕模型能力工作

这是离模型最近的一类 PM。

他们讨论的不只是：

“用户想要什么功能？”

还包括：

模型下一步应该增强什么能力；训练和后训练需要什么数据；某种 Model Behavior 是不是我们想要的；一项新能力什么时候已经稳定到可以发布。

OpenAI 有 Core Models PM。

Anthropic 的招聘里则能看到更细的：

Research Product Manager、Model Behaviors、Claude Code Model Performance。

这类岗位的技术门槛通常也最高。

搜索推荐、ML 产品、Data Platform、AI Infrastructure，甚至研究或工程背景，都会成为明显优势。

所以一个传统互联网 PM 看到这种 JD，觉得：

AI PM 怎么已经这么像 ML 了？

不一定是整个 AI PM 市场都变成了这样。

更可能只是你正在看离模型最近的那一种 AI PM。

2. AI Platform / Harness PM：负责模型周围的系统

模型本身其实只是一个组件。

一个 Agent 真正跑起来，还要解决很多东西：

API、SDK、Tool Calling、Context、Memory、Permissions、Sandbox、Retry、Fallback、Observability……

这些以前很容易被理解成“工程实现细节”的事情，现在开始形成一个独立的产品层。

OpenAI 有 API Agents、API Infrastructure 这样的 PM。

Binance 甚至已经直接出现：

Product Manager, AI Agent & Harness

它的职责里包括 Agent Task Flow、Capability Boundary、Failure Fallback、Harness Evaluation，以及 Tool Calling、RAG、MCP、多 Agent 等。

这类岗位比较自然的背景通常是：

Developer Tools、API、Platform、Infrastructure，或者长期做复杂系统的 PM。

它们的产品对象不是某个聊天界面。

而是：

怎样让其他人能够可靠地构建和运行 AI。

3. Evals / Safety PM：负责定义“到底好不好”

这是这轮 research 里我很感兴趣的一类。

普通软件比较容易验收：

按钮能不能点；金额算得对不对；接口有没有返回。

AI 麻烦很多。

同一个问题，每次结果可能不同。

一个模型版本升级以后，某项能力变好了，另一个地方却可能退化。

平均表现很好，也可能在几个非常关键的场景犯严重错误。

所以：

“怎么评价 AI”本身，开始变成产品工作。

Box 现在有一个直接叫 Product Manager, AI Evaluations 的职位。

这个 PM 会负责 Evaluation Dataset、Graders、Offline / Online Evaluation、Model Selection、Regression，以及什么模型可以进入 Production。

OpenAI 则有 Safety Measurement PM，负责测量真实使用里的 Harm，以及 Safeguard 到底有没有效果。

它和传统 QA 一个很大的区别是：

在开始测试之前，先要有人回答：

什么才算好？什么错误可以接受？什么绝对不能发生？

这些本身就是产品判断。

第二层：把 AI 变成一个真正有人用的产品

4. Applied AI PM：负责用户到底能不能完成任务

这是最接近大家直觉里的 AI PM：

Copilot、Assistant、Agent、AI Search、Recommendation……

这类 PM 不一定负责训练模型。

他们更关心：

用户能不能真的完成任务；什么时候可以相信模型；什么时候应该让人接管；失败以后怎么办；用户为什么愿意持续使用。

所以除了 DAU、Conversion、Retention，还会越来越多地看：

Task Success、Grounding、Quality、Latency、Cost、Fallback Rate。

这也是传统 PM 最容易找到迁移路径的一层。

但可能也是最拥挤的一层。

因为：

“做过互联网产品 + 会 Prompt”已经不是什么特别稀缺的组合。

真正拉开差距的，是有没有把一个不稳定的模型能力，做成一个：

可以测量、可以失败、可以恢复，也可以持续迭代的产品。

5. Vertical AI PM：负责 AI 进入一个具体行业以后怎么工作

AI 真正进入行业以后，领域知识又重新变得很值钱。

医疗 Agent 不能只是“回答得像医生”；
金融 Agent 不能随便执行不可逆操作；
法律产品要考虑证据、引用和责任；
Cyber Agent 要知道哪些工具可以调用，哪些动作必须由人确认。

所以现在已经能看到：

Healthcare AI PM、Legal AI PM、Cyber AI PM、Insurance AI Product Owner。

这类岗位不一定最需要“懂模型最多的人”。

有时候公司更需要：

真正知道这个行业里，什么地方最容易出问题的人。

然后把这些行业知识变成：

Permissions、Approval、HITL、Eval Cases、Audit Trail、Risk Metrics。

到了这里，行业经验已经不是简历上的一句：

“熟悉金融 / 医疗 / 法律。”

它会直接改变系统怎么设计。

第三层：把 AI 真正放进一家公司

6. AI Transformation PM：负责企业到底应该怎么用 AI

还有一类岗位，并不负责某一个 AI 功能。

他们负责的是：

公司几十个 AI Idea，到底哪些值得做；

哪些应该 Buy，哪些应该 Build；

哪些先 Pilot；

怎么接进现有系统；

数据和权限怎么治理；

员工到底有没有采用；

最后有没有真实 ROI。

这类职位可能叫：

AI Transformation PM、AI Product Owner、Internal AI PM。

它们的模型技术深度未必像 Core Model PM 那么高。

但很依赖：

流程拆解、Enterprise System、治理、跨部门协作和 Change Management。

所以这类岗位的核心问题不是：

模型有多聪明？

而是：

这家公司有没有真的因此改变工作方式？

7. Forward-Deployed PM：直接去客户现场把 AI 做出来

这是我之前没有特别关注，但这次 research 后觉得很值得看的职位。

Scale AI 现在就在招聘 Forward Deployed Product Manager。

它的工作不是：

写完 PRD → 交给工程 → 等上线。

而是直接深入客户：

理解问题；接数据和 API；一起构建、测试、部署；再把一次性的解决方案逐渐抽象成可以重复使用的软件产品。

所以这个岗位有一点像：

PM + Solutions Architect + Consultant + Builder。

技术能力和客户能力都需要。

它也很符合 AI 现在的产业阶段：

Demo 已经没有那么难。

真正麻烦的，往往是：

怎么把 AI 接进真实业务。

所以，同样叫 AI PM，人才画像可能完全不同

如果把这七类放在一起，会发现：

Model / Research - 模型应该变得多强、往哪里发展？
Platform / HarnessAI - 怎样可靠地被构建和运行？
Evals / Safety - 什么叫好？什么时候可以上线？
Applied AI - 用户到底能不能靠 AI 完成任务？
Vertical AI - AI 在这个行业里怎样才可信、可用？
AI Transformation - 一家公司应该在哪里、怎样使用 AI？
Forward-Deployed - 怎么把 AI 真正部署进客户工作流？

这些岗位当然会重叠。

一个 Healthcare Agent PM 可能同时做 Applied AI、Vertical AI 和 Evals。

一个 Agent Platform PM 也可能大量参与 Harness 和 Evaluation。

但这张地图至少解释了一件事：

为什么打开十个 AI PM JD，会觉得它们需要的能力完全不一样。

因为它们本来就在招不同的人。

所以我现在看 AI PM JD，会先看四件事

而不是先看职位名称。

1. 这个 PM 到底负责什么产品对象？

模型？平台？Eval？Agent？行业工作流？企业部署？

2. 他离模型和系统有多近？

理解能力边界就够了，还是需要亲自实验、写 Python、搭 Pipeline？

3. 公司为什么需要这个 PM？

提高模型质量？把 AI 上线？降低风险？推动企业采用？

4. 什么算成功？

Model Quality？Task Success？Customer Adoption？Cost？Safety？ROI？

这四个问题回答完以后，同样叫 AI Product Manager 的两个职位，可能已经几乎不是同一份工作。

所以这轮研究的第一篇，我最想先留下一个很简单的判断：

别急着问“AI PM 需要会什么”。

先问：我说的是哪一种 AI PM？

下一篇再继续往下拆一个更实际的问题：

这七种 AI PM，对技术的要求到底差多少？

「现在公司到底在招什么样的 AI PM」系列 1/4。研究基于截至 2026 年 8 月 20 日整理的 43 个公开 AI 产品岗位，并参考 Stanford AI Index 2026、PwC 2026 AI Jobs Barometer 等资料；TrueUp 仅用于补充 PM 市场的岗位量、职级和地域等聚合信息。文中的 7 类是对岗位职责的定性归纳，不代表全市场岗位比例。