Vibe Coding 项目越做越难维护？用六层工程能力给 AI Coding 加护栏
本文依据 Kxians（@xulijian1994）于 2026 年 10 月 17 日发布的长帖整理。工具名称和方法评价均保留为原作者的讨论语境；本文不代表对这些工具或其实际效果做过独立评测。
AI 能很快生成代码，但项目变大后，修改可能牵连多个模块，修复一个问题又引入新问题。Kxians 的判断是，这不一定只是模型能力问题，也可能说明项目缺少适合 AI 参与的工程约束。
长帖提出六类可以组合使用的工程能力：规格驱动开发（SDD）、测试驱动开发（TDD）、领域驱动设计（DDD）、上下文工程、Workflow/Harness，以及项目规则与 Skills。它们解决的是不同层面的问题，不是六种需要择一的开发流派。
六类能力分别管什么
| 能力 | 主要解决的问题 | 可以沉淀的内容 |
|---|---|---|
| SDD | 需求是什么、准备怎样执行 | 结构化 Spec、技术方案、任务拆分 |
| TDD | 实现是否符合预期行为 | 测试、契约和持续反馈 |
| DDD | 业务边界如何划分 | 领域职责、模块边界、跨模块接口 |
| 上下文工程 | AI 在什么信息基础上工作 | 项目约定、模块规则、架构决策、任务所需上下文 |
| Workflow / Harness | 开发步骤如何执行并得到检查 | 分析、设计、确认、实现、测试、Review 等流程 |
| 项目规则 / Skills | 团队经验如何约束重复任务 | 可持续更新的规则、技能和执行要求 |
SDD：先把需求变成可执行的规格
规格驱动开发先整理需求、技术方案和任务拆分，再让 AI 按约定实施。它能减少模型面对模糊自然语言时自行补全过多假设的机会，也有助于跨会话持续推进。
但规格清楚不代表架构一定合理。SDD 更像是把“要做什么、按什么步骤做”明确下来，业务边界和方案质量仍要由人负责判断。
TDD：让实现接受可重复的反馈
测试驱动开发先定义预期，再实现功能并重构。对于 AI Coding，测试能把“看起来正确”转成可执行检查，让模型或开发者更快发现实现与约定的差距。
测试也可能遗漏场景或表达错业务规则，因此通过测试不等于业务一定正确。测试集需要随着真实问题和需求变化持续修订。
DDD：先让业务边界站稳
领域驱动设计关注业务概念、模块职责和边界。以 ERP 为例，库存、采购、销售和财务之间由谁负责什么、哪些数据可以跨模块访问、哪些操作必须经过领域服务，都应当有清晰规则。
如果边界不清楚，AI 可能把同一类业务逻辑散落到多个模块。DDD 的目标不是堆更多抽象层，而是让职责和依赖保持明确。小型工具未必需要完整采用 DDD，复杂且长期维护的业务系统更值得认真考虑这些边界。
上下文工程：提供足够且新鲜的信息
上下文越长不代表有效信息越多。历史对话、无关代码和过期需求可能干扰当前任务。原帖建议把项目约定和关键知识沉淀到可持续维护的载体中，例如 AGENTS.md 或 CLAUDE.md、模块级规则、架构决策文档；每次任务只提供完成当前工作所需的信息。
跨会话继续工作时，文档和代码中的明确决策比依赖聊天记录更可靠。关键是让模型能找到正确版本的信息，而不是把所有材料无差别塞进上下文。
Workflow / Harness：减少步骤遗漏
开发流程可以包含需求分析、方案设计、人工确认、任务拆分、编码、测试和 Review。原作者提到 Superpowers、Trellis、PStack 等作为可研究的对象；这只是原帖中的举例，不构成本文对其能力或适配性的评测。
Workflow/Harness 的价值是让步骤更可重复、遗漏更容易被发现。但流程无法替代架构判断：如果模块边界一开始就错了，按流程执行也不会自动让设计变正确。
项目规则与 Skills：把局部经验变成明确约束
通用 Skill 可以提供可复用能力，项目级规则则可以描述这个代码库自己的要求。原帖举出的规则包括：Controller 不直接操作数据库、跨模块调用经过明确接口、新增 API 补契约和测试、改公共组件时检查调用方、数据库变更提供迁移脚本。
规则不必一开始写得很庞大。可以从反复出现的缺陷和 Review 反馈开始，逐条增加、验证和修订，让规则与真实项目一起演进。
用“可重建性”检查知识有没有沉淀
原帖提出了一个很有用的思考实验：假设只保留需求文档、架构设计、接口规范和测试用例，把实现代码与聊天记录暂时拿走，另一个 AI 会话能不能重新实现出业务行为基本一致的系统？
这不是要求每次生成相同的代码，而是检查核心业务行为、模块边界和约束能否从项目留下的材料中恢复。如果做不到，可能意味着关键知识仍藏在个人记忆、对话历史或难以解释的代码细节里。
可以把这个问题转成一次小范围演练：选一个边界清楚的模块，只提供正式文档、公开接口和相关测试，让另一位开发者或新的 AI 会话尝试理解它。记录无法回答的问题，再决定需要补充哪份规格、决策记录、契约或测试。它是本文基于原帖延伸出的实践建议，不是衡量系统质量的唯一指标。
让方法按项目复杂度逐步增加
简单、短期的小工具可以直接 Vibe Coding，再按实际需要补充测试和说明。对于跨模块、多人协作或需要长期维护的商业项目，则可以逐步增加规格、领域边界、上下文文档、可重复工作流和项目规则。
一个务实的起点是先挑最近反复出错的一类任务：
- 需求反复变化或模型自行补全假设，就补一份简短 Spec。
- 修改经常引入回归，就补充能覆盖关键行为的测试。
- 逻辑散落在多处，就先说明模块职责和允许的调用方向。
- 新会话总要重新解释项目，就把稳定约定写进项目文档。
- 步骤容易遗漏，就把确认、测试或 Review 加进工作流。
- 同类 Review 问题反复出现，就把规则写成可检查的约束。
最终，SDD 管需求，TDD 管反馈，DDD 管业务边界，上下文工程管信息，Workflow/Harness 管执行过程，项目规则与 Skills 管经验复用。它们组合起来，才有机会把软件工程经验转成 AI 能稳定遵守的工作条件。
AI 降低了生成代码的成本，却没有消除设计、验证和维护成本。对于要长期演进的项目，持续沉淀清楚的业务规则、边界和验证证据，比单次写出更多代码更重要。