企业官网建设流程全解析

关于 AI 泡沫的争论，每隔一段时间就会出现一次“爆款”。Ed Zitron 是这类批评声音里很有代表性的一位。他的核心观点概括起来并不新鲜：很多 AI 产品没有真实需求，模型公司烧钱规模巨大，技术成果可能只是资本叙事。这个判断听起来很有逻辑，尤其在 C 端产品增长放缓、明星模型商业化困难的时候，几乎每个开发群里都会有人转发类似观点并感慨“这次可能真的是泡沫”。

我对这种质疑持保留态度，不是因为它提醒估值风险不对，而是因为它衡量 AI 的方式停留在两年前。Ed Zitron 的批评几乎都落在“聊天机器人使用体验”和“公司财务模型”上，却很少认真看待模型接入生产系统之后发生的变化。过去一年我观察到的行业信号不是“用户不再玩 AI”，而是 AI 正在从聊天工具变成可以被评估、被灰度、被回滚的软件模块。这才是判断 AI 是否有真实价值时更值得关注的维度。

这篇文章不打算证明“所有悲观论都错了”。技术圈需要泡沫警告，否则容易在概念炒作里过度投入。但我想把争论拉回工程界面：当你不再以日活、下载量、发布会演示来衡量 AI，而以推理成本、任务完成率、失败回退、可观测性来衡量时，会看到一条完全不同的曲线。读完这篇文章，你可以得到一套更完整的判断框架，也可以通过一个最小实验验证你所在团队的 AI 流程到底有没有用。

1. Ed Zitron 的批评结构：真正错在评价坐标系

1.1 批评声音中很有价值的部分

先说他“对”的地方。如果只看一个模型公司的收入模型和估值，确实会发现很多不对等：训练一次大模型的成本极高，而应用层的付费意愿仍然脆弱。AI 行业存在明显的“军备竞赛”特征，模型能力一旦被开源社区追平，闭源厂商的定价权就会迅速削弱，这是今天很多 AI 公司面临的实际经营问题。

Ed Zitron 式的批评者敏锐地捕捉到了这一点。他们提醒创业者不要天真地认为“只要有 AI 就能带来增长”，也提醒企业不要在没有评估指标的情况下空转一个 AI 系统。这种警惕性对技术行业是有益的，它会让预算决策者从“要不要跟风”变成“凭什么相信它能产生回报”。

如果所有讨论都像这样停在“财务与营销层面”，我会认为这是一个健康的预警机制。

1.2 被忽略的工程时间差

问题出在这一步之外。批评者普遍把 2022 到 2024 年的用户体验当作 AI 技术能力的终局，用“聊天机器人留存率不高”推出“AI 没有实用价值”。这是一个典型的评价坐标系错位。

任何通用技术进入产业时都会经历一个时间差。第一代应用往往直接复刻旧的交互模式，比如把人工搜索改成对话框搜索，把规则问答改成生成式问答。用户一开始觉得惊艳，随后很快疲劳，接下来会问：它到底替我解决了什么问题？这个阶段确实会看到增长回落，但这不代表底层技术没有意义。更准确的解释是，人们仍然在寻找和底层能力匹配的交互形态。

等这个时间差过去之后，AI 的价值会移动到平时不容易被用户看见的模块里：它帮你把 10 万份客服工单先分类一遍，帮你把需求文档转成测试用例，帮你在 CI 阶段分析一次变更可能影响哪个模块，帮你在检索库中把知识切块后再送入生成流程。这些都不是“聊天机器人日活”能反映的指标，但它们是真实的工程生产力。

1.3 认知差异：消费者技术 vs 基础设施技术

聊天机器人属于消费者技术，而大模型在今天更像一种基础设施计算单元。消费者技术要回答“用户为什么每天打开”，基础设施技术要回答“处理每单位任务需要多少成本、多少延迟、多少人工复核”。

