2025 AI Coding实践总结 - AI Coding工具真的好用吗？

2025年已经开启一个AI coding工具从”可选”变成”必需”的时代，无论你是否具备编程经验，这都是你值得去尝试AI利器

蓑雨春归

348人浏览 · 2025-12-31 22:40:38

蓑雨春归 · 2025-12-31 22:40:38 发布

2025年是AI飞速发展的一年，从年初的DeepSeek R1到年末ChatGpt-5.2，模型在复杂推理，agentic能力上持续跃升。依托大模型能力的提升，Agent在更多场景开始逐步实现工程化落地，2025年也称得上Agent元年(Manus在昨天被meta收购也是一个agent元年注脚)。这一年agent在coding，科研，办公等场景都有不同程度的应用落地，但影响最广，最为深远的当属coding领域，AI coding不但改变了程序员的工作方式，也改变了构建应用的方式。每一项技能都有其独特价值，但门槛不应该成为实现某个创意想法的障碍。在2025年末，将笔者年内使用AI coding工具的体验和经验整理成文，分享如下。

2025年的AI Coding

今年2月份Andrej Karpathy提出了“Vibe coding”的概念，字面意思为”氛围编程”，简单理解就是使用自然语言来进行编程，这个概念在整个2025年持续成为了AI社区讨论和关注的焦点。我大概也是从2月份这个时间点开始使用AI coding工具的。

最开始使用的是cursor，在使用cursor之前用的比较多的是vscode github copilot的代码补全，或者把问题粘贴给claude给出具体解决方案再粘贴回ide。而cursor不但能够直接创建文件，还能基于对code base的理解来做全局性的修改和功能实现。开始使用cursor的初体验还是觉得比较惊艳的，盯着屏幕上AI一边思考一边创建文件写代码，第一次感受到”AI帮你写代码”，有了程序员数字分身的感觉，然后cursor也深度使用了几个月，也体验了某天一个上午就用了40美金的震撼感(超出订阅外付费)！

随后社区不断看到对claude code的安利，在6月份开始尝试了claude code，一开始对命令行式的编程不太习惯，但随着越来越多的使用，发现依托anthropic自家的claude sonne/opus 4模型，claude code在解决一些复杂问题的能力上明显超过了cursor，但是3天也就把一个星期的limit用超了，遂开了max，随之也就把cursor退订了。

而我目前用得最多的是codex，codex在4月份就推出了codex cli开源版本，5月份发布云端codex，当时的重点还是云端基于github仓库的任务，模型的coding能力也明显弱于claude。然后8月份发布了gpt-5，随之9月份发布gpt-5-codex,基于gpt-5特定训练的coding模型，这个时候的codex用下来就体验不错了，而且codex团队版本更新节奏很快，持续优化codex的使用体验，在9月底的时候我的主力coding工具就从claude code迁移到了codex。

上面就是我这一年使用AI coding工具的迭代过程，可以看到这个领域的技术变化非常快，所以我也在不断的切换工具。但是这就引出一个问题，这些工具都需要付费，Cursor Pro每月20美元，Claude Max每月100/200美元,OpenAI pro每月200美金。国内AI coding工具，尤其是使用国内模型的话，订阅价格会更便宜，这个可以按需选择。

这引出了一个值得认真回答的问题：AI coding工具真的好用到让大家愿意付费订阅的程度了吗？

那些被反复提及的问题——幻觉、上下文遗漏、代码风格不匹配、引入第三方漏洞—真的在变好吗？

我的回答是：在一定条件下是好用的，但也是不得不用的，因为这对程序员和想通过软件构建产品的用户群体来说，这确实是”划时代”的工具。

下面就结合自己这一年使用AI coding工具的体验和实践来展开谈一下。

为什么说是”划时代”的工具

在讨论问题之前，先承认一个事实：AI coding工具带来的效率提升是实实在在的。

对于样板代码，以前需要30分钟手写的后端模型调用接口，现在描述一下需求，几十秒就能生成一个可用的版本。即使需要修改，也比从零开始快得多。

对于陌生代码库，以前接手一个新项目，可能需要几天时间才能搞清楚代码结构。现在可以直接问AI：”这个项目的认证流程是怎么实现的？”它能快速给你一个概览，指出项目技术架构和核心技术模块。

对于技术调研，以前需要翻文档、看Stack Overflow、读源码。现在很多问题可以直接问AI，它能综合多个信息源给你一个针对性的回答。

对于重构工作，”这个模块的实现偏离了既定目标，需要从工作流切换到agent迭代实现”、”把这些重复代码抽成工具函数”，这类复杂但耗时的工作，AI可以快速完成初版或阶段性版本。不要指望一次重构完成，不然会隐藏很多坑，后面会细讲。但掌握合理的方法，效率比自己重构仍然高出N倍。

