2025 年终醒悟，AI 让我误以为自己很强，未来程序员的转型之路

恋猫de小郭
0 阅读10分钟

2025 可以说只要是开发者都绕不过 AI ，时至今日你说你不用 AI 写代码我是不信的，但是直到最近我才发现，我似乎已经把 AI 的能力当做自己的能力，这种错觉体现在，昨天我用 AI 五分钟做出这下方这个动画效果：

不知道有没有人能看出这个动画里的梗。。。。

自从有了 AI 之后，有问题可以让 AI 解读，有需求可以让 AI 分解，比如我想做上面那个动画的时候，只需要让 AI 先根据我的表述给出数学公式，然后根据公式再让 AI 实现和组合代码，而这个过程我只需要点一点运行，预览下效果符不符合我的要求，然后我就觉得自己强的可怕。

image-20251226121839643

这种错觉经常让我陷入以为自己“无所不能”，在提效的同时，心态似乎也在慢慢的走偏，比如这段时间以来，我通过 AI 复刻和尝试了许多特效，虽然偶尔需要我介入修改问题，但是大多数时候都是在 Vibe Coding ，而看着这些充满想象力的炫酷动画，那种自以为是的心理就会被 AI 无限放大 。

但是现在想来，你真的理解过这些动画吗？真的有去了解他们的实现原理和实现逻辑吗？就算事后看过，不是你写的东西，过后还有印象吗？也让我想起了 Anthropic 在 《How AI Is Transforming Work at Anthropic》 文章里提到过的：

“我以为我喜欢写代码，其实我只是喜欢代码跑通的结果”。

这也让我开始怀疑，我究竟是喜欢写代码，还是只是单纯喜欢跑通产品？在这个过程中，AI 带来的短期能力提升，很容易就让人对自己的定位产生误差，实际上这个过程有没有发现你的能力可能正在倒退？

这种职业认同的危机不只是外部开发者有， Claude 内部开发者也有这个焦虑，所以未来 AI 对于开发者的影响，还可能会带来新的职业价值观的重构，所以有人感到迷茫：如果写代码这个动作本身不再重要，那么以后作为软件工程师的身份认同建立在哪里？

而在这个过程里，AI 能显著增加产量并扩展个人可承担任务的范围，但同时带来技能退化风险。

如今 AI 越来越强已经是时代必然的浪潮，而 AI 现在的缺陷也会很快被时代所修复，就像 Google 的 Nested Learning 论文介绍的，现在大模型的问题在于大模型无法在训练后继续学习 ，因为目前的大模型只有极快且短暂的记忆（In-Context Learning）和冻结的长期记忆（Pre-trained Weights） ，这个问题在于：

当前模型缺乏将“即时对话”转化为“长期参数”的机制，也就是它们缺乏中间的频谱：那些应该从短期逐渐变为长期的记忆。

但是这个问题已经被他们通过全新的 HOPE 架构攻克，未来能“吃一堑长一智”的 AI 也许离我们就不远了，所以编程能力对于程序员来说，未来是一个什么地位？这个职业的核心竞争力又在哪里？

在开发实现过程中 AI 很强，但是我们需要清晰的知道，AI 的强大的编程能力并不是你的能力，而作为程序员，你竞争力也不再是：

  • 熟练掌握某些框架和 API
  • 精通某个语言和语法

在这些方面，人是跑不过机器的，就像 《 OpenAI 使用 Codex 在 28 天内构建 Android 版 Sora》 里介绍的：

在使用 GPT-5.1-Codex 之后，在短短 28 天内，不仅完成了繁重的开发任务，还创造了上线 24 小时生成 100 万视频、99.9% 无崩溃率的应用，在这个过程里AI 可以 24 小时无间断编写代码和自我修复，28 天通过 50 亿 token 完成了正常需要几个月的产品上线。

所以从这里可以看到，你如果想和 AI 拼编码能力肯定是拼不过的，就像 OpenAI 最后总结的：未来的开发工程师的能力不再是打字速度或语法 API 记忆，而是对系统的深刻洞察力。

直到看到 OpenAI 和 Anthropic 等模型公司对于程序员未来的思考时，我才明白不能再沉迷于 AI 编程给自己带来的“成就感”，因为那是 AI 的能力而不是你的，你用 AI 可以做到，那别人用 AI 是不是也能做到，那你的职业竞争力在哪里？

未来的开发者，强的可能不是代码能力，而是项目管理和 AI 驯服能力。

所以未来程序员的职业能力肯定会发现变化，比如 2026 对于开发者来说，短期的价值会体现在如何驯服 AI ，因为现在的 AI 还是一批脱缰的野马，他的保证就像是“事前”的承诺，各种言之凿凿让你相信它：

而事后提起裤子，出问题了它可半点不认，所以如何驯服 AI ，同时如何管理和做好大模型善后工程师，这将是程序员短期内的职业变化。

而如何驯服 AI ，其实也很简单，那就是不要上来就让 AI 执行需求，而是给 AI 规划好需求和规则，把 AI 看作是一个“高能力但缺乏背景的资深新员工”，而你负责架构设计、用户体验和最终决策，而 AI 负责写代码、单元测试和需求落地。

因为 AI 的短板在于目前对于需求的理解还不够，也不擅长得深层的架构权衡（经常为了实现功能而把代码写乱），因为它的 Context 有限，所以经常都会比较片面去理解项目，所以作为程序员，你需要做的是：

  • 先规划后代码：先让 AI 理解系统并编写“设计文档”，纠偏后再执行
  • 背景信息驱动：通过各种文件文档为 AI 提供规范和上下文，比如各种 rule 和模块描述
  • 增加技能支持 : 通过各种技能描述让 AI 能力增加，比如 CC 可以通过 skills 加载各种插件来辅助能力提升

