Skip to content

Commit 6b056c8

Browse files
committed
docs(whitepaper): retranslate English version based on latest Chinese version
- Completely retranslate whitepaper from scratch based on Chinese version - Add missing Section 3.4 'End-to-End Example: Complete Loop Observability' - Align all chapter structures and content between CN and EN versions - Fix inconsistent technical specification references - Update terminology to be more idiomatic in English - Maintain theoretical rigor and all code examples - Total 2011 lines fully translated and aligned
1 parent 7553677 commit 6b056c8

7 files changed

Lines changed: 2200 additions & 1205 deletions

File tree

Lines changed: 134 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,134 @@
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

Comments
 (0)