用AI写代码几个月后，我发现一个反直觉的现象：工具越智能，对代码结构的要求反而越高。
不是那种宏大的"软件未来"式感悟，而是每天改代码时实打实的困扰。同样的提示词，有时候输出稳如老狗，有时候却像抽盲盒——问题往往不在AI，而在代码本身。
核心规律反复出现：职责混在一起的系统，AI代码难以控制；职责分离清晰的架构，输出突然变得稳定可预测。纸上谈兵时这道理显而易见，但真用AI干起活来，差距比想象的大得多。
混乱从哪开始
很多项目，尤其是老项目，职责是慢慢漂到一块的。一个服务同时管验证、数据库访问、缓存、编排、映射，有时候还兼着授权。过程渐进，等有人意识到复杂时，早已积重难返。
对人类来说，这很烦，但熟悉代码库后还能应付。对AI工具，这种结构很快变成噩梦。
模型得同时理解多个关注点，判断什么该放哪，避免破坏无关逻辑，还要在边界模糊的地方保持一致。输出很少全错，问题更隐蔽：可靠性下降。提示词微调可能导致实现大变，整体行为飘忽不定。
紧耦合为何难搞
问题通常不是AI不会写代码，是系统本身结构不足。一切紧密相连时：
• 改哪不清楚
• 职责重叠
• 小改动波及无关区域
• 架构决策变成隐式的
生成代码时，模型被迫同时做架构假设——漂移往往从这里开始。
真正让我理解这点的是个细微观察：AI处理代码库的方式和人类长期积累完全不同。
开发者慢慢建立心理上下文，记得决策缘由、系统脆弱点、历史捷径。再乱的系统，带着这些背景也能对付。
大语言模型不一样。它们每次只看有限上下文，像工作记忆。单个类或组件混进太多职责时，有限上下文被无关细节大量占用，而非聚焦你真正想做的改动。
模型不再纯粹专注功能本身，被迫在噪声中分辨信号。这不是能力问题，是注意力分配问题。
分离职责的实际效果
当我把验证逻辑抽成独立模块、数据库访问隔离到仓库层、业务规则与基础设施解耦后，AI输出质量明显提升。同样提示词，结果更可预期；边界清晰的地方，模型很少越界。
这种改进不是渐进式的，而是阈值式的——混乱到某个临界点，可靠性断崖下跌；清晰到某个程度，稳定性突然跃升。
有趣的是，这和我早年学设计模式时的体验相反。那时"分离关注点"像是优雅追求，为了可维护性牺牲开发速度。现在面对AI工具，它成了实用刚需——不是为了未来的自己，为了当下的机器协作。
对日常开发的启示
这个观察改变了我的编码习惯。写提示词前，我会先检查目标模块的职责纯度。如果发现它同时干三件事，宁愿先重构再生成，也不愿直接让AI在泥潭里挣扎。
代价是前置工作量增加，收益是后续迭代次数大幅减少。更关键的是，调试时间缩短了——当AI输出偏离预期时，问题定位快得多，因为边界限制了可能的出错范围。
另一个意外收获：清晰的结构让代码审查更轻松。人类审AI代码时，同样受限于上下文负荷。职责分离后，审查者能快速判断"这部分改得对不对"，而非在纠缠的逻辑中迷失。
这不是说AI写不了复杂代码。恰恰相反，复杂系统更需要人机分工：人类定架构、划边界，AI填实现。模糊地带留给人类，机械部分交给机器。
但前提是，边界真的存在。很多老代码的"架构"只是历史沉积，没有明确契约。这种土壤上，AI和人都容易栽跟头。
所以现在的做法是：生成新代码前，先花十分钟梳理职责归属。这十分钟省下的，可能是后面几小时的提示词调试。
工具变了，但老道理反而更硬。AI时代，"高内聚低耦合"从设计美学变成了生产效率问题——结构不清，机器帮不上忙；结构清晰，机器才能放大你的意图。
热门跟贴