ACDL研发流程06：共同完成产品与架构设计
ACDL研发流程系列第6篇，共15篇。
1.被选中的需求还不能直接交给Agent实现
REQ进入已选中，表示Director已经确认这个问题值得改变，问题、期望结果、非目标和验收场景足以开始设计。但这时通常还没有把所有关键问题说清：用户从哪里操作，对象属于谁，状态怎样变化，失败时发生什么，接口和数据怎样实现，权限和恢复边界又是什么。
如果直接让Agent编码，这些空白不会自动消失，它往往会在实现过程中自行补齐。很多返工并不是代码写错，而是代码替项目作出了还没有确认的产品或技术决定。
设计阶段的任务，是把REQ中的期望结果变成一套前后一致、可以实施和验证的当前答案。
2.先用一句话写清准备改变什么
开始修改设计前，Director和Agent先用普通中文描述变化。
以“收藏会话”为例：
员工可以收藏自己有权访问的会话，收藏属于员工个人，刷新和重新登录后仍然保留，并能帮助员工更快找到这些会话。
这不是完整设计，但已经可以用来检查：
- 当前已经确认的设计是否已经要求这个行为；
- 哪一层设计首先发生变化；
- 哪些相关设计需要同步；
- 当前代码只是没有做到设计，还是确实需要新的设计决定。
如果现有设计已经明确答案，只是代码没有实现，应该转为实现缺陷处理，不需要为了流程完整重新设计。
3.现行设计怎样分工
当前项目按五类对象组织设计。它们是事实职责，不是开发阶段：
| 类别 | 负责什么 |
|---|---|
SYS-xxx系统设计 |
产品定位、总体范围、核心进程、存储和外部边界 |
CAP-xxx能力设计 |
一项能力的用户行为、对象、状态、流程、失败，以及对应数据、接口、事务、恢复、代码和测试入口 |
CRS-xxx横切设计 |
多个能力共同遵守的安全、数据、接口、审计、观测、部署和恢复规则 |
ADR-xxxx决策记录 |
重要选择的背景、备选方案、理由、代价和替代关系 |
IDX-xxx索引与追踪 |
设计地图、编号迁移和要求验证关系，不定义新的产品或技术规则 |
旧PLAT / DOMAIN / MODULE只用于历史追溯，不再作为活动设计身份。当前入口见《设计目录》和《设计文档地图》。
4.先找负责事实的文档，不按类别走流程
以“收藏会话”为例，员工怎样收藏、关系属于谁、失去访问权后发生什么，以及对应数据、接口和测试入口，主要进入Conversation相关能力设计。员工隔离、数据所有权和接口错误等多个能力共同遵守的规则，要核对相应横切设计。只有这项能力改变产品定位、核心进程或全局边界时，才修改系统设计。
能力设计不是旧领域设计或模块设计的简单改名。它围绕一项完整能力，把用户行为与长期实现边界放在一起。这样，Agent不必从几份文档拼接同一个能力的答案，也不能让数据库或接口实现反过来偷偷定义用户规则。
一项REQ可以影响多份设计，一份设计也可以承接多个REQ。先找到真正负责该事实的位置，再检查相关共同规则；不要为每项REQ机械新建一组文件，也不要把单一能力特有的规则塞进横切设计。
5.Director和Agent怎样共同完成设计
设计不是“Director想产品，Agent补技术”，也不是“Agent出完整方案，Director只点确认”。
Director带来真实使用场景、业务优先级、风险承受和最终取舍；Agent读取REQ、当前设计、代码和数据，调查现实约束，复述自己的理解，指出缺口，并提出不同方案及其代价。
以收藏会话为例，Agent不能把“需要更快找回重要会话”直接翻译成一个星标按钮。它需要继续确认：
- 收藏是个人行为还是共享行为；
- 是否跨设备保留；
- 收藏怎样影响排序或筛选；
- 删除或失权以后是否保留关系；
- 数据量增加后查询怎样保持可用；
- 哪些失败需要用户看到。
Director根据真实工作方式回答或修正这些假设。Agent再结合现有Conversation模型、权限和分页实现提出技术方案。如果最简单的实现不能解决真实问题，就重新设计；如果产品设想会带来明显的数据或安全风险，也要在确认前把这些风险反馈回来。
共同设计的结果必须写回相应设计文档。聊天记录可以保存讨论过程，但不能代替项目当前答案。
6.设计文件和稳定要求编号不要混淆
设计文件使用：
SYS-三位编号-标题.md：系统设计；CAP-三位编号-标题.md：能力设计；CRS-三位编号-标题.md：横切设计。
这些编号标识整份文档。
文档中还会有需要跨版本长期验证的单条要求：
PRD-*：平台级产品要求；DOM-*：领域行为要求；ARCH-*：架构与跨模块技术要求；SEC-*：安全要求。
例如CAP-002是一份能力设计，DOM-021则是正文中的一条具体行为要求。两种编号不能混用。
不是每句“必须”都要分配编号。只有会长期影响用户结果、权限、安全、数据或跨模块边界，并需要持续回归的要求，才值得进入设计要求追踪。
7.ADR记录为什么这样选，不是第四层设计
设计中经常存在多个都能实现的方案。如果选择会长期限制后续方向、迁移或运维成本较高，或者要替代已有决定，就用ADR记录：
- 当时遇到什么问题；
- 比较过哪些真正不同的方案；
- 最后选择什么；
- 为什么这样选；
- 为此接受什么代价；
- 什么情况下需要重新评审。
普通错误修复、局部实现细节和容易替换的技术选择不需要ADR。
ADR只回答“为什么这样决定”。决定生效以后，当前应该怎样工作仍要写回真正受影响的系统、能力或横切设计。否则后续Agent只知道历史理由，却找不到当前实施依据。
8.设计怎样从草稿变成已确认状态
设计写出来不表示已经确认，更不表示代码已经实现。
评审时，Director和Agent把REQ、受影响的设计和必要ADR放在一起检查，重点确认：
- 用户问题和非目标有没有被设计真正覆盖；
- 系统、能力和横切设计之间有没有互相矛盾；
- 权限、安全、数据、迁移、回退和失败结果是否说清；
- 验收场景是否真的能判断结果；
- 是否还存在阻止当前方案进入实施的问题。
评审问题要区分“阻塞当前设计”和“以后可以继续优化”。阻塞问题必须解决，或者通过缩小范围明确移出本次设计。
Director明确确认后，把受影响的设计更新为Accepted并通过Git保存。只在聊天里说“可以”而文档长期停在Review，后续Agent仍然无法可靠判断它能否采用。
9.设计确认以后才决定是否排期实施
Accepted表示设计已经可以作为实施依据，不表示代码已经完成，也不表示需求已经承诺进入某个正式版本。
如果Director决定现在实施，再为REQ确定目标版本并把它改为已排期。随后才进入下一章，把设计拆成一个或多个可以独立验证的ACL。
完整关系是：
1 | 已选中的REQ |
设计分类的目标不是增加文档数量，而是让系统整体、完整能力和共同规则各自有明确位置。只要相关文档描述的是同一个系统，Agent就能够从需求进入实现，而不用在代码中重新猜产品答案。