AI 开发时代的控制反转 • HUYIFAN

一个功能从提出到上线，要经过需求确认、方案设计、任务拆分、开发、测试、审查、交付和维护。这套完整过程被称为软件开发生命周期（SDLC），是行业长期经验的沉淀。

成熟团队的日常开发依赖大量隐性工程判断：沿用既有的模块划分和命名约定、在涉及公共接口或核心数据时增加复核环节等。这些判断贯穿整个开发过程，却很少被统一规范化和持久化，而是依靠资深工程师通过代码审查和日常协作传递。开发节奏稳定时，这套方式足以维持，因为总有人熟悉项目，也总有人能及时发现偏差。

Claude Code、Codex 等 AI 编程工具的出现，正在改变这一节奏。过去数天的工作，现在几十分钟就能得到一版结果。变更更频繁，影响面更难预判，一次小修改可能触及开发者尚未意识到的多个功能。测试全绿不等于目标达成，故障时还需要追溯变更背后的决策过程。此外，AI 模型的上下文窗口有限，长任务中随时可能丢失规则约束、扩大修改范围、堆积冗余代码。

依赖人来承担工程治理，已经无法匹配 AI 的代码产能。

一、提示词和 Workflow 无法独立承载持续的治理判断

最直接的应对方式，是给 AI 更详细的提示词：控制修改范围、保持单一职责、完成测试并同步文档。这些要求能改善结果，但同一条原则在不同任务中要求不同的检查内容和执行粒度。例如“保持最小修改”原则，用在页面文案调整时，要求是减少文件变动；用在数据库迁移时，要考虑兼容性和回滚；用在公共接口修改时，还要检查所有调用方。随着提示词增长，真正适用于当前任务的要求反而被淹没在大量通用说明之中。

更根本的困难在于，提示词是静态的，而任务是动态展开的。一旦 AI 在执行中引入新的依赖或触及未预期的模块，已有的提示词不会自行更新，也无法追加此刻真正需要的检查。

Workflow 能约束 AI 按步骤推进，但步骤是预设的。如果 AI 在编码阶段自主引入了一张新的数据表，Workflow 不会因此自动在测试阶段追加数据迁移检查。预设流程之外，仍然需要有人持续判断哪些工程义务尚未满足，以及现有结果是否足以推动任务前进。

二、从分散控制走向控制反转

当提示词和 Workflow 都无法承担这些判断时，问题的关键就不再是怎样让 AI 更好地执行，而是如何掌控整个开发过程。由此，原本分散在开发者经验、提示词、Workflow 和聊天记录中的控制逻辑，需要被提取出来，交给一个独立运行层统一处理。

本文将这种控制权变化定义为 AI-SDLC 治理控制反转（Governance Inversion of Control in AI-SDLC，GIoC）：

在 AI 参与的软件开发生命周期中，将任务确立、规则适用、工程义务计算、动作授权、证据接纳、生命周期推进和完成判定，从交互 LLM 基于会话上下文的临时判断中提取出来，交由独立运行层（GIoC Runtime）统一协调。

这与软件工程中的控制反转有结构上的相似性。Spring 框架将对象的创建和依赖管理，从业务代码转移到容器；GIoC 则将任务治理的控制权从交互 LLM 转移到 Runtime。在这一结构中：

交互 LLM 负责理解用户意图、讨论方案并发起治理请求。
GIoC Runtime 负责回答三个问题：当前任务是什么，接下来还需要完成什么，刚刚完成的结果是否足以推动任务进入下一阶段。
执行能力（AI Agent、脚本、CI 或人工操作）负责实际完成写代码、跑测试、生成文档等具体动作。

控制反转前

交互 LLM 调用 Agent 或工具并接收结果。任务组织、规则适用、结果判断和流程推进由交互 LLM 与人工分散维持。

控制反转后

Runtime 根据生效规则和持久化治理状态计算当前工程义务，向执行能力派发获得授权的工作；执行结果返回后，由 Runtime 完成证据校验、状态更新和生命周期推进。

三、GIoC Runtime：AI-SDLC 的治理运行层

GIoC Runtime 位于交互 LLM 与执行能力之间。它保存任务事实，读取当时生效的规则，观察已经发生的修改和验证结果，并据此计算下一步需要完成的事项。

一次变更可以完成实现但仍缺审查，可以通过审查但仍有遗留事项，可以处理完遗留事项但尚未正式交付。这些是不同的工程事实。因此，符合 GIoC 原则的系统需要为任务建立完整的生命周期，并在每个阶段计算当时必须满足的工程义务——即该阶段可核查的工程要求，包括测试基线验证、范围检查、文档同步和代码审查等。

控制权的落地依赖两个机制。

票据化授权。 对于被标记为需要票据的受管操作，Runtime 校验与任务绑定的有效票据，并据此确认当前允许的操作范围，未获授权的操作不能推动治理状态。这使得“谁授权了这次变更”成为执行时的硬约束，而非事后追溯的问题。

