Vibe Coding实践：从零跑通Easy Vibe Task 02全流程-代码聚汇网

Vibe Coding实践：从零跑通Easy Vibe Task 02全流程

Vibe CodingAI辅助编程Flask

|难度：普通|阅读约 43 分钟

我从Datawhale组队学习群里看到Easy Vibe Task 02这个任务卡的时候，第一反应是"这名字起得真准"。Vibe这个词在编程圈最近确实火，它代表的是一种"用对话驱动代码生成"的工作方式，而Easy则点明了这个任务的定位——不是让你从零硬啃语法，而是通过一个足够简单的项目，把AI辅助开发的完整链路跑通。Task 02在整个学习路径里处在承上启下的位置：Task 01通常解决的是"认识和上手"，Task 02则开始真正逼你动手做东西。如果你正卡在"不知道从哪里开始问AI""生成了代码却跑不起来""跑起来了不知道怎么改"这种阶段，这篇内容就是为你准备的。

我花了一个周末完整复现了Easy Vibe Task 02的任务流程，中间踩了不少坑，也把组队学习群里高频出现的问题做了整理。这篇文章会按照我自己实际操作的顺序来写，把环境的搭建、与AI协作的完整流程、常见卡点的解决方案，以及隐藏在每个任务背后的学习逻辑都拆开讲清楚。不整虚的，全部是可复现的步骤和真实记录。

1. 先搞懂Task 02在学什么：从"看教程"到"动手做"的转折点

1.1 Easy Vibe是什么：Vibe Coding概念的通俗拆解

Easy Vibe本质上是Datawhale组队学习中关于AI辅助编程实践的一个项目代号。要理解这个任务，先得明白"Vibe Coding"到底是什么意思。这个词最早出现在2024年，指的是程序员不再逐行手敲代码，而是用自然语言向AI模型描述需求，由模型生成代码，人负责审查、测试、纠错和迭代方向把控。打个比方，传统编程像自己买菜、切菜、炒菜，每个环节都要亲力亲为；Vibe Coding则更像你当餐厅主厨，AI是你的帮厨，你告诉它"今天要做一道少油版的鱼香肉丝"，它负责洗菜切菜配好料，你最后把关口味和出锅火候。

Easy Vibe这个项目名称中的"Easy"，我理解包含两层含义。第一层是工具链的Easy——整个任务使用的开发工具和AI辅助插件，安装和配置门槛已经被压到很低，只要按步骤走，基本不会卡在环境问题上。第二层是任务难度的Easy——它刻意选择了一个业务逻辑简单的应用场景作为实践载体，让你把注意力集中在"如何与AI高效协作"这件事上，而不是被复杂的业务逻辑带偏。这种设计非常有Datawhale组队学习的风格：先保证你跑通，再谈优化和深度。

Task 02在这个项目里承担的具体任务，是把"AI辅助编程"这个概念从理论推向实践。它不要求你学会所有编程知识，而是要求你完成一个功能完整的微项目。这个微项目通常包含前端页面、后端逻辑、数据交互这几个基本元素，麻雀虽小五脏俱全。你会在这个过程中经历需求描述、代码生成、运行调试、功能迭代的完整闭环，这是任何纸上谈兵的教程都给不了的体验。

1.2 Task 01到Task 02的衔接逻辑：为什么说这是真正的"第一道坎"

组队学习的学习路径设计是有讲究的。Task 01通常是环境准备和工具熟悉，你安装了Python、配置了开发环境、注册了AI平台的API，也试着让AI生成了一两段"Hello World"级别的代码。这时候你的感觉可能是"就这？好像也不难"。但Task 02会立刻把难度拉到一个真实项目的维度——AI生成的代码不再是几行演示代码，而是几十个文件、几百行代码组成的完整应用。这种跨度的跳跃，会让很多人第一次产生"我是不是跟不上"的焦虑。

我在群里见过大量类似的求助帖："Task 01明明很轻松，Task 02生成了项目代码后根本跑不起来，报错信息看都看不懂。"这其实是正常现象。Task 01解决的是"你敢不敢用AI写代码"的心理门槛，Task 02解决的是"你能不能真正驾驭AI写代码"的能力门槛。两者之间有一道认知鸿沟：前者是单向的指令下发，AI生成什么你用什么；后者则需要你具备基本的代码阅读能力、问题定位能力和需求拆解能力，才能和AI形成真正的协作闭环。

