从 Vibe Coding 到 Harness Engineering：注意力时代的软件工程

当ChatGPT拉开生成式AI的序幕后，「用AI写代码」迅速成为开发者群体的热门议题。Vibe Coding——借助大模型快速生成代码的开发模式一度被视为提升效率的灵丹妙药。然而，在经历大规模项目实践后，越来越多的团队发现：AI生成代码的速度确实惊人，但后期的维护成本却呈指数级攀升。这不仅是代码质量问题，更暴露了当前软件开发范式的深层危机。

注意力时代：人类的核心价值

本文基于一次为期十天的会员系统重构实践，深入剖析Vibe Coding的本质局限及其工程化解决路径。核心结论是：大模型的输出本质是「概率最优」而非「约束最优」。它擅长生成「看起来像正确答案」的内容，但无法保证这些输出对你的业务目标、架构边界或长期可维护性是最优的。

分析

无约束的Vibe Coding在复杂系统中通常会导致四类典型问题：业务逻辑散落——会员权益规则分散在Controller、SQL、Lua脚本等多处，需求变更时找不到「唯一的真相来源」；事务边界失真——扣减配额、下单支付、补偿逻辑跨层混合，一致性问题在生产环境频发；读写职责混乱——查询与指令混在同一个流程，修改一处可能意外影响多处业务逻辑；架构渐进腐化——领域模型依赖框架，反向驱动领域设计。 更隐蔽的风险在于「静默删测」（测试用例被悄悄删除）、「结构畸形」（巨型函数或畸形代码结构）、「表面全绿」（测试通过但内部逻辑空洞）——这些现象的共同点是：输出的可用性被高估，而工程的真实性被低估。没有约束的AI，本质上只是一个「高性能技术债放大器」。

破解之道在于「More Context, Less Control」——用高质量的上下文降低控制成本。具体而言，DDD（领域驱动设计）构建高质量的代码上下文：通过限界上下文、分层边界、事务边界、领域单纯化四点，让代码结构成为「AI可理解、可遵守、可复用」的工程底座。SDD（规格驱动开发）构建需求上下文：把需求意图显式化、版本化，让AI协作有明确的认知脚手架。TDD（测试驱动开发）把约束落到可执行层——测试先行防止静默删测，行为测试约束「外观正确但内核错误」的代码，架构测试持续检查层间依赖。 三者的核心公式是：More Context, Less Control = DDD（代码结构）+ SDD（需求结构）+ TDD（验证结构）。

基于上述分析，团队可以按四阶段演进：阶段A为Vibe快速期，追求快速验证业务价值，但需警惕规则边界开始模糊；阶段B为约束引入期，引入DDD分层与上下文边界，将「到处都要改」转化为「知道该在哪里改」；阶段C为Spec驱动期，全面采用OpenSpec生命周期，将「靠人记得」转化为「靠仓库记得」；阶段D为Harness化期，将规则编码为自动化检查，将质量问题转为持续清理任务，将「靠人盯流程」转化为「系统托底流程」。 这不是替代工程，而是重建工程——Vibe Coding解决的是「代码生成速度」问题，Harness Engineering解决的是「系统可靠演进」问题。前者是加速器，后者是底盘，只有底盘稳定，加速才有意义。

如有侵权，请联系删除。