WWW.YOUINFO.SITE
标签聚合 知识

/tag/知识

LinuxDo 最新话题 · 2026-06-11 22:40:00+08:00 · tech

本帖使用社区开源推广,符合推广要求。我申明并遵循社区要求的以下内容: 我的帖子已经打上 开源推广 标签: 是 我的开源项目完整开源,无未开源部分: 是 我的开源项目已链接认可 LINUX DO 社区: 是 我帖子内的项目介绍,AI生成、润色内容部分已截图发出: 是 以上选择我承诺是永久有效的,接受社区和佬友监督: 是 以下为项目介绍正文内容,AI生成、润色内容已使用截图方式发出 (全文上万字符长时间手打+十数张图,先前已经多次回复说明情况却都被认为是ai生成举报,上百楼内容丢失,哪怕为了其他佬友的认真讨论与交流的内容都请勿随意举报!如有意见请友好私信交涉) 注:这里有一个三分钟使用极简教程,正式使用前推荐看看:【全开源免费!抢先体验属于个人的Easy Research!Obsidian开发者手把手教你三分钟速通NotEMD!-哔哩哔哩】 https://b23.tv/lqR0RlA 2026.05.25: 在版主提醒下,L站禁止给群组引流,有需要进一步交流需要请给项目点star或私信本人。 安装 Obsidian 社区插件里直接搜索 Notemd 或者去 GitHub 仓库查看源码和 release 项目地址: GitHub: notemd github项目 Obsidian Community Plugin: 搜索 Notemd 下面是正文 这两年关于 AI 读论文的讨论很多。但这个阅读的痛点始终存在:读完以后,内容有没有留下来? 在对话框里提问很方便,模型也能很快给出总结、翻译和解释。但过几天再回看,常见结果只有一个模糊印象。论文的核心概念、方法关系、实验设置、局限性,以及它和已有知识的连接,往往没有真正进入自己的知识库。 所以我现在更在意一件事:把论文阅读过程中有价值的内容,持续写回 Obsidian。 Notemd 就是在这个场景里我用得比较顺手的工具。它把论文笔记、概念卡片、研究摘要、翻译、图表和工作流放在同一个工作台里,让一次阅读不只停留在一次对话,而是变成后面还能继续调用的资料。 一句话介绍: Notemd 是一个开源的 Obsidian 社区插件,用来把论文阅读过程中的概念链接、概念笔记、原文证据摘录、背景补充、翻译、图表和工作流沉淀回知识库,并支持多语言 UI、README 和内容转换。 实际阅读状态示例: 多语言支持: 我想解决的问题:读完一篇之后,还能继续积累 我现在看“AI 读论文”,关注点已经在长期积累能不能形成。 你当然可以把 PDF 丢给模型,让它做总结、翻译、解释公式、分析贡献。这些都很有用。但论文不是孤立存在的。每次读到的新术语、方法、数据集、实验范式,理论上都应该慢慢长进自己的知识网络里。 我更想要的结果是这些: 一篇论文读完以后,关键概念被自动补成 [[wiki-link]] 新出现的概念可以继续生成概念笔记 我关心的问题能直接定位到原文证据,而不只是拿到一段转述 背景资料和补充搜索能附着在当前笔记旁边 复杂方法链路可以压成 Mermaid 或图表,方便回看 这些结果都留在 vault 里,而不是散在不同聊天记录中 Notemd 的价值也正是: 它把论文阅读变成一条可以复用、可以回看、可以持续补充的知识流。 和聊天式 AI 相比, Notemd 更适合把结果沉淀进知识库。 维度 聊天式 AI(如Smart Composer插件的功能) Notemd 核心落点 当前会话 当前笔记和 vault 文件 结果形态 一段回答 链接、概念笔记、译文、图表、日志、工作流产物 适合场景 快速问答、临时解释 长期阅读、积累、复用 主要风险 聊完就忘,不利于回忆与搜寻 需要自己维护知识库结构 这两种方式并不冲突。我自己也会继续用对话式 AI (例如Obsidian中的Smart Composer等插件)针对论文做即时追问。但如果目标是让今天读过的东西,三周后还能准确记忆与获取,那么文件化、结构化和可回写会更重要。 结构化总结: 我现在比较顺手的一套论文工作流 Notemd 当前处理的是 Markdown / txt 内容,不是直接载入 PDF(但打开开发者选项后个别不需要修改原文的任务是支持载入其他格式)。这会让整个流程更干净,并且MD是AI的原生语言。 1. 先把 PDF 变成 Markdown 我一般会先用 MinerU 之类的工具做 PDF → Markdown,再把结果放进 Obsidian。 (当前MinerU在目前的免费软件里使用起来解析质量高且速度较快) 这样做有几个直接好处: 原文结构更清晰 注: v1.9.1已支持章节结构提取功能 后续链接、翻译、提取、图表都围绕同一份 Markdown 笔记发生 你的“论文阅读结果”本身就是知识库资产 注意,后面的大部分自动化,都要求原文已经进入你的知识库,是Notemd可处理的文件。 2. 先做概念链接,再做概念沉淀 导入 Markdown 以后,我一般先运行这两个指令: 处理文件(添加链接)| Process file (add links) 从标题批量生成| Batch Generate from Title 前者会把论文里的关键概念补成 [[wiki-links]] ,后者则可以借助高质量AI(比如 降智前 的Gemini-3.1-pro)把每个概念扩充为深入的领域知识与术语间关系的总结,支持调用搜索 api(比如 Tavily)做定向搜索后生成。 很多论文难读,原因很简单:默认你已经知道太多术语。backbone、训练范式、benchmark或是统计指标,而实际上需要你临时去查,特别是当你不了解这个领域时更是无从查起。 因此我通过Notemd将这些概念用ai提取后直接沉淀到固定的或者是自定义领域的概念文件夹里。这样第二篇、第三篇相关论文读下去时,已有概念会越来越完整,不需要每次从头补背景。 如果你愿意的话可以打开概念日志,每次新增了哪些概念都有记录。并且, 我已经将这套流程固化为一键处理按钮,不需要拆解单独执行(但需要注意tokens消耗),最大化便利佬友们使用。 3. 用“提取特定原始内容”做证据导向的精读 “提取特定原始内容”顾名思义,是获取原文中的依据,适合继续做精读笔记、组会汇报,或者后面写 related work 时快速回查。 你可以先在设置里定义一组问题,例如: 这篇论文的核心贡献是什么? 作者如何定义问题? 实验设置是什么? 主要 baseline 有哪些? 作者明确承认了哪些 limitation? 然后让插件从当前论文里逐字提取对应原文片段。 如果你希望明确知道“这句输出到底对应原文哪一句”,记得使用这个功能 4. 不懂的背景用 Research & summarize 试试 如果需要临时查阅当前论文或笔记的特定只是,我不会立刻跳出 Obsidian 去开很多网页,可以在当前笔记旁边做 Research & summarize 。它会调用你配置好的搜索服务和 LLM,把主题相关的补充信息整理出来,附加回当前笔记。 背景知识不散在浏览器标签页里 你查过什么,和当前 paper 绑定在一起 后面回看时,论文旁边就是当时补的上下文 我主要用它补背景和补术语网络,不替代正式文献检索。在课题早期扫盲阶段能明显降低阅读门槛。 5. 英文精读压力大时,直接翻译,但翻译结果也应该保存到本地 当前很多 AI 翻译论文的方案,问题通常是单次翻译没有有效落盘, Translate current file 这个链路的价值,在于它会把译文作为 Obsidian 里的另一份产物保存下来,成功后还会直接在侧边栏打开。 多语言知识库用户可以实现:原文、译文、概念卡片、研究摘要都能在同一个 vault 里互相引用,不需要来回搬运。并且由于 UI Locale 和 Task Output Language 是分开的,界面语言可以跟着 Obsidian 走中文,任务输出也可以保持英文,反过来配置也可以。科研场景里,这种拆分很方便。 这是效果图,内容摘选自 Feynman 的物理学讲义: 6. 最后把理解压缩成图 论文阅读与领域学习的过程中很常见的问题是:脑子里一堆概念,但没整理出结构。 有这两个功能可以辅助解决: Summarise as Mermaid diagram Generate diagram (experimental) 前者更适合方法流程、模块关系、因果链路这类结构化内容。后者在当前版本里已经覆盖 Mermaid、JSON Canvas 和 Vega-Lite 等图表路径,其中 dataChart 还能用 Vega-Lite 生成更规整的数据图。 图是一种"理解压缩层"。让 AI 把论文画成流程图、关系图或数据图,它必须先把结构显式整理出来。检查图的时候,也更容易一眼看出哪里有问题。 注意:图不是事实本身。AI 生成的图,尤其是科研图,只适合当草图、摘要层和检查层,不适合不经核对直接当最终结论。 如图, v1.8.4 最新版支持众多种类图的生成: 下面再给一些图类型的举例: Mermaid正常图: 时序图: 7. 最后用工作流把这些动作串起来 如果上面这些动作每次都手动点一遍,久了还是会烦。所以 Notemd 里我很喜欢的另一个点是:你可以把常用动作编成自己的 One-Click Workflow 。 默认就有一个 One-Click Extract 功能把几个动作串起来跑。除此之外,你也可以按自己的论文习惯重组,比如: 论文入库::process-current-add-links>extract-concepts-current>research-and-summarize>summarize-as-mermaid 在设置中有非常高度自定义工作流的支持: 对我来说,工作流的意义除了少点几次按钮,还有真正把阅读习惯固定下来。你跑得越多,知识库结构就越稳定,后面的复用价值也会越高。 这个项目更偏实际工作流程落地,有下面这些突出优点 完整开源 。github开源,具体设置有文字+多图说明。 模型选择自由 。支持 OpenAI、Anthropic、Google、DeepSeek、Qwen、Ollama,以及通用 OpenAI Compatible 网关。 注: v1.9.1 已支持“获取模型列表”功能。 不同的任务均支持对特定的模型进行配置 。对于链接、研究、翻译以及生成等任务,均能够独立地去进行 provider 以及 model 的选用。 对于每一个具体需要去执行的任务,都支持开展 prompt 的修改工作 。这就为插件在功能拓展方面提供了相当充裕的空间。 结果都会以文件的形式来予以保存 。在开展学习的过程当中,插件会把相对应的链接、概念笔记、译文、图表以及日志都进行留存。 在本地用户友好性方面表现得十分出色 。针对那些已经习惯于去使用 Obsidian 的用户来说,这一工具可以直接在既有的工作台环境当中去嵌入 AI 相关的能力,这样一来,就完全不需要再去对一整套既有的笔记体系开展任何的替换工作。 它能帮你构建"外部大脑",但真正记住与掌握,开始实践的只能是你自己。 哪些人应该尝试这个插件: 已经在用 Obsidian 管理读书或论文笔记的人 面对较大规模的文献阅读量,且期望将零散理解逐步构建为系统化知识网络的人 不满足于“总结一下”,而是想把概念、证据、图表和上下文都留下来的人 期望将翻译、搜索、概念提取以及图表生成整合至同一工作台之中的人群 对模型选择上期望自由切换云端和本地部署模型的人 如果你只是偶尔看一两篇 paper,能协助你完成翻译与核心概念的提取工作,上手门槛很低,并且有保姆式视频教学。 如果你有长期积累需求,它的价值会更为显著,因为这些结果最终均会沉淀于个人知识库之中。 如果大家感兴趣,后面我还可以再单独整理一篇更偏实操的帖子专门针对大家的后续问题,比如: 我怎么配置提取问题模板 如何把 prompt 开展有针对性的调整工作,来让它得以深度契合到不同的学科领域以及具体的任务场景当中 …… 如果觉得喜欢有所收获,对你有帮助,就支持一下吧! LINUX DO Credit 3 个帖子 - 3 位参与者 阅读完整话题

