还记得今年火热的 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 团队。就像现在每个人都有智能手机一样自然。

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

以上。

虽然 GZ 的观点有些尖锐，但其核心表述的：过度依赖这类 AI 工具，可能会导致程序员的独立思考能力和实际编码能力下降。 是有道理的，人都是有惰性的，由简入奢易，由奢入简难。

AI 给编程带来了「捷径」和「舒适区」。有即时的满足感，有认知负载的降低，还有我好像什么都会了的错觉。

• 即时满足感： AI工具能迅速生成代码、解答疑问，这种即时满足感是非常诱人的。就像以前需要自己做饭（从买菜、洗菜、切菜到烹饪），现在可以直接点外卖，省时省力，结果直接呈现。
• 认知负荷降低： 思考是耗能的。AI 工具在很多时候替我们完成了初步的思考和构建工作，大大降低了认知负荷。大脑天然倾向于节能，所以会不自觉地依赖这种轻松模式。
• 我好像什么都会了的错觉： 有了AI的辅助，很多以前觉得困难或耗时的任务变得简单，这容易让人产生一种「能力快速提升」的错觉，从而更愿意待在这个由AI构建的「舒适区」里。

美国心理学家 NoelTichy 提出的理论人类对外部世界的认识可分为三个区域：舒适区，学习区，恐慌区。

参考下面这张图：

图片来源：即梦 AI 生成

我们天生是喜欢舒适区的，有在 AI 的加持下慢慢滑向依赖的自然趋势。

• 习惯的养成： 一旦习惯了 AI 带来的便利，就很难再回到过去那种凡事亲力亲为的「简朴」状态。第一次用 AI 生成复杂函数可能还会仔细研究，第十次可能就直接 Accepted 了。惰性会让我们不自觉地选择最省力的方式。
• 「温水煮青蛙」效应： 思考能力和编码能力的退化，往往不是一蹴而就的，而是像温水煮青蛙一样，在不知不觉中慢慢发生的。每次都依赖一点点，每次都少思考一点点，日积月累，当真正需要独立面对复杂问题时，才发现「内功」已经荒废了。
• 对「不便」的容忍度降低： 习惯了 AI 的「秒回」和「全能」，一旦遇到 AI 无法解决或需要自己深入研究的问题，可能会更容易感到沮丧、不耐烦，甚至选择回避。

当我们真的养成了这种依赖的习惯，适应了这种舒服区，就会面对能力退化后的困境：

• 核心技能的生疏： 长期依赖 AI 完成编码和调试，会导致对编程语言特性、底层原理、算法数据结构、系统设计等核心技能的生疏。就像长期开车的人，突然让他走一段远路，可能会觉得非常吃力。
• 问题解决能力的下降： 独立分析问题、定位问题、解决问题的能力，是在一次次「啃硬骨头」的过程中锻炼出来的。如果这个过程被 AI 替代，那么这种宝贵的实战经验就会缺失。当 AI 「失灵」或给出错误方案时，便会束手无策。
• 创新能力的抑制： 真正的创新往往源于对问题的深刻理解和多角度的尝试。如果满足于AI给出的「标准答案」，就可能失去探索更优解或全新解决方案的动力和能力。
• 学习动力的削弱： 「反正有AI」，这种心态可能会削弱一些人主动学习新知识、钻研深层技术的动力。因为「奢华」的生活方式似乎唾手可得，何必再去「简朴」地刻苦修炼呢？

就像我们家包包公主说的，这算不算「没苦硬吃」呢？

小朋友的视角不一样，也很形象。我们再深入思考一下：

从某种程度上说，如果 AI 已经能完美、高效地解决一些重复性的、模式化的、或者我们已经非常熟悉且没有太多新学习价值的问题，我们还非要「绕过」AI，坚持用原始的、低效的方式去「硬磕」，那确实有点「没苦硬吃」的味道。这就像明明有洗衣机，还非要每一件衣服都手洗，只为了「体验劳动的艰辛」，效率上肯定是不划算的。

但是，这里面有个核心的思考：我们「吃苦」的目的是什么？

比如，AI 能快速生成一个标准的 CRUD 代码框架，我们非要一行一行手动敲，而且这个过程对我们来说已经没有新的知识增量了，那这种「苦」可能就真的是「没必要硬吃」。时间应该花在更有价值的地方。

如果是为了「锻炼核心能力」、「深化理解」、「探索未知」而吃苦：

