一个很蠢的现状
我们先看看现在是什么情况。
你用Codex，它要求你把技能文件放在.codex/skills。
你用Cursor，它可能要求你放在.cursor/skills。
你再用个别的Agent工具，又是另一个目录。
结果就是你的项目根目录里一堆.xxx/skills文件夹。
每次写个新技能，复制粘贴三四份。改个bug，三四个地方都得改。
这不是在写代码，这是在当复读机。
更糟糕的是，你想换个Agent工具试试？对不起，先把所有技能文件迁移一遍吧。
问题出在哪儿
本质上这是个地盘问题。
每个Agent工具都想搞自己的专属目录，就像动物撒尿划地盘一样。
.codex/skills是我的地盘，.cursor/skills是你的地盘，谁也别想侵犯谁。
听起来很合理对吧？各管各的，井水不犯河水。
但开发者遭殃了。
我们不是Agent工具的附庸，我们只是想用个顺手的工具干活而已。
一个很简单的方案
Alexander提出的方案简单到让人想笑：
大家都从.agents/skills读不就完了？
没错，就这么简单。
不是.codex/skills，不是.cursor/skills，就是.agents/skills。
所有Agent工具都从这一个地方读技能文件。
Codex已经支持了，现在正在呼吁其他工具跟进。
这就像当年前端模块化的混战。AMD派、CMD派、UMD派打得不可开交，最后ES Module出来，大家终于消停了。
标准的价值就在于让大家不用再瞎折腾。
为什么这事儿重要
你可能觉得这是小事。
改个目录名字而已，有必要这么大张旗鼓吗？
有必要。
这关系到整个生态会不会变成一盘散沙。
如果每个工具都搞自己的标准，开发者就被绑死了。用了Codex就得用它的目录结构，想换工具？先把配置全迁移一遍。
这种vendor lock-in（供应商锁定）是生态的毒瘤。
它会让开发者不敢尝试新工具，让新工具很难进入市场，让整个生态停滞不前。
反过来，如果大家都用.agents/skills：
你可以随便换Agent工具，零成本。
技能文件可以在社区共享，就像npm包一样。
新工具不需要让用户重新组织项目，直接就能用。
这才是健康的生态。
技术上不是问题
实现这个很简单。
对Agent工具来说，就是改个读取路径：
const skills = await readDir('.agents/skills')
.catch(() => readDir('.codex/skills'));
对用户来说，就是移动一下文件：
mv .codex/skills .agents/skills
技术从来不是问题，人心才是。
真正的挑战
Alexander在推文里特别强调"like/tag/RT for momentum"。
这不是在求关注，而是因为标准需要足够多的人支持才能成为标准。
如果只有Codex支持.agents/skills，那它就只是又一个专属目录。
但如果主流工具都支持，它就是标准了。
这让我想起TypeScript的故事。微软刚推出时，很多人不屑一顾。但Angular用了，Vue用了，React也用了，最后TypeScript就成了事实标准。
网络效应是标准形成的关键。
越多人用，就越有价值。越有价值，就越多人用。
这是个正反馈循环。
我们能做什么
如果你在开发Agent工具，支持.agents/skills。
如果你在用Agent工具，去提issue要求支持。
如果你在写教程，推荐用.agents/skills。
每个人的一小步，汇聚起来就是生态的一大步。
总结
.agents/skills这个提议看起来很小。
但它解决的是生态碎片化这个大问题。
技术实现很简单，难的是让大家达成共识。
这需要社区的力量，需要每个人的参与。
好的标准不是设计出来的，是用出来的。
P.S. 如果你在用Codex，现在就可以把技能文件移到.agents/skills了。
粤ICP备14082021号
免费POC，
零成本试错
