Description： AI 聊着聊着就犯傻、Skill 成功率忽高忽低、复制别人的配置却跑不出同样的效果——这些问题的根源往往是同一个。理解上下文窗口，是用好所有 AI 工具的第一课。 像对待你最宝贵的注意力一样，对待 AI 的上下文。 前言：这些问题，你可能都遇到过 和 AI 聊了二十几轮，它开始前后矛盾，甚至忘了你五分钟前说的话 让 Agent 跑同一个流程，有时候一次过，有时候莫名其妙失败 把一大段数据扔给 AI 做分析，结果答非所问，或者分析得驴唇不对马嘴 同一个 Skill，换个模型结果完全不同；同一个模型，这次成功下次又失败 原来运行正常的 Skill，安装了更多 Skill 之后反而开始出错 完整复制了别人的 Agent 配置和工程设定，实际效果却和演示差了十万八千里 Meta 安全总监的 AI 助手帮他删光了所有邮件——因为对话太长，上下文压缩时丢失了安全限制 如果你有过类似的经历（或者担心类似的事发生在自己身上），这篇文章可能会帮你找到根源。 这些问题看起来五花八门，但往往指向同一个原因——上下文窗口（Context Window）。简单说，它就是 AI 的"工作记忆"，是它在回答你时能同时"看到"的所有信息的总量。这个空间是有限的，而且远比你想象的脆弱。 理解上下文窗口，是理解当下所有 AI 工具的钥匙。不论你是在用 ChatGPT、Claude，还是在搭建自己的 Agent 自动化流程，这个概念都是绕不过去的第一课。 Harness Engineering：为什么我没有追最新的潮流 业界当前最热门的方向叫 Harness Engineering——它的目标是让 AI 系统能自动纠偏、自动迭代，全程最小化人类干预。它包含上下文工程、架构约束、自动化反熵等多个支柱，确实是一个很有前景的方向。 但坦白说，目前即便是最顶尖的团队，也还处在探索阶段。OpenAI 声称部分内部系统中 90% 的代码由 Agent 编写无人类参与，但这离普通人在日常工作中可以直接复用，还有相当的距离。 而如果你去拆解 Harness Engineering 的底层，会发现它的第一根支柱就是上下文工程——把正确的信息以正确的方式喂给 AI。所以与其追一个还在演进中的顶层框架，不如先把最底层的东西理解透。地基打好了，将来理解上层建筑也更容易。 本文聚焦的，就是这个地基。 一个贯穿全文的比喻：你的工作台 为了让后面的内容更好理解，我们先建立一个比喻——把 AI 的上下文窗口想象成一张工作台。 工作台的面积是有限的（上下文窗口有上限） 桌上堆的东西越多，你越难找到关键资料（噪声导致输出质量下降） 桌子越大，租金越贵——而且不是线性增长（成本问题） 聪明的做法是把资料分类归档到抽屉里，需要时再拿出来（渐进式披露） 脏活累活可以让助手在另一张桌子上干，只把结果递过来（Sub-agent 隔离） 每天重复的手工活，应该想办法变成一台机器自动跑（流程工具化） 后面的每一个方法论，都可以回到这张工作台上来理解。 ...

