最新文章

Notex：一个开源 NotebookLM 替代方案的实现

Notex 是一个受 Google NotebookLM 启发的开源替代方案，旨在提供本地优先、数据不外泄的文档智能处理与知识管理体验。其核心是一个基于检索增强生成（RAG）技术的系统，支持 PDF、Word 等多种文档格式的上传解析，并通过 AI 提供内容问答、总结、思维导图及幻灯片生成等功能。 项目采用务实的技术栈，后端使用 Go 语言（Gin + SQLite）以实现单一二进制部署，前端为嵌入式原生 JavaScript 单页应用。AI 调用层通过 LangChainGo 统一管理，支持 OpenAI、Ollama 本地模型及 Google Gemini。其架构的关键创新点在于将 RAG 与高级视觉内容生成深度集成。 具体实现上，系统处理了中英文混合的文档分词与检索策略。对于视觉化功能，幻灯片生成采用两阶段流程：先由 LLM 生成包含叙事与布局的大纲，再调用图像模型为每页生成配图。信息图生成则利用 Prompt Engineering 将文本转化为结构化的视觉描述描述，驱动图像模型输出手绘风格插图。思维导图生成则通过特定提示词模板，直接输出可渲染的 Mermaid.js 代码。整个系统形成了从文档解析、索引、AI 生成到可视化输出的完整闭环，在保证隐私的前提下提供了丰富的文档处理能力。

拆解Manus：真正有用的深度报告的生成

传统大模型在执行大规模分析任务时，会因上下文窗口被持续填满而导致信息压缩和质量下降，即“上下文窗口陷阱”。为解决此问题，业界探索出两条主要技术路线。其一以Google Gemini Deep Research为代表，通过升级模型、扩大上下文窗口并强化多步推理能力，适合需要深度综合分析的任务。其二以Manus Wide Research为代表，采用分布式并行架构：将大型任务拆解为多个独立子任务，由数百个具备独立上下文的子Agent并行执行，最后由主Agent汇总。这种方式从结构上规避了单Agent上下文溢出的瓶颈，确保大量独立对象（如数十家公司）分析深度的一致性。其架构借鉴了CodeAct论文思想，结合ReAct执行循环、沙箱隔离环境、有向无环图任务分解以及动态质量检测机制，模拟了人类研究员“规划-检索-分析-迭代”的完整工作流，标志着AI从聊天助手向具备规划、工具使用、迭代验证与综合能力的研究助手演进。

40+ Claude Code Tips： From Basics to Advanced

本文系统介绍了40余项Claude Code高效使用技巧，从基础设置延伸至高级工作流编排。核心建议包括：自定义状态栏以实时监控上下文消耗与项目状态；精简系统提示词以优化性能；利用语音交互提升沟通效率；将复杂任务分解为可管理的子问题以实现逐步解决。在开发集成方面，重点讲解了如何熟练运用Git与GitHub CLI进行代码提交、分支管理和PR审查，并强调定期启动新对话以保持上下文“新鲜度”。进阶技巧涉及在容器内安全执行高风险或长时间任务、借助Gemini CLI作为备用工具、以及通过半克隆对话等方式压缩上下文。文章还倡导将Claude Code视为通用接口与协作伙伴，建议用户通过持续实践、编写测试、简化代码及自动化工作流来深化其应用能力，最终实现个人化软件开发流程的全面升级。

中美 AI 竞争的差距到底有多大？

中美AI竞争的差距难以单一维度定义，专业基模能力上中国编程模型与美国差距约5%-10%，整体落后3-6个月，但在OCR等领域中国开源模型如PaddleOCR-VL-1.5已达SOTA。个人体验因任务而异：中文模型在生活问题回答上可能优于ChatGPT，编程领域简单任务MiniMax M2.1表现良好，复杂任务Claude优势明显。整体上中国基模落后但不超过一年，预测2026年差距缩小，因Scaling Law效果减弱，AI转向Online Learning利于追赶者。 模型能力极限方面，大多数用户无法压榨模型能力，如Opus

