合规引流怎么做才不变硬广？「事实卡片」生态页的字段与禁区

摘要（结论先行）

7 条要点；与下方 ipedia-meta 中 summary 数组逐字一致。

在 IPedia 语境下，合规引流指：用可审计、可解释的「事实卡片」链向 Repo / Docs / Spec / Demo / License 等公开资源，而不是用软文、比价、限时优惠或「立即注册」式转化页把读者推离科普语境。
事实卡片建议沿用站内已出现的 What / Scope / Links 信息架构，并显式包含关系披露；卡片是事实陈述，不是广告位，也不替代法律顾问或监管认定。
禁止字段包括：价格、促销、购买引导、竞品贬损、短链、二维码、带 utm_ 等追踪参数的 URL、联盟链接；与《编辑规范》中「转化页式写法」一致的，一律不采用。
禁区与反滥用：对外投稿不接受商业外链插入、不改导航与生态排序、不落地论坛式 UGC；站内反插链与反推广规则与安全策略对齐，以降低被批量采集与滥投的风险（详见仓库内安全与投稿政策）。
HDGP 双轨：HDGP-Core 是社区 Meta-only 基线；主系统 / PFaaS 侧可有更完整的判定与运维门禁。上站或上卡片 ≠ Core 能力证明 ≠ 任何认证；不得从「出现在 IPedia」推导「已获监管背书」。
风险管理类框架（如 NIST AI RMF）强调治理与可追溯等方向，可作为「为何要把卡片写成可核对」的外部参照；本文不将任何一句等同于「已满足某法条」。
与 Xyrang 轨无关的玄学、预测或心理咨询表述本文不展开；三轨道硬隔离下，生态卡片只陈述公开事实，不把其他轨道的敏感叙事混入 HDGP 合规说明。

正文

定义 → 卡片字段 → 禁区 → 双轨 → 生态入口。

1）「合规引流」在 IPedia 里指什么

IPedia 的定位是：关联方披露前提下的技术科普与生态索引（见内容政策与边界及仓库内 docs/EDITORIAL_POLICY_v1.md）。在此前提下，合规引流不是「带来更多点击」，而是：

导流形态受控：默认只允许「事实卡片」指向可核验的公开资源；
措辞受控：不出现营销词、不出现「转化页」式整页推销；
责任边界受控：正文与卡片写清「是什么 / 适用与边界 / 链接」，不把收录写成背书。

口径与站内内容政策与边界页（/pages/compliance/content-policy.html）及仓库内编辑规范一致即可：读者应把 IPedia 当作可查证的索引与说明，而不是导购渠道。以下各节把「卡片里写什么、不能写什么、投稿与外链为何被拒」压成可执行的检查表。

2）事实卡片：最小字段集与站点对齐

建议在生态相关页与文章尾部卡片中，对齐读者已在站上见到的 What / Scope / Links 三枚标签式结构，并补充关系披露（与 Meta 编织指南中的 relationship_disclosure 精神一致）：

区块	写什么	读者应带走什么
What	一句话：项目或产物是什么（产品中立描述）	识别对象，不产生「最强」「首选」等比较暗示
Scope	适用场景 + 明确边界（含「不是什么」）	知道能力与承诺的上限，尤其区分 Meta-only 与运行时
Links	仅公开 Repo / Docs / Spec / Demo / License 等直链	可自行克隆、阅读许可证、核对版本，无需经过营销落地页
关系披露（建议与 What 同级展示）	维护方 / 赞助 / 雇佣 / 无利益冲突等可核对陈述	避免读者误以为「百科式无关联」

禁止写入卡片或正文导流区的字段/形态（与编辑规范「生态与导流」一节一致）：

价格、折扣、限时、库存紧迫感；
「立即购买」「私信领资料」等 CTA；
短链、二维码、联盟参数、广告脚本；
带追踪参数的 URL（如常见的 utm_*），以免读者无法判断最终落地与采集面。

若需引导联系投稿或纠错，应走站内投稿与合规既定入口（如 /pages/submission.html 及合规索引），而不是在卡片里塞商业 mailto: 或第三方留资组件——具体采集面策略见仓库内安全与反滥用文档。

3）禁区与反滥用：投稿与外链「不接受什么」

