当 Claude Code 学会值夜班：我的 5 个实战工作流案例

用了大半年 Claude Code，我越来越觉得：真正拉开差距的不是提示词，而是你给 AI 搭的“工作流系统”。 这篇文章不讲理论，只讲我用这套系统真实跑过的 5 件事。

写在前面：我的工具栈和心法

先交代下我的“装备”，免得后面的案例看着像空中楼阁。

我日常的主力是 Claude Code，但不是“裸奔”着用，我在它上面搭了一套自建工作流系统，主要由三部分组成：

自定义 Skills：把反复出现的验证步骤、代码规范、提交习惯写成 .md 文件，让 Claude Code 每次自动遵守。这是最核心的一层。
MCP 工具链：把浏览器、文件系统、数据库、Figma、GitHub 这些外部能力接进来，让 Claude Code 能“看见”和“动手”，而不只是“说”。
脚本 + AI 编排：确定性的活儿用脚本跑（便宜、稳定），需要判断的活儿交给 AI。两者用 Skills 串起来。

官方文档：用 Skills 扩展 Claude Code

围绕这套系统，我每天的工作方式可以用一句话概括：

把“我自己重复做的判断”全部编码成文件，让 Claude Code 带着这些上下文替我干活。

下面 5 个案例，就是这个原则在不同场景下的落地。

案例一：把“提测前的自检”整段外包出去

痛点

我带一个中型项目，每次提测前要做一遍固定动作：跑 lint、跑单测、检查有没有漏掉的 console.log、确认 CHANGELOG 更新了没、看一眼 git diff 有没有奇怪的调试代码。

这些事不难，但又碎又重复，每次至少耗我 20 分钟，还经常因为赶时间漏掉一两项。漏掉的代价是测试同学打回来，来回一次就是半天。

我的解法：写一个 pre-release Skill

我写了个 pre-release-check.md，放在项目的 .claude/skills/ 下：

markdown

---
name: pre-release-check
description: 提测前执行完整的自检流程，任何一项不通过都不算完成。
---

# 提测前自检

收到“准备提测”指令后，必须按顺序执行：

1. 运行 `npm run lint` 和 `npm test`。任何 error 必须修复，warning 列出来让我决定。

2. 用 `git diff origin/main...HEAD` 检查本次所有改动，重点找：
   - 残留的 `console.log` / `debugger` / `TODO`
   - 注释掉的大段代码
   - 硬编码的测试 URL、密码、token

3. 检查 CHANGELOG.md 是否有本次版本对应的条目。没有就根据 commit message 起草一版让我确认。

4. 检查 package.json 版本号是否符合本次改动幅度（patch/minor/major）。

5. 生成一份“提测清单”：本次改动范围、影响模块、需要重点回归的点、已知风险。

任何一步发现问题，先修复再继续，不要带着问题往下走。

效果

现在提测前我只要打一句“准备提测”，Claude Code 会：

跑 lint + test，红了一项项修
扫 diff，揪出我忘删的调试代码（上周它抓到一个我手滑留下的 // TODO: 删掉这行）
对照 commit 历史起草 CHANGELOG
输出一份提测清单

20 分钟的碎活儿，压成了一句指令。 测试同学打回来的次数也明显少了，因为 AI 比我更不会“赶时间漏项”。

💡 一个反直觉的体会：Skill 写得越死板、越像流水线，效果越好。 早期我写成“请检查代码质量”，Claude 就糊弄我“质量良好”。后来每一项都规定成可执行动作，它就老实照做。

案例二：让 Claude Code 看见数据库，schema 迁移不再抓瞎

痛点

做一次 schema 迁移有多痛，写过的人都懂。以前我的流程是：

在脑子里构思新的 schema
写 migration 脚本
在本地跑一遍，报错了看日志
改，再跑
还要手写对应的 ORM 模型更新、改受影响的查询代码

