文章总结： 本文讨论astragpt-6模型上线后应清理旧指令，重点优化技能文件与agents.md。建议删除为旧模型写的补丁式指令，技能描述要短且触发条件准确，agents.md需逐条重审，将完成标准写进需求里，按新模型判断力重新校准边界。核心是给指令做减法，释放新模型潜力。 综合评分： 80 文章分类： 实战经验

Astra GPT-6 来了，你必须要懂的东西！

原创

一个不正经的黑客 一个不正经的黑客

一个不正经的黑客

2026年9月5日 23:43 广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

“

新模型上线时，最该清理的不是代码，是 你写给旧模型的那些指令 。

Astra 上线第一周，我把项目里那份攒了大半年的 AGENTS.md 拿出来逐条审， 删掉了将近一半 。

原本为了压住 Sol 的各种问题才加上的条款，到了 Astra 身上 要么多余，要么变成了阻力 。

这件事 比任何 benchmark 都更值得讲 。新模型到来的那一刻，最该做的不是研究它能做什么，而是回头看看 我们塞给旧模型的那些补丁式指令 还成不成立。

这些指令的载体不止一种： 技能文件、AGENTS.md ，以及你每次临时写的 任务提示词 。它们都在影响模型干活的方式，也都该重新过一遍。

📌 本文看点

01

技能文件越堆越难选

02

AGENTS.md 逐条再审

03

完成标准写进需求里

01

SUBTRACT

这次该做的是减法

每次模型换代，第一反应通常是 补几条新说明 。真正有效的做法却相反：把过去一年攒下来的指令 逐条拿出来 ，问一句它是否还成立。

我在几个长期维护的项目里逐条审过，结果相当一致， 大部分指令 在 Astra 上要么多余，要么变成了阻力，具体比例随项目而异，但确实是一个 不小的量 。

02

SKILLS

技能文件最容易失控

一）别把技能当收藏品

技能文件本质上就是一份 Markdown 提示词 ，偶尔附带几个脚本，适合承载 只在特定任务里才需要 的流程，或者说明某个插件该怎么用。

很多人习惯往项目里塞大量技能，这个做法本身就是错的。每个技能的 名称和描述都会进上下文 ，模型靠它们判断该调用谁。描述写得太长，或者技能数量太多，Codex 就会为了塞进上下文而 截断描述 。

后果比想象中严重。模型看到的每条描述 只剩半句 ，挑哪个的准确率跟着下降。有些描述还带着强烈的「快选我」语气，彼此 互相矛盾 ，模型就会把一堆跟当前任务无关的指令一起加载进来。

如果你让 Codex 自己创建过技能，它多半用过 $skill-creator 。我们最近调整了它的指导内容，专门针对实践中观察到的几类问题。

二）描述要短，触发条件要准

技能描述的第一原则是 尽可能短 ，同时说清楚什么情况下该用它。这不是文风问题，它 直接决定调用准确率 。

举个常见的翻车例子。一个管数据库迁移的技能，如果描述里含糊地写「处理数据库相关任务」，模型就会在 任何跟数据库沾边的事情 上调用它，而不是只在真正需要迁移的时候。

「描述里写清楚触发条件，比写清楚功能重要得多。」

三）把根文档做成导航入口

好的技能有个共同特征， 渐进式披露 。读取技能要占上下文，占得越多， 上下文压缩就来得越早 ，还容易把跟当前任务无关的指导一起带进来。

对包含多种流程的技能，正确做法是把根文档写成一份 精简的导航页 ，指向配套的文档和脚本。给模型足够的线索，让它知道该去哪儿查，而不是逼它一上来就把所有内容读完。

四）别把技能写成操作清单

还有一类技能被写成了详尽的流程清单。这在模型理解力有限的年代有效，如今 反而成了枷锁 。

模型对细微差别和模糊地带的把握已经强了很多。 过于具体的步骤说明 ，会限制它根据实际情况做出更好的选择。

