周五下午四点四十分产品经理把一个多线程爬虫的需求丢过来说下周一早上要。我看了一眼那堆待解析的页面结构又看了一眼已经凉透了的咖啡脑子里突然冒出一个念头要不……让AI试试那是我第一次认真尝试用AI写代码。之前我也用过一些AI工具但都是零敲碎打——生成一句SQL、补一个正则表达式、查一下某个API的用法。但这次不一样这次是一个完整的功能模块有明确的输入输出有性能要求还有deadline压着。我花了大概二十分钟写提示词用AI写出了第一版代码跑通后又花了一个晚上调试。那个晚上之后我对AI写代码这件事的看法彻底变了——它确实能干活但前提是你会正确地指挥它。这篇博文就是我这段时间折腾AI写代码的全记录。我会告诉你我踩过的坑、总结出来的提示词模板、遇到的典型翻车现场以及一些连文档里都不会写的实操细节。无论你是刚接触AI辅助开发的新手还是试过几次但被AI坑得够呛的老手这篇文章应该都能给你一些参考。1. 为什么突然想试试AI写代码1.1 那个周五下午的真实需求先说那个爬虫的需求。其实本身不难——从某个行业网站上抓取公开的商品信息包括名称、价格、规格参数、库存状态大概两百多个商品分布在二十多个页面上。难点在于这个网站不是标准REST API数据是通过JavaScript动态渲染出来的直接用requests库抓不到得用Selenium或者Playwright这类工具模拟浏览器行为。页面还有一些简单的反爬策略比如请求频率限制、User-Agent检测。如果让我手动写我的大概思路是用Playwright启动浏览器、逐个页面加载、等待渲染完成、解析DOM节点、提取字段、写入CSV文件。这个流程我写过很多次闭着眼睛也能写但问题是写起来很痛苦——不是逻辑复杂而是大量重复的样板代码浏览器实例配置、等待条件、异常重试、日志输出、文件写入。这些代码没有技术含量但每一个环节都有可能出错每一个出错都要花时间去查。当时我用了大概十分钟的时间在一个在线大模型里输入了这样的需求描述第一版代码很快就生成出来了。代码长什么样呢说实话第一眼看到的时候我有点惊讶——Playwright的用法是对的定位元素的XPath选择器竟然也是对的连显式等待都加上了。但当我把它粘到项目里跑起来问题就来了没有处理页面加载超时的情况没有处理元素不存在的情况也没有考虑请求频率限制的问题。第一个页面抓完就报错了。这就是我第一次真正感受到AI写代码的“上限”——它能给你一个60分、70分的初稿但绝对不会给你一个100分的成品。从60分到100分的这段路仍然需要你自己走完。1.2 我用了哪些AI工具一个人不可能把所有大模型都用一遍但我确实花了一些时间对比过主流方案。这里按类型分一下工具类型代表产品优点缺点适用场景通用大模型对话ChatGPT、Claude、通义千问、文心一言等能力强、上下文长、可以深度讨论方案生成质量不稳定不结合项目上下文方案讨论、复杂任务拆解、生成初稿IDE插件GitHub Copilot、通义灵码、CodeGeeX、Fitten Code等集成在编辑器补全丝滑结合已有代码不会主动询问需求依赖光标位置推断日常开发中的代码补全和快速实现AI原生IDE/智能体Cursor、Windsurf等理解整个项目结构可跨文件修改越智能越要约束容易“自作主张”跨文件重构、全局搜索、复杂修改第一类通用大模型对话产品的优点是能力全面、上下文长、可以处理很复杂的对话而且不局限于代码——你可以在同一个对话里先讨论技术方案再让它实现代码。缺点是生成质量不稳定同一个问题问十次可能有十种不同的写法而且不会主动结合你的项目上下文。到我写这篇文章的时候这类工具依然是大多数人接触AI编程的入口。第二类IDE插件的好处是能读取你当前打开的代码文件结合上下文给出补全建议使用体验非常丝滑。缺点是你得学会“顺着它的想法走”——它不会主动问你需求而是根据你光标的位置和已有代码推断你想写什么。如果你自己思路不清晰它给出的东西大概率也不对。第三类比较专业的AI编程智能体能理解整个项目结构可以跨文件进行修改甚至可以执行命令、跑测试、根据错误信息自动调整代码。听起来很理想对吧但说实话我用了之后最大的感受是越智能的工具越需要你把它框在正确的范围内否则它会“自作主张”做一些你完全没让它做的事。我自己在实际项目中是“混搭”状态日常开发用IDE插件做补全遇到不熟悉的技术栈或者需要从零构思方案时去通用大模型对话产品里先聊清楚思路遇到复杂的跨文件改代码场景才会打开AI原生IDE。这个组合不能说最优但至少对我是最顺手的。1.3 先想清楚AI写代码到底能替代什么在我们深入实操之前我想先把预期管理这件事聊透。很多人对AI写代码抱有不切实际的幻想以为输入一句话就能得到一个完整的、可以直接上生产环境的系统。坦率地说以我目前的体验来看这个目标还远远没实现。对现在的AI编程工具比较准确的定位是“高级结对编程助手”——它可以帮你写大量样板代码、生成算法原型、翻译老代码、补测试用例、解释报错信息但在关键逻辑决策、架构设计、性能调优、安全审查这些环节它依然需要人类来做最终决定。我的经验是AI在以下场景里表现是最好的生成工具类代码正则表达式、日期处理、字符串转换、文件操作写单元测试给它一个函数它能生成比较规范的测试用例生成模板代码CRUD接口、前端表单、配置文件、Dockerfile解释陌生代码把一个开源项目里看不懂的模块丢给它让它讲清楚逻辑跨语言翻译把Python代码翻译成Java或者Go它能做到八九不离十而它表现不太好的场景是理解复杂的业务规则比如涉及多表关联、状态机流转、权限控制的业务逻辑保证代码安全性它不知道你的密钥怎么管理、接口怎么限流做性能优化它能给你一个能跑的版本但未必是能扛住高并发的版本处理模糊需求你自己都说不清楚要什么它给你的代码大概率也是模糊的想明白这些就能更好地理解后面要讲的内容——提示词工程为什么会成为关键实操中哪些环节需要人工介入。2. 提示词工程决定AI写代码上限的关键2.1 一句话需求直接翻车好现在进入正题。先说一个我刚接触AI写代码时踩过的大坑提示词写得过于简单。我第一次给AI的任务描述是“帮我写一个爬虫”。就这么一句话。它倒也挺痛快唰唰写了一段requests加BeautifulSoup的经典代码放在一个标准静态网页上确实能跑。但我那个场景根本用不了——页面是JS动态渲染的代码里连Selenium的影子都没有。为什么会这样回想一下大模型的原理你就能理解了。大模型本质上是在做“下一个词元的最大概率预测”——当你给它“帮我写一个爬虫”这么短的输入时它只能基于训练数据里最常见的“爬虫长什么样”来输出。训练数据里最常见的是requests加BeautifulSoup的教科书式爬虫所以它就输出了这个。它没有能力追问你“目标网站是什么结构用什么语言要不要处理反爬数据存到哪里”后来我把需求描述改成了一段两百字的详细说明把目标网站类型、渲染方式、需要的字段、保存格式、运行环境都写了进去结果生成的代码质量完全不同。这个转变就是我理解提示词工程重要性的开始。2.2 三要素提示词框架经过反复测试我把一个高质量的编程提示词拆成了三个核心要素。角色设定。让AI知道它现在是什么身份。同样一个问题你说“帮我写一段代码”和“你是一名有十年经验的高级Python工程师帮我写一段代码”AI生成的质量是完全不同的。因为角色设定会影响它接下来选择的知识领域和代码风格。任务描述。这是最核心的部分要把需求说清楚、说完整。一个比较实用的标准是给AI足够的信息完成一个“不追问也能直接动手”的任务。如果AI还需要问你“数据格式是什么”“运行环境是什么”“有没有异常处理要求”说明任务描述还不够详细。约束条件。把“不要做什么”和“必须做什么”明确列出来。常见约束包括语言和框架版本、代码风格、性能要求、依赖限制、输入输出格式、边界情况处理。约束条件越清晰AI生成代码的偏差就越小。我把自己常用的提示词框架整理成了一个模板这里分享出来你是一名具有[具体年限]经验的[语言/技术方向]高级工程师。 任务目标[用一两句话清楚描述要完成什么] - 功能点1[具体描述] - 功能点2[具体描述] - 功能点3[具体描述] 约束条件 - 开发语言[语言及版本] - 依赖框架[框架及版本] - 运行环境[操作系统/容器环境/浏览器版本等] - 代码规范[命名风格/注释要求/是否允许第三方库] - 边界处理[对异常输入、超时、数据缺失的处理要求] - 输出形式[代码片段/完整文件/命令行工具/API接口] 补充背景[与任务相关的上下文信息如已有的数据格式、接口协议、调用关系等]这个模板看起来简单但你真正用它写出来的提示词会变得很长。每次多花这两分钟写提示词往往能节省后面半小时的调试时间。提示写提示词时最关键的判断标准是——把提示词给一个完全不熟悉你项目的同事看他能否仅凭这段文字直接开始编码如果不行说明信息还不够完整。2.3 一个完整的提示词样例我拿前面说的爬虫需求举一个例子。用这个模板写出的提示词大致是你是一名有五年经验的Python爬虫工程师熟悉Playwright和异步编程。任务目标实现一个爬虫脚本用于定时抓取某个行业网站的商品列表页面。使用Playwright的Chromium浏览器以无头模式运行自动处理页面JavaScript动态渲染等待商品数据加载完成解析商品名称、价格、规格参数、库存状态四个字段将抓取结果追加保存到本地的data.csv文件中UTF-8编码支持命令行参数指定最多抓取页数默认抓取全部约束条件开发语言Python 3.10仅使用Playwright和标准库不需要其他第三方依赖运行环境Linux服务器无显示器环境必须无头模式请求频率控制每次页面加载完成后至少等待3秒异常处理单页抓取失败时记录日志并跳过不能中断整个任务代码风格函数式模块化关键逻辑必须添加中文注释补充背景目标网站列表页的URL参数格式为/page/NN从1开始递增。每个商品条目位于class为“product-item”的div内。你看这个版本的提示词信息量比最初那句“帮我写一个爬虫”大了几十倍。AI有了这些信息生成出来的代码才真正贴合实际需求。当然没有提示词模板是万能的这个模板也需要根据具体场景调整。比如写前端组件时我会在补充背景里加上设计稿描述和组件库API文档写算法题时我会在约束条件里加上时间复杂度和空间复杂度的上限写测试用例时我会在任务描述里明确要求覆盖正常路径和异常路径。2.4 迭代式对话让AI逐步优化代码提示词工程还有一个容易被忽略的重要技巧不要指望一次对话就拿到完美代码要学会迭代。我见过很多人让AI生成了一版代码跑起来报错就直接把AI工具关掉了然后说“AI写代码不靠谱”。这里有个认知误区——如果当年你在Stack Overflow上搜到一个回答代码复制下来直接报错你也不会从此不用Stack Overflow吧你会把报错信息贴回去你会根据评论区补充条件你会调整几版直到能跑。和AI协作也是一样的道理。我的实践方法是先让AI生成第一版然后自己跑起来把运行结果或报错信息原样复制粘贴回去告诉AI“运行时报了这个错误”它会根据报错信息修正代码。这个过程可以反复多轮每一轮它都在更接近正确结果。举一个我在实践中遇到的例子。让AI写一个日期区间处理的函数第一版代码看起来没问题但实际运行后发现当结束日期早于开始日期时函数返回了一个负数和错误的结果。我把这个异常场景描述给AI说“当end小于start时应该抛出ValueError异常”它很快就修正了代码。迭代式对话需要注意一个细节每一轮修改时最好把完整的代码片段而不是修改的部分发给AI。因为对话的长度越长AI越容易忘记最初的上下文如果你只说“第124行改成xxx”它可能根本不知道第124行现在长什么样。3. 实操记录四个典型场景从零到落地讲完了思路我拿几个真实的实操场景来复盘。这些场景我都在本地项目里跑过你可以对照你自己的任务类型参考。3.1 场景一用AI生成Python爬虫脚本这个场景其实就是文章开头说的那个需求。我最终通过“提示词模板加迭代对话”的方式拿到了一个能用的版本。第一轮生成的代码结构说实话让我有点惊喜。AI根据提示词里的信息自动选择了Playwright的async API来写主逻辑用asyncio做并发控制明确地把页面加载和DOM解析分成了两个模块。但是运行第一遍的时候连续踩了三个问题。第一个问题是元素定位。AI根据“class为product-item的div”这个信息生成了page.locator(div.product-item)的定位代码。结果实际页面上商品列表被包在一个外层容器里部分商品条目有嵌套的product-item结构导致重复解析。我通过把单个商品的HTML片段复制给AI看它改用了一层更精确的XPath定位问题解决。第二个问题是页面等待。AI默认用了固定等待page.wait_for_timeout(3000)来等待动态数据加载。这个方法虽然能跑但效率很差——网络好的时候白等3秒网络差的时候3秒可能还不够。我把这个情况反馈给AI它改成了显式等待也就是用page.wait_for_selector(div.product-item)来等待商品元素出现同时保留了一个超时兜底。第三个问题是反爬。目标网站会在连续请求二十多次后返回一个验证码页面。AI生成的代码没有处理这种情况我补充说“检测到验证码页面时暂停30秒后重试当前页”它很快就加上了对应的逻辑。经过四轮迭代最终版本的脚本在本地跑了三次一共抓了两百多个商品没有任何缺失字段耗时从最初手动写预计的四个小时缩短到了实际一个半小时左右。这个时间包括我写提示词、调试和迭代的时间。说实话对于这种模板性质的爬虫任务AI的效率优势非常明显。3.2 场景二用AI排查一个异步Bug第二个场景有点不一样不是让AI从零写代码而是让AI帮我排查一个困扰了我很久的前端问题。问题是这样的一个Vue 3项目里某个按钮点完之后需要依次执行三个异步操作然后再刷新页面数据。我写的代码逻辑是const fetchData async () { const a await api.getA(); const b await api.getB(); const c await api.getC(); rows.value [a, b, c]; }预期是等三个请求都完成之后再把数据赋给rows。但实际运行结果是界面上的数据永远是空的直到我再次触发其他操作时数据才出现。我一开始的定位思路是看接口是否返回了正确数据结果发现接口没问题是赋值时机不对。我怀疑是异步执行顺序的问题但找不到具体原因。我把这段代码丢给AI附上说明“这个组件在页面加载后数据为空的Bug一直无法复现但触发某个按钮后就正常了”。AI在分析后提出一个我之前完全没想过的突破口——它建议我检查这个fetchData函数是否在组件的onMounted生命周期中被调用了以及父组件是否会因为某个响应式数据变化而重新创建子组件导致早期的赋值被覆盖。顺着这个思路我发现问题的根本原因这个组件被一个v-if包裹父组件在某个异步回调里改变了数据源导致整个组件被销毁重建重建后的组件重新执行了初始化流程但此时接口还没有数据返回于是rows被赋成了空值。排查到这里修复方案就非常简单了把对rows的赋值放在接口调用结果的后续处理中同时给组件加上一个数据源变化时重新拉取的监听。AI虽然没有直接替我写出这个修复但它在排查方向上提供了非常关键的一条线索。这种“用AI加速问题定位”的场景我个人觉得比让AI写一段全新代码的价值更大。3.3 场景三用AI生成前端组件第三个场景是给内部后台系统写一个通用的数据看板卡片组件。这个需求本来不难但是因为有明确的设计规范、交互细节和框架约束写起来挺啰嗦的。我的提示词大致是这样写的你是一名有三年经验的Vue前端开发工程师。任务目标是基于Vue 3和Element Plus实现一个统计卡片组件CardItem.vue。组件接收标题、数值、图标、是否显示环比、环比变化率等props数值在1.5秒内从0动画递增到目标值环比为正时显示绿色上升箭头为负时显示红色下降箭头组件不引入额外依赖使用Element Plus的Icon和Tooltip组件约束条件使用Composition API按script setup语法编写样式使用scoped遵循项目的设计规范主色#316CFFprops需要定义类型和默认值代码中添加简单注释AI生成的代码直接运行就能用。动画用的是requestAnimationFrame实现的数字递增环比判断的逻辑也完全符合要求。对比我自己手写的话大概是十分钟可以写完AI生成加人工检查大概花了两分钟。这类模板化组件的需求我认为AI已经达到了“可以直接接手”的水平。当然我也检查了几处细节props的命名规范是否匹配项目约定、动画逻辑是否会频繁创建定时器导致性能问题、依赖的Icon组件在Element Plus中是否真的存在。这些检查花了大约五分钟但我认为这是绝对必要的——AI生成的代码在使用前必须经过人工审查。3.4 场景四让AI补单元测试最后一个场景是最让我惊艳的。我给AI一个自己写的工具函数——一个把时间戳格式化为“xx分钟前/xx小时前/xx天前”的函数——让它生成单元测试用例。AI生成的测试代码覆盖了正常时间戳、当前时间附近的时间边界、未来时间戳、负数时间戳、极端老的时间戳、非法输入NaN、null、undefined、字符串等场景总共15个测试用例运行后全部通过。说实话我自己手写时大概率只会写五六个“happy path”用例因为潜意识里会偷懒觉得自己的代码自己测试差不多就行。AI完全没有这种心理负担它可以非常机械地把所有边界情况都列一遍。这个场景给我一个很大的启发AI写代码的最适合场景不一定是“从零写一个新功能”也可能是“承担项目里那些重复度高、但非常重要且耗时的任务”比如补测试、写注释、整理配置文件。这些活不显眼但做好了整个项目的质量都会提升。4. 常见问题与排查技巧实录这一章是我觉得最值钱的干货。AI写代码的实际使用中你会遇到各种奇奇怪怪的问题。我把高频踩坑的情况整理成了一个速查表并且给你说一些通用排查思路。问题典型现象排查思路解决建议代码能跑但结果不对程序不报错但输出错误对照业务语义逐行审查逻辑构造边界用例在提示词中补充业务规则和边界条件AI幻觉引用了不存在的API或方法去官方文档核对API签名让AI解释逻辑重要API人工验证优先选流行稳定框架上下文丢失对话后期AI忘记最初需求观察AI是否推翻之前的结论一段对话只解决一个问题新开对话贴上下文安全合规敏感信息泄露风险检查提交到在线工具的内容本地部署离线模型代码脱敏处理强制代码审查4.1 代码能跑但结果不对这是最让人头疼的一类问题——代码不报错、能运行、但结果就是不对。我遇到过一个典型案例让AI写一个数组去重排序的工具函数它给了一个用Set去重的代码看起来天衣无缝但在跑数据的时候出现了问题。原因在于JS的数组元素既有数字也有字符串比如[12, 12, 3, 3]Set认为它们是不同的元素所以去重之后“12”和12都在。AI默认假设的是“元素严格相等才是同一个”而业务需求是“类型不同但值相同也要去重”。这类“代码能跑但结果不对”的问题根源通常是AI对你的业务语义理解不够深。排查思路分两步第一步把AI生成的代码核心逻辑通读一遍确认每一步在做什么脑子过一遍就知道大概哪里不对。第二步构造几个包含边界条件的测试用例把AI代码的输出和预期结果对比快速锁定偏差位置。如果你有一个边界条件没测就不要假设AI会帮你处理它。写进提示词的约束条件里有AI才有可能处理没写的大概率依赖训练经验默认处理。4.2 AI幻觉看似正确实则错误的代码AI幻觉是大模型的一个通病在写代码场景里的表现就是它给你的代码里引用了不存在的函数、库或API方法但代码看起来非常自然不熟悉的人根本看不出问题。举个例子。我曾经让AI写一段用某云服务的Python SDK上传文件的代码它生成的时候引用了一个对象方法我用编辑器提示查了一下发现那个方法根本不存在于该SDK的最新版本中。AI在训练数据里见过这个方法的旧版本但版本已经更新了它没有实时联网能力于是错误地复用了一个已废弃的API。应对AI幻觉有几个办法。第一针对你准备使用的重要API去官方文档确认它当前的真实签名和用法不要直接信任AI生成的调用方式。第二让AI给出代码逻辑的解释它如果能讲清楚每一步的作用说明它对这段代码是有真实理解的如果解释得含糊不清那它大概率是在“编”。第三在可以的情况下尽量选择流行框架或较稳定的API因为AI对这些知识的掌握更加可靠。4.3 上下文丢失长对话后AI开始“失忆”用过AI对话产品的朋友应该都有这种感觉对话越到后面AI越容易“忘事儿”。我和AI连续讨论一个复杂模块的时候到了第五六轮它有时会忘记最初的需求甚至推翻了之前已经确认的方案。大模型的上下文机制决定了它只能记住有限的信息超出限制之后较早的内容会被“挤”出去。所以我的经验是一段对话只解决一个问题。比如今天你要让AI生成一个爬虫就只聊爬虫的事不要中间又插一句“顺便帮我写个正则”。如果你确实有多个不相关的问题宁可新开对话重新贴上下文也不要混在一个对话里。另外还有一个容易被忽视的细节当你把项目代码复制给AI的时候最好把相关的文件结构、依赖环境也一起说清楚不要只说“我有个模块报错”。信息越完整AI给出的回答越准确也越不容易在后续对话中产生偏差。4.4 安全认知哪些内容不能直接交给AI我要特别提醒一个事情线上环境的敏感代码、真实密钥、数据库连接串这类信息绝对不要随手就粘贴到在线的AI工具里。因为一旦出了泄露问题责任在你自己。而且现在很多企业和团队对代码管理、数据加密都是有一定审计要求的。我个人的习惯是在本地搭一套可离线运行的模型来专门处理一些涉及内部业务的代码分析需求日常一些不敏感的工具代码、算法片段再放到在线大模型里讨论。如果你手头没有离线模型的条件至少要做到给AI的内容先做脱敏处理把真实的密钥替换成占位符把数据库表名和字段名改成无关名称然后再用来讨论逻辑。注意AI生成的代码进入生产环境之前必须走正常的人工代码审查流程。这是一个底线不是建议。审查重点包括是否有不可控的外部调用、是否有不安全的反序列化操作、是否在未授权情况下访问了敏感数据、是否依赖了来源不明的第三方库。5. 一些额外的经验与延伸思考5.1 AI写代码的能力边界我现在的判断用了一段时间之后我形成了一个大致的判断AI在“脚手架级”的代码任务上已经非常可靠但在“大脑级”的代码任务上还差得远。什么是脚手架级就是那些有清晰规则、输入输出明确、逻辑相对简单的代码比如CRUD接口、数据转换、正则、脚本工具、UI组件、配置文件。这些任务本质上是规则套路的组合AI的识别和重组能力很强生成的代码质量已经接近甚至超过初级工程师的水平。什么是大脑级就是需要架构设计、复杂状态管理、跨模块协调、性能权衡、安全防护、未知问题探索的代码。这些任务需要的不只是“知道规则”还需要对系统整体有深刻的理解对业务目标有准确的判断。AI在这些场景里目前只能当参谋——拿不定主意时可以参考但拍板还得靠人。5.2 给新手的几条实操建议如果你正准备开始尝试AI写代码我觉得下面几条经验对你会有用。第一从小的、具体的、可验证的任务开始。不要一开始就妄想用AI写一个完整的系统。先让AI写一个独立函数、一个脚本、一个小工具跑通了再逐渐扩大范围。在第一阶段你最重要的是建立对AI输出质量的直观感受——它什么时候靠谱、什么时候离谱错误集中在哪些地方。这种“感觉”比什么教程都管用。第二任何AI生成的代码都必须经过人工阅读和审查。我见过不少初学者把AI生成的代码粘进去跑通一次就直接提交结果后面线上出问题都说不清楚。至少要看懂每一段AI代码的实现逻辑能解释它为什么这么做再决定是否使用。第三把项目经验和领域知识变成提示词素材。我自己维护了一个“提示词片段库”平时把常用的角色设定、约束条件、模板片段记录下来需要的时候直接复用。随着这个库越来越大我写提示词的效率也越来越高AI生成代码的准确率也明显提升。第四不要被“AI取代程序员”这类话题干扰。工具永远是工具关键看你怎么用。能熟练使用AI辅助编程的人和不会用AI的人工作方式和效率确实会有区别但这不等于“会AI的人不再需要编程能力”。恰恰相反编程功底越扎实的人越容易判断AI生成代码的质量越能用好AI。5.3 后续可以怎么扩展玩法AI写代码这件事本身就像滚雪球越用越有心得。我目前比较感兴趣的几个方向是第一用AI自动生成接口文档和注释减少项目维护成本第二让AI根据错误日志自动生成问题描述和解决方案建议相当于给团队配一个“自动答疑助手”第三探索多个AI工具协作的模式比如让一个模型负责方案设计、另一个模型负责代码审查把AI当团队用而不是当打字机用。另外想强调一下AI写代码并不是银弹。在不同的项目、不同的技术栈、不同的团队协作模式下它的表现会有很大差异。我鼓励大家在实践中逐渐找到自己的节奏不迷信、不抗拒把它当成一个真正好用的工具来看待。写到这儿我想起那次周五晚上真正把爬虫跑通之后我坐在工位上对着屏幕发了一会儿呆。AI写出来的代码并不完美我改了很多地方但几个小时出稿这件事换在一年前几乎不可能。那次尝试给我的启发是AI不会替你成为程序员但它确实能帮你把更多时间留给真正重要的事情。如果你还没认真试过AI写代码建议从一个小任务开始给它一次机会也是给自己一次机会。我个人在这段时间最大的体会是——用AI写代码这件事最需要的不是高超的技术而是一个谦虚的心态承认AI能比你快也要承认AI不懂你的业务既要会指挥它也要会控制它。