前一阵我给自己定了个小目标逼自己连续两周把所有能交给AI的琐碎编码任务全部用AI写代码来完成。这两周下来网上一堆“AI马上要取代程序员”的说法我基本确定是吓唬人的但另一句话我认“AI能让普通开发者的日常效率翻倍”是真的。这篇就是这个系列的第一篇记录不聊虚的从选型、提示词、调试到改代码完整走一遍AI辅助编程的真实流程把我踩过的坑全摊开说。适合正在犹豫要不要把AI纳入工作流的开发、测试和运维朋友也适合想入门的同学先看看这条路到底长什么样。1. 内容整体设计与思路拆解1.1 为什么突然想试“AI 写代码”作为一个常年和业务系统打交道的开发者我手头真正让我头疼的往往不是那种需要啃三个月的核心架构而是一堆“食之无味、弃之可惜”的琐碎脚本写个临时数据清洗、做一个批量文件重命名、给测试环境造一批假数据、把一段老的Python逻辑翻译成Java。这些事情有个共同特点不复杂但很磨人。以前我都是自己动手一写就是半小时起步中间还要反复查文档。后来看身边同事开始用AI生成代码我也动了心思。我的想法很简单不指望AI帮我想清楚业务架构只要它能把这些一次性脚本的活接下来把常规DTO、工具类、正则、SQL映射这些“体力活”搞定就已经值回票价了。所以这个系列的第一篇我刻意选了一个非常小的真实任务来试水。任务越小越能看清楚AI的稳定性和边界在哪也方便记录从需求到落地的完整链路。1.2 选型通用大模型还是垂直编程工具开始尝试前我先给自己列了个选型清单。市面上可选的方案大致分成两类一类是通用大模型比如Claude、GPT系列通过网页或API对话来获取代码另一类是编辑器里的AI编程插件比如GitHub Copilot、通义灵码、CodeGeeX、Fitten Code这类直接在IDE里做补全和对话。我的第一反应是“小孩子才做选择我全都要”。但实际用了几天后发现两类工具解决的是完全不同的问题得按场景分配。类型典型工具优势短板通用大模型Claude、GPT系列上下文理解强能处理长对话和复杂需求拆解要手动复制粘贴代码离编辑器远编辑器补全GitHub Copilot和写码节奏无缝衔接注释转代码体验好大段生成容易放飞自我编辑器对话通义灵码、Fitten Code、Cursor能直接选中代码片段提问边写边改方案完整性弱于通用大模型终端AgentCodex、Claude Code类能自己跑命令、改文件接近“AI替你干活”翻车时定位成本高如果你刚开始接触AI写代码我的建议是先别急着买付费工具。通用大模型免费额度足够跑完第一个任务编辑器插件也有一批免费可选的先用最便宜的方案把流程跑通了再考虑付费工具是否值得。1.3 谁适合用“AI 写代码”谁暂时别碰两周试下来我对适合场景有比较清晰的判断。先说适合的写一次性脚本、做原型验证、跨语言翻译、生成单元测试、解释老代码逻辑、写正则和SQL这类“模式化”产物。这些任务边界清晰、验收标准明确AI生成的代码即使有小问题也容易通过测试暴露出来。不适合的也要说清楚涉及复杂业务约束的系统核心模块比如订单状态机、资金计算、权限控制安全敏感代码比如鉴权逻辑、加密解密以及那些需要大量隐性上下文才能动手的模块AI看不到你们的内部设计文档硬让它写它只能编一个看起来很合理但实际不合规的版本。我踩过一个很典型的坑让AI生成一段访问内部服务接口的代码它给我写了一个自以为很标准的OAuth2流程结果我们内部用的其实是签名机制两边完全对不上。所以我的原则是AI可以用来写骨架但涉及内部规范的部分人工必须牢牢把关。1.4 “AI 写代码”的三个老大难先打预防针两周前我对AI写代码的印象停留在“它挺能写”。两周后我对它的评价变成了“它能写但有三件事你必须提前心里有数”。第一件事AI生成的代码经常是“看起来对跑起来错”。这个错还不是语法错而是逻辑边界错数组越界、空指针、时区问题、编码问题全是跑起来才暴露的。第二件事AI非常自信地给你一个完全错误的方向尤其在你描述不清楚的时候它会顺着你话里的漏洞编一个自洽但错误的方案。第三件事上下文一长它就会“失忆”你让它改完A再改B它很可能把A给忘了。这三个问题不是AI厂商能靠更新模型解决的而是AI写代码本身的结构性问题。所以我的应对方式很固定小步验证、代码审查、问题不断抛回给它。后面每个部分都会围绕这三件事展开。2. 核心细节解析与实操要点2.1 AI 写代码的能力边界到底在哪里想用好AI写代码第一步不是学提示词而是搞清楚它到底擅长什么。我的体感是AI本质上是一个“见过无数代码模式的超级检索器”它对常见场景的“套路”非常熟练但对“你这家公司的特殊约定”一无所知。比如生成一段从Excel里读取数据并生成SQL插入语句的脚本这种事网上有海量资料AI能写得非常像样。但如果让它写一段对接你们内部统一登录、带特定埋点、带降级开关的接口代码它大概率会写得四不像。这就像你请了一个见过很多世面的外包工程师但它从来没进过你们公司。它能帮你把通用部分做得又快又好但公司内部特定的部分你得自己做或者仔细教它。所以我后续的所有实操都是把任务拆分之后只把“通用套路”部分丢给AI内部定制部分自己动手改编。2.2 提示词才是真正的“生产力”网上很多人说“AI写代码不行”我看了下他们的提问方式普遍是把需求说得非常模糊“给我写个爬虫”“做个管理系统”。这种问法AI只能给你一个泛泛的模板离可用差得远。问题的关键不在AI而在提示词。我后来把提示词固化成了一个模板核心就四块角色定义、任务描述、约束条件、输出格式。拿我第一周做的一个文件分类脚本举例我的提示词是这样的你是一名Python开发工程师。请编写一个Python脚本功能是把指定目录下的文件按扩展名分类移动到对应的子文件夹中。 要求 1. 只处理普通文件不处理子目录 2. 目标子文件夹不存在时自动创建命名格式为“{扩展名}_files” 3. 如果目标位置已有同名文件自动在文件名后加 _1、_2 编号不能覆盖 4. 每移动一个文件都打印一条日志 5. 支持命令行参数传入目录路径不传则默认当前目录 6. 编码使用UTF-8兼容Windows和Linux 请输出完整可直接运行的代码不要给解释。你会发现这个提示词里几乎没有废话全是AI做决策需要的信息。特别是“不能覆盖”、“兼容Windows和Linux”这种边界约束你不说AI百分之百不会主动想到。还有一个技巧值得单独说如果需求复杂不要期望一个提示词搞定。你先让AI生成主体框架然后针对框架里你不满意的地方一条一条追加修改要求。比如第一次生成完我发现它没处理目录本身权限不足的情况我就追加一句“分类移动时请捕获权限异常并给出清晰报错”它很快就能补上。2.3 “AI 生成 ≠ 可用”代码审查时间不能省这两周我最大的进步是养成了一种“AI代码审查强迫症”。AI写出来的代码我永远不会直接复制到项目里就跑一定会花一两分钟通读一遍重点看几个地方。第一是边界条件。稍微有点经验的AI会处理空列表、空目录但很多AI想不到“目标文件已存在”这种现实冲突或者“文件名包含特殊字符”的情况。第二是异常处理AI默认写出的代码往往是没有try/except的一旦遇到权限问题、网络超时整个程序就会崩。第三是资源释放尤其是涉及文件读写、数据库连接、网络请求的操作AI偶尔会漏掉close或with上下文管理。我把这个审查流程总结成了一张自查清单贴在终端旁边入参校验做了吗、异常分支处理了吗、资源释放了吗、有没有硬编码绝对路径、会不会误删文件、类型转换有没有隐患。每一条都对着过一遍。如果你觉得自己不会审查最简单的办法是让AI自己审查把代码发给它问“这段代码有哪些潜在问题”它一般能找出七八成问题剩下的还是靠经验。2.4 小步快跑别让 AI 一口气建系统我一开始犯过一个典型的错误让AI一次性生成一个带数据库、带接口、带前端页面的完整小系统。结果AI输出了一大坨代码我自己看都看不完更别说验证哪个部分有问题。项目毫无悬念地卡住了三个小时最后我全部删掉重来。后来我总结出一条铁律每次只让AI完成一个可运行、可验证的小步骤。比如做一个小系统我会拆成“先生成数据库表结构”“再写数据访问层”“再写一个查询接口”“最后写一个简单页面”。每个步骤之间我亲手把它跑通再让AI做下一步。这个策略和模块化开发很像但更严格。因为AI的生成是基于概率的步骤越少、目标越明确它猜中你心思的概率越高。一旦中间隔了好几层上下文它就会开始自由发挥。小步快跑还有一个好处出错时你能迅速定位是哪一步的提示词写得不好修正成本极低。与其花半小时懊恼AI为什么不听话不如花十秒钟把任务拆小再喂一次。3. 实操过程与核心环节实现3.1 第一个完整任务批量整理文件夹脚本前面说了半天思路这里进入完整实操。我的第一个任务是写一个Python脚本把下载文件夹里乱七八糟的文件按扩展名分类到对应子文件夹。为什么选这个任务因为它边界清晰、涉及文件操作和异常处理、还能直观看到AI写的代码在真实环境下跑得怎么样。需求我先在文档里定清楚再翻译成提示词。注意我在需求定义阶段就做了取舍“只做文件分类移动不做重复文件清理不做内容识别”。别让AI去猜你没写清楚的需求宁可自己先拆好也不要让它自由发挥。然后我把这段需求连同格式要求一起发给AI得到了一版完整代码。下面是我简化后的产物它基本做到了“能跑”但离“好用”还有距离。import os import shutil import sys from collections import defaultdict def classify_files(directory.): if not os.path.isdir(directory): print(f目录不存在: {directory}) return ext_map defaultdict(list) for entry in os.listdir(directory): full_path os.path.join(directory, entry) if os.path.isfile(full_path): ext os.path.splitext(entry)[1].lower().lstrip(.) or noext ext_map[ext].append((entry, full_path)) for ext, files in ext_map.items(): target_dir os.path.join(directory, ext _files) os.makedirs(target_dir, exist_okTrue) for name, full_path in files: dest os.path.join(target_dir, name) if os.path.exists(dest): base, extname os.path.splitext(name) counter 1 while os.path.exists(os.path.join(target_dir, f{base}_{counter}{extname})): counter 1 dest os.path.join(target_dir, f{base}_{counter}{extname}) shutil.move(full_path, dest) print(f已移动: {name} - {os.path.basename(dest)}) if __name__ __main__: target sys.argv[1] if len(sys.argv) 1 else . classify_files(target)平心而论第一版生成到这个程度我是满意的。它用了defaultdict做分组用os.makedirs的exist_ok避免重复创建还处理了同名冲突的问题。这些都是网上常见写法AI抓得很准。3.2 踩坑与调试和 AI 来回拉扯的过程代码生成只是开始后面才是真正见功夫的地方。我把它保存成organize_files.py在测试目录里扔了一堆假文件跑了一遍第一次运行就暴露了三个问题。第一个问题是日志信息有误导性。它打印的是已移动: 文件名 - 文件名但目标路径只显示文件名不带子目录我看日志根本不知道文件被移到了哪里。这不算严重但确实影响使用体感。第二个问题是编码问题。在Windows的cmd窗口下中文日志直接报UnicodeEncodeError程序跑到一半就崩了。这其实不是AI的代码逻辑错而是运行环境编码不匹配但它没做任何兼容处理。第三个问题是权限异常完全没考虑如果某个文件被占用或没有权限程序直接抛异常退出后面的文件也没处理完。发现问题后我并没有自己动手改而是把报错信息原样贴回给AI又加了一句要求脚本在Windows下运行时中文日志报UnicodeEncodeError请修复编码兼容问题。另外请给每个文件的移动操作加上异常捕获单个文件失败不能影响其他文件继续处理。日志请改成已移动: 原文件名 - 目标子目录/新文件名。AI很快返回了修订版本。它在文件头加了sys.stdout.reconfigure(encodingutf-8)用try/except包裹了shutil.move还完善了日志里的目标路径。这里我想提醒一句你给AI反馈错误时一定要把完整报错信息、运行环境、期望行为三点写清楚缺一个它就可能瞎猜。这也是AI写代码场景里最实用的提示词技巧。3.3 我的改造脚本从“能跑”到“好用”AI的修订版跑通了但我作为一个经常收拾烂摊子的开发者觉得这个脚本还差最后几步才算“好用”。这一步我选择自己动手因为下面这些东西属于个人使用习惯AI猜不到也不应该瞎猜。我加了三个功能。第一个是--dry-run参数执行时只打印将要做什么不真正移动文件。这很重要任何涉及批量移动、删除的操作我都建议先有个演练模式防止手滑。第二个是日志同时输出到控制台和文件方便排查“前天跑的脚本到底把文件弄哪儿去了”。第三个是移动完成后统计每个分类的文件数量让我心里有数。改造后的主体逻辑没变但可靠性和可用性提升了一个档次。这恰好也是我想表达的观点AI写代码是帮你把80%的重复工作做掉剩下20%的个性化打磨恰恰是体现工程师经验的地方也是你不可替代的地方。3.4 实际耗时就记一笔这个任务如果我自己从头写大概需要30分钟到40分钟其中一半时间花在回忆os模块和shutil的API细节上。用AI辅助之后整个流程耗时的分布是这样的写需求定义和提示词花了大约8分钟等AI生成、审查、修改花了15分钟我自己做个性化改造花了10分钟。总计约35分钟。注意总时间其实没有显著缩短。但区别在于以前是我一个人花40分钟纯写代码现在是AI负责输出主体我负责审查和决策。这种工作方式的转变在简单任务上体现得不够明显一旦任务变成“生成100个DTO”“把200行老代码翻译成另一种语言”AI带来的效率红利就会非常夸张。这也是我坚持用AI的原因它不是省掉你的时间而是让你把时间花在更有价值的事情上。前面这段实操走完我对AI写代码的第一印象已经从“玩具”变成了“趁手工具”。但紧接着我就遇到了一堆奇奇怪怪的问题有的来自AI有的来自编辑器环境。接下来把这两周遇到的高频问题集中整理一下。4. 常见问题与排查技巧实录4.1 “VSCode 写 C 没有代码提示”是怎么回事我知道很多人搜热词时都遇到过一个场景装了AI插件但在VSCode里写C/C代码发现代码提示没了。这个问题的锅一半在编辑器配置一半在环境依赖还真不能全赖AI。C/C的语言代码提示依赖C/C扩展和编译器的配合。你如果单纯装了AI补全插件它只能做“续写”没法做“基于编译器上下文的智能提示”。排查思路按下面顺序来先确认装了微软官方的C/C扩展再看项目里有没有tasks.json和c_cpp_properties.json没有就找插件自动生成然后检查编译器路径配没配好Windows下常见的是Mingw没进PATH。把这些配置理清之后再用AI插件补全两边就不会打架了。这里有一个很容易踩的坑AI补全插件默认可能会和VSCode自带的tab补全快捷键冲突。我实际遇到的情况是按Tab想接受AI补全结果触发的是编辑器的默认代码片段比如自动补了/。解决方法是到快捷键设置里把“接受AI建议”的快捷键改一下或者把编辑器的tab-completion关掉两者留一个。4.2 AI 修不好自己的 bug怎么把错误信息喂给它用AI写代码最让人血压升高的场景是你把报错信息贴给AI它改了一次还是错再改一次更离谱第三次直接给你一个风格完全不同的新方案。遇到这种情况我现在的处理方式很固定停止无脑追问把“错误现场”整理成一小段结构化的问题描述。高效的问题描述包含四部分第一我想干什么背景一句话说清楚第二我做了什么操作最好是可复现的最小步骤第三完整报错信息原样贴出不要自己概括“报错了”你概括得越狠AI错得越远第四我期望的结果和实际结果的差异。照这个模板写AI的修复成功率至少提高一半。如果这样改了三次还不行我的建议是直接换个对话重新生成。AI在同一个对话里反复修同一个问题容易陷入“钻进死胡同”的状态它会为了迎合你上一条要求把前面本来对的东西改坏。新开对话把原需求加“已尝试的修复方式”重新描述一遍往往能跳出循环。4.3 上下文窗口太小大型项目怎么用 AI很多朋友会抱怨“AI写代码只能写玩具我们这种大项目它根本看不懂”。这个说法一半对。AI确实看不到你的完整工程它每次只能接触你丢给它的那一段提示词。但这不意味着大型项目不能用AI关键是把“项目级信息”塞进提示词里或者用“接口先行”的策略。我的做法是让AI产出某个模块的代码前先手工把相关的接口定义、数据结构、关键枚举压缩成一个“上下文小抄”贴在提示词最前面。AI不需要知道你们整个系统的来龙去脉它只需要知道你这次让它写的函数要接收什么、输出什么、依赖哪些类型。把这些信息喂给它它生成的代码就能和你项目里的现有代码衔接上。还有一个小技巧先用对话模型做设计再用编辑器插件做实现。我通常会在ChatGPT或Claude这类对话模型里把模块的整体设计、文件拆分、接口签名先讨论清楚然后把接口签名复制到编辑器里让补全插件挨个函数实现。这样既解决了上下文问题又让两代工具各用所长。4.4 AI 代码里的隐性安全问题这两周我特别留了一个心眼所有AI生成的代码过安全这一关。不是说不信任AI而是因为它见到的训练数据太杂经常不自觉地用一些“看起来简单但很危险”的写法。最常见的几个问题在这里集中说一下。第一个是执行系统命令时用了shellTrue比如用os.system拼接字符串如果中间夹了用户输入这就是命令注入点。第二个是处理文件路径时直接拼接字符串导致路径穿越比如用户传入../../就能把文件移到别的目录。第三个是反序列化或动态执行AI有时会为了“动态”用eval()或pickle处理不可信数据这在真实业务里是绝对不能出现的。我给自己定的审查红线就三条用户输入不能直接拼进系统命令文件路径操作必须用os.path.join并校验真实路径凡是AI代码里出现eval、exec、pickle一律标红重写。这三条算是最低要求再往上要根据具体业务场景做安全评审。4.5 问题速查表把这两周遇到的高频问题整理成一个速查表方便大家遇到类似情况直接定位。现象大概率原因解决动作AI生成的代码能跑但结果不对需求没写清边界约束补充输入输出示例让AI按例子对齐同一对话反复修不好AI陷入局部死循环新开对话重新描述需求编辑器代码提示失效语言服务和AI补全冲突检查扩展配置调整快捷键中文日志输出乱码或报错控制台编码不匹配重配stdout编码或设置环境变量AI用危险写法训练数据影响人工审查按红线规则重写生成代码和项目风格不搭缺少风格约束在提示词里加“参照XX文件风格”上下文一长就失忆窗口限制把关键信息压缩成上下文小抄这张表里的每一条我都真实踩过。尤其是“同一个对话反复修不好”和“上下文失忆”几乎是每个用AI写代码超过三天的人都会遇到的。提前有心理准备能少吃很多亏。5. 工具生态与工作流组合5.1 通用对话模型和编辑器插件分工完全不同前面操作和排查都聊完了再来横向说下工具生态。很多新手问“到底哪个AI写代码最强”我现在的观点可能有点泼冷水不存在最强只存在和你的工作流匹不匹配。通用对话模型和编辑器插件是两种物种千万别搞混。通用对话模型适合做“离线思考”你给它完整上下文它给你一大段设计方案或完整文件。它的优点是上下文窗口大、理解能力好能陪你推演需求。编辑器插件适合做“在线辅助”你在写函数时它给你补下一行你选中报错代码它给你解释。它的优点是快、顺手但视野很浅只盯着当前文件看。把这两者配合起来的典型姿势是先用通用对话模型把一个模块想清楚拿到可执行的整体方案然后回到编辑器里用插件一行行把方案落地。这就像你先和资历深的同事过一遍设计再回工位写代码效率自然高。滥用编辑器插件去问“帮我设计整个系统”得到的结果大概率是灾难。5.2 我实测过的几类方案一句话总结这两周我前后试了五六种工具这里不报参数不跑分只给个人感受。GitHub Copilot的补全体验还是最顺滑的但付费且对国内网络的依赖是个门槛Claude在长上下文和方案设计上很稳是我用来做整体设计的主力通义灵码这类国产插件胜在免费、上手快在IDE里用中文对话很自然Fitten Code在某些场景下补全速度很快作为轻量备选不错Codex这类付费编程工具我短测过一两次功能很强但对使用者的工程素养要求也高新手容易在花哨能力里迷失。需要特别说明的是我这些评价都是基于我自己的工作场景和网络环境仅供参考。工具迭代非常快两个月的口碑就可能反转选型的关键不是追新而是固定一套自己熟悉的工作流。工具是流动的方法论才是沉淀下来的资产。5.3 当前我的工作流组合经过两周折腾我目前固定下来的工作流是“三件套”开新任务先打开对话模型把需求和边界聊清楚拿到方案然后在编辑器里用补全插件把方案里的函数一个个实现实现完后把关键文件整段喂回对话模型让AI做一次代码评审重点挑边界问题和安全问题。这三步里我最重视的是最后一步——AI评审。散步时我在想人写代码会眼瞎AI写代码也会眼瞎但让两个“瞎”的互相看对方反而能找到更多盲点。哪怕AI的评审意见只有一半靠谱也相当于免费多了个结对工程师。这套组合不依赖任何单一付费工具如果中途哪个环节不好用了我可以随时替换。5.4 关于“AI Agent 替你写代码”的一点实测体会最后聊一下“AI Agent”。现在很多文章都在讲AI能自己开终端、自己改代码、自己跑测试听起来像是你只需要在旁边喝咖啡。我这个系列一开始也专门试了这个方向。实际体验是在非常封闭的沙箱环境里给一个非常明确的任务比如“让这个函数通过全部单测”Agent确实能完成但过程远没有宣传的那么丝滑。它经常会在两三个似是而非的方案之间来回横跳反复修改、反复跑失败吞掉大量时间。有一次我让它自己修复一个测试失败它在十分钟内换了三种解决思路最后一种还把本来通过的两个测试弄挂了。我的判断是这类Agent可以当“实习生”用在你的全程监督下帮你做批量操作和试错推导但别把它当成“无人驾驶”。至少现阶段把Agent的能力作为辅助手段嵌入现有流程比完全放手要靠谱得多。等Agent成熟了这个系列再回头更新对应的实践案例也不迟。每次实践往里走一步都会有新的细节冒出来。这次的经历告诉我用好AI写代码关键不在“让它写得更多”而在“让它更懂你要什么以及你更懂它能给什么”。把这个基础工作做扎实AI才会从玩具变成真正的生产力。