AutoSnippet 开发中的思考与洞察

写在前头

现在 AI 编程的势头真得很猛，它确实做到了大家梦想中的画面，随随便便说一些指令就能搭建起大型项目的复杂架构。这是我三个月使用 AI 开发一个项目的经历，删删减减，折腾得有点久，我现在回过头反思为什么做这么久，答案应该是我在长远目标上的失焦。我常常在开发好一个功能后，才搞清楚功能的意义与项目的关系，这也不完全是我的问题，AI 经常会设计前说一套，完成后说一套，现在的 AI 是流水线上的一次性机器人，上次跟你对话的机器人永远也不会回来了。

但说回来 AI 四处探索，磕磕绊绊的样子也挺可爱的，谁还没个学习的过程呢？

提到学习，现在普通人想要用 AI 编程的成本还是有的，就拿我这项目来说，JS 对普通人应该是非常简单的语言了，但我一直在按照我的工作经验做底层建设，按照现在 AI 乱写乱画的编程方式，如果不懂编程，那我无法想象会是什么样的灾难。

AI 编程看起来降低了门槛，但底层建设仍然需要工程经验，Skills 就是解决这个 gap 的。

Skills 现在更像是新的编程方式，开发者提供 Skills 与工具，普通人通过提示词让 AI 使用。那未来的方向就应该是 普通人让 AI 自己生成 Skills 和工具，不是从应用市场下载的，是完全通过 AI 来创建的。在普通人与编程之间构建一道 Skills 和工具层，这个语义层来决定底层搭建，数据库，数据实体，异步方式，服务注入等等。AI 如果能够自由的锻造工具，那普通人，各个领域的专业人士，面对的就不是一次性机器人，而是一次性机器人给你量身打造的永久性锤子。

当然，我在项目开始时是没想清楚的，我当时唯一能听懂的一句就是向量余弦求相似度。

虽然我没想清楚，但我的直觉是对的，我在试图让现在这个强大的 AI，给我留下有价值的内容。可能因为我的性格使然，当我第一次使用 AI 编程我就想到，这么厉害的能力，用完即弃是一种奢侈的美式浪费。于是诞生了现在的 AutoSnippet，一个符合中式节约主义的项目。

由于很多现实问题，我没办法去做那个自由锻造工具的机器人，但我在做类似的事情：用有限的答案，回答无限的问题。让 AI 分析代码库得出有限的高质量答案，AI 编程时来对知识库进行提问，以获取必要的约束和建议。这里稍微有点绕，但我觉得 AI 编程时有必要对知识库发起提问的，而不是只从网络上寻找资料，这不符合正常程序员的开发逻辑。

这就是我对 AI 短期内的思考，Anthropic 也确实在推出我口中的锻造机器人，但我只能着眼于我当下的事，构建一份绝对正确的参考答案。

时间线总览

Phase 0: iOS Snippet 工具（01-13 ~ 01-26）

做了什么

• 从旧仓库迁移，项目初始定位是 iOS/Xcode 代码片段管理工具
• 核心功能：快速插入常用代码、自动管理 SPM 依赖、头文件注入
• 技术方案：Node.js + 文件系统 + Xcode 集成，支持 ObjC 和 Swift
• 两阶段配置查找：boxspec.json（子模块）→ boxspec.json（根目录）
• 区分同模块 / 跨模块导入（相对路径 vs <Module/Header.h>）

思考与洞察

🔑 洞察 1：配置驱动 > 硬编码 从一开始就选择了配置文件驱动的行为系统（boxspec.json），而非硬编码路径。这个决策在后续多次架构演进中被证明是正确的——配置体系的抽象层为后来的 constitution.yaml 和 boxspec.json 奠定了基础。

🔑 洞察 2：解决”最后一公里”问题 Snippet 工具的核心价值不是「存储代码片段」（这谁都能做），而是「自动补齐 import + SPM 依赖」——让开发者插入代码后能一次编译通过。这个「执行闭环」的思路贯穿了整个项目的进化历程。

