30 Aug 2026

提高 chatgpt 工作效率：我最需要改进的 3 个习惯

最近我使用 chatgpt 和 codex 的频率越来越高，处理的事情也从简单问答扩展到了项目分析、代码修改、文档生成、浏览器操作、定时任务和环境验证。

这些实践确实节省了不少时间，但回顾最近的使用过程，我发现自己还有 3 个明显可以改进的习惯：任务要求经常边做边补充、review 节点设置得过多、相似工作仍然通过临时对话重复发起。

这 3 个问题并不是 chatgpt 不够聪明，而是我还没有把人与 ai 的协作方式设计得足够清楚。下面是我准备直接采用的改进方法。

一、从边做边补充要求，改为先写任务契约

我以前经常这样开始一个任务：

帮我看看这个项目，优化一下文档。

任务开始以后，再逐步补充：不要修改代码、要面向初学者、需要实际命令、不能包含本机路径、完成后先让我 review。

这种方式看起来省事，实际上会产生两个问题：

• chatgpt 在前期缺少边界，容易先做出不符合预期的内容；
• 对话越长，重复要求越多，后续每一步都要重新确认上下文。

更高效的方式不是写一篇很长的 prompt，而是在开始时提供一份简短的“任务契约”。我准备固定使用下面 5 个字段：

目标：最终需要得到什么结果
来源：以哪些文件、页面或实时数据为准
约束：哪些内容不能修改，哪些信息不能出现
交付：需要生成什么文件或结果
验收：完成前必须通过哪些检查

例如，优化一个开源项目的使用文档，可以直接这样写：

目标：把当前项目的 readme 改成初学者可以独立完成的安装和运行指南。
来源：以当前工作区的代码、脚本和依赖文件为准，不要根据旧对话猜测。
约束：只修改 readme，不修改代码；不要写入用户名、绝对路径或内部地址。
交付：直接修改文件，并总结主要变化。
验收：检查命令与项目一致，检查链接、markdown 格式和 git diff。

这类写法比详细规定“先打开哪个文件，再运行哪条命令”更有效。只要结果、事实来源和验收标准清楚，就可以让 chatgpt 自己选择效率更高的执行路径。

我的落地规则是：

超过 10 分钟、涉及文件修改或需要最终交付物的任务，开始前先写任务契约；简单问答不需要套模板。

二、从每一步都 review，改为一次定义授权边界

我很重视 review，尤其是部署、删除、推送代码和对外发送信息时。这是必要的安全习惯，但如果所有步骤都需要单独确认，就会把一个完整任务拆成很多轮对话。

例如，一个本地文档修改可能出现这样的过程：允许读取文件、允许编辑、允许检查格式、允许查看 diff。每一步都很安全，却因为没有提前授权而反复停下来等待。

更实用的做法是，在任务开始时直接选择授权级别：

高风险或不可恢复的动作仍然需要单独确认，例如删除数据、覆盖未知文件、修改生产环境或扩大原任务范围。review 不应该被取消，而应该放在真正需要人做判断的位置。

一个允许连续执行、但保留发布确认点的任务可以这样写：

允许你读取当前项目、修改指定页面并运行本地检查。
检查通过后停下来给我看 diff，不要提交、推送或部署。
如果发现必须修改其他模块，先说明原因，不要自动扩大范围。

如果整个流程已经成熟，也可以一次授权到底：

直接创建今天的博客，完成格式和隐私检查，只提交这篇文章，然后推送到当前远程分支。
如果检查失败或出现无关改动，停止发布并报告原因。

这样既不会牺牲安全性，也能避免 chatgpt 在读取、编辑、验证这些预期操作之间频繁暂停。官方 openai 文档同样建议明确自主执行和批准边界，让模型在安全范围内持续工作，并在外部、破坏性或超出范围的操作前停止。

我的落地规则是：

每个任务只设置一次默认授权级别；只在外部影响、不可恢复操作或范围变化时增加新的 review 节点。

三、从重复发起相似对话，改为选择正确入口并沉淀工作流

我现在会用 chatgpt 讨论问题，也会让它创建文档、修改仓库、操作应用和运行定时任务。如果所有事情都从一个临时对话开始，短期很方便，长期会出现上下文混杂和重复说明。

更高效的方式是先根据结果选择入口，再决定是否需要复用：

例如，“今天应该优先处理什么”适合先在 chat 中讨论；“根据会议材料生成周报”更适合交给 work；“修改前端页面并运行测试”应该直接在 codex 项目中完成。

对于重复工作，我准备使用下面的沉淀流程：

第一次：手动执行，确认输入、步骤和结果是否正确
第二次：修正规则，补充异常处理和验收标准
第三次：稳定流程保存为 skill
需要定时运行：在手动流程稳定后再创建 automation

例如，每周工作总结不应该每次重新说明“读取哪些材料、忽略哪些内容、如何分组”。这些规则稳定后，可以保存成固定工作流；如果还需要每周自动执行，再增加 automation。只依赖网页或云端资料的任务优先放在云端运行，必须访问本机文件或桌面应用时才使用本地环境。

skill 也不应该只是保存一段长 prompt。一个可用的 skill 至少要固定以下内容：

• 什么情况下使用；
• 输入和事实来源是什么；
• 哪些操作允许自动执行；
• 遇到什么情况必须停止；
• 完成后如何验证结果。

openai 的官方使用案例也把“将重复工作流保存为 skill”和“运行可验证的重复操作”列为 codex 的典型用法。真正的效率提升不是少输入几句话，而是让同类任务不用每次重新设计。

我的落地规则是：

同一类任务执行 3 次后必须判断是否应该沉淀为 skill；有固定时间要求时，再判断是否应该创建 automation。

总结

这 3 个改进可以组合成一套很简单的工作方式：

先写清任务契约
→ 一次定义授权边界
→ 选择合适的执行入口
→ 完成并验证结果
→ 将稳定流程沉淀为 skill 或 automation

我需要减少的不是使用 chatgpt 的次数，而是无效的补充、重复的确认和每次从零开始的流程设计。

以后开始一个实际工作任务前，我会先问自己 3 个问题：结果和验收标准是否清楚、chatgpt 被允许执行到哪一步、这项工作是否已经重复到应该沉淀了。只要这 3 个问题有明确答案，chatgpt 才能真正从聊天工具变成稳定、高效的工作助手。

ref

• openai 模型和 prompt 最佳实践
• chatgpt、work 和 codex 使用方式
• chatgpt 和 codex 官方使用案例

LEo at 00:12