大模型企业应用：从试点到规模落地的工程路径

现实校准：70%企业卡在试点，问题出在哪一步

先看一组让人清醒的数字。中国信通院在其2024年大模型落地路线图研究报告中给出的行业画像是：超过七成企业已经把大模型写进了战略文件，但真正跑通落地闭环的只有三成左右；与此同时，还有约三分之一的企业停留在评估甚至尚未启动的状态。把这三层叠在一起看，行业呈现出一个典型的"倒三角"结构——顶部是庞大的战略意愿，中部是拥挤的试点项目，底部是稀薄的生产级系统。

这个结构说明什么？大量项目死在了从"试点"到"生产"的过渡带里。

更值得注意的是死因分布。从工程实操角度复盘那些卡住的项目，技术本身——模型精度不够、推理速度不达标——其实只是少数情况。多数项目的崩溃路径长这样：

• 选了一个看起来合理但缺乏硬性可行条件的场景；
• 推进两个月后发现所需数据要么不存在、要么质量无法支撑模型表现；
• 即便勉强出了demo，到对接业务系统（CRM、ERP、工单平台）时发现集成复杂度远超预期，项目停滞。

这三步是一条连锁反应链：场景选错导致数据需求定义模糊，数据问题暴露晚导致返工，返工后即使模型侧勉强交付，系统集成层的断裂又把整个链条拖入僵局。信通院同份报告中列举的企业核心挑战——数据质量、系统集成复杂度、合规约束——本质上都是这条链条不同环节的具体表现。

行业里还有一个容易被忽视的结构性问题：应用推进速度呈现"两头快、中间慢"的特征。面向消费者的轻量场景（客服机器人、内容生成）和面向生产端的垂直场景（代码辅助、质检）推进相对顺畅，但涉及企业中间环节——流程审批、跨部门协同、供应链决策——的深度业务融合，进展远不及预期。原因很直接：中间环节的场景往往同时触发数据壁垒和集成壁垒，两道门槛叠加，失败概率陡增。

理解了这个现状，本文的核心判断也就明确了：企业大模型项目能否从试点走向规模落地，取决于三道工程门槛是否在启动前就被严肃评估过——

• 场景门槛：这个场景是否有可量化的可行性指标支撑，还是仅凭直觉和PPT在驱动？
• 数据门槛：所需数据在当前组织内是否真实可获取、可治理、可持续供给？
• 集成门槛：模型输出能否在可控成本内接入现有业务系统并形成闭环？

任何一道门槛过不了，项目就不应该进入开发阶段。这不是保守，而是对资源的基本尊重。后续各节会逐一拆解每道门槛的具体判断方法和量化标准，最终给出一条从试点到规模化的可执行工程节奏。

第一道门槛：场景可行性——用四个硬指标砍掉伪需求

企业内部提报的大模型候选场景，通常远多于工程团队能承接的数量。问题不在于"哪个场景有价值"，而在于"哪个场景在当前条件下能跑通闭环"。我们在实践中用四个硬指标做第一轮筛选，目标是把注定会烂尾的项目拦在立项之前。

硬指标一：任务容错率

大模型的输出本质上是概率性的。第一个要问的问题是：这个业务场景能承受多大的错误率？

• 容错率极低的场景（如财务对账、合规审计、剂量计算），错误代价是直接经济损失或法律风险，不适合作为首批上线场景。
• 容错率较高的场景（如内部知识检索、营销文案初稿、工单分类），即使模型输出有偏差，后续人工校正的成本可控。

判断标准很朴素：如果模型犯一次错需要三个人花半天善后，这个场景就不该出现在第一期清单里。容错率不是固定属性，而是跟流程设计有关——同一个场景加一层人工审核环节，容错空间就会放大，但也意味着自动化收益打折。需要在立项阶段就把这笔账算清楚。

硬指标二：ROI 可量化性

场景选择的第二个硬约束是：能否在六个月内建立效果基线并度量改善幅度。"感觉效率提升了"不算数据，必须有可对比的指标——处理时长、人力工时、转化率、错误率中至少一个能被埋点采集。

不同场景类型的回报结构差异很大。行业调研普遍显示，数据分析与供应链优化类场景的投资回报倍数明显高于人力资源等内部效率场景。这并不意味着后者没有价值，而是说如果团队只能同时跑两个试点，应该优先选择回报信号强、度量链路短的场景——它能更快给组织提供"继续投入"的决策依据。

