员工提什么我就做什么，是我做企业 AI 落地踩过的第一个坑
我最开始做企业 AI 服务时，判断需求的标准很直接：业务部门提出了一个问题，这个问题看起来又能用 AI 或自动化解决，那就去做。
有人想自动整理表格，有人想生成图片，有人想分析数据，也有人希望把一段人工流程做成工具。只要需求足够具体，我就会开始考虑模型、工作流和系统实现，也很容易把「完成了多少需求」当成 AI 岗位创造价值的证明。
做过一批需求以后，我逐渐发现：员工提出的通常是他们站在各自岗位上看到的局部痛点。痛点可能完全真实，却不一定值得开发；工具可能做得出来，却不一定有人持续使用；功能可能已经完成，却很难回答它改变了哪一段业务。
员工提出的 AI 需求，是理解业务现场的线索，不是项目立项的依据。
真实痛点不等于开发项目
员工每天直接面对具体工作，最容易发现哪里麻烦、哪里重复、哪里经常出错。因此，当员工问「这件事能不能用 AI 做」，当然值得继续了解。
但把一个岗位上的痛点放回完整流程，情况往往会变得不同。以整理表格为例，局部动作之外可能还有这些问题：
- 上游提供的数据格式持续变化；
- 不同部门对同一个字段的定义不一致；
- 整理完成后还要交给另一位同事继续汇总；
- 最终结果涉及金额或正式核算，需要业务责任人复核。
如果只盯着「整理表格太麻烦」，很容易马上做出一个脚本。可上游数据仍不稳定，下游仍要重新处理，责任边界也没有改变。局部动作可能更快了，整个流程的交接、复核和返工却没有减少。
还有一些任务，现成 AI 工具配合人工检查就足够解决。如果每个小需求都由 AI 岗位单独开发、部署和维护，需求方得到一次便利，团队却留下一个需要长期解释、修改和维护的工具。
所以我现在会把两件事分开判断：痛点是否真实，决定要不要继续了解；是否值得开发，决定企业要不要正式投入。前者可以来自员工的直接感受，后者必须回到完整业务流程。
「能不能做」只是四道判断中的一道
做 AI 应用的人很容易先回答技术问题：模型能不能识别，数据能不能接入，工作流能不能跑，能不能较快做出 Demo。这些问题很重要，但它们只是在回答「能不能做」。
一个需求要不要进入正式开发，我至少会继续看四件事。它们够不上一张精确的评分表，但每一个都不能跳过。
业务价值够不够
先不谈 AI，先问问题解决以后，企业究竟会得到什么。它可能影响增长，打通关键业务卡点，稳定减少人工成本，或者降低合规、客诉和经营风险。
如果一个需求说不清它改善了什么，只能说「用了 AI 会更方便」，我不会因为技术上容易就立刻开发。小需求同样有价值，只是它可能更适合成本更低的解决方式。对个人工作有帮助，不等于值得公司为此立项。
是否具备执行条件
痛点真实，不代表现在已经适合 AI 化。还要确认这个动作是否高频发生，输入能否相对稳定地提供，输出有没有明确标准，以及能不能先用少量真实样例试跑。
例如，商品信息写作看起来很适合做成 Skill。但如果没有真实商品资料、人工确认过的合格输出、平台规则和实际使用人的验收标准，仅仅做出一个会生成文案的 Skill，并不能证明业务问题已经解决。更合理的做法，是先拿真实样例由 AI 岗位和业务人员一起试跑。
出了问题谁负责
只要需求涉及金额、合同、客户承诺、正式核算、合规判断或者对外发布，就不能只讨论准确率。必须说清谁复核结果，哪些步骤只能由 AI 提供初稿，数据缺失或判断不确定时由谁接管，以及哪些决定不能交给 AI 独立完成。
这些问题没有答案时，功能越自动化，风险反而可能越大。
做到什么才算有效
「开发完成」不是验收标准，「Demo 能运行」也不是。还要回答：谁会实际使用，在什么工作节点使用，输出是否被下游采用，连续运行时如何处理异常，最终改善了什么业务结果。
功能做出来、上线、采用、稳定运行和产生结果，处于不同的证据阶段，不能互相替代。如果一个项目只能证明「做出来了」，它最多证明技术实现完成，还不能证明企业应该继续投入。
筛选以后，不只有「做」或「不做」
需求筛选不能变成 AI 部门单方面拒绝业务。员工提出的想法仍然是理解现场的直接入口，只是这些想法不应全部进入同一条开发队列。
我更倾向于把需求分到四种处理路径中：
- 员工自助。 任务只影响个人工作，风险低，不依赖复杂系统和敏感数据，而且现成工具已经能解决主要问题。AI 岗位提供基础培训、示例和人工确认边界即可。
- AI 岗位辅助。 需求有一定复用价值，但暂时不值得建设系统。可以通过整理输入、拆解任务、形成 SOP、模板或轻量 Skill，先帮助业务跑通真实样例。
- 正式立项。 需求已经影响多人协作或关键业务流程，并且业务价值、数据、权限、责任人和验收方式都能说清，才进入完整的开发、测试、部署和维护流程。
- 暂缓或不做。 业务价值不够、数据和流程条件不足、没有责任人，或者任务本就不该由 AI 承担时，暂停也是明确的项目决策。
例如，偶尔生成一张营销图片，使用现成工具可能已经足够；当需求进一步涉及设计模板沉淀、销售自助生成、产品资料维护和历史参数追溯时，它才从一次生成任务变成多角色协作流程，值得进一步设计入口、权限、数据和审核。
反过来，一个需求即使同时涉及客户资料、销售记录、管理看板和 AI 建议，如果数据来源、权限、维护责任和验收方式都不明确，继续开发也只是在把多个未解决的问题封装进更大的系统。暂停、拆分和重新定义范围，通常比继续堆功能更负责任。
AI 岗位的价值是筛选和验证
企业 AI 岗位很容易变成内部接单员：业务提出需求，AI 岗位负责实现，做完一个再接下一个。工具越来越多，工作越来越忙，但没有人持续追问它们是否被使用、是否进入真实流程、由谁维护，以及带来了什么可以验证的变化。
企业 AI 岗位不是来证明所有问题都能用 AI 解决的。它需要理解业务、筛选需求、选择承接方式，并和业务负责人一起验证项目有没有进入真实流程。
面对一批 AI 需求时，可以先给需求记录补上五项信息：
- 它解决什么业务价值；
- 当前是否具备执行条件；
- 出了问题由谁负责；
- 做到什么才算有效；
- 它应该由员工自助、AI 岗位辅助、正式立项，还是暂缓或不做。
这五项说不清的需求，先不要进入开发。企业真正需要的是更少、但值得跑通的 AI 需求。