深度解构：如何用 DBS 三箭齐发，完成一次高水准的商业诊断复盘？

🏥 模块 3：商业诊断完整闭环

深度解构：如何用 DBS 三箭齐发，完成一次高水准的商业诊断复盘？

——用 dbs-diagnosis + dbs-benchmark + dbs-report 把你的项目放上手术台

写在前面：为什么你的「商业直觉」需要被检验？

先做一个测试。

用一句话，回答以下三个问题：

1. 你的客户，为什么付钱给你，而不是给别人？2. 如果你把价格提高 50%，有多少客户会留下来？3. 你的生意，三年后会因为什么原因失败？

大多数创业者，第一个问题回答得很自信，第二个开始模糊，第三个基本回避。

这不是勇气问题，是诊断工具的问题。

没有系统性的诊断框架，商业直觉就是一块确认偏误的镜子——它只反射你想看到的东西。

我们要做的，是给你一套完整的诊断闭环：

dbs-diagnosis 做商业模式诊断（消解问题，不回答问题），dbs-benchmark 做对标分析（五重过滤，排除噪音），dbs-report 生成结构化诊断报告。

三个 skill，构成一次完整的「商业体检」。

一、理解三个 Skill 的分工与关系

在进入操作之前，必须先理解这三个工具各自的边界：

1.1 三工具分工表

1.2 最关键的一个理解：「消解」vs「回答」

dbs-diagnosis 是 dontbesilent 的商业模式诊断 AI，提供两种模式：咨询模式（带着具体问题来——使用「消解漏斗」逐步判断问题是否真实，并提供解决路径）和体检模式（使用结构化框架全面拆解商业模式，产出诊断报告）。

「消解问题」和「回答问题」的区别，是这个模块最重要的认知升级：

text

❌ 回答问题的思维： 「我的产品怎么定价？」→ AI 给你一个定价建议 ✅ 消解问题的思维： 「我的产品怎么定价？」→ 先问： → 你的客户是谁？他们为什么付钱？ → 你的定价对标谁？他们为什么是你的对标？ → 你现在的价格是谁定的？依据是什么？ → 问完这些，你会发现： 「定价问题」根本不是问题， 「不知道客户为什么付钱」才是真正的问题。

核心功能包括分层漏斗交互（语言陷阱检测、隐性假设检查等），在每一层暂停等待用户确认，引导模糊词语量化，并输出有优先级的可行动建议。

1.3 诊断的六个公理：进入诊断前必须内化

把知识库/Skill知识包/diagnosis_公理与诊断框架.md 的内容粘贴到你的 system prompt 里，你的 AI 就有了 6 条公理 + 消解漏斗。

以下是这 6 条公理的实践含义：

公理一：商业模式是一台机器

商业模式是一台有固定 input 要求的机器，人只是喂料员。 这意味着：你的问题大多数时候不是「我能力不够」，而是「这台机器的设计有问题」。诊断商业模式，先诊断机器，再诊断人。

公理二：真实需求 ≠ 你以为的需求

判断一个生意能不能做，必要条件之一是：你能不能说出这个产品的「颜色」。 「颜色」是具体性的隐喻——你能不能用感官语言描述你的产品解决了什么具体问题？说不出「颜色」的产品，说明你对用户需求的理解还停留在抽象层。

公理三：99% 的创业问题是伪装成创业问题的心理问题

99% 的创业问题是伪装成创业问题的心理问题。如果用户来找你，大概率他的问题不是「不知道怎么做」，而是「知道怎么做但在逃避」。

公理四：问题被消解，比问题被回答更有价值

一个问题被正确消解，意味着它从「我不知道怎么办」变成了「原来根本不是这个问题」。消解之后，行动方向自然清晰。

公理五：对标是起点，不是答案

对标分析的价值不是「找人模仿」，而是「通过对比发现自己真正缺什么」。dbs-benchmark 的核心是五重过滤，排除噪音。 大多数人做对标，选的对象本身就是噪音。

公理六：诊断走完才能存档