这些效率提升是实打实每天都在发生的。这也是为什么即使存在各种问题，很多人仍然愿意付费使用这些工具，节省的时间是真实的，解放的精力也是真实的。

但效率提升不意味着没有问题。接下来我们逐个分析那些被反复提及的痛点。

幻觉问题—存在但在改善

什么是代码场景下的幻觉

幻觉在代码场景的表现和在问答场景不太一样。它不是编造一个不存在的历史事件，而是在函数匹配，api使用实时性和技术阐释上存在误引用和过时问题，这个通常在超长上下文时容易触发。

编造函数：生成一个看起来合理但实际不存在的方法，比如response.json().await在某些框架中根本没有
混淆版本：把不同版本的API混在一起用，例如langraph的使用的是前几版的api，导致适配报错
虚构配置：为agent的记忆存写策略编造一个”应该存在”但实际不存在的配置项
错误解释：自信满满地解释一段代码的工作原理，但解释的逻辑与代码实现存在偏差(忽略了部分实现)

正在改善的方面

首先必须承认，基础模型的能力是AI coding工具的地基。模型不行，工程化做得再好也没用。

但顶尖模型的幻觉确实在持续减少，所以在进行复杂关键模块编码时，尽量选择幻觉率低的模型(比如gpt-5.2的幻觉就低于gemini 3 pro，虽然gemini 3 pro的世界知识能力更强)。而这些幻觉问题的改善主要体现在这几个方面：

模型学会了说”不确定”。模型在遇到不熟悉的API也没有进行联网时，会有概率输出表示”我不确定这个方法的确切用法，建议查阅官方文档”，而不是编造一个看起来合理的答案。这是一个重要的进步—承认不知道比胡说八道好得多，这个属于know unknow问题，虽然现阶段over-confidence的概率还是比较大。

上下文层面的retrival补充。codex和claude code在对项目进行全局分析时，大量使用了grep和rg(ripgrep,rust版rg)命令来检索文件并进行读取利用，而这使用背后不仅仅是检索功能的准确调用，同时也是上下文工程的持续优化 - 如何把检索到的相关全局代码信息放到当前上下文，实现模型的有效理解和代码生成。

可执行环境的集成。这也是比较有效的改善。Claude Code、codex，Cursor Agent都可以执行代码、看到报错、然后执行自我修正。代码有一个自然语言没有的特性：客观可验证性。能跑就是能跑，不能跑就是不能跑。当AI可以获取这个反馈信号时，最终输出的质量就有了基本兜底(虽然一些问题通过单元测试不代表整体功能就没问题)。测试驱动开发也是一种不错的实践方式，每开发完一个模块，可以让AI coding工具写单元测试脚本并进行测试验证。

仍需注意的场景

但幻觉问题仍然存在影响，在以下场景仍需注意:

新发布的框架或库：训练数据还没覆盖，模型可能基于旧版本的知识”推测”新版本的用法
小众技术栈：训练数据中样本少，模型的”知识”本身就不太可靠
底层实现细节：模型对”怎么用”通常比”为什么这样”更可靠
在一个上下文持续执行多个任务：在一个上下文执行多个任务，随着上下文堆积，模型容易失焦

保持上下文比较聚焦，不要堆积太长上下文，及时总结当前内容作为上下文，开一个新窗口把这个问题迁移到新窗口解决，从实践上看是比较有效的缓解幻觉的方式。

对于AI生成的代码，现阶段我们需要保持审慎的态度，不能假设它的实现思路一定对。尤其是涉及到你不熟悉的API或模块实现，需要花时间查一下官方文档和最佳实践确认，这个习惯能避免很多坑。一般可以使用AI coding 调用搜索工具进行搜索，codex对搜索的支持还不太行，处于安全考虑默认不进行网络搜索，claude code和cursor支持比较好。所以一般对于需要搜索相关技术方案和参考实践时，我会用claude code进行调研生成结果，再让codex读取这个搜索结果进行分析。

上下文遗漏——最棘手的问题

“上下文腐烂”是什么

这是目前AI coding工具最棘手的问题，也是比较容易让人抓狂的问题。

你和AI进行了一个长对话，讨论了项目架构，定义了代码规范，修改了十几个文件。然后你让它继续改一个相关的文件，它突然”忘了”之前讨论过的规范，生成了一段风格完全不一致的代码。

这种现象也被称为“上下文腐烂”（Context Rot）。

为什么会发生

原因一：模型的固有特性——Lost in the Middle

