去年开始，我们团队一直在为游戏研发团队做 AI Native 应用。

最早的思路很简单：接入大模型，做知识问答，帮用户处理一些零碎工作。这个方向看起来很合理，大模型负责理解和生成，知识库提供上下文，用户通过自然语言完成原本需要人工处理的任务。

但跑了一段时间之后，两个问题逐渐暴露出来。

第一个问题是知识库建设成本远超预期。知识库虽然由我们主导建设，但我们对游戏研发这样的专业领域理解有限，用户提供的资料也不完整。有些内容散落在各种文档里，有些知识掌握在具体业务人员手中，还有一些内容根本没有被系统化沉淀下来。为了补齐这些信息，我们不得不借助爬虫、AI 提取和人工整理去不断完善资料。结果是知识库越来越大，维护成本越来越高，而信息的完整性和准确性依然难以保证。

第二个问题是信息无法形成回流。用户在使用 AI 的过程中会持续产生新的内容，例如补充角色设定、完善剧情背景、生成任务方案等。这些内容虽然创造了价值，但大多停留在聊天记录中，没有进入系统，也没有成为后续工作的输入。AI 消费了知识，却没有把新的知识沉淀下来；用户完成了工作，却没有让系统变得更聪明。整个信息流始终是割裂的，自然也无法支撑更复杂的工作流。

这两个问题逼着我们重新思考：我们做的到底是“AI 化”，还是“AI Native”？

AI 化和 AI Native，差别在哪

很多团队所谓的 AI Native 建设，本质上是在现有系统中接入一个大模型 API。从结果上看，这确实提升了效率，但更多是在原有流程上的能力增强，而不是对系统本身的重构。

我们更倾向于把这种模式称为 AI 化。

AI Native 则是另一种思路：在设计系统的时候，就把 AI 当成核心能力来考虑，而不是后期增加的外挂功能。

如果把这个过程拆开来看，大致可以分为四个阶段。

第一阶段是 AI 工具化。无论是 ChatGPT 写文案、Claude 写代码，还是 AI 自动生成会议纪要，本质上都是人在主导、AI 在辅助，原有流程几乎没有发生变化。这也是目前绝大多数企业所处的阶段。

第二阶段是 AI Workflow。AI 开始进入业务流程，例如需求提交之后由 AI 拆解需求、生成方案，再由人工审核，随后继续生成代码和测试用例。AI 已经开始参与生产，但决策权仍然掌握在人手里。很多 Agent 产品目前都停留在这一阶段。

第三阶段是 AI Native System。系统从设计之初就假设 AI 的存在。传统 CMS 的流程可能是“编辑文章 → 发布”，而 AI Native CMS 则会变成“提出想法 → AI 生成初稿 → AI 补充资料 → AI 校验事实 → 人工修改 → 发布”。这里的变化不是增加了几个 AI 功能，而是整个系统架构已经围绕 AI 重新设计。

第四阶段是 AI Native Organization。过去的组织结构往往是产品、设计、开发、测试依次协作，而未来更有可能变成业务负责人管理多个 Agent，由人工负责关键决策和最终审核。随着 AI 能力的提升，组织结构本身也会发生变化。

我们怎么落地到产品里

想清楚这些问题之后，我们重新设计了产品的底层逻辑。

之前我们先设计流程，但对于游戏研发来说，真正贯穿整个生产过程的并不是流程，而是角色、NPC、场景、道具、事件等业务实体。这些对象会经历创建、补充、修改、评审到最终交付的完整生命周期，因此它们才应该成为系统设计的核心。

当实体成为核心之后，实体之间稳定存在的关系也变得重要起来。角色与角色之间有关系，角色与剧情之间有关系，剧情与任务之间有关系。把这些关系结构化表达出来之后，就形成了一张知识图谱。这张知识图谱不仅用于检索，更重要的是为后续所有 AI 能力提供统一的上下文来源。

在此基础上，我们进一步设计 SOP（标准作业流程）。每一道工序都需要明确规定输入和输出，而负责完成工序的对象，无论是人、AI、工具还是 Workflow，本质上都只是执行单元。执行单元会随着技术的发展不断变化，但输入输出的标准不应该变化。

多个 SOP 串联之后形成 Pipeline，它负责推动业务实体从一个生命周期阶段流转到下一个生命周期阶段。当 SOP、执行单元和 Pipeline 被验证有效之后，再通过系统进行固化，最终沉淀为组织能力。这样经验不会停留在某个人身上，而能够持续复用和演进。

取数据同样需要区分不同场景。对于高度结构化的信息，例如配音配置、数值配置等内容，直接读取权威数据源即可；而对于剧情背景、角色关系、设定解析等半结构化甚至非结构化信息，则需要借助 AI 对上下文进行理解、筛选和重组，才能转化为后续流程能够消费的输入。

沉淀出的几个原则

经过这一年的实践，我们越来越确信几件事。

首先，应该先抓实体，再设计流程。Pipeline 和 SOP 都应该围绕实体生命周期构建，而不是反过来。

其次，输入输出必须标准化。每个环节只消费自己需要的信息，同时产出能够被下一道工序直接消费的结果。

再次，执行者并不是重点。人和 AI 本质上都只是执行单元，关键在于谁更适合完成当前工作。

另外，System 的价值在于把隐性经验转化为可执行机制。如果所有经验都停留在人脑里，那么组织能力就无法积累和复用。

最后，事实源、标准和数据回流机制必须掌握在核心团队手中。能力可以开放，但系统中的事实定义权不能丢失。

这套逻辑，放到任何团队都成立

回头看这一年的实践，我们最大的收获并不是学会了如何接入大模型，也不是搭建了多少 Agent。

真正的变化来自认知上的转变。

最初，我们把 AI 当成一个更聪明的搜索框，希望通过知识库解决问题。经过一些实践发现，真正需要被管理的并不是知识本身，而是那些贯穿整个生命周期、持续演进并最终交付的业务实体。

当实体成为核心之后，知识图谱、SOP、Pipeline 和上下文服务才逐渐有了统一的组织方式。从这个角度看，AI Native 并不是给员工配一个 Claude，也不是在现有系统旁边增加一个 AI 功能，而是围绕业务实体重构生产体系，让信息能够持续沉淀、流转和回流。

AI 只是其中的一个参与者。

真正需要被设计的，是支撑 AI 与人共同协作的生产系统。