不是语法错误、不是逻辑 bug——是"方向对但路径有问题"。这种偏差最隐蔽:代码能跑、测试能过,但你越看越觉得不对劲。
我让 WorkBuddy 帮我设计一个缓存层。它给了 150 行代码。
前 30 行看起来合理:定义了 CacheManager 类,有 get/set/delete 方法。中间 60 行开始让我皱眉:它自作主张加了分布式锁、主从同步、缓存预热。我没要求这些。后 60 行我意识到:它把"缓存层"当成"分布式缓存中间件"在做——完全不是我要的轻量本地缓存。
问题不在最后 60 行。问题在前 10 行就暴露了,只是我当时没学会看信号。
# AI 写的第一个类名
class DistributedCacheClusterManager:
def __init__(self, nodes: list, replication_factor: int = 3):
...
# 信号:类名里有 "Distributed"、"Cluster"、"Manager"、replication_factor
# 但你的需求里没有一个字提到"分布式"
# AI 过度推断了一个完全不存在的复杂度层级检测方法:看 AI 写的第一个类名/函数名,和你需求里的关键词做对照。
# 你说的是 AI 写的是
"缓存" "分布式缓存集群" ← 升了一级
"用户登录" "OAuth2 认证系统" ← 升了两级
"定时清理日志" "日志采集+聚合+告警平台" ← 升了三级经验阈值:如果你需求里没有的词出现在关键类/函数名中 → 立刻停下来确认方向,不要让它继续。
# AI 给你的架构方案
# 第 1 层:定义数据模型 ← 正确
# 第 2 层:实现缓存读写 ← 正确
# 第 3 层:实现分布式一致性协议 ← 跳了两层!你还没到这一步
# 第 4 层:实现故障转移和高可用 ← 又跳了一层抽象层级的跳跃 = AI 在替你"预先设计"。 它不是在解决你当前的需求,它在替你做下一阶段甚至下下阶段的设计决策。
你还没决定用 Redis 还是内存缓存,它已经帮你决定用 Raft 协议了。
你:等一下。回到第 2 层。先实现基于 dict 的内存缓存。不要考虑分布式。
现在的目标不是"完美的缓存系统",是"能跑的缓存层"。关键句式:"回到第 X 层。现在的目标不是 Y,是 Z。" 这比"别想那么多"有效——AI 需要知道具体的"回到哪"。
# AI 在回复中自己构建了一个你没提过的场景
AI:考虑到未来可能有多个服务实例同时访问缓存,
我设计了一个基于 Redis 的分布式锁方案。
...
另外,为了防止缓存雪崩,我加入了随机过期时间。
# 问题:AI 在"考虑"你根本没有提到的场景
# "未来可能有" = 它自己编的
# "为了防止" = 它自己加的"考虑到"、"为了防止"、"万一"——这三个词出现时,停一下。AI 在替你做你没授权它做的设计决策。
怎么处理:
你:关于"多个服务实例"和"缓存雪崩"——
1. 当前只有单实例,不需要分布式锁
2. 缓存雪崩是未来的事,当前版本不考虑
请去掉这两个部分,只保留基础缓存读写。不是让它删除那部分重新生成——是指出具体哪些"自问自答"不需要,给它明确的剪枝指令。
# 你要求:一个简单的配置文件读取器
# AI 给了:
class ConfigManager:
def __init__(self):
self._cache = {}
self._watchers = []
self._version = 0
def load(self, path):
# 支持 YAML、JSON、TOML、INI、ENV
...
def watch(self, path, callback):
# 文件变更监听
...
def validate(self, schema):
# JSON Schema 校验
...
def merge(self, *configs):
# 深度合并
...一个配置文件读取器,变成了一个配置中心。复杂度从 1 跳到 10。
# 你要求的功能 AI 给了
读取配置文件 读取 + 监听 + 校验 + 合并 + 多格式支持
发送邮件 发送 + 模板引擎 + 队列 + 重试 + 追踪
生成报表 生成 + 调度器 + 多格式导出 + 数据源抽象层经验判断:如果你要求的功能数 = N,AI 给了 N × 3 以上的功能数 → 方向跑偏。
# 你的需求:用 SQLite 存储用户数据(明确说了"不要用 MySQL,环境不支持")
# AI 的方案:
class UserRepository:
def __init__(self, db_url: str = "mysql://..."): # ← 默认 MySQL
if "mysql" in db_url:
self.db = MySQLConnection(db_url)
else:
self.db = SQLiteConnection(db_url) # ← SQLite 是备选AI 把你的核心约束从"必须"降成了"备选"。 它"知道"MySQL 更适合生产环境,所以"好心"地调整了你的优先级。
# 重新声明约束,用"硬边界"词汇
你:SQLite 不是"备选",是"唯一选项"。不要写 MySQL 分支代码。
规范:如果只能用 SQLite 跑不通的功能,告诉我跑不通,不要自己切换数据库。| 信号 | 检测方法 | 干预动作 |
|------|---------|---------|
| 命名暴露错误假设 | 类名/函数名里有你没提过的词 → 停 | "这个词不在需求里,请澄清含义" |
| 抽象层级跳跃 | 方案出现了你还没决定的下层细节 → 停 | "回到第 X 层,当前目标不是 Y" |
| 开始自问自答 | 出现"考虑到""万一""为了防止" → 停 | "去��� X 和 Y 部分,只保留 Z" |
| 注入未要求复杂度 | 功能数 N → 变成了 N×3+ → 停 | "只实现 A/B/C,其余全部移除" |
| 回避核心约束 | 你的"必须"变成了 AI 的"备选" → 停 | "X 是硬约束,不是建议。按此重新生成" |五个信号的核心原则:不要让 AI 的"好意"悄悄替换你的设计意图。 它的训练让它倾向于"更完整、更健壮、更面向未来"——在你的场景下,这些倾向经常是方向偏差而不是优化。
很多人觉得"AI 帮我考虑了更多"是好事。有时候是的——当你需要它帮你拓宽思路时。但更多时候,它帮你"考虑"的东西是你下一阶段甚至下下阶段的决策,你在当前阶段还没准备好做这些决策。
AI 的过度发挥 = 它在替你做你没有发给它的设计决策。 可以欣赏它的"好意",但也得叫停它的"越界"。
本文基于与 WorkBuddy 的协作经验撰写。你遇到过 AI "过度发挥"的情况吗?它帮你加了什么你没要求的功能?评论区来吐槽。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。