我先说个真实感受这两年我用 AI 写过的生产代码比我前五年自己敲的还多。但真正让我对「AI 编程」改观的不是它能生成多少行代码而是它确实能帮我处理那些脏活累活——补测试、查兼容、理老代码。这篇文章没有高大上的理论全是我在真实项目里用 AI 编程的实际流程、提示词模板和踩坑记录适合那些已经把 AI 用在副业、但还没敢让它碰核心工程的同学。1. 真实编程和「让 AI 跑通 demo」差在哪1.1 从一次翻车说起去年我用 AI 写过一个爬虫。单文件、依赖少、跑起来很顺数据抓得也挺干净。我当时觉得AI 编程不过如此。结果把它往公司项目里一塞直接挂掉——项目里有统一的日志规范、超时控制、代理配置、依赖版本锁定这些 AI 一概不知道。它给我的是「能跑」的代码但不是「能上线」的代码。这个教训让我想明白一件事真实编程的难度从来不在「写出一段逻辑正确的代码」而在「这段代码能不能放进一个已经有十年历史、有团队规范、有线上流量、有天量异常路径的系统里安安稳稳地跑下去」。AI 擅长前者后者才是人的主场。1.2 真实工程里的四笔隐形成本用 AI 做真实编程第一个要建立的概念就是「隐形成本」。一个功能从「AI 写出来」到「真正发布」中间隔着四样东西业务约束不仅仅是功能对不对还要考虑数据和权限边界。比如导出接口不能把所有人的手机号都导出去AI 不知道你的业务规则。团队规范命名风格、目录结构、错误码约定、日志格式。这些在 AI 的训练数据里存在但你项目里的具体约定它只能靠猜。运行环境差异本地能跑、测试环境能跑、生产环境不一定能跑。文件路径、内存上限、并发模型、中间件版本全是变量。长期维护成本代码是写给下一次看的人包括三个月后的自己。AI 生成的「压缩饼干式」代码往往注释少、命名随意、抽象过度后面接手的人想骂人。这也解释了为什么很多人说「AI 写的代码不敢用」。不是 AI 不行而是缺了一个环节——你需要用自己的工程经验补齐 AI 看不到的上下文。2. AI 编程工具的实际分工2.1 我每天都在用的三类工具现在市面上的 AI 编程工具眼花缭乱但按工作方式分其实就三类。我身边总有同事问我「到底哪个最好」我的答案一直是分类看别指望一个工具干所有事。工具类型代表定位适合场景注意点IDE 插件GitHub Copilot、通义灵码、CodeGeeX补全型选手写代码时的逐行补齐、函数级生成、注释转代码对全局上下文感知弱容易生成风格违和的代码对话式模型ChatGPT、Claude、DeepSeek讨论型选手方案设计、代码解释、逻辑推演、排查思路不主动看你项目需要你把关键代码贴给它上下文编辑器Cursor、Trae、JetBrains AI 助手等结对型选手直接在项目里选中代码段提问、生成 diff上下文窗口有限超大型 repo 还是抓瞎Agent 工具Cline、Codex 等执行型选手批量重构、跨文件机械修改、自动跑测试修错改动范围大必须严格审查 diff短期别让它独立改业务核心模块我个人的组合拳是IDE 插件负责日常补全不打断思路遇到复杂需求我会把相关代码片段丢给对话式模型先聊清楚方案再动手上下文编辑器用于需要精准改动单个函数的场景Agent 类工具我只在机械性重构时才会用比如批量把print改成统一日志、把某个老接口的参数从str换成enum。这类改动路径清晰、验证明确Agent 很在行。2.2 选型不必「All in One」按任务选工具很多人挑 AI 工具像挑手机非要分个高下。真实情况是同一个项目里我会同时用三个工具各管一段。举个例子我最近在做的一个数据同步模块设计同步策略时用对话式模型讨论主从冲突怎么处理、失败重试用什么策略、幂等怎么保证。写具体同步函数时用 IDE 插件补全生成基础的fetch/transform/load框架。遇到某个同事写的晦涩函数直接在上下文编辑器里选中那段代码让它解释给我听。最后用 Agent 工具把这个模块里的重复代码统一抽取成公共方法。这套组合拳打下来每个工具都在干自己最擅长的事。你不需要担心工具之间切换会不会打断思路因为真实编程本来就是一件多线程的事情——设计、编码、调试、重构本来就交替出现。3. 可复制的 AI 编程对话流3.1 一份能用的提示词模板四个上下文要素很多人用 AI 写代码时上来就是一句「帮我写个登录接口」然后抱怨 AI 写得稀烂。问题不在 AI在你给的上下文太少。我总结了一套提示词模板核心是四个要素项目背景、技术栈、代码位置、约束条件。写清楚这四样AI 的输出质量会提升一个档次。先说我自己常用的一个模板你是这个项目的资深后端工程师。 项目技术栈是 Python 3.11 FastAPI SQLAlchemy 2.0。 现在需要新增一个 GET /api/orders/export 接口返回全部订单的 CSV 文件。 请先阅读 server/main.py、api/routes/orders.py、models/order.py 这三个文件 搞清楚现有的鉴权方式和错误处理约定然后 1. 给出接口设计说明包括错误码和返回格式 2. 复用现有的 resp 工具函数不要引入新依赖 3. 对数据量做上限保护超过 10 万行给出明确报错 4. 先不要写代码先列出你要改动哪些文件、每处改什么。这个模板的关键动作是「先不要写代码先列出改动计划」。我让 AI 在动笔之前先汇报思路这样我能第一时间发现它的误解而不是等它写完一大坨再花更多时间纠正。真实工程里改错一个接口签名比多写十个函数代价更大。3.2 把大需求拆成 AI 能吃的任务第二个心法是拆任务。AI 跟我们一样一次处理的信息量有限。你让它「帮我做一个完整的订单系统」它只会产生一坨难以维护的缝合怪代码。真实项目里我会把一个功能拆成五个左右的小任务每个小任务都能独立验证第一步定义数据结构让 AI 生成数据模型和字段校验规则。第二步写访问层只做数据库读写不掺业务逻辑。第三步写业务规则一个函数只管一件事。第四步写接口层参数验证、鉴权、调用业务层。第五步补测试和文档。每步之间我都会做一次代码审查确认没问题再进下一步。这样做的好处是出问题你能精准定位到是哪一步 AI 开始跑偏而不是面对一整屏的代码无从下手。拆任务还有另一个隐藏价值它逼着你先想清楚设计。很多程序员自己动手时习惯边写边想但让 AI 动手之前你必须先把大方向想明白不然 AI 的「自由发挥」会让你原地爆炸。3.3 让 AI 先读代码而不是先写代码真实编程里最有价值的场景之一是让 AI 帮你理解陌生代码。我接手过很多历史项目老同事离职、文档缺失代码全靠猜。以前碰到这种情况只能硬啃现在我会直接把文件丢给对话模型问它几个问题这个模块的整体流程是什么这个函数为什么这么写里面的注释都不在了。这里有段看起来永不执行的逻辑是 bug 还是有意为之这个过程的重点是让 AI 复述代码逻辑你来做判断。AI 的代码理解能力在多数场景下相当靠谱但偶尔也会自作聪明地帮你补全「作者的意图」这时候你反而是那个发现问题的人。把 AI 当外援军师而不是当权威这是我在真实项目里最深的体会。我之前在处理一个 MapReduce 风格的数据处理任务时项目里的一个 reducer 函数特别晦涩几十个状态变量互相纠缠。我花了一个下午没理清楚后来把它拆成几段丢给 AI让它一段一段解释再用自己的话复述给同事听确认思路没错。那次之后我就养成了一个习惯看懂老代码之前不让 AI 动一行代码。先把代码吃透再只做最小改动是真实项目里最稳的策略。4. 真实项目实操两个任务全流程拆解4.1 给老系统新增一个导出接口我带你们走一遍我在真实项目中使用 AI 新增接口的完整流程。这是一个订单管理系统Python 写的几十万行代码里面的路由、鉴权、错误处理都有自己的约定。我不能直接让 AI 凭空生成一个接口得按流程来。第一步让 AI 读代码。我会把相关的三个文件路径贴给它路由文件、模型文件、公共工具文件。目标是让 AI 搞清楚现有的鉴权方式和返回结构。这一步的输出是一个「项目现状说明」不是代码。第二步让 AI 提接口设计方案。我会告诉它新增接口的功能、数据规模、性能要求。它给我方案我再根据经验调整。比如它建议直接同步导出全部订单我根据数据量判断应该加一个异步任务的方案但考虑到现有系统没有任务队列最终选择同步导出加上限保护。这步的 AI 是讨论对象不是决定者。第三步让 AI 生成实现代码。这次我会给它明确的约束返回格式、错误码、依赖限制。代码生成后我不会直接使用而是先做一次人工代码审查。我会重点看三处鉴权是否复用现有逻辑、SQL 是否走了索引、异常处理是否符合项目约定。第四步让 AI 补测试。把生成的实现代码发给它让它给出测试用例设计覆盖正常路径、权限不足、数据超限、下游超时这几种情况。然后我再加上项目特有的两个场景重复点击导出时的并发控制和导出文件编码问题老系统的 Excel 导入模块一直因为编码问题被业务投诉我吃过这个亏。这整个流程走下来一个中等复杂度的接口大概花两三个小时比我自己徒手写快了不少更重要的是每一步都有明确的验证节点不会等问题堆积到最后才爆发。4.2 排查一个线上偶发 bug比写新代码更考验 AI 能力的是排查线上问题。遇到过一次用户头像上传后偶尔出现 503 的诡异现象平时没事高峰期必现。这种问题靠肉眼盯代码很难找出来因为问题往往不在报错的那一行而在某个资源的生命周期管理上。我的排查流程是这样的把相关文件的代码、报错堆栈、线上环境信息一起喂给 AI让它列出所有可能的原因先不要给修复方案。AI 会从缓存键冲突、临时文件句柄泄漏、上游存储服务的连接池耗尽、鉴权 token 过期重试这几个角度分析。我根据经验给每个可能原因排优先级再让 AI 针对前两个嫌疑点给出加日志的方案。在预发布环境复现看日志定位。让 AI 给出修复方案我审查后小范围灰度。这次的实际元凶是临时文件没有及时关闭头像处理时先写入临时目录再上传到存储服务但句柄一直没释放。高峰期文件描述符被耗尽新请求无法创建临时文件直接抛 503。AI 最开始列的原因里也有这一条但它没把它排在前面。是我结合「高峰期必现 平时没事」这个特征把资源耗尽类问题排到前面这才少走了弯路。排查类任务的正确用法是让 AI 做头脑风暴和知识检索而不是让它直接断案。它对运行时的理解、对中间件行为的认识都相当不错但你的实战经验依然是最重要的判断依据。5. AI 代码的验收标准与安全红线5.1 我过 AI 代码时的六项检查AI 代码能不能上线最终拍板的必须是人。我的日常做法是把 AI 生成的代码当成新同事写的 patch按一套标准去 review。我把这套标准总结成六个检查项每次都照着过检查项具体看什么常见问题编译与静态检查有没有类型错误、未定义变量、语法问题AI 偶尔会写错 import 路径测试覆盖关键路径有没有测试异常分支是否覆盖AI 喜欢只测 happy path边界条件空数据、超大数据、并发请求、超时情况这是 AI 最容易忽略的地方异常处理异常是吞掉了还是会暴露堆栈有没有重试机制AI 常写except: pass这类危险代码性能风险有没有 N1 查询、全表扫描、不必要的循环嵌套AI 对数据量级没有概念可维护性命名是否清晰、注释是否必要、函数是否过长AI 会生成上千行的巨型函数每次 review 我都会先跑静态检查和已有测试再人工过一遍核心逻辑最后补上 AI 漏掉的边界场景测试。这套流程看着繁琐实际执行起来很快但能挡住绝大多数坑。5.2 几条不能越的红线除了检查项我还给自己定了几条 AI 代码的安全红线几条「绝不让步」的规矩不直接使用 AI 生成的加密、鉴权、支付相关代码。这类代码出问题的代价太大AI 就算写得对也未必理解业务场景里的合规要求。我会让它给出思路但核心实现一定自己写。不在生产环境使用except: pass这种静默吞异常的模式。AI 非常喜欢用这种方式「健壮化」代码但对排查问题而言这等于把故障埋进地里。不让 AI 直接修改数据库迁移文件。迁移文件的历史记录和数据一致性非常重要AI 不了解线上数据的实际情况它生成的迁移脚本我只作参考手动改写。不对 AI 生成的代码做「无脑信任」的优化。有时候 AI 会主动建议「这里可以用线程池优化一下」但如果原来的同步代码已经够用为了优化而优化反而增加复杂度。设定红线的本质是把 AI 当工具而不是当队友。工具能帮你干活但决策权必须在自己手里。5.3 实测下来提效了多少很多人问我用 AI 编程到底能快多少。我的体感是纯机械性工作补测试、写简单 CRUD、改格式提效 50% 以上中等复杂度任务新增接口、修 bug、重构单个模块提效 30%~40%高难度设计任务系统架构、数据一致性方案、性能瓶颈分析提效 10%~20%但在方案讨论上省了大量时间。我的实测经验是提效最大的不是写代码本身而是「减少上下文切换」。以前写代码卡住了要切到搜索引擎、翻技术文档、翻自己的笔记一折腾就是十几分钟。现在直接问 AI几秒钟就有答案哪怕答案不完美也能快速提供思路。这种不打断心流的感觉才是让我真正离不开 AI 编程的原因。6. 踩坑实录与排查速查表6.1 三个最常见的错误用法跟大量朋友交流过用 AI 编程的经验我发现几个高频错误自己也都犯过写出来帮你们避雷。错误一把 AI 当搜索引擎搜到答案直接粘贴。搜索引擎返回的答案是面向广大网友的AI 生成的代码也是。你项目里数据库字段叫user_nick还是nickname你跟它说了它才会知道。不做任何适配就直接复制几乎肯定会留下隐患。错误二给 AI 的信息太少然后抱怨它「不听话」。我见过有人只发一句「这个接口怎么优化」AI 给出一个泛泛的方案他就觉得 AI 没用。真实情况是你需要给 AI 赋予足够的角色设定和背景信息它才能给出贴合实际的建议。你问得越笼统它答得越空洞这是必然的。错误三让 AI 一次生成一个超大功能。如果你拿到一个两千行的 AI 生成脚本我建议不要直接放到项目里用。AI 没有「项目感」它不会替你考虑这个模块将来怎么扩展、跟其他模块怎么衔接。拆成小任务、逐步生成、逐步审查才是可控的做法。一句话概括让 AI 帮你写函数而不是帮你写系统。6.2 排查速查表AI 代码常见问题我在日常 review 中整理了一份 AI 生成代码的常见问题速查表分享出来你遇到类似情况可以直接对照问题现象可能原因处理办法代码能编译但运行直接报错import 路径写错、依赖版本不对先看报错堆栈别急着改逻辑测试用例全过了但功能是错的测试用例和实现用了一样的错误假设人工走一遍核心逻辑别只看测试结果小数据量没问题大数据量卡死AI 没考虑复杂度写了 O(n²) 算法让 AI 改用哈希表或减少循环再跑性能测试生成的代码风格跟项目不一致没有给它看已有代码风格贴一段项目里的代码作为风格参考异常被静默吞掉看不出来哪里有问题AI 习惯用except: pass全局搜索except:要求改成日志输出函数太长一个函数几百行AI 倾向于把流程全塞进一个函数里让它按职责拆分每个函数只做一件事这张表解决不了所有问题但能帮你快速归类。AI 编程最有意思的一点是它的错误模式是稳定的你踩过一次坑就知道下次该怎么让它避开了。7. 我现在的一天AI 编程的日常节奏讲了这么多最后聊聊我现在的日常节奏也当是给大家一个参考。我的一天大概是这样开始的早上先花半小时处理消息、看代码 review 请求这个阶段我会开着 IDE 插件它会在旁边自动补全一些简单的重复代码不太需要我动脑。上午的黄金时间我会用上下文编辑器集中写复杂业务逻辑这时候我会先让 AI 读代码、列方案再进入「讨论 → 生成 → 审查 → 修正」的循环。下午一般处理 bug 和测试这类任务我会优先用对话式模型快速定位问题再进入修改流程。傍晚留一个小时给自己——不依赖 AI手写一些代码练手感。这样做一段时间以后我发现自己真正的进步不是「代码写得更多了」而是「设计能力变强了」。因为 AI 承担了执行层的琐事我有更多时间思考业务逻辑、系统边界和长期演进。以前写一个功能大半时间在抠语法、调参数、踩坑现在可以把精力放在「这个模块值不值得做」「接口应该怎么设计才不会被需求折腾死」这些更根本的问题上。最后分享一个小技巧我每隔一段时间会强迫自己不用 AI 写一个完整的小功能从头到尾纯手写。这样做不是为了证明什么而是为了保持「没有 AI 也能写」的能力。工具在进化但你的基本功才是你在技术这条路上走远的底气。依赖 AI 可以依赖到失去手写能力那就要警惕了。AI 编程现在对我而言更像是一个能力放大器。代码还是要人写架构还是要人选锅还是要人背但它确实帮我省下了大量时间让我能把精力花在真正重要的事情上。这篇文章里的所有流程和模板都是我在真实项目里一遍遍试错试出来的希望能给正在探索 AI 编程的朋友一些参考。