从模糊想法到可执行 One-Pager：agent-skills 中 idea-refine 技能的三阶段头脑风暴示范会话解析

skills/idea-refine/examples.md 是 agent-skills 仓库中 idea-refine 技能（结构化发散/收敛式想法打磨技能）的示范会话文档，用三个覆盖不同领域（创业概念、既有代码库功能、团队流程改进）的完整对话，展示了"好的头脑风暴会话应该长什么样"。读完本文，你将理解该技能三阶段流程（Understand & Expand → Evaluate & Converge → Sharpen & Ship）在真实对话中的节奏与语气，掌握其变体生成透镜（Inversion、Constraint Removal 等）、压力测试维度与 One-Pager 产出结构，并能照此标准评估或复现 Agent 辅助的创意打磨过程。

示范会话的定位：为什么 idea-refine 需要 examples.md

idea-refine 技能将原始想法打磨成"值得动手构建"的清晰概念，其完整定义见 SKILL.md。技能的三阶段流程为：

1. Understand & Expand（发散）：重述想法、提出打磨问题、生成变体；
2. Evaluate & Converge（收敛）：聚类想法、压力测试、暴露隐藏假设；
3. Sharpen & Ship（交付）：产出一份能推进工作的 Markdown One-Pager。

该技能本质上是一段交互式对话：用某个想法调用它，Agent 会引导你走完整个流程。触发词包括 "Help me refine this idea"、"Ideate on [concept]"、"Stress-test my plan"。可选地，可先运行初始化脚本建立想法目录：

# Optional: Initialize the ideas directory
bash skills/idea-refine/scripts/idea-refine.sh

这个 初始化脚本 的逻辑非常简单：若 docs/ideas/ 目录不存在则创建，并输出 {"status": "ready", "directory": "docs/ideas"}——后续的 One-Pager 最终就保存到 docs/ideas/[idea-name].md（且需用户确认后才落盘）。

examples.md 文档开头明确了自己的用法意图：学习这些会话的节奏（rhythm）、语气（tone）和结构（structure）——而不只是内容。该技能应该既能自如应对模糊的创业概念，也能应对既有产品的功能改进，或团队流程改进。这也是 Agent 技能写作中"示例驱动"的典型做法：用高质量对话样本约束 Agent 的输出风格，比纯规则描述更能稳定行为。

技能文档还要求 Agent 在对话中按需读取同目录下的两份参考资料：

• frameworks.md：发散阶段可用的头脑风暴框架库（SCAMPER、How Might We、First Principles、JTBD、Constraint-Based、Pre-mortem、Analogous Inspiration），要求"选择性使用——挑选契合想法的透镜，不要机械地跑完所有框架"；
• refinement-criteria.md：收敛阶段（Phase 2）使用的完整评估量表，包含用户价值（止痛药 vs 维生素）、可行性、差异化三个核心维度，以及三级假设审计（Must Be True / Should Be True / Might Be True）和价值-可行性决策矩阵。

仓库中的评测用例 evals/cases/idea-refine.json 也印证了这套流程的验收标准：给定模糊想法（如 "some kind of tool that helps teams share knowledge better"），期望输出包含"收敛前先提出打磨问题、显式暴露隐藏假设、包含明确的 Not Doing 列表、对薄弱点反驳而非一味附和"。这些 expectation 与 examples.md 中示范会话的行为一一对应。

以下逐一拆解文档中的三个示例。

---

示例 1：模糊的早期创业概念（完整三阶段会话）

调用方式： /ideate I want to help small local restaurants compete with the big delivery platforms

Phase 1：Understand & Expand

技能首先把原始诉求重述为一个精确的 How Might We 问题：

How might we 让独立餐厅获得顾客期待的外卖平台般的触达与便利，而不把它们推进一个侵蚀利润和品牌的模式？

然后指出"竞争"是一个很大的空间，并提出三个打磨问题：

1. "竞争"指哪一部分？ 获客？配送物流？在线点餐体验？忠诚度/留存？还是平台佣金带来的利润压力？
2. 为谁构建？ 餐厅老板？食客？还是两者？
3. 约束是什么？ 你在想软件？合作社模式？还是某种实体方案？

用户回应："面向餐厅老板。核心痛点是：他们向外卖 App 支付 25–30% 佣金，却感觉自己无法退出，因为顾客都聚集在那里。我在想软件，但不排除其他可能。"

