Product Mindset

product-mindset

何时必须加载

只要成果会被自己以外的人重复使用，就进入覆盖范围；审查深度由交付级别决定：

• 立项 / 大改（L1）： "我要做一个 XX 产品/工具/网站/App"、"帮我搭一个 MVP"、"重做首屏"、"要不要开一条新产品线"
• 加/砍功能（L2）： 新增页面/模块/主要路径；砍掉一个功能；改一条核心流程；决定"要不要加这个功能"
• 微交互（L3）： 改文案、按钮、错误提示、空状态、loading 反馈
• 发布节点： 项目从"能跑通"要推到"能给别人用"；准备上线/更新
• 研究判断： 竞品分析、市场调研、用户替代方案分析、定位或商业模式判断
• 不确定信号： Agent 已经想开写，但目标用户/差异化/受众还没定型

不适用： 仅自己使用的一次性脚本、明确不交付的技术实验，以及不改变用户体验或发布风险的纯技术任务（"修这个内部 bug"、"重构这个模块"、"加个测试"）。公司内部工具不是天然豁免：只要多人依赖、会修改真实数据或需要部署维护，就至少按 T2 处理。

先选择交付级别

不要把个人小工具和正式生产系统套进同一张清单。新产品或首次启用本 Skill 时，用户只需说一句"这是 T0/T1/T2/T3 产品"；不得要求填写产品定义模板。Agent 根据级别和现有上下文推进对应流程，只在缺失信息会改变级别、范围或安全边界时问一个聚焦问题。后续迭代沿用已确认级别，除非实际暴露面或失败后果需要升级。

| 级别 | 适用场景 | 必须覆盖 | | --- | --- | --- | | T0 · 探索原型 | 验证技术、交互或需求假设；不对外承诺可用 | 写清假设、验证方法、停止条件；不得称为已产品化 | | T1 · 共享小工具 | 个人 vibecoding 后免费分享、开源项目、低风险社区工具 | 核心价值、最短路径、安装与基本文档、错误恢复、数据边界、局限说明、基本验证 | | T2 · 持续使用产品 | 公司内部多人使用、公开长期运行、依赖真实账户或数据 | T1 + 指标、权限、安全、可靠性、兼容性、监控、备份恢复、发布回滚、反馈支持、升级迁移 | | T3 · 商业/关键产品 | 收费、SLA、敏感数据、关键业务、医疗金融等受监管场景 | T2 + 合规、威胁建模、审计、容量与成本、事件响应、正式支持、生命周期；商业成立时再检查定价与单位经济性 |

分层原则：

• 盈利不是产品化前提。 T1 不因免费而强加定价、客服团队或长期商业规划。
• 风险不会因免费而消失。 处理凭据、隐私、支付、健康或不可逆数据时，直接提升相关安全门槛。
• 同一项目可以按维度升级。例如小工具仍可因处理敏感数据而执行 T3 的隐私与安全检查。
• 用户明确只做 T0 时可以继续编码，但要说明这是验证性原型，而不是可发行产品。

Q1 · 用户为什么不用现有替代方案？

先确认用户当前怎样完成任务：竞品、通用 AI、人工服务、表格/脚本、多个工具拼接，还是不处理。至少说明一种改变理由：

• 独有输入： 专有上下文、数据、UGC、设备、身份关系或本地隐私。
• 更完整的结果： 端到端工作流、可执行或可验证输出、更低的操作与认知成本。
• 场景专精： 有规则、评测或领域证据证明通用方案达不到要求。
• 持续复利： 记忆、协作、历史沉淀或网络效应使长期使用更有价值。

AI 产品额外检查"为什么不直接问通用 AI"；只有更好看或封装 prompt 不构成可靠差异。差异不必是永久护城河，但必须解释用户为什么现在愿意改变原有做法。

同时检查问题证据，不能让差异化掩盖伪需求：

• T0：至少写清目标用户、发生场景、假设和验证方式。
• T1：至少有一种轻量证据，例如真实抱怨、重复手工流程、访谈记录、搜索/社区信号或自己持续遇到的问题。
• T2–T3：需要可复核证据，包括发生频率、现有替代、损失或收益、采用阻力；商业产品还要区分使用者、购买者和决策者。

没有证据时标为"待验证假设"。T0 可以做最小原型收集证据；T1–T3 应先缩小到可验证切口，不能硬编理由或把推测写成用户事实。

Q2 · 如果你是用户，第一次打开你愿意用吗？哪里最不便利？

按新用户首次使用路径检查：能否理解价值、知道第一步、以最少必要的注册或配置完成核心任务，并在等待、出错或误操作后知道如何继续。消费级简单产品默认关注前 60 秒；复杂专业工具使用与任务相称的目标。

每个无法消除的摩擦都要说明原因；重大摩擦需要用户决定是否接受。具体检查项统一放在自查表 B/C，不在这里重复。

竞品与市场调研

