我以前做项目时，经常会把“部署”当成最后一步。功能差不多了，再想办法打包、起容器、配数据库，感觉也说得过去。可这次做 aibotchat 的过程，让我很明显地意识到，AI 系统不是这样收尾的。AI系统本身就是不稳定的，类似于黑盒一样的系统，我所要做的，就是尽可能的降低直接由LLM导致的问题。harness的思想确实给我了很大启发。
因为 AI 项目最麻烦的地方，往往不是你把接口跑起来，而是它上线之后会不会稳定、这样架构设计后效果到底好不好、参数改动方不方便、出了问题你能不能第一时间知道是哪条链路坏了。
我为什么后来不再把部署当“附录”
普通应用的部署已经不轻松了，AI 系统只会更复杂。它除了应用本身，还会带着模型、检索、Embedding、重排、知识库和运行时配置一起移动。只要其中一个环节处理得草率，后面就会一直补坑。
我也是做到一半才真正意识到，部署不是项目做完以后的动作，它其实是系统设计的一部分。你准备怎么跑、怎么调、怎么查、怎么回滚，这些问题越早想清楚，后面越省事。
说实话，现在用 Docker 本身已经不算亮点了。真正让我觉得这套方案有价值的，是它没有只停留在“把镜像拉起来”这个层面，而是把运行单元和管理视角一起考虑进去了。
从项目结构来看，至少有几个角色是明确的：
后端服务负责业务接口和核心能力。
前端不只是聊天页，还承担了知识库、设置、监控和日志相关能力。
PostgreSQL 和 Redis 被当成正式依赖来设计，而不是临时配件。
Compose 承担的是把这些东西拉成一套整体，而不是单独起几个容器。
这种感觉很像你终于开始把系统当系统看，而不是把一堆服务凑到一起就算完成。
上线之后，我最怕的其实不是启动失败
启动失败反而没那么可怕，因为它至少会直接暴露。更麻烦的是服务已经起来了，但它开始慢、开始抖、开始偶尔答错，或者某条链路悄悄坏了。AI 项目一旦碰到这种问题，没有日志、指标和链路信息，几乎就是摸黑排查。
所以我会越来越在意这些东西：
有没有独立的监控指标能看系统状态。
有没有运行日志能快速定位失败点。
模型、Embedding、Reranker 这类配置能不能相对平滑地调整。
前后端拆分之后，SSE、静态资源、接口转发有没有都跑顺。
这些问题看起来没有“系统回复效果提升”那么吸引人，但真的要交付时，它们才是决定系统能不能长期跑下去的部分。
这次我对“可交付”的理解变了
以前我会觉得，只要主要功能能跑，项目就已经差不多了。现在我更倾向于用另一种标准来判断：如果这个系统明天要让我自己继续维护三个月，我愿不愿意接。
如果答案是否定的，那通常不是因为功能少，而是因为部署、监控和日常维护成本太高。aibotchat 让我重新认识到，AI 项目的交付感，不在于页面有多炫，而在于它能不能稳稳地待在线上持续的正常使用以及能不能发挥应有的价值。
写在最后
我现在越来越相信，AI 工程真正的门槛不在“接上模型”，而在“把系统跑稳”。部署、观测、配置、回滚，这些以前很容易被我放到后面的事情，现在反而成了我评估一个项目成熟度时最先看的部分。至少这次做 aibotchat，我是真切地感受到了这一点。