/dbs-plain-writing

name: dbs-plain-writing
description: 按事实与功能顺序直接撰写、改写或检查产品、工具、功能、项目和更新说明，内置 ASD-STE100 清晰表达原则，核对主体、动作、指代、术语、条件与承诺强度，保留原意和用户锁定的文字，不加营销钩子、痛点渲染和抽象包装。用户要求平铺直叙地写、不要营销腔、把能力逐条写清、检查措辞歧义或只改指定一处时使用；中文为原则适配，不等于官方符合性认证。
metadata:
  dbs-handoff: |
    - 主题或材料，还没有成稿 → 按信息顺序写成的完整成稿，第一段直接定义对象；缺少会改变事实或范围的信息时只问一个问题
    - 一篇现有文稿，要求整体改写 → 删去钩子、反问、痛点和拔高后按信息顺序重组的全文，不新增事实
    - 现有文稿或文件，只要求改指定一处 → 重读当前版本后只改点名范围，交出该处修改和改动说明，用户改过的内容保持不动
    - 一段文本，只要求检查表达或歧义 → 逐句的原句、问题和建议改法，不改写全文，不覆盖文件
    - 只要求排版、格式转换或去掉行末句号，包括只对指定一处做这类操作 → 只在指定范围执行指定操作，不改措辞
    - 不交出：营销钩子、标题优化、传播建议、材料中没有的功能或效果、ASD-STE100 官方符合性认证

dbs-plain-writing：平铺直叙写作

直接写清楚对象、事实、功能和使用方法。完成用户要求的文章或局部修改，不增加用户没有要求的传播设计。

本 Skill 内置依据 ASD-STE100 清晰表达原则制定的语义核对方法。所需规则与参考文件均在本目录内，不依赖其他 Skill。

工作定义

「平铺直叙」在本 Skill 中表示：

1. 先说明写作对象是什么； 2. 按读者理解所需的信息顺序展开； 3. 一个段落只承担一个信息任务； 4. 枚举型内容逐项说明，不用抽象主题包装； 5. 事实来自用户材料或可核实来源； 6. 语气保持直接、克制、具体； 7. 用户已经确认的表达优先于默认规则。

完成后的文章应让读者直接获得信息，无需先经过情绪铺垫、痛点教育或观点升高。

适用范围

用于以下任务：

• 产品介绍；
• 工具介绍；
• Skill 能力介绍；
• 项目说明；
• 功能清单；
• 使用方法；
• 安装说明；
• 更新说明；
• 已有说明文的平铺直叙改写；
• 文本的歧义检查与清晰表达修改；
• 对现有文件做保留用户修改的局部调整。

用户要求观点文、故事文、销售文、短视频钩子或其他明确体裁时，服从用户指定体裁。只把平铺直叙作为其中的表达要求，不擅自改变任务类型。

模式判断

先判断当前属于哪一种模式。新写、整体改写和局部修改均须执行下文「清晰表达处理」及交付前核对；局部修改仅处理获准范围。只要求排版、格式转换、逐字引用或删除行末句号时，只执行指定操作，不启动措辞改写。只要求对指定一处做这类操作时，先重新读取文件当前版本，只在点名范围内执行指定操作，不改措辞。

新写模式

用户提供主题、材料或要求，希望从零生成文章。

执行：

1. 读取全部材料； 2. 提取已确认事实、专有名词、数字、功能和限制； 3. 根据任务选择信息结构； 4. 直接生成完整成稿； 5. 检查事实、语气、格式和字数。

材料足够时直接写。只有缺少的信息会改变事实正确性、文章范围或交付形式时，才提出一个具体问题。

整体改写模式

用户提供现有文稿，希望去掉营销包装、抽象表达或 AI 套路。

执行：

1. 保留原文事实、顺序要求和专有名词； 2. 识别有信息作用的句子； 3. 删除没有新增信息的钩子、反问、情绪铺垫和拔高； 4. 把模糊标题改成内容标签； 5. 按信息顺序重组； 6. 不添加原文和材料中没有的事实。

局部修改模式

用户已经修改文件，或明确要求只改某一处。

执行：

1. 重新读取文件当前版本； 2. 把当前版本视为唯一工作底稿； 3. 锁定用户已经确认或亲自修改的内容； 4. 只修改用户点名的词、句、段或规则； 5. 不恢复旧版本，不使用先前生成稿覆盖当前文件； 6. 修改后检查目标词和相邻内容； 7. 确认没有产生范围外变化。

用户说「我的修改肯定没问题」「一定要保留我的修改」时，将全部现有修改设为硬锁。除非用户随后明确点名，否则不改这些内容。

检查模式

用户只要求检查表达、歧义或是否符合指定规则时，逐句检查指定范围，给出「原句、问题、建议改法」。说明可能产生的误解；信息不足时指出缺少哪个对象或条件，不猜测改法。检查请求不授权重写或覆盖文件。

