AI Agent人工智能代码智能体交互助手【免费下载链接】openchamberAgentic Development Environment based on OpenCode AI agent项目地址https://gitcode.com/gh_mirrors/op/openchamber点击查看免费下载导读本文围绕 OpenChamber 仓库中负责「React Doctor 诊断清理」的无人值守任务命令 rd-fixes.md 展开系统讲解如何通过bun run doctor的next-batch/check-batch/release等子命令按批次领取一组文件、以行为保持为原则修复 React Doctor 诊断、校验并生成单一可评审的维护 PR。读完本文你将掌握这套批处理流程的安全门机制、批次的生成与并发隔离原理、修复与中止规范、PR 描述填写要求以及它与仓库内 scripts/react-doctor.mjs、scripts/lib/batch-claims.mjs 和 AGENTS.md 之间的源码级对应关系。一、任务定位可定时运行、可随时安全停止的维护批次OpenChamber 的rd-fixes命令被设计为一个可以无人值守、按计划定时执行的任务它随时可以安全启动并且在「无活可干」时必须干净地停下来。命令自身的 frontmatter 声明了其职责--- description: Create a React Doctor diagnostics cleanup PR from the next generated batch agent: build ---它的目标是在一个小型、可评审的维护 PR 内减少 React Doctor 诊断数量。支撑它的入口位于根目录 package.json 的doctor脚本doctor: node scripts/react-doctor.mjs也就是说所有bun run doctor -- 子命令实际都转发到 scripts/react-doctor.mjs。该脚本将仓库识别为openchamber-monorepo项目并固定使用react-doctor0.9.12见 scripts/react-doctor.mjs以保证无人值守批次不会因为诊断器版本漂移而改变输出形态。doctor命令族共支持 6 个子命令速查如下来自 usage 帮助文本子命令作用next-batch生成下一个批次打印 Run ID、批次名、分支名与 PR 标题check-batch --run run-id对比基线与本批修复后的诊断数量变化active列出所有活跃批次含其他管线的占用release --run run-id释放批次声明把文件归还给公共池file path单独查看某个文件的诊断明细top [--limit N]按优先级排序展示诊断最多的文件rd-fixes.md中出现的next-batch、check-batch、release、file均一一对应上述命令批处理之外还有一条独立的配套闭环命令 rd-follow-up.md负责在 PR 收到 Greptile/评审机器人反馈后做跟进下文会简要提及。二、第一道安全门启动前的 worktree 检查由于任务可能在任何时刻被调度执行它首先必须确认「当前工作副本是否安全可用」。命令给出的第一步是git status --porcelain根据输出是否为空任务会进入两种截然不同的分支存在.maintenance-clone标记文件说明这是专门为无人值守维护准备的一次性克隆里面的任何改动都不属于人类的工作成果而是上一次失败任务遗留的「碎片」。此时应当恢复克隆而非停止git checkout -- . git clean -fd git checkout main git pull执行后必须报告具体丢弃了哪些文件然后继续任务——一个失败的前任任务不能把后续每次运行都堵死在脏工作副本上。标记文件不存在这是人类正在使用的工作副本。此时应立即停止并报告「worktree 存在未提交改动」且明确禁止 stash、reset、丢弃、提交或切换分支。这一设计在 scripts/lib/batch-claims.mjs 的注释中也有呼应维护管线预期运行在同一个仓库的专用克隆上因此批次声明claim默认存放在工作副本之外的~/.openchamber/maintenance-claims/runsbatch-claims.mjs所有克隆与所有管线共享同一份声明无需任何按调度器的额外配置只有当需要隔离实验时才通过--claims-dir或环境变量OPENCHAMBER_BATCH_CLAIMS_DIR覆盖batch-claims.mjs。三、生成批次bun run doctor -- next-batch检查通过后命令执行bun run doctor -- next-batch --min-issues 75 --max-issues 120并以该命令的输出作为本次任务范围的唯一事实来源。3.1 关键参数与默认值next-batch支持的全部参数及默认值如下usage 帮助文本 与 commandNextBatch 实现参数默认值含义--min-issues75批次诊断数量目标下限--max-issues120批次诊断数量目标上限--max-files4单批次最多包含的文件数--max-active20同时存在的活跃批次上限--claim-ttl3天声明有效期的 TTL天--claims-dir共享默认目录覆盖批次声明存放位置隔离用如果--min-issues大于--max-issues脚本会直接抛错拒绝执行。3.2NO BATCH AVAILABLE语义空手而归也是正确结果如果输出中包含NO BATCH AVAILABLE任务必须立即停止并报告打印出的原因不得创建分支、不得创建 PR、也不得自行寻找其他工作。触发该输出的两种情形见 commandNextBatch活跃批次数量已达上限默认 20已无未被占用的诊断所有文件都被活跃批次声明。并发问题在命令层已被处理next-batch会读取全部活跃声明把已被其他批次声明的文件从候选中剔除claimedFilePaths过滤见 react-doctor.mjs并拒绝超过活跃批次上限。3.3 批次选择算法候选文件按「文件优先级分数」排序sortedFileEntries / filePriority优先级分数由该文件诊断涉及的规则优先级之和、高信号规则数量优先级 ≥ 66加成、以及噪声规则比例优先级 ≤ 35的惩罚共同计算。随后 selectBatch 按以下顺序决策若存在诊断数落在[min-issues, max-issues]窗口内的文件直接选中整文件批次否则若存在超过max-issues的「超大文件」将其作为单一完整文件批次选中否则按排序顺序贪心累加完整文件直到达到min-issues或文件数达到max-files若仍无组合命中选择当前最靠前的完整文件可低于目标窗口。其原则始终是**「完整文件」而不是「抽取部分诊断」**——这正是 rd-fixes 命令中「Treat the selected files as complete-file scope」的来源。3.4 批次输出与元数据成功生成批次后命令会打印Run ID: ISO 时间戳 Batch name: rd-时间戳-区域slug Branch name: react-doctor/batch name PR title: Reduce React Doctor diagnostics in 区域这些命名规则由 createBatchMetadata 生成并同时落盘为 run 目录中的baseline.json全量诊断基线与batch.json批次元数据见 writeRun。任务必须逐字使用命令打印的 Run ID、批次名、分支名与 PR 标题不得自行改写。四、修复工作流整文件范围与行为保持优先拿到批次后工作流明确如下生成批次前先切到main并git pull拉取最新远端代码仔细阅读next-batch输出使用打印的精确Branch name创建分支只处理批次中列出的文件且以「完整文件」为范围禁止只挑前 N 条诊断敷衍了事默认行为是尽可能修复所选诊断而不是跳过。4.1 推荐的修复类型命令明确了「优先直接、行为保持」的修复方式包括缺失的 effect 清理missing effect cleanup可变 effect 依赖mutable effect dependencies用语义化修复处理可访问性问题如键盘事件局部性能改进Tailwind 简写替换边界清晰的组件抽取先搜索确认无引用后再删除死代码局部且清晰时的 reducer / 派生状态清理。这些修复类型与 scripts/react-doctor.mjs 中PRIORITY_RULES的高优先级规则一一呼应——例如effect-needs-cleanup100、no-mutable-in-deps95、click-events-have-key-events90、no-direct-state-mutation86等。该规则表是批次文件排序的依据也是「哪些诊断值得优先处理」的量化标尺规则名优先级effect-needs-cleanup100no-mutable-in-deps95click-events-have-key-events90no-direct-state-mutation86no-secrets-in-client-code85async-await-in-loop/server-sequential-independent-await80no-fetch-in-effect/rerender-state-only-in-handlers62no-array-index-as-key52no-giant-component15exports/types10files5完整映射见 PRIORITY_RULES。4.2 大诊断也要从容处理而非跳过组件拆分抽取能降低诊断的最小内聚子组件同时保持 props/state 流转不变死代码删除导出、类型或文件前必须用搜索验证引用状态架构问题优先做最小的局部 reducer 或派生状态简化并保持行为渲染函数抽取只抽取不依赖大型隐式闭包状态的稳定渲染辅助函数或改为显式传 props行为敏感诊断先通读周边代码保留既有运行时行为。4.3 文件完成标准与诚实跳过一个文件只有当诊断清零或每条剩余诊断都有具体、个别的保留理由时才算完成。半修的文件之后会被再次选中等于为同一段代码付出第二次 PR、第二次评审、第二次合并。因此完成前必须重跑bun run doctor -- file path查看剩余项若剩余超过文件诊断的四分之一说明还没有修完共享同一根因的一组诊断只算一个理由而该根因通常值得修而非延后允许跳过的情形修复会导致不清晰的行为变更改动大到 PR 失去可评审性唯一能想到的关闭方式是自己在评审中都无法辩护的改动。诚实的跳过永远好于强行修复但「普通难度」本身不构成理由跳过的诊断必须在 PR 正文的## Non-goals中给出具体理由若整个文件需要的是刻意的架构改造而非清理应按「Aborting cleanly」中止并报告该文件是糟糕的批次选择除非存在明确误报否则不得抑制 React Doctor 诊断若诊断需要改动选中文件之外的内容只做最小必要支撑改动不得扩大清理范围。五、干净地中止Aborting cleanly批次可能遇到无法正确完成的情况验证持续失败或唯一能关闭发现项的方式是任务明令禁止的模式。此时停止是正确的决定但带着修改过的副本走开是错误的。工作副本中的任何编辑都是本会话几分钟前自己的产出不是人类进行中的工作删掉它们没有任何损失留下它们会让之后每次定时运行它们会正确拒绝脏 worktree全部卡死。中止必须按顺序执行回滚所有修改git checkout -- paths对新建文件加git clean -fd再用git status --porcelain确认结果为空释放声明让文件回到公共池bun run doctor -- release --run run-id回到main报告尝试了什么、为何停止并确认 worktree 已干净、声明已释放。命令给出的原则是永远不要把半修的工作副本留给下一次运行——如果某个文件抗拒正确的修复它应该出现在报告里而不是磁盘上。releaseRun在源码中的实现就是删除对应 run 目录batch-claims.mjs目录一删声明即失效。六、验证与交付6.1 批次级验证编辑完成后先执行bun run doctor -- check-batch --run run-idcheckBatch 会读取该 run 的baseline.json与batch.json重新运行诊断器并逐文件打印Before / After / Delta最后汇总「选中文件已修复诊断数」「剩余诊断数」以及「选中文件之外诊断的增量」。6.2 包级校验而非全仓校验只验证实际动过的包而不是整个 workspace。例如动到packages/ui时bun run --cwd packages/ui type-check bun run --cwd packages/ui lint bun run --cwd packages/ui testworkspace 级的bun run type-check与bun run lint是 CI 的职责只有在改动跨越包边界或触及共享契约时才在本地运行。对于 TypeScript 覆盖不到的 server / CLI JavaScript 等文件应运行该模块的针对性测试。这一点与 AGENTS.md 的 Validation 一节完全一致优先 focused tests 与包级 type-check/lint静态检查不能替代运行时验证。6.3 交付流程确认选中文件的诊断数比之前更少若验证失败仅当修复仍在任务范围内才修复否则停止并报告阻塞点用简洁信息提交改动推送分支用gh pr create创建恰好一个PR使用打印的精确PR titlePR 创建后切回main并再次git pull。七、PR 描述规范模板化、可审计、证据充分仓库有强制的 PR 模板 .github/PULL_REQUEST_TEMPLATE.md且 AGENTS.md 要求为最终 PR HEAD 提供具体证据因此写描述前必须先读模板和 CONTRIBUTING.md。rd-fixes 命令要求按模板顺序填写每个章节不得自造替代标题各章节要点如下章节填写要求## Intent声明这是无人值守维护批次写明Run ID、Batch name、Branch name说明行为变化无可见变化时明确说明而非暗示并在此处列出选中文件及check-batch报告的「已修复/剩余」诊断数## Non-goals选中文件内未修复的诊断、仓库其他位置的诊断、刻意未开始的任何重构每个都要给出理由而非只写数量## Affected surfaces改动触及的包、运行时、用户可见状态与持久化/外部契约逐一说明改动运行的每个运行时并解释看似适用实则不受影响的运行时## Repository guidance填写表格遵循的AGENTS.md规则、匹配的项目技能、必读的技能引用、所动模块最近的README.md或DOCUMENTATION.md每行都要解释适用原因与合规方式## Validation精确列出运行过的命令与结果包含check-batch及每个包级 type-check/lint/test诚实记录失败含与本 PR 无关的既有失败说明未运行哪些检查不得仅凭 type-check/lint 声称运行时行为## Visual evidence此类 PR 通常无可见变化需具体解释为何 diff 不可能影响渲染行为若确有可见变化附受影响状态的 before/after 证据## Risks and failure behavior覆盖改动错误时的影响、回滚方式以及兼容性、数据、性能、跨运行时问题只有给出具体理由时才允许写「None identified」模板章节之后还需追加## Manual testing recommendations一节基于选中文件与实际编辑给出聚焦检查项例如受影响的 dropdown、键盘导航、模型/agent 选择、设置控件、移动端与桌面端变体。说明仓库内 .github/PULL_REQUEST_TEMPLATE.md 实际使用的标题为## What and why、## Affected surfaces、## Validation、## Visual evidence、## Risksrd-fixes 命令在此基础上进一步要求以## Intent、## Non-goals、## Repository guidance、## Risks and failure behavior等章节组织内容并保留模板的全部既有标题顺序。写描述时以命令要求为准同时遵守模板与AGENTS.md的完整性与证据要求。八、约束清单与防碰撞机制命令末尾的约束为整条维护流水线兜底PR 保持小而可评审禁止 auto-merge除选中文件修复所需的最小支撑改动外不修改无关文件不做大范围格式化不修复选中文件之外的诊断不改CHANGELOG.md、包版本或发布元数据——这是无用户可见变化的内部维护与 AGENTS.md 中「changelog 只由维护者在发布时写入」的规则一致保留批次的 run 目录next-batch会打印其位置。该目录既是评审跟进任务的交接物也是防止另一个批次包括 anti-slop 管线触碰同一批文件的声明。过早删除会让并行批次与本 PR 冲突。永远不要手工删除它而要用bun run doctor -- release --run run-id若因任何原因在创建 PR 前停止同样用release释放声明让文件回到公共池。从源码看声明的 TTL 与活跃判定在 readActiveClaimsrun 目录命名形如rd-ISO 时间戳pipeline-runId超过claim-ttl天默认 3 天的声明视为过期并跳过printClaims会区分「本管线」与「其他管线」anti-slop 批次显示为[pipeline as]——rd-follow-up.md 中明确要求绝不触碰anti-slop 管线的批次。九、配套闭环rd-follow-up跟进任务next-batch生成的 PR 评审意见由 rd-follow-up.md 承接。其要点包括用bun run doctor -- active列出活跃批次只处理「最旧且有未处理反馈的开 PR」的批次PR 已合并或关闭时用release释放声明修复反馈时保持改动限于原选中文件、不重写原 PR、不强制推送回复评审意见时给出改动说明与提交哈希PR 未合并前不得释放批次只有合并/关闭后才release。它与 rd-fixes 共用同一套 claim 机制保证整条「生成批次 → 修复 PR → 跟进评审」的无人值守链路文件互不冲突。十、快速定位索引主题仓库路径本任务命令全文.opencode/commands/rd-fixes.md配套跟进命令.opencode/commands/rd-follow-up.mddoctor CLI 实现批次选择、元数据、校验scripts/react-doctor.mjs批次声明与释放共享 claims 目录、TTLscripts/lib/batch-claims.mjsdoctor脚本入口package.jsonAgent 全局规则与验证/PR 交接要求AGENTS.md强制 PR 模板.github/PULL_REQUEST_TEMPLATE.md贡献流程与模板说明CONTRIBUTING.md这套流程的核心价值在于把「降低 React Doctor 诊断」这类反复出现的代码卫生工作封装成可定时、可并发、可回滚、可审计的自动化维护批次——用完整文件范围保证每个文件一次修完用共享 claims 保证多个管线rd 与 anti-slop并行不撞车用严格的 PR 模板保证每一条修复都有据可查、每一处跳过都有理由。赞分享AI Agent人工智能代码智能体交互助手【免费下载链接】openchamberAgentic Development Environment based on OpenCode AI agent项目地址https://gitcode.com/gh_mirrors/op/openchamber点击查看免费下载相关推荐KernelSU 内核 root 完全指南GKI 与 LKM 模式怎么选、boot 镜像怎么刷KernelSU 内核 root 完全指南GKI 与 LKM 模式怎么选、boot 镜像怎么刷 KernelSU 是一款跑在内核态的 Android root操作系统驱动开发5 分钟画好第一条风扇曲线FanControl 安装与调参完整指南5 分钟画好第一条风扇曲线FanControl 安装与调参完整指南 刚装完大型游戏一进主菜单机箱风扇就满速呼啸BIOS 里却只有一个自动档。FanCo桌面应用智能硬件如何在 oxlint 中注册 oxlint-plugin-react-doctor 并启用 React Compiler 诊断如何在 oxlint 中注册 oxlint plugin react doctor 并启用 React Compiler 诊断 如果你不想跑完整的 React开发工具代码质量静态分析LintAI 技能上一篇Lucide 图标以图片形式使用lucide-static 中 img 标签与 CSS 背景图完整指南下一篇TDengine PI 实时数据同步指南从任务配置、高级功能到故障排查的完整实战手册创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
