Mars

OSINT Explorer：1300+ 免费开源情报工具导航与合规使用指南

Mon, 08 Jun 2026 00:00:00 GMT

如果你做过安全研究、舆情分析、威胁情报、品牌风控，或者只是想把一个公开线索查清楚，应该很快会遇到一个问题：OSINT 工具太多了。

邮箱查询、用户名枚举、域名解析、证书透明度、社交媒体搜索、图片反查、泄露数据核验、地图与地理位置、公司注册信息、区块链浏览器、暗网索引、元数据分析……每个方向都有一堆工具，每个工具又有自己的适用范围、免费额度、地区限制和数据源偏差。

所以我今天想记一下这个工具导航：OSINT Explorer。

它在站点元数据里的名称是 OSINT Brasil，作者标注为 Juan Mathews Rebello Santos。站点对自己的定位很直接：一个免费的 OSINT 工具目录，收录 1300+ 个开源情报工具，支持 30+ 种语言，并且强调工具数据会自动从 GitHub 上的 awesome-osint 资源更新。

这类导航真正的价值，不是“帮你点开一个工具”，而是把混乱的开源情报工具生态整理成一个可检索、可筛选、可复用的入口。对初学者来说，它降低了入门门槛；对熟手来说，它更像一个调查前的工具箱索引。

什么是 OSINT#

OSINT 是 Open Source Intelligence 的缩写，中文通常叫“开源情报”或“公开来源情报”。

这里的 “Open Source” 不是单指开源软件，而是指公开、可自由访问、无需未授权入侵即可获取的信息来源。常见来源包括：

搜索引擎结果
新闻报道和公开文章
社交媒体公开内容
政府、法院、工商、招投标等公开数据库
域名 WHOIS、DNS、证书透明度日志
GitHub 等代码托管平台公开仓库
公司官网、招聘页面、帮助文档、状态页
图片、视频、地图、卫星影像等公开资料
安全公告、漏洞库、恶意样本情报平台

OSINT 的核心不是“偷偷拿数据”，而是把公开数据变成可验证、可解释、可交叉印证的分析结论。真正专业的 OSINT 工作，更像情报分析和证据整理，而不是到处乱搜。

flowchart LR A["公开来源"] --> B["检索与采集"] B --> C["清洗与去重"] C --> D["交叉验证"] D --> E["时间线与关系图谱"] E --> F["结论与风险判断"] F --> G["合规留痕"]

这也是为什么一个好的 OSINT 导航站很重要：它不是替你做判断，而是让你更快找到“下一步应该用什么工具验证”。

OSINT Explorer 到底解决了什么问题#

很多人第一次接触 OSINT，会直接去搜“邮箱查询工具”“手机号查询工具”“域名反查工具”。这种方式短期有效，但长期会非常低效，因为你很难知道：

工具是否还活着
工具是免费还是付费
工具偏向哪个国家和地区
工具查的是实时数据还是历史快照
工具结果是否能导出、复查、引用
工具是否需要注册账号或提交敏感查询
工具背后是否会记录你的查询目标

OSINT Explorer 的价值就在这里。它把大量工具集中在一个目录里，通过搜索、分类、语言和收藏等能力，把“找工具”这件事从搜索引擎随机碰运气，变成一个更像工程化索引的动作。

根据站点公开元数据，它有几个明显特征：

维度	说明
工具数量	收录 1300+ 个 OSINT 工具
访问方式	Web 页面，可直接在线浏览
数据来源	站点描述称会从 GitHub 的 awesome-osint 资源自动更新
语言支持	支持 30+ 种语言
使用成本	站点本身免费，不要求用户先注册
目标用户	调查人员、记者、安全分析师、研究人员、网络安全从业者
辅助能力	搜索、过滤、收藏、明暗主题等

这类站点最适合放在浏览器收藏夹里，不一定每天打开，但一旦你要做公开信息核验、资产摸底、线索归类，它会很省时间。

工具分类应该怎么理解#

OSINT 工具导航最容易让人眼花，因为分类太多。我的建议是不要按“工具名”记，而是按“线索类型”记。

一个公开情报任务，通常会围绕几个实体展开：人、组织、域名、IP、账号、邮箱、手机号、图片、地点、文件、代码仓库、钱包地址、事件时间线。你手里有什么线索，就从对应实体切入。

1. 社交媒体与用户名#

社交媒体 OSINT 主要关注公开账号、用户名复用、头像复用、公开发帖、关注关系、简介字段、历史昵称和外链。

这类工具适合做品牌冒用排查、虚假账号识别、公开舆情研究、新闻事实核验。真正有价值的不是“找到一个账号”，而是判断多个账号之间是否存在可解释的关联。

专业做法通常会注意三件事：

用户名相同不等于同一个人
头像相同可能来自模板、盗图或转载
平台时间线、语言习惯、外链、互动关系需要互相印证

2. 邮箱与账号暴露#

邮箱是很常见的 OSINT 入口。它可能出现在公开代码提交、论坛资料、公司页面、数据泄露通知、邮件安全配置、Gravatar 头像或注册状态检查里。

对个人来说，邮箱 OSINT 更适合用于自查：看看自己的邮箱有没有出现在公开泄露事件、是否被写进了公开仓库、是否暴露在不该暴露的页面里。

对企业来说，它适合做攻击面管理：识别哪些员工邮箱暴露在公开页面、哪些域名没有配置好 SPF / DKIM / DMARC、哪些历史邮箱可能仍被钓鱼利用。

3. 手机号与通信线索#

手机号相关 OSINT 很敏感，因为它直接触及个人隐私。合法场景通常是本人自查、企业客户资料合规核验、反欺诈、账号安全排查，或者经过授权的调查工作。

技术上，手机号可能关联到地区号段、公开页面、社交应用注册状态、历史黄页信息、泄露数据痕迹等。但在实际使用里，最重要的是边界：不要把工具用于骚扰、跟踪、肉搜或未经授权的身份定位。

一个成熟的 OSINT 使用者，应该把手机号视为高敏标识符。能不用就不用，必须用时要有授权、有目的、有留痕。

4. 域名、DNS 与证书#

域名方向是安全研究里最常见、也最工程化的一类 OSINT。

从一个域名出发，可以扩展到：

子域名
DNS 解析记录
历史解析
WHOIS 与注册商信息
证书透明度日志
CDN 与云服务供应商
开放端口和服务指纹
关联域名、跳转链、同备案主体或同组织资产

这类信息常用于企业资产盘点、供应链风险分析、钓鱼域名识别、攻防演练前期授权范围确认。它的技术含量不一定最高，但最容易影响真实安全结果，因为很多风险并不在主站，而在没人记得的测试域名、旧后台、临时对象存储桶和历史服务上。

5. IP、网络与基础设施#

IP 相关工具通常用于判断一个地址属于谁、暴露了什么服务、是否出现在威胁情报记录里、是否被滥用为垃圾邮件或恶意流量节点。

这里要特别注意：公开查询和未授权扫描不是一回事。查公开数据库、威胁情报、历史记录属于典型 OSINT；主动对目标发起大规模探测、爆破、绕过访问控制，就已经越过了公开情报的边界。

6. 图片、视频与地理位置#

图片和视频 OSINT 是最容易被低估的一类。公开图片里可能有 EXIF 元数据、拍摄时间、地标、车牌、路牌、天气、影子方向、建筑风格、语言文字、店铺招牌等线索。

它适合新闻核验、反诈骗、地理定位、品牌侵权识别、灾害现场信息验证等场景。真正专业的做法不是“看起来像哪里”，而是把多个公开证据放在一起：地图街景、建筑轮廓、历史天气、太阳方位、上传时间、原始出处、二次传播链。

7. 文件、代码与元数据#

公开文档和代码仓库经常泄露不该暴露的信息，比如内部路径、用户名、邮箱、API 地址、测试域名、版本号、调试日志、访问密钥、对象存储链接。

对企业安全来说，这类 OSINT 的价值非常高。因为它不需要触碰目标系统，只要检查公开仓库、公开附件、公开文档，就可能发现真实的资产暴露和流程缺陷。

但同样要注意：发现疑似密钥或敏感数据时，正确动作是停止扩散、保存必要证据、按负责任披露流程联系所有者，而不是尝试使用它。

为什么说它适合安全团队#

对安全团队来说，OSINT Explorer 最有价值的场景不是“查别人”，而是查自己。

企业最应该定期做的 OSINT 自查包括：

公司域名和子域名是否完整纳管
历史测试环境是否仍然暴露
GitHub、GitLab、Gitee 等平台是否有敏感信息
员工邮箱是否出现在公开泄露数据中
招聘 JD 是否暴露内部技术栈和安全边界
帮助文档、状态页、API 文档是否泄露内部路径
证书透明度日志里是否出现未知域名
品牌、商标、客服账号是否被仿冒
云对象存储、CDN、旧后台是否可被公开索引

这些工作不一定需要高深漏洞利用能力，但非常考验耐心和方法。OSINT Explorer 的价值，是让安全团队少花时间找入口，多花时间做判断。

为什么说它也适合普通开发者#

普通开发者使用 OSINT 工具，最现实的收益是“减少自己的公开暴露面”。

你可以从几个问题开始：

我的常用邮箱是否出现在公开泄露事件里？
我的 Git 提交邮箱是否暴露了私人邮箱？
我的旧博客、旧域名、旧项目是否还挂着敏感信息？
我的简历、作品集、文档里是否暴露了不必要的内部系统地址？
我的域名 DNS、证书、对象存储配置是否留下历史痕迹？

很多人以为隐私泄露来自黑客入侵，但现实里，大量暴露来自“我以前自己发出去过，只是忘了”。OSINT 自查的意义，就是把这些散落在公开互联网里的碎片重新捡回来。

合规边界：会用工具不等于可以乱用工具#

OSINT 最容易被误解的一点，是“公开可见”不等于“可以任意使用”。

公开来源情报仍然要遵守法律、平台条款、隐私边界和职业伦理。尤其是涉及个人身份、手机号、家庭住址、行踪轨迹、社交关系、未成年人信息、医疗金融信息时，更要谨慎。

我建议给自己设几条硬规则：

不做未经授权的个人跟踪和骚扰
不把手机号、住址、身份证明等敏感标识用于公开传播
不绕过登录、权限、付费墙或访问控制
不使用泄露凭据登录任何系统
不把单一工具结果当成确定事实
不采集与目标无关的个人信息
不保存超出任务所需的敏感数据
不在没有公共利益或授权的情况下发布个人画像

对团队来说，还应该把 OSINT 纳入制度：明确授权范围、数据保留时间、证据记录方式、报告脱敏规则和披露流程。

结果可信度怎么判断#

OSINT 工具给出的结果，天然存在误差。公开数据库可能过期，搜索引擎可能缓存旧页面，社交平台可能存在同名账号，域名记录可能经过隐私保护，泄露数据可能被污染或伪造。

一个结果能不能用，至少要看四个维度：

维度	要问的问题
来源	数据来自官方、平台、第三方聚合，还是未知来源
时间	信息是什么时候产生、抓取、更新的
关联	是否有其他独立来源能够支持同一结论
解释	是否存在更普通、更无害的解释

这就是为什么 OSINT 报告里最好写置信度。比如“高置信度关联”“中等置信度疑似关联”“低置信度线索待验证”，比一句“查到了就是他”专业得多，也安全得多。

和传统搜索引擎的区别#

很多人会问：既然都是公开信息，为什么不用 Google、Bing、百度直接搜？

搜索引擎当然重要，但它只解决了一部分问题。OSINT 工具导航解决的是“垂直数据源”和“专用查询方法”。

搜索引擎擅长全文索引，但不一定擅长：

查历史 DNS
查证书透明度
查泄露事件聚合
查社交平台用户名占用
查代码提交历史
查图片元数据
查恶意 IP 信誉
查区块链地址流转
查地图与地理线索

所以正确姿势不是二选一，而是组合使用：搜索引擎做广域发现，专用 OSINT 工具做垂直验证。

我会怎么使用 OSINT Explorer#

如果是我自己用，我不会上来就挨个点工具，而是先把任务拆成实体。

比如做企业外部暴露面自查，我会按这个顺序走：

先列出根域名、品牌名、公司名、常见缩写。
用域名、DNS、证书、历史解析类工具扩展资产。
用搜索引擎和代码平台工具查公开泄露线索。
用威胁情报工具看 IP、域名、样本、钓鱼记录。
用社交媒体和品牌监测工具检查仿冒账号。
把所有发现按“可验证风险”和“待确认线索”分开。
对每个风险记录来源、时间、截图、影响和修复建议。

如果是个人隐私自查，我会反过来收缩范围：

只查自己的邮箱、用户名、域名、公开主页。
不扩大到无关联系人和社交关系。
重点清理旧账号、旧项目、旧域名、公开仓库。
对无法删除的公开信息，至少降低关联性和可检索性。

这两种工作流的区别很重要：企业安全更关注资产和风险闭环，个人自查更关注最小化暴露。

它的局限性#

OSINT Explorer 这种导航站很有用，但它不是魔法。

它不能替你判断工具结果是否真实，也不能保证每个第三方工具都安全、稳定、合法、隐私友好。你点开的每个外部工具，都可能有自己的日志策略、查询限制、商业模型和合规风险。

使用时要特别注意：

不要把敏感目标随便丢进陌生网站查询
不要默认免费工具没有数据收集
不要在没有隔离环境时上传敏感文件
不要把导航站收录等同于官方背书
不要依赖单一工具做最终结论

换句话说，OSINT Explorer 是地图，不是目的地；是入口，不是证据本身。

总结#

OSINT Explorer / OSINT Brasil 最值得关注的地方，是它把 1300+ 个 OSINT 工具整理成了一个免费、可搜索、可持续更新的入口。对于安全研究、新闻核验、企业资产盘点、品牌保护和个人隐私自查来说，这类导航能明显降低工具发现成本。

但 OSINT 的专业性不在于你会点多少工具，而在于你能不能守住边界、记录来源、交叉验证、标注置信度，并把公开信息整理成负责任的结论。

如果你只把它当成“人肉搜索工具箱”，那就完全走偏了。真正有价值的 OSINT，是用公开信息降低不确定性，而不是制造伤害。

参考链接：

OSINT Explorer / OSINT Brasil: https://osint.juanmathewsrebellosantos.com/
Awesome OSINT: https://github.com/jivoi/awesome-osint

我自己收集的 PPT 设计技巧资源：从杂志风到 Open Design

Mon, 08 Jun 2026 00:00:00 GMT

最近我一直在收集一类很有意思的资源：它们不是传统意义上的 PPT 模板，也不是单纯的配色参考，而是给 AI Agent 使用的 PPT 设计 Skill / 设计工作流 / 开源设计系统。

这类资源的价值在于，它们把“审美规则”写成了可复用的工程资产。以前做 PPT，很多时间会消耗在反复试字号、调间距、找版式、做封面、补动效上；现在这些经验可以被整理成 SKILL.md、设计规范、检查清单、导出流程和可执行的 Agent 指令，让 Claude Code、Codex、Cursor 这类工具按照稳定的视觉语言产出简报。

这篇文章整理 4 个我认为值得收藏的项目：

guizang-ppt-skill：杂志风格 PPT 设计 Skill
huashu-design：带设计动画、原型和评审能力的 HTML 原生设计 Skill
Awesome-PPT-Design-Skills：7 种不同风格的 PPT Design Skills
open-design：复刻 Claude Design 思路的本地优先开源替代品