问题出在第 3 步之后：报错信息我得自己读、自己定位、自己想改法。而 Claude Code 默认看不见数据库，它能读写代码文件，但不知道你数据库里现在长什么样、有哪些表、字段类型是什么。它写的 migration 经常是基于“猜测”，一跑就炸。

我的解法：接一个 MCP 数据库连接器

官方文档：通过 MCP 给 Claude Code 接上外部工具

我用 MCP 给 Claude Code 接了一个只读的数据库连接（PostgreSQL）。关键配置里只开了 SELECT 和 EXPLAIN 权限，只看不动，安全第一。

接上之后，画风完全变了。我描述需求：

“把 orders 表的 shipping_address 字段拆成 street / city / zip / country 四个字段，写 migration，并更新所有相关查询。”

Claude Code 的操作链路变成了这样：

先 SELECT 看一眼现有 schema：orders 表结构、shipping_address 现在是 text 类型、有多少行数据、有没有 NULL。
EXPLAIN 看哪些查询用到了这个字段：发现 3 个 JOIN 和 2 个 WHERE 依赖它。
基于真实情况写 migration：加新列、回填数据（因为它看了真实数据，知道用 split_part）、删旧列。
同步更新 ORM 模型和那 5 处查询。
自己跑一遍，回报结果。

一个让我意外的细节

它跑 SELECT 时发现 shipping_address 里有约 12% 的行格式不规范（不是标准的“街道,城市,邮编”），如果一刀切用 split_part 会丢数据。它主动在 migration 里加了“格式异常的行暂存到临时表，生成一份清单让我人工处理”。

这种“看了真实数据后做的判断”，是它没接数据库时绝对做不到的。AI 加 MCP 的本质，是给它从“纸上谈兵”升级到“实地勘察”的能力。

⚠️ 安全提醒：数据库 MCP 一定只开只读权限，且最好接到开发库的副本而不是生产库。我见过有人图省事直连生产，AI 一通操作差点把数据改了。

案例三：用浏览器 MCP 做“闭环前端开发”

痛点

案例一解决了后端自检，案例二解决了数据库，但前端开发有个老大难：Claude Code 改完代码，它自己不知道效果对不对。

比如我让它“加个暗黑模式切换按钮”，它改完 CSS 就跟我说“已完成”。至于按钮点了有没有反应、暗色样式有没有覆盖全站、移动端布局有没有崩，它一概不知，全靠我自己开浏览器看。

这种“改完不验证”的模式，让我每次前端改动都得手动过一遍：启动 server、开浏览器、点一遍、看控制台、调响应式。比写代码本身还累。

我的解法：Chrome DevTools MCP + 验证 Skill

我接了 Chrome DevTools MCP，让 Claude Code 能驱动一个真实的浏览器：导航、点击、截图、看控制台、跑性能追踪。然后写了个 Skill 把“验证”流程固化下来：

markdown

---
name: verify-frontend
description: 任何前端改动，必须端到端验证后才能报告完成。
---

# 前端验证流程

1. 启动 dev server，导航到改动涉及的页面，截图存档（before）。

2. 执行改动涉及的核心交互（点按钮、填表单、切状态），截图（after）。

3. 对比 before/after，确认预期的变化确实发生了。

4. 检查浏览器控制台：不得有新增的 error。

5. 用 DevTools 切到移动端视口（375px），确认响应式没崩。

6. 跑一次 Lighthouse，记录性能分数。如果比改动前下降超过 10 分，报告给我。

任何一步不符合预期，修复后从第 1 步重来。

官方配套文章：用 Skills 搭建验证循环

实战演示

我让它“在导航栏加一个搜索框，支持回车跳转搜索页”。它现在的完整动作是：

改代码，加搜索框组件和路由。
启动 server，浏览器打开首页，截图，确实多了个搜索框。
在搜索框输入“测试”，回车，跳到了 /search?q=测试，截图确认。
查控制台，干净，没报错。
切 375px 视口，搜索框挤变形了，它发现移动端 CSS 有问题，自己改了 flex 布局，重新验证。
跑 Lighthouse，性能分没掉。
回来告诉我“完成，移动端布局也调整过了”。

