从写代码到驾驭 AI：2024—2026，程序员的价值正在被重新定义

两年前，我还在思考如何利用 AI 更快地写代码。两年后的今天，我开始思考如何让 AI 帮我完成整个软件工程。

当 Codex 能够理解项目、修改代码、执行命令甚至独立完成复杂任务时，我逐渐意识到：AI 改变的不只是开发效率，更是程序员的工作方式与能力价值。

未来真正重要的，或许不再是一个人能够写多少代码，而是他能否设计出正确的系统，并让 AI 高质量地实现它。

一、两年时间，AI 编程发生了什么？

如果把时间拨回 2024 年，彼时的 AI 已经展现出不错的编程能力。

ChatGPT 可以解释代码、生成函数、分析异常，GitHub Copilot 能够根据上下文提供代码补全，一些 AI 编辑器也开始尝试跨文件修改与 Agent 工作流。

但在我的实际开发习惯中，AI 更多扮演的是一个辅助编码工具。

开发的主要流程依然是：

1. 自己分析业务需求。
2. 自己设计代码结构。
3. 自己查阅文档、寻找解决方案。
4. 让 AI 生成部分代码。
5. 手动将代码整合到项目。
6. 自己运行、调试和部署。

AI 的确提高了效率，但大部分时候，我仍然需要承担几乎所有的操作。

到了 2026 年，情况已经发生了明显变化。

以 OpenAI Codex 为代表的 Coding Agent，已经不再局限于回答编程问题，而是能够在授权范围内主动探索代码仓库、调用工具、修改文件、运行测试，并根据反馈迭代结果。

这意味着开发者能够从大量具体操作中抽身，将更多精力投入需求分析、技术决策和工程质量控制。

2024 VS 2026：AI 编程能力对比

。 info 一个重要区别

这并不意味着 2024 年完全没有 Agent，也不意味着 2026 年的 AI 已经能够可靠地独立交付任何项目。

真正的变化在于：具备自主工具使用和多步骤执行能力的 AI 编程方式，已经从前沿探索逐渐进入日常工程实践。

。

我认为，这比单纯的模型跑分提升更值得关注。

因为它改变的是软件生产方式本身。

二、使用 Codex 后，我的开发流程发生了哪些变化

作为一名前端开发者，我过去的大量时间都花在具体实现上。

例如：

• 根据设计稿开发页面和交互。
• 封装 React 组件。
• 编写 TypeScript 类型与业务逻辑。
• 设计接口并完成前后端联调。
• 修改数据库模型和查询逻辑。
• 排查构建失败、运行异常和依赖冲突。
• 维护项目部署流程。

这些工作中有相当一部分具有明确的目标、既定的模式和可以验证的结果。

过去需要我一项一项完成，现在很多任务已经可以交给 Codex 执行。

1. 从「帮我写代码」到「帮我完成任务」

以前，我可能会向 AI 提出这样的要求：

使用 React 和 TypeScript，
帮我写一个支持分页的评论列表组件。

AI 会生成一个组件，然后我继续补充接口调用、类型定义、加载状态、错误处理等内容。

现在，我更倾向于直接给 Codex 描述目标：

请先分析当前项目的评论模块。

目标：
1. 实现评论分页和二级展示。
2. 保持现有 UI 风格。
3. 兼容匿名评论和审核机制。
4. 不修改既有 API 的公共契约。
5. 避免不必要的数据库查询。
6. 补充必要的异常处理。

执行要求：
- 先分析现有实现和依赖关系。
- 给出修改方案及影响范围。
- 确认不存在明显架构冲突后再实现。
- 完成后执行相关检查和测试。
- 总结修改内容、验证结果和剩余风险。

这两种方式之间存在本质区别。

前一种方式是在请求 AI 生产代码。

后一种方式是在给 AI 分配一项具有目标、约束和验收标准的工程任务。

我不再需要提前决定每一行代码怎么写，而是需要明确最终应该得到什么。

2. 最明显的提升，不只是敲代码变快

使用 Codex 后，我感受到的效率提升主要来自几个方面。

第一，减少重复劳动。

例如基础 CRUD、类型声明、接口适配、表单校验和常规组件封装。

这些任务本身未必困难，却会消耗大量时间。

第二，减少上下文切换。

过去遇到一个问题，我可能需要反复切换 IDE、浏览器、文档和终端。

现在 Codex 可以在允许的范围内主动查找项目代码、阅读相关实现并执行检查。

开发者不必再为每一个细节亲自完成检索和操作。

第三，加快复杂项目的理解速度。

面对一个陌生项目，最耗费时间的事情之一就是建立整体认知。

