1. 那个时刻：当"测试通过了"并不等于"能用"
那个时刻，在你发现一个扎心真相的那天到来：代码"没问题"并不保证你的应用能用。你上线了，测试全绿，部署完美无缺。可即便如此，一个用户就是登不进去。怎么会？因为在你的代码和你的用户之间，隔着一大堆你仓库里任何测试都看不见的东西：服务器、网络、某个生产环境配置、一个变慢的外部 API、一个最后一刻的改动。
这就是 Watch 登场的时刻：当你明白，你需要有人从外部、像真实用户一样真真切切地测试这个应用——打开浏览器、在登录框里打字、点按钮、确认下一个屏幕加载出来。不是检查代码，而是使用应用。这叫合成监控（synthetic monitoring），而 Watch 替你来做。
2. 那份痛：你从客户那里才得知，而那已经太晚了
这份痛是真实而无声的。它不算戏剧化——比那更糟：它一直隐形，直到开始让你流失用户。症状是这样的：
- 登录在凌晨 3 点坏了，而你早上 9 点才知道——就在第一封愤怒客户的邮件到来时。
- 一个文案改动（"登录" → "进入"）在没人察觉的情况下弄坏了一条自动化流程。
- 一个屏幕开始要加载 8 秒；用户不抱怨，他们只是默默走掉。
- 一个外部 API 挂了，半个应用瘫痪，但你的监控只盯着"服务器是否响应"（而它确实在响应……响应的是一个坏掉的页面）。
根本问题在于：传统监控只检查"服务器还活着吗？"。可一个服务器可以活得好好的，却在提供一个坏掉的页面。要知道你的应用能不能用，唯一的办法就是有人去用它。而如果那个"有人"永远是发现故障的真实客户，你就已经输了。
3. 那个习惯：巡查是持续的，而不是一次性的检查
这里就是改变你行为的地方：Watch 不是你上线前跑一次的测试。它是一趟不断重复的巡逻。你告诉它每隔一段时间（比如每 15-30 分钟）巡查你的关键流程，并把每一趟和上一趟做对比。昨天 2 秒能跑完、今天却要 8 秒的，它会发现。昨天能通过、今天却失败的，它会发现。
那些永远值得巡查的流程（一旦坏了，你就会流失金钱或用户的那些）：
- 登录——如果没人能进，那你的应用对已经是客户的人来说就是挂了。
- 注册——如果没人注册，你就停止增长（还有你已经付了钱的推广活动也白花）。
- 养活你的那条流程——用户专程来做的那件事（创建点什么、发布、购买）。
- 结账 / 支付——一旦坏了，你会悄无声息地损失收入。
4. 它怎么工作，拆成 3 个简单部件
不用懂代码也能明白。Watch 分三步干活：
1) 你把流程描述一次。在一个简单的文件里（flows.json）你列出关键路径："打开 /login，输入邮箱，输入密码，点击登录，确认到达面板"。这里面不写真实密码——用的是安全变量。
2) Watch 像用户一样走一遍。它用 agent-browser（一个由 AI 控制的真实浏览器）来做的正是这件事：打开、输入、点击、等待、查看。它测量每一步花多久，并抓取屏幕截图。
3) 和上一次一切正常时做对比。一个以前能用的步骤现在失败了？一条以前 2 秒的流程现在要 8 秒？它只提醒你真正变了的东西——不会拿同一个警报刷屏一百遍。
5. 怎么安装：一条命令
Watch 是一个 Claude Code 的 skill。一条命令就装好，它需要 agent-browser 作为浏览器引擎：
/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 说话就行。
/schedule）把它排上程，让它每隔一段时间自己跑。说句老实话：它不是一个永远自己跑下去的魔法服务——它是你的智能体，在你决定的时间表上，执行你的流程。6. 拿来即用的 prompt
这里给你从头到尾一整套。把它粘进你的智能体（Watch 已装好的前提下），填好 [方括号] 里的内容，让这位哨兵去巡逻：
我想让你用 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，先别对比）。除非某个步骤被明确标记为安全且在沙盒中，否则不要执行任何破坏性或支付相关的步骤。
7. 省事的路径：谁做什么
- 在真实浏览器里一步步走你的流程，像个用户一样。
- 测量耗时、抓取屏幕截图，并检测失败的网络请求。
- 和上一趟正常运行做对比，把带修复方案的报告写给你。
- 在示例文件里描述你的关键流程（或者请 AI 帮你写出来）。
- 指向一个测试环境，而不是有真实客户数据的生产环境。
- 如果你想要周期性的自动巡查，就排上例程（/schedule）。
8. 仓库（免费、MIT、给它点个星）
Watch 是开源且免费的。如果它抢在你的用户之前提醒了你一次故障，就给它点个星：
一个机器人用户，用 agent-browser 在真实浏览器里走一遍你的关键流程，在其中某条坏掉或变慢时提醒你——附上出错步骤、截图和修复方案。默认只读。