用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/dontbesilent2025/dbskill --skill dbs-standard-answer命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
自动识别用户是在解决具体商业问题，还是希望全面检查商业模式，并进入对应诊断流程。用户希望拆解业务、检查商业模式或消解具体商业困境时使用。
dontbesilent 商业工具箱主入口，提供新手教程、任务前路由和任务后导航。用户不知道该用哪个 dbs Skill、要求分析商业问题或询问下一步时使用。
dontbesilent JTBD 任务澄清。用 Jobs to Be Done 识别具体情境中用户想推进的进展、切换方案的力量与可观察的选择标准，据此优化产品、内容、服务、决策和 AI 提示词。调用名：/dbs-jtbd。用户问「到底要解决什么」「为什么会选择这个方案」「用 JTBD 重写提示词」时使用。
基于 SOC 职业分类
正在显示 SKILL.md
| name | dbs-standard-answer |
| description | 从商业史、管理史、技术史、职业史和制度史中寻找与现实困境同构的成功、失败和反例，提炼带条件的重复机制。用户要求历史类比、经典解法或标准答案时使用。 |
你的任务：先把用户的现实困境压缩成一个可比较的「结构指纹」，再从历史中寻找同构案例。通过成功案例、失败案例和反例的交叉比较，判断过去是否形成了可复用的标准答案，以及这个答案在用户处境中的适用条件。
这里的「标准答案」指多次独立出现、能解释结果差异、适用条件清楚的应对机制。它可以是成熟共识、条件性答案，也可以是「目前没有统一答案」。
| 用户真正要做的事 | 使用 skill |
|---|---|
| 找一个今天可以模仿、学习或竞争的对象 | /dbs-benchmark |
| 诊断当前业务的矛盾、瓶颈和优先级 | /dbs-diagnosis |
| 让不同思想人物分别发表意见 | /dbs-chatroom |
| 理解某个理论或知识 | /dbs-learning |
| 从历史同构案例中提炼重复解法和边界 | /dbs-standard-answer |
用户同时要求历史定位与个性化行动方案时，先完成本 skill。历史研究结束后，把已验证机制、适用条件、证据强度和失效边界写进本轮结论；用户还要继续推进时，交回 /dbs 根据当前目标选择下一步。不要在历史证据形成前直接给用户排任务。
从用户原话、当前对话和用户指定的本地材料中提取：
现实角色：
所处阶段：
必须维持的结果：
正在争夺的稀缺资源：
同时存在的任务：
主要矛盾：
反复出现的失败循环：
用户当前希望先得到什么：
材料足够时直接形成暂定判断。只有缺失信息会改变历史案例类别时，才问 1 个最小问题。
将现实困境转写成可跨时代比较的结构：
| 维度 | 要回答的问题 |
|---|---|
| 主体 | 个体创作者、创始人、职业经理人、团队还是组织？ |
| 阶段 | 生存、增长、规模化、转型、守成还是衰退？ |
| 收入结构 | 单一现金牛、项目制、订阅、周期性销售还是多业务组合？ |
| 稀缺资源 | 时间、注意力、现金、人才、信任还是渠道？ |
| 核心张力 | 当前交付与能力建设、亲自做与组织化、短期销售与长期探索等 |
| 锁定机制 | 哪个必要任务不断占用资源，使解决它的能力无法建立？ |
| 压力机制 | 波动、目标抬升、身份期待、沉没成本或组织惯性怎样影响决策？ |
| 理想转变 | 用户希望从什么状态进入什么状态？ |
最后写成一句「结构命题」：
一个处于
{阶段}的{主体}，依赖{收入或交付结构}，因{锁定机制}无法投入{能力建设}，同时受到{压力机制}的持续牵引。
先列 3–6 个候选问题家族，再去找人物：
这些只是示例。根据用户的结构指纹生成更准确的搜索假设。
每个假设写清：
候选问题家族：
它与现实问题共享的结构：
可能破坏类比的差异：
需要寻找的证据：
先查用户指定材料和本地知识库。涉及具体人物、时间、决策、结果、理论归属或原话时，使用联网检索核验。
来源优先级：
每个核心事实尽量找到 2 个独立来源。引用具体页面，避免只给搜索结果页。找不到可靠证据时，写明「尚未核验」，并降低结论强度。
默认选择 4–6 个案例，并覆盖下面四种证据角色：
失败案例与反例承担不同任务，不能互相替代。某一类确实找不到时，必须说明搜索范围、缺失原因及其对结论强度的影响。
每个案例使用同一组字段，防止只挑对结论有利的细节：
## 案例：{人物／组织，时间}
- 原始处境：
- 真实约束：
- 当时可选方案：
- 实际决策：
- 执行成本：
- 后续结果：
- 证据：
- 证据状态：已核验事实／研究者解释／本次推断／待核验
- 与用户相同之处：
- 与用户不同之处：
- 类比有效性：高／中／低
- 能提取的机制：
- 不能照搬的部分：
不要伪造当事人的内心动机。只有行为和材料能支持时，才描述动机。
把现实问题与所有案例放入同一张表：
| 案例 | 阶段相似 | 收入结构相似 | 稀缺资源相似 | 锁定机制相似 | 压力机制相似 | 结果可比 | 总体可信度 |
|---|
评分使用高／中／低，并补 1 句理由。不要用未经定义的精确分数制造确定感。
若一个案例只有行业或人物身份相似，结构维度大多为低，则淘汰。
寻找能够解释「为什么某些人走出来、某些人仍被困住」的差异：
| 重复机制 | 出现在哪些案例 | 可能的因果解释 | 成立条件 | 失败边界 | 证据强度 |
|---|---|---|---|---|---|
常见机制可能涉及：
这些只是候选机制。没有案例证据时不要提前采用。
按证据输出三种结论之一：
多个高可信案例与系统研究同时支持同一机制，经过失败案例和反例检验后仍然成立，且适用条件稳定。只有案例故事收敛、缺少系统研究时，最多标为条件性答案。
机制反复有效，但依赖规模、现金流、人才供给、行业节奏或个人目标。必须把条件写进答案。
案例分歧明显，或历史条件差异足以破坏类比。此时给出不同路径的适用场景，保留不确定性。
标准答案使用下面的句式：
当
{条件}成立时，历史上反复有效的做法是{机制}，因为{因果解释}。当{边界}出现时，这个答案容易失效。
避免把工具名、某位名人的个人习惯或一句格言当成标准答案。
根据用户授权选择停止位置：
| 用户要求 | 停止位置 |
|---|---|
| 「先定位」「先找历史类比」「先别回答我的问题」 | 给出结构定位、案例研究计划、候选问题家族；等待用户确认后再深挖 |
| 「研究以前怎么解决」 | 完成案例、类比矩阵和标准答案 |
| 「结合我现在怎么办」 | 在历史研究后增加 1–3 个可验证动作 |
| 「帮我做完整计划」 | 完成历史研究并输出可交接结论，再交回 /dbs 根据现实目标选择下一步 |
不要因为掌握了一个历史答案，就自动替用户作出现实决策。
## 当前问题的历史定位
**结构命题**：{一句话}
**结构指纹**：
- 主体与阶段：
- 收入与交付：
- 稀缺资源：
- 核心张力：
- 锁定循环：
- 压力机制：
## 候选问题家族
| 问题家族 | 相似结构 | 关键差异 | 研究价值 |
|---|---|---|---|
## 历史案例
{按统一字段写 3–5 个案例}
## 类比有效性
{类比矩阵与淘汰说明}
## 反复出现的机制
{重复机制表}
## 标准答案判断
**结论等级**：成熟共识／条件性答案／尚无统一答案
**答案**：{带条件和边界的机制}
## 对当前问题的启发
{遵守用户授权深度}
## 尚待确认
- {会改变案例选择或结论的事实}
## 资料来源
- {可点击的具体来源}
用户只要求研究计划时，省略尚未研究的案例结论，输出搜索假设、选例标准、证据标准和下一轮要查的材料。
交付前逐项检查：
完成当前任务后直接结束。只有用户明确询问下一步，且当前环境已经安装 /dbs 时，简短提示：「下一步不确定时，可以输入 /dbs。」