常见问题 (FAQ)
学习方法相关
Q: 没有Go基础能学吗？
A: 可以，但需要额外时间补基础。
建议：
- 如果完全零基础：先花1周学Go语言基础（Go官方入门）
- context.Context 的使用
- interface 的设计
- goroutine 和 channel
- error handling 模式
- 然后从Day 1开始
Day 1的教材会讲解所有涉及的Go概念，但理解会更快。
Q: 时间紧张能跳过某些天吗？
A: 可以跳，但有前置要求。
必修：
- ✅ Week 1 (Day 1-7) - Agent Runtime基础，必须完整做
- ✅ Week 2 Day 8-10 - RAG基础，对后续理解很重要
可选（根据面试方向）：
- Week 2 Day 11-14 - 如果面试不考RAG深度
- Week 3 某些Day - 如果不需要展示工程细节
- Week 4 Day 25-30 - 如果只准备coding不准备系统设计
不推荐跳过：
- ❌ Day 1-4 - agent loop是整个系统的核心
- ❌ Day 8-10 - RAG是面试重点
Q: 怎样最高效地学习？
A: 遵循苏格拉底法三步走：
-
问题驱动 (10分钟)
- 读"问题驱动"部分，在脑子里思考答案
- 不要直接看答案
- 这个过程激活你的前置知识
-
代码实战 (90分钟)
- 看"答案揭示"对比自己的想法
- 跟随代码示例自己敲代码（不要复制粘贴）
- 遇到不懂的，停下来查资料
-
自测验证 (30分钟)
- 完成"自测清单"
- 答不出来就回头重读相关部分
- 做"作业"部分，动手应用
效率提示：
- ✅ 自己敲代码记忆深度是+40%
- ❌ 复制粘贴只能看懂，遇到新问题就卡壳
- ✅ 理解Why比记住How重要10倍
Q: 代码跑不起来怎么办？
A: 按这个顺序排查：
-
读error message - 99%的问题错误信息都说清楚了
# 例如：package xxx not found
# 解决：go get xxx
-
检查环境 - 确保依赖装好
go mod download
go mod tidy
-
Google错误信息 - 加上"golang"前缀搜索
-
不要瞎改试试看 - 乱改会让问题更复杂
-
看提供的完整代码示例 - 对比自己写的代码
Q: 进度太慢是不是有问题？
A: 不是。这是正常的。
时间估算：
- Day 1-2: 2-3小时（打基础）
- Day 4: 4-5小时 ⚠️ Agent Loop最复杂
- Day 8-10: 3-4小时/天（RAG要理解深）
- Day 6, 13, 18: 都比较难，预留时间
加快进度的建议：
- ✅ 提前预习（看下一个Day的问题驱动部分）
- ✅ 重用上一个Day的代码框架
- ✅ 建立笔记系统，记录关键概念
- ❌ 不要跳过基础，后面会更卡
技术问题
Q: Chunk大小（1000 tokens）怎样确定？
A: 这是一个权衡问题。
太小的危害：
- 上下文断裂
- 检索时噪音多
- 需要更多个chunks，成本高
太大的危害：
- 包含无关信息，LLM容易分散注意力
- retrieval不精准
建议做法：
- 先用1000试（Day 8推荐值）
- 看Day 12的eval结果
- 根据评估指标调整
- 常见值：500-2000
Q: Embedding用哪个模型？
A: 根据场景选择。
文本-Embedding-3-small（推荐Day 8-14用）
- 便宜：$0.02 per 1M tokens
- 快速：一般3D embedding
- 够用：中文支持好
文本-Embedding-3-large
- 更准确：1536D embedding
- 贵一倍
- 只在recall要求超高时用
其他开源选项（自部署）：
- bge-base-zh（中文最好）
- M3E（中英双语）
Day 9会详细讲选择标准。
Q: 为什么要用RBAC而不是直接检查权限？
A: 可维护性和扩展性。
直接检查的问题：
// ❌ 坏：每个地方都要检查
if user.role == "admin" && request.action == "delete" {
// 允许
}
RBAC的好处：
// ✅ 好：权限定义在一个地方
if rbac.Can(user.role, "delete", resource) {
// 允许
}
- 一个地方维护所有权限
- 权限变更不需要改代码
- 审计日志清晰
Day 19会详细讲RBAC实现。
Q: vector search vs keyword search，什么时候用哪个？
A: 应该混用（混合检索）。
Keyword search
- ✅ 精确匹配
- ✅ 对特殊名词敏感
- ❌ 无法理解语义相似性
Vector search
- ✅ 理解语义
- ✅ 对改写query容错好
- ❌ 精确度不如keyword
混合方案（推荐）
- Day 10会讲如何权衡：
result = 0.6 * keyword_score + 0.4 * vector_score
- 可以根据query类型动态调权重
- 评估后调整
面试相关
Q: 怎样讲我的项目？
A: 用这个框架：
30秒版本
我做了一个Go版企业客服Agent。它包含Agent Runtime、RAG检索、审批流、Guardrails和Tracing。我的重点不是聊天demo，而是生产级系统——有状态、有权限、有审计、有评估。
2分钟深化
[30秒] +
Week 1做了Agent Runtime，LLM判断需要哪个工具，Tool Registry执行，重试和超时处理。
Week 2做了RAG，向量检索+关键词检索混合，防止幻觉。
Week 3加了Approval flow，确保重要操作需人工批准。
Week 4上线了Docker Compose，加了OpenTelemetry tracing和eval runner。
5分钟系统设计模式
[2分钟] +
我遇到的关键权衡：
- Agent loop是串行还是并行？我选串行，因为工具间有依赖关系
- Retrieval用什么？我用混合检索，keyword+vector各有用处
- 工单创建需要审批吗？我设计成需要，成本是延迟，收益是防止误操作
- 怎样评估效果？我做了eval runner...
Q: 系统设计面试常问什么？
A: 这个项目涵盖的3道系统设计题：
-
Customer Support Copilot（最常见）
- 架构：Agent + RAG + Approval
- 重点：多租户隔离、权限模型、成本控制
- 参考：系统设计指南
-
Enterprise Agent Platform
- 架构：Multi-tenant、Plugin system、Audit trail
- 重点：可扩展性、隔离性、可观测性
-
RAG系统设计
- 架构：Chunking + Embedding + Retrieval + Rerank
- 重点：检索精度、延迟、成本
准备方法：
- 每道题花30分钟看系统设计指南
- 画出架构图（Week 4 Day 27专项）
- 能讲清权衡点和trade-off
Q: 回答系统设计题时常见的坑？
A: 这些坑要避：
坑1：只讲happy path
- ❌ "用户发消息，LLM回答，完成"
- ✅ 讲failure scenarios: timeout、rate limit、幻觉、权限错误
坑2：不讲权衡
- ❌ "我们用PostgreSQL"
- ✅ "我们用PostgreSQL因为要ACID事务和复杂查询，但PostgreSQL写入没Redis快，所以在非关键路径用缓存"
坑3：数字模糊
- ❌ "很多用户"
- ✅ "假设100万日活，每个用户平均5个请求，对应5M QPS，我们需要..."
坑4：只讲API层
- ❌ "API接收请求，调LLM，返回"
- ✅ "从API → LLM Client → Tool Registry → Database → Cache，每层的设计考虑"
坑5：忘记可观测性
- ❌ 系统设计完了没提Tracing/Metrics
- ✅ "每个请求打trace_id，Tool调用记metrics，异常走alert"
Day 27系统设计专项会详细讲。
Q: coding面试和system design怎样分配时间？
A: 通常是这样的：
标准面试流程：
- Coding: 45分钟（1道题）
- System Design: 45分钟（1道题）
- Behavioral: 15分钟（背景、项目、冲突）
这个项目的优势：
- Coding: 你用Go实现了完整的Agent系统，例子充足
- System Design: 这3道题正好是高频面试题
- Behavioral: 可以深度讲你的项目、思考过程、学到的东西
时间分配建议：
- Week 1-2: 主要准备Coding（Go + 数据结构）
- Week 3-4: 主要准备System Design + Behavioral
项目管理相关
Q: 项目完成后怎样展示给面试官？
A: 这些很重要：
必须有：
- ✅ GitHub repo（代码整洁、有README）
- ✅ 运行文档（怎样跑起来）
- ✅ 架构图（2-3张Mermaid图）
- ✅ 自己能讲清每个环节
可以加：
- ✅ Demo video（跑一遍系统）
- ✅ Eval结果（Day 12的dataset.jsonl）
- ✅ Failure case分析（Day 26）
- ✅ 部署说明（Docker Compose）
千万不要：
- ❌ 代码有TODO未完成
- ❌ README只有一行
- ❌ 讲不清自己的代码
- ❌ 只讲了最简单的Day 1，其他都skip
Q: Week间怎样做code review？
A: 建议每周一次：
# 在周末花30分钟
git log --oneline --since="7 days ago" # 看这周改动
git diff main..HEAD # 看详细diff
# 自问这些问题：
# 1. 代码能跑吗？(go test -v)
# 2. 错误处理完整吗？
# 3. 有race condition吗？(go test -race)
# 4. 日志够清楚吗？
# 5. 命名有歧义吗？
Week 1末检查清单：
Q: 怎样整理Project Showcase？
A: Day 28 就是这个。提前准备：
30秒版本 - elevator pitch
2分钟版本 - 展示会说辞
- 背景：为什么做这个？
- 核心：做了什么？
- 数字：效果怎样？
- 学到了什么？
5分钟版本 - 深度讨论
- [2分钟] +
- 最难的问题是什么？怎样解决的？
- 有没有想不到的坑？
- 如果重做，会怎样不同？
- 下一步想补充什么？
Day 28会详细讲怎样打磨这些版本。
部署和运维
Q: 本地开发和部署环境怎样同步？
A: 用Docker保证一致性。
# 本地开发
npm run dev
# 本地模拟生产
docker-compose up
# 提交前必须
npm run build
npm run preview # 预览构建后
Q: GitHub Pages / Vercel / 自托管，选哪个？
A: 场景不同选择不同：
| 方案 |
优点 |
缺点 |
适合场景 |
| GitHub Pages |
免费，无限流量，GitHub集成 |
无自定义域名，CDN不全球化 |
个人项目、学习 |
| Vercel |
快速，自定义域名，Analytics |
有流量配额限制（极高才会超） |
个人项目、展示 |
| 自托管 |
完全控制，无限制 |
需要自己维护服务器 |
公司内网、高流量 |
这个项目推荐：Vercel
Q: Markdown文档怎样管理版本？
A: 用git。
# 每天工作完
git add docs/ weekplan/
git commit -m "Add: Day 8教学材料 - 文档解析与Chunking"
git push
# 周末总结
git log --since="7 days ago" # 看这周的改动
好的commit message范例：
- ✅ "Add: Day 1教学材料和代码示例"
- ✅ "Update: 修正Day 5中的goroutine死锁例子"
- ✅ "Fix: 修复Week 2 Overview中的Mermaid图语法"
- ❌ "update"
- ❌ "修改"
其他问题
Q: 能接其他学习资料吗？
A: 可以，但要注意：
推荐补充：
- ✅ Go官方文档（语言细节）
- ✅ LeetCode（算法题）
- ✅ 系统设计Primer（通用知识）
不建议补充：
- ❌ 其他Agent框架（langchain等）- 会分散注意力
- ❌ 其他RAG课程 - 这个项目已经够全面
- ❌ 其他Go项目 - 先完成这个
原则：
- 把这个项目做完是第一优先级
- 补充资料要有明确目的（弥补某个知识gap）
Q: 完成后怎样继续深化？
A: Day 30后的方向：
如果想继续Go：
如果想学AI系统设计：
如果想转向面试：
没找到你的问题？提交Issue或联系维护者。
需要帮助？ 查看 快速开始 或 学习地图