上个月写了一篇《LLM 吞噬一切，我用 AI 长出来的那些工具》，聊了聊过去一年多我用 AI 给自己造的那套信息处理体系。反响还不错，收到了不少反馈。 但写完之后总觉得意犹未尽。那篇更多是在讲"我做了什么"，而这段时间脑子里一直转的，其实是一些更虚的东西——关于 AI 怎样影响我们的生活、社会关系、乃至人的价值定义。这些想法比较零碎，层峦叠嶂的，跟朋友聊过一些，姑且一并写下来，算是闲言几则。 先交代一下背景。尽管我分享了不少技术相关的东西，但本质上我对编程这件事没有狂热的热爱，始终只是拿它当实现目标的工具。我的代码水平长期停留在"脚本小子"的层级——大学学过一点 C++，对底层数据结构有基础了解，平时用 Python 写写脚本，但也仅此而已。语言底层那些语法、规范实在太烦人，我没那个耐心去深入学。我只想问一句：能不能直接帮我把功能实现了？ 所以在很长一段时间里，我都是用各种自动化工具组合来解决问题。Windows 上的 Quicker（也是我没用 Mac 的唯一原因）、Android 上的 Tasker、iOS 上的捷径——这些自动化软件就是我之前的主要手段。写代码？更多只是拼接一些现成的代码片段，来回调试。 一、我和 AI 协作的这一路 ChatGPT 出来之后，写脚本确实方便了很多。脚本这种东西目的明确、体量小，基本上在对话框里就能搞定。但那时候想写一个完整的工程项目还是很困难——单纯的 Chatbot 缺乏对项目全局的了解，运行日志要手动粘贴给它，如果你自己都不了解项目底层，想把一个项目 run 起来都费劲。困难更多是耐心层面的，夹杂着知识框架上的缺失。 不过那个阶段已经可以写一些稍微复杂的脚本、Chrome 插件之类的了。 后来 GitHub 出了 Copilot。很多情况下它的 Tab 补全准确率非常高，函数级别的功能基本上定义好输入输出，一路 Tab 就行。但此时还是需要你对相关框架和语法有基本的了解。 再后来 Cursor 出来了，体验有一个跃升。在 IDE 里面它能调用更多工具，拥有更多项目上下文和日志信息。此时完成一个中小型项目已经有非常大的效率提升了。 然后就是去年大概三四月份，Claude Code 的口碑慢慢起来了。最开始我对这种 CLI 工具（命令行工具，没有图形界面，纯文字交互）还是有些心理门槛的，觉得不如 IDE 直观。但用了以后就真的回不去了。慢慢地 IDE 就只剩一个功能——查看项目结构，选择重要文件，复制相对路径提供给 Claude Code 来构建它的上下文。其他功能都没太多意义了。因为 Claude Code 自己能做的越来越多，每当它需要人类介入的时候，你总会去想：凭什么这个事情要让人类来做？ 严格意义上讲，过去一年我应该没有写过一行代码，但 GitHub 的提交次数却越来越密。基本流程就是：有想法 → 跟 Gemini 做 Deep Research 调研可行性 → 找参考项目和文档 → 精选上下文 → 跟 Claude Code 开聊 → 不断描述需求和问题 → 迭代。 ...

过去一年多，我用 AI 给自己写了不少工具。从一开始只是想解决某个具体的小问题，到后来不知不觉搭出了一套还算完整的信息处理体系。 今天分享的内容在当下会有一些价值。不过这个价值更多是在于思路上，具体的代码其实没有那么重要。按当前 Coding Agent 的发展速度，恐怕过几个月，当前的这些代码就一文不值了。 下面我按层次来介绍。先讲我造的那些工具，再讲支撑它们运行的基础设施，最后聊几点这一年折腾下来的想法。 全景概览 图 1：信息流主线（采集 → 处理 → 存储 → 回顾） 图 2：基础组件与硬件（谁跑在哪，谁调用谁） 这套体系不是一次性设计出来的，是过去一年多时间里根据实际需求一点点迭代出来的。简单来说，信息的流向大概是这样的： 采集 → 过滤筛选 → 转录/理解 → 存储管理 → 回顾分析 每一层都有对应的工具在支撑。下面逐个介绍。 处理系统 AI Information Processor —— 统一的信息处理中枢 每天要面对大量的文章、图片、音频、视频，信息过载严重，人工筛选完全不现实。最初是从范冰老师那里学到的思路——把所有文本内容走一条统一的 Pipeline，用 AI 打分过滤。 我在这个基础上做了两点迭代：一是把处理范围从纯文本扩展到所有内容形式——图片、音频、视频都先转换成文字（虽然现在很多模型都有多模态的能力，但不论从成本还是效果上看，文字都是最优选择），然后走同一条管线；二是增加了事件聚类去重。具体来说，管线做两件事： 第一是打分过滤。按一定的规则给内容打分，分数不够的直接剔除。系统会用 AI 对内容做结构化分析——分类、评分、简单摘要、提取水下信息——然后根据评分阈值过滤。此部分 AI 工作流会以 API 的形式暴露给其他工具使用（比如长文本的主动剪藏）。 第二是事件聚类去重。对所有内容做 Embedding 向量嵌入（用的 text-embedding-3-small，非常便宜），计算相关性，剔除针对同一个主题、不同信息源的重复内容。这里有一套三级通知降噪机制：相似度低于 0.85 的视为全新事件，完整推送；0.85 到 0.97 之间的视为增量更新，只推送新增信息；超过 0.97 且实体高度重合的，直接静默。一个事件簇如果连续 7 天没有更新，会自动归档。 热点的信息，多个信息源会同时报道，所以此时会做一个去重来提取增量信息。 信息采集方面，系统对接了多种 RSS 源： ...

