放下傲慢！停止自欺欺人！与其做AI的主人，不如做它的搭档——慢慢学AI142

写在前面：

• AI 编程是帮我们写一些简单的脚本?
  • 或生成我们不愿意写的重复代码
  • 是否过于依赖简单的命令？是否低估了 AI 的创意激发潜力？
  • 当我们面临复杂任务时，是否太快地放弃 AI，认为它无法胜任？
• 我们总是喜欢手搓，看起来是把关兜底：
  • AI 的代码可能没有灵魂？无法理解复杂逻辑？
  • 我们害怕一旦出现问题，找谁背锅去。
  • 这种疑虑让我们停留在“工具”的视角，未能看到 AI 真正的协作潜力。
• 许多人认为有了 Copilot/类 Copilot/Cursor 等 AI 工具就能实现编程自由
  • 怎么可能呢？
  • 就像 AI 画图或生成视频一样，初期的兴奋之后，挑战依然存在。
• 如果没有专业训练，无法编出高质量的程序
  • AI 的加入是否会加剧系统质量下降
  • 或将世界变得更好？
• 为什么要放下自己的积累和成见
  • 因为我们对问题难度的理解和 AI 并不相同

AI 编程正在彻底颠覆我们的工作方式，它不再只是写点代码的工具，而是一个强大的协作伙伴！如果还把 AI 局限于执行简单任务，那已经落后了。初学者反而更具优势，因为他们不被固有框架束缚，敢于大胆创新。而“早期玩家”，“资深玩家”呢？还在困在老旧的思维中，没看到 AI 真正的潜力。机会与挑战并存，AI 的创造力足以让人突破瓶颈，敢放手让它主导吗？不敢？那注定会被抛在身后！准备好了吗？Dive in, 或者被淘汰。

前言：重新思考 AI 编程的潜力

去年，Copilot 横空出世，以每月 20 美元的价格确立了这类工具的标准，也因为它确实能提高效率，使大家乐此不疲。而最近大热的 Cursor，其实去年就已经发布，但直到 Claude 3.5 版本推出后，它才开始大放异彩。各大厂也有自己的代码生成团队，但效果因人而异。

AI 编程工具的出现大幅提升了代码生成的效率，但我们往往只看到了它作为“高级工具”的表面潜力，用它来生成代码或完成任务。但是，AI 的潜力真的仅限于此吗？它绝不是池中之物！

AI 编程的常见误区：

1. 工具化思维：许多人仍然将 AI 视为工具，只会提供明确指令，获取具体结果，限制了 AI 的真正潜力。
2. 过分依赖指令：很多人只依靠简单命令生成代码，未能通过与 AI 对话挖掘深层次的创意解决方案。
3. 忽视协作潜力：AI 不仅可以生成代码，还能参与需求分析、设计讨论和优化工作流程。

1. 从工具到协作：AI 编程的转型

1.1 传统观念的局限性

AI 圈子看起来很大，但实际影响却有限。由于模型能力的限制，以及很多人对 AI 的初体验不佳，自媒体宣传的奇效并未在自己身上得到验证，导致许多人对 AI 产生了误解和怀疑。

在企业实践中，我们也发现 AI 普及的一个障碍是它的“门槛”——往往需要看到具体的成功案例，或者由外部力量引导，才能建立对 AI 的信任。

在编程辅助方面，如果 AI 使用不频繁，通常会将其视作一种高级的自动化工具，用来生成代码或完成重复性任务。虽然这种方式提高了效率，但也有明显的局限性：AI 仅处于辅助角色，我们称之为命令式。

具体表现：

在传统的命令式编程中，AI 执行的是单一、线性的任务。例如，当我们需要一个排序算法时，直接命令 AI 生成代码，它会按命令操作，但这种简单的执行模式限制了 AI 的更广泛应用。以下图所示，传统 AI 编程流程的局限性十分明显。

问题点：

命令式的“指令-执行”模式忽略了 AI 在创意激发和解决问题中的潜力。AI 被局限于简单的代码生成，而未能在设计优化、逻辑推理和需求分析等方面发挥作用。

