document-writer

name	document-writer
description	根据用户提供的链接或素材，单篇或批量撰写中文 AI 玩法教程和 AI 字段教程。只要用户要求把链接内容写成玩法分享、知识分享、AI 提效案例、字段介绍、字段使用教程，或要求学习参考文章的结构与版式时，都应使用本 skill。先完整读取来源，再确认教程类型、标题和需要增删的内容，自适应设计大纲，输出美观简洁、结构清楚、可直接发布到钉钉文档的成稿。

AI 教程写作

目标

把用户提供的链接、原文和补充材料，写成容易理解、看完可以动手操作的 AI 教程。文章应像真实的知识分享：先让读者理解问题和价值，再展示效果并带着读者完成操作。

本 skill 只处理两类文章：

• 玩法教程：围绕真实工作或生活场景，讲清怎样组合使用 AI 提高效率，重点是场景、完整流程、结果和经验。
• 字段教程：围绕一个 AI 字段或同系列字段，讲清字段是做什么的、输入什么、输出什么、怎样配置和使用。

1. 先完整读取来源

收到链接后先阅读全文，再向用户确认写作方向。钉钉文档使用钉钉文档读取能力，普通网页使用可读取网页正文的能力。提取以下信息：

• 文章解决的问题、适用对象和实际场景
• 产品、字段、输入、输出、参数、限制和操作入口
• 真实存在的版本、模式或子玩法，以及它们的共享步骤、差异和选择条件
• 原文中的步骤、案例、图片、视频、附件和链接位置
• 可以复用的事实，以及只属于原文的表达和推广内容

把来源信息分为三类：已核实事实、仅用于教学的写作示例、尚待补充的素材或参数。只有已核实事实可以写成确定陈述；示例只放在明确标注的示例位置；未知图片、视频或参数只使用具体占位，不补写成已经存在的结果。

存在多个相近的输入、链接、附件或结果对象时，先建立内部称谓表，记录“对象用途 → 真实字段名 → 来源 → 去向”。这张表只用于写作校验，不强制展示在成稿中；正文始终使用已经核实的名称，不把用途不同的对象混成同一个称呼。

读取不完整时说明缺失范围并请用户补充，不根据标题猜正文。用户提供的范文默认只影响当前任务；是否把本次反馈沉淀为长期规则，按“7. 任务后的增量学习”判断，不因单篇范文自动固化。

来源文章需要重新组织标题、顺序和表达，不做逐句换词。只处理用户有权使用的材料，不帮助隐藏抄袭或伪造原创归属。详细规则见 references/rewrite-mode.md。

2. 再做简短确认

读完来源后，把已经识别的信息填入确认卡，不重复询问用户已经说过的内容：

请确认本次教程：
- 类型：玩法教程 / 字段教程
- 标题：用户指定 / 根据内容拟定
- 主要方向：
- 内容调整：无 / 需要增加…… / 需要删除……
- 写作方式：根据链接原创重构 / 只参考结构 / 修改已有教程

请回复“确认”，或直接修改上面的内容。

默认用途为对外知识分享，不必每次重复询问受众。用户已经说明具体人群时，按其真实场景调整讲解深度，称呼与适用范围的表达遵循第 4 节。用户已经说“确认”“直接写”“开始写”或“无需再确认”时，视为已确认，不再设置第二道确认。

读完来源仍无法判断教程类型时，在卡片中标记“待确认”；缺少标题时主动拟定，不要因此卡住。

3. 选择教程路径

• 写玩法教程前，读取 references/reference-style.md。
• 写字段教程前，读取 references/field-tutorial-style.md。
• 同一请求同时包含玩法教程和字段教程时，分别读取两份规范并分别成稿，不把两种结构混在一起。
• 用户一次要求两篇及以上或明确要求批量撰写时，额外读取 references/batch-mode.md；共享版式，不共享未经当前来源核实的字段、参数、限制、示例、图片或链接。

章节标题、数量和顺序可以按照内容增删、合并或改名，但以下信息大类不能缺失：

玩法教程必须覆盖

1. 使用场景、痛点和适合人群
2. AI 在流程中做什么、能带来什么结果
3. 效果、案例或最终产出
4. 可以直接照做的完整步骤
5. 关键技巧、限制和注意事项

字段教程必须覆盖

1. 字段用途和适合人群
2. 输入、处理过程、输出和效果
3. 最快上手方法
4. 配置项及填写方法
5. 手动添加或接入工作流的方法（确有需要时）
6. 使用限制和注意事项

可以把多个信息大类合并在同一章节，但不能为了追求短文而删掉关键说明。来源没有提供必要事实时使用“待补充”，不要编造。

4. 按真实使用场景写作

• 成稿不把经验、能力或熟练程度写成对读者的身份判断。标题、章节、提示框、表格、图片占位和正文直接说明场景、任务、操作与收益；确需称呼时使用“你”“读者”或“用户”，也可以省略主语。用户在需求中使用的能力或经验描述通常只用于判断讲解应有多具体；当它确实影响步骤、权限、版本或适用范围时，改写成客观前置条件、教程范围或任务状态，不使用“你是……”式分类。只有用户明确要求逐字保留或必须引用时例外。
• 第一次出现专业词、字段名或按钮名时，用一句白话解释。
• 先说“为什么要用”，再说“怎么操作”；步骤按真实点击和使用顺序排列。
• 先交代真实准备项，再进入操作；同时存在现成模板和手动配置时，先给能完成一次运行的模板最短路径，再讲自定义配置，避免把入口、授权和业务操作混成一段。
• 流程同时包含自动处理、按需手动运行和允许为空的结果时，先核实真实依赖顺序，再分别写清哪些会自动完成、哪些需要手动触发、什么情况下空结果属于正常现象。不要笼统称为“全自动”，也不要让读者在上游结果尚未产生时提前运行下游。
• 每个步骤只承担一个主要动作，写清入口、操作和预期结果。
• 「使用技巧」按“遇到什么情况 → 具体怎么做 → 应看到什么结果”写，只使用已核实的字段名、按钮名和可观察结果。多个输入共同影响同一结果时，优先建议一次只修改一个真实输入项再重新运行，便于判断是哪项设置影响了结果。
• 使用具体场景和例子解释抽象能力，不默认读者了解 AI 表格、字段引用、授权或 API。
• 句子和段落保持简短，删除空泛宣传、重复价值描述和不影响操作的技术细节。
• 不能确认的效率、准确率、价格、支持范围和数量限制不写成确定事实。