入口在哪里？

业务逻辑分布在哪些模块？

数据如何流转？

修改某个功能会影响哪些地方？

Codex 可以辅助梳理这些关系，让我更快进入实际问题。

第四，降低跨技术领域的实现成本。

过去从前端扩展到后端、数据库、容器和部署，需要投入大量时间学习实现细节。

AI 并没有消除这些领域的技术门槛，但确实降低了从理解方案到完成实现的成本。

对于具备一定全栈基础的开发者而言，这种提升尤其明显。

。 tip 我的直观感受

过去，一个功能的开发往往需要我持续完成大量具体编码工作。

现在，我可以把更多时间用于分析需求、设计实现方案、检查 AI 的修改和验证最终结果。

AI 带来的最大变化，不是让我不用工作，而是让我能够把精力放在更高价值的工作上。

。

三、当代码越来越容易生成，架构能力反而越来越重要

这是我最近思考最多的问题。

如果 AI 可以完成大量代码编写，那么开发者还需要掌握什么？

我的答案是：

系统架构能力、工程判断能力，以及对复杂问题的抽象与拆解能力。

1. 写出能运行的代码，不等于设计出好的系统

假设现在需要开发一个博客系统。

功能包含：

• 用户认证
• 文章管理
• 分类与标签
• 评论审核
• 搜索功能
• AI 对话
• 后台管理
• 自动化部署

如果直接让 AI 根据这些描述进行开发，它完全可能生成一个功能相对完整的项目。

但功能完整，不代表架构合理。

我们还需要思考：

系统结构：

• 采用单体架构还是微服务？
• 哪些模块应该独立？
• 哪些业务逻辑可以复用？
• 未来增加功能时是否容易扩展？

数据设计：

• 数据表之间是什么关系？
• 哪些字段需要索引？
• 如何处理事务和并发？
• 数据结构是否能够兼容未来需求？

安全与权限：

• 如何设计认证和授权？
• 如何防止越权访问？
• 如何限制恶意请求？
• 如何确保敏感信息不会泄露？

工程交付：

• 如何管理不同环境的配置？
• 如何实现自动化构建和部署？
• 如何监控错误与性能？
• 线上发生故障时如何回滚？

这些问题，很难仅凭一个简单的需求描述就得到适合实际业务的答案。

因为它们不是孤立的代码问题，而是系统性决策。

2. AI 擅长实现局部任务，但需要明确的全局约束

我们可以把软件开发划分为几个层次：

在这个流程中，AI 可以深度参与多个阶段。

但我认为，开发者至少需要对三个关键问题承担最终责任：

1. 我们究竟要解决什么问题？
2. 为什么选择当前的技术方案？
3. 如何证明最终结果是正确且可靠的？

如果开发者自己都无法解释这些问题，那么即使 AI 生成了大量代码，也很难判断整个系统是否朝着正确方向发展。

3. 架构能力决定了 AI 生产力能否持续放大

一个架构清晰的项目，通常具有以下特征：

• 模块职责明确。
• 依赖关系相对简单。
• 接口契约稳定。
• 数据模型具有一致性。
• 测试与验证手段完善。
• 开发规范可以明确表达。

这些特征不仅对人类程序员友好，对 AI Agent 同样重要。

假设一个项目的业务模块高度耦合，修改一处逻辑就可能影响十几个文件。

即使 Codex 可以快速完成修改，也可能因为上下文复杂、隐含约束过多而产生问题。

相反，如果系统拥有清晰的模块边界和测试保障，Agent 就能在更明确的范围内完成任务。

开发者也更容易检查变更是否符合预期。

。 warning 一个值得警惕的现象

AI 可以大幅提高代码的生产速度，但并不会自动保证软件质量。

如果项目缺乏设计和约束，代码生成越快，也可能越快地积累技术债务。

过去，技术债务往往随着人工开发逐渐积累；AI 时代，不合理的设计可能被更快地复制和放大。

。

这也是为什么我越来越认同一个观点：

架构能力不仅决定软件系统的上限，也决定 AI 能否在这个系统中持续、高效、可靠地工作。

四、AI 时代的架构师，不应该只是会画架构图

提到软件架构，很多人会联想到微服务、分布式、消息队列、缓存、负载均衡等技术。

但我认为，架构能力的核心并不是掌握多少技术名词。

而是能够在真实业务约束下，设计出足够简单、合理、可维护的解决方案。

1. 好的架构，从理解业务开始

假设我们开发一个中小型内容平台。

使用 Next.js、MySQL、Prisma 和一套成熟的部署方案，可能已经能够满足当前业务需求。

