吏部侍郎

最近大家看Gemini3.0可能了解了很多它在前端代码生成方面的能力。但忽略了它的最强的一个应用场景：就是把它当做任何一个软件的高级专家去使用。这个用法能将我们学习新工具（如影刀、Dify、Hexo）的时间从几天压缩到几分钟，跳过枯燥的学习过程，直接拿结果。当然，如果这个软件满足以下条件任意之一会更好（因为Gemini 3.0强大的上下文窗口能力)： 在网上有很多教程 官方文档写的非常好 软件开源 下面我们以影刀RPA为例，简单的给大家演示一下过程。 操作过程先将我们的需求简单描述一下，让Gemini 3.0帮我们优化下提示词。因为我本身对影刀有一些简单的了解，知道它很多工具都是基于python处理的，也知道他对python有非常好的支持，所以我下面的初版提示词提到了python脚本。但是如果大家没用过，其实它也会给一个完全是影刀RPA的指令的完成方式，但是会相对会需要你多沟通几次。你可以这样问，还有没有其他操作起来更加简单地方案呢？ 我现在有一个业务需求，业务人员每天都会受到一封固定邮件，附件内容也是固定的是一个excel，业务人员收到以后，需要将附件下载，然后解压缩...

如果你想在使用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中的...

一直以来我都非常的喜欢孟岩和E大，所以特想把他们在网上的发言都收集起来，以便于自己学习。还想着后续也做一个知识库，随时随地学习他们的理财理念。 但是我之前一直目标瞄在了他们的微博上，但是我这个技术水平，爬取微博，每次最多1000多条微博，就GG了。 后来，突然想，其实孟岩最新的有知有行上面的理财教程和E大合集本身就是精华啊，我为什么不收集一下。 所以我就打开了有知有行的官网: https://youzhiyouxing.cn/materials 在这里，必须感慨下，孟岩实在是太好了，他其实允许所有人读，免登录，直接阅读，后来在写爬虫的过程中，还发现他实际上是一个静态网站。 孟岩太酷了。 爬虫已经开源了： https://github.com/Wangshixiong/youzhiyouxing 欢迎大家使用，但是请大家一定一定注意频率，避免对服务器造成压力，在此感谢孟岩老师。 现在主要是记录下爬虫的开发过程。 最终的成果展示： 起源其实我从网上找到了别人整理的有知有行中E大的发言，但是他是一个pdf文件，而且非常的没有条理，没有目录，没有标题，因为我后续是计划做知识...

在生产环境用 Dify，我们最头疼的就是大模型的不确定性。 让 Agent 节点自己调用工具，结果总会有点飘。 今天分享一个能让工作流更稳定、更可控的小技巧： 就是我们可以将MCP中的工具作为工具节点直接插入dify的工作流中。 不知道大家有没有注意到我上一篇文章的一个使用方式： 这里我直接将腾讯的Edgeone-Pages当做一个工具节点了。大家可以看到它是一个工具，这个实际上是我从dify的插件市场下载的一个工具插件，最主要是这玩意儿必须要申请APIkey.而且它输出的text不是url，还需要我从json中提取，所以我加了一个模板转换节点。 虽然他的apikey申请起来并不是特别费劲。 但是大家如果之前在其他地方用过腾讯这个网页部署的mcp服务的话，应该是知道，他是不需要key的。 所以，比如我们可以直接登录modelscope（魔塔社区），开通一下这个服务。 魔塔社区EdgeOne Pages · MCP 然后配置到你的dify里面： 接下来，我们就可以直接再工作流里面把MCP中的工具，直接当做工具引用了。 大家看下效果： 当然，这只是非常简短的一个案例。 ...

不知道大家怎么落地大模型的。我现在完全都是从小事出发，因为搞业务，业务难搞。所以先把自己解放出来。 就比如，我比较烦一件事情，每次流程要求，需求评审之前必须发需求评审邮件，我挺烦这件事情，虽然那内容不复杂，但是每次都要自己写，从需求管理平台里面复制名字，链接，还要写评审时间，按照格式填充邮件模板，然后找抄送人发送人。 我就寻思让大模型给我干了。但是大模型又不知道我是什么需求，每次我给他打出来，那还不是很复杂吗。没必要啊。 所以就有了今天这个事儿。 我就用Dify搞了一下。 当然，自己解放出来就有更多时间思考业务，就比如这次这个事儿，完全可以复用用在很多其他场景，比如我要到时间了自动给客户发送一个个性的生日祝福，每次开发个http请求，调用官方api多麻烦啊。 dify又没有触发器，那还能咋整，我们自己想办法呗。 还有个点就是，我是真服了。网上那么多教程啊，文档啊，那都是给懂技术的老师写的，像我们这种，那是真难啊，要是没了AI，我想搞成这个事儿那是不可能的。 不多说废话了，我们开始哈。 这个文章有点长，我想记录下这个插件的使用方式，配置项是怎么用的，一个方式方便自己记录，另一个是...

前面给大家介绍过很多AI编程工具，Claude code、codebuddy、Trae等等。 大家可能会想，AI编程工具？我又不是程序员，这东西跟我有啥关系？。 我想说不是的，大家每个人都用得上。 AI编程工具早已不是程序员的专属，它更应该被看作是我们每个人的“效率放大器”。 AI编程工具应该成为我们每个人电脑上必备的软件。无论是IDE、命令行工具还是什么，我们都不应该把它当成什么编程工具，应该当做一个效率工具。我们不需要会编程，会写代码，我们只需要清晰地表达清楚我们的需求是什么，让AI给我们解决就好。 接下来，我会用4个案例，跟大家说，我在日常工作是怎么用AI编程工具的： 一句话，将PDF批量转换为高清图片。 一句话，将上百张照片按“时间地点”智能重命名。 一个指令，实现文章图片自动上传云端并替换链接。 一次提问，让AI带你读懂软件的底层代码逻辑。 格式转换，比如pdf转成图片。 比如，我们现在下载到的发票大部分都是pdf格式，但是我们在保险理赔或者其他场景的时候，需要上传图片格式。这个时候，我们把pdf打开，一个个截图那可真是麻烦死了。 当然，网上有各种工具，那我们要不就得...

