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

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

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

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

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

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

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

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

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

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

技能： 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 。构建含控制叙述、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 。针对不符合项的纠正与预防措施报告（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 。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 技能 中为您的领域选一个技能，用该工作流创建项目，将结构化、经验证的输出与单次 ChatGPT 提示的结果对比即可。