这段时间我一直在试几种 AI 工具。

刚开始也犯过一个错误：
看到一个新工具，就想让它从头到尾把项目做完。

比如直接丢一句：

帮我做一个英语培训小程序。

结果基本都差不多。
页面有了，功能也像是有了，但真要拿去交付，就会发现很多地方是虚的。

字段没想清楚。
后台没有真正的管理逻辑。
代码能跑一部分，但不好改。
说明文档看起来很完整，实际客户一问就露馅。

后来我才慢慢意识到，AI 工具不是越多越好，也不是哪个工具最强就用哪个。

真实项目里更重要的是：

每个工具放在它适合的位置上。

这篇就拿我后面准备长期写的一个项目来说：英语培训小程序。

先从里面最小的一个功能拆起：

试听课预约模块。

用户能看课程，填姓名、手机号、年级、意向课程、预约时间，提交之后，后台能看到预约记录，方便老师或课程顾问回访。

这个功能不复杂，但足够说明问题。

---

一、我不会一上来就让 Codex 写代码

以前我会直接让 AI 写：

帮我做一个英语培训小程序，包含课程展示和试听课预约功能。

这种写法看起来省事，实际上很容易把项目带偏。

因为“试听课预约”这五个字背后，有很多没说清楚的东西。

比如：

• 是学生自己预约，还是家长帮孩子预约？
• 年级是小学、初中、高中，还是四六级、成人英语？
• 用户是随便填时间，还是只能选老师空闲时间？
• 预约之后要不要短信提醒？
• 后台只看列表，还是要有回访状态？
• 课程顾问能不能备注？
• 后面要不要接支付？

这些问题没拆清楚，代码生成得越快，后面返工越多。

所以我现在的顺序是：

先让 ChatGPT 拆需求，再让 Codex 写代码。

Codex 更像一个执行代码的人。
你把任务写清楚，它效率很高。
你只给它一句模糊需求，它就会自己脑补一套系统。

脑补出来的东西，看着丰富，但不一定能交付。

---

二、ChatGPT：适合用来拆需求，不适合替客户做决定

在这个项目里，我一般先用 ChatGPT 做需求拆解。

比如我会这样问：

我要做一个英语培训小程序，第一阶段只做试听课预约模块。
请从真实交付角度，帮我拆一下用户角色、页面结构、表单字段、后台需要看到的数据，以及最小可用版本应该包含哪些功能。

它通常能把结构先拉出来。

比如：

• 用户角色：学生/家长、老师、课程顾问、管理员；
• 前端页面：首页、课程列表、课程详情、预约表单、预约成功页；
• 后台页面：预约列表、预约详情、回访状态、备注；
• 数据字段：姓名、手机号、年级、意向课程、预约时间、提交时间、回访状态；
• 第一阶段：先做课程展示、预约提交、后台查看预约记录。

这一步对我很有用。

不是因为 ChatGPT 一定比我懂业务，而是它能帮我把客户一句话拆开，避免我漏掉明显的字段和流程。

但这里有个坑：

ChatGPT 给出的东西不能直接当最终需求文档。

它会习惯性地把功能补完整。

你问一个预约模块，它可能顺手给你加上：

• 在线支付；
• 课程套餐；
• 老师排课；
• 优惠券；
• 学习打卡；
• 数据统计；
• 订单管理。

这些功能不是没用，而是第一版不一定该做。

真实外包项目里，功能越多，边界越容易失控。
客户预算没变，需求越加越多，最后吃亏的是交付的人。

所以 ChatGPT 在我这里的定位是：

帮我把问题拆开，但不替我决定做什么。

最后哪些功能进第一版，还是要我自己判断。

---

三、Gemini：适合看外面的东西，但不能照搬竞品

英语培训小程序这种项目，如果完全闭门想，也容易漏东西。

所以我会用 Gemini 做一些资料整理。

比如问它：

帮我整理英语培训机构小程序里，试听课预约功能常见的页面入口、表单字段、转化流程和后台管理需求。

它适合做这种横向整理。

比如它可能会提醒我：

