# 开发审计规范

创建人员：Codex  
文件职责：规定开发体系的方案审核、实现审核、测试验收、问题归因和审计闭环。  
管理规范/模板：../../全局规范.md；编码规范.md。  
引用文件：编码规范.md；开发环境创建指南.md；开发事项总纲模版.md；开发事项计划模版.md；编码方案范本.md；开发执行日志模版.md；开发审计报告模版.md；开发问题记录模版.md。  
记录方式：开发审计规范；审计流程、阻断标准或问题闭环变化时更新。

统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地开发审计规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。

## 1. 审计定位

开发审计不是替开发者写代码，也不是把所有边角料升级为阻断。

开发审计负责确认：

1. 开发目标是否和上游依据一致。
2. 重型开发是否先有编码方案，且方案合理。
3. 实现是否符合需求、计划和方案。
4. 测试和自检是否覆盖关键路径。
5. 问题是否正确归因到需求、代码、数据、流程或产物。
6. 结论是否可追踪、可复现、可复审。

## 2. 审核员权限边界

开发审核员可以：

1. 读取开发证据链上的文档、代码、日志、测试和结果。
2. 执行证据链上的脚本、测试或检查命令。
3. 写 `开发审计报告.md`。
4. 在需要跨轮跟踪时，在 `开发问题记录.md` 建立索引。

开发审核员不得：

1. 直接改业务代码。
2. 直接改测试代码。
3. 改写正式产物。
4. 替开发者修复问题后直接判自己通过。

如审核员同时拥有开发角色，应在记录中明确本次是“开发动作”还是“审计动作”。

## 3. 审计关口

### 3.1 计划审计

检查：

1. 计划是否有来源聊天记录或上游依据。
2. 计划目标是否和开发事项总纲一致。
3. 计划是否明确输入、输出、影响范围和验收方式。
4. 轻量 / 重型判断是否合理。
5. 如为重型开发，是否要求编码方案。

### 3.2 方案审计

只对重型开发必需。

检查：

1. 模块边界是否清楚。
2. 接口、输入、输出是否明确。
3. 公共能力是否该抽取。
4. 关键字段和数据结构是否统一。
5. 重跑、缓存、失败产物、性能风险是否处理到位。
6. 验收方案是否能证明目标完成。

方案审计不通过时，不应进入编码实现。

### 3.3 实现审计

检查：

1. 实现是否按计划和方案进行。
2. 是否绕过公共入口或重复散修核心逻辑。
3. 是否改了不该改的文件。
4. 是否引入不必要的复杂度。
5. 是否有主流程阻断、数据污染、未来函数、不可追踪或不可重跑问题。
6. 是否把需求问题误修成代码问题。

### 3.4 测试验收

检查：

1. 基础语法或导入是否通过。
2. 关键函数或模块测试是否通过。
3. 链路 smoke 是否覆盖主要接口。
4. 反例或边界样本是否覆盖核心风险。
5. 测试是否只锁当前错误行为，而没有证明需求正确。

## 4. 阻断标准

以下问题应阻断：

1. 需求或上游依据不清，导致代码只能靠猜。
2. 重型开发没有方案或方案未审通过就实现。
3. 实现绕过主链或公共入口，造成流程不可控。
4. 输出主表、正式产物、核心接口或关键字段错误。
5. 测试无法证明关键路径。
6. 会导致数据污染、未来函数、错误复用、不可重跑或半成品误用。
7. 审计证据链缺失，无法复核。

## 5. 不应阻断的事项

以下事项通常不应阻断，除非会影响结果或流程：

1. 命名不够优雅但语义清楚。
2. 注释风格差异。
3. 非核心诊断项缺失。
4. 可后续补充的性能优化建议。
5. 不影响当前目标的扩展性建议。

审核员应优先报告真问题，避免层层加码。

## 6. 问题归因

发现问题时必须标注主因：

1. 需求问题：上游要求不清、矛盾、缺字段、缺边界、缺验收。
2. 代码问题：需求清楚但实现不符。
3. 数据 / 产物问题：输入、输出、快照、结果包、schema、hash、行数异常。
4. 流程 / 调度问题：顺序、权限、重跑、缓存、目录、审计链路错误。
5. 测试问题：测试覆盖不足、误锁错误行为、没有反例。
6. 待归因：证据不足，需补充检查项。

需求问题必须明确告诉项目管理员或上游负责人，不得只写进代码问题里。

## 7. 审计报告口径

开发审核员发现的问题主记录写入对应审计报告入口。

默认入口：

1. 需求开发、项目工具开发、独立开发事项：`dev-doc/开发审计报告.md`。
2. 实验开发：`exp-doc/实验审计报告.md`。
3. 案例分析开发：`ana-doc/案例审计报告.md`。

非审计人员发现的问题写入 `开发问题记录.md`。

如果同一个问题需要跨多轮跟踪，可以在问题记录里建索引，但不重复审计报告全文。

## 8. 通过标准

开发事项可通过的最低标准：

1. 目标和上游依据对齐。
2. 计划已记录。
3. 重型开发的编码方案已审计通过。
4. 实现符合计划和方案。
5. 关键测试通过。
6. 执行日志记录关键节点。
7. 审计报告有明确结论。
8. 没有阻断性问题。