夜雨聆风“我们也做个 AI 助手吧。”
老板在群里丢下一句话，顺手转来一个同行的 Demo。
半小时后，产品经理开始画聊天框，工程师开始选模型，所有人都在讨论 RAG、Agent 和知识库。
但没人问：这个助手到底替谁，在什么时候，完成哪个动作？
这类项目最危险的地方，是它特别容易做出东西。
接个模型，上传几份文档，再套一个对话界面，几天就能演示。老板问什么，它都能答上几句。会议室里一片叫好，项目顺利进入下一阶段。
然后三个月过去了：
员工试用两次，还是回去搜文档；
回答看起来不错，却没人敢直接采用；
数据接不全，业务说“这不是我们真实的流程”；
团队不断修提示词，却说不清项目到底有没有效果。
最后，大家把失败归结为“模型还不够稳定”。
其实很多 AI 项目不是模型做不出来，而是从第一天起，团队就没有定义自己要做成什么。
下次再听到“做个 AI 助手”，先别打开 IDE。把下面 7 个问题拿出来，逐个问清楚。
1. 到底是谁，会在什么时刻使用它？
“给公司员工用”不算答案。
公司员工可能是销售、客服、财务，也可能是刚入职的新人。他们面对的问题、掌握的信息和能够承担的风险完全不同。
一个合格的回答应该具体到：
一线客服在收到用户退款申请、无法判断是否符合规则时使用。
只有明确了人和时刻，你才能判断 AI 应该出现在哪里：是一个聊天框、一枚按钮，还是直接嵌进现有工单系统。
如果连第一个真实用户都说不清楚，先别做。
2. 没有 AI 时，他现在怎么完成这件事？
不要先问“AI 能做什么”，先看人现在怎么工作。
他要打开几个系统？查哪些表格？问谁确认？一次要花多久？最容易卡在哪一步？
比如客服处理退款，真实流程可能是：
在工单里确认订单号；
去后台查看购买时间和商品状态；
翻退款政策；
遇到边界情况，在群里询问主管；
回到工单组织回复。
这时你会发现，他需要的可能不是一个“无所不知的聊天机器人”，而是在工单页自动汇总订单信息、匹配退款规则，并标出需要主管确认的异常。
先画出旧流程，才能知道 AI 应该改变哪一步。
3. AI 具体要替用户改变哪个动作？
“提高效率”“赋能客服”“降低成本”都不是可以开发的需求。
你需要把目标压缩成一个可以观察的动作：
把查找三份资料，变成自动给出相关段落；
把手写一封回复，变成审核并发送草稿；
把每天人工整理 200 条反馈，变成只处理聚类后的 10 个问题；
把无法判断的工单，自动交给正确的负责人。
最实用的句式是：
当____发生时，可以用它把原来的，变成____。
这句话填不完整，就说明“AI 助手”仍然只是一个想法，不是一个需求。
4. 它可以犯什么错，绝不能犯什么错？
所有 AI 都会犯错。真正的问题不是能否做到 100% 正确，而是：哪种错误可以被发现和修正，哪种错误会直接造成损失？
推荐错一篇内部文档，用户可以重新搜索；擅自承诺退款、编造合同条款或泄露客户信息，后果完全不同。
在开发之前，至少列出三类边界：
可以容忍：错误容易被发现，也容易撤销；
必须确认：AI 可以给建议，但需要人批准；
严禁发生：AI 不应执行，甚至不应接触相关数据。
这一步会直接决定产品形态。
低风险任务可以自动完成；中风险任务应该“生成草稿＋人工确认”；高风险任务则只能检索、提示或转交。
别等上线以后，才第一次讨论责任。
5. 它需要的数据究竟在哪里？
“我们有很多数据”通常是一句危险的话。
真正要问的是：
数据存在哪个系统？
是结构化字段，还是散落在文档和聊天记录里？
内容是否完整、最新、彼此矛盾？
谁拥有访问权限？
哪些数据可以送进模型，哪些绝对不能？
很多团队花一周做出 Demo，接着花三个月才发现：最关键的数据拿不到，拿到的数据不能用，能用的数据也没有人负责维护。
如果数据来源和负责人没有确定，Demo 里的好效果很可能只是幻觉。
6. 谁来确认结果，谁来处理异常？
AI 给出答案，不等于工作已经完成。
谁来判断答案可不可以用？谁有权点击确认？模型没把握时交给谁？出错后，谁负责修正数据、规则或流程？
如果答案是“到时候业务会看”，这个项目大概率会停在试用阶段。
业务人员不会因为公司上线了 AI，就自动多出一项审核 AI 的工作。你必须把确认和异常处理设计进原来的流程，并明确责任人。
一个能上线的系统，不只要设计“顺利时 AI 做什么”，还要设计：
AI 不知道怎么办时，人怎么接得住。
7. 上线后，哪个数字变了才算成功？
“上线一个 AI 助手”不是结果，只是交付物。
准确率也不一定是最终指标。一个准确率 95% 却没人使用的系统，没有创造任何价值。
好的指标应该回到第一线的工作变化：
单张工单的平均处理时间，从 8 分钟降到 5 分钟；
新客服独立上岗时间，从两周缩短到一周；
需要主管介入的退款工单，从 30% 降到 15%；
销售每周整理客户记录的时间，从 3 小时降到 30 分钟。
同时设一条风险指标，例如错误承诺率、人工撤回率或用户投诉数。
没有成功指标，项目就会变成无限优化：模型永远还能更聪明，提示词永远还能再改一版，但没有人知道什么时候应该继续、停止或换方向。
7 个问题问完，“AI 助手”才会变成一个项目
还是用前面的客服场景。
最初的需求只有一句：
做一个公司内部的 AI 客服助手。
问完 7 个问题后，它应该变成：
当一线客服收到退款工单时，系统自动读取订单状态并匹配最新退款规则，生成一份带依据的回复草稿；客服确认后才能发送，边界情况自动转给主管。首期目标是把平均处理时间从 8 分钟降到 5 分钟，同时不提高错误承诺率。
前一句可以做出无数个 Demo。
后一句才知道该接什么数据、做什么界面、由谁确认，以及上线后如何判断成败。
这 7 个问题也不需要开三天战略会。
找一个真正做这项工作的人，用 30 分钟走一遍真实流程。如果团队连这些问题都答不上来，最正确的进度不是“先做个原型看看”，而是暂缓开发，先把业务现场看明白。
AI 把做出 Demo 的成本降得越来越低。
这听起来是好事，但也意味着我们可以用更快的速度，做出更多没人需要的东西。
所以，老板下次再说“做个 AI 助手”，别急着讨论模型。
先把这 7 个问题发进群里。
真正决定项目能不能上线的，往往不是 AI 会不会回答，而是团队有没有把问题问对。
你见过的 AI 项目，最常卡在哪一个问题上？
欢迎在评论区聊聊，也可以把这份清单转给那个刚刚说“我们也做个 AI 助手”的同事。