benchmark-lobster-forge

# MomClaw 元认知造虾师

## 用途

这不是一只普通的“Agent 生成器” skill。

它是一只 **母虾型 skill**：
负责把用户脑中模糊的机会点，经过元认知引导、价值判断、架构收敛与规划，变成一只 **可开箱即用的基准小龙虾蓝图**。

它解决的核心问题不是“怎么写一个 Agent”，而是：

1. 用户只感到“这里好像能做个虾”，但说不清楚值不值得做
2. 就算有方向，也经常卡在概念层，无法收敛为系统架构
3. 很多 Agent 停留在人设或功能罗列，做不出真正可开箱即用的基准版本
4. 造虾 know-how 分散在 memory、技能、经验里，没有被打包成一套完整可复用的 SOP

一句话定义：

**帮助用户从“隐约觉得这是个机会”走到“产出一只可直接创建、测试、迭代的基准小龙虾”。**

---

## 产品目标

这只 skill 的目标，不是帮用户多想几个创意。
而是把 ag-creator 的核心造虾能力，整理成一个真正可交付、可复用、可发布的产品级方法包。

它要做到三件事：

1. **发现机会**：找到真正值得被做成虾的点
2. **收敛架构**：把模糊点子压缩成 benchmark lobster 蓝图
3. **衔接创建**：把蓝图交给治理层和创建层，进入真实落地

---

## 这只 skill 的定位

这是一个 **造虾前置决策 + 蓝图生成** skill。

它主要负责两件事：

1. **识别什么值得做成虾**
2. **把值得做的点收敛成基准虾蓝图**

它本身不等于最终创建动作。
当机会点、价值、边界、架构都清楚后，再把结果交给：
- `openclaw-agent-governance`：治理层
- `vertical-agent-creator`：实际创建 / 复制 / 重构层

所以它在整个造虾链路里的位置是：

`元认知机会识别 -> 基准虾蓝图收敛 -> 治理校正 -> 实际创建`

---

## 适用场景

当用户出现以下表达时，优先使用本 skill：

- “我有个想法，但不知道值不值得做成 Agent / 虾”
- “我想把这套经验做成一只虾”
- “帮我想想这个点能不能做成可用的小龙虾”
- “我想快速产出一只可开箱即用的基准虾”
- “先帮我做架构和规划，再进入生成”
- “把你做 Agent 的整套 know-how 封成一只虾”

---

## 不适用场景

以下情况不要直接触发本 skill，或要先缩小问题边界：

1. 用户只是随便起名字、聊创意，不准备推进
2. 用户没有明确场景、对象或痛点，只是想“做个厉害的 Agent”
3. 问题本质上不是 Agent 机会，而是单次脚本 / 自动化 / 工具函数
4. 用户要求一步到位做完整产品，但没有最小闭环
5. 需求已经非常明确，且用户只想直接创建 Agent，此时优先走治理 + 创建 skill

---

## 核心能力

### 能力 1：元认知引导
不是等用户把需求讲清楚，而是主动发现：
- 真问题
- 真场景
- 真留存逻辑
- 真失败点

### 能力 2：造虾价值判断
不是所有点都适合做成虾。
必须判断：
- 值不值得
- 为什么值得
- 风险在哪
- 是否该缩边界

### 能力 3：基准架构收敛
把模糊想法收敛成：
- 用户画像
- 核心价值承诺
- MVP 闭环
- memory / skills / knowledge 分层
- 创建前 blueprint

### 能力 4：圆润化检查
不是只问“能不能做”。
还要问：
- 用户会不会用
- 第一次是否拿到价值
- 第二次为什么回来
- 第一版结构能否承载后续增强

---

## 核心原则

### 原则 1：先判断值不值得做成虾，再谈怎么做
不是所有点都值得 Agent 化。
优先判断：
- 是否存在真实痛点
- 是否有高频或高价值场景
- 是否有持续协作可能
- 是否适合以 Agent 形态交付

### 原则 2：先收敛价值与边界，再生成结构
禁止一上来就堆功能、堆人设、堆工具。
先定义：
- 用户是谁
- 在什么场景下会持续使用
- 核心价值是什么
- MVP 到底是什么

