一个能稳定写文章的 Skill，主文件只有 162 行

开始写作前，Skill 要求建立 `research.json` 和 `field-notes.json`。第一次只把文章交给编辑检查器，它直接报错：没有提供现场笔记。补上参数后，报告显示 5 条现场观察、无阻塞错误；来源检查器又逐条核了 9 个事实。

这比在提示末尾写“请真实、深入、有观点”更有效。形容词无法验收，缺少字段、来源或观察可以让流程明确失败。

Agent 通常先看到名称和 description，再决定是否加载完整说明。当前写作 Skill 的描述同时写了能力范围——研究、测试、写作、配图和公众号导入，也写了硬边界——必须有具体观察、不能捏造体验、不能自动发布。

“帮助写文章”几乎没有路由价值。更好的描述应回答三件事：做什么、哪些请求触发、哪些相似请求不要触发。Word 文档技能就应说明处理 `.docx`，并排除 PDF 与纯文本写作。

当前主说明共 162 行，旁边有 8 份 references 和 7 个 scripts。编辑政策、来源规则、写作节奏、文章类型、视觉风格、微信格式与接口说明各自独立；只有任务走到相应阶段才读取。

这就是渐进加载的价值。`SKILL.md` 保存不可跳过的流程和判断分支，references 保存按需知识，scripts 负责可重复的校验与渲染，assets 保存主题和模板。主文件只画路线，百科式细节留在需要时再打开。

来源记录是否缺 URL、文章是否没有现场观察、图片路径是否失效，这些问题适合脚本判断。脚本应有清晰参数、非零失败状态和可读报告；Agent 负责解释结果并修改内容，不必每次重新发明一套检查逻辑。

本次文章第一版完成后又删掉至少 15%，最终编辑报告统计 2474 个正文字符、17 个自然段、5 条现场观察。数字不能判断文章是否好看，却能拦住“没有证据却写得很长”这种常见失败。

如果 Skill 总是不触发，问题多半在 description；触发后漏步骤，才修改主流程；上下文过大，再拆 references。把每次失败都变成一条新规则，会让相同意思出现多个版本，Agent 反而难以判断优先级。

安全边界例外。发布、发送、删除、外部上传等动作需要清楚的确认节点，这些约束值得出现在主流程，而不是藏在深层参考文件里。

明显正例：“打开这些网站，核验后写一篇公众号文章并配图。”明显反例：“把这段 CSS 的卡片高度改小。”边界例：“帮我整理几个 AI 网站。”第三类需要看用户到底要列表、研究还是成稿。

再跑一条完整任务，检查是否按顺序读取资料、保存证据、执行脚本和生成指定格式。一个 Skill 的价值不在目录有多漂亮，而在第二次遇到同类任务时，解释更少、结果更稳、失败更容易定位。