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 架构理解、圆润化产品思维、基准小龙虾规划能力，打包成一套可重复执行的母体流程。

它先回答：

• 什么值得做成虾
• 为什么值得
• 应该做成什么样

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