Xie Yanbo retweeted
Weekend hack: HackerTube. I was annoyed with YouTube's recommendations so I had Claude filter down 43M comments over 20 years of HN to 6,454 videos that keep being recommended. *Significantly* better viewing experience, ~2 hours with Opus 5.5:
hackertube.org/
- Excellent recs without any logins (state is kept in local browser session)
- Thumbnail is a representative frame from middle of the video instead of the super duper A/B test hyper-optimized user uploads
- Underlying data from the comment analysis as one zip file, point your Claude at it and ask for your own version
- HackerTube Longs ✊
A bit more on the process:
I use Claude Code (desktop app for Mac), Opus 5.5 on Medium effort as my default. I only talk to Claude and have it do everything, the only "manual work" I helped with in tandem was in the browser (reminiscent of MenuGen): 1) I had to create some kind of API key from Google Cloud UI to query YouTube for video metadata, 2) I booted up a VPS box for serving and 3) I bought the domain name. Once the box was up I gave Claude the IP and told it update, secure, harden, deploy and optimize the code, and it did the whole thing.
Many awesome projects that would have normally taken weeks/months even can now be few-shotted for breakfast. What else are we not thinking of.
Xie Yanbo retweeted
RAG 又杀回来了。
最近 Agent Memory 越做越复杂，但这篇《Memory Tax》发现了一个挺尴尬的结果：
很多专门设计的 Memory 系统，最后还不如直接对 raw history 做 RAG，而且成本更高。
作者把 Memory 的价值拆成两部分：
Memory Benefit：RAG 答错，但 Memory 答对的问题。
Memory Tax：RAG 本来能答对，经过 Memory 处理后反而答错的问题。
问题就出在「整理记忆」这一步。
历史被摘要、重写和结构化以后，一些细节会直接丢失；另一些虽然还在，却变得更难检索。
比如在 LongMemEval 上，Qwen3.6-27B 用两轮 RAG 能做到 81.4%，GPT-5.6 Luna 达到 90%，都高于对应的复杂 Memory 方案。
一个简单的修补反而很有效：
Memory 继续用，但同时保留 raw history 的检索通道，再把两边结果一起 rerank。
这篇工作也给我们做了一个提醒，给 Agent 加 Memory 之前，最好先拿最简单的 raw-history RAG 做个 baseline。
有时候，真正昂贵的并不是「没记住」，而是过早把原始信息总结掉了。
📎 arxiv: arxiv.org/abs/2610.34073
Xie Yanbo retweeted
这条推文的建议很好，但"把压缩调到 400K"对每个人都成立吗？不一定。
这就是 magpie 要做本地 agent 可观测性分析的原因。每个 agent 都有自己独特的行为，每个用户也有自己的使用习惯，任务难度也因人而异，所以不存在一份对所有人都最优的配置。
更麻烦的是，每个 agent 的配置项又多又复杂，还藏得很深。大多数人压根儿不知道有这些开关，就这么不知不觉地用着最不适合自己的配置，浪费了大量时间和 Token，甚至牺牲了完成任务的质量。
magpie 新功能「为你调优」：在本地用你自己的真实调用，按每个 agent、每个模型去回放压缩阈值和缓存时长，算出对你最省 Token 的那一组。千人千面，但对每个人都是最省的。
最近用 Claude Code 跑长任务经常感觉 5 小时额度像流水一样掉？之前社区甚至有人吐槽它根本没做上下文压缩，暗地里疯狂塞 token。今天看了 Anthropic 官方工程师 Lydia Hallie 的详细解释，才发现大家都误解了它的机制，实际问题出在默认策略太激进。
很多人不知道，auto-compact 其实是真正在做摘要的。只要一触发，前面所有的历史记录都会被一段很短的 summary 直接替换掉，根本不会在上下文里保留上百万的冗余内容。
那为什么大家的配额还是崩得飞快？ 关键在于 1M 上下文模型下，系统默认一定要憋到将近 967K 才会启动自动压缩。这就很要命了——在憋到 967K 之前的那段漫长对话里，你发过去的每一句话，背后都在默默拖着七八百 K 甚至近百万 token 的庞大上下文。即便大部分命中了 Prompt Cache 且读取单价很低，但只要基数膨胀到这个量级，每一轮对话依然在疯狂蚕食你的 5 小时用量。
还有人纠结“压缩会导致前缀改变、缓存失效，重新写一遍岂不是血亏”。其实完全不会。生成摘要本身走的大多是热缓存读取，失效之后你只需要为那段极短的新摘要付一次小额的 Cache Write，换来的却是后续交互基数直接腰斩，长远来看绝对是划算的。
不想额度莫名其妙被吞完的话，建议赶紧顺手做两个调整：
平时在终端直接敲个 /autocompact 400k，或者在 ~/.claude/settings.json 里配置好 autoCompactWindow，强制它提前压缩，别让上下文滚雪球滚到 900多K。
另外个人订阅的缓存保活时间默认是 1 小时，但后台子代理（subagent）只有 5 分钟。如果写代码停顿久了，缓存冷掉重写确实心疼，有需要可以在配置里改一下 promptCacheTtl 和 subagentPromptCacheTtl。如果主会话跑的是 Opus，顺便把后台打杂的 subagent 换成更轻量的模型，额度立马耐用很多
Xie Yanbo retweeted
@mattpocockuk's skills repo has more stars than React, and the most installed skill is one line long.
I animated how his whole workflow works, from /grill-me to /retro
Xie Yanbo retweeted
At the top of my AGENTS.md:
- NEVER write unit tests after you write code.
- Highly prefer E2E tests as the sole testing mechanism. Use them to verify complex features work. At the end of E2E tests, produce a verifiable and repeatable artifact.
- If you must test a system in isolation, FIRST write all the ways it could fail, THEN write the code.
Xie Yanbo retweeted
Qwen3.8-27B 低于 3 bpw：我们发布了 2.96 / 2.48 bpw 两个 GGUF 版本，文件仅 9.71 / 8.20 GiB，均包含 MTP，AIME 2026 实测均为 100%。支持 MTP
视觉编码器完成瘦身（已解决 GGUF 量化兼容问题，无需修改 llama.cpp 即可推理。）：Qwen3.8-27B 的 Q4_K 版本仅 314.46 MiB，比 BF16 小 64.59%，与原始 HF FP32 视觉输出的 cosine 相似度达 0.99537。
开源 huggingface.co/drawthingsai/…
Xie Yanbo retweeted
github.com/projecteru2/quick… 拿去玩吧…一个调度平台，三类不同资源，完全统一…哦对了当年在 S 社，包括全东南亚最大的中间件集群，就是这玩意驱动的，什么 K8s，路边一条
我把 AI 使用的信息分成两个层面：想清楚的结论继续放 obsidian，当下高频检索、修改的过程内容交给 worklog。它是专门给 agent 设计的，基于命令行，命令简短、输出省 token，所有信息有机关联，变为结构化存储，可以高效检索。项目地址 github.com/xyb/worklog
我最开始还是保持以前的习惯，只是换成让 AI 把计划、过程都记进 Markdown，但是过了几个月就发现难以为继：几个 Agent 一起写同一个记录文件会互相覆盖，文件越来越大每次都得重读，想理清思路、做计划和总结又得把整个几百 KB 的文件全读一遍，每天要浪费很多时间和算力。
自从变成全程只说话、让 AI 干活之后，越来越发现obsidian 作为第二大脑存在的缺陷，干脆写了一个命令行工具，叫 worklog，让 agent 一边干活一边把计划、进展、决策都记进去。有了这个工具，工作效率明显高了很多。
Xie Yanbo retweeted
Announcing mattpocock/skills v1
- Achieved a 63% reduction in token cost for skill descriptions
- Split skills into model-invocable and user-invocable skills, adding /codebase-design, /domain-modeling, and /grilling
- (UPDATED) /writing-great-skills - rewritten from the ground up, encoding my skill-writing best practices
- (UPDATED) /diagnose -> /diagnosing-bugs - now model-invocable, awesome for fixing hard bugs
- (NEW) /ask-matt: a router skill that teaches you how all the engineering skills work together
