跳转至

告别“氛围编程”：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践

Ch01.407 告别“氛围编程”：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践

📊 Level ⭐⭐ | 8.8KB | entities/告别氛围编程基于-harness-治理和-sdd-的团队级-ai-研发范式演进与实践.md

-> 原文存档 从微信文章 告别“氛围编程”：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进与实践 提取。

核心内容

source_url: https://mp.weixin.qq.com/s/-_IBJFuXpvoqMJxL9oaEJQ

主要章节

  • 原因2：存量应用进行 Vibe Coding 风险非常高

  • 原因3：大型项目、复杂需求超出了单次 AI 对话的能力边界

  • SDD （规范驱动开发）

  • Harness Engineering （驾驭工程）

  • 步骤1：设计知识库

  • 步骤2：处理需求 PRD

  • 步骤3：专家团执行任务

  • 步骤4：任务部署

深度分析

「氛围编程」（Vibe Coding）的本质是用自然语言模糊了需求和实现之间的边界，这在探索性、原型化阶段有巨大价值，但当系统进入存量维护和复杂需求阶段时，这种模糊性就成了风险本身。Harness Engineering 和 SDD 的提出，本质上是在说：AI 辅助开发需要一套结构化的「确定性承重层」（Deterministic Load-Bearing Layer），而不能把所有决策都推给模型的随机生成能力。 文章中「存量应用进行 Vibe Coding 风险非常高」这一判断揭示了一个被忽视的工程现实：对于已有大量业务逻辑、边界条件和异常处理的历史系统，AI 的介入必须非常谨慎。一个 5 万行的遗留系统，其「隐性规则」数量远超显式代码，任何未经 Harness 过滤的 AI 生成代码都可能与这些隐性规则产生冲突，结果是系统性的、难以追踪的回归 Bug。 SDD（规范驱动开发）和 Harness Engineering 的关系值得深究：SDD 提供的是需求到规范的转化层（PRD → 设计知识库），而 Harness Engineering 提供的是规范到代码的治理层（设计知识库 → AI 执行）。这两者合在一起，构成了一条从业务需求到 AI 生成结果的完整链路。

实践启示

团队引入 AI 辅助开发时：第一步不是让所有人开始用 AI 写代码，而是建立设计知识库——把团队的设计决策、业务规则、边界条件用 AI 可消费的格式（而非自然语言文档）结构化存储。没有这个基础层，AI 生成的代码质量完全依赖模型能力，无法进行有针对性的治理。 存量项目改造：采用「特权最小介入」原则——只让 AI 处理明确无误的任务（如测试生成、文档编写、重构辅助），关键业务逻辑和跨模块决策仍由人类把关。在 Harness 中设置「AI 禁止修改」区域，并配置强制人工 review 的门禁。 大型复杂项目：将需求进行 SDD 分解后，再通过专家团（Human Expert Panel）逐个确认每个子任务的可行性和安全性。AI 的角色是「加速执行」，而非「替代判断」。任务部署前必须有 Harness 的自动化检查清单覆盖。

相关实体