1实现原理 · 为什么它能做到

纯 prompt 编排，无脚本无外部依赖：全部能力来自 SKILL.md 里的判断框架、提问纪律与输出模板

skills/dbs-jtbd/SKILL.md

本 Skill 从 Jobs to Be Done 视角理解用户要完成的事，用于产品、内容、决策或 AI 协作中的任务澄清。

目录内只有 SKILL.md 与 agents/openai.yaml（界面元数据），无 scripts/references/data。

核心机制是「先看进展、后看方案」：把用户提出的交付物（写文章/做课程/做 Agent）降格为候选手段，再反推其想推进的进展

skills/dbs-jtbd/SKILL.md

用户说「帮我写一篇文章」「我需要一个课程」「给我做一个 Agent」时，先不要把这句话直接当成需求结论。它通常只说明了用户想到的方案。

配套一条五段链：情境 → 卡住的进展 → 想得到的结果 → 当前方案 → 选择标准。

任务陈述被强制成可填充的句式模板，并要求「进展写成变化、结果落在可感知状态」，把模糊形容词挡在输出之外

skills/dbs-jtbd/SKILL.md

当我处于 `{情境}`，我想要 `{推进的进展}`，以便 `{得到的结果}`。

同一段还立了两条反例：不要只复述动作（如「整理访谈」），避免空泛的「提升效率」。

把 JTBD 的三层任务与「雇用/解雇四力」（推力/拉力/焦虑/习惯）作为固定检查表，要求建议同时处理四种力量而非只放大卖点

skills/dbs-jtbd/SKILL.md

一个方案被采用，通常需要推力和拉力强过焦虑与习惯。输出建议时要处理这四种力量，不能只放大卖点。

三层任务表特别点出：功能任务决定交付物，情绪与社会任务常决定表达、阻力与最终选择。

「最小提问」纪律：先基于已有材料写任务假设，只在缺失信息会改变建议时才问 1 个具体事实性问题，并禁用宽泛问法

skills/dbs-jtbd/SKILL.md

只有以下信息缺失且会改变建议时，才问 1 个最小问题：

文中给出的正例是「你上一次试图解决这件事时，卡在了哪一步？」，反例是「你的痛点是什么」「你的目标用户是谁」。

选择标准被要求「可观察、可判断、带优先级」：必须满足 / 加分项 / 可接受代价三类，并要求把「简单好用」这类词还原成可检验表述

skills/dbs-jtbd/SKILL.md

标准要可观察。把「简单好用」还原为「第一次使用 10 分钟内能否得到可修改的结果」这类表述。

这是该 skill 与泛泛「用户画像」话术的主要分野。

输出端按场景分流：与 AI 协作→重写提示词；产品或服务→任务定义与降低切换焦虑；内容销售→情境与可信证据；个人决策→最小验证动作

skills/dbs-jtbd/SKILL.md

| 产品或服务 | 任务定义、雇用时刻、需求优先级、降低切换焦虑的设计 |

并规定：若用户只要一个答案/文案/提示词，不必展示完整框架，内部完成判断后直接交付。

内置针对 AI 协作的提示词骨架，把任务陈述前置，并补情境/材料/边界/交付物/验收标准，让模型从约束推导方案

skills/dbs-jtbd/SKILL.md

把任务陈述放在提示词开头，并补上情境、已有材料、边界、交付物和验收标准。

骨架文末尾还内置「若任务与我的方案错位，请先指出错位」的自纠条款。

2核心能力

01任务澄清：把「我要一个 X」翻译成「当…我想推进…以便…」的任务陈述

02表面请求 vs 任务错位识别（并保留用户原方案作为候选，不武断否定）

03三层任务检查（功能/情绪/社会），且只输出对当前任务有用的层

04切换力量诊断（推力/拉力/焦虑/习惯）

05可观察选择标准的提炼与优先级标注

06按场景产出行动建议（AI 协作/产品服务/内容销售/个人决策四类）

