企业官网建设流程全解析

李继刚提出的“AI 生成无法替代言说事件”这个判断，初看像是一个哲学断言，但放到大语言模型的实际落地场景里，它有一个非常具体的工程含义：一段文本被“生成出来”，和一段文本被“真实地说了出来”，是两个不同的事件状态。很多 AI 应用的翻车现场，并不是模型文笔差，而是把第一阶段生成的文本直接当成了第二个阶段的言说事件来处理。

这个判断值得展开讨论的地方在于：它并不是说 AI 生成的文字没有价值，而是说文字生成与“言说”之间存在机制性差异。这个大模型应用每天都要面对的问题，恰恰是被许多团队忽视的部分。如何把“言说事件”这个概念翻译成技术需求，如何设计出“辅助言说”而不是“替代言说”的 AI 系统，是这篇文章要讨论的主线。

1. 先把“言说事件”从哲学话题翻译成技术话题

1.1 言说事件不只是一段文本

讨论 AI 生成能否替代言说事件，首先要明确一件事：言说事件不是“一段话”本身。它至少包含五个要素：

• 有说话者：这句话是谁说的，谁为这句话负责。
• 有听众：这句话是对谁说的，听众会如何理解。
• 有时空场合：这句话在哪个时间、哪个地点、什么背景下说出来。
• 有意图行为：说这句话是为了承诺、声明、请求、道歉还是命令。
• 有后续效果：说完之后，双方的关系、权利、义务、行动会发生什么变化。

用一个例子对比。用户在某个系统里填写退订申请，AI 生成一封“我已经帮您处理退订”的回复。如果这个回复只是生成出来，并没有触发真实的退订流程，那它就是“有文字、无事件”。用户收到文字，以为事情已经完成，实际业务状态并没有变化。这就是把 AI 生成误当成言说事件最典型的场景。

所以“言说事件”本质上是一个“行为过程”，文本只是这个行为过程的载体和痕迹。技术系统如果只建模文本，不建模行为，那么无论生成质量多高，都不等于完成了一次言说。

1.2 语言生成模型到底在做什么

大语言模型的基本能力是：根据前面的 token 序列，预测下一个 token 的概率分布，然后采样或贪心选择生成后续文本。这个机制有一个关键特点：模型处理的对象是“文本符号”，不是“真实世界的事实”和“说话者的状态”。

模型学习的是语料中文本与文本之间的统计关联。它可以生成“我已确认你的工单已解决”这样一句语法通顺、语义合理的文字，也可以生成“我承诺明天下午三点前修复”这样的句子。但从机制上看，模型并没有完成一个承诺行为，它只是完成了一组 token 的排列。

这里不是说模型没有理解能力，而是说“生成一个承诺句”和“做出一个承诺”在行为逻辑上是两回事。输出一段文本，不自动携带说话者身份、真实语境、行为后果和外部世界联动。这个区别在开发聊天机器人、客服系统、Agent 应用时尤其重要，因为产品一旦让 AI 以品牌身份对外发言，用户会默认把生成文本当作真实言说事件，后续责任就落在产品方和企业方身上。

1.3 一个最小对比：文本生成与真实言说

可以把“AI 生成文本”和“真实言说事件”放在同一张表里对比，方便团队讨论需求时快速对齐：

这个对比不只是理论上的，它直接决定产品设计。客服自动回复、医疗建议、法律文书、家长通知、营销承诺、工单处理，这些场景都需要判断“文本是草稿还是事件”。如果团队没有这个判断，很容易把统计生成当成事实承诺来用。

2. 从大模型机制看 AI 生成的边界

2.1 下一个词预测只能建模文本序列

很多团队开始做 AI 项目时，会默认“只要模型能力强，生成效果就会更好”。这个直觉在草稿生成、翻译、摘要类任务里成立，但在真实言说场景里会有偏差。

