-
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 足够好的上下文；
-
给系统足够硬的约束；
-
给组织足够快的反馈；
-
把人类注意力留给真正重要的问题。
约束不是限制自由，而是创造高质量自由：通过结构化上下文使 AI 输出更可靠、更可预测变化不是威胁，而是新能力的来源。
