立项：先定动作边界
列出助手能做的动作，标出哪些不可逆、哪些对外。不可逆动作先定为必须人工确认，再倒推权限与数据范围，避免开发完才发现要重构，那时候改动成本往往是前期的好几倍，边界先于功能确认，很多团队会低估。
设计：攻击面清单
按输入源、工具、数据与用户四类画攻击面，逐项写控制措施。清单不需要很长，但要覆盖真实入口，尤其是文档上传与第三方回调这类常被漏掉的路径，它们往往是最先被打通的地方，清单要随需求变更更新。
开发：默认拒绝
工具默认不可用，按任务逐个开通；出站默认拒绝，按域名放行；数据默认最小可见，按角色放开。默认拒绝让遗漏变成「功能不可用」，而不是「风险敞口」，两者的处理成本天差地别，默认开放是多数事故的起点。
测试：用例集与红队
用例覆盖直接、间接、编码混淆、多语言与工具链五个方向，按可利用影响排序修复。测试报告要留下未修复项与接受理由，交付时一并移交，否则接手的人会以为全部通过，未修复项要有人签字接受。
上线与运营：确认门与复测
上线前确认人工门的位置与提示文案，上线后按月看告警、按季度复测。模型或插件升级要触发一次轻量回归，否则防护可能悄悄失效，而监控上看不到任何异常。回归要有结论，不能只是把用例跑一遍就算完成。
适用与不适用
适合谁
- 正在做 AI 项目立项与评审的产品团队
- 需要把安全要求写进合同的甲方，验收要看物
- 负责上线评审的安全与法务人员，要签字背书
不适合谁
- 仅做内部演示、不接真实数据的团队
- 希望用一次测试覆盖全部风险的项目
典型场景
某能源集团的合同审查助手在立项时就把「提交审批」定为人工动作，开发阶段默认关闭全部工具再逐个开通。测试阶段发现两处越权读取合同附件，修复后上线；运行两个月，告警触发三次，均为员工粘贴外部文档导致，记录进入上线档案。
可执行步骤
- 列出助手可执行的全部动作，标出不可逆与对外的部分并分级，写明时限。
- 画攻击面清单，覆盖输入源、工具、数据与用户四类，逐项写控制措施，标出优先级。
- 把工具调用与出站访问都设为默认拒绝，按任务逐个开通并留审批记录。
- 编写覆盖五类手法的注入用例集，执行红队测试并记录未修复项，抄送安全。
- 确定人工确认门的位置、触发条件与提示文案，并做一次可用性测试，留档备查。
- 把季度复测与模型升级回归写进运维计划，指定负责人与触发条件，由专人跟进。
常见坑
- 立项只写功能不写动作边界，开发完才发现高风险动作没有确认门，返工往往拖到上线前，后续很难补救。
- 工具默认全开、上线后再逐个关，只要漏关一个就是长期敞口，而且很难被日常巡检发现，后续还会复发。
- 测试报告只写通过项，未修复项与接受理由不记录，交付后没人知道风险还在，事后举证非常困难。
- 模型升级没有触发回归，老用例早已失效，防护看着还在其实形同虚设，回归用例也要跟着更新，信任很难修复。
自检与验收清单
- 是否列出不可逆动作并逐一设定确认门，含二次复核
- 攻击面清单是否覆盖文档上传与第三方回调入口
- 工具调用与出站访问是否都默认拒绝，按任务发放
- 用例集是否覆盖直接、间接、混淆、多语言与工具链，逐项判定
- 模型或插件每次升级是否触发一次轻量回归测试
常见问题
清单要写多细？
细到能验收即可：每个动作有边界、每个入口有控制、每条用例有预期结果。写得太细没人维护，写得太粗无法判断是否做到，建议按项目规模取中，并在评审时当场抽查几条。
甲方怎么在合同里要求？
把交付物写成可检查的项：攻击面清单、用例集与测试报告、确认门设计、复测计划。约定升级时的回归义务，比笼统要求「符合安全标准」更有约束力，也更容易验收，验收时逐项打勾。
项目小能不能简化？
可以少写文档，但不能省掉默认拒绝、人工确认与一次用例测试这三件事。它们成本很低，却决定了出事时影响是局部还是全面，性价比是所有措施里最高的，别为了省事跳过。