value-realization by done-0/value-realization
npx skills add https://github.com/done-0/value-realization --skill value-realization状态:生产就绪 ✅ 版本:1.1.7 最后更新:2026-02-24 类型:分析框架
此技能提供了一个哲学框架和分析方法,用于评估终端用户能否“知道”他们通过产品可以实现什么价值。它从价值发现的角度指导分析,而不是提供检查清单。
此技能提供的内容:
核心问题:终端用户能否清楚地理解他们通过产品将实现什么价值——即使该价值需要时间才能实现?
关键术语:
核心区别:
当终端用户知道他们将获得什么价值时,才会采用产品。这种“知道”至关重要:
“知道”的含义:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
观察到的模式:
终端用户寻求的价值类型(但不限于):
大多数产品创造者面临一个隐藏的问题:终端用户通常不知道他们真正想要什么,而且他们表达的方式可能是错误的。
工作不仅仅是构建终端用户要求的东西——而是帮助终端用户发现他们真正寻求的价值。
此技能通过对话分析运作。当用户提出一个产品创意时:
此框架指导思考。它不规定解决方案。
分析方法:
references/scoring-rubric.md当用户讨论一个产品创意时,分析以下四个维度以评估终端用户是否会发现价值:
审视:
为何重要:如果终端用户无法向自己(或他人)解释为什么使用产品,他们就不会采用。
真实示例 - Dropbox(详细数据见 references/real-cases.md):
真实示例 - Google Wave(详细分析见 references/real-cases.md):
分析方法:提问:当被问到“你为什么使用这个?”时,终端用户会说什么?如果答案不清晰或以功能为中心(“因为它有X”),则深入挖掘实际的价值主张。
审视:
为何重要:短期价值和长期价值都是有效的方法。选择取决于产品的性质、具体场景和终端用户上下文。没有哪种天生更优越。
短期价值产品(终端用户在几分钟/几小时内看到结果):
长期价值产品(终端用户在几周/几个月内看到结果):
可用的设计方法:
分析方法:识别主要的价值时间线。评估方法是否与产品性质及目标终端用户的期望相匹配。如果终端用户已经致力于长期目标,不要强行加入短期机制。
审视:
为何重要:对终端用户来说,不可见的价值感觉就像没有价值。进展必须是可感知的。
注意:“可感知”在不同产品类型中呈现不同形式:
对终端用户可见的成果:
不可见的成果(对终端用户有问题):
分析方法:识别终端用户可以指出并说“我实现了这个”的东西。如果价值是不可见的,探索通过用户界面、通知或进度指示器使其有形化的方法。
审视:
为何重要:有时终端用户在体验之前并不知道他们想要什么。产品必须帮助他们快速发现。
发现模式 - Instagram(增长数据见 references/real-cases.md):
发现模式 - Notion:
分析方法:确定终端用户是否已经知道他们想要什么,或者需要去发现。如果需要发现,通过引导、教程或渐进式功能揭示,识别通往“顿悟时刻”的最快路径。
这些不是要遵循的规则——它们是分析具体情况时要考虑的观察到的模式。
有关真实数据的详细案例研究,请参见 references/real-cases.md(英文)或 references/real-cases-zh.md(中文)。
使用具体成果描述的产品:
使用技术或功能描述的产品:
有关包含指标和数据源的完整案例研究,请参见 references/real-cases.md。
最适用于:
较不适用于:
陷阱:完全按照终端用户的要求构建 现实:终端用户通常不知道他们真正需要什么 方法:通过对话和探索帮助终端用户发现真正的价值
陷阱:“我们的产品有X、Y、Z功能” 现实:终端用户不关心功能,他们关心他们将实现什么 方法:始终将功能转化为价值:“功能X帮助终端用户实现Y”
陷阱:“Duolingo使用连续天数,所以我们也应该用” 现实:连续天数适用于日常习惯,不适用于偶发性使用 方法:理解模式为何对终端用户有效,然后适应特定上下文
陷阱:“我们的算法好10倍” 现实:如果终端用户看不到/感受不到改进,那就不重要 方法:使价值对终端用户来说是有形且可见的
引用真实产品案例时,基于可验证的信息并解释与当前产品的相关性。
工具可用性:
references/real-cases.md 中的案例(Dropbox、Instagram、Duolingo、WeChat、Google Wave、Quibi)说明了模式,而不是普遍规则。
评估适用性:
当案例不适用时:如果用户的产品与参考案例差异显著(例如,B2B基础设施工具 vs C2C社交应用),搜索同一领域中可比较的产品。分析那些特定领域的例子,而不是将消费应用模式强行应用于不同的上下文。
示例:
探索性思考(适用于以下情况):
基于证据的分析(在以下情况下需要):
过程:
主要来源(首选):
次要来源(谨慎使用):
避免:
用户 vs 终端用户:
功能 vs 价值:
价值感知时机:
遇到不熟悉的概念时:
平衡探索与证据:
评估案例适用性:
此技能在对话中效果最佳。当用户讨论一个产品创意时:
这不是一个检查清单——它是一种思考方式。每个产品都不同。每个市场都不同。目标是清晰地思考终端用户是否会“知道”他们将获得什么价值。
分析过程中的研究:当用户提到特定产品、技术或概念时,此技能可能会通过WebFetch或WebSearch进行研究,以提供基于当前信息而非假设的、适合上下文的分析。
案例研究包含定量数据和数据来源:
references/real-cases.md - Dropbox、Instagram、Duolingo、WeChat、Google Wave、Quibi 的案例研究(英文)references/real-cases-zh.md - Dropbox、Instagram、Duolingo、微信、Google Wave、Quibi 的案例分析(中文)状态指示符参考标准:
references/scoring-rubric.md - 价值清晰度、时间线、感知、发现四个维度的状态指示符(🔴🟡🟢)参考标准(英文)references/scoring-rubric-zh.md - 价值清晰度、价值时间线、价值感知、价值发现四个维度的状态指示符(🔴🟡🟢)参考标准(中文)此技能帮助思考价值,而不是规定解决方案。每个产品都是独特的。每个市场都不同。目标是发现终端用户是否会清楚地理解他们将实现什么——因为这种理解是驱动采用的关键。
每周安装次数
268
仓库
GitHub 星标数
506
首次出现
2026年2月20日
安全审计
安装于
codex263
gemini-cli262
opencode262
github-copilot261
amp259
kimi-cli259
Status : Production Ready ✅ Version : 1.1.7 Last Updated : 2026-02-24 Type : Analytical Framework
This skill provides a philosophical framework and analytical methods for evaluating whether end users can "know" what value they can achieve through a product. It guides analysis from a value discovery perspective, rather than providing checklists.
What this skill provides :
Core question : Can end users clearly understand what value they'll achieve through the product - even if that value takes time to achieve?
Key terminology :
Core distinction :
End users adopt products when they know what value they'll get. This "knowing" is critical:
What "knowing" means :
Observed patterns :
Value types end users seek (but aren't limited to):
Most product creators face a hidden problem: end users often don't know what they actually want, and how they articulate it may be wrong.
The job isn't just to build what end users ask for - it's to help end users discover what value they're actually seeking.
This skill operates through conversational analysis. When the user presents a product idea:
This framework guides thinking. It does not prescribe solutions.
Analysis approach:
references/scoring-rubric.mdWhen the user discusses a product idea, analyze these four dimensions to evaluate whether end users will discover value:
Examine :
Why this matters : End users won't adopt a product if they can't explain to themselves (or others) why they're using it.
Real example - Dropbox (see references/real-cases.md for detailed data):
Real example - Google Wave (see references/real-cases.md for detailed analysis):
Analysis method : Ask: What would an end user say when asked "Why are you using this?" If the answer is unclear or feature-focused ("because it has X"), dig deeper into the actual value proposition.
Examine :
Why this matters : Both short-term and long-term value are valid approaches. The choice depends on the product's nature, specific scenarios, and end user context. Neither is inherently superior.
Short-term value products (end users see results in minutes/hours):
Long-term value products (end users see results in weeks/months):
Design approaches available :
Analysis method : Identify the primary value timeline. Assess whether the approach matches the product's nature and target end users' expectations. Don't force short-term mechanisms if end users are already committed to long-term goals.
Examine :
Why this matters : Invisible value feels like no value to end users. Progress must be perceivable.
Note : "Perceivable" takes different forms across product types:
Visible outcomes for end users :
Invisible outcomes (problematic for end users):
Analysis method : Identify what end users can point to and say "I achieved this". If the value is invisible, explore ways to make it tangible through UI, notifications, or progress indicators.
Examine :
Why this matters : Sometimes end users don't know what they want until they experience it. The product must help them discover it quickly.
Discovery pattern - Instagram (see references/real-cases.md for growth data):
Discovery pattern - Notion :
Analysis method : Determine whether end users already know what they want, or need to discover it. If discovery is needed, identify the fastest path to the "aha" moment through onboarding, tutorials, or progressive feature revelation.
These aren't rules to follow - they're observed patterns to consider when analyzing specific situations.
For detailed case studies with real data, see references/real-cases.md (English) or references/real-cases-zh.md (中文).
Products using concrete outcome descriptions :
Products using technical or feature descriptions :
For complete case studies with metrics and data sources, see references/real-cases.md.
Most applicable for :
Less applicable for :
The trap : Building exactly what end users ask for The reality : End users often don't know what they actually need The approach : Help end users discover the real value through conversation and exploration
The trap : "Our product has X, Y, Z features" The reality : End users don't care about features, they care about what they'll achieve The approach : Always translate features into value: "Feature X helps end users achieve Y"
The trap : "Duolingo uses streaks, so we should too" The reality : Streaks work for daily habits, not for episodic use The approach : Understand why a pattern works for end users, then adapt to specific context
The trap : "Our algorithm is 10x better" The reality : If end users can't see/feel the improvement, it doesn't matter The approach : Make value tangible and visible to end users
When citing real product cases, base on verifiable information and explain relevance to current product.
Tool Availability :
The cases in references/real-cases.md (Dropbox, Instagram, Duolingo, WeChat, Google Wave, Quibi) illustrate patterns, rather than universal rules.
Assess applicability :
When cases don't apply : If the user's product differs significantly from reference cases (e.g., B2B infrastructure tool vs C2C social app), search for comparable products in the same domain. Analyze those domain-specific examples instead of forcing consumer app patterns onto different contexts.
Example :
Exploratory thinking (appropriate when):
Evidence-based analysis (required when):
Process :
Primary sources (preferred):
Secondary sources (use with caution):
Avoid :
User vs End user :
Features vs Value :
Value perception timing :
When encountering unfamiliar concepts :
Balancing exploration and evidence :
Evaluating case applicability :
This skill works best in conversation. When the user discusses a product idea:
This isn't a checklist - it's a way of thinking. Each product is different. Each market is different. The goal is to think clearly about whether end users will "know" what value they'll get.
Research during analysis : When the user mentions specific products, technologies, or concepts, this skill may research them via WebFetch or WebSearch to provide context-appropriate analysis based on current information rather than assumptions.
Case studies include quantitative data and data sources:
references/real-cases.md - Dropbox, Instagram, Duolingo, WeChat, Google Wave, Quibi case studies (English)references/real-cases-zh.md - Dropbox、Instagram、Duolingo、微信、Google Wave、Quibi 的案例分析(中文)Status indicator reference criteria:
references/scoring-rubric.md - Reference criteria for status indicators (🔴🟡🟢) across four dimensions: value clarity, timeline, perception, discovery (English)references/scoring-rubric-zh.md - 价值清晰度、价值时间线、价值感知、价值发现四个维度的状态指示符(🔴🟡🟢)参考标准(中文)This skill helps think about value, not prescribe solutions. Every product is unique. Every market is different. The goal is to discover whether end users will clearly understand what they'll achieve - because that understanding is what drives adoption.
Weekly Installs
268
Repository
GitHub Stars
506
First Seen
Feb 20, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
codex263
gemini-cli262
opencode262
github-copilot261
amp259
kimi-cli259
AI代理协作核心原则:提升开发效率的6大Agentic开发原则指南
7,600 周安装