嗨，HN。标准广义相对论认为时间膨胀仅由质量-能量引起。但当信息熵达到临界密度时，会发生什么呢？
我发布了我的论文版本2.0，提出了信息诱导时间膨胀（ITD）假说。
假说：
我提出局部信息熵（\Delta S_{info}）作为时空度量的“计算负载”。就像质量使时空弯曲一样，极端的信息密度可能会使局部时钟出现“滞后”。
实验（严格可证伪）：
为了验证这一点，我设计了一种使用铷-87光学晶格钟的差分测量（第6节）：
比较：一个处于GHZ纠缠态的系统（高信息）与一个处于乘积态的系统（低信息）。控制：质量和能量保持相同。预测：如果我的推导是正确的（\alpha \neq 0），那么纠缠部分将相对于对照组显示频率红移。
完整论文（Zenodo）：
[https://zenodo.org/records/18027729](https://zenodo.org/records/18027729)
需要帮助：
我希望能得到对实验设置的反馈。
主要的工程挑战是保持GHZ相干性足够长的时间，以便将效果与环境噪声隔离开来。
如果您在量子计量学方面有专业知识，我将非常感激您的技术见解。
（可选）请求ArXiv支持：
支持代码：E3Y83D（physics.gen-ph）
返回首页
最新
所有开发应用程序都使用9092端口，当我在前台或后台使用Antigravity时，它与我的其他程序发生冲突。谷歌，你在干什么？？
像Claude Code这样的AI编码代理可能会产生危险的命令。错误的路径、错误的目录，突然间你可能会执行“rm -rf ~/”而不是“rm -rf ./”。我开发了Leash来在这些错误执行之前捕捉到它们。
Leash是一个简单的钩子，在每次工具调用之前运行。它会阻止在工作目录之外的危险命令，保护项目内部的敏感文件，如.env和.git，并停止像reset --hard或push --force这样的破坏性git操作。
一些最初不明显的情况也由它处理：代理执行“cd ~/Downloads && rm -rf folder”以逃离沙箱，复合模式如“find -delete”或“xargs rm”针对项目外的路径，以及基于符号链接的逃逸。
它与Claude Code、OpenCode、Pi和Factory Droid兼容。设置只需执行“npm install -g @melihmucuk/leash”，然后运行“leash --setup claude-code”。
这不是一个完整的沙箱。如果你需要真正的隔离，请使用容器。这个工具只是捕捉常见的幻觉模式，以防止意外损害。
<a href="https://github.com/melihmucuk/leash" rel="nofollow">https://github.com/melihmucuk/leash</a>
新开发者在获取新设备时，首先需要配置他们的开发环境。<p>Stackup 允许你通过一个命令完成这一过程，前提是你只需编写一次配置 yaml。<p>它是基于 MIT 许可证的免费开源软件。<p>这是我作为一名经验丰富的开发者所做的第一个 Go 项目。<p>欢迎随时给我反馈。
这是个人观点，但我认为当前的编码代理在错误的时机需要人类对人工智能的产出进行审核。大多数工具在执行之前专注于创建和审查计划。
因此，这一理念的核心是在让代理接触代码库之前先批准其意图。这听起来合理，但在实践中，这并不是实际学习发生的地方。
“计划模式”发生在代理尚未承担现实成本之前。在它还没有浏览代码库、运行测试、遇到奇怪的边缘情况或依赖问题之前。输出本质上是推测性的，通常看起来比实际情况要自信得多。
实际上，更有用的是审查“操作过程”：即代理在尝试解决问题后所做工作的总结。
目前，在大多数编码代理中，默认仍然将计划视为主要检查点，而操作过程则在之后。这将重心放在了错误的地方。
我在软件工程方面的经验是，我们不审查意图，而是信任执行。我们审查结果：差异、测试变更、发生了什么故障、修复了什么，以及原因。这实际上就是一个操作过程。
因此，我觉得当我们对操作过程提供反馈时，我们是在对具体的决策和后果做出反应，而不是基于假设的内容。这种反馈更清晰、更具可操作性，也更接近我们作为工程师今天审查工作的方式。
我很好奇其他人在使用以计划为先的编码代理时是否有相同的感受。原因是我正在开发一个开源编码代理，并决定减少对事先批准计划的重视，而更多地关注审查代理在实际工作中所经历的内容。
但这是我们团队内部正在激烈讨论的问题，希望能听到一些想法，以帮助我们以最佳方式实施这一点。
请访问以下链接观看视频： [https://youtube.com/watch?v=I41gcYUtzcM](https://youtube.com/watch?v=I41gcYUtzcM)
嘿，HN！
我正在开发一个新应用，希望它能够像 Linear 一样快速且响应灵敏，具备实时查询、同步和写操作的能力。
我对此并不是专家，所以欢迎大家来给我普及一下。我已经研究了一些选项，比如 Convex、ElectricSQL、Zero、Liveblocks 等等。
我觉得这些选项在某些方面总是有所欠缺，最好的总结就是它们的模块化。
我希望在一个同步引擎中实现以下几点：
- 能够使用我的数据库（Postgres，AWS RDS）
- 能够在我的后端形成并执行查询（假设我在 Next.js（Vercel）中有前端，并通过 API 路由连接到我的 FastAPI 服务器（AWS ECS），在这里我有所有的身份验证/权限中间件等）
- 有一种简单且熟悉的方式来向同步引擎声明模式（比如重用 SQLalchemy 或 Drizzle 的模式）
- 一个简单的 SDK 来形成使用 SQL 的查询
此外，我想知道这样的系统如何与连接池、分片、复制等功能协同工作。
是否有类似的解决方案存在？或者有哪些主要挑战阻碍了这类解决方案的出现？