# 大家都在用 dbskill 时，我已经挖到 dontbesilent 背后的底层方法论
**作者**: MrPrism
**日期**: 2026-05-02T08:36:21.000Z
**来源**: [https://x.com/MrPrismAI/status/2050494590730555639](https://x.com/MrPrismAI/status/2050494590730555639)
---
工具只是结果，背后的工作方法才是核心。
很多人用 dbskill，是为了让 AI 给自己一个更好的答案。
但更值得探索的是：dontbesilent 到底是怎么把自己的思考，变成一套可以调用、持续迭代、还能互相协作的 skill 系统的？
我花了一些时间拆解他的公开推文和 skill 源码，提炼了自己关于dbskill的一些思考，也给出大家可以直接复用的部分：
1. dontbesilent 的核心工作模式是什么？
skill 系统是怎么生成的？
skill 怎么迭代？
skill 或 Agent 之间如何协作分工？
2. 背后的内容生产模式是什么？
3. 这套系统背后的底层能力有哪些？
4. 对于我们有哪些值得学习的地方？
## 一、dontbesilent 的核心工作模式是什么？
他的工作模式不是“想到什么写什么”，也不是“写几个 prompt 提高效率”。
它更像一条会反复升级的生产线：
```
真实问题 → 和 AI 深度讨论 → 形成有效判断 → 沉淀成文档/skill
↑ ↓
再服务下一次问题 ← 迭代 skill ← 收集负反馈 ← 用真实场景测试
```
关键不只是“这次有没有解决问题”。
而是在于：这次解决问题的过程，能不能留下来，下次继续用。
普通人和 AI 聊完，得到一个答案。 他和 AI 聊完，可能得到三样东西：
```
一个答案
↓
一套判断标准
↓
一个以后还能调用的 skill
```
如果只看 skill 文件，很容易漏掉一个细节：
进入 dontbesilent 的社群的小伙伴都能发现，dontbesilent 对群员提问非常认真。市面上很多博主可能会把这类问题交给助理或客服处理，但他经常自己回应，而且不是敷衍式回应。
这件事表面看很耗时间，但价值很大。
一方面，群员会感受到被重视，社群归属感更强。
另一方面，这些真实提问本身就是一线需求样本。他在回答问题的同时，也在观察用户卡在哪里、表达哪里不清楚、产品哪里没想明白。
也就是说，社群问答不只是服务动作，也是素材收集、需求研究和方法沉淀。
## skill 系统是怎么生成的？一切皆可沉淀为 skill
dontbesilent 的底层逻辑是：
每一次有价值的对话、每一次对外交付，都应该尽量沉淀成可复用的 skill。
这样知识才不会只停留在某一次聊天里，而是可以被下一次、下一个人、下一个场景继续调用。
通常有 4 类生成场景：
## 1.1 对话中聊出有用结果
他有一个很重要的习惯：尽量多用 Claude Code 聊天。
原因不是为了聊天本身，而是因为一旦聊出有用结果，就可以把这个过程做成 skill，后面继续调用。
他举过一个具体例子：在讨论选题时，他发现 AI 不是一次性完成输出，而是在讨论过程中逐步确定结果——"于是我一条命令就让它又生成了一个'讨论选题' skill，在 iCloud 文件夹，我可以通过其他设备的" 也就是说，skill 的生成逻辑是：
```
和 AI 对话
↓
聊出有效结果
↓
提炼出过程和判断标准
↓
生成 skill
↓
供后续调用
```
它不是提前拍脑袋规划“我要做什么 skill”，而是在真实工作里慢慢形成的。
## 1.2 对外交付中沉淀通用 skill
他提到过，会把优化文案的一堆 skill，用陪跑用户的真实内容全部跑一遍。
目的不是为某个人定制一个专属 skill，而是反过来测试：
这套方法能不能跨行业、跨场景、跨内容类型继续成立？
如果只对自己有效，那还不够。
如果对很多人的真实内容都有效，它才有资格变成通用 skill。
这也是为什么他强调：不要维护个人专属 skill，要维护通用 skill。真正重要的不是某个领域的小技巧，而是对文字、内容和商业判断的底层理解。
## 1.3 特定平台需求下，打磨专项 skill
不同平台有不同语境。
公众号、小红书、短视频、X，都不是同一种表达环境。
所以他会针对具体平台打磨专项 skill。比如公众号文章，可以让一篇文章用 7 种方法写 7 遍。
这说明平台 skill 不是简单换标题，而是要理解平台的表达习惯、用户预期和内容结构。
## 1.4 衍生工具型 skill
除了内容生产类 skill，他还会把一些“过程”本身做成工具。
比如：
讨论选题 skill。
skill 迭代复盘 skill。
前者用于帮助确定选题，后者专门用来复盘其他 skill。
这说明在他的体系里，不只是内容可以被沉淀，连“怎么讨论”“怎么复盘”“怎么迭代”也可以被沉淀。
所以总结一下，skill 大概来自 4 类场景：
```
1. 对话里聊出了有用结果
→ 把这次对话过程沉淀成 skill
2. 对外交付里发现通用问题
→ 把反复出现的问题沉淀成通用 skill
3. 某个平台需要稳定打法
→ 为公众号、小红书、短视频等打磨平台 skill
4. 某个流程值得反复调用
→ 把选题讨论、内容复盘、skill 迭代工具化
```
所以 skill 的本质不是提示词。
它更像一份“被验证过的做事流程”。
它不是让 AI 突然变聪明，而是把人脑里原本说不清的判断，写成 AI 可以照着执行的规则。
关键原则是：不是为了做 skill 而做 skill，而是在解决真实问题的过程中，把有效方法自然留下来，沉淀成skill。
## 2. skill 怎么迭代？
skill 不是写完就结束。
真正重要的是：它怎么变得越来越准。
## 2.1 用“迭代复盘”机制优化 skill
他专门做过一个“skill 迭代复盘 skill”。
原因很简单：一次对话里可能会调用多个 skill，而不同 skill 的产出可能都会出现问题。
如果这些负反馈只停留在当下，这次问题就白白过去了。
所以在对话结束时，需要 AI 回看整场对话，判断：
1. 哪些 skill 需要更新？
2. 具体应该怎么更新？
3. 哪些问题不是更新 skill，而是需要补充信息、调整流程或改变调用方式？
它的触发方式可以是 /skill 复盘 或 /迭代清单。
本质上，这是在给 skill 做“复盘会”。
## 2.2 通过负反馈驱动迭代
他的迭代不是靠“我觉得不够好”，而是靠负反馈。
这里大概有两条路径：
```
路径 A：改工作流
文案智能体产出
↓
测试智能体挑刺
↓
不合格就打回
↓
直到通过才进入 output
```
```
路径 B：改系统提示词
测试智能体产出大量正反馈和负反馈
↓
收集反馈数据
↓
用这些反馈迭代文案智能体
↓
再放回真实工作流中测试
```
一个像生产线，负责保证当下结果过关。
一个像训练场，负责让产出者本身变得更强。
## 2.3 用真实用户数据迭代
他不是闭门造车。
他会把 skill 拿去跑陪跑用户的真实内容，测试它在不同场景、行业和表达风格下能不能成立。
如果只在自己身上成立，那只是个人经验。
如果能在不同人的真实内容里跑通，才可能成为通用方法。
这就是 skill 复盘的意义。
每一次 bad case 都不是废稿，而是系统升级的材料。
他不只沉淀成功经验，也沉淀失败、误判、跑偏、AI 味、表达不成立。
一个 skill 如果只记录“怎么做”，很容易变成鸡汤。
但如果它同时记录“什么情况不能这么做”，它才会越来越准。
## 3. skill 或Agent 之间如何协作分工？
这部分最值得大家学。
因为很多人用 AI，还是把它当成一个万能助手。
但 dontbesilent 的思路，更像是在设计一个小团队。
## 原则 1：生产、评判、决策分开
不要让一个 Agent 又当运动员，又当裁判。
更合理的分工是：
```
文案智能体
→ 负责产出
测试智能体
→ 负责挑错和打反馈
决策 skill
→ 判断下一步是补反馈、改流程，还是迭代 prompt
```
每个角色只做一件事，反馈链路才会清楚。
## 原则 2：用“通过门槛”做硬隔离
协作不是让几个 Agent 坐在一起“商量”。
更像一条有验收标准的生产线。
```
文案智能体产出
↓
测试智能体评判
↓
通过 → 进入 output
不通过 → 打回重做
```
这就是硬门槛。
不合格就不进入下一步。
## 原则 3：维护共享词典，减少沟通损耗
多 Agent 协作最大的问题之一，是每个 Agent 对概念的理解不一致。
一个词你觉得很清楚，AI 可能并不知道你在说什么。
所以他会维护一个核心概念词典。
这个词典的作用，就是让所有 Agent 对同一个词有相同理解。
这相当于团队里的统一话术和内部语言。
## 原则 4：区分“改工作流”还是“改 prompt”
不是所有问题都该靠改 prompt 解决。
有些问题是流程设计不合理。
有些问题是文案智能体本身能力不够。
所以要分两条路：
```
A 路径：改工作流
测试智能体持续挑错 → 不合格不放行
B 路径：改 prompt
收集大量正负反馈 → 迭代文案智能体
```
更关键的是，他还会用“整个工作流的 token 消耗是否稳定降低”作为指标。
也就是说，新版文案智能体不是看起来更聪明就行，而是要让整个流程更省力、更稳定。
## 原则 5：把 Agent Team 当敏捷小团队管理
他提到过，设计 Agent Team 的时候，可以借鉴德鲁克管理学。
这句话很关键。
因为 AI 协同的本质，不只是技术问题，更是管理问题。
你要知道：
谁负责什么？
谁的产出交给谁？
什么标准算合格？
不合格谁来打回？
什么时候复盘？
把“Agent”换成“员工”，把“工具”换成“岗位”，你会发现逻辑完全成立。
这不是 AI 特有的问题，而是组织协作问题。
## Skill或Agent的协同机制
从资料里可以提炼出 5 个机制。
## 机制 1：工作流串联
```
文案智能体产出
↓
测试智能体评判
↓
通过则进入 output
↓
不通过则打回重做
```
这就是典型的生产-质检流程。
## 机制 2：双模型或多模型交叉验证
```
G 模型回答
+
O 模型回答
↓
互相评价对方
↓
把两个回答 + 两份评价放回上下文
↓
得到更稳的判断
```
这有点像同行评审。
两个专家各自给答案，再互相挑错。
## 机制 3：工作流 A 和 B 配合迭代
```
工作流 A：生产线
文案智能体产出 → 测试智能体评判 → 循环直到通过
工作流 B：训练场
测试智能体产出大量正负反馈 → 迭代文案智能体
验证方式：
新版文案智能体放回 A 流程
看是否能用更少轮次触发 output
```
这个设计的聪明之处在于：
不只看反馈好不好听，而是看整个流程有没有更省力、更稳定。
## 机制 4：人机分工明确
```
Claude Code
→ 负责生成文件
人类
→ 负责写负反馈
决策 skill
→ 判断是补充反馈，还是迭代 system prompt
```
这里的关键是：决策权不是随便交给某个生成者。
它被交给一个专门负责判断下一步的 skill。
## 机制 5：skill 之间条件触发
各个 skill 不是孤立存在的，而是会根据问题自动推荐下一步。
```
content 发现开头问题
→ 推荐 hook
content 检测出 AI 味
→ 推荐 ai-check
content 发现用户在走捷径
→ 推荐 slowisfast
对话结束
→ 触发 skill 迭代复盘
```
这才是协作。
不是把工具堆在一起，而是让不同工具在合适的时候接力。
## 二、背后的内容生产模式是什么？
dontbesilent 的内容生成，不是从“今天发什么”开始。
而是先问：
这个内容到底服务什么？
是服务产品、信任、转化，还是影响力？
大概可以拆成 6 步：
```
1. 判断商业目标
这条内容服务产品、信任、转化，还是影响力？
2. 判断选题是否成立
不是我想讲什么，而是用户为什么要看。
3. 找到对标
不凭空创作，先找已经被市场验证过的表达。
4. 生成内容结构
观点、案例、冲突、解释、结论要站得住。
5. 打磨三件套
开头、标题、封面决定内容能不能被看见。
6. 进入质检
查逻辑、查表达、查 AI 味、查是否有空泛大词。
```
所以它不是“AI 一键写稿”。
更像是 4 个动作反复循环：
```
判断
↓
表达
↓
质检
↓
复盘
```
内容储备也不是传统意义上的“选题库”。
他的素材来自日常对话、交付案例、负反馈、用户问题、平台数据、旧内容复盘。
这些东西会被不断整理成文档、案例、原子、概念词典和 skill。
所以内容不是临时憋出来的。
内容是从长期工作过程里不断积累出来的。
一方面，它会形成复利。每一次真实反馈，都可能变成下次内容的材料。
另一方面，它也能解决创作枯竭的问题。因为只要持续工作、持续回应真实问题，不断发现新的痛点，素材就会不断出现。
## 三、这套系统背后的底层能力是什么？
我认为至少有 7 个。
## 能力 1：把隐性知识显性化
这是整个体系的入口能力。
很多人会做一件事，但说不清自己为什么这么做。
他厉害的地方，是能把这件事说清楚。
他能把自己做过的事，反向拆成：
```
原则
↓
公理
↓
流程
↓
触发词
```
比如 dbs-diagnosis 里有 6 条公理，dbs-benchmark 里有 4 条信条。
这不是简单总结，而是把脑子里的判断写成别人和 AI 都能调用的规则。
他的做法大概是：
1. 把自己的判断逻辑写成 skill。
2. 用真实用户内容跑一遍，确认能不能跨场景使用。
3. 不维护个人专属 skill，只维护通用 skill。
4. 每次对外交付，都顺手优化 skill，给后面的人继续用。
这里的核心不是技巧，而是对文字和问题的底层理解。
## 能力 2：用公理系统代替经验清单
普通人写方法论，常常是列 tips。
比如“要坚持”“要复盘”“要多发”。
但 tips 的问题是：只能记，不能推导。
他的做法更像是写公理。
公理的好处是：可以推导、可以验证、可以迭代。
比如：
定价即产品。
高利润是唯一标准。
高毛利、高复购、高壁垒，不等于高利润。
这些不是零散建议，而是判断问题时的底层标尺。
## 能力 3：跨学科融合能力
他的体系不是只来自内容技巧。
他会把不同学科揉到一起：
维特根斯坦的语言哲学，用来拆概念。
奥派经济学，用来做商业判断。
阿德勒心理学，用来做执行力诊断。
德鲁克管理学，用来设计 Agent 协作。
这不是“学了很多框架”。
而是能把不同框架放到同一个问题里，让它们各自解决不同层级的问题。
所以他的 skill 不浅，原因不只是 prompt 写得好，而是底层骨架比较硬。
## 能力 4：通用化抽象能力
很多人的方法论，只适合自己。
换一个人、换一个行业、换一个平台，就失效了。
他会用陪跑用户的真实内容，把 skill 反复跑一遍。
目的就是看：
这套东西到底只是我的个人经验，还是能被更多人复用的规律？
如果只对自己有效，就还不是通用方法。
如果在不同人的真实场景里都能跑通，才值得沉淀。
这其实是在防止方法论只适合自己。
## 能力 5：管理学迁移能力
他把 Agent 当员工管。
这个视角很重要。
很多人设计 AI 工作流，会先想技术怎么实现。
他会先想：
这个团队怎么分工？
谁负责生产？
谁负责评判？
谁负责决策？
谁负责复盘？
这就是把管理学迁移到 AI 协作里。
AI 协同不是单纯技术问题，而是组织分工问题。
## 能力 6：边界意识
他的 skill 都有明确边界。
比如 dbs-diagnosis 遇到情绪类问题，会直接说明：
这不是商业问题，这是情绪问题。
我的业务边界是商业诊断。
这很重要。
因为一个没有边界的 AI 助手，看起来什么都能答，最后什么都不准。
边界感让每个 skill 都有明确职责，也有可验收标准。
它知道自己做什么，也知道自己不做什么。
## 能力 7：问题消解能力
这是最核心的能力。
dbs-diagnosis 里有一句话很重要：
8000+ 人付费问过商业问题，其中只有 0.9% 真正被解答，99.1% 是被消解掉的。
因为很多问题本身就是错的。
所以他的核心工作不是急着回答，而是先判断问题成不成立。
比如一个人问“我该怎么做爆款”，可能真正的问题不是爆款，而是：
没有产品。
没有对标。
没有承接。
没有定义清楚用户是谁。
如果这些没搞清楚，直接回答“怎么做爆款”，就是在错误问题上越跑越远。
所以每个 skill 的第一步，不是给答案，而是判断问题本身是不是成立。
## 四、对于我们有哪些值得学习的地方？
至少有 以下4 个方向：
## 思维层面：学会先问“是什么”，再问“怎么办”
他的底层姿态，不是上来就解决问题。
而是先确认：
这个问题到底是什么？
这个对象本身是什么？
问题里的词是不是说清楚了？
比如他看商业模式，不是先问“商业模式怎么设计”，而是先问“商业模式本身是什么”。
这会带来一个很反常识的工作姿态：
很多问题不需要回答，而是需要先被拆开。
普通人也可以学这个动作。
以后遇到问题，先别急着问 AI“怎么办”。
先问：
我这个问题本身成立吗？
我用的关键词说清楚了吗？
我是不是把情绪问题、执行问题、商业问题混在一起了？
## 行为层面：先执行后学习
不要等完全学会再动手。
先做。真正的问题，往往是在做的过程中才会出现。
很多人之所以问的问题很空，是因为没有真正做过。
没做过，就只能问：
怎么做内容？
怎么赚钱？
怎么用 AI？
这些问题太大，AI 也很难给出真正有用的答案。
但你先拍 3 条视频、先卖一个小产品、先跑一次流程，问题就会变具体：
是哪一步卡住？
哪个标题没人点？
哪个用户不买？
哪句话自己说不出口？
这时候，AI 才真正帮得上忙。
## AI 实战层面：把有用过程沉淀成自己的 skill
不要每次都从零开始问 AI。
每次和 AI 聊完，至少留下 4 个东西：
```
这次解决了什么问题？
↓
我是怎么判断的？
↓
下次遇到类似问题怎么用？
↓
这次哪里容易误判？
```
时间久了，你就会有自己的小型 skill 库。
它不一定真的叫 skill。
它可能只是一个文档、一个检查清单、一个模板。
但本质一样：
你把这次想明白的东西留下来，下次遇到类似问题，直接拿来用。
同时，要学会用“小团队思维”使用 AI。
不要只对 AI 说“帮我写一篇”。
可以拆成几个角色：
```
选题助手
→ 负责判断选题值不值得做
写稿助手
→ 负责出初稿
评审助手
→ 负责挑逻辑漏洞和 AI 味
数据助手
→ 负责复盘发布后的表现
```
你不是在找一个万能 AI。
你是在组一支小团队。
## 表达层面：练“说清楚”的能力
你给 AI 的稿子只是一个结果。
但 AI 真正需要的，是产出这个结果背后的规则。
你要能说清楚：
在什么情况下？
用什么标准？
做什么判断？
为什么这样改？
为什么这个标题比另一个标题好？
为什么这个选题成立，另一个不成立？
只是疯狂喂数据没用。
如果你说不清自己的判断，AI 只能模仿表面。
如果你能把做事逻辑拆成清楚的规则，AI 才能真正帮你复用。
所以，最该练的，不是“会不会写 prompt”。
而是能不能把自己脑子里的判断说清楚。
你要解决什么问题，为什么这样判断，什么结果算好，哪里不对、下一步该怎么改，这些都需要说清楚。
因为 AI 不是替你凭空判断，它是在你给出的信息和标准上继续往前推。
你说得越模糊，它越容易给你一个看起来完整、但方向错误的答案。
你说得越清楚，它越能把你的想法变成方案、流程，甚至下一次还能复用的 skill。
所以，“说清楚”不是写作技巧，而是和 AI 协作的基本能力。
## 最后总结
所以回到开头那个问题：
dbskill 真正值得研究的，不只是它能帮我们诊断什么、生成什么、优化什么。
更重要的是，它展示了一种新的工作方式：
```
把真实问题留下来
↓
把有效判断写清楚
↓
把反复出现的流程沉淀下来
↓
用真实反馈不断修正
↓
让下一次工作不再从零开始
```
这才是 dontbesilent 这套系统最值得学习的地方。
我们不一定要复制他的 skill，也不一定要做出同样复杂的工具箱。
但我们可以从一个很小的动作开始：
每次做完一件事，都问自己一句：
这次有没有什么东西，值得留下来给下一次用？
如果有，就把它写下来。
写清楚，跑一遍，改一次，再继续用。
时间久了，它就不只是笔记。
它会变成你自己的方法库、工作流，甚至是你自己的 skill 系统。
这也是我拆解 dbskill 后最大的感受：
工具也会过时的，经验也有被遗忘的时候。只有把经验变成可复用的规则，再借助技术把它产品化，才能转化成你反复调用的能力。
最后，特别感谢 don 哥一直以来无私开源。无论是非常实用的 dbskill，还是各类商业与工作方法论，都给了我很多启发和帮助，真的受益匪浅🫡🫡🫡
## 资料来源
本文基于以下dontbesilent的公开内容：
1. dontbesilent 的 X 公开内容与案例记录：https://x.com/dontbesilent
2. dbskill 开源项目与知库：https://github.com/dontbesilent2025/dbskill
3. dbskill 项目内 README、skills 源文件、Skill 知识包、原子库与相关工作流说明
4. dontbesilent 的直播回放、公众号文章、以及社群等渠道的公开回答
以上内容仅属我基于公开资料和个人理解做出的分析与提炼，并不代表 dontbesilent 本人观点，也不保证完全还原他的真实想法，由于资料理解、视角选择和表达取舍都可能存在偏差，如有失准或偏颇之处，还请多多谅解。
## 相关链接
- [Jackywine reposted](https://x.com/Jackywine)
- [MrPrism](https://x.com/MrPrismAI)
- [@MrPrismAI](https://x.com/MrPrismAI)
- [479](https://x.com/MrPrismAI/status/2050494590730555639/analytics)
- [https://x.com/dontbesilent](https://x.com/dontbesilent)
- [https://github.com/dontbesilent2025/dbskill](https://github.com/dontbesilent2025/dbskill)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:36 PM · May 2, 2026](https://x.com/MrPrismAI/status/2050494590730555639)
- [479 Views](https://x.com/MrPrismAI/status/2050494590730555639/analytics)
---
*导出时间: 2026/5/4 09:15:39*