另一个现实约束是回报周期。基础应用场景（客服、内容生成）的完整回报周期通常在一年到一年半，而涉及智能决策、预测分析的复杂场景往往需要两到三年才能看到全量回报。首批试点如果全部选择长周期场景，大概率会在第九个月因为"看不到成果"而被管理层叫停。

硬指标三：数据闭环周期

模型上线只是起点。真正决定项目生命力的是：场景运行过程中，能否自然产生可回流的标注数据来支撑后续迭代？

好的数据闭环是这样的：用户在系统中采纳或修改了模型输出，这个行为本身就构成了一条标注样本，无需额外的标注团队介入。典型如智能客服——客服人员修改模型推荐的回复，修改后的版本直接成为下一轮微调的正样本。

差的数据闭环是：模型输出之后，业务流程中没有任何自然的反馈信号，要评估效果就必须单独组织专家评审。这种场景的迭代成本会随时间线性增长，最终变成一个只出不进的消耗型项目。

硬指标四：人机协同边界

最后一个指标关注的是决策权分配：哪些环节模型可以自主输出结果，哪些环节必须由人类做最终判断？这个边界必须在立项时画清楚，而不是上线后再摸索。

边界模糊的场景风险极高。典型症状是：业务方说"模型辅助决策"，但没有定义当模型建议与人工判断冲突时谁拥有最终决定权。结果要么是人完全不看模型输出（系统沦为摆设），要么是人过度依赖模型输出却无人为结果负责（出事后互相推诿）。

工程上的做法是把每个场景拆成若干决策节点，逐个标注"自动/半自动/人工"。只有当自动节点占比超过一半时，这个场景的大模型应用才具备足够的效率杠杆。否则你建的不是智能系统，是一个需要持续喂人力的审批流水线。

四条线都过了的场景，在我们的经验中通常不会超过企业最初候选清单的三分之一。这不是悲观，而是工程纪律——把有限资源集中在能跑通的场景上，比广撒网然后逐个烂尾要高效得多。

第二道门槛：数据就绪度——别让"数据质量差"成为万能借口

"数据质量差"是企业大模型项目里出现频率最高的失败归因，但它几乎没有诊断价值。就像病人跟医生说"我不舒服"——接下来要做的是拆解症状，而不是反复确认"确实不舒服"。

把"质量差"拆成五个可度量的工程维度

实际工程中，数据问题可以沿五条轴线定位，每条轴线对应不同的修复手段和资源投入：

这五条维度中，覆盖率和标注一致性决定模型效果的上限，时效性决定效果的衰减速度，合规可用性决定能用多少数据，格式标准化决定把数据变成可用状态要花多少人天。诊断时按这个顺序逐条过，比笼统说"质量差"有效得多。

最小可用数据集：试点不需要完美，但需要底线

一个常见误区是试图在项目启动前把数据治理到"完美"状态——这往往导致半年过去还没开始建模。务实的做法是定义一个最小可用数据集（Minimum Viable Data Set），即：在上述五个维度上各设一个明确的准入阈值，达标即可启动试点迭代。

• 覆盖率：核心场景的 Top 80% 高频 query 类型有对应语料即可启动，长尾后补。
• 标注一致性：关键分类任务的标注者间一致率达到 0.75 以上。低于此值，模型评测结果不可信，调参没有意义。
• 时效性：试点期间确保数据更新周期短于业务变更周期。做不到自动同步，手动维护也行，但必须有明确责任人。
• 合规可用性：在试点范围内完成数据分级审批，拿到可用于模型训练或检索的正式授权。
• 格式标准化：试点涉及的数据源完成结构化解析，解析准确率高于 95%。

这些阈值不是学术标准，而是工程经验值：低于这个底线，试点阶段的评测结论不可靠，无法为后续决策提供依据。

预算黑洞在数据侧，不在推理侧

推理成本的下降速度超出多数人预期。行业数据显示，过去两年大模型推理单价以每年超过 80% 的幅度下降（多家云厂商公开定价可验证此趋势）。但推理便宜了不代表项目便宜了——成本结构正在发生位移：GPU 算力从主要开支项退居次席，数据准备（采集、清洗、标注、脱敏、格式转换、持续更新）成为占比最大的单项。

行业调研普遍显示，数据相关工作在企业大模型项目总成本中的占比处于相当高的水平，尤其在非结构化数据密集的场景（如合同审查、研报生成、工单处理），格式解析和清洗管线的开发运维本身就是一个独立的工程子系统。如果预算规划时把数据治理当作"前期一次性工作"，几乎必然超支。

