1. 从“AI写代码尝试1”说起我为什么要认真做这件事“AI写代码尝试1”这个标题看起来像随手记的一个实验编号但我第一次看到它的时候脑子里冒出来的是一连串很具体的问题AI到底能写多少代码写出来的代码能不能直接跑哪些环节它靠谱哪些环节它一定会翻车我是不是可以把日常开发里那些重复、琐碎、但又不得不做的编码任务逐步交给它带着这些问题我花了相当一段时间做了一轮系统性的尝试。这篇文章就是这轮尝试的完整记录包括我用的方法、踩过的坑、总结出来的提示词套路以及一个最关键的结论AI写代码不是“能不能用”的问题而是“在哪些环节用、怎么用、用完怎么验”的问题。如果你是一个正在观望AI编程的开发者或者已经用过但觉得“也就那样”的人这篇内容应该能给你一些不一样的角度。先说清楚这篇文章适合谁看。第一类是有一定编程基础、想借助AI提升效率的开发者比如后端、前端、数据方向的同学第二类是想了解AI编程真实能力边界的技术管理者你需要知道团队里引入AI辅助之后质量把控的重点应该放在哪里第三类是对AI Agent、多AI协作这些概念感兴趣但还没动手试过的人。我会尽量把每个环节讲透让不同基础的人都能拿走能直接用的东西。我这次尝试的核心目标有三个一是验证AI在从零生成代码场景下的真实水平二是摸索一套可复现的提示词模板让输出质量稳定三是搞清楚AI写出来的代码该怎么验收毕竟代码不是写完就完事能跑、能维护、不出安全问题才算数。这三个目标贯穿了整轮尝试也是后面各个章节的主线。2. 整体思路与方案选型为什么这样设计尝试流程2.1 把“AI写代码”拆成可验证的小任务一上来就让AI写一个完整项目是最容易失望的做法。我试过结果就是它给你一堆看起来像模像样、但拼在一起跑不起来的代码。所以这次我换了个思路把编程任务按粒度拆开从最小的函数级任务开始逐步往上加复杂度。具体拆成了这么几层单函数生成比如“写一个快速排序”“写一个XGBoost的训练脚本”验证基础代码能力。模块级生成比如“写一个带重试机制的HTTP请求封装”验证它对工程结构的理解。跨文件协作比如“给我一个Flask项目包含路由、模型、配置三个文件”验证它能不能维持上下文一致性。调试与修复给它一段有bug的代码看它能不能定位并修好。Agent式任务让它自己规划步骤、调用工具、分多轮完成一个稍大的任务。这样拆的好处是每一层的能力边界都能单独观察不会因为一个环节崩了导致整轮尝试没法评估。而且这种拆法本身就贴近真实开发——我们平时写代码也是从函数到模块再到系统一层层搭起来的。2.2 工具选型为什么我没有只用一个AI这次尝试里我用了不止一个AI编程工具原因很简单不同工具在不同任务上的表现差异很大只用一个会误判整体能力。我主要用了三类第一类是对话式AI编程助手就是那种你在聊天框里描述需求、它给你代码的形式。这类工具适合做探索性任务比如“我不确定这个算法怎么写先让它给个思路”。它的优势是交互灵活可以反复追问劣势是上下文容易丢长任务容易跑偏。第二类是IDE内嵌的代码补全工具就是写代码时自动提示下一行那种。这类工具适合做重复性编码比如写CRUD、写测试用例、补全样板代码。它的优势是融入工作流、不打断思路劣势是它只补全局部不理解整体架构。第三类是Agent型工具能自己读文件、跑命令、改代码、再验证。这类工具适合做“帮我修个bug”“帮我加个功能”这种需要多步操作的任务。它的优势是自动化程度高劣势是容易在复杂任务里迷失方向需要人盯着。我实测下来的感受是没有哪个工具能通吃关键是按任务类型选工具。写算法用对话式写业务代码用IDE补全做重构和调试用Agent。这个组合策略后面会反复提到。2.3 提示词设计决定输出质量的关键变量同样一个需求提示词写得好和写得差AI给出的代码质量能差出一个数量级。我这次专门花时间打磨了提示词模板核心原则有这么几条第一明确输入输出。不要只说“写个排序函数”要说“写一个Python函数输入是一个整数列表输出是升序排列的新列表不要修改原列表要求时间复杂度O(n log n)”。输入输出越明确AI越不容易自由发挥。第二给出约束条件。比如“不要用第三方库”“要处理空列表”“要加类型注解”“要写docstring”。这些约束会显著提升代码的可用性。第三要求它解释思路。我习惯在提示词最后加一句“先用三句话说明你的实现思路再给代码”。这一步很关键因为如果思路就是错的代码写得再漂亮也没用而且你能从思路里看出它有没有理解你的需求。第四要求它给测试用例。加一句“给这段代码配三个测试用例覆盖正常情况和边界情况”。这样你拿到代码的同时就拿到了验证手段。这套模板我后面会给出完整版本你可以直接抄。3. 核心细节解析AI写代码到底强在哪、弱在哪3.1 它真正擅长的模式化、有大量先例的代码AI写代码最强的地方是那些有大量公开先例、结构高度模式化的任务。我实测下来以下几类任务它完成得相当好算法实现快速排序、二分查找、动态规划这类经典算法它写得又快又对。我让它写快速排序它给的版本带随机化pivot、处理了空数组和单元素数组还附了测试用例基本可以直接用。数据处理脚本比如用pandas做数据清洗、用XGBoost做训练和预测这类代码网上范例极多它写出来结构清晰、参数合理。样板代码Flask路由、Django模型、React组件、单元测试框架这些有固定套路的代码它生成得又快又规范。代码解释给它一段陌生代码让它解释每行在干什么它做得比大部分文档都好。我印象比较深的一次是让它写一个LSTM的时间序列预测脚本。它给的代码包含了数据归一化、序列切分、模型定义、训练循环、预测反归一化整个流程完整我只改了几个路径就能跑。这种任务如果我自己写至少半小时它几秒钟就给了初稿。3.2 它容易翻车的地方上下文、边界、依赖但AI写代码的短板也很明显而且这些短板往往在“看起来没问题”的代码里埋着雷。我总结了几类高频翻车场景第一类是上下文丢失。当你让它写一个跨多文件的模块时它经常写着写着就忘了前面定义的接口。比如你让它写一个类前面说好了方法A返回一个字典后面调用的时候它可能当成列表用。这种问题在长对话里尤其明显。第二类是边界条件处理不全。它写的代码通常能处理“正常情况”但对空输入、超大输入、非法输入的处理经常缺失。我让它写一个解析用户输入的代码它没处理输入为None的情况也没处理格式错误的情况直接就会抛异常。第三类是依赖和版本问题。它给的代码可能用了某个库的旧版API或者用了一个你环境里根本没装的库。比如它写XGBoost代码时用了某个已经废弃的参数名跑起来直接报错。还有一次它给的代码里有个函数在某个版本之后改了签名我排查了半天才发现是版本问题。第四类是“看起来对但逻辑错”。这是最危险的。代码能跑不报错但结果不对。比如它写的一个分页逻辑边界算错了导致最后一页数据重复。这种问题如果不写测试很难发现。3.3 一个关键认知AI是“高级代码补全”不是“程序员替代品”这轮尝试下来我最大的认知转变是不要指望AI理解你的业务。它不知道你的系统架构、不知道你的数据特点、不知道你的性能要求、不知道你的团队规范。它只能基于你给的信息和它见过的模式生成“大概率合理”的代码。所以正确的定位是AI是一个极其高效的代码草稿生成器但最终的判断、验证、集成必须由人来做。它帮你把“从0到0.7”的部分做了剩下的“0.7到1”才是你的价值所在。想清楚这一点你对它的预期就对了用起来也不会失望。4. 实操过程一次完整的AI写代码流程记录4.1 任务设定写一个带重试和超时的HTTP请求封装我选了一个不大不小、但足够有代表性的任务写一个Python的HTTP请求封装函数要求支持重试、超时、错误处理并且要有测试用例。这个任务的好处是它既不是纯算法太简单也不是完整项目太复杂刚好能体现AI在工程代码上的真实水平。我用的提示词是这样的请用Python写一个HTTP请求封装函数要求 1. 函数名 request_with_retry输入参数url、method、timeout、max_retries、retry_delay 2. 使用 requests 库 3. 支持GET和POSTPOST时接受json参数 4. 超时默认10秒重试默认3次重试间隔默认1秒 5. 重试只针对网络错误和5xx错误4xx不重试 6. 每次重试前打印日志 7. 加类型注解和docstring 8. 先用三句话说明实现思路再给代码 9. 给三个测试用例覆盖正常、超时、4xx错误4.2 第一轮输出结构不错但有坑AI给的代码整体结构是对的用了requests的Session、用了for循环做重试、区分了异常类型。但我一眼就看出了几个问题第一个问题是重试间隔没有做退避。它用的是固定1秒间隔但实际生产里更合理的是指数退避比如1秒、2秒、4秒。这个不算错但不够好。第二个问题是日志打印没有区分级别。它用的是print而不是logging。在真实项目里print是会被嫌弃的。第三个问题是4xx的判断逻辑有漏洞。它写的是if response.status_code 400 and response.status_code 500: raise但这样会把429请求过多也当成不重试的错误而429其实应该重试。第四个问题是测试用例只覆盖了正常情况超时和4xx的测试它写得很敷衍基本没法直接用。4.3 第二轮迭代用追问把代码打磨到可用我没有直接接受第一轮结果而是针对每个问题追问。比如针对退避问题我说“把重试间隔改成指数退避第一次1秒之后翻倍但最大不超过8秒”。针对日志问题我说“把print换成logging用warning级别打印重试信息”。针对429问题我说“429应该重试请修正判断逻辑”。这样一轮轮追问下来代码质量明显提升。最终版本我贴一部分关键逻辑import time import logging import requests from typing import Optional, Dict, Any logger logging.getLogger(__name__) def request_with_retry( url: str, method: str GET, timeout: int 10, max_retries: int 3, retry_delay: float 1.0, json_data: Optional[Dict[str, Any]] None, ) - requests.Response: 带重试和超时的HTTP请求封装。 session requests.Session() last_exception None for attempt in range(max_retries 1): try: response session.request( methodmethod, urlurl, timeouttimeout, jsonjson_data, ) # 4xx 不重试但 429 除外 if 400 response.status_code 500 and response.status_code ! 429: return response if response.status_code 500 or response.status_code 429: raise requests.HTTPError(fServer error: {response.status_code}) return response except (requests.ConnectionError, requests.Timeout, requests.HTTPError) as e: last_exception e if attempt max_retries: delay min(retry_delay * (2 ** attempt), 8.0) logger.warning( Request failed (attempt %d/%d), retrying in %.1fs: %s, attempt 1, max_retries, delay, e, ) time.sleep(delay) raise last_exception这段代码我实测下来是能直接用的退避逻辑、日志、异常分类都到位了。但注意这是经过三轮追问之后的结果第一轮给的版本是不能直接用的。4.4 测试用例AI写测试的水平参差不齐测试用例这块AI的表现明显不如业务代码。它给的测试基本是“happy path”边界情况覆盖很少。我后来是自己补的测试用pytest加mock覆盖了超时、连接错误、5xx重试、4xx不重试、429重试这几个场景。这里有个经验让AI写测试不如让AI写“测试思路”然后你自己写测试代码。因为测试的核心是“你知道哪些地方容易错”这个判断AI做不好但你自己清楚。5. 提示词模板我反复打磨后留下的那套5.1 通用模板结构经过这轮尝试我沉淀了一套提示词模板基本结构是四段第一段角色和任务。比如“你是一个有十年经验的Python后端工程师请帮我实现以下功能”。第二段需求描述。用列表把功能点、输入输出、约束条件写清楚。这一段越细越好。第三段质量要求。比如“加类型注解”“加docstring”“处理边界情况”“不要用第三方库”。第四段输出格式。比如“先说明思路再给代码最后给测试用例”。这套结构看起来简单但实测下来比随手写的提示词输出质量高很多。核心原因是它把“模糊需求”变成了“明确规格”AI不用猜。5.2 几个提升输出质量的小技巧除了模板结构还有几个技巧是我试出来确实有用的技巧一给例子。如果你要的代码有特定风格直接给一段示例代码说“按这个风格写”。AI模仿能力很强给例子比描述风格有效得多。技巧二分步要。不要一次要太多。先要核心逻辑确认对了再要错误处理再要测试。一次要太多它容易顾此失彼。技巧三让它自我检查。在提示词最后加一句“写完后检查一遍指出这段代码可能存在的问题”。它经常能自己发现一些边界问题。技巧四用“不要”约束。比如“不要用eval”“不要吞异常”“不要用可变默认参数”。这些是AI容易犯的错提前说能避免。5.3 不同任务类型的提示词差异不同类型的任务提示词侧重点不一样。我整理了一个对照表任务类型提示词重点常见坑算法实现输入输出、复杂度要求、边界条件边界处理不全业务代码接口定义、依赖库、错误处理上下文丢失数据处理数据格式、缺失值处理、性能要求假设数据干净测试代码覆盖场景、mock方式、断言重点只测正常情况重构任务保持接口不变、目标结构、约束改坏原有逻辑这张表是我踩坑踩出来的你可以直接拿去用。6. 常见问题与排查技巧实录6.1 代码跑不起来怎么办这是最高频的问题。AI给的代码跑不起来原因通常有这么几类第一类是依赖缺失。它用了你没装的库或者用了某个库但没告诉你。排查方法是看报错信息里的ModuleNotFoundError然后pip install。但要注意版本有些库新旧版本API不兼容。第二类是API变更。它用的某个函数签名和你环境里的版本不一致。比如XGBoost的某些参数在不同版本里名字不一样。排查方法是查官方文档的版本变更记录。第三类是语法或逻辑错误。这个相对少见但偶尔会有。比如缩进错误、变量名拼错。这类问题一般看报错行号就能定位。我的建议是拿到AI代码后先在一个干净的环境里跑一遍别直接往项目里塞。跑通了再集成能省很多事。6.2 代码能跑但结果不对怎么办这类问题最隐蔽。代码不报错但输出不符合预期。排查思路是第一步确认输入。打印输入数据看是不是你预期的格式。很多时候是输入和AI假设的不一样。第二步分段验证。把代码拆成几段逐段打印中间结果看哪一段开始偏了。第三步对照逻辑。把AI的实现逻辑和你的预期逻辑逐行对照找出差异点。第四步写最小复现。用一个最小的输入复现问题然后针对这个最小案例调试。我遇到过一次AI写的分页逻辑在最后一页会重复数据。排查发现是它的边界计算用了而不是。这种问题不写测试根本发现不了。6.3 常见问题速查表问题现象可能原因排查方法解决方式ModuleNotFoundError依赖未安装看报错模块名pip install注意版本AttributeErrorAPI版本不匹配查库版本和文档降级或改用新API结果不符合预期逻辑或边界错误分段打印中间结果逐段对照修正长对话后代码跑偏上下文丢失检查前后接口一致性重新开对话给完整上下文性能很差算法或数据结构选择不当加计时看瓶颈换算法或加缓存测试跑不过测试假设和实现不一致看断言失败信息对齐测试和实现的预期6.4 几个我踩过的坑你可以直接避开坑一不要相信AI说的“这段代码没有问题”。它经常这么说但实际有问题。永远自己跑一遍。坑二不要在一次对话里塞太多任务。对话越长它越容易忘前面说的。一个任务一个对话或者定期重开。坑三不要让它改你没看过的代码。Agent型工具改代码之前先让它说明要改哪里、为什么改你确认了再让它动手。坑四不要忽略它给的“注意事项”。它有时候会在代码后面附一句“注意这段代码假设输入是UTF-8编码”这种话往往是关键别跳过。坑五版本锁定很重要。AI给的代码可能依赖特定版本把版本写进requirements.txt避免以后环境变了跑不起来。7. 多AI协作与Agent式编程的初步探索7.1 多AI协作让不同AI干不同的事这轮尝试里我还试了一个玩法用不同的AI做不同环节。比如让一个AI写代码让另一个AI做代码审查再让第三个AI写测试。实测下来这个模式确实能提升质量因为不同AI的“盲区”不一样互相能补。具体流程是AI-A生成代码我把代码贴给AI-B说“请审查这段代码指出潜在问题”AI-B经常能发现AI-A漏掉的边界问题。然后我把审查意见贴回AI-A让它修改。这个“生成-审查-修改”的循环比单AI反复追问效果更好。但要注意多AI协作的成本也高来回贴代码很费时间。适合用在关键代码上不适合所有任务。7.2 Agent式编程自动化程度高但需要盯着Agent型工具是这轮尝试里最让我惊喜也最让我头疼的。惊喜的是它真的能自己读文件、改代码、跑测试、看结果、再改整个闭环能跑通。头疼的是它在复杂任务里容易“迷路”比如改着改着改到了不相关的文件或者陷入死循环反复改同一个地方。我的经验是Agent适合做边界清晰的任务比如“把这个函数的错误处理补全”“把这个文件的类型注解加上”。任务越具体它表现越好。任务越模糊比如“优化这个项目”它越容易跑偏。用Agent的时候一定要设置检查点。比如让它改完一个文件就停下来给你看确认了再继续。别让它一口气改十个文件最后你都不知道它改了什么。7.3 关于“AI程序员”这个说法的冷静看法现在到处都在说“AI程序员”“AI替代开发”我这轮尝试下来的看法是AI确实在改变编程的方式但改变的是“怎么写”不是“写什么”。它让写代码这件事变快了但“决定写什么代码”“判断代码对不对”“把代码集成到系统里”这些事还是人的活。所以与其焦虑被替代不如把精力放在提升“定义问题”和“验证结果”的能力上。这两件事AI短期内做不好而恰恰是这两件事决定了你的价值。8. 一些实操心得和后续可以扩展的方向这轮“AI写代码尝试1”做下来我最大的收获不是某个具体技巧而是一套和AI协作的工作习惯。简单说就是需求写清楚、代码跑一遍、测试自己补、关键环节人工审。这套习惯建立起来之后AI带来的效率提升是实打实的我估算日常编码任务里大概有40%到60%的代码可以由AI生成初稿我只需要做修改和验证。如果要把这个尝试继续往下做我觉得有几个方向值得深入一是把提示词模板工程化做成团队共享的规范二是探索AI在代码审查环节的深度应用不只是找bug还包括找性能问题和安全隐患三是研究多AI协作的自动化流程减少人工来回贴代码的成本。最后分享一个我自己的小习惯我会把每次AI生成的、经过验证可用的代码片段存到一个“代码库”里标注好场景和注意事项。时间长了这个库就成了我自己的加速器——下次遇到类似任务直接改改就能用比重新让AI生成还快。这个习惯看起来笨但积累效应很明显你可以试试。