• 首页通常要有明显的“预约试听”入口；
• 课程详情页也应该放预约按钮；
• 表单里最好有年级、学习目标、联系电话；
• 提交后可以提示“老师会在24小时内联系”；
• 后台最好有回访状态，比如未联系、已联系、已到店、已报名。

这些信息有参考价值。

但 Gemini 输出的东西有一个问题：
它容易把“行业里常见的功能”都整理出来。

你看完会觉得每个都该做。

这里就要克制。

竞品有直播课，不代表你第一版要做直播。
竞品有优惠券，不代表你第一版要做营销系统。
竞品有学习打卡，不代表你第一版要做学习平台。

我对 Gemini 的用法是：

用它补资料，不用它定方案。

竞品分析不是照抄别人，而是帮我确认：
我这个小版本有没有漏掉最基本的预约转化流程。

---

四、Codex：需求写得越清楚，它越好用

等需求边界定下来，再把任务交给 Codex。

这个时候就不能写一句“帮我做个小程序”。

要写得具体一点。

比如：

请实现一个微信小程序试听课预约模块。

页面包括：
1. 课程列表页
2. 课程详情页
3. 试听课预约表单页
4. 预约成功页

预约表单字段：
- 学生姓名
- 手机号
- 年级
- 意向课程
- 预约时间
- 备注

要求：
1. 姓名、手机号、年级、意向课程为必填；
2. 手机号做格式校验；
3. 提交成功后跳转到预约成功页；
4. 预约数据先用 mock 数据或本地存储模拟；
5. 代码结构要方便后续接后台接口。

这种任务给 Codex，效果会稳定很多。

它适合做的事情包括：

• 生成页面结构；
• 写表单逻辑；
• 做必填校验；
• 补手机号校验；
• 根据报错改代码；
• 调整页面样式；
• 帮你检查目录结构。

但它不适合做产品判断。

比如“这个预约模块到底要不要接支付”，这不是 Codex 该决定的。
“老师排课要不要放第一版”，也不是它该决定的。
“这个功能客户愿不愿意加钱”，更不是它能解决的。

我现在对 Codex 的定位很简单：

它是代码执行助手，不是项目负责人。

你给它的任务越具体，它越省时间。
你给它的任务越模糊，它越容易生成一堆看起来很完整、实际不好交付的东西。

---

五、Claude：适合整理交付文档，但要防止太模板化

项目交付的时候，代码不是唯一的东西。

尤其是做外包，最后最好能给客户一份简单清楚的说明。

比如：

• 这个版本做了哪些功能；
• 哪些功能没有做；
• 后台怎么查看预约记录；
• 表单字段分别是什么意思；
• 客户怎么验收；
• 后面如果要加支付、短信、排课，要另外评估。

这些内容我会让 Claude 帮忙整理。

我一般会这样写：

根据下面的小程序功能，帮我整理一份客户能看懂的交付说明。
不要写成宣传稿，只写已经完成的功能、使用步骤、注意事项和验收清单。
没有做的功能不要编。

Claude 的好处是长文整理比较顺。
一堆零散信息，它能整理成一份像样的文档。

但它也有一个毛病：
容易写得太正式、太完整。

比如它会写一些很漂亮但没什么用的话：

本系统致力于提升培训机构数字化管理能力……

这种我一般会删掉。

客户真正需要看的不是口号，而是：

• 点哪里；
• 怎么用；
• 哪里能看到数据；
• 什么情况算验收通过；
• 哪些东西不在本次范围内。

所以 Claude 适合做文档初稿，但最终还是要人工压一遍，把虚的句子删掉。

---

六、真实项目里，我一般按这个流程走

现在如果做一个“试听课预约模块”，我不会同时打开四个 AI 乱问。

我的流程大概是这样：

客户说需求
↓
我先判断这个需求大不大、有没有坑
↓
ChatGPT 拆用户、页面、字段、流程
↓
Gemini 补竞品资料和常见功能
↓
我筛选第一版范围
↓
ChatGPT 整理给 Codex 的开发说明
↓
Codex 写页面、表单、校验和数据逻辑
↓
我本地跑一遍，记录报错和问题
↓
Codex 根据问题继续改
↓
Claude 整理交付说明和验收清单
↓
我最后检查，确认能不能交付