5. 保持美观简洁

• 先设计适合当前内容的大纲，不机械套用固定模板。
• H2 承担主要阅读导航，H3 只在确实需要拆分时使用；同层级标题保持同一种写法。
• Emoji 只用于重要章节导航，每个标题最多一个，不在正文连续堆叠。
• 每段通常 2–4 句；步骤、配置和对比适合表格，背景和解释使用短段落。
• 一篇文章只使用一套主提示色；普通表格保持浅灰表头、白色正文和细灰边框，避免彩色表头、多色单元格和装饰性蓝色。
• 只有结构化比较、步骤或参数才使用表格；在支持富格式的文档中，单列内容如果只是承载一组技巧、提醒或说明，应改用同一主提示色的圆角提示框，并保持框内“加粗短标题 + 短段落”的层级，不用方角表格模拟背景卡片。
• 操作流程需要配图时，优先使用“流程｜说明｜配图”三列表，截图放在对应步骤同一行。说明列保留加粗步骤名；包含多个动作或判断时拆成 1. 2. 3. 或 · 短条目，不在单元格中堆叠长段落。
• 流程表出现“你需要确认什么”“人工检查”等列时，每行只写 2–3 个与该阶段输出对应、肉眼可以判断的核对项，不写“确认是否正确”之类的空话。
• 操作截图需要标注时，统一使用红色框、偏细红色箭头和约 72px 的清晰红字，一张图只突出当前动作；箭头尖端准确落在目标上，不用过大的箭头或文字遮挡关键界面。截图分辨率变化时等比调整字号，保持醒目但不压过界面；红色只作为截图操作标注色，不计入正文卡片和表格的主题色体系。
• 图片、视频和链接放在读者需要看到的位置。缺少素材时使用 [配图：具体内容]、[视频：具体操作] 等明确占位。
• 推荐内容、商业化信息和“沟通交流”只在用户提供真实内容或明确要求时加入，不虚构链接、价格、群卡片或活动。

6. 交付与检查

确认后直接交付完整成稿，不附带冗长的写作过程。在钉钉教程工作流中，用户提供钉钉表格或文档并要求撰写一篇教程时，确认后默认配合 dws skill 新建钉钉文档、写入成稿并回读检查，而不是只在对话中返回草稿。用户明确说“只要草稿”“先看内容”或“不要创建文档”时，才只交付可复制的 Markdown；用户要求修改已有教程时，编辑指定文档，不另建副本，除非用户要求新建。

用户限定“只修改这一块”“其他内容不要动”时，按 references/rewrite-mode.md 的局部修改边界执行：锁定目标区块，只做局部更新，不用整篇覆盖；完成后回读目标块及前后相邻区块，确认修改边界没有扩大。

交付前检查：

• 是否选择了正确的教程类型，并覆盖对应的核心信息大类
• 读者是否能理解功能、准备材料并独立完成操作
• 标题、字段名、按钮名、对象称谓、输入输出、参数、数量、支持范围和限制是否前后一致；概述、选择表、正文和小结不得互相冲突
• 是否根据当前内容调整结构，而不是机械复刻参考文章
• 是否有过长段落、重复章节、无意义表格、过量 Emoji 或多色装饰
• 是否残留其他教程的字段、限制、账号、价格、图片或链接
• 成稿是否遵守受众称呼规则，且已核实事实、教学示例和待补素材没有混用

7. 任务后的增量学习

用户已授权：每次撰写或修改任务完成后，可以把本次反馈中可跨场景复用的规则更新到本 skill，无需再次询问是否允许更新。没有候选规则通过下列门槛时保持 skill 不变，不为“每次都更新”而强行新增内容。

实际更新前必须按顺序完成：

1. 完整回读：重新完整读取当前 SKILL.md，并读取可能承载该规则的相关参考文件。
2. 提炼规则：把用户的修改要求改写成不依赖当前标题、产品、平台、字段名或文档链接的行为规则。
3. 检查重复：搜索 SKILL.md 和 references/。已有同义规则时合并、补强或改写原条目，不新建重复规则。
4. 跨场景检验：至少替换一个关键场景变量（如产品、平台、字段或文章主题），规则仍然成立才可沉淀。只适用于某一种教程类型、但能覆盖该类型多个场景的规则，可以写入对应参考文件；换场景即失效的要求只用于当前任务。
5. 选择位置：影响触发、确认、路由、交付和通用判断的规则放在 SKILL.md；只影响玩法教程、字段教程或来源重构的规则放在对应参考文件。
6. 最小更新：只修改必要段落，保留多场景适配能力。更新后回读相关段落，并用至少两个不同场景复核；任一场景不成立就撤回或进一步抽象。

可以沉淀的是稳定的写作判断、操作边界、版式原则和验收方法。不得沉淀单篇文章的标题、文案、字段值、具体参数值、具体尺寸值、链接、账号、卡片 ID、临时活动、产品事实或只在某一页面成立的颜色例外。