还记得今年火热的 3 月，Manus 发布当天就引爆了社交网络。邀请码一码难求，甚至在二手平台被炒出天价。创始人肖弘（人称red）带领的这支年轻团队，用一个产品点燃了整个行业对 AI Agent 的热情。

2025 年是 AI Agent 元年。AI Agent 的发展速度惊人。不只是 Manus 这种通用型 Agent，还有各种垂直领域的，如 设计领域的 lovart，编程领域的 Claude Code Cursor 等等。

那什么是 AI Agent，它由什么组成？今天我们聊一聊。

1. 从专家系统说起

要说 AI Agent 的历史，得从上世纪 60 年代说起。那时候，计算机科学家们就在琢磨一个事：能不能让机器像人一样，自己去感知环境、做出决策、然后采取行动？

最早的尝试是专家系统。比如 1970 年代斯坦福大学开发的 MYCIN，这是一个诊断血液感染疾病的系统。它的工作方式很简单：问医生一堆问题，然后根据预设的规则给出诊断建议。虽然现在看来很原始，但在当时，这已经算是「智能」了。

到了 80 年代，出现了更复杂的系统，比如 R1/XCON，帮助 DEC 公司配置计算机系统。这些系统有个共同特点：它们都是基于规则的。你得事先把所有可能的情况都想到，然后写成 if-then 规则。问题是，现实世界太复杂了，你不可能把所有情况都考虑进去。

90 年代，研究者们开始尝试新的路子。他们发现，与其让人去编写所有规则，不如让机器自己去学习。于是有了基于机器学习的 Agent，比如强化学习 Agent。这些 Agent 可以通过试错来学习如何完成任务。

但真正的转折点出现在 2010 年代深度学习兴起之后。特别是 2017 年 Transformer 架构的出现，彻底改变了游戏规则。有了 GPT、BERT 这些大语言模型，AI Agent 突然变得「聪明」了很多。它们不再需要人类事先编写规则，而是可以理解自然语言，根据上下文做出合理的判断。

2. 现代 AI Agent 的样子

要理解现代的 AI Agent，我们得先搞清楚它到底是什么。

简单来说，AI Agent 就是一个能够自主感知环境、制定计划、采取行动来完成特定目标的系统。听起来很抽象？我举个例子：

假设你要让 AI 帮你订一张从北京到上海的机票。一个简单的聊天机器人可能只会回答：”请您登录航空公司网站自行预订。”但一个真正的 AI Agent 会这样做：

1. 理解你的需求（什么时间、预算多少、有什么偏好）
2. 搜索多个航空公司的航班信息
3. 比较价格和时间
4. 根据你的偏好筛选
5. 甚至可能帮你完成预订（如果有相应的接口）

这就是 AI Agent 和普通 AI 应用的区别：它不是被动地回答问题，而是主动地解决问题。

3. 核心技术和架构

现在咱们来看看 AI Agent 是怎么实现的。核心架构可以分成四个部分：

3.1 感知模块

这是 Agent 的「眼睛」和「耳朵」。它需要理解用户的输入，同时还要感知环境的状态。比如，当你让 AI Agent 帮你写代码时，它需要理解：

• 你想要实现什么功能
• 使用什么编程语言
• 有什么特殊要求
• 当前的代码结构是什么样的

但这里有个关键点：感知模块需要区分两种不同的信息——状态上下文和意图上下文。

状态上下文是环境的客观信息。比如：

• 当前项目使用的是 Python 3.9
• 代码库里已经有了用户认证模块
• 数据库是 MySQL
• 使用的是的 FastAPI 框架

这些信息是确定的、可验证的事实。Agent 需要准确地获取和理解这些信息，因为任何误判都可能导致后续行动的失败。

意图上下文则是用户想要达成的目标，这往往更加模糊和主观。比如用户说「帮我优化一下这段代码」，Agent 需要理解：

• 「优化」是指性能优化还是可读性优化？
• 用户的性能预期是什么？
• 有没有特定的约束条件？

区分这两种上下文至关重要。很多 AI Agent 的失败，就是因为混淆了状态和意图。比如，用户说「这个函数太慢了」，Agent 需要识别出：

• 状态：函数执行时间是 500ms
• 意图：用户希望降低到 100ms 以内

现代的 AI Agent 通过多种方式来增强感知能力：

多模态感知：不只是文字，还包括图像、语音、甚至视频。Cursor 支持图片上传，代码索引，文档等。