金融与政务：合规不是附加项，是架构约束

在金融和政务行业，数据合规要求从根本上改变架构选型空间：

• 数据不出域：模型必须部署在机构自有或专属环境内，排除了大部分 SaaS 化方案。这意味着运维复杂度和基础设施投入同步上升。
• 字段级权限控制：同一份文档中不同字段的可见性取决于调用者角色，RAG 检索管线必须内嵌权限过滤逻辑，而非仅在前端做展示屏蔽。
• 审计可追溯：每一次模型推理的输入输出需留痕，用于事后审计。这对日志系统的吞吐和存储提出额外要求。
• 数据脱敏与回填：敏感字段脱敏后送入模型，推理结果再回填原始上下文。这条管线的工程复杂度经常被低估。

这些约束不是"额外需求"，而是项目第一天就必须纳入架构设计的硬前提。忽略它们做出的试点方案，到合规审查阶段大概率需要推翻重来——相当于试点白做。

总结一下判断标准：如果你的项目在五个数据维度中有三个以上无法在合理周期内达到最小可用阈值，正确的决策不是"先做起来再说"，而是重新评估场景选择本身是否合理。数据就绪度不足是一个信号——它可能在告诉你，这个场景目前不具备落地条件。

第三道门槛：系统集成——CRM/ERP对接不是"最后一公里"而是"中间断裂带"

多数项目团队把系统集成排在计划的最后阶段，留出两三周做"接口联调"。这是一个代价极高的误判。实际经验反复证明：集成工作不是收尾动作，而是整个工程最密集的断裂地带——技术问题和组织问题在这里同时爆发。

高并发只是表象，业务流程重构才是真正的工程量

企业级场景对推理服务的并发承载力有硬性要求，万级QPS的吞吐门槛在行业讨论中已是共识。但实际项目里，性能达标往往不是最耗时的环节——真正消耗工期的，是把大模型的输入输出嵌入到已有业务流程中去。

一个典型的例子：将大模型接入CRM做客户意图识别，表面上是"加一个API调用"。实际要解决的问题包括：

• 原流程中人工判断节点的决策权归属需要重新定义——模型输出是建议还是决定？
• 异常处理分支成倍增加：模型超时、置信度不足、输出格式异常，每种情况都需要降级路径
• 上下游系统的数据契约要同步修改：字段新增、枚举值扩展、调用时序变化

这些问题没有一个能靠纯技术手段在最后阶段补救，它们本质上是业务流程的重新设计。

多模型路由：不是架构炫技，是成本与质量的工程平衡

企业应用中支持多模型智能路由已经从"可选项"变成了工程上的实际需要。判断逻辑并不复杂，核心考量三条：

路由层的工程实现要点在于：分类器本身必须足够轻量（通常是规则+小模型打分），否则路由判断的开销会吞掉它省下的推理成本。

渐进式替换：影子模式不是保守，是工程纪律

一步切换到大模型驱动的流程，在生产环境中几乎必然触发事故。经过验证的接管节奏是三个阶段：

• 影子模式：模型与现有系统并行运行，模型输出不进入实际业务链路，仅用于对比评估。这个阶段的核心产出是一份差异分析报告，明确模型在哪些子场景上已经稳定可靠。
• 并行运行：模型输出开始进入业务流程，但保留人工复核节点。重点监控的不是准确率本身，而是错误模式——同一类错误反复出现意味着流程设计有缺陷而非模型能力不足。
• 逐步接管：按子场景分批移除人工节点。每批接管后至少运行两周再推进下一批，给长尾异常足够的暴露窗口。

AI智能体在集成层的实际价值：从工具调用到流程编排

当集成涉及多个系统的协调操作时，AI智能体的角色开始超越"被调用的工具"，转向主动编排流程。智能体在金融等领域已有落地实践，承担从交易策略生成到风险评估的多环节串联任务。

在集成架构中，智能体带来的关键变化是：把原本需要硬编码的跨系统协调逻辑，变成可由智能体根据上下文动态决定的执行路径。这降低了每次流程变更时的人工开发成本——但前提是你的系统接口已经被设计为智能体可理解、可调用的形式。缺乏标准化接口描述的遗留系统，仍然需要先做一层适配封装。

总结这道门槛的核心判断：如果你的项目计划中，集成工作占比低于总工期的40%，大概率是低估了。把它提前到架构设计阶段同步推进，而非留到最后"联调"，是避免项目后期失控的关键决策。

