首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >从 Vibe Coding 到 Harness × SDD:重构全栈应用的可控交付体系

从 Vibe Coding 到 Harness × SDD:重构全栈应用的可控交付体系

原创
作者头像
用户12502882
发布2026-07-04 18:15:22
发布2026-07-04 18:15:22
1631
举报

从 Vibe Coding 到 Harness × SDD:重构全栈应用的可控交付体系

当 AI 辅助编码的“快感”遭遇企业级合规的“铁律”,我们该如何在效率与规范之间架起一座自动化的桥梁?

引子:Vibe Coding 的“失控”时刻

在过去的 18 个月里,“Vibe Coding”成为了全栈开发的新宠。借助 AI IDE 插件和强上下文模型,我们可以在 10 分钟内“敲”出一个带有鉴权、数据库和 API 的完整应用。这种流畅感是前所未有的。

但作为一名架构师,我在最近接手一个由 AI 主导生成的微服务项目时,却遭遇了典型的“技术债井喷”:

  1. 基础设施碎片化:同一个项目的四个服务,用了三种不同的 CI 触发规则,且 Dev/Stage/Prod 环境的 IaC(基础设施即代码)状态严重漂移。
  2. API 契约虚无化:前后端依赖纯口头沟通,没有强类型的 Schema 约束,导致发布后前端频繁报错 4xx。

破局思路:我们不能拒绝 AI 编码的效率,但必须用“规范”来约束 AI 的“想象力”。这就是我们今天要实战的主题:SDD(Schema-Driven Development,架构定义驱动开发),并通过 Harness 这一企业级交付平台,将规范固化为全自动的交付流水线。


第一章:重塑认知——什么是 Harness × SDD?

1.1 SDD:不只是 API 定义

传统的 OpenAPI/Swagger 只是 SDD 的一部分。完整的 SDD 应当包含:

  • API Schema:请求/响应结构、错误码。
  • Infrastructure Schema:所需云资源(RDS、Redis、VPC)的声明。
  • Pipeline Schema:构建、测试、部署的门禁条件(Approval Gates)。

1.2 Harness 在 SDD 中的生态位

Harness 不是简单的 CI/CD 工具,它是一个 AI 驱动的软件交付平台。在 SDD 实践中,Harness 扮演“规范执行者”的角色:

  • GitOps 引擎:监控 Git 仓库中的 schema.yaml 变更。
  • 智能金丝雀:基于 Schema 中的流量权重定义自动调整发布策略。
  • 服务可靠性治理 (SRG):强制检查部署后的服务是否违背了 Schema 中定义的 SLO。

第二章:实战——从零构建 SDD 全栈工程

我们将模拟一个电商平台的“订单服务”重构。技术栈:Node.js (NestJS) + PostgreSQL,IaC 使用 Terraform

2.1 定义“真相之源”(Source of Truth)

在项目根目录创建 .schema/ 目录,这是所有规范的唯一来源。

文件:.schema/api/order.v1.yaml (OpenAPI 3.0.3)

代码语言:javascript
复制
openapi: 3.0.3
info:
  title: Order Service API
  version: 1.0.0
paths:
  /api/v1/order:
    post:
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [ "userId", "skuId", "quantity" ]
              properties:
                userId: { type: string, format: uuid }
                skuId: { type: string }
                quantity: { type: integer, minimum: 1 }
      responses:
        '201':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/OrderResponse'
components:
  schemas:
    OrderResponse:
      type: object
      properties:
        orderId: { type: string }
        status: { type: string, enum: [PENDING, CONFIRMED] }

文件:.schema/infra/order-service.yaml (自定义 DSL,用于 Harness 解析)

代码语言:javascript
复制
environment:
  - name: stage
    region: us-east-1
    instance_type: t3.medium
    env_vars:
      LOG_LEVEL: debug
  - name: prod
    region: eu-west-1
    instance_type: t3.large
    env_vars:
      LOG_LEVEL: error

2.2 契约驱动的代码生成 (Code Generation)

我们利用 @openapitools/openapi-generator-cli 将 Schema 直接编译为服务端接口层,确保 AI 生成的 Controller 代码永远符合规范。

代码语言:javascript
复制
npx @openapitools/openapi-generator-cli generate -i .schema/api/order.v1.yaml -g typescript-nestjs -o src/generated/

关键点:将生成的 OrderService 接口作为强制依赖注入。AI 只能去实现接口,无权修改接口定义。

代码语言:javascript
复制
// src/order/order.controller.ts
import { OrderApi } from '../generated/api/order-api';
import { CreateOrderRequest, OrderResponse } from '../generated';

@Controller('api/v1/order')
export class OrderController implements OrderApi {
  // AI 自动生成实现,但必须符合 Schema 签名
  async createOrder(createOrderRequest: CreateOrderRequest): Promise<OrderResponse> {
    // 业务逻辑...
  }
}

2.3 Harness Pipeline 配置(Schema-Driven 流水线)

在 Harness 中,我们不使用 UI 点击配置,而是使用 Harness Pipeline YAML(同样存储在 Git 中,实现 Pipeline as Code)。

文件:.harness/order-service-pipeline.yaml

