项目越讨论越大，通常是范围没有被定义
企业第一次做 AI，常常从一个具体问题开始：客服想减少重复回答，销售想更快准备方案，管理者想看到异常提醒。讨论几轮之后，需求会自然扩张到知识库、客户系统、审批流程、外呼和报表。每一项都听起来合理，但它们需要的资料、权限、接口和责任人并不一样。把所有事情绑在一起，最后可能没有一项能真正上线。
范围失控还有一个隐蔽表现：团队不断修改演示，却没有一份正式的任务清单。今天演示的是客服问答，明天变成销售方案，后天又要求 AI 自动改客户状态。项目成员都很忙，却没人能回答第一阶段交付的具体结果是什么。企业 AI 要先服务一个可确认的工作变化，而不是把所有想象中的能力一起装进系统。
第一阶段要写清楚服务谁、处理什么任务
范围说明至少包括使用部门、岗位、任务入口、输入资料、输出结果和完成标准。比如只服务售前团队的方案初稿，输入是客户需求记录和当前产品资料，输出是内部草稿，不能直接发送给客户。这样的定义比“建设销售 AI 助手”更容易开发、培训和验收，也能让员工知道系统暂时不能做什么。
任务边界还要落到数量和条件。一个项目可以先支持三种高频问法、一个资料库和一个内部入口，低频问题进入人工队列；也可以先服务一个团队，等结果稳定后再扩展。第一阶段不必追求面面俱到，重点是让一条链路真正跑通，并且每个参与者都知道出了问题在哪里停。
- 明确第一阶段的岗位、任务、入口、资料和输出格式。
- 列出暂不支持的部门、系统、风险场景和自动执行动作。
- 写明扩展前需要满足的样本量、质量和责任条件。
不做清单不是拒绝需求，而是给需求排出顺序
项目里出现暂不处理的需求很正常。关键是说明原因和未来条件。某个系统暂时没有稳定接口，可以等数据字段确定后接入；某类合同风险高，可以先做检索和草稿，不做自动审批；某个部门资料没有负责人，可以等资料治理完成后再开放。把原因写出来，业务方更容易接受，也不会反复在会议里提出同一件事。
还可以给每个新增需求设置进入条件：是否属于原定用户，是否复用已有资料，是否改变权限，是否新增对外动作，是否影响验收时间。满足条件的需求进入当前迭代，超出条件的需求进入下一阶段评估。这样项目既不会僵化，也不会因为一句“顺便加上”改变整个交付计划。
范围变化必须伴随责任、时间和成本变化
新增一个部门，不只是多几个账号，还会带来新的资料口径、权限规则、培训对象和评测样本。新增一个自动动作，也不只是加一个按钮，还要定义失败处理、人工确认和日志记录。如果范围变化后交付日期、维护人和验收指标都不变，项目压力只会被转移到最后一周。
每次变更可以用一页变更记录说明影响：增加了什么，取消了什么，需要谁参与，哪些测试要重做，是否改变预算和上线时间。业务负责人据此做决定，技术和交付团队也能按照同一份记录工作。范围管理的目标不是限制业务，而是让每一次扩展都被看见、被讨论、被负责。
验收要证明边界内可用，边界外不会乱做
试点验收除了测试正常任务，还要测试被明确排除的场景。让员工询问暂不支持的部门、缺少资料的问题和要求直接对外发送的动作，观察系统是否给出清楚提示、转人工或拒绝执行。若 AI 在边界外仍然生成一段很确定的答案，说明范围只写在文档里，没有进入系统规则。
项目结束时留下范围版本、已交付任务、暂不支持清单、扩展条件和下一阶段建议。这样企业下次评估时能从真实结果出发，而不是重新从“AI 能不能做”开始争论。一个边界清楚、能持续扩展的项目，通常比一开始功能很多但没人敢用的系统更有生命力。
实际交付中，边界还要照顾员工的工作节奏。系统提示暂不支持时，最好同时给出人工入口、资料补充方式和责任人，而不是只弹出一句拒绝。这样员工不会为了完成任务绕开系统，也能把新需求带回下一轮评估。验收记录则要保留正常样本和拒答样本，证明系统既能完成该做的事，也能在不该做的地方停下来。
边界说明还可以写成员工看得懂的几句话，放在入口和操作手册里。比如“可以帮你查资料和生成内部草稿，但不能替你审批、报价或向客户承诺”。越靠近实际动作，越能减少误用。等第一阶段运行稳定后，再根据真实任务决定哪些范围值得扩大，不能把未来可能做到的能力提前当成今天已经交付的能力。
要点总结
- 不建议。先选一个任务链路清楚、资料稳定、有业务负责人和人工兜底的范围，更容易得到可验证结果。
- 把暂不处理的原因、风险和扩展条件写清楚，反而能说明项目是按交付能力和业务边界设计的。
- 不一定。先判断是否复用原有资料和流程，若改变权限、风险或验收范围，就应重新评估时间和责任。
参考来源说明
本文围绕“企业 AI 立项先把“不做什么”写清楚，项目才不会越做越大”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。