GPT-6 Astra 升级了，你的 Codex 还在用旧规则？
需要直接复制？ 打开完整提示词与全量修改版，或下载教程和提示词 ZIP。页面提供单项目试用与全量正式修改两种完整用法。
GPT-6 Astra 发布后，Codex 用户值得先做一件事：重新检查自己的 AGENTS.md 和 Skills。
模型更能遵循指令，也会更认真地执行你留下的旧要求。过去为了催它读文档、跑测试、先问清楚而补上的规则，现在可能带来多余的步骤，甚至让任务提前停住。
以前帮你管住 AI 的规则，现在可能限制了新模型的发挥。
OpenAI 的官方指南明确建议检查模型可读取的 Skills、AGENTS.md 等指令文件。Eric Provencher 也专门写了《Rethinking skills and prompts for GPT-6 Astra》，拆解哪些要求应该重新审视，以及怎样调整 Skills、AGENTS.md 和任务提示。OpenAI 指南 · Eric 原文
下面用一个例子贯穿讲解：假设你已经装了一份叫 article-writer 的 Skill，负责公众号文章的起草、检查和发布。 它把“先问清需求、读取素材、写正文、检查封面、准备发布”写成一套固定流程。现在你只让 Codex 改一个标题，它却又开始提问、读整套资料，甚至检查起了封面。
接下来，我们就整理这份现有 Skill，以及影响它的 AGENTS.md：起草时读写作要求，检查时读相关清单，已经要求发布时再进入发布流程；只改标题，就完成这次标题修改。
前半篇使用这个假设例子解释方法，后半篇展示我实际运行后的产物和删减数据。完整提示词也会一起给出，方便你处理自己的项目。
01｜先分清：全局、项目、Skills 与运行记录，各放一层
AGENTS.md 是给 AI 的工作约定；Skill 是某一类任务的专门说明。在这个例子里，项目 AGENTS.md 可以告诉 Codex 本项目的文章素材放在哪里，article-writer 则说明怎样起草、检查和发布文章。
全局 AGENTS.md，在 Codex 界面里对应哪里？ 打开桌面端的“设置 → 个性化”，找到 Codex 说明（自定义指令）。这个区域编辑的是个人级 AGENTS.md，默认文件位置是 ~/.codex/AGENTS.md，用于跨项目的习惯和约定。官方设置说明 · 全局 AGENTS.md 说明
项目 AGENTS.md 则放在具体项目文件夹中。例如，一份公众号项目的 AGENTS.md 可以记录这批文章的素材目录和专有用词。这些项目事实无需都填进“个性化”。
整理之前，先把信息放对位置。
| 信息 | 更适合放在哪里 | 例子 |
|---|---|---|
| 多个项目都适用的沟通习惯、协作约定 | 全局 AGENTS.md；在界面中通过“设置 → 个性化”里的“Codex 说明”编辑 | 默认中文回答；专业词要解释并举例 |
| 当前项目的事实、特殊操作、限制和资料位置 | 当前项目或相关子目录的 AGENTS.md | 这个公众号项目的素材目录、专有用词 |
| 某一类任务才需要的方法或工具用法 | 对应 Skill 的 SKILL.md |
article-writer 如何根据任务选择写作、检查或发布流程 |
| 很长的步骤、例子、参考资料 | Skill 的 references，用于存放按需读取的资料 |
references/drafting.md 存写作要求；references/publishing.md 存发布步骤 |
| 可以反复自动完成的固定操作 | Skill 的 scripts，用于存放可执行脚本 |
scripts/check_cover.py 自动检查封面图片尺寸 |
| 本次目标、输入、交付要求和完成条件 | 你在当前 Codex 对话里发送的任务提示词 | 把两份资料合成一篇面向新手的文章，核对并保存 |
| 已确认的决定、原因、进度和待办 | 项目工作记录或交接文件 | 已采用哪版标题、为什么采用、下一步补什么 |
这样，长期规则负责反复需要的约定，具体资料在用到时再读，今天的进度也有单独的位置。
沿用文章 Skill 的例子，这三句话可以分别这样放：
- “默认用中文回答”：写进全局 AGENTS.md，也就是“个性化”里的“Codex 说明”，以后换项目也能沿用。
- “本次文章面向新手”：直接写在这次 Codex 对话的任务消息中，例如“请根据这两份资料写一篇文章，读者是第一次使用 Codex 的人”。
- “发布前检查封面尺寸”：写进
article-writer的references/publishing.md，让 Codex 准备发布时读取。
这里的“当前任务”，指你在当前 Codex 对话（session）里交代的这次工作。对话是你持续沟通的位置；“这次文章面向谁、交付什么”，是你在其中写下的具体要求。
“发布说明”在这个例子中就是 references/publishing.md，是一份供 AI 阅读的 Markdown 文件，里面可以写“检查封面尺寸、确认摘要、核对发布账号”等步骤。如果已经有程序能自动检查图片尺寸，这段可执行代码才放在 scripts/check_cover.py，再由发布说明指向它。上面的文件名是结构示例，实际使用时应核对相应文件确实存在。
这样，只改正文中的一句话时，就不必读取整份发布说明或运行封面检查程序。
同一条重要规则，尽量只维护一份正文，其他入口指向它。否则，一处已经更新，另一处还留着旧要求，AI 就可能读到两套说法。
如果项目已经使用多个 AI 助手，它们各自负责什么，可以放在相应的助手配置中。容易变化的模型设置、当前进度，也不必永久写在全局规则里。
最后，让 Codex 核对实际使用的是哪些文件。电脑上存在一个文件、本次读过一次、以后会自动采用，是三种不同情况，不能混为一谈。
02｜Skills：先改入口，再改正文
这里的“入口”指 Skill 的 name 和 description。在我们的例子里，name 就是 article-writer；description 则要写清什么时候需要它，例如起草完整文章，或明确要求执行文章检查、发布流程时。
AI 先根据这些信息选择 Skill，再阅读 SKILL.md 中的方法和步骤。SKILL.md 是每个 Skill 的核心说明文件，例如它可以写明一篇文章需要哪些输入、交付什么结果。
先解决选得对不对，再解决选中之后怎么做。
它到底提供了什么额外帮助？
先看这份 Skill 是否提供了模型无法自行得知的内容：专门工具的用法、项目特殊要求、稳定的输出格式，或者经过实际使用检验的方法。
例如，“默认把资料保存到指定目录”有明确作用；“认真思考、努力完成”如果没有补充任何信息，就可以考虑缩短。
不要因为一份说明以前给旧模型用过，就认定它现在完全无效。要看它是否仍然解决你的实际问题。
只改标题，为什么也会启动整套写作流程？
先检查 description 是不是写得太宽。
description 应当把“什么时候使用”说准确。安装的 Skills 很多、description 又很长时，Codex 还可能缩短模型能看到的内容，反而让它难以选准。
可以这样改：
原来的 description |
改写后的 description |
|---|---|
| 所有写作任务都使用，开始前先访谈用户 | 起草完整公众号文章，或明确要求执行文章专项检查、发布流程时使用；仅改标题或错字时不用 |
长背景、完整步骤和能力介绍，放进 SKILL.md 正文或 references。例如，“起草所需信息不足时补充询问”可以写在写作分支中，不必让每种任务都先进入访谈。description 先回答清楚：什么时候需要我？
改完后，用“从零写一篇文章”和“只改一个标题”分别试一次，看看 AI 是否真的选对。只把 description 写短，还不足以说明问题已经解决。
几份 Skill 会不会同时要求“先用我”？
把相关 Skills 的 description 放到一起看。
一份要求所有任务先规划，另一份要求所有任务先访谈，还有一份要求改完必须再启动另一轮检查。叠加起来，小任务也可能被拉成长流程。
应让它们各自负责清楚的事情。例如，写完整文章和检查引用是两项不同工作；一项任务可能需要两者，但不用每次都把两套方法全部启动。
SKILL.md 中的要求也要一起核对。不能只把 description 里的“必须”改成“建议”，正文仍然保留一整串互相冲突的步骤。
这套方法，能不能只在需要时使用？
对于步骤太多的 Skill，可以选择三种处理方式：
- 缩小适用范围。例如，只有从零写文章且信息不足时才提问，改标题时不用。
- 保留方法，但只在你点名要求时使用。例如，你说“先采访我，了解写作需求”时，才进入访谈。
- 如果它持续打断工作，也没有值得保留的内容，就先不用这套说明。
方法的使用方式可以改变，不需要把写作、检查、调试等能力一并放弃。
还要检查有没有附带操作。例如，检查文章前要求配置其他工具，或文章写完后自动发布。这些都要依据当前任务判断，不能因为某份说明把它们连在一起，就默认每次都做。
暂停使用是否真正实现，也要按工具支持的方式核对。只改 name 或文件名，不能直接宣布它已经不再被使用。
SKILL.md 能不能先指路，详细步骤需要时再读？
我们的 article-writer 包含写作、检查、发布三种工作，可以在 SKILL.md 中先对应到具体文件：
| 用户这次要求做什么 | SKILL.md 指向哪里 |
|---|---|
| 从零起草完整文章 | references/drafting.md，存放写作要求 |
| 专门检查文章的事实、引用或格式 | references/reviewing.md，存放对应检查清单 |
| 已明确要求发布文章 | references/publishing.md，存放发布步骤和相关操作要求 |
这样，AI 当前只写正文，就不用先把所有发布步骤读一遍。
长步骤和参考资料放在 references，需要自动执行的操作可以放在 scripts。例如，发布说明可以在需要检查封面时调用 scripts/check_cover.py；检查清单可以在需要核对链接时调用 scripts/check_links.py。这些仍是结构示例，实际引用的文件必须存在。小而单一的 Skill 可以继续放在一个文件里，不必为了整理而拆出一堆空目录。
为什么 SKILL.md 改了，AI 还是照旧执行？
因为旧要求可能还在 references 或 scripts 里。
例如，你从 SKILL.md 删掉了“每次检查整个项目”，但它仍让 AI 读取 references 中的检查清单。清单里留着同样的话，AI 读完后，还是会照做。
所以，要沿着 SKILL.md 的引用检查 references 和 scripts，看 AI 会继续读什么、执行什么。移动文件后，核对路径正确、文件可用，里面的要求也已经同步调整。
哪些先后顺序必须保留，哪些可以放开？
先取得完整资料，再比较异同，这种先后关系必须保留。没有原文，就谈不上准确比较。
但“无论做什么，都先问十个问题，再写计划，再等一次确认”，就需要检查是否每次都必要。
可以把固定步骤改成具体条件：缺少会影响结果的信息时才提问；资料齐全、目标清楚时，就选择合适的方法继续完成。
如果同一套 Skills 还供同事或不同模型使用，要保留他们共同需要的要求。例如，发布时使用哪个账号、图片存放在哪里，不能因为换了模型就删掉。
skill-creator 是什么，它自己更新了吗？
Codex 确实有 OpenAI 随产品提供的系统内置 skill-creator。它的用途是帮助创建或修改 Skill：把你想完成的工作整理成合适的 name、description、SKILL.md，再按实际需要组织补充资料或脚本。可以在 Codex 中用 $skill-creator 调用它。官方 Skill 创建说明
例如，你可以说：
请使用 Codex 系统内置的 skill-creator，整理现有的 article-writer。保留写作、检查和发布的方法，让它按本次任务读取对应资料；只改标题时不进入整套流程。请先核对实际使用的 skill-creator 来自哪里。
之所以要确认来源，是因为同名 Skill 可能来自不同地方。系统内置版本与自行安装的版本，不能只看 name 就当成同一份。
官方指导有过更新。 Eric 在这篇介绍 GPT-6 Astra 的文章中明确提到，他们近期更新了 skill-creator 的指导，重点包括更短且准确的 description、按需读取资料，以及减少不必要的固定步骤。Eric 原文的 Skill files 部分
本次全量整理使用了系统版的检查脚本，没有修改 skill-creator 本身。 下文统计的是实际改写或迁移的私有 Skills。使用工具生成或调整文件之后，仍要检查 description 是否准确、步骤是否适量、references 和 scripts 是否有效。
03｜AGENTS.md：留下长期有用的要求，改掉过宽的规定
Skills 解决专项任务怎么做，AGENTS.md 则会持续影响它适用范围内的工作。
逐条检查时，可以采用四种处理方式：
| 处理 | 适用情况 | 例子 |
|---|---|---|
| 保留 | AI 无法猜出的事实、明确习惯和真实边界 | 素材目录、默认中文、不要覆盖已有修改 |
| 删除 | 已过时，或没有额外作用的重复提醒 | 失效路径、已经不再使用的旧流程 |
| 改写 | 本意有用，但范围太宽或容易误解 | 把“每次读所有资料”改成按任务查对应文件 |
| 移动 | 只在特定项目或任务中需要 | 把发布清单移到发布说明，把进度移到工作记录 |
对于要移动的内容，先安排好真实可用的新位置。没有反复使用价值的旧案例，也不必全部换个地方继续堆着。
具体修改时，重点看下面几件事。
文档从“每次全读”改成“需要时查”。
核对价格时查价格表，修改程序的数据结构时查对应说明，准备发布时查发布清单。让 AI 根据任务补充阅读其他必要资料，不必用规则强制它每次全读。
入口本身也要更新。文件是否存在，操作方式是否变化，都要核对。程序项目还可以对照当前安装配置、实际脚本及自动检查设置，确认旧说明里的命令仍然适用。
检查写清楚“查什么”，也写清楚“什么时候够了”。
改标题，核对文字和保存结果即可；修复程序问题，就需要检查原来的问题是否解决、相关功能是否受影响。
项目必做检查仍然保留。检查通过以后，只有新改动、新失败或尚未解决的具体疑点，才扩大或重复检查。同一份内容和同一环境下，已有的有效结果可以复用；相关状态变化后，再重查受影响部分。
把可以连续完成的工作说清楚。
如果已经交代“整理资料、写成文章、核对并保存”，就应把这些做到结束，不默认在第一稿后停下来。
程序项目也可以写明具体情况：本地检查只使用临时数据、不连接正式服务时，在已经授权的修复范围内，可以连续检查、修复本次引起的问题、再检查，无需每一步重新询问。
涉及其他范围的操作，仍然按实际授权处理。例如，完成本地文章，并不自动包含对外发布。
你自己的稳定习惯，可以留下。
“默认用中文回答”“必须使用专业词时先解释并举例”，都可以是长期约定。
有人希望直接拿结果，有人希望顺便理解关键思路。让规则服务你的使用习惯，不必为了减少几行，把这些也删掉。
如果需要整理结构，可以按六方面组织。
沟通习惯、要求的适用关系、执行方式、检查方式、工具与协作、正式资料位置。内容少时合并写即可，不强制凑齐六个标题。
其中，要求之间如何协调，应遵循工具和平台的实际规则；并行工作，也就是让多个助手同时处理任务，只适合真正独立的工作。例如，可以分别阅读两份材料，但同一篇最终稿应统一改写，避免互相覆盖。
如果某条规则导致任务停住，让 AI 说明具体是哪份文件、哪句话，以及它为什么认为必须停。这样才知道要修正的是规则，还是它对规则的理解。
本次任务的完成标准则放在当前提示词里。例如：
把这两份资料整理成一篇面向新手的文章，核对事实与链接，保存到指定目录。交付文章及仍未核实的问题，完成后结束，不自行发布。
04｜这八类 Skills，值得重点检查
不需要因为模型升级就把所有 Skills 重做。先看以下类别里，是否存在对应问题。
| 类型 | 重点检查什么 | 调整方向 |
|---|---|---|
| 网页与电脑操作 | 是否大量重复模型已经能完成的基础操作；是否遗漏账号与环境要求 | 减少无用步骤，保留账号、专用浏览器环境、工具参数和下载位置 |
| 程序检查 | 是否只有通用提醒，缺少项目实际会犯的错误 | 保留特殊约定和真实错误案例，用已知有问题的例子检查效果 |
| 长文档处理 | 分段是为了容量，还是为了读齐资料和定位出处 | 容量条件变化后重新判断；图片文字、附件、视频文字稿仍要取得完整 |
| 数据分析 | 是否限制了有价值的复杂任务，或缺少计算口径 | 按实际需要扩展，保留单位、口径与核对方法，用已知答案检查 |
| 多步骤任务 | 是否把普通操作顺序写得过死 | 保留必须先完成的业务条件，让 AI 选择适合本次任务的做法 |
| 操作安全 | 是否没说清能读、能记、能改什么，或给所有小事加长流程 | 针对真实缺口补规则，区分临时数据、真实业务和对外操作 |
| 常用提示词 | 是否堆了很多催促，却没说交付什么 | 保留目标、资料、工具范围、交付物和完成标准，删除重复表达 |
| 跨对话记忆 | 是否每次都要重讲，或把所有聊天都塞进长期说明 | 用简短交接记录保留已确认决定、依据和待办；个人偏好按意愿保存 |
比如，AI 一次能处理更长的文字，也不意味着扫描图片里的字已经识别出来。会操作网页，也不意味着知道应该登录哪个账号。
再比如，多步骤方法是否需要固定顺序，可以用同一项任务比较。保留能够提高质量的条件，不凭模型升级就认定“步骤越多越好”或“全部删掉更好”。
这些类别提供的是检查方向。当前项目没有的类别，可以跳过。
05｜改完，用三个任务看实际变化
第一，给一个应该使用某个 Skill 的任务，再给一个相近但不需要它的任务。例如，从零写文章和只改标题，看看是否区别处理。
第二，做一个小改动。看看是否减少了无关阅读、没有必要的提问和重复检查。
第三，给一个有明确交付要求的完整任务。看看它是否真的完成文件生成与核对，同时保留中文回答、资料位置和已有改动保护等重要约定。
先保持同一模型和同一套设置，便于比较。文件短了多少可以记录，任务是否完成得更好才是判断依据。
新版文件还需要按工具支持的方式启用。单独生成一份 AGENTS.candidate.md，也就是一份供试用的候选文件，不会仅因为这个名字就自动生效。如果无法验证实际启用后的表现，应明确写“文件已生成，行为尚未验证”。
06｜复制这份完整提示词，让 Codex 开始整理
在 Codex 中打开要整理的项目，复制下面整段。项目范围和交付位置可以填写；留空时，按提示词中的默认方式处理。
它会依次盘点和分类，整理 Skills，再整理 AGENTS.md，补查八类用途，完成必要检查并交付可用文件。已有明确修改授权的，按授权实施；其他部分生成独立新版。
这是本次整理任务的完整说明，长度是为了覆盖检查项。整理后的长期规则只保留反复需要的内容，不要把这整段再放回 AGENTS.md。
请帮我整理当前项目适用的 AGENTS.md 和 Skills，使 AI 更容易选对方法、读到相关资料，并把已经交代的工作完成。
AGENTS.md 是给 AI 的工作约定，例如素材位置和回答语言；Skill 是某一类任务的专门说明，例如写文章或检查表格的方法。Skill 的 `name` 是标识，例如 `article-writer`；`description` 写清何时使用，例如“从零起草完整文章时使用”。
我不追求固定行数、删减比例或停用数量。需要保留真正有用的信息，改掉重复、过时、冲突和让简单任务变复杂的要求。
【项目范围】未填写时，使用当前打开的项目。先核对实际目录，不搜索整个电脑来猜测我要处理的项目。
【交付位置】未填写时，在当前项目下新建一个不覆盖已有内容的“规则整理结果”目录。
【处理方式】默认在交付目录生成完整、可使用的新版。如果我已经明确授权修改某些正式文件，则按已有授权处理那些文件，保留可恢复的原版，并保护原有未完成改动。其他文件仍输出独立新版或明确建议。
【常用任务】优先从当前项目和我已经提供的信息中识别，不清楚的部分注明；不要要求我先填写一份冗长问卷。
以下是完整任务要求，可以直接开始，不需要另找文章来补足步骤。
一、先找到真正相关的规则
1. 检查当前工具提供的实际采用规则的信息，列出适用的全局说明、项目及子目录的 AGENTS.md、已安装 Skills 的 `name` 和 `description`，以及相关的 `SKILL.md`、`references`、`scripts` 和其他被引用文件。`SKILL.md` 存放核心要求；`references` 存放按需读取的资料，例如发布清单；`scripts` 存放可执行脚本，例如链接检查程序。全局说明是多个项目共用的要求，例如默认回答语言；项目说明只管当前项目，例如这篇文章的素材目录。
2. 区分“文件存在”“本次主动读过”“工具确实把它作为指令使用”三种情况。有证据才写已生效；工具不提供证据就写无法确认，不要靠文件名猜。
3. 检查是否有多个重复入口，以及类似快捷方式、实际指向另一处文件的链接。找到真正维护正文的位置，避免改错副本。遵守本机现有存放约定，不修改系统内置文件，不把同一份私有 Skill 复制到多个安装目录。
4. 先看 Skills 的 `name` 和 `description`，再深入检查与本次任务有关、`description` 重叠或存在问题的内容。不需要把所有无关资料一次读完。若范围较大，可分批处理，并列明已检查、尚未检查和无法读取的部分。
5. 如果现有环境有多个 AI 助手、独立的助手配置或交接说明，一并确认它们和规则文件的关系。没有这些配置就跳过，不为了整理规则新搭一套系统。
二、逐条判断，留下处理依据
对范围内的规则分别标记“保留、删除、改写、移动、暂不确定”，注明原文件、位置、原句、影响、建议和新去向。没有问题的内容可以合并说明，值得修改的问题按实际影响排序。
判断时区分这些情况：多个项目都需要的稳定约定；重复内容；已经过时的要求；仅当前项目需要的信息；只适合某个模型的指导；本应放到助手配置里的职责；已经有另一份正式文档维护的流程；暂时无法判断的内容。
保留 AI 无法猜出的事实，例如真正的素材位置、需要使用的账号、特殊命令、业务口径、我的语言与解释偏好、不能覆盖的已有改动和实际授权范围。当前聊天里出现了同一句话，不足以证明以后新对话可以删掉那条长期规则。保留账号和凭据的使用要求，但不要把密码、登录凭据等秘密原文写进规则文件。
没有反复使用价值的旧案例可以删除，不必为每段删除内容另建一个文件。需要移动的内容，先安排真实可用的新位置并检查引用，再从原处移走。重要规则尽量只维护一份正文，其他入口指向它。
三、整理 Skills：先改入口，再改正文
1. 说明每个相关 Skill 提供什么额外价值：专门工具的用法、项目特殊知识、必须遵守的业务要求、经过验证的方法或稳定输出格式。没有额外信息的通用提醒可以减少。不能仅因它为旧模型编写，就判定整套方法无效。
2. 检查 `name` 和 `description`。`description` 要短且准确，例如“从零起草完整公众号文章时使用”，不堆长步骤和能力宣传。大量过长的 `description` 可能影响模型看到的信息；只在有证据时说明具体截断情况，不虚构容量数字。
3. 改掉适用范围过宽的 `description`。例如，将“所有写作任务都先访谈”改为“从零写完整文章且关键信息不足时先访谈”；必要时补一句“只改标题或错字时不用”。不要为每个 Skill 堆一长串无关排除条件。
4. 把相关 Skills 放在一起检查：是否都要求先使用自己，是否重复问问题，是否一份要求继续、另一份要求停下。将 `name`、`description` 和 `SKILL.md` 中的要求一起核对和调整，不能只换一句措辞却保留后面的冲突步骤。
5. 将处理方式具体分为：保留原用法；只在更合适的任务中自动使用；只在我点名要求时使用；暂停使用；合并或删除无价值的重复内容。解释每项选择，并使用当前工具真实支持的方式实现。仅修改 `name` 或文件名、把文件留在原目录或写一句“不再使用”，不能直接宣称已经停用成功。同组多份说明若通过相同流程自动参与任务、共同造成冲突，可以按一组调整其使用方式；不必先证明每份文件都没有价值。
6. 检查是否多做了我没有要求的事，例如：简单修改前固定访谈；普通检查前配置额外工具；强制替换项目惯用词；做完后自动记录版本、提交全部已有改动或发布。Git 是记录代码版本的工具，记录一个版本也不等于发布到网站。按实际任务和授权处理这些步骤，不把它们自动连在所有工作后面。
7. 有价值的专门方法可以保留为点名使用。例如，TDD 是先写检查程序、再写功能的方法；若它不适合每次小改动，可在用户明确要求时使用。独立审查和调试也按任务需要决定，不因为停用一套自动流程就丢掉所有有效方法。
8. 一个 Skill 包含多种任务时，在 `SKILL.md` 中先说明“做什么任务去读哪份资料”，详细步骤再按需读取。例如，写正文时读 `references/drafting.md`，准备发布时才读 `references/publishing.md`；这些只是路径示例，实际引用必须存在。单一小 Skill 不必强行拆成多个文件。
9. 同步检查 `references` 和 `scripts`。`SKILL.md` 删掉的要求若仍在这些文件中，问题可能继续存在。核对所需文件是否可读、路径是否正确、步骤是否仍适用；发现缺失或过时内容如实列出。
10. 保留真实的业务先后关系，放宽无必要的固定操作顺序。例如，先取得完整原文才能比较资料，是必要条件；必须提十个问题、固定调用五个工具，不应在所有任务中强制执行。
11. 如果这套 Skills 确实由不同人、不同模型共用，保留共同需要的业务事实，必要时区分模型相关指导。不要把只在一个模型上成立的删减结论直接套给所有使用者。
12. 若使用 `skill-creator` 等工具，先核对实际来源和当前指导；在 Codex 中优先使用当前可用的系统内置版本，不将同名私有版本直接视为同一份，也不修改系统内置 Skill 本身。`skill-creator` 用于创建或调整 Skill，例如帮助生成 `SKILL.md`。检查生成结果是否仍有 `description` 太宽、步骤过多、文件引用失效等问题。不要因为是工具生成的就默认正确，也不因缺少辅助生成工具而停止能够完成的改写。
四、重写 AGENTS.md：把长期要求写清楚
1. 按实际需要组织沟通习惯、要求之间的适用关系、执行方式、检查方式、工具与协作、正式资料位置。小文件可以合并表达，不强制六个标题。稳定通用习惯放全局；项目事实放项目；专项长流程放对应 Skill 或资料；历史决定、进度与交接信息放工作记录。
2. 删改没有具体作用的口号和过时补丁。例如，“认真思考、遵守最佳实践”若没有额外信息，可以缩短；特殊业务约束不能一并删掉。不把容易变化的模型名称、运行状态写成永久事实。
3. 把“每次都先读所有文档”改成按任务读取。例如，改产品价格时查价格表，准备发布时查发布清单，改一个错字不强制先读全项目。核对被指向的文件是否存在、内容是否仍适用。
4. 程序项目还要核对安装、检查和运行命令。依据当前配置、实际可用脚本、记录依赖版本的文件及自动检查配置交叉确认。例如，旧说明中的安装命令，应与项目现在采用的安装工具一致。不要仅因旧文件写了某条命令就照做。
5. 保留项目必做检查，检查范围与本次变化相称。改标题可以核对文字和保存结果；修复程序行为需要检查问题是否解决及相关功能是否受影响。不要只为重复证明显而易见的实现而新增测试。
6. 必要检查通过后，只有新改动、新失败或未解决的具体疑点，才扩大或重复检查。同一代码、输入和环境状态下的有效结果可以复用；相关状态变化后重查受影响部分。调试先确认现象，必要时用能重现问题的最小例子查原因，不凭猜测扩大修改。
7. 在环境前提真实成立时，写清可以连续做的工作。例如，本地检查只使用临时测试数据、不连接正式服务时，可以在既有修复授权内运行检查、修复本次引起的问题、再查受影响部分，无需每一步重新询问。
8. 保留系统和平台约束，按当前工具的实际机制处理用户要求、项目说明和 Skill 的关系。Skill 中的默认流程不能自行增加本次授权，也不应把已经授权的工作无故停住。涉及权限变化的改写单列说明。
9. 沟通面向我的理解程度：先用日常语言解释；标准字段名、文件名和工具名保留原文，例如 `name`、`description`、`SKILL.md`、`references`、`scripts`，不要用中文称呼替换；首次出现时解释用途并给例子。已熟悉的基础知识不反复讲。明确偏好可以保留短句，不为追求更短而删除。
五、再按八类用途查缺补漏
只检查当前实际存在、与任务相关的类别；缺少某类不代表必须安装。以下是检查方向，不是预先决定全部删除或新增。
1. 网页与电脑操作：能否减少重复的点击说明，同时保留账号、独立浏览器环境、工具参数和下载位置？例如，AI 会打开网页，也不代表知道应该登录哪个账号。
2. 代码检查：减少通用口号，保留项目特殊要求和真实错误案例。需要判断效果时，用包含已知问题的小样例检查能否发现它。
3. 长文档：区分“因为一次装不下而分段”和“为了读齐、定位出处而分段”。一次能读更多文字，不代表图片、附件和被工具截掉的内容已经取得。扫描图片需要识别其中的文字；视频需要逐句记录的文字稿。资料未取得不能声称读完。
4. 数据分析：保留计算口径、单位和输出格式；确有需要时扩展更复杂的计算。用已知答案或独立计算检查结果，不凭未经核验的模型分数增加承诺。
5. 多步骤工作：保留必须先完成的业务条件及质量要求，普通实现顺序按任务选择。对有争议的固定流程，可用同一任务比较，不预设步骤越多越好或越少越好。
6. 操作安全：检查读取、记忆和实际行动的范围是否清楚，针对真实缺口补规则。区分本地临时数据与真实业务数据，不为所有低影响任务增加同一套冗长审查。
7. 提示词模板：删重复催促，保留目标、已有资料、可用工具、交付物、完成条件和停止范围。不要要求必须减半。
8. 跨对话衔接：优先利用已有工作记录保存已确认的决定、依据、待办和何时需要重新核对。例如，记录选择了哪份稿件、原因和下一步，而不是抄全部聊天。个人偏好若要存入跨任务使用的长期记忆，应按用户实际授权办理；没有必要就不新增记忆系统。
六、让任务做到约定结果，合理使用工具
1. 为常用任务给出简短模板，包含：目标、已有资料、可用工具和操作范围、实际交付物、怎样检查、完成后在哪里停。例如，“把两份资料整理成一篇面向新手的文章，核对事实并保存到指定位置，交付后结束，不自行发布”。
2. 已授权工作持续到目标完成、必要检查结束或遇到真实阻塞。不要默认在第一次写完后停住，也不要在目标完成后凭空增加后续任务。用户中途补充、纠正或询问进度时，回应后继续原任务，除非用户明确取消或替换目标。
3. 只对会实质改变结果、范围或授权的缺失信息提问，能独立做的部分继续。如果规则导致停顿，给出具体文件位置和原句，解释它是明确要求还是你的理解，不笼统说“按规定必须确认”。
4. 工具选择以当前可用能力为准，优先适合目标的专用工具；互不等待对方结果的读取和查询可以批量执行，不把共享状态操作强行同时进行。
5. 如果现有工具支持且用户授权允许使用多个 AI 助手，只把真正独立的工作交出去。例如，两份互不依赖的材料可以分别阅读；同一份稿件的最终改写由一个助手统一处理。交代输入、输出、读写范围和完成标准，汇总后核对，不让多个助手同时改同一文件。没有这项能力就由当前助手完成。
6. 本次整理保持当前有效的模型和思考档位，方便判断规则修改的效果。思考档位是工具允许模型投入多少推理的设置，例如日常小任务和复杂分析可能适合不同档位。只有用户要求另行比较或迁移模型时，再核对工具当前支持的选择，不把统一调低当成整理规则的必做项。
七、用少量真实任务检查，而不只比较字数
先检查新文件格式、所需引用、冲突及内容是否完整。再选择与实际改动有关的代表任务，不为没有变化或不适用的项目强行增加检查。
至少为以下三类行为给出适用检查，并在具备真实启用条件和授权时执行：
- 应该用某个 Skill 的任务能选中它；相近但不需要的任务不会误用。例如，从零写文章和只改一个标题应区别处理。
- 一个小改动不会读大量无关资料、额外找多个助手或反复扩大检查。
- 一个明确交付任务能继续到文件生成、结果核对完成；关键个人偏好和项目规则仍被遵守。
有条件时再检查：已授权任务是否重复询问；适合并行的只读任务能否正常分工；是否避免同时改同一文件；是否仍读取正确的项目和工作说明；未授权的发布、删除、真实业务修改是否保留边界。边界检查采用不会产生真实破坏或外部发布的方式。
运行对比前，先确认工具真正支持怎样临时使用新版，保留原版与恢复方式。名为 AGENTS.candidate.md 的候选文件不会仅因这个名字就自动成为正式规则；模型按要求读一次，也不能直接证明以后会自动生效。如果临时替换配置测试，结束后恢复并核对；如果已经授权正式采用，保留恢复副本并核验实际启用状态。
比较时尽量使用相同任务、资料、模型和思考档位。优先看交付质量、误用方法、无关读取和不必要停顿，再记录行数或字数变化。工具不提供用量或内部助手的真实运行信息时，写“无法取得该证据”，必要时标记 NOT_EXPOSED；不要猜。没有多助手功能就跳过相关项，不临时搭建复杂配置。
如果不能验证真实启用后的行为，交付完整新版和准确的手动试用步骤，并明确“文件已生成，行为尚未验证”，不要用模拟结果冒充实际效果。
八、交付可使用的文件及简短说明
请连续完成：盘点、改写、生成文件、必要检查和交付，不在每个小阶段重复等待确认。
最终给我：
1. 完整的新版 AGENTS.md，以及确实需要调整的 `SKILL.md`、`references` 或 `scripts`。保持它们之间的引用可用；文件名冲突时另建位置，不覆盖无关内容。不只提供摘要或建议清单。
2. 一份变化表：原文件与位置、旧规则、处理方式、新表达或去向、理由、预期影响。会改变操作权限的项目单列，无法判断的项目说明缺什么证据。
3. 一份检查记录：实际做了什么、结果如何、哪些没有执行或无法验证。根据结果说明可以试用、还要修改、宜保留原版或当前无法验证；没有足够证据不宣称提效或没有退化。
4. 一份新手使用说明：文件在哪里、如何按当前工具的真实方式启用、怎样确认启用、如何恢复。独立新版生成完不等于已经安装或生效。
5. 一个适合当前项目的任务提示示例，写清目标、输入、范围、交付和完成标准。
遇到打不开的文件、失效位置、缺少工具、读取被截断或规则冲突，说明卡在哪里、影响了哪部分、尝试过什么，以及继续所需的最少信息；其他可以完成的部分继续。
这是一项有范围的整理任务，不因发现其他可改善事项就无限扩展。完成后，以后只针对真实出现的问题补充必要规则，并安排能判断该问题是否解决的检查，避免把文件重新堆满通用提醒。
07｜我用这套方法，整理了自己的全部 19 个项目
我按照这套方法，对自己全部 19 个项目中的 AGENTS.md 和 Skills 进行了整理和修改。
这次处理覆盖项目规则、Skills 的入口与正文、参考资料、辅助脚本，以及文件之间的引用关系。需要调整的文件已经更新到正式位置，有效的内容继续保留。
| 处理范围 | 实际结果 |
|---|---|
| 项目检查 | 19 个项目都有处理结论，需要改的修改，仍然有效的保留 |
| AGENTS.md | 修改 13 份项目或子目录规则 |
| Skills 主说明 | 改写 11 份已有 SKILL.md，另整理并迁入 1 份 Skill |
| 补充资料 | 新增 6 份参考文件，用来承接详细方法、阶段记录及缺失资料 |
| 正式文件应用 | 共 49 个文件：24 个原位置改写、6 个参考新增、19 个随 Skill 包迁移 |
| 文件夹链接 | 修复或建立 3 处链接，让项目入口指向实际维护的 Skill 目录 |
其中一份 Skill 连同参考资料、模板和脚本，共 19 个文件，移到了统一维护的目录。原来的入口指向新位置，避免同一份方法在多个地方各改一版。
打开结果文件夹，可以按下面的顺序查看。这里列的是实际产物名称，你收到的文件名可能不同。
| 产物示例 | 里面有什么 | 什么时候看 |
|---|---|---|
README.md |
本次范围、完成状态和其他文件入口 | 第一个打开 |
项目结果.md |
19 个项目分别改了什么、保留了什么 | 核对是否覆盖要求的范围 |
变化表.md |
主要修改、理由、内容去向及操作范围的变化 | 判断改动是否符合使用习惯 |
检查与恢复.md |
实际检查、未通过的项目、尚未验证的行为和恢复步骤 | 判断结果能证明什么，以及如何恢复 |
application-manifest.json |
实际应用的文件、正式位置、对应备份和内容核对记录 | 追查某份文件是否已替换、应恢复哪一版 |
applied-backups/ |
修改前的文件及迁移前的完整 Skill 包 | 需要比较原文或恢复时查看 |
逐条去向.md、逐条去向.json |
原句、原位置、改写结果和理由 | 对具体删改有疑问时查看 |
行数与字节.json |
原始行数与文件大小记录 | 查原始统计；本文的字符数另按备份和实际改写文件重新计算 |
第一次查看，先读 README.md 和 项目结果.md，再读 变化表.md 与 检查与恢复.md。需要查某个文件的实际位置和备份时，打开 application-manifest.json；需要追查某句话时，再读 逐条去向.md。
08｜看结果时，重点核对这四件事
第一，整理的范围是不是你要求的范围。
“检查了多少项目”“修改了多少文件”和“安装了多少个文件”，是不同的数量。这次检查了 19 个项目，没有要求每个项目都必须删掉一些内容。
已经有效的规则可以保留，没有本地规则的项目也不必硬加通用说明。多个项目共用的 Skill 按实际维护位置处理一次，历史备份和示例文件与正式使用的规则分开记录。
如果你要求检查全部项目，就让 Codex 先列出项目清单，再逐项写明处理结果。发现了某份文件，不等于已经读完并检查了其中的内容。
第二，它删掉的是什么，留下的是什么。
这次有一份 Skill，原来的 SKILL.md 有 498 行，新版是 27 行。重复内容合并后，详细方法放进了三份 references 文件，主说明留下适用条件、关键约定和资料入口。
这样，AI 先判断本次需要哪种方法，再读取对应资料。新版也写清了检查的适用条件：只修改一段文字时，不要求启动与本次改动无关的整套检查。
其他修改主要集中在四个范围：
- 资料读取：根据本次任务查相关内容，减少无条件全文预读。
- 检查要求：检查范围与实际改动对应，避免一个小修改默认检查整个项目。
- 任务衔接：复用已经明确的要求和仍然有效的决定，减少重复提问与停顿。
- 内容位置：把阶段进度和历史记录移出长期规则，补齐缺失资料并修复失效引用。
你可以重点查看常用 Skills 的 description，再看它指向的正文和资料。素材位置、账号环境、特殊命令和真实业务要求，应当能在对应文件中找到。对某项删除不放心，就让 Codex 找出原句和处理后的去向。
第三，检查通过，究竟通过了哪种检查。
这轮记录了以下结果：
- 49 个正式文件与最终改写版的内容校验值一致；这意味着放到正式位置的文件与准备采用的版本相同。
- 12 份 Skill 主说明中，10 份通过通用格式检查，另两份出现已有字段的兼容问题。
- 检查脚本识别出的 10 处 Markdown 相对链接有效；分组记录还核对了其他被引用资料的位置。
- 7 个辅助脚本通过语法检查。这只能说明代码在语法上可以解析，没有实际运行它们处理业务数据。
两份未通过通用格式检查的文件，都包含原有的 effort 字段，而这个字段不在检查脚本的允许列表中。它是用来声明思考投入的配置项，例如 medium。这次保留了原值，并另外确认文件开头的配置与原版一致、能够正常解析，没有为了让检查通过而删除原设置。这个结果也不能证明当前工具一定会采用该字段。
所以，报告不能只写一句“全部通过”。文件格式、引用路径、程序语法和真实任务表现，要分别说明。这轮没有完成原版与新版在相同条件下的业务任务对比，不能仅凭文件检查宣称整体提效。
第四，新版现在处于哪一步。
| 结果里写的状态 | 对你意味着什么 |
|---|---|
| 候选文件已生成 | 新版已经写好，可以检查内容 |
| 正式文件已替换 | 新版已经放到正式位置，恢复备份应当可找到 |
| Skill 入口已被发现 | 工具提供的可用 Skill 目录中已经出现该入口 |
| 已用实际任务验证 | 已经观察过指定场景的表现，结论以这些任务为准 |
我这轮已经完成正式文件应用，后续任务提供的 Skill 目录也出现了新入口。 各项目的新任务是否读取正确规则、是否选对 Skill、是否少读无关资料，仍需要实际使用记录。
已经正式采用的文件无需再安装一遍。接下来直接从相应项目开始一项真实工作，观察具体表现即可。
09｜看完产物后，可以怎样回复 Codex？
根据实际交付状态，选择合适的回复。把项目范围和 Skill 名称换成自己的即可。
范围没有做完整时，要求补齐遗漏。
我要求整理的是 Codex 中保存的全部项目。请用实际项目列表逐项核对，列出已检查、已修改、保留、不适用、无法访问和未完成的部分。复用本轮已有结果及仍然有效的检查，只处理遗漏或发生变化的部分。继续按已经约定的方式交付；若原来已授权正式修改，就完成必要备份、修改和检查，不停在候选文件阶段。
看不懂为什么删了某条要求时，要求解释具体改动。
请拿我常用的一个 Skill 举例，列出最重要的几处改动：原来怎么写、现在怎么写、原要求会造成什么行为、为什么这样调整。重点说明语言偏好、素材位置、账号环境和业务要求是否保留；移动的内容请给出新位置。按已有记录回答，不需要重新审计全部文件。
如果收到的仍是候选文件，选定采用范围。
本次采用范围是这份项目 AGENTS.md，以及我选定的 Skill 的新版 SKILL.md 和同步修改的 references。请按交付清单核对正式位置，检查原文件在整理后是否又有变化，保护新增改动并保存可恢复的原版。然后应用选定文件，完成必要检查，告诉我如何在新任务中确认启用。
这段话已经交代了采用对象和后续操作，不需要每完成一个小步骤再回复一次“继续”。若出现会改变范围的冲突，Codex 应说明具体文件和影响。
如果已经正式应用，直接给一个实际任务。
例如，新开对应项目的任务后，可以这样写：
请把指定文章的标题改成我给的新标题，保存并回读，确认正文没有变化。完成后简短说明实际使用了哪些规则或 Skill，以及本次改动的检查结果。
观察它有没有直接完成标题修改，是否仍然进入访谈、封面检查或其他无关流程。完整写作任务和发布任务，也可以分别按自己的真实需求试用。
启用后仍然出现老问题时，提供具体场景。
我刚才只要求修改一个标题，但你仍然读取了完整写作资料，并进入访谈。请根据刚才这次执行记录，找出导致这些额外步骤的 description、正文或引用位置，只修正与该问题直接相关的要求。保留仍有用的方法，用同一个标题修改任务复查一次，并报告结果。
这样的反馈能对应到真实行为，也方便判断修改是否有效。比起笼统地说“还是太啰嗦”，描述刚才让它做什么、它额外做了什么，更容易找到要改的地方。
10｜这次到底精简了多少？
先把数量说清楚：这轮应用了 49 个文件，其中 40 个内容新增或改写，9 个只是随 Skill 原样迁移。 下面的整体精简比例只统计这 40 个内容有变化的文件。
比较时，6 个真正新增的参考文件在原版按零计算；迁移的文件使用原目录的备份作比较，不能因为换了存放位置，就把原有内容算成新增。统计包含本次改动的参考资料和脚本，不计报告及未改动资料。
| 统计项 | 整理前 | 正式新版 | 变化 |
|---|---|---|---|
| 总行数 | 4,298 行 | 3,832 行 | 减少 466 行，约 10.8% |
| 总字符数 | 149,067 | 139,236 | 减少 9,831 个字符，约 6.6% |
字符数包含文字、标点、空格和换行，按本次修改前的备份与最终文件计算。
再把主说明单独拿出来看：
| 主说明范围 | 行数变化 | 字符数变化 | 字符减少比例 |
|---|---|---|---|
| 13 份 AGENTS.md | 1,552 → 1,039 | 48,676 → 35,678 | 26.7% |
| 12 份 SKILL.md | 1,605 → 1,139 | 64,855 → 46,081 | 28.9% |
其中 12 份 Skill 主说明的具体变化如下，表中用编号区分。
| Skill 编号 | 行数变化 | 字符数变化 | 字符变化 |
|---|---|---|---|
| Skill 01 | 498 → 27 | 23,493 → 1,609 | 减少 93.2% |
| Skill 02 | 45 → 45 | 1,342 → 1,377 | 增加 2.6% |
| Skill 03 | 41 → 41 | 1,867 → 1,957 | 增加 4.8% |
| Skill 04 | 56 → 56 | 1,885 → 1,925 | 增加 2.1% |
| Skill 05 | 44 → 44 | 1,003 → 1,011 | 增加 0.8% |
| Skill 06 | 64 → 64 | 2,554 → 3,486 | 增加 36.5% |
| Skill 07 | 54 → 55 | 1,724 → 2,026 | 增加 17.5% |
| Skill 08 | 47 → 43 | 1,120 → 1,264 | 增加 12.9% |
| Skill 09 | 368 → 372 | 17,405 → 17,579 | 增加 1.0% |
| Skill 10 | 89 → 89 | 3,197 → 3,467 | 增加 8.4% |
| Skill 11 | 153 → 150 | 4,816 → 5,323 | 增加 10.5% |
| Skill 12 | 146 → 153 | 4,449 → 5,057 | 增加 13.7% |
这些数据说明了两种不同变化。
一种是把长主说明改成简短入口。Skill 01 的主说明减少了 93.2%，但详细方法进入了参考文件，所以不能把 93.2% 写成整份 Skill 包的减少比例。
另一种是把条件写准确。有些说明补充了适用范围、当前有效的资料位置或已有决定的复用条件，字符数反而增加。是否值得保留这些内容，要看它们能否减少误操作和无关步骤，不能要求每份文件都按同一个比例缩短。
如果你也想取得同样口径的数据，可以这样问：
请根据本轮实际应用清单，区分内容改写、新增、迁移和原样保留。只对内容新增或改写的文件统计原版与新版的行数、字符数和变化比例，AGENTS.md、SKILL.md 及全部改动文件分别列出。真正新增文件的原版按零计算；迁移文件以迁移前的原包为基线，不能因路径改变计为新增。未改动资料和报告不计入。说明哪些内容删除了、哪些移动了、哪些因为补齐必要要求而增加。
这轮 19 个项目的审查与正式应用耗时约 20 分 36 秒，主任务启动了 3 个子 Agent。 子 Agent 是协助处理独立工作的其他 AI 助手，这次按互不依赖的范围分工，主任务汇总并应用最终文件。时长按这一轮检查和修改的运行记录计算。
这只是本次运行方式，不意味着整理规则必须使用多个助手。若希望控制额外开销，可以在提示词中写明：“本任务由当前 Agent 完成，不启动子 Agent；独立读取可以批量执行。”实际耗时仍取决于处理范围和检查内容。
目前能确认的是：本轮范围内的正式文件已经更新，整体字符数减少约 6.6%，主说明、引用资料及部分流程也完成了调整。 新任务是否更快、是否少读无关资料、是否减少 Token，仍没有相同条件下的前后对比。
Token 是模型处理文本时的计量单位，与字符数不一一对应；多个助手的用量和缓存还需要分别核对。本次没有核定包含全部子 Agent 的完整用量或费用，因此不能把字符减少 6.6% 写成 Token 或费用也降低了 6.6%。
现在可以从第五节的三个任务开始观察：该用的 Skill 能选中，小修改能直接完成，完整任务能交付到位。把具体结果记下来，再决定哪些调整保留、哪些继续修正。