兰 亭 墨 苑

标题 *

URL 别名 *

内容 * (支持 Markdown 格式) 去年12月底，Notion 的联合创始人兼 CEO Ivan Zhao 在官网博客上发了一篇文章，叫《Steam, Steel, and Infinite Minds》。它没有谈具体的模型参数或产品功能，而是用"钢铁"和"蒸汽机"的历史隐喻来讲 AI 对个人、组织和经济体的影响。当时就想翻译分享，但年底赶项目交付加上视频课录制，一直没腾出手。正好趁春节空了两三天，就借这篇文章写一些思考。另外，最近发生的两件事让我感触更深。一是大年二十九 Qwen3.5 发布，国产开源模型在 Agent 能力上第一次和 GPT-5.2、Gemini 3 Pro 站到了同一梯队，Plus 版本 API 定价做到了输入百万 token 八毛钱；二是 OpenClaw 这类个人 Agent 工具在过去一两个月的爆火。结合过去两年做企业大模型应用的体感，我觉得我们确实在接近一个应用爆发的临界点：模型能力到位了，成本降到了可以大规模试错的区间，工具和协议的基础设施也成熟了。这篇试图说清楚：Qwen 3.5 和 OpenClaw 背后的成本拐点与应用层趋势、Ivan Zhao 这篇博客的中文翻译（在几个关键节点加了个人批注）、以及从一线做项目的角度聊聊工程方法这个最容易被忽视的事（原文视角是硅谷 SaaS 公司 CEO，我的补充更多是从中国企业大模型应用一线出发）。以下，enjoy:1 两个值得说道的产品/模型1.1 Qwen 3.5：不试白不试先说 Qwen3.5，这次发布的旗舰版是一个 397B 总参数、17B 激活的 MoE 架构模型，在多模态 Agent 任务、数学视觉（MathVision 88.6 刷新纪录）、指令遵循（IFBench 76.5）等多个评测上做到了 SOTA 或接近 SOTA 的水平。<img src="https://pic1.zhimg.com/50/v2-4da345b9347ee68ab8b9a7ccdf0757a0_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="634" data-original-token="v2-5945749bef6e60aeda87abc69f720039" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-4da345b9347ee68ab8b9a7ccdf0757a0_r.jpg?source=2c26e567"/>整体来看，它和 GPT-5.2、Claude Opus 4.5、Gemini 3 Pro 属于同一梯队，在 Agent 自主执行（TAU2 评测 86.7）和多模态理解上表现尤其突出，在竞赛级数学和编码上稍弱一些。但作为一个开源、可私有部署的模型，这个能力水平已经是生产可用了。但更让我关注的是价格，这里我整理了一下从 ChatGPT 3.5 发布至今，关键模型的能力跃迁和成本（百万 token）变化：时间模型输入输出关键意义2023.03GPT-3.5 Turbo$2$2便宜但能力有限，只能做简单对话2023.03GPT-4$30$60能力惊艳，但跑个 demo 就几百块，小公司用不起2023.11GPT-4 Turbo$10$30降了 3 倍，还是不便宜2024.05GPT-4o$5→$2.5$15→$10能力持平 4 Turbo，成本降了一个数量级2024.06Claude 3.5 Sonnet$3$15编程能力很强，让 Cursor 出圈，第一个让我觉得可以上生产的模型2024.12OpenAI o1$15$60第一个思维链推理模型，但隐藏 CoT token 按输出计费，实际成本 2-4 倍2025 初DeepSeek R1≈¥4≈¥15开源推理模型逼近闭源水平，重塑国内价格预期2025 底DeepSeek V3.2≈¥2≈¥3持续降价2026.01Kimi K2.5≈$0.6$2.5-3多模态统一架构，性价比很高2026.01MiniMax M2.5$0.3$1.2编程和办公突出，带缓存综合成本可低到$0.062026.02Qwen3.5-Plus¥0.8—≈GPT-4 的 1/300，Gemini 3 Pro 的 1/18从 2023 年 3 月 GPT-4 的$30/百万 token 到现在 Qwen3.5-Plus 的¥0.8/百万 token，三年不到，同等甚至更强能力的模型，调用成本降了大约 300 倍。为了更好理解成本的前后变化，这里也举个具体的客户例子。去年给一个三百多人的企业做知识库项目，初期讨论 API 预算的时候算过一笔账。系统上线后日活用户大概 80-100 人，每人每天平均 10-15 次提问，每次提问系统要做检索改写加回答生成，平均触发 2-3 次模型调用，单次调用大概消耗 4000 输入 token（含系统提示词和检索到的上下文片段）和 800 输出 token。这样算下来月均 token 消耗大概在 2-3 亿，按当时主流的中高端模型价格（输入输出综合均价大概¥10-15/百万 token），一年光 API 差不多三四万。当然这只是一个知识库问答场景，如果再叠加文档审查、报告生成等 token 消耗更重的任务，成本还要往上翻。按现在 Qwen3.5-Plus 的价格重新算，同样的用量，年 API 成本可能只要几千块。以前很多企业对大模型应用的态度是看看再说，因为试一轮成本不低；现在是不试白不试，试错成本已经低到可以忽略。对于需要多步推理、工具调用的复杂 Agentic Workflow 来说，这个价格拐点尤其关键，我想也算是到了基本可以放开了跑的状态。1.2 OpenClaw：一个人、43 个废弃项目、和第 44 个的爆发再来说说 OpenClaw，这个项目最早是去年 11 月以 Clawdbot 的名字发布的，我当时在 X 上就翻到了些讨论，但碍于当时忙于年底项目交付一直没来得及测试。再然后 1 月底因为 Anthropic 的商标投诉改名 OpenClaw 之后突然爆火，24 小时涨了 2 万 GitHub 星标，到现在已经超过 20 万星了，增长速度超过了 React 和 Kubernetes。<img src="https://picx.zhimg.com/50/v2-110f2a81ff164a1b712bdaa7a1e4cb32_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="674" data-original-token="v2-3bb5658e8f9679c99ca1bb0ff32dc87d" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-110f2a81ff164a1b712bdaa7a1e4cb32_r.jpg?source=2c26e567"/>创始人 Peter Steinberger 也在 2 月 14 号这天被 Sam Altman 亲自官宣加入了 OpenAI（Anthropic 对比之下格局确实小了点）。<img src="https://pic1.zhimg.com/50/v2-a9fe293594add2e5eb6b0c636f6e0f69_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="772" data-original-token="v2-42b2dcdf865ea2f0a42735a0c93ce1dc" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-a9fe293594add2e5eb6b0c636f6e0f69_r.jpg?source=2c26e567"/>这个人是谁但如果去翻一下这个人的背景，就会发现他根本不是什么 AI 领域的新人碰巧蒙对了。Steinberger 之前做了 13 年的 PDF 组件产品 PSPDFKit，算是在移动开发圈子里算是很知名的工具型产品，21 年卖了公司套现过亿美元。之后据说经历了一段迷茫期，他在自己的博客（http://steipete.me）里也写过这段经历。<img src="https://pic1.zhimg.com/50/v2-112565b8f20cd2cd3f3e317f112b9dd7_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="921" data-original-token="v2-76d9041f11f988f937bafc4149b4fa8a" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-112565b8f20cd2cd3f3e317f112b9dd7_r.jpg?source=2c26e567"/><img src="https://picx.zhimg.com/50/v2-28cbf1ceadd97ad7cddad3a2c770e07d_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="496" data-original-token="v2-46220033fa043e9f8db4b6063c428411" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://pic1.zhimg.com/v2-28cbf1ceadd97ad7cddad3a2c770e07d_r.jpg?source=2c26e567"/>三年后重新开始用 AI 工具折腾，从他的 GitHub 可以看到，他先后做废了 43 个项目，OpenClaw 是第 44 个。最初只是去年 11 月用了一个小时把 Claude API 接进 WhatsApp，用他自己的话说，当时觉得这就是个"weekend hack"（一个玩具）。怎么做出来的根据他在 GitHub、博客以及后来接受 Lex Fridman 采访时的描述，OpenClaw 的开发过程其实非常朴素。他自己每天用这个工具，用着用着发现 agent 发不了消息，就加了个消息模块；发现 agent 看不了屏幕上的东西，就加了个屏幕读取的功能；发现 agent 管不了邮件，就写了个邮件的集成。<img src="https://pic1.zhimg.com/50/v2-8f35dfeebcc087cd891bbf62e7a9c41a_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="742" data-original-token="v2-52af964de5e7612cba341e0f145caf33" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://pic1.zhimg.com/v2-8f35dfeebcc087cd891bbf62e7a9c41a_r.jpg?source=2c26e567"/>感兴趣的可以看原视频他的 GitHub 简介写的是："Ship beats perfect — I build tools to solve my own problems, then share them with the world"（先做出来比追求完美更重要——我造工具是为了解决自己的问题，然后分享给全世界）。GitHub 上那 40 多个 CLI 小工具，每一个的出发点都是"我自己在用的时候缺什么"。别人是先画产品蓝图再开发，他是先用起来再一点点补齐。而且他后期基本不自己写代码了，而是指挥 agent 来写，同时并行跑 3 到 6 个 agent 实例，光今年 1 月就提交了超过 6600 次 commit。<img src="https://picx.zhimg.com/50/v2-5186ba10f8c883511070109a9d53aac5_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="257" data-original-token="v2-6d8095515fb6f8ee6f93cf4756ef4bfb" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-5186ba10f8c883511070109a9d53aac5_r.jpg?source=2c26e567"/>所以要说 OpenClaw 有什么技术突破，个人感觉确实没有啥，毕竟底层用的还是主流的大模型 API、RAG 检索、MCP 工具调用这些现成的能力。它做的事情是把这些零散的能力缝合成了一个开箱即用的个人 Agent，能接各种 IM 平台，能跨会话记住你的偏好和上下文，预置了 100 多个日常任务的 AgentSkill，可以接本地模型跑在自己的服务器上，数据不出本机。有人说它是一个巨大的套壳，这个说法也没错，但关键是这个套壳过程经过了好几个月真实场景的反复打磨和验证。可参考的启示让我觉得值得专门拿出来聊的，不是已经被很多自媒体吹嘘的 OpenClaw 本身有多好用，而是它背后证明了一件事。当模型能力、API 成本、MCP 工具协议这些基础设施成熟到一定程度之后，一个有足够产品直觉和工程手感的人，就能用现成的积木搭出让大厂都紧张的东西。OpenClaw 也确实很好证明了 Agent 层不独属于模型公司，入口可以脱离模型而独立存在。但反过来说，这件事也很好地说明了一个容易被忽略的常识。AI 工具确实能成百上千倍地放大一个人的产出，但它放大的是你已有的东西。Steinberger 能做出 OpenClaw，靠的不是 AI 有多强，而是他 13 年做产品的手感、43 个失败项目的试错经验、以及对"用户到底需要什么"这个问题的体感积累。工具变了，但产品的基本功没有变。对于做企业大模型应用来说也是一样，模型再强、成本再低，如果不理解业务场景、不清楚怎么把需求翻译成可执行的工作流、不知道怎么评估和迭代，工具再好也只是摆设。这个基本功恰恰是最需要通过真实案例和系统方法论来补齐的。2 翻译转载《Steam, Steel, and Infinite Minds》原文作者：Ivan Zhao（Notion 联合创始人兼 CEO）原文发布日期：2025 年 12 月 23 日<img src="https://pica.zhimg.com/50/v2-a2892da003d7ce577c012a5d79f1c5ca_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="435" data-original-token="v2-32655737dc59de562ffd58046632c94e" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-a2892da003d7ce577c012a5d79f1c5ca_r.jpg?source=2c26e567"/>备注：为控制篇幅，以下翻译在忠实原意的基础上对部分修辞性重复和过渡句做了精简，未改变任何实质内容。建议感兴趣的读者阅读原文。每个时代都有它的"奇迹材料"。钢铁铸就了镀金时代，半导体开启了数字时代。现在 AI 来了，作为"无限心智"登场。谁掌握了那个时代的核心材料，谁就定义了那个时代。<img src="https://pica.zhimg.com/50/v2-81666e7a5d7f07a63bcd8c2cd0f45a36_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="721" data-original-token="v2-b73baf0b6e990bd5d02a3978b8fcfe71" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://pic1.zhimg.com/v2-81666e7a5d7f07a63bcd8c2cd0f45a36_r.jpg?source=2c26e567"/>1850 年代，安德鲁·卡内基还是个在匹兹堡泥泞街道上送电报的男孩，那时六成美国人都是农民。但仅仅两代人之后，马车让位于铁路，烛光让位于电灯，铁让位于钢。此后工作的重心从工厂转移到了办公室。今天我在旧金山经营一家软件公司，给数百万知识工作者做工具。所有人都在谈 AGI，但全球 20 亿坐在办公桌前的人，大多数还没真正感受到它的变化。<img src="https://picx.zhimg.com/50/v2-a2b65741504326363b4bbf1ce6c474d7_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="678" data-original-token="v2-4a715d298adc42bfa44e3ff460e901e5" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://pic1.zhimg.com/v2-a2b65741504326363b4bbf1ce6c474d7_r.jpg?source=2c26e567"/>未来往往很难预测，因为它总是伪装成过去的样子。早期的电话简短得像电报，早期的电影就是拍下来的舞台剧。麦克卢汉说过："我们总是通过后视镜驶向未来。"今天的 AI 聊天框长得和 Google 搜索框一模一样——我们正处在技术变革中那个"不上不下"的过渡期里。<img src="https://picx.zhimg.com/50/v2-cf3f8781e00937a95f12d016d703512a_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="1253" data-original-token="v2-a2ac8fb1d0fa623f196f2c134b72fe0b" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-cf3f8781e00937a95f12d016d703512a_r.jpg?source=2c26e567"/>后面的事情会怎样，我没有全部的答案。但我想借几个历史隐喻，聊一聊 AI 在不同尺度上可能的工作方式——从个体，到组织，到整个经济体。2.1 个体：从自行车到汽车最先感受到变化的，是知识工作里的"高阶祭司"：程序员。我的联合创始人 Simon 过去是我们常说的"10 倍程序员"，但他现在几乎不写代码了。你走过他的工位，会看到他同时开着三四个 AI 编程 Agent，这些 Agent 不只是打字快，它们会"思考"——这让 Simon 变成了一个 30-40 倍的工程师。他会在午饭前或者睡前排好任务队列，让 Agent 在他不在的时候继续跑。他变成了一个"无限心智的管理者"。【批注①】 这段描述和我自己做项目的体感非常一致。去年开始，我在做企业大模型项目时也逐渐切换到了类似的工作模式，超过 80%的代码不是我或者团队亲手写的，而是把任务拆成清晰的指令和验收标准，丢给 AI Coding Agent 去跑，我来做抽检和纠偏。前面提到的 OpenClaw 的创始人 Steinberger 也是同一个路子，同时并行 3-6 个 Agent 实例。这种转变的核心不是 AI 替我干活了，而是你的工作重心从执行上移到了&quot;设计任务、定义质量标准、复盘迭代&quot;。从骑自行车变成了开车，换句话说，你不用自己蹬了，但你得知道往哪开、走哪条路。<img src="https://picx.zhimg.com/50/v2-370ed97cbe88fd27c10bd30988c85011_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="695" data-original-token="v2-0f98e59eb2a68944bed5e901bffa79e0" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-370ed97cbe88fd27c10bd30988c85011_r.jpg?source=2c26e567"/>1980 年代乔布斯把个人电脑叫做"心智的自行车"，但直到今天，绝大多数知识工作仍然是人力驱动的——就好像我们一直在高速公路上骑自行车。有了 AI Agent，像 Simon 这样的人相当于从骑车升级到了开车。那其他类型的知识工作者什么时候能开上车？有两个问题需要先解决。2.2 两个关键阻塞：上下文碎片化与可验证性第一个问题是上下文碎片化。对于编程来说，工具和上下文基本集中在一个地方：IDE、代码仓库、终端。但一般的知识工作散落在几十个工具里。想象一下，一个 AI Agent 要帮你写一份产品方案：它需要从 Slack 对话里提取讨论结论、从战略文档里拿方向、从上季度的数据看板里抓指标、还有一些只存在于某个人脑子里的"部落知识"。今天这些事情全靠人来做——复制粘贴、来回切标签页。只要上下文没有被统一整合，Agent 就只能困在狭窄的单点场景里。【批注②】 原文说的是 Slack、Docs、Dashboards。换成中国企业的真实组合就更明显：微信/企微聊天记录、飞书/钉钉文档、各种 OA/ERP/CRM 系统、邮件、共享网盘、甚至纸质的制度手册和审批流。中国企业的上下文碎片化程度比硅谷还严重得多。但反过来说，一旦有人能把这些碎片缝合成一个统一上下文层，带来的效率提升反而更大。毕竟原来靠人肉粘合的成本更高。这也是为什么我觉得在中国做企业大模型应用落地，知识库和工具整合这一层的价值特别大。第二个缺失的要素是可验证性。代码有一个神奇的特性：你可以用测试和报错来验证它对不对。模型厂商也利用这一点，通过强化学习让 AI 在编程上越来越强。但你怎么验证一个项目管理得好不好？一份战略备忘录写得行不行？我们还没有找到系统性的方法来提升模型在一般知识工作上的表现。所以人类仍然需要留在回路中，去监督、引导、示范什么是"好的产出"。<img src="https://picx.zhimg.com/50/v2-6b10e61ec3b5d0ed5ef98dd3d087ff57_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="679" data-original-token="v2-febd385e154df861765a2e6df7e66d80" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-6b10e61ec3b5d0ed5ef98dd3d087ff57_r.jpg?source=2c26e567"/>今年的编程 Agent 经验告诉我们，"人在回路中"并不总是件好事。这就像让人亲自检查流水线上的每一颗螺栓，或者在汽车前面举旗开路（参见 1865 年的"红旗法案"）。我们要的不是人在循环里面，而是人在一个有杠杆的位置上去监督整个循环。当上下文统一了、工作可验证了，数十亿工人就会从骑自行车升级到开车，然后从开车升级到自动驾驶。【批注③】 我个人看来，可验证性这三个字可能是 2026 年企业大模型应用落地最核心的命题。实际项目沟通中，跟客户说我们的模型很聪明没用，客户要的是你能不能证明它在我的场景里真的好使。这就涉及到评测怎么做、调用链路能不能追溯、出了问题能不能定位到底是模型幻觉还是检索没检准还是上下文传错了。再往深了说，还有权限控制、数据脱敏、操作审计这些听起来不够洋气的事。但做企业交付的人都清楚，客户最后签字买单往往就看这些。原文用历史隐喻讲得很好，但对于正在做企业项目的人来说，这一段才是从宏大叙事到你到底能交付什么的关键。2.3 组织：钢铁与蒸汽公司是一个相对晚近的发明，而且它们在扩张的过程中会退化。<img src="https://picx.zhimg.com/50/v2-21b6cd65dbed5be6f2d1a219cd7f6b30_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="1692" data-original-token="v2-9703ef4280bf43016d7abab5d66383f7" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-21b6cd65dbed5be6f2d1a219cd7f6b30_r.jpg?source=2c26e567"/>几百年前，大多数公司就是十来个人的小作坊。现在我们有了几十万人的跨国集团，但沟通基础设施（人脑连接人脑，靠开会和发消息）在指数级增长的负载下早就撑不住了。我们一直在用人的尺度的工具来解决工业尺度的问题——就像用木头盖摩天大楼。<img src="https://picx.zhimg.com/50/v2-c5387b494f05f7d1ebde4d83f7391de7_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="736" data-original-token="v2-a08015f16aef978a1e7c0aa8734e8752" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-c5387b494f05f7d1ebde4d83f7391de7_r.jpg?source=2c26e567"/>先说钢铁。钢铁出现之前，建筑最多盖六七层。钢铁改变了一切——骨架更轻、墙更薄，建筑可以拔地而起几十层。AI 就是组织的钢铁。它可以在工作流之间维持上下文、在需要时浮现决策信息。人与人的沟通不再需要做"承重墙"——每周两小时的对齐会议可能变成五分钟的异步评审，原来三层审批的决策可能几分钟就能完成。<img src="https://pic1.zhimg.com/50/v2-bf34549eb5ddabb26c47c1c3995393d3_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="690" data-original-token="v2-6eb741900df68624a1a1c15f3c3a1be1" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-bf34549eb5ddabb26c47c1c3995393d3_r.jpg?source=2c26e567"/>再说蒸汽机。工业革命初期，纺织工厂靠水车驱动，挨着河流建造。蒸汽机出现后，工厂主一开始只是把水车换成蒸汽机，其他一切照旧，结果生产力提升并不大。真正的突破在于他们意识到可以彻底摆脱水源约束——把工厂建在离工人、港口、原材料更近的地方，围绕蒸汽机重新设计整个布局。生产力由此爆发。我们现在还处在"换水车轮"的阶段。把 AI 聊天框嵌到现有工具上，但还没有去想象，当旧的约束消失之后，组织到底应该长什么样。在我的公司 Notion，我们一直在做实验。除了 1000 名员工，我们现在还有超过 700 个 Agent 在处理重复性的工作。它们做会议纪要、回答问题来合成部落知识、处理 IT 服务请求、记录客户反馈、帮新员工了解福利制度、写周报让大家不用再手动复制粘贴。这些还只是小试牛刀。真正的收益上限只取决于我们的想象力和惰性。【批注④】 这段和我在一线做项目的经验高度吻合。现实中很多企业做大模型应用，还停留在给现有流程加个聊天框的阶段，本质上就是原文说的把水车换成蒸汽机，其他一切照旧&quot;。我见过不少客户花了不少钱上了一套问答系统，结果没人明确这个系统产出的东西谁来验收、出了错谁负责，跑了没多久大家就不用了。真正有效果的做法是什么呢？我想应该是把大模型当成业务流程里的一个执行节点，而不是一个万能入口。输入是什么、输出是什么、验收标准是什么、出了异常谁来兜底，这些写清楚了，模型才能真正嵌进去跑。2.4 经济体：从佛罗伦萨到超级城市钢铁和蒸汽不只是改变了建筑和工厂，它们改变了城市。<img src="https://picx.zhimg.com/50/v2-a96b044765f96040ffb347d40e20116c_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="720" data-original-token="v2-6446b078eba090bdaa9633ab4e60cc96" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://pic1.zhimg.com/v2-a96b044765f96040ffb347d40e20116c_r.jpg?source=2c26e567"/>几百年前，你可以在四十分钟内走遍佛罗伦萨，生活的节奏取决于一个人能走多远。然后钢铁框架让摩天大楼成为可能，蒸汽机驱动的铁路把市中心和腹地连接了起来，城市在规模和密度上爆炸式增长——东京、重庆、达拉斯。这些不是"更大版的佛罗伦萨"，而是完全不同的生存方式。知识经济正在经历同样的转变。今天知识工作占美国 GDP 近一半，但大部分仍在人的尺度上运转：几十人的团队、靠会议和邮件推动的工作流、超过几百人就开始内耗的组织。当大规模 AI Agent 上线之后，我们要建的是东京——跨越数千个 Agent 和人类的组织、跨时区不间断运转的工作流、在恰到好处的人机协作中完成决策。2.5超越水车轮我们现在仍然处在 AI 的"水车轮阶段"——把聊天机器人嵌在为人类设计的工作流上。我们需要去想象，当琐碎的忙活被委托给永不休息的心智时，知识工作可以变成什么样。钢铁。蒸汽。无限心智。下一条天际线就在那里，等着我们去建造。3 工程方法：最容易被忽视的事儿前面聊了这么多，不管是 Qwen 3.5 的成本拐点、OpenClaw 背后应用层才是主战场的判断、还是 Ivan Zhao 文章里关于流程重构和可验证性的讨论，其实都指向同一个结论：2026 年企业大模型落地，瓶颈不在模型，在应用层的工程能力。3.1 个人市场观察但应用层的工程能力到底指什么？过去一年多我在知识星球给成员做答疑、给企业做项目咨询的过程中，发现一个很普遍的现象，不管团队一开始做的是知识库问答、业务工作流、还是 Agent 自动化，跑通了一个基础版本之后，几乎都会卡在同一组问题上.比如业务专家脑子里那些没成文的隐性经验怎么提炼出来？非结构化文档里的业务规则怎么变成模型能用的知识？现有方案的上限到底在哪、下一步应该往哪个方向投入资源等等。<img src="https://pica.zhimg.com/50/v2-4e4d78af526db79694759cefd13cf323_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="451" data-original-token="v2-f48abc72b44e6c392a33df7ac8cef74a" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://pica.zhimg.com/v2-4e4d78af526db79694759cefd13cf323_r.jpg?source=2c26e567"/>3.2 干中学的拼图坦率说，这些问题我和团队也是干中学。过去两年多聊了 300 多家企业、做了 20 多个项目之后，才算是慢慢形成了一个相对完整的拼图。比方说，上线前怎么通过埋评测点和设计人机交互来自然积累 golden test set 和 bad cases；上线后怎么做持续的动态调优；再比如我之前在一个报价项目里，用聚类算法从 7000 多份历史报价单中提炼出了 20 种报价模式，这本质上是用数据方法去暴力蒸馏行业的隐性业务规则。这些做法和微调/强化学习没有关系，但它们才是真正让项目在业务上产生价值的东西。<img src="https://pica.zhimg.com/50/v2-159ae396ec7f33db8b0b28a50f9a0f34_720w.jpg?source=2c26e567" data-caption="" data-size="normal" data-rawwidth="1080" data-rawheight="769" data-original-token="v2-fe349688863b7f9a7c6805a94e5f8e3b" class="origin_image zh-lightbox-thumb" width="1080" data-original="https://picx.zhimg.com/v2-159ae396ec7f33db8b0b28a50f9a0f34_r.jpg?source=2c26e567"/>总结来说，先找高频的、业务价值高、容错率可控的场景切入，跑通之后再按业务优先级扩展。这个过程里绕不开的就是面向大模型的知识工程（非结构化文档的清洗、结构化、关联），以及结合传统算法做规则和模式的提取。这些活儿不洋气，但决定了项目到底能不能用起来。3.3 工程思维比编程语言更重要我也越来越觉得，在 AI 后时代工程思维比掌握某个编程语言或框架更重要。工程思维是什么？是用系统视角去拆解问题、设计架构的能力——它关注的是"做什么"和"为什么"，而不是怎么写这行代码。创新往往诞生于约束之中，而企业数据的非标、系统的碎片化、业务的复杂性，恰恰就是这些约束。能在约束中找到可行路径的人，才是这个阶段最稀缺的。这也是我写书和做课程的出发点。过去两年的一线项目经验，踩过的坑、验证过的方法、总结出的可复用路径，我都整理在了这本书和配套的视频课里。如果你正处在基础 RAG 做完了但不知道下一步往哪走的阶段，或者你在公司推大模型项目但缺一套从需求拆解到评测运营的方法论，可以了解一下。星球成员赠送书和视频课程（仅限26年2月份新加入成员）4 写在最后最后扯个题外话。这两年做项目有一个感受越来越强，工具迭代得很快，但用工具的人其实没怎么变。我们每天能集中注意力干活的时间就那么几个小时，能同时记住的事情就那么多，做判断的时候该犯的认知偏误一个都不会少。这些东西几千年都没变过。所以每次有新技术出来，真正的价值不是它本身多炫酷，而是它能不能帮我们把这些人的局限性给补上。Ivan Zhao 这篇文章让我觉得写得好的地方就在这，他没有吹 AI 多厉害，而是在说我们现在协作的方式太笨了，该换个效率更高的方式。Notion 这篇文章给了我不少启发，我不想在这篇内容里把它包装成什么"时代洞察"或者"技术红利"来讲，毕竟市场上已经充斥了太多这类宏大叙事。倒是前面聊到的 Steinberger 让我挺有感触，一个已经在资本市场上成功退出过一次的人，财务上早就自由了，但还是在新的技术浪潮里找到了自己的第二增长曲线。他的 GitHub 个人介绍写的是"Full-Time Open-Sourcerer"，这种完全的注意力自由，也是我个人很向往的一种状态。但更让我觉得值得学习的是，他前前后后做废了 40 多个项目才成了一个。成功确实会发生，但它极少会在我们想要的时间尺度内发生。保持常识，解决具体问题，然后产品化。新年新气象，共勉。

配图 (可多选)

标签