核心用法
guard 是一个六阶段深度工作流，将产品和法律政策转化为可执行的技术行为：
1. 政策范围（Policy Scope）：定义禁止类别（仇恨、性内容、暴力、自残、恶意软件指令等）及敏感领域免责声明（医疗、法律），确保政策文档由法律/产品团队拥有。
2. 威胁建模（Threat Model）：识别攻击者（提示注入、数据外泄、工具滥用）和资产（用户数据、系统提示、连接器）。
3. 控制层叠（Controls Stack）：构建多层防御——输入筛查、模型安全API、输出分类器、工具沙箱、工具/URL白名单。
4. 实现模式（Implementation Patterns）：设计结构化拒绝消息，记录每次拦截的遥测数据，区分拦截/重写/警告三种处理级别，避免静默失败。
5. 监控与审查（Monitoring & Review）：人工抽查边缘案例，按类别监控拦截率，设置滥用激增警报。
6. 迭代与申诉（Iteration & Appeals）：建立用户申诉通道，版本化政策变更，按地区和使用场景测量误报率。
显著优点
- 系统化：六阶段框架覆盖从政策到运营的全生命周期
- 防御纵深：明确"无单一分类器足够"，强制多层防护
- 可观测性：强调遥测、人工审查、误报度量，避免"黑箱"拦截
- 合规就绪：内置区域合规（未成年人、受监管建议）和企业数据防泄漏场景
潜在局限
- 复杂度高：完整实施需跨法律、产品、工程、运营多团队协作
- 延迟成本：多层过滤可能增加响应时间，需明确延迟预算
- 误报权衡：严格过滤可能误伤合法用例，需持续迭代调优
- 不替代人工：高风险的最终决策仍需人工审核机制
适合人群
- 构建消费者向LLM功能的产品团队
- 面临越狱攻击、政策违规、PII泄露风险的AI安全工程师
- 需满足区域合规要求的法务/合规负责人
- 企业内部Bot开发者（侧重数据防泄漏和连接器范围控制）
常规风险
- 政策漂移：未版本化的政策变更导致行为不一致
- 监控盲区：缺乏边缘案例人工审查，累积用户信任损失
- 延迟失控：未预设延迟预算，多层过滤拖垮用户体验
- 申诉缺失：无申诉通道时，误报直接造成用户流失