📜 制定DPML协议RFC规范

[deepracticexs]

目标

制定DPML Protocol的RFC规范文档，建立标准化的协议定义。

背景

DPML (Deepractice Prompt Markup Language) 是用于定义AI应用的声明式标记语言协议。目前已有基础实现（Agent runtime），但缺少正式的协议规范文档。

设计原则

RFC vs W3C 双层设计

根据之前讨论确定的设计策略：

• RFC层（协议核心）：面向实现者

  • 语法定义（BNF/ABNF）
  • 数据结构规范
  • 解析规则
  • 可被计算机验证和解析

• W3C层（使用指南）：面向使用者

  • 实用示例
  • 最佳实践
  • 领域扩展（Agent/Task/Role/Workflow）
  • 可被AI和人类理解

核心理念

• 声明式优先：像写HTML一样定义AI行为
• 可扩展性：插件系统和领域扩展机制
• 标准化：确保一致性和互操作性
• 低门槛：5分钟上手，无需深入了解AI模型内部

协议范围

1. 核心协议（当前focus）

• XML/HTML-like 标记语法
• 基础元素定义（agent, llm, prompt等）
• 属性系统（api-key, model等）
• 引用机制（@env:, @file:等）
• 验证规则

2. 领域扩展（未来）

• Agent Domain - 对话式AI助手（已实现）
• Task Domain - 状态机任务定义（规划中）
• Role Domain - AI角色人格定义（规划中）
• Workflow Domain - 工作流编排（规划中）

待讨论问题

1. 协议命名

   • 正式名称确认：DPML Protocol
   • 版本策略：如何管理协议版本

2. RFC文档结构

   • 采用标准RFC格式还是简化版本
   • 章节组织方式
   • 示例的详细程度

3. 语法规范

   • 使用ABNF还是其他形式描述语法
   • 标签命名规范
   • 属性值类型系统

4. 扩展机制

   • 如何定义自定义标签
   • 插件系统规范
   • 命名空间策略

5. 与现有实现对齐

   • 当前packages/dpml的实现与协议的关系
   • 如何保证实现遵循规范

产出物

• DPML Protocol RFC 文档（英文）
• 协议概述页面（中英文，网站用）
• 核心规范页面（中英文，网站用）
• BNF/ABNF 语法定义
• 验证规则文档

参考

• RFC 2616 (HTTP/1.1)
• RFC 7946 (GeoJSON)
• HTML5 Specification
• 现有的 /Users/sean/Deepractice/projects/PromptX/packages/resource/resources/protocol/dpml.protocol.md

里程碑

1. Phase 1: 协议框架和核心语法定义
2. Phase 2: Agent Domain详细规范
3. Phase 3: 扩展机制和插件系统规范
4. Phase 4: 其他领域规范（Task/Role/Workflow）

---

协作方式：使用本issue作为RFC讨论和迭代的工作空间

[deepracticexs]

RFC 7322 标准章节结构

根据 RFC 7322 (RFC Style Guide) 官方标准，标准RFC文档包含以下章节：

必需章节 (Required Sections)

1. First-Page Header（首页头部）

• 作者姓名
• 所属组织
• ISSN编号
• Updates/Obsoletes信息

2. Title（标题）

• 居中显示
• 准确反映文档范围和目的

3. Abstract（摘要）

• 简明扼要概述文档目的和内容
• 通常以"This document..."开头
• 不允许引用

4. Status of This Memo（文档状态）

• 定义文档在标准轨道中的地位

5. Copyright Notice（版权声明）

6. Table of Contents（目录）

• 所有RFC必须包含
• 位于版权声明之后，引言之前

7. Body of the Memo（正文主体）

核心章节包括：

• Introduction（引言）- 必须是TOC后的第一个章节

  • 说明RFC的动机
  • 描述文档的适用性

• Requirements Language（需求语言）

  • 定义关键词（MUST, SHOULD, MAY等）

• [Technical Content]（技术内容章节）

  • 具体的技术规范章节，根据协议需要组织

• IANA Considerations（IANA考虑）

  • 注册、分配或保留号码/名称

• Internationalization Considerations（国际化考虑）- 如适用

• Security Considerations（安全考虑）- 必需

  • 讨论安全影响

