服务器半夜挂了没人知道？我用 Doubao-Seed-Evolving 写了个监控

我自己手上长期跑着几个网站，YesApi 官网、YesDev 官网，还有平时常逛的稀土掘金。前阵子有个朋友的站点半夜挂了，第二天上班才知道，丢了一晚上表单数据。这种事只要发生一次，就会开始想：能不能有个东西替我盯着，出事第一时间喊我。

市面上的 UptimeRobot 免费版额度紧、付费版按年收，对只想盯三五个站的人来说有点重。我那段时间正好在用 Doubao-Seed-Evolving 做一系列复刻实验——它最让我感兴趣的一点是：能从一个自然语言需求直接产出可运行的代码，而且能跟着我多轮改、不丢上下文。我就冒出一个念头：与其花钱买一个监控 SaaS，不如让它给我写一个，跑通了再顺手沉淀成产品能力。

先交代模型背景。Doubao-Seed-Evolving 是字节跳动面向复杂工程任务推出的模型，8 月 3 日刚完成第二次升级，重点强化了 Coding 工程能力、Agent 检索能力和幻觉控制能力。我这次想验证的正是它的 Coding 工程能力：一个自然语言需求，能不能直接变成「能跑、能告警、能调度」的真实工具。

我没自己从头敲代码。我的做法是先把需求边界想清楚，再交给 Doubao-Seed-Evolving 实现——监控谁、怎么算异常、出事往哪发通知，这三件事必须由人定，模型只是按边界施工。

下面这段是我发给它的完整提示词（已精简，原意一字未改）：

帮我写一个 Python 监控脚本 monitor.py（用 requests，Py3.10+ 可直接运行，带中文注释）：
1. 读同目录 targets.json（JSON 数组），每项含 name、url、timeout（秒）。
2. 逐个发 HTTP GET，记录：是否可达、状态码、响应耗时。
3. 异常判定（任一即异常）：不可达 / 状态码>=400 / 耗时>timeout。
4. 异常且配了飞书时，发 markdown 告警，正文须含"告警"二字（过关键词校验），含名称、URL、错误原因、时间；未配则跳过只打印。
   飞书地址优先读 config.json 的 feishu_webhook，缺失则只打印控制台日志。
5. 正常/异常都打印一行带时间戳的日志。
6. 末尾附运行示例，并说明：需同目录 config.json（含 feishu_webhook）和 targets.json。

它返回的不是一个片段，而是一个完整可运行的 monitor.py。拆开看，这次 Doubao-Seed-Evolving 在 coding 上的表现有几个值得说的点（不吹，就事论事）：

• 整条链路一次写齐，没有缺环。 配置读取、HTTP 探测、异常判定、飞书告警、控制台日志、退出码，六件事在一个文件里闭环，不是写完 requests.get 就交差的「框架 Demo」。
• 异常分支覆盖得全。 它把网络请求会出的几种失败类型分开了：Timeout（超时）、ConnectionError（连不上）、通用 RequestException（其他）。这说明它理解真实网络环境里有多种挂法，而不是只写 happy path。
• 配置和代码分离。 监控目标放 targets.json、飞书地址放 config.json，脚本本身不写死任何业务数据。
• 工程化意识在线。 函数带类型注解、带中文注释，末尾还附了运行示例和 crontab 定时样例。

AI 负责把第一版造出来，人负责判断它造得对不对、值不值得留。

我故意设计了五组目标，覆盖三种情况：正常、超时、彻底连不上。前三个是真实要盯的站点，后两个是制造异常的演示目标，用来验证告警真的会响。

• YesApi 官网、YesDev 官网、稀土掘金：预期全部正常返回 200。
• https://httpbin.org/delay/8，超时阈值设 5 秒：预期触发超时。
• 一个根本不存在的域名：预期触发连接失败。

终端跑出来的结果跟预期完全一致，三个正常、两个异常。这一步的意义不只是验证功能。它证明 Doubao-Seed-Evolving 生成的代码不是 Demo 级玩具，是能处理真实网络异常、能区分不同失败类型的。

监控逻辑对了，但飞书一条消息都没收到，后台报错「Key Words Not Found」。

我第一反应是提示词里让模型把「告警」二字放在 markdown 加粗里，可能飞书的关键词校验只认纯文本。于是让模型把「告警」挪到正文第一行。重跑，还是失败。

这才往根因上想：问题不在代码格式，是飞书机器人对 markdown 类型消息的关键词校验在这台机器人上不稳定。换成 text 类型、关键词改成「监控」之后，测试消息立刻成功。

这个插曲比一次跑通更有价值。它说明的是同一个事实的不同两面：一方面，Doubao-Seed-Evolving 能在我把根因讲清楚后，立刻给出一个修正版本——把关键词挪到正文第一行、同步改 title、去掉加粗包裹，一版就改到了位，没有反复扯皮；另一方面，第三方平台的安全规则、兼容细节，模型第一次生成时往往踩不中，得靠人来定位根因。也就是说，模型负责把「已知问题」快速修好，人负责「发现问题是哪个问题」。

手动能跑之后，我把它挂进 Windows 计划任务，想让它每五分钟自动跑一次。结果日志里报 gbk codec can't encode character。

根因很明确：Windows 计划任务调起的控制台默认是 GBK 编码，而我脚本日志里用了两个 emoji。手动在终端跑时环境是 UTF-8 没事，一进计划任务就崩。

修法也简单：bat 入口里加一句 chcp 65001 强制 UTF-8，再把 emoji 换成 [正常] 和 [异常] 纯文字。两处都改完，定时任务跑得干干净净。

脚本能跑通不算完，能一直跑、出事能喊你，才算真正在岗。

跑通之后，我顺手列了几个能加但不必一次做满的点，给后来的人留扩展空间：

• 告警通道从飞书扩到邮件、企业微信、钉钉，不同通道用不同关键词策略。
• 告警分级：P0 打电话、P1 发飞书、P2 发邮件，按严重程度分流。
• 历史可用率统计：把每次探测结果落库，生成七天、三十天可用率曲线。

这些都不是模型能替你拍板的，它们属于「这个工具将来怎么长」的产品判断，恰好是人该补上的部分。

脚本在我电脑上跑着，我没有停在「能跑就行」。我手头在用的 YesApi Pro 是一个企业级 API 低代码开发与接口开放平台，我就想：这个监控能力能不能变成它上面的一个接口，让更多人不用写脚本也能用？

于是把 monitor.py 里的探测逻辑抽象成一个 HTTP 健康检查接口，参数就是 url + timeout + expected_status，返回 status_code、elapsed_ms、is_error。再往上叠告警规则、调度、历史可用率，它就成了一个替代 UptimeRobot 的轻量级监控能力，而且国内飞书、企微、钉钉告警原生支持，比海外 SaaS 更贴合国内团队。

这不是为了写个 Demo 而写 Demo，是把一次个人实践沉淀成可以复用的产品能力。

回头看，整个过程 Doubao-Seed-Evolving 负责了从零到一的代码生成、以及后续 Debug 时的快速改版——它真正的强项不是「一次写对」，而是能接住一个自然语言需求、产出完整可运行工程，还能跟着我多轮修正不丢上下文。我负责的是前面的需求边界、中间的踩坑定位、后面的部署和产品化判断。两者缺一个，这件事都到不了「真在跑、真在告警」这一步。

最好的 AI 实践不是炫技，是跑通之后还能沉淀成别人能复用的能力。