查看: 10|回复: 0

DeepSeek开源了自己的工程SOP,这才是Harness真正的宝藏。

[复制链接]

16

主题

1

回帖

50

积分

注册会员

积分
50
发表于 4 小时前 | 显示全部楼层 |阅读模式

DeepSeek开源了自己的工程SOP,这才是Harness真正的宝藏。

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 的项目背后的工程纪律,现在就摆在那里,等你去拆。

传送门:github.com/deepseek-ai/deepseek-harness/tree/master/.agents/skills

#科技先锋官##How I AI##DeepSeekHarness发布#


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关注公众号

相关侵权、举报、投诉及建议等,请发 E-mail:2776601884@qq.com

Powered by Discuz! X5.0 © 2001-2026 Discuz! Team.|青ICP备2025004122号-1

在本版发帖
关注公众号
返回顶部