在很长一段时间里，我对 AI 的使用目标其实非常简单：
能不能直接帮我把活干完？
不管是写代码、改文档，还是做技术方案，我最初的期待都是—— 一次输入，直接可用。
但随着使用频率越来越高，我反而越来越少这样用了。
⸻
一、单模型很好用，但它不适合长期协作
大多数技术人第一次用 AI，都会从 ChatGPT 开始。
原因很现实：
- 对话式交互，几乎零学习成本
- 代码、解释、示例一并给出
- 在“试一下”的阶段，体验非常好
如果你的需求是：
- 快速理解一个概念
- 验证某个 API 用法
- 写一次性脚本
单模型基本没有问题。
但当我开始把 AI 拉进持续性工作流时，比如：
- 多天维护同一个模块
- 长期输出技术内容
- 同一个问题反复演进
问题就慢慢出现了。
不是“写错”，而是不稳定。
⸻
二、真正让我警惕的，是“返工成本”
有一段时间，我发现一个很奇怪的现象：
AI 写代码的速度很快，但我 review 的时间越来越长。
常见问题包括：
- 逻辑看起来没问题，但边界条件模糊
- 命名风格前后不一致
- 示例代码能跑，但不适合真实工程环境
这时候我才意识到： 我不是在用 AI 写代码，而是在用 AI 写“初稿”。
而问题在于—— 我之前并没有把它当成“初稿工具”。
⸻
三、不同模型，其实更像不同“工程角色”
后来因为一些项目需要，我开始同时接触多个模型，比如 Claude、Gemini、Grok。
真正用下来之后，我的感受非常明确：
它们不是同一个工具的不同版本，而是偏好完全不同的“角色”。
非常工程化地说：
- 有的模型更适合做需求与上下文理解
- 有的模型在代码结构和可读性上更稳定
- 有的模型特别适合用来做反向验证和找问题
这时候，我第一次开始用“分工”的方式看 AI。
⸻
四、一次简单的流程拆分，改变了使用体验
真正的转折点，其实不是换模型，而是换思路。
我把一个常见任务拆成了几个步骤：
- 只让 AI 做结构设计，不写完整实现
- 换一个模型补充实现细节
- 再用第三个模型检查边界条件和潜在问题
- 最后由人决定是否合并
结果非常明显：
- 单次输出质量没有“神级提升”
- 但整体可控性明显增强
- 最重要的是：返工次数下降了
那一刻我才意识到：
AI 更适合参与流程，而不是接管结果。
⸻
五、多模型不是“高级技巧”，而是工程现实
很多人对多模型的第一反应是：
“这会不会太复杂？”
但如果你从工程角度看，其实非常熟悉：
- 多次校验
- 不同视角 review
- 降低单点失败风险
这和我们在代码里做的事情，本质上是一样的。
单模型的问题在于：
- 一次幻觉，可能污染整个输出
- 你很难判断它哪里是“确定的”
而多模型协作，本质是把不确定性拆散。
⸻
六、真正拖慢效率的，是“上下文切换”
当我接受多模型之后，一个新的问题立刻出现：
- 平台来回跳
- 上下文反复重建
- 注意力被严重打断
这时候，瓶颈已经不在模型能力，而在使用方式。
我后来做的事情很简单：
- 固定任务 → 固定模型角色
- 减少无意义的平台切换
- 把经验记录下来，形成可复用流程
我会把这些过程性的反思，整理成更系统的文字，放在公众号 【AI 效率引擎】 里，本质上更像是工程日志，而不是工具推荐。
⸻
七、AI 使用的终点，其实是“工程化心态”
现在再回头看，我会觉得 AI 使用大概会经历几个阶段：
- 能不能用
- 快不快
- 稳不稳
- 累不累
前两个阶段，模型能力决定上限； 后两个阶段，流程设计才是关键。
当 AI 开始真正参与工程，你迟早会意识到：
问题不在模型够不够强，而在你是否给了它合适的位置。
⸻
写在最后
如果你现在仍然习惯：
- 把完整需求一次性交给 AI
- 再反复修它的输出
这并不是错误，只是还在“试用阶段”。
但如果你已经开始关心：
- 输出是否可预测
- 流程是否可复用
- 使用是否可持续
也许可以试着换一个角度：
不要让 AI 成为“万能执行者”， 而是让它成为流程中最稳定的一环。
真正成熟的 AI 使用方式， 一定是工程化的，而不是魔法化的。