前几天参考 中国人申请美国EIN几个方法-VPS大玩家 打电话申请了 EIN，此处做一个记录。 虽然我有 ITIN，但申请 EIN 实际上无需 ITIN ，也无需创办公司。 ITIN -网络申请：原则上可行，实际不行 秉承着能线上解决就不打电话的思想，我首先尝试通过在线填表的方式来申请 EIN。 打开 雇主身份识别号码 (EIN) 在线申请 | Internal Revenue Service 这个网站，按流程操作。 这里我没有遇到大玩家里所说的输入 ITIN 后会出现错误提示，我输入 ITIN 后正常进入下一步填写 “Address” 的步骤，但这里就很蛋疼了，此处它询问的是： Where is the Sole Proprietor physically located? 网申地址只能填写美国 而有 ITIN 的我肉身是在中国，但此处只允许填写美国地址。 填写租用的美私地址倒也能下一步，但为了防止以后出麻烦，我还是放弃了网申的方案。 通过电话申请 EIN 打电话总共用时 30 min，这里建议还是比较推荐 Chrome + Google Voice 的方式。两个原因： 用 gv 可以 0 成本 Chrome 支持 Live Caption + Live Translate，实时语音转文字的效果还是比较准的，可以有效降低沟通门槛（方法见文末）。 接线的是一位大妈，很有耐心。中间填报地址的时候她听不清我翻译的中国地址，所以她主动提出叫一个翻译加入对话。 这里如果你没什么信心的话，可以开始的时候就直接就跟她说：“I want a Chinese translator.” ...

背景 前阵子女朋友去读研，授课是全英的，加之又有很多专业名词，有时就会出现理解能力跟不上讲课速度的情况。 因此借助课堂回放/录音复习也变成了一项每周必做的工作，但是完全回看一个三小时长的课程显然是不现实的，所以，音视频转文字就成了必选项。 方案选择 商用 ASR 服务大多难以实现高精度转写 我是飞书妙记的会员，所以遇到了这个需求，我马上想到先用妙记试试。 然而，尝试转录的结果表明，妙记在专业课程上的转录准确度相当差，无法满足通过文字转录来提高复习速度的需求。 妙记转录结果：词汇未转录、转录错误问题频发 其他商用服务(如通义听悟、讯飞听见、Notta 等)的转录效果和飞书妙记差不太多，大体原因有三点： 手机远距离收音比较差，音频文件质量不高。 一般的商业自动语音识别(ASR-Automatic Speech Recognition) 服务主要面对会议等日常场景。但若音频内容含有过多的专业词汇，此类 ASR 服务则有点力不从心了。 商业 ASR 服务需在速度、准确性和成本之间取得平衡，高准确度通常需要以成本变高、速度变慢作为代价。 基于问题 2 和 3 ，我放弃了继续寻找其他商业 ASR 服务的想法。 Whisper 的惊艳效果 因为平时业务里我自己基于 OpenAI 发布的 Whisper API 写了不少工作流，所以我又试了试 Whisper(Large-v2)的转录效果。——非常惊艳，甚至连符号的写法(theta_i^t)它都转写了出来。 Whipser LargeV2 转录结果：精度高到甚至照顾到了符号写法 这里简要介绍一下 Whisper，Whisper 是 OpenAI (没错，还是 chatGPT 背后的公司)在 2022 年 9 月开源的音频转文本的模型，它的转写精确度非常高。 但想使用 Whisper 进行转写也并非易事。它有两种实现方式：云端 Or 本地。 云端转写的优势在于不会受到本地机器性能的限制，且速度相对较快。但它存在两个问题： 项目处理流程复杂：OpenAI 的 Whisper API 限制单次请求的音频大小为 25Mb，而一节 3h 的音频通常都会有大几十 MB。这就需要对音频先做分段处理，再请求结果，最后合并结果。如果是 mp4 文件则还需要从中抽取音频文件，这个过程里没少踩坑。 成本问题：OpenAI 的 Whisper 模型 1min 收费 0.006 美元，1h 的音频按照 7.3 的汇率需要收费 2.7 元。坦白讲，Whisper 的 API 价格非常便宜了，几乎只是 Google Speech2Text API 的四分之一。但是，如果我们假设有 5 门课程，每堂课长 3小时，每周有一次课，那么每个月的转写成本 = 5 x 3 x 4 x 2.7 = 162 元，这个价格还是有点肉疼。 本地转写的话倒是没有上述两个问题，但本地转写的麻烦之处在于： ...