技能随即重新定界问题：问题不在配送物流，而在顾客依赖——平台拥有客户关系，餐厅相当于用自己收入的 30% "租用"对自己顾客的触达权，这正是可以打破的杠杆点。接着生成 6 个带透镜标签的变体：

1. Direct Channel Toolkit（直接渠道工具包）：给餐厅提供自有品牌的点餐渠道（Web、SMS、轻量 App），把现有顾客从平台上迁走。核心赌注：已经认识某家餐厅的顾客，只要够方便就会直接下单——不需要和 DoorDash 抢新客发现，只需要抢复购。
2. Inversion（反转）——收顾客的钱，而非餐厅的钱：把配送费模式倒过来？顾客为直接点餐支付小额溢价，餐厅零佣金。定位为"支持本地商家"。赌注：足够多顾客在乎支持本地生意，愿意每单多付 1–2 美元。
3. Constraint Removal（去约束）——如果配送不是必需呢？ 平台把发现 + 点餐 + 配送捆绑销售，但大部分成本（和餐厅的佣金）来自配送。如果只解决点餐和自取呢？Pickup-first 模式：餐厅保留 100% 收入，顾客省下配送费，最适合高密度社区。
4. Combination（组合）——餐厅合作社：一个区域内 20–50 家本地餐厅共享平台、分摊成本、互相导流的 co-op 模式。单店付不起营销成本，但一个街区共同体可以。相当于"数字化的本地美食广场"。
5. Audience Shift（受众转换）——面向老顾客：不获取新客，只为餐厅的既有常客构建——每周都来的那些人。一个极简忠诚度/复购工具："还是老样子？"一键复购。80/20 赌注：20% 的顾客贡献 80% 的收入，这些人不需要 DoorDash 来发现这家餐厅。
6. Expert Lens（专家视角）——餐厅老板实际在做什么：多数小餐厅老板不盯仪表盘，他们在后厨。任何要求他们"管理"某事的工具都会失败。取胜之道可能是完全自动运行的东西——两周没下单自动发短信提醒常客、自动发布每日特餐、自动处理复购。餐厅侧零操作。

最后技能给出自己的判断：变体 5 和 6 组合起来很有意思——不是去"平台化"地对抗平台，而是做一个超窄的产品：为餐厅最好的老顾客服务的复购与留存工具。不碰发现、不碰配送、不碰市场，只做"让你的常客持续直接下单"。并反问用户哪些方向感兴趣。

Phase 2：Evaluate & Converge

用户回应："我更喜欢常客角度（5 和 6）。直接渠道工具包（1）必要但无聊。合作社（4）有意思但复杂。让我聚焦 1 + 5 + 6 的组合。"

技能把该组合提炼为清晰论点：拥有与你最好顾客的关系，让复购零摩擦，且餐厅老板零操作。然后对两个方向做压力测试：

方向 A："Regulars Engine"（变体 5 + 6 融合）——完全聚焦餐厅既有复购顾客的工具，自动复购、自动触达、零管理。

• 核心赌注：餐厅前 20% 的顾客，只要体验无摩擦且个性化，就会转向直接点餐。餐厅不需要新顾客——它需要停止为已有顾客支付 30% 佣金。
• 用户价值：高且立竿见影。每次直接复购为餐厅省下 25–30% 佣金。若一位常客每周下单 30 美元，每年每位顾客节省约 400 美元费用。50 位常客 = 每年 2 万美元——对小餐厅是实打实的钱。
• 可行性：中等。点餐/支付技术是商品化的，难的是：(a) 如何在不让餐厅做手工活的前提下识别并导入"常客"？(b) 冷启动问题——第一次复购所需的订单历史在配送平台上，不在你这里。
• 差异化：在细分领域内很高。平台优化的是市场动态（新客发现、司机物流），没有人专门优化"让常客直接下单"。这个市场小到 DoorDash 懒得管，恰恰因此是好的楔子。
• 隐藏假设：常客愿意再安装/使用一个点餐方式（最可能错的假设）；餐厅老板愿意分享或授权访问顾客联系方式；直接点餐不会蚕食堂食收入。
• 可能杀死它的因素：顾客就是不肯换渠道。习惯的力量很强——即便 DoorDash 更贵，它已经在手机里了。

