日常节奏

这是什么

你安装了 Claude Code，配置了 CLAUDE.md，学会了 Skills。但每天早上打开终端，盯着光标，不知道第一句该敲什么。

这个页面给你一套完整的日常节奏——从开机到关机，每一步都是具体的、可操作的。学完这一页，你不必再在“我现在该做什么”上消耗决策精力。

类比：日常节奏像早上的起床流程

早上起床后你会做什么？刷牙、洗脸、吃早餐、出门。你不会每天重新决定“今天要不要刷牙”——它是自动的。

Claude Code 的日常节奏也一样：一组固定的习惯动作，消除“我现在该干嘛”的决策疲劳。你不用思考“要不要记录”、“要不要提交”、“要不要复习”——答案永远是“要”，问题只是“怎么做”。

这个类比很重要，因为大多数 Claude Code 新手的问题不是“不会用工具”，而是“用完之后什么都没留下来”。三个月后回头看，做了那么多任务，但一个都回想不起来。日常节奏就是你的保险：每个值得记住的东西，都有一个确定的路径存起来。

开始之前

• 已完成 10 分钟上手，能正常启动 claude
• 最好已有项目级 CLAUDE.md（没有也能跟做，但协作质量会差一截）
• 了解 Skill 体系 的基本概念；文中带 / 的自定义 Skill（如 /commit、/wiki）不是 Claude Code 内置命令——没有的话用文中给出的手动替代步骤

实际操作：7 步日循环

以下 7 步是一条完整的日循环。不需要全部记住——先挑你感觉最自然的那一步开始，慢慢把整个循环走全。

早上：回顾与选择

1. 回顾——看昨天做到哪了

打开浏览器看你的 index.html（不是终端里 cat 某个文件——你需要视觉上的索引页来快速定位）：

open index.html          # macOS
start index.html         # Windows
xdg-open index.html      # Linux

你的 index.html 是知识库的顶层地图。昨天写到一半的笔记、上周遇到但还没解决的问题、最近在学习的概念——这些都在首页上。

如果你没有 index.html，说明你还没开始做知识库。没关系，记住这个习惯就行：每天打开同一个起点，让上下文不在关机后丢失。最小替代：打开昨天的笔记文件，或问 Claude：

根据 CLAUDE.md 和最近的文件改动，用三句话总结：昨天可能做到哪了、今天最自然的下一步是什么。

2. 选择——今天只做一件事

扫一眼昨天的记录后，问自己一个问题：今天要推进哪一件事？

只选一件。不是三件，不是五件，是一件。

原因很简单：AI 编程的节奏和传统编程不同。传统编程你可能同时修三个 bug、改两个功能。但 Claude Code 是在对话里工作的——一个对话有上下文窗口，任务越聚焦，AI 理解得越准。把一件事情做透，比十件事都碰一下效果好得多。

选好后，若上一任务残留在对话里，先 /clear（见上下文窗口管理）。

工作中：计划与实施

3. 计划——先让 Claude 读相关文件

不要上来就说“帮我做一个 XX 功能”。先说：

我想做一个 XX 功能。
请先只读相关文件，理解现有代码结构，然后给我一个实施方案。
先不要改代码。方案里写清：要改哪些文件、每步做什么、有什么风险。

为什么这一步不能跳过？Claude Code 不是写完代码就忘了的 ChatGPT——它会读你项目里的真实文件。但你得给它一个机会先“看清局面”。跳过这一步直接让它写代码，等于让一个刚走进房间的人立刻回答“这间房哪里有问题”——它可能说得头头是道，但和现实对不上。

一个好的计划提示包含三个要素：

• 你要做什么（目标）
• 让它先读什么（上下文范围）
• 让它先输出方案而不是代码（暂缓执行）

成功标准：你拿到一份可勾选的步骤列表，且你同意范围后再进入实施。

如果 Claude 直接开始改代码：立刻停下（Ctrl + C 如需要），说：

停。先不要改文件。把方案用编号列表写出来，等我回复「按方案执行」后再动手。

4. 实施——边看边学

方案确认后，Claude 开始写代码。你的任务不是盯着进度条——你的任务是看懂它在改什么。

具体做法：

