别再只写提示词了，高手已经开始给 Agent 写工作习惯

「Skills For Real Engineers」，Matt Pocock 给这个仓库起的名字，嚣张得恰到好处。

7.3 万 star、6300 多个 fork，这个数据已经够夸张了。

但我更喜欢它这个标题。Real Engineers，玩票的请出门左转。

Matt Pocock 在 TypeScript 圈子里算得上大神，他之前搞过一个 TypeScript 报错翻译工具。这次他把注意力转向了 AI 编程，切入角度却跟市面上大部分教程不一样。

很多 AI 编程教程都在教一件事，怎么把提示词写得更精致，让 Agent 一次回答得更漂亮。

Matt 这套不太一样。

他没把 Agent 当许愿池，而是当一个每天都要进项目干活的同事。既然是同事，就不能每次开工都靠临场发挥，规矩要提前写清楚。

提示词解决不了协作习惯

他列了几个 Agent 在真实工程里反复掉进去的坑。

明明需求说得够清楚了，Agent 还是 get 不到点，要么漏了边界条件，要么理解反了优先级。

Agent 话太多，每次都要从长篇大论里淘金，找那几句能落到代码上的。

团队成员跟 Agent 说话的语气、用词、期待全不一样，张三写的提示词李四接手完全看不懂。

Agent 做了一个工程决策，你问它怎么这么改，它支支吾吾，给不出清晰的推理链条。

这几个坑我看完挺有共鸣。

很多时候 Agent 会写代码，但状态不稳。同样一个项目，今天你强调边界，它就注意边界。明天你忘了强调，它又按自己的理解往前冲。

这才是最烦的地方。

玄学提示词救不了这个问题，稳定工作习惯才救得了。

skill 管的是规矩

Matt 的处理方式也很工程化。

每个坑后面，都跟一条固定规矩。

比如需求容易被理解歪，就先让 Agent 把任务拆清楚，别急着写代码。

决策说不清，就要求它把取舍过程留下来。改了什么，依据是什么，放弃了哪条路，事后都能翻。

团队里术语叫法不一样，也写进规矩里，别让 Agent 猜。

这些 skill 的聪明之处，在于它们不急着解决某个具体技术难题。

它先解决一个更底层的麻烦，每次开新对话，你都得把工作方式从头讲一遍。

提示词像即兴演讲，每次都得现组织语言，背景讲一遍，规矩再强调一遍。

Skill 是把规矩写成制度。

花一个小时写一个好的 skill，之后一百次对话都按这个规矩走。

这个账很划算。

工程味在这里

Matt 在 README 里留了一句挺狠的话，My agent skills that I use every day to do real engineering - not vibe coding。

翻译过来大概是，我用这些技能每天做正经工程，跟着感觉写代码的那套别来沾边。

vibe coding 最近很火，说得委婉点是「让 AI 带着你飞」，说得直白点就是「我也不知道在写什么，反正能跑就行」。Matt 直接划了条线，这仓库是给认真做工程的人准备的。

这个项目给我的启发很直白。

跟 Agent 协作的质量瓶颈，已经从「模型够不够聪明」，慢慢变成了「你们之间的协作习惯够不够稳定」。

再聪明的实习生，每天换一套工作标准，也干不出好活。Agent 也一样。

提示词写得再漂亮，到头来还是在赌单次对话的运气。Skill 把赌局变成了制度。

目前这个仓库里的 skill 数量不算多，但看得出来，都是从真实工程摩擦里长出来的。

Matt 没有试图覆盖所有场景，只是把自己每天在用的东西晒了出来。

这比那种「我教你写提示词」的教程更实在。

提示词决定一次对话的上限，skill 决定一套协作能不能长期稳定。

明天再跟 Agent 开工前，先把今天反复提醒过的那条规矩写下来。