在这个阶段，非 IT 人士或程序员很难融入，也难以想象普通人可以通过编程提升效率。转机来自于两方面：大模型能力的提升，以及更多 AI 使用中的实践积累，催生了对 AI 更高的期待。

如何突破这些局限呢？答案是给予 AI 更多的信任，赋予它更多的“自由”和“权力”。

1.2 新思维：从命令到协作

思维转变：

要真正解锁 AI 编程的潜力，我们需要从“命令式思维”转向“对话式编程”。这意味着，我们不仅仅向 AI 发出命令，还要通过深度互动，与 AI 一起讨论需求、设计和优化方案，让它成为编程中的合作伙伴。这种“对话”不仅仅指聊天形式，更意味着在编程之外进行更多的探索和协作。

实际应用案例：

在一个复杂项目中，开发者常常陷入细节而忽略整体设计和优化。通过对话式编程，AI 不仅可以帮助完成具体的编程任务，还能提出项目需求、设计思路和功能优化建议。例如：

可以把这种协作比作“抛球游戏”：资深技术人员可以在空中维持多个“球”不落地，但有了 AI 的协作，很多球可以放心地交给 AI。

通过这种协作，AI 不再只是代码生成工具，而是帮助开发者从全局角度出发，提出创意性方案，参与需求分析和设计讨论，极大地提升工作效率。

对话示例：

在一个项目中，如果你需要设计一个用户认证模块，传统的方法是直接生成代码，而通过对话与 AI 互动，你可以获得更多建议。例如：

• 你： “帮我生成一个用户注册页面。”
• AI： “你需要什么样的用户体验？是否集成社交登录？是否需要两步验证？”
• 你： “希望用户体验流畅，并确保数据安全。”
• AI： “建议集成 OAuth 2.0，并增加两步验证，确保数据安全。”

通过这种互动，AI 不仅生成代码，还帮助你分析需求并提出优化建议。

例如，社交登录的概念很容易理解，如微信扫码登录。而两步验证和 OAuth 2.0 稍显专业，但不用过于纠结理解它们的细节，重点是通过 AI 的建议，整体解决方案变得更加完整。

就像公司里招来一个名校毕业的助理，原本只是给他分配好任务，要求按时完成。后来无意中发现，这位助理相当资深，开会时记得请他一起讨论，并且给他更多的自由发挥空间。

接下来，我们将从与 AI 交互的四个角度深入探讨命令式和对话式的内在区别，以及如何让普通人通过与 AI 的互动辅助编程。

2. 和 AI 相处 1000 小时后，意识到自己的傲慢

前几年有个脱口秀讲了个段子，叫“加班闭环”：

经过多年发展，IT 信息化技术已经形成了非常复杂的体系，既包括技术也包括管理。如何保障系统健康运行，单靠人力既容易出错也不现实。运维的日常工作中有许多繁琐任务，总是离不开编写各种脚本。

传统的操作系统脚本不太算是完备严谨的编程语言，很多老运维人员对他们的脚本保密，甚至视为安身立命的秘密武器。然而，随着 DevOps 和 AI 的发展，这种状况有了很大改善。

这也引出了我在这方面的感受。今年初参与离谱村视频制作时，面对的原始文件是这样的：

当时的做法是让 AI 写个脚本来处理这个文件——非常典型的命令式方法。然而，调试这个脚本花了很长时间，因为我并不完全理解它的原理，结果显得“又菜又爱玩”。

2.1 我说你听 — AI 初相识，我们指挥 AI 干活

我们的能力上限决定了 AI 的能力上限。“我说你听”意味着我们有技术想法，让 AI 去实现。换句话说，就是自己也能做，只是想偷懒，让 AI 帮忙完成。

去年夏天，偶然有人请我们写一个自动备份配置的脚本。具体情况是：

• 有若干台不同操作系统的服务器（Ubuntu，Debian）
• 每个服务器上运行一些应用（基于 Podman 部署，但没有使用 k 8 s）
• 需要备份到云盘中，且定期清理

当时，我们对运维领域不太熟悉（也就是没吃过苦、没背过锅的意思），想着这应该不难，就决定挑战一下 Shell 脚本。虽然事情不紧急，但还是花了断断续续的时间。