注：本文记录的是 2026-06-08 查询到的公开信息。GitHub Stars、内置 Skill 数量、设计系统数量这类数据会持续变化，建议以仓库 README 和 Release 页为准。

为什么这类资源值得单独收藏#

传统 PPT 模板解决的是“页面长什么样”的问题，但 AI Agent 时代真正缺的不是模板，而是 可执行的设计判断。

一个可用的 PPT 设计 Skill，通常不只是给几张示例图，它会把下面这些内容固化下来：

适用场景：演讲、产品发布、研究报告、品牌提案、技术分享、社媒封面
视觉系统：字体、字号层级、主色、辅助色、留白、网格、边框、图片比例
版式模块：封面、章节页、数据页、对比页、流程页、结尾页、索引页
生成流程：从资料理解、内容重组、页面规划、视觉落地到导出文件
QA 清单：检查对齐、字号、信息密度、图片裁切、色彩一致性和可读性
交付格式：HTML、SVG、PPTX、PDF、MP4、GIF 或社媒封面图

也就是说，它们不是“素材包”，而更像一套可被 Agent 调用的设计方法论。

flowchart LR A["原始内容"] --> B["Agent 理解与重组"] B --> C["选择设计 Skill"] C --> D["生成版式与视觉系统"] D --> E["视觉 QA 与人工调整"] E --> F["导出 PPTX / HTML / PDF / MP4"]

如果你经常要做技术分享、产品路演、课程材料、公众号封面、内部汇报，这类资源非常值得放进自己的工具箱。

资源总览#

项目	核心定位	更适合的场景	许可证 / 状态
guizang-ppt-skill	杂志风、瑞士风网页 PPT Skill	观点分享、方法论、产品分析、个人风格表达	AGPL-3.0，GitHub 高活跃
huashu-design	HTML 原生设计 Skill，支持 PPT、原型、动画和评审	产品发布动画、交互原型、高保真简报、设计评审	MIT，支持商用
Awesome-PPT-Design-Skills	多风格 PPT Skill 集合	同一内容切换不同视觉气质	多 Skill 集合，适合学习拆解
open-design	本地优先的开源设计工作台	多 Agent、多设计系统、多格式导出	Apache-2.0，桌面应用方向

下面逐个拆开看。

1. guizang-ppt-skill：杂志风 PPT 的工程化表达#

仓库地址：https://github.com/op7418/guizang-ppt-skill

guizang-ppt-skill 是一个适配 Claude Code / Codex 等 Agent 环境的网页 PPT Skill，主要用于生成单文件 HTML 横向翻页 PPT、PPT 配图和多平台封面。

它最吸引人的地方，是把“杂志感”和“演讲型 PPT”结合得比较好。很多 AI 生成的简报容易出现两个极端：要么像普通办公模板，信息规整但没有气质；要么像海报堆叠，视觉很花但不适合讲述。guizang-ppt-skill 的优势在于，它更强调叙事、版面节奏和展示场景。

根据 README，项目内置两套视觉系统：

Style A：电子杂志 × 电子墨水
适合叙事、观点表达、个人分享、公众号风格内容、专题型演讲。
Style B：瑞士国际主义
强调网格、直角、发丝线、高饱和锚点色和强字号对比，适合产品分析、事实表达、方法论、商业汇报。

这两个方向很实用：一个负责“好看且有故事感”，一个负责“冷静、专业、结构强”。

它适合做什么#

我会把它放在下面这些场景里：

把一篇长文改成 6-10 页演讲 PPT
做一份有个人表达感的分享材料
给技术文章、产品分析、行业观察做封面
为公众号、小红书、视频号生成不同尺寸的封面图
把产品截图或系统图重新设计成更适合展示的页面

它不太像传统 PPT 模板，而更像一个“讲稿到演示文稿”的转换器。你给它内容，它会尝试帮你建立节奏：封面先立主题，中间做观点递进，关键页用大字号或图文混排强化记忆点，最后用收束页完成表达。

适合直接使用的 Prompt#

1
请使用 guizang-ppt-skill，把这篇文章整理成一份 8 页左右的杂志风演讲 PPT。
2
要求：
3
1. 封面有强标题和副标题
4
2. 每页只讲一个核心观点
5
3. 保留关键数据，但不要堆满文字
6
4. 需要 2-3 张适合 PPT 的配图
7
5. 最后输出可预览的 HTML Deck

如果是更偏商业、产品、技术复盘的内容，可以这样写：

1
请使用 guizang-ppt-skill 的瑞士风视觉系统，把这份产品分析整理成 7 页 PPT。
2
风格要求：白底、强网格、少装饰、信息密度适中，重点页用大号数字和对比模块。

我的评价#

guizang-ppt-skill 的核心价值，不是“它能生成 PPT”，而是它已经把一套审美稳定、场景清晰的网页 PPT 方法沉淀下来了。对于经常做内容表达的人来说，它特别适合作为一个默认起点：先用它把结构和版式跑出来，再人工精修关键页。

2. huashu-design：从 PPT 扩展到动画、原型和设计评审#

仓库地址：https://github.com/alchaincyf/huashu-design

huashu-design 的定位更宽。它不是只做 PPT，而是一个 HTML 原生的设计 Skill，目标是让 Agent 通过一句话生成高保真原型、幻灯片、产品发布动画、信息图，并支持 MP4 / GIF 这类媒体导出。

它的 README 里有一句很直接的表达：在你的 Agent 里打一句话，拿回一份能交付的设计。这个方向和传统“PPT 模板”已经不是一个层级了，它更接近“把设计流程交给 Agent 编排”。

它的几个关键词#

HTML-native：以 HTML / CSS / JS 作为主要设计载体，而不是先套 PPT 模板
Agent-agnostic：不绑定单一 Agent，README 明确提到可用于 Claude Code、Cursor、Codex、OpenClaw、Hermes 等环境
设计哲学库：仓库描述提到 20 设计哲学，用来指导不同气质的输出
5 维评审：可以对设计结果进行结构化评审，而不只是生成页面
动画与导出：支持产品发布动画、MP4、GIF 等更接近传播物料的产出
MIT License：README 标注 2026-05-14 起改为 MIT 协议，个人和商用都免费

它适合做什么#

如果说 guizang-ppt-skill 更像“把内容做成好看的演讲 PPT”，那 huashu-design 更像“把一个想法做成完整视觉交付物”。

它适合：

产品发布动画
可点击 App / Web 原型
高保真产品演示页
可编辑 PPT
信息图
设计方案评审
品牌资产输入后的风格化输出

尤其是做“产品发布”或“功能演示”时，它比普通 PPT Skill 更有优势。因为发布材料通常不只是几页静态幻灯片，还会需要动效、节奏、展示画面、社媒传播物料，甚至视频导出。

适合直接使用的 Prompt#

1
请使用 huashu-design，基于下面这段产品说明做一份 60 秒产品发布动画。
2
要求：
3
1. 先给我 3 个视觉方向
4
2. 选择最适合 SaaS 工具发布的方向
5
3. 输出 HTML 动画预览
6
4. 最后导出 MP4 和 GIF

做 PPT 可以这样：

1
请使用 huashu-design，把这份技术方案做成一套能交付的演示 PPT。
2
要求：
3
1. 先做信息架构重组
4
2. 给出 3 个风格方向
5
3. 采用克制、专业、适合企业汇报的视觉语言
6
4. 完成后做一次 5 维设计评审，并根据评审结果修一轮

我的评价#

huashu-design 更适合有“交付物意识”的场景。它不是只问“这页好不好看”，而是把一个设计需求拆成方向选择、视觉落地、动画表达、导出和评审。对个人创作者来说，它可以降低动效和高保真原型的门槛；对团队来说，它更像一个可复用的轻量设计流水线。

3. Awesome-PPT-Design-Skills：7 种风格的 PPT Skill 集合#

仓库地址：https://github.com/software-ai-life/Awesome-PPT-Design-Skills

Awesome-PPT-Design-Skills 是一个 PPT Design Skills 集合。它的价值不在于某一种风格特别强，而在于它把多种视觉气质拆成了独立 Skill，适合学习“风格如何被工程化”。

README 里列出的风格包括：

japanese-style-ppt-skill：日本生活方式编辑风 / 和纸柔光风
soft-3d-clay-ppt-skill：柔和 3D / Claymorphism 风格
futuristic-tech-editorial-ppt-skill：未来科技编辑风
minimalist-luxury-branding-ppt-skill：极简奢华品牌风
modern-illustration-editorial-ppt-skill：现代插画编辑风
japanese-hand-drawn-editorial-ppt-skill：日式手绘编辑风

README 标题里写的是 7 种不同风格，因为 japanese-style-ppt-skill 内部又包含两个 house style：Washi Paper & Soft Glow 和 Japanese Lifestyle Editorial。

这类集合最值得学什么#

我认为这个仓库最适合当“拆解教材”。

你可以观察每个 Skill 如何定义：

这个风格适合什么内容
背景色、主色、辅助色如何选
字号和层级如何约束
图片用写实、插画、3D 还是纯图表
图表是强调数据，还是强调故事
页面留白和信息密度如何控制
如何避免 Agent 生成“看起来像 AI 模板”的页面

举个例子：

做 AI、工程、平台、数据主题，可以优先试 futuristic-tech-editorial-ppt-skill
做品牌提案、公司简介、创始人路演，可以试 minimalist-luxury-branding-ppt-skill
做生活方式、消费品牌、人文内容，可以试 japanese-style-ppt-skill
做轻产品介绍、教育内容、友好型功能说明，可以试 soft-3d-clay-ppt-skill

适合直接使用的 Prompt#

1
请从 Awesome-PPT-Design-Skills 里选择一个最适合这份内容的 PPT Skill。
2
内容主题是：AI 产品商业化复盘。
3
要求：
4
1. 先说明为什么选择该风格
5
2. 输出 6 页 PPT 的页面规划
6
3. 每页给出标题、核心信息、视觉处理方式
7
4. 再开始生成 PPT

如果你想学习不同风格的差异，也可以让 Agent 做风格对照：

1
请分别用 futuristic-tech-editorial-ppt-skill 和 minimalist-luxury-branding-ppt-skill，
2
为同一段内容各生成一页封面，并解释两种风格在配色、排版、信息密度上的差异。

我的评价#

这个仓库非常适合作为“风格库”。当你不确定一份内容应该用什么视觉语言时，可以先用它做风格探索。它也适合给自己的 Skill 写法打样：如果以后想沉淀公司内部的 PPT 设计规范，可以参考它如何把风格拆成可执行规则。

4. open-design：本地优先的开源 Claude Design 替代品#

仓库地址：https://github.com/nexu-io/open-design

open-design 的野心更大。它不是一个单独的 PPT Skill，而是一个本地优先、开源的设计工作台，定位是 Claude Design 的开源替代品。

根据仓库 README，它是一个桌面应用，支持 macOS 和 Windows，强调：

local-first，本地优先
open-source，开源
可接入 Claude Code、Codex、Cursor、OpenCode、Qwen、Copilot、Kimi 等多种 Agent / CLI
支持 Web、桌面、移动原型、slides、images、videos 等多种产物
支持 HTML / PDF / PPTX / MP4 导出
提供沙箱 iframe 预览
通过 Skills、Design Systems、Plugins 组织设计能力

用户最初给到的信息里提到它有 19 项技能、71 个品牌级设计系统、4k+ Stars；我在 2026-06-08 查询 GitHub API 和 README 时，看到的数据已经显著增长：仓库描述中写到了 259+ Skills、142+ Design Systems，README 里则出现 100+ skills、150 brand-grade design systems、261 plugins 等表述，Stars 也已经远超 4k。这个增长速度说明它处在非常活跃的阶段。

它和前面三个项目有什么不同#

前面三个更像“Skill 资源”，而 open-design 更像一个“设计操作系统”。

可以这样理解：

flowchart TB A["PPT Skill"] --> B["单一风格或单一工作流"] C["Skill 集合"] --> D["多种 PPT 风格选择"] E["Open Design"] --> F["桌面应用 + Skills + Design Systems + Plugins"] F --> G["HTML / PDF / PPTX / MP4 导出"] F --> H["多 Agent / 多模型接入"] F --> I["原型 / 简报 / 图片 / 视频"]

如果你只是偶尔做一份好看的 PPT，前面几个仓库已经够用。如果你想把 Agent 设计变成长期工作台，比如沉淀品牌规范、反复生成原型、管理不同设计系统、对接多个 Agent，那 open-design 更值得重点研究。

它适合谁#

我觉得它适合三类人：

个人创作者：想用本地工具完成封面、海报、PPT、视频和网页原型
产品 / 运营团队：需要快速把需求、活动、发布信息变成可展示物料
技术团队：希望把设计系统、导出流程、Agent 能力放进可控的本地环境

尤其是“本地优先”这个点很重要。很多团队对设计资产、品牌规范、产品原型、内部文档都有隐私和权限要求，把设计工作流放在本地或可控环境里，比完全依赖云端服务更容易治理。

我的评价#

open-design 代表的是另一个方向：把设计能力从单个提示词，升级成可安装、可扩展、可导出、可接入多 Agent 的本地工作台。它不只是为了做 PPT，而是想把 Agent 时代的“设计生产链路”重新组织起来。

怎么选择：一张速查表#

你的需求	推荐优先级
把文章快速做成有风格的演讲 PPT	guizang-ppt-skill
想做杂志风、瑞士风、公众号封面	guizang-ppt-skill
想做产品发布动画、可点击原型、MP4 / GIF	huashu-design
想让 Agent 先给视觉方向，再做设计评审	huashu-design
想尝试多种 PPT 风格	Awesome-PPT-Design-Skills
想学习 PPT Skill 的写法	Awesome-PPT-Design-Skills
想搭一个长期使用的本地设计工作台	open-design
想管理 Skills、Design Systems、Plugins	open-design

我的建议是：

新手先用 guizang-ppt-skill，因为它最容易看到 PPT 效果
想做更复杂视觉交付，再试 huashu-design
想学习风格化 Prompt 和 Skill 写法，看 Awesome-PPT-Design-Skills
想把整套设计生产链路搬到本地，再研究 open-design

一套更实用的组合工作流#

如果不是单独体验，而是真要把这些资源用起来，我会这样组合：

flowchart LR A["内容资料"] --> B["整理成 Markdown 大纲"] B --> C["选择 PPT Skill"] C --> D["生成 6-10 页初稿"] D --> E["用 huashu-design 做视觉评审"] E --> F["补封面 / 动画 / 社媒图"] F --> G["导出 PPTX / HTML / PDF"] G --> H["沉淀为自己的 Skill 或设计规范"]

具体步骤：

先把内容整理成 Markdown
不要一上来就让 Agent 做 PPT。先让它帮你提炼主题、受众、核心观点、页面数量和讲述顺序。
选一个主风格
观点分享选杂志风，技术分析选瑞士风或未来科技风，品牌提案选极简奢华风，生活方式内容选日式编辑风。
生成初稿后做 QA
检查是否每页只有一个重点，图文是否抢信息，字号是否过小，页面是否存在“堆字”问题。
再补传播物料
一份 PPT 经常还需要公众号头图、社媒封面、活动海报、短视频封面，这时可以用 guizang-ppt-skill 或 huashu-design 扩展。
最后沉淀自己的规则
如果你总是做同一类内容，比如技术教程、项目复盘、产品发布，就应该把常用版式、色彩、页面结构沉淀成自己的 Skill。

如何写一个更容易出好 PPT 的需求#

不要只写：

