ACDL研发流程附录A：术语和对象关系
ACDL研发流程系列第13篇，共15篇。
这份附录怎样使用
正文按一次研发工作的自然顺序介绍ACDL，本附录按概念查找。遇到一个缩写、编号或状态不知道属于哪里时，先在这里确认它回答什么问题，再到附录B查实际登记入口。
ACDL中的对象不是越多越好。每份文档或记录只回答一个主要问题：ISSUE保存问题去向，REQ保存为什么改变产品，设计保存系统应该怎样工作，Loop保存一轮实际工作，版本保存最终交付结果。能够在当前会话内完成的小事，不需要为了填满这张关系图制造全部对象。
ACDL和两类参与者
| 名称 | 全称或中文含义 | 在当前项目中的作用 |
|---|---|---|
| ACDL | Agent Collaborative Development Lifecycle；Agent协同研发体系 | 当前项目根据自身研发现场定制的完整研发体系，覆盖问题、需求、设计、实施、验证、反馈和版本 |
| Director | 对方向和结果负责的人 | 提出和筛选问题，参与设计，决定取舍与授权，确认Loop结论和正式版本 |
| Agent | 在明确目标与边界内工作的智能体 | 调查、设计、实施、测试、发布、记录证据或开展独立评审 |
Director不是一个传统管理岗位。一个人在不同时间可以同时承担产品、架构、开发、测试、发布和验收职责，但涉及取舍、授权和最终接受时，仍以Director身份作出决定。
Agent也不是单一代码生成器。它可以主导ACL中的实施，也可以在没有参与被评内容实施时主导ERL。Agent承担的工作越多，越需要从仓库文档和固定提交中取得上下文，不能只依赖当前聊天记录。
一项变化涉及的主要对象
1 | 真实问题、反馈，或者实际代码、测试与环境中发现的问题 |
这不是每项工作的必经清单。已经明确的产品变化可以直接登记REQ；恢复Accepted设计的缺陷可以从ISSUE或ACL开始；DFL和ERL可以单独启动；一轮Loop结束后也可以不立即形成正式版本。
问题、需求和路线图
| 对象 | 编号或名称 | 回答的问题 | 不负责什么 |
|---|---|---|---|
| ISSUE | ISSUE-六位编号 |
发现了什么问题，现在处于什么状态，由什么继续处理 | 不提前决定一定要改变产品，也不复制完整实施证据 |
| GitHub Issue | GitHub中的#数字 |
怎样接收反馈、讨论和在看板中展示进展 | 不替代本地ISSUE身份和状态 |
| REQ | REQ-六位编号 |
为什么改变产品，希望得到什么结果，何时实际交付 | 不规定接口、数据表和代码方案 |
| 路线图 | RM-三位编号 |
多个候选REQ之间怎样排序，有什么依赖和开始条件 | 不重复定义需求，也不提前承诺版本范围 |
ISSUE和REQ最容易混淆。判断方法是：如果仍在调查发生了什么，或者只是让实现重新符合已经确认的设计，使用ISSUE；如果已经确认要改变用户行为、业务规则、权限、安全、数据边界或正式支持范围，使用REQ。
REQ-000001和PRD-001也不是同一种编号。REQ追踪一次产品变化，稳定设计要求追踪系统需要长期保持的一条规则。一项REQ可以产生多条稳定设计要求，一条旧要求也可能被后续REQ修改。
当前设计、ADR和稳定设计要求
| 对象 | 文件或编号形式 | 保存什么 |
|---|---|---|
| 系统设计 | SYS-三位编号-标题.md |
产品定位、总体范围、核心进程、存储和外部边界 |
| 能力设计 | CAP-三位编号-标题.md |
一项能力的用户行为、对象、状态、流程、失败，以及对应数据、接口、事务、恢复、代码和测试入口 |
| 横切设计 | CRS-三位编号-标题.md |
多个能力共同遵守的安全、数据、接口、审计、观测、部署和恢复规则 |
| ADR | ADR-四位编号-决定名称.md |
重要决定的背景、备选方案、选择理由和代价 |
| 索引与追踪 | IDX-三位编号-标题.md |
设计地图、旧编号迁移和要求验证关系，不定义新的设计规则 |
| 稳定设计要求 | PRD-*、DOM-*、ARCH-*、SEC-* |
需要长期保持、追踪和验证的单条规则 |
设计类别按事实职责划分，不要求每个REQ新建一组文档。先找到真正负责当前事实的设计，再检查相关共同规则是否需要同步。旧PLAT / DOMAIN / MODULE只用于历史追溯。
ADR解释为什么选择某个重要方案，最终决定仍要进入受影响的系统、能力或横切设计。推翻Accepted ADR时建立新的ADR，并让旧记录进入Superseded。
稳定设计要求的前缀表达规则性质，不等同于所在文档目录：
| 前缀 | 表达的规则 |
|---|---|
PRD- |
平台级产品范围、用户承诺、核心规则和结果指标 |
DOM- |
领域行为、用户流程、对象状态和验收结果 |
ARCH- |
跨进程、数据、接口、部署、迁移和恢复约束 |
SEC- |
身份、凭据、隔离、网络、审计和数据安全约束 |
目标版本、Loop和三种Loop
目标版本为准备组织的交付分配版本号，并在版本总览中建立记录。它在设计确认、REQ准备排期时形成，但此时还没有承诺最终纳入全部候选内容。正式版本要等验收完成并创建真实Git标签后才存在。
Loop是一轮有明确准备、执行、证据和结论的工作单元，不是Agent在一个Prompt中反复思考的内部循环。
| Loop | 全称 | 主导者 | 主要结果 |
|---|---|---|---|
| ACL | Agentic Coding Loop | Agent | 把Accepted设计变成代码、测试和可以评审的实施结果 |
| DFL | Developer Feedback Loop | Director | 在真实角色、界面、数据和环境中完成任务并记录反馈 |
| ERL | Engineering Review Loop | 独立Agent | 对固定提交、差异范围或Git标签开展独立工程评审；局部发现先留在本轮记录，需要继续处理时再进入ISSUE、REQ或ACL |
三种Loop彼此独立，不是开发、测试、验收三个串行阶段。ACL可以单独结束，DFL可以检查运行已久的功能，ERL也可以单独评审一个关键模块。是否成为某个正式版本的证据，由版本验收时的实际选择决定。
启动方案、独立计划和实施记录
| 对象 | 回答的问题 | 通常放在哪里 |
|---|---|---|
| 启动方案 | 这一轮准备为什么做、从哪里开始、做什么、不做什么、怎样验证和结束 | 对应Loop主记录的开头 |
| 独立计划 | 哪些工作需要在执行前单独批准高风险、恢复或评审边界 | 确实需要单独确认时建立，不按Loop类型机械创建 |
| 实施或评审记录 | 实际做了什么，发生了哪些失败、差异、验证和剩余问题 | 对应ACL、DFL或ERL目录 |
| 当前摘要 | 当前做到哪里、什么已完成、什么阻塞、下一步是什么 | 正在执行的Loop记录 |
计划写将要发生的事，记录写已经发生的事。执行过程改变时，在记录中追加变化原因，不把原方案悄悄改成最后结果。
环境、目标版本和正式版本的区别
| 对象 | 回答的问题 |
|---|---|
| 环境记录 | 某个环境现在运行什么提交、制品和配置，怎样恢复 |
| 目标版本 | 目前准备组织哪一次候选交付 |
| 正式版本 | 哪些变化已经验收，哪个Git标签固定了结果 |
环境中已经部署不表示Loop结束，也不表示正式版本形成。正式版本形成后，也不表示它已经部署到所有环境。一个环境可以运行候选供DFL使用，也可以暂时停留在旧正式版本。
状态属于对象还是文档
同一份REQ正文同时有需求状态和Markdown文档状态，它们表达不同事实。需求状态说明这项产品变化走到了哪里，文档状态说明这份文件是否已经可以采用。Loop整体状态与它的计划、记录文档状态同样不能互相替代。
例如：
- REQ可以处于
候选，正文仍处于Draft； - REQ进入
已排期时，相关设计应当已经Accepted； - ACL整体处于
Review时，其记录也在等待Director确认； - 一份Accepted设计可以被多轮ACL长期使用；
- 正式版本和发布说明只有在Git标签真实存在后才进入
Completed。
附录B集中列出这些登记表、状态和命令。