@double-codeing/flow2spec 3.0.7 → 3.0.8
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/README.md
CHANGED
|
@@ -7,6 +7,9 @@ Flow2Spec 用于在业务仓库初始化一套可持续的 AI 协作结构：
|
|
|
7
7
|
|
|
8
8
|
集中管理项目知识，同时不破坏各工具原生的 rules/skills 加载机制。
|
|
9
9
|
|
|
10
|
+
> 🎬 **在线演示**：组内分享用的 13 页 HTML PPT（脱敏版）——**<https://lands-1203.github.io/Flow2Spec/>**
|
|
11
|
+
> `←` `→` 翻页，`S` 打开演讲者模式。源文件见 [presentations/flow2spec-intro-public/](./presentations/flow2spec-intro-public/)。
|
|
12
|
+
|
|
10
13
|
---
|
|
11
14
|
|
|
12
15
|
## 快速开始
|
|
@@ -24,15 +27,15 @@ npm install -g @double-codeing/flow2spec@latest
|
|
|
24
27
|
|
|
25
28
|
`init` 完成后的目录结构：
|
|
26
29
|
|
|
27
|
-
| 路径
|
|
28
|
-
|
|
29
|
-
| `.Knowledge/stock-docs/`
|
|
30
|
-
| `.Knowledge/req-docs/`
|
|
31
|
-
| `.Knowledge/topics/`
|
|
32
|
-
| `.Knowledge/template/`
|
|
33
|
-
| `.Knowledge/manifest-routing.json` + `matchers/` | 机器可读路由与关键词索引
|
|
34
|
-
| `配置根/rules/` + `配置根/skills/`
|
|
35
|
-
| `flow2spec.config.json`
|
|
30
|
+
| 路径 | 用途 |
|
|
31
|
+
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------ |
|
|
32
|
+
| `.Knowledge/stock-docs/` | 架构说明、终稿等沉淀文档 |
|
|
33
|
+
| `.Knowledge/req-docs/` | 需求澄清与技术方案 |
|
|
34
|
+
| `.Knowledge/topics/` | 主题路由摘要 |
|
|
35
|
+
| `.Knowledge/template/` | 终稿与技术方案模板 |
|
|
36
|
+
| `.Knowledge/manifest-routing.json` + `matchers/` | 机器可读路由与关键词索引 |
|
|
37
|
+
| `配置根/rules/` + `配置根/skills/` | 各工具规则与技能入口 |
|
|
38
|
+
| `flow2spec.config.json` | 控制 `subAgent`、`switchAgentVerification`、`changeTracking`（各技能独立子项），默认均为 `false` |
|
|
36
39
|
|
|
37
40
|
> `init` 只做结构与模板补齐，业务文档内容由 `f2s-*` 技能维护。详见 [Flow2Spec使用说明](./docs/Flow2Spec使用说明.md)。
|
|
38
41
|
|
|
@@ -45,9 +48,11 @@ npm install -g @double-codeing/flow2spec@latest
|
|
|
45
48
|
所有技能均以 `f2s-*` 前缀或主题名在 Agent 内触发。以下按**业务场景**分组，标明推荐执行链路与前置条件。
|
|
46
49
|
|
|
47
50
|
> **前置要求**：涉及「旧库迁移」或「包模板对齐」时，需先在本地安装最新 CLI：
|
|
51
|
+
>
|
|
48
52
|
> ```bash
|
|
49
53
|
> npm install -g @double-codeing/flow2spec@latest
|
|
50
54
|
> ```
|
|
55
|
+
>
|
|
51
56
|
> 其余场景以仓库内已初始化的规则与技能为准。
|
|
52
57
|
|
|
53
58
|
### 一、需求交付链路
|
|
@@ -56,40 +61,41 @@ npm install -g @double-codeing/flow2spec@latest
|
|
|
56
61
|
|
|
57
62
|
> **任务清单控制**：`f2s-req-plan` **强制**创建任务清单；`f2s-implement-tech-design` 是否使用任务清单取决于 `changeTracking.implement` 配置。
|
|
58
63
|
|
|
59
|
-
| 场景
|
|
60
|
-
|
|
61
|
-
| 有 PRD，需澄清后出方案并落地
|
|
62
|
-
| 已有方案，需强制任务清单后实现 | `f2s-req-plan`
|
|
64
|
+
| 场景 | 执行链 | 产出 |
|
|
65
|
+
| ------------------------------ | ----------------------------------------------------------------------------------- | --------------------------------- |
|
|
66
|
+
| 有 PRD，需澄清后出方案并落地 | `f2s-req-clarify` → `f2s-req-backend` → `f2s-implement-tech-design` → `f2s-kb-feat` | 澄清纪要 → 技术方案 → 实现+知识库 |
|
|
67
|
+
| 已有方案，需强制任务清单后实现 | `f2s-req-plan`
|
|
68
|
+
| 可确认任务清单与实现编排 |
|
|
63
69
|
|
|
64
70
|
### 二、知识沉淀链路
|
|
65
71
|
|
|
66
72
|
将非结构化信息（口述、草稿、外部文档、代码）转化为可检索的知识资产。
|
|
67
73
|
|
|
68
|
-
| 场景
|
|
69
|
-
|
|
74
|
+
| 场景 | 执行链 | 产出 |
|
|
75
|
+
| ----------------- | -------------------------------------------------- | ------------------------------ |
|
|
70
76
|
| 从口述/草稿到终稿 | `f2s-doc-arch` → `f2s-doc-final` → `f2s-ctx-build` | 架构初稿 → 规范终稿 → 主题路由 |
|
|
71
|
-
| 外部文档转知识库
|
|
72
|
-
| 存量代码/散稿补录 | `f2s-doc-add` 或 `f2s-kb-sync`
|
|
77
|
+
| 外部文档转知识库 | `f2s-doc-final` → `f2s-ctx-build` | 可检索 Markdown + 路由索引 |
|
|
78
|
+
| 存量代码/散稿补录 | `f2s-doc-add` 或 `f2s-kb-sync` | 自动提取能力 → 主题索引 |
|
|
73
79
|
|
|
74
80
|
### 三、日常协作
|
|
75
81
|
|
|
76
82
|
缺陷修复、迭代与上下文同步。
|
|
77
83
|
|
|
78
|
-
| 场景
|
|
79
|
-
|
|
80
|
-
| 修复缺陷
|
|
81
|
-
| 新增功能
|
|
82
|
-
| 同步已实现能力 | `f2s-kb-sync`
|
|
83
|
-
| 解决合并冲突
|
|
84
|
+
| 场景 | 技能 |
|
|
85
|
+
| -------------- | -------------- |
|
|
86
|
+
| 修复缺陷 | `f2s-kb-fix` |
|
|
87
|
+
| 新增功能 | `f2s-kb-feat` |
|
|
88
|
+
| 同步已实现能力 | `f2s-kb-sync` |
|
|
89
|
+
| 解决合并冲突 | `f2s-kb-merge` |
|
|
84
90
|
|
|
85
91
|
### 四、仓库治理
|
|
86
92
|
|
|
87
93
|
一次性或周期性的结构化维护。
|
|
88
94
|
|
|
89
|
-
| 场景
|
|
90
|
-
|
|
95
|
+
| 场景 | 技能 | 注意事项 |
|
|
96
|
+
| -------------------------------------------- | ---------------- | ------------------ |
|
|
91
97
|
| 旧版迁移（rules/skills 散稿 → `.Knowledge`） | `f2s-kb-migrate` | 一次性；执行前备份 |
|
|
92
|
-
| 模板对齐（包升级后同步）
|
|
98
|
+
| 模板对齐（包升级后同步） | `f2s-kb-upgrade` | 可重复执行 |
|
|
93
99
|
|
|
94
100
|
---
|
|
95
101
|
|
|
@@ -109,4 +115,3 @@ npm install -g @double-codeing/flow2spec@latest
|
|
|
109
115
|
- [README-体系与原理](./docs/README-体系与原理.md)
|
|
110
116
|
- [Flow2Spec-使用案例-模拟对话](./docs/Flow2Spec-使用案例-模拟对话.md)
|
|
111
117
|
- [Flow2Spec-设计说明](./docs/Flow2Spec-设计说明.md)
|
|
112
|
-
- [Flow2Spec-演讲稿](./docs/Flow2Spec-演讲稿.md)
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@double-codeing/flow2spec",
|
|
3
|
-
"version": "3.0.
|
|
3
|
+
"version": "3.0.8",
|
|
4
4
|
"description": "在业务仓库初始化「文档驱动、可写回知识库」的 AI 协作骨架：项目根 .Knowledge 承载 stock-docs/req-docs 与机读路由，.cursor/.claude/.codex 写入 f2s-* 规则与技能（含 Karpathy 式编码行为准则 f2s-karpathy-guidelines，init 同步 rules / Codex topics / skills）；init 只落结构与模板，业务内容由各 f2s-* 技能在对话中维护。",
|
|
5
5
|
"homepage": "https://github.com/Lands-1203/Flow2Spec#readme",
|
|
6
6
|
"repository": {
|
|
@@ -1,411 +0,0 @@
|
|
|
1
|
-
# Flow2Spec 演讲稿
|
|
2
|
-
|
|
3
|
-
> 每张幻灯片：标题 + 图 + 极少文字。演讲说明在引用块里。
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## Slide 1 · 开场
|
|
8
|
-
|
|
9
|
-
```
|
|
10
|
-
Flow2Spec
|
|
11
|
-
|
|
12
|
-
让 AI 持续理解你的项目
|
|
13
|
-
```
|
|
14
|
-
|
|
15
|
-
---
|
|
16
|
-
|
|
17
|
-
## Slide 2 · 你遇过这种情况吗？
|
|
18
|
-
|
|
19
|
-
```
|
|
20
|
-
┌─────────────────────────────────────────────┐
|
|
21
|
-
│ │
|
|
22
|
-
│ 你： 帮我改一下订单模块的支付回调逻辑 │
|
|
23
|
-
│ │
|
|
24
|
-
│ AI： 好的，我来看一下…… │
|
|
25
|
-
│ （把整个项目翻了一遍） │
|
|
26
|
-
│ 这个回调是 Webhook 还是轮询？ │
|
|
27
|
-
│ 幂等键是什么？用什么存储？ │
|
|
28
|
-
│ 有没有失败重试机制…… │
|
|
29
|
-
│ │
|
|
30
|
-
│ 你： （开始从头解释项目背景） │
|
|
31
|
-
│ │
|
|
32
|
-
└─────────────────────────────────────────────┘
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
> 每次新会话都要重新介绍项目，是所有用 AI 协作开发的团队的共同痛点。背景质量取决于你那天愿意解释多少。
|
|
36
|
-
|
|
37
|
-
---
|
|
38
|
-
|
|
39
|
-
## Slide 3 · 问题的根源
|
|
40
|
-
|
|
41
|
-
```mermaid
|
|
42
|
-
graph LR
|
|
43
|
-
A[架构约定] --- X[ ]
|
|
44
|
-
B[技术方案] --- X
|
|
45
|
-
C[模块边界] --- X
|
|
46
|
-
D[团队经验] --- X
|
|
47
|
-
X:::hidden
|
|
48
|
-
|
|
49
|
-
classDef hidden display:none
|
|
50
|
-
```
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
**知识散落在三个地方：代码、文档、人脑**
|
|
55
|
-
|
|
56
|
-
没有结构 → AI 每次从零开始
|
|
57
|
-
|
|
58
|
-
> 不是 AI 变笨了，是它每次都在盲飞。
|
|
59
|
-
|
|
60
|
-
---
|
|
61
|
-
|
|
62
|
-
## Slide 4 · Flow2Spec 是什么
|
|
63
|
-
|
|
64
|
-
```
|
|
65
|
-
一套规范 + 工具链
|
|
66
|
-
|
|
67
|
-
把项目知识组织好 → 让 AI 随时能读懂
|
|
68
|
-
```
|
|
69
|
-
|
|
70
|
-
```mermaid
|
|
71
|
-
graph LR
|
|
72
|
-
A[业务知识] -->|统一放| B[.Knowledge/] --> E[AI 工具]
|
|
73
|
-
C[执行规则] -->|保留在| D[各工具配置根] --> E
|
|
74
|
-
F[任务进度] -->|记录于| G[.task/] -->|跨会话续作| E
|
|
75
|
-
```
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
> 不是新的 AI 框架，不是新的工具。就是一套把知识放对地方的规范。
|
|
80
|
-
|
|
81
|
-
---
|
|
82
|
-
|
|
83
|
-
## Slide 5 · 两层结构
|
|
84
|
-
|
|
85
|
-
```mermaid
|
|
86
|
-
graph TB
|
|
87
|
-
subgraph K[" .Knowledge/ 知识层 "]
|
|
88
|
-
K1[stock-docs\n架构 / 终稿]
|
|
89
|
-
K2[req-docs\n需求 / 方案]
|
|
90
|
-
K3[topics\n路由摘要]
|
|
91
|
-
K4[manifest-routing.json]
|
|
92
|
-
K5[matchers/*.json]
|
|
93
|
-
end
|
|
94
|
-
|
|
95
|
-
subgraph R[" 配置根 执行层 "]
|
|
96
|
-
R1[.cursor/rules/]
|
|
97
|
-
R2[.claude/rules/]
|
|
98
|
-
R3[.codex/AGENTS.md]
|
|
99
|
-
end
|
|
100
|
-
|
|
101
|
-
K -->|知识输入| AI[AI 工具]
|
|
102
|
-
R -->|规则约束| AI
|
|
103
|
-
```
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
**知识随项目迭代 · 规则随工具升级**
|
|
108
|
-
|
|
109
|
-
> 两者生命周期不同，混在一起就会互相干扰。分开是这套设计最基本的决策。
|
|
110
|
-
|
|
111
|
-
---
|
|
112
|
-
|
|
113
|
-
## Slide 6 · 不是全量加载，是精准路由
|
|
114
|
-
|
|
115
|
-
```mermaid
|
|
116
|
-
graph LR
|
|
117
|
-
T[用户任务] --> M[manifest-routing.json\n读路由表]
|
|
118
|
-
M -->|关键词匹配| MT[matchers/xxx.json\n只读这一个分片]
|
|
119
|
-
MT -->|命中| TP[topics/xxx.md\n只读相关主题]
|
|
120
|
-
TP --> ACT[执行]
|
|
121
|
-
M -->|未命中| FB[fallback-triage\n分诊]
|
|
122
|
-
```
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
**上下文窗口有限 · 加载什么 = 不加载什么**
|
|
127
|
-
|
|
128
|
-
> 大多数系统是把所有文档塞进去，再让 AI 自己过滤。Flow2Spec 反过来，先路由再加载。
|
|
129
|
-
|
|
130
|
-
---
|
|
131
|
-
|
|
132
|
-
## Slide 7 · 四步流水线
|
|
133
|
-
|
|
134
|
-
```
|
|
135
|
-
match expand verify act
|
|
136
|
-
|
|
137
|
-
命中主候选 → 展开依赖主题 → 缺口检查 → 执行
|
|
138
|
-
↓
|
|
139
|
-
置信度不足
|
|
140
|
-
↓
|
|
141
|
-
先澄清
|
|
142
|
-
```
|
|
143
|
-
|
|
144
|
-
**不是命中就跑，是确认够了再动**
|
|
145
|
-
|
|
146
|
-
> 防止 AI 拿着半份信息就开始干，干到一半发现方向不对。
|
|
147
|
-
|
|
148
|
-
---
|
|
149
|
-
|
|
150
|
-
## Slide 8 · matchers 分片是个细节，但很重要
|
|
151
|
-
|
|
152
|
-
```
|
|
153
|
-
❌ 常见做法 ✅ Flow2Spec
|
|
154
|
-
|
|
155
|
-
manifest.json manifest-routing.json
|
|
156
|
-
├── task1 ├── task1 → matcherPath: m-order.json
|
|
157
|
-
│ └── keywords: [...] ├── task2 → matcherPath: m-payment.json
|
|
158
|
-
├── task2 └── task3 → matcherPath: m-refund.json
|
|
159
|
-
│ └── keywords: [...]
|
|
160
|
-
└── task3 m-order.json ← 路由时只读这一个
|
|
161
|
-
└── keywords: [...] { includeAny: [...] }
|
|
162
|
-
```
|
|
163
|
-
|
|
164
|
-
- 更新关键词不需要动路由结构
|
|
165
|
-
- 每次路由 token 成本固定且极小
|
|
166
|
-
|
|
167
|
-
> 关键词会随业务演化频繁更新，路由结构相对稳定。把两者混在一起，每次小改都要读大文件。
|
|
168
|
-
|
|
169
|
-
---
|
|
170
|
-
|
|
171
|
-
## Slide 9 · topicDependencies：依赖挂在主题上
|
|
172
|
-
|
|
173
|
-
```
|
|
174
|
-
❌ 挂在任务级 ✅ 挂在主题级
|
|
175
|
-
|
|
176
|
-
task: implement topicDependencies:
|
|
177
|
-
topics: implement-tech-design:
|
|
178
|
-
- stock-docs-vs-req-docs - stock-docs-vs-req-docs
|
|
179
|
-
- implement-tech-design
|
|
180
|
-
任何路径加载 implement-tech-design
|
|
181
|
-
task2: (新增，漏写了前置) 都自动带上前置依赖
|
|
182
|
-
topics:
|
|
183
|
-
- implement-tech-design ← 新增任务不需要重新声明
|
|
184
|
-
← 漏了前置，静默失效
|
|
185
|
-
```
|
|
186
|
-
|
|
187
|
-
> 语义上的"必须先理解 X 才能做 Y"，应该在 Y 上声明，而不是在每条任务上重复声明。
|
|
188
|
-
|
|
189
|
-
---
|
|
190
|
-
|
|
191
|
-
## Slide 10 · 知识维护闭环
|
|
192
|
-
|
|
193
|
-
```mermaid
|
|
194
|
-
graph LR
|
|
195
|
-
DEV[代码改动] -->|修复 Bug| FIX[f2s-kb-fix\n自动同步知识库]
|
|
196
|
-
DEV -->|新增能力| FEAT[f2s-kb-feat\n自动同步知识库]
|
|
197
|
-
DEV -->|会话结束| SYNC[f2s-kb-sync\n先出大纲再写入]
|
|
198
|
-
|
|
199
|
-
FIX --> K[.Knowledge/]
|
|
200
|
-
FEAT --> K
|
|
201
|
-
SYNC --> K
|
|
202
|
-
K --> AI[下次会话的 AI]
|
|
203
|
-
```
|
|
204
|
-
|
|
205
|
-
|
|
206
|
-
|
|
207
|
-
**维护知识库不是额外的工作 · 是开发动作的一部分**
|
|
208
|
-
|
|
209
|
-
> 知识库腐化的原因通常不是懒，是把"更新文档"当成了另一件要做的事。这里的设计是让它变成同一件事。
|
|
210
|
-
|
|
211
|
-
---
|
|
212
|
-
|
|
213
|
-
## Slide 11 · 完整工作流
|
|
214
|
-
|
|
215
|
-
```
|
|
216
|
-
新需求
|
|
217
|
-
│
|
|
218
|
-
▼
|
|
219
|
-
f2s-req-clarify ── 澄清需求边界、反问直到清楚
|
|
220
|
-
│
|
|
221
|
-
▼
|
|
222
|
-
f2s-req-backend ── 生成技术方案 → req-docs/
|
|
223
|
-
│
|
|
224
|
-
▼
|
|
225
|
-
implement-tech-design
|
|
226
|
-
├── 输出任务列表 ← 不可跳过
|
|
227
|
-
├── 实现前提问 ← 不可跳过
|
|
228
|
-
├── 按任务实现
|
|
229
|
-
└── 输出待完成清单
|
|
230
|
-
│
|
|
231
|
-
▼
|
|
232
|
-
f2s-kb-feat ── 新能力同步进知识库
|
|
233
|
-
```
|
|
234
|
-
|
|
235
|
-
> implement-tech-design 里强制步骤是写在规则里的约束，不是文档建议，不能被跳过。
|
|
236
|
-
|
|
237
|
-
---
|
|
238
|
-
|
|
239
|
-
## Slide 12 · 任务清单与跨会话续作
|
|
240
|
-
|
|
241
|
-
```
|
|
242
|
-
会话中断了怎么办？
|
|
243
|
-
```
|
|
244
|
-
|
|
245
|
-
```mermaid
|
|
246
|
-
graph LR
|
|
247
|
-
FEAT["f2s-kb-feat\nf2s-kb-fix\nimplement-tech-design"] -->|"changeTracking: true"| TJ["写入 todo.json\n+ task.md checklist"]
|
|
248
|
-
RP["f2s-req-plan\n（始终创建）"] --> TJ
|
|
249
|
-
|
|
250
|
-
TJ --> NS["新会话第一句话"]
|
|
251
|
-
NS -->|"关键词匹配"| LD["展示剩余步骤\n加载 SKILL.md 上下文"]
|
|
252
|
-
LD --> RS["直接继续"]
|
|
253
|
-
```
|
|
254
|
-
|
|
255
|
-
|
|
256
|
-
|
|
257
|
-
```
|
|
258
|
-
模式 A changeTracking: true 技能自动创建清单，下次会话关键词自动续作
|
|
259
|
-
模式 B f2s-req-plan 明确规划 + 实现，始终创建清单，不依赖配置
|
|
260
|
-
```
|
|
261
|
-
|
|
262
|
-
**任务不会因为会话结束而丢失 · 技能约束可完整恢复**
|
|
263
|
-
|
|
264
|
-
> 大模型没有跨会话记忆，这是结构性缺陷。todo.json 是显式的任务锚点，关键词匹配让用户不需要说"我上次在做 XX 任务"，直接描述问题就能续上。
|
|
265
|
-
|
|
266
|
-
---
|
|
267
|
-
|
|
268
|
-
## Slide 13 · Agent 执行模型
|
|
269
|
-
|
|
270
|
-
```mermaid
|
|
271
|
-
graph TB
|
|
272
|
-
subgraph CONFIG[flow2spec.config.json]
|
|
273
|
-
SA[subAgent: false/true]
|
|
274
|
-
SV[switchAgentVerification: false/true]
|
|
275
|
-
end
|
|
276
|
-
|
|
277
|
-
SA -->|true| SPLIT[拆分子 Agent\n并行处理]
|
|
278
|
-
SA -->|false| MAIN[主 Agent 顺序完成]
|
|
279
|
-
|
|
280
|
-
subgraph VERIFY[验证归属]
|
|
281
|
-
V1[默认：谁落盘谁验\n子 agent 自验 / 主 agent 自验]
|
|
282
|
-
V2[交叉：子落盘 → 主验\n主落盘 → 子验]
|
|
283
|
-
end
|
|
284
|
-
|
|
285
|
-
SV -->|false| V1
|
|
286
|
-
SV -->|true + 技能明确写出| V2
|
|
287
|
-
```
|
|
288
|
-
|
|
289
|
-
|
|
290
|
-
|
|
291
|
-
**两个维度正交 · 独立配置 · 自由组合**
|
|
292
|
-
|
|
293
|
-
> 并行度和验证方向是两件事，不捆绑。大多数场景两个都是 false，默认够用。
|
|
294
|
-
|
|
295
|
-
---
|
|
296
|
-
|
|
297
|
-
## Slide 13b · 配置怎么「进到」上下文
|
|
298
|
-
|
|
299
|
-
```
|
|
300
|
-
flow2spec.config.json （磁盘，权威）
|
|
301
|
-
│
|
|
302
|
-
├── Cursor f2s-config-check.mdc → 先 Read
|
|
303
|
-
├── Claude f2s-config-inject hook → Skill 前注入（缺文件/坏 JSON 也出声）
|
|
304
|
-
├── Codex AGENTS 顶部 Read + init 快照表
|
|
305
|
-
└── 知识库 config-precheck 主题摘要 → 链 Codex 长文，不复制第二份全文
|
|
306
|
-
|
|
307
|
-
多层提示 · 不互相替代 · 进技能正文前仍以 Read JSON 为准
|
|
308
|
-
```
|
|
309
|
-
|
|
310
|
-
> **不要**在台上把四层各背一遍。一句话：**产品不会替你自动读盘，Flow2Spec 用规则 + hook + 表 + 路由摘要叠概率；真值永远是一次 Read。** 详表与路径只维护在 [Flow2Spec使用说明 § 一](./Flow2Spec使用说明.md)，设计归纳在 [Flow2Spec-设计说明 § 四、5.1](./Flow2Spec-设计说明.md)。
|
|
311
|
-
|
|
312
|
-
---
|
|
313
|
-
|
|
314
|
-
## Slide 14 · init 的边界
|
|
315
|
-
|
|
316
|
-
```
|
|
317
|
-
flow2spec init
|
|
318
|
-
|
|
319
|
-
✅ 补齐缺失的目录和模板
|
|
320
|
-
✅ 落盘各工具 rules/skills
|
|
321
|
-
✅ manifest-routing 包级结构对齐
|
|
322
|
-
|
|
323
|
-
❌ 写业务文档内容
|
|
324
|
-
❌ 更新路由关键词
|
|
325
|
-
❌ 替代 f2s-* 技能
|
|
326
|
-
|
|
327
|
-
可以安全重跑 · 只补缺失 · 不覆盖已有知识
|
|
328
|
-
```
|
|
329
|
-
|
|
330
|
-
> init 和"写知识库"是两件事。这是最常见的误用场景——跑完 init 以为知识库就更新了。
|
|
331
|
-
|
|
332
|
-
---
|
|
333
|
-
|
|
334
|
-
## Slide 15 · 三工具共享一份知识
|
|
335
|
-
|
|
336
|
-
```
|
|
337
|
-
.Knowledge/
|
|
338
|
-
（知识只写一份）
|
|
339
|
-
↙ ↓ ↘
|
|
340
|
-
Cursor Claude Codex
|
|
341
|
-
.cursor/ .claude/ .codex/
|
|
342
|
-
rules/ rules/ AGENTS.md
|
|
343
|
-
skills/ skills/ skills/
|
|
344
|
-
|
|
345
|
-
各工具用自己原生的方式加载规则
|
|
346
|
-
知识层统一，执行层各自独立
|
|
347
|
-
```
|
|
348
|
-
|
|
349
|
-
> 团队里不同人用不同工具，或者 CI 用 Codex，本地用 Claude。以前要维护三份"背景说明"，现在只需要一份。
|
|
350
|
-
|
|
351
|
-
---
|
|
352
|
-
|
|
353
|
-
## Slide 16 · 说实话：三个局限
|
|
354
|
-
|
|
355
|
-
```
|
|
356
|
-
┌─────────────────────┬────────────────────────────┐
|
|
357
|
-
│ 前期投入高 │ init 搭结构，知识要靠技能 │
|
|
358
|
-
│ │ 建起来才有用 │
|
|
359
|
-
├─────────────────────┼────────────────────────────┤
|
|
360
|
-
│ 小项目用不上 │ 路由、分层、分片的管理成本 │
|
|
361
|
-
│ │ 超过收益 │
|
|
362
|
-
├─────────────────────┼────────────────────────────┤
|
|
363
|
-
│ 还是需要团队纪律 │ 改了代码不同步技能 │
|
|
364
|
-
│ │ 知识照样会腐化 │
|
|
365
|
-
└─────────────────────┴────────────────────────────┘
|
|
366
|
-
```
|
|
367
|
-
|
|
368
|
-
> 不说这三点是不诚实的。Flow2Spec 不是银弹，它用结构投入换长期质量。
|
|
369
|
-
|
|
370
|
-
---
|
|
371
|
-
|
|
372
|
-
## Slide 17 · 适合谁
|
|
373
|
-
|
|
374
|
-
```
|
|
375
|
-
项目规模
|
|
376
|
-
小 ←────────→ 大
|
|
377
|
-
短 │ 不需要 │ 可以用 │
|
|
378
|
-
│ │ │
|
|
379
|
-
长 │ 可以用 │ 强推荐 │
|
|
380
|
-
```
|
|
381
|
-
|
|
382
|
-
**同时满足：有规模 · 长期迭代 · 多工具或多人 AI 协作**
|
|
383
|
-
|
|
384
|
-
> 一次性项目、单人小项目，直接把几个 Markdown 丢给 AI 更快。Flow2Spec 的价值在于长期复利。
|
|
385
|
-
|
|
386
|
-
---
|
|
387
|
-
|
|
388
|
-
## Slide 18 · 结尾
|
|
389
|
-
|
|
390
|
-
```
|
|
391
|
-
Flow2Spec
|
|
392
|
-
|
|
393
|
-
不是让 AI 更聪明
|
|
394
|
-
|
|
395
|
-
是让 AI 一直知道你在做什么
|
|
396
|
-
```
|
|
397
|
-
|
|
398
|
-
---
|
|
399
|
-
|
|
400
|
-
## 备注：建议制作工具
|
|
401
|
-
|
|
402
|
-
|
|
403
|
-
| 工具 | 适合 |
|
|
404
|
-
| -------------- | ---------------------------- |
|
|
405
|
-
| Marp | 直接用 Markdown 渲染，Mermaid 原生支持 |
|
|
406
|
-
| Slidev | Vue 驱动，代码块和图表效果最好 |
|
|
407
|
-
| Notion / Gamma | 快速出图，AI 辅助美化 |
|
|
408
|
-
| Keynote / PPT | 手动排版，最终呈现质量最高 |
|
|
409
|
-
|
|
410
|
-
|
|
411
|
-
Mermaid 图可直接复制进 Marp / Slidev 渲染，无需重画。
|