诊断走到「问题被消解」「报告输出」「行动方案确定」这类节点时，相关 skill 会主动建议你/dbs-save。后面回来时一句「接着上次」或/dbs-restore 就能继续，不用从头再讲一遍背景。

二、课节 3-1：启动商业模式诊断

场景设定： 你有一个副业项目，做了 3-6 个月，有一些收入，但感觉「做了很多但不知道核心问题在哪」。这正是 dbs-diagnosis 体检模式的理想触发场景。

⚠️ 你可以用「朋友的项目」「你熟悉的一家小店」「某个你想创业的方向」作为案例。诊断的质量取决于你对案例的了解程度，而不是案例本身是否属于你。

Step 0：诊断前的自我盘点（不用 AI，先自己做）

在启动工具之前，独立完成以下表格。不要查资料，不要思考太久，写第一反应：

Markdown

═══════════════════════════════════════════ 诊断前自我盘点表（5分钟完成） ═══════════════════════════════════════════ 【业务描述】 我在做什么：___________________________ （一句话，不超过20字） 【客户画像】 我的客户是：___________________________ 他们有什么共同特征：___________________ 他们在哪里找到我：_____________________ 【产品与定价】 我卖的具体是什么：_____________________ 价格是：______________________________ 这个价格是怎么定出来的：_______________ 【收入现状】 当前月收入：__________________________ 最近一笔收入是什么时候：_______________ 平均每个客户贡献多少：________________ 【最大困惑】 我现在最不确定的一件事是：_____________ 如果这件事能解决，我下一步会___________ ═══════════════════════════════════════════

为什么先自己填？ 诊断的价值不在于 AI 告诉你什么，而在于「AI 的问题让你看到了自己之前没看见的盲点」。先有自己的答案，再看 AI 的诊断，对比才有冲击力。

Step 1：建立项目诊断目录

Bash

# 建立隔离的项目诊断空间 mkdir -p ~/projects/my-project/dbs-sessions cd ~/projects/my-project # 在 Obsidian 中建立对应目录 obsidian create name="03-Projects/my-project/项目概况" \ content="--- type: project name: my-project created: $(date +%Y-%m-%d) status: diagnosing tags: [project, diagnosis] --- # 项目概况 （粘贴自我盘点表的内容） "

Step 2：触发 dbs-diagnosis，选择模式

Bash

# 在 Claude Code / Codex 中，进入项目目录 cd ~/projects/my-project /dbs-diagnosis

dbs-diagnosis 适合创业者、创始团队、产品/运营人员和顾问，用于快速验证问题合理性、重建商业假设，以及优化定价和流量变现策略。

Agent 会问你：体检模式还是咨询模式？

text

体检模式：我帮你全面检查商业模式的6个维度 咨询模式：你带着具体问题来，我帮你消解它 → 第一次使用：选「体检模式」 → 后续有具体问题：选「咨询模式」

选择「体检模式」后，开始描述你的业务：

text

我在做一个面向独立创作者的知识付费社群。 具体产品： - 年费会员 1980元/年 - 包含：每周1小时直播答疑 + 课程录播 + 微信群 - 目前有 47 个付费会员 客户来源： - 我的公众号（8000粉，月更2-3篇） - 朋友介绍 月收入：大概5000-8000（新会员不稳定） 最大困惑： 感觉每次都要花很多时间做直播，但新会员增长很慢， 不知道是内容问题还是渠道问题。

Step 3：跟着诊断漏斗，逐层回答

dbs-diagnosis 会按照以下六个维度，逐层深入提问。每一层都要认真回答，不要跳过。

完整的诊断报告结构包括：印钞机检验、道德检验、定价检验、需求检验、流量-变现检验、规模化检验，以及成长层级判断。

维度一：印钞机检验

核心问题： 你的商业模式，是否像一台「放进去就出来」的印钞机？

text

Agent 会问： 「你的47个会员，续费率是多少？ 上一个自然流量新增会员是什么时候？ 他们为什么续费，有没有问过他们？」 你的回答示例： 「续费率大概60%，上次新增是3周前， 问过几个人，说是觉得直播答疑有价值。」 Agent 诊断： 印钞机检验 → 部分通过 核心问题：新客获取路径不稳定，依赖创始人个人时间， 不是自动运转的机器。

