第一周工作流：把 AI 编程工具真正嵌进日常开发节奏

很多人装了 AI 编程工具，用两天之后就悄悄回到了老习惯——该怎么写还是怎么写，工具吃灰。这不是意志力问题，是没有把工具嵌进日常开发节奏的问题。

装好工具是第一步，但"装好"和"会用"之间有一段距离，叫做习惯形成期。心理学研究普遍认为，建立一个新习惯需要至少两周的有意识重复。第一周最关键，也最容易掉链子。这篇给你一套明确的七天节奏，让工具从"偶尔试试"变成"每天都在用"。

---

为什么装了工具不等于会用

根本原因是工具没有和你的真实工作发生接触。

很多人第一次用 AI 编程工具是这样的：打开工具，输入一个"帮我写个 hello world"，看到输出，心想"哦挺好用的"，然后关掉，继续用老方法写代码。

这种体验有两个问题：

问题一：用的是玩具任务，不是真实任务。 "写个 hello world"没有任何上下文，也不需要 AI 去理解你的代码库。这跟你真正开发时面对的问题差距很大，自然感受不到价值。

问题二：没有触发使用时机。 真正有价值的使用场景是：你正在写一段样板代码、正在看一个报错看不懂、正在要补一个函数的测试……这些时机每天都在发生，但如果你没有"先问一下 AI"的反射，工具就永远待在后台。

解决这两个问题的方法，就是用真实任务、在真实时机、建立真实触发——这正是第一周节奏要做的事。

---

第一周节奏：七天做什么

Day 1 ——装好，跑通，别急着做更多

目标只有一个：让工具在你的真实项目里跑通一次。

选一个你现在正在开发的项目（不是新建一个练手仓库），cd 进去，启动工具，问一个和这个项目有关的问题。比如：

• "Claude Code：帮我解释一下这个文件在整个项目里是干什么的"
• "帮我看看 README，总结一下这个项目的结构"
• "这个函数的参数有什么问题"

不需要让它改代码。今天的任务就是完成一次真实对话，感受它对真实项目的理解能力。完成后，把这个时间记下来——大多数人第一次真正在真实项目里用 AI 工具，都会被它的理解深度吓到。

Day 2 ——用它改一个真实的小需求

今天找一个你本来打算自己写的小需求，把它交给 AI 来做。标准是：

• 功能清楚，可以用一两句话说明白
• 如果你自己写，大概需要 10-30 分钟
• 改完之后你能看懂和审核产出

比如："在 user.js 里加一个 validateEmail 函数，用正则校验，加上对应的测试"。

交出去，等结果，认真审核产出——不是扫一眼，是真的读代码，确认逻辑对，测试覆盖有意义。今天的核心不是省时间，而是建立"交出去→拿回来审"的工作流感知。

Day 3 ——学会喂上下文，学会审产出

上下文是 AI 编程工具最核心的变量。今天专门练这个。

找一个昨天交给 AI 但结果不够好的任务，或者找一个新任务，刻意练习怎么描述需求：

• 不好的描述："帮我写一个处理订单的函数"
• 好的描述："在 src/services/order.js 里，帮我写一个 processRefund 函数，入参是 orderId（string）和 amount（number），调用 paymentService.refund() 方法，处理失败时需要记录日志到 logger.error，返回 { success: boolean, message: string }"

注意差别：好的描述包含文件路径、函数名、参数类型、调用哪些已有方法、返回格式。信息越具体，产出越接近你想要的。

今天另一个练习是审产出的纪律：产出之后，至少检查三件事：逻辑是否正确、边界情况是否处理、命名是否符合项目风格。这个习惯要从第一周就建立，不能养成"AI 写的应该没问题"的懒惰心态。

Day 4 ——用它做一个小项目（上）

连续两天，把一个你正在做或者计划做的小功能交给 AI 来主导实现。标准是：

• 需要改 2-5 个文件
• 有明确的输入和输出
• 你能完整审核

全程参与，但让 AI 先出方案、先写代码、先写测试，你负责审核和指导方向。

这两天是第一周最重要的部分。你会开始感受到：AI 工具的生产力不在于帮你写单个函数，而在于帮你维持一个功能开发的完整循环——方案、实现、测试、联调，都有它的参与。