所以，如果你在做Task 02时感到吃力，不要急着怀疑自己。这不是你不行，而是任务设计本身就把这里设定为一个需要跨越的台阶。Task 02的真正价值不在于最后的成品代码多漂亮，而在于你经历的那几次"报错—排查—修复—再报错"的循环。每一次循环，都是你和AI协作默契度的一次提升，也是最接近真实开发场景的珍贵训练。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 动手前的准备：把基础环境一次性配到位

2.1 开发环境的三件套：Python版本、包管理器与代码编辑器

进入Task 02的实操环节，第一步是确认开发环境的完备性。虽然Easy Vibe任务在设计上尽量降低了环境门槛，但有几个基础组件是绕不开的。我在实际操作中发现，很多同学遇到的问题并非AI生成的代码有误，而是基础环境本身存在隐患，导致后续排查方向被带偏。

首先是Python版本。建议使用3.10及以上版本，一方面是因为较新的AI生成代码可能使用了一些新语法特性，另一方面是很多依赖库对Python版本的兼容性有明确要求。检查版本的方法很简单，在终端执行python --version或python3 --version，确认输出的版本号符合预期。这里有个小细节值得注意：Windows系统可能需要使用py命令来启动Python，macOS和Linux系统则通常直接使用python3，不同系统的命令差异会在后续执行脚本时频繁遇到。

其次是包管理器。我推荐使用pip结合虚拟环境工具。虚拟环境的重要性很容易被初学者忽视，但在Task 02这种依赖较多的项目中，它能避免不同项目间的包版本冲突。创建和使用虚拟环境的命令如下：

bash复制# 创建虚拟环境
python -m venv easyvibe_env

# 激活虚拟环境
# Windows下激活
easyvibe_env\Scripts\activate
# macOS/Linux下激活
source easyvibe_env/bin/activate

# 退出虚拟环境
deactivate

激活后，终端提示符前面会出现(easyvibe_env)字样，这说明你现在处于独立的虚拟环境中。在这个环境里安装的所有Python包都不会污染系统全局环境，也不会被其他项目干扰。这一步是我反复建议组队成员不要跳过的，因为它能在后期省下大量排查依赖冲突的时间。

第三是代码编辑器的选择。VS Code是绝大多数组队学习成员的首选，它免费、跨平台、插件生态丰富，尤其对AI辅助编程的支持非常好。需要安装的关键插件包括Python扩展（为代码提供语法高亮和运行支持）、GitHub Copilot或通义灵码等AI编程助手插件（提供代码补全和对话能力），以及REST Client或Thunder Client这类API测试插件（用于测试后端接口）。安装插件的路径是左侧活动栏的扩展图标，搜索插件名称点击安装即可，整个过程不需要额外配置，装完重启编辑器就能生效。

2.2 AI辅助工具的选择与配置：把"工具"调成趁手状态

Task 02的核心是AI辅助编程，所以AI工具的选择和配置直接决定任务体验。目前主流的选择大致可以分为两类：一类是依托于云端API的通用大模型对话服务，你通过网页端或API调用它生成代码；另一类是深度集成在IDE中的AI编程助手插件，你直接在编辑器里和它对话，生成的代码可以直接插入当前文件。我的建议是两者搭配使用：IDE插件负责写代码，通用大模型对话服务负责解答概念性问题、排查报错和逻辑设计讨论。

以VS Code配合通义灵码插件为例，配置过程大致如下。首先在插件市场搜索"通义灵码"并安装，安装完成后VS Code会自动检测登录状态，按提示使用账号登录即可。登录成功后会有一个欢迎页，说明它的核心功能：行级代码补全、函数级生成、多文件代码修改、代码解释、单元测试生成。使用时按以下快捷键呼出对话面板：

bash复制# 呼出AI对话面板
Ctrl + Shift + I (Windows/Linux)
Cmd + Shift + I (macOS)

如果你选择使用GitHub Copilot，配置方式类似，但需要先在GitHub Settings里启用Copilot服务，然后在VS Code中登录GitHub账号并授权，等待图标变为"已就绪"状态即可。选型上需要注意的是，不同AI工具的上下文理解能力有差异。Task 02涉及多文件项目，建议选择上下文窗口较大、支持跨文件感知的AI助手，否则它在处理逻辑关联较强的代码时，容易出现"改一个文件却不管另一个文件"的割裂情况。

