我要投稿

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

发布日期：2026-04-01 06:44:31 浏览次数： 1961

作者：愣虾说

微信搜一搜，关注“愣虾说”

这不是一篇理论文档，而是总结了我通过10天重构 Vibe Coding 产物的实践反思。

📌核心观点

当前大模型的输出，本质是在已有语料和上下文约束下的概率最优产物。它擅长生成「看起来像正确答案」的内容，但并不保证这些输出对你的业务目标、架构边界或长期可维护性是最优的。

📚 内容导览

AI 给我们的答案，本质是概率的产物

1.1 为什么这么说

1.2 不加约束的 Vibe Coding，在复杂系统里会怎样

1.3 结论：没有约束，AI 只是「高性能技术债放大器」

More Context, Less Control 让「上下文」成为工程底座

2.1 DDD：构建高质量的代码上下文

2.2 SDD：构建需求上下文

2.3 TDD：把约束落到可执行层

从Vibe Coding到Harness Engineering的可落地演进路径

3.1 Harness Engineering 的关键启示

3.2 结合会员系统的重构路线图

3.3 不是替代工程，而是重建工程

「Attention is all you need」AI 时代，人类的注意力才是稀缺资源

4.1 为什么注意力比编码更稀缺

4.2 人类应该把注意力放在哪里

4.3 核心竞争力

AI 给我们的答案，本质是概率的产物

1.1 为什么这么说

目前核心主流大模型的输出，是在已有语料和上下文约束下，概率上最优的延续。它生成的答案「看起来正确」，但 AI 无法保证：

是否最符合你的业务目标；

是否最贴合你的架构边界；

是否最有利于长期可维护性。

这也是 Vibe Coding 的主要风险：在没有约束的情况下，初期速度很快，但后期质量会极速下滑。

⚠️Vibe Coding 的具体风险

静默删测（The Vanishing Tests）：测试用例被悄悄删除。

结构畸形（Eldritch Horror）：出现巨型函数或畸形的代码结构。

表面全绿（Cardboard Muffins）：测试通过，但内部逻辑空洞。

这些现象的共同点是：输出的可用性被高估，而工程的真实性被低估。

1.2 不加约束的 Vibe Coding，在复杂系统里会怎样

结合会员系统的业务特征（会员、商品、订单、配额等多个上下文耦合），无约束的 Vibe Coding 通常会带来四类问题：

业务逻辑散落
会员权益规则分散在 Controller、SQL、Lua脚本，甚至其他系统和前端兜底逻辑里。
危害：需求变更时，找不到「唯一的真相来源」。
事务边界失真
扣减配额、下单支付、补偿逻辑跨层混合编写。
危害：一致性问题在生产环境频发。
读写职责混乱
为了求快，把查询和指令混在同一个流程里，临时 join、临时 patch 随处可见。
危害：修改一个查询，意外影响一个甚至多个业务逻辑。
架构渐进腐化

领域模型依赖框架，基础设施反过来驱动领域模型。

危害：每次「加速」都在透支未来的可维护性。

1.3 结论：没有约束，AI 只是「高性能技术债放大器」

如果把「提示词技巧」当作 AI 时代的核心能力，团队很快会产生一种错觉：

局部速度更快了；

全局演进却更慢了。

我们不是要否定 Vibe Coding，而是必须认识到

Vibe Coding 必须有结构化的约束。否则，它提供的只是平庸最优解的批量生产能力，以及指数级积累的技术债务。

More Context, Less Control

在 AI 时代，高质量结果，光靠更强的控制是不现实的，应该靠更高质量的上下文来降低控制成本，让「上下文」成为工程底座。

2.1 DDD：构建高质量的代码上下文

在会员系统重构实践里，DDD 不是口号，而是把「业务决策」落地为「代码结构」的机制：

限界上下文：会员、商品、订单、配额、用户模型各自收敛自己的领域。

分层边界：adapter、application、domain、infrastructure 各司其职。

事务边界：在应用层编排事务，而不是到处开启事务。

领域单纯：domain 不依赖 Spring、MyBatis 等任何框架细节。

这四点共同构成了「AI 可理解、可遵守、可复用」的代码上下文。它让模型「更不容易写错」，而不是依赖人工「每次盯着它别错」。

