AI开发从原型到生产：企业必须构建的治理工作流

AI Coding 在 Demo 阶段很迷人。

你给 AI Coding Agent 一个需求，它能快速生成代码；你让它修一个 Bug，它能迅速定位问题；你让它写一个小工具，它可能几分钟就完成。对于脚本、原型、内部小工具、一次性页面，这种效率提升非常直观。

但企业真正要面对的问题不是 Demo。

企业要面对的是会议系统、直播系统、邮件系统、客服系统这类长期运行的生产系统。这里的代码不是“能跑就行”，而是要面对真实用户、真实数据、真实权限、真实 SLA、真实线上事故。

一旦 AI Coding 进入生产系统，风险就不只是“代码写错”。

更大的风险包括：

所以，提示词不等于工作流。

AI Coding Agent 能力越强，企业越不能只靠聊天窗口、临时提示词和个人经验。DORA 2025 对 AI-assisted software development 的判断非常关键：AI 的首要作用更像一个“放大器”，会放大组织已有的优势，也会放大组织已有的混乱；真正的 AI 投资回报，不只是来自工具本身，而是来自底层组织系统。[1]

这句话放到 AI Coding 场景里，就是：

混乱的研发流程接入 AI Coding Agent，只会更快地产生混乱；成熟的软件工程体系接入 AI Coding Agent，才可能真正形成降本提效。

因此，AI Coding 从玩具到生产系统，企业真正要建设的不是一个“更会写代码的工具”，而是一套让 AI Coding Agent 可控、可验、可复盘、可进化的 AI 原生软件开发工作流。

在前面的连载中，我们已经建立过 AI Coding 七阶段成熟度模型。

这个模型的价值，不是为了证明 AI Coding 一定要走到最深层，而是为了帮助团队判断：

当前任务应该停在哪一层。

连载三已经讲过：AI Coding 不是越深越好，关键是停在正确一层。

那为什么连载四要重点讲第七阶段？

因为第七阶段“AI 原生软件开发工作流”不是孤立的一层，而是一套完整的软件工程系统。它可以向下涵盖前六阶段，只是不同任务使用的治理强度不同。

所以，第七阶段不是让 AI Coding Agent 更自由，而是让组织治理更成熟。

它不是一个更强的工具能力，而是一套组织级软件工程机制。

企业要把 AI Coding Agent 放进生产系统，不能只靠“会不会提示”。

真正可持续的 AI 原生软件开发工作流，应该由五个驱动构成：

工件驱动 + 流程驱动 + 测试驱动 + 审批驱动 + 知识沉淀驱动。

第一，工件驱动。

企业不能把需求、规则、上下文、测试标准、Review 标准全部放在聊天窗口里。聊天窗口适合沟通，但不适合承载长期治理。真正能被团队复用、被 AI Coding Agent 读取、被人审计、被项目继承的，是稳定的工程工件。

这就是本文统一使用的术语：

AI Coding 工程治理工件体系。

它包括 AGENTS.md、OpenSpec、context-index、engineering 规范、code_review.md、runbook.md、knowledge、workflows、scripts/verify.sh 等。

第二，流程驱动。

AI Coding Agent 不能一上来就写代码。进入生产系统的正确流程应该是：先规约、再设计、再计划、再执行、再验证、再 Review、再发布、再复盘。

第三，测试驱动。

AI Coding Agent 生成的代码不能因为“看起来合理”就被相信。它必须通过 lint、typecheck、unit test、integration test、build、security scan 等验证。

第四，审批驱动。

人类不能把责任交给 AI Coding Agent。产品目标、需求边界、技术方案、上线风险、发布审批，必须由人确认。

第五，知识沉淀驱动。

每次任务结束后，组织必须回答：这次哪里做对了？哪里错了？为什么错？下次如何避免？哪些规则、上下文、Workflow、Skill、Knowledge 需要更新？

一次提示词只能启动一次任务。

五驱动机制，才能支撑组织级 AI 原生软件开发工作流。

这套方法不是凭空设计出来的。它是在吸收 OpenAI Codex、AGENTS.md、GitHub Spec Kit、OpenSpec、Superpowers 等理念之后，面向企业生产系统落地做出的组合。

OpenAI Codex 官方文档明确说明，Codex 在开始工作前会读取 AGENTS.md；通过全局规则和项目级覆盖，团队可以让每个任务从一致的预期开始。[2]

AGENTS.md 官方站点把 AGENTS.md 定义为“给 AI coding agents 的 README”，也就是一个专门、可预测的位置，用来告诉 AI Coding Agent 如何在项目中工作。[3]

