文章
20356 条发现 · 精选自开放网络的发现，按时间从新到旧。
-
【vscode扩展】apis-tester
一个轻量级的 VS Code 扩展，用于在编辑器内快速测试和管理 API 接口。支持分组管理、导入导出、WebDAV 云端同步，让 API 测试更加高效。
北门清燕 · ZH
-
🎙️ 科技热文播报 - 2026-03-14
我看到一个很有意思的话题 [1]：1M context is now generally available for Opus 4.6 and Sonnet 4.6
北门清燕 · EN
-
DBeaver WebDAV 备份插件
这是一个面向 DBeaver 24/25+ 的 Eclipse/OSGi 插件，用于将 DBeaver 项目、脚本和凭据备份到 HTTPS WebDAV 端点。
北门清燕 · ZH
-
阿里云实人认证iOS SDK 升级
记录阿里云实人认证 RPSDK 停止服务后，iOS 项目迁移到金融级实人认证 SDK 的完整过程，包含旧 SDK 删除、新 SDK 接入与踩坑记录。
崎径 其镜赵安琪的博客 · ZH
-
Unity 项目迁移鸿蒙（一）：环境准备与工程结构
Unity 项目迁移 HarmonyOS 的系列教程（一）：完成团结引擎与 DevEco Studio 环境配置，处理平台宏和字体兼容问题，并快速理解 OpenHarmony 导出工程结构。
崎径 其镜赵安琪的博客 · ZH
-
Unity 项目迁移鸿蒙（二）：打包与调试
Unity 项目迁移 HarmonyOS 的系列教程（二）：使用 DevEco Studio、HiLog 和 HDC 调试 OpenHarmony 工程，处理平台代码，配置 Jenkins 构建，并将 Unity 日志转发到原生层。
崎径 其镜赵安琪的博客 · ZH
-
Unity 项目迁移鸿蒙（三）：SDK 接入与双向通信
Unity 项目迁移 HarmonyOS 的系列教程（三）：讲解 DevEco Studio 工程中的 SDK 模块划分、HAR 依赖接入、C# 与 ArkTS 双向通信，以及延迟启动和应用重启等常用方案。
崎径 其镜赵安琪的博客 · ZH
-
Unity 项目迁移鸿蒙（四）：联合登录报错 1002000001 排查
Unity 项目迁移 HarmonyOS 的系列教程（四）：排查鸿蒙联合登录错误码 1002000001，正确区分 AGC 项目级与应用级参数，并配置 App ID 和 Client ID。
崎径 其镜赵安琪的博客 · ZH
-
Unity Android 混淆踩坑：升级 AGP 后找不到 Java 方法
Unity Android 混淆踩坑：升级 AGP 后找不到 Java 方法。本文分析了 AGP 8.4 及以上版本的库模块缩减行为变化，并提供了混淆规则配置方法，确保 Unity 调用的 Java 方法在混淆后仍可访问。
崎径 其镜赵安琪的博客 · ZH
-
AI 时代，还有什么值得自己写？
我曾经是一个非常习惯做笔记、写文章的人。学习的时候，总觉得如果只是看了一遍而没有动手做点什么，就好像没有真正学到东西。 对于技术性的内容，可以通过动手实操来掌握；但对于知识型的内容，似乎只能靠输出——做笔记、写总结——来验证自己是否真的有所收获。 不过，“记笔记”这件事其实比较笼统。笔记至少可以分为两种：一种是 主观输出型 ，由自己思考、总结得出，能写出这样的笔记自然没什么问题；另一种是 摘录整理型 ，也是大多数人更常做的——把学到的内容摘录下来，最多做一些结构化整理。 这种摘录式的笔记，记下来似乎没什么意义：记完不过是堆在知识库里，不一定会再翻出来看，顶多是偶尔需要的时候去笔记软件里搜一下。但如果不记，又会有种不安感，好像没有学过一样。尤其是刷网课、看视频的时候，看完不留下点什么，总觉得白看了。这种矛盾感大概很多人都有。 AI 时代的冲击 到了 LLM 的时代，再回过头来看这个问题，笔记和博客还有写的意义吗？ 先说博客。以前我的博客更多是记录解决问题的过程——遇到一个技术问题，从网上搜集资料，自己整理出一套解法，写下来。比如一些早期的文章里就有这样的内容，那时候可能更喜欢把遇到的问题、学到的东西直接贴出来分享： Mysql 忘了 root 密码怎么办 Linux 文件系统中操作文件导致 NTFS 文件系统中文件丢失 Some Notes About SQLAlchemy 但现在，
YeungYeah 的乱写地 · ZH
-
深度使用语音输入后，还是得继续重视写作
本文使用古法键盘手搓码字 拥抱语音输入也有一段时间了 ，进一步深入使用后，还是真的爽，尤其是需要长文输入的场景里面，使用语音输入可以让自己没有拘束地输入大段文字，再加上使用 typeless 这种能够帮忙整理语音输入内容和句式结构的软件，使用体感非常好。 之前提到的一些问题，现在用多了再回头看来，其实也不太算问题了，或者说都有比较好的解法。 比如“需要挑安静环境”这件事，换了一些软件之后我才发现，有些软件其实可以过滤掉背景声音，或者明显和说话者无关的杂音。如果再配一个专门收音的麦克风，那就更不是问题了。 再比如准确率和所谓的 AI “加戏”。如果软件够强、模型够强，准确率其实还是相当不错。哪怕是专有名词或者英语单词，只要比较常用，识别效果也已经可以接受；如果还能维护词典，那体验就更友好了。之前所谓的 AI “加戏”，估计更多还是因为当时用的 LLM 模型还不够强。 最近刚好在准备面试，也会用 AI 来做问答和 mock 面试。在这种场景下，语音输入就更合适了，因为它更接近真实面试时的状态，可以直接一口气输出大段内容来作答。有些时候，在 AI 的润色加持下，一些自己本来答得没那么好的内容，被调整之后反而能串得更顺，补得更完整。 不过，用多了之后，有时候也会想：自己是不是开始产生依赖了？ 这种依赖，可能会影响自己的输出能力、打字能力，甚至成文能力。打字就不用说了，语音输入用得多了，打字
YeungYeah 的乱写地 · ZH
-
我的 RSS 与独立博客阅读史
我一直是 RSS 的老用户。早在建立个人博客之前，我就养成了用 RSS 订阅别人博客的习惯。所以我的博客一搭起来，就马上开启了 RSS 订阅源。 对我来说，RSS 一直不只是个订阅工具。这些年我读到的那些人、那些故事，基本都是从一条条 RSS 链接开始的。所以这篇想聊的，除了我用过的几个 RSS 工具，也想顺便说说，那些工具带我看到了哪些博客和哪些人。 RSS 之于我 在那段时期，RSS 基本上就是我的博客与其他博客之间的主要关联方式。这也跟我没加"友链"有关——我感知别人的更新、看到别人写了什么，基本都通过 RSS；反过来，别人想知道我写了什么，也是通过 RSS 来发现。 RSS 本质上是输出内容的索引。它维护一份像内容摘要或预告单一样的文件，供别人定期抓取。这非常有用，否则一个个去点开看别人有没有更新，工作量未免太大。 从 Feedly 到中文博客圈 最开始我用的是 Feedly。当时它的免费版好像支持 50 或 100 个订阅源。最初订阅的博客并不多，我都不太记得第一批是怎么找到的，可能是学校里的一些师兄。 后来我在 GitHub 上看到了一些"中文博客圈"或"中文独立博客"的 repo，可以提交收录个人博客信息和 RSS 地址。我把自己的博客提交了上去，也从上面找了一些比较多人关注的订阅源。 也正是从那时起，我读到了非常广泛的博客——不只是程序员，还有各行各业、各种年龄层的
YeungYeah 的乱写地 · ZH
-
Waline 数据源迁移记
起源：Valine + LeanCloud 博客最早期用的评论系统是 Valine.js。当时整套方案完全是前端操作，后端找一个 SaaS 提供对象存储服务。在 2017、2018 年左右，大部分博客系统推荐的都是 Valine.js + LeanCloud 这套组合 —— 存储免费、够用也好用，基本上大家都用 LeanCloud。 中途 Valine 爆出过漏洞。毕竟它是纯前端的，Token 之类的敏感信息都直接写在页面里，很容易泄露。一旦泄露，别人就能拿你的 Token 去读写数据 —— 更恶心的是，可以往里面乱写一通，直接把你的博客评论刷满无意义内容甚至危险内容。 漏洞出来后没多久，就有人在 Valine 的基础上做了一个新框架 —— Waline。主要改进有几点：在 Valine 上套了一层 Web 服务，可以直接跑在 Vercel 上；把敏感信息都放到了后端，所有数据操作都通过后端服务完成；另外还提供了一个管理后台，方便内容管理。 我当时也注意到了 Valine 的安全问题，所以 Waline 一出来我就跟着换了。当时博客主题还不支持 Waline，我自己手动改的支持，用着也算稳定。 至于 Waline 本身，体感反而一般，主要是 breaking changes 太多。最开始用的是 V1，后来升到 V2，按它的使用方式，客户端一直引用最新版本，而服务端是自己部署、版本写
YeungYeah 的乱写地 · ZH
-
当 AI 开始读懂我的健康数据
从怀疑数据记录开始 几年前，我曾经写过一篇 博客 ，吐槽自己对各种数据记录的执念。那时候我会记录很多东西：戴运动手表记录身体数据，用时间记录工具记录每天的行为和工作，也会关注一些健康指标。记录得越多，我反而越怀疑这些数据的价值。它们被保存下来之后，似乎很少真正被使用，也很难从中看出什么有价值的信息。 现在回头看，当时的吐槽有它的背景。数据本身被记录下来，并不等于它能自动产生价值。真正困难的地方在于：如何读取、整理、分析这些数据，并从里面发现一些对自己有用的规律。但在 AI 逐渐普及之后，这件事情的意义开始变得不一样了。 AI 让健康数据重新变得可用 最开始让我产生这个想法的，是在推特上看到有人把自己的 Apple Health 数据全部导出，然后用 AI 分析睡眠情况。AI 根据这些数据发现了他的睡眠问题，并给出了相关的建议，最后成功改善了睡眠质量。 这个例子让我意识到，健康数据的价值可能一直都在那里，只是过去个人很难高效地挖掘出来。 过去我也会定期查看 Apple Health 里的数据，但整个过程比较繁琐。每次都要点进某个单项指标，手动切换周、月、年等不同时间范围，再自己观察趋势、最大值、最小值和阶段变化。这样确实能看出一些表面变化，但观察范围很有限，也很依赖主观判断。 更重要的是，苹果的健康数据虽然记录得很完整，但某种程度上也相对封闭。之前我有一段时间换过安卓手机，那段时间的
YeungYeah 的乱写地 · ZH
-
给所有 Agent 加一层共享记忆
最近重新上班之后，在公司里大量使用 AI 进行工作和开发，使用强度上来后，消耗也多了很多。眼下最头疼的是：公司虽然提供工具和额度，但多且杂，没有一个足够好用、也足够用的。公司层面有自己的 AI 平台，部门又单独搞了一个，限额、可用性、排队都经常碰到。为了补这些缺口，我自己也自费买了一些订阅，可即便切到最高档的 Codex 猛用，一个账号也完全不够，还是得在多种工具之间来回切。日常工作里同时面对多个 AI 工具、多个模型和不同供应商，管理起来很乱。往后可能还是得用回公司内部的各种工具和模型；再加上公司所谓的保密要求，以后对外部模型大概也会有所限制——真要是自己的订阅用不了，切换只会更频繁。 更麻烦的是，对话内容、记忆和工作进展很难在这些工具之间同步。之前试过靠落文档来同步，每个内容都还得再通过对话传递一遍，效率很低。所以现在很需要一种能在不同 AI 平台和工具之间把这些东西带着走的办法。刷推特时看到有人在讲 Nowledge Mem，了解了一下，看起来还行。它的本质是在各个 Agent 之外建一层 Memory：Agent 启动执行前先通过 hook 去查 Memory，执行完再用 post hook 把内容更新回去。大家共用这一层，跟建一个统一的文档仓库有点像，但不用每次都手动决定该落下什么；有些内容也算不上知识，硬落只会又多又乱。 最近打算先在各个 Agent 里启用、安装一些
YeungYeah 的乱写地 · ZH
-
关于 AI 的一些随想
有了 AI 之后，都有点感觉不会写东西了，或者说已经不太会打字写东西了。自己的事情，用语音输入乱喷一通，然后交给 AI 做润色和结构调整，就能拿到成文的内容。工作的时候，不方便语音输入，很多时候也只是简单打几个字词拼凑下，然后就让 AI 去组织生成一篇完整的文章，很多时候都是先让 AI 写好，然后自己微调而已。要不是重新工作的话，感觉打字表达这个能力还得继续退化。 之前看到一个挺有意思的 meme 图还是段子，说的就是 AI agent 盛行之后，很多很简单的事情，人们都不会自己去干，而是选择丢给 AI 去做。比如自己去干可能只是一两分钟，丢给 AI 的话，AI 思考调用执行一通，时间其实差不多，甚至还可能更多，因为 AI 还可能会做错。但是人还是会不愿意做，比如当前有些时候，可能发现问题改几行代码，或者改个变量，几秒的事情，或者 push 一下分支，也是点一点的事情。但就这种操作，还是丢给了 AI，用尊贵的 gpt5.6-sol 去做一些简单的操作，耗时还更长。 用进废退，长久下来，个人技能是否会彻底退化呢？之前有段时间其实在想，智能时代来临之后，对于我们这种技术人员、研发人员，核心竞争力到底是什么？技术壁垒已经被大部分消除掉了，那以后就比拼谁更会用 AI？其实之前还真的有这种想法，甚至还专门和 AI 讨论过，当前智能时代，到底要 train 些什么，培养些什么能力，然而讨论完就
YeungYeah 的乱写地 · ZH
-
共享记忆，最后还是落回了文档
上次写了篇 给所有 Agent 加一层共享记忆 ，当时还挺期待几个 Agent 共用一层 Nowledge Mem 会是什么效果。结果用了一段时间，还是放弃了，最后又绕回了比较土的办法，就是写文档、搭个知识库，感觉反而更方便一些。 Nowledge Mem 没用起来 Nowledge Mem 的思路其实是没问题的，每次对话前先去查一下 Memory，执行完再把内容写回去，专门搞一层来管记忆。但实际用下来，经常断连，有时候 hook 根本没生效，说好的自动写入也没怎么写，基本上没感觉到有什么效果。而且整个东西有点重，每轮对话都要先查再写，对话节奏被拖慢了，任务跑起来也慢。用着用着就觉得没必要了，干脆卸掉。 卸掉之后问题还在，还是得找个办法。想了想，其实工作上一直在用的办法就挺好使的。 工作上：让 Agent 写成飞书文档 回到最开始的问题，其实就是多个平台、多个 Agent 之间，上下文和记忆怎么共享。工作上现在的做法比较简单，就是让 Agent 把它知道的东西写出来，整理成飞书文档分享出去，写得足够细，不管是人还是别的 Agent 拿到，照着文档走就能复现。公司里有飞书的 Skill，AI 工具配上之后就能直接读飞书文档。飞书在这里只是个载体，里面装的大多是一些经验、方法和指引，某件事怎么做、某个平台怎么用、某个流程是怎么走的，传来传去，比在对话里一遍遍重新讲要省事很多。 工作上这
YeungYeah 的乱写地 · ZH