今天测试 Memo 的翻译服务，发现经常失败，于是想抓包看看失败原因。 很自然的打开了电脑上的 Fidder，但出乎意料的是完全抓不到 Memo 的任何 Http 请求…(已开启 https 抓包，其他软件测试正常) 搜了一下，发现可能是由于 Electron 的缘故。 于是又参考 抓包经验总结（一） - 知乎 尝试使用 wireshark 来抓包，但无奈 wireshark 里面信息太多了，我光通过 ip 和协议过滤还是有大量请求…遂放弃。 后来搜到了 Electron应用抓包_electron 程序 抓包-CSDN博客 这篇文章。 code.exe --args --proxy-server=localhost:8888 --ignore-certificate-errors 我拿 Fidder 测试了一下，发现可以抓取到 Memo 检测更新的请求，但是依旧抓取不到翻译的请求。。 接着按照 Electron抓包体验-CSDN博客 的思路，在 Chrome 里调试 Electron 应用。 Memo.exe -remote-debugging-port=9222 然后用 Chrome 打开 chrome://inspect/#devices Console 里有输出，network 里没有 尴尬的是，能看到 Console 里输出了翻译的记录，但在 Network 里没有发现任何 http 请求。。 最后用英文搜了一下，最终找到了解决方案。 Download HTTP Toolkit for Windows HTTP Toolkit 抓取 Electron 应用 ...

测试设备 Windows 微信 3.7.6.44 Android 微信 8.0.34 红米 K50，MIUI 13 背景 我有一个持续了三年的习惯——每周备份当周的微信聊天记录。但微信的备份功能做得实在是很烂，经常遇到网络问题： 当前网络状况复杂，请尝试使用其他网络 提示手机和电脑的网络不一致( 明明都在同一个 WIFI 下，备份界面显示的网络名字也一致) … 在互联网上搜了一下，解决方案也无非是： 重启微信/手机 给予地理位置权限(Android)/给予 Local Network 权限(iOS) 但实操下来不能百分百解决问题。 真正的解决方案 按照下面的步骤来操作，我这里从未失败过。 前提 手机和电脑在同一个 WIFI 下面(2.4G 和 5G 最好区分开) Android 给予了微信定位权限(因为定位权限里包含部分 WIFI 的信息)，iOS 给予了微信 Local Network Access 权限 Android 的定位开关为开启状态。 遇到网络问题，提示无法备份 Kill 掉微信的进程，要到应用信息页面『结束进程』，在 MIUI 上是『长按图标』=>『应用信息』=>『结束运行』 微信 PC 版本点击『迁移与备份』=>『迁移』(没错，先使用迁移，而不是备份)。 迁移一个体积很小的聊天记录，让手机和电脑之间完成通信过程。 等待迁移成功后，点击『备份』，通常这时就不会有网络问题了。 如果还是无法解决？建议重新检查上面的步骤。

很早之前在 Win10 遇到的和 H265 相关的问题是不显示缩略图，解决方法往上比较成熟，安装Download K-Lite Codec Pack 即可。 最近业务需要，通过『要你命三千』从抖音/快手上下载了很多无水印的视频，其中一部分是 H264 编码，另一部分则是 H265 编码，在 Win10 文件管理器中预览不成问题。 但好死不死的，我需要把它们统一拖进 Eagle 进行管理，Eagle 目前只能支持 H265 的收藏，但是不支持 Eagle 预览播放==… 所以我需要把 H265 的视频转换成 H264，转换倒也不复杂，使用 HandBrake: Open Source Video Transcoder 就行。 但问题是，怎么从 H264 和 H265 混合的视频文件夹里找出 H265 的视频文件呢？不然视频数量一多，H264 相当于白白浪费转换时间。 Finding which videos in a directory of various videos are H.265? - Page 2 - Windows 10 Forums 英文搜索倒是找到了相似的问题，可惜当时没有解答。 几经尝试，最后还真找出了解决方案： 安装 Icaros 3.3.0 Beta 3 在文件管理器中勾选『Video tracks』列 Snipaste_2022-07-14_00-08-21 以上。 ...

