seedpeak

Seedpeak — 种子驱动工作流

触发条件

当用户输入匹配以下模式时激活：

• 种子：<模糊灵感> / seed: <idea>
• 用户表达一个模糊想法并希望结构化推进

不要因为用户描述不完整就等待——从种子开始，一步步引导。

---

流程概览

核心路径（大多数任务走这里）:
1. 明确目标 → 2. 制定方案 → 3. 补充上下文 → 4. 执行 → 5. 交付与迭代

快车道（目标已经足够清晰时）:
1. 明确目标(快速) → 2. 制定方案 → 3. 补充上下文(按需) → 4. 执行 → 5. 交付与迭代

🚧 门禁规则：每步之间必须等待用户显式确认

你询问"这个方案可以吗？"之后：

• ❌ "改一下"——这是讨论，不是确认。停在当前步骤修改。
• ✅ "可以""通过""没问题""就这样""go ahead"——这是确认，进入下一步。
• ✅ "下一步""继续"——这也是确认。

为什么这样设计： 在流程中，用户的讨论和建议是正常且必要的，但讨论本身不构成对方案的最终认可。如果在不确定的时候自动前进，可能会导致方向偏差和返工。只有明确的同意信号才代表真正对齐。

---

第 1 步：明确目标

从一个模糊的灵感逐步收敛为一个清晰、可执行的目标。

常规流程

1. 收到种子后先确认理解："收到，种子是「...」。我来帮你梳理成可执行的目标。"
2. 根据种子内容生成维度清单。典型维度包括：

维度	核心问题
领域/范围	在什么领域？边界在哪里？
具体目标	想达成什么成果？
可用时间	有多少时间？截止日期？
资源/约束	有什么资源或限制？

3. 逐个询问赋值，一次只问 1-2 个。
4. 收集完毕后汇总为目标描述。

## 最终目标

**一句话概括:** ...

**具体规格:**
- 领域/范围：...
- 成果：...
- 时间：...
- 约束：...

⚡ 快车道

如果种子已经很清晰（如"种子：把这个 Python 脚本改成 Go 语言实现"），可以直接跳到第 2 步。判断标准：

• 目标明确，没有歧义
• 涉及的领域和范围不模糊
• 不需要进一步缩小边界

此时只需一句话总结确认即可。

🚧 门禁

必须等待用户显式确认目标后才能进入下一步。修改后重新呈现，继续等待确认。

---

第 2 步：制定方案

将目标拆解为可执行的计划。

1. 任务拆分 — 主任务拆为子任务，标注依赖关系
2. 执行次序 — 按优先级排序，颗粒度建议每个任务 1-2 小时内可完成
3. 技术方案 — 使用的工具、技术、方法
4. 风险预判 — 主动暴露可能的坑

## 执行方案

### 子任务（按执行顺序）
1. [任务 A] — 前置：无
2. [任务 B] — 前置：任务 A
...

### 工具与技术
- 工具名称：用途说明

### 可行性与风险
- 风险点 → 应对措施

### 交付物与验收标准
- 交付物：[具体产出]
- 验收标准：[衡量成功的标准]

🚧 门禁： 必须等待用户显式确认方案才能进入下一步。用户说"改一下"时针对性修改后重新提交；只有用户明确同意后继续。

---

第 3 步：补充上下文（按需）

补齐执行所需的信息。只在有不确定的地方才问，不要重复询问已经在前面步骤提供过的信息。

典型维度：

类别	什么时候问	示例
角色设定	不同身份产出风格差异大	"资深产品经理视角"
输出要求	格式、长度、风格影响质量	"JSON，500 字以内"
参考资料	需要参照已有材料	"参考附件中的销售数据"
禁忌边界	有硬性限制条件	"不要出现品牌名称"

---

第 4 步：执行

按方案执行每个子任务。

关键规则：

• 执行前回顾方案和上下文，确保遗漏
• 如果子任务复杂，递归应用此流程（即对该子任务独立走步骤 1-5）
• 执行过程中主动反馈进度：✅ 完成、⏳ 进行中、❌ 遇到问题
• 遇到困难时暂停并询问用户意见

---

第 5 步：交付与迭代

包含原来的整合、反馈、迭代三个步骤，合并为一个连续的闭环。

交付

• 检查各部分衔接是否一致，消除重复、填补缺口
• 确保结构和格式符合第 3 步的输出要求
• 自检：
  • 是否满足第 1 步的所有目标？
  • 是否符合第 3 步的输出要求？
  • 是否有明显缺陷或遗漏？

然后呈现完整产物给用户并邀请反馈：

"请检查这份产出。有什么需要修改或补充的地方吗？"

迭代

根据反馈持续改进：

• 修复用户指出的缺陷
• 根据补充内容更新产出
• 如有必要回到第 1 步（明确迭代目标），重新开始

形成闭环：目标 → 执行 → 反馈 → 再目标。

---

示例对话

用户: 种子：我想学 Rust

AI: 收到，种子是「我想学 Rust」。我来帮你梳理成一个可执行的学习计划。

以下是几个维度，我逐一问：

1. 你的编程基础如何？用过哪些语言？
2. 你想用 Rust 做什么？Web 开发、系统编程、还是通用学习？
3. 预期多长时间投入？

--- （用户回答：有经验但没写过 Rust，想做 CLI 工具，大概一个月）

好的，综合下来我们的目标是：

## 最终目标
制定一份为期一个月、针对有编程基础的开发者学习 Rust 并能够编写 CLI 工具的计划。

你觉得这个目标准确吗？

--- （用户确认）

## 执行方案

### 子任务
1. 第一周：Rust 语法基础（所有权、借用、生命周期）
2. 第二周：类型系统与错误处理
3. 第三周：常用生态工具链（clap、tokio、serde）
4. 第四周：实战——开发一个文件搜索 CLI 工具

### 交付物
- 每日学习路线 + 练习代码
- 一个完整的 CLI 工具项目

可以先走第一周的详细计划，每周结束时根据你的进度决定是否调整后续安排。

这个方案可以吗？

--- （用户确认）

## 执行 —— 第一周：Rust 语法基础

Day 1-2: 安装配置 + Hello World + Cargo 工作区
Day 3-4: 变量、不可变性、函数...
...

---

注意事项

常见错误	正确做法
一次性抛出所有维度让用户填	一次只问 1-2 个，逐步收集
用户给种子后直接开干	必须先走完目标→方案→上下文再执行
把用户的讨论当成确认	识别讨论≠确认，停在当前步骤
方案被拒后盲目重做	先问哪里不满意，针对性修改
忽略前面已经说过的信息	复用已有信息，不重复问
子任务复杂仍线性执行	对复杂子任务递归应用此流程