盒子
盒子
文章目录
  1. 前言
  2. 一、风向：不是 AI 不行，是「敞开供应」这种用法太原始
  3. 二、三层瓶颈：能下手的，其实只有最上面一层
  4. 三、上下文工程：方向我看对了，也看清了新词是怎么造出来的
  5. 四、上下文工程真正难的另一半，不在技术，在组织
  6. 五、从 MindHub 的落地，看「为什么有人吃到红利、有人还没动」
  7. 最后
  8. 参考

关于 AI 现状与未来的思考

2026.06.13 JerryC 三省吾身  热度 ℃

一年 AI 实践之后的一些思考

#前言

去年下半年，我刚带完一场格式会战——三地六团队三十多人，忙了大半年。会战收官，支援的兄弟们陆续归位，回到各自原来的岗位，格式引擎重新变回几个人维护的常态。这本是仗打完之后的正常收场，但也让我开始想一件事：这么一个跑了好几年、几十万行代码的复杂领域，未来要靠这几个人撑着，那些散落在很多人脑子里的门道，怎么留下来？

那段时间我在琢磨：能不能用 AI，把「领域专家」这件事沉淀下来？于是有了 DocExpert——我把二十万行格式代码当成一个信息论上的「降熵」问题，先做语料工程把它压缩成几百篇结构化文档，再用 RAG 检索喂给模型，配上 Spec 驱动开发（AI-SDD），让 AI 沿着「需求 → 方案 → 拆解 → 实现」往下走。

那是我第一次真切地感到：研发和编码的方式，要被彻底改写了。后来我从 0 立项做的 MindHub（一套围绕大模型的研发支撑系统，把「裸模型」变成可靠的研发生产力），就是从这个判断里长出来的。

这半年，我自己几乎是泡在 AI Coding 里过来的。一个数字我自己都觉得离谱：这半年我用 vibe coding 写出来的代码，大概一百二十万行，比我过去十年写的加起来还多。

我说这些，不是想晒用得多深。而是想说：正因为用得深，最近半年行业里那些信号，我才格外有体感——它们看着零散，甚至有点互相矛盾，但我隐约觉得，背后有某种共性的问题没被说清楚。

这篇就是想把这点东西捋一捋。算不上结论，更像「想到这儿了」的一份笔记。

#一、风向：不是 AI 不行，是「敞开供应」这种用法太原始

先说最直接的体感：token 的风向，这半年坐了趟过山车。

年初还在「敞开供应」。我自己就在这趟车上——2026.2，我们每人每月能批到 $3000 额度，leader 点头还能加到 $6000，氛围是「你尽管用」。到 6 月，我的额度降到 $1000，而这点额度，我一周就能用完。

不只是我们。微软 2025.12 才把 Claude Code 开放给数千名员工，鼓励大家用 vibe coding 重塑工作流；到 2026.5 就开始收回许可，理由是「烧 token 已经比养员工还贵」。Uber 更夸张，全年的 AI 编程预算，前四个月就烧光了。半年之内，行业从「随便用」翻到「省着用」。

只看这个表象，很容易觉得：AI 是不是要退潮了？

我的看法正好相反。「烧不起」不是 AI 不行，是用法还很原始。

先说个反直觉的事实：我天天用的前沿模型，单价其实没怎么降。 Claude Opus 从 4.5 到 4.8，一直钉在 $5/$25（每百万输入/输出 token），几代没动；中间换 tokenizer 的那一版，同样的输入还要多切出三成 token，等效成本不降反升。

但要说「模型单价在降」，作为行业趋势也没错——只是降在别处。开源追赶者把「同等智能」的价格一路打下来：DeepSeek V4 的缓存命中输入压到了每百万 token 几分钱，输出也只要几块钱；Epoch 的测算也显示，达到 GPT-4 同等性能的推理成本，几乎每年降一个数量级。

