ce-resolve-pr-feedback

并行评估、修复和回复 PR 审核反馈。修复真实的内容；不要为那些不存在的东西而烦恼。

ce-resolve-pr-feedback 是传入反馈解析技能。在您的 PR 获得审核意见后，此技能会获取所有未解决的线程，将它们分类为新的和已处理的，调度并行代理来验证每个发现并修复真正正确的内容（或通过推理进行回复），提交和推送，然后通过 GitHub 的 GraphQL API 发布回复并解决线程。它根据每个项目的优点来判断——无论来源（人类或机器人）或形式（内嵌线程、正式审查机构或顶级评论）——并且默认进行修复，仅在阅读代码发出具体信号时才转移（发现是错误的，修复会造成损害，它什么也买不到，或者风险无法限制）。

复合工程构思链是/ce-ideate → /ce-brainstorm → /ce-plan → /ce-work。 ce-resolve-pr-feedback 是 PR 后反馈循环 — 在审阅者留下评论后调用，与 /ce-code-review（在 PR 开放之前进行审阅）和 /ce-debug（调查破坏行为，而不是审阅反馈）互补。

TL;DR

＃＃ 问题

大规模解决公关反馈的失败是可以预见的：

• 过度修复机器人噪音 - 自动审查机器人过度标记、标记无关紧要的事物，有时甚至是错误的； “修复一切”本能反应会通过低价值的更改来搅乱代码和 PR
• 根据权威而非事实得出的结论 - 修复是因为审阅者（或机器人）这么说，但没有确认问题确实存在于代码中
• 已经回复的项目每次运行都会重新出现 - 顶级 PR 评论和审核机构没有解决机制，因此它们会一直出现，直到手动检查
• 机器人包装噪声 - 审查机器人样板（“这里有一些自动审查建议......”）夸大了工作计数
• 顺序修复很慢 — 一次寻址 12 个线程是挂钟时间的 12 倍
• 并行修复冲突 - 编写同一文件的两个代理会默默地丢失其中一项更改
• 无组合验证 - 每个代理对其自己的更改运行有针对性的测试；跨代理回归被忽略
• 过时的评论行号 - 对已经漂移的行的反馈很难重新定位

解决方案

ce-resolve-pr-feedback runs feedback resolution as a structured pipeline:

• Fetch all unresolved feedback (review threads + PR comments + review bodies) via GraphQL
• Triage new vs already-handled — a substantive reply that defers action counts as handled; only new items are processed
• Drop bot wrapper noise silently — non-actionable boilerplate is filtered, not announced
• Fix by default; validate as a tripwire — each finding is judged on its merits regardless of source or form; the agent fixes unless reading the code trips a concrete signal (the finding's wrong, the fix would harm, it buys nothing, or the risk can't be bounded)
• Parallel agent dispatch with file-collision avoidance — agents that touch overlapping files serialize automatically
• Combined validation — one full validation run after all agents complete, catches cross-agent regressions
• Reply with quoted context — every reply quotes the relevant feedback for continuity, then states what was done
• Resolve via GraphQL — review threads get resolved; PR comments and review bodies get a top-level reply (no resolve mechanism in the API)

是什么让它如此新颖

1. 默认固定 — 仅在绊线上转移

大多数评论反馈（从 P0 到 P2，包括挑剔）都是正确的并且值得修复，因此默认是修复它。至关重要的是，验证不是一个单独的分析过程：代理必须读取代码才能进行修复，并且检查是它在读取期间注意到的绊线，而不是每个项目都必须争论通过的大门。当没有任何问题发生时，它会修复并继续前进——无需对每个项目进行深思熟虑。深度工作（读取来电者、评估爆炸半径、为用户编写决策）仅花费在少数会触发电线的项目上。

项目仅在具体信号上从修复中转移：

• the finding doesn't hold (reading the code disproves it) → not-addressing with evidence
• the fix would make the code worse → declined citing the harm
• the change buys nothing real (cosmetic or immaterial — small real improvements still get fixed; the skip bar is "no benefit," not "minor") → replied
• the change is risky and the blast radius can't be bounded (a one-line edit can hit a hot path or thinly-tested code; the reviewer, especially a bot, usually couldn't see it) → de-risk with a test and fix if possible, else needs-human
• it's a question, not a change → replied, or needs-human for a product/business call

防止过度思考的护栏是明确的：“我感到不安”不是绊网；而是“我感到不安”。 “我读了来电者的信息，这打破了X”。这对于自动审核机器人来说最为重要，因为它们会过度标记——但规则与来源无关：机器人或人类断言某件事并不能证明它是正确的。

2. 根据优点而不是来源或形式进行判断

