Vibe Coding：用Spec驱动与Context工程重构AI开发范式

最新推荐文章于 2026-08-11 16:15:30 发布

原创

最新推荐文章于 2026-08-11 16:15:30 发布 · 381 阅读

1. 这不是“写代码”，是给AI员工发工单：为什么传统程序员必须立刻切换开发范式

你有没有过这种体验：花三天写完一个需求文档，再花五天和产品对齐细节，接着两周反复改接口字段、补边界条件、修测试用例，最后上线前发现漏了支付超时重试逻辑——而这个逻辑，其实在第一次评审时产品就提过，只是被淹没在27页PRD的第18页脚注里。这不是你能力问题，是开发范式本身出了故障。今天要说的“Vibe Coding”，不是又一个炫技的AI编程玩具，而是面向大型需求时，把LLM从“高级补全器”升级为“可调度、可追责、可复盘的Agent员工”的整套工作流。核心关键词就五个： SDD（Spec-Driven Development）、Agent、Vibe Coding、Spec、Context ——它们共同指向一个现实：当单次Prompt能承载的上下文逼近百万token极限（比如API报错里反复出现的 context window limit ），靠堆砌提示词硬刚复杂业务，就像用螺丝刀拧航母甲板铆钉，方向错了，力气越大越危险。

我带过三个百人级产研团队，亲眼见过最典型的失败案例：某金融中台项目，团队用Claude+自建Spec Kit写了3个月，初期效率翻倍，但到第四个月，所有Agent开始集体“失忆”——昨天还能精准解析信贷审批规则树的Agent，今天连“逾期90天”和“逾期91天”的分界线都搞混。根因不是模型退化，而是没人管理 Context的熵增 。Spec没版本化，业务规则散落在飞书文档、Confluence评论区、Slack频道和某位同学的本地笔记里；Agent调用链路里，上游Agent输出的JSON字段名和下游Agent期待的Schema对不上，错误日志里只有一行 context overflow: prompt too large for the model ，没人知道是哪个环节偷偷塞进了500行无用日志。Vibe Coding的本质，是建立一套比Git更严格的“业务意图版本控制系统”。它要求你把“用户要什么”翻译成机器可执行的Spec（不是自然语言描述，是带约束、带校验、带上下游契约的结构化协议），再把Spec编排成Agent协作网络，最后用Context Engineering技术给每个Agent分配精确的“认知带宽”。这不是让程序员失业，是把程序员从“人肉编译器”解放成“AI团队CTO”——你不再写if-else，而是设计Agent的KPI、定义它的OKR、审核它的日报。适合谁？所有正在用Cursor Pro、正在为 unlimited tab 付费、正在深夜调试 api error: 400 invalid params 的资深开发者。如果你还在用 /reset 命令清空对话历史来绕过context limit，说明你还没真正进入Vibe Coding的门。

2. 从“写函数”到“建组织”：Vibe Coding的底层架构与设计哲学

2.1 为什么SDD是Vibe Coding的基石？——Spec不是文档，是契约

传统TDD/BDD/SDD三者常被并列讨论，但Vibe Coding里的SDD有本质不同。BDD关注“行为”，TDD关注“实现”，而SDD在这里特指 Spec-Driven Development ，核心是把业务需求固化为可验证、可传播、可演进的机器可读契约。举个真实例子：某电商促销系统要求“满300减50，同一用户每日限用1次，优惠券不可叠加”。传统做法是后端写个 calculateDiscount() 函数，前端传参校验。SDD做法是先定义一个 PromotionSpec ：

{
  "spec_id": "PROMO_2024_Q3",
  "version": "1.2.0",
  "business_rules": [
    {
      "id": "rule_amount_threshold",
      "description": "订单实付金额满300元",
      "condition": "order.total_paid >= 300",
      "error_message": "订单金额不足300元，无法使用该优惠"
    },
    {
      "id": "rule_daily_limit",
      "description": "同一用户每日限用1次",
      "condition": "user.daily_promo_usage_count < 1",
      "error_message": "今日已使用过该优惠，请明日再试"
    }
  ],
  "schema_contract": {
    "input": {
      "order": {"type": "object", "required": ["total_paid", "items"]},
      "user": {"type": "object", "required": ["id", "daily_promo_usage_count"]}
    },
    "output": {
      "discount_amount": {"type": "number", "minimum": 0, "maximum": 50},
      "applied": {"type": "boolean"}
    }
  }
}

这个Spec的价值远超文档：它是Agent的“入职须知”。当 PromotionAgent 启动时，它不靠记忆理解规则，而是加载此Spec，自动校验输入数据是否符合 schema_contract ，逐条执行 business_rules 中的条件表达式。如果某天产品说“满300减50改成满299减49”，你只需更新Spec的 version 和 business_rules 数组，触发CI流水线——所有依赖此Spec的Agent会自动拉取新版本，无需修改一行业务代码。这解决了Vibe Coding最痛的点： Context漂移 。网络热词里反复出现的 context overflow ，根源往往是Spec未收敛。我见过最夸张的案例：一个支付Agent的Prompt里硬编码了12个银行的清算规则文本，导致每次调用都逼近token上限。换成SDD后，规则抽离为独立Spec文件，Agent只加载当前交易涉及的2家银行规则片段，Context体积直接下降76%。

2.2 Agent不是“智能体”，是“岗位说明书”——重新定义开发单元

把LLM当Agent用，最大的认知陷阱是认为“越聪明越好”。Vibe Coding恰恰反其道而行之： Agent的能力必须被严格限制 。我们团队内部有个铁律：“一个Agent只做一件事，且这件事必须能用一句话说清KPI”。比如 InventoryCheckAgent 的KPI是“在500ms内返回SKU库存状态，准确率≥99.99%”，它的全部职责就是解析 InventorySpec ，查询缓存/DB，返回标准化JSON。它绝不处理“库存不足时推荐替代商品”——那是 RecommendationAgent 的KPI。

这种设计直击 api error: the model has reached its context window limit 的根源。当Agent职责模糊时，工程师会本能地在Prompt里塞入大量“以防万一”的兜底逻辑：比如库存Agent里硬加一段“如果查不到数据，尝试用历史均值估算”。这段逻辑本身可能只占200token，但当10个Agent串联时，冗余上下文呈指数级增长。而岗位化Agent通过三层隔离控制Context：

输入隔离 ：每个Agent只接收Spec定义的最小必要输入字段（如 InventoryCheckAgent 只收 sku_id 和 warehouse_id ，不收整个订单对象）
逻辑隔离 ：Agent内部不包含任何跨领域知识，所有业务规则外置为Spec
输出隔离 ：强制返