所以单价这件事，是「前沿没降、同档在崩」。可不管你站哪一边，账单都在涨——因为真正爆炸的不是价格，是用量。 Agent、长上下文、一轮套一轮的推理（Reasoning），把单任务的 token 量撑到了过去的几倍、几十倍。实测推理模型一次回答烧的 token 约是普通模型的 2.5 倍，有些 Agent 产品的 token 膨胀甚至到二十倍。

于是真正的悖论是：哪怕单价原地不动，光是用量的暴涨，就足以让账单失控。

所以「敞开供应」注定撑不住。它不是被 AI 的失败击穿的，恰恰是被 AI 太好用击穿的——人人敞开烧，账自然兜不住。市场规模已经验证，真正的问题从「值不值得用」变成了「怎么才用得起」。风向变了，但方向没错。

#二、三层瓶颈：能下手的，其实只有最上面一层

顺着「怎么才用得起」往下想，我慢慢把它整理成了一个三层的模型。

我们总说 AI 还没真正大规模用起来。那「用起来」这件事，到底卡在哪几层？我的答案是三层，自下而上：物理资源、模型优化、上下文工程。

最底下一层，是物理资源。 这一层撞的是自然世界的天花板——算力、能源、数据中心。

这里有个反直觉的地方：现在卡脖子的，已经不是芯片，而是电。微软有上百亿美元的云订单，因为没有足够的电力，迟迟交付不了。美国 2026 年规划的数据中心，相当一部分卡在变压器、电网这些环节上，而电网的建设周期动辄数年。芯片可以加钱排队，电网不行。

这事到底有多被当真？国内在推雅鲁藏布江下游水电工程这种级别的项目，背后的算力与能源需求是绕不开的一环；马斯克那边走得更极端，他认真讨论过「地球每年新增电力大约只能做到 1 太瓦，这是硬上限」，所以要把 AI 算力搬到月球和太空去——那里太阳能效率是地面的好几倍。一个连「把数据中心搬上太空」都开始有人当正经事算的领域，你就知道这层物理约束有多硬。它不是砸钱当天就能解决的。

中间一层，是模型优化。 这一层是模型厂商的战场——同样一份「智能」，怎么做得更便宜、更快、更省。

前面说的单价每年降一个数量级，就发生在这一层。但这件事，大多数人插不上手，原因有两道坎：一道是硬件准入门槛——训一个有竞争力的模型，光算力投入就是天文数字，组织级的门票，不是个人能够着的；另一道是知识鸿沟——就算身在大厂、坐在岗位上，预训练、推理优化这些活儿，跟我这种做应用的工程师之间，也隔着一条不浅的专业沟。这一层，注定是少数人的战场。

最上面一层，是上下文工程（Context Engineering）。 这一层做的是：把模型那份通用的能力，对齐到一个具体的、真实的场景里去。

讲到这儿，三层的关系就清楚了。底下两层决定的是「单位智能有多便宜」，最上面这层决定的是「便宜的智能，能不能真的变成生产力」。

而最关键的判断是：前两层都在快速改善——电力在建，单价在塌——可真实世界的生产力，并没有跟着同比例往上走。姚顺雨把这个叫「效用问题」（utility problem）：AI 在各种榜单上早就超人了，可真实世界的 GDP 没怎么动。缺口卡在哪？我认为就卡在最上面这一层。

底下两层我够不着。物理资源是国家和巨头的事，模型优化是厂商的事。作为一个做应用的工程师，我唯一能下手的，就是第三层。

而第三层，恰好是我一年前那轮判断的落脚点。

#三、上下文工程：方向我看对了，也看清了新词是怎么造出来的

上下文工程是工程团队的「唯一」战场——我们碰不到模型参数，但可以精心构造 LLM 看到的上下文。

这句话，是我做 MindHub 立项调研时写下的。当时我顺手扒了一圈行业里的声音，想确认自己这个判断站不站得住。今天回头看，它正好接住了上面三层模型的落点。

要理解为什么是「上下文」，得先退远一点看 AI 这七十年。

