拆解 dbskill，24 个 Skills 如何把商业判断变成工作台

大家好，我是若风。

6 月底，我刷到一个挺有意思的仓库。它不是新的 Agent 框架，也不是一个把各种 prompt 打包到一起的提示词大全。它叫 dbskill。

截至我写这篇文章时，这个仓库有 7220 个 star、896 个 fork，最新版本是 v2.15.1，最近一次 push 是 2026 年 6 月 29 日。README 里的定位很直接，dontbesilent 把 12,307 条推文里的商业判断方法，整理成了 24 个 Agent Skill。

坦白讲，这个数字组合有点反常。看完以后我有点焦虑，也有点释然。焦虑的是，个人方法论正在被工程化得很快。释然的是，这事终于不只是「写一堆 prompt」了。

表面上看，大部分 prompt 项目会告诉你「这里有一堆好用提示词」。真正关键是，dbskill 不是这么做的。它更像把一个人的商业判断过程拆成了 24 个可以被 Agent 调用的工作台，每个工作台都有明确入口、边界、流程和退出条件。

它不是 prompt 合集

如果只看 README，dbskill 很容易被误解成「商业版 awesome prompts」。

但我把仓库 clone 下来看了一圈，发现它的核心不是 prompt，而是工作流。

仓库里有 24 个 skills/*/SKILL.md。其中 /dbs 是主入口，skills/dbs/SKILL.md 明确写着它不做诊断，也不做分析，只做两件事，任务前路由和任务后导航。

这个设计挺关键。

普通 prompt 包的入口通常是人脑，人先判断自己要用哪个 prompt，再复制粘贴。dbskill 反过来，它先做一个路由器，让用户只记住一个入口。你说「帮我看看商业模式」，它会去 /dbs-diagnosis。你说「我该学谁」，它会去 /dbs-benchmark。你说「这篇有没有 AI 味」，它会去 /dbs-ai-check。

说真的，这个差别不小。

提示词包解决的是「我有一段好文本」。工作台解决的是「我不知道该从哪开始」。

商业问题最麻烦的地方，也常常不在答案，而在问题还没被分流。一个用户说「帮我看看」，背后可能是商业模式问题、内容表达问题、执行力问题，也可能只是概念没定义清楚。如果入口没有路由层，后面的 prompt 再漂亮，也会被错误问题拖歪。

dbskill 把这个入口单独做成 /dbs，其实就是承认了一件事。

判断先于回答。

诊断不是输出，是消解

最能体现 dbskill 气质的，是 skills/dbs-diagnosis/SKILL.md。

这个文件有 510 多行，不是让 AI 上来给商业建议，而是先立了 6 条公理。比如「商业模式是独立于人的客观存在」「流量不等于收入」「定价即产品」「99% 的创业问题是心理问题」。

你可以不同意这些判断。

但它至少把判断坐标摆出来了。

然后它把问诊流程拆成多个 Phase。Phase 0 先让用户选问诊还是体检。问诊模式里，Phase 2 会先把问题分成纯信息获取、情绪宣泄和复杂问题。只有复杂问题才进入 Phase 3 的消解漏斗。

这个漏斗也挺有意思。它不是急着回答，而是逐层检查语言陷阱、假设错误、逻辑错误、事实前提和信息充分性。

你想想看，很多商业咨询的失败，不就是这个顺序反了吗。

用户问「我要不要做某个平台」，AI 马上回答「要，原因有三点」。但真正的问题可能是「适合」这个词没定义，也可能是用户把流量和收入当成了同一件事。dbskill 的选择是，先把错误问题消掉，再谈少数真正成立的问题。

这也是我觉得它比提示词合集更像工具箱的原因。

工具箱不是把锤子、扳手、螺丝刀随便堆一起。工具箱要告诉你，什么时候不该拿锤子。

真正重的是知识原子

README 里有一句容易被忽略的话，原子库可以直接导入向量数据库。

我实际数了一下，知识库/原子库/atoms.jsonl 有 4176 行，另外还有 2024Q4 到 2026Q1 的 6 个季度分片。每条原子大概包含 id、knowledge、original、url、date、topics、skills、type 和 confidence。

这说明 dbskill 并不是只把方法论写进 SKILL.md。

它还有一层更底部的材料层。

比如一条原子会保留原始推文、结构化后的知识点、主题标签、关联 Skill，以及置信度。这里可以这么理解，SKILL.md 是运行时入口，知识库/原子库 是可检索素材，知识库/Skill知识包 则像方法论文档。

这三层叠起来，才是它真正的产品形态。

我一直觉得，很多个人方法论很难被 Agent 用起来，不是因为方法不对，而是因为它没有被拆到合适的颗粒度。太大了，就只能当文章读。太碎了，又失去判断结构。dbskill 的做法是，把判断流程放进 Skill，把案例和观点拆成原子，再通过路由器把它们接回用户的具体任务。

这个模式很适合内容型专家。

如果你过去几年写了几千条推文、几百篇文章、几十套课程，最难的不是「再写一篇总结」。最难的是把它们变成 Agent 能反复调用的判断系统。

打包脚本暴露了它的取舍

我还专门跑了它的 tools/build-skills.sh。

脚本会读取 VERSION，把每个 skills/*/SKILL.md 打成独立 zip，再把这些 zip 按场景分组，收束成一个总包。我本地跑出来的是 /tmp/dbskill-dist/dbskill-2.15.1.zip，里面有 25 个文件，一个总 README 加 24 个 Skill zip。

