翻译下这个，我们应该如何使用gpt6:https://x.com/pvncher/status/2095991462416490862

翻译好了，这是 OpenAI Codex 方向的 eric provencher 发的长文，主题一句话：GPT-6 Astra 出来之后，你过去一年攒的那堆「叮嘱模型的话」（Skills、AGENTS.md、任务提示词）该重新审视瘦身了，很多以前必要的指令现在反而拖后腿。按原文结构翻译： 一、Skill 文件 1、别往项目里堆一堆 skill。每个 skill 的名字和描述都会塞进模型上下文供它判断何时使用，描述太长、数量太多，Codex 会自动截短描述，模型反而更分不清该选哪个；描述还可能互相矛盾或都带「选我选我」的劲。 2、描述要尽量短，但要写清楚「什么时候该用」。原文给了对比：坏描述会诱导模型一碰数据库相关的事就加载它；好描述只在处理迁移（migration）时才该用。 3、要渐进式披露：读 skill 本身耗上下文，所以多流程的 skill，根文档只当个最小路由，指向子文档和脚本，给模型足够线索去查，别逼它把暂时用不着的全读一遍。 4、很多 skill 写成了详尽剧本/菜谱，但模型对歧义的理解强太多了，过度具体的指引以前帮得上忙，现在反而碍事。 5、仓库里的 skill 还会指导其他协作者的 agent（可能是别的模型），给 Sol/Luna 写的约束可能把 Astra 管死，要考虑留什么给谁用。 二、AGENTS.md 1、逐条重审：每次编辑前强制读一摞文档、生成全仓 repo map，改个 typo 也要这样就是过度，Astra 自己知道该读什么。 2、老模型需要你催「跑测试、检查结果」，Astra 自己会做，你再写同样的指令，反而导致没必要的多余测试。 3、Astra 更谨慎、放不开，你要主动给它授权。原文例子：在 AGENTS.md 里写明「本地测试用一次性 fixture、无生产权限，直接跑，改坏了就修，不用每一步都问我批准」。 三、边界怎么画 以前模型爱自作主张，你可能写了很重的「必须先问我」措辞。Astra 判断力好得多，而且它是当真遵守边界的——你写得过于保守，它会在你其实希望它继续的地方停下来。 四、收尾时机（Persistence） 以前 Sol 能一口气干很久，Astra 更倾向于干完第一版就回头找你 review，哪怕后面还有活。解法：开工前把「完成」定义清楚——把「把实现跑起来、检查结果、修掉失败」写进任务本身；反过来，如果你写了「第一版实现完就停下来等我」，等于把它往更早停的方向拽。想让它继续深挖，就明确说清探索哪里、在哪停。 收尾建议：新模型是打扫屋子的好机会——让 Astra 按这篇文章的清单给你的仓库做一次审计，然后去做以前不敢动手的东西。 给你落地的三条：AGENTS.md 瘦身到只剩「会管住它出错」的规则；skill 描述压到最短并写明触发条件；每个任务先把「完成标准」写全再开工。核心逻辑就一句：模型越强，你要给的越不是流程，而是边界、目标和授权。