主动询问：当信息不充分时，优秀的 Agent 会主动提问。「你提到要优化性能，具体是想优化响应时间还是内存占用？」这种澄清式的对话，能大大提高后续行动的准确性。

历史记录：通过分析用户的历史行为，Agent 可以更好地理解当前的意图。如果用户之前多次要求「简洁的代码」，那么在新的任务中，Agent 就会倾向于生成更简洁的解决方案。

环境探测：高级的 Agent 还会主动探测环境。比如，在开始写代码前，它可能会先检查项目的配置文件、依赖列表、测试用例等，构建一个完整的环境画像。

感知的准确性直接决定了 Agent 的表现。一个看不清路的司机，再好的驾驶技术也没用。同样，一个不能准确理解用户意图和环境状态的 Agent，后续的规划和执行必然会出问题。

3.2 推理模块

这是 Agent 的「大脑」，也就是大语言模型。现在主流的做法是使用 GPT-4、Claude、Gemini 这样的大模型。但光有大模型还不够，还需要深入理解不同模型的特性，才能让它们更好地工作。

模型的性格差异

就像人有不同的性格，AI 模型也有各自的「个性」。这不是玄学，而是训练方式和优化目标的差异造成的。

以 Cursor 编辑器的实践为例，他们把模型分为两大类：

思考型模型（Thinking Models）：

• Claude 3 Opus：喜欢先理解全局，会主动推断你的意图
• Gemini 2.0 Flash：自信果断，经常会做出超出预期的大改动
• o1：专门为复杂推理设计，会花时间深入分析问题

这类模型就像经验丰富的专家，你给它一个大方向，它会自己规划路径。适合探索性任务、大规模重构、或者当你自己也不太确定最终方案时使用。

执行型模型（Non-thinking Models）：

• Claude 3.5 Sonnet：等待明确指令，不会过度推断
• GPT-4 Turbo：行为可预测，适合精确控制
• 文心一言 4.0：在中文任务上表现稳定

这类模型像是可靠的助手，严格按照你的要求执行。适合明确的任务、需要精确控制的场景、或者当你已经知道要做什么时使用。

选择模型的艺术

选择合适的模型，就像选择合适的工具。你不会用大锤子去拧螺丝，也不会用螺丝刀去砸钉子。

根据任务类型选择：

• 代码生成：Claude 3.5 Sonnet 和 GPT-4 都很优秀
• 代码理解和重构：Gemini 2.0 Flash 的长上下文能力突出
• 复杂 Bug 调试：o1 的深度推理能力更适合
• 中文文档处理：通义千问、豆包有本土优势

根据交互风格选择：

• 如果你喜欢给出详细指令：选择执行型模型
• 如果你偏好给出大方向：选择思考型模型
• 如果你需要创造性方案：选择更”活跃”的模型
• 如果你需要稳定输出：选择更”保守”的模型

提示词工程的进化

早期的 AI Agent 严重依赖精心设计的提示词。但随着模型能力的提升，这种情况正在改变。

从复杂到简单： 过去我们可能需要这样的提示词：

你是一个专业的Python开发者。请严格遵循PEP8规范。
在编写代码时，请考虑以下几点：
1. 代码的可读性
2. 性能优化
3. 错误处理
...（还有20条）

现在，一句简单的”帮我优化这段代码”就能得到不错的结果。

动态提示词策略： 现代 AI Agent 会根据上下文动态调整提示词：

• 初次对话：使用更详细的背景说明
• 后续对话：只提供增量信息
• 错误修正：加入具体的约束条件
• 创造性任务：减少限制，鼓励探索

混合模型策略

越来越多的 AI Agent 开始采用混合模型策略，在一个任务流程中使用多个模型：

1. 理解阶段：使用 Claude 3 Opus 深入分析需求
2. 规划阶段：使用 o1 制定详细的执行计划
3. 执行阶段：使用 GPT-4 Turbo 快速生成代码
4. 优化阶段：使用专门的代码模型进行微调

这种方式能够充分发挥每个模型的优势，同时控制成本。

3.3 记忆模块

人做事情需要记住前面发生了什么，AI Agent 也一样。记忆分成几种：

• 短期记忆：当前对话的上下文
• 长期记忆：之前的对话历史、学到的知识
• 工作记忆：执行任务过程中的中间状态

但实现一个好的记忆系统，比想象中要复杂得多。