关键洞察： 「每周直播」不是产品，是你的时间成本在承担所有价值交付。如果你停播一个月，会员会续费吗？

维度二：道德检验

核心问题： 这是一个「好模式」还是「坏模式」？

text

Agent 会问： 「你的会员，加入后有没有获得他们期待的结果？ 他们付钱买的是什么？你交付的是什么？ 有没有会员觉得不值？」 这个维度不是在做道德评判， 而是在检验：你的价值交付是否持续成立。 好模式：用户付钱→获得价值→愿意续费→告诉朋友 坏模式：用户付钱→价值不稳定→续费率下降→靠不断拉新维持

维度三：定价检验

核心问题： 1980元/年，这个价格有没有基础？

text

Agent 会问： 「1980元，是怎么定出来的？ 你的目标用户，在其他地方花多少钱买类似服务？ 如果你涨到2980，会有多少人不续费？」 诊断信号： 如果你说「1980是参考同行定的」→ 价格没有自己的锚点 如果你说「我怕贵了没人买所以定低了」→ 存在定价焦虑

定价检验的核心逻辑： 价格不是「我觉得值多少」，是「用户认为他们获得了多少倍回报」。1980元的课程，如果帮用户多赚了10000元，那用户会觉得便宜。

维度四：需求检验

核心问题： 他们买的是你以为的那个东西吗？

text

Agent 会问： 「你的会员说有价值的是「直播答疑」， 但你有没有问过他们： 在认识你之前，这个需求他们怎么解决的？ 他们加入后，具体做了哪件之前做不到的事？」 这是最容易被创业者跳过的维度。 常见陷阱： 创作者以为用户买的是「知识」， 实际上用户买的是「和同类人在一起的感觉」。 前者是内容逻辑，后者是社群逻辑， 运营方式完全不同。

维度五：流量-变现检验

核心问题： 流量进来→变现，这条路通不通？

text

Agent 会问： 「你的公众号8000粉， 过去12个月新增了多少？ 每篇文章带来几个新会员？ 从看到你→付款，这中间用户走了几步？」 诊断信号（你的案例）： 公众号增长慢 + 转化路径不清晰 → 流量-变现检验：需要调整 → 核心问题不是「内容质量」，而是「没有清晰的转化动作」

维度六：规模化检验 + 成长层级判断

核心问题： 你现在在哪一层？这一层的核心任务是什么？

text

Agent 会问： 「如果会员从47个变成470个， 你的交付方式会不会崩溃？ 你现在最大的瓶颈是时间还是方法论还是渠道？」 成长层级示例： 第1层：验证需求（0-10个付费用户） 第2层：稳定交付（10-100个付费用户）← 你现在在这里 第3层：规模化获客（100-1000个付费用户） 第4层：系统化运营（1000+） 每一层的核心任务完全不同。 在第2层做第3层的事，是最常见的创业陷阱。

Step 4：记录诊断中的「不舒服时刻」

在整个诊断过程中，专门记录让你不舒服的问题——那里是信息密度最高的地方。

Bash

obsidian append \ file="03-Projects/my-project/项目概况" \ content=" ## 诊断中的不舒服时刻（$(date +%Y-%m-%d)） ### 问题1：「续费率60%，那40%去哪了？」 我的反应：沉默了30秒 真正原因：我从没认真追过流失原因，怕面对 ### 问题2：「1980是怎么定出来的？」 我的反应：说「参考同行」 暴露的问题：我的定价没有自己的逻辑 ### 最不想被问到的问题： 「如果你消失6个月，会员还会续费吗？」 （答案是否定的，说明产品依赖我个人，不是独立产品） "

三、课节 3-2：对标分析——五重过滤，排除噪音

对标分析是被误用最多的商业工具之一。

绝大多数人做「对标分析」的方式是：找一个自己仰慕的账号/公司，看他们在做什么，然后模仿。

benchmark 找到对标后，进入具体表达和内容执行推荐 content；benchmark 发现用户在模仿路径上贪快，推荐 slowisfast。

