product-mindset

# product-mindset ## 何时必须加载 本 Skill 用两条**相互独立**的轴控制介入方式，不要混为一谈： - **L 轴（改动规模）：** 决定本次改动要展开多少产品判断和多少可见输出。L1 > L2 > L3 > L4，规模越大越要显式判断。 - **T 轴（交付级别，T0–T3，见下一节）：** 决定产品化要求的**深度**（要覆盖哪些检查项）。 一次任务先按 L 判断"展开到什么程度"，再按 T 判断"检查到多深"。只要成果会被自己以外的人重复使用，就进入覆盖范围： - **L1 · 立项 / 大改：** "我要做一个 XX 产品/工具/网站/App"、"帮我搭一个 MVP"、"重做首屏"、"要不要开一条新产品线" - **L2 · 加 / 砍功能：** 新增页面/模块/主要路径；砍掉一个功能；改一条核心流程；决定"要不要加这个功能" - **L3 · 微交互：** 改文案、按钮、错误提示、空状态、loading 反��� - **L4 · 纯技术任务：** 不改变用户体验或发布风险的内部改动（"修这个内部 bug"、"重构这个模块"、"加个测试"）。**默认不展开产品判断**，正常完成即可，但一旦发现核心闭环、数据、安全或发布风险被破坏就主动升级。 以下场景无论落在哪个 L 都要触发对应流程： - **发布节点：** 项目从"能跑通"要推到"能给别人用"；准备上线/更新 - **研究判断：** 竞品分析、市场调研、用户替代方案分析、定位或商业模式判断 - **不确定信号：** Agent 已经想开写，但目标用户/差异化/受众还没定型 **完全不适用：** 仅自己使用的一次性脚本、明确不交付的技术实验。公司内部工具不是天然豁免：只要多人依赖、会修改真实数据或需要部署维护，就至少按 T2 处理。 ## 先选择交付级别 不要把个人小工具和正式生产系统套进同一张清单。新产品或首次启用本 Skill 时，用户只需说一句"这是 T0/T1/T2/T3 产品"；不得要求填写产品定义模板。Agent 根据级别和现有上下文推进对应流程，只在缺失信息会改变级别、范围或安全边界时问一个聚焦问题。后续迭代沿用已确认级别，除非实际暴露面或失败后果需要升级。 | 级别 | 适用场景 | 必须覆盖 | | --- | --- | --- | | **T0 · 探索原型** | 验证技术、交互或需求假设；不对外承诺可用 | 写清假设、验证方法、停止条件；不得称为已产品化 | | **T1 · 共享小工具** | 个人 vibecoding 后免费分享、开源项目、低风险社区工具 | 核心价值、最短路径、安装与基本文档、错误恢复、数据边界、局限说明、基本验证 | | **T2 · 持续使用产品** | 公司内部多人使用、公开长期运行、依赖真实账户或数据 | T1 + 指标、权限、安全、可靠性、兼容性、监控、备份恢复、发布回滚、反馈支持、升级迁移 | | **T3 · 商业/关键产品** | 收费、SLA、敏感数据、关键业务、医疗金融等受监管场景 | T2 + 合规、威胁建模、审计、容量与成本、事件响应、正式支持、生命周期；商业成立时再检查定价与单位经济性 | 分层原则： - **盈利不是产品化前提。** T1 不因免费而强加定价、客服团队或长期商业规划。 - **风险不会因免费而消失。** 处理凭据、隐私、支付、健康或不可逆数据时，直接提升相关安全门槛。 - 同一项目可以按维度升级。例如小工具仍可因处理敏感数据而执行 T3 的...