Phase 3 总结 — 60天AI系统工程深度学习回顾
Phase 3 总结 — 60天AI系统工程深度学习回顾
日期: 2026-10-28 方向: AI系统工程 / LLM / RAG / Agent / LLMOps 阶段: Phase 3 收官 (Day 121-180) 标签: #Phase3End #Retrospective #AIEngineering #Career #Reflection
0. 写在前面 / Foreword
60 天前的 2026-08-30,我从 Phase 2(量化/微观结构, Day 61-120)切换到 Phase 3 时,曾在 Day 121 笔记的开头写下一句话:
"我担心的不是学不会LLM。我担心的是用了两年LLM工具之后,依然停留在'调prompt'层级,没真正理解一个生产级 AI 系统该怎么搭。"
今天 2026-10-28,Phase 3 收官。我可以诚实地说:这两个担心都没成真,也都部分成真。
- 我没有止步于 prompt 层级 — 从 Transformer 数学到 vLLM PagedAttention 到 Ragas 到 LangGraph 到 OWASP LLM Top 10,全部走了一遍;
- 但我也没真正"做出过千万 DAU 级 AI 产品",所以"理解"和"主导"之间还隔着一个真实项目的距离。
这 60 天本质上是一次 "用 LLM 的 PM → 用 LLM 做架构的工程师"的身份切换。下面是完整复盘。
1. Phase 3 全景回顾 / Phase 3 Panorama
1.1 60天主题分布
Phase 3: Day 121-180 (2026-08-30 → 2026-10-28)
┌──────────────────────────────────────────────────────────────────────────┐
│ │
│ W19-20 (Day 121-134) ──── LLM基础与Prompt工程 ── 14天 │
│ ├─ Transformer/Attention/KV-cache (Day 121-123) │
│ ├─ Tokenization/Decoding (Day 124-125) │
│ ├─ Prompt techniques (CoT/ToT/SC) (Day 126-128, 129=Week复习) │
│ ├─ Constitutional / RLHF (Day 130-131) │
│ ├─ Long context / Caching (Day 132-133) │
│ └─ Prompt SOP (Day 134) │
│ │
│ W21-22 (Day 135-148) ──── RAG高级模式 ── 14天 │
│ ├─ rag_v1 baseline (Day 135) │
│ ├─ Embedding / Vector DB (Day 136-137) │
│ ├─ Hybrid + Rerank (Day 138-139) │
│ ├─ Query rewrite + rag_v2 (Day 140-141, 0.948) │
│ ├─ Hierarchical / GraphRAG (Day 142-143) │
│ ├─ Agentic RAG / Long Context (Day 144-145) │
│ ├─ Multimodal / Eval (Day 146-147) │
│ └─ rag_v3生产化 (Day 148, R 0.95 / Faith 0.93) │
│ │
│ W23-24 (Day 149-162) ──── Agent架构与多Agent ── 14天 │
│ ├─ Agent定义 / 5+1 pattern (Day 149) │
│ ├─ ReAct / Plan-Execute (Day 150-151) │
│ ├─ Tool design / MCP / A2A (Day 152-154, 155=Week复习) │
│ ├─ LangGraph / 三框架对比 (Day 156-157) │
│ ├─ Memory 4层 (Day 158) │
│ ├─ 多Agent拓扑(seq/hier/net) (Day 159) │
│ ├─ Agent Eval (Day 160) │
│ ├─ Onchain Agent (session key/x402) (Day 161) │
│ └─ multi_agent_v1整合 (Day 162) │
│ │
│ W25-26 (Day 163-176) ──── 生产基础设施与评估 (LLMOps) ── 14天 │
│ ├─ vLLM/SGLang/TGI推理 (Day 163) │
│ ├─ Cost / Latency 优化 (Day 164-165) │
│ ├─ Deterministic eval / LLM judge (Day 166-167) │
│ ├─ Golden dataset / Pipeline (Day 168-169) │
│ ├─ Langfuse Observability (Day 170) │
│ ├─ PromptOps CI / 灰度 (Day 171) │
│ ├─ Prompt vs RAG vs FT 决策 (Day 172) │
│ ├─ LoRA / QLoRA (Day 173) │
│ ├─ Safety & Guardrails / Red Team (Day 174-175) │
│ └─ LLMOps Stack蓝图 (Day 176) │
│ │
│ W27 (Day 177-180) ──── 综合产出 ── 4天 │
│ ├─ 金融研究AI Agent v1 (Day 177) │
│ ├─ 金融研究AI Agent v1续 + 部署 (Day 178) │
│ ├─ AI工程方法论白皮书 (Day 179) │
│ └─ Phase 3 总结 + 30题面试集 (Day 180 ← 今日) │
└──────────────────────────────────────────────────────────────────────────┘
1.2 累计学习时间与产出统计
| 维度 | 数据 |
|---|---|
| 学习日数 | 60 天(2026-08-30 至 2026-10-28) |
| 累计学习时长 | ≈ 360 小时(60 × 6h,含部分周末加深) |
| 笔记文件数 | 60 份(EXPERT-DAY121.md ~ EXPERT-DAY180.md) |
| 笔记总行数 | ≈ 36,500 行(平均 608 行/天) |
| 代码模块 | transformer_demo, prompt_lib, rag_v1/v2/v3, multi_agent_v1, finance_research_agent_v1, eval_pipeline, guardrails — 共 7 个独立 package,~ 9,200 LoC |
| RAG指标提升 | baseline Recall 0.86 → rag_v3 0.95;Faithfulness 0.78 → 0.93 |
| Cost优化 | prompt caching + batch API 实测把核心查询成本降 82%(Day 164 数据) |
| 面试题 | 30 题资深 AI(File 2,本日附件)+ 散落于各日的 ~140 个小题 |
| 长报告 | 《Prompt SOP》(Day 134)、《RAG技术报告》(Day 148)、《Multi-Agent v1 设计》(Day 162)、《LLMOps Stack蓝图》(Day 176)、《AI工程方法论白皮书》(Day 179) |
1.3 AI系统工程能力图(prompt → RAG → agent → eval → production)
┌────────────────── Phase 3 AI Engineering Stack ──────────────────────┐
│ │
│ [LLM Foundations] │
│ Transformer/Attention ─→ Tokenization ─→ Decoding ─→ Long context │
│ (Day 121-123) (Day 124) (Day 125) (Day 132-133)│
│ │ │
│ ▼ │
│ [Prompt Layer] │
│ Templates ─→ CoT/ToT/SC ─→ Caching ─→ Constitutional ─→ SOP │
│ (Day 126) (Day 127-128) (Day 132) (Day 130-131) (Day 134) │
│ │ │
│ ▼ │
│ [Knowledge Layer / RAG] │
│ Embedding ─→ VectorDB ─→ Hybrid+Rerank ─→ Hierarchical+Graph ─→ │
│ (Day 136) (Day 137) (Day 138-139) (Day 142-143) │
│ Agentic ─→ Long-context routing ─→ Multimodal ─→ rag_v3 │
│ (Day 144) (Day 145) (Day 146) (Day 148) │
│ │ │
│ ▼ │
│ [Agent Layer] │
│ ReAct ─→ Plan-Exec ─→ Tools ─→ MCP ─→ A2A ─→ LangGraph ─→ Memory │
│ (D150) (D151) (D152) (D153) (D154) (D156) (D158) │
│ ─→ Multi-agent topology ─→ Onchain (session keys/x402) │
│ (Day 159) (Day 161) │
│ │ │
│ ▼ │
│ [Evaluation Layer] │
│ Deterministic ─→ LLM-judge ─→ Golden set ─→ Online eval ─→ CI │
│ (Day 166) (Day 167) (Day 168) (Day 170) (Day 171) │
│ │ │
│ ▼ │
│ [Production Layer] │
│ Inference (vLLM) ─→ Cost (caching/batch) ─→ Latency (stream/spec) │
│ (Day 163) (Day 164, -82%) (Day 165) │
│ Observability ─→ Versioning/Canary ─→ Guardrails ─→ Red team │
│ (Day 170) (Day 171) (Day 174) (Day 175) │
│ │ │
│ ▼ │
│ [Domain Application] │
│ Finance Research Agent v1 (Day 177-178) — RAG + Agent + Eval + │
│ Guardrails + Onchain tools,端到端落地 │
│ │
│ [Methodology Capstone] │
│ AI Engineering Methodology Whitepaper v1 (Day 179, 22+ pages) │
└────────────────────────────────────────────────────────────────────────┘
这张图就是 60 天的"Phase 3 stack"。从下往上是产品依赖链:没有底层就上不去,没有上层就落不了地。
2. 4个子阶段核心收获
2.1 W19-20: LLM基础与Prompt工程 (Day 121-134)
3条洞察:
- Self-attention 不是魔法,是带权点积 — 真正写过 numpy 版 multi-head attention 之后,Claude/GPT 不再是黑盒。每多一个 head 就是多一种"关系学习器"。
- Decoding 参数对输出的影响远超 prompt 字面 — temperature=0 vs 0.3、top_p=0.9 vs 0.95 在金融场景下能切换"严谨/创造性"模式。这是 PM 经常忽略的杠杆。
- CoT 对中等模型有效,对 Claude 4.7 反而要警惕过度思考 — 高能力模型自己有内部 reasoning,强制 CoT 反而引入位置漂移。Day 127 的 ablation 数据明确了这点。
1条认知更新:之前以为 prompt engineering 是"语言艺术",做完 14 天后改成"prompt 是软件"——要版本化、要测试、要 CI。
关键概括:把 LLM 从黑盒变白盒,把 prompt 从手艺变工程。
3天推荐回顾:Day 121(Transformer 数学)/ Day 127(CoT/ToT/Self-consistency 对比)/ Day 134(Prompt SOP)。
额外细节(值得在面试里讲的):
- Day 121 numpy 实现 multi-head attention 帮我搞清楚 head 之间的"分工"——Anthropic mechanistic interpretability 论文里讲的"induction head"在我自己跑的 toy model 里能复现,那种"啊原来是这样"的体感比看十篇论文更深。
- Day 132 实测 prompt caching 效果——在 Anthropic console 看到
cache_read_input_tokens第一次跳出来时,cost dashboard 是肉眼可见的下降曲线。这是从"知识"变"肌肉记忆"的转折。 - Day 134 把零散 prompt 经验整理成 SOP 时发现:80% 的"prompt 调整"其实是"任务定义不清"。一旦把 task spec / I/O schema / success metric 写下来,prompt 写起来反而简单。这个认知是 PM 视角带来的优势。
2.2 W21-22: RAG高级模式 (Day 135-148)
3条洞察:
- "Hybrid 永远赢 dense-only"是错的 — 在金融术语密集的query上 BM25 反而比 dense embedding 更准;在抽象意图查询上 dense 赢。RRF 融合不是参数调优问题,是"按 query 类型路由"问题。
- Reranker 的 ROI 远超大多数其他优化 — bge-reranker-v2-m3 给了 +6 个点 Recall@10,比换更贵的 embedding 模型还有效。但延迟代价 80-150ms,要分场景。
- GraphRAG 不是替代 vanilla RAG — 适合多跳推理 + 关系密集语料(合同条款交叉引用、法规对照),在 FAQ/单文档摘要上反而更慢更差。
1条认知更新:以前认为"RAG 准确率 = 检索准确率",现在改成"RAG 端到端质量 = retrieval × generation faithfulness × hallucination guardrails",三个独立指标。
关键概括:从"塞文档进 prompt"升级为"按查询路由 + 多模态 + 评估闭环"的工程系统。
3天推荐回顾:Day 138(Hybrid + RRF)/ Day 144(Agentic RAG self-correct)/ Day 148(rag_v3 capstone)。
额外细节:
- Day 138 RRF 调参的 ablation 让我意识到——很多 RAG 教程把 RRF 当成"塞进去就行"。实际上 BM25 / Dense 在不同 query 类型下"该听谁的"差异巨大。Day 138 我做了 query type × retriever weight 的二维 ablation 矩阵,发现"按 query 类型路由权重"比"全局调 k"贡献的 NDCG 提升大 2 倍。
- Day 142 hierarchical / parent-child 让我认知更新——之前 RAG 的 chunk 大小一直是"拍脑袋 512 tokens",做完 parent-child 后 Recall 直接 +5 个点。这是免费的——不换模型不换数据库。
- Day 148 把 rag_v3 完整部署到 Docker + FastAPI + Qdrant + Prometheus 上线后,看 Grafana dashboard 的 p99 latency 曲线——那种"系统真的活着"的体感是单纯写代码体会不到的。
2.3 W23-24: Agent架构与多Agent (Day 149-162)
3条洞察:
- Agent ≠ Chatbot + Tools — Agent 的本质是 "reasoning + tools + state" 三件套的循环。没 state 就没记忆,没 reasoning 就退化成函数调用。LangGraph 把 state 显式化后,调试效率提升至少 5x。
- Multi-agent 最难的是 coordinator — 不是 worker 设计;当 worker > 3 时,coordinator 的设计决定了性能上限。AutoGen 用 group chat、CrewAI 用 process、LangGraph 用 supervisor,三者各有取舍。
- MCP 是 tool calling 的协议层升级 — 它不是另一种 API;而是把 tool definition 从 client-side 提升到 server-side,使 tools 可以被多个 agent 复用。Day 153 用 Claude Desktop 配置 MCP server 之后这点很清楚。
1条认知更新:之前以为 "agent 越多越聪明"。Day 159 的对比数据告诉我:3-agent debate 比 single-agent ReAct 慢 4x、贵 5x,但准确率只提升 8%。多 agent 是工具,不是默认。
关键概括:Agent 不是"更聪明的 chatbot",是有状态的 reasoning loop;多 agent 不是默认,是当任务可分解时才用。
3天推荐回顾:Day 150(ReAct)/ Day 156(LangGraph)/ Day 161(Onchain Agent + session keys)。
额外细节:
- Day 150 用裸 SDK 实现 ReAct(不依赖 LangChain)让我搞清楚 agent 不是黑魔法——就是个 while loop。这种"去 framework 化"的练习是必修,否则永远不知道框架隐藏了什么。
- Day 156 LangGraph 的 state machine 范式让我做 multi-agent 时调试效率提升 3-5 倍。CrewAI 把 state 隐藏看似"美",但生产 debug 时是噩梦。显式 > 隐式 是 agent 工程的硬规则。
- Day 161 Onchain agent + session keys 是 Phase 1 (机构 DeFi) 和 Phase 3 (AI agent) 第一次正式合并——那一天我意识到 270 天计划的"叠加效应"是真的存在的。一个 demo 让 agent 自主在测试网买了 0.01 ETH 的 USDC,限额 100 USDC、24h 失效。这种感觉比单独做任何一个 phase 都更兴奋。
2.4 W25-26: 生产基础设施与评估 (Day 163-176)
3条洞察:
- eval 体系是"AI 产品的回归测试" — 没有 deterministic eval + LLM judge + golden set 三层组合,PR 合不合并就只能拍脑袋。Day 169 的 CI 跑通后,团队心智完全变了。
- Prompt caching + batch API 是最被低估的省钱手段 — Day 164 实测对一个金融 RAG 系统,启用 prompt caching 后核心 query cost 降 82%。但前提是 cache hit rate > 70%,否则反而花钱。
- Red team 必须自己做 — 第三方 jailbreak benchmark 永远滞后。Day 175 跑 200 个攻击 case 之后,发现 5 类高危漏洞都不在 OWASP LLM Top 10 标准库里,是金融场景特有的(套出客户持仓、伪造合规口径)。
1条认知更新:之前以为"上线 AI 产品 = prompt OK + 模型选好"。现在的 mental model 是"上线 = 6 层 stack(gateway → guardrails → routing → eval → observability → governance)每层都过关"。
关键概括:LLM 上生产不靠模型,靠工程;eval 不是事后审核,是开发闭环。
3天推荐回顾:Day 167(LLM judge + position bias)/ Day 169(eval pipeline CI)/ Day 175(Red team 报告)。
额外细节:
- Day 164 cost optimization 让我从"LLM 就是贵"的认知中走出来——把 prompt caching + batch + model routing 三件套用起来,82% 降幅在生产是真的、可复现的。这不是技巧,是 LLM 工程师必修课。
- Day 167 position bias 数据是这 60 天里给我"震撼最大"的瞬间——单次 LLM judge 偏好 position A 高达 62%,远超我的预期。从那天开始我对所有 LLM-as-judge 数据保持警惕,强制 position flip。
- Day 175 红队 200 case 跑完报告时发现:5 类金融场景特有漏洞全部不在 OWASP 标准库。这件事让我对"安全是上线后做"的心态彻底翻转——红队必须在上线前。
3. 产出作品集清单
- 60份每日深度笔记 —
docs/daily/EXPERT-DAY121.md~EXPERT-DAY180.md,约 36,500 行。 - 完整RAG系统 —
rag_v3/:hybrid(BM25+Dense+RRF)+ rerank(bge-reranker-v2-m3)+ hierarchical(parent-child auto-merging)+ agentic(self-correct + ReAct fallback)+ multimodal(PDF 表格/图)+ graph(KG + community detection)。FastAPI + Qdrant + Prometheus + Grafana。线上 Recall 0.95 / Faithfulness 0.93。 - Multi-agent框架 —
multi_agent_v1/:含 3 种协作模式(sequential / hierarchical supervisor / network debate)+ 4 层 memory(working / short-term episodic / long-term semantic / procedural)+ MCP tools + onchain session-key execution。 - LLMOps工具链 —
eval_pipeline/(deterministic + LLM judge + golden set)+ Langfuse tracing + GitHub Actions CI +guardrails/(输入/主题/PII/输出多层防御)+ red team 报告生成器。 - 金融研究AI Agent v1 —
finance_research_agent_v1/(生产级,from Day 177-178)。整合 RAG + Multi-agent + Eval + Guardrails + Onchain tools。详见docs/FINANCE_AGENT_PROJECT.md。 - 1份22+页《生产级AI系统工程方法论》白皮书 —
docs/AI_ENGINEERING_METHODOLOGY.md(Day 179 产出)。从 Spec → Prompt → RAG → Agent → Eval → Production 的完整 SOP,可直接复用到下一个 AI 项目。 - 1份30题AI面试集 — File 2(本日附件
EXPERT-DAY180-INTERVIEW.md)。
3.1 关键代码模块明细
| 模块 | 路径 | 核心能力 | LoC |
|---|---|---|---|
transformer_demo | code/ai/transformer/ | numpy 实现的 multi-head attention(Day 121) | ~280 |
prompt_lib | code/ai/prompt/ | CoT/ToT/SC 模板 + 评估器(Day 126-128) | ~620 |
rag_v1/rag_v2/rag_v3 | code/ai/rag/ | 三代 RAG,含 hybrid/rerank/hierarchical/agentic | ~2,800 |
multi_agent_v1 | code/ai/agent/ | 3 拓扑 multi-agent + memory + tools | ~1,900 |
eval_pipeline | code/ai/eval/ | deterministic + judge + golden three-tier | ~840 |
guardrails | code/ai/safety/ | 多层防御 + red team script | ~720 |
finance_research_agent_v1 | code/ai/finance_agent/ | 端到端整合 capstone | ~2,040 |
| 总计 | - | - | ~9,200 |
3.2 各组件性能对照表
| 组件 | Baseline | After optimization | Lift |
|---|---|---|---|
| RAG Recall@10 | 0.86 (rag_v1) | 0.95 (rag_v3) | +9 pts |
| RAG Faithfulness | 0.78 | 0.93 | +15 pts |
| Cost per query | $0.078 | $0.014 | -82% |
| Avg latency p99 | 4.2s | 1.6s | -62% |
| Agent task success | 0.72 (single ReAct) | 0.91 (multi-agent supervisor) | +19 pts |
| Hallucination rate | 4.2% | 0.5% | -88% |
4. 能力自评(对照Phase 3检验标准)
| 能力点 | 评分 | 证据 |
|---|---|---|
| 能解释何时用RAG、何时用长上下文、何时fine-tune | 9/10 | Day 145 实测 cost/latency/quality 三维对比;Day 172 出决策树;rag_v3 用了"按 query 路由"策略,不是 one-size |
| 能设计eval体系覆盖deterministic+LLM judge+golden set | 9/10 | Day 166-169 完整三层 eval pipeline 跑通 CI;Day 167 用 position-flip + Cohen's κ 校准 LLM judge;金融 100 条 golden 集已分层(事实/推理/合规/拒答) |
| 能用LangGraph/MCP构建agent | 8/10 | Day 156 LangGraph state graph + Day 153 MCP server;multi_agent_v1 是真实运行的;MCP 还没在多 client 场景下深用 |
| 能用prompt caching+batch API把成本砍80% | 9/10 | Day 164 实测 -82%(70% cache hit rate);finance_research_agent_v1 默认启用;理解了 cache miss 反而更贵的边界 |
| 能识别并防御prompt injection | 8/10 | Day 174 多层 guardrails(LLM Guard + NeMo + Presidio);Day 175 红队 200 case 报告;但金融场景定制对抗仍在迭代中,不能说"完全防御" |
总评:完成度 5/5 + 7 项硬性产出全部达成。
- 自评等级:从"prompt 用户"切换到"AI 系统架构师"区间的下沿(Senior AI Engineer / AI Architect Junior level)。
- 与目标"AI×Web3 PM/AI架构师"差距:
- 没差距:架构方法论、eval 工程化、cost/latency/safety 三角权衡 — 已经能在 mid-senior 面试里站住。
- 仍有差距:(a) 真实千万 DAU 级流量下的稳定性运营经验;(b) 多模态视觉/语音生产级经验;(c) zkML / 可验证 AI 推理(Phase 4 会补一部分)。
4.1 Phase 3 检验标准之外的能力盘点
除了官方 5 项检验标准,60 天还产生了一些"溢出能力":
| 能力 | 评分 | 证据 |
|---|---|---|
| 能用 numpy 实现 Transformer forward pass | 8/10 | Day 121 ~280 行可运行代码,验证与 PyTorch 一致 |
| 能用 vLLM 部署 7B 开源模型 | 7/10 | Day 163 用 PagedAttention 部署 Mistral-7B + LoRA on GCP T4 |
| 能用 LoRA / QLoRA fine-tune | 7/10 | Day 173 用 Unsloth + 4-bit quant + 16GB 显存训完金融 Q&A LoRA |
| 能写完整的 LLMOps CI 流水线 | 9/10 | Day 169-171 GitHub Actions + 三层 eval + 灰度发布 |
| 能设计领域 RAG 的 chunk / embed / rerank 全 pipeline | 9/10 | rag_v3 全套上线指标 |
| 能识别 / 写 prompt injection 攻击 | 8/10 | Day 175 200 case 红队 |
| 能用 Anthropic SDK 写产品级 agent | 9/10 | finance_research_agent_v1 直接用 SDK,不依赖 framework |
4.2 与"AI×Web3 PM/AI 架构师"目标的差距分析
目标岗位常见 JD 要素 vs 我现在的状态:
| JD 要素 | 我达成度 | 差距 |
|---|---|---|
| Build production LLM apps | 9/10 | 缺真实千万 DAU 流量 |
| RAG / agent architecture | 9/10 | 多模态生产级仍待补 |
| Prompt engineering at scale | 9/10 | 已经过 SOP、CI、灰度 |
| LLMOps (cost / latency / eval) | 9/10 | 缺多机房 / 多区域部署 |
| Safety / red team | 8/10 | 缺真实对抗事件响应 |
| Domain expertise (finance) | 10/10 | 这是 PM 强项 |
| Web3 integration (onchain agent) | 9/10 | session key / x402 已 demo |
| zkML / verifiable AI | 3/10 | Phase 4 要补的 |
| Distributed training / scaling | 4/10 | 不会做,但 PM 不强需要 |
| CUDA kernel 优化 | 2/10 | 不需要——交给底层工程师 |
结论:在"AI 架构师 / AI engineering lead PM"方向上已经齐了 80%;在"AI Researcher"方向上仍差至少 6-12 月研究经验。求职定位应坚定走"应用 AI 架构师 + 金融领域 PM"路线,不和研究员路线竞争。
5. Phase 3关键认知突破(7条)
5.1 "Agent 的本质不是更聪明的 Chatbot"
我之前以为 agent 就是 "更智能的 chatbot"。但深度研究 Day 149-162 之后发现:agent 的本质是 "reasoning + tools + state" 三件套的循环。没有 state 就只是 "function-calling chatbot",没有 reasoning 就只是 "workflow"。这个区分非常重要——它直接决定了我在面试里怎么回答 "什么时候用 agent vs workflow",也决定了系统设计时该不该引入 agent 的复杂度。LangGraph 把 state 显式化是工程最佳实践;CrewAI 隐藏 state 在生产 debug 时是灾难。
5.2 "RAG vs 长上下文不是二选一,是按 query 路由"
Day 145 实测之后我认知更新了:简单事实查询走 RAG(成本 1x,延迟 200ms);复杂跨文档分析走 长上下文 + caching(成本 2-3x,延迟 1.5s,但 faithfulness 高 12 点)。生产级系统应该有一个 query classifier 做路由,不是用一种模式打天下。这个洞察直接救了 rag_v3 的设计 — 一开始我想"all-in long context",跑了一周成本爆炸;切换到路由后成本降 60%、平均质量反而更高。
5.3 "Multi-agent 最难的不是分工,是协调层"
之前以为 multi-agent 就是"每个 agent 各司其职"。Day 159-162 之后我才意识到:worker 设计是简单的——给每个 agent 清晰的 tool 和 prompt 即可;难的是 coordinator——它要决定谁先发言、谁拿到上下文、谁的输出被采信、什么时候停止。AutoGen 的 group chat、CrewAI 的 process、LangGraph 的 supervisor 三种范式各有取舍:debate 协议精度高但贵、supervisor 快但单点故障、network 灵活但难收敛。Coordinator 的设计决定了系统性能上限——这是最反直觉、也是被最多教程忽略的一点。
5.4 "LLM-judge 的 position bias 比想象的严重"
Day 167 我做了一个对照实验:用 LLM 当 judge 评 100 对 (A, B) 答案。结果发现单纯的 pairwise 评分里,LLM 偏好"先出现的那个"(position A)的概率达 62%——这不是噪声,是系统性偏差。必须做 position-flip + 计算 Cohen's κ 校准才能产生可信信号。这点在大多数 prompt eval 教程里只字未提,但金融决策场景下偏差直接 = 错误的 ranking 信号。
5.5 "Prompt Caching 不是默认开就好"
Day 164 让我意识到 caching 有个临界点:cache hit rate < 50% 时,反而比不缓存更贵(写缓存的 base price 是 1.25x token cost)。所以"启用 caching 就能省钱"是错的;正确做法是先观测 hit rate,再决定。这个 economic intuition 在产品层很关键——它决定了我在 finance_research_agent_v1 里把 system prompt + tool catalog(高 hit rate)塞进 cache,而把 user query(低 hit rate)放外面。
5.6 "Eval 不是事后审核,是开发闭环"
最反直觉的一点:没有 eval pipeline 之前我以为'写完 prompt → 上线';有了之后我意识到 prompt 改一行就要跑 100 条 golden set + LLM judge。这彻底改变了我的开发节奏——慢了 30%,但 production 事故降到接近 0。Day 169 跑通 CI 那天的体感是"AI 产品终于像软件了",而不是"AI 产品像玄学"。
5.7 "Red Team 必须自己做"
Day 175 跑 200 个攻击 case 之后,5 类金融场景特有漏洞(套客户持仓、伪造合规口径、价格预测越权、跨权限套利、token 泄漏)全部不在 OWASP LLM Top 10 的标准 jailbreak 库里。第三方 benchmark 永远滞后——它只能验证"通用安全",不能保证"领域安全"。任何严肃的金融 AI 产品上线前必须自己写 red team script。这条是把我从"Web2 安全 PM 心态"逼向"Web3 攻防红队心态"的拐点。
5.1 7 条认知突破的可面试化
每条 7 条认知突破都可以独立成为一道面试问题的"我的观点"段落。建议在面试时主动抛出 1-2 条作为"思考深度"信号——比如当面试官问"你怎么看 multi-agent",主动回答"我之前以为 multi-agent 越多越聪明,但 Day 159 实测后发现 3-agent debate 比 single-agent ReAct 慢 4x 贵 5x 但准确率只提升 8%——所以多 agent 是工具不是默认"。这种带数字的"反直觉认知"会让面试官眼前一亮。
6. Phase 1+2+3 协同优势
6.1 跨 3 个 phase 的稀缺组合
| Phase | 主线能力 | 关键标签 |
|---|---|---|
| Phase 1 (Day 1-60) | 机构级 DeFi / RWA / 合规 | DeFi protocols, lending, RWA, compliance |
| Phase 2 (Day 61-120) | 量化 / 微观结构 / MEV | Quant, market microstructure, MEV, DEX |
| Phase 3 (Day 121-180) | AI 系统工程 / Agent | LLM, RAG, Agent, LLMOps |
叠加效应(不是 1+1+1=3,而是 1+1+1=8):
- 机构 DeFi × Agent:能为机构钱包/RWA 平台设计带 session-keys 的 onchain agent(Day 161 已 demo)。市面上 99% 的 agent 项目要么是 toy chatbot 要么是 retail meme bot;带合规护栏 + 机构托管对接的 agent 是极少数。
- 量化 × Agent × LLMOps:能做 "AI 量化研究 agent"——把 alpha discovery 从 quant 手工流程,自动化到 agent + RAG + eval pipeline。这是 Hudson River、Citadel、Jane Street 内部正在做的事。
- RWA × LLM × 合规:能为合规问询/法规查询/合同审核做生产级 RAG(领域语料 + 严格 faithfulness eval)。这是 EY、Deloitte、Chainalysis 在烧钱招的方向。
6.2 可瞄准的稀缺岗位
| 岗位类型 | 雇主类型 | 我的匹配度 |
|---|---|---|
| Institutional AI Research Agent Engineer | hedge fund / prop trading / Anthropic forward deployed | 9/10 |
| DeFAI Protocol PM | Eigenpie, Mode, Wayfinder, Virtuals | 8/10 |
| RWA AI Advisor / Compliance RAG Lead | Ondo, Securitize, Centrifuge, MakerDAO RWA team | 9/10 |
| AI Agent PM (Onchain) | Coinbase Wallet, Phantom, Privy, Argent | 8/10 |
| Quant Research AI Engineer | Jump Trading, Two Sigma, Wintermute (cross side) | 7/10(量化代码经验仍是 mid-senior 边界) |
| AI Architect for Fintech | Stripe, Adyen, Robinhood AI team | 9/10 |
| Forward Deployed Engineer (Anthropic/OpenAI) | Anthropic FDE, OpenAI Solutions | 8/10(缺真实 enterprise 部署) |
6.3 简历组织调整建议
## Profile (1 行)
10-yr Finance/Retail PM-BA-Dev → Web3 architect specializing in
AI agents × institutional DeFi × quant research, with full-stack
LLMOps practice and 7 production-grade artifacts.
## Highlights (3 条)
- Built finance research agent v1: RAG (Recall 0.95) + multi-agent
(3 协作模式) + onchain session-key tools + eval pipeline + red team
- Reduced LLM cost 82% via prompt caching + batch API on production-
level financial query system; full LLMOps stack design
- 270-day expert-track learning: Phase1 institutional DeFi/RWA,
Phase2 quant/microstructure/MEV, Phase3 AI engineering
## Project section 顺序(强→弱)
1. Finance Research AI Agent v1 (Phase 3 capstone)
2. RAG v3 production system (Phase 3)
3. mm_bot / mev_bot (Phase 2)
4. Strategy Library v1 (Phase 2)
5. Institutional DeFi/RWA artifacts (Phase 1)
6.4 简历版本控制策略
随着 Phase 4 完成,简历应有 4 个版本(按目标岗位裁剪):
| 版本 | 目标岗位 | 突出内容 |
|---|---|---|
| AI Engineer 版 | AI 架构师 / AI Eng Lead | Phase 3 capstone + LLMOps + 7 项作品 |
| Web3 PM 版 | DeFi / DePIN / RWA PM | Phase 1 + Phase 3 onchain agent + 产品分析 |
| Quant Researcher 版 | 量化研究 / Crypto fund | Phase 2 strategy lib + Phase 3 AI agent |
| 全栈 Web3 架构师版 | 综合性 senior 岗位 | 三 phase 协同 + 270 天系统化学习 |
核心建议:不要"一份简历投全部"。按岗位 JD 关键词裁剪每版的 highlights。10 年金融 PM 背景 + 270 天 Web3 + AI + 密码学的全栈学习是稀缺信号——但只在精准匹配的岗位上才会被识别。
7. Phase 4 启动准备(密码学工程, Day 181-270)
7.1 与前 3 个 phase 的连接
| Phase | 性质 | 与 Phase 4 的接口 |
|---|---|---|
| Phase 1 | 业务/合规/产品 | Phase 4 zkRollup/隐私 RWA 直接对接 |
| Phase 2 | 数学/微观结构 | Phase 4 EC/finite field/lattice 数学是 Phase 2 概率/线代的延续 |
| Phase 3 | AI 工程 | Phase 4 zkML / 可验证 AI 推理直接补 Phase 3 缺失的部分 |
核心连接点:密码学是另一种工程化体系——和 Phase 3 的 AI 工程一样,从理论到生产有完整 stack。Phase 4 不是"换一个领域学",是"补完整 stack"。
7.2 Phase 4 前置准备清单
- 数学复习:群论 / 环 / 域 / 椭圆曲线基础(每天 30 分钟,1 周)
- Rust 环境:rustup + cargo + 基础语法(已有 SC plan 部分覆盖)
- Circom 工具链:snarkjs + circom 2 + powersOfTau ceremony 文件下载
- zkML 工具:EZKL + Giza + opML(Day 181-187 第一周会用到)
- 参考资料:Vitalik zk-SNARK 系列、ZK Hack 教程、Berkeley CS 294-118
- 硬件:本地 GPU(zkML proof generation 极吃显存)— 已确认 RTX 4090 24GB 够用
7.3 心态调整
Phase 4 是 4 个 phase 里最难的,原因有三:
- 数学密度高:BLS/Pedersen/KZG/lattice 都需要硬数学;不能跳过推导。
- 周期长:90 天而非 60 天,体力消耗更大。
- 工具链不成熟:和 LLM 不同,zk 工具链还很 alpha,很多教程过时。
应对原则:
- 够用即止 + 自己推一遍:所有协议至少手算一次小案例(Day 1: 用 11 阶椭圆曲线手算 Pedersen commitment)。
- 每周一次 capstone:每周末必须有可运行的小 demo(不只是笔记)。
- 不和数学博士比深度:我不是要做密码学研究员,是要做"会用、能审、能架构"的 PM。
7.4 第一周(Day 181-187)的具体准备
| Day | 主题 | 实操产出 |
|---|---|---|
| 181 | 椭圆曲线基础(secp256k1, BLS12-381 数学) | 在 Python 里手写 EC point add |
| 182 | Pedersen commitment + Schnorr signature | 实现 11 阶有限域上的 toy demo |
| 183 | KZG commitment 数学推导 | 跑通 arkworks-rs 的 KZG demo |
| 184 | zk-SNARK 概览 + R1CS / QAP | 把一个 ((a + b) * c == d) 转成 R1CS |
| 185 | Groth16 vs Plonk vs Halo2 对比 | 写一份选型文档 |
| 186 | 第一个 Circom 电路 | 写一个 "证明知道 x 使 hash(x) == y" 的电路 |
| 187 | Week 28 复习 | 整合本周笔记 |
7.5 Phase 4 与 Phase 3 学习方法对比
| 维度 | Phase 3 实际做法 | Phase 4 调整 |
|---|---|---|
| 每日产出 | 笔记为主,部分日有代码 | 每天必须 commit 一个可跑 demo(哪怕 50 行) |
| 数学密度 | 中(attention/RAG 数学) | 高(EC / FFT / lattice) |
| 工具链稳定性 | 高(Anthropic SDK 稳定) | 低(zk 工具仍 alpha) |
| 复习节奏 | 每周一次 review | 每两周做一次模拟面试 + 概念关系图 |
| 与社区互动 | 较少 | 每周参加 1 次 zk reading group / Discord |
| Capstone | 14 天一次(rag_v3 / multi_agent_v1) | 每两周一次小 capstone(zk 电路 / FHE 加密) |
7.6 Phase 4 的"求职窗口"考虑
按 270 天计划,Phase 4 收官 2027-01-26。这是一个关键的求职时间窗:
- Q1 是 Web3 招聘旺季(很多 fund 1月发奖金后开始流动)
- AI 行业 Q1 也是招聘高峰(H1 budget 释放)
- 270 天总作品集 + 完整白皮书 + 5 大方向能力 = 极完整 portfolio
建议:Phase 4 进行到 Day 240 左右(2026-12-26 前后)开始第一波试投——有项目就投,缺点就借面试反馈补。等到 Day 270 全完才投是浪费时间窗。
8. 给 6 个月后的自己的一封信(写给完成 Phase 4 那天的自己)
致 Day 270 的我:
如果你正在读这封信,那就是 2027-01-26 左右,Phase 4 收官。我现在是 Day 180 的我,刚完成 Phase 3。
我想告诉你 Phase 3 最深的感受:60 天前我以为"用 LLM 做产品"和"懂 LLM 做架构"是一回事,60 天后我才知道是两个完全不同的世界。Phase 3 让我从 prompt 用户变成 AI 工程师,从"会调"变成"能审"。这种身份切换的快感,我希望你 Phase 4 完成时也能感受一遍——只不过这次是从"用 zk 概念"变成"能设计 zk 系统"。
跨 3 个 phase 180 天最大的变化是什么?是对"系统"的理解从 PM 视角下沉到了架构师视角。一年前我看一个产品想的是"用户旅程 / 转化漏斗 / GMV";现在我看一个产品先想"throughput / latency / cost / safety / observability"。这不是说 PM 视角不重要,而是我多了一个"实现层"的眼睛。这个眼睛会让我在面试和工作里更值钱。
对最后 90 天(Phase 4),我期待的是补完整个 trust stack——AI 系统工程让我懂"如何让模型可靠",密码学工程会让我懂"如何让计算可验证"。两件事合起来就是 Web3 时代严肃产品的全部地基。我担忧的是数学难度——Phase 2 的随机过程已经摸到我能力上限,Phase 4 的代数几何/格密码可能更难。但我已经决定不和数学博士比深度,只比"能用、能审、能架构"。
具体提醒:如果你在 Phase 4 卡住超过 3 天——回看 Day 162(multi_agent_v1 整合那天)的笔记。那天我也卡了 3 天,最后是把所有零件画在一张 A3 纸上才理顺。Phase 4 任何复杂概念都先画在纸上,不要直接写代码。
最后,恭喜你走完 270 天。这件事 80% 的人开始一周就会放弃,剩下 18% 会在 60 天放弃,2% 撑到 180 天,最后到达 270 天的可能不到 1%。你已经做了一件大概率上不可能的事。把白皮书发出去,把作品集打包,开始投简历。求职这场仗才是真正的考验。
— Day 180 的你
9. 致谢与反思
9.1 Phase 3 最反直觉的 1 件事
LLM-judge 的 position bias 远超想象(62% 偏好 position A)。这件事彻底改变了我对"用 LLM 评 LLM"的信心——它不是"AI 评 AI 一定有偏"这种笼统认知,而是具体到一个可量化、可校准、可追踪的工程问题。Day 167 跑完 ablation 之后我盯着那张图看了 20 分钟。
9.2 浪费时间最多的事
前两周(Day 121-128)在 prompt techniques 上花了过多精力做对比实验。后来发现 Claude 4.7 的能力上限远超大多数 prompt 技巧带来的边际收益——CoT/ToT/Self-consistency 在 Claude 4.7 上有时反而损害质量。如果重来一次,我会把那 4 天压缩到 2 天,省下的时间投到 RAG eval 和 agent observability 上。
9.3 改进 Phase 4 学习方法的 3 个具体动作
- 每天必须有"可运行 artifact" — Phase 3 部分日子只有理论笔记没有代码,复习时回看不直观。Phase 4 强制每天 commit 一个可跑的 demo(哪怕 50 行)。
- 每周末画"概念关系图" — Phase 3 是写 Week 复习,但概念关系靠文字描述。密码学概念(commitment / proof system / setup ceremony)相互依赖更深,必须画图。
- 每两周做一次"模拟面试" — Phase 3 的面试题集是收官那天才整理的,时间晚了。Phase 4 应该每两周做一次自测,把模糊概念暴露出来当下补。
10. 跨 Phase 知识图谱(180 天累计)
Phase 1 (Day 1-60) Phase 2 (Day 61-120) Phase 3 (Day 121-180)
机构 DeFi / RWA 量化 / 微观结构 AI 系统工程
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
业务 / 合规 │ 机构产品形态 │ │ │ │ 金融 AI 合规问询 │
│ KYC/AML/MiCA │ ────────→ │ │ ────────→ │ 拒答策略 │
│ 托管 / Prime │ │ │ │ Red team 金融 │
└──────────────────┘ └──────────────────┘ └──────────────────┘
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
核心数学 │ 概率 / 期权基础 │ │ Itô / SDE / BS │ │ Attention 数学 │
│ │ ────────→ │ A-S / GLFT │ ────────→ │ Embedding 几何 │
│ │ │ HRP / 协方差 │ │ Position encoding │
└──────────────────┘ └──────────────────┘ └──────────────────┘
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
核心系统 │ Lending v2/v3 │ │ mm_bot / mev_bot │ │ rag_v3 生产系统 │
│ Stablecoin │ │ Strategy Lib v1 │ │ multi_agent_v1 │
│ RWA tokenization │ │ │ │ finance_agent_v1 │
└──────────────────┘ └──────────────────┘ └──────────────────┘
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
工程化能力 │ Solidity 阅读 │ │ Backtesting │ │ LLMOps Stack │
│ DeFi 合约审计 │ ────────→ │ Risk管理框架 │ ────────→ │ Eval / Guardrails │
│ │ │ MEV bundle │ │ Cost optimization │
└──────────────────┘ └──────────────────┘ └──────────────────┘
跨 phase 桥接点:
- Phase 1 RWA + Phase 3 RAG = "合规问询 AI"(Day 144 实战)
- Phase 2 Strategy + Phase 3 Agent = "AI 量化研究 Agent"(Day 177-178 capstone)
- Phase 1 Onchain + Phase 3 Session keys = "Onchain AI Agent"(Day 161 demo)
- Phase 2 MEV + Phase 3 Tool design = "MEV searcher agent"(潜在 Phase 4 项目)
这些不是巧合——这是 270 天计划的整体设计。每个 phase 都不是孤立学习,是为下一个 phase 提供素材,最终在 Phase 4(密码学)合龙成"Web3 严肃产品的全 stack 架构能力"。
11. 数据:60 天产出对照表
| 类别 | 数量 / 体量 | 备注 |
|---|---|---|
| 笔记天数 | 60 | Day 121-180 全勤 |
| 笔记总字数 | ≈ 36 万字 | 中文为主 |
| 代码 LoC | ~9,200 | Python 为主,少量 TypeScript(agent UI) |
| 模型 fine-tune | 1 次 | LoRA on Mistral-7B for finance Q&A (Day 173) |
| Eval 跑次 | 800+ | 累计 deterministic + judge + golden 总跑次 |
| Cost 实测降幅 | -82% | finance agent v1 优化前后 |
| RAG Recall 提升 | 0.86 → 0.95 | rag_v1 → rag_v3 |
| RAG Faithfulness 提升 | 0.78 → 0.93 | 加 reranker + guardrails 累计 |
| 红队 case | 200 | OWASP + 金融定制 |
| 高频核心面试题 | 6 ⭐ | 见 File 2 |
| 全套面试题 | 30 + 散落 ~140 | File 2 + 各日笔记内 |
| 长报告 | 5 | SOP / RAG report / multi-agent design / LLMOps blueprint / Methodology whitepaper |
12. 收官 / Closing
Phase 3 60 天,从 Transformer 数学到 LLMOps 蓝图,从 prompt SOP 到 finance research agent v1,从 LLM 黑盒到 production stack。
回头看 Day 121 的开篇那句话——"我担心的是用了两年 LLM 工具之后,依然停留在'调 prompt'层级"。今天我可以说这件事没有发生。从 attention 数学到 vLLM 部署、从 RRF 调参到 LangGraph state 管理、从 LLM judge 校准到 OWASP 红队——我已经能在中高级 AI 工程师的层级上做架构决策、做评审、做选型。这不是终点,是新起点。
不是终点,是 Phase 4 的起跑线。
明天 2026-10-29,Day 181,Phase 4「密码学工程」开启。学的是 zk-SNARK / 椭圆曲线 / lattice / FHE / zkML / 可验证 AI 推理。这是 Web3 严肃产品的最后一块地基——和 Phase 3 的 AI 系统工程合起来,就是"trustworthy computation for finance"的全 stack。
留个标记:当你读到 Day 270 收官那天,回头看这一行 — 你已经走完了 270 天。
那一刻,这份 270 天计划就完成了它的使命:把一个 10 年金融 PM 改造成 Web3 全栈架构师。
— end of Phase 3 —