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 核心竞争力
是否最符合你的业务目标；
是否最贴合你的架构边界；
是否最有利于长期可维护性。
静默删测（The Vanishing Tests）：测试用例被悄悄删除。
结构畸形（Eldritch Horror）：出现巨型函数或畸形的代码结构。
表面全绿（Cardboard Muffins）：测试通过，但内部逻辑空洞。
业务逻辑散落
会员权益规则分散在 Controller、SQL、Lua脚本，甚至其他系统和前端兜底逻辑里。危害：需求变更时，找不到「唯一的真相来源」。 事务边界失真
扣减配额、下单支付、补偿逻辑跨层混合编写。危害：一致性问题在生产环境频发。 读写职责混乱
为了求快，把查询和指令混在同一个流程里，临时 join、临时 patch 随处可见。危害：修改一个查询，意外影响一个甚至多个业务逻辑。 架构渐进腐化
局部速度更快了；
全局演进却更慢了。
限界上下文：会员、商品、订单、配额、用户模型各自收敛自己的领域。
分层边界：adapter、application、domain、infrastructure 各司其职。
事务边界：在应用层编排事务，而不是到处开启事务。
领域单纯：domain 不依赖 Spring、MyBatis 等任何框架细节。
proposal：定义问题和边界，减少方向性误解；
design：沉淀决策和取舍，减少结构性误解；
specs：把验收写成具体场景，减少语义性误解；
tasks：让执行过程可追踪，减少过程性误解；
verify/archive：让结果可复盘，减少组织性遗忘。
防止"静默删测"：测试先行，删除测试就会引发异常；
防止"表面全绿"：行为测试能约束"外观正确但内核错误"的代码；
防止"架构走形"：架构测试持续检查层间依赖和规则。
人类的职责从「写代码」转向「设计环境、表达意图、构建反馈回路」；
计划、规则、反馈、技术债治理要成为仓库内的一等资产；
真正稀缺的是人类的判断与注意力，而不是代码的产量。
目标：快速验证业务价值。
风险：业务规则、事务边界、分层责任开始模糊。
动作：引入 DDD 分层与上下文边界，补齐业务逻辑地图。
结果：从「到处都要改」变成「知道该在哪里改」。
动作：全面采用 OpenSpec 生命周期；关键决策文档化。
结果：从「靠人记得」变成「靠仓库记得」。
动作：
将规则编码为自动化检查； 将质量问题转为持续清理任务； 将评审意见反哺为文档与工具。
结果：从「靠人盯流程」变成「系统托底流程」。
问题定义：到底要解决什么问题，而不是实现哪个功能；
价值判断：权衡哪个值得做，哪个不值得；
结构判断：哪些边界是系统长期健康的关键；
责任判断：哪些决策必须由人类最终拍板。
放在目标上
明确业务目标、系统目标、质量目标的优先级。放在边界与约束上
限界上下文、事务边界、兼容性边界、演进边界。放在反馈回路上
指标是否能提前预警问题？问题是否被沉淀为规则，还是依旧依赖个人记忆？ 放在组织学习上 把失败案例转化为「可执行的守护规则」； 把个体经验转化为"团队的默认能力"。
用 SDD 决定需求结构；
用 DDD 决定系统结构；
用 TDD 决定验证结构；
用 Harness Engineering 决定协作结构；
人类决定方向与取舍。
给 AI 足够好的上下文；
给系统足够硬的约束；
给组织足够快的反馈；
把人类注意力留给真正重要的问题。