在开始Task 02正题之前，我额外补充一个配置建议：提前为AI助手设定一个"行为偏好"描述。例如你可以在对话开始时告诉它："你是一名Python后端开发者，请编写代码时添加清晰的中文注释，并使用Flask框架。"这种前置设定能显著提升生成代码的规范性和可读性，也减少了后续反复要求修改的沟通成本。

3. 核心瓶颈：把任务需求拆解成AI能听懂的语言

3.1 建模思维：不要直接让AI"做个网站"，而是描述清楚功能边界

很多同学在Task 02的第一步就犯了一个认知错误——把整个项目需求一口气抛给AI，让AI直接生成完整项目。这种操作方式往往会得到一堆看似合理但跑不起来的代码，因为AI在理解复杂需求时会按照平均概率补全细节，而你的具体业务场景往往偏离它的预设。

正确的做法是拆解。以一个常见的Easy Vibe微项目——"简易待办事项应用"为例，我建议将需求拆成如下模块，逐个与AI沟通：

模块	功能描述	与AI沟通的切入点
后端接口	实现任务的增、删、改、查	定义数据结构、接口请求方式、响应格式
数据存储	数据持久化方案	选择SQLite、JSON文件或内存存储
前端页面	展示任务列表、交互入口	页面布局、表单设计、交互逻辑
前后端连接	页面与接口的数据交互	跨域配置、请求封装、渲染逻辑

每个模块作为一个独立的对话回合，与AI逐步沟通。这样做的价值在于，每个回合的上下文聚焦特定模块，AI生成的代码在逻辑完整性上明显优于一次性生成。同时，你也更容易在某个模块出现问题时定位并修复，而不必对着整个项目大海捞针式找错。

这里我总结了一套我自己采用的需求描述模板，供你和组队成员参考：

text复制请实现一个[模块功能描述]。
- 输入：接收[具体输入格式，如JSON请求体]，字段包括xx、xx、xx
- 处理：执行[具体逻辑，如对输入数据进行合法性校验，然后写入数据库]
- 输出：返回[具体响应格式，如JSON对象]，包含状态码status和业务数据data
- 技术要求：使用[框架/库名称]，代码添加中文注释

这套模板的关键在于"三明确"：明确输入、明确处理逻辑、明确输出格式。AI在拿到这类结构清晰的需求时，生成代码的准确率会明显提升。更重要的，这种描述方式也在训练你自己的需求表达能力——这是AI辅助编程时代最核心的软技能。

3.2 设计任务与AI协作时的"最小闭环"原则

这里再说一个实战中总结出来的经验：与AI协作开发时，不要试图在一次对话中完成所有功能，应该遵循"最小闭环"原则——先跑通一个最简单的完整流程，再在此基础上叠加功能。

以待办事项应用为例，最小闭环可以是"后端接收新增请求→数据写入存储→查询接口返回数据→前端页面展示"。这四步构成一个完整的、可从输入到输出验证的业务循环。当你和AI一起把这个闭环跑通，再进入"删除功能怎么做""编辑功能在哪改"的迭代阶段，每一步的改动量小、影响范围可控、问题定位容易，不会出现改一处代码导致十处报错的连锁反应。

这个原则在AI辅助编程中的意义比传统编程更大。因为传统编程中你对自己写的每一行代码都有完整的心智模型，改动时能做全局推演；但AI生成的代码你并不完全了解内部实现，改动时的不可控风险更高。通过"最小闭环+小步迭代"的策略，你始终把不确定性控制在可观测、可回退的范围内。

具体操作时的顺序建议如下：

先让AI生成后端接口，用API测试工具单独验证接口的增删改查是否正常
再让AI生成前端页面，先写静态页面，确认布局和交互是否符合预期
最后让AI连接前后端，此时如果出现跨域或数据格式问题，你可以明确知道问题出在连接层，而不是业务逻辑层
每完成一步，运行一次程序，留下一个可运行的程序快照

这个流程看起来慢，实际上比"全部写完再一起调试"快得多。我实测过，按照"最小闭环"推进，一个简单应用从零到可运行大约需要2到3个小时；而一次生成完整项目的做法，调试时间平均在4小时以上，而且挫败感会高很多。

