转载小红书：AI产品赵哥
前言 🔖
大家好，我是 AI 产品赵同学，做这么多年的 AI 产品，遇到最多的问题就是：AI 产品经理需不需要懂代码？需不需要自己训练模型？
当然，这些问题没有标准答案，不过我个人建议还是要学一学 LangChain，试着自己写一些 AI 应用，这样我们会对大模型的边界有更深刻的理解。
其实，LangChain 没那么玄乎。抛开那些花里胡哨的名词，它本质上就是一套把大模型和外部世界连接起来的工具代码。
对于产品经理来说，你不需要自己去写底层库，但你必须理解它的逻辑架构。因为只有懂了它能做什么、不能做什么，你设计出来的 AI 产品才落地得了，才不会被开发怼回去。
我会把 LangChain 相关的内容，汇总起来陆续发出，在这里我们直接讲逻辑，讲功能，讲数据是怎么流转的。
今天是第一篇，我们来聊聊 LangChain 中最核心的三个组建：Model（模型）、Prompt（提示词）、Chain（链）。
搞懂这哥仨，你就能用 LangChain 搞出一些小规模的 AI 应用了。
一、Model（模型）：是对话，更是计算单元 🔖
很多初学者觉得 Model 就是 ChatGPT，就是个聊天框。但在 LangChain 的开发逻辑里，Model 是一个 输入文本、输出文本的函数接口。
LangChain 里的 Model 组件，主要解决了一个核心痛点：接口标准化的缺失。
市面上有 OpenAI、Anthropic、Google Gemini，还有国内的百度文心、阿里通义。每家的 API 调用方式都不一样。如果你的产品今天要从 GPT-4 切换到 Claude 3，开发人员可能要重写大量代码。
LangChain 的 Model 组件把这些差异抹平了。它定义了一套统一标准：无论底层用什么模型，上层的调用命令都是一样的。
🔹1.1 两类关键模型的区别
在 LangChain 中，Model 分为两类，这个区别对产品设计至关重要：
- LLMs（纯文本模型）：这是早期的 GPT-3 的模式。输入是一串字符串，输出也是一串字符串。它没有 “对话历史” 的概念，就是简单的文本续写。
- 输入：“北京的首都是”
- 输出：“中国。”
- Chat Models（聊天模型）：这是现在的 GPT-4、Claude 的模式。它的底层虽然还是文本续写，但在接口层面，它接受的是 消息列表（List of Messages）。
- 输入：[SystemMessage: “你是个助手”, HumanMessage: “北京哪有好吃的？”]
- 输出：AIMessage: “北京烤鸭不错…”
产品经理注意点：现在绝大多数新应用，都应该基于 Chat Models 进行设计。因为它支持 System Prompt（系统提示词），这对控制 AI 的人设、边界非常关键。
🔹1.2. 代码具象化（Python 示例）
作为产品经理，一定不要惧怕代码，这里我只写最关键的几行，你能看懂逻辑就行。
# 引入 LangChain 的 openAI 接口
from langchain_openai import ChatOpenAI
# 1. 实例化模型
# temperature=0 表示结果最确定，越接近 1 越随机
# model_name 指定具体版本
# openai_api_base、openai_api_key: 需要在.env中配置
chat_model = ChatOpenAI(temperature=0, model_name="gpt-3")
# 2. 直接调用（虽然能跑，但在实际工程中很少这么裸奔）
response = chat_model.invoke("给我的AI产品起个名字")
# 3. 打印结果
# 结果是一个对象，包含内容 content 和元数据 metadata
print(response.content)
🔹1.3. 经验谈：Model 层的参数陷阱
在产品设计文档（PRD）里，你必须定义清楚两个参数，开发往往懒得问你直接用默认值，最后效果不好就怪模型不行。
- 1．Temperature（温度）：控制随机性。做客服机器人、数据提取，必须设为 0，我们要的是准确和稳定。做创意写作、陪聊，可以设为 0.7 ～ 0.9。不要以为模型自己知道该严谨还是该活泼，这需要你来规定。
- 2．Max Tokens（最大长度）：控制输出的字数上限。防止模型发疯输出一大堆废话，消耗你的 Token 预算。
二、Prompt（提示词）：结构化管理的艺术🔖
既然模型可以直接调用，为什么 LangChain 还要搞一个 Prompt 组件？
因为硬编码（Hard Coding）是工程大忌。想象一下，你做了一个翻译功能的 App。如果你把提示词写死在代码里：”Please translate this to English:”。当你想要把目标语言改成法语，或者想优化一下提示词，开发就需要去改代码、重新部署。这效率太低了。
LangChain 的 PromptTemplate（提示词模板）实际上是一个字符串处理工厂。它把静态的指令和动态的用户输入分离开来。
🔹2.1. 提示词模板的构成
LangChain 提倡把 Prompt 拆解为三个角色消息，这直接对应 Chat Models 的结构：
- SystemMessage（系统消息）：这是产品的 “上帝视角”。例如：“你是一个资深的法律顾问，只回答法律问题，不闲聊。” 这部分内容通常由产品经理预设好，用户不可见。
- HumanMessage（人类消息）：这是用户的实际输入。例如：“合同违约怎么赔偿？”
- AIMessage（AI 消息）：这是为了给模型提供 “示例” 或者 “上下文”。你可以预设几轮高质量的问答，让模型照猫画虎（这叫 Few-Shot Prompting，少样本提示）。
🔹2.2. 代码具象化
这里我们展示一个带变量的模板，这才是工程化的写法。
from langchain_core.prompts import ChatPromptTemplate
# 定义一个模板，用 {variable} 挖好坑
template = ChatPromptTemplate.from_messages([
("system", "你是一个专业的{industry}翻译助手。"),
("human", "请将这段话翻译成{language}：\n{text}")
])
# 此时这只是一个模板对象，还没有填入内容
# 当用户操作时，我们再把变量填进去
prompt = template.invoke({
"industry": "医疗",
"language": "中文",
"text": "My headache is getting worse."
})
# 最终生成给模型的真实输入是:
# System: 你是一个专业的医疗翻译助手。
# Human: 请将这段话翻译成中文: My headache is getting wors
🔹2.3. 经验谈：Prompt 也是代码
在实际产品开发中，我建议产品经理把 Prompt 当作 “配置” 来管理。不要把 Prompt 散落在飞书文档或者口头沟通里。LangChain 甚至支持从专门的 Prompt Hub 拉取提示词。
你给开发的不仅是一段话，而应该是一个结构清晰的 Template 定义：哪些是死的，哪些是活的（变量）。特别是 Output Formatting（输出格式化）的指令，一定要写在 Prompt 里。比如：“请仅输出 JSON 格式，不要包含任何其他解释性文字。” 这点非常重要，我们在后面的 Chain 部分会细说。
三、Chain（链）：工作流的组装🔖
语言有了 Model 和 Prompt，单独用它们也能跑通。但现实中的 AI 应用往往没这么简单。一个最基础的业务流程通常是这样的：
- 1．用户输入内容。
- 2．程序把内容填入 Prompt 模板。
- 3．把完整的 Prompt 发送给 Model。
- 4．程序处理 Model 返回的字符串，转成 JSON 或其他格式。
Chain（链）的作用，就是把这些独立的步骤，按照顺序串联起来，形成一个自动化的流水线。
在 LangChain 的新版本中，最重要的概念是 LCEL（LangChain Expression Language）。这是一种类似于 Linux 管道符的语法，很优雅。
🔹3.1. 核心操作符：Pipe（|）
LCEL 使用 | 符号来连接组件。A | B 的意思是：运行 A，然后把 A 的输出作为 B 的输入，运行 B。这就构成了数据流。
🔹3.2. 这里的第三个关键角色：OutputParser
在 Model 和 Prompt 之外，通常必须通过 Chain 引入第三个组件：OutputParser（输出解析器）。
模型吐出来的是一大段文本（String）。但你的后端代码（Python）通常需要处理的是结构化数据（Object/JSON）。
比如你想做一个 “情感分析器”，你希望模型返回 {"sentiment": "positive", "score": 0.9 }，而不是 “我觉得这句话情绪很积极…”。
OutputParser 负责把模型的 “人话” 强行转换成 “机器语言”。
🔹3.3. 代码具象化：构建你的第一条链
这是一个完整的、可运行的逻辑闭环。我们要写一个 “把用户输入转换成简短推文的功能。
from langchain_core.output_parsers import StrOutputParser
# 1. 准备 Prompt 模板
prompt = ChatPromptTemplate.from_template("请把这段文字改写成只有20个字的推文：{topic}")
# 2. 准备模型
model = ChatOpenAI(model="gpt-4")
# 3. 准备输出解析器
# StrOutputParser 的作用是自动把 API 返回的复杂对象中的 content 字段提取出来
output_parser = StrOutputParser()
# 4. 组装链条（LCEL 语法）
# 数据流向：字典输入 -> 填入模板 -> 发给模型 -> 提取文本文字串
chain = prompt | model | output_parser
# 5. 调用链条
result = chain.invoke({"topic": "LangChain 是一个非常强大的大语言模型应用开发框架"})
print(result)
# 输出结果直接就是字符串: "LangChain：强大的LM应用开发框架。"
# 没有多余的元数据，干干净净。
🔹3.4. 经验谈：Chain 的本质是解耦
为什么不用 Python 的 f-string 拼接字符串，然后直接调 API，非要用 Chain？
这涉及到可维护性。当你使用 Chain 时，这三个组件是热插拔的。
- 觉得 OpenAI 贵了？只替换 model 变量，把 ChatOpenAI 换成 ChatAnthropic，其他的 Prompt 和 Parser 逻辑完全不用动。
- 觉得输出格式不对？只在最后加一个 JsonOutputParser，前面的逻辑也不用动。
Chain 赋予了 AI 应用模块化的能力，这对产品迭代至关重要。
四、实战拆解：一个真实的产品案例🔖
为了让你彻底明白这三者如何协作，我们来复盘一个我做过的真实小功能：用户评论自动打标机。
需求：后台收到用户反馈，AI 自动判断情绪（正面 / 负面），并提取出用户提到的核心功能点，生成 JSON 存入数据库。
如果不适用 LangChain，开发人员需要写大量正则表达式来清洗模型返回的数据。使用 LangChain，逻辑如下：
🔹第一步：定义 Prompt
我们告诉模型：你是一个数据分析师。你的任务是分析评论。这里的关键是，我们在 Prompt 里注入了格式要求。
template = """
分析用户的以下评论:
{comment}
请输出 JSON 格式, 包含两个字段:
1. sentiment: "positive" 或 "negative"
2. features: 一个列表, 包含提到的功能点
"""
prompt = ChatPromptTemplate.from_template(template)
🔹第二步：选择 Model
模型选择可以根据你项目对输出质量的要求，当然，越贵的模型越好，这是毋庸置疑的。这里我们的模型，选择 gpt-4 或 gpt-3.5-turbo，设置 temperature=0 保证格式稳定。
🔹第三步：定义 OutputParser
我们需要模型返回的是 Python 字典，而不是字符串。LangChain 提供了 JsonOutputParser。
🔹第四步：构建 Chain 并执行
# 假设 chain = prompt | model | json_parser
user_input = "你们的导出功能太慢了，但是界面真的很好看！"
data = chain.invoke({"comment": user_input})
# 此时 data 已经是标准的 Python 字典/JSON
# data = {
# "sentiment": "mixed",
# "features": ["导出功能", "界面"]
# }
这个过程中：
- Prompt 负责把自然语言需求和格式约束定义好。
- Model 负责进行逻辑推理和提取。
- Chain 负责连接输入输出。
- Parser 负责把结果清洗成数据库能直接用的格式。
这就是一个标准的 AI Native 功能的开发范式。
五、总结一下吧🔖
读到这，你应该能建立起这样的认知：
- Model 是底层的发动机，提供算力，但不管业务逻辑。
- Prompt 是业务逻辑的载体，决定了模型怎么干活。
- Chain 是传送带，把原材料（用户输入）经过加工（Prompt），送到发动机（Model），最后包装成成品（Parser 输出）。
作为纯产品经理，你不需要学会写 chain = prompt | model 这行代码，但当你给开发提需求时，你的思路路径应该是：
- “这个功能，System Prompt 我们怎么设定？”
- “这里需要几个变量输入？”
- “模型输出必须是 JSON 格式，字段定义是 XYZ。”
- “这个环节我们要不要拆成两个 Chain 来做？”