技术文档写作助手

基于已有的产品/项目资料（docx、pdf、md），按照给定的大纲或模板生成结构化的中文技术文档（Markdown 格式）。

典型使用场景

写作方向：

• 基于产品的开发设计文档，生成招投标技术方案
• 基于多份零散的需求/设计材料，按模板整合为一份完整的设计文档
• 基于代码/接口说明，按规范生成接口文档
• 基于架构资料，按大纲生成系统架构文档

评审方向：

• 对刚写完的文档做一次整体评分，产出评审报告
• 对已有文档（不论是本 skill 写的还是别人写的）进行独立评分
• 写作过程中逐节做内联自检（可选）

两种工作模式

本 skill 有两种调用模式，开始前先判断用户属于哪一种：

• 模式 A：写作模式（默认）— 用户希望基于素材和大纲/模板生成一份新文档。走【写作工作流】。
• 模式 B：评审模式 — 用户直接给一份已写好的文档要求评分/评审（"帮我评下这份方案"、"按这个标准打个分"）。跳过写作流程，直接走【评审工作流】。

两种模式可以串联：写作完成后用户说"顺便评一下"，则进入评审工作流。

【写作工作流】

第 1 步：澄清任务

开始前确认以下信息（从用户消息中能推断的直接推断，推断不出来再问；一次最好一起问完，别分多轮打扰用户）：

1. 参考文档目录 — 哪个路径下的文档作为素材（可能在 /mnt/user-data/uploads/ 或用户指定的其它路径）
2. 大纲/模板 — 文件路径，或直接在对话里给的文字大纲
3. 输出位置 — 默认写到 /mnt/user-data/outputs/，文件名建议"文档类型_简要主题.md"
4. 文档类型 — 招投标技术方案 / 产品设计 / 接口 / 架构 / 其他。优先从大纲或模板的标题和行文风格推断，若推断不明再问用户

第 2 步：盘点素材

1. 列出参考目录所有文件（递归 find 或 ls），把清单给用户看，确认范围
2. 根据文件名和大纲推断每个文件的可能用途，生成一份"素材地图"
3. 先读 md 和纯文本，再按需读 docx / xlsx / pdf / pptx（后者更耗时、更占上下文）
4. 在工作目录（如 /home/claude/）用临时 md 文件记录"哪个文档哪节讲了什么主题"，作为后续写作时的索引

读取方式的核心原则（重要）：先检查 available_skills，如果环境里已安装 docx / xlsx / pptx / pdf-reading 等专门 skill，一律优先调用它们（view 对应 SKILL.md 并按其指引执行），不要重复造轮子。只有在没有对应 skill 时，才使用 references/file-reading.md 里给出的 Python 应急脚本（python-docx / pandas / pdfplumber / python-pptx）。详见 references/file-reading.md。

第 3 步：解析大纲/模板

情况 A：模板是 docx/md 文件

• 提取完整标题层级（H1/H2/H3…）
• 提取每节的占位文字、提示语、括号说明（这些往往暗示每节该写什么）
• 若模板中有示例段落，留意其语气/粒度/是否使用表格或图
• docx 模板要注意："红色字"、"【此处填写】"、"XXX 公司"这类占位符

情况 B：用户给的是纯文字大纲

• 把大纲整理为清晰的层级结构
• 对每个叶子节点，推断应该写什么内容、什么粒度

无论哪种情况，在开始写之前，把解析出的完整章节结构简要列给用户过一遍，防止对结构理解偏差。

第 4 步：按节编写

对每一节，按顺序执行：

1. 从素材地图定位相关原始资料（此时可以回头再细读 docx/pdf 的具体章节）
2. 识别该节应包含的元素：纯文字说明 / 架构图 / 流程图 / 时序图 / ER 图 / 部署拓扑 / 接口表 / 配置表 / 对比表
3. 基于参考材料写正文 — 不同文档类型的语气风格见 references/writing-style.md
4. 合理插入 Mermaid 图和表格 — 模板见 references/mermaid-patterns.md
5. （可选）内联自检：用户明确要求"边写边查"、"每节加自检"、"写完能自己复查"时开启，给出问题的地方用 HTML 注释标在正文里，Markdown 渲染时不可见。格式：。详见 references/scoring-criteria.md 的"内联自检格式"章节。默认不开启以保持正文干净。