• 每改完一个文件，扫一眼 diff：加了什么？删了什么？文件名是什么？
• 如果某段代码你看不懂，立刻问：

这段是什么意思？用三句话讲一下，并指出我以后改它时最容易踩的坑。

• 如果 Claude 改了你不认识的文件，问它：

为什么需要改这个文件？它和我们要做的事有什么关系？如果可以不改，请说明替代方案。

这是 AI 编程最大的学习红利：你不是在“看教程”，你是在“看一个比你强的人在帮你干活，同时随时给你解释”。抓住这个机会。

5. 验证——确认改的东西是对的

实施完成后别急着提交。验证有三步：

• grep 检查：用 grep（或 PowerShell Select-String）搜关键名字（函数名、变量名、文件名），确认改了的地方和没改的地方都符合预期
• diff 检查：用 git diff --stat 再 git diff 看完整改动，确保没有意外修改
• 实际运行：如果程序能跑，跑一下看效果；如果不能跑，至少确认语法没问题

可复制的收口 prompt：

请按三层验证帮我自检：1) 搜索新增名字是否定义/调用一致 2) 对照 git diff 与我的原始需求列遗漏 3) 给出我可以手动跑的最短验证步骤。

完整的验证方法论见验证方法论。这里只需要记住原则：验证不是可有可无的检查项，它是区分“能用”和“用对了”的唯一防线。

收工前：记录与提交

6. 记录——今天学了什么（至少一句话）

关终端之前，打开今日的 daily 文件，写一句话：今天学到了什么。

是的，一句话就够了。不是为了交作业，是为了给明天的你留一个上下文锚点。明天的你打开 index.html，看到这句话，立刻知道自己昨天做到了哪。

没有 daily 目录时，最小替代：

# macOS / Linux
mkdir -p daily
echo "2026-07-10：今天用 Claude Code 做了 ____" >> daily/$(date +%F).md

# Windows PowerShell
New-Item -ItemType Directory -Force -Path daily | Out-Null
Add-Content -Path ("daily\{0:yyyy-MM-dd}.md" -f (Get-Date)) -Value "今天用 Claude Code 做了 ____"

或让 Claude：

在 daily/ 下创建或追加今天的笔记，只写一句话：我今天学到了什么 / 做到了哪。不要写成论文。

如果你有更多想记的——学会了一个新概念、解决了一个难 bug、读了一段源码有启发——这些都是知识资产，值得单独归档。具体记在哪里，看下一节“工件选择启发式”。

7. 提交——一个改动一个提交

代码和笔记都写完了，用 /commit skill 提交（若你已创建该 Skill）。规则只有一条：一个提交做一件事。

没有 /commit Skill 时，手动最小流程：

git status
git diff --stat
git add <具体文件>
git commit -m "简短说明今天这一件事"

不要无脑 git add .。三个不同的改动？拆成三个提交。原因：一个月后你要回看历史找某个 bug 是从哪个提交引入的，一个提交一件事让你能迅速定位，而不是在一大坨改动里大海捞针。

安全提醒：提交前确认没有 API key、密码、.env 真实密钥进入暂存区。不确定就先 git diff --cached 扫一眼。

做完这个提交，今天的循环就完整了。关终端。

工件选择启发式：值得记录的东西记在哪？

日常节奏中第 6 步“记录”是最容易被跳过的。但更隐蔽的问题是：记在哪里。

Jason 的 CLAUDE.md 里有一条“命中即停”的工件选择规则，解决了这个决策问题。当你有东西想记时，按以下顺序判断，第一个能匹配的就记在那里：

优先级	触发条件	记在哪里	为什么这个优先级最高
1	mentor / 同事 / code review 的反馈	feedback/inbound/	别人的反馈是最稀有的输入，丢了最可惜
2	新概念 / 模式 / 技能，以后能复用	learnings/	可复用知识不记下来，下周就忘了
3	排查超过 30 分钟，且根因清晰	problems/	踩过的坑是最高效的学习材料
4	其他一切	daily/	杂事也值得记，但用最简单的方式

这个排序的逻辑是什么？

反馈排第一，因为 mentor 不会把同样的话说第二遍。你今天听懂了，但两周后你可能忘了。记下来，两周后你的 inbound 还在，随时能回看。