原因在于：模型训练目标是最大化下一个 token 的条件概率，它没有在训练时建模“这句话是否真的被执行了”。例如：

用户：我的账号被锁了，请求尽快解锁。 AI：我很抱歉给您带来不便，您的账号已经解锁。

从文本上看，这是一段通顺的客服回复。但如果系统没有实际调用解锁接口，用户下一次登录仍然失败，这段文本就变成了一次无效言说，甚至是一次错误承诺。模型生成这段文字时，并不知道数据库里的账号状态是 locked 还是 active。

所以做工程时，不能把文本生成当作唯一的系统能力。AI 生成文本之外，必须有状态查询、接口调用、人工确认、结果回写等环节，把生成文本和外部的真实事件绑定起来。

2.2 上下文窗口不等于真实语境

上下文窗口越来越大，让不少开发者产生一种错觉：只要把聊天历史、用户资料、业务数据都塞进 prompt，模型就能准确理解真实语境。

上下文窗口解决的是“文本信息容量”问题，不是“真实语境理解”问题。真实语境包括的内容超过文本：用户此时是不是在生气、客服有没有权限、产品当前版本是否支持某个功能、数据库中该用户是否存在、承诺的时间是否在合同范围内。这些信息，一部分可以被文本描述，一部分只能通过外部系统和实时状态获得。

把资料塞进 prompt 不意味着模型理解了它们，更不意味着模型能正确判断它们之间的因果关系。有效的做法是在系统设计上明确：prompt 只负责语言生成和一般推理，外部状态统一通过工具调用和结构化数据源获取，生成结果再用规则或人工把关。

2.3 可验证的边界现象

在实际运行中，可以观察到几类边界现象：

• 索引词错位：AI 生成“今天下午三点”时，它并不指向任何真实的日历日期，除非外部系统注入了当前时间。
• 指代悬空：生成“这位客户”时，如果没有绑定客户 ID，系统内实际存在多个客户，这句话就无法对应到真实对象。
• 承诺过度：生成“免费延长一年会员”时，如果产品后台没有对应优惠券模板和赠予接口，这句话就是无效承诺。
• 口径不一致：生成内容基于训练语料的旧信息，而当前产品文档已经更新，AI 仍按旧规则回答。

这些现象不是偶尔出现的 bug，而是“文本生成”和“言说事件”之间机制差异的必然体现。边界明确之后，工程上的责任也就清楚了：模型负责产出候选文本，系统负责把文本与真实状态绑定，人负责最终确认与对外言说。

3. 为什么 AI 生成无法替代言说事件：四个技术原因

3.1 索引性缺失

索引性指的是语言中依赖语境才能确定意义的部分：我、你、这里、现在、这个、那个、这次、下周。这些词在不同的时空里指代不同对象。模型生成的文本里即使包含这些词，它本身也没有指向真实世界的具体对象。

例如模型生成“我刚才已经帮您查过了”，这句话需要一个真实的“刚才”和一个真实的“查询动作”支撑。如果系统没有记录查询时间、查询人、查询结果和查询日志，这句话就是悬空的。

在技术落地时，可以用实体解析和日志查询来补齐这部分缺失。比如生成文本之前，先查询当前用户信息和操作历史，再用模板把真实信息填充进句子，而不是让模型凭空生成这些信息。

3.2 说话人责任缺失

真实言说有一个重要特征：说话者要为自己的话负责。客服说“我们会退款”，公司就可能因此承担退款义务。医生助理说“这个药没有副作用”，患者就可能据此做决定。建模 AI 系统时，说话人责任不会自动出现在模型输出里，只能靠产品规则、权限控制和审计日志来体现。

这就是为什么银行、医疗、法律、政务等行业的 AI 落地特别谨慎。不是模型不够聪明，而是这些场景对“谁说的、依据什么说的、说了之后谁来承担后果”有明确要求。AI 生成文本之前，系统要能回答这三个问题，否则生成的内容就不具备对外言说的条件。

