Claude Code斜杠命令进阶：从自动化提交到智能分支管理
前言在使用 Claude Code 的过程中，我发现了一个非常实用的斜杠命令：/git-commit。这个命令实现了从简单的自动化提交到智能分支管理的完整演进过程。本文将记录这个命令从最初版本到现在的完整演变历程。 版本1.0：基础自动化提交需求背景最初的需求很简单：每次写完代码后，都要手动执行一系列 git 操作： git add . git status 查看变更 git diff --cached 查看具体修改内容 手动思考写什么 commit message git commit -m "xxx" 这个过程虽然简单，但重复执行非常繁琐。 实现方案创建了第一个版本的 /.claude/commands/git-commit.md： ---description: "【全自动】一键执行 git add . 并自动生成信息提交"argument-hint: "[可选：指定提交意图或关键词]"allowed-tools: Bash(git add:*), Bash(git diff:*), Bash(git sta...
我画了十几张图，终于把GPT识字这件事，从头到尾讲透了
很多文章在讲 tokenizer 的时候，往往从「词」「子词」直接开始，但如果你真的想理解 GPT 这类模型是怎么”看懂文字”的，我们可能要从头了解。需要强调的是，本文将要拆解的底层原理，不仅是GPT的魔法，同样也是驱动千问、豆包、DeepSeek、Kimi等所有顶尖大模型的共通基石。 这篇文章，我想完整记录： 文本是如何一步一步，从”电信号”，变成模型输入的一串整数 ID，又如何在模型输出后，被还原成人类能读懂的文字。 为什么不能只用字节？——从0-256开始的BPE之路在任何语言模型、任何 tokenizer 出现之前，有一个不可绕过的事实： 计算机并不认识”字符”，只认识电压的高低。 这些电压状态，在逻辑上被抽象为 0 和 1（bit）。 但需要强调的是： 语言模型并不会直接处理 bit 级别的数据。 因为 bit 太底层、太长，而且不同编码方式会导致完全不同的 bit 序列。 真正进入 tokenizer 之前，所有文本都会先经过UTF-8 编码： 例如，我爱中国 china在 UTF-8 编码下，在计算机中存储运算的时候，其实是以一串字节序列进行的（字节...
最高效的学习其实是“不学习”？Gemini 3.0 揭示了AI时代的“拿来主义”
最近大家看Gemini3.0可能了解了很多它在前端代码生成方面的能力。但忽略了它的最强的一个应用场景：就是把它当做任何一个软件的高级专家去使用。这个用法能将我们学习新工具（如影刀、Dify、Hexo）的时间从几天压缩到几分钟，跳过枯燥的学习过程，直接拿结果。当然，如果这个软件满足以下条件任意之一会更好（因为Gemini 3.0强大的上下文窗口能力)： 在网上有很多教程 官方文档写的非常好 软件开源 下面我们以影刀RPA为例，简单的给大家演示一下过程。 操作过程先将我们的需求简单描述一下，让Gemini 3.0帮我们优化下提示词。因为我本身对影刀有一些简单的了解，知道它很多工具都是基于python处理的，也知道他对python有非常好的支持，所以我下面的初版提示词提到了python脚本。但是如果大家没用过，其实它也会给一个完全是影刀RPA的指令的完成方式，但是会相对会需要你多沟通几次。你可以这样问，还有没有其他操作起来更加简单地方案呢？ 我现在有一个业务需求，业务人员每天都会受到一封固定邮件，附件内容也是固定的是一个excel，业务人员收到以后，需要将附件下载，然后解压缩...
Dify知识库图文混排到底应该怎么做，两种主流方案，一次讲清！
如果你想在使用dify知识库的实现下面的图文混排效果，那你非常有必要读一下这篇文章。 我发现，目前实现这样的图文混排效果应该是有两种方案： 使用图床或者直接将word文件导入知识库。 大家用知识库多的话，或者大模型多的话，可能都知道大模型其实非常擅长理解markdown文件，图床就是markdown中的图像在网络上存储的位置。 而word导入知识库以后，word中的图片会被dify的知识库解析，然后存储到dify所在的服务器。 上面的这两种方案，其实本质上的原理，都是使用的dify的前端是支持markdown渲染的。因此，markdown的图片渲染也是支持的。 下面实验的dify版本是1.9.2，win11环境，docker启动。 markdown图床使用markdown图床的方式，实现知识库答案的图文混排。 前几天，我们怕了E大很多的文章，这里我们就以E大的文章为例。 如果大家看了之前的文章的话： 从被 Trae 气到崩溃，到用 Gemini 一次跑通，终于爬下了孟岩和E大的全部理财干货 可能看到了我爬取得markdown文档图片是在本地电脑上存储的，在markdown中的...
从被 Trae 气到崩溃，到用 Gemini 一次跑通，终于爬下了孟岩和E大的全部理财干货
一直以来我都非常的喜欢孟岩和E大，所以特想把他们在网上的发言都收集起来，以便于自己学习。还想着后续也做一个知识库，随时随地学习他们的理财理念。 但是我之前一直目标瞄在了他们的微博上，但是我这个技术水平，爬取微博，每次最多1000多条微博，就GG了。 后来，突然想，其实孟岩最新的有知有行上面的理财教程和E大合集本身就是精华啊，我为什么不收集一下。 所以我就打开了有知有行的官网: https://youzhiyouxing.cn/materials 在这里，必须感慨下，孟岩实在是太好了，他其实允许所有人读，免登录，直接阅读，后来在写爬虫的过程中，还发现他实际上是一个静态网站。 孟岩太酷了。 爬虫已经开源了： https://github.com/Wangshixiong/youzhiyouxing 欢迎大家使用，但是请大家一定一定注意频率，避免对服务器造成压力，在此感谢孟岩老师。 现在主要是记录下爬虫的开发过程。 最终的成果展示： 起源其实我从网上找到了别人整理的有知有行中E大的发言，但是他是一个pdf文件，而且非常的没有条理，没有目录，没有标题，因为我后续是计划做知识...
在Dify工作流里，我为什么“剥夺”了大模型调用工具的能力？
在生产环境用 Dify，我们最头疼的就是大模型的不确定性。 让 Agent 节点自己调用工具，结果总会有点飘。 今天分享一个能让工作流更稳定、更可控的小技巧： 就是我们可以将MCP中的工具作为工具节点直接插入dify的工作流中。 不知道大家有没有注意到我上一篇文章的一个使用方式： 这里我直接将腾讯的Edgeone-Pages当做一个工具节点了。大家可以看到它是一个工具，这个实际上是我从dify的插件市场下载的一个工具插件，最主要是这玩意儿必须要申请APIkey.而且它输出的text不是url，还需要我从json中提取，所以我加了一个模板转换节点。 虽然他的apikey申请起来并不是特别费劲。 但是大家如果之前在其他地方用过腾讯这个网页部署的mcp服务的话，应该是知道，他是不需要key的。 所以，比如我们可以直接登录modelscope（魔塔社区），开通一下这个服务。 魔塔社区EdgeOne Pages · MCP 然后配置到你的dify里面： 接下来，我们就可以直接再工作流里面把MCP中的工具，直接当做工具引用了。 大家看下效果： 当然，这只是非常简短的一个案例。 ...
Dify官方没给的“触发器”，我用一个Webhook异步技巧“曲线救国”了
不知道大家怎么落地大模型的。我现在完全都是从小事出发，因为搞业务，业务难搞。所以先把自己解放出来。 就比如，我比较烦一件事情，每次流程要求，需求评审之前必须发需求评审邮件，我挺烦这件事情，虽然那内容不复杂，但是每次都要自己写，从需求管理平台里面复制名字，链接，还要写评审时间，按照格式填充邮件模板，然后找抄送人发送人。 我就寻思让大模型给我干了。但是大模型又不知道我是什么需求，每次我给他打出来，那还不是很复杂吗。没必要啊。 所以就有了今天这个事儿。 我就用Dify搞了一下。 当然，自己解放出来就有更多时间思考业务，就比如这次这个事儿，完全可以复用用在很多其他场景，比如我要到时间了自动给客户发送一个个性的生日祝福，每次开发个http请求，调用官方api多麻烦啊。 dify又没有触发器，那还能咋整，我们自己想办法呗。 还有个点就是，我是真服了。网上那么多教程啊，文档啊，那都是给懂技术的老师写的，像我们这种，那是真难啊，要是没了AI，我想搞成这个事儿那是不可能的。 不多说废话了，我们开始哈。 这个文章有点长，我想记录下这个插件的使用方式，配置项是怎么用的，一个方式方便自己记录，另一个是...
醒醒！AI编程工具压根不是给程序员的，而是给每一个想“偷懒”的你
前面给大家介绍过很多AI编程工具，Claude code、codebuddy、Trae等等。 大家可能会想，AI编程工具？我又不是程序员，这东西跟我有啥关系？。 我想说不是的，大家每个人都用得上。 AI编程工具早已不是程序员的专属，它更应该被看作是我们每个人的“效率放大器”。 AI编程工具应该成为我们每个人电脑上必备的软件。无论是IDE、命令行工具还是什么，我们都不应该把它当成什么编程工具，应该当做一个效率工具。我们不需要会编程，会写代码，我们只需要清晰地表达清楚我们的需求是什么，让AI给我们解决就好。 接下来，我会用4个案例，跟大家说，我在日常工作是怎么用AI编程工具的： 一句话，将PDF批量转换为高清图片。 一句话，将上百张照片按“时间地点”智能重命名。 一个指令，实现文章图片自动上传云端并替换链接。 一次提问，让AI带你读懂软件的底层代码逻辑。 格式转换，比如pdf转成图片。 比如，我们现在下载到的发票大部分都是pdf格式，但是我们在保险理赔或者其他场景的时候，需要上传图片格式。这个时候，我们把pdf打开，一个个截图那可真是麻烦死了。 当然，网上有各种工具，那我们要不就得...
GLM-4.6 + Claude Code实战：从入门配置，到一个差点翻车的项目
最近苦于在dify上去做一些MVP验证时，相对来说非常麻烦的问题，比如数据分析报告的生成。 因为在我的理解看来，对于数据表这种结构化数据，现阶段大模型其实并不擅长处理，他擅长处理的反而是非结构化的数据。所以现阶段来说，生成数据分析报告，肯定是需要提前加工好数据的，就是对原始数据做好数据透视，这样才能在一定程度上确保分析报告生成的准确性。 但是类似这汇总分析场景，使用dify的做MVP验证的话，就相对来说比较麻烦一些。因为这涉及到提前设计一些数据分析的脚本，来进行数据透视。相对来说，类似Claude code这种本地的AI Agent或者Trae这种AI IDE，做这件事情就非常擅长了。 不同的工具，有自己擅长的事情，而我们，要找到对自己最有利的工具，并且要用好它。 今天想给大家介绍下我最近经常用的claude code。当然今天主要就是简单地介绍下他的使用方式，深入使用，还是得在具体的业务场景。 1. Claude Code安装及配置Claude Code 安装这里我默认大家都已经安装了nodejs，如果没有安装的话，请大家去下面的网址下载安装下。 Node.js — Run ...
你的 RAG 还在“垃圾进，垃圾出”？我用这套流程，把“废料”文档变成了黄金知识库
最近大家关注Dify的进展的话，应该知道它的版本更新直接从1.8.0—>2.0.1了。跨越了一个大的版本。它本次的主要更新就在于知识库构建的知识流水线。 我认为Dify2.0以后的知识流水线会极大地降低了构建知识库的门槛，未来也许能高效处理 80% 的相对标准的文档。 但是，仍然会有20%，还是要依赖于我们人来手动处理。 我们都知道，现阶段来说，对于知识库，仍然是一个垃圾进垃圾出的状态，因此，在构建知识库之前我们需要对知识文档做很多的预处理。 今天这篇文章的分享，其实也是想给大家分享下我们自己手工处理文档的数据清洗思路。 1. RAG知识库的瓶颈知识库的质量不取决于模型，而取决于“垃圾进，垃圾出”的铁律。真正的瓶颈是ETL（抽取、转换、加载）过程，尤其是从非结构化源文档到结构化知识块（Chunks）的转换过程。 我们每个公司其实私有的数据量，私有的文档是非常庞大的，而它的内容又是千奇百怪的。针对一个合同，就可能有几十几百种格式，所以指望一套流程来完成这个非结构化源文档到RAG知识库的转变基本是不可能的。 我们如果想偷懒直接将某个文档上传到RAG知识库，就希望他回答的10...
