AI 编程元年:我的 2025

写在前面:为什么要记录这一年?

2026 年初的某个深夜,我打开 GitHub,看到 OpenClaw 作者一周 1000+ commits 的数据,突然意识到:我和真正的 AI 原生开发者之间,还隔着一道巨大的鸿沟。

不是技术鸿沟,而是认知鸿沟。

这一年,我经历了从怀疑到尝试、从挫折到突破、从工具使用到理念转变的完整过程。我想把这些记录下来,不是为了炫耀,而是为了:

1. 给自己留个纪念——AI 编程元年的个人史

2. 给同行一个参考——你不是一个人在迷茫

3. 给行业一个观察——变革正在发生

如果你也在焦虑"AI 会不会取代我",或者困惑"为什么 AI 总是不听话",希望这篇文章能给你一些启发。

一、播种怀疑(2023 下半年)

那时的我,还在怀疑。

做 AI 流程类产品的时候,我得出了一个看似笃定的结论:AI 并不适合做流程串联中需要决策的工作。试水了几个 AI 生图场景后,甚至使用 AI 换脸的插件来生成家里小朋友的艺术照,内心却冒出了另一个声音——AI 编程才是真正的生产力场景。

为什么?因为代码是可验证、可闭环的。数学题有标准答案,代码有测试用例,这种确定性反馈,正是训练大模型的沃土。而写文章、画画这些创意工作,评判标准过于主观,AI 很难在其中找到清晰的进化方向。

这个判断,在后来的一年里被反复验证。

二、初尝心流(2024 年)

第一次用 Cursor 的 Tab 功能,我体验到了久违的心流。

下载第一版 Cursor 时,它甚至连目录树都不支持,简陋得像个玩具。但同事的推荐让我再次尝试,那一刻,代码在指尖流淌的感觉回来了——不是手写代码的那种,而是一种"思考即实现"的顺畅感。

从那天起,我开始为 Cursor 付费。不是因为它完美,而是因为它让我看到了一种可能性:编程的瓶颈,或许不再是打字速度。

三、打开新世界(2025 年初)

3.1 Composer 模式的震撼

Composer 模式上线那天,我意识到游戏规则变了。

配合 Yolo 模式和一些"神奇的提示词",我完成了一个完整的前端 Demo 页面——工业级别的代码,不是玩具。那个 Demo 最终开源到了 GitHub,至今仍在运行。

huyansheng3.github.io/desgin-prom…

那一刻的震撼,不是"AI 能写代码"这么简单。而是:前端开发这件事,对 AI 来说已经不是难题了。

3.2 能力边界的探索

从那之后,我刻意训练自己对 AI 出码能力的理解。例如尝试用完全没有用过的 Rust 和 Tauri UI 技术栈去写一个粘贴板应用,在自己对这门语言毫无经验的前提下,同样能够写出一个可打包可运行的应用。至此,对 AI 的能力理解有了充分的认知。

四、挑战与突破(2025 年中)

4.1 开启 CodeFliker IDE:复杂度爆炸

甜蜜期很快结束了。

2025 年 6 月,我开始了 CodeFliker IDE 的开发。这是一个基于 VS Code 深度定制的项目,架构极其复杂:

• 上百个核心文件

• 多进程通信

• 插件系统

• 自定义协议

AI 开始频繁跑偏。

典型场景:

• 我让它实现功能 A,它却修改了毫不相关的模块 B

• 我让它修复 Bug,它引入了新的 Bug

• 我让它优化性能,它破坏了兼容性

4.2 手动管理上下文:做 AI 的保姆

为了让 AI "听话",我开始像操纵傀儡一样控制它:

1. 手动筛选要读取的文件(怕它读错)

2. 用复杂的 prompt 限制行为(怕它乱改)

3. 按任务难度分配模式(简单用快速,复杂用深度)

4. 频繁介入纠正方向(怕它跑偏)

我变成了 AI 的"上下文代理人"和"保姆"。

这段时间,我的状态是:

• 白天:和 AI 斗智斗勇,精疲力尽

• 晚上:收集各种 prompt,试图找到"银弹"

• 周末:研究模型原理,想搞清楚"为什么不听话"

那时我常常想:AI 真的能提效吗?还是只是把我变成了"AI 运维工程师"?

4.3 深度研究:理解而非控制

某天无意中发现 DeepWiki,它能生成技术方案的深度讲解,对理解复杂项目非常有帮助。

我突然意识到:AI 不是不聪明,它只是对项目一无所知。

后来我试图用一些比较复杂的提示词,让 IDE 的 Agent 尽可能去读取更多的代码,发现它其实也能做到 DeepWiki 类似的效果。