每个项目都以相同的方式进行评估，无论谁提出它（人工审阅者或审阅机器人）或以什么形式到达（内嵌审阅线程、正式审阅机构或顶级 PR 评论）。正确性并不取决于来源或表面。结构形式仅改变响应机制（内联线程通过 GraphQL 解析；审核主体和顶级评论获得顶级回复）——从不改变结果是否正确。

3. 六个判决——每个判决都有不同的行动

needs-human 是高信号且罕见的——它包括对审阅者所说内容、代理调查内容、为什么需要做出决定以及权衡的具体选项的结构化分析。

4. 分类 — 新的与已处理的

对于每条反馈，该技能在处理之前都会进行分类：

• 查看主题 — 阅读主题；推迟采取行动的实质性答复（“需要对此进行协调”，“将仔细考虑这一点”）正在待决，请勿重新处理。只有原始评论线程才是新的。
• 公关评论 + 审查机构 - 没有解决机制，因此每次运行都会重新出现。两个过滤器：可操作性（跳过审核包装、批准、状态徽章、不询问的 CI 摘要），然后是已回复（引用并解决反馈的现有回复）。任何通过两者的东西都是新的。

来自 CodeRabbit、Codex、Gemini Code Assist、Copilot 的机器人包装器会默默地被丢弃——通过样板内容识别，从未公布或计数。这是一个内容检查（这里有什么可操作的吗？），而不是源检查，因此无论哪个机器人的格式发生变化它都有效。

5. 避免文件冲突的并行调度

对于 1-4 个项目，全部并行运行。对于 5 个以上，批量为 4 个。 在调度之前，技能会检查项目之间的文件重叠 — 重叠的项目会序列化，因此两个代理永远不会并行写入同一文件。

顺序回退：没有并行调度的平台按顺序运行代理。

6.所有代理完成后联合验证

每个解析器代理都会对其自己的更改运行有针对性的测试。所有代理返回后，该技能会聚合 files_changed 并运行项目的完整验证一次 — 捕获目标运行无法看到的跨代理交互。

7. 带引号上下文的回复格式

每个回复都会引用原始反馈的相关部分以保持连续性，然后说明已完成的操作：

• 已修复： > [quoted feedback] 后跟 Addressed: [brief description of the fix]
• 未寻址： > [quoted feedback] 后跟 Not addressing: [reason with evidence]
• 拒绝： > [quoted feedback] 后跟 Declined: [specific harm cited]

这使得审阅者在几周后阅读回复时能够保持方向——他们无需重新阅读整个线程即可看到正在解决的问题。

8.过时评论迁移

过时线路上的线程通常具有 line: null 并需要回退到 originalLine。该技能将 isOutdated 标志和所有四个位置字段（line、originalLine、startLine、originalStartLine）携带到每个代理的调度中，以便代理知道报告的线路可能已漂移并可以适当地重新定位。

9. 升级的两遍循环

如果验证步骤后仍有新线程，则该技能将从剩余线程的分类中重复。经过两个修复验证周期后，该技能停止循环，并将重复出现的模式显示为 needs-human：“[主题] 的多轮反馈表明存在更深层次的问题。”

10. 两种模式——完全模式和目标模式

目标模式适用于“仅处理这一评论”的情况 - 当用户想要单独处理一条反馈时很常见。

简单示例

审阅者（和审阅机器人）对您的 PR 留下 8 条评论。您调用 /ce-resolve-pr-feedback。

该技能从当前分支检测 PR，通过 GraphQL 获取：6 个未解决的评审线程、2 个评审主体（一个是 CodeRabbit 包装器）、0 个 PR 评论。分类：CodeRabbit 包装器是不可操作的样板文件 — 悄然丢弃。一条评论线程从昨天的推迟行动中得到了实质性答复——待定，跳过。剩下 5 个评论主题 + 1 个评论正文为新。

步骤 4 分批调度 6 个 ce-pr-comment-resolver 代理，每批 4 个。文件冲突检查：两个线程接触 app/services/dispatcher.rb → 这两个线程进行序列化；其余部分并行运行。每个代理都会阅读实际代码并根据其优点判断其发现：

• 2 个发现显然是正确的 → fixed
• 1 建议一种可行的方法，但存在更干净的方法 → fixed-differently
• 1 是一个机器人发现标记了“可能的 null deref”，类型系统已经排除了 → 已根据代码确认，不支持 → not-addressing 有证据（无流失）
• 1问“这是故意的吗？” → 由代码负责 → replied
• 审查机构提出设计问题 → replied

针对 3 个更改的文件运行一次组合验证；测试通过。提交+推送。

第7步发布回复：每个回复都引用原始反馈并说明所做的事情。所有 5 个审核线程均通过 GraphQL 解析；审核机构获得顶级 PR 评论（API 中没有解析机制）。步骤 8 验证：再次获取 — 空。完毕。摘要表面。

