AI 能加速个人产出，但只有经过核对、删减和编辑，才不会把成本转嫁给团队。
原文链接：AI 小老六
AI 最容易制造一种错觉：屏幕上出现了更多文字，工作就完成得更多了。
很多团队已经尝到这种甜头。技术方案几分钟生成，PR 描述自动补齐，测试用例一口气扩展几十条，决策备忘录从半页变成五页。个人当然变快了。问题是，团队没有。
图：个人生成速度提高后，团队审阅压力也可能同步上升
慢的部分没有消失，只是换了人承担。
一个工程师要写数据库迁移方案。以前他会花一个下午读代码、查资料、删掉不确定的判断，最后写出一份相对短的说明。每句话都经过他自己的脑子。现在他把上下文丢给模型，几分钟后拿到一份漂亮、完整、分点清楚的方案。
看起来效率提高了。可审阅者打开文档后，麻烦才开始。
审阅者真正要确认的，往往不是文档写得漂不漂亮，而是里面每个判断是否成立：
- “当前任务是顺序处理事件。”是真的吗？
- “迁移涉及九张表。”谁数过？
- “可以先灰度新写入路径。”依赖条件在哪里？
人手写的一句话，通常隐含一个承诺：我查过，我认可，我愿意为这个判断负责。模型生成的一句话没有这个承诺。审阅者看不出哪些是工程师确认过的，哪些只是模型顺手补出来的。于是整份文档都要被当成未核验材料处理。
这就是 AI 时代最隐蔽的时间转移。
| 表面变化 | 实际发生的事 |
|---|---|
| 写方案更快 | 审阅者需要检查更多未经压缩的内容 |
| PR 描述更完整 | 维护者要判断哪些说明真的对应代码 |
| 测试更多 | 后续的人要确认测试是否覆盖了正确行为 |
| 决策文档更正式 | 会议里仍要重新厘清取舍 |
文档本来是一种服务。写的人多花一点时间，读的人就少花一点时间。公司里通常是一个人写，很多人读，所以写作者欠读者一个更短、更准、更干净的版本。
图：好的 AI 工作流会把核对和压缩留在交付前
AI 把初稿成本降得很低，但没有把编辑成本降到零。删减、核对、压缩、判断，仍然是工作本身。少了这些步骤，生成内容就会像一张账单，递给后面每一个人。
代码里也一样。AI 可以帮忙写出大段改动，但不能替你理解改动。一个很实用的规则是：解释不清的代码，就不要合进去。这个规则同样适用于文档：解释不清的一句话，就不要留在最终版本里。
更健康的流程应该是这样：
图：从 AI 初稿到可审阅版本，中间必须经过人工核对和压缩
这里最关键的一步是 C。很多 AI 草稿的问题不是错得离谱，而是“没错但没用”。它把背景、风险、建议、下一步都写满，却没有告诉读者此刻到底要做什么决定。
收到这种内容的人也不必硬着头皮审。可以直接把球打回去：
这看起来还是未经编辑的草稿。请压缩到结论、取舍和需要我判断的点，我再看。
这不是挑剔，是保护团队吞吐量。
AI 当然该用。它能省掉搜索、起草、补全和改写的大量时间。但省下来的时间最好花回去一部分，用来检查事实、缩短文字、明确责任。否则个人的速度会变成组织的阻力。
真正有效的AI 工作流有个很朴素的标准：它不能只是让你少花时间，还要让下一个人也少花时间。
如果做不到，所谓生产力提升只是从你的日历里搬到了别人的日历里。
推荐阅读
AI 短剧“买脸”上热搜：500 元肖像授权背后的生成式内容生意
AI 支付大战开打：微信支付宝争夺下一代交易入口
LLM 写代码为什么不能盲信：AI 编程进入生产前，必须过人类的门
AI 生成 PR 正在刷爆开源项目：GitHub 贡献信号为什么失灵了
AI 编程争论变味了：为什么反 AI 情绪开始走向怀旧化
