/~learn/s/f520ff9d
> 前四篇我们聊了上下文密度衰减、工程实践指南、Claude Code 源码拆解、概率模型能力边界，以及那篇关于超级个体飞轮的推演。这一篇我们跳出"怎么用 AI"的技术细节，回到一个更根本的问题：AI 到底是给旧系统装上新引擎，还是在催生一种全新的系统范式？
---
最近一直在研究 Agent Harness、Eval、Observability 这些东西。看的东西越多，反而越有一种说不上来的感觉：现在很多 AI 产品，可能还是在用以前的软件工程思维做 AI。
最近几个月，几乎所有团队都在做类似的事情。Agent、Workflow、Skill、平台、UI……每个人都希望做自己的那一套，然后要求业务接入。有时候甚至同一个能力，会有两个团队分别做一套，最后业务两边都要接。
这当然不是说平台没有价值，每个团队都有自己的定位和约束。但随着接入越来越多，我越来越觉得，AI 带来的复杂度，并没有替代掉原来的复杂度，而是在原来的基础上又叠了一层新的复杂度。
前两天讨论一个需求，同事说准备再做一套新的 UI。我当时问了一句：如果 Agent 已经能自己完成整个修改流程了，人为什么还需要操作这个 UI？
得到的回答大概是，希望人还是能够参与这些步骤。这个回答没有问题，技术方案不同人理解不一致也是正常的，但让我突然想到工业革命早期的一个故事。
工业革命刚开始的时候，工厂都是围绕蒸汽机设计的。一台大型蒸汽机作为中央动力源，通过顶部的传动轴、皮带和齿轮，把动力传递给整个车间。
后来电出现了。
理论上，每台机器都可以安装自己的电机，直接驱动，不再依赖中央动力系统。但很多工厂最开始并没有重新设计，而是把蒸汽机拆掉，换成一个更大的电动机，然后继续带动原来的传动轴和皮带。整个工厂几乎没有变化，只是动力源变了。
真正的变化发生在很多年之后。当工厂开始围绕电重新设计，机器不再需要围着动力源摆放，流水线重新规划，整个生产组织方式都发生了变化。后来人们发现，真正提高生产力的不是电，而是围绕电重新设计了一遍工厂。
我越来越觉得，现在很多 AI 产品特别像这个阶段。
以前没有 AI，所以软件工程很多流程天然都是围绕人设计的。需要点击、需要确认、需要审批、需要 UI、需要 Workflow，需要大量中间状态。这些设计在当时都是合理的，因为真正拥有理解能力的是人。
AI 出现之后，很多系统做的事情，只是把流程里的「人」替换成了「AI」。
原来的流程没有变，组织方式没有变，系统边界没有变。AI 被放进原来的 Workflow，去走原来一样的流程，再适配原来的权限体系。
甚至为了让 AI 适应这些流程，又增加了新的 Workflow、新的平台、新的编排层。很多复杂度，其实不是 AI 带来的，而是旧的软件工程范式被完整继承到了 AI 时代。
马斯克说过这样一句话：
> The most common mistake of smart engineers is to optimize a thing that should not exist.
以前我一直把我对这句话理解的重点放在 optimize 上，觉得他说的是不要过度优化。
现在越来越觉得，这句话真正重要的是后半句。
这个东西到底还应不应该存在？
Workflow 为什么要这样设计？Skill 为什么一定要这么组织？UI 是不是所有场景都必须存在？如果今天没有任何历史包袱，只基于现在的大模型能力重新设计一遍，这些东西还会不会出现？
如果答案是否定的，那优化得越好，可能反而离正确答案越远。
所以现在我们做的事情其实越来越映照马斯克另一句话的反面：
> Try to delete the part or the process step entirely. If you're not forced to put back at least 10% of what you delete, you're not deleting enough.
很多时候，不是优化得不够，而是删得不够。我们是不是不应该继续关注那些炫酷的 Demo 和 Workflow 编辑器。
Agent 真正进入生产以后，真正困难的问题根本不是怎么画一个漂亮的流程图。
工业革命真正改变世界，也不是因为蒸汽机换成了电机。如果只是换了动力源，效率可能只提高一点点。真正的变化发生在后来，人们开始围绕电重新设计整个工厂。
AI 可能也一样。
如果只是把 AI 放进原来的软件工程里，它带来的提升或许是渐进式的；但如果围绕 AI 重新思考整个开发范式、协作方式和系统边界，很多今天看起来理所当然的东西，未来可能都会消失。
AI Native 不是给软件加一个 AI。真正值得重新思考的，不是哪个 Workflow 更好，也不是哪个平台更方便，而是哪些流程本来就是因为没有 AI 才存在的。
如果未来回头看今天，很多现在正在重复建设的 Workflow、平台和 UI，也许就像工业革命初期挂在工厂天花板上的那些传动轴和皮带一样。
它们并不是错误。
只是属于上一个时代。
---
原文的核心洞察极其深刻，但读了几遍之后，我觉得这个隐喻还可以再挖得更深一些。在实际开发量化系统和 AI 工具的过程中，我逐渐意识到——"传动轴和皮带"不仅仅存在于软件系统里，它们也存在于我们的思维方式、组织协作和个人工作流中。
原文说的"把蒸汽机换成电动机，继续带动原来的传动轴"，这个现象至少发生在五个层面：
| 层次 | "蒸汽机时代"的设计 | "电动机时代"的错误做法 | 真正的 AI Native 可能是什么 |
| ------ | ------------------ | --------------------- | -------------------------- |
| 交互层 | 人点击按钮、填表单、拖拽 Workflow | 让 AI 去"点按钮"、模拟人操作 UI | AI 直接调用能力接口，没有 UI 中间层 |
| 流程层 | 线性审批流、状态机、人工确认节点 | AI 被塞进每个节点做"智能审批" | 目标驱动，AI 自主规划路径，人只对结果负责 |
| 架构层 | 微服务、API 边界、数据库 Schema 预先定义 | 给每个服务加个 AI 端点 | AI 理解意图后直接组合能力，不需要预先编排 |
| 组织层 | 团队按职能划分（前端/后端/产品/测试） | 每个团队各自做一套 AI 平台 | 围绕"意图→结果"重组，角色边界消融 |
| 思维层 | 人必须把需求拆成可执行步骤 | 人继续拆步骤，让 AI 执行每一步 | 人说目标，AI 拆步骤、选工具、执行、验证 |
最危险的不是任何一层的"传动轴"，而是第五层——思维层的传动轴。很多人以为自己在"用 AI"，但他们做的事情不过是把原来自己要做的步骤，逐字逐句写成 prompt，让 AI 替自己打字。这本质上还是在用蒸汽机时代的工作方式，只是打字员从自己换成了 AI。
真正的 AI Native 思维是：先说"我要什么结果"，而不是"帮我做这几个步骤"。
读完这篇文章后，我回头审视自己的量化交易系统，发现了一个很典型的例子：
"传动轴"设计：
传统流程：
1. 我手动修改策略参数 → 2. 点击"运行回测"按钮 → 3. 等待结果 →
4. 看图表 → 5. 发现问题 → 6. 回到步骤1调参"换了电动机但没改传动轴"的 AI 版本：
假 AI Native：
1. 我告诉 AI"把动量窗口改成 20 天" → 2. AI 修改参数文件 →
3. AI 调用命令行运行回测 → 4. AI 把结果截图发给我 →
5. 我看完告诉 AI"再改成 15 天试试" → ...看起来 AI 介入了，但整个循环的结构完全没变。我还是那个做决策、给指令、看结果的人，AI 只是一个更快的"手"。这就是把 AI 放进旧 Workflow 的典型做法。
真正的 AI Native 应该是什么样？
真 AI Native：
1. 我对 Agent 说"帮我找到这个 ETF 组合在过去 5 年最优的动量窗口，
考虑交易成本，目标是 Sharpe 最大化，回撤不超过 15%"
2. Agent 自主确定参数搜索范围，运行批量回测，分析结果
3. Agent 返回最优参数 + 敏感性分析 + 过拟合风险评估
4. 我只做最终判断：用不用？要不要再约束什么？这里消失的传动轴包括：手动调参的循环、等待单次回测的时间、我自己筛选结果的劳动。我从"操作工"变成了"设定目标和验收标准的人"。
这恰好印证了超级个体飞轮那篇文章的核心论点——AI 时代的核心技能从"执行"变成了"定义目标 + 判断结果"。
马斯克说"Try to delete the part or the process step entirely"。问题是，怎么判断什么东西是"传动轴"——那种因为没有 AI 才存在、在 AI Native 世界里本来就不应该有的东西？
我总结了一个"删除测试"框架，用来识别系统中那些应该被质疑的环节：
对任何一个流程步骤、UI 界面、平台组件、工作节点，问三个问题：
Q1：如果一个能力无限的 AI Agent 能直接理解意图并完美执行，这一步还需要存在吗？
Q2：这一步存在的根本原因，是"能力不够"还是"权责需要"？
Q3：如果今天从零开始设计，没有任何历史代码和流程包袱，你还会设计这一步吗？
| 组件 | Q1：AI 能力无限后还需要吗？ | Q2：能力问题还是权责问题？ | Q3：从零设计会做吗？ | 判断 |
| ------ | -------------------------- | -------------------------- | --------------------- | ------ |
| Workflow 可视化编辑器 | ❌ AI 自己规划路径 | 能力问题 | ❌ 不会 | 典型传动轴 |
| 人工点击"确认执行"按钮 | ⚠️ 部分需要 | 权责问题（怕 AI 闯祸） | 会，但形态变 | 保留"紧急刹车权"，删掉"每步确认" |
| 拖拽式 Skill 编排界面 | ❌ AI 自己选工具 | 能力问题 | ❌ 不会 | 传动轴 |
| 详细的权限审批流 | ✅ 需要 | 权责+合规问题 | 会 | 保留，但简化 |
| 人写 PRD → AI 生成代码 | ❌ | 能力问题（AI 还不会读心） | ❌ 直接说目标 | 过渡态传动轴 |
| AI 生成代码 → 人 Code Review | ✅ 需要 | 权责+质量问题 | 会 | 保留，但 Review 重点从"正确性"转向"方向对不对" |
| 统一的 Agent 平台/中台 | ⚠️ 需要但不是今天的形态 | 两者都有 | ⚠️ 会做但完全不同 | 今天的平台大多是传动轴，真正的平台是"能力超市"而非"编排器" |
这个测试跑完，你会发现今天 80% 的 AI 平台建设，可能都在优化传动轴。
知道什么是传动轴，和真的敢动手拆，是两件完全不同的事。为什么大家都在做"换电动机"而非"重新设计工厂"？我观察到三个深层认知陷阱：
工厂主把蒸汽机换成电动机时，传动轴和皮带还在那里转，虽然效率没提升多少，但至少"看起来和以前一样"，心理上是安全的。
软件里也是一样。一个可视化的 Workflow 编辑器，一个可以拖拽的 Skill 编排界面，一个让人点点点的审批流——它们给管理者带来的控制感，远远大于它们实际带来的生产力。
"我能看到每一步在做什么"和"我能控制最终结果"，这是两件完全不同的事。前者是工业时代留下的心理舒适区，后者才是 AI 时代真正需要的能力。
真正的 AI Native 系统可能看起来很"无聊"——就是一个对话框（或者干脆连对话框都没有，Agent 在后台自主运行），你告诉它目标，它给你结果。中间过程不可见，也不需要可见。就像你今天用电时不会去想"电子现在是怎么流过电线的"——你只关心灯亮不亮。
很多团队的思路是：我们先做一个 AI 辅助的版本（把 AI 塞进旧流程），然后慢慢迭代，逐步去掉人工环节，最终到达 AI Native。
这个思路在理论上成立，在实践中几乎不可能发生。原因有三个：
克莱顿·克里斯坦森的"颠覆式创新"理论在这里完全适用——延续性创新（在旧范式上持续优化）永远不可能产生范式转移。真正的 AI Native 产品，大概率不会从今天那些大 AI 平台团队里长出来，而会从某个"根本没按你们那套做"的小团队里冒出来。
原文中同事说"希望人还是能够参与这些步骤"，这个想法非常普遍，也非常值得深究。
"人要参与"本身没有错。但关键问题是：人应该在什么层面参与？
| 参与方式 | 本质 | AI Native 吗？ |
| --------- | ------ | --------------- |
| 人在每一步操作节点上点"同意" | 人被当作流程的一个齿轮 | ❌ 伪参与 |
| 人设定目标和约束条件 | 人是方向设定者 | ✅ 真正的参与 |
| 人审阅最终结果，决定是否采纳 | 人是质量验收者 | ✅ 真正的参与 |
| 人随时可以中断/干预（紧急刹车） | 人保留最终控制权 | ✅ 必要的安全网 |
| 人在 AI 搞不定的边缘 case 上介入 | 人是异常处理器 | ✅ 合理的兜底 |
很多系统说"需要人参与"，实际上设计出来的是第一种——把人变成流程里的一个"人工审批节点"。这不是尊重人，这是浪费人。人应该在目标设定和结果判断这两个 AI 做不了的环节参与，而不是在中间的执行步骤上当一个"人形图章"。
基于上面的分析，我尝试总结真正 AI Native 系统可能具备的特征。注意这些特征不是"更高级的 Workflow"或者"更智能的 UI"，而是完全不同的设计哲学：
旧范式：定义流程 → AI 执行流程中的某些步骤
新范式：定义目标 → AI 自主规划并执行完整路径这就像打车：你不需要告诉司机"走哪条路、在哪个路口转弯"，你只需要说目的地。司机（AI）自己选路，如果遇到封路（异常）会自己绕行或告诉你。
旧范式：每一步都要人确认（人是流程的一部分）
新范式：人只看结果，过程对人透明但不要求人介入
旧范式：预先定义 API 边界 → 编排服务调用链 → 处理集成问题
新范式：AI 理解各种能力的输入输出 → 按需组合 → 不需要预先编排这恰好呼应了第三篇文章里对 Claude Code 工具系统的分析——它的工具调用不是预设 Workflow，而是 AI 根据当前状态自主选择。
旧范式：图形界面（GUI）是主要交互方式，人学习软件的操作逻辑
新范式：自然语言是主要交互方式，软件学习人的意图回头看我自己的量化系统，现在大部分日常操作已经变成了对 Agent 说话，而不是点按钮。我已经很难想象再回到手动点"运行回测"→选参数→等结果的日子。
旧范式：人做决策 + 人做执行 + AI 辅助部分执行
新范式：人做判断（目标 + 验收 + 异常处理） + AI 做所有执行这不是说人变懒了，而是说人的精力被彻底解放出来，集中到只有人能做的事情上：
概率模型能力边界那篇文章详细论证过：AI 是 System 1（直觉、快速、模式匹配），不是 System 2（推理、慢速、步步为营）。人的角色就是那个 System 2——做最终的理性判断和价值裁决。
---
回到我自己每天用的量化交易系统，这篇文章的启示是直接的、可操作的：
这个判断也解释了为什么我现在越来越依赖 TRAE/Claude Code 这种 Agent 式工具，而对各种"AI Workflow 平台"提不起兴趣——前者已经在往电动机方向走了，后者大多还在打磨传动轴。
---
工业革命的历史告诉我们一件事：在范式转移期，最大的障碍不是新技术不够好，而是旧范式太熟悉、太舒适、太"显然正确"。
那些在工厂里继续优化传动轴的工程师不是蠢人——他们是那个时代最聪明的工程师。传动轴系统是他们理解世界的方式，是他们一辈子积累的专业知识。要他们亲手拆掉自己精通的东西，承认"这个东西本身就不该存在"，反直觉到了极点。
但历史不会因为你是聪明人就手下留情。传动轴最终还是消失了，不是因为它不好，而是因为它属于上一个时代。
所以这篇文章给我的最大启发不是"赶紧去做 AI Native"，而是一个更朴素的提醒：
> 在动手优化任何东西之前，先问一句——这个东西本身还应该存在吗？
看见传动轴，是拆掉传动轴的前提。而在所有人都在比谁的 Workflow 画得更漂亮、谁的平台功能更多的时候，能停下来问"我们是不是在优化一个本该删除的东西"——这种能力，可能才是 AI 时代最稀缺的判断力。
毕竟，马斯克那句话的完整版本应该是：
> 最聪明的工程师最常犯的错误，是优化一个根本不该存在的东西。 > 而更大的错误，是因为太擅长优化它，而看不见它根本不该存在。
---