我们花了大量时间熟悉 Shell 的语法和一些特殊用法。本以为 Shell 简单易上手，可以速战速决，结果却事与愿违，代码不仅难写，还不易交接给他人。

这时，AI 的作用就体现出来了，它可以教我们如何完成任务。虽然在过程中，我们并没有完全依赖 AI 来实现代码，但 AI 确实是很好的教练。

我说你听的典型例子：

• 请教 AI 具体问题：
  • “请告诉我 rclone 命令的用法。”
  • “Shell 里面的循环怎么写？”
  • “如何遍历一个文件夹的所有文件？”
  • “如何让 Shell 输出的内容显示为绿色？”
  • “如何让一个脚本每天自动运行？”

其实，大多数人没必要真的深入了解 Shell 的语法，只需告诉 AI 你的目标即可，AI 会提供解决方案。

从结果来看，AI 不仅写出了代码，还给出了详细的中文注释，帮助我们理解逻辑。即使代码部分看不太懂，光看注释也能大致了解。

当然，我们也可以直接问 AI 有没有现成的工具推荐，或者干脆找专业的人来完成任务。

“我说你听”的问题在于，我们的能力限制会成为 AI 的瓶颈，但我们自己往往不自知。接下来再看一个“我做你看”的例子。

2.2 我做你看 — Few-shot 指挥 AI，我们教它做事

有了之前的经验后，从投入产出比来看，能不自己动手就尽量不做，花钱省时间绝对是合理的选择。

还是用之前的备份案例。这次，我从网上找了一些现成的脚本，虽然看不太懂，但直接把它们发给 AI，说：“参考这些脚本，写一个新的出来。”

你是 Shell 的专家，我需要定期备份 Linux 服务器的数据到网盘中，请参考下面的代码帮我写一个…… 

这里的潜台词是：

• 这次照着做，不要瞎发挥。
• 上次被坑了，这次别乱来。
• 我需要看到结果和过程，按规矩来！

通常情况下，AI 会按要求给出所需的结果，这样的正反馈也带来了一些副作用。我们逐渐构建了一个信息茧房，这种模式用得越多，似乎就越顺手，但也限制了探索其他可能。

容易出现的问题有：

• 实际上可能用其他语言或工具可以更快解决问题。
• 但因为我们没给 AI 自由，它也没提出建议。

这两个问题的核心原因在于，我们太快进入了细节，急于用自己的经验解决问题，忽视了其他创新的可能性，也抑制了 AI 的发挥。

2.3 你做我看 — 放手让 AI 主导，相信相信的力量

最近尝试将一个 PPT 转化为网站时，遇到了一些困惑。PPT 中关于线下沙龙的内容有两页，如何组织好这两页并进行切换，当时并没有好的思路。心里想了一些方案，但老实说并不知道如何实现，因为真的不懂。

于是我决定放手让 AI 给些建议看看。

这是我当时向 AI 咨询的记录。从这里可以感受到，当我们放下自己的执念时，AI 可以带来惊喜。在这个过程中，我想了三种方案：

• 菜单中增加二级菜单。
• 右侧放置卡片，每页对应一个卡片。
• 使用箭头进行切换，有就切换，没有就不显示。

当时差点就去谷歌搜关键字找代码示例了，突然想到，为什么不直接问 AI 呢？

于是，我告诉 AI 这些需求，并询问如何维护管理对应关系。AI 提出了第四种方案，还给出了代码。

放下执念，不给 AI 预设立场和方案，可以极大地突破自己的知识和认知边界。能不能再迈出一步？

2.4 你说我听 — 从需求到设计，AI 的全程参与

一个小伙伴想要一个 AI 视频一站式工作台，将过去使用的 ChatGPT、MJ、Runway 等工具整合在一起。这次我学乖了，虽然心里有想法，但没有直接告诉 AI，而是全程由它来引导。

一开始还有些担心 AI 不理解图片的内容，但事实证明这种担心是多余的。作为产品经理，放下自己的想法并不容易，但这次的效果却出乎意料的好。

2.5 从“命令式”到“对话式”，放手吧

