AI编程助手的真正瓶颈,不在模型这边

AI 编程助手用久了，会发现一个反复出现的场景：需求提了，代码生成了，每一步都对，但拼起来就是不对劲。

问题通常不在模型够不够聪明，而在需求方根本没搞清楚自己想要什么。

Claude Code 最近发了一篇博客《Finding your unknowns》，聊的正是这件事。

地图不是地形

博客里有个比喻：给 AI 的 prompt 是"地图"，真正要干活的地方是"地形"。

地图上画着一条直线，从 A 到 B，看起来清清楚楚。但地形里有沼泽、有悬崖、有没标注的小路。AI 照着地图走，走着走着就掉坑里了。

地图和地形之间的差距，原文叫 unknowns——“未知”。你以为是交代清楚了，其实有一大片灰色的地带，AI 只能在里面瞎猜。猜对了皆大欢喜，猜错了觉得它蠢。但没说清楚的东西，谁来都得蒙。

原文把未知拆成了四类，这个分类比大部分 AI 编程教程都精准：

已知已知——写在 prompt 里的东西。“帮我写个登录页面”，“用 React”，“要响应式”。明确，清晰。

已知未知——“API 限流策略还没定”，“数据库选型在纠结”。意识到了，只是还没解决。

未知已知——那些觉得"这还用说？"的东西。比如项目里所有状态管理必须用 Zustand 不能用 Redux。你觉得是常识，但 AI 不知道，它可能给你写了一堆 Redux 代码，然后还得花时间解释为什么不对。

未知未知——最隐蔽的一类。部署环境对某些 npm 包有特殊限制，团队有不成文的代码风格偏好，某个上游服务有未文档化的行为。不去想就永远发现不了，AI 更不可能知道。

一个值得注意的现象：跟 AI 配合特别默契的开发者，往往不是 prompt 写得多花哨的人，而是"未知"比较少的人。他们对代码库了如指掌，对模型行为也有体感，给 AI 的指令自然就精准。反过来，对项目本身不熟，又不太清楚 AI 会怎么理解指令，翻车几乎是必然的。

原文给了几个实操方法，挑两个效果最明显的聊聊。

盲点扫描。在开始干活之前，先跟 AI 说："我对这块代码完全不熟，帮我找出可能忽略的盲点。"听起来简单，但确实有用。接手一个没碰过的微服务时，先让 AI 做一遍盲点扫描，它可以帮你挖出隐藏的依赖关系和已经废弃但还在跑的定时任务——这些东西手动翻代码可能一周都发现不了。

让 AI 反过来采访你。给 AI 一些上下文，然后让它一个一个问问题，优先问那些"回答会改变架构"的问题。比如它问"这个功能需要实时同步还是可以接受几秒延迟"，一下子就能帮确定要用 WebSocket 还是轮询。如果它不问，很多人会默认上了 WebSocket，但其实轮询就够了。

还有一个建议值得重视：先做原型。

很多时候以为自己知道要什么，看到东西才发现不对。这在 UI 开发里太常见了。“我要一个仪表盘”——做出来觉得哪里都不对，又说不清到底哪里不对。

更好的做法是先让 AI 做一个粗糙的原型，看了之后反应："这个布局不对，侧边栏太宽了，数据卡片要换一种排列方式。"这些反馈比在脑子里空想高效得多。

原型阶段的试错成本很低。代码写得乱没关系，反正要扔掉。但如果在正式实现阶段才发现方向错了，回退的代价就大了——AI 改过的代码，有时候它自己也改不回去。

原文提到一个做法：让 AI 在实现过程中维护一个 implementation-notes.md 文件。

这个文件不是给人看的，是给 AI 自己看的。它遇到计划之外的决策，就记一笔。比如"原计划用 Redis 做缓存，但发现项目已经有 Memcached 的依赖，改为复用现有方案"。

万一结果不对，翻翻这个文件就能知道 AI 在哪里拐了弯。而且下一次重试的时候，把这些笔记喂回去，它就不会犯同样的错。实际使用中，AI 在实现过程中偷偷改了接口返回格式却不汇报的情况并不少见，有了笔记机制，这类问题一眼就能看到。

用 AI 编程这件事，技术不是瓶颈，沟通才是。

跟 AI 的协作，本质上跟跟人协作差不多——得让对方知道你要什么，得理解对方的思考方式，还得接受有些事情一开始就是模糊的，得边做边清晰。

那些"未知"不会消失，但可以学会更快地找到它们。每一次盲点扫描、每一次原型反馈、每一次让 AI 采访你，都是在缩小地图和地形之间的差距。

每次开始新功能之前，先花十五分钟做"未知排查"。听起来浪费时间，但比起改三天代码发现方向就错了，这十五分钟简直是捡来的。