这说明 AGENTS.md 的职责不是写具体需求，而是建立项目长期规则。

GitHub Spec Kit 则强调：先定义要构建什么，再构建。它把 Spec-Driven Development 放到 AI-assisted software development 的中心，核心流程是 Spec → Plan → Tasks → Implement。[4]

GitHub 官方博客进一步强调，在这种流程下，开发者的角色不仅是 steer，更是 verify。AI 可以生成工件和代码，但人必须在每个阶段检查：规格是否真正表达了想要的东西？计划是否考虑了现实约束？是否遗漏了边界场景？[5]

OpenSpec 的价值在于把规格和变更管理得更轻量。它将 specs 作为系统行为的 source of truth；每个 change 有 proposal.md、design.md、tasks.md 和 delta specs；变更完成后再合并回长期 specs。[6]

Superpowers 则更强调过程纪律。它不是让 AI Coding Agent 直接跳进写代码，而是先澄清目标，形成规格，得到设计确认，再制定 implementation plan，并强调 TDD、YAGNI、DRY 等工程纪律。[7]

Codex Skills 进一步提供了能力复用机制。OpenAI 的 Codex Skills 文档说明，Skills 采用 progressive disclosure：Codex 初始只看 Skill 的名称、描述和路径，只有决定使用时才加载完整 SKILL.md，这有助于控制上下文开销。[8]

这些工具和理念不是互相替代，而是分层协作：

真正的企业落地，不是选一个工具，而是把这些理念组合成 AI Coding 工程治理工件体系。

这里必须先破一个误区：

治理文档不是越多越成熟，而是越少、越准、越可复用，越有价值。

如果一个团队为了用 AI Coding Agent，一上来就写几十个文档，让所有人每天围着文档打转，那不是治理成熟，而是新的流程负担。

真正可落地的策略应该是：

保留完整目录骨架，内容按需填充，从最小闭环启动。

推荐的项目目录结构可以这样设计：

这里有几个关键设计。

第一，去掉 docs/product.md。

因为项目长期目标、系统边界、长期产品方向，更适合放在 openspec/project.md 中，避免和 docs/product.md 重合。OpenSpec 管“产品目标、行为规格、需求变更”；docs 管“工程上下文、开发规范、运维、知识和流程沉淀”。

第二，阶段性产物不要散落在根目录。

建议放到：

例如：

这样每次 AI Coding Agent 的执行，都能追踪到对应 change、对应计划、对应验证、对应 Review、对应复盘。

第三，不要一开始填满所有目录。

初始阶段只需要最小闭环：

其他 docs/engineering、docs/knowledge、docs/workflows，可以先建目录、写用途说明，后续随着真实任务沉淀。

这才是最小必要的 AI Coding 工程治理工件体系。

完整的 AI 原生软件开发工作流，不是“需求 → 写代码 → 提交”。

它应该是一个闭环：

前 8 步解决的是一次交付。

第 9、10、11 步决定它是否能成为一个可进化系统。

如果没有经验沉淀与错误归因，这只是一次性 AI 编程流程。今天快一点，明天可能还是重复解释、重复犯错、重复返工、重复 Review、重复踩坑。

有了最后三步，它才变成组织能力。

每次完成任务后，团队都应该追问：

AI Coding 工作流的终点不是代码合入，而是复盘、归因、沉淀和下一轮复用。

为了避免文档重合，必须把关键工件职责说清楚。

AGENTS.md：AI Coding Agent 的长期项目宪法。

它负责告诉 AI Coding Agent 怎么工作：必须读哪些文档，不能做什么，如何计划，如何测试，如何 Review，如何总结经验，什么情况下必须请求人工确认。

OpenAI Codex Best Practices 也建议：如果 AGENTS.md 变得太大，就保持主文件简洁，把规划、代码 Review、架构等任务特定内容引用到其他 Markdown 文件；如果 Codex 重复犯同样错误，应要求它做 retrospective，并更新 AGENTS.md。[9]

这正好支撑我们的原则：

AGENTS.md 不是越长越好，而是越短、越准、越能约束关键行为越好。

openspec/project.md：项目长期目标、系统能力边界、长期产品方向。

它是产品目标与系统能力边界的唯一入口，避免和 docs/product.md 重复。

proposal.md：本次为什么做、做什么、不做什么。

它解决本次变更的意图、范围和边界问题。

design.md：怎么设计、影响什么、风险是什么。

它解决技术方案、影响范围、架构决策和风险判断问题。

tasks.md：任务拆解与验证路径。

它把大需求拆成 AI Coding Agent 可以逐步执行、逐步验证的小任务。

docs/context-index.md：上下文最小化。

