Claude Code 入门：用四个小项目练会 AI 编程工作流

01问题引入：这不是“学语法”，而是换一种交付方式

这期视频面向的不是已经会写大量代码的工程师，而是想用 Claude Code 把具体工作流做成小软件的人。讲者没有从 API、框架或算法开始，而是连续构建四个很小但完整的项目：个人落地页、Chrome 右键摘要扩展、图片自动文案脚本、浏览器本地习惯追踪器。它们覆盖网页、浏览器扩展、后台脚本和单文件本地应用，目的是让观众看到同一种 AI 编程循环如何迁移到不同形态的工具。

真正值得看的地方在于，它把 Claude Code 解释成一种“描述目标、审阅计划、让模型写代码、再用视觉或错误反馈迭代”的工作方式，而不是把它包装成万能程序员。视频反复强调：人仍然要负责判断结果是否好、需求是否具体、什么时候该换模型、什么时候该重开上下文。这比“让 AI 一键写 App”的宣传更有实践价值。

可以把视频的核心观点转述为：Claude Code 不会让你自动变成软件工程师，但它能让你用自然语言快速验证一个具体工具是否值得继续投入。

02核心概念：Opus 负责思考，Sonnet 负责执行

视频最重要的操作模式是“先规划、再建造”。复杂一点的任务先切到 Opus，让它像资深架构师一样列出方案、文件结构、依赖和边界；确认计划后切到 Sonnet，让它按计划写代码。讲者用个人落地页和图片文案脚本演示这个交接：Opus 花更多 token 做判断，Sonnet 用更快速度落地实现。

这个模式不只是省钱技巧。它背后的工程含义是：当任务涉及多个文件、状态保存、API 调用或长期可维护性时，先把设计暴露出来，比直接让模型改文件更容易发现遗漏。反过来，如果任务很小，比如一个本地习惯追踪器或简单 Chrome 扩展，就可以直接用 Sonnet，从一版可运行结果开始迭代。

另一个关键概念是 CLAUDE.md。视频里建议初始化项目上下文，让 Claude 生成项目记忆文件，避免每个 session 都重新解释文件结构、技术选择和偏好。对真实项目而言，这相当于给 AI 一份轻量级开发手册：它不保证模型永远正确，但能显著减少“忘记上文”和“重复踩坑”。

03四个项目怎么串起完整工作流

第一个项目是个人落地页。它用来展示基础安装和第一次生成：安装 Node.js、Claude Code 和 Cursor，登录 Claude，信任项目目录，安装 Claude Code 扩展，然后在 Cursor 里看到 Claude 修改哪些文件。讲者先让 Opus 规划，再切 Sonnet 执行，最后用 Live Server 或直接拖拽 HTML 到浏览器验证页面。这一步训练的是“先让模型把结构想清楚，再让它写”的基本肌肉。

第二个项目是 Chrome 摘要扩展。提示词要求 Claude 生成一套浏览器扩展文件：选中网页文本后右键出现 summarize 菜单，点击后调用 OpenAI API，把选中文本压缩成三句话。这个例子很适合初学者，因为 Chrome 扩展本身文件数少、交互清晰，安装方式也具体：打开扩展页面、启用开发者模式、加载 unpacked 文件夹。视频强调的是“为一个非常具体的个人痛点做工具”，而不是泛泛做一个聊天机器人。

第三个项目是图片文案自动化脚本。它监听本地文件夹，发现新图片后调用 OpenAI Vision API，分别生成 Instagram 和 LinkedIn 风格的文案，再把结果写入同名 txt 文件。这个项目让观众理解 Claude Code 不只能做前端页面，也能写在本机后台运行的小自动化。更重要的是，出错时把错误粘回 Claude Code，让它定位行号和修复实现，这才是日常使用中最常见的循环。

第四个项目是本地习惯追踪器。它是一个不用服务器、双击即可打开的浏览器单文件应用，数据保存在本地。讲者随后要求 Claude 增加最长 streak 统计和新纪录礼花动画，用它演示“先出可用版本，再一点点打磨”的体验。这里的人类角色更像产品负责人：决定保留什么、删掉什么、怎样才算顺手，而不是逐行写实现。

04决策矩阵：什么时候用哪种 Claude Code 模式

场景	推荐模式	优点	风险与提醒
跨 3 个以上文件、需要状态设计或 API 边界	先 Opus 计划，再 Sonnet 实现	更容易提前发现结构问题，减少返工；适合落地页、后台脚本、复杂自动化。	Opus 成本更高，计划需要人工审阅，不能把计划当作事实保证。
简单单文件应用或明确的小功能	直接 Sonnet 生成第一版	速度快，反馈周期短，适合习惯追踪器、简单表单、一次性小工具。	需求太模糊时会生成“看起来能跑但不好用”的结果，需要快速验收。
视觉样式不符合预期	截图或 Figma 导出 + 明确修改目标	Claude 能同时看图和读项目文件，容易定位要改的组件与样式。	不要只说“更好看”；要指出字号、间距、色彩、按钮状态等具体变化。
错误连续修不好	压缩上下文或新开 session	清掉噪声后更容易让 Claude 聚焦关键代码和报错。	同一问题连续修三次仍失败时，不要继续堆聊天记录，重述问题更有效。
试探某个业务想法值不值得投开发资源	用 Claude Code 做下午级原型	快速给真实用户看可运行版本，避免只停留在需求文档。	金融、医疗、安全敏感后台不应只靠 AI 原型上线，需要专业工程审查。

05容易被忽略的五个新手坑

第一，不初始化项目记忆。没有 CLAUDE.md，每次新会话都像从零开始，Claude 很容易忘记技术栈、命名约定和你已经做过的选择。视频建议先运行初始化，让项目规则固化下来。

第二，提示词太抽象。“让它好看一点”几乎没有约束，模型只能猜。更好的说法是指出页面哪一段、哪种视觉问题、期望改成什么，例如“hero 字体太重，换轻一点并增加行距”。

第三，复杂任务跳过计划模式。如果一个任务会碰多个文件，模型边写边发现结构不对，就容易重复改动。先进入 plan mode，把文件清单、依赖和步骤确认下来，通常更稳。

第四，不主动压缩上下文。长会话里堆了大量尝试、废弃方案和错误输出后，模型可能开始循环或给出互相矛盾的答案。中途 compact 相当于保留关键决定、清掉噪声。

第五，在坏上下文里反复修同一个问题。如果 Claude 连续两次修不好同一处错误，问题可能不是代码本身，而是上下文已经被污染。新开会话，只贴相关代码和报错，往往比继续原会话更快。