1. 项目概述当“吃自己的狗粮”变成一项自动化任务作为一名独立开发者我猜你和我一样都信奉“吃自己的狗粮”这条黄金法则。道理我们都懂深度使用自己的产品才能像用户一样发现那些藏在角落里的Bug感受那些令人皱眉的交互痛点。但现实往往是在项目启动初期我们热情高涨恨不得把产品当饭吃一旦进入密集开发期我们与产品的互动就只剩下“开发者模式”——我们只走“正确”的路径只测“预期”的流程。“它能跑起来”成了唯一标准而那些粗糙的用户体验、诡异的边界情况就这么悄悄溜进了生产环境。我独自维护着一个名为KaizenLab的Web应用一个用于产品假设验证和知识沉淀的工具。几周前我突然意识到一个可怕的事实我已经很久没有像一个真正的、一无所知的用户那样打开自己的产品了。我一直在疯狂地推送新功能修复已知问题但我对产品的“体感”正在迅速钝化。我知道所有按钮该点哪里所有API该怎么调这让我几乎不可能发现那些只有新用户才会踩进去的坑。于是我做了一件听起来有点疯狂的事我把“吃狗粮”这个任务外包给了一个AI智能体。现在每三个小时这个AI就会像一个挑剔的、不知疲倦的用户一样打开我的产品执行一系列检查。如果它发现任何不对劲的地方——无论是API返回了错误数据还是移动端的布局崩了甚至是新用户看到的只是一个空白的页面——它都会自动创建一个Git分支尝试修复运行测试并为我提交一个Pull Request。这听起来像是科幻情节但背后的逻辑其实非常务实将那些重复、枯燥但至关重要的质量检查工作自动化把我自己解放出来去处理更需要人类直觉和创造力的部分。这篇文章我就来详细拆解这个系统的搭建过程、它实际抓到的那些让我后背发凉的Bug、它的能力边界以及你如何也能为自己的项目构建一个类似的“自动化质量守护环”。2. 系统架构与核心组件拆解整个系统的核心目标很明确模拟一个真实用户或开发者的周期性检查行为并将发现问题、定位问题、尝试修复的流程自动化。它不是要取代完整的测试套件而是作为一道动态的、贴近真实使用场景的补充防线。我的架构基于三个核心组件它们各司其职共同完成了这个任务。2.1 大脑AI智能体我选用ClaudeAI智能体是整个系统的决策中枢。它的角色不是一个简单的脚本执行器而是一个具备理解、推理和行动能力的“虚拟质检员”。我选择Claude主要是基于其出色的长上下文理解能力和稳定的工具调用Function Calling表现但理论上任何支持类似功能的模型如GPT-4都可以胜任。它的核心职责包括计划与决策读取我编写的Markdown格式的检查清单决定本轮检查要执行哪些任务。清单是轮换的以避免每次检查都千篇一律。执行与交互通过调用工具Tools来与我的应用交互。这包括调用内部API、控制浏览器进行UI测试、执行命令行代码检查等。分析与判断接收工具调用的结果如API响应、页面截图、命令行输出并判断其是否正常。它需要理解“数据完整性”、“响应格式正确”、“布局错乱”这些概念。修复与报告一旦确认问题它需要创建Git分支修改代码可能是修复一个CSS类也可能是更正一个导入语句运行测试确保无误最后提交Pull Request并在Discord中通知我。注意AI并非万能。它严格遵循指令但缺乏人类的“感觉”。它擅长判断“按钮是否可点击”但不擅长判断“点击这个按钮的流程是否令人烦躁”。明确它的能力边界是设计有效指令的关键。2.2 桥梁MCP服务器模型上下文协议这是让AI能够与我的应用内部状态进行深度交互的关键。默认情况下一个AI智能体只能看到你给它的文本它无法直接操作你的数据库或业务逻辑。MCP服务器本质上是一组我将应用内部API“暴露”给AI的标准接口。我创建了一个简单的Node.js服务器定义了一系列工具函数// 示例MCP服务器工具定义 const tools { list_projects: { description: “获取所有项目列表用于检查数据可访问性” handler: async () await db.project.findMany() }, create_test_record: { description: “创建一个测试记录模拟用户新增数据操作” handler: async (args) { // 参数验证逻辑 if (!args.name) throw new Error(‘记录名称必填’); return await db.record.create({ data: args }); } }, get_system_health: { description: “检查核心服务的健康状态数据库连接、缓存等” handler: async () { const [dbOk, cacheOk] await Promise.all([ checkDatabase(), checkRedis() ]); return { database: dbOk, cache: cacheOk }; } } };为什么需要MCP而不仅仅是公开的REST API语义化与安全MCP工具提供了清晰的描述description让AI理解每个函数是做什么的。同时我可以在handler内部进行严格的权限控制和参数校验避免AI进行危险操作。访问内部状态有些检查需要直接查询数据库或调用内部服务这些接口通常不会对外部公开。MCP服务器在受控环境下为AI打开了这扇门。标准化调用对于AI来说调用list_projects这个工具和调用playwright.goto(‘https://myapp.com’)在形式上是一样的简化了AI的决策逻辑。2.3 眼睛与双手PlaywrightUI测试是“吃狗粮”不可或缺的一环。用户是通过浏览器与产品交互的因此任何自动化检查都必须包含真实的浏览器环境。我选择了Playwright而非Cypress或Selenium主要基于以下几点考量选型理由多浏览器支持Playwright对Chromium、Firefox、WebKit的原生支持非常出色我可以轻松让AI检查跨浏览器的表现。自动等待与可靠性它的自动等待元素可交互机制减少了测试脚本中的“硬编码”等待sleep使得AI生成的测试脚本更健壮。丰富的截图与录制能力当AI发现UI异常时它可以命令Playwright对异常区域、整个视口或特定元素进行截图并将图片作为证据附在PR描述或报告里这对于诊断视觉回归问题至关重要。AI如何驱动PlaywrightAI并不直接编写Playwright脚本。相反我通过MCP服务器暴露了几个高阶的Playwright操作工具例如open_browser_and_goto(url): 打开浏览器并导航到指定页面。check_viewport(viewport): 将视口调整为特定尺寸如375x667模拟手机检查布局。find_and_click(selector): 查找并点击元素模拟用户操作。take_screenshot_of_element(selector): 对特定元素截图。AI根据检查清单如“检查移动端视口”组合调用这些工具完成复杂的UI流测试。这比让AI直接生成原始Playwright代码更可控、更安全。3. 检查清单设计与执行流程系统的“智慧”很大程度上来源于我为其设计的检查清单。这份清单不是一个死板的脚本而是一个动态的、可轮换的“任务池”指导AI在每次检查中关注不同的方面。我的清单是一个Markdown文件结构如下# 每3小时质量检查清单轮换执行 ## 本轮API检查选2项 - [ ] 调用 list_projects验证返回数组结构并检查首个项目的createdAt字段是否为合理日期。 - [ ] 调用 get_canvas 并传入一个已知存在的画布ID验证响应中包含所有必需的区块blocks数据。 - [ ] 调用 get_verification_status确保没有长期处于error状态的验证任务超过24小时。 ## 本轮UI检查全部执行 - [ ] **主流程冒烟测试**打开生产环境首页登录使用测试账号导航至仪表盘确保核心数据图表加载。 - [ ] **移动端响应式检查**将视口切换至375px宽度遍历主导航项确保无水平滚动条所有按钮触控区域不小于44x44px。 - [ ] **深色模式一致性**启用深色模式主题检查所有文本颜色对比度是否达标图片是否有异常白色边框。 - [ ] **空状态用户体验**使用一个全新的测试账号登录访问项目列表页和画布页检查是否显示友好的引导文案和创建按钮而非空白或错误。 ## 本轮代码健康度检查选1项 - [ ] 在项目根目录运行 npm run type-check即tsc --noEmit报告任何新的TypeScript错误。 - [ ] 对最近3次提交中修改过的文件运行 eslint --fix-dry-run检查是否有可自动修复的代码风格问题。 - [ ] 使用 depcheck 工具扫描报告是否存在未在package.json中声明的依赖引用。 ## 问题处理协议 当发现任何问题时按以下步骤操作 1. **创建分支**基于main分支创建新分支命名格式为 fix/auto-{日期}-{问题简述}。 2. **实施修复**修改代码。如果是CSS问题直接调整样式表如果是逻辑错误修正业务代码。 3. **验证测试**运行 npm test即vitest run。**必须所有测试通过才能继续**。 4. **提交与推送**提交更改推送到远程仓库。 5. **发起拉取请求**创建PR标题清晰描述问题如“Fix: mobile layout overflow on project card”在描述中附上AI发现问题的上下文和截图。 6. **通知**将PR链接发送到指定的Discord频道。执行流程详解定时触发系统通过GitHub Actions的cron任务每3小时触发一次。你也可以用任何云函数或服务器上的cronjob。清单解析AI智能体启动读取最新的检查清单Markdown文件。它会根据“轮换”指示从每个类别中选择本次要执行的项目形成本次检查的具体任务列表。顺序执行AI按顺序执行任务。对于API检查它调用对应的MCP工具对于UI检查它通过Playwright工具控制浏览器。结果判定AI收到每个工具调用的结果后会进行分析。例如对于list_projects它会检查返回的是否是数组、数组是否为空在某些情况下空数组是正常的、数据字段是否完整。问题处理一旦判定为“异常”AI立即转入问题处理协议。它不会在检查完所有项目后再处理而是发现一个处理一个确保问题能被及时隔离和修复。报告生成无论是否发现问题AI都会生成一份简短的执行报告记录检查项、结果状态和耗时并发送到日志系统。这个设计的关键在于平衡覆盖度与执行时间。每次检查不可能遍历所有功能但通过轮换机制在一天内核心功能都能被覆盖多次。UI检查相对耗时所以被设计为每次必做以确保前端体验的持续稳定。4. 实战案例AI抓到了哪些人类会忽略的Bug理论说再多也不如实际案例有说服力。下面是我印象最深的三个由AI智能体发现的Bug每一个都揭示了我手动测试或传统单元测试中的盲区。4.1 Bug 1API与UI的数据源不同步现象AI在例行调用create_item_via_api工具创建一条测试数据后紧接着通过UI检查工具去页面上查找这条数据发现怎么也找不到。然而API的创建接口返回了“成功”和完整的数据对象。根因分析经过AI提交的PR中的代码diff我震惊地发现问题出在数据存储层。我的应用里Item项目条目这个概念的数据竟然被存储在了两个不同的数据库表里items表和item_summaries表。创建逻辑是这样的API路径当通过API创建时后端服务只向items表插入了数据。负责更新item_summaries表的异步处理函数因为一个条件判断错误被意外跳过了。UI路径当用户在网页上点击“创建”按钮时前端发起的请求会触发一个不同的服务端流程这个流程会同时向两个表写入数据。为什么人类测试者会错过它非常简单因为作为开发者的我以及我邀请的内部测试者从来都只通过UI界面来创建数据。我们本能地点击那个绿色的“新建”按钮。那个“仅通过API创建”的路径在真实用户场景中几乎不存在除非有第三方集成因此它在手动测试中被完全遗漏了。但AI严格遵循指令它既会调用API也会检查UI这种跨路径的验证立刻暴露了不一致。修复统一数据创建入口确保无论通过API还是UI都走同一套包含完整副作用的业务逻辑。AI提交的PR修复了那个条件判断错误。4.2 Bug 2移动端特定视口下的布局崩溃现象AI在执行“移动端响应式检查”时对项目卡片列表页面进行了截图。通过图像分析我后来为AI集成了简单的截图对比库它发现当视口宽度为375pxiPhone SE尺寸时卡片内的“标签”和“操作按钮”区域发生了水平溢出出现了横向滚动条。根因分析问题出在一个Tailwind CSS的类上。在桌面端为了美观我使用了grid-cols-2两列网格来排列标签和按钮。但我忘记为这个网格容器添加响应式前缀。在移动端空间不足两列布局导致内容被挤压、溢出。为什么人类测试者会错过它响应式测试是前端开发中最繁琐且容易遗漏的环节之一。开发者通常在Chrome DevTools中切换几个主流设备尺寸看看但很难覆盖所有可能的视口尤其是那些极端的小尺寸。AI则可以毫无怨言地、精确地切换到任何我指定的视口进行检查。我将这个检查项设为“每次必做”就相当于雇佣了一个不知疲倦的QA专门盯着小屏幕用户会不会遇到问题。修复AI提交的PR将CSS类修改为grid-cols-1 md:grid-cols-2。意思是默认单列排列在中等尺寸md及以上屏幕才变为两列。一个字符的改动解决了移动端用户的糟糕体验。4.3 Bug 3新用户面对的“友好的空白”现象AI使用一个全新的测试账号登录后访问“我的画布”页面。Playwright截图显示页面内容区域一片空白没有错误信息但也没有任何引导性文字或操作按钮。AI将其标记为“UX问题空状态缺失可能导致用户困惑”。根因分析这不是一个功能性的Bug。API返回了空数组前端也正确地渲染了这个空数组——结果就是什么都不显示。对于老用户有数据时这里会显示列表但对于新用户这里本该有一个设计好的“空状态”组件上面写着“你还没有画布”并配有一个醒目的“创建第一个画布”按钮。我在设计时构思过这个组件但在开发优先级排序中它被遗忘了。为什么人类测试者会错过它因为测试者包括我自己的大脑里有上下文。我们登录的是充满测试数据的老账号我们“知道”这个页面应该显示什么。我们很少会特意、频繁地使用一个纯净的新账号去走一遍完整的新用户流程。AI没有上下文它严格执行指令“检查空状态”。它发现页面是空的但根据产品设计规范我在指令中简要描述了空的时候应该显示引导内容。于是它报告了这个问题。修复这超出了AI自动修复的范围涉及设计和组件创建。AI在PR描述中详细说明了问题并建议创建EmptyState组件。我根据这个提示自己实现了该组件。这个案例完美说明了AI在确保产品符合设计意图方面的价值而不仅仅是检查功能是否崩溃。5. 能力边界与互补系统引入Sentry监控在运行这个“AI狗粮员”几周后我意识到它虽然强大但并非全能。它本质上是一个主动探测系统它按照预设的剧本去检查产品是否按预期工作。然而有些Bug是“害羞”的它们只在非常特定的、难以预测的条件下出现一个组件只在用户快速连续点击某个按钮两次且网络稍有延迟时才会崩溃。一个第三方库的导入错误只在特定的路由懒加载组合下才会触发。一个内存泄漏需要应用运行数天后在特定的用户操作序列下才会显现。这些Bug靠每3小时一次的主动探测捕获概率极低。它们通常首先在生产环境的错误监控系统中露出马脚。因此我引入了第二个反馈环Sentry应用性能监控。5.1 双环系统的构建现在我的质量保障体系由两个互补的循环构成循环检查频率核心目标能发现的问题类型盲点AI Dogfooding (主动探测)每3小时产品是否可用、易用UI布局错乱、交互流程中断、数据不一致、空状态缺失、视觉回归、移动端适配问题。生产环境独有的、低频率的、非用户路径触发的运行时错误。Sentry Monitoring (被动监控)实时产品是否稳定、可靠未捕获的JavaScript异常、API接口5xx错误、性能瓶颈慢API、长任务、崩溃报告。功能正常但体验糟糕的问题如 confusing UX、未导致错误响应的逻辑错误。它们如何协同工作AI Dogfooding Loop像一个严格的内部用户不断尝试使用产品确保主流程畅通体验达标。它回答的问题是“如果我们公司新来一个员工他能不能顺利地用这个工具完成工作”Sentry Monitoring Loop像一个24/7值班的急诊室医生监控着生产环境应用的生命体征。它回答的问题是“现在正在使用我们产品的真实用户有没有人正在遭遇崩溃或错误”5.2 从监控到自动修复的进化引入Sentry后AI智能体的职责得到了史诗级扩展。它不再仅仅是一个主动的检查者还成为了一个被动的响应者。我建立了一个新的工作流定期巡检SentryAI智能体除了每3小时做一次主动狗粮测试还会每1小时检查一次Sentry的接口获取“未解决”Unresolved且“高频”例如24小时内发生5次的错误事件。错误分析与定位对于抓取到的错误AI会获得完整的错误信息、堆栈跟踪、用户浏览器信息、以及Sentry捕获的上下文如请求参数、用户ID、Redux状态快照等。AI会分析堆栈跟踪定位到源代码中的具体文件和行数。尝试自动修复如果错误看起来是“简单且安全”的——例如一个明确的“Cannot read property ‘name’ of undefined”错误指向某行代码中缺少空值判断——AI会尝试生成修复代码如添加可选链操作符?.或空值合并运算符??。安全验证与提交和之前一样AI会在独立分支上修改代码运行完整的测试套件。只有测试全部通过它才会创建PR。对于更复杂的错误如果AI无法确定修复方案它会在PR描述中详细分析错误上下文并我进行人工处理。一个经典的成功案例Sentry报告了一个路由懒加载导致的页面崩溃错误信息是“Module not found”。堆栈跟踪指向一个动态导入语句import(‘./SomeComponent’)。AI分析发现在最近的代码重构中SomeComponent.vue文件被移动到了子目录但这条导入语句的路径没有更新。AI生成了修复更新导入路径运行测试通过并自动提交了PR。从错误发生到修复代码合并全程无人干预耗时不到15分钟。这个结合了主动探测Dogfooding和被动监控Sentry的双环系统让“质量保障”从一个离散的、人工驱动的任务转变为一个持续的、自动化的“维护循环”。它不仅能发现问题还能在相当程度上自动解决问题。6. 构建你自己的自动化质量守护环你不需要完全照搬我的技术栈Claude MCP Playwright Sentry。关键在于理解核心模式并从最小可行版本开始。以下是你可以采取的步骤6.1 第一步选择一个调度执行器你需要一个能定时运行脚本的东西。最简单如果你项目托管在GitHub直接用GitHub Actions的cron定时任务。这是零成本、易配置的起点。更灵活使用云函数如AWS Lambda、Google Cloud Functions或Vercel/Netlify的定时任务。它们可以运行更长时间、更复杂的任务。传统可靠在你自己的服务器上设置一个crontab。6.2 第二步暴露一个“健康检查”端点不要一开始就想搞复杂的UI测试。先从最核心的开始你的应用还活着吗在你的后端创建一个API端点例如GET /api/health。让它检查关键依赖数据库连接是否正常缓存服务是否可达必要的第三方API是否响应返回一个结构化的JSON包含各项检查的状态和详情。6.3 第三步创建一个最简单的AI检查脚本用一个简单的Node.js/Python脚本配合OpenAI或Anthropic的API。脚本调用你的/api/health端点。将返回结果和检查指令一起发送给AI例如“请分析这个健康检查结果判断服务是否健康。如果不健康请描述问题。”。让AI输出判断结果。如果失败通过邮件、Slack或Discord通知你。初始指令示例你是一个系统监控助手。请分析以下健康检查报告。如果所有status字段均为healthy则回复“一切正常”。否则请指出不健康的组件及其message并建议可能的排查方向。 报告 { “database”: { “status”: “healthy”, “message”: “Connection OK” }, “redis”: { “status”: “unhealthy”, “message”: “Connection timeout” }, “external_api”: { “status”: “healthy”, “message”: “Response time 120ms” } }6.4 第四步逐步扩展检查范围在基础健康检查稳定运行后开始迭代添加业务API检查像我的list_projects一样暴露一些只读的核心业务API给AI调用检查数据完整性。引入简单的UI检查集成Playwright。开始时只做一件事打开首页截图让AI判断页面是否大体加载正常有无巨大错误提示、布局是否严重错位。定义你的检查清单根据你的产品特点在Markdown文件中列出最重要的检查项。优先覆盖用户核心路径和最近修改过的模块。连接错误监控集成Sentry或类似的错误追踪服务。让AI定期去获取错误列表并尝试分析归类。6.5 关键经验与避坑指南在搭建和运行这套系统的过程中我积累了一些血泪教训希望能帮你少走弯路1. 信任但要验证用测试套件作为守门员AI有时会“幻觉”hallucinate它可能自信地告诉你问题已修复但实际上代码引入了新错误。绝对不要依赖AI的自我报告作为合并代码的唯一标准。我的铁律是任何由AI修改的代码在创建PR前必须通过完整的自动化测试套件npm test。如果测试失败AI不能提交PR而必须将失败报告给我。这极大地减少了误报和错误修复。2. 权限最小化原则通过MCP服务器暴露给AI的工具必须遵循最小权限原则。不要给它DROP TABLE的权限。大部分工具应该是只读的GET操作。对于写操作如创建测试数据要创建专用的、隔离的测试账号或测试数据库并且工具内部要有严格的参数校验和边界控制。3. 指令的清晰度就是系统的天花板AI的表现与你给它的指令清晰度直接相关。避免模糊的指令如“检查一下页面有没有问题”。要像给实习生写任务清单一样具体差“检查登录功能。”优“使用测试账号testexample.com和密码123456在登录页面执行登录操作。验证1. 登录成功后页面跳转到/dashboard。2. 页面顶部导航栏显示用户名‘Test User’。3. 控制台无JavaScript错误。”4. 接受不完美明确边界这个系统不是银弹。它擅长发现客观的、可重复的问题布局崩了、接口报500、控制台有错误。它不擅长判断主观的、体验性的问题这个配色舒服吗这个流程顺滑吗这个文案清晰吗。不要试图让它做所有事情。用它来承担重复的、枯燥的检查工作把你自己的时间节省下来去做那些真正需要人类同理心和创造力的深度体验与用户交流。5. 从“成本中心”到“效率引擎”的思维转变搭建和维护这套系统需要初期投入。你需要写MCP工具、设计检查清单、处理误报。但请把它看作是对“未来自己”的时间投资。它每自动捕获一个Bug就是为你节省了一次深夜被用户投诉吵醒、或者一次手忙脚乱的线上故障排查。它让你能更安心地交付代码更频繁地进行发布。7. 总结与展望让机器操心让人专注回过头看这个项目的核心价值不在于我用了多酷的AI技术而在于我通过自动化解决了一个经典的生产力问题如何将重要的、但非紧急的、重复性的纪律性任务从依赖个人意志力转变为依赖系统可靠性。“吃自己的狗粮”很重要但它反人性因为它总是在与更紧急的开发任务、产品规划、用户支持争夺你有限的注意力。将其自动化后它变成了一个后台进程一个沉默的守护者。我不再需要“记得”去测试移动端布局系统会每三小时替我检查一次。我不再担心某个不起眼的API路径因为无人使用而悄悄坏掉系统会定期去调用它。现在我的工作流变成了这样我专注于编写新功能、设计用户体验、与用户沟通。而我的“AI质检搭档”则负责在后台持续地、不知疲倦地巡逻确保我已经构建好的部分始终坚固、可用。当Sentry报警时它常常能在我还没看清错误信息之前就已经提交了一个修复PR。这不仅仅是节省时间更是创造了一种“质量安全感”。如果你也是一个独立开发者或者在一个小团队中我强烈建议你尝试构建一个类似的、哪怕是最简单的自动化检查循环。从一个健康检查端点开始从一个简单的定时脚本开始。你会发现将一部分质量保障工作委托给机器不仅能让你睡得更好还能让你有更多精力去思考那些真正能让产品变得与众不同的东西——而这些东西是目前的AI还无法替代的。
