会议开始前，有人把一段需求描述丢进对话框，几秒后得到一份结构完整的说明。语气平稳，条目清楚，看起来可以直接转发。问题在于，转发之前没人能说清：这些内容是来自可查的来源，还是模型根据上下文拼出的合理表述。
这不是个例。生成式人工智能进入日常办公后，最容易被误用的场景之一，就是把它当成搜索引擎。搜索引擎返回链接，要求人去点开、比对；生成式工具返回一段已经组织好的话，顺手把“查找”和“写作”合并了。合并带来效率，也把判断环节藏了起来。
流畅答案不等于可核验信息
从机制上看，生成式人工智能在做的是基于上下文预测和生成语言，而不是从某个固定数据库里逐条调取事实。它可以把一个模糊需求扩写成邮件、提纲、会议纪要的草稿，也能把一段生硬表述改得通顺。但这些能力指向的是语言组织，不是来源担保。遇到细节、数字、时间、引用时，生成内容需要回到原始材料核对。这个动作听起来笨，却决定了它能不能进入正式流程。
我倾向于把它放在“初稿助手”的位置：先让生成式人工智能给出一个可修改的框架，再由人补充事实、删去不确定表述、标注来源。这样做并不削弱它的价值，反而让使用边界更清楚。团队里如果只强调“能不能生成”，很容易忽略“生成之后谁来负责”。
先分清任务，再决定是否打开对话框
在实际工作里，可以把请求分成几类：
- 适合起草：通知、提纲、改写、头脑风暴、把零散笔记整理成段落。这些任务对语言组织要求高，对事实精度要求相对可控。
- 适合解释：让工具用更通俗的话说明一个概念，但概念本身仍需回到可靠资料确认。
- 需要谨慎：涉及具体来源、数字、时间、人物关系的内容，不宜直接采用生成结果。
- 需要复核：任何准备对外发布或进入正式决策流程的文本，都应有人读过、查过、改过。
这个分法不复杂，难的是在赶时间的时候仍然执行。很多误用不是因为不知道风险，而是因为答案看起来足够顺。越顺的文本，越容易让人跳过核对。一个可行的习惯是：让工具在给出内容时同时列出“哪些地方需要人工确认”，把不确定项显性化。即使它列得不完整，也能提醒使用者不要把整段话当成结论。
协作里要说清楚的几件小事
团队使用生成式人工智能，未必需要一份很厚的规范。更实际的是把几个动作固定下来：对外文本标注是否经过工具辅助；引用信息回到原始出处；内部资料不随意粘贴到不可控的对话窗口；重要内容由提出需求的人完成最后复核。这些动作不针对某个工具，也不依赖某个模型版本，换一个产品仍然成立。
还有一个容易被忽略的问题：当生成内容进入协作文档，后来的人往往只看到结果，看不到它经过哪些修改。于是“谁写的”和“谁核对的”变得模糊。解决方式不是拒绝工具，而是在流程里留下痕迹，比如保留修改说明、标明待确认项、把来源链接放在段末。痕迹越清楚，工具越像工具，而不是一个无法追问的答案来源。
回到开头那个场景，我更愿意把问题改成：这份生成内容里，哪些句子可以直接用，哪些必须查？生成式人工智能可以帮人更快走到草稿，但走到可发布、可决策的位置，仍需要人来完成最后一段路。把这段路说清楚，比争论它像不像搜索引擎更有意义。