Claude Code 初学者每天 15 分钟例行：早上安全推进的操作步骤

周五晚上，我对 Claude Code 丢下一句「这个项目里你觉得有问题的地方，全部都帮我修了」，然后就去睡了。

第二天早上，被改动的文件有 23 个。里面确实有能跑的代码。可问题是，到底哪些真的修好了、我该确认什么，我自己一个字都说不出来。光是从头到尾把改动读一遍就花了一个小时，最后心里发虚，一行都不敢提交。

我把活儿大方地交给了聪明的 AI，结果不但没往前走，反而倒退了。这正是初学者最先掉进去的那个坑。

原因不在 Claude Code 的能力，而在于我没有事先决定怎么「收尾」一项工作。今天我把自己每天早上煮咖啡那会儿做的 15 分钟流程，原封不动地交给你。

本文要点

• 「全部都修」是出事故的根源。每天只做「用一句话定下来的一件小事」。
• 在动手编辑之前，先定好用来判断「做完没」的验证命令。
• 干完活之后，只留下「改了哪些文件」「验证命令的结果」「下一步做什么」这三样就够了。
• 交给 AI 的是动手的部分。划定范围、按下发布按钮，由人来做。
• 把下面的脚本复制过去，每天早上的检查就能自动按顺序跑一遍。

为什么「小步收尾」对初学者特别管用

刚开始碰 Claude Code 那阵子，我每次的目标都很模糊。「弄好看点」「让它读起来顺一点」。这样一来，AI 到底做了什么、做到哪一步，干完之后我也搞不清楚。

对人类新人也是同一个道理。被交代「这份资料你看着随便整一下」的人，多半会发愁。而被交代「把第 3 页的数字换成最新版，再看看表格有没有错位」的人，马上就能动手，而且自己就能判断到底做完没。

每日例行里最关键的，不是一口气写出一条聪明的指令，而是切成小块，做成能判断「结束」的形状。能做到这一点，哪怕是初学者，也能每天说出一句「今天推进到了这里」。

顺便一提，这套思路的地基，和另外两篇文章是连着的：Claude Code 入门指南和权限管理基础。先用那两篇把环境搭好，再把这个习惯叠上去，效果才足。

15 分钟要做的，只有 4 步

我每天早上做的，就下面这 4 件，而且每次顺序都一样。把顺序固定下来，不用动脑子，身体就自己动了。

1. 用一句话写下今天的最小任务。 像「只把 README 的开头 3 行重写一下」这样，颗粒度小到能看见终点。大活儿故意今天先不碰。
2. 先把验证命令定下来。 像「npm run build 能过就 OK」「有 1 个测试变绿就 OK」这样，在动手之前就把目标的样子定好。
3. 做完后，按 diff、构建、线上 URL 的顺序确认。 别一上来就发布，从机器能判断的地方开始，一项一项地看。
4. 为下次只留一行。 记下「还剩的风险」和「下一个最小任务」。这就是明天早上的起跑线。

要点在第 2 步。不先定验证命令就开始编辑，就会退回到那个周五晚上——「感觉是修好了，但没有确证」。先把终点线画好，再开跑。 光是这一点，就能让每天的活儿轻松一大截。

交给 AI 的范围，和人来定的范围

我觉得初学者最容易乱的地方就在这儿。既不能什么都甩给 AI，要是全都自己干，那用它又有什么意义。我把分界线的参考标准做成了一张表。

场景	交给 AI	人来定 / 人来按
定范围	让它列候选	确定今天要做的那一句
编辑	写代码或文字	改什么的方针
验证	执行构建或测试	把哪个验证当作目标
发布	输出 diff 的摘要	按下发布按钮
危险操作	先问「能不能做」	删除、上生产的最终决定

拿不准的时候，判断标准很简单。能反悔的活儿交给 AI，回不了头的活儿留给人。 编辑文件随时可以重来，所以交出去；上生产、删文件，一开始一定要自己亲手按。等某个操作真的熟了，之后再一点点把它升级成自动。权限的细节设置，在 Claude Code 官方文档里有完整说明，分界线拿不准时翻一遍会更安心。

可以直接复制的请求模板

每次从零写请求，颗粒度就会忽大忽小。我把这个模板贴在记事应用里，每天早上做填空。

今天的最小任务：（这里写一句。例：重写 README 开头 3 行）
可以动的范围：（例：仅 README.md。其他文件禁止改动）
完成的验证方式：（例：npm run build 成功）

进行方式：
1. 先不要改动，读一遍现状并做摘要。
2. 只编辑上面定的范围。范围之外的不要碰。
3. 编辑后，报告改了哪些文件名，以及验证方式的结果。
4. 如果需要删除、上生产、对外发送，先不要执行，先来确认。

只要加上「范围之外不碰」「危险操作先确认」这两行，开头那个 23 个文件的事故就基本不会再发生了。这不是给 AI 自由，而是递给它一个安全的箱子。

可以直接跑的验证脚本

每天早上的检查，靠手打总会忘。我把这个脚本存成 morning-check.mjs，煮咖啡之前先让它跑一遍。只要装了 Node.js 就能用。

// morning-check.mjs：把每天早上的检查按顺序排好并执行
import { execSync } from "node:child_process";

