刚开始接触AI编程工具时我和很多人一样是带着抵触情绪的。写代码写了那么多年自动补全用了一堆什么智能提示、代码联想说白了就是“高级版输入法”真正复杂的业务逻辑它帮不上忙有时候还会给出莫名其妙的建议让人越改越乱。真正让我改变看法的是一次临时接手的旧接口迁移任务。那批接口数量大、逻辑相似、字段映射琐碎如果全靠手写一天都不一定写得完。我抱着试一试的心态把需求拆开喂给AI编程工具结果几个小时就出了可运行的骨架我再逐段审查、改边界、补异常整个任务当天就收工了。那之后我慢慢形成一个习惯不把AI当“自动写代码机”而是当成一个随叫随到的“快速实习生”。你给它越清晰的任务说明它越能给到可用的产出你越是笼统地说“写个系统”它就越可能给你一个华丽但落不了地的玩具。这篇文章我想聊的就是这三件事AI编程工具到底怎么选使用过程中该建立什么样的方法论以及如何把它们组合成一条可重复落地的工作流。如果你已经开始用AI写代码但总觉得效率提升有限、生成结果不稳定或者还在观望不知道怎么入手这篇内容应该能给你一些参考。1. AI编程工具怎么选先搞清楚形态再谈效率很多人选AI编程工具的时候容易盯着“哪个品牌强”“哪个模型新”“哪个通过率更高”这类指标但忽略了一件更基础的事你手上的任务到底是什么形态需要的是哪种类型的工具。选错工具和用扳手拧螺丝有点像不是不能用但一定别扭。1.1 三种主流形态对应三类场景我按实际使用方式把AI编程工具粗略分成三类编辑器内嵌的代码补全型、对话问答型、以及终端命令行型。它们解决的是不同粒度的问题不能互相替代。代码补全型在编辑器里跟着光标实时预测下一段代码。适合写样板代码、重复性结构、熟悉语言里的句式比如for循环、SQL查询、JSON序列化、常见正则。它的价值是“少打字”对手感的提升最直接但对架构层面的事基本帮不上忙。对话问答型以多轮聊天的方式交互可以贴代码、贴报错信息、问方案、做Code Review。适合处理“需要理解上下文”的任务比如解释一段陌生代码、设计一个模块结构、讨论某个技术选型。它是最通用的形态也是我日常用得最多的。CLI终端型直接在命令行里调用可以指定文件、目录做批量重构、生成单元测试、分析项目结构。适合需要把AI能力嵌入脚本和自动化流程的场景比如持续集成里自动生成变更说明、批量给旧代码补注释。三种形态不是同一件事的不同包装它们的交互模型差别很大。补全型依赖“你正在打字”的即时反馈适合微操对话型依赖“你问一个完整问题”适合设计命令行型适合“给明确路径和文件范围”的任务适合工程化。我现在的组合方式是编辑器里的补全功能常开用来处理手头正在写的代码对话型工具放在另一个窗口需要方案讨论、逻辑梳理、代码审查的时候用命令行型则在批量任务和自动化脚本里调用。形态擅长任务典型短板适合人群代码补全局部代码、样板代码、语法填空不理解全局设计无法处理跨文件改动日常写代码最多的开发者对话问答方案讨论、代码解释、报错分析、Code Review受上下文长度限制长会话会遗忘早期约定需要整体思考的开发者命令行批量重构、测试生成、项目级分析交互不够直观需要明确指定范围有自动化脚本经验的人1.2 选型避坑经验我在工具选型上踩过的坑主要有三个。第一别被演示效果带偏。很多AI工具的官方演示都是精心挑过的场景看起来一次生成一整段完美的业务代码但你拿自己真实的项目一试结果完全不一样。我后来总结了一个方法准备一个“测试集”包含你项目里最有代表性的三个小任务一个用你用得不熟的语言写的一个涉及复杂配置的一个需要访问某种API的。切换工具时用同一套任务做横向对比只看实际产出不看宣传片。第二注意代码安全和隐私边界。把公司核心代码贴进公网的对话型工具是有泄露风险的。我在某公司实习时明确规定过敏感算法模块绝不能贴给外部工具只允许用本地部署的方案处理。这个约束要提前想清楚不能等代码都贴上去了才发现问题。工具选型时先问一句这个工具的数据处理链路是什么能不能本地化历史会话会不会被用于训练。第三控制工具数量。不要同时订阅五六个AI编程工具然后每天都在切换和对比。工具是拿来用的不是拿来评测的。我个人保留两套组合就够了一套是常用的编辑器补全对话助手另一套是本地部署的模型专门处理敏感代码和离线场景。多了反而是负担。2. 方法论让AI输出可控的四个关键动作工具选得再好如果方法不对AI生成出来的代码依然会让人血压升高。我把和AI协作的过程总结成四个关键动作拆需求、设边界、控上下文、切小步。这几个词看起来简单但每一个背后都有具体的操作技巧。2.1 先拆需求再写提示词AI不理解你的业务它只理解你写出来的文字。你给它一句“帮我写个用户管理系统”它就默认按照教科书里的用户、角色、权限泛化设计来写大概率不是你真正想要的。正确的做法是先把需求拆成AI能执行的粒度再写提示词。我常用的提示词结构大概是这样的角色你是一个熟悉Python的资深后端工程师。任务目标请实现一个函数输入为订单列表JSON文件路径输出为CSV文件。输入数据结构给出JSON的具体字段和类型。输出要求CSV包含哪些列、列名是什么、日期格式是什么。约束条件只使用标准库不要引入第三方依赖不要修改输入文件错误统一抛出自定义异常。验收标准写一个简单的示例调用包含正常输入和空输入两种情况。这样写出来的提示词AI回复的代码质量会稳定很多。对比一下“帮我导出一个CSV”和上面这段产出完全是两个级别。前者AI会自己脑补一大堆不确定的参数后者它只需要按规则填充就好。2.2 明确边界告诉AI什么不该做这一点容易被忽略。给AI列“允许做什么”之外还要列“不允许做什么”。因为AI生成代码的时候有种倾向就是“过度补全”。你让它写一个导入脚本它可能会自己加上日志、多线程、重试机制、配置文件解析看起来高大上但你的项目根本不需要这些反而增加了排查问题的难度。我处理过一个真实的例子让AI生成一个批量处理图片缩略图的脚本结果它自动加了基于内存的队列、多线程池、优雅关闭逻辑代码长度翻了三倍。后来我在提示词里明确加了一句“不要使用多线程不要引入第三方库只同步逐个处理”生成结果一下就干净了。设定边界还有一个好处降低AI犯错的概率。当你明确告诉它“不要用某个库”“不要动某个目录”它就不会往那个方向试探。方法是在提示词里单独开一段“约束与限制”清单每一条都是明确的可执行语句而不是模糊的“注意代码质量”。2.3 控制上下文把约定写下来而不是指望AI记住对话型AI有一个绕不开的问题就是上下文窗口有限。你会发现一个会话聊得时间长了它渐渐忘了最早讨论过的技术栈、命名规范、目录结构甚至会前后矛盾。这不是它变笨了而是它的注意力被后面的大量信息稀释了。我的解决办法是把关键约定“外部化”。不要让AI在对话里记约定而是把约定写在一个文件里每次开启新会话时贴给AI或者直接告诉它去读项目里的某个文档。比如项目中维护一个docs/ai-conventions.md里面记录技术栈、目录结构、代码风格、禁止使用的库、常用命名规范。每次开始一个新任务第一件事就是把这份文件内容粘进对话。还有一个小技巧让AI先复述你的需求。别急着让它写代码先让它用自己的话说一遍它理解的任务、约束和验收标准。如果复述的内容有偏差这时候纠正成本最低。等它确认理解一致了再让它开始动手。2.4 分批处理一次只让AI做一件小事经常有人抱怨“让AI写一个完整模块结果代码根本跑不起来”。这太正常了因为一个完整模块里包含太多隐含假设和关联设计只要有一个地方前后不一致整段代码就废了。正确做法是把模块拆成多个小任务一步一步来。我这里说的“小”具体到什么程度呢比如一个“用户管理”模块我不会让AI一次写全部而是拆成四步写数据库表结构定义写数据访问层包括增删改查写业务层的注册逻辑包含邮箱校验和密码加密写接口层包含参数校验和错误返回每一步生成完以后我先审查、跑通、确认没问题再进行下一步。这个过程很像带新人一次交代一件事验收完再给下一件。AI不是全知全能的协作伙伴它的工作记忆和推理稳定性撑不起超大规格的任务把它当成快速但需要频繁确认的实习生效果反而更好。3. 工作流设计从提示词到可维护代码的完整闭环有了工具、有了方法还要把它们装进一条固定的工作流里才能在团队里复制也才能保证每次产出质量稳定。我把自己跑顺的流程整理成了五个步骤。整个过程看起来有点重但对于真正要交付的项目每一步都不能省。3.1 我的五步工作流第一步需求澄清与拆分。拿到一个任务先不要打开编辑器也不要打开AI工具。拿一张纸把目标写清楚列出输入、输出、约束、验收标准。这个动作花的时间通常不超过15分钟但它决定了后续AI生成的代码是不是贴题。只有人能想清楚的任务才有资格交给AI。第二步方案设计。在纸上或者文档里先勾出一个大致的结构分几个模块、每个模块的职责是什么、模块之间的接口怎么约定。这一步不需要非常细有个大方向就行。然后把这个方案结构喂给AI让它补充遗漏点。这时候AI的价值是“查漏”和“扩展”而不是“从零发明”。第三步AI生成与人工改造。按上一节说的方式拆成小任务逐个让AI生成。生成以后我会逐行读一遍把不符合项目风格的代码改掉。这一步的判断标准是这段代码如果是我自己写的我能不能接受它合入主干。接受不了就让AI重写或者自己动手改。第四步验证与测试。AI生成的代码跑通主流程只是开始还要补测试、测边界、测异常输入。我通常会让AI自己设计测试用例但测试用例我会人工过一遍因为AI有时会顺着功能的思路写测试测不到真正的边界问题。关于这一点下一节还会详细展开。第五步记录与沉淀。任务完成后把这次用到的提示词、遇到的坑、修改的关键点整理保存下来。这一步最容易被跳过但长期来看收益最大。我建了一个自己的“AI提示词模板库”按任务类型分类写函数、写测试、解释代码、重构模块、排查报错。时间久了写新任务的开销会小很多。3.2 代码审查把AI当成“快速实习生”而不是“权威专家”AI生成的代码在语法上通常没什么问题真正的问题隐藏在逻辑里。我审查AI代码时重点看五个地方输入校验是否对空值、类型错误、越界情况做了处理。异常处理出错时是直接崩溃还是有明确的错误信息。资源释放文件、网络连接、数据库连接是否正常关闭。性能隐患有没有循环里做重复查询、不必要的数据拷贝。边界条件空列表、单元素列表、超大输入是否都能正确处理。这五个点写成一个固定的审查清单每次审查AI代码时逐条对照。一开始觉得麻烦但用过几次就会发现AI生成代码的“事故高发区”基本都集中在这几个地方尤其是边界条件和异常处理。还有一个反向提问技巧代码生成后直接问AI“这段代码有哪些潜在问题请按严重程度列出”。你会发现它自己也能指出一些坑。虽然它不一定全部找出来但至少能帮你打开思路。3.3 反向验证让AI证明自己的代码是对的比直接审查更进一步的做法是让AI为自己的代码写测试。写出来的测试再反过来验证代码逻辑是否通顺。这种“自己出题自己答”的方式能在提交之前暴露不少问题。更有效的一种方式是“交叉验证”用一个会话生成代码用另一个会话的干净上下文去审查同一段代码。因为第二个会话没有看过生成过程不会带着生成时的思路走更容易发现逻辑漏洞。我经常把同一个函数分别丢给两个不同会话让它们各自找问题然后合并去重。效果比我自己埋头检查好很多。要注意的是不要被AI自信的回答迷惑。你问它“这个实现有问题吗”它大概率会说“目前看起来是ok的需要注意边界情况”。这种回答没有参考价值。所以要问具体问题“如果输入是一个0字节的文件会发生什么”“如果文件路径不存在这个函数会抛什么异常”只有具体到场景的问题AI的回答才有信息量。4. 实操记录用AI从零实现一个数据导出小工具前面的内容多少有点抽象我拿一个真实的例子走一遍完整流程。这次任务是做一个命令行小工具读取一个JSON文件里面是订单数据导出一个CSV文件但要做字段映射、日期格式化还要处理嵌套对象并且只能用标准库目标是以后能批量处理一批文件。4.1 需求澄清与拆分我先写下了需求输入JSON文件内容是订单列表每条订单包含order_id、created_at、customer、items等字段。输出CSV文件但输出的列名需要是中文表头并且customer是嵌套对象需要拆成customer.name和customer.contact两个字段。约束只使用标准库不引入任何三方依赖支持命令行参数指定输入输出文件路径异常时给出明确中文报错信息并退出。拆成小任务先做一个通用的“JSON转带映射CSV”的核心函数再做命令行参数处理最后处理嵌套字段展开。这三个任务都是可在10分钟内完成的小粒度任务。4.2 提示词与AI生成过程我给AI的第一个提示词大概是这样的角色擅长Python的工程师。任务实现一个函数接收两个参数json文件路径和csv输出路径。JSON文件内容是一个对象数组每个对象包含order_id、created_at、customername和contact、items数组。输出CSV时列名为订单号、创建时间、客户姓名、客户联系方式、商品数量。创建时间格式为YYYY-MM-DD HH:mm:ss。约束只用标准库不要用第三方库不要改动原JSON文件如果输入文件不存在或JSON格式错误抛出带中文信息的异常。验收生成完成后给出一个可直接运行的命令行入口。AI生成的核心逻辑大体可用但有两个地方需要改。第一个问题是它用了csv.DictWriter对于嵌套字段需要预先展开它直接把整个嵌套结构塞进去了导致输出不符合预期。我纠正了它的实现方式要求先做字段映射和展开再写入表格。第二个问题是它在处理中文字段名时没有设置UTF-8-sig编码生成的CSV用表格软件打开会出现中文乱码这在Windows平台上是经典问题。加上encodingutf-8-sig之后就正常了。4.3 踩到的典型问题和解决方案这个项目过程中踩了三个值得记录的坑都是AI生成代码时容易“想当然”的地方问题一AI喜欢引入不必要的依赖。第一版生成时它试图用第三方库来解析JSON和写CSV。我明确说了“只用标准库”之后它改成了json和csv。这类问题出现的频率非常高解决方式只有一个把约束写得极其明确。问题二嵌套字段展开不够灵活。当我要展开customer.name时AI直接写死了字段路径没有做通用映射。我要求它改为接收一个“字段映射表”参数核心逻辑变成根据映射表递归取值。这样改造之后以后导其他类型的数据也能复用不再需要为不同报表各写一套代码。问题三缺少错误处理。AI默认了文件一定存在、JSON格式一定正确。我给它补上“输入不存在时给出明确提示并退出”的约束它才在入口函数里加了判断逻辑。这件事提醒我AI不会主动考虑异常场景除非你在需求里说了。整个过程做完包含我自己改代码和测试的时间大约花了一个下午。如果完全手写差不多要到第二天。更重要的是这套结构化的提示词和流程在后续类似任务中都能复用边际成本越来越低。5. 常见问题与排查技巧实录最后整理一份我日常使用AI编程工具时的常见问题速查表这些问题不特定于某个工具更多是在协作过程中反复出现的模式。5.1 提示词明明很详细AI还是跑偏先检查是不是缺少“输出格式”约束。AI是文本模型你让它“写一段代码”它默认会附带很多解释文字甚至给你提供多套方案而不是只给代码。如果你在提示词末尾加一句“只输出可以直接运行的Python代码不要解释”它就会收敛很多。再检查示例是否充分。给一个输入输出的示例会大幅减少歧义。比如你要求“把日期格式改成2024-01-01”但没说原来的格式长什么样它只能靠猜。贴一条真实样例数据进去它就会照着格式处理。如果还是跑偏那就拆小。把一个大任务拆成两个小任务分别确认结果再合并。我和AI协作的前期大部分“不靠谱”都是因为一次性喂了太多信息把AI“撑晕了”导致的。5.2 长会话中AI忘记早期需求典型表现是前十分钟还约定得很好后二十分钟开始出现违反约定的代码比如用了禁止的库、改了不相关的文件、字段命名忽而英文忽而中文。这是上下文长度导致的不用怀疑AI智商。解决办法刚才提过两次这里再强调一遍重要约定写在外部文档里每个新会话开始时贴给AI或者让AI按“复述-确认-执行”的流程工作。我自己维护的ai-conventions.md大约20行每次开新会话前复制粘贴两秒钟的事但可以省掉后面大量返工时间。5.3 怎样识别AI的“幻觉代码”“幻觉代码”就是你让它调用一个不存在的API或者编造一个不存在的方法名、参数名、函数行为。这种问题在涉及不常见库、新版本API、或者内部开发的接口时尤其容易发生。第一道防线在提示词里明确写“如果你不确定某个API存在请直接说不确定不要猜测”。这条约束不是绝对有效但能减少一部分编造。第二道防线生成后立刻做“编译/测试验证”不要肉眼看一遍觉得没问题就合入。把AI生成的代码放进独立的测试环境里跑一遍是最直接的检测方式。第三道防线让AI说明代码的依据。问它“这个函数是哪个版本引入的列出参数签名”。如果它回答得含糊或者给的版本信息对不上基本可以判定是编造的。这类问题排查多了你会形成一种肌肉记忆对于AI写的代码默认“先验证再信任”而不是“先信任再报错”。5.4 小技巧速查表场景症状快速解法AI跑题生成内容不是你想要的范围检查提示词是否包含“不要做什么”清单输出带多余解释代码混在说明文字里要求“只输出代码不要额外说明”上下文遗忘后期代码违反早期约定把约定写入外部文档新会话开头粘贴API名称错误调用不存在的方法要求AI给出版本出处或改用你提供API列表生成过于复杂代码比需求本身还长几倍明确最小实现要求禁止额外功能中文乱码CSV/文本文件内容错乱检查编码必要时候指定utf-8-sig我自己最常犯的错是默认AI看懂了所有上下文。后来每次写提示词之前我都会问自己一个问题如果这句话是发给项目组新来的实习生他能完成任务吗如果答案是“不能”那说明提示词还需要再补。AI编程工具本质上就是把这个标准动作放大到了极高的速度你给它的上下文质量决定了它回传给你的代码质量。经过这些实践我的体会是与其把AI看成“取代程序员的技术”不如把它看成“让程序员更像技术架构师”的催化器。你被从重复代码里解放出来后真正要做的是把问题想清楚、把边界设定好然后把执行交给工具把决策权牢牢留给自己。 
长河君 · 2026/10/13 18:40:38 · 阅读 1.2k AI编程工具实战指南：从选型到高效工作流
刚开始接触AI编程工具时我和很多人一样是带着抵触情绪的。写代码写了那么多年自动补全用了一堆什么智能提示、代码联想说白了就是“高级版输入法”真正复杂的业务逻辑它帮不上忙有时候还会给出莫名其妙的建议让人越改越乱。真正让我改变看法的是一次临时接手的旧接口迁移任务。那批接口数量大、逻辑相似、字段映射琐碎如果全靠手写一天都不一定写得完。我抱着试一试的心态把需求拆开喂给AI编程工具结果几个小时就出了可运行的骨架我再逐段审查、改边界、补异常整个任务当天就收工了。那之后我慢慢形成一个习惯不把AI当“自动写代码机”而是当成一个随叫随到的“快速实习生”。你给它越清晰的任务说明它越能给到可用的产出你越是笼统地说“写个系统”它就越可能给你一个华丽但落不了地的玩具。这篇文章我想聊的就是这三件事AI编程工具到底怎么选使用过程中该建立什么样的方法论以及如何把它们组合成一条可重复落地的工作流。如果你已经开始用AI写代码但总觉得效率提升有限、生成结果不稳定或者还在观望不知道怎么入手这篇内容应该能给你一些参考。1. AI编程工具怎么选先搞清楚形态再谈效率很多人选AI编程工具的时候容易盯着“哪个品牌强”“哪个模型新”“哪个通过率更高”这类指标但忽略了一件更基础的事你手上的任务到底是什么形态需要的是哪种类型的工具。选错工具和用扳手拧螺丝有点像不是不能用但一定别扭。1.1 三种主流形态对应三类场景我按实际使用方式把AI编程工具粗略分成三类编辑器内嵌的代码补全型、对话问答型、以及终端命令行型。它们解决的是不同粒度的问题不能互相替代。代码补全型在编辑器里跟着光标实时预测下一段代码。适合写样板代码、重复性结构、熟悉语言里的句式比如for循环、SQL查询、JSON序列化、常见正则。它的价值是“少打字”对手感的提升最直接但对架构层面的事基本帮不上忙。对话问答型以多轮聊天的方式交互可以贴代码、贴报错信息、问方案、做Code Review。适合处理“需要理解上下文”的任务比如解释一段陌生代码、设计一个模块结构、讨论某个技术选型。它是最通用的形态也是我日常用得最多的。CLI终端型直接在命令行里调用可以指定文件、目录做批量重构、生成单元测试、分析项目结构。适合需要把AI能力嵌入脚本和自动化流程的场景比如持续集成里自动生成变更说明、批量给旧代码补注释。三种形态不是同一件事的不同包装它们的交互模型差别很大。补全型依赖“你正在打字”的即时反馈适合微操对话型依赖“你问一个完整问题”适合设计命令行型适合“给明确路径和文件范围”的任务适合工程化。我现在的组合方式是编辑器里的补全功能常开用来处理手头正在写的代码对话型工具放在另一个窗口需要方案讨论、逻辑梳理、代码审查的时候用命令行型则在批量任务和自动化脚本里调用。形态擅长任务典型短板适合人群代码补全局部代码、样板代码、语法填空不理解全局设计无法处理跨文件改动日常写代码最多的开发者对话问答方案讨论、代码解释、报错分析、Code Review受上下文长度限制长会话会遗忘早期约定需要整体思考的开发者命令行批量重构、测试生成、项目级分析交互不够直观需要明确指定范围有自动化脚本经验的人1.2 选型避坑经验我在工具选型上踩过的坑主要有三个。第一别被演示效果带偏。很多AI工具的官方演示都是精心挑过的场景看起来一次生成一整段完美的业务代码但你拿自己真实的项目一试结果完全不一样。我后来总结了一个方法准备一个“测试集”包含你项目里最有代表性的三个小任务一个用你用得不熟的语言写的一个涉及复杂配置的一个需要访问某种API的。切换工具时用同一套任务做横向对比只看实际产出不看宣传片。第二注意代码安全和隐私边界。把公司核心代码贴进公网的对话型工具是有泄露风险的。我在某公司实习时明确规定过敏感算法模块绝不能贴给外部工具只允许用本地部署的方案处理。这个约束要提前想清楚不能等代码都贴上去了才发现问题。工具选型时先问一句这个工具的数据处理链路是什么能不能本地化历史会话会不会被用于训练。第三控制工具数量。不要同时订阅五六个AI编程工具然后每天都在切换和对比。工具是拿来用的不是拿来评测的。我个人保留两套组合就够了一套是常用的编辑器补全对话助手另一套是本地部署的模型专门处理敏感代码和离线场景。多了反而是负担。2. 方法论让AI输出可控的四个关键动作工具选得再好如果方法不对AI生成出来的代码依然会让人血压升高。我把和AI协作的过程总结成四个关键动作拆需求、设边界、控上下文、切小步。这几个词看起来简单但每一个背后都有具体的操作技巧。2.1 先拆需求再写提示词AI不理解你的业务它只理解你写出来的文字。你给它一句“帮我写个用户管理系统”它就默认按照教科书里的用户、角色、权限泛化设计来写大概率不是你真正想要的。正确的做法是先把需求拆成AI能执行的粒度再写提示词。我常用的提示词结构大概是这样的角色你是一个熟悉Python的资深后端工程师。任务目标请实现一个函数输入为订单列表JSON文件路径输出为CSV文件。输入数据结构给出JSON的具体字段和类型。输出要求CSV包含哪些列、列名是什么、日期格式是什么。约束条件只使用标准库不要引入第三方依赖不要修改输入文件错误统一抛出自定义异常。验收标准写一个简单的示例调用包含正常输入和空输入两种情况。这样写出来的提示词AI回复的代码质量会稳定很多。对比一下“帮我导出一个CSV”和上面这段产出完全是两个级别。前者AI会自己脑补一大堆不确定的参数后者它只需要按规则填充就好。2.2 明确边界告诉AI什么不该做这一点容易被忽略。给AI列“允许做什么”之外还要列“不允许做什么”。因为AI生成代码的时候有种倾向就是“过度补全”。你让它写一个导入脚本它可能会自己加上日志、多线程、重试机制、配置文件解析看起来高大上但你的项目根本不需要这些反而增加了排查问题的难度。我处理过一个真实的例子让AI生成一个批量处理图片缩略图的脚本结果它自动加了基于内存的队列、多线程池、优雅关闭逻辑代码长度翻了三倍。后来我在提示词里明确加了一句“不要使用多线程不要引入第三方库只同步逐个处理”生成结果一下就干净了。设定边界还有一个好处降低AI犯错的概率。当你明确告诉它“不要用某个库”“不要动某个目录”它就不会往那个方向试探。方法是在提示词里单独开一段“约束与限制”清单每一条都是明确的可执行语句而不是模糊的“注意代码质量”。2.3 控制上下文把约定写下来而不是指望AI记住对话型AI有一个绕不开的问题就是上下文窗口有限。你会发现一个会话聊得时间长了它渐渐忘了最早讨论过的技术栈、命名规范、目录结构甚至会前后矛盾。这不是它变笨了而是它的注意力被后面的大量信息稀释了。我的解决办法是把关键约定“外部化”。不要让AI在对话里记约定而是把约定写在一个文件里每次开启新会话时贴给AI或者直接告诉它去读项目里的某个文档。比如项目中维护一个docs/ai-conventions.md里面记录技术栈、目录结构、代码风格、禁止使用的库、常用命名规范。每次开始一个新任务第一件事就是把这份文件内容粘进对话。还有一个小技巧让AI先复述你的需求。别急着让它写代码先让它用自己的话说一遍它理解的任务、约束和验收标准。如果复述的内容有偏差这时候纠正成本最低。等它确认理解一致了再让它开始动手。2.4 分批处理一次只让AI做一件小事经常有人抱怨“让AI写一个完整模块结果代码根本跑不起来”。这太正常了因为一个完整模块里包含太多隐含假设和关联设计只要有一个地方前后不一致整段代码就废了。正确做法是把模块拆成多个小任务一步一步来。我这里说的“小”具体到什么程度呢比如一个“用户管理”模块我不会让AI一次写全部而是拆成四步写数据库表结构定义写数据访问层包括增删改查写业务层的注册逻辑包含邮箱校验和密码加密写接口层包含参数校验和错误返回每一步生成完以后我先审查、跑通、确认没问题再进行下一步。这个过程很像带新人一次交代一件事验收完再给下一件。AI不是全知全能的协作伙伴它的工作记忆和推理稳定性撑不起超大规格的任务把它当成快速但需要频繁确认的实习生效果反而更好。3. 工作流设计从提示词到可维护代码的完整闭环有了工具、有了方法还要把它们装进一条固定的工作流里才能在团队里复制也才能保证每次产出质量稳定。我把自己跑顺的流程整理成了五个步骤。整个过程看起来有点重但对于真正要交付的项目每一步都不能省。3.1 我的五步工作流第一步需求澄清与拆分。拿到一个任务先不要打开编辑器也不要打开AI工具。拿一张纸把目标写清楚列出输入、输出、约束、验收标准。这个动作花的时间通常不超过15分钟但它决定了后续AI生成的代码是不是贴题。只有人能想清楚的任务才有资格交给AI。第二步方案设计。在纸上或者文档里先勾出一个大致的结构分几个模块、每个模块的职责是什么、模块之间的接口怎么约定。这一步不需要非常细有个大方向就行。然后把这个方案结构喂给AI让它补充遗漏点。这时候AI的价值是“查漏”和“扩展”而不是“从零发明”。第三步AI生成与人工改造。按上一节说的方式拆成小任务逐个让AI生成。生成以后我会逐行读一遍把不符合项目风格的代码改掉。这一步的判断标准是这段代码如果是我自己写的我能不能接受它合入主干。接受不了就让AI重写或者自己动手改。第四步验证与测试。AI生成的代码跑通主流程只是开始还要补测试、测边界、测异常输入。我通常会让AI自己设计测试用例但测试用例我会人工过一遍因为AI有时会顺着功能的思路写测试测不到真正的边界问题。关于这一点下一节还会详细展开。第五步记录与沉淀。任务完成后把这次用到的提示词、遇到的坑、修改的关键点整理保存下来。这一步最容易被跳过但长期来看收益最大。我建了一个自己的“AI提示词模板库”按任务类型分类写函数、写测试、解释代码、重构模块、排查报错。时间久了写新任务的开销会小很多。3.2 代码审查把AI当成“快速实习生”而不是“权威专家”AI生成的代码在语法上通常没什么问题真正的问题隐藏在逻辑里。我审查AI代码时重点看五个地方输入校验是否对空值、类型错误、越界情况做了处理。异常处理出错时是直接崩溃还是有明确的错误信息。资源释放文件、网络连接、数据库连接是否正常关闭。性能隐患有没有循环里做重复查询、不必要的数据拷贝。边界条件空列表、单元素列表、超大输入是否都能正确处理。这五个点写成一个固定的审查清单每次审查AI代码时逐条对照。一开始觉得麻烦但用过几次就会发现AI生成代码的“事故高发区”基本都集中在这几个地方尤其是边界条件和异常处理。还有一个反向提问技巧代码生成后直接问AI“这段代码有哪些潜在问题请按严重程度列出”。你会发现它自己也能指出一些坑。虽然它不一定全部找出来但至少能帮你打开思路。3.3 反向验证让AI证明自己的代码是对的比直接审查更进一步的做法是让AI为自己的代码写测试。写出来的测试再反过来验证代码逻辑是否通顺。这种“自己出题自己答”的方式能在提交之前暴露不少问题。更有效的一种方式是“交叉验证”用一个会话生成代码用另一个会话的干净上下文去审查同一段代码。因为第二个会话没有看过生成过程不会带着生成时的思路走更容易发现逻辑漏洞。我经常把同一个函数分别丢给两个不同会话让它们各自找问题然后合并去重。效果比我自己埋头检查好很多。要注意的是不要被AI自信的回答迷惑。你问它“这个实现有问题吗”它大概率会说“目前看起来是ok的需要注意边界情况”。这种回答没有参考价值。所以要问具体问题“如果输入是一个0字节的文件会发生什么”“如果文件路径不存在这个函数会抛什么异常”只有具体到场景的问题AI的回答才有信息量。4. 实操记录用AI从零实现一个数据导出小工具前面的内容多少有点抽象我拿一个真实的例子走一遍完整流程。这次任务是做一个命令行小工具读取一个JSON文件里面是订单数据导出一个CSV文件但要做字段映射、日期格式化还要处理嵌套对象并且只能用标准库目标是以后能批量处理一批文件。4.1 需求澄清与拆分我先写下了需求输入JSON文件内容是订单列表每条订单包含order_id、created_at、customer、items等字段。输出CSV文件但输出的列名需要是中文表头并且customer是嵌套对象需要拆成customer.name和customer.contact两个字段。约束只使用标准库不引入任何三方依赖支持命令行参数指定输入输出文件路径异常时给出明确中文报错信息并退出。拆成小任务先做一个通用的“JSON转带映射CSV”的核心函数再做命令行参数处理最后处理嵌套字段展开。这三个任务都是可在10分钟内完成的小粒度任务。4.2 提示词与AI生成过程我给AI的第一个提示词大概是这样的角色擅长Python的工程师。任务实现一个函数接收两个参数json文件路径和csv输出路径。JSON文件内容是一个对象数组每个对象包含order_id、created_at、customername和contact、items数组。输出CSV时列名为订单号、创建时间、客户姓名、客户联系方式、商品数量。创建时间格式为YYYY-MM-DD HH:mm:ss。约束只用标准库不要用第三方库不要改动原JSON文件如果输入文件不存在或JSON格式错误抛出带中文信息的异常。验收生成完成后给出一个可直接运行的命令行入口。AI生成的核心逻辑大体可用但有两个地方需要改。第一个问题是它用了csv.DictWriter对于嵌套字段需要预先展开它直接把整个嵌套结构塞进去了导致输出不符合预期。我纠正了它的实现方式要求先做字段映射和展开再写入表格。第二个问题是它在处理中文字段名时没有设置UTF-8-sig编码生成的CSV用表格软件打开会出现中文乱码这在Windows平台上是经典问题。加上encodingutf-8-sig之后就正常了。4.3 踩到的典型问题和解决方案这个项目过程中踩了三个值得记录的坑都是AI生成代码时容易“想当然”的地方问题一AI喜欢引入不必要的依赖。第一版生成时它试图用第三方库来解析JSON和写CSV。我明确说了“只用标准库”之后它改成了json和csv。这类问题出现的频率非常高解决方式只有一个把约束写得极其明确。问题二嵌套字段展开不够灵活。当我要展开customer.name时AI直接写死了字段路径没有做通用映射。我要求它改为接收一个“字段映射表”参数核心逻辑变成根据映射表递归取值。这样改造之后以后导其他类型的数据也能复用不再需要为不同报表各写一套代码。问题三缺少错误处理。AI默认了文件一定存在、JSON格式一定正确。我给它补上“输入不存在时给出明确提示并退出”的约束它才在入口函数里加了判断逻辑。这件事提醒我AI不会主动考虑异常场景除非你在需求里说了。整个过程做完包含我自己改代码和测试的时间大约花了一个下午。如果完全手写差不多要到第二天。更重要的是这套结构化的提示词和流程在后续类似任务中都能复用边际成本越来越低。5. 常见问题与排查技巧实录最后整理一份我日常使用AI编程工具时的常见问题速查表这些问题不特定于某个工具更多是在协作过程中反复出现的模式。5.1 提示词明明很详细AI还是跑偏先检查是不是缺少“输出格式”约束。AI是文本模型你让它“写一段代码”它默认会附带很多解释文字甚至给你提供多套方案而不是只给代码。如果你在提示词末尾加一句“只输出可以直接运行的Python代码不要解释”它就会收敛很多。再检查示例是否充分。给一个输入输出的示例会大幅减少歧义。比如你要求“把日期格式改成2024-01-01”但没说原来的格式长什么样它只能靠猜。贴一条真实样例数据进去它就会照着格式处理。如果还是跑偏那就拆小。把一个大任务拆成两个小任务分别确认结果再合并。我和AI协作的前期大部分“不靠谱”都是因为一次性喂了太多信息把AI“撑晕了”导致的。5.2 长会话中AI忘记早期需求典型表现是前十分钟还约定得很好后二十分钟开始出现违反约定的代码比如用了禁止的库、改了不相关的文件、字段命名忽而英文忽而中文。这是上下文长度导致的不用怀疑AI智商。解决办法刚才提过两次这里再强调一遍重要约定写在外部文档里每个新会话开始时贴给AI或者让AI按“复述-确认-执行”的流程工作。我自己维护的ai-conventions.md大约20行每次开新会话前复制粘贴两秒钟的事但可以省掉后面大量返工时间。5.3 怎样识别AI的“幻觉代码”“幻觉代码”就是你让它调用一个不存在的API或者编造一个不存在的方法名、参数名、函数行为。这种问题在涉及不常见库、新版本API、或者内部开发的接口时尤其容易发生。第一道防线在提示词里明确写“如果你不确定某个API存在请直接说不确定不要猜测”。这条约束不是绝对有效但能减少一部分编造。第二道防线生成后立刻做“编译/测试验证”不要肉眼看一遍觉得没问题就合入。把AI生成的代码放进独立的测试环境里跑一遍是最直接的检测方式。第三道防线让AI说明代码的依据。问它“这个函数是哪个版本引入的列出参数签名”。如果它回答得含糊或者给的版本信息对不上基本可以判定是编造的。这类问题排查多了你会形成一种肌肉记忆对于AI写的代码默认“先验证再信任”而不是“先信任再报错”。5.4 小技巧速查表场景症状快速解法AI跑题生成内容不是你想要的范围检查提示词是否包含“不要做什么”清单输出带多余解释代码混在说明文字里要求“只输出代码不要额外说明”上下文遗忘后期代码违反早期约定把约定写入外部文档新会话开头粘贴API名称错误调用不存在的方法要求AI给出版本出处或改用你提供API列表生成过于复杂代码比需求本身还长几倍明确最小实现要求禁止额外功能中文乱码CSV/文本文件内容错乱检查编码必要时候指定utf-8-sig我自己最常犯的错是默认AI看懂了所有上下文。后来每次写提示词之前我都会问自己一个问题如果这句话是发给项目组新来的实习生他能完成任务吗如果答案是“不能”那说明提示词还需要再补。AI编程工具本质上就是把这个标准动作放大到了极高的速度你给它的上下文质量决定了它回传给你的代码质量。经过这些实践我的体会是与其把AI看成“取代程序员的技术”不如把它看成“让程序员更像技术架构师”的催化器。你被从重复代码里解放出来后真正要做的是把问题想清楚、把边界设定好然后把执行交给工具把决策权牢牢留给自己。