ACDL研发流程12：不同工作从哪里开始、在哪里结束
ACDL研发流程系列第12篇，共15篇。
每项工作不必走完同一条路
前面的章节用一项需求串起了完整ACDL，但日常工作并不都是新功能。修正一句错误说明、补一条测试、恢复已经设计好的行为、调整模块内部实现和处理环境故障，需要的约束明显不同。
如果所有工作都先建立REQ(Requirement)、重写所有设计类别、依次开展三种Loop再形成正式版本，ACDL会变成填写材料的负担。反过来，如果所有工作都以“小改动”为由直接修改，产品承诺、长期设计和现场事实又会逐渐失去可信度。
因此，选择流程时不是追求步骤最少，而是保留这项工作真正需要的决定、检查和记录：重要决定有依据，实际修改能验证，发现的问题有去向，后来的人能够理解结果。达到这些条件以后就可以结束，不需要为了形式继续增加对象。
文件数量和代码行数不能直接决定路径。一个只改一行代码的权限规则调整，如果改变了安全边界，也可能需要REQ、设计评审和正式版本；一次涉及几十个文件的机械重命名，只要没有改变行为和长期约定，可能仍然只是一次边界清楚的实施工作。
先判断实际改变了什么
收到任务以后，Director和Agent先回答四个问题。
是否要改变已经确认的产品或设计
先看用户行为、业务规则、权限、安全边界、数据含义、接口语义、部署方式或正式支持范围是否改变。只要其中一项发生变化，就不能只根据任务标题把它当成缺陷或重构。
如果已经有明确并确认的设计，而本次只是让实现重新符合设计，可以直接进入实施。现有设计没有答案，或者准备采用不同答案，就先回到需求和设计。
事实是否已经清楚
“页面有问题”“测试不稳定”“环境坏了”都只是现象。事实不清楚时，先复现、读取日志、核对当前代码和环境，必要时建立ISSUE保留调查过程。不要在原因尚未确认时直接建立一项虚假的产品需求。
是否需要跨会话继续追踪
能在当前会话中完成并验证的低风险修正，不一定需要新增编号。需要以后继续、需要多个任务协作、会进入排期，或者必须保存处理决定时，就使用ISSUE、REQ、Loop或环境记录分配唯一编号并登记。
“当前会话可以完成”不能单独作为不登记ISSUE的理由。需要跨工作单元、跨责任人或跨版本继续处理时，应当取得稳定编号；DFL和ERL中的局部发现可以先留在本轮记录中，需要修改正式产物时另建ACL，需要跨上述范围继续处理时再登记全局ISSUE。
是否准备形成正式交付
代码合入主线、Loop结束和正式版本形成是不同的结束位置。多数维护工作可以在验证完成或ACL(Agentic Coding Loop)结束后停止。只有Director准备向使用者形成一次正式交付时，才继续进行版本验收并创建Git标签。
可以把这四个问题压缩成一条判断顺序：
1 | 先确认事实 |
新功能或产品变化：从REQ和设计开始
增加新能力、改变用户行为、修改业务规则，或者改变权限、安全、数据和正式支持范围时，先建立或关联REQ。REQ说明为什么要改变、准备解决什么问题、怎样判断结果有用，不提前代替设计决定实现方法。
Director选择REQ以后，与Agent共同修改受影响的产品与架构设计。先找到负责当前事实的系统、能力或横切设计，再检查相关共同规则。需要替换既有重要决策或作出难以撤销的选择时，另外建立ADR(Architecture Decision Record)保留选择依据。
这类工作的典型路径是：
1 | 问题和证据 |
DFL(Developer Feedback Loop)和ERL(Engineering Review Loop)不是ACL后面的固定步骤。Director希望通过真实使用检验某个场景时，可以独立启动DFL；需要独立Agent从一个明确的提交、差异范围、Git标签或设计范围中寻找工程遗漏时，可以独立启动ERL。是否把它们作为版本证据，由本次交付风险和验收目标决定。
如果完成ACL以后暂时不准备发布，工作可以停在Loop结束。REQ保持已排期，直到它真正随正式版本交付，不能因为代码已经完成就提前改成已完成。
实现缺陷：先看设计有没有明确答案
实现缺陷是代码、配置或部署结果没有兑现已经确认的设计。例如设计明确要求员工只能读取自己的会话，而当前实现允许跨员工读取。这时产品承诺没有变化，不需要为了修复缺陷重新创造REQ。
处理过程先记录可复现的现象、预期结果和实际结果。问题需要跨会话处理、影响真实环境或需要保留优先级和处置决定时，建立ISSUE。随后直接依据对应的已确认设计启动ACL；计划版本尚未确定时如实填写未确定，再完成修复、定点验证和受影响范围的回归。
1 | 发现偏差 |
如果核对以后发现设计没有说明预期行为，Director和Agent面对的就不是单纯实现缺陷。此时先用ISSUE保留现象和调查，再决定是否建立REQ并补充设计。不要让Agent在修Bug的名义下替项目决定新的产品规则。
缺陷修复通常在ACL进入Completed后结束。只有这次修复需要作为正式交付发布时，才继续进入版本形成；是否紧急不改变这一点。
设计变化：先判断哪类设计负责当前事实
“修改设计”也不是一条固定路径，需要先看被修改的设计正在承诺什么。
如果变化影响产品行为、跨能力关系、权限、安全、数据含义、接口语义或正式范围，就从REQ开始，联合修改产品与架构设计。系统、能力和横切设计之间存在影响时一起评审，不能只更新最靠近代码的位置来掩盖其它长期规则已经变化。
如果产品目标不变，只调整某项能力内部的长期实现约定，可以直接修改对应能力设计，并说明修改原因、影响范围和验证方法。这类变化不必编造产品REQ，但设计仍要经过Review和Director确认，再由ACL实施。
无论发生在哪一层，只要准备推翻已经确认的ADR，或者选择会长期限制后续方案且难以撤销，都要新增ADR。旧ADR保留当时事实并标记为已被替代，不直接改写成今天的结论。
判断边界不清楚时，先按设计变化处理。多做一次设计确认的成本，通常低于Agent按照未经确认的假设修改代码以后再返工。
内部重构和测试补充：不制造虚假的产品变化
内部重构可以改变代码结构、依赖组织和实现方式，但不能借此改变用户行为、接口语义、数据边界或安全规则。开始前先指出准备改善的工程问题，例如重复逻辑、难以测试、职责混杂或构建耗时，并明确哪些行为必须保持不变。
如果重构会改变能力或横切设计中的长期约定，先更新对应设计；如果只改变局部实现，可以直接进入ACL。范围很小、能够在当前会话完成且不需要持续追踪时，也可以在完成代码审查、定点测试和必要回归后结束，不为它单独建立REQ或目标版本。
测试补充同样以现有已经确认的设计为依据。Agent先说明测试准备证明哪条行为，再增加能够失败、能够复现目标条件的测试。只有新增或调整了长期设计要求与测试之间的直接、支持关系时，才同步更新验证追踪记录。
测试暴露出实现不符合设计时，按实现缺陷处理；暴露出设计没有答案时，回到ISSUE、REQ和设计判断。不要为了让测试通过而悄悄改变产品行为，也不要把“只改测试”当成降低风险的理由。
文档变化：区分表达、事实和规则
文档修改看起来都发生在Markdown文件中，实际影响却可能完全不同。
修正表达
错别字、标点、排版、失效的内部引用和不改变含义的名称修正，可以直接修改。Agent需要完整阅读目标文件，检查相关引用，并运行文档检查和差异检查。结果通过后即可结束，不需要ISSUE、REQ或Loop。
更正事实
测试结果、发布状态、版本、环境地址、当前实现和完成情况属于事实。修改前先找到原始证据，例如真实命令结果、Git提交、Git标签、环境记录或当前代码，再更新负责保存该事实的文档。
如果更正会推翻已经由Director确认的结论，需要保留更正原因和新证据，并重新取得确认。不能只因为修改对象是文档，就把一次结论变化当成文字润色。
改变规则或设计
规范、产品承诺和已经确认的设计本身发生变化时，按项目规则变化或设计变化处理。先说明为什么改、影响哪些对象、如何验证，再经过对应评审和确认。代码尚未变化，不表示这次修改没有工程影响；文档作为代码的“源码”，会改变后续Agent应该实现的内容。
环境故障：先恢复现场，再决定长期修改
环境故障与普通代码任务的顺序不同。服务不可用、数据异常或安全风险正在扩大时，首先保存发现时间、环境、影响、当前状态和已有证据，再在授权范围内采取可逆的止损或恢复动作。现场尚未稳定时，不必先写完整产品设计。
一般环境问题可以在环境变更记录中保存操作、结果和环境当前运行的版本、配置和服务状态；需要跨会话调查、影响持续存在或要安排后续处理时，再建立ISSUE。严重生产故障仍然沿用ISSUE和环境记录，不另外建立一套Incident编号。
恢复以后要重新检查服务健康、关键路径、数据一致性、安全状态和最初受影响的任务。仅看到进程启动或接口返回成功，不能证明故障已经结束。
1 | 发现环境故障 |
长期根因如果是实现偏差，进入维护ACL；如果需要改变产品行为、权限、安全或数据规则，建立REQ并修改设计；如果只是环境参数或操作错误，在环境记录和运维入口中完成修正与验证。紧急恢复只缩短止损动作的前置过程，不是绕过长期设计和评审的理由。
环境恢复和根因修复也可以分别结束。现场已经恢复时，环境处置可以先结束；尚未完成的长期修复由ISSUE、REQ或ACL继续追踪，不必让环境记录无限保持进行中。
DFL和ERL：从准备回答的问题开始
DFL由Director主导，适合回答“真实角色实际使用时能不能完成任务”。它可以针对刚完成的功能，也可以用于检查一个已经运行很久的版本。开始时选择真实角色、任务和环境，结束时保存实际操作、观察和发现的问题。
ERL由没有参与被评内容实施的Agent主导，适合回答“固定范围中还有哪些工程遗漏”。它可以检查设计、代码、测试、部署或版本候选，不要求前面刚刚完成一轮ACL。开始前固定评审对象、提交和边界，避免检查过程中对象持续变化。
两种Loop发现的问题都先复核，再按性质进入对应路径：
- DFL和ERL先在本轮记录局部Finding，不直接修改被测或被评对象；
- 已有设计明确且需要修改正式产物的，另建ACL处理；需要跨工作单元、跨会话、跨责任人或跨版本继续时，再登记全局ISSUE；
- 设计没有答案或产品承诺需要变化的，建立REQ并回到设计；
- 只影响本轮评审方法的，更新当前DFL或ERL记录；
- 与本轮目标无关但值得以后处理的，建立ISSUE保留，不顺手扩大当前范围。
DFL和ERL在本轮问题得到回答、发现项都有去向并由相应主导者确认后结束。它们不因为发现了后续工作就必须一直保持进行中。
任务目标决定在哪里结束
下面这张表给出常见工作的默认路径。它不是机械规则；只要实际影响更大，就增加更完整的需求、设计、验证和评审。
| 工作类型 | 通常从哪里开始 | 主要保留什么 | 通常在哪里结束 |
|---|---|---|---|
| 新功能或产品行为变化 | REQ和产品与架构设计 | 问题、验收场景、已经确认的设计、实施与验证证据 | ACL结束；准备交付时继续形成正式版本 |
| 已有设计明确的实现缺陷 | 已经确认的设计，必要时建立ISSUE | 复现、偏差、修复和回归证据 | 维护ACL进入Completed |
| 产品或架构设计变化 | REQ和负责当前事实的设计 | 改变原因、相关设计、评审结论，必要时增加ADR | 设计进入Accepted；实施另由ACL继续 |
| 能力内部长期约定变化 | 能力设计 | 技术原因、影响范围、评审和验证方法 | 设计确认并完成ACL |
| 局部内部重构 | 当前代码或维护ACL | 不能改变的行为、代码审查和测试结果 | 验证通过或ACL结束 |
| 测试补充 | 已经确认的设计和现有测试 | 目标行为、测试结果，必要时更新验证追踪 | 验证通过 |
| 文字和排版修正 | 目标文档 | 差异与文档检查结果 | 文档检查通过 |
| 事实更正 | 原始证据和负责维护这项信息的文档 | 新证据、更正原因，必要时增加Director确认 | 记录与证据一致 |
| 环境故障 | 环境现场和环境记录 | 影响、操作、恢复验证和环境当前状态 | 环境恢复得到验证；长期根因另行追踪 |
| 独立开展DFL或ERL | 待回答的问题和明确的提交、Git标签或设计范围 | 使用或评审过程、发现项及其去向 | 本轮结论得到确认 |
真正足够的路径，最后应该能回答五个问题：
- 为什么要做这项工作；
- 它改变了什么，又明确不改变什么；
- Director和Agent依据什么作出决定；
- 什么证据说明结果达到了目标；
- 尚未解决的事情由谁、在哪个对象中继续处理。
五个问题已经有清楚答案，工作就可以在适当位置结束。缺少答案时，增加对应的调查、设计、Loop或确认；答案已经充分时，不再为了“走完整流程”制造多余对象。ACDL的价值不在于让每项工作看起来一样，而在于让不同工作都根据风险高低完成必要的设计、验证和评审，并得到可靠结果。