通过前面的几个例子，我们看到，和 AI 的互动就像陪伴孩子成长一样，需要逐渐抽离、逐渐信任、逐渐放手。而最终，我们得到的远比失去得多。

命令式编程

我们习惯于通过明确的指令让 AI 执行具体任务，比如“帮我写一个排序函数”或“生成一个 API 接口”。这种方法简单直接，但也浪费了 AI 更大潜力的发展机会。

对话式编程

相比之下，“对话式编程”鼓励我们与 AI 进行深度互动。与其直接命令 AI 编写一个函数，不如和它讨论背后的需求：“这个功能是否真的必要？”、“符合 MVP 的标准吗？”、“有没有更简洁或更高效的实现方式？” 通过这种对话，AI 不仅提供代码实现，还能为我们带来更多创意和优化的可能。

AI 带来的编程转变：从想法到实现的协同探索

通过前面的探讨，我们意识到 AI 的强大之处在于它不仅能帮我们解决代码问题，还能从想法到实现全程协助。

想象一下，有了一个创新产品的想法——在过去，我们可能需要找专业开发者来实现，或者自己花费大量时间学习编程。而在今天，只需描述你的想法，AI 不仅能生成相应代码，还能帮助我们验证需求、优化实现路径，甚至根据用户反馈进行功能迭代。

因此，我们可以对 AI 编程的发展进行这样的总结：

注意事项：虽然AI降低了编程门槛，但初学者仍需谨慎使用。过度依赖AI可能导致基础知识的缺失，影响长期的编程能力发展。建议将AI作为学习工具，而不是完全替代传统学习方法。

到此，我们已经从四个不同的视角阐述了与 AI 相处的方式。接下来，我们将进一步探索——在具备这些技能的基础上，与 AI 相处时还需要注意哪些问题？

3. 与 AI 共舞：放下控制欲，拥抱探索

在许多情况下，我们只需给 AI 下达明确的命令来完成一次性任务，例如制作一个简单的 Chrome 插件、编写脚本、或创建 Python 爬虫。但当 AI 满足了我们简单的需求，并让我们获得正反馈之后，我们的期待也会不断提高，希望能进一步从繁琐的日常任务中解脱出来。这个时候，我们需要了解 AI 编程的边界和限制。

3.1 AI 编程准则第一条：能不编，尽量不编

随着 IT 技术的发展，各种基础设施和工具越来越多，大多数需求都能找到现成的软件解决方案，只需权衡投入产出，进行评估即可。

搜索技巧的逆袭：在 AI 统治的世界中寻找价值

• 成熟产品
  • 优先找线上工具：例如制作白底图等功能，如果线上有现成的工具那最好。
  • 其次找插件：基于现有系统找合适的插件。
  • 最后是本地应用：当线上工具和插件都不满足需求时，再考虑本地应用。
• API 功能
  • 先找现成的开源工具，GitHub 上很多。
  • 然后考虑付费服务。

如果都找不到现成的方案，才考虑自己编程。毕竟，人生苦短，何必为难自己呢？如果真的需要动手编写，也要以终为始，抛开技术障碍，聚焦于目标。

3.2 因为不懂，所以敢想——初生牛犊不怕虎

在为企业非 IT 部门介绍 AI 编程时，一些人由于害怕新事物或受学生时代编程的痛苦回忆影响，对编程有排斥心理。但在我们的实践中，不懂反而成为了优势。因为不知道实现的技术难度，所以敢于提出大胆的想法，更专注于业务需求。

这种心态在 AI 辅助编程中至关重要：

• 跨平台支持 Mac、Linux 和 Windows 的程序难不难？
• 支持多国语言的应用难不难？
• 与小朋友互动的智能硬件应用难不难？
• 开发 Photoshop、C4D、Office 等插件来减少日常工作，难不难？

说实话，我们不知道，因为我们不懂。但关键在于：“会者不难，难者不会”。当我们不被技术储备限制，朝目标前进时，命运的齿轮就会转动起来。

例如，针对跨平台的应用，我们只需问 AI：“如何把代码打包成跨平台应用？”

最终结果	打包过程	会话

敢想比敢干更重要

动起来是必要的，但要懂得如何动手才行。