这段经历让我深刻理解了一个道理:工具不好用,往往不是工具的问题,而是使用方式的问题。

4.4 讨论模式:从对抗到协作

哪怕在后续的很长时间也常常陷入和 AI 搏斗,直到同事分享了一套 “讨论模式” 的提示词指令，我的工作方式才发生了根本性的转变。这套模式的核心，不再是简单地 “命令” AI，而是将其视为一个具备专业能力的协作伙伴。我开始先与 AI 进行充分、深入的前置讨论，共同梳理需求、界定边界、探讨方案的可行性与潜在风险。

在这种模式下，AI 不再是被动的执行者，而是主动的共创者。它能基于我的初步想法，提出更周全的考量、补充我未曾想到的细节，甚至优化整体的执行路径。当我们在 “讨论” 阶段就达成了高度共识，明确了所有关键细节后，后续的落地实施就变得异常顺畅。需要我手动引导和修正的地方大幅减少，真正实现了从 “人机对抗” 到 “高效协作” 的跨越。

4.5 并行模式:真正的转折点

真正的转折点,是理解了"并行"的本质。

开发 Duet Space 之前,我也困惑:谁会同时开多个 AI?人的注意力根本顾不过来。直到我把工作 SOP 沉淀成 Skill,才发现:并行的不是我的注意力,而是工作流本身。

我开始改变默认模式:

• 从助理模式改为深度研究

• 从边讨论边写改为讨论清楚→研究架构→一次性完成

• 从单线程改为多任务并发

更关键的是,我不再手动控制上下文。让 AI 自己去研究项目,让 Skill 封装重复性工作,让深度模式驱动长时间任务。

结果是:AI 很少跑偏了。因为它真正理解了项目,而不是在猜测我的意图。

4.6 技术本质:理解模型的"性格"

到这时,我开始理解大模型的工作原理对使用方式的影响。

大模型本质是"下一个 token 预测",每次输出都需要对前文做注意力计算。这决定了:

1. 它天然倾向于一次性给出完整答案——哪怕有些部分并不确定

2. 不同的 prompt 会激活不同的"思考模式"——简单问题触发快速模式,复杂问题触发深度模式

3. 训练方式决定了模型的"性格"——有的模型谨慎多问,有的模型大胆假设

理解这些后,我学会了反向利用:

• 用明确的指令抑制"过度自信"

• 用分阶段提问引导"深度思考"

• 用 Skill 固化"正确的行为模式"

这不是在驯服工具,而是在理解一个有特定认知模式的协作者。

4.7 最佳实践总结

原则 1:用"半成品设计"代替"需求描述"

反模式:

"帮我实现一个用户管理模块"

最佳实践:

"实现用户管理模块,具体设计如下:
- 入口文件: src/services/UserService.ts
- 依赖模块: AuthService(鉴权), DatabaseService(持久化)
- 核心方法: createUser, updateUser, deleteUser, getUserById
- 数据流: Controller → Service → Repository → Database
- 参考实现: ProductService(src/services/ProductService.ts)

如果设计有问题或需要更多信息,请先和我讨论。"

原则 2:用"样板代码"代替"抽象规范"

反模式:

"按照我们的编码规范实现"

最佳实践:

"参考 src/services/AuthService.ts 的实现风格:
- 使用 class 而非函数式
- 错误处理统一用 Result<T, Error> 类型
- 数据库操作用 transaction 包裹
- 导出时用 export default new XxxService()
"

原则 3:先方案后实现

工作流:

1. 提需求:"我需要实现 XXX 功能"
2. 要方案:"先给我技术方案,不要写代码"
3. 讨论调整:"方案 A 有问题,因为...改成..."
4. 确认实现:"方案确认,开始实现"

价值:

• 方案阶段改 10 次成本几乎为 0

• 实现阶段改 1 次成本很高(代码已经固化)

原则 4:建立"项目记忆",复利工程

实践方法:

维护 CLAUDE.md 文件,记录:

• 这个项目不能改的地方(历史债务)

• AI 曾经犯过的错误

• 特定的编码约定

• 模块间的依赖关系

效果:

每次开始新任务时,先让 AI 读取这个文件,大幅降低重复犯错。

五、能力边界:AI 不擅长什么?

5.1 强业务语义的历史逻辑

场景:

某个字段在特定状态下用特殊算法计算,代码层面看起来很诡异。

原因:

这是某次需求的定制化解决方案,或某个历史版本的兼容性处理。

AI 的问题:

它能把逻辑写对,但不理解"为什么必须这样",可能会"优化"掉这些关键逻辑。

应对方式:

