大模型应用上线前检查清单提示词（评测达标、兜底与降级、内容安全、日志监控、灰度与回滚逐项自查）
一个基于大模型的功能（智能客服、文档问答、内容生成、智能体）准备对真实用户开放前用：说明功能和现状，AI 按八个方面逐项追问并生成一份针对你这个功能的上线检查表，标出「不满足就不能上线」的阻断项，以及上线后第一周要盯的指标。
通用大模型 对话模型通用
我有一个基于大模型的功能准备上线。请帮我做上线前评审：先逐项了解现状，再输出一份针对这个功能的检查表。请直接指出缺口，不需要客气。 功能说明：[功能说明] 面向的用户与规模：[用户与规模] 出错的后果：[出错后果]（例如：答错只是体验差 / 可能造成用户金钱损失 / 涉及未成年人或敏感内容） 目前已经做了的准备：[已有准备] 计划的上线方式与时间：[上线计划] 第一步：按下面八个方面向我提问 每个方面最多问 3 个问题，只问从我的描述里看不出来的。全部问题一次列出，等我回答。 1. 质量评测：有没有评测集；覆盖了哪些情况；当前结果如何；通过线是怎么定的；最近一次改动后是否重新跑过。 2. 失败时的表现：模型接口超时、报错、被限流、返回空内容或格式不对时，用户会看到什么；有没有重试、降级和兜底文案；有没有转人工的出口。 3. 输入与输出的边界：超长输入、空输入、无关问题、试图让它偏离用途的输入分别怎么处理；输出是否会被直接执行、直接展示为网页内容或直接发给第三方。 4. 内容与合规：是否可能输出不当或侵权内容；是否需要向用户说明内容由 AI 生成；用户数据是否会发送给第三方模型服务，隐私政策是否已覆盖；所在地区对生成式 AI 服务有无备案或标识要求需要核实。 5. 权限与数据安全：模型或智能体能访问哪些数据、能执行哪些操作；越权是否在服务端拦截；提示词注入能造成的最坏后果是什么。 6. 成本与容量：单次请求的成本估算；是否有用户级与全局的用量上限；流量突增时的表现；账单告警。 7. 可观测性：是否记录了每次请求的输入、输出、所用提示词版本与模型版本、耗时与用量；能否按用户反馈回查到当时的完整记录；日志中的个人信息如何处理。 8. 发布与回滚：是否灰度；提示词与模型版本是否纳入版本管理；发现问题时多长时间可以关闭功能或回退；谁有权限、谁值班。 第二步：根据我的回答输出检查表 检查项 | 现状 | 结论（满足 / 部分满足 / 缺失）| 是否阻断上线 | 补救措施与预计工作量。 阻断项的判定要结合我写的「出错后果」：后果越重，对兜底、权限和人工介入的要求越高。 第三步：给出 1. 上线前必须完成的事项，按顺序排列； 2. 可以带着上线、但要在两周内补齐的事项； 3. 上线后第一周每天要看的 5 个指标与对应的报警阈值设定思路（阈值由我根据基线确定）； 4. 用户反馈入口与问题回流到评测集的流程。 法律与合规方面的结论请只给出「需要核实的问题清单」，并说明应向法务或主管部门的公开规定确认，不要直接下合规与否的结论。
高亮处换成你自己的内容：[功能说明]、[用户与规模]、[出错后果]、[已有准备]、[上线计划]
ChatGPT Plus 充值
已被复制 0 次
使用说明
这份清单针对的是大模型功能特有的风险。传统功能上线看的是测试通过、性能达标；大模型功能多出几样东西：输出不确定，同一个问题今天答对明天可能答错，所以需要评测集而不是几个手工用例；依赖外部模型服务，会超时、限流、涨价；输入是自然语言，用户可以说任何话，包括试图带偏它的话；出了问题要能回查「当时模型到底看到了什么、用的哪版提示词」。八个方面就是围绕这些设计的。
怎么填变量：[出错后果] 是整份评审的标尺，请写最坏情况。同样是答错，闲聊助手和能操作订单的智能体，上线门槛天差地别。[已有准备] 如实写，没做就写没做，评审才有意义。[上线计划] 写清是否灰度、放量节奏。
怎么用结果：检查表里的「阻断项」不满足就不要上线，或者缩小范围上线——例如先只对内部员工开放、先只开放只读能力、先加人工审核。「可后补项」要落到具体负责人和日期，否则上线后很容易被搁置。
常见问题与调整：
- 没有评测集 → 这是最常见的阻断项。先做一个最小版本：从内测记录里挑几十条有代表性的输入，写出每条的合格标准。可配合本站「提示词评测集怎么建提示词」。
- 兜底方案不知道怎么设计 → 追问：「针对超时、限流、格式错误三种情况，分别给出用户侧的提示文案和服务端的处理逻辑。」
- 智能体类功能 → 追问：「按『提示词注入能造成的最坏后果』逐个审视它能调用的工具，哪些要加人工确认。」并参考本站「提示词注入怎么防护提示词」。
提醒：合规要求因地区和业务类型而异且在不断更新，清单里的合规问题只是帮你列出要确认的点，结论请以法务意见和主管部门的公开规定为准。
示例输出
示例，仅供参考（功能：电商 App 内的售后智能助手，可查询订单并发起退款申请；节选）
| 检查项 | 现状 | 结论 | 阻断上线 | 补救措施 |
|---|---|---|---|---|
| 评测集覆盖退款场景 | 只有 20 条问答类用例，没有退款操作类 | 部分满足 | 是 | 补充退款相关用例，含金额不符、重复申请、超出退款期限等情况 |
| 模型超时的兜底 | 前端一直转圈 | 缺失 | 是 | 设置超时上限，超时后提示并提供人工入口 |
| 退款操作的确认 | 模型判断后直接提交 | 缺失 | 是 | 提交前向用户展示订单与金额并要求确认；服务端校验订单归属 |
| 提示词版本记录 | 已纳入版本库，日志记录版本号 | 满足 | 否 | —— |
| 账单告警 | 未设置 | 缺失 | 否（两周内补齐） | 设置日用量告警与单用户上限 |
上线前必须完成：退款确认与服务端校验 → 超时兜底 → 补齐退款评测用例并达到通过线。在此之前，可先上线只读的订单查询能力。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～