--- schemaVersion: 1 scope: "public-indexable-html" renderScope: "server-rendered-main" canonical: "https://isafwan.com/zh-CN/ideas/better-questions-before-ai/" companion: "https://isafwan.com/agent/zh-CN/ideas/better-questions-before-ai/index.md" locale: "zh-CN" language: "zh-CN" direction: "ltr" title: "先把问题写清楚，再谈人工智能 | Safwan AlModhayan" description: "采用人工智能之前，真正需要被设计的往往不是提示词，而是问题、决定与责任之间的边界。" --- ## Language versions - [ar-SA](https://isafwan.com/ar/ideas/better-questions-before-ai/) - [en](https://isafwan.com/en/ideas/better-questions-before-ai/) - [ru](https://isafwan.com/ru/ideas/better-questions-before-ai/) - [x-default](https://isafwan.com/ar/ideas/better-questions-before-ai/) - [zh-CN](https://isafwan.com/zh-CN/ideas/better-questions-before-ai/) [Safwan AlModhayan](https://isafwan.com/zh-CN/)[观点](https://isafwan.com/zh-CN/ideas/) 已发表 # 先把问题写清楚，再谈人工智能 采用人工智能之前，真正需要被设计的往往不是提示词，而是问题、决定与责任之间的边界。 一个团队说要“引入人工智能”时，讨论很容易直接滑向模型、接口和成本。更早也更难的一步却常被跳过：究竟要改善哪一个决定？谁会受到这个决定影响？什么样的错误可以接受，什么样的错误必须由人及时拦下？如果这些问题没有被写清楚，工具选择再精细，也可能只是在加速一个尚未定义的流程。 工具能够生成答案，却不能替人决定什么值得回答。它可以整理材料、比较版本、发现重复，甚至提出新的表达方式；但“是否应该这样做”并不包含在生成能力之中。能力描述的是可能性，决定表达的是取舍，责任则说明出现后果时谁必须解释、纠正并承担代价。把三者混成一句“系统建议如此”，只是让真正的判断者从语言里消失。 问题的边界越模糊，自动化放大的就越可能是含混本身。比如“提高服务效率”听起来合理，却没有说明效率属于谁：是让工作人员更快结案，让使用者更少等待，还是减少机构的支出？这些目标可能同时成立，也可能彼此冲突。一个可操作的问题需要说明对象、时间范围、成功条件、禁止越过的边界，以及遇到不确定信息时应当暂停还是继续。 设想一个完全假想的工作流程：某机构希望用模型给来信分类，并起草回复。第一版目标写成“自动处理所有来信”。重新审视后，团队把它改为“识别常见主题，为工作人员生成可编辑的回复草案；涉及权利、金钱或人身风险的内容必须由指定人员阅读”。后一个版本没有夸大工具，也没有拒绝自动化，而是把速度、例外和责任放进同一张图里。 这时，测试也会发生变化。团队不只问草案是否通顺，还要查看分类错误会把来信送到哪里，工作人员能否看见模型依据不足的地方，使用者是否知道自己面对的是草案流程，以及紧急内容能否绕过常规队列。测试对象从“模型表现”扩大为整个决定系统，因为实际后果通常产生在交接处，而不是产生在演示画面里。 定义问题还需要承认利益并不天然一致。管理者可能关心吞吐量，工作人员关心解释负担，使用者关心被准确理解，法务或安全人员关心不可逆的风险。好的问题不会假装这些关注点已经统一，而会把冲突摆到桌面上，明确谁有权设定阈值、谁能要求复核、谁可以让流程停止。 责任不能随着一次点击转交给模型。即使输出由系统生成，采用输出、把它送入流程、允许它影响他人的仍是组织中的决定。责任设计因此需要留下清晰记录：输入来自哪里，哪些内容被修改，谁批准了最终行动，申诉如何进入，错误由谁通知相关者。记录不是为了堆积文件，而是为了让解释和修复成为可能。 当然，先定义问题也有局限。现实中的目标会变化，少数情况无法提前列全，参与者也可能用漂亮的定义掩盖真实动机。因此，问题陈述不应成为一次性文件。它更像一份可以被质疑的工作协议：随着新证据出现而修订，同时保留修改原因，让团队看见目标如何移动，而不是事后声称一切早有安排。 采用工具之前，可以进行一次短暂但严格的检查：把拟自动化的决定写成一句话；列出会承受错误的人；区分可逆与不可逆的后果；指定必须由人完成的判断；再写下停止条件。若团队无法在这些句子上达成清楚的理解，继续比较模型排行榜不会让问题自动成熟。 真正有用的起点不是“我们能用人工智能做什么”，而是一个更具体的追问：在这个流程里，我们希望改善哪项决定，又有哪些责任无论工具多强都必须留在人手中？ [隐私](https://isafwan.com/zh-CN/privacy/) ## 来源 网站新编文本，并非历史引语或个人回忆录 [来源 ↗](https://isafwan.com/zh-CN/colophon/) 已发表 ## 主题 [人工智能](https://isafwan.com/zh-CN/topics/#artificial-intelligence)[真相与认知](https://isafwan.com/zh-CN/topics/#truth) [阅读清单 ↗](https://isafwan.com/zh-CN/archive/) ## 相关内容 [观点 / 已发表数据提供视野，但不会替你作决定指标能帮助人看见变化，也会把注意力锁定在可记录的部分；判断必须处理那些尚未进入表格的现实。](https://isafwan.com/zh-CN/ideas/data-does-not-decide/)[观点 / 已发表安全是一种设计决定安全不只关乎阻挡访问，也关乎权力如何分配、摩擦放在哪里，以及系统出错后能否被解释和修复。](https://isafwan.com/zh-CN/ideas/security-is-a-design-decision/) [返回](https://isafwan.com/zh-CN/ideas/)