这跟 Sol 时代是反过来的。那时候智能体常常跳步骤、漏边界，写得越具体越让人放心；现在你替它把每一步都钉死，它反而没了 腾挪的空间 。

仓库里的技能也会指导 其他贡献者使用的智能体 ，而那些智能体背后的模型可能完全不同。对 Sol 或 Luna 有帮助的约束，放到 Astra 身上就可能变成 过度限制 。动笔之前要想清楚，这份指令究竟会被哪些模型读到。

03

AGENTS.MD

AGENTS.md 需要逐条重新审判

AGENTS.md 的覆盖面最广， 只要模型在你的仓库里工作，它就在生效 。正因为如此，这里的 每一条指令都值得单独问一句 ：现在的任务还需要它吗？

最典型的过度约束是「 修改前先通读相关文档 」。修一个拼写错误，却要求模型先把一大堆文档读一遍、把整个仓库梳理一遍，显然过头了， Astra 自己就能判断该读什么 。

要求每次改动前都预读文件，代价是 上下文被快速消耗 、进度被拖慢。不过，指向真正相关的文档依然有价值，前提是你得记得 同步更新这些文档 。

另一类该删的指令，是那些提醒模型跑测试、检查自己工作的条款。旧模型确实需要被提醒， Astra 会主动做这些事 ，再写一遍只会换来一轮不必要的重复测试。

Astra 做事细致，但在「该把任务推进到什么程度」这件事上 比前代更犹豫 ，有时候需要推它一把。与其每次口头授权，不如直接 把授权写进 AGENTS.md ，例如这样一段：

本地测试使用一次性测试夹具，没有生产环境的访问权限。运行这些测试，修复由本次请求的改动引起的测试失败，并重新运行受影响的测试，无须在每一步都请求批准。

04

BOUNDARIES

别把新模型管成旧模型

如果你的上一代模型曾经未经许可就替你执行操作，你大概率在指令里加过 措辞强硬的限制 ，要求它凡事先征得同意。这类约束本身没错， 问题出在力度 。

Astra 的判断力比前代强得多，协作方式也该跟着调整。更要紧的是，它会 认真遵守你划下的每一条边界 ，于是在那些你其实希望它继续做下去的地方，它也会停下来等你。

边界依然要写，但要按新模型的判断力重新校准。

值得重新过一遍：哪些是 真的需要人类点头 的危险操作，哪些只是当初被旧模型吓出来的条件反射。

05

DONE CRITERIA

把完成标准写进需求里

习惯了 Sol 接下请求后长时间连续工作的人，换了 Astra 可能会不适应。它在判断何时该停下来时 明显更谨慎 ，往往 做完初步实现就回来找你审阅 ，哪怕后面还有一堆活没干。

我自己就被这件事绊过几次。让 Astra 写一个工具的初版，它默认在代码能跑的那一刻就停下等你审阅，不会主动去做 README 里没列但其实需要的发布脚本或文档校验。

💡 解决办法是在开工前就把「怎样算完成」讲清楚。

如果这件事包含让实现真正跑起来、检查结果、修掉发现的问题，那就把这些要求 直接写进请求里 。

反过来同样成立。如果你明确要求它在初步实现后停下等你审阅，它就会倾向于 更早收手 ，所以要先确认自己是否真的需要在那个节点做决定。

要是你希望它第一轮做完之后继续往下探索，也得说清两件事：探索什么，以及 探索到哪一步为止 。

∞

THE END

给指令做一次大扫除

新模型上线，是给现有指令做一次彻底清理的 最好时机 。清空那些为了迁就旧模型而写下的补丁，你会发现 Astra 能跑到的地方， 比自己以为的要远得多 。

我的建议是，把这篇文章交给 Astra，让它按这几条原则给你的项目 做一次指令审查 。然后，去构建一些 你以前根本不会尝试的东西 。

END

我是 一个不正经的黑客 ，十年信息安全老兵，长期关注 AI 编程工具的实践与变化。

如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：一个不正经的黑客 一个不正经的黑客 一个不正经的黑客《Astra GPT-6 来了，你必须要懂的东西！》