产品层面的做法是建立“发话人角色”和“话术权限”。内容区分模型生成、客服编辑、用户确认、系统自动回复等不同层级，不同层级对应不同责任和审核流程。

3.3 共同在场与互动节奏缺失

言说事件通常发生在人与人之间，哪怕是线上沟通，也存在基本的信息同步和反馈节奏。说话者会根据对方的反应调整措辞，会停顿，会追问，会澄清。这个过程不是一次性生成“最终文本”，而是持续协商。

AI 对话系统虽然可以多轮交互，但它目前做得更多的是“序列生成”，不是真正的“共同在场协商”。它不太可能感知到用户读到哪一句时产生困惑，也不太会像一个现场说话者那样，主动修正语境理解偏差。

因此，在敏感或复杂场景里，推荐的做法是：AI 承担第一轮信息收集、知识检索和候选回答生成，人类负责最终确认和关键澄清。这样既保留 AI 的生成效率，也保留了真实言说需要的互动性和责任闭环。

3.4 语义由生成概率驱动，不由承诺驱动

模型生成的每一句话，本质上是条件概率分布下的一次采样。它输出的依据是“在训练语料中，这些词经常这样衔接”，而不是“这句话在系统里承诺了一个真实动作”。

这种机制在开放域闲聊里没有太大问题，但在任务型场景中会造成“流畅但不正确”的生成结果。模型可以流畅地编出订单号、处理结果、办理时间，而这些信息完全未经后端校验。

针对这个问题，工程上有几种做法：

• 关键信息不生成，只填充：订单号、金额、时间、状态等字段从结构化数据读入，不让模型编造。
• 生成结果做规则校验：对承诺类动词（承诺、安排、保证、尽快）和数字类信息做额外审查。
• 低置信度场景转人工：当外部状态无法确认时，明确回复“需要进一步核实”，而不是硬生成一个看似肯定的答案。

4. 工程实践：让 AI 辅助言说，而不是替代言说

4.1 先划分场景：草稿、助手、发言者

不是所有场景都需要让 AI 承担“言说者”角色。在项目启动阶段，可以把 AI 的能力按三种身份划分：

这个划分非常重要。同一个模型、同一个应用，如果身份定位不同，系统设计完全不同。草稿助手不需要对接业务数据库，自动发言人则必须对接。

4.2 给生成文本增加“言说态”标记

“言说态”指一段文本当前处于哪一层状态。在系统设计里，可以给每条生成文本打标记：

• draft：草稿状态，未经过任何人确认。
• reviewed：已经有人审核，准备发送。
• executed：已发送或已执行，附带发送时间、发送人、操作日志。
• invalid：被拒绝或被撤销。

这个标记体系可以与数据库字段、日志、审计模块联动。只要一条文本没有进入 executed 状态，就不应该产生任何对外承诺效力。这个设计可以避免“系统自动回复了，但业务没执行”的尴尬。

在实现上，状态机不需要太复杂。一个消息表里至少要有这几个字段：

CREATE TABLE speech_event ( id BIGINT PRIMARY KEY AUTO_INCREMENT, content TEXT NOT NULL, speaker_type VARCHAR(20) NOT NULL COMMENT 'user/assistant/system', responsible_operator VARCHAR(64) COMMENT '对人类审核者的唯一标识', status VARCHAR(20) NOT NULL DEFAULT 'draft', business_id VARCHAR(64) COMMENT '关联订单、工单或客户ID', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, executed_at TIMESTAMP NULL, CONSTRAINT check_status CHECK (status IN ('draft', 'reviewed', 'executed', 'invalid')) );

这里的关键不是表结构多么复杂，而是把“文本”和“文本是否生效”分成两个维度来对待。这样即使 AI 生成了错误文案，系统也可以保证它在真实验证前不产生实际效力。

4.3 设计人机协作流程

