address-feedback

处理反馈

将一组评审反馈转化为一套有记录的决策、获批的变更，以及基于已验证结果的回复。

反馈分为两种来源：

• 可跟踪来源具有可定位的评论和回复位置：拉取请求或合并请求、问题、工单、共享文档上的评论。
• 不可跟踪来源是没有可供 Agent 写入回复的渠道的纯文本：粘贴到对话中的笔记、文件、电子邮件或聊天消息、会议记录、评审者的口头总结。

主题是反馈所针对的内容：代码、文档、设计、规范、配置。第 2 至第 4 步对两种来源都相同；第 1、5、6 步则根据来源类型有所不同。

当 AGENTS.md 指向任务跟踪器配置时，该配置会记录如何读取和更新所配置的跟踪器。若没有此配置，或配置中未说明，则直接确定来源和访问方式。

流程

1. 确定来源、主题和工作上下文

使用用户指定或提供的来源。否则，仅当当前分支或对话明确指向唯一来源时才推断；若仍有歧义，则询问用户。

对于可跟踪来源，阅读其标题、描述以及所有评论和评审讨论串，包括已解决和过时的讨论串（只要它们仍能说明意图或限制变更）。记录每条评论的标识符，以便回复。

对于不可跟踪来源，阅读完整文本并拆分为单独的反馈点。为每个点分配一个稳定的引用标识（F1、F2……），并摘录足以识别该点的最少文本；已知时记录反馈者。

然后定位主题并阅读其当前状态：相关代码和差异、文档，或反馈所指的其他产物。如果主题位于代码库中，则阅读仓库说明，并确认当前检出的分支是应接收变更的分支。如果无法定位主题，应先询问，而不是猜测评审针对的是哪个版本。

完成条件：已明确来源类型、完整的评论或反馈点、主题的当前状态，以及（对于仓库工作）接收变更的分支。

2. 逐项处理反馈

将每条实质性评论或反馈点视为一个反馈单元。只有在它们要求相同结果时才合并重复项，并保留组内的每个引用，以便逐一回复。将自动状态消息、未提出请求的批准，以及社交性致谢记录为非实质性反馈。

为每个实质性反馈单元指定一种处理方式：

• 接受：请求本身正确。
• 调整：问题成立，但通过其他变更能更好地满足要求。
• 已处理：当前主题已满足该要求；注明证据。
• 拒绝：请求与规范、项目约束或证据更充分的设计相冲突；说明权衡。
• 受阻：缺少决策或事实，无法负责任地作出处理决定。

根据各反馈单元之间的关系、来源中陈述的意图、项目惯例、测试和当前行为进行核对。发现矛盾或范围扩展时，应提请用户决定。对于事实问题，应先进行只读调查，再判定为受阻。

提供一张简洁表格，列出引用、请求、评估、处理方式，以及拟议的变更或回复。表格后附上实施和验证计划，包括可能需要修改的文件。涉及判断时，给出明确建议。

完成条件：每个实质性反馈单元恰好出现一次；每个非实质性反馈也单独记录；用户可以审阅接受该计划的全部影响。

3. 获取对变更计划的批准

请用户批准或修改处理决定和计划。此关卡仅授权进行本地更改。如果修订实质性改变了工作内容，请再次展示计划。

只有在用户批准计划后，才能修改目标。计划获批后，继续实施和验证，无需就计划已涵盖的常规选择征求意见。

完成条件：用户已为每个实质性单元批准了具体的处理决定和操作。

4. 实施并验证

仅实施获批的更改，同时保留无关工作。对于代码仓库代码的更改，请遵循 implement-changes.md，并将获批计划作为用户批准的批次。对于其他目标，按更改规模进行相称的验证。如果实施过程中发现某项获批的处理决定有误，或需要实质性扩大工作范围，请停止处理该项，说明证据，并返回计划审批关卡。

根据每项获批的处理决定检查结果。测试套件通过本身不能证明某个单元已处理；请将每个单元与已更改的目标、现有证据或明确说明的决定关联起来。

完成条件：已实施获批的更改，相关验证通过，且每个实质性单元都有经验证的结果。

5. 起草回复

每条回复开头都应说明决定及其理由。对于已实施的更改，请说明可观察到的结果，以及支持该结果的验证。对于调整或拒绝的请求，请直接说明权衡。只有第 4 步已验证更改后，才能声称更改已完成。回复应简短具体，并使用反馈所用的语言。仅当用户要求或项目惯例要求时，才使用 [AI] 前缀。

• 有跟踪记录的来源：针对每条实质性评论各起草一条回复，包括已拒绝、受阻、重复和已处理的评论；如果跟踪系统支持线程，应将回复放在原始线程中。对于无线程的问题或工单，只引用足以明确回复对象的内容。单独列出拟议的线程解决方式或状态变更：发布回复并不意味着授权解决线程、批准审查、关闭工单或更改状态。
• 无跟踪记录的来源：起草一份面向审阅者的汇总回复，通过引用其编号或简短引述，回答每个实质性要点，并使用反馈传来的媒介。若用户表示只需通过更改作答，则不必起草回复。

完成条件：每个实质性单元都有确切的回复草稿（或用户已免除对无跟踪记录来源的回复），且任何跟踪系统变更均单独列出。

6. 确认并交付

请用户批准回复以及任何单独列出的跟踪系统变更，并根据要求进行修改。仅当用户在看到实施结果后已提供要逐字发布的确切回复文本时，才跳过此确认步骤。

• 有跟踪记录的来源：通过第 1 步确定的访问方式发布获批回复；如果批量提交审查有助于保留线程位置，则优先采用此方式。仅执行单独获批的解决方式或状态变更。报告已发布评论的网址或引用。
• 无跟踪记录的来源：将获批回复交给用户，以便其直接发送；Agent 无法通过任何渠道代为发送。

报告任何有意不回复的单元，以及最终验证结果。

完成条件：每条获批回复都已发布到目标位置或交到用户手中，每个实质性单元都已得到妥善处理，且未发生未经批准的跟踪系统变更。