过了三道门槛之后：试点到规模化的工程节奏

场景筛过了、数据备好了、集成方案验证了——接下来最常见的失败模式不是技术崩溃，而是节奏失控：试点无限延期，或者反过来，还没建好运维骨架就急着铺场景。工程节奏本身需要设计。

三阶段不是时间表，是退出条件表

行业实践普遍收敛到三段式推进——试点验证、规模推广、全面应用——但真正区分成败的不是每段花多久，而是每段结束时用什么硬指标决定"能不能往下走"。把阶段划分当日历排，是项目管理最常见的错觉。

任何一项退出条件未达成就推进到下一阶段，后续返工成本会成倍放大。Gate Review 的价值不在于放行，在于拦截。

试点验证期：交付物不是"模型跑通了"

试点阶段最危险的产出是一份效果截图加一句"准确率 92%"。真正需要交付的东西完全不同：

• ROI 验证模型——把推理成本、人力节省、错误率变化、维护投入拉成一张三年现金流表，让财务部门能签字。基础场景（客服、内容生成类）的回收周期通常在一到一年半，复杂决策类场景则需要两到三年，试点阶段必须把这个预期锚定下来。
• 运维 SOP——包括模型漂移告警阈值、回退策略、人工兜底触发条件。如果试点期没有经历过至少一次效果退化并走通恢复流程，那这套 SOP 就是纸面文件。
• 组织接口定义——谁负责 Prompt 迭代、谁审批模型上线、谁监控业务指标——角色不清晰的试点，推广时必然卡在协作摩擦上。

规模推广期：用平台化对冲人才瓶颈

技术人才短缺是行业公认的扩展瓶颈。但换个角度看：如果每接一个新场景都需要同等水平的算法工程师从头搭建，说明试点阶段的工程资产没有沉淀为可复用平台。规模推广期的核心任务就是把"英雄项目"变成"工业流水线"：

• MLOps 管线标准化——模型训练、评估、部署、监控四个环节的工具链固化，新场景接入时只需配置不需开发。
• Prompt 与数据管线模板化——把试点期积累的有效模式封装为可参数化的组件，降低业务团队的使用门槛。
• 能力分层开放——将"需要算法团队深度介入"的场景和"业务团队自助配置"的场景明确区分，让稀缺人才聚焦在高难度问题上。

破局策略：先消费侧，后深度融合

当前行业呈现一个清晰规律：面向终端用户的消费侧场景（智能客服、内容生成、知识问答）和面向生产环节的自动化场景推进较快，但涉及核心业务逻辑的深度融合（定价决策、供应链优化、风险建模）进展明显迟缓。

工程上的合理策略是顺势而为：先用标准化程度高的消费侧场景跑通整条 MLOps 管线、建立运维肌肉记忆、培养业务团队的 AI 协作习惯，再把积累的工程能力投射到深度业务融合场景。反过来做——上来就攻最复杂的决策场景——大概率在试点阶段就耗尽组织耐心。

规模化不是试点的简单复制，而是一次工程体系的升级。节奏对了，每个新场景的边际成本递减；节奏错了，每个新场景都是一次独立创业。

成本工程：投资回报周期的真实结构

企业大模型项目的预算表，大部分在立项时就已经失真。常见的错误是把"模型接入"当作主要成本项，而实际上模型本身往往只是冰山尖角。真正吞噬预算的是水面以下那些不性感但不可回避的工程投入。

成本构成的真实分布

一个典型的企业大模型项目，从试点到稳定运行的18-36个月周期内，成本大致沿五条线分布：

多数项目失败的财务根源在于：把第一项当全部，忽略后四项的持续消耗。一个更接近现实的预算模型，应该把基础设施视为成本起点而非成本全貌。

推理成本下降的红利去了哪里

过去两年间推理成本的急剧下降（行业共识是年降幅超过80%）确实改变了规模化应用的经济可行性。但在实际项目中，省下来的算力预算很少直接转化为利润——它被重新分配了。

明智的工程团队把这笔红利投向两个方向：

• 数据飞轮建设——用节省的推理成本扩大数据采集与标注规模，让模型效果持续改善而非原地踏步
• 评估体系加固——建立自动化的效果回归测试、A/B实验平台、漂移检测机制

换句话说，推理变便宜了，但把省下的钱装进口袋的企业，通常会在半年后发现模型效果悄然下滑。成本节约的正确去处是提高系统韧性，而非美化当期报表。

不同场景的ROI路径差异

