一个必须说清楚的事实：AI 会生成看起来正确、但实际有问题的代码。它不会因为不确定而停下来，它会填满每一个位置。
这不是缺陷，是概率模型的本质。因此，任何把 AI 生成结果直接上生产环境的做法，都缺少了一环。
这一环叫质量门禁。
为什么必须有门禁
| AI 的特点 | 带来的风险 |
|---|---|
| 倾向于给出完整答案 | 不确定时也会编造 |
| 上下文有限 | 看不到项目的全部历史约束 |
| 不理解业务后果 | 语法正确但逻辑错误 |
| 每次生成有随机性 | 同样的输入可能不同输出 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
语法正确 ≠ 逻辑正确 ≠ 业务正确。这三件事需要三道不同的检查。
四级门禁模型
| 级别 | 检查什么 | 谁来查 | 成本 |
|---|---|---|---|
| L1 构建门禁 | 能不能编译/构建通过 | 自动化 | 秒级 |
| L2 结构门禁 | 跨文件是否一致、命名是否规范 | 自动化 + 工具 | 分钟级 |
| L3 逻辑门禁 | 业务规则是否正确实现 | 人 + 测试用例 | 小时级 |
| L4 上线门禁 | 安全、权限、性能、数据 | 人（IT / 负责人） | 小时级 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
L1：构建门禁（自动化）
最基础也最不该省的一层：生成完立刻构建，跑不通过就不要往下走。
| 检查项 | 说明 |
|---|---|
| 语法合法性 | 能否通过解析 |
| 依赖完整性 | 引用的包/模块是否存在 |
| 类型一致性 | 类型是否匹配 |
| 构建产物 | 能否成功产出 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
初元AI 在这层使用 Tree-sitter 做语法树级校验，避免"看起来对但语法非法"的情况进入下一步。
L2：结构门禁（自动化 + 工具）
| 检查项 | 说明 |
|---|---|
| 跨文件一致性 | 改名/改接口是否全部改到 |
| 命名规范 | 是否符合团队约定 |
| 目录结构 | 是否落在正确的位置 |
| 重复代码 | 是否生成了重复实现 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
这一层是 AI 最容易出错的地方：它改了调用处，忘了改定义处；或者在不同位置生成了两份相似的数据库访问代码。
L3：逻辑门禁（人 + 测试用例）
这是自动化最难替代的一层，因为它需要知道业务应该是什么样。
| 检查项 | 例子 |
|---|---|
| 计算规则 | 折扣是否按约定口径计算 |
| 状态流转 | 订单状态能否正确流转 |
| 边界条件 | 库存为 0 时会怎样 |
| 权限判断 | 谁能看到什么数据 |
| 异常路径 | 网络失败、数据缺失时的行为 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
建议做法：为关键规则写最小测试用例，而不是逐行读代码。
| 方式 | 效率 | 可靠性 |
|---|---|---|
| 逐行读全部代码 | 低 | 中（人也会漏） |
| 关键规则写测试 | 高 | 高 |
| 只看 AI 的说明 | 高 | 低 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
不要相信 AI 对自己工作的描述。让它跑一遍，比让它说一遍可靠。
L4：上线门禁（人）
| 检查项 | 说明 |
|---|---|
| 权限 | 谁能访问、谁能改，是否最小权限 |
| 数据安全 | 敏感字段是否脱敏、传输是否加密 |
| 备份 | 能否回滚、数据是否有备份 |
| 性能 | 数据量上来后是否还能跑 |
| 监控 | 出问题能否被发现 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
这一层不该交给 AI 判断，也不该省略。它涉及责任归属：系统上线后出问题，需要有人能说清楚"当时检查了什么"。
门禁放在流程的哪里
初元AI 把门禁嵌在四阶段流程的节点上：
| 阶段 | 门禁 | 不通过怎么办 |
|---|---|---|
| 出方案后 | 方案确认 | 调整需求重出 |
| 定框架后 | 版式定版 | 换风格重来 |
| 生成后 | 构建校验 | 自动修复或提示 |
| 上线前 | 人工验收 | 回退修改 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
门禁的位置决定修复成本。在方案阶段发现需求错了，改一个选择题；在上线后发现，改一个系统。
一个诚实的边界
即使有四级门禁，以下风险仍然存在：
| 风险 | 说明 | 缓解 |
|---|---|---|
| 业务理解偏差 | 需求描述本身不准确 | 需求阶段多确认 |
| 隐性规则遗漏 | 没写下来的规则 AI 不知道 | 补充规则并重跑 |
| 集成环境问题 | 本地能跑，服务器不行 | 部署前在目标环境验证 |
| 长期维护 | 生成时的假设后来变了 | 保留文档与版本记录 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
最后一条最容易被忽略：记录当时的假设。三个月后有人问"为什么这里这样处理"，如果没人记得，维护成本会陡增。
“自动化的价值，是把人从重复劳动里解放出来去做判断，而不是把判断也一起省掉。”— 初元AI 团队
AI 生成的代码能直接上生产环境吗？+
不建议。建议至少经过四级门禁：构建校验（能否编译通过）、结构校验（跨文件是否一致）、逻辑验证（关键业务规则是否有测试用例覆盖）、上线审查（权限、数据安全、备份、性能）。前两层可以自动化，后两层需要人参与。跳过门禁的代价通常会在上线后以更高成本返还。
我们公司没有 IT，怎么把关？+
分层处理。前两层门禁（构建与结构）由工具自动完成，不需要技术背景；逻辑层可以由业务人员用"跑一遍看结果对不对"的方式验证——用真实数据试几个典型场景，比读代码更有效；上线环节（域名、服务器、备份、权限）建议请外部技术人员协助一次，形成 checklist 后可复用。关键是不能因为没人懂技术就完全不验证。
为什么 AI 会生成看起来对但实际错的代码？+
因为生成模型的目标是产出"最可能的下一段内容"，而不是"经过验证的正确内容"。它在不确定时倾向于补全而非声明不确定。这在文本创作里是优点，在代码里是风险。因此需要外部的验证机制（编译、测试、人工审查）来兜底，这也正是质量门禁存在的理由。
有没有办法减少 AI 出错的概率？+
有，且效果明显：一是在需求阶段把规则写清楚，尤其是边界条件和例外情况，AI 不知道没写下来的规则；二是用 Skill 固化团队规范，减少每次生成的自由度；三是把大任务拆小，一次只让它改一个明确的范围；四是给关键规则写测试用例。这几项的共同点是减少 AI 需要"猜"的空间。
质量门禁会不会让"15 分钟出系统"变得不成立？+
需要区分两个概念：生成时间和上线时间。生成一个可运行的系统在十几分钟内可以完成，这是真实的；但从生成到可放心使用，还需要验证与确认，这部分时间取决于业务复杂度与严谨程度，通常在数小时到数天。把这两件事分开说，才是对客户负责的表述。
本文四级门禁模型为作者团队归纳的工程实践参考，非行业标准。具体检查项需按企业业务复杂度与安全要求调整。