此时如果为了追求所谓的高级架构，直接引入多个微服务、复杂的消息中间件和分布式基础设施，反而可能增加维护成本。

架构设计需要权衡：

好的架构不是技术越复杂越好，而是在满足需求的前提下，尽可能控制复杂度。

2. 真正重要的是设计能力，而非框架熟练度

以前，我可能更关注：

• React 某个 Hook 如何使用。
• 某个 UI 组件怎样实现。
• 某个接口应该如何编写。

现在，我开始更重视：

• 如何划分业务边界？
• 如何避免数据状态混乱？
• 如何设计可扩展的接口？
• 如何保证模块之间低耦合？
• 如何处理异常、并发与一致性？
• 如何设计可验证、可回滚的变更？

这些能力不依赖某一个具体框架。

React 会更新，Next.js 会迭代，AI 模型也会不断升级。

但软件设计中关于抽象、职责、边界、复杂度和可靠性的思考，依然具有长期价值。

五、一个实际场景：如何让 Codex 参与完整的软件工程？

以一个基于 Next.js、Prisma 和 MySQL 的博客项目为例。

假设现在需要重构评论模块。

需求包括：

• 支持匿名发表评论。
• 支持多级评论数据关系。
• 页面只展示两级评论结构。
• 评论提交后进入审核状态。
• 后台能够分页查看和审核评论。
• 不影响已有文章和用户数据。

第一阶段：人工明确设计约束

我会先明确评论系统的数据与权限规则。

例如：

Comment
├── id
├── postId
├── parentId
├── authorName
├── content
├── status
├── createdAt
└── updatedAt

其中：

postId 用于关联文章。

parentId 用于表达评论之间的父子关系。

status 用于管理评论审核状态。

但这只是数据结构的一部分。

还需要明确：

1. 未审核评论不得出现在公开列表中。
2. 只有具备审核权限的用户才能修改审核状态。
3. 数据层允许多级回复，页面展示层限制为两级。
4. 分页策略必须避免深层查询带来的性能问题。
5. 匿名提交需要考虑频率限制和恶意内容处理。
6. 数据库迁移必须保护已有数据。

这些属于业务规则和工程约束。

第二阶段：让 Codex 分析现有项目

我不会立即要求 Codex 开始修改。

而是先让它分析：

阅读当前评论模块相关代码。

重点分析：
- Prisma 数据模型
- API 接口
- 权限校验
- 评论审核流程
- 前端组件
- 数据查询和分页逻辑

请输出：
1. 当前模块结构
2. 存在的问题
3. 推荐的重构方案
4. 可能受影响的模块
5. 需要补充的测试

本阶段仅进行分析，不修改代码。

这一步的意义在于建立共同的工程上下文。

第三阶段：审查方案后分阶段实现

当设计方案符合预期，再将工作拆分为相对独立的任务。

例如：

在具体实施中，需要注意模块之间的依赖关系。

数据库结构和 API 契约需要先明确，再开展依赖这些契约的工作。

相互独立的任务可以并行推进，而共享文件或共享数据库结构的修改则需要协调。

第四阶段：验证结果，而不是只检查代码数量

完成修改后，我需要关注：

• 是否引入新的权限漏洞？
• 是否破坏已有接口？
• 是否出现重复查询或性能退化？
• 是否通过 TypeScript 和项目构建检查？
• 是否有必要的自动化测试？
• 数据库迁移能否安全执行？
• 是否具备回滚方案？

尤其是数据库变更、用户权限和线上部署，不能因为 AI 表示任务完成就直接信任。

AI 可以执行任务，但任务完成与工程验收是两个不同的概念。

六、我正在改变自己的 AI 编程工作流

经过持续使用，我越来越倾向于把 AI 编程看作一种新的工程协作方式。

而不是简单地把自然语言当作代码生成按钮。

1. 给 AI 提供长期稳定的项目规则

例如使用 AGENTS.md 描述项目约定。

# Project Guidelines

## Architecture
- Use Next.js App Router.
- Use TypeScript for application code.
- Use Prisma for database access.
- Keep business logic separate from UI components.

## Development
- Follow existing project conventions.
- Prefer small and reviewable changes.
- Do not introduce dependencies without justification.
- Preserve existing public API contracts.

## Quality
- Run relevant tests after changes.
- Check TypeScript and build errors.
- Explain assumptions and remaining risks.

## Safety
- Never expose secrets or credentials.
- Never modify production data without approval.
- Never deploy automatically without authorization.

对于 Codex 而言，AGENTS.md 是一种能够向 Agent 提供仓库级工作约定的方式。

不过，项目规则并非越多越好。

