五槽位模型

每条决策通过五个"槽位"被索引，每个槽位对应一种检索机制。槽位本身是固定的基础设施，槽位内的值由 AI 动态提取。

概览

槽位 1：代码锚点      → 图遍历
槽位 2：关键词        → 倒排索引
槽位 3：决策关联      → 图上的边
槽位 4：元数据        → 结构化过滤
槽位 5：语义向量      → 向量搜索

槽位 1：代码锚点

存什么： 这条决策在代码中的位置。

精度范围：

• 精确： 函数名、文件 + 行号范围、API endpoint（POST /api/v1/orders）
• 模糊： 目录级（order-service/src/auth/*）、repo 级、自然语言（"跟鉴权流程有关"）

怎么检索： coding AI 编辑某个函数时，从该函数节点出发往外走：这个节点有决策吗？调用者/被调用者上有吗？文件级？目录级？服务级？由近到远，每层设数量上限。

多锚点： 一条决策可以锚定到多个代码位置——涉及两个函数或两个服务的决策，每个位置各建一条边。

槽位 2：关键词

存什么： 从决策对话中提取的显式概念词。不区分业务和技术——"退款超时"既是业务概念也是技术实现。

例子： ["退款", "部分退款", "限流", "Redis", "缓存穿透", "TTL 策略"]

怎么检索：

• 被动： coding AI 写代码时，系统从当前代码和注释中提取关键词去命中
• 主动： 人搜索"退款相关的决策"，直接走关键词索引

为什么重要： "退款"、"会员等级"、"风控"这些业务关键词不存在于代码中。它们是人思考问题时最自然的入口——也是 grep 和 AST 永远捕获不到的维度。

槽位 3：决策关联

存什么： 这条决策跟图上其他决策的关系。

关系类型：

类型	含义
CAUSED_BY / LEADS_TO	因果链
CONFLICTS_WITH	张力——各自合理但放一起有 trade-off
SUPERSEDES	新决策替代旧决策
DEPENDS_ON	A 的前提是 B 成立
CO_DECIDED	同一个 session 中一起做出的

怎么检索： 通过槽位 1 或 2 找到一条决策后，沿这些边扩散，把因果链上的关联决策也拉出来。扩散深度可控。

跟槽位 1 的区别： 槽位 1 的边是 代码结构 关系（函数调用函数），槽位 3 的边是 决策结构 关系（决策导致决策）。两种边在同一张图中共存。

槽位 4：元数据

存什么： 决策的生产信息。

字段	说明
created_at	时间戳
owner	谁产生的
session_id	AI 对话 session 标识
commit_hash	产生时的代码版本
source	来源：ai_chat、meeting、manual
confidence	内部字段：owner_confirmed、ai_inferred、auto_generated
staleness	active、stale、archived

怎么检索： 不单独用来发现决策，而是作为过滤器叠加在其他槽位结果上——过滤掉过期的、按时间排序、新的优先。

INFO

confidence 字段仅供内部使用——精炼管线用来判断哪些需要再跑一轮。消费端（你的 coding AI）看不到它，所有决策一视同仁。

槽位 5：语义向量

存什么： 决策完整自然语言描述的向量表示。

怎么检索： 前四个槽位没找到足够结果时，用当前代码片段或用户问题做 embedding 走语义相似度搜索。

为什么是兜底： 语义匹配太模糊（"用户鉴权"和"用户注册"向量空间接近但 context 无关）。前四个槽位有精确信号，能精确就不模糊。

真正有用的场景： 决策的表述方式跟搜索方式完全不同时。讨论"怎么防止重复扣款"→ 搜索"幂等性设计"——关键词不 match 但语义 match。

检索优先级

五个槽位不是平行查询，有严格优先级：

优先级 1：槽位 1（精确代码锚点匹配）+ 图上邻居扩散
优先级 2：槽位 2（关键词命中）
优先级 3：槽位 3（决策关联扩散）— 在前两步命中的基础上触发
优先级 4：槽位 5（语义兜底）
全程叠加：槽位 4（元数据过滤排序）

越前面越精确，越应该优先占用 context window 位置。每层有数量上限。

渐进披露

默认只返回摘要级别的决策。coding AI 觉得某条有用，可以再请求完整内容。MCP 天然支持这个两步模式。