用消费者技术的指标衡量基础设施技术，自然会得出“没有需求”的结论。今天我们不会问“数据库为什么没有留存率”，也不会问“消息队列为什么不够有趣”，但会关心它们的吞吐、稳定性和运维成本。AI 进入成熟期后应该被当成一种新型的“软件构建原材料”，而不是另一个互联网应用。

这正是我判断 Ed Zitron 观点存在结构性问题的地方。他指出的财务泡沫可能为真，但他用来证明“AI 无用”的证据，大多数只适用于消费级聊天机器人这一个早期品类。

2. 为什么用“聊天机器人日活”衡量 AI 是过时的坐标系

2.1 从单轮对话到多工具调用

两年前的 AI 应用大多是单轮问答：用户给一句话，模型补一个后续，然后退出。这种形态的留存天然不稳定，因为高频需求有限，模型也无法主动改变业务流程。批评者看到的“用户玩几天就不再玩”，就是这种交互形态的直接结果。

今天工程上更有价值的使用方式已经变成多步骤工具调用。用户提出一个目标，模型把目标拆解为多个子任务，然后按顺序调用检索模块、业务 API、数据库查询或代码解析器等外部工具，再把结果汇总成最终输出。这个流程不再像一个聊天窗口，更像一个自动化工作流，而用户关心的也不是每一轮“对话是否有趣”，而是最终那个任务是否被完成。

举个例子：一个客服 Agent 收到用户投诉后，要完成用户意图识别、订单状态查询、退款政策匹配、生成回复文案、提交工单这五步。每一步都可能调用不同的系统，最终以工单关闭率作为评估指标。这时讨论“用户是否愿意一直和它聊天”就变得很奇怪了，用户当然不想和系统聊天，用户只想知道退款进度。

2.2 RAG、Agent、MCP 为什么不是营销词

经常被讨论的 RAG（检索增强生成）并不是一种新玩法，而是一种降低成本、控制幻觉的工程手段。它让模型在生成答案前先从企业知识库中检索相关片段，然后再基于片段作答。没有 RAG 的方案要求模型记住所有业务知识，这既昂贵又不稳定。

Agent 则把模型从“文本生成器”升级为“任务规划器”。它不一定要自己完成所有动作，而是学会调用搜索结果、代码解释器、业务 API，并在失败后尝试别的路径。MCP（模型上下文协议）一类的标准化尝试，本质上是在给不同工具定义统一的接入格式，让 Agent 不再每个项目重写一套函数调用协议。

这些概念并不解决“用户会不会聊天”的问题，却决定了模型能否真正进入业务流程。

2.3 观察窗口不同的两种结论

如果观察窗口停留在对话文本，AI 很容易被描述成“成本高昂的自动补全”。如果观察窗口放到端到端的任务链，AI 是在替代过去需要大量 if else、状态机、规则引擎和人工运营才能维护的自动化系统。

同样一个模型，嵌入不同的技术架构，产出的效果差异可能非常大。这也解释了为什么有些团队觉得大模型只是玩具，有些团队却已经在用几个小模型组合解决过去需要上百条规则才能解决的事。真正拉开差距的不是模型本身，而是工程系统是否把模型放进了正确的位置。

3. 成本曲线：决定 AI 是否有真实价值的关键变量

3.1 成本下降往往比舆论转向更真实

每次“AI 泡沫论”出现，都有很多人举出“某次推理调用成本为何这么高”的例子。这里的逻辑容易误导人：他们常拿超大参数模型的定价作为全部 AI 成本的代表，但工程上真正推动采用率增加的，是成本曲线的快速下移。

一个稳定健康的 AI 系统不会在所有请求上都调用最强模型。系统会根据问题难度做路由，简单的分类任务交给小模型，复杂推理任务才交给更大模型。加上量化、蒸馏、缓存等工程手段，使得很多曾经“算不过来”的任务逐渐变得经济上可承受。

从公开的模型定价趋势可以看出，同一类任务用成熟的中小模型处理，成本比早期拼接出来的解决方案有明显下降。这个变化不依赖某一家公司的营销，而是由芯片效率、模型结构优化、推理框架成熟度共同推动的。

3.2 部署形态决定真实技术成熟度