我更倾向于只保留真正重要、长期稳定的约束，避免大量重复说明干扰任务执行。

2. 复杂任务，先设计再实施

对于简单、低风险的修改，可以直接交给 AI 处理。

但对于数据库重构、认证系统升级、架构调整等复杂任务，我更愿意采用以下流程：

这种方式看似增加了前期沟通成本，但它能够避免 AI 在错误方向上持续生成大量代码。

对于复杂项目而言，减少返工往往比提高单次代码生成速度更加重要。

3. 衡量效率，要看最终交付结果

我不认为 AI 的价值应该简单地通过生成多少行代码来衡量。

真正值得关注的是：

• 从需求提出到功能交付需要多久？
• AI 生成的修改需要多少人工返工？
• 测试和代码审查发现多少问题？
• 上线后是否产生新的故障？
• 项目的可维护性是否改善？

可以把实际开发成本理解为：

总成本 = 需求分析 + 设计 + 实现 + 验证 + 返工 + 后续维护

AI 可能显著降低实现成本。

但如果因此增加了测试、返工和维护成本，整体收益未必理想。

因此，AI 编程的目标不应该只是更快地产生代码，而应该是更快地交付正确、稳定、可维护的软件。

七、一个需要面对的现实：AI 不一定让所有开发任务都更快

谈到 AI 编程，很容易产生一个印象：

只要使用最先进的模型，工作效率就一定能够提升数倍。

但真实情况比这复杂。

2025 年，METR 发布了一项针对资深开源开发者的随机对照研究。

在其研究条件下，使用当时的 AI 工具，开发者完成任务的时间反而增加了约 19%。

而 METR 在后续研究中观察到，使用 2025 年末 AI Agent 的开发者，在特定测试条件下已经出现了约 4%—20% 的生产率收益。

需要注意，这些数字来自不同研究时期和具体实验条件，并不代表所有开发者或所有项目的平均效率。

它们至少说明两件事情：

1. AI 编程工具的能力确实在快速进步。
2. AI 对实际开发效率的影响，受到任务类型、项目复杂度、工具能力和使用方式的共同影响。

我自己的体会也是如此。

在页面开发、常规业务实现、项目理解和部分重构任务上，Codex 能够带来非常明显的帮助。

但涉及复杂业务决策、隐含历史约束、生产环境安全以及难以验证的系统问题时，仍然需要投入大量人工判断。

。 note 关于效率提升

我确实感受到 Codex 大幅改善了自己的开发体验，但这种主观感受不应该直接换算成未经测量的生产率倍数。

对于 AI 编程的效果，需要结合具体任务判断收益和限制。

。

八、AI 时代，程序员真正的竞争力在哪里？

这两年，我对程序员职业价值的理解发生了变化。

过去，衡量一个开发者能力的重要依据之一，是他能够熟练使用多少技术，以及独立完成多少代码。

但随着 AI 逐渐掌握越来越多的代码实现能力，单纯依靠框架 API 熟练度建立竞争优势，会变得越来越困难。

我认为，未来值得持续投入的能力主要有五个方向。

1. 系统架构与工程设计能力

包括：

• 业务建模
• 模块划分
• 数据库设计
• API 设计
• 性能与可靠性
• 可扩展性与可维护性

AI 能生成更多代码后，明确目标、约束和验收标准就更加重要。

2. 跨技术领域的理解能力

对于前端开发者而言，我认为不应该把自己局限在浏览器和 UI 层。

应该逐渐理解完整的软件交付链路：

业务需求
   ↓
前端应用
   ↓
API 与服务端逻辑
   ↓
数据库与缓存
   ↓
容器与运行环境
   ↓
CI/CD
   ↓
监控与维护

并不是要求每个人都成为所有领域的专家。

而是需要具备足够的系统知识，能够理解各层之间的关系，并判断 AI 提出的技术方案是否合理。

3. AI Agent 的使用与编排能力

未来，善于使用 AI 的开发者，可能更像一个能够协调多个任务执行单元的技术负责人。

这要求我们掌握：

• 如何描述清晰的目标。
• 如何拆解复杂任务。
• 如何组织项目上下文。
• 如何定义稳定的技术约束。
• 如何设计自动化验证。
• 如何控制工具权限与执行风险。

相比于追逐某个特定的提示词技巧，这些能力更具有长期价值。

4. 解决真实业务问题的能力

技术最终需要服务于真实需求。

能够开发一个漂亮的页面，与能够理解客户需求、设计产品流程、解决业务问题，并持续交付价值，是两种不同层次的能力。

我越来越觉得，开发者需要从关注「这个功能怎么实现」，向关注「这个功能为什么存在」转变。