回报周期与场景复杂度强相关，不存在统一的收益时间表：

快周转场景（12-18个月回本）：客服、内容生成类应用。特点是效果可量化（响应速度、人工替代率）、反馈回路短、业务方接受度高。行业调研普遍显示，智能客服上线后人工工作量可削减过半，运营成本显著下降，这使得它成为最容易自证ROI的切入点。

慢积累场景（24-36个月回本）：风控、预测分析、供应链优化类应用。特点是需要长时间数据积累才能体现统计显著性，且效果往往体现为"损失减少"而非"收入增加"，这使得回报不易被业务方直观感知。金融风控场景中，从风险识别准确率的提升到误报率的压降，需要经历多轮模型迭代和规则校准才能稳定。

三类隐性成本不进预算表就等着超支

• 模型漂移监控——线上数据分布持续变化，模型效果会静默退化。没有监控就没有预警，等业务投诉时修复成本已经翻倍。
• Prompt工程迭代——Prompt不是写一次就定型的配置文件，它需要随业务场景演变持续调优，这部分人力投入是持续性的，不可一次性预提。
• 合规审计——监管要求在加速落地，数据安全评估、算法备案、可解释性报告都需要专项投入，且频次通常高于预期。

做预算时的一条经验法则：把你估算的"一次性开发投入"单独拿出来，再叠加同等量级的三年运维储备金，这个数字才更接近真实的总持有成本。低估持续运营开销是大模型项目最常见的财务盲区——项目不是上线即结束，上线只是成本曲线从陡峭变为平缓的拐点。

2026下半年趋势：门槛会变低，但不会消失

技术演进确实在压低前几节描述的三道工程门槛，但压低不等于消除。更准确的判断是：技术门槛在下移，非技术门槛在上移，两者此消彼长。

多模态能力重构数据就绪度的定义

过去，图纸、影像、语音这类非结构化数据进入模型之前，必须经过专门的解析、清洗与格式转换流程，这道预处理管道是项目预算和工期的主要消耗点之一。2026年陆续投入商用的多模态大模型，已能直接以原始格式接收上述输入，把转换工作从工程端移到了模型端。

工程含义是：数据就绪度门槛的位置变了，但门槛本身没消失。以前卡在"如何把非结构化数据转成可用的结构化特征"，现在卡在"多模态输入的质量管控与业务语义对齐"。制造业图纸识别的实际误判率，很大程度上取决于企业能否提供覆盖度足够的标注样本，而不只是能否把PDF传进API。

AI智能体把集成门槛从技术问题变成治理问题

传统API集成的挑战是显性的：接口协议、认证方式、字段映射，出错了日志里有记录。Agent自主编排引入了一类新的失效模式——模型在多步推理中途偏离预期路径，中间状态难以审计，回滚逻辑也不像数据库事务那样有原子性保证。

金融行业已有机构将Agent用于交易策略生成与风险评估场景，随之而来的是监管合规压力和内部审批流程的重新设计。能源交易领域同样出现了AI驱动的自主交易产品进入商业化阶段的案例，人工干预机制和行为边界定义随即成为主要工程难点。集成门槛没有消失，只是从"能不能接通"变成了"接通之后如何管控"。

行业专属模型给中小企业打开了新入口，但入口有条件

通用大模型的垂直适配需要持续的微调投入和行业数据积累，对资源有限的中小企业是实际的准入壁垒。行业专属模型的商业化缩短了这段距离：企业可以跳过自建微调流程，直接在垂直模型上做场景配置。

但这个入口有约束。垂直模型的效果高度依赖供应商的行业数据质量与迭代频率，企业的核心业务逻辑能否准确表达给模型，仍是场景可行性的实质考验。行业专属模型降低了技术起步成本，但场景定义和业务规则的整理工作，依然需要企业自己完成，这一点不会因为模型换了一个供应商而改变。

门槛转移之后，真正的分水岭在哪里

综合来看，2026年下半年的技术趋势在做同一件事：把工程复杂度从基础设施层往上推，推到组织能力层。以下三项能力正在成为新的决定因素：

• 数据治理能力：能否持续产出带有业务标注、可用于评测的高质量数据，而不是靠项目启动前的一次性整理撑过试点
• 跨部门协同效率：IT、业务、合规三方能否在同一项目里对齐决策节奏，而不是在流程节点上互相等待
• 风险容忍与响应机制：组织是否具备在AI出错时快速定界、快速响应的能力，而非每次异常都触发全面叫停