何时去实现它

在以下情况下使用 ce-resolve-pr-feedback：

• 您的 PR 收到了您想要解决的评论反馈
• 自动审查机器人留下了一堆发现，您希望它们根据代码进行验证，而不是盲目应用
• 您想要单独处理特定评论（带有评论 URL 的定向模式）
• 之前的运行留下了 needs-human 项目，您已决定如何继续

在以下情况下跳过 ce-resolve-pr-feedback：

• PR还没有反馈
• 你只想确认反馈而不修复 - 该技能期望采取行动，而不仅仅是确认
• 反馈是关于头脑风暴或计划文档，而不是代码 → 使用 /ce-doc-review

用作工作流程的一部分

ce-resolve-pr-feedback 是 /ce-commit-push-pr 打开 PR 后的关闭循环：

/ce-work → /ce-commit-push-pr → reviewer leaves comments → /ce-resolve-pr-feedback

它补充了：

• /ce-code-review — PR 开放之前进行评论；此技能处理之后收到的反馈
• /ce-debug — 针对损坏的行为；这个技能是为了review-comment解析

决议提交 PR 后，将适用标准合并/重新审核周期。如果下一轮审核产生更多反馈，则该技能可以在新一轮中再次运行。

使用独立版

该技能直接起作用：

• 当前分支的 PR — /ce-resolve-pr-feedback
• 具体 PR — /ce-resolve-pr-feedback 1234
• 有针对性（单线程） — /ce-resolve-pr-feedback https://github.com/.../pull/1234#discussion_r5678901

在目标模式下，仅对 URL 的特定线程进行寻址，不会获取或处理其他线程。

＃＃ 参考

scripts/ 中的脚本：get-pr-comments（GraphQL 获取）、get-thread-for-comment（映射注释 → 目标线程）、reply-to-pr-thread（GraphQL 突变）、resolve-pr-thread（GraphQL 突变）。

＃＃ 常问问题

你还在修复挑剔吗？ 是的——默认情况下。大多数反馈（包括挑剔的反馈）都是正确的并且值得修复，因此代理会进行修复，除非阅读代码发出具体信号：发现不成立，修复会使代码变得更糟，或者更改不会带来任何实际效果。改进代码（即使是轻微的）的正确 nit 得到修复；一个纯粹的装饰性的、没有任何好处的问题会得到简短的回复，而不是流失。跳过栏“没有任何好处”，而不是“次要的”。

它对待机器人反馈的方式与人类反馈的方式不同吗？ 不——这是故意的。验证是根据优点而不是权威来判断的：阅读实际代码来确认发现的结果是相同的工作，无论是机器人还是人类提出的，而权威启发式（“机器人→可能是噪音”）可能会忽略真正的机器人捕获的错误。优点绊线（发现是否成立？修复是否真的有帮助？）自然地过滤机器人噪音 - 大多数是推测性的或无关紧要的 - 无需对来源进行分类。这同样适用于表单 - 内联线程与正式审查机构与顶级评论仅改变回复的发布和解决方式，而不会改变发现是否正确。

为什么要默默地放弃机器人包装？ 因为宣布它们会增加毫无价值的噪音。 CodeRabbit 样板文件（“这里有一些自动审查建议......”）包含了真实的发现；包装器本身是不可操作的。在摘要中对丢弃的包装进行计数或列出会使报告变得混乱。脚本级过滤器仅处理 CI/状态机器人；内容感知下降（可操作性检查，而不是源检查）捕获其余部分。

如果两个并行代理发生冲突怎么办？ 调度前的文件冲突检查可以捕获大多数情况 - 重叠项目序列化。对于极少数情况下，修复会扩展到其引用的文件之外（重命名会更新其他地方的调用者），步骤 5 中的组合验证会捕获测试破坏，而步骤 8 中的验证步骤会捕获未解析的线程。如果其中任何一个出现不一致，该技能将按顺序重新运行受影响的代理。

needs-human 是什么意思？ 代理调查了反馈和代码，但无法自信地确定正确的操作 - 通常是因为选择取决于代理无法推断的用户意图。该线程保持打开状态，并有确认回复，摘要呈现结构化的 decision_context：引用的反馈、调查结果、权衡选项、代理的精益（如果有）。

如果反馈循环永远不收敛怎么办？ 经过两个修复验证周期后，该技能将停止循环，并使用累积上下文将重复模式升级为 needs-human。它不会无限期地重试。

另请参阅

• ce-code-review — 公关前审查；该技能处理公关后反馈
• ce-commit-push-pr — 打开该技能响应的 PR
• ce-debug — 对于报告为错误的损坏行为，而不是查看反馈
• ce-doc-review — 针对需求或计划文档的反馈，而不是代码