新概念排第二，因为可复用的知识是你最重要的资产。学会“怎么在 Claude Code 里配置 hook”不是一个一次性的操作——你以后每次需要 hook 都可以回看这篇 learning。

排查 30 分钟以上的问题排第三，因为你投入了时间，根因有价值。30 分钟的阈值是在说你已经走完了“试了这个、试了那个”的阶段，真正找到了原因。这种经验如果不写下来，下次踩同样的坑就是纯浪费。

其他排最后，因为 daily 本来就是收纳箱。不是贬义——收纳箱很有用。你不知道放哪的东西就放 daily。但先把有价值的放到它们该去的地方。

会遇到的真实场景：

• 同事在群里说：“你这个 API 的返回格式不对，应该用 snake_case”——这条反馈优先放 feedback/inbound/
• Claude 跟你解释了一个你不懂的 Python 特性——这个新知识放 learnings/
• 你调一个配置调了 40 分钟才发现少了一个空格——这个坑放 problems/
• 今天做了三个小任务但没什么值得单独记的——写进 daily 的“今日回顾”段

还没有这些目录时，先只用 daily/ 也完全够；目录是为了长大后的检索，不是入门门槛。

Skill 链示例：Skills 如何组成日常流程

Jason 的日常不是零散地用一个一个 skill——它们是互相衔接的链条。下面三个最常用的链条，展示 skills 是怎么拼成完整流程的。

这些是自定义 Skill 示例

/source-learn、/learn、/wiki、/sync-all、/daily-learn、/render、/commit 等来自个人/项目 Skill 包，不是 Claude Code 默认自带。没有它们时，用同一步骤的手动写法即可；创建 Skill 的方法见 Skill 体系。

学习链：/source-learn → /learn → /wiki index → /sync-all

当你读到一段源码、有了新理解：

1. /source-learn 提炼：把源码中的模式、设计决策变成你自己的理解
2. /learn 自测：通过几个小测试确认你真的懂了（不是“感觉懂了”）
3. /wiki index 索引：新的 learning 写完后，更新知识库索引，让以后能找到
4. /sync-all 刷新：全量重建 HTML 页面，然后在浏览器里打开 index.html 看成果（macOS 用 open，Windows 用 start，Linux 用 xdg-open）

手动替代：把理解写成 learnings/ 下一篇短文 → 自己出 2 道题回答 → 在索引里加一行链接 → 如有需要再生成/打开 HTML。

这条链的价值：读一段源码 → 消化成自己的理解 → 存入知识库 → 变成可视化成果。一步不少，每个环节都不可跳过。

反馈链：write feedback/inbound/ → write feedback/action/ → update CLAUDE.md

当 mentor 或同事给了反馈：

1. 写 feedback/inbound/：记录“谁说的、内容是什么、当时在做什么”。必须包含下接 action/ 的链接
2. 写 feedback/action/：把反馈拆成具体可执行的计划。每一条行动都有 来源: 字段指向 inbound 文件
3. 如果反馈涉及你和 Claude Code 的协作方式，更新 CLAUDE.md：把新的规则或边界写进去，下次 Claude Code 会自动遵守

这条链的价值：反馈不是听完就完，它有来处有去路，最终变成你的系统规则。

收工链：write daily/ → /daily-learn → /render → /commit

每天收工前：

1. 写 daily/：按模板填“今日学到”和“明日计划”
2. /daily-learn（自定义 Skill——如果还没创建，跳过这步，手动在 daily 文件中补充学习内容）：分析今天的对话，补充 daily 中的学习内容
3. /render daily/<today>.md：把今天的日报渲染成 HTML（你明天早上打开 index.html 就能看到）
4. /commit：原子化提交，一个改动一个提交；没有 Skill 就用上面的手动 git add + git commit

这条链的价值：关终端不是一个动作，是一组动作。做完这四步，今天的数据就全都在该在的地方了。

周/月维护

日常循环管每天，周/月维护管长期趋势。

每周五：复盘

1. 扫本周 daily/ 和 problems/：这周学到了什么？卡在哪里？
2. 跑 /wiki lint（若有）：检查知识库健康——有没有写了但没索引的笔记？有没有引了但没消化的来源？没有 wiki 时，手动打开本周笔记扫一遍即可
3. 把复盘结论写进当日 daily 的“周复盘”段——不单独开文件

