背景相信现在 AI Coding 已经占据工作中大部分代码了，甚至很多人就直接交给 AI 来写，自己只做 review。 再有甚者 review 都不做了，直接全面交给 AI，自己只做产品经理提需求、验证功能逻辑是否正确——也就是现在很流行的 Vibe Coding。 前段时间我自己用 Vibe Coding 写了一个 macOS 原生的 APP，以此来判断 Vibe Coding 是否能让我在一

背景最近我一直在折腾项目文档生成的事情。之前写过两篇关于 deepwiki 的文章：deepwiki-rag-principle 讲了 RAG 原理，deepwiki-optimize-line-number 聊了给代码加行号的优化。 经过几轮迭代，搞了两个优化： 代码加上行号前缀 基于 Proto 文件生成确定性目录 这两个优化背后其实是同一个思路：把确定的东西明确告诉 AI，不确定的才让

背景最近我们在做一件非常危险的大事——把用了好几年的腾讯云企业版 Istio 服务网格迁移到社区开源版。 事情的起因是腾讯云突然宣布不再维护 Istio 服务网格了，后续也不会推出新版本。这就导致我们的网格一直停留在旧版本，进而连带着 k8s 这些基础组件也很难升级。可以说是血的教训：用托管服务一时爽，一旦厂商放弃维护，迁移成本还是得自己扛。

背景 上周末参加了一个我们重庆本地的一个 AI 分享会，分享了一些企业大模型与 Vibe Coding 的实战经验，现在把它整理成一篇 blog。

背景最近在用 deepwiki-open 给内部的 Java 项目生成 wiki，发现一个很明显的问题：生成的 wiki 页面里引用的代码行号经常不准确，看起来是 LLM 根据上下文自己推算的。 比如一个函数明明在第 503 行，生成出来的 wiki 里可能标注成第 510 行甚至更离谱的数字。 之前我在 DeepWiki 一个常用 RAG 应用的开发流程 里分析过它的整体流程，本文主要聊聊我们在

背景最近 OpenClaw 突然爆火，我的 SkillDeck 也乘热打铁支持了 OpenClaw 的 Skills 管理和 ClawHub 市场浏览安装功能。 这篇文章一方面介绍下 SkillDeck 的更新内容，另一方面也聊聊我对 OpenClaw 这波热度的一些看法。 安装命令： 1brew tap crossoverJie/skilldeck && brew install

背景最近在同时用多个 AI coding agent的过程中，Skills 管理起来比较麻烦， 我日常在 Claude Code、Codex、Copilot CLI 之间切换，每个 Agent 的 Skills 存放在不同的目录下（~/.claude/skills/、~/.agents/skills/、~/.gemini/skills/、~/.copilot/skills/），安装一个 Skill

背景最近用 Claude Code、Copilot CLI 这类 AI Agent 工具的时候，有一个挺烦人的问题：让 AI 在后台跑任务，我总是会忍不住去查看他的执行状态，有时候比较复杂的任务可能会耗时十来分钟，每次来回切换非常浪费时间。 更惨的是有时候 AI 需要我授权某个操作（比如执行 shell 命令），我没注意到，它就一直卡在那里等。 所以我一直想找一个靠谱的通知方案。 灵感来源于播客「

背景最近上一篇文章里答应过要分享下我那三个 SKILLS 的创建过程，乘热打铁赶紧写出来。 上篇提到过我写博客的一个痛点：每次写完文章都要手动找封面图 → 上传图床 → 粘贴链接，这套流程走下来虽然不复杂，但每次都要做一遍确实烦。 所以我就想着把这个流程自动化掉，而且全程一行代码没写，完全和 AI 对话搞定。

背景最近 Claude 的 SKILLS 很火，忍不住也来体验了一下，发现确实是有些东西的；但也发现身边的一些同事对这些新出的概念总是很懵逼，所以便有了这篇文章。 从最早的 Function Call，到 MCP 协议，再到如今的 Agent Skills。 本文将从技术演进的角度，带你理解这些概念之间的关系，以及它们如何让 AI 从一个”只会说话的聊天机器人”变成真正能”动手做事”的智能助手。