p13g-mid-judgment
九步中段——做成什么形态、用户托付度、怎么做的决策框架
What it does
中段判断 Skill
适用场景
- 确定产品形态与交付形式
- 评估用户信任与采用意愿
- 设计人机协作方案
输入
| 字段 | 说明 |
|---|---|
| target_users | 目标用户画像 |
| solution_concept | 解决方案概念 |
| ai_role_options | AI角色选项(助手/协作者/代理等) |
输出
- 产品形态建议(产品/模块/能力层)
- 用户托付度评估
- 人机协作设计方案
工作流程
- 形态判断:做成独立产品、系统模块,还是工作流中的能力层?
- 托付度判断:用户愿意尝试吗?愿意持续用吗?敢把关键任务交给它吗?
- 协作方式判断:AI该辅助还是代理?模型边界在哪里?需要补哪些交付条件?
注意事项
- 形态选择影响技术架构与商业化路径
- 托付度是产品能否成立的关键——再好的技术,用户不敢用等于零
核心概念
1. 第一次像魔法 vs 后来像习惯
很多产品第一次用起来像魔法,后来却没有变成习惯。第一次用的时候用户看到的是能力跃迁,继续使用时用户面对的是现实摩擦。一个产品如果只有第一次魔法没有后续习惯,就会陷入典型路径:首次体验很强→社交传播不错→用户愿意试一下→第二次频率下降→第三次想不起来为什么要打开→最后只剩"大家都觉得它挺厉害"。长期成立的核心不是能不能制造一次惊艳,而是能不能让价值在时间里反复被验证。
2. 长期成立五问
(1) 价值是第一次感知还是反复验证——"看见能力"vs"感受到系统性帮助"?(2) 用户为什么还会回来——"因为它很聪明"不是回访理由,"因为它明显省时间/更稳/接住了麻烦的下一步"才是。(3) 价值会累积吗——数据/上下文/偏好/协作关系累积才有黏性,每次使用都像第一次就容易被替代。(4) 它能进入真实工作流和预算吗——"偶尔会用"vs"已经变成工作的一部分"。(5) 拿掉后用户会不会不舒服——"有点可惜"vs"效率倒退、流程变麻烦"。
3. 首周数据是在看烟火,复访理由才是在看炉火
AI 产品特别容易制造惊艳时刻,所以首周数据经常骗人。注册、激活、生成次数、分享率更接近"点火指标",不是长期成立指标。更值得看的是:用户第二次为什么回来?没回来的用户卡在了哪?留下来的用户把它接进了什么任务?使用频率是否稳定?用户是因为"有趣"而来,还是因为"离不开"而留?
4. 分清惊艳时刻和回访理由
每次看到一个很强的 AI 产品,强迫自己分别写两句话:第一句"用户第一次为什么会被打动",第二句"用户第十次为什么还会回来"。如果第一句写得很顺,第二句却开始发虚,这就是警报。比如:第一次被打动"它能把长文快速变短",第十次回来"因为我每天都要处理大量信息,而且它能直接接进我的研究和汇报流程"——第二句写不出来,长期成立就很可疑。
5. "试用成功"≠"长期行为"
很多看起来好用的 AI 产品最后死在"外挂地位"——用户偶尔会用但不会放进主要工作流,团队偶尔会提但不会写进正式流程,公司偶尔会买试用但不会长期留预算。它的价值还没有从"可用"升级到"不可轻易拿掉"。工作流和预算都是长期成立的重要信号。
深入核心概念
1. 首周数据是在看烟火,复访理由才是在看炉火
"AI产品特别容易制造惊艳时刻,所以首周数据经常骗人。注册、激活、生成次数、分享率更接近'点火指标',不是长期成立指标。" ——书稿第7章
很多团队把试用成功误认成PMF。注册率高、激活率高、首日留存不错——但AI产品的首日数据天然好看,因为新鲜感强。真正的PMF要看第三周、第四周的回访行为。更值得看的是:用户第二次为什么回来?没回来的用户卡在了哪?留下来的用户把它接进了什么任务?应用:对每个AI产品,强迫自己分别写两句话——第一句"用户第一次为什么会被打动",第二句"用户第十次为什么还会回来"。如果第一句写得很顺,第二句却开始发虚,这就是警报。
2. 累积性是长期成立的隐藏引擎
"如果一个产品每次使用都像第一次,没有记忆,没有沉淀,没有路径依赖,用户不会觉得'我已经在这里投入过东西'。" ——书稿第7章
长期成立的产品往往都有某种累积性:数据累积、上下文累积、偏好累积、协作关系累积、模板累积。如果每次使用都像第一次,用户不会觉得"我已经在这里投入过东西",只会觉得"下次换一个也差不多"。没有积累就没有黏性,没有黏性长期成立就会很难。应用:检查产品是否有至少两种以上的累积机制——越用越懂上下文、越用越接近用户偏好、越用越减少重复动作、越用越嵌进团队协作。没有累积性的产品,需要非常谨慎地评估长期成立性。
3. "试用成功"≠"长期行为"——外挂地位是最大陷阱
"很多看起来好用的AI产品最后死在'外挂地位'——用户偶尔会用但不会放进主要工作流,团队偶尔会提但不会写进正式流程。" ——书稿第7章
工作流和预算都是长期成立的重要信号。前者说明它已经进入行为链路,后者说明它已经进入资源分配逻辑。两者缺一个,产品都容易停留在边缘。团队偶尔会提但不会写进正式流程,公司偶尔会买试用但不会长期留预算——这说明价值还没有从"可用"升级到"不可轻易拿掉"。应用:做"拿掉测试"——如果用户只是"有点可惜",产品还没真正成立。如果用户明显觉得效率倒退、流程变麻烦,甚至会主动找替代品,说明它已经从新鲜感走向了依赖。
分步执行
步骤 1:新鲜感 vs 持续价值区分
判断当前产品的价值主要来自新鲜感(第一次感知强)还是持续价值(每次使用都验证)。如果价值主要停留在第一次感知,它就更容易被更快更新、更会演示、更新鲜的东西替代。
步骤 2:回访理由分析
明确回答:用户第二次为什么会回来?把"因为它很聪明"排除掉,找到更朴素也更持久的理由——省时间、更稳、接住了麻烦的下一步、减少了拖延、比旧方法省脑子、团队已经围绕它形成协作方式。
步骤 3:累积性评估
检查产品是否有累积性:数据累积、上下文累积、历史记录累积、协作关系累积、模板累积、偏好累积。如果每次使用都像第一次,没有记忆、没有沉淀、没有路径依赖,用户不会觉得"我已经在这里投入过东西"。
步骤 4:工作流嵌入与预算检查
检查产品是否已经进入主要工作流和正式预算。不只是"偶尔会用",而是"已经变成工作的一部分"。不只是"试试看的花费",而是"不太愿意撤掉的预算"。两者缺一个,产品都容易停留在边缘。
步骤 5:"拿掉测试"与诊断
做拿掉测试。如果用户只是"有点可惜",产品还没真正成立。如果用户明显觉得效率倒退、流程变麻烦、协作变乱,甚至会主动找替代品,说明它已经从新鲜感走向了依赖。对不通过拿掉测试的产品,诊断卡在哪个环节。
示例 1:AI 文案起草产品——试用数据好看为什么还是死了
场景:AI 文案起草产品上线第一周数据很好看——注册率高、首日试用率高、社交传播不错。但三周后二次使用率大幅下降。
长期成立五问诊断:
- 价值是第一次感知还是反复验证:偏第一次。"一秒生成一版营销文案"很惊艳,但不是每天的刚需。
- 用户为什么还会回来:回访理由弱。"还是在原来的文档里写更顺""复制来复制去很麻烦""团队协作还是在别的工具里"。
- 价值会累积吗:没有。每次生成都像第一次,没有记忆、没有偏好沉淀。
- 能进入工作流和预算吗:没有。用户没有形成"先打开你"的习惯,不会把它写进正式流程。
- 拿掉后会难受吗:不会,只是"有点可惜"。
诊断:团队把"第一次感知价值"误认成了"长期使用理由"。它解决了"试一下很惊艳",没有解决"下次为什么回来"。也许适合嵌入某种更大的写作工作流,但作为独立产品长期成立性不强。
示例 2:惊艳时刻 vs 回访理由对照练习
场景:用两个 AI 产品做对照练习。
| 产品 | 第一次为什么被打动 | 第十次为什么还会回来 | 长期成立判断 |
|---|---|---|---|
| AI 长文摘要 | 它能把长文快速变短 | 因为我每天要处理大量信息,它能接进研究和汇报流程 | ✅ 有回访理由 |
| AI 图片生成 | 它能一秒做出很酷的图 | ……因为我偶尔需要配图? | ⚠️ 回访理由弱 |
| AI 客服回复 | 它能自动生成回复草稿 | 因为它在我的客服系统里接住了版本迭代和团队协作,少了很多重复劳动 | ✅ 强回访理由 |
| AI 周报生成 | 它能自动汇总一周工作 | 因为我每周都要写周报,它省了我最讨厌的整理步骤 | ⚠️ 场景低频 |
练习收获:只要第二句写不出来或开始发虚,长期成立就很可疑。真正能长出来的产品,不是让人第一次惊叹"这也行",而是让人后来越来越自然地把它留在日常工作里。
示例 3:典型路径复盘——从首次体验很强到只剩口碑
场景:复盘一个 AI 产品走过的典型失败路径。
路径还原:
| 阶段 | 表现 | 团队判断 | 真实问题 |
|---|---|---|---|
| 首次体验 | 很强,用户惊呼"这也行" | 产品成立 | 能力跃迁被误认为持续价值 |
| 社交传播 | 不错,朋友圈有人转 | 增长有戏 | 传播驱动力是新鲜感 |
| 用户试一下 | 激活率高 | PMF 已到 | 激活 ≠ 留存 |
| 第二次频率下降 | DAU 降低 | 需要优化 | 没有找到回访理由 |
| 第三次想不起来 | 用户流失 | 竞争激烈 | 产品没有进入工作流 |
| 最后只剩口碑 | "挺厉害但不用了" | 市场问题 | 长期成立性没有建立 |
复盘结论:整个路径的断裂点不是"能力不行",而是"从惊艳到习惯的桥梁没有架起来"。团队需要在早期就把精力分配到回访理由建设上,而不是只优化首次体验。
诊断 Checklist:长期成立性快速自检
| # | 检查项 | 状态 | 说明 |
|---|---|---|---|
| 1 | 能一句话说清用户第十次回来的理由 | ⬜ | 不是"因为聪明" |
| 2 | 产品有价值累积机制 | ⬜ | 数据/偏好/模板/协作关系 |
| 3 | 用户已形成"先打开你"的习惯 | ⬜ | 不是偶尔想起来 |
| 4 | 产品进入了正式工作流 | ⬜ | 不只是"有时候用" |
| 5 | 产品进入了正式预算 | ⬜ | 不只是"试试看的花费" |
| 6 | 拿掉测试结果:用户觉得效率倒退 | ⬜ | 不只是"有点可惜" |
| 7 | 使用频率稳定或上升 | ⬜ | 不依赖活动和补贴 |
| 8 | 非首发期的自然新增 > 0 | ⬜ | 有口碑驱动 |
常见错误模式
错误 1:把试用成功当成 PMF
注册率高、激活率高、首日留存不错——团队就觉得 PMF 到了。但 AI 产品的首日数据天然好看,因为新鲜感强。真正的 PMF 要看第三周、第四周的回访行为。
错误 2:用功能迭代掩盖回访理由缺失
用户不来?加新功能。用户不用?加新场景。实际上用户不是因为功能不够才不来,而是因为没有找到"下次回来"的理由。功能迭代解决的是"能力上限",回访理由解决的是"日常嵌入"。
错误 3:只优化首次体验路径
投入大量精力优化 onboarding、首次生成质量、首次分享体验。这些都很重要,但如果只优化这条路径,产品会变成一个"漂亮的第一次"。更需要投入的是:第二次打开的理由、第三次使用的场景、第十次留存的黏性。
错误 4:用传播数据代替留存数据
转发率高、KOL 推荐、社交平台讨论量大——这些都是传播指标,不是留存指标。传播说明产品有"被讨论"的价值,但"被讨论"和"被使用"是两件事。
错误 5:混淆"好用"和"离不开"
用户说"这个产品挺好的"——这不等于用户说"我离不开它"。"挺好的"意味着可替代。"离不开"意味着有真实的路径依赖。产品需要从"挺好的"进化到"离不开"。
训练方法:六句话诊断法
挑一个你最近觉得"很有前景"的 AI 产品,写下这六句话:
- 用户第一次为什么会被打动
- 用户第十次为什么还会回来
- 这个产品的价值会不会随着使用而累积
- 它有没有进入真实工作流
- 它有没有机会进入正式预算
- 如果今天把它拿掉,用户会不会明显不舒服
把这六句话写清楚,你会更容易识别:这个方向到底是在制造一次漂亮的火花,还是在形成一团能持续燃烧的火。
关键信号监测指标
| 指标类别 | 具体指标 | 健康标准 | 警报阈值 |
|---|---|---|---|
| 回访 | 第 7 日回访率 | > 30% | < 15% |
| 回访 | 第 30 日回访率 | > 15% | < 5% |
| 嵌入 | 用户自定义设置比例 | > 20% | < 5% |
| 嵌入 | 工作流集成使用率 | 上升趋势 | 停滞或下降 |
| 累积 | 每用户平均历史记录数 | 持续增长 | 增长停滞 |
| 依赖 | 拿掉测试"明显不适"比例 | > 40% | < 15% |
| 传播 | 自然推荐率 | > 10% | < 3% |
使用说明:这些指标不是一次性检查,而是持续跟踪。一个长期成立的产品,应该在以上指标中大部分处于健康状态,且趋势向上。
形态判断决策框架
产品形态选项
| 形态 | 定义 | 适用条件 | 风险 |
|---|---|---|---|
| 独立产品 | 有独立入口和完整体验 | 场景足够大、用户认知明确 | 获客成本高、竞争激烈 |
| 系统模块 | 嵌入已有产品的一个功能 | 宿主产品有足够用户基础 | 依赖宿主、话语权弱 |
| 能力层 | 提供 API/SDK 让别人集成 | 技术壁垒高、场景分散 | 离用户远、难建立品牌 |
形态判断五问
- 用户是否知道在用你:独立产品用户知道,能力层用户可能不知道
- 你是否需要完整交互:如果需要完整交互→独立产品/模块;如果只是能力调用→能力层
- 获客路径是什么:独立产品需要自己获客;模块/能力层借宿主获客
- 商业模式是什么:独立产品按产品收费;模块按功能收费;能力层按调用收费
- 竞争壁垒在哪里:独立产品靠品牌和体验;模块靠深度集成;能力层靠技术差异化
形态选择常见错误
- 错误 1:场景太小就做独立产品——获客成本撑不起来
- 错误 2:技术很好但做成独立产品——应该先做能力层验证技术价值
- 错误 3:嵌入宿主但没有独立价值——宿主抛弃你时什么都没留下
- 错误 4:做了能力层但不关心终端用户——技术再好也不知道该往哪迭代
人机协作设计方案
协作模式选项
| 模式 | AI 角色 | 人角色 | 适用场景 |
|---|---|---|---|
| 助手模式 | 辅助完成 | 主导决策 | 高风险、高解释需求 |
| 协作者模式 | 分工完成 | 关键决策 | 中等风险、标准化程度高 |
| 代理模式 | 自主完成 | 异常处理 | 低风险、高重复性 |
协作设计 Checklist
| # | 设计项 | 状态 | 说明 |
|---|---|---|---|
| 1 | AI 角色已明确定义 | ⬜ | 助手/协作者/代理 |
| 2 | 人机分工边界已画清 | ⬜ | 哪些步骤 AI 做、哪些人做 |
| 3 | 交接点已设计 | ⬜ | 人→AI、AI→人的切换 |
| 4 | 异常处理已定义 | ⬜ | AI 做不了时怎么办 |
| 5 | 质量保障已设计 | ⬜ | 如何确保 AI 输出质量 |
回访理由深度挖掘
回访理由层级
| 层级 | 理由类型 | 持久性 | 示例 |
|---|---|---|---|
| L1 新鲜感 | "因为它很酷" | 最弱 | 试一次就不再来 |
| L2 功能价值 | "因为它能做X" | 弱 | 有替代品就走 |
| L3 效率价值 | "因为它省时间" | 中 | 省得不够多就不用 |
| L4 流程嵌入 | "因为工作需要它" | 强 | 已经形成依赖 |
| L5 网络效应 | "因为团队都在用" | 最强 | 切换成本极高 |
诊断方法:问用户"如果它明天消失了,你会怎么办?"
- "找个替代品" → L1-L2
- "会不方便,但能适应" → L3
- "会影响工作进度" → L4
- "团队会乱" → L5
累积性设计建议
| 累积类型 | 设计方式 | 黏性效果 |
|---|---|---|
| 数据累积 | 保存用户历史输入/输出 | 越用越懂用户 |
| 偏好累积 | 学习用户修改和选择模式 | 越用越准 |
| 模板累积 | 用户自建/收藏常用模板 | 切换成本高 |
| 协作累积 | 团队共享配置和知识库 | 组织依赖 |
| 习惯累积 | 形成固定使用路径 | 行为惯性 |
使用说明:至少在 2 种以上累积类型上有明确设计,产品才可能有长期黏性。
工作流嵌入诊断
嵌入深度层级
| 层级 | 描述 | 信号 | 产品状态 |
|---|---|---|---|
| L0 未嵌入 | 用户不知道有这产品 | 无使用 | 不存在 |
| L1 偶尔使用 | 用户想起来才用 | 低频、无规律 | 边缘 |
| L2 定期使用 | 用户有固定使用时机 | 中频、有规律 | 有位置 |
| L3 默认动作 | 用户先打开你再开始工作 | 高频、习惯性 | 核心 |
| L4 不可或缺 | 拿掉后工作明显受影响 | 嵌入流程 | 必需 |
诊断方法:观察用户的第一个动作。如果用户的第一个动作是打开你的产品,说明至少在 L3。如果用户完成任务后才想起来"哦对,还有这个工具",说明在 L1。
Capabilities
Install
Quality
deterministic score 0.48 from registry signals: · indexed on github topic:agent-skills · 56 github stars · SKILL.md body (7,791 chars)