1. 为什么一个写了十几年代码的人突然开始认真用AI写代码先说清楚我不是那种整天追着新工具跑的人。之前看到朋友圈里有人晒AI写代码生成一堆花里胡哨的东西我内心其实是不屑的——代码这玩意儿需求稍微绕一点业务逻辑埋得深一点机器怎么可能替你拎得清直到上个月有个小任务把我恶心到了才认真尝试了一把AI写代码结果这一试原来的想法确实动摇了不少。这个任务本身不复杂客户有一批旧日志文件大概几千个文本格式乱得离谱有GBK编码的有UTF-8的有的带时间戳有的不带需要写个脚本统一清洗成结构化JSON。这类活儿以前我写过很多次闭着眼也能写但就是烦——正则要调半天编码要反复试还得处理各种边界情况。当时正好手头还有别的项目deadline压着我就想着要不让AI先出个初版我再改这大概就是很多人的第一次带着我倒要看看你能写成什么样的心态打开了一个AI编程工具。结果让我挺意外的。AI不仅给出了能跑的代码还把我原本容易忘记的边界情况都考虑到了比如空文件、乱码回退、超大文件流式读取。第一次跑通的时候手里那杯咖啡差点没端稳。这篇文章就是想聊聊我这次尝试的全过程——怎么选工具、怎么写提示词、AI写的代码到底能不能直接上线、以及踩过的那些坑。如果你也和我一样对AI写代码半信半疑或者已经在用但总感觉差点意思这篇文章值得你花十分钟看完。我会尽量说人话复杂的东西拆开了讲保证你拿回去就能用。2. AI写代码工具选型我实际用过的几款以及它们的脾气2.1 主要工具的实际体验对比既然要尝试第一步就是选工具。市面上能写代码的AI工具多到眼花缭乱我大概分成了四类对话式大模型、IDE插件、编程Agent、以及国内的一些大模型产品。我不搞那种参数层面的评测就说说实际用下来什么感受。先说我用得最多的对话式大模型。OpenAI的ChatGPT我用的GPT-4系列和Anthropic的Claude系列是这类工具里最能打的。我在这次日志清洗任务里基本用的这两款配合一些国内模型做交叉验证。GPT-4系列的长处是代码生成的整体性和规范性都很好你给它一个完整需求它能直接给出比较严谨的项目结构变量命名的语义感也在线代码风格贴近有经验的工程师手笔。Claude的长处则是上下文理解——它能记住你在很长的对话里埋过的细节比如前面那个文件路径变量后面要用在函数参数里这种跨对话的关联能力对写代码实在太重要了。这次任务里我明显感觉到Claude在处理多人协作风格的注释和复杂逻辑推导时更顺手。IDE插件类里GitHub Copilot和国内的一些替代品比如之前被不少人安利的Fitten Code插件是主流。这类工具的价值不是从零生成一大段代码而是你在写代码的时候它知道你要干什么——光标停在半行它帮你补完下一行或者根据函数名反推参数。这个体验用一句话形容像多了个手速很快的结对编程搭子。但它的局限性也很明显如果你没有开始打字它基本帮不上什么忙得有上下文它才知道怎么接。编程Agent类工具则更进一步典型代表是OpenAI的Codex和市面上号称帮你写完整仓库的一类AI程序员。Codex这类工具会把写代码这件事当成一个任务来做你描述需求它自己去仓库里翻代码、找相关文件、改掉需要改的地方然后跑测试验证。它确实能做到更像一个程序员而不只是一个打字机。不过至少在现阶段这类工具在大型项目上的成功率还达不到能放手不管的程度容易改一处带崩另一处需要人工盯得比较紧。国产大模型我也试了比如月之暗面、通义千问、智谱清言、深度求索这些产品在普通对话和通用知识问答上已经很强了代码生成能力也都在快速追赶。如果日常只是解决小函数、写正则、做点数据处理的脚本国内这些模型完全够用而且中文理解上有时候更接地气——你拿中文问帮我写个脚本把文件名里的日期提取出来排序它们的理解准确率很高。但遇到复杂项目级任务和第一梯队的差距还是能感受到的主要体现在长链路推理和代码一致性的保持上。2.2 我最后选型的结论和理由给你一个可以直接抄的结论。如果你之前完全没用过AI写代码第一选择是装一个IDE插件让AI在你手写的边上打辅助学习成本极低。如果你已经写过一些代码想体验AI独立干活那么对话式大模型是最快出成果的路径。如果你有足够的耐心和代码评审能力可以尝试Agent类工具体验真正把活交给它的感觉。我这篇文章里的实操部分主力用的是对话式大模型辅助用了一个IDE插件。为什么这么选因为这次任务是脚本级的复杂度适中非常适合对话式生成——需求说清楚上下文都在聊天里改起来也方便。IDE插件则用来处理我手动改代码时零碎补全的需求。3. 提示词工程和AI说清楚需求才是关键3.1 写代码提示词的四个核心要素很多人第一次用AI写代码张口就是一句帮我写一个日志处理脚本然后AI给了个看起来像模像样的东西跑一下发现完全不是自己想要的于是得出AI写代码不行的结论。但真相是问题不在AI在于你给的需求太口语化了。同样是说帮我把这堆日志处理成JSON高手会拆成四块说——角色、任务、约束、验收。很多朋友看到这四个词可能觉得抽象我给你直接翻译成人话。这四个词说白了就是你是谁、要我干啥、有什么规矩、干完我怎么检查。我们一个一个拆开说。角色这块你可以直接告诉AI你是一个熟悉Python和日志处理的资深工程师。别觉得这句是废话。它决定了AI输出的代码风格——是写着玩的流水账还是带着工程思维的正式实现。AI回答问题时会根据你设定的角色调整语气和深度你给它设定的身份越具体它给出的代码越接近那个水准的人写出来的东西。任务这块反而最简单——说清楚你要做什么就行。但注意一个诀窍不要只说做什么还要说输入是什么、输出是什么。比如读取一个目录下所有.txt文件每一行解析成一个JSON对象最后写入到result.json这种描述方式AI几乎不会跑偏。约束是最容易被忽略但最要命的一块。你要不要兼容旧语法运行环境是什么Python版本依赖能不能装外部的库代码里允不允许出现print需要走日志模块执行时间有没有上限你没说这些AI就按最通用最理想的方式写然后你的生产环境就会教它做人。验收标准这块以前很多人觉得没必要说反正自己会看。但我现在建议你明确写出来比如生成的JSON每个字段都要有对应类型说明文档。为什么因为AI在接到明确的验收标准后会在写完代码的同时自动补充必要的测试和类型标注——这些东西正是让它从能跑的脚本变成能交付的代码的关键。3.2 同一个需求两种问法差距有多大我直接给你看实际对比。第一种问法帮我写个脚本把日志转成JSON。AI确实会给你一个能用的脚本但大概率是单体函数错误处理全靠try-except包一层正则写得很天真编码处理基本只考虑UTF-8。你拿真实数据一跑立刻暴露问题。第二种问法我是这样写的你是一个熟悉Python异步编程和日志处理的资深工程师。现在需要你写一个命令行工具任务是把一个目录下所有扩展名为.log的文件解析为JSON。输入文件的特征可能包含GBK和UTF-8两种编码每行可能以时间戳开头也可能不以时间戳开头需要自动识别。输出要求一个JSON数组写入output/result.json每条记录包含timestamp、level、message、source_file四个字段。约束只允许使用Python标准库运行环境为Python 3.10不支持异步之外的其他并发模型出错时输出具体错误信息到stderr但不中断整体处理。验收请额外给出一个最小测试样例。结果两者的差别可以说一个天上一个地下。第二种问法AI直接给出了异步批量处理方案编码检测用的是先试错再回退的策略还贴心地处理了某个文件全是乱码的时候该怎么跳过的情况。最让我惊讶的是它还自动生成了一个测试样例考虑到了空行和异常编码。整个过程没用我操什么心。3.3 让AI自己提问比自己瞎猜省事得多还有一个实战技巧值得单独说说当你拿不准该给AI什么信息时让AI反过来问你。你可以在提示词的末尾加一句在写代码之前请先列出你需要的所有信息并说明每项信息会影响代码的哪个部分。就这一句话AI会进入一种需求澄清模式把业务字段的含义、运行环境、性能要求、输入规模逐条问清楚。比你自己对着需求文档抠脑壳高效得多而且能有效防止AI瞎猜。比如我处理日志那个任务AI问了我一个问题源文件的行数规模大概什么量级当时我愣了一下后来明白了——如果行数少同步读就完了如果上百万行就得考虑流式处理。这就是高手和AI第一次配合时会碰撞出的东西你提供事实它帮你把工程判断补上。4. 一次完整的AI写代码实操从需求到可用代码4.1 第一轮AI给出的初版质量超出了我的预期理论说了一堆现在给你完整还原一次实操过程。我挑一个真实的小例子帮一个做运营的朋友批量重命名产品图片文件。文件放在一个文件夹里命名乱得一塌糊涂有IMG_1234.jpg这种默认名也有最终版不改了.jpg这种绝望的命名还有重复命名的副本。需求是统一改成产品名_序号.jpg的格式并生成一个对照表记录原名和新名。这次我没用上面那套复杂的提示词刻意简化了一点只说你是一个熟悉Python脚本开发的工程师。帮我写一个脚本处理一个目录下的所有图片文件按产品名加序号重命名并输出原名和新名的对照关系到CSV文件。AI第一轮给的代码说实话质量超出了我的预期。它用pathlib做路径管理用正则把序号从原名中提取出来比如IMG_1234中的1234再跟产品名拼接自动处理同名冲突——重名时自动加后缀。CSV输出也用csv模块的标准写法不是那种手拼逗号字符串导致分号被拆裂的半吊子方案。我检查了一圈合规、可读、能跑。4.2 第二轮提出修改意见我当老板它当干活的人但真实场景里总有意外。朋友看了方案说产品名不能统一用一个得按子目录的名字来区分比如手机/abc.jpg应该重命名为手机_1.jpg。而且原来的1234序号要保留变成手机_1234.jpg。两个需求一叠加问题复杂了不少。我把这些要求整理成自然语言发回去没有给任何代码提示。AI在理解新需求后并没有推翻整个方案而是在原有代码基础上做了局部修改——引入了当前子目录名作为前缀同时保留了原始文件名的数字部分。关键是你得会说你把语义本身说清楚剩下的逻辑组合让AI做一般来说比你自己现场右移左移代码要稳得多。这轮交互让我体会到一个很关键的点AI写代码并不是一次性交付而是一个协作过程。你不需要会写每一行但你要能看出哪里不符合预期并且准确地把为什么和期望是什么说清楚。这种能力本质上和你带一个初级开发时给他提评审意见是一模一样的。4.3 第三轮边界条件与代码审查别想着直接跑路在拿到第二版后我没有急着交付给朋友而是做了一轮更严格的人工审查。头号问题是我发现AI处理目标文件名已经存在的思路是直接报错终止。这在一次性清理场景下勉强能用但如果同一批文件里有多个IMG_1234.jpg存在比如来自不同子目录就直接卡死了。这时候你需要告诉AI无缝衔接的覆盖行为是否允许AI的反应几乎是立刻的马上改成了自动追加后缀的模式并增加了一个--dry-run参数让朋友可以先看一遍将要执行的操作清单再决定是否真正执行。这个参数我觉得特别值得划重点。--dry-run看起来只是加了一个只显示不执行的开关但对真实使用体验的改善是巨大的——它在人和机器之间加了一道确认缓冲。任何批量破坏性操作重命名、删除、覆盖都该默认带上这个参数这已经是我的习惯动作了。实际上到了这个阶段你也能感觉到了AI的钱也就是省心省在了搭骨架你的时间花在了别人看不到的边界条件、验收测试和异常处理上。但这就是正常的工程步骤绝不能省。5. 踩坑记录AI写代码最大的问题不是代码本身5.1 上下文污染对话一长它就开始自己发明历史AI写代码不是没问题。相反问题不少而且这些问题不遇到一次你很难真正理解它的边界。最让我头疼的是上下文污染。具体来说就是当你和AI连续对话超过一定轮数之后它开始把之前的回答当成既成事实引用。比如我在处理图片重命名时第二轮我曾口头提到可能要考虑Windows文件系统大小写不敏感的问题但当时我没有正式确认要去处理。到了第四轮AI居然主动在代码里加了一段专门判断大小写冲突的逻辑并注释说根据前面讨论需要处理该边界。而当我在回复里纠正不需要这个逻辑时它竟然回复好的但我建议保留因为在Windows环境下确实存在这个风险部分表现得很像是在试图说服我而不是执行指令。这就是典型的上下文污染信息在被模型理解后沉淀为预期一旦对话长了它会把你说过的话、它自己的解释、甚至它自行脑补的内容混杂在一起。这时候唯一的保命手法是——开新对话把需求重新完整描述一遍。别恋战。恋战的代价是你得花成倍的精力把它的记忆擦干净。5.2 幻觉式API调用一本正经地编造不存在的接口第二个坑比上下文污染更隐蔽也更致命——幻觉式API调用。我在另外一个项目中让AI写一个调用某云服务SDK的代码片段它给我写了一段看起来逻辑完美的代码直到运行时才发现那个API方法名根本不存在。我又回头翻了一遍这个SDK的官方文档确认这个接口早在三年前的版本中就被废弃了AI给出的调用方式、参数名和返回结构完全是它的训练语料里偏向于旧版本知识的产物。这个事给我教训很大。后来我养成了一套习惯涉及外部SDK、开源库、框架接口的代码AI写完之后一定要去官方文档或实际调用环境中验证而不是靠它看起来很对来判定可用。尤其在API版本更新比较频繁的领域比如云服务、前端工具链AI的这种一本正经地胡说八道是所有坑里最贵的。因为它表面上根本看不出问题来往往是测试环境或者生产环境报错了你回头查才发现是根目录上跑不通。5.3 代码回退困难与版本管理没有Git就别谈AI写代码还有一个实操层面的问题我估计很多人都会遇到AI写的代码确实帮你省了不少事但它改起代码来有时候也是大刀阔斧。你可能只是想让它加个缓存逻辑它顺手把整个函数的实现换了一种风格。等你看了一眼觉得还是原来那版舒服想让它恢复它却可能已经记不清原来的代码长什么样了。这里就凸显出本地代码版本管理的必要性。我自己的做法是每次让AI动代码之前先把当前项目状态提交到Git。AI给的每一版修改不管是否满意也都提交一次。这样万一哪一步改坏了直接回退到上一个commit就行完全不依赖AI的记忆。你没有版本控制裸奔着用AI写代码早晚有一天会被坑得很难看——因为AI写代码的迭代速度远比你手工时代快迭代快意味着变化的次数多变化次数多意味着出错和回溯的需求也急剧上升。5.4 安全审查密钥、依赖、权限一样都不能少最后一个坑可能平时个人写脚本碰不到但一旦把AI写的代码放到生产环境它就是底线问题——安全。我见过有人让AI写一个处理数据库的脚本AI非常贴心地自动生成了一个连接字符串里面硬编码了数据库密码。可能AI只是觉得这样方便演示但如果你没留意直接复制到生产环境这密码就变成了明文资产。还有一次让AI生成一段从网页抓取信息的代码它顺利地用了一个第三方解析库并且pip install也就这么用了——但仔细一查该库有一段已知的依赖漏洞版本号虽然不是最新的问题就在于AI并不会主动去查安全公告它使用的是训练语料里比较常见、比较稳妥的版本号组合。所以我现在对AI写的代码必然有一套安全审查流程检查有没有硬编码的密钥和密码检查依赖库版本有没有已知安全问题检查文件读写和网络请求的权限控制是否合理。这一套流程做下来才能真正谈得上用AI写的代码上线。6. 我现在的AI写代码工作流与边界认知6.1 什么任务放心交给AI什么任务我绝对不交经过这段尝试我现在对AI写代码这件事形成了一个相对清晰的工作流认知按任务的复杂度和风险性做了一个简单分类。低风险、模板化的任务比如数据清洗脚本、文件批处理、正则表达式编写、一次性爬虫采集、格式转换、自动化测试用例的初始化这些可以大胆交给AI。它们的目标明确、边界清晰、出错了影响面可控AI完全能在几分钟内交付可用版本。复杂但可拆分的任务比如一个带数据库的小型Web服务、一个消息队列的消费者、一个带身份验证的API接口这类任务我的做法是让AI负责架构设计和骨架搭建剩下的业务逻辑细节我亲自补。我给出约束和验收标准让AI先出第一版全貌我再逐块审查、逐块修订。大概有七成时间AI出的代码质量达到了我要的框架水平另外三成时间它会漏掉一些关键设计点需要我补课。高风险、强业务耦合的任务比如涉及金额计算逻辑、用户隐私数据处理、核心交易链路这类任务我不会让AI独立完成哪怕一行的核心逻辑最多让它生成一些辅助工具类、Mock数据、单元测试脚手架。原因前面说了AI的这些短板幻觉、上下文污染、边界意识弱在核心业务里一旦被触发代价不是几行代码而是线上事故。6.2 个人开发者怎么用AI放大产出我的节奏建议如果你是一个像我一样的个人开发者或小团队技术负责人我给你的节奏建议是按照三轮互动两次审查来走这是我踩坑之后沉淀出来的标准动作。第一轮是需求建模。清晰描述目标、输入、输出、约束和验收标准让AI先给设计方案而非直接写代码。这一轮的价值在迫使你自己先想清楚需求。第二轮是骨架搭建。确认AI给出的技术方案没有跑偏之后让它生成主体代码框架——类结构、函数签名、数据流、接口定义。第三轮是边界补齐。这时候你要特别强调异常处理、边界条件、性能瓶颈并让AI针对这些点逐一回答你准备了什么方案。然后两次审查。第一次是我上面说的代码级审查逻辑对不对、依赖有没有问题、有没有硬编码密钥、样式是否达标。第二次是系统级审查跑起来看行为是否符合预期、性能是否达标、日志是否清晰。这套动作做下来我用AI干活的质量已经接近我之前纯手工写的标准但速度大约是原来的三到四倍。6.3 尝试1这个标题的言外之意一切才刚刚开始最后说回这篇帖子的标题——AI写代码尝试1。既然编号是1说明这只是个开始。这段时间的尝试让我最大的体会是AI写代码这个事会的人已经悄悄用它把生产效率拉高了一个身位没试的人还在争论AI是不是取代程序员。但事实比争论更有说服力——AI不取代谁它只是让一个知道怎么写代码的人变得更快、更强、更专注于真正需要人判断的那部分。下一篇文章我想聊聊我后来用Agent类工具尝试改造一个小型微服务的过程——那个过程里AI全自动改代码的表现更惊艳但也更吓人。如果你也在这个方向上有自己的经验欢迎在评论区一起聊聊你的尝试。