• 在 CLAUDE.md 中明确标注这些"不能动的逻辑"

• 这类改动由人类主导,AI 辅助实现

5.2 架构方向性决策

场景:

系统处于探索阶段,还在验证技术方案是否可行。

AI 的问题:

它很擅长把每个方案讲得"头头是道",但那不代表这是最适合你场景的方向。

应对方式:

• 把 AI 当"备选方案生成器"

• 让它展开 A/B/C 三个方案的实现细节

• 人类负责拍板决策

5.3 需要"对后果负责"的改动

边界原则:

凡是需要对后果负责的决策,人类多想一步。
凡是只是展开已确定的东西,放心交给 AI。

例子:

• ✅ AI 可以:重构函数提取公共逻辑,优化代码结构

• ❌ AI 慎用:改动核心支付逻辑,修改鉴权流程

展望未来:工作模式的范式转移

一年下来,我经历了这些转变:

最理想的状态是:

1. 用讨论模式聊清楚需求

2. 让深度研究模式理解项目架构

3. 启动 AutoRun 模式自驱完成任务

4. 人类只做最后的验收

这不是科幻,OpenClaw 作者一周 1000+ commits 的数据已经证明:AI 原生开发者和传统开发者之间,存在 100 倍的效率差距。

产业趋势:百团大战与标准化

回到 2026 年初再看这一年,会发现几个明显的趋势:

1. AI Coding 产品的全球化竞争

每天都有新的 AI 编程工具涌现,国内外百花齐放。这不是简单的产品竞争,而是在争夺开发者的工作流入口。

2. Agent 能力的标准化

• AI IDE 产品越来越多地接入 Claude Code 作为底层 Agent

• Agent 从差异化优势变成基础设施

• 竞争焦点从"能不能用 AI"转向"如何用得更好"

3. 智能体平台的崛起

Coze、Dify 等工作流平台走向另一条路:让非程序员也能编排 AI 能力。这和 AI IDE 不是竞争关系,而是在满足不同层次的需求。

4. Openclaw 带来的启示

它最伟大的地方不是打通手机端访问,而是提供了 Agent 自进化能力——它可以扩展自己的底层能力,甚至给自己提供 Meta 级别的能力。

如果 AI 能够自我进化,那它和通用人工智能(AGI)的边界在哪里?这个问题,值得我们警惕,也值得我们期待。

个人反思:面对变革的姿态

这一年的经历,让我时常在想一些"不成熟"的问题:

• 如果我现在出去面试,对方还在问 API 用法、算法实现,我该怎么回答?

• 如果我面试别人,是该问技术细节,还是该问 AI 协作能力?

• 我们是否应该刻意保留"原始编码能力",就像会计保留心算能力一样?

目前我没有标准答案。但我知道:抗拒变化毫无意义,拥抱变化才有未来。

悲观派的焦虑

"程序员要失业了""编程不再是高技能工作""AI 会取代我们"

乐观派的憧憬

"我们能做的事情更多了""效率提升带来更大的创造空间""人类专注于更高层次的工作"

我更倾向于后者。财务软件取代了算盘,但财务人员并没有消失,他们只是在做更高价值的工作。编程也会如此:代码实现会被 AI 承担,而架构设计、需求理解、价值判断,仍然需要人类。

结语:抬头望天,脚踏实地

2025 年,是 AI 编程从"可用"走向"好用"的一年。

我们见证了:

• Tab 补全到 Agent 自驱的技术演进

• 个人工具到协作平台的生态构建

• 实验性尝试到工业化应用的成熟落地

当前的组织还存在前 AI 时代的惯性,2026 年及以后,可能会看到:

• 新的代码版本管理方式(AI Git)

• 新的软件开发流程(超越瀑布和敏捷)

• 新的团队协作模式(人机混合团队)

作为开发者,我们能做的是:

1. 主动学习 AI 协作方式——这已经是必备技能,不是加分项

2. 理解模型的能力边界——知道什么该交给 AI,什么该自己把控

3. 保持对技术本质的追问——工具会变,但解决问题的思维方式不会变

普通开发者和 AI 原生开发者之间,还有巨大的能力 gap。弥合这个 gap 的方法不是焦虑,而是行动。

我们既要抬头望天,看到硅基生命带来的变革;也要脚踏实地,在每一次和 AI 的协作中,让自己变得更强。

这不是碳基生命和硅基生命的对抗,而是一场关于如何定义"开发者"这个角色的大讨论。

最终的答案,会在无数个像你我这样的普通开发者手中,逐渐清晰。

写于 2026 年初, Claude 4.6 发布的早上,回望那个充满探索与惊喜的 AI 编程元年。