AI Coding 之高价值软件门控系统

一、日抛软件与高价值软件的区别

核心结论：AI Coding 在日抛软件中是“加速器”，在高价值软件中则是“放大器”——既放大效率，也放大风险，因此必须引入门控。

二、为什么高价值软件需要门控

1. AI 生成代码的特殊性风险

• • 幻觉风险：AI 可能生成不存在的 API、错误的业务逻辑、虚构的依赖
• • 表面正确：代码可编译、可运行，但语义错误、边界条件遗漏
• • 风格漂移：不同 Prompt、不同模型生成的代码风格不一致
• • 架构侵蚀：AI 倾向于“最短路径”实现，绕过分层、破坏边界
• • 知识断层：AI 不了解企业私有架构规范、历史债务、业务约束

2. 高价值软件的质量特征

• • 长期演进：代码需要被反复阅读、修改、重构
• • 多人协作：需要统一的规范、可预测的架构
• • 合规与审计：需求、设计、代码需要可追溯
• • 线上稳定：缺陷代价高，需要前置拦截

3. 门控的本质价值

将 AI 的“概率性正确”约束为“确定性合规”

门控不是限制 AI 效率，而是为 AI 生成代码建立“质量护栏”，确保：

• • 每一次 AI 产出都符合企业规范
• • 每一个变更都可追溯、可回滚
• • 每一行代码都经过系统化验证

三、门控的核心原则

1. 源码是唯一事实（Source of Truth）

• • 需求文档、设计文档是意图与约束，不是事实
• • 源码是系统当前真实状态的唯一权威来源
• • 所有门控最终必须落地到对源码的验证
• • 需求/设计漂移检查以源码为基准

2. 需求和设计是意图与约束

• • 需求：定义“做什么”
• • 设计：定义“怎么做”
• • 代码：实现“做出来”
• • 门控需要验证：代码是否忠实实现了设计意图，设计是否准确响应了需求

3. 优先计算型门控，后做概率型门控

• • 计算型：规则明确、结果稳定、可硬拦截 → 优先建设
• • 概率型：依赖 LLM、结果不确定、适合辅助 → 后建设、软提示
• • 避免用概率型门控做早期硬拦截，防止误杀和体验恶化

4. 优先左移，分层拦截

开发期（IDE 内反馈）
    ↓
提交前（本地/客户端拦截）
    ↓
合并前（流水线门控）
    ↓
发布前（集成/回归验证）
    ↓
线上（监控+反哺）

• • 越左移，修复成本越低
• • 能本地发现的问题，绝不拖到流水线
• • 能自动拦截的问题，绝不依赖人工 Review

5. 公司统一规则 + 产品线扩展规则

• • 公司级：基础规范、安全红线、通用架构约束
• • 产品线级：业务语义、技术栈差异、领域规则
• • 规则分层管理，支持继承与覆盖

四、门控的流程

1. 开发期门控（IDE 内）

• • 触发时机：编码过程中、保存时
• • 门控内容：
• • 语法检查、Lint
• • 基础架构规则（分层、依赖方向）
• • AI 生成代码标记与提示
• • 反馈方式：实时波浪线、Hover 提示、Quick Fix
• • 目标：开发者在输入阶段即时修正

2. 提交前门控（Pre-commit）

• • 触发时机：git commit 时
• • 门控内容：
• • 全量 Lint、格式化
• • 单元测试（受影响模块）
• • 基础架构规则检查
• • Commit Message 规范
• • 执行方式：Git Hook / IDE 插件
• • 拦截策略：不通过则禁止提交

3. 合并前门控（Pre-merge / PR Gate）

• • 触发时机：Pull Request 创建 / 更新
• • 门控内容：
• • 编译 + 全量测试
• • 覆盖率检查
• • 架构规则深度检查
• • LLM Code Review（软提示）
• • 需求/设计/代码一致性检查
• • 执行方式：CI 流水线
• • 拦截策略：不满足门控条件禁止合并

4. 发布前门控（Pre-release）

• • 触发时机：发布分支构建
• • 门控内容：
• • 集成测试、E2E 测试
• • 性能基线对比
• • 安全扫描
• • 兼容性验证
• • 执行方式：CD 流水线
• • 拦截策略：不通过则阻断发布

5. 线上缺陷反哺

• • 触发时机：线上缺陷创建
• • 反哺内容：
• • 缺陷根因分析
• • 补充/调整门控规则
• • 扩充测试用例
• • 优化 LLM Review 提示词
• • 闭环机制：缺陷 → 规则 → 门控 → 预防同类问题