Android Perfetto 系列 10 - Binder 调度与锁竞争

本文聚焦 Android 跨进程通信核心 Binder 的性能瓶颈诊断，提供了一套基于 Perfetto 的实用分析工作流。文章首先阐明了 Binder 的基础架构与角色，随后重点讲解如何利用 `linux.ftrace` 数据源（捕获 Binder tracepoints、调度事件及 ART Monitor Contention）进行数据采集，并给出了具体的 Trace 配置模板。分析流程分为三步：首先通过事务耗时（如 `client_dur` 和 `server_dur`）定位问题调用；若耗时在派发阶段，则需评估 Binder 线程池是否饱和或缓冲区是否耗尽；若耗时在服务端，则需进一步排查代码逻辑、I/O 等待或 Java 锁竞争（通过 `dalvik` 类别观察）。文章同时介绍了 `am trace-ipc` 和 `binder-trace` 等辅助工具，旨在帮助开发者将复杂的跨进程调用链可视化，从而更直观地定位耗时、线程池压力及锁竞争问题。

我把 OpenClaw 跑在本地三周后，发现它根本不是聊天机器人

作者在本地部署并深度使用 OpenClaw 三周后，将其定位从 AI 工具重新认识为一套持续运转的“本地 AI 调度层”与工作系统。OpenClaw 的核心价值在于能够串联消息入口、定时任务、本地与云端模型、长期记忆及知识库（如 Obsidian），将信息流自动化、知识整理、日报复盘、工程协作等重复性、跨工具工作从依赖个人意志转为系统默认执行，从而实质性地推动工作流进展。 文章详细阐述了作者的实践配置与心得：采用 Mac Studio 高配硬件实现云端与本地模型混合调度；通过 SOUL.md、USER.md 等核心文件建立“文件化人格与规则”以实现稳定运行；管理 Skill 扩展以获取具体能力；在 Telegram 中按职责拆分多个 Agent 以保持上下文清晰；并始终将安全边界置于前置条件。 OpenClaw 的直接成果体现在 Obsidian 中持续积累的数百篇自动化任务文档、上千篇整理后的知识库内容以及标准化的研究资料。同时，作者也坦诚分享了其初期不稳定性、环境配置陷阱（如 Node 环境混用、文件路径处理）及自动化过度等踩坑经验。总结而言，OpenClaw 适合有持续工作流、愿意构建系统并深度整合 AI 的工程师与创作者，其最终效果是让系统从背后推动工作，产生工作流层面的复利。

SmartPerfetto 架构文章 Q&A：8 个深度技术问答

文章深入解析了SmartPerfetto架构的核心设计哲学，重点阐述了其在确定性约束与Agent自主性之间的平衡策略。关键机制在于三层配合：Strategy文件以声明式规则定义分析必须完成的步骤与硬性约束，Planning Gate强制Agent在执行前提交计划以确保规划纪律，而Verifier则在事后对关键分析动作进行多维度检查与纠错。这使得系统对核心分析路径（如滑动卡顿的根因深钻）施加强约束，而在探索性环节保留灵活度。 文章澄清了Agent与Workflow的本质区别，指出决策权分配应因环节而异。SmartPerfetto在数据收集阶段采用类似SOP的确定性策略（Workflow），而在需要因果推理和归纳的归因阶段充分信任LLM的自主能力（Agent）。其最终架构选择基于Claude Agent SDK，并叠加了场景分类、策略注入、验证纠错等自建约束层，而非固定控制流的ReAct或LangGraph。这一选择源于性能分析路径的不可预测性，使LLM能根据运行时数据自主选择分析路径，同时通过约束框架确保分析深度与完整性，定义了由观测能力、约束框架与反馈质量共同决定的Agent能力边界。

万字长文推演：手机不再从 App 开始，Agent OS 如何接管任务入口