3.3.1 记忆的层次结构

就像人脑有不同类型的记忆，AI Agent 的记忆系统也需要分层设计：

感知记忆（Sensory Memory）：

• 保存时间：几秒到几分钟
• 内容：用户刚刚的输入、系统刚刚的输出
• 用途：处理连续对话中的指代关系

工作记忆（Working Memory）：

• 保存时间：整个任务周期
• 内容：当前任务的状态、中间结果、待办事项
• 用途：复杂任务的分步执行

情景记忆（Episodic Memory）：

• 保存时间：数天到数月
• 内容：完整的对话历史、任务执行记录
• 用途：理解用户偏好、避免重复错误

语义记忆（Semantic Memory）：

• 保存时间：永久
• 内容：领域知识、最佳实践、学到的模式
• 用途：积累经验、提升能力

3.3.2 实现方案-RAG（检索增强生成）

这是目前最成熟的方案。基本思路是：当 AI Agent 需要回答问题时，先去知识库里检索相关信息，然后把这些信息作为上下文提供给大模型。

比如你问：”我们公司的年假政策是什么？”Agent 会先去检索公司的政策文档，找到相关内容，然后基于这些内容生成回答。

RAG 的进化史

第一代 RAG（2020-2022）：

• 简单的向量检索
• 使用 BERT 或 Sentence-BERT 做编码
• 召回 Top-K 相关文档
• 效果一般，经常找不到真正相关的内容

第二代 RAG（2023-2024）：

• 引入混合检索（向量+关键词）
• 使用更强的编码模型（如 BGE、E5）
• 加入重排序（Reranking）步骤
• 开始考虑文档结构和语义分块

第三代 RAG（2024-现在）：

• 多级索引结构（摘要→章节→段落）
• 查询改写和扩展
• 动态上下文窗口调整
• 引入知识图谱增强检索

实践中的 RAG 优化技巧

1. 智能分块：不要机械地按字数切分，而是按语义单元切分

   • 代码：按函数/类切分
   • 文档：按章节/段落切分
   • 对话：按话轮切分

2. 多路召回：同时使用多种检索策略

   • 向量相似度检索
   • BM25 关键词检索
   • 实体链接检索
   • 基于图的检索

3. 上下文工程：检索到的内容需要精心组织

4. 增量索引：新知识的实时更新

   • 使用流式处理架构
   • 支持热更新索引
   • 版本控制和回滚机制

3.3.3 实现方案-超长上下文

最新的趋势是直接增加模型的上下文长度。比如 Claude 3 已经支持 200K token 的上下文，Gemini 1.5 Pro 甚至支持 200 万 token。

长上下文的真实挑战

虽然模型号称支持超长上下文，但实际使用中会遇到很多问题：

1. 「迷失在中间」现象：模型对上下文开头和结尾的内容记忆较好，但中间部分容易遗忘

2. 注意力稀释：上下文越长，模型对每个部分的注意力就越分散

3. 推理退化：在超长上下文中，模型的推理能力会显著下降

混合方案：长上下文 + 选择性注意

3.3.4 主动遗忘

这是一个反直觉但很重要的概念：不是记住越多越好，而是要学会遗忘。

为什么需要遗忘？

1. 降噪：不是所有信息都值得记住
2. 隐私：某些敏感信息需要及时删除
3. 效率：保持记忆系统的高效运转
4. 相关性：过时的信息可能产生负面影响

遗忘策略

1. 基于时间的遗忘：

   • 会话结束后 24 小时删除临时信息
   • 30 天后归档低频访问的记忆
   • 90 天后删除无用的错误记录

2. 基于重要性的遗忘：

   • 使用 LRU（最近最少使用）策略
   • 基于访问频率的动态评分
   • 保留高价值的”关键时刻”

3. 基于相关性的遗忘：

   • 当新信息与旧信息冲突时，更新而非累加
   • 合并相似的记忆，避免冗余
   • 定期整理和压缩记忆库

3.4 行动模块

这是 Agent 的「手脚」，让它能够真正做事情。

行动模块的核心是 Function Calling（函数调用），这是目前最主流的方式。

简单来说，就是预先定义好一系列函数，比如搜索网页、查询数据库、发送邮件等，然后告诉大模型这些函数的作用和参数。

当用户提出需求时，模型会判断需要调用哪个函数，提取相应的参数，执行函数并获取结果。这个过程已经从最初的单次调用，进化到现在可以进行多步骤调用、并行执行、错误重试等复杂操作。

