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 步：给这只虾做类型归类

判断它更像哪一类：