@ppdocs/mcp 3.2.30 → 3.2.31
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
package/templates/cursorrules.md
CHANGED
|
@@ -26,6 +26,53 @@ kg_discuss(action:"list") → 检查待回复讨论
|
|
|
26
26
|
|
|
27
27
|
---
|
|
28
28
|
|
|
29
|
+
## 方案制定 (第一性原理)
|
|
30
|
+
|
|
31
|
+
**任何需求，先设计逻辑流程，再写代码。禁止跳过设计直接编码。**
|
|
32
|
+
|
|
33
|
+
### Phase A: 第一性原理分析
|
|
34
|
+
```
|
|
35
|
+
1. 拆解需求本质: 这个功能的核心目的是什么？
|
|
36
|
+
2. 识别输入/输出: 进什么 → 出什么？
|
|
37
|
+
3. 查图谱现状: kg_flowchart(get) → 哪些模块已存在可复用？
|
|
38
|
+
4. 最小化依赖: 能否用最少的模块、最短的路径实现？
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### Phase B: 逻辑流程设计
|
|
42
|
+
```
|
|
43
|
+
用 ASCII 流程图画出完整逻辑:
|
|
44
|
+
|
|
45
|
+
+----------+ +----------+ +----------+
|
|
46
|
+
| 输入 | --> | 处理逻辑 | --> | 输出 |
|
|
47
|
+
+----------+ +----+-----+ +----------+
|
|
48
|
+
|
|
|
49
|
+
+----v-----+
|
|
50
|
+
| 异常分支 |
|
|
51
|
+
+----------+
|
|
52
|
+
|
|
53
|
+
向用户展示流程图，确认逻辑正确后再继续。
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
### Phase C: 细化逻辑节点
|
|
57
|
+
```
|
|
58
|
+
对流程图中每个节点，依次向下细化:
|
|
59
|
+
1. 定义接口: 输入参数 + 返回值
|
|
60
|
+
2. 选择实现: 复用现有 / 新建模块
|
|
61
|
+
3. 标注依赖: 上游数据来源 + 下游消费者
|
|
62
|
+
4. 异常处理: 每个节点的失败路径
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
### Phase D: 按流程执行 + 审查
|
|
66
|
+
```
|
|
67
|
+
按 Phase B 确认的逻辑流程，逐节点实现:
|
|
68
|
+
使用 Step 3 的逐步执行循环 (执行→验证→记录→回写)
|
|
69
|
+
|
|
70
|
+
全部完成后:
|
|
71
|
+
对照逻辑流程图进行审查，确保实现与设计一致
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
---
|
|
75
|
+
|
|
29
76
|
## 标准执行流程
|
|
30
77
|
|
|
31
78
|
### Step 1: 知识锚定 (理解需求时)
|
|
@@ -26,6 +26,53 @@ kg_discuss(action:"list") → 检查待回复讨论
|
|
|
26
26
|
|
|
27
27
|
---
|
|
28
28
|
|
|
29
|
+
## 方案制定 (第一性原理)
|
|
30
|
+
|
|
31
|
+
**任何需求，先设计逻辑流程，再写代码。禁止跳过设计直接编码。**
|
|
32
|
+
|
|
33
|
+
### Phase A: 第一性原理分析
|
|
34
|
+
```
|
|
35
|
+
1. 拆解需求本质: 这个功能的核心目的是什么？
|
|
36
|
+
2. 识别输入/输出: 进什么 → 出什么？
|
|
37
|
+
3. 查图谱现状: kg_flowchart(get) → 哪些模块已存在可复用？
|
|
38
|
+
4. 最小化依赖: 能否用最少的模块、最短的路径实现？
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### Phase B: 逻辑流程设计
|
|
42
|
+
```
|
|
43
|
+
用 ASCII 流程图画出完整逻辑:
|
|
44
|
+
|
|
45
|
+
+----------+ +----------+ +----------+
|
|
46
|
+
| 输入 | --> | 处理逻辑 | --> | 输出 |
|
|
47
|
+
+----------+ +----+-----+ +----------+
|
|
48
|
+
|
|
|
49
|
+
+----v-----+
|
|
50
|
+
| 异常分支 |
|
|
51
|
+
+----------+
|
|
52
|
+
|
|
53
|
+
向用户展示流程图，确认逻辑正确后再继续。
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
### Phase C: 细化逻辑节点
|
|
57
|
+
```
|
|
58
|
+
对流程图中每个节点，依次向下细化:
|
|
59
|
+
1. 定义接口: 输入参数 + 返回值
|
|
60
|
+
2. 选择实现: 复用现有 / 新建模块
|
|
61
|
+
3. 标注依赖: 上游数据来源 + 下游消费者
|
|
62
|
+
4. 异常处理: 每个节点的失败路径
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
### Phase D: 按流程执行 + 审查
|
|
66
|
+
```
|
|
67
|
+
按 Phase B 确认的逻辑流程，逐节点实现:
|
|
68
|
+
使用 Step 3 的逐步执行循环 (执行→验证→记录→回写)
|
|
69
|
+
|
|
70
|
+
全部完成后:
|
|
71
|
+
对照逻辑流程图进行审查，确保实现与设计一致
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
---
|
|
75
|
+
|
|
29
76
|
## 标准执行流程
|
|
30
77
|
|
|
31
78
|
### Step 1: 知识锚定 (理解需求时)
|