# 规范驱动的文档起草：为何优于单纯用 ChatGPT 提问

> Rakenne 技能如何将复杂文档起草从临时提示变为可重复、可验证的工作流——含示例与输出对比。

Author: map[bio:Founder linkedin:https://www.linkedin.com/in/ricardocabral/ name:Ricardo Cabral]
Published: 2026-02-20
Tags: workflows, skills, validation, quality, spec-driven
URL: https://rakenne.app/zh-cn/learn/best-practices/spec-driven-document-drafting/index.md


用通用聊天界面起草复杂、受监管的文档——政策、控制叙述、CAPA 报告、授权包——很诱人：贴一段提示就能得到草稿。问题在于**一致性、结构和合规性**。一次性提示无法强制工作流、无法执行检查，也无法让模型自我纠正。Rakenne 中的**规范驱动文档起草**扭转了这一点：技能定义工作流、加载参考资料，并使用扩展工具让智能体进行验证、修正并保持质量。本文说明为何这种做法明显优于「在 ChatGPT 上普通提问」，并给出具体示例与输出对比。

## 为何规范驱动优于临时提示

| 方面 | 单纯 ChatGPT（或类似） | 使用技能的 Rakenne |
|------|------------------------|---------------------|
| **工作流** | 您在提示中描述步骤；模型可能跳过或打乱顺序。 | 技能定义固定工作流（范围 → 加载参考 → 起草 → 验证）；智能体按此执行。 |
| **参考资料** | 您粘贴或附上文档；上下文变杂，关键条款易丢失。 | 参考资料在技能中；智能体按需加载并保持上下文聚焦。 |
| **结构** | 输出格式由模型推断；章节与编号易偏离。 | 技能规定章节、准则和文档结构；模板与示例保持输出一致。 |
| **检查** | 无法内置验证覆盖率、完整性或逻辑。 | 扩展工具执行确定性检查（如 TSC 覆盖、5 Whys 门、有效性日期）；智能体修正并重跑直至通过。 |
| **自我纠正** | 模型可能声称「已包含 X」却未真正包含。 | 验证工具返回通过/失败及具体发现；智能体必须先处理再继续。 |
| **可重复性** | 每次会话取决于您如何写提示。 | 同一技能每次产生相同工作流与检查；仅内容变化。 |

简言之：**规范驱动起草**为 LLM 提供**规范**（工作流 + 参考资料 + 结构）和**工具**（扩展）以自查自纠。单纯提示则没有。

## Rakenne 技能如何实现规范驱动起草

在 Rakenne 中，每个**技能**是 pi 智能体可触发的一个小包，通常包含：

1. **SKILL.md** — 名称、描述（何时使用）以及**工作流**：有序步骤（如定义范围 → 加载参考 → 起草 → 验证）。
2. **参考资料** — Markdown 文件（标准、准则列表、模式），智能体在技能激活时加载，使草稿与权威要求对齐。
3. **扩展工具**（可选） — 在智能体处注册的 TypeScript 工具（`extension.ts`），对文档执行**确定性检查**（覆盖率、逻辑门、完整性）。智能体调用它们、读取结果并修订直至检查通过。

项目级上下文（文档类型、领域、术语表）位于工作区根目录的 **AGENTS.md**，因此该项目的每次对话都在同一范围内。

下面用真实的 Rakenne 技能说明工作流、检查与自我纠正，并对比输出。

---

## 示例 1：HIQA 用药政策（工作流 + 参考资料）

**技能：** [HIQA Designated Centre Medication](/skills/hiqa-designated-centre-medication/)。为爱尔兰指定中心起草符合 HIQA 标准的用药政策。

**技能中的工作流：**

1. **定义范围** — 中心类型、自我用药与机构给药、现有程序。
2. **加载参考** — 阅读 `references/hiqa-nssbh.md` 中 NSSBH 主题 3（安全照护、用药安全）。
3. **起草** — 产出涵盖以下内容的政策：订购与供应、储存与安全、处方与核对、给药（谁、如何、何时）、自我给药（如适用）、记录与 MAR 表、差错与事件、处置、人员培训与能力、居民用药审查。
4. **交叉引用** — 与事件上报及照护/支持计划对齐。

参考文件写明 HIQA 八大主题与治理要求，智能体无需猜测。

**Rakenne（使用技能）：** 智能体按工作流执行，从参考中引入 NSSBH 主题 3 及相关治理内容，产出带明确章节（订购、储存、给药、差错、培训等）的政策，并显式对齐「NSSBH Theme 3」与「designated centre」语境。

**单纯 ChatGPT：** 您可能提示：「为爱尔兰一家护理院写一份用药政策。」模型常返回一份可套用任何地方的通用「用药政策」：模糊的「定期审查」「适当人员」，与 HIQA 或 NSSBH 无关联。无法保证主题 3（或储存、MAR、差错、处置）被系统覆盖，也没有内置的「先加载参考再起草」步骤。

---

## 示例 2：SOC 2 控制叙述（工作流 + 验证工具）

**技能：** [SOC 2 Control Narrative Author](/skills/soc2-control-narrative-author/)。构建含控制叙述、TSC 映射与证据占位符的 SOC 2 文档。

**工作流：**

1. **范围** — 哪些 TSC 类别（Security 必选；可选 Availability、PI、Confidentiality、Privacy）。
2. **控制叙述** — 对范围内每个准则（CC1–CC9、A1、PI1、C1、P1–P8）：叙述 + 证据引用。
3. **证据** — 为每条叙述添加证据占位符。
4. **验证** — 运行扩展工具并修正直至通过。

**扩展工具：**

- **check_trust_services_criteria_coverage** — 确保范围内每个 TSC 准则都有叙述与证据引用；标记未映射准则。
- **soc2_narrative_reliability_check** — 应用 SOC 2 可靠性评分：标记模糊表述（「定期审查」「管理层维护安全」），要求具体化（谁、如何、何时、何地、具名技术）。

**Rakenne（使用技能）：** 智能体起草叙述后运行两个工具。若 CC4 缺少证据引用或叙述写「访问定期审查」，工具返回失败及具体发现。智能体修订（补充证据、写明「每季度由安全团队通过 IdP 访问报告执行」）并重跑直至通过。

**单纯 ChatGPT：** 您要求「Security 的 SOC 2 控制叙述」。常得到提及「控制」「政策」的文本，但未系统覆盖 CC1–CC9、未将每个准则映射到叙述+证据，且使用评分明确反对的模糊用语（「定期审查」「适当控制」）。没有自动检查，缺口与模糊只在审计准备时暴露。

---

## 示例 3：CAPA 报告（工作流 + 逻辑门）

**技能：** [CAPA Report](/skills/capa-report/)。针对不符合项的纠正与预防措施报告（ISO 9001 / ISO 13485）。

**工作流：**

1. **不符合项** — 发现、范围、遏制。
2. **根本原因** — 完成**5 Whys** 小节（Why 1 … Why 5）。在完成前**不要**提出措施。
3. **门控** — 对文档运行 **root_cause_logic_gate**。仅当其通过后再继续。
4. **纠正/预防措施** — 措施、负责人、截止日期。
5. **实施** — 记录完成情况。
6. **有效性验证** — 设定**未来**验证日期。关闭前运行 **verification_of_effectiveness_timer**；在其通过前不得关闭。

**扩展工具：**

- **root_cause_logic_gate** — 检查是否存在根本原因/5 Whys 小节且至少五个不同 why 层级。若文档在完成合格 5 Whys 前跳到「解决方案」则失败。
- **verification_of_effectiveness_timer** — 确保存在有效性验证日期且为**未来**日期，避免在验证尚未安排前关闭 CAPA。

**Rakenne（使用技能）：** 智能体起草不符合项与根本原因。若只有三个 why 层级或直接写「我们将培训员工」，门控返回失败：「检测到 Why 层级：3/5。在提出措施前完成 5 Whys 分析。」智能体补全 Why 4 和 Why 5、重新运行门控后再继续措施。关闭前必须设定未来有效性日期；若填「2025-01-15」而当前已过该日，计时器失败，智能体须设定未来日期。

**单纯 ChatGPT：** 您要求「关于文件控制的审计发现的 CAPA」。常得到一段原因加一列措施一次性输出——无强制 5 Whys、无门控、无检查有效性验证是否安排在将来。输出看起来合理但经不起严格 ISO 9001/13485 审查。

---

## 示例 4：FedRAMP 授权包（工作流 + 完整性检查）

**技能：** [FedRAMP Authorization Package](/skills/fedramp-authorization-package/)。SSP、附件、SAP、SAR、POA&M。

**工作流（简化）：** 系统分类 → 系统描述 → 授权边界 → 数据流 → 控制实施（含基线参考）→ SSP 附件 → 用 **fedramp_package_completeness_check** **验证**。修正并重跑直至通过。SAP/SAR 与 POA&M 有独立子工作流；同一工具用于标记缺失控制、缺失附件章节或缺少补救计划/逾期无说明的 POA&M 项。

**Rakenne（使用技能）：** 智能体按工作流执行，加载基线与附件参考、起草各节并运行完整性检查。缺口（如未实施控制无理由、缺 PIA 节）被报告；智能体补全并重新验证。

**单纯 ChatGPT：** 您要求「某 SaaS 产品的 FedRAMP SSP」。常得到长叙述，形似 SSP 但不符合真实 FedRAMP 结构、逐条控制实施或附件清单。无法验证基线覆盖或附件完整性；缺口只能事后人工发现。

---

## 小结：同一模型，不同结果

底层 LLM 可以相同。差异在于**使用方式**：

- **单纯提示：** 单次或来回对话，无固定工作流、无技能加载的权威参考、无验证工具。输出泛化、结构漂移，模型无法可靠地「自查自纠」。
- **Rakenne 规范驱动：** 技能定义**工作流**、**参考资料**和**扩展工具**。智能体按工作流执行、加载正确参考、起草后运行返回通过/失败与具体发现的工具，**修正**直至检查通过并**维持**所需结构与质量。

对复杂、受监管的文档——政策、控制叙述、CAPA、授权包——规范驱动起草配合工作流与验证工具，不是小升级，而是「也许够用」与「可审计、可重复」之间的差别。

试用方式：在 [Rakenne 技能](/skills/) 中为您的领域选一个技能，用该工作流创建项目，将结构化、经验证的输出与单次 ChatGPT 提示的结果对比即可。


---

Back to [最佳实践](https://rakenne.app/zh-cn/learn/best-practices/index.md)