Phase 1: AI 能力探索（01-26 ~ 02-01）

做了什么

• 开始思考 AutoSnippet 与 AI IDE（Cursor/Copilot）的关系
• 调研 AI 自动生成代码片段的可行性
• 设计 Agent Skill 机制：Skill = 可复用的 AI 能力单元
• 规划从「Xcode Snippet 工具」到「可执行知识库 / SDK Brain」的愿景
• 业界 AI 代码沉淀方案对比分析

思考与洞察

🔑 洞察 3：互补而非竞争——找到自己的位置 当 Cursor/Copilot 席卷而来时，第一反应可能是恐慌。但深入分析后发现：AI IDE 擅长「智能生成」但难以「标准化」，AutoSnippet 擅长「标准化」但缺乏「智能」。二者是互补关系，不是替代关系。这个认知让项目从「被 AI 干掉」的焦虑中解脱出来，转向「给 AI 做外挂」的定位。

🔑 洞察 4：可执行的知识 vs 可阅读的文档 通过对比 6 大业界方案（Notion/Docs-as-Code/Prompt Library/RAG/Backstage），发现它们的共同问题是知识不可执行。Notion 里写了规范，开发者不看照样违反。关键差异在于：AutoSnippet 的知识单元（后来叫 Recipe）绑定了依赖、import、SPM target，是可执行的工程资产，不是可阅读的文档。

🔑 洞察 5：Skill 的本质不是 Snippet，是「可检索、可推理、可组合的能力单元」 这个概念超越了代码片段的范畴。Skill 有触发条件（trigger）、有输入输出、有依赖声明、有后处理逻辑。它让 AI 从「写代码」变成「调用 Skill」，输出从不可控变为可控。

🔑 洞察 6：三层知识沉淀入口——零成本积累

1. 从代码提炼（选中代码 → 提炼为 Skill）
2. 从问题沉淀（AI 检索失败 → 自动生成 draft）
3. 从文档沉淀（扫描 README 代码块 → 生成骨架） 越用越全，而不是需要专门维护。

Phase 2: 知识库萌芽（02-01 ~ 02-05）

做了什么

• 术语统一：Skill（Agent 能力）vs Recipe（项目知识产出）
• 上下文存储架构：分层设计（Agent 消费层 → 服务层 → 存储适配层 → 持久化层）
• 向量数据库选型：JSON → LanceDB → SQLite-vec 的分级方案
• Dashboard 初版上线，支持知识审核
• 权限体系设计（git push —dry-run 作探针）

思考与洞察

🔑 洞察 7：人审闭环——AI 提议，人决策 这也许是整个项目最关键的设计哲学之一。AI 可以发现模式、生成候选、检测衰退，但最终的「发布到知识库」必须经过人工审核。这不是保守，而是对知识质量的尊重。一条错误的 Recipe 比一条缺失的 Recipe 危害更大。

🔑 洞察 8：护城河在于垂直深度 定位明确后，确立了 5 大护城河：

1. 人审闭环（质量保证，AI 幻觉不会污染知识库）
2. 人机双通道（人和 AI 都能提交候选）
3. 源码指令（as: 指令直接在代码中触发）
4. SPM 深度绑定（解析 Package.swift、Target 依赖关系）
5. 项目级可版本化（知识跟随 Git，而非存在云端）

🔑 洞察 9：可选依赖 = 降低门槛 向量数据库选型的核心原则是「默认零依赖（JSON），按需升级」。LanceDB/SQLite 作为 optionalDependencies，新用户不需要安装任何额外东西就能跑起来。这对开源工具的推广至关重要。

Phase 3: V2 统一架构（02-12）

做了什么

• 一天内完成 V2 架构发布——6 阶段递进式架构
  • Phase 1-2: DI 容器 + 事件驱动 + 三层记忆体系（88 个测试通过）
  • Phase 3-4: 服务层 + 搜索引擎 + Guard 系统
  • Phase 5: Agent 系统（Strategy 模式，14 个组件，31 个测试）
  • Phase 6: 系统集成（链式编排 + 资源池 + 工具编排，35/35 测试通过）