方向 B：Direct Channel + 留存混合（变体 1 + 5）——品牌点餐 + 留存自动化，更完整但更复杂。

• 核心赌注：餐厅既需要渠道（接单方式）又需要引擎（让顾客通过该渠道回来的方式）。
• 用户价值：上限更高，但前提是两部分协同工作。点餐渠道本身是商品（Square、Toast 已经做了）；留存层单独存在则没有渠道可留存。
• 可行性：较低。你在构建两个产品并祈祷它们合起来更好。
• 差异化：中等。组合有意思，但每一块单独都有竞争对手。
• 隐藏假设：捆绑构建优于合作（例如把留存层架在 Square Online 之上）。
• 可能杀死它的因素：范围。把两件事做好，难度指数级超过做好一件事。

诚实的读法：方向 A 是更锋利的赌注，方向 B 更稳但差异化弱。A 的最大风险是"渠道切换"问题——让顾客通过新方式下单。如果突破了这一点（变体 6 的"零操作"方案可能有帮助——基于 SMS 的复购不需要装新 App），其余都会跟上。

技能还进行了一次明确反驳：你说变体 1"必要但无聊"——把"必要的东西"拉进来的直觉，正是产品失去焦点的方式。如果常客引擎可行，以后随时可以加品牌点餐渠道；但若先建渠道，你只是又一个 Square Online 竞争者。

Phase 3：Sharpen & Ship

技能产出完整 One-Pager（结构与 SKILL.md 中定义的输出模板逐节对应）：

# ReOrder: Keep Your Regulars Ordering Direct

Problem Statement：How might we 帮助独立餐厅通过直接点餐留住最好的既有顾客，消除最重要的收入上 25–30% 的平台佣金？

Recommended Direction：构建一个仅面向常客的留存引擎——不是市场，不是完整点餐平台。超聚焦于一件事：让餐厅的复购顾客直接复购变得毫不费力。关键洞察是：餐厅不需要帮忙找最好的顾客——他们知道谁每周二都来；他们需要的是把这些关系从平台上搬走。而且工具必须自己跑起来，因为老板在后厨，不在仪表盘前。SMS 优先（而非 App 优先）很可能是正确的渠道：一条写着"嘿，要你的周四老订单（Marco's）吗？"的短信加一键确认，比任何 App 安装都低摩擦。

Key Assumptions to Validate：

• [ ] 复购顾客会经由 SMS/直接链接而非惯用的外卖 App 复购——用 5 家餐厅、每家 20 位常客测试，4 周内测转化率
• [ ] 餐厅老板能识别其 top 20–30 位常客并分享联系方式——询问 10 位老板是否愿意这样做
• [ ] 佣金节省（每单 8–10 美元）足以激励老板投入初始设置——访谈 10 位老板关于平台费用的痛点

MVP Scope：面向餐厅自识别常客的 SMS 复购；老板手动添加常客（姓名 + 电话 + 常点单）——15 分钟完成设置；顾客收到包含其常点单的短信，回复确认，通过链接支付；餐厅通过短信/简易仪表盘接单；v1 无配送、仅自取；无发现、无市场、无 App。

Not Doing (and Why)：配送物流——配送昂贵复杂且不是核心问题，Pickup-first 免运营负担即可验证需求；获客/发现——那是平台的战场，与之竞争意味着和 DoorDash 的预算对赌，我们改为竞争留存；品牌餐厅 App/网站——商品化能力，Square 和 Toast 已做，又一个品牌渠道不解决行为问题；菜单管理、POS 集成——范围蔓延，"老样子"不需要动态菜单，静态订单起步；分析仪表盘——老板在后厨，做被动式报告（每周短信摘要）而非主动式（登录看图表）。

Open Questions：向餐厅顾客做 SMS 营销的法律/合规环境如何？"老样子"订单的菜单/价格变更怎么处理？能否从现有 POS 数据导入常客列表而非手工录入？定价模型是每单抽成还是月订阅？

这个 One-Pager 展示了该技能的交付标准：每一条假设都带验证方法（谁、多少样本、测什么指标），MVP 有明确边界，Not Doing 列表每一项都给出"为什么不做"的推理，Open Questions 留给构建前必须回答的问题。

---

示例 2：既有产品内的功能想法（代码库感知）

调用方式： /ideate adding real-time collaboration to our document editor

