一次项目复盘会上，团队试着用生成式人工智能整理录音。几分钟就出了稿，句子通顺，结构也像样。但大家随后花了更长时间核对：谁说了哪句话，哪些结论被润色得变了味，哪段总结其实漏掉了分歧。省下来的时间没有消失，只是换了个地方出现。
这算不上反对工具。它更像一个提醒：生成式人工智能把“写出来”的成本压低了，却把“判断能不能用”的成本推到了前面。
它先替代的是“第一稿”
生成式模型的基本动作，是根据上下文预测接下来的词。这个机制让它很擅长把零散要点扩成通顺段落：邮件初稿、会议纪要、产品说明的几种说法，它都能快速给出。问题是，“通顺”不等于“准确”。它不会自动知道你们内部的术语、项目的来龙去脉、哪句话只是气话。信息不完整时，它会补一个看起来合理的说法。草稿阶段这可以接受，对外文件里就是风险。
省下的时间，常常花在“说清楚”上
一个容易被忽略的环节，是把需求讲明白。要让生成式人工智能给出可用结果，得先交代背景、对象、语气和禁忌。这个动作本身有价值，但也占时间。有人用一句话让它写，拿到泛泛的稿子，再改三遍；有人花十分钟写清约束，一次得到接近可用的版本。差别不在模型，在使用者愿不愿意把隐含判断显性化。这其实是管理问题，不是技术问题。
哪些事不适合直接交出去
我目前会划出去几类场景：
- 需要对外担责的承诺和数字，必须有人复核；
- 涉及未公开信息的判断，不直接交给外部模型；
- 需要理解内部微妙关系的沟通，先由人定调；
- 事实性内容逐条核对，不让“看起来合理”替代“确实如此”。
还有一个边界是连续性。它不记得上次为什么否掉某个方案，除非你重新交代。把长期项目的上下文完全交给它，容易得到“每次都正确、但彼此不连贯”的输出。
把它当同事之前，先当工具
如果团队准备把它放进日常工作流，有几件事值得先做：固定审核环节，明确哪些文档可以用、哪些不能，要求标注生成部分，保留修改记录。这不是流程洁癖，而是让责任可追溯。工具越顺手，越容易跳过检查。真正影响效率的，不是生成那几秒，而是从需求到可交付之间的返工次数。
回到开头那个场景。后来团队改了个小规则：录音转写后，先由最熟悉项目的人标出关键结论，再让生成式人工智能整理成稿。时间没省多少，但返工少了。生成式人工智能的位置也清楚了：它负责把话写顺，人负责判断哪些话该说。