3.3 提示词工程入门：如何追问、纠错与引导

Task 02中你很大一部分时间花在"追问"和"纠错"上。AI生成的代码第一次运行就完全不出错的情况非常少见，更多时候是运行报错、逻辑不符、格式错误等问题。很多同学在这个环节会手足无措，直接把报错信息原封不动丢给AI，然后对着AI给出的修复方案看得一头雾水。

高效纠错的第一个关键点：不要只贴报错信息，还要附上上下文和你的目标。有效的提问格式是：先说明"我要实现什么功能"，再说明"当前代码做了什么"，最后贴出"运行时报错的具体信息"。这三个信息组合起来，AI才能准确定位问题根源。比如下面这样：

text复制我需要在Flask应用中实现一个删除任务的功能。
当前代码中我在前端点击删除按钮时，浏览器控制台报404错误。
删除接口的代码是：[粘贴代码]
后端路由的代码是：[粘贴代码]
请帮我分析一下404错误可能是什么原因，并给出修改建议。

这种提问方式比单纯贴报错信息有效得多。AI在理解了你完整的业务逻辑后，给出的修复建议往往能一步到位，而不是给你一个针对某一行代码的局部修补。

第二个关键点是学会验证AI的回答。AI给出的修复建议有时并不适用于你的代码版本或环境配置，你需要具备基本的判断能力。收到修复建议后，先理解它的逻辑：改的是哪部分？为什么这么改？有没有可能引入新问题？确认没问题后再动手修改。在这个过程中，你可以继续追问AI"请解释一下这样修改的原因"，这不仅能验证AI的建议是否合理，也能帮助你真正理解这段代码的工作原理。

第三个关键点是使用"代码解释"功能。当AI生成了一段你不理解的代码时，直接让它"逐行解释这段代码的逻辑"。AI会输出详细的逐行注释，这是学习阅读代码的一种高效方式，也让后续的修改和调试变得更有把握。

4. 实操过程全记录：从创建虚拟环境到跑通第一个接口

4.1 项目初始化与依赖安装：代码还没写，先把"地基"打好

完成环境配置后，正式进入Task 02的项目初始化阶段。这个阶段的目标是搭建项目的目录结构和依赖清单，相当于建筑工程中的打地基环节。地基不牢，后期代码再多也容易塌。

我建议的项目目录结构如下：

text复制easyvibe_project/
├── app.py                 # Flask主应用文件
├── requirements.txt       # Python依赖清单
├── static/                # 存放前端静态文件
│   ├── css/               # 样式文件
│   └── js/                # 前端脚本
├── templates/             # HTML模板文件
│   └── index.html         # 主页面
└── data/                  # 数据存储目录
    └── tasks.json         # 任务数据文件（自动生成）

在项目根目录下创建虚拟环境并激活，然后在虚拟环境中安装依赖。对于一个基础的待办事项应用，需要的Python包比较精简：

bash复制# 安装Flask Web框架
pip install flask

# 安装Flask-CORS，处理前端跨域请求
pip install flask-cors

# 将已安装的依赖导出到requirements.txt
pip freeze > requirements.txt

Flask是一个轻量级的Python Web框架，非常适合作为Vibe Coding实践项目的载体，原因是它的路由定义简单直观，创建Web应用的代码量很少，即使没有Web开发经验的人也能通过AI生成的代码理解基本逻辑。Flask-CORS则是处理跨域问题的扩展包，当前后端分离时，没有它前端页面将无法正常请求后端接口。

安装完成后，可以用下面的命令检查安装是否成功：

bash复制python -c "import flask; print(flask.__version__)"

如果输出了版本号类似"3.0.x"的内容，说明Flask安装成功。requirements.txt文件记录了这个项目所有的依赖包及版本号，以后换一台电脑或在其他环境复现项目时，只需执行pip install -r requirements.txt就能快速恢复完整的依赖环境。

4.2 让AI生成基础后端代码：一次成功的对话记录

项目环境和目录结构准备好之后，开始让AI生成第一个核心代码文件——app.py。这个文件是整个应用的"心脏"，负责定义所有的后端接口和业务逻辑。

我使用的提示词如下，这里完整贴出以供参考：