这个示例演示了技能在代码库内部运行时如何变化：SKILL.md 明确要求，若在代码库中运行，应使用 Glob、Grep、Read 扫描相关上下文——既有架构、模式、约束、先例，并"用实际存在的东西支撑变体，引用具体的文件和模式"。

Phase 1：Understand & Expand

技能把诉求重述为：

How might we 让多个人能同时在同一文档上工作，且感觉自然而不混乱？

关键差异在于先做了代码库扫描："我扫了你的代码库，看到你们用基于 block 的编辑器架构 + REST API 持久化，目前没有 WebSocket 基础设施。这是重要上下文。" 然后提出三个问题：

1. 协作模式是什么？ 同一段落同时编辑（Google Docs 式）？不同区域各干各的（Notion 式）？还是一人编辑、他人评审/评论？
2. 多少并发用户？ 2–3 人（结对编辑）？还是 10+（团队工作区）？
3. 现在是什么在驱动这件事？ 客户请求？竞争压力？内部需要？

用户回应："2–5 人，通常在不同区域。客户不断问起，我们在丢单给 Notion，因为客户默认现代编辑器都有这功能。"

技能指出竞争压力框架的含义：这可能是勾选框功能（留在候选集里的必备项）而非差异化点——这决定了你应该投入多少。并且再次引用具体代码："你们的文档模型用独立 block + 扁平排序（src/models/document.ts:45），这其实是有利的——block 级粒度意味着冲突比字符级编辑少得多。"（此文件路径为示例中的示意引用，展示"引用具体文件"这一行为模式。）

随后生成 5 个变体：

1. Block-Level Locking（最简单路径）：某人开始编辑某 block 时，该 block 对他人锁定。他人看到在线指示（"Alex is editing…"）但可自由编辑其他 block。无需冲突解决。现有 block 模型几乎零改动即可支持——加一个 locked_by 字段和一层 WebSocket presence 即可。
2. Inversion —— Async-First 协作：不追求实时协同编辑，而拥抱异步：行内建议、评论、由文档 owner 合并的拟议编辑。像 suggestion mode，但作为首要协作模型。赌注：对 2–5 人分区工作而言，异步可能优于实时。
3. Simplification —— Presence 但不协同编辑：展示谁在看文档、看哪个区域（光标、边栏头像），但不启用同时编辑，靠口头协调。听起来原始，但可能是用 10% 的工程成本拿到 80% 的价值。
4. Combination —— 协作 + 版本分支：允许创建文档"分支"、独立编辑、再合并。每人有自己的空间，编辑期间无冲突，你构建一个合并 UI。契合既有版本化系统。
5. 10x Version —— AI 中介协作：多人各自描述想在某区域实现什么，AI 综合各方输入成一份大家都迭代的草稿。没有人直接编辑同一段文字——所有人都在影响它。激进、可能为时过早，但值得命名。

最后给出倾向："基于你们的架构和竞争背景，我推向变体 1 或 3。你们要成交，意味着要上线，意味着需要能勾选框的最简版本。变体 1 给你真实协同编辑；变体 3 更便宜但可能不满足'我们需要实时'这个勾选项。"

Phase 2 会聚为"最小可行协同（1 或 3）"与"差异化协作模型（2 或 4）"的取舍——快速勾选竞争框，还是投资一个能成为卖点的东西。Phase 3 会产出推荐 block-level locking 为 MVP 的 One-Pager，其 Not Doing 列表包括：字符级 CRDT（太复杂）、离线同步（2–5 用户不需要）、AI 功能（为时过早）。

这个示例的核心教学点：在代码库中做头脑风暴时，架构既是约束也是机会——现有的 block 模型直接决定了哪些变体成本低（变体 1），竞争上下文决定了目标是"勾选框"而非"颠覆"，从而把最优解锚定在便宜且足够的方案上。

---

示例 3：流程/工作流想法（非产品）

调用方式： /ideate a better way to run our weekly team retrospectives — they've gotten stale and people dread them

这个示例演示技能对非产品类想法的适配：输出不是产品方案，而是零成本实验。

Phase 1：Understand & Expand

重述为：

How might we 让回顾会真正有用——成为团队期待的事——而不是一场人们忍受的定期会议？

三个前置问题：

