Cursor 一分钟给我生成了 200 行能跑的代码。我扫了一眼，变量名 data1、tempList，异常吞了，Optional 套了三层——手痒，想全删重写。
同事说：「能跑就行，先上线。」
我愣了一下：AI 把「写代码」的价格打到了地板价，洁癖如果还停在「每一行必须亲手写漂亮」，只会又累又焦虑。但如果把洁癖当成标准制定 + 审查 + 边界控制，在 AI 时代反而更值钱。
一、谁是「代码洁癖者」？
不是贬义词。通常有几条命中：
| 表现 | 背后其实在追求 |
|---|---|
| 见不得魔法数、缩写变量名 | 可读性、可维护性 |
| 分层乱了、循环依赖就难受 | 架构清晰 |
| 重复代码必须抽、命名要对齐 | DRY、一致性 |
| 没测试、没注释（或注释说废话）不放心 | 可验证、可交接 |
| Code Review 会抠格式、边界、异常 | 工程质量 |
核心：你不是爱写字，是爱「代码应该长什么样」。 这和 AI 并不天然冲突——冲突在于，你还在用「手写时代」的方式表达这份坚持。
二、AI 时代，洁癖者为什么容易焦虑？
AI 擅长 快、全、像那么回事；洁癖者在意 稳、简、长期能维护。
| AI 常见输出 | 洁癖者的反应 |
|---|---|
| 一次生成大段代码 | 「这谁以后敢改？」 |
| 风格随 prompt 飘 | 「项目规范呢？」 |
| 幻觉 API、编造依赖 | 「没编译过就敢提交？」 |
| 修 A 坏 B | 「边界呢？测试呢？」 |
焦虑的本质：产出速度是 AI 的，质量责任还是人的。 你以前靠「写得慢但写得净」建立优势；现在 AI 写得比谁都快，优势被稀释了。
但反过来看：Vibe Coding 越泛滥，能守住质量底线的人越缺。 见《会让 AI 写、做对、稳定交付》那篇——第二层 Spec Coding、第三层 Harness，恰恰是洁癖者的主场。
三、生存法则：从「手写洁癖」到「审查洁癖」
1. 接受分工：AI 起草，你定稿
| 手写时代 | AI 时代 |
|---|---|
| 你写每一行 | AI 出草稿，你改关键 20% |
| 洁癖体现在落笔 | 洁癖体现在 规则、Review、门禁 |
| 价值 = 实现功能 | 价值 = 定义什么叫对 + 证明它对了 |
别跟 AI 比手速，比判断力。
2. 把洁癖「外置」成 AI 读得懂的约束
AI 不会猜你们团队的品味，你得写进它能遵守的地方：
- 项目规范：
.cursor/rules、AGENTS.md、Checkstyle / Spotless 配置 - Prompt 模板：「遵循现有分层，Controller 不写 SQL，异常用业务异常类」
- 示例驱动：「参考
OrderService的写法，保持命名和异常处理一致」
## 代码要求（贴进 Agent 规则）
- 变量名禁止 data1/temp，用业务语义
- 禁止空 catch；外部调用必须设 timeout
- 新接口必须带单元测试，覆盖正常 + 边界
- 改动范围最小化，不要顺手重构无关文件
洁癖不再是脑内标准，而是可执行的 Spec。
3. 建立 Review 清单，而不是逐行重写
AI 交稿后，我按这张表过一遍（5～10 分钟）：
| 检查项 | 问一句 |
|---|---|
| 正确性 | 编译、测试、主流程跑通了吗？ |
| 边界 | 空值、超时、并发、幂等考虑了吗？ |
| 一致性 | 命名、分层、异常处理和项目一致吗？ |
| 范围 | 有没有多改、漏改、引入无关依赖？ |
| 安全 | SQL 注入、敏感信息日志、权限校验？ |
只有清单里红灯项，才动手改或打回让 AI 重改——不全盘否定，也不全盘接受。
4. 知道什么时候该松手
洁癖的敌人有时不是 AI，是过度优化：
| 该坚持 | 可以放过 |
|---|---|
| 公共模块、核心链路、对外 API | 一次性脚本、POC、内部分析工具 |
| 安全、事务、并发 | 不影响行为的命名偏好（若团队有统一工具会 format） |
| 会被 copy 的「模板代码」 | AI 生成后你反正要删重写的废稿 |
洁癖要分级：P0 必须净，P2 可以脏一点换速度。
四、与 AI 协作的实操姿势（Java 后端）
1. 先 Spec，再 Generate
❌ 「帮我写一个订单接口」
✅ 「在 order 模块新增取消接口：入参 orderId，校验状态=已支付才
可取消，调 OrderService.cancel，事务内只动 DB，返回统一 Result。
参考 CancelOrderRequest 现有风格，补单测。」
洁癖者的工作前移：把「应该长什么样」说清楚。
2. 小步提交，别一次生成整个模块
- 一次只做：一个接口 / 一个方法 / 一个测试类
- 每步
git diff看过再下一步 - AI 适合 填肉，你守住 骨架（包结构、接口定义、领域模型）
3. 用工具代替口水仗
| 目的 | 工具 |
|---|---|
| 格式统一 | Spotless、Google Java Format |
| 静态扫描 | SpotBugs、Sonar、IDE 检查 |
| 测试门禁 | CI 里 mvn test 不过不准合并 |
| AI 行为约束 | Cursor Rules、项目 Skill |
能自动化的洁癖，别用手抠。
4. 你当「最后编译器」
AI 不会为你的线上故障负责。上线前洁癖者最后一道关：
- 我是否亲手跑过主路径？
- 是否理解每一行为什么在这？
- 若 AI 代码错了，我能否10 分钟内定位？
看不懂的 AI 代码，不许合主分支——这不是老派，是职业底线。
五、洁癖者在 AI 时代的三种新角色
| 角色 | 做什么 |
|---|---|
| 规范制定者 | 写 Rules、模板、架构约束，让 AI 一次生成就接近合格 |
| 质量审查者 | Review、测试设计、安全与边界把关 |
| Harness 搭建者 | CI、lint、测试、Skill，让「脏代码」进不了主干 |
从「最会写干净代码的人」，变成「最会让 AI 稳定产出干净代码的人」。
六、几条硬规矩
- AI 是实习生，不是架构师——方向你定，它填实现。
- 洁癖用在门禁上，别用在每一行亲自写。
- 规范写进 Rules / Spec，别只存在脑子里。
- 看不懂的 AI 代码不许合，比「不完美但能跑」更危险。
- 速度交给 AI，责任留给自己。
洁癖者常问：设计模式、Spring 源码、JVM 还要专门啃吗？见同系列：AI 能写代码了，还要学设计模式、Spring 源码和 JVM 吗？