回看这张时间线，有一条容易被忽略的主线：
最近这一波能力跃迁，靠的不是又一个更聪明的算法，而是把海量知识喂进了一个已经够好的架构。

算法侧，2017 年的 Transformer 之后并没有再出现同量级的突破；真正让 Agent 在 2023 年集中爆发的，是预训练把海量世界知识灌了进去，模型第一次有了在开放世界里干活的「常识」。不是说算法不重要——没有 Transformer 什么都不成；而是说，当架构这一步已经够用，后面拉开差距的，是知识。

这个判断，不是我一个人的臆测。我扒到三篇来自完全不同视角的文章，它们几乎不约而同地指向同一个方向。

第一篇是 姚顺雨的《The Second Half》（2025 年 4 月）。他从强化学习的视角回看 AI 这几十年，结论是个让人意外的优先级翻转：过去大家以为最重要的是算法，磨了三十年；直到 GPT 出现才恍然大悟，让 AI 能泛化的不是更好的算法，而是预训练注入的海量知识。知识 > 环境 > 算法。

第二篇是 Karpathy 的 2025 年度回顾（2025 年 12 月）。他打了个比方：LLM 是操作系统，上下文窗口是内存——我们的活儿，是准备好它运行所需要的数据和环境。「Context Engineering」这个词，比「Prompt Engineering」更本质，就在这儿。

第三篇是 OpenAI 的《Harness Engineering》（2026 年 2 月）。他们一个三到七人的小团队，五个月里用 Codex 写了大约一百万行代码、上千个 PR，0 行人工手写。结论是：工程师的活儿，从「写代码」变成了「设计一个让 Agent 能写好代码的环境」。

三个不同背景的人，在不同时间、从不同角度出发，最后收敛到同一句话上：决定智能能不能用好的，不是模型本身，是模型周围那套东西。 我去年的判断，方向上没看错。

但顺着这件事，我想多说一个我亲历的、更有意思的现象。

这一年，AI 圈的新词冒得特别快。Prompt Engineering、Context Engineering、Harness Engineering，到最近的 Loop Engineering，几乎一个月换一个。很多人觉得这是炒作、是换皮。

我一开始也这么想，后来觉得不对。它不是换皮，而是同一个方向上的形态进化——一句话说，就是人在一步步从 AI 身边往后退：

  • Prompt Engineering：你握着 AI 的手，一句一句喂；
  • Context Engineering：你不光喂指令，还把它该看的料备齐；
  • Harness Engineering：你干脆给它搭好整个环境，让它在里面自己跑；
  • Loop Engineering：连「驱动它干活」这件事都交出去——你只定义目标和验收，剩下的让一套循环自己去敲。

从「握着手」退到「喂对料」，退到「搭环境」，再退到「连驱动都不亲自做」。每一个新词，标记的都是人往后退的一格。这不是换皮，是退后的姿势在迭代。

更有意思的，是 Harness Engineering 这个词跟我自己的关系。

我从今年 1 月就开始做 MindHub 了——围绕大模型搭一整套研发支撑。做的时候它还没名字。直到 2 月，OpenAI 抛出「Harness Engineering」这个词，我才发现：这个词，正好能命名我过去大半年在做、在想的东西。

但我要说的，不是「你看，OpenAI 印证了我是对的」。

我要说的是，这件事本身，印证了一个机制。

当一个工具的使用者基数涨到足够大，大家会撞到高度类似的问题。这时候，一个有名望的人或组织，提出一个能概括这种共同体验的词——它会瞬间引起共鸣，火起来。然后，这个词被无数人接着加工、解读，慢慢被赋予越来越多的意思和愿望，渐渐偏离它最初的本意。

所谓新概念，很多时候不是新发现，而是给一种集体的共同体验，起了个名字。 Harness Engineering 是这样，姚顺雨的「下半场」也是这样。

