agent-skills 中 idea-refine 的评估标准拆解:AI Agent 如何做想法压力测试

agent-skills 中 idea-refine 的评估标准拆解:AI Agent 如何做想法压力测试

【免费下载链接】agent-skillsProduction-grade engineering skills for AI coding agents.项目地址: https://gitcode.com/GitHub_Trending/agentskill/agent-skills

本文围绕 refinement-criteria.md 展开,这是 agent-skills 仓库中idea-refine技能的核心评估量表(rubric),用于三阶段创意精炼流程的第二阶段「Evaluate & Converge」——对发散产生的多个想法方向做压力测试。读完后,你将理解这套评估体系如何从用户价值、可行性、差异化三个维度筛选方向,如何用三层假设审计(必须为真 / 应该为真 / 可能为真)暴露隐藏赌注,以及如何用决策矩阵和五条 MVP 原则把评估结论收敛为可执行的 one-pager。这套方法论的意义在于:它把「人类资深工程师的收敛式判断」编码成 AI Agent 可以在对话中稳定执行的检查清单,避免 Agent 沦为只会附和的 yes-machine。

文档定位:idea-refine 第二阶段专用的评估量表

要理解这份文档,先看它在技能中的调用位置。SKILL.md 将 idea-refine 定义为「把原始想法精炼成清晰、可执行概念」的结构化发散-收敛思维技能,其工作流程分三个阶段:

1. Understand & Expand(发散):复述想法为 How Might We 问题陈述,提出 3-5 个锐化问题,用反转、约束移除、受众转移、组合、简化、10x 版本、专家视角等镜头生成 5-8 个变体;
2. Evaluate & Converge(评估收敛):将用户认可的变体聚成 2-3 个方向,用三个标准做压力测试,并显式暴露隐藏假设;
3. Sharpen & Ship(精炼交付):产出一个 markdown one-pager,经用户确认后保存至docs/ideas/[idea-name].md。

refinement-criteria.md正是阶段 2 的操作手册。SKILL.md 第 97 行明确指示 Agent:「Readrefinement-criteria.mdin this skill directory for the full evaluation rubric.」。这种「主文件只写流程、细则按需加载」的拆法,符合 docs/skill-anatomy.md 中「Progressive disclosure(渐进式披露)」的设计原则:启动时上下文里只有技能名和描述,SKILL.md全文在 Agent 判断相关时才加载,支撑文件则在工作流真正走到该步骤时才读取,从而压低 token 成本。也就是说,这份量表不是给人翻的参考手册,而是给 Agent 在收敛阶段「加载进工作记忆」后逐条执行的评分规则。

文档开头还有一条使用纪律:并非每条标准都适用于每个想法,要用判断力决定哪些维度在当前语境下最重要。这防止 Agent 机械地把所有问题问一遍,与 SKILL.md 的哲学「Challenge every assumption. "How it's usually done" is not a reason.」一脉相承。

核心评估维度一:用户价值(最重要的一维)

文档对三个维度的排序本身就是观点:User Value 是最重要的维度。如果价值不清晰,其他一切都无关紧要。这一维度首先要求区分「止痛药」与「维生素」:

• Painkiller(止痛药):解决急性、高频的问题,用户会主动寻找,会从现有方案切换过来。信号:人们带着情绪描述问题、已经自建了临时 workaround、愿意为解决方案付费。
• Vitamin(维生素):锦上添花,让某件事好一点点,用户不会特意去用。信号:人们礼貌地点头说「挺酷的」,然后行为毫无变化。

原文档给出的自问清单(逐条用于审视具体想法):

1. 你能否说出3 个现在就有这个问题的具体人名?
2. 他们今天实际在用什么替代方案?(真正的竞争对手永远是现有的 workaround。)
3. 他们会不会从当前做法切换过来?什么会促使他们切换?
4. 他们多久遇到一次这个问题?(每日问题 > 每月问题)
5. 这是「pull」问题(用户在主动要)还是「push」问题(你自认为他们应该想要)?

对应的红旗(red flags)信号:

