上周做一个内部工具，需要加个登录。
需求很简单：局域网内，团队十来个人用，能区分一下身份就行。我脑子里想的大概是 basic auth，或者一个固定 token，五分钟搞定的事。
AI 给我交付的方案：
- JWT access token + refresh token 双令牌
- 公私钥非对称加密签发
- token 过期策略（15 分钟短期 + 7 天长期）
- refresh token 轮转和黑名单机制
- 超管角色隔离 + RBAC 权限矩阵
- 密码 bcrypt 加盐 + 登录失败锁定
- session 审计日志
我看了三秒，关掉了。
这不是我要的东西。我要的是一扇卧室门——能关上就行。AI 给我设计了银行金库——虹膜识别、指纹比对、双人转门、全程录像。
这不是偶发，是 AI 的系统性倾向
程序员圈子有个老梗：Hello World 有多少种写法——从一行 print 到工厂模式、依赖注入、配置中心、Docker、K8s 全家桶。以前笑的是过度设计的同事，现在发现 AI 把这个笑话变成了日常。
第一次遇到的时候，你会觉得是自己没说清楚。于是加了约束："简单实现""不要过度设计""局域网内部使用"。
然后 AI 给你把方案从"银行金库"缩到"保险柜"。还是太重了，但它觉得已经在克制了。
这个现象不是个例，你让它做任何带"安全""权限""认证"关键词的事情，它都会本能地往最严格的方向跑。原因也不难理解——训练数据里安全相关的最佳实践全是面向生产环境的，面向互联网暴露面的，面向金融级合规的。AI 不知道你这个东西跑在 192.168 开头的网段里，只有十个人能碰到。
它没有"够用就好"的判断力。
三种症状，同一个病根
回头看，AI 过度设计有三种典型表现。你大概率都见过。
第一种：你没要求的它全给你加上了。
项目管理里叫"镀金"（Gold Plating）。开发者在完成基本需求之后，自作聪明地添加用户没要求的功能。AI 特别擅长这个——你说"加个登录"，它理解成"设计一个完整的身份认证体系"。你说"存个配置"，它理解成"设计一个可审计的配置管理平台"。
镀金的问题不是功能多余，而是每多一层抽象，后续维护就多一层理解成本。你本来只需要改一行密码，现在要先搞明白它的 token 签发链路。
第二种：把未来可能的需求当成现在的需求。
YAGNI——You Ain't Gonna Need It。你现在十个人用，AI 在帮你设计一万人并发的方案。你现在只需要区分身份，AI 在帮你设计多租户隔离。
"万一以后要扩展呢？" AI 不会问这句话，它直接替你回答了"会"，然后按"会"来设计。
第三种：脱离了业务场景的性价比，飞到九霄云外。
架构宇航员症候群。AI 不知道你的上下文——这个工具的生命周期可能只有三个月；这个服务跑在内网，外面根本访问不到；这个项目就你一个人维护，复杂度越高你越痛苦。
它只看到了"登录"两个字，然后按照它见过的所有登录最佳实践取了并集。结果就是一个理论上无懈可击、实际上没人维护得动的方案。
病根在哪：AI 没有"场景感"
这三种症状的共同病根是一个：AI 不知道你的场景边界。
它不知道这个东西给谁用、用多久、跑在哪里、维护成本谁来扛。它只知道"登录应该安全"，然后把安全做到它能做到的最高水位。
人类工程师做判断的时候，脑子里天然有一个"性价比滤镜"：
- 内部工具，十个人用 → basic auth 够了
- 面向互联网，有用户数据 → JWT + HTTPS 是底线
- 金融场景，有合规要求 → 多因素认证 + 审计 + 加密存储
这个滤镜不是技术判断，是业务判断。AI 缺的恰恰是这个。
怎么治
治法不复杂，但要明确说出来。
第一，在 CLAUDE.md 或 prompt 里把场景边界写死。
不是"简单实现"这种模糊指令。而是：
这是一个内网工具，局域网访问，10人团队内部使用。
安全级别：基础（不涉及用户隐私数据，不暴露到公网）。
认证方式：优先最简方案（环境变量密钥 / basic auth / 单 token）。
禁止引入：JWT 双令牌、OAuth2、RBAC、公私钥签发、MFA。
你不说"禁止"，它就会加。就像带新人——你不明说"不要做"，他就默认"做了总比没做好"。
第二，给 AI 一个"够用"的标尺。
设计原则：YAGNI。只实现当前明确需要的功能。
如果不确定是否需要某个安全机制，默认不加，而不是默认加。
这一条加进去之后，AI 的行为会明显收敛。它需要你明确告诉它：不确定的时候，少做比多做好。
第三，先问再做。
遇到安全/权限/认证相关需求时，先确认场景约束，再给方案。
不要在未确认场景的情况下直接输出完整认证体系。
这条让 AI 从"拍脑袋做到满"变成"先问清楚再做到刚好"。
什么时候真的需要"银行级"
上面说的都是过度设计的场景。但也要守住另一个边界：有些场景真的需要严格。
- 服务暴露到公网 → 加密、鉴权、rate limiting 都不能省
- 涉及用户隐私数据 → 存储加密、审计日志是合规要求
- 多租户 SaaS → 权限隔离是底线
- 团队有合规审计要求 → 按合规要求来，不打折
判断标准很朴素：这个东西如果出了安全事故，后果由谁承担、有多大？
后果小（内部工具崩了，重启就好）→ 简单来。后果大（用户数据泄露，上新闻）→ 该复杂就复杂。
AI 的问题不是"会做安全"，而是它不区分卧室和银行。你得帮它分清楚。
结尾
AI 写代码最大的毛病不是写不对，是写太多。特别是安全和权限这类话题，它的默认姿态就是"宁可十防，不可一漏"。
但工程不是这么做的。工程是在约束条件下找到够用的解——时间约束、人力约束、场景约束、维护成本约束。一个只有你自己维护的内网工具，搞出银行级安全架构，不是严谨，是浪费。
下次 AI 给你一个过于宏大的方案时，先问自己一句：我这是卧室，还是银行？
答案决定了你需要一扇什么样的门。