AI 编程助手通常会假设用户的意图并直接执行。有时这样做很快；但往往意味着花更多时间在撤销操作上，而不是实际执行。<p>Epistemic Protocols 是一个 Claude Code 的插件，它在不可逆操作之前、存在多种方法时或意图可能被误解时插入决策检查点。<p>三个协议：
- /lens — 在分析之前，让你选择视角（性能、操作复杂性、数据模型适配等）
- /gap — 在决策点，提出潜在的差距作为问题
- /clarify — 当你的请求可能模糊时，帮助明确意图<p>原则：AI 照亮选项；你来选择。识别优于回忆——从明确的选择中选择胜过猜测。<p>GitHub: <a href="https://github.com/jongwony/epistemic-protocols" rel="nofollow">https://github.com/jongwony/epistemic-protocols</a><p>示例：
```
> /lens "我应该使用 Redis 还是 PostgreSQL 作为这个缓存？"
```
Claude 显示出视角（性能、操作复杂性、数据模型适配……）。你选择重要的内容，然后它通过这些视角进行分析。
返回首页
最新
archive.today 最近（我大约三天前注意到的）开始自动向某个人的博客的 CAPTCHA 页面发起请求。以下是我所说内容的截图：https://files.catbox.moe/20jsle.png
相关的 JavaScript 代码是：
```javascript
setInterval(function() {
fetch("https://gyrovague.com/?s=" + Math.round(new Date().getTime() % 10000000), {
referrerPolicy: "no-referrer",
mode: "no-cors"
});
}, 300);
```
查看这个博客，似乎只有一篇文章提到 archive.today——“archive.today：追踪互联网神秘游击档案员”（https://gyrovague.com/2023/08/05/archive-today-on-the-trail-of-the-mysterious-guerrilla-archivist-of-the-internet），在这篇文章中，博客的作者挖掘了一些关于 archive 拥有者的信息。
所以这或许是一种报复/拒绝服务攻击尝试/故意浪费他们带宽以回应这篇文章？也许是试图让他们沉默并迫使他们删除文章？但如果真是这样，我有很多疑问。比如，为什么 archive 的拥有者会在文章发布 <i>2.5 年</i> 后才这样做？或者他们为什么会这样做，他们难道不知道斯特赖桑效应吗？
我很困惑。
请访问以下链接： [https://github.com/stepandel/chroma-explorer](https://github.com/stepandel/chroma-explorer)
在进行机器学习特征工程和多组学数据处理时，我遇到了一个实际限制。
在某个时刻，问题不再是“有多少行”，而是“有多少列”。列数从几千到几万，有时甚至更多。
我在实践中观察到：
- 标准SQL数据库通常限制在大约1000到1600列。
- 像Parquet这样的列式格式可以处理宽度，但通常需要Spark或Python管道。
- OLAP引擎速度很快，但通常假设相对较窄的模式。
- 特征存储通常通过将数据拆分为连接或多个表来解决这个问题。
在极宽的情况下，元数据处理、查询规划甚至SQL解析都会成为瓶颈。
我尝试了一种不同的方法：
- 不使用连接
- 不使用事务
- 列分布而不是行
- 将SELECT作为主要操作
通过这种设计，可以在具有数十万到数百万列的表上运行原生SQL选择，并且在访问部分列时具有可预测的（亚秒级）延迟。
在一个小集群（2台服务器，AMD EPYC，每台128 GB内存）上，粗略的数据如下：
- 创建一个100万列的表：约6分钟
- 插入一个包含100万值的单列：约2秒
- 在约5000行中选择约60列：约1秒
我很好奇这里的其他人是如何处理超宽数据集的。你们是否见过在这种宽度下能够顺利工作的架构，而不需要依赖繁重的ETL或复杂的连接？