前两篇文章，我们聊了传统软件和AI应用的本质区别，也聊了AI产品经理的工作方法变化。

这篇文章把视角切到你作为开发者/技术负责人最关心的问题上：

我以前的技术栈还能用吗？AI应用开发到底在做什么？和以前比，核心差异在哪里？

直接说结论：

AI应用开发的本质不是「多学了几门新技术」，而是「换了一套开发范式」。

你以前积累的所有工程经验依然有用，但你做产品的方式——写什么、测什么、怎么迭代——已经完全不同了。

下面逐一拆解。

一、从”写逻辑”到”写约束”：代码的本质变了

传统应用开发的代码，本质上是你替机器做决策。

用户下单 → 检查库存 → 扣减库存 → 创建订单 → 返回结果

每一步的逻辑都是你写的，机器照着执行，出错了是代码有bug，修复就好。

AI应用的代码，本质上是你把决策权交给模型，只给它划边界。

以一个文档问答机器人为例：

# 传统开发：每一步都是你写的defanswer_question(user_question):    sql = build_sql_from_question(user_question)  # 你写的SQL生成逻辑    result = db.execute(sql)                      # 你写的查询逻辑return format_result(result)                  # 你写的格式化逻辑# 逻辑100%由你控制，输出100%可预测# AI应用开发：你只定义约束，模型负责推理defanswer_question(user_question):    docs = vector_db.similarity_search(user_question)  # 检索相关文档    context = format_docs(docs)                        # 组装上下文    response = llm.generate(                           # 模型负责"理解+推理"        system_prompt="你是文档助手，只基于提供的文档回答...",        context=context,        question=user_question    )return validate_and_parse(response)                # 你只做输出校验

这不是”少了什么”，而是角色变了。

以前你是决策者，现在是裁判——你决定什么算赢、什么算犯规，然后让模型在规则内发挥。

这个转变带来的连锁反应，体现在开发流程的每一个环节。

二、开发流程对比：完全不同的四个环节

1. 写什么

传统开发：写业务逻辑。

你要处理的是”当用户做了X，系统应该Y”。每个if分支、每个异常处理，都是你在替系统做决策。

AI应用开发：写约束描述。

你要处理的是”当用户做了X，我希望系统在Y条件下输出Z”。不是你在做决策，而是你在告诉模型”在什么边界内做决策”。

最典型的例子——做一个”礼貌拒绝”功能：

传统开发：if user_ask about_unrelated_topic:return"抱歉，该功能无法回答此问题"AI应用开发：# System Prompt里写- 只回答与[限定话题]相关的问题- 不在话题范围内的问题，回复：「抱歉，这个问题超出了我的服务范围，  我可以帮您处理XX、YY、ZZ相关的问题，是否需要我协助？」- 语气：礼貌、简洁、专业- 不使用以下话术：[列举不可用的话术]

你的产出从”if/else逻辑”变成了”行为边界描述”。这不是换语言，是换思维。

2. 测什么

传统开发：测逻辑覆盖。

单元测试跑覆盖率，确保每个分支都被执行过。边界条件有没有覆盖？异常路径有没有处理？这些都能测出来。

AI应用开发：测输出质量。

模型不会”走错分支”，但会”说错话”。你测的不是代码逻辑，而是模型输出的质量。

以一个翻译功能为例：

# 传统测试：测代码逻辑deftest_translate_chinese():    result = translate("你好")assert result isnotNone# 逻辑：非空assert isinstance(result, str)     # 逻辑：字符串类型# 断言覆盖了，测试通过# AI测试：测输出质量（Evals思维）deftest_translate_quality():    test_cases = load_test_cases("fixtures/translation_cases.json")# 每个case包含：输入原文、参考译文、评估维度打分规则    results = batch_translate(test_cases)    scores = evaluate(results, dimensions=["语义一致性",      # 翻译是否准确传达原意"语言流畅度",      # 目标语言是否自然"术语准确性",      # 专业术语是否正确"格式规范性"# 标点、换行是否合规    ])assert scores["语义一致性"] >= 0.9# 90%以上达标assert scores["格式规范性"] == 1.0# 格式问题零容忍

传统测试的答案是布尔值：通过或不通过。AI测试的答案是一组指标：各维度得分是多少，距离上线标准差多少。

3. 怎么判断”做完了”

传统开发：所有bug修完，测试全部通过。

这意味着功能符合需求规格，可以上线。

AI应用开发：评估指标全部达标，才能上线。

但这里有一个关键区别：AI应用没有”bug”的概念，只有”效果不达标”。

# 传统：bug修复完了 = 做完了if remaining_bugs == 0and test_coverage >= 80%:    ready_to_release()# AI应用：效果达标了 = 做完了defis_ready_to_release():    evals_results = run_evals()return (evals_results["准确率"] >= 0.92and evals_results["幻觉率"] < 0.05and evals_results["格式合规率"] == 1.0)# 三个指标同时达标，才算完成

注意”幻觉率 < 0.05″这一项。AI应用里，有些问题是无法彻底消除的，你只能把概率压到可接受的范围内。这意味着你必须在产品层面做兜底：AI回答错了怎么办？有没有人工复核机制？这些是传统开发里不需要考虑的问题。

4. 怎么迭代

传统开发：改代码 → 提PR → Review → 测试 → 发版。

