Work Sc Document Sop Builder

---
name: work-sc-document-sop-builder
description: "参考文档 SOP 提取：从参考文件中提取结构规则、内容要求、格式规范和导出模板，沉淀为可复用的文档编制 SOP。depends on docx/pdf（社区上游）。用户提到'参考文档做模板''提取文档规则''文档 SOP'时使用。"
argument-hint: "<reference file / reference markdown / document type>"
---

# Document Reference SOP Builder

将参考文档中的隐含规则整理成可复用的文档编制 SOP、格式规范和导出模板能力。

## 适用场景

- 用户给出一个 `docx`、`md`、参考底稿或历史成品，希望后续类似文档都按它来编
- 需要从参考文件中提取章节结构、内容要求、固定口径、版式规范和导出模板
- 需要把一次性的“照着参考文件做”沉淀成项目级 Skill 或 SOP

## 不负责的内容

- 不替代具体业务领域的专业写作技能
- 不自动判断法律、合规或行业规范是否正确
- 不直接完成所有文档编写任务，而是先把规则体系抽出来

## 总体目标

把参考文件中的规则拆成以下几层：

1. 内容层规则
2. 结构层规则
3. 表达层规则
4. 版式层规则
5. 导出层规则
6. 工作流层规则

最终形成：

- 可复用 SOP
- 可复用导出模板
- 可复用项目级 Skill
- 可引用的规则说明文档

## 标准流程

### SOP 1：确认参考源

先确认参考材料类型：

- `docx`
- `md`
- `pdf`
- 已有 Skill / 已有模板说明文档

若参考源是 `docx`，优先使用 `markitdown` 一类转换能力转成 `md` 再分析。

### SOP 2：拆分规则层次

阅读参考文档时，不只看“写了什么”，而要拆成以下几类规则：

1. 结构规则
   - 有哪些章节
   - 章节顺序是否固定
   - 是否存在常用子章节

2. 内容规则
   - 每一章要求写什么
   - 哪些内容必须展开
   - 哪些内容只是补充说明

3. 表达规则
   - 是公文语气、技术语气、汇报语气还是宣传语气
   - 是否存在固定称呼、固定衔接语、固定标题口径
   - 哪些表达应避免

4. 版式规则
   - 字体、字号、行距、缩进、页边距
   - 首页信息栏、表格、页眉页脚、目录等

5. 导出规则
   - 输出为 `docx`、`pdf`、`html` 还是其他格式
   - 是否区分不同 profile
   - 文件名与正文标题区的版本信息如何分离

6. 工作流规则
   - 永远先改 `md` 再导出
   - 先做结构确认还是先做版式确认
   - 内容确认后才进入导出

### SOP 3：抽取显性要求与隐性要求

区分两类信息：

- 显性要求：文档中直接写明的章节要求、格式要求、填写说明
- 隐性要求：从成品排版、措辞、结构重复中推断出的稳定规则

抽取时应明确标记：

- 哪些来自原文直接要求
- 哪些属于分析归纳

### SOP 4：沉淀为规则文档

建议至少产出以下一种或多种资产：

1. `章节编写要求.md`
2. `导出模板与格式要求.md`
3. `编制工作流.md`
4. 项目级 `SKILL.md`

### SOP 5：封装为项目级 Skill

当以下条件满足时，建议正式沉淀为项目级 Skill：

1. 该类文档未来还会重复编制
2. 结构和格式规则较稳定
3. 用户已明确要求长期复用
4. 已经完成至少一次真实项目验证

Skill 内应明确：

- 适用文档类型
- 输入材料
- 结构规则
- 内容规则
- 版式规则
- 导出规则
- 与其他专业写作 Skill 的协同关系

### SOP 6：接入知识管理

该 Skill 一旦形成，应同步：

1. 建立或更新 `Skill卡片`
2. 回填 `Skill收藏库`
3. 标注它是通用编制方法、项目级执行资产，还是可供其他文档类型参照的基础 Skill

## 使用原则

### 原则 1：先抽规则，再套用

不要直接把参考文档机械改名后复用。先提取规则，再决定是形成新模板、形成新 Skill，还是补充到旧 Skill 中。

### 原则 2：内容规则与版式规则分开沉淀

同一参考文档里，内容要求和导出样式可能分别适用于不同场景，应分开维护。

### 原则 3：先 `md`，后导出

即使目标是 `Word` 或 `PDF`，也优先把结构和规则沉淀到 `md`。

### 原则 4：优先形成 profile

若存在多种交付样式，应明确形成多个 profile，例如：

- `client-review`
- `internal-review`
- `gov-style`
- `reference-template`

## 推荐输出结构

```markdown
# 一、参考文档来源
# 二、章节结构要求
# 三、章节内容要求
# 四、语言与表达要求
# 五、版式与导出要求
# 六、工作流与使用边界
```

## 与其他 Skill / 能力的关系

- 推荐与 `markitdown` 一类文档转写能力配合，用于把 `docx` 参考文件转成 `md`
- 可与垂直领域 Skill 配合，如专利、汇报、方案书、制度文件、公文
- 可与导出类 Skill 配合，用于把提取出的版式规则进一步落到导出脚本
- 本 Skill 自身是“规则抽取与 SOP 封装层”，不替代具体业务领域 Skill 和导出脚本

## 专题引用

- `references/REFERENCE-DOCUMENT-RULE-EXTRACTION-CHECKLIST.md`：文档规则抽取时的结构化检查清单，用于补充主流程中的细化核对项。

## 典型应用

### 示例 1：专利技术交底书

- 从参考交底书中提取章节要求
- 从参考 `docx` 中提取字体、行距、首页信息栏
- 再分别沉淀为：
  - `patent-disclosure-workflow`
  - `work-sc-patent-docx-exporter`

### 示例 2：项目汇报材料

- 从历史汇报模板中提取固定章节和图表顺序
- 从成品中提取标题层级、摘要写法和页面版式
- 形成项目级汇报编制 Skill


## 推荐输出格式

执行完毕后输出极简回执：**状态**（✅ 成功 / ⚠️ 部分成功 / ❌ 失败）+ **关键结果**（1-2 行，如操作对象、产出位置、下一步）。无需强制套用大表格。
## 最终判断标准

完成后应能回答：

1. 这份参考文档要求“写什么”了吗
2. 这份参考文档要求“怎么写”了吗
3. 这份参考文档要求“怎么排版”了吗
4. 这些要求是否已经从一次性经验变成可复用 SOP

## Human Decisions

> 结构化同源见 `decisions.yaml`；以下为人类可读汇总。

| # | 决策点 | 触发条件 | 选项 | 默认行为 |
|---|--------|---------|------|---------|
| HD-1 | 文档导出确认 | SOP 文档整理完成、进入导出之前 | 用户确认后导出 / 退回修改 | 必问 |

参考文档：
- references/REFERENCE-README.md