我从2023年初开始把AI编程工具当“试验品”玩到2024年下半年它已经成了我每天写代码离不开的伙伴。这两年最大的体会不是“AI又进化了”这种热闹话而是发现一个很分裂的现象同样一套工具有人用它把三天工作量压缩到半天有人却整天跟在AI后面改bug、清垃圾代码。差距基本不在工具本身而在一些使用技巧上——怎么选型、怎么写提示词、怎么管理上下文、怎么防止它帮倒忙。这篇文章就是我这两年实际攒下来的AI编程工具使用经验覆盖Cursor、Codex、Claude Code、本地部署大模型这几条主流路线也把踩过的坑一并交代清楚。不管你是刚入门的新手还是已经用了几个月想提效的老手应该都能在里面找到点可复用的东西。1. 先用工作流选型别被工具热度带着跑每次打开技术社区都能看到“XX工具杀疯了”“XX来了补全神器”这类的标题。我认识的不少朋友因此患上了工具焦虑今天换Cursor明天切Copilot后天又去折腾Codex结果一个月下来工具换了好几轮手里的项目进度却基本没动。工具本身没错但大概率是没想清楚一个问题自己的开发工作流到底缺什么。1.1 先问自己三个问题再考虑用什么我自己的选型逻辑很简单先盘清楚日常写代码的画像。第一个问题你主要是写新项目还是在存量代码库里修修改改如果是以新建模块、写功能为主IDE集成式的AI助手Cursor、Copilot这类最合适因为它能通过索引把当前文件和项目结构投喂给模型补全和生成都很顺手。如果是盯着一套几万行的老系统做维护那命令行Agent类工具Codex CLI、Claude Code往往更好用它们能自己遍历仓库而不是依赖你在IDE里打开哪个文件。第二个问题代码有没有保密要求如果你公司在做未公开项目或者你个人很在意代码不能出内网那本地部署是走得通的路线代价是要有个像样的硬件。第三个问题更现实——预算。别小看订阅费这回事Cursor Pro、Copilot、Claude订阅加起来一个月轻松上百了。像我这种偶尔用的个人开发者更合理的方案是先免费额度顶住再按需买一个主力订阅。1.2 主流AI编程工具的能力边界对比我把自己实际用过的几类工具整理成一张对比表方便你按场景对号入座。工具/类别形态最适合的场景需要留意的点Cursor基于VSCode的AI IDE新功能开发、日常补全、多文件Agent改造订阅制索引大仓库时占资源GitHub CopilotIDE插件补全稳定、团队场景成熟代码补全强但大任务需要配chatCodex CLI终端命令行Agent存量仓库的定向修改、跑测试有权限执行命令风险与效率并存Claude Code终端命令行Agent老代码梳理、重构方案、多文件改写长任务耗token成本要高一些Continue开源IDE插件接本地模型或任意API自由度高需要自己配置模型门槛略高Trae / QoderAI IDE中文界面国内网络友好生态还在长插件兼容性需实测通义灵码IDE插件国内团队协作已有合规诉求模型能力中等适合企业统一管控1.3 不建议“全家桶”堆满有些人喜欢把几个AI插件同时开着补全用这个对话用那个Agent再用另一个。我自己试过一段结论是得不偿失。AI工具起作用的前提是它能理解你的项目上下文而每次你切到另一个工具它都等于一个刚进组的新人啥也不懂你得重新把项目背景讲一遍。这还没算快捷键冲突和几个插件同时吃内存的损耗。所以我现在的做法是一个主力工具负责日常补全和对话一个命令行Agent负责大任务本地模型只在离线或隐私场景下兜底。三个以内主线清晰。2. 提示词才是真正的“编程语言”很多人觉得AI编程就是“把需求扔进去把代码复制出来”但实际用了之后会发现同样的需求有人让AI三分钟出活有人跟AI拉扯一小时还出不来能跑的代码。区别就在提示词。我甚至觉得在AI编程这件事上写提示词的能力已经比手写代码的速度更影响产出。2.1 把AI当成一个“很聪明但没经验”的实习生一个很管用的心理模型是AI不是你肚子里的蛔虫而是一个刚从名校毕业、代码能力很强但完全不熟悉你这摊业务的实习生。你让它“改一下登录逻辑”它可能真就只改登录逻辑完全不顾你项目里已经有了一套现成的用户状态管理方案。你不是在“命令工具”而是在“给实习生交代任务”——要把背景、边界、验收标准全说清楚。2.2 编程提示词的三层结构我写编程提示词基本固定用三层结构无论给Cursor还是给Codex都用这个套路。第一层是背景与角色。告诉它“你是这个项目的后端工程师项目使用Python 3.11、FastAPI、PostgreSQL代码采用仓库分层结构”。这个信息决定了它会用哪套技术栈习惯来写代码。第二层是任务与约束。把目标说清楚之外必须列出“不能做的事”。经验是约束比目标更重要。比如“不要修改现有接口签名”“不要新增第三方依赖”“错误处理统一走全局异常处理器”“不要动数据库迁移文件”。第三层是验收与输出格式。让它“改完两个文件后给出一份改动说明并写出对应测试用例”。提前定义可验证的标准AI才不会交出一堆你以为对、跑起来就废的代码。2.3 一个具体例子从模糊需求到可执行任务举个例子。模糊版本是帮我写一个订单超时自动关闭的定时任务。我实际会这么写背景这是一个商品交易后端技术栈为Python 3.11 FastAPI PostgreSQL 任务调度用的是APScheduler。 任务新增一个定时任务每5分钟扫描一次订单表把创建时间超过30分钟、 状态为“待支付”的订单批量更新为“已关闭”。 约束 1. 不要改动现有订单查询逻辑新增独立模块。 2. 数据库更新用现有的事务管理方式。 3. 每次扫描最多处理500条避免长事务锁表。 4. 必须记录处理数量日志日志格式与项目现有格式一致。 5. 不要新增依赖。 验收提供新模块的代码、定时任务注册方式以及针对边界情况的 单元测试思路空表、超过500条、并发触发。你看这跟直接甩一句“写个定时任务”的区别是本质性的。AI拿到这个提示词之后不会自己去猜业务规则也不会引入什么新异步框架产出的代码基本贴近项目风格。即便有不满意的地方也是在现有逻辑上调而不是推翻重来。2.4 让AI先给计划再动代码在我用Agent模式时还有个习惯我不允许AI拿到任务就咔咔改代码。我会先让它“先读这几个文件列出改动计划等我确认后再动手”。很多Agent工具本身就支持这个流程。这一步看着多花几十秒实际能省大量返工时间。因为AI列出来的计划本质上就是它对这个需求的理解。你看了之后马上能发现“它理解偏了”还是“方向对路”不理解的地方在写代码之前就纠正掉了成本极低。另外建议把团队里反复用到的规范沉淀成一个固定文件比如项目根目录的ai_notes.md或者 Cursor 的 Rules 文件让AI每次会话都自动带上这些约束。这样你的提示词不用每次都重复一大堆规则AI输出的风格也会前后一致。3. Cursor实测从Tab补全到Agent模式我的真实感受Cursor是我目前日常主力。它本质上是基于VSCode改的AI IDE但我用它至今最深的体会是它不是一个“给自动补全加了个AI”的玩具而是一个可以接管完整研发动作的平台。3.1 Tab补全真正改变手指肌肉记忆的功能很多人低估了Tab补全的威力。用过一段时间后你会发现它不只是“敲几个字母补出词”而是能根据你当前文件和项目上下文预测你接下来要写的整段逻辑。比如你写一个处理用户注册的函数刚敲完函数签名按下Tab它能把参数处理、校验、调用户表、发欢迎邮件这一串都补出来。补出来的代码风格跟你前面代码的风格基本一致因为它读了你文件里已有的写法。我个人的用法是让它补全但补完之后不会直接保留而是先扫一眼有没有逻辑偏差。补全内容一旦超过十行建议一定要过目一次。它补得再像也只是“大概率正确”业务边界需要你把关。3.2 Agent模式跨文件改代码的正确姿势Cursor的Agent模式有的版本叫Composer是让我把它从“编辑器”升级成“协作者”的关键。你不再把需求发给一个聊天窗口而是让它自己搜索代码库、定位相关文件、跨多个文件改动甚至执行命令跑测试。这个能力很强但也很容易失控。我给自己定了几条使用纪律。第一凡是涉及多文件大改先让Agent阅读相关文件并输出改动计划确认后再执行。第二给任务时限定文件范围——“本次只允许修改app/services和app/api目录”防止它顺手改了一堆不相干的文件。第三改完后要求Agent先运行对应的测试命令不要让它改完就“交作业”测试跑挂了它自己会先修。3.3 Rules文件把项目规范写进AI的“入职手册”Cursor的Rules全局规则和项目规则是我非常推荐弄起来的功能。全局规则可以放通用偏好比如“代码注释用中文”“函数命名遵循PEP8”“改动不能破坏现有测试”项目规则放到.cursor/rules目录比如“本项目的数据库操作必须走repository层不要在路由里直接写SQL”“第三方依赖版本以pyproject.toml锁定为准”。这些规则的作用相当于给每个新会话的AI发了一本员工手册。它不需要你每次都重新解释项目规矩AI会在生成代码时自动参考。我建议在搭建项目第一天就写好而不是等项目代码多了再补。补规则的效力永远不如一开始就约束住。3.4 实测强项与翻车现场优点方面最突出的是对“当前文件语境”的理解。在我用Go写服务时它能基于当前函数里的上下文自动生成结构体字段、接口配套代码这个在一些国产IDE插件上还经常跑偏。另一个强项是多文件串联改动比如把一个服务的日志全部从fmt.Println换成统一logger包Agent能一下子把十几个文件都改对。翻车点我也遇到过不少。最典型的是依赖版本幻觉让它引入新库写功能它会照着训练数据里的旧版本API给你写代码结果一跑就报错。另一个是大仓库索引慢代码一多补全响应明显延迟有时候补到一半我就放弃了。还有一个是“闷头改”Agent改完了文件但不主动告诉你它到底动了哪些地方不主动跑测试除非你明确要求。这些都需要你用规则去约束或者用git diff去复盘。3.5 Cursor的提速小技巧最后分享几个我实测有用的细节。大改之前先git commit这一步保证你能随时回到安全点。用CmdEnter或对应快捷键让AI带上仓库索引来回答比直接选中代码片段“CtrlK”效果差很远。长上下文任务优先在设置里切换大上下文模型别让完整贴入的中型函数被截断。还有就是对话里多贴报错日志别只把“这段代码我给你告诉我哪里错”丢给AI带上运行环境信息和完整堆栈它通常会直接定位到问题根因。4. Codex和Claude Code终端Agent的威力与边界先说明一下这里说的“Codex”主要指OpenAI的命令行Agent工具Codex CLIClaude Code是Anthropic家的同名终端工具。第一次用这类工具的人会有一种很奇妙的体验有点像你坐在工位上带了一个能力很强的实习生你告诉他要做什么他噼里啪啦就在终端里开始读代码、改代码、跑测试、给你报告。4.1 为什么我还在终端里用AI有人说IDE里都有了为什么还要单独开个终端Agent我的答案是任务类型不一样。IDE里的AI更擅长“围绕你正在看的文件转”而终端Agent天生就是“围绕整个仓库转”。你在IDE里让AI改一个跨模块的逻辑它往往只盯着你打开的文件或者它自己索引到的少数文件但Codex/Claude Code这类工具会用类似“先搜代码、再读代码、再改代码”的方式把任务链路打通。尤其适合两种场景。一种是老项目代码没文档、历史包袱重你让Agent“把订单模块的创建接口从同步改成异步保持对外返回结构不变”它能自己把上下游调用关系找出来评估改动点。另一种是任务拆解明确、可验证的小项目让它从Issue描述直接写实现甚至自动提交commit。4.2 Codex CLI的实际落地体验我在一个Go项目里实测过Codex CLI。流程是在项目根目录运行codex然后输入一段任务描述比如“给订单状态变更逻辑加一个超时重试机制对网络错误采用指数退避重试3次不改变对外接口”。它会先自己读合约和调用链然后列出一个改动计划再动手改文件最后还会尝试跑go test。让我印象最深的是它懂“进度反馈”。它不是闷头一口气改完给你惊喜而是先把改哪个文件、为什么不改某个文件都讲清楚。如果我不同意可以在它动手前叫停。这个交互方式比IDE里“生成了一堆代码你慢慢看”要高效得多因为你在代码生成之前就控制了方向。4.3 Claude Code在复杂重构和解释旧代码时的优势Claude Code给我感觉是“自然语言理解更细腻”。我给过它一段祖传的PHP代码让它先帮我梳理这段逻辑再按新业务要求重构。它能把代码的隐藏逻辑、可能的边界条件都梳理成清晰的描述然后给出重构方案还会建议我保留哪些行为不变。这种事如果纯靠人肉看没有两小时看不明白。但Claude Code也有个很现实的问题长任务很费token。我自己用过一次大规模目录重构会话还没到一半额度烧得我心都在滴血。所以用它的经验是小任务用它不划算大任务一定要先把范围圈死不要让它自由发挥去探索一堆无关代码。4.4 给Agent权限前先把安全边界划好终端Agent能直接跑命令这是它强大也是它危险的地方。我强烈建议第一次用的时候单独拉一个git分支给Agent一个“允许折腾”的独立空间。如果项目里没有CI或者本地测试让Agent改完直接交付风险特别大你根本看不出它是否偷偷破坏了什么。另外要注意别在任务描述里粘贴密钥或者把内网域名、数据库地址写进去。这类内容一旦进入远端模型的上下文相当于把公司资产送到了外部服务端合规上是很大的隐患。我一般会把环境变量之外的信息都脱敏后再丢给Agent。5. 本地部署大模型编程助手动手前先算清这笔账本地部署AI编程助手是隐私敏感场景里绕不开的话题。我自己也折腾过一阵子结论是它能救急也能当底线方案但别指望它达到GPT-4级别Agent的完整体验。5.1 为什么会有人坚持本地跑模型主要有三类原因。第一是数据敏感公司的代码和注释不能出内网这个理由最硬。第二是长上下文成本一些外部API按tokens计费长期开着当自动补全成本高本地模型多跑几次不花钱。第三是断网离线环境下开发比如出差、代码隔离区本地模型是唯一能提供智能补全的方式。5.2 我试过的方案Ollama Qwen2.5-Coder Continue我的个人实践是本地用Ollama跑模型IDE里用开源的Continue插件搭桥。安装这类工具链不难大致是下载Ollama然后用命令把模型拉到本地ollama pull qwen2.5-coder:14b然后在VSCode里装Continue插件配置模型地址指向本地Ollama。这样IDE的补全和对话就能走本地模型代码完全不用出机器。5.3 硬件需求表与量化常识很多人问“我16G内存能不能跑”。能跑但能不能跑得好取决于模型大小和量化方式。B是模型参数规模4-bit量化会在几乎不损失太多效果的情况下显著减少内存占用。大概参考如下模型规模大致内存需求Q4量化建议配置体验7B约6-8GB16GB内存6GB显存补全流畅对话稍差点14B约10-14GB32GB内存12GB显存补全质量明显好生成有延迟32B约22-28GB64GB内存24GB显存效果接近API小模型硬件成本高我的经验是如果只用于补全7B到14B足够如果希望它理解复杂逻辑并做Agent式对话本地模型和API模型的差距立刻暴露。5.4 本地部署的性价比真相用了大半个月我最大的感受是本地部署适合做“补全工具”不适合当“重构Agent用”。它在你写代码时给出风格一致的下一段很有帮助但让它跨文件做涉及业务规则的修改常常答非所问。尤其是一些需要“项目全局视野”的任务本地模型要么算力不够要么上下文窗口处理不过整个仓库效果和云端API模型差一个量级。所以我现在的策略是“混合用”日常补全走本地小模型敏感模块处理也走本地涉及复杂重构、跨模块设计时还是切回云端工具把该脱敏的信息脱敏后再用。这样既保护隐私又保证效率也算是对成本和效果的一个平衡。6. AI编程一年踩坑记录每一条都是拿真金白银换的前面讲了很多“怎么用好”但我还是要诚实地说AI编程远没有到“交钥匙”的程度。这一整年我在生产项目里踩过不少坑有些甚至让团队项目进度倒退了几天。全记录出来希望能帮你绕开。6.1 上下文超限AI不会提醒你它“忘了前面”这个坑我踩得很早。Claude Code和Cursor这类工具上下文窗口是有上限的。当对话聊得太长或者你塞进去的文件太多系统会把最早的内容悄悄丢掉简称“静默截断”。最坑的地方在于AI不会告诉你“对不起我忘了你前面说的约束”它只会若无其事地继续回答。后来我养成了两个习惯。一是“一个任务一个会话”任务结束马上开新会话绝不把无关问题堆在同一个上下文里。二是把关键决策写成文件比如在ai_notes.md里记录“本项目数据库操作必须走repository层”“外部API调用需统一加超时0.5秒”。这样新会话的AI只要读这个文件就能快速对齐上下文不依赖之前的对话历史。6.2 幻觉代码比报错更可怕的是“看起来能跑”AI幻觉在编程场景里有两种一种是编造不存在的API这种还算好一跑就报错你能发现。另一种很阴它给出的代码语法完全正确、逻辑也大致合理但里面引用了并不存在的内部函数或者把一个事务放在循环里没意识这会导致性能问题。这类问题编译器不报错测试也能过等压力上来才炸。我现在的兜底办法是任何AI生成的业务逻辑我必须自己补测试用例。尤其是涉及金额、状态机、并发控制这三类代码绝不无测试直接上。说句实话AI生成代码的价值恰恰在于效率高而质量把关还得靠人靠真实的测试环境和压测。6.3 自动补全覆盖手动编辑小心你的Tab键这属于IDE层面的坑。Cursor的Tab补全有时候会和你手动写的代码打架。常见场景是你刚手动写完半个函数AI自动补全后半段时把你手动写的内容直接覆盖了而且不做diff也不容易发现。我当时就遇到过写好的字段被默默替换直到跑单测才发现少了关键逻辑。解决方法是开git diff检查自动补全产生的改动不要凭感觉“它补得差不多就行”。如果这块代码特别核心我甚至会先选中区域再让AI在指定区域外补全避免重叠。6.4 不跑基线测试就让AI大改灾难的一下午那次教训我记得特别清楚。让Agent重构一个支付服务它一口气改了十几个文件看起来漂漂亮亮。结果我提交一跑测试全线标红。一开始我还以为是Agent改坏了后来排查半天才发现原来测试在我改动之前就已经是红着的——我压根没跑过基线。这事听起来蠢但在快节奏开发里特别容易犯。现在我给自己定了一条死规矩任何大规模AI改动之前先把当前分支git stash或者记录当前测试状态确保基线是绿的。再让Agent改动改完后再对比“基线测试结果”和“改动后测试结果”差异才能看得清楚。6.5 权限与敏感信息的合规底线最后这条技术之外但很重要。AI编程工具基本都是云端模型你的代码提示词会作为请求发送到服务端。公司项目一定要先搞清楚数据和代码是否允许出内网。有些团队严格要求代码不能上传到外部AI服务那就老老实实走本地部署方案或者使用企业内部自建的AI网关。同时我绝对不会在提示词里写数据库密码、云厂商密钥、内网IP、真实手机号这些。给AI演示数据也尽量用example.com、0000这类假信息。这个习惯说到底是在保护自己和管理员的职业生涯。6.6 我现在每天都固定执行的一套AI编程工作流踩了这么多坑之后我把日常AI编程收敛成一套固定流程。每天开工先写ai_notes.md或查看项目规则把当天要做的任务用三层结构写成提示词让Agent先列计划确认后开跑改动前确保git分支干净重要改动先commit改完强制跑测试和diff review会话结束前把关键结论回写到规则文件里。这套流程听起来不热血但恰恰是它让我从“被AI牵着走的兴奋”回到“按自己节奏推进”的状态。如果你现在正被一堆AI工具整得手忙脚乱我的建议很简单先关掉一半工具把剩下那个用熟练再来说提效的事。AI编程确实是这个时代给开发者最好的礼物之一但礼物再好也得有会拆的人。