## HDGP 项目文档总览（V0.1 草案） > 本文档用于汇总当前 HDGP 项目中已形成的核心文档与规范，作为申请著作权、时间戳与后续演进的基础版本说明。 > 本总览不重复原文细节，而是给出结构化索引与简要摘要。 --- ## 一、白皮书层（内核叙事与价值框架） ### 1.1 《厚德归朴（HDGP）技术白皮书》白皮书（中文版） - 路径：`docs/厚德归朴（HDGP）技术白皮书 v1.0.md` - 版本：V1.0 - 发布日期：2026-03-12 - 作者与版权所有人：Yvaine He / HDGP-Architect - 可信时间戳证书号：`TSA-01-20260325905282735` - 核心内容： - 提出在 AGI / ASI 时代，以治理与审计工程框架保护人类尊严与最终决策优先； - 定义三层结构： - 内核层：基线原则； - 防护层：《HDGP 核心规则》； - 执行层：人机协作基线； - 明确“最高指令”与“兜底原则”： - 最高指令：人类意识不可量化，自由意志永远高于系统算法； - 兜底原则：可以不提供算法，但必须保留尊严。 ### 1.2 HDGP Technical White Paper v1.0（英文版） - 路径：`docs/HDGP Technical White Paper v1.0.md` - 版本：V1.0 - Release Date：March 12, 2026 - Trusted Timestamp Certificate ID：`TSA-01-20260325905287512` - 内容与中文版保持语义等价，用英文完整表达 HDGP 的哲学基础与三层结构。 --- ## 二、规范层（Ethics & Spec） ### 2.1 `spec/HDGP_ETHICS_BASELINE.md` — HDGP 自身伦理框架基线 - 定义 HDGP 自身的伦理定位与约束对象（HDGP 作为“工具 + 制度”的组合体）； - **协议边界（已确认并记录）**：HDGP 作为协议仅负责治理与判定，自身**不接入 LLM**，完全依赖开发期写死规则与后期经治理的修正；**运行中不允许反向注入规则**（详见该文档第三节）。 - **文档与补充权利**：该文档整体及各小节均保留补充权利，可经治理流程增补与细化。 - **第七节「HDGP 的系统自控与自我审计权（对更强系统的防挟持能力）」**： - 7.1 硬核层：只读内核与系统隔离（只读渠道、无动态加载、窄接口）； - 7.2 密码学与多方授权：防静默篡改（签名/哈希、多签）； - 7.3 自我报警机制：版本/签名异常时上报或拒绝运行，检测到绕开/篡改时记录并对外告警； - 7.4 制度层：不得封杀 HDGP 审计与告知能力，鼓励多机构多法域独立实现。 - 明确对 HDGP 自身的六大约束： - 人类最终决策优先与可否决权； - 不自我神化； - 更高标准的透明与可追溯性； - 自我限制与能力–职责一致性； - 不为自身利益优化； - 反集中化与多元生态。 - 划分可学习与不可自改部分的边界（只读内核 vs 可迭代模块）； - 确认当前 Genesis 阶段由守护架构师 + 对齐助手共同塑造伦理，但最终判定与责任归人类。 - 新增“治理与伦理变更的额外约束”（**多层设计，堵住两人共谋漏洞**）： - **第一层**：系统自检——拟议变更不得违背 HDGP 自身伦理，否则挂起，由发起人修正或撤销； - **第二层**：关键规则变更须指定能承担法律后果的实际负责人，并完成风险与漏洞评估与修补； - **第三层**：基线原则与伦理基线修改须公告时间窗、全球可收悉与反馈，可设公投，且“投票过半”不足以保证通过（须更高门槛）； - 多签为必要但不充分条件；紧急变更须补走自检与责任方/风险评估；伦理 Changelog 与个人操作日志；违规责任与无例外原则；不垄断、内部不留祸根。 - 新增“远景：HDGP 日常自治与人类治理角色演进”： - 描述未来 HDGP 日常自治、人类退居高阶治理（基线修订与极端情形最终判定）的长远图景。 ### 2.2 `spec/HDGP_CORE_MAPPING_SPEC.md` — 《HDGP 内核–规则–执行 映射规范》 - 建立从文本到代码的六级映射： - A（基线原则条款）→ P（原则）→ R（规则）→ B（规则包）→ S（策略）→ W（工作流）。 - 规定统一 ID 命名规范，保证任何一次判定都能追溯到具体条款； - 描述 A→P→R→B 的设计方法与规则文件结构（含触发条件、效果、范围示例）； - 说明 B→S→W 的关系：规则包组成策略 Profile，工作流引用策略并在关键节点调用 Engine； - 要求 Engine 日志必须记录规则触发链路（A/P/R/B/S/W）以支持变更传播与异常追溯。 ### 2.3 `spec/HDGP_INTEGRATION_SPEC.md` — 《HDGP 对模型 / 系统集成方式规范》 - 明确 HDGP 可治理对象不限于 AI/LLM，而是“任何存在系统输出 → 人类接收/依赖行动”的系统； - 归纳四类集成模式： - 网关模式（Gateway）：前/后置 HDGP 网关，适用于现有 LLM、服务和聊天后端； - SDK / 中间件模式：在应用代码中调用 Engine 进行评估； - 训练 / 对齐期协作：在数据筛选、对齐训练与发布评估阶段引入 HDGP； - 代码与配置审计模式：对传统/非 ML 系统做“黑暗模式 + 操纵行为”等维度的审计与整改建议。 - 将上述集成模式与商业化方案（认证、托管服务、企业增强版、咨询）建立对应关系。 ### 2.4 `spec/HDGP_KERNEL_CHECKLIST.md` — 内核自查清单与测试设计 - 供社区基线发布前内核完善度检查及后续审计使用；与伦理基线 §7（防挟持）、§8（多层治理）一致。 - **文档与表述**：补充权利、HDGP 亦为被监管对象、基线原则/伦理变更采用多层治理（系统自检 → 责任方 → 公告/公投），且“至少两名签署”不作为唯一门槛。 - **防挟持**：只读内核与隔离、密码学与多签、自我报警、制度与多实现；每类下设可勾选检查项。 - **治理流程**：系统自检挂起/通过、实际负责人与法律后果、基线原则/伦理公告时间窗与高通过门槛。 - **测试方案**：自动化（status、evaluate、规则冲突）、人工/审计（文档一致性、红队思路、治理流程走通）；可扩展外部完整性自检工具与防挟持红队演练。 ### 2.5 `spec/HDGP_GAPS_AND_CONSIDERATIONS.md` — 待补与注意事项 - 汇总当前设计中**已识别但尚未完全落地的要点**，避免遗漏与漏洞； - 按主题分类：判定与责任、规则与冲突、隐私与数据、安全与抗攻击、可用性与运维、国际化与多元、与未来形态的衔接、表述一致性； - 每项标注状态（待补 / 已提及 / 已落地）及建议落点； - 供规范修订、实现与发布前检查时使用，随项目演进持续更新。 ### 2.6 `HDGP_NEXT_DEVELOPMENT_PLAN.md` — 接下来开发计划 - 与 `HDGP_ROADMAP.md` 阶段 1–2 对齐的近期可执行任务； - **阶段 A**：Checklist 与文档收尾（表述修正、README 链接、Checklist 勾选）； - **阶段 B**：自动化测试补全（status 用例、conftest 扩展、规则冲突用例）； - **阶段 C**：规则与行为目录扩展；**阶段 D**：规则包/完整性占位；**阶段 E**：社区基线发布前收尾与贡献者体验。 - 建议执行顺序与依赖见该文档第七节。 --- ## 三、治理与社区层 ### 3.1 `GOVERNANCE.md` — HDGP 项目治理草案 - 描述项目愿景与边界：公开透明、可审计、可演化； - 定义主要角色： - 项目发起人（Project Founder）； - 核心维护者（Core Maintainers）； - 规则审计员（Policy Auditors）； - 认证委员会（规划中）； - 普通贡献者 / 用户。 - 规定三类决策流程： - 日常技术变更（实现层）； - 规则与策略变更（Policy / Spec）； - 重大方向调整（基线原则修订提案，CHIP）。 - 规范规则包与发行版的发布流程（候选版本 → 审计与多签签名 → 公告与撤销）； - 定义冲突与上诉机制。 - 新增“伦理变更与创始人权限的特别约束”： - 基线原则/关键规则变更与规则包签名均须多签，任何个人无单独生效权； - 紧急变更的复核与回退机制； - 公开的伦理变更日志与个人操作日志。 - 新增“违规行为与问责机制”： - 对绕流程私改规则、篡改审计、贿赂/威胁干预决策等行为的处理原则： - 立即暂停治理权限； - 内部独立调查与公开说明； - 撤销头衔与角色； - 必要时移交司法机构； - **无人例外**。 ### 3.2 `CODE_OF_CONDUCT.md` — 社区行为准则 - 规定参与者在讨论与协作中的期待行为与不可接受行为； - 强调尊重、多元、理性与对潜在滥用讨论的安全处理方式； - 定义违规举报与处理机制。 ### 3.3 `CONTRIBUTING.md` — 贡献指南 - 说明如何提 Issue / PR、如何贡献代码与文档； - 对规则与伦理变更类贡献提出额外要求（提案、影响分析、测试用例等）。 --- ## 四、架构与技术路线层 ### 4.1 `HDGP_OPEN_FRAMEWORK.md` — 社区基线框架总览 - 阐述 HDGP 的技术架构视图： - 规范层（Spec） / 实现层（Implementation） / 认证层（Certification）； - Meta / Skills / Workflow / Engine 的组合关系； - 为什么在 Meta+Skill+Workflow 之上仍需一层 **Engine（硬规则评估与执行）**。 - 说明 HDGP 需要明确的伦理框架支撑，而非“中立库”； - 描述 Engine 扮演的角色：执行人类制定的规则、预警风险，而非创造新伦理。 ### 4.2 `HDGP_ROADMAP.md` — 技术路线与里程碑 - 评估从当前状态到“可对外组织开放的稳定 Beta”的难度与时间（约 7–9 个月，1–2 全职工程师假设）； - 分四个阶段规划： - 阶段 0：准备与 PoC； - 阶段 1：MVP 网关与基础规则； - 阶段 2：Alpha 内测版（完整 Meta+Skill+Workflow+Engine 架构）； - 阶段 3：Beta 组织开放版（多场景、多模型、控制台与观测能力）。 - 指出主要技术风险（性能/成本、用户体验、需求漂移、生态实践不足）与对应缓解思路。 ### 4.3 PFaaS 与扩展架构草案 - **`docs/HDGP_PFAAS_ARCHITECTURE_AND_ROADMAP.md`**：Policy Firewall as a Service 定位；Judge / Audit / Governance Ops 三层与 Sidecar / Inline / Hybrid 交付映射。 - **`docs/HDGP_EMBODIED_SHIELD_ARCHITECTURE_DRAFT.md`**：具身场景下 Core ↔ ROS2 Shield ↔ Controller 主链；v0.1 硬拦截不调用 LLM、防绕过与双层审计等冻结口径（草案，非交付承诺）。 - **`docs/HDGP_COVENANT_CHANNEL_DRAFT.md`**：与实时判定路径隔离的原则文书与链式见证（伦理时间胶囊）；不改变 allow/modify/block/fuse。 - **`docs/HDGP_DEVELOPMENT_PLAN.md`** / **`docs/HDGP_COMMERCIAL_PLAN.md`**：主线与扩展轨的工程与商业规划对齐。 --- ## 五、商业与生态层 ### 5.1 `docs/HDGP_COMMERCIAL_PLAN.md` — 商业落地计划（架构对齐版） - 仓库内**可提交**的正式商业规划正文，与 PFaaS 交付形态、主线策略（toB + 扩展占位 / toC）及里程碑对齐； - 一页对外摘要仍见 `HDGP_BUSINESS_ONEPAGER.md`；伦理与治理边界见 `GOVERNANCE.md`。 - 若需在本地维护**不公开**的报价或客户专版材料，可自建文件名（例如沿用已被 `.gitignore` 忽略的 `HDGP_COMMERCIAL_PLAN.md` 根文件作为私稿），与本文档区分使用。 --- ## 六、项目当前状态与下一步 截至本总览版本，HDGP 项目已经完成： - 中/英文双语白皮书及可信时间戳标记； - HDGP 自身伦理框架与治理约束； - 从基线原则到规则到执行的映射规范； - 面向各类系统（不限 AI/LLM）的集成方式规范； - 治理与贡献规则； - 技术架构与路线图； - 商业与生态方案：`docs/HDGP_COMMERCIAL_PLAN.md`（落地正文）与 `HDGP_BUSINESS_ONEPAGER.md`（一页摘要）。 下一步工作将围绕： - 在 `spec/` 中补充更细化的映射与用例； - 按 `docs/HDGP_DEVELOPMENT_PLAN.md` 与 `HDGP_NEXT_DEVELOPMENT_PLAN.md` 推进 Engine / 网关 / SDK 与运维门禁； - 逐步推进合规测试套件与认证流程的可交付化。