AI Product Growth 101｜01｜Wedge Workflow：先选一个值得被接管的工作流
很多 AI 产品从一句话开始：
“我们能不能给这个页面加一个 Copilot？”
这句话的问题，不是 Copilot 一定没用。问题是它跳过了更重要的一步：用户到底想把哪一段工作交出去？
一个空白聊天框可以演示很多能力，却很少天然对应一项工作。
用户打开它，还要自己想清楚目标、准备上下文、组织提示词、判断结果、修正错误，再把输出搬回原来的工具。
看起来 AI 在帮忙，实际上用户成了 AI 的项目经理。
从能力清单转向工作流
模型能力通常用动词描述：总结、生成、分类、搜索、规划、调用工具。
用户的工作却不是孤立动词，而是一条有起点和终点的流程。
例如，“生成销售邮件”只是一个能力。
“根据最近一次客户会议、CRM 阶段和产品使用情况，写出跟进邮件，交给销售确认后发送”才是一条工作流。
后者有输入、有上下文、有验收标准，也有明确的下一步。
AI 产品应该先找到一条可以闭环的工作流，再决定模型在里面承担什么角色。
这并不是抽象的“回归用户价值”。OpenAI 在面向 Agent 团队的实践指南里，给出了三个更具体的适用信号：任务需要复杂判断、原有规则越来越难维护，或者工作高度依赖非结构化数据。它也明确提醒，如果确定性方案已经够用，就没有必要为了使用 Agent 而使用 Agent。
这个边界很重要。AI 不是需求成立的证据，只是一种成本结构、失败方式和交互方式都不同的实现手段。
五个筛选条件
可以用五个问题判断一个切口是否值得做。
1. Pain：不做会不会付出代价
用户嘴上说“挺麻烦”，不代表这是痛点。
真正的痛点通常有可见代价：任务被拖延、收入损失、错误返工、响应变慢，或者需要雇人填补。
如果用户今天已经选择不做这件事，AI 把它做得便宜一点也未必有价值。
2. Frequency：它会不会重复发生
高频工作流更容易形成习惯，也更容易收集反馈。
频率不一定是每天。季度报税频率低，但代价高、流程稳定，也可能成立。
关键是任务会再次出现，而且下一次的产品体验能利用上一次积累的上下文。
3. Verifiability：结果能不能被判断
“写得更有创意”很难稳定验收。
“提取合同中的续约日期，并链接到原文位置”就容易得多。
早期产品应优先选择能快速判断对错、好坏或是否完成的任务。可验证性越高，评估和改进闭环越快。
4. Context：你能不能拿到关键上下文
模型不是不知道怎么写，而是不知道为谁、在什么约束下写。
如果完成任务需要用户每次手动粘贴十份资料，产品很难留下来。
好的切口往往靠近已有数据：代码仓库、客服记录、CRM、文档库、交易记录或团队工作台。
上下文获取本身，就是产品的一部分。
5. Delegability：用户愿不愿意交出控制权
能力可行，不代表用户愿意委托。
改一段内部文案，风险很低。自动退款、修改生产数据库、向客户承诺交付日期，风险很高。
同一条工作流也可以分级：先给建议，再生成草稿，再一键执行，最后才是条件满足时自动执行。
最好的早期切口，不一定能完全自动化，但应该能逐步扩大委托范围。
一个简单评分
给每个候选工作流按 1 到 5 分评估：
Opportunity = Pain × Frequency × Verifiability × Context × Delegability
乘法比加法更残酷，也更接近现实。
如果可验证性接近零，其他项再高，团队也很难知道产品是否在变好。
如果委托意愿接近零，技术自动化率再高，用户也只会把它当玩具。
这个分数不用于制造精确答案。它用于暴露团队的假设。
不要一开始接管整份工作
“替代一个岗位”通常不是好切口。
岗位由很多任务组成，不同任务的频率、风险、上下文和验收方式完全不同。
更好的方法是找到其中一个边界清楚的环节。
不是“替代产品经理”，而是“把访谈记录转成带证据链接的机会清单”。
不是“替代律师”，而是“标出合同里偏离公司标准条款的段落”。
不是“自动做销售”，而是“在客户出现明确使用信号时生成下一步建议”。
小切口不是小市场。
它是进入真实工作流的一扇门。
小结
选 AI 产品方向时，不要先问模型能做什么。
先问：哪一段工作让用户反复付出代价，结果可以验证，关键上下文能够获得，而且用户愿意逐步交给系统？
找到这条工作流，你才有了产品的起点。
下一篇，我们会讨论怎样用原型验证它。原型的任务不是证明团队能做出来，而是尽快发现用户会不会真的把工作交过来。