AI 写作让一份文档的初稿变得很容易：把几条要点丢给模型，一份结构完整、措辞专业的文字很快就出来了。可使用 AI 辅助写作时，怎样确认自己仍在独立思考，而不只是接受一份读起来顺畅的答案？
省下时间当然好。但交出去之前，可以试着关掉文档，向同事讲清楚三个问题：为什么选择这个方向，什么条件下它会失效，还有哪个问题暂时没有答案。
如果离开那份文字，就说不明白自己的决定，那么这次写作可能还没完成。
Paul Bakker 在《Don’t use AI to write》中提出了一个值得讨论的观点：写作会逼人思考，直接生成初稿容易跳过这个过程。他主张先自己写，再用 AI 的反馈检查表达。这是一种个人工作方法，不能据此断言 AI 必然削弱人的思考能力。沿着这个提醒，我更想讨论一个具体问题：一份看起来已经写完的文档，如何把尚未解决的判断藏起来？
AI 写作为什么容易掩盖没想清的问题
设想你要给一台联网设备写远程升级方案。手头只有几条要求：支持断点续传、升级失败能恢复、尽量少占存储、用户操作简单。
让 AI 扩写，它可能会给出一套很像样的结构：下载、校验、安装、回滚，再加上进度提示和日志记录。每个环节都合理，标题之间也接得上。
可在真实设备上，几个词背后都是具体的工程选择。
「失败能恢复」到底指什么？下载中断后重试，和写入固件时掉电后仍能启动，是两件不同的事。「少占存储」与「保留一份可回滚的固件」可能存在资源上的冲突。「用户操作简单」也要问清楚：设备没有屏幕时，用户从哪里知道升级还在继续？
这些问题没有被回答，文档却已经有了总结和实施建议。它的完整外观会让人误以为，剩下的只是执行。
自己动笔时，写到「失败后自动恢复」这一句，往往会卡住。你得去查启动流程、核对分区布局，或者找硬件同事确认约束。这个停顿有价值，因为它把一个含混的愿望，变成了需要查证的问题。
AI 也能帮助发现这些遗漏。前提是，你要让它检查具体条件，并把查出来的缺口继续追下去。
如何用 AI 辅助写作，保留自己的判断
先写下优先级、未知条件和下一步行动
不必把每篇初稿都写得漂亮。写方案之前，先留下一小段自己的判断，哪怕只有几行：
这次最先要解决的是升级后无法启动的问题。当前存储是否足够保留旧固件，还没有确认。如果不够，需要重新评估恢复方式。我倾向于先验证掉电场景，再讨论操作界面的优化。
这段话不够周全，却交代了优先级、未知条件和下一步行动。它给后面的讨论一个明确起点。
接下来再把资料和这段判断交给 AI，让它帮助整理，或者提出替代方案。它提出新方向时，你也有一份记录可以对照：自己的决定为什么变了？是发现了新证据，还是只觉得它说得更有气势？
初稿的作用之一，就是留下这条判断路径。修改之后的版本可以更简洁，但不该让那些尚未确认的条件凭空消失。
用方案审查提示词找出缺失条件
「帮我优化这份方案」容易得到一轮措辞调整。更有用的要求，是告诉 AI 从哪个角度检查，以及检查结果要怎样呈现。
例如，可以这样问：
请从固件开发和售后维护两个角度审查这份方案。逐条指出哪些承诺缺少实现条件，并列出需要查文档、做实验或向同事确认的问题。不要自行补全未知的硬件参数。
再追问一轮：
假设升级过程中随机掉电，请沿启动流程检查方案。区分文档明确说明的行为、你推测的行为，以及目前无法判断的行为。
这样的反馈更容易落到行动上。读完之后，你应该知道要补哪项实验、找谁确认、撤回哪个过早的承诺。
把 AI 审查意见带回原始资料核查
AI 的质疑同样需要核查。它可能提出一个设备根本不支持的机制，也可能漏掉某种失败路径。因此，审查意见要回到器件文档、现有代码和测试结果中验证。多个模型都觉得合理，也不能替代一次真实的掉电测试。
处理反馈时，可以给每一项标明「已确认」「待验证」或「不适用」，并记录依据。涉及硬件参数的，查器件文档；涉及现有行为的，读代码或复现实验；涉及需求取舍的，找实际负责的人确认。缺少依据的建议，暂时留在待办里，别直接写成方案已经具备的能力。
AI 写作的使用边界：哪些内容值得自己先想
区分传达已有决定与形成新决定
并非所有写作都值得从空白页开始。已经确定的会议安排、例行通知、格式转换，可以交给 AI 起草，再核对姓名、时间和要求。对表达有困难的人，AI 也能帮助把已经形成的想法说清楚。
技术方案、复盘和观点文章需要更多投入，因为写作过程中往往还要作决定。一个实用的分法是看这份文字的用途：它是在传达已有决定，还是在帮助形成决定？后者尤其值得先自己想一轮。
即使用 AI 生成了初稿，也可以把它当作待审的提案。逐段追问依据，删去无法兑现的承诺，写下不同意的地方，必要时从头改写。生成得快，不等于必须接受得快。
提交前检查：能不能解释自己的决定
文档交出去之后，讨论才刚开始。同事会问预算不足怎么办，客户会问为什么没有另一个功能，测试人员会拿出与你预期不同的结果。
这时，真正有用的是你能解释已有决定，也能根据新信息调整它。文字再流畅，如果无法支撑这些讨论，就还需要继续做功课。
下次用 AI 写重要文档，可以保留一个小习惯：提交前，合上成稿，用自己的话回答下面四个问题。
- 这份文档要解决什么具体问题？
- 为什么选择这个方案，放弃了哪些替代方案？
- 哪些结论已经有依据，哪些还需要验证？
- 如果关键条件改变，应该调整哪个决定？
讲不通的地方，就回去补证据、补推理，或者明确写成限制。这个检查用于发现文档中的判断缺口，不是用来测量一个人的思考能力。
让 AI 帮忙之后，问题应该变得更清楚，你也应该更能说明自己为什么这样决定。
阅读来源：Paul Bakker — Don’t use AI to write，发表于 2026 年 8 月 13 日。本文据其核心观点重新组织，并加入联网设备升级方案的假设场景与使用建议；不作逐句翻译，延伸分析不代表原作者观点。