从AI-Native软件工程到AI-Native组织

上一篇文章，我提出：

AI-Native不是技术变革，而是运营模式变革。

这篇，我想讲讲这个判断是怎样从实践中形成的。

我们的探索，并不是先设计一个“AI-Native组织”，再要求团队按照蓝图执行。

起点很具体：软件工程。

最初，我们关注如何利用AI提升软件交付效率。后来，我们开始围绕AI和数字员工重新设计交付流程。

在这个过程中，我逐渐意识到：

我们正在改变的，不只是软件怎样开发，而是工作怎样被组织。

这也是我们从软件工程走向企业运营、进一步思考AI-Native组织的起点。

一、最初，AI进入了工作，但流程没有改变

过去，软件交付流程主要围绕人的角色设计。

有人分析需求，有人开发，有人测试，再由不同角色完成审查、发布和运营。

每个人有自己的任务，流程负责把这些任务连接起来。

最初使用AI时，我们也是在这些环节中加入AI。

开发人员用AI辅助编码，团队用AI分析问题、生成测试和编写文档。

人仍然负责推动工作，AI帮助人完成其中的任务。

这是一个自然的起点，也确实有价值。

但此时，工作的组织方式没有发生根本变化。

需求还是按原来的方式流转，任务还是按原来的角色分配，AI主要是每个人手里的助手。

我们问的仍然是：

“这个角色，可以怎样利用AI做得更快？”

而不是：

“有了AI，这项工作还需要按原来的方式组织吗？”

这两个问题，后来成为我们区分“使用AI”和“AI-Native”的关键。

二、真正的变化，从重新设计交付流程开始

在推动软件工程AI-Native化的过程中，我们开始重新审视整条交付流程。

不再只是把AI放进某个岗位的工作里，而是把AI和数字员工本身纳入工作分工。

过去，设计流程时，我们首先考虑：

谁分析需求，谁写代码，谁测试，谁负责交接。

现在，我们开始从目标和交付结果出发：

为了完成这个目标，哪些工作可以由AI执行？

哪些环节需要人审查？

哪些判断必须由人作出？

哪些交接仍然必要？

流程的设计起点，开始从人的角色，转向人和AI如何共同完成目标。

这里所说的“数字员工”，不是一个机器人形象，也不只是一个聊天窗口。

它指向的是一种工作角色：在明确的目标、权限和质量要求下，AI参与执行任务，并交付可以检查的结果。

这并不意味着AI可以独立完成所有工作。

但它意味着，我们不能再只把AI放在流程之外，作为人的辅助工具。

三、一项需求，如何以新的方式走向交付？

沿着一项需求看它如何走向交付，变化就更容易理解。

在我们的软件工程实践中，交付流程逐步围绕这样的闭环展开：

人表达目标 → AI理解与实现 → 测试和文档 → 人审查 → 发布与监测 → 反馈迭代。

这不是把人从流程中拿走，而是重新安排人的工作与AI的工作。

人先讲清楚目标

人需要明确要解决什么问题，预期结果是什么，以及哪些要求和边界必须遵守。

这与“给AI一句指令，让它自己完成一切”不同。

目标是否清楚，仍然需要人的业务理解和判断。

AI参与执行

AI参与需求理解、代码实现、测试和文档工作。这些能力被纳入同一条交付流程，而不只是分别放在不同角色手里的助手。 

我们关注的，也不再只是某一步生成得多快，而是这些工作能否连接起来，形成可以审查的交付结果。

人在关键节点审查和决策

AI生成了结果，不等于结果已经可以交付。

人仍然需要检查关键输出，判断是否符合目标，作出必要决策，并承担最终责任。

新的分工不是“AI做完，人就不管了”。

而是：

AI参与执行，人负责目标、判断、监督和责任。

交付之后，继续反馈

我们的交付框架还包括发布后的监测，以及持续反馈和迭代。 

工作不止于“完成一个任务”，还需要回到实际结果：交付是否有效，哪里需要调整，下一轮如何改进。

沿着这条链看，我们重新设计的就不只是开发、测试或文档中的某一步。

而是一项工作怎样从目标走向结果。

四、交付方式变了，团队和质量保障也要跟着变

流程不是孤立存在的。

当AI承担部分执行工作，人的注意力、团队的协作方式，以及质量保障机制，都需要重新考虑。

在我们的实践中，团队变成了更小规模、端到端负责的工作方式，推动工程师从单一专业角色向全栈交付能力发展（Full Stack Engineer)；协作活动也围绕原型评估、交付物评估和复盘重新组织。 

这不是简单减少会议或减少人数。

它与交付流程的变化相连：人需要更完整地理解目标，更认真地审查结果，并对整体交付负责。

