让 AI 生成的代码更好维护：三个反直觉的写法

用代码智能体写业务代码，最大的成本不在生成，而在半年后回来看懂它。下面三个做法看起来反直觉，但确实把维护成本降下来了。

一、宁可多写一层类型，也别靠注释
AI 很擅长从上下文推断结构，但推断结果不会写进代码里。让它把请求体、响应体、内部状态都落成显式类型，后面任何人（包括新一次对话的 AI 本身）都能直接从类型看出契约，比读注释可靠。

二、先写测试，再让它改实现
改动前先把关键路径写成测试用例，再让它动代码。这样它不仅知道「要实现什么」，还知道「不能破坏什么」；改完直接跑测试，比人工逐行 review 一个几百行的 diff 快得多。

三、拆小文件，而不是让它一次写完
一个文件超过三四百行，后续对话里的上下文就会失真，它开始「猜」而不是「看」。把职责拆开，一次只改一个文件，改动范围可控，diff 也可读。

最后一点：让它解释自己的改动。发布前问一句「这次改了哪些文件、每个文件为什么改」，回答对不上的地方往往就是需要人工复核的地方。