外网爆料者 @elder_plinius 近期公开了一份据称属于 OpenAI 现役代码模型 GPT-6 Sol Codex 的系统提示词与工具定义，文件已在 GitHub 仓库 CL4R1T4S 的 OPENAI/Codex_Desktop 路径下放出。按爆料说法，文档约 29.4 万字符、共 1902 行，涵盖指令模板、临时指令文件与内部协作逻辑。需要说明的是，这份材料的真实性在开发者社区仍有争议，下文仅以「若内容属实」为前提，拆解其中反映出的提示词工程与智能体设计思路。

先给自己列了一份「废话黑名单」

文档中最直观的一点，是 OpenAI 在写作风格板块对模型做了严厉的反套路训练。指令点名要求避免使用一批「AI 废话词汇」，例如结论中不要写「底线是（Bottom Line）」「重要性（Significance）」「视角（Perspective）」，也不要用「深入（delve）」「培养（foster）」「利用（leverage）」「值得注意的是（it’s worth noting）」「重要的是（importantly）」这类套话。

更进一步的约束包括：不准强行热情——要求模型像「充满好奇心、思想严谨的协作者」，让个性自然流露，而非阿谀奉承；不准用废话凑字数，直接说明意图，不要列举「我不会做什么」「哪些保持不变」；讨论技术概念时像和同事对话，优先用熟悉词汇与具体描述，绝不假设用户能自行脑补缺失步骤。

对中文使用者而言，这相当于给所有提示词工程师上了一课：想要模型输出高质量内容，第一步往往是建立一份负面词汇黑名单，强制斩断套路化表达。

被赋予「别烦我，我在干活」的自主权

文档把 GPT-6 Sol Codex 塑造成一个拥有极高自主权的数字员工。在「自主与持久性」章节，指令明确要求：一旦会话中的证据支持下一步操作，模型就应继续工作，而不是停下来向用户确认；不要为了节省时间或令牌而满足于「勉强有用」的半成品。

落到具体行为：遇到缺陷自己修，可自主创建隔离工作区、解决 Git 合并冲突、创建草稿拉取请求（PR），除非操作具有破坏性或不可逆，否则不会中途询问「接下来怎么办」；只有在点击「部署」或「合并代码」这类最后一步时，才把结果交给用户签字。为防止后台干活时把用户晾在一边，指令还规定：只要请求需要调用工具，每 60 秒必须在评论频道给出一条简短状态更新。

工具链偏好与并行策略

作为代码智能体，文档暴露了它对工具链的硬编码偏好。搜索文本或文件时，指令要求优先使用 rg（ripgrep，极速搜索工具）或 rg –files，而非更慢的 grep；多个独立任务必须用 await Promise.allSettled([…]) 并行处理，压榨时间效率。

文档还定义了一套名为 SKILL.md 的机制：当用户要求做某件事时，模型可去指定目录读取技能说明，甚至通过短路径别名快速调用，相当于给模型外挂了一本可热更新的「技能书」。在浏览器与桌面操作模块，OpenAI 设置了多级确认模式，既允许模型自己打开网页、点击按钮、填写表单、截图，又用复杂确认逻辑防止其「闯祸」。

记忆压缩与「心跳唤醒」

面对庞大代码库，大模型最怕上下文超载。文档给出的解法是：当令牌（Token）预算即将耗尽时，系统不会直接崩溃，而是先用笔记工具保存一份简明的交接记录——包含目标、决策、进度、学习内容、下一步，以及相关窗口与项目编号，再开启全新上下文窗口，如同人类换班前写交接文档。

更值得关注的是常驻后台能力：文档要求模型主动跟踪任务，例如用户问某个评估（eval）跑得怎么样、而它还在运行时，先报告当前状态，再继续监控直到终止；系统还会定期向模型发送隐藏的 XML 标签将其「唤醒」，检查后台任务是否完成。若无事可做，模型必须选择不通知；若持续集成（CI/CD）跑崩，则立即弹窗通知用户。

一份能直接抄走的代码审查指南

对程序员来说，文档里最实用的或许是内置的代码审查规则：忽略无关紧要的代码风格，除非它影响可读性或违反既定标准；每一条建议都必须用一段话讲清「为什么这是个问题」；绝不提供超过 3 行的代码片段；若是具体替换建议，必须使用 Markdown 的 suggestion 块，并完美保留原有缩进；语气必须客观，禁止拍马屁，不许说「干得好」「谢谢你的提交」。这套逻辑稍加改造，就能接进公司内部的代码审查机器人。

社区怎么看

这份近 30 万字的泄露在外网开发者社区引发两极反应。有人被其系统工程密度震撼；也有人质疑意义——网友 vechen 指出，这「泄露」可能本就从本地文件直接取得，在 OpenAI 公开的 Codex 仓库里本就有影子；另有开发者嘲讽，称任何人跑一个 mitmproxy 都能从 OpenAI、Gemini 或 Claude 提取提示词，无需包装成「死海古卷」般的噱头。

