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