// 把想确认的命令从上到下排好。按自己的项目改写。
const checks = [
  { label: "被改动的文件", cmd: "git status --short" },
  { label: "构建能不能过", cmd: "npm run build" },
];

let allOk = true;

for (const { label, cmd } of checks) {
  console.log(`\n=== ${label} : ${cmd} ===`);
  try {
    // 结果原样输出到屏幕。出错就走到下面的 catch。
    const out = execSync(cmd, { encoding: "utf8" });
    console.log(out.trim() || "(无输出)");
  } catch (e) {
    allOk = false;
    console.log("失败：", e.message.split("\n")[0]);
  }
}

console.log("\n--- 今天的收尾 ---");
console.log(allOk ? "验证 OK。把下一个最小任务用一行记下来。" : "验证卡住了。修好再往下走。");

执行就这一句。

node morning-check.mjs

诀窍是把 checks 里的内容按自己的项目改写。有测试就加上 npm test，是静态网站就加上线上 URL 的确认。只要每天早上同一套命令按同一个顺序流一遍，漏检几乎就消失了。我还在这里加了一条「最后是不是没提交就停下了」的检查。

这些场景下特别管用（3 个）

例 1：第一天只画仓库的地图 不用一上来就改代码。让 AI 摘要出「危险的目录在哪」「配置文件放在哪」，光是读这个，第一天就算成功。从第二天起的活儿会快很多。

例 2：第二天只改 README 的一段 攒一次小的成功体验。把开头 3 行重写一下，再用 npm run build 确认有没有改坏。就这些。把活儿做小、并且真的走到验证那一步，「我自己也能转起来」的感觉就到手了。

例 3：第三天做一个能连到数字的小改善 改一个文章标题、加 1 个测试、修 1 处死链。挑成果看得见的小改善。关键是每天攒一个「验证也走通了的改动」。

失败例，以及它的修法

说句实话，我在这 3 件事上栽过好多次。

坑 1：想一次把全部都做完。 「觉得有问题的地方全部」会生出一个没法验证的巨大 diff。修法很简单，把今天的那一句收紧成「一件」。剩下的转进明天的备忘。

坑 2：本地构建过了就当作完成。 npm run build 过了，不代表线上 URL 就正确地出来了。我有一次，构建是绿的，可线上页面还是旧的，我都没发现。修法是：发布后实际打开那个 URL，用眼睛看标题和正文开头是不是这次的改动。

坑 3：危险的确认顺手就按了。 弹出确认框时，初学者往往「先 Yes 再说」。一旦来的是删除或上生产的确认，先把手停下来。要是拿不准，那个操作今天就别做，这才是对的。权限的思路，给非工程师的讲解也可以参考。

留给下次的备忘是什么形状

最后留的备忘短一点就行。不过要定好格式，免得第二天早上的自己又把同一个判断重做一遍。

- 今天做了什么：重写了 README 开头 3 行
- 验证的方式：npm run build 成功 / 在线上 URL 确认了标题
- 还剩的风险：有 2 处图片死链
- 明天的最小任务：只修 1 处图片链接

有了这份备忘，第二天早上「从哪儿开始」的纠结时间就归零了。我从开始这么做以后，早上进入状态的速度，体感上快了 5 分钟。

常见问题

问：我每天连 15 分钟都抽不出来，能再短点吗？ 能。一开始哪怕只做「用一句话写下今天的最小任务」也 OK。只要养成了定验证命令的习惯，作业时间自然会变短。

问：我不知道验证命令该是什么。 项目里有 npm run build 或 npm test，先用它就足够了。要是什么都没有，「打开线上 URL 用眼睛看」也是一个像样的验证。一开始先定一个机器能判断的就行。

问：是不是全都交给 AI 反而更快？ 短期看像是这样。但「说不清到底改了什么」的改动，最后还是得整个重读一遍。小步收尾，从总账上算反而更快——这是我的真实体会。

问：初学者最先该做的是什么？ 画仓库的地图。改代码之前，先让 AI 摘要出哪儿有什么，然后去读。这是安全推进的地基。

问：这套例行能用在团队导入上吗？ 能。只是在团队里，要先把「谁来批准发布」「把哪个验证当目标」写成文档，这样个人的习惯就直接变成了团队的规则。配套地把项目约定写进 CLAUDE.md 最佳实践，新人也能照同一套节奏跑起来。

我实际跑下来的结果

自从那个周五晚上之后，我就不再纠结「该把多少交给 AI」了。取而代之，每天早上只定两样：今天的那一句，和验证命令。

把 morning-check.mjs 跑了两周，变化最大的是漏检。以前我常常以为构建过了就提交，后来发现其实坏了。改成让验证按同一个顺序在机器上流一遍以后，这种情况归零了。

还有每晚留的那 4 行备忘。从开始记它以后，第二天早上「我要干啥来着」就消失了。与其去找什么聪明用法，不如小步收尾、把验证留下来。这事很朴素，但初学者往前走的速度，我觉得就是在这儿定下来的。

先从明天早上开始，只定一句话，跑一个验证命令试试。坚持下去，等自己的套路成形了，再去教材一览里多攒几个请求模板，每天的手数还能再少几下。