3.3 因为看见，所以相信——先整体后局部

既然我们敢想，也迈出了实践的第一步，但还是需要保持冷静，花更多时间在想要达到的最终效果上，而不是过分纠结于技术细节。

例如，针对文本生成视频的一站式工作台，我们需要更多地打磨交互体验。虽然“打磨”听起来可能有点沉重，但其实并不需要太多担忧。

传统的产品经理工具如 Figma 和 Axure，对于普通人来说仍有一定门槛，可以在未来学习。但现在，我们可以让 AI 帮忙制作界面设计，就像之前提到的“你说我听”的例子。

这样做的好处包括：

• 看到效果，才敢推进：我们需要尽快看到成品的效果，这样才能有信心进一步推进项目。
  • 但不要急于求成，保持冷静。
• 一开始尽量多考虑一些细节：可以帮助我们避免后续陷入完美主义。
  • 随着项目的深入，我们的想法会越来越多，也可能变得越来越苛刻。

因为看见，所以相信。当我们看到项目的最终呈现效果时，更容易下决策推进。拥有整体设想，也能避免中途被各种诱惑带偏。

3.4 延迟优化，关注核心功能

在与 AI 交互的过程中，随着经验的积累，我们的能力会不断增强。这个时候需要避免的是过早优化一些不重要的功能和界面。

例如，针对文本转视频的功能，最初我们希望剧本能显示字数，但改了几次都没有做好（即使是让 AI 改的）。这种情况很像外行领导对着周报挑剔“字体间距不对”，自己折腾了半天也搞不定，最后只好含糊地说一句“下次注意”。

什么是核心功能？完全可以和 AI 商量。

避免在局部优化时带来全局混乱，确保每个改动都能看到实际效果，而不是对着一个永远不完善的半成品耗费精力。

3.5 从小开始，避免大而全，尽快看到结果

对于完全没有编程基础的人来说，起步比较简单，但有些稍微懂一些编程的人，往往会有一种“大而全”的追求。

还是以文本转成视频的例子来说，中间涉及将文本转成图片。然后开始考虑：

• 有可能会有多人参与。
• 有可能会同时开展多个项目。
• ……

因此，预留了很多可能性。进一步考虑到这个系统要同时支持移动终端、网页端、以及桌面程序（如 mac 和 Windows），于是就问 AI 有没有什么办法可以实现代码跨平台共用，保持一致性。

在这个过程中，虽然学到了一些新奇的知识，但也收获了不少挫败感。

图中的文件夹结构包含客户端、web 端、管理后台等等。对于普通人而言，还是需要量力而行。也许未来可以实现，但目前确实有难度。

一开始，我们可以和 AI 探讨系统的最关键和核心功能是什么，优先确保这些最重要的功能能够完成。至于后续的拓展，等到实际需要时再说。

3.6 避免完美主义，跑起来才有新灵感

和写文章类似，我们很容易陷入完美主义的情结。这里的完美主义可能体现在多个方面，哪怕是我们自己用的工具或系统，不对外提供服务，也会遇到这种困扰。

• 希望系统更灵活
  • 希望通过一些配置就能生效，而不是固定的。
• 希望系统更智能
  • 希望它能适应不同的大模型，并通过简单配置支持新的模型。
• 希望系统更好看
  • 看到别人的系统很漂亮，就想着去改进自己的界面。
• 希望系统有不同皮肤
  • 希望自动适应白天和晚上的配色。
• 希望系统有统计功能
• ……

完美主义会不知不觉中让我们陷入项目范围不断扩大的困境。如果这个系统是对外的，可能情况会更严重。

经验表明，尽快让系统“跑起来”，让它能被实际使用，这样才能获得真实的用户反馈，推动系统不断改进。

3.7 不期望 AI 一次搞定，也不想去抢程序员的饭碗

就像很多 AI 工具一样，我们起初可能对 AI 充满期待，以为它是一种银弹、利器，一句话就能解决所有问题。这种期望常常会带来巨大的挫败感。

同时，现代编程语言大多能很好地告诉我们错误出在哪里，将这些错误信息交给 AI，它通常可以给出帮助。这时我们只是一个搬运工。