这句话暗含了 dbs-benchmark 的核心设计逻辑：对标的危险不是「找不到对标」，而是「找到了错误的对标」，或者「找到了正确的对标，但在错误的维度上模仿」。

Step 1：触发 dbs-benchmark

Bash

/dbs-benchmark

Agent 会先问你三个问题，再开始分析：

text

1. 你的业务是什么？（用dbs-diagnosis的结论描述） 2. 你想通过对标解决什么问题？ - 我想找到更好的获客方式 - 我想优化定价结构 - 我想改进内容质量 - 我想看清楚行业天花板在哪 3. 你现在心目中已有的对标是谁？

Step 2：理解「五重过滤」——排除噪音的核心机制

1 dbs-benchmark 的核心是五重过滤，排除噪音。

过滤层 1：阶段过滤

text

你的对标，和你处于同一成长阶段吗？ 错误的对标案例： 你有47个会员 → 你对标某个有10万会员的大 V → 他解决的问题和你的问题根本不是同一个问题 → 他的方法不适合你现在的阶段 正确的对标： 找到那些「刚跨过你正在面对的门槛」的人 （比如从50个会员到300个会员的那段历程）

过滤层 2：赛道过滤

text

你的对标，和你面对的是同类客户吗？ 常见误判： 同样是「知识付费社群」， 面向职场白领的社群 vs 面向独立创作者的社群 → 客户画像不同 → 获客方式不同 → 定价逻辑不同 不能直接套用，需要先过滤掉赛道差异。

过滤层 3：资源过滤

text

你的对标，和你拥有同类资源吗？ 典型错误： 对标一个有10年行业人脉的人的内容策略 → 他靠人脉分发，你没有 → 方法失效 要对标的是：「资源基础相似」的成长路径。

过滤层 4：护城河过滤

text

你的对标的成功，有多少是「可复制的」？ 有些成功来自： - 天时（特定时间点的市场空缺）→ 不可复制 - 个人IP（与生俱来的表达力/人格魅力）→ 难以复制 - 系统方法（可学习的运营策略）→ 可复制 只在「可复制维度」上进行对标。

过滤层 5：成本过滤

text

模仿这个对标，你付出的成本是什么？ 隐性成本检查： - 时间成本：他花了3年做到的，你计划多久？ - 机会成本：模仿他，意味着放弃了什么？ - 心智成本：模仿别人的风格，会不会让你失去自己的声音？

Step 3：完整运行对标分析

输入你的三个对标候选（通过了五重过滤后的）：

Bash

/dbs-benchmark 基于dbs-diagnosis的结论： 我的业务是「面向独立创作者的年费知识付费社群」 目前47个会员，最大问题是新增获客不稳定 我想解决的问题： 找到一个可持续的、不依赖个人时间爆发的获客方式 过滤后的三个对标： 1. 某创作者社群（100-500会员阶段，靠邮件列表稳定增长） 2. 某独立顾问（从公众号→私域转化，有清晰的转化漏斗） 3. 某内容作者（把单次内容变成长期资产，靠搜索带来持续流量）

对标分析输出结构：

text

════════════════════════════════════════ dbs-benchmark · 对标分析报告 ════════════════════════════════════════ 【对标1：邮件列表增长型】 核心策略：用高质量长文 → 邮件订阅 → 付费会员 可借鉴维度： → 邮件列表比公众号更「私域」（可控性更高） → 他的转化路径：免费内容→邮件订阅→30天培育→付费 不可借鉴维度： → 他的内容风格是英文技术内容，受众不同 核心启发： 你缺的不是内容质量，缺的是「订阅→培育→转化」的自动化路径 【对标2：清晰转化漏斗型】 核心策略：公众号文章结尾有清晰的「下一步动作」 可借鉴维度： → 每篇文章都有一个「如果你想深入，可以...」的转化口 → 他把社群定位成「解决一个具体问题的场所」，而非「综合学习」 不可借鉴维度： → 他的文章发布频率是你的3倍 核心启发： 你的公众号文章没有清晰的转化动作，流量在文章结束后就消散了 【对标3：内容资产型】 核心策略：把直播/语音内容转化成可搜索的文字资产 可借鉴维度： → 直播之后生产「结构化笔记」，成为长期可被搜索的内容 → 解决了「直播结束内容即消失」的问题 核心启发： 你的每周直播是时间黑洞，如果直播内容变成可搜索的知识库， 就变成了资产而非消耗 【综合判断】 你不缺内容质量，你缺的是： 1. 清晰的转化路径（每篇内容结束后用户该做什么？） 2. 直播内容的资产化（时间投入转化为可复用资产） 3. 一个可持续的「培育-转化」机制（不依赖个人出现） ════════════════════════════════════════