LinuxDo 最新话题 · 2026-06-11 09:47:38+08:00 · tech

微信接入 AI 自动回复,解放双手的全新方案 还在为微信群消息太多没空回复而烦恼? 还在担心错过好友的重要消息? 给你的微信装一个 24 小时在线的 AI 管家,让一切变得简单。 它是什么? VX 智能 AI 是一个将微信与大型语言模型深度结合的系统。 它能实时监听微信消息,通过 AI 自动回复好友和群聊,支持知识库问答、关键词触发、白名单管理等多种模式。 简单说:你登录微信,它帮你回消息。 当前有的核心功能 智能回复 · 像真人一样聊天 支持接入 智谱 GLM、Dify、FastGPT 等多种 AI 引擎,回复自然流畅。无论是好友私聊还是群聊,都能回复。 群聊管理 · @触发不打扰 可指定哪些群开启 AI 回复, 仅在 @机器人 时触发 ,不干扰群内正常对话。适合客服群、社群运营等场景。 白名单模式 · 只回该回的人 支持设置白名单好友名单, 只有白名单内的好友才能触发 AI 回复 。保护隐私,精准服务。 关键词触发 · 自动化响应 预设关键词,当消息命中时自动回复指定内容。适合常见问题自动解答、菜单查询等场景。 消息工作台 · 全局掌控 一个页面查看所有会话消息,支持: 会话列表 + 未读消息气泡 消息状态标记(已回复/待处理/失败) 手动发送消息 联系人信息查看 知识库集成 · 让 AI 更懂你 对接知识库服务,AI 可以基于你提供的资料回答问题。适合 产品 FAQ、内部知识库、客服话术 等场景。 适用方向 场景 说明 社群运营 自动回复群成员常见问题,24h 在线 电商客服 白名单模式只回复客户,自动解答售前售后 个人助手 好友消息自动回复,不遗漏每个联系 教育社群 关键词触发课程资料、报名链接等 服务行业 预约查询、业务咨询自动应答 技术栈 前端:React 18 + Vite 5 + Tailwind CSS 后端:Python FastAPI + SQLite 接口:RESTful API 对接:pywxrobot 微信协议 AI:智谱 GLM / Dify / FastGPT 开源、轻量、易于部署,支持 Windows/Linux。 根据个人呢知识库,实现微信智能回复,大家在生活中都有什么需求啊 3 个帖子 - 3 位参与者 阅读完整话题