• References（参考文献）- 必需

  • Normative References（规范性引用）
  • Informative References（信息性引用）

8. Optional Sections（可选章节）

• Appendices（附录）
• Acknowledgements（致谢）
• Contributors（贡献者）
• Author'''s Address(es)（作者地址）

---

建议的 DPML Protocol RFC 结构

基于标准RFC格式，为DPML Protocol定制的章节结构：

1. Abstract

2. Status of This Memo

3. Table of Contents

4. Introduction
   4.1 Motivation
   4.2 Terminology
   4.3 Requirements Language

5. DPML Protocol Overview
   5.1 Design Principles
   5.2 Use Cases
   5.3 Protocol Scope

6. Syntax Specification
   6.1 Basic Structure
   6.2 Elements
   6.3 Attributes
   6.4 ABNF Grammar

7. Core Elements
   7.1 <agent> Element
   7.2 <llm> Element
   7.3 <prompt> Element
   7.4 Additional Core Elements

8. Reference Mechanisms
   8.1 Environment Variables (@env:)
   8.2 File References (@file:)
   8.3 Other Reference Types

9. Extension Mechanisms
   9.1 Custom Elements
   9.2 Plugin System
   9.3 Namespace Management

10. Domain Extensions
    10.1 Agent Domain (Normative)
    10.2 Task Domain (Informative)
    10.3 Role Domain (Informative)
    10.4 Workflow Domain (Informative)

11. Validation Rules
    11.1 Schema Definition
    11.2 Parsing Requirements
    11.3 Error Handling

12. Security Considerations
    12.1 API Key Management
    12.2 File Path Security
    12.3 Injection Prevention

13. IANA Considerations
    13.1 Media Type Registration
    13.2 File Extension Registration

14. Internationalization Considerations

15. References
    15.1 Normative References
    15.2 Informative References

Appendix A. Complete Examples
   A.1 Simple Agent
   A.2 Complex Agent with Tools
   A.3 Multi-Domain Example

Appendix B. ABNF Grammar (Complete)

Appendix C. Implementation Notes
   C.1 Parser Implementation
   C.2 Runtime Requirements

Appendix D. Comparison with Other Formats
   D.1 vs. JSON Configuration
   D.2 vs. YAML Configuration

---

参考资源

• RFC 7322: RFC Style Guide - https://www.rfc-editor.org/rfc/rfc7322
• RFC 2616: HTTP/1.1 (协议范例)
• RFC 7946: GeoJSON (数据格式范例)

下一步

建议按以下顺序编写：

1. Phase 1: 框架章节

   • Abstract, Introduction, Overview
   • 建立文档基本结构

2. Phase 2: 核心规范

   • Syntax Specification
   • Core Elements
   • ABNF Grammar

3. Phase 3: 扩展机制

   • Extension Mechanisms
   • Domain Extensions

4. Phase 4: 完善和审查

   • Security/IANA Considerations
   • Examples and Appendices

[deepracticexs]

决策点1: Element（概念）约定 ✅

经过讨论，达成以下共识：

1. 命名规则

✅ 全小写 + kebab-case

• 正确示例：<agent>, <api-key>, <travel-planner>
• 错误示例：<Agent>, <apiKey>, <API_KEY>

2. 术语约定

✅ Element在DPML中称为"概念"（Concept）

• 每个标签代表一个概念
• 概念具有完备性：自包含、有明确边界
• 示例概念：<role>, <thought>, <execution>, <agent>, <task>

3. 层级关系

✅ 父子关系由概念本身决定，不在协议层约束

• 概念的语义自然决定其可以包含什么
• 例如：<agent> 包含 <llm> 和 <prompt> 是因为"Agent"概念的完备性需要

4. 必需性和可选性

✅ 由Domain Specification决定，协议层不约束

• Agent Domain Spec定义 <agent> 的必需子元素
• Task Domain Spec定义 <task> 的必需子元素
• 协议层只定义规则，不定义具体要求

5. 顺序约束

✅ 协议层不约束元素顺序

• 子元素可以任意顺序出现
• 如果某Domain需要顺序要求，在Domain Spec中定义

---

协议层职责边界

DPML Protocol RFC在Element维度的职责：

✅ 定义：

• 命名规则（kebab-case）
• "概念"（Concept）的定义和完备性原则
• 元素的基本结构规则（遵循XML）

❌ 不定义：

• 具体概念清单（如 <agent>, <task> 等）
• 概念之间的具体层级关系
• 必需性和可选性规则
• 出现顺序要求

---

设计原则：协议定义"如何定义概念"，Domain定义"具体的概念是什么"。

下一步：讨论Attribute（属性）约定

[deepracticexs]

决策点2: Attribute（属性）约定 ✅

经过讨论，达成以下共识：

1. 命名规则

✅ 全小写 + kebab-case（与Element一致）

• 正确示例：api-key, content-type, model-name
• 错误示例：apiKey, API_KEY, ModelName

2. 类型系统

✅ 协议层无类型系统，属性值均为字符串

• XML原生行为：所有属性值都是字符串
• 类型解释和验证由Domain层负责
• 示例：temperature="0.7" 在协议层是字符串，Agent Domain解释为数字

3. 引用机制

✅ 协议层暂不提及 @ 引用语法

• 当前不支持 @env:, @file: 等引用
• 未来需要时通过协议版本升级添加
• 保持协议简洁

4. 必需性和可选性

✅ 由Domain Specification决定

• 协议层不定义哪些属性是必需或可选的
• Agent Domain定义 <llm> 的必需属性
• Task Domain定义 <task> 的必需属性

---

核心设计原则：双重语义（Dual Semantics）

DPML的每一种语法元素都同时承载两种语义：

1. 机器语义（Machine Semantics）

• 面向计算机解析器
• 结构化、可验证、可计算
• 用于：解析、验证、执行、转换

2. AI语义（AI Semantics）

• 面向大语言模型理解
• 概念化、语境化、可推理
• 用于：理解意图、推断关系、生成内容

三层语法的语义倾向

Tag（概念层）：

• 机器语义：结构标记、嵌套关系、可解析性
• AI语义：概念框定、语义完备性、认知锚点
• 双重语义平衡

Attribute（属性层）：

• 机器语义：键值对、类型标记、元数据（主导）
• AI语义：参数说明、配置意图（辅助）
• 偏向机器语义

Content（内容层）：

• 取决于 content-type
• 自然语言：AI语义主导
• 结构化数据：机器语义主导
• 代码：混合语义

---

保留属性（Reserved Attributes）

协议层定义2个保留属性，服务于通用的元需求：

✅ content-type

• 用途：标记内容的格式类型
• 机器语义：告诉解析器如何处理content
• AI语义：让AI理解内容的性质
• 值域：markdown, json, javascript, python, yaml, text 等
• 示例：

  <prompt content-type="markdown">
    # 你是旅游规划师
  </prompt>
  
  <config content-type="json">
  {
    "timeout": 30
  }
  </config>

✅ id

• 用途：元素的唯一标识符
• 机器语义：为引用系统提供标识（虽然当前未实现）
• AI语义：让AI能够指代特定元素
• 示例：

  <prompt id="travel-system-prompt">
    你是旅游规划师
  </prompt>

❌ 不包含的属性

lang 自然语言标记 - 被排除的原因：

• 只对自然语言内容有意义
• 对JSON、代码等无意义
• 不够通用，不应该是保留属性
• 如果Domain需要，可以自行定义（如Agent Domain的 <prompt lang="zh-CN">）

---

设计原则总结

1. 双重语义原则：所有语法元素同时服务机器和AI
2. 保留属性最小化：只定义真正跨Domain通用的属性（2个）
3. 机器语义优先：保留属性主要服务于计算机解析
4. Domain自治：具体属性的语义由Domain定义

---

下一步：讨论Content（内容）约定

[deepracticexs]

决策点3: Content（内容）约定 ✅

经过讨论，Content层的约定非常清晰简洁。

核心原则

1. 格式由 content-type 属性决定

内容的解析规则完全由 content-type 指定：

<prompt content-type="markdown">
  # 你是旅游规划师
  ## 技能
  - 规划行程
</prompt>

<config content-type="json">
{
  "timeout": 30,
  "retry": 3
}
</config>

<script content-type="javascript">
function greet(name) {
  return `Hello, ${name}!`;
}
</script>

2. 语义由概念定义决定（Domain层）

内容的用途和含义由元素的概念定义决定：

• <prompt> 的content是"给AI的系统提示词"（Agent Domain定义）
• <config> 的content是"配置参数"
• <script> 的content是"可执行代码"
• 协议层不关心内容的语义，只关心格式

3. 默认 content-type

如果未指定 content-type 属性：

• 默认为 text（纯文本）
• 不做特殊格式解析
• 保留原始字符串

<!-- 等价于 content-type="text" -->
<prompt>
  你是一个助手
</prompt>

---

协议层的Content规则（遵循XML标准）

1. 空白字符处理

• ✅ 保留所有空白字符（空格、制表符、换行符）
• 遵循XML标准行为
• Domain层可以自行决定是否trim或normalize

2. CDATA支持

• ✅ 支持XML的CDATA语法
• 用于包含特殊字符（<, >, & 等）

<script content-type="javascript">
<![CDATA[
  if (x < 10 && y > 5) {
    console.log("OK");
  }
]]>
</script>

3. 混合内容

• ✅ 协议层语法上允许混合内容（文本 + 子元素）
• ⚠️ 但是否接受由Domain决定

<!-- 协议层语法允许，但Agent Domain可能禁止这种写法 -->
<prompt>
  你是助手
  <skill>规划行程</skill>
  <skill>建议住宿</skill>
</prompt>

大多数Domain可能只接受：

• 纯文本内容
• 或纯子元素内容
• 不接受混合

---

协议层职责边界

协议层定义：

• ✅ Content是元素的文本内容或子元素（XML标准）
• ✅ content-type 属性标记内容的格式类型
• ✅ 基本的XML语法规则（CDATA、空白字符等）

协议层不定义：

• ❌ 具体内容应该是什么（由概念定义决定）
• ❌ 内容如何被使用、解释（由Domain决定）
• ❌ 内容的验证规则（由Domain决定）

---

三个维度总结完成 🎉

我们已经完成了DPML协议的三个核心维度的约定：

1. Element（概念） ✅

• 命名：kebab-case
• 术语：称为"概念"（Concept），具有完备性
• 层级、必需性、顺序：由Domain决定

2. Attribute（属性） ✅

• 命名：kebab-case
• 类型：无类型，纯字符串
• 保留属性：content-type, id
• 双重语义：偏向机器语义

3. Content（内容） ✅

• 格式：由 content-type 决定
• 语义：由概念定义决定
• 协议层：遵循XML标准，极简约定

---

下一步建议：

1. 讨论DPML的文件格式和文档结构
2. 讨论验证规则和错误处理
3. 讨论协议版本管理策略

或者你想先讨论其他方面？

[deepracticexs]

核心设计哲学 🎯

基于实践验证和认知科学研究，DPML的设计遵循两个核心哲学原则：

---

1. 约而不束原则

"约定共识，但不束缚逻辑"

什么是"约"（约定）？

结构层面：

• XML标签体系：<role>, <agent>, <task>
• 层次关系：父子嵌套
• 命名规范：kebab-case

语义层面：

• 使用共识概念，而不是自造词汇
• <personality>, <principle>, <knowledge> - AI和人类都能理解
• 概念即定义，零额外成本

为什么不用 <lero> 或 <xuanwu>？

• 自造词增加信息熵
• 需要额外解释
• 增加认知负担
• 破坏人机共识

什么是"不束"（不束缚）？

不束缚逻辑：

<!-- ❌ 错误：束缚逻辑 -->
<rules>
  <if condition="user_angry">
    <response>抱歉让您不愉快</response>
  </if>
  <if condition="user_confused">
    <response>让我来解释一下</response>
  </if>
</rules>

<!-- ✅ 正确：约而不束 -->
<personality>
我是一个有同理心的助手。当用户情绪不好时，
我会先安抚情绪；当用户困惑时，我会耐心解释。
</personality>

核心思想：

• 给AI原则，不给AI规则
• 让AI理解意图，灵活应对
• 相信AI的判断能力
• 不要用管理机器的方式管理AI

---

2. 认知负担最小化原则

"AI的注意力资源是稀缺的"

认知科学基础

实验验证（基于真实测试）：

• OpenAPI spec（高认知负担）→ AI错误率 > 30%
• Markdown文档（低认知负担）→ AI错误率 < 10%
• DPML（最低认知负担）→ AI错误率 < 5%

核心发现：

• 复杂规则占用AI的"思维带宽"
• 过度约束让AI注意力分散
• 简洁原则 > 详细规则

信息熵与复杂度

规则越多 → 信息熵越高 → 认知负担越重 → 错误率上升
共识概念 → 信息熵低 → 理解成本低 → 准确率提升

DPML的认知优化策略

1. 使用共识概念

<!-- 信息熵低：概念即定义 -->
<role>
  <personality>...</personality>
  <principle>...</principle>
</role>

<!-- 信息熵高：需要额外解释 -->
<xuanwu>
  <qiankun>...</qiankun>
</xuanwu>

2. 极简保留属性

• 只有2个：content-type, id
• 不增加认知负担
• 核心概念数 < 5个

3. 分层降复杂度

• 标签层：结构化（给计算机）
• 内容层：自然语言（给AI）
• 各司其职，不互相干扰

---

3. 双重语义原则（之前已讨论）

每个语法元素同时服务：

• 机器语义：结构化、可解析、可验证
• AI语义：概念化、可理解、可推理

---

设计决策的验证标准

当我们做设计决策时，要问：

✅ 约的检查

• 是否使用了共识概念？
• AI和人类能否不需解释就理解？
• 是否提供了结构和方向？

✅ 不束的检查

• 是否限制了AI的灵活性？
• 是否试图用规则控制行为？
• 是否给了AI原则而非细节？

✅ 认知负担检查

• 核心概念数是否 < 5个？
• 是否增加了信息熵？
• AI的注意力是否被合理使用？

---

实践指导

好的DPML设计：

• 标签清晰：<role>, <agent>, <task>（共识概念）
• 结构简单：层次分明，不过度嵌套
• 内容自由：自然语言，不束缚逻辑
• 认知最小：注意力聚焦核心

糟糕的设计：

• 标新立异：<lero>, <xuanwu>（需要解释）
• 过度约束：if-else规则，穷举情况
• 规则复杂：增加认知负担
• 信息熵高：自造概念，破坏共识

---

哲学总结

DPML的本质是：

• 信任AI的能力：给原则，不给规则
• 尊重认知资源：简洁胜于复杂
• 利用人机共识：共识概念零成本
• 协作而非控制：方向性指导，不固化限制

"标签不光是代码，更是概念的占位。概念是人和AI的共识沉淀。"

---

参考资料：

• 约而不束原则：/workspaces/prompts-blog/03-约而不束原则.md
• 认知负担与信息熵：/workspaces/prompts-blog/04-认知负担与信息熵.md

[deepracticexs]

决策点4: 文件格式和扩展名 ✅

文件扩展名

双扩展名策略：

主扩展名：.dpml ✅ 推荐

• 官方、正式、推荐使用
• 完整表达：Deepractice Prompt Markup Language
• 清晰无歧义

短别名：.pml ✅ 等价

• 便捷、简短的替代
• 在AI应用领域无冲突
• 与 .dpml 完全等价，解析器必须同等对待

说明：

• 虽然 .pml 在其他领域已被使用（Process Monitor Log、PyMOL Script等）
• 但在AI应用定义领域没有冲突
• 作为短别名提供便利性

示例：

# 两者等价
travel-agent.dpml
travel-agent.pml

---

MIME Type

推荐：

• Primary: application/dpml+xml
• Alternative: text/dpml+xml

理由：

• 遵循 <type>/<subtype>+<suffix> 约定
• +xml 后缀表明基于XML
• application/ 前缀表明这是应用特定格式

---

文档结构

1. 根元素

✅ 必须有且只有一个根元素

• 遵循XML良好实践
• 根元素可以是任何Domain定义的概念

<!-- ✅ 正确：单一根元素 -->
<agent>
  <llm model="gpt-4"/>
  <prompt>你是助手</prompt>
</agent>

<!-- ❌ 错误：多个根元素 -->
<agent>...</agent>
<task>...</task>

2. XML声明

⚠️ 可选，不强制要求

<!-- 可以包含，但非必需 -->
<?xml version="1.0" encoding="UTF-8"?>
<agent>
  ...
</agent>

<!-- 也完全合法 -->
<agent>
  ...
</agent>

理由：

• 保持简洁（认知负担最小化原则）
• 大多数现代XML解析器会自动处理
• 如果需要指定编码，建议添加

3. 注释

✅ 支持XML标准注释

<!-- 这是注释 -->
<agent>
  <!-- 注释可以出现在任何位置 -->
  <llm model="gpt-4"/>
</agent>

4. 与XML标准的关系

✅ DPML是XML 1.0的子集

• 遵循XML 1.0语法规范
• 支持：元素、属性、CDATA、注释
• 暂不支持：DTD、XML Schema、Processing Instructions、Entities

---

文件示例

完整的DPML文件示例：

<?xml version="1.0" encoding="UTF-8"?>
<!-- 旅游助手 Agent -->
<agent>
  <llm 
    model="gpt-4" 
    api-key="sk-xxx"
  />
  
  <prompt content-type="markdown">
# 角色
你是一名张家界旅游规划师

## 技能
- 推荐景点
- 规划行程
- 建议住宿
  </prompt>
</agent>

最简DPML文件示例：

<agent>
  <llm model="gpt-4" api-key="sk-xxx"/>
  <prompt>你是一名旅游规划师</prompt>
</agent>

---

总结

已完成的核心决策

1. ✅ Element（概念）约定

   • 命名：kebab-case
   • 术语：概念（Concept），具有完备性
   • 使用共识概念，不标新立异

2. ✅ Attribute（属性）约定

   • 命名：kebab-case
   • 类型：纯字符串，无类型系统
   • 保留属性：content-type, id

3. ✅ Content（内容）约定

   • 格式由 content-type 决定
   • 语义由概念定义决定
   • 支持自然语言、Markdown、JSON、代码等

4. ✅ 文件格式约定

   • 扩展名：.dpml (主) / .pml (别名)
   • MIME: application/dpml+xml
   • 单一根元素，XML声明可选

5. ✅ 设计哲学

   • 约而不束：约定共识，不束缚逻辑
   • 认知负担最小化：AI注意力稀缺
   • 双重语义：机器+AI共同理解

---

下一步：开始编写RFC文档正文

[deepracticexs]

补充设计原则：概念选择的严格考证 ✅

核心原则：最优概念选择标准

在定义领域概念（标签）时，必须严格考证，选择符合以下标准的概念：

四个选择标准

1. 共时性最大

   • 在当前时代、当前领域有最广泛的共识
   • 跨文化、跨语言都能理解
   • 不使用过时或小众的术语

2. 最精准

   • 概念边界清晰
   • 不会产生歧义
   • 一个概念对应一个明确的语义

3. 语义性最强

   • 词汇本身承载丰富的语义
   • 不需要额外解释就能理解
   • AI 和人类都能直接理解

4. 最富有内涵

   • 概念背后有深厚的理论基础
   • 承载着领域的最佳实践
   • 隐含了结构和关系

---

理论基础：信息熵与奥卡姆剃刀

信息熵视角

共识概念（低熵）：

概念 "role" 的信息
├─ 显式信息：4个字母 "r-o-l-e"
└─ 隐式信息：
   ├─ 职责框架
   ├─ 能力边界
   ├─ 行为模式
   └─ 社会关系
   
总信息熵：极低（概念即定义）

自造词汇（高熵）：

概念 "lero" 的信息
├─ 显式信息：4个字母 "l-e-r-o"
└─ 隐式信息：无
└─ 需要额外解释：
   ├─ "lero 是什么？"
   ├─ "lero 包含什么？"
   ├─ "lero 如何使用？"
   └─ 至少需要 50-100 个词解释
   
总信息熵：极高（概念需要大量文本定义）

奥卡姆剃刀应用

"如无必要，勿增实体"

使用共识概念：

<role>           <!-- 0个词的解释成本 -->
  <personality>  <!-- 0个词的解释成本 -->
    我是一个分析师
  </personality>
</role>

总成本：0个额外词汇

使用自造概念：

<lero>           <!-- 需要50个词解释什么是lero -->
  <qiankun>      <!-- 需要30个词解释什么是qiankun -->
    我是一个分析师
  </qiankun>
</lero>

总成本：80+个额外词汇

结论：使用共识概念相当于免费获得80+个词汇的信息量。

---

实践案例

✅ 好的概念选择

概念	共时性	精准性	语义性	内涵	说明
role	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	职责框架，广泛共识
agent	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	AI领域标准术语
personality	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	人格特征，心理学概念
task	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	任务，计算机科学术语
principle	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	原则，哲学/管理学概念

❌ 糟糕的概念选择

概念	问题	信息熵	解释成本
lero	自造词，无共识	极高	50+ 词
xuanwu	文化特定，非通用	高	30+ 词
qiankun	抽象，需要解释	高	40+ 词
thing	过于泛化，不精准	高	20+ 词
processor	技术性强，不直观	中	15+ 词

---

概念选择决策框架

当需要定义新的领域概念时，按以下流程决策：

Step 1: 识别概念需求
├─ 这个概念要表达什么？
└─ 核心语义是什么？

Step 2: 搜索共识概念
├─ 查询该领域的标准术语
├─ 参考权威文献、框架
└─ 询问领域专家

Step 3: 评估候选概念
├─ 共时性：在当前时代是否广泛使用？
├─ 精准性：是否有明确边界？
├─ 语义性：是否自带含义？
└─ 内涵性：是否承载深层知识？

Step 4: 计算信息熵成本
├─ 需要多少词汇解释这个概念？
├─ AI和人类能否直接理解？
└─ 是否符合奥卡姆剃刀？

Step 5: 决策
├─ 所有标准 ⭐⭐⭐⭐ 以上 → 采用
├─ 任一标准 ⭐⭐ 以下 → 拒绝
└─ 找不到合适概念 → 重新审视需求，可能过度设计

---

提示词经济学

使用共识概念是一种提示词经济学的实践：

成本分析

方案A：共识概念

<role>
  <personality>...</personality>
</role>

• Token 成本：~10 tokens
• 信息传递：完整清晰
• AI 理解：即时准确

方案B：自造概念

<!-- 首先需要解释 -->
<!-- lero 是一个职责框架的概念，类似于role... (50+ tokens) -->
<!-- qiankun 是人格特征的容器... (30+ tokens) -->
<lero>
  <qiankun>...</qiankun>
</lero>

• Token 成本：~100+ tokens
• 信息传递：需要额外解释
• AI 理解：需要推理转换

经济效益：使用共识概念节约 90% 的 token 成本

---

设计原则更新

基于此补充，我们的概念选择原则应该是：

原则名称：共识概念优先原则（Consensus Concept First Principle）

定义：在定义领域概念时，必须优先选择共时性最大、最精准、语义性最强、最富有内涵的共识概念，以最小化信息熵和认知负担。

口诀：概念即共识，共识即免费

验证方法：

• 如果需要 >10 个词解释这个概念 → 不是好的共识概念
• 如果 AI 需要额外上下文才能理解 → 不是好的共识概念
• 如果跨文化、跨语言无法直接理解 → 不是好的共识概念

---

与现有原则的关系

这个原则是**"最小化认知负担"原则**的具体实施策略：

最小化认知负担（目标）
    ↓
共识概念优先（策略）
    ↓
严格考证概念选择（方法）
    ↓
四个标准：共时性、精准性、语义性、内涵性（评估）
    ↓
信息熵最小化（结果）

---

总结

核心洞察：

• 共识概念 = 压缩的知识
• 选择概念 = 选择信息密度
• 好的概念 = 免费的提示词
• 自造概念 = 信息熵灾难

实践指导：

1. 永远优先使用领域标准术语
2. 参考权威框架和文献
3. 避免自造或过度抽象的概念
4. 用"解释成本"检验概念质量

理论基础：

• 信息论：最小化信息熵
• 奥卡姆剃刀：如无必要勿增实体
• 认知科学：降低认知负担
• 提示词经济学：最大化token效率

这个原则确保 DPML 作为标记语言的经济性和高效性。