三个月后：还在写代码、还在学习、偶尔还是会卡住

更新（2026）： S&P 500 金融聊天机器人项目后来已下线。Sydney 回来了，现在聚焦博客内容与产品。 试试 Sydney →

---

我一直在犹豫要不要写这篇关于 coding 旅程的更新。因为这段时间的进展并不“炫”、外部也不太看得见——那为什么还写？

也许这篇可以留给未来的我一个提醒：进步有时会放慢，成长往往是跳跃式发生的。

从我 4 月中写完“自评估聊天机器人”那篇后，我这段时间主要在补几门课：

• Meta 的 React Basics（Coursera）
• Meta 的 React Advanced（Coursera）
• Django web framework
• Full Stack

为什么是这些课程？

我想分享一下我选择这些课程背后的真实思路。希望能对正在（或将要）走类似路径的人有一点帮助。

学会更好地“指挥机器”

从我开始摸 coding 到现在大约 10 个月了，而且我还是全职工作状态下进行的。（更多背景见我 2023 年 10 月的那篇：How I Built My Own Chatbot with No Coding Experience: Lessons Learned）

坦白说，没有 Generative AI 帮助（不管是 ChatGPT、Anthropic Claude 还是 VS Code 里的 Microsoft CoPilot），我肯定走不到今天。但我越写代码越意识到：这些基础模型虽然很强，但更像“实习生”。它们在规划和处理模糊任务上还不够稳定。你给的指令越具体，输出就越好。

这意味着我也必须把 coding 指令写得越来越具体。那怎么做？到目前为止，我一直用自然语言描述需求。基础任务可以，但一旦任务复杂就明显不够。

于是下一个逻辑问题就是：该学什么？

聚焦我真正要解决的业务/用户问题

这个网站上的聊天机器人（代号 Sydney）之前（也许现在某些时候仍然）是慢的。慢体现在：

• 启动耗时
• 对话过程耗时

Streaming 也没开，用户得等一段不短时间才能看到完整回答。

所以我的目标一直很简单：让它更快、更有响应性。

目标很清晰，但如果基础能力不够，很难把它拆成可执行的小问题。所以我决定补足前端框架、后端框架和全栈（含数据库）方面关于“可扩展、可安全、可高性能”的知识。

我目前对 React 和 Django 的体感

• React：相对 Django 更容易学习和部署。（Duh!）当前聊天机器人前端就是 React，我发现 Claude 和 ChatGPT 在这块 coding 任务大多能顺利完成。React 在生产部署也比较直接，聊天页面在对话中的响应体感确实更好。
• Django：Django 和 Django Rest Framework（DRF）学习曲线更陡，尤其是结合 Cloud SQL 数据库和安全部署那部分。Django 很全面，也意味着要以合适安全级别上线会更花时间。问题是我到现在依然 还不能 让 DRF 在生产环境稳定输出 streaming HTML！我确实能用 WebSockets 做出来，但那已经偏离 DRF 主路径很多，所以目前还没采用。

如果你知道某个框架或做法能让 Langgraph streaming 在简洁前端里稳定跑通，欢迎告诉我！

那我 4 月提到的 Financial Chatbot 现在怎么样了？

好消息是，这个项目确实引发了不少兴趣——我收到了很多问题和留言。坏消息是？我离“做完”还很远 T.T 原因主要是：

1. 检索质量、向量库月成本、embedding 成本三者拉扯

如我在 4 月那篇 文章 中提到，我在评估 Weaviate 的 Serverless Cloud Vector Store。它确实是要真金白银的。这个项目规模下，我预估：

• 数据体量：超过 1,000 万，可能到 1,250 万 - 1,500 万 data objects。
• 成本估算：若向量维度设 512，月度 成本大概在 $600 - $750。

对公司生产环境来说这个级别可能可接受，但对这种 side project 来说就偏高了。所以我必须想办法降成本。

按 Weaviate pricing 的机制，主要两根杠杆是：减少 data objects 数量，或降低 vector 维度。两者都有 tradeoff。

如何减少 data objects

• 更激进的文本清洗：考虑到我们覆盖的是 S&P 500 的 500 家公司、每家过去 10 年多份 filings，先尽量压缩 10K/10Q 总文本量。我认为这条我基本榨干了。
• 增大 chunk size：把 chunk size 从 256 提到 512、1000、2000、3000，可把 data objects 降到 1/2、1/4 甚至 1/10。但检索精度通常会下滑，因为 chunk 越大越不“精准”。

如何降低 vector 维度

降低维度通常和检索质量正相关——维度越低，检索越容易劣化。我还在持续试不同 embedding 模型，比如 OpenAI 的 “text-embedding-3-small” 与 “text-embedding-3-large”，以及不同维度组合。如果你有好建议，欢迎分享！

另外，用 OpenAI 的 “text-embedding-3-large” 在 embedding 阶段本身也会加成本。比如我给 23 家公司过去 10 年 10K/10Q 生成 embedding（1024 维），就花了约 $4.5。按这个规模粗算，整个 S&P 500 可能要 $100+。（是的，我有点抠。你现在才知道吗 :P ?）

2. 查询翻译、结构化、检索过程中的延迟

查询翻译与结构化做得越细，生成的 search terms / content search terms 越好，检索质量就越高。但代价是延迟增加。

• Query translation 这一步是让模型把用户原始问题翻译成更适合检索的子问题。比如用户问 “How did Airbnb's operating margin change from 2020 to 2022?”，模型可以拆成：

[
"What was Airbnb's operating margin in the 10-K filing for the year 2020?",
"What was Airbnb's operating margin in the 10-K filing for the year 2021?",
"What was Airbnb's operating margin in the 10-K filing for the year 2022?"
]

• Query structuring 这一步是让模型把这些子问题进一步转成检索查询或 content search 查询，并附带相关 filters。以上面第一问为例，模型可能返回：

{
    "content_search": "What was Airbnb's operating margin in the 10-K filing for the year 2021?",
    "company_conformed_name": "Airbnb, Inc.",
    "form_type": "10-K",
    "conformed_period_of_report": "2021-12-31"
}

在 retrieval 阶段，返回结果越多，模型处理时间越长；返回太少则会更快，但因为上下文不足可能降低答案质量。

收个尾

还有很多点我还在处理，但这篇已经比预期长了，我先收在这里。

你也是在全职工作同时学 coding 吗？当你觉得“每件事都同样重要”时，你是怎么决定下一步学什么的？

致敬，

Chandler