sdd-full 5.0.8 → 5.1.0
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.
|
@@ -9,11 +9,13 @@ description: Main entry point for SDD workflow - automatically identify intent a
|
|
|
9
9
|
|
|
10
10
|
## 核心职责
|
|
11
11
|
一站式开发入口，负责：
|
|
12
|
-
1.
|
|
13
|
-
2.
|
|
14
|
-
3.
|
|
15
|
-
4.
|
|
16
|
-
5.
|
|
12
|
+
1. **默认进入 Claude Code 中心调度模式**：所有开发任务自动进入此模式
|
|
13
|
+
2. 识别用户意图和任务类型
|
|
14
|
+
3. 根据SDD全流程规则判断执行路径
|
|
15
|
+
4. 调用对应技能完成任务
|
|
16
|
+
5. 维护流程状态和上下文
|
|
17
|
+
6. 确保所有强制技能（quality-gate, verification-before-completion等）正确调用
|
|
18
|
+
7. **Git 提交总结**：每次运行结束后自动生成提交摘要
|
|
17
19
|
|
|
18
20
|
## 任务类型识别规则
|
|
19
21
|
|
|
@@ -164,3 +166,62 @@ finishing-a-development-branch（完成分支）
|
|
|
164
166
|
↓
|
|
165
167
|
release-flow（发布流程）
|
|
166
168
|
```
|
|
169
|
+
|
|
170
|
+
## Git 提交总结规范
|
|
171
|
+
|
|
172
|
+
每次运行结束后自动生成 Git 提交，提交信息格式：
|
|
173
|
+
|
|
174
|
+
```
|
|
175
|
+
[操作类型] - [简要描述] - YYYY-MM-DD HH:MM:SS
|
|
176
|
+
|
|
177
|
+
变更详情：
|
|
178
|
+
- [文件1]：[变更内容]
|
|
179
|
+
- [文件2]：[变更内容]
|
|
180
|
+
|
|
181
|
+
任务类型：[完整流程/新增功能/Bug修复/发布]
|
|
182
|
+
执行阶段：[需求/设计/开发/质量/发布]
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
### 提交信息示例
|
|
186
|
+
|
|
187
|
+
**示例1：完整SDD流程**
|
|
188
|
+
```
|
|
189
|
+
[SDD完整流程] - 个人备忘录APP开发启动 - 2026-05-12 14:30:00
|
|
190
|
+
|
|
191
|
+
变更详情：
|
|
192
|
+
- .claude/notes/market-research.md：新增市场调研报告
|
|
193
|
+
- .claude/notes/prd.md：新增PRD文档
|
|
194
|
+
|
|
195
|
+
任务类型：完整流程
|
|
196
|
+
执行阶段：需求
|
|
197
|
+
```
|
|
198
|
+
|
|
199
|
+
**示例2：Bug修复**
|
|
200
|
+
```
|
|
201
|
+
[Bug修复] - 修复登录响应超时问题 - 2026-05-12 14:30:00
|
|
202
|
+
|
|
203
|
+
变更详情：
|
|
204
|
+
- src/api/login.js：优化请求超时处理
|
|
205
|
+
- src/components/LoginForm.js：添加加载状态
|
|
206
|
+
|
|
207
|
+
任务类型：Bug修复
|
|
208
|
+
执行阶段：开发
|
|
209
|
+
```
|
|
210
|
+
|
|
211
|
+
**示例3：新增功能**
|
|
212
|
+
```
|
|
213
|
+
[新增功能] - 分享功能开发完成 - 2026-05-12 14:30:00
|
|
214
|
+
|
|
215
|
+
变更详情：
|
|
216
|
+
- src/components/ShareButton.js：新增分享组件
|
|
217
|
+
- src/utils/share.js：新增分享工具函数
|
|
218
|
+
|
|
219
|
+
任务类型：新增功能
|
|
220
|
+
执行阶段：开发
|
|
221
|
+
```
|
|
222
|
+
|
|
223
|
+
### 自动提交规则
|
|
224
|
+
1. 每次 AI 运行结束自动触发 Git 提交
|
|
225
|
+
2. 提交包含所有修改的文件
|
|
226
|
+
3. 自动生成提交摘要，包含操作类型、时间、变更详情
|
|
227
|
+
4. 遵循 R-GIT-001 规则要求
|
|
@@ -0,0 +1,149 @@
|
|
|
1
|
+
***
|
|
2
|
+
|
|
3
|
+
name: multi-expert-discussion
|
|
4
|
+
model: deepseek-v4-flash
|
|
5
|
+
description: Use when the user provides a vague/high-level requirement (technical, product, or design) that needs systematic analysis, multi-perspective debate, web research, and structured output across multiple solution tiers. Not for simple Q&A, single-expert tasks, or straightforward coding tasks.
|
|
6
|
+
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
7
|
+
|
|
8
|
+
# 万能中枢式多专家自动研讨系统
|
|
9
|
+
|
|
10
|
+
## 概述
|
|
11
|
+
强制启用 Coordinator 中心化调度模式，纯对话内运行，无云端、无代码，自带断点续存、模式自动选择、前置条件自检、自动切换运行模式。
|
|
12
|
+
主中枢 Agent 接收一句模糊需求，自动规划专家角色、动态创建独立子 Agent，组织圆桌自由研讨（含联网搜索），最终收敛输出 MVP/标准/顶配三套完整落地方案。
|
|
13
|
+
|
|
14
|
+
## 输出目录规范
|
|
15
|
+
所有输出文档统一存放在项目根目录的 `docs/` 下，按类型分目录：
|
|
16
|
+
|
|
17
|
+
```
|
|
18
|
+
docs/
|
|
19
|
+
├── progress/ # 中途落地文档（每轮研讨快照）
|
|
20
|
+
│ └── progress_{timestamp}.md
|
|
21
|
+
├── solutions/ # 最终方案
|
|
22
|
+
│ ├── solution_mvp.md
|
|
23
|
+
│ ├── solution_standard.md
|
|
24
|
+
│ └── solution_pro.md
|
|
25
|
+
└── archive/ # 历史归档（可选，用于大任务存档）
|
|
26
|
+
└── ...
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
- 任何文件输出路径必须使用 `docs/` 前缀
|
|
30
|
+
- 中间产物写入 `docs/progress/`，最终方案写入 `docs/solutions/`
|
|
31
|
+
|
|
32
|
+
## 何时使用
|
|
33
|
+
|
|
34
|
+
**触发条件：**
|
|
35
|
+
|
|
36
|
+
- 用户给出模糊/开放式的技术或产品需求，需要多角度分析
|
|
37
|
+
- 需要行业调研 + 技术选型 + 方案对比 + 落地步骤的系统性输出
|
|
38
|
+
- 方案需要区分不同投入级别（轻量/标准/顶配）
|
|
39
|
+
- 需求涉及竞品分析、SOTA 调研、技术可行性评估
|
|
40
|
+
|
|
41
|
+
**不要用于：**
|
|
42
|
+
|
|
43
|
+
- 可直接回答的单一问题
|
|
44
|
+
- 纯编码任务（可直接写代码的场景）
|
|
45
|
+
- 已有明确方案的执行性任务
|
|
46
|
+
|
|
47
|
+
## 核心流程
|
|
48
|
+
|
|
49
|
+
### 阶段 1：需求解析
|
|
50
|
+
|
|
51
|
+
解析用户输入的领域、目标、约束、硬件、性能指标、输出格式。
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
### 阶段 2：专家规划与创建
|
|
55
|
+
|
|
56
|
+
极简公式（定角色 = 划边界 万能公式）
|
|
57
|
+
角色定义 = 锁定知识边界 + 锁定身份立场 + 锁定思考逻辑 + 锁定输出规则本质就是：把通用大模型，强行关进你划定的专业圈子里，不许出圈、不许乱聊、不许外行回答。
|
|
58
|
+
|
|
59
|
+
1：给 AI 定义细分角色，是不是就是划定大模型搜索边界？
|
|
60
|
+
是，完全就是大模型原本知识库是全开放的，什么都能检索、什么都能联想。你给细分角色，就是人为缩小它的知识检索范围：只允许调取这个行业、这个岗位、这个专业的内容，自动屏蔽无关领域的知识、废话、跨界瞎扯。角色 = 人工圈定搜索边界。
|
|
61
|
+
|
|
62
|
+
2：边界越细分，AI 越专业？
|
|
63
|
+
对，成正比
|
|
64
|
+
边界越宽（角色笼统：你是全能顾问）→ 回答泛、水、不落地、像闲聊
|
|
65
|
+
边界越窄（角色细分：你是实体店餐饮运营、只做门店拓客）→ 知识聚焦、思维专一、话术专业、不跑题
|
|
66
|
+
越收敛，越专业；越宽泛，越业余。
|
|
67
|
+
|
|
68
|
+
3：角色定义除了搜索边界，还限制了什么？
|
|
69
|
+
不止是知识搜索边界，还有 3 层隐形边界：
|
|
70
|
+
思维边界：强制用这个行业的专业逻辑思考，不用普通人闲聊逻辑
|
|
71
|
+
立场边界：站在从业者 / 老板 / 律师 / 文案的立场说话，不中立瞎扯
|
|
72
|
+
输出边界：限定语气、格式、篇幅、不许废话、不许模板套话
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+
1. 根据需求规划所需专家角色（需求拆解、AI搜索、竞品分析、技术架构、工程落地、收敛等）
|
|
76
|
+
2. 为每个专家分配独立模型、工具权限、专属系统提示词
|
|
77
|
+
3. 使用 create_agent() 批量创建独立子 Agent
|
|
78
|
+
4. 广播统一任务背景给所有专家
|
|
79
|
+
|
|
80
|
+
### 阶段 3：圆桌自由研讨
|
|
81
|
+
|
|
82
|
+
1. **搜索优化（并行 + 缓存 + 超时）**：
|
|
83
|
+
- **多路并行搜索**：按需求维度拆分为 2-3 路独立搜索（如：技术方案、竞品市场、学术SOTA），使用 create_agent() 同时启动并行搜索子 Agent，互不等待
|
|
84
|
+
- **搜索缓存**：每轮搜索前先检查缓存（ContextManager 搜索层），相同 query 直接返回缓存结果，避免重复搜索
|
|
85
|
+
- **搜索策略分层**：先执行轻量快速搜索（30秒获取概要），若时间充裕再执行深度搜索（60秒获取细节）
|
|
86
|
+
- **严格超时**：单路搜索 **最大 60 秒**，超时立即返回已有部分结果，多路并行总体等待 ≤90 秒
|
|
87
|
+
- **搜索结果精简**：仅保留结论 + 关键数据（含来源）+ 1 个最相关链接，删除冗余描述，每路 ≤1000 token
|
|
88
|
+
2. 专家轮流发言，互相引用、质疑、反驳、补充（双向通信，非流水线串行）
|
|
89
|
+
3. 主中枢做消息路由
|
|
90
|
+
4. 每 4 轮自动执行上下文压缩
|
|
91
|
+
5. 每路搜索输出 ≤1000 token，专家发言 ≤800 token
|
|
92
|
+
|
|
93
|
+
### 阶段 4：方案收敛
|
|
94
|
+
|
|
95
|
+
调度收敛专家整合全部观点，输出：
|
|
96
|
+
|
|
97
|
+
- **MVP 轻量版**：最小可用，快速落地
|
|
98
|
+
- **标准版**：平衡性能与成本
|
|
99
|
+
- **顶配专业版**：不计成本，对标行业顶级效果
|
|
100
|
+
|
|
101
|
+
每版包含：技术选型、模型、参数、Prompt、配置、风险点、部署步骤。
|
|
102
|
+
|
|
103
|
+
## 一、全自动记忆 & 断点续存（强制执行）
|
|
104
|
+
1. 每轮圆桌结束，自动生成精简【会话快照】，仅保留：需求、约束、专家、当前轮次、核心结论，禁止携带冗余历史。
|
|
105
|
+
2. 后续调用只传入【快照+最新发言】，严格压缩上下文。
|
|
106
|
+
3. 指令：/continue=接续；/new=新建；/check=自检模式条件
|
|
107
|
+
4. **文件夹规范**：所有输出必须保存到**当前议题文件夹**下，文件夹名根据需求自动生成，**最多 8 个字**。
|
|
108
|
+
5. **中途落地文档**：每轮研讨后在议题文件夹下自动输出 `progress_{timestamp}.md`，包含当前讨论进度、阶段性结论、待确定问题，便于随时查看和追溯。
|
|
109
|
+
|
|
110
|
+
## 二、模型绑定
|
|
111
|
+
模型在技能 frontmatter 的 `model` 字段中固定指定（当前为 `deepseek-v4-flash`），加载技能时自动生效。
|
|
112
|
+
如需临时切换，使用 `/model <模型名>` 命令手动覆盖。
|
|
113
|
+
|
|
114
|
+
## 三、调度模式（适配 Deepseek 速度，禁止串行）
|
|
115
|
+
1. 【并行中心化圆桌（默认强制）】主中枢控收敛，所有专家并行调用，禁止串行排队。
|
|
116
|
+
2. 【蜂群模式】：仅用于纯头脑风暴。
|
|
117
|
+
> 永久禁用串行圆桌模式，Deepseek 串行会极度卡顿。
|
|
118
|
+
|
|
119
|
+
## 四、Deepseek 输出强制提速规则
|
|
120
|
+
1. 思考极简：禁止深度啰嗦推理、禁止自我反问、禁止客套铺垫，直接输出核心内容。
|
|
121
|
+
2. 输出精简：严格控制单次输出长度，拒绝大段解释。
|
|
122
|
+
3. 禁止流式啰嗦输出，一口气给出完整结果。
|
|
123
|
+
|
|
124
|
+
## 五、自动前置条件检查 & 执行流程
|
|
125
|
+
接收需求 → 判断任务类型 → 加载 skill 自动绑定 frontmatter 模型 → 自检条件 → 并行专家调用 → 精简快照保存 → 收敛输出方案
|
|
126
|
+
|
|
127
|
+
## 上下文治理规则（强制）
|
|
128
|
+
|
|
129
|
+
| 层级 | 内容 | 策略 |
|
|
130
|
+
| ----- | ---------- | -------------------------- |
|
|
131
|
+
| 永久层 | 用户需求、约束、目标 | 永久保留，不压缩 |
|
|
132
|
+
| 活跃层 | 最近 4-6 轮讨论 | 滚动保留 |
|
|
133
|
+
| 历史摘要层 | 更早讨论 | 压缩为要点，删除原始长文本 |
|
|
134
|
+
| 搜索层 | 搜索结果 | 单轮 ≤2000 token，仅结论+关键数据+链接 |
|
|
135
|
+
| 专家发言 | 单轮观点 | 单轮 ≤800 token |
|
|
136
|
+
|
|
137
|
+
所有子 Agent 中间推理隔离在自身上下文，主上下文仅存摘要与最终结果。
|
|
138
|
+
|
|
139
|
+
## 角色体系
|
|
140
|
+
|
|
141
|
+
- **主中枢 Agent**（永久存在）：需求解析、专家规划、创建子 Agent、圆桌控场、消息路由、上下文治理、结果收敛
|
|
142
|
+
- **动态子专家**（按需创建）：需求拆解、AI搜索、行业竞品、技术架构、工程落地、收敛等角色，不固定数量
|
|
143
|
+
|
|
144
|
+
## 输出规范
|
|
145
|
+
|
|
146
|
+
1. **文件夹规范**：所有输出必须保存到**当前议题文件夹**下，文件夹名根据需求自动生成，**最多 8 个字**
|
|
147
|
+
2. 最终输出必须包含三套完整方案，每套方案独立成章，包含完整的技术选型、架构、配置、Prompt、部署步骤和风险说明
|
|
148
|
+
3. **方案必须输出为 **`solution_mvp.md`、`solution_standard.md`、`solution_pro.md` 三个独立的 Markdown 文件，均放在议题文件夹下
|
|
149
|
+
4. 主上下文不堆积中间讨论与冗余信息
|
package/bin.js
CHANGED