1
帮我做一份高级 PPT。

这种提示词太空，Agent 很容易生成一份“看起来努力了，但哪里都不准”的东西。

更好的写法是：

1
请把下面这份内容整理成 8 页 PPT，用于 20 分钟技术分享。
2
受众是有开发经验但不了解该项目的人。
3
风格：克制、清晰、有技术质感，不要营销风。
4
每页要求：
5
1. 一个主标题
6
2. 一个核心观点
7
3. 最多 3 个要点
8
4. 需要图表时优先用结构图、流程图或对比表
9
5. 不要使用大段正文
10
最后请先输出页面大纲，确认逻辑后再生成。

如果你已经选定了 Skill，可以继续补充：

1
请使用 guizang-ppt-skill 的瑞士风视觉系统。
2
页面比例 16:10。
3
希望整体像专业技术大会的分享，而不是公司年会模板。

这类工具的局限#

虽然这些资源很强，但不要把它们理解成“自动变设计大佬”。

它们依然有几个限制：

内容质量决定上限。原始材料混乱，生成结果也会混乱
Agent 容易过度装饰，需要明确限制信息密度和视觉风格
PPTX 导出后的可编辑性、字体兼容、动画还原度需要实际检查
复杂图表、数据关系、品牌规范仍然需要人工判断
对正式商业交付，最好保留一轮人工设计 QA

我更愿意把它们看成“设计能力放大器”。你越清楚受众、内容重点和视觉目标，它们越能帮你节省时间；你越依赖一句模糊指令，它们越容易跑偏。

结语#

这 4 个项目放在一起看，其实能看到一个很明显的趋势：PPT 设计正在从“模板选择”变成“Agent 可执行的设计系统”。

guizang-ppt-skill 解决的是风格稳定的网页 PPT；huashu-design 把范围扩展到动画、原型和设计评审；Awesome-PPT-Design-Skills 提供了多种可学习、可拆解的风格样本；open-design 则试图把这些能力收束到一个本地优先的开源设计工作台里。

如果你经常做分享、写教程、做产品发布、整理项目复盘，建议把这几个仓库都收藏起来。它们不是简单的“PPT 美化工具”，而是 AI Agent 时代非常值得研究的设计基础设施。

参考链接#

Codex App 安装指南：绕过 Microsoft Store 下载链路限制

Mon, 08 Jun 2026 00:00:00 GMT

有时候你只是想在 Windows 或 Mac 上装一个 Codex App，但最麻烦的地方不是软件本身，而是下载链路。

在 Windows 上，官方分发通常会绕不开 Microsoft Store / App Installer / AppX 这套体系。问题是很多机器并不一定具备一个“完整可用的商店环境”：

Microsoft Store 被精简、裁剪或卸载
AppX / MSIX 相关服务被关闭
组织账号、学校账号或公司策略限制了商店下载
winget download 遇到 Store 包认证限制，不能在无人值守环境里稳定运行
国内网络访问 Microsoft Store 或 GitHub Release 时速度不稳定

这时可以看看这个项目：codex-app-mirror。

它的目标很明确：镜像官方 Codex 桌面安装包，并按版本整理发布到 GitHub Release。

更重要的是，它不是破解工具，也不是重打包工具。根据仓库 README，codex-app-mirror 不构建、不修改、不重打包 Codex，只是从官方上游来源拉取当前安装包，然后把 Windows MSIX、macOS DMG、校验和、release manifest 一起发布出来，方便用户直接下载。

一句话理解 codex-app-mirror#

你可以把它理解成一个“Codex App 官方安装包的版本镜像索引”。

flowchart LR A["官方上游来源"] --> B["自动探测版本变化"] B --> C["下载官方安装包"] C --> D["生成 SHA256 校验和"] D --> E["发布到 GitHub Release"] E --> F["用户下载 Windows MSIX / macOS DMG"]

它解决的是“下载入口不好用”的问题，不解决“你的系统是否允许安装”的问题。

这点要先说清楚：如果你的 Windows 设备策略明确禁止安装 MSIX / AppX，或者公司安全策略禁止安装未审批软件，这个镜像不会也不应该帮你绕过这些策略。它只是让你在 Microsoft Store 下载链路不顺的时候，可以拿到对应平台的官方安装包文件。

下载入口#

最新版本可以从两个渠道下载。

1. GitHub Release#

官方 GitHub Release：

https://github.com/Wangnov/codex-app-mirror/releases/latest

进入 Release 页面后，按平台选择资产：

平台	下载文件
Windows x64	`OpenAI.Codex_..._x64__2p2nqsd0c76g0.Msix`
Apple Silicon Mac	`Codex-mac-arm64.dmg`
Intel Mac	`Codex-mac-x64.dmg`
校验和	`SHA256SUMS.txt`
上游指纹	`release-manifest.json`

截至 2026-06-08，我查询到的最新 Release 是：

字段	信息
Release 名称	`Codex App Mirror 26.602`
Release Tag	`codex-app-force-20260606-165817`
发布时间	`2026-06-06 17:01:18 UTC`
Windows 资产	`OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0.Msix`
macOS Apple Silicon	`Codex-mac-arm64.dmg`
macOS Intel	`Codex-mac-x64.dmg`

版本会继续更新，实际下载时以 Release 页面显示为准。

2. 国内 R2 镜像#

如果你在国内网络环境下访问 GitHub Release 比较慢，可以使用 R2 短链接。

平台	链接
Windows	https://codexapp.agentsmirror.com/latest/win
Apple Silicon Mac	https://codexapp.agentsmirror.com/latest/mac-arm64
Intel Mac	https://codexapp.agentsmirror.com/latest/mac-intel
校验和	https://codexapp.agentsmirror.com/latest/checksums

R2 镜像只保留最新版本。如果你要找旧版本，请去 GitHub Releases 里按 release/tag 找历史资产。

Windows 安装方式#

Windows 用户下载的是 .Msix 文件。

下载完成后，最简单的方式是双击安装。如果系统里的 App Installer 正常，通常会弹出安装界面，确认后即可安装。

如果双击没有反应，可以尝试用 PowerShell 安装：

Terminal window

1
Add-AppxPackage -Path "D:\Downloads\OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0.Msix"

把路径替换成你实际下载的位置。

如果你习惯先切到下载目录：

Terminal window

1
cd "$env:USERPROFILE\Downloads"
2
Add-AppxPackage -Path ".\OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0.Msix"

安装完成后，可以在开始菜单里搜索 Codex。

Windows 常见问题#

1. 提示无法安装 MSIX#

这通常不是镜像问题，而是本机的 AppX / MSIX 安装环境有问题。可以检查：

App Installer 是否存在
AppXSVC 服务是否可用
系统策略是否禁止安装 MSIX
当前 Windows 版本是否过旧
公司或学校设备是否启用了软件安装限制

如果设备由组织管理，建议先确认内部 IT 策略。不要把这个镜像当成规避组织安全策略的工具。

2. 双击 MSIX 没反应#

可以改用 PowerShell 的 Add-AppxPackage。如果 PowerShell 也报错，优先看报错信息里的 Deployment failed、policy、dependency、certificate 等关键字。

3. 安装后启动失败#

先确认下载文件是否完整，再检查 Windows 事件查看器或应用日志。下载损坏、版本不匹配、系统依赖缺失，都可能导致启动异常。

macOS 安装方式#

macOS 用户下载的是 .dmg 文件。

不同芯片选择不同版本：

Mac 类型	下载文件
Apple Silicon，M1 / M2 / M3 / M4	`Codex-mac-arm64.dmg`
Intel Mac	`Codex-mac-x64.dmg`

如果你不确定自己的 Mac 是什么芯片，可以点左上角苹果菜单，进入“关于本机”查看芯片信息。

安装步骤：

下载对应的 .dmg
双击打开
将 Codex.app 拖到 Applications / “应用程序”目录
从 Launchpad 或应用程序目录启动 Codex

如果 macOS 提示应用来自互联网，属于常见的 Gatekeeper 提醒。你可以在“系统设置 - 隐私与安全性”里确认是否允许打开。

如果你使用的是 Apple Silicon Mac，却下载了 Intel 版本，通常也可能通过 Rosetta 运行，但不建议这样做。优先使用 arm64 版本。

一定要做校验#

第三方镜像最重要的不是“能不能下”，而是“下到的文件是不是你以为的那个文件”。

codex-app-mirror 每个 Release 都会提供 SHA256SUMS.txt。建议你下载安装包后，同时下载校验和文件，对照 SHA256。

Windows 校验#

PowerShell 里运行：

Terminal window

1
Get-FileHash -Algorithm SHA256 "D:\Downloads\OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0.Msix"

把输出的 Hash 和 SHA256SUMS.txt 里的对应值对上。

也可以直接在下载目录里：

Terminal window

1
cd "$env:USERPROFILE\Downloads"
2
Get-FileHash -Algorithm SHA256 ".\OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0.Msix"

macOS 校验#

终端里运行：

Terminal window

1
shasum -a 256 ~/Downloads/Codex-mac-arm64.dmg

Intel 版本则换成：

Terminal window

1
shasum -a 256 ~/Downloads/Codex-mac-x64.dmg

把输出值和 SHA256SUMS.txt 对上。

为什么校验很重要#

因为这里的下载链路可能经过浏览器、代理、镜像、断点续传、网络缓存等多个环节。SHA256 校验至少可以确认：

文件没有在下载过程中损坏
文件和 Release 中记录的哈希一致
你下载的不是一个被替换过的同名文件

校验不是万能安全保证，但它是使用镜像安装包时应该做的最低限度检查。

release-manifest.json 是做什么的#

除了 SHA256SUMS.txt，Release 里还有 release-manifest.json。

它记录的是本次探测到的上游指纹，比如版本、文件大小、ETag、Last-Modified 等信息。这个文件对普通用户不是必看项，但对想确认镜像来源、自动化下载、监控版本变化的人很有用。

你可以把它理解成“这次 Release 为什么被发布”的元数据说明。

版本号为什么 Windows 和 macOS 不一致#

README 里特别说明了一点：Windows 和 macOS 的版本号来自不同上游包，不保证完全一致。

Windows MSIX 的版本来自 Microsoft Store 包名里的四段版本，例如：

1
26.602.4764.0

macOS 的版本来自 DMG 内部 Codex.app/Contents/Info.plist，主要看：

1
CFBundleShortVersionString
2
CFBundleVersion

所以你可能会看到 Release 名称、Windows 包名、macOS build 之间并不是完全同一种格式。这不一定代表版本错了，而是上游平台的版本体系不同。

codex-app-mirror 是怎么更新的#

根据 README，项目通过 GitHub Actions 自动轮询。

它的更新逻辑大致是：

每 15 分钟运行一次 Mirror Codex App Installers workflow
Windows 侧通过 Microsoft Store DisplayCatalog 查询 ProductId 9PLM9XGG6VKS
再通过 FE3 metadata 解析当前 Windows Desktop x64 对应的 MSIX 包信息
macOS 侧对 OpenAI 官方 DMG 地址做 HEAD 请求
读取 ETag、Last-Modified、Content-Length 等稳定字段
和最新 Release 的 release-manifest.json 比较
如果没有变化，就不下载、不重复发布
如果任意平台发生变化，就下载三端安装包，生成校验和与 manifest，然后发布新的 GitHub Release

这套机制的好处是：它不是手工搬运，也不是随缘更新，而是通过上游指纹变化来决定是否发布新版本。

sequenceDiagram participant G as GitHub Actions participant M as Microsoft Store Metadata participant O as OpenAI DMG URL participant R as GitHub Release G->>M: 探测 Windows MSIX 信息 G->>O: HEAD 探测 macOS DMG 指纹 G->>R: 读取最新 release-manifest.json alt 指纹无变化 G-->>G: 停止，不发布重复 Release else 指纹有变化 G->>M: 下载 Windows MSIX G->>O: 下载 macOS DMG G->>G: 生成 SHA256 和 manifest G->>R: 发布新 Release end

它不会做什么#

这一段很关键。

codex-app-mirror 不是“破解 Codex App”，也不是“绕过授权”的工具。它不会做下面这些事：

不修改 Codex 安装包
不破解 Microsoft Store 或 OpenAI 的授权逻辑
不重打包 Codex
不保留 Microsoft CDN 临时 URL 作为长期下载地址
不保证你的本机 Windows AppX / MSIX 策略允许安装
不替代 OpenAI、Microsoft 或 Microsoft Store 的官方分发渠道

所以它适合的场景是：你本来就可以合法使用 Codex App，只是官方下载链路不顺，想要一个更稳定、更容易下载和校验的安装包入口。

我的建议#

如果你在 Windows 上装 Codex App，我建议按这个顺序来：

优先尝试官方正常渠道
如果 Microsoft Store 不可用，再去 GitHub Release 下载 MSIX
国内网络慢时，用 R2 镜像下载最新版
下载后一定做 SHA256 校验
如果安装失败，先查 App Installer / AppX / 系统策略，而不是反复换下载源

如果你在 macOS 上安装：

先确认芯片架构
Apple Silicon 下载 Codex-mac-arm64.dmg
Intel Mac 下载 Codex-mac-x64.dmg
下载后做 SHA256 校验
拖进应用程序目录再启动

结语#

codex-app-mirror 解决的是一个很现实的问题：官方安装包存在，但正常下载链路在某些环境下不好用。

它的价值不在于“提供了另一个神秘版本”，而在于把官方 Codex App 安装包按版本整理到 GitHub Release，并配套提供 SHA256 校验和、release manifest、国内 R2 最新版短链接。这样 Windows 用户不用卡在 Microsoft Store 下载链路，macOS 用户也能直接拿到 Apple Silicon / Intel 对应的 DMG。

对我来说，这类项目最值得称赞的地方是边界清楚：只镜像、只整理、只校验，不修改、不破解、不重打包。你拿它来解决下载问题可以，但安装前的校验和合规判断，仍然应该自己认真做。

参考链接#

Fiddler Everywhere 5.17+ 非官方补丁 Release 技术解读与风险复盘

Tue, 02 Jun 2026 00:00:00 GMT

这篇文章聊一个比较敏感、但很值得技术复盘的话题：GitHub 上 Eilte/Fiddler-Everywhere-Crack 仓库发布的 5.17+ Release。

先把态度说清楚：本文不是破解教程，也不会复述补丁执行流程。原因很简单，Fiddler Everywhere 不是普通桌面软件，它是会接管系统代理、安装调试证书、查看 HTTPS 流量的网络调试工具。对这类工具动刀，不只是“改一个授权状态”那么轻，真正危险的是你把自己的网络信任边界交给了一个无法验证的第三方二进制。

所以这篇会从工程视角做一次完整拆解：

这个 Release 到底公开声明了什么
Fiddler Everywhere 为什么天然属于高信任软件
这类 patcher 可能触碰哪些系统边界
使用非官方补丁的安全、合规和工程风险
如果只是想抓包调试，有哪些更稳的路线

Release 元数据速读#

根据 GitHub Release 页面与 GitHub API 可见信息，这个 Release 的基本情况如下：

项目	信息
仓库	`Eilte/Fiddler-Everywhere-Crack`
Release 名称	`5.17+`
发布时间	2024-12-11
最后更新时间	2024-12-23
适配声明	Fiddler Everywhere 5.17 及以上
Release 资产	Windows x64 与 Linux x64 两个压缩包
Windows 资产下载量	约 5948 次
Linux 资产下载量	约 624 次
Release 文案来源声明	声称补丁来自 52pojie 论坛
额外提示	提到可使用 PowerShell 脚本禁用更新

