尧图网站建设 
Plate 的评审模式挖掘Review Pattern Mining把一条 PR 评审意见变成全 diff 范围的修复【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate本篇基于 Plate 仓库中的 review-sweep 技能文档系统讲解评审模式挖掘这一 AI Agent 协作方法论如何从单条 PR 评审意见中提取普适规则并在当前 diff 内识别同类模式、批量修复同时用明确的适用性分级与爆炸半径约束防止过度扩散。读完本文你将掌握这套方法的完整规则集、正负目标清单、八步工作流以及它与 Plate 仓库中 resolve-pr-feedback 技能 的衔接关系和一个真实落地的应用案例。一、背景Plate 的 Agent 技能体系与 review-sweep 的定位Plate 是一个面向富文本编辑器生态的 TypeScript monorepo核心编辑器框架 数十个插件包见 packages/ 目录与 README。仓库在.agents/目录下维护了一套给 AI AgentClaude Code、Codex 等使用的技能与规则体系review-sweep 就是其中之一。从源码结构看这套体系有一个明确的单一事实源约束。.agents/AGENTS.md 第一行规定.agents/AGENTS.mdand.agents/rules/*.mdcare source of truth. After editing them, runpnpm installto sync. Never editSKILL.mddirectly.也就是说真正可编辑的源头是 .agents/rules/review-sweep.mdc而本文主角 .agents/skills/review-sweep/SKILL.md 是由 skiller 工具 从.mdc同步生成的。SKILL.md 的 frontmatter 也印证了这一点--- description: Mine review comments for broader diff-wide fixes instead of handling each line in isolation name: review-sweep metadata: skiller: source: .agents/rules/review-sweep.mdc ---.agents/skiller.toml 中default_agents [claude-code, codex]、[skills] enabled true表明该技能会在这些 Agent 环境中被激活。文档开头的适用场景说明也点明了触发时机Use this when handling PR review feedback and you want to reduce repeated follow-up review on the same branch.目标Goal一句话概括把每条评审意见当作推断一条更宽规则的机会再把该规则应用到当前 diff 中所有明确匹配的位置。二、核心哲学提取规则而不是照搬这一行的改法文档的 Core Rules 共 7 条是整套方法论的行为约束完整继承如下提取底层规则而不是字面上的那一行修改Extract the underlying rule, not just the literal line edit。当规则是客观的、低歧义的就在当前 diff 的所有地方修复同一模式Fix the same pattern everywhere in the current diff when the rule is objective and low-ambiguity。不要cargo-cult教条式搬运评审者的建议到不相关的代码上。如果反馈属于架构性或个人品味范畴只做一次决策二选一在有意义的接缝seam上做一次刻意的重构或准备一份带理由的简短反驳pushback草案。优先做一次连贯的后续重构而不是许多零碎的复制粘贴式修补。让爆炸半径blast radius与你的置信度成比例——置信度越高扩散范围可以越大。如果一次建议的扫描依赖于另一个 PR 或上游的待合并变更必须显式指出而不是靠猜。这 7 条规则构成一个完整的扩散决策框架规则 1–2 定义何时扩规则 3 定义何时不扩规则 4–5 处理扩不动/该不该扩的主观性反馈规则 6 是强度约束规则 7 处理跨 PR 依赖。值得注意的设计取舍是第 4 条面对品味型taste-heavy反馈不允许逐处讨价还价而是强制收敛为一次全局决策避免同一条主观意见在 diff 里被反复拉扯。三、扫描目标清单什么值得扫什么不该扫文档把扫描目标分成Good Sweep Targets和Bad Sweep Targets两组白/黑名单这是该方法论最具可操作性的部分两组清单完整继承如下。3.1 好的扫描目标Good Sweep Targets安全规则类Safety rules——规则客观、错误可验证输入校验input validation索引或 key 的防御性守卫index or key guards危险属性的过滤dangerous property filteringnull/undefined 处理null or undefined handling重复出现的文档问题Repeated docs issues解释不完整incomplete explanationsAPI 文档与概念文档之间的漂移drift between API docs and concept docs缺少权衡tradeoff或使用指导usage guidance重复的代码形态问题Repeated code-shape issues冗余的类型断言redundant casts别扭的条件分支awkward conditionals重复的 helper 模式repeated helper patterns同一接缝上重复的注释、或缺失的注释duplicated comments or missing comments at the same seam重复的测试问题Repeated test issues脆弱的测试夹具brittle setup过度具体的选择器over-specific selectors相似测试中本应同样存在、却被评审恢复的断言restored assertions that should exist in similar tests这四类有一个共同特征判定标准是客观的——一个索引守卫该不该加、一条断言该不该补可以由代码事实本身回答不依赖评审者的个人偏好。这正是核心规则 2 中objective and low-ambiguity的具体化。3.2 坏的扫描目标Bad Sweep Targets没有明显可读性收益的命名偏好naming preferences without a strong readability win没有仓库证据支撑的大范围架构变更broad architecture changes without repo evidence只能弱泛化的主观风格选择subjective style choices that only weakly generalize仅为满足局部便利而扩大公开 API 的变更changes that widen public API just to satisfy local convenience任何你无法用一句话解释清楚的改动anything you cannot explain in one sentence最后一条是整份文档中最锋利的自检条款如果一次diff 范围修复说不清自己为什么成立它就属于坏目标应放弃而非执行。四、八步工作流从一条评审意见到一份可审计的交接文档的 Workflow 部分给出了严格编号的八步流程完整继承如下读取评审意见并分类归入五类之一safety安全docs clarity文档清晰度code-shape cleanup代码形态清理test robustness测试健壮性architecture or taste架构或品味用一句话写下你推断出的规则。在当前 diff 的其余部分搜索同一模式。把发现分为三档clear applies明确适用maybe applies可能适用does not apply不适用只自动应用 clear 档。对 maybe 档做出一个显式的、带理由的决策而非逐处临场发挥。直接验证被修改的接缝Verify the changed seam directly。在交接handoff中把两类工作分开陈述你实际处理的那条原始评审意见你从该意见推断出的、diff 范围内的额外修复。步骤 4 的三档分级是整套流程的安全阀它把能自动做的和需要人判断的显式切开与核心规则 6 的爆炸半径与置信度成比例呼应。步骤 7 要求直接验证而非泛泛回归即对修改点本身跑聚焦的测试或类型检查而不是等待 CI 全量反馈。步骤 8 则把模式挖掘的成果变成可审计的交付物——评审者能在 handoff 里看到一条意见如何变成了 N 处修复。Output Rule证明你没有只做字面回答文档最后的输出规则Output Rule规定When summarizing the work, make it obvious that you did not just answer the comment literally. Say what broader rule you inferred and where else in the diff you applied it.即总结工作时必须明确说明推断出的更宽规则是什么、它在 diff 的哪些其他位置被应用。这条规则把模式挖掘从隐性行为变成可检验的产出标准——如果一份 PR 处理记录里只能看到按评审意见改了那一行那么 review-sweep 并没有真正发生。五、上下游衔接review-sweep 在 resolve-pr-feedback 流水线中的位置review-sweep 不孤立存在。Plate 的 resolve-pr-feedback 技能 定义了完整的 PR 反馈处理流水线拉取反馈 → 分类 → 逐条修复 → 验证 → autoreview 收口 → 回复 → 解决线程 → 复核其中第 5 步 Fix 明确规定usereview-sweepwhen one comment implies a clear diff-wide rule;同时它要求keep fixes scoped to the reviewed diff and its direct owners、do not implement speculative architecture changes from review comments。可以看到两个技能形成清晰分工resolve-pr-feedback 管流程与边界review-sweep 管一条意见如何正确地放大。review-sweep 的不扩到无关代码核心规则 3与 resolve-pr-feedback 的不实现投机性架构变更是同一防扩散原则在两个层级的表述。六、真实案例PR #5120 中的一次 review-sweep 落地仓库中的 PR 5120 反馈台账 记录了这套方法的一次真实执行可以作为工作流的完整印证。该 PR 有 3 条评审线程其中一条指出 math 包会把来自旧版 HTML 导入的原始primitive公式值在规范化时抹掉。按 review-sweep 的处理方式修复没有停在被点名的那一处台账中的 Decisions 一节写道Preserve string/number/boolean equation values as text; nullish and unsupported values remain empty. Sweep package render/input helpers and copied editable/static/DOCX views without widening public exports.这正是核心规则 2在 diff 内修复同一模式与 Bad Sweep Targets 第四条不扩大公开 API同时生效的结果从一条意见推断出可恢复的原始值不应在规范化中丢失这一规则然后把同一规则扫过包内渲染/输入辅助函数与复制出去的 editable/static/DOCX 视图但明确不新增任何公开导出。步骤 7直接验证被修改的接缝在该案例中对应一组聚焦测试证据均记录在台账 Verification evidence 一节bun test packages/math/src/lib56 通过0 失败bun test packages/math/src/react/hooks/useEquationInput.spec.tsx5 通过bun test apps/www/src/registry/ui/equation-node-static.spec.tsx16 通过外加pnpm turbo typecheck --filter./packages/math与完整 www typecheck。而步骤 8 的交接分开陈述则体现为台账的 Findings 与 GitHub receipts 部分3 条可操作线程的逐条裁决2 fixed、1 replied/already fixed、每处回复对应精确的 discussion 链接、以及3 条线程全部 resolve、refetch 后 0 条未解决的最终核对。七、小结review-sweep 的本质是一个受控放大机制用一句话可陈述的规则作为放大条件用clear / maybe / does not apply三档作为闸门用爆炸半径与置信度成比例作为强度约束最终通过handoff 中显式区分原始意见与推断修复形成可审计闭环。它的适用前提也很明确——对象是当前 diff规则必须客观、低歧义且能用一句话解释超出这些边界的东西品味、架构、公开 API要么收敛为一次显式决策要么被直接排除在扫描目标之外。这套方法不仅适用于 AI Agent 处理评审人类开发者在回应 code review 时同样可以直接套用其目标清单与三档分级。技能正文由 skiller 同步生成.agents/skills/review-sweep/SKILL.md可编辑的事实源.agents/rules/review-sweep.mdc技能同步与 Agent 配置.agents/skiller.toml、.agents/AGENTS.md上游流水线技能.agents/skills/resolve-pr-feedback/SKILL.md应用案例台账docs/plans/2026-09-06-pr-5120-feedback.md【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Plate 的评审模式挖掘（Review Pattern Mining）：把一条 PR 评审意见变成全 diff 范围的修复
Plate 的评审模式挖掘Review Pattern Mining把一条 PR 评审意见变成全 diff 范围的修复【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate本篇基于 Plate 仓库中的 review-sweep 技能文档系统讲解评审模式挖掘这一 AI Agent 协作方法论如何从单条 PR 评审意见中提取普适规则并在当前 diff 内识别同类模式、批量修复同时用明确的适用性分级与爆炸半径约束防止过度扩散。读完本文你将掌握这套方法的完整规则集、正负目标清单、八步工作流以及它与 Plate 仓库中 resolve-pr-feedback 技能 的衔接关系和一个真实落地的应用案例。一、背景Plate 的 Agent 技能体系与 review-sweep 的定位Plate 是一个面向富文本编辑器生态的 TypeScript monorepo核心编辑器框架 数十个插件包见 packages/ 目录与 README。仓库在.agents/目录下维护了一套给 AI AgentClaude Code、Codex 等使用的技能与规则体系review-sweep 就是其中之一。从源码结构看这套体系有一个明确的单一事实源约束。.agents/AGENTS.md 第一行规定.agents/AGENTS.mdand.agents/rules/*.mdcare source of truth. After editing them, runpnpm installto sync. Never editSKILL.mddirectly.也就是说真正可编辑的源头是 .agents/rules/review-sweep.mdc而本文主角 .agents/skills/review-sweep/SKILL.md 是由 skiller 工具 从.mdc同步生成的。SKILL.md 的 frontmatter 也印证了这一点--- description: Mine review comments for broader diff-wide fixes instead of handling each line in isolation name: review-sweep metadata: skiller: source: .agents/rules/review-sweep.mdc ---.agents/skiller.toml 中default_agents [claude-code, codex]、[skills] enabled true表明该技能会在这些 Agent 环境中被激活。文档开头的适用场景说明也点明了触发时机Use this when handling PR review feedback and you want to reduce repeated follow-up review on the same branch.目标Goal一句话概括把每条评审意见当作推断一条更宽规则的机会再把该规则应用到当前 diff 中所有明确匹配的位置。二、核心哲学提取规则而不是照搬这一行的改法文档的 Core Rules 共 7 条是整套方法论的行为约束完整继承如下提取底层规则而不是字面上的那一行修改Extract the underlying rule, not just the literal line edit。当规则是客观的、低歧义的就在当前 diff 的所有地方修复同一模式Fix the same pattern everywhere in the current diff when the rule is objective and low-ambiguity。不要cargo-cult教条式搬运评审者的建议到不相关的代码上。如果反馈属于架构性或个人品味范畴只做一次决策二选一在有意义的接缝seam上做一次刻意的重构或准备一份带理由的简短反驳pushback草案。优先做一次连贯的后续重构而不是许多零碎的复制粘贴式修补。让爆炸半径blast radius与你的置信度成比例——置信度越高扩散范围可以越大。如果一次建议的扫描依赖于另一个 PR 或上游的待合并变更必须显式指出而不是靠猜。这 7 条规则构成一个完整的扩散决策框架规则 1–2 定义何时扩规则 3 定义何时不扩规则 4–5 处理扩不动/该不该扩的主观性反馈规则 6 是强度约束规则 7 处理跨 PR 依赖。值得注意的设计取舍是第 4 条面对品味型taste-heavy反馈不允许逐处讨价还价而是强制收敛为一次全局决策避免同一条主观意见在 diff 里被反复拉扯。三、扫描目标清单什么值得扫什么不该扫文档把扫描目标分成Good Sweep Targets和Bad Sweep Targets两组白/黑名单这是该方法论最具可操作性的部分两组清单完整继承如下。3.1 好的扫描目标Good Sweep Targets安全规则类Safety rules——规则客观、错误可验证输入校验input validation索引或 key 的防御性守卫index or key guards危险属性的过滤dangerous property filteringnull/undefined 处理null or undefined handling重复出现的文档问题Repeated docs issues解释不完整incomplete explanationsAPI 文档与概念文档之间的漂移drift between API docs and concept docs缺少权衡tradeoff或使用指导usage guidance重复的代码形态问题Repeated code-shape issues冗余的类型断言redundant casts别扭的条件分支awkward conditionals重复的 helper 模式repeated helper patterns同一接缝上重复的注释、或缺失的注释duplicated comments or missing comments at the same seam重复的测试问题Repeated test issues脆弱的测试夹具brittle setup过度具体的选择器over-specific selectors相似测试中本应同样存在、却被评审恢复的断言restored assertions that should exist in similar tests这四类有一个共同特征判定标准是客观的——一个索引守卫该不该加、一条断言该不该补可以由代码事实本身回答不依赖评审者的个人偏好。这正是核心规则 2 中objective and low-ambiguity的具体化。3.2 坏的扫描目标Bad Sweep Targets没有明显可读性收益的命名偏好naming preferences without a strong readability win没有仓库证据支撑的大范围架构变更broad architecture changes without repo evidence只能弱泛化的主观风格选择subjective style choices that only weakly generalize仅为满足局部便利而扩大公开 API 的变更changes that widen public API just to satisfy local convenience任何你无法用一句话解释清楚的改动anything you cannot explain in one sentence最后一条是整份文档中最锋利的自检条款如果一次diff 范围修复说不清自己为什么成立它就属于坏目标应放弃而非执行。四、八步工作流从一条评审意见到一份可审计的交接文档的 Workflow 部分给出了严格编号的八步流程完整继承如下读取评审意见并分类归入五类之一safety安全docs clarity文档清晰度code-shape cleanup代码形态清理test robustness测试健壮性architecture or taste架构或品味用一句话写下你推断出的规则。在当前 diff 的其余部分搜索同一模式。把发现分为三档clear applies明确适用maybe applies可能适用does not apply不适用只自动应用 clear 档。对 maybe 档做出一个显式的、带理由的决策而非逐处临场发挥。直接验证被修改的接缝Verify the changed seam directly。在交接handoff中把两类工作分开陈述你实际处理的那条原始评审意见你从该意见推断出的、diff 范围内的额外修复。步骤 4 的三档分级是整套流程的安全阀它把能自动做的和需要人判断的显式切开与核心规则 6 的爆炸半径与置信度成比例呼应。步骤 7 要求直接验证而非泛泛回归即对修改点本身跑聚焦的测试或类型检查而不是等待 CI 全量反馈。步骤 8 则把模式挖掘的成果变成可审计的交付物——评审者能在 handoff 里看到一条意见如何变成了 N 处修复。Output Rule证明你没有只做字面回答文档最后的输出规则Output Rule规定When summarizing the work, make it obvious that you did not just answer the comment literally. Say what broader rule you inferred and where else in the diff you applied it.即总结工作时必须明确说明推断出的更宽规则是什么、它在 diff 的哪些其他位置被应用。这条规则把模式挖掘从隐性行为变成可检验的产出标准——如果一份 PR 处理记录里只能看到按评审意见改了那一行那么 review-sweep 并没有真正发生。五、上下游衔接review-sweep 在 resolve-pr-feedback 流水线中的位置review-sweep 不孤立存在。Plate 的 resolve-pr-feedback 技能 定义了完整的 PR 反馈处理流水线拉取反馈 → 分类 → 逐条修复 → 验证 → autoreview 收口 → 回复 → 解决线程 → 复核其中第 5 步 Fix 明确规定usereview-sweepwhen one comment implies a clear diff-wide rule;同时它要求keep fixes scoped to the reviewed diff and its direct owners、do not implement speculative architecture changes from review comments。可以看到两个技能形成清晰分工resolve-pr-feedback 管流程与边界review-sweep 管一条意见如何正确地放大。review-sweep 的不扩到无关代码核心规则 3与 resolve-pr-feedback 的不实现投机性架构变更是同一防扩散原则在两个层级的表述。六、真实案例PR #5120 中的一次 review-sweep 落地仓库中的 PR 5120 反馈台账 记录了这套方法的一次真实执行可以作为工作流的完整印证。该 PR 有 3 条评审线程其中一条指出 math 包会把来自旧版 HTML 导入的原始primitive公式值在规范化时抹掉。按 review-sweep 的处理方式修复没有停在被点名的那一处台账中的 Decisions 一节写道Preserve string/number/boolean equation values as text; nullish and unsupported values remain empty. Sweep package render/input helpers and copied editable/static/DOCX views without widening public exports.这正是核心规则 2在 diff 内修复同一模式与 Bad Sweep Targets 第四条不扩大公开 API同时生效的结果从一条意见推断出可恢复的原始值不应在规范化中丢失这一规则然后把同一规则扫过包内渲染/输入辅助函数与复制出去的 editable/static/DOCX 视图但明确不新增任何公开导出。步骤 7直接验证被修改的接缝在该案例中对应一组聚焦测试证据均记录在台账 Verification evidence 一节bun test packages/math/src/lib56 通过0 失败bun test packages/math/src/react/hooks/useEquationInput.spec.tsx5 通过bun test apps/www/src/registry/ui/equation-node-static.spec.tsx16 通过外加pnpm turbo typecheck --filter./packages/math与完整 www typecheck。而步骤 8 的交接分开陈述则体现为台账的 Findings 与 GitHub receipts 部分3 条可操作线程的逐条裁决2 fixed、1 replied/already fixed、每处回复对应精确的 discussion 链接、以及3 条线程全部 resolve、refetch 后 0 条未解决的最终核对。七、小结review-sweep 的本质是一个受控放大机制用一句话可陈述的规则作为放大条件用clear / maybe / does not apply三档作为闸门用爆炸半径与置信度成比例作为强度约束最终通过handoff 中显式区分原始意见与推断修复形成可审计闭环。它的适用前提也很明确——对象是当前 diff规则必须客观、低歧义且能用一句话解释超出这些边界的东西品味、架构、公开 API要么收敛为一次显式决策要么被直接排除在扫描目标之外。这套方法不仅适用于 AI Agent 处理评审人类开发者在回应 code review 时同样可以直接套用其目标清单与三档分级。技能正文由 skiller 同步生成.agents/skills/review-sweep/SKILL.md可编辑的事实源.agents/rules/review-sweep.mdc技能同步与 Agent 配置.agents/skiller.toml、.agents/AGENTS.md上游流水线技能.agents/skills/resolve-pr-feedback/SKILL.md应用案例台账docs/plans/2026-09-06-pr-5120-feedback.md【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考