导语
Vibe Coding在AI编程里最爽的阶段，通常发生在“主流程能跑、Demo能演示”的那一刻。真正让人卡死的，往往是剩下30%：验收口径、边界条件、测试回归、权限安全、数据迁移、部署发布、可观测、升级路径。

Vibe Coding越顺手，这30%越像一堵墙。解决办法也很明确：把剩下30%拆成可交付工件，再让Oinone把工件变成可追溯、可复用、可协作的工程资产，AI编程的推进才不会靠反复重生成硬顶。

Agentic Coding这两年来，效率瓶颈换了三轮。最早卡在代码生成本身，AI写不好，得人工补。后来卡在工程集成，AI能写了但跑不通。现在代码生成和集成都不是问题了，真正的瓶颈转移到了决策：技术选型选错了，写到一半得推翻重来；架构没想清楚，写得越多返工越多。有人在前期花大量精力做架构设计、反复迭代，结果后续开发速度越来越快，几乎不怎么看代码了。也有人试过全程Vibe Coding，最后出了问题还得自己debug。

这就是“70%很爽，30%卡死”的真实位置。70%靠Vibe Coding和AI编程的生成能力推上去，30%靠工程决策、工程验证、工程边界来推进。METR对经验丰富的开源开发者做过随机对照试验，结果显示允许使用AI工具的任务平均更慢，主要时间消耗在提示、等待、审查与修补输出上。这类时间成本，往往集中爆发在最后30%。

1 70%很爽的部分到底完成了什么

Vibe Coding在AI编程里最容易搞定的，是“可演示的主路径”。

页面出来了，按钮能点，接口能通，数据能写，甚至能做出看起来很完整的流程。很多团队到这里会产生一种错觉：项目已经差不多了。

这70%更像“功能可演示”。它覆盖的是主干逻辑，覆盖的是成功路径，覆盖的是你主动去点的那条路。

Vibe Coding在这个阶段很强，因为AI编程擅长把一段自然语言变成一段可运行实现。它能把UI、接口、业务流程快速拼起来，速度很容易让人上头。

问题在于，这70%通常还没触到交付链路里最贵的部分。真正昂贵的细节还没出现，或者出现了也没被当成必须解决的东西。

2 剩下30%通常卡在哪里

剩下30%最常见的一类叫“验收口径”。

同一个功能能跑，不代表它满足验收。失败语义怎么定义，边界条件怎么算，错误码怎么返回，幂等怎么处理，重试怎么做，这些东西只要没定清楚，Vibe Coding再生成十轮也可能换十种口径。

第二类叫“质量与回归”。

测试缺失、回归点不清、改动范围不可控，都会把团队推到“不敢动”的状态。因为你知道一动就要付出大量验证成本，甚至验证也验证不全。

第三类叫“稳定与性能”。

超时、限流、并发、资源、队列、锁、缓存一致性，这些在Demo阶段往往不显眼。一旦数据量上来、访问量上来、链路复杂度上来，问题会集中出现。

第四类叫“安全与权限”。

权限口径、脱敏、审计字段、访问控制，属于交付阶段绕不过去的清单。Vibe Coding能写出功能，但经常很难自动对齐企业场景的安全口径。Veracode对100多个模型做了80个编码任务测试，报告提到AI生成代码在相当比例任务里会引入已知安全缺陷。

第五类叫“发布与升级”。

部署脚本、环境差异、配置治理、回滚路径、升级兼容、定制与升级互不影响，这些最容易把项目锁死在最后阶段。因为你担心一改就把交付链路拆散。

3 为什么最后30%最容易把团队卡死

最后30%有一个共同特点：隐性需求密度更高。

这些隐性需求很少写在最初的自然语言里，却决定了能不能交付。Vibe Coding靠自然语言推进时，隐性需求往往在后期才被发现，发现时改动面已经很大。

最后30%还会放大“决策缺口”。

技术选型摇摆、模块边界含糊、接口契约不稳，都会让每一轮AI编程的生成把系统推向不同方向。你以为在修一个小问题，实际在改系统的语义。

提示词变长还跑偏，也会在最后30%更明显。

长上下文里，关键信息处在中间位置时更容易被忽略，这是有研究结论支持的。MIT Press发表的“Lost in the Middle”研究观察到明显的U形曲线：相关信息在开头或结尾时表现更好，在中间时表现显著下降。

提示词越写越像“项目全集”，关键规则越容易被挤到中间。

这也解释了一个很具体的现象：到最后阶段，团队会越来越像“提示词工程团队”，不断投喂、不断修补、不断重生成。Token账单和时间账单一起上升。

Claude Code的成本说明里给了一个很直观的量级参考：平均每位开发者每天约6美元，90%用户日成本低于12美元，团队使用时月度也会出现较大波动。最后30%如果靠反复重生成硬顶，波动就会变成常态。

4 把剩下30%拆成可交付工件的拆法

“卡住”通常来自一个事实：剩下30%没有被拆成能验收的东西。

继续让Vibe Coding对话，只会得到更多“看起来完整的实现”，却很难得到“可以交付的结果”。可交付工件的核心特征很简单：范围小、输入输出清晰、验收方式明确、回归点明确。

可以用一套更贴近交付链路的拆法，把30%拆成几类工件。

验收工件
把验收标准写清楚，把失败语义写清楚，把边界用例写清楚。没有这类工件，AI编程输出的“能跑”就缺少统一判定。