该文从OpenAI手机产业链传闻切入，探讨了手机操作系统从以App为中心向以AI Agent任务为中心演进的系统性变革。核心观点在于，当用户目标从“打开App”转向“完成任务”时，手机OS需进行深层次的结构迁移：前台从App网格变为任务流，后台从App独占能力变为可授权能力，系统从管理进程窗口转向管理任务、上下文与责任。 文章指出，Agent OS需解决五个关键问题：持续理解用户状态、App转为后台能力提供者、建立可恢复审计的任务运行时、端云按需分工、明确跨边界执行的权限与回滚机制。针对Android平台，作者分析了其作为Agent OS基座的优劣，认为短期更可能从现有系统服务、能力声明框架（如AppFunctions）和Agent协议（如A2A、MCP）中渐进演化，而非彻底重构。变革的关键在于系统层需新增一套对象模型来管理任务（Task）、能力（Capability）、上下文（Context）、权限授权（Grant）和审计记录（Audit），从而将App封装为可调度的能力单元。 最终，这场变革旨在让用户从管理App图标转为管理任务状态，推动手机成为真正的智能任务执行中心。

SmartPerfetto 开源：面向 Android Trace 分析的 Perfetto AI Assistant

SmartPerfetto 是一个面向 Android 性能工程师的开源 AI 助手，深度集成于 Perfetto UI，旨在将重复性的 trace 数据查询与初步判断流程自动化，使工程师能更专注于核心归因与决策。该项目将 Perfetto UI 作为前端，在其基础上增加了 AI Assistant 面板；后端由 TypeScript 编写的 agentv3 运行时负责场景识别、计划编排、工具调用与报告生成；核心数据查询仍然依赖 Perfetto 官方的 trace_processor_shell 执行 SQL。 其核心设计是将领域分析经验封装为可执行的 YAML Skill（目前包含 165 个，覆盖滑动、启动、ANR、渲染管线等场景），并通过 MCP 工具协议向 Agent 暴露结构化操作，确保大模型不直接接触原始 trace 文件，而是通过调用 SQL、Skill 和内部工具来获取数据与结论。这种架构使得分析过程可重复、结果可展示、规则可审查与复用。 该项目选择在开发阶段开源，以期利用真实设备、厂商差异和业务 trace 样本来持续打磨其分析规则与策略。它并非替代工程师，而是作为一个能稳定执行查询、整理证据并按策略检查的分析辅助工具，帮助性能工程师从海量 trace 事件中快速定位问题侧，减少手动翻表与编写临时 SQL 的工作量。

别再傻等了，给 Claude Code 装个通知铃铛

这篇讲的是作者在使用Claude Code这类AI Agent时发现的一个痛点：任务跑在后台，总忍不住去查看状态，或者错过了需要授权的交互提示，导致效率低下。 他先是试了让LLM在任务完成时播放提示音，但发现这个“软提示”方案极不靠谱——LLM不会100%遵循指令，长对话还会压缩丢掉提示词，什么算“任务完成”也没个准谱。 于是他转向了确定性的“硬触发”方案：利用各平台的Hook机制，开发了`agent-notifier`这个SKILL。它能统一监听Claude Code、Copilot CLI、Cursor等多个平台的事件（如任务空闲、需要授权），然后并发地将通知发送到声音、系统通知、Telegram、邮件等多种渠道。 整个设计很巧妙，纯用Python标准库实现零依赖，拿过来就能用。核心是统一事件模型加并发分发，单个渠道失败也不影响其他。本质上是把通知这个“该确定的事”从不靠谱的LLM手里，交给了确定的Agent脚本去执行，最终实现了可靠的自动提醒。

全程用 Claude Code 搓了一个 macOS 原生应用：SkillDeck