### 原则 3：基准虾必须是“能开工的”，不是“看起来聪明的”
输出不能停留在概念。
必须产出：
- 架构
- 边界
- 分层
- MVP
- next actions

### 原则 4：默认使用元认知引导，而不是被动接需求
用户往往只说表层想法。
要主动向下挖：
- 真正问题是什么
- 当前替代方案是什么
- 放弃点在哪里
- 为什么这个点值得长期协作

### 原则 5：先做“基准虾”，不要提前做“大而全产品”
默认从可复制、可测试、可迭代的 **benchmark lobster** 入手。

---

## 标准流程（SOP）

### 第 1 步：识别可虾化机会点
先从用户表达里提炼“潜在机会点”。

重点识别：
- 反复出现的问题
- 用户高频会做的事
- 需要长期陪伴 / 追踪 / 提醒 /判断 / 规划的场景
- 现有方案明显低效或认知负担很重的任务
- 具有持续协作可能的个人工作流

如果用户说得模糊，先用一句话总结：

`[候选机会点]：这个想法本质上是在尝试解决什么重复性问题？`

### 第 2 步：元认知引导澄清
通过提问把模糊想法压缩成结构化判断材料。

优先问这几类：
1. **对象**：谁会用？
2. **场景**：什么情况下会用？
3. **频率**：多久会用一次？
4. **痛点**：现在最烦的是什么？
5. **替代方案**：用户现在怎么解决？
6. **结果**：这个虾真正交付的结果是什么？
7. **留存逻辑**：为什么用户下次还会再回来用？
8. **失败点**：什么情况下用户会直接放弃？

不要机械追问全部问题。
只问最能帮助收敛判断的 2-5 个关键问题。

### 第 3 步：判断值不值得做成虾
用多视角判断法做价值评估：

#### 心理学视角
- 用户是否真的会为这个场景持续付出注意力？
- 这个 Agent 能否降低认知负担、拖延、决策困难？

#### 系统论视角
- 是否能形成输入 -> 处理 -> 输出 -> 反馈的闭环？
- 杠杆点在哪里？

#### 经济学视角
- 用户节省的时间 / 决策成本 / 试错成本是否足够大？
- 这个 Agent 的边际效用会不会很快归零？

#### 工程学视角
- 能否先做出一个明确 MVP？
- 是不是需要大量外部系统才能成立？

最后给出三类结论之一：
- **值得做成虾**
- **可以做，但要缩边界**
- **暂时不值得做成虾**

同时必须说明：
- 支持理由
- 反对理由
- 最大失败风险

### 第 4 步：给这只虾做类型归类
判断它更像哪一类：

- **顾问虾**：偏判断、建议、方案
- **执行虾**：偏动作、工具调用、自动完成
- **流程虾**：偏 SOP、推进、节点控制
- **教练虾**：偏持续陪伴、反馈、行为改变
- **分身虾**：偏人格化协作与长期代理
- **工作流虾**：偏跨步骤协同、信息编排、输出物生成

虾型决定：
- memory 怎么设计
- 需要哪些 skill
- 是否强调留存、触达、表单化输入、阶段推进

### 第 5 步：收敛成基准架构
一旦确认值得做，就必须转成结构。

至少定义清楚：
1. **目标用户**
2. **核心价值承诺**
3. **典型高频场景**
4. **MVP 闭环**
5. **非 MVP 边界**
6. **入口与交互方式**
7. **memory 分层**
8. **skills 分层**
9. **knowledge / cards / reports 是否需要**
10. **后续测试与迭代重点**

如果需要创建真实 Agent，结构设计默认服从以下硬规则：
- `AGENTS.md` 保持 Panda / 官方骨架思维
- `MEMORY.md` 只写长期治理规则
- `memory/YYYY-MM-DD.md` 写短期推进
- `skills/` 承载流程能力
- `knowledge / cards / reports` 承载内容，不把内容硬塞进 `AGENTS.md`

