Vibe Coder 与软件工程师：AI 时代的责任分界线
副标题：从 vibe coding 的现象出发，重新理解 AI 辅助开发中的责任、审查成本与交付纪律
目标读者：中高级软件工程师、技术负责人、正在引入 AI 辅助开发流程的团队管理者
阅读时间：约 15 分钟
一句话
分界线在责任从哪里开始、到哪里结束。主要产出是创意验证时，vibe coder 有用；主要成本是责任归属时，就需要软件工程师。
目录
- 一、错误的衡量指标
- 二、输出不等于进展
- 三、AI 无法替你担责
- 四、上下文不只是文件
- 五、Vibe Coding 适合交付流程中的某些阶段但不适用于所有地方
- 六、学徒问题
- 七、区别
- 八、统一模型：探索与交付之间的责任边界
- 九、实践清单
- 结语：选择模式，而不是选择阵营
- FAQ
- 来源
一、错误的衡量指标
围绕 vibe coding 的很多讨论，量的东西就是错的。大家秀的是"从想法到应用用了多快"。这当然有价值，尤其当你只是想验证一个想法时。但到了真实的开发团队里，总得有人审查它。总得有人理解背后的意图。总得有人判断这个依赖该不该放这里。总得有人检查测试到底有没有验证行为。总得有人处理 schema 变更。总得有人在团队之间协调这次改动。总得有人回滚。总得有人写运行手册。总得有人回应告警。
这些活，没有一件属于玩具项目。
所以衡量 AI 生成工作，得换一个指标：安全合并所需时间。它包括可审查性、风险、测试质量、所有权、回滚能力，以及作者能不能说清这次变更里的关键决策。AI 要是把代码生成搞便宜了，却把安全合并搞贵了，那团队拿到的收益就没有自己以为的那么多。
vibe coder 量的是首次跑通版本所需时间；软件工程师量的是安全合并所需时间。探索阶段，首次跑通版本很有用；一旦进入共享代码库，安全合并所需时间才是必要指标。它包括审查成本、测试成本、发布成本、回滚成本、协调成本，还有未来的维护成本。
本节核心结论
演示算不上正确的终点。它能证明东西可以展示出来，证明不了团队能接纳它。共享代码库里的真实成本，是安全合并所需时间。
常见误区
把"从提示词到可运行原型"的速度当成团队整体效率，会盖住后面审查、修复和运维的隐性开销。
二、输出不等于进展
AI 辅助写的代码应该更好，不是更多。工具让你能生成更多内容，人就得更多地约束它。不然你并没有省下工作量，只是把活顺延到下游，让维护变成别人的麻烦。AI 辅助代码不能套另一套标准，它得达到和手写代码一样的门槛。
所以它应该是收敛的。它应该只有一个存在理由。它不该夹带无关的清理。它不该因为模型"顺手"就把半个文件重新格式化。它不该在没有清晰解释的情况下新增一个包。
变更之所以很大，如果是模型生成得太多，那就拆。模型很乐意为一个十行能写完的东西生成一大堆样板代码。作者要是说不出每个有意义的文件为什么变了，那就还没准备好。这就是基本的所有权意识。
第二个区别在工作单位。vibe coder 把生成结果当进展；软件工程师把任何改动都当责任单位。生成结果可以很大、很乱、也可以是临时的。但真正的变更管理不能这么随意。它得足够聚焦，便于审查；足够可解释，值得信任；足够边界清晰，合并不至于把半个系统一起拖下水。速度要么因此变得有用，要么沦为审查债。
本节核心结论
AI 辅助代码的输出单位应该是"可合并的改动"，不是"模型生成的内容"。进展的度量标准，是变更的可解释性和可维护性。
工程启示
提交前对生成结果做一轮主动收缩：删无关改动、拆大变更、补测试和说明。这是把生成内容变成工程产出的最低门槛。
三、AI 无法替你担责
审查生成代码和审查人写的代码不一样。人写代码时，背后通常有一条决策链。它可能有缺陷，但至少有一个人能解释这条路径。你可以问他为什么用了那个抽象，为什么把规则放那儿，为什么选这个包，为什么测试写成那样。
AI 生成的代码，其中一些所谓"决策"根本不是决策，只是补全。作者要是没把生成结果转化成自己真正负责的成果，审查者就同时在干两件事：审查，外加追溯作者意图。
所有权是第三个区别。vibe coder 可以说是模型生成的；软件工程师必须说，这是我负责的。这意味着请求审查之前，作者得先把生成内容转成一个工程决策。代码也许从模型开始，但责任不能停在模型那里。
本节核心结论
审查权替代不了所有权。模型可以提供起点，但对设计决策、风险和后续维护负责的，只有工程师。
常见误区
觉得"我审查过了"就等于"我负责了"。审查是质量手段，责任归属才是工程身份的分界线。
四、上下文不只是文件
现在模型已经能读很多代码了。这不代表它理解系统。一部分上下文存在于代码里，但大量工程上下文存在于别处——存在于事故里、旧迁移里、客户行为里、运维痛点里、团队惯例里、安全要求里、合规规则里，还有过去那些奇怪的决策里。
你不给它，这些上下文模型就没有。即便给了，它携带这些上下文的方式也跟工程师不一样。它在自己的上下文窗口里运行。任务越大，模型越容易局部优化，全局上造成破坏。
所以"直接让它把整个东西修好"既是个坏习惯，现阶段也确实不太管用。更好的做法是在让它写代码之前，先缩小决策空间。要求更具体时，模型确实能做得更好。但更具体要求什么？要求作者自己真正明白到底在干什么。
经验丰富的工程师从 AI 里拿到的价值最大，方式是给模型更少自由，不是更多。自由适合周末折腾；生产环境需要约束。
这就是第四个区别。vibe coder 给模型一个目标，软件工程师给模型一个有边界的任务。真正的工程性就发生在这个有边界的任务里：用这个接口，不要碰这一层，等等。好的提示词在这里谈不上魔法，它通常只是说明工程师已经理解了边界。
本节核心结论
工程上下文分布在代码之外的系统、团队和历史里。把大目标拆成有边界的任务，是让 AI 输出可用产出的关键约束。
工程启示
在提示词里显式声明"不做什么"，往往比"做什么"更能压低后续审查成本。
五、Vibe Coding 适合交付流程中的某些阶段，但不适用于所有地方
Zig 的创建者 Andrew Kelley 在采访里提过，这个项目禁止 AI 贡献，一概称之为垃圾。维护者们看到的是大量 AI 生成的拉取请求，里面塞满无关改动、损坏的遗留行为、奇怪的依赖新增，还有那些连自己提交的代码都解释不清的贡献者。
但他们描述的混乱，算不上对 AI 的判决；它只是 vibe coding 越界时的产物。所以问题不在于禁它，在于把它放到合适的位置。
这就是第五个区别：探索与交付。同一份让维护者花掉一整个下午的拉取请求，在你做原型验证时无伤大雅。没人会对那段一次性代码负责。探索可以容忍混乱，目标是学习，或者围绕一个想法快速迭代。交付不能容忍无法解释的混乱，目标是一个真实的业务结果。你不能说我们有 99.9% 的正确率。有时候，它就是必须正确。现实里的分界线就在这儿。
这条线也在动。工具在测试、回滚和审查方面变强之后，安全合并的部分成本会降。但降不等于消失。只要还需要有人对结果负责，就得保有一定程度的纪律。把 vibe coding 用在出错代价低的地方，把工程纪律用在出错代价由客户、团队或业务承担的地方。
本节核心结论
探索可以容忍混乱，因为目标是学习；交付不能容忍无法解释的混乱，因为目标是可追责的业务结果。
常见误区
把"它能跑"当成"它能交付"。演示级代码和生产级代码之间，隔着审查、测试、回滚、运维和长期维护的成本。
六、学徒问题
初级工程师一定会用 AI，他们也该用。用得好时，它可以解释代码、比较方案、生成示例，加速学习。但也有坏的一面。
初级工程师要是用 AI 来逃避理解系统，就可能交付更多，学得更少。这是一笔糟糕的交易。工程生涯头几年，正是人建立心智模型的时候。这个模型得在自己大脑里建起来，不能从机器那儿借。
你不会靠一直站在系统外面、让模型替你修问题来建立判断力。这也是管理者最难处理的部分之一。AI 短期内可能让初级工程师看起来更高产，却削弱了把他们培养成强工程师的学习闭环。Kelley 对 Zig 禁止 AI 的更深层原因也跟这个有关。他把代码审查叫"贡献者扑克"——也就是项目寻找值得成长为核心团队成员的人的方式。AI 提交会破坏这一点，因为贡献者并没有真正学代码库，也没吸收反馈。
最后一点。工程需要一定程度的学徒制。vibe coding 诱使你单打独斗；但人是在团队里工作和学习的。软件工程师靠跟别人协作来提升技艺。工作不只是写代码，工作是判断——判断什么有风险、什么没风险。这种判断力来自跟系统和人之间的接触。
本节核心结论
AI 可以加速学习，也可以替代学习。初级工程师的成长依赖于跟系统、代码库和团队反馈的接触，不是持续依赖模型输出。
工程启示
给 junior 工程师设置"先解释、后生成"的练习：调用模型之前，先用自己的话描述问题、约束和预期改动。
七、区别
主要产出是创意验证时，vibe coder 有用。他们可以缩短想法到可点击原型之间的距离。很多想法都值得先这样处理，再决定要不要投入真正的工程产能。
主要成本是责任归属时，就需要软件工程师。他们控制什么进入系统、怎么审查、怎么保护、怎么测试、怎么运维，以及今后怎么改。这个区别是运营层面的，它也不是固定身份。同一个人应该在探索阶段做 vibe coding，在交付阶段切到工程模式。
关键技能在于知道自己当前处于哪种模式，并且别让一种模式的习惯渗到另一种里。vibe coding 能帮你更快学习；软件工程能帮你避免为这份学习付出永远的代价。
本节核心结论
vibe coder 和软件工程师是两种模式，不是两种人。识别当前模式并遵守它的纪律，是 AI 时代工程成熟度的核心标志。
八、统一模型：探索与交付之间的责任边界
前文从衡量指标、工作单位、所有权、上下文边界、阶段适用性和学徒制六个角度展开了讨论。它们可以归并成一个统一模型：以"责任归属"为主轴，区分创意验证的探索阶段和可追责交付的工程阶段。
%%{init: {'theme': 'base', 'themeVariables': { 'fontFamily': 'Inter, PingFang SC, Microsoft YaHei, sans-serif', 'primaryColor': '#F8FAFC', 'primaryTextColor': '#172033', 'primaryBorderColor': '#CBD5E1', 'lineColor': '#64748B', 'fontSize': '13px'}}}%%
flowchart TB
subgraph CORE["核心问题"]
direction TB
C["责任从哪里开始、到哪里结束"]
end
subgraph EXPLORE["探索阶段：创意验证"]
direction TB
E1["指标：首次跑通版本所需时间"]
E2["容忍混乱，目标是学习与迭代"]
E3["模式：vibe coder"]
end
subgraph DELIVER["交付阶段：可追责结果"]
direction TB
D1["指标：安全合并所需时间"]
D2["要求可审查、可回滚、可维护"]
D3["模式：软件工程师"]
end
subgraph BOUNDARY["责任边界"]
direction TB
B1["所有权：我负责，而不是模型负责"]
B2["上下文：代码之外还有系统、团队与历史"]
B3["约束：把无边界目标拆成有边界任务"]
end
C --> E1
C --> D1
C --> B1
E1 --> E2 --> E3
D1 --> D2 --> D3
B1 --> B2 --> B3
E3 -.->|"跨越边界需要工程化"| D3
classDef core fill:#172033,color:#fff,stroke:#172033,stroke-width:2px
classDef wait fill:#EEF6FF,stroke:#3B82F6,color:#172033,stroke-width:1.5px
classDef block fill:#FFF7E6,stroke:#F59E0B,color:#172033,stroke-width:1.5px
classDef work fill:#ECFDF3,stroke:#22C55E,color:#172033,stroke-width:1.5px
classDef metric fill:#F5E8FF,stroke:#A855F7,color:#172033,stroke-width:2px
class C core
class E1,E2,E3 wait
class D1,D2,D3 work
class B1,B2,B3 metric探索阶段
探索阶段主要产出是创意验证。vibe coding 可以快速把想法变成可点击、可讨论的原型。这个阶段的指标是首次跑通版本所需时间，允许一定程度的混乱，因为目标是学习和迭代。
交付阶段
交付阶段主要成本是责任归属。软件工程师得确保变更可审查、可测试、可回滚、可运维。这个阶段的指标是安全合并所需时间，纪律要求高于速度要求。
责任边界
两个阶段之间的转换不会自动发生。它靠三个要素：作者对产出承担所有权、理解代码之外的工程上下文、把大目标拆成有边界的任务。这些条件满足时，生成内容才能从探索阶段进到交付阶段。
本节核心结论
统一模型的主轴是责任边界的移动，不是人和工具的对立。识别当前阶段、履行该阶段的纪律，是工程判断力的体现。
九、实践清单
衡量指标
变更管理
所有权与审查
上下文控制
阶段划分
团队成长
结语：选择模式，而不是选择阵营
AI 不是另一种编程语言，也不是另一个框架。它改变的是软件开发的经济学：生成代码的成本在降，但审查、理解、维护和担责的成本并没有同比例消失。于是真正的问题，从"能不能写出来"变成了"谁对它负责"。
vibe coder 和软件工程师之间的区别，所以不是身份标签，是工作模式的选择。探索阶段需要速度、容忍混乱、以学习为目标；交付阶段需要纪律、可解释性和可追责的结果。同一个人完全可以上午做 vibe coding，下午切到工程模式。成熟的标志，是清楚自己处于哪种模式，并遵守该模式的规则。
工具会继续变强，边界会继续移动，但责任归属这条线不会消失。
分界线在责任从哪里开始、到哪里结束。主要产出是创意验证时，vibe coder 有用；主要成本是责任归属时，就需要软件工程师。
FAQ
1. Vibe coding 是不是不专业的开发方式？
不是。它是一种适合创意验证和快速学习的模式。问题在于把它用在需要可追责交付的场景里，却不附加工程纪律。专业性体现在知道什么时候该用哪种模式。
2. 如果 AI 生成的代码通过了所有测试，是不是就可以安全合并？
测试通过只是合并条件之一。还需要审查者理解设计意图、确认边界条件、评估依赖变更、检查回滚能力，并明确作者愿意为后续问题负责。测试覆盖的是已知行为，工程责任覆盖的是未知风险。
3. 初级工程师应该如何使用 AI 才能不影响成长？
把 AI 当解释和比较方案的工具，别当绕过理解的捷径。建议生成代码之前先自己描述问题、约束和预期改动；生成之后手动走读并解释每一行。管理者应保留代码审查里的反馈闭环。
4. 团队应该怎样划定 vibe coding 与工程交付的边界？
可以从"出错代价"出发：只在个人或隔离环境里允许无约束的 vibe coding；进共享代码库、用户环境或生产路径之前，必须经历可审查、可测试、可回滚的工程流程。阶段划分应在任务开始时就明确。
5. 如果同一个人既要探索又要交付，如何避免习惯混淆？
用明确的切换信号：给探索任务设独立分支或目录，标注"原型"属性；转向交付前强制做一次变更清理，包括删无关文件、补测试、写说明。关键是别让探索阶段的临时性产物默认进到交付流程。
来源
- Yusuf Aytaş. Vibe Coder vs Software Engineer：https://yusufaytas.com/vibe-coder-vs-software-engineer
- Yusuf Aytaş. The Invisible Difference：https://yusufaytas.com/the-invisible-difference
- Yusuf Aytaş. Managers Have Been Vibe Coding All Along：https://yusufaytas.com/managers-have-been-vibe-coding-all-along