一行 description，从"各种"改到"窄而不薄"

旧稿是这样写的：

description: 一个功能全面、帮助用户处理各种开发任务的辅助插件。

二十四个字，没有一个字在传达信息。【全面】是夸自己，【各种】是没想清楚。毛病不在短，在又宽又薄——范围宽，什么都装；深度薄，一个词都没说明白。模型读完跟没读一样，还得猜这插件是干嘛的。

V1 我想到的改法是列举功能，写教程的人最容易有的直觉：

description: 包含 MCP server，提供代码检索、日志分析、依赖检查和部署辅助等功能。

具体是具体了，跑起来才发现新问题：列出来的四样，模型全部当成硬边界。"部署辅助"写在 description 里，模型在不该用部署的时候也会想起它。列举不等于精确——列举是把还没出口的边界，用错误的方式钉死。

V2 我把列举全删了：

description: 符合 Agent Plugins 规范的插件。

窄是真窄了，却窄成了一张说明书封面——说了它是合规的，没说里面是什么。模型读完照样不知道什么时候该调用它。这让我想起昨天 OpenAI、微软、亚马逊、Cursor、Vercel 一起发的 Agent Plugins。只定义打包和发现方式，其余一概不管。Dax Raad 批评它太单薄，有用部分迟早落进各客户端专属扩展，这话有道理。但我更在意的是它怎么处理窄：plugin.json 格式、MCP server 怎么打包，全定义得清清楚楚。窄是范围，薄是深度——范围窄了，内容反而厚了。

我那两版失败稿，一版宽而薄，一版窄而更薄。缺的是：分清哪些字在划边界，哪些字在讲内容。边界要窄，内容要厚。标准只管打包和发现，description 也该只写它是什么、怎么被加载，能力留给 MCP server 自己暴露。

V3 定稿：

description: 将 MCP server 与 Agent Skills 打包为符合 Agent Plugins 规范的插件目录，通过 plugin.json 描述配置，供客户端发现并加载。

四十来个字。比旧稿长，但每个字都在干活。真正牵动模型行为的诗眼是【符合规范】——它把边界划死了；后面那句【发现并加载】，告诉模型什么时候该碰它。Angie Jones 说统一性正来自这份"只管打包和发现"的克制，什么都管管不出统一。

说这是定稿，其实心里没底。上个月我改一条 system prompt，当时觉得完美，这周回头看又扎眼。这行 description 大概率也一样。哪天模型理解岔了，再回来改。改就改，只要动手前问一句：这一版，是想窄了，还是想薄了。