先把问题写清楚，再谈人工智能

一个团队说要“引入人工智能”时，讨论很容易直接滑向模型、接口和成本。更早也更难的一步却常被跳过：究竟要改善哪一个决定？谁会受到这个决定影响？什么样的错误可以接受，什么样的错误必须由人及时拦下？如果这些问题没有被写清楚，工具选择再精细，也可能只是在加速一个尚未定义的流程。

工具能够生成答案，却不能替人决定什么值得回答。它可以整理材料、比较版本、发现重复，甚至提出新的表达方式；但“是否应该这样做”并不包含在生成能力之中。能力描述的是可能性，决定表达的是取舍，责任则说明出现后果时谁必须解释、纠正并承担代价。把三者混成一句“系统建议如此”，只是让真正的判断者从语言里消失。

问题的边界越模糊，自动化放大的就越可能是含混本身。比如“提高服务效率”听起来合理，却没有说明效率属于谁：是让工作人员更快结案，让使用者更少等待，还是减少机构的支出？这些目标可能同时成立，也可能彼此冲突。一个可操作的问题需要说明对象、时间范围、成功条件、禁止越过的边界，以及遇到不确定信息时应当暂停还是继续。

设想一个完全假想的工作流程：某机构希望用模型给来信分类，并起草回复。第一版目标写成“自动处理所有来信”。重新审视后，团队把它改为“识别常见主题，为工作人员生成可编辑的回复草案；涉及权利、金钱或人身风险的内容必须由指定人员阅读”。后一个版本没有夸大工具，也没有拒绝自动化，而是把速度、例外和责任放进同一张图里。

这时，测试也会发生变化。团队不只问草案是否通顺，还要查看分类错误会把来信送到哪里，工作人员能否看见模型依据不足的地方，使用者是否知道自己面对的是草案流程，以及紧急内容能否绕过常规队列。测试对象从“模型表现”扩大为整个决定系统，因为实际后果通常产生在交接处，而不是产生在演示画面里。

定义问题还需要承认利益并不天然一致。管理者可能关心吞吐量，工作人员关心解释负担，使用者关心被准确理解，法务或安全人员关心不可逆的风险。好的问题不会假装这些关注点已经统一，而会把冲突摆到桌面上，明确谁有权设定阈值、谁能要求复核、谁可以让流程停止。

责任不能随着一次点击转交给模型。即使输出由系统生成，采用输出、把它送入流程、允许它影响他人的仍是组织中的决定。责任设计因此需要留下清晰记录：输入来自哪里，哪些内容被修改，谁批准了最终行动，申诉如何进入，错误由谁通知相关者。记录不是为了堆积文件，而是为了让解释和修复成为可能。

当然，先定义问题也有局限。现实中的目标会变化，少数情况无法提前列全，参与者也可能用漂亮的定义掩盖真实动机。因此，问题陈述不应成为一次性文件。它更像一份可以被质疑的工作协议：随着新证据出现而修订，同时保留修改原因，让团队看见目标如何移动，而不是事后声称一切早有安排。

采用工具之前，可以进行一次短暂但严格的检查：把拟自动化的决定写成一句话；列出会承受错误的人；区分可逆与不可逆的后果；指定必须由人完成的判断；再写下停止条件。若团队无法在这些句子上达成清楚的理解，继续比较模型排行榜不会让问题自动成熟。

真正有用的起点不是“我们能用人工智能做什么”，而是一个更具体的追问：在这个流程里，我们希望改善哪项决定，又有哪些责任无论工具多强都必须留在人手中？