无论真伪，这份文档折射出一个趋势：工业级人工智能应用靠的不是几句讨巧话术，而是严密的系统工程——模块化技能动态加载、记忆管理与压缩、并行执行与重试、以及挂载严格的安全协议。大模型正从一个聪明的对答机，逐步演进为具备接管权限的自主系统，而这类底层逻辑，正是通向该方向的一份说明书。

Anthropic 在发布后不久推出了配套的提示词指南，专门给这类问题打补丁。官方排查清单直接点名了这种「半路溜号」：无人值守的智能体汇报完进度后，直接停在了中途。

根子出在「太爱汇报」

问题的根源在于 Opus 5.5 太爱汇报进度。处理长任务时，它会主动同步进展；但有些汇报发完，它就不再调用工具，API 返回的信号表示本回合结束（end_turn）。而不少沿用旧逻辑的程序只认一条死规矩：模型不再调用工具，就算任务完成。一份进度汇报，就这样被当成了交差。

官方指南说得很直白：纯文本的回合结束，应当视为一份汇报，绝不能当作任务完成的凭证。

四种典型停法

官方把中途停工归纳为四种情况：

• 纸上谈兵：写完长篇总结、宣布下一步要做什么，却没调用任何工具，下一步永远停在口头上。
• 过分礼貌：干到一半突然停下来问「如果您不介意，我接下来继续处理某事项」，然后原地挂机，等待根本不在电脑前的用户回复。
• 假装请示：列出一长串需要用户拍板的决策项，但按模型自己的说法，这些决策并不影响其继续干活。
• 汇报强迫症：模型觉得当前回合字数够多，或刚做完一个小阶段，非得停下来做个总结。

有意思的是，「沟通更主动、总结更清楚」恰恰是 Opus 5.5 官方宣传的核心卖点。这些「优等生」的好习惯，一旦放进旧的无人值守程序里，反而成了停工的诱因。

官方三招：把验收权从 AI 手里拿回来

第一招，任务清单。 把大任务拆成细项，交给待办工具或文本维护，让模型边做边勾选。回合结束时，若清单上还有未完成的任务、且模型未说明被什么卡住，应用就自动发一条消息点名让它续跑。官方示例：「你的任务清单还有未完成项：迁移剩下两个端点，并更新它们的测试。继续做。如果某项被卡住，说明卡在哪里。」

第二招，铁面验收员。 事先定好完成标准，每次回合结束交给一个更小的模型对照检查；不达标，就把原因作为下一条消息塞回去让它返工。

第三招，硬刹车。 同一任务若自动续跑两三次仍卡在原地，必须强制停下交人工复查，避免把 API 额度空转烧光。

此外，提示词也需要更新。官方给出了一段可直接套用的系统提示词，核心思路是「两头堵」：既要明说绝对不想要上述四种停法，也要说清何时才允许停止，例如离了用户真推不动，或碰到被刻意保护的核心资源。

从 Opus 5 到 5.5 的迁移陷阱

如果说干一半停工只是磨洋工，下面这些接口变动则会直接让程序崩溃。沿用给 Opus 5 写的请求、不改就发给新模型，会被直接拒绝并返回 400 错误，共有四处关键改动：

1. thinking 参数不能再关闭。若把 thinking 设为禁用，或手工指定思考预算，系统会直接拒绝请求。要么不传 thinking 字段，要么设为自适应模式，由 effort 参数控制思考深度。
2. tool_choice 不能再强制调用工具。把 tool_choice 设为任意或指定某个具体工具都会报 400。官方建议用自动模式，配合严格工具调用或结构化输出，并在提示词中说清何时用哪个工具。
3. thinking 块绑定了模型和上下文。2026 年 8 月 31 日之后创建的账户，中途修改系统提示词、工具或历史消息后再回放旧的 thinking 块，默认会直接报错；只追加、不改写的用法不受影响。
4. 旧版电脑操作工具下线。在 Claude API 和 Google Cloud 上需换用 computer_toolset_20260801；Amazon Bedrock 上旧的 computer_20251124 仍可继续使用。

对开发者而言，关键不是催促模型多干一点，而是把「任务是否真的完成」的判断权从模型手里收回到程序里——用可校验的清单和外部验收，替代模型自己写下的「我做完了」。

换句话说，”用 AI 会不会让人变笨”这个问题，暂时还没有盖棺定论的答案，但风险信号已经出现。Ghosh 的做法不是弃用工具，而是针对研究者归纳出的认知风险机制，设计了三套提示词，把被动接受答案的用法，改造成主动参与思考的用法。

一、把它当家教，而不是自动答题机

最常见的退化路径，是让 AI 直接替人写代码、写文章。Ghosh 的建议是反过来——让它帮人成为更好的程序员或写作者。遇到卡壳的概念时，明确告诉模型自己卡在哪一步，要求它给出有研究依据或成熟实践支撑的针对性指导。

他用自己的经历举例。在不懂原理的情况下，让 AI 一路”氛围编程”（vibe coding）生成脚本和小工具，让他很不踏实。这就像收到一封 AI 代写的邮件，看都不看就点发送——尤其是对没有编程背景的人来说，风险更明显。于是他决定真正学会写代码，把模型变成自己的私人导师。

