前段时间我去QCon北京全球软件大会分享了一个专题：
为什么AI产品这么难做？
提示词工程被极大低估
AI 产品团队如何构建
谨小认知，仅供参考。写给所有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
