同一个目标，「要求大家用 AI」和「降低 Review 成本」，前者推了半年没动，后者三个月到了 70%。

「这个问题我好像在哪儿见过。」—— 大部分重复踩的坑，都是这 8 个结构之一。

线性思维告诉你「A 导致 B」。系统思维追问的是：A 和 B 之间那条看不见的线是什么。

---

RAG 工程化实战:分层评估、查询转换、分块与 Agentic 实现

RAG 学习 Day 2 下半部分。
关键字:分层评估 / MRR vs MAP / 忠实度 / 查询转换 5 方法 / Step-back / 自适应 RAG / 分块策略 / Rerank / CRAG / Agentic RAG 实现。

---

📌 写在前面

上一篇讲了 RAG 的五种范式和演进。但范式只是"选哪条路"。

真正决定效果的是路上怎么走。

我把这部分过了一遍，最大的感受是：

RAG 的效果问题，90% 不是"要不要上 GraphRAG"，而是"你能不能定位是哪一层坏了"。

这篇讲工程化的四件事：

1. 分层评估 —— 定位问题出在哪一层
2. 查询转换 —— 5 种方法怎么选
3. 分块策略 —— 唯一没有 ground truth 的环节
4. Agentic RAG 实现 —— 自主决策的约束机制

---

---

RAG 基础与五种范式演进:从链式检索到自主决策

RAG 学习 Day 1-2 上半部分。
关键字:RAG 五组件 / Naive → Advanced → Modular → Graph → Agentic / GraphRAG / Leiden 社区检测 / Local vs Global / 范式选型决策树。

---

📌 写在前面

RAG 这两个字现在有点被用滥了。什么"我们做了 RAG 系统"，什么"RAG 落地最佳实践"，翻开一看全是"文档切块 → 向量化 → 检索 → 拼 prompt"。

这套四步流程没错，但它只是起点。

我花了两天把 RAG 的五种范式过了一遍（Naive / Advanced / Modular / Graph / Agentic），最大的感受是：

RAG 不是一种技术，是一条谱系。选错范式的代价，比调错参数大 10 倍。

这篇讲基础和范式演进。工程化那部分（分层评估 / 查询转换 / 分块策略 / Agentic RAG 实现）单独一篇。

---

---

Claude Code 架构精读:从 30 行循环到独立判断器

精读开源项目 shareAI-lab/learn-claude-code 的三个核心 session。
关键字:Agent Loop / Integrated Harness / Goal Loop / 独立判断器 / Hooks / 权限边界。
系列位置:9-16 Harness 工程 → 9-17 AI Coding 工程 → 9-18 Agent Loop → 9-20 Harness 全家福 → 本文(读别人的 harness 实现)。

---

📌 写在前面:这次讲什么,怎么讲

前 4 篇 Harness 系列是我自己搭的。这一次不一样 —— 我在读一个把 Claude Code 剥到只剩骨架的开源项目,442 个文件,17 个 session,中文文档齐全。

我挑了三个 session 精读:

Session	代码量	一句话
s01 Agent Loop	120 行	一个 while True + 一个 bash = 一个 Agent
s15 Integrated Harness	3326 行 / 158 函数	26 个工具 + 15 个机制,全挂在同一个循环上
s17 Goal Loop	903 行	模型说停不算停,独立判断器说了算

讲法我改了:前几篇我是"先讲架构,再举例"。这次反过来 —— 先说你在什么处境下会需要它,再给能直接抄的样例,最后才拆架构。

因为 11 年经验的人不需要"这是什么",需要的是"这玩意解决我什么问题、我什么时候用、怎么用"。

---

---

DDD 进阶:从领域事件到四层架构的实战体系

Day 3 进阶篇,2 波素材整合。
关键字:领域事件 / 最终一致性 / 事务边界 / 四层架构 / 严格分层 / 聚合演进 / 职责分层 / 仓储分层 / 4 大误区。
DDD 基础篇(9-24)讲"业务怎么切 + 代码怎么写",本文讲"怎么用得起来,怎么不踩坑"。

---

📌 一句话核心

"DDD 进阶 = 领域事件解耦 + 四层架构落地 + 严格分层 + 4 大误区防范。"
领域事件 = 已发生的业务事实,过去时命名,跨上下文用最终一致性;
四层架构 = 用户接口 + 应用 + 领域 + 基础,严格分层,领域层零技术依赖;
误区 = 不写三层架构的伪 DDD,不写应用层业务,不拆 1 聚合 = 1 微服务,不让领域服务啥都干。

---

---

DDD 架构模式:从整洁架构到六边形架构的统一视角

Day 4 架构模式,2 波素材整合。
关键字:整洁架构(洋葱)/ 六边形架构(端口适配器)/ 防腐层(ACL)/ 三种架构本质相同 / 5 大核心要点。
DDD 进阶篇(9-27 上)讲"领域事件 + 四层架构 + 误区防范",本文讲"整洁 + 六边形 + ACL"——统一视角看架构模式。

---

📌 一句话核心

"DDD 架构模式 = 整洁架构(洋葱同心圆)+ 六边形架构(端口适配器)+ 防腐层(ACL),三种本质相同。"
整洁架构讲分层,六边形架构讲端口适配器,DDD 四层架构讲职责划分;
三种架构本质相同:领域模型在中心,依赖指向内层,内层定义接口,外层实现接口,技术细节可替换;
防腐层(ACL)= 保护下游领域模型不被外部污染的翻译隔离层。

---

---

DDD 基础:从战略设计到战术设计的完整体系

整合 9-22 战略设计 + 9-24 战术设计(Day 1+Day 2)。
关键字:战略 5 件事 / 子域 3 类 / 通用语言 / 限界上下文 / 3 个空间 / 实体 / 值对象 / 聚合 / 聚合根。
这是 DDD 3 天计划的"基础篇"(Day 1 + Day 2),Day 3 是实战篇。

---

📌 一句话核心

"DDD 不是设计模式,不是架构,是一种服务业务的设计思想。"
战略设计 = 在业务视角下划清边界 + 统一语言;
战术设计 = 在技术视角下实现业务规则。
两者形成完整的'从业务到代码'的桥梁。"

---

---

DDD Day 1 — 战略设计:从业务视角划分领域

今天开始复习 DDD 领域驱动设计,预计 3 天。这是 Day 1(战略设计)。
关键字:战略设计 / 子域划分 / 通用语言 / 限界上下文 / 事件风暴 / 上下文协作。
关联:AgentScope 4 PR 等开源贡献 / 之前项目里大量 DDD 影子,都跟 DDD 直接相关。

---

📌 一句话核心

"DDD 不是设计模式,不是架构,是一种服务业务的设计思想。战略设计 = 在业务视角下,回答 5 个核心问题,划清边界、统一语言、协作流畅。"

---