1. "stale"具体指什么？ 每次都是同一格式？都是同一批人在说？行动项永远不落地？话题重复？
2. 团队规模与动态？ 5 个人都发言，还是 15 个人里 3 个主导？
3. 你心目中好的回顾会什么样？ 有过一次成功的吗？它不同在哪？

用户回应："8 个人，大概 3–4 个人真正发言。'做得好的 / 做得不好的 / 行动项'格式用了一年。行动项越堆越多，什么都没变。大家觉得这是演戏。"

技能抓住真正的信号：行动项问题才是信号。如果回顾会后什么都没变，人们理性地就投入了。会议不是 stale——它是坏在输出层。如果跟进机制有效，格式可能没问题。

6 个变体：

1. 修复输出，而非修复会议：保留回顾会格式，但彻底改变会后发生的事。每次回顾会至多一个行动项。当场指定 owner 和截止日。下次回顾会以 5 分钟已完成项演示开场。没完成，那本身就成为回顾会话题。"一项"的约束强制优先级排序。
2. Inversion —— 杀掉会议：用异步回顾替代同步回顾。每人周内书面提交反思，轮值 facilitator 综合主题并提出一项改变。"会议"变成 15 分钟站会来同意或反对。赌注：书面比群体口头反馈更诚实。
3. Audience Shift —— 为沉默者设计回顾会：为那 4–5 个不发言的人设计格式。匿名提交话题、点选投票（dot-voting）排优先级、全组讨论前先双人小组分组。嗓门大的仍参与，但结构防止他们主导。
4. Simplification —— 一个问题回顾会：每次回顾会只问一个问题，每周换。"哪件事拖慢了你？""你学到了什么团队应该知道？""如果你能改变我们工作方式的一件事，是什么？"约束强制深度而非广度。
5. Combination —— 回顾会 + 实验：把每次回顾会产出当作假设。"我们相信 [改变] 会改善 [结果]。"跑两周实验。下次回顾会：有效吗？保留、修改或杀掉。把回顾会变成内建问责的持续改进引擎。
6. Expert Lens —— 专业 facilitator 知道什么：经验丰富的 facilitator 说，回顾会头号杀手是缺乏安全感，不是格式。如果担心后果，人们不会说真正的问题所在。修复可能不是结构性的——可以从每周一次匿名"团队健康度"打分（1–5）开始。安全感足够高时，回顾会自然变好。

收尾指出有趣的张力：变体 1 和 5 修的是输出问题（什么都没变），变体 2、3、4 修的是输入问题（同样的声音、同样的话题），变体 6 说两者都是更深问题的症状。反问：你认为真正的瓶颈在哪？

Phase 2 会按以下维度评估：尝试成本（多数免费——下次会议换个开法即可）、风险（变体 2 偏离最大）、以及团队真正的问题是输出（行动项死亡）还是输入（诚实不足）。Phase 3 的 One-Pager 推荐以变体 1（一个行动项、下周演示）作为零成本实验起步，叠加变体 3 的匿名提交；Not Doing 列表：新工具、复杂的引导技术、任何需要预算的东西。"第一个修复应该是 0 分钟准备、0 美元。"

---

从示例中提炼的八个设计要点

examples.md 文末的 "What to Notice in These Examples" 是整篇文档的方法论总结，逐条对应 SKILL.md 中的 Anti-patterns 与 Red Flags 约束：

1. 重述会改变框架。 "帮餐厅竞争"变成"留住既有顾客"；"加实时协作"变成"让人同时工作而不混乱"；"修复 stale 的回顾会"变成"修复输出层"。HMW 重述不是修辞，而是定界。
2. 问题在开处方之前先做诊断。 每个问题决定了这实际是哪一类问题。回顾会示例暴露出真正的问题是行动项跟进，而非会议格式——而这改变了每一个变体。
3. 变体带有理由。 每个变体解释为什么它存在（哪个透镜生成的），而不只是是什么。标签（Inversion、Simplification 等）本身在教用户这样思考。透镜清单与 SKILL.md Phase 1 定义一致：Inversion、Constraint removal、Audience shift、Combination、Simplification、10x version、Expert lens。
4. 技能有观点。 "我推向 1 或 3""变体 6 值得细品"。它告诉你它认为什么重要、为什么——不是中立的选项陈列。这对应 SKILL.md 的 "Be honest, not supportive"：好的头脑风暴伙伴不是 yes-machine。
5. Phase 2 是诚实的。 低差异化或高复杂度的想法会被直接点名。技能会反驳："把'必要东西'拉进来的直觉，正是产品失去焦点的方式。"
6. 产出是可执行的。 One-Pager 以能做的事收尾（验证假设、构建 MVP、跑实验），而不是值得思考的事。
7. "Not Doing" 列表做了实工作。 它具体且有推理。每一项都是你可能想做但暂不该做的事。SKILL.md 称其为"One-Pager 中最有价值的部分"——焦点就是对好想法说不。
8. 技能适配上下文。 代码库感知的示例引用真实架构；流程类想法生成零成本实验而非产品。框架不变，但输出匹配领域。

