10.8 上线自检清单

概念

前面七节都在讲「怎么做配置」。这一节给你一个上线评审前必须逐条回答的八问清单。原则是：答不上来就别上线。这不是吓唬人——任何一个答不上来，意味着你的约束体系有裸奔的环节，客户一旦较真你就交代不了。

用法

把前面七节收敛成一张上线前自检清单。这张表就是你在企业安全评审会上要能逐条回答的问题。

提示

怎么用这张表：进场访谈时用它挖需求（第 6 章），方案设计时用它做约束清单，上线评审时用它逐条过。它不是给客户看的合同附件，是FDE 自己的职业底线检查表。

示例

一份填写后的自检清单：

上线自检清单 v1.2

1. 数据会不会出企业内网？部署形态选对了吗？

   答：私有化企业版部署，数据不出内网；出口另配白名单（api.entreprise.com）+ DLP 扫描兜底

   证据：data_egress_policy.yaml

2. 每个连接器的授权是否最小必要？

   答：Agent 子账号仅绑定 contracts_db:SELECT，无写权限；MCP 出站仅允许 api.internal.corp，其他一律拒绝

   证据：iam_policy.json / mcp_egress_policy.yaml

3. 谁能用哪些能力，下发策略是否验证过？

   答：按部门配白名单下发，已用后台「权限查询」逐一验证 10 个成员账号的生效结果

   证据：distribution_policy.yaml

4. 不可逆动作有没有人工门禁？

   答：send_email 强制 human-in-the-loop，DELETE 默认禁用；工具调用仅允许 query_contract / query_order 两个 Skill

   证据：skill_permissions.yaml / tool_whitelist.yaml

5. 出了争议，能不能从日志还原完整链路？

   答：三段式日志（Prompt/Tool/Response），统一 request_id 串联

   证据：logging_config.yaml

6. 上线有没有评测门槛？通过线是多少？

   答：500 条测试集，准确率 92.4%、幻觉率 1.4%、合规率 100%，红线指标全部达标

   证据：eval_report_v1.2.md

7. 系统会不会「不知道也硬答」？兜底设计在哪？

   答：知识库无答案时 100% 显式标注「无依据，建议人工确认」；Prompt 注入关键词黑名单 + 小模型分类器，检出率 96%

   证据：fallback_rules.yaml / prompt_guard_config.yaml

8. 终审决策是不是由人做、且留了痕迹？

   答：高风险输出进人工审批队列，审批人、时间、结论全量留痕

   证据：approval_audit_log.yaml

结论：八问全绿，建议上线。

注意事项

• 「答不上来就别上线」是硬规则 。如果八条有任何一条答不出或证据缺失，评审应当一票否决——哪怕业务方催得再急。上线后出事，背锅的是交付工程师，不是催你上线的业务方。

10.9 本章小结

• 约束三层模型 是心智底座：数据层管进出、能力层管能不能、过程层管留没留痕+够不够格——上线评审三层都要过，任何一层裸奔都算不合规

• 数据边界 靠敏感数据字典 + 入口过滤 + 出口白名单 + DLP 扫描四件套，「进出」两个方向都要控

• 权限模型 核心是「最小必要」——Agent 比人更不可信，只读优先、不可逆动作必须有 HITL 门禁

• 日志审计 必须三段式（Prompt/Tool/Response）+ 统一 request_id 串联，敏感字段要脱敏

• 评测门槛 定义指标+阈值+通过规则三件套，幻觉率和安全合规率是红线

• 三类护栏 分工明确：Prompt 护栏管输入、Tool 护栏管动作、Connector 护栏管外发

• 人工兜底 是贯穿全课的总原则——入口、过程、出口三个位置都要兜，把「不知道就说不知道」写进专家人设是最有效的设计

• 上线自检八问 是最后一道闸——答不上来就别上线，这不是建议是红线