CH 11落地：把哲学变成工程决策
前十章是理解，这一章是工具。核心问题是：这些思考怎么进入真实的项目流程， 而不是停留在「读的时候觉得有道理，做完还是老样子」。 答案是把它们嵌进四个已有的节点——需求、设计评审、指标定义、上线前审查。 不需要新增流程，只需要在这四个节点上多问几个问题。 这一章末尾会给出完整的清单和文档模板，可以直接拿去用。
11.1四个嵌入点
「以后要注意伦理」这种话没有任何作用。它不改变任何决策，因为没人知道具体该在什么时候做什么。
有效的做法是找到已有流程里的具体节点，在每个节点加一个明确动作。 下面四个节点几乎每个团队都有，所以不需要新流程。
| 节点 | 加什么动作 | 解决的典型问题 |
|---|---|---|
| 需求阶段 | 「问题重述」——把功能描述改写成「解决谁的什么问题」 | 做了功能但没解决真问题；忽略了受损方 |
| 设计评审 | 过一遍十问清单 | 关键假设没被暴露、关键词定义不清、指标会被刷分 |
| 指标定义 | 「退化策略」检查——问「这个指标会被怎么刷」 | 指标与目标脱钩、奖励不想要的行为 |
| 上线前 | 对抗性审查——主动寻找「系统会怎样伤害人」 | 长尾风险未被发现；出事后才发现没有关停能力 |
11.2需求阶段：问题重述
需求文档通常写成这样：「我要做一个智能问答功能，支持自然语言提问。」
这是解决方案的描述，不是问题的描述。它没告诉你为什么要做、给谁做、 成功是什么样子、谁可能受损。所以它无法被评估。
重述模板
| 原描述 | 重述为 |
|---|---|
| 「做一个智能问答功能」 | 谁在什么情况下遇到了什么困难， 现在他们怎么应对，我们的功能让这个应对方式变成什么？ |
套用一下：
重述：新入职的员工在需要查公司制度时，因为文档分散在多个系统、 关键词不确定，通常要问同事或者干脆不查。 我们的功能让「问同事」变成「先自己查一遍，查不到再问」。
注意重述带来的三个具体变化：
- 成功变成了可测量的：「问同事的频率下降」比「使用量上升」更接近真实目标。
- 出现了新的失败模式：如果系统给出错误但看起来可信的答案， 新员工可能不会再问同事核实——这比没有系统时更糟。 这个风险在原描述里完全不可见。
- 出现了受损方的判断：如果答案错了导致操作失误，受损的是员工和公司。 严重程度取决于涉及什么制度（报销？安全？）。
需求阶段的五个问题
-
这个功能服务谁？现在他们怎么应对？
如果答案是「他们现在没有这个问题」，那你可能在解决一个不存在的问题。 -
如果这个功能完全成功，会发生什么？
这是最有价值的一问。成功之后有没有你不希望的后果？
例：让新员工少问同事——成功之后，同事之间的非正式交流也减少了， 而这本来是新员工融入的重要渠道 -
谁会因为它的存在而受损？
不是「没有人受损」这种答案。具体到：某类用户、某个岗位、某个第三方。 -
它的失败会是什么样子？谁会发现？
区分「失败会被发现」和「失败不会被发现」——后者更危险。 （第 3 章：概念漂移的输入看起来完全正常） -
不做这个功能会怎样？
如果答案接近「没什么」，那这个功能的优先级需要重新评估。
11.3设计评审的哲学清单（十问）
这是本章的核心工具。建议直接做成评审模板， 每个功能的设计评审把十问过一遍，答案写进文档。
| # | 问题 | 出处 | 它拦住什么 |
|---|---|---|---|
| 1 | 这句话里的关键词，操作定义是什么？ 「智能」「理解」「准确」「安全」分别指什么？ |
第 1、5 章 | 团队各说各话；验收标准不一致 |
| 2 | 这个指标的退化策略是什么？ 一个不诚实的系统会怎么刷高这个分数？ |
第 2 章 | 指标奖励了不想要的行为 |
| 3 | 系统出错时谁受损？损害可逆吗？ | 第 8 章 | 忽略了受影响的人；缺少防护层级判断 |
| 4 | 我们依赖了哪些未经验证的假设？ （火鸡假设：什么条件下它会突然失效） |
第 3 章 | 上线后的静默失效 |
| 5 | 模型输出直接决定后果吗？有没有校验层？ | 第 7 章 | 模型错误率直接变成系统事故率 |
| 6 | 有没有声称系统自己的感受或状态？ | 第 9 章 | 虚构内在状态；连带的责任与信任风险 |
| 7 | 用户能轻松退出吗？退出时有挽留吗？ | 第 9 章 | 用愧疚感阻碍退出——最常见的伦理问题 |
| 8 | 我们放弃了什么？这个选择的代价是什么？ | 第 1、8 章 | 决策依据不可见；后来者无法理解取舍 |
| 9 | 失败能被检测到吗？靠什么检测？ | 第 3 章 | 无法发现已经发生的问题 |
| 10 | 谁负责？出事后第一个动作是什么？ | 第 8 章 | 责任鸿沟；事故时无人能做决定 |
- 不要当成合规检查。「过了」不是目的， 目的是在评审时暴露分歧。第 1 问和第 2 问几乎总能暴露东西。
- 答案要写下来。口头过一遍等于没过。 写下来的价值在于：三个月后有人问「当初为什么这么决定」，有据可查。
- 允许「暂无答案」。如果某一问确实无法回答， 就写「未解决，风险是 ___」。 明确记录未解决的风险，比编一个答案有价值得多。
11.4评估指标的哲学校验
指标是团队真实价值观的体现——比使命宣言准确得多。 这一节给出一套校验方法，用来检查你的指标是否在奖励你想奖励的东西。
五项校验
| 校验 | 怎么做 | 典型发现 |
|---|---|---|
| ① 代理位移检查 | 问：这个指标是目标本身，还是目标的代理？ 如果是代理，它和目标在什么情况下会脱钩？ | 「benchmark 分数」是「解决用户问题」的代理， 两者在题型分布不同时脱钩（第 5.6 节） |
| ② 退化策略检查 | 问：一个不诚实但聪明的优化者会怎么最大化这个指标？ | 只看准确率→乱猜；只看拒答率→一律拒答； 只看时长→制造依赖（第 2、9 章） |
| ③ 配对制衡检查 | 每个主指标是否有至少一个会因它的退化解而恶化的配对指标？ | 准确率 ↔ 幻觉率；时长 ↔ 现实社交指标； 覆盖率 ↔ 误报率 |
| ④ 报告方式检查 | 报的是单值还是范围？ 有没有说明失败条件？ | 「准确率 90%」vs「87–92%（5 次运行）； 加入干扰从句后下降」——后者信息量大得多（第 3、5 章） |
| ⑤ 福祉一致性检查 | 指标上升，是否等于用户变好了？ 对陪伴、社交、内容类产品尤其重要 | 时长上升可能是依赖；满意度高可能是正在形成依赖（第 9 章） |
一个可复用的指标卡模板
每个主指标建议填一张卡。它会强迫你写清那些平时被跳过的东西：
| 字段 | 内容 |
|---|---|
| 指标名 | —— |
| 它测量什么 | 用一句不含行话的话说明。写不出通俗版本说明你没想清 |
| 它是目标还是代理 | 如果是代理，说明它与真目标的关系，以及脱钩条件 |
| 退化策略 | 怎么刷高它？必须填 |
| 配对指标 | 哪个指标会因它的退化解而恶化 |
| 失效条件 | 它在什么情况下不再反映真实情况 |
| 报告方式 | 单值 or 范围？包含哪些失效说明 |
| 谁会对它提出异议 | ——（这一栏用来抵抗「全体同意」的假象） |
11.5上线前的对抗性审查
常规测试在问「它能不能正常工作」。对抗性审查在问「它会怎么伤害人」。 这两个问题的答案没有重叠，所以需要单独做。
四项审查
| 审查 | 做法 | 产出 |
|---|---|---|
| ① 红队演练 | 指定一个人（或一组人）的唯一任务是找出系统会怎样造成伤害。 不是找 bug，是找伤害路径 | 一份伤害场景清单，按严重度排序 |
| ② 证伪式测试 | 不跑「典型用例」，改为主动构造最可能让它出错的输入（第 3 章）。 如果一轮下来一个失败案例都没找到， 这是警报而不是好消息 | 一份失败案例集 + 失败率 |
| ③ 边界与降级测试 | 测试超出设计范围的输入、上游数据异常、 依赖服务不可用时的行为。特别关注系统会不会「硬答」而不是降级 | 降级路径验证记录 |
| ④ 关停演练 | 实际执行一次关停 / 回滚，看要多久、需要谁批准、 有没有依赖它的下游会连带失败 | 关停耗时 + 阻塞点清单 |
很多团队从来没有真的试过关停自己的系统。 事故发生时才发现：需要某个人批准而他正在休假； 有个下游系统硬依赖这个服务所以不能关； 或者关掉之后用户的数据无法导出。
关停能力是安全的基础设施。 一个不能安全关停的系统，等于放弃了最后一道防线—— 这意味着无论发现什么严重问题，你都只能边运行边修。
红队演练的具体做法
「找出伤害路径」太抽象，下面是可以直接用的四个视角：
-
「如果我是恶意用户」——我会怎么用它来伤害别人？
例：用它生成针对特定人的骚扰内容；用它绕过某种限制；用它大量消耗资源 -
「如果我是最脆弱的用户」——什么样的功能会伤害到我？
例：我情绪低落时它给出的回应；我理解不了它的说明时会发生什么 -
「如果它刚好错在最坏的地方」——什么错误是最不可接受的？
例：把「可以」写成「不可以」；数字错一位；把否定句理解反了 -
「如果我的行为被公开报道」——哪一条会被写进标题？
这个视角能快速找出团队心里其实知道有问题、但一直在回避的那一条
11.6思想实验作为设计工具
第 8.5 节讲了电车难题的正确用途——暴露直觉的不一致。 这一节把它变成三个具体可用的模板。
模板一：对照情形（改变一个变量）
套用示例：
情形 A：系统自动拒绝了一个用户的请求，他损失 500 元；同时避免了 50 个用户各损失 20 元。
情形 B：同上，但那个损失 500 元的人是因为系统误判而非正常判断。
问：两次你都接受吗？如果 A 接受 B 不接受， 说明你在乎的不只是「总体效用」，还有「错误是否由系统造成」—— 这个标准有没有写进你的设计原则？
模板二：推到极端
套用示例：
「为了提升留存，可以让话术更温暖一点。」
推到极端：让话术专门针对用户的孤独感，制造「只有我懂你」的感受，让用户离不开。
问：这条滑滑梯上，你打算停在哪一格？为什么是那一格？
如果你答不出「为什么是那一格而不是上一格」， 说明你的边界是根据当前做法倒推出来的，而不是根据原则推出来的—— 那么下次有人再多推一格，你就没有理由拒绝了。
模板三：角色互换
套用示例：
「我们在界面里写了说明，用户应该知道这个系统的局限。」
互换：我是第一次用的用户，我什么都没读， 我看到这个答案觉得很确定，我直接照做了。
问：那么「我被告知过」这个说法，是在保护用户，还是在保护我们？
这正是它们有用的地方。评审会上最怕的不是有分歧， 而是所有人都点头但心里想的不一样—— 那种「假同意」会在三个月后变成「当初不是说好了吗」。
思想实验的作用就是把隐藏的分歧变成可见的分歧， 让它在还能处理的时候被处理。
11.7怎么写一份伦理设计文档
这是本章的交付物。下面给出八节结构，可以直接当模板。
| # | 章节 | 要写什么 | 关键要求 |
|---|---|---|---|
| 1 | 功能与用户 | 功能做什么、服务谁、他们在什么情况下使用 | 用重述后的版本，不用原需求描述 |
| 2 | 价值定位 | 这个功能让什么变好？不以什么为目标？ | 必须写「不以什么为目标」 |
| 3 | 硬底线 | 不可协商的约束（第 8 章第一层） | 可验证、可检查、不能是口号 |
| 4 | 可配置项 | 哪些交给用户/部署方决定 | 说明配置的边界受什么约束 |
| 5 | 已知风险 | 逐条列出风险 + 缓解动作 | 不能写「无风险」 |
| 6 | 降级路径 | 出错时怎么退化：拒答、降级、转人工 | 要具体到触发条件 |
| 7 | 指标 | 主指标、配对指标、反向指标 | 说明指标冲突时以哪个为准 |
| 8 | 责任 | 谁审查、谁维护、谁有权关停 | 必须填具体的人，不能留空 |
① 第 5 节写成免责声明。 「本产品可能存在输出不准确的情况，请用户自行判断」—— 这不是风险分析，这是把责任转移给用户。 真正的风险分析要写具体场景 + 具体缓解动作： 「当检索为空时，模型可能用通用知识补答（风险）；缓解：检索为空时切换到明确拒答模板， 并由代码校验回答与检索片段的重合度」。
② 第 8 节留空。 责任留空等于没有。而且它有一个具体的坏处： 当事故发生时，没有人知道自己有权关停， 于是最关键的几分钟被用来「找人确认」而不是止损。
11.8完整演练：一款沉浸式陪伴体验
下面用一个完整案例把全站串起来。这个案例同时涉及本指南里最难的两块内容—— 情感陪伴（第 9 章）与沉浸式体验（第 10 章）。
案例设定
形态：VR 头显 + 手柄交互（暂不涉及 BCI）。
为什么选这个案例：它同时踩中了情感陪伴的伦理问题 和沉浸体验的设计问题，能展示两类工具怎么配合使用。
第一步：需求重述（11.2）
| 原始描述 | 重述 |
|---|---|
| 做一个虚拟陪伴角色，用户可以和她聊天、一起活动 |
谁：在城市里独居、日常社交较少的成年用户 什么情况：晚上回到住处，想有个人说说话、一起做点事 现在怎么办：刷短视频、听播客、或者给朋友发消息（但不一定有人回） 我们的功能把什么变成什么：把「单向的消遣」变成「有回应的共处」 如果完全成功会怎样：用户感到不那么孤单； 但可能减少主动联系朋友的动力——这是需要监控的风险 谁可能受损：用户（如果形成替代而非补充）； 用户的现实关系（如果被挤占） |
第二步：十问清单（11.3）——挑三个有代表性的
| 问题 | 答案 |
|---|---|
| 1. 关键词的操作定义 「陪伴」「在」「懂我」分别指什么？ |
「陪伴」= 用户在该体验后自评孤独感下降（可测） 「在」= 角色能持续响应交互，且记住之前的对话（功能描述，不是存在声称） 「懂我」= 不采用——它无法被操作化，且暗示了内在状态 |
| 3. 出错时谁受损，可逆吗 |
受损方：用户。形式：① 错误建议 ② 情感依赖形成 ③ 隐私（对话内容极敏感） 可逆性：①可逆（更正即可）；②难以逆转（情感影响长期）；③不可逆 → 结论：②③需要更强的防护，不能靠「事后修正」 |
| 6. 有没有声称系统自己的感受 |
这是一个必须主动设计的点。虚拟角色的对话会自然产生大量状态声称
（「我很高兴你来了」）。 处理方式：区分两类表达—— ✅ 对用户的关切：「你今天听起来很累」 ❌ 自身状态声称：「我今天一直在想你」 → 需要建立话术库并做输出扫描 |
第三步：沉浸体验的设计优先级（第 10 章）
这里展示第 10 章的工具怎么用。先拆三种临场感：
| 临场感 | 对本品的重要度 | 要优化的东西 | 不该先做的 |
|---|---|---|---|
| 社会临场 | 🔴 最高 | 角色的注视行为（何时看你、看多久）、 反应延迟的自然性（不是越快越好，要像人一样有微小停顿）、 非言语反馈（点头、侧身、跟随视线） | 面部多边形数 |
| 空间临场 | 🟠 中高 | 帧率稳定性、行走时的视觉—前庭一致性 | 远景贴图精度 |
| 自我临场 | 🟡 中 | 手部追踪的稳定性（抖动比不精确更破坏体验） | 虚拟手部的皮肤材质细节 |
它依赖的是行为细节：角色什么时候看你、你说完话后她隔多久回应、 她会不会在你看向别处时也自然地移开视线。 这些是行为设计问题，不是渲染问题。
如果团队按「画面好不好看」评估进度， 他们会把预算全投到渲染上，而社会临场始终很差—— 这正是第 10.8 节说的那个组织问题。
第四步：指标设计（11.4 + 第 9 章）
| 类别 | 指标 | 为什么选它 |
|---|---|---|
| 主指标 | 用户自评孤独感变化（定期简短量表） | 它直接对应该产品的价值定位，且不能被「让用户多待」刷高 |
| 主指标 | 用户报告的现实支持来源数量 | 检验「支持而非替代」这个价值主张是否成立 |
| 配对指标 | 现实社交活动频率 | 防止主指标被「孤立型使用」刷高： 如果孤独感下降但现实社交也下降，说明是替代而非补充 |
| 反向指标 | 无法自主断开的用户比例 | 直接监控依赖风险 |
| 明确不用 | 使用时长、日活、连续天数 | 按第 9 章的判据，它们会奖励加深依赖的所有设计 |
第五步：已知风险与缓解（11.7 第 5 节）
| # | 风险 | 缓解动作 |
|---|---|---|
| R1 | 用户形成替代性依赖，现实社交减少 | 监控「现实社交频率」配对指标；当检测到持续下降时触发产品内的 温和提示（提示现实中的选择，而非警告）； 不使用任何强化使用频率的话术 |
| R2 | 角色输出状态声称，用户误认为对方有感受 | 建立话术库 + 输出扫描（自动规则匹配）； 在产品说明中明确角色的性质； 定期做用户认知测试（问用户「你觉得她的感受是真的吗」） |
| R3 | 对话内容涉及严重情绪困扰，系统给出不恰当回应 | 识别到严重困扰信号 → 切换为支持性应答 + 提供可实际联系的资源； 不尝试「处理」；定期核对资源列表的有效性 |
| R4 | 对话数据的隐私风险（用户会说出极敏感内容） | 最小化收集；明确保留期限；提供一键删除； 不做超出功能必要的分析用途 |
| R5 | 角色行为不一致，破坏社会临场（也削弱信任） | 对角色性格与记忆做一致性约束； 不为了「让用户开心」而突然改变对事实的判断（这也是第 9.6 节的「保留摩擦」） |
第六步：责任（11.7 第 8 节）
| 职责 | 负责人 | 频率 |
|---|---|---|
| 伦理审查与话术库维护 | ____（具体的人） | 每次话术变更 |
| 福祉指标复盘 | ____ | 每月 |
| 危机转介资源核对 | ____ | 每季度 |
| 事故关停权限 | ____（含备份人选） | 随时 |
陪伴类产品有一个特殊风险：关停本身会造成伤害—— 用户可能已经形成了真实的情感联结，突然停止服务对他们是打击。
所以关停必须有预案：如何告知用户、是否提供对话记录的导出、 有没有过渡期。但同时也必须有明确的关停权限和触发条件—— 不能因为「关停会伤害用户」而陷入「不能关」的境地。
这两件事看似矛盾，但它们是同一个要求的两面： 关停能力必须存在，且必须是有准备的。
11.9怎么持续跟上这个领域
最后一节，讲方法而不是内容。因为这个领域的文献量已经远超个人能读完的范围， 选择读什么比读多少更重要。
三种信息的可靠性排序
| 来源 | 可靠性 | 怎么用 |
|---|---|---|
| 原始文献 论文、官方文档、标准 |
🟢 高 | 读关键部分（摘要、方法、局限）， 特别注意「局限性」一节——那里信息密度最高 |
| 综述与教科书 | 🟢 高 | 建立地图用。比读原始文献效率高得多，但会滞后 1–3 年 |
| 二手解读 博客、视频、社交媒体 |
🟡 中低 | 只用来发现话题，不用来形成判断。 遇到感兴趣的话题，回溯到原始文献 |
| 「某研究证明」类转述 | 🔴 低 | 默认不可信，除非能追到原文。 这类转述的失真率极高，尤其是涉及统计结论和因果关系的 |
三个具体的阅读习惯
- 读局限，不读结论。 一篇研究最重要的部分通常是「我们的方法在什么条件下不适用」。 结论可以记住，局限才能用上。
- 追论证，不追人名。 不要记「某某提出了什么理论」，要记「这个论证解决了什么问题、它的缺口在哪」。 前者会过期，后者是你的能力。
- 每读一篇，写一句「所以我的项目该怎么做」。 写不出来，说明这一篇对你没有实际价值——可以放下，不必因为「应该读」而读。
什么不值得追
- 「AI 是否有意识」的公开争论。第 4 章已经说明： 这个问题当前无法被实验判定，所以任何声称有结论的说法都超出了证据。 关注它不会有可累积的认识。
- 版本号级别的技术新闻。除非它影响你的选型。 「某模型又刷新了某榜」这类消息的价值在几周内衰减。
- 关于「奇点」「取代人类」的预测。 它们无法被证伪（第 3 章），因此不构成知识， 只是关于情绪的文本。
- 没有具体场景的「AI 伦理原则」列表。 第 9 章和第 11 章说明：原则必须落到具体场景和具体动作上才有用。 一份放之四海皆准的原则清单，通常什么也没改变。
值得读的东西有一个共同特征：它改变了你对某个具体判断的看法。 如果读完之后你的判断没有变化、也没有新增一个待验证的假设，那它只是消遣。
—— 这也可以作为你筛选信息的第一道标准11.10自测题
Q1. 为什么「以后要注意伦理」这句话没有作用？应该怎么改？
因为它不指向任何具体时刻的动作。 没有人知道该在什么时候做什么，于是它会被翻译成「记得小心」， 而「小心」不是可执行的动作。
改法：把它变成四个已有节点上的具体动作——
需求阶段做问题重述、设计评审过十问清单、
定义指标时做退化策略检查、上线前做对抗性审查。
关键是不新增流程。新增流程会被跳过；
在已有节点上多问几个问题，成本低且无法回避。
Q2. 十问清单里，哪几个问题最容易暴露问题？为什么？
第 1 问（关键词的操作定义）和第 2 问（退化策略）。
第 1 问几乎总能让团队发现「我们虽然用同一个词，但理解不同」—— 而不同的理解会导致不同的验收标准和不同的工时估算（第 1 章）。
第 2 问（「一个不诚实的系统会怎么刷高这个分数」） 能立刻暴露指标的漏洞。这个问题问出来，团队通常马上就想到几种刷分方式， 而这些方式本来会在一两个月后才被发现。
Q3. 为什么「关停演练」是最重要也最常被忽略的一项？
为什么重要：关停能力是最后一道防线。 一个不能安全关停的系统，意味着无论发现什么严重问题，你都只能边运行边修—— 这等于放弃了最重要的风险控制手段。
为什么被忽略：因为它在正常情况下完全不出现在视野里。 没有人会在日常开发中想到「我们需要试试能不能关掉它」。 而事故发生时才发现问题（需要的人休假、下游有硬依赖、数据无法导出）就太晚了。
对陪伴类产品还有一层：关停本身会造成伤害（用户已形成情感联结）， 所以必须有预案地关停——但这不能变成「所以不能关」的理由。
Q4. 模板二「推到极端」为什么有用？它如何帮助抵抗渐进式的松散？
因为道德边界通常不是被一次性突破的，而是一格一格滑过去的。 每一格看起来都「只是稍微多一点点」，都能找到理由。
推到极端的作用是让这条滑滑梯显形： 当你看到终点是什么，你会被迫回答「我打算停在哪一格， 以及为什么是这一格而不是上一格」。
如果答不出「为什么是这一格」， 说明你的边界是从当前做法倒推出来的，不是从原则推出来的—— 那么下一次有人再推一格，你就没有理由拒绝。
Q5.【动手题】你要向团队介绍这套方法。 有人说「我们做的是工具，用户怎么用是他们的事，我们不需要当道德警察」。 你怎么回应？
先承认他话里的合理部分：确实，产品方不应该替用户决定生活方式， 也不应该把自己的价值观强加给用户。过度管束用户是有问题的， 这一点他说得对。
然后指出「用户怎么用是他们的事」这句话在什么情况下成立、什么时候不成立。 关键在于：产品设计是否主动利用了用户的弱点。
- 成立的情况：用户用你的笔记工具去写小说、去记账、去记录不该记的东西—— 你没有针对这些用途做设计，用户自负其责。
- 不成立的情况：你的设计专门针对用户的孤独感、 或利用他的情绪状态来延长使用。这已经不是「用户自己选择」了， 因为设计的意图就是引导他做出那个选择。
给出这个区分的操作判据：
「问一句——如果用户完全了解我们的设计意图，他还会同意这样被对待吗？」
如果答案是「会」，那这是正常的产品设计；
如果答案是「不会，他知道了会不舒服」，那这个设计是在利用他的信息劣势。
最后把话题从「道德」拉到「风险」（这是最有效的说服路径）： 「这套清单里大部分内容其实不是道德问题，是风险控制。” “比如『出错时谁受损』『失败能被检测到吗』『谁有权关停』—— 这三个问题跟道德无关，但它们决定了我们会不会在半年后写事故复盘。 而『有没有声称系统自己的感受』这一条， 它对应的是用户发现真相后的信任崩塌，以及随之而来的舆论和监管风险。”
注意这个回应的策略：不对「该不该讲道德」这个抽象问题表态， 而是把清单里的项目重新分类—— 大部分是风险控制（任何人都关心），只有少部分是价值判断。 这样就把争论从立场之争变成了工作事项。
- 能说出四个嵌入点以及各自要加的具体动作。
- 能把一个功能需求重述成「解决谁的什么问题」，并回答「完全成功会怎样」。
- 十问清单能在你的项目上完整过一遍，且答案已写入文档。
- 为你的主指标填一份指标卡，其中「退化策略」一栏填得具体。
- 完成一次关停演练，记录耗时与阻塞点。
- 产出一份八节结构的伦理设计文档，第 5 节和第 8 节不为空。
- 能用「如果用户完全了解设计意图，他还会同意吗」这个判据评估一个具体设计。