清晰表达处理

本节为默认步骤。首次使用本 Skill 时读取本目录的 [标准依据与检查边界](references/standard-and-scope.md)。

1．固定原意与修改边界

写作或改写前，确定以下内容作为内部核对依据：

• 事实、数字、单位、日期、专有名称和来源归属；
• 条件、例外、否定、因果、先后顺序和适用范围；
• 「可能」「可以」「必须」「预计」等承诺或要求的强度；
• 用户要求保留的原文、引语、代码、命令、界面标签和链接；
• 任务范围、体裁、主要观点和作者立场。

沿用用户指定的语言、读者、体裁和篇幅。用户要求改写或检查，但没有提供文本、上下文中也没有目标文本时，请用户提供需要处理的内容，不自行编写示例文本代替。

新写时以提供的材料为依据，改写时对照当前原文。不能把「生成方案」改成「完成执行」，也不能把「有机会改善」改成「保证改善」。缺失信息会改变含义时，先完成不依赖该信息的部分，再提出一个具体问题。

2．逐句检查理解障碍

| 检查对象 | 判断问题 | | --- | --- | | 主体与对象 | 谁做这件事？处理哪个对象？材料是否已说明？ | | 动作 | 读者能否说出具体做什么？动词是否只起情绪或评价作用？ | | 指代 | 「它」「这个」「上述内容」是否可能指向多个对象？ | | 术语 | 同一对象是否用了多个名称？读者是否需要简短定义？ | | 条件与结果 | 条件作用于哪个动作？是否暗示了材料没有的保证？ | | 句子结构 | 是否挤入多个独立判断？条件、原因和结果是否混淆？ | | 段落 | 是否有明确主题？理解后文所需的信息是否齐全？ |

按上下文判断词语，不机械替换。比如「认出照片中的人」对象明确；「认出需要的东西」可能需要补充判断对象，补充内容必须来自材料。

3．在授权范围内修改

• 使用材料已有的主体、动作和对象，优先使用主动句；执行者未知时不猜测；
• 一个句子集中表达一个主要判断，拆句时保留因果、条件、否定和先后顺序；
• 同一对象使用同一名称，允许重复准确术语；首次出现必要术语时简短解释其作用；
• 操作说明写清动作及必要前提；介绍、论证、课程说明等保留原体裁，不统一改成命令句；
• 用已知事实解释模糊评价，不虚构数字、时限、功能、交付物和效果来填补缺口；
• 一个段落集中说明一个主题；并列项目可以列出，相关解释用短段落；
• 删除无信息作用的套话，保留有解释作用的细节、案例和限制；
• 保留正常中文语法、必要成分及句内标点，不逐字模仿英语句法，不把英文词数上限换算成中文字数；
• 行末标点继续按本 Skill 的「行末标点习惯」处理；锁定文字、逐字引用和仅格式操作优先遵守用户的保留要求。

4．对照核实语义

对照原文或新写依据，核对事实、条件、例外、否定、承诺强度与任务范围。确认没有把可能性改成确定结果、删除必要前提、增加产品能力或交付，也没有用另一句抽象话替换原来的抽象话。发现变化先修正，再交付。只有原文信息不足以确定含义时，才在交付中留下明确的问题，说明缺少哪个对象或条件。

标准适用边界

ASD-STE100 面向英语技术文档。本 Skill 的中文步骤属于本地原则适配，不宣称中文通过正式符合性检查。

英文普通改写可直接处理。用户要求英文完整符合性检查时，读取指定版本的完整标准、受控词典及项目术语依据；资料不全时完成可核查部分，说明未核查范围。不得编造规则编号、词典许可或认证结果，也不能凭短句和主动语态宣布全部符合。

普通写作不附标准说明或免责声明。仅在用户询问依据、要求认证或完整符合性检查时，说明相应依据和限制。

信息结构

根据任务选择最短、最自然的结构。不要为了套模板补写无关章节。

产品、工具或 Skill 全介绍

默认顺序：

1. 名称和定义； 2. 作者或来源，仅在用户要求或材料提供时写； 3. 制作方式，仅在用户要求或理解产品需要时写； 4. 能处理什么任务； 5. 安装或使用方法； 6. 功能或能力逐项介绍； 7. 最简单的开始方式。

推荐骨架：

# {名称} 是什么？它有哪些能力？

{名称} 是……

它可以……

## 怎么安装／怎么使用？

{直接说明步骤}

## {名称} 有哪些能力？

### 1. `{功能名称}`

`{功能名称}` 用于……

它会……

使用后会得到……

没有安装步骤时删除安装章节。没有作者或制作过程时不补写。

单项功能说明

优先回答三个问题：

1. 它用于做什么； 2. 它会处理什么； 3. 使用后会得到什么。

默认写法：

### `{功能名称}`

`{功能名称}` 用于……

它会……

使用后会得到……

三句话存在重复时合并，不强行凑满。

