DeepSeek 怎么养 skill：AI 初审，人工拍板

在多数开源项目里，skill 的命运是「写完即冻结」：发布一版，偶尔想起来再改两笔，改得对不对全凭记忆。DeepSeek 开源的 agent 基础设施项目 deepseek-harness（GitHub 上的 deepseek-ai/deepseek-harness，MIT 协议）给自家代码评审技能 dsh-code-review 配了一套不一样的机制：把 skill 当成活文档，由一名指定操作员驱动周期性维护工作流，让人工评审反馈持续沉淀为 skill 更新，每一批更新都以小型 PR 的形式进入仓库，而不是攒一次大规模审计。本文整理自该仓库 docs/cookbook 下的官方维护手册，讲清这套机制怎么运转、人在哪里拍板。

为什么按周期小步更新

维护流水线：从选 PR 到门禁的五步

手册开篇就把定位说清楚：这份实操指南既是操作员和接任者的入口，也帮仓库贡献者理解，为什么 skill 更新总是以小型周期 PR 的形式出现。工作流本身由仓库内 2026 年 7 月提出的一份 Agent Note（人工评审 skill 维护流程）规定，整套机制的原料只有一个：合并前真人评审留下的、带 commit 锚点的意见，有没有真的落进代码。

操作员每天手动调用一次包装脚本，使用 2 个 UTC 日的重叠窗口；每周再手动补一次 7 日窗口的恢复运行。每轮运行做五件事：

选 PR。 只选窗口内合并、且合并 commit 可以从 origin/master 到达的 PR（每日运行选 2 个 UTC 日，每周运行选 7 日）。合并 commit 无法到达的（例如父分支被 squash 的堆叠分支），或超出 250 个 commit 获取上限的 PR，会记录到 skipped-pulls.json 然后跳过，不会中止本次运行。
收集反馈并比对 patch。 工作流收集合并前带 commit 锚点的人工评审反馈，包括行内评论和评审提交，再对照反馈提出时与最终落地 patch 的差异判断采纳情况。PR 会话评论不在收集范围，因为 GitHub 目前的状态无法为这类评论提供能抵抗 force-push 的反馈时基线；只存在于目标分支的变更也不会被当作采纳证据。
双适配器独立分类。 两个独立配置的评审适配器，先各自对每个条目的作者、更改是否采纳了这条反馈做分类；只有双方一致认定已采纳的条目，才交给当前 skill 判断这条指导是否已经被覆盖。
起草与互审。 主适配器起草完整修订版 SKILL.md，两个适配器评审同一份 diff；只要仍有阻塞性问题，循环就继续，直到双方批准。
门禁收尾。 工具声明成功之前，会对候选版本运行 pnpm run doc-sync 和 pnpm run lint。

产物与留痕

每轮运行的产物都保存在操作员本机：保存的 diff、候选 SKILL.md 和提升 manifest（元数据清单）按时间戳命名，放在 ~/dsh-code-review-outputs/ 下。manifest 记录源 master commit 与 skill blob、源反馈 ID 和 URL、已落地的证据范围、适配器裁决和门禁结果；每个适配器的原始输入输出留在私有临时目录，路径会写进通知和 ~/Library/Logs/dsh-code-review-maintainer/ 下的每日日志。维护 worktree 在每次运行后都会恢复干净状态，避免有人直接在维护副本里编辑。这套留痕的实际效果是：任何一条新 skill 规则，都能追回到具体反馈和具体 commit。

操作员怎么处置候选 diff

操作员三分支决策：丢弃、留待成批、提升

某轮运行产出候选版本时，macOS 会弹出一条带 dsh-code-review-promote <时间戳> 提示的通知。手册给操作员的第一条纪律是：根据 diff 本身作出判断，不要因为「评审者已经批准」就直接接受，维护者约定把最终决定权交给操作员。判断时看四件事：检查清单是否膨胀、是否混入历史叙述、是否根据单次事件做出无依据的外推、是否与现有 skill 或权威文档重复。提升 manifest 会把每条拟议规则映射到源反馈和已落地证据，适配器的详细输入输出在本次运行的私有临时目录（路径见日志），操作员至少要抽查一条：链接的人工评论是否真的支持新增规则，链接的 PR 是否真的采纳了它。

然后从三种处理方式里选一种：

丢弃。 删除保存的候选版本。下一次运行会依据届时的当前 skill，重新考虑同一份反馈。
留待成批处理。 更新很小的时候，把候选留着和后续版本合并；源 skill 检查仍然适用，如果 master 先发生变化，就重新运行分析，或者手动 rebase 后重新评审 diff。
提升。 在仓库干净的 master checkout 里运行提升辅助工具：刷新 master，验证当前 skill 与 manifest 记录的源 blob 一致，应用保存的 diff，创建一份 draft PR。PR 正文列出原始反馈的 URL 或 ID、已落地的 commit 范围、发起这次更改的运行、检查结果以及操作员编辑。如果 skill 已发生漂移，工具会停下来而不是覆盖更新后的指导；操作员仍要在 GitHub 上评审这份 PR，决定合并还是关闭。

手册还划了一条红线：不要逐字提交适配器输出。提升过程中做小幅编辑是预期行为，例如收紧措辞、移除只有结合源 PR 上下文才有意义的示例、把新规则并入现有规则。这些编辑保住了工作流依赖的「评审者判断」，合并前应在分支上修订到位。

没有候选版本，也是正常状态

只要每个非空分类阶段都至少产生一个有效的适配器结果，某轮运行没有候选版本就是常见情况：工具在每日日志里记一笔「无候选版本」，不发通知（避免提醒疲劳），然后继续。某天没有 skill 更新，说明工作流运行正常，而不是停滞。

三类中断的应对

机制运行在一台机器上，手册要求操作员随时能处理三类中断：

错过每日运行。 2 日重叠窗口会自动覆盖一次漏跑；更长的间隔可通过设置 DSH_CODE_REVIEW_SINCE=<天数> 手动运行包装脚本来恢复。重叠窗口是幂等的：当前 skill 已包含的指导会被归类为已覆盖，不会再次成为候选项。
适配器提供方中断。 当两个评审命令解析为逐字节相同的可执行文件时，工具会拒绝运行。某个批次的适配器响应未通过 schema 或 ID 校验时，该批次整体 fail-closed，其中每个条目都标记为不明确，运行继续，原始输出保留以便调试。如果任一适配器在某项操作的所有非空批次中都未产生有效结果，本次运行就失败、写入失败记录并通知操作员；它绝不会把提供方完全中断折叠成「无候选版本」。
交接给另一名维护者。 新建一篇取代当前记录的 Agent Note：要么把机制移入仓库，要么记录新操作员的私有设置。不要暗中转交工具；Agent Note 的风险章节已把「单维护者关键人风险」列为交接必须记录决策的原因。