• 总产出：98 个文件，18.5K 行代码，44 个组件，215+ 测试

思考与洞察

🔑 洞察 10：自底向上构建——每层都基于下层 V2 架构的成功在于严格的分层：基础设施 → 领域模型 → 服务层 → Agent → 高级编排。没有跳层依赖，每层只依赖下层。这让后续的每次重构都能在明确的边界内进行，而不是牵一发动全身。

🔑 洞察 11：DI 容器是架构演进的基石 引入依赖注入容器看似「过度工程化」，但它解决了一个致命问题：当 AI Provider 切换时（比如从 OpenAI 换到 Gemini），所有依赖服务需要自动重建。通过 aiDependent 标记，容器可以在热重载时精准清除缓存。后来 45 个服务通过 5 个 Module 注册，证明了这个决策的前瞻性。

Phase 4: Agent 智能化（02-13 ~ 02-19）

做了什么

• v2.1~2.5：知识图谱 + AI 关系发现 + 项目感知 ChatAgent
• v2.7：双 Agent 架构冷启动（Analyst + Producer）
• v2.10：Guard 三级审计
• v2.11~2.13：V3 全链路统一 + Agent Memory 四层架构 + Guard AST 语义规则
• v2.17：搜索引擎单管线统一架构
• v2.19：Native Tool Calling

思考与洞察

🔑 洞察 12：Agent-Pull > Agent-Push 最初的设计是「系统主动推送知识给 Agent」（Push），但实践发现 Agent 需要的信息是动态的、上下文相关的。改为「Agent 按需检索」（Pull）后，知识命中率和利用率显著提升。Agent 自己知道它需要什么。

🔑 洞察 13：搜索质量决定一切 一个知识库系统，搜索不好用就等于不存在。六信号融合（BM25 + 向量 + 权威分 + 新鲜度 + 使用量 + 分类匹配）将搜索准确率从 70% 提升到 90%，Token 消耗降低 40%。单条搜索结果不准确，整个 Agent 的行为就会偏离。

🔑 洞察 14：冷启动是第一印象 「用户第一次用 AutoSnippet」的体验决定了他会不会继续用。双 Agent 冷启动（Analyst 分析项目结构 → Producer 生成 Recipe 候选）让空知识库能在 510 分钟内产出 2040 个候选条目。第一印象如果是空空如也的知识库，用户就不会回来了。

🔑 洞察 15：决策会被遗忘——Agent 长对话的结构性缺陷 发现一个严重问题：Agent 和用户达成的共识（比如「不禁用 Swift」）只存在于对话上下文中，3-5 轮之后被 LLM 上下文压缩截断，之前的共识就丢了。催生了 record_decision 操作——让 Agent 把重要决策写入持久化层，prime() 每次返回高重要性决策。同一知识多层冗余而非单点存在。

🔑 洞察 16：行为强制 > 温柔提醒 规则写得再清楚，Agent 经常跳过。「第一步」暗示可以跳过，它就真的跳了。解决方案是 MUST/NEVER 硬规则 + 翻译表（用户说「修 bug」= Agent 执行 create）+ 多层冗余（instructions + prime output + hooks output）。同一条核心规则在 4 个层面重复出现，压缩后仍然存在。Agent 不应该被「建议」做事，而是被迫做事。

🔑 洞察 17：Handoff 信息损耗——自然语言是信噪比最低的交接格式 Analyst 的 24 轮 ReAct 循环、多次工具调用的丰富上下文，经过 20+ 正则清洗后只剩 analysisText(string) + referencedFiles(string[])。Producer 无法回溯「why」。改成三层结构化工件（Core 必传发现 / Detail 按需证据 / Raw 审计用追踪），并引入「负空间信号」——明确告诉下游「搜了但没找到的东西，不要猜测」。

