Notes on gotchas while migrating 35kb preprompts from Opus to self-hosted Ollama（把 35KB 长提示词从 Opus 迁到自托管 Ollama 的踩坑笔记）

📅 2026-09-14 | 🏷️ 工程 & Agent | ⭐ HN 110分/62评论
🔗 原文：https://patrickmccanna.net/notes-on-migrating-large-prompts-away-from-anthropic-openai-to-self-hosted-llms/
💬 讨论：https://news.ycombinator.com/item?id=49697014

是什么

一篇一线工程师的迁移实录：作者把约 35KB 的长预提示词（preprompts）体系从 Anthropic Opus 迁移到自托管的 Ollama 本地模型，逐条记录过程中的坑。HN 上 110 分、62 条评论，是近期少见的「自托管降本」一手经验帖。

🔍 小白解读

先说几个词

• Preprompt / 系统提示词：发给模型的那段「岗位说明书」，规定它的角色、规则和输出格式。35KB 约相当于几万字符，属于超长提示词。
• 自托管（Self-hosted）：把开源模型跑在自己的服务器上，而不是调用 OpenAI/Anthropic 的 API。好比从「天天点外卖」改成「自己开火做饭」。
• Ollama：让你在本地一条命令跑起开源大模型的工具，是自托管阵营里最流行的「灶台」之一。
• Opus：Anthropic Claude 系列中的旗舰档模型，能力强、价格也最高。
• 量化（Quantization）：把模型参数从高精度压成低精度以省显存、提速度，类似把无损音乐压成 MP3——体积小了，音质略有损耗。

这篇到底在说什么

作者面对的是一个非常典型的成本-能力权衡题：一套长期迭代出来的超长提示词（35KB）跑在 Opus 这种旗舰闭源模型上，效果好但账单可观，于是决定搬到自托管的开源模型上。但迁移远不是「换个接口地址」那么简单：长提示词在本地模型上的服从性、输出格式稳定性、上下文保持能力都会打折，各种隐性坑（标题里的 gotchas）一个接一个冒出来。这篇笔记的价值就在于把坑一条条记下来——哪些地方要改写提示词、哪些行为差异要重新测试、哪些预期要调低。HN 评论区 62 条讨论，也围绕「自托管到底省不省钱」「开源模型与旗舰闭源的真实差距」展开了大量实战交锋。

这跟普通人有什么关系

对依赖 AI API 的团队，这是一份「降本避坑指南」的预览：自托管不是免费午餐，省下 API 费的同时要投入硬件、运维人力和效果调优。普通人使用的各类 AI 产品背后同样在做「旗舰 API 还是便宜模型」的权衡——这直接决定你用的产品是又贵又稳，还是便宜但偶尔抽风。

为什么值得架构师关注

• 「API vs 自托管」选型的一手数据点：当提示词规模达到几十 KB、调用频次高时，旗舰 API 成本与自托管 TCO（GPU、运维、调优）的交叉点在哪里，本文提供实证参考。
• 迁移风险清单可直接复用：长提示词跨模型的行为差异是很多团队踩过的隐雷，标题点名的「gotchas」条目可用于自查现有提示词资产。
• 为混合路由策略提供依据：关键路径留旗舰 API、非关键路径下沉自托管是当前主流降本架构，此类实践帖是路由阈值设定的重要输入。

核心内容

• 一次真实迁移：约 35KB 的预提示词体系，从 Anthropic Opus 迁至自托管 Ollama。
• 以「踩坑笔记」形式记录迁移中的具体问题与处理方式，而非泛泛教程。
• 核心结论方向：大提示词场景下，迁移的主要成本在「行为差异」而非「接口差异」。
• HN 62 条评论聚焦两大主题：自托管的成本账、开源与旗舰模型的能力差距。

行动建议

正在评估「哪些负载可以下沉自托管」的团队，把这篇作为 checklist 读一遍；按文中思路先做小流量影子测试（同一提示词双跑对比），量化输出质量差再定迁移比例。纯 API 用户也可关注其中关于提示词跨模型兼容性的经验。