“AI编程”这四个字这两年被人说得有点玄乎，一边是各种“零基础三天接单”的夸张宣传，一边是干了十年的老工程师抱怨AI写的代码根本没法用。我把这两年在实际项目里用AI写代码、带着身边朋友从零入门的过程整理了一遍，写成这份可以直接照着走的路线。这篇东西不讲玄学，只讲三件事：AI编程到底在编什么、用哪些工具、怎么在两周内跑出第一个真正能用的东西。适合三类人看——完全没写过代码但想动手的、会写点脚本但没形成工作流的、以及想搞清楚AI到底能替自己干多少活的从业者。下面出现的环境配置、代码片段、参数取值，我都在本机跑过，可以直接抄。
1. 先搞清楚AI编程到底在编什么
很多人一上来就问“学AI编程要多久”，这个问题本身就有问题。就像问“学开车要多久”一样，答案取决于你是想从小区开到超市，还是想跑长途。AI编程这个词现在被用得太宽，它至少包含了三层意思：用AI工具辅助写传统代码、调用AI模型能力做应用、以及训练和微调模型本身。前两层是绝大多数人真正需要的，第三层是另一条完全不同的路，没有相当的数学和工程基础碰不得。我见过太多人一入门就扎进第三层，买了几百G的课程，最后连一个能跑的东西都没做出来。
我建议所有新手先把目标收窄：用AI工具，把一个具体的、能看见结果的小需求做出来。这个目标足够低，两天就能摸到；也足够真，做完你就知道AI在哪些环节帮得上忙、哪些环节还得靠自己。下面几节我拆开讲，为什么这么定目标，以及这条路上最容易踩的坑在哪。
1.1 三种最常见的误解，以及它们对应的现实
第一个误解是“用了AI就不用学编程了”。持这个想法的人通常会在第三天卡住：AI给了一段代码，运行报错，他不知道错在哪，也不知道该改哪一行。AI确实能生成代码，但它生成的东西需要有人验收。验收的前提是你读得懂。我不要求你能手写，但至少要看得出“这行在打开文件”“这行在发网络请求”“这里少了一个括号”。读代码的能力是可以速成的，比写代码快得多，这也是新手最该优先补的一课。
第二个误解是“AI编程就是研究提示词”。提示词确实重要，但它只是整条链路里的一环。你还要会装环境、会管依赖、会看日志、会用版本控制。我见过提示词写得极其漂亮的人，卡在ModuleNotFoundError上两个小时，最后发现是虚拟环境没激活。这类问题跟AI一点关系都没有，纯粹是工程基本功。所以别把精力全押在“怎么问”上，工具链的熟练度同样决定你能不能走远。
第三个误解是“得先学完数据结构和算法才能动手”。这话放在十年前没毛病，现在顺序该倒过来。你先用项目跑出正反馈，遇到性能瓶颈、遇到需要选合适数据结构的时候，再回头补理论，吸收效率高得多。我自己学排序算法最认真的一次，是因为一个真实脚本处理十万条数据慢了四十秒，逼着我去查为什么。带着问题学，比空着脑子学强十倍。
1.2 AI的能力边界在哪里：一张能/不能清单
新手最容易犯的错是高估AI。它不是什么都能干，它的强项和弱项非常分明，分界线大致是：有没有大量公开范例、需求边界是否清晰、出错后能不能立刻验证。满足这三条，AI的表现通常超出预期；不满足，它就会一本正经地给你编。
| 任务类型 | AI表现 | 背后的原因 |
|---|---|---|
| 写模板化代码（文件读写、数据处理、接口请求） | 强 | 公开范例极多，模式高度重复 |
| 解释报错信息和堆栈 | 强 | 报错文本本身就是最好的上下文 |
| 写单元测试、补测试用例 | 较强 | 有明确输入输出，容易验证 |
| 格式转换、正则表达式编写 | 较强 | 规则明确，可即时验证 |
| 跨文件重构、大型项目改造 | 中等 | 需要全局上下文，容易被截断 |
| 性能调优 | 中等 | 需要真实 profiling 数据，AI只能猜 |
| 从零设计系统架构 | 弱 | 缺少你的业务约束和团队现状 |
| 涉及私有业务规则的逻辑 | 弱 | 训练数据里没有你的业务 |
| 安全审计、合规判断 | 弱 | 责任无法转移，必须人工兜底 |
这张表我建议你打印出来贴显示器边上。每次想偷懒把整块任务丢给AI之前，先对一下它在哪一栏。落在“弱”那一栏的事情，不是不能问，而是问完之后你必须逐行核对，别指望它替你做决定。
还有一点要说清楚：AI生成的代码“能跑”和“能用”是两回事。能跑是指不报错、输出看着对；能用是指异常情况处理了、边界条件覆盖了、日志打了、别人接手能看懂。新手阶段先追求能跑，但心里要有这根弦，别把第一版当成最终版。
1.3 为什么我建议“先项目后语法”
传统编程教学是语法先行：变量、循环、函数、类，一章一章过。这套方法在课堂里成立，自学场景下失败率极高，因为反馈周期太长，学两周还做不出任何东西，热情就耗没了。AI编程把反馈周期压缩到了极限，你应该利用这个优势。
我的做法是倒着来：先定一个两小时能看见结果的小项目，比如“把一堆杂乱的文本文件按关键词分类”“把表格里某一列批量翻译成中文”“把日志里所有报错行提取出来”。然后一边做一边学需要的语法，用到什么学什么。这样做的好处是每个知识点都有落点，你学for循环是因为要遍历文件，不是为了考试。
这里有个关键概念叫最小闭环：输入→处理→输出，三段都跑通，你就算完成一次循环。第一个闭环越短越好，哪怕它只是“读一个txt文件，统计有多少字，打印出来”。闭环跑通之后，你再加功能、加异常处理、加界面，每一步都是在已有基础上叠加，心理压力小得多。
我得提醒一句，先项目后语法有个副作用：知识是碎片化的，容易留下盲区。对策是每做完一个项目，花半小时复盘——这次用到了哪些新东西、哪些地方是靠AI糊过去的、哪些概念还是一知半解。把后两类记下来，专门补。这个复盘习惯坚持三个月，你的知识结构会比按部就班学的人更结实，因为它是有骨架的。
2. 工具选型：别在安装配置上耗掉热情
新手放弃的高发区不是写代码，是装环境。我统计过身边十几个半途而废的案例，超过一半卡在第一步：装Python、配路径、装依赖，折腾一晚上没跑起来，第二天就不想碰了。所以这一章我把工具选型的逻辑讲透，原则只有一条——能用现成的就别自己攒，能少装一个就少装一个。
工具不是越多越好。很多人一入门就装了七八个编辑器、五六个插件、三套环境管理工具，结果互相打架。我建议的配置是极简四件套：一个编辑器、一个AI助手、一个终端、一个版本控制。四件之外的东西，等你明确知道缺什么了再加。
2.1 编辑器、AI助手、终端：三层结构
先理清这三层各自负责什么，很多人把它们混在一起。编辑器是你写代码的地方，负责语法高亮、文件管理、代码跳转；AI助手是挂在编辑器里或者独立运行的一层，负责补全、对话、改写；终端是你敲命令的地方，负责装依赖、跑脚本、看输出。三者分工明确，别指望一个工具全包。
编辑器选型上，现在市面上的主流产品分两类。一类是传统编辑器加AI插件，好处是你原来的使用习惯不用改，插件可以随时换；另一类是原生集成AI的编辑器，好处是AI能读到整个项目的上下文，补全和改写更连贯，坏处是迁移成本和学习曲线。我的建议是：如果你已经有顺手的编辑器，先加插件，别急着换；如果你是全新开始，两类都可以，挑一个界面看着顺眼的就行，别在选型上纠结超过半天。
AI助手也要分层看。行内补全型（你打字它接后半句）适合写重复度高的代码，速度快、不打断思路；对话型适合讨论方案、解释报错，但需要你主动切过去；还有一类能直接在终端里读文件、跑命令、改代码，适合处理“把这个目录下所有脚本的日志格式统一一下”这种批量任务。这三类不是替代关系，我日常是三个一起用：补全负责敲，对话负责想，终端型负责批量改。
还有一层容易被忽略：版本控制。新手会觉得“我一个人写代码要什么版本控制”，直到某次AI帮你改代码，改完之后整个文件面目全非，你想回到十分钟前都回不去。Git的第一课不是分支不是合并，是git init、git add .、git commit -m "说明"这三条，学会就能救命。后面第4章我会给具体操作。
2.2 模型怎么选：一份务实的对比
模型这块更新太快，具体型号半年就换一轮，所以我讲选型的维度，不讲具体产品。你需要关注四个指标：上下文长度、代码能力、响应速度、单位成本。这四个通常互相牵制，不可能全占。
| 类型 | 典型特征 | 适合干什么 | 不适合干什么 |
|---|---|---|---|
| 通用大模型（对话式） | 上下文长，理解力强，速度中等 | 讨论架构、读长文档、解释复杂报错 | 高频行内补全，成本扛不住 |
| 代码专用补全模型 | 延迟极低，专注代码片段 | 一边敲一边补，写模板代码 | 长篇讨论、跨文件推理 |
| 本地部署的小模型 | 数据不出本机，能力受限 | 处理敏感数据、离线学习 | 复杂逻辑、长上下文任务 |
| 支持工具调用的模型 | 能读文件、跑命令、多轮迭代 | 批量改造、自动化任务 | 对准确性要求极高的场景 |
选择逻辑其实很简单：日常敲代码用补全型，遇到想不明白的用对话型，处理敏感数据用本地型，批量改造用带工具调用的。别指望一个模型包打天下，也别迷信“最强模型”，很多时候快而准的小模型比慢而全的大模型体验好。
还有一个实用技巧：同一个问题，如果第一次回答明显不对，别在同一个会话里反复追问。开一个新会话，把问题重新组织一遍，往往一次就对了。原因我在3.3节细讲。
2.3 最小环境配置：Python + 虚拟环境 + Git
下面这套配置我反复在干净机器上装过，全程十五分钟左右。选Python是因为它对新手最友好，库多、报错信息清楚、AI训练语料也最多。
第一步，装Python。去官网下3.11或更新的稳定版，安装时勾选“添加到系统路径”那个选项，这一步漏了后面全是坑。装完打开终端敲python --version，能打印出版本号就成。Windows上如果提示找不到命令，试试py --version。
第二步，建虚拟环境。这一步很多人跳过，然后被“装了一个库把另一个项目搞崩了”折磨。虚拟环境就是给每个项目单独划一块地，互不干扰：
# 在项目目录下执行 python -m venv .venv # 激活（macOS / Linux） source .venv/bin/activate # 激活（Windows PowerShell） .venv\Scripts\Activate.ps1激活成功的标志是命令行提示符前面多了(.venv)。看不到这个前缀，说明没激活，后面装的包全会跑到系统环境里去。
第三步，装依赖。项目里所有依赖写进requirements.txt，方便换机器时一键还原：
pip install requests python-dotenv pip freeze > requirements.txt国内网络下装包慢的话，可以给pip配一个镜像源，具体地址搜一下就有，配置一次长期生效。
第四步，初始化版本控制：
git init echo ".venv/" > .gitignore echo ".env" >> .gitignore git add . git commit -m "初始化项目骨架".gitignore这两行非常关键，.venv目录动辄几百兆，.env里放的是密钥，都不该进仓库。这一点我在5.4节还会展开。
注意：不要在系统Python里直接
pip install任何东西。装坏了修复起来比重装系统还麻烦，而虚拟环境删掉重建只需要十秒。
3. 提示词不是玄学：和AI协作的工程化方法
聊提示词的文章很多，大部分在教“咒语”，什么“你是一位资深工程师”“请一步一步思考”。这些话有用，但作用被夸大了。真正决定输出质量的，是你给了多少有效上下文和你把任务拆得多细。一个模糊的大任务配一句神奇咒语，效果远不如一个清晰的小任务配一句大白话。
我把和AI协作的过程类比成带一个很聪明但没有背景信息的新人。你不能说“帮我把这个项目弄好”，你得说“这个文件负责读取配置，现在它读到空值会崩，你帮我加个默认值，默认值取环境变量里的TIMEOUT，没有就用30”。信息给到位，它一次就能做对。
3.1 结构化提示词的五个组成部分
我总结的模板包含五块，缺一块输出质量就往下掉一档。
角色：告诉它站在什么位置回答。写代码就说“你是一个注重可读性和异常处理的Python工程师”，别写“你是一个天才”。角色越具体，输出越收敛。
任务：一句话说清要做什么，动词开头。“写一个函数，把传入的字符串里所有URL替换成[链接]”。
约束：这是最容易被忽略也最关键的一块。约束包括：用什么语言和版本、能不能引入第三方库、时间复杂度要求、输出必须是完整可运行的文件还是片段、命名风格、中文注释还是英文注释。约束写得越细，返工越少。
输出格式：明确要代码块、要表格、要分点、要 JSON。不指定的话它会自由发挥，你还得自己整理。
示例：给一组输入输出样例。这是提升准确率最有效的手段，尤其是格式转换类任务。给两个例子，比写两百字描述管用。
组合起来大概长这样：
角色：你是一个注重异常处理和日志输出的Python工程师。 任务：写一个函数 extract_errors(log_text)，从日志文本中提取所有包含 ERROR 级别的行。 约束： - Python 3.11，只用标准库 - 输入可能是几十MB的字符串，不要用 O(n^2) 的写法 - 遇到空输入返回空列表，不要抛异常 - 每行保留原始时间戳 输出格式：完整函数代码 + 三行调用示例 示例： 输入 "2026-01-01 10:00:00 ERROR 连接失败" 输出 ["2026-01-01 10:00:00 ERROR 连接失败"]这个模板我用了两年，返工率比随口问低了一大截。你可以把它存成文本片段，每次改改就用。
3.2 三个可以直接套用的场景模板
第一个是解释代码。你从别人那里拿到一段看不懂的代码，或者AI给你的代码你不确定在干什么：
逐行解释下面这段代码做了什么，重点说明： 1. 每一行的作用（用一句话） 2. 有没有潜在的异常风险（空值、越界、编码问题） 3. 如果输入是空字符串会发生什么 代码： [粘贴代码]第二个是生成函数。适合需求明确的小功能：
用 Python 写一个函数，实现 [功能描述]。 输入：[类型和取值范围] 输出：[类型和边界情况] 要求：不引入第三方库，函数内部捕获异常并记录到 logging，附三个边界测试用例。第三个是定位bug。这里的关键是给足信息，光贴一行报错没用：
运行环境：Python 3.11，macOS 执行的命令：[命令] 完整报错：[粘贴完整堆栈，不要截断] 相关代码：[粘贴出错文件的相关函数] 我已经试过：[列出你排查过的方向] 请判断最可能的原因，按可能性从高到低排序，每条给出验证方法。最后那句“按可能性排序，每条给出验证方法”很关键。它逼着AI给出可执行的下一步，而不是一句“可能是环境问题”就完事。
3.3 上下文管理：为什么聊得越久它越笨
这是新手最困惑的现象：刚开始聊得好好的，聊到第二十轮，它开始答非所问、忘记前面说过的约束、甚至把已经否定的方案又提一遍。这不是模型坏了，是上下文管理出了问题。
原因有三个。一是上下文有长度上限，超出之后最早的内容会被丢弃，你最开始定的约束就消失了。二是信息污染，中途你贴过一段错误的代码、一次失败的尝试，这些内容会一直留在上下文里干扰判断。三是注意力稀释，对话越长，关键信息被淹没的概率越高。
对策我总结了四条，实测有效：
- 一个任务一个会话。做完一件事就开新会话，别在一个窗口里从装环境聊到部署上线。
- 定期让AI总结。聊到十轮左右，让它“用五句话总结目前的结论和待办”，然后把总结复制到新会话里继续。这相当于手动做了一次上下文压缩。
- 贴路径而不是贴全文。如果你的AI助手能读项目文件，告诉它“看
src/parser.py第 40 到 80 行”，比把整段代码粘进去更省上下文，也更准。 - 否定过的方案要明确说。“不要用正则，性能不够”这种话要说出来，否则它可能绕一圈又回来。
还有个小习惯：每次让AI改代码之前，先git commit一次。改坏了直接git checkout .回滚，比让AI“改回去”靠谱得多。AI改回去经常改出新问题。
4. 第一个能跑的项目：从脚本到工具
理论和工具讲完了，这一章直接上手。我选的项目是日志/文档批量处理小工具，理由有三个：输入输出明确、结果可以肉眼验证、不需要前端界面。新手做带界面的项目，八成时间会耗在调样式上，学不到核心东西。
项目需求定成这样：扫描指定目录下所有.log文件，提取包含ERROR的行，按文件分组输出到一个汇总文件里，同时打印统计信息（处理了几个文件、提取了多少行、耗时多少）。别看简单，它覆盖了文件遍历、字符串处理、异常捕获、命令行参数、日志输出这几个核心技能，做完你对“一个程序是怎么跑起来的”会有实感。
4.1 选题逻辑：为什么是这类任务
我见过太多新手第一项目选“做个网站”“做个聊天机器人”。这两个方向不是不行，而是它们的失败面太宽：网站要处理路由、模板、静态资源、跨域；聊天机器人要处理流式输出、上下文存储、界面交互。任何一个环节出问题，你都分不清是核心逻辑错了还是外围配置错了。
批处理类任务的好处是错误可定位。程序跑完，输出文件里少了几行，你很容易反推是哪一步出的问题。而且这类任务天然适合增量开发：第一版只处理一个文件，第二版遍历目录，第三版加异常处理，第四版加命令行参数，第五版加并发。每加一层都是一个完整的小胜利。
选完题之后，先别急着写代码。拿一张纸，把输入、处理、输出三段写清楚，再列出三个“可能出错的地方”。这一步花十分钟，能省你两小时调试。我当年的清单是：文件编码可能不是UTF-8、目录里可能有子目录、某个文件可能没有读权限。后来这三个坑一个不落全踩了，但因为提前想到，排查速度快了很多。
4.2 核心代码：带超时和重试的调用封装
如果你的工具需要调用AI模型接口，一定要做封装。直接把请求写在业务逻辑里，后面加超时、加重试、加日志的时候你会想砸键盘。下面这个封装我用了很久，直接改改就能用：
import os import time import logging import requests from dotenv import load_dotenv load_dotenv() API_KEY = os.environ.get("MODEL_API_KEY") ENDPOINT = os.environ.get("MODEL_ENDPOINT") MODEL_NAME = os.environ.get("MODEL_NAME", "default-model") logging.basicConfig( level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s" ) def call_model(prompt: str, system: str = "你是一个严谨的文本处理助手。", temperature: float = 0.2, max_retries: int = 3, timeout: int = 30) -> str: """调用模型接口，带指数退避重试。""" if not API_KEY or not ENDPOINT: raise RuntimeError("缺少 API_KEY 或 ENDPOINT，请检查 .env 文件") payload = { "model": MODEL_NAME, "messages": [ {"role": "system", "content": system}, {"role": "user", "content": prompt}, ], "temperature": temperature, } headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", } for attempt in range(1, max_retries + 1): try: resp = requests.post(ENDPOINT, json=payload, headers=headers, timeout=timeout) if resp.status_code == 429: wait = 2 ** attempt logging.warning("触发限流，%s 秒后重试", wait) time.sleep(wait) continue resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"] except requests.exceptions.Timeout: logging.warning("第 %s 次请求超时", attempt) if attempt == max_retries: raise time.sleep(2 ** attempt) except requests.exceptions.RequestException as e: logging.error("请求失败：%s", e) if attempt == max_retries: raise time.sleep(2 ** attempt)几个参数的选择理由说清楚。temperature取0.2，是因为文本处理类任务需要稳定输出，取值太高每次结果都不一样，没法做回归测试；如果做创意类任务可以调到0.8以上。timeout给30秒，是考虑到长文本处理可能慢，但也不能无限等，卡住的话整个流程就废了。重试次数给3次，配合指数退避（等2秒、4秒、8秒），足以扛过大部分网络抖动和临时限流，再多就说明是配置问题，重试也没用。
raise_for_status()这行别省。很多人只判断状态码是不是200，结果4xx、5xx全被当成成功处理，拿到一堆空数据还不知道为什么。异常往上抛而不是吞掉，也是为了让你在调用层能看到真实原因。
4.3 加一层命令行外壳
脚本能跑了，但每次改路径都要打开编辑器，很烦。加个命令行参数，它就从一个脚本变成一个工具：
import argparse import sys import logging from pathlib import Path def build_parser(): p = argparse.ArgumentParser(description="批量提取日志中的错误行") p.add_argument("src", type=Path, help="源目录") p.add_argument("-o", "--output", type=Path, default=Path("errors.txt"), help="输出文件") p.add_argument("-p", "--pattern", default="ERROR", help="匹配关键字，默认 ERROR") p.add_argument("-v", "--verbose", action="store_true", help="输出详细日志") return p def main(): args = build_parser().parse_args() if args.verbose: logging.getLogger().setLevel(logging.DEBUG) if not args.src.is_dir(): logging.error("源目录不存在：%s", args.src) sys.exit(1) files = list(args.src.rglob("*.log")) logging.info("找到 %s 个日志文件", len(files)) total = 0 with args.output.open("w", encoding="utf-8") as out: for f in files: try: text = f.read_text(encoding="utf-8", errors="ignore") except OSError as e: logging.warning("跳过 %s：%s", f, e) continue hits = [line for line in text.splitlines() if args.pattern in line] if hits: out.write(f"=== {f.name} ===\n") out.write("\n".join(hits) + "\n") total += len(hits) logging.info("共提取 %s 行，输出到 %s", total, args.output) if __name__ == "__main__": main()这段代码里有三个细节值得说。rglob而不是glob，是为了递归子目录，我第一版用的glob，结果漏了所有二级目录下的日志，排查了半天。errors="ignore"是防编码炸弹，日志文件里经常混着各种编码，遇到解不开的字符直接跳过比整个文件崩掉强。try/except OSError是防权限问题，某个文件读不了不应该让整个任务中断。
跑起来是这样：
python extract.py ./logs -o ./out/errors.txt -p "ERROR" -v4.4 用Git把每次“改坏了”变成可回退
这一步很多人跳过，然后被AI坑得很惨。AI改代码有个特点：它经常在你没要求的地方顺手“优化”一下，改完之后原来能跑的功能不能跑了。这时候如果你没有版本控制，只能凭记忆一行行改回去，非常痛苦。
最小工作流就三条命令，养成习惯：
# 每次让AI动手之前 git add -A && git commit -m "改之前的存档" # 让AI改 # 跑测试 # 发现不对，回滚 git checkout -- .我给自己定的规矩是：每次让AI改动超过二十行，先提交一次。提交信息不用讲究，写“存档”都行，关键是能回去。这条习惯帮我省下的时间，比我学过的任何一个技巧都多。
等你熟练了，再学git diff看AI到底改了什么，学git stash临时存一下。这些进阶命令不急，先把“提交-回滚”这个循环跑顺。
5. 高频踩坑与排查实录
这一章是我踩过的坑的汇总，按出现频率排序。新手遇到问题容易慌，其实八九成的问题都在这张表里。
5.1 环境与依赖问题速查表
| 现象 | 最可能的原因 | 处理办法 |
|---|---|---|
command not found: python | 没加系统路径，或系统里只有python3 | 试python3 --version，或重装时勾选添加路径 |
ModuleNotFoundError | 依赖没装，或装到了别的环境 | 确认提示符有(.venv)，再pip install |
| 装了包但代码里导入失败 | 编辑器选错了解释器 | 在编辑器里手动指定.venv下的解释器 |
pip install卡住不动 | 网络问题 | 换国内镜像源，或加超时参数重试 |
| SSL证书错误 | 系统证书过期或代理干扰 | 升级证书库，检查系统时间是否正确 |
| 中文输出乱码 | 文件读写没指定编码 | 所有open()加encoding="utf-8" |
| 路径里有空格导致失败 | 命令参数没加引号 | 路径整体用双引号包起来 |
| 脚本在编辑器里能跑，终端里不行 | 工作目录不同 | 用绝对路径，或在脚本里打印os.getcwd()确认 |
这张表覆盖了我遇到的八成环境问题。剩下一成里，有一半是权限问题，另一半是杀毒软件拦截，删掉重装基本能解决。
有个排查方法值得单独说：二分法定位。程序出问题，先把后半段代码注释掉，看前半段能不能跑；能跑说明问题在后半段，再对半切。这样五六轮就能定位到具体行，比从头读一遍快得多。AI也能帮你做这件事，把代码贴给它说“用二分法帮我定位哪一行导致崩溃”，它给出的思路通常可用。
5.2 AI代码“看着对、跑不通”的五种典型
第一种是幻觉接口。AI会编出一个不存在的函数名或者参数，语法上完全合法，运行就报AttributeError或者TypeError。对策是：凡是你不认识的函数，先查官方文档确认存在，再确认参数签名。
第二种是版本过时。AI训练数据有时间截止点，它给的写法可能是三个版本前的。表现是弃用警告，或者某些参数突然不认了。对策是看依赖库的当前版本号，遇到不认识的参数先查变更日志。
第三种是依赖不存在。它引用了某个包，你pip install发现根本没这个包，或者包名拼错了。对策很简单，报错之后回去问它“这个包的确切名称是什么，有没有标准库替代方案”。
第四种是边界条件缺失。代码对正常输入没问题，遇到空列表、空字符串、None就崩。这是最常见也最隐蔽的，因为你不测边界就发现不了。对策是每段AI生成的函数，都让它补三个边界测试用例，然后自己跑一遍。
第五种是静默失败。代码不报错，但结果不对。典型场景是异常被except: pass吞掉了，或者返回值被忽略。这种最难查，对策是加日志，在每个关键节点打印中间结果，跑一遍看数据在哪一步偏离预期。
心得：AI给的代码，我会先做一次“三问检查”——这个函数在我用的版本里存在吗？边界输入会怎样？出错的时候我能看到原因吗？三问过完再合入，能挡掉大部分问题。
5.3 成本、速率与超时的控制
调用模型接口是要花钱的，新手容易在这一点上翻车。我见过一个朋友写了个循环，把一千条数据逐条发给模型，跑了一晚上，第二天看到账单差点晕过去。
控制成本的核心是批处理 + 缓存 + 限额。批处理是指把多条小请求合并成一个请求，比如一次发二十条让模型批量处理，比发二十次便宜得多，也快得多。缓存是指相同输入直接读本地结果，别重复请求，用文件哈希做键就行。限额是指给每次调用设max_tokens上限，防止模型话痨输出一大段。
token这个概念要理解清楚：它是计费单位，中文大概一个字对应一到两个token，英文大概四个字符一个token。一个上下文长度为八千token的模型，意味着你输入加输出总共不能超过这个数，超了就会被截断。所以长文档处理要分块，别一股脑塞进去。
超时和重试的策略我在4.2节给过代码了，这里补一句原则：超时时间要大于正常耗时的两倍，重试次数不要超过三次。超时设太短会误杀正常请求，设太长会让整个流程卡死；重试太多次在真出故障的时候只会雪上加霜。
5.4 数据和密钥的安全底线
这条没有商量余地。密钥写死在代码里，一旦代码分享出去就等于泄露。正确做法是放在.env文件里，代码通过环境变量读取，.env写进.gitignore。
# .env 文件内容示例（不要提交到仓库） MODEL_API_KEY=your_key_here MODEL_ENDPOINT=https://your-endpoint-here MODEL_NAME=your-model-name还有几条底线：日志里不要打印完整密钥，需要打印就打前四位加星号；处理用户数据时，别把真实数据直接贴给外部接口做调试，先用脱敏样本；模型返回的内容不要直接eval执行，也不要直接拼进SQL，这是两个经典的安全漏洞。
最后一条容易被忽略：AI生成的代码也要做安全审查。它可能会给你一段“读取用户输入并执行”的示例代码，看着方便，实际上是个大洞。凡是涉及文件系统、网络请求、命令执行的部分，都要人工过一遍。
6. 90天学习路线：把热情变成习惯
最后说说节奏。新手最常见的问题不是学不会，是节奏乱——头三天热情高涨，学到凌晨两点，第四天开始疲惫，第七天彻底放弃。我给身边朋友排的路线是九十天，分三段，每段有明确的验收标准。
6.1 三个阶段的目标与验收
| 阶段 | 时间 | 目标 | 验收标准 |
|---|---|---|---|
| 打基础 | 第1-2周 | 跑通环境和第一个闭环 | 能独立装好环境，写出读文件、处理、写文件的完整脚本 |
| 做工具 | 第3-6周 | 完成一个带命令行参数的实用工具 | 能处理真实数据，有异常处理和日志，代码提交到本地仓库 |
| 接AI | 第7-12周 | 把模型能力接进自己的工具 | 能封装接口调用，处理超时重试，控制成本，有缓存 |
第一阶段的关键词是跑通，不求优雅，只求能跑。第二阶段的关键词是健壮，重点补异常处理和边界条件。第三阶段的关键词是可控，重点是成本、延迟、失败处理。三个阶段层层递进，每个阶段的产出都是下一个阶段的基础。
我特别想强调第一阶段的验收标准：能独立装好环境。这个能力看着基础，实际上它决定了你遇到问题时是能自己解决还是只能等人救。判断方法很简单，把电脑上的环境全删了，从零装一遍，全程不看教程。装得下来，这一关就过了。
6.2 每天的时间怎么分配
我给的建议是每天两小时，其中半小时读、一个半小时写。读的部分包括看文档、看别人的代码、看AI的解释；写的部分必须是真敲键盘，不能只看不练。
两小时里我会切三段：前二十分钟回顾昨天写的代码，看看有没有能改进的地方；中间一小时推进当前任务，遇到卡点先自己查十五分钟，查不出来再问AI；最后十分钟做记录，把今天学到的新东西和没搞懂的问题各写三条。这个记录习惯坚持三个月，你会有一份完全属于自己的知识清单，比任何教程都贴合你的实际水平。
周末可以放宽一点，做一次复盘，把这一周卡住的问题集中解决。别小看复盘，很多人学了很久没进步，就是因为一直在重复同样的错误，从来没停下来看过。
6.3 判断自己“入门了”的几个信号
入门不是一个证书，是一种状态。我观察下来，真正入门的人通常有这几个表现：
- 看到报错不再慌，能读懂堆栈的前三行，知道去哪个文件哪一行找问题
- 能判断AI给的答案对不对，至少能判断出“这段代码在干什么”
- 遇到没见过的库，知道去哪里查文档，知道怎么找到最小可用示例
- 写代码之前会先想清楚输入输出，而不是上来就敲
- 知道什么时候该问AI，什么时候该自己查，什么时候该放弃当前方案换一条路
这几条里，我认为最重要的是第二条。能判断AI答案的对错，意味着你有了独立的判断力，不再是被工具牵着走。这条过了，剩下的都是时间问题。
7. 一些不太好归类但很重要的体会
写到这里，该讲的流程都讲完了，剩下几条零碎的经验，塞不进上面的框架，但我觉得比很多正式内容更值钱。
第一条是关于心态的。AI编程最大的陷阱不是技术，是“看起来学会了”的错觉。你看AI写了一段代码，觉得逻辑很清晰，自己懂了；关掉窗口自己写，一个字都敲不出来。这不是你笨，是看懂和写出之间隔着一条鸿沟。跨过这条鸿沟的唯一办法是关掉AI，自己从头写一遍，写完再对比。这个过程很痛苦，但它是唯一有效的。
第二条是关于提问的时机。我给自己定的规矩是：卡住十五分钟再问AI。十五分钟之内自己查文档、自己试、自己打印变量，这段时间的训练价值最高。一卡住就问，你会逐渐丧失独立排查的能力，最后变成离开AI什么都干不了。当然，十五分钟也不是死规矩，如果是环境配置这类纯粹的记忆性问题，直接问就行，没必要浪费时间。
第三条是关于代码的可读性。AI生成的代码经常变量名是data、result、temp，功能没错但过两周你自己都看不懂。我的习惯是AI给完代码，让它再做一遍“重命名变量并加中文注释”，多花十秒钟，省下未来半小时。
第四条是关于不要追新。AI领域三天一个小模型，五天一个新框架，追是追不完的。我建议每年只深入学一两个真正用得上的东西，其余的了解个概念就行。判断标准很简单：这个东西能不能解决你手上的具体问题。能，就学；不能，先记下来。
最后一条，也是我这两年体会最深的：AI改变的是写代码的速度，不是解决问题的能力。问题定义、任务拆解、方案取舍、结果验收，这四件事AI替不了你，而且随着生成代码的成本降到接近零，这四件事反而变得更值钱。所以别把时间全花在“怎么让AI写出更多代码”上，多花点在自己“怎么想清楚要做什么”上，这个投入的回报周期更长，也更稳。
我自己的做法是每做完一个项目，花二十分钟写一份复盘，记录三件事：这次哪里卡最久、下次怎么避免、有没有可以沉淀成模板的东西。这份复盘攒到现在有几十份，比任何教程都贴合我自己的短板。你也可以试试，从今天这个项目开始。
