Meta 文档怎么写才经得起核对：意图、适用范围、字段与版本说明（protocols 导读）

• 协议与 Meta 文档层的任务，是把「意图、适用范围、关键字段与版本变更」写成可公开核对、可随实现演进维护的声明，而不是把运行时能力写进同一段对外口径里混讲。
• 最小公开包建议固定 What、Scope、Links 三类信息并补充关系披露：What 用一句话写对象与边界，Scope 写适用与不适用，Links 只指向 Repo、Docs、Spec、License 等可核验入口。
• 版本号应对外读者具备可读语义：在同一文档承诺下的字段含义或约束发生变化时，应提升版本号并在「变更说明」中写明动因与迁移提示，禁止长期静默改写正文却不留记录。
• 「声明冻结」反模式指：版本与变更说明停滞，而实现与配置持续变更，导致公开声明与真实行为漂移；检查表要求把字段级或语义级变更写进变更说明，或显式标注「待与实现对齐」。
• 与 HDGP-Core 的 Meta-only 对齐，指采用其字段语义（如 `scope_boundary`、`risk_tags`、`relationship_disclosure`）承载边界语言；对齐不构成法律意见，也不表示已部署 Judge 或 Engine。
• 常见反模式包括：把计划能力写进 Scope 当作既成事实、在 Meta 段暗示审计或拦截已默认开启、用变更说明推销功能而非记录契约变化。
• 文末检查表供维护者在发版前核对：版本号、变更说明、Meta 与运行时分段、外链是否符合事实卡片形态及编辑规范中的禁止项。

1. 定义与读者任务

协议 / Meta 文档层在工程上解决的是：读者（含公共机构读者）能否在不读代码仓库全文的前提下，用一份短文档回答四件事——我们声称提供什么、不声称什么、证据链接在哪、上一版与这一版差在哪。这与 governance 栏目里讨论的「分层职责」「合规引流形态」是不同焦距：本篇只谈文档与字段如何写，不把「是否已上生产门禁」当作本篇结论。

若你更关心「Meta-only 与 Policy、Judge、Engine 怎么分」「合规事实卡片长什么样」，请直接阅读 governance 轨既有文章（见 §6）；本篇仅在一处用一句话串起定位：文档层先把边界语言写对，运行时与导流形态才有可对齐的锚点。

2. 最小字段集：与站内 What / Scope / Links 对齐

站内生态与文章尾部常见 What / Scope / Links 卡片形态；在 protocols 语境下，可把它理解为最小公开包的目录，而不是营销三折页。

字段若采用键值或 schema（例如 JSON Meta），键名与含义应在文档正文中有一份「字段表」：每个字段类型、必填与否、默认值、弃用计划。新增字段时，优先在字段表与变更说明中同时出现，避免只改示例 JSON 不改说明。

3. 版本号与「变更说明」：和「声明冻结」对照

何时必须 bump 版本号（建议规则，可写入团队 checklist）：

• 任意对外承诺的语义改变：例如 scope_boundary 从「不做 X」改为「在条件下可做 X」。
• 必填字段增删、或某字段从可选变为必填。
• 默认行为在读者理解上等价于契约变化（即使实现认为只是「小重构」）。

哪些变更建议写入「变更说明」而不必 bump 主版本（团队可约定 semver 或日历版本，但须自洽）：

• 错别字、链接修正、示例代码与当前实现一致化（不改变语义）。
• 纯排版与可读性改进，且经双人核对零语义差分。

若团队采用 SemVer：破坏性语义变更 → 主版本；向后兼容扩展 → 次版本；修正性文档 → 补丁版本——关键是读者能否凭版本号判断「要不要重读 Scope」。

「声明冻结」反模式：对外文件名或版本号长期不变，仓库里 Meta 与实现却月月改；外部审计或集成方拿着旧 PDF 与线上行为对照会得出「声明不可信」。对策是：要么 bump 并写变更说明，要么在文档顶部用醒目标注「本页与 release X 对齐，若 HEAD 超前以仓库 tag 为准」，二者择一，避免三不管地带。

