@templmf/temp-solf-lmf 0.0.67 → 0.0.69
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/guanwang.zip
ADDED
|
Binary file
|
package/package.json
CHANGED
|
@@ -1,173 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: requirements-checker
|
|
3
|
-
description: 需求文档完善度审查工具，专门用于评估面向 AI 编码（特别是小参数模型如 Qwen3、DeepSeek 等）的需求文档是否达到"机器可执行"标准。当用户提交需求文档、PRD、功能说明、接口文档、设计稿描述，并希望评估其是否足够清晰、完整，或询问"需求写得够不够"、"AI 能不能按这个开发"、"这份文档有没有歧义"时，必须触发此 skill。即使用户只是粘贴了一段需求描述问"这样行吗"，也应触发。
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# 需求文档完善度审查 Skill
|
|
7
|
-
|
|
8
|
-
## 定位
|
|
9
|
-
|
|
10
|
-
本 skill 的目标是：**以小参数 AI 模型（7B-32B，如 Qwen3、DeepSeek-Coder）为执行方**，评估输入的需求文档是否达到"无歧义、可直接编码"的标准。
|
|
11
|
-
|
|
12
|
-
评审视角：**假设执行者是一个能力有限、不会主动追问、遇到歧义会自行脑补的初级 AI**。
|
|
13
|
-
|
|
14
|
-
---
|
|
15
|
-
|
|
16
|
-
## 审查流程
|
|
17
|
-
|
|
18
|
-
### Step 1：识别文档类型与范围
|
|
19
|
-
|
|
20
|
-
首先判断用户提供的是哪类文档：
|
|
21
|
-
- 功能需求文档（PRD / 用户故事）
|
|
22
|
-
- 接口文档（API Spec）
|
|
23
|
-
- 视觉/交互说明
|
|
24
|
-
- 数据模型定义
|
|
25
|
-
- 以上混合
|
|
26
|
-
|
|
27
|
-
根据类型选择对应的审查维度（见下方）。
|
|
28
|
-
|
|
29
|
-
---
|
|
30
|
-
|
|
31
|
-
### Step 2：逐维度审查打分
|
|
32
|
-
|
|
33
|
-
对每个适用维度评分：**✅ 合格 / ⚠️ 需补充 / ❌ 缺失**
|
|
34
|
-
|
|
35
|
-
#### 维度 A：功能行为规格（针对 PRD/功能说明）
|
|
36
|
-
|
|
37
|
-
| 检查项 | 标准 |
|
|
38
|
-
|--------|------|
|
|
39
|
-
| A1 触发条件 | 每个功能都明确了"什么操作/事件触发" |
|
|
40
|
-
| A2 执行动作 | 明确了触发后系统做什么（而非模糊的"展示/处理"） |
|
|
41
|
-
| A3 结果状态 | 明确了操作完成后 UI/数据的最终状态 |
|
|
42
|
-
| A4 异常路径 | 失败/边界场景有明确的处理说明 |
|
|
43
|
-
| A5 状态矩阵 | 加载中、空数据、错误、权限不足等状态都有描述 |
|
|
44
|
-
| A6 交互时序 | 是立即触发还是点击确认？有无防抖/节流要求？ |
|
|
45
|
-
| A7 持久化说明 | 状态是否需要持久化（URL、LocalStorage、后端）？ |
|
|
46
|
-
|
|
47
|
-
#### 维度 B：数据结构定义（针对数据模型/接口文档）
|
|
48
|
-
|
|
49
|
-
| 检查项 | 标准 |
|
|
50
|
-
|--------|------|
|
|
51
|
-
| B1 字段完整性 | 所有展示/使用的字段都有定义 |
|
|
52
|
-
| B2 类型精确性 | 每个字段有明确类型（string/number/enum/array...） |
|
|
53
|
-
| B3 枚举值 | 所有枚举类型列出全部合法值及含义 |
|
|
54
|
-
| B4 单位说明 | 金额（分还是元）、时间（时间戳还是字符串格式）等单位明确 |
|
|
55
|
-
| B5 必填/可选 | 每个字段是否必填有说明 |
|
|
56
|
-
| B6 长度/范围 | 字符串长度限制、数字范围有说明 |
|
|
57
|
-
| B7 前后端命名一致 | 前端变量名与接口字段名是否统一定义 |
|
|
58
|
-
|
|
59
|
-
#### 维度 C：接口规格（针对 API 文档）
|
|
60
|
-
|
|
61
|
-
| 检查项 | 标准 |
|
|
62
|
-
|--------|------|
|
|
63
|
-
| C1 完整 Request 示例 | 包含 headers、body、query params |
|
|
64
|
-
| C2 完整 Response 示例 | 成功响应有完整字段示例 |
|
|
65
|
-
| C3 错误码枚举 | 所有错误 code 列出，并说明前端处理方式 |
|
|
66
|
-
| C4 鉴权说明 | 哪些接口需要 token？token 放在哪？ |
|
|
67
|
-
| C5 幂等性 | 哪些接口可以重试？哪些不能？ |
|
|
68
|
-
| C6 分页规范 | 分页接口的 page/size/total 字段命名统一 |
|
|
69
|
-
| C7 文件上传 | 如有文件上传，明确格式、大小限制、接口格式 |
|
|
70
|
-
|
|
71
|
-
#### 维度 D：视觉与交互说明（针对设计稿/UI 描述）
|
|
72
|
-
|
|
73
|
-
| 检查项 | 标准 |
|
|
74
|
-
|--------|------|
|
|
75
|
-
| D1 组件边界 | 哪些是独立组件，哪些是页面内嵌内容 |
|
|
76
|
-
| D2 响应式断点 | 不同屏幕尺寸下的布局变化有说明 |
|
|
77
|
-
| D3 动效说明 | hover/过渡/加载动画有描述（或明确"无动效"） |
|
|
78
|
-
| D4 间距/字号 | 有具体数值，或明确引用的设计系统（如 Ant Design） |
|
|
79
|
-
| D5 空态设计 | 列表为空时展示什么 |
|
|
80
|
-
| D6 禁用态 | 按钮/输入框的禁用条件和样式 |
|
|
81
|
-
|
|
82
|
-
#### 维度 E：工程约定（全局）
|
|
83
|
-
|
|
84
|
-
| 检查项 | 标准 |
|
|
85
|
-
|--------|------|
|
|
86
|
-
| E1 技术栈 | 前端框架、后端语言、数据库等明确指定 |
|
|
87
|
-
| E2 命名规范 | 文件命名、变量命名、组件命名规则有说明 |
|
|
88
|
-
| E3 目录结构 | 期望的项目结构有示例或说明 |
|
|
89
|
-
| E4 错误处理全局规范 | 统一的 Toast/弹窗/跳转处理方式 |
|
|
90
|
-
| E5 鉴权全局规范 | token 存储位置、过期处理、路由守卫 |
|
|
91
|
-
|
|
92
|
-
---
|
|
93
|
-
|
|
94
|
-
### Step 3：输出审查报告
|
|
95
|
-
|
|
96
|
-
按以下结构输出报告：
|
|
97
|
-
|
|
98
|
-
```
|
|
99
|
-
## 需求完善度审查报告
|
|
100
|
-
|
|
101
|
-
### 总体评级
|
|
102
|
-
[🟢 可以开始开发 / 🟡 需补充后开发 / 🔴 缺失过多，需重写]
|
|
103
|
-
|
|
104
|
-
评级依据：
|
|
105
|
-
- 合格项：X 项
|
|
106
|
-
- 需补充：X 项
|
|
107
|
-
- 缺失项：X 项
|
|
108
|
-
|
|
109
|
-
---
|
|
110
|
-
|
|
111
|
-
### 关键风险点（优先解决）
|
|
112
|
-
> 列出 ❌ 缺失 + 最严重的 ⚠️ 问题，按影响程度排序
|
|
113
|
-
|
|
114
|
-
1. [问题描述] → [如不补充，AI 可能会...]
|
|
115
|
-
2. ...
|
|
116
|
-
|
|
117
|
-
---
|
|
118
|
-
|
|
119
|
-
### 逐维度详情
|
|
120
|
-
|
|
121
|
-
**A. 功能行为规格**
|
|
122
|
-
- ✅ A1 触发条件：已明确
|
|
123
|
-
- ⚠️ A5 状态矩阵：未描述加载中和空数据状态
|
|
124
|
-
→ 补充建议：[具体应该写什么]
|
|
125
|
-
- ❌ A4 异常路径：完全缺失
|
|
126
|
-
→ 补充建议：[具体应该写什么]
|
|
127
|
-
|
|
128
|
-
（其他维度同上格式）
|
|
129
|
-
|
|
130
|
-
---
|
|
131
|
-
|
|
132
|
-
### 补充模板
|
|
133
|
-
|
|
134
|
-
针对缺失项，提供可直接填写的模板片段：
|
|
135
|
-
|
|
136
|
-
[输出对应的文档片段模板，用户填入具体内容即可]
|
|
137
|
-
```
|
|
138
|
-
|
|
139
|
-
---
|
|
140
|
-
|
|
141
|
-
### Step 4：互动追问（可选）
|
|
142
|
-
|
|
143
|
-
如果用户的文档描述某个模块，但信息太少无法完整审查，主动询问：
|
|
144
|
-
- "这个模块有对应的接口文档吗？"
|
|
145
|
-
- "用的是哪个前端框架？"
|
|
146
|
-
- "有设计稿还是只有文字描述？"
|
|
147
|
-
|
|
148
|
-
不要假设，不要跳过，直接问。
|
|
149
|
-
|
|
150
|
-
---
|
|
151
|
-
|
|
152
|
-
## 评级标准
|
|
153
|
-
|
|
154
|
-
| 评级 | 条件 |
|
|
155
|
-
|------|------|
|
|
156
|
-
| 🟢 可以开始开发 | 无 ❌ 缺失项，⚠️ 项少于 3 个且不涉及核心流程 |
|
|
157
|
-
| 🟡 需补充后开发 | 存在 1-3 个 ❌ 缺失项，或核心流程有 ⚠️ 问题 |
|
|
158
|
-
| 🔴 缺失过多，需重写 | 超过 3 个 ❌ 缺失项，或维度 A/B/C 有重大空白 |
|
|
159
|
-
|
|
160
|
-
---
|
|
161
|
-
|
|
162
|
-
## 常见高风险模式（自动标记）
|
|
163
|
-
|
|
164
|
-
审查时特别注意这些模式，发现即标红：
|
|
165
|
-
|
|
166
|
-
1. **"按需展示"** → 没有明确展示条件
|
|
167
|
-
2. **"处理一下"** → 动作不明确
|
|
168
|
-
3. **"状态/金额/时间"字段没有单位** → 前后端会对不上
|
|
169
|
-
4. **只有成功流程，没有失败流程** → AI 会忽略错误处理
|
|
170
|
-
5. **"参考竞品"** → AI 不知道竞品长什么样
|
|
171
|
-
6. **枚举值用"等"结尾** → AI 会自己发明值
|
|
172
|
-
7. **接口文档只有路径，没有字段说明** → AI 会猜字段名
|
|
173
|
-
8. **设计稿只有图片，没有任何标注** → 间距/字体会被随机发明
|