• 打地基的苦： 对于初学者，或者在学习新技术、新领域时，有些基础的「苦」是必须吃的。比如，亲手搭建环境、理解底层原理、调试简单的错误。这个过程 AI 可以辅助，但不能完全替代，因为这是建立认知框架和培养解决问题直觉的过程。直接跳过，地基不牢。
• 理解「所以然」的苦： AI 给出了一个方案，我们不满足于「知其然」，而是要去深究「所以然」——它为什么这么写？有没有其他方案？优劣何在？这个思考和验证的过程，可能需要查阅资料、动手实验，是「苦」的，但这种「苦」能让我们真正掌握知识，而不是停留在表面。
• 攻坚克难的苦： 面对复杂的、AI 也难以完美解决的、或者需要创新性思维的问题时，我们需要自己去分析、设计、试错。这个过程无疑是「苦」的，但正是这种「苦」孕育了核心竞争力和真正的技术突破。
• 保持「手感」和「警惕性」的苦： 就像运动员需要日常训练来保持状态一样，程序员偶尔也需要「刻意练习」一些基础技能，或者对AI的输出进行严格的审视和重构，以保持对代码的敏感度和对潜在问题的警惕性。这种「苦」是为了防止能力退化。

明明有更优解（AI能完美胜任且无损学习），却固执地选择低效、重复且对能力提升帮助不大的方式。这是一种低效的勤奋，属于没苦硬吃。为了掌握核心技能、深化理解、培养批判性思维、解决复杂问题而进行的有目的的、高价值的努力。这是一种战略性的投入。不是没苦硬吃。

回到「由简入奢易，由奢入简难」和「人的惰性」

正是因为惰性的存在，我们很容易滑向完全依赖 AI 的「奢华」生活，从而不自觉地回避了那些必要的、能提升核心能力的「苦」。这时候，有意识地去「吃一些必要的苦」，就不是「没苦硬吃」，而是对抗惰性、保持清醒、主动投资未来的表现。

举个例子：

• AI能帮我们写单元测试。如果我们只是为了应付覆盖率，让 AI 生成然后看都不看，那可能会错过很多理解代码逻辑和边界情况的机会。
• 但如果我们让 AI 生成初步的测试用例，然后再仔细分析这些用例是否覆盖了所有关键逻辑、边界条件、异常情况，并在此基础上进行补充和优化，甚至思考如何设计更健壮的被测试代码——这个过程虽然也「苦」，但价值巨大。

那如何对抗这种「人性」？

正因为「惰性」和「由简入奢易，由奢入简难」是人性的一部分，所以对抗它需要刻意的练习：

1.保持警惕意识： 时刻提醒自己，AI 是工具，不是替代品。享受便利的同时，要警惕能力滑坡的风险。

2.刻意练习：

• 主动「脱离」 AI ： 对于一些核心模块或自己希望提升的领域，尝试不使用或少使用 AI，强迫自己独立思考和编码。
• 深究 AI 的答案： 不满足于AI给出的结果，而是去理解它为什么这么做，它的原理是什么，有没有更好的方式。把 AI 的输出当成学习材料，而不是最终答案。
• 复盘与总结： 即使使用了 AI，也要对过程和结果进行复盘，总结学到的东西和 AI 的局限性。

3.设定更高的目标： 将 AI 视为达到更高目标的「杠杆」，而不是满足于现有水平的「安乐椅」。比如，利用 AI 节省下来的时间去学习新的架构知识、去钻研更复杂的算法、去思考更有创造性的解决方案。让 AI 帮助我们去追求一种更高层次的、更依赖人类智慧的「奢华」。

4.强化元认知： 思考自己是如何思考的，学习自己是如何学习的。意识到自己可能陷入了惰性思维，并主动调整策略。

5.对「思考能力」和「代码能力」的重新定义

• 思考能力： 可能从「如何从零开始解决问题」更多地转向「如何清晰地描述问题」、「如何将大问题分解给 AI」、「如何评估和整合 AI 提供的方案」、「如何在更高层面进行架构设计和技术决策」。
• 代码能力： 可能从「熟练编写每一行具体代码」更多地转向「快速理解和修改 AI 生成的代码」、「保证代码质量、可维护性和安全性」、「进行有效的Code Review（即使是AI生成的代码）」。

AI 编程工具，确实像一把双刃剑。它带来的「即时满足感」和「认知负荷降低」，很容易就把我们拽进那个诱人的「舒适区」。毕竟，谁不爱走捷径呢？可问题也随之而来，长期依赖这种「外挂」，我们自己的「内功」——独立思考和编码能力，真可能在「温水煮青蛙」般的日常中，不知不觉就打了折扣。

当然，这也不是说我们就得跟 AI 划清界限，放着高效的工具不用，非得事事躬亲，那确实有点「低效勤奋」，甚至真成了「没苦硬吃」。关键在于，我们得想明白，哪些「苦」是值得吃的，是能真正提升我们核心竞争力的「战略性投入」。

• 那些AI能完美胜任、重复性高且对我们知识增量有限的活儿，大胆交给 AI，这叫明智地利用工具，解放生产力。
• 但那些关乎「打地基」、深究「所以然」、需要「攻坚克难」的硬骨头，以及为了保持「手感」和「警惕性」的刻意练习——这些「苦」，恰恰是 AI 时代我们安身立命的本钱。它们能帮助我们构建真正的理解，培养批判性思维，并最终驾驭 AI，而不是被 AI 所定义。