但也有例外，有些问题提示并不清楚。例如，在系统中使用智谱模型时，配置如下：

TRANSLATION_API_BASE_URL=https://open.bigmodel.cn/api/paas/v4/
TRANSLATION_API_MODEL=glm-4-flash
TRANSLATION_API_KEY=8f7e10904a0c

在让 AI 编写代码时，我只是告诉它写一个兼容 OpenAI 模式的代码（因为智谱没有官方支持的 NodeJS 版本 API，但兼容 OpenAI，所以使用 OpenAI 的库）。AI 使用了 OpenAI_BASE_URL 的 key，导致系统不断报错，错误信息非常长，也没有指明具体位置。最后通过添加一些输出信息，才找到问题所在。

总结起来，可以从这个图上可以看出来

注意事项：在全流程使用AI时，需要注意保持人为判断和决策的重要性。AI可能无法完全理解项目的全局需求和长期目标，因此关键决策仍需人类开发者的参与和审核。

4. AI 编程的一般性流程

4.1 案例交互展示

这是一个视频从脚本到图片的网址流程图，大致是从一段文字，拆分文案，每个文案分别出画面描述，这里的 gpts 是基于 prompts 的，最终会放在我们网站内，通过 api 调用来实现，后面可以批量调用 mj 的 api 来生成图片，mj 第一次出图可能效果不好，需要调整，另外它会出 4 张图供选择，这个地方可以多次反复，最后把图片和我们内置的 prompt 去调用 runway 等视频 api 出视频，最终调用剪映来完成，我想因为有客户端操作，可能合适的方案是做客户端程序，你先从生产力工具专家，产品经理的视角，帮我设计交互界面，让我参考

第一步的脚本是很长的，所以是一个很大的输入框，最好旁边显示字数，拆分以后，是多个内容，你可以看看什么方式交互比较好，可以用类似表格的形式，或者是card的形式，根据你的经验来，这里你帮我预设一段脚本，后续拆分以后是10个文案，另外我能看出来，每个文案的状态，比如是否进行过一次mj的交互，生成了图片，是否经过了2次交互，也就是选择了其中一张图片进行操作，是否进行过runway的交互生成了视频，图片和视频都直接展示在卡片或者单元格中

整体上可以了，生成图片是2个部分，你要不然分左右好了，左边是4格图，右边是一张大图，图片可以点击放大看，鼠标移动过去在图的右下角有2行4列按钮，分别是 V1 V2 V3 V4 U1 U2 U3 U4

这个第二步这里，最上面可以放一个工具栏，上面放一个按钮，全部生成，它的第一个步骤这里计数信息和 Enter Your Script 放一起，字数右对齐，这样空间节约一些

非常好，第二步最上面再加个按钮，生成所有视频，另外，刚刚那个v1 v2 u1 u2 应该是在左边的图上的，不是右边的图。重新给我生成一个，然后一步步告诉我如何创建一个nextjs的项目，我注意到你似乎使用了一个ui组件，也一起告诉我步骤

篇幅原因，放出几个关键步骤。

4.2 网页上与 AI 交互编程的一般流程

通过探索，我们总结了在网页上与 AI 对话式辅助编程的一个通用流程，如下所示：

补充说明：

1. 讨论需求：明确项目目标和用户需求，确保团队对产品方向有一致的理解。
2. 确定关键功能：根据需求确定产品最核心的功能，确保能实现最基本的用户价值。
3. AI 生成产品草图：利用 AI 快速生成界面草图，帮助团队更好地理解产品的外观和交互。
4. 列出功能列表：明确产品所需的功能模块，并逐一列出。
5. 选择一个功能：每次专注完成一个功能，确保质量与效率。
6. 向 AI 描述功能：详细描述功能需求，AI 会根据描述生成代码。
7. AI 编写代码：AI 根据需求编写代码，减少开发者的重复性劳动。
8. 测试代码：测试生成的代码，确保正常运行。
9. 向 AI 提出问题：若功能不正常，将问题反馈给 AI 进行调整。
10. 功能完成：功能通过测试后标记为完成。
11. 还有功能吗：若还有未完成的功能，继续开发下一个功能。
12. 发布初始版本：所有核心功能完成后发布初始版本，以获取用户体验反馈。

