1. 当招聘JD开始写“Vibe Coding”到底在说什么前阵子帮朋友内推一个后端岗位JD里赫然出现一条“熟悉 Vibe Coding 工作流能借助 AI 编程工具独立完成模块交付。”朋友看完一脸懵问我这是不是又造出来的新词。我笑了笑说这词你其实早就在用了只是没给它起名字。所谓 Vibe Coding直译过来是“氛围编程”或者“感觉编程”核心意思不是让你闭着眼睛瞎写而是把 AI 编程工具、Agent 框架、提示词工程和 SPEC 规范这几样东西捏成一套工作流让开发者从“逐行敲代码”转向“描述意图、设定规则、审查产出”。你负责想清楚要什么、边界在哪、验收标准是什么AI 负责把大量重复的、模板化的、体力活的代码先铺出来你再做判断和收口。这套东西之所以突然被写进岗位要求是因为它实实在在改变了交付节奏——以前一个人一天能写两百行有效代码算不错了现在配合得当同样的时间能推进一个完整模块的骨架。这篇文章适合三类人看一是正在找工作、发现 JD 里冒出陌生词汇的开发者二是想把手上的 AI 编程工具真正用起来、而不是停留在“帮我写个函数”阶段的人三是团队里负责定规范、想让 AI 产出更可控的技术负责人。我会把 Vibe Coding 背后的核心领域、潜在需求、关键技术点和实际落地场景拆开讲尽量说人话也尽量给能直接抄作业的东西。先说清楚一个前提Vibe Coding 不是“不用懂代码”。恰恰相反它要求你对代码结构、依赖关系、边界条件有更强的判断力因为 AI 会给你一堆看起来对、跑起来可能出问题的东西你得能一眼看出哪里不对。它淘汰的不是程序员淘汰的是只会机械搬运、不愿意升级工作方式的那部分习惯。2. 拆解 Vibe Coding 的核心构成与选型逻辑2.1 为什么是“工具 框架 提示词 SPEC”四件套很多人第一次接触 Vibe Coding以为就是装个 AI 编程工具然后对着它说“帮我写个登录功能”。这么用当然也行但你会发现产出质量极不稳定同一个需求问三次给你三种结构改起来比重写还累。问题出在只用了四件套里的一件。我把这套工作流拆成四个层次来理解。最底层是AI 编程工具负责实际的代码生成和补全比如各类支持对话式编程的编辑器、插件。往上一层是Agent 框架与编排它决定 AI 能不能自己读文件、跑命令、看报错、再修正而不是你手动把上下文一段段喂给它。再往上是提示词工程解决的是“怎么问”的问题同样的工具提示词写得好和写得烂产出差距可能是天壤之别。最顶层是SPEC也就是规格说明它回答的是“做什么、做到什么程度算完成”这是整个工作流的方向盘。为什么必须是四件套而不是单点突破因为 Vibe Coding 的本质是“把人的意图高保真地翻译成可运行代码”。工具负责翻译的手速框架负责翻译过程中的自主纠错提示词负责翻译的准确度SPEC 负责翻译的目标不跑偏。缺任何一环你都会在某个环节被迫退回手动模式效率立刻掉下来。我自己的经验是新手最容易忽略的是 SPEC 这一层。大家兴致勃勃地研究哪个工具好用、哪个 Agent 框架强却不愿意花二十分钟把需求写成一份清晰的规格说明。结果就是 AI 一直在猜你一直在改来回拉扯。后面我会专门讲 SPEC 怎么写。2.2 工具选型的三个真实考量维度市面上的 AI 编程工具多到让人眼花免费的和付费的混在一起宣传语一个比一个猛。我踩过几轮坑之后总结出选型时真正该看的三个维度而不是看谁广告打得响。第一个维度是上下文理解能力。工具能不能读懂你整个项目的结构而不是只盯着当前打开的这个文件。这一点直接决定了它生成的代码能不能和你现有的代码风格、依赖、命名习惯对齐。有些工具单文件补全很溜但一涉及跨文件调用就开始胡编这种在真实项目里基本没法用。第二个维度是Agent 编排的成熟度。也就是它能不能自主完成“读需求→改代码→跑测试→看报错→再改”这个闭环。这个能力决定了你是把它当“高级自动补全”还是当“能替你跑腿的助手”。成熟度高的框架你给一个任务它能自己折腾几轮把问题收敛成熟度低的每一步都要你手动确认累。第三个维度是对规则设定的支持。好的工具允许你配置项目级的规则文件比如“所有函数必须写类型注解”“禁止使用某个废弃的库”“错误处理统一用某种模式”。这些规则一旦设定AI 每次生成都会遵守省去你反复纠正的力气。这个功能看起来不起眼但在长期项目里价值极高。至于免费还是付费我的建议是先用免费的把工作流跑通确认这套方式真的适合你再考虑为更强的上下文和 Agent 能力付费。工具是手段工作流才是目的别本末倒置。2.3 Agent 框架与编排从“问答”到“干活”的分水岭普通对话式 AI 和 Agent 框架最大的区别在于前者是“你问我答”后者是“你派活我干完”。这个差别听起来小实际体验差很远。举个具体场景。你要给一个现有模块加缓存。用普通对话工具你得自己找到相关文件、复制粘贴给 AI、告诉它上下文、拿到代码、自己贴回去、自己跑测试、报错了再复制报错信息回去问。整个过程你是个搬运工。用 Agent 框架你只需要说“给这个模块加一层缓存用现有的缓存客户端注意并发安全”它会自己去读文件、找依赖、改代码、跑测试报错了自己看日志再改最后告诉你改完了、测试过了、改了哪几个文件。编排能力的关键在于任务分解和状态保持。好的框架能把一个大任务拆成若干子步骤并且在执行过程中记住前面做了什么、当前卡在哪。这背后涉及工具调用、记忆管理、错误恢复等一堆机制。作为使用者你不需要懂它内部怎么实现但你要会判断它拆任务的粒度合不合理卡住的时候会不会死循环改错了能不能回滚。我实测下来Agent 框架最适合的场景是“有明确验收标准的重复性改造”比如批量加日志、统一异常处理、迁移某个 API 的调用方式。这类任务目标清晰、边界明确AI 自主执行的成功率很高。反过来涉及复杂业务逻辑判断、需要大量领域知识的设计工作还是得人来主导AI 打下手。2.4 提示词工程在编程场景下的特殊打法网上讲提示词工程的内容很多但大部分是面向通用对话的搬到编程场景里不完全适用。编程场景有几个特殊性一是对精确性要求极高一个符号错了整个跑不起来二是上下文很长涉及多个文件和依赖三是有客观的验证标准代码能不能跑、测试过不过骗不了人。基于这些特殊性我总结了几条编程场景下的提示词打法。第一条是先给约束再给需求。比如“使用 Python 3.10不要引入新的第三方库错误处理用自定义异常类然后帮我实现一个配置加载器”。把技术栈和边界先框死AI 就不会自由发挥引入一堆你不需要的东西。第二条是要求它先复述再动手。对于稍微复杂的任务我会让它先把我的需求复述一遍确认理解无误再开始写。这一步能挡掉大量“理解偏差导致的返工”。很多人嫌这一步麻烦但比起写完发现方向错了重来复述的成本几乎可以忽略。第三条是分步验证而不是一次性交付。不要指望一句话让 AI 写完一整个模块还全对。正确的做法是把任务切成小步每步产出后你快速扫一眼确认没问题再进下一步。这就像盖房子一层验收合格再盖下一层比盖完发现地基歪了强得多。第四条是把报错信息完整贴回去。AI 排查问题靠的是信息量你只贴一句“报错了”它只能瞎猜。完整的堆栈、复现步骤、你期望的结果和实际结果这些都给全它定位问题的准确率会高很多。3. SPEC 驱动让 AI 产出可控的关键一环3.1 SPEC 到底是什么为什么它比提示词更重要SPEC 是 specification 的缩写翻译成规格说明或者需求规格。在 Vibe Coding 的语境里它指的是你在让 AI 动手之前先把“要做什么、输入输出是什么、边界条件有哪些、验收标准是什么”写清楚的那份文档。为什么我说它比提示词更重要因为提示词解决的是“怎么表达”SPEC 解决的是“表达什么”。提示词写得再漂亮如果需求本身是模糊的AI 照样给你一堆没法用的东西。反过来SPEC 写得清楚哪怕提示词朴素一点产出质量也不会差到哪去。我见过太多人跳过 SPEC 直接开问然后抱怨 AI 不好用。其实问题不在 AI在于他自己都没想清楚要什么。你让一个实习生干活如果只说“帮我弄个登录”他大概率也做不对。AI 和实习生在这点上是一样的你给的信息越完整产出越靠谱。一份合格的 SPEC 至少包含这几块功能描述做什么、输入输出定义数据长什么样、边界与异常什么情况要处理、依赖与约束能用什么不能用什么、验收标准怎么算做完。不需要写得多正式哪怕就是几段大白话只要把这几点覆盖到效果立竿见影。3.2 手把手写一份能直接喂给 AI 的 SPEC我拿一个真实的小需求来演示给一个现有的用户服务加一个“根据邮箱查用户”的接口。下面是我会写给 AI 的 SPEC。功能描述这块我会写“在 UserService 类中新增一个方法 find_by_email接收一个字符串参数 email返回对应的 User 对象如果找不到返回 None不要抛异常。”输入输出定义“email 是标准邮箱格式的字符串长度不超过 254 字符。返回的 User 对象包含 id、email、nickname、created_at 四个字段其中 created_at 是 UTC 时间戳。”边界与异常“如果 email 为空字符串或 None直接返回 None不查数据库。如果 email 格式明显不合法不含 也返回 None。数据库查询异常按现有项目的异常处理规范处理不要吞掉异常。”依赖与约束“使用项目现有的数据库会话管理方式参考 UserService 里已有的 find_by_id 方法的写法。不要引入新的第三方库。查询要走已有的 ORM 模型不要写裸 SQL。”验收标准“方法能通过单元测试测试覆盖正常查到、查不到、email 为空、email 格式非法四种情况。代码风格和现有文件保持一致。”你看这份 SPEC 没有任何高深的东西就是把一个需求该说清楚的地方都说清楚了。把它喂给 AI产出的代码基本一次就能用最多微调。而如果你只说“加个按邮箱查用户的方法”AI 可能会抛异常、可能返回空列表、可能用裸 SQL你还得来回纠正。3.3 SPEC 与提示词如何配合使用SPEC 和提示词不是二选一而是配合关系。我的习惯是把 SPEC 作为“任务说明书”放在前面把提示词作为“执行指令”放在后面。具体操作上我会先贴 SPEC然后加一句“以上是需求规格请先复述你的理解确认无误后再开始实现。实现时遵守项目根目录下的规则文件。”这样 AI 先对齐目标再对齐约束最后动手。对于复杂任务我还会把 SPEC 拆成多个阶段每个阶段单独喂。比如第一阶段只做数据模型第二阶段做业务逻辑第三阶段做接口层。每个阶段都有对应的 SPEC 片段和验收标准。这样做的好处是每步都可控出问题容易定位不会一锅粥。有个细节值得注意SPEC 不是写完就锁死的。AI 在执行过程中如果发现 SPEC 里有矛盾或者遗漏它应该提出来而不是自己瞎猜。所以我会在提示词里加一句“如果 SPEC 中有不明确或矛盾的地方先提出来不要自行假设。”这一条能挡掉不少隐患。3.4 规则设定把团队规范固化进 AI 的工作流规则设定是 SPEC 的延伸区别在于 SPEC 是针对单个任务的规则是针对整个项目的、长期生效的。好的 AI 编程工具支持项目级的规则文件你写一次之后所有生成都自动遵守。规则文件里该写什么我一般分几类。代码风格类命名规范、缩进、注释要求、类型注解要求。技术约束类允许使用的库清单、禁止使用的 API、必须使用的内部工具类。架构约束类分层规则、依赖方向、哪些层不能直接调用哪些层。安全约束类敏感信息处理方式、日志脱敏要求、输入校验要求。举个例子我会在规则文件里写“所有对外接口的入参必须做非空和类型校验”“日志中禁止打印用户手机号和邮箱”“数据库操作必须通过 Repository 层Service 层不得直接调用 ORM”。这些规则一旦设定AI 生成的代码天然就符合团队规范省去了大量 code review 时纠正风格问题的精力。规则设定这件事前期投入半小时后期省下的是几十上百次的重复纠正。这笔账怎么算都划算。而且规则文件本身也是团队知识的沉淀新人来了看规则文件就能快速了解项目约定一举两得。4. 完整实操用 Vibe Coding 工作流交付一个真实模块4.1 环境与工具准备清单在动手之前先把家伙什备齐。下面是我目前常用的一套配置你可以根据自己的情况调整。环节作用选型考量AI 编程工具代码生成与对话优先选上下文理解强、支持项目级规则的Agent 框架自主执行多步任务看任务分解能力和错误恢复能力版本控制兜底与回滚每次 AI 大改前必须提交一次测试框架验收 AI 产出有测试才能判断 AI 改对没改对规则文件固化项目规范放在项目根目录工具自动读取这里我要特别强调版本控制这一项。AI 改代码有时候会改出你意想不到的结果甚至把好的代码改坏。每次让 AI 做大范围改动之前先 commit 一次出问题直接回滚这是保命的习惯。我吃过亏有一次让 AI 重构一个模块它顺手把另一个不相关的文件也改了还没告诉我要不是有版本控制排查起来能累死。测试框架同样关键。Vibe Coding 的验收标准很大程度上依赖自动化测试。你让 AI 改完代码怎么知道改对了跑测试。测试过了基本可信测试挂了把报错喂回去让它继续改。没有测试的项目用 Vibe Coding 会非常心虚因为你没有客观的验收手段。4.2 从需求到 SPEC 的转化实操接着上一节的例子假设现在要交付的是“用户服务加邮箱查询接口”这个模块。我先把需求转化成 SPEC这一步前面讲过怎么写这里重点讲转化过程中的思考。拿到需求后我会先问自己几个问题这个接口给谁用调用频率高不高需不需要加缓存邮箱字段有没有索引查不到的时候调用方期望什么行为这些问题有些 SPEC 里要写有些是我自己判断后决定不写的。比如缓存如果这个接口调用频率不高加缓存反而增加复杂度我就不写进 SPEC。如果邮箱字段没索引我会在 SPEC 里加一句“确认 email 字段有索引没有的话先加索引”。这些判断依赖你对业务和系统的理解AI 替代不了。转化完成后我会把 SPEC 读一遍检查有没有自相矛盾的地方有没有遗漏的边界情况。这一步花不了几分钟但能挡掉很多返工。然后我会把 SPEC 连同规则文件的引用一起发给 AI让它先复述理解。4.3 让 Agent 自主执行多步任务SPEC 对齐之后进入执行阶段。如果是简单任务我直接用对话式工具一步步来。如果是多步骤任务我会用 Agent 框架让它自主跑。以这个邮箱查询接口为例任务可以拆成几步第一步确认 User 模型和现有 UserService 的结构第二步实现 find_by_email 方法第三步写单元测试第四步跑测试并修复问题。用 Agent 框架的话我会把这几步作为一个整体任务派下去让它自己按顺序执行。执行过程中我会盯着它的输出但一般不打断除非发现方向明显跑偏。它跑完测试后会告诉我结果如果测试没过它会自己看报错继续改改到过为止。这里有个经验给 Agent 的任务要有明确的终止条件。比如“测试全部通过”就是一个明确的终止条件。如果你说“尽量优化一下”它可能无限循环下去因为它不知道什么时候算优化够了。终止条件越清晰Agent 的执行越高效。执行过程中如果卡住了比如反复改都过不了测试我会介入看看是不是 SPEC 有问题或者任务本身超出了它的能力范围。这时候可能需要把任务拆得更细或者我自己接手处理卡住的那部分。4.4 人工审查与收口哪些必须自己看AI 跑完不代表活干完了人工审查这一步不能省。我审查的时候重点看几块。第一块是业务逻辑正确性。AI 能保证代码语法对、测试过但它不一定理解业务。比如“查不到返回 None”这个行为测试能覆盖但如果业务上其实期望返回一个空对象AI 是不知道的。这类需要业务判断的地方必须人来确认。第二块是边界和异常处理。AI 写的异常处理有时候过于宽泛一个 try 包住一大段出了问题根本定位不到。或者该抛异常的地方它吞掉了。这些要逐个看。第三块是安全和性能隐患。比如有没有 SQL 注入风险、有没有 N1 查询、有没有把敏感信息打进日志。AI 不一定每次都注意到这些需要你把关。第四块是代码风格一致性。虽然有规则文件约束但 AI 偶尔还是会跑偏。扫一眼命名、注释、结构和现有代码对齐一下。审查完该改的自己改或者把问题指出来让 AI 改。改完再跑一遍测试确认没问题提交。整个流程走下来一个中等复杂度的模块从需求到交付时间能压缩到以前的三分之一左右而且质量不降。5. 踩坑实录Vibe Coding 常见问题与排查技巧5.1 AI 产出“看起来对但跑不起来”的排查思路这是最常见的问题代码读起来没毛病一跑就报错。排查思路我总结成三步。第一步看报错信息的第一行和最后一行。第一行通常是错误类型最后一行通常是出错位置。中间那一大堆堆栈先扫一眼有没有你认识的类名或文件名。很多时候问题就出在某个依赖版本不对、某个导入路径写错、某个参数类型不匹配。第二步把完整报错喂回给 AI。不要只贴一句“报错了”把堆栈、你的操作步骤、期望结果和实际结果都给全。AI 拿到完整信息后定位问题的准确率会高很多。我实测下来完整报错喂回去AI 一次修对的概率能到七八成。第三步如果 AI 改了两轮还没对停下来自己看。有时候 AI 会陷入死循环反复改同一个地方。这时候你介入往往一眼就能看出问题所在因为你有它没有的全局视角。别跟 AI 死磕该接手就接手。5.2 上下文丢失与“改着改着就忘了”的应对长任务里AI 改到后面忘了前面的约定是很常见的问题。比如一开始说好不用某个库改到第五个文件的时候它又用上了。这不是 AI 笨是上下文窗口有限信息被挤掉了。应对办法有几个。一是把关键约束写进规则文件规则文件通常优先级高不容易被挤掉。二是分阶段执行每个阶段重新贴一次关键约束别指望它从头记到尾。三是定期让它复述当前状态比如“现在改到哪了还剩哪些没做有哪些约束要遵守”让它自己把关键信息捞回来。我自己的习惯是每完成一个阶段就让它总结一下当前进度和待办然后我把这个总结作为下一阶段的输入。这样即使上下文丢了关键信息还在。5.3 版本回滚与“AI 把好代码改坏”的急救AI 把好代码改坏这事我遇到过不止一次。最气人的是它改坏了还不告诉你你跑测试才发现。所以版本控制是底线每次大改前 commit出问题直接回滚。回滚之后别急着骂 AI先想想为什么会改坏。常见原因有几个一是任务描述里没明确说“只改这个文件别动其他文件”二是规则文件里没写清楚哪些代码是稳定的、不要动三是任务本身太大AI 顾此失彼。针对这些原因我的改进做法是任务描述里明确改动范围规则文件里标注核心文件大任务拆小。改完之后AI 改坏的概率明显下降。5.4 常见问题速查表问题现象可能原因排查动作代码跑不起来依赖版本、导入路径、类型不匹配看报错首尾行完整喂回 AI改到后面忘了前面上下文窗口溢出分阶段执行关键约束进规则文件好代码被改坏改动范围不明确版本控制兜底明确改动范围反复改不对任务超出能力或 SPEC 有歧义拆细任务检查 SPEC产出风格不一致规则文件缺失或未生效检查规则文件配置补充约束测试过但业务不对AI 不懂业务语义人工审查业务逻辑这张表我贴在工位上遇到问题先对一遍大部分情况能快速定位。5.5 几个我踩过的坑和独家心得第一个坑是过度信任 AI 的测试。AI 写的测试有时候是“为了通过而通过”它可能把断言写得很宽松或者干脆测了个无关紧要的东西。所以 AI 写的测试我会自己看一遍断言逻辑确认它真的在测该测的东西。第二个坑是提示词里用了模糊的形容词。比如“优化一下性能”“让代码更优雅”这种词 AI 没法量化产出全凭它心情。后来我改成“把这段循环里的数据库查询提到循环外减少查询次数”效果立竿见影。能量化就别用形容词这是血泪教训。第三个坑是一次性给太大的任务。我试过让 AI 一口气重构整个模块结果它改到一半上下文就乱了后面全是胡改。后来我学乖了再大的任务也拆成小步每步验收。慢是慢一点但稳。一个我觉得很值的小技巧让 AI 在改代码前先写改动计划。比如“先列出你打算改哪些文件、每个文件改什么我确认后你再动手”。这一步能挡掉大量方向性错误而且计划本身也是很好的文档。6. 嵌入式场景下的 Vibe Coding 有什么不一样6.1 资源受限环境对 AI 产出的额外要求前面讲的都是通用软件开发场景嵌入式是另一回事。嵌入式 Vibe Coding 最近也被频繁提起但它的玩法和普通应用开发差别很大不能照搬。最大的差别是资源约束。嵌入式设备内存可能只有几十 KBFlash 可能只有几百 KBAI 生成的代码如果随手用个动态分配、随手引入个库直接就把资源吃光了。所以嵌入式场景下SPEC 里必须明确写清楚内存预算、栈大小限制、能不能用动态分配、能不能用浮点运算。这些约束不写AI 默认按桌面环境给你生成根本跑不了。第二个差别是硬件相关性。嵌入式代码大量涉及寄存器操作、中断处理、时序控制这些和具体芯片强相关。AI 的训练数据里这类内容相对少而且不同芯片差异大它很容易张冠李戴。所以嵌入式场景下AI 更适合写那些与硬件无关的纯逻辑部分比如协议解析、状态机、数据处理硬件相关的部分还是得人来。第三个差别是调试手段有限。桌面程序报错了有完整堆栈嵌入式可能就给你个硬件异常啥信息都没有。所以嵌入式场景下测试和验证要更前置不能等跑起来再调。单元测试、静态检查、代码审查这些在嵌入式里权重更高。6.2 嵌入式场景的 SPEC 该怎么写嵌入式 SPEC 除了通用那几块还要额外加几项。资源预算这个模块最多用多少 RAM、多少 Flash、多少栈空间。实时性要求有没有硬实时约束中断里能不能做耗时操作。硬件依赖依赖哪些外设、哪些寄存器、哪些中断。可移植性要求是绑定特定芯片还是要求可移植。举个例子写一个串口协议解析模块的 SPEC我会这么写“解析模块运行在中断上下文单次解析耗时不超过 50 微秒。不使用动态内存分配所有缓冲区静态分配总 RAM 占用不超过 512 字节。不依赖具体芯片型号通过回调函数获取字节。解析状态机需覆盖帧头、长度、数据、校验、帧尾五个状态异常帧丢弃并计数。”这份 SPEC 把嵌入式特有的约束都框进去了AI 生成出来的代码基本能直接用。如果不写这些它可能给你生成一个用 malloc 的、带浮点运算的、还调了 printf 的解析器在单片机上根本跑不起来。6.3 嵌入式 AI 编程的验证策略嵌入式场景下我对 AI 产出的验证分三层。第一层是静态检查用编译器的严格警告选项、静态分析工具过一遍把明显的资源问题和未定义行为挡掉。第二层是单元测试把与硬件无关的逻辑抽出来在 PC 上跑测试覆盖各种边界。第三层是目标板验证烧进去实测看资源占用、看时序、看异常情况。这三层里第一层和第二层是 AI 能帮上忙的第三层基本靠人。我的做法是让 AI 生成代码和测试我自己负责静态检查配置和目标板验证。这样分工效率和质量都能兼顾。还有个经验嵌入式场景下让 AI 生成代码时明确指定 C 标准版本和编译器。比如“使用 C99 标准编译器是 GCC开启 -Wall -Wextra”。不同标准和编译器的行为差异很大指定清楚能避免很多莫名其妙的兼容问题。7. 岗位要求背后的能力模型变化7.1 从“写代码的人”到“定义问题的人”Vibe Coding 被写进岗位要求反映的是开发者能力模型的一次迁移。以前招聘看的是“你写过多少代码、熟悉多少框架、算法题刷得怎么样”现在越来越多看的是“你能不能把问题定义清楚、能不能设计出可验证的方案、能不能判断 AI 产出对不对”。这个变化不是突然发生的是工具能力提升到一定程度后的必然结果。当 AI 能承担大量编码工作时人的价值就往上移了一层移到“定义问题”和“判断质量”上。这不是说编码能力不重要了而是说光会编码不够了。我观察身边适应得好的开发者都有一个共同点他们本来就有很强的“把模糊需求变清晰”的能力。以前这个能力体现在写设计文档、拆任务上现在体现在写 SPEC、写提示词上。本质没变只是载体变了。7.2 哪些能力在升值哪些在贬值升值的几项能力需求拆解能力能把大问题拆成 AI 能执行的小任务规格撰写能力能把模糊需求写成清晰的 SPEC质量判断能力能一眼看出 AI 产出哪里不对系统设计能力能设计出 AI 容易实现、人容易维护的架构调试排查能力AI 搞不定的疑难杂症还得人来。贬值的几项能力机械编码能力纯靠记忆写模板代码的价值在下降API 记忆能力记不记得住某个函数的参数顺序AI 一查就知道重复劳动能力批量改代码、写样板文件这类活AI 干得又快又好。这个变化对开发者来说其实是好事。它把大家从重复劳动里解放出来去做更有创造性、更有价值的事。前提是你愿意升级而不是抱着旧方式不放。7.3 团队协作方式会怎么变Vibe Coding 普及后团队协作方式也会跟着变。以前 code review 主要看代码写得对不对、风格好不好以后 review 的重点会更多放在“SPEC 写得清不清楚”“规则文件全不全”“AI 产出的业务逻辑对不对”上。代码评审的粒度也会变。以前一行行看以后可能更多看模块级的接口设计、数据流、异常处理策略。因为细节代码 AI 已经帮你保证了一部分质量人的精力应该放在更高层的东西上。还有一个变化是知识沉淀的方式。以前团队知识散在每个人脑子里现在更多沉淀到规则文件、SPEC 模板、提示词库里。新人来了看这些文件就能快速上手不用一个个问。这对团队来说是效率的整体提升。8. 我个人的一些实操体会聊了这么多最后说点我自己的真实感受。Vibe Coding 这套东西我用了大半年最大的体会是它放大的是你原本的能力而不是替代你的能力。你本来架构设计就清楚它让你实现得更快你本来需求就理得顺它让你交付得更稳。但如果你本来就想不清楚要什么它只会让你更快地做出一堆没用的东西。另一个体会是别追求一步到位。我见过有人想搭一套完美的 Vibe Coding 工作流工具挑来挑去规则文件写了又改结果一个月过去一行代码没写。正确的做法是先跑起来用最简单的工具、最朴素的提示词先完成一个真实任务然后根据遇到的问题逐步优化。工作流是长出来的不是设计出来的。还有一点保持对代码的敬畏。AI 让写代码变容易了但代码是要上生产的是要给人用的是要长期维护的。容易写不等于可以随便写。该有的测试要有该做的审查要做该守的规范要守。工具变了对质量的追求不能变。最后分享一个我最近在用的做法每周留出半小时回顾一下这周 AI 帮我改的代码里哪些地方它做得好、哪些地方它反复出错。做得好的总结成提示词模板存起来反复出错的写进规则文件或者 SPEC 模板里。这样一周一周积累下来我的工作流越来越顺AI 的产出质量也越来越稳。这个习惯看起来不起眼但长期价值很大推荐你也试试。