Day 5 ——用它做一个小项目（下）+ 遇到问题怎么办

继续 Day 4 的任务，重点练习当 AI 产出不对时怎么纠正。

遇到错误不要直接 Ctrl+Z 全撤，而是：

1. 告诉它哪里不对（具体说，别说"这不对"，要说"这里的 userId 应该是字符串，你用了数字类型比较"）
2. 让它解释为什么这么做（有时候它的逻辑是对的，你理解了再决定要不要改）
3. 让它改，再看一遍

这个"指出→解释→修正"的循环，是和 AI 协作的核心技能。

Day 6 ——回顾哪些活适合交给它

今天不写新代码。回顾这五天：

• 哪些任务 AI 做得很好（耗时少、产出质量高、基本不用纠正）？
• 哪些任务 AI 做得不好（要改很多次、产出和预期差太多）？
• 有没有哪些应该用但没用 AI 的时机？

把这些写下来，哪怕就是几条记录。这个复盘会让你明白自己应该在哪里投入更多使用习惯的培养。

Day 7 ——把触发器固定下来

今天的任务是给自己设定几个明确的"先问 AI"触发时机，下周起遇到这些情况就反射性地开口问。

建议至少选三个触发器，比如：

• 每次遇到不认识的报错，先把错误信息完整贴给 AI
• 每次要写一个新函数，先问 AI 建议的参数设计和函数签名
• 每次要写测试，先让 AI 列出测试用例大纲，再自己填充

触发器越具体越好，"多用 AI"这种要求没法变成习惯，"遇到报错先问 AI"可以。

---

哪些日常开发动作最该先交给 AI

不是所有任务都适合先交给 AI。根据 ROI 排序，这五类是最值得优先交出去的：

1. 写样板代码（Boilerplate）

新建一个 Express 路由、一个 React 组件的骨架、一个数据库 Model 定义——这类代码格式固定、有套路、写起来无聊但容易出错。AI 写样板的质量稳定，基本不需要纠正，直接节省时间。

2. 查报错、理解异常

遇到看不懂的错误信息，把完整的 stack trace 贴给 AI，告诉它"这个报错在什么操作之后出现的"。AI 的排错速度通常比自己 Google 快很多，因为它能结合你的代码上下文来分析，而不只是泛泛解释错误类型。

3. 写测试

这是最能产生正向强化的场景。单元测试写起来枯燥，覆盖率容易偷懒，很多人会拖延。AI 写测试的质量普遍不错，覆盖边界情况的能力比你自己一拍脑袋想出来的要全。把"让 AI 先出测试大纲"变成每次写函数之后的固定动作。

4. 写注释和文档

函数的 JSDoc 注释、API 的文档字符串、README 里某个模块的说明——AI 写这类文字的速度远超手写，质量也够用。不要因为"写文档不是核心任务"就一直拖，交给 AI 五分钟搞定。

5. 小重构和代码清理

"帮我把这个函数的嵌套 if 改成更清晰的结构"、"帮我把这几个重复的工具函数合并"——这类任务很适合 AI，改动有限、效果明显、容易审核。Cursor 这类 IDE 工具对这类任务的上下文支持特别好，可以直接选中代码让它重构。

---

怎么建立"先问 AI 再自己写"的肌肉记忆

肌肉记忆的本质是降低触发成本。

现在你的默认状态是：遇到问题 → 自己想 → 自己写。要改成"遇到问题 → 先问 AI"，需要把"问 AI"的成本降到和"自己想"差不多低。

几个实用方法：

保持工具常开，不要每次用都要去找它。 在开发时 Claude Code 始终在终端里开着，Cursor 就是你的编辑器本身。消除"打开工具"这个步骤，就消除了一大半的阻力。

用快捷键和固定入口。 Cursor 的 Cmd+K（行内编辑）和 Cmd+L（对话）、Claude Code 的 / 命令——花半小时把这些快捷键练熟，让"开口问"这个动作的时间成本低于五秒。

接受"问了没用"的情况。 你问 AI，它给了一个不对的答案，你花了一分钟确认它不对，然后自己解决——这不是浪费，这是校准。随着你越来越懂怎么提问、哪类任务适合 AI，"问了没用"的比例会快速下降。

