95%的用户没发现！DeepSeek Harness竟藏11个高级工程技巧

这两天研究 DeepSeek Harness，我原本一直把注意力放在四种 Agent 模式、Cordis、自修改 Runtime、Subagent 这些新功能上。

结果继续翻仓库时，我在一个很不起眼的目录里发现了另一批东西：

.agents/skills/

里面没有演示性质的“写诗 Skill”“帮我总结 Skill”，而是整整 11 个直接服务于 DeepSeek Harness 项目开发的工程 Skill：

dsh-archive-agent-notesdsh-code-reviewdsh-doc-site-syncdsh-doc-standardsdsh-find-simplificationsdsh-merging-stacked-prsdsh-pre-push-checksdsh-prose-standarddsh-translate-docsdsh-trim-cot-leakagerecord-browser-gif

我把这些 Skill 一个个打开以后，最大的感受是：

DeepSeek 开源的不只是 Harness 代码。

连他们怎样要求 Agent 做 Code Review、怎样决定 Push 前跑哪些测试、怎样验收 GUI、怎样减少过度设计、怎样维护文档，甚至怎样清理 Agent 写进仓库里的“思考痕迹”，都放出来了一部分。

换句话说，这 11 个 Skill 更像一套：

工程规范Review 方法Quality GatesAgent SOP

尤其值得研究。

因为 Skill 真正有价值的地方，从来不只是让 AI“多会一个功能”。

它还可以告诉 AI：

一件事情到底做到什么程度，才算真正做完。

一、先说清楚：这 11 个 Skill 真的会被 DSH 识别

DeepSeek Harness 自己有完整的 Skill 文件系统。

默认情况下，它会扫描多个位置，其中就包括项目根目录下的：

/.agents/skills

所以仓库里的这 11 个目录，并不是随手存档的几份 Markdown。

每个 Skill 里面都有自己的 `SKILL.md`，包含名称、使用时机以及真正的工作规则。

而且 DSH 对项目 Skill 还做了目录监控。

也就是说，你修改 Skill 后，Harness 可以重新发现变化，不需要每次把整个项目重新安装一遍。

这其实已经透露出 DeepSeek 对 Skill 的理解：

Prompt只是临时告诉 AI 一次怎么做Skill则把团队长期做事的方法沉淀下来

不过有一点必须提前说明。

这 11 个 Skill 很多都深度绑定 DeepSeek Harness 自己的仓库结构，例如：

AGENTS.mdAgent NotesCordisDSH PackagesQuality Gates双语文档体系GitHub PR Stack

所以不能简单理解成：

把 11 个文件复制到任何项目，就直接获得 DeepSeek 同款工程能力。

真正值得抄的，是里面的方法。

二、Code Review：DeepSeek 不让 Agent 只挑代码格式问题

先看最重要的：

dsh-code-review

普通情况下，我们给 AI 一句：

帮我 Review 这个 PR。

最后很容易得到一堆：

这里变量名可以优化这里可以加注释这里函数稍微有点长这里风格不统一

看起来说了很多，真正影响上线的问题却可能一个没发现。

DeepSeek 在这个 Skill 里直接规定了 Review 的优先级。

它要求 Agent 优先看：

正确性生命周期并发安全接口契约资源释放权限绕过测试证据模型真正看到的 Prompt 和 Tool文档与实现是否一致

甚至明确告诉 Reviewer：

一个证据充分的阻塞问题，比列出一堆无关痛痒的小毛病更有价值。

这个思路我很喜欢。

举个例子。

假设一个 PR 新增了后台任务功能。

普通 Review 可能主要看：

代码能不能跑类型有没有错测试绿不绿

这套 Skill 会继续追问：

任务启动后谁拥有它？Session 结束时有没有清理？取消过程中会不会留下进程？回调异常会不会影响主流程？插件卸载以后注册项有没有撤销？其他调用路径能不能绕过权限检查？

如果这个改动会影响模型，还会继续检查：

模型最终看到的 Tool Schema 是什么？Prompt 有没有变化？错误信息模型能不能正确理解？Snapshot 有没有覆盖这种变化？

这已经很接近真正资深工程师做架构 Review 的思路。

所以第一个值得抄的经验就是：

不要只给 Agent 一个“Code Review”角色，要把“什么才值得 Review”写进 Skill。

三、Pre-push Checks：AI 写完以后，不允许一句“测试通过”就结束

第二个很实用：

dsh-pre-push-checks

它负责 Push 代码之前的质量检查。

我原先以为 DeepSeek 会要求：

pnpm testpnpm lintpnpm build

全部跑一遍。

结果恰好相反。

它强调的是：

找到能够证明这次改动正确的“最小充分证据”。

比如 Agent 只改了：

packages/foo/

那就先找到真正覆盖这个 Package 的测试。

如果只改文档，就跑文档同步和对应检查。

如果改变的是 CLI、模型输出、编辑器行为，就跑负责这些行为的 Snapshot 或真实场景测试。

如果动了构建产物、Package Export、Worker 或 Bin，再增加：

buildhygiene check真实产物 smoke test

