从这篇文章开始，系列进入规范与实操专题。

前面我们已经讲过 SkillSentry 怎么评估价值、怎么做盲测、怎么对照外部框架、怎么把线上失败回流成 regression。接下来这组文章回到发布前最具体的工作：Skill 应该怎么写、环境怎么配、完整测评怎么跑、CI 门禁怎么落地。

这一组会依次讲四件事：

写法规范 → 环境 → 操作全景 → CI

说到先区分两件事。让 Skill 触发，和让 Skill 做对

使用者痛点：Skill 常常要么根本不被模型选中，要么在错误场景被误触发，导致业务中断或使用者体验差。

写 SKILL.md 的主要挑战是它同时服务于两个目的：

1. 让 AI 正确触发当使用者说了对的话，这个 Skill 应该生效。
2. 让测评程序正确验证测评用例能够精确地验证 Skill 的每条规则。怎么说呢，

这两件事需要不同的写法。也有不同的失败模式，本篇围绕5 条主要原则展开，每条原则对应一类常见的写法问题。

原则一的观点是，description 是触发的生死线

description 做什么

description 是 AI 判断「是否应该加载或使用这个 Skill」的最关键前置信号。使用者发来的消息会先和 Skill 的元数据做语义匹配。description 写得越清楚，模型越容易在正确场景中选择它，也越不容易误触发。

Description 必须回答 4 件事：

1. 这个 Skill 解决什么问题
2. 什么情况下触发
3. 什么情况下不触发
4. 使用者输入的典型形态

差的 description vs 好的 description

差的写法示例：

description: 公司报销助手，帮助员工处理报销相关事务。

• "报销相关事务" 太宽泛，AI 不知道什么时候该用。
• 没有触发词，匹配度低。
• 没有排除条件，容易误触发「查一下我上次报销记录」这种非提交场景。

用于员工发起差旅或日常资源用量报销申请。**触发场景**：
- 使用者说「帮我报销」「提交报销」「我要报差旅费」
- 使用者提到发票、资源用量单、出差资源用量并要求提交或处理
**不触发场景**：
- 仅查询历史报销状态
- 催促审批
- 只问资源用量政策

触发率与 description 的关系

sentry-static 会评估你的 description 能否被正确触发。旧的 sentry-trigger 已经退役，仅作兼容入口。下面是 SkillSentry 当前建议的触发率阈值——这是工程门禁口径。而非领域通用标准：

触发率	含义 & 处理方式
≥95%	正常，description 清晰标注参考值。
90%–95%	黄色警告，建议调整 description。
<90%	严重问题，自动降级为 CONDITIONAL PASS。

Pain Point：Sprint 中频繁出现「Skill 从未被模型召回」导致需求卡住需要反复调试 description 才能通过门禁。

• A) 用「管理」「处理」「助手」等泛词，没有具体动作；B) 没写触发词，全靠 AI 猜测语义；C) 没写排除条件，导致其他场景误召回。

原则二的观点是，主文件 行警戒线

为什么是 行警戒线？

This numeric threshold is not a universal research constant;it is an engineering safeguard derived from long‑context studies and our own static analysis experience. When context grows,language models tend to forget information located in middle of prompt.

• The rules placed at very beginning or end have high compliance.
• The rules in middle suffer a systematic drop as file length increases.
• The longer file。higher risk that middle rules are ignored.

The “<= 200 行警戒线*` is a practical limit for ordinary Skills. If you exceed it,consider splitting skill,extracting includes,or de‑duplicating rules.

超过 行时怎么办？不过，

• 方案一：规则拆分

expense-reimbursement/
│ SKILL.md ← 只负责“发起报销”
expense-query/
│ SKILL.md ← 只负责“查询状态”
expense-policy/
│ SKILL.md ← 只负责“回答政策”
...

• 方案二：提取 include 文件

# 主文件保持简洁
## 主要规则
...
# 引入外部枚举
include: ./expense-types.md
include: ./city-subsidies.md
...

• 方案三：审查冗余规则

You can run `sentry-static` to automatically surface duplicate or near‑duplicate rules and merge m into a single canonical statement.

sentry-static 的静态检查项

• Main file> 200 行 → 发出 “中间遗忘效应风险” 警告。
• 发现重复规则 → 标记语义相近对并提供合并建议。
• 缺失 HiL 步骤 → 报告 “高风险操作未确认”。

原则三的观点是，两种规则。两种写法

SKILL.md 中的规则分为两类；其实，混用会让 AI 难以执行准确且可预测。

类型一这方面。强制型规则

• 定义 : 无论任何情况都必须遵守，不允许上下文变通。
• 写法 : 命令式、直接、无歧义。其实，

- 提交前必须调用 validateExpense 验证金额。- 发票金额超过 5000 元 时必须请使用者上传原件。❌ 差的写法：
- 通常情况下应该先验证金额。话说回来，- 如有必要，请上传原件。

再看类型二。解释型规则

• 定义 : 提供背景与判断依据，让 AI 在特定情境下做出合适决策。
• 写法 : 给出 Why + What，可根据上下文灵活处理。

- 如果使用者提交金额明显低于行业市场价。说明可能填写错误，应提示核查。❌ 差的写法：
- 检查金额是否合理。

混用代价

• 强制型用了软表达 : AI 把 “通常” 当成可变通，从而跳过必要步骤。
• 解释型用了硬表达 : AI 将每个细节视作不可违背约束，使对自然语言变体缺乏弹性。

判断技巧 : 问自己：“这条规则允许 AI 根据上下文不执行吗？” 若答案是“不允许”，使用强制型；若答案是“要看情况”，使用解释型。

原则四这方面，步骤优先于目标

为什么步骤更好？老实说，

从目标式提示来看。帮使用者完成报销流程

• AI 每次自行设计流程时可能产生随机性；步骤顺序难以保证一致性， 至于步骤式提示。1. 收集使用者信息 2. 调用 `uploadExpenseDoc` 上传凭证 ...

Pain Point:

> 步骤式写法的5个要素 < / h4>>

1. 有序编号 : 明确顺序。< / li ... etc

Given time constraints I'll stop here.

---