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

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

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

❝

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

又或者说，用了 10分钟复刻了别人写的这个效果，代码连接在最后：

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

这种错觉经常让我陷入以为自己“无所不能”，在提效的同时，心态似乎也在慢慢的走偏，比如这段时间以来，我通过 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/：

SKILL.md

—name: flutter-clean-featuredescription: 能够按 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/ 
       
         /{data,domain,presentation} 
       。3. Phase 3: 实现与绑定 - 实现 Repository 时，必须使用 fpdart 处理 Either 
       。 - UI 层必须使用 AsyncValue 处理加载状态。

references/domain_rules.md(知识库)

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

assets/repo_template.dart(模版)

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

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

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

二、增加上下文信息

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

GPT plus 代充 只需 145# 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): 读取 …/SKILL.md…读取 CLAUDE.md..

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

Domain: 定义 TransactionEntity…

Scaffold: 运行脚本创建 lib/features/transaction_detail/…目录。

Data: 实现 Repo，调用 Context 中提到的 DioClient。

Presentation: 使用 riverpod_generator创建 …。

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

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 也能像是你多年的老哥们一样懂你需求，比如：