本文分享作者对 AI 编程工具的实际使用体验，评测了多种 AI 聊天机器人和代码编辑器的性能特点。详细探讨了 AI 辅助编程的工作流程，分析了人在 AI 时代转变为”产品经理”角色的趋势，并提出了软件架构能力、技术基础和资源调度能力在新范式下的重要性。
2025 年 AI 的发展真是让人目不暇接，各种公司的 AI 产品迭代速度真快，甚至在我写这篇文章的初稿之后，有些内容需要再次更新。
作为一个程序员即感觉到了危机，又感觉得到了一些机会。对于最新最先进的技术，总希望能够快速体验，生怕落后了。
于是在体验了一段时间各种先进 AI 应用之后，有一些小小体验和感想。
总结#
首先以我自己的使用体验总结一下用过的 AI 产品：
截止日期 2025 年 3 月初
AI Chatbot：
纯主观的，不公正的使用体验
-
速度快的：Gemini，Grok，QWen（本来有 ChatGPT 的，最近一段时间感觉慢了不少，输出结果也不太满意，因此把它开除了）
-
速度慢的：Deepseek，VS Code with Copilot
-
中文逻辑能力强的：Deepseek
-
代码能力强的：Cladude-3.7(new)，Cladude-3.5，Deepseek
-
Reasoning+WebSearch: ChatGPT，Deepseek
-
DeepSearch: Grok3
-
bugfix 能力强的：o3-mini, Deepseek, Cladude-3.5/3.7
-
识别图片的：Gemini，QWen
-
生成图片的：Gemini，Grok3
AI 编辑器：
- Cursor + Deepseek/Cladude-3.7
- Trae + Cladude-3.5/Cladude-3.7
- VS Code with Copilot + o3-mini
速度最慢的是：VS Code with Copilot 项目起步适合用：Trae 后续功能迭代适合用：Cursor
这里面最有名的是 Cursor，不过我对 Cursor 深度使用之后，感觉它也不是那么好用。
比如使用 rust 写项目，功能复杂之后，模块比较多，模块间的依赖关系也就复杂了。再通过 Cursor 几次重构后，更是越来越混乱。编译时永远有一大堆模块依赖问题，重复定义，重复引用，缺少定义，缺少引用，缺少导入等等这一堆低级问题。最后的结局大概只有重开项目，因为太费时间，也太费 token 了，不值得。
我后面应对方案是：一开始所有的代码都在单个文件。只有基本功能实现，把这先跑通，能够算得上是 MVP 了，提交保存，然后再让 Cursor 将这个项目工程化，即将单个大文件拆分为多个模块，这个时候，往往能取得比较好的效果。当然这个也可以让 Trae 的 Builder 来完成。
不过它们都有一个大的特点，就是会输出一大堆”车轱辘”代码，就跟它们很擅长输出漂亮的废话一样，以及会犯一些低级错误、重复性错误。实际上还是那个问题，对于入门级项目，或者网上有很多模板的项目，特别是现在的前端，用它们实现项目原型确实又快又好，但是要实现复杂的逻辑、功能，这是得取决于人，需要人来把控需求和质量。
人越来越像产品经理#
以前有句话：人人都是产品经理。在 2025 年，这句话可能更正确，更合适。
我的流程：
- 让 AI 整合信息，生成完整的有逻辑的 prompt 语句
- 根据整合的 prompt 再让 Grok3 DeepSearch 生成技术报告
- 根据技术报告，再让 Cursor, Trae 同时完成项目。
- 再对功能进行优化、改进。
我让几个 AI 生成了一份软件设计文档，然后综合了起来，作为模版使用。 准备材料：
- cursor rules 文档（JavaScript, golang, rust 等不同项目使用的规则不同）
- 软件设计文档（通用模板，但是具体项目需要填写具体的内容）
- 参考文档（具体技术栈所涉及的文档）
- 相关网页，URL，本地资料等。（更广泛的资料）
cursor rules 有很多参考：
*关键点：
- 前期对产品功能所涉及的技术要有所了解
- 合理设置 AI IDE 的规则
- 从最小可行产品开始，验证功能以及流程后，进行功能迭代
- 每次不能改变太多文件，否则难以审核更改的正确性
- 测试代码不可少
- 多测试 (对于每次跑测试需要等待一会儿的开发不太友好)，多验证
- 及时 git commit
- 灵活使用 git 分支，可以在新的分支上进行代码修改，验证可行后，cherry-pick 到主分支
考验的能力：
- 资源调度以及合理利用能力：各种 AI 工具很多 (ChatGPT，Gemini，DeepSeek、Grok，Qwen)，VS code with CoPilot, Trae, Cursor, 他们各有优缺点，适合干不同的活，如何合理安排，让它们有条不紊的配合工作，是一种能力。
- 软件架构能力，在编写技术文档时，需要特别从全局考虑软件的架构问题，从而决定哪些是重点模块，哪些是优先级靠后的功能
- 对底层技术的了解，如果完全不了解，对于 AI 生成的代码，它们很多都是 “糊弄”或者说不知道从哪里拼凑出来的东西 (比如从 CSDN 上？😄)，因此 AI 提供的代码看起来一大堆，但可能实际上都是”废话满篇”，一本正经”胡说八道”。因此我们作为管理它们的人，首先要对技术有所了解。
- 从上面的点自然看出来，管理能力的重要性了，这里既包括手底下的 “AI 员工”，又包括自身的技术基础。
最后#
对于用 AI 写代码的人来说，某种程度上，我们只是有了一个更聪明的编译器，而不是有了万能钥匙，最后的落脚点还是在于人，而不是工具。软件行业也已经从 Cloud-native 到了 AI-native，在新趋势面前，总是会有很多新机会的。
最后附上飞书表格+DeepSeek 实现的单词本，只需要输入单词，自动获得其中文翻译、发音、使用示例。我觉得这就能把很多单词应用取代了。