契约工件
把数据对象、接口输入输出、状态流转规则写成稳定契约。契约稳定，Vibe Coding生成的实现更容易保持语义一致。

质量工件
把单测、回归点清单、静态检查规则、格式规范写出来。质量工件越清楚，后期越敢改，debug也更可控。

稳定工件
把超时、重试、幂等、限流、降级路径做成可验证的机制。稳定工件决定系统有没有“后期空间”。

可观测工件
把日志字段、指标、告警、追踪链路写出来。很多团队卡死，是因为问题出现后缺少定位路径，只能反复重生成试运气。

安全工件
把权限口径、审计字段、脱敏规则写出来。安全工件属于交付底线，越晚补越痛。

发布工件
把变更说明、升级说明、回滚步骤写出来。发布工件清楚，交付链路就不会被一次部署事故打断。

每个工件可以用一个极短模板来描述，保持可复用。

工件目标
影响范围
验收方式
回归点

这四行写清楚，Vibe Coding的提示就能变短，AI编程的改动也更容易保持在小范围内。

5 Oinone怎么把剩下30%变成可交付链路

Oinone是AI驱动的企业级产品化引擎

把Vibe Coding和Oinone一起使用时，Oinone更适合做两件事：把工件固化为工程事实，把工程事实变成团队资产。

第一件事是元数据化。

术语、字段语义、失败语义、接口契约、模块边界，这些本来散落在提示词、评审记录、群聊里。Oinone把它们更稳定地表达出来，Vibe Coding在AI编程时就不必反复投喂同一套背景。

第二件事是边界化。

工件按模块归属，改动范围更容易限定。最后30%最怕大范围重写，模块边界清楚之后，Vibe Coding更像在一个责任区里补齐细节，而不是在全局到处改。

第三件事是可追溯。

变更说明、回归点、回滚步骤进入同一套交付链路，后期“不敢动”的根源会减少。因为你知道改动影响哪里，也知道怎么验证，也知道出了问题怎么回退。

第四件事是把“工件清单”变成“工件顺序”。

很多团队卡死，表面是任务太多，实际是顺序乱。Oinone更适合把“先补契约与验收，再补质量与稳定，再补发布与升级”变成团队默认节奏，Vibe Coding的每轮AI编程就不会在错误的顺序里反复重生成。

6 Vibe Coding + Oinone的协作节奏怎么设计

最后30%最怕“一次大对话”。

一次大对话会让提示词膨胀，让改动范围膨胀，让输出Token膨胀，也更容易触发“中间信息失真”。

更有效的节奏是“多工件小迭代”。

每一轮Vibe Coding只针对一个工件。先让AI编程输出变更计划，再输出最小变更集，再输出验证步骤。计划里必须写清楚改动范围与回归点，否则不进入实现。

提示结构也更容易稳定下来。

固定块写元数据
术语、字段字典、契约、模块边界、失败语义

当前块写工件
工件目标、改动范围、验收与回归点

固定块越稳定，团队就越不需要反复投喂，Token成本也更容易控制。Claude Code的成本文档也强调了跟踪与优化用量的必要性，尤其在团队场景下波动会很大。

METR的研究结果其实给了一个很现实的提醒：当任务进入隐性需求密集阶段，提示、等待、审查会吞掉速度。把剩下30%拆成工件，能直接减少这些消耗。

7 关键结论

Vibe Coding的70%更像“功能可演示”，剩下30%集中在隐性需求与交付细节。

最后30%卡死，多数不是代码写不出来，而是验收口径、语义契约、模块边界、验证路径没有固定表达，导致反复投喂、反复重生成、反复debug。

Oinone和Vibe Coding一起使用时，更容易把剩下30%拆成可交付工件，并把工件变成团队资产。工件越清楚，提示越短，改动范围越小，AI编程越接近持续交付。

8 常见问题

为什么Vibe Coding到后期越改越慢？
后期隐性需求密度更高，提示、审查、修补输出会吞掉速度。METR的随机对照试验也观察到类似现象。

最后30%应该先补测试还是先补契约？
先补契约与验收更划算。契约稳定后，测试与回归点才更明确。否则你会在不稳定语义上堆测试，返工会更痛。

怎样判断当前卡住的是验收问题还是边界问题？
验收问题常见表现是“失败语义不统一、边界用例缺失”。边界问题常见表现是“小改动引发大范围重写”。两者都常见时，先做契约工件。

怎样把一个大需求拆成多个可交付工件？
先拆验收工件和契约工件，再拆质量工件和稳定工件，最后拆发布工件。每个工件用四行模板写清楚，Vibe Coding的提示会自然变短。

Oinone的元数据资产先沉淀哪些最划算？
高频争论项优先：术语表、字段字典、失败语义、接口契约、模块边界。这些内容稳定后，AI编程的重生成会明显下降。

9 结尾

“70%很爽，30%卡死”并不说明Vibe Coding不行，它说明AI编程把速度抬高之后，工程的重心会向交付与决策迁移。生成与集成更容易，验收口径、语义契约、边界与验证就会变成真正的分水岭。

剩下30%如果靠反复重生成硬顶，团队会越来越像在付提示与审查税，Token成本和时间成本会一起上升。把剩下30%拆成可交付工件，让工件具备清晰目标、影响范围、验收方式、回归点，推进会更稳定。

AI负责速度，Oinone负责尺度。速度让Vibe Coding更快跑到70%，尺度让剩下30%更像可交付的工程。