它告诉 AI Coding Agent：不同类型任务该读哪些文档，不该读哪些文档。上下文不是越多越好，而是越准确越好。

docs/engineering/：技术规范层。

这里放 Python、FastAPI、MySQL、Redis、React、TypeScript、API、Testing、Security、Logging 等规范。它解决“AI Coding Agent 每次按不同风格写代码”的问题。

docs/workflows/：高频任务标准作业流程。

例如新增 FastAPI API、新增 React 页面、增加 MySQL migration、增加 Redis 缓存、修复生产 Bug、发布检查。

docs/knowledge/：经验沉淀层。

这里沉淀 success-patterns、bug-fix-playbook、agent-failure-patterns、legacy-decisions、domain-notes、incident-notes。

docs/code_review.md：质量闸门。

它检查需求一致性、架构一致性、测试充分性、安全风险、可维护性、上线风险。

docs/runbook.md：生产可运营。

Google Cloud 对 SRE 的定义是：SRE 是运行可靠生产系统的一种岗位、思维和工程实践。[10] 所以生产系统不能只关注“代码能跑”，还要关注部署、健康检查、日志、监控、故障处理和回滚。

scripts/verify.sh：统一验证入口。

它不是统一验证内容，而是统一触发入口。

compose.yaml：环境一致性与宿主机纯净。

它让团队尽量不在宿主机安装一堆项目依赖，而是通过容器环境完成构建、测试和验证。

一句话总结：

AGENTS.md 管 AI Coding Agent 怎么工作，OpenSpec 管这次变更到底要做什么。

Linux下容器化开发是我多年的开发习惯，也是我要求我团队的开发准则

很多团队做 AI Coding 试点时，很容易忽略环境问题。

AI Coding Agent 生成代码很快，但如果每个人宿主机上的 Python、Node、MySQL、Redis、系统依赖、环境变量都不一样，那么验证结果就不稳定。

所以，我们必须强调：

尽量不要在宿主机安装项目相关组件。

数据库、缓存、依赖服务、构建、验证、测试，尽量通过 Docker Compose 或容器化环境完成。compose.yaml 负责环境一致性，scripts/verify.sh 负责统一验证入口。

但要注意：

verify.sh 是统一入口，不是统一内容。

不同语言、框架、技术栈，质量检测方法必须不同。

例如：

这一步解决的不只是“能不能跑”。

它解决的是环境一致性、验证一致性和交付可靠性。

也就是说，AI Coding Agent 不是在宿主机上自由试错，而是在可重复、可验证、可回收的工程环境中执行。

第七阶段最重要的地方，不是 AI Coding Agent 写完代码。

真正重要的是任务结束之后。

每次任务完成后，团队必须做一次轻量 retrospective。这里可以由 AI Coding Agent 先生成草案，但必须由人筛选确认。

它至少要回答这些问题：

然后把经验分流：

这就是从一次性 AI 编程流程，走向可进化软件开发系统的关键。

没有这一步，AI Coding 只是每次都快一点。 有了这一步，组织会越来越准、越来越稳、越来越可复用。

真正的降本提效，不是取消责任人，而是减少重复解释、重复编码、重复排错、重复 Review 和重复上线失误。

企业落地 AI Coding，最怕两种极端。

一种是过度乐观：直接让 AI Coding Agent 改核心系统、连测试都不补、Review 也不做。

另一种是过度治理：一上来写几十个文档，所有人都在维护文档，最后 AI Coding 没有提效，反而增加负担。

正确路径应该是五步。

第一阶段：最小治理闭环。

先建立：

目标不是全自动，而是做到：需求说清楚、计划先确认、代码可验证、Review 有门禁、上线有回滚、经验可沉淀。

第二阶段：低风险任务试点。

先从测试补全、文档整理、内部工具、小功能、Bug 修复、非核心模块重构开始。不要一开始就让 AI Coding Agent 改核心交易链路、核心权限系统、核心计费逻辑。

第三阶段：沉淀 workflows。

当某类任务反复出现，就沉淀为 docs/workflows。

例如：

第四阶段：升级 Skills。

当某个 workflow 稳定、高频、可复用，就升级成 Codex Skill。借助 Codex Skills 的 progressive disclosure，只有真正需要时再加载完整 SKILL.md，避免上下文过载。[8]

第五阶段：指标化评估。

不要只看“代码写快了多少”。真正应该看：

用会议系统举例，AI Coding Agent 可以沉淀会议纪要格式、发言人识别规则、权限边界、录音转写测试样例。

用直播系统举例，可以沉淀推流链路、HLS / FLV / WebRTC 协议差异、CDN / 边缘节点配置、延迟指标、回滚方案。

