AI Native 受控软件工程

Controlled AI-Native Software Engineering（CANSE）

——从 AI 自动编程，走向 AI 驱动的可控软件工程体系

我认为，未来的软件工程将出现一个重要变化：

软件开发的核心竞争力，不再只是编写代码的能力，而是定义软件、约束软件、验证软件和持续演进软件的能力。

我最近使用 Codex 开发大型项目时遇到的问题，正好反映了这种变化。

以前，开发一个工具类软件，需求相对清晰，代码逻辑简单，运行结果直观，AI 生成的软件是否正确，通常一眼就能看出来。

但是，企业级系统完全不同。

当软件达到几十个模块、上百张数据表、复杂的业务流程和多层依赖关系时，代码正确不等于业务正确，功能存在不等于流程完整，系统能够运行也不等于具备交付条件。

如果仍然采用“提出需求 → AI 生成代码 → 看界面 → 修改”的方式开发，软件规模越大，人的控制能力反而可能越弱。

这就是我提出 AI Native 受控软件工程 的根本原因。

需要先说明：CANSE 是我们在这里归纳和命名的一套工程方法论，不是已经发布的国际标准，也不是 OpenAI 官方产品或官方认证的框架。它融合了需求工程、领域驱动设计、架构治理、契约测试、持续交付和 AI Agent 工程等思想，尤其参考了 OpenAI 于 2026 年 2 月提出的 Harness Engineering 实践。

一、CANSE 的核心定义

AI Native 受控软件工程，是一种以 AI 编程代理为主要实现力量，以人的业务意图和架构决策为控制依据，以自动化测试与运行证据为验证手段，以持续反馈和工程治理为保障的软件开发方法。

可以把它凝练为一句话：

人定义正确性，AI 负责实现正确性，工程体系负责持续证明正确性。

这里的“正确性”不是单纯指代码没有报错，而是软件从需求到运行的多个层面都符合预期。

这套模型有三个重要转变。

第一，从代码驱动转向意图驱动。 不再把软件开发理解为编写功能，而是先确定业务目标、业务对象和预期结果，再让 AI 选择最合适的实现路径。

第二，从人工控制实现细节转向自动化控制架构边界。 人不需要审查每一个函数，但必须掌握关键数据模型、模块依赖、业务规则和接口契约。

第三，从主观验收转向证据验收。 Codex 告诉你“已经完成”，只是开发状态说明，不是交付证明。只有可复现的测试结果、业务操作过程、数据库状态和运行记录，才能支持验收结论。

CANSE 与传统软件工程的区别

CANSE 并不是要在传统软件工程上再增加一套复杂流程。

恰恰相反，它的方向是：

减少人的重复劳动，减少 AI 的无约束自由度，减少无法验证的中间成果。

二、为什么复杂项目需要“受控”？

2.1 AI 编程存在一种特殊风险：实现速度超过理解速度

假设传统开发中，一个工程师每天完成少量可测试的业务功能，项目负责人通常还有机会了解开发过程。

当你使用 Codex 时，它可能在一个开发任务中修改几十个文件，创建多张数据库表，新增多个接口，并同时调整前后端代码。

这时出现了一个不容易察觉的失衡：

软件实现速度与工程掌控能力的关系（概念示意）

真正的问题不是 AI 写不出复杂软件，而是 AI 的实现速度太快，导致软件的复杂度超出了你能够通过界面操作和阅读代码直接掌握的范围。

这时，如果缺少架构约束与测试证据，就会出现四种失控：

其中，验证失控最容易掩盖其他三种问题。

2.2 为什么不能单纯靠更强的模型解决？

即使模型的推理能力和编码能力大幅提升，也不能替代企业业务中的关键决策。

例如，开发一个供应商预付款系统时：

“审批通过后可以付款”，并不能告诉 AI 付款是不是必须绑定合同、是否允许一笔预付款对应多个采购项目、撤销审批是否应回退资金占用、跨公司结算是否需要独立对账。

这些问题的答案来自业务制度，而不是程序设计语言。

AI 可以提出方案，也可以帮助发现矛盾，但不应该把没有确认的业务假设直接变成最终实现。

因此：