这里最关键的不是“下载量挺高”，而是三个信号：

它不是 Progress Telerik 官方发布。
它发布的是二进制 patcher，而不是透明的源码补丁。
它还提到了禁用更新，这意味着它可能影响软件后续安全修复链路。

单看这三点，风险等级就已经不低了。

先理解 Fiddler Everywhere 的位置#

Fiddler Everywhere 的官方定位是跨平台 Web 调试代理，用来捕获、检查、修改、重放网络请求。它支持 Windows、macOS、Linux，并且能处理 HTTPS、HTTP/2、WebSocket、gRPC 等现代协议。

换成人话说，它不是“看一下网络日志”的小工具，而是一个被你主动放进网络链路中间的调试代理。

flowchart LR A["浏览器 / App / CLI"] --> B["系统代理配置"] B --> C["Fiddler Everywhere"] C --> D["证书信任链 / HTTPS 解密"] C --> E["会话存储 / 导出 / 重放"] C --> F["规则、过滤、修改响应"] C --> G["互联网服务"]

这张图里每一层都是敏感点。

系统代理：决定流量先经过谁。
证书信任链：决定谁可以解密 HTTPS。
会话存储：可能包含 Cookie、Token、接口返回、用户数据。
请求修改：可以改变前后端交互结果。
自动更新：决定软件能不能及时拿到安全修复。

如果一个非官方补丁修改了这类软件，那么你要问的就不只是“能不能用”，而是：

我是否愿意让一个未知 patcher 间接触碰我的代理、证书、流量和更新机制？

这才是问题的核心。

官方版本线索：5.17 并不是当前新版本#

官方 Release History 显示，Fiddler Everywhere v5.17.0 发布于 2024-09-12。这个版本的更新内容包括复制 Timings timeline 信息的提示、若干 gRPC / Overview 时间显示问题修复，以及更新第三方依赖以缓解安全问题。

截至 2026-06-02，官方 Release History 已经进入 7.x 系列，页面可见最新版本为 v7.7.3，发布日期是 2026-04-14。

这意味着 5.17+ 这个标签覆盖的是一段已经过去很久的版本区间。对安全软件或代理工具来说，旧版本本身就会带来额外问题：你不知道后续版本修了哪些依赖漏洞、证书处理问题、协议兼容问题或更新机制问题。

如果再叠加“禁用更新”，风险会进一步放大。

非官方 patcher 通常会动哪里#

这里不讨论这个具体补丁的执行方式，只讲这类工具在工程上常见的修改面。商业桌面软件的授权逻辑一般会分布在几个地方：

本地二进制文件
应用资源文件
授权状态缓存
登录与订阅校验逻辑
自动更新模块
运行时配置
与云端服务交互的请求逻辑

一个 patcher 如果想改变授权行为，常见思路通常离不开下面几类高层动作：

修改面	可能影响
修改可执行文件或动态库	破坏原始签名与完整性校验
修改授权判断逻辑	让应用状态偏离官方预期
修改配置文件	改变启动、更新、登录或网络行为
禁用更新组件	阻断官方安全修复
写入额外文件	增加持久化或后门风险
调整代理 / 证书相关逻辑	影响系统网络信任边界

对普通软件来说，修改二进制已经足够危险；对抓包代理来说，危险点还会继续扩大，因为它运行时本来就拥有很强的流量可见性。

真正的风险不是“破解失败”，而是信任链断裂#

很多人看这类 Release，只会关心一句话：能不能用？

但从安全工程角度，应该先问另外五个问题：

这个 patcher 的源码可审计吗？
Release 资产有可验证的哈希、签名或可复现构建吗？
它会不会改系统代理、证书存储、hosts、防火墙或启动项？
它会不会禁用更新，导致后续漏洞无法修复？
它会不会读取、导出或转发 Fiddler 捕获到的敏感会话？

这几个问题如果答不上来，就不应该在主力机器、办公机器、开发机器上运行。

尤其是第 5 点。Fiddler Everywhere 捕获到的内容，经常不是“无害日志”，而是非常实在的敏感信息：

登录态 Cookie
Bearer Token
API Key
内部接口返回
用户手机号、邮箱、订单、地址
OAuth 回调参数
企业内网请求
测试环境账号密码

抓包工具一旦被污染，后果不是“软件坏了”，而是整条调试链路都不可信了。

风险矩阵#

下面这张表可以作为判断这类补丁的通用框架。

风险类型	严重程度	触发原因	可能后果
二进制完整性风险	高	patcher 修改应用文件	官方签名失效、行为不可预测
供应链风险	高	Release 资产来源不透明	后门、植入、投毒、二次打包
网络流量风险	高	工具本身处理 HTTPS 与代理	Token、Cookie、业务数据泄露
更新链路风险	高	禁用或绕过更新	长期停留在存在漏洞的版本
合规风险	高	绕过商业授权	违反许可协议、审计不通过
稳定性风险	中	应用状态偏离官方设计	崩溃、抓包异常、证书错误
团队扩散风险	高	非官方工具被内部传播	开发环境批量污染

一句话：这不是“装不装一个工具”的问题，而是你愿不愿意把调试环境的信任根交出去。

为什么“禁用更新”是一个危险信号#

很多破解补丁都会建议禁用更新，原因并不复杂：官方更新可能覆盖被修改的文件，也可能修复或改变授权逻辑。

但从防御视角看，自动更新是软件供应链安全里非常关键的一环。它至少承担三件事：

修复第三方依赖漏洞
修复协议处理与证书逻辑问题
修复应用自身的安全缺陷

Fiddler Everywhere v5.17.0 的官方更新说明里就明确提到过更新第三方依赖以缓解安全问题。也就是说，这类软件的版本更新并不只是“加功能”，还包含安全修复。

当一个补丁建议你停掉更新时，它实际上是在说：

为了维持非官方状态，请放弃官方安全修复链路。

这对代理工具尤其不划算。

如果你是安全研究员，应该怎么分析它#

如果你只是普通开发者，不建议运行这类补丁。如果你是安全研究员，确实需要做样本分析，也应该把它当成未知二进制处理，而不是当成普通安装包。

一个相对稳妥的分析框架如下：

阶段	关注点
静态元数据	文件大小、编译时间、PE/ELF 结构、签名、哈希
静态行为	字符串、URL、注册表路径、文件路径、进程名
沙箱运行	进程树、文件写入、网络连接、DNS 查询
系统改动	代理设置、证书存储、hosts、启动项、计划任务
应用改动	被替换文件、配置变更、更新模块状态
网络侧	是否有异常出站连接、是否上传本地信息

这里有个原则：只在隔离环境里观察，不在真实工作机上验证。虚拟机快照、无敏感账号、独立网络、运行前后 diff，这些都应该是基本动作。

不要因为它来自 GitHub，就默认它可信。GitHub 是托管平台，不是安全背书。

对个人开发者的建议#

如果你的目标只是抓包调试，优先考虑这几条路线：

使用 Fiddler Everywhere 官方试用或正式授权。
如果你在 Windows 上，按官方许可选择 Fiddler Classic 等工具。
前端页面请求优先用浏览器 DevTools。
API 调试可以用 Postman、Insomnia、Bruno 等工具。
需要代理式抓包可以看 mitmproxy、HTTP Toolkit、Requestly、Charles Proxy、Wireshark 等。

这些工具能力边界不同，不存在一个绝对替代品。但只要你不把“绕授权”作为第一目标，就会发现可选方案其实不少。

对团队和公司的建议#

团队环境里，这类补丁不应该进入开发机基线，更不应该出现在共享网盘、内部 Wiki、装机脚本或 onboarding 文档里。

更稳的做法是：

明确网络调试工具白名单。
统一购买或申请合法授权。
禁止使用来源不明的 patcher、loader、keygen。
对抓包工具的证书安装和代理配置建立操作规范。
定期检查开发机代理设置、根证书列表和启动项。
对导出的 SAZ、HAR、日志文件做敏感信息处理。
在安全培训里强调“抓包工具比普通工具更敏感”。

如果公司已经有人运行过类似补丁，建议按安全事件的方式做一次轻量排查：

检查系统代理和证书存储是否异常。
检查 Fiddler 安装目录是否被非官方文件覆盖。
检查是否存在未知启动项或计划任务。
检查近期是否有异常出站连接。
轮换在该机器上出现过的关键 Token、API Key 和测试账号密码。

这听起来可能有点严肃，但对代理工具来说并不过分。

技术人的底线：能逆向，不等于该绕过#

逆向工程本身不是原罪。安全研究、兼容性分析、漏洞挖掘、恶意样本分析，都离不开逆向能力。

但绕过商业授权是另一件事。它的问题不只是法律和版权，也包括工程伦理：你把一个本该可信的软件运行链路改成了不可验证状态，又把它用于处理敏感流量。

这就是为什么我不建议把这类 Release 当成“福利工具”传播。它更适合作为一个反面案例，用来提醒我们：越接近网络、证书、身份和数据的工具，越不能随便交给未知补丁。

结论#

Fiddler-Everywhere-Crack 的 5.17+ Release，表面上是一个适配 Fiddler Everywhere 5.17 及以上版本的非官方补丁发布；从工程安全角度看，它更像是一次典型的桌面软件供应链风险样本。

它触碰的不是普通功能开关，而是代理工具的高信任运行环境。尤其是当 Release 文案同时出现二进制 patcher、第三方来源、禁用更新这些信号时，风险已经非常明确。

我的建议很简单：

不要在主力机或办公机运行。
不要把它写成可执行教程传播。
不要在团队环境里扩散。
真需要抓包，选官方授权或可信替代工具。
真要研究，也把它当未知样本隔离分析。

网络调试工具越强，越应该从可信来源安装。因为它看到的不是软件界面，而是你机器上最真实的一部分流量。

参考链接#

GitHub Release: Eilte/Fiddler-Everywhere-Crack 5.17+
Fiddler Everywhere 官方介绍: docs.telerik.com/fiddler-everywhere/introduction
Fiddler Everywhere Release History: telerik.com/support/whats-new/fiddler-everywhere/release-history
Fiddler Everywhere v5.17.0 Release Notes: telerik.com/support/whats-new/fiddler-everywhere/release-history/fiddler-everywhere-v5.17.0

qunl-api Linux 服务器 Docker 部署保姆级教程

Tue, 02 Jun 2026 00:00:00 GMT

这篇文章记录一次在全新的阿里云 Linux/CentOS 服务器上，从零部署 qunl-api 的完整流程。整体方案使用 Docker 管理基础中间件，包括 PostgreSQL 15、Redis 7 和 Nginx 反向代理，qunl-api 主程序则通过二进制文件在宿主机后台运行。

说明：本文保留原部署笔记中的密码，方便一键复制复现。正式生产环境建议在部署前改成自己的强密码，并同步更新 .env 配置。

部署目标#

完成后服务器上会运行以下服务：

PostgreSQL 15：保存 qunl-api 主数据库与日志数据库。
Redis 7：提供缓存或队列能力。
Nginx：监听服务器 80 端口，并反向代理到本机 6000 端口。
qunl-api：监听 6000 端口，通过 .env 读取数据库与 Redis 配置。

适用环境：

阿里云 Linux/CentOS 服务器。
已拥有服务器 root 权限或 sudo 权限。
已准备好 qunl-api 二进制文件。

一、安装 Docker 环境#

先在阿里云服务器终端依次执行下面的命令，安装 Docker 引擎和基础工具。

Terminal window展开收起

1
# 1. 更新系统软件包（可选，建议新服务器执行）
2
yum update -y
3

4
# 2. 安装 Docker 所需的基础系统工具
5
yum install -y yum-utils device-mapper-persistent-data lvm2
6

7
# 3. 设置阿里云官方的 Docker Yum 源（国内服务器加速）
8
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
9

10
# 4. 安装 Docker 社区版
11
yum install -y docker-ce docker-ce-cli containerd.io
12

13
# 5. 启动 Docker 服务并设置开机自启
14
systemctl start docker
15
systemctl enable docker
16

17
# 6. 验证 Docker 是否安装成功
18
docker version

展开收起

如果最后能看到 Docker 客户端和服务端版本信息，说明 Docker 已经安装成功。

二、清理旧环境并启动基础中间件#

下面这段脚本会做三件事：

停止并删除旧的 pg15、redis7、nginx-proxy 容器。
删除旧的数据挂载目录。
重新启动 PostgreSQL、Redis 和 Nginx。

如果你是全新服务器，也可以直接执行。若服务器里已有重要数据库数据，请不要直接运行这段清理脚本。

Terminal window展开收起

1
# ==========================================
2
# 1. 环境彻底清理
3
# ==========================================
4
docker stop pg15 redis7 nginx-proxy && docker rm pg15 redis7 nginx-proxy
5
rm -rf /data/postgres /data/redis /data/nginx/conf.d
6

7
# ==========================================
8
# 2. 启动全新 PostgreSQL 15（密码：BbAxy_110goodpg）
9
# ==========================================
10
docker run --name pg15 \
11
  -e POSTGRES_USER=root \
12
  -e POSTGRES_PASSWORD=BbAxy_110goodpg \
13
  -v /data/postgres:/var/lib/postgresql/data \
14
  -p 5432:5432 \
15
  -d postgres:15
16

17
# ==========================================
18
# 3. 启动全新 Redis 7（密码：BbAxy_110goodredis）
19
# ==========================================
20
docker run --name redis7 \
21
  -p 6379:6379 \
22
  -v /data/redis:/data \
23
  -d redis:7.2 \
24
  redis-server --appendonly yes --requirepass BbAxy_110goodredis
25

26
# ==========================================
27
# 4. 配置并启动 Nginx 反向代理（映射 80 端口）
28
# ==========================================
29
mkdir -p /data/nginx/conf.d
30

31
cat << 'EOF' > /data/nginx/conf.d/qunl_api.conf
32
server {
33
    listen 80;
34
    server_name localhost;
35

36
    location / {
37
        proxy_pass http://host.docker.internal:6000;
38
        proxy_set_header Host $host;
39
        proxy_set_header X-Real-IP $remote_addr;
40
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
41
        proxy_set_header X-Forwarded-Proto $scheme;
42

43
        # 支持 WebSocket 流式传输
44
        proxy_http_version 1.1;
45
        proxy_set_header Upgrade $http_upgrade;
46
        proxy_set_header Connection "upgrade";
47
    }
48
}
49
EOF
50

51
docker run --name nginx-proxy \
52
  -p 80:80 \
53
  -v /data/nginx/conf.d:/etc/nginx/conf.d:ro \
54
  --add-host=host.docker.internal:host-gateway \
55
  -d nginx:latest

展开收起

启动完成后，可以用下面的命令确认容器是否正常运行：

Terminal window

1
docker ps

正常情况下，列表中应该能看到 pg15、redis7 和 nginx-proxy 三个容器。

三、初始化数据库#

等待中间件容器启动约 5 秒后，执行下面两条命令，分别创建主数据库和日志数据库。

Terminal window

1
docker exec -it pg15 psql -U root -c "CREATE DATABASE \"qunl_api\";"
2
docker exec -it pg15 psql -U root -c "CREATE DATABASE \"qunl_api-logs\";"

这里会创建两个数据库：

qunl_api：主业务数据库。
qunl_api-logs：日志数据库。

如果重复执行并提示数据库已存在，说明之前已经创建过，可以继续后续步骤。

四、配置 qunl-api 主程序#