• 「人人都能用上」——说不出具体用户,说明价值不清晰;
• 「像 X 但更好」——边际改进很少能驱动采用;
• 问题真实但罕见——高强度低频率的问题很难支撑一个产品。

核心评估维度二:可行性(不只是技术可行)

可行性评估回答的是「你真的做得了吗?不只是技术上,而是实际意义上」。文档把它拆成三个子维度:

技术可行性:

• 核心技术是否存在且可靠工作?
• 最难的技术问题是什么?是「已知的难问题」还是「全新问题」?
• 是否依赖你不可控的第三方、API 或数据源?
• 最小技术栈是什么?(如果答案是「很多」,那本身就是信号。)

资源可行性:

• 构建 MVP 的最小团队/工作量是什么?
• 是否需要你不具备的专门技能?
• 是否存在监管、法律或合规要求?

Time-to-value(到达价值的时间):

• 多快能让用户看到东西?
• 是否存在一个天/周级(而非月级)就能交付价值的版本?
• 关键路径是什么?什么必须最先发生?

可行性红旗:

• 「我们得先解决某个很难的研究问题」——典型的拖延信号;
• 多个依赖必须同时工作才行;
• MVP 仍需要数月工作量——说明它根本不够 minimal。

核心评估维度三:差异化(是 different,不是 better)

这一维度的关键句式值得注意:「What makes this genuinely different? Not better —different.」文档给出的问题清单:

• 如果用户向朋友描述这个东西,他们会怎么说?这个描述有吸引力吗?
• 它做到了什么而别的一切都没做到?(如果答不出「一件事」,那就是问题。)
• 这种差异化是持久的吗?竞争对手一周内能复制吗?
• 这个差异是用户真正在意的,还是只是构建者觉得有意思?

文档还给出了一套按强度排序的差异化类型(从最强到最弱):

差异化红旗:

• 差异化完全在技术层面而非用户体验层面;
• 「我们更快/更便宜/更好看」却没有结构性原因;
• 带来差异化的功能恰恰不是用户最在意的功能。

假设审计:把赌注显式写出来

在收敛出方向之后、决定下注之前,文档要求对每个想法方向把假设显式列出,并分三类:

Must Be True(Dealbreakers,致命假设)

如果错了会彻底杀死整个想法的假设,必须在构建之前验证。

原文示例:「用户愿意把数据分享给我们」——如果他们不愿意,整个产品就不成立。

Should Be True(Important,重要假设)

显著影响成功与否,但错了不会杀死想法——可以调整打法。

原文示例:「用户更偏好自助式而非与人沟通」——如果错了,需要换 go-to-market,但核心产品仍可能成立。

Might Be True(Nice to Have,锦上添花)

关于次要功能或优化的假设。核心被证明之前,不要验证这些。

原文示例:「用户会想把结果分享给队友」——这是增长功能,不是核心价值主张。

这个三层结构直接服务于 MVP 取舍:只有第一层的假设才配得上 MVP 的验证预算。examples.md 中的餐厅案例正是如此处理的——Phase 2 对「Regulars Engine」方向列出的隐藏假设里,「常客愿意改用新的下单方式」被标注为「最可能出错的假设」,最终 MVP 的三条验证项就围绕它展开(5 家餐厅、每家 20 位常客、4 周转化率)。

决策框架:价值 × 可行性四象限矩阵

在多个方向之间做选择时,文档给出一个 2×2 矩阵作为排序依据:

矩阵之外,规则只有一条:在同一象限内的选项之间,用差异化作为平局裁决器。这与上一节「差异化类型按强度排序」形成闭环——先按价值/可行性定位,再用差异化的持久性打破平局。

MVP 范围设定的五条原则

选定方向后,定义 MVP 范围时文档给出五条原则,逐条都有针对性:

