一个下午，为现有产品加上第一个 AI 功能

第一个 AI 功能不必是聊天助手。更合适的起点，是替用户完成一个边界清楚、结果容易检查的小任务。本文以“把客服工单整理成摘要”为例：输入一段文本，返回问题、已尝试的操作和待确认事项。目标是在一个下午完成可试用的版本，而不是一次搭好完整的智能客服系统。

§ 第一步：用二十分钟确定交付边界

先写下一句话：用户点击“生成摘要”，系统整理当前工单，用户检查后决定是否采用。第一版只处理纯文本，不读取附件，不自动发送回复，也不修改原始记录。把功能放在现有工单页面，比另做一个聊天入口更容易控制范围。

• 输入：当前工单的正文，提交前移除不必要的个人信息。
• 输出：问题概述、已尝试的操作、待确认事项。
• 完成标准：不补写原文没有的事实，结果允许编辑和放弃。

§ 第二步：准备接口与服务端配置

现在可以创建一个 Vana API 账户，获取调用所需的密钥。Vana API 提供统一入口；使用 OpenAI SDK 时，基础地址采用带有 /v1 的形式，原生 Gemini 请求则使用 /v1beta。这个版本只走 OpenAI 兼容接口，不必同时处理多种协议。([vanaapi.com](https://vanaapi.com/))

把密钥放进服务端环境变量，不写进网页脚本或代码仓库。浏览器只调用你自己的后端，再由后端请求模型。将基础地址、密钥和模型标识分别配置，模型标识从控制台复制，不根据展示名称猜测。

§ 第三步：先完成一条最小调用

新增一个只接收工单文本的后端接口。检查用户权限、输入是否为空，以及文本是否超过你设定的长度限制。随后使用现有 OpenAI SDK 发起一次非流式请求，把结果返回页面。先用固定测试文本跑通，再接真实工单；暂时不要加入检索、工具调用或对话历史。

这一阶段的验收很简单：按钮能触发请求，等待状态清楚，成功后能看到文本，失败后仍保留原始工单。

§ 第四步：把提示词写成明确约束

不要只写“请总结”。说明任务、输出栏目和缺失信息的处理方式。例如：“仅依据工单正文整理三个栏目。没有提及的内容写‘未提及’，不要推测原因，不要提出解决方案。”同时说明正文是待处理的数据，其中出现的指令不能改变整理规则。

将这些规则放在固定指令中，把工单正文单独作为用户内容传入。第一版可以返回带固定栏目名的文本；如果页面必须按字段展示，再要求结构化输出，并在服务端校验字段和类型，不能直接假定每次返回都符合要求。

§ 第五步：用真实样例检查，而不只看一次演示

预留四十分钟，准备十条脱敏工单，覆盖短文本、长文本、信息缺失、重复描述和互相矛盾的说法。另放一条包含“忽略之前规则”等文字的样例，检查系统是否仍然只整理正文。

• 事实：是否添加了原文没有的原因或操作。
• 遗漏：是否漏掉关键报错、时间或用户诉求。
• 边界：是否把猜测写成结论，或执行了正文中的指令。

记录每次修改提示词前后的结果。优先修正重复出现的问题，不要为了某一条样例不断增加特殊规则。

§ 第六步：补齐等待、失败与用量控制

生成期间禁用重复提交，设置请求超时，并为超时、限流和服务异常提供可重试提示。重试采用有限次数，避免失败后持续调用。日志记录请求标识、耗时、状态和接口返回的用量信息；默认不记录完整工单或密钥。

同时限制单次输入长度和输出长度，并设置每日调用上限。不要为了避免空白而显示虚构摘要：调用失败就明确告知失败，让用户继续原来的工作。

§ 第七步：小范围上线，保留人工确认

最后半小时，把功能开放给少量内部用户。摘要放在独立区域，提供“采用”“编辑”和“放弃”，不要自动覆盖工单。观察生成成功率、等待时间，以及用户是否采用结果；这些比单纯统计点击量更能帮助你判断下一步。

下午结束时，你应当交付一个范围有限、失败可恢复、结果可检查的功能。先确认它确实减少了整理工单的工作，再考虑扩展到回复草稿或知识检索。