AI 协作实践：软件工程的下一个管理对象

过去两年，企业布局 AI 大多遵循相似路径：采购 Codex、Claude Code 等 AI 编码工具，搭建统一的大模型服务平台，将 AI 能力纳入研发流程，再通过企业内部培训推动工程师使用。就部署进度而言，这一阶段已基本完成，AI 正从试验性技术逐步成为研发团队的标准配置。

从个体效率维度来看，这些投入已见到明确成效。Google DORA 在《State of AI-assisted Software Development 2025》中指出，超九成受访开发者已在日常研发中使用 AI，超八成开发者认为 AI 提升了自身工作效率。但同一份报告也呈现出值得关注的分化：约三成开发者仍对 AI 输出结果存疑；不同团队引入 AI 后的收益差距，远大于工具本身的差异。

企业面对的核心问题正在发生转变。

此前讨论 AI，焦点是"要不要部署"；如今更值得探讨的是"为什么完成相同部署，不同团队的收效天差地别"。部分团队能持续沉淀 AI 使用经验，研发效率随着时间不断提升；另一些团队即便配备了同款模型、同款工具，AI 应用也始终停留在个人层面——项目结束后，大量实践经验也随之消失，新成员加入仍要从头摸索。

DORA 将这一现象总结为：AI 更像是一种能力放大器（Amplifier），而非能力创造者。 它既能放大优秀团队已有的软件工程能力，也会放大流程、协作与治理中的短板。这也解释了同款 AI 工具为何在不同组织中效果迥异：决定收益上限的从来不是模型能力，而是团队能否持续吸收、沉淀 AI 协作实践。

很多企业应对这一问题的第一反应，是升级模型、追加培训或是引入新的开发工具。这些手段确有必要，但解决的大多是"个人如何用好 AI"的问题，而非"组织如何持续沉淀 AI 能力"。当前多数研发团队真正缺失的，不是更多 Prompt，也不是更先进的模型，而是能将个人与 AI 的协作经验持续沉淀、共享与演进的工程化机制。

本文想要探讨的，并非如何提升单个工程师的 AI 使用技巧，而是一个更具长期价值的命题：

如何将人与 AI 协作形成的实践方法纳入软件工程体系，让它们像代码一样可管理、可复用、可持续演进。

这是本文要回答的核心问题，也是企业 AI 建设正在迈入的新阶段。

软件工程管理的从来不止是代码

要回答这个问题，我们需要先回到软件工程的本质。

在很多认知里，软件工程的管理对象就是代码。版本管理、代码评审、持续集成、自动化测试、交付流程，几乎所有工程实践都围绕代码展开。也正因如此，AI 介入研发后，人们很自然地将关注点放在生成代码的质量上，比如模型是否足够智能、输出是否准确、代码接受率是否提升等。

但代码从来不是软件工程的最终目标，只是工程的载体之一。软件工程的所有机制设计，本质上都围绕知识沉淀展开。

工程核心是将个人经验转化为团队能力，并让这些能力随项目持续积累和演进。代码的价值不止于实现业务逻辑，更在于它能嵌入一套成熟的工程体系：开发者提交代码，团队通过评审完成知识共享，版本管理记录演进轨迹，自动化测试守住质量底线，持续集成 / 持续交付（CI/CD）保障每一次修改都能稳定上线。经过这一系列工程活动，个人经验最终沉淀为团队共同维护的资产。

过去几十年，软件工程的绝大多数创新都围绕这一目标展开。从版本控制系统到持续集成，从自动化测试到 Infrastructure as Code（基础设施即代码），这些实践突破的都不是某一项具体技术，而是知识复用、协作与持续演进的方法。软件工程的发展史，本质就是知识工程化的演进史。

AI 的引入没有改变这一核心目标，只是改变了知识产生的场景。

传统软件开发中，大部分工程经验最终都会沉淀在代码里。随着 AI 辅助开发成为常态，越来越多影响研发质量的关键经验，开始出现在开发者与 AI 的协作过程中：比如如何组织上下文、如何拆解复杂需求、如何逐步引导模型完成推理、如何约束生成结果，以及何时该终止 AI 建议、切换为人工判断。这些决策通常不会直接体现在最终提交的代码里，却越来越直接地决定 AI 输出的稳定性与质量。

换言之，AI 时代诞生了一类软件工程过去极少管理的对象——协作实践。这类实践既不属于业务知识，也不等同于代码实现，是开发者在长期使用 AI 的过程中逐步摸索出的工作方法，且绝大多数仍停留在个人层面：它们可能散落在聊天记录、个人笔记、本地 Prompt 文件里，甚至只存在于工程师的工作习惯中，项目结束后很少能转化为团队的共同能力。