🔑 洞察 18：从 20K tokens 到 500 tokens——让 Agent 自己探索 v9 首条 prompt 约 20K tokens，信号质量受限于静态启发式。v10 的 prompt 只含任务描述 + 项目摘要 ~500 tokens，LLM 自主通过 list_project_structure + get_file_summary + semantic_search_code 三个工具探索项目。prompt 瘦了 97.5%，产出质量不降反升。LLM 不是被投喂的执行者，是自主探索的领域大脑。

Phase 5: V3 平台化（02-19 ~ 02-22）

做了什么

• MCP 协议统一：22 个工具，Agent 通过标准协议访问知识库
• 严格提交验证：16 个必填字段，3 层校验
• 跨平台支持：macOS / Linux / Windows 全平台兼容
• web-tree-sitter WASM 迁移：消除 C++ 编译依赖
• 10 语言 AST 支持（Go/Python/Java/Kotlin/Swift/JS/TS/Rust/ObjC/Dart）
• VS Code 扩展：Guard 实时诊断 + CodeAction 快速修复

思考与洞察

🔑 洞察 19：MCP 是统一协议的最佳选择 当需要同时支持 VS Code Copilot、Cursor、Claude Code 时，MCP（Model Context Protocol）成为天然的统一层。不再为每个 IDE 写一遍集成代码，而是暴露标准 MCP 工具，让 IDE Agent 自己调用。这个决策将集成成本从 O(n) 降到 O(1)。

🔑 洞察 20：WASM 取代原生绑定——实用主义胜出 从原生 tree-sitter（C++ 编译，安装频繁报错）迁移到 web-tree-sitter（WASM，零编译依赖），牺牲了约 20% 的解析性能，但换来了所有平台零报错安装。用户不会因为 AST 解析快 20% 而选择你的工具，但会因为 npm install 失败而放弃。

🔑 洞察 21：Guard 规则的质量 = 误报率的管控 Guard 从 261 条违规降到 118 条（-55%）不是因为放松了规则，而是加了 skipComments、skipTestBlocks、excludePaths 等精调机制。一条误报对开发者信任的伤害远大于漏报。Guard 系统必须「宁缺毻滥」。

🔑 洞察 22：存储格式 ≠ 交付格式——四通道交付体系 Cursor 有 4 种知识消费通道：alwaysApply 强制规则、按主题智能注入、Agent Skill 渐进加载、MCP 按需拉取。各有不同的触发机制和 token 预算。知识如果只「存」了不「送」，就等于没有。alwaysApply 只放「绝对不能违反」的约束，≤400 tokens；其余按场景分层交付。这个认知来自适配 Cursor 时的痛苦经历：.md 文件落盘后没有任何机制把它主动推给 Agent。

Phase 6: 搜索与质量深化（02-22 ~ 03-09）

做了什么

• 多语言 Discoverer 体系：Node/Go/Jvm/Python/Dart/Spm/Generic 独立识别
• CallGraph 静态分析引擎：跨文件调用图构建
• FileManifest + FileDeployer 统一部署引擎（SetupService -59%，UpgradeService -80%）
• Chat Memory 三层架构：ActiveContext / PersistentMemory / SessionStore
• 飞书远程编程桥接

思考与洞察

🔑 洞察 23：类型安全是重构的信心来源 从 v3.2.11 开始的全面类型安全修复（361 个文件，净减 3552 行代码）看似繁琐，但它给了后续每一次大胆重构以信心。catch (err: any) → catch (err: unknown) 不只是语法变化，是「我知道每个错误从哪里来」的工程自信。

🔑 洞察 24：统一部署引擎——从 1350 行到 559 行 SetupService 和 UpgradeService 的逻辑高度相似但各自实现，导致每改一个地方要改两次。引入 FileManifest + FileDeployer 后，用声明式方式描述「应该部署什么文件」，引擎统一执行。代码量减少不是目的，「一处修改，处处生效」才是。

Phase 7: AI-First 转型（03-10 ~ 03-27）

做了什么

