一次 AI 使用的深度思考

一次 AI 使用的深度思考一个跨语言、覆盖我主要开发场景、并且能自进化的 AI 集成工具我是怎么搭的。全文按五层组织入口层 → 路由层 → 填充层 → 执行层 → 沉淀层。目标我希望构建一个跨语言、涵盖自己主要工作开发场景、并且能自进化的 AI 集成工具。三个限定词都不是修饰每一个都决定了后面的架构选择限定意味着什么跨语言不能绑定在某个语言或某个项目上。判断标准、准入纪律、知识通道必须与领域解耦覆盖主要开发场景架构设计、功能实现、Bug 修复、重构——每个场景的输入输出要求都不一样所以它们是不同的入口自进化每次交付都要产出一条可复用增量让下次的起点比这次高架构图五层各管什么层一句话职责关键问题入口层承接我的输入并把它变成有约束的请求用什么宿主记忆放哪谁来判断路由层判断这是什么场景和该用哪种调度方式走普通任务还是长任务填充层给 AI 补齐解决问题所需的上下文补什么从哪补怎么补才准执行层AI 真正开始解决问题怎么拆错了怎么办怎么验证沉淀层把这次的经验留下来供下次复用不手工维护怎么自动长出来入口层harnessharness LLM Tools。这一类东西现在非常多了。我主流用两个Hermes与DeepSeek HarnessDSH。欣赏Hermes的自进化 agent更折服于DSH 的生态与插件。选两个而不是一个是因为它们解决的不是同一个问题一个是agent 怎么变强一个是能力怎么插进来。agent memory记忆层用来解决通用约束跨 harness、跨会话丢失的问题。我用的是OpenViking。几个特点三层结构按需加载上下文——更精准也更省 token自动记忆提取与召回——不需要我每次手动喂⚠️高并发有风险本地自己玩玩可以不要上生产。第三条是踩过的不是理论担心。gateway入口层里真正做判断的那一层主要承担意图识别包括开发场景区分、开发模式区分等。用 Jev 实现。这一层的设计原则只有一条它必须薄。它只负责回答这件事归哪一路不做分析、不出方案、不内联任何领域规程。判断错了怎么办这是我被问得最多的一个问题。答案分三层从根到梢层级做法说明1. 服务侧根源修复去看 Jev 的判断条件改判据但记住——这层应该薄不要把所有规则都堆进来2. 客户端根源修复调整 prompt让输入更明确很多判错其实是问题本身没问清3. 机制兜底Loop 工程 AI 本身可以反复提问我其实不 care 一次两次失败第三层是我认为最关键的一层整个体系不依赖任何单次判断的准确性它依赖的是错了能发现、发现了能补。但有一类错必须单独说阈值门拦不住它有把握但理解偏了。实测出现过置信度 1.000 却判错的案例——这类错的唯一防线是影子模式 定期回归不是调阈值。关于集成与闭环我现在的实际玩法是这样的底座是 DeepSeek Harness装了很多插件其中一个是 OpenViking。在 OpenViking 里明确写了一条约束性记忆当我在和 AI 交互时优先使用一个意图识别 skill。因为记忆是每轮自动注入的这条约束不需要我每次说。这个 skill内部有一堆规则然后去调用 Jev。再次强调这层很薄。通过 Jev 的判断我可以直接定位很多信息——比如AI 调度场景、AI 调度方式。如果 Jev 判断你就是在瞎聊场景关联置信度很低那就随意了AI 不会进这个门。这里补一条边界网关管的是不确定流量不是收费站。开发类场景架构设计 / 功能实现 / Bug 修复 / 重构一律先过这层但已经点名了项目或模块的非开发类任务直接连对应的领域技能就行不必多绕一跳——多一跳就是白花 token。路由层AI 调度场景我盘了盘我能用到 AI 协助的开发场景有四个架构设计、功能实现、Bug 修复、重构。事实上每个开发场景都是我自己的一个 skill——因为它们要求的输入和输出都不一样场景要什么输入出什么架构设计现状 约束 目标方案与取舍理由功能实现契约 边界 惯例可编译、可验证的实现Bug 修复现象 复现 根因证据根因修复不是数据补丁重构不许变的契约 回归面等价改造 回归证据AI 调度方式我本地的调度方式分两种普通任务和长任务。换句话说一个是原生 AI Agent一个是Workflow Agent。前者代表智能推理后者代表一个长任务的约束。关于长任务我自己封了一个长任务的 skill。当 Jev 判断我的任务归属于复杂性问题时就走这个逻辑。长任务我借鉴了三个成熟的架构来源借鉴了什么Ouroboros模糊度门槛判断——不够清晰就不开工Spec Kit不断追问、把上下文填充完整DSH 原生能力设置 goal、todo、workflow、subagent、ralph不要把 vibe coding 变成 wish coding总有一些人看到我这套长任务就很激动满脑子想的是全自动化。虽然我用了很多技术让输入更明确、让成果阶段性交付但实际上——AI 总会在某一个节点上出现不 OK 的方式。而你的链路越长就越尴尬任何一个 chain 打了 0.8 折后面的最终交付结果就开始偏差。于是这类长任务的适用场景到底是什么OPC——大量需要做原型验证的时候。我不需要为结果质量保证但我需要在最短时间内交付一个意向版本用来讨论技术可行性、业务覆盖度——那时候是真好用。我实测用过好几个一个双轨语音识别带热词的2 小时写完一套复杂数据中台半天写完一个帮助中心系统半天写完。但再次强调这是用来做快速原型验证的不是用来交付的。老板幻觉大致就在于此——早期看到一个完整度很高的原型就问“这些功能不是都写了吗为啥你还要三个月”填充层我认为所有 AI 在使用的时候都要获取两部分数据源动态层与静态层。动态层这个很简单——harness 自带的那么多工具能帮你抓网页信息、抓接口信息、看需求文档、直接看你的数据库、甚至可以直接操作你的服务器、看你的 Jira 任务系统、抓你的项目代码、抓你的相似实现、抓你的产品源码……等等。当你在描述一个问题的时候AI 会自动把周边它认为需要捕获的动态内容抓取过来。当然了这个抓取过程本质上是一个Loop 工程是分多个步骤的操作。Claude Code 源码泄露之后我看了源码现在就记得两件事一个是Loop 工程一个是为什么它不用 RAG。静态层这个就比较麻烦了。所谓的静态层在我的理解里就是我每次的知识沉淀一些良性开发守则、一些项目上之前遇到的坑、一些团队内部开发使用的默认契约。这块我主要用的是RAG。那么为什么一定要 RAG按整洁架构的思路我用bash grep也很快——那 RAG 到底能给我带来什么收益我是这么理解的RAG 不一定更快但它一定更准。索引召回、Rerank 精排、Wiki 知识图谱——这些能力远远大于普通的 grep。知识是集中管理的。我可以管理对应的版本冲突可以打 Tag、用 Metadata 描述我的知识还可以开定时任务清理过期知识、压缩知识点。不要把 RAG 弱化理解为单独的知识库。在我的视角里RAG 知识库动态维护 Agent自带 system prompt Toolsweb search、MCP 注入 复杂检索方式关键字检索、混合检索、索引召回、Rerank、Wiki 图谱成本可控。我电脑是 MacBook Pro性能不错本地装了向量模型和 Rerank 模型压根不要钱。⚠️ 注意如果你是 Mac不要把这些模型塞进 Docker——它的底层走的是 Linux 的协议我让 AI 验证过慢了 14 倍。谈谈 RAG 里存了啥我在 RAG 里主要存了两样东西知识库和智能体。知识库按业务分类知识库形态解决什么问题良性开发规约FAQ 模式增加了相似问怎么做才算对良性代码案例库我自己觉得很棒的代码设计让 AI 参照良性设计——你没这个AI 一读项目代码看到的全是别人写的代码。我看了看他们的设计我都不满意。本质上是为了避免代码污染产品教材卡怎么使用内部产品的教程解决使用侧、场景化的问题踩坑卡踩坑与反模式修 Bug 的时候 AI 会主动问我要不要沉淀进去避免下次踩坑产品二开使用的规则经过一套规则、被反复信任过的产品使用规则在一个混沌系统内的系统化开发处理上有一点差别FAQ 之外其他所有知识我都是 Wiki——这样检索更准。反正检索模型都在我本地又不花钱又快。智能体刚刚其实也讲了——知识库只是知识工程处理而智能体就是一个 system prompt toolsweb search、MCP 注入 复杂检索方式关键字检索、混合检索、索引召回、Rerank。事实权威 × 理想权威为什么不是直接搜 RAG你可能以为我是拿问题直接去搜 RAG。不不是。我是先拿了动态层里的一堆关键东西然后再去匹配 RAG——这里面是有本质区别的。原本我也是直接查询 RAG 的但我发现复杂问题处理效果不好。后来有一天忽然灵机一动我想明白了动态数据是「事实权威」它表示的是我的真实状态RAG 是「理想权威」它里面全都是我反复维护的各种标准化的东西。所以我做的是拿到事实权威里的东西再到 RAG 里去匹配关键点。这也恰好解决了上下文污染的问题。你要知道在复杂多人协同的开发场景里只要有一个人开发得很乱很烂AI 照旧读也会依葫芦画瓢写得一塌糊涂。为啥我要这么干本质上就一句话尽可能给到 LLM 更准 更少的信息相对的——关键业务信息肯定要给让它拿到足够解决问题的上下文优雅地解决这些问题。执行层上面说了这么多一个有效输出都还没有。这一层就是 AI 正儿八经去解决问题了。先说清楚不走这条路的情况。在 Jev 判断为非主流问题的时候——比如你问 AI今天天气怎么样——它是不会走这条路的。实际上在我的理解里执行就是以下三步。子 agent 分发主任务下来之后你可以让 AI 精准地拆分子任务去实现。但请不要把它理解为这就是一个 feature 开发——后面的回归验证也可以是一个子 agent。顺便提一嘴一个坑我一般不会在同一个代码模块内跑相似任务比如存在部分相同的包然后开好多个 session 不停地干——因为AI 会发现自己刚刚写的内容都被覆盖了。所以有的时候任务该串行还是串行有的时候子任务该并行就并行。Loop 工程这是一个机制。永远不要觉得 AI 不会犯错——它可能经常犯错。你用再贵的模型也只是解决犯错的次数。而 Loop 可以在犯错之后检查、发现有问题、再去操作。这也是为什么有的时候你要调用很多次 Tools——因为每一步步骤内的消息都可能不全然后你一步步地抓取、纠正。回归验证我感觉 AI 火了之后TDD 真的好好用。之前我都不写 Test 测试类的因为麻烦但AI 写这些好快的而且这也接上了刚刚说的 Loop——AI 能够快速地、低成本地校验自己。我的感觉是写 TDD 就像刷力扣算法题平台验证你的算法对不对而我就是穷举大量的入参和预期出参判断你算法的合理性。顺带一提完整的出口闸门其实有三道TDD 管该做的做了没编译管低级错误有没有整洁架构管有没有多做。前两道量的是做够了没第三道量的是做多了没——方向相反缺一不可。沉淀层以上所有东西都是教你怎么用好。但是要沉淀啊——不能说我今天改了一个 Bug明天遇到相似的 Bug还要再花 15 分钟处理一遍。那么怎么弄呢我的做法是四条OpenViking 的记忆——每次交互的即时结论自动落定时任务——抽取产品的一些规约自动化复盘验证抽取到 RAG 内定期人为抽取——把我的良性代码示例挑出来入库每次修 Bug——如果我觉得有价值我会让它沉淀到我的案例库。这四条的共同点是都不是我手工去维护知识库。我审我不抄。手工维护这件事在量、及时性和时点上都走不通——最该沉淀的那一刻恰好是人最想收工的时候。一些最后的技巧我上次 review 过一些代码写得啰嗦又分不清边界。讲一些额外的技巧吧不要让 AI 写好多 Fallback——它不知道业务场景但是我们知道啊。有些场景直接抛异常怎么了不碍事的。不要为了历史数据写好多兼容——正常情况下除非急着上线数据态应该是一致的。处理好历史数据而不是让代码替数据背锅。不要让 AI 参照不可信的代码——这就是我的 RAG 搞那么多知识库的原因。它一读项目既有代码直接降智为当时的开发水平还一直在想这个地方有个 Fallback是不是有这种旁路分支优先定义契约与对象——前者表示对象行为后者表示对象属性。想清楚这两个大体逻辑就不会有大的偏差。必要时做类似思维链的操作——在你的主方法内手写一个个步骤比如数据获取 → 数据校验 → 数据处理 → 数据分流 → 数据后置填充。当然你要是足够自信也可以直接说使用什么架构方式、什么设计模式。