RepoIntermediate

Watch：像真人一样测试你的应用、并抢在客户之前提醒你的机器人用户

在"我的代码没问题"和"我的应用对真实用户可用"之间，有一个盲区。这个缝隙里藏着上千件你的测试看不见的事：CDN 挂了、生产环境里一个变量配错了、一个改了文案的按钮把登录搞坏了、一个屏幕突然要加载 8 秒。你往往是等到客户来抱怨才知道……或者等到他一声不吭地走掉。Watch 就是来堵这个缝隙的：它是一个机器人用户，像真人一样用真实浏览器走一遍你的关键流程，在有东西出问题或变慢的那一秒就提醒你——而且不只是拉响警报：它会把出错的确切步骤、截图和修复方案一并带给你。它免费，住在 GitHub 上，下面我来告诉你什么时候用它、以及怎么把它装起来。

Jun 25, 202612 min

这是给谁的？

给任何已经上线了应用或网站、想睡个安稳觉的人——哪怕你不会写代码。如果你曾经因为一个客户给你发消息才发现自己的网站挂了，那这就是给你的。Watch 是一个机器人哨兵，它会每隔一段时间像用户一样测试你的应用，并第一个提醒你。你用自然语言配置一次，剩下的它自己搞定。

1. 那个时刻：当"测试通过了"并不等于"能用"

那个时刻，在你发现一个扎心真相的那天到来：代码"没问题"并不保证你的应用能用。你上线了，测试全绿，部署完美无缺。可即便如此，一个用户就是登不进去。怎么会？因为在你的代码和你的用户之间，隔着一大堆你仓库里任何测试都看不见的东西：服务器、网络、某个生产环境配置、一个变慢的外部 API、一个最后一刻的改动。

这就是 Watch 登场的时刻：当你明白，你需要有人从外部、像真实用户一样真真切切地测试这个应用——打开浏览器、在登录框里打字、点按钮、确认下一个屏幕加载出来。不是检查代码，而是使用应用。这叫合成监控（synthetic monitoring），而 Watch 替你来做。

这样想象一下

你的测试就像检查一栋大楼的图纸：它们确认设计是对的。Watch 则是那个真正走进去、坐电梯上楼、开门、开灯的验收员。图纸可以完美无缺，而电梯却坏了。Watch 会找到那部坏掉的电梯——因为它真的坐了。

2. 那份痛：你从客户那里才得知，而那已经太晚了

这份痛是真实而无声的。它不算戏剧化——比那更糟：它一直隐形，直到开始让你流失用户。症状是这样的：

没有哨兵时会发生什么

登录在凌晨 3 点坏了，而你早上 9 点才知道——就在第一封愤怒客户的邮件到来时。

一个文案改动（"登录" → "进入"）在没人察觉的情况下弄坏了一条自动化流程。

一个屏幕开始要加载 8 秒；用户不抱怨，他们只是默默走掉。

一个外部 API 挂了，半个应用瘫痪，但你的监控只盯着"服务器是否响应"（而它确实在响应……响应的是一个坏掉的页面）。

根本问题在于：传统监控只检查"服务器还活着吗？"。可一个服务器可以活得好好的，却在提供一个坏掉的页面。要知道你的应用能不能用，唯一的办法就是有人去用它。而如果那个"有人"永远是发现故障的真实客户，你就已经输了。

隐藏的成本

一个撞上你坏掉应用的用户，很少会告诉你。他直接走了。每有一个客户抱怨，就有几十个只是关掉标签页、再也不回来。一条坏掉流程的损失，不是用支持工单来衡量的——它是用你失去的、且永远不知道为什么失去的那些人来衡量的。

3. 那个习惯：巡查是持续的，而不是一次性的检查

这里就是改变你行为的地方：Watch 不是你上线前跑一次的测试。它是一趟不断重复的巡逻。你告诉它每隔一段时间（比如每 15-30 分钟）巡查你的关键流程，并把每一趟和上一趟做对比。昨天 2 秒能跑完、今天却要 8 秒的，它会发现。昨天能通过、今天却失败的，它会发现。

