搜yinheit-从 Vibe Coding 到 Harness × SDD 全栈开发实战-学习记录
从Vibe Coding到Harness × SDD：AI全栈开发的范式跃迁与工程化落地
一、Vibe Coding的浪漫与残酷
2025年初，Andrej Karpathy提出了一个引爆技术圈的概念——Vibe Coding（氛围编程）。它的本质是：你不再逐行写代码，而是描述你想要什么，让AI去写，你只看效果不看实现。在原型验证、一次性脚本这些低风险场景中，Vibe Coding确实好用——简单、快、几乎没有认知负担。
但浪漫很快被残酷现实击碎。
当Vibe Coding被引入生产级代码库，三个结构性缺陷迅速暴露：
| 问题维度 | Vibe Coding的典型表现 |
|---|---|
| 信息损耗 | 同一句话多次执行给出不同实现，AI按自己的理解“猜”需求 |
| 知识孤岛 | AI只知训练语料里的通用知识，不懂团队历史决策和私有约束 |
| 验证断档 | “能跑”就直接提交，概率性错误顺着MR滑进主干 |
更扎心的一组数据来自高德大模型应用平台：出码率从53%提升到80%-90%，但项目交付周期没有明显缩短。编码快了，但Review慢了；出码多了，但返工也多了。
出码率≠交付率——AI编程的瓶颈，已经不再是模型本身的智力，而是工程化能力。
二、范式跃迁：从“写代码”到“控工程”
行业对“AI究竟怎么写代码才靠谱”这个问题的认知，经历了清晰的演进：
Vibe Coding（凭感觉写）→ SDD（规范驱动）→ Harness Engineering（工程化体系）
这不是三个并列选项，而是三个递进阶段。Vibe Coding教会了我们“AI能写代码”，但也暴露了“光让AI写代码不够”的残酷事实。
SDD：让规范成为AI的“唯一事实来源”
SDD（Spec-Driven Development，规范驱动开发）的核心思路是：在AI写代码之前，先把“你想要什么”严格地、结构化地写下来，再让AI去实现。SDD的工作流包含四个阶段：
写Spec（规范）→ 描述“要做什么、满足什么约束”
写Plan（计划）→ 拆成具体任务、定义验收标准
生成代码→ AI按Spec和Plan实现
验证→ 用Spec里定义的验收标准对照验收
一份完整的SDD通常包含三个核心文档：
proposal.md：需求提案，描述“为什么要做”和“要做什么”
spec.md：技术规格，包含组件设计、接口契约、数据结构
tasks.md：任务拆分，每个task对应可执行的代码变更单元
Harness：给AI套上“工程缰绳”
Harness Engineering不是简单的技术叠加，而是一套给AI智能体设立边界、搭建运行环境、实现可控自治的系统级工程方法论。它的核心目标是让AI在复杂代码库中像资深工程师一样工作，而非像刚入职的实习生。
Harness思维的本质是：给AI一个已有的实现作为参照，让它照着复刻，而不是凭空创造。
三、四阶段实战指南
结合实战经验，从Vibe Coding到Harness × SDD的全栈落地可以分为四个阶段：
第一阶段：Vibe Coding的“可控化”改造
Vibe Coding最大的痛点是生成的代码“能跑但不规范”。破局点是：让AI生成代码的同时，强制生成规格文件。
实战操作：在Prompt中明确要求——“请为这个功能编写代码，并同步生成openapi.yaml和package.json中的版本依赖锁”。
工具链：使用Cursor/Windsurf结合GitHub Copilot，利用.cursorrules文件强行约束AI的输出结构。
产物：一份包含API契约、数据库Schema（Prisma/Entity）以及基础单元测试的PR。
第二阶段：SDD的“契约”锚定
规格驱动开发的核心是“契约即真理”。在AI生成大量代码后，需要用规格来反向校验代码，而不是用代码去解释规格。
实战策略：
引入Confluent Schema Registry（Kafka事件）和Stoplight（REST API）进行规格托管
将openapi.yaml作为PR合并的硬性门槛
利用Spectral对规格进行质量检查，确保AI生成的API路径符合RESTful规范
基于固化的规格，使用Prism生成Mock Server，前后端彻底解耦并行
第三阶段：Harness平台的全栈编排
Harness在这里不仅是CI/CD，它是连接“规格”与“运行时”的神经中枢。
三个核心实践：
Harness CI：在Pipeline中插入“规格合规性检查”步骤。如果AI生成的代码导致OpenAPI规格与现有生产环境规格冲突，Pipeline直接Fail，不构建镜像
Harness CD + GitOps：部署新服务时，Harness自动读取SDD中定义的SLO（如：P99延迟 < 100ms）
特性标志（Feature Flags）：将AI生成的新功能用Harness FF包裹起来，先在生产环境对内部员工或小流量用户开放，而不是全量上线
第四阶段：持续验证闭环
这是让系统“自愈”的关键。
实战要点：
在Harness中定义“Verification”步骤，利用其机器学习算法自动对比新版本部署后的黄金指标（吞吐量、错误率、饱和度）与历史基线
如果验证失败（如错误率飙升），Harness自动触发回滚
自动在Git中创建Issue，将失败的监控截图和日志片段附着在Issue上
四、Harness思维的核心：让AI模仿，而非凭空创造
得物技术团队的实践揭示了一个关键洞察：
Agent = 模型 + Harness治理层
| 原则 | 核心执行点 |
|---|---|
| 找相似实现 | 在代码库中锚定功能最相似的现有模块作为参照物 |
| 复用优先 | 强制复用现存的组件、接口封装与底层数据结构 |
| 模仿替换 | 维持Controller/Service分层原貌 |
| 锁定生成域 | 精确框定需要参考的具体文件路径与代码行号 |
提示词对比：
❌不推荐（零约束）：
“请实现一个结束语管理的CRUD接口及前端页面。”
✅推荐（Harness驱动）：
“请参照现有的'场景欢迎语'功能（后端接口/api/v1/feature/list，前端入口@FeatureTable/index.tsx:53-58），实现'结束语'功能。数据结构、分层逻辑、命名规范必须保持一致。”
五、写在最后
Vibe Coding提供了无与伦比的生成效率，而Harness × SDD则赋予了其企业级的工程骨架。这一技术架构的融合，让全栈开发者从繁琐的“代码搬运工”与“流程救火队员”转型为真正的“AI架构师”。
核心矛盾在于：大模型本质是概率驱动的非确定性引擎，而软件工程要求绝对的确定性。SDD与Harness的结合，正是连接AI非确定性推理与软件工程确定性要求的桥梁。
如果你还在Vibe Coding的舒适区里“随性编程”，不妨试试这套方法论——把写代码的时间，前置到写规约上。当AI出码率达到90%却没有真正提效时，真正该升级的不是模型，而是你的工程化思维。