进入 qunl-api 二进制文件所在目录后，执行下面的命令，重写本地 .env 配置文件。

Terminal window展开收起

1
cat << 'EOF' > .env
2
# 端口号
3
PORT=3000
4
# 前端基础URL（留空则使用本机嵌入的 WEB 页面；设为其他域名则访问本机时会被重定向到该地址，易导致白屏）
5
# FRONTEND_BASE_URL=
6
FRONTEND_BASE_URL=
7
REGISTER_DEFAULT_GROUP=default
8
# 调试相关配置
9
# 启用pprof
10
# ENABLE_PPROF=true
11
# 启用调试模式
12
DEBUG=true
13

14
# 数据库相关配置
15
SQL_DSN=postgres://root:BbAxy_110goodpg@127.0.0.1:5432/qunl_api?sslmode=disable
16
LOG_SQL_DSN=postgres://root:BbAxy_110goodpg@127.0.0.1:5432/qunl_api-logs?sslmode=disable
17
REDIS_CONN_STRING=redis://:BbAxy_110goodredis@127.0.0.1:6379/0
18
LOG_REQUEST_RESPONSE_ENABLED=true
19

20

21

22
# PostgreSQL 格式：postgresql://user:password@host:port/dbname（密码含 @ 等需 URL 编码，如 @ → %40）
23
# MySQL 格式：user:password@tcp(host:port)/dbname?parseTime=true
24
#SQL_DSN=postgresql://root:new_API%402025@data.qunl.com:14421/new-api
25
# 日志数据库
26
#LOG_SQL_DSN=postgresql://root:new_API%402025@data.qunl.com:14421/new-api-logs
27
# SQLite数据库路径
28
# SQLITE_PATH=/path/to/sqlite.db
29
# 数据库最大空闲连接数
30
# SQL_MAX_IDLE_CONNS=100
31
# 数据库最大打开连接数
32
# SQL_MAX_OPEN_CONNS=1000
33
# 数据库连接最大生命周期（秒）
34
# SQL_MAX_LIFETIME=60
35

36

37
# 缓存相关配置
38
# Redis连接字符串
39
# REDIS_CONN_STRING=redis://user:password@localhost:6379/0
40
# 同步频率（单位：秒）
41
# SYNC_FREQUENCY=60
42
# 内存缓存启用
43
# MEMORY_CACHE_ENABLED=true
44
# 渠道更新频率（单位：秒）
45
# CHANNEL_UPDATE_FREQUENCY=30
46
# 批量更新启用
47
# BATCH_UPDATE_ENABLED=true
48
# 批量更新间隔（单位：秒）
49
# BATCH_UPDATE_INTERVAL=5
50

51
# 任务和功能配置
52
# 更新任务启用
53
# UPDATE_TASK=true
54

55
# 对话超时设置
56
# 所有请求超时时间，单位秒，默认为0，表示不限制
57
# RELAY_TIMEOUT=0
58
# 流模式无响应超时时间，单位秒，如果出现空补全可以尝试改为更大值
59
# STREAMING_TIMEOUT=300
60

61
# Gemini 识别图片 最大图片数量
62
# GEMINI_VISION_MAX_IMAGE_NUM=16
63

64
# 会话密钥
65
# SESSION_SECRET=random_string
66

67
# 其他配置
68
# 生成默认token
69
# GENERATE_DEFAULT_TOKEN=false
70
# Cohere 安全设置
71
# COHERE_SAFETY_SETTING=NONE
72
# 是否统计图片token
73
# GET_MEDIA_TOKEN=true
74
# 是否在非流（stream=false）情况下统计图片token
75
# GET_MEDIA_TOKEN_NOT_STREAM=false
76
# 设置 Dify 渠道是否输出工作流和节点信息到客户端
77
# DIFY_DEBUG=true
78

79
# LinuxDo相关配置
80
LINUX_DO_TOKEN_ENDPOINT=https://connect.linux.do/oauth2/token
81
LINUX_DO_USER_ENDPOINT=https://connect.linux.do/api/user
82

83
# 节点类型
84
# 如果是主节点则为master
85
# NODE_TYPE=master
86

87
EOF

展开收起

因为这里使用的是下划线密码，所以连接字符串里不需要额外加双引号，也不需要做 URL 转义。

五、后台启动 qunl-api#

为了避免当前终端中残留的全局环境变量影响程序读取 .env，先清理可能存在的变量，再用 nohup 后台启动主程序。

Terminal window

1
# 清理全局缓存
2
unset SQL_DSN && unset LOG_SQL_DSN && unset REDIS_CONN_STRING
3

4
# 后台挂起程序，监听 6000 端口
5
nohup ./qunl-api --port 6000 > output.log 2>&1 &

启动后查看日志：

Terminal window

1
tail -f output.log

如果看到类似下面的日志，就说明 qunl-api 已经启动成功：

Terminal window

1
HTTP server started on port :6000

此时访问服务器公网 IP，Nginx 会把 80 端口请求转发到本机 6000 端口的 qunl-api 服务。

常见问题#

1. `docker stop` 提示容器不存在怎么办？#

如果是新服务器，旧容器本来就不存在，这是正常情况。可以继续执行后面的启动命令。

如果想让清理脚本在容器不存在时也不影响继续执行，可以改成：

Terminal window

1
docker stop pg15 redis7 nginx-proxy 2>/dev/null || true
2
docker rm pg15 redis7 nginx-proxy 2>/dev/null || true

2. PostgreSQL 或 Redis 连接不上怎么办？#

优先检查容器是否运行：

Terminal window

1
docker ps

再检查端口是否已经监听：

Terminal window

1
docker logs pg15
2
docker logs redis7

如果日志里出现权限、端口占用或密码错误，就根据日志提示处理。

3. Nginx 能打开，但 qunl-api 无响应怎么办？#

先确认 qunl-api 是否真的在监听 6000 端口：

Terminal window

1
tail -f output.log

再确认 Nginx 容器是否启动成功：

Terminal window

1
docker logs nginx-proxy

本文的 Nginx 配置通过 host.docker.internal 访问宿主机，并在启动容器时加了：

Terminal window

1
--add-host=host.docker.internal:host-gateway

如果 Docker 版本较旧，不支持 host-gateway，需要升级 Docker，或者改用宿主机网关 IP。

4. 修改 `.env` 后没有生效怎么办？#

.env 修改后需要重启 qunl-api 进程。可以先找到旧进程，再重新执行 nohup 启动命令。

Terminal window

1
ps -ef | grep qunl-api

确认进程号后结束旧进程：

Terminal window

1
kill <进程号>

然后重新启动：

Terminal window

1
nohup ./qunl-api --port 6000 > output.log 2>&1 &

完成#

到这里，qunl-api 的基础部署就完成了。整体链路是：

Terminal window

1
用户请求 -> Nginx:80 -> qunl-api:6000 -> PostgreSQL / Redis

后续如果要绑定域名和 HTTPS，可以继续在 Nginx 层配置域名证书，把 server_name localhost; 改成自己的域名，并增加 SSL 配置。

我让 Codex 直接安装飞书 CLI，并把 Excel 生成线上多维表格

Fri, 29 May 2026 00:00:00 GMT

这篇文章按一次真实操作整理。

我没有自己从头研究飞书开放平台，也没有手动敲完整套命令，而是直接把官方文档链接发给 Codex，让它照着文档完成安装、配置、测试，最后还顺手把一个本地 Excel 文件导入成了飞书线上多维表格。

一开始我只发了这样一句话：

1
# 飞书
2
帮我安装飞书 CLI: https://open.feishu.cn/document/no_class/mcp-archive/feishu-cli-installation-guide.md

后面的事情，基本就是 Codex 一边查文档、一边执行命令、一边让我在需要人工确认的地方点一下浏览器授权。

这类流程很适合小白：你不需要先理解所有命令，只要知道什么时候该把需求告诉 Codex，什么时候该在浏览器里完成飞书授权。

先说结论#

这次最终跑通了这些东西：

安装了飞书 CLI：lark-cli
安装了飞书 Agent Skills：lark-doc、lark-sheets、lark-base 等 26 个
完成了飞书 CLI 应用配置
跑通了 lark-cli doctor
把本地 .xlsx 导入成飞书在线表格
又按要求导入成飞书多维表格

最后生成的多维表格链接形态是：

1
https://xxx.feishu.cn/base/xxxxxxxxxxxxxxxx

也就是说，整个流程可以概括成：

1
给 Codex 官方文档链接
2
-> Codex 安装飞书 CLI
3
-> 用户在浏览器里授权
4
-> Codex 验证安装
5
-> 用户给 Excel 文件
6
-> Codex 导入飞书线上文档

飞书 CLI 是什么？#

飞书 CLI 是飞书开放平台提供的命令行工具，命令名叫：

1
lark-cli

它的作用不是“打开飞书客户端”，而是让本地电脑可以通过命令行调用飞书开放平台能力。

它能做的事情包括：

上传本地文件到飞书云空间
把 Word、Excel、PPT 导入成飞书在线文档
把 Excel 导入成飞书表格
把 Excel 导入成飞书多维表格
读取和写入飞书表格
操作文档、云盘、知识库、日历、消息、任务等
配合 Codex 这类 AI Agent 做自动化办公

如果说飞书网页端适合人手动点点点，飞书 CLI 更适合让 AI 或脚本来自动处理。

比如这次我给了一个 Excel，最后 Codex 就能帮我生成飞书多维表格链接。

飞书 CLI 和 Skill 是一回事吗？#

不是。

这次过程中我问了 Codex 一句：

1
这个是skill吗

它解释得比较清楚：

lark-cli 本身是飞书命令行工具，不是 skill
larksuite/cli Agent Skills 是给 Codex、Claude Code 这类 AI Agent 使用的技能说明

可以这样理解：

1
lark-cli：真正执行飞书操作的工具
2
Agent Skills：让 Codex 更懂飞书 API 和飞书 CLI 的使用方式

所以一套完整体验里，两者最好都装：

装 lark-cli，让电脑能操作飞书
装飞书 skills，让 Codex 更会用它

第一步：把官方文档链接直接发给 Codex#

我的第一条消息是：

1
# 飞书
2
帮我安装飞书 CLI: https://open.feishu.cn/document/no_class/mcp-archive/feishu-cli-installation-guide.md

这里最重要的是：不要只说“帮我装一下”，最好把官方文档链接也给它。

这样 Codex 会先打开文档确认当前安装方式，而不是凭旧记忆乱猜。

在这次操作里，Codex 先确认了文档里的核心步骤：

全局安装 @larksuite/cli
安装飞书 CLI 的 Agent Skills
使用 lark-cli config init --new 初始化配置
通过浏览器完成飞书授权
使用 lark-cli doctor 做健康检查

第二步：Codex 检查本机 Node 和 npm#

飞书 CLI 通过 npm 安装，所以 Codex 先检查了本机有没有 Node.js 和 npm。

它执行了类似命令：

Terminal window

1
node --version
2
npm --version
3
lark-cli --version

当时结果是：

1
node: v22.22.0
2
npm: 10.9.4
3
lark-cli: 未安装

这一步的意义是：先确认地基。

如果你的电脑没有 Node.js，Codex 一般会提醒你先安装 Node.js；如果已经有，就可以继续自动安装飞书 CLI。

第三步：Codex 安装飞书 CLI#

确认环境没问题后，Codex 执行了：

Terminal window

1
npm install -g @larksuite/cli

安装完成后，它继续验证：

Terminal window

1
lark-cli --version
2
lark-cli --help

这次得到的版本是：

1
lark-cli version 1.0.43

lark-cli --help 里可以看到很多飞书能力入口，比如：

drive
sheets
base
docs
wiki
calendar
im
task
approval

看到这些，就说明 CLI 本体已经装好了。

第四步：Codex 安装飞书 Agent Skills#

接着 Codex 安装了飞书的 Agent Skills：

Terminal window

1
npx skills add larksuite/cli -g -y

安装结果显示：

1
Found 26 skills
2
Installing all 26 skills
3
Done!

这些 skill 被安装到了类似目录：

1
C:\Users\你的用户名\.agents\skills

里面包括：

1
lark-approval
2
lark-apps
3
lark-base
4
lark-calendar
5
lark-contact
6
lark-doc
7
lark-drive
8
lark-im
9
lark-sheets
10
lark-slides
11
lark-task
12
lark-wiki
13
...

这一步完成后，Codex 后续就更容易理解飞书文档、表格、多维表格这些操作。

第五步：初始化飞书 CLI 配置#

CLI 装好以后，还不能直接操作你的飞书空间。

它需要先在飞书开放平台创建或绑定一个应用。

Codex 执行了：

Terminal window

1
lark-cli config init --new --lang zh_cn

这个命令会生成一个浏览器验证链接，类似：

1
https://open.feishu.cn/page/cli?user_code=XXXX-XXXX&lpv=1.0.43&ocv=1.0.43&from=cli

这一步需要用户配合。

Codex 可以帮你打开链接，但飞书登录、确认授权、应用配置这些动作，需要你自己在浏览器里点完。

我当时完成网页授权后，只回复了一句：

1
完成了

Codex 就继续检查配置结果。

第六步：Codex 做健康检查#

授权完成后，Codex 运行：

Terminal window

1
lark-cli doctor

当时检查结果里关键项是：

1
{
2
  "ok": true,
3
  "workspace": "local"
4
}

并且显示：

1
cli_version: pass
2
config_file: pass
3
app_resolved: pass
4
bot_identity: pass
5
endpoint_open: pass
6
endpoint_mcp: pass

这里有一个小细节：user_identity 当时是 missing。

这不是失败。

它表示还没有登录个人用户身份，但 bot 身份已经 ready，可以进行不少机器人或租户 API 调用。

如果后面要访问个人账号拥有的文档，或者希望新建文档自动归到个人权限下，可以再运行：

Terminal window

1
lark-cli auth login

第七步：我给 Codex 一个 Excel 文件#

CLI 安装好以后，我给了 Codex 一个本地 Excel 文件路径：

1
D:/softWare/weChatData/documents/xwechat_files/.../专家中心分工表.xlsx

然后我说：

1
好的，我给你一个xlsx，你给我弄成飞书线上的并给我链接

Codex 先做了两件事：

检查这个文件是否存在、大小是多少
查看 lark-cli drive 和 lark-cli sheets 的相关命令

文件很小，只有几 KB，所以适合直接导入。

第八步：第一次导入时遇到路径限制#

Codex 一开始尝试直接传绝对路径，结果飞书 CLI 返回：

1
unsafe file path: --file must be a relative path within the current directory

这句话的意思是：为了安全，--file 不能随便传当前目录外的绝对路径。

解决方式很简单：切换到 Excel 文件所在目录，再用相对路径。

比如：

Terminal window

1
cd "D:\softWare\weChatData\documents\xwechat_files\...\2026-05"

然后：

Terminal window

1
lark-cli drive +import --as bot --file ".\专家中心分工表.xlsx" --type sheet --name "专家中心分工表"

这个细节很重要。小白如果自己操作，很容易卡在这里。

第九步：第一次导入时遇到飞书权限不足#

导入过程中，又遇到一个飞书开放平台权限问题：

1
App scope not enabled: required scope docs:document.media:upload

这表示当前 CLI 创建的飞书应用还没有“上传媒体文件用于导入文档”的权限。

好在 CLI 会给出一个权限申请链接，类似：

1
https://open.feishu.cn/page/scope-apply?clientID=cli_xxx&scopes=docs%3Adocument.media%3Aupload

Codex 直接帮我打开了这个页面。