Step 4：dbs-benchmark 之后的关键决策

benchmark 找到对标后，进入具体表达和内容执行，推荐 content；benchmark 发现用户在模仿路径上贪快，推荐 slowisfast。

对标分析完成后，不要立刻开始执行。先做两个检验：

检验 A：这个结论改变了我的判断吗？

text

诊断前的判断：「我的问题是内容质量不够好」 对标后的判断：「我的问题是没有转化路径 + 内容没有资产化」 → 判断发生了实质性改变 → 对标有效 → 判断和之前一样 → 对标可能没有过滤掉噪音

检验 B：我准备借鉴的那一点，是否正在「贪快」？

text

如果你说「我要马上建邮件列表 + 改所有文章结尾 + 把直播笔记化」 → 这是三件事同时做 → /dbs-slowisfast 介入：先选最小的一个，跑通闭环

四、课节 3-3：生成完整诊断报告 + 存档

Step 1：触发 dbs-report

Bash

/dbs-report

dbs-report 会读取当前会话中的诊断结论（包括 diagnosis 和 benchmark 的输出），生成结构化报告。

完整诊断报告结构：

Markdown

════════════════════════════════════════ 商业模式诊断报告 项目：面向独立创作者的知识付费社群 日期：2026-06-13 诊断用时：约3小时 ════════════════════════════════════════ ## 基本信息 - 业务：面向独立创作者的年费知识付费社群 - 产品：年费会员 1980元/年（直播答疑+录播+微信群） - 价格体系：单一年费制 - 月收入：5000-8000元（不稳定） ## 诊断结果 ### 印钞机检验：部分通过 价值交付有效（续费率60%），但获客路径依赖创始人时间投入， 不是自动运转的机器。核心问题：没有独立于个人出现的流量入口。 ### 道德检验：好模式 用户付费后获得了他们期待的价值（答疑+同伴）。 问题不在于模式的诚信度，在于交付效率。 ### 定价检验：需要重新建立锚点 1980元定价参考同行，缺乏自己的定价逻辑。 建议：用「用户的一个具体成果」重新建立价值锚点。 ### 需求检验：需要澄清 用户购买的核心需求可能是「和同类人的连接感」， 而非「知识本身」。这两种需求对应完全不同的产品设计。 ### 流量-变现检验：需要调整 公众号→会员的转化路径不清晰。 每篇文章结束后，用户没有清晰的下一步动作。 ### 规模化检验：还没到时候 当前在第2层（稳定交付），尚未解决交付效率问题前， 不适合做规模化获客。 ### 成长层级：第2层 当前核心任务：稳定交付 + 建立清晰的转化路径 ## 核心判断 这是一个有真实需求支撑的好生意，但被困在创始人个人时间里。 最大的问题不是内容，是结构：没有独立于创始人的转化路径， 也没有把时间投入（直播）转化为可复用资产。 ## 一句话处方 先停一周直播，把过去12期直播变成12篇可搜索的结构化笔记， 在每篇公众号文章结尾加一个清晰的入口。 这比再做10期直播更值钱。 ## 下一步行动（按优先级） 1. 【本周】访谈5个流失会员，问他们为什么不续费 2. 【本月】把过去3个月直播内容整理成3篇长文资产 3. 【本月】设计一个公众号→邮件列表→付费的转化路径 4. 【下季度】有了稳定转化路径后，再考虑扩大内容投入 ════════════════════════════════════════ 「你对这份报告有什么不同意的地方吗？」 ════════════════════════════════════════