2.2 Spec（SDD）：构建需求上下文

我们强调的 proposal → design → specs → tasks → apply → verify → archive 流程，本质是把「需求意图」显式化、版本化。

这套机制对 AI 协作尤其关键：

proposal：定义问题和边界，减少方向性误解；

design：沉淀决策和取舍，减少结构性误解；

specs：把验收写成具体场景，减少语义性误解；

tasks：让执行过程可追踪，减少过程性误解；

verify/archive：让结果可复盘，减少组织性遗忘。

换句话说，SDD（Spec-Driven Development）不是文档负担，而是 Agent 的「认知脚手架」。

2.3 TDD：把约束落到可执行层

如果 DDD 是模型约束，SDD 是意图约束，那么 TDD 就是运行前的事实约束。

在 AI 参与开发的场景里，TDD 的价值（ROI）被放大了，但要警惕

防止"静默删测"：测试先行，删除测试就会引发异常；

防止"表面全绿"：行为测试能约束"外观正确但内核错误"的代码；

防止"架构走形"：架构测试持续检查层间依赖和规则。

最终形成的核心公式：

More Context, Less Control = DDD（代码结构） + SDD（需求结构） + TDD（验证结构）

从 Vibe Coding 到 Harness Engineering 的可落地演进路径

3.1 Harness Engineering 的关键启示

OpenAI 的 Harness Engineering 实验传递了一个清晰的信号：

人类的职责从「写代码」转向「设计环境、表达意图、构建反馈回路」；

计划、规则、反馈、技术债治理要成为仓库内的一等资产；

真正稀缺的是人类的判断与注意力，而不是代码的产量。

这个实验的重点不是「模型有多强」，而是「系统如何让模型稳定地产生正确结果」。

3.2 结合会员系统的重构路线图

我们可以把演进划分为四个阶段：

阶段 A：Vibe 快速期（追求快速交付）

目标：快速验证业务价值。

风险：业务规则、事务边界、分层责任开始模糊。

阶段 B：约束引入期（追求可控交付）

动作：引入 DDD 分层与上下文边界，补齐业务逻辑地图。

结果：从「到处都要改」变成「知道该在哪里改」。

阶段 C：Spec 驱动期（追求可复用交付）

动作：全面采用 OpenSpec 生命周期；关键决策文档化。

结果：从「靠人记得」变成「靠仓库记得」。

阶段 D：Harness 化期（追求可规模化交付）

动作：

将规则编码为自动化检查；
将质量问题转为持续清理任务；
将评审意见反哺为文档与工具。

结果：从「靠人盯流程」变成「系统托底流程」。

3.3 不是替代工程，而是重建工程

Vibe Coding 解决的是「代码生成速度」问题；

Harness Engineering 解决的是「系统可靠演进」问题。

💡 前者是加速器，后者是底盘。只有底盘稳定，加速才有意义。

「Attention is all you need」

AI 时代，人类的注意力才是稀缺资源

4.1 为什么注意力比编码更稀缺

在 Agent-first 的环境中，代码和文档的产量可以指数级提升，但以下能力很难被替代：

问题定义：到底要解决什么问题，而不是实现哪个功能；

价值判断：权衡哪个值得做，哪个不值得；

结构判断：哪些边界是系统长期健康的关键；

责任判断：哪些决策必须由人类最终拍板。

4.2 人类应该把注意力放在哪里

建议团队更应该把注意力从「写得快」迁移到「想得对」。

放在目标上
明确业务目标、系统目标、质量目标的优先级。
放在边界与约束上
限界上下文、事务边界、兼容性边界、演进边界。
放在反馈回路上
指标是否能提前预警问题？
问题是否被沉淀为规则，还是依旧依赖个人记忆？
放在组织学习上
把失败案例转化为「可执行的守护规则」；
把个体经验转化为"团队的默认能力"。

4.3 核心竞争力

AI 时代最危险的不是「不会用模型」，而是「把注意力浪费在模型已经擅长的事情上」。

真正的竞争力来自：结构化的系统性思维。

用 SDD 决定需求结构；

用 DDD 决定系统结构；

用 TDD 决定验证结构；

用 Harness Engineering 决定协作结构；

