我有个烦恼
我一直有个不小的烦恼。
在我的日常工作中，有一项工作是要监控公司线上的产品，既包括服务器，也包括客户端，必须保证所有服务24小时运转正常。服务器的监控相对比较容易，现在已经有很多成熟的自动化方案，直接用就可以。反倒是移动端的监控比较麻烦，基本上没有现成又可靠的方案。
为了解决这个问题，一开始我是靠纯人工，每天时不时地打开app看一看。为了防止忘记，我还给手机设置了自动任务，每天定时打开公司的App：
但这也不是个事！这人工检查的时间间隔，定长了起不到效果，定短了人就很容易……很烦躁！
为了让我过得轻松一点，后来我又用selenium自动化测试框架写了个服务，每隔5分钟跑一次自动化测试。效果确实不错，但也不完美，因为selenium需要基于预定的规则去执行。也就是说，你需要把所有功能拆解成详细的执行步骤，再写成代码去执行。而且这些花大力气写的测试用例，一旦产品功能迭代，大概率得重写。光是想到这维护成本，我就没什么动力写下去，毕竟我可是超级的懒~
我一直想着，等哪天整个AI，每天24小时让AI帮我巡查app，如果有事就给我发个通知，没事就不要来找我。嘿嘿，想想就开心！这不，OpenAutoGLM它来了，两眼一对，是你！没错，OpenAutoGLM就是你！你就是我一直以来要找的苦力啊！
抓个OpenAutoGLM做苦力
OpenAutoGLM是智普开源的手机自动化操作Agent。底层原理简单说，就是通过手机截屏给视觉模型，让模型理解图片后根据设定目标发出指令操作手机，反复循环，最终完成任务。
我花了一个周末的时间，对OpenAutoGLM进行二次开发，实现了对指定app定时巡查的功能：
支持通过一个yaml文件配置整个巡查过程。
支持自动巡查，自动巡查会遍历app的一级和二级页面，也可以定义最大巡查页面数量和层级深度。
支持指定具体巡查任务列表，比如指定某个页面的什么功能要达到什么状态
支持定时巡查，还可以分别配置成功和失败后，下一次巡查的间隔时间
支持巡查失败后，发送飞书通知
我已经把项目开源：https://github.com/qinxiandiqi/Open-AutoGLM
详细使用文档：https://github.com/qinxiandiqi/Open-AutoGLM/blob/main/patrol/README.md
我的案例实现效果如下：
先创建一个配置文件（在项目patrol/configs目录下提供了一些示例模板，简单选一个修改就行）
然后通过patrol的cli工具执行配置文件：
程序会按照配置文件进行巡查：
看下手机上的效果（完整过程太长，只截取了几秒钟并对视频加速。用的是智普的在线模型，模型思考的过程还是有点慢的，不过在可接受范围内）：
如果执行失败了会发送飞书通知：
怎么实现的？
说来有点出乎意外，我把整个功能完成后，才发现我没写过一行代码！
这次用的还是老搭子：Claude Code + GLM 4.7。不知道是这次的项目和功能比较简单，还是因为我使用Claude Code的姿势比较正确，总之我没写过一行代码，整个过程甚至没跟GLM红过脸，实属难得。
整个实现的过程很长，大多是循环重复的套路，我就挑一些重点的来讲。
1. 切换ClaudeCode的output-style
我要基于OpenAutoGLM进行二次开发，怎么也得先了解下它的项目架构和基本原理，对吧？我把OpenAutoGLM的仓库clone下来后，第一件事就把Claude Code的output-style切换到 Explanatory（解释）模式：
output-style，可以说是被我严重低估的功能。根据Claude Code的官方描述，它是通过屏蔽系统提示词中一些工程高效输出的约束，并添加上自己的特定的内容。也就是说，output-style修改的是Claude Code的系统提示词。
切换成Explanatory解释模式后，我能明显感觉到Claude Code的回复会变得更详细更具体。以前用默认模式，我经常要一边提问，一边在项目中找代码核对，时不时还有防止Claude Code突然地动手改代码。而使用解释模式，它会试图考虑你提出问题的意图，解释的时候还会找出具体的代码给你做说明，就好像它真的想教会你：
我之前不信邪，认为解释模式是给不熟悉编程的人用的。用了两天后，我发现真香！尤其是对完全不了解的新项目，使用这个output-style非常合适。
2. Shift+Tab，灵活切换编辑模式
Claude Code默认的编辑模式是“Ask before edits”，每次修改之前都会先询问。之前我都是在这个模式下工作，大小任务都是一股脑输入后直接回车执行，从来没有想过按“Shift+Tab”切换编辑模式。但实际上，如果在执行不同类型的任务时，手动切换下编辑模式，体验差别会很大，特别是“Plan mode”计划模式。
“Plan mode”，它会在执行之前先根据你的输入，结合当前的项目代码进行分析。如果Claude Code发现有模糊的部分，它会提示你补充输入。等你补充完输入后，它才会给出一份方案和任务表让你确认。只有你批准后，Claude Code才会开始按任务表执行。可见，这个模式非常适合实现大颗粒度的需求。
我这个项目的5个主要功能点，每一个都是手动切换到“Plan mode”去执行的，执行的效果非常稳定。反过来，如果你输入一个大需求，又没有手动切换到“Plan mode”会怎样呢？会很随机，模型会自己判断要不要创建任务表。有时候明明是一个大需求，可模型却直接草草了事。所以啊，为了稳定，还是得手动“Shift+Tab”切换下编辑模式。
当然了，“Plan mode”好是好，但也不要一次性输入一个巨大的需求，太大的需求“Plan mode”也可能处理不过来。像我的5个功能点，我都是拆成5次才逐步迭代出来。 不要一口吃成大胖子，要逐步迭代 。
还有一点也很重要， 我是在output-style的解释风格下开启的“Plan mode”，它给的方案说明会非常具体且符合人的理解习惯，阅读起来不费劲 （假装这里有个图……聊得太多忘记截图，上下文被压缩，截不了了）。不要小看这点区别，它能大幅度提高开发体验。需方案的审查过程轻松又详细，返工自然也会少很多。在Vibe Coding这件事情上，我们程序员的心情也是很重要的！
3. 代码实现后再让Claude Code解释清楚
“Plan mode”执行完后，会一次生成很多代码，要是一个一个去核对的话，也会很费劲，这时候就可以套娃了。还是用output-style的解释风格，让Claude Code把自己写的代码解释清楚。
自己写的代码自己解释，非常闭环，很完美~
大概就是以上三个技巧了。整个过程就是这套组合拳反复打，我愣是一行代码没写就做完了。
复盘一下
最后再复盘一下：
1. 用OpenAutoGLM做运维是个好场景
OpenAutoGLM做运维这套方案，我试运行了一个多小时，基本上能满足我的预期。它跟我之前使用的方案，最大的优势就是省心省事。我不需要再去写一大堆自动化测试用例，一个配置文件全部搞定，大模型自己能够判断要怎么做。我在它操作的过程中，还故意把app切到后台。这种情况下大模型也能识别出app不在前台，并尝试把app切换回来，这点让我很惊喜！它真的会像人一样尝试去解决各种意外情况，非常适合复杂环境和不确定性的场景。
如果要说这个方案还有什么顾虑点的话，那就是模型的价格还不确定。我用的智普在线模型（没钱买显卡本地部署，穷啊），在官网上没看到这模型的价格，问了客服也没回复。等明儿看看账单，要是成本太高的话，就没法落地了。
2. 温故知新，多翻翻Claude Code的文档
Claude Code功能非常多，玩法非常很多，用多小功能在特定的场景下会有buff加成。多翻翻Claude Code的官方文档，也许会有意外发现。
后续迭代
这项目目前是先满足了自己的需求，实际上还有很多优化空间，后面再找时间迭代一下（日常占位挖个坑）：
把app巡查功能分离成独立的项目。现在是临时以一个包的形式放在OpenAutoGLM项目中，实际上基本没有改动OpenAutoGLM的代码，OpenAutoGLM仅是作为底层驱动来调用而已。把功能分离成独立的项目，架构会更合理一点
把包发布到pypi上，后续可以直接pip安装后运行，不需要下载源码，方便部署。
基于同样的原理，其实在自动化测试上也大有可为。可以探索在测试场景下自动拆解需求，自动化测试的使用。