text复制请使用Flask框架实现一个简单的待办事项应用后端，要求：
1. 数据存储使用JSON文件，文件路径为data/tasks.json
2. 支持以下接口：
   - GET /api/tasks：获取全部任务列表
   - POST /api/tasks：新增任务，请求体格式为{"title": "任务标题"}
   - DELETE /api/tasks/<int:task_id>：根据ID删除任务
3. 每个任务的数据结构包含id、title、completed、created_at四个字段
4. 所有接口返回JSON格式数据，包含status字段表示操作是否成功
5. 代码添加详细中文注释，方便新手理解
6. 端口设置为5000，开启debug模式方便调试

AI生成的代码的结构非常标准，包括Flask应用初始化、JSON数据读取和写入辅助函数、三个路由处理函数、以及主程序入口。在运行之前，需要确保data目录存在，否则程序首次运行时写入JSON文件会报目录不存在错误：

bash复制mkdir -p data

然后启动Flask开发服务器：

bash复制python app.py

启动成功的标志是终端输出如下内容：

text复制 * Running on http://127.0.0.1:5000
 * Running on http://127.0.0.1:5000

看到这个输出，说明后端服务已经跑起来了。这时候可以去浏览器访问http://127.0.0.1:5000/api/tasks，如果返回了一个空列表{"status": "success", "data": []}，说明后端接口工作正常。这个时刻是整个Task 02中最让人兴奋的瞬间之一——你一行代码都没手写，但一个运行中的Web服务已经诞生了。

4.3 验证接口功能：用API测试工具完成增删改查

后端服务启动后，不要急着写前端页面，先用API测试工具把所有接口验证一遍。推荐使用VS Code的Thunder Client插件或直接使用命令行工具curl，两者的效果类似，选择顺手的方式即可。

以curl命令为例，按顺序执行以下操作：

bash复制# 新增两个任务
curl -X POST http://127.0.0.1:5000/api/tasks \
  -H "Content-Type: application/json" \
  -d '{"title": "学习Flask"}' 

curl -X POST http://127.0.0.1:5000/api/tasks \
  -H "Content-Type: application/json" \
  -d '{"title": "完成Task 02"}'

# 获取全部任务列表
curl http://127.0.0.1:5000/api/tasks

# 删除ID为1的任务
curl -X DELETE http://127.0.0.1:5000/api/tasks/1

# 再次获取列表，确认删除成功
curl http://127.0.0.1:5000/api/tasks

正常情况下，第一次GET请求返回两个任务，DELETE执行后再次GET只返回一个任务。完整的增、删、查流程验证通过，后端逻辑基本没有问题。这个步骤之所以重要，是因为它把"后端逻辑正确性"和"前端展示问题"分离开来：如果后端接口验证通过，后续前端页面出现异常时，问题范围就锁定在纯前端层面，排查效率会高很多。

验证完成后，在data/tasks.json文件中会看到如下格式的数据：

json复制{
  "tasks": [
    {
      "id": 2,
      "title": "完成Task 02",
      "completed": false,
      "created_at": "2025-01-15 14:30:22"
    }
  ]
}

看到这个文件自动生成了数据，说明整个"请求→处理→持久化"的数据闭环已经建立。这是后端开发中最核心的概念——数据不是存在内存里而是落到了磁盘上，即使重启服务，数据也不会丢失。

4.4 前端页面的生成与修改：AI生成的代码如何"为我所用"

后端接口验证通过后，开始生成前端页面。前端部分的实现涉及HTML、CSS和JavaScript三种技术的配合，HTML负责页面结构展示，CSS负责美化样式，JavaScript负责和后端接口交互。对于没有前端开发经验的初学者，一次性让AI生成完整的前端代码很容易失控，所以这里依然建议分步骤进行。

第一步，让AI生成页面结构。提示词示例：

text复制请生成一个待办事项管理页面的HTML代码，要求：
1. 页面顶部是标题"我的待办事项"
2. 中间有一个输入框和一个"添加"按钮
3. 下方是任务列表区，每个任务项显示标题、创建时间和"删除"按钮
4. 引入CDN的Bootstrap样式，让页面看起来简洁美观
5. 先在静态HTML中写死两个示例任务用于预览布局效果