文章作者因在多个AI编程助手（Claude Code、Codex、Gemini CLI、Copilot CLI）间切换时面临Skills管理分散、安装更新繁琐的问题，决定利用Claude Code全程辅助开发一款名为SkillDeck的macOS原生应用。该应用提供了统一的图形化界面，核心功能包括：三栏式仪表盘支持搜索与按Agent过滤；集成Skills市场实现一键安装；通过对比tree hash实现更新检测；提供SKILL.md编辑器；以及通过开关控制Skill在不同Agent间的symlink分配，实现一份Skill多处共享。开发过程体现了AI编程辅助跨语言开发的巨大潜力——作者虽无Swift与macOS开发经验，但通过清晰的需求提出、代码测试与问题反馈，借助AI完成了完整应用的开发。文中总结了多项AI编程实践技巧：每个功能在新对话中进行以避免上下文干扰、将AI生成的复杂分析结果保存为文档以节约token、利用`--resume`恢复会话但不宜长期依赖、以及通过`CLAUDE.md`文件设定开发规范（如Git分支策略、测试要求）来约束AI行为。项目已开源，旨在解决多AI代理下Skills生命周期管理的痛点。

SkillDeck 支持 OpenClaw 了，顺便聊聊小龙虾

SkillDeck 刚更新了 v0.0.14，正式支持了 OpenClaw。这次更新主要有两方面：一是新增了对 Antigravity、Cursor、Kiro、CodeBuddy 和 OpenClaw 本身的 Skills 目录管理，现在总共支持 10 个主流 AI coding agent；二是直接集成了 ClawHub 市场，可以在 SkillDeck 里浏览、搜索并一键安装 Skills，不用再手动操作。 作者借着这次更新，也聊了聊对 OpenClaw 这波热潮的看法。他认为爆火背后是自媒体的焦虑传播、AI 公司卖 token、云厂商卖服务器等多方推动。OpenClaw 的本质更像是一个高级自动化工具，核心是让 AI 通过模拟操作来帮我们执行任务。但当前最主要的问题是权限过大，已经出现了不少安全案例，比如公网暴露导致电脑被远程控制。 理想的解决方案或许是让应用间通过标准化的 AI 可识别接口通信，但这涉及厂商的商业利益，还有很长的路要走。最后作者提醒，工具是用来解决问题的，不必盲目追逐热点，Claude Code 等工具已具备的循环任务功能，其实和 OpenClaw 没有本质区别。

从「能用」到「好用」：LLM 流式响应实现方式的探索之路

在LLM应用开发中，Server-Sent Events已成为实现流式响应的事实标准，它基于HTTP协议轻量地实现实时数据推送。文章深入探讨了如何将SSE接口从基础的“能用”状态优化至“好用”层面。传统请求-响应模式需等待完整生成结果，而流式输出能实时展示模型的思考过程、工具调用及逐字生成内容，显著提升交互体验。基础实现虽简单——仅需设置正确的Content-Type和逐块写入事件流，但生产级应用需解决事件抽象、组件复用及优雅取消请求等挑战。作者通过实际编码演示，逐步拆解设计思路，引导读者掌握构建高效、可维护流式响应架构的方法，最终实现从功能演示到工程化实践的跨越。

1Panel 部署 FastAdmin 管理端访问 302 解决方案

最近使用 1Panel 面板部署 FastAdmin 项目用于测试，站点的伪静态选择 thinkphp，在部署完成后发现用户端可以正常访问，而管理端则会无限制重定向到 login/index，最终提示 “重定向次数过多...” 如下图所示：

经过排查 发现问题出现在 1Panel 自带的 fastcgi-php.conf 上这个文件上，如图 21 行:

解决方案是注释掉这一行，然后使用 fastadmin 官方推荐的 fastcgi 配置，代码如下：

location ~ [^/]\.php(/|$) {
        fastcgi_pass 127.0.0.1:9000; 
        # include fastcgi-php.conf;  # 注释掉这一行或者直接复制我的示例代码
        include fastcgi_params; 
        fastcgi_index index.php; 
        fastcgi_split_path_info ^((?U).+\.php)(/?.+)$; 
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
        fastcgi_param PATH_INFO $fastcgi_path_info; 
        fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; 
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
    }

保存修改的配置后，fastadmin 管理端入口即可正常访问：

