Vibe Coding时代：为何降本不一定增效？

背景

随着 Vibe Coding（一种通过自然语言指令让 AI 直接生成代码的编程方式）的流行，许多人认为它赋予了人人「超能力」，可以毫不费力地将脑海中的想法变成现实。这种情绪催生了一种新的技术优越论：理科生呆板、文科生掌握了话语权；工程师不再重要，产品经理可以自行从零到一；设计师可以独立做出优雅产品；工程师则可以独自指挥 AI 完成一切。大公司也纷纷拥抱 AI，裁减人员，用 Token 替代人力，期待一场生产力革命。然而，现实却是产品经理做出的东西全是 Bug，设计师做出的东西卡顿严重，工程师做出的产品无人使用，大公司从 AI 高潮中醒来后削减 Token 预算，重新召回被裁的工程师。这种「降本增效」的幻想为何破灭？答案隐藏在软件研发的复杂流程中。

核心内容

软件架构的劣化：从「造物」到「建大楼」

许多开发者（包括资深工程师）容易忽略一个事实：软件开发不是像作画一样随意添加元素，而是像建大楼一样层层叠加。每一层（产品定义、视觉架构、体验架构、信息架构、工程架构）之间都有紧密依赖关系。需求变更如果发生在基础层级，会牵动整个结构，导致「楼体」不稳定。实践中，常见做法是「先随便塞进去交差，以后再说」，经过几次迭代，工程会变得满是飞线、复制粘贴的代码、打结的逻辑、理不清的事件和数据流。任何模块的修改都可能引发连锁 Bug，这就是「屎山」的由来。

工程质量会随产品演进自然劣化，劣化越严重，维护成本越高。疏于维护导致工程师心力交瘁，进而制造出更大的屎山，形成恶性循环。地基的品质（架构设计时的清晰思考）决定了楼能搭多高，开发习惯（如频繁需求变更且不留修补时间）决定了能搭多快。Vibe Coding 加速了代码输出，但也加速了架构腐化的到来。一旦达到不可维护的临界点，工程必须推倒重做。因此，Vibe Coding 省下来的时间应该用于清理历史债务，而不是单纯加快产出。

把事情想清楚：软件研发是一场接力赛

软件研发从产品发想、设计团队具象化，到开发实现，需要多角色接力。每个环节都必须把问题想清楚，再传递棒子。

问题与用户的澄清

首先需要找到一个问题：明确、可证伪、被人需要，并有清晰边界（内涵、外沿、力所不能及）。接着要确定谁会提出这个问题，这需要构建用户画像（姓名、年龄、职业、动机、目标等），并且必须基于真实的用户研究，不能全权委托给大语言模型。LLM 没有真实生活经验，无法感受真实用户的惊喜与沮丧，只能捏造出看似完整的虚构画像。团队需要走出办公室，设计问卷、访谈，与真人沟通，记录真实问题。

从抽象到具体：Epic、User Story、Job Story、Journey Map

• Epic：将用户目标转化为大方向描述，如「作为个人 NAS 玩家，我想要能够轻松备份硬盘文件，不丢失重要文件」，不涉及具体功能。
• User Story：将 Epic 拆解为可交付的单元，格式为「作为某类用户，我想要执行某项操作，以便达成某个业务目标」。例如，「作为每天产生10GB视频素材的NAS玩家，我想要指定不需要备份的文件夹，以便确保存储空间不被浪费」。
• Job Story：关注触发动作的具体场景，格式为「当处于某种情境时，我想要执行某个动作，以便解决当前问题」。例如，「当NAS提示存储空间已满90%，且我马上需要导入新素材时，我想要一键排除所有 .tmp 和 .cache 文件夹，以便将空间留给重要文档」。
• Journey Map：绘制用户使用产品的大致流程，包含顶部区域（用户、场景、目标）、中间区域（旅程阶段、用户动作、心态、情绪曲线）、底部区域（发现的机会、数据标准）。通过情绪曲线可以识别出需要优化的负面情绪时刻。

所有构想必须建立在真实用户对话基础上，LLM 只能辅助整理和提取共性，不能替代真人沟通。

把想象化作现实：原型设计与架构设计

在写代码之前，原型设计不可跳过。可以先用大语言模型生成低保真原型（如网页界面），但需注意 AI 设计常带有霓虹色彩、大圆角、尴尬动效等特征。可以阅读成熟设计系统文档（如 Material Design、Apple HIG、IBM Carbon Design System）来识别问题。拿着原型与用户和 Stakeholder 做访谈，迭代确认后，再套用设计系统进入开发。

工程师需要根据需求上下文做出具备包容力的架构设计，确定系统模型、数据流向、模块依赖等。架构设计非常依赖开发经验，很难完全委托给大语言模型。LLM 对问题的理解不够全面，容易产生零散数据和特殊条件，如果工程师看不出问题，就会埋下隐患。

模型管理：避免思考外包导致的工程腐化

Vibe Coding 环境下，容易出现将思考外包给 LLM 的惯性，导致大量缺乏逻辑支撑的「补丁式开发」。当修复一个 Bug 导致更多 Bug 时，工程就变得脆弱。LLM 也会胡写代码，且速度比人类快得多。建议在开发中引入多个厂商的模型，以获取多元视角，降低盲点。选择模型时不应只看跑分排名，因为跑分可能失准（如厂商提交多个版本只展示最优者，或上线后做剪枝、量化等操作）。模型的实际表现需在团队自己的任务上持续观察，并建立专属的 SOP 和质量标准，这些标准会随模型版本更新而失效。

可以制定一份开发道德规范文档，规定 LLM 的行为准则，如：任务完成需完整集成、验证、清理；编写代码前需理解整体上下文；代码要健壮、简洁、自文档化；测试驱动；资源管理责任；可证伪的沟通等。不同代模型的问题不同，需要持续更新规范。

关键要点

• Vibe Coding 不能直接提效：更快的代码输出加速了架构腐化，导致不可维护的临界点更快到来，省下的时间应用来清理历史债务，而不是单纯加快产出。
• 软件研发是建大楼而非作画：各层之间有紧密依赖关系，基础层级的需求变更会引发广泛影响，必须避免「先塞进去再说」的短期行为。
• 用户研究不可替代：构建用户画像、Epic、User Story、Job Story、Journey Map 必须基于真实用户对话，LLM 无法替代真人体验，只能辅助整理和共性提取。
• 原型设计不可跳过：即使使用大语言模型生成低保真原型，也需要与用户和 Stakeholder 迭代验证，再套用设计系统进入开发。
• 架构设计依赖人类经验：LLM 难以全面理解问题，容易产生零散架构，工程师需要具备批判性思维，及时发现并修正问题。
• 模型管理需持续观察：不盲信跑分，关注模型在特定任务上的实际表现；引入多个模型以获取多元视角，并建立随版本更新而失效的专用标准。
• 开发规范能约束 LLM 行为：制定明确的道德规范（如完整性、健壮性、测试驱动、资源管理、可证伪沟通等），可减少 LLM 的「补丁式」