本文面向：想了解不同 LLM 摘要质量差异的 ChatCrystal 用户。
预计阅读时间：10 分钟
为什么要横评
ChatCrystal 的核心功能之一是把冗长的 AI 编程对话压缩成结构化笔记------标题、摘要、关键结论、代码片段、标签。这个过程完全依赖 LLM 的理解能力。
问题在于：不同模型之间的摘要质量差距，可能远超你的预期。
本地模型（Ollama + qwen2.5:7b）零成本、无隐私泄露，但 7B 参数的小模型能不能胜任结构化知识提炼？云端模型（GPT-4o、Claude Sonnet）能力毋庸置疑，但每条对话都要付费，批量总结几百条对话时成本不可忽视。
这篇文章的目的很简单：帮你在质量、成本、速度之间做出 informed decision。
测试方法
测试对象
选取同一条中等复杂度的编程对话（约 15 轮交互，涉及 bug 调试 + 方案讨论 + 代码实现），分别用以下模型生成摘要：
| 模型 | 提供商 | 类型 | 默认模型 |
|---|---|---|---|
| qwen2.5:7b | Ollama | 本地 | 是 |
| gpt-4o | OpenAI | 云端 | - |
| claude-sonnet-4-20250514 | Anthropic | 云端 | - |
| gemini-2.0-flash | 云端 | - | |
| deepseek-chat | DeepSeek (Custom) | 云端 | - |
评测维度
ChatCrystal 的摘要 Schema 定义了 5 个结构化字段（来自 server/src/services/summarize.ts 的 SummarizeSchema），配合 SYSTEM_PROMPT 中的详细要求一起控制输出质量：
- 标题准确性 --- 是否精准概括对话主题，20 字以内
- 摘要完整性 --- 2-4 段 Markdown，覆盖决策上下文、实施要点、可复用知识（由 SYSTEM_PROMPT 约束）
- 关键结论提取 --- 3-5 条独立可理解的结论
- 代码片段识别 --- 0-3 个最关键代码片段，附语言和描述
- 标签生成 --- 3-6 个英文小写标签，覆盖技术栈、问题类型、领域
预处理逻辑
所有模型收到的输入是相同的。ChatCrystal 的 prepareTranscript 函数（server/src/services/transcript.ts）会做智能截断：
- 总预算：
maxInputChars = 32000（约 8000 tokens） - 保留首 Turn 和末尾两个 Turn（完整渲染）
- 中间 Turn 按得分排序，高分保留原文，低分压缩为一行摘要
- 确认类 Turn（用户输入 < 20 字符）直接标记
[确认]跳过
这意味着即使对话很长，每个模型看到的内容是一致的。
各模型表现
Ollama (qwen2.5:7b) --- 免费但粗糙
优势：
- 零成本，本地运行，无隐私问题
- 速度尚可（取决于硬件，通常 10-30 秒）
- 能正确识别对话的主要话题
问题：
- 标题过于宽泛：倾向于生成 "修复 Bug"、"代码优化" 这类泛化标题，缺乏具体性
- 摘要深度不足：能覆盖 "做了什么"，但对 "为什么这样做" 的决策上下文提取较弱
- 关键结论雷同：3-5 条结论之间区分度低，有时只是换了个说法重复同一件事
- 代码片段选择随意：经常选取冗长的完整实现而非最能说明方案的核心片段
- 标签过少或过泛 ：有时只生成 2 个标签，且偏向通用词汇（如
debug、fix）
适合场景： 个人使用、对话量大但对质量要求不高、隐私敏感环境。
OpenAI (gpt-4o) --- 全面均衡
优势：
- 标题精准且具体，能抓住对话的核心技术点
- 摘要结构清晰，决策上下文和实施要点分离得很好
- 关键结论之间有明确的层次和区分度
- 代码片段选择准确，倾向于选取最有说明力的片段
- 标签覆盖全面，技术栈 + 问题类型 + 领域三个维度都能兼顾
问题：
- 偶尔在摘要中加入对话中没有的 "推测性" 内容
- 对中文对话的摘要有时会中英混杂（技术术语保留英文是合理的，但偶尔连描述性文字也会混入英文）
适合场景： 团队使用、需要高质量知识库、预算可控。
Anthropic (claude-sonnet-4) --- 最佳摘要质量
优势：
- 标题最精准：既能概括主题，又保持简洁，几乎不需要人工修改
- 摘要最具可读性：段落之间的逻辑连贯性最好，读起来像人写的文档
- 关键结论最有价值：提取的结论往往是真正 "可复用" 的知识，而非对对话的简单复述
- 代码片段描述最清晰：不仅选对了代码，描述文字也能准确说明这段代码解决什么问题
- 严格遵循 Schema：字段长度、数量限制都控制得最好
问题：
- 成本最高（Sonnet 级别的 token 单价高于 GPT-4o）
- 速度较慢，尤其是长对话（需要更多 thinking time）
适合场景： 对知识库质量有高要求、预算充裕、对话量不大但每条都很重要。
Google (gemini-2.0-flash) --- 速度之王
优势：
- 速度最快，通常 3-5 秒完成
- 有免费额度，成本极低
- 标题和标签质量不错
- 支持 Embedding（text-embedding-004），可以一套 Google 方案走到底
问题：
- 摘要深度不如 GPT-4o 和 Claude，倾向 "点到为止"
- 关键结论有时过于简短，缺乏上下文
- 对复杂多步骤对话的理解力稍弱，偶尔会遗漏中间的方案切换
适合场景： 对速度敏感、预算有限、对话复杂度中等。
DeepSeek (deepseek-chat via Custom) --- 性价比之选
优势：
- 价格极低（远低于 OpenAI 和 Anthropic）
- 中文对话摘要质量出乎意料地好，中文表达自然
- 通过 ChatCrystal 的 Custom provider 接入，配置简单
- 关键结论的提取质量接近 GPT-4o
问题：
- API 稳定性偶有波动，高峰期可能变慢
- 英文对话的摘要质量不如中文
- 代码片段描述有时过于简略
适合场景： 预算敏感、中文对话为主、能接受偶尔的不稳定。
质量 vs 成本 vs 速度的三角权衡
用一句话总结每个维度的冠军：
- 质量天花板：Claude Sonnet > GPT-4o > DeepSeek > Gemini Flash > Ollama
- 成本友好度：Ollama > Gemini Flash > DeepSeek > GPT-4o > Claude Sonnet
- 速度体验：Gemini Flash > Ollama > DeepSeek > GPT-4o > Claude Sonnet
但真实决策不是选冠军，而是找平衡点。
真实成本估算
假设你有 200 条对话需要总结，每条约 8000 tokens 输入 + 2000 tokens 输出：
| 模型 | 单条成本（约） | 200 条总计 | 摘要质量 |
|---|---|---|---|
| Ollama qwen2.5:7b | ¥0 | ¥0 | ★★☆☆☆ |
| Gemini 2.0 Flash | ¥0.01-0.02 | ¥2-4 | ★★★☆☆ |
| DeepSeek Chat | ¥0.02-0.05 | ¥4-10 | ★★★★☆ |
| GPT-4o | ¥0.10-0.15 | ¥20-30 | ★★★★☆ |
| Claude Sonnet | ¥0.15-0.25 | ¥30-50 | ★★★★★ |
注：价格基于 2025 年中的公开定价，实际费用因 token 计数方式略有差异。
推荐方案
预算为零：Ollama + qwen2.5:7b
本地跑，完全免费。接受质量上的妥协，后续可以手动编辑笔记来弥补。ChatCrystal 默认就是这个配置，开箱即用。
进阶： 如果你的机器有 16GB+ 显存，可以试 qwen2.5:14b 甚至 qwen2.5:32b，质量提升明显。
小预算、大对话量：DeepSeek
通过 Custom provider 接入，200 条对话不到 10 块钱。中文对话的质量甚至可以媲美 GPT-4o。配置方式：
bash
crystal config set llm.provider custom
crystal config set llm.baseURL https://api.deepseek.com/v1
crystal config set llm.apiKey your-key
crystal config set llm.model deepseek-chat均衡之选：GPT-4o
质量稳定，生态成熟，出问题时社区资源最多。适合团队环境和需要可靠性的场景。
追求极致：Claude Sonnet
如果你的对话记录包含复杂的技术决策、架构讨论，Claude 的摘要质量是最好的。特别是关键结论的提取，往往能捕捉到真正有价值的决策逻辑。
速度优先：Gemini 2.0 Flash
批量总结时体验最好，几秒钟一条。免费额度够个人用很久。质量虽然不如 GPT-4o 和 Claude，但对大多数场景够用了。
ChatCrystal 的设计考量
几点技术细节值得注意：
Schema 约束保证了下限。 ChatCrystal 使用 Vercel AI SDK 的 generateObject 配合 Zod Schema 强制结构化输出。无论用哪个模型，输出一定是合法的 JSON，字段类型和数量都有约束。这避免了 "模型自由发挥导致输出不可解析" 的问题。
队列限速保护 API。 摘要任务通过 p-queue 串行执行（concurrency: 1），每秒最多 1 次请求，429 错误自动指数退避重试。这意味着即使你选了有 rate limit 的免费 API，也不会被封号。
Embedding 和 LLM 可以分开选。 这是很多人忽略的一点：你可以用 DeepSeek 做摘要（便宜），同时用 Ollama 的 nomic-embed-text 做语义搜索（免费本地）。两者独立配置，互不影响。
输入预处理是公平的基础。 prepareTranscript 的智能截断确保每个模型看到的内容是一致的------首 Turn 和末尾两个 Turn 完整保留，中间按重要性排序填充。这消除了 "模型 A 看到了更多上下文所以表现更好" 的变量。
下一步
- 实测你自己的对话：本文的结论基于特定对话模式，你的实际场景可能不同。建议先用 Ollama 跑几条，再用云端模型对比，找到自己的质量阈值。
- 混合策略：日常导入用 Ollama 自动总结，重要对话手动触发 Claude 重新生成。ChatCrystal 支持覆盖已有笔记。
- 关注 Custom provider：国内的 DeepSeek、Moonshot、智谱等都兼容 OpenAI API 格式，通过 Custom 接口接入后，选择空间比表中列出的 5 种大得多。
本文基于 ChatCrystal v0.4.x 的摘要服务实现。模型定价和能力会持续变化，建议以实际测试为准。