把项目指令想成一种信号传递练习。
你的智能体需要知道哪些事,才能避免一场事故?很多时候,差别就在于一行蠢话——比如告诉你的智能体备份放在哪,以及这对生产环境意味着什么。
就这么一行,本可以拦下今年 CEO 氛围编码灾难里的三起。全是同一个问题。
把 AGENTS.md 想成代码注释,但是合并成一个文件。不写「是什么」,写「为什么」。一旦开始写那些光看仓库结构就能轻易推出来的东西,你就是在浪费时间,浪费 token。
编码标准与实践很重要。
一个 issue 或 PR 上需要什么形式的证据。
还有,你要求 feature request 里的任何重大设计变更都必须有他妈的 mermaid 图,因为……那玩意儿实在太有用。
技能该处理的是:这是一件超出你分布范围的、特定工具或特定情境下的实践,以及把它做好的最佳路径。
以上两者,都尽量保持干净、易读、简洁,用尽可能少的字,以及你能凑出的最少的计算逻辑。
类似这样的话,We love uncle bob on our coding team, and strictly adhere to the principles of decoupling, SOLID, and self documenting code. CRAP everything at mid tolerances to reduce cyclomatic complexity. 就该放进你的 AGENTS.md,而且比花一万 token 解释同样几个概念省事得多。
这叫预计算先验。
机器知道的东西,但未必知道该用到当下这个项目或仓库上。
预计算先验很好玩,因为先验就是先验就是先验,不管它来自哪个领域。
Write this app like an early Stephen King novel 会让你的编码和文档风格发生变化。未必是变好,但意思你懂了。
实际上,你可以检验一个模型的泛化能力:看它是否只在旁边做叙述,还是真用这种方式让输出产生了实打实的差别。
一般来说,Claude 和 Astra 会把这类指令消化得很深,而 Grok 会照旧用同样的编码风格写代码,同时给你配上世界级的旁白式注释。
Grok 更有娱乐性,但它对「正确性」的偏执,对编码任务上的创造性思维是个大问题,我也担心它因此在真实场景里过拟合。
重点是:只要你小心别在叠加时制造歧义,你通常可以把相关领域的先验一层层叠上去。
举一个技能的例子:这是 cookie ledger API 的用法。这个工具的用途是追踪你饼乾和各类零食的进度。这是 API 规格。这些是常见的坑。
如果你的智能体要用一套复杂的电话系统,或与 SDD 工具交互,或任何比面包盒大的东西——这时候,你该写一个技能。