周复盘之所以放在周五而不是周一，是因为你的短期记忆会在周末重置。周五写完，周一早上看到那句“周复盘”，立刻能接上周五的上下文。

每月末：大扫除

1. 跑一次 /sync-all（若有）：全量刷新所有派生文件和 HTML；没有就跳过
2. 打开 wiki/issues.md（或你的待学清单）看“知识缺口”段：有哪些你标记了但还没学的内容？
3. 挑 1-2 个缺口放进下月的学习计划

月维护的本质是退一步看全局。日常循环是在显微镜下干活，月维护是把镜头拉远，看这片森林长成什么样了。哪片区域太稀疏（某个主题你只写了标题但没内容）？哪片区域杂草丛生（一些早期笔记已经过时但还没更新）？每月看一次就够了。

常见坑

没有固定节奏

今天用了 Claude Code，明天忘了，下周再打开发现已经不知道怎么用了。

解法：从第 6 步开始——每天关终端前写一句话。就这一句。连续 3 天就算养成第一个习惯。

只写代码，从不记录

三天写了一个功能，下周 mentor 问你怎么实现的，你看着代码说“我不记得了”。

解法：写代码的过程中，每理解一个新概念就问自己一句“这个我下周还记得吗”。如果答案是不记得，停下来花 2 分钟记到 learnings/（或 daily/）。

从不复习

记了十几条 learnings/，但从来没回看过。知识库变成了知识的坟场，而不是知识的复利机器。

解法：每周五的复盘扫一遍本周 learnings/，至少确认每条你还记得是什么。想不起来的重新读一遍。

一次想做太多

今天既要学 Rust，又要重构项目结构，又要搭 CI/CD 流水线。结果每个都做了 20%，没有一个完成。

解法：早上选任务时，只选一件。如果你觉得“一件事太少了”，说明你还没尝到“一件事做透”的味道。试一次，就知道了。

把记录当成写论文

写一条 learning 写了一小时，反复改措辞。这不是在记录，这是在逃避干活。

解法：learning 的第一稿只写关键词和一句话解释。格式、交叉引用、代码示例——这些都可以后来补。先把想法钉住，别让它跑了。

把自定义 Skill 当成官方内置

输入 /wiki 没反应，以为 Claude Code 坏了。其实那是你（或别人）写的 Skill。解法：先确认 .claude/skills/<name>/SKILL.md 是否存在；不存在就用本页的手动替代步骤，需要时再按 Skill 体系 创建。

收工不验证就提交

“明天再看”常常变成“再也不看”。解法：至少跑 git diff --stat + 一次实际运行（或打开页面），再 commit。细节见验证方法论。

Checkpoint

三天挑战：每天关终端前写一句话。

从明天开始，连续三天，关终端前打开你的 daily 文件（或新建），写一句话：今天用 Claude Code 做了什么。

不需要写得好。不需要觉得“这值得记”。就一句。写完就关。

三天之后，你有了第一个习惯的基础。接下来第二个习惯（提交）、第三个习惯（验证），在已有的基础上一个一个叠加。

勾选（今天就能勾的先勾，三天挑战单独计）：

• □ 我能按顺序说出 7 步：回顾 → 选择 → 计划 → 实施 → 验证 → 记录 → 提交
• □ 我有一句可复制的「先读文件、先出方案、先不改代码」计划 prompt
• □ 我知道验证三步（搜索 / diff / 实际运行），或会用自检 prompt 让 Claude 协助
• □ 我知道没有 /commit、/wiki 等自定义 Skill 时该怎么手动替代
• □ 我完成了至少 1 天的“关终端前写一句话”（目标：连续 3 天）

下一步

现在你有了完整的日循环。接下来推荐三篇：

• 验证方法论——第 5 步“验证”的完整展开。三层检查体系让你不再依赖“感觉应该没问题”。
• 上下文窗口管理——理解 Claude Code 的“记忆范围”，学会在对话变慢之前主动干预。
• 学习管理系统——把日常记录系统化，让每天学到的东西持续复利。