一次变更周期通常是几天，频繁发版有风险，所以要憋一个版本一起发。

AI应用开发：改Prompt → 跑Evals → 验证效果 → 生效。

如果你只是调整Prompt（不改底层逻辑），整个流程可以压缩到几十分钟。核心原因是你有了一套自动化的质量验证机制（Evals），不需要人工回归测试。

# 传统迭代iteration_time = 开发(2天) + PR(1天) + Review(1天) + 测试(1天) + 发版(1天)# ≈ 1周/次# AI迭代（仅Prompt层面）iteration_time = 改Prompt(5分钟) + 跑Evals(30分钟) + 验证(10分钟)# ≈ 1小时/次，快了40倍

但要强调一句：AI的快速迭代必须有Evals托底。没有Evals，你只是在盲目试错；有了Evals，你才能快速收敛。

三、技术栈全景：哪些还在用，哪些变了，哪些新增了

关键结论：

• 你以前学的前端、后端、数据库、部署，不是不用了，是在新体系里找到新的用法
• 新增的核心技能是：Prompt工程、向量数据库基础、Evals体系搭建
• 最大的变化不在”用什么工具”，在”用什么思维方式工作”

四、真实工作量：AI应用开发一天在做什么

这是最有参考价值的部分——从传统开发转到AI应用开发，你的一天会怎么过？

传统开发者的一天：

9:00  晨会，同步开发进度9:30  写新增功能的业务逻辑代码11:00 修Bug，处理用户反馈的边界情况14:00 Code Review，看同事的PR15:30 对接产品和测试，确认需求变更17:00 继续写代码，提交当日工作

AI应用开发者的一天：

9:00  晨会，同步效果指标（哪些功能最近幻觉率上升了？）9:30  分析Evals报告，发现"价格咨询"场景的一致性得分下降了10:00 优化System Prompt，在"价格咨询"场景加了更明确的回答边界10:30 跑Evals，验证优化效果——一致性从87%升到93%，达标11:00 调整RAG检索策略，补充一批高质量知识库文档14:00 处理线上用户投诉——AI在某个边界case答错了，加到测试集15:00 优化RAG的知识库chunk策略，减少上下文噪音16:00 新增功能的设计评审：评估用哪个模型最合适（效果vs成本）17:00 跑一次完整的Evals回归，确保所有指标稳定

看出核心区别了吗？

• 传统开发的时间主要花在”写逻辑”和”修Bug”上
• AI应用开发的时间主要花在”定义边界”、”分析效果”、”优化Prompt和知识库”上

代码量少了，但对问题边界的定义能力、对输出质量的敏感度，要求反而更高。

五、四个必须建立的新习惯

从传统开发转到AI应用开发，有几个思维方式上的习惯，必须刻意培养。

习惯一：从”我实现它”到”我约束它”

传统开发中，你的目标是覆盖所有情况，把每个分支都写清楚。

AI应用中，你不可能覆盖所有情况，模型的输出本质上是概率分布。你要做的是划定边界：什么可以发生，什么绝对不能发生，什么发生了要降级处理。

习惯二：从”测试覆盖率”到”效果指标”

看覆盖率，只能证明代码跑了；看效果指标，才能证明产品好了。

建立一套针对AI输出的指标体系，比写一百个单元测试更重要。

习惯三：从”bug可以修”到”风险必须控”

传统开发里，bug修完就没了。AI应用里，幻觉永远无法彻底消除——你能做的不是消灭它，而是把风险控制在可接受的范围内，并在产品层面做好兜底。

习惯四：从”一次性设计”到”持续调优”

传统开发：设计→实现→上线→下一个版本AI应用开发：上线→监控效果→发现gap→优化Prompt→再上线→持续循环

AI应用的上线不是终点，而是调优的起点。产品效果会随着Prompt优化、知识库扩充、测试集完善而持续提升。

六、技术负责人要回答的新问题

如果你带团队，或者要做技术决策，还要额外面对几个传统开发里没有的问题：

模型选型：用GPT-4o还是Claude 3.5？用本地部署的开源模型还是云端API？这不只是技术选型问题，也是成本和合规问题。

Prompt版本管理：传统代码有Git，Prompt的版本怎么管？不同环境的Prompt一致性怎么保证？

Token成本治理：一个用户对话平均消耗多少Token？月峰值成本是多少？怎么防止用户恶意触发高消耗调用？

数据安全：用户的对话数据会不会被用于模型训练？上传到第三方API的内容合规吗？

这些问题没有标准答案，但必须在你开始做AI应用之前，就想清楚怎么应对。

七、结语

说了这么多，回到最初的问题：AI应用开发到底和以前有什么不一样？

不是多了几门新技术。不是要推倒重来。是你做产品的方式变了：

• 从写决策逻辑 → 写行为边界
• 从测试覆盖率 → 测输出质量
• 从版本发布 → 持续调优
• 从消灭Bug → 控制风险

这套新范式，对有经验的老开发者来说，最大的挑战不是”学不会”，是忘掉旧习惯、建立新直觉。

你积累的所有工程经验——架构思维、质量意识、系统观、用户视角——依然是你最核心的竞争力。只是现在，你用它们来约束模型，而不是编写流程。

这个转变，值得认真对待。但也完全不必恐惧。

你比你想象的，更接近AI应用的开发。