Anthropic 推出的 MCP（Model Context Protocol）协议，试图建立行动模块的统一标准。

MCP 采用服务器-客户端架构，工具提供方作为服务器，AI 应用作为客户端，通过标准化的协议进行通信。这种设计的好处是解耦和复用：AI 应用不需要知道工具的具体实现细节，一个 MCP 服务器可以同时服务多个 AI 应用。更重要的是，MCP 提供了统一的安全管理和权限控制机制，让行动模块的集成变得更加简单和安全。

安全性是行动模块最关键的考虑因素。

在 Manus 刚上线的时候就爆出一个问题，有人用提示词，让 AI Agent 打包了当前执行的环境的所有代码。

给 AI 执行能力就像给孩子一把剪刀，必须设置严格的安全边界。现代 Agent 通常采用多层防护：首先是沙箱环境，所有代码执行都在隔离的容器中进行，限制内存、CPU、网络访问；其次是权限管理，基于用户角色和具体场景动态分配权限；最后是审计日志，记录所有行动的执行情况，便于追溯和分析。这些措施确保 Agent 在帮助用户的同时，不会造成安全风险。

复杂任务往往需要多个行动的协调配合，这就需要工作流引擎来编排。比如”帮我分析竞品并生成报告”这个任务，可能需要先搜索竞品信息，然后提取关键数据，接着进行对比分析，最后生成可视化报告。工作流引擎负责管理这些步骤的执行顺序、处理步骤间的数据传递、应对执行失败等情况。高级的引擎还支持条件分支、循环执行、并行处理等复杂逻辑，让 Agent 能够处理更加复杂的任务。

行动模块的未来发展方向是更强的自主性。目前的 Agent 主要执行预定义的动作，但未来可能会具备动作发现和学习能力，能够自动发现新的 API、学习新的操作模式、甚至创造性地组合已有动作来完成新任务。另一个重要方向是与物理世界的交互，通过机器人或 IoT 设备执行物理动作。随着这些能力的提升，AI Agent 将真正从「会说」进化到「会做」，成为人类在数字世界和物理世界中的得力助手。

4. 当前的局限性

AI 有其局限性，了解这些局限性，对于合理使用和未来改进都很重要。

4.1 幻觉问题

这是所有基于大模型的 AI Agent 都面临的核心挑战。

Agent 可能会编造不存在的 API、虚构执行结果、或者对自己的能力过度自信。比如，当你要求 Agent 查询某个数据库时，它可能会返回看起来合理但实际上完全虚构的数据。

这种幻觉在连续多步骤的任务中会被放大，一个小错误可能导致整个任务链的崩溃。

更危险的是，这些幻觉往往很难被发现，因为它们在表面上看起来完全合理。虽然通过 RAG、工具调用验证等方法可以部分缓解，但彻底解决仍然是个开放性难题。

4.2 可靠性不足

AI Agent 的表现稳定性仍然是个大问题。

同样的任务，在不同时间执行可能得到不同的结果。

这种不确定性来源于多个方面：模型本身的随机性、上下文理解的偏差、外部环境的变化等。

在一些对可靠性要求高的场景，比如金融交易、医疗诊断、工业控制等，目前的 AI Agent 还远远达不到要求。

即使加入了重试机制、结果验证等保障措施，也只能提高而非保证可靠性。这导致在关键业务场景中，AI Agent 更多是作为辅助而非主导。

4.3 成本与效率

运行一个功能完善的 AI Agent 系统成本不菲。

首先是模型调用成本，特别是使用 GPT-4、Claude 等顶级模型时，每次交互都要花费不少钱。复杂任务可能需要多次模型调用，成本会快速累加。

其次是延迟问题，每次函数调用、每次推理都需要时间，一个看似简单的任务可能需要等待数十秒甚至几分钟。对于需要实时响应的场景，当前的 AI Agent 往往力不从心。

虽然可以通过模型蒸馏、缓存优化等手段降低成本，但在性能和成本之间找到平衡点仍然很困难。

4.4 安全与隐私挑战

AI Agent 需要访问大量数据和系统才能发挥作用，这带来了严重的安全隐私问题。

首先是数据泄露风险，Agent 可能无意中将敏感信息包含在给大模型的请求中，而这些数据可能被用于模型训练。