长文档处理：如果整份文档预计超过 1 万字，分批输出，按一级章节（或每 2-3 个一级章节）为一批。每批完成后停下来，告诉用户进度，让用户审阅后再继续下一批。不要闷头写几万字。

第 5 步：处理内容缺失

大纲某节在参考文档里找不到对应内容时，按文档类型选择策略：

• 招投标 / 应标类文档：可以基于通用技术知识合理补充（这类文档允许一定的方案设计），但在对应段落末尾用 HTML 注释标注 ，方便用户审阅
• 产品设计 / 接口文档：不得编造具体的接口、表结构、字段、参数、性能数据、版本号。应在该节用醒目的 blockquote 标注 > ⚠️ 待补充：xxx（参考文档中未找到相关材料）
• 架构文档：中间策略 — 架构思路可以合理推断但要标注，具体技术选型和数字必须来自原材料

第 6 步：输出和交付

1. 保存为 .md 文件到 /mnt/user-data/outputs/
2. 在对话中给出生成总结报告（不是写进文档里），包含：
• 已完成章节清单
• 使用的参考文档清单（哪些用到了、哪些没用上）
• ⚠️ 待用户核对的章节清单（缺失 / 基于通用知识推断 / 术语存疑）
• 使用的图表清单（几张 Mermaid、几个表）
• 字数统计
3. 使用 present_files 工具交付文件
4. 主动询问是否评分：交付后问用户一句"要不要顺便跑一次评审？如果有评分标准可以一起给我。" 如果用户同意，进入【评审工作流】。

第 7 步（可选）：串联评审

用户要求评分时，沿用刚生成的文档直接进入【评审工作流】。写作阶段已经识别过文档类型，可以直接复用，不用再问。

【评审工作流】

当用户希望对一份已有文档进行评分/评审时走此流程。可以是独立调用（用户一上来就要评分），也可以接在写作工作流之后。

评审-1：确认任务

澄清以下信息（能推断就推断，一次问完，别多轮打扰）：

1. 被评文档路径（md / docx / pdf 都支持，读取方式同写作工作流）
2. 评分标准：用户有没有提供？
• 有（招标文件评分细则、公司规则、自定义评分表）→ 完全按用户的
• 没有 → 根据文档类型使用内置默认标准（见 references/scoring-criteria.md）
3. 文档类型（招投标 / 设计 / 接口 / 架构）—— 优先从文档内容和标题推断，不明确再问
4. 输出位置：默认和原文档同目录，命名 <原文件名>.review.md

评审-2：读取文档和标准

1. 用 view 或对应 skill 读取被评文档全文（长文档分段读）
2. 读 references/scoring-criteria.md 了解评分流程和报告模板
3. 如果是默认标准，按文档类型查对应评分表；如果是用户提供，完整录入

评审-3：逐维度评分

按评分标准每个维度执行：

1. 扫描文档相关部分
2. 给出本维度得分（0 到满分）和失分依据
3. 把具体问题记录下来（供详细审阅章节使用），标注优先级：
• 🔴 高优先级：违反底线（编造、严重偏题、缺关键章节）
• 🟡 中优先级：重要但不致命（术语不一致、图文不匹配、空泛口号）
• 🟢 低优先级：细节问题（格式、错别字、排版）

评审-4：扫通用扣分项

全文扫一遍，叠加通用扣分项（编造、术语不一致、图文不匹配、空泛口号等）。详见 references/scoring-criteria.md。

评审-5：生成报告

严格按 references/scoring-criteria.md 里的报告模板产出 <原文件名>.review.md：

