做AI产品两年，我得出的实操经验 作者 | 宁晨然 前段时间我去 QCon 北京全球软件大会分享了一个专题： AI 时代的新范式：如何构建 AI 产品？ 观众反响特别好，想着要不把分享的内容公开出来，所以整理了这篇文章。本篇内容是对我过去两年时间，做了无数个 AI 产品 demo 的一个阶段性的总结，主要聚焦这三个方面的经验： 为什么 AI 产品这么难做？ 提示词工程被极大低估 AI 产品团队如何构建 谨小认知，仅供参考。写给所有 AI 路上的朋友们。 简单自我介绍，我是 ONE2X AI全栈工程师，AI 视频剪辑效果负责人。负责 ONE2X 的 Medeo（AI 视频剪辑工具）的视频自动化制作工作流全流程搭建、工具产品的设计及创新 AI 应用场景探索。 22 年 11 月 GPT 刚出后，就开始尝试做各种各样的 AI 产品，23 年年中毕设做的是 AI 情感陪伴、暑假在做企业知识库 Chatbot 智能客服、23 年年底到 24 年年中在大厂做低代码编排 AI 工具和智能医疗、24 年年中到现在在 AI 创业工作做 AI 自动剪辑。途中还做过大大小小的 project，包括 AI 写遗嘱、AI Agent做动画等等……也算是积累了很多实操经验了。 为什么 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，你才知道这是什么感觉的产品。 我做的大大小小的 demo 认知三，产品 / 开发的界限模糊以前的开发模式，是产品、研发。现在可能变成了一个紧密的团队一起调 prompt。 这是我在公司内部做的后台，支持任何人追溯每次 LLM 调用，并且重新调试 prompt。 最好是产品 / 全栈能自己调试 prompt。 AI 产品需要紧密配合的团队，一起设计架构。 Prompt 需要沟通能力，业务能力。代码需要研发能力。 Prompt + 代码是团队之间才能做的事情。 一起创作。 写在最后我们正在见证新范式的出现，很幸运。 有了 AI，才有了年轻人的机会，所以我非常感激能在这个时代能有这么多有意思的事情。 谨小认知，仅供参考。 认知截止到 20250411