所以，面对AI，我们不能简单地「躺平」享受，也不能盲目地「排斥对抗」。更重要的是，要保持那份警惕意识，用刻意的练习去对抗人性的惰性。

这不仅仅是关于代码怎么写得更快，更是关于我们如何重新定义自己的「思考能力」和「代码能力」，如何在 AI 的浪潮中，通过主动学习和深度思考，完成一次自我进化。说到底，AI 是工具，方向盘始终还是握在我们自己手里，是选择成为更智慧的「驾驶员」，还是满足于当一个「乘客」，这道题，得我们自己用心作答。

★AI 编程真的能做到一天写完一个网站吗？ 这听上去像科幻小说里的情节，但事实证明，借助字节的 Trae，我真的在一天之内完成了一个网站的开发。本篇文章主要分享这次 AI 编程的完整实战经验，包括踩过的坑、用到的技巧，以及如何最大化 AI 的生产力。

整个写代码的过程有点钢铁侠里面的场景，只是没有那么炫，大概是这样：

网站已经上线，有兴趣的同学可以访问： 开发哥 AI 编程工具箱 https://www.kaifage.com/

完工后的界面如下：

纯前端项目，使用了 Vue 框架

AI 编程的核心思路

在这次沉浸式 AI 编程过程中，主要使用了 Trae 作为 AI 编程助手，并结合 Claude 3.5 Sonnet 和 GPT-4o 进行代码生成和优化。整体思路如下：

1. 让 AI 发挥创造力：先给 AI 一个大致的需求，让它自己发挥，生成一个完整的功能雏形。
2. 分步细化需求：每次只修改一个小地方，比如调整颜色、优化布局或添加某个功能，而不是一次性提出复杂需求。
3. 查漏补缺：AI 生成的代码通常会有小问题，需要自己细心检查并修正。
4. 多模态交互：可以用截图标注问题，让 AI 直接针对修改点进行调整，而不是仅靠文字描述。
5. 灵活切换 AI 工具：Claude 3.5 Sonnet 在代码生成上的表现比 GPT-4o 更稳定，但有时候 GPT-4o 也能提供不同的实现思路。

AI 编程的最佳实践

在这次 AI 编程过程中，有以下的一些体验点，能极大提升开发效率：

1. AI 对于前端生成效果比较好

在前端（HTML/CSS/JavaScript）方面，AI 生成的质量较高，尤其是像 React、Vue 这样的框架，AI 处理起来相对流畅。 实际使用体感，传统的前端方案略差一些。

2. 遇到死循环？换个方法！

如果 AI 一直在重复错误，或者陷入死循环，不妨试试：

• 换个 AI 问，让另一个 AI 重新理解问题。
• Google 搜索，找到正确的解决方案后，再喂给 AI，让它基于正确的信息继续优化。
• 直接问 AI：有没有其它办法？你再想想？ 适当「PUA」 AI，往往能让它跳出思维定式。

3. 抽象表达 vs. 精确指令

有时候，AI 对于具体代码的理解会有偏差，但如果用抽象表达，它反而能给出更好的优化方案。例如：
✅ ❌ 直接写代码请求：「请调整 div 的 padding 为 20px。」 这种还不如自己直接调。

✅ ✔️ 抽象表达：「当前的界面布局不合理，请优化为更合理的布局。」

4. 结合多模态能力，提高沟通效率

• 如果界面某个地方不合理，可以 截图+红框标注，让 AI 直接修改。
• 视觉化的反馈比纯文本描述更直观，减少沟通成本。

5. 让 AI 直接修改具体文件

• 如果 AI 生成的代码分散在多个文件里，可以 指定文件路径，让它直接修改，而不是让它自己找文件，有时候会出错，特别是有某些文件相似的时候。

⚠️ 踩坑记录

当然，AI 编程并不总是生成你想要的代码，这次编程过程中也遇到了不少问题：

1. 「正在为当前文件写入变更」 真的太慢！

   • 有时候 AI 生成代码的速度很快，但写入修改的时候却非常慢，甚至会提示「网络故障」。
   • 解决方案：如果长时间没反应，手动复制代码粘贴到文件里，或者让 AI 直接输出完整代码。

2. 代码不准，得自己检查！

   • AI 生成的代码 80% 以上是可用的，但仍然会有小错误，比如少了一个逗号，无法跑通，时序问题等。
   • 解决方案：自己多测试、多 Debug，不要 100% 依赖 AI。

3. AI 生成的代码风格不一致

   • 可能前后使用的变量名不统一，或者代码风格参差不齐。
   • 解决方案：事先定义好代码风格，然后让 AI 统一格式，或者使用代码格式化工具。

