前三篇讲了是什么、怎么装、怎么对话。该做点真东西了。
这篇我们用 Claude Code 从零搭建一个小项目——一个笔记管理的命令行工具。你会看到从「我有个想法」到「它能跑了」的完整过程：描述需求、审批代码、遇到 bug、修复、加功能。
你不需要懂编程。 Claude Code 会处理所有技术细节。你只需要做两件事：告诉它你要什么，以及看看它做的对不对。这正是本篇想让你体验的——用 AI 把想法变成可运行的程序是什么感觉。
你需要已经按照第二篇装好了 Claude Code，并且能正常启动。
另外需要 Node.js 环境。如果不确定有没有装，在终端输入：
node --version
看到版本号（比如 v22.x.x）就行。没有的话，回第二篇看「方式二：通过 npm 安装」下面的 Node.js 安装方法。
一个叫 note 的命令行工具：
note add "今天学了 Claude Code" — 创建一条笔记note list — 列出所有笔记note search 关键词note delete 3 — 删除第 3 条笔记存在本地文件夹里，一条笔记一个文件。项目小，但你能从中感受到 Claude Code 的工作方式。
先创建一个空文件夹，在里面启动 Claude Code：
mkdir note-cli && cd note-cli
claude
进入对话后，告诉它你要做什么：
我要做一个笔记管理的命令行工具，用 Node.js。
功能：添加笔记、列出笔记、搜索笔记、删除笔记。
笔记存为本地文件。
帮我从头搭建这个项目。
Claude Code 会自动决定项目结构、选择合适的库、创建配置文件。它可能会创建五六个文件——package.json（项目配置）、源代码文件、.gitignore 等。
你可能看不太懂这些文件的内容，没关系。它们都是标准的项目模板配置，和你去餐厅不需要懂后厨怎么摆放调料是一个道理。看到 Claude Code 提示要创建文件，按 y 批准就行。
它创建完文件后，可能会说需要安装依赖。让它来：
帮我安装依赖
Claude Code 会执行安装命令。终端会输出一堆信息——包括一些黄色的 warning。大多数 warning 可以忽略，只要最后没有红色的 error 就没问题。
前面第三篇讲过的原则在这里很重要：分步骤，别一口气说太多。
先做第一个功能：
先实现 add 命令。
用户输入 note add "今天天气不错" 就能创建一条笔记。
笔记要包含创建时间。
Claude Code 会写代码、创建文件。你审批通过后，看一下它的方案合不合理。觉得哪里不对，直接说：
创建时间的格式改成 2026-03-15 14:30 这种，更好读
它会立刻改。
确认 add 没问题后，继续下一个：
实现 list 命令。列出所有笔记，
按时间倒序，显示序号、时间和内容预览。
然后是 search 和 delete，同样一个一个来。每实现一个功能就确认一下，再做下一个。
四个功能都写完后，让它帮你测试：
帮我测试一下：
1. 添加两条笔记
2. 列出所有笔记
3. 搜索其中一条
4. 删除一条
5. 再列出确认删除成功
Claude Code 会在终端里逐步执行命令。你会看到实际的运行结果——笔记被创建、被列出、被搜索到、被删除。
大概率会碰到一些问题。 可能某个命令报错了，可能搜索结果不对。完全正常——这不是你的问题，也不是 Claude Code「笨」，写程序就是这样，第一遍跑通反而是小概率事件。
重点是接下来发生的事：Claude Code 会自己看到报错，分析原因，提出修复方案，改代码，再测试。这个**「报错 → 分析 → 修复 → 验证」的循环**是你以后和它协作的日常。你不需要自己去读报错信息——让它处理就好。
提醒： 做到这一步，对话已经比较长了。如果感觉 Claude Code 的回复开始变得不太对劲（忘了之前说过的事、重复做已经做过的事），输入
/compact让它压缩一下对话历史。这个问题在第三篇提过，现在是你第一次在实战中遇到它。
基础功能跑通后，你可以继续加需求，体验迭代开发的感觉：
给笔记加上标签功能。
add 的时候可以指定标签，list 的时候可以按标签筛选。
或者：
加一个 stats 命令，显示统计信息：
总共多少条笔记、最早和最近一条分别是什么时候写的。
或者让它改善用户体验：
list 命令的输出太素了，帮我加上颜色和格式，让它更好看。
每次加功能都是同样的节奏：描述想要什么 → 看它怎么做 → 不满意就说 → 满意就继续。
让 Claude Code 帮你做一些收尾：
帮我生成一个 README 说明文档，
介绍这个工具是什么、怎么安装、怎么用。
根据实际的功能来写，不要编造。
初始化 git 仓库，提交代码。
到这里，你就拥有了一个完整的、能运行的、有版本管理的项目。
最后用
/cost看看这次对话花了多少 token——对后续估算使用成本有个概念。
回过头看，几个值得记住的点：
你全程没有手动写代码。 但你做了所有决策——做什么功能、怎么设计、哪里要改。代码是 Claude Code 写的，产品是你设计的。这就是 AI 时代的协作方式：你负责「做什么」，AI 负责「怎么做」。
拆分任务很关键。 如果上来就说「帮我做一个笔记工具」然后什么都不管，结果大概率会偏离你的想法。分步骤走、每步确认，最终结果反而更好、更快。
它会犯错，但修复很快。 报错不可怕。关键是你不需要自己定位问题——告诉它出错了，它能自己分析和修复。对于不会编程的人来说，这个价值尤其大。
上下文在积累。 因为 Claude Code 一直在你的项目目录里工作，后面加功能时，它会自动遵循之前建立的模式。不需要你每次都重复解释项目结构和代码风格。
四篇下来，你已经走过了一个完整的学习路径：
现在你对 Claude Code 应该有了直觉层面的理解——它能做什么、怎么和它配合、什么时候它很靠谱、什么时候需要你多留个心眼。
接下来可以做两件事：
自己动手试一个项目。 把你脑子里那个「一直想做但觉得太麻烦」的小工具拿出来，用 Claude Code 试试。你会发现，很多以前觉得「我不会编程所以做不了」的事情，现在真的能做了。
继续读日常使用篇。 下一篇讲 CLAUDE.md——它可能是 Claude Code 最重要的配置文件。写好 CLAUDE.md，就像给你的 AI 搭档发了一份详细的入职文档，让它从第一句话开始就知道你的项目规则和偏好。用好这个文件，你的 Claude Code 效率会再上一个台阶。