先分清两条路：需求拉和技术推
找 AI 场景有两条路径。技术推是拿着模型能力找落点，「我们有长文本能力，能做点什么」；需求拉是从用户的麻烦出发，「这个岗位上的人每天被什么事折磨，AI 能不能接一段」。我见过挂掉的项目，十有八九是技术推：团队先有了锤子，再满世界找钉子，最后做出来的东西演示很惊艳，没人持续用。技术推不是不能用，但它产出的每个候选场景都必须回到用户那里验证，不能内部评审通过就算数。
需求拉的三个矿源
我自己的经验是盯三个地方。一是用户的抱怨和 workaround，一个用户愿意忍受很笨的办法也要解决问题，说明痛点是真的——大量运营人员把 Excel 导出来手动贴进 ChatGPT 洗数据，这个「体外循环」本身就是场景信号。二是人力密集的重复劳动，去算一个流程里人小时花在哪，客服、审核、标注、初稿写作这些环节天然适合让 AI 先接一棒。三是已经被验证但供给很差的需求，外贸小商家要写多语言营销文案，原来只能找外包按篇计费，Jasper 就是从这个缝里长出来的。三个矿源的共同点：你看到的都是行为证据，不是用户的口头愿望。
技术推的正确用法：能力扫射加人效校验
技术推也有规范动作。把模型当前稳定可用的能力列成清单——总结、翻译、抽取、改写、代码生成、多轮对话——然后拿目标行业的流程一条条对照，每对一条就问「这一步交给模型，人效能提升几倍」。注意是稳定可用的能力，不是发布会上演示的能力，demo 里行和生产环境行之间隔着一条鸿沟。扫出来的候选场景同样要过用户验证这一关，流程上一步都不能省。
筛选：频率、痛点强度、AI 解决度
挖到一堆候选后，我用三个维度打分。频率决定使用习惯能不能养成，痛点强度决定付费意愿，AI 解决度决定现在能不能做，而不是两年后能不能做。Kimi 早期押长文本，赌的就是「读研报、论文、财报」这个场景：频率够高、原来没有好工具、长上下文能力刚好成熟，三个维度同时成立。三个维度里我权重给最高的是频率，低频高痛的场景容易做成一锤子买卖，用户用完一次就走，留存撑不起一个产品。
筛选也不是一次性动作。模型能力每个季度都在跳变，三个月前被「AI 解决度」卡掉的场景，可能现在就能做了。我的习惯是维护一个「暂缓清单」，记下那些痛点真实但技术还没到位的场景，每次大模型有重要升级就翻出来重估一遍。从这个清单里捡回来的场景，往往比临时头脑风暴出来的质量高得多。
最后一步：画边界
场景确认后还有一步常被跳过：想清楚 AI 在这个场景里做多深。是给人打下手——出草稿、给建议，还是端到端替人干活？这个边界直接决定交互形态、准确率门槛和责任划分。同样是「AI 写代码」，Copilot 画的是补全和建议的边界，决定权始终在工程师手里；一些 Agent 类产品画的是「给个需求直接交付 PR」的边界，对准确率的要求就完全不是一个量级。边界画错了，后面所有设计都是在错的地基上盖楼。