配套资料与验收机制：examples.md 在技能体系中的位置

examples.md 不是孤立的参考文件，它与 idea-refine 技能目录下的其他文件构成一个闭环：

文件	角色
SKILL.md	流程本体：三阶段指令、透镜清单、One-Pager 模板、Anti-patterns、Red Flags、验收清单
examples.md	本文主题：三个示范会话，示范节奏、语气与结构
frameworks.md	Phase 1 的框架库：SCAMPER、HMW、First Principles、JTBD、Constraint-Based、Pre-mortem、Analogous Inspiration，每个都标注"最适合"的适用场景
refinement-criteria.md	Phase 2 的量表：三大评估维度、三级假设审计（Must/Should/Might Be True）、价值-可行性决策矩阵、MVP 范围五原则
scripts/idea-refine.sh	初始化 docs/ideas/ 目录，输出 JSON 状态供 Agent 消费

其中 refinement-criteria.md 里的 MVP 范围原则，恰好解释了示例 1 的 MVP 为什么长成那样：只做一件工作并做好（"老样子复购"而非"完整点餐平台"）、先验证最危险的假设（顾客肯不肯换渠道）、以时间盒而非功能列表定义范围、Not Doing 列表强制存在、"如果不觉得尴尬，说明你等太久了"。决策矩阵（高价值高可行性→先做；高价值低可行性→值得冒险；低价值→基本不做）则解释了示例 2 为何在"勾选框"定位下选择 block-level locking 而非 CRDT。

验收机制有两层。一是 SKILL.md 的 Verification 清单：会话结束时须确认存在清晰的 HMW 问题陈述、目标用户与成功标准已定义、探索了多个方向（不止第一个想法）、隐藏假设已显式列出并附验证策略、Not Doing 列表明确了取舍、产出是具体工件而非纯对话、用户在实施前确认了最终方向。二是仓库的评测层：evals/cases/idea-refine.json 定义了触发判据（正例如 "I have a rough idea for a habit tracker, help me refine it"，反例 "Fix the failing CI pipeline" 归属 ci-cd-and-automation）与对话类评测的期望行为，确保技能在真实 Agent 环境中保持与 examples.md 一致的行为基线。

适用前提与限制

• 该技能设计为对话式流程：示例中的节奏依赖用户逐轮回应（指出哪些变体共鸣、反驳、补充上下文），跳过 Phase 1/2 直接要 Phase 3 输出被列为 Red Flag；
• 在代码库中运行时，示例 2 引用的 src/models/document.ts:45 是示范对话内的示意路径，用于展示"引用具体文件"的行为模式，并非本仓库的文件；
• One-Pager 落盘位置（docs/ideas/[idea-name].md）默认是相对被服务项目的仓库根目录，而非 agent-skills 仓库本身；
• 示例中的商业数据（如"50 位常客 = 每年 2 万美元节省"）是会话内用于说明评估推理的计算示例，不是任何真实业务数据。

小结

skills/idea-refine/examples.md 用三个不同领域的完整会话，把"什么是好的 Agent 辅助头脑风暴"从抽象规则变成了可模仿的对话范式：HMW 重述定界、诊断式提问、带透镜标签且各有理由的 5–8 个变体、有观点的收敛与反驳、以及以可执行假设清单、MVP 边界和 Not Doing 列表收尾的 One-Pager。配合 SKILL.md 的流程指令、frameworks.md 的透镜库、refinement-criteria.md 的评估量表和 evals/cases/idea-refine.json 的行为评测，idea-refine 展示了 Agent 技能仓库中"文档驱动 + 示例驱动 + 评测驱动"三者如何协同，把一个模糊想法可靠地推进到值得动手构建的状态。