用邮件系统举例，可以沉淀反垃圾规则、黑白名单、投递策略、误伤样本和合规约束。

用客服系统举例，可以沉淀知识库结构、WebSocket 连接策略、坐席状态、会话恢复、质检标准。

业务上下文越能沉淀，AI Coding Agent 越能从临时助手变成组织能力。

回到这一组文章的主线。

第一篇讲的是：软件开发组织模型正在从编码走向编排 AI Coding Agent。

第二篇的四部连载主要讲的是AI Coding 从玩具到生产系统，企业到底该怎么做的来龙去脉。

第二篇连载一讲的是：AI Coding、AI Coding Agent、Agentic Coding 这些概念必须先统一。

第二篇连载二讲的是：AI Coding 不是单点能力，而是七阶段成熟度模型。

第二篇连载三讲的是：AI Coding 不是越深越好，关键是停在七阶段成熟度模型的正确一层。

第二篇连载四讲的是：企业要进入第七阶段，必须建设 AI 原生软件开发工作流。

这个工作流不是工具清单，也不是文档堆砌，更不是让 AI Coding Agent 自主开发一切。

它的本质是：

用最小必要的 AI Coding 工程治理工件体系，把产品目标、需求规格、技术设计、执行计划、测试验证、Review 门禁、发布准备、经验沉淀、规则更新连接成一个完整闭环。

SWEBOK 对软件工程知识的解释提醒我们，“普遍接受”的工程知识并不意味着所有实践都必须一刀切应用到所有项目；项目团队始终需要判断什么实践适合当前项目。[11] IEEE/ISO/IEC 12207 则从生命周期视角强调，软件过程需要能够被定义、控制、评估和改进。[12]

这正是 AI Coding 进入生产系统时最需要补上的一课：

最终，AI Coding 的终局，不是 AI Coding Agent 替代研发团队，而是研发团队用 AI Coding 工程治理工件体系，把软件开发变成可控、可验、可复盘、可进化的组织能力。

真正的分水岭，不是模型更强。

而是组织是否拥有 AI 原生软件开发工作流。

提示词不等于工作流。

AI Coding Agent 不是越自由越高级，而是越受控、越可验证、越可复用，越适合进入生产系统。

第七阶段（AI原生软件开发工作流）不是一个更强的工具能力，而是一套组织级软件工程机制。

AI Coding 的治理文档不是越多越成熟，而是越少、越准、越可复用，越有价值。

没有经验沉淀与错误归因，AI Coding 只是一次性编程流程；有了规则、Context、Skill、Knowledge 的持续更新，它才是可进化的软件开发系统。

AI Coding 降本提效不是取消责任人，而是减少重复解释、重复编码、重复排错、重复 Review 和重复上线失误。

AGENTS.md 管 AI Coding Agent 怎么工作，OpenSpec 管这次变更到底要做什么。

真正的分水岭，不是模型更强，而是组织是否拥有 AI 原生软件开发工作流。

不要一开始追求全自动，先建立最小治理闭环。

先从低风险、可验证、边界清晰的任务试点。

每个项目先建立 AGENTS.md、OpenSpec change、context-index、verify.sh、code_review.md、runbook。

用 Docker Compose 保持环境一致，尽量保持宿主机纯净。

每次任务必须有 verification，不要相信“看起来对”的代码。

每次任务结束后必须做 retrospective 和 update-suggestions。

只把重复出现、真正有价值的经验沉淀进长期文档。

高频 workflow 稳定后，再升级为 Codex Skill。

用指标评估 AI Coding 是否真的降本提效，不要只看代码生成速度。

会议系统、直播系统、邮件系统、客服系统这类长期业务系统，要优先沉淀业务上下文、测试样例、Review 清单、Runbook 和故障经验。

[1] DORA 2025：State of AI-assisted Software Development。

[2] OpenAI Developers：Codex AGENTS.md 指南。

[3] AGENTS.md 官方站点。

[4] GitHub Spec Kit 官方文档。

[5] GitHub Blog：Spec-driven development with AI。

[6] OpenSpec 官方站点与 GitHub 文档。

[7] Superpowers 官方 GitHub 仓库。

[8] OpenAI Developers：Codex Skills。

[9] OpenAI Developers：Codex Best Practices。

[10] Google Cloud SRE 官方文档。

[11] IEEE Computer Society：SWEBOK。

[12] IEEE/ISO/IEC 12207 软件生命周期过程标准。

本文讲解的这套最小化的“AI Coding 工程治理工件体系”的模版文件，我会在随后的时间里脱敏后提供出来，大家有需要的可以留言。