证据的可验证接纳。 执行结果要进入治理记录并推动任务前进，需要具备可重新核验的依据，例如测试结果、审查产物，以及与代码或状态关联的可验证记录。只有可重新验证的结果才被接纳，这使治理记录从操作日志升级为可审计证据。

任务、规则、执行结果和证据，经由 Runtime 形成一套持久化的治理事实，不依赖 LLM 的会话记忆。任务可以跨会话暂停、恢复和继续推进；后续参与者也能还原任务当时的工程要求、执行过程和推进依据。

四、Delta 引导执行

任务启动时实际生效的规则、项目配置和上下文，共同构成该次任务的治理环境。在确定的治理环境中，GIoC Runtime 随着任务事实的变化，重新比较“任务希望达到的状态”与“当前已经发生的事实”。两者之间尚未消解的部分，就是治理差异（Delta）。

每个 Delta 说明当前还缺什么、由何种规则或事实触发、可采取什么动作，以及处理后会推动任务的哪一步。Runtime 按确定性逻辑执行检查和状态推进，将需要推理的工作——方案设计、编码、测试、审查——交给 AI Agent 或人工。执行结果返回后，Runtime 校验并记录，再根据新的事实重新计算 Delta。

Delta 调和循环

Runtime 读取任务目标与当前工程事实，比较两者并计算 Delta。Delta 派发给执行能力后，执行结果更新当前事实，触发 Runtime 重新计算，直到所有 Delta 消解，任务进入下一阶段。

例如，当用户提出“增加登录功能”，交互 LLM 理解意图后，向 Runtime 发起治理请求。Runtime 建立任务、确定范围，计算出初始 Delta：测试基线未通过、范围未检查、文档未同步、代码审查未完成。AI Agent 完成代码修改后，Runtime 重新比较任务要求与当前事实，发现测试基线仍未通过，就将它作为当前需要先处理的 Delta 返回。AI 补全测试后，Runtime 发现范围检查未完成，则继续引导。

在此过程中，如果 AI 实际修改的文件超出了任务声明的范围，例如顺手重构了一个不相关的模块，Runtime 识别到范围偏差，就会阻断后续流程，要求先处理范围偏差。范围收敛后继续消解剩余 Delta，直到所有工程义务满足，任务进入下一生命周期阶段。

这一调和机制与 Kubernetes 的控制循环相通。K8s 持续比较集群的期望状态与实际状态，驱动基础设施向期望状态收敛；GIoC 持续比较任务目标与当前工程事实，驱动开发过程向工程义务完成收敛。

五、工程价值与治理延伸

治理环境的版本化。 开发团队的工程原则与配置通常分散且持续调整。符合 GIoC 原则的系统会将这些要求整理为可追溯的治理环境，并记录任务执行时所依据的规则版本。事故调查时，团队能够调取当时生效的治理环境，明确该次变更受何种规则约束、履行了哪些义务以及由谁授权。

生产过程的确定性。 开发者、交互 LLM 和审查者在 GIoC 运行结构内围绕同一套任务事实协作。工程规则得以跨模型与工具复用，促使隐性经验转化为团队公共机制，并降低底层工具更迭后反复重建流程的成本。

可信的变更记录。 Git 保存代码差异，Agent 留下会话日志，工单记录需求，测试平台保存验证结果。GIoC 将这些分散信息建立可追溯联系，说明 AI 的任务目标、修改范围、适用规则与实际执行情况，并关联到相应的代码提交和版本。

审计与监管。 AI 深度参与核心系统开发后，软件产品的合规治理需要能够还原一次变更的任务来源、修改范围、验证过程和责任依据。欧盟《网络韧性法案》已为适用范围内的数字产品确立技术文档要求，覆盖设计、开发、漏洞处理、测试和软件组成等信息。相关义务以产品及其开发过程为对象；AI 加入开发后，能够持续形成并核验这些记录的治理结构，将成为质量管理、变更控制和合规举证的共同基础。对于金融、医疗和工业软件等严监管行业，GIoC 形成的记录可以作为质量保证、变更控制、内部审查和外部监管的结构化输入。

交付确定性、组织能力沉淀和可信记录构成了 GIoC 的直接工程价值；审计与监管支撑则是这一运行结构的自然延伸。

六、结语

当编码范式从人工编写转向 AI 生成，软件开发的关键约束也从代码产能转向工程治理。GIoC 是本文对这一变化给出的结构性回应。

GIoC 中哪些治理要素真正有效，需要在真实项目里经过任务偏移、规则遗漏和审查不足的反复检验，稳定下来的部分才可能被更多团队采用，最终沉淀为通用规范。

七、相关工作

GIoC 与这两项工作关注的问题有交集，但出发点不同：前者侧重静态协议与证据，后者侧重案例观察与经验提取；GIoC 从控制结构层面，将任务状态维护、义务计算和生命周期推进，统一为一个运行时问题。