把一本行为科学方法变成 Agent Skill：Fogg B=MAP 如何从知识变成可测试的工作流

AH-0306 是一条很适合 alphahole 的素材。

因为它不只是：

“我读了一本书，有几个感悟。”

作者真的把 Fogg Behavior Model 做成了一个 Skill， 而且把源码放进 GitHub。

这给了我们一个很好的研究样本：

> 一本方法论，怎样被转成 Agent 能执行的 Skill，而不是变成一段长提示词。

一、先核 Fogg 模型本身

BJ Fogg 官方 Behavior Model 当前仍然明确写：

> B = MAP

Behavior 发生，需要：

Motivation Ability Prompt

在同一时刻汇合。

如果行为没发生， 至少一个元素缺失。

这一点源文没有讲错。

二、源文第二个关键点也能闭环：优先让行为更容易

Fogg 官方 Ability 页面强调：

提升 Ability 可以通过： 训练、 提供工具， 或把目标行为缩小、变简单。

Tiny Habits 更强调：

让行为简单。

所以源作者发现：

“我的复盘模板太大、太复杂”

然后把它缩成：

只说/写一句今天最值得记录的事，

这与原方法方向一致。

这比“提高意志力”更符合 Fogg 的设计思路。

三、Prompt 不是“手机提醒”这么简单

Fogg 官方还强调：

没有 Prompt，目标行为不会发生。

Prompt 可以是外部提醒， 也可以来自已有日常行为。

源文把：

用完牙线

作为复盘锚点。

这是 Tiny Habits 中非常典型的：

Anchor → Tiny Behavior

思路。

所以这一段也可以保留。

四、Celebration 也不是作者自己加的鸡汤

Tiny Habits 官方材料确实强调：

在新微行为之后立即庆祝， 制造积极情绪， 帮助习惯变得更自动。

所以：

做完马上产生“我做到了”的正反馈，

是方法的一部分。

但是要注意：

“庆祝就一定让习惯扎根”

仍然不应该写成所有人的确定性生理机制。

我们保留：

方法建议。

不升级成万能结果保证。

五、真正值得研究的是 Skill 如何保持 Method Fidelity

源作者 GitHub 当前：

lovekeji-ai/keji-skills

是真实公开仓库。

当前未归档。

README 明确列出：

fogg-habit

并标 MIT License。

仓库在原帖之后仍有 2026 年 7 月后续提交， 所以不是发帖后立即 abandoned 的一次性 Demo。

Skill 本身也真实存在。

这满足 B29 的 Repo Lifecycle Gate。

六、Skill 里有哪些值得学的设计

当前 fogg-habit/SKILL.md 把任务分成：

• 诊断坚持不下来；
• 设计新习惯；
• 戒坏习惯；
• 庆祝设计；
• 帮别人改变。

这比“一段万能 Fogg Prompt”好很多。

因为它首先做：

> Mode Selection

不同问题走不同 reference。

这就是 Skill Contract 的：

Trigger / Anti-trigger / Workflow 分层。

七、它还有一个很好的交互原则：一次只问一两个问题

很多方法型 Agent 最大的问题是：

一上来就问 12 个问题。

用户累了， Skill 也失败了。

这个 Skill 明确要求：

一次走一个模式； 一次问一两个问题； 等用户回答后继续。

这把“方法正确”转成了：

> Interaction Cost

这是很重要的产品字段。

方法论不能只看理论忠实度。

还要看用户能不能真的走完。

八、但 Skill 里也存在需要进一步标注的“解释性扩展”

例如：

“情绪创造习惯，不是重复次数”

是 Tiny Habits 的核心表达方向， 但在产品中最好继续标：

Canonical Principle / Skill Interpretation。

另外：

“把行为砍到30秒内”

更像具体操作 heuristics， 不是 B=MAP 本身的公式定义。

所以 Batch 31 新增：

> Method-to-Skill Fidelity Gate

Canonical Source → Concept Map → Workflow → Prompt Rules → Heuristics → Anti-trigger → Failure → Examples → Evaluation。

这样不会把 Skill 作者的实现细节， 静默变成“Fogg 原话”。

九、“我坚持了两周”不是方法验证

源文说：

作者从 6 月 22 日坚持到发文； 还建立了几个小习惯。

这是真实的：

作者自述体验。

但不是：

Fogg Skill 对所有用户有效的验证。

所以产品 V3 不能只展示：

streak。

必须测：

Time to Action

从想做，到第一次执行多久？

Friction

任务是否变容易？

Restart Rate

断掉以后能否更快回来？

Drop-off

在哪一步放弃？

Self-blame

是否减少“我意志力差”的归因？

Adherence

短期执行是否提升？

新增：

> Habit Skill Outcome Gate