4.3 网页聊天式编程的局限性

在没有使用 Cursor、Copilot 等工具的情况下，我们可以通过与 AI 对话的方式，在网页上编写一些”Hello World”式的应用，这些应用不一定只是玩具，在大多数情况下也可以使用。在具体编程过程中，我们会交替使用 Claude、Gemini 和 ChatGPT。然而，这种方法也存在一些局限性。

技术概念速览：
- Token：AI处理文本的基本单位，通常一个单词对应1-2个token。
- API（应用程序接口）：软件组件之间交互的规则和工具集。
- 上下文：AI理解和回应时参考的前后文信息。

4.3.1 上下文限制

不同的 AI 平台有不同的限制方式：

• Claude 基于 Token 限制上下文
  • 简单理解就是每次和 AI 对话，可能有多个来回，但是所有内容字数加起来不能太多
  • 如果超过了，它就会忘记一些内容，Claude 直接就提示我们要另起一个对话了

• ChatGPT 限制会话轮数
  • 简单理解就是，一天之中，我们和 AI 会话的次数有限制
  • 比如说，4 个小时，只能和它说 50 句话
  • 那么我们只能每次说之前多准备一些内容

这意味着，当功能比较复杂时，在一次会话中可能无法全部完成，需要多次会话来完成。

应对策略：

• 将复杂任务分解为小模块
• 定期总结关键信息
• 在新会话中重新引入重要上下文

4.3.2 版本兼容性

大模型训练完成以后，基本上就固定了。例如，如果 ChatGPT 训练时 iPhone 16 还未发布，它就不会知道相关信息，除非重新训练。这个问题同样适用于软件版本。

API 兼容性指不同版本的编程接口之间的兼容程度。当 AI 推荐的 API 版本与实际使用的不一致时，可能导致代码无法正常运行或需要大量修改。

解决这个问题需要我们：

• 明确指定所需的库版本
• 请求 AI 使用最新版本的 API
• 手动检查并更新关键依赖

实用提示：
在描述需求时，明确指出您使用的技术版本，如"使用React 18和Node.js 14版本"，以确保AI提供相兼容的代码和建议。

4.3.3 连续性和一致性

在多次会话中完成一个项目时，保持代码风格和架构的一致性是一个挑战。这可能需要我们：

• 定期回顾和总结已完成的部分
• 为 AI 提供 clear coding guidelines
• 在每次新会话开始时重申项目的整体结构

因此，我们需要总结关键信息，并在下次会话中引入，以便 AI 了解我们的需求。随着系统规模扩大，这样的操作费时费力，且相当扰乱我们要专注完成的任务。

实用提示：
创建一个简短的项目概要文档，包含主要功能、使用的技术栈和代码风格指南，在每次新会话开始时提供给AI。

4.4. AI 编程的潜在风险

AI 编程还远没有达成终极形态，还有很多变数。加上很多企业有合规要求，数据隐私的要求，无法使用最新的模型。需要避免机密信息。

也应该避免过度依赖 AI，避免 AI 对我们的反向影响，从而形成新的信息茧房。

4.5 接下来做什么

随着我们学习的越来越深入，越玩越 high，开始要面对这些问题了

• 代码越写越长，怎么才能让它更易读、易维护？
• 做完了，打开系统很慢，很卡，但不知道该从哪里下手优化？
• 代码看起来已经很复杂了，加一个新功能，不知道会影响到哪些代码？
• 从网上找到了一段代码，功能是挺好的，但是它是 Python 的，现在的代码是 TypeScript 的，怎么办呢？
• 代码里有很多重复的部分，有什么好方法可以简化吗？
• 听说用到的一个什么库，版本很低，马上没人管了，怎么办呢？
• 有一个界面布局要调整，涉及很多文件，不知道有哪些？

除了这些，使用 AI 辅助编程，还有一个点，是它给出的代码中，引用的是比较旧版本的库，如何解决呢？

且听下回分解，我们来看看 cursor 等工具，真正解决的是什么问题，又是如何解决的，哪些问题没解决呢？