昨日晚上在外面吃饭时发现有两个比较感兴趣的老师都在视频号做直播，两边的内容都想听，但无奈只有一台手机，也没办法确定之后是否有回放，遂生下载微信视频号直播随后观看的想法。 下载微信视频号直播大体可以分成三步： 抓包获取视频号直播推流地址 调用下载器下载，最后生成一个 flv 文件 将 flv 转码成 mp4 文件 抓包获取视频号推流地址 核心是在各个平台上设置 https 抓包，推流的 URL Host 为 http://voipfinderliveplay.wxqcloud.qq.com，按这个地址过滤就可以直接找到可以下载直播视频流的 Url。 Windows 平台 Fiddler配合Proxifier抓包PC客户端HTTPS明文数据 - 飘易博客 在电脑上打开直播的视频号，使用 Fidder 抓包。 可以用 ‘@voip’ 过滤 Android Android 7.0 + 抓包比较麻烦，要么需要 Root 迁入证书，要么使用平行空间等创建一个虚拟环境来抓包。我自身手机是 Root 过的，就直接将 http canary 的证书迁入系统即可。 安卓11 httpcanary小黄鸟系统证书的安装_哔哩哔哩_bilibili http canary 安装完毕后，针对微信抓包即可。 iOS iOS 上抓包 https 相对来说非常简单，我是使用 Stream 来完成的。 IOS抓包工具Stream——让移动端的抓包变得轻而易举 - 温一壶清酒 - 博客园 调用下载器下载 flv 文件 原则上在什么设备上拿到了视频号地址，那可以直接在对应的设备上使用下载器下载。 但手机的网络不太稳定，所以我更倾向于统一用电脑下载，在电脑上我使用的下载器是 IDM。 ...

最近入手了一台米物 Art 键盘，上面有一个语音唤醒键。但是在 Win10 上，它默认唤醒的是小娜(Cortana)，众所周知小娜在 Win10 上基本没用，所以自然产生一个想法：怎么把唤醒的小娜替换为小爱同学？ 首先通过键位监测发现，键盘的语音键实际上是模拟了 Win+C 的命令实现调用小娜，那问题就转变成：如何使 Win+C 唤醒的是小爱同学？ 自定义快捷键的应用我一直使用的是 HotKeyP，本来想直接添加一个命令行打开小爱同学的命令，但尴尬地发现小爱同学是 UWP 应用，没有 .exe 的文件，也没办法通过快捷方式调用。 所以问题又转换成了：如何通过命令行唤醒 UWP 的小爱同学？ How to open UWP apps from the command line on Windows 10 搜寻一番，通过上述文档找到了解决办法。 explorer.exe shell:appsFolder\8497DDF3.639A2791C9AB_kf545nqv09rxe!App 但往 HotKeyP 中添加热键的时候又出现了新的问题： 没找到直接调用命令行的方法 问题又转变成：如何使 HotKeyP 可以直接执行命令行？ 方法也很自然，将命令写成 .bat 脚本存放在磁盘里，用 HotKeyP 调用此脚本。 但实验起来发现执行 .bat 脚本时会有一个黑色的控制台闪过，非常不爽。搜了一下怎样让 .bat 隐身运行。 全网最详细，bat不弹黑框/不显示控制台方法_时过境迁一样美的博客-CSDN博客_如何运行bat文件不弹出黑框 所以再使用 .vbs 命令执行 .bat 脚本就可以避免黑框。 所以最终用小爱同学替换小娜的路径就明确了： 用 HotKeyP 给 Win+C 快捷键绑定上执行 .vbs 命令的脚本，.vbs 脚本无控制台调用 .bat 脚本唤醒小爱同学 UWP 应用。 ...