做了几年传统软件开发，现在想往AI方向转，你最先碰到的困惑大概是：

“我学什么？模型是怎么接的？跟我以前做的事情差多少？”

这篇文章不聊大而空的概念，用一个真实的”智能客服”需求，带你把传统软件和AI应用在用户交互、技术架构、迭代方式、新问题这四个层面，逐一对比清楚。

一、同一个需求，两种做法

假设产品经理想做一个”智能客服”功能。

传统做法：

1. 产品写PRD，定义所有能问的问题类型和对应回答
2. 工程师把每个问题和答案写成if/else或查数据库
3. 用户点击菜单或输入关键词，命中就返回答案
4. 没命中的问题，跳转人工客服

代码大概长这样：

defhandle_question(user_input):if"退款"in user_input:return"请提供订单号，我们为您处理退款"elif"物流"in user_input:return query_logistics(user_id)else:return transfer_to_human()

AI应用做法：

1. 产品写一个System Prompt，描述客服的身份、语气、知识范围
2. 把公司的客服知识库接入RAG（检索增强生成）
3. 用户直接用自然语言提问，模型理解意图并生成回答
4. 回答质量靠Evals（评估体系）持续监控和优化

代码的核心变成了：

defhandle_question(user_input):    context = rag_search(user_input)  # 从知识库检索相关内容    response = call_llm(system_prompt, context, user_input)return validate_output(response)     # 校验输出是否合规

看到差异了吗？

传统做法，逻辑完全由你写死——能答什么、怎么答，都是预设的。AI应用做法，你把”判断”交给了模型——它自己理解意图、自己组织语言，你只负责划定边界和校验结果。

二、用户交互：从”你选选项”到”你直接说”

传统软件的交互，本质是受限的。

用户能做什么，取决于界面上放了什么按钮、什么菜单。产品经理和工程师在前期把所有可能的操作设计好，用户只能在这些选项里选。

AI应用的交互，本质是意图驱动的。

用户说一句话，模型去理解它，然后决定怎么回应。界面可以只是一个输入框，用户用自然语言描述需求，模型生成结果。

这对技术人员意味着什么？

意味着你以前设计的”状态机”思维——用户当前在哪个页面、能点什么按钮、点了之后跳去哪里——在AI应用里部分失效了。用户不再走你设计的固定路径，而是用语言直接描述目标，模型帮你完成。

不是状态机没了，而是**状态机从”强制路径”变成了”可选引导”**。

三、技术栈：哪变了，哪没变

这是技术人员最关心的问题。直接说结论：

变了的地方：

没变的地方：

• 前端该会还是得会（聊天界面、流式输出展示都要做）
• 后端该会还是得会（API编排、权限控制、日志监控）
• 数据库该会还是得会（用户数据、对话历史、业务数据都要存）
• 部署该会还是得会（AI应用也是应用，该有的工程规范一样不少）

最关键的转变：

你以前花80%时间写的业务判断逻辑（比如”用户积分够不够””订单状态能不能取消”），现在有一部分可以交给模型来做。但你得学会怎么让模型做对——这就是Prompt工程和RAG要解决的问题。

四、迭代速度：从”发版”到”改句话”

传统软件的迭代流程：

写代码 → 提PR → Code Review → 测试 → 发版周期：几天到几周

AI应用的迭代流程（针对Prompt层面的调整）：

改System Prompt → 跑Evals测试 → 效果达标 → 上线周期：几分钟到几小时

注意，这里说的是只改Prompt的情况。如果你要改RAG的知识库、改应用层逻辑，那还是得走传统发版流程。

但哪怕只是Prompt的可分钟级迭代，也已经彻底改变了产品的演进速度。很多AI应用团队，一周内把一个功能的Prompt迭代几十个版本，这是传统软件开发难以想象的。

对技术人员来说，这意味着你影响产品效果的方式变了：以前是靠提PR，现在可以直接通过优化Prompt来提升用户体验，而且能快速验证。

五、新麻烦：传统软件没有的坑

AI应用带来了传统软件几乎没有的一类问题——输出不确定性。

1. 幻觉

模型可能一本正经地输出错误信息。在传统软件里，错误通常是因为代码有bug；在AI应用里，错误可能是因为模型”脑补”了不存在的信息。

解法不是改模型，而是在应用层加防护：

• 用RAG限定模型只能基于提供的知识库回答
• 对输出做合规校验，不合格就重试或降级
• 在界面上给用户明显的”AI生成”提示

2. 输出格式不稳定

你让模型返回JSON，它可能偶尔会多输出几句解释，导致解析失败。

解法：输出解析 + 重试机制，不能假设模型输出一定是你想要的格式。

3. Token成本

传统软件的运行成本几乎是固定的（服务器费用）。AI应用每行一次用户对话，都要消耗Token，成本随用量线性增长。

做AI应用，你必须时刻问自己：这个功能的Token消耗值得吗？能不能用更小的模型？能不能减少上下文长度？

六、给转岗技术人的一句话

转AI岗位，不需要从零开始学。

你已经会的前端、后端、数据库、部署，全部有用，而且是很重要的基础——AI应用也是应用，工程规范、代码质量、系统稳定性，一样都不能少。

你需要新增的能力是：

• Prompt工程：怎么让模型稳定输出你想要的结果
• RAG基础：怎么把私有知识库接给模型用
• Evals思维：怎么用评估体系替代传统QA
• 成本意识：每次模型调用都有真金白银的代价

这些新能力，不要求你有AI研究背景，不需要你懂Transformer原理（懂了当然更好，但不是必须），更像是给你原有技术能力体系，新增了一套工具和思维框架。

传统软件和AI应用，底层的差异没有大到让你”从头再来”。真正的变化是：你从”写逻辑的人”，变成了”设计约束、让模型在约束内发挥作用的人”。

这个转变，比你想象的容易。也可以比你想的有趣。

下一篇，我们会聊：AI产品经理和传统PM，工作方法到底差在哪？