前言

这两年，AI 编程工具已经不只是“帮你补全几行代码”了。
如果只是把它当成一个高级代码补全器，其实有点低估它的价值。

在我的实际开发过程中，我更愿意把 Codex、Claude Code 这类工具，当成一种 工程协作助手。
它们能参与的，不只是代码生成，还包括：

• 需求拆解
• 方案分析
• 代码生成
• 重构优化
• 接口联调
• 测试用例补全
• 文档整理

也就是说，AI 真正提高的，不只是“写代码的速度”，而是 从需求到交付的整体效率。

这篇文章就结合我自己的使用方式，以 Codex 为例，聊聊我是怎么做 AI 辅助开发 的。

---

一、我理解的 AI 辅助开发，不是“让 AI 替我写代码”

很多人对 AI 编程工具的第一印象是：

“哦，就是帮我写代码更快一点。”

这没错，但还不够全面。

在真实项目里，开发慢很多时候并不是因为“手敲代码慢”，而是因为下面这些事情太耗时间：

• 需求不清晰，要来回确认
• 新模块看不懂，上手成本高
• 改旧代码怕出问题，不敢动
• 联调阶段问题多，定位慢
• 测试和文档总是最后才补
• 遇到非主栈需求，切换成本大

所以我现在更愿意把 AI 辅助开发理解成：

让 AI 帮我减少重复劳动、降低上下文切换成本、加快从需求到交付的落地过程。

也就是说，AI 不只是“写代码工具”，而是一个参与工程流程的协作对象。

---

二、为什么我会用 Codex 这类工具

以 Codex 为例，它对我最有价值的地方，不是“会写代码”，而是它能参与到更完整的开发流程里。

我在实际使用时，最看重它这几个能力：

1）能帮我快速理解陌生代码

很多项目不是从 0 到 1，而是在老项目、旧模块上做迭代。
这种时候，最浪费时间的不是实现，而是：

• 调用链不清楚
• 模块职责不清楚
• 改动影响范围不清楚

这时候让 Codex 帮我先看结构、捋调用链、分析改动点，效率会高很多。

---

2）能帮我做需求拆解

有些需求不是难在代码，而是难在“第一步到底该怎么做”。

比如一个功能看起来不复杂，但真正开始做时会发现：

• 要改哪些文件？
• 先改后端还是先改前端？
• 哪些地方有连锁影响？
• 测试要怎么补？
• 边界场景有哪些？

如果这些问题自己一点点摸，时间其实耗得很快。
这时候让 AI 先帮忙拆需求，能明显减少试错。

---

3）能辅助我快速处理非主栈需求

这个对我来说很重要。

比如你主栈是 C++/Qt，但业务里突然来了：

• 一个 Python 脚本
• 一个小型管理后台
• 一个接口适配层
• 一段自动化工具逻辑

这些东西不一定难，但不熟的时候特别容易卡在细节上。
AI 工具在这里最大的价值，就是帮你更快从“不会”进入“能做出原型、能跑通业务”的状态。

---

三、我平时怎么用 Codex 做需求拆解

我现在很少一上来就直接说：

帮我写这个功能。

因为这种提问方式，AI 很容易直接冲进代码细节，结果写出来的东西和项目实际结构不一定匹配。

我现在更常用的方式是，先让它做分析。

比如我会这样提问：

先不要写代码，请先基于当前项目帮我分析：
1. 这个需求最可能涉及哪些模块和类
2. 哪些文件需要改动
3. 可能的实现步骤是什么
4. 有哪些风险点和边界条件
5. 建议补哪些测试

这样做的好处非常明显：

• 我先拿到的是“实施路线图”
• 能先知道影响范围
• 可以提前规避一些明显风险
• 后面再让 AI 生成代码时，方向更稳

说白了，先分析，再生成，效果通常比“直接生成”好很多。

---

四、代码生成阶段，我最看重“带约束生成”

我发现很多人用 AI 写代码，最大的坑不是生成不出来，而是生成出来的代码 不贴合现有项目。

最常见的问题包括：

• 命名风格不一致
• 分层不一致
• 引入了项目里根本不用的库
• 逻辑能跑，但不符合现有架构
• 重复造轮子，没有复用已有模块

所以我现在在让 Codex 生成代码时，会明确加很多约束。

例如我会这样写：

请基于当前项目风格实现这个功能：
- 沿用现有 service / repository 分层
- 不要引入新框架
- 复用已有 DTO 和工具函数
- 保持当前错误码风格
- 优先做最小改动
- 输出前说明准备修改哪些文件

我自己的体会是：

AI 代码生成不是越开放越好，而是约束越明确越好。

因为工程开发不是写 demo，最重要的是能不能融入现有系统。

---

五、AI 最让我受益的地方，其实是重构和代码梳理

如果只把 AI 用在“新功能生成”上，我觉得其实还没用透。

在真实项目里，我更常把它用在：

• 看旧代码
• 找重复逻辑
• 拆大函数
• 找职责混乱的类
• 给出低风险重构建议
• 梳理调用链和模块关系

