ACDL研发流程10：通过真实使用和独立评审发现遗漏
ACDL研发流程系列第10篇，共15篇。
自动化验证通过以后还会遗漏什么
自动化测试擅长回答已经被写成判断条件的问题。例如，收藏接口能否保存状态，重复请求是否生成重复数据，员工是否只能收藏自己有权访问的会话。这些问题只要定义清楚，就可以快速、稳定地反复检查。
但产品仍然可能不好用。收藏按钮也许没有明显反馈，收藏后的会话也许仍然淹没在长列表中，真实账号也许因为历史数据触发了测试数据没有覆盖的情况。代码还可能存在另一类问题：实现者和测试使用了同一种理解，因此一起漏掉了权限、并发、恢复或发布风险。
ACDL使用两种彼此独立的Loop主动寻找这些遗漏：
| Loop | 主导者 | 主要观察对象 | 主要回答的问题 |
|---|---|---|---|
| DFL(Developer Feedback Loop) | 负责人 | 固定环境、制品、提交、角色和账号中的真实任务 | 产品在实际工作中是否真的好用 |
| ERL(Engineering Review Loop) | 独立Agent | 固定提交、差异范围或Git标签中的设计、代码、测试和发布材料 | 现有结果是否隐藏工程风险 |
DFL不是人工执行一遍自动化测试，ERL也不是让原来的Agent再解释一次自己的代码。两者都要从实施者以外的视角寻找ACL(Agentic Coding Loop)和自动化验证不容易发现的问题。
它们也不是ACL之后必须依次完成的两个阶段。Director可以单独对运行已久的功能开展DFL，独立Agent也可以单独评审某个关键能力或正式版本。是否启动、何时启动、检查多深，由当前问题和风险决定。
DFL全称中的Developer是这个Loop既有名称的一部分。在ACDL中，主导DFL的人仍然统一称为Director，Developer不是第三类参与者或一个单独岗位。
两种Loop分别登记编号和记录
DFL和ERL都单独使用编号、范围、记录和结束条件。开始前分别在docs/03-实施/DFL/README.md和docs/03-实施/ERL/README.md登记，取得DFL-六位编号或ERL-六位编号。编号在整个项目中连续使用，不随目标版本重新开始。
DFL和ERL是否另建独立计划，都取决于执行前是否需要单独批准高风险、恢复或评审边界。普通工作直接在主记录中保存启动方案、当前进展、实际操作、发现和结论，不因Loop类型机械拆成计划和记录两份文档。
对应登记表保存每轮Loop的整体状态和文档入口。单个计划或记录的文档状态，只说明这份文件是否已经确认，不能代替整轮Loop的状态。
DFL(Developer Feedback Loop)：让Director真正使用产品
DFL由Director主导。这里的“主导”不是指Director独自准备环境、收集日志和整理文档，而是由Director选择真实任务、亲自操作产品，并对观察到的体验作出判断。
Agent可以帮助确认环境状态、准备测试账号、定位入口、记录操作、提取日志和调查原因，但不能代替Director感受产品。Agent能够证明按钮响应了请求，却不能替Director判断这个按钮是否容易找到、等待过程是否让人困惑，或者整个流程是否符合实际工作习惯。
DFL关心的是一个人能不能自然地完成任务，而不是每个控件是否被点击过。以“收藏会话”为例，一次有意义的DFL可能是：
1 | 从日常使用的长列表中找到一个重要会话 |
这段过程会自然暴露按钮反馈、列表排序、等待时间、错误提示和上下文中断等问题。只写“点击收藏按钮，结果成功”看似通过了检查，却没有回答收藏功能是否真的帮助Director更快找回重要内容。
开始DFL前，先记清使用的环境、账号和版本
DFL不要求先完成某轮ACL，但开始前要说清楚这次准备了解什么。普通DFL直接在实施记录开头写启动方案，不需要另外制造一份计划文档。
启动方案至少要让后来的人看懂这些信息：
- 为什么开展这轮DFL，准备回答什么问题；
- 实际使用哪个环境，以及环境中运行的具体提交或制品；
- 使用什么账号和角色，它具有什么权限和已有数据；
- 本轮完成哪些真实任务，明确不检查什么；
- 哪些风险优先观察，遇到什么情况立即停止；
- 做到什么程度可以认为本轮使用已经完成。
“关联V0.10”只能说明这轮工作开始时的版本背景，不能证明环境里实际运行了什么。DFL需要另外记录执行基线。执行基线就是当时真正部署的提交、制品和必要配置。否则同样一条反馈可能来自不同代码，后续Agent无法复现。
账号角色同样不能省略。员工、管理员和运维人员看到的入口、数据和失败结果不同。使用一个拥有全部权限的临时账号通过，不代表普通员工可以完成相同任务。
如果DFL涉及备份恢复、全局暂停、系统或公共Skill紧急禁用等高风险操作，则先建立独立计划，固定可恢复环境、操作前状态、停止条件和恢复检查。普通体验反馈不要与这些可能改变系统状态的专项操作混在同一轮中。
用真实任务开展DFL，而不是维护永久手工清单
开始使用后，Director按自然顺序完成任务。Agent记录发生了什么，必要时同时查看页面、接口、日志和数据，但不要频繁打断使用过程，把一次真实体验切成几十项孤立的技术检查。
每项关键结果可以记为“通过”“有问题”“阻塞”“当前不可用”或“不适用”。这些词需要配上具体观察。例如：
- 通过：重新登录后收藏状态仍然保留，收藏会话出现在列表顶部；
- 有问题：点击后约两秒没有反馈，Director误以为没有生效并再次点击；
- 阻塞：普通员工打开列表时接口返回无权限，无法继续完成寻找任务；
- 当前不可用：目标环境没有部署这次变化，因此本轮不能检查；
- 不适用：本轮使用员工账号，不检查管理员批量操作。
DFL不是问题数量竞赛。没有发现问题也是有效结果，前提是记录能够说明使用了什么环境、完成了什么任务，以及观察覆盖了哪些风险。反过来，漫无边际地试遍所有历史功能并不会让结论更可靠，只会让每一轮都难以完成，也让反馈失去明确对象。
一条路径已经稳定、步骤固定并且需要反复检查时，把它转成ACL中的自动化测试或发布后的冒烟检查。DFL保留给真实工作流、体验和新风险，不承担永久人工回归清单。
DFL发现问题以后先固定发现，不在原Loop里修产品
真实使用中经常会发现看似很小的问题，例如按钮没有反馈、文字不准确，或者一个已经确认的交互状态没有实现。DFL此时先记录实际操作、观察结果和候选基线，不直接修改产品代码、测试、部署定义或正式文档。这样，原记录才能持续回答“这个固定候选在真实使用中发生了什么”。
需要修改时，先在DFL中记录一项局部发现（Finding），再建立ACL处理。问题需要跨工作单元、跨会话、跨责任人或跨版本继续调查、决定或验证时，再登记全局ISSUE；需要改变产品行为、权限、安全、数据或正式范围时，则建立REQ并回到设计。修复完成后固定新的环境、制品和提交，开始下一次尝试（Attempt）复验，不把新结果覆盖到第一次候选上。
ERL(Engineering Review Loop)：让独立Agent检查固定结果
ERL由没有参与被评内容实施的Agent主导，从评审者而非实现者的角度，独立检查一个不会在评审中继续变化的提交、差异范围或Git标签。Director确定为什么评审、评审什么以及哪些风险值得优先关注，评审Agent负责展开调查、提出候选发现并寻找证据。
一次ERL至少需要三种变化：
- 使用独立上下文重新理解问题，不继承原实现过程中的全部判断；
- 读取已经确认的设计、完整差异和验证结果，而不是只听原Agent概述；
- 主动寻找能够推翻“已经完成”的证据，而不是帮助实现者证明原方案正确。
原来主导ACL的Agent可以解释背景和提供入口，但不应代替独立评审。完全没有新视角的自检仍然有价值，却不能当作ERL。
普通Pull Request审查不自动成为ERL
ChatGPT或其它Agent可以在Pull Request中检查需求与实现是否一致、测试是否覆盖主要风险、实施记录是否与差异和验证结果相符。这类普通审查适合快速发现当前候选中的遗漏，问题也可以直接留在Pull Request中，由当前ACL修复并重新验证。
普通审查不要求另建ERL。尤其是评审Agent已经参与同一方案的形成、评审对象仍在持续变化，或者结论只服务当前Pull Request时，把它登记成ERL不会增加独立性，只会增加记录。Pull Request中的通过、批准或自动检查结果也不能代替本机、数据库、容器、浏览器或真实环境验证。
出现以下情况时，可以考虑把普通审查升级为正式ERL：
- 变化涉及权限、Secret、员工隔离、事务、并发、迁移、删除、恢复或其它高风险边界；
- 需要一个没有参与被评内容实施的Agent从新上下文重新理解问题；
- 需要固定评审基线、逐项复核发现，并把结论作为长期工程证据；
- 某个版本或重要候选需要独立于原ACL保存审查范围和结果。
使用ChatGPT开展正式独立评审时，可以新建会话，只提供Pull Request、完整HEAD提交、Accepted需求与设计、相关源码、验证证据和明确评审目标，不把原实现讨论当作结论灌入新上下文。评审期间保持被评提交不变；需要修复时另开ACL或在原ACL的新提交中处理，再决定是否对新提交开展复核。这样做是降低原方案锚定的一种推荐方法，不是所有Pull Request的强制门禁。
ERL先固定评审对象，再决定检查角度
ERL默认可以把启动范围和评审结果保存在同一份主记录中。只有评审边界需要在执行前单独批准时，才另建独立计划；无论是否拆文档，第一次正式检查开始后都保留原范围，后续变化追加原因和影响。
开始前，Director与评审Agent固定：
- 一个完整Git提交或Git标签，作为评审基线，也就是本轮实际检查且不会中途替换的对象；
- 关联版本或“未确定”，用来说明开始时的计划背景；
- 评审范围和明确不检查的范围；
- 真正受影响的风险角度；
- 使用的模型、工具和必要配置；
- 问题严重程度、复核方法、证据位置和结束条件。
评审基线回答“实际检查了什么”，关联版本回答“当时可能服务于哪个版本”，两者不能互相替代。一轮ERL后来是否成为某个版本的正式验收依据，要等版本验收时由Director选择，不因为记录里写了关联版本就自动生效。
不同改动需要不同检查角度。收藏功能可能重点检查员工之间的数据隔离、重复请求、会话删除后的残留数据、列表查询性能、迁移回退和测试遗漏；纯文档调整则重点检查事实是否准确、入口是否完整和规则是否互相矛盾。不要每次照抄一份覆盖整个仓库的万能清单。
评审Agent先提出可能存在的问题，再用证据确认
评审Agent和辅助工具可能给出大量看似合理的风险，其中一部分来自误读、重复发现或不适用于当前设计的通用建议。ERL的价值不在于生成更长的问题列表，而在于把真正成立的问题找出来。
每项候选发现都要回到已经确认的设计、代码、测试或运行事实复核：
1.指出具体对象和可以复现的条件；
2.说明它违反了哪项已经确认的行为或工程边界；
3.提供代码、测试、数据或运行证据；
4.检查是否已经存在相同根因的ISSUE或历史发现；
5.确认影响和严重程度，再决定去向。
只有“这里可能有并发问题”还不够。评审Agent需要进一步说明哪些操作可能同时发生、当前代码怎样处理、会出现什么错误结果，以及现有测试为什么没有发现它。无法取得证据的推测可以保留为未确认候选，但不能登记成已经确认的问题。
相同根因、修复方式和验证方式的发现合并处理。后续ERL再次发现同一问题时，引用原ISSUE并记录新的评审基线，不为同一个问题重复分配编号。
ERL记录问题，修复工作另开ACL
ERL评审的是固定基线。评审过程中即使已经知道怎样修复，也不能修改代码后继续使用同一个基线，并把原问题写成不存在。否则评审记录无法再回答“当时的候选结果是否安全”。
确认的实现、测试或文档问题进入ISSUE，并由独立ACL修复；需要改变产品行为、权限、安全或数据边界的问题进入REQ和设计。修复工作可以在ERL尚未结束时并行启动，但它使用自己的起点、范围、验证和实施记录。
原ERL继续保存原基线、发现证据和当时的严重程度。修复结果和回归证据写在处理它的ACL中，两边保持明确关联。需要确认修复是否消除风险时，可以对新的固定提交开展定点复核，不能改写第一次评审的记录。
DFL与ERL发现的问题怎样回到ACDL
无论问题来自真实使用还是独立评审，先判断它是让实现重新符合已经确认的设计，还是要改变产品或设计。这个判断决定工作返回实施还是重新进入需求。
1 | DFL或ERL中的候选发现 |
例如，DFL发现刷新后收藏状态丢失，而现行设计已经明确要求状态持久保存，这是实现缺陷，可以进入ISSUE和ACL。DFL发现收藏超过十个后需要文件夹，则是在增加新对象和新流程，需要登记REQ。ERL发现员工可以读取他人的收藏数据，是实现或安全缺陷；如果修复需要重新定义跨员工共享行为，则还要回到REQ和相应层级设计。
ISSUE保存问题的当前状态和后续去向，DFL或ERL记录保存它最初怎样被发现。不要把真实操作、评审证据和完整调查复制到ISSUE台账中，也不要只在原Loop里写一句“后续处理”，却没有给需要跨会话处理的问题分配ISSUE编号并登记。
一轮Loop结束不等于所有问题已经修完
DFL达到结束条件，表示约定的真实任务已经完成，结果和问题已经记录，并且未解决事项都有明确去向。ERL达到结束条件，表示计划范围已经检查，候选发现已经逐项复核，重复项已经合并，问题严重程度和后续去向也已经写清，误报与不采用项也说明了理由。
两者都不要求在结束前修复全部发现。如果把“所有问题都修完”作为结束条件，一轮评审会因为不断产生新的ACL和新需求而永远无法结束，原来的使用或评审事实也会被后续变化冲淡。
准备结束时，记录先进入Review。Director核对：
- 原来准备回答的问题是否已经得到结论；
- 实际环境、执行基线或评审基线是否清楚；
- 结果、失败、跳过和停止事项是否如实保留；
- 确认问题是否都已经写入对应的ISSUE、REQ、ACL或环境记录；
- 当前结论有没有把“尚未检查”写成“已经通过”；
- 如果这轮工作准备服务某个版本，它能证明什么，又不能证明什么。
Director确认结论后，Loop及其必要记录才能进入Completed。Completed表示这轮真实使用或独立评审已经完整结束，不表示相关版本已经形成，也不表示它自动成为某个版本的验收依据。
按风险选择DFL、ERL或两者都不开展
DFL和ERL的价值来自不同视角，不来自数量。准备交付一项明显影响日常操作的新功能时，DFL通常很有价值；涉及权限、Secret、数据迁移、并发、恢复或大范围架构变化时，ERL通常更值得投入。既改变核心工作流又涉及高风险数据边界的候选，可以分别开展两种Loop。
低风险文档修正、局部重构或已经有充分自动化证据的内部调整，可能两者都不需要。选择不开展时，不用建立空记录来证明“已经跳过”；只需要在ACL或版本验收中如实说明实际采用了哪些证据，以及为什么这些证据足以检查本次风险。
反过来，开展了DFL或ERL也不能让版本自动通过。下一章将继续说明怎样分别结束多轮Loop，再由Director选择真正纳入的需求、提交和证据，形成一个可以用Git标签固定的正式版本。