我全程没碰浏览器。 它甚至能发现我自己都不一定会注意的移动端问题。

这套打法的真正价值

不是省时间，而是省“认知负担”。以前改前端我得在“写代码”和“验证效果”两种心智模式间反复切换，现在验证完全外包了，我可以专注想产品本身。

案例四：用 Claude Code “考古”，读懂一个祖传项目

痛点

接手了一个 5 年的项目，前任开发走得急，几乎没留文档。代码量大、注释稀少、命名随意（见过 doStuff()、handleIt()、temp2 吗？）。我要在它上面加一个支付功能，但根本不知道该往哪儿加。

纯手工读代码，光摸清“支付流程涉及哪些文件”就得一周。

我的解法：让 Claude Code 当“考古学家”

我没有直接让它“加支付功能”，而是分了三步走。

第一步：让它画地图。

“通读这个项目，给我一份架构地图：核心模块有哪些、它们之间的依赖关系、数据流向。不用太细，先给我全局。”

它扫了一遍目录结构和关键文件，产出了一份“模块关系图”，哪个是入口、哪些是工具层、哪些是业务逻辑、数据库怎么组织的。这份地图本身就成了我后续工作的导航。

第二步：让它做局部深挖。

“在这个架构里，支付相关的逻辑大概在哪？把所有跟钱、订单、交易相关的文件找出来，解释每个文件干嘛的。”

它定位到几个文件，逐个解读，这个是订单模型、这个是支付网关适配层、这个处理回调。最让我惊喜的是，它从一些“看起来无关”的工具函数里，揪出了实际参与支付流程的逻辑（因为函数名含糊，但参数和调用链暴露了用途）。

第三步：让它列风险清单。

“假设我要在这个基础上加微信支付，最可能出问题的地方是哪？给我一份风险清单。”

它给出了让我后背发凉的清单：

现有的事务处理没有正确处理并发（两个请求同时下单可能超卖）
支付回调没有幂等性校验（同一个回调来两次会重复发货）
金额计算用了浮点数（经典精度坑）
日志里会打印完整卡号（合规风险）

这些坑，任何一个都可能让我上线后炸雷。 而 Claude Code 在我没写一行新代码的情况下，光靠“读懂”就帮我把雷排了大半。

关键体会

“考古”场景下，千万别一上来就让它改代码。 先让它读懂、画地图、列风险。磨刀不误砍柴工，前期这几个小时的“考古”，省掉的是后期成倍的 debug 时间。

我后来把这个流程固化成了一个 codebase-archaeology.md Skill，每次接手新项目都先跑一遍。

案例五：自建“夜间值班”工作流，PR 自动修复

痛点

我维护一个开源项目，全球都有贡献者。问题是：我睡觉的时候，他们活跃。 经常早上醒来发现：几个 PR 挂着 CI 失败、reviewer 留了意见没人回、依赖机器人提了个升级 PR。

这些事每一件都不大，但积压起来很烦，早上头一个小时全在收拾昨晚的烂摊子。

我的解法：脚本 + Claude Code 的定时循环

我没有用什么重型 CI 机器人，而是用 Claude Code 的 /loop 配合一段自写脚本，搭了个轻量的“夜间值班”。

核心逻辑：

脚本层（确定性，便宜稳定）：一个 shell 脚本每隔 10 分钟调 GitHub API，列出我所有 open PR 的状态，CI 红没红、有没有新评论、有没有 conflict。
判断层（Claude Code）：把脚本输出的状态丢给 Claude Code，让它判断“这个 PR 现在需要我做什么”。
执行层（Claude Code + Skills）：如果是 CI 失败，让它读日志、定位原因、改了推回去；如果有 review 意见，逐条处理并回复；如果只是 conflict，rebase 推回去。