• 激进决策：删除全部 iOS 平台特定代码（~50 个文件，1000+ 行）
  • 删除 Xcode IDE 自动化、SPM 集成服务、IDE Snippet 生成
  • 删除 ClipboardManager、NativeUi、ScreenCaptureService
  • 删除 FileWatcher、DirectiveDetector 自动化系统
• 保留核心：Agent Runtime、知识服务、搜索引擎、向量服务、Guard、MCP Server、Dashboard、VSCode 扩展
• AutoDream（Anthropic Memory 2.0）竞品分析
• AI-First 审计：重新评估每个组件的存在价值

思考与洞察

🔑 洞察 25：删代码的勇气——减去 15% 获得 85% 的聚焦 这是整个项目最大胆的决策。AutoSnippet 最初因 Xcode Snippet 而生，现在把这部分全删了。背后的逻辑是：当 AI Agent 通过 MCP 直接消费知识时，IDE 内的 Snippet 自动插入变得多余。与其维护两套交付通道（MCP + Snippet），不如全力做好一套。备份分支 backup/full-platform-services 是安全网，但事后证明不需要回滚。

🔑 洞察 26：知道自己不是什么，比知道自己是什么更重要

• 不是 Notion（协作文档）
• 不是 Copilot（通用代码助手）
• 不是 Backstage（开发者门户）
• 是「项目级可执行知识库」，是 Agent 的外挂记忆

🔑 洞察 27：AutoDream 启示——知识需要「睡眠整理」 Anthropic 的 AutoDream 在 session 结束后自动整理记忆（合并、修剪、重组）。这启发了 AutoSnippet 的知识衰退机制：不再使用的知识应该自动衰减、过时的知识应该被检测和清理。知识库不能只增不减。

🔑 洞察 28：SOUL.md——价值观 > 规则引擎 Claude 的 Constitutional AI 给了一个启发：AI 的行为规范应该是人格文档注入 system prompt，让 AI 「天然就这么想」，而不是运行时逐个校验规则。constitution.yaml 试过做成规则引擎（检查「删除是否有确认」），但这些是输入校验不是价值观。最终创建了 SOUL.md 定义 AI 身份（「我是知识策展人，不是通用助手」）+ 3 条硬约束，灰色地带靠价值观判断。Claude 也只有 7 条 bright lines。

🔑 洞察 29：三层信任模型——安全靠物理边界而非审批矩阵 OpenClaw 189k stars，零治理组件。安全通过环境物理隔离实现，不是每个操作检查权限。AutoSnippet 之前做了 6 角色 × 27 Action 的权限矩阵，实际只有 3 个入口。MCP 工具暴露了什么 = Agent 能做什么，它无法「漂移」到未暴露的能力。删了 ~1090 行死代码（RoleDriftMonitor、SessionManager、ComplianceEvaluator），换成三层：防御性编程（删除前备份）、项目配置（boxspec.json）、工具注册本身就是权限边界。

🔑 洞察 30：@escape-hatch——技术债可视化与渐进式消除 代码里有些 any 和 as 是真的绕不过去的——ORM 限制、动态 SQL、第三方库类型缺失。不是「以后再说」，而是给每一笔债打标签。@escape-hatch(permanent) 承认客观限制，@escape-hatch(temporary) 有对应的 Phase 计划。CI 强制阈值确保债务只减不增，从 71 处降到 12 处经历了 5 个 Phase。

Phase 8: 知识有机体（03-28 ~ 至今）

做了什么

• 统一进化架构（六面体模型）：
  • M1 Panorama（骨骼）：项目全景，Tarjan SCC 耦合分析，Kahn 拓扑分层
  • M2 Governance（代谢）：六态生命周期（pending→staging→active→evolving→decaying→deprecated）
  • M3 Guard（免疫）：三态输出（pass/violation/uncertain），ReverseGuard 反向验证
  • M4 Signal Bus（感觉器官）：9 种信号类型，30s 批量采集
  • M5 Agent（大脑）：自建自消费，宪法 + 置信度路由
  • M6 Tool Forge（造物能力）：动态工具锻造，沙箱验证