即使模型声称支持100k、200k甚至1M token的上下文窗口，即使”大海捞针”测试能达到99%，它对上下文的关注并不均匀。模型天然对开头和结尾的内容关注度更高，对中间部分的关注度较低。

这意味着：如果你在对话中间讨论了一个重要技术细节，到对话后期，模型对这个技术细节的”记忆”可能已经模糊了。

原因二：训练分布的偏移

模型在训练时很少见到那种”30轮以上、涉及20个文件、包含大量代码修改”的复杂对话。你的真实使用场景超出了它的训练分布。当对话复杂度超过训练时见过的样本时，模型的表现就开始不可预测。但这个问题随着更多复杂真实场景数据的积累，下一版模型引入这些复杂训练数据就会得到改善。

原因三：累积误差

每一轮交互都可能引入轻微的理解偏差。单独看每个偏差可能可以忽略，但经过几十轮累积，偏差被放大，最终导致模型对项目的理解和你的实际意图严重脱节。

上下文工程：当前的应对方案

各家模型厂商和AI coding工具都在尝试解决这个问题，方案可以归类为三种思路：

思路一：压缩

对上下文进行删减和压缩，只保留关键信息。Cursor的Compact功能、Claude Code的自动压缩都是这个思路。

好处是可以延长有效对话长度，坏处是每次压缩都可能丢失细节。多次压缩后，性能下降会比较明显。Codex一开始需要手动compact，现在可以自动compact了，但用户反馈是”多次compact之后，它对项目的理解明显变差了”。

思路二：卸载

把大段内容放到文件里，上下文中只保留文件引用。当AI需要某个文件的内容时，再动态加载。

这实际上是把上下文窗口当作”工作内存”而不是”长期存储”。就像人类程序员不会把整个代码库背下来，而是在需要时查阅特定文件。

思路三：隔离

通过Sub-agent实现上下文隔离。主agent负责高层规划和协调，子agent各自执行具体的子任务，每个子agent有自己独立的、较小的上下文。

这类似于人类团队的分工：架构师掌握全局，各个开发者专注于自己负责的模块。子agent之间不需要共享所有上下文，只需要共享接口约定。

实用建议

这些方案在思路上看上去没有什么特别之处，但是关键是工程化实践，不同的AI coding工具可能使用了类似的上下文工程方案，但体验上仍然会存在差异，例如在cursor中使用gpt-5.2模型，与在codex中使用gpt-5.2模型，在处理同一个任务时，因为上下文压缩策略，以及环境内置工具的差异，会在某些节点上给出不一样的方案。

而作为使用者，我们可以做一些事情来缓解这个问题：

勤开新对话。不要在一个对话里做太多不相关的事情。当你感觉AI开始”忘记”之前讨论过的内容，或者它的回答开始偏离主题，这是开新对话的信号。一个经验法则：一个对话专注于一个相对独立的任务。

用规则文件固化约定。把项目的技术栈、代码规范、架构约定写在agents.md、CLAUDE.md或.cursorrules里。这些内容会在每个对话开始时自动加载，不会随着对话变长而”腐烂”。

分阶段处理大任务。如果一个任务涉及大量文件和复杂逻辑，不要试图在一个对话里全部完成。分成几个阶段，每个阶段用一个新对话，阶段之间通过文档或git 信息来传递上下文。

代码与框架不匹配—通常是对齐问题

问题的两面

AI生成的代码”不符合项目规范”是一个常见的问题，但这个问题需要拆成两个角度来看：

角度一：你给了充分的上下文，AI还是实现偏了

这确实是模型的问题。但根据我的经验，这种情况的概率其实不大。比如你要实现一个pdf翻译的功能，如果构造的上下文明确包含了ocr api，翻译 llm api对应的接口参考，那直接通过一次性构建的可用率还是很高的，但问题也在于判断何种程度的上下文为“成分的上下文”，这个一般需要对经过一段时间的AI coding工具深度使用，就会对其的知识能力边界和上下文操作能力有更清晰的认知，在每次实现需求时给到充分且必要的上下文，可以有效增加AI实现功能的准确率。

角度二：上下文不充分，人与AI未对齐

这是更常见的情况。你说”写一个认证模块”，上下文没有明确要求技术栈是什么、代码风格是什么、架构约定是什么。AI就只能基于”最常见的做法”来生成代码。如果你的项目不是用”最常见的做法”，结果自然就不匹配了。

这意味着什么

你的代码可能99%都由AI生成，但让项目代码可维护，绝不是几次交互就能实现的。

现阶段我在使用AI coding工具时，大量的工作其实花在实现过程的review、纠偏和对齐上：