Step 2：执行「你有什么不同意？」

这是整个诊断流程中最容易被跳过、也最有价值的一步。

报告出完后，Agent 会问：「你对这份报告有什么不同意的地方吗？」

不要说「没有，都对」。 认真想：

text

你可能不同意的地方： - 「你说我的需求是连接感，但我觉得用户真的是来学东西的」 - 「你说定价没有逻辑，但1980是我认真算过成本后定的」 - 「你说先别做规模化，但我已经到瓶颈了，不增长就死」 每一个不同意，都是一次更深的诊断机会。 把它说出来，Agent 会进入新一轮澄清。

Step 3：dbs-save 存档

Bash

/dbs-save project="my-knowledge-community"

诊断走到「问题被消解」「报告输出」「行动方案确定」这类节点时，相关 skill 会主动建议你/dbs-save。后面回来时一句「接着上次」或/dbs-restore 就能继续，不用从头再讲一遍背景。

存档完成后，把报告写入 Obsidian：

Bash

obsidian create \ name="03-Projects/my-project/诊断报告-$(date +%Y%m%d)" \ content="--- type: diagnosis-report project: my-knowledge-community date: $(date +%Y-%m-%d) skills-used: [dbs-diagnosis, dbs-benchmark, dbs-report] session-path: ~/.dbs/sessions/my-knowledge-community/ status: final layer: 2 tags: [diagnosis, project, knowledge-community] --- （粘贴完整的诊断报告内容） " # 同步 git commit git add . git commit -m "diag: my-knowledge-community 第一轮完整诊断 $(date +%Y%m%d)"

五、诊断的进阶用法：「重复诊断」与「诊断对比」

5.1 一个月后重跑诊断，比较前后差异

诊断不是一次性的。好的诊断应该定期重跑，追踪判断的变化：

Bash

# 一个月后，恢复上次存档 cd ~/projects/my-knowledge-community /dbs-restore # 更新业务数据，重新诊断 /dbs-diagnosis

重跑诊断的关键问题：

text

上次诊断后，我做了什么？ 做了之后，哪些指标变化了？ 哪些判断被现实证伪了？ 新的核心问题是什么？

5.2 诊断结论的「时效性」管理

在 Obsidian 里追踪每次诊断的核心结论变化：

Bash

obsidian create \ name="03-Projects/my-project/诊断历史追踪" \ content="--- type: diagnosis-tracker project: my-knowledge-community tags: [tracking, diagnosis] --- # 诊断历史追踪 | 日期 | 成长层级 | 核心问题 | 一句话处方 | 执行情况 | |------|---------|---------|----------|---------| | 2026-06-13 | 第2层 | 没有独立的转化路径 | 先把直播内容资产化 | 进行中 | | （下次诊断后填入） | | | | | "

六、常见诊断误区深度解析

误区 1：把「症状」当「问题」

text

症状：「我的新会员增长很慢」 ↓ 你以为的问题：「我的内容不够好」 ↓ 真正的问题（诊断后）：「没有转化路径」 区分方法：问「为什么」三次 为什么新会员增长慢？→ 因为转化率低 为什么转化率低？→ 因为看完内容后不知道下一步做什么 为什么不知道下一步？→ 因为没有设计转化动作 → 真正的问题找到了

误区 2：对标选错了阶段

text

你在第2层（47个会员）→ 对标第4层（万人规模） → 他的方法论完全不适用于你 正确做法： 找到「刚从第2层跨到第3层」的那类人 研究他们跨越这个门槛「具体做了什么」

误区 3：诊断完了，但没有改变任何判断

text

如果诊断前的判断是「A」，诊断后的判断还是「A」， 那这次诊断是无效的。 有效诊断的标志： 至少有一个「我之前以为是X，诊断后发现是Y」的时刻

误区 4：把「一句话处方」当作全部行动计划

text

诊断报告里的「一句话处方」，是优先级最高的一件事， 不是全部的行动计划。 正确用法： → 先做「一句话处方」 → 做完后，重新诊断 → 再做下一个优先级最高的事 不要同时做报告里所有的建议。