模型能力解决的是实现效率，工程控制解决的是目标一致性和结果可信度。

这也解释了为什么传统软件工程中容易被忽视的需求追踪、架构基线和验证机制，在 AI 高速编码时代反而更加重要。

三、CANSE 的五大控制机制

这套方法论真正重要的部分，不是文档格式，也不是某一个开发工具，而是如何把复杂软件中的不确定性转化成受约束、可观察、可验证的工程活动。

我将它划分为五个相互衔接的控制机制。

3.1 目标控制：保证 AI 始终在开发正确的东西

软件开发的第一个问题是：

我们究竟要解决什么业务问题？

传统 Prompt 常常直接描述功能：

开发一个 AI API 中转站系统，支持用户、模型、供应商、渠道、充值、套餐、计费和账单功能。

这句话看似完整，实际上存在大量不确定性。

例如账户是预付费还是后付费？余额扣减发生在请求之前还是之后？流式响应中断以后如何结算？供应商与模型的映射是什么关系？客户是否能够同时拥有多个套餐？

这些问题如果没有明确答案，Codex 就会自行补充假设。

而 AI 自行补充的假设，很可能与你真实的商业运营逻辑不一致。

CANSE 要求首先建立业务真相基线（Business Source of Truth）。

对于一个业务需求，要至少明确六个方面：

这六个维度不要求每次都写成长篇文档，但关键决策必须明确。

最理想的是给每一项核心需求分配稳定的编号，例如 REQ-BILL-001，以后从架构、代码到测试都能追踪这个编号。

3.2 结构控制：保证 AI 不会把系统越写越乱

复杂系统的真正难点，不是功能数量，而是模块之间的依赖关系。

如果一个计费系统存在 20 个模块，理论上的模块两两关系有 190 组。虽然现实中不会每组都产生依赖，但这说明系统复杂度不再只是功能数的线性增长。

因此，你过去强调的“统一架构、合并同类、提炼共用能力、组合实现”非常重要。

CANSE 要求在开发之前，建立一张清晰的领域边界图。

以 AI API 网关为例：

这里需要特别区分共用业务能力与共用代码工具。

例如账户、余额和计费规则是具有明确业务所有权的领域能力，不能因为多个模块需要访问，就在各自模块里重新实现一遍。

而日志、缓存、时间处理、配置读取等属于技术层面的基础能力，可通过共享组件统一提供。

在架构治理上，我建议明确三种约束：

依赖约束。 哪些模块允许直接依赖其他模块，哪些必须通过服务接口通信。

数据约束。 哪个模块拥有数据写入权，哪些数据不得被其他模块直接修改。

业务不变量（Business Invariants）。 无论什么场景，都不能违反的核心业务规则。

例如：

• 同一个已确认计费事件不能重复产生有效扣费。
• 客户的权限检查不能被后台内部接口绕过。
• 账单金额必须能够追溯到计费明细和定价版本。
• 已经形成的财务流水不能因为修改账单页面而直接丢失。

这些规则不能只留在 Prompt 中。能够通过数据库约束、类型系统、静态检查和自动化测试落实的，应尽量转化成机器可执行的约束。

OpenAI 的 Harness Engineering 实践也强调这一点：与其规定 AI 必须如何编写每一段实现代码，不如严格约束模块边界和系统不变量，让代理在边界内自主实现。

3.3 执行控制：让 Codex 只处理边界明确的任务

这一步要解决你的另一个实际问题：如何防止 Codex 一次修改范围过大，导致问题越来越难定位？

我的建议是分层拆解，但纵向交付。

需要注意，L2 不应该再被拆解成一堆永远无法独立运行的孤立菜单。

正确做法是让 Codex 在每个里程碑内，完成贯穿数据层、服务层、接口层和操作层的纵向切片（Vertical Slice）。

举例来说，第一阶段只实现一个客户、一种测试模型、一种定价规则、一条正常调用流程，保证整个计费链路能够运行。

当这条链路通过验收以后，再增加其他供应商、异常计费、套餐折扣和结算功能。

这样可以最大限度减少“做了很多，但什么都没法完整使用”的问题。

3.4 证据控制：把软件变成可证明的系统