我在浏览器里启用权限后，回复：

1
可以了

然后 Codex 继续重试导入。

第十步：先生成了飞书在线表格#

补完权限后，Codex 成功把 Excel 导入成飞书表格。

命令类似：

Terminal window

1
lark-cli drive +import --as bot --file ".\专家中心分工表.xlsx" --type sheet --name "专家中心分工表"

成功结果里会有：

1
{
2
  "ok": true,
3
  "data": {
4
    "type": "sheet",
5
    "token": "xxxxxxxxxxxxxxxx",
6
    "url": "https://xxx.feishu.cn/sheets/xxxxxxxxxxxxxxxx"
7
  }
8
}

这里 /sheets/ 开头的链接就是飞书在线表格。

但我后面发现，我要的不是普通表格，而是多维表格。

于是我又对 Codex 说：

1
你给我创建成多维表格

第十一步：重新导入成飞书多维表格#

Codex 没有覆盖前面那个表格，而是重新用 bitable 类型导入了一次。

核心命令是：

Terminal window

1
lark-cli drive +import --as bot --file ".\专家中心分工表.xlsx" --type bitable --name "专家中心分工表"

成功后返回：

1
{
2
  "ok": true,
3
  "data": {
4
    "type": "bitable",
5
    "token": "xxxxxxxxxxxxxxxx",
6
    "url": "https://xxx.feishu.cn/base/xxxxxxxxxxxxxxxx"
7
  }
8
}

这里 /base/ 开头的链接，就是飞书多维表格。

Codex 还继续用 inspect 验证了一次：

Terminal window

1
lark-cli drive +inspect --as bot --url "https://xxx.feishu.cn/base/xxxxxxxxxxxxxxxx"

确认结果里显示：

1
{
2
  "type": "bitable",
3
  "title": "专家中心分工表"
4
}

这就说明确实生成成了多维表格。

这套流程里，人需要做什么？#

这个过程里，Codex 能做很多事：

查官方文档
检查本机环境
安装 npm 包
安装 Agent Skills
执行 lark-cli 命令
读取错误信息
打开飞书授权页面
重试失败命令
导入 Excel
验证生成的飞书链接

但人仍然需要做几件事：

在飞书网页里登录账号
确认 CLI 应用配置
开启飞书开放平台提示缺少的权限
判断自己要的是表格还是多维表格
如果链接权限不够，在飞书里补授权，或登录 user identity

所以它不是“完全不用管”，而是“把复杂命令交给 Codex，人只处理必须人工确认的飞书网页授权”。

可以直接复制的 Codex 提示词#

如果你也想复刻这个流程，可以按下面这样发给 Codex。

安装飞书 CLI#

1
# 飞书
2
帮我安装飞书 CLI: https://open.feishu.cn/document/no_class/mcp-archive/feishu-cli-installation-guide.md

授权完成后#

1
完成了

让 Codex 验证安装#

1
帮我检查飞书 CLI 是否安装和配置成功，跑一下 doctor，并告诉我 bot/user 身份状态。

把 Excel 变成飞书线上表格#

1
我给你一个 xlsx 文件，请帮我导入成飞书线上表格，并把链接发我。
2
文件路径：
3
D:\你的路径\文件名.xlsx

把 Excel 变成飞书多维表格#

1
请把这个 xlsx 创建成飞书多维表格，不是普通表格，生成后把 base 链接给我。
2
文件路径：
3
D:\你的路径\文件名.xlsx

如果已经生成了普通表格，但想改成多维表格#

1
不对，我要的是飞书多维表格，请你重新创建成多维表格。

小白最容易遇到的坑#

1. `lark-cli` 和 skill 不是一个东西#

lark-cli 是命令行工具。

lark-* skills 是给 AI Agent 的说明和工作流。

两个都装，体验最好。

2. 需要 Node.js 和 npm#

如果电脑没有 Node.js，npm install -g @larksuite/cli 就跑不起来。

先装 Node.js LTS 版本。

3. 飞书 CLI 初始化必须浏览器授权#

lark-cli config init --new 会生成飞书网页链接。

这一步 Codex 可以帮你打开，但不能替你登录和点击确认。

4. Excel 文件路径最好用相对路径#

如果看到：

1
unsafe file path

就让 Codex 切到文件所在目录，再用：

Terminal window

1
--file ".\文件名.xlsx"

5. 缺 scope 很正常#

第一次导入时，飞书开放平台应用可能没开对应权限。

看到：

1
App scope not enabled

就打开 CLI 返回的 console_url，在飞书开放平台启用权限，再让 Codex 重试。

6. bot 创建的文档可能没有自动给你个人权限#

如果导入成功但你打不开链接，可能是 bot 身份创建了文档，但没有给你的个人账号授权。

可以让 Codex 帮你：

1
帮我处理这个飞书文档的访问权限。如果需要 user identity，请引导我登录。

为什么这种方式适合 Codex？#

飞书 CLI 这种工具很适合交给 Codex。

原因是它的流程不是单纯一条命令，而是一串判断：

文档里的安装命令是不是最新
本机有没有 Node.js
CLI 是否已经存在
安装后版本是否正确
初始化是否需要浏览器授权
doctor 哪一项失败
导入文件时是路径问题还是权限问题
要导入成 sheet 还是 bitable
最终链接是不是对应的文档类型

这些判断让小白自己做，会很容易卡住。

但交给 Codex 后，它可以边执行边读错误，然后告诉你“现在需要你去浏览器点一下授权”。

这就是 AI Agent 真正有用的地方：不是只告诉你命令，而是陪你把事情跑完。

总结#

这次我真正输入的核心需求，其实就几句话：

1
帮我安装飞书 CLI: 官方文档链接
2
完成了
3
给你一个 xlsx，弄成飞书线上的并给我链接
4
你给我创建成多维表格

剩下的安装、检查、报错处理、权限提示、重新导入、类型验证，都是 Codex 在过程中完成的。

如果你也想让 Codex 接入飞书，最推荐的方式不是先自己研究半天命令，而是直接把官方文档链接和目标说清楚：

1
请按照这份官方文档帮我安装和配置飞书 CLI，完成后帮我跑 doctor 验证。

然后等它做到需要你人工确认的地方，再去浏览器里点授权。

对于小白来说，这比传统教程友好很多；对于经常处理飞书资料的人来说，这也意味着以后可以把“本地文件 -> 飞书线上文档 -> AI 继续处理”的链路交给 Codex 来跑。

官方文档：

2026 还值得装的免费 AI 编程工具：Cursor、Copilot、Gemini Code Assist 怎么选

Fri, 15 May 2026 00:00:00 GMT

工具	分类	描述	免费额度	评分	标签	备注
Codex	模型应用	OpenAI 的 ChatGPT 编程应用	按 5 小时、1 周、1 个月计算 Token 限额	9/10	模型、桌面应用	学生可获得 $100 额度
Gemini Code Assist	IDE 扩展 & 终端应用	Google 的 AI 编程助手	每天最多 1000 次请求	7/10	IDE 扩展、终端应用	-
Cursor	IDE	AI 原生代码编辑器	每月 2000 次补全 + 50 次慢速高级请求	8/10	IDE、桌面应用	学生可免费获得一年 Pro
Qodo	IDE 扩展	AI 驱动的测试与编程工具	每月 75 Credits	6/10	IDE 扩展、开源	-
OpenCode	终端应用	开源版 Claude Code 替代方案	基础模型免费，可接入 API Key 使用更强模型	7/10	终端应用、开源	-
GitHub Copilot	IDE 扩展 & 终端应用	AI 结对编程助手	每月 2000 次补全	6/10	IDE 扩展、终端应用	学生可免费使用高级版
Junie	IDE 扩展	JetBrains AI 工具	每 30 天 3 个 AI Credits	3/10	IDE 扩展	JetBrains 学生包内含免费 AI 功能
Cline	IDE 扩展 & 终端应用	开源 AI 助手	免费不限量，可接入 API	3/10	IDE 扩展、终端应用	-
Ollama	终端应用 & API	本地运行大模型	完全免费开源，可运行 Llama、Mistral 等模型	5/10	终端应用、开源	-
Continue	IDE 扩展 & 终端应用	开源 Copilot 替代方案	无限使用（本地或 API 模式）	4/10	IDE 扩展、开源、终端应用	-
Windsurf	IDE 扩展 & IDE	Codeium 推出的 AI IDE	免费版可用，部分高级功能受限	7/10	IDE、IDE 扩展	-
Void	IDE	开源 AI Code Editor	完全免费开源，可接入 API	5/10	IDE、开源	-
Kiro	IDE	AWS 推出的 AI IDE	免费预览期	4/10	IDE	-
Zed AI	IDE	Zed 编辑器内置 AI 功能	基础功能免费，部分模型需 API	6/10	IDE	-
Tabby	IDE 扩展 & 自部署	开源本地代码补全工具	完全免费开源	5/10	IDE 扩展、开源、自部署	-

这两年 AI 编程工具已经多到有点眼花了。

问题不是“有没有工具可用”，而是你刚打开官网时，很难第一眼看明白三件事：

哪个真的能免费用
哪个免费版不是摆设
哪个适合你现在的开发方式

所以这篇就不铺概念了，直接按“普通开发者今天装上去能不能用、值不值得长期留着”的角度来盘一遍。

先说结论：

想要免费额度最宽松，优先看 Gemini Code Assist
想要 GitHub 生态里最省心，优先看 GitHub Copilot Free
想试 AI 原生编辑器，Cursor 依然值得装，但免费版没有以前那么豪横
想完全掌控模型和成本，Cline + Ollama 这条路更自由
Continue 适合折腾型用户，不一定最省事，但很适合自己搭工作流
Codex 很强，但严格说它不是这篇“免费清单”里的性价比首选

1. Gemini Code Assist：免费党最该先装的一个#

如果你现在只想找一个“先用起来再说”的 AI 编程助手，我会把第一推荐给 Gemini Code Assist。

它最猛的地方不是模型名，而是免费版给得真的不算小气。按照 Google 官方文档，截至 2026 年 5 月 15 日：

面向个人开发者的版本可以免费使用
使用个人 Gmail 账号即可开通
每位用户每天有 1000 次请求额度
每月有 180,000 次代码补全

对大多数个人项目、学习项目、日常修 bug 来说，这个额度已经不是“尝鲜级别”，而是能实打实用进日常开发流里。

它适合的人也很明确：

你主要在 VS Code、JetBrains 或 Android Studio 里写代码
你不想折腾 API Key
你想要一个装完就能开始补全、问答、改代码的工具

它不算完美的地方也要提前说清楚。Gemini Code Assist 给人的感觉是“很能用、很稳”，但在某些复杂工程任务上，它未必总是最有主导性、最像一个强 Agent。它更像一个持续在线、额度很厚的编程搭子。

如果你现在还没装任何 AI 编程工具，从它开始，基本不会错。

2. GitHub Copilot Free：最像“通用默认选项”的免费方案#

GitHub Copilot 的优势从来不是最便宜，而是它太容易融进已有开发环境里了。

如果你本来就重度使用 GitHub、PR、Issues、VS Code 或 JetBrains，那 Copilot 的学习成本几乎为零。你不需要重新适应一套全新的开发方式，很多时候它就是自然地补进你现有流程里。

截至 2026 年 5 月 15 日，GitHub 官方公开的 Copilot Free 包含：

每月 2000 次代码补全
每月 50 次 agent mode 或 chat 请求
可在支持的平台中直接使用

这套免费额度说实话不算特别大方，但它有个优点：边界很清晰。你大致知道自己每个月能拿它完成什么，不太会出现“看起来免费，结果几分钟就见底”的心理落差。

我会把它推荐给这几类人：

已经把 GitHub 当开发主场的人
不想折腾新编辑器，只想在熟悉环境里多一个 AI 助手
更在意生态整合，而不是单项能力拉满

它的缺点也很明显。免费版的 agent / chat 请求数不算多，如果你习惯把 AI 当成持续协作对象，而不是偶尔补全代码，那你很快就会碰到上限。

所以 Copilot Free 更像一把“顺手的默认工具”，而不是“火力全开的免费神器”。

3. Cursor：AI 原生编辑器里，依然很能打#

如果你已经不满足于“IDE 里多一个聊天框”，而是更想体验“整个编辑器围着 AI 协作来设计”的感觉，那 Cursor 还是绕不开。

它这两年最成功的地方，是把 AI 从一个插件，慢慢做成了编辑器核心交互的一部分。你会明显感觉到它不是在现有 IDE 上打补丁，而是在改“你和代码对话”的方式。

不过说回免费版，Cursor 现在的策略已经比早期收紧不少。官方定价页面显示，Hobby Free 目前提供的是：

无需信用卡
有限的 Agent 请求
有限的 Tab 自动补全

也就是说，它依然值得装，但你最好不要再把它理解成一个无限白嫖的主力工具。免费版更像“体验 Cursor 工作方式”的入口，而不是长期高强度使用的终局方案。

它更适合：

想试试 AI 原生 IDE 到底和传统编辑器有多大差别
更喜欢一体化交互，而不是到处装插件
愿意把 AI 当成核心工作流，而不是辅助功能

如果你只是偶尔写点代码，Cursor 免费版未必比 Copilot 或 Gemini 更合算；但如果你想体验当下最成熟的一批 AI 编辑器思路，它仍然很值得保留。

4. Cline：真正给你“自己选模型、自己控成本”的自由#

Cline 的定位和前面几位不太一样。

它不是那种“官方给你包好额度、包好模型、包好体验”的产品，而是一个开源 AI coding agent。它强调的是透明、可控和不锁模型生态。你可以自己选模型，自己接供应商，也可以自己决定成本和能力之间怎么取舍。

这条路线的好处，是自由度非常高。官方文档也明确提到它有几种免费路径：

使用带 FREE 标记的免费模型
使用部分服务商提供的免费额度
直接接入本地模型

这也是为什么很多喜欢折腾工作流的人会偏爱 Cline。它不是让你接受一个现成套餐，而是把方向盘给你。

当然，自由的另一面就是更依赖你的动手能力。你要理解模型差异、供应商差异、上下文成本、任务耗费，才更容易把它调到顺手。

所以它更适合：

已经理解 API / 模型 / token 成本这些概念的人
希望模型可替换、供应商可替换
不喜欢被某一个平台彻底锁死

如果你是新手，Cline 未必是最省心的第一站；但如果你已经开始在意“以后要不要把整个工作流绑在单一厂商上”，那它会越来越有吸引力。

5. Continue：更像一套可拼装的 AI 开发基础设施#

Continue 和 Cline 一样，也是偏开放路线的工具，但它给人的感觉更像“基础设施”而不是“成品工具”。

它提供 IDE 扩展、CLI、规则配置、MCP 扩展能力，还能把 AI 检查带进 PR 工作流。换句话说，它不是只想帮你补全几行代码，而是想进入整个开发流程。

这类工具最吸引人的地方，是你可以按自己的习惯拼装：

在 IDE 里做交互式改代码
在终端里跑 TUI 或自动化流程
在 CI / PR 阶段做检查

但它也有一个很现实的门槛：Continue 本身不是那种“官方塞给你一大把免费模型额度”的产品。它更像一个开放框架，是否免费、花多少，往往取决于你接的模型和部署方式。

所以我会把它推荐给：

已经不满足于单点 AI 补全
想把 AI 融进终端、PR、检查流
乐于自己搭配置的人

如果你要的是“装完立刻用”，它不是最短路径；如果你要的是“把 AI 真正接进团队工程化流程”，Continue 的上限会很高。

