DeepSeek Harness 真正的宝藏，可能不是 Agent，而是这个不起眼的目录

DeepSeek Harness 发布的时候，大家的注意力都在框架本身：插件架构、Agent 循环、工具调用。但很少有人注意到仓库里藏着一个不起眼的目录：

.agents/skills/

这个目录里放了11个 Skill 文件，每一个都是 DeepSeek 内部真实在用的工程规范。换句话说，他们把自己团队日常怎么做 Code Review、怎么管理 PR、怎么保证代码质量的那套方法论，直接开源了。

这件事的价值，可能比 Harness 框架本身还大。

为什么这么说？因为框架到处都是，好的工程规范却极其稀缺。一个团队能不能持续产出高质量的代码，靠的从来不是用了什么框架，而是背后那套看不见的工程纪律。DeepSeek 这次相当于把自己的工程纪律摊开给你看了。

我逐个拆了一遍这11个 Skill，说说我看到了什么。

第一类是质量门禁。dsh-code-review 这个 Skill，定义了他们做代码审查的完整标准。它要求审查者不只是看代码对不对，还要追踪接口两侧的契约是否匹配、生命周期和并发是否安全、每个抽象是否有真实的消费者在用。特别值得注意的是，它明确要求：一个简短的、有实证的 blocker，比一堆 nit 有价值得多。这说明他们的 Review 文化是追求深度，不是追求覆盖面。

dsh-pre-push-checks 则定义了推送前的检查策略。有意思的是，它并不要求你每次都跑全量测试，而是要求你根据改动范围，选择最小但足够覆盖的检查集。这个思路很务实：全量测试交给 CI，本地只跑跟你改动相关的部分。但前提是你得能判断“相关”是什么，这本身就是一种工程能力。

第二类是代码治理。dsh-find-simplifications 专门用来发现过度设计。它列出了一系列判断标准：一个公开方法没有生产环境的消费者、两个表示层在镜像同一个事实、一个 seam 的方法没有任何调用者在用、一个包只为测试代码存在却增加了发布开销。每一条都很具体，不是那种空泛的“保持简单”。它甚至鼓励引入外部依赖来替换手写实现，只要那个依赖足够成熟。这跟很多团队“能自己写就不引入依赖”的惯性思维完全相反。

第三类是文档工程。dsh-doc-site-sync 管理文档网站的同步发布，dsh-doc-standards 定义文档该写在哪里、写多少、怎么组织，dsh-prose-standard 则规定了文字本身的质量标准。这三个 Skill 组合在一起，构成了一套完整的文档治理体系。最让我印象深刻的是 prose-standard 里的一句话：写够保留契约所需的内容，然后删掉推理过程、重复和修饰。这是一种极其克制的写作哲学，跟大多数团队“文档越多越好”的想法截然不同。

第四类是翻译和国际化。dsh-translate-docs 定义了一套双语文档的维护工作流。它不是简单地“翻译一下”，而是建立了一个完整的配对机制：英文 foo.md 和中文 foo.zh.md 必须保持同步，有专门的一致性校验工具，有术语表约束，有结构对齐检查。这套东西的严谨程度，说明 DeepSeek 在认真对待中英文文档的同等权威性。

第五类是 AI 特有的工程问题。dsh-trim-cot-leakage 是我觉得最有意思的一个。它专门处理“思维链泄漏”，就是那些在写代码注释或文档时，不小心把 AI 推理过程中的痕迹留下来的情况。比如引用了一个只在设计会话中存在的决策编号、用了“之前是”“不再是”这种变更叙事、或者写了“审查者确认了”这种面向审查者的辩护。这些东西对读代码的人来说完全没有意义，但在 AI 辅助编程的场景下特别容易出现。DeepSeek 专门为此建了一个 Skill，说明他们已经在大规模使用 AI 写代码，并且踩过这个坑。

第六类是协作流程。dsh-merging-stacked-prs 定义了如何合并一组有依赖关系的 PR 栈。它强制要求使用 GitHub 原生的 Stacked PR 功能，禁止手动逐个合并再重定向。这看起来是个小事，但在多人协作的大型项目里，PR 栈的管理混乱是非常常见的问题。

最后一个特别的是 record-browser-gif。它要求每个改变了用户可见 GUI 行为的 PR，都必须附带一个从真实服务器录制的 GIF 演示。不是截图，不是描述，是一个可验证的、带有确切 commit SHA 的动态录屏。这个要求把“我改了 UI”这件事从一句话变成了一个可审计的证据链。

把这11个 Skill 放在一起看，你会发现一个清晰的工程哲学：

一切可以被规范化的东西，都应该被规范化，而且这个规范应该是可执行的、可验证的，而不只是写在 wiki 里的一段文字。

这些 Skill 本质上就是给 Coding Agent 用的 SOP。它们告诉 Agent：做 Code Review 的时候该关注什么、推代码之前该检查什么、发现过度设计该怎么判断、写文档该遵循什么标准。每一个都足够具体，具体到可以直接执行。

对于正在做 Coding Agent 或者工程效能工具的团队来说，这11个文件比任何一篇论文都有参考价值。因为它们不是理论，是 DeepSeek 自己在用的东西。一个9.5万 Star 的项目背后的工程纪律，现在就摆在那里，等你去拆。