质量保障同样如此。

我们正在把既有的软件工程质量标准转化为AI可以执行的指令和检查机制，并结合代码审查、测试验证和发布前检查。 

因此，围绕AI重新设计流程，并不意味着否定过去的IT和软件工程积累。

改变的是执行与协作方式，不是取消专业判断、质量要求和责任。

过去主要依靠人理解和执行的标准，现在还需要进入AI参与执行的过程。

这也是为什么，AI-Native软件工程不能只靠一个更强的模型完成。

它需要流程、团队能力、知识和质量保障一起演进。

五、从软件工程中，我们看见了更普遍的工作逻辑

到这里，我们重新设计的仍然是软件交付。

但我开始意识到，发生变化的并不只是“写代码”这件事。

软件交付中，有需求理解、信息处理、规则执行、结果验证，也有人的判断和责任。

企业里的许多其他工作，同样包含这些要素。

于是，我们开始问：

如果软件交付可以这样重新设计，采购、财务、人力资源和企业运营，是否也可以？

问题从“软件怎样交付”，走向了“工作怎样完成”。

这就是从AI-Native软件工程走向AI-Native工作流的连接点。

我们开始把注意力从某个专业领域的工具，转向一项工作从开始到结束，如何由人和AI共同完成。

六、当这条逻辑进入日常运营

同样的思路，也进入了公司运营实践。

例如，在订货计划与采购订单流程中，原来需要员工协调库存信息、供应商询价、订单创建、材料上传和审批跟踪。

重构后的流程由AI智能体参与编排和执行，人保留关键确认、审批与例外处理。 

它与软件工程相通的，不是具体技术，也不是把开发流程照搬到采购。

相通的是设计起点：

先看目标与结果，再安排AI的执行和人的判断。

AI驱动流程，人负责监督和决策。

当这条逻辑进入日常运营，我们讨论的就不再只是一个软件项目如何交付。

而是公司里的工作如何持续运行。

采购案例中的具体分工与责任边界，我会在第四篇文章中展开。这篇更重要的是说明：软件工程中的发现，为什么会把我们带到企业运营的问题面前。

七、流程重构，进一步带来了组织问题

当AI参与的不再只是某个人的一项任务，而是一条工作流，甚至日常运营，新的问题也随之出现。

人需要具备什么能力？

团队应该怎样分工？

AI可以获得哪些权限？

哪些节点必须由人判断？

一个团队积累的知识和方法，怎样被其他团队复用？

这些问题，不是更换一个工具就能回答的。

我们的公司战略也逐步从AI应用，走向AI驱动流程与组织，将人才、流程、组织和产品放在一起推进。实践路径包括先锋团队、真实场景验证、标准沉淀和逐步推广。 

因此，AI-Native组织并不是我们在软件工程之外突然增加的一个概念。

它是软件交付流程重构之后，逐步展开的一组组织问题。

我们也并没有因为一个案例跑通，就认为整个公司已经完成转型。

从一个团队的实践，到可以复用的工作方式，再到更广泛的运营与组织变化，仍然需要持续验证。

八、这就是我们的演进路径

回看这段实践，我确认的主线是：

AI-Native Software Engineering从软件工程开始，重新设计交付方式。

↓

AI-Native Workflow从专业任务走向整条工作流，重新设计人机分工。

↓

AI-Native Operations将这种思路应用到公司日常运营。

↓

AI-Native Organization进一步思考能力、协作、权限与责任如何组织。

这条路径不是要求所有企业都从软件工程开始。

它是我们的实践起点。

其他企业可能从采购、财务、客户服务或其他业务流程开始。不同场景需要不同的设计，不能直接照搬。

但我认为，围绕AI和数字员工重新设计工作的思路，会逐步应用到千行百业。

值得共同探索的，是同一个问题：

当工作参与者发生变化，工作的设计方式是否也应该改变？

从一条交付流程，到重新思考企业

我们不是先定义一个未来组织，再寻找案例证明它。

而是从软件工程实践出发，重新设计交付流程。

从交付流程中，看见工作流的变化。

从工作流的变化中，走向公司运营。

再从运营实践中，重新思考组织。

这也是第一篇文章中那个判断的来处：

AI-Native不是多用AI，而是围绕AI重新设计企业。

对我们而言，它是一条从实践中逐步展开、仍然需要持续验证的路径。

下一篇：组织能力从哪里来？

当AI和数字员工进入工作流程，组织能力还只是员工能力的总和吗？

下一篇《为什么未来组织能力 = Human + Agent + Model + Data》，将继续讨论这个问题。

欢迎关注微信公众号

持续阅读《AI-Native组织》系列。这里记录真实实践，也分享探索中的问题与思考。