工作流，才是高手与新手使用 ChatGPT、Codex 的差距
为什么高手和新手的差距会越用越大？
最近整理了一波自己的收藏，X、小红书、抖音、知乎和公众号的，整理了一大堆所谓的“技巧”。有一些已经在使用，有一些还属于新发现。但无一例外的是：最热的内容，提示词总是洋洋洒洒一大篇；而高手的案例里，输入框里其实没多少东西。项目资料在文件里，长期规则在 AGENTS.md 里，重复的方法做成 Skill，正确与否交给测试、来源和验收标准，当前提示词只需要说清楚差异即可。6月份以前，自己还属于松鼠症晚期，看到一个技巧就想装一个，配置、插件、Skill 越来越多，正经事没干多少，工具先堆了一桌子（差生文具多的典型）。后来才发现，工具换来换去，真正能留下来的，不是哪个按钮，而是怎么把一件事交给 AI，怎么知道它跑偏了，怎么把这次踩过的坑留到下一次。这些文章分别分享了自己在各个实践中的经验和思考，现在回头看，还缺了一条线：我们该如何组织自己和 AI 工作的方式？（这些是我的思考与分析，高手与新手的差异在于个人判断，请勿对号入座）新手每次都在重新写说明书：你是谁、背景是什么、应该怎么做、分几步、用什么格式、哪些事情不能碰、最后怎么检查（这几年我就是这样）。高手把这些东西拆开了（其实就是把 Harness 里的不同东西分开）。这些东西不是为了让系统看起来复杂，而是把一次任务里会反复出现的判断搬到提示词之外。Harness 不是一条更长的提示词，而是套在模型外面的工作环境：项目文件、规则、Skill、工具和验收（Codex 官方文档也把 AGENTS.md 定义成项目级的长期指导，并允许按目录分层覆盖）。[1]所以高手的提示词看起来短，不是因为他没想清楚，而是因为 Harness 部分已经外置了。OpenAI 的提示文档也没有要求固定格式，复杂任务只要把目标、上下文、输出和边界交代清楚，再根据结果继续修正就行。[2]万能提示词想把所有情况都写在当前对话里，高手的工作流则会把不经常变化的部分搬出去，只把当前变化留下来——前者每次重新装配，后者是在用已经装好的东西。ChatGPT 和 Codex，到底该谁负责哪一段？关键不在谁更强，而在任务有没有被放到合适的环境里。ChatGPT 适合在问题没定型时的工作，把模糊想法说清楚。比如搜集外部资料，比较不同方案，处理文档、报告和表格。而 Codex 更适合问题已经落到真实环境以后：读代码库，改文件，跑命令，查日志，看 diff，补测试，继续修正。所以，有效的组合就是：让 ChatGPT 和 Codex 分别接住不同阶段。所以，使用 ChatGPT、Codex 的第一步不是选一个“最强模型”，然后用一个「万能提示词」搞定任务，而是先分清楚：我现在缺的是理解、资料、动作，还是验证？很多人理解的「项目」，就是一个可以把所有资料和聊天都装进去的文件夹（我之前也这么认为的）。实际上，正确的做法是：给这项工作真正需要的文件、指令和上下文。官方建议，工作会持续一段时间、产生多个成果，或者依赖同一批资料时再建项目；不同成果仍然应该拆成不同聊天。[3]文件太多，旧版本太多，或者同一个决定只在某次聊天里顺手提过，项目记忆不一定会按你想要的方式召回。真正不能出错的内容，还是要写进一份可以回查的文件里（我是直接让AI来干哈哈哈）。这也是我后来把“经验落文档”看得越来越重的原因——记忆适合带回背景，项目适合组织工作，文档才适合保存当前事实和已经确认的决定。如果只是问一次“帮我改一封邮件”这种小问题，直接在网页端用 Chat 模式就行（还省额度，有方向了可以直接转到客户端来）；如果要连续几周处理同一批资料，或者每次都要遵守同一套规则，项目通常更适合。AGENTS.md、Skill 和 MCP，分别应该解决什么？这几个词经常被放在一起，但它们本来就不在同一层：分别是规则、方法、工具和验证。这两个观点其实是一回事：不要把“怎么做这一次”和“以后遇到这类问题都应该怎么判断”混成一份说明书。MCP 解决的是 AI 能不能拿到 GitHub、Drive、Slack 或本地系统里的信息，不能替你判断这些信息是否完整、是否过期、是否足以支持一个结论（吃过MCP拿了过期信息的亏）。同一个工作目录里，同时让多个 Agent 或进程改同一批文件，通常不是真正的并行，而是冲突排队（AI 上一秒读了文件，下一秒文件又变了，你想想那个画面，有独立分支、worktree 或只读检查时，另当别论）。并行最适合处理互不冲突的“读”和“查”：不同平台搜资料、不同模块做检查、不同方案做对比。社区里有人分享过一种重型 Codex 编排：主 Agent 负责理解和分发，上下文更窄的执行分身负责测试、修复和文档，主线程只接收重要变化。但要注意，省下的上下文和额度，也可能被低质量实现和后续返工吃回去。[4]流程还没稳定，就急着让它每天、每小时、无人值守地重复，只会更快地制造混乱。“已经生成”“已经执行”和“已经验证，可以进入下一步”，是三种不同的状态。使用 AI 时最容易发生的误会，是把“已经生成”当成“已经验证”。而如果是循环工程，还要把退出条件提前写出来：最多跑几轮，最多花多久；连续几轮没有新结果怎么办；遇到删除、发布、权限或产品决策时交给谁；预算上限和无进展退出，应该由运行循环的控制层守着，不能只写给 Agent 自己看；否则它很容易把“继续试”当成“正在接近完成”。没有预算出口和人工升级路径，所谓“自主运行”很容易变成“无人负责”。新手完成一次任务，留下的通常是一段聊天记录。下次遇到类似问题，再重新解释一遍、重新试一遍、重新踩一遍。内层循环，是把这次任务做完：触发、观察、动作、验证、停止，必要时升级。外层循环，是把这次经验留下来：记录结果，找出反复出现的问题，把它变成下一次不用重说的规则。我自己在这条线上折腾了几个月，本地两个目录加起来攒了 700 多个会话记录，最后蒸出了 8 个自己在用的 Skill（曾经最多的时候装过差不多 400 个 Skill，后来只留下自己创建和常用的十几个）。不是说“装得越多越专业”，它们只是说明了一个过程：很多东西必须真实跑过，才知道该留下什么；很多东西留下以后，还得继续用，才知道规则是不是写对了。长任务还要把状态放在聊天记录之外。当前做到哪一步、哪些决定已经确认、哪几个问题还没解决，写进项目文件或状态记录里；下一轮重新读它，不要相信模型还记得二十步以前的数字（吃过亏）。这就是工作流的复利：一次纠错只解决一次问题，纠错被写进规则以后，才会减少下一次的成本。高手并不是不犯错，只是不愿意为同一种错误反复付钱。[1]: OpenAI,《Custom instructions with AGENTS.md》,OpenAI Developers,访问 2026-09-09,https://developers.openai.com/codex/guides/agents-md[2]: OpenAI,《Prompting》,ChatGPT Learn,访问 2026-09-09,https://learn.chatgpt.com/docs/prompting[3]: OpenAI,《Projects and chats》,ChatGPT Learn,访问 2026-09-09,https://learn.chatgpt.com/docs/projects[4]: u/Otherwise-Sir7359,《How I effectively got 3× more Codex usage by changing the orchestration workflow》,Reddit r/codex,2026-08-13,https://www.reddit.com/r/codex/comments/1vmqscy/howieffectivelygot3morecodexusageby/