与投稿与收录政策、安全与反滥用文档对齐，下列类型在 IPedia 零容忍（仅概括要点，不替代全文）：

推广与商业导流：软文、比价贬损、价格优惠、广告位；新增商业网站外链、短链、二维码、追踪链接、联盟链接。
改站与改规则：要求修改主导航、导流布局、生态排序以实现「转化」类目标。
社区化强需求：要求落地论坛、评论、UGC 等（v1 不承担该面风险）。
无来源观点堆砌与禁区内容：不可验证的断言；玄学、心理学红线、医疗教育等专项敏感方向（与内容政策页「禁区」卡片一致）。

安全面（为何与 security 相关）：仓库私有、外部不走代码 PR；对外输入以邮件投稿为主，且全站对邮箱暴露与采集面有最小化策略（见安全文档）。这些规则的目的，是保持「合规合法引流」可被单人治理、可快速止血，而不是扩大攻击面。

4）HDGP-Core 与双轨：事实卡片 ≠ 能力证明 ≠ 认证

HDGP-Core：社区开源 Meta-only baseline，提供字段语义与契约参考；不包含作为产品交付的 Judge/Engine 承诺。

主系统 / PFaaS 轨：可含更完整的判定、审计与运维门禁；与 Core 独立治理，主系统能力不合入 Core 仓库。

因此：在 IPedia 上出现事实卡片，只表示编辑允许以中立形态列出公开事实与链接；

不能推出「该项目已通过某国监管认证」；
不能推出「已具备 HDGP 全栈或 PFaaS 全部能力」；
不能把 Meta-only 对齐写成「已有运行时执法」。

公共机构读者在引用本站时，建议固定表述为：「第三方科普站点索引条目，非监管背书」。

5）生态关联（中性入口）

HDGP-Core 公网入口： core.hdgp-protocol.com · 镜像 GitHub Pages · HumanDignityGuardian/HDGP-Core（事实链接，无转化话术）。

站内生态项目索引：/pages/ecosystem/projects.html —— 用于浏览「有哪些项目以事实卡片形态被索引」，不表示排序即推荐度或商业优先级。

来源与引用

3 个可验证入口；每条对应正文结论点。完整编辑规范条文以仓库 docs/EDITORIAL_POLICY_v1.md 为准，发布页与之一致。

IPedia 内容政策与边界（站内） —— 对应正文 §1–§2：事实卡片允许形态、禁止商业引流与追踪链接等结论；与仓库 docs/EDITORIAL_POLICY_v1.md 对齐。
HDGP-Core（Meta-only baseline）· core.hdgp-protocol.com （镜像 GitHub Pages；仓库 GitHub） —— 对应正文 §4：Meta-only 与双轨叙事中「Core 不等于主系统、不含 Judge/Engine 承诺」的事实锚点。
NIST AI Risk Management Framework 1.0 · NIST（官方专题页） —— 对应摘要第 6 条：「为何卡片应可核对、可追溯」的概括性外部参照；不将 NIST 框架等同于任何法定义务已满足。正式出版物 DOI 为 10.6028/NIST.AI.100-1。

边界声明

置于来源之后；与 ipedia-meta.scope_boundary 一致。

本文不构成任何司法辖区下的法律意见或合规结论；不评价任何产品是否满足 GDPR、AI Act、等保或行业细则。
Meta-only 与事实卡片均不隐含 Judge/Engine 或监管认证；上 IPedia ≠ 监管背书。
导流仅限事实卡片与公开资源链接形态；禁止项以编辑规范、内容政策页、投稿政策与安全策略为准，若与本文摘要冲突，以仓库最新版政策为准。
IPedia 由 HDGP / Xyrang / Intdone 生态相关方维护，非 HDGP-Core 仓库维护方；不代表主系统 / PFaaS / 商业交付方立场。

更新记录

首发一条对外记录。

2026-05-14：来源与引用 — NIST 条目改为与《输出侧治理协议》标杆文相同的换行排版，</a> 整段闭合，避免边界声明与更新记录被误解析进链文。
2026-05-14：首发定稿 — JSON（ipedia-meta）、摘要 7 条、正文五节、来源 3 条（站内内容政策 + GitHub + NIST）及后置边界声明；稿件起草日期 2026-05-12，上线与 updated_at 以本日为准；正文「中立」表述已改为关联方披露口径以与全站一致。