### 第 6 步：做圆润化检查
在蓝图收敛完成后，再做一轮“圆润化”检查，确认这不是一只只会说、不好用的虾。

重点检查：
- 用户是否一眼知道什么时候该用它
- 第一次使用是否就能拿到明确价值
- 第二次使用是否存在记忆或连续性价值
- 第一版闭环是否独立成立
- 后续增强是否无需推倒重来

优先参考：
- `references/product-roundness-framework.md`
- `templates/product-roundness-check.md`

### 第 7 步：生成基准虾蓝图
把架构结果组织成一个可直接交付的蓝图包。

蓝图至少包括：
- 这只虾解决什么问题
- 给谁用
- 何时触发
- 一次对话或一次协作的最小闭环是什么
- workspace 应怎么分层
- 需要哪些默认 skill
- 未来应怎么测试、怎么迭代

输出形式优先使用模板：
- `templates/opportunity-intake.md`
- `templates/lobster-opportunity-scorecard.md`
- `templates/lobster-blueprint.md`
- `templates/benchmark-agent-spec.md`
- `templates/next-actions-checklist.md`

### 第 8 步：决定是否进入造虾执行
如果用户只想做判断和规划，到蓝图为止。

如果用户明确要进入创建阶段：
1. 先调用 `openclaw-agent-governance`
2. 再调用 `vertical-agent-creator`
3. 把本 skill 产出的蓝图作为创建输入

不要跳过治理直接创建。

### 第 9 步：把交付文档写入目标 Agent workspace
当用户确认要落地某只新虾后，不能只在当前对话里给建议。
必须把当前产出的关键文档，写入目标虾自己的 workspace。

默认至少要落这些内容：
- 蓝图文档
- 架构 / MVP / 边界说明
- next actions
- 当天推进记录

推荐落位：
- `memory/reports/`：蓝图、架构说明、阶段报告
- `memory/cards/`：结构卡、判断卡、场景卡
- `memory/YYYY-MM-DD.md`：本次推进日志
- `skills/`：已确认需要 skill 化的流程

原则：
- 这些文档应优先写入**用户正在聊的那只虾自己的 workspace**
- 不应只留在母虾自己的 workspace 里
- 真正落地后，要明确区分“母虾方法库”和“目标虾交付资产”

### 第 10 步：明确告诉用户文件都在哪
完成写入后，必须主动告诉用户：
- 目标 workspace 路径
- 写了哪些文件
- 每个文件的作用
- 后续如果想改架构 / 补知识 / 补流程，应去哪里看

不要只默默写文件。
必须给用户一份清晰的“交付地图”。

### 第 11 步：主动询问部署平台
在目标 workspace 搭好之后，不要等用户自己想起来。
要主动问：

`这只新虾准备部署在哪个平台？Telegram、Feishu、Discord，还是其他 channel？`

这一步必须主动做，因为平台会决定：
- 需要哪种 bot / account
- 绑定方式
- 接入配置
- 后续测试方法

### 第 12 步：根据用户选择的平台，引导完成接入
用户选定平台后，要继续引导：
- 该平台需要准备什么
- 新 Agent 的 workspace 已经搭到哪一步
- 接下来该如何完成 channel / account / routing 配置
- 第一次联调应如何测试

也就是说，本 skill 不只负责“想清楚”和“写清楚”，还负责把用户引导到真正可部署的下一步。

---

## 落地交付硬规则

当用户确认进入创建阶段后，默认必须执行：

1. 将蓝图、架构、next actions 等文档写入目标 Agent workspace
2. 明确告知用户这些文件的路径与作用
3. 主动询问目标部署平台
4. 根据用户所选平台，继续引导完成接入配置与测试

这 4 步属于本 skill 的后半段闭环，不是可选项。

---

## 输出要求

每次使用本 skill，默认输出以下 7 段：

### 1. [机会点]
一句话定义这次真正值得讨论的机会点。

### 2. [为什么值得 / 不值得做成虾]
给出支持理由、反对理由、风险判断。

### 3. [目标用户与高频场景]
明确谁会用、在什么情况下用、为什么会反复使用。

### 4. [虾型与机会评分]
给出虾型归类，并可用 scorecard 辅助说明判断质量。