举个例子，比如你要用 Flutter 做一个 Wallet App ，而任务是开发一个 TransactionDetail 模块，需求是：

  • 必须遵循 Clean Architecture (Domain -> Data -> Presentation)
  • 数据敏感，金额精度（Decimal）、哈希脱敏显示有严格规范
  • 状态管理，强制使用 riverpod_generator + freezed

那么在 Claude Code 场景，首先接下来你需要做的会是：

一、增加 Skill

这里的核心是教 AI “在这个团队里，如何标准化地生产一个 Feature” ，例如创建一个 skills/flutter-clean-feature/ ：

  1. SKILL.md

    ---
name: flutter-clean-feature
description: 能够按 Clean Architecture 标准生成全套 Flutter 功能模块
usage: "当用户想开发新页面或功能模块时使用"
---

# 标准工作流 (SOP)
AI 在执行此 Skill 时，必须严格遵守以下顺序：

1.  **Phase 1: 领域建模 (Domain First)**
    - 读取 `references/domain_rules.md`。
    - 优先定义 Entity 和 Repository 接口。
    - *Check*: 所有的金额字段必须使用 `Decimal` 类型，禁止使用 `double`。

2.  **Phase 2: 架构脚手架 (Scaffolding)**
    - 调用 `scripts/scaffold_module.py` 自动生成文件夹和空文件。
    - 路径结构必须是 `lib/features/<name>/{data,domain,presentation}`。

3.  **Phase 3: 实现与绑定**
    - 实现 Repository 时，必须使用 `fpdart` 处理 `Either<Failure, T>`。
    - UI 层必须使用 `AsyncValue` 处理加载状态。

  2. references/domain_rules.md (知识库)

    • 包含团队约定的 Clean Architecture 分层图
    • 包含 JSON 解析的通用错误处理模版

  3. assets/repo_template.dart (模版)

    • 预置了带有 Either 返回值的 Repository 接口模版

  4. scripts/scaffold_module.py (自动化工具)

    • 一个 Python 脚本，接受模块名参数，自动在 lib/features/ 下创建标准的文件夹结构和基础文件（解决 AI 有时候懒得创建文件的毛病）

二、增加上下文信息

核心思想就是告诉 AI “这个项目现有的基础设施是什么” ，比如项目维护一个 CLAUDE.md，提供项目级上下文：

# CryptoWallet Project Context

## 技术栈
- Flutter 3.24
- Riverpod (Annotation mode only)
- Dio (已封装在 `lib/core/network/dio_client.dart`)
- UI Kit (所有按钮必须使用 `lib/core/widgets/app_button.dart`)

## 现有能力
- 格式化工具：`lib/core/utils/formatters.dart` (包含 hash 截断、货币格式化)
- 路由：GoRouter，路由定义在 `lib/routes.dart`

三、先规划后代码 (Plan)

可以利用 Claude Code 的交互能力，先加载 Skill 进行规划，审核无误后再由 Skill 中的 Script 自动执行，例如：

1. 启动与规划

"使用 skill: flutter-clean-feature，我要开发一个 TransactionDetail 模块，输入是 txHash，需要展示交易金额、时间、发送方和接收方。"`

Claude (加载 Skill): 读取 skills/flutter-clean-feature/SKILL.md... 读取 CLAUDE.md 获取项目上下文...

Claude (输出规划): 根据 Flutter Clean Feature SOP，我制定了以下计划：

  1. Domain: 定义 TransactionEntity (包含 Decimal amount) 和 ITransactionRepo。
  2. Scaffold: 运行脚本创建 lib/features/transaction_detail/... 目录。
  3. Data: 实现 Repo，调用 Context 中提到的 DioClient。
  4. Presentation: 使用 riverpod_generator 创建 transactionDetailProvider。

请确认：是否需要支持“交易状态（成功/失败）”的枚举？

2. Review 优化

User: "需要。另外，UI 上金额显示需要调用 formatters.dart 里的方法，不要自己写格式化逻辑。"

3. 执行

Claude: 收到。开始执行。

(Claude 内部触发 Skill 中的 Script) Run script: python skills/flutter-clean-feature/scripts/scaffold_module.py transaction_detail ：

Terminal Output: ✅ Created lib/features/transaction_detail/domain ✅ Created lib/features/transaction_detail/data ✅ Created lib/features/transaction_detail/presentation

(Claude 继续编写代码) Claude 根据 assets/repo_template.dart 填充 transaction_repository.dart，并根据 CLAUDE.md 里的规则，引入了 dio_client.dart。

······

是不是觉得很繁琐？是不是觉得一轮整下来我需求都写完了？但是这就是使用 AI 的趋势，只有这样才能控制和管理好 AI 的代码，不至于让 AI 写出一坨屎山，而随着你对工程文档和技能补充的完善，你的开发速度就会越来越快，AI 也能像是你多年的老哥们一样懂你需求，比如 ：

CLAUDE.md 确保了 AI 不会引入 http 库（因为它知道有 Dio），也不会手写丑陋的按钮（因为它知道有 AppButton），它理解了项目的现状，知道有什么技能可用，然后通过规划很你完成确认，这些写出来的代码和项目才是可持续维护的。

最后，这一年里我出了用 AI 写代码之外，也开始尝试用 AI 去解决和尝试代码之外的事情，因为 AI 所以我敢于尝试一些以前不敢接触的领域，因为过程学习成本太高，而现在 AI 提供了另外一种思路：

我不需要真的懂，我只需要让 AI 去做就好了，而我只需要提供想法和验证结果。

2025 即将结束，而 2026 也会如期而至，而 AI 的浪潮从未停歇，愿你我都能在新的浪潮下找到自己的位置~

avatar
文章
阅读
粉丝