一、核心工程定位与基本原则
1.1 人机协作边界定义
- 人类负责人：确定业务目标、关键取舍、权限边界与验收口径；澄清不能由实现者自行判断的业务歧义；承担领域审查与交付责任。
- 执行 Agent：探索代码与文档、拟定方案、切片实施、运行验证、定位失败、维护证据与交付资料；在授权边界内自主推进。
- Reviewer Agent / 独立审查者：以固定的规范和需求为依据，独立复核代码及文档，指出缺陷、证据盲区与未覆盖场景。
- 工具与流水线：通过确定性、可重复的构建、检查与测试执行工程约束。模型推断与确定性工具的执行结果分别记录，严禁互相替代。
1.2 三项工程原则
- 证据验收（Evidence over Attestation）：
- 任务完成声明必须对应明确的受测版本（Commit SHA / 内容摘要）、实际执行命令、运行环境、退出码及可访问证据；
- PR 勾选框、截图数量、Agent 自述或单纯“CI 配置已存在”，均不能作为完成证据。
- 基础设施先行（Harness First）：
- 明确的规则、可运行的环境、可信契约与验证入口是工程交付的基础；
- 缺失的门禁应明确登记负责人与补齐计划，不得以更换能力更强的模型代替工程基础设施建设。
- 按风险准备资料（Proportional Artifacts）：
- 关键上下文必须存入可追踪的任务系统或版本化文档中；
- 充分复用既有文档链接，小任务合并记录，仅为新的重要决策、安全边界或核心证据创建新材料，避免不必要的文书负担。
本文将阻止不合格变更进入下一阶段的检查称为质量门禁（下文简称“门禁”）；将需求拆成可独立验证的增量称为任务切片。判定任务完成的标准、版本发布条件和业务效果目标分别记录，避免混用。
1.3 文档权威与真实状态
每个项目应设立清晰的规范入口，明确哪些记录分别规定强制约束、业务决策、当前规格、实施顺序与运行操作。历史审计与废弃方案应保留其历史语境。
重要文档必须显式标注生命周期元数据：
核心元数据格式：
{ 状态, 适用范围, 责任人, 依据版本/日期, 关联决定, 替代关系, OPEN 项 }
- 状态定义：通用文档可采用
Draft（草案）、Accepted（已接受）、Effective（当前有效）、Superseded（已替代）、Archived（历史归档）；实现与验证状态另行独立登记。决策记录的Proposed对应草案阶段，另保留Rejected表达否决，不能与“已替代”混用； - 执行机制与落实状态声明：规范声明“由 CI 阻断”时，必须能定位到实际执行入口与流水线中的实际阻断点；人工判断项明确标注“人工复核”；未落地的能力统一标注为“计划中”。