站在软件工程的视角看，这正是新的工程对象诞生的信号。

AI 时代，软件工程迎来新的工程对象

软件开发早期，工程实践主要围绕源代码展开。随着系统规模持续扩张，仅管理代码已不足以支撑复杂项目的协作，测试用例、构建脚本、部署配置、基础设施乃至运行环境，逐步被纳入软件工程体系。Infrastructure as Code、Configuration as Code（配置即代码）等实践的出现，都遵循着同一个核心原则：凡是影响软件质量、需要长期维护的对象，都应纳入工程体系，而非依赖个人经验维系。

AI 的广泛普及，让软件工程再次面临相似的变化。前文提到的各类协作经验——上下文组织方式、任务拆解策略、模型行为约束、人工介入时机——直接影响 AI 的输出质量，却很难从最终提交的代码中反向还原。如果始终停留在个人层面，它们就无法接入软件工程已有的知识积累机制。

所以当前企业真正缺失的，不是更多 AI 工具，而是可落地的 AI 协作实践管理机制。

这里所说的"协作实践"，不是单条 Prompt，也不是单次对话记录，而是经过持续验证、可跨项目复用、能随团队实践不断演进的一整套工作方法。它有明确的适用场景，可持续优化，也需要像代码一样经历评审、版本管理与演进过程，已经具备了典型的工程对象特征。

过去，代码是软件工程最核心的工程对象，承载着软件系统的实现逻辑；如今，AI 协作实践同样承担起知识沉淀与经验复用的职能。二者承载的内容不同，但都是组织需要长期维护的核心资产。

这一变化也给软件工程提出了新的命题：如何让 AI 协作实践像代码一样，被持续管理、持续演进，最终沉淀为稳定的组织能力。 行业内已经出现了围绕这一方向的探索，也正在逐步形成共同的演进路径。

行业探索的方向与现有工具的边界

过去一年，行业对 AI 协作的探索走出了多条路径，它们分别解决不同层面的问题，却尚未触及"组织沉淀工程实践"的核心。

• 有的团队搭建 Prompt Library，沉淀高质量输入模板，解决单次 Prompt 的复用问题；
• 有的完善知识库与 RAG（Retrieval-Augmented Generation，检索增强生成）方案，帮助 AI 获取更多上下文信息，解决信息获取问题；
• 有的探索 Memory 能力，保留跨会话的协作状态，解决上下文持续保持的问题；
• 还有的基于 Agent Framework 或 AI Workspace 搭建工作流，尝试让 AI 完成连续、多步骤的任务，解决任务编排问题。

这些探索方向各有侧重，并不冲突，分别补齐了 AI 协作的不同基础能力。与此同时，行业也出现了更贴近工程化方向的新尝试：Anthropic 在 Claude Code 中引入 CLAUDE.md，让 AI 进入项目时能主动理解团队约定、工程规范与协作方式，无需开发者每次重复输入；由 OpenAI、Google、Cursor 等联合推出、现由 Linux 基金会维护的 AGENTS.md 开放标准走得更远，尝试建立统一的项目约定，让不同 AI Agent 都能通过标准格式理解项目背景、开发规范、可调用工具与协作边界，将临时提示词变为可随项目持续维护的工程配置。

但从组织能力建设的视角看，目前所有这些工具与探索，仍未完成最核心的跨越。

Prompt Library 能保存经过验证的模板，却无法承载一项工程实践的形成背景、适用范围与演进逻辑；知识库与 RAG 能让 AI 检索到规范，却无法判断何时该引用规范、何时需要人工介入、何时调整协作策略；Memory 能保留上下文状态，却不会自动筛选哪些实践值得推广、哪些已经失效，更无法替代团队对工程规范的持续维护。

它们解决的核心是模型如何获取信息，而非组织如何积累实践；它们更偏向支撑 AI 运行的基础设施，而非管理 AI 协作的治理机制。即便企业全部部署了这些能力，依然可能陷入同一个困境：优秀工程师的经验在持续增长，却始终停留在个人层面，无法转化为团队的稳定能力。

Prompt、Memory、知识库、Agent 都是构建治理机制的重要基础，但不能替代治理机制本身。真正的问题依然存在：组织需要在这些基础能力之上，建立一套怎样的工程过程，才能让协作实践持续沉淀下来？

AI 协作实践如何融入软件工程体系

软件工程之所以能够支撑大规模协作，并不是因为拥有完善的开发流程，而是因为它建立了成熟的知识演进机制。任何经过实践验证的工程经验，都不会长期停留在个人层面：它会进入代码仓库，接受团队评审，随版本持续迭代，最终成为全团队共同维护的工程资产。代码如此，测试规范如此，基础设施配置同样如此。