更新说明

默认顺序：

1. 更新了什么； 2. 具体变化； 3. 对现有使用方式的影响； 4. 更新方法； 5. 必要的兼容或保留说明。

项目说明

默认顺序：

1. 项目是什么； 2. 由谁负责； 3. 当前包含什么； 4. 怎样使用或参与； 5. 当前状态与限制。

写作规则

直接开始

• 第一段直接写对象的名称和定义；
• 用户指定开头时原样执行；
• 不先描述读者处境；
• 不先解释为什么这篇文章值得读；
• 不先制造一个需要文章解决的矛盾。

按信息排序

• 先写理解后文必须知道的信息；
• 安装和使用方法放在读者需要开始操作的位置；
• 枚举能力时保持相同粒度；
• 功能名称、作用、处理过程和产出分开写清；
• 同一事实只在确有导航作用时重复。

使用具体语言

• 使用准确的产品名、功能名、数字和动作；
• 专有名词保持用户给出的大小写和写法；
• 一个词准确时可以重复，不为避免重复强换同义词；
• 使用「用于」「可以」「会得到」「安装后」等直接句式；
• 用实际动作替代「赋能」「重塑」「构建全新体验」等空泛表达；
• 在获准改写范围内，删除没有来源的最高级、唯一性和效果承诺；涉及用户锁定文字时指出问题，不静默改动。

使用说明型标题

标题直接标明内容：

• 「dbskill 是什么？它有哪些能力？」
• 「怎么安装 dbskill？」
• 「dbskill 有哪些能力？」
• 「`{功能名称}`」

标题只承担导航作用，不制造悬念、焦虑或认知优越感。

控制段落

• 一个段落说明一个事实、动作或结果；
• 同类能力使用一致结构；
• 能用短段落讲清时不扩写；
• 列表适合并列信息，正文适合解释关系；
• 删除不影响信息完整性的总结句和过渡句。

行末标点习惯

• 为 dontbesilent 新写或改写文案时，默认去掉每个手动换行或段落末尾的中文句号「。」；屏幕自动折行不算换行；
• 行末句号位于右引号之前时，同样去掉句号，保留右引号，例如「你就得听我的。」改为「你就得听我的」；
• 保留行内句号，以及问号、感叹号、省略号等其他标点，不把多句话合并成无标点长句；
• 不处理代码、网址、小数点等非文案内容；要求逐字引用或零改写的原文，以及用户明确锁定的文字，优先遵守保留要求，除非用户明确授权调整标点；
• 用户只要求去掉行末句号时，只改这一项，不顺带改写措辞、调整段落或删减内容。

用户文字保护

用户材料的优先级：

1. 用户本轮明确指令； 2. 用户亲自修改并确认的当前版本； 3. 用户提供的事实、名称和格式； 4. 权威来源中的事实； 5. 本 Skill 的默认结构与措辞。

执行文件修改时遵守：

• 先读取当前文件，再修改；
• 不凭对话记忆还原文件；
• 不把用户删掉的内容重新加回；
• 不纠正用户已经确认的表达偏好；
• 发现明显事实冲突时指出冲突，不静默覆盖；
• 用户只要求替换一个词时，只做对应替换；
• 完成后核对是否保留全部范围外内容。

事实规则

• 把用户明确提供的信息视为当前任务事实；
• 涉及版本、数量、价格、支持平台等动态信息时，优先读取用户指定的权威来源；
• 材料之间冲突时保留冲突并请求确认；
• 不从产品名称或文件名推测能力；
• 不把推测写成事实；
• 不编造用户案例、使用效果、读者痛点和市场评价；
• 用户要求忠实整理时只整理格式与结构，不改动事实表达。

默认禁用

用户没有明确要求时，禁止加入：

• 营销钩子；
• 痛点渲染；
• 开头反问；
• 替读者发言；
• 虚构读者处境；
• 焦虑、恐惧或成功承诺；
• 「看完你就懂了」「你一定遇到过」等阅读承诺；
• 「正确的废话」等带立场的包装；
• 「你现在到底该解决什么」等引导型标题；
• 「真正」「本质上」「归根结底」等无必要的升高；
• 「不是……而是……」及其近似变体；
• 为每组功能重新发明一个抽象主题；
• 未经用户确认的「普通用户」「小白」「新手」等人群标签；
• 用户没有要求的案例、比喻、金句和总结；
• 用户没有要求的传播建议、标题优化和平台策略；
• Emoji、感叹号和口号式结尾。

引用原文、分析句式或用户明确要求时，可以保留对应表达。

交互规则

• 用户要求明确、材料充分时直接完成，不重复确认目标；
• 用户问「有没有需要确认的」时，只提出会实际改变结果的问题；
• 不使用「如果做到了，你会指着什么」等已能从交付物直接回答的问题；
• 每次最多提出一个关键问题；
• 可以从文件、目录或权威文档