4. AI 把原来已经跑通的模块搞坏了

   • AI 在修改代码时，可能覆盖已有代码，导致逻辑混乱，甚至让原本能跑通的功能失效。
   • 解决方案：使用 Git 进行版本管理，当一个功能调通后，先提交，建立一个可用的基线。同时如果过程中发现不可用了，可以取消本次编辑结果。

以下为本次写代码过程中的一些记录和截图。

比如做密码生成功能的时候

比如做二维码功能的时候

会把其它功能弄坏掉，需要修复

移动端的适配

实际上他只改了布局，具体的页面内容还是不行

单独对这个页面增加响应式布局。

同样，对于其它页面也一个一个任务的要求 AI 修改。 如：

过去，技术硬实力是研发同学的核心武器，但今天，AI 工具正在以惊人的速度让这些技能「平民化」：

• 代码量产：AI 几秒钟生成数百行代码；
• 自动调优：AI 自主优化算法参数，超越人类水平；
• 全栈覆盖：从前端到后端，从 DevOps 到数据分析，AI 工具无处不在。

然而，AI 的快速普及并不是威胁，而是机会。未来最优秀的研发，不再只是写代码的人，而是能够驾驭 AI，解决复杂问题、创造价值的人。而这一切的基础，就在于软技能的升级。

1. AI 时代的「新研发」画像：从执行到创造的转型

AI 时代对研发同学的要求正在发生质的变化。你需要的不仅是工具使用能力，更是掌握以下三大能力的思维跃迁：

1.1 问题定义力：从「如何做」到「做什么」

AI 工具可以为你提供实现方案，但它无法回答「我们到底要解决什么问题」。能精准定义问题的人，才能引领 AI 高效运转。

• 举例：用户反馈「系统太慢」，真正的瓶颈可能并不是代码性能，而是业务逻辑过于复杂，或者数据库架构不合理。
• 关键问题：AI 可以帮你解决「已知问题」，但只有你能找到「未知问题」。

建议实践：

• 在接到需求时，不急于动手写代码，而是花 30% 的时间明确核心目标。
• 使用「5 WHY」拆解问题，找到真正的根因。

以某电商大促系统卡顿的问题为例：

当用户反馈「下单页面卡顿」时，我们需要问：

第一层追问：卡顿发生在点击下单按钮时？还是页面加载时？（发生在哪里？）

第二层追问：只有大促期间出现？普通时段正常？（发生在什么时候？）

第三层拆解：日志显示数据库查询耗时暴增，但真的是 SQL 问题吗？（多问一次）

最终发现根本原因是优惠券叠加计算逻辑：当用户同时使用店铺券、平台券、满减券时，业务逻辑循环嵌套导致指数级复杂度上升。

• 用「5 WHY」法拆解问题：
  比如面对「系统太慢」的反馈，可以问：
  1. 为什么太慢？ -> 数据查询耗时过长。
  2. 为什么查询耗时过长？ -> 数据库没有索引。
  3. 为什么没有索引？ -> 设计时没有考虑这个场景。
     通过层层追问，找到问题的根因，而不是停留在表面。

多站在用户视角思考：系统性能对用户真正的影响是什么？是加载时间？响应速度？还是页面卡顿？明确目标后再行动。

1.2 跨领域协作力：从「技术孤岛」到「多维桥梁」

研发同学往往被视为技术专家，但在 AI 时代，研发工作正在从「单一技术领域」走向「跨领域协作」,能够在技术与业务、技术与设计之间建立桥梁的人更具影响力。

AI 工具的普及，让技术不再是只有工程师能看懂的「黑箱」，它正在成为每个部门都能触及的工具。这意味着，研发者的作用不再是单纯的技术专家，而是跨部门桥梁。

• 场景 1：向业务团队解释 AI 模型的局限性，例如：大模型生成的预测结果为何在特定场景无法应用。
• 场景 2：与设计师协作，优化用户体验，而不是单纯关注技术实现。

建议实践：

• 多关注非技术领域的语言和逻辑，例如：用「用户故事」代替技术术语。
• 在技术方案中，明确描述其对业务的价值和风险。

举个例子：从「技术术语」到「用户故事」假设业务部门提出一个需求：「我们需要一个 AI 模型来预测用户流失率。」

• 如果你直接给出技术方案，比如「我们用随机森林算法和 LSTM 模型」，业务团队可能一头雾水，也无法判断你的方案是否符合实际需求。
• 更好的方式是转化为业务语言，比如：「我们会用 AI 模型预测哪些用户可能流失，这样可以提醒销售团队提前联系，并减少用户流失。」

这种「跨领域翻译能力」不仅能让技术方案更落地，还能让你在团队中更具影响力。

那么，如何提升跨领域协作力？