在需要真实言说后果的场景里，推荐采用“三明治流程”：

1. AI 生成候选文本。
2. 系统自动做业务状态校验。
3. 人工审核并确认，或者脚本在具备权限的情况下执行。
4. 执行结果回写，生成审计记录。

这个流程不是为了降低效率，而是为了把“生成”和“生效”解耦。AI 的产出永远是候选，不代表行动已经发生。下面的伪代码描述了这一过程：

def handle_user_request(user_id: str, request_text: str): # step 1: 查询真实业务状态 customer = customer_service.get(user_id) order = order_service.get_active_order(user_id) # step 2: 组装上下文，让模型生成候选回复 context = { "customer_tier": customer.tier, "order_status": order.status, "can_refund": order_rule.can_refund(order) } candidate = llm_client.generate_reply(context, request_text) # step 3: 关键字段用结构化数据覆盖，阻止模型编造 candidate = override_field(candidate, "order_id", order.id) candidate = override_field(candidate, "refund_deadline", None) # step 4: 状态校验，不通过则转人工 if not verify_event(candidate): ticket_service.create_review_ticket(user_id, candidate) return "已收到您的需求，我们将进一步核实。" # step 5: 人工确认后进入生效流程 send_to_review_queue(user_id, candidate) return "您的申请已提交，请等待确认。"

这个示例可以按实际项目调整，但核心顺序不能变：先查状态，再生成文本，再覆盖关键字段，再校验，再确认，最后执行。顺序一旦颠倒，文本生成就会脱离业务现实。

4.4 一个可运行的检测 demo

如果团队需要从数据层面排查“一段文本是否具备言说事件特征”，可以先用启发式规则做一个快速扫描。下面示范一个简单的 Python 脚本，用来标记文本中出现了哪些言说索引成分：

import re INDEX_MARKERS = { "第一人称": ["我", "我们", "我方"], "第二人称": ["你", "您", "你们"], "时间索引": ["今天", "明天", "本周", "现在", "刚才", "下周一"], "地点索引": ["这里", "本公司", "会议室", "后台", "平台"], "承诺动词": ["承诺", "保证", "马上", "一定", "负责", "处理完成"], "立场动词": ["我认为", "我方确认", "我们同意", "我们拒绝"] } def scan_speech_event(text: str) -> dict: hits = {} for label, words in INDEX_MARKERS.items(): matched = [word for word in words if word in text] if matched: hits[label] = matched return hits def check_unsupported_promise(text: str, supported_order_ids: set) -> list: order_patterns = re.findall(r"订单[ #]?([A-Za-z0-9-]+)", text) return [oid for oid in order_patterns if oid not in supported_order_ids] if __name__ == "__main__": generated = "我们已经处理完成，您的订单 #A12345 将在今天安排退款，请放心。" print(scan_speech_event(generated)) print(check_unsupported_promise(generated, {"A12345"}))

这个 demo 的价值在于把“言说事件”变成一个可检查的工程指标。生产系统可以升级成调用 NER 模型、外部知识图谱和业务对象解析，但设计思想保持一致：找到文本中暗示“有人负责、有具体时间、有外部动作”的成分，再判断这些成分是否由真实数据支撑。

5. 怎么验证 AI 生成是否破坏了言说事件

5.1 用五个维度做言说事件检查

面对一段 AI 生成文本，团队可以在发布前做五维检查：

任何一项不满足，该文本都只能算作 draft，不能直接对外发送或断言“已解决”。

5.2 自动化可查部分与人工必查部分

自动化检查适合做三类事情：第一，检查时间地点索引是否来自真实字段；第二，检查订单号、金额、用户 ID 等实体是否存在；第三，检查承诺动词是否在高风险名单中。例如“承诺”“保证”“一定”“立即”等词出现，但外部接口没有对应动作，就需要告警。