七、与其他 Skill 的完整联动图

text

dbs-diagnosis（商业模式诊断） ↓ 发现概念模糊 → /dbs-deconstruct（先拆清楚概念） ↓ 发现空转目标 → /dbs-goal（重建目标系统） ↓ 发现内容问题 → /dbs-content（内容诊断） dbs-benchmark（对标分析） ↓ 找到对标后 → /dbs-content（学习对标的内容策略） ↓ 发现在贪快 → /dbs-slowisfast（强制慢下来） dbs-report（诊断报告） ↓ 报告完成后 → /dbs-save（存档） → obsidian create（写入知识库） → /dbs-action（把行动项变成可执行任务）

dbs-diagnosis 的主要优势：避免被错误的问题牵着走，提升诊断准确性，并产出可落地的商业模式改善计划。

八、模块 3 作业：提交标准与验收

Markdown

═══════════════════════════════════════════ 📋 模块 3 作业清单 ═══════════════════════════════════════════ 【必交作业】 □ 1. 完成诊断前自我盘点表 要求：5分钟内完成，写第一反应 不可以：查资料、思考太久 □ 2. 完整运行 dbs-diagnosis 体检模式 要求：六个维度都要认真回答 记录：诊断中让你「不舒服」的3个时刻 + 原因 □ 3. 完成对标分析 要求：三个对标候选，都过一遍五重过滤 记录：过滤掉了哪些噪音？保留了哪些有效维度？ □ 4. 生成完整诊断报告（dbs-report） 要求：报告出来后认真回答「你有什么不同意的？」 记录：不同意的地方 + 追问后的新结论 □ 5. 写入 Obsidian 诊断报告 严格按模板，必须包含： - 六个检验结论 - 成长层级判断 - 一句话处方 - 三个下一步行动（有优先级） □ 6. dbs-save 存档 + git commit 格式：「diag: [项目名] 第一轮完整诊断 YYYYMMDD」 □ 7. 建立诊断历史追踪表 即使现在只有一行，也要建起来 【选交作业（加分）】 ○ 8. 诊断完成一周后，对照「一句话处方」 实际执行情况如何？遇到了什么障碍？ 用 /dbs-restore 恢复，追加记录 ○ 9. 用 dbs-chatroom 对诊断结论做多视角验证 「3位不同背景的创业者，会对这份诊断报告提什么质疑？」 ═══════════════════════════════════════════ 【作业提交格式】 Obsidian 诊断报告截图 + 一段总结文字： 「诊断前我以为问题是___，诊断后发现真正的问题是___」 文件命名：模块3-作业-[你的名字]-[项目名].pdf ═══════════════════════════════════════════

九、模块 3 结语：诊断是最被低估的「执行动作」

很多人觉得诊断是「想明白再做」的前置动作，是在浪费时间。

真正做过商业诊断的人知道：诊断本身就是一种执行——它是「停止做错误的事」的执行。

你有没有算过，你在「内容不够好」这个错误判断上，已经投入了多少时间？如果诊断告诉你，真正的问题不是内容，而是转化路径——那之前花在内容上的时间，大部分是浪费的。

17 个 Agent skills 从 12,000+ 条推文中提炼，覆盖商业诊断、内容、对标分析和目标审计。状态管理机制（跨会话的 save、restore、report）修复了大多数 Claude Code 工作流中最大的缺口。

这句话里最关键的词是「跨会话」。

诊断不是一次对话，是一个持续的过程。今天的诊断结论，会被下个月的新数据修正；下个月的修正，会被三个月后的实践检验。

dbs-save + dbs-restore 的价值不是「保存记录」，是「让你的判断系统可以持续迭代」。

这才是 Skill Stack 工作流的核心：不是用 AI 替你思考，而是用 AI 帮你建立一个持续进化的判断系统——一个你自己都可以「存档、恢复、对比、修正」的思维操作系统。

💡  「消解问题，比回答问题，值钱十倍。」 找到真正的问题，执行自然跟上。找错了问题，执行越努力，离答案越远。