2025 AI 实践总结

前言

2025年初，我使用AI编程还处于半吊子水平，只能解决一些局部问题。到年底，已经能够独立完成大部分开发任务。这一年，我在业务和个人项目中深度使用了业界主流的AI模型、CLI工具和IDE，本文将从模型对比、成本分析、实践场景和思考几个维度，总结这一年的AI编程经验。

一、模型和工具对比

工具评测表

我的工具组合

综合对比下来，我形成了如下的工具使用策略：

1. IDE选择

• 新功能开发：首选Antigravity，token充足，使用流畅

• 小功能迭代：使用Cursor

2. 模型选择

• UI实现：Gemini 3 Pro

• 逻辑开发和Bug修复：GLM 4.7或Opus 4.5（复杂问题优先Opus 4.5）

• 代码重构：Codex

3. 成本控制

• Codex：$20/月

• GLM：¥40/月

• Cursor：$20/月（已退订，改用自接入的GLM 4.7）

• Token不足时：配合opencode使用免费额度

二、实践场景

1. 从RAG到LLM.txt

上半年遇到一个需求：将Vue项目代码转换为React。由于源项目使用了古早的组件库，目标项目需要使用公司内部组件库，而通用模型不具备这两种组件库的知识。

初始方案：基于RAG的实现

我搭建了一个基于RAG的客户端，流程如下：

1. 用户选择源码文件

2. 通过AST分析依赖图

3. 对依赖图中的关联代码进行AI转换

知识库处理流程：

• 使用脚本提取和拼接组件库的md文档

• 对文件进行分割和向量化

• 在AI转换前进行知识召回

这个典型的RAG链路最终效果不理想，主要问题在于：

• 模型能力是基座，使用的Qwen模型能力确实不足

• 向量化和召回的第三方库都比较轻量（为了本地运行），效果不佳

优化方案：llm.txt + 本地索引

受社区启发，以及Sonnet 3.5的发布，我改变了思路：

• 在Cursor中使用llm.txt建立本地索引

• 将转换前后的代码写入llm.txt

• 将所有组件文档喂给Sonnet，生成精简版llm.txt

在消耗大量token后，典型页面的转换成功率达到了90%的可用度。

2. 从Agent到提示词

在个人项目中，我实践了Agent的能力，主要涉及：

• 模型的智能切换

• 多Agent的编排

• 上下文压缩处理

在langgraph的加持下，开发难度并不大。当然，这也得益于项目本身不算太复杂。

目前业界对Agent的实践还没有形成统一的范式。观察Code Agent领域，gemini cli、codex cli、kimi cli的实现方式都各不相同。

Agent的演化趋势

Agent目前主要作用是弥补AI基座能力的不足。但随着模型能力的提升，一些原本需要Agent完成的任务，正在逐步被AI直接接管，比如任务编排。

这让我想起《沸腾新十年》中的观察：Android早期，当系统能力较弱时，垃圾清理、电池管理等增强类工具市场很大。但随着系统能力完善，这些APP不可避免地被系统开发商取代。

AI的能力演化似乎也遵循类似的规律。如今，dify和coze这类平台搭建的Agent，已经可以直接用一句提示词让AI独立完成。从agent，到mcp，再到skill，AI的能力增强其实是越来越简化的。

3. 全链路赋能实践

帮忙写代码只是单点问题。从整个开发链路和前端工程角度，还需要补充更多实践来实现全链路赋能。

（1）从UI到代码

这是AI尝试最多的方向。Figma官方也推出了MCP服务，用于将设计稿生成代码。但实际体验并不理想，特别是需要转换为公司自有组件时，通用AI往往力不从心。

我实践下来，最有效的方式是：直接截图交给Gemini 3，并清晰描述各个元素使用什么组件。

（2）私有组件知识库

沿用之前的实践，将组件库文档生成llm.txt，交给本地索引。实际上，Cursor和claudecode在生成代码时会参考现有代码，所以只要样本代码足够，这一环节的作用没有之前那么显著。

（3）从单一问题到Spec Coding

前端架构在整体产品中相对较薄，即使在复杂业务生态下，上下文和状态管理也是有限的。这带来一个好处：大部分场景下，我们可以用文字准确描述背景和计划。

关键在于如何给AI编写指导手册。通用原则如SOLID是公认的，但文件结构、组件颗粒度、状态拆分和耦合等设计，依赖于开发者自己的设计理念。如果完全交给AI，效果往往不佳。

对于复杂需求，我目前的实践流程是：

1. 描述背景

2. 添加关键代码路径