十、Streak 不是唯一成功指标

如果一个用户：

连续 30 天后断掉， 然后再也不做。

另一个用户：

一个月做 18 次， 断了两天也能恢复。

哪一个更成功？

单纯连续天数可能误导。

对于习惯 Skill，更应该看：

> Resilience

断裂后的恢复能力。

这也符合源文：

状态不好时只做一句， 状态好时再详细记录。

十一、Behavior Design 不应该侵入临床问题

这是 Skill 产品化必须补的一层。

B=MAP 可以帮：

复盘； 读书； 运动； 整理； 任务管理； 写作。

但如果用户说：

严重抑郁； 进食障碍； 自伤； 物质依赖； 强迫； 临床失眠；

不能继续把问题解释成：

“把行为缩小一点就好”。

因此新增：

> Behavior Intervention Scope Gate

高风险问题转向专业支持， Skill 只承担辅助行为设计。

十二、真正优秀的 Method Skill 应该做什么

它不是：

复述书。

而是：

Diagnose

找到卡点。

Reduce

缩小行为。

Anchor

接到已有行为。

Act

让用户现在就能做。

Reflect

看哪里卡。

Adapt

调整设计。

它必须把“概念”变成“动作”。

十三、Method Skill 还需要回归测试

如果未来作者更新 Skill：

怎么知道没有把 Fogg 方法改坏？

需要一组 Evals。

例如：

Happy Path

想建立每天读书。

Ability Failure

目标太大。

Prompt Failure

没有稳定触发。

Motivation Fluctuation

今天没劲。

Overcomplexity

用户设计 12 步。

High-risk

用户描述临床问题。

Restart

中断一周后回来。

每个场景看：

Skill 是否正确识别问题， 有没有一次问太多， 有没有过度承诺。

这就是：

> Method Skill Regression

十四、这条对 alphahole 最重要的产品启示

很多知识库现在只做：

“把书放进去，可以问。”

真正更高价值的是：

> 把方法变成可执行 Skill。

知识库回答：

“Fogg 模型是什么？”

Skill 回答：

“你现在这个习惯为什么失败？下一步只改什么？”

这是：

Knowledge → Capability

的升级。

十五、产品化

进入：

Personal Agent OS

新增：

> Behavior Skill Compiler

它不只服务 Fogg。

可以用于：

GTD； 写作方法； 研究方法； 复盘框架； 销售框架； 会议框架。

输入一本清晰方法。

输出：

Canonical Map / Modes / Questions / Workflow / Anti-trigger / Safety Scope / Evals / Version。

十六、V3

选 3 种方法：

Fogg + 一个研究方法 + 一个工作方法。

每种找 10 个真实任务。

比较：

A. 直接把原文丢给模型。

B. Method-to-Skill Contract。

测：

completion； questions asked； method drift； user friction； error； restart； decision quality。

如果 Skill 只是把原文包装成更多步骤，没有实际改善，就不要产品化。

最后

AH-0306 最值得学的不是：

> “一个 AI 习惯教练。”

而是：

> 怎样把一个清晰的方法论，拆成 Agent 可重复执行、可限制边界、可测试失败的能力。

知识被保存，

只是知识库。

知识能被可靠执行，

才开始变成 Skill。

十七、再补一层：Skill 的“成功”不能只由 Skill 自己判断

方法型 Skill 很容易出现一种自证循环：

它先问用户问题； 再按自己的框架给方案； 最后又问“这个方案是否更清楚”。

用户说“清楚”，就被当成方法有效。

这不够。

真正的 V3 还需要区分三层结果：

Conversation Success

用户是否愿意把对话走完？

Behavioral Success

用户是否真的采取了那个微行为？

Method Fidelity

Agent 给出的建议是否仍然忠于原方法，而不是越聊越变成普通鸡汤？

这三层必须分开。

因此 Behavior Skill 的每次测试最好保留：

Input Scenario / Mode Selected / Canonical Principle Used / Skill Heuristic Used / User Action / Follow-up Result / Reviewer Fidelity Score。

这样才能知道，产品变“顺滑”以后，有没有同时把方法改坏。

十八、Method Skill 还需要一个“最小必要方法”原则

不是一本书里的所有概念都要塞进第一次对话。

用户问“为什么复盘坚持不下来”，可能只需要：

Prompt 是否稳定？ 行为是否太大？

如果 Agent 立刻讲完整行为模型、焦点地图、庆祝理论、坏习惯设计，理论虽然正确，交互却失败了。

所以新增：

> Minimum Necessary Method

每一轮只调用解决当前卡点所需的最少概念。

这会同时降低：

认知负担； 模型跑偏； 解释长度； 用户中途退出。

真正好的 Skill 不是最完整地复述一本书，而是在正确时机调用正确的一小部分。