07JTBD 提示词骨架生成（把任务陈述写进提示词开头）

08证据纪律与反画像：不拿人口属性/行业标签/产品名当任务证据，不虚构访谈与行为数据

4管控建议与判定依据

建议配套管控措施

面向 Agent

可自动加载

面向管理者

登记来源与版本

判定依据（文件路径与关键语句摘要）

SKILL.md: 纯提示词指令与规则文本，无脚本执行与外部影响

审计说明： 。判级对象是本 skill 自身目录：目录内只有 SKILL.md 与一份界面元数据 yaml，无脚本、无网络端点、无凭证读取、不写盘，属纯指令型。主要注意点不属代码安全，而是「框架诱导」——JTBD 三层任务与四力表格若被机械套用，可能给出比用户原问题更宏大的任务定义；skill 自身已用「不为了套框架连续发问」「缺证据不硬写」等条款约束。

5第二遍独立确认

[ok] 外部资源/工具：是否存在 SKILL.md 未声明的依赖 — 目录内仅 SKILL.md 与 agents/openai.yaml；token 扫描无 URL/CLI/API/包名命中，external_deps 为空数组成立。agents/openai.yaml 只含 display_name/short_description/default_prompt 三个界面字段，非运行依赖。
[ok] 安全结论：是否真的零文件读写 — 全文无读取或写入指令——不要求读用户文件、不要求落盘产物（唯一「输出」是对话中的 markdown 模板）。相比同批 dbs-save/dbs-report/dbs-knowledge 有明确落盘动作，本 skill 属同批风险最低档。
[ok] 实现原理是否成立：宣称的「切换力量」与「可观察标准」是否真有可执行定义 — 四力表给出每力的具体提问句（如「旧做法造成了什么具体损失、压力或阻塞？」），选择标准要求三分类并标优先级、给出「简单好用→第一次使用 10 分钟内能否得到可修改的结果」的还原示例。非口号式条目。
[unlocatable] 证据定位：star/last_push 等仓库级元数据 — stars 与 last_push 来自站点池 data/pool.json 的 GitHub API 采集值，pin 源码内无此数据，无法在仓库文件内逐字命中；license 可在仓库根 LICENSE 逐字命中。

6结论

把「先问清要解决什么」做成可复用的判断链而非空泛提问：五段链（情境→进展→结果→方案→标准）+ 四力表 + 三层任务，任一条都有具体提问句与输出落点

对 AI 协作场景的落地性最强：直接给可粘贴的提示词骨架，并内置「若任务与我的方案错位，请先指出错位」的自我纠错条款

提问克制：材料够就不追问，只在会改变建议时才问 1 个事实性问题——避免了咨询式 skill 常见的「问卷轰炸」

证据纪律自带：区分事实/推断/待确认，禁止虚构访谈与行为数据，缺证据写假设而非编故事

适合： 适合动工前校准需求的场景：做产品/服务定义、写内容选题、梳理个人决策、或与自己出的 AI 提示词对账——尤其是「用户说的方案未必是真实需求」这一常见错位。也适合内容/咨询从业者把它当提问脚本，直接复用四力表与三层任务做访谈提纲。

不适合： 不适合规格已经明确、只等执行的场景（此时追问反而增加成本）；不适合需要外部数据或验证的商业判断（它不做检索与核对）；不适合需要落盘交付物的流程——本 skill 不产出任何文件，产不出存档、报告或计划文档（应改用 dbs-save / dbs-report / dbs-learning 等）。

Install Agent-Ready

① Verified Mirror 2026-09-15

Option A · Direct DownloadDownload dbs-jtbd.tar.gz

sha256: 236334174ad98f29…

Option B · Copy Guide for Agent

install.json

agent 读 JSON 指南后会自动从本站下载安装，无需更多说明。

② Upstream GitHub

GitHub Repo ↗

Pinned to commit 8b8e33f1ec.