AI 协作实践也应遵循相同的规律。今天，大量高价值的工程经验已经不再直接体现在代码之中，而是在开发者与 AI 的协作过程中逐步形成。这些经验同样会不断演进，也同样需要跨团队共享，因此，它们理应进入软件工程已经成熟的治理体系。

从工程管理的角度来看，一个完整的 AI 实践生命周期至少包含四个阶段，且四个阶段形成持续循环，而非线性流程。

实践发现

AI 的最佳实践无法通过顶层设计产生，只能在真实项目中逐步沉淀。工程师在持续使用 AI 的过程中不断尝试新的协作方式，其中只有少数能够稳定提升研发效率，并具有跨项目复用价值。

实践验证

个体经验并不等于组织经验。只有当一种协作方式能够在不同项目、不同成员甚至不同模型环境下保持稳定效果时，它才具备进入团队工程规范的价值。验证的目的，并不是寻找唯一正确的方法，而是筛选出能够持续复用的实践。

标准化落地

这里的标准化并不意味着固化 Prompt，而是将实践整理为团队可以共同维护的工程对象，例如 AGENTS.md、CLAUDE.md、组织级系统指令、共享 Skills、Agent 配置或者其他适合当前研发体系的工程载体。它们均可纳入版本管理，随项目持续演进。需要强调的是，标准化的终点不是"写进文档"，而是分发生效：通过项目模板、脚手架或统一平台，让这些实践成为新项目的默认配置，而不是需要开发者主动查阅的知识。

持续演进

AI 实践并不是静态资产。模型能力不断变化，业务系统持续演进，团队经验也会持续积累，因此实践本身同样需要接受版本管理、代码评审和持续优化。每一次工程实践的调整，都应当像代码修改一样具有明确的变更原因、评审过程和历史记录。

新的实践不断产生，已有实践不断被验证和修正，工程规范也会随着模型能力和业务变化持续演进。这与软件工程过去几十年管理代码、测试和基础设施的方式并没有本质区别。

AI 时代的软件工程并不是需要全新的开发流程，而是在现有工程体系中增加一种新的工程对象——AI 协作实践。当这些实践能够完整走完发现、验证、标准化、演进的循环时，组织积累的将不再只是零散的开发经验，而是能够持续复制和扩展的 AI 工程能力。

组织落地容易陷入的三个误区

如果将 AI 协作实践纳入软件工程视为一项新的工程能力建设，那么企业真正面对的挑战，并不是选择哪一种模型或工具，而是如何建立与之匹配的治理机制。从目前大量团队的实践来看，AI 建设过程中反复出现的问题，几乎都源自三类治理认知误区。

误区一：错把工具部署等同于 AI 能力建设

这是目前最常见的一种情况。

企业采购 AI 工具、完成模型接入、组织内部培训之后，往往认为 AI 建设已经完成。随后，AI 的使用完全交由工程师自行探索，团队既不会持续沉淀新的协作经验，也没有机制评估哪些实践值得推广。

这种模式能够提升个体效率，却很难形成组织能力。工具部署解决的是"能不能使用 AI"的问题，而组织能力建设关注的是"如何持续积累 AI 实践"。如果缺少后者，即使所有工程师都开始使用 AI，团队获得的收益也会随着人员变化不断波动，而不会形成稳定的能力增长。

误区二：将 Prompt 当作实践沉淀的最终载体

随着 Prompt Engineering 的普及，越来越多团队开始建设 Prompt Library，希望通过共享 Prompt 提高整体使用水平。

Prompt 的确具有复用价值，但它并不是工程实践本身。同样一句 Prompt，在不同项目、不同模型、不同上下文中可能产生完全不同的结果。真正具有长期价值的，是 Prompt 背后的协作策略：为什么要这样组织上下文、为什么采用这样的任务拆解方式、为什么选择当前模型，以及这些经验适用于哪些工程场景。

如果组织最终沉淀的只是 Prompt，而没有沉淀形成 Prompt 的工程经验，那么团队仍然需要不断重复理解和试验的过程，无法形成真正的能力复用。

误区三：没有建立可持续的实践演进机制

还有一些团队已经开始积累 AI 实践，也建立了 Prompt Library、团队规范甚至 Agent 配置，但这些内容往往停留在文档层面。

它们缺少版本管理、缺少评审机制，也缺少持续反馈。模型升级之后，没有人确认哪些实践仍然有效；团队积累新的经验之后，也没有机制将其纳入统一规范。随着时间推移，这些内容逐渐失去维护，最终重新回到个人经验。