最近苦于在dify上去做一些MVP验证时，相对来说非常麻烦的问题，比如数据分析报告的生成。 因为在我的理解看来，对于数据表这种结构化数据，现阶段大模型其实并不擅长处理，他擅长处理的反而是非结构化的数据。所以现阶段来说，生成数据分析报告，肯定是需要提前加工好数据的，就是对原始数据做好数据透视，这样才能在一定程度上确保分析报告生成的准确性。 但是类似这汇总分析场景，使用dify的做MVP验证的话，就相对来说比较麻烦一些。因为这涉及到提前设计一些数据分析的脚本，来进行数据透视。相对来说，类似Claude code这种本地的AI Agent或者Trae这种AI IDE，做这件事情就非常擅长了。 不同的工具，有自己擅长的事情，而我们，要找到对自己最有利的工具，并且要用好它。 今天想给大家介绍下我最近经常用的claude code。当然今天主要就是简单地介绍下他的使用方式，深入使用，还是得在具体的业务场景。 1. Claude Code安装及配置Claude Code 安装这里我默认大家都已经安装了nodejs，如果没有安装的话，请大家去下面的网址下载安装下。 Node.js — Run ...

最近大家关注Dify的进展的话，应该知道它的版本更新直接从1.8.0—>2.0.1了。跨越了一个大的版本。它本次的主要更新就在于知识库构建的知识流水线。 我认为Dify2.0以后的知识流水线会极大地降低了构建知识库的门槛，未来也许能高效处理 80% 的相对标准的文档。 但是，仍然会有20%，还是要依赖于我们人来手动处理。 我们都知道，现阶段来说，对于知识库，仍然是一个垃圾进垃圾出的状态，因此，在构建知识库之前我们需要对知识文档做很多的预处理。 今天这篇文章的分享，其实也是想给大家分享下我们自己手工处理文档的数据清洗思路。 1. RAG知识库的瓶颈知识库的质量不取决于模型，而取决于“垃圾进，垃圾出”的铁律。真正的瓶颈是ETL（抽取、转换、加载）过程，尤其是从非结构化源文档到结构化知识块（Chunks）的转换过程。 我们每个公司其实私有的数据量，私有的文档是非常庞大的，而它的内容又是千奇百怪的。针对一个合同，就可能有几十几百种格式，所以指望一套流程来完成这个非结构化源文档到RAG知识库的转变基本是不可能的。 我们如果想偷懒直接将某个文档上传到RAG知识库，就希望他回答的10...

整理十几个人的周报，是不是特烦人？ 我也烦，所以我用Dify搞了个自动化助手，从一个时不时抽风的玩具，迭代成了能在生产环境稳定跑的周报助理。 这篇文章主要就是记录下这个周报助理达到生产可用的过程和 几个问题的解决方法： 当模型输出不稳定时，别死磕Prompt，用“代码节点”这种确定性的方法才是王道。 不会写代码？没关系，现在AI就是你最好的程序员，我教你怎么让它给你打工。 工作流里那些意想不到的“小坑”（比如超时、渲染失败），怎么提前规避掉。 如果你也想把手里的 Agent 从 Demo 搞成真能用的东西，这篇文章的经验，你绝对能直接拿去用。下面，咱们就从头盘一盘这个“打怪升级”的过程。 1. 从0-1，先让Agent跑起来再说第一版，搭个简版大家可以看到第一个版本相对比较简单，就是一个判断节点+两个LLM节点。 因为初始版本只是想快速验证是否可行。 当然，一定是可行的，因为我自己拿着历史大家提交的原始版本和整理后的版本，反复迭代了一版提示词， 这个提示词有两个，本周的提示词和下周的提示词，并且将提示词在最好的模型上验证过（记得脱敏的，大家可千万别随便拿自己的数据去外面瞎搞...

1. 引子最近在做了一个邮件通知的小助手，这个dify工作流非常非常的简单，如下图所示，一个Agent的mcp查询节点，一个格式转换节点，一个邮件发送节点。 但是碰到了一个问题，就是受限于内部模型的能力，在react模式下调用mcp服务进行查询时，如果查询的数据量一旦超过10条，直接就会缺失非常多的数据。 但是如果使用其他模型，则不会出现这种问题。 所以最初，是想着下一个版本的优化，将Agent查询节点修改为http请求。又要有个但是，出现的问题是，不知道是什么原因，在内部使用这个http请求节点的时候，永远都是网络不通，而其实服务器和这个查询服务的地址是特意开通了的，使用代码访问就完全没问题。 所以最后的的方案就是继续让开发同志搞一个查询工具出来（因为之前碰到过邮件插件不好使的时候，开发同学也是这么干的）。 但是我感觉这事儿，根源还是得让运维同志解决。哈哈。 当然，这个点，也是我们今天这个事儿的起源。 后来开发同学实在是有点忙，而我呢，又着急用，所以就让开发同学给我个案例（邮件的那个）我看看复杂不，能用AI干不，我一看，这不是Python嘛，还就一个文件，AI应该比较擅长啊。...