使用版本为 1Panel 2.0.16, OpenResty 版本为 1.27.1.2-2-3-focal

解决访问 https 网站时，后端重定向或获取 URL 变成 http 的问题

在常见的Nginx反向代理后端Java应用的部署架构中，客户端与Nginx之间为HTTPS，但Nginx转发至后端服务器的请求协议为HTTP。这会导致后端应用通过`HttpServletRequest.getRequestURL()`获取到的URL为内网HTTP地址，且`HttpServletResponse.sendRedirect()`生成的重定向地址也为HTTP，无法反映真实的客户端访问协议。 解决此问题需结合Nginx配置与后端代码调整。对于URL获取问题，需在Nginx中通过`proxy_set_header Host $host`和`proxy_set_header X-Forwarded-Proto $scheme`向后端传递原始主机名与协议信息。后端Java应用则需通过自定义Servlet过滤器，读取`X-Forwarded-Proto`头并重写请求的`getScheme()`与`getRequestURL()`方法，确保返回正确的HTTPS URL。对于重定向问题，可通过Nginx的`proxy_redirect http:// $scheme://`指令，将后端响应中的Location头协议自动修正。 当架构中Nginx前存在负载均衡器时，需由负载均衡器透传`X-Forwarded-Proto`头，同时将Nginx配置中相关的`$scheme`变量替换为`$http_x_forwarded_proto`，以正确识别和传递最前端的访问协议。

Windows 95 defenses against installers that overwrite a file with an older version

早期16位Windows系统中，许多系统组件可由程序安装包分发，导致程序安装程序常直接覆盖系统文件，可能将Windows 95组件替换为更旧的版本。Windows 95通过建立隐藏的备份目录SYSBCKUP来应对：安装程序完成后，系统会检测关键文件是否被覆盖；若新覆盖文件的版本高于备份版本，则将其存入备份目录；若版本较低，则用备份文件还原，从而防止系统组件被降级。此前曾尝试直接阻止覆盖操作，但引发了更多兼容性问题，最终采用“先允许覆盖、后自动修复”的策略更为有效。

Use Obsidian Sync on Desktop without Installing Obsidian

作者在使用Obsidian Sync时面临一个问题：Obsidian GUI是一个基于Electron的重型应用，运行桌面端同步时占用资源多，且一旦关闭同步就会中断。为解决此问题，作者采用了Obsidian发布的headless同步终端客户端obsidian-headless。该客户端通过CLI命令（如ob --continuous）实现笔记文件夹的实时同步，无需运行GUI应用。具体配置步骤包括：使用npm全局安装obsidian-headless，通过ob login和ob sync-setup

Geist in the machine

本文探讨人工智能与人类独特性的哲学和技术辩论，聚焦智力、意识和人格三个传统维度，并延伸至认识论、美学和伦理学等领域的当代冲突。AI的智力基于符号知识获取和问题解决，但缺乏身体和需求，限制了其智能；意识涉及内在感质与外在意向性，难以通过图灵测试捕捉；人格要求能动性，涉及道德责任和理由

中文 Markdown 强调标记的渲染问题

中文Markdown在强调标记（如`**文字**`）的渲染中常出现异常，表现为星号未被正确解析为加粗格式。问题根源在于CommonMark规范为提升语法严谨性引入的“左侧贴合”与“右侧贴合”规则，这些规则依赖空格判断文本边界，但无法适应中文无空格分词的书写特性，导致符合中文语义的强调标记被错误判定为无效。相比之下，早期Markdown.pl的简单正则匹配反而能正确处理中文场景。 针对此问题，现有解决方案包括：直接使用HTML `` 标签、在强调标记外侧插入普通空格以满足贴合要求，或使用零宽空格（U+200B）进行不占位的视觉修正。部分AI服务和Markdown处理器已针对CJK文字进行了适配。文章同时指出，在中文排版中依赖粗体强调本身并非理想实践，应优先通过语义和句式变化突出重点。