https://blog.yungyu.tech/悲观者正确，乐观者成功，自律者自由。 2026-06-05T03:56:42+00:00 羊羽 https://blog.yungyu.tech/ Jekyll © 2026 羊羽 /assets/img/favicons/favicon.ico /assets/img/favicons/favicon-96x96.png 2026-06-04T00:00:00+00:00 2026-06-04T00:00:00+00:00 https://blog.yungyu.tech/posts/Claude-Code-%E6%9D%83%E9%99%90%E6%A8%A1%E5%BC%8F-%E5%9B%9B%E7%A7%8D%E6%A8%A1%E5%BC%8F%E6%80%8E%E4%B9%88%E9%80%89-bypass-%E6%80%8E%E4%B9%88%E8%A7%A3%E9%94%81/ 羊羽

一、四种权限模式：四个档位 Claude Code 有四种权限模式，按 Shift+Tab 循环切换： 档位 模式 行为 一句话 ① default 每次工具调用都弹窗确认 凡事都要问 ② acceptEdits 文件编辑自动放行，Bash、网络仍要确认 改代码不问，跑命令要问 ③ plan 只读操作放行，写操作需确认 看可以，动要问 🔓 bypassPermissions 全部跳过，直接执行 你办事，我放心 档...

2026-06-03T00:00:00+00:00 2026-06-03T00:00:00+00:00 https://blog.yungyu.tech/posts/RAG%E6%A0%B8%E5%BF%83%E6%A6%82%E5%BF%B5%E4%B8%8E%E5%8E%9F%E7%90%86-Chunking-Embedding-%E7%9B%B8%E4%BC%BC%E5%BA%A6-HNSW%E4%B8%8E%E5%A4%9A%E8%B7%AF%E5%8F%AC%E5%9B%9E/ 羊羽

一、为什么需要 RAG —— LLM 的先天局限 问 ChatGPT 一个公司内部系统的问题，它一本正经地编了个看起来很合理、但完全错误的答案——这事儿不少人都碰到过。 写代码时问「这个框架的 v2.3 版本 API 怎么用」，结果它给的是 v1.x 的写法，早已废弃。问「公司内部优惠券系统的退款流程是什么」，它直接开始编。 LLM 的问题很明确，就三条： 训练数据有截止日期：GPT-4 的知识停留在训练那一刻，不知道之后发生的事。 遇到知识盲区会”幻觉”：不会说”我不知道”，而是硬编一个看起来合理的回答。 不知道企业私有知识：内部文档、代码库、业务规则、团队约定——这些东西不可能出现在公开训练数据里。 RAG（Retrieval-Augmented Generation，检索增强生成） 就是来解决这些问题的。 思路很朴素——让 LLM 先查资料，再回答问...

2026-05-24T00:00:00+00:00 2026-05-24T00:00:00+00:00 https://blog.yungyu.tech/posts/Claude-Code-%E6%88%90%E6%9C%AC%E8%B0%83%E4%BC%98%E5%AE%9E%E8%B7%B5-%E6%8A%8A%E5%A5%BD%E6%A8%A1%E5%9E%8B%E7%94%A8%E5%9C%A8%E5%85%B3%E9%94%AE%E8%B7%AF%E5%BE%84%E4%B8%8A/ 羊羽

最近两个月Token总是不够用，感觉 Claude Code 在偷我 Token！动了换个其他开源 Coding Agent 的心思。 了解了一圈，看到了 omp（oh-my-pi，一个 AI 编程工具）的模型角色设计。 omp 把模型分为几个命名槽位，比如 default（主模型 / 日常对话）、smol（快而便宜的任务）、slow（深度推理）、plan（规划模式）。每个槽位可以独立绑定模型，agent 在特定时刻自动从对应槽位取模型——用户只需要把合适的模型固定到对应的角色上。 这是一个很好的思路。反观我的实际用法——主对话、Explore 搜代码、后台 hook、离开摘要(recap)，所有场景都跑在同一个重模型上，等于统统用大炮。 用大炮打蚊子，Token 用量肯定爆炸~ Claude Code 没有 omp 那种明面上的【角色系统】，但模型配置里留了不少入口，够我...

2026-05-16T00:00:00+00:00 2026-05-16T00:00:00+00:00 https://blog.yungyu.tech/posts/Claude-Code-Terminal-Tab-%E4%B8%80%E4%B8%AA%E5%BC%80%E6%BA%90%E5%B0%8F%E5%B7%A5%E5%85%B7/ 羊羽

背景 用 Claude Code 一段时间了，有个问题一直很烦：官方的 JetBrains 插件在多窗口下工具栏按钮时不时没反应，GitHub 上相关 issue 积压了好几个月没动静。 一开始觉得能忍——毕竟功能上没缺失，顶多是按一下没反应，再按一下就好了。但”再按一下”这件事，在每天几十次切换的节奏下真的很磨人，T_T。 翻了翻 issue，发现大家反馈的现象都差不多，版本卡在 0.1.14-beta 五个多月没动，Marketplace 评分 2.5 分，清一色在骂这个。等不了，索性自己写了个。 官方插件的问题在哪 Claude Code (Beta) 其实挺好用的，核心能力有两块：一是 IDE MCP Server（把当前文件、选中内容等上下文喂给 Claude Code CLI），二是在 IDE 内置终端里快捷打开 Claude 会话。第一块没什么问题，第二块经常...

2026-05-13T00:00:00+00:00 2026-05-13T00:00:00+00:00 https://blog.yungyu.tech/posts/Agent%E6%8A%80%E6%9C%AF%E5%86%85%E5%B9%95-%E4%B8%80%E4%B8%AA%E8%BF%90%E7%BB%B4%E6%8E%92%E9%9A%9CAgent%E7%9A%84%E8%AE%BE%E8%AE%A1%E4%B8%8E%E8%90%BD%E5%9C%B0/ 羊羽

微服务架构下排查线上问题是一件很折磨人的事。一个用户反馈”订单支付失败”，你可能需要： 先查日志平台，定位到具体报错的服务和时间点 再查链路追踪，看这次请求经过了哪些服务、每个环节的耗时 翻 CMDB 找对应服务的实例信息和配置 登录 K8s 看 Pod 的运行状态和最近事件 结合监控指标判断是不是系统资源问题 每一步都要切不同的平台、记不同的查询语法、手动拼凑信息碎片。 排查过程本身并不需要多高深的技术判断，但【上下文切换成本】极高——等你把上述步骤走完，可能十几二十分钟就过去了。 我们要解决的正是这个问题：让 AI 替你完成这些机械的信息收集和初步分析工作，你只需要描述现象，剩下的事情交给系统去跑。 这篇文章会先用一个典型场景讲清楚这类系统怎么用，再深入剖析后端几个值得聊聊的设计决策。尤其是 ReAct 调度模型、事件驱动架构、工具错误恢复这几个...