软件开发：AI与学徒

最新推荐文章于 2026-06-20 12:10:43 发布

原创最新推荐文章于 2026-06-20 12:10:43 发布 · 611 阅读

9 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#人工智能

当越来越多的工作岗位被AI所替代，你是否有过茫然与无措，是否担心。结合多年的开发经历与现状，分享近期的思考与感受。

一句话阐述核心：工作不是一成不变的，我们要为未来做长久计划

1. 现阶段，文字创意，图像创意相关的工作，影响是非常大的，以前几天写一个文案；现如今一天写很多文案；（实际上文案质量不是重点）

2. 随着AI编程工具的大量涌现，软件开发行业也在经历变革，原来的以瀑布流形式衍生的各种软件开发工程，引入AI辅助编程/氛围编程之后，导致软件编码阶段速度飞快，一部分来老板开始裁撤开发岗位，要求提效；

随着AI的演进，很多名词也逐渐产生，比如 AI 氛围编程(Vibe Coding), Spec 编程，Agent，Skill，总之一堆名词。我们甚至 IT 行业善于创建名词。那么这些对我们软件开发人员有什么影响呢。

AI对于软件开发的影响

1. AI 工具

1.1 早期IDEA 代码补全

在早期JetBrains IDEA 内置了很强的自动提示，代码补全，Postfix Complete, 以及代码模版等一堆便捷功能，确实给软件开发者带来了便利。但是需要开发人员熟练掌握IDEA系列的工具使用。

此时人力是软件开发的重点。

1.2 AI Tab 编程（Tab 补全）

随着AI LLM 的发展，出现了很多以 VSCode 为平台的插件产品或者封装产品，提供方便的 Tab 代码补全，或者是行间预测。开发人员选择是否接受预测内容；

此时属于辅助编程；

1.3 AI 氛围编程 (VibeCoding)

这就是一个被创建的名词，意思是`在聊天的氛围中，把代码开发完成`。目前很多AI编程工具都已经支持了这种方式，确实开发效率会有所提升，但是也有一些问题涌现出来。

常见的 Vibe Coding 的模式氛围两种：

1. 基于代码编辑器的开发模式：以VSCode为平台的工具，或者是 JetBrains 插件方式；比如常见的 Trae AI, 和 Qoder 等

2. 基于纯聊天工具的开发模式：如 Goose 那种纯聊天的模式；

目前从我个人的使用体验来说，更加倾向于编辑器模式，因为纯聊天方式没有程序员那种控制万物的感觉。

在使用上 Qoder 更加适应旧有项目，因为包含的 Repo Wiki 这种功能就非常适应原有项目的文档补写

而 Trae 在Agent编码能力以及重构代码能力上感觉不错。我们借助 Trae 以及提示词工程，已经在旧有百万行代码项目中实现特定功能解耦等操作。

1.4 基于Spec的AI编程

这也是一个概念，就是现在的AI编程工具从空白创建一个新的工程时，都会按照大模型自己的喜好来创建。并不能完全符合企业的开发模式。

举个最常见的例子：当我要求使用 Angular 20 创建一个前端项目，并且内置包含 TailwindCSS 4.0 时，部分编程工具将会陷入操作循环。

1. Angular 20 开发网站符合 TailwindCSS 4.0 直接使用 PostCSS 配置文件，省略了 tailwincss.conf.js；

2. 部分大模型只有 TailwindCSS 3.x 的记忆，上来就创建了 tailwindcss.conf.js，并且使用 TailwindCSS 最新版；

3. 然后编译不通过，就发现 ng b 的提示是需要使用 postcss，并且分析出 tailwincss 版本不合适，则直接删除了 config, 创建了 postcssrc, 然后把 TailwindCSS 降级成为 3.x；是不是有一种和学徒一起工作的感觉

发现编译失败，于是有自以为是的升级成 4.0 再删除 postcss。从而无限循环。越智能与自以为是

Spec编程就是，提前写好一堆规则、设计、或者限定文档，让AI在处理之前先按照规则处理

此处的工具如 AWS Kiro 就是支持这种模式，尤其在项目初创阶段，需要创建Spec文件作为后续操作的。可以从最开始的需求、设计、限定、进行创建，后续再进入辅助编程阶段。

2. 开发工作的影响

确实摸鱼的时间变多了、同一时间可以做多个项目了，公司项目和私活也不冲突了、项目周期还是没变。

实际上当开发速度提升，会导致后续的步骤阻塞，比如测试的压力会上升。程序员一路“接受/Accept”，导致代码可控性变差，只有在测试阶段才会发现问题。AI 真的可以进行测试吗？

因为项目类型的多样性，很多项目即使有自动化的单元测试，也还有很多需要进行人工测试的，比如安卓APP 的点击操作，两次点击时间过近，或者是拖拽等操作，一时间还是无法自动化处理。

所以大量的压力会交给测试阶段。

而且代码正确性的保证，谁来对程序员 Accept 的代码负责，是程序员还是 AI呢？

2.1 不想当架构师的程序员不是好厨师

随着AI编程的推进，我们会发现，编写文档/提示词/规则的需求会越来越多，项目启动有各种规范，在开发过程中也需要持续更新项目级的提示词，甚至是更小粒度的提示词。

分享一个在项目中进行老旧代码重构解耦的提示词操作：

## 重构设计

### 功能路由化 FeatureRouter

- 需要在功能同级目录中创建以 [FeatureName]Entry 结尾的文件，这个文件包含了功能的路由信息

- 在 AppDelegate 中的 initFeatureRouter 方法调用 Entry 中的 initFeatureRouter 方法

- 在 Entry 中实现 initFeatureRouter 方法，将功能的路由信息注册到 FeatureRouter 中

- 在 Entry initFeatureRouter 中，需要支持所有的参数，不能删除已经定义的参数设置

- initFeatureRouter 方法中，需要支持 present/push 两种启动方式

- 注册时使用的 featureKey 是功能的唯一标识符，在 FeatureRouter 中用于查找功能的路由信息, 采用 `feat.模块名.功能名或功能别名`

- 调用 FeatureRouter 的 registerRoute 方法注册路由信息

- 在 FeatureDispatcher.h 中定义对应的启动方法，并且在 FeatureDispatcher.m 中实现对应的启动方法

- 不可以将已经转换为FeatureDispatcher的功能再转换为普通的Controller调用

- 在代码中启动必须使用 FeatureDispatcher 中的启动方法, 不能直接调用FeatureRouter的open方法