过去写软件，大半时间花在敲代码上。AI 把"敲代码"这件事的成本压到接近于零之后，时间该怎么重新分配？我的答案是一个有点夸张、但越用越觉得对的比例：80% 在思考与讨论（架构、流程、测试用例、度量、CI/CD、Harness），10% 在编程，10% 在验证。本文聊清楚这 80% 到底在想什么、剩下两个 10% 怎么花，以及为什么这个转变对老程序员是好事、对新手是陷阱。

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

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

上一篇讲过用 promptfoo 测 LLM API 类的 AI skill。可咱们日常写的更多是另一种——给 Cursor、Codex、Claude Code 用的本地 skill，它没有 endpoint，没有固定 prompt，调用方是另一个 agent。这种 skill 该怎么测？本文给一套从结构 lint 到行为回归的完整方案。