24 个案例里，行业不同、技术选型不同，但真正决定成败的动作高度一致。这一页把共性抽出来：一条六段式落地路径、一组场景判断标准、一份分工原则，以及一份踩坑清单。
案例里最有效的项目，都是按这个顺序推进的；反过来，跳过前面的阶段直接做技术，往往会在最后一公里卡住。
不要先问"用什么模型"。跟着员工走一遍他每天的工作流程，看他在哪里停下来、哪里需要问别人、哪些问题反复出现； 很多问题只做访谈是问不出来的，坐到工位旁边看他实际怎么操作，往往比开三次会更有效。
"沉淀老师傅经验""把两个系统打通""我们想用 AI 赋能"都不是可执行的工程问题。要往下拆到：谁在什么场景下、 因为缺什么信息、每天重复做什么动作、这件事造成的具体损失是什么。
用阶段性成果跟业务对话，先找关键人和业务骨干用真实数据/真实订单试，再让一个小组试，稳定后才扩展到部门。 这样既降低技术风险，也降低组织层面的阻力。
真正的业务价值在于识别之后数据能不能自动流转、流程能不能继续往下执行、异常由谁处理、原岗位是否需要多一步操作。 如果只是多出一个页面、还要人工复制粘贴，价值会大打折扣。
上线前记录人工处理需要多少时间、多少人力；上线后持续记录同样的指标，并尽量找到可量化的业务口径 （应收差异、装载方数、办件量、报价响应时长）。交付一个"能跑的 AI"不够，还要能证明它创造了多少业务价值。
底层能力（模型、架构、知识库、技能模块）标准化，业务方案保持适度定制； 每做完一个项目，把方法、流程、组件与业务理解留下来。第一次做 100% 成本，第二次 80%，第三次 60%——这就是壁垒。
不是为了"AI First"硬找场景。案例里反复出现的判断标准是这四条，四条都成立才值得投入。
每天、每周都在做的动作，才有优化的必要。一次性的工作交给流程，不必交给 AI。
占用的是稀缺人力（技术骨干、法务、老师傅、设计师高手）时，成本才真正高。
步骤说不清的事，AI 只能自己"生成"。流程要被梳理出来，人觉得"理所当然"的步骤恰恰最需要显性化。
数据脏、口径乱、来源不可追，AI 只会把错误放大得更快。先治数据，再谈智能。
不要纠结方案"是不是纯 AI"。真正解决问题的方案往往是混合的：模型负责判断，规则负责确定性，机器负责重复执行，人负责例外与责任。
| 分工 | 承担什么 | 案例里的例子 |
|---|---|---|
| AI / 模型 | 非结构化理解、判断辅助、生成与归纳 | 材料识别、图纸解析、文案生成、动销数据归纳、经验检索 |
| 业务规则 / 算法 | 确定性计算、优化求解、口径统一 | 报价规则、装载优化、科目归集规则、补货公式（保留客户原有逻辑） |
| RPA / 自动化 | 跨系统的重复执行与搬运 | 单据创建与填写、跨系统取数、模板套用、批量生成文件 |
| 人 | 最终判断、例外处理、情感与责任 | 评级与评价、复杂工艺决策、家长/客户沟通、最终审批与监督 |
真正要解决的是业务问题。技术越强，越容易在错误的场景上做得很漂亮。
业务人员讲不全自己的工作，很多细节要在他身边才看得见。
Demo 到生产之间要解决稳定性、可重复性、成本、权限与日常使用习惯。
数据没变时同一个问题必须给同一个答案。这是要工程化解决的部分，不是借口。
多一个页面、多一步人工复制粘贴，价值立刻减半。
交付完不追踪，就无法回答"到底省了多少、赚了多少"，项目很难进入下一轮。
AI 上线后，绩效、流程、岗位边界如果不调整，工具再多也变不成生产力。
先在真实场景解决一个问题，再从多个项目里找共性——共性是被验证出来的，不是设计出来的。
技术门槛在下降，行业认知与组织理解反而越来越难复制——这是 24 个案例里最一致的一个结论。
