企业官网建设流程全解析

给大模型接一个知识库，再搭一个聊天页面，能不能算企业 AI 落地？

我的判断是：这可以算一个开始，但不能仅凭它证明落地成功。因为演示时问的是“AI 能不能回答”，业务里问的却是“回答能不能用、出了问题怎么办、值不值得持续投入”。

企业真正需要的，不是一个展示 AI 能力的入口，而是一段被实际改善的业务流程。

对技术从业者来说，这意味着关注点不能停留在模型调用、提示词和框架选型上，还要往前理解业务问题，往后验证交付结果。

趋势背景：从 2024 到 2026，企业关注点发生了什么变化？

严格来说，这两年的变化不是“大家不再关注技术”，而是企业讨论 AI 的层级正在上移：模型能力仍是基础，但仅仅证明模型会对话、会写代码、会调用工具，已经越来越难单独支撑项目立项和持续投入。

2024 年，重点是采用与能力验证。麦肯锡当年的全球调查显示，65% 的受访者称其组织已在至少一个业务职能中经常使用生成式 AI，整体 AI 采用率则升至 72%。这一阶段的典型问题是：大模型到底能做什么？哪些职能适合先试？准确性等风险如何控制？[1]

2025 年，重点转向Agent、试点和规模化之间的落差。同一机构的调查显示，88% 的受访者称其组织已在至少一个职能中经常使用 AI，62% 表示组织至少已开始试验 AI Agent；但近三分之二仍未进入企业级规模化阶段。技术热点从“模型能生成什么”扩展到“Agent 能否执行多步任务”，与此同时，企业也开始更直接地追问：试点怎样嵌入流程，为什么演示成功却难以复制？[2]

到了 2026 年，ROI、运行成本和工作流重构成为更突出的议题。调查中，近九成受访者称组织在至少一个职能中经常使用 AI，44% 表示已在企业范围推进规模化，但只有 37% 报告 AI 对组织 EBIT 产生了正向影响；约五分之一还表示 AI 运行成本限制了使用。换句话说，企业已经不只问“能不能做”，而是进一步问“能否稳定做、成本是否合理、结果能否被财务和业务指标验证”。[3]

这里需要注意：不同年份的样本、问法和统计口径并不完全相同，所以这些数字适合用来观察讨论重点与采用阶段，不宜简单拼成一条精确增长曲线。本文所说的“从技术走向落地”，指的是企业验收标准在扩展，而不是技术研发已经结束。

过去的典型展示是“回答得像不像”，现在更关键的问题是“任务是否真的完成”。这也是本文后续要讨论真实场景、权限、人工接管、成本和验收指标的原因。

一、为什么“用上 AI”和“用好 AI”是两回事？

麦肯锡于 2026 年 8 月发布的全球 AI 调查指出，受访者报告的个人生产力改善，并没有同步转化为普遍的企业财务改善；报告同时强调了工作流重设计与效果衡量的重要性。这是全球受访者自报调查，不能直接当作中国企业的普查结果，也不能单凭它证明某种做法必然有效。[3]

它提醒我们注意一个容易忽略的区别：一个人写材料更快，不代表整个业务流程就一定更快。

设想这样的情况：AI 帮员工生成了一份回复，但员工还得重新查资料、确认适用版本，再复制到工单系统。如果核验和搬运的时间抵消了生成环节节省的时间，聊天窗口里的效率就没有转化成业务效率。

问题不一定是模型不够强，也可能是资料不可靠、流程没打通，或者根本没有选中真正耗时的环节。

模型能力决定了能做什么，业务流程决定了这些能力能否真正被用起来。两者不能互相替代。

二、真实场景，要具体到“谁在什么时候做什么”

“做一个企业智能助手”是产品方向，还不是足够清晰的落地场景。

“让客服在处理某一类产品配置咨询时，从当前有效且有权限访问的帮助文档中找到依据，生成带引用的回复草稿，由客服确认后发送”，才接近一个可以开始开发的需求。

后者说明了使用者、触发时机、数据来源、输出形式和人工责任。技术团队才能继续判断：需要哪些接口、如何过滤权限、怎么测试、做到什么程度算有用。

我建议在选框架之前，先把几个问题写清楚：现在最费时间的是哪一步？现有做法是什么？AI 输出交给谁？什么情况必须停下来？业务负责人用什么标准决定继续使用？

如果这些问题还答不上来，先梳理流程，通常比立刻增加一个 Agent 更有意义。

三、从三个具体场景，看 AI 应该落在哪里

下面是用于说明设计思路的场景示意，不是某家企业的实际项目战报，也不代表它们在所有企业中都有正向收益。

1. 客服知识检索：先帮助找到依据，再考虑自动回答

可以从一类边界明确的产品咨询入手。AI 根据问题检索有效文档，给出相关条款、适用版本和回复草稿，客服在原有工单界面确认并发送。

这里真正需要解决的，不只是“搜得到”，还包括旧文档不能冒充新规则、不同客户的权限不能混用、证据不足时不能硬答。RAG，即检索增强生成，可以作为实现方式，但接上知识库并不自动保证答案正确。

