最近一个 Golang 新项目让我重新认识了 AI 编程：顶流大模型加各种 harness，仍会写出看起来漂亮、跑起来似乎也没问题、但可读性和可维护性不尽如人意的代码。带 AI 就像带一个刚毕业的博士生——它懂得多，却不知道什么最适合你的产品、环境、业务和那座“屎山”。上岗必须备齐指导手册、设计与代码规范、架构原则、编码规范、验收清单，一个都不能少。

同样用 AI 写代码，Go 后端比 Spring Boot 那套好伺候——因为 Go 的工具链（gofmt / go vet / go test -race / -cover）天生白送了半套 harness。问题是，白送的不等于拧紧的，多数团队连这半套都没接进 CI 闸门。本文讲清楚 AI 在 Go 项目里真正爱翻的三块（吞错误、并发竞态、幻觉依赖），怎么先把白送的工具链拧紧，再用 AGENTS.md、internal 边界、depguard、表驱动测试、golangci-lint 把缺的那半套补上，并给出可直接抄的配置、CI 闸门和行动 / 检查清单。

AI 写小函数行云流水，一到 Spring Boot + MyBatis + MySQL + Kafka 的大功能就顾此失彼、改 A 坏 B。这不是模型太笨，而是项目的 harness 太差——AI 像个聪明但失忆、看不到全局、不敢负责的新外包。本文把 PKB、SDD、DDD、TDD、BDD、MDD 还原成 harness 的六块拼图：上下文、规约、领域边界、回归测试网、行为契约、度量闭环，并给出在传统 Java 项目里渐进落地的顺序。

架构图画在 wiki 上，三个月后就和代码对不上了——这叫架构腐化，AI 时代腐化得更快。ArchUnit 的思路很朴素：把"Controller 不许直连 Mapper""领域之间不许循环依赖"这类约定写成会失败的测试，跟着 mvn test 一起跑。它本质上就是 JUnit，却能把你脑子里的架构纪律，变成 AI 和新人都绕不过去的硬约束。本文讲清楚 ArchUnit 是什么、怎么用、怎么在老项目里冻结存量违规，以及它为什么能大幅提升项目的 harness 水平。