• 学习对方的语言和逻辑：比如了解产品经理常用的「用户故事」格式，用场景化的方式描述技术方案。
  • 比如：用户故事可以是「作为一名用户，我希望系统能在 2 秒内加载完成，这样我就不会失去耐心」。
• 明确技术对业务的价值：在提交技术方案时，补充说明「这个功能可以提升 xx% 的用户体验，节约 xx% 的成本」。

在 AI 时代，研发者不仅是技术的推动者，更是沟通技术与业务、技术与设计的桥梁。谁能打通这些边界，谁就掌握了更多主动权。

1.3 批判性思维：从「接受答案」到「验证答案」

AI 工具给出的代码、方案并非总是可靠。研发者必须具备质疑与验证的能力，避免高效地犯错。

• AI 提供的代码是否安全？ Cursor 生成的代码可能存在漏洞。
• AI 生成的方案是否符合需求场景？ 自动化工具可能忽略了业务逻辑中的特殊条件。

建议实践：

• 为你的 AI 工作流创建「质检清单」，例如：性能测试、安全检查、业务逻辑验证等。
• 从 AI 输出中学习，而不是无脑接受，学习其思路和编码的方式等等。

如何培养批判性思维？

• 为 AI 创建「质检清单」：
  每次接受 AI 的输出前，进行以下检查：

  1. 技术层面：代码是否经过边界测试？是否存在安全隐患？
  2. 业务层面：输出结果是否符合实际场景？是否考虑了用户行为习惯？
  3. 合规层面：生成内容是否符合公司政策或行业法规？

• 从失败案例中学习：多分析 AI 工具失败的案例，理解 AI 的局限性和潜在风险。比如，研究某些场景下的 AI 偏见问题，避免类似错误。

2. AI 时代的软技能到底有多重要？

如果技术硬实力是「上限」，软技能就是「下限」。AI 可以让所有人起点更高，但也会放大研发者的短板：

• 不会定义问题的人，会被工具束缚在错误的方向上。
• 缺乏沟通能力的人，会在跨部门协作中失去对话权。
• 思维固化的人，无法适应 AI 工具带来的工作流变化。

2.1 生存指南

1. 用「 CTO 思维」拆需求，接到任务时先问三连：

   1. 这个需求背后的商业目标是什么？（比如提升转化率？降低客诉？）
   2. 如果只能用一句话描述成功标准，应该是什么？
   3. 现有数据中哪些指标暗示了真正的问题？（如支付环节跳出率>80%）

2. 给 AI 加「导航仪」，向 AI 提问时避免开放式指令，而是结构化引导：

   • 错误示范：”优化系统性能”
   • 正确姿势：”当前订单提交平均耗时 2.3 秒（ APM 数据），在保证 100% 数据一致性的前提下，请提供三种不同成本预算的优化方案”

2.2 话术 – 「见人说人话，见鬼说鬼话」

• 对老板：「投入 1 个月开发时间，能防止明年 618 大促期间服务器崩溃的风险」，关注成本和产出
• 对运营：「这个接口延迟降低1秒，首页UV转化率能提升0.7%（附 A/B 测试数据）」，关注指标
• 对客服：「新系统上线后，用户咨询’物流进度’的话术可以减少 3 次点击步骤」，关注对于其工作的影响

2.3 软技能的红利公式

AI 时代个人价值 = （技术硬实力 × 软技能系数）^ AI 工具适配度  

系数破局点：

• 会用AI写代码 → 硬实力基准线（人人可达）
• 能判断该让 AI 写什么代码 → 软技能决胜区（稀缺资源）

那些软技能出色的研发同学，能够借助 AI 实现飞跃式成长，成为团队中的关键角色。

3. 打造你的「AI 时代工具箱」

软技能的提升不是一朝一夕的事，但可以通过系统化的方法论，逐步打造适应 AI 时代的「工具箱」。

3.1 练习「问题之上」的思维：从执行者到问题定义者

AI 工具可以帮助你高效地执行任务，但它无法告诉你「最重要的问题是什么」。在 AI 时代（也不仅仅是 AI 时代），研发需要从全局视角思考问题的本质：为什么做，而不仅仅是怎么做。

3.1.1 如何练习「问题之上」的思维？

每天主动问自己三个「为什么」，从执行层面上升到战略层面：

1. 为什么这个功能重要？：真实案例：某研发团队接到任务，优化一个页面加载速度。当他们问「为什么优化加载速度重要？」时，发现问题的本质并不在于技术性能，而是用户期望在关键时刻快速获取信息。最终，他们通过简化页面结构和聚焦核心功能，比单纯优化代码更高效地解决了问题。

2. 为什么用户需要这个解决方案？：从用户视角出发，挖掘需求背后的真实动机。例如，一款 AI 推荐系统的研发团队意识到，用户并不需要复杂的算法结果，而是想快速找到符合场景的解决方案。于是，他们优化了推荐理由的呈现方式，让用户更容易理解和采纳推荐结果。

