我的 4 周旅程：从前端升级到 Docker 挣扎，再到突破

更新（2026）： 下文提到的 WordPress 前端与 Docker 部署已是“古早历史”。网站现在运行在 Next.js 上，Sydney 也已基于 Supabase pgvector + Claude 从零重构。还在写代码，还在学习。

Ask Sydney →

---

以下保留 2024 年 3 月原文以供参考。

过去 4 周我都没发文。你可能会想发生了什么？我是不是变懒不学了？嗯某种程度上，确实有一周末和家人朋友出去旅行了。

今天这篇会比较短。我想简单记录过去 4 周学到了什么。但谁会在意？确实可能没人会在意，所以这篇主要是给我自己做进度留档，可能再加 1 位读者（不管你是谁 :D）。

TL;DR："Just in time learning" 真的存在，而且我就在亲身体验。

前端变好了

如果你几个月前来过我的站，现在应该会看到页面外观更现代、导航更顺（希望如此）。我用了 Github Copilot 和 ChatGPT4，让机器协助改“look and feel”。结果产出了 300+ 行 CSS，其中大部分我自己根本写不出来。下面是片段：

/* Defining CSS variables for common values */
:root {
    --main-font: 'Poppins', sans-serif; /* Main font for the website */
    --primary-color: #003366; /* Primary color for text */
    --accent-color: #4da6ff; /* Accent color for links and buttons */
    --background-color: #FAFAFA; /* Background color for the body and some elements */
    --text-color: #333333; /* Main text color */
    --hover-color: #4da6ff; /* Color for hover effects */
}

/* Applying the main font and color to various elements */
body, button, input, select, textarea, h1, h2, h3, h4, h5, h6, .nav-menu, .nav-menu a, .widget-title, .page-numbers.current,
#primary-menu .menu-item a, #primary-menu .sub-menu .menu-item a, .site-title a, .primary-navigation a, .widgettitle, .simpletoc-title {
    font-family: var(--main-font);
    color: var(--text-color);
}

另外现在访问 chatbot 页面 时，整体风格也和站点其他页面更一致。提问输入框就在首屏 above the fold，且对话框会随会话展开自动增长。我都不敢相信自己怎么没早点做完。也向之前访问过那个页面的人说声抱歉。

Sydney 聊天机器人换了新向量库，query translation 也更好了

从 WordPress 导出内容，到 HTML 清洗、chunk、生成 embedding、存入向量库——这整套流程一旦做过几次，其实会变得又快又顺。

我换了新的向量库方案（仍然是 FAISS），并调整了 chunk 方式（这次 chunk size 和 overlap 略高）。

用户 query 会通过 Langchain 的 multi-query retriever 做转换。对比之前的 retriever，我现在拿到的回答更完整、也更有层次。

# Set up vector store and llm
embeddings = OpenAIEmbeddings()
vectorstore = FAISS.load_local("faiss_index", embeddings)
llm = ChatOpenAI(model_name="gpt-3.5-turbo-0125", temperature=0)

# Set up retriever
retriever_from_llm = MultiQueryRetriever.from_llm(
    retriever=vectorstore.as_retriever(), llm=llm
)

推 Docker 镜像到 GCP Artifact 卡住，结果反而成了好事

大概一个月前开始，不知什么原因我在把 Docker Image 推到 GCP Artifact 这一步一直出问题。我试了很多办法都没解决，而此前几个月一直都正常。

正因为这样，我被迫思考另一种部署方式——不依赖把镜像推到 Artifact。然后我发现了在 GCP Cloud Run 上通过 Github repo 做持续部署这条路。

差不多同一时间，我看了一个教程，里面用了 poetry。我当时完全不知道它是什么，就让 chatGPT 解释了一下。结果它在依赖管理上非常好用，所以现在我也在用了 :) 这次探索也让我更系统地学了如何给每个项目建独立虚拟环境，并开始在所有项目里执行。

所以现在我的流程是：新项目先建虚拟环境，用 poetry 管依赖，再配 GCP Cloud Run 持续部署。整个节奏顺了很多。只要我先在本地测透，部署 chatbot 新版本也快很多。

我现在在做什么？

当前我在做并部署一个 基于 Langchain 的 research assistant。Langchain 和 GPT-Researcher 的开源代码（感谢两位！）已经足够清晰，我本地可以跑通。但要部署到生产环境就难多了，尤其是内容抓取这块。具体问题是：我在本地 Docker Container 里压测时，CPU 占用太高。

我也有一些想法，想进一步改进 GPT-researcher 和 Langchain 当前展示的 research assistant 路径，但还要继续做成可落地的版本。准备好后我再分享。

你的想法？

每一行代码、每一小时排障、每一次突破，都是一步台阶。虽然这条路是我自己的，但如果它能给你一点启发、提供一点思路，或者只是有一点点娱乐价值，也很好。你在技术实践里遇到过哪些挑战？欢迎在下面分享你的故事或问题——我们一起在这片数字海域里航行。

致敬，

Chandler

P.S：如果你在做 RAG 应用，我觉得 Langchain 的 “RAG from scratch” 系列非常实用。