[AI书房] 第16章 部署之后的世界：维护与更新
Claude Code完全掌握
Claude Code完全掌握
第16章 部署之后的世界：维护与更新
金京镇
部署后自动化的局限：自愈机制失效的临界点
Blender落地页部署两天后，打开网站看了一下。运转正常。一周后依然没问题。可是一个月后，滚动动画在某些移动端浏览器上开始卡住。该从哪里下手？对Claude Code说一句「帮我修好」就行了吗？
在开发阶段，Claude Code具备强大的自我检查能力。它截取屏幕截图进行比对，读取错误日志，修改代码，再次验证。这个循环实时进行，问题一出现就能立刻察觉并修复。
然而，网站部署上线之后，这条自愈循环（self-healing loop）就不再运转了。Claude Code是在本地开发环境中运行的工具，而非持续监控已部署服务器的守护程序。网站上传到Vercel之后，Claude Code的会话很可能已经结束。出了问题，既没有谁自动检测，也没有谁自动修复。
这个区别必须清楚地认识到。开发过程中，AI扮演的是「主动守护者」的角色。部署之后，AI变成了「随叫随到的维修工」。
[图16-1] 开发阶段与部署后阶段AI角色的变化
部署后可能出现的问题，性质上和开发中的bug不一样。
外部依赖变更：网站所调用的外部API响应格式可能改变，通过CDN（Content Delivery Network）托管的字体文件URL也可能失效。
浏览器更新：Chrome或Safari升级后，某些CSS属性或JavaScript API的行为可能发生变化。开发时运行得毫无问题的动画，在新版浏览器上崩溃，这种事确实会发生。
流量波动：访问量突然暴增时，图片加载可能变慢，动画帧可能出现卡顿。在本地开发环境中只有自己一个人访问，根本不会遇到这类问题。
证书与域名：SSL证书过期、域名续费遗漏等基础设施层面的问题随时可能出现。Vercel在很大程度上自动处理这些事务，但如果使用了自定义域名，域名注册续费就是用户自己的责任。
应对这些问题的基本原则是：定期亲自访问网站进行检查。在没有自动化监控工具的情况下，人眼是最可靠的监控手段。
定时执行与Webhook触发的区别
定期检查网站这件事本身，能不能自动化？有两种方式。
定时执行（scheduled execution）是按固定时间间隔重复运行特定任务的方式。比如「每天早上9点访问网站的主要页面，测量响应时间」。这种方式也叫cron job，基于时间触发。问题发生的时刻和下一次检查的时刻之间存在时间差，因此未必能第一时间发现问题。
在Claude Code中，可以用/loop命令设置简易的定时执行。比如请求「每5分钟检查一次部署状态」，它会在同一个会话内反复检查。不过这个循环只在会话保持期间有效，最长持续3天。如果需要长期监控，就得搭建独立的监控服务。
[图16-2] 定时执行的时间驱动检查流程
Webhook触发（webhook trigger）的工作方式不同。它在特定事件发生时立即发送通知或执行操作。「GitHub上有新的commit被push时，Vercel自动重新部署」就是Webhook的典型例子。它响应的不是时间，而是事件。
两种方式的区别可以这样理解。
实际工作中，两种方式会组合使用。用Webhook处理部署自动化和即时通知，用定时执行进行定期的健康检查（health check）。
Vercel本身就是使用GitHub Webhook的典型案例。Vercel在GitHub仓库上注册了Webhook，每当有新commit被push，GitHub就会通知Vercel「有新的变更」。Vercel收到信号后立即拉取代码、构建并部署。用户不需要做任何额外配置，这个流程就已经自动串联起来了。
部署前的压力测试：用多样化输入进行验证
在按下部署按钮之前，多走一个步骤，就能在很大程度上预防部署后的问题。那就是压力测试（battle test）。
假设有位开发者做了一个支付表单。在本地输入姓名、邮箱、卡号，点击提交按钮。运行正常。于是部署了。可是实际用户中，有人在邮箱栏里填了中文名字。有人在卡号栏里输入了空格。还有人按了返回键之后又点了提交。其中某一种情况触发了错误，网站卡死了。
压力测试不是「正常地」使用网站，而是「非正常地」使用。故意输入意料之外的内容，按不合逻辑的顺序点击，尝试极端的屏幕尺寸，模拟缓慢的网络环境。
可以借助Claude Code进行压力测试。
把验证步骤加入待办清单。正如前面章节提到的，Claude Code自动生成的待办清单中可以加入「网站构建完成后截图确认」这样的条目。同样的道理，也可以添加「在不同浏览器尺寸下检查渲染效果」「用空值提交表单」「模拟图片无法加载的情况」等条目。
[图16-3] 压力测试清单示例
还可以借助Chrome开发者工具（Chrome DevTools）。Claude Code能打开浏览器并直接交互，，点击按钮、填写表单、读取控制台错误。利用这个功能，可以请求「打开网站，点击所有按钮，检查控制台是否有报错」。
移动端适配检查也不能遗漏。还记得前面的案例中，用手机打开Blender网站时，由于没有做移动端优化，布局显得很别扭。如果在部署前检查清单中加入「确认在移动端视口（viewport）尺寸下布局是否正确显示」，就能提前发现这类问题。
压力测试的原则只有一条：质疑「我用着没问题，应该没事吧」这个假设。提前确认当别人以你意想不到的方式使用网站时，会发生什么。
部署工作流和工具，但不部署Agent的原则
理解了网站部署的流水线之后，自然会冒出一个念头：「能不能把AI Agent本身也部署上去，让它7×24小时运行？」
假设你用Claude Code建了一个工作流，这个工作流负责采集数据、分析数据、生成报告，整个过程已经自动化。能不能把它放到服务器上，让它在无人值守的情况下持续运行？
答案是「技术上可以，但大多数情况下不这么做更好」。
工作流和Agent之间有本质区别。工作流按照预设步骤依次执行。输入进来，按既定逻辑处理，输出结果。路径可预测。Agent不一样。它判断形势，自主决定下一步行动。同样的输入，根据上下文不同，可能做出不同的选择。
部署工作流是安全的。「每天早上从这个API拉取数据，转换成指定格式，存入数据库。」这类工作流步骤清晰，失败时容易定位问题，不会做出意外行为。
部署Agent则会带来不可预测的状况。Agent向外部API发送请求，如果响应与预期不同，Agent会做出什么判断，事先无法确定。有人在旁边时，可以审查和纠正Agent的判断；在无人环境下，一个错误判断可能引发连锁反应。
[图16-4] 工作流 vs Agent：部署适配性对比
可操作的指导原则是这样的。
应该部署的是工具和工作流。网站代码、定时数据采集脚本、API端点（endpoint）、自动化构建流水线等都属于这一类。
不宜部署的是需要判断力的Agent。分析代码并进行重构的Agent、解读用户修改意见并决定设计变更的Agent、组合多个API执行复杂任务的Agent，这些都应该在有人监督的环境中运行。
也可以在VPS（Virtual Private Server）等远程服务器上安装Claude Code，让它始终保持运行。笔记本合上后会话依然存在，适合长时间任务。通过SSH（Secure Shell）连接，甚至可以用手机远程操控。但即便如此，「人定期检查」这个前提不能少。
Agent独立判断并执行，和Agent执行后由人审核，两者之间有决定性的差异。
[图16-5] 区分可部署要素与需要监督要素的决策树
这条边界会随项目性质而变化。风险低、容易恢复的工作（比如生成博客文章草稿），可以给予智能体更大的自主权。风险高、难以回退的工作（比如修改数据库结构、调整支付系统），则必须经过人工确认。
网站已经上线，更新流水线已经搭好，维护原则已经确立。编写代码和完成部署的技术能力，是工具赋予我们的；但做什么、为谁做、维持怎样的品质，这些判断仍然属于人。驾驭工具的能力越强，「用它来做什么」这个问题就越重要。
人工智能专家 金京镇 律师
AI法律政策专家 · 前国会议员 · 著作等身
如果这本书曾在您身边停留片刻，请支持我们，让下一个故事也能与世界见面。
（自愿赞助账户：农协 302-1096-0948-81 户名：金京镇）