6. Ollama：当你不想继续把代码上下文都交给云端#

如果你越来越在意隐私、成本，或者单纯想体验本地模型工作流，那 Ollama 现在已经是非常成熟的入口了。

它的价值不在于“单独拿来替代一切云端编程助手”，而在于它让你拥有了另一种选择：

模型跑在自己机器上
数据留在本地
没有按次调用的焦虑
可以和别的工具组合使用

Ollama 官方目前提供免费方案，支持本地运行开源模型，也提供 CLI、API 和桌面应用。对很多人来说，它不是第一个装的工具，却很可能是后面越来越离不开的那个底座。

尤其是当你把它和 Cline、Continue 这类开放工具组合起来之后，你会明显感受到一件事：AI 编程不一定非得建立在“每一步都把代码发到第三方云端”这条路上。

它适合：

本地机器配置还不错
对隐私更敏感
希望把长期成本压低
想自己掌控模型选择

7. 那 Codex 呢？#

很多人会把 Codex 也一起拉进比较里，这很正常，因为它在“像工程代理一样持续做事”这件事上，确实非常有代表性。

但如果我们把这篇文章限定为“免费 AI 编程工具盘点”，那我会把 Codex 放在一个比较特殊的位置。

原因很简单：它很强，但它并不属于那种最适合零门槛白嫖上手的选择。OpenAI 目前公开的文档重点更多放在不同 ChatGPT 方案下的 Codex 额度与计费方式上。也就是说，它更适合已经在用 ChatGPT 生态、并且愿意为更强代理能力付费的人，而不是单纯想找一个免费主力工具的新手。

所以如果你问我“Codex 强不强”，我的答案是强。

但如果你问我“2026 年 5 月，免费党应该先从哪一个开始”，我还是会把优先级放在 Gemini Code Assist、Copilot Free、Cursor Free，或者 Cline / Continue + Ollama 这一类更容易控制成本的组合上。

一张表看完#

工具	免费可用性	更适合谁	我对它的定位
Gemini Code Assist	很强	个人开发者、学生、日常编码用户	免费主力首选
GitHub Copilot Free	中上	GitHub / VS Code 重度用户	最省心的默认选项
Cursor Free	中	想体验 AI 原生 IDE 的人	最值得体验的编辑器路线
Cline	取决于模型	想自由选模型的人	高可控开源 Agent
Continue	取决于部署	想自己搭工作流的人	AI 工程化基础设施
Ollama	很强	本地模型爱好者、隐私敏感用户	本地底座
Codex	不适合按“免费主力”理解	已在 ChatGPT 生态里的用户	强，但不是免费榜首

我的建议#

如果你懒得对比太久，可以直接按下面这个顺序试：

先装 Gemini Code Assist，看你日常写代码到底会不会真的用 AI
如果你本来就深度用 GitHub，再补一个 Copilot Free
想体验 AI 原生 IDE，再装 Cursor
如果你开始在意隐私、成本和模型自由度，再去试 Cline、Continue 和 Ollama

AI 编程工具到 2026 年，已经不是“谁最聪明”这么简单了。真正拉开体验差距的，往往是它和你当前工作流合不合拍。

你不一定需要最强的那个，但你很需要那个你愿意每天打开的工具。

官方链接#

Gemini Code Assist: developers.google.com/gemini-code-assist
GitHub Copilot: github.com/features/copilot/plans
Cursor: cursor.com/pricing
Cline: docs.cline.bot
Continue: docs.continue.dev
Ollama: ollama.com
Codex: openai.com/codex

StackPrism：比 Wappalyzer 更愿意深挖线索的栈探针

Tue, 12 May 2026 00:00:00 GMT

如果你平时喜欢看别人网站怎么做的，那你大概率用过 Wappalyzer。它足够经典，也足够省事，但只要你认真拆过一些现代站点，就会很快发现一个问题：很多技术线索根本不在表面上，尤其是那些动态加载、按需注入、或者藏在源码快照和响应头里的东西。

所以我今天想记一下这个项目：StackPrism。

它给我的第一感觉不是“又一个技术栈识别插件”，而是“这作者是真的想把页面翻个底朝天”。按照仓库介绍，StackPrism 不只是扫一眼页面源码，它会从页面运行时、DOM、资源 URL、响应头、动态加载资源和源码快照里持续收集线索，然后再按分类展示结果。

这意味着什么？简单说，就是它不是只想告诉你“这个站像不像 React”，而是更想把整条痕迹链都找出来。仓库里列出的分类非常细，从前端框架、UI / CSS 框架、构建与运行时，到 CDN、Web 服务器、CMS、电商平台、统计分析、OAuth、支付、AI / 大模型，覆盖面明显比很多老牌检测器更激进。

我尤其喜欢它对“动态页面”的重视。现在很多站点在首屏几乎不暴露太多信息，真正的线索要等交互之后才会出现。StackPrism 会持续记录交互后新增的脚本、样式、iframe 和关键 DOM 标记，再把这些动态信息合并回结果里。这个思路很对味，因为现代网页本来就不该只用一次静态扫描去理解。

另一个很加分的点，是它没有把规则系统做成黑箱。仓库里专门把规则放在 rules/ 目录维护，技术名称链接、响应头匹配、页面源码规则都能继续扩展。换句话说，它不只是一个“拿来即用”的插件，也是一套可以继续生长的检测规则库。

截至 2026 年 5 月 12 日，这个仓库在 GitHub 上大约有 250 个 star，而且提交历史已经相当活跃。对一个还在持续完善中的浏览器扩展来说，这种状态很讨喜，因为它说明项目不只是一个一时兴起的小玩具。

源码链接：

GitHub: setube/stackprism

如果你经常分析竞品站点、研究建站方案，或者单纯就是喜欢看一个网页背后到底堆了什么技术，我觉得 StackPrism 很值得装上试试。它不一定替代所有老工具，但至少会让你重新意识到：网页技术栈这件事，真的还能挖得更深。

中国专利.skill：把技术交底书流程拆开重做

Tue, 12 May 2026 00:00:00 GMT

很多人做专利时，真正痛苦的不是“没技术”，而是手里明明已经有设计文档、代码、流程图，最后却还是要重新把材料再讲一遍。更折磨的是，讲完还不一定能直接变成代理人可用的技术交底书。

我今天翻到一个挺有意思的开源项目：中国专利.skill。它不是那种只会吐一段“专利风文字”的包装工具，而是试图把整个链路打通：先扫项目文档和代码，再挖专利点，再去做查新，最后生成可交付的交底书，甚至连后续修订记录都考虑进去了。

仓库 README 里写得很明确，这个 skill 的目标不是只帮你“写一篇文”，而是围绕交付物组织流程。它支持把 .docx、.pptx 先转成 Markdown 再扫描，查新时优先走国知局公布公告站，成稿时还能补系统框图、流程图，以及 Word 版本的输出。对真正做过专利材料的人来说，这些细节比“会不会写漂亮句子”重要得多。

我觉得它最有价值的一点，是把“专利写作”从一次性的玄学劳动，往“可复用、可追溯、可修订”的工程流程上拉。你可以把它理解成一条专门服务技术交底书的生产线，而不是一个只在聊天框里显得聪明的助手。

如果你正好处在下面几种状态，这个项目很值得点进去看看：

手里有真实项目，准备开始做专利挖掘
已经被交底书、查新和反复补材料折腾过
不想把技术细节完整交给外部代办反复沟通
想把专利材料流程沉淀成团队内部方法

当然，它也不是“点一下就万事大吉”的那类工具。专利点判断、方案边界、权利要求质量，最后还是要靠人来把关。但如果你最头疼的是前期资料整理、查新入口和交付格式，这个仓库已经把最耗时间的那一段路铺得很长了。

截至 2026 年 5 月 12 日，这个项目在 GitHub 上已经拿到约 268 个 star。对一个非常垂直、而且偏中文实务场景的 skill 来说，这个关注度已经说明它确实击中了痛点。

源码链接：

GitHub: handsomestWei/patent-disclosure-skill

如果你最近刚好在做技术成果沉淀、专利申请准备，或者想把“项目文档 -> 专利交底书”的过程做成半自动化，我会把它列进值得认真试一轮的开源工具清单里。

中国软著.skill：软著申请材料终于不用外包整理了

Tue, 12 May 2026 00:00:00 GMT

软件著作权这件事，很多开发者其实不是怕申请，而是怕整理材料。软件名称、版本号、申请表字段、操作手册、代码前后 30 页，任何一个地方不一致，都会把原本不复杂的事情拖成体力活。

今天看到的这个项目，中国软著.skill 就很直给：它想解决的不是“替你懂法律”，而是“把那一整套重复、机械、还容易出错的资料准备工作接过去”。

这个仓库最让我有好感的一点，是它把边界写得很清楚。它不是瞎编源码的生成器，代码材料直接来自你自己的真实项目；它也不是把软著包装成一门高深服务，而是明确告诉你，很多所谓付费代办，本质上卖的就是文档整理。既然如此，不如把这部分流程尽量开源、透明，而且尽可能留在本地完成。

按照仓库说明，它会围绕真实项目生成一整套可检查的软著申请资料，包括：

申请表信息整理文本
面向审核视角编写的操作手册
按常见要求抽取的代码前 30 页和后 30 页
最终可导出的 .docx 正式资料

比起“生成几段申请说明”，我更看重它对流程细节的处理。比如它会强调关键字段统一、代码页数规则、让用户在关键节点确认内容，尽量避免到最后才发现名称不一致、描述写偏、代码截取不合规。对第一次申请软著的人来说，这种流程感其实非常重要。

另外一个很现实的优点是：它默认把资料生成在本地项目目录里。换句话说，你不需要先把项目代码和产品细节发给外部服务，再来回沟通“这个功能不是这么描述的”。如果你的项目本身就比较敏感，这种本地化处理会让人安心很多。

截至 2026 年 5 月 12 日，这个仓库在 GitHub 上的公开信息显示它已经形成了完整的 demo、目录结构和生成样例。它现在未必是“最花哨”的 skill，但很像那种真正能帮你省时间、省沟通成本的工具。

源码链接：

GitHub: Fokkyp/SoftwareCopyright-Skill

如果你正准备申请软著，或者团队里总有人被资料整理拖住节奏，这个项目很适合收藏下来。它最吸引人的地方不是炫技，而是把一件大家都嫌麻烦、但又必须做的事，尽量做得顺手一点。

Claude Desktop 配置第三方 API 保姆级教程

Sun, 10 May 2026 00:00:00 GMT

本文转载自 @xiangxiang103 的推文，感谢原作者分享。

这个功能可以把 Claude Desktop 变成你自己的第三方 API 桌面客户端。配置完成后，模型调用会走你填写的第三方 API，不再消耗 Claude 官方订阅额度；但会消耗第三方 API 的额度或余额。

它适合想在 Claude Desktop 里使用 Cowork、Projects、Artifacts 等功能，同时又希望接入自己 API 服务的用户。需要注意的是：第三方模式并不是”完整网页版 Claude”的替代品，官方普通 Chat 标签在这个模式下不可用，主要使用的是 Cowork / Code / Projects / Artifacts 这些能力。

重要前提（必须看）#

必须使用最新版 Claude Desktop：低版本可能没有开发者模式或第三方推理配置入口。
建议先保持未登录状态：不需要先登录 Claude 官方账号。如果已经登录，建议先退出后再配置。
必须使用支持 Anthropic-compatible 的第三方 API：单纯 OpenAI-compatible 的接口不一定能用。
Gateway base URL 需要是 HTTPS 地址：并且对应服务需要支持 Anthropic Messages API，通常也就是能处理 /v1/messages 请求。
注意隐私风险：你的提示词、文件内容、项目上下文可能会经过第三方 API 服务。不要把敏感资料交给不可信的中转站。

本教程以 Windows 为例，截图也是 Windows 环境下的界面。

步骤 1：打开 Claude Desktop 并启用开发者模式#

打开 Claude Desktop，先不要登录官方账号。
如果当前界面不好直接点菜单，可以按键盘 Tab 切到左上角菜单区域，再按回车打开菜单。
在顶部菜单栏选择 Help（帮助） → Troubleshooting（疑难解答）。
在弹出的子菜单里点击 Enable Developer Mode（启用开发者模式）。
启用成功后，顶部菜单栏会多出一个 Developer（开发者） 菜单。

步骤 2：进入第三方 API 配置页面#

点击新出现的 Developer 菜单。
选择 Configure Third-Party Inference…（配置第三方推理…）。

步骤 3：填写 Base URL 和 API Key（最关键一步）#

打开配置窗口后，按下面方式设置：

Use this configuration：打开开关，必须开启。
Gateway：选择 Anthropic-compatible。
Gateway base URL：粘贴你的第三方 API Base URL。
Gateway API key：粘贴你的 API Key，也就是中转站后台复制出来的那串密钥。
Gateway auth scheme：一般保持默认即可。
Gateway extra headers：一般不用填写，除非你的服务商明确要求额外请求头。

设置完后，点击右下角 Apply locally（本地应用）。

步骤 4：验证是否成功#

配置完成后，Claude Desktop 可能会提示重启；如果没有提示，也建议手动完全退出后重新打开。

重新打开后，进入 Cowork、Code 或 Projects 相关页面。
输入一个简单问题测试。
如果模型能正常响应，或者界面中显示的是你第三方 API 提供的模型，就说明配置成功。

成功后你会看到：

模型调用走第三方 API，不消耗 Claude 官方订阅额度。
可以使用 Cowork / Projects / Artifacts 等第三方模式支持的功能。
响应速度取决于你的第三方 API 服务质量和网络延迟。

常见问题 & 解决办法#

Q1：找不到 Developer 菜单怎么办？#

确认已经点击 Help → Troubleshooting → Enable Developer Mode。
完全退出 Claude Desktop 后重新打开。
确保 Claude Desktop 已经更新到最新版本。

Q2：配置后还是进了普通 Claude 登录页？#

可能是配置没有生效，尝试：

确认 Use this configuration 已经打开。
确认填写了 Gateway、Base URL 和 API Key。
点击 Apply locally 后完全退出并重新打开 Claude Desktop。
如果仍不生效，可以在 Help → Troubleshooting 里查看配置报告或错误提示。

Q3：报错或无法连接怎么办？#

重点检查这几项：

API Key 是否复制完整，前后不要多空格。
Base URL 是否是 https:// 开头。
你的第三方 API 是否真的支持 Anthropic-compatible，而不是只支持 OpenAI-compatible。
服务商是否要求额外请求头，如果要求，就需要填到 Gateway extra headers。
第三方 API 余额、额度或模型权限是否正常。

Q4：为什么我填了 OpenAI 格式的接口不能用？#

Claude Desktop 的第三方推理配置要求 Anthropic-compatible 接口，也就是需要支持 /v1/messages 格式的请求。单纯的 OpenAI-compatible（/v1/chat/completions）接口不兼容。

Q5：想切换回官方 Claude 怎么办？#

可以直接关闭 Use this configuration 开关即可恢复官方模式。

小贴士#

这个配置是本地保存的，只影响当前这台 Windows 电脑上的 Claude Desktop。
它不影响网页版 Claude，也不会改变你的 Claude 官方账号设置。
第三方 API 的质量很关键，建议优先选择稳定、透明、可信的服务。
官方客户端和相关功能可能随时更新，如果界面变化，以最新版本里的菜单和提示为准。

配置完成后，可以直接去试试 Cowork 或 Projects。桌面版体验确实很顺手。

