GPT-6 Astra 时代的 Skills 与 Prompt 重构指南：少一点脚手架，多一点判断
过去一年，很多团队为了让 AI 编程 Agent 稳定工作，给项目不断增加规则、Skill、AGENTS.md 和超长 Prompt。早期模型确实需要大量手把手的引导，但随着模型能力提升，曾经有效的脚手架可能正在变成新的负担。
GPT-6 Astra 时代需要重新审视一个问题：
这条指令是在帮助 Agent 理解任务，还是在替 Agent 重复执行它已经会做的事情？
本文整理 Eric Provencher 在 X 上发布的《Rethinking skills and prompts for GPT-6 Astra》，并将其扩展为一套适用于 GPT88、Codex 以及其它 Coding Agent 的实践方法。重点不是删除所有规则，而是让每条规则都拥有明确的适用范围、成本和停止条件。
一、先说结论：规则越多，不一定越可靠
一个 Agent 项目通常包含三类指令：
| 指令层 | 典型文件或内容 | 主要作用 |
|---|---|---|
| Skill | Markdown 文件、脚本和辅助资料 | 处理特定任务或工作流 |
AGENTS.md | 仓库级、目录级规则 | 约束 Agent 在项目中的通用行为 |
| 任务 Prompt | 当前用户请求 | 描述本次目标、范围和完成标准 |
这些指令共同决定 Agent 如何行动，但也会带来三种成本：
- 上下文成本：每次加载规则都会占用模型上下文；
- 路由成本：Skill 太多或描述太相似，模型更难判断该使用哪一个；
- 行为成本：互相冲突或过度具体的要求，会让模型反复确认、过早停止或执行多余步骤。
在 GPT-6 Astra 这类更擅长理解上下文和处理模糊任务的模型上，最有效的配置往往不是继续增加流程细节，而是保留必要事实、明确危险边界，并把任务完成标准说清楚。
可以把新的指令策略概括为：
最小必要规则
+ 按需加载知识
+ 清晰的权限边界
+ 明确的完成定义
= 更稳定的 Agent 工作流
二、Skill 文件：从“大而全的说明书”变成按需路由器
Skill 本质上是存储在 Markdown 文件中的工作方法，有时还会附带脚本、模板和参考资料。它最适合描述 Agent 只有在特定任务中才需要的知识，例如：
- 如何执行数据库迁移；
- 如何生成和验证 PDF；
- 如何运行一套特殊的部署流程；
- 如何使用某个团队内部插件；
- 如何完成一套需要多个工具配合的研究工作流。
Skill 不应该变成所有项目规则和背景知识的垃圾桶。
1. Skill 描述要尽可能短
Agent 通常需要先看到 Skill 的名称和描述，才能判断是否加载它。描述过长会产生两个问题：
- 每个 Skill 的触发条件占用更多上下文；
- 当 Skill 数量增加时，系统可能压缩或截断描述，导致模型看不到关键条件。
一个好的 Skill 描述应该回答三个问题：
- 什么时候必须使用它？
- 它解决哪类问题？
- 什么时候不应该使用它？
例如，下面这种描述范围过大：
处理所有数据库相关任务，包括查询、设计、迁移、调试、性能优化和部署。
它可能在任何提到“数据库”的任务中被触发，即使当前任务只是修改一个 README。
更好的写法是：
仅在需要创建、修改或回滚数据库迁移时使用。包含迁移前检查、执行、验证和失败恢复流程；普通查询和应用层数据库代码修改不使用本 Skill。
关键不在于写得更长，而在于边界更准确。
2. 避免“Pick me”式描述
有些 Skill 描述会不断强调“我最重要”“任何相关任务都应该使用我”，这会造成 Skill 之间互相争抢触发机会。
一个 Skill 不需要证明自己比其它 Skill 更强，只需要清楚说明自己的适用条件。建议避免：
- “这是处理所有 X 问题的终极 Skill”；
- “只要任务涉及 X，就必须优先使用我”；
- “比其它工具更可靠、更完整、更专业”；
- “任何情况下都应该先调用本 Skill”。
这些句子通常增加路由噪声，却不会增加可执行信息。
3. 使用渐进式披露
Skill 被完整读取一次，就会消耗上下文，并把模型带入更接近压缩或截断的状态。如果一个 Skill 同时包含多个工作流，不应该把所有内容塞进根文件。
推荐使用下面的结构：
skills/
└── database-migration/
├── SKILL.md # 最小路由器：判断何时使用、指向哪里
├── migration.md # 迁移流程
├── rollback.md # 回滚流程
├── verify.md # 验证检查
└── scripts/
├── preflight.sh
└── verify-migration.ts
根 SKILL.md 只保留：
- 适用条件；
- 不适用条件；
- 必须先检查的前置条件；
- 支持的工作流列表；
- 详细资料和脚本的位置。
示例：
---
name: database-migration
description: 仅在需要创建、修改或回滚数据库迁移时使用；普通查询和应用层数据库代码不使用。
---
# Database Migration
先确认目标环境、迁移版本和回滚策略。
- 新建迁移：阅读 `migration.md`
- 回滚迁移：阅读 `rollback.md`
- 验证结果：阅读 `verify.md`
- 可重复的检查：运行 `scripts/preflight.sh`
这样，Agent 先读取路由器，只有确实进入某个工作流时才加载对应资料。
4. 不要把旧模型的习惯硬套给新模型
某些 Skill 是为较弱或较早的模型设计的：它们会要求模型严格按照几十步清单操作、每一步都复述确认、每次编辑前读取整个仓库。
这些要求在当时可能有价值，但在 GPT-6 Astra 上可能造成：
- 不必要的上下文消耗；
- 任务速度下降；
- Agent 把注意力放在形式步骤，而不是实际目标；
- 简单任务被复杂流程拖慢；
- 模型在每个中间节点过度停下来等待确认。
Skill 应该告诉 Agent 哪些事实和边界必须知道，而不是替它写出每一个思考动作。
三、AGENTS.md：只保留仓库级的稳定事实
AGENTS.md 会在 Agent 进入项目时持续生效，因此它比临时 Skill 更需要克制。
适合放进 AGENTS.md 的内容包括：
- 项目使用的语言、框架和包管理器；
- 代码、测试、文档和生成资源所在位置；
- 不应修改的目录；
- 必须遵守的安全和隐私规则；
- 提交、发布和部署的固定约定；
- 项目特有的验证命令；
- 生产数据和凭据的权限边界。
不适合放进 AGENTS.md 的内容包括：
- 每个任务都要重复的长篇通用教程；
- 只适用于一个文件的临时说明；
- 模型已经能够自行判断的显而易见步骤；
- 与当前项目无关的工具清单；
- 过于具体、容易过期的操作顺序。
1. 每条规则都要问一次：现在还需要吗？
可以定期对 AGENTS.md 做一次清理审计：
| 检查问题 | 如果答案是否定的 |
|---|---|
| 这条规则是否仍然适用于当前仓库？ | 删除或移到历史文档 |
| 这条规则是否每个任务都需要？ | 移到专用 Skill |
| 这条规则是否属于安全底线？ | 保留，并尽量用工具或 CI 强制 |
| 这条规则是否只是模型能力不足时的补丁？ | 用新模型重新验证后考虑删除 |
| 这条规则是否已有其它文件重复描述？ | 合并，保留唯一来源 |
2. 不要要求每次修改前都读取整个仓库
“每次改文件前先阅读完整项目结构、所有文档和全部相关代码”是一条常见但昂贵的规则。
对于大型项目，它会快速消耗上下文；对于简单改动，它会把一个几秒钟的任务变成多轮侦察。更合理的写法是：
- 修改前读取与目标直接相关的文件和调用路径。
- 只有在跨模块、架构或数据流影响不明确时，才扩大检索范围。
- 不要为了满足形式要求而读取与当前任务无关的文件。
这仍然保留了“先了解影响范围”的原则，但把判断权交给模型。
3. 不要强制模型重复它已经会做的验证
早期模型可能需要明确提醒“修改后运行测试”。如果 GPT-6 Astra 在当前项目中已经稳定执行这类检查，就不必在每个 Skill 和 Prompt 中重复五次。
更好的做法是把验证要求分成两类：
- 必须验证的项目底线：放入
AGENTS.md、CI 或脚本； - 根据任务决定的验证：让 Agent 判断相关测试范围。
如果测试环境安全且不会访问生产资源，可以明确授权：
本地测试使用可丢弃的 Fixture，不访问生产环境。完成实现后，直接运行相关测试；只修复由本次改动引起的失败，然后重新运行受影响的测试，无需在每一步重复请求批准。
这比单纯写“必须测试”更有用，因为它同时说明了安全前提、执行范围和继续工作的权限。
四、决策边界：保护安全，但不要让 Agent 过度停摆
很多团队在 Agent 曾经误删文件、覆盖 Git 历史或修改生产数据后，会快速增加“任何事情都必须先询问”的规则。
这类规则能够降低一部分风险，但也可能把所有低风险操作都变成等待点。GPT-6 Astra 的判断能力更强，因此边界设计应该从“所有动作都要确认”转向“只有不可逆或高影响动作需要确认”。
推荐使用风险分层
| 风险等级 | 示例 | 默认行为 |
|---|---|---|
| 低风险 | 读取文件、搜索代码、运行只读检查 | 自动执行 |
| 中风险 | 修改工作区、运行本地测试、生成临时文件 | 在明确范围内执行 |
| 高风险 | 修改生产数据、推送、部署、删除、迁移 | 执行前确认 |
| 不可逆风险 | 覆盖历史、删除密钥、破坏性数据操作 | 明确目标、二次确认并保留回滚方案 |
边界规则需要说明的是“什么动作需要停下来”，而不是泛泛地要求 Agent 对所有事情都询问。
让安全边界尽可能由技术机制保证
Prompt 中的“不要做危险操作”容易被遗漏或误解。更可靠的控制方式包括：
- 最小权限的系统用户；
- 只读生产数据库角色；
- Git 分支保护；
- CI 门禁；
- 文件系统沙箱；
- Hook 和命令白名单；
- 部署审批；
- 可回滚的迁移和发布流程。
Prompt 负责解释意图，工具和平台负责执行底线。
五、Persistence：把完成定义写清楚
一些开发者会发现：GPT-6 Astra 完成第一轮实现后，比 GPT-5.6 Sol 更容易停下来等待复核。它并不是不会继续，而是更谨慎地判断“当前是否已经达到交付点”。
这时最有效的办法不是简单地说“不要停”，而是在任务开始时定义完成标准。
模糊 Prompt
把这个功能实现一下。
Agent 很难判断：实现到什么程度算完成？是否要运行测试？是否要修复测试失败？是否要启动本地服务？
清晰 Prompt
实现这个功能，并完成以下闭环：
1. 阅读与需求直接相关的代码；
2. 修改实现和必要的测试；
3. 运行受影响的测试和 lint；
4. 修复由本次改动引起的失败；
5. 检查最终 diff 和运行结果；
6. 汇报修改文件、验证命令和仍存在的风险。
在本地测试和代码修改范围内持续推进，不要在第一轮实现后提前结束。
遇到生产写入、推送或部署时暂停并询问。
这段 Prompt 同时定义了：目标、执行范围、验证闭环、继续工作的许可和必须停下来的边界。
2. 说明“继续探索”的范围和停止条件
如果你希望 Agent 在第一版实现后继续优化，不要只说“继续看看”。应该说明：
- 要探索什么；
- 探索到什么程度；
- 哪些方向不需要尝试；
- 何时停止并汇报。
例如：
完成基础实现后，继续检查错误处理、移动端布局和现有测试覆盖。只修改与本功能直接相关的文件。完成这三项检查并运行测试后停止，汇报剩余风险，不要扩展到无关重构。
六、用一次“指令清理审计”升级项目
GPT-6 Astra 上线或切换后，适合做一次完整的 Agent 配置审计。
第一步：盘点指令来源
列出项目中的：
- 所有
AGENTS.md； - 所有 Skill 名称和描述；
- 常用任务 Prompt 模板；
- Hook、权限、CI 和部署规则；
- 重复出现的测试、审查和提交要求。
第二步：标记每条规则的来源和目的
给每条指令增加几个问题：
这条规则解决过什么问题？
它现在仍然复现吗？
它是安全底线、项目事实还是模型补丁？
它是否有更可靠的工具机制？
它每次会消耗多少上下文？
第三步：合并重复和冲突
同一条“修改后必须运行测试”可能同时出现在：
- 根目录
AGENTS.md； - 前端 Skill；
- 提交 Prompt；
- PR 模板；
- CI 工作流。
它们不一定都要删除，但应该明确谁是权威来源。安全底线应尽量由 CI 或脚本强制，工作方法放入 Skill，任务范围放在当前 Prompt。
第四步：用真实任务回归
清理之后不要只看文件长度。选择三类任务验证：
- 一个简单任务，例如改文案或修小 Bug；
- 一个中等任务，例如跨文件功能和测试；
- 一个复杂任务，例如重构、研究或长链路 Agent。
记录：
- 是否选择了正确 Skill；
- 是否过度读取文件；
- 是否提前停止；
- 是否遗漏验证；
- 是否触碰了不该触碰的资源；
- 完成同一任务需要多少轮交互。
七、GPT88 项目中的推荐配置结构
对于使用 GPT88 接入多个模型的团队，可以采用下面的分层：
项目根目录/
├── AGENTS.md # 稳定事实、安全边界、项目级完成标准
├── docs/
│ ├── architecture/ # 架构和领域背景
│ └── adr/ # 关键决策记录
├── skills/
│ ├── database-migration/
│ │ ├── SKILL.md # 最小路由器
│ │ ├── migration.md
│ │ └── scripts/
│ ├── release/
│ │ ├── SKILL.md
│ │ └── rollback.md
│ └── research/
│ ├── SKILL.md
│ └── evidence.md
└── .github/
└── workflows/ # 确定性检查和发布门禁
建议的责任分配：
| 内容 | 放置位置 |
|---|---|
| 项目不可违反的安全规则 | AGENTS.md + 权限/CI |
| 只在特定任务需要的流程 | Skill |
| 大型参考资料和历史背景 | docs/，按需读取 |
| 可重复执行的检查 | 脚本、测试和 CI |
| 当前任务目标和范围 | 用户 Prompt |
| 临时决策 | 当前任务或 ADR |
八、常见反模式
反模式一：安装所有热门 Skill
Skill 数量越多，不代表 Agent 能力越强。描述越多、重叠越多，路由就越不稳定。只安装项目真实使用的能力，并定期清理长期未触发的 Skill。
反模式二：把所有知识写入根 AGENTS.md
根规则文件应该告诉 Agent 如何在项目中工作，不应该成为完整 Wiki。领域背景、历史决策和复杂教程应该拆到可按需读取的文档。
反模式三：用 Prompt 模拟权限系统
“请不要读取生产数据库”不如不给它生产数据库权限可靠。安全底线应由凭据、沙箱、网络和 CI 控制。
反模式四：为每个模型维护一套完全不同的规则
如果项目必须同时支持 GPT-6 Astra、GPT-5.6 Sol、Claude 或其它模型，应优先保留项目事实和安全边界，把模型差异放在少量路由说明中。不要让整个仓库规则被某个模型的历史弱点绑架。
反模式五：任务完成标准写得太模糊
“做完告诉我”不等于“运行测试并修复失败后汇报”。需要继续推进时，明确闭环、验证和停止条件。
反模式六：无限递归审查和探索
让 Agent 不断寻找更多问题，可能导致低价值修改、虚构缺陷和无止境循环。审查需要范围、优先级和停止条件。
九、可直接复制的任务 Prompt 模板
目标：
用一句话说明要交付的结果。
范围：
- 允许修改哪些目录或文件；
- 不应触碰哪些资源；
- 是否允许新增依赖。
完成定义：
- 实现目标功能；
- 运行与本次改动相关的检查；
- 修复由本次改动引起的失败；
- 检查最终 diff；
- 汇报修改文件、验证命令、结果和剩余风险。
继续工作权限：
在本地代码、测试、文档和可回滚修改范围内持续推进，不要在第一轮实现后提前结束。
需要暂停确认的动作：
生产数据写入、删除、Git 历史覆盖、推送、部署、密钥操作和不可逆迁移。
停止条件：
完成上述验收项后停止；如果发现目标不明确、权限不足或需要扩大范围，先汇报问题。
十、最终检查清单
- 每个 Skill 的描述都能清楚说明适用和不适用条件；
- Skill 根文件是路由器，而不是几十页的总教程；
- 复杂资料和脚本采用渐进式披露；
-
AGENTS.md只包含稳定的项目事实和安全边界； - 没有强制 Agent 为简单任务读取整个仓库；
- 安全底线由权限、Hook、CI 或沙箱协助执行；
- 低风险操作不会被“全部先询问”规则阻塞；
- 任务 Prompt 明确定义完成、验证和停止条件；
- 长任务说明了可以继续探索的范围；
- 清理指令后用简单、中等、复杂任务做回归；
- 已记录模型选择、任务成功率、交互轮次和返工量；
- 长期未使用或互相冲突的 Skill 已删除、合并或降级。
结语：把模型能力用在判断上，而不是让它背流程
GPT-6 Astra 时代的 Prompt Engineering，不是写出更长的指令，而是更准确地决定哪些信息值得进入上下文、哪些动作需要授权、哪些知识应该按需加载，以及什么时候可以把判断交给模型。
好的 Skill 不会试图替 Agent 思考每一步；它会提供任务所需的知识、工具和边界。好的 AGENTS.md 不会把整个项目写成教程；它会保留稳定事实和不可违反的规则。好的任务 Prompt 不会只描述“做什么”；它会定义“做到什么算完成，以及什么情况下必须停下来”。
对于 GPT88 用户来说，切换到 GPT-6 Astra 也是一次清理项目的机会：删除已经过时的模型补丁，缩短过度膨胀的 Skill 描述，把复杂资料改为渐进式披露，并用真实任务重新验证整套工作流。
最终目标不是让 Agent 看更多规则，而是让它在更少但更准确的规则下，完成更多可靠的工作。
来源与说明
- 原始文章：Rethinking skills and prompts for GPT-6 Astra
- GPT88 相关：GPT-6 Astra 模型详情：能力分析与评测
- GPT88 相关：GPT88 Skill 完整指南
本文是基于公开 X 长文的中文结构化整理与方法论扩展。不同模型、Harness、Skill 加载器和项目规模会导致实际效果不同；建议用自己的真实任务集验证规则清理前后的上下文消耗、交互轮次、成功率和返工量。
தொடர்புடைய வழிகாட்டி
GPT-6 Astra 模型详情：能力分析与评测