这里有几个文件级细节很能说明它的工程取舍。

tools/build-skills.sh 里的 group_for 函数，把 Skill 分成「必装入口」「看商业问题」「做内容」「进阶-内容工程」「进阶-状态管理」这些目录。这不是技术分类，而是使用场景分类。对 Trae Solo 这种一个 zip 装一个 Skill 的平台来说，这个分类比源码结构更重要。

脚本还会用 grep -Eo '知识库/[^,。 、)]*.md’扫描SKILL.md里的知识库引用，把需要的.md` 一起拷进打包目录。

这说明它不是简单压缩整个仓库。

它在做一件更细的事，把 Skill 需要的上下文打成可迁移单元。

另一个更重的例子是 skills/dbs-content-system。这个 Skill 不是单文件 prompt，它带了 templates/、scaffold/、docs/ 和 tools/。其中 tools/init-content-system.js 会创建 00-规则与索引、01-原始素材区、02-内容单元库、03-处理状态 等目录，还会复制模板、规则文件和后续脚本。

这就不是「请 AI 帮我整理内容」了。

这是把内容资产工程初始化出来。

别把它当普通开源包

夸完结构，也得说它的边界。

第一，它的许可证不是常见的 MIT 或 Apache 2.0。GitHub API 返回的 license 是 NOASSERTION，我读了仓库里的 LICENSE，实际是 CC BY-NC 4.0，也就是署名加非商业。README 也写了，个人使用、学习、研究、非商业项目可以用，商业用途需要单独授权。

这对很多人很关键。

如果你只是自己装来诊断项目，没问题。如果你想把这套东西内置到商业 SaaS、课程产品或咨询交付里，就不能按普通开源库理解。

第二，它现在的 Claude Code 插件更新链路有一个真实坑。我查了 .claude-plugin/marketplace.json，metadata.version 是 2.15.1，但 24 个 plugins[] 里的版本号并不统一，大部分还是 1.0.0，dbs-decision 是 2.0.0。issue #38 也在说同一个问题，claude plugin update 会误判已经是最新版，导致新增 Skill 拿不到。issue #39 提了修法，但我看的时候还是 open。

这不是致命问题。

但它提醒你，dbskill 更新很快，分发链路还在追它自己的增长速度。README 里的通用安装方式 npx -y skills add dontbesilent2025/dbskill -g --all，目前反而是更稳的路径。

第三，dbskill 强依赖用户提供高质量上下文。

比如 /dbs-diagnosis 再强调消解问题，如果用户只给一句「帮我看看」，它仍然要追问。/dbs-content-system 也写得很清楚，要先审计内容规模和边界，文本文件少于 50 个、正文总字数不足 80000 字，或者来源边界不清，就不进入重工程。

这点我反而觉得是优点。

真正严肃的 Skill 不应该假装自己什么都能接。它应该知道什么时候该停下来。

和同类工具的差别

如果硬要横向放一下，dbskill 不是在和 LangChain、Dify、Coze 这种 Agent 平台竞争。它也不是纯 prompt 商店。

更准确的参照，是三类东西。

所以我不太建议用「强不强」来判断它。

更好的问题是，你需不需要把一套人的判断，迁移到 Agent 工作台里。

如果你要的是通用自动化框架，dbskill 不合适。如果你要的是一套商业、内容、决策、执行力的判断语言，它很有价值。如果你自己也有大量公开内容，想把它变成 Agent 可用的系统，它的工程形态甚至比具体内容更值得学。

我会带走的一个模式

这篇拆完，我最想带走的不是某个具体 Skill，而是一个我暂时叫「判断工作台模式」的东西。

它有四层。入口层，先路由，不急着回答。方法层，把判断拆成公理、Phase、门槛和输出格式。材料层，把原始观点、案例、反例拆成可检索原子。分发层，把每个工作台打成可迁移、可单独安装的 Skill 包。

这个模式对个人创作者尤其有启发。过去我们说知识产品，通常是文章、课程、社群。到了 Agent 工作台里，知识产品可以变成一套可调用的判断系统。它不一定替你做决定，但它会逼你把问题问清楚。

最后说两句，真正稀缺的不是把知识交给 AI，而是把自己的判断拆到 AI 能接住、能追问、能拒绝的程度。其实吧，这可能比直接给答案更贵。