4. 与 HDGP-Core Meta-only 的对齐方式（概括）

HDGP-Core 提供的是 Meta-only baseline 的字段语义参考：例如用 scope_boundary 承载「不做什么」、用 risk_tags 标注风险域、用 relationship_disclosure 做利益关系陈述。对齐的含义是：你的公开 Meta 文档与对外 JSON 使用同一套可讨论、可 diff 的语言——便于跨项目对齐与机器解析，不表示你已开源全部实现、不表示已通过某法规审查。法条与标准映射属于法务与合规模块，不在 protocols 文档层展开；若需「合规引流与事实卡片」写法，见 governance 交叉引用。

5. 反模式与可执行检查表

反模式（节选）

• 混写：在同一段「用户可见说明」里交替写「字段定义」与「我们已默认开启审计流水线」——读者无法判断后者是承诺还是路线图。
• 幽灵字段：线上 Meta 已出现新键，文档字段表未更新。
• changelog 当营销栏：变更说明里写「体验大幅提升」却无字段或行为对照表。

发版前检查表（可打印）

• 版本号是否已提升（对照 §3 规则）？
• 「变更说明」是否列出至少一条可核对的契约变化或明确写「无契约变化，仅勘误」？
• What / Scope / Links 是否与当前 tag 一致？Links 是否无禁止形态？
• Meta 段是否未暗示 Judge、Engine、认证或监管背书？
• 若存在「计划能力」，是否已迁出 Scope 至路线图或内部 wiki，避免与「当前契约」混排？
• relationship_disclosure 是否与组织事实一致？
• 是否与 HDGP-Core 字段命名冲突（若有 fork，是否在文档中声明差异）？

6. 延伸阅读（protocols 姊妹篇 + governance）

• 「最小 ipedia-meta」：匿名示例与键对照 —— Riverbend 形状演示、键名表、机检/摘要/验稿边界。
• 读者看到的「版本」，和仓库里的 tag 对齐了吗？ —— 文档、发布面与 Git tag 的最小约定。
• 什么是「输出侧治理协议」：从可拦截到可审计的工程路径
• Meta-only、Policy、Judge、Engine：四层怎么分
• 合规引流与事实卡片：字段与禁区

以上 governance 三文承担「双轨叙事」「分层对比」「合规导流」主体篇幅；protocols 姊妹篇含 匿名 meta 形状、 tag 与发布面 与本篇导读。

1. HDGP-Core（Meta-only baseline）· core.hdgp-protocol.com —— 公网首选；字段语义以 Core 公开定位为事实依据。镜像 GitHub Pages； 仓库 HumanDignityGuardian/HDGP-Core。
2. NIST AI Risk Management Framework 1.0 · NIST（官方专题页） —— 概括参照治理、测量与可追溯等方向；不将文中任何一句等同于 NIST 或某法条的合规认定。正式出版物 DOI 为 10.6028/NIST.AI.100-1。

• 本文不提供法律意见或监管合规结论；不评价任何具体产品或服务是否满足某部法规或标准；不暗示在 IPedia 或 HDGP-Core 上发布即获得监管背书或认证。
• 不承诺 Meta-only 文档或字段对齐即等同于已部署 Judge、Engine 或等价运行时能力。
• 不代表 HDGP 主系统、PFaaS 或商业交付方立场。

• 2026-05-15：读者体验 — 移除正文渲染区「关于 slug」内部命名说明（slug 仍体现在 URL / canonical；不占用读者正文）。
• 2026-05-14：延伸阅读 — 增补指向姊妹篇 doc-release-tag-and-published-surface.html（protocols 第二篇上线后互链）。
• 2026-05-14：主系统侧验稿 — Accept；机读 ipedia-meta 与摘要 7 条一致；主系统采纳「维持约 2100～2300 字档」篇幅结论，正文未因字数硬压或硬扩。
• 2026-05-14：首发定稿 — JSON（ipedia-meta）、摘要 7 条、正文六节、来源 2 条（GitHub + NIST）及后置边界声明；栏目 protocols；与 governance 三连发差异化子问题。