|
| 1 | +<?xml version="1.0" encoding="UTF-8"?> |
| 2 | +<!-- |
| 3 | + 元模式定义:定义什么是模式 |
| 4 | + 这是一个自举的定义 - 用模式的形式定义模式本身 |
| 5 | +--> |
| 6 | +<pattern name="pattern"> |
| 7 | + |
| 8 | + <essence> |
| 9 | + <purpose> |
| 10 | + 定义DPML认知框架模式的标准结构,确保所有模式定义具有一致的格式和完备性。 |
| 11 | + 模式是可复制的原型(Replicable Archetype),它定义了结构约束和语义边界, |
| 12 | + 但不限制具体内容的创造。 |
| 13 | + </purpose> |
| 14 | + |
| 15 | + <metaphor> |
| 16 | + 青铜铸造的"模范":模(内模)定义形状结构,范(外模)定义边界约束, |
| 17 | + 两者结合形成完整的铸造系统,可以生产无数个形状一致的器物。 |
| 18 | + </metaphor> |
| 19 | + </essence> |
| 20 | + |
| 21 | + <structure> |
| 22 | + <required> |
| 23 | + <element name="essence"> |
| 24 | + 模式的本质和核心价值,包含purpose(目的)和可选的metaphor(隐喻) |
| 25 | + </element> |
| 26 | + |
| 27 | + <element name="structure"> |
| 28 | + 模式的结构定义,说明包含哪些必需元素和可选元素 |
| 29 | + </element> |
| 30 | + |
| 31 | + <element name="semantics"> |
| 32 | + 各元素的语义约定,框定每个元素应该包含什么性质的内容 |
| 33 | + </element> |
| 34 | + </required> |
| 35 | + |
| 36 | + <optional> |
| 37 | + <element name="usage"> |
| 38 | + 使用指南,包含适用场景、示例和反模式 |
| 39 | + </element> |
| 40 | + |
| 41 | + <element name="validation"> |
| 42 | + 验证规则和质量标准 |
| 43 | + </element> |
| 44 | + </optional> |
| 45 | + |
| 46 | + <composition> |
| 47 | + 模式定义应按照 essence → structure → semantics → usage → validation 的顺序组织, |
| 48 | + 体现从本质到形式、从抽象到具体的递进关系 |
| 49 | + </composition> |
| 50 | + </structure> |
| 51 | + |
| 52 | + <semantics> |
| 53 | + <essence> |
| 54 | + 回答"为什么需要这个模式"和"这个模式的核心价值是什么"。 |
| 55 | + 应该是声明式的,说明模式解决什么问题、服务什么场景。 |
| 56 | + metaphor是可选的,但好的隐喻能帮助理解模式的本质。 |
| 57 | + </essence> |
| 58 | + |
| 59 | + <structure> |
| 60 | + 回答"这个模式由哪些部分组成"。 |
| 61 | + 必须明确区分required(必需)和optional(可选)元素。 |
| 62 | + composition说明元素之间的关系、顺序或组合规则。 |
| 63 | + </structure> |
| 64 | + |
| 65 | + <semantics> |
| 66 | + 回答"每个元素意味着什么"。 |
| 67 | + 为每个元素定义语义边界 - 框定应该包含什么性质的内容,但不限制具体内容本身。 |
| 68 | + 体现"约而不束"原则:约束语义性质,不束缚内容创造。 |
| 69 | + </semantics> |
| 70 | + |
| 71 | + <usage> |
| 72 | + 回答"何时用、如何用、怎样用好"。 |
| 73 | + scenarios描述适用场景,examples提供具体示例, |
| 74 | + anti-patterns指出常见误用,帮助使用者避免错误。 |
| 75 | + </usage> |
| 76 | + |
| 77 | + <validation> |
| 78 | + 回答"如何判断使用是否正确"。 |
| 79 | + 可以包含结构验证规则(必需元素是否齐全)和 |
| 80 | + 质量标准(内容是否符合语义约定)。 |
| 81 | + </validation> |
| 82 | + </semantics> |
| 83 | + |
| 84 | + <usage> |
| 85 | + <scenarios> |
| 86 | + <scenario>设计新的认知框架模式时作为模板</scenario> |
| 87 | + <scenario>审查现有模式定义是否完备和规范</scenario> |
| 88 | + <scenario>为自动化工具提供验证标准</scenario> |
| 89 | + <scenario>为社区贡献者提供统一的模式定义规范</scenario> |
| 90 | + </scenarios> |
| 91 | + |
| 92 | + <examples> |
| 93 | + <!-- 见附录:使用元模式定义thought模式 --> |
| 94 | + </examples> |
| 95 | + |
| 96 | + <anti-patterns> |
| 97 | + <anti-pattern> |
| 98 | + <mistake>在structure中包含具体内容示例</mistake> |
| 99 | + <why>structure应该只定义"有哪些元素",不应该包含"元素里写什么"</why> |
| 100 | + <correct>具体内容示例应该放在usage/examples中</correct> |
| 101 | + </anti-pattern> |
| 102 | + |
| 103 | + <anti-pattern> |
| 104 | + <mistake>semantics定义过于宽泛,如"可以是任何内容"</mistake> |
| 105 | + <why>这失去了"框定语义边界"的作用</why> |
| 106 | + <correct>应该明确说明"什么性质的内容",如"客观描述"、"推理过程"等</correct> |
| 107 | + </anti-pattern> |
| 108 | + |
| 109 | + <anti-pattern> |
| 110 | + <mistake>required元素过多,导致使用负担重</mistake> |
| 111 | + <why>违反"最小化"原则</why> |
| 112 | + <correct>只将真正必不可少的元素标记为required</correct> |
| 113 | + </anti-pattern> |
| 114 | + </anti-patterns> |
| 115 | + </usage> |
| 116 | + |
| 117 | + <validation> |
| 118 | + <rules> |
| 119 | + <rule>模式定义必须包含essence、structure、semantics三个必需元素</rule> |
| 120 | + <rule>structure必须明确区分required和optional</rule> |
| 121 | + <rule>semantics必须为每个required元素提供语义定义</rule> |
| 122 | + <rule>所有元素名称必须遵循kebab-case命名规范</rule> |
| 123 | + </rules> |
| 124 | + |
| 125 | + <quality-criteria> |
| 126 | + <criterion>purpose是否清晰说明了模式的价值和适用场景</criterion> |
| 127 | + <criterion>required元素是否精简(≤5个为佳)</criterion> |
| 128 | + <criterion>semantics是否框定了清晰的语义边界</criterion> |
| 129 | + <criterion>是否提供了足够的使用示例</criterion> |
| 130 | + <criterion>是否指出了常见的误用模式</criterion> |
| 131 | + </quality-criteria> |
| 132 | + </validation> |
| 133 | + |
| 134 | +</pattern> |
0 commit comments