这是 CANSE 中我认为最有价值的部分。

传统开发经常把“系统已编译通过”当作一个重要进度指标。AI 编程则可能进一步把“Codex 说已经完成”当作交付依据。

这两个判断都不充分。

CANSE 要求形成一条完整的证据链：

假设需求编号为 REQ-BILL-007：

当上游 API 返回使用量以后，系统必须按照客户生效的价格策略计算费用，并保证同一个已结算请求不会重复扣费。

那么你应该能够从这个需求追踪到对应的接口、业务服务、数据表、自动测试，以及某一次真实的验证记录。

更重要的是，AI 自己生成测试并让这些测试通过，并不能独立证明需求正确。

原因是，AI 可能同时误解需求和测试预期。此时，错误的代码可以通过错误的测试。

因此要区分两个概念：

实现验证（Verification）：系统是否按照设计正确实现？

业务确认（Validation）：这个设计与实现是否真正满足业务目标？

前者可以大量自动化；后者的关键标准必须由业务负责人或架构负责人确认。

3.5 演进控制：避免每一次修改都破坏已有成果

大型软件不是一次性开发完成的，真正困难的是持续迭代。

在没有工程治理的项目里，AI 很容易复制旧代码中的不良模式。一个早期的小问题，会随着模块增加被反复传播。

CANSE 将每次修改看成一个有边界的变更事务：

基线版本 → 变更需求 → 影响分析 → 增量实现 → 回归验证 → 审查合并 → 新基线

这里的关键不是流程审批，而是三个工程事实：

第一，版本必须可回退。 Git 提交、数据库迁移、配置变更和部署版本要能够相互对应。

第二，修改必须可评估。 如果 Codex 修改了一个公用计费函数，它必须分析哪些流程、接口、数据和测试可能受到影响。

第三，历史问题应转化为长期规则。 例如某次扣费 Bug 来源于非幂等操作，修复时不应只修复一个函数，还应补充幂等性测试或约束，防止未来再次出现。

这意味着，系统每出现一次重大问题，工程体系就应该获得一项可复用的防护能力。

四、把五大控制机制变成实际开发流程

我建议将 CANSE 落地为五个阶段和五个质量门（Quality Gates）。

这里不要求每个小改动都经过五次人工审批。

例如修改一个页面上的提示文字，可以只执行相关检查。

但如果修改的是计费规则、资金流水、权限模型、数据库结构或外部 API 契约，就需要更严格的控制。

根据风险决定 AI 的自主程度

这叫做基于风险的自主权分配（Risk-based Autonomy）。

受控不等于事事请示，而是高风险决策保留控制权，低风险操作尽量自动化。

我认为，一个人使用 Codex 开发大型系统，最适合这种组织形式。你负责关键架构决策，Codex 负责绝大部分工程实施；不需要人为创建产品经理、架构师、程序员、测试员等多个互相聊天的 AI 角色。

必要时，可以额外启动独立的代码审查会话，但它是质量检查手段，不是组织架构的复制。

五、CANSE 最关键的技术体系：让系统自己证明自己

下面进一步讨论工程实现。

我建议把 CANSE 的验证体系设计成六个层次，而不是只关注单元测试覆盖率。

5.1 六层验证体系

这六个层次的目的不同，不能相互替代。

比如，单元测试覆盖率很高，也不能证明整个业务流程可用。

端到端测试通过，也不能证明架构合理、数据安全、性能达标。

最重要的是根据项目风险选择验证层次，不是给所有项目机械套用全量测试。

5.2 把架构原则写成可执行规则

以 Java 后端为例，假设你批准了以下模块依赖关系：

Controller → Application Service → Domain → Repository Interface

那么可以利用 ArchUnit 等架构测试工具，检查是否出现 Controller 直接访问持久化实现、领域层反向依赖 Web 框架等违规行为。

Go 项目也可以通过包依赖检查、自定义静态分析以及接口测试落实类似约束。

对于 API 网关，更应该建立类似下面的业务不变量：

这里有个很重要的观念：

架构文档告诉 AI 什么是正确的，架构检查阻止 AI 持续偏离正确的方向。

如果只写文档，不做自动检查，项目规模扩大以后架构仍然可能漂移。