“这两个模块耦合了，需要拆出来保持独立解耦”
“这个错误处理之前遇到过，参考这个文件的修改思路”
“这几行代码属于防御性编程，不需要这么写”
“这个逻辑太复杂了，拆成几个函数”
“react的obs函数不应该承担上下文管理的职责，需要由一个上下文管理器负责”

这个过程很像费曼学习法——在AI犯错时，你需要把如何纠偏的思路清晰地表达给AI。这个表达的过程，本身就是在梳理你自己对项目的理解。

程序员需要的新能力

这引出了一个对程序员的认知和能力转变：当我们越来越多使用AI coding工具来进行编码，那我们就应该对如何使用AI工具变得更擅长，这实际上也对程序员提出了新的能力要求和挑战。

以前的核心能力：手写代码 - 把需求一行一行手敲实现为可运行、可维护的代码。

现在的核心能力：评估代码、指导代码实现思路 - 在不亲自写代码的情况下，判断AI生成的代码是否正确、是否符合规范、是否有潜在问题，并给出清晰的修改指导。

这意味着实现不再是核心，规划、编排、指导成为核心，能能力结构上来分析，这是一种更抽象，更偏向管理的能力。你需要：

快速阅读代码并识别潜在问题
清晰表达你的意图和约束
在架构层面做出正确判断
知道什么时候该相信AI，什么时候该质疑
编排工作流，管理不同的AI agent来协作完成coding任务

比较有意思的是，对当前项目代码深入理解的过程很可能就是在与AI交互协同开发的过程中建立的。你通过不断地review和纠偏，逐渐建立起对项目的深入理解以及对核心技术喊更深刻的认知。从这个角度看，AI虽然取代了写代码的工作，但对架构设计，评审代码，抽象逻辑，AI协同意识的要求更高了。

实用建议

建立完善的上下文供给机制

花时间写一个详尽的项目规则文件：

技术栈声明（可以精确到框架版本）
代码风格规范（或指向配置文件）
目录结构说明
架构决策及其原因
常见模式的示例代码
明确的禁止事项

这个投资是一次性的，收益是持续的。

用示例代码而不是描述

与其说”按照我们的代码风格写”，不如说”参考@src/components/UserProfile.tsx的风格”。AI可以直接从示例中学习你的命名约定、状态管理方式、错误处理模式。

接受迭代式的工作流

不要期望一次prompt就得到完美代码。把”生成→review→纠偏→再生成”当作常态。每一步都保持控制，而不是寄希望于最后一步的审计。

防范错误扩散风险—需要新的Review习惯

问题的本质

AI生成代码的速度远快于你review代码的速度。

代码review属于一个结构性的问题。当AI只用了5分钟内生成了包含5个文件改动接近400行的重构需求代码，改动包含十几个依赖的模块，你有多大把握确保它的改动是完全符合需求的呢？

如果review跟不上，就可能：

放过潜在的bug
引入有安全漏洞的依赖
导致实现偏离目标却没有及时发现

当前没有银弹

坦白说，目前没有特别好的自动化review方案能完全解决这个问题。各种静态分析工具、安全扫描工具可以提供一定帮助，但不能替代人来review的工作。

可行的应对策略

基于文档规范

维护一个”技术决策文档”文件夹，用于记录和指导项目中的复杂改动，比如发现的重要bug，模块级重构需求，让AI分析问题所在，与预期的偏差，修复思路，以及带优先级的行动清单，这样记录之后，AI不但可以有一个清晰的文档参考来实现复杂改动，也同时沉淀了项目知识，可以在后续遇到类似问题时，让AI参考复用。

拆解模块

把大任务拆成小模块，每个模块相对独立。这样每次review的范围可控，不容易遗漏问题。

勤review、勤commit

不要等AI生成了一大堆代码才开始review。每完成一个小功能就review一次、commit一次。这样：

错误发现得早，修复成本低
commit历史清晰，方便回溯
你对项目的理解在这个git提交过程中不断加深

目标 - 缩小错误扩散空间

假设AI生成的代码中有问题，你的目标是让这个问题尽早暴露、影响范围尽量小，否则这个问题会导致级联错误产生，通过一个引入一个bug来掩盖之前的bug，导致越往后越难以排查。同时如果漏过的bug和错误实现没有及时发现，那这个“错误实现”可能成为AI参考的“最佳实践”，后续的实现都以这为标准，直到某天你发现这个实现偏差，你问AI为什么这么实现的，它会给出一个”合情合理”的理由 - “因为之前的模块我们就是这么实现的”。所以通过文档规范驱动，模块拆解，勤commit的方式就是尽可能的将错误早暴露，早识别，早解决，避免后面需要大量投入的纠偏返工(别问我为什么知道的)。