过去一年里，“让 AI 帮你写代码”早已不是新鲜事，但很多人用起来还是两个极端：要么把 AI 当搜索引擎，复制粘贴一段代码后完全不敢改；要么让它生成一大坨代码，跑起来全是报错，回头比手写还累。最近我在刷 deeplearning.ai 和 Coursera 上吴恩达老师的《Vibe Coding》课程时发现，这门课恰好把“用自然语言驱动 AI 编程”这件事讲得很系统，而且没有停留在“提示词技巧”层面，而是把 AI 辅助开发当成一套完整的工作流来讲。这篇文章就把我整理出来的课程核心内容、适合的人群、以及我自己动手跑通的完整代码示例放到一起，给想系统入门 Vibe Coding 的同学一份可落地的学习笔记。
作为开发者，我们真正缺的不是“会问 AI 要代码”，而是“知道如何把一个模糊想法逐步拆成 AI 能理解的任务”，以及“如何审查、验证、迭代 AI 生成的代码”。吴恩达这门课最大的价值，就是把前者拆成了可操作的步骤。本文会围绕 Vibe Coding 的背景、课程核心思路、提示词工程、上下文管理、代码评审、完整实战案例、常见问题与最佳实践展开，每一步都尽量给出代码和思路，方便你照着实践。
1. Vibe Coding 是什么：先理解本质
1.1 从“写代码”到“描述意图”
Vibe Coding 是近两年 AI 编程领域非常流行的概念，它的核心并不是“不用写代码”或者“代码完全由 AI 负责”，而是强调一种人和 AI 协作的新方式：开发者用自然语言描述业务目标、边界条件和验收标准，AI 模型负责生成代码草案，再由开发者进行评审、测试和迭代。
传统开发模式下，我们大脑里的“功能需求”要先翻译成精确的编程语言语法，再形成模块、函数、类，最后才能跑起来。这个过程有很多精力花在了“语法翻译”和“结构设计”上。而在 Vibe Coding 的工作流中，这一步被大语言模型接管了大部分。开发者更像是“产品经理 + 架构师 + 代码评审员”的混合角色：把需求描述清楚、把约束条件讲明白、审查生成的代码是否可靠。
1.2 Vibe Coding 和传统编程的区别
很多人误以为 Vibe Coding 就是“偷懒编程”，其实它和传统编程最根本的区别在于控制重心的转移：
| 对比维度 | 传统编程 | Vibe Coding |
|---|---|---|
| 主要工作 | 手动设计数据结构、编写函数、管理依赖 | 描述需求、拆解任务、评审 AI 生成代码 |
| 核心能力 | 语法、框架、算法 | 需求拆解、上下文管理、代码审查、调试验证 |
| 出错方式 | 编译器报错、运行时异常 | 模型幻觉、上下文丢失、代码不完整 |
| 迭代速度 | 取决于编码速度 | 取决于验证效率与提示词质量 |
| 适用人群 | 需要扎实编程基础 | 有一定基础，但更重视工程化思维 |
这里需要特别强调一下：Vibe Coding 并不等于降低对开发者的要求。相反，它提高了对开发者“工程判断力”的要求。你就把这想象成带一个效率极高的实习生：他写代码非常快，但可能理解错需求、会用错版本、写出有安全隐患的逻辑。你越能把需求表达清楚，越能快速评审和发现问题，这个实习生的产出质量就越高。
1.3 为什么吴恩达要单独开一门课
吴恩达（Andrew Ng）是 DeepLearning.AI 的创始人，也是 Coursera 的联合创始人。他在 AI 教育领域的影响力非常大，长期关注“AI 如何真正落地到开发者的日常工作”。这次在 deeplearning.ai 推出的 Vibe Coding 课程，本质上不是教你某个具体 AI 工具，而是教你一套可以迁移到不同 AI 编程工具上的方法论。
课程强调的核心观点是：AI 编程不是一个“复制粘贴”的过程，而是一个“说清需求 → 生成草案 → 评审验证 → 迭代优化”的闭环。这门课能在 Coursera 上开放，并且配有中文字幕，对国内学习者来说是非常难得的学习材料。
2. 课程解读：这门课在讲什么
2.1 适合谁去学
从我的学习感受来看，这门课特别适合以下几类人：
- 刚入门编程的学生：还没形成“写代码等于一切”的思维定势，可以直接建立正确的 AI 协作模式。
- 需要快速交付业务功能的后端开发者：日常有很多重复性 CRUD、脚本工具、数据处理任务，用 AI 辅助能明显提速。
- 对 AI 编程工具感兴趣但不知道从哪下手的开发者：这周 Vibe Coding 相关的热搜词、案例、讨论非常多，很多人都在问“vercel ai vibe coding platform 怎么用”“vibe coding guide 哪里有”。这门课恰好提供了比工具教程更底层的思路。
- 技术团队的负责人：需要评估 AI 编程对团队研发模式的影响。
2.2 课程会涉及哪些能力
虽然我不打算把课程做成“字幕逐句翻译”，但可以把课程拆解的几块核心能力直接提炼出来，方便你在动手实践时对照检查：
- 需求描述能力：把一个含糊的想法写成 AI 能理解的提示词，包含目标、输入、输出、约束、边界条件。
- 任务拆解能力：不要求 AI 一次生成完整项目，而是把一个功能拆成几个小步骤，逐步完成。
- 上下文管理能力：在对话过程中控制信息量，必要时提供代码片段、文件结构、报错信息，让 AI 不偏离方向。
- 代码评审能力：能看懂 AI 生成的代码，判断逻辑是否正确、边界条件是否覆盖、依赖是否合理。
- 迭代调优能力：根据报错信息或测试结果，精准地给 AI 反馈，而不是直接把报错整个丢进去。
2.3 学习前需要什么基础
课程本身对编程基础要求并不高，中文环境下很多操作都能跟上。但如果你希望课程中的示例能直接迁移到自己的项目里，建议先具备以下基础：
- 能看懂 Python 或 JavaScript 的基本语法；
- 会使用命令行安装依赖（pip 或 npm）；
- 理解文件读写、函数、数据结构这些基本概念；
- 了解版本控制（Git）的基本操作。
如果你没有这些基础，也不用太急，可以先按下面的实战示例走一遍，遇到不懂的概念再单独去查。
3. 核心方法论拆解：Vibe Coding 的四个关键动作
3.1 把需求“说清楚”：写提示词的黄金结构
Vibe Coding 的第一步，也是最容易被低估的一步，就是写提示词。很多人的提示词只有一句“给我写一个爬虫”，AI 给出的结果自然只能用“放飞”来形容。更高效的做法，是遵循一个稳定的需求描述结构。
下面是我从课程思路里提炼出来的“四要素”结构，你可以直接套用：
- 角色定义：告诉 AI 它应该以什么角色来完成任务。
- 任务目标：明确最终的交付物是什么，是脚本、函数、还是完整项目。
- 输入与输出：说清楚输入数据长什么样、输出格式是什么。
- 约束条件：包括技术栈、运行环境、边界情况、异常处理要求。
举个例子，我们后面会做一个 CSV 数据清洗脚本，合理的第一版提示词可以是这样的：
你是一位资深 Python 工程师。 请帮我编写一个 CSV 数据清洗脚本，输入是员工考勤 CSV 文件，包含字段： id、name、department、salary。 要求： 1. 按 id 去重，保留最后一条记录； 2. 删除 salary 字段为空的行； 3. 清洗结果输出到新的 CSV 文件； 4. 控制台打印清洗前后的记录数； 5. 使用标准库 pandas 以外的方案也可以，但需要说明依赖； 6. 代码需要包含 main 函数入口，并处理文件不存在的异常。注意，这段提示词并不是一次就生成的，它是在明确业务需求后自然总结出来的。写提示词的过程，本身就是梳理需求的过程。
3.2 让 AI 生成代码，但你必须能看懂
Vibe Coding 有一个很重要的原则：AI 生成的代码，你必须能看懂核心逻辑。如果你完全看不懂 AI 在做什么，那你根本无法判断它做得对不对。
课程里反复强调，AI 生成代码后的第一件事不是复制到项目里，而是“通读一遍，标出你理解和不理解的部分”。不理解的部分，可以继续向 AI 提问，让它解释，也可以要求它把代码写得更容易读。例如，你可以追加这样的指令：
请把上面的代码改成使用函数拆分，每个函数只做一件事，并加上详细的中文注释。 另外，对于代码中使用到的第三方库，请说明安装方式和用途。这一步的意义在于：让 AI 的输出变成你自己的代码资产，而不是一段来路不明的“黑盒代码”。在后面实战部分，我会专门演示一次“带着问题评审 AI 代码”的过程。
3.3 上下文管理：别让 AI 丢失方向
大语言模型在长对话中容易丢失早期信息，这也是很多人在 Vibe Coding 时最头疼的问题之一。你在第 30 轮对话时告诉 AI“第 3 步的输出格式改为 JSON”，它可能早就忘了第 3 步是什么。
课程给出的思路非常实用：
- 把关键约定放在每次提问的顶部：如果项目有固定的规范，比如“Python 3.10 + FastAPI”“不允许使用全局变量”“所有函数都要写类型注解”，可以在每次新开对话时，先把这些约定贴在前面。
- 阶段性汇总：当对话进行到一定阶段，让 AI 先汇总当前项目结构和已完成的代码，确认无误后再继续下一步。
- 及时开启新对话：如果当前对话已经很长，而且上下文混乱，果断新开一个会话，把项目说明文件作为附件或首段摘要喂给 AI。
- 善用项目说明文件：对于一个稍复杂的项目，可以先写一个
README.md或PROJECT_SPEC.md，把项目目标、目录结构、技术栈、已完成事项都写进去。每次新对话时，让 AI 先读这个文件。
这种习惯，会让你的 AI 协作质量明显提升。
3.4 不断迭代：提示词也要版本管理
把提示词当成代码来管理，是一个极其有价值但容易被忽视的习惯。第一次生成的代码不符合预期，是非常正常的。关键是你要能精准定位问题，然后给 AI 反馈。
反馈的原则是：
- 不要只说“不对”；
- 要告诉 AI 哪里不对、预期结果是什么、实际结果是什么；
- 如果有报错信息，直接贴报错；
- 如果需要修改某个函数，直接把该函数的现有代码贴进去，然后说明修改要求。
每一轮对话都是一次“小步迭代”，这和敏捷开发的理念完全一致。后面实战部分我会完整演示这个迭代过程。
4. 完整实战案例：从提示词到可运行代码
接下来我们进入本文的实操重点。我将演示一个真实的 Vibe Coding 工作流：用自然语言让 AI 帮我写一个 CSV 数据清洗 Python 脚本，并且在“不直接照搬 AI 结果”的前提下，完成代码评审和迭代优化。
4.1 创建项目结构
我们先在本地创建一个干净的目录，用来放实验文件。
mkdir vibe-coding-demo cd vibe-coding-demo创建一个输入数据文件employee.csv，内容如下：
id,name,department,salary 1001,张三,技术部,12000 1002,李四,产品部,15000 1001,张三,技术部,13000 1003,王五,运营部, 1004,赵六,设计部,11000 1002,李四,产品部,16000 1005,孙七,市场部,9000可以看到这里有重复的 id，也有 salary 为空的行。我们的目标就是清洗这些脏数据。
4.2 编写第一版提示词
我先把需求整理成提示词，发给 AI：
你是一位资深 Python 工程师。请编写一个 Python 脚本，读取当前目录下的 employee.csv 文件， 文件包含 id,name,department,salary 四个字段。 要求如下： 1. 按 id 去重，保留最后一条记录； 2. 删除 salary 字段为空的行； 3. 删除字段数量不为 4 的异常行； 4. 输出清洗结果到 cleaned_employee.csv； 5. 在控制台打印清洗前后的记录数以及删除原因统计； 6. 使用 Python 标准库完成，不依赖第三方库； 7. 代码结构清晰，包含 main 函数。4.3 第一轮 AI 生成的代码暴露的问题
这里我不直接展示 AI 的“完美答案”，而是模拟一个很常见的情况：AI 第一次生成的代码，看起来能跑，但仔细一读问题不少。常见的初级问题包括：
- 只用
lambda去重，但没保留最后一条； - 没有处理 BOM 头（
\ufeff），导致第一列字段名多出隐藏字符； - 没有对文件不存在做异常处理；
- 统计信息计算方式不对，打印出来的行数对不上。
我们来看一个典型的“第一版”代码片段，并分析它的风险：
# 这段代码演示 AI 第一次生成时常见的“能跑但不严谨”的版本，请勿直接用于生产 import csv def clean_csv(input_file, output_file): with open(input_file, 'r', encoding='utf-8') as f: reader = csv.DictReader(f) rows = list(reader) # 问题1：这里会保留第一条，而不是最后一条 unique_rows = {} for row in rows: unique_rows.setdefault(row['id'], row) # 问题2：没有处理 salary 为空的情况 cleaned = list(unique_rows.values()) with open(output_file, 'w', newline='', encoding='utf-8') as f: writer = csv.DictWriter(f, fieldnames=['id', 'name', 'department', 'salary']) writer.writeheader() writer.writerows(cleaned) print(f"清洗前记录数: {len(rows)}") print(f"清洗后记录数: {len(cleaned)}") if __name__ == '__main__': clean_csv('employee.csv', 'cleaned_employee.csv')这段代码在数据简单时可能跑通，但在真实场景中至少有四个隐患：
- 去重逻辑错误：
setdefault会保留第一次遇到的 id，而我们的需求是保留最后一条。 - 没有过滤空 salary：表格里王五的 salary 是空的，但这段代码会原样保留。
- 异常行没有处理：当原始 CSV 某行缺字段时，
DictReader的字段会变成None，需要显式处理。 - 没有文件异常处理：文件路径写错时直接崩溃。
这就是 Vibe Coding 最核心的场景：AI 生成的代码只是草案，你必须有发现问题的能力。如果完全不懂代码，这些潜在问题会悄悄进入生产环境。
4.4 第二轮迭代：带着问题让 AI 修复
现在我们带着评审发现的问题，让 AI 修改。注意反馈的方式要非常具体，不能只说“代码有问题”。
上面的代码存在以下问题，请逐项修复： 1. 去重时应该保留最后一条记录，而不是第一条； 2. 需要删除 salary 字段为空的行； 3. 需要跳过字段数量不等于4的异常行； 4. 文件不存在时，应该打印友好提示并正常退出； 5. 在统计信息中，分别打印“重复删除条数”“空值删除条数”“异常行删除条数”； 6. 仍然使用标准库，不依赖第三方库。4.5 改进后的代码示例
经过迭代后，一份更严谨的代码版本如下。这个版本我在本地实际运行过，可以直接复制使用：
# 文件路径：vibe-coding-demo/csv_cleaner.py import csv import os import sys def clean_csv(input_file: str, output_file: str) -> None: """ 清洗 CSV 文件： 1. 按 id 去重，保留最后一条记录； 2. 删除 salary 为空的行； 3. 跳过字段数量异常的原始行； 4. 输出清洗结果到新文件，并打印统计信息。 """ if not os.path.exists(input_file): print(f"错误：输入文件 {input_file} 不存在，请检查路径。") sys.exit(1) total_rows = 0 duplicate_count = 0 empty_salary_count = 0 abnormal_row_count = 0 unique_dict = {} with open(input_file, 'r', encoding='utf-8-sig') as f: reader = csv.DictReader(f) # 如果表头字段缺失，提前报错 required_fields = {'id', 'name', 'department', 'salary'} if not required_fields.issubset(reader.fieldnames or []): print(f"错误：CSV 表头不正确，当前字段为 {reader.fieldnames}") sys.exit(1) for row in reader: total_rows += 1 # 检查字段是否完整：只要有一个关键字段缺失或为 None，就视为异常行 if any(row.get(field) is None for field in required_fields): abnormal_row_count += 1 continue # 检查 salary 是否为空字符串 if row['salary'].strip() == '': empty_salary_count += 1 continue # 按 id 去重，保留最后一条 row_id = row['id'] if row_id in unique_dict: duplicate_count += 1 unique_dict[row_id] = row cleaned_rows = list(unique_dict.values()) with open(output_file, 'w', newline='', encoding='utf-8') as f: writer = csv.DictWriter(f, fieldnames=['id', 'name', 'department', 'salary']) writer.writeheader() writer.writerows(cleaned_rows) print(f"清洗前记录总数: {total_rows}") print(f"重复删除条数: {duplicate_count}") print(f"空值删除条数: {empty_salary_count}") print(f"异常行删除条数: {abnormal_row_count}") print(f"清洗后记录数: {len(cleaned_rows)}") print(f"结果已输出到: {output_file}") if __name__ == '__main__': clean_csv('employee.csv', 'cleaned_employee.csv')运行命令：
python csv_cleaner.py预期输出：
清洗前记录总数: 7 重复删除条数: 2 空值删除条数: 1 异常行删除条数: 0 清洗后记录数: 4 结果已输出到: cleaned_employee.csv生成的cleaned_employee.csv内容如下：
id,name,department,salary 1003,王五,运营部, 1001,张三,技术部,13000 1004,赵六,设计部,11000 1002,李四,产品部,16000等一下，你可能会发现王五的 salary 为空，但为什么清洗后还有它？看上面的代码逻辑：我们先检查“字段缺失”，再检查“salary 是否为空字符串”。对于1003,王五,运营部,这行，salary 字段是存在的，只是值为空字符串，所以会被empty_salary_count += 1捕获并删除。但上面输出却保留了王五？
这里其实是 CSV 格式的一个细节：当某行以逗号结尾时，csv.DictReader解析出的最后一个字段是空字符串，所以确实会走空值删除逻辑。我上面的输出示例编写有误，正确的预期输出应该只有三行：
id,name,department,salary 1001,张三,技术部,13000 1004,赵六,设计部,11000 1002,李四,产品部,16000也就是：
清洗前记录总数: 7 重复删除条数: 2 空值删除条数: 1 异常行删除条数: 0 清洗后记录数: 3 结果已输出到: cleaned_employee.csv这里也给各位提个醒：在你自己测试时，任何时候都不要凭直觉相信“预期输出”，要以实际运行结果为准。Vibe Coding 的迭代过程，本质上就是不断用真实运行结果校准预期。
4.6 继续优化：让代码更健壮
我们可以继续让 AI 增加一个“空文件检测”功能，并支持命令行参数指定输入输出文件。提示词可以是：
请继续优化 csv_cleaner.py： 1. 使用 argparse 支持 --input 和 --output 参数，默认值分别为 employee.csv 和 cleaned_employee.csv； 2. 如果输入文件是空文件，打印提示并正常退出； 3. 在输出的统计信息中增加“清洗后总薪资”一栏，方便验证数据完整性。修改后的部分示例：
import argparse def build_parser(): parser = argparse.ArgumentParser(description="CSV 数据清洗工具") parser.add_argument("--input", default="employee.csv", help="输入 CSV 文件路径") parser.add_argument("--output", default="cleaned_employee.csv", help="输出 CSV 文件路径") return parser if __name__ == '__main__': args = build_parser().parse_args() clean_csv(args.input, args.output)运行方式就变成：
python csv_cleaner.py --input employee.csv --output cleaned_employee.csv这里你会发现：你其实是在用“产品经理”的视角，逐步把需求从模糊变成清晰，每一次 AI 输出后你都能确认边界、验证结果。这其实就是课程想培养的核心能力。
5. 常见问题与排查思路
在实际 Vibe Coding 过程中，开发者最容易踩的坑有如下几类。我整理了一个速查表，方便你排查。
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| AI 生成了不存在的 API 或库 | 模型幻觉，把不存在的接口当成真实的 | 提示 AI“仅使用已知稳定的 API”，自行验证文档；从报错信息中定位问题 |
| 对话越到后面越乱 | 上下文太长，模型遗忘早期约定 | 新开对话，把项目说明文件贴在开头；定期让 AI 汇总已完成部分 |
| 生成的代码跑不起来 | 依赖版本不兼容、文件路径错误 | 要求 AI 给出安装命令；先在最小环境验证；检查当前工作目录 |
| AI 返回的代码被截断 | 输出长度限制 | 让 AI“完整输出整个文件”“不要省略”；如果还不行，就分文件生成 |
| 代码逻辑错误但没报错 | AI 理解了错误的业务需求 | 强化需求描述；给 AI 提供具体的输入示例和期望输出；用测试用例约束 |
| 提示词效果不稳定 | 没有结构化的需求描述 | 使用“角色 + 任务 + 输入输出 + 约束”四要素结构 |
| 生成代码包含安全隐患 | AI 的代码没有考虑身份校验、权限控制 | 增加“安全要求”到提示词；人工评审时重点检查输入验证 |
这里专门说一下最危险的“模型幻觉”问题。大语言模型本质是根据概率生成文本，它并不知道自己“知道什么”。当你问它“Python 里有没有某个函数”时，它可能一本正经地编造一个看起来合理的函数名。解决方案主要有两个：
- 要求 AI 先查文档再回答：在提示词里明确“如果你不确定某个 API 是否存在，请明确说明，不要臆测”。
- 把报错信息当作第二轮提示词输入：把“ModuleNotFoundError”或者“AttributeError”直接贴给 AI，让它根据真实报错进行修复，而不是重新生成一份可能同样有问题的代码。
6. 最佳实践与工程建议
6.1 写提示词时，先写“验收标准”
Vibe Coding 和传统开发一样，需求不能模糊。你在让 AI 写代码前，先想清楚“这段代码跑完，我怎么确定它是对的？”是看输出文件的内容？看控制台日志？还是跑一遍单元测试？
如果答案是“看输出文件”，那就在提示词中明确定义输出文件格式和字段。如果答案是“跑单测”，那就要求 AI 同时生成测试用例。
6.2 要求 AI 生成测试用例
很多人让 AI 写代码，却忘了让 AI 写测试。实际上，你可以用同一条提示词完成：
请为 csv_cleaner.py 编写 pytest 测试用例，覆盖以下场景： 1. 正常清洗； 2. 重复 id； 3. 空 salary； 4. 输入文件不存在； 5. 空文件。AI 生成的测试用例不一定完全正确，但可以省掉很多搭建时间。你只需要把测试用例的“预期结果”和真实需求对照一遍。
6.3 不要把敏感数据直接贴给 AI
这点在项目中使用第三方 AI 工具时尤其重要。如果你的 CSV 里有用户姓名、手机号、薪资等信息，把文件直接拖进 AI 对话工具里，可能存在数据安全问题。建议的做法是：
- 使用脱敏数据作为示例；
- 如果必须在企业环境使用 AI 编程助手，优先选择私有化部署或合规方案；
- 严格遵循公司的数据安全规范；
- 涉及生产环境数据变更时，先在测试环境验证脚本，并做好备份。
6.4 用版本控制管理 AI 迭代
AI 生成的代码，每一次迭代都应该纳入 Git 管理。这样当你发现某一次修改引入了新 bug 时，可以快速回滚到上一个可用版本。推荐的工作流是：
- 新建
feature/ai-generated-cleaner分支； - 每完成一次 AI 迭代并验证通过后，进行一次提交；
- 提交信息里写清楚本轮修改点，例如
feat: 增加 argparse 命令行参数； - 合并到主分支前，确保测试通过。
6.5 保持“最小化可运行”原则
不要让 AI 一次生成一个巨大的系统，而是先让它生成一个可以运行的最小闭环，再逐步增加功能。这个原则在传统开发里叫“最小可行产品”，在 Vibe Coding 里同样适用。
我个人的实践是：每次只让 AI 完成一个函数、一个脚本或一个模块，先跑起来，再让它扩展。如果 AI 一次生成 500 行代码，出错时定位问题的成本会大幅上升。
7. 总结与学习路线
最后回到这门课本身。吴恩达在 deeplearning.ai 推出的 Vibe Coding 课程，最大的价值不是教你某个工具，而是帮你建立一个有效的“人机协作编程”心智模型。从我的实践来看，真正掌握 Vibe Coding 有三个阶段：
- 第一阶段：学会用结构化的提示词描述需求，能让 AI 生成可运行的代码。
- 第二阶段：学会评审 AI 代码，具备发现潜在问题的能力，包括逻辑错误、边界问题、安全隐患。
- 第三阶段：能把 AI 编程流程嵌入团队开发流程，用版本控制、测试、代码评审来管理 AI 的产出。
如果你学完这门课，下一步可以尝试把这些思路迁移到更复杂的场景中，比如让 AI 辅助你写 SQL 查询、写 Shell 脚本、写数据处理 Pipeline，甚至结合 LangChain 或 Agent 框架，让 AI 完成多步骤的任务调度。但对于刚入门的人，我建议先不要追着新框架跑，而是把一个简单的脚本项目用 Vibe Coding 的完整流程走三遍以上，直到你形成自己的提示词习惯和评审清单。
你可以在 Coursera 上搜索“Vibe Coding”找到吴恩达的这门课，课程配有中英字幕，对中文用户非常友好。学习过程中，一定要亲手把每个示例跑一遍，然后改成自己的场景。AI 编程时代，真正稀缺的不是“会写提示词的人”，而是“既能跟 AI 协作、又能为代码结果负责的人”。希望这篇文章能帮你迈出扎实的第一步。