5.3 从“看到界面”升级为“看到业务执行证据”

针对你现在的软件不知道怎么使用的问题，我建议以后每个核心业务流程都提供一份可执行操作说明。

它应该至少包含：

最好进一步要求 Codex 使用 Playwright 等工具，在隔离环境中自动启动系统、完成操作并保存测试结果。

对于无法完成自动化的环节，必须明确标记人工验证步骤。

这样一个大型系统即使暂时只有部分业务能力，也不会是一个完全陌生的黑箱。

同时，你还能根据操作脚本判断 Codex 的设计是否符合实际业务习惯。

六、实例：利用 CANSE 开发 AIX Gateway

下面用你的 AI API 网关与商业计费平台作为完整示例。

假设目标是构建一套支持多模型接入、客户管理、使用量计费、套餐、账单和渠道结算的系统。

6.1 首先做架构拆解，而不是直接做功能菜单

对于这类产品，架构上可以明确区分数据平面（Data Plane）和控制平面（Control Plane）。

这是一种可行的候选架构，不是说 AIX Gateway 已经采用了这些实现。

Go 适合作为高并发网关数据平面的候选语言，但是否必须采用 Go，仍然要根据目标吞吐量、长连接数量、延迟、团队维护能力和实际压测结果判断。

商业运营控制平面可以使用 Java 或 Go，不必为了技术统一而把网关请求路径和复杂财务逻辑强行放到同一执行链中。

控制面的账号、套餐、定价等配置可以通过明确的契约向数据平面提供能力。高频请求路径不应无必要地同步依赖复杂账单查询。

6.2 明确第一条业务闭环

首个交付目标可以这样定义：

BC-001：客户完成一次真实模型调用，并产生准确、可追溯的计费记录。

这条业务闭环不要求先完成所有后台菜单，但必须能够贯通：

创建测试账户 → 生成 API Key → 配置模型 → 发起调用 → 获取 Usage → 按生效价格计费 → 更新账务 → 查询详单

需要特别留意模型计量存在多维度数据：

prompt_tokens、completion_tokens、缓存输入、推理 Token，以及图片、音频、视频等不同计量单位。

这些维度在不同 Provider 的语义可能不同，某些字段是其他字段的子集，而非额外用量。

因此，系统不能简单将所有 Token 字段相加。

需要先建立供应商计量适配契约，明确 Usage 原始数据、标准化结果、计价依据和缺失数据时的处理策略。

对于流式请求、重试及上游中断，还需要区分预授权额度、实际确认使用量、最终结算和可能发生的释放或冲正操作。

6.3 定义可以实际运行的验收用例

当这项功能完成时，Codex 不能简单回复“已完成计费模块”。

它应该提供相应的代码提交、测试命令及结果、测试场景、使用的定价策略版本、示例调用请求及实际运行记录。

对于高并发系统，还要验证重复事件、事务隔离、重试和故障恢复行为。不能因为单次调用正确，就认为并发计费正确。

这就是 CANSE 与普通 Vibe Coding 的关键区别：交付的是可证明的业务能力，而不只是已经生成的程序。

七、如何在 Codex 中真正落地 CANSE

不建议一开始开发所谓的“CANSE 管理平台”。

对于你现在使用 Codex 开发项目的场景，只需要 Git、Markdown 文档、项目现有构建工具、自动化测试与 CI，便足以建立基础体系。

7.1 推荐的项目目录

project/      ├── AGENTS.md      │      ├── docs/      │   ├── REQUIREMENTS.md      │   ├── ARCHITECTURE.md      │   ├── DATA_MODEL.md      │   ├── ACCEPTANCE.md      │   ├── RUNBOOK.md      │   │      │   ├── adr/      │   │   └── ADR-001-gateway-design.md      │   │      │   └── milestones/      │       └── M001-core-business-flow.md      │      ├── src/      │   └── ...      │      ├── tests/      │   └── ...      │      └── scripts/          └── ...      

核心不是文档数量，而是每份文档拥有明确职责。

