企业官网建设流程全解析

从 3 天做出 Demo，到 3 个月上不了线，我总结了 7 个比提示词更致命的问题

过去一年，我见过太多 AI 应用团队：

3 天做出 Demo，演示时全场惊艳；

3 周后内部试用，问题开始冒出来；

3 个月后还没上线，提示词改了 80 多版。

如果你问他们：“AI 应用开发最难的是什么？”
十有八九会回答：“写提示词。”

但真正做过生产级 AI 应用的人，往往会沉默一下。

因为最难的不是写提示词，而是：

当模型输出不确定时，你的系统如何仍然可靠、可控、可迭代、可赚钱。

提示词很重要，但它只是冰山露出水面的那一角。水面之下，是评估、数据、上下文、工具、架构、成本、延迟、安全、产品设计和组织协作。

这篇文章，我想把“AI 应用开发”从提示词神话里拉出来，聊聊真正决定项目生死的东西。

一、为什么大家都觉得提示词最难？
因为提示词最可见。

模型效果不好，第一反应是：
“是不是提示词没写好？”
“加一句‘请一步一步思考’试试？”
“再强调一遍‘不要幻觉’。”

提示词确实能解决一部分问题。它门槛低、反馈快、看起来像魔法。改几个字，模型输出立刻变化，这种即时反馈很容易让人上瘾。

但这也带来一个危险：把系统问题误判成提示词问题。

我见过一个真实案例。

一个客服 AI 项目，团队花了两个月优化提示词。角色、语气、边界、示例、格式，全都打磨得非常精致。Demo 阶段几乎完美。

上线后第一周，用户投诉暴涨。原因不是提示词，而是：

RAG 检索经常召回旧政策；

工具调用超时后没有降级；

模型返回的 JSON 偶尔多一个逗号，前端直接白屏；

用户问“我的订单呢”，系统没有权限校验，差点泄露他人信息；

高峰期 p95 延迟 12 秒，用户早就关掉窗口。

提示词写得再好，也救不了这些工程问题。

所以第一句话：

提示词是接口，不是系统。提示词是钥匙，不是房子。

二、Demo 和生产之间，隔着一条“不确定性鸿沟”
Demo 的逻辑是：只要有一次惊艳，就算成功。
生产的逻辑是：只要有一次严重失败，就可能崩盘。

这两个目标完全不同。

维度 Demo 生产
目标 惊艳 稳定
数据 手工样例 真实分布
评估 感觉不错 指标 + 回归
失败 重试一下 降级 + 人审
成本 不计 每请求成本
延迟 能等 p95 必须达标
迭代 改提示词 实验平台 + 版本管理
安全 先忽略 护栏 + 审计
用户 围观者 付费者
AI 应用开发和传统软件最大的区别是：模型是概率系统，业务是确定系统。

传统后端可以假设：输入 A，经过逻辑 B，得到输出 C。
AI 应用必须假设：输入 A，经过模型 B，可能得到 C、D、E，甚至一段乱码。

所以，AI 应用开发的核心不是“写出完美提示词”，而是：

在概率模型之上，构建确定性业务能力。

三、真正难的是这 7 件事

1. 定义“好”：没有评估集，你只是在盲调
   这是最被低估、也最致命的一环。

很多团队优化提示词的方式是：
改一版，试几个问题，感觉不错，上线。
再改一版，试几个问题，感觉更好，上线。

这不是工程，这是玄学。

你需要一个黄金评估集：

从真实用户日志里采样 100～500 条；

覆盖高频、低频、边缘、对抗、多轮场景；

为每条定义期望输出或通过标准；

每次改提示词、换模型、调 RAG，都跑一遍回归；

线上再做 A/B 和在线指标。

一个最小评估流程长这样：

python
for case in golden_set:
output = app.run(case.input)
assert check_format(output)
score = judge(case.expected, output)
record(score, latency, cost)
没有评估集，你永远不知道：
这次改动是变好了，还是只是碰巧。
模型升级是提升，还是灾难。

提示词不是护城河，评估集才是。

2. 上下文工程：不是塞得多，而是塞得对
   很多人把 RAG 当成“把文档切块、向量检索、塞进提示词”。

但生产级上下文工程远不止这些。

一次模型调用里，上下文可能包括：

系统指令；

用户当前输入；

多轮历史；

检索到的知识；

工具返回结果；

用户权限与画像；

业务规则；

输出格式约束；

安全策略。

难点在于：

哪些该放？哪些不该放？

怎么排序？怎么压缩？

冲突信息听谁的？

Token 预算怎么分配？

检索错了怎么办？

历史太长怎么摘要？

权限不同，上下文是否隔离？

上下文不是越多越好。塞太多，模型会迷失；塞太少，回答不准确；塞错，直接幻觉。

上下文工程的目标，是在有限 Token 里，给模型最相关、最可信、最可执行的信息。

3. 可靠性工程：模型会错，系统不能崩
   生产系统必须接受一个事实：模型一定会出错。

所以你要设计：

输出格式校验：JSON Schema、正则、类型检查；

业务规则校验：金额、权限、库存、状态机；

失败重试：换模型、换提示词、重新检索；

降级策略：模板回复、规则引擎、转人工；

幂等设计：工具调用重复执行不产生副作用；

超时控制：不能让用户等 30 秒；

审计日志：每次调用可追溯。

举个例子。

模型要调用“退款工具”。它可能：

参数格式错；

金额多一个零；

对没权限的订单发起退款；

重复调用两次。

这时候，不能靠提示词说“请小心”。要靠工程：