• Recipe 可信任性：sourceRefs 证据链
• Task 重设计：从 19 个操作精简到 5 个，多查询搜索 + 场景路由
• 冷启动与增量更新彻底分离（bootstrap vs rescan）
• 搜索路由优化：Weighted-First + Confidence Gate（精确查询从 22s → 40ms）
• 统一数据访问层：「文件 = 真相源，DB = 物化索引」
• 自定义配置发现（支持百度 EasyBox 等自研构建系统）
• 多语言 AST 全管线增强

思考与洞察

🔑 洞察 31：有机体隐喻——知识不是静态文档 这是最深层的思考转变。知识库不是一个「数据库」，而是一个有感知（Signal）、代谢（Governance）、免疫（Guard）、进化（Agent）能力的有机体。就像生物体有新陈代谢一样，好的知识库也应该有：

• 新知识的「消化吸收」（staging 观察期）
• 过时知识的「代谢排出」（decay + deprecate）
• 有害知识的「免疫排斥」（Guard 拦截 + 矛盾检测）
• 自我进化的「基因突变」（Evolution Agent 提案替代）

🔑 洞察 32：确定性标记 + 概率性消解 Guard 的三态输出（pass/violation/uncertain）是一个重要的认知突破。以前总觉得规则检查要么合规要么违规。但现实是很多情况「不确定」——规则覆盖不到、上下文不完整、边界情况模糊。承认 uncertain 不是软弱，而是诚实。「覆盖率 72% 的报告」比「满分 100 的报告」更有价值——因为后者可能只是检查不够充分。

🔑 洞察 33：信号驱动 > 时间驱动 不是「每 24 小时扫描一次」，而是「信号饱和时触发」。衰减评分跌破阈值、矛盾检测发现冲突、使用量突然下降——这些信号才是触发动作的正确时机。时间驱动是懒方案，信号驱动是精准方案。

🔑 洞察 34：ConfidenceRouter——置信度不是分数，是行动路由 把「置信度」从一个展示用的数字，变成一个决策触发点：

• < 0.2 → 直接拒绝（垃圾进不来）
• 0.2~0.69 → 排队等人审（不确定时交给人）
• 0.7~0.84 → 自动 staging + 72h 观察期
• ≥ 0.85 → 自动 staging + 24h 快速通道

这让 AI 的「自信程度」直接映射到了「行动策略」，既保证了效率又保证了安全。

🔑 洞察 35：冷启动 ≠ 增量更新——一个是认识，一个是补充 长期混淆 bootstrap（我完全不了解这个项目）和 rescan（项目变化了，补充新知识），用 snapshot diff ratio 自动判断走哪条路。但这两个是完全不同的用户意图：

• bootstrap = 干净重来（低频率，全量分析）
• rescan = 知识补给（高频率，保留旧知识 + 增量检测）

分离后代码更简单，用户也不再困惑。

🔑 洞察 36：搜索的 550 倍加速——精确查询不需要 embedding 精确术语查询（如 WBISigner）走 BM25 只需 40ms，走 embedding 需要 22s（因为要调 API）。Confidence Gate 根据查询特征判断：精确术语直接返回 BM25 结果，自然语言句子才追加语义搜索。这不是优化，是架构层面的认知提升——不是所有查询都需要 AI。

🔑 洞察 37：Recipe 需要证据——不信任没有来源的知识 Agent 不信任 Recipe 的 coreCode，因为里面用的是 MyRepository 这样的泛化名称。增加 sourceRefs（指向项目真实文件的路径）后，Agent 可以验证「这个模式确实存在于代码库中」。没有证据的知识就是传闻，有证据的知识才是事实。

🔑 洞察 38：文件 = 真相源，DB = 物化索引 最后形成的数据哲学：.md 文件是持久化的真相源（人可编辑、Git 追踪、灾难恢复），SQLite 是快速查询的物化索引。冲突时文件胜出。这意味着即使数据库完全损坏，也能从文件重建。

