loop-me 融入 my-taste 设计方案
调研日期：2026-08-11 ｜ 状态：已批准（方案 B：完整落地 Workflow 发现器，2026-08-11 用户确认）｜ 设计变更已写入 REQUIREMENTS.md 与 content-part2.md
来源：用户分享微信文章《Matt Pocock 发了新 loop-me Skill》+ 3 路并行社区调研
一、结论先行（TL;DR）
不安装 loop-me 原版，借鉴其 3 个设计模式，作为 Steward 阶段二的一个子能力「Workflow 发现器」落地。
loop-me 的价值不在工具本身（in-progress、未完成、无格式锚点），而在三个可借鉴的设计模式：
| 设计模式 | 核心思想 | 融入点 |
|---|---|---|
| Loop 透镜 | 把工作看成 loop 套 loop，可预测 = 值得委托 | Steward 新增「Workflow 发现器」：主动发现用户可自动化的重复模式 |
| Push Right + Brief | 把人的介入点推到最晚，给人一份决策就绪的简报 | 强化渐进式授权机制：补「简报」呈现标准 |
| grilling 拷问引擎 | 一次问整个 frontier、每题附推荐答案、事实/决策分离 | 融入需求澄清方法 |
二、loop-me 是什么
- 作者：Matt Pocock（Total TypeScript 作者，GitHub 21.2 万 star 仓库）
- 状态：
skills/in-progress/loop-me（beta 桶，2026-06 创建，不随插件分发） - 机制：苏格拉底式轮次拷问（底层 grilling 引擎）→ 发现用户工作中的重复 loop → 输出
workflows/*.md规格 - 完成标准：implementer agent 照着规格构建时不需要问任何问题
- 架构本质：loop-me = grilling 引擎 + Loop 透镜 + 限定输出（workflow spec）
- 关键设计：设计树（把主题映射成决策树）→ frontier（当前可问的问题集合）→ 轮次制（一轮问整个 frontier，每题附推荐答案）；事实查询与决策提问分离（能自己查的事实派 sub-agent 查，绝不问用户）
三、安全评估（用户核心关切）
基于本地克隆完整 SKILL.md + 全仓库审计：
危险操作：几乎为零
- ✅ 只写
workflows/*.md+NOTES.md两个文件 - ✅ 不执行 git 操作、不发网络请求、不跑 shell 脚本
- ✅ 不实际运行任何 workflow（只产出规格，运行是另一个环节）
未完成风险（真实存在）
| # | 风险 | 说明 |
|---|---|---|
| 1 | 规格格式无锚点 | 无模板、无示例、无校验工具——「implementer 无问题构建」没有可验证手段 |
| 2 | run 级语义缺口（GitHub issue #657） | 缺 Success signal 和 Failure policy，可能产生无界重试或虚假成功 |
| 3 | in-progress 契约 | 可随时变更或消失，git pull 后行为可能漂移 |
| 4 | 弱模型塌缩 | 低配模型把拷问退化成两三个问题+大纲，直接开建（"自信的废话"规格） |
结论：低危险、中质量风险、明确未完成 → 不建议直接安装使用，建议借鉴方法论。
四、社区调研发现
4.1 同类工具（工作流发现 / 自动化规格化）
| 工具 | 机制 | 与我们的关联 |
|---|---|---|
| GitHub Spec Kit | 规格→计划→任务→实施（无发现环节） | 代表「规格驱动」主流，缺需求发现端 |
| Codex Record & Replay | 用户演示一遍→录制→生成 skill | 发现路径的互补方案：演示替代访谈 |
| Claude Code Dynamic Workflows | 对话→可执行 JS 脚本 | 规格 = 可执行脚本的可行目标 |
| OpenClaw standing intents/orders | 事件触发 + 确定性匹配 + 永久授权 | 事件触发优于定时 + 授权白名单设计 |
| n8n / Zapier Copilot | 描述→生成自动化 | 需求明确后的生成器，非发现器 |
| 学术：LLMREI / OntoAgent | LLM 需求访谈 + 经验本体 | grilling 提问策略的学术背书 |
关键发现：没有与 loop-me 完全同款（"拷问→发现→规格"）的工具，但每个组成模式在业界都有独立验证——grilling 设计树（访谈引擎）、OpenClaw standing intents（事件触发）、Record & Replay（演示替代访谈）、Spec Kit/BMAD（规格驱动实现）。
4.2 授权设计（Push Right + Brief 的业界对照）
- Claude Code 权限光谱：manual → acceptEdits → plan → auto → bypass，本质是「用什么机制代替问」而不是「要不要问」
- 关键数据（Claude 官方博客，auto mode 默认化论证）：
- 人类对权限提示批准率 97%（橡皮图章）
- 人类只拦下 13.6% 危险命令，auto 分类器拦 89%
- 手动批准严重意外伤害率 6.3% vs auto 2.4%
- 计划级审查 vs 逐条提示：计划审批拒绝率 39%，逐条权限拒绝率仅 3%——介入点上移到计划层，审查质量显著更高
- OpenAI 企业指南：工具安全分级（只读/可逆/账户权限/财务影响）+ 人工干预双触发器（超失败阈值/高风险动作）
- LangGraph interrupt：动态可条件中断 + 幂等副作用 + JSON 序列化简报
- Pocock 本人 HITL 定义：人在环 vs AFK 的判断准则 = "走错路的代价有多高？你多晚才会发现？"
4.3 大牛观点
- Karpathy：Claws = agent 之上的编排/调度/持久化层；config via skills 而非 config files
- Simon Willison：个人自动化正从「配置型」走向「把电脑交给 agent 型」，工作流发现成为瓶颈
- 共同指向：发现 + 规格化用户循环 = Claw/管家层应有的核心能力
五、project-blueprint 分析（第一性原理 + 剃刀 + 对抗性验证）
5.1 第一性原理：缺口在哪？
my-taste 五阶段设计当前的闭环： `` 阶段一 TasteExtractor → 阶段二 Steward → 阶段三 EventLog → 阶段四 EvolutionEngine → 阶段五 平台化 ``
核心缺口：阶段二 Steward 的「渐进式授权」（Q4 已确认）回答了"管家能做什么"，但没回答"管家怎么知道该自动化什么"。loop-me 的 Loop 透镜恰好补这个缺口——把用户工作中可预测的重复模式识别出来，作为授权/自动化的候选。
第二性原理：用户的判断力是稀缺资源（Pocock：attention is the scarce resource）。Steward 的核心价值 = 帮用户把重复工作委托出去，让用户聚焦高价值决策。而「发现哪些可以委托」本身需要方法论支撑——loop-me 是这套方法论。
5.2 剃刀原理：什么该拿、什么不该拿
该拿（3 个设计模式）：
1. Loop 透镜 → 融入 Steward：新增「Workflow 发现器」子能力
2. Push Right + Brief → 强化 Steward 的渐进式授权机制（已有雏形，补上"简报"呈现标准）
3. grilling 拷问引擎（设计树 + frontier + 轮次 + 推荐答案 + 事实/决策分离）→ 融入需求澄清环节
不该拿：
- ❌ 不安装 loop-me 原版（in-progress、无格式锚点、缺 run 级语义）
- ❌ 不引入 workflows/*.md 自由格式（我们已有 REQUIREMENTS.md / DESIGN.md / 任务卡更成熟）
- ❌ 不做「全自动规格化」承诺（模型塌缩风险，保持人在环）
5.3 对抗性验证（自问自答）
Q1：这不就是把 loop-me 抄一遍吗？ A：不是。loop-me 是通用个人工作流工具；我们把它降维成 Steward 的一个子能力，且用我们已有的更成熟载体（REQUIREMENTS / DESIGN / 任务卡）替换它的自由格式。取的是方法论，不是工具。
Q2：grilling 的「拷问到无问题可问」和我们的任务卡标准重复吗？ A：方向一致但层级不同。任务卡解决"CC 实现时无需追问"；grilling 解决"需求发现时把隐含假设挖干净"。前者是执行层标准，后者是需求层方法。互补不重复。
Q3：Push Right + Brief 会不会导致管家越权？ A：不会。关键在"简报"的呈现标准：Brief = 决策就绪摘要（做了什么/为什么/资产链接），用户读简报做最终决策。而且有 Q4 渐进式授权兜底（推荐→确认→规律化→自动化）+ Claude 官方数据支撑（介入点上移反而更安全）。
Q4：Loop 透镜的「发现」靠对话不靠数据，可靠吗？ A：这是 loop-me 的设计自觉（发现是认知过程不是检测算法），但也是它的局限。我们的补充：阶段一 TasteExtractor 已从历史数据提取品味，可作为 Loop 透镜的"预训练"——对话发现 + 数据佐证双通道。
六、推荐方案
方案 A：方法论借鉴（推荐 ⭐）
把 3 个设计模式作为设计事实补入 my-taste 的 DESIGN.md（content-part2.md），不新增独立功能：
- DF-新增1：Steward 含「Workflow 发现器」——定期用 Loop 透镜视角审视用户工作，产出「可自动化候选清单」供用户确认（融入阶段二 6.3 关键设计）
- DF-新增2：渐进式授权强化——补 Push Right + Brief 呈现标准（简报 = 决策就绪摘要，不是原始输出）
- DF-新增3：需求澄清方法——grilling 三要素（一次问整个 frontier、每题附推荐答案、事实/决策分离）写入 blueprint 阶段一
- 成本：低（只改设计文档，不动代码）
- 收益：Steward 从"被动催办"升级为"主动发现可自动化项"
方案 B：完整落地 Workflow 发现器（扩展）
方案 A + 把「Workflow 发现器」作为阶段二的独立里程碑：
- 新增子功能：定期（如每周）用 Loop 透镜审视用户一周工作 → 产出候选 workflow 规格（用我们已有的任务卡格式）→ 用户确认后进入自动执行
- 成本：中（阶段二 M2/M3 之间插入一个里程碑）
- 收益：工作站真正开始"自我发现可自动化项"
- ✅ 已选定（2026-08-11）：用户确认采用本方案
方案 C：不融入
loop-me 还在 in-progress，等它成熟（补齐 #657 的 Success signal / Failure policy + 格式锚点）再评估。
- 成本：零
- 收益：避免吸收未成熟方法论
- 风险：错过工作流发现能力的时间窗口；我们的设计已可独立演化，依赖小
🔴 最终决策（2026-08-11 用户确认）：选择方案 B——完整落地 Workflow 发现器。 方案 A 的 3 个设计模式融入 + 阶段二插入 M2.5 里程碑（Workflow 发现器）。设计变更已写入 REQUIREMENTS.md（REQ-20）与 content-part2.md（5.2 发现 loop / 6.3 关键设计⑥ + M2.5 / 7.1 行业对照 / 8.1 R9）。
七、融入点明细（已批准方案 B，以下改动已全部落地）
| 文件 | 改动 |
|---|---|
content-part2.md 6.3 阶段二关键设计 | 补 DF：Workflow 发现器 + Push Right + Brief 呈现标准 |
content-part2.md 5.2 监督循环 | 补「发现」环节：监督 loop 前置一个「发现 loop」 |
content-part2.md 7.1 行业对照 | 补行：loop-me（Loop 透镜 / Push Right / Brief） |
content-part2.md 8.1 风险 | 补 R9：模型塌缩风险（弱模型把拷问退化成大纲） |
REQUIREMENTS.md | 补 REQ-20：工作站需能主动发现用户可自动化的工作模式（源自用户 2026-08-11 分享 loop-me 文章） |
| project-blueprint skill 阶段一 | 补 grilling 三要素到需求澄清方法（需另行批准） |
八、决策点（请用户明确）
1. 方案选择：A（推荐）/ B / C
2. 若选 A：是否连同 project-blueprint 阶段一的需求澄清方法一起补（还是只改 my-taste）？
3. REQ-20 是否加入需求事实（作为 my-taste 的正式需求）？
附：调研来源
- loop-me SKILL.md 全文（本地克隆
/home/ubuntu/mattpocock-skills验证） - GitHub issues：#657（Success signal / Failure policy 缺口）、#44（200 问题无上限）
- HN 社区评价（grilling 被多位用户推荐："Code quality is better and it uses less tokens"）
- Anthropic/Claude 官方文档（权限模式、auto mode 默认化数据）
- OpenAI 企业指南（工具安全分级、人工干预触发器）
- LangGraph interrupts 文档
- Codex Record & Replay 文档（learn.chatgpt.com）
- OpenClaw 文档（standing intents / standing orders）
- Karpathy Claws / Simon Willison 观点