3. 如果资源有限，如何找到最优解？：设想一个极限场景：如果只能用 50% 的时间或资源完成任务，你会如何取舍？这种思考方式能帮助你聚焦核心问题，避免陷入无意义的细节优化中。

3.1.2 成为「破界思考者」的 4 层跃迁法

人类擅长于发现隐藏在表象下的真问题。4 层跃迁法帮助突破思维惯性：

▌认知框架

• 第1层：需求表象：「业务方要求 3 天上线一个推荐算法」
• 第2层：利益相关者分析：使用 RACI 矩阵梳理：谁决策/执行/被影响
• 第3层：系统动力学推演：用因果回路图分析技术方案对用户体验/后端负载/商业指标的连锁影响
• 第4层：第一性原理拆解：追问：用户点击转化率低的根本原因是算法不准？还是商品信息呈现方式问题？

▌实战工具包

• 丰田「5Why分析法」进阶版：

  现象：用户投诉支付失败率上升  
  Why 1 ▶ 接口超时？  
  Why 2 ▶ 第三方支付网关响应慢？  
  Why 3 ▶ 未适配银行新加密协议？  
  Why 4 ▶ 运维监控策略未覆盖合作方变更？  
  Why 5 ▶ 跨部门信息同步机制缺失？  
  

• MIT系统思考工具箱：

记住：AI 再强大，也需要你来定义问题。跳脱「怎么做」的思维框架，才能成为团队中的问题定义者。

3.2 刻意提升「非技术表达」：让技术为业务赋能

技术再高深，如果让人听不懂，价值就会大打折扣。AI 时代的研发者不仅需要写得出代码，更需要讲得清技术。能用简单、直观的方式表达技术方案，既能提高跨部门协作效率，又能让你的工作成果更具说服力。

3.2.1 如何刻意练习「非技术表达」？

1. 用一张图解释技术架构：将复杂的技术架构简化成流程图、思维导图或者用户体验图。例如，一个后端服务的高可用方案，可以用一张图展示数据流动、容错机制以及业务价值，而不是写一长段技术描述。

2. 用「用户视角」描述技术方案的价值：比如，你正在开发一个自动化测试工具，与其说「这个工具可以减少测试时间」，不如说「这个工具可以帮助团队提前发现潜在的产品缺陷，从而减少 30% 的用户投诉」。这样的表达更容易被非技术团队接受。

3. 用故事化的方式呈现你的方案：例如，在解释一个推荐算法时，可以说：「想象一下用户点开首页，看到的是他最喜欢的内容，这背后是我们的 AI 模型在实时分析用户行为。」这种讲故事的方式更具感染力。

3.2.2 实践工具

• ▌FAB 法则（Feature-Advantage-Benefit）
  表达技术方案时，从功能（Feature）入手，解释优势（Advantage），最后明确带来的好处（Benefit）。

  • 功能：我们的推荐算法会实时预测用户偏好。
  • 优势：它能够在用户访问的第一时间推荐最相关的内容。
  • 好处：提升用户粘性和点击率，从而增加转化率。
• 例如：

• ▌SCQA模型（情境-冲突-问题-答案）

  [情境] 当前订单查询 API 响应时间突破 2s  
  [冲突] 用户体验下滑 vs 硬件扩容成本激增  
  [问题] 如何在零成本下优化性能？  
  [答案] 通过 AI 预测缓存热点数据（命中率提升至 92% ）  
  

• 金字塔原理实战：技术方案文档采用「结论先行+ MECE 分类」结构

记住：技术的价值必须通过清晰的表达被团队和业务部门感知，才能真正落地并创造商业价值。

3. 搭建「AI 质检工作流」：让 AI 为你所用，而不是盲目信任

AI 工具再强大，也只是工具，其输出的内容仍然可能存在问题。研发者需要对 AI 的输出保持质疑态度，并建立一套完善的质检流程，确保工具真正符合需求。

▌四阶验证框架

当AI工具成为标配，建立质量管控机制比盲目追求效率更重要。

4. 用 AI 「解未来」

• 精准定义问题，让 AI 为你服务，而不是反过来被工具左右。
• 跨领域协作，用技术思维解决业务问题，成为团队的桥梁。
• 对 AI 保持质疑，避免高效犯错，用批判性思维守住技术底线。

AI 不会淘汰研发，只会淘汰不会用 AI 的研发。当机器开始思考时，人类的智慧应该闪耀在机器停止思考的地方。

此刻的你，不妨用 0.1 秒思考：是继续做工具的操控者，还是成为驾驭 AI 的「指挥官」？这场进化游戏没有旁观席，每个技术人都已身在局中。

