不整体改造，从一个场景切进去
已经跑起来的公司，最怕的是“上系统”。流程本来就复杂，一次大改造，业务停三个月，改完还不一定好用。 我们的做法相反：挑一个高频、边界清楚、做错了能兜住的环节，先跑通一个，再复制第二个。 整个过程由 FDE（Forward Deployed Engineer）进到业务现场，把 AI 接进真实流程——跑通了才算交付，不是交一套系统就撤。
先说为什么大部分“公司级 AI 项目”没结果
责任没落到人
“公司要搞 AI”这句话经过三层传达，到执行层就变成“你去研究一下”。没人对这个场景的结果负责，试点就变成试用，试完没有下文。
数据还没就位
想让它自动生成报表，结果数据一半在 ERP、一半在 Excel、还有一半在微信群里。先把数据通路打通，比换模型重要得多。
指标定错了
“提效 30%”不是指标，“月底结账从 5 天降到 2 天、返工不超过 2 处”才是。指标定不清，做完也没法判断值不值。
场景怎么选：四问过一遍
四个问题都过得去，这个场景才值得投人。任何一问答不上来，说明还没到能做的程度。
这件事多久发生一次？
可做：每周 ≥2 次
为什么：频次太低，做出来也用不了几次，摊不平投入
做对做错，标准清楚吗？
可做：有明文规则或历史样本
为什么：标准说不清，AI 只能猜，猜错的代价由你承担
输入的数据拿得到吗？
可做：有系统、有表格、有权限
为什么：数据拿不到，再好的模型也只能编
做错了代价多大？
可做：可回滚、可人工兜底
为什么：不可逆的环节（对外承诺、付款、报税定稿）必须留人签字
一个场景从 0 到 1 的六步
拆需求
把“要提效”拆成动作级：谁在什么触发条件下做什么、输出交到谁手上。拆到能写成一段流程说明为止。
定指标
用时间、返工次数、漏项数这类可数的指标，不用“效率提升”这类无法验收的说法。指标先定，再动手。
接数据
把这件事需要的数据通路先打通：从哪来、谁维护、多久更新、出错怎么发现。这一步通常比搭 AI 花的时间更长。
搭流程
按拆出来的动作配智能体，一个环节一个环节接。不要一次接全套——出问题时你不知道是哪一环坏了。
跑通验收
用真实业务跑两周，和人工结果对照。达标就固化，不达标先找流程漏洞，不是换个模型再来一遍。
复制
跑通一个场景后，把可复用的部分沉淀成模板，第二个场景的工期通常只有第一个的一半。
FDE 到底在现场做什么
很多人把 FDE 理解成“派个工程师驻场”。我们的理解不一样：FDE 的核心动作是拆。
拆不清楚，派谁进去都是陪着加班；拆清楚了，很多场景不需要长期驻场，配好流程我们自己撤。 也正因为这样，规模不大的团队也能接中小项目——不是靠人多，是靠拆得动。
三条边界，写在前面
不接“全公司 AI 战略”这类大包
那种项目需要咨询公司、需要一年、需要组织架构配合，我们做不了也不装能做。我们做的是能在一个季度内跑出结果的具体场景。
数据敏感就走私有化
客户名单、财务数据、工艺参数这类不能出内网的，本地部署或专有实例；通用场景走 API 控成本。哪种合适要算，不一味推重的。
试点不达标就停
两周跑不出可验收的结果，我们主动叫停，把过程中的问题写成报告交给你。硬推下去对双方都是浪费。
先拿一个场景试，四问帮你过一遍
把你最想改的那个环节讲出来，我们按上面四个问题当场过一遍：频次够不够、标准清不清、数据拿不拿得到、错了兜不兜得住。过不了就说不行。
