DeepSeek Harness 开源的 11 个 Skill 文件，隐藏着一套真实可落地的工程规范，其体现出的工程纪律与研发流程价值，甚至超过框架本身。核心内容：1. 这 11 个 Skill 文件是 DeepSeek 团队内部真实使用的工程规范与开发标准2. 11 个 Skill 的能力分类，包括质量门禁、代码治理、文档工程、国际化与协作流程等3. 工程规范本身的稀缺性，以及此次开源所展示出的工程纪律参考价值
DeepSeek Harness 发布时，很多人的关注点都集中在框架本身，比如插件架构、Agent 循环和工具调用能力。但很少有人留意到仓库里一个并不起眼的目录：
.agents/skills/
这个目录中放着 11 个 Skill 文件，而它们并不是演示性质的示例配置，而是 DeepSeek 内部真实在使用的工程规范。也就是说，他们把团队日常如何做 Code Review、如何管理 PR、如何保障代码质量的那套实践方法，直接以开源方式公开出来了。
这件事的参考价值，可能比 Harness 这个框架本身还要大。
原因也很简单：框架并不稀缺，真正稀缺的是成熟且可执行的工程规范。一个团队能否长期稳定地产出高质量代码，决定因素往往不是选用了什么技术框架，而是背后那套看不见但持续发挥作用的工程纪律。DeepSeek 这次，等于把自己的工程体系直接摊开给外界看。
我把这 11 个 Skill 逐一拆解了一遍，下面说说我看到的重点。
首先体现出来的是质量门禁机制。dsh-code-review 这个 Skill 明确给出了代码审查的完整判断标准：Review 不能只停留在“代码能不能跑通”这一层，还要进一步核对接口两端的契约是否一致、生命周期管理和并发处理是否足够安全，以及每一层抽象是否真的存在实际使用者。更关键的是，它把审查优先级讲得非常直接：一个简洁但有证据支撑的 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 是我认为最有意思的一个 Skill。它专门处理“思维链泄漏”问题，也就是开发者在写代码注释或技术文档时，无意间把 AI 推理过程中的痕迹保留了下来。比如引用了只存在于设计讨论中的决策编号，使用“之前是”“现在不再是”这类变更叙事，或者写出“审查者确认了”这种面向 Reviewer 的辩护式表达。对于后来阅读代码的人来说，这些信息基本没有直接价值，但在 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、AI 编程工具或工程效能平台的团队来说，这 11 个文件的参考意义，可能比很多泛泛而谈的论文和方法论文章都更高。因为它们不是抽象理论，而是 DeepSeek 自己正在使用的真实工程规范。一个拥有 9.5 万 Star 项目的工程纪律，如今就摆在这里，值得每个做研发体系、代码质量和 AI 工程化的人认真拆解。
地址：https://github.com/deepseek-ai/deepseek-harness/tree/master/.agents/skills
最后，欢迎大家加入我的 AI 社群，整体内容非常超值，性价比也很高。今年已经录制了近 50 期视频教程，覆盖 Agent Skills 系列课程、各类 AI 落地应用场景实战教程、很多有趣的 Skill 玩法，以及丰富的 AI 副业案例。目前副业案例库已经累计拆解了 70 多期内容。
登录查看剩余 70% 内容