从想法到上线：我用47天把LLM（大语言模型）塞进真实业务流

大多数人死在了第0步。不是技术不行，是根本没走到需要技术的那一步。

作者花了47天，把一个关于LLM的模糊念头变成了能跑的生产系统。没融资，没团队，没"先做个MVP试试"的借口。这个案例的价值不在于他用了什么模型，而在于他踩中了90%AI项目会栽的同一个坑——把模型当产品，而不是把系统当产品。

01 先别写代码，先画一张没人看的草图

作者的第一件事出乎很多人意料：打开空白文档，不是IDE。他花了整整3天只写文字——用户是谁，问题是什么，LLM在哪个环节介入，出错时怎么办。

这个反直觉的动作救了他。因为LLM项目的失败模式太固定了：demo惊艳，上线崩溃。上下文丢失、幻觉乱答、跟现有工具链打架。作者发现，问题从来不是模型不够聪明，是模型被丢进了一个没设计过的环境。

他画了一张流程图，现在看很丑，但关键决策全在上面：用户输入怎么清洗，什么进上下文窗口，什么走外部检索，模型输出怎么校验，错了怎么回滚。这些后来成了系统的骨架。

02 第一周就部署，哪怕只能回答"你好"

第4天，作者把第一个版本推到了服务器。功能极其简陋：接收文本，调用API，返回结果。但他坚持这么做，理由是"部署焦虑"比"代码焦虑"更致命。

很多人反着来：本地调完美再上线，结果环境差异、依赖冲突、配额限制全在最后一刻爆发。作者的做法是，让基础设施问题尽早暴露，而不是攒到庆祝时刻。

这个版本的用户是他自己。每天往系统里丢真实的工作邮件、会议记录、需求文档，看哪里断链。第11天，他发现模型在处理长线程对话时会"遗忘"关键约束——不是因为上下文窗口不够，是他没设计记忆机制。这个发现直接改写了架构。

03 幻觉不是病，没做防护才是

第23天，系统第一次给出完全错误的法律条款引用。作者没换模型，加了一层校验模块：LLM输出→结构化提取→外部源核对→置信度评分→低置信触发人工复核。

这个设计让响应延迟增加了400毫秒，但错误率从"偶尔出现"变成了"可量化、可拦截"。他接受了一个现实：在生产环境，LLM的确定性比聪明更重要。

同期他做了另一个反常识的决定：不追求单轮对话的完美，而是强制每5轮触发一次状态总结。用户看到的还是流畅交流，但后台的上下文被压缩、归档、重新注入。这个机制让长会话的稳定性提升了3倍以上——具体数字来自他后来公开的日志分析。

04 集成比模型更难搞

第31天到第40天，作者几乎没碰模型本身。全在跟Slack、Notion、邮件系统打交道。每个集成点都是一座冰山：OAuth流程、速率限制、格式转换、错误重试、用户权限。

他写了一段话记录当时的崩溃：「我以为自己在建AI系统，结果80%时间在处理某个API返回的奇怪时间格式。」

这个阶段他建立了一条规则：任何外部调用必须包装在统一的故障隔离层里。一个服务挂了，不能拖垮整个对话流；一个格式解析失败，要降级到明文展示而不是抛异常。这些"无聊"的工程决策，后来成了系统能扛住真实用户的关键。

05 上线前48小时，他删了30%的功能

第45天，系统功能完备度已经超标。作者做了最后一次审计：哪些功能用户真的需要，哪些只是"这个很酷"。

被砍掉的功能包括：多模型自动切换（复杂度爆炸）、实时联网搜索（延迟不可接受）、个性化语气调节（数据不够）。留下的核心只有三样：可靠的上下文管理、可验证的输出、无缝的现有工具集成。

第47天，系统对第一批5个真实用户开放。没有发布会，没有技术博客，只有一条私信："试试这个，坏了告诉我。"

一周后，用户反馈里出现最高频的词是"稳定"——在LLM应用里，这几乎是最高评价。

作者在最后写道：「我没造出一个更聪明的AI，我造的是一个AI不会搞砸事情的容器。」这句话或许解释了为什么大多数LLM项目停在PPT里——我们过度投资在让模型变强，却低估了一个事实：用户要的不是最强的大脑，是最靠谱的同事。

现在他的系统还在跑，用户涨到了多少？作者没说。但他在文档里留了一个待办事项：第90天复盘，标题是"如果重来，第几天会放弃"。