最近这个 Loop Engineering 更典型：2026 年 6 月 7 日，一位开发者发了条推——大意是「别再往 Agent 里一句句打字了，去设计一个替你打字的循环」，几天里冲到几百万阅读；第二天，另一位有影响力的工程师就发博客把它正式命名为「Loop Engineering」。一条推，一个晚上，一个新词就立住了。

这里我想多留个心眼，提醒一句：提出这些词的人，大多也是卖模型、卖 Agent 产品的人。 Context Engineering 出自 OpenAI 的创始成员，Harness Engineering 是 OpenAI 提的，Loop Engineering 的提出者现在也在 OpenAI。

而这条「人不断往后退、让 Agent 自己多轮跑」的路线，还有个不太被点破的副作用：每往前走一格，单任务烧掉的 token 就翻一截。前面算过，推理模型本就比普通模型多烧两倍多，Agent 自循环更是动辄十几二十倍。换句话说，越往后退，账单越厚——而收账的，恰好是提出这些词的人。

我不是说这些概念是假的。它们指向的方向是真的，我自己也在这条路上。但概念的提出者，和 token 账单的受益者，高度重合——这一点，作为重度使用者，得始终拎得清。

所以概念跑得飞快，但拨开热闹，你会发现很多时候是同一件事，在被反复地重新命名，再被层层包装上新的期待。看清这一点，比追着每个新词跑，要省心得多。

#四、上下文工程真正难的另一半，不在技术，在组织

把上下文工程的方向看对、词也认全，是不是把它做扎实，事情就成了？

真动手做 MindHub 之后我越来越确定：这套「知识驱动智能」的判断，技术只是其中一半，另一半在组织——而组织那一半，要难得多。

这事 Databricks 的 CEO Ali Ghodsi 讲得比我透。他在斯坦福和学生聊 AI 价值链时，有个观点我很认同：企业用不起来 AI，主要不是因为模型不够聪明，而是另外两件事。

一件是，AI 缺企业内部那些藏在人脑里的隐性上下文——流程怎么走、潜规则是什么、当年那个决定为什么那么定。这些东西没人写下来。更麻烦的是组织政治：员工担心自己把经验交出去就被替代了，于是不愿意交。

另一件是，大多数企业只是把 AI 塞进了旧流程里，而没有为 AI 重构一套新流程。Ghodsi 举过他们自己的例子（这是他在分享里讲的口径）：原来做一个生产级的数据连接器要好几个月，引入 AI 后压缩了一些；但真正的飞跃，是后来他们把流程整个重做——需求收集从一个季度压到一周，多人并行、测试环境外包，最后一个季度交付了好几个连接器。重构流程带来的提升，远大于「把 AI 塞进老流程」。

我听完特别有共鸣。因为上下文工程里最难的那一块，从来不在技术，而在组织。技术上，把知识结构化、做好检索、搭好环境，这些都有章可循。可「人脑里的隐性知识愿不愿意交出来」「流程肯不肯为 AI 推倒重来」——这两件事，没有一行代码能直接解决。

#五、从 MindHub 的落地，看「为什么有人吃到红利、有人还没动」

MindHub 做到现在，我是有成就感的。

它已经接进了不少研发项目，也跑出了几个像样的标杆案例——线上 Bug 的 Oncall 从人工流转变成自动流转，产品经理不写代码也能自己做出可点击的原型。这些是实打实的结果。

它大概长这样——一张脱敏后的全景图，隐去了内部基础设施和具体业务代号，只留结构。不必细看每个格子，扫一眼分层就行：最底下是被封装的外部底座，往上是可复用的内核（记忆、LLM 网关、可观测、知识检索等几根能力支柱），内核之上长出研发租户和孵化的标杆产品，最外面统一接入多种 IDE 宿主；一条主轴 MindFlow 把「需求 → AI 实现 → 自动验证 → 交付」串起来。说白了，就是把 OpenAI 那篇 Harness Engineering 讲的事，落成一套自己团队能用的工程底座。

（这是脱敏后的示意图，隐去了内部系统、具体业务与量化数据，只保留分层结构与命名。）