REQUIREMENTS.md 是需求和业务规则基线；ARCHITECTURE.md 描述模块边界与关键约束；DATA_MODEL.md 明确核心实体与数据关系；ACCEPTANCE.md 定义验收规则；RUNBOOK.md 告诉使用者如何安装、启动、操作和排查问题。

ADR（Architecture Decision Record）用于记录重要架构决策及其理由，例如为什么将高并发网关与商业计费服务分离。

Milestone 文档记录一个阶段需要交付的业务闭环、任务进度和验证结果。

7.2 AGENTS.md 应该写什么？

不要将几百页的需求和设计文档全部复制到 AGENTS.md。

它应该是项目工作的简短入口和基本规则，而不是一个庞大的提示词集合。

例如：

# Project Engineering Rules    ## Project Goal      按 docs/REQUIREMENTS.md 中批准的业务目标开发系统。## Context      - 涉及领域边界时查阅 docs/ARCHITECTURE.md      - 修改数据库时查阅 docs/DATA_MODEL.md      - 实现业务功能时查阅对应验收用例      - 部署与操作变更参考 docs/RUNBOOK.md ## Architecture Invariants      - 禁止绕过认证与权限控制      - 禁止非授权模块直接修改财务流水      - 跨模块依赖必须遵循批准的接口契约      - 金额计算必须使用精确金额类型 ## Development      - 每次任务应明确需求编号和修改范围      - 以最小可验收业务闭环组织实现      - 不无故重写无关模块      - 运行与变更范围相符的测试      - 重要架构调整应先提交设计决策 ## Delivery      - 说明修改文件、实现结果和测试证据      - 提供可复现的操作步骤      - 未运行的检查必须标注为未验证      - 不得自行执行破坏性生产操作    

这类规则也应定期删减和更新。OpenAI 2026 年 9 月的 Codex 实践建议强调，让 Agent 按任务读取必要的文档，避免重复、过长和相互冲突的指令。

7.3 不要把所有开发方法都写成 Skill

Skill 应用于需要反复执行、具有固定输入输出的特定流程。

例如，可以逐步沉淀数据库迁移审查、架构一致性检查、业务闭环验收、回归测试报告等流程为可复用 Skill。

但是一开始没有必要创建十几个 Skill。

更合理的做法是先把真实项目跑通，再将重复出现且容易出错的流程固化为 Skill，并用测试任务验证其效果。

Codex 现在既支持规划模式，也可以利用仓库内的规则辅助代码审查。规划模式可通过 /plan 启动，用于复杂任务实施前先确认方案；不过代码审查仍是辅助机制，不能取代自动化测试和必要的人工批准。

7.4 一个可复制的 Codex 受控开发指令

以后每次要开发一个核心功能，我建议采用统一的任务描述结构，而不是直接让 Codex 自由发挥。

CANSE 业务闭环开发任务

这套指令适合较复杂的功能任务。填写具体需求编号、目标和验收范围后使用；小修复无需机械套用全部阶段。

八、对你当前几个已经开发的大项目，如何进行治理？

这一部分比重新建立开发规范更加紧迫。

你已经花费大量精力让 Codex 完成了代码，现在软件已经存在，却不清楚结构和业务完成度。

我建议采用 Brownfield CANSE，即面向已有代码项目的受控改造。

第一阶段：冻结功能，建立事实基线

先保存 Git 基线，对数据库进行必要备份，并让 Codex 在不修改业务实现的前提下分析整个项目。

特别强调三个事实来源的区别：

绝对不要让 Codex 根据现有代码重新编造一份需求文档，再用它证明自己实现正确。

那会形成自我证明的逻辑循环。

第二阶段：给现有功能重新分类

对每一个核心功能，至少区分以下五种状态。

这会让你立即发现一个重要区别：

软件的“界面完成率”可能很高，但“业务验收完成率”可能并不高。

这不是否定 Codex 已经完成的工作，而是重新建立可靠的项目进度口径。

第三阶段：选择核心业务闭环进行补救

根据业务价值、风险程度以及依赖关系，优先验证最核心的业务链路。

如果流程无法运行，先排查缺失的配置、测试数据、入口和操作步骤。

如果流程可以运行，但业务结果错误，优先修正业务规则。

如果业务正确，但代码结构严重越界，再有计划地重构。

