我们还在+AI阶段:软件、岗位与组织

和之前大部分文章风格不同，本文纯个人观点

讨论 AI 如何改变组织之前，我想先明确自己的判断：我们今天还没有进入 AI Native 。现在看到的大多数应用，顶多算是在原有的软件、岗位和工作流程上“＋ AI”。

但在这个过渡阶段，一些变化正在触及更深的地方：一个人能够推进的工作变多，岗位职能开始融合，软件原先划定的边界也随之松动。沿着这条路，组织会怎样变化？我们又是否在用过去的概念理解未来？

下面这张图，是我对这条演进路径的整理。

我们习惯按照岗位理解企业：销售、产品、研发、人力、财务。人的知识、时间和执行能力有限，专业分工提高效率，层级与流程则负责把分散的工作连接起来。

传统企业软件延续了这套结构。 CRM 围绕客户与销售， HCM 围绕人员管理，财务系统负责核算， ERP 统筹资源和流程。软件把分工编码成模块，把协作编码成流程，把管理编码成权限；组织使用它们，又逐渐适应它们规定的工作方式。

因此，岗位边界与软件边界是相互塑造的。但一件真实的业务，往往横跨这些边界。

假设一家企业要完成一笔订单，从理解客户要求，到安排资源、交付、开票和回款，目标是连续的，操作却被切成许多段。补充背景、核对口径、等待确认、转述进度，构成了大量日常协作。

当前的“＋ AI”，大多从这些既有分工内部开始：研发增加编码助手，产品增加需求整理和原型生成，销售增加客户分析。先有岗位、软件和流程，再决定把 AI 放进去。

但增强个人能力，会进一步影响分工本身。从代码补全到 vibe coding ，从辅助设计到生成可运行的原型，一个人有机会推进更完整的工作，过去必需的交接就可能减少。图里从“产品、研发”到“产研”，再到领域专家与业务参与其中，表达的正是这种重组。

FDE ，也就是深入业务现场的部署工程师，可以作为观察这一变化的切口：业务理解、技术实现和交付被拉近，围绕一个实际问题组织起来。技术执行更容易获得之后，识别问题、判断结果和理解业务后果的能力，也变得更重要。

当原本分散在几个岗位里的工作能够连贯完成，软件就会承受打破原有边界的压力。岗位职能融合推动软件融合，软件进一步减少交接，又会为新的工作组合创造条件。

“数字员工”是当前阶段容易落地的表达。企业先选一个熟悉的岗位，列出任务，再把其中一部分交给 AI ，范围、预算和权限都容易与现有管理衔接。

但把它当作未来组织的基本单元，我认为前提就不成立了。数字销售、数字财务、数字产品经理，都默认岗位保持原样，只是换了执行者。而岗位里的能力正在被拆开，跨岗位的能力又在重新组合。给每个旧岗位安排一个数字员工，很可能把旧边界一并带过去。

因此，往后看，我更愿意从 Ability 理解组织：在具体条件下完成某类工作的能力，例如识别需求、判断交付风险、制定资源方案、核验结果。

一个岗位可以包含多种能力，同一种能力也可以参与不同工作。人、模型和工具都可以提供能力，组织需要判断的是：眼下需要什么能力，由谁提供，怎样组合。岗位可以继续承载管理与责任，但不必决定所有工作的执行边界。

驱动这种组合的，我认为会是业务语义。它包含目标、业务对象之间的关系、当前状态、规则和约束。自然语言可以表达语义，订单状态、客户反馈和资源变动也可以携带语义。

接着前面的订单例子：客户要求提前交付，需要同时理解合同承诺、可用库存、生产安排与成本变化。根据这些关系，系统才能组织相应能力评估方案，把影响承诺或利润的事项交给有权决策的人，并在方案确定后调整执行。只是把客户的话转发给几个 Agent ，还做不到这些。

这也解释了我所理解的从科层走向 network 。人与 Agent 是能力的承载者，协作关系围绕业务目标形成，并随着条件变化调整。组织的灵活性和可塑性，来自能力可以重新组合，而不必每次都靠重画部门、增加层级来适应变化。

网络协同仍然需要共同的业务理解、准确的状态，以及清楚的决策和责任关系。若每个节点只看见局部信息，遇事仍需反复转述和升级，增加 Agent 反而可能增加沟通成本。

