1. 从“AI写代码尝试1”说起我为什么要认真对待这件事“AI写代码尝试1”这个标题乍一看像是某个技术社区里随手发的帖子标题朴素到甚至有点敷衍。但恰恰是这种“尝试1”的命名方式暴露了一个真实场景一个开发者第一次认真地把AI引入自己的编码流程带着好奇、怀疑和一点点试探想看看它到底能不能干活。我太熟悉这种状态了因为我自己也是从“尝试1”走过来的。先把这个话题的边界说清楚。这里聊的“AI写代码”指的是用大语言模型驱动的编程助手来辅助完成日常开发任务包括但不限于根据自然语言描述生成函数体、补全重复性代码片段、解释陌生代码逻辑、生成单元测试、排查报错原因、重构已有代码结构。它不涉及任何自动化攻击、恶意脚本生成或绕过安全机制的内容纯粹是正经开发场景下的效率工具。为什么值得认真聊因为大部分人对AI编程的认知还停留在两个极端要么觉得“AI马上要取代程序员了”要么觉得“AI写的代码根本不能用”。这两种判断都太粗糙了。实际用下来AI写代码的能力边界非常清晰——它在某些任务上确实能把你从重复劳动里捞出来在另一些任务上则会给你埋坑而且埋得悄无声息。你需要知道哪些活可以交给它哪些活必须自己盯着以及怎么跟它配合才能把效率真正提上去。这篇文章适合三类人看第一类是从没用过AI编程工具、想找个靠谱切入点的新手第二类是用过几次但觉得“也就那样”、没找到正确使用姿势的开发者第三类是对AI辅助开发持怀疑态度、想看看实际效果到底如何的老手。我会从整体设计思路、核心实操细节、完整工作流、常见坑与排查方法四个维度展开尽量把每个环节的“为什么”讲透让你看完能直接上手复现。2. 整体设计与思路拆解AI写代码到底该怎么定位2.1 先搞清楚AI编程工具的三种典型形态在动手之前有必要把市面上AI编程工具的形态理一遍。不同的形态决定了你跟它协作的方式完全不同用错了形态就像拿螺丝刀去敲钉子不是不行但效率极低。第一种是编辑器内嵌式补全。这类工具直接集成在你的代码编辑器里你敲几个字符它就开始预测你接下来要写什么按Tab就能接受建议。它的特点是响应快、侵入性低适合处理那些你“知道要写什么但懒得敲”的场景比如循环结构、条件判断、常见的API调用模板。缺点是它只能看到当前文件或附近几个文件的上下文对项目整体架构的理解有限。第二种是对话式编程助手。你打开一个聊天窗口用自然语言描述需求它给你生成代码块你再复制到项目里。这种形态适合处理“从零开始写一个模块”“解释这段代码在干什么”“帮我看看这个报错怎么修”之类的任务。它的优势是你可以反复追问、逐步细化需求缺点是来回粘贴比较繁琐而且它看不到你项目的完整上下文。第三种是项目级Agent。这类工具能读取你整个项目的文件结构理解模块之间的依赖关系然后直接在你的项目里创建、修改、删除文件。它适合处理跨文件的修改任务比如“把所有用到旧API的地方替换成新API”“给这个模块补一套单元测试”。能力最强但也最需要小心因为它动的是你真实的代码库。我自己的习惯是日常编码用第一种做快速补全遇到需要思考的问题用第二种做方案讨论批量修改或重构用第三种。三种形态配合使用覆盖了大部分开发场景。2.2 为什么选择“先小后大”的尝试策略回到“尝试1”这个场景。很多人第一次用AI写代码上来就让它“帮我写一个完整的电商后台”结果生成出来的东西跑不起来然后得出结论“AI不行”。这不是AI的问题是使用策略的问题。我的建议是第一次尝试选一个独立的小功能作为切入点。什么叫独立的小功能就是它不依赖项目里其他模块的复杂状态输入输出清晰逻辑边界明确。比如一个日期格式化函数、一个字符串校验工具、一个简单的数据转换逻辑。这种任务的好处是你能快速判断AI生成的代码对不对即使错了排查成本也很低。为什么不一开始就让它处理复杂任务因为AI生成代码的质量跟任务复杂度呈反比。任务越复杂它越容易在细节上出错而且错误往往藏得很深你排查起来花的时间可能比自己写还多。先用小任务建立信任、摸清它的能力边界再逐步扩大使用范围这是比较稳妥的路径。2.3 提示词的质量决定了输出质量的上限这一点怎么强调都不过分。同样一个需求你用不同的方式描述AI给出的代码质量可能差出好几个档次。我总结了一个比较实用的提示词结构分四个部分角色设定告诉AI它是什么身份。比如“你是一个有十年经验的Python后端工程师”这会让它倾向于使用更成熟的写法和更规范的代码风格。任务描述用一句话说清楚要做什么。越具体越好避免模糊表述。约束条件明确技术栈、版本、编码规范、性能要求等。比如“使用Python 3.10语法”“不要引入第三方库”“函数需要处理空输入的情况”。输出格式告诉它你想要什么样的输出。比如“只输出代码不要解释”“每个函数附带docstring”“给出两个版本的实现一个追求可读性一个追求性能”。我试过用同一个需求分别写了一段模糊提示和一段结构化提示模糊提示生成的代码需要改三处才能用结构化提示生成的代码直接就能跑。这个差距在长期使用中会累积成巨大的效率差异。3. 核心细节解析与实操要点从需求到可运行代码3.1 第一个实操案例写一个带缓存的斐波那契函数我拿一个具体例子来演示整个流程。需求很简单写一个计算斐波那契数列第n项的Python函数要求带缓存避免重复计算并且处理非法输入。先看我的提示词你是一个有十年经验的Python工程师。 任务实现一个计算斐波那契数列第n项的函数。 约束 - 使用Python 3.10语法 - 使用functools.lru_cache做缓存 - 输入必须是正整数否则抛出ValueError并给出明确错误信息 - 函数需要附带docstring - 不要引入除标准库以外的任何依赖 输出只输出代码不要额外解释。AI生成的代码如下from functools import lru_cache lru_cache(maxsizeNone) def fibonacci(n: int) - int: 计算斐波那契数列的第n项。 Args: n: 正整数表示要计算的项数从1开始计数。 Returns: 斐波那契数列的第n项。 Raises: ValueError: 当n不是正整数时抛出。 if not isinstance(n, int) or n 0: raise ValueError(f参数n必须是正整数当前值为: {n}) if n 2: return 1 return fibonacci(n - 1) fibonacci(n - 2)这段代码直接就能用。我实际跑了一下fibonacci(100)瞬间返回fibonacci(0)和fibonacci(-1)都正确抛出了ValueErrorfibonacci(abc)也正确拦截了。唯一需要注意的是isinstance(n, int)这个判断在Python里True也是int的实例所以fibonacci(True)会返回1而不是报错。如果你在意这个边界情况可以把判断改成type(n) is not int。但这是很细的点了AI没有主动处理也正常。3.2 第二个实操案例让AI帮我写单元测试代码写完了下一步是测试。我继续用对话式助手提示词如下基于上面那个fibonacci函数用pytest写一套单元测试。 要求 - 覆盖正常输入、边界输入、非法输入三种情况 - 正常输入至少测试5个不同的n值 - 边界输入测试n1和n2 - 非法输入测试0、负数、浮点数、字符串、None - 使用pytest.raises来断言异常 - 每个测试函数只测一个关注点AI生成的测试代码import pytest from fibonacci import fibonacci class TestFibonacciNormal: pytest.mark.parametrize(n,expected, [ (1, 1), (2, 1), (3, 2), (4, 3), (5, 5), (10, 55), (20, 6765), ]) def test_normal_inputs(self, n, expected): assert fibonacci(n) expected class TestFibonacciBoundary: def test_n_equals_1(self): assert fibonacci(1) 1 def test_n_equals_2(self): assert fibonacci(2) 1 class TestFibonacciInvalid: pytest.mark.parametrize(invalid_input, [0, -1, -100]) def test_non_positive_integers(self, invalid_input): with pytest.raises(ValueError): fibonacci(invalid_input) pytest.mark.parametrize(invalid_input, [1.5, 2.0, abc, None, [1]]) def test_non_integer_types(self, invalid_input): with pytest.raises(ValueError): fibonacci(invalid_input)这套测试结构清晰参数化用得很到位。我跑了一遍全部通过。但有一个细节值得注意fibonacci(2.0)会触发ValueError因为isinstance(2.0, int)返回False。但如果你把判断改成type(n) is not int结果也一样。这里AI的处理是合理的。3.3 第三个实操案例让AI解释一段陌生代码有时候你接手了一个老项目看到一段看不懂的代码这时候AI的解释能力就派上用场了。我随便找了一段用了装饰器和生成器的代码丢给它def retry(max_attempts3, delay1): def decorator(func): def wrapper(*args, **kwargs): for attempt in range(max_attempts): try: return func(*args, **kwargs) except Exception as e: if attempt max_attempts - 1: raise time.sleep(delay) return wrapper return decoratorAI的解释很到位这是一个带参数的重试装饰器max_attempts控制最大重试次数delay控制每次重试之间的等待秒数。当被装饰的函数抛出异常时它会捕获异常并等待一段时间后重试直到达到最大次数才把异常抛出去。它还主动指出了这段代码的一个潜在问题time模块没有导入直接运行会报NameError。这个提醒很有价值因为如果你只是复制粘贴而不仔细看很容易忽略这个细节。3.4 实操心得三个让我少走弯路的习惯用了几个月AI编程工具之后我养成了三个习惯分享出来供参考。第一个习惯永远先让AI写测试再让它写实现。这个顺序很重要。如果你先让它写实现它会给你一个看起来能跑的版本但边界情况可能没处理全。如果你先让它写测试它会从测试的角度思考各种输入情况然后你再让它基于测试写实现覆盖率会高很多。这个思路其实就是测试驱动开发TDD的变体只不过把写测试的活交给了AI。第二个习惯生成的代码必须自己跑一遍。不管AI生成的代码看起来多合理我都会在本地跑一遍。有时候是语法问题有时候是逻辑问题有时候是版本兼容问题。跑一遍花不了多少时间但能避免很多后续麻烦。第三个习惯保留对话记录。我会把跟AI的对话记录保存下来尤其是那些涉及方案讨论的部分。过一段时间回头看能发现自己当时思考的盲点也能积累一套适合自己的提示词模板。注意AI生成的代码不要直接提交到生产环境。即使它看起来没问题也要经过代码审查和测试流程。这不是对AI的不信任而是对工程质量的基本要求。4. 完整实操流程从零搭建一个AI辅助开发工作流4.1 环境准备与工具选型先说工具选型。编辑器内嵌补全类的工具我目前用的是VS Code配合主流的AI编程插件安装后在设置里填入API Key就能用。对话式助手我直接用网页版方便随时开一个窗口讨论问题。项目级Agent我还在谨慎尝试阶段目前只在不重要的项目上做实验。环境准备方面你需要确保本地开发环境是完整的。Python项目的话建议用虚拟环境隔离依赖避免AI生成的代码引入的包跟你现有项目冲突。我习惯用python -m venv .venv创建虚拟环境然后source .venv/bin/activate激活。Node.js项目就用npm init初始化按需安装依赖。有一点需要提醒AI生成的代码可能会引用一些你项目里没有的库。比如它可能默认你装了requests或numpy但实际上你的环境里没有。所以每次拿到生成的代码先扫一眼import部分确认依赖是否满足。4.2 提示词模板的迭代过程我一开始用的提示词很随意就是“帮我写一个XXX函数”。后来发现这样生成的代码质量不稳定就开始迭代模板。目前我的标准模板是这样的角色你是一个有X年经验的[语言/领域]工程师。 任务[一句话描述要做什么]。 输入[描述输入数据的格式和范围]。 输出[描述期望的输出格式]。 约束 - 技术栈[语言版本、框架、库] - 编码规范[命名风格、注释要求、错误处理方式] - 性能要求[时间复杂度、空间复杂度、并发要求] - 禁止事项[不要引入的依赖、不要使用的语法] 边界情况[需要处理的特殊输入] 输出格式[只输出代码/附带解释/给出多个方案]这个模板看起来有点长但实际用起来效率很高。因为你在写提示词的过程中其实也在梳理自己的需求。很多时候写着写着就发现原来自己都没想清楚要什么。4.3 代码审查与集成流程AI生成的代码不能直接合并到主分支这是我给自己定的规矩。我的流程是这样的第一步在本地新建一个临时分支把AI生成的代码放进去。第二步跑一遍现有的测试套件看看有没有破坏已有功能。第三步针对新代码写补充测试覆盖AI可能遗漏的边界情况。第四步自己通读一遍代码重点看错误处理、资源释放、并发安全这几个容易出问题的地方。第五步确认没问题后再合并到开发分支。这个流程听起来繁琐但实际操作下来对于小功能来说也就多花几分钟。相比于AI帮你节省的时间这点投入完全值得。4.4 一个完整的端到端案例我拿一个实际做过的任务来演示完整流程。需求是写一个函数接收一个文件路径列表返回其中所有文本文件的行数统计按行数降序排列。第一步写提示词。我按照模板填好特别强调了要处理文件不存在、编码错误、非文本文件这三种异常情况。第二步获取AI生成的代码。它给了一个用pathlib和chardet检测编码的方案。我注意到它引入了chardet这个第三方库而我的约束里写了“尽量只用标准库”。于是我追问了一句“能不能不用chardet只用标准库实现编码检测”它改成了用errorsreplace的方式打开文件虽然不能精确检测编码但能保证不崩溃。第三步本地测试。我造了几个测试文件一个正常的UTF-8文本、一个GBK编码的中文文本、一个二进制文件、一个不存在的路径。跑下来发现GBK文件用errorsreplace打开后行数统计是对的但内容会有乱码。不过对于“统计行数”这个需求来说乱码不影响结果可以接受。第四步补充边界测试。我加了空文件、只有一行没有换行符的文件、超大文件100万行的测试。空文件返回0行单行无换行符返回1行超大文件在2秒内完成统计。都符合预期。第五步集成到项目。合并到开发分支跑全量测试通过。整个流程从开始到完成大概花了40分钟其中AI生成代码只用了不到1分钟剩下时间都在测试和验证上。这个时间分配是合理的——AI负责生成你负责验证各司其职。5. 常见问题与排查技巧实录5.1 AI生成的代码跑不起来怎么办这是最常见的问题。根据我的经验原因通常集中在以下几类问题类型典型表现排查方法解决思路依赖缺失ModuleNotFoundError检查import语句安装缺失的包或让AI改用标准库版本不兼容SyntaxError或API行为差异确认Python/Node版本在提示词中明确版本号逻辑错误代码能跑但结果不对用测试用例验证把错误结果反馈给AI让它修正边界遗漏特殊输入导致崩溃构造边界输入测试在提示词中补充边界情况说明上下文缺失引用了不存在的变量或函数检查项目上下文把相关代码一起提供给AI我遇到最多的是依赖缺失和版本不兼容。有一次AI用了一个Python 3.12才有的语法特性而我的环境是3.10直接报SyntaxError。后来我在提示词模板里固定加上“使用Python 3.10语法”这个问题就再没出现过。5.2 AI写的代码“看起来对但实际有坑”这种情况比直接报错更危险因为你不容易发现。我踩过的一个坑是让AI写一个并发下载文件的函数它用了ThreadPoolExecutor代码看起来很标准。但实际跑的时候发现它没有处理线程池的异常传播——如果某个下载任务抛异常主线程不会收到通知程序会静默地继续执行。这个坑藏得很深我是因为下载的文件数量对不上才发现的。后来我总结了一个检查清单专门用来审查AI生成的并发代码异常是否被正确捕获和传播线程池/进程池是否正确关闭共享资源是否有锁保护超时机制是否完善取消操作是否支持这个清单不一定全面但能覆盖大部分常见问题。5.3 如何判断AI给出的方案是否合理有时候AI会给出多个方案或者你让它“给出三种不同的实现方式”这时候需要你自己判断哪个更合适。我的判断标准有三个第一看可读性。代码是写给人看的顺便给机器执行。如果一个方案用了太多奇技淫巧即使性能好一点我也不倾向于选它。除非性能是硬性要求。第二看可维护性。这个方案依赖的库是否活跃维护代码结构是否清晰后续如果要加功能改动成本大不大第三看边界处理。好的方案会主动处理边界情况而不是假设输入永远合法。如果一个方案对异常输入没有任何处理那它大概率不够成熟。5.4 独家避坑技巧三个“不要”不要在没有测试的情况下信任AI生成的代码。这句话我说多少遍都不嫌多。AI生成的代码看起来越流畅你越容易放松警惕。但流畅不等于正确。不要在提示词里省略约束条件。你省略的每一个约束AI都会用它的默认值来填充。而它的默认值可能跟你的项目规范完全不搭。比如你不说命名风格它可能用驼峰也可能用下划线取决于它当时的心情。不要把AI当搜索引擎用。有些问题AI的回答听起来很有道理但实际上是错的。尤其是涉及具体库的API用法、版本特性、配置参数这类需要精确信息的问题最好还是查官方文档。AI适合帮你理清思路、生成模板代码、解释概念但不适合作为权威信息源。5.5 常见问题速查表现象可能原因快速排查解决动作代码复制后报缩进错误复制时格式丢失检查缩进是否一致用编辑器的格式化功能函数返回None忘记写return检查函数体最后一行补上return语句循环次数不对边界条件写错打印循环变量调整range参数中文乱码编码不一致检查文件编码统一用UTF-8性能比预期慢算法复杂度高分析时间复杂度让AI优化算法测试通过但线上报错环境差异对比本地和线上环境统一依赖版本6. 我对AI写代码这件事的真实看法用了这段时间我对AI写代码的定位越来越清晰它是一个效率放大器不是一个能力替代品。它能帮你更快地完成你本来就会做的事情但它不能帮你完成你不会做的事情。如果你不懂代码AI生成的代码你无法判断对错那它对你来说就是个黑盒风险大于收益。如果你懂代码AI能帮你省掉大量重复劳动让你把精力集中在真正需要思考的地方。我现在的日常是写新功能时先让AI生成一个初版然后我在初版基础上修改和优化。写测试时让AI生成测试用例框架我补充边界情况。排查问题时把报错信息和相关代码丢给AI让它给出排查方向我再逐一验证。读陌生代码时让AI先解释一遍我再对照源码确认。这个协作模式让我在保持代码质量的前提下效率大概提升了30%到40%。不是翻倍也不是取代就是实打实的效率提升。对于日常开发来说这个提升已经很有价值了。最后分享一个小技巧如果你觉得AI生成的代码风格跟你的项目不一致可以在提示词里附上一段你项目里的典型代码作为参考告诉它“按照这个风格来写”。这招很管用生成的代码几乎不需要调整格式就能直接用。 AI写代码实战：从尝试到高效工作流
1. 从“AI写代码尝试1”说起我为什么要认真对待这件事“AI写代码尝试1”这个标题乍一看像是某个技术社区里随手发的帖子标题朴素到甚至有点敷衍。但恰恰是这种“尝试1”的命名方式暴露了一个真实场景一个开发者第一次认真地把AI引入自己的编码流程带着好奇、怀疑和一点点试探想看看它到底能不能干活。我太熟悉这种状态了因为我自己也是从“尝试1”走过来的。先把这个话题的边界说清楚。这里聊的“AI写代码”指的是用大语言模型驱动的编程助手来辅助完成日常开发任务包括但不限于根据自然语言描述生成函数体、补全重复性代码片段、解释陌生代码逻辑、生成单元测试、排查报错原因、重构已有代码结构。它不涉及任何自动化攻击、恶意脚本生成或绕过安全机制的内容纯粹是正经开发场景下的效率工具。为什么值得认真聊因为大部分人对AI编程的认知还停留在两个极端要么觉得“AI马上要取代程序员了”要么觉得“AI写的代码根本不能用”。这两种判断都太粗糙了。实际用下来AI写代码的能力边界非常清晰——它在某些任务上确实能把你从重复劳动里捞出来在另一些任务上则会给你埋坑而且埋得悄无声息。你需要知道哪些活可以交给它哪些活必须自己盯着以及怎么跟它配合才能把效率真正提上去。这篇文章适合三类人看第一类是从没用过AI编程工具、想找个靠谱切入点的新手第二类是用过几次但觉得“也就那样”、没找到正确使用姿势的开发者第三类是对AI辅助开发持怀疑态度、想看看实际效果到底如何的老手。我会从整体设计思路、核心实操细节、完整工作流、常见坑与排查方法四个维度展开尽量把每个环节的“为什么”讲透让你看完能直接上手复现。2. 整体设计与思路拆解AI写代码到底该怎么定位2.1 先搞清楚AI编程工具的三种典型形态在动手之前有必要把市面上AI编程工具的形态理一遍。不同的形态决定了你跟它协作的方式完全不同用错了形态就像拿螺丝刀去敲钉子不是不行但效率极低。第一种是编辑器内嵌式补全。这类工具直接集成在你的代码编辑器里你敲几个字符它就开始预测你接下来要写什么按Tab就能接受建议。它的特点是响应快、侵入性低适合处理那些你“知道要写什么但懒得敲”的场景比如循环结构、条件判断、常见的API调用模板。缺点是它只能看到当前文件或附近几个文件的上下文对项目整体架构的理解有限。第二种是对话式编程助手。你打开一个聊天窗口用自然语言描述需求它给你生成代码块你再复制到项目里。这种形态适合处理“从零开始写一个模块”“解释这段代码在干什么”“帮我看看这个报错怎么修”之类的任务。它的优势是你可以反复追问、逐步细化需求缺点是来回粘贴比较繁琐而且它看不到你项目的完整上下文。第三种是项目级Agent。这类工具能读取你整个项目的文件结构理解模块之间的依赖关系然后直接在你的项目里创建、修改、删除文件。它适合处理跨文件的修改任务比如“把所有用到旧API的地方替换成新API”“给这个模块补一套单元测试”。能力最强但也最需要小心因为它动的是你真实的代码库。我自己的习惯是日常编码用第一种做快速补全遇到需要思考的问题用第二种做方案讨论批量修改或重构用第三种。三种形态配合使用覆盖了大部分开发场景。2.2 为什么选择“先小后大”的尝试策略回到“尝试1”这个场景。很多人第一次用AI写代码上来就让它“帮我写一个完整的电商后台”结果生成出来的东西跑不起来然后得出结论“AI不行”。这不是AI的问题是使用策略的问题。我的建议是第一次尝试选一个独立的小功能作为切入点。什么叫独立的小功能就是它不依赖项目里其他模块的复杂状态输入输出清晰逻辑边界明确。比如一个日期格式化函数、一个字符串校验工具、一个简单的数据转换逻辑。这种任务的好处是你能快速判断AI生成的代码对不对即使错了排查成本也很低。为什么不一开始就让它处理复杂任务因为AI生成代码的质量跟任务复杂度呈反比。任务越复杂它越容易在细节上出错而且错误往往藏得很深你排查起来花的时间可能比自己写还多。先用小任务建立信任、摸清它的能力边界再逐步扩大使用范围这是比较稳妥的路径。2.3 提示词的质量决定了输出质量的上限这一点怎么强调都不过分。同样一个需求你用不同的方式描述AI给出的代码质量可能差出好几个档次。我总结了一个比较实用的提示词结构分四个部分角色设定告诉AI它是什么身份。比如“你是一个有十年经验的Python后端工程师”这会让它倾向于使用更成熟的写法和更规范的代码风格。任务描述用一句话说清楚要做什么。越具体越好避免模糊表述。约束条件明确技术栈、版本、编码规范、性能要求等。比如“使用Python 3.10语法”“不要引入第三方库”“函数需要处理空输入的情况”。输出格式告诉它你想要什么样的输出。比如“只输出代码不要解释”“每个函数附带docstring”“给出两个版本的实现一个追求可读性一个追求性能”。我试过用同一个需求分别写了一段模糊提示和一段结构化提示模糊提示生成的代码需要改三处才能用结构化提示生成的代码直接就能跑。这个差距在长期使用中会累积成巨大的效率差异。3. 核心细节解析与实操要点从需求到可运行代码3.1 第一个实操案例写一个带缓存的斐波那契函数我拿一个具体例子来演示整个流程。需求很简单写一个计算斐波那契数列第n项的Python函数要求带缓存避免重复计算并且处理非法输入。先看我的提示词你是一个有十年经验的Python工程师。 任务实现一个计算斐波那契数列第n项的函数。 约束 - 使用Python 3.10语法 - 使用functools.lru_cache做缓存 - 输入必须是正整数否则抛出ValueError并给出明确错误信息 - 函数需要附带docstring - 不要引入除标准库以外的任何依赖 输出只输出代码不要额外解释。AI生成的代码如下from functools import lru_cache lru_cache(maxsizeNone) def fibonacci(n: int) - int: 计算斐波那契数列的第n项。 Args: n: 正整数表示要计算的项数从1开始计数。 Returns: 斐波那契数列的第n项。 Raises: ValueError: 当n不是正整数时抛出。 if not isinstance(n, int) or n 0: raise ValueError(f参数n必须是正整数当前值为: {n}) if n 2: return 1 return fibonacci(n - 1) fibonacci(n - 2)这段代码直接就能用。我实际跑了一下fibonacci(100)瞬间返回fibonacci(0)和fibonacci(-1)都正确抛出了ValueErrorfibonacci(abc)也正确拦截了。唯一需要注意的是isinstance(n, int)这个判断在Python里True也是int的实例所以fibonacci(True)会返回1而不是报错。如果你在意这个边界情况可以把判断改成type(n) is not int。但这是很细的点了AI没有主动处理也正常。3.2 第二个实操案例让AI帮我写单元测试代码写完了下一步是测试。我继续用对话式助手提示词如下基于上面那个fibonacci函数用pytest写一套单元测试。 要求 - 覆盖正常输入、边界输入、非法输入三种情况 - 正常输入至少测试5个不同的n值 - 边界输入测试n1和n2 - 非法输入测试0、负数、浮点数、字符串、None - 使用pytest.raises来断言异常 - 每个测试函数只测一个关注点AI生成的测试代码import pytest from fibonacci import fibonacci class TestFibonacciNormal: pytest.mark.parametrize(n,expected, [ (1, 1), (2, 1), (3, 2), (4, 3), (5, 5), (10, 55), (20, 6765), ]) def test_normal_inputs(self, n, expected): assert fibonacci(n) expected class TestFibonacciBoundary: def test_n_equals_1(self): assert fibonacci(1) 1 def test_n_equals_2(self): assert fibonacci(2) 1 class TestFibonacciInvalid: pytest.mark.parametrize(invalid_input, [0, -1, -100]) def test_non_positive_integers(self, invalid_input): with pytest.raises(ValueError): fibonacci(invalid_input) pytest.mark.parametrize(invalid_input, [1.5, 2.0, abc, None, [1]]) def test_non_integer_types(self, invalid_input): with pytest.raises(ValueError): fibonacci(invalid_input)这套测试结构清晰参数化用得很到位。我跑了一遍全部通过。但有一个细节值得注意fibonacci(2.0)会触发ValueError因为isinstance(2.0, int)返回False。但如果你把判断改成type(n) is not int结果也一样。这里AI的处理是合理的。3.3 第三个实操案例让AI解释一段陌生代码有时候你接手了一个老项目看到一段看不懂的代码这时候AI的解释能力就派上用场了。我随便找了一段用了装饰器和生成器的代码丢给它def retry(max_attempts3, delay1): def decorator(func): def wrapper(*args, **kwargs): for attempt in range(max_attempts): try: return func(*args, **kwargs) except Exception as e: if attempt max_attempts - 1: raise time.sleep(delay) return wrapper return decoratorAI的解释很到位这是一个带参数的重试装饰器max_attempts控制最大重试次数delay控制每次重试之间的等待秒数。当被装饰的函数抛出异常时它会捕获异常并等待一段时间后重试直到达到最大次数才把异常抛出去。它还主动指出了这段代码的一个潜在问题time模块没有导入直接运行会报NameError。这个提醒很有价值因为如果你只是复制粘贴而不仔细看很容易忽略这个细节。3.4 实操心得三个让我少走弯路的习惯用了几个月AI编程工具之后我养成了三个习惯分享出来供参考。第一个习惯永远先让AI写测试再让它写实现。这个顺序很重要。如果你先让它写实现它会给你一个看起来能跑的版本但边界情况可能没处理全。如果你先让它写测试它会从测试的角度思考各种输入情况然后你再让它基于测试写实现覆盖率会高很多。这个思路其实就是测试驱动开发TDD的变体只不过把写测试的活交给了AI。第二个习惯生成的代码必须自己跑一遍。不管AI生成的代码看起来多合理我都会在本地跑一遍。有时候是语法问题有时候是逻辑问题有时候是版本兼容问题。跑一遍花不了多少时间但能避免很多后续麻烦。第三个习惯保留对话记录。我会把跟AI的对话记录保存下来尤其是那些涉及方案讨论的部分。过一段时间回头看能发现自己当时思考的盲点也能积累一套适合自己的提示词模板。注意AI生成的代码不要直接提交到生产环境。即使它看起来没问题也要经过代码审查和测试流程。这不是对AI的不信任而是对工程质量的基本要求。4. 完整实操流程从零搭建一个AI辅助开发工作流4.1 环境准备与工具选型先说工具选型。编辑器内嵌补全类的工具我目前用的是VS Code配合主流的AI编程插件安装后在设置里填入API Key就能用。对话式助手我直接用网页版方便随时开一个窗口讨论问题。项目级Agent我还在谨慎尝试阶段目前只在不重要的项目上做实验。环境准备方面你需要确保本地开发环境是完整的。Python项目的话建议用虚拟环境隔离依赖避免AI生成的代码引入的包跟你现有项目冲突。我习惯用python -m venv .venv创建虚拟环境然后source .venv/bin/activate激活。Node.js项目就用npm init初始化按需安装依赖。有一点需要提醒AI生成的代码可能会引用一些你项目里没有的库。比如它可能默认你装了requests或numpy但实际上你的环境里没有。所以每次拿到生成的代码先扫一眼import部分确认依赖是否满足。4.2 提示词模板的迭代过程我一开始用的提示词很随意就是“帮我写一个XXX函数”。后来发现这样生成的代码质量不稳定就开始迭代模板。目前我的标准模板是这样的角色你是一个有X年经验的[语言/领域]工程师。 任务[一句话描述要做什么]。 输入[描述输入数据的格式和范围]。 输出[描述期望的输出格式]。 约束 - 技术栈[语言版本、框架、库] - 编码规范[命名风格、注释要求、错误处理方式] - 性能要求[时间复杂度、空间复杂度、并发要求] - 禁止事项[不要引入的依赖、不要使用的语法] 边界情况[需要处理的特殊输入] 输出格式[只输出代码/附带解释/给出多个方案]这个模板看起来有点长但实际用起来效率很高。因为你在写提示词的过程中其实也在梳理自己的需求。很多时候写着写着就发现原来自己都没想清楚要什么。4.3 代码审查与集成流程AI生成的代码不能直接合并到主分支这是我给自己定的规矩。我的流程是这样的第一步在本地新建一个临时分支把AI生成的代码放进去。第二步跑一遍现有的测试套件看看有没有破坏已有功能。第三步针对新代码写补充测试覆盖AI可能遗漏的边界情况。第四步自己通读一遍代码重点看错误处理、资源释放、并发安全这几个容易出问题的地方。第五步确认没问题后再合并到开发分支。这个流程听起来繁琐但实际操作下来对于小功能来说也就多花几分钟。相比于AI帮你节省的时间这点投入完全值得。4.4 一个完整的端到端案例我拿一个实际做过的任务来演示完整流程。需求是写一个函数接收一个文件路径列表返回其中所有文本文件的行数统计按行数降序排列。第一步写提示词。我按照模板填好特别强调了要处理文件不存在、编码错误、非文本文件这三种异常情况。第二步获取AI生成的代码。它给了一个用pathlib和chardet检测编码的方案。我注意到它引入了chardet这个第三方库而我的约束里写了“尽量只用标准库”。于是我追问了一句“能不能不用chardet只用标准库实现编码检测”它改成了用errorsreplace的方式打开文件虽然不能精确检测编码但能保证不崩溃。第三步本地测试。我造了几个测试文件一个正常的UTF-8文本、一个GBK编码的中文文本、一个二进制文件、一个不存在的路径。跑下来发现GBK文件用errorsreplace打开后行数统计是对的但内容会有乱码。不过对于“统计行数”这个需求来说乱码不影响结果可以接受。第四步补充边界测试。我加了空文件、只有一行没有换行符的文件、超大文件100万行的测试。空文件返回0行单行无换行符返回1行超大文件在2秒内完成统计。都符合预期。第五步集成到项目。合并到开发分支跑全量测试通过。整个流程从开始到完成大概花了40分钟其中AI生成代码只用了不到1分钟剩下时间都在测试和验证上。这个时间分配是合理的——AI负责生成你负责验证各司其职。5. 常见问题与排查技巧实录5.1 AI生成的代码跑不起来怎么办这是最常见的问题。根据我的经验原因通常集中在以下几类问题类型典型表现排查方法解决思路依赖缺失ModuleNotFoundError检查import语句安装缺失的包或让AI改用标准库版本不兼容SyntaxError或API行为差异确认Python/Node版本在提示词中明确版本号逻辑错误代码能跑但结果不对用测试用例验证把错误结果反馈给AI让它修正边界遗漏特殊输入导致崩溃构造边界输入测试在提示词中补充边界情况说明上下文缺失引用了不存在的变量或函数检查项目上下文把相关代码一起提供给AI我遇到最多的是依赖缺失和版本不兼容。有一次AI用了一个Python 3.12才有的语法特性而我的环境是3.10直接报SyntaxError。后来我在提示词模板里固定加上“使用Python 3.10语法”这个问题就再没出现过。5.2 AI写的代码“看起来对但实际有坑”这种情况比直接报错更危险因为你不容易发现。我踩过的一个坑是让AI写一个并发下载文件的函数它用了ThreadPoolExecutor代码看起来很标准。但实际跑的时候发现它没有处理线程池的异常传播——如果某个下载任务抛异常主线程不会收到通知程序会静默地继续执行。这个坑藏得很深我是因为下载的文件数量对不上才发现的。后来我总结了一个检查清单专门用来审查AI生成的并发代码异常是否被正确捕获和传播线程池/进程池是否正确关闭共享资源是否有锁保护超时机制是否完善取消操作是否支持这个清单不一定全面但能覆盖大部分常见问题。5.3 如何判断AI给出的方案是否合理有时候AI会给出多个方案或者你让它“给出三种不同的实现方式”这时候需要你自己判断哪个更合适。我的判断标准有三个第一看可读性。代码是写给人看的顺便给机器执行。如果一个方案用了太多奇技淫巧即使性能好一点我也不倾向于选它。除非性能是硬性要求。第二看可维护性。这个方案依赖的库是否活跃维护代码结构是否清晰后续如果要加功能改动成本大不大第三看边界处理。好的方案会主动处理边界情况而不是假设输入永远合法。如果一个方案对异常输入没有任何处理那它大概率不够成熟。5.4 独家避坑技巧三个“不要”不要在没有测试的情况下信任AI生成的代码。这句话我说多少遍都不嫌多。AI生成的代码看起来越流畅你越容易放松警惕。但流畅不等于正确。不要在提示词里省略约束条件。你省略的每一个约束AI都会用它的默认值来填充。而它的默认值可能跟你的项目规范完全不搭。比如你不说命名风格它可能用驼峰也可能用下划线取决于它当时的心情。不要把AI当搜索引擎用。有些问题AI的回答听起来很有道理但实际上是错的。尤其是涉及具体库的API用法、版本特性、配置参数这类需要精确信息的问题最好还是查官方文档。AI适合帮你理清思路、生成模板代码、解释概念但不适合作为权威信息源。5.5 常见问题速查表现象可能原因快速排查解决动作代码复制后报缩进错误复制时格式丢失检查缩进是否一致用编辑器的格式化功能函数返回None忘记写return检查函数体最后一行补上return语句循环次数不对边界条件写错打印循环变量调整range参数中文乱码编码不一致检查文件编码统一用UTF-8性能比预期慢算法复杂度高分析时间复杂度让AI优化算法测试通过但线上报错环境差异对比本地和线上环境统一依赖版本6. 我对AI写代码这件事的真实看法用了这段时间我对AI写代码的定位越来越清晰它是一个效率放大器不是一个能力替代品。它能帮你更快地完成你本来就会做的事情但它不能帮你完成你不会做的事情。如果你不懂代码AI生成的代码你无法判断对错那它对你来说就是个黑盒风险大于收益。如果你懂代码AI能帮你省掉大量重复劳动让你把精力集中在真正需要思考的地方。我现在的日常是写新功能时先让AI生成一个初版然后我在初版基础上修改和优化。写测试时让AI生成测试用例框架我补充边界情况。排查问题时把报错信息和相关代码丢给AI让它给出排查方向我再逐一验证。读陌生代码时让AI先解释一遍我再对照源码确认。这个协作模式让我在保持代码质量的前提下效率大概提升了30%到40%。不是翻倍也不是取代就是实打实的效率提升。对于日常开发来说这个提升已经很有价值了。最后分享一个小技巧如果你觉得AI生成的代码风格跟你的项目不一致可以在提示词里附上一段你项目里的典型代码作为参考告诉它“按照这个风格来写”。这招很管用生成的代码几乎不需要调整格式就能直接用。