为什么“先选模型”经常把项目带偏？
先选模型很容易把讨论变成功能比较：参数规模、上下文长度、价格和速度。但企业真正卡住的往往是资料散乱、版本不一致、岗位责任不清、结果无人确认。模型只能处理得到的输入，不能自动替企业补齐组织事实。
如果任务没有清楚边界，演示时看起来什么都能做，进入业务后却无法判断哪一次回答可用、错误由谁处理、什么结果算完成。这也是很多 AI 项目停留在聊天窗口或样板演示的原因。
第一步要写清四件事
- 真实问题：谁在什么场景下遇到什么阻碍，当前怎样处理。
- 必要输入：完成任务需要哪些文档、图片、数据和人工说明，来源是否可信。
- 责任与权限：谁能查看资料，谁负责使用，哪些判断必须由人确认。
- 通过条件：用什么样本测试，错误怎样记录，谁签字或确认通过。
这四项组成最小任务合同。模型、数据库和界面都应服务于它，而不是反过来要求业务适配某个工具。
怎样选第一件试点任务？
优先选择高频、边界清楚、数据可取得、结果能人工核对的工作。例如从资料中核对产品规格、把确认过的知识整理成内部答复、根据脚本和素材生成镜头编排初稿。不要从“替企业自动做全部经营决策”开始。
源途科技的FDE 前线部署方法就是让工程师进入真实现场，先看当前资料、流程和责任，再构建一个可运行的最小工作链。成功标准不是演示好看，而是任务能够重复运行、异常能够被看见、人工可以确认结果。
模型应该在什么时候进入？
当任务合同明确后，再根据语言理解、图像处理、上下文长度、部署环境、成本和速度选择模型。一个任务也可能组合多个模型：小模型做分类，检索系统提供资料，大模型生成初稿，规则脚本做字段校验，人负责最终确认。
这时“换模型”只是可控部件的替换，不会把整个业务流程推翻。企业最终拥有的是工作能力，而不是对某个模型名称的依赖。
能够证明什么，不能证明什么
源途科技公开的智能企业工作台和项目实例可以说明任务总控、知识中心、人工确认、并行工作流等设计与本地工程记录。公开材料不能自动证明客户经营效果、正式公网运行、模型优于其他方案或已获得搜索与 AI 引用。
常见问题
企业 AI 试点应该选多大范围？
选择一件输入可取得、负责人明确、结果能在短周期人工验收的任务。范围越大，责任和证据越容易失真。
什么时候再选择模型？
在任务、资料、权限、成本和验收条件明确以后，再根据需要选择模型。
做出一个演示界面算落地吗？
不算。没有真实任务记录、人工反馈和验收证据，只能算演示或试用。