这周 AI 编程圈的人，大概都被 DeepSeek Harness 刷过屏。
8 月 13 号晚上，DeepSeek Harness 团队的崔添翼发了一条微博：以 MIT 协议开源发布，「目前的版本还很不完善，请大家多提提意见」。微博接下来几天的剧情大家都看到了：star 数猛涨，架构被逐层拆解，保姆级安装教程铺满知乎和 B 站，连「跟 Codex 谁更强」的对比都打了好几轮。
该聊的差不多都聊完了。但热闹里有一条帖子，值得单独拎出来。
8 月 15 号，有博主发了篇《DeepSeek 开源了自己的工程 SOP，这才是 Harness 真正的宝藏》，五百多赞、四百多转发。评论区画风和其他讨论帖完全不一样：没人吵 DSH 好不好用，满屏都是「@我的印象笔记」「@我的Notion」「mark，很珍贵」，还有人直接问——这些东西能不能装到别的编程工具里用？微博
让这么多人忙着收藏的，是 Harness 仓库里一个几乎没出现在安装教程里的目录：.agents/skills/。
这个目录里装的是什么
按社区的拆解，.agents/skills/ 里放了 11 个 Skill 文件。微博先给不熟悉这个概念的朋友补一句：Skill 本质上是一份写给 AI 看的 markdown 版 SOP。它不教 AI「这段代码怎么写」，而是规定「做这类事必须按什么流程、什么标准来」。Skills 机制本身不新鲜，Claude Code、Codex 这些主流工具都有类似设计。
稀罕的是这 11 个文件的内容。按博主的说法，这是 DeepSeek 内部真实在用的工程规范——怎么做 Code Review、推代码前查什么、文档写多少算够、双语翻译怎么对齐，全被写成了可直接执行的 Skill。
「内部真在用」这一点，仓库外面没法验证。但看内容细节，这不像是为了开源临时摆出来的样板间。
拆开看，确实有点东西
把社区流出的 Skill 逐个过一遍，大致可以归成六类：
第一类是质量门禁。dsh-code-review 定义了完整的代码审查标准：不只看代码对不对，还要追接口两侧的契约是否匹配、生命周期和并发是否安全、每个抽象是否有真实消费者在用。dsh-pre-push-checks 则规定推送前的检查策略。
第二类是代码治理。dsh-find-simplifications 专门用来揪过度设计，判断标准列得非常具体：一个公开方法没有生产环境的消费者、两个表示层在镜像同一个事实、一个包只为测试代码存在却增加了发布开销。
第三类是文档工程，三个文件：dsh-doc-site-sync 管文档站的同步发布，dsh-doc-standards 规定文档写在哪、写多少，dsh-prose-standard 管文字本身的质量。
第四类是双语文档同步。dsh-translate-docs 不是「顺手翻译一下」，而是要求英文 foo.md 和中文 foo.zh.md 配对维护，有术语表约束和一致性校验。
第五类最特别，是 AI 特有的病：dsh-trim-cot-leakage 专门清理「思维链泄漏」——AI 写代码注释和文档时，不小心把推理痕迹留下来的问题。
第六类是协作流程。dsh-merging-stacked-prs 强制用 GitHub 原生的 Stacked PR 功能合并依赖 PR 栈；record-browser-gif 要求每个改了 GUI 行为的 PR，必须附一段从真实服务器录制的 GIF，带着确切的 commit SHA。
六类里，有三个细节值得划重点。
一是 dsh-code-review 里那条：「一个简短的、有实证的 blocker，比一堆 nit 有价值得多」。微博做过代码审查的都懂，review 变成挑刺大赛有多容易，这条标准直接把审查文化往深度上拧。
二是 dsh-pre-push-checks 不要求每次跑全量测试，而是根据改动范围选「最小但足够覆盖」的检查集，全量交给 CI。全量测试跑一小时的痛，谁跑谁知道。
三是 dsh-trim-cot-leakage。它列举的泄漏痕迹包括：引用只在设计会话里存在的决策编号、用「之前是」「不再是」这种变更叙事、写「审查者确认了」这种面向审查者的辩护。微博能专门给这种事立一个 Skill，说明 AI 辅助编程在他们内部已经是日常，而且坑踩得足够多。
为什么说它比框架更值钱
框架到处都是，工程纪律稀缺。
Harness 火了之后，讨论大多围着架构转：一切皆插件、Cordis 微内核、四种运行模式。知乎这些当然重要，但对大多数不打算魔改框架的人来说，看个热闹也就过去了。而工程规范不一样——一个团队能不能持续产出能维护的代码，靠的从来不是用了哪个框架，而是这套看不见的纪律。DeepSeek 这次相当于把自己团队的工程纪律摊开给你看，这在行业里几乎没有先例。
而且这不是孤例。今年 4 月，Google Cloud 一位 AI 总监开源过一个 AI 编程 Skills 仓库，把谷歌软件工程实践做成了 19 项 SOP；8 月上旬，Rust 项目也给 AI 贡献立了新规——AI 可以帮你看代码，但不能替你写，AI 代码要过更高的门槛。微博知乎方向是一致的：代码生成的速度已经卷到头了，接下来的瓶颈是「管不管得住」。
不装 Harness，也能把它搬回家
先泼两盆冷水。
第一，这些规范是贴着 DeepSeek 自己的仓库场景长出来的，Stacked PR、双语文档流这些东西，和你的项目未必匹配，别整份照抄。第二，Harness 本身还是 v0.1 开发者预览版，接口随时可能变，仓库内容也会更新，现在存下来的快照未必是最终版。知乎
但好消息是：这些文件就是 markdown，思想是通用的。主流工具现在都有「项目级指令文件」机制——Claude Code 的 CLAUDE.md 和自定义 skills 目录、Cursor 的 .cursorrules、Codex 的 AGENTS.md，社区已经在往统一的 agents.md 规范上收敛。知乎这 11 个文件在 Harness 里干的事，换个壳基本都能搬。
分三档给个建议：
个人开发者，先看三个就够：dsh-code-review、dsh-find-simplifications、dsh-trim-cot-leakage。把里面的标准改写成你自己项目的语言，塞进 CLAUDE.md 或 .cursorrules，让 AI 每次动手前先知道「什么叫合格」。
团队用户，可以重点消化 dsh-pre-push-checks 的思路：不追求全量检查，而是让每个人（包括 AI）在提交前说清楚「这次改动相关的最小检查集是什么」。另外 record-browser-gif 那招——UI 变更必须附可验证的录屏——对远程团队几乎零成本就能落地。
做 Agent 工具或工程效能的，11 个都该读一遍。正如那篇拆解帖说的：这些文件比任何一篇论文都有参考价值，因为它们不是理论，是一套正在被使用的东西。微博
最后说两句
这一轮 Harness 热潮里，框架是热闹，纪律才是资产。装不装 DSH、换不换模型，是另一本账——API 刚在 17 号涨过价，成本账得自己算。知乎但这 11 个文件零成本、不挑工具，属于看了就能往自己项目里带的那种。
后续可以盯两个信号：一是社区会不会把这些 Skill 移植成 Claude Code、Codex 生态里的通用版本；二是 DeepSeek 官方仓库的更新节奏——v0.1 之后这套 SOP 是越磨越利，还是随版本烂尾，决定了它到底是长期资产还是一次性谈资。
