尧图网站建设 
dbskill 问题单元模板深度解析从 YAML frontmatter 到 QST 内容单元的实战指南【免费下载链接】dbskilldontbesilent 的商业诊断 Skills项目地址: https://gitcode.com/gh_mirrors/db/dbskill导读dbs-content-system 是 dontbesilent 内容结构化系统的核心 skill它把本地大量文稿、推文、选题、案例和课程稿搭成一个可持续生长的内容工程而**问题单元QST**是其中定义「内容要回答什么问题」的骨架单元。本篇以仓库中的 问题单元模板 为蓝本结合同目录下的概念、观点、案例、方案四份模板、内容单元字段规范 与 generate-unit-draft.js 等源码完整讲解 QST 单元的字段语义、手写/脚本生成两种落盘方式、与其他单元的关系建立以及它在「审计 → 样本 → 批量 → 全量」四档工作流中的实际用途。读完你将能够独立创建一份合格的问题单元并理解它如何支撑主题地图与选题装配。一、问题单元在内容结构化系统中的定位1.1 五类内容单元的最小语义对象dbs-content-system的第四原则是「对象不是文件而是内容单元」内容不被当作文件夹来整理而是被拆成可复用的最小语义对象。首期只保留 5 类前缀类型职责QST问题单元记录一个值得回答的问题原句、问题类型与适用人群CON概念单元固定一个概念的稳定定义与其功能OPI观点单元固定核心判断、适用范围与重要性CAS案例单元记录案例主体、摘要、过程与结果SOL方案单元记录目标问题、方案摘要、动作步骤与预期结果其中QST处于抽取链路的最前端在 首批样本自动抽取协议 中每篇样本文稿强制抽取的第一个单元就是「1 个主问题单元QST」随后才是观点OPI、概念CON、案例CAS与方案SOL。1.2 QST 单元要回答的两个问题从模板与字段规范看问题单元回答两个问题内容在问什么——由question_text问题原句与question_type问题类型承载这个问题为谁、为哪些选题而存在——由user_stage用户阶段与applicable_topics适用选题承载。二、问题单元模板逐字段解析2.1 完整模板原文仓库中的 问题单元模板 全文如下--- id: QST-YYYYMMDD-001 type: 问题单元 title: 标题 source_documents: - SRC-* source_authors: - 待补 themes: - 主题 keywords: - 关键词 status: 待核对 canonical: true version: 1 created_at: YYYY-MM-DD updated_at: YYYY-MM-DD question_text: 问题原句 question_type: 认知问题 user_stage: 起步期 applicable_topics: - 适用选题 relationships: [] --- ## 核心内容 ## 来源依据 ## 使用场景 ## 关联单元 ## 备注2.2 通用字段五类单元共用根据 内容单元字段规范每个内容单元必须包含以下 13 个通用字段字段含义取值建议id单元唯一标识QST-YYYYMMDD-001形式日期三位序号type单元类型固定为问题单元title标题一句话概括问题主题source_documents来源文档 ID默认SRC-*后替换为真实来源source_authors来源作者默认待补themes所属主题一个或多个主题词keywords关键词供检索与聚类status状态默认待核对canonical是否主单元合并去重时true者为主单元version版本号语义变化才递增created_at/updated_at创建/更新时间YYYY-MM-DDrelationships关联关系空为[]2.3 类型专属字段问题单元独有除通用字段外问题单元多出 4 个专属字段字段含义示例question_text问题原句用户真实提出的问题尽量保持原话question_type问题类型认知问题/方法问题见 2.4 判定规则user_stage用户所处阶段起步期、成长期等applicable_topics适用选题该问题可以支撑的选题列表2.4question_type的判定口径来自抽取器源码虽然模板中question_type默认写认知问题但 extract-sample-units.js 中的detectQuestionType函数给出了可操作的判定规则命中为什么 / 本质 / 根本 / 误区 / 错在→认知问题命中怎么 / 如何 / 怎样 / 步骤 / 路径 / 开始 / 落地→方法问题两者都不命中 →待人工复核。这提醒我们手工填写时也应遵循同一口径保证全库判断一致。三、从模板到真实单元两种落盘方式3.1 手工填写最小合格样例把模板中的占位符替换为真实内容即可--- id: QST-20260602-192 type: 问题单元 title: 什么样的兴趣能真正变现 source_documents: - SRC-20260602-011 source_authors: - dontbesilent themes: - 兴趣变现 keywords: - 生产型兴趣 - 变现 status: 待核对 canonical: true version: 1 created_at: 2026-06-02 updated_at: 2026-06-02 question_text: 什么样的兴趣属于可以变现的生产型兴趣以及怎样把兴趣、能力和具体业务接起来做成可持续增长 question_type: 认知问题 user_stage: 起步期 applicable_topics: - 年轻人怎么赚钱 relationships: [] --- ## 核心内容 什么样的兴趣可以变成钱是内容库里反复出现的主问题。本单元将其固定为可复用问题节点供主题地图与装配稿引用。 ## 来源依据 来源文稿《兴趣变现实操》核心段落SRC-20260602-011。 ## 使用场景 - 兴趣变现主题地图的主问题 - 「年轻人怎么赚钱」选题装配稿的开场问题 ## 关联单元 - [[CON-20260602-190|生产型兴趣]]解释 - [[OPI-20260602-200|兴趣变现三要素]]回应 ## 备注 question_type 按规则命中「为什么/本质」判为认知问题待人工核对 user_stage 是否覆盖成长期人群。注意模板中question_text: 问题原句、question_type: 认知问题、user_stage: 起步期等默认值应当被替换为真实内容relationships: []在建立关系后要按 内容单元关系规则 的格式改写。3.2 脚本生成generate-unit-draft.js手工从零写空文件容易出错。dbs-content-system自带 generate-unit-draft.js它会读取模板并替换占位符。用法node 07-脚本与工具/generate-unit-draft.js QST|CON|OPI|CAS|SOL YYYYMMDD 序号3位 标题 [sourceId] [theme] [keyword] [author]生成 QST 单元的例子node 07-脚本与工具/generate-unit-draft.js QST 20260602 192 什么样的兴趣能真正变现 SRC-20260602-011 兴趣变现 生产型兴趣 dontbesilent从源码看该脚本的核心行为id拼接规则为${prefix}-${date}-${seq}即QST-20260602-192类型前缀映射typeMap把QST指向问题单元/问题单元模板.md输出目录为02-内容单元库/问题单元/文件名固定为ID_标题.md例如QST-20260602-192_什么样的兴趣能真正变现.md通过正则替换模板中的QST-YYYYMMDD-001、title: 标题、SRC-*、待补、主题、关键词、created_at、updated_at等占位符若目标文件已存在会直接报错退出避免覆盖。3.3 样本抽取extract-sample-units.js 自动产出 QST在首批样本阶段推荐直接用 extract-sample-units.js 从样本文稿批量抽取node 07-脚本与工具/extract-sample-units.js --files 完整副本/兴趣变现.md,完整副本/找生意.md从源码可以推断该脚本会先对每个来源做分类成稿、短稿、推文合集等再从正文中提取问题原句buildMainQuestion调用detectQuestionType判定question_type用inferTheme推断themes并自动生成nextId序号扫描02-内容单元库/问题单元/下已有QST-YYYYMMDD-前缀文件取最大值 1最后落盘到02-内容单元库/问题单元/并更新抽取日志与处理状态总览。脚本产出的仍是「草稿」需要按 新增文稿进入系统流程 人工复核。四、问题单元如何与其他单元建立关系4.1 四种允许的关系类型内容单元关系规则 规定第一期只允许 4 类关系关系语义典型方向回应直接回应另一个问题、判断或方案回应方 → 被回应对象解释概念解释问题、观点或方案概念单元 → 被解释对象证明案例证明观点、方案或问题判断案例单元 → 被证明对象冲突判断方向、适用边界或结论直接冲突建议双向建立并补note4.2 relationships 的两种写法空关系模板默认relationships: []存在关系时内容单元字段规范 示例relationships: - type: 解释 target: CON-20260602-001 note: 用于定义判断边界问题单元最常见的两种关系是被解释概念单元CON用解释指向问题单元把问题中出现的术语边界固定下来被回应观点单元OPI用回应指向问题单元表示该观点是对这个问题的直接回答。4.3 正文中的链接纪律SKILL.md 明确frontmatter 中的id、relationships.target保留结构化 ID正文里引用其他内容单元、主题地图、装配稿时统一写[[文件名]]。对应地fill-obsidian-links.js 会把正文中的结构化 ID 补成[[文件名]]方便在 Obsidian 中看到节点关系。五、问题单元在四档工作流中的用途dbs-content-system固定分为审计、样本、批量、全量四个模式默认永远从审计模式进入闸门全过才升档。QST 单元在其中的角色阶段QST 的产出要求审计模式不产出单元只锁定边界与规模样本模式每篇样本文稿至少强制抽取 1 个主 QST并补齐source_documents、themes、keywords、relationships批量模式按批次推进来源分类器先分流每批复盘字段/关系/去重是否变动全量模式以既有规则滚动扩展覆盖率不得重新发明字段、关系或去重类型进入「样本模式 → 批量模式」的闸门中明确要求「QST / CON / OPI / CAS / SOL的判断口径已经稳定」以及「回应 / 解释 / 证明 / 冲突的关系口径已经稳定」因此问题单元的question_type判定规则与关系方向纪律直接决定系统能否安全升档。在 Phase 5 建立主题地图与选题装配稿时QST 通常作为主题地图的主问题节点在 assemble-topic-from-units.js 组装新选题时问题单元通过--question QST-...,QST-...参数被装配进新稿的骨架。六、版本、去重与状态管理6.1 canonical 与 version内容单元去重与版本规则 规定去重类型第一期只允许完全重复 / 同义重复 / 近似重复 / 重复讲述4 类完全重复与同义重复默认合并合并时必须指定canonical: true的主单元作为当前有效对象只有语义边界、适用范围、核心结论或关键步骤发生变化才提升version。对问题单元而言「问题原句」就是它的语义边界——如果两个 QST 的问题原句只是措辞不同而指向同一问题应合并并保留一个canonical: true的主单元。6.2 状态流转status: 待核对是模板默认状态配合03-处理状态/下的已处理清单、待处理清单与 处理状态总览 一起跟踪。新抽取的 QST 草稿在人工复核后将status从待核对提升为可用态同时把version保持在当前有效版本历史变化交给 Git 管理。七、填写检查清单自检新建或复核一份 QST 单元时逐项确认id满足QST-YYYYMMDD-三位序号且不与库内已有 ID 重复type: 问题单元未写错question_text是问题原句而不是一段结论question_type按「为什么/本质→认知问题怎么/如何→方法问题」口径判定user_stage与目标读者阶段一致source_documents、source_authors已替换SRC-*/待补占位符themes、keywords可被检索与聚类relationships为空则写[]非空则符合 4 类关系之一并保留结构化 ID正文引用一律用[[文件名]]不用裸 IDcreated_at/updated_at格式为YYYY-MM-DD八、相关文件速查模板问题单元模板本文主体、概念单元模板、观点单元模板、案例单元模板、方案单元模板规则内容单元字段规范、内容单元关系规则、内容单元去重与版本规则、处理流程工具generate-unit-draft.js单单元落盘、extract-sample-units.js批量抽取、fill-obsidian-links.jsID 转[[文件名]]、assemble-topic-from-units.js选题装配总览SKILL.md、快速上手掌握问题单元模板等于掌握了整个内容结构化系统的入口语义先锁定「问什么」才能谈观点、概念、案例与方案的组装。【免费下载链接】dbskilldontbesilent 的商业诊断 Skills项目地址: https://gitcode.com/gh_mirrors/db/dbskill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 dbskill 问题单元模板深度解析：从 YAML frontmatter 到 QST 内容单元的实战指南
dbskill 问题单元模板深度解析从 YAML frontmatter 到 QST 内容单元的实战指南【免费下载链接】dbskilldontbesilent 的商业诊断 Skills项目地址: https://gitcode.com/gh_mirrors/db/dbskill导读dbs-content-system 是 dontbesilent 内容结构化系统的核心 skill它把本地大量文稿、推文、选题、案例和课程稿搭成一个可持续生长的内容工程而**问题单元QST**是其中定义「内容要回答什么问题」的骨架单元。本篇以仓库中的 问题单元模板 为蓝本结合同目录下的概念、观点、案例、方案四份模板、内容单元字段规范 与 generate-unit-draft.js 等源码完整讲解 QST 单元的字段语义、手写/脚本生成两种落盘方式、与其他单元的关系建立以及它在「审计 → 样本 → 批量 → 全量」四档工作流中的实际用途。读完你将能够独立创建一份合格的问题单元并理解它如何支撑主题地图与选题装配。一、问题单元在内容结构化系统中的定位1.1 五类内容单元的最小语义对象dbs-content-system的第四原则是「对象不是文件而是内容单元」内容不被当作文件夹来整理而是被拆成可复用的最小语义对象。首期只保留 5 类前缀类型职责QST问题单元记录一个值得回答的问题原句、问题类型与适用人群CON概念单元固定一个概念的稳定定义与其功能OPI观点单元固定核心判断、适用范围与重要性CAS案例单元记录案例主体、摘要、过程与结果SOL方案单元记录目标问题、方案摘要、动作步骤与预期结果其中QST处于抽取链路的最前端在 首批样本自动抽取协议 中每篇样本文稿强制抽取的第一个单元就是「1 个主问题单元QST」随后才是观点OPI、概念CON、案例CAS与方案SOL。1.2 QST 单元要回答的两个问题从模板与字段规范看问题单元回答两个问题内容在问什么——由question_text问题原句与question_type问题类型承载这个问题为谁、为哪些选题而存在——由user_stage用户阶段与applicable_topics适用选题承载。二、问题单元模板逐字段解析2.1 完整模板原文仓库中的 问题单元模板 全文如下--- id: QST-YYYYMMDD-001 type: 问题单元 title: 标题 source_documents: - SRC-* source_authors: - 待补 themes: - 主题 keywords: - 关键词 status: 待核对 canonical: true version: 1 created_at: YYYY-MM-DD updated_at: YYYY-MM-DD question_text: 问题原句 question_type: 认知问题 user_stage: 起步期 applicable_topics: - 适用选题 relationships: [] --- ## 核心内容 ## 来源依据 ## 使用场景 ## 关联单元 ## 备注2.2 通用字段五类单元共用根据 内容单元字段规范每个内容单元必须包含以下 13 个通用字段字段含义取值建议id单元唯一标识QST-YYYYMMDD-001形式日期三位序号type单元类型固定为问题单元title标题一句话概括问题主题source_documents来源文档 ID默认SRC-*后替换为真实来源source_authors来源作者默认待补themes所属主题一个或多个主题词keywords关键词供检索与聚类status状态默认待核对canonical是否主单元合并去重时true者为主单元version版本号语义变化才递增created_at/updated_at创建/更新时间YYYY-MM-DDrelationships关联关系空为[]2.3 类型专属字段问题单元独有除通用字段外问题单元多出 4 个专属字段字段含义示例question_text问题原句用户真实提出的问题尽量保持原话question_type问题类型认知问题/方法问题见 2.4 判定规则user_stage用户所处阶段起步期、成长期等applicable_topics适用选题该问题可以支撑的选题列表2.4question_type的判定口径来自抽取器源码虽然模板中question_type默认写认知问题但 extract-sample-units.js 中的detectQuestionType函数给出了可操作的判定规则命中为什么 / 本质 / 根本 / 误区 / 错在→认知问题命中怎么 / 如何 / 怎样 / 步骤 / 路径 / 开始 / 落地→方法问题两者都不命中 →待人工复核。这提醒我们手工填写时也应遵循同一口径保证全库判断一致。三、从模板到真实单元两种落盘方式3.1 手工填写最小合格样例把模板中的占位符替换为真实内容即可--- id: QST-20260602-192 type: 问题单元 title: 什么样的兴趣能真正变现 source_documents: - SRC-20260602-011 source_authors: - dontbesilent themes: - 兴趣变现 keywords: - 生产型兴趣 - 变现 status: 待核对 canonical: true version: 1 created_at: 2026-06-02 updated_at: 2026-06-02 question_text: 什么样的兴趣属于可以变现的生产型兴趣以及怎样把兴趣、能力和具体业务接起来做成可持续增长 question_type: 认知问题 user_stage: 起步期 applicable_topics: - 年轻人怎么赚钱 relationships: [] --- ## 核心内容 什么样的兴趣可以变成钱是内容库里反复出现的主问题。本单元将其固定为可复用问题节点供主题地图与装配稿引用。 ## 来源依据 来源文稿《兴趣变现实操》核心段落SRC-20260602-011。 ## 使用场景 - 兴趣变现主题地图的主问题 - 「年轻人怎么赚钱」选题装配稿的开场问题 ## 关联单元 - [[CON-20260602-190|生产型兴趣]]解释 - [[OPI-20260602-200|兴趣变现三要素]]回应 ## 备注 question_type 按规则命中「为什么/本质」判为认知问题待人工核对 user_stage 是否覆盖成长期人群。注意模板中question_text: 问题原句、question_type: 认知问题、user_stage: 起步期等默认值应当被替换为真实内容relationships: []在建立关系后要按 内容单元关系规则 的格式改写。3.2 脚本生成generate-unit-draft.js手工从零写空文件容易出错。dbs-content-system自带 generate-unit-draft.js它会读取模板并替换占位符。用法node 07-脚本与工具/generate-unit-draft.js QST|CON|OPI|CAS|SOL YYYYMMDD 序号3位 标题 [sourceId] [theme] [keyword] [author]生成 QST 单元的例子node 07-脚本与工具/generate-unit-draft.js QST 20260602 192 什么样的兴趣能真正变现 SRC-20260602-011 兴趣变现 生产型兴趣 dontbesilent从源码看该脚本的核心行为id拼接规则为${prefix}-${date}-${seq}即QST-20260602-192类型前缀映射typeMap把QST指向问题单元/问题单元模板.md输出目录为02-内容单元库/问题单元/文件名固定为ID_标题.md例如QST-20260602-192_什么样的兴趣能真正变现.md通过正则替换模板中的QST-YYYYMMDD-001、title: 标题、SRC-*、待补、主题、关键词、created_at、updated_at等占位符若目标文件已存在会直接报错退出避免覆盖。3.3 样本抽取extract-sample-units.js 自动产出 QST在首批样本阶段推荐直接用 extract-sample-units.js 从样本文稿批量抽取node 07-脚本与工具/extract-sample-units.js --files 完整副本/兴趣变现.md,完整副本/找生意.md从源码可以推断该脚本会先对每个来源做分类成稿、短稿、推文合集等再从正文中提取问题原句buildMainQuestion调用detectQuestionType判定question_type用inferTheme推断themes并自动生成nextId序号扫描02-内容单元库/问题单元/下已有QST-YYYYMMDD-前缀文件取最大值 1最后落盘到02-内容单元库/问题单元/并更新抽取日志与处理状态总览。脚本产出的仍是「草稿」需要按 新增文稿进入系统流程 人工复核。四、问题单元如何与其他单元建立关系4.1 四种允许的关系类型内容单元关系规则 规定第一期只允许 4 类关系关系语义典型方向回应直接回应另一个问题、判断或方案回应方 → 被回应对象解释概念解释问题、观点或方案概念单元 → 被解释对象证明案例证明观点、方案或问题判断案例单元 → 被证明对象冲突判断方向、适用边界或结论直接冲突建议双向建立并补note4.2 relationships 的两种写法空关系模板默认relationships: []存在关系时内容单元字段规范 示例relationships: - type: 解释 target: CON-20260602-001 note: 用于定义判断边界问题单元最常见的两种关系是被解释概念单元CON用解释指向问题单元把问题中出现的术语边界固定下来被回应观点单元OPI用回应指向问题单元表示该观点是对这个问题的直接回答。4.3 正文中的链接纪律SKILL.md 明确frontmatter 中的id、relationships.target保留结构化 ID正文里引用其他内容单元、主题地图、装配稿时统一写[[文件名]]。对应地fill-obsidian-links.js 会把正文中的结构化 ID 补成[[文件名]]方便在 Obsidian 中看到节点关系。五、问题单元在四档工作流中的用途dbs-content-system固定分为审计、样本、批量、全量四个模式默认永远从审计模式进入闸门全过才升档。QST 单元在其中的角色阶段QST 的产出要求审计模式不产出单元只锁定边界与规模样本模式每篇样本文稿至少强制抽取 1 个主 QST并补齐source_documents、themes、keywords、relationships批量模式按批次推进来源分类器先分流每批复盘字段/关系/去重是否变动全量模式以既有规则滚动扩展覆盖率不得重新发明字段、关系或去重类型进入「样本模式 → 批量模式」的闸门中明确要求「QST / CON / OPI / CAS / SOL的判断口径已经稳定」以及「回应 / 解释 / 证明 / 冲突的关系口径已经稳定」因此问题单元的question_type判定规则与关系方向纪律直接决定系统能否安全升档。在 Phase 5 建立主题地图与选题装配稿时QST 通常作为主题地图的主问题节点在 assemble-topic-from-units.js 组装新选题时问题单元通过--question QST-...,QST-...参数被装配进新稿的骨架。六、版本、去重与状态管理6.1 canonical 与 version内容单元去重与版本规则 规定去重类型第一期只允许完全重复 / 同义重复 / 近似重复 / 重复讲述4 类完全重复与同义重复默认合并合并时必须指定canonical: true的主单元作为当前有效对象只有语义边界、适用范围、核心结论或关键步骤发生变化才提升version。对问题单元而言「问题原句」就是它的语义边界——如果两个 QST 的问题原句只是措辞不同而指向同一问题应合并并保留一个canonical: true的主单元。6.2 状态流转status: 待核对是模板默认状态配合03-处理状态/下的已处理清单、待处理清单与 处理状态总览 一起跟踪。新抽取的 QST 草稿在人工复核后将status从待核对提升为可用态同时把version保持在当前有效版本历史变化交给 Git 管理。七、填写检查清单自检新建或复核一份 QST 单元时逐项确认id满足QST-YYYYMMDD-三位序号且不与库内已有 ID 重复type: 问题单元未写错question_text是问题原句而不是一段结论question_type按「为什么/本质→认知问题怎么/如何→方法问题」口径判定user_stage与目标读者阶段一致source_documents、source_authors已替换SRC-*/待补占位符themes、keywords可被检索与聚类relationships为空则写[]非空则符合 4 类关系之一并保留结构化 ID正文引用一律用[[文件名]]不用裸 IDcreated_at/updated_at格式为YYYY-MM-DD八、相关文件速查模板问题单元模板本文主体、概念单元模板、观点单元模板、案例单元模板、方案单元模板规则内容单元字段规范、内容单元关系规则、内容单元去重与版本规则、处理流程工具generate-unit-draft.js单单元落盘、extract-sample-units.js批量抽取、fill-obsidian-links.jsID 转[[文件名]]、assemble-topic-from-units.js选题装配总览SKILL.md、快速上手掌握问题单元模板等于掌握了整个内容结构化系统的入口语义先锁定「问什么」才能谈观点、概念、案例与方案的组装。【免费下载链接】dbskilldontbesilent 的商业诊断 Skills项目地址: https://gitcode.com/gh_mirrors/db/dbskill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考