比如我经常这样让它做分析：

请分析这个模块：
1. 找出重复代码和过长函数
2. 标出职责不清的类
3. 给出低风险的重构建议
4. 尽量保持外部接口不变
5. 如果重构，优先分小步实施

为什么这类场景好用？

因为新功能你自己大概率知道想做什么，
但面对一个历史遗留模块时，真正难的是：

• 快速建立整体认知
• 找到值得改的点
• 判断改动风险

而 AI 在“扫描结构、归纳问题、提出候选方案”这件事上，真的很适合。

---

六、接口联调阶段，AI 帮我省的是“排查思路”

接口联调阶段其实特别耗人。

很多问题并不是代码本身不会写，而是联调时会遇到各种情况：

• 参数传了但结果不对
• 字段命名不一致
• 响应结构和预期不匹配
• 某些边界值没处理
• 前后端理解不一致
• 日志看不出问题点

这时候我会让 Codex 帮我做两类事。

1）梳理调用链

请梳理这个接口的完整调用链：
入口 -> 参数校验 -> service -> repository -> 响应封装
并指出最容易出问题的环节

2）帮我做联调材料

请整理这个接口的：
- 请求示例
- 响应示例
- 错误场景示例
- 字段说明
- 可能的联调风险点

这种方式最大的价值，不一定是 AI 直接把 bug 修掉，
而是它能快速帮你建立 排查框架。

很多时候，开发最怕的不是问题复杂，而是没有排查方向。

---

七、测试用例和文档整理，特别适合 AI 来辅助

在日常开发中，最容易被拖到最后的，往往是两件事：

• 测试
• 文档

而这两类工作，其实特别适合 AI。

---

1）测试用例补全

我经常会这样问：

请基于这个函数/接口补充测试：
1. 正常路径
2. 边界路径
3. 异常路径
4. 当前实现最容易漏测的点
5. 给出最小可落地的测试方案

这样做的好处是：

• 测试覆盖更系统
• 容易发现漏掉的边界场景
• 能更快把“能跑”提升到“更稳”

---

2）文档整理

很多功能其实做完了，但别人接手时看不懂，或者几周后自己都忘了。

所以我也会让 AI 帮我整理一版结构化文档：

请把这个功能整理成文档，包含：
- 功能目的
- 核心流程
- 关键接口
- 配置项
- 限制条件
- 测试建议

我觉得这一点特别实用，因为它能把“开发完成”进一步推进到“可交付”。

---

八、跨技术栈快速落地，是 AI 辅助开发最有价值的能力之一

我越来越觉得，AI 辅助开发真正有含金量的地方，不在于会不会写几段代码，而在于：

能不能借助 AI，在非主栈需求里快速完成原型和业务落地。

比如你主要做的是 C++/Qt，
但业务里突然需要你做：

• 一个脚本工具
• 一个简单接口服务
• 一个前端管理页
• 一个自动化处理脚本

这类需求如果完全靠自己从头查资料、搭环境、试错，会很慢。
但借助 AI，你可以：

• 先快速理解技术栈基本结构
• 再生成一个可运行原型
• 再根据现有业务做增量修改
• 再补测试、补文档

我对这种能力的理解不是：

AI 替我学习了新技术

而是：

AI 帮我缩短了从“陌生”到“可交付”的距离

这一点，在业务开发里非常重要。

---

九、我现在对 AI 辅助开发的总结

如果要我用一句话总结我的使用方法，那就是：

先让 AI 帮我拆问题、建框架、找路径，再让它在明确约束下生成代码，最后由我来做判断、验证和收口。

也就是说，AI 最适合承担的是：

• 重复劳动
• 结构整理
• 初步方案
• 快速原型
• 测试补全
• 文档归纳

而开发者自己最重要的职责仍然是：

• 需求理解
• 架构判断
• 风险控制
• 质量把关
• 最终交付

所以我不认为 AI 会让开发变成“只会提问就行”。
相反，我觉得：

工具越强，对开发者的工程判断能力要求越高。

---

十、适合写进简历的一段总结

你可以把上面的内容，压缩成简历里更职业化的一段表述：

AI 辅助开发： 熟悉使用 Codex、Claude Code 等 AI 编程工具进行需求拆解、代码生成、重构优化、接口联调、测试用例补全与文档整理；能够结合现有项目结构和业务约束，借助 AI 快速完成方案分析与工程落地，具备较强的跨技术栈快速原型开发和业务功能交付能力，在保证代码质量和可维护性的前提下提升开发效率与交付速度。

---

结语

以前我觉得 AI 编程工具最大的价值是“省时间”。
现在我越来越觉得，它真正改变的是开发方式。

它让我把更多精力放在：

• 需求理解
• 方案设计
• 风险控制
• 质量把关

而把那些高频、重复、结构化的工作，交给更适合处理它们的工具。

所以在我看来，AI 辅助开发的本质不是“偷懒”，而是：

用更高效的方式完成同样甚至更高质量的工程交付。