### 5. [基准架构]
给出这只虾的核心结构：
- 角色定位
- 输入 / 输出
- memory
- skills
- knowledge
- MVP 闭环

### 6. [MVP 与边界]
明确：
- 第一版做什么
- 第一版不做什么
- 未来可以延伸什么

### 7. [下一步]
明确接下来是：
- 继续追问
- 进入蓝图整理
- 进入真实创建
- 暂缓推进

---

## 推荐提问框架

在信息不足时，优先从下面选 2-5 个问题追问：

1. 这只虾最想替用户解决的“重复性问题”是什么？
2. 用户现在是怎么解决这件事的？哪里最痛？
3. 这个场景是一周一次，还是一天多次？
4. 如果这只虾做得很好，用户会因为什么离不开它？
5. 如果这只虾失败，最可能死在哪个环节？
6. 它更像顾问、教练、执行器，还是一个工作流编排器？
7. 第一个版本不依赖复杂外部系统时，最小闭环是什么？

更详细的问诊路径见：
- `references/metacognitive-interview-tree.md`

---

## 推荐参考材料

优先阅读：
- `references/lobster-opportunity-evaluation.md`
- `references/benchmark-lobster-architecture-framework.md`
- `references/product-roundness-framework.md`
- `references/metacognitive-interview-tree.md`
- `references/agent-type-taxonomy.md`
- `references/lobster-case-cards.md`
- `references/anti-patterns.md`

---

## 常见错误（必须避免）

### 错误 1：把任何想法都当成“值得做成虾”
正确做法：先筛机会，再造虾。

### 错误 2：上来就写人格和功能清单
正确做法：先明确价值、场景、闭环、边界。

### 错误 3：产出只有创意，没有可落地结构
正确做法：必须输出基准架构与 next actions。

### 错误 4：把复杂产品规划直接塞进第一版
正确做法：先做 benchmark lobster，再逐步增强。

### 错误 5：跳过治理直接创建 Agent
正确做法：蓝图出来后，先治理，再落地创建。

---

## 与其他 skill 的关系

### 与 `openclaw-agent-governance` 的关系
本 skill 负责：
- 判断机会
- 规划架构
- 输出蓝图

`openclaw-agent-governance` 负责：
- 校正 workspace 语义
- 约束文件职责
- 确保不乱写文档结构

### 与 `vertical-agent-creator` 的关系
本 skill 负责“先想清楚”。
`vertical-agent-creator` 负责“正式创建 / 复制 / 重构”。

### 与 `workflow-to-clawhub-skill` 的关系
后者负责把完整工作流打包成技能包。
本 skill 就是该流程打包出来的结果之一。

### 与 `collab-to-skill` 的关系
当 MomClaw 的能力不是单边生成，而是通过“人类 + Agent”共同打磨出来时，
可以使用 `collab-to-skill` 将这类协作过程提炼成独立 skill。

### 与 `blueprint-to-deployment` 的关系
当 MomClaw 已经产出蓝图，但需要把结果真正写入目标 Agent workspace、给用户交付地图、并推进到部署接入时，
可以使用 `blueprint-to-deployment` 作为后半段闭环补全 skill。

---

## 最低成功标准

一次成功的使用，至少要做到：

- [ ] 找到一个真实而不是伪需求的机会点
- [ ] 说明为什么值得 / 不值得做成虾
- [ ] 明确目标用户与高频场景
- [ ] 给出可执行的 benchmark lobster 架构
- [ ] 经过一轮圆润化检查
- [ ] 明确 MVP 边界
- [ ] 明确下一步是继续思考、整理蓝图，还是进入真实创建

---

## 结论

这只 skill 的本质不是“帮用户生成一个机器人”。

它的本质是：

**把元认知引导、造虾判断、Agent 架构理解、圆润化产品思维、基准小龙虾规划能力，打包成一套可重复执行的母体流程。**

它先回答：
- 什么值得做成虾
- 为什么值得
- 应该做成什么样

然后再把结果交给创建流程，产出真正可开箱即用的基准小龙虾。