给自己设定一个"强制提问期"。 第一周的每天，强制自己在开始写任何超过 15 行的代码之前，先问一次 AI。不管问的好不好，先问。这个强制期过后，"先问"就会变成自然反应。

---

避免两个极端

极端一：啥都自己写，AI 白装

症状：装了工具，但每次遇到任务都觉得"这个我自己写更快"，结果工具吃灰。

这种想法在短期内往往是对的——你熟悉代码库，你知道自己想要什么，自己写确实快。但短期效率不等于长期生产力。AI 工具的价值在于累积效应：用得越多，你越会提问，产出质量越高，时间节省越明显。

破解方式：不要用"快不快"来决定要不要用 AI，改用"这类任务 AI 能做好吗"来决定。

极端二：啥都甩给 AI，产出失控

症状：把所有任务都交给 AI，不认真审产出，代码库里开始出现自己都看不懂的代码，或者 bug 在几层 AI 生成的代码里追不到根源。

这个极端更危险，因为它的早期症状不明显——速度很快，代码量很大，但技术债在悄悄积累。一旦出现复杂 bug，你发现自己对这段代码完全没有掌控感，那就出问题了。

破解方式：设定一个"必须自己审核"的底线——凡是涉及业务核心逻辑、数据安全、外部 API 调用的代码，不管 AI 写得多好看，都要亲自逐行读一遍，确认自己能解释每一行在做什么。

中间地带是：AI 来主导实现，你来主导审核。你的注意力从"怎么写"转移到"写得对不对、符不符合预期"——这个分工才是高效协作的正确姿势。

---

常见问题

Q：我用的是 Cursor 还是 Claude Code，这套节奏都适用吗？

都适用。Claude Code 是命令行工具，适合习惯终端、或者需要在项目级别操作文件和 git 的场景；Cursor 是 IDE，适合喜欢图形界面、想在编辑器里内嵌 AI 的场景。工具不同，但"用真实任务建立习惯"的方法是一样的。关于两个工具的选型对比，见 2.1 工具全景。

Q：第一周之后，怎么知道自己真的建立了习惯？

有一个简单的检验标准：遇到报错时，你是条件反射地先打开 AI，还是先打开搜索引擎？ 如果答案是前者，习惯初步建立了。如果还是后者，把 Day 7 的"触发器固定"再做一遍，更具体地定义你的触发条件。

Q：第一周感觉 AI 的产出经常不对，是我的问题还是工具的问题？

大概率两者都有。工具本身有局限，不是所有任务都能做好；同时，第一周的描述方式通常也还在摸索。区分的方法：同样的任务换一种描述方式再试一次，如果第二次明显更好，是描述问题；如果换了几种描述都差不多，是任务本身超出了工具能力范围，记下来就好，不要在这类任务上强求。喂好上下文的方法，可以看 3.1 上下文是一切，有更系统的讲解。

Q：第一周结束了，后面怎么进阶？

第一周解决的是"装了会用"的问题，后续的进阶是学会处理更复杂的协作场景：多文件重构、需求拆解与任务分发、用 AI 做 code review、把 AI 嵌进 CI/CD。这些在后续节里会逐步展开。一个好的起点是先把 Claude Code 上手的完整第一次 认真过一遍，确保基本操作没有盲区。

Q：Day 4-5 的"小项目"找不到合适的任务怎么办？

翻一下你的 issue 列表或者 TODO 注释。几乎每个项目里都有一堆"早晚要做但不紧急"的小功能，这类任务特别适合 Day 4-5 的练习——风险低、有完整需求、改完之后能上线验证。如果真的找不到，可以在现有项目里做一次"帮我找几处可以改善的代码质量问题，选一个最值得改的做掉"——让 AI 帮你找练习题。

---

下一步

第一周节奏把你带到了"每天都在用"的状态。接下来值得深入的方向：

• 理解上下文为什么是 AI 编程工具最核心的变量，系统学习怎么提问——3.1 上下文是一切
• 熟悉 Claude Code 的具体操作方式，确保基本功没有盲区——2.2 Claude Code 上手第一个项目
• 回到 AI 编程教程大全 对照全图，确认自己在哪个位置、下一步该学什么

---

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。