3. 提供接口数据结构

4. 描述自己的解决方案

5. 让AI优化和补充文档

6. 让AI按文档拆分任务

7. 进行渐进式实现开发

配合通用的skill和subagent，目前日常需求能够完成80%，疑难问题90%都可以帮我解决或提供解决思路。

（4）活文档

程序员最讨厌两件事：别人不写注释，以及自己要写注释。

几年前，我读了《活文档》一书，这本书探讨如何制度化地将文档流程融入业务开发。但因为国内实际情况，这个制度很难落地。

有了AI就不同了。在项目中维护一个文档库，利用Claude skill对提交的代码进行总结，并实时补充到文档中。这样，无论是做回溯还是后续迭代都有裨益，既方便程序员开发，也方便AI理解背景和上下文。

三、独立开发者的AI创业观察

过去两年，许多程序员转为独立开发者，做AI相关业务。根据我的观察，主要分为以下类别：

1. 套壳应用

典型如GPT套壳产品。前期确实有不少人赚到钱，但随着豆包、千问等产品的诞生，这些套壳应用逐渐消失。之前火出圈的VSCode插件ChatMoss，一度做到数万用户，现在已经一年不更新了。

2. 图片生成

这个赛道很难。做视频没有那个财力和能力，做图片相对简单，但也因此没有门槛。可以吃一波新鲜饭，但很快因为大家都涌入而难以做出差异化。年初关注一个美团程序员，离职做图片应用，当时数据很好，但后来竞争激烈，不知道现在怎么样了。

3. 提效工具

如数据处理、文案生成等。市面上有ChatExcel、AIPPT等成熟产品，一般是小公司做的，目前没看到比较好的个人开发产品。

4. 知识库和笔记类

笔记类本身场景小，还有Notion、飞书这类成熟产品。玉伯做的youmind据说已经有千万级别的ARR，我试用过youmind，但还是没理解它的卖点。

5. 资讯和AI博主

这个成功的比较多。也有一部分人趁机拉圈子，卖知识星球和课程，目前看这部分人成功的较多。

6. 垂类工具或插件

细分领域和市场，如AI播客、AI翻译、建站模板等。目前了解到比较成功的应该是沉浸式翻译。

四、思考

元旦前与前司老板吃饭，他提出一个问题：AI时代下，社会如何重新分配？

在非AI时代，学历和知识是社会分层和分配的主要依据。但AI造成了知识平权，那如何重新分配社会财富？

老板的思维高屋建瓴。

当时我说：相信社会的演化，在不同时代下自然会演化出不同的分配方式。

回来后我想起出差路上看的《周期》一书。作者是投资大鳄，他说自己有很多投资技能建立在实践之上，这部分东西无法描述，即使描述出来也无法通过阅读学会。

一个简单的例子：AI可以告诉你游泳的所有技巧，但并不等于你就能学会游泳。

最近遇到一个案例：有同学要在某图层上的两个图标之间画贝塞尔曲线连接，但绘制出现了偏移，连不上两个图。不同的缩放比例下，偏移量也不同。他使用AI来解决这个问题，很久没有解决。我建议换个思路，直接挪一下图标位置。按照这个思路，很快解决了问题。

也就是说：知识和能力之间存在鸿沟，而社会的分配大概率上仍是以能力为导向的。

我把社会上的知识，分为三类：通识，专业知识，精英知识。

通识是AI最擅长的，比如这个鸟什么种类，这个单词是什么意思。

专业知识就是我这种程序员或者会计，他有一定的难度，需要一定的经验，但是没有难到需要比拼天赋。

精英知识就是一些不是依靠人力就能突破的知识点，比如我在AI的指导下去学习其他编程语言，是可以XX天从入门到精通，但是你现在给我一本《控制论》，我还是学不会。

从这个划分上讲，AI的冲击是对我们这种所谓专业知识人员冲击较大。但是这到底是一个好的冲击还是坏的冲击，现在难以论述的。如果简单的用出租车和马车的历史来做例子，我认为是有点粗暴的。我对AI的能力表示惊叹，但也不认为它能解决一切问题，一个段子说：如果全用AI了，谁来背锅呢？

在《人类简史》中，作者说智人之所以打败更强壮的尼安德特人，是因为智人拥有更强的协作能力。

人类社会的发展，也是在不同的时代，气候，生产力的背景下，人与人协作关系的变化中发展的。AI是新的生产力，我相信也会最终演化出新的生产关系来的。所以未来是什么样，我觉得更多的还是以演化的态度去看，不用规划的态度去看。