真正涉及模型 Provider 行为时，才考虑需要凭据的 E2E。

这解决了 AI Coding 一个很现实的问题。

AI 特别喜欢两种极端：

一种是什么都不测。

另一种是：

为了证明改了一行代码没问题，把整个仓库测试跑 40 分钟。

DeepSeek 给 Agent 的要求则是：

先分析 Diff判断影响范围找到能证明这个行为的测试只增加真正必要的检查再 Push

而完整平台矩阵和 exhaustive coverage，则交给 CI。

这其实特别适合我们自己的 Agent。

比如给 Claude Code、Codex 或 Hermes 写一个 `pre-push` Skill，以后再也不用反复提醒：

改完以后记得测试。

Skill 可以直接规定：

先判断这次改动影响了什么，再选择测试。

四、最让我意外：改 GUI 的 PR，Agent 必须录一个真实 GIF

11 个 Skill 里面，我觉得最有传播力的是：

record-browser-gif

名字听起来挺普通。

打开以后规则非常严格。

DeepSeek 要求：

涉及用户可见 GUI 行为变化的 PR，必须带一个真实演示 GIF。

关键在“真实”两个字。

这个 GIF 需要来自：

这个 PR 真正的代码真正启动的 Server真实浏览器真实 API Key真实 Model Round

不能为了方便偷偷换成：

FixtureMock TransportSynthetic EventTest-only Hook

甚至还要求记录：

演示对应哪个 Commit SHA运行的是哪一棵代码树使用了什么模式有没有真的调用模型

假设 Agent 改了一个新的“审批”按钮。

过去我们很容易接受：

Agent：功能已经实现。测试全部通过。

DeepSeek 这套流程会变成：

代码完成构建真实 PR 分支启动真实 DSH真实模型跑一轮浏览器完成实际操作截图关键状态编码成 GIF人工再检查 GIF把 GIF 放进 PR

而且一次录制就是一条完整证据链。

如果中途录坏了，不能从第一次运行拿两张图，再从第二次运行拿两张图，最后拼出一个看起来成功的 GIF。

需要重新从干净环境跑。

这个设计非常值得借鉴。

因为 AI 时代最大的麻烦之一是：

Agent 会非常自信地告诉你“已经完成”。

GIF 给出的是另一种证据：

让我直接看看它到底有没有完成。

以后做前端 Agent、浏览器 Agent、桌面 Agent，其实完全可以照搬这种思路。

五、AI 太爱写代码？DeepSeek 专门做了一个 Skill 让它“主动删东西”

接下来这个特别有意思：

dsh-find-simplifications

它干的事情可以用四个字概括：

寻找简化。

现在 Coding Agent 一个非常明显的问题，就是写代码实在太快。

遇到一个问题：

加一个接口

又遇到一个边界：

再加一层 Adapter

未来也许要用：

再加三个配置

担心以后不够通用：

提前抽象一个 Manager

一个人类团队可能半年才积累起来的复杂度，Agent 几天就能给你造出来。

DeepSeek 干脆为这个问题做了一个 Skill。

它会要求 Agent 专门寻找：

没有生产消费者的 Public API测试和文档才在使用的功能两份重复表示同一事实的数据为了“未来也许需要”提前建的抽象已经没有意义的兼容路径重复 Package重复生命周期状态自己手搓、但成熟依赖已经能解决的基础设施

其中还有一个我很喜欢的词：

Speculative Generality

也就是“投机式通用化”。

现在只有一个场景，却提前设计一个可以支持十种场景的抽象。

AI 特别容易犯这种毛病。

所以 DeepSeek 的 Agent 工作流里，居然已经出现了一个专门的角色：

Agent 写代码Agent 再回来问：“这些东西里面，有什么其实可以删？”

我觉得这是 11 个 Skill 里面最值得普通用户学习的一个思想。

强大的 Coding Agent 并不只需要：

write-code

还应该有：

delete-complexity

六、还有个“CoT 清理”Skill：专门防止 Agent 把思考现场写进代码库

这个名字很容易被误解：

dsh-trim-cot-leakage

这里的 CoT Leakage，并不是在检测 DeepSeek 模型内部隐藏推理有没有泄漏。

它关注的是另一种很常见的 AI 污染：

Agent 把自己完成任务时的“过程视角”，写进了正式仓库。

例如下面这种注释：

最初我们采用方案 A，后来 Reviewer 认为不合适，所以这个版本改成方案 B。

或者：

decision 7audit C2design §4.7v3 先这样后面的 PR 再处理

又或者：

原来这里……现在我们……这次修改……Reviewer 确认……

这些内容在当前 Coding Session 里看起来都能理解。

过半年以后，新维护者只有 Git 仓库，没有：

当时的 ChatPR Review 上下文未提交设计稿Agent 的任务计划

于是很多引用已经彻底变成谜语。

DeepSeek 给这个 Skill 的判断方法非常简单：

一个只有当前 HEAD 仓库的读者，能不能独立解析和验证这句话？

如果不能，就把真正有用的事实留下，把任务过程删掉。

比如：

原来方案 A 有问题，Reviewer 要求改成 B，所以现在这里使用 B。