那些永远值得巡查的流程（一旦坏了，你就会流失金钱或用户的那些）：

这个习惯要盯的关键流程

养活你的那条流程——用户专程来做的那件事（创建点什么、发布、购买）。

结账 / 支付——一旦坏了，你会悄无声息地损失收入。

Watch 的差异化

和 Sentinel 一样，Watch 不会停在"流程失败了，祝你好运"。它会告诉你哪个步骤失败了，给你那个确切时刻的截图，并向你提议修复方案。真实的例子："第 4 步（点击"登录"）失败了，因为按钮现在叫"进入" → 改一下期望的文案，一行搞定"。不只是警报：还有原因和解药。

4. 它怎么工作，拆成 3 个简单部件

不用懂代码也能明白。Watch 分三步干活：

1) 你把流程描述一次。在一个简单的文件里（flows.json）你列出关键路径："打开 /login，输入邮箱，输入密码，点击登录，确认到达面板"。这里面不写真实密码——用的是安全变量。

2) Watch 像用户一样走一遍。它用 agent-browser（一个由 AI 控制的真实浏览器）来做的正是这件事：打开、输入、点击、等待、查看。它测量每一步花多久，并抓取屏幕截图。

3) 和上一次一切正常时做对比。一个以前能用的步骤现在失败了？一条以前 2 秒的流程现在要 8 秒？它只提醒你真正变了的东西——不会拿同一个警报刷屏一百遍。

引擎：agent-browser，不是魔法

Watch 依托 agent-browser——一个真实的工具，它给 AI 一个货真价实的浏览器，让它像人一样浏览（不是 Playwright，不是外部付费服务）。如果你已经看过 agent-browser 那篇资源，这就是那份能力，被拿来 24/7 巡查你的应用。

5. 怎么安装：一条命令

Watch 是一个 Claude Code 的 skill。一条命令就装好，它需要 agent-browser 作为浏览器引擎：

bash

/plugin marketplace add MentexDev/neuralos-watch
/plugin install neuralos-watch@neuralos-watch

# El motor del navegador (una vez):
npm i -g agent-browser && agent-browser install

用别的助手？它也能配合 npx skills add MentexDev/neuralos-watch 使用。然后你复制那个流程示例文件，改成适配你的应用，再像平常一样跟你的 AI 说话就行。

最省事的：用大白话跟它讲

装好之后，你对你的 AI 说："在我的应用上跑一遍 Watch，告诉我有没有东西坏了"，或者"我的登录和结账还正常吗？"。而要做周期性巡查，你用一个例程（/schedule）把它排上程，让它每隔一段时间自己跑。说句老实话：它不是一个永远自己跑下去的魔法服务——它是你的智能体，在你决定的时间表上，执行你的流程。

6. 拿来即用的 prompt

这里给你从头到尾一整套。把它粘进你的智能体（Watch 已装好的前提下），填好 [方括号] 里的内容，让这位哨兵去巡逻：

用 Watch 巡查我应用的健康状况text

我想让你用 neuralos-watch 这个 skill 来检查我关键流程的健康状况，采用只读（read-only）且非破坏性的模式（不要删除数据，也不要真的下单购买）。

我应用的 URL（指向 staging/测试环境，不要指向有客户数据的生产环境）：[https://staging.miapp.com]
要巡查的关键流程：[例如 1) 首页能加载 · 2) 用邮箱+密码登录 → 到达面板 · 3) 创建一个新项目]
测试凭据：使用环境变量 [WATCH_TEST_EMAIL / WATCH_TEST_PASSWORD]，绝不要在这里写死密码。

遵循 Watch 的流程：如果我还没有 flows.json，帮我把它定义出来，用 agent-browser 走一遍每条流程，测量耗时，然后给我一份报告。对每个问题：出错的确切步骤、截图、期望的是什么 vs 你实际遇到的是什么，以及提议的修复方案。同时也标出虽然没坏但变慢了的地方。

如果是第一次运行，就建立基线（baseline，先别对比）。除非某个步骤被明确标记为安全且在沙盒中，否则不要执行任何破坏性或支付相关的步骤。