1. 动手前的准备选定一个值得交给AI的任务先说个背景。我在2024年底开始认真尝试AI写代码之前对这类工具的认知一直停留在“高级补全插件”的层面总觉得生成的东西跑不起来最后还得自己重写。直到我被一个时间紧、重复度高、又不太需要架构设计的小任务逼到墙角才真正把一个完整功能从需求到落地全部交给了AI。很多人第一次试AI写代码容易犯一个方向性错误拿一个自己正在开发的核心业务模块去试水。结果AI生成一坨看似合理、实际全是坑的代码然后大家得出结论“AI不行”。我的建议反过来了第一次尝试AI写代码一定要选一个具备三个特征的任务第一逻辑边界清晰输入输出明确第二不涉及太多历史包袱和复杂依赖第三即使AI翻车你也能在两小时内手工兜底。我选择的任务是“批量日志分析脚本”。当时手头有一批Nginx访问日志需要统计不同接口的QPS、P95响应时间、状态码分布还要过滤掉特定爬虫的流量。这个任务用Python来写大概需要200行左右逻辑不复杂但是文件多、格式跳、字段缺失各种小问题缠着手工写耗时不说还容易在边界条件上挂掉。选定任务之后下一步才是工具选型。这一步比很多人想象的重要因为不同模型在写代码上的差异真的比跑分差距看起来还要大。我当时主测了三类模型通用大模型、专用编程模型、以及集成在IDE里的AI助手。通用大模型在写长文件、多文件协作时经常出现“前半段记住了、后半段跑偏”的问题专用编程模型在生成短函数、算法片段、日常脚本上非常稳IDE内置助手则强在实时补全和零切换成本但弱在生成整段完整逻辑时缺乏大局观。我最后选择了“专用模型生成 通用大模型做设计评审 IDE助手做局部补全”的组合方案。这里必须多说一句别迷信模型榜单。代码生成能力和自然语言理解能力是两个维度有些对话表现很好的模型在代码生成上的语法正确率可能很一般。我的判断标准很简单给它一段包含明显边界条件的任务描述比如文件编码不一致、日期跨月、字段可能缺失看它生成代码里有没有对应的防御性逻辑。如果它只顾主流程不管异常分支那这个模型在当前版本就不适合干生产级别的活儿。1.1 为什么拿“日志分析脚本”作为第一次试验日志分析脚本是个特别理想的AI写代码测试场景。首先它属于典型的“脏活累活”任务几乎所有开发者都不爱写但每周都可能遇到。其次这类脚本的成败标准极其简单跑起来、出统计结果、结果可验证不需要讨论设计模式不需要考虑后期演进非常适合用来检验AI代码生成的实际质量。我那条需求大概是这样的每天凌晨会产生一批access.log命名格式是access_20241201.log不同服务器的日志格式略有差异有的多了个$upstream_response_time字段有的没有希望统计出每个URL路径的每分钟请求量、P95响应时间、5xx错误次数还要识别并排除常见的爬虫UA前缀。输出格式用CSV按请求量倒序排列。我把这段需求原样扔给AI第一次生成的结果只能说“框架是对的”。它用了pandas做数据分组统计思路清爽但是完全没有处理两个关键细节一是Nginx日志里响应时间为空的情况二是不同机器字段顺序不一致导致的列错位。这两个问题直接导致脚本在真实数据上跑崩。这说明AI确实能理解任务主流程但对真实世界的嘈杂程度估计不足而这恰恰是工程经验所在。所以我不打算拿第一次生成的结果直接用而是把它当“初稿”通过后续对话不断修正。这个经验很重要让AI写代码的正确姿势是“多轮迭代”不是“一次生成”。第一轮的目标是拿到一个结构合理、主逻辑正确的骨架然后通过喂真实数据和错误信息一次一次把边界条件补全。1.2 工具选型实测多模型对比与选择逻辑工具选型上我把当时主流的几个渠道都实测了一遍。IDE插件类以GitHub Copilot和同类国产插件为代表优势是补全速度快、上下文感知窗口就摆在眼前劣势是生成大段代码时容易自作主张在你不注意的地方悄悄改掉变量命名风格。程序员如果没养成逐行审阅的习惯很容易被带沟里。独立对话类模型包括Codex系列和几个国内大模型在“面对面聊需求”这种模式下表现更好。你可以把需求完整描述一遍然后追加限制条件AI会输出一整段可运行文件。这类模型的问题在于一旦生成的代码超过300行它们开始出现“遗忘前面定义过的函数”的现象比如前面明明定义了一个parse_line()函数后面调用时会突然写成一个新的名字。这是上下文窗口和注意力机制的物理限制短期内很难根除。还有一个容易被忽略的工具是各种开源模型在本地部署的方案。如果你有私密代码不想外传本地跑一个7B甚至13B模型是完全可行的。实测下来本地模型在代码生成能力上和云端模型有一定差距但在补全、注释生成、简单重构上已经够用。考虑到零数据外泄这个优势对于公司内部项目来说它比云端工具更稳妥。我的选择逻辑可以总结为三条涉及敏感业务逻辑的用本地模型需要长文件、多文件协作的用云端专用编程模型日常小步快跑式开发的用IDE补全插件。三者组合使用而不是单押某一个。2. 从需求到提示词让AI听懂“人话”的工程化方法很多人问“为什么我让AI写代码它老是写不明白”这跟提示词质量有直接关系。我见过一个同事让AI写爬虫需求是“写一个爬虫抓取商品价格”结果AI生成了一段BeautifulSoup写死的页面结构解析代码换个网站就崩。原因很简单需求描述里没有告诉AI目标网站的结构特征、登录态要求、反爬策略、数据存储格式AI只能按最理想的情况猜。提示词工程本质上是个“翻译”工作把人类脑中隐含的需求翻译成AI能理解的形式化需求。好的代码类提示词至少应该包含五个要素输入数据的格式和来源、输出的格式和去向、需要处理的核心逻辑、必须覆盖的边界条件、禁止出现的行为。我把这五要素称为“代码提示词五件套”缺一个都可能让生成结果跑偏。举个例子。同样让AI写日志分析脚本一个菜鸟提示词是“统计日志中的请求量和响应时间”一个合格提示词是“读取目录下所有access_*.log文件这些文件是Nginx默认格式每行一个请求字段顺序为ip、时间、方法、URL、状态码、响应时间其中响应时间可能为空需要跳过空值输出CSV包含三列URL、每分钟请求量、P95响应时间按请求量倒序”。这两段话的信息密度完全不在一个量级。AI拿到第一段大概率生成一个只处理单文件、不处理空值、不区分URL的简单脚本拿到第二段它至少知道要做文件遍历、空值处理、按URL分组、输出特定CSV。所以有时候不是AI弱是需求没说透。2.1 任务拆解才是真正的提示词工程提示词工程的核心不是“把话说漂亮”而是“把任务拆解清楚”。我自己在实践中总结了一个拆解流程先让AI自己复述一遍它对这个任务的理解再用提问的方式引导它列出实现方案最后再让它把这些方案细化成步骤每一步对应一个可验证的里程碑。比如我在写“批量日志分析脚本”之前先问AI“你觉得这个脚本应该分成哪几个模块”它回答文件读取、日志行解析、统计聚合、结果输出。然后我再追问每个模块的输入输出是什么、可能遇到什么问题。这个过程看似多花了几分钟实际上能提前暴露掉一大堆坑比如它认为日志行用split()按空格切分就行但真实Nginx日志里的URL可能包含空格编码直接按空格切会错位。如果不提前拆解等到运行报错再排查浪费时间更多。拆解还有个额外好处让AI生成代码的过程可控。如果你让AI一口气输出500行代码它大概率在某个位置上突然风格突变或者出现未定义变量。但如果你让它按模块一个一个来每个模块单独生成、单独测试跑通一个再接下一个代码质量会明显上升。这种工作方式也直接影响最终的代码质量。我自己实测下来按模块拆解生成的多文件结构比一次性生成的单文件大杂烩更容易维护出了问题也更方便定位。后来我把这套方法用在不同项目上效果都很稳定。2.2 我用过的三套提示词模板及适用场景第一套叫“精确锁定模板”适合生成一个具体的函数或类方法。格式是函数名 输入参数类型和格式 输出类型和格式 边界条件列表。比如“写一个Python函数parse_log_line(line: str) - dict输入是Nginx访问日志的一行输出包含ip、time、method、url、status、response_time六个字段的字典注意URL可能包含空格响应时间可能为空返回None表示解析失败”。这种模板生成的代码通常可以直接用。第二套叫“方案咨询模板”适合在动手写代码之前让AI帮你梳理技术路径。格式是场景描述 约束条件 问题开放度。我会这样写“我需要写一个工具每月处理约10GB的Nginx日志机器内存只有8GB不能用pandas因为加载整个文件会内存溢出。请推荐一种处理方案并说明每种方案的优缺点。”这个场景下AI会给出流式处理、多线程分块、数据库导入等多种方案你从中选一个最合适的再继续深入。实测下来这种先问方案再写代码的方式能避开“AI默认方案和你运行环境不匹配”这个最大的坑。第三套叫“代码评审模板”适合对已有代码做质量检查。格式是代码 预期行为 你担心的点。比如我把AI生成的代码粘进去然后写“这段代码要在低配服务器上每天跑一次我担心正则回溯导致卡死请帮我找出潜在的性能问题和极端输入下可能出现的异常”。AI会静下心来审一遍代码找出问题并给出修改建议。这个用法很多人不知道但非常好用相当于让AI给你做免费的Code Review。2.3 上下文管理如何让AI记住前面的要求AI写代码的一大痛点是“聊长了就忘”。你半小时前让它“所有输出时间字段统一用UTC”它可能在生成第三个模块时又用回了本地时间。这个问题的根源在于上下文窗口被无关内容占满了。所以上下文管理是AI写代码的隐形基本功。我的操作习惯是这样的。第一系统提示词里把最重要的约束放在最前面比如“全局规则所有时间戳使用UTC、错误处理统一用日志记录、禁止使用第三方公共库以外的依赖”。这条规则放在对话的最顶部AI在后续生成中会更大概率遵守。第二等到围绕这个话题聊了超过三轮就开一个新对话把前面的关键结论整理成一段摘要贴在开头而不是继续在旧对话里追加。旧对话的上下文窗口会被大量冗余内容占据比如你贴给它看的报错信息、中间产物这些都会稀释它对核心需求的注意力。第三也是最实用的一招让AI自己维护一个“需求清单”。在任务开始时让它先输出一份结构化需求描述然后在之后每一轮对话里你提醒它“对照这个需求清单检查你的生成结果”。这相当于强制AI在心里做一次自查。实践下来这个方法能显著降低“需求漂移”类问题的发生频率。3. 完整跑一遍从AI出码到本地运行的实操记录理论聊够了来一次完整的实操记录。这里我以一个“自动化报表生成脚本”为例展示从提出需求到代码落地的完整流程这个例子是我后来做的比日志分析更贴近日常工作场景。需求是这样的每天从公司内部数据库导出前一天的订单数据按城市汇总订单量和销售额生成一张Excel报表自动发送到指定邮箱。数据库是MySQL表结构已知城市字段可能为空导出时间为每天的9点整。这个任务的特点是业务逻辑清晰、步骤多、涉及多系统协作非常适合跑一遍完整流程。我把需求描述完之后没有急着让AI写代码而是先让它输出一个开发计划。AI给出的方案分成了四步第一步连接数据库并查询昨天的订单记录第二步按城市维度和日期维度做聚合城市为空时标记为“未知区域”第三步生成Excel并设置列宽、行高、表头样式第四步通过SMTP发送邮件。这个计划符合我的预期我只补充了一点加一个异常处理机制比如数据库连接失败时要能自动重试邮件发送失败时要保留本地文件作为备份。顺着这个计划我依次让AI生成每个模块的代码。每个模块生成后我立即在本地跑一个最小可用测试确认没问题再进下一个模块。下面把这个过程的关键细节展开。3.1 第一次生成先要能跑再谈优化生成第一个模块“数据库查询”时AI交回的代码用了pymysql和pandas整体结构是对的。但有一个细节引起了我的注意它没有使用参数化查询而是直接用字符串拼接SQL这是一个典型的安全隐患。我在对话中指出这个问题要求它改为参数化查询它立刻修正了。这里有个重要心得AI生成的第一版代码大概率是“能跑但不够好”的水平。它倾向于选择最常用的库和最直白的写法这些写法在安全性和性能上未必最优。所以第一次生成后我从不直接进入下一个模块而是先把代码读一遍重点盯三件事一是所有外部输入有没有走参数化或转义二是文件操作有没有正确的关闭逻辑三是全局变量和函数参命名是否一致。这三件事如果第一版都没问题再考虑下一步。数据库模块跑通之后我进入第二个模块“数据聚合”。AI生成的代码按城市和日期做groupby逻辑没问题但没想到一个业务细节订单表里存在“测试订单”这类数据应该被过滤掉。于是我在这个模块的提示词里专门加了一条“过滤掉order_typetest的数据”。如果没有这个补充报表里就会混入测试数据最终发给领导的报表就会成为事故。从这两段经验可以总结出AI写代码的第一原则就是“小步快跑拿到能跑的版本再逐步加固”。不要指望一次生成就符合所有生产要求尤其不要在前端加载一个网页应用这种场景下用“一次性生成全部代码”的玩法去试。我第一次尝试AI写代码时就是栽在这个坑里一个全栈项目让AI一口气生成结果跑起来全是问题。3.2 依赖安装与运行调试AI不背锅的环节代码生成只是第一步真正考验人的是让它跑起来。我遇到过不少朋友说“AI生成的代码根本没法运行”但仔细一看大部分问题出在环境依赖上而不是代码本身。AI生成的代码假定你有一个“干净的、装了全部所需依赖的”环境这在现实中很少存在。我的建议是让AI写完代码后额外问它一句“这段代码需要哪些依赖请给出requirements.txt内容。”大多数情况下AI能给出准确的清单。接着在本地虚拟环境里安装依赖时务必用指定版本而不是最新版因为AI生成代码时参考的语法版本可能是固定的装一个不兼容的升级版库很容易让代码报错。我在跑邮件模块时就遇到过AI生成的代码用了smtplib这个库没版本问题但它调用了email模块里的一个方法在Python 3.10和3.12之间的行为有差异导致服务器拒绝认证。后来我固定Python版本到3.10问题就消失了。还有一个小技巧跑AI生成的代码前先做一次“静态检查”——用py_compile编译一下或者用IDE打开看有没有红色波浪线。这个操作能在真正运行前拦截掉大部分低级语法错误。我见过有人让AI写了个JavaScript脚本贴到项目里直接运行报了个语法错误然后花了一小时找原因其实只要在浏览器控制台看一眼就能定位。工欲善其事必先利其器基础校验不能省。运行调试过程中最常见的报错类型包括文件路径不对、数据库字符集不支持中文、时间时区对不上买卖双方、第三方库版本不匹配。这些报错都不是AI可以预判的全看你本地环境的具体情况。所以不要一报错就骂AI先看堆栈信息再判断是环境问题还是逻辑问题。环境问题自己解决逻辑问题丢回给AI继续改这才是高效的分工方式。3.3 代码集成与版本管理AI写的代码也要入仓评审等所有模块都单测通过下一步就是集成。集成阶段最容易出现的坑是“模块接口不一致”。AI分模块生成的代码如果每个模块都是独立对话生成的可能会出现数据库连接的变量名在一个模块里叫conn、另一个模块里叫db_connection这样的情况。所以我强烈建议在一个对话里顺着往下生成所有模块这样至少上下文是连续的变量命名风格能保持一致。集成完成后把完整的脚本跑一遍输出结果先不要急着发邮件而是另存为文件人工抽几条数据核对一下。这一步我在第一次试验时跳过过一次结果发现聚合结果和数据库直接查询差了一个数量级原因是订单表里存在已取消订单我不要求统计但AI没有过滤。从那以后无论任务多紧急我都保留“核对输出”这个步骤它可以拦截掉大量逻辑层面的错误。代码最终落地前务必走一遍版本管理流程。即使AI生成的代码也应该放进Git仓库、写README、加注释。很多人觉得AI生成的代码是“一次性消耗品”不用管版本。这是一个巨大的误区。AI生成的代码一样会面临维护下次项目说出就出问题没有版本记录你连上一次跑通的版本都找不到。我在最终提交前会让AI基于这段代码再生成一个README文档说明运行环境、依赖清单、输入输出格式和常见问题。别小看这个步骤它能帮你省下一个月后再回来看代码时的认知成本。README生成完我还会让AI给自己代码加注释重点标注两个位置容易出错的边界逻辑和未来可能需要修改的地方。4. 踩坑实录与排错技巧AI写代码的常见翻车现场跑了几十个AI写代码的实际任务之后我慢慢能预判AI会在哪些地方犯错了。这些坑不是个例而是AI代码生成能力当前水平的真实映射。整理出来分享给大家能帮你少走很多弯路。第一个大坑是“AI幻觉代码”。什么叫幻觉就是代码看起来非常合理、变量名都对、注释也有但实际运行时就是报错或者结果不对。我遇到过最经典的场景是让AI写一个正则表达式提取URL中的查询参数它生成了一段在极少数情况下会漏掉参数的正则。这段代码在测试样例上全过但放到真实日志里就出问题。后来我发现AI对正则这种“边界隐形”的东西特别容易翻车因为正则语言的“正确性”很难通过直觉判断AI在生成正则时倾向于用最典型的写法而不是考虑全部边缘情况。排查这类问题没有捷径只有两条路一是多准备真实数据做验证把漏掉的边界情况暴露出来二是让AI自己解释这段正则的匹配逻辑通过解释发现它的设计盲区。我一般两种都做先把真实数据跑一遍再把AI解释贴过来人肉核对。4.1 上下文漂移聊着聊着AI就忘了原始需求第二个大坑是“上下文漂移”。你和AI聊了十几轮开始时设定的“过滤测试订单”“时间戳用UTC”“不要使用第三方库”等约束到了第15轮AI生成的新代码很可能不再遵守。这个问题的根源是我在前面提到的上下文窗口限制但表现形式更隐蔽——它不是整段代码违反约束而是在某个小地方悄悄越界。比如我做过一个任务要求AI禁止使用print输出调试信息统一走logging。前五轮它做得很好到了第六轮它在函数里加了一个print(“debug: x”, x)。如果不仔细看很容易漏掉。后来我给自己定了个规矩每次让AI生成新模块之前都把全局约束重新贴一遍不嫌麻烦。这个方法虽然老土但在当前AI能力阶段下是最可靠的防漂移手段。另一个处理漂移的方法是“分段校验”。当AI生成一个较长文件时我从不在最后才整体读一遍而是每生成一个函数就确认一次是否严格遵守全局约束。把这个过程当成“代码评审”来做发现问题当时就让AI改正而不是攒到最后一起看。攒到最后一起检查的结果往往是好几处漂移同时出现定位问题成本陡增。4.2 风格不一致与代码审查的边界第三个大坑是代码风格不统一。AI生成代码时经常在一个文件里混用单引号双引号、混用换行缩进宽度、混用函数命名风格。这些在Python这类对格式有要求的语言里虽然不影响运行但对后续维护是灾难。解决这个问题最简单的方法是直接让AI“模仿指定的编码风格”。我会在系统提示词里贴上项目的.editorconfig或者PEP8规范然后再补一句“所有代码必须遵守这个风格”。实测下来大部分AI都能做到偶尔一两个变量名不统一跑一遍格式检查工具就能发现。不过需要划一条清晰的边界AI可以做代码评审但不能完全替代人工评审。AI评审擅长发现逻辑漏洞、边界条件遗漏、性能隐患但在业务正确性、隐含规则、团队开发约定上不具备判断力。让AI审代码可以把它定位成“找明显的、技术性的问题”而业务正确性必须人工把关。之前有一个项目AI生成的代码逻辑完全正确但算出来的指标定义和运营团队的要求不一致这种偏离只有懂业务的人才能发现。4.3 异常处理缺失跑几个小时后才暴露的隐患第四个坑也是我踩得最惨的一个异常处理缺失。AI生成的代码默认假设输入都是“标准输入”但现实中的输入永远混杂着意外情况日志的行尾有空格、Excel的某个单元格是公式而不是值、数据库偶尔返回可能为null的字段。AI常常不会主动处理这些因为它的训练数据里代码示例的输入都是干净数据。我的解决方案是在提示词里明确加上一条“请确保所有外部输入都作防御性校验任何单个文件解析失败都不能中断整体运行要跳过并记录错误。”这个提示词一加AI生成的代码会明显多出很多try/except分支。尤其是长时间运行的任务比如每小时跑一次的数据同步脚本如果没有合理的异常捕获一个小报错就可能让整个任务链断掉而且排查时才发现中间夹着一个被吞掉的错误。说到底AI写代码是一项需要持续迭代和人工边界控制的工程活动。它在短平快任务上已经能稳定交付但在长期维护、深度业务耦合、高并发环境下还远达不到独立生产的水平。把AI定位成“一个代码能力很强但没有业务常识的队友”可能是目前最理性的看法。每次生成后不自作聪明、不盲目信任、不跳过审查最后得到的结果反而能比手写还稳定。这也是我在这段时间里最大的体会。