说句实话现在很多人对“AI编程”的感觉是两极分化的。一部分人觉得AI已经强到能替自己写整个项目另一部分人试了几次以后骂骂咧咧退回纯手写理由是“AI生成的代码根本不能用改它的功夫我自己都写完了”。我见过太多这样的例子本质问题不在AI能力而在大部分人把AI编程理解成了“在对话框里提需求、等代码、复制粘贴”这三步。真正拉开效率差距的是把AI嵌进一条完整的工作流里让它在需求分析、方案设计、编码、调试、Review 每一个环节都发挥正确的作用而不是把它当成一个偶尔灵光乍现的代码生成器。这篇文章我想聊的就是我从零搭建一套 AI 编程工作流的过程。不吹某个工具多神也不绕什么高深理论就讲我实际在项目里怎么设计这条流程、怎么选工具、怎么写提示词、怎么让AI少犯低级错误以及遇到坑以后怎么排查。内容适合正在用或者准备用 AI 辅助开发的人看不管你是独立开发者、刚入行的新人还是在团队里带项目的技术负责人应该都能从里面找到能直接抄走的思路。1. 先用流程思维理解AI编程而不是依赖“一句话魔法”1.1 为什么两个人用同一款AI工具效率差距那么大我经常被问到同一个问题别人说AI编程多好多好我用起来怎么跟人工智障一样后来我仔细观察过那些说“AI不好用”的人他们的典型操作是打开对话框输入“帮我写一个商城系统”然后期待屏幕上出现能直接上线的代码。这个期待本身就有问题。你现在让一个刚毕业的实习生去写商城系统也得先给他讲清楚业务范围、技术栈、数据库设计他才能动手。AI虽然读过大量代码但它不是一个全知全能的单体大脑它的工作方式更像一个知识面极广、沟通意愿极强、但工作记忆非常有限的结对工程师。如果你不给它清晰的边界、明确的验收标准、必要的项目上下文它就只能靠猜。AI一猜代码自然就跑偏。反观那些效率高的人他们做的事其实只有一件把原本模糊的想法拆成一系列AI可以理解和执行的子任务并且在每个节点都做好验证和纠正。这套拆解、执行、验证的过程就是我们说的“工作流”。同一款AI工具在懂流程的人手里是超级杠杆在不懂流程的人手里就是随机数生成器差别就是这么来的。1.2 一套合格的工作流要覆盖哪些环节从我的实践来看一条靠谱的AI编程工作流至少要有四个环节少了任何一个都会出问题。第一是需求定义。不管项目多小动手之前都要把“我要做什么、给谁用、在什么环境跑、有哪些约束”写清楚。这一步很多人觉得多余觉得脑子里有想法就够了。但AI没有读心术你脑子里想的是“一个轻量的内部工具”描述出来变成“帮我写个软件”它给你返回的很可能是一套企业级微服务骨架。第二是技术方案设计。拿到需求以后先让AI给你出方案而不是直接让它写代码。方案里应该包含模块划分、技术选型、数据结构设计、关键接口定义。这相当于施工图纸图纸没定就开始砌墙后面返工成本极高。第三是编码实现。这一步也不能把一整个需求一次性丢给AI要切成逻辑完整的子任务一次让AI只做一件事。每完成一个子任务你都要在本地跑一下、验证一下过了再进入下一个。这个过程有点像流水线作业每道工序都质检合格了最后组装出来的东西才靠谱。第四是审查与修复。AI写完代码不要直接信也不要直接改。先让它自己做一遍Code Review再结合你本地运行的结果让它修复。很多时候AI代码看起来逻辑没问题但一跑就报错这时候把完整报错信息贴回去让它进入“自我纠错循环”通常几轮下来就能稳定运行。这四个环节串起来AI编程才会从一个“碰运气”的行为变成一套“可预期”的生产流程。下面我展开讲讲每个环节里我具体是怎么操作的。2. 工具怎么选帮你把每个环节交给最合适的AI2.1 编辑器内AICursor、Copilot 这类工具是干嘛的工具选型是个很现实的问题。市面上的AI编程工具名字多得让人眼花缭乱什么Cursor、GitHub Copilot、通义灵码、CodeGeeX还有各种基于大模型做的插件。很多人的选择策略是“哪个火用哪个”结果装了一堆插件每个都在跟你抢光标体验反而糟糕。我的经验是先把工具按使用场景分成几类。第一类是编辑器内的编程助手代表就是 Cursor 和 GitHub Copilot。这类工具干的事是在你写代码的过程中实时补全、根据注释生成代码、框选一段代码直接让AI修改。它们适合的场景是“你已经知道怎么写想让AI帮你加速”或者“你在一个不太熟悉的语言/框架里摸路让AI帮你把常用样板代码铺好”。我现在的日常主力是 Cursor因为它把编辑器和 AI 结合得比较深。你按一下快捷键就能选中代码跟AI对话AI可以直接帮你改文件改完你能看到diff同意就采纳不同意就回滚。Copilot 我也用过它在补全的流畅度上很出色尤其是写重复性代码的时候。差异点在于 Cursor 更擅长“理解整个文件甚至整个项目再动手”Copilot 则更偏“逐行预测”。如果你主要写的是Python、JavaScript这类生态成熟的语言两个都够用真正决定体验的是你给它多大范围的上下文。2.2 对话式大模型在需求分析和方案讨论阶段最好用第二类是通用对话式大模型比如 ChatGPT、Claude、Gemini也包括国内能用的一些大模型产品。这些工具不嵌在编辑器里更适合做需求分析、方案设计、代码解释、写测试用例这类“思考型”工作。我会在开工前先把需求文档丢给它让它帮我列问题清单、给方案选项、指出我没考虑到的风险点。这个阶段用对话式模型比用编辑器内AI舒服因为对话界面更适合来回讨论。很多人会纠结到底选哪个模型。我的建议是不用太纠结只要上下文窗口够大、代码能力在平均线以上哪个都行。真正影响结果的是你会不会提问题。你让它“给个方案”它给你的是通用模板你让它“根据我给的目录结构和数据量对比三种遍历方案的性能差异推荐一种”它给的才是能用的建议。我习惯把对话模型当“技术顾问”用而不是当“打字员”用这是很重要的一层心态转换。2.3 工作流平台Dify、Coze、n8n 用在哪一层第三类是工作流平台包括 Dify、Coze、n8n 等。很多初学者会把这类平台和前面的AI编程工具搞混以为装了个 Dify 就能自动写代码了。实际上它们解决的是另一个层面的问题把大模型能力编排成自动化应用。比如你想做一个“根据简历自动生成面试提问清单”的内部工具或者想搭建一个“把公众号文章抓下来总结后发到内部知识库”的自动化管道这类需求适合用 Dify 或 Coze 这类平台来搭。它们的价值在于把AI能力、业务逻辑、外部API串成一个可视化的工作流不需要你从头写一套服务端代码。n8n 则更偏通用自动化它像是编程里的“胶水层”重点是把不同系统的接口连起来比如“收到表单提交→调用大模型处理→写入数据库→发送通知”。如果你在团队里负责工具链建设这类平台值得花时间研究。但我也要说句实话这些平台适合做“独立应用”或“自动化流程”不太适合替代你日常开发项目里的核心编码工作。你写一个业务系统的时候核心逻辑还是得靠编辑器内AI 对话式大模型来完成平台类工具是在外围搭把手。2.4 我的选型逻辑按任务类型分工而不是按品牌站队工具篇最后总结一下我的选型逻辑。我不会迷信某一个品牌而是按任务类型来分工需求讨论和方案设计优先用对话式大模型因为它上下文长、适合发散性讨论实际写业务代码用编辑器内AI因为它能直接改我的文件、看到diff重复性的自动化流程交给工作流平台因为它有可视化编排和触发机制涉及公司敏感代码或强合规场景时优先选择能私有化部署的方案。一开始你可能觉得一个项目里切换好几个工具很麻烦但用过一段时间你会发现每个工具在它的位置上都不可替代。这就像你家里有炒锅、汤锅、蒸锅你不会因为“炒锅最常用”就用它煮汤。AI编程工作流也是一样给每个环节配上合适的工具才能减少摩擦、提升整体效率。3. 从0到1搭建流程拿一个真实小项目走一遍3.1 先写需求卡把话说清楚理论讲了半天不如直接走一遍。接下来我用一个真实的小项目演示整套工作流怎么落地。场景是这样的我自己电脑里存了大概三年多的照片各种手机、相机、截图混在一起有几千个文件之前一直懒得整理最近想写个脚本自动把它们按拍摄日期归档到“年/月”目录下面。这个需求听起来简单但如果不做定义直接丢给AI它大概率会给你写一个基于文件修改时间的脚本而文件修改时间在照片拷贝、转存以后往往会变根本不是真实的拍摄时间结果就是归档乱套。所以开工之前我先写了一张“需求卡”把信息和约束都填清楚。【任务背景】 本机有一个目录 photos/里面混合存放了 jpg、png、mp4 等格式的媒体文件 共约6000个来源包括手机微信备份、相机导出、网页截图。 【目标】 写一个 Python 脚本扫描该目录读取媒体文件自带的拍摄时间 按 年/月 结构移动到输出目录例如 2024/11/IMG_01.jpg。 【技术约束】 - Python 3.10优先使用标准库 - 读取 jpg 的 EXIF 信息优先取 DateTimeOriginal 字段 - heic 格式如果读不到时间就跳过并单独记录日志 - 移动文件时处理重名出现重名自动加序号不覆盖已有文件 【验收标准】 处理完以后输出一份统计成功多少、跳过多少、失败多少、失败原因 【本次只做】 先给你上面的背景请帮我确认有没有遗漏的边界情况这张需求卡是我跟AI协作最重要的工具。它把AI需要知道的信息一次性给全了而不是让AI一边问一边挤牙膏。实际使用的时候你会发现很多隐藏需求是在写需求卡的过程中浮现的比如“移动还是复制”“要不要保留原始目录结构”“文件重名怎么处理”这类问题如果你自己都没想过AI更不可能替你想全。写需求卡这个动作本身就是在逼你把需求想透。3.2 让AI先出方案不急着写代码需求卡写好后我没有直接要求AI写代码而是让它先给我一份实现思路。这一步非常关键因为AI直接生成的成品代码通常只有一个解法而这个解法未必适合我的实际条件。比如我知道这六千个文件分布在几十个子目录里遍历的时候用什么方式、怎么避免重复扫描、内存怎么控制都值得先想清楚。我把需求卡的前半部分丢给了对话式大模型很快收到了一个方案用 os.walk 递归遍历jpg 用 PIL 或者 piexif 读取 EXIFmp4 用 ffprobe 读取创建时间移动文件时用 os.path.exists 做重名检测然后自动编号。方案整体合理但其中有个选择我不太满意为了读EXIF引入第三方库我觉得对一次性整理的脚本来说太重了。我让AI给出一个只用标准库的替代方案它告诉我可以用 struct 直接解析 JPEG 的 EXIF 段。这就是先聊方案的价值。如果我一上来就让它写代码它会默认引入一批依赖库最后我在一个没有外网环境的机器上跑脚本就寸步难行。先讨论方案等于在开工前把技术路线和依赖都敲定后面实现的时候就不会出现“写完了发现环境装不上”的尴尬。我觉得对任何项目来说这个环节至少能帮你在前期就排除掉三成以上的返工风险。3.3 分阶段生成代码骨架、核心逻辑、边界情况方案定了以后进入编码环节。我强烈建议不要对AI说“按这个方案写完整脚本”而是把任务切成三步走。第一步是先让AI生成骨架包括参数解析、目录扫描、主流程结构。这一阶段的代码不需要处理细节逻辑只要把整体框架立起来让我能看清数据是怎么流动的。第二步是让AI填充核心函数比如读取EXIF时间、生成目标路径、执行移动操作。第三步才是处理边界情况像重名文件、损坏图片、目录不存在这类异常场景。下面我贴一段当时生成的核心代码用来展示AI补全后我做了哪些调整。最初代码里它直接用了 shutil.move 来移动文件并且在重名时用 while 循环自增序号。import os import shutil from datetime import datetime def unique_dest_path(dest_dir, filename): name, ext os.path.splitext(filename) candidate os.path.join(dest_dir, filename) counter 1 while os.path.exists(candidate): candidate os.path.join(dest_dir, f{name}_{counter}{ext}) counter 1 return candidate def move_media_file(src_path, dest_dir): os.makedirs(dest_dir, exist_okTrue) dest_path unique_dest_path(dest_dir, os.path.basename(src_path)) shutil.move(src_path, dest_path) return dest_path这段代码功能上没问题但我 review 的时候发现一个潜在性能隐患当目标目录里同名文件特别多时unique_dest_path 每次都要从头查找假设已经有 file_99.jpg再移动第100个重名文件while 循环要探测 100 次。对一次性整理脚本来说这个性能可以接受但我觉得代码不优雅于是让AI改成先读取目录下所有文件名到集合里用集合判断重名。这一个小改动让代码在极端情况下效率提升了几十倍。这里我想分享一个核心经验AI生成的代码只是初稿你必须带着工程思维去审视它。不要因为“AI能跑就行”而降低标准。代码是给人维护的哪怕是一次性脚本三个月后你再打开它如果满屏都是AI风格的命名和混乱逻辑你一样会骂人。3.4 让AI做代码审查比你自己看更细代码写完、能跑通以后不要急着收工。我一般会多做一步把完整文件丢回给AI让它以资深代码评审者的身份做一次审查。具体提示词大概是这样的“你现在是代码审查专家请检查下面的Python脚本重点关注资源泄漏、异常处理、路径跨平台兼容性以及可能在Windows/macOS上表现不一致的地方列出每个问题并说明修复方式。”这一步的效果经常出乎我意料。有一次AI帮我指出我处理 JPEG 文件时如果 EXIF 段不存在直接对空数据调用解析函数会抛异常而我在外层捕获异常时没区分“文件损坏”和“格式不支持”导致统计日志里错误原因全是笼统的 Unknown Error对后续排查没帮助。这些问题自己看确实不容易发现因为自己对刚写的代码有“思维盲区”总觉得逻辑是对的。AI review 的另一个好处是它能提供你认知之外的视角。比如它可能提醒你读取 mp4 元数据时用 ffprobe但某些非标准编码的文件 ffprobe 会返回非零退出码再比如移动文件前要确保源文件不是只读属性否则在 Windows 上会报 PermissionError。这些细节未必会立刻触发但一旦触发就是半夜修 bug 的节奏。让AI提前帮你把这层窗户纸捅破省下的时间相当可观。3.5 把整套工作流沉淀成可复用模板一次项目走下来真正值钱的其实是那套流程。我现在电脑里存了一个名为 ai-workflow-templates 的目录里面每个子项目都包含四个固定文件需求卡、方案纪要、提示词记录、回顾笔记。需求卡记录这个项目当初要解决什么问题、有哪些约束方案纪要记录最后定了什么技术路线、放弃过什么方案提示词记录是我最看重的我会把每次效果特别好的提示词原样保存下来下次遇到类似场景改改就能用回顾笔记则写这个项目里AI哪里给力、哪里拉胯、下次怎么调整。这样做的好处是工作流会随着项目数量增长而不断进化。第一次用AI项目可能需要来回折腾十轮对话第二次遇到类似需求我直接调出之前的模板改几个关键词就能用基本三轮以内出稳定结果。如果你现在刚开始接触AI编程我建议无论项目多小都走完这遍流程并留个记录。不用一个月你就能积累出一套属于自己的“AI协作方法论”那比任何网上的教程都更适合你的实际场景。4. 实测中躲不开的问题和排查方法4.1 AI答非所问大概率是上下文喂错了用得多了你就会发现AI翻车很多时候不是能力问题而是它没有足够的上下文。我见过最典型的情况是让AI改一个函数代码里明明用的是requests库AI“自作聪明”给你改成aiohttp异步版本因为它默认你在做高性能服务。这种问题的根源是你没有告诉它这个项目是什么类型、有没有第三方依赖约束、改动的范围边界在哪。我现在的做法是每次让AI处理任务前把相关的上下文打包给它。最低限度的上下文包括项目是做什么的、技术栈是什么、当前文件的核心逻辑、这次改动期望达成的效果。如果项目里有特殊约定比如“不允许引入新的依赖”“所有路径必须用 pathlib 而不是 os.path”我会单独起一行写清楚。AI提示词没有那么多玄学核心就是信息充分、边界明确、要求具体。4.2 AI写出的代码一运行就报错按这个顺序让AI自修遇到运行报错很多人会把报错信息贴给AIAI改完再跑还是错再贴再错几轮下来就失去耐心了。这个循环低效的原因在于你给AI的信息不完整。报错信息只是结果背后的运行环境、输入数据、调用方式都在影响问题排查。我自己有一套固定的Debug提示词先描述“我想做什么”再贴“我运行的命令”再贴“完整报错堆栈”最后补充“我尝试过什么操作”。按照这个顺序把信息给全AI基本能一次定位问题。比如说FileNotFoundErrorAI看到完整堆栈以后通常会反问你是不是在别的目录下运行脚本这时候你再检查一下十有八九是执行路径问题。你只贴一句“FileNotFoundError”让它猜它只能给你列出十种可能你一个个试过去效率当然低。还有一个实用小技巧如果AI连续两次修改都没解决问题果断把当前整个文件或者函数贴给它让它重新分析而不是继续在原答案上打补丁。因为有时候大模型会陷入“确认偏误”你说有问题它就改一行实际上问题在更远的地方。重开一段对话、从完整的现状重新开始往往能跳出死循环。4.3 AI越改越乱代码像滚雪球回到上一版本比报错更烦人的是AI“过度修复”你让它解决一个问题它顺手把原本正常的代码也重构了一遍结果修好了bug又引入新bug你再让它修它又动了别的逻辑几轮下来整个文件改得面目全非你都不知道自己最初写的版本去哪了。应对这个问题我的办法简单粗暴在让AI大规模修改前先把当前文件放进Git提交一次或者手动复制一份带时间戳的备份文件。如果AI改完的效果不理想我不会跟它继续纠缠而是直接放弃这轮的修改恢复备份重新开一轮并且在新对话里强调“只改xxx函数不要动其他逻辑不要重构不要改变原有风格”。把AI的修改范围约束住比事后让它“改回去”要靠谱得多。这个经验来自一次让我印象深刻的经历。有一回我让AI给一个数据处理脚本加日志功能它顺手把整个数据处理逻辑从面向过程改成面向对象核心流程还出了错我花了一个多小时才把代码“人肉回滚”到修改前。从那以后“改前先备份”就成了我工作流里的铁律也推荐你尽早养成这个习惯。4.4 你问它“怎么做”它回你“指导意见”加上场景约束很多人在工作流里遇到的问题是AI说话太“正确”但没用。问它“怎么优化Python代码性能”它给你输出一篇泛泛的性能优化指南什么“使用合适的数据结构”“避免不必要的循环”全是正确废话。原因在于你提的问题太像一个技术博客的标题它就按技术博客的格式来回答。要让AI给出能落地的答案你得把问题嵌到具体场景里。你实际想解决的可能只是“这段处理一万个文件时内存占用太高”那就把代码贴出来说明数据量级和运行环境问它“哪些地方是性能瓶颈怎么改”。这时候它才会具体地回答你这行用了列表推导式还可以但那个地方把整个文件读进了内存改成流式读取就好。场景越具体AI的答案越实用。这个道理放在跟人类专家请教时也成立只不过AI不会嫌你烦它会一本正经地陪你跑偏直到你把它拽回来。5. 把工作流变成习惯我的几点实际操作体会整套流程跑顺以后我最大的感受是AI编程工作流重点落在“工作流”三个字上AI只是嵌入在流程里的加速器。需求定义不清、任务拆解不合理、验证环节缺失这些问题的根源都不在AI而在工作习惯。把流程理顺了AI自然好用了。如果你现在还是习惯打开对话框让AI“写个完整项目”我建议你从下一个小任务开始做两个改变。第一把目标缩小一半先做一个能跑的最小版本而不是一个完美的完整项目。第二动手前强制自己写五行的需求说明写完再发给AI。就这两个习惯坚持两周你会发现AI生成代码的可用率有明显提升。我最近还在尝试把这条工作流往外延伸比如让AI帮我写 commit message、生成项目文档、自动补单元测试。这些周边工作虽然技术含量不如主流程高但加起来每天能帮我省下不少时间。如果后续实践出什么新的心得我再接着分享。希望这篇内容能给你一些启发也欢迎你在自己的项目里试试这套流程有问题可以留言交流。
AI编程工作流实战：从需求定义到代码审查的完整方法
说句实话现在很多人对“AI编程”的感觉是两极分化的。一部分人觉得AI已经强到能替自己写整个项目另一部分人试了几次以后骂骂咧咧退回纯手写理由是“AI生成的代码根本不能用改它的功夫我自己都写完了”。我见过太多这样的例子本质问题不在AI能力而在大部分人把AI编程理解成了“在对话框里提需求、等代码、复制粘贴”这三步。真正拉开效率差距的是把AI嵌进一条完整的工作流里让它在需求分析、方案设计、编码、调试、Review 每一个环节都发挥正确的作用而不是把它当成一个偶尔灵光乍现的代码生成器。这篇文章我想聊的就是我从零搭建一套 AI 编程工作流的过程。不吹某个工具多神也不绕什么高深理论就讲我实际在项目里怎么设计这条流程、怎么选工具、怎么写提示词、怎么让AI少犯低级错误以及遇到坑以后怎么排查。内容适合正在用或者准备用 AI 辅助开发的人看不管你是独立开发者、刚入行的新人还是在团队里带项目的技术负责人应该都能从里面找到能直接抄走的思路。1. 先用流程思维理解AI编程而不是依赖“一句话魔法”1.1 为什么两个人用同一款AI工具效率差距那么大我经常被问到同一个问题别人说AI编程多好多好我用起来怎么跟人工智障一样后来我仔细观察过那些说“AI不好用”的人他们的典型操作是打开对话框输入“帮我写一个商城系统”然后期待屏幕上出现能直接上线的代码。这个期待本身就有问题。你现在让一个刚毕业的实习生去写商城系统也得先给他讲清楚业务范围、技术栈、数据库设计他才能动手。AI虽然读过大量代码但它不是一个全知全能的单体大脑它的工作方式更像一个知识面极广、沟通意愿极强、但工作记忆非常有限的结对工程师。如果你不给它清晰的边界、明确的验收标准、必要的项目上下文它就只能靠猜。AI一猜代码自然就跑偏。反观那些效率高的人他们做的事其实只有一件把原本模糊的想法拆成一系列AI可以理解和执行的子任务并且在每个节点都做好验证和纠正。这套拆解、执行、验证的过程就是我们说的“工作流”。同一款AI工具在懂流程的人手里是超级杠杆在不懂流程的人手里就是随机数生成器差别就是这么来的。1.2 一套合格的工作流要覆盖哪些环节从我的实践来看一条靠谱的AI编程工作流至少要有四个环节少了任何一个都会出问题。第一是需求定义。不管项目多小动手之前都要把“我要做什么、给谁用、在什么环境跑、有哪些约束”写清楚。这一步很多人觉得多余觉得脑子里有想法就够了。但AI没有读心术你脑子里想的是“一个轻量的内部工具”描述出来变成“帮我写个软件”它给你返回的很可能是一套企业级微服务骨架。第二是技术方案设计。拿到需求以后先让AI给你出方案而不是直接让它写代码。方案里应该包含模块划分、技术选型、数据结构设计、关键接口定义。这相当于施工图纸图纸没定就开始砌墙后面返工成本极高。第三是编码实现。这一步也不能把一整个需求一次性丢给AI要切成逻辑完整的子任务一次让AI只做一件事。每完成一个子任务你都要在本地跑一下、验证一下过了再进入下一个。这个过程有点像流水线作业每道工序都质检合格了最后组装出来的东西才靠谱。第四是审查与修复。AI写完代码不要直接信也不要直接改。先让它自己做一遍Code Review再结合你本地运行的结果让它修复。很多时候AI代码看起来逻辑没问题但一跑就报错这时候把完整报错信息贴回去让它进入“自我纠错循环”通常几轮下来就能稳定运行。这四个环节串起来AI编程才会从一个“碰运气”的行为变成一套“可预期”的生产流程。下面我展开讲讲每个环节里我具体是怎么操作的。2. 工具怎么选帮你把每个环节交给最合适的AI2.1 编辑器内AICursor、Copilot 这类工具是干嘛的工具选型是个很现实的问题。市面上的AI编程工具名字多得让人眼花缭乱什么Cursor、GitHub Copilot、通义灵码、CodeGeeX还有各种基于大模型做的插件。很多人的选择策略是“哪个火用哪个”结果装了一堆插件每个都在跟你抢光标体验反而糟糕。我的经验是先把工具按使用场景分成几类。第一类是编辑器内的编程助手代表就是 Cursor 和 GitHub Copilot。这类工具干的事是在你写代码的过程中实时补全、根据注释生成代码、框选一段代码直接让AI修改。它们适合的场景是“你已经知道怎么写想让AI帮你加速”或者“你在一个不太熟悉的语言/框架里摸路让AI帮你把常用样板代码铺好”。我现在的日常主力是 Cursor因为它把编辑器和 AI 结合得比较深。你按一下快捷键就能选中代码跟AI对话AI可以直接帮你改文件改完你能看到diff同意就采纳不同意就回滚。Copilot 我也用过它在补全的流畅度上很出色尤其是写重复性代码的时候。差异点在于 Cursor 更擅长“理解整个文件甚至整个项目再动手”Copilot 则更偏“逐行预测”。如果你主要写的是Python、JavaScript这类生态成熟的语言两个都够用真正决定体验的是你给它多大范围的上下文。2.2 对话式大模型在需求分析和方案讨论阶段最好用第二类是通用对话式大模型比如 ChatGPT、Claude、Gemini也包括国内能用的一些大模型产品。这些工具不嵌在编辑器里更适合做需求分析、方案设计、代码解释、写测试用例这类“思考型”工作。我会在开工前先把需求文档丢给它让它帮我列问题清单、给方案选项、指出我没考虑到的风险点。这个阶段用对话式模型比用编辑器内AI舒服因为对话界面更适合来回讨论。很多人会纠结到底选哪个模型。我的建议是不用太纠结只要上下文窗口够大、代码能力在平均线以上哪个都行。真正影响结果的是你会不会提问题。你让它“给个方案”它给你的是通用模板你让它“根据我给的目录结构和数据量对比三种遍历方案的性能差异推荐一种”它给的才是能用的建议。我习惯把对话模型当“技术顾问”用而不是当“打字员”用这是很重要的一层心态转换。2.3 工作流平台Dify、Coze、n8n 用在哪一层第三类是工作流平台包括 Dify、Coze、n8n 等。很多初学者会把这类平台和前面的AI编程工具搞混以为装了个 Dify 就能自动写代码了。实际上它们解决的是另一个层面的问题把大模型能力编排成自动化应用。比如你想做一个“根据简历自动生成面试提问清单”的内部工具或者想搭建一个“把公众号文章抓下来总结后发到内部知识库”的自动化管道这类需求适合用 Dify 或 Coze 这类平台来搭。它们的价值在于把AI能力、业务逻辑、外部API串成一个可视化的工作流不需要你从头写一套服务端代码。n8n 则更偏通用自动化它像是编程里的“胶水层”重点是把不同系统的接口连起来比如“收到表单提交→调用大模型处理→写入数据库→发送通知”。如果你在团队里负责工具链建设这类平台值得花时间研究。但我也要说句实话这些平台适合做“独立应用”或“自动化流程”不太适合替代你日常开发项目里的核心编码工作。你写一个业务系统的时候核心逻辑还是得靠编辑器内AI 对话式大模型来完成平台类工具是在外围搭把手。2.4 我的选型逻辑按任务类型分工而不是按品牌站队工具篇最后总结一下我的选型逻辑。我不会迷信某一个品牌而是按任务类型来分工需求讨论和方案设计优先用对话式大模型因为它上下文长、适合发散性讨论实际写业务代码用编辑器内AI因为它能直接改我的文件、看到diff重复性的自动化流程交给工作流平台因为它有可视化编排和触发机制涉及公司敏感代码或强合规场景时优先选择能私有化部署的方案。一开始你可能觉得一个项目里切换好几个工具很麻烦但用过一段时间你会发现每个工具在它的位置上都不可替代。这就像你家里有炒锅、汤锅、蒸锅你不会因为“炒锅最常用”就用它煮汤。AI编程工作流也是一样给每个环节配上合适的工具才能减少摩擦、提升整体效率。3. 从0到1搭建流程拿一个真实小项目走一遍3.1 先写需求卡把话说清楚理论讲了半天不如直接走一遍。接下来我用一个真实的小项目演示整套工作流怎么落地。场景是这样的我自己电脑里存了大概三年多的照片各种手机、相机、截图混在一起有几千个文件之前一直懒得整理最近想写个脚本自动把它们按拍摄日期归档到“年/月”目录下面。这个需求听起来简单但如果不做定义直接丢给AI它大概率会给你写一个基于文件修改时间的脚本而文件修改时间在照片拷贝、转存以后往往会变根本不是真实的拍摄时间结果就是归档乱套。所以开工之前我先写了一张“需求卡”把信息和约束都填清楚。【任务背景】 本机有一个目录 photos/里面混合存放了 jpg、png、mp4 等格式的媒体文件 共约6000个来源包括手机微信备份、相机导出、网页截图。 【目标】 写一个 Python 脚本扫描该目录读取媒体文件自带的拍摄时间 按 年/月 结构移动到输出目录例如 2024/11/IMG_01.jpg。 【技术约束】 - Python 3.10优先使用标准库 - 读取 jpg 的 EXIF 信息优先取 DateTimeOriginal 字段 - heic 格式如果读不到时间就跳过并单独记录日志 - 移动文件时处理重名出现重名自动加序号不覆盖已有文件 【验收标准】 处理完以后输出一份统计成功多少、跳过多少、失败多少、失败原因 【本次只做】 先给你上面的背景请帮我确认有没有遗漏的边界情况这张需求卡是我跟AI协作最重要的工具。它把AI需要知道的信息一次性给全了而不是让AI一边问一边挤牙膏。实际使用的时候你会发现很多隐藏需求是在写需求卡的过程中浮现的比如“移动还是复制”“要不要保留原始目录结构”“文件重名怎么处理”这类问题如果你自己都没想过AI更不可能替你想全。写需求卡这个动作本身就是在逼你把需求想透。3.2 让AI先出方案不急着写代码需求卡写好后我没有直接要求AI写代码而是让它先给我一份实现思路。这一步非常关键因为AI直接生成的成品代码通常只有一个解法而这个解法未必适合我的实际条件。比如我知道这六千个文件分布在几十个子目录里遍历的时候用什么方式、怎么避免重复扫描、内存怎么控制都值得先想清楚。我把需求卡的前半部分丢给了对话式大模型很快收到了一个方案用 os.walk 递归遍历jpg 用 PIL 或者 piexif 读取 EXIFmp4 用 ffprobe 读取创建时间移动文件时用 os.path.exists 做重名检测然后自动编号。方案整体合理但其中有个选择我不太满意为了读EXIF引入第三方库我觉得对一次性整理的脚本来说太重了。我让AI给出一个只用标准库的替代方案它告诉我可以用 struct 直接解析 JPEG 的 EXIF 段。这就是先聊方案的价值。如果我一上来就让它写代码它会默认引入一批依赖库最后我在一个没有外网环境的机器上跑脚本就寸步难行。先讨论方案等于在开工前把技术路线和依赖都敲定后面实现的时候就不会出现“写完了发现环境装不上”的尴尬。我觉得对任何项目来说这个环节至少能帮你在前期就排除掉三成以上的返工风险。3.3 分阶段生成代码骨架、核心逻辑、边界情况方案定了以后进入编码环节。我强烈建议不要对AI说“按这个方案写完整脚本”而是把任务切成三步走。第一步是先让AI生成骨架包括参数解析、目录扫描、主流程结构。这一阶段的代码不需要处理细节逻辑只要把整体框架立起来让我能看清数据是怎么流动的。第二步是让AI填充核心函数比如读取EXIF时间、生成目标路径、执行移动操作。第三步才是处理边界情况像重名文件、损坏图片、目录不存在这类异常场景。下面我贴一段当时生成的核心代码用来展示AI补全后我做了哪些调整。最初代码里它直接用了 shutil.move 来移动文件并且在重名时用 while 循环自增序号。import os import shutil from datetime import datetime def unique_dest_path(dest_dir, filename): name, ext os.path.splitext(filename) candidate os.path.join(dest_dir, filename) counter 1 while os.path.exists(candidate): candidate os.path.join(dest_dir, f{name}_{counter}{ext}) counter 1 return candidate def move_media_file(src_path, dest_dir): os.makedirs(dest_dir, exist_okTrue) dest_path unique_dest_path(dest_dir, os.path.basename(src_path)) shutil.move(src_path, dest_path) return dest_path这段代码功能上没问题但我 review 的时候发现一个潜在性能隐患当目标目录里同名文件特别多时unique_dest_path 每次都要从头查找假设已经有 file_99.jpg再移动第100个重名文件while 循环要探测 100 次。对一次性整理脚本来说这个性能可以接受但我觉得代码不优雅于是让AI改成先读取目录下所有文件名到集合里用集合判断重名。这一个小改动让代码在极端情况下效率提升了几十倍。这里我想分享一个核心经验AI生成的代码只是初稿你必须带着工程思维去审视它。不要因为“AI能跑就行”而降低标准。代码是给人维护的哪怕是一次性脚本三个月后你再打开它如果满屏都是AI风格的命名和混乱逻辑你一样会骂人。3.4 让AI做代码审查比你自己看更细代码写完、能跑通以后不要急着收工。我一般会多做一步把完整文件丢回给AI让它以资深代码评审者的身份做一次审查。具体提示词大概是这样的“你现在是代码审查专家请检查下面的Python脚本重点关注资源泄漏、异常处理、路径跨平台兼容性以及可能在Windows/macOS上表现不一致的地方列出每个问题并说明修复方式。”这一步的效果经常出乎我意料。有一次AI帮我指出我处理 JPEG 文件时如果 EXIF 段不存在直接对空数据调用解析函数会抛异常而我在外层捕获异常时没区分“文件损坏”和“格式不支持”导致统计日志里错误原因全是笼统的 Unknown Error对后续排查没帮助。这些问题自己看确实不容易发现因为自己对刚写的代码有“思维盲区”总觉得逻辑是对的。AI review 的另一个好处是它能提供你认知之外的视角。比如它可能提醒你读取 mp4 元数据时用 ffprobe但某些非标准编码的文件 ffprobe 会返回非零退出码再比如移动文件前要确保源文件不是只读属性否则在 Windows 上会报 PermissionError。这些细节未必会立刻触发但一旦触发就是半夜修 bug 的节奏。让AI提前帮你把这层窗户纸捅破省下的时间相当可观。3.5 把整套工作流沉淀成可复用模板一次项目走下来真正值钱的其实是那套流程。我现在电脑里存了一个名为 ai-workflow-templates 的目录里面每个子项目都包含四个固定文件需求卡、方案纪要、提示词记录、回顾笔记。需求卡记录这个项目当初要解决什么问题、有哪些约束方案纪要记录最后定了什么技术路线、放弃过什么方案提示词记录是我最看重的我会把每次效果特别好的提示词原样保存下来下次遇到类似场景改改就能用回顾笔记则写这个项目里AI哪里给力、哪里拉胯、下次怎么调整。这样做的好处是工作流会随着项目数量增长而不断进化。第一次用AI项目可能需要来回折腾十轮对话第二次遇到类似需求我直接调出之前的模板改几个关键词就能用基本三轮以内出稳定结果。如果你现在刚开始接触AI编程我建议无论项目多小都走完这遍流程并留个记录。不用一个月你就能积累出一套属于自己的“AI协作方法论”那比任何网上的教程都更适合你的实际场景。4. 实测中躲不开的问题和排查方法4.1 AI答非所问大概率是上下文喂错了用得多了你就会发现AI翻车很多时候不是能力问题而是它没有足够的上下文。我见过最典型的情况是让AI改一个函数代码里明明用的是requests库AI“自作聪明”给你改成aiohttp异步版本因为它默认你在做高性能服务。这种问题的根源是你没有告诉它这个项目是什么类型、有没有第三方依赖约束、改动的范围边界在哪。我现在的做法是每次让AI处理任务前把相关的上下文打包给它。最低限度的上下文包括项目是做什么的、技术栈是什么、当前文件的核心逻辑、这次改动期望达成的效果。如果项目里有特殊约定比如“不允许引入新的依赖”“所有路径必须用 pathlib 而不是 os.path”我会单独起一行写清楚。AI提示词没有那么多玄学核心就是信息充分、边界明确、要求具体。4.2 AI写出的代码一运行就报错按这个顺序让AI自修遇到运行报错很多人会把报错信息贴给AIAI改完再跑还是错再贴再错几轮下来就失去耐心了。这个循环低效的原因在于你给AI的信息不完整。报错信息只是结果背后的运行环境、输入数据、调用方式都在影响问题排查。我自己有一套固定的Debug提示词先描述“我想做什么”再贴“我运行的命令”再贴“完整报错堆栈”最后补充“我尝试过什么操作”。按照这个顺序把信息给全AI基本能一次定位问题。比如说FileNotFoundErrorAI看到完整堆栈以后通常会反问你是不是在别的目录下运行脚本这时候你再检查一下十有八九是执行路径问题。你只贴一句“FileNotFoundError”让它猜它只能给你列出十种可能你一个个试过去效率当然低。还有一个实用小技巧如果AI连续两次修改都没解决问题果断把当前整个文件或者函数贴给它让它重新分析而不是继续在原答案上打补丁。因为有时候大模型会陷入“确认偏误”你说有问题它就改一行实际上问题在更远的地方。重开一段对话、从完整的现状重新开始往往能跳出死循环。4.3 AI越改越乱代码像滚雪球回到上一版本比报错更烦人的是AI“过度修复”你让它解决一个问题它顺手把原本正常的代码也重构了一遍结果修好了bug又引入新bug你再让它修它又动了别的逻辑几轮下来整个文件改得面目全非你都不知道自己最初写的版本去哪了。应对这个问题我的办法简单粗暴在让AI大规模修改前先把当前文件放进Git提交一次或者手动复制一份带时间戳的备份文件。如果AI改完的效果不理想我不会跟它继续纠缠而是直接放弃这轮的修改恢复备份重新开一轮并且在新对话里强调“只改xxx函数不要动其他逻辑不要重构不要改变原有风格”。把AI的修改范围约束住比事后让它“改回去”要靠谱得多。这个经验来自一次让我印象深刻的经历。有一回我让AI给一个数据处理脚本加日志功能它顺手把整个数据处理逻辑从面向过程改成面向对象核心流程还出了错我花了一个多小时才把代码“人肉回滚”到修改前。从那以后“改前先备份”就成了我工作流里的铁律也推荐你尽早养成这个习惯。4.4 你问它“怎么做”它回你“指导意见”加上场景约束很多人在工作流里遇到的问题是AI说话太“正确”但没用。问它“怎么优化Python代码性能”它给你输出一篇泛泛的性能优化指南什么“使用合适的数据结构”“避免不必要的循环”全是正确废话。原因在于你提的问题太像一个技术博客的标题它就按技术博客的格式来回答。要让AI给出能落地的答案你得把问题嵌到具体场景里。你实际想解决的可能只是“这段处理一万个文件时内存占用太高”那就把代码贴出来说明数据量级和运行环境问它“哪些地方是性能瓶颈怎么改”。这时候它才会具体地回答你这行用了列表推导式还可以但那个地方把整个文件读进了内存改成流式读取就好。场景越具体AI的答案越实用。这个道理放在跟人类专家请教时也成立只不过AI不会嫌你烦它会一本正经地陪你跑偏直到你把它拽回来。5. 把工作流变成习惯我的几点实际操作体会整套流程跑顺以后我最大的感受是AI编程工作流重点落在“工作流”三个字上AI只是嵌入在流程里的加速器。需求定义不清、任务拆解不合理、验证环节缺失这些问题的根源都不在AI而在工作习惯。把流程理顺了AI自然好用了。如果你现在还是习惯打开对话框让AI“写个完整项目”我建议你从下一个小任务开始做两个改变。第一把目标缩小一半先做一个能跑的最小版本而不是一个完美的完整项目。第二动手前强制自己写五行的需求说明写完再发给AI。就这两个习惯坚持两周你会发现AI生成代码的可用率有明显提升。我最近还在尝试把这条工作流往外延伸比如让AI帮我写 commit message、生成项目文档、自动补单元测试。这些周边工作虽然技术含量不如主流程高但加起来每天能帮我省下不少时间。如果后续实践出什么新的心得我再接着分享。希望这篇内容能给你一些启发也欢迎你在自己的项目里试试这套流程有问题可以留言交流。