人类决定方向与取舍。

结语

从 Vibe Coding 到 Harness Engineering，不是一次简单的工具升级，而是一次工程认知的升级。

当我们承认「AI 给出的默认答案往往是概率上的平庸最优解」时，真正的行动应该是：

给 AI 足够好的上下文；

给系统足够硬的约束；

给组织足够快的反馈；

把人类注意力留给真正重要的问题。

这，才是 AI 时代可持续的软件工程。

AI 不是替代工程师，而是重新定义工程：将人类从低层次实现中解放，聚焦于高层次设计与判断。

约束不是限制自由，而是创造高质量自由：通过结构化上下文使 AI 输出更可靠、更可预测变化不是威胁，而是新能力的来源。

AI 时代可持续的软件工程不是关于「如何让 AI 写更好代码」，而是关于「如何设计系统让人类和 AI 共同创造更大价值」。

这需要工程思维、工具设计、组织文化的系统性变革。

未来的赢家不是最会写代码的工程师，而是最会设计工程系统的设计师。

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业

相关资讯

2026-05-20

当企业AI走入一线：对用友YonClaw的几点冷观察与热期待

2026-05-20

从会聊天到会办事，Amazon Quick 让我重新理解办公 AI

2026-05-18

Kimi WebBridge：让 AI 帮你操作浏览器

2026-05-16

AI智能体需要的是反馈循环，而不是完美的提示词

2026-05-15

Anthropic创始人手册：如何打造一家 AI Native 公司！

2026-05-15

Forward Deployed Engineer：AI 时代的新宠岗位，到底干什么？

2026-05-15

Agent 从一问一答到自主执行面临哪些挑战？

2026-05-15

AI 编程工程化：Subagent——给你的 AI 员工打造协作助手

联系获取

160+中大型企业正在使用53AI

立即咨询预约演示

把握AI发展的机遇，共同探索、共同进步

2025-01-22

如何打造基于GenAI的员工服务机器人

2025-01-22

热点资讯

国内的Agent OS，可能最终还是要看腾讯（微信）

2026-03-20

同事群里催催催，龙虾自动回回回！刚发布的「飞书龙虾」把我解脱了

2026-03-19

火山养“龙虾”日志 | ArkClaw + Coding Plan 即刻帮教培老师减负提效

2026-03-17

把 MiniMax M2.7 扔进真实业务里：它替我省了 BI 和程序员的钱

2026-03-19

阿里上线电商龙虾智能体！30分钟完成海外选品到开店

2026-03-26

10 秒部署 MaxClaw！我给自己招了个不用睡觉的 AI 助理

2026-03-03

AI编程元年：初级开发者被「团灭」？

2026-03-21

终于测到一个不像玩具的AI Agent了

2026-03-25

OpenAI发布Symphony：AI时代的敏捷看板

2026-03-05

一家AI公司的两周转型小龙虾实战故事

2026-03-09

大家都在问

Forward Deployed Engineer：AI 时代的新宠岗位，到底干什么？

2026-05-15

Agent 从一问一答到自主执行面临哪些挑战？

2026-05-15

Agent从一问一答到自主执行面临哪些挑战？

2026-05-13

AI编程元年：初级开发者被「团灭」？

2026-03-21

GPT-5.4、OpenClaw冲击波：未来2-3年内，80%的测试工程师会被裁掉？

2026-03-07

OpenAI发布Frontier：一个企业级的Agent构建平台，把 AI 变成企业里的“数字同事”，那么OpenAI Frontier能做什么？

2026-02-06

全网都在预测DeepSeek-R2功能，但它如何“落地企业”呢？

2026-01-27

Manus公告里的这8000万虚拟计算机究竟是个什么来头？

2026-01-08

热门标签

内容创作大模型技术个人提效 langchain llamaindex 多模态技术 RAG技术智能客服知识图谱模型微调 RAGFlow coze Dify Fastgpt Bisheng Qanything AI+汽车 AI+金融 AI+工业 AI+培训 AI+SaaS Skill 提示词技巧 AI+电商 AI面试数字员工 ChatBI AI知识库开源大模型智能营销智能硬件智能化改造 AI+医疗 MaxKB Palantir Glean Openclaw