应该更接近：

这里必须使用 B，因为 A 在并发取消时无法保证资源释放。

后一句才是未来维护者真正需要知道的东西。

这个 Skill 其实解决了一个非常新的工程问题：

AI 写代码以后，代码库正在开始堆积“机器写作垃圾”。

以前我们担心垃圾代码。

以后还得担心垃圾解释。

DeepSeek 已经开始专门治理这一层了。

七、文档也有完整 SOP，连翻译 Skill 都规定“AI 不能自己调用”

继续往下，还有四个与文档有关的 Skill：

dsh-doc-standardsdsh-prose-standarddsh-doc-site-syncdsh-translate-docs

这套东西看下来，会发现 DeepSeek 对“让 AI 写文档”同样没有完全放任。

`dsh-doc-standards` 会要求 Agent 先判断：

这篇到底是 Tutorial 还是 Reference？应该放到文档树哪一层？这里是不是解释得过深？细节是不是应该交给下一级页面？有没有重复文档？有没有超过文档 Budget？双语文档是不是一起维护？

`dsh-prose-standard` 则负责文字质量。

它要求保留真正有长期价值的内容：

ContractInvariant前置条件后置条件兼容承诺重要设计理由

代码一眼就能看出来的东西，别再用一段注释重新翻译。

最有意思的是：

dsh-translate-docs

它的 Frontmatter 里专门写了：

disable-model-invocation: trueuser-invocable: true

意思很直白：

Agent 自己不能看到“需要翻译”就擅自启动这套扩展工作流。

只有用户明确点名调用时才使用。

这说明 Skill 已经开始承担另一类职责：

不仅规定“怎么干”还规定“谁有权决定要不要干”

这就已经有一点 Agent Governance（智能体治理）的味道了。

八、真正值得抄的，是把“口头要求”变成 Agent 的固定 SOP

剩下几个 Skill 同样很有 DeepSeek 项目的特点。

例如：

dsh-merging-stacked-prs

专门处理多个相互依赖的 Stacked PR。

它会要求 Agent核实真正的 PR Stack、Base、Head、CI 和 Review 状态，再按照 GitHub 的 Stack 机制合并。

甚至明确禁止为了省事直接裸用：

git push --force

涉及历史重写，要使用 Lease 保护，防止把别人刚推上去的提交覆盖掉。

还有：

dsh-archive-agent-notes

专门管理项目长期积累的 Agent Notes。

因为 Agent Notes 越积越多，同样会形成另一种上下文垃圾。

这个 Skill 会判断：

这个设计理由以后还有没有价值？是不是已经被新的实现替代？未来还可能帮助 Agent 避免一个错误吗？应该继续留在活跃区？冻结进 Archive？还是已经可以彻底删除？

它甚至明确提醒：

不能因为一份 Note 很旧、很长，就自动认定应该归档。

判断标准是它还有没有未来决策价值。

所以把这 11 个 Skill 放在一起看，我觉得 DeepSeek 真正给出的答案已经很清楚了。

以前一个团队管理 AI，可能靠的是：

“记得认真 Review。”“写完一定要测试。”“UI 改了记得截图。”“别过度设计。”“注释写清楚一点。”“Push 前检查一下。”

全是口头要求。

Agent 换一个 Session，很可能又忘了。

Skill 的做法是：

Code Review→ 一个 SkillPre-push→ 一个 SkillGUI 验收→ 一个 Skill复杂度治理→ 一个 Skill文档规范→ 一个 SkillPR 流程→ 一个 Skill

只要 Agent 进入相应场景，就让它加载同一套团队 SOP。

这可能才是这 11 个 Skill 最值得我们照抄的地方。

如果自己正在用 Claude Code、Codex、Hermes 或 DSH，我觉得完全可以从三个最简单的 Skill 开始：

my-code-reviewmy-pre-push-checksmy-ui-verification

不要一上来写 30 个。

先把团队天天重复说的三句话，变成三份固定规则。

例如一个最简单的项目 Skill，结构其实就可以从：

.agents/└── skills/└── my-code-review/└── SKILL.md

开始。

核心也不需要写得特别长：

---name: my-code-reviewdescription: Use when reviewing code changes before merge.# Code Review优先检查：1. 正确性和边界条件2. 安全与权限3. 生命周期和资源释放4. 是否存在重复或不必要抽象5. 测试是否真正覆盖本次改动报告问题时给出：位置、影响、证据和修复建议。不要用大量代码风格小问题淹没真正的阻塞问题。

接着让实际项目经验不断把它补完整。

这比天天换一套“超级提示词”更有长期价值。

DeepSeek Harness 仓库里的这 11 个 Skill，真正让我看到的也正是这一点：

Skill 不只是教 Agent“会做什么”。

更重要的是，把一个团队长期积累的工程经验变成：

Agent 每次都知道“怎样才算做好”。

当 Coding Agent 越来越能写的时候，下一阶段真正稀缺的东西，很可能已经从“写代码能力”变成了“工程纪律”。

而 DeepSeek 把自己的这部分纪律，已经悄悄放进了 `.agents/skills/`。