它没有在整个部门一夜之间铺开——这一点，我从一开始就有预期。一套新的研发范式，本来就不可能所有人立刻接受，这是规律，不是失败。所以我不是带着挫败感讲这段，而是想把一个观察到的现象，客观地拆开看看：为什么同一套东西，有的人用得风生水起，有的人迟迟不动？

拆开之后我发现，它跟 Ghodsi 说的，是同一件事的两面。

跑得快、愿意动的那批人和产品，先吃到了效率红利。他们愿意把自己的领域知识喂进去，愿意为了 AI 改自己的流程，于是 MindHub 这套东西在他们手里转得飞快。

跑得慢、还没动的那批，恰好印证了 Ghodsi 说的瓶颈。不是工具不好用，是隐性知识还在脑子里没交出来，是旧流程还没为 AI 让位。

这种「先动的人先受益」的分化，其实并不新鲜。回顾人类历次技术革命，容易看出一个相似的规律：蒸汽机刚进工厂时，最早改造产线的厂子率先尝到甜头；电力替代蒸汽动力的头几十年也一样——真正把效率提上去的，是那些懂得围绕电机重新设计车间布局的工厂，而多数只是把电机一换、产线照旧的，提升寥寥。

工具到位，从来不等于效率到位。中间总隔着一段「先改的人和后改的人拉开差距」的日子。这是生产力跃迁绕不过的阵痛期，AI 这一次，大概也逃不开。

所以问题就摆在这儿了：怎么让红利从「少数跑得快的人」，扩散到更多人？

我现在的判断是——光靠自下而上的自发采用，不够。

自发采用有个天然的天花板：它只会发生在那些本来就主动、本来就跑得快的人身上。这批人吃饱了，剩下的大多数，不会因为「有个好工具」就自动跟上，因为挡住他们的不是工具，是流程和习惯。

要让 AI 真正铺开，还得有一股自上而下的力量下场。具体说，是让真正懂 AI 的人——比如组织里做 harness 的团队——自己走到一线业务里去，亲手用 AI 把一个真实需求从头跑通，在这个过程里，顺带把那条卡了很久的旧流程，重做一遍。

流程一旦被重做，就会反过来「逼」那些还在观望、不愿动的人改变。而很多时候，人就是这样——被推着用上了，真正尝到甜头，才会回过头说一句「真香」。

这不是我已经验证过的结论，是我现在押的方向。对不对，得让时间来说。

而押下这个方向，对我个人也意味着一次身份的切换。我做了很多年前端，但这一年，我在有意地放下「前端工程师」这个旧身份，把重心挪到 AI 上来——学模型、学 Agent、学怎么把 AI 变成可靠的生产力。我有个预感：一个叫「AI 应用工程师」的岗位，正在或者已经诞生了。与其等这个岗位来定义我，不如我自己先走过去。

#最后

写到这儿，前面那些乱糟糟的信号，在我心里大致归位了。

token 从敞开到收紧，不是退潮，是用法在回归理性。概念一个月换一个，也不全是炒作，更多是人在一步步退到 AI 身后——只是别忘了，提词的人往往也在卖账单。而企业迟迟用不起来，问题真不在模型聪不聪明，在组织和流程肯不肯为它让路。

说到底是同一件事的几个侧面——AI 的瓶颈，早就从「模型够不够聪明」，挪到了「我们这些用它的人和组织，跟不跟得上」。

至于更远的地方，价值大概会像每一次技术浪潮那样，慢慢从底层流向应用层。互联网时代真正赚到钱的，是 Uber、Amazon 这些应用，不是底层协议。这一次，我猜也差不多。

但再往后，AI 真的大规模用起来之后，社会会变成什么样——说实话，我还想象不出来。

所以这篇真的只是「想到这儿」的一份笔记，不是什么结论。先记下来，继续走着看。

#参考

支持一下
扫一扫，支持JerryC
  • 微信扫一扫
  • 支付宝扫一扫