ACDL研发流程04：需求怎样走完整个ACDL
ACDL研发流程系列第4篇，共15篇。
多项工作同时发生时，需要共同的事实入口
当需求、实现缺陷、环境问题和评审发现同时存在，或者多个Agent并行工作时，Director面对的已经不是“怎样让Agent写完一个功能”这一个问题。此时，任何参与者都需要知道当前依据是什么、哪项工作正在改变什么，以及结果最终进入了哪里。
每个任务单独看都可能很小，组合起来却容易出现更大的问题：一项修改使用了过期设计，两个并行任务改变了同一个接口或数据规则，已经部署的代码没有经过真实使用，或者一个看似完成的版本仍然遗留阻断问题。
完整ACDL要解决的，是一项需求如何在这样的项目中保持方向、留下证据，并最终成为Director可以确认并负责的交付结果。是否需要完整流程取决于工作能否在一次短任务中可靠结束、风险大小和是否准备正式交付，不由代码行数机械决定。
本章继续使用“收藏会话”这个虚构例子。它只用于讲解流程，不是当前项目的实际开发记录。
先认识REQ(Requirement)、ISSUE和三种Loop
完整路线中会反复出现REQ、ISSUE、ACL、DFL和ERL。先说清它们各自保存什么，后面再看这些对象怎样连在一起。
REQ(Requirement)记录一项需求
REQ是Requirement的缩写，中文称为“需求”。在ACDL中，它特指一项需要持续追踪的需求，记录为什么要改变产品、希望得到什么结果，以及怎样判断需求已经满足。它不提前决定数据库、接口和代码结构。
ISSUE记录一个待处理问题
ISSUE与REQ不是同一件事。ISSUE保存一个需要跨会话处理的问题，记录问题从哪里发现、当前状态和下一步去向。它可以是实现缺陷、环境问题、尚未复核清楚的反馈，也可以是DFL或ERL中发现的问题。
如果已经可以确认要改变产品，可以直接登记REQ；如果还需要调查是实现缺陷还是新需求，先使用ISSUE保留问题。调查清楚后，恢复已经确认行为的实现缺陷可以进入ACL，需要改变产品的问题则进入REQ和设计。
ACL(Agentic Coding Loop)、DFL(Developer Feedback Loop)和ERL(Engineering Review Loop)是三种Loop
一轮Loop是一个有明确准备、执行、证据和结论的工作单元，不是指Agent在同一个Prompt里反复循环。ACDL在实施阶段使用三种Loop：
| 简称 | 全称 | 主导者 | 主要回答的问题 |
|---|---|---|---|
| ACL | Agentic Coding Loop | Agent | 是否已经把确认的设计变成代码，并通过相应的自动化验证 |
| DFL | Developer Feedback Loop | 负责人 | 负责人使用固定候选完成真实任务后，这项变化是否真的好用 |
| ERL | Engineering Review Loop | 独立Agent | 检查固定提交、差异或版本后，是否发现正确性、安全、数据、测试或发布风险 |
“主导”表示谁负责推动这轮工作的主要过程，不表示由它独自完成，也不改变Director的决定权。Agent主导ACL中的实施和验证；负责人主导DFL中的真实使用和反馈；没有参与被评内容实施的Agent主导ERL中的独立检查。三种Loop都有自己的编号、范围、起点、记录和结束条件，都要保留实际发生的事，并由负责人确认结论。
每一种Loop都可以单独启动和结束，不要求另外两种Loop在之前已经完成或之后继续开展。Loop只是ACDL组织实施、真实使用和独立评审的方式，不是ACDL的同义词。
先看完整路线
一项需求进入正式版本时，主路线可以先简化为四个阶段：
1 | 真实问题或新想法 |
这条路线只是建立全局印象，不是一条只能向前的传送带。实施发现设计无法落地时，工作要回到设计；真实使用发现用户需要不同的行为时，工作要回到需求；独立评审发现实现缺陷时，则建立新的实施工作。
还有三个边界需要先记住：
- ISSUE用于保留需要跨会话处理的问题，但不是每项需求的必经步骤。已经形成明确需求的想法，可以直接进入REQ。
- 路线图只在多个候选需求需要比较顺序和依赖时使用，不是每项工作都要先写一份路线图。
- 部署可以发生在实施中、真实使用前或正式版本完成后，因此环境发布可能出现在多个阶段，不单独算成一个主阶段。
第一阶段：需求管理，先决定为什么要改
Director发现，员工的会话越来越多，重要内容很难再次找到。此时已经可以确认需要一项新的用户行为，因此这个例子可以直接登记REQ，不为了让流程看起来完整而先制造一个ISSUE。
需求先说清四件事：
- 问题：员工难以从大量会话中快速找回重要内容；
- 期望结果：员工可以收藏自己有权访问的会话，之后能够容易地再次找到；
- 非目标：本次不同时建设共享收藏、标签分类和智能推荐；
- 验收场景：员工收藏会话后，刷新页面和重新登录仍能看到收藏状态，并能从列表中优先找到它；取消收藏后恢复普通显示。
这时不决定数据库增加什么表，也不因为某个界面容易实现就提前限定产品答案。Director先判断这个问题是否值得保留，再确认需求进入设计。如果尚无足够证据，需求继续留在候选中，不过早确定目标版本，让尚未确认的需求看起来像已经承诺交付。
第二阶段：产品与架构设计，找到负责当前答案的文档
当前项目按系统设计、能力设计和横切设计组织长期设计。它们是三类事实职责，不是每项REQ必须依次经过的三个阶段。Director和Agent先找到真正负责当前事实的文档，再检查相关的共同规则。
系统设计说明当前项目整体是什么
系统设计回答产品面向谁、整体提供什么、哪些事情不做，以及核心进程、存储和外部边界怎样组成。
“收藏会话”并不自动意味着系统设计需要修改。Director和Agent先检查这项需求是否改变产品整体范围或核心系统边界；没有改变时，就引用现有答案，不为了形式完整而重写。
能力设计把用户行为和实现边界放在一起
收藏会话主要改变Conversation能力，因此从受影响的能力设计开始。它需要回答：谁可以收藏，关系属于谁，用户从哪里操作，收藏后如何显示，无权访问或会话已删除时看到什么结果，以及数据、接口、事务、迁移和测试从哪里进入。
能力设计不按前端、后端或代码目录划分，也不是旧领域设计和模块设计的简单拼接。它围绕一项完整能力保存用户行为和长期实现约定，避免Agent在几份文档之间拼接同一个答案。
横切设计保存多个能力共同遵守的规则
员工隔离、数据所有权、接口错误和审计等规则如果由多个能力共同遵守，就从相应横切设计读取。只有这项需求确实改变共同规则时才修改；单一能力特有的决定仍留在能力设计中。
设计目录还包括ADR和IDX。ADR保存重要选择的背景、方案比较和代价，IDX保存设计地图、旧编号迁移和要求追踪；它们都不代替当前设计正文。旧PLAT / DOMAIN / MODULE只用于历史追溯，活动设计使用SYS / CAP / CRS。
设计的目的是让Agent有一份可以实施的当前答案，而不是在写代码前猜完所有细节。如果一项不确定性必须用代码证明，可以在明确范围内做可以清理的技术原型，但原型不能自动变成产品承诺。Agent可以调查代码、比较方案和指出风险，产品行为、权限、数据和长期技术边界仍然由Director确认。阻断问题解决之后，受影响的设计进入Accepted，才可以作为Agent按设计修改代码的依据。
从设计进入实施：确定目标版本
当设计已经确认，Director准备将这项需求放入一次交付时，才为REQ确定目标版本并把它置为已排期。目标版本只表示当前准备为哪个版本工作，不表示这项功能已经交付。
第三阶段：实施，按当前目的选择一种Loop
ACL、DFL和ERL不是一条固定流水线，也没有谁必须放在谁后面。Director根据当前要解决的问题单独启动其中一种：把已经确认的设计变成代码时使用ACL，了解现有产品是否好用时使用DFL，独立检查一份固定代码或版本时使用ERL。
一项新需求通常会因为需要实施而启动ACL，但这不表示随后必须开展DFL和ERL。反过来，Director也可以直接对正在使用的产品启动DFL，或者直接对现有代码和版本启动ERL，无需先有一轮ACL。某种Loop发现问题后，先把问题作为REQ或ISSUE另行处理；原Loop不因此延长，三种Loop也不因此组成一条流程。
ACL(Agentic Coding Loop)：实施已经确认的改变
ACL由Agent主导。Agent依据已经确认的需求和设计推进编码、测试、记录和问题排查；Director负责确认目标、边界以及本轮最后是否可以结束。
对“收藏会话”这项新需求，当前目的是把已经确认的设计变成代码，因此启动ACL。开始前，大目标被拆成能够独立完成和验证的任务，每项任务可以建立一轮ACL，由Agent完成实施和自动化验证。
如果收藏功能的范围不大，最简单的做法是用一轮ACL完成从界面、接口到存储和测试的端到端结果。如果范围已经大到一轮难以检查，再按可以独立验证的用户结果拆分。例如：
- 一轮让员工能够收藏和取消收藏，并在刷新和重新登录后保留状态；
- 一轮让员工在大量会话中优先看到和快速找回收藏内容。
每一轮都要跨越完成该结果所需的代码层，不把同一个结果拆成“前端Agent”、“后端Agent”和“测试Agent”共享一个模糊任务。上述两轮如果存在依赖，就按顺序开展。项目需要并行时，让其它Agent处理边界清楚的独立任务；存在文件冲突风险时，再为任务建立独立worktree。
每轮ACL在编码前先登记编号，记下工作来源、起点提交、目标、非目标、设计依据、执行范围、验证方法和停止条件。这些内容组成本轮的启动方案，用来防止Agent在实施中丢失目标。
Agent从记录清楚的基线提交和工作树开始，读取需求、已经确认的设计和本轮启动方案，再修改代码、文档和测试。它可以用很多个短循环实现和检查，但这些内部尝试仍然属于同一轮ACL。
在收藏功能中，自动化测试至少需要挑战本轮改变的风险：收藏是否可以保存和取消，刷新后是否保留，重复操作是否产生错误数据，一名员工是否无法收藏或查看他人的会话。测试要回答已经确认的行为，不是只追求数量和覆盖率。
实施记录随着工作追加内容，保存实际提交、测试命令与结论、使用的环境、失败和跳过项、方案变化、证据位置和剩余问题。不用最后的成功结果反过来改写开始时的计划，也不删除中间出现的失败。
如果实施只能通过改变已经确认的用户行为、权限、数据或架构边界继续，Agent要停下实现，说明冲突，回到受影响的设计进行评审。Agent不能为了让代码通过测试而自行重新定义产品。
代码完成、自动化测试通过或部署到开发环境，都不会自动结束本轮ACL。本轮范围、候选提交、验证证据、失败和剩余问题整理清楚之后，实施记录先进入Review。负责人确认结论后，还要把结果合入目标分支并记录实际合入提交，这轮ACL才进入Completed。
DFL(Developer Feedback Loop)：在真实使用中发现问题
DFL由Director主导。Director亲自操作和感受产品，判断它是否符合真实工作习惯；Agent可以帮助准备环境、记录过程和调查问题，但不能代替Director使用产品并给出反馈。
DFL用来了解产品在真实界面、账号、数据和操作过程中是否好用。它可以检查刚完成的变化，也可以单独检查已经运行很久的功能，不需要以某轮ACL为前提。
以收藏功能为例，Director使用真实账号和已有会话完成收藏、刷新、重新登录、取消收藏和再次寻找。这种使用可能发现，功能都能操作，但收藏内容在真实列表中仍然很难找到。DFL需要记下实际环境、操作过程、观察和感受，不以“找到的问题越多越好”为目标。
ERL(Engineering Review Loop)：独立检查固定的提交、差异或版本
ERL由没有参与被评内容实施的Agent主导。独立性来自固定评审对象、清楚范围和没有参与原实施过程，而不是来自某个模型等级。原来主导ACL的Agent可以提供背景，但不能代替这次检查。
ERL用来检查产品与设计是否一致，以及代码在正确性、权限与数据、并发与恢复、测试和发布方面是否存在风险。它可以评审刚完成的代码，也可以单独审查现有提交或版本，不需要先完成ACL或DFL。
开始ERL前，负责人和评审Agent先固定完整提交、差异范围或Git标签，并写清评审范围、问题等级和结束条件。Agent据此开展独立检查，不根据一句“帮我看看代码”无限扩展。Agent或辅助工具给出的发现还要回到代码、设计、测试和运行证据复核，未经复核的推测不能直接算作已经确认的问题。
三种Loop各自结束，发现的问题另行处理
ACL、DFL和ERL各有自己的结束条件。一轮Loop完成，只表示这一轮约定的实施、使用或评审范围已经走完，证据已经整理，发现也有了清楚去向；它不表示其它两种Loop也已经完成，更不表示三种Loop必须补齐。
任何一种Loop发现的问题都需要先复核和分类，再决定去向：
1 | 需要跨会话处理、用于恢复已经确认行为的实现缺陷 |
DFL开始前先记下实际使用的环境、制品、提交、角色和账号，ERL开始前先记下实际检查的提交、差异或标签；检查过程中都不直接修改这些内容。需要修改时，先在原记录中写下局部发现，再建立ACL处理。只有问题需要跨工作单元、跨会话、跨责任人或跨版本继续时，才登记全局ISSUE。修复完成后，DFL固定新候选并开始下一次尝试，ERL继续保留原基线上的发现。
第四阶段：版本验收与冻结，只纳入已经确认的结果
目标版本是工作目标，正式版本是已经验收的事实。两者之间不是等到日期后自动发生的状态变化。
准备版本验收时，Director核对本次实际准备纳入的REQ、ACL、DFL和ERL，而不是根据编号或早期关联关系自动把它们全部算进来。被选中的工作需要说清：
- 需求的验收场景得到了什么结论；
- 当前产品和技术设计是否已经确认；
- 实际纳入了哪些提交和Loop结果；
- 本版本实际采用了哪些自动化验证、真实使用或独立评审证据，没有开展的检查是否与本次风险所需的检查范围匹配；
- 还有哪些未解决问题，它们是被修复、排除在本版本之外，还是由Director明确接受风险；
- 发布说明是否准确表达使用者能够感知的新增、修复、限制和升级影响。
如果这些问题还没有可靠答案，版本继续保持Review。已经合并代码、部署到某个环境或者达到原定日期，都不能代替这次验收。
Director确认实际范围、验收结论、未解决问题和发布说明后，才创建指向对应提交的Git标签。标签、版本记录和发布说明相互一致之后，版本进入Completed，实际纳入的REQ才进入已完成。
完整ACDL(Agent Collaborative Development Lifecycle)不等于所有工作都走全套
这个例子从新的产品需求一直走到正式版本，因此经过了四个主阶段。真实工作必须从它的实际起点进入：
- 代码没有做到已经确认的设计，可以从ISSUE和ACL开始，不重新制造一项需求；
- 不改变产品行为的工程维护，可以建立计划版本为
未确定的ACL； - 已经稳定的小范围文档修正，可以在阅读现有依据和完成文档检查后结束；
- 真实使用或独立评审可以为了了解当前系统单独开展，不必等待一个新版本。
“完整处理一项工作”通常表示走到这项工作自己的Loop结束条件，不表示Agent可以自行开启版本验收、将REQ改为已完成或创建Git标签。形成正式版本是另一个需要Director明确决定的目标。
完整ACDL表示项目知道每项工作应该从哪里开始，谁有权决定，Agent应该依据什么执行，怎样留下验证证据，以及在什么条件下可以结束。它不是用最长的路径处理所有小事。
在这条路线中，Director始终负责从需求到正式版本的关键决定：决定值得解决的问题，确认产品和技术边界，决定什么可以实施，根据真实证据确认每轮结论，并对最终版本负责。Agent可以承担大量调查、设计、实施、验证和评审工作，但不会因此接管Director的决定和责任。
后续章节将把这条完整路线拆开。下一章先讲一项真实问题怎样进入ISSUE或REQ，以及怎样走到能够指导Agent实施的已确认设计。