Redpanda Connect 的 AI 代码评审策略共享评审政策.claude/review-policy.md的设计与实践【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect本指南围绕 Redpanda Connect 仓库中的 AI 自动代码评审体系展开核心是共享评审政策文件 .claude/review-policy.md。该文件同时被交互式/review技能.claude/skills/review/SKILL.md与 CI 评审器.github/workflows/claude-code-review.yml消费是保证人工评审与机器评审结论一致的单一事实来源。读完本文你将掌握 Redpanda Connect 评审体系的信号判定标准、误报过滤原则、评论与链接格式约定以及这些规则如何通过 Skill 编排与 GitHub Actions 沙箱化执行落到实处。一、这份政策文件是什么一份被多方共享的如何评审约定Redpanda Connect 的 AI 评审体系区分了两层职责评审什么rules一个 PR 应当依据的规则本身存放在CLAUDE.md与CONTRIBUTING.md中如何评审how to review什么样的发现算数、哪些噪声要过滤、评论怎么写、链接怎么拼——这些由 .claude/review-policy.md 统一定义。政策文件开篇即点明其定位它被两类入口共同消费——交互式/review技能供开发者在 Claude Code 中手动触发与 CI 评审器.github/workflows/claude-code-review.yml中的自动化流程因此两者永不漂移never drift。每个入口各自装配自己的工具与编排但评审规则完全一致。从源码结构看这条单一来源约束在 CI 侧被强制执行工作流在 Prepare review context 步骤中通过 GitHub Contents API 从base ref而非 PR 头拉取.claude/review-policy.md、.claude/agents/godev.md、.claude/agents/tester.md注入评审提示词从而保证一个 PR 无法改写自己被评审所依据的规则。唯一例外是CONTRIBUTING.md它从 checkoutHEAD读取因为贡献者可能在同一 PR 中合法地更新它。二、信号门槛Signal Bar只放行高价值问题政策文件的第一条核心规则是只标记 HIGH SIGNAL高信号问题。具体包括四类明确无歧义的CLAUDE.md/CONTRIBUTING.md违规——要求能够引用被违反的具体条款例如§1.2.2、§5.4.1。对于本质上主观的标准UX 打磨、文档措辞只有存在由 diff 中的具体证据支撑的、明确且实质性的缺口时才标记绝不基于风格偏好。连接器选择标准CONTRIBUTING.md §2只能作为 NOTE 提出永不阻塞合并。项目 Go 模式或测试模式违规——即违反 .claude/agents/godev.md 与 .claude/agents/tester.md 中沉淀的工程约定。Bug 与安全问题——逻辑错误、nil 解引用、竞态条件、资源泄漏、注入、硬编码密钥。提交策略违规——对应 CONTRIBUTING.md 的 §3.3变更规模与 §3.4提交约定。门槛的兜底原则是一句朴素但关键的话如果你不确定一个问题是真实存在的就不要标记它。误报会侵蚀信任、浪费评审者时间——这正是后续误报过滤清单存在的理由。三、误报过滤清单什么不该进入评论政策文件给出了一个明确的黑名单评审模型在动手前必须逐条过滤非本次 PR 引入的既有问题pre-existing issues——评审只对 diff 负责看起来不对但实为有意为之的代码intentional资深工程师不会标记的吹毛求疵pedantic nitpickslinter、类型检查器或编译器已能捕获的问题imports、类型、格式化——AI 不重复机器的工作一般质量问题除非CLAUDE.md或技能文件明确要求已被代码中的 lint ignore 注释静默处理的、CLAUDE.md里点过名的问题作者并未修改的行上的真实问题——哪怕它确实是个 bug只要不在改动范围内就不该由本次评审提出。这套清单与工作流实现一一对应在 claude-code-review.yml 的评审提示词 中明确要求过滤掉 False positives 清单中的一切内容特别是不要运行 linter 去验证本可由 lint 捕获的问题。四、评论格式约定Summary 与行内评论的规范4.1 摘要评论格式政策文件规定了唯一的摘要评论模板**Commits** 无违规时为 LGTM否则为带编号的违规列表 **Review** 简短总结 无代码评审问题时为 LGTM否则为带链接的编号问题列表从 SKILL.md 的工作流 可以看到它的执行细节若有代码评审问题先通过mcp__github__pull_request_review_writemethod:create创建 pending review再用mcp__github__add_comment_to_pending_review追加行内评论最后以COMMENT事件提交若无任何问题则跳过 pending review只发布摘要评论。4.2 链接格式GitHub Markdown 渲染要求链接遵循精确格式https://github.com/redpanda-data/connect/blob/[full-sha]/path/file.ext#L[start]-L[end]约束有三条必须使用完整 git SHA不得缩写、不得使用$(git rev-parse HEAD)这类命令替换文件名后必须使用#L行号记号行号须为L[start]-L[end]区间形式且至少包含前后各 1 行上下文。在 CI 场景中完整 SHA 由工作流通过steps.review-context.outputs.head_sha注入提示词评审模型不得自行调用 git 命令。五、从政策到执行双入口如何编排评审政策文件本身只定义规则真正的编排在技能与工作流中。理解这两层能帮助你读懂整套体系如何落地。5.1 交互式入口/review技能的四步工作流.claude/skills/review/SKILL.md 定义了四步流程收集上下文Gather context——收集相关CLAUDE.md根目录、config/以及 PR 触及目录下的、CONTRIBUTING.md并总结 PR 的修改文件与变更类别优先并行执行评审Review——启动多个专职子 agent 并行分析Go 模式与架构godev组件注册单例 vs 批量MustRegister*、ConfigSpec 构造、字段名常量、ParsedConfig提取、Resources 模式、错误包装gerund 形式 %w、context 传播方法内不得context.Background()、不得在结构体上存储 ctx、并发模式mutex、goroutine 生命周期、幂等 Close sync.Once等并负责 CONTRIBUTING.md §3.1.3Go-first禁止逐行移植其他生态实现测试tester单元测试的表驱动写法errContains、assertvsrequire、MockResources解析配置、集成测试规范integration.CheckSkip(t)、Given-When-Then 配t.Log()、testcontainers-go、assert.Eventually轮询等Bug 与安全通用 agent逻辑错误、nil 解引用、竞态、资源泄漏、SQL/命令注入、XSS、硬编码密钥性能基准Benchmarking agent仅在 PR 触及internal/impl/*/bench/或改动连接器性能关键路径时启动校验docs/benchmark-results/与docs/benchmarking.md的同步性认证与贡献指南通用 agent逐节审计整个CONTRIBUTING.md每条发现必须引用精确条款并负责将各领域问题路由defer给对应 agentCDC 连接器标准通用 agent仅当 PR 触及 CDC 连接器时运行以internal/impl/oracledb、internal/impl/mysql、internal/impl/postgresql为规范性参照依据 §5 逐条比对提交策略通用 agent依据 §3.3/§3.4 校验提交并给出了文档未明说的测量方法如 §3.3.1 的 ~10K 行估算需扣除生成文件、vendor、锁文件与非代码内容。过滤Filter——按共享政策中的信号门槛与误报清单收敛只保留 HIGH SIGNAL评论Comment——行内评论 摘要评论格式严格遵守第四节约定。5.2 CI 入口claude-code-review.yml的权限闸门与沙箱.github/workflows/claude-code-review.yml 将上述流程搬进 GitHub Actions并增加了两层防护权限闸门gate job两种触发方式——PR 作者具有 write 权限时自动评审或维护者admin/write手动打上Claude Review标签触发。无论哪种触发只要 PR 修改了.claude/或CLAUDE.md评审立即中止防提示词注入与规则篡改。评审完成后自动移除标签重复评审需重新打标。Fail-closed 工具沙箱review job评审模型运行在--permission-mode dontAsk下允许的工具被精确枚举——仅两个 MCP 评论工具、限定路径的Read仓库 checkout 预存的/tmp/pr.diff等三个输入与TodoWriteBash、文件编辑、Web、子 agent 全部禁用并硬性封禁.env*、*.pem、*.key等敏感形状文件的读取。任何工具调用被拒绝都视为硬停止fail closed不允许绕行。值得注意的设计细节评审所需的一切上下文diff、提交元数据、变更文件清单都在前置步骤预存到/tmp使评审模型完全不需要 shell 能力评审规则godev.md、tester.md、review-policy.md从 base ref 拉取并直接注入环境变量REVIEW_GUIDES避免 PR 改写自身被评审的依据。从这些实现可以推断该体系的设计者将不可信输入 最小权限 可审计上下文作为 CI 评审的三大支柱。六、政策落地的实例CDC 连接器评审的确定性闸门政策文件强调引用具体条款如 §5.4.1——这条要求在 CDC 连接器评审中体现得最为具体。CONTRIBUTING.md 的 §5 CDC 连接器标准 定义了命名system_cdc/system_changefeed、消息形状扁平顶层元数据 原始行作为消息体禁止before/after/source/op嵌套信封、规范配置字段名stream_snapshot、checkpoint_cache、snapshot_max_batch_size、max_parallel_snapshot_tables等与核心要求持久化 checkpoint、at-least-once、ConnectionTest、追踪、十进制以sqlutil.CanonicaliseDecimal规范化等。评审模型被要求以 internal/plugins/cdctest 作为确定性闸门——该测试包通过正则_(cdc|changefeed)$在运行时从注册表自动发现整个 CDC 连接器舰队无需手工维护清单并断言规范化配置字段名。测试采取非破坏策略已收敛的连接器microso_sql_server_cdc、mysql_cdc、oracledb_cdc当前完全合规不出现在豁免列表中未收敛的连接器如aws_dynamodb_cdc、cockroachdb_changefeed则在knownNonConformant映射中逐字段注明迁移原因新连接器默认严格合规。这正是政策 → 标准 → 可执行测试 → 评审提示词逐层落地的闭环示例。七、给你的实践要点规则与评审分离评审规则CLAUDE.md/CONTRIBUTING.md与评审方法review-policy.md解耦前者管评什么后者管怎么评二者都面向多方消费者共享避免重复维护信号优先、宁缺毋滥只标记能引用具体条款的违规、模式违规与真实 bug不确定就不报显式过滤噪声把误报类型写成清单既有问题、有意为之、lint 可捕获、未修改行等让模型有据可依而非靠感觉格式即契约摘要评论与链接格式有精确模板含完整 SHA、行号区间、前后 1 行上下文保证人机输出一致CI 侧防御纵深权限闸门、base-ref 规则来源、fail-closed 沙箱、预存只读上下文共同防止评审体系被 PR 内容劫持。对希望在自己项目中落地 AI 代码评审的团队而言Redpanda Connect 这套单一来源政策 双入口编排 沙箱化执行 确定性测试闸门的组合是一份结构完整、可参照的实现范本。【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Redpanda Connect 的 AI 代码评审策略共享评审政策.claude/review-policy.md的设计与实践【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect本指南围绕 Redpanda Connect 仓库中的 AI 自动代码评审体系展开核心是共享评审政策文件 .claude/review-policy.md。该文件同时被交互式/review技能.claude/skills/review/SKILL.md与 CI 评审器.github/workflows/claude-code-review.yml消费是保证人工评审与机器评审结论一致的单一事实来源。读完本文你将掌握 Redpanda Connect 评审体系的信号判定标准、误报过滤原则、评论与链接格式约定以及这些规则如何通过 Skill 编排与 GitHub Actions 沙箱化执行落到实处。一、这份政策文件是什么一份被多方共享的如何评审约定Redpanda Connect 的 AI 评审体系区分了两层职责评审什么rules一个 PR 应当依据的规则本身存放在CLAUDE.md与CONTRIBUTING.md中如何评审how to review什么样的发现算数、哪些噪声要过滤、评论怎么写、链接怎么拼——这些由 .claude/review-policy.md 统一定义。政策文件开篇即点明其定位它被两类入口共同消费——交互式/review技能供开发者在 Claude Code 中手动触发与 CI 评审器.github/workflows/claude-code-review.yml中的自动化流程因此两者永不漂移never drift。每个入口各自装配自己的工具与编排但评审规则完全一致。从源码结构看这条单一来源约束在 CI 侧被强制执行工作流在 Prepare review context 步骤中通过 GitHub Contents API 从base ref而非 PR 头拉取.claude/review-policy.md、.claude/agents/godev.md、.claude/agents/tester.md注入评审提示词从而保证一个 PR 无法改写自己被评审所依据的规则。唯一例外是CONTRIBUTING.md它从 checkoutHEAD读取因为贡献者可能在同一 PR 中合法地更新它。二、信号门槛Signal Bar只放行高价值问题政策文件的第一条核心规则是只标记 HIGH SIGNAL高信号问题。具体包括四类明确无歧义的CLAUDE.md/CONTRIBUTING.md违规——要求能够引用被违反的具体条款例如§1.2.2、§5.4.1。对于本质上主观的标准UX 打磨、文档措辞只有存在由 diff 中的具体证据支撑的、明确且实质性的缺口时才标记绝不基于风格偏好。连接器选择标准CONTRIBUTING.md §2只能作为 NOTE 提出永不阻塞合并。项目 Go 模式或测试模式违规——即违反 .claude/agents/godev.md 与 .claude/agents/tester.md 中沉淀的工程约定。Bug 与安全问题——逻辑错误、nil 解引用、竞态条件、资源泄漏、注入、硬编码密钥。提交策略违规——对应 CONTRIBUTING.md 的 §3.3变更规模与 §3.4提交约定。门槛的兜底原则是一句朴素但关键的话如果你不确定一个问题是真实存在的就不要标记它。误报会侵蚀信任、浪费评审者时间——这正是后续误报过滤清单存在的理由。三、误报过滤清单什么不该进入评论政策文件给出了一个明确的黑名单评审模型在动手前必须逐条过滤非本次 PR 引入的既有问题pre-existing issues——评审只对 diff 负责看起来不对但实为有意为之的代码intentional资深工程师不会标记的吹毛求疵pedantic nitpickslinter、类型检查器或编译器已能捕获的问题imports、类型、格式化——AI 不重复机器的工作一般质量问题除非CLAUDE.md或技能文件明确要求已被代码中的 lint ignore 注释静默处理的、CLAUDE.md里点过名的问题作者并未修改的行上的真实问题——哪怕它确实是个 bug只要不在改动范围内就不该由本次评审提出。这套清单与工作流实现一一对应在 claude-code-review.yml 的评审提示词 中明确要求过滤掉 False positives 清单中的一切内容特别是不要运行 linter 去验证本可由 lint 捕获的问题。四、评论格式约定Summary 与行内评论的规范4.1 摘要评论格式政策文件规定了唯一的摘要评论模板**Commits** 无违规时为 LGTM否则为带编号的违规列表 **Review** 简短总结 无代码评审问题时为 LGTM否则为带链接的编号问题列表从 SKILL.md 的工作流 可以看到它的执行细节若有代码评审问题先通过mcp__github__pull_request_review_writemethod:create创建 pending review再用mcp__github__add_comment_to_pending_review追加行内评论最后以COMMENT事件提交若无任何问题则跳过 pending review只发布摘要评论。4.2 链接格式GitHub Markdown 渲染要求链接遵循精确格式https://github.com/redpanda-data/connect/blob/[full-sha]/path/file.ext#L[start]-L[end]约束有三条必须使用完整 git SHA不得缩写、不得使用$(git rev-parse HEAD)这类命令替换文件名后必须使用#L行号记号行号须为L[start]-L[end]区间形式且至少包含前后各 1 行上下文。在 CI 场景中完整 SHA 由工作流通过steps.review-context.outputs.head_sha注入提示词评审模型不得自行调用 git 命令。五、从政策到执行双入口如何编排评审政策文件本身只定义规则真正的编排在技能与工作流中。理解这两层能帮助你读懂整套体系如何落地。5.1 交互式入口/review技能的四步工作流.claude/skills/review/SKILL.md 定义了四步流程收集上下文Gather context——收集相关CLAUDE.md根目录、config/以及 PR 触及目录下的、CONTRIBUTING.md并总结 PR 的修改文件与变更类别优先并行执行评审Review——启动多个专职子 agent 并行分析Go 模式与架构godev组件注册单例 vs 批量MustRegister*、ConfigSpec 构造、字段名常量、ParsedConfig提取、Resources 模式、错误包装gerund 形式 %w、context 传播方法内不得context.Background()、不得在结构体上存储 ctx、并发模式mutex、goroutine 生命周期、幂等 Close sync.Once等并负责 CONTRIBUTING.md §3.1.3Go-first禁止逐行移植其他生态实现测试tester单元测试的表驱动写法errContains、assertvsrequire、MockResources解析配置、集成测试规范integration.CheckSkip(t)、Given-When-Then 配t.Log()、testcontainers-go、assert.Eventually轮询等Bug 与安全通用 agent逻辑错误、nil 解引用、竞态、资源泄漏、SQL/命令注入、XSS、硬编码密钥性能基准Benchmarking agent仅在 PR 触及internal/impl/*/bench/或改动连接器性能关键路径时启动校验docs/benchmark-results/与docs/benchmarking.md的同步性认证与贡献指南通用 agent逐节审计整个CONTRIBUTING.md每条发现必须引用精确条款并负责将各领域问题路由defer给对应 agentCDC 连接器标准通用 agent仅当 PR 触及 CDC 连接器时运行以internal/impl/oracledb、internal/impl/mysql、internal/impl/postgresql为规范性参照依据 §5 逐条比对提交策略通用 agent依据 §3.3/§3.4 校验提交并给出了文档未明说的测量方法如 §3.3.1 的 ~10K 行估算需扣除生成文件、vendor、锁文件与非代码内容。过滤Filter——按共享政策中的信号门槛与误报清单收敛只保留 HIGH SIGNAL评论Comment——行内评论 摘要评论格式严格遵守第四节约定。5.2 CI 入口claude-code-review.yml的权限闸门与沙箱.github/workflows/claude-code-review.yml 将上述流程搬进 GitHub Actions并增加了两层防护权限闸门gate job两种触发方式——PR 作者具有 write 权限时自动评审或维护者admin/write手动打上Claude Review标签触发。无论哪种触发只要 PR 修改了.claude/或CLAUDE.md评审立即中止防提示词注入与规则篡改。评审完成后自动移除标签重复评审需重新打标。Fail-closed 工具沙箱review job评审模型运行在--permission-mode dontAsk下允许的工具被精确枚举——仅两个 MCP 评论工具、限定路径的Read仓库 checkout 预存的/tmp/pr.diff等三个输入与TodoWriteBash、文件编辑、Web、子 agent 全部禁用并硬性封禁.env*、*.pem、*.key等敏感形状文件的读取。任何工具调用被拒绝都视为硬停止fail closed不允许绕行。值得注意的设计细节评审所需的一切上下文diff、提交元数据、变更文件清单都在前置步骤预存到/tmp使评审模型完全不需要 shell 能力评审规则godev.md、tester.md、review-policy.md从 base ref 拉取并直接注入环境变量REVIEW_GUIDES避免 PR 改写自身被评审的依据。从这些实现可以推断该体系的设计者将不可信输入 最小权限 可审计上下文作为 CI 评审的三大支柱。六、政策落地的实例CDC 连接器评审的确定性闸门政策文件强调引用具体条款如 §5.4.1——这条要求在 CDC 连接器评审中体现得最为具体。CONTRIBUTING.md 的 §5 CDC 连接器标准 定义了命名system_cdc/system_changefeed、消息形状扁平顶层元数据 原始行作为消息体禁止before/after/source/op嵌套信封、规范配置字段名stream_snapshot、checkpoint_cache、snapshot_max_batch_size、max_parallel_snapshot_tables等与核心要求持久化 checkpoint、at-least-once、ConnectionTest、追踪、十进制以sqlutil.CanonicaliseDecimal规范化等。评审模型被要求以 internal/plugins/cdctest 作为确定性闸门——该测试包通过正则_(cdc|changefeed)$在运行时从注册表自动发现整个 CDC 连接器舰队无需手工维护清单并断言规范化配置字段名。测试采取非破坏策略已收敛的连接器microso_sql_server_cdc、mysql_cdc、oracledb_cdc当前完全合规不出现在豁免列表中未收敛的连接器如aws_dynamodb_cdc、cockroachdb_changefeed则在knownNonConformant映射中逐字段注明迁移原因新连接器默认严格合规。这正是政策 → 标准 → 可执行测试 → 评审提示词逐层落地的闭环示例。七、给你的实践要点规则与评审分离评审规则CLAUDE.md/CONTRIBUTING.md与评审方法review-policy.md解耦前者管评什么后者管怎么评二者都面向多方消费者共享避免重复维护信号优先、宁缺毋滥只标记能引用具体条款的违规、模式违规与真实 bug不确定就不报显式过滤噪声把误报类型写成清单既有问题、有意为之、lint 可捕获、未修改行等让模型有据可依而非靠感觉格式即契约摘要评论与链接格式有精确模板含完整 SHA、行号区间、前后 1 行上下文保证人机输出一致CI 侧防御纵深权限闸门、base-ref 规则来源、fail-closed 沙箱、预存只读上下文共同防止评审体系被 PR 内容劫持。对希望在自己项目中落地 AI 代码评审的团队而言Redpanda Connect 这套单一来源政策 双入口编排 沙箱化执行 确定性测试闸门的组合是一份结构完整、可参照的实现范本。【免费下载链接】connectFancy stream processing made operationally mundane项目地址: https://gitcode.com/GitHub_Trending/con/connect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