其次是提示注入攻击，恶意用户可能通过精心构造的输入操控 Agent 执行非预期的操作。

还有权限滥用问题，一个被赋予过多权限的 Agent 可能造成严重损害。

虽然业界正在开发各种防护措施，如差分隐私、安全沙箱、细粒度权限控制等，但攻防对抗仍在继续。

4.5 理解与推理的局限

虽然大模型展现出了惊人的能力，但 AI Agent 在深层理解和复杂推理方面仍有明显不足。它们往往只能处理相对直接的任务，面对需要长链条推理、创造性思维或深层次理解的问题时就会暴露短板。

比如，Agent 可能很擅长执行”帮我订一张机票”这样的任务，但如果要求”帮我规划一个考虑预算、时间、个人兴趣的完整旅行方案”，效果就会大打折扣。

此外，Agent 缺乏真正的常识推理能力，可能会提出一些违背基本常识的方案。即使是最新的 o1 模型，虽然推理能力有所提升，但距离人类水平的推理能力还有很大差距。

5. 写在最后

AI Agent 的发展才刚刚开始。虽然现在的技术还不完美，但进步的速度是惊人的。两年前，我们还在惊叹 ChatGPT 能够进行对话；现在，AI Agent 已经能够帮我们写代码、分析数据、制定计划了。

对于技术人员来说，现在是最好的时代。我们有机会参与到这场变革中，创造出真正有用的 AI Agent。但同时，我们也要保持清醒：AI Agent 是工具，不是魔法。它能够提高效率，但不能替代人类的创造力和判断力。

未来的世界，可能每个人都会有自己的 AI Agent 团队。就像现在每个人都有智能手机一样自然。

而现在，正是这个未来的开端。

以上。

身边不少同事和朋友都已经用上了，有人说效率翻倍，有人说就是个高级的代码补全。在网上也看到许多争论，如程序员会不会被 AI 取代等等话题。

作为一个在一线写了十多年代码的人，我想聊聊自己的观察和思考。这篇文章不是要唱衰 AI，也不是要贩卖焦虑，而是想分析一下当前 AI 编程的真实情况。

今天主要聊两块：LLM 的固有局限、这些局限在编程领域的具体表现，应对策略我们下一篇文章再聊。

1. LLM 的天生缺陷

要理解 AI 编程的问题，得先搞清楚底层的大语言模型（LLM）有哪些局限。这些局限不是某个产品的 bug，而是当前技术架构的固有特性。

1.1 概率预测的本质

LLM 说到底是个概率模型。它的工作原理是根据上下文，预测下一个最可能出现的词。注意，是「最可能」，不是「最正确」。

这就像一个特别会察言观色的人，能根据前面的对话猜出你想听什么，但他并不真正理解你们在聊什么。大部分时候猜得挺准，偶尔也会离谱到家。

在写作、聊天这种场景下，这种「猜测」问题不大，甚至还能带来一些创意。但在编程这种需要 100% 精确的领域，问题就来了，这就是我们所说的 LLM 的幻觉。

以编程为例，AI 可能会「发明」一个当前环境中并不存在的库函数，或者一本正经地告诉你某个框架有某种你从未听说过的特性。例如，你让它用一个小型库 mini-lib 写个功能，它可能会自信地写下 mini-lib.complex_function()，而这个函数实际上只存在于它通过模式匹配「幻想」出的世界里。这种随机性在创意写作中是火花，但在编程中就是地雷。一个分号、一个等号、一个大于号的随机错误，都可能导致程序编译失败、运行崩溃或产生灾难性的计算错误。

LLM 的本质是一个概率预测引擎，而不是一个事实检索数据库。它的核心任务是基于海量训练数据，「猜」下一个 token 是什么最合理，而不是「下一个 token 是什么最真实」。它的训练数据中包含了海量的代码和文档，当它发现很多库都有 .complex_function() 这种模式时，它就会推断 mini-lib 可能也有，从而生成一个语法通顺但功能无效的代码。它追求的是「看起来对」，而不是「真的对」。

1.2 知识的时间窗口

训练一个大模型需要几个月时间和巨额成本，所以模型的知识总是滞后的。比如 Claude 的知识截止到 2025 年 1 月，那么 2 月份发布的新框架、新 API，它就完全不知道。

对于技术更新速度极快的编程领域，这是个大问题。React 19 出了新特性，Node.js 又发布了新版本，某个常用库爆出了安全漏洞……这些信息，AI 都无法及时获取。