1. One job, done well(做好一件事)。MVP 应精确完成一个用户 job,而不是把三件事各做一半。
2. The riskiest assumption first(先验证风险最大的假设)。MVP 的首要目的就是测试最可能出错的那个假设——这与假设审计的第一层直接咬合。
3. Time-box, not feature-list(用时间盒,而非功能清单)。「在 [时间段] 内我们能构建并测试什么?」比「我们需要哪些功能?」是更好的问法。
4. The 'Not Doing' list is mandatory(「不做什么」清单是强制项)。显式列出砍掉什么、为什么砍。这防止 scope creep,并迫使诚实的优先级排序。
5. If it's not embarrassing, you waited too long(如果初版让你不尴尬,说明你出手太晚了)。第一个版本应当让构建者自己觉得不完整;如果没有,说明构建过头了。

值得注意的是,第 4 条与 SKILL.md 的表述互相强化:one-pager 模板中「Not Doing (and Why)」被描述为「arguably the most valuable part(可能有价值最大的部分)」,因为 focus 的本质就是对好想法说不。

量表如何落地:仓库中的实操证据

评估案例的完整示范。examples.md 的 Example 1(独立餐厅对抗外卖平台)是这份量表的完整运行记录:Phase 2 对两个方向逐一给出「Core bet / User value / Feasibility / Differentiation / Hidden assumptions / What could kill it」的结构化评估。其中 User value 维度被量化——「常客每周 $30 订单,每年省下约 $400 佣金,50 位常客即 $20K/年,对小餐厅是实打实的钱」;Feasibility 维度明确点出难点(如何零人工冷启动获取订单历史);Differentiation 维度指出「对 DoorDash 来说这个市场太小不值得进入,这恰恰是好的楔子」。最终给出的诚实结论是「Direction A 是更锋利的赌注」,并直接反驳用户的想法——「把『必要但无聊』的东西塞进来的本能,正是产品失去焦点的方式」。

预验尸(Pre-mortem)的配合。frameworks.md 中列出的 Pre-mortem 框架明确标注「Best for: Phase 2 evaluation. Stress-testing ideas that feel good but haven't been pressure-tested.」——假设项目 12 个月后失败了,倒推所有可能的失败原因,再逐一判断「可防吗?是不是想法该改的信号?」。这与量表中「What could kill this idea」的暴露要求互为表里。

输出物的强制结构。Phase 3 的 one-pager 模板包含 Problem Statement、Recommended Direction、Key Assumptions to Validate(每条附测试方法)、MVP Scope、Not Doing (and Why)、Open Questions 六个部分。scripts/idea-refine.sh 负责初始化输出目录:执行bash skills/idea-refine/scripts/idea-refine.sh会创建docs/ideas/目录并向 stdout 输出机器可读的 JSON 状态{"status": "ready", "directory": "docs/ideas"},符合 docs/skill-anatomy.md 对 skill 脚本的约定(bash shebang、set -e、状态信息走 stderr、JSON 走 stdout)。

评估门禁的自动校验。仓库的 evals/cases/idea-refine.json 定义了触发测试与行为断言:正例包括「help me refine it」「Stress-test my plan」「Ideate on...」,负例(修 CI、安全审计)应路由给其他技能;行为期望则直接对应量表的落点——「收敛前先问锐化问题」「显式暴露隐藏假设」「输出包含显式 Not Doing 清单」「Agent 对弱点提出反驳而非一味同意」。也就是说,这份量表是否被 Agent 真正执行,本身是被评测的。

小结

refinement-criteria.md 的设计思路可以概括为三层:第一,用「用户价值 > 可行性 > 差异化」的排序和每维的红旗信号,防止评估被技术兴奋感带偏;第二,用三层假设审计和四象限矩阵,把「凭感觉选方向」变成可检查的决策步骤;第三,用五条 MVP 原则(尤其强制的 Not Doing 清单和「先验证最险假设」)把评估结论转化为最小验证成本。它与 SKILL.md 的三阶段流程、frameworks.md 的镜头库和 examples.md 的完整示范共同构成了一个可被 AI Agent 稳定执行的收敛式判断系统——对任何需要在「先做什么」上止损的开发者,这套清单即使脱离 Agent 场景,也可以直接当作人工评审想法的检查表使用。

【免费下载链接】agent-skillsProduction-grade engineering skills for AI coding agents.项目地址: https://gitcode.com/GitHub_Trending/agentskill/agent-skills