先给结论：想解决具体问题、尽快见到效果，从业务切入；要建长期能力、团队有技术积累，从技术切入。这是 AI 落地路线选择的头一把尺子。两条路没有高下之分，只有合不合适的区别——判断依据是你的目标、家底和验证方式。
两条路各自的账
从业务切入，是需求驱动：拿一个具体场景（客服问答、报表生成、合同初审）打样，目标明确，成败好判断，见效快，容易争取后续资源。代价也明显：容易做成一次性方案，不同业务线各自为战，能力难以复用，第二次落地又是从零开始。
从技术切入，是能力驱动：先把模型服务、数据管道、评测体系这些底座做起来，后续业务接入成本低，能力可沉淀、可复用。代价是前期看不到直接回报，且容易做出"没有业务场景用"的能力——底座很漂亮，上面没长东西。
| 维度 | 业务切入 | 技术切入 | 判断标准 |
|---|---|---|---|
| 见效周期 | 按周计，一个场景跑通就能演示 | 按月计，底座成型才有产出 | 三个月内要不要拿出可演示的结果 |
| 资源门槛 | 懂业务的人牵头就能启动 | 要有能搭服务、管数据、做评测的工程力量 | 团队里有没有能独立交付工程的人 |
| 成果形态 | 单点效果，难复用 | 通用能力，待场景激活 | 组织要的是标杆案例还是长期底座 |
| 主要风险 | 各自为战，重复建设 | 悬空，做完没人用 | 哪种风险你更输得起 |
选业务切入的三个信号
一是目标可量化：要证明 AI 有用，且成功标准能写成业务指标（处理时长下降多少、人力投入减少多少）。二是业务理解深、技术力量薄：让最懂流程的人牵头，工程能力外包或借助成熟平台补。三是时机紧：半年内需要拿出结果争取预算或应对外部竞争，业务切入是来得及的路线。
选技术切入的三个信号
一是场景多且分散：五六个部门都有需求，各自从零做必然重复建设，先建底座摊薄成本。二是有稳定的数据资产：数据质量高、能持续供给，底座建起来立刻有场景可接。三是团队有工程积累：有人能搭服务、管评测、兜底故障，且短期没有硬性的业务指标压顶。三个信号占两个以上，技术切入才成立。
更稳的走法：业务带技术
两条路不是互斥的。更稳的走法是用一两个具体业务场景拉动，同时在过程中沉淀通用能力：场景一的提示词模板、数据清洗脚本、评测集，到场景二时直接复用。只谈技术容易悬空，只谈业务容易重复造轮子；带着具体问题建底座，底座才不会跑偏，场景也不会白做。
操作上给一个配比参考：七成精力扑在当季要交付的场景上，三成用于把场景里可复用的部分抽出来。前两个场景允许重复劳动，第三个场景开始必须复用，否则说明沉淀机制没建起来。
技术切入先沉淀的通用件
技术切入最容易犯的错，是一上来追模型效果。真正该先做扎实的是通用件：鉴权怎么过、超时怎么兜底、告警怎么分级。这几件事和模型效果无关，却决定业务能不能放心把流程接进来。以超时兜底为例，重试策略、降级路径、失败告警必须提前定好，做法可以读超时的兜底动作有哪些；服务开放给多个业务方之前，网关层的鉴权与配额要先立规矩，参考网关的鉴权是怎么过的；出问题能不能尽早知道，取决于告警分级是否合理，详见告警的分级是怎么定的。通用件做扎实，场景接入才是天数和周数的问题。
这个判断什么时候会失灵
三个条件下，上面的尺子会失灵。一是场景太散：需求横跨十几个部门且互不相同，"业务切入"会退化成十几个互不相干的小项目，这时该先收敛场景，而不是选路线。二是核心数据不在自己手里：落地效果的天花板由数据决定，数据靠外部供给且随时可能断，从哪端切入都做不出持续效果。三是两类人都缺：既没有懂业务能把需求说清的人，也没有能交付工程的人，此时先解决人的问题，路线讨论没有意义。
关于落地路线还有三个问题
两条路能中途换吗？能，但有代价。业务切入转技术切入，要把前几个场景里重复的部分抽出来重构，早抽早省；技术切入转业务切入，先接一个最成熟的场景做出效果，证明底座有用，否则团队信心会先垮。
没有技术团队，只能业务切入吗？多数情况是。借助成熟平台和现成工具也能起步，把工程门槛外包出去；但涉及数据必须自己管的场景，还是要有至少一个懂工程的人把关，否则出事没人兜底。
怎么判断"底座建好了"？看接入速度：新场景从提需求到跑通演示，是按天计还是按月计。按天计说明底座真的可用；每次都要大改，说明沉淀的是代码，不是能力。
路线选择速查
- 要效果、要快、团队偏业务 → 业务切入
- 场景多、有数据、有工程家底 → 技术切入
- 更稳的走法：业务带技术，七成场景、三成沉淀
- 底座建没建好，看新场景接入是按天还是按月