LinuxDo 最新话题 · 2026-06-10 16:14:20+08:00 · tech

枚举和注解 枚举 基础知识 枚举是一组常量的集合。枚举属于一种特殊的类,里面只包含一组有限的特定的对象。 其实枚举类是可以通过传统写法自定义的,写法为: 构造器私有化 不提供set方法 在类内部预先初始化好静态的实例,并且对外暴露 代码略,直接学习如何创建真正的枚举。 使用enum关键字来代替class 直接写FALL(“秋天”,“凉爽”),效果上等价于 public static final Season FALL = new Season(“秋天”,“凉爽”); 如果有多个常量对象,使用逗号间隔即可 使用 enum 实现枚举,必须把定义的常量对象写在枚举类的最前面 使用无参构造器时,可以把括号也省略,直接写FALL,举例 FALL, SPRING, SUMMER, WINTER; public class Enum { public static void main(String[] args) { System.out.println(Season.SPRING); } } enum Season{ SPRING("春天","温暖"), SUMMER("夏天","炎热"), FALL("秋天","凉爽"), WINTER("冬天","寒冷"); private String name; private String desc; Season(String name, String desc) { this.name = name; this.desc = desc; } @Override public String toString() { return "Season{" + "name='" + name + '\'' + ", desc='" + desc + '\'' + '}'; } } .java文件可以用 Javac 编译成.class文件,.class文件也可以用 Javap 反编译成字节码文件,通过观察先编译再反编译的结果,可以看到很多隐藏的细节。 对于 Seanon 类,反编译得到的代码如下 Compiled from "Enum.java" final class hspedu.inner.enumer.Season extends java.lang.Enum<hspedu.inner.enumer.Season> { public static final hspedu.inner.enumer.Season SPRING; public static final hspedu.inner.enumer.Season SUMMER; public static final hspedu.inner.enumer.Season FALL; public static final hspedu.inner.enumer.Season WINTER; public static hspedu.inner.enumer.Season[] values(); public static hspedu.inner.enumer.Season valueOf(java.lang.String); public java.lang.String toString(); static {}; } 值得关注的细节有: 枚举类是 final 类型的,因此不可被继承 枚举类默认继承 java.lang.Enum 类,因此不可继承其他类 每一个常量都默认是 public static final 类型的 简单练习 第一题 判断语法正误 enum Gender { BOY, GIRL; } 答案: 语法没有错,相当于一个“没有属性,只含有无参构造器”的枚举类 第二题 判断输出什么 enum Gender2 { BOY, GIRL; } Gender2 boy = Gender2.BOY; Gender2 boy2 = Gender2.BOY; System.out.println(boy); System.out.println(boy2 == boy); 答案: BOY true 分析: 首先,枚举类本质也是类,所以Gender2 boy = Gender2.BOY;这种写法肯定是对的 boy相当于拿到了枚举类里的public static final常量,因此boy和boy2肯定是一样的 System.out.println(boy)相当于调用Gender2的toString方法,但是显然它没有,就去找父类的toString方法,父类是java.lang.Enum(前面有提到) Enum类的成员方法 分别是 name、ordinary、values、valueOf、compareTo方法,建议自己写一写用一用,方法的效果都写在代码里了: public class Enum { public static void main(String[] args) { Season spring = Season.SPRING; // name方法,建议优先使用toString,效果类似 System.out.println(spring.name()); System.out.println(spring); // ordinary方法,输出该枚举对象的序号,从0开始 System.out.println(spring.ordinal()); // values方法,返回所有的枚举对象 Season[] values = Season.values(); for (Season value : values) { System.out.println(value); } // valueOf方法,返回指定名称的枚举对象 Season valueOf = Season.valueOf("FALL"); System.out.println(valueOf); // compareTo方法,比较两个枚举对象,返回它们的序号之差,在这里是spring的序号 - valueOf的序号 System.out.println(spring.compareTo(valueOf)); } } enum Season{ SPRING("春天","温暖"), SUMMER("夏天","炎热"), FALL("秋天","凉爽"), WINTER("冬天","寒冷"); private String name; private String desc; Season(String name, String desc) { this.name = name; this.desc = desc; } } 简单练习2 声明 Week 枚举类,其中包含星期一至星期日的定义; MONDAY, TUESDAY, WEDNESDAY, THURSDAY,FRIDAY, SATURDAY, SUNDAY; 使用 values 返回所有的枚举数组,并遍历,要求打印值为“星期一”而不是“MONDAY” public class Enum { public static void main(String[] args) { Week[] values = Week.values(); for (Week value : values) { System.out.println(value); } } } enum Week{ MONDAY("星期一"), TUESDAY("星期二"), WEDNESDAY("星期三"), THURSDAY("星期四"), FRIDAY("星期五"), SATURDAY("星期六"), SUNDAY("星期日"); private String name; Week(String name) { this.name = name; } @Override public String toString() { return name; } Enum类的接口 Enum类本身已经有了继承关系,因此不能继承其他类 但作为一个类,它仍然可以实现接口 interface Playing { void play(); } enum Music implements Playing { HARD_ROCK, POP, CLASSIC, ROCK, JAZZ; @Override public void play() { } } 注解 最基本的修饰符 最基本的三个修饰符分别是: Override:用来限定某个方法必须重写父类的方法,只能用于方法 SuppressWarnings:抑制编译器的警告 Deprecated:用来表示某个程序元素(比如类或者方法)已经过时 Override 其实对于正确的方法重写来说,加不加这个修饰符都可以。 但如果加了的话,编译器会检查你是否有正确地重写这个方法。如果不正确的话会报错,产生编译错误。 Override的源码如下,从 @Target (ElementType.METHOD) 上可以看出,这个修饰符只能用在方法上。 @interface 修饰的类都是注解类。 @Target(ElementType.METHOD) @Retention(RetentionPolicy.SOURCE) public @interface Override { } 顺带一提, @Target 是修饰注解的注解,也称为元注解。 Deprecated 用 @Deprecated 修饰符修饰的元素,暗示其已经过时了,不推荐再继续使用,但其实可以使用。 @Documented @Retention(RetentionPolicy.RUNTIME) @Target(value={CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE, MODULE, PARAMETER, TYPE}) public @interface Deprecated { String since() default ""; boolean forRemoval() default false; } 从源码可以看出,该修饰符可以修饰方法、字段、包、参数等。 该关键字一般用于 JDK 版本更迭时,给过时的方法打上标注。 SuppressWarnings 用来抑制编译器警告,在 ( ) 中可以填抑制的警告类型。 因为懒得打字,我直接把文档粘在这: 参数名称 作用描述 all 抑制所有警告。 unchecked 抑制与泛型相关的“未经检查的操作”警告,例如在使用原始类型时。 deprecation 抑制使用了 @Deprecated 标记的过时类或方法的警告。 rawtypes 抑制使用了泛型但未指定具体类型的“原始类型”警告。 unused 抑制代码中存在但未被使用的变量、方法或类的警告。 serial 抑制可序列化的类未定义 serialVersionUID 的警告。 null 抑制与空值分析相关的警告(如潜在的空指针)。 cast 抑制与强制类型转换操作相关的警告。 fallthrough 抑制在 switch 语句中缺少 break 而导致“直通”的警告。 finally 抑制 finally 块无法正常返回的警告。 boxing 抑制与自动装箱(boxing)和拆箱(unboxing)操作相关的警告。 static-access 抑制不正确的静态成员访问方式的警告。 dep-ann 抑制使用过时注解的警告。 incomplete-switch 抑制 switch 语句中未覆盖所有枚举常量的警告。 javadoc 抑制与 Javadoc 相关的警告。 synthetic-access 抑制内部类访问未优化的警告。 resource 抑制与资源(如 Closeable )使用相关的警告。 restriction 抑制使用了不建议或禁止引用的警告。 使用示例,代码如下: @SuppressWarnings({"all"}) enum Music implements Playing { HARD_ROCK, POP, CLASSIC, ROCK, JAZZ; @Override public void play() { } } @SuppressWarnings是没有对使用位置限制的,从源码中也可以看出,它没有 @Target 去限制,源码如下: @Retention(RetentionPolicy.SOURCE) public @interface SuppressWarnings { String[] value(); } 元注解 注解的注解,看源码时可能遇到,没那么重要,快速过一下。 四种元注解: Retention:指定注解的作用范围,三种值SOURCE,CLASS,RUNTIME Target:指定注解可以在哪些地方使用 Documented:指定该注解是否会在javadoc体现,即在生成文档的时候,可以看到该注解 Inherited:子类会继承父类注解 这部分我战略性跳过了,稍微不太好理解,也有点深入了。 1 个帖子 - 1 位参与者 阅读完整话题

LinuxDo 最新话题 · 2026-06-10 11:28:13+08:00 · tech

vibe coding确实让程序员变得浮躁了,没有耐心看代码(也看不过来)更没耐心手敲代码了,但好在从古法编程时代过来,好歹能看懂代码以及知道其是如何运行的,心里有点底。 那么计算机专业的学生呢,毕竟vibe coding能让人实实在在看到“成果”,谁还会去结合新学的知识去手敲-运行-找语法错误?不过也或许这种旧时代的学习方式根本不需要了。 7 个帖子 - 7 位参与者 阅读完整话题