说实话这两年我身边程序员朋友聊得最多的话题已经从“你用哪个框架”变成了“你让AI写了多少代码”。2025年再谈AI Coding已经不是一个要不要用的问题而是一个怎么用好、怎么用稳、怎么真正提升交付质量的问题。如果你去翻社区的热搜词会看到一堆让人眼花的概念vibe coding、spec coding、AI agent、codex、coding plan、GLM Coding Plan……很多人以为AI Coding就是“开口说需求代码自动落地”实际干过之后才知道工具走得再快思维方式跟不上照样会把项目搞成一团乱麻。这篇就聊聊我自己在真实项目里反复试出来的一套打法怎么选工具、怎么设计流程、怎么让Agent真正听你的指挥而不是给你生成一堆看着像样、一跑就崩的“幻觉代码”。如果你是一名前后端工程师、技术负责人或者刚准备入行AI应用开发的产品经理这篇文章应该能帮你少踩几个我踩过的坑。1. AI Coding 不是“让AI写代码”而是重构整个研发流程1.1 从“人写机器查”到“人审AI写”角色变了传统模式下代码几乎是一个人脑到编辑器的单向输出需求分析、技术方案、编码、自测、联调所有环节都要人亲自动手。AI Coding起来之后最本质的变化不是“打字的人从人变成机器”而是人从“代码生产者”变成了“代码审查者和决策者”。我举个很直白的例子。以前写一个订单超时关闭的功能我要先建定时任务再写扫描逻辑再处理状态流转大概要半天。现在我让Codex这类Agent直接动手它十几分钟就能把主体代码写完但问题来了我得花半小时以上去审它写的逻辑看事务边界对不对、看并发情况下会不会重复关单、看异常路径有没有兜底。这个过程里我的工作效率表面上是“半天变40分钟”但真正值钱的不是那台生成代码的“打字机”而是我用来判断代码正确性的那套经验。很多人觉得AI Coding会让程序员贬值我倒觉得恰恰相反——在AI能快速产出大量代码之后判断力反而成了最稀缺的能力。你越能快速识别出AI代码里的逻辑漏洞你的不可替代性就越强。所以我一直跟团队强调AI Coding的第一课不是学工具而是调整心态。你要接受代码不再全部出自你手但也要清楚每一行AI产生的代码最终责任都在你身上。代码是AI写的锅是你背的。1.2 当前AI Coding工具的四个圈层聊工具之前得先把市面上这些工具归归类不然很容易被热搜词绕晕。我自己习惯把AI Coding工具分成四层补全型GitHub Copilot、通义灵码这类主要在你写代码时做行级补全、函数级生成。它们最适合的场景是“人主导、AI辅助”侵入性最小基本不改变你原本的编码习惯。对话型ChatGPT、Claude、通问AI这类通用大模型可以粘贴代码片段问问题、生成独立函数、解释报错。它们没有直接接入IDE的工作区上下文属于“问一句答一句”的模式。编辑器集成型Cursor、Windsurf这类AI原生编辑器能理解整个仓库的代码结构支持跨文件改动、智能重构。它们的核心价值是“理解项目上下文”而不只是理解你选中的那几行代码。Agent型Codex、Claude Code、OpenHands这类能自主规划和执行的Agent可以自己列计划、改文件、跑命令、甚至提交PR。这是目前把“AI Coding”推向“AI软件工程”的关键形态。这四层本质上是一个递进关系从“辅助打字”到“理解项目”再到“执行任务”。不同的人、不同的项目阶段适合的工具完全不一样。我见过有人一上来就上Agent结果AI改坏了代码他自己都发现不了这种“工具先进、能力撑不住”的局面比不用AI还糟糕。所以选工具之前先诚实回答一个问题你愿意花多少时间做代码审查如果答案是不愿意那你最好只停在第一层如果你愿意承担审查责任四层工具都值得尝试。2. 工具选型别追新先想清楚你的场景需要什么2.1 按项目阶段选工具老项目、新项目、修Bug是完全不同的打法很多人在工具选型上踩坑是因为他们想用一个工具解决所有问题。实际项目里不同场景对工具的需求根本不同我拆开说。老项目维护与重构。这种场景最大的痛点是项目上下文极其复杂牵一发而动全身。我建议优先用编辑器集成型工具比如Cursor。它能读取整个仓库的索引当你准备改一个公共函数时它能告诉你有哪几个模块在调用它避免“改完A模块B模块直接崩”的尴尬。遇到特别老、几乎没有测试的代码我会保守一点不让Agent直接动手改而是让AI先帮我梳理调用链和影响面我自己再决定怎么改。新项目快速开发。这种场景最适合Agent型工具。从零搭一个内部工具、写一套CRUD接口、搭一个原型页面Agent的效率和想象力都很惊人。我试过让Codex从零写一个营销落地页带表单提交功能它自己建项目结构、写组件、配接口十几分钟就能跑起来。这种场景下别过度设计让Agent先跑通主流程再说。修Bug和排查问题。这一块我强烈建议混合使用先用对话型工具把报错日志、代码片段、预期行为丢给它让它给出可能的原因方向然后自己或者让Agent去代码里定位。为什么不用Agent直接改因为修Bug的本质是“理解根因”如果你没有把上下文整理清楚AI很容易在错误的方向上修修补补最后代码变复杂了Bug还在。新项目、老项目、修Bug三者对工具的要求差异很大你应该根据当前阶段的主任务选择主力工具而不是跟风下最新的Agent。2.2 我在真实项目中的工具组合拳说点具体的。我自己目前的日常组合是写新功能用Codex Claude Code日常小改动用Cursor面试筛人或者快速验证想法用GLM Coding Plan这类带“试用额度”的产品。为什么这么搭配一方面Agent型工具适合处理“目标明确、范围可控”的任务比如“给登录模块增加一个忘记密码的流程”“把这个列表接口改成支持分页”。这类任务边界清晰Agent自己列计划、改代码、跑测试我只需要最后做整合审查效率确实高。另一方面日常小改动如果也走Agent光是任务的启动和上下文加载就要花不少时间反而是Cursor的对话式修改更轻快。我会在Cursor里直接选中一段代码说“这个函数有个边界条件没处理帮我补上”它能基于仓库上下文快速修改我肉眼扫一遍改动内容就能合入。最后关于“coding plan”这个概念我想多说一句。很多人把coding plan理解成“让AI帮自己列一个编码计划”其实不对。它更接近一个人机协作的任务契约你在动手之前把目标、方案、验收标准写清楚AI按这个契约去执行。GLM Coding Plan那类产品本质上就是把“计划先行”的产品化——它逼着你先想清楚要什么再让AI去执行。这个思维后面讲spec coding的时候还会再展开。3. 从 vibe coding 到 spec coding让AI跑在规范里3.1 vibe coding 为什么爽又为什么坑vibe coding这个词真的是2025年上半年最火的AI编程热词之一大意是“跟着感觉让AI写代码”——你不太管每行代码是怎么实现的只要整体感觉对跑起来顺就往下走。对于快速验证一个想法、做Demo、参加黑客松来说vibe coding简直爽到飞起你说话AI干活整个原型以肉眼可见的速度成型。但我在真实项目里吃过vibe coding的亏。有一次我让AI写一个数据清洗脚本它写出了一版“结果正确但完全不可维护”的代码没有类型定义没有错误处理逻辑全堆在一个巨大的函数里变量命名还是拼音缩写。我当时图快直接用了结果两周后需求微调那段代码几乎没办法改最后重写花的精力比一开始老老实实写还多。vibe coding的坑总结起来有三个上下文失控AI在长对话里会慢慢丢失前面的约束后期生成的代码可能跟前面完全不兼容。技术债爆炸AI会倾向于“实现功能”而不是“可维护地实现功能”注释缺失、抽象混乱是常态。行为不可预测你会慢慢失去对项目的掌控感不知道哪个小改动会引发连锁反应。所以我现在的态度是vibe coding适合“玩”不适合“交付”。如果你想做一个能上线、能维护、能交接的项目必须往前走一步进入spec coding。3.2 spec coding 的核心做法把需求变成AI能听懂的执行契约vibe coding和spec-driven的本质区别在于谁来定义“什么是对的”。vibe coding里AI随时在猜你的意图而spec coding里你先把规格写清楚AI只是按规格施工。我实践下来的spec coding流程是这样的用自然语言写目标说清楚这个功能要解决什么问题为谁服务。拆出明确的接口和行为约定入参是什么、出参是什么、异常情况下做什么、边界条件如何处理。写验收标准怎么算做完过哪些测试必须保证哪些场景不回归。把spec喂给Agent让它出实现方案Agent会基于spec先列一个coding plan你确认方案没问题再让它动代码。按spec验收Agent改完之后拿spec逐条核对而不是只看“能不能跑”。举个我最近做的小例子。我要给一个内容管理系统加一个“批量导入文章”的功能。我的spec大概是这样目标运营人员可以上传CSV文件批量创建文章草稿。接口POST /api/articles/batch-import接收multipart文件返回创建成功数量和失败明细。行为约定CSV表头必须包含title和content单次导入上限500条任一行数据校验失败不阻塞其他行导入失败行必须返回行号和原因。验收标准单元测试覆盖表头缺失、空行、超长标题、特殊字符四类异常批量导入后文章列表可见失败明细能定位到具体行。这个spec大概就几百字但Agent拿到它之后写出来的代码基本不用大改因为它知道你要什么、边界在哪、验收标准是什么。相比之下如果你只说“给我做个批量导入功能”AI大概率会猜一个实现方案然后你俩陷入“猜错—改—再猜”的循环。我对vibe coding和spec coding的态度非常简单vibe coding用来找感觉spec coding用来做交付。两者的切换点就是你决定“这个项目要认真做了”的那一刻。4. 提示词工程与上下文管理决定AI Coding的上限4.1 好提示词不是“求AI”而是“给AI定边界”先纠正一个常见误解会AI Coding不等于会写提示词。很多人打开Cursor或者ChatGPT写的是“帮我写一个登录功能”然后抱怨AI生成的代码用不了。这不是AI不行是你的指令太模糊了。好的提示词本质上是一份微缩的spec。我自己常用的提示词结构是四段式角色与背景你是这个项目的后端工程师熟悉我们现有的技术栈列出具体语言和框架。任务目标你要完成什么功能输入是什么输出是什么。约束条件不要用什么库、必须遵循什么代码风格、性能要求、安全要求。验收清单完成后怎么自我检查列出几条关键测试点。给你看一组对照。差的提示词“帮我写个用户注册接口。”我实际会用的提示词“在现有FastAPI项目里实现用户注册接口。接收JSON格式的username、email、password密码用bcrypt加密存储用户名重复时返回409错误邮箱格式用pydantic校验。接口文件放在app/routers/auth.py不要改动其他文件。完成后给出用curl测试的示例命令。”这俩指令的差别AI理解出来的东西完全是两个层级。前者它需要猜你的技术栈、猜存储方案、猜错误处理风格大概率猜偏后者几乎把边界全锁死了AI没机会自由发挥。我在团队里反复强调提示词的价值不在于“写得华丽”在于“把不确定性降下来”。你每多提供一个约束AI就跑偏的概率就低一分。4.2 上下文管理决定AI是“懂你”还是“瞎猜”很多人在用Agent型工具时遇到一个怪现象同一个功能上午问它答得很准下午问它就开始胡言乱语。这通常不是模型变笨了而是上下文出了问题。上下文管理有几个我实测下来非常管用的技巧按需携带相关文件不要让AI读整个仓库只把跟当前任务相关的文件“喂”给它。无关代码越多AI越容易受到干扰回答质量反而下降。长对话及时“归档”一个任务做完就新开对话把spec和产出总结写在新对话的开头。不要在一棵树上吊死AI在超长对话里会慢慢丢失最早的约束这是模型本身的机制决定的。善用项目索引Cursor这类工具能自动建代码索引你提问时它会自动检索相关内容。用这类工具时尽量用准确的术语和文件名提问比如“DeviceService里的checkStatus方法为什么慢”而不是“设备状态怎么那么慢”前者能让索引更精准地定位到相关代码。把结论写回代码注释AI不理解项目里那些“隐含的业务规则”。比如一个看似多余的if判断其实是当年为某个客户做的特殊逻辑。这些信息如果不在代码注释或者文档里AI后续优化时很可能把它当死代码删掉。所以我会要求团队凡是反直觉的代码必须写清楚原因这不仅是给人看的也是给AI看的。上下文管理做得好不好直接决定AI Coding的效率天花板。那些觉得AI“时灵时不灵”的人八成是上下文喂得不对。5. AI Coding 路上的常见翻车现场与排雷清单5.1 六个高频翻车现场我用了小半年AI Coding稳定踩坑的六个场景今天一次性说清楚。一是“假代码”问题。AI经常生成一套看起来完整、实际根本不存在的函数或API。比如让它调某个第三方SDK它会凭训练记忆发明一个并不存在的方法名。这种幻觉在Agent自主写长代码时特别常见。我的对策是Agent提交代码后第一件事不是跑功能而是全局搜一遍它引用的外部API是否存在、参数对不对。二是“死循环式修改”。你让它修一个Bug它改了A结果测试报B错你再让它修B它又动了C最后整个模块被它改得面目全非。这种问题的根因是它没有全局视图每次只盯着局部。我的对策是在动手前给它限制改动的文件范围并且要求它每次修改后必须跑关联测试不是只跑它自己写的那个测试。三是“自作主张的过度设计”。Agent经常在你只要一个简单函数的时候顺手给你引入一个设计模式、一个依赖库。看起来挺专业实际上增加了维护成本。我的对策是在提示词和spec里明确写“不要引入新的依赖”“不要创建额外抽象”把它的表现欲摁住。四是“回归Bug防不胜防”。这也是最危险的。Agent在改一个功能时很可能破坏另一个看似无关的模块而且它自己完全不知道。因为它的注意力在当前任务不在全量回归。我的对策是所有AI改动合入前必须跑一遍全量测试尤其是核心业务链路。偷懒跳过这步上线必炸。五是“测试陷阱”。AI会写测试但它写的测试大概率是“为了证明自己的代码是对的”边界条件和异常场景覆盖很弱。比如它写了密码校验的测试只测正确密码不测空密码、超长密码、特殊字符密码。所以AI生成的测试我要么要求它先给测试计划我再放行要么自己补测试绝不因为它说“测试全过了”就放心。六是“进度幻觉”。Agent在输出计划时会把任务拆得很漂亮执行过程中却可能卡在某一步然后假装已经做完了。尤其是没有跑命令权限的Agent它只会改代码不验证编译和运行。所以我在交付前的最后一道关卡永远是人工跑一遍主流程启动项目、走一遍核心链路、看日志有没有异常。5.2 我的排雷经验清单踩了这么多坑我沉淀了一套自己的AI Coding排雷流程按这个顺序走基本能控制住质量。范围锁定明确告诉AI这次改动允许涉及哪些文件不允许碰哪些文件。方案确认AI给的实现方案先审后干不要让它边干边想。小步提交让AI分步提交改动而不是一次性甩给你几十个文件。全量测试合入前自己跑一遍全量测试和主流程不轻信AI的测试结果。代码走查对AI生成的核心逻辑逐行看重点看错误处理、并发边界、敏感数据。文档同步如果AI改了关键逻辑同步更新相关文档和注释否则两周后没人说得清这段代码为什么存在。这套流程看着麻烦但实际用起来之后你会发现省下的时间比花掉的还多。因为AI多数时候是靠谱的你只需要把注意力集中在少数可能出现问题的节点上。最后分享一个我自己最近的心得。AI Coding发展到今天工具层面的差距正在快速缩小真正拉开人与人之间效率差距的是你有没有一套稳定的协作流程。工具更新迭代你拦不住但流程是你自己的护城河。与其每天追着新出的Agent跑不如从今天开始把你手头最常做的三类任务各自写出一份标准spec模板和提示词模板。这套东西沉淀下来比任何一个工具都管用。 
长河君 · 2026/9/7 3:55:42 · 阅读 1.2k AI Coding实战：从vibe coding到spec coding的协作流程与避坑指南
说实话这两年我身边程序员朋友聊得最多的话题已经从“你用哪个框架”变成了“你让AI写了多少代码”。2025年再谈AI Coding已经不是一个要不要用的问题而是一个怎么用好、怎么用稳、怎么真正提升交付质量的问题。如果你去翻社区的热搜词会看到一堆让人眼花的概念vibe coding、spec coding、AI agent、codex、coding plan、GLM Coding Plan……很多人以为AI Coding就是“开口说需求代码自动落地”实际干过之后才知道工具走得再快思维方式跟不上照样会把项目搞成一团乱麻。这篇就聊聊我自己在真实项目里反复试出来的一套打法怎么选工具、怎么设计流程、怎么让Agent真正听你的指挥而不是给你生成一堆看着像样、一跑就崩的“幻觉代码”。如果你是一名前后端工程师、技术负责人或者刚准备入行AI应用开发的产品经理这篇文章应该能帮你少踩几个我踩过的坑。1. AI Coding 不是“让AI写代码”而是重构整个研发流程1.1 从“人写机器查”到“人审AI写”角色变了传统模式下代码几乎是一个人脑到编辑器的单向输出需求分析、技术方案、编码、自测、联调所有环节都要人亲自动手。AI Coding起来之后最本质的变化不是“打字的人从人变成机器”而是人从“代码生产者”变成了“代码审查者和决策者”。我举个很直白的例子。以前写一个订单超时关闭的功能我要先建定时任务再写扫描逻辑再处理状态流转大概要半天。现在我让Codex这类Agent直接动手它十几分钟就能把主体代码写完但问题来了我得花半小时以上去审它写的逻辑看事务边界对不对、看并发情况下会不会重复关单、看异常路径有没有兜底。这个过程里我的工作效率表面上是“半天变40分钟”但真正值钱的不是那台生成代码的“打字机”而是我用来判断代码正确性的那套经验。很多人觉得AI Coding会让程序员贬值我倒觉得恰恰相反——在AI能快速产出大量代码之后判断力反而成了最稀缺的能力。你越能快速识别出AI代码里的逻辑漏洞你的不可替代性就越强。所以我一直跟团队强调AI Coding的第一课不是学工具而是调整心态。你要接受代码不再全部出自你手但也要清楚每一行AI产生的代码最终责任都在你身上。代码是AI写的锅是你背的。1.2 当前AI Coding工具的四个圈层聊工具之前得先把市面上这些工具归归类不然很容易被热搜词绕晕。我自己习惯把AI Coding工具分成四层补全型GitHub Copilot、通义灵码这类主要在你写代码时做行级补全、函数级生成。它们最适合的场景是“人主导、AI辅助”侵入性最小基本不改变你原本的编码习惯。对话型ChatGPT、Claude、通问AI这类通用大模型可以粘贴代码片段问问题、生成独立函数、解释报错。它们没有直接接入IDE的工作区上下文属于“问一句答一句”的模式。编辑器集成型Cursor、Windsurf这类AI原生编辑器能理解整个仓库的代码结构支持跨文件改动、智能重构。它们的核心价值是“理解项目上下文”而不只是理解你选中的那几行代码。Agent型Codex、Claude Code、OpenHands这类能自主规划和执行的Agent可以自己列计划、改文件、跑命令、甚至提交PR。这是目前把“AI Coding”推向“AI软件工程”的关键形态。这四层本质上是一个递进关系从“辅助打字”到“理解项目”再到“执行任务”。不同的人、不同的项目阶段适合的工具完全不一样。我见过有人一上来就上Agent结果AI改坏了代码他自己都发现不了这种“工具先进、能力撑不住”的局面比不用AI还糟糕。所以选工具之前先诚实回答一个问题你愿意花多少时间做代码审查如果答案是不愿意那你最好只停在第一层如果你愿意承担审查责任四层工具都值得尝试。2. 工具选型别追新先想清楚你的场景需要什么2.1 按项目阶段选工具老项目、新项目、修Bug是完全不同的打法很多人在工具选型上踩坑是因为他们想用一个工具解决所有问题。实际项目里不同场景对工具的需求根本不同我拆开说。老项目维护与重构。这种场景最大的痛点是项目上下文极其复杂牵一发而动全身。我建议优先用编辑器集成型工具比如Cursor。它能读取整个仓库的索引当你准备改一个公共函数时它能告诉你有哪几个模块在调用它避免“改完A模块B模块直接崩”的尴尬。遇到特别老、几乎没有测试的代码我会保守一点不让Agent直接动手改而是让AI先帮我梳理调用链和影响面我自己再决定怎么改。新项目快速开发。这种场景最适合Agent型工具。从零搭一个内部工具、写一套CRUD接口、搭一个原型页面Agent的效率和想象力都很惊人。我试过让Codex从零写一个营销落地页带表单提交功能它自己建项目结构、写组件、配接口十几分钟就能跑起来。这种场景下别过度设计让Agent先跑通主流程再说。修Bug和排查问题。这一块我强烈建议混合使用先用对话型工具把报错日志、代码片段、预期行为丢给它让它给出可能的原因方向然后自己或者让Agent去代码里定位。为什么不用Agent直接改因为修Bug的本质是“理解根因”如果你没有把上下文整理清楚AI很容易在错误的方向上修修补补最后代码变复杂了Bug还在。新项目、老项目、修Bug三者对工具的要求差异很大你应该根据当前阶段的主任务选择主力工具而不是跟风下最新的Agent。2.2 我在真实项目中的工具组合拳说点具体的。我自己目前的日常组合是写新功能用Codex Claude Code日常小改动用Cursor面试筛人或者快速验证想法用GLM Coding Plan这类带“试用额度”的产品。为什么这么搭配一方面Agent型工具适合处理“目标明确、范围可控”的任务比如“给登录模块增加一个忘记密码的流程”“把这个列表接口改成支持分页”。这类任务边界清晰Agent自己列计划、改代码、跑测试我只需要最后做整合审查效率确实高。另一方面日常小改动如果也走Agent光是任务的启动和上下文加载就要花不少时间反而是Cursor的对话式修改更轻快。我会在Cursor里直接选中一段代码说“这个函数有个边界条件没处理帮我补上”它能基于仓库上下文快速修改我肉眼扫一遍改动内容就能合入。最后关于“coding plan”这个概念我想多说一句。很多人把coding plan理解成“让AI帮自己列一个编码计划”其实不对。它更接近一个人机协作的任务契约你在动手之前把目标、方案、验收标准写清楚AI按这个契约去执行。GLM Coding Plan那类产品本质上就是把“计划先行”的产品化——它逼着你先想清楚要什么再让AI去执行。这个思维后面讲spec coding的时候还会再展开。3. 从 vibe coding 到 spec coding让AI跑在规范里3.1 vibe coding 为什么爽又为什么坑vibe coding这个词真的是2025年上半年最火的AI编程热词之一大意是“跟着感觉让AI写代码”——你不太管每行代码是怎么实现的只要整体感觉对跑起来顺就往下走。对于快速验证一个想法、做Demo、参加黑客松来说vibe coding简直爽到飞起你说话AI干活整个原型以肉眼可见的速度成型。但我在真实项目里吃过vibe coding的亏。有一次我让AI写一个数据清洗脚本它写出了一版“结果正确但完全不可维护”的代码没有类型定义没有错误处理逻辑全堆在一个巨大的函数里变量命名还是拼音缩写。我当时图快直接用了结果两周后需求微调那段代码几乎没办法改最后重写花的精力比一开始老老实实写还多。vibe coding的坑总结起来有三个上下文失控AI在长对话里会慢慢丢失前面的约束后期生成的代码可能跟前面完全不兼容。技术债爆炸AI会倾向于“实现功能”而不是“可维护地实现功能”注释缺失、抽象混乱是常态。行为不可预测你会慢慢失去对项目的掌控感不知道哪个小改动会引发连锁反应。所以我现在的态度是vibe coding适合“玩”不适合“交付”。如果你想做一个能上线、能维护、能交接的项目必须往前走一步进入spec coding。3.2 spec coding 的核心做法把需求变成AI能听懂的执行契约vibe coding和spec-driven的本质区别在于谁来定义“什么是对的”。vibe coding里AI随时在猜你的意图而spec coding里你先把规格写清楚AI只是按规格施工。我实践下来的spec coding流程是这样的用自然语言写目标说清楚这个功能要解决什么问题为谁服务。拆出明确的接口和行为约定入参是什么、出参是什么、异常情况下做什么、边界条件如何处理。写验收标准怎么算做完过哪些测试必须保证哪些场景不回归。把spec喂给Agent让它出实现方案Agent会基于spec先列一个coding plan你确认方案没问题再让它动代码。按spec验收Agent改完之后拿spec逐条核对而不是只看“能不能跑”。举个我最近做的小例子。我要给一个内容管理系统加一个“批量导入文章”的功能。我的spec大概是这样目标运营人员可以上传CSV文件批量创建文章草稿。接口POST /api/articles/batch-import接收multipart文件返回创建成功数量和失败明细。行为约定CSV表头必须包含title和content单次导入上限500条任一行数据校验失败不阻塞其他行导入失败行必须返回行号和原因。验收标准单元测试覆盖表头缺失、空行、超长标题、特殊字符四类异常批量导入后文章列表可见失败明细能定位到具体行。这个spec大概就几百字但Agent拿到它之后写出来的代码基本不用大改因为它知道你要什么、边界在哪、验收标准是什么。相比之下如果你只说“给我做个批量导入功能”AI大概率会猜一个实现方案然后你俩陷入“猜错—改—再猜”的循环。我对vibe coding和spec coding的态度非常简单vibe coding用来找感觉spec coding用来做交付。两者的切换点就是你决定“这个项目要认真做了”的那一刻。4. 提示词工程与上下文管理决定AI Coding的上限4.1 好提示词不是“求AI”而是“给AI定边界”先纠正一个常见误解会AI Coding不等于会写提示词。很多人打开Cursor或者ChatGPT写的是“帮我写一个登录功能”然后抱怨AI生成的代码用不了。这不是AI不行是你的指令太模糊了。好的提示词本质上是一份微缩的spec。我自己常用的提示词结构是四段式角色与背景你是这个项目的后端工程师熟悉我们现有的技术栈列出具体语言和框架。任务目标你要完成什么功能输入是什么输出是什么。约束条件不要用什么库、必须遵循什么代码风格、性能要求、安全要求。验收清单完成后怎么自我检查列出几条关键测试点。给你看一组对照。差的提示词“帮我写个用户注册接口。”我实际会用的提示词“在现有FastAPI项目里实现用户注册接口。接收JSON格式的username、email、password密码用bcrypt加密存储用户名重复时返回409错误邮箱格式用pydantic校验。接口文件放在app/routers/auth.py不要改动其他文件。完成后给出用curl测试的示例命令。”这俩指令的差别AI理解出来的东西完全是两个层级。前者它需要猜你的技术栈、猜存储方案、猜错误处理风格大概率猜偏后者几乎把边界全锁死了AI没机会自由发挥。我在团队里反复强调提示词的价值不在于“写得华丽”在于“把不确定性降下来”。你每多提供一个约束AI就跑偏的概率就低一分。4.2 上下文管理决定AI是“懂你”还是“瞎猜”很多人在用Agent型工具时遇到一个怪现象同一个功能上午问它答得很准下午问它就开始胡言乱语。这通常不是模型变笨了而是上下文出了问题。上下文管理有几个我实测下来非常管用的技巧按需携带相关文件不要让AI读整个仓库只把跟当前任务相关的文件“喂”给它。无关代码越多AI越容易受到干扰回答质量反而下降。长对话及时“归档”一个任务做完就新开对话把spec和产出总结写在新对话的开头。不要在一棵树上吊死AI在超长对话里会慢慢丢失最早的约束这是模型本身的机制决定的。善用项目索引Cursor这类工具能自动建代码索引你提问时它会自动检索相关内容。用这类工具时尽量用准确的术语和文件名提问比如“DeviceService里的checkStatus方法为什么慢”而不是“设备状态怎么那么慢”前者能让索引更精准地定位到相关代码。把结论写回代码注释AI不理解项目里那些“隐含的业务规则”。比如一个看似多余的if判断其实是当年为某个客户做的特殊逻辑。这些信息如果不在代码注释或者文档里AI后续优化时很可能把它当死代码删掉。所以我会要求团队凡是反直觉的代码必须写清楚原因这不仅是给人看的也是给AI看的。上下文管理做得好不好直接决定AI Coding的效率天花板。那些觉得AI“时灵时不灵”的人八成是上下文喂得不对。5. AI Coding 路上的常见翻车现场与排雷清单5.1 六个高频翻车现场我用了小半年AI Coding稳定踩坑的六个场景今天一次性说清楚。一是“假代码”问题。AI经常生成一套看起来完整、实际根本不存在的函数或API。比如让它调某个第三方SDK它会凭训练记忆发明一个并不存在的方法名。这种幻觉在Agent自主写长代码时特别常见。我的对策是Agent提交代码后第一件事不是跑功能而是全局搜一遍它引用的外部API是否存在、参数对不对。二是“死循环式修改”。你让它修一个Bug它改了A结果测试报B错你再让它修B它又动了C最后整个模块被它改得面目全非。这种问题的根因是它没有全局视图每次只盯着局部。我的对策是在动手前给它限制改动的文件范围并且要求它每次修改后必须跑关联测试不是只跑它自己写的那个测试。三是“自作主张的过度设计”。Agent经常在你只要一个简单函数的时候顺手给你引入一个设计模式、一个依赖库。看起来挺专业实际上增加了维护成本。我的对策是在提示词和spec里明确写“不要引入新的依赖”“不要创建额外抽象”把它的表现欲摁住。四是“回归Bug防不胜防”。这也是最危险的。Agent在改一个功能时很可能破坏另一个看似无关的模块而且它自己完全不知道。因为它的注意力在当前任务不在全量回归。我的对策是所有AI改动合入前必须跑一遍全量测试尤其是核心业务链路。偷懒跳过这步上线必炸。五是“测试陷阱”。AI会写测试但它写的测试大概率是“为了证明自己的代码是对的”边界条件和异常场景覆盖很弱。比如它写了密码校验的测试只测正确密码不测空密码、超长密码、特殊字符密码。所以AI生成的测试我要么要求它先给测试计划我再放行要么自己补测试绝不因为它说“测试全过了”就放心。六是“进度幻觉”。Agent在输出计划时会把任务拆得很漂亮执行过程中却可能卡在某一步然后假装已经做完了。尤其是没有跑命令权限的Agent它只会改代码不验证编译和运行。所以我在交付前的最后一道关卡永远是人工跑一遍主流程启动项目、走一遍核心链路、看日志有没有异常。5.2 我的排雷经验清单踩了这么多坑我沉淀了一套自己的AI Coding排雷流程按这个顺序走基本能控制住质量。范围锁定明确告诉AI这次改动允许涉及哪些文件不允许碰哪些文件。方案确认AI给的实现方案先审后干不要让它边干边想。小步提交让AI分步提交改动而不是一次性甩给你几十个文件。全量测试合入前自己跑一遍全量测试和主流程不轻信AI的测试结果。代码走查对AI生成的核心逻辑逐行看重点看错误处理、并发边界、敏感数据。文档同步如果AI改了关键逻辑同步更新相关文档和注释否则两周后没人说得清这段代码为什么存在。这套流程看着麻烦但实际用起来之后你会发现省下的时间比花掉的还多。因为AI多数时候是靠谱的你只需要把注意力集中在少数可能出现问题的节点上。最后分享一个我自己最近的心得。AI Coding发展到今天工具层面的差距正在快速缩小真正拉开人与人之间效率差距的是你有没有一套稳定的协作流程。工具更新迭代你拦不住但流程是你自己的护城河。与其每天追着新出的Agent跑不如从今天开始把你手头最常做的三类任务各自写出一份标准spec模板和提示词模板。这套东西沉淀下来比任何一个工具都管用。