做AI产品两年，我得出的实操经验

推荐语

AI产品实操经验分享，带你深入了解AI产品构建的难点和技巧。

核心内容：
1. AI产品构建的难点与挑战
2. 提示词工程在AI产品中的作用与重要性
3. 工程师视角下的AI产品实操案例分析

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

前段时间我去QCon北京全球软件大会分享了一个专题：

谨小认知，仅供参考。写给所有AI路上的朋友们。

✨一、为什么AI产品这么难做？

让我们轻松的聊聊AI与产品

认知截止到20250411

A Joke：先从一个笑话开始，你能看懂吗？

如果你知道每一条背后的原因，那么恭喜你上道了！

所以为什么AI产品这么难做？

AI时代的产品和传统的产品不一样的是什么？

基础流程是什么？

所有流程可枚举全部已知

• 流程的自动化的定义是什么，什么流程可以被SOP化，就可以做成产品。那AI产品，首先肯定是产品，其次它还会完成以前人类才能完成的某种任务。这个任务如果需要AI完成，那就发生了范式转移

你得帮用户做出来这个任务。

举个例子，Cursor

Cursor是我认为2024年最好的AI产品

它解决了三端关系。

Cursor Team解决了如下问题：

• 任务分级：根据给AI的执行权限不同的不同可控颗粒度的任务
• 帮用户完成了任务：每个任务/功能在用户还没来之前就已知该任务如何完成（Coding，且无论语言，无论项目）
• 交互方式：每个任务/功能与人协同的人机交互方式
• 
  

✨二、提示词工程被极大低估

认知一：Prompt也是代码，所以要测试。

尊重prompt，同代码享受同等权利，需要git diff

需要对prompt单独进行版本管理

Prompt也是代码，但有区别？

LLM和函数很类似，它们都是实现某个“计算”的节点。

但它能提供比传统函数能做的更多的事情，提供“智慧类型”计算。

它可以接受非结构化的数据，经过推理，输出非结构化/结构化的数据。

Prompt也是代码，如何测试……？

函数，我们在运行前，通过IDE或者单测即可完成功能正确性校验。

LLM怎么测试呢？

如果你只是让它完成传统函数的任务，也很好测试，可以使用function call 加上单测。

比如加法任务，只让它输出结果，可以做正确性校验。

但大概率你让LLM做的事情是非结构化的。

所以Prompt的好坏怎么测？

一：格式正确性

使用function call / Json mode确保输出格式不出错

任何LLM相关的调用，都使用pydantic严格校验

二：功能Baseline

输出内容，通过batch evaluation进行校验。

三：人工评测结果

模型的上限，还是取决于人对于结果的要求有多高。

Baseline只是保证功能正常运行，上限在于“人”

四：放权

模型可能比你想象中的更强，不要限制它的思考方向，思考内容，knowhow，把prompt当成一种容器，你只是为模型提供必要的信息，而不是教它如何思考。

总结一下，Prompt也是代码，所以要测试。

认知二：AI产品就是基于“给模型提供上下文”出发开始的

首先，不要发现模型做不对任务，就觉得它有问题。接下来以Text2SQL为例。

做产品的人需要知道这个任务完成本身需要什么上下文，并且努力为模型提供出来。你并不需要那么多Prompt技巧，而是努力为模型提供更多的“必要信息”。

你会发现跟人很像。把它当成实习生，你也需要给实习生上下文。

对于大部分业务场景而言，你不需要“神级Prompt”（如下图），你需要的是对业务的熟悉程度。把业务knowhow沉淀成Prompt。

一件事情上下文到底是啥？寻找root变量的过程。

认知三：如何面向未来进行设计，避免被模型更新所冲击？

Manus画的AI Model Timeline

模型每天都在更新，我怎么设计提示词和架构？

模型更新之后，提示词会不会失效了呢？

每个模型有什么不同的脾性？

模型越来越智能，未来还需要复杂的提示词吗？

……

Slow Down，别焦虑。

打不过就加入：用最好的模型的API创建应用。除非自己顺手能训练模型。

Flow Engineer：什么时候拆分任务，什么时候合并任务？

我的体感（纯经验，没有数据支撑，knowledge截至20250321）

如果不知道用啥，就先试试Claude

通用类型任务：Claude-3.5-Sonnet / Claude-3.7-Sonnet

强推理任务：Claude / Gemini 2.5 Pro

中文语言任务：DeepSeek

图片多模态任务：Claude / Gemini / 阶跃

视频多模态任务：Gemini

简单任务：Gemini Flash （省钱）

中文B端本地任务：Qwen

可能的Bad Case:

DeepSeek指令遵循弱

Gemini flash幻觉严重

……

当然GPT4o生图很好！

Flow Engineer

“Flow Engineering” 是一个最近越来越受欢迎的术语。它第一次被提及作为术语是在 CodiumAI 关于 AlphaCodium 的论文中，他们在论文中使用流工程来产生关于编码问题的最新结果。

推荐看一遍Langgraph的ipynb examples

Flow强调的是用整体系统设计去完成任务

多节点设计，每个节点去实现单一任务。

单一任务简单可靠，一定在LLM可实现范围之内。

当一个任务太难的时候，就拆成两个任务去做。

好像有点像dify/Coze的意思？

对，但不全对。不要忘了传统代码的能效。

你并不需要全部节点都是LLM，你也可以组合function和LLM。

所以推荐使用Dify/Coze验证原型，写代码用LangGraph搭建实际应用。

当模型更新后，就合并任务。

在设计Flow的时候，不需要拘泥于优化一个节点的LLM Prompt。

因为模型推理能力不够，大概率三个月后就够了。不需要过度设计。

用几个小的task拆解后完成任务，等模型更新后把整个大任务交给新的模型。

总结一下，Prompt Engineer的认知

✨三、AI 产品团队如何构建

认知一，首先你得成为“创作者”

Cursor很厉害，也最先落地：

• 懂AI的本来就是程序员。团队懂Coding。
• 团队知道如何拆解任务，每一个任务如何写Prompt的knowhow，团队很清楚。
• 模型Coding能力已经阶跃（Claude3.5） 文本模态Coding任务是最擅长的。

但还有如此多的业务场景，等着创造。

认知二，快速做出Demo最重要

AI产品最后长成什么样子，已经是无人定义清楚的事情了。

只有当把所有的要素及其，做出一个demo，你才知道这是什么感觉的产品。

认知三，产品/开发的界限模糊

以前的开发模式，是产品、研发。现在可能变成了一个紧密的团队一起调prompt。

最好是产品/全栈能自己调试prompt。

AI产品需要紧密配合的团队，一起设计架构。

Prompt需要沟通能力，业务能力。代码需要研发能力。

Prompt + 代码是团队之间才能做的事情。

一起创作。

写在最后

我们正在见证新范式的出现，很幸运。

谨小认知，仅供参考。

认知截止到20250411

我正在做的AI产品，也即将发布。

AI视频剪辑工具

尽情期待！