判断 AI 是不是泡沫，除了看财务数据，还需要看人们如何部署模型。

模型部署通常有几个层次：调用公有云 API、在私有云中运行开源权重模型、在本地工作站模型跑批任务、在边缘设备上使用量化后的轻量模型。每一层都代表一种工程实践场景。如果 AI 只停留在浏览器搜索引擎的聊天窗口里，支撑不了太多产业链；但当企业开始把模型权重放进自己的 Kubernetes 集群、给不同部门分配配额、监控推理失败率时，它就已经成为系统架构的一部分。

从实践变化来看，越来越明显的趋势是“默认不自己预训练，而是选择开源基座模型并做领域微调”。这与两三年前“只要堆算力就能做出大模型”的叙事有很大差异。真正把 AI 做出生产力的团队，往往不是在训练新大模型，而是在配置已有模型并让它稳定运行。

3.3 一个最小接入示例：用兼容接口统一调用不同模型

为了让讨论更具体，下面通过一个最小示例展示 AI 如何成为可以被代码调用的模块。这里的调用协议采用常见的 OpenAI 兼容接口，无论你接云端服务，还是接本地通过 vLLM、Ollama 等工具启动的模型，都可以用类似结构。

# llm_call.py import os import time import requests def chat( prompt: str, model: str = "local-qwen2.5-7b-instruct", max_tokens: int = 1024, ) -> tuple[str, float, dict]: """调用一个兼容 /v1/chat/completions 的模型接口。 返回： content: 模型回复文本 elapsed: 调用耗时（秒） usage: 接口返回的 token 用量 """ endpoint = os.getenv("AI_ENDPOINT", "http://localhost:8080/v1/chat/completions") api_key = os.getenv("AI_API_KEY", "") headers = {"Content-Type": "application/json"} if api_key: headers["Authorization"] = f"Bearer {api_key}" payload = { "model": model, "messages": [{"role": "user", "content": prompt}], "temperature": 0.1, "max_tokens": max_tokens, } start = time.time() resp = requests.post(endpoint, headers=headers, json=payload, timeout=60) resp.raise_for_status() elapsed = time.time() - start data = resp.json() content = data["choices"][0]["message"]["content"] usage = data.get("usage", {}) return content, elapsed, usage

这个封装看起来简单，但在工程上已经有三个可观测点：调用耗时、返回文本、token 用量。只要把这三项记录到日志或监控系统，AI 请求就不再是不可解释的黑盒。

运行命令可以是：

export AI_ENDPOINT=http://localhost:8080/v1/chat/completions export AI_API_KEY= python -c "from llm_call import chat; content, latency, usage = chat('请用一句话解释大模型部署中的量化是什么意思'); print(content); print(latency); print(usage)"

如果接口返回正常，会看到一句模型解释，外加耗时和用量。如果启动失败，第一步应该检查AI_ENDPOINT对应的服务是否真的在监听端口，以及模型名称是否与后端实际加载一致。

3.4 成本拆解计算公式

一个更完整的成本验证方式，是把请求量、单次输入 token、单次输出 token 和部署成本放到同一个表达式里。

# cost_estimate.py def estimate_monthly_cost( requests_per_month: int, avg_prompt_tokens: int, avg_output_tokens: int, prompt_price_per_million: float, output_price_per_million: float, fixed_cost: float = 0.0, ) -> dict: """估算按月调用某个模型 API 的直接费用。""" prompt_tokens_total = requests_per_month * avg_prompt_tokens output_tokens_total = requests_per_month * avg_output_tokens prompt_cost = prompt_tokens_total / 1_000_000 * prompt_price_per_million output_cost = output_tokens_total / 1_000_000 * output_price_per_million total_cost = prompt_cost + output_cost + fixed_cost return { "monthly_prompt_tokens": prompt_tokens_total, "monthly_output_tokens": output_tokens_total, "monthly_cost": round(total_cost, 2), } if __name__ == "__main__": result = estimate_monthly_cost( requests_per_month=100_000, avg_prompt_tokens=800, avg_output_tokens=200, prompt_price_per_million=2, output_price_per_million=8, fixed_cost=100, ) print(result)

