企业官网建设流程全解析

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 改代码有时候会改出你意想不到的结果，甚至把好的代码改坏。每次让 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 注入风险、有没有 N+1 查询、有没有把敏感信息打进日志。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 常见问题速查表

这张表我贴在工位上，遇到问题先对一遍，大部分情况能快速定位。

5.5 几个我踩过的坑和独家心得

第一个坑是过度信任 AI 的测试。AI 写的测试有时候是“为了通过而通过”，它可能把断言写得很宽松，或者干脆测了个无关紧要的东西。所以 AI 写的测试，我会自己看一遍断言逻辑，确认它真的在测该测的东西。

第二个坑是提示词里用了模糊的形容词。比如“优化一下性能”“让代码更优雅”，这种词 AI 没法量化，产出全凭它心情。后来我改成“把这段循环里的数据库查询提到循环外，减少查询次数”，效果立竿见影。能量化就别用形容词，这是血泪教训。

第三个坑是一次性给太大的任务。我试过让 AI 一口气重构整个模块，结果它改到一半上下文就乱了，后面全是胡改。后来我学乖了，再大的任务也拆成小步，每步验收。慢是慢一点，但稳。

一个我觉得很值的小技巧：让 AI 在改代码前先写改动计划。比如“先列出你打算改哪些文件、每个文件改什么，我确认后你再动手”。这一步能挡掉大量方向性错误，而且计划本身也是很好的文档。

6. 嵌入式场景下的 Vibe Coding 有什么不一样

6.1 资源受限环境对 AI 产出的额外要求

前面讲的都是通用软件开发场景，嵌入式是另一回事。嵌入式 Vibe Coding 最近也被频繁提起，但它的玩法和普通应用开发差别很大，不能照搬。

最大的差别是资源约束。嵌入式设备内存可能只有几十 KB，Flash 可能只有几百 KB，AI 生成的代码如果随手用个动态分配、随手引入个库，直接就把资源吃光了。所以嵌入式场景下，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 的产出质量也越来越稳。这个习惯看起来不起眼，但长期价值很大，推荐你也试试。