2026 年 9 月 11 日，OpenAI 发布了 Rethinking skills and prompts for GPT-6 Astra，讨论使用新模型时，应该怎样重新检查技能、AGENTS.md 和任务提示词。这篇官方文章，正是本次整理工作说明和知识库、并把过程写成操作实例的契机。
官方提出了一个很实际的问题：随着模型能力增强，过去为了让它做好事情而不断增加的指令，是否还都有必要？有些步骤曾经能帮上忙，沿用到 GPT-6 Astra 上，却可能带来无关的资料读取、重复检查，或者让它在本可以继续的地方停下来。
这很容易对应到日常使用中的情况：先把背景读完，每做一步都确认，结束后更新所有记录。时间一长，这些要求叠在一起，可能让一次小修改变成漫长的准备工作；一条让它继续做完，另一条又让它每一步都停下来。
因此，这篇文章从官方建议出发，用一次真实的 AGENTS.md 与 Obsidian 整理，说明怎样让 GPT-6 Astra 找出旧要求中的问题、生成改稿，再核对结果。你可以先在 ChatGPT 中上传或粘贴材料，完成审查和改稿；如果也使用 Codex，再继续处理本地文件。
官方建议，具体要改什么
官方文章主要讨论 Codex 的工作方式。与这次实例直接相关的建议，可以归为四点：
- 技能写清适用范围，材料按需展开。 技能描述太长、触发条件太宽，容易让模型加载无关说明。官方用数据库迁移举例：应该在新增、修改迁移或审查其上线方案时使用相应技能，而不是一碰到数据库就触发。复杂技能的入口也应尽量简短，再指向需要的说明和脚本。
- AGENTS.md 按任务指路。 改一个错别字，没有必要先读完整套架构、数据库和部署文档。保留资料入口，但说明什么任务需要看什么。官方也提醒，旧模型需要的反复测试提示，可能让 Astra 做出不必要的重复检查；验证要求应结合实际任务调整。
- 重新检查“先问我”的边界。 OpenAI 提醒，过去为了防止模型做得太多而写下的强硬限制，可能让 Astra 在用户愿意让它继续时也停下来。已经明确、安全且获准的流程，可以写清允许连续完成的范围。
- 提前说明怎样才算完成。 官方指出，Astra 有时会在第一版实现后就回来征求意见。如果你期待它继续运行、检查结果并修复问题，就应把这些写进任务，同时说明在哪里停下。
落实到这次整理，就是检查每条要求为什么存在：哪些仍然必须遵守，哪些只在特定任务中需要，哪些可以交给模型自行判断。涉及权限、原始资料和真实验证的约束，仍要保留。
官方文章并没有规定 Obsidian 应该怎样组织。下文的知识库结构和同步方法，来自这次项目实践；普通 ChatGPT 用户可以先借鉴其中的材料准备、任务说明和验收方式。
先弄清楚，这次要整理什么
这里涉及三个名字，其实对应三种常见材料。
AGENTS.md 是写给编码助手的项目工作说明。 它告诉助手去哪里找资料、哪些事情可以继续做、什么结果才算完成。没有代码项目，也可以先拿自己反复粘贴给 ChatGPT 的要求来练习。
Obsidian 是管理笔记的工具。 笔记可以互相链接，还可以直接引用另一篇笔记中的某段原文。这次整理的重点，是让人和 AI 都能从首页找到需要的资料，再查到原始依据。
操作手册或技能，负责说明具体任务怎么做。 例如发布网站、整理会议纪要、检查资料引用。它们适合在需要时再读。
还有一个操作上的区别：把 AGENTS.md 上传到普通 ChatGPT 对话中，是把它作为材料交给模型审阅，并不意味着它会像 Codex 那样自动加载本地项目规则，也不表示它已经能修改你的 Obsidian 文件。 本文前半段只需要上传或粘贴文字。
第一步：准备四份小材料
如果你的 ChatGPT 账号已经可以选择 GPT-6 Astra，选好模型，再开一个对话。先准备下面四份材料，涉及内部信息时使用脱敏副本：
- 一份工作说明：现有 AGENTS.md，或你平时给 AI 的固定要求。
- 一份知识库首页：README、目录页或资料索引。
- 一条决策记录：写清当时为什么这样做。
- 一条问题记录：最好带日期、处理过程和验证结果。
第一轮用这四份材料就够了。让模型先指出还缺什么，再补相关文件，比较容易看清它的判断从哪里来。
还没有这些文件，可以使用本文的练习材料包。里面的内容全部为虚构示例，故意保留了重复要求和前后矛盾的状态。解压后，把四份 Markdown 文件上传到同一个对话；不能上传时，分别标明文件名后粘贴正文也可以。
真实材料上传前，删除密码、密钥、Cookie，以及无关的客户信息；把内部项目名、仓库地址、服务器信息换成一致的占位名称。两条记录讲的是同一个对象，就保留同一个代号，否则模型很难判断它们是否冲突。
图为流程示意，并非 ChatGPT 界面截图。
上传后，可以直接发这段话：
请帮我审查这四份材料，目标是让 GPT-6 Astra 在处理任务时，
更容易找到所需资料，并清楚知道什么时候可以继续、什么时候该停下。
这一步只审查，不修改正式文件。
请找出重复、冲突、已经过时或触发范围太宽的要求。
每项发现都引用原文，说明会影响哪类任务，再给出具体改法。
区分三类内容：长期工作规则、按任务查阅的操作步骤、历史事实。
不要因为想缩短文件，就删掉事实来源、必要授权或验证要求。
材料不足的地方请注明；先完成已有材料能支持的分析。
交付一份修改清单，最后说明还需要补充哪份资料及原因。
你要看的，是它能否指出某一句话为什么有问题。例如，“每次先读完全部文档”会让改错别字也背上整套流程；“把文档写得更简洁”则还不足以指导修改。
第二步：把笼统要求改成能判断的条件
这次真实整理中，旧规则要求每次预读固定的几份核心文档。改稿把它们变成了按任务选择的入口：涉及架构再查架构说明，追踪进度再查当前状态，准备发布再查发布手册。
下面是简化后的写法，文件名只是示例：
处理服务边界时，查 Architecture.md 的相关章节。
核对任务进度时，查 TODO.md 及其证据链接。
准备发布时，查 Runbooks/发布.md。
先读当前任务需要的内容，发现缺口后再扩大范围。
类似的调整还出现在“每一步都确认”上。如果已经明确让助手修改一份草稿，再让它为调整标题、检查链接、修正自己引入的错误逐次询问，会把一件完整的事情切得很碎。
可以把继续做的范围写清楚：
本轮已授权的草稿修改、相关链接检查和本次引入的错误修正，
请连续完成，不必逐步询问。
涉及正式发布、删除原始记录或扩大到其他项目时，说明新增范围。
只有草稿权限时，不把修改建议登记为已采纳决策。
这类文字描述的是你的工作约定，不能替代产品权限、工具许可或组织要求。它的作用，是减少已经获准范围内的重复确认。
“完成”也要具体。对于这次文档整理，完成条件可以是：交付完整改稿；保留原文引用；确认引用目标存在；列出仍未核实的状态。若只要求审查，交付有依据的审查结果就是完成，无须自动升级成正式修改。
官方文章还提醒，旧的测试要求可能让 GPT-6 Astra 重复检查。因此可以写“验证覆盖本次改动影响”，而不是让所有任务都跑一遍全部测试。改文字检查文字与链接；修改程序行为，再选择相应测试。真实案例中的同步脚本涉及文件覆盖与历史保留，仍然需要专门验证。
看完修改清单后，继续发第二段：
请按刚才有原文依据的建议，生成以下完整改稿：
1. 工作说明：保留稳定规则、资料入口和完成条件。
2. 知识库首页：让读者能按任务找到原始资料。
3. 操作手册：接收从工作说明移出的具体步骤。
逐项列出保留、改写、移走和删除的内容，说明理由。
原始记录和日期必须保留，不把建议写成已经实施的事实。
没有提供的目标文件或路径，标为“待创建”或“待确认”。
请完成全部改稿和自查后再交付。
这轮仍只生成候选文件，不覆盖正式文件，不提交或发布。
候选文件的价值，在于能逐项核对。你应该找得到每条重要旧规则的新位置，也看得出哪些句子确实被删除了。
第三步：知识库首页负责带路，原始记录负责留证据
给工作说明减负以后，移出去的内容还得找得到。如果只是把长文件拆成十几个短文件，却没有清楚的入口，下次仍然要到处翻。
这次采用的方式是：总纲指向项目首页，首页指向主题与索引，再由决策、问题视图链接或嵌入原文。原文继续保存事实，导航页说明去哪里看。
图为结构示意。资料少时，用一个首页和几条原文链接就能开始，不必一次建齐所有层级。
下面这个最小例子，可以在一份空白的 Obsidian 笔记库里直接试。新建 Decisions.md，写入：
为便于查证，决策索引只引用原文，不复制完整事实正文。 ^decision-example-01
如果使用练习包，Decisions.md 中已经有这段内容，无需重复添加。再新建一篇 决策索引.md，写入：
## 记录方式
![[Decisions#^decision-example-01]]
切到阅读视图，索引页应显示那段原文。前面的感叹号表示嵌入；去掉感叹号，就变成指向原文的链接。
以后改动这段原文，引用页会跟着显示新内容。需要保留历史变化时，在原始记录中注明日期并追加说明，不要悄悄覆盖过去的结论。块标识 decision-example-01 也应保持稳定，否则旧链接可能失效。
“当前状态”则单独写清核验日期和依据。例如，问题记录先写“已修复”，两天后又写“复测失败，重新打开”，首页就不能继续沿用旧的“已完成”。模型应该指出状态变化，并标明最近记录仍需怎样核实。
这次实际做到了哪一步
上面的提示词是根据真实过程整理的练习写法。参考案例的实际操作发生在 Codex 的本地工作环境中，已经从审查推进到正式实施；在 ChatGPT 中得到审查结果或候选文件，不能算作已经完成这些本地操作。
在 2026 年 9 月 13 日的实施记录中，项目工作说明、知识库总纲和操作手册已经更新，随后将同样的方法用于另外三个项目。规则原件纳入版本管理，本机使用安装副本；安装前比较文件指纹，遇到未知修改就停下，避免覆盖别的工作。
已有的知识库分叉也经过保留双方历史的整合，并完成推送与独立核对。图谱检查覆盖数百条记录、数千个链接；后续三个项目各通过了 17 项工具测试，原有草稿保持原来的提交范围。
但还有两件事需要说清楚。第一，本次没有发布业务代码，也没有修改业务数据库。第二，服务器的直接拉取凭据并未配置；验证通过的是另一条文件传输与校验通道。把通道验证写成“部署完成”，就会给下次工作留下错误前提。
最有启发的一次修正，出现在 Obsidian 显示检查中：文件链接检查通过了，表格仍然显示错了。 原因是表格里的双链别名含有竖线，渲染时被拆成了额外列。后来调整了写法，并补上对应检查。
所以，生成一份“检查通过”报告还不够。最后在软件里实际点开几条链接，仍然能发现脚本没有覆盖的问题。
这些结果证明的是本次文件整理与同步按记录完成；没有做同题的新旧模型对照，也没有测得耗时或费用的改善幅度，不能据此宣称换模型后效率提高了多少。
最后一步：让它拿证据验收，你再点开看看
在 ChatGPT 中，可以把原稿和改稿留在同一对话里，发第三段：
请对照原稿审查刚才的改稿，并直接修正你能确认的问题。
检查重要规则是否丢失，移动的内容是否有新入口，
原始记录、日期和引用是否保留，历史状态是否被误写成当前事实。
不要把存在同名文件当成链接一定可用，也不要声称执行过没有做的检查。
交付最终候选稿，并按“已核对、未验证、需要我操作”列出验收结果。
仅依据上传文件能确认的内容作结论。
不能实际打开 Obsidian 的部分，给我具体点击路径和预期显示。
然后自己检查几处：从首页能否找到那条决策；嵌入的内容是否来自正确原文；当前状态是否带日期；被移走的操作步骤是否还找得到；没有证据的事项是否仍标为未验证。
如果使用 Codex，并希望它实际修改本地文件，需要进一步指定目录、允许修改的文件和最终验收。例如：“将我确认的三份改稿写入指定目录，先备份原文件，保留其他未提交修改；完成链接检查和代表性页面检查后交付。本轮不提交、不推送、不发布。”随后根据工具权限完成操作，不能把上一步生成候选稿当作已经写入。
第一次尝试，到一份工作说明和一个知识库入口就可以停下来。等下一个真实任务到来，观察它是否更容易找到资料、是否仍反复询问、有没有丢掉重要约束。出现具体问题，再改对应那一条。这样留下的规则，才知道为什么值得保留。
参考与材料说明
- OpenAI：Rethinking skills and prompts for GPT-6 Astra，2026 年 9 月 11 日发布，本文于 2026 年 9 月 13 日核对正文。
- 本文参考同日完成的协作规则与多项目知识库实施记录。项目名、账号、仓库地址、服务器信息、内部编号与本地路径已省略；代码块中的名称为教学示例。
- 三段提示词为本文整理的操作示例，未声称逐字复现原会话，也未声称已在普通 ChatGPT 中逐段复测。封面与两幅插图由 AI 生成，均不是真实项目截图。
- 下载四份虚构练习文件。练习输出可能不同，以能否发现原文问题并保留依据来判断。