1. 为什么我放弃了“对话式问代码”——聊聊AI编程的正确打开方式先说说我自己的经历。有一段时间我特别热衷于在ChatGPT、Claude这类工具里问“帮我写个爬虫”“用Python实现一个排序算法”拿到的代码大部分时候也确实能跑。但到了真正干活的时候比如给公司的内部系统加一个功能模块或者重构一个历史遗留项目这种“对话式问代码”的做法就完全失灵了——倒不是AI不行而是我用它的方式根本不对。那段时间我最大的困惑是为什么AI写的单文件Demo这么溜放到真实项目里就各种别扭后来我慢慢明白了一个很扎心的道理写代码只是编程里占比很小的一个环节理解需求、拆解任务、定位Bug、处理边界、跟现有系统整合这些才是最花时间的地方而AI在这些环节里能帮的忙取决于你怎么用它。这篇文章不打算讲什么“AI会取代程序员”之类的宏大叙事就想老老实实把我自己从“拿AI写玩具代码”到“拿AI做真实开发”这个过程里踩过的坑、总结出来的方法分享出来。不管你是刚入门想用AI提速的开发者还是已经用Copilot/Cursor一段时间但感觉“也就那样”的同学这篇文章应该都有点参考价值。先说一个结论AI编程真正有用的形态不是“你问它答”而是“你指挥它干”——这中间的差别就是我文章标题里说的“做真实编程”和“玩AI”的分水岭。2. 从聊天窗口到编辑器我的AI编程工具链演变2.1 工具选型从Copilot到Cursor再到Claude Code最早我用的自然是GitHub Copilot它的补全能力确实不错写个函数签名、重复性的样板代码体验很顺畅。但它的短板也很明显它更像一个“高级自动补全”不适合处理跨文件的修改。比如我想要它“把用户模块里所有硬编码的状态值改成枚举类型”Copilot基本只能在我打开每个文件时给出零碎的局部建议很难做主逻辑的重构。后来我换到了Cursor这是一个基于VS Code二次开发的AI编辑器。它的核心卖点是“代码库级别的上下文理解”——你选中一段代码或者直接问它关于整个项目的问题它能基于向量索引把相关的文件都找出来。实际体验下来处理“跨文件改动”确实比Copilot强很多尤其适合那种“帮我把所有异常处理的格式统一一下”的批量操作。最近几个月我又开始重度使用Claude Code。如果说Copilot是“补全选手”Cursor是“搜索改代码选手”那Claude Code更像是一个“能自己读代码库、自己跑测试、自己改完文件再跑一遍验证的Agent”。它可以按照你给的命令在终端里连续执行多步操作比如“先看README再找到配置文件的加载逻辑修改后再运行测试用例验证”整个链路它都能自己串起来。2.2 Agent模式能做什么、不能做什么我花了不少时间才真正搞明白Agent模式的边界。以Claude Code为例它能做的读取指定目录下的多个文件理解项目结构跨文件追踪数据流比如一个变量从接口入口到数据库层的完整流转自动跑测试、根据报错信息迭代修改代码执行git diff、git log之类的命令来理解最近的改动但它不能做的或者说做不好的往往更值得关注它没法真正“理解”业务上的隐性约束比如“这个字段历史上有过数据迁移不能直接改动”它在面对那种“没有明确报错只知道结果不对”的问题时容易漫无目的地瞎试它处理超大项目时即使有上下文压缩还是容易丢失某些关键细节所以我的结论是Agent模式的本事在于“执行”不在于“决策”。你可以让它把“改A文件、改B文件、跑测试”这条链路执行得非常利索但哪些事该做、哪些事不该做、改动会对哪个兄弟模块产生什么影响这些判断必须由你来做。3. AI写的代码三分能跑七分要修真实项目里的认知偏差3.1 从零到一很快从一到九十九全靠人我团队里有个刚转正的同学一开始特别迷信AI。他觉得AI写代码又快又全自己只要复制粘贴就行。有次他负责对接一个第三方支付接口AI把整个接入代码都写好了——HTTP签名、回调验签、异步通知处理看起来像模像样。结果联调的时候发现一堆问题回调接口没有做幂等处理签名算法里有个参数顺序不对超时重试策略根本没写直接把数据库写入了大量重复订单。这个例子特别典型。AI非常擅长“从零到一”——把一段需求的骨架代码搭出来因为网上有海量的类似案例可供参考。但“从一到九十九”就完全是另一回事了幂等性、并发安全、异常兜底、可观测性日志、参数校验这些生产环境必须考虑的东西AI不会主动替你想到除非你的提示词里明确提到。打个比方AI像是一个读过很多菜谱但没怎么下过厨的人。你让它做一道红烧肉它能给你列出配方和步骤做得八九不离十。但实际操作中火候该多大、什么时候该转小火、收汁收到什么程度这些只能靠掌勺的人来判断——而你就是那个掌勺的。3.2 AI不知道你的技术债和历史包袱真实的工程项目几乎没有一个是“从零开始写的”。你的系统里必然存在历史原因留下来的奇怪设计某个表结构为了兼容老版本故意冗余了字段、某个模块的性能问题众所周知但一直没重构、某个接口的返回格式被三套不同时期的规范搞得乱七八糟。这些“技术债”和“历史包袱”AI是不知道的。它看到的只是你当前代码库的状态它不会知道“这个函数之所以写这么绕是为了兼容2019年上线的一版移动端老逻辑”。如果你不加提示地让它“优化这个函数”它大概率会按照教科书式的写法给你“优化”得漂漂亮亮然后老逻辑就崩了。我在刚用AI重构一个权限校验模块时就吃过这个亏。原来的代码里有一段很诡异的判断逻辑我让AI“简化”它结果它把中间一个关键的特殊分支删掉了——那个分支是为了支持一个已经很少有人用但还没下线的“访客模式”。上线之后企业客户那边直接报白屏最后紧急回滚。所以我现在给自己定了一条规矩任何涉及历史包袱的代码改动必须在提示词里把背景说清楚告诉AI“这个特殊的逻辑是为了支持什么情况不要动它”或者让AI先解释这段逻辑的作用经过你确认后再动手。4. 让AI理解整个项目而不只是单个文件4.1 上下文工程给AI足够的“前情提要”用AI编程到一定阶段后你会发现一个规律你给AI的上下文质量直接决定它的输出质量。不是提示词写得漂亮就行而是它“看见”的信息够不够多、够不够准确。普通的聊天式问代码你给AI的信息就是那几句话但在做真实项目时你需要让它理解的东西远比这个多——它得知道这个项目用的什么框架、遵循什么目录规范、相关的其他文件里有什么约定、你要改的地方被谁调用、调用方期望什么行为。我自己常用的做法是“三段式上下文”先告诉AI项目的基本情况技术栈、项目类型、关键目录结构再告诉它这次任务的具体目标要修什么Bug、要加什么功能、有什么约束条件最后把跟任务相关的文件路径或关键代码片段直接贴给它在Cursor里我通常会同时打开所有相关文件然后选中其中核心的那段代码在提问栏里用符号把其他相关文件也引进来。这样做有一个很实际的好处AI在生成修改方案时不会只盯着你当前打开的那一个文件而是会参考其他文件的命名规范、数据结构和调用约定。4.2 结构化任务拆解从“读懂项目”到“小步快跑”还有一个特别重要的习惯一次只让AI做一件事不要给它一个庞大的任务。有一阵子我想让AI一次性完成“给用户系统增加企业认证功能”结果提示词写了二三百字包含了数据库表设计、接口逻辑、前端页面、权限控制——AI给出的方案看起来很完整但真正执行起来处处是坑因为它的完整只是“看起来完整”内部各部分的衔接它根本没有真正验证过。后来我改成了这样第一步让AI先读一遍现有的用户表结构和登录流程总结一下现状第二步让AI出一个“企业认证”功能的设计方案包括表结构变更和接口列表第三步确认方案没问题后先让AI写数据库迁移脚本第四步再让AI实现服务端核心逻辑第五步最后接前端每一步都是小步快跑每完成一步我都能验证。这样做的好处很明显如果AI在最后一步出现了方向性错误你只需要重做最后一步前面的成果不受影响。从实际效率来看这种“拆得很碎”的做法看似每一步都要多几次交互但总体进度反而比一次性给AI一个大任务要快得多。5. 调试才是真正的战场AI帮不了你的那些事5.1 定位BugAI能猜但未必能查说句实话我在实际项目里花时间最多的不是让AI写新代码而是让AI帮我排查bug。这个场景下AI的发挥很不稳定。有次我发现线上的一个接口偶尔会返回500日志里有空指针异常但堆栈信息不完整。我把报错信息扔给AI它倒是很快给出了好几种可能的原因“可能是这个字段没做空判断”“可能是这个服务在超时后返回了null”“可能在并发情况下缓存没命中”。说实话这些猜测我不用AI也能列出来而且列得可能比它还全。真正有用的场景是把完整的日志、相关代码片段、调用链信息都喂给AI让它帮你画出一条数据从入口到异常点的完整路径。这时候它能发挥“人肉阅读代码能力”的长处——分析速度比人快尤其适合那种跨多个文件的调用链排查。所以我的经验是AI适合做“基于已有信息的分析和推理”不适合做“盲猜”。你给它的信息越完整它分析得越接近真相如果你自己都还没搞清楚问题出现在哪个环节指望AI从一两行报错信息里准确定位问题那基本是在赌运气。5.2 让AI成为结对程序员而不是背锅侠我后来想明白了一个更准确的比喻用AI调试就像跟一个经验丰富但有时候会想当然的结对程序员一起干活。它会给你建议、帮你分析可能的走向但最终决策和验证逻辑必须是你自己来做。尤其是“改动代码之后怎么验证”这个环节AI的可靠性真的不太行。你让它“修完这个bug之后检查一下会不会影响其他调用方”它往往会顺着你的话说“不会影响”或者“影响很小”但实际上它只分析了部分调用路径。更靠谱的做法是改完代码后把git diff结果拿给AI让它逐行审查这次改动特别留意它自己写的时候逻辑上不严谨的地方——这个用法我后面会专门说。我自己在团队里还推过一个“AI结对编程”的规范每次用AI改完代码必须自己再跑一遍相关的测试用例和主要功能流程同时在代码评审时重点审查AI改过的部分。不是说AI改的就一定有问题而是AI改的比例越高越要警惕那些“看起来都对但被忽略了”的边界条件。6. 代码审查和安全红线AI生成内容的最后一道闸6.1 安全隐患要人审如果说前面讲的都是“效率”层面的问题那“安全”就是一条绝对不能含糊的红线。我在DeepSeek/ChatGPT上经常看到有人贴出带数据库连接串的代码去问AI“我这段代码有什么问题”——这就是早期容易踩的大坑。当然这里我不讨论安全合规但至少从工程实践上说任何涉及密钥、口令、敏感数据的代码审查的环节必须严格放在本地不能因为AI生成就放松警惕。举几个我自己见过的AI生成代码里的安全隐患把API密钥硬编码在代码里AI觉得这样“简单直观”在日志里打印了完整的用户手机号或身份证号AI不会主动想到脱敏在SQL查询里直接拼接用户输入AI默认你传入的参数是可信的文件上传功能没有限制文件类型和大小AI按最“齐全”的写法把所有校验都注释掉了这些都是很现实的问题。AI生成的代码逻辑上可能完全正确但在安全视角下可能漏洞百出。我现在的一个习惯是凡是AI新增的涉及外部输入、数据库操作、文件读写、网络请求的代码我都要人工重点过一遍不能拿“AI写过了”当借口跳过审查。6.2 不要迷信AI的自信还有一个容易让人放松警惕的现象AI在回答技术问题时的语气通常都很笃定不管它给你的方案是成熟的还是想当然的。举个例子有次我问AI“在Python里用多线程处理千万级数据有什么要注意的”它洋洋洒洒列了七八条注意事项都很有道理。但如果只照着它说的做你还是会踩到GIL全局解释器锁带来的性能坑——因为它的建议是基于“常规多线程”场景的而你实际需要的可能是多进程方案。这种“方向性原则性错误”AI不会告诉你除非你明确问它“我这个场景下到底该用多线程还是多进程”。所以我特别强调一个技巧拿到AI的方案时先追问它一句“你这个方案的假设前提是什么”。如果它说的前提跟你实际情况不符那就得重新评估。这个追问看似多了一步但能省掉大量后面返工的时间。7. 真实项目落地三个我认为最有价值的提示词习惯7.1 任务描述模板把“背景-目标-约束-验证”写全很多人的AI编程提示词是“帮我写个XXX”这种写法放到真实项目里基本没用。我现在自己用的提示词基本上固定一个模板背景这个项目是XXX技术栈在xxx模块里存在XXX逻辑 目标我想实现/修复XXX 约束不要改动XXX遵循项目里已有的XXX规范对输入做XXX校验 验证改完之后请跑一下test_xxx.py或者检查XXX部分的diff不要嫌麻烦。写清楚背景和约束比反复跟AI来回解释要省时间得多。尤其是“约束”这一条几乎每次都要写——因为AI默认会往“最通用、最标准”的方向写而真实项目往往需要的是“符合现状”的代码不是“最标准”的代码。7.2 让AI先说方案再写代码第二个习惯是不要一上来就让AI写代码先让它给你出方案。这招我是从一次惨痛教训里学到的。那次我想给内部管理后台加一个“导出Excel报表”的功能。我直接让AI写实现几分钟后它给我写出了一段看起来没毛病的代码用的是POI库。但等我们要集成的时候才发现服务端环境版本太老跟POI的最低版本要求不匹配导致整个服务起不来。如果当时先让它“给我几个导出方案的对比”它可能会提到用CSV导出轻量、不需要额外依赖、用模板填充适合复杂格式、用POI功能全但依赖重这几种路线我就能结合自己项目的情况选一条更合适的。方案先行是为了避免“代码对了但方向错了”这种最浪费时间的情况。7.3 追问“为什么”和“还有哪些边界情况”最后一个习惯也是我用了很久才意识到的AI给完方案或代码之后一定要追问“为什么”和“还有哪些边界情况”。为什么是“为什么”因为很多时候AI给你的代码能跑但你不清楚它为什么这样写。比如它帮你实现了一个“批量导入”功能里面用到了分批处理。如果你不问你就不知道分批的size参数是它拍脑袋定的还是根据性能测试算出来的。把它写成一个审核项追问清楚之后你才能真正接手这段代码——真实项目里只有你完全理解的代码你才敢上线。为什么追问“边界情况”因为AI生成代码时默认你传给它的数据都是“理想情况下的干净数据”。但你真实的用户输入里会有空字符串、超长文本、特殊字符、并发请求、重复提交。这些边界情况AI通常不会主动处理除非你问它它才会象征性地补上几个if判断。8. 我踩过的那些坑和你可能会踩的坑8.1 AI代写的代码进了代码评审被同事打回来的那次有一次我让AI帮忙写一个数据同步逻辑它写得很漂亮用了stream流、lambda表达式看起来又简洁又高级。我一时大意没有仔细看逻辑就提了PR。结果同事在做代码评审的时候发现了一个问题这个同步逻辑在遇到某条数据校验失败时会抛异常导致整个批次的后续数据全部不执行了。这个就是典型的“代码看起来高级但实际不健壮”的例子。AI倾向于把逻辑表达得优雅但优雅不等于健壮它不会主动去考虑“这批数据里有一条脏数据怎么办”这种现实问题。从那以后我给自己的规矩升级了AI生成代码后先自己看一遍再让AI自己审一遍把diff贴给它让它找问题最后还要过人的评审。三道关卡下来出问题的概率就低多了。8.2 告诉AI“现有语言版本太老”有多重要还有一个很低级但很常见的坑AI往往会默认你用的是比较新的语言版本或框架版本。比如Java项目里AI很喜欢推荐你用var关键字、用record、用List.of()之类的现代写法。如果你们项目还在Java 8这些代码编译都过不了。Python项目也一样AI默认你会用3.10以上的版本但很多企业项目还停在3.8或者3.9。解决方案没什么花哨的就是在背景描述里明确写上技术栈版本“这个项目是Java 8 Spring Boot 2.x请遵循这个版本的语法习惯”。AI不会主动关心你的技术栈版本但只要你注明它就会乖乖按版本约束来写。这个细节能在集成阶段帮你省掉大量的“复制后发现编译失败”的挫败感。9. 现在的我是怎么用AI做真实编程的9.1 我的日常协作流程最后总结一下我自己目前相对稳定的一套用法。这套流程经过大半年试错我可以说是踩坑踩出来的实践经验拿到需求后自己先梳理一遍逻辑明确“要做什么、不能碰什么、验收标准是什么”把需求和上下文整理成提示词让AI先出方案我和它讨论方案的优缺点后再确认方向拆解成小步骤让AI按步骤实现每完成一步我都在本地验证一次全部实现完后跑测试、跑主流程再把diff交给AI做一轮自审自己再过一遍代码尤其是外部输入、数据库操作、文件读写这些安全敏感点提交PR并在PR描述里明确标注“哪些部分是AI生成的、哪些是我人工改过的”方便评审同事有重点地进行审查9.2 给刚准备用AI做真实项目的朋友们的建议如果你刚准备把AI从“玩具”变成“生产力工具”我建议你先从“辅助理解别人的代码”开始而不是急着让AI帮你“写新代码”让AI帮你解释一个你不太懂的老模块的逻辑它往往能给你讲得很清楚让AI帮你给一段复杂代码写注释可以省不少时间让AI帮你搜索项目里某个变量被哪些文件引用了在IDE里它是一个工具在AI这里它可以帮你穿越文件边界梳理依赖等到你对AI的输出风格和工作边界有了感觉之后再慢慢让它参与实际功能开发、Bug修复和重构。有个很朴素但有效的心得你在哪个环节跟AI协作得最顺畅就让它多做那个环节的事哪个环节总是出问题就暂时别用它做那一环的工作。AI编程不是“A I替你编程”而是“你和AI一起编程”这个心态摆正了工具才能真正派上用场。