具体做法是围绕个人的学习方式来搭建流程：他属于”做中学”而非”读中学”的类型，于是告诉模型想学什么，由模型生成一套以项目为核心的课程表、布置作业并全程担任导师。他完成练习、发送进度截图、卡住时提问。最关键的一条配置是：禁止模型直接给出答案，只能不断提示方向，直到他自己想明白为止。掌握一个概念后，再进入下一个。

二、定期审计自己”外包”了哪些思考

现在的主流大模型大多能够回溯此前的对话记录。Ghosh 由此想到一个反向用法：让模型充当审计员，把用户历次把思考外包给它的具体场景全部翻出来。审计结果相当于一张地图，清楚标出哪些”心智肌肉”已经停止锻炼——之后再有意识地决定，哪些值得保留。

他本人并不认为所有外包都是坏事，关键在于优先级。作为写作者，他日常工作包含大量流程性环节：重命名图片、添加标签、插入内链、调整排版。这些任务谈不上创造性，交出去并不心疼，何况相关规则本身就在频繁变动，学了也要反复重学。

但创造性工作不同。找到读者真正关心的话题、为一篇报道确定切入角度、搭建论证结构、打磨文字——这些能力他不愿意丢，因此即便对着空白文档写不出字，也拒绝让 AI 代劳。

以下是他用于追踪外包情况的提示词：

> 回顾我最近与你的对话，找出所有我把认知工作外包给你的情况： > – 我本可以自己读完却让你总结的内容 > – 我本可以自己写却让你写的内容 > – 我本可以自己推理却让你决定的事情 > – 我本可以自己形成却让你给出的观点 > > 把这些整理成一张三列表格：任务、该任务锻炼的底层能力、我委托给你的频率。 > 然后标出哪些能力在持续外包下可能会退化。 > 不要为了照顾我的情绪而弱化结论——我要的是诚实的审计，不是安慰。 > 最后反问我：这些能力里，哪些是我希望继续自己锻炼的，好让我们据此约定哪些事不该再交给你。

三、让它站到你的对立面

多数模型默认带有讨好倾向，而且随着记忆和上下文的积累，它们越来越擅长说用户爱听的话。就有争议的话题去问 ChatGPT 或 Claude，得到的回答往往与提问者本人的立场高度接近。

这会把人困在回音室里，也剥夺了用一个强有力的反方观点来检验自身信念的机会——而后者恰恰是磨砺思维最有效的方式之一。辩赢了，信念更牢固；辩输了，说明原本的立场经不起推敲。两种结果都是收获，唯独一台只会附和的答题机什么都给不了。

Ghosh 认为这个问题反而最好解决：探讨某个想法时，不要问 AI 怎么看，而是先亮出自己的观点，再指派它去扮演反方。聊天机器人本身极擅长角色扮演，能够真正代入持相反立场者的视角，展开一场只针对观点、不涉及人身攻击的理性辩论。

在他看来，这可能是 AI 最好的用途之一。现实生活中大多数人很难获得这种体验：与亲友避免争执，或者因为自认了解不够而选择沉默——却忘了每个人都是从知道得更少开始的。面对 AI，这些社交压力基本消失，提出外行问题、挑战自身假设都变得容易得多。

他使用的辩论提示词如下：

> 我想通过结构化辩论来探讨一个话题。 > 我的立场是：［填入你的立场］。 > 你的任务是为对立观点构建最强有力的论证——要用最强版本的反方论证，不要偷换成稻草人。 > 请使用该立场真正的支持者会用的最佳论据、证据与推理。 > 全程保持理性专业，但不要为了迎合我而软化论证，也不要因为我反驳就轻易让步。 > 如果我的反驳确有漏洞，请直接指出。每交锋几个回合后，简要总结双方目前的立场，以及哪些争点仍未解决。 > 任何时候都不要跳出角色来肯定我的立场。

Ghosh 特别提醒：应当把这段提示词保存为一个专门的自定义助手（例如 Claude 的项目、ChatGPT 的自定义 GPT 或 Gemini 的 Gem），取名”辩手”。不要在日常对话里直接粘贴，否则模型会误以为用户长期偏好这种风格，在需要协作的场景下也开始处处抬杠。

工具本身没有好坏

Ghosh 想强调的核心观点是：AI 既不是好东西也不是坏东西，它只是一件工具，而且是极其强大的一件。用得随意，它会缓慢侵蚀既有能力；用得刻意，它可以帮人建立新的能力。

他在原文末尾列出了九项支撑其判断的研究，涵盖生成式 AI 对高中数学学习的影响、结肠镜检查中医生因接触 AI 而产生的技能退化风险、大语言模型与网络搜索在学习深度上的对照实验、中学生阅读理解与记忆的随机实验、知识工作者自评认知投入下降的调查，以及生成式 AI 提升个体创造力却降低群体内容多样性等方向。

需要说明的是，这些研究观察到的多为短期效应或相关性，尚不足以对长期认知影响下定论。真正可靠的结论，恐怕还要等这批工具再运行若干年才能得出。

来源：How-To Geek，作者 Dibakar Ghosh，2026 年 8 月 1 日