🔑 洞察 39：Tool Forge——LLM 做锻造师而非管理者 三种模式：复用（ToolRegistry 命中，~0ms）→ 组合（原子工具拼装，~10ms）→ 生成（LLM 写代码 + 沙箱验证，~5s）。LLM 造好工具就退场，执行过程是确定性的。跟 Guard 的 uncertain 是同一哲学：确定性层做擅长的事，不确定时结构化上抛。类比：子 Agent 是「我有 10 个工人分活」，Tool Forge 是「告诉车间要什么产品，它造出工具线再生产」。

🔑 洞察 40：AI 预计算 > 运行时启发式猜测 AI 在提取知识时拥有完整源码上下文，这是语义理解的最佳时机。但之前只要求产出 9 个字段，52+ 字段中 18 个始终为空。到交付阶段只能从残缺数据中用正则猜——比如 _extractDo() 从中文 description 取第一句。“何时用 AI”比“是否用 AI”更关键：应该在创建知识时就产出 trigger、whenClause、coreCode 等交付字段，而不是交付时现猜。

🔑 洞察 41：Wiki ≠ Delivery——同一知识的双重人格 同一个项目需要两套完全不同的文档输出：一套给 AI 读（.mdc 压缩为 When/Do/Don’t，token 极简），一套给人类读（Markdown 完整文章 + Mermaid 架构图）。.cursor/ 通常 gitignore，而 AutoSnippet/wiki/ 可 Git 共享。数据来源几乎零重叠——Delivery 消费已提炼的知识，Wiki 消费原始代码结构。两者互补而非竞争。

🔑 洞察 42：信号收集器——让 AI 自己决定下次什么时候跑 SignalCollector 不用 setInterval，用 setTimeout。AI 在响应中指定 nextIntervalMinutes。信号密集时缩短到 15-30 分钟，信号平静时延长到 4-8 小时。六维信号（Guard 冲突 / 对话记忆 / Recipe 健康 / Candidate 堆积 / 操作日志 / 代码变更）并行收集，AI 综合判断是否值得推荐。这是 Agent 自治理念在调度层面的具体实现。

跨阶段的核心思考主线

主线一：从工具到有机体

工具（Snippet 管理） 
  → 知识库（Recipe 存储 + 搜索）
    → 智能体（Agent 自动分析 + 生成）
      → 有机体（自感知、自代谢、自免疫、自进化）

每个阶段都觉得「已经够了」，但下一个阶段总会出现新的需求推动进化。

主线二：在 AI 浪潮中找到自己的位置

不是替代 AI，不是被 AI 替代，而是成为 AI 的外挂记忆。AI 负责智能，AutoSnippet 负责权威性和可执行性。

主线三：质量 > 数量

宁缺毋滥的设计哲学：人审闭环、置信度路由、观察期、Guard 误报管控——每一个设计都在说同一件事：一条高质量的知识胜过十条低质量的。

主线四：实用主义技术选择

• JSON 优先，按需升级（向量数据库选型）
• WASM 取代原生绑定（tree-sitter 迁移）
• 删除 iOS 代码获得聚焦（AI-First 转型）
• Confidence Gate 跳过不必要的 embedding（搜索优化）

每次都是「先让它跑起来，再让它完美」。

主线五：AI 编译期思考 + 工程运行期执行

这是从 Claude、OpenClaw、AutoDream 三个项目中提炼出的同一件事：复杂性应该存在于它真正增加价值的地方。 规则创建用 AI，规则执行用正则/AST；工具锻造用 LLM，工具执行用确定性代码；知识提取用 AI 预计算，知识交付用结构化字段。让 AI 在它擅长的时刻做它擅长的事，其余时间它不应该在场。

主线六：确定性标记 + 概率性消解

Guard 的 uncertain 上抛给 Agent 判断，Runtime 缺工具上抛给 Forge 锻造，KnowledgeCompressor 缺字段上抛给 AI 预计算。每个系统都是同一公理的实例：确定的事情确定性地做，不确定的事情结构化地上抛给更高层消解。