“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.11macOS 执行的命令[命令] 完整报错[粘贴完整堆栈不要截断] 相关代码[粘贴出错文件的相关函数] 我已经试过[列出你排查过的方向] 请判断最可能的原因按可能性从高到低排序每条给出验证方法。最后那句“按可能性排序每条给出验证方法”很关键。它逼着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( levellogging.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: fBearer {API_KEY}, Content-Type: application/json, } for attempt in range(1, max_retries 1): try: resp requests.post(ENDPOINT, jsonpayload, headersheaders, timeouttimeout) 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, typePath, help源目录) p.add_argument(-o, --output, typePath, defaultPath(errors.txt), help输出文件) p.add_argument(-p, --pattern, defaultERROR, help匹配关键字默认 ERROR) p.add_argument(-v, --verbose, actionstore_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, encodingutf-8) as out: for f in files: try: text f.read_text(encodingutf-8, errorsignore) 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结果漏了所有二级目录下的日志排查了半天。errorsignore是防编码炸弹日志文件里经常混着各种编码遇到解不开的字符直接跳过比整个文件崩掉强。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()加encodingutf-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_KEYyour_key_here MODEL_ENDPOINThttps://your-endpoint-here MODEL_NAMEyour-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写出更多代码”上多花点在自己“怎么想清楚要做什么”上这个投入的回报周期更长也更稳。我自己的做法是每做完一个项目花二十分钟写一份复盘记录三件事这次哪里卡最久、下次怎么避免、有没有可以沉淀成模板的东西。这份复盘攒到现在有几十份比任何教程都贴合我自己的短板。你也可以试试从今天这个项目开始。