搜yinheit-从 Vibe Coding 到 Harness × SDD 全栈开发实战-学习记录

📅 发布时间:2026/7/18 21:25:33
搜yinheit-从 Vibe Coding 到 Harness × SDD 全栈开发实战-学习记录 从Vibe Coding到Harness × SDDAI全栈开发的范式跃迁与工程化落地一、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的“唯一事实来源”SDDSpec-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契约、数据库SchemaPrisma/Entity以及基础单元测试的PR。第二阶段SDD的“契约”锚定规格驱动开发的核心是“契约即真理”。在AI生成大量代码后需要用规格来反向校验代码而不是用代码去解释规格。实战策略引入Confluent Schema RegistryKafka事件和StoplightREST 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%却没有真正提效时真正该升级的不是模型而是你的工程化思维。