# 同样是 AI 编程，为什么有人越用越快，有人越用越乱？ **URL:** \ **Category:** Xenon的杂谈\ **Created:** [2026 年10 月 1 日 06:06 UTC](https://meta.appinn.net/t/topic/92722 "2026-10-01T06:06:26Z")\ **Posts on this page:** 9\ **Page:** 1
作者： ![Xenon](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/xenon/32/63063_2.png) [@Xenon](https://meta.appinn.net/u/Xenon)\ 发布日期： [2026 年10 月 1 日 06:06 UTC](https://meta.appinn.net/t/topic/92722/1 "2026-10-01T06:06:26Z")
相信有人跟我一样，在使用 AI 辅助开发的过程中发现一个现象： > 同样是向 AI 描述一个需求，不同人得到的结果可能会有很大差异。 有些人只需要简单说明目标，AI 就能给出比较接近预期的方案；而有些人即使不断补充描述，结果依然容易偏离。 这种差异，很多时候并不是因为谁更会写 prompt，而是因为双方对问题本身的理解程度不同。 下面两句话虽然描述的是同一个需求，但它们提供给 AI 的信息量并不在同一个层次。 > 我做了一个网站，现在想让用户登录，登录以后服务器要知道这个人是谁，你帮我写一下这个功能。 > 写一段代码用于实现后端鉴权，使用 JWT 作为认证，前端只负责从 LocalStorage 中读写。 第一句话只描述了目标：认证身份。 至于认证应该放在哪里、使用什么方案、前后端如何分工，全部没有说明。 第二句话则已经给出了几个关键概念： - 后端鉴权 - JWT - LocalStorage 这些词看起来只是几个技术名词，但实际上每一个都压缩了大量信息。 例如说“使用 JWT”，就已经排除了大量其他认证方案；说“后端鉴权”，意味着认证逻辑的主要职责在哪里；说“前端只负责从 LocalStorage 中读写”，又进一步划定了前端的职责边界。 所以第二句话并不只是“描述得更详细”。 它实际上是在用几个概念，一次性告诉 AI 大量已经做出的判断。 这也是我认为的，AI 编程中一个很容易被忽视的问题： 真正决定 AI 能做什么的，不只是你告诉它多少，而是你有没有能力用正确的概念告诉它。 ## 概念是一种信息压缩 很多人会把专业概念理解为需要记忆的术语。 但实际上，概念更像是对大量经验的压缩。 例如，一个不了解软件工程的人可能会说： > 我希望这个程序以后方便添加功能。 这是一个合理的需求，但它并没有说明具体应该如何实现。 而一个有经验的开发者可能会说： > 这里需要降低模块之间的耦合。 这句话看起来虽然抽象，但背后包含了很多信息。 “降低耦合”这个概念，并不是为了让表达听起来更加专业，而是因为它已经包含了一套经过验证的问题模型。 因此，概念的价值在于： **用较少的信息，表达更多已经被整理过的经验。** ## 找到正确的问题边界 之前我提过，我做过一个图片站的桌面客户端。 当时这个网站本身已经有官方移动端，但网页端和移动端或多或少都存在使用上的不便。 因此目标并不是简单复刻网页，而是实现一个更符合自己需求的桌面客户端。 如果按照表面理解，问题可能是： > 如何把这个网站做成桌面应用？ 这样思考，很容易进入网页层面： - 页面结构（DOM） - 页面布局（CSS） - 前端逻辑（JavaScript） - 浏览器环境（Cookie、LocalStorage） 但仔细分析后会发现：网页只是这个服务提供给用户的一种表现形式。 真正需要的是： **服务中的数据，以及访问这些数据的方式。** 因此，我选择从官方移动端入手，分析它与服务器之间的数据交互，理解 API 的请求方式和数据结构。 这样问题发生了变化。 不再是： > 如何模拟一个网页？ 而是： > 如何基于已有 API 开发客户端？ 这两个问题看起来相似，但复杂度完全不同。 前者需要处理大量和核心需求无关的内容； 后者只需要关注： - 数据如何获取 - 数据如何解析 - 数据如何展示 最终实现的，也不是一个网页复制品，而是一个基于已有接口重新设计的桌面客户端。 ## 好的抽象，是减少无关复杂度 这个过程里，真正重要的并不是某个具体技术。抓包只是手段。 更重要的是意识到： **问题本身可能被定义错了** 。 很多时候，经验丰富的人并不是知道更多解决方案，而是能够更快找到正确的问题边界。 面对一个网站，新手看到的可能是： ```auto 网站 ├── 页面 ├── HTML ├── CSS ├── JavaScript ├── 浏览器行为 ├── 网络请求 └── 数据 ``` 而理解系统之后，关注点可能变成： ```auto 客户端 ├── API请求 ├── 数据处理 └── 用户界面 ``` 大量复杂度并不是消失了，而是被发现不应该考虑。 这就是抽象的作用。 ## AI 能展开问题，但不能替你定义问题 这也是为什么 AI 使用效果会产生明显差异。 如果只告诉 AI： > 帮我做一个图片站的桌面客户端。 它只能根据已有经验猜测。 但如果能够说明： > 这是一个已有服务，需要通过 API 获取数据，客户端负责本地展示和管理。 AI 得到的信息完全不同。因为后者已经完成了一部分分析工作。 在架构设计中，真正重要的也不是记住多少技术方案，而是知道： - 系统的核心对象是什么 - 哪些部分应该被拆分 - 哪些复杂度是必要的 - 哪些复杂度可以避免 AI 可以帮助我们把一个想法快速实现出来。 但在实现之前，仍然需要先完成一次抽象： **找到正确的问题，选择合适的概念，再让 AI 帮助展开。** ---
作者： ![kat](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/kat/32/58750_2.png) [@kat](https://meta.appinn.net/u/kat)\ 发布日期： [2026 年10 月 3 日 05:05 UTC](https://meta.appinn.net/t/topic/92722/2 "2026-10-03T05:05:36Z")
我很认同文章把「抽象」拉进视野。像「耦合」这样的词，确实能让 AI 很快进入一套成熟的概念框架。 但对非程序员来说，这里还差一个前提：如果我不知道「耦合」这个概念，怎么想到用它？ 所以除了知道抽象，还要知道怎么应对自己的抽象/概念缺失。我想到一个办法，也许这件事可以交给 AI。在描述完问题后，问他： > 先不要写代码。请分析我描述的问题：在软件工程里，这类问题通常叫什么？涉及哪些常见概念？一个有经验的程序员会怎样重新描述这个需求？请用外行能理解的话解释。 这样做我不需要事先知道「耦合」，也可以让 AI 把相关概念找出来。 如果这篇文章是写给非程序员的，我觉得这一层值得展开。 ---
作者： ![Xenon](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/xenon/32/63063_2.png) [@Xenon](https://meta.appinn.net/u/Xenon)\ 发布日期： [2026 年10 月 3 日 05:15 UTC](https://meta.appinn.net/t/topic/92722/3 "2026-10-03T05:15:17Z")
确实应该写一写这方面的。主要是我已经很难想象完全不懂的人是怎么思考的了，所以就没有主动展开。你提到的这个方法挺好的。 记得我之前看过一篇关于怎么做web界面的文章，大意是让AI先提供几个参考方案，然后根据预览排除掉不喜欢或者不适合的，确认了目标之后再开工。 ---
作者： ![Qingwa](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/qingwa/32/58632_2.png) [@Qingwa](https://meta.appinn.net/u/Qingwa)\ 发布日期： [2026 年10 月 3 日 08:14 UTC](https://meta.appinn.net/t/topic/92722/4 "2026-10-03T08:14:23Z")
这就是专业程序员和野生程序员的真实差距吧。AI 把这个差距放大了 ---
作者： ![ennis](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/e/f14d63/32.png) [@ennis](https://meta.appinn.net/u/ennis)\ 发布日期： [2026 年10 月 3 日 10:03 UTC](https://meta.appinn.net/t/topic/92722/5 "2026-10-03T10:03:10Z")
所以在编程工具和人之间，需要一名编程经理 :laughing: ---
作者： ![syun](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/syun/32/16821_2.png) [@syun](https://meta.appinn.net/u/syun)\ 发布日期： [2026 年10 月 3 日 11:26 UTC](https://meta.appinn.net/t/topic/92722/6 "2026-10-03T11:26:52Z")
愿意用ai编程的 其实现在 大部分是 对概念有一定了解的 没概念的人 描述都做不到 ---
作者： ![highwind](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/highwind/32/2255_2.png) [@highwind](https://meta.appinn.net/u/highwind)\ 发布日期： [2026 年10 月 3 日 11:59 UTC](https://meta.appinn.net/t/topic/92722/7 "2026-10-03T11:59:44Z")
我属于那种拿ai搭农民房的，不知道拿ai建摩天大楼是啥感觉。我觉得就现在token花费的意愿，我还是可以停留在非术语化的舒适圈的。 ---
作者： ![Xenon](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/xenon/32/63063_2.png) [@Xenon](https://meta.appinn.net/u/Xenon)\ 发布日期： [2026 年10 月 3 日 12:22 UTC](https://meta.appinn.net/t/topic/92722/8 "2026-10-03T12:22:47Z")
> [@syun](#): > > 愿意用ai编程的 其实现在 大部分是 对概念有一定了解的 没概念的人 描述都做不到 这个还真不好说，我是见过不咋懂的人用 Vibe Coding 用得飞起的，自己做着玩怎么折腾都无所谓 > [@highwind](#): > > 我属于那种拿ai搭农民房的，不知道拿ai建摩天大楼是啥感觉。我觉得就现在token花费的意愿，我还是可以停留在非术语化的舒适圈的。 是啊，不考虑 Token 成本当然是想怎么蹬怎么蹬，但一旦把这个因素考虑进来就得做权衡了 ~~穷玩车富玩表，顶富用顶尖模型发Hello~~ 没额度了就只能干瞪眼的大有人在（绝无任何暗示，doge） ---
作者： ![CCR](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/ccr/32/68442_2.png) [@CCR](https://meta.appinn.net/u/CCR)\ 发布日期： [2026 年10 月 3 日 15:49 UTC](https://meta.appinn.net/t/topic/92722/9 "2026-10-03T15:49:59Z")
所以说虽然AI时代已经来临，但是该学的还是得学，不然啥玩意都不懂，只能说你做个这个，你做个那个，最后结果纯抽奖…… 我在维护lertaro（类listary的文件搜索工具）时感觉就极其明显，之前从来没有系统地搞过c#，维护起来就很麻烦，尤其是涉及到性能优化的方面，那真的是纯抽奖…… 1. 市面上没看到比较成熟的开源类似实现（没地方抄） 2. 我本人非计算机专业，也没系统学过（不了解性能瓶颈的发生位置与原因） 3. 再叠加上exfat、ntfs的兼容…… 综上所述整个人都是懵的。 唯一的好消息是电脑配置太低，一般能比较方便地本地复现。然后一点点抓dmp、来回debug……维护得极其勉强…… 充分可见不懂专业知识的即便能通过AI的协助，借助已有的其他语言知识触类旁通，但也通不了太多，专业的事还得专业的人来干。我至今也没整明白怎么优化追踪exfat磁盘的文件变化的占用。哪怕用户的[issue](https://github.com/Lertaro/Lertaro/issues/298)都开到我脸上来了，我也还是修不了…… 虽然我知道原因，但我就是修不了，难受…… * * * by the way，everything真是绝了，怎么做到搜得又快，占用又低的（相对其他同类搜索软件），这是什么神仙级别的优化，体积还那么小