canary

canary 技能概览

canary 技能用于部署后监控，适合你在应用上线后确认线上行为是否仍然正常。它会监测生产环境中的控制台错误、页面失败和性能回退，并将当前行为与部署前基线进行对比。如果你需要的是一个 canary 技能，关注的是实际用户可见风险，而不是依赖静态提示词，这套方案就是为发布后的监控而设计的。

canary 适合做什么

当你的任务是监控一次发布、捕捉页面损坏，或确认新版本没有引入可见回退时，使用 canary。它尤其适合那些希望用 canary 进行 Monitoring，并同时覆盖控制台、截图和页面级失败的团队。

canary 为什么不同于通用提示词

通用的“检查一下网站”提示词，通常只会停留在表层审查。canary 是围绕监控流程设计的：在部署后运行、随时间观察线上行为、与基线对比，并标记异常。这让它更适合回答“生产环境现在是否健康？”而不是“这个页面看起来一次性是否还行？”

最佳适用场景与限制

这个技能适合 CI 邻近或运维/值守式的工作流，尤其是在部署后需要确认稳定性时。它不太适合只做一次性的内容审查、设计点评，或不需要持续监控的人工 QA 清单。它最大的落地门槛通常是上下文：canary 最好在你能明确指向正确的线上目标，并定义“正常”应该是什么样时使用。

如何使用 canary 技能

canary 的安装与设置

按照仓库里展示的 gstack skills 流程安装 canary，然后先阅读 SKILL.md 和 SKILL.md.tmpl。这个技能没有额外的支持文件夹，所以核心安装上下文都在这两个文件里。如果你要把 canary 指南接到自己的仓库里，提示词里一定要明确生产环境 URL、部署事件和基线来源。

首次提示词要提供什么

给 canary 的信息越少越好，但前提是这些信息足以让监控有意义：

• 要监控的应用或路由
• 这次部署改了什么
• 发布前什么表现算“正常”
• 什么情况算失败
• 观察多久
  一个弱提示词只会说“监控这个应用”。更强的提示词会写成：“观察今天部署后的 /checkout，把截图与发布前基线对比，并在 10 分钟内标记新的控制台错误、坏掉的按钮或布局偏移。”

canary 的建议使用流程

先从部署时点入手，再从基线走到观察，最后给出结论。先确认目标分支或环境，再定义基线行为，然后要求它做线上检查并报告异常。如果你在交互式使用这个技能，最重要的早期决定是：你要的是主动监控，还是一次性验证，因为这会决定技能该如何组织检查方式。

优先阅读哪些文件

先读 SKILL.md，再读 SKILL.md.tmpl，这样可以理解这个技能是如何生成的，以及哪些部分承担工作流逻辑。特别要注意 preamble、plan mode 安全性、plan mode 期间的 skill 调用，以及 routing 相关章节。这些内容最可能影响 canary 是否能正确触发，并在正确的时间运行。

canary 技能 FAQ

canary 只适合生产环境监控吗？

不是。它是为部署后的 canary 检查设计的，所以生产环境当然是最典型的场景，但同样的模式也适用于 staging，或者任何你希望在变更后做基线对比的线上环境。

canary 和普通 QA 提示词有什么不同？

普通提示词通常只要求做一次检查。canary 更偏运维化：它要监控回归、捕捉证据，并将当前状态与历史状态对比。也正因为如此，当你需要的是用于 Monitoring 的 canary，而不是泛泛的审查时，它会更合适。

canary 对新手友好吗？

友好，只要你能说清楚部署内容、页面对象和失败条件。难点不在于会不会用这个技能，而在于你能否提供足够上下文，让它基于有意义的基线判断变化。如果你说不清改了什么，或者哪些内容必须保持稳定，输出质量就会变弱。

什么时候不该用 canary？

不要把它用于宽泛的产品分析、内容编辑，或那些不依赖线上应用健康状况的任务。没有基线、无法访问目标环境，或者部署没有清晰的通过/失败阈值时，它也不适合。

如何改进 canary 技能

给 canary 更清晰的基线

最有价值的升级，是把“正常状态”定义得更明确。加入部署前截图、已知正常的 URL、预期的控制台行为，以及任何必须保持完好的关键 UI 元素。基线越精确，技能就越不容易把无害差异误报成问题。

直接说明你关心的失败模式

当你提前点明可能的回归类型时，canary 的价值会明显提升：空白屏、API 数据缺失、导航失效、CSS 偏移、控制台错误、页面加载过慢，或者交互失败。一个知道要重点看什么的 canary 技能，产出的结果会比泛泛要求“找问题”更能直接用于决策。

第一次运行后要迭代

先用第一轮结果了解它会暴露什么，再收紧提示词。如果噪音太多，就缩小路由范围或提高异常阈值。如果漏掉了重要问题，就补充关键用户流程、预期文案或对比点。好的 canary 指南用法本来就是迭代式的：先定基线，再检查，再调整，再重跑。