生成后的HTML代码保存到templates/index.html中。这一步的重点是确认页面的布局和静态样式符合预期，不涉及任何数据交互逻辑，复杂度低、易于调整。

第二步，让AI生成前后端交互逻辑。提示词示例：

text复制在上面的HTML页面基础上，添加JavaScript代码实现以下功能：
1. 页面加载时，使用fetch发送GET请求到http://127.0.0.1:5000/api/tasks获取任务列表，并渲染到任务列表区
2. 点击"添加"按钮时，读取输入框内容，使用fetch发送POST请求到http://127.0.0.1:5000/api/tasks，成功后重新加载列表
3. 点击任务项右侧的"删除"按钮时，使用fetch发送DELETE请求到http://127.0.0.1:5000/api/tasks/{id}，成功后重新加载列表
4. 使用async/await处理异步请求，添加try-catch捕获错误，并在控制台打印错误信息
5. 删除按钮使用Bootstrap的danger样式

然后让AI"将JavaScript代码整合到index.html中，与原有的HTML结构拼接成完整的单文件页面"。生成的完整代码就是一个可直接运行的前端页面，保存后直接替换原来的templates/index.html。

第三步，启动测试。确保Flask服务仍在运行，浏览器访问http://127.0.0.1:5000/，打开开发者工具（通常按F12），切换到Network标签页，此时你应该看到页面成功发出GET请求且返回200状态码，页面正确显示了之前通过接口添加的任务数据。整个过程验证通过，一个前、后端联通的应用就诞生了。

这里特别提醒一个常见问题：如果浏览器控制台报CORS跨域错误，说明前端页面请求被浏览器安全策略拦截了。原因通常是Flask-CORS插件没有正确加载。检查app.py代码中是否有以下两行：

python复制from flask_cors import CORS
CORS(app)

如果没有，通过AI生成的代码往往会在早期就包含CORS配置，但如果你在生成过程中自己修改过代码，可能会不小心删掉这些配置。发现缺失时，把上述两行添加到app.py中重启服务即可解决。

5. 组队学习中被问爆的5个卡点与解决方案

5.1 虚拟环境激活失败或命令找不到

组队学习群里最常出现的问题是虚拟环境相关命令执行报错。Windows系统和macOS/Linux系统的激活命令不同，如果混用就会出现"找不到activate脚本"的报错。Windows系统在PowerShell中执行激活命令可能遇到脚本执行策略限制，这时需要以管理员身份运行PowerShell并执行Set-ExecutionPolicy RemoteSigned，或者直接使用命令提示符（cmd）执行激活命令。

另外，有些同学创建虚拟环境的命令可能有问题。确认当前目录是否正确很重要——必须进入项目目录后再执行python -m venv easyvibe_env，否则虚拟环境会创建在错误位置。如果以上方法都无效，可以尝试使用conda环境管理工具，它跨平台兼容性更好，命令统一为conda create -n easyvibe python=3.10和conda activate easyvibe。

5.2 Flask服务启动失败，显示"Address already in use"

这个报错说明5000端口已经被其他程序占用了。解决方法是换一个端口启动，不再使用默认的5000端口：

bash复制# 指定端口为5001启动
python app.py --port 5001

同时，前端JavaScript代码中请求的URL也要同步修改为http://127.0.0.1:5001/api/tasks。这种情况在多次重复实践中很常见——旧的服务进程没有完全关闭，再启动新进程时就会端口冲突。这里我建议养成一个好习惯：每次修改完代码需要重启服务前，先确认旧进程已经停止：

bash复制# 查看占用5000端口的进程PID
lsof -i :5000   # macOS/Linux
netstat -ano | findstr :5000   # Windows

# 根据PID强制结束进程
kill -9 进程PID   # macOS/Linux
taskkill /PID 进程PID /F   # Windows

5.3 前端请求返回500错误，但后端接口本身测试正常

这种情况通常意味着前端发送的数据格式和后端期望的格式不一致。前端在发送POST请求时，需要显式指定Content-Type: application/json头，并且使用JSON.stringify()将JavaScript对象转换为JSON字符串。如果这两个步骤缺失，后端接收到的可能是一个字符串而不是JSON对象，解析时就会抛出异常，返回500错误。

修复方法是在fetch请求中确保以下配置正确：