虽然可以通过 RAG/Agent 等技术缓解，但这更像是在给一个旧大脑外挂一个「实时信息提示器」，而非大脑本身的更新。

对于技术迭代比翻书还快的软件开发领域，依赖一个「活在过去」的工具，无异于拿着旧地图在新世界航行。更危险的是，它可能会自信地推荐一个已经停止维护、或者已知存在 CVE 的第三方依赖库，从而出现安全隐患。

1.3 上下文窗口限制

这个问题就像人的短期记忆一样。当我们和 AI 聊天聊久了，它会忘记开头说了什么。目前最好的模型，上下文窗口能达到百万级 token，能解决部分问题，但是也不够用。

对于动辄几十万、上百万行代码的现代开发项目，AI 就像一个只能通过门缝看房间的访客。它能看到门缝里的景象，但对整个房间的布局、风格和功能一无所知。开发者们常常抱怨 AI 编程工具「用着用着就变笨了」，根本原因就在于此。

1.4 缺乏真正的理解

这是最根本的问题。LLM 不理解代码的含义，它只是在模式匹配。

举个例子，当我们让 AI 写一个排序算法，它能写出完美的快排代码。但这不是因为它理解了「分治」的思想，而是因为训练数据里有大量类似的代码，它学会了这个模式。

一旦遇到需要真正理解业务逻辑、需要创新思维的场景，AI 就可能搞不定了。

2. 编程领域的具体挑战

上面这些通用局限，在编程领域会被急剧放大，产生一些特有的问题。

2.1 错误的放大效应

我们知道人是有容错能力的，如这张图，汉字顺序错了，我们也能读懂。

写文章错个字，读者能看懂。但代码里少个分号、多个逗号，程序直接跑不起来。更要命的是逻辑错误，比如边界条件判断错了，可能测试都能通过，上线后才爆雷。

我见过 AI 生成的代码，把 < 写成 <=，导致数组越界。还有在金融计算中使用浮点数，精度问题累积后造成账目对不上。这些都是看起来微小，实际后果严重的错误。

2.2 安全漏洞

这个问题相当严重。研究显示，AI 生成的代码中，包含安全漏洞的比例明显高于人工编写的代码。

原因很简单：

• 训练数据本身就包含大量有漏洞的代码
• AI 不理解什么是「安全」，只知道完成功能
• 很多老旧的、不安全的编码模式被 AI 学习并复现

最常见的问题包括 SQL 注入、XSS、路径遍历等。AI 可能会直接把用户输入拼接到 SQL 语句里，或者在处理文件上传时不做任何验证。除非特别要求。

我们在实际写代码过程中，正向逻辑往往并不是花时间最多的，最复杂的就是边界，异常和特殊情况。

2.3 项目上下文的缺失

真实的项目开发不是写独立的函数，而是在一个复杂的系统中工作。每个项目都有自己的：

• 代码规范和风格
• 架构设计和模式
• 业务领域知识
• 自定义的工具类和框架

AI 看不到这些全貌，经常会：

• 重复造轮子（明明有现成的工具类不用）
• 违背架构原则（在该用依赖注入的地方直接 new 对象）
• 误用内部 API（不理解接口的设计意图）

2.4 代码质量和可维护性

AI 生成的代码往往追求「能跑就行」，但忽略了可读性和可维护性。常见问题包括：

• 过度复杂的嵌套和链式调用
• 缺乏有意义的变量名和注释
• 不符合团队的编码规范
• 没有考虑扩展性和重用性

当我们习惯了 AI 写代码，可能会不想去看代码（自信点，就是不想看），如果这样过度依赖 AI，可能会失去对代码的深度理解。当需要调试或优化时，面对一堆自己没真正理解的代码，问题就会比较大，甚至出了问题还需要现场看代码来定位问题。

小结

写了这么多，核心观点其实很简单 ：AI 编程工具是很强大，但也有明显的局限性。我们需要清醒地认识这些局限，合理地使用工具，同时不断提升自己的核心能力。

代码是我们与机器对话的语言，但写代码的意义，永远是为了解决人的问题。无论工具如何进化，这一点不会变。

所以，继续写代码吧，带着思考去写，带着责任去写。让 AI 成为你的助手，而不是你的拐杖。

毕竟，最好的代码，永远是有灵魂的代码，在写代码中注入心流。

以上。