相信有人跟我一样，在使用 AI 辅助开发的过程中发现一个现象：
同样是向 AI 描述一个需求，不同人得到的结果可能会有很大差异。
有些人只需要简单说明目标，AI 就能给出比较接近预期的方案；而有些人即使不断补充描述，结果依然容易偏离。
这种差异，很多时候并不是因为谁更会写 prompt，而是因为双方对问题本身的理解程度不同。
下面两句话虽然描述的是同一个需求，但它们提供给 AI 的信息量并不在同一个层次。
我做了一个网站，现在想让用户登录，登录以后服务器要知道这个人是谁，你帮我写一下这个功能。
写一段代码用于实现后端鉴权，使用 JWT 作为认证，前端只负责从 LocalStorage 中读写。
第一句话只描述了目标：认证身份。
至于认证应该放在哪里、使用什么方案、前后端如何分工，全部没有说明。
第二句话则已经给出了几个关键概念：
- 后端鉴权
- JWT
- LocalStorage
这些词看起来只是几个技术名词，但实际上每一个都压缩了大量信息。
例如说“使用 JWT”，就已经排除了大量其他认证方案；说“后端鉴权”，意味着认证逻辑的主要职责在哪里；说“前端只负责从 LocalStorage 中读写”，又进一步划定了前端的职责边界。
所以第二句话并不只是“描述得更详细”。
它实际上是在用几个概念，一次性告诉 AI 大量已经做出的判断。
这也是我认为的，AI 编程中一个很容易被忽视的问题：
真正决定 AI 能做什么的，不只是你告诉它多少，而是你有没有能力用正确的概念告诉它。
概念是一种信息压缩
很多人会把专业概念理解为需要记忆的术语。
但实际上，概念更像是对大量经验的压缩。
例如，一个不了解软件工程的人可能会说：
我希望这个程序以后方便添加功能。
这是一个合理的需求，但它并没有说明具体应该如何实现。
而一个有经验的开发者可能会说：
这里需要降低模块之间的耦合。
这句话看起来虽然抽象，但背后包含了很多信息。
“降低耦合”这个概念，并不是为了让表达听起来更加专业，而是因为它已经包含了一套经过验证的问题模型。
因此，概念的价值在于：用较少的信息，表达更多已经被整理过的经验。
找到正确的问题边界
之前我提过，我做过一个图片站的桌面客户端。
当时这个网站本身已经有官方移动端，但网页端和移动端或多或少都存在使用上的不便。
因此目标并不是简单复刻网页，而是实现一个更符合自己需求的桌面客户端。
如果按照表面理解，问题可能是：
如何把这个网站做成桌面应用？
这样思考，很容易进入网页层面：
- 页面结构（DOM）
- 页面布局（CSS）
- 前端逻辑（JavaScript）
- 浏览器环境（Cookie、LocalStorage）
但仔细分析后会发现：网页只是这个服务提供给用户的一种表现形式。
真正需要的是：服务中的数据，以及访问这些数据的方式。
因此，我选择从官方移动端入手，分析它与服务器之间的数据交互，理解 API 的请求方式和数据结构。
这样问题发生了变化。
不再是：
如何模拟一个网页？
而是：
如何基于已有 API 开发客户端？
这两个问题看起来相似，但复杂度完全不同。
前者需要处理大量和核心需求无关的内容；
后者只需要关注：
- 数据如何获取
- 数据如何解析
- 数据如何展示
最终实现的，也不是一个网页复制品，而是一个基于已有接口重新设计的桌面客户端。
好的抽象，是减少无关复杂度
这个过程里，真正重要的并不是某个具体技术。抓包只是手段。
更重要的是意识到：问题本身可能被定义错了。
很多时候，经验丰富的人并不是知道更多解决方案，而是能够更快找到正确的问题边界。
面对一个网站，新手看到的可能是：
网站
├── 页面
├── HTML
├── CSS
├── JavaScript
├── 浏览器行为
├── 网络请求
└── 数据
而理解系统之后，关注点可能变成：
客户端
├── API请求
├── 数据处理
└── 用户界面
大量复杂度并不是消失了，而是被发现不应该考虑。
这就是抽象的作用。
AI 能展开问题，但不能替你定义问题
这也是为什么 AI 使用效果会产生明显差异。
如果只告诉 AI：
帮我做一个图片站的桌面客户端。
它只能根据已有经验猜测。
但如果能够说明：
这是一个已有服务，需要通过 API 获取数据，客户端负责本地展示和管理。
AI 得到的信息完全不同。因为后者已经完成了一部分分析工作。
在架构设计中，真正重要的也不是记住多少技术方案，而是知道：
- 系统的核心对象是什么
- 哪些部分应该被拆分
- 哪些复杂度是必要的
- 哪些复杂度可以避免
AI 可以帮助我们把一个想法快速实现出来。 但在实现之前，仍然需要先完成一次抽象：
找到正确的问题，选择合适的概念，再让 AI 帮助展开。