我期待被压缩的，是部分围绕信息传递和任务转交形成的层级。目标由谁确定、资源如何分配、什么情况需要人的判断、结果由谁确认，这些组织问题仍然要解决。

如果工作能够围绕目标组合能力，软件也需要重新考虑如何承载它。

今天讨论的对话入口、动态界面，乃至“液态软件”，都还不足以回答这个问题。更深的变化在于，业务如何被理解、状态如何被保持、执行如何被组织，以及真实结果怎样回到系统中。

我们可以从“＋ AI”向前演进，但如果始终保留旧结构、只增加 AI 功能，就无法完成 AI Native 所需要的重构。岗位与软件的融合，需要进入设计软件的基本逻辑。

例如，面对一次交付调整，未来的软件应当能够围绕这个业务目标组织评估、决策和执行。库存、合同、财务等系统可以参与其中，而它们各自的入口和操作顺序，不再必然决定整件事怎样完成。

这也是原始草图里“ERP 消失”想表达的方向：面向人的固定模块，以及由模块规定的操作和交接方式，可能逐渐失去主导地位。资源管理、业务记录和核算等职能依然存在，合同、账务和权限约束也必须准确维持，但承载这些职能的软件可以形成新的结构。

Connector 让能力接触已有系统， skill 封装可复用的做法，它们可以是重要组成部分。至于软件本身，我更倾向于把它理解为：在模型之上，围绕现实业务职能形成、能够组织能力并推进业务的软件形态。连接方式和工具清单，无法单独定义它。

这种软件究竟会长成什么样，我现在不急于给出定型答案。值得继续探索的是，哪些业务规则必须稳定，哪些流程与协作关系可以随目标调整，以及调整后的结果如何被验证。

上面这些变化，都依赖底层真正可用的能力。模型能否理解复杂上下文，在长任务中保持目标、处理异常，以及完成工作的成本，会直接影响上层能走多远。如果只能偶尔完成一次演示，业务里仍然需要大量人工接管。

我把模型演进放在整张图的最底层，也是出于这个考虑。不同模型体系的持续发展，会改变组织能够获得的能力基础；模型之上组织和使用智能的方式，也在演进。我把后一条路径画为 Prompt → Context → Harness → RSI。

Prompt 侧重表达任务， Context 进一步组织完成任务所需的信息； Harness 则把模型、工具、业务状态和执行约束放进持续运行的机制， Loop 是其中的执行循环。任务范围扩大之后，发现错误、中断恢复和结果核验，都需要在这个运行机制里得到处理。

RSI ，即递归自我改进，是图中进一步的探索方向。我并不把这些概念理解为已经完成的代际替换，前面形成的方法仍会继续使用。关键在于，每向前一步，系统能否可靠承担更完整的工作。

这条从下向上的依赖，构成了整张图的基础：模型与执行范式扩大工作能够完成的范围，推动岗位职能与软件边界融合，进而改变组织的协作方式。上层设想最终都要回到执行能力上接受检验。

企业也需要在实际运行中积累自己的经验。哪些信息曾经缺失，什么方式容易失败，什么时候需要调整计划，都应当通过结果反馈进入下一次工作。

我所说的业务自我进化，首先发生在这里：系统保留错误与有效做法，据此调整上下文、能力组合和执行方式，再用业务结果验证调整是否有效。只有保存记录、没有改变后续行为，还谈不上进化。

这与基础模型本身的递归改进是两个层次。企业可以在不改变模型参数的情况下改进业务运行，模型继续进步又会扩大改进空间。两者共同影响组织向 AI Native 演进的速度和深度。

回到当前实践，我会用几个具体问题判断进展：跨系统任务是否减少了人工转述？工作能否完整推进到业务结果？职能融合之后，判断与责任是否清楚？这次发现的问题，是否改变了下一次执行？

我愿意把 AI Native 留给这样的变化：新的业务目标出现后，组织能够理解其含义，组合所需能力，在明确责任的条件下推进工作，并用结果改进后续行动。那时，理解一家企业的起点，也许会逐渐变成它拥有什么能力，以及这些能力能够怎样被组织起来。