过去二十多年，软件工程师的主战场是“面向对象”。我们习惯于拆分类、定义接口、抽象模型，通过设计模式提升系统的可维护性与扩展性。这一套方法论，本质上是在解决一个问题：如何让人类写的代码更接近现实世界的复杂性。

但现在，这个前提正在发生变化。

一、范式变化：从“写代码”到“描述问题”

面向对象的核心，是人去设计结构；而面向 AI 编程，本质上是人去描述意图。

以前开发流程大致是：

需求 → 设计 → 编码 → 调试 → 测试

而现在，逐渐变成：

需求 → 描述 → 生成 → 校正 → 迭代

你不再需要一行行实现逻辑，而是需要把问题描述清楚，让 AI 去生成代码、结构甚至测试用例。这里的关键能力，从“编码能力”转变为：

• 抽象问题的能力
• 精确表达需求的能力
• 快速验证与纠偏的能力

换句话说，工程师从“实现者”，转向“指挥者”。

二、工程能力的重构

很多人误以为，AI 会让工程师“变弱”。实际上，门槛不是降低，而是换了维度。

在面向 AI 编程中，真正拉开差距的，是这些能力：

1. 结构设计能力依然重要

AI 可以生成代码，但不会替你做长期架构决策。系统边界、模块拆分、数据流设计，依然是工程师主导。

2. 结果判断能力更关键

AI 输出的代码，不一定正确，但一定“看起来很对”。你必须能快速识别：

• 是否有隐性 bug
• 是否存在性能问题
• 是否符合业务边界

3. 工具链整合能力

AI 编程不是单点能力，而是系统工程：

• LLM（如代码模型）
• 本地环境（如容器、CI/CD）
• 自动化测试（UT / E2E）
• 数据与日志分析

工程师的角色，更像是在搭建一条“自动化生产线”。

三、开发方式的实战变化

以实际开发为例，现在的高效路径通常是：

1. 先让 AI 输出需求说明书（PRD）
2. 再生成系统设计（架构图、模块划分）
3. 输出代码框架（而不是直接写细节）
4. 分模块逐步生成代码
5. 自动生成测试用例（UT / E2E）
6. 持续迭代优化

这个过程看起来更“轻”，但对节奏控制要求更高。核心在于：不要一次让 AI 做太多，而是分阶段控制输出质量。

四、一个具体案例：疯狂的弹弓

“疯狂的弹弓”就是一个典型的面向 AI 编程产物。

这个项目的关键特点不是技术复杂，而是开发方式的变化：

• 游戏玩法（弹弓打目标）由自然语言描述生成初版逻辑
• 场景系统（白天/黑夜 + 晴雨雾雪）通过参数化设计快速扩展
• 道具系统（天气魔法水、速度魔法水、补血）由 AI 批量生成逻辑与配置
• 新增模块（练习场：固定目标 / 动态目标）通过迭代描述快速落地
• UI、图标、资源也大量借助 AI 生成

整个开发过程中，几乎没有“从零手写一整块代码”的阶段，而是：

描述 → 生成 → 修改 → 重用 → 扩展

这带来的直接结果是：

• 开发速度显著提升
• 试错成本极低
• 创意可以快速验证

但同时也带来一个挑战：系统会越来越“松散”，需要工程师持续做结构收敛和代码重构。

五、软件工程师的转身

这场变化，本质上不是工具升级，而是角色重构。

未来的软件工程师，更像：

• 产品经理（能定义问题）
• 架构师（能设计系统）
• 审计员（能判断结果）
• 指挥官（能调度 AI）

而纯粹的“编码工”，会逐渐被边缘化。

结语

从面向对象到面向 AI 编程，不是替代关系，而是演进关系。

面向对象解决的是“如何组织复杂系统”，而面向 AI 编程解决的是“如何更高效地产出系统”。

真正的竞争力，不在于你会不会写代码，而在于你能不能——

把一个模糊的想法，快速变成一个可运行的产品。

“疯狂的弹弓”只是一个开始。这种开发方式，正在重塑整个软件行业。