这个脚本的意义不在于得出一个精确财务数字，而在于提醒你：上线任何 AI 功能之前，必须把 token 用量当成数据库查询次数一样对待。当你能把一次任务的成本算清楚，你也就具备了回答“AI 是否值得用”的基本能力。

4. 反泡沫实验：怎样证明一条 AI 流程真的有效

4.1 不要争论概念，先建立评测基线

“AI 到底有没有用”不应该停留在观点交锋上。更务实的做法是选择一个具体的重复性任务，建立离线评测集，然后测量模型改造前后的效果差异。这就像给 AI 写单元测试一样，先定义什么是“它答对了”，再让模型反复跑。

建议选择的第一个任务要有三个特点：第一，你已经有历史数据或业务答案，可以标注答案；第二，任务本身会反复出现，而不是一次性需求；第三，结果的正确性可以由人工快速复核。例如客服工单分类、退款原因归类、日志异常类型判断，都很适合作为新手实验。

4.2 准备一个小型评测集

下面用一个非常简单的“客服诉求分类”任务来演示。先把少数几条实际案例放入 JSON 文件：

[ { "id": "case-001", "text": "我刚付款就取消了订单，为什么一直没有给我退款？", "expected": "退款申请" }, { "id": "case-002", "text": "我收货地址填错了，能帮我改成公司地址吗？", "expected": "订单修改" } ]

评测脚本会逐个调用模型，判断模型输出是否落在期望类别中。为了让结果更稳定，可以在 prompt 中要求模型只输出类别，不要展开解释。

# eval_classify.py import json import os from llm_call import chat LABELS = ["退款申请", "订单修改", "账号安全", "其他"] def classify(text: str) -> str: prompt = ( "请判断以下客户诉求属于哪个类别。\n" "可选类别：退款申请、订单修改、账号安全、其他。\n" "只输出一个类别词，不要解释。\n" f"客户原文：{text}" ) content, _, _ = chat(prompt, model=os.getenv("MODEL_NAME", "local-qwen2.5-7b-instruct")) content = content.strip() for label in LABELS: if content == label or content.startswith(label): return label return "其他" def main(dataset_path: str) -> None: with open(dataset_path, "r", encoding="utf-8") as f: cases = json.load(f) total = len(cases) correct = 0 wrong_cases = [] for case in cases: pred = classify(case["text"]) if pred == case["expected"]: correct += 1 else: wrong_cases.append({"id": case["id"], "expected": case["expected"], "pred": pred}) print(f"数据集样本数: {total}") print(f"正确数: {correct}") print(f"准确率: {correct / total:.2f}") print(f"错误案例: {wrong_cases[:5]}") if __name__ == "__main__": main("eval_dataset.json")

运行方式：

python eval_classify.py

预期输出不是“某个神奇分数”，而是一个可以直接对照的准确率。如果准确率低于预期，通常不是模型“不聪明”，而是问题定义不够清楚、标注标准不一致，或者 prompt 没有限制输出格式。这时候应该先检查少数错误案例，观察模型输出的真实形态。

4.3 先关心趋势，再追求绝对值

任何小规模评测集都会存在过拟合风险。你请模型处理 20 条案例得到 90% 准确率，但它未必能推广到全部线上请求。所以更稳妥的做法是给这个实验增加两个维度：

第一个维度是先做小批量人工复核。把无法判断题干的案例收集起来，由业务人员写批注。这个动作看起来原始，却是 AI 项目里最有价值的数据积累。第二个维度是把离线准确率和线上业务指标分开记录。分类任务对应“人工二次复核率下降了多少”，生成任务对应“编辑修改率下降了多少”。只有当线上业务指标发生变化时，才能证明 AI 确实贡献了价值。

这也是“AI 是泡沫论”中最常忽略的部分。许多批评只看到模型当前还存在错误，却不理解工程实践正是在错误中建立评估和校正机制的。