不要在业务结果尚不清楚的情况下，为了“代码更优雅”就让 Codex 大范围重写。

第四阶段：建立项目的验收仪表盘

我建议只关注少数真正有效的指标。

不要将代码行数、Git Commit 数、页面数量甚至单纯的测试用例数量作为主要成果指标。

这些指标很容易增长，但并不能证明商业价值和工程质量。

九、CANSE 应该如何控制开发成本？

这里需要特别强调一个原则：

受控工程不是把所有项目都变成重型软件工程。

对一个几百行代码的桌面小工具，要求完整的领域模型、ADR、契约测试和多层审批，是没有必要的。

对百万级用户的运营支撑系统，或者涉及资金、身份权限、计费的企业软件，没有这些机制则风险很大。

因此，CANSE 应该采用分级治理。

这符合你一直强调的最简单可行、最少工时的工程思想。

对于 CANSE，我建议遵守一个额外原则：

任何工程控制措施，都应该能够减少实际风险，或降低后续重复劳动。否则就应该考虑简化。

例如，在一个项目里写 50 页架构说明，不如为三个关键模块增加真实有效的依赖测试。

让 Codex 提交十份漂亮报告，不如交付一份能够一键初始化并重现业务流程的测试脚本。

复杂系统需要的是控制能力，不是文档数量。

十、如何分阶段建立这套工程能力？

我建议不要追求一步到位，而是逐步建立以下四个成熟度等级。

从你目前的状况来看，最应该优先达到的是 L2：可验证开发。

因为 L2 能够直接解决你提出的两大问题：不知道软件怎么用，以及不知道内部设计和业务结果是否正确。

随后再进入 L3，通过架构规则、CI 和自动化回归降低后续维护成本。

至于 L4，不必急于实现。它依赖项目本身已经具有高质量的测试、运行环境、明确的权限控制和可靠的验证反馈。

十一、CANSE 的边界：它不能解决什么？

任何工程方法都不能保证 AI 永远不犯错。

尤其需要明确以下几个限制。

需求本身可能有问题。 如果业务规则存在根本矛盾，编码和测试都无法自动决定什么才是正确的商业选择。

自动化测试并不等于业务正确。 一套与错误实现共同生成的测试，可能系统性地遗漏真实需求。因此核心验收条件应该独立于实现确定。

架构规则不代表系统不会出故障。 网络中断、数据库竞争、第三方接口行为变化和生产负载仍需要通过压测、故障处理、监控和恢复机制应对。

AI 不应天然具有生产系统完全控制权。 特别是资金、客户数据、生产部署、权限配置和不可逆操作，必须按照风险配置授权和审批。

所以，CANSE 追求的并不是消灭全部风险，而是让风险能够被识别、定位、验证、控制和恢复。

十二、我的最终观点：软件工程的控制点正在发生迁移

在传统软件工程里，工程师主要通过亲自设计和编写代码来掌握系统。

在 AI Native 时代，如果仍然试图通过阅读每一行代码来维持控制权，最终会被 AI 产生代码的速度超过。

但完全放手让 AI 自行开发，也会让软件逐渐变成无法理解的黑箱。

所以，真正有效的路线是：

我认为，可以用三个标准判断你是否真正掌握了一套 AI 开发的软件：

第一，你能独立操作它。 不需要反复询问 Codex，就能根据操作手册完成主要业务流程。

第二，你能解释它的关键设计。 不需要记住每个函数，但能够明确核心数据对象、模块边界、业务状态和重要接口关系。

第三，你能证明它符合需求。 不依赖 Codex 的自我评价，而是依据已确认的业务标准、可复现的测试及运行证据作出判断。

做到这三点，即使软件的 100% 代码都由 AI 编写，你仍然掌握着这套系统。

对于你接下来开发的 KDBOSS、AIX Gateway 等复杂业务系统，我认为 CANSE 值得成为统一的软件工程方法论：不是让 Codex 少写代码，而是让 Codex 的每一次开发都形成可理解、可验证、可复用的工程资产。

从长远来看，最有价值的产出不仅是某一套软件，还包括一套能够让你持续、稳定地利用 AI 生产复杂软件的工程体系。