小小华山-拿下!

Sat, 21 Jun 2025 00:00:00 GMT

一、西岳华山地图总览#

二、车票门票预定与购买#

西安站→ 华山站（火车）#

推荐方案：

备选方案：

华山站→ 游客服务中心/玉泉院（索道上山/徒步登山口）#

高德打车价格在10R上下 / 不排除拼车 / 大巴 / 黑车

三、华山门票预定与购买#

购买途径#

华山景区官方微信公众号/美团/咸鱼
门票成人160 学生80 非官方会便宜一些

套餐详情#

我们选择徒步路线即 - 玉泉院徒步到达北峰 → 西峰索道 + 出山车（必做）下山

北上西下北上北下等相关全程索道套餐如下：

详细信息可在华山微信公众号官网点击门票预约查看相关信息。

总费用预估#

（排除吃喝、登山工具、拼车等开销）大致如下：

火车20/30 + 徒步北上西下340 + 火车20/30 = 380/400

火车20/30 + 全程索道北上172（学生优惠）+ 西下180 + 火车20/30 = 392/422

其余套餐可在华山微信公众号官网点击门票预约查看相关信息。

四、登山装备#

华山在渭南华阴县，周日气温较高

自备背包，有条件尽量双肩包（爬山途中牢固）
运动鞋/登山鞋
手机、充电宝（2万毫安以下，不然火车不让带）、充电线
线手套
2-3瓶小瓶矿泉水 / 1瓶大瓶矿泉水（山上购买价格较高）
自热米饭/火锅（推荐）、高能量零食、可乐雪碧小甜水、压缩饼干、士力架等
卫生纸、湿巾
考虑天气较为炎热，可携带湿巾、毛巾等
衣服以短袖（可外加防晒衣）、长裤为主（避免擦伤），可不携带外套
可携带帽子、太阳镜、防晒霜

五、应急方案#

为避免突发性事件的产生，建议携带以下药用：

创可贴
百多邦
医用酒精

六、徒步登山日程规划#

到达登山口#

周日早9:00/9:30到达索道/徒步登山口

徒步登山#

华山天险第一关—— 五里关（徒步时间较长、坡缓）#

毛女洞（徒步时间较长、坡缓）#

千尺幢（徒步时间较长、坡先缓后陡）#

拥有台阶370余级，坡度极陡，又名”太华咽喉”

百尺峡（徒步时间较短、坡度极陡）#

二仙桥（徒步时间较短、坡度较陡）#

北峰（海拔1614米）#

云台峰，金庸题字”华山论剑”处。有华山论剑、真武殿、卧牛台、聚仙台等众多景点。

到达北峰后，沿山脊行走：

苍龙岭（徒步时间较短、坡度平坦）#

“韩退之投书处” —— 韩愈游华山在此畏险大哭投书求助

金锁关（徒步时间较短、坡度平坦）#

分流口#

左登顶中峰、后走东、南、西峰。（预估2小时）

五峰简介：

东峰：最佳日出观测点 “朝阳台”
南峰：最高峰2154.9米，必拍海拔碑
西峰：最美莲花峰，索道旁有沉香劈山救母石
北峰：云台峰，金庸题字”华山论剑”处
中峰：最小众，古松奇石值得一看

乘西峰索道下山#

游玩项目#

东峰：鹞子翻身（安全绳 30R/人）#

长空栈道（30R/人）#

东峰顶#

南峰顶#

西峰顶#

七、总耗时预计#

徒步到北峰 3-4小时：9点→ 13点左右
徒步东西南北中峰 1-3小时（拍照、游玩、打卡等）：14点→ 17点
西峰下山索道排队预留时间30分钟：17点半→19点
大致8点上火车/高铁，到家预计10点上下

八、返程票#

返程票暂时无需购买，可能由于路途安排延误等情况。
可待下西峰时进行购买。

PS#

大家一定多加小心，有身体或不可预见问题及时沟通交流！

上海15号线永德路「每周一店」深度探索指南

Sat, 10 May 2025 00:00:00 GMT

住在永德路，也能逛遍上海最前沿的生活方式。本指南精选 30+ 家西安稀缺或未有的特色店铺，涵盖超市、咖啡、书店、潮牌、艺术空间等，助你每周打卡一家，提升生活质感。

挑战计划概览#

周数	主题	推荐店铺数
第1-4周	高端超市 & 生活方式	5家
第5-8周	网红咖啡 & 甜品	6家
第9-12周	设计师品牌 & 潮流地标	6家
第13-16周	书店 & 艺术空间	5家
第17-20周	小众街区 & 开放式商业	5家
第21-24周	餐饮首店 & 国际品牌	5家
第25-30周	周边延伸 & 滨江体验	4家

第一章：高端超市 & 生活方式（西安稀缺）#

店铺名称	位置	交通路线（从永德路出发）	推荐指数	适合人群
Ole’精品超市 (iapm)	环贸iapm LG2, 淮海中路999号	15号线 → 罗秀路站换7号线 → 常熟路站换1号线 → 陕西南路站（约40分钟）	⭐⭐⭐⭐☆	品质生活、家庭采购
City’s Super (国金中心)	IFC B1, 世纪大道8号	15号线 → 紫竹高新区站换13号线 → 世博大道站换14号线 → 陆家嘴站（约50分钟）	⭐⭐⭐⭐⭐	进口食品爱好者、日韩料理控
APITA (金桥店)	金桥国际商业广场, 张杨路3611弄	15号线 → 南方商城站换12号线 → 金京路站（约55分钟）	⭐⭐⭐⭐	日系生活爱好者、家庭客群
盒马X会员店 (森兰)	森兰商都B1, 东靖路1881号	15号线 → 紫竹高新区站换13号线 → 孙桥站换14号线 → 东靖路站（约60分钟）	⭐⭐⭐⭐☆	大家庭、囤货党
BLT精品超市 (环贸iapm)	iapm B2, 淮海中路999号	同Ole’路线	⭐⭐⭐☆	年轻白领、轻奢生活

第二章：网红咖啡 & 甜品（西安暂无或稀少）#

店铺名称	位置	交通路线	推荐指数	适合人群
Blue Bottle Coffee (蓝瓶)	外滩源, 虎丘路20号	15号线 → 南方商城站换12号线 → 汉中路站换13号线 → 南京东路站（约50分钟）	⭐⭐⭐⭐⭐	咖啡发烧友、打卡党
%Arabica (武康路)	武康路376号	15号线 → 南方商城站换12号线 → 陕西南路站（约35分钟）	⭐⭐⭐⭐☆	情侣约会、拍照打卡
M Stand (滨江店)	东岸滨江, 近董家渡路	15号线 → 南方商城站换12号线 → 大世界站换8号线 → 老西门站换10号线 → 秦皇码头站（约50分钟）	⭐⭐⭐⭐	江景爱好者、摄影控
Seesaw (安福路旗舰店)	安福路322号	同%Arabica路线	⭐⭐⭐☆	手冲咖啡爱好者
Lady M (新天地店)	新天地北里, 马当路245号	15号线 → 南方商城站换12号线 → 汉中路站换13号线 → 新天地站（约45分钟）	⭐⭐⭐⭐☆	甜品控、下午茶
Kura Sushi (藏寿司)	南京西路会德丰广场	15号线 → 南方商城站换12号线 → 汉中路站换13号线 → 南京西路站（约40分钟）	⭐⭐⭐⭐	家庭聚餐、亲子体验

第三章：设计师品牌 & 潮流地标（西安暂无对标）#

店铺名称	位置	交通路线	推荐指数	适合人群
TX淮海	淮海中路523号	15号线 → 南方商城站换12号线 → 陕西南路站（约30分钟）	⭐⭐⭐⭐⭐	潮人、Z世代
前滩太古里	东育路500号	15号线 → 南方商城站换12号线 → 东方体育中心站（约35分钟）	⭐⭐⭐⭐☆	家庭休闲、滨江散步
POPMART全球旗舰店	南京东路353号	15号线 → 南方商城站换12号线 → 汉中路站换13号线 → 南京东路站（约45分钟）	⭐⭐⭐☆	潮玩爱好者
Aesop (东平路旗舰店)	东平路10号	15号线 → 南方商城站换12号线 → 陕西南路站（约35分钟）	⭐⭐⭐⭐	护肤品爱好者、小众品牌控
COS (环贸iapm店)	环贸iapm L3	同Ole’路线	⭐⭐⭐☆	极简风爱好者
The North Face Urban Exploration (TX淮海)	TX淮海L2	同TX淮海路线	⭐⭐⭐☆	户外潮流爱好者

第四章：书店 & 艺术空间（西安文化氛围不同）#

店铺名称	位置	交通路线	推荐指数	适合人群
茑屋书店 (上生·新所)	延安西路1262号	15号线 → 南方商城站换12号线 → 江苏路站换2号线 → 中山公园站（约40分钟）	⭐⭐⭐⭐⭐	文艺青年、阅读爱好者
多抓鱼循环商店 (静安嘉里中心)	南京西路1515号	15号线 → 南方商城站换12号线 → 汉中路站换13号线 → 南京西路站（约45分钟）	⭐⭐⭐⭐	环保生活、二手书爱好者
衡山·和集	衡山路880号	15号线 → 南方商城站换12号线 → 陕西南路站（约35分钟）	⭐⭐⭐☆	摄影、文艺打卡
龙美术馆 (西岸馆)	龙腾大道3398号	15号线 → 南方商城站换12号线 → 龙华中路站（约40分钟）	⭐⭐⭐⭐☆	艺术爱好者、周末看展

第五章：小众街区 & 开放式商业（西安尚在起步）#

店铺名称	位置	交通路线	推荐指数	适合人群
安福路	安福路全段	同%Arabica路线	⭐⭐⭐⭐	慢生活、咖啡漫游
武康路	武康路全段	同%Arabica路线	⭐⭐⭐⭐☆	历史建筑爱好者
永康路	永康路	15号线 → 南方商城站换12号线 → 常熟路站（约35分钟）	⭐⭐⭐☆	本地生活体验
上生·新所	延安西路1262号	同茑屋书店路线	⭐⭐⭐⭐	建筑摄影、周末散步
愚园路	愚园路全段	15号线 → 南方商城站换12号线 → 江苏路站（约30分钟）	⭐⭐⭐☆	城市漫步爱好者

第六章：餐饮首店 & 国际品牌（西安未进入）#

店铺名称	位置	交通路线	推荐指数	适合人群
Shake Shack (iapm店)	环贸iapm L4	同Ole’路线	⭐⭐⭐⭐	汉堡爱好者
鼎泰丰 (新天地店)	新天地北里	同Lady M路线	⭐⭐⭐☆	小笼包爱好者
Peet’s Coffee (旗舰店)	徐家汇美罗城	15号线 → 南方商城站换12号线 → 徐家汇站（约25分钟）	⭐⭐⭐	咖啡控
Wagas (滨江店)	东岸滨江	同M Stand路线	⭐⭐⭐	健康轻食爱好者

第七章：周边延伸 & 滨江体验（西安无江景）#

店铺名称	位置	交通路线	推荐指数	适合人群
前滩休闲公园 + 滨江步道	东育路500号旁	同前滩太古里路线	⭐⭐⭐⭐☆	跑步、骑行、遛娃
徐汇滨江 (西岸)	龙腾大道沿线	15号线 → 南方商城站换12号线 → 龙华中路站（约35分钟）	⭐⭐⭐⭐☆	艺术、骑行、看展
森兰商都 + 森兰绿地	东靖路1881号	同盒马X会员店路线	⭐⭐⭐☆	家庭休闲
滴水湖环湖步道 (临港)	浦东新区	15号线 → 南方商城站换12号线 → 东方体育中心站换16号线 → 滴水湖站（约70分钟）	⭐⭐⭐	周末远足、自然爱好者

总结：上海 vs 西安生活方式差异#

维度	上海优势	西安优势
国际品牌	丰富，首店多	较少，依赖SKP引入
小众文化	街区多元，独立店密集	有尝试，但未成气候
滨江生活	黄浦江沿线成熟	无江景，曲江为湖
高端超市	Ole’、City’s Super、APITA	仅有BHG，选择有限
艺术空间	茑屋、多抓鱼、龙美术馆	美术馆多偏传统

挑战建议#

优先选择30分钟内可达的店铺：如徐家汇、南方商城周边。
周末集中探索远距离目标：如前滩、外滩、西岸。
结合天气选择：晴天去滨江，雨天逛商场。
拍照打卡+小红书分享，记录生活质感。

祝你挑战成功，发现一个更丰富的上海！

Mars

OSINT Explorer：1300+ 免费开源情报工具导航与合规使用指南

什么是 OSINT#

OSINT Explorer 到底解决了什么问题#

工具分类应该怎么理解#

1. 社交媒体与用户名#

2. 邮箱与账号暴露#

3. 手机号与通信线索#

4. 域名、DNS 与证书#

5. IP、网络与基础设施#

6. 图片、视频与地理位置#

7. 文件、代码与元数据#

推荐的 OSINT 工作流#

为什么说它适合安全团队#

为什么说它也适合普通开发者#

合规边界：会用工具不等于可以乱用工具#

结果可信度怎么判断#

和传统搜索引擎的区别#

我会怎么使用 OSINT Explorer#

它的局限性#

总结#

我自己收集的 PPT 设计技巧资源：从杂志风到 Open Design

为什么这类资源值得单独收藏#

资源总览#

1. guizang-ppt-skill：杂志风 PPT 的工程化表达#

它适合做什么#

适合直接使用的 Prompt#

我的评价#

2. huashu-design：从 PPT 扩展到动画、原型和设计评审#

它的几个关键词#

它适合做什么#

适合直接使用的 Prompt#

我的评价#

3. Awesome-PPT-Design-Skills：7 种风格的 PPT Skill 集合#

这类集合最值得学什么#

适合直接使用的 Prompt#

我的评价#

4. open-design：本地优先的开源 Claude Design 替代品#

它和前面三个项目有什么不同#

它适合谁#

我的评价#

怎么选择：一张速查表#

一套更实用的组合工作流#

如何写一个更容易出好 PPT 的需求#

这类工具的局限#

结语#

参考链接#

Codex App 安装指南：绕过 Microsoft Store 下载链路限制

一句话理解 codex-app-mirror#

下载入口#

1. GitHub Release#

2. 国内 R2 镜像#

Windows 安装方式#

Windows 常见问题#

1. 提示无法安装 MSIX#

2. 双击 MSIX 没反应#

3. 安装后启动失败#

macOS 安装方式#

一定要做校验#

Windows 校验#

macOS 校验#

为什么校验很重要#

release-manifest.json 是做什么的#

版本号为什么 Windows 和 macOS 不一致#

codex-app-mirror 是怎么更新的#

它不会做什么#

我的建议#

结语#

参考链接#

Fiddler Everywhere 5.17+ 非官方补丁 Release 技术解读与风险复盘

Release 元数据速读#

先理解 Fiddler Everywhere 的位置#

官方版本线索：5.17 并不是当前新版本#

非官方 patcher 通常会动哪里#

真正的风险不是“破解失败”，而是信任链断裂#

风险矩阵#

为什么“禁用更新”是一个危险信号#

如果你是安全研究员，应该怎么分析它#

对个人开发者的建议#

对团队和公司的建议#

1. `docker stop` 提示容器不存在怎么办？#

4. 修改 `.env` 后没有生效怎么办？#

1. `lark-cli` 和 skill 不是一个东西#