未来的研发工作，不再是机械地写代码，而是以技术为工具，解决问题、创造价值、推动变革。

从今天开始，思考：

• 我的工作是否创造了价值？
• 我的技能是否放大了 AI 的潜能？
• 我的软技能是否已跟上时代的节奏？

AI 已来，你准备好了吗？ 

「你认为 AI 时代最重要的软技能是什么？欢迎评论留言讨论！」

以上。

对标 Cursor，Windsurf 的国内出海的一个 IDE，当前可使用 Claude-3.5-Sonnet 和 GPT-4o 大语言模型

深入使用，花了三个小时，不写一行代码，实现了一个前端后端分离架构，包含登录/退出，数据库查询，跨域，以及首页功能的小管理后台，包括前端和后端的代码。前端所使用技术栈为 Vue，后端使用了 golang + beego。

这 3 个小时有一个耗时点是想让 AI 来解决跨域的问题，我们知道跨域主要是 Access-Control-Allow-Origin 等头信息的处理，把前后端的代码上下文都给了，反复试 OPTIONS 请求跨域总是不成功，后来发现是后台接口实现所修改的跨域文件没有加载导致的。

除了通用功能，实际业务开发中，花了 30 分钟实现了 Java 的流式输出，其场景是要实现 DeepSeek 的模型调用，以实现打字机的输出效果。

这里 AI 给的 golang 的实现，但是当前我需要的是 Java 的，这里的问题是没有把需求讲清楚。同时也表示在开始对话时，需要把一些背景信息讲清楚能提高整体的效率。

经过了大概 10 轮对话，他大概就了解我真正想要的是什么了，再经过 6 轮对话补全，把过程中有问题的地方和相关代码圈出来给到 AI，很快就有结果，并解决了问题。

1. 使用过程中的感受

1. 表述清楚需求很重要，在最开始的时候一些背景重要的背景信息可以提前给出，如技术栈，表结构、想做的事情等等；
2. 给到更多的上下文，更容易得到正确的答案，在 Trea 中使用 # 号引入，当前支持代码、文件、目录及工作区间；
3. 从 AI 中来，到 AI 中去，可以跳出 AI 来解决问题，当 AI 限入解决问题的死循环，可以找 google 要一些答案喂给 AI，后续应该会自动支持这个功能；
4. 出错的地方，选中后，直接让 AI 解决，甚至不需要多说一句话，当然，你也可以多说几句，更清晰的表述你想要的东西；
5. 多模态的能力，在界面有问题的地方，截图说明给到 AI 就能解决；
6. 先做框架，再逐个功能实现，当前阶段，AI 解决小范围的问题会更合适一些。

到这里，对于这种通用类的功能，AI 已经能发挥出很大的能力了，再进化一段时间，程序员的大部分编码工作真的就会被 AI 取代了。那是不是我们就失业了呢？从纯粹写代码的角度来说，是的，但是从整个项目的角度不一定。

2. 程序员的当前职责

和康总有聊到这块，当前我们程序员基本在解决的问题包括决策、连接和编码三部分。

• 决策：技术选型、架构设计等高层次决策，AI 尚无法完全替代。
• 连接：跨部门需求分析、团队沟通与资源协调。
• 编码：过去程序员的核心工作，但 AI 的介入正在加速其主要功能的边缘化。

2.1 决策

项目开发的过程实际上是一个个的决策过程组成的，决策是咱们的核心职责之一，是一个项目从业务需求到技术实现的过程中，如何选择解决方案的过程。

我们需要在不确定性和多种选择中，基于经验、知识和实际需求，做出技术上的关键决定。这些决策往往会对团队的效率、产品的质量和未来的技术发展方向产生深远影响。

决策指的它涉及从业务层面到技术层面的全局性规划，包括但不限于：

• 需求分析：
  • 理解并提炼业务需求，制定核心目标和功能优先级。
  • 与产品经理、业务方的沟通，明确业务目标和用户需求。
• 技术选型：
  • 决定使用何种技术栈（前端框架、后端框架、数据库、云服务等）。
  • 评估不同技术的可行性、扩展性和成本。
• 架构设计：
  • 系统架构的顶层设计，比如单体架构 vs 微服务架构。
  • 数据库选择（SQL vs NoSQL）、缓存策略、性能优化方案。
• 风险评估与管理：
  • 评估技术方案的风险（如性能瓶颈、技术债务、团队技术栈能力）。
  • 制定备选方案和应急措施。

AI 替代能力：

• 当前能力：
  • AI 已能提供强大的技术选型建议（如根据场景推荐框架、库、工具）。
  • 在简单的架构设计中，AI 已能生成初步方案（如微服务与单体架构优劣分析）。
• 未来潜力：
  • AI 可能在复杂的技术决策中辅助更精准的数据分析和方案评估。
  • 但最终决策依赖对业务需求的深刻理解，这仍需要人类的经验和判断。

