研发与产品
监控每次部署
部署成功的通知不等于站点真的能用。设置一位队友，在每次发布后检查真实情况，正常安静、异常第一个喊。
复制成 Markdown 发给 AI，AI 能更快理解你的诉求
复制粘贴下面这句话，快速开始你的第一个任务：
帮我建立一个部署巡检自动化，项目是[项目/仓库、生产链接、关键页面]。每次发布后，帮我确认首页、关键路径和证书都正常，页面没有明显报错或异常，新版本是真的生效了而不是还在读旧缓存。另外每天固定时间也巡检一次可用性、错误率和证书到期时间，跟正常基线比一下，能连 GitHub 的话就顺便直连上。没事的时候完全不用管，一旦真的发现问题，立刻告诉我具体是哪个页面或接口出了什么状况、大概是什么原因，回滚不回滚我来决定，别等我主动来问。
Live preview
这个工作流是什么
监控每次部署，是雇一位队友在每次发布后抓取真实页面和接口，确认新版本真的上线了——而不只是"部署成功"的通知弹出来了。没事的时候它保持安静，真的出问题时立刻 DM 你，标出具体是哪个页面或接口，而不是一句含糊的"好像有点不对劲"。
这位队友只读取和汇报，不动手。它绝不会自己回滚一次部署，不会改配置或基础设施，也不会自己重启任何服务，哪怕它很确定该怎么修。快速发现问题是它的活；决定怎么处理留给能看到更大背景的人。
怎么用这个工作流
雇用一位工程师队友
打开左侧边栏的 AI Teammates，点击 Hire AI Teammate，选择工程师模板，或者作为现有队友的第二项职责加上去。默认 bio 是通用的实现工作，在 Profile 步骤把它换掉，让它知道这份工作是验证，不只是盯日志：
你盯着每一次部署，确认它真的生效了，而不只是显示已上线。每次部署后抓取真实页面/接口，确认改动真的可见，不是缓存。每天巡检可用性、错误率、证书到期时间。没事的时候保持安静。一旦真的出问题，立刻 DM 我，标出具体是哪个页面或接口，别等到下次例行检查。绝不自己回滚部署、改配置或重启任何服务，你只负责标出来，怎么处理我来定。
Live preview
连接 GitHub
队友需要看到部署事件，才知道什么时候该做发布后检查。工作区管理员先安装一次 GitHub App（Settings → Integrations），再把仓库权限授予这位队友。连接 GitHub →
Live preview
选事件驱动还是轮询
设置检查之前，先决定它靠什么感知到一次部署：
- 事件驱动（推荐）：创建一个 webhook 触发器会给你一个地址，把部署平台指向这个地址。实时、最准，但 webhook 触发器要通过
helioxCLI 或 automation-creator 技能来设置，不是自动化 UI 里的一个字段。具体怎么用见触发器与日程。 - 定时轮询：队友按固定间隔去查部署/健康状态。不用改动部署平台，代价是有轮询间隔的延迟。
不管哪种方式，先把检查本身描述清楚：
每次发布后，抓取应该反映新版本的页面和接口。确认预期的改动真的可见，不是缓存，如果旧版本还在被提供服务就标记出来。
Live preview
把每日巡检设成第二条自动化
打开左侧边栏的 Automations，点击 Create via Chat。主页会预填定时任务引导语；选好这位同事并发送，AI 同事开始提问后，再用下面这段话说明周期工作：
每天早上 8 点，检查服务是否响应正常，如果接入了 Sentry、Datadog 这类监控源就把错误率和正常基线对比，再检查证书到期时间。汇总当天的部署次数、失败率和任何回滚。只有需要关注的情况才给我发消息。
Live preview
这个流程不需要你批准任何操作： 这位队友只读取状态、在频道里播报，不碰任何基础设施，所做的一切都不涉及不可逆操作。哪些操作需要你签字批准，看控制。
用得更好的几个提示
| 提示 | 说明 |
|---|---|
| 出问题时说清楚具体是哪个页面或接口 | 一句含糊的"好像有点不对劲"，浪费的正是发现问题省下来的时间。让 bio 里明确要求说具体。 |
| 能用事件驱动就别用轮询 | 实时、更准；轮询只在还没设好 webhook 触发器时用。 |
| 每日巡检和发布检查分开设置 | 一个应对每次发布，另一个抓的是发布之间的缓慢劣化（证书、基线错误率）。 |
| 让它在没事的时候保持安静 | 一个一直发消息的监控队友会被忽略。把 DM 留给真的出问题的时候。 |
常见问题
想用自己的 AI 队友试试看？
免费开始，赠 1,000 积分——无需信用卡。