5. 持续学习与独立判断能力

AI 模型、框架和工具的迭代速度正在加快。

今天最熟悉的开发方式，未来未必依然是最佳方案。

但无论工具如何变化，理解原理、识别问题、评估方案、独立判断的能力，都不会轻易失去价值。

。 tip 我认为值得坚持的方向

对于有一定经验的前端开发者，我更看好这样的成长路径：

前端工程师 → 具备全栈能力的软件工程师 → 拥有架构设计和 AI 协作能力的技术负责人。

这里的技术负责人不一定是管理岗位，更重要的是能够对系统设计和工程交付承担责任。

。

九、从「自己写好代码」到「让整个系统高质量运转」

回过头来看，我觉得 AI 对软件开发最大的改变，不是某个模型能够一次生成多少行代码。

而是让开发者有机会改变自己在整个工程流程中的位置。

过去，我需要把大量精力放在具体实现上。

现在，借助 Codex，我可以将更多注意力放到系统设计、任务组织和质量验证上。

这并不意味着基础编程能力已经不重要。

恰恰相反。

如果没有足够的技术基础，我很难知道 AI 生成的代码是否正确，也很难在复杂问题出现时判断应该如何修复。

AI 降低了实现的成本，但没有消除理解系统的必要性。

一个缺乏技术基础的人，可能能够借助 AI 快速制作出可运行的原型。

但要将原型发展为安全、稳定、长期可维护的软件，仍然需要扎实的工程能力。

我更愿意把 AI 看作能力放大器。

对于缺乏系统理解的人，它可以降低入门门槛。

对于具备工程经验的人，它可以扩大能够独立承担的任务范围。

而对于既理解业务、又具备架构能力，同时善于使用 AI 的开发者，它可能进一步提高完整产品的交付能力。

十、写在最后：代码生成更方便以后，我更关注技术决策

2024 年，我更多是在学习如何利用 AI 编写代码。

2026 年，我已经开始习惯让 Codex 参与整个项目的开发、重构与调试。

这两年之间，变化远远不止工具更智能。

它让我重新思考一个问题：

当编写代码不再是软件开发中最昂贵的环节，程序员应该靠什么创造价值？

我的答案逐渐清晰。

不是单纯追求掌握更多框架。

不是将所有开发工作不加判断地交给 AI。

更不是因为 AI 能够编程，就放弃对技术原理的理解。

而是不断提高自己定义问题、设计系统、管理复杂度和验证结果的能力。

过去，我们需要证明自己能够把代码写出来。

未来，我们可能更需要证明自己能够把正确的软件做出来。

AI 可以帮助我们实现想法，却不能替我们承担所有技术决策的后果。

它能够改善开发效率，也可能让错误的设计以更快的速度扩散。

因此，越是在 AI 能力迅速发展的时代，我越认为应该重视那些不依赖具体工具的底层能力。

理解业务，理解系统，理解工程。

同时学会与 AI 协作，把先进工具转化为真正的生产力。

。 quote 最后的思考

2024 年，我希望 AI 能帮我写更多代码。

2026 年，我希望自己能够设计更好的系统，让 AI 帮我完成更多工程。

代码仍然重要，但代码从来不是软件开发的最终目的。

真正有价值的，是理解问题、做出正确决策，并持续交付能够解决实际需求的软件。

。

未来的软件工程师，或许不再需要亲自编写每一行代码。

但一定需要知道：

为什么要这样设计，如何让系统正确运行，以及出了问题应该由谁来负责。

这就是我理解的，AI 时代程序员最值得构建的长期竞争力。

参考资料

以下资料用于了解 AI 编程工具的发展和实际工程应用。其中涉及的研究结论具有特定实验条件，不宜直接推广到所有开发场景。

1. OpenAI：Introducing Codex（2025） — Codex 云端软件工程 Agent 的早期发布。
2. OpenAI：Codex as a Platform（2026） — Agent 执行框架与工程工作流。
3. OpenAI：Rethinking Skills and Prompts for GPT-6 Astra（2026） — 项目指令、上下文组织与 Coding Agent 协作。
4. Google：2025 DORA Report — AI 在软件开发中的实际使用与组织层面的影响。
5. METR：AI 对资深开发者生产率的影响（2025） — 随机对照实验与生产率研究。
6. METR：Frontier Risk Report（2026） — 包含 AI Agent 能力与后续生产率研究的讨论。

本文是我对 AI 编程发展、Codex 实践以及软件工程师长期竞争力的一次阶段性思考。随着 AI 技术持续演进，这些认识也会不断更新。