5. AI 编程：最容易验证，也最需要工程纪律

5.1 为什么 AI 编程场景很难用“日活”评估

AI 编程经常被低估为“代码自动补全”。原因是工程师使用的 AI 插件不是每天要打开两次的独立 App，它嵌在 IDE 里，一次代码联想可能只帮助减少了 10 秒查找时间。但如果你统计一个开发团队的“上下文切换次数”，AI 编程的价值会非常明显：它减少了从编辑器切到搜索引擎、再切到文档站点查找语法的频率。

真正发挥作用的不是“让 AI 直接写完整功能”，而是“让 AI 在明确约束下完成一个小步骤”。比如写单元测试、生成数据迁移脚本初稿、将一段老旧代码翻译成新版本语法、解释一段难以读懂的异常日志。这些任务都有相对固定的正确标准，容易被人工复查，也适合用来建立信任。

5.2 把 AI 代码审查放入 CI 而不只是 IDE

如果把 AI 编程局限在开发者本地，那么很难形成团队级经验。更推荐的实践是让 AI 在 CI 流程里做一次“预检查”。可以先从一段小型 diff 摘要开始：让模型读取git diff的输出，尝试总结变更范围，并标记是否涉及危险函数。

这里的关键不在“AI 能不能替代代码审查”，而在于把 AI 的能力纳入现有工程流程中，保留人类控制权。自动生成代码审阅结果后，仍然需要由人工处理其中的高风险提示。任何直接让 AI 改写并合并代码的做法，在大多数组织中风险都过高。

5.3 不要忽视统计代码被采纳的过程

为了证明 AI 编程有价值，需要统计“AI 建议被采纳的比例”。许多 IDE 插件本身提供了类似的统计，但团队也可以用最原始的方式记录：每次通过 AI 辅助生成并最终提交的代码，都打一个特殊前缀或关联一个任务标签。不要信任“屏幕时间”之类的间接数据，更可靠的是代码提交记录里的引用标识。

当团队统计到某个重复性样板代码的生成采纳率超过 70% 时，通常说明这个场景值得继续投入。如果始终低于 30%，就应该调查是 prompt 约束不够，还是任务类型根本不适合模型处理。这个统计过程本身就是一次管理上的“反泡沫校验”。

6. Agent：AI 工程化的下一层试金石

6.1 Agent 不再只是概念，而是系统设计问题

Agent 的成熟度是判断 AI 是否真进入工程化的又一关键指标。所谓 Agent，不是说给模型一个开放权限让它随意行动，而是给它定义一组受限工具、一套调用策略、若干失败返回路径，并记录所有中间决策。当模型只能在允许的工具范围内行动时，它才算是可以进入生产系统的软件组件。

一个典型的 Agent 由四个部分组成：模型、工具集合、任务规划器、安全边界。模型负责理解任务和生成下一步动作，工具包括搜索、数据库查询、HTTP 请求等，任务规划器决定先调用哪个工具，安全边界限制模型能访问的资源和可执行的高风险操作。

6.2 高风险工具必须默认关闭

这种能力很容易被误解为“Agent 什么都能做”。实际工程中恰恰相反，越是自动化能力强的系统，越需要细化权限。默认情况下，Agent 应该只能读取白名单数据，不能执行修改、删除、退款、发布等高风险操作。

下面给出一个最小配置示例，重点不是为了复刻某个框架，而是表达一种权限设计思路：

# configs/customer_agent.yaml agent: name: customer-refund-agent model: fast-model fallback_model: strong-model max_steps: 6 timeout_ms: 15000 tools: - name: search_order permission: read timeout_ms: 3000 allowed_operations: - "GET /api/v1/orders" - name: create_ticket permission: write timeout_ms: 5000 allowed_operations: - "POST /api/v1/tickets" - name: refund permission: disabled # 高风险操作默认不开放

在这里，“refund”被显式关闭。即使模型规划出退款动作，系统也会因为工具权限不足而拒绝执行。这个设计的重要意义在于：Agent 的价值不是“完全代替人”，而是“在有限权限内帮助人更快完成任务”。

