⚠️ 只会用聊天型大模型、最近又想跟进新工具的人，最容易在这种时候花错力气：晚上刷到一个 5.4 万星的 GitHub 仓库，手都准备划走了，又怕自己错过下一步真会用上的东西。要是这一步看错，你花掉的不只是时间，还可能是预算和注意力。[C003]
GitHub 上这个叫 addyosmani / agent-skills 的仓库，前面是作者名，后面是项目名。名字看着像一包“让模型更会写”的技能，其实更接近给大模型提前写好的做事顺序。我的判断先放前面：agent-skills 卖的不是提示词，是工程纪律。[C001][C002][C005]
一条更新值不值得看，不看它列了多少功能，先看它会不会改掉你下一步的判断。这个仓库最容易让人看错的地方，就是把注意力全放在“5.4 万星、5900 次分叉”这层热闹上。[C003] 真正该看的，是它把“不准乱来”写成了流程。要是你只盯着表面热闹，很容易继续用“多找几个提示词、多换几个模型”这种老办法，最后一直围着聊天框打转，却没解决模型一进真实项目就容易跑偏的问题。
证据其实很直接。README 没把重点放在花哨功能，而是把写需求、列计划、动手做、补测试、复查、上线，直接钉成 /spec、/plan、/build、/test、/review、/ship 六步，还明确写了“先写需求，再写代码”“测试才算证明”。[C004] 另一个技能文档也把话说得更直：这些“技能”不是随口建议，而是工作流程。[C005] 看到这里就明白了，它不是帮模型多说两句，而是先把模型什么时候能动手、动手后要怎么证明自己没乱来，提前定死。
所以这条更适合哪种人？不是只拿聊天框改文案、写周报的人，而是已经想让大模型去碰脚本、网页、代码的人。你不一定现在就要用它，但最好先记住这个判断：以后再刷到类似工具，先问它有没有把流程写死，再问它功能多不多。身边要是有人正准备让模型直接改项目，这条值得转给他。