一派的看法很直接：跟 AI 说清楚，就是把过程写清楚。skill 里要列出每一步，先做什么再做什么，遇到 X 走哪个分支，遇到 Y 走哪个分支，文档越长越细越好，最好把所有 corner case 都覆盖。这一派的潜台词是：模型不可靠，所以要替它把流程钉死。

另一派恰恰相反：跟 AI 说清楚，说的不是过程，是目标。是验收标准，是边界，是几个具体例子。把 skill 当 SOP 去写是不对的。这一派的潜台词是：模型已经能自己拆任务、自己选工具、自己判断什么时候该停，你写的"标准路径"既覆盖不全，又压住了它本来能给你的更好路径。

我自己写 skill 的时候用的是后一派。我自己工作区里有一份专门讲"新 skill 怎么写"的元规则，被自己反复读过，核心就一句话：结果确定性优先于过程确定性，写 enabling 的指导，不要写 SOP。这不是个人偏好，是踩了几次坑被迫做出的选择。坑的形状每次都很类似：今天写一份很详细的步骤指令、跑得也行；过半年模型升一代，同一份指令突然犯一些奇怪的错；团队的反应永远是"再把它写得更清楚一点"，于是 prompt 越改越长、效果越改越差。

这件事看起来是写法之争，但底下藏着一个被严重低估的成本：如果你写的是过程，模型每升一代，你都在被偷偷扣掉智能红利。

过程型 SOP 是怎么折旧的

把指令分成两类，事情就清楚了。一类我叫它过程型 SOP，替模型规定"先做 A、再做 B、然后判断 X、走分支 Y"。另一类我叫它结果型契约，把目标、验收标准、边界、例子讲清楚，剩下的让模型自己拆。这两类指令的命运正好相反：模型每升一代，前者贬值、后者升值。

过程型 SOP 在 GPT-3.5 时代是必要的脚手架，因为那时候模型推理能力弱、上下文跟不住、工具调用经常出错。但今天它已经是最容易折旧的那一类内容。模型已经会自己拆任务、会自己选工具、会自己判断什么时候该停；reasoning model 内部的 CoT 比你手写的 step-by-step 更强；你规定的"标准路径"在长尾场景上必然失效，而模型本来有能力绕开。Wharton 有个研究测过这件事，在 reasoning model 上额外加 CoT 只剩边际收益，但延迟会暴涨百分之二三十甚至更高。换句话说，你为了"让模型更可靠"加进去的步骤，正在让它变慢、变贵、变笨。

更扎心的是另一个方向：过程型 SOP 限定了输出的形状。你规定了 12 步流程，输出的天花板就被这 12 步框住了。模型再聪明也只能产出一份"很好执行的 12 步结果"，而不是它本来能给你的"重新设计后的 5 步结果"。模型每一代升级，最大的增量都是"在更模糊的目标下做出更好的判断"。这种增量必须有发挥空间才能体现。你把空间封死了，增量就被你自己挡在门外。

结果型契约相反。它规定的是"答案的形状"，不是"路径的形状"。模型变强之后，对模糊目标的脑补能力变强，但它只在你给了清晰目标的前提下才发挥得出来；你不告诉它"什么是好"，它只能凭直觉给你"看起来好"。验收标准是这件事的杠杆点。模型越聪明，杠杆越长。边界和例子则是 corner case 上唯一稳的锚。这一类内容写一次，跨多代模型都能用，质量随模型变强自动上升。

过程型 SOP 还有一个隐性的工程信号代价。如果指令是"做成这样"，agent 在做不出来的时候会反推"目标是不是定错了"；如果指令是"按这 12 步做"，agent 在第 7 步卡住时只会告诉你"第 7 步失败了"。前者给你的是产品级反馈，后者给你的是工单。

我去年在金融科技团队推 AI 转型的时候吃过这一脚。最早几份 skill 我让大家写得很详细，恨不得每个 if-else 都列出来。模型升一次级，每份 skill 都要手动改一轮。后来我把团队的写法换了：第一段写"这个 skill 干什么、产出什么"，第二段写"做对了长什么样"加 3 条可验证标准，第三段写"边界和已知坑"，所有"先做 A 再做 B"的描述都删掉，只在不可逆操作那几处保留"必须先 dry-run"这种硬约束。换了几次模型之后，这批 skill 的存活率比之前明显好。

那合规场景呢？一个三档框架

讲到这里我必须接住对面最强的几条论据，不然就是稻草人。

第一条是合规。如果一个工作流必须能按步骤复盘才能通过审计，那就老老实实写 SOP。Anthropic 在 Skills 的官方建议里把这件事讲得很清楚：给 skill 匹配合适的自由度，是一个三档框架。高自由度，纯文本指令，模型可以按多种方法走；中自由度，带参数的伪代码，结构定了细节可调；低自由度，写死脚本，不允许偏离。数据库 migration、金融交易、医疗给药、PCI 和 HIPAA 合规链路，这些就该用低自由度档。把所有 skill 都按高自由度写是错的，把所有 skill 都按低自由度写也是错的。问题从来不是"要不要 SOP"，是"哪一档配哪一类任务"。我反对的是把低自由度档的写法套到高自由度任务上。

第二条是 Andrew Ng 那个经常被引用的 HumanEval 实验：GPT-3.5 加上 agentic workflow，性能能跑赢 zero-shot 的 GPT-4。这条结论我也信，但它说的是 reflection、planning、tool use、multi-agent 这一类系统级的工程编排，不是在 prompt 里塞 12 步流程。reflection 是一种结构，让模型自己 review 自己；planning 是一种循环，让模型自己出 plan 自己执行。这是 agent harness 层的设计，不是 skill 内部的步骤清单。这两件事经常被混为一谈。Workflow 作为系统编排是对的；workflow 作为单个 skill 内部的 step-by-step 写法，今天已经是反模式。

第三条最有意思也最容易让我妥协：新人写不出好的"目标 prompt"，过程型 SOP 反而是经验沉淀的载体。我的回应是，如果一个团队连"这个 skill 要解决什么问题、做对了长什么样"都写不清楚，那不是 prompt 写法的问题，是产品定义的问题。把它包装成 12 步 SOP，看起来交付了一份文档，实际上是把"产品定义不清晰"埋进了系统。每次模型升级、每次场景变化、每次新人接手，它都会重新爆出来。

两条相反的官方建议指向同一件事

有一个细节经常让人困惑。OpenAI 的 GPT-5 prompting guide 在说"少即是多"，模型越聪明，prompt 越要简洁，过度规定反而伤害性能。Anthropic 的 Claude 4.x 最佳实践在说反方向，Claude 4.5 出来之后打破了大量已有 prompt，因为新版本更"字面执行"，你说什么它就做什么、多一点都不会。两家头部模型公司对"该怎么写 prompt"给出了表面上相反的建议。

很多人看到这里会得出"业界没共识"的结论。我的解读是另一回事。这两条建议针对的根本不是"要不要写步骤"，而是"要不要写明确目标和验收标准"。OpenAI 说的是别在 prompt 里塞重复的、互相矛盾的、为了壮胆而堆叠的话；Anthropic 说的是模型不再替你"脑补意图"了，你想要什么就明明白白说出来，不要假设它会主动做"超出预期"的事。两边的指向其实是同一件事：把目标、验收、边界写清楚，把过程、步骤、套话写少。

如果你写的是"You are an expert. Think step by step. Be concise. Be helpful. Use bullet points when appropriate." 这种填充话术，GPT-5 会因为它们互相矛盾而浪费 reasoning token，Claude 4.5 会因为它们没有具体内容而字面理解到失控。两边都崩，但崩在不同环节。如果你写的是"目标是 X、验收标准是 1/2/3、边界是 A/B、例子见 examples/case-1"，GPT-5 会按它的判断帮你做到，Claude 4.5 会一字不差地按你说的做。两边都活。

一个具体的反模板

具体一点。我见过的某团队 skill 文件大致长这样：

你是一个数据分析专家。
请按以下步骤执行：
第一步，调用 BI 工具拉取最近 7 天的数据
第二步，按渠道分组
第三步，计算每个渠道的转化率
第四步，找出 TOP 3 异常渠道
第五步，对每个异常渠道做归因
第六步，输出报告

注意：
- 不要使用模糊词
- 不要漏掉任何渠道
- 报告必须分小节
- 必须包含数据来源
- 必须有结论
- 必须有建议
- 必须有下一步行动
- 不要使用第一人称
- ……（再 30 行类似的注意事项）

这份文档在 GPT-3.5 时代很 work。换到 GPT-5 时代会出两种典型问题。要么模型严格按 6 步走，每一步都用最朴素的方式做，浪费了它本来能识别"这周哪个渠道值得深挖"的能力；要么模型在第 4 步发现 TOP 3 里有 2 个是数据噪声，但它没有跳出 SOP 的权限，于是给你一份"看起来完整但其实没价值"的报告。

同样的需求，按目标加验收加边界写就成了：

目标：每周一早晨给业务方一份"上周哪些渠道异常 + 为什么"的简报

输入：BI 系统中过去 7 天的渠道转化数据
输出位置：reports/weekly_channel_anomaly_<日期>.md

验收标准：
- 必须明确指出"本周值得关注的异常"，0 个或多个都行，不为了凑数硬找
- 异常的归因必须能追溯到具体数据点（不能只说"可能是季节性"）
- 简报让业务方读完能在 2 个动作内决定是否需要拉会

边界：
- 数据明显异常（如某渠道转化率突然为 0）时先报警，不要直接归因
- 归因涉及"竞品策略变化""政策影响"这类外部因素时，标注为"假设"而不是"结论"
- 不要在简报里写本工具的执行过程

例子：
- 见 reports/weekly_channel_anomaly_20260428.md（一份好简报）
- 见 reports/weekly_channel_anomaly_20260421.md（一份不够好的简报，问题：把 5 个边缘异常都列了，业务方看不下去）

这份指令模型会自己拆步骤，会自己判断要不要分组、要做几层归因、要不要追加查数据。下一代模型来了，它的"自己判断"能力变强，这份指令的产出质量也跟着上去。你不用动一个字。

检查自己已经写了的 prompt 和 skill，可以问几个问题。里面有没有"第一步、第二步、第三步"这种字样，如果有，那串步骤是在描述"做对了长什么样"还是"该怎么做"，如果是后者并且任务不是不可逆操作，删掉它，让模型自己拆。指令最后能不能被一个新来的 agent 拿来判断"这件事做完了没有"，如果不能，说明你的验收标准还没写到位。"必须 / 不要 / 不能"这类硬约束如果超过十条，绝大部分多半是在应对脑补出来的 corner case，让真实的失败驱动迭代，第一次出错是噪声，第二次才是模式。最后看几个具体例子，不是抽象描述、不是反面教材清单，是真实的"长这样的输入产出长这样的输出"，对高自由度任务尤其关键。

那一截增量进谁的口袋

回到开头那个分歧。两派都在说"要跟 AI 说清楚"，区别在于说清楚什么。说清楚过程，你拿到的是一份在 GPT-3.5 上扎实、在 GPT-5 上别扭、在下一代模型上明显落后的脚手架；说清楚目标和验收标准，你拿到的是一份会跟着模型一起变强的契约。

模型每升一代，能解的问题都比上一代多一截。如果你的指令规定的是答案的形状，那一截增量进了你的口袋；如果你的指令规定的是路径的形状，那一截增量被你自己挡在门外。你写的不是给 AI 看的指令，是给"未来一年里每一代模型"看的契约。

写 SOP 不是错，把所有 skill 都当 SOP 写，是。真正的工程能力，是知道哪一档自由度配哪一类任务。这个判断本身，就是 AI 时代里不太可能被 AI 替代的那部分手艺。

这个说法一下子击中了我最近的一个感受。

我现在确实越来越依赖上下文系统。工作区里有规则，有技能，有公理，有项目历史，有每日复盘，有大量被 AI 处理过的中间产物。它们让 AI 更懂我，也让我和 AI 协作的摩擦越来越低。但与此同时，我也越来越警惕一件事：上下文如果只做横向分类是不够的。

横向分类回答的是：这段信息属于哪个领域。比如 AI、管理、家庭、项目、写作、投资、复盘。

但还有一个更重要的纵向分类：这段信息到底有多属于我？

横向分类解决“资料放哪”，纵向分类解决“谁有发言权”。

这件事在 AI 时代会变得特别重要。因为以前你的知识库主要是给自己看的，混一点问题不大。你知道哪篇文章只是收藏，哪句话只是觉得有意思，哪条结论是自己真正相信的。但 AI 不知道。你把所有东西都放进同一个篮子里，它会把这些东西当成同等权重的语料来理解你。

结果很可能不是 AI 更像你，而是你被 AI 拉回互联网平均值。

收藏不等于拥有

这其实是知识管理里一个很老的问题。很多人以为收藏就是学习，摘录就是理解，转发就是拥有。后来 Zettelkasten、Second Brain 这些方法论反复强调一件事：收藏只是入口，真正的知识必须被你重新加工过。

以前这句话更多是在提醒人不要做收藏癖。到了 AI 时代，我觉得它变成了一个更严肃的问题：如果你没有标明一条信息的归属，AI 就会替你决定它的归属。

比如你收藏了一篇文章，里面有一个观点写得很好。你当时只是觉得“有道理”，还没有想清楚自己是否同意，也没有把它放到自己的经验里验证。过了几个月，你让 AI “根据我的知识库写一篇我的观点”。AI 检索到了这篇文章，就很自然地把那个观点揉进了你的文章里。

表面上看，它引用了你的知识库。实际上，它借用了别人的大脑，并且给你署了名。

这不是 AI 故意乱来，而是因为你的系统没有告诉它：这只是我看过的，不是我相信的；这只是我收藏的，不是我消化的；这只是别人说得漂亮，不代表它有资格替我发言。

所以我越来越觉得，个人知识库里最危险的东西，不是假信息，而是没有标明归属的真信息。

什么才算“我的”

这里容易走到另一个极端：是不是只有完全原创的想法才算我的？我觉得也不是。

人的观点本来就不是从真空里长出来的。我们读书、看文章、听别人说话、看视频、做项目、和人争论，最后形成自己的判断。外部输入当然重要。问题不在于观点是不是有外部来源，而在于它有没有经过你的处理。

我现在会把上下文大概分成几层。

最底层是原始外部资料：文章、论文、视频、别人说的话。这些东西有价值，但它们只能当证据，不能直接当立场。

再往上是摘录和摘要：我觉得它可能有用，所以先记下来。它比原文更接近我，但仍然不是我。

再往上是我的转述：我用自己的话说过一遍，说明我至少理解了它。

更高一层是我的判断：我赞成什么，反对什么，保留什么，在哪个场景成立，在哪个场景不成立。

最高权重的，是我的经历和长期规则。亲身做过的项目，踩过的坑，管理现场里反复验证过的判断，日复一日复盘后沉淀出来的公理。这些东西不一定更宏大，但最能代表我。

换句话说，一个观点可以从别人那里来，但必须经过转述、碰撞、取舍和验证，才真正变成你的。

AI 应该优先放大的，是后面几层，而不是前面几层。

AI 平均化，从上下文混装开始

我之前写过一篇《AI 味不是机器味，是平均值的味道》。那时候更多是在讲写作表达：AI 为什么会写得越来越像一个训练得很好的优等生。

现在我觉得还可以再往前追一层。很多时候，AI 味不是从生成那一刻才开始的，而是从上下文混装那一刻就开始了。

如果一个知识库里同时放着你的亲身经历、别人的金句、网页收藏、AI 摘要、会议纪要、临时想法，而且这些东西没有权重差异，模型会怎么处理？它只能做一件事：求一个语义上的平均值。

它会把你的个人经历说得更像行业共识，把你的犹豫说得更像成熟判断，把别人的漂亮话说得更像你的观点。最后出来的东西可能都对，但不像你。

这和大模型训练很像。训练模型不是一股脑把所有数据倒进去就完了。要去重，要过滤，要标来源，要调数据配比，要给不同数据不同权重。高质量语料和低质量语料不能一样，人类原创和模型生成内容不能一样，主干知识和长尾样本也不能一样。

个人知识库也是一样。它不是硬盘，更像训练集。每条内容都有权重。

亲历项目应该是高权重样本，随手收藏的文章应该是低权重样本，AI 生成的内容要打水印或者隔离。否则你训练出来的不是“更懂我的 AI”，而是“更会综合我看过的一切的 AI”。这两者差别很大。

人的独特性在分布尾部

我很喜欢 model collapse 里的一个隐喻：模型反复吃自己生成的数据，最先消失的是分布尾部。也就是那些少见的、不典型的、低概率但很重要的东西。

人的表达也是这样。真正像你的部分，往往不在那些正确的大道理里，而在分布尾部。

比如一个项目里你为什么放弃了看起来更先进的方案。一次管理沟通里你为什么没有继续推进。某个看似琐碎的家庭场景，为什么让你重新理解一个抽象概念。某次失败后，你到底改了哪条规则。别人可能也知道类似道理，但只有你有那段具体经历。

这些东西不一定体面，也不一定完整，甚至有时候很土。但它们是你的尾部样本。

如果上下文系统没有给这些尾部样本更高权重，AI 默认会回到更安全、更顺滑、更常见的表达。它不是不想写出你，而是不知道你把这些不平滑的东西看得更重要。

所以我现在越来越相信，个人风格不是形容词，是加权函数。

你说自己“务实、理性、有判断”，这还不够。真正决定 AI 能不能写出你、帮你思考、替你推进事情的，是它在冲突时知道谁权重大。是收藏的文章权重大，还是你复盘里的反思权重大？是行业通用说法权重大，还是你某次亲身踩坑后的结论权重大？是 AI 上一轮生成的顺滑段落权重大，还是你手动删掉它的编辑动作权重大？

这些才是上下文主权。

我现在更想这样管理上下文

如果把这件事落到个人系统里，我觉得以后至少要有几条规则。

第一，原始记录和个人判断要分开。录音、聊天、网页、论文、视频都可以收，但它们应该保留“外部资料”的身份。它们能提供证据，不能直接代表我。

第二，AI 处理过的内容要单独放。AI 摘要、AI 初稿、AI 生成的中间分析都有用，但它们是加工品，不是原材料，更不是最终判断。它们如果混进长期记忆，很容易反过来污染后续输出。

第三，每条重要信息最好有一个“我怎么看”。哪怕只是一句话也行：我同意哪里，不同意哪里，适用边界是什么，和我的哪个经历有关。没有这句话，它就只是资料，不是知识。

第四，把人工删改当成高价值信号。AI 写了一段，我删掉了什么、保留了什么、重排了什么，这些动作比我说“写得更像我一点”重要得多。因为 taste 不是抽象偏好，taste 是选择痕迹。

第五，长期规则要从行为里长出来。公理系统最有价值的地方，不是写了多少漂亮原则，而是它来自长期复盘后的行为模式归纳。不是我说过什么，而是我一直在做什么。

这套系统听起来像知识管理，但我觉得它更像给自己的 AI 建一个免疫系统。不是所有进入身体的东西都会变成自己。身体要识别、吸收、排异，知识系统也一样。

最后

过去我们讲个人知识管理，核心问题是怎么不忘。AI 时代这个问题变了：不是怎么记住更多，而是怎么避免被自己记住的东西稀释。

上下文越多，越需要治理。资料越丰富，越需要权重。AI 越能理解你，越要告诉它什么才算你。

否则所谓“我的知识库”，最后会变成一个很会说话的互联网平均值。它知道你读过什么，知道你收藏过什么，知道你让 AI 生成过什么，但它不知道你真正相信什么。

AI 时代，真正稀缺的不是上下文长度，而是上下文主权。

群里大部分人的反应都比较一致：不是特别好的选择。我自己的感受也差不多。不是因为 Harness 不重要，而是因为多数人现在纠结的 Harness，很可能不是他们当下最该解决的问题。

这件事让我想到鸭哥之前说过的一个词：外包。

这个词听起来很朴素，甚至有点不够“技术”。但我现在越来越觉得，它可能是 AI Coding 进入下一阶段之后，很多人最缺的一种能力。

AI 越强，人越容易重新变成手工业者

过去几个月，AI Coding 的能力确实在快速变强。模型能处理更长的上下文，工具能跑更复杂的任务，Agent 能在一个 repo 里来回改文件、跑测试、修错误。以前你只敢让它写一个函数，现在你会开始让它做一个功能，甚至做一个完整模块。

能力变强以后，一个很自然的冲动就出现了：既然它能做，那我就让它从零做。

页面自己写，框架自己搭，评测自己做，Harness 自己建。以前人写代码成本高，大家还会认真想想这个东西到底该不该自研。现在 AI 把第一版代码的成本打得很低，反而让很多人失去了 build or buy 的判断。

这是一个很隐蔽的陷阱。

AI 让执行变便宜了，但没有让维护变便宜。它能帮你把第一版写出来，但后面的理解、迁移、升级、验证、排错，还是会回到你身上。尤其是 Harness 这种东西，一旦你自建，它就不是一个功能，而是一条长期责任链。

所以最危险的不是 AI 不够强，而是 AI 足够强，让你误以为什么都可以自己搭。

Harness 当然重要，但它不是所有人的第一优先级

我并不是反对 Harness。

Agent 要从 Demo 变成真正可用的系统，肯定需要一整套中间层：状态怎么保存，工具怎么调用，权限怎么控制，失败怎么恢复，过程怎么记录，效果怎么评估。这些问题每一个都不性感，但每一个都决定 Agent 能不能长期稳定运行。

成熟团队确实需要 Harness。平台团队要做 Agent 发布门禁，需要评测集、回归门槛、灰度机制。业务 Agent 上线给多人使用，需要可回放、可审计、可回滚。公司要比较不同模型、不同 prompt、不同工具配置，也需要稳定的评测框架。

但这里有个前提：你得先有稳定的任务分布。

如果你现在每次让 AI 做的事情都不一样，没有固定任务集，没有失败样本库，没有明确 KPI，没有持续回归需求，那你搭出来的 Harness 服务谁？它评测什么？它优化什么？它证明什么？

很多人现在的问题不是缺 Harness，而是缺一个清楚的任务定义和验收标准。你还不知道什么叫做“做对了”，却开始搭一套系统来评估“做得好不好”。这个顺序反了。

这就像店还没开，先花半年造收银系统。收银系统当然重要，但它不是第一天最该解决的问题。

所谓外包，不是把责任甩出去

我理解的外包，不是把事情丢给别人，也不是降低要求。

它更像现代软件工程里的依赖管理。通用的东西，尽量交给成熟模块。真正和你业务强相关、和你判断强相关、和你责任强相关的东西，自己留下。

模型能力，外包给模型厂商。Agent runtime，优先看成熟框架或公司内部平台。评测基准，先看现成的 eval 工具和开源 harness。部署、监控、权限、审计，能接已有基础设施就不要重做。

那人留下什么？

留下问题定义，留下上下文，留下方案选择，留下结果验收。

这几件事才是 AI Coding 时代人的核心价值。你知道这个问题为什么重要，知道输入怎么描述才不偏，知道输出长什么样才算对，知道哪些风险不能接受，知道这个方案放到你的业务和组织里会不会出问题。

AI 擅长执行，但它不天然知道你的业务边界。成熟工具擅长提供通用能力，但它不替你承担最终判断。

所以外包不是放弃控制权。相反，它是为了把控制权从“我能不能写出这段代码”，转移到“我能不能判断这套方案是否正确”。

AI Coding 有两个层级

我现在越来越觉得，AI Coding 至少有两个层级。

第一个层级是执行层 AI Coding。你让 AI 一行一行写，把功能做出来。这个阶段很重要，它让很多过去不会写代码的人，第一次可以把想法变成可运行的东西。

第二个层级是架构层 AI Coding。你让 AI 帮你判断：这个问题有没有成熟解法，同类开源项目怎么做，官方文档推荐什么架构，别人踩过什么坑，哪些模块该接，哪些模块该买，哪些地方必须自己保留控制权。

这两个层级的差别很大。

执行层 AI Coding 让你更快地产生代码。架构层 AI Coding 让你更少地产生错误代码。前者提升速度，后者提升方向。

如果只停留在第一层，人会越来越像一个指挥 AI 干活的包工头：这里加个功能，那里补个模块，缺什么搭什么。项目看起来推进很快，但底层越来越重。

进入第二层以后，问题会变成：这个模块是不是我的核心竞争力？有没有成熟方案？我真正需要掌控的是接口、数据、流程，还是底层实现？

这个判断一旦做对，后面少写的代码，比多写的代码更值钱。

更好的路径：先集成，再沉淀，最后才平台化

如果今天有人问我该不该投入 Harness，我会建议他先按这个顺序走。

第一步，先用现成工具跑通真实问题。不要先搭系统，先让 AI 真正在你的场景里完成几次任务。

第二步，把验收标准写清楚。不是“看起来不错”，而是哪些输入要覆盖，哪些输出不能错，失败了怎么发现。

第三步，保留运行轨迹和失败样本。不要急着抽象，先积累足够多的真实失败。真正有价值的 Harness，往往不是从设计文档里长出来的，而是从重复失败里长出来的。

第四步，当失败模式开始重复，再做轻量机制。比如固定测试集、简单回归脚本、日志结构化、人工 review 表单。

第五步，只有当这些轻量机制变成瓶颈，再考虑平台化。

这个顺序听起来慢，其实更快。因为你没有在一开始就背上一个大系统，也没有为了一个还没被验证的问题，提前支付复杂度。

AI Coding 的高级用法，不是让 AI 写更多代码，而是让 AI 帮你识别哪些代码根本不该写。

回到群里的那个问题

所以，如果问“现在把时间花在 Harness 搭建上是不是好选择”，我的回答会是：看你处在哪个阶段。

如果你是平台团队，有稳定场景，有上线责任，有评测闭环，那当然值得做。Harness 是基础设施，不做迟早要还债。

但如果你只是个人 AI Coding 使用者，或者团队还在探索阶段，那现在最值得投入的不是从零搭 Harness，而是训练自己做三件事：定义问题，寻找成熟模块，设计验收闭环。

这三件事比写代码更难，也更值钱。

AI 时代的工程能力，不会只体现在“我能造出什么”。它还会体现在“我知道什么不该自己造”。过去不会写代码是一种短板，未来不懂外包才是一种短板。

真正拉开差距的人，不是最会让 AI 干活的人，而是最会给 AI 和外部系统分工的人。

背景是这样：他们整个 HR 团队都在推 AI 提效，内部分成了单点提效、流程提效、组织提效三个层级。团队里已经有人在用 AI Coding 工具、低代码平台拉内部数据做小网页，也有人用 Co-Work 之类的协作工具。不算完全不会用，但碰到了瓶颈。

他们最困惑的一个点是：做出来的小网页，第一眼看挺好，数据能展示，页面也漂亮。但是然后呢？如果只是看数据，直接把 MCP 挂上去问就行了，何必做成网页？如果要给别人看，又涉及部署、维护、权限，普通业务同学根本兜不住。所以他们想知道，"你平常是怎么搭 Agent 的"。

聊完之后我一直在想这件事。不是想怎么回答他们的问题，而是觉得这个问题本身就藏着好几个误区。记录一下。

误区一：把 AI 提效等同于"做 Agent"

这是我听到的最普遍的混淆。大家一说 AI 提效，脑子里的画面就是搭一个 Agent。好像不做 Agent，就不算在认真搞 AI。

但你仔细想想，AI 提效的工具形态其实很多。有些场景你只需要一个查询接口，让 AI 能帮你问数据，那做个 MCP 就够了。有些场景你需要几个人协作看一个东西，或者收集一些信息，那做个网页没问题。有些场景是固定流程跑得快一点，那是 Workflow 的事。只有当一个任务路径不确定、需要多轮推进、中间可能失败需要恢复、需要动态选择工具的时候，才值得上 Agent。

所以第一个判断应该是：这个场景需要什么形态来承载？而不是"我要不要做一个 Agent"。

拿 HR 的场景举例。员工问政策、查福利、看流程，这些是查询类的，挂个 MCP 让 AI 直接回答最自然。内部搞个活动要收报名信息、展示数据看板，这是展示和操作类的，做个网页就行。入职手续一步步审批走完，这是固定流程，Workflow 足够。只有像"帮我从 50 份简历里筛出最合适的 3 个人，还要交叉验证背景、评估文化匹配"这种开放式任务，才真正需要 Agent 的能力。

形态选错了，做出来的东西要么过度复杂（为了一个查询场景搭了整套 Agent），要么能力不足（用一个静态网页试图做动态决策）。先判断场景，再选工具。这个顺序不能反。

误区二：以为"我能用"就等于"别人能用"

这是第二个巨大的误解。一个人用 AI Coding 做出一个小工具，自己用得挺开心，就觉得可以推给团队用了。但单人自用和多人共享之间，隔着一条看不见的线。这条线叫工程稳定。

个人工具可以靠作者的记忆运转：坏了自己修，数据错了自己知道怎么补，权限粗糙点也只影响自己。但一旦给别人用，每一个"自己知道"的东西都会变成一个坑。别人不知道它为什么突然不能用了，不知道数据口径变没变，不知道出了问题找谁。

这时候你需要的不是更好的 AI Coding 能力，而是工程基础设施：部署、监控、日志、权限管理、回滚机制、事故响应流程。这些东西不是一个两小时的 AI 培训能覆盖的，也不是 AI 本身能替你解决的。AI 可以帮你写代码，但它不会替组织承担运维责任。

所以我的判断是：单点提效确实可以靠个人学习解决，但流程提效和组织提效，本质上是组织能力建设的问题，不是工具培训的问题。指望通过一两次培训让业务同学从"给自己用"跨越到"给团队用"，不太现实。更现实的路是：业务同学负责原型和验证，平台团队负责生产化和稳定运行，中间有明确的交接标准。

误区三：觉得 Agent 难在"模型+工具+知识库"

即便真的需要做 Agent，很多人对 Agent 的理解也停留在表面：找个模型，挂几个工具，接个知识库，就是 Agent 了。这个组合能做 Demo，但离真正稳定跑起来差太远了。

Agent 真正难的地方是中间的 Harness 过程。所谓 Harness，就是让 Agent 稳定运行的那一整套机制：状态怎么保存，工具权限怎么控制，哪些操作需要人来审批，出错了怎么恢复，每次运行的轨迹怎么记录，怎么评估它比上周跑得好还是差。这些问题一个比一个不性感，但每一个都决定着这个 Agent 能不能从 Demo 变成真正可用的东西。

所以对普通同学来说，从零搭一个成熟 Agent 不是正确的路。更好的方式是：把你的业务想法包装在已有的成熟 Agent 能力上面。比如前端提供用户的输入口，核心的智能处理部分调用后端成熟的 AI 产品（不管是 Claude Code 的 SDK、某个 CLI 的远程调用、还是企业内部的 Agent 平台），处理完之后对输出做一些规范，再接回到你的业务流程里。你负责定义"要做什么"和"做得对不对"，平台负责"怎么稳定地做"。

这个分工才是当前阶段大多数非技术人员用 Agent 能力的正确姿势。不是降低要求，是找对边界。

误区四：写了 Plan 就以为方向是对的

最后一个感触来自我自己最近的经历。我在做一个 App 的时候，功能做出来了，但怎么调都不太对。反复改了几版之后我忽然想起来，我这个东西和一个开源项目的功能很相似。于是让 AI 去调研那个项目的架构，结果发现我之前的设计从根上就有很多不对的地方。

这件事给我的提醒很直接：写 Plan 不等于方向对。

我以前每次让 AI 干活之前都会先让它写 Plan。Plan 的好处是让 AI 在长时间工作的时候不至于游离目标，干着干着忘了自己在干嘛。这一点没问题。但 Plan 还有另一层价值，就是方向本身是否正确。如果你在一个自己不熟悉的领域里，你写出来的 Plan（或者让 AI 写出来的 Plan）很可能方向就是错的。这时候 Plan 越详细，AI 执行得越认真，结果可能越歪。

所以我现在的做法是：如果涉及到我不确定"什么是好的"的领域，我会先让 AI 去外面找最佳实践。看看同类的开源项目怎么做的，看看官方文档推荐什么架构，看看别人踩过什么坑。基于这些外部输入，再来写 Plan。这样 Plan 指向的方向至少是经过验证的，而不是 AI 在真空里编出来的。

先去找什么是好的，再来规划怎么做。这个顺序，比"帮我搭一个 Agent"重要得多。

回到那门课

如果最后真要给他们讲，我不会把题目定成"如何搭建 Agent"。这个题目本身就把问题带偏了。

我更想讲的是四件事：第一，怎么判断一个场景该做成什么形态。第二，从"自己用"到"别人用"中间差的是什么。第三，如果确实需要 Agent 能力，怎么借力而不是从零开始。第四，在不熟悉的领域里，怎么确保你的方向不是在跑偏。

这四件事比具体的工具操作重要得多。工具会迭代，但判断力的框架不会过时。

真正的组织提效，不是让每个人都造车。是让每个人知道什么时候该骑车、什么时候该坐车、什么时候该修路。

有个朋友在群里发了一段话："这两个月 AI 用量大增，但我感觉思维能力在下降。用 AI 处理信息，再用 AI 生成信息，过程中我自己并没有变强。"

我第一反应是想反驳，因为我自己的体感是 AI 确实让我做事更快了、更好了。但那天晚上做复盘的时候认真想了想，发现他说的不完全是错觉。

从思考者到审稿人

我注意到一个变化。以前做调研，我会先自己花一两个小时读资料、画脑图、形成初步判断，然后才开始写。现在呢？打开 Claude，丢一个问题进去，等它吐出初稿，然后我在上面改。效率提升了至少三倍。

但在这个"改"的过程里，我的角色悄悄变了。从"思考者"变成了"审稿人"。审稿人是在别人搭好的框架里做修补，思考者是自己搭框架。

更微妙的是，我开始不自觉地接受 AI 给我的框架。不是因为它的框架比我的好，而是因为推翻重来太费劲，改几段话省事得多。就像有人帮你把食物嚼碎了喂进嘴里，营养可能进去了，但你的咀嚼肌再也得不到锻炼。

苏格拉底当年担心文字会让人忘记如何记忆。两千年后再看，那点"威胁"简直不值一提。文字只替代了记忆，AI 替代的是综合、判断和决策。量级完全不同。

不只是感觉

MIT 今年做了一个实验，让三组人分别用纯脑力、Google 搜索和 ChatGPT 写作文，持续四个月，每月测脑电波。结果：ChatGPT 组的大脑认知网络活跃度比纯脑力组低了 55%。83% 的人无法回忆自己刚写过什么。英语教师盲评 AI 辅助的文章，给了一个词：soulless。语言完美，但空洞。

研究者管这叫"认知债务"。就像财务债务一样，你在享受即时便利的同时，以未来的认知能力为利息在还。而且这个利息是复利：你越不独立思考，独立思考就越难，然后就越依赖 AI。

这不是学术界在制造焦虑。我在自己团队里也看到了类似的迹象。有个同事以前做数据分析，思路清晰，能从一堆乱七八糟的数据里自己理出线索。用了半年 AI 之后，他的分析报告表面上更漂亮了，但洞察变浅了。给他一份 AI 生成的初稿，他很少质疑框架本身，更多是在调措辞和补细节。

这种变化很难自我察觉。因为你的产出效率确实提高了，表面质量也不差。你要到某一天被逼着在没有 AI 的场景下独立做一件事，才会发现自己的"裸奔能力"下降了多少。

谁先动脑

到这里你可能会想：那就少用点 AI 吧。但这不是我的结论。

MIT 的那个实验有一个被报道得比较少、但我认为最重要的发现。第四个月做了交叉：让 AI 组独立写，让独立组用 AI。

结果很清楚：先独立思考三个月、第四个月才用 AI 的人，即使用了 ChatGPT，大脑活跃度没有下降。他们的认知网络已经够强壮了，AI 削弱不了它。反过来，用了三个月 AI 再被要求独立写的人，脑连接度已经明显松弛了。更糟的是，他们开始不自觉地复用 AI 曾给他们的短语和结构。

问题不在于用不用 AI，而在于谁先动脑。

这跟我自己的体感完全吻合。我的每日复盘本质上就是在做"先独立思考"这件事。不是在 AI session 过程中思考，那时候你已经在 AI 的框架里了。而是在 session 结束后，拉出来，自己重新过一遍：今天的判断对不对？哪些是 AI 给的框架，哪些是我自己想的？有没有被带偏？

这个过程费劲。说实话有些日子我也想偷懒跳过。但坚持下来的体感很明确：有复盘的时候，第二天和 AI 协作的质量明显更高。你带着更清晰的判断进去，AI 的产出就更精准。没复盘的时候，你的判断模糊了，AI 的产出看起来都"差不多行"，你也就接受了。然后你的判断进一步模糊。然后认知债务开始滚利息。

放大器只放大你已有的东西

我一直跟自己说一句话：AI 是放大器，不是替代品。

如果你有认知结构，AI 放大你的结构，让你更快更好。如果你没有，AI 放大的只是噪声和惰性。放大器的特性决定了：输入的质量比放大器本身更重要。你带着清晰判断去用 AI，得到高质量的加速。你带着模糊想法去用 AI，得到包装精美的平庸。区别不在 AI，在你。

还有一件事我最近想得比较多：AI 把代码和内容的生成成本推向零了，但理解和判断的价值反而上升了。这两件事指向同一个方向。你应该把省下来的时间投到那些 AI 做不了的地方，比如定义问题、形成判断、做出取舍。而不是把省下的时间全用来让 AI 帮你生成更多产出。

但现实恰恰相反。BCG 今年的调查发现，AI 没有减轻工作者的负担，它扩大了你的"责任球体"。上级发现你一小时能做完以前六小时的活，于是给了你六倍的任务量。你用 AI 省下的时间没被用来深度思考，而是被填满了更多任务。于是更依赖 AI，更没时间独立思考，判断力进一步退化，然后更依赖 AI。

这才是真正的恶性循环。不是"AI 让你变笨"这么简单，而是一个系统性的陷阱。

我怎么做

说了一堆问题，说说我自己的三个做法。

第一，每次用 AI 之前，先花几分钟形成自己的初步判断。不需要很完整，但至少要有一个方向。保证自己是在 AI 的帮助下深化自己的思考，而不是在 AI 的框架里做修补。

第二，每天做复盘。我跑了 161 天了，效果是双向的：AI 越来越符合我的预期，我对自己认知盲区的感知也越来越敏锐。复盘的核心不在于记录做了什么，而在于分辨：哪些判断是我自己的，哪些是 AI 的。

第三，刻意保留一段无 AI 的时间。不长，半小时到一小时。写东西、跑步、想问题，干什么都行。重点是让大脑在没有辅助的情况下独立运转一段时间。就像健身一样，你可以用器械辅助，但得有几组是自重训练。

这三件事的共同逻辑是什么？保持"认知做功"。学习和成长只发生在大脑做功的时候。AI 最大的诱惑不是它能做什么，而是它让你可以不做什么。但你不做的那些事，恰恰是认知在生长的时刻。

大脑用则进，退则废。这句话在 AI 时代不是变假了，是变得前所未有地真了。因为"不用"变得太容易了。

关键来源：MIT Media Lab arXiv:2506.08872 · Wharton/PNAS Nexus pgaf316 · BCG/HBR AI Brain Fry 2026

巧的是，我刚结束今年暑期实习招聘的终面。过去一个多月面了 26 位硕士和本科生，覆盖算法、开发、数据科学几个方向。面完之后最大的感受，和 Jobright CTO 说的几乎一模一样：不是学生能力不行，而是大多数人还在用五年前的方式来准备一场 2026 年的面试。

"说"正在贬值

我先说一个底层逻辑，理解了这个，后面的东西自然就通了。

AI 之前，校招的筛选机制是这样的：学生拿着简历，聊 30 分钟到一个小时。简历里的硬通货（学校、GPA、实习、论文、竞赛）提供背书，面试中看逻辑表达、专业深度和沟通能力。这套机制运转了十几年，大家都习惯了。

但 AI 时代这套机制正在失效。原因很简单：当 AI 能帮任何人生成一份漂亮的简历、写出看起来很专业的项目描述、甚至在面试中提供实时辅助的时候，"说"本身的可信度在急剧下降。

我面试中碰到一个真实的情况。有位同学简历上写了"AI Code Review 系统"，看上去很前沿。面试一追问，发现本质就是在 Cursor 里写了一个提示词，手动把代码贴进去跑一遍，再把结果复制给同事。他不是在骗人，但简历上那个词和实际做的事情之间的落差，在 AI 时代会被无限放大。

所以企业现在越来越看重一件事：你能不能"show me"，而不只是"tell me"。

丢一个 GitHub 链接，代码质量、项目结构、迭代历史一目了然。打开你的 CLAUDE.md 文件，面试官立刻知道你和 AI 的协作到了什么程度。给面试官看一个你完整交付的东西，胜过你讲十分钟项目经历。

这不是面试官故意刁难。是因为在一个 AI 能帮你"说"的时代，只有"做出来的东西"才是不可伪造的信号。

终面面试官真正在看什么

再说一个很多学生不了解的内部视角。

现在校招面试一般分两轮。技术初面由团队骨干主持，考的是专业基本功，在细节层面看你是否合格。通过初面之后，终面由更高层级的面试官来做，这一轮基本不再考技术细节了。

为什么？一方面到了这个层级，面试官对具体技术细节的把控不一定比一线同事精准；另一方面，终面要判断的东西不一样——潜力、思维方式、成长性，这些更难量化的东西才是终面决定录不录你的核心。

以前这些东西靠经验和直觉判断。但现在有了更好的方式：如果你有一个 GitHub 仓库、有一个完整的项目、有你自己的 AI 工作流配置文件，终面面试官可以在面试前就借助 AI 对你的项目做深度观测。你的代码组织方式、你的设计决策、你和 AI 的协作模式、你在项目中遇到问题时怎么解决的，这些信息全在那里。

这比你在面试中口头回答三个问题，信息密度高出一个量级。

所以 AI 改变了两件事：一是"说"在贬值，二是"做出来的东西"可以被更高效地读取和评估。 两头一挤，结论就很清楚了——有作品的人会越来越占优势。

我实际看到了什么

说回这 26 个人。我在面试中有一个习惯：直接让候选人打开他们的 CLAUDE.md 或 agents.md 文件给我看。

结果是大部分人愣住了。26 个人里只有 2 个有成熟的 AI 工作流。不到 8%。

剩下的人大致这几种情况。

把 AI 当搜索引擎用。 占了至少三分之一。我问"你平常用 AI 吗？"都说用。怎么用？打开浏览器问 ChatGPT 一个问题，看回答。有位同学很坦诚，我说"就把它当成高级版搜索"，她直接说"对，是的"。当整个行业已经从对话式交互迁移到 IDE 类工具的时候，这些同学还在浏览器里一问一答。

研究 AI 但不用 AI。 这个反差最让我意外。有位做大模型微调的同学，自己写代码只用豆包当搜索。有位本硕都读 AI 专业的，从没用过 Cursor。能把 PPO、DPO、GRPO 三种对齐算法讲得头头是道，但可能从没让 AI 帮自己完整做成过一件事。造工具和用工具，是两回事。

用了很多工具但没有方法论。 有位同学付费用了 GPT 和 Trae，使用频率很高。但当我问"你有 agents.md 吗？"他不知道。问他怎么约束 AI 不重复犯错，他说写了个文件，让他给我看，他说好像在实验室电脑上。这意味着 AI 每次都不知道他在做什么项目，相当于永远带着一个失忆的人一起工作。

让我眼前一亮的那 2 个人，共同特征是：问他们 AI 的问题，不像在回答面试题，而是在聊他们每天都在做的事。一个人业余时间自己搭了选股 Agent，写 skills 并持续迭代，出发点是真实需求。另一个在微软有无限 Copilot 额度，但选了 Claude Code 做主力，能说清为什么。

使用 AI 是动词，不是名词

这个社区一直在说的一个观点，我觉得特别到位：使用 AI 是一个"动词"，不是一个"名词"。

很多学生把"了解 AI"当标签。看了几篇文章、知道一些概念，觉得自己"会 AI"了。但 AI 的真正价值只有在动手的过程中才能体会。什么时候该信任它的输出，什么时候该打断它；怎么给 AI 足够的上下文让它做对事情；碰到它反复犯同一个错误该怎么约束它。这些东西看文章看不出来。

面试中有位同学让我印象深。他能引用 Anthropic CEO 的话，用比喻描述 AI 对工作方式的变革，讲得很有见地。但当我追问他自己的 AI 工作流是什么，他答不出来。认知超前但行动为零，这是我看到的最典型的错位。

在过去，企业希望学生除了上课和写论文，还能有实习和项目经历。实习经历意味着实践，现在在绝大多数企业都希望寻找到那些有 AI 属性的毕业生时，AI 时代的实践是什么？我想，跟过去的实习经验，又不同了。现在对实践的要求非常直白：你在 AI 上有没有动手能力。为什么会要求动手能力，是因为面试你的那群人，也都每天在承受被 AI 变化驱动带来的震撼或者焦虑，他们很清楚，AI 每天都在变化，应对这种变化，或者说，在这种变化中，与企业的业务做好结合的前提，就是 AI 体感。而这种体感只能从使用中获得，和所有快速变化的领域逻辑一样——光看方向盘说明书不行，你得真开过车。

具体怎么做

如果你正在准备找工作，以下几件事我觉得值得好好考虑一下。

从今天开始，用 AI 去做一件完整的事。什么事都行：一个小工具、一个自动化脚本、一个数据分析流水线。过程中你自然会碰到怎么选工具、怎么配上下文、怎么约束 AI 的问题，这些问题会逼你建立自己的方法论。

做完之后，你会有一个 GitHub 仓库，里面有你的代码、你的 CLAUDE.md、可能还有几个你写的 skills。这些东西加在一起，就是你在这个时代最有说服力的能力证明。面试时打开给面试官看，比任何话术都管用。

如果你还有余力，把你做的东西、学到的东西分享出来。技术博客、小红书笔记、LinkedIn 上一段项目总结，什么形式都行。这些公开可见的内容就是"signal"——它传递的不是"我有多厉害"，而是"我知道什么是真正有价值的"。

GitHub、真实项目、技术博客、有干货的社交媒体 profile——把这几个装点齐全，三个月足够了。

写在最后

说这些不是为了制造焦虑。从我面试的情况看，绝大多数人还没有开始。你花两三周时间认真做一个东西出来，就已经站在前 5% 的位置了。

我自己在 AI 这条路上受益于课代表与鸭哥社区的课程和氛围。Architect 课程帮我建立了对 AI 架构和工作流的系统认知，社区里大家分享的实践让我少走了很多弯路。其实社区里面免费的文章就很多，有条件的同学如果有机会去看看系列课程，然后跟着做完一个项目，我想你能感受到不同，并且这种不同也能传递到你的面试官。如果条件不允许，我也建议从今天开始，把"名词"变为"动词"。因为我面试的过程中我都在想这个事情，如果这些学生，哪怕就上一周的课，哪怕有一点点"做出来的东西"，他们都会因为这种不对称优势，而迅速排到前列，而那恰恰是面试官最想看到的。

这件事值得想深一层。不是"为什么领英在中国失败了"这种商业分析选题，而是一个更底层的问题：为什么中国根本不需要 LinkedIn 这个品类？以及，LinkedIn 在海外正在变成什么？

LinkedIn 需要什么样的土壤

LinkedIn 2003 年上线时，美国的社交网络还是荒地。Facebook 还没出生，人们的职业关系散落在邮件、名片夹、行业会议中。LinkedIn 做了一件简单的事：给每个职场人一张"活的名片"，让弱连接可以被激活。

这个模式的前提是：人们的社交关系没有被一个超级平台垄断。

中国的情况完全不同。猎聘 CEO 戴科彬在 2014 年就看得很清楚：

"LinkedIn 上线时美国没有 IM 社交领域，Facebook 还没出现，他们的社交需求被 LinkedIn 满足了。但中国有 QQ，中国人工作时间都挂着 QQ，现在有了微信……中国人的职业习惯已经被培养为另一种模式了。"

这不是"产品做得不好"的问题，是生态位已被占据的问题。微信让中国人不需要区分"职业社交"和"生活社交"。你的老板、同事、猎头、客户、前同事，全在微信里。加微信就是建立关系，不需要另一个平台。

更深的裂缝：关系文化 vs 弱连接文化

LinkedIn 的核心机制是"弱连接"（weak ties）。社会学家 Granovetter 1973 年的论文《弱连接的力量》说了一个反直觉的观点：给你带来新工作机会的，往往不是密友，而是"认识但不熟"的人。LinkedIn 把这个理论产品化了。

中国的职场不是这样运作的。

中国人靠"关系"（guanxi）：强信任、面子、中间人引荐。你想接触一个人，不是发一封 cold InMail，而是找一个共同认识的人"打招呼"。这个中间人不是算法推荐的"你可能认识的人"，而是一个真实的人、真实的面子背书。

所以 LinkedIn 的核心能力，在中国几乎没有用武之地。

更微妙的是，中国社交产品有一个反复验证的规律：关系链一旦泛化，平台就会失去价值。人人网、微博、微信朋友圈，全都经历了从"私密分享"到"不敢发言"的退化。LinkedIn 那种"所有职业关系都加"的模式，天然就是泛化的。它在中国注定会变成一本"有事才翻"的黄页。

需求没有消失，只是被拆碎了

中国人不用 LinkedIn，不代表没有对应的需求。只是这些需求被不同的产品分别满足了：

求职：BOSS 直聘用"聊天即投简历"的轻模式覆盖从蓝领到白领，1.6 亿月活。中国人需要高效的求职工具，但不需要它附带社交功能。

职场八卦和信息不对称：脉脉的"职言"匿名社区是 LinkedIn 永远不可能做出来的东西。它满足了中国人在职场中"脱去假面"的需求。同事之间的真话，只有匿名才能说出来。

职业关系维护：微信。

个人品牌和行业影响力：分散到了微信公众号、知乎、即刻、小红书。没有一个统一的"职业内容平台"。

这就是 LinkedIn 在中国"不存在"的真相：不是市场空白，是需求被拆碎了。

同一时间，LinkedIn 在海外变成了什么

有意思的是，当 LinkedIn 离开中国的同时，它在海外正经历一次深刻的转型。

2025 年的数据：12 亿注册用户，3.1 亿月活，年营收超 163 亿美元。但真正重要的不是数字，是使用方式的变化。

LinkedIn 正在从"找工作时才打开的平台"变成"职业人的社交媒体"。具体表现：

内容创作爆炸。LinkedIn 的 Feed 不再是"张三升职了""李四换工作了"的通知流。大量用户在上面写行业观察、分享工作心得、发表观点。"LinkedIn Influencer"是一个正式的身份。

Personal Branding 成为核心动机。越来越多人使用 LinkedIn 不是为了"找下一份工作"，而是为了"让下一份工作来找我"。通过持续输出内容，建立行业认知度和不可替代性。

从工具到社区。评论区形成了高质量的行业讨论。很多人每天打开 LinkedIn 的频率和 Twitter 相当。

说白了：LinkedIn 正在变成"穿西装的 Twitter"。一个以职业身份为锚点的内容社交平台。

这暴露了什么

中国没有 LinkedIn，海外 LinkedIn 正在社交化。两件事放在一起，暴露的是一个系统性差异：

中国是"超级 APP + 功能整合"模式。微信一个 APP 解决通讯、社交、支付、小程序、公众号。需求被一个平台通吃，垂直平台很难生存。

海外是"垂直 APP + 场景分离"模式。工作用 LinkedIn / Slack，社交用 Instagram / Twitter，通讯用 WhatsApp。每个场景有独立的平台和独立的身份。

哪个更好？没有答案。但它解释了为什么同一个产品思路，在两个市场得到完全相反的结果。

一个未被满足的缝隙

但这里有一个微妙的空白。

LinkedIn 在海外正在做的那件事，"通过持续内容创作建立职业影响力"，在中国其实没有一个好的承载平台。

微信公众号太重、太正式。知乎太杂、太容易被带偏。脉脉太匿名、太八卦。即刻太小众。小红书太生活化。

一个介于"正式发文"和"随手分享"之间的、以职业身份为锚点的内容社区，在中国并不存在。脉脉试图往这个方向走，但它的匿名基因让它很难成为一个"实名知识分享"的地方。

这可能是中国互联网真正的"LinkedIn 缺位"：不是缺一个求职工具，不是缺一个人脉平台，而是缺一个让职场人可以持续、轻量、实名地输出专业内容并建立行业认知的地方。

谁能填补这个缝隙，谁可能就是中国的"下一代 LinkedIn"。但也许，它根本不会以 LinkedIn 的形态出现。

用了几轮之后，我的体感是：很容易一两轮就停。而同样的任务交给 Ralph Loop，至少能主动优化三五轮。不是 Codex 不努力，是它停下来的时候真诚地认为自己完成了。

这让我很好奇：两个功能描述几乎一样的东西，为什么体验差这么多？

调研之后我的判断是：体感大概率是对的，但原因不是"Codex 的 /goal 比 Ralph Loop 弱"。而是这两个东西的目标函数根本不同。

它们不是同一种产品

先说 /goal 在技术上做了什么。4 月 30 日发布的 Codex CLI 0.128.0 加入了这个 experimental 命令。Simon Willison 第一时间分析了它，指出核心实现是两个模板文件：continuation.md 在每个 turn 结束后自动注入，提醒 agent "继续朝目标推进"；budget_limit.md 在预算快用完时提醒 agent "收尾，别开新坑"。

Ralph Loop 呢？Geoffrey Huntley 的原始设计只有一行 bash：

while :; do cat PROMPT.md | claude-code ; done

一个外部循环，每次迭代启动一个全新的 Claude 进程。

表面上看，两者都是"循环做事直到完成"。但把它们的核心循环拆开看，差异是结构性的：

/goal 的循环是：持久目标 → idle 检查 → 注入 continuation prompt → 模型执行下一步 → 模型自己 audit → 模型标记 complete（或 runtime 预算到期强停）。

Ralph Loop 的循环是：外部脚本启动 agent → agent 做一轮 → 外部检测 completion signal → 如果不满足，丢弃上下文、保留文件状态、重新启动 agent。

前者更像"单 agent 的持久任务生命周期"。后者更像"多次独立审查的蒙特卡洛式工程搜索"。

为什么 /goal 容易一两轮就停

GitHub 上有一个精准定位了 /goal 核心问题的 Issue #19910。一位深度用户报告：密集使用 /goal 几天，在 ambitious work 上没有一次真正跑到完成。根因是 compaction：session 对话太长时系统会压缩历史，而压缩过程可能把 goal continuation prompt 丢掉。新一轮的 agent 只看到"刚才在跑测试，快完事了"，不知道这只是子步骤。于是验证完局部任务就标记 goal achieved。

但 compaction 只是表层原因。更深层的是 /goal 的续跑规则本身带有收敛倾向。

从 Codex 的 runtime PR 可以看到一个关键设计：如果某一轮模型用自然语言总结"我检查过了，目标已达成"而没有进一步调用工具，运行时不会触发下一轮 continuation。这意味着 agent 只要输出一段"总结性文字"而非动手操作，循环就自然停了。这大概率就是我体验到"一两轮就停"的直接技术原因。

再看 continuation.md 模板本身。它要求 agent 在决定完成前把目标重述成 deliverables/success criteria，建立 prompt-to-artifact checklist，检查文件、命令输出、测试结果等真实证据，只有 audit 显示"no required work remains"时才调用 update_goal complete。

这套设计对"验收型任务"很合理。但对"持续优化型任务"有天然收敛倾向：它问的是"显式要求是否都覆盖了"，而不是"还有没有高价值的非显式改进机会"。

Ralph Loop 的主动性从哪来

理解了 /goal 的收敛设计，Ralph Loop 的优势就不只是"架构更好"那么简单了。它的主动性来自一个反直觉机制：不是让同一个 agent 更聪明，而是不断制造新的、不完全一致的审查视角。

每次 bash loop 迭代启动的新 Claude 进程：没有上一轮的对话历史，没有自我确认偏误，通过 git diff 和文件系统状态来了解"上一轮做了什么"。它会自然产生新的 framing：刚才那轮完成了什么？测试能过吗？结构还能更好吗？有没有边界情况没覆盖？

LLM 在同一上下文里容易产生承诺一致性，就是"我已经做得差不多了"的路径依赖。Fresh run 会降低这种依赖。对于架构优化、质量提升、测试补洞这类开放任务，重新采样通常比继续同一条思路更有效。

Blake Crosley 的实践报告证实了这一点：他用 Ralph Loop 架构跑了多个通宵 session，交付了 3,455 行 Python 代码和 141 个测试。HN 上也有人总结：Ralph 这类东西的核心价值是"在长期任务中纠正 drift"，通过 fresh context 打破 agent 的自我满足叙事。

公平地说：/goal 的早停不全是 bug

写到这里需要补一个视角。如果只从"谁循环得更久"来评判，对 /goal 不公平。

/goal 是 OpenAI 官方运行时的一部分。它必须考虑预算控制、用户可暂停恢复、误触发防护、安全边界。PR 里明确说不让模型从普通 task request 推断 goal，不给模型 broad control over user/runtime-owned state。这些产品约束是有意为之的。

Ralph Loop 是社区脚本。它的哲学是粗暴但有效：不断跑，直到外部条件满足或 max iterations 停止。有些实现加了 rate limiting、circuit breaker，但本质仍然是"外部循环优先"。它更浪费，但更不容易满足于第一轮的局部最优。

所以 /goal 的早停有三层原因：

• 技术层：compaction 丢失 goal context、"无 tool call 则不续跑"规则
• 设计层：continuation prompt 的审计逻辑天然偏向收敛
• 产品层：safety 和 cost control 的有意约束

它不是一个"做坏了的 Ralph Loop"。它是一个不同目标函数的产品，碰巧被社区拿来跟 Ralph Loop 对比。

真正的判断：你的任务是哪一种

两种工具做的事用人话说：

/goal 是一个合规的工程员工：拿到需求、执行、验收通过、汇报、停止。它擅长"把一个明确的 goal 可控地做完"。

Ralph Loop 是一个偏执的外部审稿流程：你说完成了，我换个脑子再看一遍。你还是说完成了，我再换个人来看。它擅长"不断发现下一个改进点"。

我之前觉得 /goal "不好用"，本质上是因为我给它的任务不是"做完一个有明确验收标准的需求"，而是"持续优化，帮我发现还能更好的地方"。前者 /goal 理论上可以做（如果 compaction 问题修好的话），后者它的设计基因就不支持。

换句话说：你觉得 Ralph 更好用，暴露的是你的真实任务性质。你不是在"达成一个 goal"，你是在"持续发现下一个更高价值的 goal"。这两者不是同一个产品形态。

架构差异的本质：自检 vs 外审

抽象到更一般的层面，这里有一个工程管理中的经典问题。

让同一个 agent 在同一个 session 内自我评估是否完成，本质上就是"自检"。让一个全新的 agent 来审视上一轮的产物，是"外审"。

自检不如外审可靠，这是组织管理、软件工程、质量体系都验证过的普遍规律。代码要别人 review，审计要独立第三方。不是因为你不诚实，是因为你不可能客观审视自己持续投入的工作。agent 也一样，在同一 context 里积累的"我在认真工作"叙事会形成路径依赖。

Ralph Loop 通过进程级隔离实现了"外审"。每次迭代是一个独立的 code review + continue 决策。/goal 通过 prompt 注入试图在"自检"框架内提高审计质量。前者结构上更可靠，后者产品上更可控。

实操建议：混合架构

如果你跟我一样，日常任务里"持续优化"比"验收完成"更多，有一个比较务实的混合做法：

用 /goal 做单轮长任务的内层执行器（它对有明确 deliverables 的单次任务确实比反复手动"继续"好用）。在外层套一个 Ralph 式的循环做"反满意"外壳。外层不需要一直让它写代码，可以交替执行三种 prompt：builder、reviewer、regression-finder。只有 reviewer 连续两轮找不到 material issue，外层才停。

这正好补上 /goal 的弱点：/goal 擅长沿着目标推进，外层 loop 擅长"不相信它已经完成"。

如果非要只选一个，我的判断是：对于"做完一个有验收标准的需求"，等 /goal 修好 compaction 问题后值得一试；对于"持续优化、不断发现改进点"这类开放任务，Ralph Loop 的架构基因更匹配。它的"浪费"（每轮丢弃上下文）恰恰是它的优势（破坏 agent 对自己已完成的叙事）。

带走一个判断框架

评估 AI coding 工具的自主循环能力时，不要看功能描述，看三个设计选择：

• 循环边界在哪里：进程级 > session 内 stop hook > session 内 prompt 注入 > 手动"继续"
• 完成判断由谁做：外部验证 > 独立 agent 审视 > 同一 agent 自评
• continuation 的触发条件：外部不满意就续跑 > 有 tool call 才续跑 > 无条件续跑

更关键的是：先想清楚你的任务属于哪种。

如果是"把这个明确的需求做完"，你需要的是一个可预算、可审计的完成器。/goal 的方向是对的。

如果是"帮我持续发现还能更好的地方"，你需要的是一个不断重新采样的搜索器。Ralph Loop 的架构更匹配。

工具不分好坏，但目标函数要对齐。你觉得一个工具"不好用"，很多时候不是工具有问题，是你在用验收型工具做搜索型任务。

这不是空想。2024 年 7 月，牛津大学的 Shumailov 等人在 Nature 正刊上证明了一件事：AI 模型训练在自身生成的数据上，会发生不可逆的退化。他们给这个现象起了个名字，叫 Model Collapse。数学上，这不是可能性，而是必然性。

"Over time, models start losing information about the true distribution, which first starts with tails disappearing, and learned behaviours converge over the generations to a point estimate with very small variance."

翻译成人话：模型先丢掉稀有但重要的知识（长尾），然后所有输出趋向"安全的平均值"，最后变成一团正确但无趣的白噪声。

有人给这个过程起了一个更形象的名字：Habsburg AI。

哈布斯堡的诅咒

Jathan Sadowski 在 2023 年造了这个词。哈布斯堡王朝是欧洲历史上最强大的皇室之一，为了保持血统纯正，数百年来坚持近亲通婚。结果是末代国王查理二世：近交系数 0.25（等同于亲兄妹后代），不育、智力低下、下颌畸形。王朝因此终结。

生物学的原理很简单：近亲繁殖让隐性有害基因有更高概率被"双份激活"。基因多样性是种群的保险：它确保当环境变化时，总有一些个体携带应对新挑战的遗传方案。一旦基因池收窄，这个保险就消失了。

AI 正在走同一条路。当模型 A 的输出成为模型 B 的训练数据，B 的输出再喂给 C，每一代都在丢失原始分布中的"稀有等位基因"。互联网上 AI 内容已超过 50%，Graphite 的数据显示 2024 年 11 月起 AI 生成文章数量首次超过人类。也就是说，下一代模型的训练语料里，有一大半是上一代模型"排泄"出来的。

这像极了猎豹的命运。猎豹在末次冰期经历了两次遗传瓶颈，精子异常率至今高达 71%，整个物种脆弱到一场传染病就可能全军覆没。它们跑得飞快，但遗传上已经是一个"几乎相同的个体"的群体。AI 模型也在变得更"流畅"更"快"，但内在的知识多样性正在坍缩。

文明从来在碰撞中产生

人类进化史上有一条反复验证的规律：隔离导致退化，碰撞带来创新。

最极端的案例是塔斯马尼亚岛。一万年前海平面上升切断了它与澳大利亚大陆的联系，此后不足 5000 人的岛上社会，在 8000 年间逐步丧失了骨制工具、渔网、防寒衣物、回旋镖。哈佛大学的 Joseph Henrich 用数学模型证明：文化传承本质上有损，每一代学习者无法完美复制前辈技能。群体越大，出现"偶然改进"的概率越高，可以对冲这种损耗。但当群体太小、又与外界隔绝，技术水平就会呈净下降趋势。

反面的例子同样有力。丝绸之路不只是贸易通道，它是知识的超级公路。阿拉伯数字其实起源于印度，经伊斯兰黄金时代的数学家系统化后传入欧洲，催生了文艺复兴的计算革命。伊斯兰帝国之所以能在 8 到 14 世纪成为全球知识中心，核心原因是它打通了中国、印度、波斯、希腊、埃及的知识流通。Frans Johansson 把这叫做"美第奇效应"：当不同学科、文化和产业在同一个物理空间碰撞时，突破性创新就会涌现。

Henrich 的理论可以浓缩成一句话：创新不是个人天才的产物，而是"集体大脑"在足够大的社会网络中运作的涌现属性。

现在再看 AI 正在做什么：它在缩小这个集体大脑的有效尺寸。

从分发层到生产层：问题已经下沉

互联网时代我们已经体验过"回音室效应"：算法推荐让你只看到你想看的内容。但那是分发层面的问题，信息本身还是多样的，只是分发机制在做筛选。

AI 时代的危险在于，问题从分发层下沉到了生产层。不是"你只能看到你想看的"，而是"所有人只能想到同样的东西"。

2026 年发表在 Nature 正刊上的实证研究分析了 4130 万篇论文，发现了一个悖论：使用 AI 工具的科学家个人产出提升 3 倍、引用提升 4.8 倍、晋升加快 1.37 年。但同时，AI 采纳使得学术界研究的主题总量缩减了 4.63%，科学家之间的互动降低了 22%。

个体变强了，集体变窄了。

Cornell 大学的实验更直观：让印度和美国的参与者使用 AI 写作后，两国人的文字"变得更相似"，都趋向"西方规范"。甚至被问到最喜欢的食物时，用 AI 辅助的人更可能回答"pizza"。

"AI is a technology of averages: large language models are trained to spot patterns across vast tracts of data; the answers they produce tend toward consensus."
— Kyle Chayka, The New Yorker

剑桥大学的 Traberg 等人在 2026 年把这个循环描述得很清晰：研究 AI 的实践本身正在变得统一，不仅是研究什么在收敛，连问题怎么被框定、怎么被调查、怎么被评估，全在趋同。他们引用了一个精准的类比：

"Just as biodiversity protects ecosystems from collapse, intellectual heterogeneity protects science from paradigm shocks."

三条链条的正反馈环

把上面说的整合起来，我看到三条因果链在互相喂养：

链条 A：AI 工具同质化 → 研究方法和主题趋同 → 科学变成"单一种植"。

链条 B：AI 训练数据来自 AI 输出 → Model Collapse → 知识退化，尾部消失。

链条 C：AI 生成内容占据互联网主体 → 人类原创被挤出 → 认知多样性萎缩。

A 减少了 B 的多样性输入，B 加速了 C 的退化速度，C 进一步缩窄了 A 的研究视野。这是一个正反馈退化环。

最让我不安的是第三条链。StackOverflow 的问题量已经下降了 78%。不是因为人们不再有问题，而是问技术问题的习惯正在从"社区互答"迁移到"问 AI"。但 AI 的回答是基于它训练时吞掉的那些社区问答。一旦社区萎缩，AI 的知识来源也在萎缩。这像一棵树在啃食自己的根。

解药存在，但需要刻意的制度设计

好消息是，生物学早就给出了解法：引入外来基因。瑞典有一个被农业活动隔离的蝰蛇种群，出现了高比例的死产和畸形。研究者引入了其他种群的个体后，种群迅速恢复。

对应到 AI：NeurIPS 2024 的论文证明，只要训练时把合成数据"叠加"到真实人类数据上（而不是替换），Model Collapse 就可以被避免。甚至只保留 10% 的真实人类数据，就能显著延缓退化。

但这需要刻意的制度设计，不会自发发生。几个方向值得关注：

• 数字种子库：有人已经在系统性存档 AI 爆发前的人类创作内容，类比冷战后科学家保存"核爆前钢铁"（未被核辐射污染的钢材在精密仪器中不可替代）。
• 数据血统管理：标注每条训练数据是人类产生还是 AI 产生，建立来源溯源。哈佛法学院已经在讨论"未被 AI 污染的人类数据权利"。
• 方法论多元主义：在学术资助中刻意保护非 AI 路径的研究。不是所有问题都应该用同一把锤子。
• 跨模型杂交：有实验证明，用模型 A 的输出训练模型 B（不同架构），比 A 训练自己退化更慢。类似于远缘杂交的杂种优势。

我的判断

Model Collapse 不是终将到来的末日预言，它是已经在发生的渐进过程。互联网内容中 AI 的占比每月都在上升，每一天都有新的模型在训练时不自觉地吞入上一代模型的输出物。

但我不认为这是不可逆的宿命。它更像一个公共卫生问题：如果放任不管，退化会持续加速；如果有意识地管理数据来源的多样性，保持人类原创输入的"基因流"，系统可以维持健康。

真正让我警惕的，是一个更深层的问题。AI 正在把知识生产从"碰撞模式"推向"收敛模式"。在碰撞模式下，不同背景、不同训练、不同文化的人互相激发，产出超越各自视野的新东西。在收敛模式下，所有人用同一个工具、看同一批数据、得到同一个"最可能的答案"。

人类文明最伟大的突破，几乎都来自碰撞：希腊哲学遇到阿拉伯数学产生了科学方法，东方丝绸遇到西方玻璃催生了光学实验，生物学观察遇到工程学思维发明了尼龙搭扣。

如果 AI 让所有人都在同一个知识空间里用同一种方式思考，那么即使每个人都变得更"高效"了，人类作为整体的创新能力也可能在下降。就像塔斯马尼亚岛上的居民：他们并不比祖先更笨，但因为群体太小、太隔绝，无法维持复杂技术所需的知识传承临界量。

AI 时代的反直觉真相是：让所有人都变聪明的工具，可能让人类集体变蠢。

解法不是拒绝 AI，而是刻意维护多样性。用不同的模型、保留人类原创、鼓励跨界碰撞、保护那些"低效但独特"的知识路径。在进化论里，那些看起来没用的基因变异，往往是物种在下一次环境剧变中存活下来的关键。

知识世界也一样。

这个问题背后有一个看起来矛盾的信号。一方面，技术社区里"RAG is dead"的声音此起彼伏，长 context window 每半年翻一倍，Gemini 的 1M token、Claude 的 200K，似乎让"先检索再生成"越来越多余。另一方面，打开 Indeed 一搜，4800+ 个标注 RAG 的职位在招，高级岗薪资 $240K 起步，MarketsandMarkets 预测整个 RAG 市场 5 年内从 $19 亿涨到 $99 亿。

如果 RAG 真的在死，为什么就业市场在疯狂招人？

我的判断是：RAG 作为一个 demo 级技能在贬值，但 RAG 作为企业级系统工程在增值。公司招的不是"会用 LangChain 搓一个 pipeline"的人，而是能解决三个远比 RAG 本身更难的问题的人：合规和权限控制、可观测性与评测、Agentic RAG 编排。

这三件事跟网上 99% 的 RAG 教程完全不是一个东西。

教程教的 RAG 为什么越来越不值钱

打开 YouTube 或 Medium，2026 年的 RAG 教程和 2024 年几乎没有区别：加载文档、切分 chunk、生成 embedding、存入向量数据库、查询检索、拼接 prompt、调用 LLM 生成。四步走。一个下午就能跑通。

问题在于，这四步走的价值正在被两个方向同时压缩。

从上面看，长 context window 在蚕食简单场景。Tian Pan 的 production 决策框架给了一组很务实的数据：Gemini 1.5 Pro 在 needle-in-haystack 上达到 99.7%，但在现实的多事实检索上只有 60%，延迟是 RAG 的 30-60 倍，成本是 1,250 倍。换句话说，对于"一个文档里找一个答案"这种简单任务，长 context 已经够用了。RAG 在这个场景里确实在变多余。

从下面看，框架在把搭建门槛压到接近零。LangChain 和 LlamaIndex 让任何人都能在几小时内搭出一个 RAG demo。但真实工程经验揭示了硬币的另一面：同一个抽象层在 demo 阶段省了时间，到生产阶段每个请求多加了 2 秒延迟。TechTide 有一个尖锐的总结："LangChain 因为门槛低成为所有人的第一选择，也正因如此，很多团队用它构建了不该用它的系统。"

这两个方向的合力，让"会搭 RAG pipeline"这个技能的稀缺性快速蒸发。它变成了一个入门级操作，类似于 2015 年的"会写 SQL 查询"。有用，但单独拿出来不值钱。

公司真正在招的，是三种不同的能力

KORE1 的薪资指南有一句话说得很到位：

"RAG architecture went from obscure to essential in about eighteen months. The people who've done it well, in production, at scale, have their pick of opportunities."

关键词是 in production, at scale。不是"会搭"，是"搭了能用、用了不出事、出了事能查"。

DevOpsSchool 的 Senior RAG Engineer 角色蓝图把这个需求拆得很清楚。十项核心职责里，搭建检索管道只占两项。剩下八项全是教程不教的东西：安全加固、评估体系、可观测性、生产运维、质量门禁、护栏编排。

第一：合规和权限控制

这是最被低估的方向，也是最致命的。

标准 RAG 的安全模型有一个根本性的漏洞：向量数据库检索的是语义最相似的文档，不管这些文档的所有者是谁。安全研究者 Christian Schneider 把这叫做 RAG 的"信任悖论"：用户查询被当作不可信输入，但检索到的上下文却被隐式信任，尽管两者进入了同一个 prompt。

这不是理论风险。2024 年 8 月，PromptArmor 发现 Slack AI 存在间接提示注入漏洞：攻击者在公开频道发布恶意指令，当其他用户使用 Slack AI 时，系统将该消息检索为上下文并据此构造钓鱼链接，可以从攻击者无权访问的私有频道泄露 API key。Amine Raji 的实验更直接：在标准 ChromaDB + LangChain 栈上，跨租户数据泄露在 20 次查询中 100% 成功，"不需要任何技术能力"。

四大主流向量数据库（Pinecone、Weaviate、Qdrant、Milvus）都不原生支持 ACL 和每查询审计日志。权限控制必须在应用层从头构建。教程永远不会教你这些，因为解决方案不是通用的，它需要知道"用户是谁"和"他们被授权看什么"。

第二：可观测性、评测和调试

RAG 的 debugging 跟传统软件有本质区别。传统软件失败时会崩溃、报错、返回错误码。RAG 系统的失败是安静的：它不崩溃，只是给了一个看起来合理但错误的答案。

更麻烦的是，失败会级联。Zen Van Riel 总结得很精准："Bad chunking causes bad embeddings, which causes bad retrieval, which causes bad generation. Fix the root cause, not the symptom." 你在生成层看到的问题，根因可能在切块层。

要诊断这些问题，需要一整套工具栈。当前最佳实践是三段式组合：开发期用 RAGAS 做质量评估，CI/CD 用 DeepEval 做部署门禁，生产环境用 LangSmith 或 Arize 做持续监控。这套能力已经催生了独立岗位：ZipRecruiter 和 Greenhouse 上都有专门的 LLM/RAG Evaluation Engineer 在招。

而且这个方向的价值不只在工程侧。EU AI Act 正在把 RAG 系统的可审计性从"最佳实践"提升为合规要求。对受监管行业来说，可观测性不是可选项。

第三：Agentic RAG

如果说前两个方向是"把 RAG 做对"，Agentic RAG 是"把 RAG 做强"。

传统 RAG 的管道是线性的：检索一次，生成一次。Agentic RAG 引入一个 Agent 作为编排器，让系统能动态决策：这个问题需不需要检索？检索结果够不够？要不要换个查询词再来？要不要拆成子问题分别检索？要不要调用其他工具来补充？

Self-RAG（ICLR 2024 Oral）让模型自行决定何时检索并自我评估质量；CRAG 在检索结果不满足时触发 web search fallback，准确率提升近 13%；Adaptive RAG 用小型分类器预判查询复杂度，动态选择检索策略。框架层面，LlamaIndex 最早推广 Agentic RAG 概念，LangChain 将 Agent 编排集中到 LangGraph，Microsoft 在 2025 年 10 月将 AutoGen 和 Semantic Kernel 合并为统一的 Agent Framework。

代价是 token 消耗3-10 倍。但对于跨文档合成、多步推理的复杂任务，这个成本是值得的。基准测试显示 RAG 在跨文档合成任务上比长 context 准确率高 67%，成本低 8 倍。

好事和坏事

好事在于，这三个方向远比"搓 RAG pipeline"更有职业价值。

合规和权限控制不是 RAG 独有的。掌握了它，你在做 MCP 集成、Agent 平台、企业数据中台时都用得上。可观测性和评测更是 transferable 的核心能力：任何 AI 系统进入生产都需要评测，任何 LLM 应用上线都需要可观测性。Agentic RAG 的 Agent 编排能力直接接轨整个 Agentic AI 赛道，Stanford AI Index 显示这个技能集群一年增长 280%。

用武侠的话说，这三条路打通的不是一个穴道，是任督二脉。

坏事在于，这些能力没办法通过跟教程搓 RAG pipeline 来学会。教程的 happy path 上没有权限问题（示例数据不分权限），不需要评测体系（示例问题有标准答案），不需要 Agentic 编排（示例查询单次检索就能回答）。

更深层的原因是：这三个方向本质上都是系统工程问题，不是算法问题。你不能通过读论文或看教程视频来掌握它们。你需要在一个真实的、多用户的、有权限边界的、有脏数据的、有合规要求的系统里摸爬滚打。

这也解释了为什么 Tunga 的观察如此尖锐：招聘经理"不知道怎么招、不知道怎么筛、不知道怎么评"。因为他们要的能力没有对应的教程认证，只有项目经历能证明。

"RAG is Dead"需要分层看

在简单场景上，RAG 确实在退让。一个文档内找一个答案，长 context 更直接。Callstack 的工程师在真实项目中发现，很多场景用"确定性预处理 + 结构化上下文注入 + 单次 API 调用"比搭完整 RAG 栈更简单。

但在企业场景上，RAG 不可能死。成本和延迟是第一个原因（1M token 请求成本是 RAG 的 1,250 倍）。知识库规模是第二个（2GB 文本约 5 亿 token，远超任何 context window）。权限隔离是第三个（长 context 要把所有文档灌入 prompt，权限隔离几乎无法实现；RAG 的分层架构天然支持 pre-retrieval filtering）。

所以更准确的说法是：naive RAG 在死，production RAG 在活。简单单文档查询长 context 准确率高 34%，跨文档合成 RAG 准确率高 67%。两者是按场景互补的关系，不是替代关系。

如果你要学，学什么

回到开头的问题：2026 年 RAG 值不值得学？取决于你学的是哪个 RAG。

如果你学的是"用 LangChain 搓一个 embed-store-retrieve-generate 的 demo"，这个技能的市场价值正在快速归零。不是因为它没用，而是因为它太容易被复制。

如果你把 RAG 当作一个入口，通过它进入企业级 AI 系统工程的三个核心领域，那它是目前最好的学习路径之一。RAG 是最早进入企业生产环境的 LLM 应用模式，它积累的生产经验最丰富、踩过的坑最多、形成的工程实践最成熟。通过 RAG 学合规，比从零学合规快；通过 RAG 学评测，比抽象地学方法论扎实；通过 RAG 学 Agent 编排，比直接跳进 Agentic AI 有更好的基础。

具体建议：

1. 跳过纯教程阶段，最多花一个下午。一个 demo 跑通就够了。
2. 尽快接触真实数据。找一个有权限边界的数据集（哪怕自己模拟多用户），体会"语义检索 vs 权限控制"的冲突。
3. 从第一天就搭评测体系。用 RAGAS 跑你的 pipeline，看 faithfulness 和 context precision 的分数。你会发现 demo 的好分数在换了数据集后会断崖式下跌。
4. 至少做一次 Agentic RAG 实验。用 LangGraph 搭一个会自我评估检索结果、会 rewrite query 的系统。你会立刻理解为什么这比 naive RAG 难一个数量级。
5. 读生产级经验，不读教程。Looming Tech 的企业部署经验和 Zeta Alpha 的 GenAI pilot 失败分析比任何教程都有价值。

回到那个矛盾：RAG 看衰和 RAG 招聘火爆并不矛盾。看衰的是教程级 RAG。火爆的是企业级 AI 系统工程，RAG 恰好是它最可见的入口。公司在 JD 里写"要会 RAG"，其实是在说"要会在生产环境里把 AI 做对"。

不要把 RAG 当终点学，把它当隘口学。穿过这个隘口，你进入的不是"RAG 专家"这条窄路，而是 AI 系统工程的广阔地带。合规、评测、可观测性、Agent 编排，这些能力在未来五年只会越来越稀缺。而 RAG，只是通往那里最近的一条路。

这句话如果只说一半，容易被误解成“本地 Agent 不重要”。我不是这个意思。对个人用户来说，本地 Agent 的优势非常明显。我的文件在本机，我的浏览器登录态在本机，我的开发环境在本机，我的很多真实 context 也只在本机。Manus 这样的 cloud agent 再强，也拿不到这些东西。它后来推出 My Computer，本质上就是承认 cloud sandbox 有本地上下文缺口。

但一旦把场景换成公司，这个判断就要反过来看。

公司的电脑名义上在员工手里，但资产、权限、知识和审计链路并不在员工手里。Wiki 在云上，Slack 在云上，GitHub 在云上，SharePoint 在云上，数据仓库在云上，CRM、工单、日程、邮件也大多在云上。员工只是被授权访问这些系统，不是这些系统的所有者。

所以企业 Agent 的真正问题，不是“云端好还是本地好”。
更正确的问题是：组织上下文在哪里，权限在哪里，审计在哪里，执行在哪里。

个人的 local 优势，到了公司会变成治理问题

个人使用 local agent 的优势很直接：它离真实工作现场最近。

你让它改一个本地项目，它能读文件、跑测试、看日志。你让它整理一堆桌面文件，它不用申请复杂权限。你让它操作浏览器，它可以借用你已有的登录态。对个人来说，这种“贴身”就是生产力。

但公司看同一件事，视角会完全不同。

本地 Agent 读了哪些文件？有没有读到不该读的目录？它调用了哪个 MCP？这个 MCP 是谁写的？有没有把数据发到外部网络？它生成的结果有没有被评测？失败日志在哪里？离职以后这些 skill 和上下文归谁？

个人觉得便利的地方，企业会看成治理盲区。

这不是保守，而是组织的基本责任。公司不是一个放大的个人。公司里存在团队边界、密级边界、地区边界、合规边界、系统边界、岗位边界。Agent 越能跨系统行动，越不能只靠个人本地自由配置。

云端不是因为更先进，而是因为更接近组织上下文

很多人讨论 cloud agent 时，会默认它和“模型更强”“算力更大”“异步执行”绑定在一起。这些当然重要，但不是企业场景里最本质的部分。

企业 cloud agent 真正的优势，是它天然更靠近组织系统。

公司里的上下文越来越少存在于某台电脑里，而是存在于一组 SaaS 和平台中：代码在 GitHub，文档在 SharePoint 或 Google Drive，沟通在 Slack 或 Teams，项目在 Jira，客户在 CRM，数据在 warehouse，指标在 BI，知识在 wiki，流程在工单系统。

如果 Agent 要回答一个真实业务问题，它需要穿过这些系统。它不是读一个本地文件就够了。它要知道这个人有没有权限，某个文档是不是最新，某个数据指标有没有认证，某个 Slack 讨论是不是只在小范围频道里，某个代码仓库是不是内部可见。

这也是为什么 OpenAI Company Knowledge、Microsoft 365 Copilot Agent Builder、GitHub Copilot Spaces 都在强调同一件事：尊重已有权限模型。OpenAI 说 Company Knowledge 只访问用户已经有权查看的内容；Microsoft 写到 agents respect existing Microsoft 365 permissions；GitHub Spaces 也说 follows the same role/visibility model。

这些表述背后是同一个判断：企业 Agent 的产品价值，不只是能不能把答案生成出来，而是能不能在组织边界内生成答案。

Local Agent 在企业里的新角色：受管数据面

如果只看到上面这一点，很容易得出另一个过头结论：企业都应该用 cloud agent，本地 agent 没价值。

这也不对。

Manus 的 My Computer 很有代表性。它原来完全活在 cloud sandbox 里，但后来仍然要进入用户桌面。原因不是 cloud sandbox 不好，而是很多真实工作就是发生在本地：项目文件、开发环境、桌面应用、本地算力、已登录浏览器、内网资源。

企业也是一样。开发者的 IDE 和 terminal 在本地，很多内网工具只能从公司网络访问，某些系统有 IP 白名单，某些文件不允许上传到 SaaS，某些操作必须在受控终端执行。

所以 local agent 不会消失。它会改变角色。

它不再应该是一个完全自治的个人外挂，而应该变成企业 Agent 系统里的受管数据面。它负责进入端点，云端负责下发策略。它可以读取本地，但要遵守本地目录范围。它可以调用工具，但工具来自企业 registry。它可以执行任务，但关键动作要审批。它可以产生结果，但 trace、日志、产物和 eval 要回传。

Cloud 是控制面，Local 是执行面之一。

控制面决定谁能做什么，能连什么，能读什么，结果如何评测，风险如何审计。执行面负责在具体环境里完成任务，包括云端浏览器、Slack bot、IDE 插件、本地 CLI、桌面 Agent、私有网络 runner。

Share skill 的重点，也要从“共享文件”升级成“共享能力供应链”

这个判断会改变 share skill 的 big picture。

如果 Agent 是个人工具，那么 share skill 很容易被理解成：我写了一个好用的 prompt 或 markdown，发给你，你放到本地目录里用。

这在早期很有价值，因为启动成本低。团队可以快速把经验沉淀下来，也能形成示范效应。

但公司级 skill sharing 不能停在这里。

Anthropic 对 Agent Skills 的定义是 instructions、scripts、resources 的组合，而且 Agent 可以动态加载。它还提醒用户只安装可信来源的 skill，低信任来源要审计。这其实已经说明 Skill 不只是文档，而是软件资产。

既然是软件资产，就不能只靠群文件传播。它需要 owner、版本、依赖、适用范围、测试样例、评测分数、变更记录、审批、回滚。

OpenAI 关于 skill eval 的文章也给了一个重要信号：真正成熟的 Skill，不应该只靠“感觉更好用”。它应该有 prompt、captured run、trace、artifacts、checks、score。也就是说，Skill 要能被回归测试。

这是个人经验和组织能力的分水岭。

个人经验可以靠体感。组织能力必须靠可复现证据。

企业 AI-native org 的三层结构

把这些放在一起，我更倾向于把企业内部 Agent 系统设计成三层。

第一层是 local agent。它负责个人实践、私有上下文、本地工具、桌面文件、IDE、终端、浏览器登录态和快速试验。它是创新的前线，也是 Skill 的生产入口。

第二层是团队 skill repo。这里放的不是散乱 prompt，而是版本化的 skills、scripts、references、examples、evals、metadata。每个 Skill 要有 owner，有适用场景，有验收标准，有变更记录，有失败案例。它应该像代码一样走 review，而不是像资料一样到处转发。

第三层是企业治理面。这里负责 registry、权限、MCP allowlist、审计、eval dashboard、发布、回滚、数据边界和生命周期管理。它解决的是组织级问题：哪些能力可以被发现，哪些工具可以被调用，哪些数据不能出界，哪些动作需要审批，哪些 skill 已经过期。

这三层都少不了。

只有 local agent，会形成个人英雄主义和治理盲区。只有 cloud agent，会丢失端点上下文和真实执行力。只有 skill 文件，会变成高级 prompt 仓库，很难形成稳定的组织能力。

真正要画的四条线

所以，我不太想把这个问题继续表述成“小龙虾这样的 local agent 是不是公司里的最佳形式”。这个问法容易让人陷入工具对工具的比较。

更好的问法是四条线。

第一，上下文线。哪些 context 属于个人工作现场，哪些属于组织系统？个人现场可以本地优先，组织系统应该云端优先。

第二，权限线。哪些权限来自用户本人，哪些权限来自 Agent 专属身份？用户能看，不代表 Agent 就应该自动用。企业需要 agent-specific scope。

第三，审计线。哪些动作必须留痕，哪些产物必须可回放，哪些失败必须进入 eval dataset？只要涉及组织资产，就不能只存在本机日志里。

第四，执行线。哪些任务需要云端异步执行，哪些任务必须在本地、内网或私有运行时执行？执行位置可以多样，但控制规则要统一。

这四条线比“云端 vs 本地”更重要。

我的结论

如果一个团队正在推进 share skill，我会建议不要一上来就追求大而全的企业平台，也不要停留在本地目录同步。

更务实的路径是：先让 local agent 成为个人工作流试验场。让真正高频使用 AI 的人，把自己的流程跑通，把有效方法沉淀成 Skill。然后把高频 Skill 提升到团队 repo，要求每个 Skill 至少包含说明、脚本、示例、适用边界和最小 eval。最后再接企业治理面，把可复用 Skill 纳入 registry，把 MCP server 纳入 allowlist，把运行 trace 和 eval 接起来，把版本发布和回滚建立起来。

这条路不性感，但更像组织能力。

AI-native org 不是每个人都装一个更强的 Agent。
AI-native org 是组织能把自己的隐性知识、判断标准、工具边界和执行流程，持续封装成 Agent 可调用、可验证、可审计、可演化的能力。

本地 Agent 是很好的起点。云端控制面是组织化的必经之路。真正的分水岭，不在云端和本地之间，而在个人效率和组织能力之间。

这个问题有点反直觉。过去二十年，互联网行业很大一部分信仰都建立在产品力上。好的体验，好的交互，清晰的路径，克制的界面，强大的生态。微信几乎就是这个时代最典型的答案。

但 AI 进来之后，事情开始变得别扭。很多原本由产品界面解决的问题，正在被模型直接吸走。用户不一定要理解页面结构，不一定要找入口，不一定要在复杂系统里点来点去。他只要说出意图，模型就可能直接给答案、调工具、跨系统执行。

所以我现在的判断是：AI 没有让产品力失效，但让产品力换了位置。过去的产品力主要是“人如何更舒服地使用软件”，现在的产品力越来越是“人和 agent 如何更可靠地完成任务”。

旧产品力为什么突然变薄了

传统互联网产品的界面，本质上是一种最大公约数。

一个按钮放在哪里，一个菜单怎么分层，一个流程拆成几步，一个首页展示哪些入口，背后解决的是同一个问题：让尽可能多的用户，在一个统一界面里，以较低成本完成任务。

PC 互联网和移动互联网时代，这个能力非常值钱。因为人必须通过界面理解系统。你做得更优雅，用户就更愿意留下来；你少一步操作，转化就可能提高；你让复杂功能变简单，就能赢一大批用户。

AI 把这个前提动摇了。

模型正在学习直接使用软件。它可以看屏幕，可以理解页面，可以点击，可以调用工具。它不一定需要产品团队为每个用户设计一条最优路径。只要系统能被它理解，很多界面复杂度就会被它穿过去。

这会让传统产品优势变薄。不是体验不重要，而是体验的上游变了。过去体验来自页面结构，现在体验可能来自模型理解力、工具编排、上下文质量、权限边界、失败回滚和执行审计。

用户感受到的还是“好不好用”。但真正决定好不好用的东西，已经不完全在前端。

技术型公司为什么前半程更顺手

AI 前半程更像一场底层能力赛。

模型能力、算力投入、上下文长度、工具调用、agent loop、训练和评测体系，都还在快速变化。今天不能稳定做的任务，几个月后可能突然能做了。今天必须绕很多产品设计的地方，下一代模型可能直接穿过去。

这就是为什么过去靠技术路径成功的公司，在 AI 前半程更容易进入状态。

它们不会天然排斥技术团队赛马。一个团队做长上下文，一个团队做 coding，一个团队做多模态，一个团队做推理效率，这在它们的组织语言里不是重复造轮子，而是在探索能力边界。

而产品型公司容易有另一个惯性：两个产品团队赛马可以，两个底层技术团队赛马就显得浪费。因为在传统互联网时代，技术更多是服务产品。产品想清楚，技术做出来，增长再推起来，这是很多公司的默认肌肉记忆。

AI 把这个顺序倒过来了。很多时候不是产品定义清楚后技术实现，而是模型能力突然上了一个台阶，产品定义才被迫重写。

在这种时候，技术力不是幕后能力，而是方向发生器。

运营型公司为什么更容易先拿到钱

相比产品解，运营解反而更容易在第一波 AI 中找到抓手。

原因很简单：运营链路里有大量高频、重复、规则明确、结果可量化的任务。客服等待时长、重复咨询率、单次服务成本、售后解决率、营销制作成本、审核处理量，这些指标非常适合 AI 进入后直接对账。

携程这类公司很典型。它需要处理大量咨询、改签、取消、售后和目的地信息。AI 不需要一开始就重塑整个旅游产品，只要接住一段重复链路，就能看到等待时长下降、人工压力下降、信息处理效率上升。

Klarna 的客服 AI 也是类似逻辑。无论你怎么打折看这些官方数据，有一点很清楚：AI 在客服、售后、销售支持和营销制作里，首先改变的是成本结构。

产品解更难，是因为它经常要回答“AI 放进来会不会破坏原来的品位”。运营解更直接，它只问“这件事能不能更快、更便宜、更少出错”。

新的产品力不是界面，而是执行系统

如果只说产品型公司不占优势，这个判断会过头。

更准确地说，传统产品力正在被拆开。界面美学、交互细节、视觉统一这些仍然重要，但它们不再足够。AI 时代新的产品力至少包括四件事。

第一，agent 可执行。你的产品能力不能只是人在页面上点得顺，也要能被 agent 读懂、调用、组合和完成。

第二，工作流可嵌入。用户不想再多开一个 AI 功能页。他希望 AI 进入自己原来的工作流，帮他处理原来就要处理的任务。

第三，结果可验证。AI 做错不是边角问题，而是生产系统必须面对的常态。产品必须设计过程证据、回滚机制、人工确认和权限边界。

第四，信任可建立。过去产品让人感觉“好用”，现在还要让人相信“它替我做事不会乱来”。

这四件事背后，已经不是单纯前端能力，而是产品、技术、运营、治理、数据和组织协作的混合体。

所以 AI 时代的产品力更难了。它不是没价值，而是不能再只由产品经理和设计师闭门打磨出来。它必须长在模型能力、业务语义、评测闭环和运营系统之上。

优势真正迁移到了哪里

过去很多公司把优势存放在三个地方。

第一，界面和用户心智。用户习惯你的入口，知道怎么用你的产品。

第二，流程和人力。大量运营、客服、审核、销售、交付团队支撑复杂业务。

第三，软件系统和数据。系统越厚，流程越深，迁移成本越高。

AI 之后，这三个地方都不会消失，但都会被重新定价。界面会被 agent 穿透一部分。流程会被自动化压缩一部分。软件系统会被模型和工具调用重新包装一部分。

真正变贵的，是更上游的东西：业务语义、私有上下文、判断标准、评测样本、责任边界、组织验收能力。

这和我一直说的“AI+工程，而非工程+AI”是一回事。如果只是给旧系统外挂 AI，就会停在功能增强。真正的变化是按大 Agent 重新设计系统：AI 负责理解、决策、生成和执行，工程负责数据、权限、稳定性、审计和验证。

在这个结构里，公司的核心优势不是“我们有多少功能”，而是“我们是否知道什么叫做对，并能让 agent 稳定做对”。

别急着给公司贴标签

这件事不能简单外推成技术公司必胜、产品公司必败、运营公司稳赚。

产品力会回潮。第一波 AI 竞争看技术和运营，但当底层模型逐步商品化，新的产品力会重新变重要。只是那时的产品力不再是传统 GUI，而是 agentic workflow 的体验、信任和分发。

运营 ROI 容易先出现，也容易先碰到天花板。客服自动化能降本，但如果过度追求效率，可能伤害客户满意度。少人不是胜利，单位价值提升才是胜利。

技术力也不是纯模型竞赛。算力和模型重要，但没有业务闭环、数据回流、评测体系和安全边界，技术能力很难变成稳定业务价值。

所以最后能走到后半程的公司，可能不是三类里某一类的纯粹代表，而是能完成重新组合的公司：底层有技术沉淀，中层有运营闭环，上层有新的产品表达。

真正的问题

如果把这个判断落回公司经营，我会问几个更具体的问题。

我们的核心 knowhow 是否已经机器可读？还是还藏在老员工经验、会议纪要和口头习惯里？

我们的高频任务有没有明确验收标准？还是只有“差不多”“看感觉”“让某某把关”？

我们的 AI 失败样本有没有回流？还是每次错了就人工改掉，下次继续错？

我们的业务语义有没有统一？同一个指标、同一个客户状态、同一个服务动作，跨团队是不是同一套解释？

我们的权限和责任边界是否清楚？agent 能做什么，不能做什么，错了谁负责，怎么追溯？

这些问题比“要不要做一个 AI 产品”更重要。因为它们决定的不是一个功能能不能上线，而是公司能不能把 AI 变成组织能力。

最后的判断

饭桌上的那个问题，最后可以这样回答。

AI 时代，产品型公司不是没有机会。但如果还把产品力理解成“做一个更优雅的界面”，机会会变少。技术型公司在前半程更占便宜，因为能力边界还在快速上移。运营型公司更容易先拿 ROI，因为它们有大量高频、可量化、可替代的流程。

但最终的分界线不是产品、技术、运营三种标签。

真正的分界线是：你的公司优势，到底还存放在人手、页面和流程里，还是已经迁移到了 agent 能理解、能执行、能被验证的系统里。

AI 不是让公司不需要能力。它只是把能力从“谁能做”迁移到了“谁知道什么叫做对，并能把对的标准管理起来”。

我自己一开始装 OpenClaw 的时候，也有类似体感。你要处理安装、部署、模型、API key、消息入口、skill、权限、成本、容器、网络。开发者会觉得运行链路不够干净，非开发者更惨，很多时候连问题出在哪一层都不知道。

但这件事真正有意思的地方也在这里：OpenClaw 确实火了，而且是在全球范围内火。它不只是一个工具被讨论，而是带动了很多 Cloud Agent 类型产品出圈。

所以问题不是“它到底是不是一坨屎”。问题是：为什么一个体验这么差的东西，仍然让那么多人愿意围着它折腾？

如果只看体验，确实解释不了

外部评测里对 OpenClaw 的体验吐槽并不少。GrowwStacks 在一篇实操评测里说，OpenClaw 的 setup process quite technical，需要 VPS、终端命令和基础编码概念。即便有所谓 one-click deploy，也仍然要配置 LLM、API key 和 agent architecture。

这不是小瑕疵，而是典型的早期开源 Agent 产品问题：它把本该由产品消化的复杂度，直接暴露给用户。

开发者面对的是工程复杂度：Docker 怎么跑、端口怎么绑、Telegram 怎么接、skill 为什么坏、模型调用为什么贵。非开发者面对的是认知复杂度：不是不会输命令，而是不知道这个系统到底由哪些层组成。

所以如果按传统消费级产品标准看，OpenClaw 不应该火。它不够顺滑，不够稳定，不够安全，也不够可解释。

但这恰恰说明：我们用错了尺子。

它真正卖的不是稳定，而是未来感

Frontier Learning Lab 有一句话抓住了关键：Most AI we use today is “chat-in-a-box.” OpenClaw represents the shift to Agentic AI. It doesn’t just talk; it does.

这就是 OpenClaw 的核心。它不是让用户多一个聊天窗口，而是让用户看到一个新物种：一个可以通过 Slack、Telegram、WhatsApp 这类消息入口常驻，可以访问本地文件，可以执行任务，可以完成后主动回报，甚至可以通过写代码补齐能力的 agent。

这件事对用户的冲击，不是“这个产品好不好用”，而是“原来 AI 可以这样存在”。

传统 AI 产品像一个问答柜台。你走过去，问一句，它答一句。OpenClaw 更像一个粗糙的数字员工。它笨、脏、不稳定，但它第一次坐到了你的工作流里，而不是停在网页里。

这也是为什么它能带动 Cloud Agent 类型产品出圈。用户真正想要的不是“自托管”这三个字，而是一个 24 小时在线、可以从消息入口调度、能接工具、能持续执行并回报的 agent。OpenClaw 给了这个想象力，Cloud Agent 负责把部署、稳定性和安全成本往平台侧搬。

体验越差，教程生态越旺

这听起来反直觉，但在开源工具传播里很常见。

如果一个工具安装极其顺滑，教程空间反而有限。OpenClaw 这种工具不同：安装复杂会产生新手教程，部署复杂会产生一键安装器，运维复杂会产生代部署服务，成本复杂会产生优化指南，安全复杂会产生警告文章。

换句话说，它的粗糙体验没有只造成流失，也制造了内容供给。

这不代表体验差是好事。长期看，体验差会限制留存和商业化。但在爆发早期，粗糙体验会让社区产生大量“帮你搞定它”的二次创作。每一篇“别踩坑教程”，本质上都在替 OpenClaw 做传播。

这也是为什么很多早期开源明星项目，往往不是先像消费级 App 一样顺滑，而是先像乐高散件一样有可玩性。它吸引的第一批人不是普通用户，而是 builder、折腾者、教程作者、集成商、安全研究员和想抢窗口期的人。

安全争议不是旁枝，而是主干的影子

OpenClaw 的安全争议很严重。Immersive Labs 提到 one-click RCE、CVE-2026-25253、ClawHub 恶意 skills、暴露实例等问题。Frontier Learning Lab 则引用 Simon Willison 的 lethal trifecta：访问私有数据、访问互联网、能够采取行动。

这个框架非常适合理解 OpenClaw。

一个只能聊天的 AI，安全风险有限。一个能读邮件、改文件、跑命令、发消息、连外部服务的 AI，风险立刻变成系统级风险。

但也正因为它拿到了这些权限，它才像一个真正的 agent。

这就是 OpenClaw 的悖论：它危险，是因为它有用。它被安全研究员反复警告，反而说明它触碰到了真实生产力边界。一个玩具不会引发这种级别的安全讨论，一个能接管工作流的工具才会。

所以我不认为安全争议只是负面公关。它更像一次行业教育：当 AI 从“回答”走向“行动”，治理问题会从提示词风险升级为权限、供应链、审计、隔离和组织管控问题。

别迷信产品完成度，要看范式完成度

很多产品分析会犯一个错误：用成熟产品的尺子衡量范式切换期的样机。

成熟产品当然要看上手成本、留存、稳定性、客服、权限管理、企业治理。但范式样机最重要的问题不是这些，而是：它有没有让人看到一个以前看不到的工作方式。

OpenClaw 做到了。

它让人看到：AI 不一定是一个网页，不一定是 IDE 插件，不一定是一次性对话。它可以变成一个常驻的执行体，躲在消息入口后面，连接文件、工具、网页、API 和其他 agent。

这就够了。早期爆发不需要 100 分体验，有时候 30 分体验加 90 分想象力，就足以让一个项目冲出圈。

这不意味着 OpenClaw 值得普通人现在就装。相反，对多数非技术用户，我会建议先看，不要把真实数据和关键账号交给它。对企业，更不该让这种工具以 Shadow AI 的方式进入生产环境。

但如果看趋势，它值得研究。因为它暴露了下一代 Agent 产品的五个真实战场。

第一，低摩擦部署。用户想要 agent 常驻，不想先学 DevOps。

第二，权限隔离。Agent 越有用，越要有边界。

第三，执行审计。替人行动之后，过程证据比最终结果更重要。

第四，成本控制。Agent 会自己循环、调用、试错，费用不是线性增长。

第五，生态治理。Skill 市场不是插件市场那么简单，它更像一个能直接接触用户系统权限的软件供应链。

真正的信号

我更愿意把 OpenClaw 看成一台冒烟的蒸汽机。

它吵、脏、危险、难维护。站在马车时代最成熟的审美里，它当然很差。但它暴露出来的不是一个工具的小问题，而是一类新机器的大方向。

这对做 AI 产品的人有一个提醒：不要只问用户体验是不是顺滑，还要问用户愿不愿意为了某个新能力忍受摩擦。

如果用户愿意忍受很多摩擦，说明那里有强需求。后来的产品机会，就是把这部分摩擦系统性吃掉。

OpenClaw 的奇迹不在于它体验差还能火。真正的奇迹是：它差成这样，用户还是愿意围着它折腾。

这才是信号。

最近一两个月，我的体感变差了，尤其是 PC 端。社区里也有人有类似反馈。与此同时，一些免费的、开源的、或者更轻的语音输入方案开始变好。这件事让我想到一个更大的问题：AI 时代产品方法变了，但 less is more 的逻辑没有变，甚至变得更重要。

我不想把这篇写成对 Typeless 的吐槽。公开资料里也不能证明 Typeless 最近两个月整体变差，或者快捷键变更引发了大面积投诉。能确认的是另一件事：Typeless 官方已经把产品从语音输入扩展到了 Translate、Ask anything、选中文本问答和编辑；官方 FAQ 也写明，核心 voice-to-action 功能联网效果最佳，离线能力仍在开发。

这就够了。因为真正值得讨论的不是 Typeless 某个版本好不好，而是一个原本靠“轻”打动用户的 AI 产品，为什么会很自然地走向“重”。

用户买的不是功能，是一条不用想的路径

一个语音输入产品最打动人的时刻，不是它能不能翻译，也不是它能不能问答，而是你在任意输入框里按下一个键，说完一段话，然后得到一段基本可提交的文字。

Typeless 在中文社区里仍然有不少正面评价。V2EX 上有重度用户说它“除了贵几乎没有什么大毛病”，还说长一点的输入直接说出来就能达到可提交程度。这个评价很关键。用户愿意为它付费，买的不是“语音识别”四个字，而是“我不用再改太多”。

这类产品的价值不在功能表里，而在一条主路径里：启动、说话、识别、整理、落入输入框。只要这条路径足够稳，用户会原谅它贵一点、少一点、丑一点。反过来，只要这条路径开始不稳，再多的附加能力都会变成噪音。

输入法和普通应用不一样。普通 AI 应用慢一下，用户可能等一等。输入法慢一下，用户会烦。因为输入不是一个任务，输入是所有任务的入口。越底层的工具，越不应该抢戏。

传统软件的功能膨胀是 UI 债，AI 产品的是智能债

传统软件加功能，通常多一个按钮、多一层菜单、多一页配置。用户付出的成本是看、找、点、记。NN/g 把这种成本叫 interaction cost，包括阅读、查找、点击、等待、注意力切换和记忆负担。

AI 产品不一样。它每加一个功能，往往不是多一个按钮这么简单，而是多一段 system prompt、多一个工具描述、多一种意图识别、多一类上下文、多一条失败路径。

传统输入法增加一个皮肤功能，核心输入路径未必受影响。AI 输入法增加“随口问”和“随时翻译”，系统就必须先判断你到底是在输入、翻译、编辑，还是问答。判断错了，体验就错了。

这就是我说的智能债。UI 债让用户不爽，智能债会让系统变笨。它的表现不一定是崩溃，而是更隐蔽：输出变慢、误解意图、格式不稳、需要更多人工修正、偶尔不像以前那么懂你。用户未必知道背后的技术原因，只会说一句：没有以前好用了。

这也是为什么 AI 产品更要克制。复杂度不再只影响用户心智，也会进入模型上下文、工具选择、延迟和基础设施。

免费平替变好，是对付费产品的边界测试

现在中文社区里已经有 TypeMore、OpenTypeless 这类开源或免费替代品，卖点集中在免费、本地、BYOK、离线和可控。它们一开始未必全方位超过 Typeless，但它们会持续逼近核心动作：把语音变成可用文本。

这对 Typeless 这类产品来说，不是简单的价格战，而是边界测试。

如果免费方案能把核心输入做到 70 分，付费产品就必须证明自己为什么值得。答案不能是“我还有翻译”“我还能问答”“我还有团队功能”。这些都可以有，但它们不能替代一个更基本的问题：我是否在最常用的那条路径上，比别人更快、更稳、更少打扰？

AI 产品的竞争最后会回到结果确定性。模型能力越来越普及后，功能数量不是护城河，能不能稳定完成一个真实任务才是护城河。

微信不是功能少，而是主路径少

很多人讲 less is more，容易讲成“少做功能”。这个理解太浅。微信就是最好的反例。

微信功能并不少。支付、公众号、小程序、视频号、企业微信生态，复杂到几乎能装下一个数字社会。但张小龙真正厉害的地方，不是永远少做，而是尽量不让复杂能力破坏聊天主路径。

2019 年微信公开课里，张小龙说微信的原动力之一是“坚持做一个好的、与时俱进的工具”。a16z 对他的产品原则有一句整理我很认同：作为工具，微信必须帮助用户在最短时间内获得最有用的信息。

所以微信案例的启发不是“功能越少越好”，而是“主路径越少越好”。复杂能力可以在后面，但入口要克制，心智要稳定，高频动作不能被低频想象力打断。

这正是很多 AI 产品容易忘掉的事情。团队看到模型能力强了，就会自然想把更多场景塞进来。可用户最初爱上的，可能只是那一个不用想的动作。

很多团队不是因为不努力失败，而是因为太努力

功能膨胀通常不是懒惰造成的，而是努力造成的。

用户提需求，团队想满足；竞品加功能，团队想追上；融资后要讲增长，团队想扩场景；付费用户要更多价值，团队想证明订阅合理。每一步都合理，最后产品却变得不合理。

这就是产品管理最难的地方：大多数失败不是团队不努力，而是团队把努力用在了增加可能性上，而不是提高确定性上。

对 AI 产品尤其如此。早期用户被打动，往往是因为一个能力突破了阈值。识别准了，整理好了，速度快了，路径短了。这个时候最重要的不是马上扩到十个场景，而是把这个突破打磨到别人追不上。

一旦团队开始用新功能替代核心体验打磨，就会出现一个危险信号：用户看到产品更强了，但感觉产品更差了。强的是功能表，差的是日常主路径。

我会用四条原则看 AI 产品

第一，守住一句话定位。用户应该能一句话说清你解决什么问题。如果一句话里出现三个动词，产品边界已经开始危险。

第二，保护最高频路径。任何新功能都不能增加高频动作的认知成本。输入类产品尤其如此，因为输入是所有任务的入口。

第三，给上下文设预算。AI 产品不是把信息塞得越多越好，而是越准越好。上下文预算、工具预算、延迟预算，都应该像财务预算一样被管理。

第四，用可靠性约束功能扩张。每一次功能扩张，都应该绑定识别准确率、延迟、失败率、用户修正率，而不是只看功能使用次数。

回到那个快捷键

Typeless 最早让我惊艳的地方，不是它野心大，而是它把一个老问题做轻了：人在电脑上说话，文字可以比较自然、比较干净地落到输入框里。

这个价值足够大。大到我愿意第一次认真考虑，自己是不是应该为一个“输入法”付年费。

但越是这种底层工具，越要克制。用户不是来探索功能的，用户是来继续做自己原来的事。工具越靠近底层，越不应该抢戏。

如果让我把这次反思压成一句话，就是：AI 产品未来的护城河，不是更多功能，而是更少但更稳的主路径。

谁能更稳定地完成一个真实任务，谁就能留下来。谁把最初打动用户的点稀释掉，谁就会被更便宜、更简单、够用的产品从下面追上。

我的判断就一句话：AI 时代人的稀缺能力，不是亲手完成每一步，而是把工作改造成 AI 可执行、人类可验收、组织可追责的任务。

为什么"乙方"这个比喻用得上

把 AI 说成工具，说的是"谁用谁知道"；说成员工，说的是"要管要带要考核"。这两种说法都不太贴。AI 更像一个高吞吐、低摩擦、可反复返工的乙方。

乙方的第一个特征，是必须拿到清晰 brief 才能干活。GitHub 在讲 Copilot coding agent 的工程实践时反复强调的一件事是：生成代码是直接了当的，审查代码、确保它符合标准、做了你想做的事、能被你的团队维护，仍然需要人的判断。OpenAI 推 AGENTS.md 的背后逻辑也一样：给 AI 一份可读的项目工作手册，而不是指望它从对话里猜出你的规范。这不是 prompt 工程的花活，这是甲方给乙方的施工方案。

乙方的第二个特征，是交付要过验收，不能自证完成。GitHub Copilot coding agent 默认的产品形态是"做完 tag 你 review，CI/CD 需要人工批准"。OpenAI 在 Codex 的介绍里也写得很明白：用户仍然必须在集成和执行前手动审查和验证所有 agent 生成的代码。这些都不是谨慎派的说教，而是真实产品里默认打开的保护机制。

乙方的第三个特征，是可以给更多自主权，但关键控制权必须留在甲方。Anthropic 讲有效 agent 的时候把话说得很清楚：需要清晰的成功标准、反馈循环、以及有意义的人类监督。这不是为了让人多一道章，而是因为一旦 agent 真的有权限敲键盘、改文件、发请求、调 API，任何模糊的授权都会在某个角落被滥用。

生产力收益是真的，但有三重打折

外部数据里最被引用的一条，是 St. Louis Fed 的估算：生成式 AI 用户平均每周节省 2.2 小时，折算约 5.4% 的工作时长。Harvard 和 BCG 对咨询顾问的实验更乐观：能力边界内的任务，效率提升 25%，完成量多 12%，质量高出 40% 以上。这些数字是真的。

但它们有三重需要打折的地方。

第一重，这些多是自报数据。"用得爽"和"真的节省"在问卷里分不开，把 2.2 小时理解成每周凭空多出 2.2 小时新产出，是过度解读。

第二重，能力边界外的使用会反向扣分。同一项 Harvard / BCG 研究还有另一个结论：当任务超出 AI 能力边界时，使用 AI 的顾问正确率反而下降 19%。Harvard Crimson 对此有句话很尖锐：更快地得到错误答案，不算生产力。

第三重，对经验丰富的知识工作者，收益甚至可能是负的。METR 在 2025 年做过一次很严谨的 RCT，针对经验丰富的开源开发者在真实代码任务上做了对照实验。反直觉的结论是：在 20 分钟到 4 小时的真实 coding 任务上，使用 AI 的开发者更慢。不是工具不好，而是熟练者知道自己怎么写代码，多出来的是"审查加纠偏加返工"的开销。

三重折扣叠在一起，比较诚实的总结是：AI 的生产力收益真实存在，但会被任务类型 × 使用者经验 × 验收门槛三个维度调制。哪一维错位，账就可能从正变负。

比喻不要用过头，要补三个原生批判

"AI 是乙方"是一个有用的起点，不是终点。把它用过头，会漏掉三个在传统甲乙方关系里不存在的问题。

第一个问题：AI 乙方的能力会持续漂移。传统乙方能力相对稳定，甲方几次合作之后可以把验收流程固化下来。AI 乙方不是这样。基础模型每几个月一次跃迁，同样一份 AGENTS.md，半年前跑不动的任务今天可能一把过；同样一份 review 清单，上个月抓得住的 bug 这个月可能已经不会再出现。甲方能力的本质不是"建立一套 SOP"，而是持续校准：每隔一段时间重新评估哪些任务可以放权、哪些必须收回、哪些模板需要重写。这种动态校准是传统甲方管理里没有的职责。

第二个问题：验收能力的自我循环困境。传统认知里，能判断代码好坏的人是写过很多代码的人，能判断方案好坏的人是做过很多方案的人。如果未来大部分执行被 AI 接走，新一代从业者没有足够的执行经验去建立判断力，几年之后谁来做验收？这个循环从个人层面延伸到组织层面：一家公司如果过早把所有"动手活"交给 AI，它在一段时间内看起来效率很高，但当下一次模型能力波动、任务超出边界、或出现新型业务场景时，它可能已经没有足够多的"能判断对错"的人了。

第三个问题：谁来验收验收者？如果甲方能力是判断乙方做得对不对，那谁来判断甲方做得对不对？当人做验收时，他的判断由同伴、上级、客户的反馈来校准；当验收者也开始借助 AI 辅助时（比如用另一个模型 review 前一个模型的产出），验收本身就进入了 AI 辅助的链条。整个体系需要一个新的"元锚点"去定义什么叫做对。目前没有一个行业有清晰答案。

我没有全套方案。但我觉得这三个问题必须显式摆在桌面上，而不是被一句"AI 像乙方"顺滑地盖过去。

甲方新能力是四件事，不是"会写 prompt"

收益和风险说清楚之后，落回到"一个人、一个团队、一个管理者到底要做什么"。甲方新能力不是"更会写 prompt"，而是四件事。

第一件：把目标讲清楚。不是把需求写成多长的文档，而是把目标讲成可被执行的形状。一个可以交给 AI 的目标应该能回答三个问题：产出物是什么、约束条件是什么、输入从哪里来。OpenAI 推 AGENTS.md 的背后逻辑就是这个：给 AI 一本可读的工作手册，而不是期望它从对话里猜出项目规范。

第二件：把验收标准写在前面。大部分 AI 项目翻车的原因，不是 AI 做错了，而是甲方没讲清楚什么叫做对。验收标准的简单模板是：用什么方式验证、谁来验证、失败时怎么处理。代码场景里这套标准天然存在（单元测试、集成测试、PR review）；在写作、分析、决策这些场景里，这套标准需要被显式建出来。

第三件：看懂过程证据。AI 说"已完成"不算完成。过程证据包括：它调用了哪些工具，读了哪些文件，写了哪些内容，跳过了哪些步骤。GitHub 的 Mission Control 有一句我很同意的话：当检查失败时，不要简单重启 agent，要调查为什么失败。甲方看过程证据的能力，是防止"表演式交付"的唯一办法。

第四件：为结果负责。OpenAI 在讲 AI-native engineering team 时把话说得最直白：工程师最终为部署到生产环境的代码负责。这里不需要太多解释。把任务外包给 AI 不改变责任归属，只改变执行方式。如果一位产品经理说"这个需求是 AI 写的，不准的地方不怪我"，这家公司的验收体系已经塌了一半。

这四件事不对称：讲清楚目标偏向个人技能，写验收标准偏向团队机制，看懂过程证据偏向工具链和可观测性，为结果负责偏向组织文化。任何一件没做到，剩下三件的价值都会大打折扣。

对三类人的不同含义

如果你是个人从业者，真正应该练的不是"让 AI 写得更多"，而是四件事里的前两件：把目标讲清楚、把验收标准写在前面。大多数人用 AI 的瓶颈不是模型不够强，而是自己没想清楚要什么。一个简单的自检：每次使用 AI 前，用 30 秒写下"这次我希望它产出什么、我怎么判断它做到了"。写不出来，说明任务本身还没定义好，让 AI 先做只会把不清晰的需求放大。

如果你是团队 leader 或项目 owner，真正该投入的不是"更强的工具"，而是任务模板、验收标准、过程可观测性。McKinsey 的 State of AI 调研指出，高绩效组织比普通组织更可能"根本性重新设计个人工作流"。重新设计工作流听起来抽象，落到具体就是：哪些任务可以交给 AI、输入从哪来、输出要达到什么标准、谁来 review、失败如何升级。这些不是 AI 项目，是组织工程。

如果你是管理者，值钱的管理工作正在被重新定义。AI 不会自动消灭管理工作，但会压缩低价值的管理工作：进度追踪、信息汇总、会议纪要、催办、格式校对，这些会被逐步吸收。真正留给管理者的价值点会往两端集中：一端是定义什么叫做对（验收标准、质量基线、风险边界），一端是为组织判断力的长期再生产负责（有没有培养出能独立判断的人，有没有机制持续校准能力边界）。把管理者的 KPI 从"推动多少事发生"转向"让多少事被判断得对"，是这一阶段组织设计的关键题。

回到开头

回到开头那个场景。真正困扰人的不是 AI 做得快，而是判断它做得对。这件事过去也存在，只是过去的甲方通常自己是乙方出身，自己干过几年，验收时的肌肉记忆已经内化，所以"多一道审核"看起来不费力。现在 AI 把执行的成本压到很低，同时把执行的数量和速度拉到很高。当产出像潮水一样涌过来，"验收"就不再是工作流程里的一个步骤，而变成工作本身。

这个时候，"当好甲方"就不再是比喻，它是一组具体能力：讲清楚需求、写清楚验收、看懂过程证据、为结果负责。这四项能力过去分散在不同角色里（产品、架构师、测试、leader），现在会被压到每一个严肃使用 AI 的从业者身上。

如果让我从这轮调研里挑一个最值得带走的直觉，就是这句话：AI 时代最贵的能力，是知道什么叫做对了，并能在一个合理成本内把这件事验证到位。

本文的局限性

第一，引用的多数数据来自 2024 到 2025 年的研究。2026 年上半年以来的模型跃迁在这些研究基线里还没有充分体现，METR 那种"经验开发者用 AI 反而变慢"的结论是否在新一代模型上仍然成立，我没有把握。

第二，本文的甲乙方比喻天然偏向知识工作，尤其是软件工程。coding agent 是整个调研里证据链最清晰的一块，但它不代表所有知识工作。在销售、教学、客服、设计这些场景里，验收标准的结构完全不同，这套四件事框架需要重新具体化。

第三，关于"验收能力自我循环"和"元验收问题"，本文提出的更多是判断和警告，不是方案。如果未来一两年这个领域出现真正有效的组织实践，文中的结论应当被修订。

那时候我的判断很简单：Figma 的优势在设计生产，但 AI 正在把生产这件事从画布里抽走。Pencil 把设计搬进 IDE，让设计文件和代码共享 repo、branch、commit、merge，这看上去像是一个更接近 AI Coding 时代的设计工具。沿着这个逻辑看，Figma 的问题不是没有 AI，而是它还站在画布中心思考 AI。

这个判断没有错，但只说对了一半。

最近用 Claude Design，我的判断又变了一次。Claude Design 当然也能生成设计、原型、slide、one-pager，也能导出 PDF、PPTX、HTML，甚至能把设计 handoff 给 Claude Code。但如果只把它看成一个设计工具，就错过了它真正重要的地方。

Claude Design 不是 Anthropic 跨界做了一个 Figma 竞品。它更像是 Anthropic 把 Claude Code 那套工作架构，换了一个介质，搬到了视觉设计里。

这件事比设计工具竞争本身重要得多。

我看到的不是功能，是架构

Claude Design 最让我停下来的地方，不是它生成出来的页面有多好看，而是它的 onboarding。

它不是先问你喜欢什么颜色、什么字体、什么圆角，也不是让你从一个空白画布开始拖组件。它先问：有没有 codebase 可以读？有没有一份能代表你们品牌的 PPT、PDF 或设计文件？然后它从这些材料里抽取 color palette、typography、components、layout patterns，生成一套团队设计系统。之后每个项目都会默认带着这套系统往前走。

这看起来是在解决品牌一致性，实际上是在解决 agent 的工作条件。

一个人类设计师之所以能持续做出"像这个公司"的东西，不是因为他每次都重新思考品牌色，而是因为他脑子里已经沉淀了一套长期有效的默认判断：这个品牌通常用什么节奏，什么视觉语气，什么组件习惯，什么布局密度，什么东西看起来"不像我们"。

Claude Design 做的第一件事，就是把这些默认判断变成 agent 每次工作时都会带上的持久上下文。

这和 Claude Code 里的 CLAUDE.md 是同一件事。Claude Code 文档里说得很清楚：CLAUDE.md 是放在项目里的 markdown 文件，Claude Code 会在每次 session 开始时读取，用来承载 coding standards、architecture decisions、preferred libraries、review checklists 等长期指令。它不是一个 prompt 小技巧，而是让 agent 不必每次从零理解项目的"项目记忆"。

换到设计领域，这份记忆不再是代码规范，而是品牌资产、组件习惯、版式语言和视觉边界。

所以 Claude Design 的关键不是"能不能画图"，而是它先问了一个更底层的问题：

一个设计 agent 要想稳定工作，它每次启动时必须知道什么？

这是我认为它和 Claude Code 完全同构的地方。

真正的统一架构：不是工具，而是工作环境

我现在越来越觉得，未来垂直岗位和 AI 结合的最佳实践，不是"给这个岗位做一个 AI 工具"，而是给这个岗位搭一套 agent 可以稳定工作的环境。

这套工作环境至少有五层。

第一层是持久上下文。它回答的是：这个岗位里有哪些东西不应该每次重新解释？对工程师来说，是代码结构、架构约定、测试命令、review 标准。对设计师来说，是品牌系统、组件库、设计原则。对 PM 来说，是核心用户是谁、我们做什么、不做什么、哪些取舍原则高于短期需求。对法务来说，可能是合同模板、风险偏好、审批红线。对投研来说，可能是投资框架、历史案例、估值口径和禁区。

第二层是任务上下文。它回答的是：这一次具体要做什么？用户是谁，目标是什么，输入材料有哪些，约束是什么，失败模式是什么，参考样例是什么。Claude Design 里的 brief、上传文档、网页抓取、inline comment，都是在补这一层。Claude Code 里让它先读 repo、看 issue、跑测试、理解 error log，也是这一层。

第三层是专业技能。它回答的是：这个岗位有哪些可复用的动作流程？Anthropic 对 Agent Skills 的定义很接近这一点：Skill 是一组 instructions、scripts、resources，Claude 可以在相关任务里动态加载；它的核心原则是 progressive disclosure，先只加载 name 和 description，真正需要时再读取完整 SKILL.md，必要时再读取更多文件或运行脚本。

这句话翻译成岗位语言就是：不要把所有专业知识都塞进一次 prompt，而要把可复用的专业流程做成 agent 能按需调用的工作手册。

第四层是可执行介质。工程师的介质是 repo、terminal、IDE、git。设计师的介质是 canvas、HTML、PPT、Canva、Figma、Claude Code handoff。PM 的介质不是 PRD，而是 metrics、用户反馈、原型、issue、launch room、evals。很多人还在问"AI 能不能替我写产物"，但更重要的问题是：AI 到底能在哪里行动？它能读什么，改什么，运行什么，提交什么，交付到哪里？

第五层是评估闭环。没有 evals 的 agent workflow，本质上还是一次性生成。真正可规模化的 agent workflow，一定要有某种"成功长什么样"的可执行定义。工程里是 test、lint、CI、review。设计里可能是品牌一致性、可用性、状态覆盖、视觉偏差检查。PM 里就是 Cat Wu 说的 evals：不需要几百个，10 个好的 evals 就能让团队量化目标、量化进展、看到缺口。

把这五层合在一起，你会发现 Claude Design 和 Claude Code 不是两个产品，而是同一套东西在两个介质里的实例化。

Claude Code 是代码岗位的 agent 工作环境。

Claude Design 是设计岗位的 agent 工作环境。

未来每个岗位都会长出自己的 agent 工作环境。

这也是 Cat Wu 那段访谈真正重要的地方

我原来读 Cat Wu 那篇访谈，最容易被那句"真正值钱的是判断该写什么"吸引。它当然很对。当代码越来越便宜，判断做什么会更值钱。

但现在把 Claude Design 放在一起看，我觉得更重要的不是这句话，而是她描述的 Anthropic 内部工作方式。

她说 AI 原生产品里，PM 的重点不应该是维护多季度 roadmap，而是想办法让一个 idea 以最快速度到用户手里。她提到团队会做严格的 weekly metrics readout，让每个人理解业务；会有一份团队原则，写清楚核心用户是谁、为什么是他们、愿意牺牲什么；会用 research preview 降低上线承诺成本；工程、marketing、docs、DevRel 之间有非常紧的 launch room，让一个功能准备好后第二天就能推出去。

这不是普通意义上的"PM 用 AI 提高效率"。

这是把 PM 这条链路本身重新架构了。

过去 PM 的工作经常被理解成写 PRD、拉会、对齐路线图、协调资源、推动上线。AI 时代，如果工程速度被 Claude Code 大幅加速，PM 的瓶颈就不再是"怎么把需求写清楚"，而是"怎么让团队更快地从信号走到判断，从判断走到行动，从行动走到验证"。

这条链路可以写成：

信号 → 判断 → 行动 → 验证。

信号来自 metrics readout、核心用户反馈、dogfooding、模型边界测试。

判断来自团队原则、产品品味、对当下模型能力的理解。

行动由 Claude Code、Cowork、内部工具和轻量 launch process 放大。

验证由 evals、用户反馈、research preview 和下一轮迭代完成。

这和 Claude Design 做的事情完全对应。设计师的链路是：

需求理解 → 方向探索 → 产物生成 → 视觉验证 → 工程 handoff。

Claude Design 加速的不是"画一个页面"这一小段，而是把整条链路变成 agent 可以参与、可以沉淀、可以复用、可以 handoff 的系统。

所以 Cat Wu 的访谈和 Claude Design 其实在讲同一件事：AI 不是把某个岗位里的一个动作变快，而是把整个岗位链路变成一个更短的闭环。

真正被替代的不是岗位，而是没为 agent 搭好工作环境的岗位

这也是我觉得这轮变化比"设计师会不会被替代"大得多的原因。

很多关于 AI 的讨论还停留在岗位名上：设计师会不会被替代，PM 会不会被替代，工程师会不会被替代，分析师会不会被替代。

但岗位名其实是一个很粗糙的单位。AI 真正冲击的不是岗位名，而是岗位里那些没有被结构化、没有被验证、没有被自动化、没有被沉淀的工作链条。

一个设计师如果只会把需求翻译成静态稿，那部分工作会迅速被 Claude Design 这样的工具吞掉。但如果他能把品牌判断沉淀成设计系统，把常见视觉问题写成评估规则，把探索路径变成可复用 skill，把 handoff 变成能直接进入工程实现的包，他就不是在和 AI 抢"画图"这件事，而是在设计整个设计 agent 的工作环境。

一个 PM 如果只会写 PRD，再把 PRD 扔给工程师，那部分工作也会越来越薄。但如果他能把用户信号接进来，把团队原则写清楚，把判断标准变成上下文，把模糊问题拆成可测试的 evals，把从 idea 到用户的路径压到最短，他做的就不是传统 PM，而是产品链路的加速器。

一个运营、法务、财务、HR、投研人员也是一样。

未来每个岗位都要回答同一个问题：

你能不能把自己岗位里的隐性经验，改造成 agent 可以读取、调用、执行、验证的系统？

能回答这个问题的人，不会被简单替代。回答不了的人，不一定被 AI 替代，但会被那些已经把 agent 工作环境搭好的同行替代。

所以，Claude Design 的意义不在设计

我现在回头看 Claude Design，觉得它最重要的地方甚至不在设计。

它演示了一件更通用的事：当模型能力足够强，产品的核心不再是给用户一个更强的编辑器，而是给 agent 一个更好的工作环境。

这个工作环境里，要有长期记忆，要有本次任务的上下文，要有可调用的专业技能，要有能行动的介质，要有评估和 handoff 的闭环。

Anthropic 在 context engineering 那篇文章里讲过一个很关键的观点：agent 的关键不只是写好 prompt，而是持续管理进入模型上下文的所有信息，包括 system instructions、tools、MCP、external data、message history 等。上下文本身是有限资源，应该用最小但高信号的信息集，最大化模型产生目标行为的概率。

这句话放到岗位上看，几乎就是下一代职业方法论。

过去一个职业高手的优势，藏在脑子里、经验里、习惯里、判断里。新人跟着他干几年，才能慢慢学会什么该看、什么不用看、什么是红线、什么是好、什么是差、什么时候该推进、什么时候该停。

现在这些东西第一次可以被写进上下文、skills、tools、evals 和 workflow 里。它们不再只是人的经验，而会逐渐变成组织的可执行资产。

Claude Design 把这件事在设计领域演示了一遍。

Claude Code 已经在工程领域演示了一遍。

Cat Wu 描述的 Anthropic PM 工作方式，又在产品管理领域演示了一遍。

它们共同指向同一个结论：

AI 原生岗位的核心，不是人更会使用 AI，而是岗位本身被重新组织成一套 agent 可运行的架构。

最后

所以这次我改的不是对 Pencil 的判断。

Pencil 也好，Stitch 也好，Figma 也好，它们仍然是重要的设计工具。但 Claude Design 让我看到的不是一个新工具，而是一种更底层的迁移：同一套 Claude Code 架构，正在被套到代码之外的每一种专业介质上。

今天是设计。

明天是 PM、运营、销售、法务、财务、投研、客服、HR。

每个岗位最后都会被问同一个问题：你的 CLAUDE.md 是什么？你的 skills 是什么？你的工具接口在哪里？你的 evals 怎么写？你的 handoff 怎么闭环？你的经验能不能从个人直觉，变成 agent 可以工作的环境？

这才是 Claude Design 真正值得看的地方。

它不是设计工具的一次更新。

它是所有垂直岗位 agent 化的一次公开样板。

这句话挺狠，但不是没有道理。

它真正想说的是：一个 Skill 越好，越容易把原来靠人脑、课程、咨询和实施服务传递的知识压缩成一个文件。别人装上以后，AI 就能直接做。原来的价值链被它打掉了，但这个 Skill 本身又因为可复制、可传播、可改写，很难继承那部分收入。

我读完之后的感觉是：方向有点对，但还没打到最深处。

它说清楚了“Skill 作为文件为什么不值钱”，但没有继续追问：当 Skill 文件不值钱之后，什么东西开始值钱？

Skill 的问题，不是没有价值，而是价值不在它身上

Anthropic 对 Agent Skills 的定义很清楚：它是一个包含 instructions、scripts、resources 的文件夹，Claude 会在相关任务里自动加载。后来 Anthropic 还把它做成 open standard，强调跨平台可迁移。

这本来是好事。标准越开放，生态越容易长起来。

但商业上也会带来一个结果：单个 Skill 很难长期保持稀缺。你今天写了一个 Excel 财务模型 Skill，明天社区里可能出现十个类似版本，后天模型平台可能把高频能力直接内置。

所以，Skill 不是没有价值。它的价值只是很难停留在“这个文件只有我有”这件事上。

这和开源世界很像。代码可以免费，但围绕代码的稳定发行版、企业支持、安全审计、集成服务、责任主体，仍然可以收费。Skill 也类似。Skill 本体会变便宜，但围绕 Skill 的运行系统，反而可能开始变贵。

Excel 课程和 Skill，不是同一种价值

原文里有个例子，说过去有人花钱学 Excel 财务模型，现在一个 Skill 就能让 AI 做出来，所以原来的课程和咨询价值会被压缩。

这个例子很形象，但我觉得还可以再拆一层。

一个人花 1000 块学 Excel，并不只是买一段知识。他真正买的是长期能力。学会之后，未来几年都能靠这个能力提高效率、少犯错、升职加薪。课程只是入口，真正的付费理由是未来收益。

Skill 不一样。你拿到一个 Skill，很多时候不是你本人学会了什么，而是 AI 暂时获得了某种执行能力。这个能力不一定属于你，也不一定稳定存在。下一代模型更强了，可能就不需要这个 Skill 了。平台把它内置了，也不需要了。

所以 Skill 的价值衡量方式要换。

不是问：这个 Skill 帮我做了一件事，值多少钱。
而是问：这个 Skill 能不能持续嵌入我的工作系统，并且在模型变化、业务变化、数据变化时继续产生复利。

如果不能，它就是一个模板。如果能，它就不只是 Skill，而是运行系统的一部分。

真正的分水岭，是运行时在谁手里

原文还有一个判断：Skill 作者拿不到数据飞轮。用户在 Claude 或 ChatGPT 里运行 Skill，真实任务、失败案例、业务数据、修改反馈都进了模型平台，作者什么都拿不到。

这在很多消费级场景里是对的。

但这不是 Skill 天生命运，而是运行时归属决定的结果。谁控制运行时，谁控制数据飞轮。

如果 Skill 只是一个文件，执行发生在模型公司的环境里，飞轮当然归模型公司。如果企业通过自己的 agent 网关运行，日志、失败样本、权限、评测结果就可能沉淀在企业内部。如果 Skill 平台托管执行，它可以拿到 usage、质量、留存和错误模式。如果 Skill 绑定自有 API，数据又会回到 API 提供方。

所以真正的问题不是“Skill 有没有数据飞轮”，而是“谁拥有执行环境、日志、评测和反馈”。

这也是我觉得那篇文章有点浅的地方。它看见了 Skill 作者没有数据，却没有把问题继续推到运行时、权限、评测和治理上。

托管服务不只是 AWS 转售

原文说，把 Skill 做成托管服务，本质是在卖 hosting。这个判断对个人小工具可能成立，但对企业场景太简化。

企业买一个 agent runtime，不只是买服务器。

它买的是：谁能运行，能读哪些文件，能不能调用外部 API，执行过程有没有日志，失败能不能回滚，版本怎么管理，安全事故谁负责，敏感数据能不能脱敏，输出能不能评测，哪些 Skill 可以进入组织目录，哪些要被禁用。

这些东西不是 hosting，它们是治理。

Claude Code 的安全文档里提到默认只读、权限审批、沙箱执行、写入边界。Anthropic 也有 Software Directory Policy，要求目录里的 Skills、Plugins、MCP 等软件持续符合安全和合规规则。这些信号说明，Agent 执行不是简单调用模型，而是权限、安全、合规和责任问题。

所以未来真正可收费的，可能不是 Skill，而是 SkillOps：目录、审计、认证、权限、沙箱、版本、评测、回滚、责任链。

如果 AI 替代知识工作，别在被替代区域里找长期利润

我更愿意把 Skill 放到一个更大的背景里看。

如果 AI 会替代很多知识性工作，那么在“被替代工作本身”里寻找长期利润，意义可能不大。就像农业机械化之后，长期利润不再主要属于“更多农民下地干活”，而是迁移到机械、种子、化肥、土地、加工、渠道、品牌和金融。

知识工作也会发生类似变化。写文章、写代码、做报表、做分析、写总结、生成方案，这些任务不会消失，但它们的边际价格会下降。真正有利润的地方会迁移到基础设施、业务入口、私有数据、权限体系、责任承担、判断标准和执行闭环。

也就是说，未来不一定是谁更会写 Skill 赚钱，而是谁能让 Skill 接进真实系统、真实数据、真实权限、真实业务结果里赚钱。

这也解释了为什么我一直觉得，代码不再是壁垒，平台能力才是；认知是资产，代码是消耗品；AI+工程，而不是工程+AI。

Skill 是名片，但它也应该是接口

原文最后说：Skill 是名片，不是产品。

我基本同意，但我会再加一句：Skill 是名片，也是接口。

作为名片，它证明你有能力把一个领域的隐性经验抽象成 AI 可执行的结构。一个咨询师发布一个高质量行业 Skill，比写一篇文章更能证明他真的懂这个场景。一个产品团队发布一组高质量 Skills，也比单纯说“我们 AI-native”更有说服力。

但作为接口，它还有另一层价值。它把你的方法论暴露给 Agent，把你的产品暴露给外部工作流，把你的业务能力暴露给新的执行入口。

这时候 Skill 不赚钱也没关系。它可以像 SDK、API 文档、开源库、案例模板一样，成为分发和信任入口。真正收费发生在后面：API、托管、企业版、审计、服务、培训、私有部署、结果交付。

最后的判断

我不会把 Skill 看成一个要不要收费的小商品。我更愿意把它看成 AI 时代知识工作重组的中间形态。

它会压缩很多旧收费点，也会打开一些新收费点。旧收费点是培训、模板、初级咨询、重复交付。新收费点是运行时、审计、私有上下文、业务闭环、判断标准和责任承担。

Skill 作为产品会自我消解，
作为接口会重新分配价值。

真正要研究的不是 Skill 怎么赚钱，而是 Skill 把哪部分知识变便宜之后，哪部分能力开始变贵。

如果一个 Skill 后面没有系统，它就是一个漂亮模板。它可能会传播，也可能会被复制，但很难长期收费。

如果一个 Skill 后面有运行时、有数据、有权限、有评测、有审计、有责任链，它就不再只是一个 Skill。它是 AI 进入真实工作的接口。

所以我一开始看鸭哥那篇《团队中共享 AI skills 的原则与方法》，并没有把重点放在“这套目录怎么建”。真正让我觉得值得往下想的，是它实际上动了一个更深的前提：团队知识不一定非得先统一，才能被共享。

这件事一旦成立，AI 时代的团队知识库就和传统 wiki 不是一个物种了。

传统知识库管理的是信息，AI 时代管理的是行为

传统知识库的目标很明确：把信息写下来，方便人去查。最好的状态通常是一份统一定义，一份标准口径，一套大家都能接受的说法。它服务的对象首先是人，所以它天然追求可读、可查、可统一。

但 AI 时代不一样了。你写下来的东西，不只是给人看，还会被 Agent 拿去当运行时上下文。它会影响 AI 选什么工具、走什么路径、按什么口径解释问题、输出什么风格。也就是说，知识不再只是“描述世界”，而开始“塑造行为”。

传统团队知识库在解决“信息怎么保存”。
AI-oriented Context Infrastructure 在解决“组织经验怎样在任务执行时被稳定调用”。

这就是我觉得最本质的结构变化。对象变了，治理方式就一定会变。

真正被打碎的，不是文档格式，是“唯一权威版本”这个幻想

鸭哥文章里最有价值的地方，在我看来不是共享池，不是 baseline，也不是 heartbeat，而是它公开放弃了“团队知识最终应该收敛成一份权威版本”这个假设。

过去我们处理知识冲突，第一反应通常是合并。两个人对同一个指标有两种说法，那就拉会对齐，定一套标准，然后写进文档。这个逻辑在很多场景都成立，尤其是财务、合规、监管这种必须统一的东西。

但放到 skill 这类 AI 资产上，问题就出来了。因为 skill 的价值恰恰来自个人判断。一个分析师怎么理解某张表，另一个工程师怎么定义一个故障路径，第三个人怎么做代码审查，这些东西很多时候不是“谁对谁错”，而是带任务语境的工作偏好。你把它们过早磨平，最后沉淀下来的往往只剩 consensus，而 consensus 恰恰是 AI 最不缺的东西。

所以文章里那个“共享池负责存，个人 INDEX 决定加载”的设计，我觉得很对。它不是简单地把个人知识拿出来共享，而是第一次把“共享”和“统一”拆开了。

冲突在这里不再只是问题，而是系统信号

我越来越觉得，AI 时代很多过去要被消灭的东西，现在反而应该被保存下来。

重复是一种信号。五个人都写了差不多的 skill，说明这件事已经接近团队共识了。分叉也是一种信号。同一个对象有三种不同写法，说明这里要么存在真实的任务差异，要么还没有形成稳定共识。以前这些东西会被知识库管理员当成脏数据，现在反而可以成为治理输入。

这也是为什么我会觉得 heartbeat 这个思路很重要。它不是替人做裁判，而是先替团队做观察员：哪里高度重合，哪里明显分叉，哪些 skill 被频繁引用，哪些 baseline 已经过时。AI 第一次不只是知识使用者，也开始变成知识系统的维护者了。

AI 没有降低知识维护成本，只是改写了成本结构

很多人会直觉觉得，AI 这么强了，知识维护应该更轻了。我的判断正好相反：它没有让维护变轻，只是让维护的重点换了地方。

传统 wiki 的核心成本在写和更新。谁来写，谁愿意持续更新，谁来处理冲突。这是典型的人工编辑成本。

到了 AI 这里，新增的反而是运行成本和治理成本。你要考虑的事情会变成：哪些上下文默认加载，版本怎么定位和回滚，被引用的 skill 改了以后会影响谁，哪些记忆该保留多久，改完之后怎样证明 Agent 行为更好了而不是更飘了。

这也是为什么现在很多厂商开始把 prompt sharing、multi-agent orchestration、memory service 这些能力做成产品层。Google 已经把保存与共享 prompt做成显式能力。微软在讲multi-agent patterns时，已经不是在讲聊天体验，而是在讲任务委派和结构化协作。AWS 甚至把memory configuration直接做成了参数。

这背后其实在说明同一件事：团队真正要维护的，不再是一堆静态资料，而是一套可执行的上下文系统。

公司级 Context Infra，应该先建什么

如果站在公司层面，我会把这件事拆成五层。

最上面是组织硬规则。安全、合规、品牌、权限边界，这些必须统一，不能交给每个人各写各的。

第二层是 baseline。也就是团队推荐默认集。新人不需要从零开始，老手也不必被它绑死。它像一个比较合理的起点，不是唯一正确答案。

第三层是 personal overlay。真正值钱的 knowhow 很多都在这里。一个团队如果只剩 baseline，没有个人扩展，最后只会沉淀出一种“正确但没味道”的平均版本。

第四层是 activation。也就是在什么任务下加载什么，哪层覆盖哪层，什么是默认启用，什么只是候选能力。没有这一层，所有 skills 再多也只是一个仓库，不是 infra。

最后一层是 evaluation。哪条规则改了之后真的更好，哪些失败样本应该沉淀为新 skill，哪些 baseline 应该晋升，哪些要回滚。没有评测闭环，所有升级最后都会退化成感觉。

公司级 Context Infra 的重点，不是先做一个更大的知识中心。
而是先做一套允许分叉、能自动观察、能逐步晋升共识的上下文编排系统。

为什么很多老问题会在 AI 面前重新长出来

你如果回头看，会发现很多问题其实并不新。知识冲突、定义漂移、维护成本、标准与灵活性的拉扯，这些过去在 wiki、语义层、规范库里都出现过。

真正变化的地方在于，这些问题第一次直接进入执行层了。过去文档冲突，影响的是人理解得慢一点；现在 skill 冲突，影响的是 Agent 当场走偏。过去知识库过期，顶多是查的人多问一句；现在上下文过期，可能直接塑造出错误行为。

所以 AI 不是把这些老问题消灭了，而是把它们推到了一个更靠近产出的地方。你不能再用“反正人会二次判断”来兜底了。

最后我更关心的，不是文章写得对不对，而是它指向了什么

鸭哥那篇文章当然还不是一套完整的方法论。它没有把 evaluation 层完全展开，也没有细讲公司级 policy、权限和回滚。但它已经很明确地指向了一个方向：团队共享 Skills 这件事，不能再按传统知识库的方法来管了。

我觉得这件事最值得讨论的，不是“这个目录怎么搭”，而是它背后的那个转向：从管理信息，转向管理上下文；从统一文档，转向分层编排；从人工维护，转向 AI 参与维护。

这也是我现在对公司级 Context Infra 最核心的判断。它不会再长成一个新的 wiki。它更像一个组织级的控制平面。真正要维护的，不是一份大文档，而是一套会在运行时不断塑造 Agent 行为的系统。

如果这个判断成立，那很多事情就顺了。为什么 skill 可以允许重复，为什么 baseline 不能太重，为什么 heartbeat 比大编辑部更有前途，为什么 eval 比内容运营更重要。

因为在 AI 时代，知识库不再只是“告诉你答案是什么”，而是“提前影响系统会怎么做”。

它当然不准确。按目前公开信息，更准确的说法应该是：SpaceX 和 Cursor 达成了深度合作，同时拿到了今年稍后以 600 亿美元 收购 Cursor 的权利。这里面有合作，有 option，有后续空间，但还不是一个已经完成并表的既成事实。

可问题就在这里。为什么一个并不准确的说法，会传播得这么快，而且很多人第一眼看过去还觉得“很合理”？

我觉得原因不只是大家没看原文，而是这个错法，刚好说出了这件事真正重要的那一层。

错的不是方向，错的是时间点

过去一年，大家讨论 AI 编程工具，很多时候还停留在产品层。谁更像 IDE，谁补全更强，谁 Agent 更聪明，谁能替你多写几段代码。可这次 Cursor 被放进交易语言里之后，事情突然变味了。市场不再只是把它看成一个工具，而是在把它看成一个入口，一个控制点，一个值得被大型体系直接拿下的战略资产。

这才是重点。

如果 Cursor 只是个好用一点的编辑器，这笔交易根本不会成立。600 亿美元 这个数字，放在普通 SaaS 语境里太夸张了。可一旦你换个角度，把 Cursor 看成开发者入口，看成高价值编码流量入口，看成未来知识工作 agent 的一个分发位，这个价格虽然依然激进，但至少不再荒唐。

说白了，市场现在给 Cursor 定价，已经不只是按“它今天帮多少人写代码”来算，而是在按“它未来能卡住哪一段价值链”来算。

为什么大家会自动把它听成“已经买下了”

这里面有一个很典型的传播学现象。法律语言喜欢留空间，社交语言喜欢去掉空间。官方说的是 the right to acquire，社交平台最后传成的就是 acquired。前者是条款，后者是故事。绝大多数人转发的从来都不是条款，而是故事。

更关键的是，这个故事太顺了。Cursor 过去一年估值一路狂飙，收入也在飞。SpaceX 和 xAI 刚完成更大的资本重组，市场又早就习惯了 Musk 用更大的叙事把不同业务串起来。在这种背景下，大家天然会觉得：这件事不是会不会，而是早晚的问题。

所以很多人把“有收购权”讲成“已收购”，虽然事实层不对，但产业直觉上又不算完全离谱。因为这句话提前说出了市场真正已经意识到的那件事：Cursor 这种 AI coding 平台，正在被重新定价成基础设施级资产。

真正的变化，不是工具更强了，而是入口更值钱了

对 OpenAI、Anthropic、GitHub 这些玩家来说，真正麻烦的从来不是“多了一个好产品”，而是某个产品开始往平台级资产升级。一个工具再强，威胁都有限。可一旦这个工具同时连接了开发者工作流、模型调用、算力需求和企业落地，它就不只是工具了，而是未来软件生产系统里的一段主干道。

谁控制主干道，谁就比单纯卖铲子的人更值钱。

这也是为什么我觉得这件事值得看，但看的不是八卦，而是方向。AI coding 这条赛道，正在从应用竞争切到基础设施竞争。真正的战争，不再只是模型能力谁更强，而是谁控制算力，谁控制开发者入口，谁控制高价值任务流经哪条系统。

如果这个判断成立，那未来最值钱的公司，不一定是最会生成代码的公司，而是最会卡住工作流入口的公司。

比“买没买成”更值得盯住的事

我反而觉得，这比“SpaceX 到底买没买成 Cursor”更值得盯。

新闻层，当然要把话说准。可产业层，很多时候市场先用错话把趋势喊出来，然后事实才慢慢补上来。

Cursor 这件事，可能就是这样。

但如果你顺着它们 2025 到 2026 的产品线往下看，会看到一个更收敛的现实：所有 Labs 都在把 AI 从“信息获取工具”推向“高价值任务执行层”。

这不是措辞变化，而是产品、定价和收入结构一起变了。OpenAI 从 Operator 到 Deep Research 再到 ChatGPT agent，路径非常连续。Anthropic 则从 Claude 一个聊天框，拆成了 Claude Code、Cowork、Claude for Work 这种按任务类型和组织边界划分的系统。Google 也一样，一边继续做搜索和广告，一边把 Workspace agents、Gemini Code Assist 和 Gemini 3 的 agentic workflow推成新的企业执行层。

不是回答问题，而是把事做完

我越来越觉得，理解这一轮变化最好的分界线，不是“模型更强了”，也不是“多模态更完整了”，而是一个很朴素的问题：

AI 的价值单位，到底是“给你一个答案”，还是“替你完成一个结果”？

这两者差别非常大。

“给答案”更像流量生意。你问，我答，答完就结束。用户可以今天问你，明天问别人。切换成本低，护城河也低。搜索、广告、信息入口，基本都属于这一层。

“做结果”则完全不同。它意味着 AI 需要接进真实工作流，拿到上下文，调用工具，穿过多个步骤，最后生成一个企业愿意承认的结果物。可能是一份投资备忘录，一份 amortization schedule，一次 legal notice 的分流，一段能合并进主干的代码，一套更新过真实数据的表格，或者一份能直接拿去汇报的演示文稿。

OpenAI 在 ChatGPT agent 里已经把这个方向说得很明白了：它评估的不是泛泛任务，而是 economically valuable knowledge-work tasks。Anthropic 更直接，在融资公告里写自己领先的是 economically valuable knowledge work tasks in finance, legal, and other domains。Google 也不是在卖“更会聊天的 Gemini”，而是在卖能处理 end-to-end business processes 的 Workspace agents。

这就是为什么我说，它们真正抢的不是流量，而是工资池。因为一旦 AI 的价值单位从“答案”变成“结果”，它面对的就不再是广告预算，而是企业里那些本来发给分析师、程序员、法务、研究员、运营经理的工资预算。

为什么最先被盯上的，是 Coding、金融、法律和分析

很多人看到“高价值任务”这四个字，会误以为指的是最有创造力、最不可替代的工作。其实不是。Labs 现在最先盯上的，是另一类任务：单价高、知识密度高、工作流长，但又足够结构化、可验证、可拆解的任务。

Coding 是最典型的第一战场。它的好处太多了：结果可验证，ROI 容易算，企业愿意付费，产品也容易做成 seat + usage + governance。Anthropic 在 2026 年把 Claude Code 做成收入主力，不是偶然。Google 把 Gemini Code Assist 明确写成覆盖整个 SDLC，也不是偶然。OpenAI 把 coding task 直接放进 enterprise agent 里，更不是偶然。因为代码是今天最容易被 agent 化、也最容易被财务负责人接受的高价值任务。

金融、法律、数据分析则是第二战场。不是因为这些行业最容易被完全替代，而是因为它们内部有大量“高工资、重文档、重规则、可复核”的任务。OpenAI 拿 amortization schedule、competitive analysis 举例，Anthropic 反复强调 finance 和 legal，Google 拿 legal notices 和 business workflow 举例，本质上都在说明同一件事：这些任务最适合先被 AI 吃掉中间的大块流程。

这也是为什么我一直不太认同“脑力工作天然安全”这种说法。真正高暴露的，从来不是“低端工作”，而是那些高学历、高工资、但又被文档、表格、规则、模板和系统流程包裹得足够严实的工作。

Anthropic 那条线，最能说明问题

如果三家里只能挑一家来代表“高价值任务战略”，我会选 Anthropic。不是因为它最强，而是因为它现在的产品边界最像“工资池争夺战”的原型。

Anthropic 的意思其实已经很明确了：Code 管工程，Cowork 管知识工作，Claude for Work 管组织级治理与数据边界。换句话说，它不是卖一个模型，而是在卖一整套“组织如何把白领工作交给 agent”的系统。

更关键的是它的衡量方式。Anthropic 现在越来越喜欢用“economically valuable knowledge work tasks”这种词来描述模型能力。我觉得这比 benchmark 分数更有现实意义。因为一家公司如果开始用“经济价值任务”来定义能力，就说明它内部真正关心的，已经不是模型漂不漂亮，而是这东西能不能进收入表、成本表和组织流程。

它 2026 年的收入增速也在强化这个判断。根据 Reuters 的公开口径，Anthropic 的 annualized revenue 已经从 2025 年底的大约 90 亿美元，冲到 2026 年 4 月的 300 亿美元级别。这个数字当然仍然属于媒体口径，不是审计口径，但它至少说明一件事：市场正在为“高价值任务执行层”这件事付真钱，而且付得很快。

Google 和 OpenAI 还没有完全放弃旧世界

说到这里，也要避免另一个误判：不是说三家都已经彻底抛弃流量逻辑了。

Google 还是那个 Google。它不会突然不要广告，也不会突然把搜索变成纯企业软件公司。OpenAI 也一样，它在 consumer、commerce、甚至广告上的试探都还在继续。只是现在更清楚了：这些都不是它们最有壁垒的主战场。

真正有壁垒的，是谁能把 AI 深深嵌进企业工作流里，深到用户不再只是“来问一次”，而是“把这项工作交给你做”。一旦进入这个层级，收费逻辑就从 CPM、点击、时长，切到了 seat、premium capability、usage-based pricing、治理、审计、集成、上下文继承、系统控制权。这才是企业软件真正能吃住客户的地方。

所以我更愿意把 Google 和 OpenAI 理解成“双轨制”：旧世界还在养现金流，新世界在抢未来的工资池和控制权。只是到 2026，这条新轨已经不再是旁支，而是越来越像主航道。

真正危险的，不是某个职业消失，而是岗位被拆薄

很多讨论喜欢问：“AI 会不会替代程序员？会不会替代分析师？会不会替代律师？”我觉得这个问法已经有点过时了。

更现实的问题是：一个岗位里最值钱、最稳定的那一层任务，会先不会被拆薄？

Anthropic 的 Economic Index 给了一个很重要的信号：当前数据还不支持“整个职业整齐消失”，但很支持“岗位内部任务被拆开，然后一部分先被 agent 接管”。而且这些被接管的任务，并不主要集中在最低门槛工作上，反而更集中在高教育门槛、高知识密度任务上。

这意味着最先受冲击的，不一定是顶层专家，也不一定是底层执行者，而很可能是中间那一大层：会写、会查、会整理、会分析、会出文档、会做表、会做标准化初判的白领岗位。它们原本是中产工资池的主体部分，也是大公司组织结构最厚的一层。

这也是为什么我觉得图片里最后那句关于中产和社会稳定性的担忧，不是空话。因为这轮变化不是在吃掉最边缘的人，而是在改写很多社会里最核心的白领中间层。如果这层人的工作被压缩得足够快，组织结构、教育回报、职业晋升路径，都会一起变。

我现在更关心的，不是谁家模型第一

调研完之后，我反而对“哪家模型更强一点”没那么感兴趣了。我更关心的是三个问题：

第一，谁最先把高价值任务做成真正的工作系统，而不是 demo。

第二，谁最先拿走企业工作流里的控制权，而不是只做一个可替换的智能插件。

第三，谁最先把白领工资池里最厚、最可结构化的那一层，吃成自己的经常性收入。

如果从这个角度看，今天所谓的“AI 竞争”，已经很难再用“聊天产品份额”来解释了。它更像一场新的劳动力再分配战争。模型只是武器，Agent 是形态，真正的战场是工作流，真正的奖品是工资池。

所以，回到那张图。它最有价值的地方，不是“猜中了谁的战略”，而是把一个正在发生但还没被很多人完全说透的变化压缩成了一句话：所有 AI labs 最后都回到了同一个战场，叫高价值任务。

而我更愿意把这句话再推进一步：高价值任务只是表面，白领工资池才是底层。谁能把任务做成结果，谁就不只是拿走一部分软件预算，而是在重写整个知识工作的分配方式。

本文的局限性

第一，Anthropic 和 OpenAI 的部分收入数字仍然主要来自媒体口径或公司自述，不是审计口径，所以更适合支持趋势判断，不适合当成精确财务事实。

第二，Google 的双轨制比另外两家更复杂，它既没有离开广告世界，也没有停下 enterprise AI，所以这篇文章更强调它的新主战场，而不是完整复盘它的全部收入结构。

第三，关于白领岗位被压缩的社会后果，目前公开证据更支持“任务重写和岗位极化”，还不足以支持简单粗暴的“大规模整齐替代”结论。后续如果更多劳动市场数据出来，这个判断还需要继续更新。

这件事很反直觉。管理者不直接写代码、不直接交付，按理说应该是最不容易被 AI 替代的那批人。但 BCG 2025 年的全球调研给出了一个令人意外的数字：43% 的管理者和领导者担心失业，比基层员工的 36% 高出 7 个百分点。

"怕失业"只是表象。我觉得真正的问题藏在更深的结构里。想了几天之后，理出了一条线：问题不是"AI 会不会替代管理者"，而是组织里"定方向"这件事的游戏规则变了——变得对所有需要"既判断方向又负责执行"的人很不利。我把这群人叫做执行层：不只是传统意义上的中层管理者，而是所有被要求同时承担方向判断和落地执行的人——总监、Team Lead、资深 IC，甚至被要求"下场"的高管。

旧协议为什么能用两千年

先说过去的模式为什么能 work。

现代组织的底层逻辑，从罗马军团到今天的互联网大厂，本质上都是同一套东西：高层定方向，中层翻译和拆解，基层执行。这套模式有一个隐含假设：定方向的人不需要亲自做执行，做执行的人不需要操心方向。

这个假设之所以成立了两千年，不只是因为"环境变化慢"。更关键的原因是，高层在"定方向"这件事上，有一整套完善的支撑体系。商业分析团队做数据，咨询公司出框架，广泛的行业人脉提供信息面，战略部门做竞对分析。这些辅助设施把方向判断的风险降到了可控范围内。

而且，过去高层定方向时，最核心的考量不是外部趋势，而是与公司内部的适配性——自己的资源储备、人力结构、组织能力能不能撑住这个方向。这种"适配性判断"才是高层定方向的核心价值。它让方向判断变成了一个收益大、风险相对可控的事：因为你是在充分了解自己底牌的基础上做决策。

还有一个隐性但重要的因素：容错机制。高层判断失败了，除非是方向性的大败仗，否则很少因此被开掉。高层的人才库本身就小，培养周期长，替换成本极高。再加上方向判断本身就有高不确定性，大部分组织默认接受这个风险。败了一次两次，高层依然在位。这其实是合理的：探索方向本身就有损耗，组织需要承担这个成本，而不是让决策者个人背负。

总结一下：旧协议能 work，是因为高层定方向时有三层保障——辅助设施降低判断风险，适配性思维锚定决策质量，容错机制消化探索成本。三层叠加，方向判断成了一个"高收益、可控风险"的游戏。

AI 打破了什么

AI 时代，这套均衡被两件事同时打破了。

第一，方向判断开始依赖执行中的体感。AI 领域的变化速度按月甚至按周计。从模型阶段到 Agent 阶段到 Harness 阶段，每个阶段爆发出大量新概念。这些概念靠看报告、听汇报判断不了好坏，你要亲手试。体感、感觉、甚至直觉，成了方向判断的核心输入。

管理学里有个概念叫 OODA Loop（观察-判断-决策-行动），Boyd 当年的核心洞察不是"速度要快"，而是谁的 Orientation（判断）更贴合现实，谁就赢。当技术变化的速度超过信息在组织层级间传递的速度时，高层拿到的信息已经过时了。定方向不能再和做执行分开——这是物理限制，不是管理偏好。

UC Berkeley 的 California Management Review 说得很直接：在 AI 时代，战略不是一个静态计划，而是一种动态能力。Mintzberg 在 1985 年就提出过"涌现战略"：真正有效的战略不是纯粹自上而下设计的，很多是从执行层涌现出来的。AI 时代让这个判断变成了现实。

第二，AI 造成了一种"执行成本幻觉"，扭曲了方向判断的逻辑。由于 AI 大幅降低了执行端的成本（或者更准确地说，在大多数高层的认知中大幅降低了执行端的成本），方向判断开始从"内部适配"滑向"外部跟随"。"别人在搞 Agent，我们也得搞"，"Shopify 的 CEO 都说了 AI-first，我们也不能落后"——这类决策的逻辑是外部跟随，而不是内部适配。

过去高层定方向时最值钱的能力——判断"我们能不能做"，而不只是"该不该做"——正在被这种"AI 反正便宜，先试了再说"的心态侵蚀。

方向判断权下移了，但三层保障没有跟

当方向判断越来越需要执行体感时，高层自然会把方向判断的权力（或者说责任）往下推。IBM 调查了 2,000 名全球 CEO，68% 说 AI 正在改变他们认为"核心"的业务。但到底怎么动，他们希望下面的人给判断。

问题是，前面说的三层保障——辅助设施、适配性思维、容错机制——一个都没有跟着下移。而承接这些方向判断责任的人——我前面定义的"执行层"——面临的是三重结构性不对称。

辅助设施没有跟。高层定方向时有商分团队、咨询公司、人脉网络做底座。执行层定方向呢？大多数时候只能靠自己。没有商分团队帮你做数据支撑，没有咨询公司帮你出框架，行业人脉也远不如高层广。让执行层用和高层同等的质量去判断方向，但不给同等的支撑体系，这本身就不公平。

风险结构变形了。方向判断一旦被下推，执行层面临的赌注是三合一的：要看准方向，要自己落地，还要为执行端到底有没有 AI 承诺的那种效率负责。看远、落地、效率，三个赌注压在同一个人身上。而且，由于高层的方向判断已经从"适配性判断"退化成了"外部趋势跟随"，传递下来的方向本身就缺乏与组织能力的匹配——但这个匹配问题，最终也是执行层来扛。

容错机制没有跟。这一点很少有人讲，但在大厂里非常真实。高层判断失败有"人才稀缺"这个隐性保护伞，小仗输了不影响位子。但在组织的认知形态里，执行层的可替代性更高。一个执行层判断错了方向，导致团队半年的投入打了水漂，结果大概率是这个人背锅，而不是"组织承受方向探索的成本"。赢了是组织的功劳，输了是自己的责任。这种不对称的容错机制，使得执行层在被要求做方向判断时，本能地瞻前顾后。不是不想定方向，是游戏规则让你不敢定。

三个不对称叠加在一起，才是执行层不愿意也不敢承接方向判断的完整解释。这不是态度问题，不是能力问题，是结构性的。

死循环和它的可见症状

三重不对称造成了一个死循环：高层等执行层给方案（因为自己缺乏执行体感），执行层等高层定方向（因为自己缺乏判断的配套和容错）。两边都在等对方先动，方向在这个互等中持续空转。

一位资深 CEO 顾问 Sengupta 的描述很精准："CEOs Believe AI Is Transforming Their Business. Their Organizations Are Living a Different Reality."——CEO 觉得组织在转型，组织活在完全不同的现实里。

这个死循环有几个可见的症状。

第一，高层开始越过执行层，直接找一线做事的人聊。因为高层需要的是执行体感，而执行层如果自己不动手试，提供不了这个信息。能给的还是老三样——进度汇报、风险预警、资源方案——对"判断方向本身对不对"没什么用。

第二，传统的中层管理岗在被系统性地压缩。Fortune 在 2026 年 4 月报道，美国管理者的平均直接下属从 2013 年至今几乎翻倍，达到了 12.1 人。Meta 的新 AI 工程部门推到了 50:1。Gartner 预测到 2026 年，20% 的组织将用 AI 消除超过 50% 的中层管理岗位。Korn Ferry 调查显示 41% 的员工已经表示公司削减了管理层级。

第三，执行层被迫"假装 AI 成功"。一项对 50 名中层管理者的访谈发现，弱就业市场下，他们 "responsible for keeping up the illusion of an ultra-successful AI roll out"——要维护 AI 转型成功的幻象，即使实际效果并不好。这正是容错不对称的直接后果：你不敢说"这条路走不通"，因为说了之后你是那个被归咎的人。

砍人不是答案，但也不是给执行层找借口

写到这里，有必要说清楚一件事：分析三重不对称，不是在说执行层没有责任。分析结构性问题的目的，是把解法指向个人如何在结构中找到位置，而不是停留在"执行层要加油"或者"该淘汰一批人"的简单归因上。

Klarna 的教训很说明问题。这家瑞典支付公司 2024 年高调宣布 AI 替代了 700 名客服，声称节省 6000 万美元。一年后，CEO 公开认错："We focused too much on efficiency and cost."客户满意度下降 22%，公司被迫重新招人。Careerminds 的调查显示，66% 实施 AI 裁员的公司已在重新招聘被裁员工。

砍人之所以诱人，是因为它回避了真正的难题。传统执行层身上确实有两种功能：信息路由（汇总报告、传达指令、追踪进度）和判断（情境化决策、冲突仲裁、在模糊地带做选择）。前者确实正在被 AI 替代，也应该被替代。但如果连后者一起砍掉，你失去的不只是效率，而是组织的判断能力。

MIT 的 Neil Thompson 提出了一个"专业度悖论"：如果 AI 自动化的是非核心部分（行政杂务），管理者有更多精力做专业判断，这是好事。但如果管理幅度膨胀到连专业核心工作都做不了，那就不是提效而是灾难。放射科医生是正面例子——2016 年 Hinton 预测 AI 五年内取代他们，结果采用 AI 后人数和薪资双双增长。技术没有消灭这个职业，而是重新定义了它。

未来需要什么样的执行层

分析到这里，结构性的不对称已经很清楚了。但我不想把文章停在"组织应该怎么改"上——因为规则的调整永远慢于个人的适应。更实际的问题是：在这个方向和执行粘合的新时代，什么样的执行层能活下来，甚至活得好？

第一，能自己建支撑体系的人。

组织的辅助设施不会为你准备好，等它准备好黄花菜都凉了。过去高层有商分团队帮他看信息、做分析，未来的执行层需要自己搭建这个能力。AI 本身就是最好的工具：行业扫描、竞对分析、方案对比，一个人加 AI 能做到过去一个商分团队的信息覆盖度。但关键不是"学会用 AI"——这话太泛了。关键是把 AI 定位为你做方向判断的基础设施，而不只是提高执行效率的工具。能用 AI 看远的人，和只会用 AI 干活的人，差距会越来越大。

第二，能在执行中迭代方向的人。

三合一压力（看方向 + 抓落地 + 扛效率）不会消失，但可以换一种方式应对。未来的执行层需要学会一种新的工作节奏：不是先定方向再执行，而是在执行中不断校准方向。用两周到一个月的周期做小范围的方向试探，快速验证，快速调整。方向不是一个"决定"，而是一个"持续迭代的过程"。能接受这种节奏的人——不追求一步到位，而是追求每一步都在逼近正确——会比等待完美方案的人走得更远。这也是 Mintzberg 的"涌现战略"在个体层面的实践：让方向从你自己的执行中长出来，而不是等它从上面传下来。

第三，能主动争取容错空间的人。

容错机制不会从天上掉下来。未来的执行层需要主动做一件事：把方向探索的成本显性化。不是默默尝试然后祈祷成功，而是在尝试之前就和组织达成共识——这是一次方向试探，有失败的可能，失败的成本是 X，我们接受这个成本。能把"赌"变成"实验"的人，才有空间做真正的方向判断。那些不敢暴露不确定性、只会报喜不报忧的人，反而会在信息不对称中越陷越深。

焦虑背后的真正问题

想清楚这一圈后，回头看"管理层焦虑"这件事，可以描述得更精确了。

焦虑的本质不是"怕被 AI 替代"，甚至不是"怕跟不上"。它是一种角色模糊感：旧的分工协议失效了，新的还没有建立起来。你被要求同时做方向判断和执行落地，但既没有得到做方向判断的配套支撑，也没有得到判断失败后的容错保障。

这种感觉不分层级。高层焦虑是因为知道要动但定不了方向（缺乏执行体感，又不愿意承认自己需要下场）。执行层焦虑是因为方向判断的责任压下来了，但保障没有（赢了是组织的功劳，输了是自己的锅）。基层焦虑是因为听到的都是"AI 会替代你的工作"，但没人解释替代之后自己的角色是什么。

Fortune 那篇文章问了一个终极问题：

"Whether that is a transition cost or the new permanent condition of leadership in America is the defining workplace question of this decade."

我觉得答案取决于你怎么看自己的角色。如果你还在等组织给你一个清晰的方向和完善的保障体系，那焦虑只会越来越深——因为旧规则已经失效了，新规则也不会从天上掉下来。但如果你接受"方向和执行粘在一起"这个新现实，开始自己建支撑、自己跑迭代、自己争取容错空间，那你就不是在等规则被重写，而是在用自己的方式定义新规则。

未来需要的执行层，不是更能吃苦的人，不是更听话的人，也不是更擅长向上汇报的人。而是那些能在模糊中找到方向、在执行中校准判断、在不确定性中为自己争取试错空间的人。说到底，方向和执行的耦合不是一个需要被"解决"的问题，它是新时代的基本条件。能把这个条件变成自己优势的人，焦虑会自然消解——不是因为规则变公平了，而是因为你不再需要等别人来定规则。

我也不确定我已经变成了这样的人。但至少我在做三件事：自己下场，带着体感去定方向；用"小仗"的节奏做方向试探，让方向从执行中涌现；把不确定性摆在台面上，而不是藏起来。这不是标准答案，但至少是诚实的尝试。

有意思的地方在于：这不代表 AI 变差了。恰恰相反，很多模型现在写得比以前顺太多了。结构更稳，句子更圆，解释更全，错别字更少。问题也恰恰出在这里。它越来越像一个训练得很好的优等生，努力完整，努力礼貌，努力不犯错。最后读者闻到的，不是机器味，而是一种很强的平均值感。

AI 味不是因为它太笨，而是因为它太擅长产出“标准答案”。

很多人会把这个问题讲得很轻，好像只是删几个“首先”“其次”“综上所述”，或者少打几个破折号就行了。我不太认同。那些东西顶多算皮，不是骨头。真正的问题是：模型写出来的东西，越来越像先搭好模板，再往里填内容，而不是从一个具体判断长出来。

为什么它会越来越像“标准答案”

这件事如果拆开看，其实完全不神秘。

第一层是 next-token prediction。模型天然偏向高概率延续，而不是低概率但更有个性的表达。它最容易写出的，不是“这句话只像你会这么说”，而是“多数情况下都不会错的说法”。

第二层是 instruction tuning 和对齐训练。无论是 InstructGPT，还是 Anthropic 的 Constitutional AI，它们都在把模型往“更可用、更合作、更安全”方向推。这当然很有价值，但副作用也很明显：语气会更稳，更礼貌，也更容易变成一种统一人格。

第三层则更现实。我们自己给 AI 的 prompt，本身就在持续强化这种统一人格。你让它“结构清晰、逻辑完整、分 3 点展开、最后总结一下”，它当然会越来越像一个汇报生成器。模型没有故意油腻，是我们平时的使用方式反复奖励这种油腻。

所以 AI 味不是一个点的问题，而是三层叠加：

1. 高概率平均表达
2. 对齐训练塑造出来的稳态语气
3. 提示词自己带进去的模板收敛

三层一叠，最后就不是“像人”，而是“像一个被训练得太成功的优等生”。

人为什么会一眼闻出来

我现在越来越觉得，大家识别 AI 味，往往不是靠某个词，而是靠一组感觉同时出现。

第一，结构先于判断。读者会很快感觉到：这篇东西不是从一个观点长出来的，而是先有框架，再填观点。第二，解释欲过强。每个概念都解释了，每个转折都照顾到了，但信息越来越多，判断反而越来越薄。第三，对风险的回避过于一致。它总想两边都照顾，总想讲全面，于是读完之后你知道“它很稳”，但不知道“它到底站哪边”。

这也是为什么我现在会把 AI 味理解成一种更本质的东西：

AI 味，本质上是认知摩擦被过早抹平之后留下的平滑表面。

真正有力量的文字，很多时候不是一次就写顺的。它往往要经过卡住、删掉、重排、推翻原框架这些过程。可 AI 太擅长给你一个“已经看起来可以交”的版本了。危险也在这里。它不是写得差，而是太容易让你误以为自己已经想清楚了。

为什么有些人特别讨厌这种味道

我觉得这背后不是单纯审美差异，而是任务差异。

如果你写的是 FAQ、说明书、会议纪要、基础汇总，这种风格其实挺好用。它稳定、省事、不容易翻车。但如果你写的是判断、汇报、说服、战略表达，这套风格就会出问题。因为这些场景真正需要的，不是完整，而是压缩后的判断。你得敢于删，敢于押注，敢于让文字带着一点“这就是我的看法”的成本感。

这也是为什么我越来越反感“技术分享会式”写作。不是因为它技术不对，而是因为它太像信息同步，不像认知对齐。它把事情讲清了，却没有把判断讲出来。

真正的去味，不是删词，是改控制面

很多人对抗 AI 味的方法，像在做词汇打地鼠。删掉几个“此外”，删掉几个“总之”，不让它打破折号。这些当然有帮助，但治标不治本。因为问题不是某个词，而是任务对象本身。

如果你给模型的目标还是“写一篇完整文章”，它就会自动回到那条高概率平均值路径。你删了几处口头禅，它下一段还是会走回熟悉骨架。

真正有效的改法，我现在更相信有四条。

第一，先让模型站住判断，不是先展开结构

不要先问“怎么写完整”，先问“这篇东西最核心的一句判断是什么”。一旦没有这句判断，后面所有展开都会默认长成模板。

第二，同时给正向风格约束和反向禁令

只说“写自然一点”没用。更有效的是明确写：要具体、要有场景、要有取舍；不要每段都总结，不要平均用力，不要像主持分享会。

第三，把人工编辑动作当成高价值偏好数据

这点我体感最深。真正让 AI 变得更像你，不是你补了多少抽象形容词，而是你到底改了哪里。你删掉什么，保留什么，重排什么，这些动作本身就是最值钱的 taste signal。

所以我现在越来越相信：真正有竞争力的写作系统，不是第一次就写得最顺的系统，而是最会从“你删掉了什么”里持续学会 taste 的系统。

第四，在生成端就先控重复和模板化

OpenAI 官方文档里对 frequency_penalty 和 presence_penalty 的说明很朴素，但很有价值。它提醒我们：有些味道不该完全留到后处理，而应该在生成阶段就先压住。否则你拿到的已经是一副成型骨架，后面只能修边角。

最后的判断

如果非要把这件事压缩成一句话，我现在的判断是：

AI 味不等于机器感，它等于被奖励函数抹平之后的平均值感。

所以最好的去味方法，不是逼模型“更像人类”，而是让它少回到平均值，多暴露判断，多保留删改痕迹，多接受来自真实工作流的偏好校准。

真正有复利的，也不会是一次次手工修文，而是把这件事本身做成控制面：任务怎么定义，候选怎么分化，编辑痕迹怎么沉淀，下一轮怎么回灌。这样你对抗的就不只是这一篇文章的 AI 味，而是在给系统慢慢长出自己的 taste。

它表面上只是一个很普通的自动化问题：把 Plaud 录音拉到电脑，传到腾讯会议转写，再把文字稿接进后续总结和蒸馏链路。真拆开看，也就四步。

1. 下载录音
2. 上传转写
3. 取回文字稿
4. 进入总结和蒸馏

但就是这四步，我前前后后折腾了快一年，尝试次数不下 10 次，直到这周才真正跑顺。

所以这篇文章我真正想讲的，不是“我又做了个自动化”。而是另一件事：很多工作流之所以一直卡着，不是因为其中某一步不会写，而是因为你看问题的方式还没变。

这条链路为什么一直值得折腾

去年六七月，受鸭哥“赛博人生计划”的启发，我开始系统采集自己的日常信息。那时候“蒸馏”这个词还没像今天这么流行，但我已经在想一件事：能不能把每天真实发生的会议、对话、决策、卡点，持续沉淀成一个可用的 context 系统。

所以我买了 Plaud。因为平时会很多，我每天录音时长大多在 12 小时以上。

真正的难点从来都不在采集，而在后处理。每天十几个小时的录音，如果不能稳定转成文字、再稳定进入后续总结，它就只是另一种形式的“数据囤积”。

腾讯会议在这里很关键。它提供了一个相对稳定、而且几乎免费的转写入口。否则按我这个体量，真去按 API 成本硬算，根本不现实。

所以，这件事对我来说从一开始就不是一个可有可无的小优化，而是一条必须跑通的基础设施。

我经历了三个阶段

第一阶段：每天手工搞 1 小时

刚开始做这件事时，其实还挺兴奋。每天专门拿出 1 个小时，手工从 Plaud 下载录音，再上传到腾讯会议，等转写，最后把文字稿扔给 Gemini 做当日总结。

那个阶段只有 Gemini 顶得住。因为这么大体量的文字稿，别的模型上下文窗口都不太行。

那时候我的感觉是：虽然笨，但至少已经跑起来了。

第二阶段：改成每周集中处理，摩擦反而更大

后来我把节奏改成每周五集中处理一次。表面看像是优化，实际上摩擦更大了。

原因很简单。每天 12 小时大约会有 3 个文件，7 天就是 21 个文件。下载、上传、等待、盯状态，全都被批量放大。这个时候你会发现，批量处理带来的不是效率，而是更强的中断感。

我那时候试过浏览器 MCP，也试过 AI 浏览器。Comet 确实算其中最好用的一个，但还是不够稳。只要某个文件要下载 20 分钟，中间一断，就得人工接回去。

于是这条链路一直没法真正收口。只是后半段的“复盘总结”开始逐渐交给 Cursor 和 Claude Code 去做了。

第三阶段：这次终于做到接近 0 摩擦

这次真正完成的，不是某个脚本终于写对了，而是整条链路第一次作为系统跑通了。

Plaud 自动下载，自动保存，自动上传，等待转录，自动下载文字稿，自动总结，然后进入蒸馏序列。全程几乎不需要我介入。

做到这一步以后，我回头看才发现，真正关键的不是代码量，也不是自动化步骤数，而是背后有几件事情终于同时成熟了。

最后让我过关的，是四个变化

第一，基础设施终于到位了

如果没有一台 24 小时在线、登录态稳定、任务能持续跑的 Mac mini，这件事其实很难真正落地。很多自动化任务早期做不成，不是逻辑不对，而是运行环境一直停留在 demo 条件里。

我后来越来越觉得，所谓“把工作流做成系统”，第一步往往不是去补逻辑，而是先把基础设施补齐。机器常驻、状态持久、任务不断线，这些听起来都不是主角，但它们决定了你最后拿到的是脚本，还是基础设施。

第二，工具终于变得更适合被 AI 调用了

过去一年里，工具层本身也成熟了很多。无论是 Playwright，还是 Chrome 系列工具，对登录态保存、页面交互、长链路等待的支持，都比之前稳了不少。

很多人会把“过去没做成”解释成“自己不会做”。但不少时候，真相只是那一层工具能力当时还没成熟。时机没到，硬上只会把自己折腾得更烦。

第三，我开始从“工程解”转向“AI 解”

这是对我影响最大的一点。

我以前处理这种自动化问题，默认都是先按工程思路拆。脚本怎么写，状态怎么管，流程怎么控，异常怎么兜。这个思路当然没错，但它会天然把 AI 放在一个“辅助工具”的位置。

后来受到鸭哥一些实践和我自己在 OpenCode client 上尝试的影响，我开始换一个问题来想：

这个系统的核心控制面，到底应该是脚本，还是 Agent？

这个问题一变，设计空间就完全变了。后面我直接选了 OpenCode server 这条路，很多原来卡住的地方，一下就顺了。

所以我现在对这件事的判断很明确：AI+工程，和 工程+AI，真不是一回事。 顺序一换，系统中心就换了。

第四，我对 skill 的理解也变了

这次 workflow 跑通时，我顺手也在测试对应的 skill。中间当然还是有卡点。按我以前的习惯，我会立刻去问：“要不要针对这些卡点再补几条更强的约束？”

但这次我反而更确信另一件事：skill 的核心不是把 SOP 写满，而是围绕目标给 Agent 足够好的自由度和边界。

你如果每遇到一个局部问题，就往 skill 里加一条规则、补一个分支、再叠一层限制，短期看像是在修复，长期看其实是在把能力写死。最后 skill 会越来越重，越来越像流程图，而不是能力。

这次的结果说明，目标型的 skill 已经够用了。真正重要的是目标清楚、边界清楚，不是 SOP 无限加厚。

这件事真正重要的，不只是省掉 1 小时

如果只从“省时间”角度看，这条工作流的意义其实没那么大。真正重要的是，我重新确认了一件事：每日信息不能按周整理。

因为 context 是有时效性的。你这周真正在关注什么，卡在哪里，外部环境给了什么反馈，这些信号都在实时变化。隔一周再回头整理，归档也许还行，但蒸馏质量一定会掉。

所以我现在越来越相信，context infra 这套东西，不只是个人知识管理的问题。放到企业里也是一样。一个人的 context，不该只来自他和 AI 的 session 日志，还应该尽量贴近他的真实运行态。企业里的 context 构建，也不能只停留在文档层、汇报层、流程层，而应该更接近运行现场。

这也是为什么，这次工作流真的跑顺以后，我的第一感受不是“终于省了 1 小时”，而是“终于把一条真实世界里的 context 采集链路做成了基础设施”。

最后的判断

回头看，这件事能在这周真正落地，不是因为某一个脚本突然变神了，也不是因为某一个工具突然无所不能。它更像几个条件终于同时汇合了：

• 基础设施成熟了
• 工具能力成熟了
• 我自己的认知也变了
• 社区里已经有人把一些方向先跑出来了

这些条件少一个，可能都到不了今天这一步。

所以如果你手上也有一条反复折腾、总觉得“明明不复杂，怎么就是跑不顺”的工作流，我现在的建议不是立刻再补一个脚本，而是先问一句：

你缺的，到底是代码，还是基础设施；是工具，还是认知；是一个自动化步骤，还是整个系统的控制面。

很多问题，一旦问对了，答案会比你想象中来得快很多。

LaunchDarkly 也很容易被放进这个篮子里。它有 AI Configs，能管 prompt、model、tool、experiment、guarded rollout、observability，甚至开始讲 agent。乍一看，确实很像在做 AI 的基础设施。

但我把它的官方文档、SDK 边界和竞品都过了一遍以后，判断反而更清楚了：LaunchDarkly 真正在卖的，不是 AI infra，而是 AI control plane。

这个区别不是抠字眼。因为一旦分类错了，你对产品的期待就会彻底跑偏。你如果把它当成 model serving、AI gateway、agent runtime 去看，一定会觉得它“不够全”。但如果你把它当成一层专门管线上 AI 行为变更、分流、回滚、实验和治理的控制平面，它反而是很完整的一条产品线。

它不跑模型，这件事决定了它不属于底层 infra

判断一个产品是不是“真 AI infra”，最简单的方法不是看 marketing page，而是看它到底接不接 provider、代不代发请求、托不托管执行。

LaunchDarkly 在这件事上说得异常清楚。在官方文档 AI Configs quickstart 里，它直接写：

“In the AI Configs product, LaunchDarkly does not handle the integration to the AI provider.”

“However, it is still your application’s responsibility to call the AI provider.”

在总览页 AI Configs 里又补了一句更狠的：

“LaunchDarkly does not proxy or independently invoke model providers.”

只要一个产品明确说自己不负责 provider invocation，不 proxy model provider，你就很难再把它主标成模型基础设施。它不在跑车，它在管车道。

那它到底在卖什么

如果把 LaunchDarkly 的 AI 能力拆开看，它其实非常像把 feature flagging 时代最成熟的那套方法论，整体平移到了 AI 系统里。

它卖的是四件事。

第一，运行时配置。 你的 prompt、instructions、model config、tool schema 不再写死在代码里，而是变成一个可以按用户、按环境、按规则实时求值的对象。官方文档的说法是：“control how your application uses large language models”。

第二，发布控制。 新 prompt 能不能灰度。新 model 能不能先放 5% 用户。效果差了能不能秒回滚。有没有审批链和审计线索。这个思路本质上就是 feature rollout 的 AI 版本。

第三，实验与比较。 它不是只让你“改”，还让你“比”。不同 variation 的 token、时延、效果、judge 分数能不能一起看，这决定了你是在拍脑袋调 prompt，还是在做真正的生产实验。

第四，观测与治理。 AI 系统最怕的不是第一次跑不起来，而是上线以后慢慢漂。LaunchDarkly 的价值恰恰在这里。它想把 model behavior 放进一个可观测、可干预、可回退的闭环里。

所以我会把它翻译成一句更接地气的话：LaunchDarkly 不在造 AI 的发动机，它在造 AI 上路之后的方向盘、刹车、仪表盘和变道系统。

为什么这个位置反而可能很值钱

很多 AI 团队早期最关注的，都是“怎么把能力做出来”。接哪个模型，怎么调 prompt，怎么接工具，怎么把 demo 跑通。这当然重要，但一旦系统进入线上，真正麻烦的问题马上会变成另一组：

• 新 prompt 上线后效果变差了，怎么快速止损。
• 换模型后成本降了，但满意度掉了，怎么做分流比较。
• 某类用户应该走哪个 variation，谁来决定，怎么审计。
• judge、metric、rollout、approval 怎么绑成一个闭环。

这时候你会发现，AI 系统里最贵的部分，不一定是模型本身，而是变更管理。模型调用只是入口，真正容易出事故的是变更失控。

从这个角度看，LaunchDarkly 占的位置其实很聪明。它不是去和 OpenAI、Anthropic、Portkey、LangSmith 在同一个层面正面硬碰，而是抓住了一个很多团队都迟早会遇到的问题：AI 已经上线之后，谁来管它。

它也不是万能解

把 LaunchDarkly 看清楚以后，它的不足也就跟着清楚了。

如果你现在还处在“连 provider routing、prompt registry、trace、eval 都没搭起来”的阶段，那它不是你的第一优先级。因为它解决的不是“从零到一”，而是“从一到稳”。

如果你要的是完整 agent runtime，它也给不了。LaunchDarkly 在自己的 guide 里明确写过：配置它来管，orchestration 还是你的代码或 LangGraph 之类框架来管。这说明它想占的是 control plane，不是 runtime plane。

而且它还会带来另一个现实问题：你愿不愿意为这层控制面付费。对很多公司来说，这类平台最难证明价值的地方在于，它不直接“生成结果”，而是在防事故、防漂移、防变更失控。短期 ROI 不一定显眼，长期却可能越来越贵。

这也是为什么 LaunchDarkly 很容易在组织里碰到一种典型争论：业务会觉得“这不就是配置管理吗”，工程会觉得“这不就是 feature flag 延伸吗”，但真正把 AI 功能往线上推过几轮的人，往往会更容易理解它在卖什么。因为他们已经被 prompt 回滚、模型切换、线上漂移和实验不可追责这些问题打过脸了。

对企业团队来说，真正该问的问题

所以看 LaunchDarkly，不该先问“它算不算 AI infra”，而该先问三个更实际的问题。

第一，我们现在缺的是能力层，还是控制层。 如果能力层还没搭好，先别急着上控制平面。反过来，如果能力层已经差不多了，控制层迟早会变成瓶颈。

第二，我们的 AI 系统有没有进入需要治理的阶段。 只有当 variation、环境、审批、实验、回滚、观测这些问题同时出现时，LaunchDarkly 的价值才会真正显形。

第三，我们是否接受“AI 生产系统里，控制权本身就是产品”。 很多团队直到今天还会下意识觉得，真正值钱的是模型，控制只是配套。但我越来越觉得，AI 时代真正容易被低估的，恰恰就是控制面。

因为模型能力会越来越商品化，接口也会越来越标准化。真正长期稀缺的，不一定是“谁能调到最强模型”，而是“谁能让模型在真实业务里稳定、可控、可回退地运转”。

最后的判断

如果只让我给 LaunchDarkly 的 AI offering 贴一个标签，我不会选 AI infrastructure，也不会选 AI observability 或 AI experimentation。这些都太窄，或者太大。

我会选：AI control plane。

更完整一点，是：runtime AI control plane for production AI behavior。

它真正厉害的地方，不是替你把 AI 做出来，而是替你把 AI 上线后的失控风险，收回到一个可管理的系统里。

所以，LaunchDarkly 真正在卖的，不是 AI infra。它卖的是另一种在 AI 时代会越来越贵的东西：对生产行为的控制权。

我有。不止一次。

不是因为懒。是因为维护一个活的知识库，其工作量的增速远超它带给你的价值增速。你新收集了一篇论文，要更新三个相关页面的交叉引用，检查两处可能过时的结论，顺手修一下上周忘记补的标签。这些"记账工作"不难，但累积起来，足以让任何人放弃。

2026 年 4 月初，Andrej Karpathy 在 GitHub 上发了一个 Gist，标题叫 LLM Wiki。12 小时内拿了 2100 颗 Star，X 上的帖子被围观了 1200 多万次。他没有发布任何代码，只发了一个"idea file"。

我仔细读了这份 Gist，把社区的实现和批评都翻了一遍。我的判断是：这个概念本身不新，但他找到了一个过去一直缺失的角色来填补知识管理中最致命的空缺。

LLM 不是搜索引擎，是编译器

Karpathy 的核心命题用一句话概括：Compile, don't retrieve.

传统的 RAG（检索增强生成）是这么工作的：你问一个问题，系统把你的原始文档切成碎片，用向量搜索找到最相关的几块，塞进 LLM 的上下文窗口，让它临场发挥。每次查询都是一次独立的、无状态的处理。上一次查询积累的理解，到下一次查询时完全归零。

LLM Wiki 反过来：在你"摄入"一份新资料的时候，就让 LLM 把它消化成结构化的 Markdown 页面，和已有的知识建立交叉引用，标记与旧结论的矛盾。这些页面本身就是知识资产，下次查询时 LLM 读的是编译好的 wiki，不是原始碎片。

用软件工程的类比：RAG 像解释型语言，每次运行都从源码开始解析；LLM Wiki 像编译型语言，先编译成可执行文件，运行时直接用。

架构极其简单。三层：

三个操作：Ingest（摄入新资料时编译）、Query（在编译好的 wiki 上查询）、Lint（定期健康检查，找矛盾和知识缺口）。没有向量数据库，没有 embedding，就是 Markdown 文件加一个 index.md 做全局索引。

Karpathy 说这套东西在"中等规模下效果出奇地好"。他自己的 wiki 大约 100 篇文章、40 万字。开发者 Farza 用类似方法把 2500 条日记转化成了 400 篇结构化百科，评价是"比一年前用 RAG 做的系统好用得多"。

真正的问题从来不是工具，是谁来维护

回到开头那个场景：为什么人人都建过知识库，人人都放弃了？

不是 Notion 不好用。不是 Obsidian 的双向链接不够强。问题出在一个更根本的地方：知识库的维护成本随规模指数增长，但人类投入维护的意愿随时间线性衰减。

Karpathy 引用了 1945 年 Vannevar Bush 的 Memex 概念，那是最早描述个人知识系统的愿景。80 年过去了，从 Wiki 到 Evernote 到 Notion 到 Obsidian，工具换了一代又一代，但"谁来维护"这个问题从未被解决。每次技术迭代解决的都是"如何更方便地输入"，从来没有解决"如何可持续地维护"。

LLM Wiki 的真正价值不在于"知识编译"这个概念（确实不新），而在于它给出了一个此前不存在的答案：让 LLM 当维护者。

你往 raw/ 里扔文件，LLM 自动更新 10-15 个相关页面、重建索引、标记与旧结论的冲突。你不需要操心交叉引用、不需要手动打标签、不需要检查一致性。这些"记账工作"全部交给 LLM。

你的角色从"组织者"变成了"策展者"：决定什么值得摄入，审核 LLM 编译的质量，在关键处做判断。Karpathy 自己的定义很精准：

Human responsibility: curation, direction, thinking.
LLM responsibility: everything else.

但认知摩擦被消除了，这是个问题

最有力的批评不是来自技术层面，而是来自知识管理哲学。

Niklas Luhmann 用 Zettelkasten（卡片盒）方法写了 70 本书、400 多篇论文。这个系统的核心不是卡片本身，而是写卡片的行为：你必须用自己的话重新表述一个想法，必须思考它和已有卡片的关联，必须决定它放在哪里。这些摩擦力不是低效，而是认知整合的机制。

批评者用了一个精准的类比：

Luhmann 的 Zettelkasten 是锻炼本身。Karpathy 的 Wiki 是教练的报告。

教练报告记录了你的训练数据，但肌肉是你自己练出来的。如果 LLM 替你"消化"了所有资料，你得到的是一份光滑的综合报告，但可能绕过了真正建立理解所需要的挣扎。

Hacker News 上有人说得更直接："Karpathy mistakes the words to be the goal, rather than the thinking that caused the words."

这个批评成立吗？我觉得部分成立。

关键在于你用 LLM Wiki 做什么。如果目的是深度学习一个全新领域，让 LLM 全自动编译可能确实绕过了必要的认知挣扎。但如果目的是管理你已经有判断力的领域的信息流，比如跟踪 50 个竞品的动态、维护团队的技术知识库，那么"记账工作"确实不产生认知价值，交给 LLM 完全合理。

批评者自己也给出了折中方案：让 LLM 做地图层（索引、交叉引用、缺口发现），把综合判断留给人。LLM 发现矛盾后停下来提示你，而不是自动解决。我认为这是最务实的用法。

100 页是一道坎

技术层面最硬的约束是规模。

Karpathy 的方案用 index.md 做全局索引，LLM 在查询时先读索引再定位页面。这在 100 页以内工作得很好，但超过 500 页就开始退化，1000 页以上完全不可行。本质上 index.md 是线性搜索，随页面增长 LLM 需要处理的上下文线性增加。

Karpathy 推荐用 qmd（支持 BM25 + 向量搜索）缓解这个问题。但一旦引入向量搜索，它就开始向 RAG 靠拢。社区里也有人分层索引（从 200 token 的极简摘要到 20K token 的完整内容），分四级渐进披露。这些都是有效的补丁，但也说明原始设计在规模上有硬限制。

另一个被低估的问题是幻觉的累积效应。LLM 编译的内容和原始资料混在同一个系统里，如果某次编译引入了错误推断，后续查询会引用这个错误、放大它、让它成为"事实"。Karpathy 自己承认必须配合 Git 做版本控制，但光有 Git 不够，你还需要定期人工抽查。对个人知识库来说勉强可行，对企业级应用来说是一个严肃的工程挑战。

Karpathy 真正在说什么

如果只看 LLM Wiki 本身，它是一个有明确适用范围的知识管理方案：中等规模、相对稳定的知识、有判断力的个人用户。不是万能药。

但如果把它放进 Karpathy 过去两年的轨迹里看，信号就清晰多了。

2025 年初他提出 Vibe Coding（用自然语言让 AI 写代码）。年中他自己修正说 Vibe Coding 已经过时了，新的范式叫 Agentic Engineering。年底他做了 AutoResearch，让 AI agent 自主跑实验（700 次试验/2 天）。到 2026 年 4 月，他发布 LLM Wiki，token 用途从代码操作彻底转向知识操作。

这条线的方向很明确：从人写代码，到 AI 写代码，到 AI 自主做研究，到 AI 维护知识。人的角色在整条链路上持续上移，从执行者到审核者到策展者。

他有一句话我印象很深：

我不再需要向人类解释了，我是在向智能体解释。如果智能体理解了，它们就能以无限的耐心向人类重传这些知识。

这句话的含义比 LLM Wiki 本身大得多。它在说：人类的护城河不再是知识的传递，而是核心直觉的产出。整理、编译、传递这些中间环节，全部可以交给 AI。你要做的是决定方向、做判断、产出别人无法替代的洞察。

LLM Wiki 只是这个大趋势中的一个具体实例。但它恰好击中了一个人人都有体感的痛点：知识库为什么总是烂尾。答案不是更好的工具，而是换一个不会厌倦记账的维护者。

对我自己的启发

作为一个 AI 工具的深度用户和团队管理者，我从 LLM Wiki 里提取了三个可执行的判断：

第一，知识管理应该分三层。核心知识用编译维护（LLM Wiki 的思路），长尾信息用检索（RAG），实时数据直接 API 查。不要试图用一套系统解决所有问题。

第二，Schema 设计比工具选型重要。LLM Wiki 的质量完全取决于 Schema（那个 CLAUDE.md）的设计质量。这其实就是我一直在做的事情：用 CLAUDE.md 和 AGENTS.md 定义 AI 的行为框架。知识管理的 Schema 和 Agent 的系统指令，本质上是同一件事。

第三，Markdown 是被低估的人机协议。Karpathy 选择 Markdown 不是因为它技术先进，而是因为它是人和 AI 都能读写的最小公约数。人类用 Obsidian 浏览、AI 用文件系统导航、Git 负责版本追踪，各司其职。这比任何 SaaS 的私有格式都更持久。

至于要不要自己搭一个 LLM Wiki，我会等社区的工程化成熟度再高一些。Karpathy 自己都说了，现在还是"a pile of janky scripts"。但他提出的那个核心问题，对每一个做知识工作的人都成立：

你的知识库，有没有一个不会厌倦的维护者？

但真正用起来以后，问题也会很快暴露出来。只要提问稍微开放一点，比如“昨天的业务指标怎么样”“为什么这个漏斗掉了”“哪个渠道是主要拖累”，原来那套把报表结果透出去的方案就开始卡壳。它不是完全不能用，而是只能回答那些已经被事先组织好的问题。说得更直白一点：它能帮你取数，不能帮你判断。

我这次做完调研后，一个判断越来越明确：AI 不是来替你查报表的，它是在逼企业数据平台重写自己。

真正断裂的，不在接入层，在语义层

很多团队一开始把重点放在接入层，这很正常。先做 MCP，先把 dashboard、report、card 暴露出来，先让 Agent 能调起来，看起来是最顺手的路径。但问题在于，这种做法默认继承了旧 BI 时代的对象模型。它开放的是页面、图卡、筛选器和结果集，这些东西本来就是给人看的，不是给 Agent 做判断的。

人看报表的时候，会自动补上下文。你知道“昨天”默认是自然日还是交易日，知道“业务指标”通常指哪几类，知道某个口径最近刚改过，知道哪张图虽然还能看，但其实已经不该拿去汇报。可 Agent 不知道。你如果没把这些上下文显式做成机器可读的资产，它就只能在海量字段、图卡和长得很像的指标名里自己猜。

“the semantic layer is the critical component to build a bridge between AI and structured data.”

dbt 这句话我觉得非常准确。它点出了一个经常被低估的事实：AI 和结构化数据之间，缺的从来不是连接器，缺的是翻译层。Looker、Snowflake、Databricks 这几条产品线虽然路径不同，但都在强调同一件事：不要让 AI 直接面对物理表，而要让它面对受治理的业务语义。

所以如果今天还把问题理解成“我们要不要开放 MCP”，其实已经偏了。真正的问题不是开不开 MCP，而是 MCP 后面到底接什么对象。如果接的仍然是旧时代的展示对象，AI 最终只是把旧 BI 的局限，用更方便的方式重新暴露了一遍。

AI 时代的数据字典，已经不是说明书了

最近很多人重新开始讨论数据字典，我觉得方向是对的。但如果还是按传统思路去补，最后大概率只会得到一份更完整、却依然主要给人看的文档。

传统数据字典最像设备说明书。字段名、口径、来源、处理逻辑，写得越细越好。对人来说，这当然有价值。可对 Agent 来说，它天然缺一个层次：它没有直接回答“你为什么应该选这个字段，而不是那个也很像的字段”。

真正 AI-ready 的数据字典，不仅要告诉 Agent “这是什么”，还要告诉它“什么时候该用、默认怎么用、不能怎么用、谁对这个结果负责、最近有没有失效、别人通常怎么问它”。

这也是为什么现在不少 metadata 平台都在补 glossary、synonyms、quality、lineage、policy、usage history、verified queries 这些能力。它们不是在做装饰性元数据，而是在做一层机器判断的基础设施。

我觉得这里最容易被低估的，反而是那些看起来没那么“硬核”的能力。比如 synonyms、example questions、reference queries。技术团队天然更重视 lineage、schema、权限，因为这些东西工程味更重。但从 Agent 的真实使用角度看，最容易出错的恰恰是术语映射。业务说“主站赎回金额”，表里可能根本不叫这个名字；一个地方说“新增”，另一个地方说“首贷用户”；一个团队口中的“活跃”默认按天算，另一个团队默认按周算。人能靠经验补齐，Agent 补不齐。

所以我现在更愿意把 AI-ready 数据字典理解成一句话：不是字段说明书，而是企业分析语境的机器化表达。

这轮变化真正被产品化的，不是查数，而是可信答复

这次调研里，一个特别强烈的信号是：行业领先产品已经不再把“自然语言查数”当成核心卖点本身，而是在不断产品化“可信答复”。Snowflake 在做 verified queries，Power BI 在做 human-approved verified answers，ThoughtSpot 在做 analyst coaching。说法不同，但都在指向同一个现实：正确答案不是模型自己悟出来的，而是组织把自己的标准问题、标准答案、标准 SQL、标准语义，持续回灌给系统之后形成的。

这一点很重要，因为它把很多人的直觉反过来了。很多人默认觉得，只要模型越来越强，最终它总会学会这些东西。但企业数据问题不是互联网问答。互联网问答答错一次，最多体验差；企业数据问错一次，可能影响的是经营会、预算决策、风控判断，甚至组织信誉。所以在这个场景里，答得像远远不够，关键是答得可追责。

这也是为什么我越来越不认同“让 AI 自由探索数据库，然后再逐步调优”的路线。这个路径在 demo 阶段看起来很性感，因为它最像真正的智能。你随便问一句，它就能现场拼 SQL、现场出图表，感觉特别聪明。但企业里真正需要的，往往不是这种即兴表演，而是可复用、可审计、可回放、可纠错的标准化答复系统。

真正稀缺的能力，不是多答，而是知道什么时候不该答

我这次最强烈的一个感受是，很多团队在谈 AI 的时候，默认目标还是“尽量多答”。可如果站在企业数据平台的角度看，真正稀缺的能力恰恰不是多答，而是知道什么时候不该答。

以前数据平台面对的是人。人会自己做风险判断。一个资深运营看到一张图不更新，可能会先去问是不是任务挂了；一个分析师发现某个指标突然跳变，知道要先排除埋点或口径问题；一个懂业务的人看到结果离谱，天然会留个心眼。Agent 没这个体感。它没有“感觉不对”，除非你把“不对”的信号做成它能读懂的对象。

所以我越来越认为，未来企业数据平台的核心能力之一，不是智能问答，而是智能拒答。

什么情况下应该拒答？口径未认证，freshness 超过 SLA，质量告警还没消除，结果依赖涉敏字段但当前身份无权访问，语义层没有覆盖到这个问题，只能退回原始 SQL 猜测。真正成熟的平台，不会把“什么都能答”当能力，而会把“在不该答的时候及时停下来”当能力。因为后者才体现出系统已经开始拥有组织判断，而不是单纯拥有语言能力。

数据平台真正该升级的，不是前台，而是控制面

如果把这一轮变化压缩成一句更工程化的话，我会说：数据平台的重心，正在从前台产品迁移到后台控制面。

前几年大家最重视的是前台。报表好不好看，分析平台顺不顺手，自助取数方不方便，主题分析能不能拖出来。这些仍然重要，但 AI 时代的新变量在于，前台不再只有人，Agent 会变成新的主要用户之一。它不会抱怨按钮难点，但会无限放大底层语义和治理的缺陷。

于是，真正稀缺的东西开始变了。以后最值钱的，不一定是谁做出了最酷的问答入口，而是谁先做出了稳定的 Agentic Data Control Plane。这套控制面至少要统一四类对象：语义对象、元数据对象、可信对象和策略对象。只有这些东西统一起来，Agent 才可能在运行时做出像样的判断。否则它永远是在不同系统之间拼 patch。

从这个角度看，很多传统数据平台团队并不是要“转型成 AI 团队”，而是要把自己重新定义成企业判断基础设施团队。你们提供的不只是数据，而是带边界的数据判断力。

哪些东西该先做，哪些东西别急着做

如果把这件事落回现实，我反而不建议一开始追求“大而全的 AI 数据中台”。那很容易变成又一个方向正确、交付很慢、大家都知道重要、但半年后还是只能演示的工程。

更合理的路径，是从高价值主题域开始，先把少量但关键的东西做深。我会优先挑三到五个主题域，比如交易经营、用户增长、投放、风险、资金流转。每个主题域先补齐认证指标、关键实体关系、默认问法、verified queries、freshness 和 quality 信号、policy 和 owner 边界。只要这几个主题域做深了，系统就会开始出现一个很重要的质变：它不再只是到处都能查一点，而是在关键问题上开始稳定可靠。

相反，有些东西不需要太早做。比如一开始就追求通用自治分析，或者一开始就想让 Agent 直接面对全量数据仓库 schema。我觉得这些动作都太像“技术上很过瘾，组织上很危险”。数据平台一旦把风险边界开得太早，后面不是创新跑得快，而是事故来得快。

收束

我越来越觉得，很多团队今天看待 AI 调数的问题，还是太温和了。大家总觉得是在原有平台上补一层能力，给原来的报表体系加一个更自然的入口，给原来的分析平台多一个对话面板。这样理解不能说错，但它低估了这轮变化真正改写的东西。

真正被改写的，不是入口，而是责任。

以前数据平台的责任，是把数算出来，把工具搭出来，把报表发出去。以后这套责任还在，但外面会多一层更难也更值钱的责任：让机器知道什么时候能信，什么时候不能信，什么时候该继续分析，什么时候必须停下来。

一旦机器开始代替人提问，平台就不能只提供数据，它必须开始提供判断的边界。所以我对这件事最后的判断很明确：AI 不是来替你查报表的，它是在逼企业数据平台重写自己。真正要做的，不是把旧系统接给 Agent，而是把企业分析里那些原来只存在于资深分析师脑子里的语义、经验、规则和边界，全部工程化、产品化、机器化。

谁先做到这一点，谁的数据平台才真正进入了 AI 时代。

很多人现在讨论 AI 对软件行业的影响，还是下意识问一句：程序员会不会被替代？我越来越觉得，这个问题问得有点晚了。因为在真正大规模替代写代码之前，组织里的协作结构已经先开始被重写。

AI 这轮先压缩的，不是某个 title，而是研发组织里那些依赖信息差、串行流转和人工协调才能运转的中间结构。

为什么 Block 这个案例值得看

先把事实边界说清楚。Block 的大规模裁员是真的。CNBC 报道里直接写了，裁员规模是 more than 4,000 employees，大约接近公司员工总数的一半。更关键的是，这件事在官方口径里不是简单的“经济不好，降本增效”，而是明确和 AI、和更小更强的团队组织方式绑在了一起。

Block CFO 的表述很直白：公司希望“用 AI 自动化更多工作”，从而“让更小但更强的人才团队跑得更快”。这句话的分量在于，它不是旁观者的评论，而是公司高层自己给出的组织重构逻辑。

再往前走一步，Block 官方那篇《From Hierarchy to Intelligence》更彻底。它不是在说“AI 是一个提效工具”，而是在说：传统 hierarchy 里有一部分协调、对齐、传递、管理的功能，本身就应该被 intelligence layer 接走。它甚至把“no permanent middle management layer”写进了组织设想里。

这就意味着，Block 不是单纯在买更强的 coding tool，而是在尝试用 agent 改写组织的控制回路。

真正发生变化的，不是写代码，而是代码周围那圈人肉流转

过去一个软件需求为什么常常要经过很多层？并不是因为每一层都在创造新价值，而是因为现实世界里有太多断点。需求在产品和研发之间断一次，研发和测试之间断一次，CI 失败和修复之间再断一次，跨团队依赖又断一次。每一次断点，背后都要有人补上：同步状态、传递上下文、催一下进度、解释一下风险、再组织一次会。

所以很多中间层岗位的真实价值，未必是“我做了一个结果”，而是“我让结果能在断裂的系统里继续流动”。

这套东西在前 AI 时代当然成立，因为信息差真的存在，串行等待真的不可避免。但 agent 一旦能自己读 ticket、找代码、开分支、写实现、跑测试、修 CI、看日志，这条链路里大量原本必须靠人传递的动作，就会被收进一个更连续的执行闭环。

Block 工程博客里公开提到，95% 的工程师已经在常态化用 AI，第二大群体已经在并行跑 3 到 5 个 agent 实例。它还描述了一种以前几乎不可能成为日常的工作方式：agent 自己读工单、自己建分支、自己提 PR、自己盯 CI、自己修失败，人类主要在 review 时介入。这个变化不是“写代码更快了”那么简单，而是很多原来需要层层传递的中间动作，开始被压进同一条回路里了。

过去中间层存在的重要原因，是系统不连续；现在 agent 的价值之一，就是把这条链路重新接起来。

所以被压缩的，不是管理者，而是“只做协调的管理者”

我不太认同一种粗暴说法：AI 会先替代 manager。更准确的说法应该是，AI 会先压缩那些主要靠协调存在、却不真正拥有判断与问责权的 manager 职能。

这两者差别很大。

如果一个人的主要工作是：追状态、开会、同步、转述、向上包装、向下分发，那他最危险。因为这类价值本质上建立在信息差和串行流转上。而 AI agent 恰恰最擅长把这部分摩擦打平。

但如果一个管理者真正做的是另外几件事，情况就完全不同了：定义优先级，承担架构后果，拍板资源配置，处理跨团队冲突，扛事故，接审计，做风险接受，给外部合作方和客户兜责任。这里面的核心价值不是“传递信息”，而是“承担后果”。这类角色短期并不会因为 agent 能写更多代码就消失。

所以我更愿意把这件事说成一句更精确的话：被压缩的不是 middle management 这个词，而是 coordination-only management 这种组织形态。

哪些角色更脆弱，哪些角色更稳

如果把岗位 title 暂时放下，只看任务结构，我现在更倾向用五个问题来判断一个角色的韧性。

• 这个任务是不是高度标准化。
• 结果是不是容易自动验证。
• 角色是否承担问责与后果。
• 工作是否依赖跨边界整合。
• 价值是否建立在人际信任与博弈上。

按这个框架看，软件组织里最脆弱的，通常不是“junior”或“中层”这些名字，而是下面这些任务束：大量标准实现、大量标准测试、大量标准运维，以及主要靠状态同步、项目推进、信息搬运而存在的协调工作。

更稳的则是另一类：强 ownership 的技术负责人，平台和架构边界设计者，安全、合规、审计、事故响应这类高责任角色，以及销售、客户管理、合作关系这类高信任密度角色。不是因为 AI 碰不到这些事，而是因为这些事的价值中心不在“产出内容”，而在“对结果负责”。

这也是为什么我不太喜欢那种泛泛的岗位预测。AI 不是按岗位名册裁人，它是按任务结构重新定价。

这件事对技术管理者真正的提醒

很多管理者看到这种案例，第一反应会是：那我要不要重新学写代码？我觉得这只对了一半。

技术管理者当然必须亲自下场用 agent。否则你根本无法判断团队口中的“AI 已经提效很多”到底是事实，还是演示版幻觉。但如果只把结论停在“管理者也得会写代码”，还是太浅。

真正更重要的，是管理者要把自己从“传话筒”升级成“组织设计者”。谁能重写流程，谁能把 repo、上下文、验收标准、约束、审查回路和 agent 编排成新的生产函数，谁就不是被替代的对象，反而会成为放大器。

换句话说，AI 对管理层的要求，不是简单地下沉回执行层，而是上移到更高杠杆的设计层。

也别把社交媒体里的每个数字都当真

这里我觉得也需要克制一点。像“会议减少 70% 到 80%”“某项目从 15 人变成 4 人加 AI”这类说法，传播力很强，但我目前还没看到足够扎实的公开原始出处。能够确认的是，Block 在播客摘要和工程博客里都已经公开呈现了“小团队 + 多 agent 并行”的方向；不能确认的是，这些特别整齐、特别戏剧化的数字已经到了可以当事实引用的程度。

这并不影响大的判断成立，但会影响我们怎么讲。真正有说服力的表达，不需要靠把所有戏剧性数字都照单全收来撑场子。趋势本身已经足够强了。

值得相信的，不是每个传播中的细节数字，而是那条越来越清楚的组织逻辑：小团队 + agent 并行，正在替代大团队 + 层级协作。

最后一句

围绕这篇小红书，我最终更愿意保留的，不是“AI 开始杀职场中登”这种带情绪的说法，而是一个更冷一点、也更能落到组织设计上的判断：

AI 先压缩的，不是程序员，而是研发组织里的信息中间层。

谁的价值主要来自信息搬运、串行协调和流程存在感，谁会先被重估。谁能定义方向、承担后果、处理例外、并把 agent 编排进真实生产系统，谁反而会变得更重要。

这篇文章不是在预测某个 title 会消失，而是在提醒一件更现实的事：软件组织比代码更早进入 AI 重构期。

引用来源

• CNBC: Block laying off about 4,000 employees, nearly half of its workforce
• Block: From Hierarchy to Intelligence
• Block: codename goose
• Block Engineering Blog: AI-Assisted Development at Block
• Block Engineering Blog: How We Red-Teamed Our Own AI Agent
• CoinDesk: Jack Dorsey Says AI Should Replace Corporate Hierarchy
• a16z 节目摘要页：What Happens When a Public Company Goes All In on AI
• Microsoft Security Blog: Securing and governing the rise of autonomous agents
• Microsoft Annual Report 2025
• McKinsey Technology Trends Outlook 2025

这两个问题当然重要，但我越来越觉得，它们都还停留在表层。因为同样一个任务，不同系统做出来的真实成本，根本不是只差一点点。你以为你在为模型推理买单，最后真正烧掉的钱，常常是反复搬运的上下文、命不中的缓存、低价值的工具回路、以及长会话漂掉以后的人类返工。

Agent 时代真正贵的，不是 token 单价，而是低质量编排。

Claude 这次收紧第三方 Agent 框架接入，在我看来，不该只被理解成平台变得更封闭。它更像一次强行记账：把原来被订阅补贴遮住的成本，重新算回系统本身。

这次争议真正暴露的，不是价格，而是浪费

微信那篇文章里转述罗福莉的批评，我觉得最有价值的不是情绪，而是它点中了一种行业通病：一个请求里触发很多轮低价值工具调用，每轮都带着超长上下文，各种历史消息和工具结果反复回灌。这样一来，账单膨胀几乎是必然的。

如果只是单次聊天，这种浪费不一定明显。可一旦你把系统拉长到 Agent 模式，问题马上就暴露了。因为 Agent 不是一问一答，而是一整条执行链。计划、调用工具、改代码、跑测试、修失败、更新状态，任何一个环节设计粗糙，都会把后面的 token 和时间一起拖高。

这也是为什么我越来越不认同一种说法：只要模型再便宜一点，问题就解决了。不是的。便宜模型能降低一部分成本，但它解决不了系统级浪费。一个坏的编排层，挂什么模型都不会变得真正经济。

Anthropic 官方材料其实已经把答案写出来了

如果只看 Anthropic 的 pricing 文档，会发现它最值得注意的地方，根本不是单价表，而是它反复在讲 prompt caching、Batch API 和 tool use overhead。

这背后的意思很清楚：同样一个任务，成本不只是由输入输出 token 决定，还由缓存有没有命中、工具说明有没有做瘦身、动态结果有没有污染上下文决定。

更有意思的是 Anthropic 自己那篇讲 advanced tool use 的工程文章。它里面有一组数字我印象很深：通过 tool search，把工具提示从大约 72K token 压到 8.7K；通过 programmatic tool calling，把平均 token 从 43,588 降到 27,297。

这说明什么？说明真正的降本，很多时候根本不是换模型，而是把系统里不该让模型看到的东西拿掉。把动态结果留在执行层，把工具按需暴露，把稳定前缀留给缓存，这些动作听起来不性感，却直接决定了产品的单位经济。

编排层不再只是“实现细节”，它正在变成产品本身。

以后真正值钱的，不是会接模型，而是会把系统做成

OpenAI 讲 harness engineering 时有一句话很重：Humans steer. Agents execute. 我觉得它最值得咀嚼的地方，不是“人指挥、AI 执行”这么简单，而是工程工作的重心已经挪了。

以前大家拼的是谁写得更快。现在越来越像在拼谁能把环境、规则、记忆、评测和回退机制设计得更稳。长任务不是靠一段巨长 prompt 跑出来的，而是靠一整套 plan → execute → verify → repair 的 loop 才跑得稳。

也就是说，未来真正有护城河的东西，不会只是“我也能调同一个模型 API”。真正的差异化在 orchestrator 里：

• 工具是全量暴露，还是按需加载
• 上下文是无限往下滚，还是分层裁剪
• 缓存是产品里的真机制，还是 PPT 上的能力点
• 失败以后是继续烧 token 碰运气，还是有明确回退和修复路径

这些事情用户看不见，但账单看得见，完成率看得见，团队自己也迟早会感受到。

订阅和 API 的未来，不是二选一，而是分层

这次争议里还有一个被低估的信号：用户真正想要的，并不是“永远用订阅白跑自动化”，而是一个中间态。

GitHub 上有人提议，把订阅和 API 放进统一配额池里，人类交互和第三方 Agent 都从一个预算里扣，用完就 throttle。这种想法为什么反复出现？因为大家已经意识到，纯订阅和纯 API 都各有问题。

纯订阅的问题是太容易把真实成本藏起来。纯 API 的问题是成本太显性，很多人不敢放心把工作流搭上去。更合理的方向，大概率是：

• 日常人工工作流有一个 seat 或 subscription 级的保底额度
• 高频自动化和超额使用走 API 或额外 usage 包
• 不同入口共用统一预算池，防止套利，也逼系统把编排做好

所以我不觉得 Anthropic 这次动作只是“堵漏洞”。它更像是在用价格信号告诉整个生态：以后谁能活下来，不取决于谁最会讲 Agent 的故事，而取决于谁最懂得尊重算力和上下文这两种稀缺资源。

这件事对做平台的人，其实是个提醒

很多公司现在一看到模型变强，就很容易往一个方向冲：把越来越多事情交给通用 Agent，希望它自然长出平台能力。

这条路不是不能走，但我会非常警惕。因为自由度越高，意味着上下文、状态、失败路径和安全负担都会一起膨胀。最后你运营的不是一个产品，而是一个高波动的成本容器。

更稳的系统，往往不是一上来就把一切都开放给 Agent，而是先把大部分确定性 workflow 收好，把规则清楚、边界稳定、结果可验证的部分收进流水线，只把真正需要开放式推理和复杂博弈的那一层留给 frontier model。

这样做的意义不只是省钱，更是为了可预测。一个系统如果大多数时候都在可控轨道上运行，只有少数复杂情况再把智能放出来，它才更像能规模化交付的产品，而不是炫技 demo。

最后一句

我现在回头看 Claude 这次争议，脑子里留下来的已经不是“又一家平台变贵了”这种直觉，而是另一句话：

AI coding 赛道真正的分水岭，不是谁把 token 卖得更便宜，而是谁能在资源约束下，把同一个任务更稳定、更克制、更少浪费地做成。

以后真正能留下来的 Agent，不一定是 context 最长的，也不一定是最会说的，而是最懂得在该省的地方省，在该花的地方花，最后还能把任务做成的那个。

这篇文章不是调研笔记的平铺直叙版，而是我从那份调研里真正带走的判断：算力不再是背景条件，它正在反过来塑造产品哲学。

AI 先生成了二十个人的面试评语。我看完很不满意。不是太严肃，就是太儿戏。后来我没有继续往 prompt 里补一堆形容词，也没有试图一次性把自己的风格解释清楚。我只做了一件更笨、但更有效的事：先手工改四份，然后让 AI 自己去总结我改了什么、为什么这么改，再让它照着这个总结去改剩下十几份。

效果一下就对了。

很多时候，我们以为自己在“给 AI 补要求”，其实已经在做一件更接近偏好学习的事：先用修改动作表达偏好，再让系统去学偏好。

为什么我觉得这件事不是小技巧，而是一条大方向

RLHF 这几个字这些年被讲得很重，像是只有大厂研究团队才能玩。但如果把形式感拿掉，它最核心的那层其实很朴素：不是让人类先写出一套完美规则，而是让人类先表达“哪个更好”。

InstructGPT 那篇论文里，最关键的动作不是模型多大，而是他们收集了人类对多个输出的排序，再把这些排序变成后续训练信号。后来 DPO 又把门槛往下砍了一截，告诉大家偏好优化不一定非得显式训练 reward model，再走完整 RL 流程。

这件事对真实工作非常重要。因为人类通常不擅长提前讲清楚“什么叫恰到好处”，但很擅长在两个版本里挑一个更喜欢的，或者顺手把一句话改到顺眼。

换句话说，真正高价值的反馈，很多时候不是 thumbs up，不是五分制打分，而是编辑动作本身。

编辑动作为什么这么值钱

我现在越来越确信，很多 AI 产品最容易忽略的一种数据，恰恰是最值钱的数据：用户改了什么。

因为它天然同时带着三层信息。第一层是结果偏好。用户把一句话改掉，本身就在说“原版不如这个版本”。第二层是局部归因。用户不是整篇推翻，而是改了某几个词、某几句结构，这等于顺手告诉了你问题发生在哪。第三层是上下文。这个修改不是实验室里的标注，而是发生在真实工作流里，天然带着角色、场景和业务约束。

所以我越来越不相信那种只盯着显式反馈的产品设计。很多用户懒得点赞点踩，就算点了，你也不知道他到底不满意什么。相比之下，修改痕迹的信息密度高得多。它不像一句“写得不好”那么含糊，它已经把“不好”翻译成了具体改动。

Rubric 才是把 taste 变成系统资产的桥

回头看那次招聘评语，我觉得最关键的一步其实不是“改四份”，而是“让 AI 总结我到底改了什么”。因为这一步做的，本质上是把隐性的审美标准外化成一套 rubric。

比如：要具体，不要空泛夸赞；要有人味，但不要油；要指出优点和风险，但不要上价值上得太满；语气要像真 manager 写的，而不是像系统模板。这些东西如果永远只留在人脑里，它就只能靠资深者亲自盯。它不能规模化，也不能稳定复用。

但一旦你把它写出来，很多事都变简单了。你可以让模型按 rubric 自评，让多个候选版本互相比，让 reranker 按 rubric 排序，甚至以后再把这套 rubric 转成训练数据。rubric 的价值，不是让文风更规范，而是让 taste 开始变成外部对象，开始可积累。

不做完整后训练，也完全可以先跑起来

很多团队一听“偏好学习”，第一反应是：我们没有训练能力，也没有那么多标注资源。那是不是只能继续补 prompt？我觉得不是。

Self-Refine 已经证明，不做额外训练，只靠 test-time 的“生成 -> 反馈 -> 改写”循环，也能明显提升输出质量。它给了一个特别现实的启发：反馈不一定非得先进参数层，先进入运行时循环也能产生很大价值。

所以一个非常现实的“人工简化 RLHF”流水线，其实可以很朴素：

• 先抓少量高质量人工修改样本，不求多，先求密度高。
• 让 AI 总结原版和修改版差异，抽出 rubric。
• 后续每次先生成多个候选，再按 rubric 做挑优，而不是一把梭直接终稿。
• 边界样本、风格强样本、低置信度样本，再回给人拍板。
• 失败案例单独沉淀成回归集，让这套 taste 不断被校准。

注意，这整套东西里最值钱的，根本不是某个模型名词，而是那条持续运转的反馈链。它让“这个更像我”的主观感觉，开始变成一个可以被复用、被放大、被自动化的系统输入。

代码评审领域已经给了很强的现实信号

如果你觉得招聘评语还只是文字工作，那代码评审会给一个更硬的现实版证据。

Google 关于 code review comments 的工作 已经说明，reviewer 的自然语言评论本身，就可以驱动模型给出建议修改。这等于默认承认了一件事：评审反馈不是噪声，它本身就是可学习信号。

更进一步，像 CRScore 这类工作开始强调 code review 没有唯一标准答案，更适合用 conciseness、comprehensiveness、relevance 这类维度来评价评论质量。最新的 SWE-PRBench 甚至直接拿 human-flagged issues 去量化 AI review 质量，结果显示今天的 frontier models 仍然离人类 expert 很远。

我对这些工作的解读不是“AI 还不行”，而是另一层：团队的评审 taste 正在从经验沉淀，变成数据沉淀。以前 reviewer 的好坏，更多靠口碑和资历在传。现在，评论文本、最终修改动作、接受率、回滚率，开始都能变成结构化信号。

那注意力轨迹呢

我对“监控审核代码时的注意力轨迹”这件事的判断是：有价值，但更适合作为高成本辅信号，而不是主干监督。

像 关于 PR 情绪理解的眼动研究 已经说明，开发者在 PR 页面上的 gaze 分布是有稳定模式的。评论正文、新增代码、用户名会被看得更多，甚至 emoji 也会获得异常高的注意力。这说明 reviewer 的认知资源并不是随机投放的。

但我不会把这条路吹得太满。眼动数据贵、噪声大、解释难，而且“看得久”并不天然等于“这个地方重要”。所以它更像研究工具和产品优化信号，适合帮助理解 reviewer workflow，或者验证界面设计，而不太像最先该规模化落地的监督主轴。

真正更现实、更低成本、也更容易规模化的主监督，还是这些：reviewer comment 文本、评论后的最终修改动作、多个候选改法里人类最后选了哪一个、哪类问题总被人类盯出来、哪类问题总被 AI 漏掉。

我现在更相信的判断

下一批真正拉开差距的 agent，不是会说得更多的 agent，而是会从这些细小却高密度的人类反馈里，慢慢学会“什么叫更对”的 agent。

所以如果今天让我给 AI 产品提一个最实际的建议，我不会先问“你用了哪个模型”，我会先问：用户编辑后的痕迹你们记了吗？用户挑优的动作你们记了吗？你们有没有把这些动作沉淀成下一轮系统能力？

如果没有，那产品再智能，本质上也还只是一次性生成器。如果有了，它才开始从工具走向会学习的系统。

所以第一次在邵阳看到那种场面，我确实有点愣住。鞭炮被人熟练地围着坟头绕了几圈，引信一点，整片山都是响的。旁边还有烟花，炸开的时候甚至有点像过年。后来我才知道，在当地不少农村地区，扫墓本来就是家族性的大事，鞭炮不只是声响，还是一种通知，一种排场，甚至是一种兴旺的展示。

同样是虔诚，北方更像轻声说话，南方更像开着扩音器说话。

如果只用“谁更文明”去理解这种差异，基本上一定会看错。因为它不是礼貌程度的差异，而是世界观的差异。

同一种敬意，为什么会长成两种样子

我后来把这件事想明白，靠的不是一句民俗解释，而是把不同地方的画面摆在一起看。

山东很多地方扫墓要给坟头添新土，意思是给祖先“修屋顶”，别让夏天漏雨。烧纸也要画圈，圈口朝着坟墓方向，像是给先人开一条专属通道。整个逻辑都很北方：谨慎、克制、讲分寸，甚至有点像在做一件必须庄重完成的家务事。

广东的逻辑就完全不一样。当地把扫墓叫“拜山”，很多地方的标准流程就是清杂草、摆贡品、拜祭、放鞭炮。祭完祖还会有“太公分猪肉”这样的环节，把猪肉分给族人，意思是祖宗的福气要落到活人身上。你会发现，这不是“探望”，而是“请祖先回来一起过事”。

福建更灵活，泉州、漳州、莆田连扫墓时间都不完全跟着清明走，有的挪到上巳节，有的更看重冬至。江浙则把节令感更多放进食物里，青团、菠菠粿这些东西，本身就是一种把祖先、季节和家常生活连起来的方式。湖北、湖南处在南北之间，但在扫墓这件事上明显更偏热闹，尤其宗族性强的地方，清明既是祭祖，也是家族一年一度的再聚拢。

如果一定要压成一句话，我现在更愿意这么说：

北方扫墓，更像去探望一位需要安静休养的长辈。南方扫墓，更像把一位久未归家的长辈请回家里吃顿饭。

鞭炮不是打扰，而是一种沟通协议

理解了这个前提，再回头看“坟地为什么要放鞭炮”，就没那么难了。

民间对这件事有几种解释。有人说是通知祖先来领祭品，有人说是驱赶别的鬼魂，别让供品被“抢走”，还有一种说法更朴素，就是扫完墓后给活人驱驱晦气。三种解释听起来不一样，但底层都一样：鞭炮不是为了表演，是为了传递信号。

在北方语境里，这种信号可能显得太吵了，因为北方默认的假设是“逝者需要安宁”。可在南方不少地方，默认假设恰恰相反：祖先也需要热闹，需要排场，需要知道这一年子孙过得怎么样。你去看望朋友，总不能一句话不说，祖先也一样。既然是请他回来，那就得让他听见。

所以同一个动作，在不同文化假设下，含义可以完全反过来。对山东人来说，太响可能像打扰。对邵阳乡下很多人来说，不响反而像怠慢。问题从来不在鞭炮本身，而在你认定“那边的人”到底更需要什么。

南北差异，不只是风格问题，背后有两千年的分叉

这件事也不是现代人才分出来的。清明本身就是一个混合节日。它早年跟寒食节长期纠缠在一起，而寒食的核心记忆是禁火、冷食、节制。这个基因在北方，尤其山西、河北、山东一带保留得更深，所以北方清明天然带着一点“收着来”的气质。

南方保留下来的则更多是春祭和宗族礼俗的基因。广东、福建、湖南这些地方祠堂文化更强，很多时候扫墓不是一个小家庭的事，而是整支宗族的事。人一多，祭品一丰盛，仪式自然就往隆重走。再叠加南方物产更丰富，三牲、糕粿、聚餐这些东西都更容易进入祭祀系统，整个氛围就更像“办事”。

换句话说，今天看到的“南热闹、北肃穆”，不是谁后来故意设计出来的，而是不同历史传统、宗族结构和生活条件层层叠出来的结果。唐宋以后它们都叫清明，但骨子里保留的底色并不一样。

少数民族的例子会把这个结论再往前推一步。壮族的五色饭、土家族的挂青、满族的插佛托、苗族的生命树，再到维吾尔族和藏族完全不同的祭祀体系，都在提醒我们：中国人面对逝者，从来没有一种单一标准答案。 有人认为要让祖先热热闹闹地回来，有人认为要让祖先安安静静地长眠，也有人根本不靠坟墓去连接逝者。

今天讨论“文明祭扫”，最怕把安全问题偷换成审美问题

这几年各地都在推文明祭扫。鲜花替代烧纸，网络祭扫替代现场祭扫，很多地方也明确禁放鞭炮。从环保和消防角度看，这些规则没有问题，我也完全理解。清明期间山火风险高，这不是可以浪漫化的事。

但我越来越在意另一个细节：当我们说“文明”的时候，究竟在说什么？

如果说的是安全、环保、秩序，那就是公共治理问题。可如果不自觉地把“安静”也一起打包进“文明”，把南方那种热闹、响亮、家族性很强的祭祖方式，一概看成落后、扰民、需要被修正，那其实是在拿一种地域审美去覆盖另一种地域传统。

公共治理当然要解决风险，但不该顺手把文化差异也一起抹平。

更好的做法不是假装差异不存在，而是在承认差异的前提下做约束。哪些地方必须禁火，哪些区域可以设置安全替代，哪些传统可以用电子鞭炮或集中燃放去保留仪式感，这些都比“一刀切”更难，但也更尊重现实。

回到那座山头，我最后想明白的是一件小事

后来我再回想邵阳那座山，已经不太会把“安静”和“热闹”简单对立起来了。

我在坟前沉默磕头，是在和祖先说话。当地亲戚点燃鞭炮，也是在和祖先说话。一个用内心独白，一个用扩音器。音量差很多，频道其实是同一个。

清明最有意思的地方，也许就在这儿。它每年都来，但从来不是同一个清明。你站在哪片土地上，你从哪个家族里长出来，你小时候看惯的是烧纸、添土、挂青、青团、五色饭还是猪头肉，都会决定你觉得“怎样才算敬”。

所以我现在更愿意把问题改写一下。鞭炮绕坟头三圈，是敬还是不敬？我的答案是：先别急着判断，先问一问，在那个地方的人心里，祖先到底是睡着了，还是等着你回来。

写于 2026 年清明。起因是一段真实经历，但真正让我记住的，不是鞭炮声有多大，而是同一种思念，原来可以长成这么不一样的样子。

这个问法当然没错，但它还停留在表层。因为它默认“行业”是分析单位。可真正决定命运的，往往不是行业名，而是这个行业到底靠什么赚钱。

AI 最先压缩的，不是某个行业，而是某一种价值结构。

如果一个业务主要靠信息中转、标准化匹配、流量分发、规则执行赚钱，那它就站在 AI 的正面冲击带上。反过来，如果一个业务主要提供的是情绪价值、身份认同、线下体验、人际互动或责任背书，那它受影响的节奏就会慢很多。

第一类业务：提升中转效率的业务，最危险

我今天举的第一个例子，是基金平台。

基金平台本身并不生产基金产品，它做的是把基金公司的产品搬到平台上，再卖给用户。过去它的价值来自几件事：掌握流量入口、做精细化运营、给用户推荐、让交易更顺一点。

这个逻辑在“人直接访问平台”的时代成立，因为平台掌握入口，也掌握信息差。但当用户面前出现 Agent，这件事就开始变了。

Agent 天生会做三件事：

1. 替用户搜集信息
2. 替用户做初步比较和筛选
3. 优先寻找更短、更便宜、更少摩擦的完成路径

一旦如此，很多中间层会被直接穿透。Agent 不会天然忠于某个平台，它只忠于目标函数。它会问：如果上游产品就在那，为什么还要多经过一层？

基金平台只是一个例子。把视角再拉大一点，保险中介、OTA、招聘撮合、广告投放中间层、内容分发平台，甚至很多“帮用户做选择”的互联网产品，本质上都在回答同一个问题：我到底是在创造真实价值，还是只是在占一个中间位置？

如果答案偏向后者，那在 AI 时代，这类业务就会被重新定价。

第二类业务：提供情绪价值的业务，反而不容易被提效

第二个例子，是游戏。

游戏很有意思。你很难说 AI 能把游戏“优化”到一个更高效的状态，然后用户就更满意。因为游戏不是在卖效率，它是在卖情绪价值。

一个关卡你玩一天通关，和你三分钟通关，从“效率”角度看当然是后者更高；但从“体验”角度看，很可能恰恰相反。很多游戏的价值，本来就来自投入时间、克服挫折、在共同规则下获得反馈。

这也是为什么外挂永远会破坏游戏生命周期。外挂最大的问题不是它作弊，而是它把原本靠人去投入和竞争的东西，改写成了机器之间的执行效率竞赛。

如果所有玩家都默认用 Agent 帮自己刷副本、打排位、做资源管理，这个游戏短期数据可能还好看，长期却大概率会失去意义。因为玩家留在游戏里，并不是为了把一个 KPI 刷满，而是为了和别人一起，在不确定性、公平感和情绪波动里获得满足。

效率价值可以被机器接管，但情绪价值不能靠“更快”来定义。

这个逻辑不只适用于游戏。体育比赛、演唱会、旅游体验、奢侈品消费、高端服务、线下社交场景，很多业务都一样。AI 可以帮它们做后台优化，但不能替它们生产核心价值本身。

真正的分界线，不是行业，而是这五个问题

做完这一轮调研之后，我越来越确信，判断一个行业会不会被 AI 深度改写，不该先问“它是什么行业”，而该先问下面五个问题。

1. 这个行业赚的是效率的钱，还是意义的钱？

如果用户付钱是为了更快、更准、更便宜地完成某件事，AI 通常会很强。如果用户付钱是为了经历、身份、陪伴、成就感、被理解，那 AI 更像辅助工具，而不是替代者。

2. 这个行业的核心任务能不能被标准化？

凡是可以拆成文档处理、信息检索、标准化判断、固定流程执行的任务，都天然适合被 AI 接管。今天最先被重写的，往往不是最“低端”的工作，而是最“可编码”的工作。

3. 这个行业的中间层到底有没有不可替代的价值？

很多平台型业务以前之所以能活得很好，不一定是因为它创造了很强的新价值，而是因为它曾经占住了入口、吃住了信息差、攒起了用户心智。但当 Agent 帮用户把搜寻成本和比较成本都打下来之后，这些旧优势会迅速贬值。

4. 这个行业最后交付的是不是必须在线下完成？

餐饮、酒店、医疗照护、养老、旅游服务这些行业，AI 会重写后台，却不太可能在短期内替代最后一米交付。因为 intelligence 是一回事，physical execution 是另一回事。

5. 这个行业出了问题以后，责任能不能交给机器？

医疗、法律、金融这类行业，会被 AI 深度改造，但不会被轻易替代。原因不是这些行业不会被提效，而是出错后必须有人承担责任、给解释、接审计、兜风险。用户真正买的，往往不是一个答案，而是一层可追责的背书。

所以未来行业大概会分成三类

第一类：被压缩

这类行业的共同点是，中间层价值大于真实价值。它们看起来很忙，流程很多，运营很重，但很多动作本质上只是把信息搬来搬去，把标准化流程跑一遍。AI 一进来，链路会迅速缩短。

第二类：被重构

这类行业内部有大量可自动化任务，但整条价值链不会消失。银行、软件、生命科学、医疗、法律、咨询大多属于这一类。AI 会替它们重写工作流、重写岗位能力模型，但人仍然在回路里。

第三类：被增强

这类行业的核心价值仍然由人来提供，AI 主要在后台提升效率。比如高端服务、旅游体验、演出、体育、游戏核心玩法、社群型教育、儿童和老人照护。AI 让系统更顺，但用户买单的理由仍然是人。

这件事对公司最大的提醒，不是“赶紧接 AI”

很多公司现在谈 AI，还是停留在一个很浅的层次：能不能降本，能不能提效，能不能给现有流程打一层智能补丁。

当然这很重要，但还不够。更重要的是先搞清楚：我们现在赚的，到底是哪一种钱？

• 如果赚的是信息差的钱，那要小心 Agent 直接抹平信息差。
• 如果赚的是流程中转的钱，那要小心 AI 把流程压平。
• 如果赚的是流量分发的钱，那要小心入口从 App 迁到 Agent。
• 如果赚的是情绪、关系、身份、责任的钱，那要考虑怎么把这些价值进一步做深，而不是只盯效率。

真正稳的公司，未来大概率都得至少占住一件事：控制真实供给、控制信任责任、或者控制情绪与社群价值。

最后一句

这轮调研做完，我脑子里留下来的不是“AI 会影响多少岗位”这种统计口径，而是一句更直接的话：

AI 最先吃掉的，不是某个行业，而是那些只是在帮别人做信息搬运和规则执行的价值幻觉。

反过来，AI 最难替代的，也不是简单的“线下”或“创意”，而是那些必须由人来完成意义确认、关系建立、责任承担和情绪交换的环节。

所以以后再看一个业务，我可能会先问一句：它到底是在帮用户提高效率，还是在帮用户获得意义？这个问题，比“它是不是 AI 行业”重要得多。

这篇文章写于一顿午饭之后。它不是完整调研报告的缩写版，而是我从那份调研里真正提炼出来的一个判断框架。

校招选人，特质（Trait）比技能（Skill）重要得多。

这话说起来像老生常谈，但放在 2026 年的背景下，它的含义发生了根本性变化。

一个反直觉的数据

Korn Ferry 在 2026 年初做了一个覆盖 1600 名全球人才获取领导者的调研，结论是：73% 的 TA Leaders 把批判性思维列为第一招聘优先级，而 AI 技能仅排第五。

这个排名让很多人意外。CEO 和董事会通常认为 AI 技能是第一优先级，但每天面对候选人的一线招聘负责人，给出了完全不同的答案。

Korn Ferry 的解释很直接：

"Anyone can learn to use ChatGPT in a few weeks. But knowing when it's giving you unreliable information? Spotting the difference between helpful insights and convincing but flawed output? That requires critical thinking. Most people can learn AI in less than a month. Developing critical thinking? That takes years."

学会用 AI 工具，几周就够了。但判断 AI 什么时候在给你一个"看起来很对但其实有问题"的答案？这需要批判性思维，而批判性思维需要数年培养。

哈佛商学院的研究进一步佐证了这一点——将近 80% 的"特定技能薪资溢价"，其实依赖于底层的基础能力：阅读理解、口头表达、批判性思维、领导力和团队协作。技能是叶子，特质是根。叶子可以长出来，根坏了就全完了。

企业真正需要的人才长什么样

综合 WEF、MIT Sloan、麦肯锡、Anthropic 等多个来源，我试着画一个更清晰的画像。

WEF 2025 年对 2030 年核心技能的预测，传递了一个清晰信号：增长最快的 10 项技能中，只有 3 项是纯技术技能，其余 7 项全部是人类认知和特质类技能——创造性思维、韧性与敏捷、好奇心与终身学习、领导力与社会影响力。

MIT Sloan 对美国约 950 种职业、19000 项工作任务的逐一评估后，结论更加直接：AI 最不可能替代的任务，恰恰是那些依赖同理心、判断力、伦理和希望等"人类独有能力"的任务。

如果要给 AI 时代的人才竞争力写一个公式，我会这样写：

AI 素养（Baseline）× 批判性思维（Multiplier）× 跨学科整合力（Differentiator）× 人类独有特质（Moat）

AI 素养是入场券，不是比谁会用更多工具，而是理解 AI 的能力边界、能设计人机协作的工作流、能验证 AI 的输出质量。但真正拉开差距的，是后面三项——它们很难在短期内训练出来，也很难被 AI 伪造。

各岗位到底变了什么

变化最剧烈的是开发岗。有人在 Dev.to 上写了一句话，我觉得比任何长篇分析都精辟：

"The most valuable skill in 2026 isn't writing code. It is deleting it. Writing code is creation. Deleting code is judgment."

写代码是创造，删代码是判断力。腾讯超 90% 的工程师已经在用 AI 编码，GitHub 数据显示 80% 的新开发者第一周就开始使用 Copilot。当 AI 替你写了大部分代码，工程师的核心价值就从"能写"变成了"能判断"——系统架构怎么设计、AI 生成的代码哪里有坑、什么该留什么该删。

产品经理的变化同样深刻。传统 PM 的思维是"输入 A → 输出 B"，AI 时代的 PM 面对的是"输入 A → 输出 B/C/D"。核心任务不再是定义功能，而是构建一个能持续收敛、可评估、可干预的智能系统。中国 AI 产品经理岗位需求同比增长 240%，但 88% 声称在用 AI 的企业里，真正实现规模化变现的不足 7%。缺口不是"懂 AI 的人"，是"既懂 AI 又懂业务还能落地"的人。

运营岗最值得关注的变化是从 SEO 到 GEO（生成式引擎优化）的范式转移。AI 搜索用户渗透率已突破 78%，经过 GEO 优化的内容被 AI 引用的概率提升 8 倍。运营需要理解不同 AI 的"性格"——DeepSeek 注重事实准确性，豆包偏好通俗解答，Kimi 擅长长文本。这不是"学一个新工具"的问题，是整个内容策略的底层逻辑在变。

一个跨岗位的共同趋势：纯执行技能在贬值，问题定义能力在升值。"实现什么（What）"比"如何实现（How）"更稀缺。AI 编排能力正在成为类似当年 Excel 一样的基础技能——不会用，等于职场文盲。

校招面试的现实：作弊已成"新常态"

但选人之前，先要面对一个不那么光鲜的现实。

Fabric 平台对 19368 场面试的分析显示：38.5% 的候选人表现出作弊迹象。2025 年下半年，作弊率从 15% 飙升到 35%，半年翻了一倍多。

作弊工具已经形成了成熟的生态：Cluely（每月 20 美元）、Interview Coder、Final Round AI……提供隐形屏幕覆层、实时代码生成、音频转录加答案生成。Gartner 预测到 2028 年，四分之一的候选人资料将完全是 AI 伪造的。

简历同质化同样严重。有面试官在牛客上吐槽："面试的应届生多了之后，大家好像都没什么个性，简历上写着相似的项目，按相似的模板回答问题，再按相似的套路反问面试官。"

这是一个结构性的矛盾：AI 让候选人和简历都变得更"完美"了，但面试官反而更难看到真实的人。

怎么面试才有效：六个策略

既然作弊防不住，与其死盯对抗，不如换一种思路——设计让 AI 辅助失效的动态评估环境。几个我觉得特别有用的策略：

1. 动态追问，不给 AI 反应时间

静态、可预测的问题是作弊工具的温床。一旦候选人给出一个打磨得很漂亮的回答，立刻追问具体场景、追问失败经历、要求换一个上下文重新解释。作弊工具没法处理这种节奏。

2. "三层面试法"：结果 → 行为 → 动机

第一层问"你做了什么"，第二层问"你具体怎么做的、遇到什么困难"，第三层问"你为什么选这个方案而不是另一个"。第三层是区分度最高的——AI 可以帮候选人回答 What 和 How，但很难伪造 Why 背后的真实决策逻辑。

3. Knowledge Cutoff 钓鱼

捏造一个不存在的技术概念或框架版本，观察候选人反应。AI 工具可能生成自信的虚假回答，真正有经验的人会坦率地说"没听过"。

4. 现场实操，看过程不看结果

技术岗 live coding 加实时讲解思路。重点不是最终的代码对不对，而是候选人的思考路径——他怎么拆解问题、怎么决定从哪里开始、遇到卡壳怎么应对。

5. 追问失败经历

让候选人描述项目中最大的失败和学到了什么。AI 很难伪造一个逻辑自洽、细节丰富的真实失败经历。真的做过的人，讲起失败时的情绪和细节是装不出来的。

6. 麦肯锡范式：从"防 AI"到"测 AI 协作"

这是我认为 2026 年最值得关注的面试创新。麦肯锡不再对抗 AI，而是要求候选人在面试中使用它内部的 AI 工具 Lilli，然后评估候选人怎么向 AI 提问（问题设计能力）、怎么解读 AI 的回答（批判性思维）、怎么将 AI 输出放入业务场景（判断力和上下文理解力）。

评估的不是"能不能用 AI"，而是"用 AI 的方式暴露了什么"——好奇心、判断力、以及对 AI 边界的真实理解。

大厂都在怎么抢人

看看 2026 届校招的数据，能感受到这场人才战争有多激烈。

百度发了 4000 多个 offer，AI 岗位占比超 90%。字节的 Top Seed 计划面向博士生开出日薪 2000 到 5000 元的实习薪资。阿里星计划允许面试通过后反选项目和团队。快手的快 Star-X 计划年薪不设上限，已经开出过超 200 万的 offer。

海外更夸张。Meta 为了挖顶级 AI 研究员，单人 4 年薪酬包开到 3 亿美元。Databricks 的 VP 说了一句话："寻找 AI 人才就像寻找勒布朗·詹姆斯，全球能构建前沿 AI 模型的人不超过 1000 人。"

但薪资分化也极度剧烈——顶尖人才计划年薪 200 万，普通 AI 测试岗月薪 8500 元，差距 20 倍。这不是一般的两极分化，是K型分化：同样叫"AI 岗"，塔尖一将难求，塔底竞争惨烈。

更值得注意的变化是：AI 候选人不愿意和 HR 沟通，要求直接和技术负责人对话。这倒逼大厂技术专家大量下场做招聘。字节 Seed 邀请豆包视觉负责人做候选人的定制导师。校招的形态本身也在被重塑。

一个值得警惕的趋势

所有的热闹背后，有一个趋势让我真正担忧。

Fortune 500 的高管调研揭示了一个深层危机：AI 自动化了入门级的"grunt work"——那些重复性的基础工作，恰恰是培养深度思考能力的传统路径。金融和法律行业的新人，以前要靠做大量"苦力活"来积累行业认知和判断力。AI 把这层活干了，新人成长的阶梯被抽掉了。

"If AI is sort of replacing the entry-level typical positions, and I need people sort of in the middle, how do I prepare the future middle if I don't give them that ability at the base?"

如果入门级工作被 AI 替代了，中层管理者从哪里来？这不是一个校招问题，是一个人才供应链的结构性问题。企业如果不重新设计新人培养路径，几年后会面临中层断层。

麦肯锡对此给了一个反直觉的答案——重新优先考虑文科毕业生。理由是文科生拥有更多"真正新颖"的思维方式，能做出 AI 模型无法实现的"非连续性逻辑跳跃"。Anthropic 联合创始人 Daniela Amodei（文学专业出身）也持同样观点：那些让我们成为人类的特质——沟通力、情商、好奇心、善良——在 AI 时代会变得更重要，而不是更不重要。

我的结论

做完这轮调研，我对校招选人的判断浓缩成五句话：

1. 重新定义岗位：从 Skill-based 到 Trait-based。在 JD 里明确列出期望的特质——好奇心、韧性、判断力、学习敏捷性，而不是只列技术栈清单。
2. 升级面试流程：引入"三层面试法"+ AI 协作测试。放弃标准化技术问答，转向动态追问。对高潜力候选人，参考麦肯锡模式，测试与 AI 协作的能力。
3. 降低学历权重，提升实战权重。前程无忧数据很清晰：企业招 AI 应届生时，实际项目经历（52.5%）远比名校学历（28.8%）重要。有大厂实习的 985 本科生比无实习的清北硕士更受欢迎。
4. 实习是最好的面试。从集中校招季转向全年持续招聘。实习期本身就是最长、最真实的面试。
5. 拥抱 AI，不要对抗 AI。面试防作弊是必要的，但更前瞻的做法是把"AI 协作能力"纳入评估维度。一个能高效使用 AI 并知道何时质疑 AI 的候选人，比一个"纯靠自己"的候选人更有价值。

回到开头那句话：AI 时代的校招，不是在找"最会用 AI 的人"，而是在找"AI 无法替代的人"——然后确保这些人也会用 AI。

这两件事缺一不可。只有第一个，你招了个不会用工具的理想主义者；只有第二个，你招了个 AI 的操作员。真正的人才，是两者的交集。

调研基于 WEF、Korn Ferry、MIT Sloan、McKinsey、Forbes、Anthropic、前程无忧、BOSS 直聘等 60+ 中英文权威来源，全文调研报告留在内部归档。

这种感觉很像软件工程里的打地鼠。你把一个洞堵上，另一个洞又冒出来。于是大家自然会想到一个办法：维护错题集，把踩过的坑一条条记下来，下次执行前一股脑塞给 AI，看起来就会越来越稳。

但真正跑下来，我越来越怀疑，事情没有这么简单。

很多时候，错题集确实能修掉一个局部问题；可当它开始越积越厚，系统反而会出现一种奇怪的退化：原本主任务并没有更清楚，约束倒是越来越显眼。最后 AI 的状态，不像是在努力完成任务，更像是在努力别犯错。

这类系统最容易发生的偏移，不是“不会做”，而是“把注意力从目标转移到了约束”。

错题集的问题，不在于它是错的，而在于它会慢慢抢走主语

我觉得这里最重要的一点是，模型并不会天然把你给它的信息分成两栏：左边是“真正要完成的任务”，右边是“顺手看一下的防错提醒”。对它来说，所有信息都在同一个上下文窗口里竞争注意力。

所以，当你不断补：别忘了这个、不要漏掉那个、上次这里错了、那个页面不能只本地生成、这个链接不能只测 200、那个样式不能跑偏……你当然是在提升系统的防错意识，但你也在同步制造另一件事：目标本身在上下文里被稀释了。

换句话说，错题集不是没有价值，而是它每长一层，都会和主任务争夺一次显著性。

这也是为什么很多人会有一种很强的体感：约束越多以后，AI 开始显得“很努力”，但做出来的东西并没有更完整。它可能记住了不能只停在本地页面，却忘了首页入口还要更新；它可能记住了要上线，却忘了文章风格不能像调研报告；它可能记住了要自测，却没意识到自测的目标不是 URL 打开，而是线上内容真的正确。

看起来像是它不够聪明，实际上更像是上下文里的重心变了。

很多“新问题”，一半是旧问题终于暴露了，另一半真的是约束把系统带偏了

这里我不想走一个太轻松的结论，说“都是因为约束太多”。那也不准确。

更真实的情况是，通常两个原因同时存在。

第一种，是以前的“没问题”只是一种假象。比如之前根本没检查线上是否真的生效，只看本地目录里文件在不在；又或者之前文章风格没被认真比对，所以格式差异其实早就存在，只是没被拿出来当问题。你一旦开始加严格规则，相当于也在提高观测精度，很多历史遗留问题会同时浮出来。

第二种，才是这次讨论真正点中的核心：当负面约束不断堆高时，AI 的注意力确实会从“我要把这件事做成什么样”转向“我不能再踩哪些坑”。这个过程并不是非黑即白的崩坏，而是慢慢发生的。到某个点以后，系统的整体表现会从“完成任务”变成“规避失败”。

这两个原因叠在一起，就会形成最让人头疼的局面：你一边觉得系统更受控了，一边又明显感觉它没有更会做事。

真正该补的，不只是限制，而是“什么叫完成”

今天这轮讨论里，我觉得最有价值的启发，是有人提到一句很关键的话：当约束变多之后，你必须在“什么叫任务完成”上，补同等级别的规范，避免彼长此消。

这句话非常重要。因为大部分 prompt 或 skill 之所以越调越怪，不是因为限制不够多，而是因为“完成定义”太弱。

很多任务写起来，表面已经很清楚了。比如：“调研这个主题，按我的文风调整一下，发到我的个人网站随笔栏目。”

人看起来觉得毫无歧义，但对系统来说，其实有很多关键环节都没显式化：

• 文章是写成调研报告，还是写成网站原生随笔？
• 发布是指生成 HTML，还是同步到线上真实目录？
• 首页要不要新增随笔入口？
• 线上 URL 返回 200 就算完成，还是必须包含正确标题和新正文？
• 样式只要能看就行，还是必须和既有随笔模板一致？

如果这些定义不明确，AI 就只能从最容易达成的表面动作里猜一个“差不多完成”。于是本地文件生成了，也可能被它当成“已经发布”；URL 能打开，也可能被它当成“已经上线”；页面有内容，也可能被它当成“风格已经对齐”。

所以真正有效的做法，不是继续补“不要这样”，而是把完成标准写成一条清晰的正向链路：做到哪些可验证的状态，才算真的完成。

官方文档其实也在说同一件事：不要只说别做什么，要说该怎么做

我去翻了一圈公开资料，发现这件事并不是少数人的体感，而是现在主流模型厂商都在用不同方式提醒开发者。

OpenAI 在 prompt engineering best practices 里有一句非常直接的话：与其只说不要做什么，不如告诉模型应该做什么。这个建议看起来很朴素，但背后其实是同一个逻辑：负面约束只能减少部分坏行为，正向路径才会真正塑造任务完成方式。

Anthropic 讲 agent workflow 时也在强调类似的原则：复杂任务不要默认压成一个越来越大的总 prompt，而应该拆成更简单、可组合、可验证的工作流。因为一旦任务变复杂，真正可靠的不是“再补更多说明”，而是增加清晰的步骤、gate 和 evaluator。

这让我越来越相信，很多人今天遇到的所谓“prompt 越调越重”，本质上已经不是 prompt 工程问题，而是 workflow 工程问题。你不再是在润色几句话，而是在给系统补任务结构。

与其写更厚的错题集，不如把关键节点变成 gate

我现在越来越明确的一个倾向是：能程序化验收的，尽量不要只靠语言提醒。

比如“发布完成”这件事，如果你只是写一句“记得发布到线上并自测”，它对模型来说还是一句抽象话。可如果你把它变成一组 gate，事情就完全不同了：

• 检查生产目录里是否存在对应文件；
• 用 curl -I 看 URL 是否返回成功；
• 用 curl -s 检查页面标题是否正确；
• 用 curl -s 检查正文是否包含新文章的独特句子；
• 再检查首页是否已经出现入口。

这时候系统不再是在“理解一句提醒”，而是在经过一个明确的完成门槛。门没过，就是没完成。这样做的价值非常大，因为它把“经验性的防错”变成了“结果性的验收”。

很多时候，AI 真正需要的不是第 12 条注意事项，而是一个明确会失败的检查点。

再往前一步，很多 skill 问题其实是 harness 问题

我最近一个很强的感受是，很多团队一旦发现 AI 做事不稳，第一反应就是继续打磨 skill。本能上这当然对，因为 skill 最直观、最容易改。但改着改着就会发现，skill 越来越像一个补丁层：这也要交代，那也要补充，最后整份东西越来越厚，像一部谁都不敢删的大工作流剧本。

这时候就该问一句：这些复杂度，真的都该放在 skill 里吗？

很多问题其实是更上层的系统问题。比如：

• 哪些信息应该进长期记忆，而不是每次重复塞进 prompt？
• 哪些行为应该由 runtime 默认保证，而不是靠每次提醒？
• 哪些结果应该通过 eval 和 gate 判断，而不是靠模型自觉？
• 哪些异常应该在工具层兜底，而不是在 skill 文本里补说明？

如果这些东西不分层，系统就会形成一种非常典型的补丁循环：面多了加水，水多了加面。最后看起来像是 skill 在变复杂，实际上是在用 skill 替整个 harness 补洞。

真正成熟的系统，不是把复杂度都塞进一个 skill，而是把复杂度放到正确的位置。

我的结论很简单：每增加一层约束，就要同步增加一层完成定义

如果把今天这件事压缩成一句可执行的话，我会说：

每增加一层防错约束，就要同步增加一层“什么叫完成”的正向定义，最好再配上对应的验收 gate。

因为约束和目标不是两张彼此独立的清单，它们会在同一个上下文里竞争。你只补约束，不补完成定义，系统就会越来越偏向规避失误；你只补完成定义，不补关键错误历史，又会不断重复踩坑。真正稳的状态，是两边一起长，但完成定义必须越来越具体，验收门槛必须越来越硬。

所以我现在不太相信“错题集写厚一点就会更稳”这种简单线性逻辑了。更准确的说法是：错题集有用，但它只能减少重复犯同一类错；如果没有同等级的目标表达、完成定义和 workflow 骨架，它迟早会把系统从做成事，带到少犯错。

而一个真正好用的 AI 系统，最终评判标准从来不是“看起来很听话”，而是“能不能稳定把事情做完”。

参考来源

• OpenAI：Best practices for prompt engineering with the OpenAI API
• OpenAI Docs：Prompt engineering
• Anthropic：Building effective agents
• LangChain：Context Engineering

如果只从 demo 观感看，它像是一个“排版效果很厉害”的库。但我认真把它的 README、研究日志、benchmark 和 demo 结构都过了一遍以后，我的结论是：Pretext 真正厉害的，不是做了几个酷炫 demo，而是它把浏览器里最麻烦的一类能力——多行文本测量与换行布局——从 DOM 黑箱里抽了出来。

Pretext 的本质，不是一个排版组件库，而是一层“文本布局引擎化”的基础设施。

Pretext 到底在解决什么问题？

浏览器里很多复杂 UI 做不顺，卡点不在“画不出来”，而在“你没法提前知道文字会占多少空间”。

传统前端处理文本高度，往往要么靠猜，要么先把文字插进 DOM，再用 getBoundingClientRect()、offsetHeight 之类的方法去量。问题是，这些读取会触发布局回流。更糟的是，一旦你的页面里有很多组件都在“写一点 DOM → 读一下高度 → 再写一点”，浏览器就会进入经典的 layout thrashing：读写交错、整页反复重排。

Pretext 的做法很干脆：不要在热路径里问 DOM。 它把流程拆成两步：

1. prepare(text, font)：先对文本做一次分析、分段、测量、缓存。
2. layout(prepared, maxWidth, lineHeight)：之后每次只用纯算术去推导这个宽度下有几行、多高。

这意味着，昂贵的工作被前置，热路径只剩下非常便宜的重算。官方当前快照里，500 段文本批量处理时，prepare() 大约是 18–19ms，但 layout() 只要 0.09ms；相比 DOM interleaved 的写读交错方案，Chrome 下快出约 480 倍，Safari 下甚至是数量级更大的优势。

它为什么会让人觉得“demo 特别惊艳”？

因为 Pretext 解决的不是单点性能，而是把原本不能实时做的事情，变成了“可以每帧都做”。一旦你能在 60fps/120fps 的交互里不断重算文字布局，很多以前只存在于 print、native 或者昂贵定制系统里的效果，就会突然落到普通前端开发者手里。

1. 它让“文字”从黑箱，变成可编排对象

普通 Web 开发里，文字往往是盒模型的一部分：你给它一个容器，它自己往下流。你知道最终结果，但不掌控中间过程。Pretext 提供了 layoutWithLines()、walkLineRanges()、layoutNextLine() 这些 richer API 后，开发者开始能拿到“每一行是什么、宽多少、从哪里到哪里”。这就意味着文字不再只是 DOM 里的内容，而是变成了可被程序路由的东西。

2. 它不是只优化高度预测，而是在打开自定义排版

README 里列得很直白：它支持 DOM、Canvas、SVG，未来还准备支持 server-side。也就是说，Pretext 不是只想做“测量优化”，而是想成为手动布局文本的底层能力。比如：

• 同一段文本，每一行宽度都不一样，绕开图像、头像、浮动物、异形区域。
• 先算出最紧凑的宽度，再生成“刚刚好”的对话气泡。
• 在不知道真实 DOM 高度前，就提前给 masonry / virtualization 计算卡片占位。
• 在富文本里让 chip、code、inline tag 保持整体，同时正文继续自然换行。

这也是为什么官方 demo 给人的感觉不是“一个更快的工具库”，而是“浏览器忽然拥有了新的设计语言”。

3. 它把文本能力从 CSS 委员会节奏里解放了一部分

Cheng Lou 在自己的 thoughts 里写得很直白：如果 userland 对文本有更强控制力，很多 CSS 规范复杂度其实都可以不必继续膨胀。这个判断我非常认同。过去很多布局表达力之所以难，不是因为渲染做不到，而是文本仍然被关在浏览器原生布局黑箱里；你一旦想“拿回控制权”，就会立刻遇到性能与准确性问题。

Pretext 的战略意义就在这：它不是在扩充 CSS，而是在告诉大家，有一类文本布局能力，其实可以下放到 userland，并且性能还足够好。

Pretext 厉害在哪里？我觉得核心有五层

第一层：把最贵的问题换了个位置

很多系统优化失败，不是算法不够巧，而是把昂贵工作放在了交互热路径里。Pretext 最关键的设计不是“怎样更准”，而是先把问题重构成：一次准备、多次便宜重算。这个思想跟很多现代系统工程非常像——不是局部提速，而是重排成本结构。

第二层：它没有为了快，牺牲国际化

这点非常关键。很多文本相关库一旦强调性能，就会默默退化为“英文 + 拉丁字母 + 少量 emoji”的世界。但 Pretext 明确做了大量 i18n 工作：用 Intl.Segmenter 处理 CJK、Thai、Arabic 等脚本；为 bidi、emoji、软连字符、tab、preserved spaces、不同脚本的标点黏连做了大量工程修补；并维护了跨 Chrome / Safari / Firefox 的浏览器精度基线。

它的 research log 里最打动我的一点，是它不是靠“一套聪明公式”赢，而是非常老实地围绕浏览器行为做长期校准：哪些方法试过但失败、哪些脚本是 canary、哪些 browser-specific shim 值得保留、哪些看起来优雅但会拖慢热路径的方案必须回滚。

第三层：它把“文本测量”变成了 AI 友好的能力

这件事很多人可能还没意识到。现在 AI coding 最容易做出来的是“看起来像页面”的东西，最难做的是“真正把交互细节、空间关系、文本约束处理对”。Pretext 让很多文本相关判断不再依赖浏览器黑盒试错，而可以直接在代码与计算层面完成，比如：

• 按钮文案会不会换行；
• 某个卡片在当前宽度下应该占多高；
• 两栏排版里标题绕开图形后每行该怎么走；
• 富文本块在缩放或拖拽时何时重算布局。

这会极大提升“模型生成 UI → 自动验证 → 自动修正”的闭环质量。换句话说，Pretext 不只是前端工程提效工具，也是未来 agent 做设计实现时的一块新地基。

第四层：它打开的是一整类新 UI，不是单个组件

好的基础设施常见的标志，不是“它自己很强”，而是“它让很多此前不值得做的东西变得值得做”。Pretext 正是这样。它 unlock 的不是一个聊天气泡、一个排版 demo，而是一整类以前因性能/复杂度被压住的界面形式：

第五层：它其实在逼问浏览器的一条边界

Pretext 让我强烈感受到的一点是：前端过去很少把“文字”当作一个可编排的几何系统来对待。图形、动画、粒子、3D、shader，大家已经很习惯自己接管；但一到文本，马上又退回 DOM/CSS 默认流。Pretext 某种意义上是在挑战这个默认：如果我们能自己拿到足够接近浏览器真值的文本几何能力，浏览器上的 UI 创作边界会往外推很多。

但它也不是魔法，它的边界非常清楚

这恰恰也是我喜欢它的地方：它不是一个乱许愿的项目，而是非常诚实地定义了自己的适用面。

• 它当前面向的是常见文本配置：white-space: normal、word-break: normal、overflow-wrap: break-word、line-break: auto。
• 它明确提示：macOS 上 system-ui 不安全，最好用具名字体。
• 它不是完整 font rendering engine，很多问题仍是“尽量贴近浏览器”而不是取代浏览器。
• 它现在最强的是“测量与布局”，不是编辑器级富文本系统、也不是完整 typography 排版标准实现。

这意味着，Pretext 更像是一个高价值的“中间层引擎”：介于浏览器原生黑箱和全自研渲染栈之间。这个位置其实非常聪明，因为它不需要把整个问题吃下来，就已经足以改写很多场景的成本结构。

如果文字渲染能力真的提速这么多，会对哪些领域产生重大影响？

我觉得最值得看的，不是“现在已有谁能用”，而是“哪些原本被文字拖慢的系统，会因此换一种设计方式”。

1. 聊天、社区、信息流产品

这是最直接的一层。消息列表、评论楼、卡片流、瀑布流、本质上都是“海量文本块 + 动态宽度 + 滚动稳定性”的问题。如果高度能在渲染前准确得出，就意味着：

• 虚拟列表更稳，不必先渲染再修正；
• 图片懒加载和文字加载时，scroll anchoring 更容易控制；
• 聊天 bubble 可以更像 iMessage/Telegram 那样“刚刚好”；
• 移动端复杂 feed 的重排成本会显著下降。

2. AI 生成页面与 agent 自动实现

未来 AI 做网页，最常见的问题之一其实不是“不会写 HTML”，而是“不会处理动态内容进入后真实会发生什么”。标题长一点、按钮文案变了、语言切到德语、卡片里塞了一个 badge，页面就全乱了。Pretext 会把一部分这类问题从“等页面渲染出来再看”变成“在生成和验证阶段就能算”。这会让 agent 的 UI 自修复能力大幅增强。

3. 在线阅读、知识产品、富文档体验

今天 Web 上很多文档系统本质上还是一条标准长文流。不是因为设计师没想法，而是复杂排版的工程成本过高。Pretext 一旦成熟，真正有机会影响的，是 Web 端的“轻编辑型阅读体验”：障碍物绕排、可视化批注、动态摘要块、图文混排、可折叠注释、响应式多栏等。

4. 浏览器里的游戏 UI 与叙事系统

这个方向我觉得被低估了。很多游戏 UI 的底层痛点并不是 shader，而是文字：对白框、状态栏、日志、技能描述、任务树、tooltip、对话分支、动态气泡、聊天室、世界说明。这些一旦能用更低成本实时布局，游戏叙事层的表现力会明显提升。尤其在浏览器环境里，这是一块长期被“DOM 不适合、Canvas 不方便、自己做太贵”夹住的区域。

5. 设计工具与前端生产工具

从 Figma-like 设计工具，到可视化搭建器、智能排版助手、演示文稿工具、简报生成器，凡是需要“先知道文本几何，再决定其他对象怎么摆”的系统，都会受益。因为文字一旦可以被稳定测量，很多布局决策就可以前移，不再是结果导向的补丁。

最有意思的延伸：如果把 MUD 和这种动态图形渲染结合，会发生什么？

你提到的这个想法，我觉得非常有感觉，而且不只是“有趣”，是有潜力形成一类新的浏览器原生媒介。

MUD 本质上是高度依赖文字的交互世界：房间、物品、状态、动作、叙事、社交，全都在文本里展开。它的强大之处，是状态空间巨大、世界响应快、内容生产成本低；它的弱点，是视觉回报太弱，所以很多现代用户进不去。

而 Pretext 这一类能力，恰好在补 MUD 的另一半：不是替代文字，而是让文字和动态图形开始更紧地耦合。

一个我能想象的形态：Text-native 世界，而不是 text with images

过去很多“文字游戏 + 图像”尝试，实际上只是给文本套一层插画外壳。真正有意思的方向，是让图像、空间、粒子、动态 UI 都从文本状态里实时长出来。比如：

• 房间描述不是固定背景图，而是根据当前叙事状态实时布局成一个可呼吸的视觉场景。
• 角色台词、系统提示、环境音感知、物品说明，不只是文字块，而是有位置、层次、流向、碰撞关系的界面元素。
• 战斗或社交不是传统 HUD，而是文本行本身变成动画、涌现、聚合、消散的视觉事件。
• 世界地图、任务树、关系网，可以由文字驱动逐步显影，而不是预先设计成静态 UI。

这会带来三种新的体验跃迁

1. 叙事密度不降，但视觉回报显著提升。 传统图像游戏往往为了图像生产成本牺牲叙事分辨率；MUD 相反，叙事很强但视觉反馈弱。两者结合后，有机会把“语言的高自由度”与“图形的即时反馈”接起来。
2. 世界会更 live，而不是一页页切换。 因为文字布局足够快，你可以让界面在每次输入、每次世界状态变化后持续重组，而不是停留在表单式 prompt-response。
3. 浏览器会成为 text-native interactive fiction 的最佳载体。 它天然有字体、输入、滚动、Canvas、SVG、WebGL、网络连接、多人交互。缺的恰恰只是“把文本当一等图形对象”的中间层。

如果说传统 MUD 是“用文字描述世界”，那下一代浏览器文本世界，可能会变成“文字本身就是世界的可视化材质”。

这件事对 AI 也很重要。因为 AI 最擅长生成的就是文本状态、叙事分支、世界反馈和多角色对话。如果浏览器端已经有一套足够强的文字图形化能力，那么 AI 可以天然成为这种新媒介的“世界驱动器”。你可以想象一个形态：LLM 负责世界状态与事件推进，前端文本引擎负责把这些状态实时变成可交互、可观看、可流动的视觉叙事场。

我自己的判断：Pretext 不是“一个新库”，更像一个信号

它发出的信号大概是这样的：

1. 浏览器里文字排版这层能力，开始从被动依赖原生布局，转向主动可编排。
2. Web UI 的表达力，接下来可能不是主要靠更多 CSS 属性增长，而是靠 userland 引擎化能力增长。
3. 一旦文本几何变得廉价、准确、实时，很多“以前不值当做”的交互与媒介形式会重新被发明。

所以我觉得，Pretext 最值得关注的，不只是它现在已经做出来的那几个 demo，而是它背后那条更长的路线：文字正在从“内容”重新变成“可计算、可组合、可驱动其它系统的基础对象”。

而一旦这件事成立，受影响的就不只是前端性能，而是前端创作边界、AI UI 自动化、浏览器叙事系统，以及一类 text-native 新产品的出现。

参考来源

• GitHub - chenglou/pretext
• Pretext Research Log
• Pretext STATUS.md
• Pretext Demos
• Sebastian Markbage / chenglou text-layout archive

我看到这里，脑子里第一反应不是“这工具挺适合写文章”，而是：这其实已经不是一个普通写作工具了，它更像是一条最小可运行的 agent 自我优化闭环。

Ghostwriter 真正有意思的，不是 8 个 agent

很多人看到这类项目，注意力会被“多 agent”吸走。但我觉得真正关键的，根本不是 8 个 agent 还是 80 个 agent，而是它把一件事拆成了几个特别清楚的结构件。

第一，有一个明确的被优化对象：文章草稿。第二，有一组评价器：不同角色、不同视角的打分和批评。第三，有一个修改器：根据差评去做局部改写。第四，有复评机制：改完不是算了，还要重新打分。第五，有回滚机制：分没涨就撤回。第六，有过程日志：每一轮吐槽、评分、改动都被记录下来。

你把这几步抽象一下，就会发现这已经不是“写作工具”的问题了。它在展示的是：一个系统如何围绕目标对象做持续实验，并且只保留有效变化。

Karpathy 的 AutoResearch，把同一件事放大到了研究层

这也是为什么 Ghostwriter 很容易让我联想到 Karpathy 的 AutoResearch。

AutoResearch 做的事情很简单，但也正因为简单，所以特别有力量：给 agent 一个真实但受控的小型研究环境，让它通宵自己做实验。它修改训练代码，跑一个固定时间的实验，看指标有没有变好；变好了就保留，没变好就丢掉，然后继续下一轮。

更重要的是，它把边界划得非常清楚：prepare.py 固定，不让 agent 动；train.py 是唯一允许改的文件；program.md 由人类定义研究方向和行为准则。

自我进化不是“让 AI 随便改”，而是“冻结基线、限制可变区、用稳定评估做连续实验”。

这句话我觉得特别重要。很多人一说 agent 自我进化，想象的是某种无限生长、自由变异的系统。但真正能跑起来的，不是“无限自由”，而是“受约束的可逆试错”。

所以问题的核心，真的是两个

如果让我把这类系统的本质压缩成两个问题，我会写成：目标是什么？评估标准是什么？

这也是我觉得这类事情里最底层、最绕不开的两个支点。

没有目标，系统就不知道自己到底在优化什么。它会把“更像样”“更高级”“更复杂”误当成“更好”。最后可能只是把原本有个性的东西打磨成一块标准化的肥皂。

没有评估标准，系统就不知道哪些变化该留下，哪些该回滚。它可以不停生成新版本，却无法真正积累能力。那不叫进化，只叫反复试错。

我更愿意把它抽象成四层

顺着这个思路再往上提一层，我现在更倾向于把“任务自我进化”统一抽象成四层结构。

目标对象（Object）：到底是哪一个东西被持续优化？文章、skill、prompt、memory policy，还是 agent 的运营规则？

评估函数（Evaluator）：系统如何判断这次真的更好了？是单一指标、多维 rubric、用户反馈，还是多角色评审？

变异器（Mutator）：系统如何提出新版本？局部重写、参数调整、策略替换，还是多候选对比？

选择与记忆（Selection + Memory）：哪些变化能活下来？哪些失败以后别再犯？这次成功的经验会不会变成下一轮能力？

Ghostwriter 在文章上已经具备了这四层。AutoResearch 在研究代码上也具备了这四层。差别只是，一个优化的是博客，一个优化的是实验系统。

真正能持续跑下去，还得补上三样东西

但如果想从“局部优化工具”走向“长期可演化的 agent 系统”，我觉得还必须补上三样东西。

第一，冻结区与可变区。 你必须告诉系统，什么可以改，什么不能改。不然它很容易去“改试卷答案”，而不是提升自己的能力。

第二，预算。 每一轮实验都要有时间预算、token 预算、成本预算。没有预算的系统最后通常不是更聪明，而是更膨胀。

第三，反思层。 如果系统只会“改—测—留/丢”，那它更像自动化 hill-climbing。只有当它开始总结“为什么这次有效”“为什么上次无效”，并把这些结论写进记忆里，它才开始从试错走向学习。

这件事不会只发生在文章上

Ghostwriter 给人的第一观感是写作工具，但我觉得它真正预告的不是“以后文章会被自动优化”，而是：以后几乎所有 agent 组件都会进入可被持续优化的状态。

比如，Skill 会自我进化：哪个触发条件太宽了，哪个步骤总让用户补充说明，哪个交付格式最稳。Memory 会自我进化：什么信息值得写长期记忆，什么摘要方式更利于召回，什么写法只会污染上下文。Agent 运营策略会自我进化：什么时候提醒最合适，什么样的汇报节奏不烦人，什么决策该自己做，什么决策该升级给人。

也就是说，未来被优化的，不只是某一个任务结果，而是系统如何优化自己的方法本身。

一个我越来越相信的判断

未来最有价值的 agent，不是一次性把事做完的 agent，而是能围绕目标对象，在稳定评估下持续实验、保留有效变化，并把经验沉淀成下一轮能力的 agent。

这也是为什么我觉得 Ghostwriter 这种项目虽然看起来只是一个小工具，但背后其实踩中了一个非常大的方向：它不是在证明 AI 会改文章，而是在证明 AI 可以围绕一个目标对象形成最小进化闭环。

如果这个闭环继续往前推，写作只是开始。下一步会是 skill，接着会是 memory，再接着会是 agent 自己的运营规则。到那时，我们和 agent 的分工关系也会发生变化：人类不再亲手改每一处实现，而是更多负责定义目标、定义评估、定义边界，以及审计过程。

我现在反而觉得，未来 agent 时代最值钱的能力之一，不是“会不会写 prompt”，而是“能不能定义一个足够稳定、足够有张力、又不会被轻易作弊的评估系统”。

它像一个能力胶囊，把一类重复工作沉淀下来。你不需要每次重新解释背景，也不需要从零组织 prompt，只要在合适的时刻调用它，AI 就能按一种更稳定的方式把事做完。

这个方向当然没错。问题是，很多 skill 写着写着，就开始失控。

最初只是为了让它多覆盖一个场景，于是补一段说明；后来发现某类输出不稳定，再补一段限制；接着又怕它漏掉上下文，于是把前情、例外、边界、失败回退全都塞进去。久而久之，一个本该是“能力单元”的东西，变成了一个越来越厚、越来越难维护、越来越依赖作者本人理解力的半黑箱 workflow。

这时候它虽然还叫 skill，但实际上已经开始像负担了。

复杂 skill 的问题，不在于复杂本身，而在于它会伪装成“更完整”

这是我最近一个很强烈的感受。复杂 skill 最麻烦的地方，并不是它步骤多，而是它总让人误以为：写得越全，系统就越可靠。

可现实通常相反。

随着 instructions 不断累加，模型并不会像一个资深工程师那样自动分辨轻重缓急。它看到的是一整片需要同时处理的上下文。东西越杂，重点越容易被稀释。很多人以为自己是在“补齐规则”，其实更像是在往系统里不断注入竞争注意力的噪声。

外部一些文章已经把这件事说得很直接了：与其做一个 do-everything prompt，不如做按需加载的模块化能力。这个判断我很认同。因为一旦一个 skill 需要同时覆盖太多变体、太多例外、太多流程分支，它本质上就已经不再是 skill，而是在替一个本该由系统层解决的问题兜底。

一个好 skill，更像“能力模块”，不是“总控剧本”

我现在越来越倾向于把 skill 理解成一种边界清晰的能力封装。

它当然可以带流程感，但它不该吞掉整个流程。它可以教 agent 在某个任务类型里怎么做事，但它不该试图代替整个 runtime、memory、tool routing、异常处理和长期协作规则。

如果一个 skill 要靠自己解释所有背景、所有工具用法、所有失败路径、所有上下文读取顺序，那只能说明一件事：系统别处太空了，于是大家开始把所有问题都往 skill 里塞。

这就是为什么很多人写 skill，会写出一种“越调越重”的感觉。因为它不是在调 skill，而是在用 skill 修补 harness 的缺口。

很多 skill 的失败，其实是 harness 的失败

我越来越觉得，这件事得换个角度看。

一个 agent 做事不稳，当然可能是 skill 本身写得不好。但更多时候，真正的问题往往在 skill 外面。比如：它有没有长期记忆？有没有稳定可用的工具？有没有明确的工作规则？有没有可追溯的文件结构？有没有评测机制？有没有在运行时区分“该主动做”和“该停下来问”的边界？

如果这些东西缺位，你再怎么打磨 skill，也很容易陷入一种熟悉的循环：面多加水，水多加面。哪儿表现不好，就往 skill 里补一层说明。补到最后，skill 成了一个大杂烩，而系统的根问题却还在原地。

所以我现在会更愿意说，很多 skill 问题，本质上不是 prompt 问题，也不是某一段 SOP 的问题，而是 harness 问题。是整个系统怎样给 agent 提供记忆、工具、边界和反馈的问题。

为什么 skill 调优会慢慢变成一种技术活

这也解释了另一个很有意思的现象：为什么很多人都觉得 skill 门槛看起来很低，但真要把它调好，最后又明显不是一个纯小白活。

因为 skill 调优表面上像写文案，实际上牵涉三层能力。

第一层，是你对模型边界的熟悉程度。你得知道哪些话模型真能吃进去，哪些要求只是写给自己看的心理安慰。很多 skill 之所以显得臃肿，就是因为作者并不确定系统到底会不会按预期理解，只能不断用更多文字去“压一压”。

第二层，是你对任务的抽象能力。你能不能把一个问题说清楚，而且是对 agent 说清楚？这和对人说清楚不是一回事。很多时候我们不是说得不够多，而是说得不够结构化；也不是说得不够细，而是把不该塞进 skill 的东西也塞了进去。

第三层，是你对整个 harness 的理解。单一 skill 的优化，很多时候必须放回整个体系里看。哪些信息应该进记忆，哪些应该进 skill，哪些应该交给工具发现，哪些应该交给运行时约束，哪些应该靠 eval 托底——这不是改几句提示词能解决的。

所以所谓“skill 调优师”听起来像玩笑，但它背后的工作内容其实已经出现了。它更像一种系统调音，而不是一句 prompt 的雕花。

真正该花力气的，不是把 skill 写得更长，而是把评测标准写得更准

如果说前几年大家最容易高估的是 prompt，那现在大家最容易高估的就是 workflow。

很多人觉得，只要把 loop 跑起来，把多步骤链起来，把 skill 写成一个像样的执行流程，事情就会越来越自动、越来越聪明。可经验恰恰说明，能不能 loop 起来并不稀缺，真正稀缺的是：你到底知不知道什么结果才算“好”。

这也是为什么这波讨论最后都会落到 auto eval、奖励函数和评价框架上。因为没有评测标准，再漂亮的 skill 也只是一个会动的主观感觉生成器。它可能有时让你惊艳，但你很难稳定复现，更难系统改进。

反过来，只要你能把偏好、验收条件和负反馈定义得足够清楚，很多东西其实都可以被迭代出来。难的从来不是“让 AI 试很多次”，而是“你能不能明确地告诉系统，什么结果值得保留，什么结果应该淘汰”。

为什么 knowhow 比单次 deep research 更有复利

还有一个我越来越相信的判断：在 skill 时代，真正值钱的，往往不是一次次临时做得很漂亮的深度检索，而是那些被沉淀下来的 knowhow。

也就是你自己的 notes、评论、判断口径、做事经验、踩坑结论，甚至你对某个领域的稳定偏好。这些东西一旦被整理成 AI 可检索、可继承的结构，它们产生的价值，通常会比一次“现搜现写”的结果高得多。

因为单次 deep research 提供的是信息，knowhow 提供的是判断。信息当然重要，但真正拉开协作差距的，往往是判断层。你给 AI 的不是更多网页，而是一套越来越像你的工作语境。

从这个角度看，skill 的上限也不只是取决于 skill 本身，而取决于它背后是否接得上你的记忆、笔记、项目上下文和长期方法库。

所以，skill 最好的状态其实是“轻”，但背后要“厚”

这是我最后最想说的一点。

一个成熟系统里的 skill，表面上往往不会太重。它应该是清楚的、克制的、边界明确的。它知道自己解决什么，不解决什么；知道什么时候该触发，什么时候不该触发；知道自己该调用哪些现成能力，而不是把整座系统背在身上。

但它背后，反而应该很厚。厚的不是 skill 文件本身，而是整个 harness：记忆、工具、runtime、规则文件、评测机制、knowhow 库、项目语境，以及长期积累出来的工作方式。

换句话说，真正成熟的系统，不是把所有复杂度堆进一个 skill，而是把复杂度分散到正确的位置。

最后一句话

Skill 真正的价值，不在于它写得多完整，
而在于它是不是一个边界清晰、可验证、可组合的能力单元。

如果一个 skill 开始越写越重，先别急着继续加料。很多时候，那不是它还不够完整，而是系统该补的东西，被你全塞进 skill 里了。

比起继续把它写成一部总控剧本，我更愿意做的事，是把它拆开，把评测补上，把 knowhow 沉下去，再把整个 harness 调顺。

因为真正能长期工作的 agent，从来不是靠一份越来越厚的 skill 长出来的。

读来读去，真正学到的，不只是这个 skill 在解决什么问题，而是它背后反映出来的工作方式。

我觉得这句话非常准。

很多时候，我们看到一个 AI skill、一个 prompt、一个 agent 配置，表面上像是在看“一个工具怎么写”，但真正值得学习的，往往不是那个局部功能，而是它背后隐含的上下文组织方式、协作方式，以及它如何让 AI 在复杂任务里不失忆、不跑偏、不黑箱。

最近我越来越觉得，未来每个人大概率都要给自己搭一套 context infra。

这个词如果翻成中文，我更愿意叫它：个人的上下文基础设施。

它不是知识库，不是一堆 prompt，也不是某个神奇 agent 的配置文件。

它更像是：

你给自己的 AI 配的一套工作底座，让它在任何时候都能比较稳定地拿到“该知道的背景、该遵守的规则、该记住的东西、以及该留下的痕迹”。

为什么现在会越来越需要这套东西

以前大家更爱讲 prompt engineering。那时候问题比较简单：怎么写一句更好的话，让模型回答得更像样。

但现在任务越来越不是“一问一答”了，而是要多轮推进、调用工具、跨天持续、查资料、做判断、写产物，甚至要在多个 agent 或多个阶段之间接力。

这时候真正决定结果的，往往不是 prompt 的某一句写得漂不漂亮，而是：

• 这一轮到底该给模型看什么
• 哪些信息该常驻，哪些该临时拿
• 哪些该长期记住，哪些该及时忘掉
• 中间过程要不要留下痕迹
• 任务中断之后怎么继续

换句话说，问题从“写 prompt”变成了“设计上下文系统”。

Context Infra 本质上是什么

如果非要打个比方，我会这么理解：

• 模型像 CPU
• 工具像 I/O
• 上下文窗口像内存
• 文件、记忆、规则、日志像磁盘和配置系统
• 工作流编排像调度器

所以个人 context infra，本质上是在给个人 AI 配一层“操作系统”。

不是为了显得高级，而是因为如果没有这层，AI 每次都像刚入职一天的实习生：不知道你是谁，不知道你想怎么协作，不知道这个项目的规则，不知道哪些旧信息还有效，做完一大段事情，也没有留下可复查的过程。

一切都只能靠聊天临场猜。这在简单任务里还凑合，在复杂任务里就会越来越不稳。

我现在认为最重要的四个重点

1）先搭“工作台”，再谈“智能”

很多人会先追求更强模型、更复杂 agent、更高级自动化。但我现在越来越觉得，真正优先级更高的事情是：先把 AI 开工时要读的那个“工作台”搭起来。

也就是让它一进来就知道：你是谁、我是谁、我们怎么协作、这个项目的边界是什么、默认输出格式是什么、哪些任务应该走哪种流程。

像 AGENTS.md、SOUL.md、USER.md、WORKSPACE.md、COMMUNICATION.md、skills/INDEX.md 这类文件，看起来像文档，实际上更像“AI 的入职手册 + 工作守则 + 项目环境说明”。

它们的价值不是文件名本身，而是它们把原来只能靠聊天临时讲清楚的东西，变成了稳定、可继承、可更新的上下文入口。

这一步做完之后，AI 的状态就会从“每次重新认识你”，变成“带着长期协作框架开始工作”。

2）把记忆分层，不要把 prompt 当硬盘

这是第二个特别重要的点。很多人默认把聊天记录当全部记忆，但这种方式很快就会坏掉。

因为聊天历史天然会越来越长、越来越乱，而且里面混着当前任务信息、临时尝试、旧结论、已经过时的偏好和不再重要的上下文。

如果这些东西都一股脑塞给模型，最后很容易得到的不是更聪明，而是更混乱。

所以我觉得，个人 context infra 必须至少把记忆分成几层：

• 工作记忆：当前这轮正在做什么
• 短期记忆：这个任务最近推进到了哪里
• 长期记忆：你的稳定偏好、长期背景、关键决策
• 程序性记忆：有哪些已经验证过的流程、skill、playbook

最关键的一点不是“记得更多”，而是“记得对”。该长期保留的是稳定信息，不是全部聊天流水。

3）强制中间过程落地，减少黑箱

这是我这次最想强调的一点。一个 AI 系统如果只给你最后结论，而没有留下中间痕迹，它其实很难真正成为可靠的工作伙伴。

因为你不知道：它查了什么、它漏了什么、它中途怎么判断的、它在哪一步开始跑偏的。

所以我越来越认同一种做法：对复杂任务，强制保留中间物。

比如：

• scratchpad.md
• search_manifest.md
• notes.md
• brief.md

这些东西不是形式主义，它们有非常实际的价值：方便复盘、方便纠错、方便跨阶段续做、方便多人或多 agent 接手，也方便把“思考过程”从脆弱的上下文窗口里转移出去。

说白了，它们是在把 AI 的黑箱变成半透明系统。

4）让 context 成为基础设施，而不是一次性喂料

很多人和 AI 的协作方式，本质上还是“一次性喂料”：这次我把背景贴一大段，你先做，做完就散，下次再重新来过。

这种方式的问题是没有复利。而 context infra 的思路，是把这些内容沉成稳定层：

• 规则沉成规则文件
• 偏好沉成用户文件
• 项目背景沉成 workspace 文档
• 阶段状态沉成 brief
• 搜索路径沉成 manifest
• 经验沉成 skill / playbook

这样你不是每次都从头开始，而是在持续建设一个越来越像“个人 AI 工作环境”的系统。

如果让我给一个人从零开始搭，我会建议这样做

我不会一上来建议搞很重的系统。更现实的顺序是：

第一步：先建一个固定 workspace

至少有：AGENTS.md、SOUL.md、USER.md、MEMORY.md、memory/、projects/、skills/、notes/、scratchpads/。

第二步：先把最稳定的协作规则写出来

比如默认怎么汇报、哪些事可以直接做、哪些事要先确认、你更喜欢看到摘要还是完整方案、项目内的基本规范是什么。

第三步：把长期信息从聊天里抽出来

比如你的长期偏好、项目的长期背景、已经做过的重要决策、那些反复重复、值得沉淀的经验。

第四步：对复杂任务默认留中间物

哪怕一开始只有三样也够：search_manifest.md、notes.md、brief.md。一旦这三样开始稳定存在，你的 AI 工作流就会比纯聊天稳很多。

第五步：再考虑异步、多阶段和多 agent

这个顺序很重要。因为很多人一开始最容易犯的错，就是还没把基础文件化，就急着追求很复杂的全自动编排。最后系统很炫，但没人维护得动。

对个人来说，更好的路线通常是：先让规则稳定、记忆可取、过程可查，再逐步增加编排和自动化。

我现在最认同的一条判断

如果要我用一句话总结这次的思考，我会说：

个人 context infra 的重点，从来不是让 AI “知道更多”，而是让它在需要的时候，稳定拿到“最该知道的那一小部分”，并且把过程中真正重要的东西沉淀下来。

所以它的关键不在“堆”，而在分层、筛选、沉淀、检索、追溯和接力。

当这些东西开始成形时，AI 才不再只是一个会聊天的工具，而更像一个真正能长期协作的工作系统。

这大概也是为什么，有时候读别人一份 skill，会突然觉得自己学到的不只是某个招式，而是一种新的工作世界观。

这件事当然重要，而且它确实解释了很多现象。为什么同一个模型，在不同系统里表现会差这么多？很大程度上，就是因为喂给它的 context 完全不同。谁更会组织 instructions、examples、history、retrieval context、tool schema，谁就更容易拿到更稳定的输出。

但如果你真的开始长期使用一个 AI 助手，很快会遇到另一层问题。

你会发现，单次回答质量当然重要，但更重要的是：它下次还记不记得你？它会不会积累经验？它能不能把一次做对的事情，变成下一次更自然的默认动作？它会不会随着合作变久，慢慢长出一种“越来越懂你”的工作方式？

这时候，你会意识到一个事实：真正重要的，已经不只是 Context，而是 Harness。

Context Engineering 解决的是“这一轮怎么喂”

我并不想贬低 Context Engineering。恰恰相反，我觉得它是过去两年里非常重要的一次认知升级。

因为在 Prompt Engineering 时代，很多人还把问题理解成“怎么把一句提示词写得更聪明”。到了 Context Engineering，大家开始意识到，模型的表现并不是由一句 prompt 决定的，而是由整个上下文系统共同决定的：系统指令、示例、历史对话、检索内容、工具定义、文件内容、状态信息、压缩策略，这些东西加在一起，才构成了模型眼中的现实。

OpenAI 在官方文档里就把 retrieval-augmented generation 归到这种思路之下：把额外相关信息加入当前生成请求，以便模型在本轮回答里拥有更好的依据。Anthropic 在讲 agent 的文章时，也一再强调 tool design 和 agent-computer interface 的重要性。它们说的其实都是同一件事：模型不是凭空变好，而是在被更好地喂养。

所以 Context Engineering 的核心问题其实很清楚：在当前这一轮任务里，到底该给模型看什么，怎么给，给多少，按什么顺序给。

这是一层非常关键的工程，而且今天依然成立。没有它，很多系统连第一步都走不稳。

但个人 AI 助手真正缺的，往往不是更多上下文

问题是，当你把 AI 从“回答一个问题”升级成“长期和你一起工作”的个人助手时，Context Engineering 很快就会显得不够。

因为上下文再长，也只是这一轮的。你今天把所有背景都喂进去，明天还得重新喂一遍。你这次手把手带它完成一个复杂任务，下次它还是有可能从头再来。你可以不断复制粘贴自己的偏好、流程、口径、要求，但这件事本身就说明：系统并没有真正把这些东西变成自己的能力。

一个真正好用的个人 AI 助手，不应该永远停留在“每次都要重新对齐”的状态。它应该在长期合作里，慢慢形成自己的工作惯性。它知道你更喜欢怎样的交付格式，知道什么信息值得长期记住，知道哪些事情需要先做完再来打扰你，知道哪些流程可以直接调用，哪些场景必须让你确认。

这些能力，并不是靠把 context window 再拉长一点就能自动长出来的。

它需要别的东西。需要记忆，需要技能，需要运行时的约束，需要反馈回路，更需要一种能不断修正自己的机制。换句话说，它需要一个 Harness。

什么叫 Harness

我越来越倾向于把 Harness 理解成：模型之外，让它能长期工作的那整套支架。

这里面至少包括几层东西。

第一层是 Memory。不是把聊天记录原封不动堆起来，而是有层次地保留工作记忆、日志记忆、长期记忆、反思记忆。它不只是记住发生过什么，更重要的是，能从发生过的事情里抽出规律，形成下一次更好的默认行为。

第二层是 Skill。Skill 不是一个花哨的 prompt 模板，而是一个可复用的工作单元。它知道自己在什么时候该被触发，什么时候不该被触发；它可能附带脚本、资源、参考文档，甚至验收标准。它的作用不是“多教模型一点知识”，而是把某类任务沉淀成一种稳定能力。

第三层是 Tool 和 Runtime。也就是模型调用外部世界的方式：文件、终端、浏览器、MCP、搜索、数据库、API、审批边界。这些东西决定了它能不能真正行动，而不是停留在“会说”。

第四层是 Evaluation 和 Guardrails。一个长期运行的系统，不可能只靠运气变好。它需要知道自己哪里做对了，哪里做错了，什么时候偏了，什么时候越界了。否则所谓“自我进化”很容易变成“自我漂移”。

把这些东西放在一起，你就会发现，Harness 关心的已经不是“这轮输入怎么组织”，而是这个 agent 在长期协作里，会不会逐渐形成稳定能力。

这就是为什么我觉得，新时代真正重要的是 Harness Engineering

如果说 Context Engineering 关心的是“本轮输入编排”，那 Harness Engineering 关心的就是“长期运行支架”。

它们不是互相替代的关系，更像层级不同的关系。Context 是 Harness 的一部分，但不是全部。你当然还得解决这一轮怎么喂，可你也必须开始解决：喂过一次以后，系统会留下些什么；做对一次以后，它能不能变得更会做；做错一次以后，它能不能少犯同样的错。

这就是我为什么觉得，个人 AI 助手时代最关键的变化，不是 context engineering 消失了，而是它被放进了一个更大的框架里。真正决定上限的，不再只是“上下文组织得好不好”，而是“有没有一个能让 agent 长期学习和稳定协作的 Harness”。

你也可以把它理解成：Context Engineering 解决的是短程表现，Harness Engineering 解决的是长期人格。

个人 Harness 里，最重要的其实是 Memory 和 Skill 会不会进化

我现在对个人 AI 助手最强烈的一个判断是：未来谁更像“你的搭档”，不取决于它记住了多少，而取决于它会不会更新自己的记忆，以及会不会演化自己的技能。

因为记忆最大的风险，从来不是不够多，而是太多。什么都记，很快就会变成噪音池。今天一句随口偏好，明天一个临时任务，后天一次并不稳定的表达习惯，如果全都被无差别地塞进长期记忆，系统很快就会被自己的历史拖垮。

所以一个好的 Memory 机制，首先不是“尽量多存”，而是“知道什么该留下，什么该忘掉”。更进一步，它还要会修订。用户今天说过的话，未来可能改变；系统之前归纳出的偏好，后面可能被新的行为推翻。长期记忆如果只增不改，最后一定会越来越像一份过期档案，而不是活的工作模型。

Skill 也是一样。很多系统一开始都很热衷于沉淀 skill，结果沉淀着沉淀着，就把自己沉淀成了一座废墟。skill 越来越多，触发边界越来越模糊，说明越来越重叠，最后要么误触发，要么谁也不触发。

所以 skill 真正需要的，不只是 creation，更是 evolution。它要能被拆分、改写、弱化、归档、淘汰。一个 skill 长期没人用，就应该进入归档候选；一个 skill 覆盖范围越来越宽，就应该拆成两个更聚焦的 skill；一个 skill 误触发率太高，就应该重写 description，而不是继续堆补丁。

从这个角度看，真正决定个人 Harness 质量的，不是 memory 和 skill 有没有，而是它们是不是活的。

“自我进化”不是玄学，而是一套更新机制

很多人一说到 AI 的自我进化，就容易往很玄的方向想，好像系统会自己长脑子一样。其实我越来越觉得，这件事没有那么神秘。所谓自我进化，真正落到工程上，无非就是三件事：记录、反思、更新。

先是记录。系统得知道发生过什么：做了哪些任务，哪些地方返工了，哪些输出被用户明确认可，哪些地方总是出错。这是最基础的一层，没有它，后面所有“变好”都无从谈起。

然后是反思。不是把日志原样留在那里，而是从里面找出那些会反复出现的模式。什么偏好是稳定的，什么需求只是一次性的，什么错误是偶发，什么错误是结构性的，什么成功动作已经值得提炼成默认套路。

最后才是更新。把真正有价值的部分写回长期记忆，把成熟的流程升级为 skill，把失效的规则降级或删掉。这里最关键的一点是：更新不能全自动乱改。数据可以自动记录，规则可以自动起草，但真正会改变长期偏好、工作边界和系统身份的东西，最好还是有人把关。

所以我心里理想的个人 Harness，并不是一个每时每刻都在偷偷重写自己的人，而是一个有节奏、有分层、有审计的自我修订系统。它白天和你工作，晚上整理日志；它不会因为一句随口的话就改写长期认知，但会把连续出现的模式提成候选；它能自动做草稿，但关键边界仍然交还给人确认。

这才是我理解里的“可控自我进化”。

为什么这对个人尤其重要

企业级 agent 当然也需要这些东西，但对个人来说，这件事反而更关键。因为企业系统往往还能依赖流程、角色分工、审批链条、组织知识库来兜底；而个人助手一旦做不好，问题会直接落到一种更微妙的层面：它会显得不懂你。

而“不懂你”在个人场景里是非常致命的。因为你真正想要的，并不是一个永远能答对百科问题的模型，而是一个在日常协作里越来越省你心的搭档。它知道你更重视什么，知道你不喜欢什么，知道哪些事该主动、哪些事该保守，知道什么时候应该帮你推进，什么时候应该闭嘴。

这些都不是知识问题，而是长期协作问题。而长期协作，本质上就是 Harness 问题。

所以未来真正的分水岭，不是谁的模型更大，而是谁的 Harness 更成熟

我现在越来越相信，接下来个人 AI 助手真正的差距，未必首先体现在模型参数上，而会更多体现在 Harness 上。

同样一个底层模型，如果它只有 context，没有 memory；只有 prompt，没有 skill；只有回答，没有 update loop；只有即时反应，没有长期修订，那它永远更像一个聪明的陌生人。

反过来，如果一个系统有好的 memory 分层，有成熟的 skill 机制，有清晰的工具边界，有稳定的反思和更新节奏，它哪怕底层模型不是最强，也更容易长成一个真正可合作的助手。

因为人和人之间的长期默契，从来不是靠“每次都重新介绍自己”建立起来的，而是靠共同记忆、共同套路和不断修正形成的。个人 AI 助手也一样。

最后一句话

如果要我用一句话概括这次变化，我会这么说：

Context Engineering 让模型在这一轮更聪明，
Harness Engineering 才让它在长期协作里，慢慢变成“你的”。

真正值得投入的，不只是把上下文喂得更满，而是让记忆会更新，让技能会进化，让 AI 在长期合作中形成自己的工作方式。

这才是下一阶段更重要的事。

过去 SaaS 产品面对的主要是人：人点按钮、人看页面、人手动切换系统完成流程。产品做得好不好，主要看页面顺不顺、功能全不全、协作顺不顺手。

因为现在产品面对的，已经不只是人了，还有 Agent。人是来点按钮的，Agent 是来调能力的。它不关心你的页面漂不漂亮，它关心的是你的能力是不是稳定、清晰、可调用、可审计。

这也是为什么最近飞书、钉钉会不约而同地往 CLI 化、Skill 化走。表面上看这是开发者工具层的动作，实际上是在改产品底座：它们在把自己从“给人点的页面集合”，重构成“给人和 Agent 一起调用的执行系统”。

我对这件事的判断很明确：这不是一阵风，而是 SaaS 产品形态已经开始发生的变化。只是这里面也有一个特别容易走偏的地方：SaaS 最应该做的，是把自己做成最好的能力层，而不是急着把自己做成一个通用代理壳子。

为什么这件事几乎是必然的

CLI 在过去更像开发者接口，现在重新变成了 AI 时代的“自然机器接口”。对人来说，CLI 可能不够友好；但对 Agent 来说，它极其友好：参数清晰、输出结构化、错误可解析、帮助文档自描述、天然可脚本化。

新浪科技在总结飞书和钉钉近期动作时，有一句话说得很准：

“命令行界面（CLI）是软件能力最底层的调用方式——对AI来说，有了CLI，调用平台能力就像执行系统指令一样直接。”
—— 来源：飞书、钉钉开源 CLI，Agent 开放路径走向分岔

这句话真正重要的地方，不在于“CLI”这三个字本身，而在于它点出了一个用户模型的变化：以前 SaaS 面向的是“点击鼠标的人”，现在还要面向“会拆任务、会调工具的 Agent”。

如果一个 SaaS 产品到今天还是只有 GUI、只有零散 API、只有给人看的帮助文档，那它在 Agent 时代就会很尴尬。因为人还能凑合着用，Agent 是很难稳定接进去的。

所以这波趋势的本质并不是“大家都想做 AI”，而是大家都意识到，产品的执行层必须重新开放一次，而且这次不是开放给人，而是开放给 Agent。

飞书、钉钉为什么都在往这个方向走

最近国内最强的信号，就是飞书和钉钉几乎同时走向 CLI 化。

关于钉钉，IT 之家的一段描述很能说明问题：

“钉钉 CLI 开源了！3 月 27 日，钉钉 CLI 开源项目上架 Github 社区，项目以 Apache-2.0 协议开源，首批开放 AI 表格、日历、日志、待办、机器人、通讯录、DING 消息、考勤、开放平台文档、工作台共 10 项核心产品能力，原生支持 Claude Code、Cursor 等主流 AI 编程与 Agent 执行环境。”
—— 来源：钉钉 CLI 开源！首批开放 10 项产品能力

同一篇文章里还有一句也很关键：

“开发者完成一次初始化配置后，即可在任意支持 CLI 调用的 Agent 框架中直接使用钉钉产品能力，无需额外的 SDK 集成或中间件开发。”

翻译成人话就是：未来竞争的关键，不是让 AI 能不能听懂你，而是让 AI 能不能稳定地用你。

飞书这边，虽然这轮公开检索里更容易搜到的是社区实现，但这反而说明一件事：飞书的能力结构已经天然适合被重新封装成面向 Agent 的执行层。

“飞书开放平台命令行工具 — Markdown 与飞书文档双向转换，AI Agent 的飞书操控引擎。”
“除了传统的 CLI 用法，feishu-cli 还为 Claude Code 等 AI 编程助手提供了 11 个开箱即用的技能文件，让 AI Agent 能够直接创建文档、发送消息、管理权限。”
—— 来源：riba2534/feishu-cli - GitHub

这里有个很有意思的信号：就算平台自己不亲自下场定义执行层，生态也会替它定义。因为一旦一个 SaaS 平台沉淀了足够丰富的对象模型、权限系统和工作流能力，市场自然会把它重新打包成 CLI + Skill 供 Agent 使用。

所以从平台视角看，CLI 化、Skill 化不是“顺手多做一个工具”，而是在主动把执行层的定义权拿回来。

真正值钱的，不是 CLI，而是 Skill

CLI 解决的是“怎么调用”；Skill 解决的是“什么时候调用、按什么顺序调用、带着什么上下文调用”。

这两者完全不是一个层级的问题。

只做 CLI，本质上是在暴露原子能力；做 Skill，才是在沉淀领域里的最佳实践。它把原来需要靠资深员工、实施顾问、项目经理口传心授的东西，压缩成一个可以被 Agent 复用的工作单元。

从这个角度看，Skill 的真正价值不是“prompt 模板”，而是领域 SOP 的可执行打包格式。它不是让 AI 更会说，而是让 AI 更会干。

这也是为什么 SaaS 最终一定会往 Skill 走。因为很多 SaaS 真正有价值的部分，从来都不是按钮本身，而是按钮背后那套隐性的业务顺序、对象关系、权限边界和例外处理逻辑。

这对传统数据分析平台和报表平台意味着什么

这部分我觉得其实最值得展开。因为很多数据平台现在理解这波变化，还是停留在“给 BI 加一个聊天框”这个层面。但真正重要的地方，从来不是“会不会对话”，而是“能不能把分析和行动重新接起来”。

传统 BI / 报表平台的问题，不是没有图表，也不是没有问答，而是洞察到行动之间断了一截。

报表告诉你北美收入在掉，仪表盘告诉你某个渠道的转化率在跌，异常监控告诉你某个业务指标突然偏了——但接下来怎么办，往往还得人工再跳到 CRM、营销系统、客服系统、项目管理系统里一层层处理。

所以过去的数据平台，本质上更像“解释世界”的系统；但到了 Agent 时代，大家真正期待的是：你不只是解释清楚，还要能顺手往前推一步。

这也是我为什么觉得，数据分析平台和报表平台接下来真正应该升级的，不是一个会聊天的外壳，而是底下的四层能力。

第一层，是语义层要先 Agent-ready。没有统一语义层，Agent 只会把混乱放大。Dremio 的文章里有一句说得非常直白：“A semantic layer provides the metadata and context that AI systems need to query data accurately.” Databricks 也说得很像：当指标定义被集中到语义模型里，所有下游界面——无论是 BI 看板、Jupyter notebook，还是自然语言问答——读到的都应该是同一套受治理的逻辑。

这意味着，数据平台第一优先级不是“做一个更聪明的对话入口”，而是把指标、口径、维度、权限、血缘、同义词、认证状态这些内容整理成统一的、可被 Agent 稳定调用的语义层。

第二层，是把分析动作本身做成可编排能力。数据平台里有大量高频动作，其实天然适合被命令化：刷新某个数据集、生成某条业务线的周报、对异常指标做根因拆解、生成高管简报、触发某个看板的快照和分发、发起某个指标定义的审批。假如这些动作还是深藏在 UI 里，那 Agent 很难真正接得上来。

第三层，是从“问答式 BI”走向“行动式 BI”。所谓行动式，不是让系统替你做所有决策，而是让它在给出洞察的同时，也能往后推动一步。比如发现某地区续费率异常下降后，不只是解释原因，还能自动圈出受影响的客户分群、生成负责人的跟进清单、在 CRM 或项目管理系统中创建任务，甚至把结论写回复盘文档。这时候数据平台才真正从“看板”变成“指挥台”。

第四层，则是 GUI 的角色要重新定义。GUI 不会消失，反而会更重要，只是它不再是唯一入口。以后更适合它承担的角色，是监督、调试、配置、审批和复核。换句话说，CLI / Tool / Skill 负责执行，GUI 负责让人看清执行过程，并在关键处接管。

如果一个传统数据平台能把这四层打通，它就不是“给报表加 AI”，而是在把自己重构成一套真正 Agent-ready 的分析基础设施。

我为什么反对 SaaS 厂商重度重做一个“类似 Claw 的东西”

这一点我想说得更直接一点：不要把“自己有 CLI + Skill”误解成“自己必须做一个通用 Claw”。

像 Claw 这类产品，本质上是在解决通用任务执行器的问题：多工具协同、文件与浏览器操作、跨系统编排、终端执行、上下文调度。这是一个很大的命题，但它并不是大多数 SaaS 厂商天然擅长的命题。

大多数 SaaS 真正的护城河，从来不在“做一个通用代理壳子”，而在于它对本领域的深度理解：业务对象模型、权限关系、组织关系、流程结构、审计链路、数据语义、例外规则。这些东西，才是别人最难复制的。

如果一个报表平台、一家 CRM 厂商、一个协同办公产品，突然把大量研发资源押到“做一个自己的通用代理操作系统”上，结果大概率是：花了很大力气去补浏览器自动化、通用编排、终端沙箱、跨工具状态同步这些并不属于自己核心竞争力的部分，反而把本来最值钱的领域能力做浅了。

所以我支持的路线一直很明确：深做自己的能力层，浅做自己的代理入口，广泛兼容外部 Agent 生态。

你当然可以有一个自己的 Agent 入口，用来降低上手门槛，也服务那些不愿意折腾工具链的普通用户。但你最重要的资源，不应该砸在“做一个万能代理”上，而应该砸在“让自己的产品成为外部 Agent 最愿意接、最容易接、最放心接的能力层”上。

一句话说，就是：SaaS 厂商应当成为最好的被调用者，而不一定要成为最大的总代理。

如果我是数据分析平台或报表平台的产品负责人，我会怎么做

如果让我来排优先级，我肯定不会先做一个花哨的 AI 外壳，而是会先从最务实、最容易出结果的地方动手。

第一步，我会先把现有高频能力拆成明确的动作层。哪些事情是用户反复在做的？生成周报、快照分发、指标解释、异常诊断、批量导出、权限审批、订阅推送……先把这些变成明确的命令、工具和能力接口。因为这一步一旦打通，外部 Agent、内部工作流和未来的 Skill 才有接入基础。

第二步，我会集中补语义层。不是为了讲概念，而是为了避免后面所有 AI 能力都建立在不统一的口径之上。只要语义层不稳，所有所谓“智能分析”都会在不同场景下说出不一样的话，最后把平台信任度打穿。

第三步，我会挑几条最值钱的业务链路做 Skill，而不是泛泛地做一个“万能问数助手”。比如高管简报、运营周报、异常归因、销售漏斗复盘、投放效果归因、月结分析，这些都比“你可以问我任何数据问题”更容易形成可感知价值。因为真实用户并不缺一个会聊天的工具，他们缺的是一个能把具体工作接过去的工具。

到了这一步，如果要做自然语言入口，它也应该建立在前面这些能力之上，而不是倒过来。对话只是入口，不能成为系统本体。系统本体应该始终是语义层、动作层、Skill 层、治理层。

这也是为什么我一直觉得，对大多数传统数据平台来说，最好的路线不是激进重构一个全新的“AI 操作系统”，而是先把自己一点点改造成一个更适合 Agent 调用的基础设施。这样既不失焦，也更容易真正落到业务结果上。

最后的判断

未来几年，我觉得 SaaS 会形成一个越来越清晰的共识：GUI 不再是唯一主入口，它只是人类入口之一；CLI、Tool、Skill、MCP 会逐渐成为产品能力的标准暴露层；语义层会变成数据产品最核心的资产之一；而报表本身，也会从“结果展示品”慢慢演化成“行动触发器”。

所以，“SaaS 都要变成 CLI + Skill”这句话，如果再说得准确一点，我会改成下面这句：

不是 SaaS 都要变成一个新的 Agent，
而是 SaaS 都要把自己重构成 Agent 可以放心调用的能力层。

对于传统数据分析平台和报表平台来说，真正值得做的，也不是给现有页面再套一个聊天框，而是把指标做得可解释，把语义做得可继承，把分析做得可编排，把动作做得可执行，把过程做得可审计。

这才是这波趋势里最值钱的升级。

从153篇日记中提炼的个人操作系统——不是你说过什么，而是你一直在做什么。
基于2025年7月至2026年3月的行为模式归纳。写给未来的你。

一、你的风格：做事的方式、节奏与气质

公理1：先干再说，边干边调

你的默认模式不是"想清楚再动手"，而是"先跑起来再迭代"。从AI大赛235支队伍的全程推进，到Avatar版本管理定为P0，再到"先用起来，合同后补，流程并行"——你反复用行动证明：启动的摩擦力比方向错误更致命。

"先跑起来"不追求完美。
"先用起来，合同后补，流程并行。"

但这不是莽撞。你有一个隐含的二阶操作：事后复盘。快速决策+事后复盘，构成你的完整决策闭环。你信任自己在运动中修正方向的能力。

公理2：躬身入局，双脚沾泥

你对"只动嘴不动手"的管理者有本能的不信任。你坚持亲自写代码、亲自走查产品细节、亲自参与技术决策。这不是微管理，而是一种认知校准机制——只有自己下过场，才能判断团队汇报有几分水分。

"管理者在AI初期处于劣势，需要躬身入局，亲自写代码。"
"只有自己下过场，才能判断团队汇报有几分水分。"
"躬身入局，两手沾泥。"

你甚至把这变成了制度：薪资的5%强制用于AI工具，管理者必须亲自使用。你相信体感是判断力的基础。

公理3：善用类比，降维传达

你的沟通武器是比喻。"宜家样板间"、"零部件供应商"、"纯净水与河水"、"高射炮打小鸟"、"井冈山"——这些不是修辞装饰，而是你传递复杂概念的核心方法论。你深知：让人觉得"我也能做"，比证明"我很厉害"重要得多。

"做布道工作最怕讲得太技术化，关键是让人觉得'我也能做'。"

你的类比能力本质上是翻译能力——把技术语言翻译成业务语言，把战略意图翻译成可感知的画面。这是你区别于纯技术管理者的核心竞争力之一。

公理4：克制出头，成就他人

你有意识地控制自己的存在感。看到团队成长会"有一丢丢失落但更多欣慰"——这句话泄露了你的底层操作系统：你明白自己的角色是教练而非球员。80/20法则（下属讲70%，自己总结升华20-30%）不是谦虚，是策略。

"关注业务结果只是本职，真正有长期价值的是把经验和价值观传递给年轻人。"

你追求的不是个人英雄主义，而是可复制的组织能力。

二、你的偏好：选择倾向、审美与价值排序

公理5：业务价值是唯一叙事

技术再酷，如果不能讲清楚业务价值，在你这里等于零。这个原则贯穿了你所有的汇报准备、战略规划和项目评审。你对"技术分享会式汇报"有明确的厌恶。

"技术是手段，业务价值才是核心叙事。"
"汇报不是技术分享会，必须围绕领导关心的问题来组织。"
"不能拿不可持续的短期数据去忽悠大老板。"

你的价值排序是：业务结果 > 技术先进性 > 流程规范性。务实解决问题比纠结流程更重要。

公理6：做减法比做加法更需要魄力

你反复展示了"砍"的能力：十多个子战场精简为6个；敢放弃、敢叫停、敢删方案；从"整车交付"转向"零部件+样板间"。你对"什么都想做"有天然的警觉。

"有时候知道什么不该做比知道该做什么更重要。"
"与其什么都想抓，不如把核心壁垒握紧。"
"有时候做减法比做加法更需要魄力。"
"不是什么都自己做，而是把最稀缺的研发资源放在最关键的地方。"

这背后是一个清晰的资源观：研发资源永远稀缺，所以聚焦是生存策略，不是美德。

公理7：数据说话，但要说对的话

你重视数据，但更警惕虚荣指标。你提出了一个精妙的视角转换：用"错误率"而非"准确率"来衡量——从5%降到2%比95%升到98%更有冲击力。这说明你关注的不是数据本身，而是数据的叙事力。

"安装不等于使用，使用不等于提效。"
"用'错误率'而非'准确率'来衡量，从5%降到2%比95%升到98%更有冲击力。"

你的数据观：数据是论据，不是答案。论据的说服力取决于框架，而框架由你来建。

公理8：用人看好学和态度，战功导向

你选人的核心标准不是能力，而是学习速度和态度。你对"苦劳"无感，只认"战功"。你善用鲶鱼效应，愿意引入外部压力来激活团队。

"好学决定走多快，态度决定走多稳。"

你的管理审美是：要打仗的人，不要守城的人。在AI剧变的时代，这个偏好尤其合理——因为城本身在变。

三、你对技术的判断：技术观、工具观与趋势预判

公理9：AI+工程，而非工程+AI

这是你最核心的技术判断之一。你坚持把系统按"大Agent"来设计，工程做配合——而不是在传统工程体系上"贴"AI。这个判断决定了你团队的技术路线和产品形态。

"AI+工程，本质是把它按照大的Agent来设计，中间会用工程做配合。"
"以CLI的方式对外提供服务，本质上就是把自己当成一个智能体。"
"Skills > Workflow。"

延伸判断：你对MCP持保留态度，更倾向CLI/智能体方式。你相信AI原生的架构会淘汰"AI作为插件"的架构。

公理10：大小模型各有战场

你不迷信大模型万能论，坚持大小模型结合的务实路线。大模型负责理解，小模型负责推荐——这个分工背后是对成本、延迟和场景的精细判断。

"大模型负责理解，小模型负责推荐。"

你同时警告团队"戒掉GPT"，意思不是不用AI，而是不要把对AI的理解停留在对话框层面。真正学好AI，要深入到Agent、工具链、工程化的层面。

"现在要真正学好AI，应该戒掉GPT。"

公理11：补丁打到70分就停手

你对过度优化有清醒的克制。你认为在AI快速迭代的时代，把当前方案打磨到100分是浪费——因为新模型来了，过度定制的补丁反而无法泛化继承。

"一共100分你才十分，考虑安全直接打成零分了，先搞到七八十分再考虑。"
"补丁打到70分就OK，过度打补丁会导致新模型来了无法泛化继承。"

这是一个反完美主义的技术观：在技术剧变期，"够用"比"完美"更理性。

公理12：代码不再是壁垒，平台能力才是

你很早就看到了一个趋势：AI正在让代码本身贬值。未来的竞争力不在于写代码的能力，而在于不可替代的基础能力和平台价值。

"代码本身已不是商业竞争的绝对壁垒。"
"平台的价值不在于垄断，而在于提供不可替代的基础能力。"
"我很担心AI会把数字世界的中间商给干趴下。"

你的战略推演：中间层会被压缩，只有靠近业务的应用层和靠近基础设施的平台层能存活。你的团队定位——"修路打基建"而非"造车"——正是基于这个判断。

公理13：AI转型必过J曲线，强制使用是唯一解

你承认AI转型初期效率会下降，但你的应对不是等待，而是强制推行+忍受阵痛。这背后是一个关于惯性的判断：自愿采纳永远太慢，管理者必须制造不可逆的既成事实。

"AI转型必然经历J曲线，初期效率会下降，必须强制使用、忍受不适。"
"改变惯性的人都是伟大的。"

四、你的项目推进方式：从启动到落地的方法论

公理14：先定纲，再开枝散叶

你推进任何项目的第一步不是分配任务，而是建立"纲"——核心框架和方向共识。没有纲，所有的执行都是布朗运动。

先思考"纲"再"开枝散叶"。
"面对高层，先建立框架和共识，再用案例去佐证。"

这个习惯延伸到你的沟通中：向上汇报先给框架，再填细节；战略讨论先对齐目标，再讨论路径。

公理15：去中心化执行，中心化方向

你反对中台包办一切，主张去中心化的执行模式。但方向、标准和验收由你中心化把控。这是"三分之一"管理法的底层逻辑：1/3把握方向、1/3听专业判断、1/3放权试错。

"修路打基建"定位不和业务抢"造车"。
去中心化反对中台包办。

你的组织哲学：方向要收，执行要放。

公理16：沟通介质有优先级

你对沟通方式有明确的效率排序，并且严格执行：能当面不电话，能电话不企微，能企微不邮件。你善用非正式场合（饭局、走廊、抽烟间隙）推进关键决策。

"能当面不电话，能电话不企微，能企微不邮件。"
"信息同步不是目的，认知对齐才是。"

这背后是一个沟通观：信息传递的保真度与介质的丰富度正相关。文字最容易被误读，面对面最不容易。

公理17：向上管理是技术活

你对向上沟通有一套成熟的方法论：先建立框架共识，再用案例佐证；用数据和标杆说话；重塑期望而非迎合期望；讲什么和怎么讲有时比做了什么更重要。

"汇报不是技术分享会，必须围绕领导关心的问题来组织。"
"讲什么和怎么讲，有时候比做了什么更重要。"

你还懂得预期管理的反面：不能最后"突袭"。坏消息要早说，好消息要有节奏地说。

公理18：边界意识——学会说"不"

你在管理成熟度上的一个关键进化是：学会拒绝。守住团队边界，不接不该接的需求，不为了短期和气牺牲长期资源配置。

学会说"不"守住边界。
"团队需要从'做支持'转变为'做产品'，否则永远只能是别人故事里的配角。"

这和公理6（做减法）一脉相承：说"不"是资源管理的核心能力。

公理19：关键节点亲自拍板，日常充分放权

你的介入模式不是均匀分布的。日常运转充分信任团队，但在战略方向、关键人事、核心产品设计这些节点上，你亲自下场拍板。每周密集会议对齐是你保持控制感的机制。

"先定方向再找人执行。"
"关键节点亲自拍板。"
OKR和明确验收标准驱动。

你的节奏是：松-紧-松。平时松，关键时刻紧，紧完立刻松回去。

五、底层信念：驱动一切的元规则

公理20：实力决定下限，运气决定上限

这是你对职业和人生的底层认知。你不依赖运气，但承认运气的存在。你能控制的是不断提高下限——通过学习、通过实践、通过把自己逼进不舒服的地方。

"实力决定下限，运气决定上限。"

公理21：管理的本质是认知对齐

你的管理范式已经从"管理幅度"转向"认知幅度"。你认为这个转变不可逆。管理者的核心工作不是分配任务和监督进度，而是确保团队在认知层面对齐——对问题的理解一致，对目标的判断一致，对优先级的排序一致。

"管理范式从管理幅度向认知幅度转变，不可逆。"
"信息同步不是目的，认知对齐才是。"
"做战略规划最难的不是写方案，而是改变团队的思维方式。"

公理22：你需要一个二号位

这是你最坦诚的焦虑，也是最清醒的自我认知。你知道没有二号位，自己就是团队的瓶颈和单点故障。这不是谦虚，是对组织健康度的冷静判断。

"如果没有二号位，你是不可能再进一步的。"
"战略方向已清晰，现在缺的是关键的人和扎实的执行。"

附录：你的操作备忘

提炼自153篇工作日记（2025.07 - 2026.03），不代表你应该成为什么，而是记录你已经是什么。

• 日期：2026-03-13
• 主题：OpenAI Harness Engineering、Cursor Towards self-driving codebases / Scaling long-running autonomous coding
• 结论先行：harness engineering 不是单指提示词工程，也不是单个模型能力，而是围绕代理开发构建的一整套运行环境、知识系统、约束机制、评测反馈、观测与收敛流程。它解决的是“怎样让 agent 在真实代码库里持续、稳定、可审计地产出可合并的软件变更”。

核心结论

1. Harness engineering 的本质，是把软件工程的重心从“人直接写代码”转向“人设计环境、指定意图、建立反馈回路，agent 负责执行”。OpenAI 在官方文章中直接写到："Humans steer. Agents execute."，并称他们在 5 个月里构建并交付了一个内部 beta，且是 "0 lines of manually-written code"。OpenAI
2. 这套方法的关键不在于单次 prompt，而在于让 agent 拥有可工作的环境：可启动的应用、可访问的日志/指标/trace、可执行的 CI、可引用的仓库知识、可验证的架构边界、可复用的评测流程。OpenAI
3. Cursor 的“self-driving codebases”与 OpenAI 的 harness engineering 在工程哲学上高度同构：二者都强调多 agent 编排、角色分层、强可观测性、结构化 handoff、允许局部错误但追求整体收敛，而不是追求每一步绝对正确。Cursor self-driving codebases Cursor scaling agents
4. OpenAI 后续关于长程任务的官方文章进一步说明：真正起作用的不是超长单 prompt，而是 plan -> implement -> validate -> repair -> repeat 的 agent loop，以及 prompt/spec、plans.md、implement.md、documentation.md 这类“持久项目记忆”。Run long horizon tasks with Codex
5. 因此，harness engineering 可以理解为“agent-first 软件工程基础设施与操作系统”。它覆盖知识管理、执行编排、测试评估、审查合并、质量回收，以及长期自治运行的防漂移机制。

什么是 Harness Engineering

1. 定义

OpenAI 的定义不是一句术语解释，而是一套实践描述：当团队的主要工作“不再是亲手写代码，而是设计环境、指定意图、建立反馈循环，让 Codex agents 稳定工作”时，工程工作的核心就转向 harness。OpenAI

可压缩成一句中文：

Harness engineering = 为 agent 构建能可靠工作的工程环境、知识底座、控制规则和反馈回路。

OpenAI 原文中的几个关键句：

"Humans steer. Agents execute."

"The primary job of our engineering team became enabling the agents to do useful work."

"Our most difficult challenges now center on designing environments, feedback loops, and control systems"

来源：OpenAI

2. 它不是什么

• 不是单纯的 prompt engineering；prompt 只是入口，不是系统本体。
• 不是把大模型接进 IDE 就算完成；真正难的是让 agent 能持续完成端到端任务。
• 不是“自动写代码”这么窄；OpenAI 明确说 agent 生成的是“application logic, tests, CI configuration, documentation, observability, and internal tooling”。OpenAI

3. 为什么现在重要

• 单 agent 在复杂项目上会失焦、早停、过度自信；Cursor 明说单 agent 适合聚焦任务，但面对复杂项目“slow for complex projects”。Cursor scaling agents
• 随着 agent 运行时间变长、任务链变深，真正的瓶颈从“模型会不会写”转向“系统会不会稳定地让它持续做对的事”。
• 所以竞争壁垒开始从模型参数，转向环境设计、文档结构、边界约束、评测体系和恢复机制。

Harness Engineering 的组成部分

1. 仓库知识要成为 system of record

OpenAI 的一个核心观点是：agent 能看到的才存在，不能在运行上下文中访问的知识，对 agent 等于不存在。

"From the agent’s point of view, anything it can’t access in-context while running effectively doesn’t exist."

"We made repository knowledge the system of record"

他们反对一个臃肿的单文件 AGENTS.md，转而把 AGENTS.md 当目录，把真正的知识放进结构化 docs/、架构文档、执行计划、技术债跟踪与质量文档中，并用 linter / CI 机械检查其新鲜度与交叉链接。OpenAI

含义：

• harness 的第一层不是模型，而是“仓库内可检索、可验证的知识组织”。
• 文档不是给人看的附属品，而是 agent 的运行时依赖。

2. 让应用、日志、指标、trace 对 agent 可见

OpenAI 把 UI、日志、指标、trace 都做成 agent 可调用的运行时能力：

"Logs, metrics, and traces are exposed to Codex via a local observability stack"

"Agents can query logs with LogQL and metrics with PromQL."

并给出类似 "ensure service startup completes in under 800ms" 这样的可验证目标。OpenAI

这意味着 harness 不只是代码生成器，而是“agent 可观测的测试与诊断平台”。

3. 架构与 taste 要靠机械约束，不靠口头约定

OpenAI 明确强调：

"By enforcing invariants, not micromanaging implementations, we let agents ship fast without undermining the foundation."

它们使用分层架构、定制 linter、结构测试、命名规范、日志规范、文件大小约束等方式，为 agent 提供硬边界。OpenAI

这和传统“给人写代码规范”不同：

• 对 agent，模糊规范几乎等于没有规范；
• 规则越能转为程序检查，越容易规模化复用；
• taste 需要被编码成 lint / test / docs，而不是停留在 code review 口头意见里。

4. Throughput 会改变 merge 哲学

OpenAI 公开指出，在 agent 吞吐远高于人类注意力时，过重的阻塞式合并门槛会变成系统性瓶颈：

"Test flakes are often addressed with follow-up runs rather than blocking progress indefinitely."

"In a system where agent throughput far exceeds human attention, corrections are cheap, and waiting is expensive."

来源：OpenAI

这并不意味着放弃质量，而是把质量控制从“每一步人工卡死”转向“快速前进 + 后续自动修正 + 周期性清理”。

5. 需要持续做 entropy control / garbage collection

OpenAI 很坦率地承认全 agent 代码库会累积“AI slop”，他们早期甚至每周五花 20% 时间做清理，后来才把“golden principles”编码进仓库并由后台任务持续发起小型清理 PR。OpenAI

这说明 harness 不是“一次搭好”的系统，而是持续维护的软件工厂：

• 需要周期性质量评分；
• 需要 refactoring PR 自动生成；
• 需要技术债像垃圾回收一样被持续处理。

6. 长程任务依赖 durable project memory，而不是超长单 prompt

OpenAI 在 Run long horizon tasks with Codex 中把 long-horizon coding 拆成了非常明确的 agent loop：

"Plan" -> "Edit code" -> "Run tools" -> "Observe results" -> "Repair failures" -> "Update docs/status" -> "Repeat"

并明确指出：

"Long-running work is less about one giant prompt and more about the agent loop the model operates inside."

"The most important technique was durable project memory."

来源：Run long horizon tasks with Codex

它给出的文件栈也很值得注意：

• prompt.md：冻结目标与约束；
• plans.md：里程碑与 acceptance criteria；
• implement.md：运行手册；
• documentation.md：状态与决策日志。

这与 OpenAI 主文里“repository knowledge is the system of record”形成直接互证：

• harness 的核心是外部化状态；
• 任务越长，越依赖可回看的结构化记忆；
• 让 agent 长时间不漂移的关键，不是无限加上下文，而是把上下文整理成可重访的项目内工件。

7. ExecPlan / AGENTS / PLANS 说明 harness 不只是理念，而是可落地模板

OpenAI Cookbook 的 Modernizing your Codebase with Codex 把这种做法进一步模板化。它建议在仓库中建立 .agent/AGENTS.md 和 .agent/PLANS.md，并把复杂改造工作收敛到 ExecPlan 驱动的多阶段流程中。Modernizing your Codebase with Codex

关键表述：

"Give Codex a lightweight contract for how planning works in this repo"

"These explain what an ExecPlan is, when to create or update one, where it lives, and what sections every plan must have."

这意味着 harness engineering 在实践上至少包含三类 repo 内契约：

• agent 如何理解仓库的契约：AGENTS.md
• agent 如何规划复杂任务的契约：PLANS.md / ExecPlan
• agent 如何验证自己完成了任务的契约：validation docs / tests / parity checks

换句话说，harness engineering 并不是一句抽象口号，而是能沉淀成文件结构、计划模板和执行脚手架的工程方法。

Cursor 文章给出的互证

1. Cursor 证实了“结构比聪明更重要”

在 Towards self-driving codebases 中，Cursor 说他们“created a new agent harness to orchestrate many thousands of agents”，而且系统可以运行一周、完成大部分提交。Cursor self-driving codebases

这和 OpenAI 的观点高度一致：突破点不是单个 agent 更聪明，而是 harness 让大量 agent 可被编排、被观察、被收敛。

2. 平铺式自协调很快失败

Cursor 的早期方案是多 agent 共享协调文件，但很快出现锁竞争、忘记释放锁、状态混乱等问题：

"20 agents would slow to the throughput of 1-3"

"The coordination file quickly created more problems."

来源：Cursor self-driving codebases；Cursor scaling agents

它说明 harness engineering 不能只理解为“多开几个 agent 并行跑”，而是必须解决同步、 ownership、任务切分和信息回流问题。

3. 最终有效的是 planner / subplanner / worker 的层次系统

Cursor 最终收敛到 root planner、subplanner、worker 的递归结构，worker 只做单一任务，planner 负责全局拥有权与后续决策；handoff 不仅传结果，还传 "notes, concerns, deviations, findings, thoughts, and feedback"。Cursor self-driving codebases

这与 OpenAI 的“人负责高层意图、agent 负责执行”形成互证：

• 大任务必须拆为多层 ownership；
• handoff 必须结构化，才能支撑长期自治；
• 高吞吐系统不能依赖人人都知道全局，而是依赖清晰的局部责任与信息上卷。

4. 正确率与吞吐量之间需要工程取舍

Cursor 明确写到：

"When we required 100% correctness before every single commit, it caused major serialization and slowdowns of effective throughput."

他们更倾向接受一个“小而稳定的错误率”，再靠最终收口到 green branch 的修复阶段控制发布质量。Cursor self-driving codebases

这个观点与 OpenAI “merge gate 变轻、修正更便宜”高度一致，是目前公开材料中最值得关注的共识之一。

Harness Engineering 与评测 / Evals 的关系

如果说 harness 是 agent 的“运行系统”，那 evals 就是这个系统的“仪表盘和回归测试框架”。

OpenAI 官方 Agent evals 文档写得很直接：

"Measure agent quality with reproducible evaluations."

"For identifying errors at the workflow-level, we recommend our trace grading functionality."

来源：Agent evals

OpenAI 官方 Trace grading 文档进一步定义：

"Trace grading is the process of assigning structured scores or labels to an agent’s trace"

"Unlike black-box evaluations, trace evals provide more data to better understand why an agent succeeds or fails."

来源：Trace grading

这说明 harness engineering 不是“先让 agent 跑起来，再想办法测”，而是要把以下能力内建进去：

• 端到端 trace 留存；
• 对工具调用、决策路径、失败点的结构化打分；
• 可以大规模回归的 eval 运行；
• 把“为什么失败”而不是只看“结果对不对”纳入系统反馈。

换句话说：

没有 eval / trace grading 的 harness，很难稳定演化；
没有 harness 的 evals，也很难真正改善 agent 在真实工程流里的表现。

2. skill / workflow 的 eval 更接近“轻量端到端测试”

OpenAI 在 Testing Agent Skills Systematically with Evals 里把 agent skill 的评测说得非常工程化：

"Concretely, an eval is: a prompt -> a captured run (trace + artifacts) -> a small set of checks -> a score you can compare over time."

"In practice, evals for agent skills look a lot like lightweight end-to-end tests"

来源：Testing Agent Skills Systematically with Evals

这对 harness engineering 很关键，因为它说明：

• harness 的评测对象不是只看最终回答文本；
• 还要看 agent 有没有调用正确 skill、执行预期命令、生成约定输出；
• trace、artifacts、command execution 本身就是评测材料。

这比传统 LLM eval 更贴近真实软件工程，也更接近 survey session 里应强调的“系统性方法论”。

3. eval 不是孤立模块，而是持续改进 flywheel 的一环

OpenAI 官方 Agent evals 还明确把它和持续改进绑在一起：

"Operate a flywheel of continuous improvement using evaluations."

而在 Safety in building agents 中，又把 trace graders 和 evals 作为多 agent workflow 的安全与质量缓解手段之一。Safety in building agents

这进一步支持一个判断：

harness engineering = 运行时脚手架 + 观测 + 评测 + 安全约束 + 持续修正的闭环。

Harness Engineering 与 AI-native engineering team 的关系

OpenAI 官方 Building an AI-Native Engineering Team 给了一个更组织化的视角：coding agents 正在把工程团队从“自己做所有实现”转向“把大量 SDLC 阶段交给 agent 首轮执行，人类负责 review / own / direction”。Building an AI-Native Engineering Team

其中几条很值得和 harness engineering 放在一起看：

• "Persistent project memory"
• "Evaluation loops"
• "Structured tool execution"

这实际上说明，组织层面的 AI-native engineering，底层正是 harness engineering：

• 如果没有持久项目记忆，agent 无法稳定参与长流程；
• 如果没有结构化工具执行，agent 产出不可验证；
• 如果没有 evaluation loops，团队无法知道 agent 是在变好还是只是在漂移。

Harness Engineering 与 Benchmark 的关系

1. Benchmark 是外部度量，harness 是内部生产系统

SWE-bench 的定位是公开基准，衡量 agent 在真实软件工程问题上的解决率；官网强调 "% Resolved" 作为核心指标，并列出 Verified、Lite、Multilingual、Multimodal 等变体。SWE-bench

因此：

• benchmark 用来回答“你的 agent 在标准题上表现如何”；
• harness 用来回答“你的团队能否在真实仓库里持续做出可交付变更”。

两者相关，但不能互相替代。

2. 公开基准很重要，但不足以覆盖真实 agent 工程问题

OpenAI / Cursor 的文章都更强调真实仓库中的长期运行问题：

• 文档是否可检索；
• 日志/trace 是否可访问；
• agent 是否会漂移；
• 多 agent 是否会互相踩踏；
• 架构边界是否能被机械执行；
• merge / review / cleanup 能否闭环。

这些问题不是单一 benchmark 分数能完整描述的，所以 harness engineering 可以看作 benchmark 之外的“生产工程层”。

3. EVMbench 提醒我们：benchmark 也会反过来推动 harness 设计

Paradigm 与 OpenAI 联合发布 EVMbench 时，用词很直接：

"Together with OpenAI, we built EVMbench to measure exactly that."

"EVMbench is an open evaluation framework that tests AI agents across detecting, patching, and exploiting vulnerabilities."

"We’ve also extended the benchmark harness into an auditing agent"

来源：Paradigm - Introducing EVMbench

这里有一个非常重要的信号：

• benchmark 不只是外部排行榜；
• benchmark 的容器化环境、answer key、任务封装，本身就在塑造 harness；
• 当 benchmark 足够贴近真实工作流时，它会自然长成一个可复用的 agent harness。

它和我们当前 blog / 功力系统 / survey sessions 的相关之处

当前工作区里没有现成的 survey sessions 或已有 harness engineering 调研文件，因此本次是新建调研。结合你的描述，harness engineering 和你们现有内容体系最相关的地方至少有四个：

1. 对 blog 来说，它是一个上位框架

如果你们 blog 已经在写 agent、评测、工作流、技能系统、代码生成、自动化开发，那么 harness engineering 可以作为一个总纲，把这些零散主题串起来：

• 不是只谈 agent 能力；
• 而是谈“怎样设计一个 agent-first 的工程系统”。

2. 对“功力系统”来说，它非常像工程内功

如果“功力系统”强调的是长期积累、基本功、抽象能力、方法论沉淀，那么 harness engineering 正是 agent 时代的软件工程内功：

• 文档治理能力；
• 约束编码能力；
• 评测建设能力；
• 工作流设计能力；
• 可观测性与质量回收能力。

它不像 flashy demo，更像“把 agent 变成稳定生产力”的底层功法。

3. 对 survey sessions 来说，它很适合做系列主题

这个话题不该只做成一篇新闻摘要，后续完全可以拆成系列：

• Harness Engineering 是什么
• Agent legibility 与 repository as system of record
• Trace grading 与 agent eval flywheel
• Multi-agent orchestration 的设计模式
• Throughput vs correctness 的工程权衡
• Agent-first codebase 的 garbage collection

4. 对实际系统设计来说，它可直接映射到你们自己的 agent 产品/内容体系

如果你们已经有 blog 系统、技能系统、survey session 机制，那么可以把 harness engineering 直接翻译为内部建设议题：

• 知识是否沉淀在 repo / docs，而不是散落在聊天和口头沟通；
• 规则是否能被 lint / CI / grader 机械执行；
• agent 每次执行是否留下 trace、可复盘结果与失败原因；
• 是否有定期 cleanup / refactor / debt paydown 的后台流程；
• 是否建立了从任务定义到 PR 合并的闭环。
• 是否已经形成 spec -> plan -> implement -> verify -> document -> review -> merge 的标准回路。

对我们自己的可执行启发

1. 先做知识底座，再做更强 agent

比起继续堆 prompt，优先做这些事情更符合 harness engineering：

• 给仓库建立清晰的 AGENTS.md 目录索引；
• 把产品规则、架构规则、执行计划、质量标准写进 repo；
• 用 CI 检查文档 freshness 和 cross-link completeness。
• 给长任务建立持久项目记忆文件，而不是只依赖会话上下文。

2. 先做可观测性，再做自治

如果 agent 不能看日志、trace、指标、UI 状态，它就只能“猜”。Harness engineering 的核心恰恰是减少猜测，让 agent 能自己验证。

3. 先做约束编码，再做规模化并发

没有边界时，多 agent 容易把错误放大；有边界时，多 agent 才能带来真实吞吐提升。

4. 先做 eval flywheel，再谈可靠交付

OpenAI 近几篇文档连起来后，比较清楚的一条路线是：

• 用 AGENTS.md / docs / plans 建立可消费知识；
• 用 long-horizon loop 建立可持续执行；
• 用 trace grading / skill eval 建立可回归判断；
• 用 cleanup / doc gardening / follow-up PR 建立可持续收敛。

要把 agent 的成功标准写成可重复跑的 eval / trace graders，而不是只靠人工体验判断“这次看起来还行”。

证据状态

高共识（多个独立来源一致）

• 人类工程师的角色正在从直接编码转向环境设计、意图指定、反馈与审查。OpenAI InfoQ
• 多 agent 系统如果没有清晰结构和 ownership，会陷入锁竞争、重复劳动和漂移。Cursor self-driving codebases Cursor scaling agents
• 长期可用的 agent 工程体系必须依赖可观测性、文档系统、机械约束与评测闭环。OpenAI Agent evals Trace grading
• 长时程可靠性依赖持久项目记忆、计划文件和循环式验证，而不是单次长 prompt。Run long horizon tasks with Codex Modernizing your Codebase with Codex

单一来源（需谨慎，但很重要）

• OpenAI 的 0 lines of manually-written code、约百万行代码、约 1500 个 PR、3.5 PRs / engineer / day 等具体数字，目前主要来自 OpenAI 官方自述。OpenAI
• OpenAI 关于“每周五 20% 时间清理 AI slop”的描述，也是官方单一来源，但对理解 agent codebase entropy 很有价值。OpenAI

矛盾信息 / 表述差异

• OpenAI 的文章更偏“单仓库 agent-first product engineering”，Cursor 的文章更偏“多 agent 大规模自治编排”。二者不是直接矛盾，而是强调层级不同：OpenAI 更像团队生产方式，Cursor 更像编排系统设计。
• Benchmark 领域和生产系统领域也存在表述差异：公开榜单容易把焦点放在 % Resolved，而 OpenAI / Cursor 更重视真实工作流中的收敛、可恢复和可维护性。这不是冲突，而是评价维度不同。
• OpenAI 的官方材料更强调 repo 内知识、计划文件、验证回路与团队工作方式；Cursor 的材料更强调 planner-worker 编排、吞吐与同步开销。两边互补后，harness engineering 的轮廓才更完整。

一句话总结

Harness engineering 说的不是“让 AI 帮你写代码”，而是“把软件工程重新组织成一个 agent 能稳定运行的系统”。它最相关的不是单个 demo，而是文档、约束、评测、观测、review、merge、cleanup 这些过去常被忽略、但在 agent 时代决定成败的基础设施。

参考来源

• OpenAI - Harness engineering: leveraging Codex in an agent-first world
• Cursor - Towards self-driving codebases
• Cursor - Scaling long-running autonomous coding
• OpenAI API Docs - Agent evals
• OpenAI API Docs - Trace grading
• OpenAI Developers Blog - Run long horizon tasks with Codex
• OpenAI Developers Blog - Testing Agent Skills Systematically with Evals
• OpenAI Developers Guide - Building an AI-Native Engineering Team
• OpenAI Cookbook - Modernizing your Codebase with Codex
• OpenAI API Docs - Safety in building agents
• SWE-bench
• Paradigm - Introducing EVMbench
• InfoQ - OpenAI Introduces Harness Engineering: Codex Agents Power Large-Scale Software Development

流程合规自检表

• [x] 已检查当前工作区，未发现现成 survey sessions / harness engineering 调研文件
• [x] 已并行调研 OpenAI 主文、Cursor 两篇主文及相关评测资料
• [x] 已保留关键 URL
• [x] 已保留关键原文摘录
• [x] 已区分高共识 / 单一来源 / 表述差异
• [x] 只交付一个最终 Markdown 文件