javascript复制const response = await fetch('http://127.0.0.1:5000/api/tasks', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ title: taskTitle })
});

这也是常见的数据类型不一致问题，排查思路是先在浏览器控制台打印请求的body内容，确认格式是否符合后端要求，再决定修改前端还是后端。

5.4 AI生成的代码里包名或变量名拼写错误

AI不是万能的，它生成的代码偶尔会出现变量名拼写不一致的问题——在某个函数中使用了taskId，在另一个函数中却写成了task_id，运行时就会报NameError或ReferenceError。解决方法是让AI自己完成检查，把报错信息发给它，它会很快定位到拼写不一致的位置并给出修改建议。

更好的做法是在开发过程中养成一个习惯：写完一个完整功能后，让AI"请审查一遍这段代码，检查是否存在变量名不一致或逻辑漏洞"。相当于免费获得一次代码评审。

5.5 不知道下一步该问AI什么

这是新手最普遍的问题，本质上是因为对开发流程没有整体认知，不知道该在什么阶段做什么事情。我的建议是不要从"代码怎么写"出发，而是从"我下一步要验证什么功能"出发。想清楚这个问题，问AI的问题自然就有了。如果你不知道功能优先级怎么排，可以直接问AI："请帮我梳理一个待办事项应用从简单到复杂的功能迭代顺序，并说明每个阶段应该优先实现什么。"让AI来帮你规划是合法且高效的做法。

6. Task 02完成后：怎么验证自己真的学到了东西

6.1 一个简单的自测：独立完成一个"变体项目"

Task 02的官方任务可以通过组队打卡来确认完成，但我始终建议给自己加一个变体练习，才能真正检验是否掌握了AI辅助开发的核心能力。操作方法很简单：把任务场景换掉，但技术栈不变。例如你之前做的是待办事项应用，这次改成"个人记账本"或"学习笔记管理"应用，数据结构从"任务"换成"账目"或"笔记"，接口从增删改查变成统计功能。其他部分——Flask框架、JSON文件存储、前后端分离架构——完全复用。

独立完成这个变体项目时，记录自己是否能在不借助他人帮助的情况下，独立完成需求分析、和AI协作编码、运行调试的全流程。如果能，说明Task 02的能力目标你已真正掌握；如果中途卡住，卡住的位置就是你需要回炉复习的重点。

6.2 构建属于自己的"常用提示词库"

经过Task 02的完整实践，你手里会积累一批非常顺手的提示词，它们帮助你成功生成了后端接口、前端页面、数据交互逻辑。这些提示词就是你个人"AI辅助开发工具箱"的起步资产。我建议用Markdown文件或代码笔记工具对它们分门别类保存，建立自己的提示词库：

text复制后端接口生成提示词
前端页面生成提示词
错误分析提示词
需求拆解提示词
代码注释提示词

这些提示词其实比代码本身更有复用价值。代码会随不同项目略有调整，但提示词的内在逻辑——如何清晰描述需求、如何设计约束条件、如何规划迭代步骤——在任何项目中都能复用。

6.3 为后续任务打基础：把"Ask for diff"变成肌肉记忆

Task 02之后，你会发现AI辅助开发的协作模式会贯穿整个学习的后续阶段。而构成这种协作模式的基础，是一个看似简单却至关重要的习惯——每次AI给出修改建议时，让它明确展示"改动前后的差异"。

text复制请使用diff格式展示需要修改的代码，并逐行解释修改原因。

这个习惯的价值在Task 02阶段可能还感受不明显，因为项目小，修改影响范围有限。但当项目规模扩大到十几个文件时，能精确区分"改了哪里、为什么改"就显得至关重要。Task 02正好是培养这个习惯的最佳时机——项目复杂度恰到好处，既能让你理解diff信息中每一行的含义，又不会因修改范围过大而不知所措。

我在实际完成Task 02并复盘这次组队学习体验时，最深的一点感受是：Easy Vibe这个名字起得非常准确，但这种轻松感不是凭空来的，而是来自任务设计对学习者真实困难的精准把握。它用巧妙的学习路径和工具链，把AI辅助编程的门槛降低了，但该有的能力训练一步都没少。你完整走完一遍，获得的不仅是一个可以运行的项目，更是一种更符合时代节奏的开发思维——让AI做它擅长的事情，你专注做有创造力的决策。