• 第一部分：总览评分表（维度 / 权重 / 得分 / 失分简述）+ 总分 + 问题数量分布 + 2-4 句总体结论
• 第二部分：详细审阅，按章节或按维度列出每个问题（定位 / 原文摘录 / 问题 / 建议）
• 第三部分：改进优先级建议（如果时间有限先改哪几项）
• 附录：评分方法说明（用户给的还是默认的、为何这么扣分）

关键原则：只评分不动手。给出具体的修改建议，但不直接修改原文档，把决定权交给用户。

评审-6：交付

1. 用 present_files 交付 .review.md 文件
2. 在对话中给 3-5 行摘要：总分、最突出的优缺点、建议最先改的 3 件事

输出格式规范

• 纯 Markdown（不要用 HTML 花哨排版，保证粘贴到各种平台都兼容）
• 标题层级严格对齐大纲/模板（用户模板是三级标题就不要擅自加四级）
• Mermaid 图用 ``` `mermaid ``` 代码块包裹
• 表格用标准 Markdown 表格语法，不用 HTML
  代码/命令/字段名用反引号
  中文正文里，中英文和数字之间加空格（如"支持 10000 TPS"而不是"支持10000TPS"），提升可读性
  标点使用中文全角标点（，。：；），除非在代码块内

  关键原则（重要）

  1. 不编造：具体的接口参数、表结构、版本号、性能数据、客户案例，必须来自参考文档；找不到就标注，绝不瞎编。这是底线。
  2. 贴近源材料的粒度：参考文档详细的地方，输出也要详细；原文一笔带过的地方，不要过度展开瞎吹。
  3. 术语一致：参考文档用"审计引擎"就不要换成"审计组件"或"审计模块"。第一次使用专有名词/缩写时保留英文原文并括号说明。
  4. 按文档类型调整语气：招投标可以有适度商务化表达和卖点；设计/接口文档必须客观严谨；不要混用。
  5. 保留审阅点：每完成一个大章节就停下来汇报进度，让用户确认方向对了再继续。

  参考文件

  读取建议（Claude 按需加载，不要一次性全读）：

  • references/writing-style.md — 写作前读；不同文档类型的语气、结构、惯例
  • references/mermaid-patterns.md — 画图/做表前读；技术文档常用的图表模板
  • references/file-reading.md — 读素材前读；docx / xlsx / pdf / pptx / md 的读取方法（优先调用已安装的专门 skill）
  • references/scoring-criteria.md — 评审前读；评分标准（默认和用户提供两种）、评分流程、报告模板、内联自检格式

  版本历史

  共 1 个版本

  • v1.0.0 Initial release 当前
    2026-05-01 16:31 安全 安全

  安全检测

  腾讯云安全 (Keen)

  安全，无风险

  查看报告

  腾讯云安全 (Sanbu)

  安全，无风险

  查看报告

  🔗 相关推荐

  content-creation

  Marketing Skills

  jchopard69

  {"answer":"获取23个营销模块，包含CRO、SEO、文案、分析、发布、广告及社媒的清单、框架与现成交付物。"}

  ★ 143 📥 30,944

  content-creation

  Humanizer

  biostartechnology

  消除AI写作痕迹，使文本更自然真实。基于维基百科"AI写作特征"指南，识别并修正夸张象征、宣传用语、肤浅-ing分析、模糊归因、破折号滥用、三项排比、AI词汇、负面平行结构及冗长连接词等模式。

  ★ 909 📥 207,642

  content-creation

  humanizer-zh

  liuxy951129-cpu

  去除文本中的 AI 生成痕迹。适用于编辑或审阅文本，使其听起来更自然、更像人类书写。 基于维基百科的"AI 写作特征"综合指南。检测并修复以下模式：夸大的象征意义、 宣传性语言、以 -ing 结尾的肤浅分析、模糊的归因、破折号过度使用、三段

  ★ 62 📥 29,618

  Skill工具集 © 2026