程序员核心竞争力：

• 理解业务需求和行业背景，能够将技术与业务深度结合。
• 解决复杂的非结构化问题，比如协调跨团队需求冲突，平衡业务优先级。
• 创新能力：AI 只能在已有知识中提供建议，真正的创新需要人类。

2.2 连接

连接是将技术方案具体化并协调各方资源，使其从理论走向实践的过程。重点包括：

• 需求转化：
  • 将业务需求拆解为可执行的技术任务。
  • 明确模块划分、接口定义以及交互方式。
• 团队协作：
  • 前后端、测试、运维、产品经理之间的沟通与协作。
  • 协调跨部门资源，解决技术与运营、市场等职能间的矛盾。
• 接口与模块设计：
  • 定义 API 接口规范（RESTful、GraphQL）。
  • 确保接口的安全性、性能和兼容性。
• 测试与迭代：
  • 制定测试方案，组织单元测试、集成测试。
  • 根据测试反馈快速调整，推动迭代优化。

AI 替代能力：

• 当前能力：
  • AI 已能快速生成接口文档、代码示例、测试用例。
  • 在协作方面，AI 可以辅助生成任务拆解、需求文档、项目计划等。
• 未来潜力：
  • AI 可以成为跨部门的沟通桥梁，如生成更加精确的技术-业务对接文档。
  • 但复杂、动态的沟通和协调仍是 AI 难以替代的领域。

程序员核心竞争力：

• 优秀的沟通能力和团队协作能力，能在矛盾或模糊的需求中推动项目前进。
• 对复杂系统的整体把控力，确保各模块之间的高效协作。
• 快速适应变化的能力，能够在项目中临时调整资源和策略。

2.3 编码

编码是程序员的核心工作之一，涉及将设计方案转化为实际运行代码的过程。它包括：

• 代码实现：
  • 基于需求和设计文档，开发具体功能模块。
  • 包括前端开发（UI、交互逻辑）和后端开发（业务逻辑、数据库操作）。
• 调试与优化：
  • 修复 BUG，优化代码性能。
  • 解决复杂的技术难点（如跨域问题、性能瓶颈、并发冲突）。
• 代码质量保障：
  • 编写单元测试、集成测试，确保代码质量。
  • 遵循代码规范，进行代码审查。
• 持续集成与发布：
  • 使用 CI/CD 工具进行自动化构建和部署。
  • 实现代码版本管理和持续优化。

AI 替代能力：

• 当前能力：
  • AI 已能生成高质量的代码片段、调试建议，甚至完整的模块代码。
  • 对于常见的编码任务（如脚本处理类，CRUD 功能），AI 的效率和准确性已超过人类。
• 未来潜力：
  • AI 将进一步替代大部分重复性、模板化的编码工作。
  • 但对于复杂场景下的创新性编码，AI 的能力仍有限。

程序员核心竞争力：

• 对技术深度的理解，能够在 AI 提供的代码基础上进行优化和扩展。
• 解决复杂问题的能力，比如在非标准化场景下实现创新功能。
• 对代码质量的把控能力，确保生成代码的安全性、性能和可维护性。

3. AI 替代的趋势与程序员未来的价值

3.1 当前 AI 会逐步替代哪些部分？

1. 重复性、模板化的工作：
   • 例如脚本类、通用类、CRUD 重复类的功能。
   • 常见的 BUG 修复、代码优化建议。
2. 常规化的架构设计和技术选型：
   • AI 将能处理大部分标准化场景下的技术决策。
   • 在数据驱动的决策场景中，AI 的效率更高。
3. 文档、接口、测试的自动化：
   • 自动生成 API 文档、测试用例，将成为默认功能。

3.2 程序员的核心竞争力是什么？

1. 业务理解与技术结合能力：
   • AI 不理解业务逻辑背后的真实需求，程序员能够通过与产品、业务沟通，设计出更贴合实际的解决方案。
2. 复杂场景的解决能力：
   • 比如跨团队协作、大规模分布式系统设计、非标准化需求的实现。
3. 创新与创意能力：
   • AI 是基于已有数据训练的，无法真正创新。程序员在新领域和新需求中的创意能力不可替代。
4. 人际沟通与团队协作能力：
   • 项目中的决策、问题协调、资源整合都需要人类来推动。

3.3 程序员未来应该做什么？

1. 提升抽象能力和建模能力：
   • 从写代码转向设计方案，专注于高层次的架构和技术规划。
2. 拥抱 AI 工具：
   • 熟练使用 AI 编程工具（如 Trea、Cursor）提升效率，将 AI 当作“助手”。
3. 深耕行业知识：
   • 了解特定行业的业务逻辑，成为领域专家。
4. 培养软技能：
   • 强化沟通能力、团队协作能力和项目管理能力。

画了一个思维导图，大概是这样：