五、门控对象分层

文档型门控

文档型门控的挑战在于文档与代码同步，建议通过：

• • 结构化需求/设计文档（机器可读）
• • 自动提取代码语义与文档对比
• • LLM 辅助进行一致性分析

源码型门控

1. 语法规范 Lint

• • 代码风格（格式化）
• • 命名规范
• • 复杂度控制
• • 死代码、未使用变量
• • AI 常见错误（如错误的异常处理、空指针风险）

2. 领域架构规范（防漂移关键，参见源码即Harness文档）

• • 实体：实体类职责单一、无业务逻辑泄漏
• • 用例：用例层只编排、不实现细节
• • 接口：接口隔离、明确输入输出
• • 分层：严格分层依赖（如 Controller → Service → Repository）参考之前教程
• • 分模块：模块内高内聚、模块间低耦合
• • 分子系统：子系统边界清晰、通信方式合规

架构门控是防止 AI “抄近路”的关键手段。

3. 功能性测试

• • 单元测试：模块内部逻辑验证，AI 生成代码优先补单测
• • 集成测试：模块对外接口验证，覆盖主要调用路径
• • E2E 测试：跨模块业务流程验证，覆盖核心业务场景

4. 非功能测试

• • 性能：响应时间、吞吐量、资源占用基线
• • 兼容性：多版本、多环境适配
• • 安全性：漏洞扫描、权限校验、数据脱敏
• • 可维护性：重复率、圈复杂度、注释覆盖率

六、门控能力分型

计算型门控（硬门控）

特点：确定性、可重复、可解释、适合硬拦截

概率型门控（软门控）

特点：语义理解强、结果不确定、误报率高、适合辅助人工决策

计算型 vs 概率型对比

七、落地优先级

第一阶段：公司级 Linter 硬门控（第 1～2 月）

目标：快速拦截 AI 高频基础错误，建立门控文化

建设内容：

• • 梳理 AI 生成代码的高频错误模式（如空指针、异常处理、资源泄漏）
• • 制定低争议、确定性规则
• • 建设公司级通用 Linter 规则集
• • 产品线可扩展业务相关规则
• • 集成到 IDE 插件 + Git Hook + CI

成功标准：

• • 90% 的 AI 基础错误在提交前被拦截
• • 开发者接受度 > 80%

第二阶段：领域架构规则门控（第 3～5 月）

目标：防止 AI 破坏架构，保障长期可维护性

建设内容：

• • 定义公司级分层架构规范
• • 定义模块依赖规则（依赖方向、可见性）
• • 定义实体、用例、接口边界规则
• • 使用架构治理工具（如 ArchUnit、Dependabot 自定义规则）
• • 集成到提交前 / 合并前门控

成功标准：

• • 架构违规率下降 > 70%
• • 新代码架构合规率 > 95%

第三阶段：测试与质量基线门控（第 6～9 月）

目标：保障功能正确性与非功能质量

建设内容：

• • 单元测试覆盖率基线（如新增代码 ≥ 80%）
• • 集成测试覆盖核心接口
• • E2E 测试覆盖核心业务流程
• • 性能基线对比（禁止性能退化）
• • 安全扫描、兼容性检查

成功标准：

• • 测试覆盖率达标率 > 90%
• • 线上缺陷率下降 > 50%

第四阶段：概率型辅助门控（第 10～12 月）

目标：利用 LLM 发现复杂问题，辅助人工决策

建设内容：

• • LLM Code Review 集成到 PR 流程（软提示）
• • 需求/设计/代码一致性分析
• • 架构风险识别
• • 缺陷模式挖掘
• • 建立“人工确认 + 反馈优化”闭环

成功标准：

• • LLM Review 采纳率 > 30%
• • 发现传统门控无法识别的问题 > 20%
• • 误报率控制在可接受范围

八、总结

高价值软件的 AI Coding 门控，本质是用系统化约束对抗 AI 的概率性风险。

• • 以源码为唯一事实，以需求/设计为约束
• • 计算型门控先行，建立确定性护栏
• • 概率型门控后上，作为能力补充而非依赖
• • 分层拦截、左移优先，降低修复成本
• • 统一规则 + 业务扩展，兼顾通用性与灵活性
• • 线上反哺，形成持续优化的闭环

这套门控体系不是一次建设完成，而是分阶段、渐进式演进，最终形成“AI 高效生成 + 门控严格把关”的高价值软件开发模式。