我最近给自己的跨平台发布流程做自动化开头也想得很大七个平台一起接、草稿一起建、网页一起开。结果很快就乱了。头条后半段排版出错草稿箱堆了重复项浏览器内存也被一堆页面吃掉。真正把流程跑顺是从一篇文章、一个平台开始提取正文生成草稿补标题和标签提交后打开公开页再把无用草稿和页面清掉。这个小闭环跑通后第二个平台才有东西可复制。所以我现在理解的“第一仗”很简单先选一个真实、高频、有反馈、有业务主人的小流程让 AI 真正改变其中一个动作。下面的五个条件是我从这类实操里整理出的筛选表不是行业统一标准。为什么我不建议第一步就做大项目“企业级平台”“全系统打通”“所有部门一起用”听起来很完整却会同时放大几件麻烦。需求容易被汇报逻辑带着走最痛的现场问题反而被包装掉技术团队忙着证明模型能做什么没人追问谁每天使用、哪个动作变快项目横跨很多部门最后每个人都参与却没人持续给反馈。模型接上、页面做出来只能说明 Demo 能跑。真实流程里有人愿意继续用才说明方向可能是对的。第一仗的任务不是证明公司有多重视 AI而是验证一种新的协作方式能不能跑通。闭环没跑通范围铺得越大返工越贵。第一个试点不要大要真第一个试点我最看重的不是规模和炫技而是真实。所谓真实是它本来就在日常业务里发生不是为了展示临时拼出来的场景。它应该是企业每天都在面对的具体动作。比如客户线索来了之后谁判断优先级售后问题进来之后谁分类、谁跟进、谁判断是否升级销售写报价单时哪些信息每次都要重复整理门店日报出来以后谁看异常、谁判断问题、谁安排下一步动作项目进度同步时谁整理会议纪要、谁追踪待办、谁提醒风险这些事情看起来不大但它们是真流程。每天发生有人负责有输入有输出有反馈也有改进空间。我会优先从这种地方开始。一个流程跑穿后团队才知道怎么协作、怎么迭代哪些东西值得留下。什么流程适合做第一个 FDE 试点我会先看五件事。第一高频第一个试点最好每天或每周都在发生而不是一年才出现两次。原因很简单频率越高反馈越快。反馈越快FDE 才能快速迭代。如果一个流程几个月才发生一次第一版做出来后很久都等不到反馈团队只能靠猜。第一批试点优先选高频流程会更容易暴露问题。比如销售线索整理、客户回访记录、售后问题分类、报价单生成、日报周报分析、订单异常跟进、项目待办追踪。这些流程未必高级但每天都发生。只要能优化一点点反馈就会很快回来。低频流程可以以后做没必要拿它验证第一轮协作。第二输入和输出清楚一个好试点最好能说清楚四件事输入是什么输出是什么中间谁处理处理标准是什么。如果这些问题说不清楚就先不要急着上 AI。比如“提升销售效率”太虚。这个目标听起来正确但没法直接做。销售效率包含线索获取、客户跟进、报价、合同、回款、复购任何一个环节都可能影响效率。但如果改成“把客户聊天记录自动整理成客户需求、预算判断、意向等级和下一步跟进建议”就清楚很多。输入是聊天记录。输出是结构化线索信息。使用者是销售。判断标准是销售是否愿意拿它来跟进客户。这才是一个流程。“提升销售效率”是愿望结构化线索并交给销售跟进才是流程。前者很难验收后者可以直接放回工作里试。第三有真实业务主人试点最好有一个明确的业务主人。这个人不一定是老板也不一定是部门负责人但他必须真实拥有这个流程。他知道现在怎么做哪里麻烦什么结果算有用哪些地方不能乱改也愿意每天给反馈。没有这个人技术团队很容易按自己的理解猜业务。很多细节不在系统和流程图里而在一线人员的习惯、判断和默认规则里。比如同样是客户线索什么叫高意向什么情况要马上跟进什么情况可以延后什么客户看起来很热情但其实成交概率低这些东西不是模型凭空知道的也不是需求文档能一次写清楚的。它需要业务主人不断校准。如果暂时找不到业务主人我会先停一下。不是技术做不了而是反馈链路还没建立。第四短周期能看到变化第一个试点不该等很久才知道有没有用。它应该在比较短的周期里看到第一版结果。不是最终完美版本而是能放回真实流程里试用的东西。更稳的节奏是分阶段验收先尽快跑出能进入真实流程试用的可用原型再根据反馈形成稳定流程和可复用模板最后根据实际采用率、业务结果和组织准备度判断是否扩大推广。不同企业、系统和流程的复杂度不一样阶段长度不能一刀切。重点是尽快得到真实反馈。如果一个项目一开始就规划半年、一年期间只有汇报没有真实使用那它很容易被组织惯性拖死。需求会变负责人会变优先级会变预算也会变。更合适的做法是把一个小流程尽快推到真实环境让问题暴露出来再修正。越早进入真实流程越早知道哪里错了。越晚进入真实流程越容易在错误方向上越做越复杂。第五有沉淀价值第一个试点还要看能不能留下下次能用的东西比如 SOP、提示词模板、数据字段、业务规则、自动化脚本或评估标准。一个试点如果完全不可复用只能服务一个极其特殊的场景它不是不能做但不适合作为第一仗。比如销售线索整理这个流程如果做得好后面可能复用到客户回访、售后工单、招商线索、招聘简历筛选。它们的业务对象不同但底层都有“非结构化信息 → 结构化判断 → 下一步动作”的模式。这就是沉淀价值。一个只负责展示的样板间很难复制。能留下一套方法的试点才适合继续扩大。三类试点先删掉选试点时不只要知道什么该选还要知道什么该删。第一批项目如果选错对象后面再努力也容易跑偏。第一类领导展示型项目这类项目的目标是“看起来很 AI”。做一个大屏做一个聊天机器人做一个炫酷页面做一个可以在会议上演示的智能助手。演示的时候很热闹但会后没人用。这类项目的问题不在于不能做而在于它经常脱离真实流程。我会看真实业务人员会不会在日常工作里继续使用它而不是演示时有没有掌声。如果一个东西只能在汇报时打开平时没人碰那它对 FDE 来说价值很有限。只能在汇报时打开的东西暂时还不是一个可用流程。第二类技术炫技型项目这类项目一上来就堆概念多 Agent、知识图谱、复杂自动化、全系统打通、端到端智能决策。听起来很先进但如果没有真实流程牵引很容易变成技术堆料。我的顺序会反过来先解决一个业务动作再决定需要多少技术。如果一个简单的规则、一个表单、一个脚本、一个半自动流程就能解决问题就不要一上来搞复杂 Agent。复杂技术不是不能用但它必须服务于真实流程而不是反过来让业务流程配合技术表演。别自动化垃圾流程。也别为了显得高级把一个简单问题复杂化。第三类组织跨度过大的项目有些项目一开始就横跨销售、财务、供应链、生产、客服。每个部门都有诉求每个系统都有历史债每个负责人都有不同 KPI。这种项目不是不能做但不适合第一仗。因为它的协调成本太高反馈链路太长责任边界太模糊。FDE 还没来得及验证真实价值就会先陷入组织协调。第一仗要小、反馈要快、责任人要明确。目标不是覆盖全公司而是验证新的协作方式。等一个流程跑通了有了方法、有了资产、有了信任再扩大范围。这才是更稳的路径。FDE 试点不是外包需求单这里还要区分一个关键点FDE 试点不是传统外包项目。传统外包的启动方式通常是企业提出需求服务商报价开发交付企业验收。这个模式的问题是业务和工程是分开的。企业以为自己已经把需求说清楚了服务商也以为自己只要按需求做完就行。但真实业务里的很多问题往往不是一开始就能说清楚的。FDE 不是这样。FDE 的启动方式更像是业务现场暴露问题FDE 跟着流程走一遍和业务人员一起重构动作做出原型放回真实场景使用根据反馈迭代再把有效部分沉淀成资产。这更接近共创而不是把需求文档扔给开发团队。我在这篇里暂时把两种能力叫作 Delta 和 Echo。这只是我自己的工作标签不是行业标准Delta 贴近业务现场负责识别变化和真实问题Echo 负责工程实现把有效解法系统化。可以是一人也可以是两个人但业务判断和技术实现要保持同一条反馈链。所以企业不能只当甩手掌柜。如果企业只是扔一个需求文档然后等 FDE 交付那还是外包逻辑。FDE 要求企业参与尤其是第一批试点业务负责人必须进场。业务不进场技术团队很快又会回到猜需求的老路。第一个试点成功以后才谈复制第一个试点的意义不只是证明“这个项目能做”。它还要验证协作方式能不能跑通业务人员愿不愿意参与结果能不能衡量以及下一个场景能不能复用。如果第一个试点只是做出了一个孤立工具那价值有限。工具本身可能有用但它没有让组织变聪明。如果第一个试点沉淀出一套流程方法那企业才真正迈出了 FDE 的第一步。比如一个售后工单分类助手如果只是做成一个页面让客服偶尔用一下那它只是一个工具。但如果在这个过程中企业沉淀出了工单分类标准、升级规则、话术模板、质检指标、异常预警机制以及后续客服培训材料那它就不只是一个工具了。它变成了资产。这也是第一个试点不能随便选的原因。它既是一个项目也可能成为第一批组织资产的来源。写在最后我现在会先找一个真实流程让业务和工程一起把它跑通再决定要不要扩大。第一仗不用壮观但必须让团队看见真实使用、真实反馈和可以复用的东西。否则买再多工具也只是把 AI 放在业务旁边。本文来自「维天说」全平台同名。我会持续分享普通人能用上的 AI 工具、内容工作流和真实实践欢迎联系我一起交流 AI。