提示词大致是：

text

/loop 10m 巡逻我的开源项目 PR：
- 拉取所有 open PR 的状态（用 check-pr-status 脚本）
- CI 失败：读日志、定位根因、修复、推送，直到 CI 变绿
- 新的 review 意见：逐条理解并回复/修改，推送后礼貌 @ reviewer
- rebase conflict：解决 conflict 并推送
- 任何无法自动判断的，汇总成清单等我醒来处理

一个让我印象深刻的夜晚

有晚同时来了三个情况：

PR A：一个 contributor 的改动让 TypeScript 编译挂了。Claude Code 读日志发现是个类型推断断了，补了个类型注解，推回去，CI 绿了。
PR B：reviewer 留了“这里建议提取成 hook”。Claude Code 读懂后做了重构，回复 reviewer “已提取为 useXxx hook，请重新查看”。
PR C：依赖升级 PR，跟本地一个 patch 冲突。Claude Code 重新打了 patch，conflict 解决。

我第二天醒来，三个 PR 全绿，意见全回了。 我只需要做最终的人工 review 和 merge。

这套打法的关键

确定性的活儿（拉状态、调 API）用脚本，需要判断的活儿（读日志、改代码、回意见）用 AI。 全用 AI 又贵又慢，全用脚本又死板。两者结合，又便宜又灵活。

这也是我最想强调的一点：Claude Code 不是用来替代你整个工具链的，而是用来补上“脚本搞不定、手动又太累”的那一段。

三个共性：什么样的事，最值得交给这套系统

把五个案例放一起，能提炼出几条判断标准。当你犹豫“这事该不该交给 Claude Code + 工作流”时，拿这三条卡一下：

标准 1：这件事是否“重复且有固定章法”？

提测自检、前端验证、PR 巡逻，这些事你每次干的步骤都差不多，只是输入在变。有固定章法的重复活儿，是 Skill 化的首选。 写一次 Skill，省无数次手动操作。

标准 2：这件事是否卡在“看不见”上？

数据库迁移卡在 AI 看不见 schema，前端开发卡在 AI 看不见效果，考古卡在 AI 看不见调用链。凡是卡在“信息获取”上的，接个 MCP 基本就通了。 想想你的痛点是不是“AI 不知道某个事实”，如果是，答案大概率是 MCP。

标准 3：这件事是否“确定性部分和判断部分混杂”？

PR 修复、数据库迁移都是这种结构：拉状态、调 API 是确定性的，定位 bug、写代码是判断性的。这种混合活儿最适合“脚本 + AI”组合拳，不要让 AI 干脚本的活儿（贵且不稳），也别指望脚本能做判断。

给你一条上手的捷径

如果你看完想立刻动手，别一上来就搞案例五那种全套工作流，会把自己绕晕。

从案例一开始。 找一件你每周至少做三次、步骤固定、但又很烦的事（自检、验证、生成文档、写 commit message……都行）。把它写成一个 Skill，就 20-50 行 markdown。跑一周，感受“外包”的甜头。

尝到甜头后，你会自然而然地想：“这事卡在 AI 看不见某个东西上吗？”，如果答案是“是”，那你就该去接 MCP 了。这是第二阶段。

等你有了几个 Skill、接了一两个 MCP，再考虑把脚本和 AI 串成定时循环。这是第三阶段。

核心心法从头到尾只有一句：把你脑子里重复的判断，编码成文件。 Skill 是给 AI 看的“你的习惯说明书”，MCP 是给 AI 用的“你的眼睛和手”。这两样配齐了，Claude Code 就从一个“聪明的聊天机器人”，变成一个“懂你习惯的同事”。

而同事，是可以替你值夜班的。

本文案例来自作者的真实开发实践。Skills、MCP、/loop 等概念可查阅官方文档：https://code.claude.com/docs 。

字节笔记本