参数 Schema 校验；

权限二次确认；

金额上限；

幂等键；

人工审核阈值。

提示词负责“尽量对”，工程负责“错了也不崩”。

4. 成本与延迟：AI 应用也要算账
   Demo 时没人关心成本。
   生产时，每一条 token 都是钱。

一个请求如果调用大模型 3 次、RAG 检索 2 次、工具 4 次，成本可能从 0.01 元变成 0.5 元。日活 1 万，一天就是 5000 元。

延迟同样致命。

用户能接受的等待时间，通常只有几秒。模型再聪明，如果 p95 延迟 15 秒，产品就是不能用。

常见优化手段：

模型路由：简单任务小模型，复杂任务大模型；

语义缓存：相似问题直接命中；

流式输出：先给反馈，再补内容；

并行工具调用：减少串行等待；

上下文压缩：减少无效 Token；

批处理：离线任务合并请求；

预算控制：按用户、租户、场景限额。

不会算账的 AI 应用，活不过规模化。

5. 数据飞轮：没有反馈，就没有进化
   AI 应用不是“上线即终点”，而是“上线才开始”。

你需要把用户反馈变成数据：

显式反馈：点赞、点踩、纠错、评分；

隐式反馈：是否复制、是否采纳、是否转人工、是否重试；

业务反馈：转化率、解决率、退款率、投诉率；

人工标注：坏案例、好案例、边界案例。

然后把这些数据回流到：

评估集；

提示词迭代；

RAG 知识库；

模型微调；

路由策略；

产品交互。

没有数据飞轮，你的 AI 应用永远停在第一版。

模型不是护城河，数据飞轮才是。

6. 产品化：用户要的不是模型，是结果
   很多 AI 应用失败，不是技术不行，而是产品不行。

用户不关心你用的是 GPT、Claude 还是自研模型。
用户只关心：

能不能帮我完成任务？

我敢不敢信？

出错了我能不能控制？

能不能解释为什么？

能不能一键修正？

能不能转人工？

所以产品设计要回答：

什么场景用 AI，什么场景不用？

如何展示不确定性？

如何让用户确认关键操作？

如何提供引用来源？

如何让用户纠正？

如何兜底？

一个没有“转人工”按钮的客服 AI，是不成熟的。
一个不能查看引用来源的 RAG 问答，是危险的。
一个自动执行高风险操作的 Agent，是灾难。

AI 产品不是聊天框，而是被重新设计的工作流。

7. 可观测与迭代：看不见，就管不了
   生产环境必须能回答：

这次回答为什么这么生成？

检索到了哪些文档？

调用了哪些工具？

消耗了多少 Token？

延迟卡在哪一步？

哪个提示词版本？

哪个模型版本？

失败原因是什么？

哪些用户受影响？

你需要 Trace、日志、指标、告警、版本管理和实验平台。

没有可观测性，你就像在黑暗中修飞机。

四、一个从 Demo 到生产的 6 层框架
我习惯把 AI 应用拆成 6 层：

任务层：用户是谁？要完成什么？成功指标是什么？

模型层：用哪个模型？路由策略？提示词版本？微调？

上下文层：RAG、记忆、工具、权限、状态。

控制层：护栏、校验、重试、降级、人审。

评估层：黄金集、回归、A/B、在线指标。

运营层：监控、成本、延迟、反馈、数据飞轮。

提示词在哪？
在模型层，只是一小部分。

如果你只盯着提示词，就像只盯着汽车的方向盘，却不管发动机、刹车、轮胎和油箱。

五、提示词到底该怎么写？
写到这里，不是说提示词不重要。
它很重要，但别把它当全部。

好的提示词，应该像一份可执行的接口文档：

text
角色：你是谁
目标：要完成什么任务
上下文：你可以使用哪些信息
约束：不能做什么，边界在哪
输出格式：必须返回什么结构
失败处理：信息不足时怎么办
示例：好例子和坏例子
版本：v1.2.3
更重要的是：

提示词要版本化；

提示词要进评估；

提示词要可回滚；

提示词要能 A/B；

提示词要和模型、RAG、工具一起调。

提示词不是文案，是代码。评估不是可选，是基础设施。

六、给 AI 应用开发者的 10 条行动清单
先定义成功指标，再写第一行提示词。

建一个 100 条起步的黄金评估集。

每次改动都跑回归，不靠感觉。

把 RAG 当检索系统，不当魔法。

给所有模型输出加格式校验。

给所有高风险操作加权限和确认。

给所有工具调用加超时、重试、幂等。

监控每请求成本、p95 延迟、失败率。

设计用户反馈和坏案例回流机制。

记住：模型会错，系统不能崩。

七、结语：提示词是钥匙，系统才是房子
AI 应用开发，最难的不是写提示词。

最难的是：

在不确定的模型之上，构建确定的业务；
在有限的成本里，提供稳定的体验；
在复杂的场景中，守住安全和边界；
在快速的变化里，保持迭代和进化。

提示词是钥匙。
但用户要住的，是房子。

所以，别再只盯着提示词了。
先问自己：

成功怎么定义？

失败怎么兜底？

数据怎么闭环？

成本延迟多少？

可观测吗？

能回归吗？

用户敢信吗？

这些答不上来，提示词写得再漂亮，也只是 Demo。

AI 应用开发的核心，不是让模型更聪明，而是让系统更可靠。

如果你也在做 AI 应用，欢迎在评论区聊聊：你卡在哪一层？是评估、上下文、成本，还是产品化？