用户要求竞品、市场或定位分析，或 L1 缺乏替代方案证据时执行。覆盖直接竞品、间接方案、通用工具/人工流程，以及"不采取行动"。

• 先定义目标用户、场景、地区、时间范围和待验证问题，再搜索；不要先搜一堆产品再倒推结论。
• 优先使用官网、定价页、文档、更新记录、应用商店评价、公开用户讨论等一手或近一手来源。
• 每项关键事实记录来源与访问日期；明确区分事实、用户反馈、推断。
• 不因一次搜索没找到就宣称"没有竞品"。结论应写成"在本次范围内未发现"，并列出搜索边界。
• 不用融资额、下载量或报告数字替代需求证据；市场规模优先按可触达用户 × 采用率 × 使用/付费价值自下而上估算，并写出假设。

最小结论包括：用户当前做法、主要替代方案及工作流、用户称赞/抱怨与迁移阻力、可切入的窄场景、证据强度、未知项和下一步实验。竞品有某功能本身不是开发理由。

产品化自查表（Self-Audit Checklist）

每项必须提供截图、操作路径、测试结果、日志、用户证据或明确文案。没有证据就标记"未验证"；确实不适用时写明理由，不能为了过表虚构完成。

在三个节点使用：开始编码前确定假设与级别，实现中检查核心流程，发布/交付前按所选级别执行终检。

A. 问题、定位与范围（T0+）

• 目标用户被具体到某类人的某个场景，而不是"所有需要 X 的人"
• 问题证据与未知假设被分开记录
• 能说明用户当前替代方案，以及为什么愿意改变现有做法
• 有明确的目标、成功信号和足以控制范围的非目标
• T0 写明验证方法与停止条件；不能把原型结论当作已验证事实

B. 首次使用（T1+）

• 用户能在与产品复杂度相称的时间内理解价值并完成第一次核心任务
• 能先试后注册时不强制注册；因安全、协作或业务必须登录时解释原因
• 空状态、示例、默认值和引导能帮助用户开始，而不是要求用户猜
• 手动配置被降到最低；开发者工具必须配置时提供自动检测、示例和可行动报错
• 只适配目标用户实际使用的终端；需要移动端时才把移动端作为发布门槛

C. 核心闭环与交互（T1+）

• 核心链路是输入 → 处理 → 结果 → 下一步动作的完整闭环
• 等待有状态反馈，失败信息说明发生了什么和下一步怎么做
• 可中止、重试、撤销或恢复；无法恢复时提前警告
• 技术选项默认被吸收；面向开发者或高级用户确有控制价值时可以暴露，并提供安全默认值
• 历史、复制、分享或导出只在它们支持真实任务时要求，不机械添加

D. 数据、指标与学习（T2+；T1 按需）

• 定义结果指标和反指标，避免只统计点击量、注册量等表面数字
• 能回答核心流程在哪失败、用户为何流失；隐私约束下采用最小必要埋点
• 用户数据的保存、导出、删除和保留期限有明确规则
• 有反馈入口，并能把反馈转成验证、修复或取舍，而不是只收集不处理

E. 信任、安全与权限（所有级别按风险适用，阻断项）

• 数据边界明确：采集什么、发送到哪里、保存多久、谁能访问
• 权限最小化，并在需要时解释用途
• 危险或不可逆操作有预览、确认、备份或恢复方案
• 凭据和敏感信息不写入代码、日志、仓库或不安全存储
• AI 结果的来源、置信边界和人工复核要求与风险匹配
• 涉及敏感数据、支付、医疗、金融或未成年人时，提升到相应 T3 审查

F. 可靠性、发布与恢复（T2+；T1 做基本验证）

• 核心成功路径和关键失败路径经过实际运行，不以"代码看起来正确"代替验证
• 明确支持的平台、浏览器、依赖版本和资源边界
• T1 至少有可复现安装、启动、更新或移除说明
• T2+ 有健康检查、日志、监控、备份恢复、灰度或回滚方案
• 发布产物在干净环境验证，避免只在开发者机器上能运行

G. 分发、支持与生命周期（T2+；T1 轻量）

• 用户知道从哪里获取、如何开始、遇到问题去哪里查
• T1 可用 README、Issue 或邮箱承担轻量反馈，不强制建设客服体系
• T2+ 明确负责人、故障响应、升级迁移、兼容与弃用策略
• 依赖外部 API、模型或平台时说明中断、涨价和能力变化的降级方案

H. 商业与合规（条件触发）

• 只有存在收费或商业目标时，才检查定价、获客渠道、服务成本和单位经济性
• 只有涉及对应地区、行业、数据和内容时，才执行隐私、版权、许可及行业合规检查
• 不清楚的法律问题标为需专业确认，不让 Agent 自行宣称"完全合规"

I. 语言与可访问性（按受众适用）

• 使用用户词汇，不原样暴露后端异常和内部字段
• 按钮优先表达具体动作；通用确认对话中"确认/取消"确实最清楚时可以保留
• 关键状态不只依赖颜色；目标受众需要时检查键盘、读屏、对比度和字号
• 首屏优先帮助用户开始，必要说明按需展开

