DeepSeek-Harness 的 dsh-code-review 技能维护机制基于双评审人适配器的定期人工反馈采纳管线【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness本文档解析 deepseek-harness 仓库中 human-review skill-maintenance Agent Note 所设计的技能维护机制它用一套运行在仓库之外的私有工具把 GitHub PR 上真实的人工评审反馈经过证据过滤、双适配器独立分类、有界修订循环后转化为 dsh-code-review 技能 的周期性小批量更新。读者读完本文后将掌握该管线的采集过滤规则、采纳证据算法B/T/M 快照、评审适配器协议、推广契约与运维实操含具体命令与产物目录并理解其fail-closed证据不足即不采纳的设计哲学。一、问题背景为什么一次性的评审审计不可持续dsh-code-review是 deepseek-harness 仓库中用于 PR 评审的技能它记录了大量需要评审人主观判断的失败模式——例如新散文必须接受语义评审文档与代码必须同步注册项必须通过销毁测试。技能本身在 SKILL.md 中明确声明这是一份指导而非完整检查清单评审人需要结合pnpm --silent run change-scope报告、AGENTS.md、docs/defensive-patterns.md 等权威来源做语义判断。但技能如何随评审经验的积累而演进文档指出了一个根本矛盾把每条评审评论都当作教训会导致检查清单无限膨胀checklist bloat把PR 被合并讨论串已解决作者回复已修复当作反馈已被采纳的证据则会推动那些最终代码可能根本没落实的反馈进入技能——因为一个 PR 完全可能在反馈被拒绝、被取代或刻意搁置的情况下照常合并。一次性的人工审计one-off audit虽然能发现问题但重复开展成本高昂且每次审计的作用域容易不一致。因此需要一套周期性、可重复、证据充分、带独立评审的维护流程并且在工作流被证明有用之前不引入 webhook 服务、不持久化事件状态、不自动推广仓库改动。二、提案总览仓库外运行的私有维护工具核心方案是在仓库外部进行定期维护。一项保存在技能维护者operator机器上、不提交到本仓库的私有工具会针对刷新至origin/master的干净完整历史 checkout 运行执行以下端到端流程关键调度参数调度频率预期的调度器每天运行使用两个 UTC 日的重叠窗口即使漏跑一天也能被重叠窗口自动覆盖手动运行可通过额外的--since时长参数或重复的--pr参数指定一个显式 PR 集合幂等性扫描相对于当前技能是幂等的——已经进入技能的内容会被归类为已覆盖covered不会重复成为候选工具不存储任何仓库游标最小改动面推广时唯一允许变更的仓库文件是 .agents/skills/dsh-code-review/SKILL.md生成的 draft PR 正文只列出源反馈 URL/ID 与采纳证据绝不暴露私有适配器的原始日志。三、采集约定资格过滤先于反馈获取工具对每一个 PR 的采集遵循先过滤、后获取的原则避免把不可靠的反馈引入分析。3.1 资格检查merge commit 可达性每个被选中的 PR 在获取任何反馈之前都要经过过滤其 merge commit 必须是origin/master的祖先reachability。这是唯一的资格检查——注意它对堆叠 PRstacked PR是宽容的一个直接 base 是功能分支的堆叠 PR只要该 base 随后已经进入 master就会被纳入——因为无论中间 stack 如何评审人评论的那份代码此刻已经处于 master 上。另外工具还会解析落地 mergelanding merge的目标父级target parent若某种落地形态无法重建该 PR 会被记录到skipped-pulls.json并跳过。单个 PR 在预检、采集或证据收集阶段失败时只跳过该 PR绝不中止整次运行。3.2 搜索与分页防静默遗漏搜索阶段 fail loud当时间窗口会超过 GitHub 搜索的 1,000 条结果上限时搜索阶段会明确失败从而保证不会有已合并 PR 被静默遗漏采集阶段完整读取分页连接覆盖内联评审评论inline review comments、评审提交review submissions和 PR commit 三类数据。3.3 反馈来源过滤只信任可定位的人工反馈不采集 PR 对话评论因为当前 GitHub 状态无法证明一次 force-push 之后哪条幸存评论位于哪个 commit 之前——采纳约定会因此无条件排除它们所以干脆不采集仅接受 GitHub 报告 actortype为User的反馈作者类型在分析之前就被过滤因此人类账号转发自动化发现forwarded automation也会被作者检查排除从源头保证学习对象是人类评审反馈这一来源契约时间戳严格性反馈的创建时间与最后编辑时间都必须严格早于PR 合并时间——与合并同一时间戳的编辑被视为合并后操作而拒绝评审提交使用 GraphQL 的lastEditedAt因为 REST 表示不含编辑时间无法做上述严格性校验。四、采纳证据B/T/M 快照算法这是整条管线最精巧的部分如何判定某条反馈确实被最终代码采纳了。4.1 基线选择不用评审人点击的 commit当评审人的commit_id仍属于该 PR 时force-push 场景无法确认即 fail-closed工具会选择committer 时间戳严格早于该反馈的最新 PR commit作为基线B——而不是评审人当时点击的那个 commit因为后者可能是一个更旧的 commit。4.2 两份 PR 专用快照工具绝不直接比较基线与落地 merge因为那样的 diff 会混入不断前移的目标分支带来的无关变更。它改用三个记号构造两份 PR 专用 patch 快照B反馈基线feedback baselineT落地 merge 的目标父级landing merges target parentM落地 mergelanding merge快照构造方式含义反馈时快照merge-base(B, T)到B的树 diff反馈发生时PR 相对目标分支的改动最终快照T到M的树 diff落地时PR 相对目标分支的全部改动由此得到两个关键性质目标分支专有变更不会出现在任一 PR patch 中因为它既不属于B侧也不属于M侧相对T的改动反馈之后才加入 PR 的变更只会出现在最终快照中。于是采纳评审人adoption reviewer就能干净地判断反馈指向的改动是否真的在最终 PR 中落地。4.3 确定性unclear分类以下三类情况会在任何评审人看到之前被确定性归类为unclear不明确而不是交给模型猜测关联 commit 已因 force-push 而不再属于该 PR 的评审早于全部现存 PR commit 的反馈无法重建目标父级的落地形态。同时合并状态、已解决讨论串、作者回复已修复、同文件编辑都只是上下文context不是采纳证明PR 作者自己的评论也绝不会进入适配器——因为它们不可能构成对作者自身意见的采纳。五、双评审人分类与起草采纳证据就绪后进入两阶段分类与起草流程。5.1 第一阶段作者与采纳判定两个独立配置的评审适配器reviewer adapter对每个合格条目输出两类判定作者分类human-authored人类撰写、forwarded-automation转发的自动化、unclear采纳分类adopted已采纳、rejected被拒绝、unclear。只有两个适配器都判定为human-authoredadopted的条目才继续往下走。独立判定的价值在于能在不支持的概括进入技能之前就暴露问题——这也是文档在替代方案中否决让同一个评审人既当作者又当最终裁决的原因。5.2 第二阶段对照当前技能分类采纳集合随后接受第二次独立分类判定其相对当前技能属于候选candidate可作为新指导已经覆盖covered当前技能已涵盖特定于实现implementation-specific只对该 PR 有意义并非反馈not feedback。值得注意的是单个条目即可成为候选不要求重复出现singleton may qualify; recurrence is not required。这避免了必须等到多次重复才更新技能造成的滞后。5.3 分歧处理与批次级 fail-closed分歧两个适配器意见不一致时会获得一次有界的重新评估bounded re-evaluation仍未解决则保留在运行产物中可见不强行抹掉。批次级 fail-closed单个批次中任一适配器输出未通过 schema 或 id 校验时整个批次按不采纳处理——其中每条反馈都被标记为unclear并路由到excluded而不是中止整次运行有问题的原始输出会保存在该次运行的私有产物中供调试。整体失败保护如果任一适配器在某项操作的任何非空批次中都没有返回有效结果运行会以非零状态退出并发出失败记录而绝不会把提供方完全中断折叠成没有候选项no candidate——避免虚假的一切正常。5.4 起草主适配器只读、无工具主适配器primary adapter只根据结构化的共同指引起草structured agreed guidance绝不接触原始评审文本按适配器作者契约它保持无工具且只读edit操作也只在 JSON 中返回完整候选文件内容由工具校验后写入唯一目标起草完成后两个适配器评审同一份完整 skill diff阻塞性发现进入有界修订循环且两者必须批准同一修订版本。5.5 写入安全与产物打包工具会在运行文档/lint 门禁之前和报告成功之前两次拒绝暂存改动与目标 skill 之外的编辑防止门禁或并发进程通过添加其他路径混入失败时用尽力而为的 compare-and-swap回滚自身写入避免覆盖维护者的并发编辑回滚同时会取消暂存目标防止失败运行遗留的暂存候选进入之后的 commit成功时保存一份候选资料包candidate bundle包含源origin/mastercommit、源 skill blob ID、已评审 diff、完整候选文件、源反馈 ID 与 URL、落地证据范围、适配器判定、门禁结果工具绝不 commit、push、打开或合并 PR——推广动作留给运维人员通过正常仓库评审完成。六、评审适配器协议可审计的隔离契约两个评审适配器都是私有可执行文件通过标准输入输出与工具通信每个适配器从stdin接收有字节上限、带版本的 JSON 请求在stdout返回有字节上限且符合 schema的 JSON同字节可执行文件检查两个评审命令解析为逐字节相同的可执行文件时工具拒绝运行——这是最低限度的机械检查而主/次适配器确实由独立提供方或模型驱动属于部署运维方的责任文档在风险章节明确指出了这一边界access与tools字段是适配器作者承担的契约标记并非 OS 沙箱。6.1 子进程隔离评审子进程在清理后的环境scrubbed environment中 spawncwd指向私有运行目录而非仓库根目录并采用有界、感知中止的进程树清理。每个生产git/gh/门禁进程同样使用清理后的环境——防止 pre-push 钩子的路由变量无提示地重定向维护工具。6.2 非信任反馈包装nonce 机制反馈内容被包装在带随机数的块中untrusted-feedback nonce……/untrusted-feedback每个提示词都会指示模型将该块视为数据128 位 nonce 防止不受信任的正文伪造结束标签closing tag逃逸出包装块从而阻断提示注入路径。七、推广约定防陈旧覆盖的 draft PR 流程推广辅助工具promote helper是整个机制中唯一接触仓库的环节从刷新至origin/master的干净 checkout开始拒绝陈旧候选当当前 skill blob 与资料包中记录的源 blob 不一致即源技能已变化时拒绝应用候选——辅助工具绝不用陈旧的完整文件输出替换较新的SKILL.md运维人员此时重新运行维护分析或手动 rebase 该 diff 并重新评审候选应用仍然有效的候选后打开draft PR其正文列出源反馈 URL 或 ID、用作采纳证据的落地 commit 范围、发起该候选的运行、门禁结果、以及任何运维人员编辑原始适配器提示词与响应保持私有但仓库评审人会获得上述具体输入从而可以独立判断每条拟议规则是否确实来自已被采纳的人类反馈。八、机制所在位置与交接约定工具源码、适配器二进制、提供方凭据与每日调度器全部保留在维护者机器上不提交到本仓库。文档明确说明这是有意为之该机制只服务于由单个运维方维护的一项技能因此持续通过仓库评审来审查机制改动的成本高于提交工具及其历史的收益。如果机制将来移交给第二位维护者需要通过一篇后续 Agent Note修订本决策任何接手者都应从运维文档 docs/cookbook/maintaining-dsh-code-review.md 入手。值得注意的是配套的 cookbook 与 Agent Note 成对维护两者共享 i18n 配对一致性记录 docs/cookbook/maintaining-dsh-code-review.i18n.yaml中文版见 maintaining-dsh-code-review.zh.md。九、运维实操从候选 diff 到合并上线cookbook 文档 给出了操作员侧的完整实操细节与 Agent Note 互补。9.1 维护者收到什么操作员每天手动调用包装脚本使用 2 个 UTC 日的重叠窗口每周手动恢复运行使用 7 日窗口。工作流依次选择窗口内合并、且 merge commit 可从origin/master到达的 PR每日默认 2 个 UTC 日每周 7 日merge commit 不可达如父分支被 squash 的堆叠分支或超过250 个 commit 采集上限的 PR记录到skipped-pulls.json并跳过收集合并前带 commit 锚点的人工评审反馈行内评论与评审提交比较反馈时与最终落地的 PR patch不获取 PR 对话评论不把目标分支专有变更作为采纳证据两个独立配置的评审适配器先判定作者与采纳再对照当前技能分类主适配器起草完整修订版SKILL.md两适配器评审同一 diff阻塞发现循环直至双方批准工具声明成功前运行pnpm run doc-sync和pnpm run lint两个门禁。9.2 产物落盘位置每次运行的产物保存在操作员机器上保存的 diff、候选SKILL.md与提升 manifest 按时间戳命名存放于~/dsh-code-review-outputs/manifest 记录源 master commit 与 skill blob、源反馈 ID 与 URL、落地证据范围、适配器判定、门禁结果每个适配器的原始 I/O 留在私有临时目录其路径写入通知与~/Library/Logs/dsh-code-review-maintainer/下的每日日志维护 worktree 在每次运行后恢复为干净状态避免操作员直接在维护副本中编辑。9.3 操作员对候选 diff 的三选一决策某次运行产出候选时macOS 会发出带dsh-code-review-promote timestamp提示的通知。操作员必须根据 diff 本身作出判断而不是因为评审者已经批准就接受——最终决策权在操作员。检查要点清单膨胀、历史叙述、基于单次事件的无依据外推、与现有技能或权威文档的重复覆盖。ls ~/dsh-code-review-outputs/ # 所有历史候选 less ~/dsh-code-review-outputs/2026-07-16T02-00-00Z.diff less ~/dsh-code-review-outputs/2026-07-16T02-00-00Z.SKILL.md less ~/dsh-code-review-outputs/2026-07-16T02-00-00Z.manifest.json交叉核验后从三种处理方式中选择丢弃Discard删除保存的候选下一次运行会依据届时最新的技能重新考虑同一份反馈。rm ~/dsh-code-review-outputs/2026-07-16T02-00-00Z.{diff,SKILL.md,manifest.json}留待成批Batch更新很小时留待与后续候选合并源 skill 检查仍然适用若master先变化需重新运行分析或手动 rebase 并重新评审 diff。提升Promote在仓库的干净mastercheckout 中运行提升辅助工具它刷新master、验证当前 skill 与记录的源 blob 一致、应用保存的 diff 并创建 draft PR。skill 已漂移时停止绝不覆盖更新的指导。cd ~/path/to/deepseek-harness # clean master dsh-code-review-promote 2026-07-16T02-00-00Z操作员还应注意不要逐字提交适配器输出。提升过程中的小幅编辑——收紧措辞、移除只有结合源 PR 上下文才有意义的示例、把规则并入现有规则——是预期行为保留了工作流所依赖的评审人判断合并前应在分支上修订这些改动。9.4 无候选是常态只要每个非空分类阶段都至少产生一个有效适配器结果无候选就是最常见的情况。工具在每日日志中记录no candidate不发送通知避免提醒疲劳然后继续。文档特别强调没有技能更新的日子是工作流正确运行的标志而不是停滞。9.5 中断处理与交接错过每日运行2 日重叠窗口自动覆盖一次漏跑更长间隔通过DSH_CODE_REVIEW_SINCENd手动运行包装脚本来恢复。重叠窗口幂等已覆盖的指导归类为covered不会再次成为候选。适配器提供方中断工具拒绝两个命令逐字节相同的配置单批次 schema/id 校验失败则整批 fail-closed 并继续任一适配器在所有非空批次均无有效结果时运行失败、写失败记录并通知操作员——绝不把提供方中断折叠成无候选。交接新建后续 Agent Note要么把机制移入仓库要么记录新操作员的私有设置不暗中转交工具——单维护者风险正是交接必须留下书面决策的原因。十、考虑过的替代方案文档系统性地记录了对八种替代方案的否决理由这组决策本身也是理解机制边界的最好材料替代方案否决理由把工具放入本仓库单维护者作用域下仓库维护开销typecheck、lint、覆盖率、横切重构超过已提交源码与评审历史的价值未来移交时可重新考虑记录每条反馈产生时的 PR head需要持续运行的观察器、持久事件状态、重试与 force-push 协调定期维护用已评审 commit 证据并在证据过宽时 fail-closed持久化已处理 PR 游标重叠时间窗口扫描成本低且天然幂等游标状态反而引入恢复与漏事件问题每条新评论都触发运行一轮评审会产生大量相关评论且缺少判断采纳所需的最终产物把合并或讨论串解决视为采纳PR 可能在反馈被拒绝、被取代或刻意不解决的情况下合并自动创建或合并仓库改动工具需要先通过有用的周期输出积累可信记录应由维护者检查并经正常仓库评审推广从已修复的 bot 问题中学习来源契约限定为人类评审反馈作者类型在分析前过滤让同一评审人既当作者又作最终裁决独立判定能在不支持的概括进入技能前暴露问题十一、验收标准与实测观察从proposed/晋升到implemented/需要针对本仓库的真实端到端运行中观察到以下全部事实私有工具从刷新至origin/master的干净 detached checkout 运行要么报告没有候选项要么只生成 .agents/skills/dsh-code-review/SKILL.md 的 working-tree diff。2026-07-15 已观察扫描 62 个已合并 PR跳过 5 个merge commit 不可达或超过 250 commit 采集上限考虑 426 条人类反馈发现 0 个候选项。两个评审适配器独立配置不同提供方或模型无需用户干预完成 analyze/adopt/review 流程。2026-07-15 已观察不同主/次适配器约 8 分钟完成采纳与分析一次适配器 id 幻觉由批次级 fail-closed 处理未中止运行。调度器在无交互终端下触发工具候选 diff或无候选记录通过持久通知通道送达操作员。受控采集场景在反馈基线后向目标分支加入与反馈匹配的变更评审证据排除该目标分支专有变更同时保留后续由 PR 自身加入的变更。源 skill 改变后推广辅助工具拒绝候选仍有效的候选打开 draft PR含源反馈 ID、已采纳 commit 范围、发起运行、门禁与操作员编辑。至少一个候选 diff 由操作员检查并通过普通仓库 PR 评审推广到master——该 PR 是工作流能把已采纳反馈转化为已交付技能指导的直接证据。十二、风险边界机制承认的四个局限文档诚实列出了机制当前的局限引用它们有助于准确理解这套管线的适用前提基于 committer 时间戳推断因果关系反馈-commit 基线通过比较 GitHub commit 时间戳与反馈创建时间戳选出committer 时钟偏差与重写仍会留下误判采纳的残余窗口与 GitHub PR 事件流交叉比对可进一步收紧但超出定期工具的作用域。两个非候选项分类直接路由到excluded无争议轮次两个分类器都判不是候选但对原因如coveredvsspecific意见不一时条目被排除而非重估——因为双方一致认为它不会形成新的评审行为争议轮次不会改变结果。双评审人独立性是部署契约工具只能校验两个命令非逐字节相同无法验证两个包装层背后是不同的提供方或模型运维方必须配置独立的主/次适配器。尽力而为的 compare-and-swapPOSIX 上基于文件的 CAS 并非真正原子窗口为一个事件循环周期工具面向单用户定期维护真正并发的编辑器不在支持范围内。单维护者风险机制位于单台机器服务中断会完全停止技能维护直到操作员恢复或通过后续 Agent Note 完成移交。总结一套证据充分才更新的技能演进范式deepseek-harness 的这份 Agent Note 与其配套 cookbook 共同定义了一套可复制的技能维护范式把人工评审反馈 → 技能指导的转化从一次性、主观的审计变成周期性、可审计、默认不采纳的工程管线。其精髓可以概括为三点证据优先merge commit 可达性过滤、时间戳严格性校验、B/T/M 快照算法层层确保只有人类撰写、且确实在最终代码中落地的反馈才有资格进入下一阶段独立评审两个独立配置的适配器对作者、采纳、分类做三次交叉判定分歧有界重估单点故障通过批次级 fail-closed 隔离人机分工工具负责证据收集、隔离与门禁操作员负责最终判断与推广——工具绝不自动合并技能更新始终以小型、可审查、可回退的 PR 形式进入仓库。对于任何维护评审技能/检查清单类知识资产的团队这套机制在幂等扫描、fail-closed 判定、非信任输入隔离与防陈旧覆盖方面的设计都是一份高参考价值的工程样本。【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
DeepSeek-Harness 的 dsh-code-review 技能维护机制：基于双评审人适配器的定期人工反馈采纳管线
DeepSeek-Harness 的 dsh-code-review 技能维护机制基于双评审人适配器的定期人工反馈采纳管线【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness本文档解析 deepseek-harness 仓库中 human-review skill-maintenance Agent Note 所设计的技能维护机制它用一套运行在仓库之外的私有工具把 GitHub PR 上真实的人工评审反馈经过证据过滤、双适配器独立分类、有界修订循环后转化为 dsh-code-review 技能 的周期性小批量更新。读者读完本文后将掌握该管线的采集过滤规则、采纳证据算法B/T/M 快照、评审适配器协议、推广契约与运维实操含具体命令与产物目录并理解其fail-closed证据不足即不采纳的设计哲学。一、问题背景为什么一次性的评审审计不可持续dsh-code-review是 deepseek-harness 仓库中用于 PR 评审的技能它记录了大量需要评审人主观判断的失败模式——例如新散文必须接受语义评审文档与代码必须同步注册项必须通过销毁测试。技能本身在 SKILL.md 中明确声明这是一份指导而非完整检查清单评审人需要结合pnpm --silent run change-scope报告、AGENTS.md、docs/defensive-patterns.md 等权威来源做语义判断。但技能如何随评审经验的积累而演进文档指出了一个根本矛盾把每条评审评论都当作教训会导致检查清单无限膨胀checklist bloat把PR 被合并讨论串已解决作者回复已修复当作反馈已被采纳的证据则会推动那些最终代码可能根本没落实的反馈进入技能——因为一个 PR 完全可能在反馈被拒绝、被取代或刻意搁置的情况下照常合并。一次性的人工审计one-off audit虽然能发现问题但重复开展成本高昂且每次审计的作用域容易不一致。因此需要一套周期性、可重复、证据充分、带独立评审的维护流程并且在工作流被证明有用之前不引入 webhook 服务、不持久化事件状态、不自动推广仓库改动。二、提案总览仓库外运行的私有维护工具核心方案是在仓库外部进行定期维护。一项保存在技能维护者operator机器上、不提交到本仓库的私有工具会针对刷新至origin/master的干净完整历史 checkout 运行执行以下端到端流程关键调度参数调度频率预期的调度器每天运行使用两个 UTC 日的重叠窗口即使漏跑一天也能被重叠窗口自动覆盖手动运行可通过额外的--since时长参数或重复的--pr参数指定一个显式 PR 集合幂等性扫描相对于当前技能是幂等的——已经进入技能的内容会被归类为已覆盖covered不会重复成为候选工具不存储任何仓库游标最小改动面推广时唯一允许变更的仓库文件是 .agents/skills/dsh-code-review/SKILL.md生成的 draft PR 正文只列出源反馈 URL/ID 与采纳证据绝不暴露私有适配器的原始日志。三、采集约定资格过滤先于反馈获取工具对每一个 PR 的采集遵循先过滤、后获取的原则避免把不可靠的反馈引入分析。3.1 资格检查merge commit 可达性每个被选中的 PR 在获取任何反馈之前都要经过过滤其 merge commit 必须是origin/master的祖先reachability。这是唯一的资格检查——注意它对堆叠 PRstacked PR是宽容的一个直接 base 是功能分支的堆叠 PR只要该 base 随后已经进入 master就会被纳入——因为无论中间 stack 如何评审人评论的那份代码此刻已经处于 master 上。另外工具还会解析落地 mergelanding merge的目标父级target parent若某种落地形态无法重建该 PR 会被记录到skipped-pulls.json并跳过。单个 PR 在预检、采集或证据收集阶段失败时只跳过该 PR绝不中止整次运行。3.2 搜索与分页防静默遗漏搜索阶段 fail loud当时间窗口会超过 GitHub 搜索的 1,000 条结果上限时搜索阶段会明确失败从而保证不会有已合并 PR 被静默遗漏采集阶段完整读取分页连接覆盖内联评审评论inline review comments、评审提交review submissions和 PR commit 三类数据。3.3 反馈来源过滤只信任可定位的人工反馈不采集 PR 对话评论因为当前 GitHub 状态无法证明一次 force-push 之后哪条幸存评论位于哪个 commit 之前——采纳约定会因此无条件排除它们所以干脆不采集仅接受 GitHub 报告 actortype为User的反馈作者类型在分析之前就被过滤因此人类账号转发自动化发现forwarded automation也会被作者检查排除从源头保证学习对象是人类评审反馈这一来源契约时间戳严格性反馈的创建时间与最后编辑时间都必须严格早于PR 合并时间——与合并同一时间戳的编辑被视为合并后操作而拒绝评审提交使用 GraphQL 的lastEditedAt因为 REST 表示不含编辑时间无法做上述严格性校验。四、采纳证据B/T/M 快照算法这是整条管线最精巧的部分如何判定某条反馈确实被最终代码采纳了。4.1 基线选择不用评审人点击的 commit当评审人的commit_id仍属于该 PR 时force-push 场景无法确认即 fail-closed工具会选择committer 时间戳严格早于该反馈的最新 PR commit作为基线B——而不是评审人当时点击的那个 commit因为后者可能是一个更旧的 commit。4.2 两份 PR 专用快照工具绝不直接比较基线与落地 merge因为那样的 diff 会混入不断前移的目标分支带来的无关变更。它改用三个记号构造两份 PR 专用 patch 快照B反馈基线feedback baselineT落地 merge 的目标父级landing merges target parentM落地 mergelanding merge快照构造方式含义反馈时快照merge-base(B, T)到B的树 diff反馈发生时PR 相对目标分支的改动最终快照T到M的树 diff落地时PR 相对目标分支的全部改动由此得到两个关键性质目标分支专有变更不会出现在任一 PR patch 中因为它既不属于B侧也不属于M侧相对T的改动反馈之后才加入 PR 的变更只会出现在最终快照中。于是采纳评审人adoption reviewer就能干净地判断反馈指向的改动是否真的在最终 PR 中落地。4.3 确定性unclear分类以下三类情况会在任何评审人看到之前被确定性归类为unclear不明确而不是交给模型猜测关联 commit 已因 force-push 而不再属于该 PR 的评审早于全部现存 PR commit 的反馈无法重建目标父级的落地形态。同时合并状态、已解决讨论串、作者回复已修复、同文件编辑都只是上下文context不是采纳证明PR 作者自己的评论也绝不会进入适配器——因为它们不可能构成对作者自身意见的采纳。五、双评审人分类与起草采纳证据就绪后进入两阶段分类与起草流程。5.1 第一阶段作者与采纳判定两个独立配置的评审适配器reviewer adapter对每个合格条目输出两类判定作者分类human-authored人类撰写、forwarded-automation转发的自动化、unclear采纳分类adopted已采纳、rejected被拒绝、unclear。只有两个适配器都判定为human-authoredadopted的条目才继续往下走。独立判定的价值在于能在不支持的概括进入技能之前就暴露问题——这也是文档在替代方案中否决让同一个评审人既当作者又当最终裁决的原因。5.2 第二阶段对照当前技能分类采纳集合随后接受第二次独立分类判定其相对当前技能属于候选candidate可作为新指导已经覆盖covered当前技能已涵盖特定于实现implementation-specific只对该 PR 有意义并非反馈not feedback。值得注意的是单个条目即可成为候选不要求重复出现singleton may qualify; recurrence is not required。这避免了必须等到多次重复才更新技能造成的滞后。5.3 分歧处理与批次级 fail-closed分歧两个适配器意见不一致时会获得一次有界的重新评估bounded re-evaluation仍未解决则保留在运行产物中可见不强行抹掉。批次级 fail-closed单个批次中任一适配器输出未通过 schema 或 id 校验时整个批次按不采纳处理——其中每条反馈都被标记为unclear并路由到excluded而不是中止整次运行有问题的原始输出会保存在该次运行的私有产物中供调试。整体失败保护如果任一适配器在某项操作的任何非空批次中都没有返回有效结果运行会以非零状态退出并发出失败记录而绝不会把提供方完全中断折叠成没有候选项no candidate——避免虚假的一切正常。5.4 起草主适配器只读、无工具主适配器primary adapter只根据结构化的共同指引起草structured agreed guidance绝不接触原始评审文本按适配器作者契约它保持无工具且只读edit操作也只在 JSON 中返回完整候选文件内容由工具校验后写入唯一目标起草完成后两个适配器评审同一份完整 skill diff阻塞性发现进入有界修订循环且两者必须批准同一修订版本。5.5 写入安全与产物打包工具会在运行文档/lint 门禁之前和报告成功之前两次拒绝暂存改动与目标 skill 之外的编辑防止门禁或并发进程通过添加其他路径混入失败时用尽力而为的 compare-and-swap回滚自身写入避免覆盖维护者的并发编辑回滚同时会取消暂存目标防止失败运行遗留的暂存候选进入之后的 commit成功时保存一份候选资料包candidate bundle包含源origin/mastercommit、源 skill blob ID、已评审 diff、完整候选文件、源反馈 ID 与 URL、落地证据范围、适配器判定、门禁结果工具绝不 commit、push、打开或合并 PR——推广动作留给运维人员通过正常仓库评审完成。六、评审适配器协议可审计的隔离契约两个评审适配器都是私有可执行文件通过标准输入输出与工具通信每个适配器从stdin接收有字节上限、带版本的 JSON 请求在stdout返回有字节上限且符合 schema的 JSON同字节可执行文件检查两个评审命令解析为逐字节相同的可执行文件时工具拒绝运行——这是最低限度的机械检查而主/次适配器确实由独立提供方或模型驱动属于部署运维方的责任文档在风险章节明确指出了这一边界access与tools字段是适配器作者承担的契约标记并非 OS 沙箱。6.1 子进程隔离评审子进程在清理后的环境scrubbed environment中 spawncwd指向私有运行目录而非仓库根目录并采用有界、感知中止的进程树清理。每个生产git/gh/门禁进程同样使用清理后的环境——防止 pre-push 钩子的路由变量无提示地重定向维护工具。6.2 非信任反馈包装nonce 机制反馈内容被包装在带随机数的块中untrusted-feedback nonce……/untrusted-feedback每个提示词都会指示模型将该块视为数据128 位 nonce 防止不受信任的正文伪造结束标签closing tag逃逸出包装块从而阻断提示注入路径。七、推广约定防陈旧覆盖的 draft PR 流程推广辅助工具promote helper是整个机制中唯一接触仓库的环节从刷新至origin/master的干净 checkout开始拒绝陈旧候选当当前 skill blob 与资料包中记录的源 blob 不一致即源技能已变化时拒绝应用候选——辅助工具绝不用陈旧的完整文件输出替换较新的SKILL.md运维人员此时重新运行维护分析或手动 rebase 该 diff 并重新评审候选应用仍然有效的候选后打开draft PR其正文列出源反馈 URL 或 ID、用作采纳证据的落地 commit 范围、发起该候选的运行、门禁结果、以及任何运维人员编辑原始适配器提示词与响应保持私有但仓库评审人会获得上述具体输入从而可以独立判断每条拟议规则是否确实来自已被采纳的人类反馈。八、机制所在位置与交接约定工具源码、适配器二进制、提供方凭据与每日调度器全部保留在维护者机器上不提交到本仓库。文档明确说明这是有意为之该机制只服务于由单个运维方维护的一项技能因此持续通过仓库评审来审查机制改动的成本高于提交工具及其历史的收益。如果机制将来移交给第二位维护者需要通过一篇后续 Agent Note修订本决策任何接手者都应从运维文档 docs/cookbook/maintaining-dsh-code-review.md 入手。值得注意的是配套的 cookbook 与 Agent Note 成对维护两者共享 i18n 配对一致性记录 docs/cookbook/maintaining-dsh-code-review.i18n.yaml中文版见 maintaining-dsh-code-review.zh.md。九、运维实操从候选 diff 到合并上线cookbook 文档 给出了操作员侧的完整实操细节与 Agent Note 互补。9.1 维护者收到什么操作员每天手动调用包装脚本使用 2 个 UTC 日的重叠窗口每周手动恢复运行使用 7 日窗口。工作流依次选择窗口内合并、且 merge commit 可从origin/master到达的 PR每日默认 2 个 UTC 日每周 7 日merge commit 不可达如父分支被 squash 的堆叠分支或超过250 个 commit 采集上限的 PR记录到skipped-pulls.json并跳过收集合并前带 commit 锚点的人工评审反馈行内评论与评审提交比较反馈时与最终落地的 PR patch不获取 PR 对话评论不把目标分支专有变更作为采纳证据两个独立配置的评审适配器先判定作者与采纳再对照当前技能分类主适配器起草完整修订版SKILL.md两适配器评审同一 diff阻塞发现循环直至双方批准工具声明成功前运行pnpm run doc-sync和pnpm run lint两个门禁。9.2 产物落盘位置每次运行的产物保存在操作员机器上保存的 diff、候选SKILL.md与提升 manifest 按时间戳命名存放于~/dsh-code-review-outputs/manifest 记录源 master commit 与 skill blob、源反馈 ID 与 URL、落地证据范围、适配器判定、门禁结果每个适配器的原始 I/O 留在私有临时目录其路径写入通知与~/Library/Logs/dsh-code-review-maintainer/下的每日日志维护 worktree 在每次运行后恢复为干净状态避免操作员直接在维护副本中编辑。9.3 操作员对候选 diff 的三选一决策某次运行产出候选时macOS 会发出带dsh-code-review-promote timestamp提示的通知。操作员必须根据 diff 本身作出判断而不是因为评审者已经批准就接受——最终决策权在操作员。检查要点清单膨胀、历史叙述、基于单次事件的无依据外推、与现有技能或权威文档的重复覆盖。ls ~/dsh-code-review-outputs/ # 所有历史候选 less ~/dsh-code-review-outputs/2026-07-16T02-00-00Z.diff less ~/dsh-code-review-outputs/2026-07-16T02-00-00Z.SKILL.md less ~/dsh-code-review-outputs/2026-07-16T02-00-00Z.manifest.json交叉核验后从三种处理方式中选择丢弃Discard删除保存的候选下一次运行会依据届时最新的技能重新考虑同一份反馈。rm ~/dsh-code-review-outputs/2026-07-16T02-00-00Z.{diff,SKILL.md,manifest.json}留待成批Batch更新很小时留待与后续候选合并源 skill 检查仍然适用若master先变化需重新运行分析或手动 rebase 并重新评审 diff。提升Promote在仓库的干净mastercheckout 中运行提升辅助工具它刷新master、验证当前 skill 与记录的源 blob 一致、应用保存的 diff 并创建 draft PR。skill 已漂移时停止绝不覆盖更新的指导。cd ~/path/to/deepseek-harness # clean master dsh-code-review-promote 2026-07-16T02-00-00Z操作员还应注意不要逐字提交适配器输出。提升过程中的小幅编辑——收紧措辞、移除只有结合源 PR 上下文才有意义的示例、把规则并入现有规则——是预期行为保留了工作流所依赖的评审人判断合并前应在分支上修订这些改动。9.4 无候选是常态只要每个非空分类阶段都至少产生一个有效适配器结果无候选就是最常见的情况。工具在每日日志中记录no candidate不发送通知避免提醒疲劳然后继续。文档特别强调没有技能更新的日子是工作流正确运行的标志而不是停滞。9.5 中断处理与交接错过每日运行2 日重叠窗口自动覆盖一次漏跑更长间隔通过DSH_CODE_REVIEW_SINCENd手动运行包装脚本来恢复。重叠窗口幂等已覆盖的指导归类为covered不会再次成为候选。适配器提供方中断工具拒绝两个命令逐字节相同的配置单批次 schema/id 校验失败则整批 fail-closed 并继续任一适配器在所有非空批次均无有效结果时运行失败、写失败记录并通知操作员——绝不把提供方中断折叠成无候选。交接新建后续 Agent Note要么把机制移入仓库要么记录新操作员的私有设置不暗中转交工具——单维护者风险正是交接必须留下书面决策的原因。十、考虑过的替代方案文档系统性地记录了对八种替代方案的否决理由这组决策本身也是理解机制边界的最好材料替代方案否决理由把工具放入本仓库单维护者作用域下仓库维护开销typecheck、lint、覆盖率、横切重构超过已提交源码与评审历史的价值未来移交时可重新考虑记录每条反馈产生时的 PR head需要持续运行的观察器、持久事件状态、重试与 force-push 协调定期维护用已评审 commit 证据并在证据过宽时 fail-closed持久化已处理 PR 游标重叠时间窗口扫描成本低且天然幂等游标状态反而引入恢复与漏事件问题每条新评论都触发运行一轮评审会产生大量相关评论且缺少判断采纳所需的最终产物把合并或讨论串解决视为采纳PR 可能在反馈被拒绝、被取代或刻意不解决的情况下合并自动创建或合并仓库改动工具需要先通过有用的周期输出积累可信记录应由维护者检查并经正常仓库评审推广从已修复的 bot 问题中学习来源契约限定为人类评审反馈作者类型在分析前过滤让同一评审人既当作者又作最终裁决独立判定能在不支持的概括进入技能前暴露问题十一、验收标准与实测观察从proposed/晋升到implemented/需要针对本仓库的真实端到端运行中观察到以下全部事实私有工具从刷新至origin/master的干净 detached checkout 运行要么报告没有候选项要么只生成 .agents/skills/dsh-code-review/SKILL.md 的 working-tree diff。2026-07-15 已观察扫描 62 个已合并 PR跳过 5 个merge commit 不可达或超过 250 commit 采集上限考虑 426 条人类反馈发现 0 个候选项。两个评审适配器独立配置不同提供方或模型无需用户干预完成 analyze/adopt/review 流程。2026-07-15 已观察不同主/次适配器约 8 分钟完成采纳与分析一次适配器 id 幻觉由批次级 fail-closed 处理未中止运行。调度器在无交互终端下触发工具候选 diff或无候选记录通过持久通知通道送达操作员。受控采集场景在反馈基线后向目标分支加入与反馈匹配的变更评审证据排除该目标分支专有变更同时保留后续由 PR 自身加入的变更。源 skill 改变后推广辅助工具拒绝候选仍有效的候选打开 draft PR含源反馈 ID、已采纳 commit 范围、发起运行、门禁与操作员编辑。至少一个候选 diff 由操作员检查并通过普通仓库 PR 评审推广到master——该 PR 是工作流能把已采纳反馈转化为已交付技能指导的直接证据。十二、风险边界机制承认的四个局限文档诚实列出了机制当前的局限引用它们有助于准确理解这套管线的适用前提基于 committer 时间戳推断因果关系反馈-commit 基线通过比较 GitHub commit 时间戳与反馈创建时间戳选出committer 时钟偏差与重写仍会留下误判采纳的残余窗口与 GitHub PR 事件流交叉比对可进一步收紧但超出定期工具的作用域。两个非候选项分类直接路由到excluded无争议轮次两个分类器都判不是候选但对原因如coveredvsspecific意见不一时条目被排除而非重估——因为双方一致认为它不会形成新的评审行为争议轮次不会改变结果。双评审人独立性是部署契约工具只能校验两个命令非逐字节相同无法验证两个包装层背后是不同的提供方或模型运维方必须配置独立的主/次适配器。尽力而为的 compare-and-swapPOSIX 上基于文件的 CAS 并非真正原子窗口为一个事件循环周期工具面向单用户定期维护真正并发的编辑器不在支持范围内。单维护者风险机制位于单台机器服务中断会完全停止技能维护直到操作员恢复或通过后续 Agent Note 完成移交。总结一套证据充分才更新的技能演进范式deepseek-harness 的这份 Agent Note 与其配套 cookbook 共同定义了一套可复制的技能维护范式把人工评审反馈 → 技能指导的转化从一次性、主观的审计变成周期性、可审计、默认不采纳的工程管线。其精髓可以概括为三点证据优先merge commit 可达性过滤、时间戳严格性校验、B/T/M 快照算法层层确保只有人类撰写、且确实在最终代码中落地的反馈才有资格进入下一阶段独立评审两个独立配置的适配器对作者、采纳、分类做三次交叉判定分歧有界重估单点故障通过批次级 fail-closed 隔离人机分工工具负责证据收集、隔离与门禁操作员负责最终判断与推广——工具绝不自动合并技能更新始终以小型、可审查、可回退的 PR 形式进入仓库。对于任何维护评审技能/检查清单类知识资产的团队这套机制在幂等扫描、fail-closed 判定、非信任输入隔离与防陈旧覆盖方面的设计都是一份高参考价值的工程样本。【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