技术门槛低了，反而让组织能力差距暴露得更清楚。那些在试点阶段熬过三道工程门槛的团队，进入规模推广后遭遇的阻力，越来越多地来自会议室而不是服务器机房。这是2026年下半年企业大模型落地最值得关注的结构性变化。

FAQ：企业大模型落地的高频工程问题

企业没有专职 AI 团队，是否应该启动大模型项目？

可以启动，但启动方式必须调整。核心判断标准不是"有没有人"，而是"能不能在三个月内形成闭环反馈能力"。

没有专职团队的企业，常见的失败模式是：外包商交付一个看起来能跑的 Demo，内部没人能判断效果好坏，更没人能持续调优。三个月后模型输出质量下滑，没人知道原因，项目悄然搁置。

务实的做法是把启动拆成两件事同时推进：

• 场景侧：选一个业务部门自己能判断输出质量的场景（比如客服话术生成——业务主管看一眼就知道对不对），而不是选需要专家才能评估的场景（比如代码生成）。
• 能力侧：内部至少安排一到两个工程角色（不必是算法专家）专门跟进 Prompt 管理、效果监控和数据回流，这些工作的门槛比训练模型低得多，但决定了项目能否存活过试点期。

总结：没有 AI 团队不是不能做，而是要选"评估门槛低、反馈闭环短"的场景切入，同时把最小运营能力建在内部而非外部。

试点阶段"成功"的量化标准应该怎么定？

试点成功不等于"Demo 跑通了"，也不等于"用户说体验不错"。需要在启动前就把验收条件钉死在三个层面：

• 任务完成率：模型输出能直接使用（无需人工大幅修改）的比例。这个数字因场景而异，但必须有一个具体阈值。比如文档摘要场景，可用率过低基本没有推广价值——人工修改的成本会吃掉所有收益。
• 端到端时效：从用户发起请求到拿到可用结果的完整时长，而不是模型推理延迟。很多项目推理只要两秒，但前后的数据拼接、权限校验、格式转换加起来要三十秒，用户体验完全不同。
• 运维可持续性：试点期间需要多少人天来维持效果稳定？如果一个场景需要一个工程师全职盯着才能保持产出质量，那它在规模化阶段的人力成本会线性膨胀，不具备推广条件。

建议在试点启动时就把这三个指标写进项目章程，附带"达标则推广、未达标则复盘或终止"的明确决策规则。模糊的成功标准是项目僵尸化的温床。

推理成本已经很低了，为什么项目总成本还是很高？

因为推理调用费只是冰山露出水面的部分。真正的成本结构大致是这样的：

拿一个典型的文档处理场景来说，模型 API 调用费可能只占总投入的一小部分。更大的开销藏在这些地方：

• 数据预处理：企业内部文档格式混乱（扫描件、老旧 Word、嵌套表格），光是把它们变成模型能消费的干净文本，就需要大量工程投入。
• 集成开发：和现有业务系统对接的接口开发、权限适配、异常处理链路搭建，这些工作量往往超过模型本身的接入。
• 持续运维：Prompt 版本管理、效果监控看板、badcase 回流机制、模型升级后的回归测试——这些不是一次性投入，而是持续消耗。
• 组织成本：业务部门配合梳理规则、提供标注反馈、调整工作流程——这些隐性人力投入很少被计入项目预算，但实际消耗不小。

所以在做投资回报测算时，不要只看 API 账单。把集成开发、数据治理和运维人力一起算进去，才是真实的持有成本。

如何判断当前项目是该坚持还是该止损？

止损决策难，是因为沉没成本效应在企业内部特别强——已经投了人、投了钱、开了会、发了周报，很难承认方向不对。需要一个相对客观的判断框架：

应该坚持的信号：

• 核心指标（完成率、时效）在持续改善，哪怕速度慢；
• 瓶颈是已识别的工程问题（数据缺失、接口不通），而非模型能力本身不够；
• 业务侧有明确的人在持续使用并给反馈。

应该止损的信号：

• 核心指标三个迭代周期没有实质变化，且团队说不清楚下一步该优化什么；
• 问题不断从"工程问题"滑向"这个任务可能根本不适合用当前模型做"；
• 业务侧已经不再使用试点系统，或者使用后仍回退到原有流程。

止损不丢人。尽早释放资源投入更合适的场景，比在一个不可行的方向上反复加码要理性得多。把试点当成假设验证实验，而不是必须兑现的承诺——这个心态转变是组织层面最重要的一步。