这也是 AI 实践与传统知识文档最大的区别：它不是一次性沉淀的知识，而是一种持续演进的工程对象。只有将 AI 实践纳入版本管理、代码评审以及持续维护流程，组织才能真正建立稳定的知识积累机制，而不是不断重复相同的探索过程。

从根本上看，上述三个问题都指向同一个原因：企业已经完成了 AI 工具建设，却尚未完成 AI 工程治理。 模型能力仍然会持续进步，开发工具也会不断演进，但真正决定长期竞争力的，将越来越不是模型本身，而是组织能否建立持续发现、验证、沉淀和演进 AI 协作实践的工程机制。

落地 AI 协作实践工程化的三个核心原则

将 AI 协作实践纳入软件工程，并不意味着企业需要重新设计一套研发体系。相反，大多数团队已经具备成熟的软件工程基础，包括版本管理、代码评审、持续集成、工程规范以及研发协作流程。AI 时代真正需要增加的，并不是一套新的管理体系，而是在现有软件工程框架中增加一种新的工程对象，并为其建立相应的治理机制。

从已有实践来看，组织推进这一过程可以遵循三个核心原则。

原则一：聚焦实践本身，而非单一工具

AI 工具会持续演进。模型会不断升级，Agent Framework、Memory、开发环境乃至交互方式都可能发生变化。如果组织能力建立在某一种工具之上，那么每一次技术迭代都意味着重新学习和重新迁移。

相比之下，工程实践具有更长的生命周期。无论底层模型如何变化，需求分析的方法、上下文组织方式、团队协作规范以及人工介入策略都会持续存在，并随着实践不断完善。因此，组织真正需要沉淀的，不是某一种工具的使用技巧，而是能够跨工具、跨模型持续复用的协作实践。

原则二：融入现有工程治理体系，不搞独立流程

AI 实践不应成为独立于软件工程之外的新流程。对于已经验证有效的协作实践，应当与代码、测试规范和工程配置一样进入版本管理，接受评审，并建立明确的维护责任。

这意味着，AI 实践同样需要版本演进、变更记录和持续维护，而不是停留在团队分享、知识库或者个人笔记之中。只有进入工程治理体系，它才能真正成为组织长期维护的工程资产。

原则三：视实践演进为长期过程，而非一次性交付

软件工程的发展从来不是一次完成的。编码规范会持续调整，CI/CD 流程会不断优化，架构设计也会随着业务演进持续变化。AI 协作实践同样具有动态演进的特征。

模型能力不断提升，新的开发工具持续出现，团队也会在真实项目中积累新的经验。因此，组织更需要建立持续反馈机制，使新的实践能够不断进入工程体系，而已经失效的实践能够及时被修订或淘汰。从这个意义上说，AI 建设并不是一个独立项目，而是一项持续演进的软件工程能力建设。

回顾软件工程的发展历史，每一次工程对象的扩展，都伴随着工程治理能力的完善。代码如此，测试如此，基础设施如此，AI 协作实践同样如此。当组织能够以软件工程的方法持续管理这些实践时，AI 的价值才会从个人效率提升，逐步转化为组织能力的持续积累。

部署 AI，并不意味着拥有 AI 能力

回到文章开头的问题：为什么越来越多企业已经完成了 AI 部署，却依然没有形成真正的 AI 能力？

答案的核心在于两层建设的差异：企业部署的模型、工具和开发环境，解决的是 AI 的可用性问题；而组织真正需要建设的工程治理机制，解决的是 AI 能力的沉淀问题。两者并不矛盾，但也不能相互替代。

过去两年，大多数企业已经完成了第一层建设：模型能力持续提升，开发工具快速演进，Agent、Memory、RAG 等能力不断成熟，AI 的使用门槛已经显著降低。但工具的普及并不会自然转化为组织能力。真正决定长期收益的，永远是组织能否将个人经验沉淀为团队能力，并让这些能力随着项目持续积累。

对企业而言，接下来的核心任务，是从"AI 工具部署"转向"AI 工程治理"。不需要推翻现有的研发体系，只需要将 AI 协作实践视为一类新的工程对象，用管理代码的成熟方法去管理它：让它可被发现、可被验证、可被标准化、可持续演进。

软件工程的发展历程早已证明，组织能力从来不是来源于某一种技术，而是来源于工程实践的持续积累。AI 没有改变这个底层逻辑，只是把需要积累的对象，从代码扩展到了人与 AI 的协作方式。谁能先把这套协作实践真正纳入工程体系，谁就能在 AI 时代建立起难以复制的长期竞争力。