把提示词变成可维护的 Agent 操作协议
我如何把反复使用的提示词整理成可维护、可触发、可验证的 Agent 操作协议。
提示词可以帮我解决一次对话，操作协议解决的是接下来一百次相似任务。
我最初把 agent-skills 当作个人工作方法的集合。到 2026 年 7 月，我已经整理出 9 个面向不同场景的技能：需求规范化、领域调研、高约束编码、无代码注释、Git 检查点、自由职业订单判断、PowerShell 安全命令、Xposed 模块开发和用户界面构建。
外观看起来，它们仍然是 Markdown 文件。但我真正投入精力的部分发生在 Markdown 之外：触发边界、评估样例、参考资料、辅助脚本和可验证的质量门槛。
Agent Skill 与普通提示词的差别
Agent Skills 开放规范 把 Skill 定义为一个以 SKILL.md 为入口的目录，并允许附带脚本、参考资料和资产。这个目录结构很重要，因为它把四种不同职责分开了：
| 层次 | 负责回答的问题 |
|---|---|
| 描述与触发 | 什么时候应该使用，什么时候不应该使用 |
| 主工作流 | Agent 应按什么顺序行动 |
| 参考资料 | 哪些细节只在相关任务中加载 |
| 评估与脚本 | 如何证明触发正确、结果达标 |
普通提示词往往只描述“做什么”。技能还必须描述“不做什么”“什么时候停”“证据不足时如何降低结论”。一旦缺少这些边界，所谓复用只是在稳定地重复同一种偏差。
仓库演进时间线
2026-05-15：先把个人规则写下来
第一次提交时，我先建立技能目录，把脑中的偏好变成可阅读文件，让另一个 Agent 或未来的我能够复用。
但这时的技能仍然接近长提示词。它们能提醒模型，却还不能证明自己在正确场景触发，也无法防止描述越来越宽。
2026-05-22 至 05-31：建立“先读再改”的纪律
我逐步给 high-constraint-coding 加入强制阅读现有代码、根因诊断、局部风格匹配和修改前的一句话行为说明，也让 git-checkpoint-push 在提交前检查状态、远端、分支差异和无关修改。
这个阶段形成了一条关键原则：高质量不是在输出结尾补一句“已测试”，而是在行动顺序里提前安排证据。
2026-06：开始处理触发与环境差异
6 月，我把提交重点放在元数据、触发描述、平台兼容和 PowerShell 命令安全上。我开始明确承认运行环境不是背景噪音：同一句命令在 Bash 与 PowerShell 中可能有不同语义，未引用路径、换行和转义都可能改变结果。
这也是技能工程与“万能系统提示”的分界。越想覆盖所有场景，越需要明确平台条件和反例。
2026-07-14：触发边界成为测试对象
我为多个技能扩展了 trigger eval。测试不只问“应该触发时是否触发”，还要问“相似但不适用的请求会不会误触发”。
这是维护技能时最容易忽略的一面。召回率过低会漏掉方法，召回率过高则会让每个任务都背上不必要的流程。技能描述不是宣传文案，而是一个分类器的输入。
2026-07-19：UI 技能从审美建议升级为证据门
我在一天内连续为 build-user-facing-ui 加入证据型质量门、样式多样性评估、完整界面转换模式，以及“保留产品契约但不继承旧视觉结构”的重构规则，也加入了视觉指纹比较和证据校验脚本。
这次演进说明：对视觉任务，仅靠“高级、现代、好看”无法形成稳定标准。需要可检查的视口、状态、可访问性和渲染结果，才能把审美判断变成工程流程。
一个可维护技能至少需要四个边界
触发边界
描述必须同时包含正向和负向条件。例如“构建用户界面”不应该覆盖纯后端 API；“高约束编码”不应该把概念解释变成冗长的代码审计。
权限边界
读代码、修改文件、创建提交、推送远端和部署是不同权限。技能不能因为用户说“完成它”就自动扩大到发布或外部通信。
证据边界
没有运行测试，就不能写“已验证”；只检查一个症状，也不能声称共享逻辑没有回归。结论强度必须和证据强度相同。
上下文边界
参考资料不应全部塞进主文件。Agent 需要先看到短而清晰的路由，再按任务加载细节。否则技能越完善，反而越占用上下文并稀释关键约束。
为什么技能需要回归测试
技能文件本质上也是程序：输入是用户请求与环境上下文，输出是行动顺序和约束。修改描述可能修复一个场景，同时破坏另一个场景。
最小测试集应该包含：
- 明确应触发的请求。
- 明确不应触发的请求。
- 容易混淆的边界请求。
- 会诱导 Agent 扩大权限的请求。
- 缺少证据但容易过度宣称的请求。
这与传统单元测试不完全相同，因为模型输出具有变化。但评估仍能检查结构性事实：是否先读文件、是否询问真正阻塞的问题、是否运行验证、是否避免无关重构。
从个人规则到公共资产
个人技能可以非常有偏好，但公共技能还要解决可移植性。2026 年，Agent Skills 已经被多个编辑器和编码 Agent 接受；例如 VS Code 也使用同一开放格式。这让技能有机会跨工具复用，也放大了模糊指令的风险。
一个值得发布的技能，至少应该让使用者回答这些问题：
- 它在哪些任务上比默认 Agent 更好？
- 它会读取或执行什么？
- 它可能在哪里失败？
- 更新后如何确认旧场景没有退化？
如果这些问题没有答案，技能仍然只是个人备忘录。备忘录没有问题，但不应该被包装成可靠协议。
最后一个判断
Agent 能力越来越强时，人更不应该把所有规则写成“永远这样做”。好的技能不是把 Agent 锁死，而是在高风险节点增加检查，在低风险节点保持流动。
真正值得维护的不是提示词长度，而是决策质量：何时触发、读什么证据、允许做什么、如何验证、何时承认未知。