6.3 Agent 必须有日志链路和人工可干预切口

Agent 和普通 API 调用的最大区别在于，它会连续进行多次工具调用，并产生一个决策路径。如果这个过程没有日志，一旦出现错误，排查难度会迅速上升。

生产级 Agent 至少应该记录四类信息：每次模型生成的原始消息、每个工具的入参与出参、每次调用的耗时、最后的终止原因。这样当业务方反馈“某个 Agent 结果不对”时，可以回放这个决策序列，找出是模型理解错了、工具返回异常，还是权限配置阻止了正确操作。

对任何涉及资金、数据删除、权限变更的 Agent 动作，都应该加入“人工确认”的闸门。这不能靠提示词里的“请你先询问用户”来实现，而应该在系统流程中强制增加审批节点。

7. 常见误区与问题排查

7.1 误区对照

AI 讨论中经常出现几个重复性误区，这里用一张表说明我的判断：

7.2 部署与调用排查方法

在 AI 应用落地过程中，最容易遇到的并不是模型幻觉，而是一些枯燥的工程问题。下面是一张排错参考表：

通常情况下，第一步永远是看日志，而不是反复修改提示词。日志里往往已经记录了问题发生的环节。

8. 工程团队可以立刻做的最小实验集

如果你是技术负责人，不需要等外部争论有结论后再决定要不要投入 AI。可以从四个被反复验证过的场景开始做小范围试验。

第一个实验是内部知识库问答。选择 30 个高频问题，让模型从团队已有文档中检索并回答，由核心成员打分。这个实验能直观展示 RAG 的成效和局限。第二个实验是客服或工单分类。准备过去 2 周的工单，用模型打标，再与人工标签对比。这里能得到清晰的准确率和召回率。第三个实验是代码变更摘要。拉取最近 20 个拉取请求的 diff，让模型生成摘要，观察有多少可以直接用于 code review。第四个实验是错误日志初筛。让模型判断一批异常日志的紧急等级，和运维人员的判断对比。

所有实验都要设置“不通过时的退出条件”。如果准确率低于 60%，就暂时不上线；如果在 60% 到 80% 之间，考虑加入人工复核流程；只有超过一个预设阈值，再加上业务指标改善后，才进入生产。这个流程能有效防止 AI 项目变成一场长期赌注。

团队纪律同样重要。每个 AI 项目都要明确所有者、记录错误案例、保存模型配置版本，并且不把 prompt 当作无法管理的魔法字符串，而是存入版本库，像代码一样审查。只有这样，当模型或服务升级时，团队才能快速定位是数据变了、prompt 变了还是模型权重变了。

9. 写在最后：不要急着给 AI 下终局结论

Ed Zitron 式批评的价值在于提醒所有人：AI 不是一个“只要贴上去就能增长”的词。但技术演进并没有停在“聊天机器人”的早期阶段。如果你只站在用户产品体验和短期收入模型的外面观察，看到的当然全是泡沫；如果你进入系统内部，把 AI 作为需要评测、部署、监控和保护的工程模块，看到的则会是一条仍然陡峭的生产力曲线。

我更愿意相信的判断是：这一轮 AI 的价值不在于诞生了多少个爆款 Chatbot，而在于它让很多过去只能靠人肉分类、规则引擎和大量低质量文档堆砌的任务，第一次具备了自动化处理的可能性。这与“模型是否已经接近人脑”无关，也与“公司估值是否过高”无关，它只取决于一个简单问题：你的系统是否真的因此降低了完成某项任务的复杂度。

对开发者和技术团队来说，最好的回应不是在网上争论谁对谁错，而是回到自己的业务里，选一个最少十次会出现一次的重复任务，建立评测集，跑通基线，记录成本，再决定下一步。建议你先收藏这篇文章，按照评测脚本的思路建一个最小验证，而不是急着在讨论区站队。只有当你能用数据证明“引入 AI 后某个指标发生了变化”，你才真正参与了这场技术演进的验证。