团队准备把AI功能推上线，或者已经在线上跑着，忽然被问「你们的安全和可靠性到底靠什么撑着」，一时答不上来——这类问题通常不是缺某个工具，而是没把技术栈分层。这篇按输入、模型、数据、运行四个层面拆一遍，每层给选型判断标准和该做什么，数字类一概去站内对应页面核对。
团队准备把AI功能推上线，或者已经在线上跑着，忽然被问「你们的安全和可靠性到底靠什么撑着」，一时答不上来——这类问题通常不是缺某个工具，而是没把技术栈分层。工具买了一堆，每层都沾一点，真出事故却指不出是哪一层漏了。
这篇按输入、模型、数据、运行四个层面拆一遍，每层给选型判断标准和该做什么。数字类一概去站内对应页面核对，不写死在文档里。
先把技术栈分层，别堆工具
分层不是为了好看，是为了出事时能定位。按输入侧、模型侧、数据侧、运行侧四层划分，各自解决不同风险：输入侧管有人往你的提示里塞东西，模型侧管你调到的到底是不是你以为的那个模型，数据侧管信息流到了谁手里，运行侧管挂了之后怎么办。混在一起谈，很容易买重工具。
判断标准很简单：某一层缺失时，你能否在事故复盘时指认它？指认不了，说明这层根本没建起来，只是买了工具摆着。反过来，如果你能明确说「这次是数据侧日志落盘范围没控住」，那层就算做到位了。
输入侧与模型侧：防注入、防越权、验真身
输入侧的重点不是过滤关键词，而是结构上把用户输入和系统指令隔开。工具调用走白名单，别让模型自由决定去调哪个外部接口。常见做法是把系统提示、用户输入、工具返回分成不同角色和标记，任何来自用户的文本都不能改写到系统层。这套思路站内有专门文章讲，可以参考提示词注入防护那一篇的分层写法。
模型侧要确认你调到的到底是什么模型。同一个名字，经过中转可能被换成别的版本，能力差一截。用一组固定的对照测试跑一遍，看输出是否稳定，再结合站内 /tools/verify 与 /rankings 的判定口径交叉验证。这不是一次性的活，供应商换线路、换节点都可能变。
| 层面 | 主要风险 | 判断标准 |
|---|---|---|
| 输入侧 | 注入、越权调用工具 | 换个模型，防护配置是否还要重写？要重写说明耦合太深 |
| 模型侧 | 掺水、降智、身份不符 | 对照测试结果是否稳定，能否在中转与官方间区分 |
| 数据侧 | 上下文、日志外泄 | 能否画出提示词到落盘的完整链路 |
| 运行侧 | 中断、延迟、无法定位 | 故障期间客服能不能自己查到原因 |
数据侧与密钥侧：边界、脱敏与轮换
- 先画清数据链路：提示词、上下文、日志、缓存各自落到谁手里，能画出来才谈得上控制
- 密钥按最小权限拆分，一岗一钥，不要一个总钥打通所有服务
- 轮换与离职交接写进流程，而不是靠某个人的记忆
- 日志脱敏在写入前做，而不是事后清洗
- 第三方中转的留存策略要主动问，别默认它不留
密钥这一块最容易出事。很多团队一个总钥跑所有环境，测试、开发、生产共用，一旦泄露就是全线暴露。正确做法是按环境和角色拆，每把钥匙只管一小块，权限范围写清楚。轮换周期定下来，离职当天必须换掉经手的钥匙。
价格、限速、配额这类会变的数字，别写死在内部文档里。各家官方API的价格与限制，去 /official-api 与 /ai-nav/category/ai-api 看当时的口径，中转站那边的报价再对照 /price-watch 的记录。数字写死的地方，半年后一定过期。
运行侧：可观测、可降级、可复盘
运行侧至少盯住三个指标：延迟、可用率、错误率。单次请求的结果说明不了问题，要看一段时间的趋势。站内 /ai-status 提供状态观察，/tools/quality-monitor 讲的是怎么按节奏持续看质量变化，两者结合用，别只看一天的数据下结论。
- 定监控指标确定延迟、可用率、错误率的采集点，明确每分钟还是每五分钟采一次，先有数据再谈告警
- 写降级路径主模型不可用时切到谁，切了之后哪些功能关掉、哪些降级返回，提前写成清单
- 演练一次模拟主接口不可用，看切换是否真的生效，客服是否能查到原因，演练结果记下来
- 定复盘格式每次故障按层归类：是输入侧、模型侧、数据侧还是运行侧，归不下来就说明分层没做
降级路径不能等故障当天现想。主模型挂了切到备用，备用能力弱一些，那哪些功能必须关掉、哪些可以降级返回，提前写清楚。切换动作本身也要演练，不然真到切换时发现备用通路的密钥没配、限速没申请，等于没有。
选型顺序与止损排查
推荐顺序：先定数据边界与密钥治理，再补输入防护，最后才做模型多样化与容灾。顺序错了会返工。原因是数据和密钥是地基，输入防护依赖你对数据流路的理解，模型容灾则建立在前两者之上。先上多模型切换，结果发现日志把密钥写进去了，等于白做。
- 排查第一段
- 本地网络，先排除自己这边的连通性问题
- 排查第二段
- 自有服务，看自己的网关和业务逻辑有没有报错
- 排查第三段
- 第三方接口，确认中转侧有没有异常
- 排查第四段
- 上游厂商，看官方状态页和公告
逐段排除，不要同时开五个终端乱查。顺序是从近到远：本地网络、自有服务、第三方接口、上游厂商，一段确认没问题再进下一段，每段留一句记录。什么情况下不适用这套？已有成熟安全团队的大厂，重点不在补齐层次，而在现有工具的重复建设和口径统一，那是另一种问题。
下一步把上面的分层对着自己的项目过一遍，看哪一层指认不出来，再从站内核对当下的价格和状态数字，避免拿过期信息做决策。→常见问题
小团队有必要做全套安全技术栈吗？
没必要。5 人以内先保证三件事：密钥不外泄、数据知道发到哪、故障时能切走。其余留到有真实付费用户和合规要求再补，过早堆工具只会拖慢迭代。判断标准是出事时你有没有人力和流程去响应。
安全和可靠性是一回事吗？
不是。安全管的是「不被恶意利用和越权」，可靠性管的是「该在的时候在、该快的时候快」。两者共用一部分监控和日志，但选型和排查顺序不同。做预算时分开列，别用一套指标糊住两边。
怎么判断某个组件该不该进技术栈？
问三个问题：它拦住了哪一类具体风险、出事时它能不能给出证据、换掉它要改多少地方。三个都答得上来再上。答不上来说明是跟风采购，不如先去 /safety 对照现成的合规清单。