验收重点：处理同类问题所需的时间是否减少，答案与引用是否一致，误答和重复咨询有没有增加。草稿采纳率可以观察，但不能单独证明答案质量。

第一阶段不必追求“完全替代客服”。让客服更快地找到可靠依据，本身就是一个值得验证的目标。

2. 文档处理：不是只提取文字，而是把结果可靠地交给下一步

例如从订单附件中提取商品、数量、交付时间等字段。AI 可以负责理解不统一的表述，程序负责检查必填字段、日期格式，以及商品是否存在于主数据中。

遇到扫描不清、字段冲突或缺项，不应让模型自行补齐，而应保留原文位置，交由人工确认。确认后的结果再写入业务系统，并检查实际写入状态。

验收重点：关键字段的正确性、复核耗时、异常单比例，以及后续返工是否减少。不能只看“生成了一份结构化结果”，却不检查业务系统能不能使用。

3. 研发辅助：不是只看写了多少代码，而是看交付是否改善

与其一开始就要求 AI 接管整个项目，不如限定一个任务：针对已确认的缺陷，生成修复建议和回归测试，由开发者审查，再进入现有 CI 流程。

边界同样重要：没有复现条件就先补信息；测试通过也不等于没有风险；代码合并、部署和生产权限仍按团队规范管理。

验收重点：在缺陷类型和难度可比的前提下，修复周期、审查成本、回归问题是否改善。代码行数和生成速度可以记录，但不应取代质量指标。

三个场景有一个共同点：先围绕一个具体任务交付可用结果，而不是先建设一个“什么都能做”的入口。

四、Demo 到生产，中间差的是可控的执行流程

一条成功的演示路径，只说明某次输入得到了预期输出。正式使用还要回答：资料缺失怎么办？权限不足怎么办？接口超时后能不能重试？用户如何知道任务到底完成没有？

下面给出一条适用于含业务操作任务的最小设计示意。不同场景可以调整，但不能把异常分支省掉。

人工接管不是让用户从头再来。系统应一起交出已有资料、失败原因和当前任务状态。对于已经执行的操作，要区分未执行、执行中、部分完成和已确认完成，避免重复提交。

权限也不能只写在提示词里。数据过滤、工具授权、操作范围和审计记录，应由系统实际执行；对付款、删除、对外承诺等高影响操作，保留明确授权与必要确认。

Anthropic 的工具工程文章建议，围绕真实任务构建评测，为任务配置可验证的结果，并同时观察运行时间、工具调用、Token 消耗和错误。它也强调工具不是越多越好，应围绕明确的高价值工作流设计。这些是厂商工程经验，具体效果仍需在自己的环境中验证。[4]

因此，固定步骤能解决的问题，可以先用确定性的工作流；需要理解非结构化内容的部分，再交给模型；确实需要动态选择工具时，再引入 Agent。复杂度应当由需求证明，而不是由热点决定。

五、怎样判断项目值得继续做？先算完整的一笔账

最容易高估收益的做法，是只算模型生成得多快，却漏掉人工复核、系统集成和失败返工。

对于提效型试点，可以先比较同一类任务在两种方式下的总耗时：原流程耗时，与 AI 辅助后人工操作、等待、复核及返工的总耗时。两者的差，才更接近可释放的时间。

再把模型调用、检索存储、开发集成、监控维护等成本纳入评估。节省的时间也不应直接等同于现金利润：它是否用于处理更多需求、减少加班，或者改善服务质量，还需要业务验证。

对于增长和质量类场景，则应观察转化、缺陷、满意度等与目标直接相关的指标，而不是强行统一折算为“节省了几个人”。

实施时，我更建议分阶段推进：先记录现有流程的基线，再用包含正常和异常情况的代表性样本做离线评测；随后影子运行，只给建议、不改变正式业务结果；确认质量和成本达到事先约定的要求后，再逐步放量。

样本要尽量与真实任务一致，并留出没有参与调优的测试集。上线后仍要监测变化。如果质量下降、复核负担增加或发生越权，应缩小范围、暂停相应操作或切回原流程，而不是只靠继续调提示词维持运行。

验收标准要在试点前约定，而不是等结果出来以后，再挑一个最好看的指标。

六、对技术从业者来说，机会在“把最后一段路接起来”

模型、RAG、Agent、工具协议都值得学，但学习成果不必只是一张功能清单。更有说服力的成果，是一个说得清输入、输出、权限、失败处理和验证方法的完整案例。

你可以从身边一个反复出现的小问题开始：找资料、核对附件、整理工单，或者补充回归测试。把原流程画出来，找到最值得改善的一步，再决定用什么技术。

如果问题本质上是固定规则，用普通程序解决并不落后；如果资料缺失，先补资料也不是绕远路。真正重要的是解决问题，而不是让每个环节都出现 AI。

我更看重的企业 AI 落地，不是演示时有多惊艳，而是离开展示环境之后，仍有人愿意使用、有人负责维护，并能持续验证它带来的改善。

你所在的团队，有哪一项工作值得先做这样的试点？不妨从“最耗时、最重复、又有办法验收”的那一步开始讨论。