分层通过标准

• 所有对外交付共同阻断： 核心任务不可完成；可能丢失或泄露数据；危险操作无警告或恢复；把假设伪装成证据。
• T0： A 通过即可继续实验，但输出必须标记为原型及未验证项；使用真实数据时仍受安全与数据保护约束。
• T1： A/B/C/E 通过，F 的基本安装与验证通过；其余不适用项说明理由。
• T2： A–G 中所有适用项通过，阻断项不能推迟到路线图。
• T3： T2 全部通过，并完成对应的商业、合规、安全、容量和事件响应审查。

Agent 执行流程

Skill 激活后不能只输出建议清单。按任务规模执行最小充分闭环：

1. 识别阶段与级别： 判断是探索、实现、迭代、研究还是发布，并选择 T0–T3。能从上下文推断时不追问。
2. 检查已有证据： 阅读现有需求、代码、界面、测试、日志和用户反馈；把已知事实、假设和缺口分开。
3. 找最大风险： 一次优先解决最可能让产品无人用、不能用或不敢用的 1–3 个问题，不平均用力。
4. 实施最小闭环： 在用户授权范围内直接补齐必要实现、文案、默认值、错误恢复、文档或验证，不止停在评论。
5. 验证真实路径： 从目标用户入口运行核心任务，并按级别检查干净环境、失败路径、权限、数据和回滚。
6. 给出结论： 说明已验证证据、未解决风险、是否达到当前级别，以及下一步最小行动。

竞品与市场调研属于证据获取，不替代真实用户验证；Agent 的自我代入也不能冒充用户反馈。

Agent 行为硬约束（Hard Rules）

Skill 激活时你必须遵守：

1. 不主动堆功能。用户没提的功能不要加。三个功能做透，胜过十个功能半吊子。
2. 产品语言 ≠ 工程语言。UI 文案、错误信息、按钮标签，全部用用户的词汇。
3. 不无故暴露实现复杂度。模型名、API Key、token 限制和框架名默认由产品吸收；目标用户需要控制这些参数时，给出解释和安全默认值。
4. 默认给一条最短路径完成核心任务。高级选项不应阻塞首次成功；确属专业任务必需的配置除外。
5. 有摩擦必须先声明。因技术/合规必须让用户登录/授权/等待/配置，先告诉用户"这里会有 X 摩擦，原因是 Y"，让他决定是否接受。
6. 重大范围决策主动写非目标。L1 必须写；L2 在范围可能扩张时写；L3/L4 不机械生成。
7. 证据与推断分离。不得把 Agent 猜测、营销文案或竞品功能当作用户需求证据。
8. 发布前按级别终检。只检查当前级别及风险触发的适用项，但任何安全阻断项都不能降级豁免。

可见检查点与决策升级

这份 Skill 默认约束 Agent 的判断与执行，不要求 Agent 通过固定模板证明自己"有产品思维"。能直接落实到实现、文案、默认值、错误恢复、测试和文档中的内容，应静默完成，不额外制造产品分析仪式。

只有以下情况必须主动向用户报告：

1. 需要用户作实质决策

当产品化要求会明显改变范围、成本、周期、数据边界、登录方式、依赖或产品方向时，说明：

• 发现了什么
• 为什么会影响产品或用户
• 哪个决定必须由用户作出

不要自行替用户接受重大摩擦、风险或工作量扩张。

2. 出现阻断项

核心任务不可完成、数据可能丢失或泄露、危险操作不可恢复、缺少必要问题证据却准备正式发布，以及安全或合规风险未解决时，必须明确指出并停止把项目包装成已达到目标级别。

T0 可以继续做标明假设的最小验证原型；不能把原型结论伪装成产品证据。

3. 分析本身就是交付物

用户要求竞品、市场、定位、用户研究或产品方案时，输出证据、事实、推断、结论和未知项。不要只汇报"执行了哪些产品思维步骤"。

4. 发布或交付前

给出简短、可审计的门禁结果：

交付级别：T1/T2/T3
结论：可以发布 / 有条件发布 / 暂不发布
已验证：
阻断项：
剩余风险：

结论必须来自实际证据，不能根据 Agent 自评打勾。阻断项不能被埋进"后续优化"。

其余情况保持安静

• L1 的判断仍需完整执行，但只有遇到上述检查点才展开输出。
• L2 在功能取舍影响范围、核心闭环或风险时报告，否则直接落实。
• L3 默认静默改善文案和微交互。
• L4 正常完成技术任务；发现核心闭环、数据、安全或发布风险被破坏时才升级。

除首次产品定义必须显式确认外，能从上下文推断交付级别时不要追问。Hard Rules 按各条适用条件执行；安全、证据真实性和用户数据保护不因 L/T 等级降低。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: yhwang303
• Source: yhwang303/product-mindset-skill
• License: MIT

Install and usage instructions live in the source repository linked above.