本文来自《AI 应用开发课程》月份 1 课程文档，已整理为网站文章版本。
1. 文档目的
本实验的目标不是证明 LangChain “一定更好”，而是训练你做客观比较：
- 哪些地方更省代码
- 哪些地方更清晰
- 哪些地方被隐藏了
2. 推荐对照对象
选择一个已经完成的任务，例如：
- 需求总结
- commit message 生成
- 待办项抽取
然后分别实现：
- 纯 API 版本
- LangChain 版本
3. 对照维度
| 维度 | 纯 API | LangChain |
|---|---|---|
| Prompt 组织 | 手动拼字符串 | PromptTemplate |
| 调用链路 | 手动逐步调用 | LCEL 组合 |
| 输出解析 | 手动 json.loads + Pydantic | Parser 组件 |
| 工具抽象 | 自写注册表 | Tool 适配层 |
4. 你必须回答的问题
- 哪种实现更容易读？
- 哪种实现更容易调试？
- 哪种实现更容易替换其中一个组件？
- 哪种实现更容易让初学者误以为“框架自动帮我做了很多事”？
5. 验收要求
最终你要输出一份简短对照笔记，至少包含：
- 两种实现的核心代码结构
- 你的优缺点判断
- 哪种方式更适合月份 1 当前阶段
6. 推荐结论方向
对于月份 1，大多数情况下会得到这样的结论：
- 纯 API 更适合理解底层
- LangChain 更适合理解组件抽象
- 两者都应该会，但学习顺序应先纯 API 再框架
7. 如何把这份对照实验真正做成“有结论”的实验
建议你不要只写“我觉得 LangChain 更简洁”，而是明确比较：
- 哪一版更容易解释给别人听
- 哪一版更容易单步调试
- 哪一版更容易替换 Prompt
- 哪一版更容易替换输出解析逻辑
- 哪一版更容易让初学者失去底层理解
只有把这些维度写出来，实验结果才真正有价值。
8. 一个推荐的结论模板
你可以按下面结构记录结论：
任务说明
本次对照的是哪条链路，例如“研发任务总结”。
纯 API 版本优点
纯 API 版本缺点
LangChain 版本优点
LangChain 版本缺点
结论
这一条链路在月份 1 更适合哪种写法，为什么。
9. 本章在研发助手项目中的位置
这份对照实验的价值，不只是帮助你学会 LangChain。它还会帮助你在第 4 周决定：
- 综合项目哪些部分继续保持原生实现
- 哪些部分值得引入 LangChain 做更清晰的链路表达
10. 从本章过渡到下一章的桥接说明
LangChain 模块到这里收束完成。接下来会进入 07-综合项目-研发助手 模块，把月份 1 前面所有模块：
- Python
- 工程化
- LLM API
- Tool Calling
- FastAPI
- LangChain
真正汇总成一个可演示、可解释、可继续演进的项目。
11. 一个推荐的对照记录表
如果你真的要把这份实验做扎实，建议把“纯 API 版”和“LangChain 版”放到一张固定表里：
| 维度 | 纯 API 版 | LangChain 版 | 我的结论 |
|---|---|---|---|
| 可读性 | |||
| 调试难度 | |||
| 替换 Prompt 成本 | |||
| 替换解析器成本 | |||
| 是否容易丢底层理解 |
这张表的价值，在于它强迫你输出“比较后的判断”，而不是停留在印象。
12. 做这份实验时最容易犯的两个错误
错误一：对照的不是同一条链路
如果纯 API 版做的是“简单文本总结”，LangChain 版做的是“结构化分析 + 工具调用”，这个对照根本不公平。
错误二：把“代码更短”直接等同于“工程更好”
代码更短有时是好事，但也可能意味着：
- 隐藏细节更多
- 调试入口更少
- 初学者更容易失去边界感
所以你必须同时看：
- 表达是否清晰
- 调试是否更难
- 替换成本是否更低
13. 这份对照实验为什么对综合项目有直接价值
因为它会帮助你做一个很现实的决定：
- 综合项目哪些环节继续保留原生实现
- 哪些环节可以引入 LangChain 获得更清晰的组合表达
如果没有这份对照，很多人会在综合项目里陷入两种极端：
- 完全不用框架，重复写很多样板
- 完全依赖框架，结果解释不清每一层边界
14. 一个推荐的最终结论写法
你可以把最终结论写成一句非常具体的话，例如：
“对于月份 1 的研发任务总结链路，我保留原生 LLMClient 负责底层调用，但使用 LangChain 的 PromptTemplate + OutputParser 来提升链路可读性；我暂不把整套项目全面框架化，因为当前项目的主要目标仍是巩固边界而不是增加抽象层。”
这种结论的价值在于，它不是泛泛而谈，而是能直接指导综合项目的实现选择。