这个流程看起来比“让 AI 一键生成项目”慢。

但真实项目不是演示视频。
客户不会因为你用了 AI 就降低要求。

最后要看的还是：

• 功能能不能跑；
• 数据能不能保存；
• 页面能不能用；
• 交付范围有没有说清楚；
• 后面改动会不会扯皮。

AI 能加速，但不能替你负责。

---

七、四个工具在项目里的分工

我自己的分工大概是这样：

工具	我主要拿它做什么	我不会让它做什么
ChatGPT	拆需求、理流程、写开发说明、检查方案	不让它替客户确认需求
Codex	写代码、改代码、补页面、处理脚本	不让它在需求模糊时直接开工
Claude	整理文档、交付说明、验收清单、润色文章	不让它替我验收代码
Gemini	查资料、做竞品整理、补行业常见功能	不照搬它给的竞品方案
人工	控范围、定取舍、测功能、做交付判断	不能省

这里面最关键的是人工。

有时候 AI 生成的东西看着没问题，但你真放进项目里，会发现很多小坑：

• 字段命名前后不一致；
• 表单校验漏了；
• 页面跳转路径写错；
• mock 数据和真实接口不好接；
• 文档写了项目没做的功能；
• 竞品分析给了一堆当前用不上的功能。

这些都需要人来兜底。

---

八、最容易踩的几个坑

1. 需求没拆清楚，就开始写代码

这个坑我踩过。

需求一模糊，后面代码就会乱。
尤其是小程序这种项目，页面、字段、流程、后台数据都要对上。

前面省十分钟，后面可能多改一天。

2. 把 AI 输出当最终答案

ChatGPT 的方案、Gemini 的竞品、Claude 的文档、Codex 的代码，都只能算初稿。

它们都需要检查。

尤其是接单项目，不能因为“AI是这么写的”就直接交给客户。
客户只会找你，不会找 AI。

3. 功能越做越多

AI 很容易帮你把项目补得很完整。

但完整不等于适合交付。

一个 1000 元的小单，做成 1 万元系统的范围，最后一定出问题。

所以我现在会先问自己一句：

这个功能是不是第一版必须做？

不是必须，就先放到后续版本。

4. 文档写得太满

交付文档不是越漂亮越好。

写了没做的功能，后面就是坑。
写了“支持后续扩展”，客户可能会理解成免费扩展。
写了“完整后台管理”，客户可能会要求更多管理功能。

所以文档要清楚，但不能乱承诺。

---

九、我现在对 AI 工具的理解

以前我会问：

哪个 AI 工具最好用？

现在我觉得这个问题没那么重要。

更重要的是：

哪个环节该用哪个工具？
这个工具输出后，谁来检查？
最后能不能变成交付物？

如果只是自己玩，怎么用都行。

但如果要做真实项目，尤其是想接单，至少要留下这些东西：

• 需求确认；
• 功能清单；
• 页面结构；
• 字段表；
• 可运行代码；
• 使用说明；
• 验收清单；
• 修改记录。

这些东西不一定每次都很复杂，但必须有。

因为客户最后买的不是“AI生成过程”，而是一个能用、说得清、出了问题能定位的结果。

---

十、这篇文章的结论

这几个工具，我现在会这样用：

ChatGPT：帮我把项目想清楚
Gemini：帮我看看外面怎么做
Codex：帮我把明确的功能写出来
Claude：帮我把交付说明整理清楚
人工：负责判断、测试、取舍和最终交付

AI 工具不是替你做项目。
更准确地说，它们是在项目流程里帮你省掉一部分重复劳动。

真正决定项目能不能交付的，还是人。

下一篇我准备继续写：

AI接单不是一键生成，而是把项目拆成交付流程

会从客户需求、范围控制、报价、验收和交付清单几个角度，拆一下一个小项目到底怎么从“客户一句话”变成“能交付的东西”。