人工必查的部分包括：生成内容是否符合品牌语气，是否存在法律风险，是否与当前政策一致，是否适合对所有同类型用户统一发送。自动化可以降低低级错误，但无法替代人对“后果”的判断。

5.3 发布前检查清单

实际项目发布前，建议走过下面这个清单：

• 明确每条 AI 对外文本是否需要一个“生效”动作。
• 明确生效动作由哪个系统触发，由谁触发。
• 明确生成文本中哪些字段来自外部系统，哪些字段由模型生成。
• 对“承诺类”表达增加规则钩子，不允许直接输出。
• 所有对外发送文本都有独立的消息 ID 和状态字段。
• 有审阅机制，支持 bot 话术被驳回和重新生成。
• 有撤回或补偿机制，处理 AI 已误发但未实际执行的情况。
• 日志记录提示词、生成内容、审核人、发送时间和业务关联 ID。
• 针对“模型生成内容与业务状态冲突”的告警通道。

这个清单既是开发时的需求确认表，也是上线的测试用例来源。

6. 常见误区与落地建议

6.1 误区一：让 AI 直接扮演发言人

很多团队开发客服机器人时，直接让模型以客服口吻回答，并加上“我们承诺”“我们已经处理”等语式。表面上看体验更好，但一旦生成内容与业务状态不符，用户会认为这是企业官方表态，后续纠纷成本很高。

推荐做法是：让 AI 回答“信息类”问题；让 AI 生成“话术草稿”；涉及状态变更、承诺和退款时，先校验业务状态，转人工确认。不要在未接入业务系统的情况下让 AI 扮演全权发言人。

6.2 误区二：把上下文窗口当成真实记忆

项目组经常说“只要把用户历史全塞进上下文，AI 就有记忆了”。上下文窗口确实能提供历史文本，但不等于模型能准确区分“用户曾经说过”和“用户真实完成过”。更稳妥的做法是让模型只处理自然语言表达，真实的用户行为、订单状态、权限关系都从数据库和接口读取。

6.3 误区三：用 AI 生成逃避言说责任

有些团队认为“反正是 AI 说的，不是人说的”，借此回避责任。这在产品层面是不可持续的。用户在真实场景中对接收到的文字产生信赖，技术系统不能把“AI 生成”当作免责声明。正确做法是明确责任主体，增加人工审核链路，把 AI 定位成效率工具而不是责任载体。

6.4 误区四：只测试“生成流畅度”，不测试“事件完成度”

一些团队验收对话系统时，只确认“回复是否自然”“是否像人话”，却忽略了“这个回复是否完成了真实动作”。这里建议把测试用例从纯文本维度扩展到事件维度：

输入：用户申请退款 期望事件：创建退款单，生成退款编号，状态从申请中进入审核中 禁止事件：生成退款成功文案，但没有创建退款单

每个测试用例至少包含一个“必须发生的外部事件”和一个“禁止发生的虚假事件”。只有通过这类测试，AI 系统才算具备真实业务能力。

6.5 学习环境与生产环境的差异

学习工程实践时，可以先用简单的 Flask/FastAPI 示例、一条业务表、一个模拟接口来跑通“生成 - 校验 - 确认 - 执行”链路。学习环境不需要完整权限体系和审计模块，重点在于理解“文本与事件分开”的设计思想。

生产环境需要额外补齐：可观测性、操作日志、权限隔离、敏感内容过滤、限流与容灾、模型版本管理、人工审核队列、回滚机制和告警。任何一个环节缺失，AI 生成内容再流畅，都难以承担真实言说事件带来的业务后果。

这个判断真正值得记住的地方是：AI 生成解决的是“如何快速得到一段可用的文字”，言说事件解决的是“这段文字如何可靠地影响真实世界”。两者不是竞争关系，而是先后关系。技术系统先负责高质量生成，再负责事件化落地，最后让人来承担责任。缺掉任何一环，AI 项目都会止步于“看起来能用”，而不是真正在业务里站住脚。