代码语言:javascript
复制
pipeline:
  name: "OrderService_SDD_Pipeline"
  identifier: "OrderService_SDD"
  stages:
    - stage:
        name: "Security_Scan_and_Build"
        type: "CI"
        spec:
          execution:
            steps:
              - step:
                  type: "Run"
                  name: "Contract_Verification"
                  command: |-
                    # 检查生成的 Types 是否与当前 Schema 一致
                    npx openapi-generator-cli validate -i .schema/api/order.v1.yaml
                    npm run build:types
              - step:
                  type: "BuildAndPushDocker"
                  name: "Build_Image"

    - stage:
        name: "Harness_Approval_and_Deploy"
        type: "CD"
        spec:
          serviceRef: "OrderService"
          envRef: <+pipeline.variables.environment> # 动态传入 stage/prod
          deploymentType: "Kubernetes"
          manifests:
            - manifest:
                type: "ValuesYaml"
                identifier: "infra_config"
                spec:
                  store:
                    type: "Git"
                    spec:
                      paths:
                        - .schema/infra/order-service.yaml # 动态读取资源规格
          execution:
            steps:
              - step:
                  type: "HarnessApproval"
                  name: "QA_Smoke_Test_Gate"
                  timeout: "1h"
                  spec:
                    approvers:
                      minimumCount: 1
                      userGroups: ["QA_Leads"]
              - step:
                  type: "RollingDeploy"
                  name: "Rollout_With_Canary"
                  spec:
                    targetInstances: 100% # 按照 Schema 定义的实例规格

亮点解读

  • 环境变量驱动:通过 <+pipeline.variables.environment> 动态选择 Stage 或 Prod,并加载对应的 Infra Schema。
  • 门禁强制:Harness 会在部署前自动对比当前的 K8s 配置是否与 .schema/infra/order-service.yaml 存在漂移,若存在则自动纠正。

第三章:Harness 核心特性——智能验证与回滚

3.1 引入 Harness Service Reliability Management (SRG)

在 SDD 中,我们不仅要求“代码符合 Schema”,还要求“运行时符合 Schema”。

我们在 Harness SRG 中设置了一个 Service Level Objective (SLO)

  • 指标http_server_duration_histogram_ms
  • 阈值:P95 < 500ms(对应 order.v1.yaml 中注释的 x-slo-p95 扩展字段)。

Harness 自动化验证逻辑

  1. 金丝雀部署 10% 流量进入新版本。
  2. Harness 自动采集 5 分钟指标数据。
  3. 若 P95 延迟超过 500ms,Harness 自动触发AI 辅助回滚(无需人工干预)。
  4. 回滚后,Harness 会自动在 Git 中创建 Issue,关联到本次失败的 Commit SHA。

3.2 Database Schema 的 CD 集成(非仅依赖 ORM)

通过 Harness 与 Flyway/Liquibase 的结合,我们将数据库迁移文件也纳管进 SDD。

Harness Pipeline 步骤扩展

代码语言:javascript
复制
- step:
    type: "Run"
    name: "DB_Migrate_Check"
    command: |-
      # 利用 Harness Secrets 管理数据库密码
      flyway migrate -url=jdbc:postgresql://${{secrets.getValue("DB_HOST")}}/order_db \
                     -user=${{secrets.getValue("DB_USER")}} \
                     -password=${{secrets.getValue("DB_PASS")}} \
                     -locations=filesystem:./migrations

注:迁移文件版本号必须与 order.v1.yaml 中的 version 字段保持一致,形成版本共振。


第四章:避坑指南与最佳实践

基于实战中的血泪教训,分享 3 条哈奈斯(Harness)结合 SDD 的黄金法则:

  1. Spec 权威化(Spec as Single Source) 必须将 .schema/ 目录的修改权限设置为 Code Owner Review。任何 AI 生成的代码,如果未通过 openapi-generator 的兼容性检测,Harness CI 阶段直接 Fail,不允许进入 CD 阶段。
  2. 利用 Harness 的 Input Sets 做环境差异化 不要为每个环境写多份 Pipeline。利用 Harness Input Sets 功能,只在触发时传入 Environment: prodstage,Pipeline 内部动态加载不同的 infra Schema。
  3. Pipeline 自身的“单元测试” Harness 提供了 Pipeline Studio 沙盒。在提交 Pipeline YAML 前,使用 Harness CLI 进行语法模拟运行: harness pipeline simulate --file .harness/order-service-pipeline.yaml --input "environment=stage"

结语:从“动态灵感”到“静态确定性”

Vibe Coding 给予了我们探索未知领域的速度,而 Harness × SDD 给予了企业级系统应有的“韧性”。

当我们把 API 契约、基础设施规格、部署策略全部以 YAML 的形式固化在 Git 中,并让 Harness 作为唯一的“交付裁判”时,AI 生成的代码便不再是脱缰的野马,而是精确制导的武器。这不仅解决了 AI 编程带来的碎片化问题,更让全栈开发拥有了自文档化、自验证的能力。

“无规范的 AI 编程是浪漫的烟花,有规范的 AI 交付是稳定的恒星。”

现在,就去你的 Harness 项目中,创建第一个 .schema 目录吧。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 从 Vibe Coding 到 Harness × SDD:重构全栈应用的可控交付体系
    • 引子:Vibe Coding 的“失控”时刻
    • 第一章:重塑认知——什么是 Harness × SDD?
      • 1.1 SDD:不只是 API 定义
      • 1.2 Harness 在 SDD 中的生态位
    • 第二章:实战——从零构建 SDD 全栈工程
      • 2.1 定义“真相之源”(Source of Truth)
      • 2.2 契约驱动的代码生成 (Code Generation)
      • 2.3 Harness Pipeline 配置(Schema-Driven 流水线)
    • 第三章:Harness 核心特性——智能验证与回滚
      • 3.1 引入 Harness Service Reliability Management (SRG)
      • 3.2 Database Schema 的 CD 集成(非仅依赖 ORM)
    • 第四章:避坑指南与最佳实践
    • 结语:从“动态灵感”到“静态确定性”
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档