2026-04-02 Hacker News Top Stories #

开发者基于泄露源码构建了 Claude Code 可视化解析工具，详细展示其 Agent 循环、53 个内置工具及实验性功能的内部工作机制。

工程师采用"每日贴点"系统管理电子元件，通过彩色贴纸分布识别高频使用物品，实现无需软件的极简库存管理。

OpenAI 以 8520 亿美元估值完成 1220 亿美元融资，月收入 20 亿美元但未盈利，正战略转向企业级应用与 AI 编程工具。

第三方网站展示 GitHub 历史可用性数据，但社区质疑 2018 年前记录准确性及状态页面本身的可靠性，认为其可能更偏向宣传。

OkCupid 与 FTC 达成和解，承认未经用户同意将 300 万用户照片共享给面部识别公司，但未支付任何罚款。

Cloudflare 推出开源 CMS EmDash，通过 Worker 沙箱化与权限声明机制解决 WordPress 插件安全问题，基于 TypeScript 和 Serverless 架构构建。

PrismML 发布首个商业可行的 1-bit 大语言模型 Bonsai，内存占用降低 14 倍且能耗减少 5 倍，性能却媲美主流 8B 模型。

CERN 推出配备 64 台超导电机的悬浮卡丁车，利用迈斯纳效应替代自行车用于大型强子对撞机隧道维护。

作者宣布退出当前技术行业，批判 AI 侵蚀人类创造力并呼吁回归博客写作，拒绝参与算法操控下的技术异化游戏。

MiniStack 作为 LocalStack 的免费开源替代品发布，支持 34 个 AWS 服务且基于真实基础设施，以极小资源占用为本地开发和 CI/CD 提供轻量解决方案。

1. Claude Code 深度解析：可视化技术剖析 (Claude Code Unpacked : A visual guide) #

https://ccunpacked.dev/

这是一个关于 Claude Code 的深度技术解析页面，基于公开的源代码进行分析，揭示其内部工作机制。

页面核心内容分为五个部分：

第一部分：Agent Loop（智能体循环）详细拆解用户输入到系统响应的完整流程，共 11 个步骤。从用户输入开始，通过 TextInput 组件接收键盘或管道输入，经过消息处理、历史记录管理、系统提示构建、API 调用、Token 分词、工具调用、循环执行、结果渲染、钩子函数执行，最终完成响应。整个过程在源码中被清晰标注，展示了从输入到输出的完整链路。

第二部分：架构探索器提供对 Claude Code 项目源码树的交互式浏览功能，按模块分类展示超过 1900 个文件，涵盖工具、命令、核心处理、UI 层、基础设施、支持组件等。用户可点击任意模块深入查看代码结构，了解系统组成。

第三部分：工具系统列出 53 个内置工具，按功能分类。包括文件操作（读、写、编辑、全局查找、grep）、执行环境（Bash、PowerShell、REPL）、搜索与获取（网页浏览器、网络抓取、搜索引擎）、任务与代理协作（创建/管理任务、团队、消息传递）、规划与执行（进入/退出规划模式、验证计划）、MCP 协议支持、用户交互（询问、待办事项）、定时任务、实验性功能等。部分工具标记为安全锁，表示受权限控制。

第四部分：命令目录整理了所有可用的斜杠命令（/commands），按用途分类。包括设置与配置、日常开发工作流（如会话管理、文件操作、代码审查）、Git 与 PR 操作、调试诊断、高级与实验功能。部分命令带有安全锁，表示需特殊权限或处于测试阶段。

第五部分：隐藏功能揭示尚未正式发布但存在于源码中的实验性功能，包括：

Buddy：终端中的虚拟宠物，根据账户 ID 生成物种与稀有度
Kairos：持久化模式，支持跨会话记忆与后台自动任务
UltraPlan：使用 Opus 模型进行长达 30 分钟的长周期规划
Coordinator Mode：主代理并行分发任务，使用隔离的 Git 工作树
Bridge Control：通过手机或浏览器远程控制会话
Daemon Mode：后台运行会话，使用 tmux 实现
UDS Inbox：会话间通过 Unix 域套接字通信
Auto-Dream：在会话间自动总结与组织学习成果

该页面为非官方分析，基于 2026 年 3 月 31 日的源码快照，由 zackautocracy 制作，内容由 AI 辅助整理，旨在揭示 Claude Code 的底层技术实现与未来潜力。

HN 热度 1021 points | 评论 359 comments | 作者：autocracy101 | 18 hours ago #

https://news.ycombinator.com/item?id=47597085

该可视化工具由作者在 Claude Code 代码泄露后数小时内快速构建，旨在帮助理解其架构与工作流程，作者正根据社区反馈持续更新。
有人建议作者开源自己的项目，称赞其界面与功能设计出色，认为这是“氛围编程”的体现。
有人认为当前开发已高度依赖 AI，手动编码已不现实，但即便如此，作者仍体现了创造性投入。
有人反对“必须手动编码”的观点，认为这类似于将软件称为“手工艺品”，并调侃其荒谬性。
有人认为在特定场景下（如 UI 分析工具），手动编码仍有其价值，更多出于乐趣而非效率。
有人幽默地提出未来软件可能标榜“无虐待”或“无剥削”以吸引用户。
有人质疑认为“AI 编码是常态”是一种精神错乱的表现，认为这会削弱人类创造力。
有人坚持认为即使发明新算法，也应先用自然语言描述，再由 AI 实现，以提升效率与清晰度。
有人质疑为何现在没人愿意开源，认为这与 AI 的普及有关，但也有观点认为开源仍可提升个人履历与影响力。
有人表示自己已从“默认开源”转向“默认私有”，反映出开源文化正在变化。
有人认为开源与否更多是出于职业发展考虑，如提升简历含金量或吸引关注。
有人指出当前代码工具多为 Java/TypeScript 编写，因 AI 公司早期由前端开发者尝试，但这些语言并不适合终端工具。
有人建议在“Anthropic 消息格式”部分添加提示说明，指出其实际源自 OpenAI 格式且广泛通用。
有人分享自己使用 pi 和 Claude Code 在本地 Docker 环境中搭建完全离线的智能体系统，并希望作者能对比 pi 与 cc 的架构图。
有人询问离线智能体系统的实际运行效果及硬件配置，如 M5（24G）设备表现。
有人认为 50 万行代码的智能体 CLI 证明了让 LLM 行为确定化是巨大的状态管理难题，代码膨胀主要源于防御性编程。
有人指出代码中大量存在“挫败正则表达式”、上下文清理、工具重试、状态回滚等机制，以防止智能体“漂移”或出错。
有人赞赏 Claude Code 的核心架构设计，认为其客户端工具简洁通用，使服务端能快速创新且保护核心机密。
有人认为客户端工具虽已公开，但真正“秘密”在于服务端如何高效利用这些工具。
有人指出现有工具集已为人熟知，希望增加“展示”功能，允许模型直接展示文件内容而不必通过模型处理。

2. 每天一贴，杂乱远离 (A dot a day keeps the clutter away) #

https://scottlawsonbc.com/post/dot-system

Scott Lawson 在他的实验室中使用一个简单而高效的“每日贴点”系统来管理电子元件。整个系统仅需几美元的彩色贴纸，无需软件或数据库，已持续使用四年。

他最初面临的问题是：随着电子元件收集越来越多，原有的工具箱和分格收纳盒无法满足需求，且不透明容器导致部分零件被遗忘。他改用透明的 4 升标准盒子，所有盒子统一尺寸、清晰标注，并按类别分类存放，如电阻、电容、电机、LED 等。

为量化使用频率，他引入“每日一贴”规则：每次打开盒子，就贴一个彩色贴纸；但每天最多只贴一个，避免重复记录。不同颜色代表不同年份，通过一张手写对照表即可识别年份，系统可持续使用十年以上。

这个看似简单的做法带来了显著效果：四年后，通过观察盒子上的贴纸分布，他能直观判断哪些元件被频繁使用，哪些长期闲置。最令人意外的是，使用频率最高的并非传感器或特殊器件，而是通用耗材：胶水、胶带、贴纸、通用连接器、电池、磁铁、LED、DC-DC 转换器、USB-C 转接口线缆、电容、电阻、工具（如钻头、锉刀）、卡尺、SD 卡、USB 设备、橡胶脚垫和螺钉等。

这些高使用率的元件共同特点是“跨项目通用”——几乎每个项目都会用到，是连接和支撑系统的基础。而专用元件如电机、自行车零件等则使用较少。

系统的优势在于极简、可持续、视觉提醒强。贴纸本身成为记忆提示，且贴纸分散放置在实验室各处，随时可取。访客常被这些贴纸吸引，理解后往往惊叹其智慧。

这个系统不仅解决了“看得见才记得住”的问题，更帮助他识别出真正重要的通用工具，实现库存的“稳态”管理，避免无节制积累。它证明：最有效的管理方式，往往是简单到近乎本能的日常习惯。

HN 热度 543 points | 评论 162 comments | 作者：scottlawson | 1 day ago #

https://news.ycombinator.com/item?id=47593556

Really Useful Boxes（RUBs）因其透明、耐用、可长期购买补充而广受好评，适合长期收纳和项目管理。
RUBs 的前开式设计便于堆叠和取用，但缺乏悬挑边缘，限制了其用于浮动货架的可能。
有人用 RUBs 存放 42000 个标本化的昆虫，结合塑料展示盒和 GitHub 备份，实现高效管理。
RUBs 在潮湿沿海地区仍能保持良好状态，十年后仅轻微泛黄，证明其耐久性。
IKEA 的 Billy 书柜有更深层型号，可适配 RUBs，但部分抽屉无法完全拉出，需改装。
有人用两个盒子模拟两级缓存机制，用于管理手头的工具和材料，提升使用效率。
未来可用性是重要考量，选择可长期采购的标准化容器能避免未来资源断档。
与 RUBs 类似，UTZ Rako/Euroboxes 也适合长期存储，可堆叠、分隔，且二手市场易得。
Sortimo 等高端收纳盒虽好，但价格昂贵，难以普及。
用网格标签加记号代替贴纸，可实现更清晰、可更新的标识系统。
项目专用盒子比通用分类更高效，尤其适合周末短时项目重启。
书籍用点标记阅读深度，多点表示反复阅读，不同颜色墨水记录重读时间。
透明容器和标准化设计有助于提高空间利用率和物品查找效率。

3. OpenAI 以 8520 亿美元估值完成创纪录的 1220 亿美元融资 (OpenAI closes funding round at an $852B valuation) #

https://www.cnbc.com/2026/03/31/openai-funding-round-ipo.html

OpenAI 已关闭一轮创纪录的 1220 亿美元融资，公司估值达到 8520 亿美元，高于此前宣布的 1100 亿美元。此次融资由软银联合领投，Andreessen Horowitz 和 D. E. Shaw Ventures 等机构参与。亚马逊、英伟达和微软也继续参与投资，其中亚马逊承诺投资最高 500 亿美元，英伟达投资 300 亿美元，微软虽未披露具体金额，但此前已投入超 130 亿美元。

OpenAI 首次通过银行渠道向个人投资者开放投资，成功募集 30 亿美元。公司目前月收入达 20 亿美元，2025 年全年营收为 131 亿美元，但尚未实现盈利，仍处于烧钱阶段。

公司表示，AI 正推动生产力提升、加速科学发现，并拓展人类与组织的创造能力。此次融资将用于支持其在人工智能基础设施领域的领先地位。随着估值飙升，CEO 萨姆·阿尔特曼面临更大压力，需为未来可能的 IPO 提供合理支撑。

为控制成本，OpenAI 近期已缩减部分支出计划，关闭了如 Sora 等非核心产品。公司战略重心正转向企业级应用和 AI 编程工具，而非消费端市场。

HN 热度 510 points | 评论 476 comments | 作者：surprisetalk | 1 day ago #

https://news.ycombinator.com/item?id=47592755

OpenAI 的月收入约为 20 亿美元，年收入 240 亿美元，相较于预期增长较慢，而 Anthropic 在短时间内增长迅速，可能已超过 OpenAI。
当前关于公司收入的数据主要来自媒体和投资者的非正式信息，尚未有官方披露，未来需等待 IPO 后才能获得正式财务报告。
私营公司向投资者报告财务数据时没有统一标准，不同公司对收入的计算方式存在差异，例如是否包含平台交易总额（GMV）会影响收入估值。
亚马逊因计入 GMV 导致市销率（P/S）仅为 3 倍，而微软和谷歌等公司未计入类似数据，市销率高达 9 倍，这反映了会计方法对估值的显著影响。
会计准则（如 GAAP）在实际应用中存在灵活性，公司可根据自身情况选择收入确认方式，这可能导致不同公司间财务数据不可比。
有人担忧指数基金规则变化可能“强制”投资者在 IPO 初期即买入新公司股票，从而加剧市场泡沫，这种机制被批评为“腐败”。
有人反驳称，投资者可以选择不投资指数基金，或自行构建投资组合以排除特定股票，但现实中大多数人不会这么做。
现行纳斯达克 100 指数对 IPO 公司有三个月的等待期，但该规则可能被取消，此举对长期投资者影响有限。
现有指数规则的放宽可能削弱指数的筛选功能，但长期来看，更高质量的指数可能取代现有指数，形成更有效的市场选择。
由于大科技公司已持有大量 AI 公司股份，且与这些公司有深度业务合作，投资者实际上已深度参与 AI 行业，无论是否主动投资。
有人认为，被动投资在过度发展后已变成一种“骗局”，因为市场流动性无限，一旦出现大规模撤资，将引发系统性风险。
有人引用凯恩斯名言“长期来看我们都死了”，认为当前市场环境类似于 1928 年大萧条前的泡沫时期。
有人认为，尽管短期存在市场扭曲，但从长期看经济仍会趋向效率，不合理的制度（如垄断、关税）最终将被打破。

4. GitHub 历史可用性数据 (GitHub’s Historic Uptime) #

https://damrnelson.github.io/github-historical-uptime/

GitHub 官方状态页面显示其历史可用性数据，所有信息均来自官方状态页面。页面提供平均可用性统计，帮助用户了解 GitHub 服务的稳定性。数据按时间维度展示，支持查看不同时间段的服务中断情况。用户可点击“查看源数据”获取详细记录，包括事件时间、影响范围和恢复状态。该页面旨在提高透明度，便于开发者和企业评估 GitHub 服务的可靠性。

HN 热度 483 points | 评论 120 comments | 作者：todsacerdoti | 1 day ago #

https://news.ycombinator.com/item?id=47591928

前 2018 年的 GitHub uptime 数据可能不准确，因为当时的监控系统可能尚未建立或记录不完整。
GitHub 官方状态页面可能更偏向宣传而非真实可观测性，尤其在公司未上市前。
状态页面本身在 GitHub 服务中断时也经常无法访问，导致无法有效反映真实情况。
2018 年后 GitHub 可能改进了状态页面的可用性和准确性。
一个第三方聚合状态页面显示 GitHub 过去 90 天的平均可用性为 90.84%，但该统计方式可能存在问题。
该聚合统计可能采用“任一服务中断即视为整体中断”的逻辑，而非加权平均，这可能导致数据失真。
从用户实际体验来看，部分服务（如 GitHub Actions）的中断频率可能被低估，但整体影响仍属可接受。
用户对“系统是否可用”的判断应基于其核心使用场景，而非所有服务都必须正常运行。
如果用户依赖 GitHub Actions 进行工作流，那么其中断会严重影响使用体验，应单独评估。
GitHub Copilot 等集成服务的中断是否算作 GitHub 整体宕机，取决于其在用户工作流中的角色。
将第三方服务（如 OpenAI）的故障归为 GitHub 服务故障，可能不合理，除非该服务被明确视为 GitHub 产品的一部分。
企业级服务合同中，SLO（服务等级目标）的计算方式会影响对“可用性”的定义，不同客户可能有不同标准。
服务的可用性应根据用户实际依赖的服务组合来评估，而非简单地将所有服务合并计算。

5. OkCupid 向人脸识别公司泄露 300 万用户交友照片，FTC 称其违规 (OkCupid gave 3M dating-app photos to facial recognition firm, FTC says) #

https://arstechnica.com/tech-policy/2026/03/okcupid-match-pay-no-fine-for-sharing-user-photos-with-facial-recognition-firm/

OkCupid 及其母公司 Match Group 与特朗普政府领导的联邦贸易委员会（FTC）达成和解，未支付任何罚款。此次和解源于 2014 年的一起数据泄露事件：OkCupid 在未经用户同意的情况下，将近 300 万用户的照片、位置信息及其他个人数据共享给了人工智能公司 Clarifai，用于开发面部识别技术。

FTC 指出，OkCupid 未在隐私政策中明确告知用户这一行为，也未提供用户选择退出的机制，违反了其自身承诺的隐私条款。此外，OkCupid 在被媒体曝光后，还试图掩盖事实，声称与 Clarifai 无关联，甚至在调查期间采取措施阻挠。

尽管 Match 和 OkCupid 未承认或否认指控，但同意永久禁止其在数据使用和共享方面进行虚假陈述。该和解协议需经法院批准，目前提交至德克萨斯州北区联邦地区法院。

OkCupid 表示，此次事件反映的是 2014 年的旧有做法，公司已大幅加强隐私保护和数据治理措施，当前运营已符合用户期望。尽管近期法院限制了 FTC 的执法权力，但其仍可通过司法途径追究虚假广告行为并寻求赔偿。

Clarifai 是一家为政府机构（包括军事与情报部门）及私营企业提供 AI 服务的公司，其客户涵盖多个行业。此次事件凸显了在线平台在数据共享与用户知情权方面的重大责任。

HN 热度 464 points | 评论 92 comments | 作者：whiteboardr | 1 day ago #

https://news.ycombinator.com/item?id=47591104

目前几乎每个在线服务都应该被视为敌对，可能会以妥协私为代价获利。
数据泄露的可能性几乎是 100%，因此建议删除所有社交账户。
公司是否真的删除用户数据而不是只存档存在疑问。
在 “被遗忘权” 下，个人信息应当被删除，但实际执行情况不明。
用户缺乏数字身份会导致被误解和标签化，隐私受到严重威胁。
对隐私关注的应用市场存在，但如何信任这些应用是个问题。
许多用户虽然声称关心隐私，但实际上并不愿意为隐私支付。
随着公司寻求盈利，原本隐私导向的应用可能会改变方向。
大型互联网社交平台的隐私问题源于资本主义文化，数据视为有价值的商品。
即使应用一开始是隐私导向，也可能因出售或管理变更而失去初衷。
使用云服务的应用在数据审计上存在困难，用户不能轻易验证其隐私承诺。
用户应保持尽可能少的个人信息，以防被数据掮客利用。
法律对公司隐私政策的约束往往不力，企业可以随时修改政策。
对于违反隐私法的企业，法律惩罚通常是承诺未来遵守法律，这并不严厉。

6. Cloudflare 推出开源新内容管理系统 EmDash，作为 WordPress 的精神继承者，致力于解决插件安全等核心问题 (EmDash – a spiritual successor to WordPress that solves plugin security) #

https://blog.cloudflare.com/emdash-wordpress/

Cloudflare 推出全新开源内容管理系统 EmDash，作为 WordPress 的精神继承者，旨在解决现有 CMS 面临的核心问题，尤其是插件安全漏洞。

EmDash 采用 TypeScript 编写，完全基于 Serverless 架构，支持在 Cloudflare 或任何 Node.js 服务器上部署。其核心创新在于通过 Dynamic Workers 实现插件沙箱化运行，每个插件在独立隔离环境中执行，仅能访问其声明所需的特定能力（capabilities），从根本上杜绝了插件对数据库、文件系统等关键资源的直接访问。

与 WordPress 插件可随意访问所有系统资源不同，EmDash 插件必须在 manifest 中明确定义所需权限，例如读取内容或发送邮件。安装前即可清晰了解插件权限范围，类似 OAuth 的权限授权机制，极大提升了安全性与透明度。

此外，EmDash 采用 MIT 许可证，不强制插件开源或使用 GPL 协议，开发者可自由选择许可证，摆脱 WordPress 市场对代码许可的限制。插件无需公开源码即可被信任部署，解决了传统平台因安全顾虑导致的“市场锁定”问题。

EmDash 基于 Astro 框架构建，专为内容驱动型网站优化，具备极高的性能和可扩展性。目前 EmDash v0.1.0 已开放早期开发者测试，支持在 Cloudflare 账户或本地服务器部署，并提供在线 Playground 体验管理界面。

该产品旨在延续 WordPress 民主化内容创作的精神，同时利用现代云原生技术，构建更安全、灵活、可扩展的下一代内容发布平台。

HN 热度 426 points | 评论 309 comments | 作者：elithrar | 7 hours ago #

https://news.ycombinator.com/item?id=47602832

TypeScript 有助于实现前后端类型统一，提升开发体验和代码质量，减少类型错误。
使用 Worker 插件可实现插件沙箱化，提升安全性，避免恶意插件对系统造成破坏。
与 WordPress 相比，EmDash 在安全性和现代技术栈上更具优势，但其复杂性可能带来新问题。
静态网站生成是更简洁高效的选择，但客户常需要动态功能，导致必须依赖动态平台。
WordPress 的流行部分源于其易部署和对非技术用户的友好性，但界面臃肿、体验差。
非技术用户更倾向于通过可视化界面直接编辑内容，而非依赖开发者。
一些小型网站和业务仍依赖 WordPress 的灵活性，即使其存在性能和安全问题。
Cloudflare 推出 EmDash 可能是为推广自身 Workers 产品，具有“自用”目的。
Astro 框架支持静态生成与动态功能结合，避免开发初期陷入技术困境。
项目应避免重复 WordPress 的臃肿问题，追求轻量化和简洁的用户体验。
采用 Drizzle Schema 首先的设计理念，可实现数据库结构的完全控制与灵活性。
项目应尽量减少依赖，避免供应链攻击和维护负担。

7. 1-Bit Bonsai：首个具备商业可行性的 1-bit 大语言模型 (Show HN: 1-Bit Bonsai, the First Commercially Viable 1-Bit LLMs) #

https://prismml.com/

PrismML 正在推动人工智能模型的效率革命，致力于在不依赖数据中心的情况下，实现高性能、低功耗的智能计算。其核心成果是推出一系列采用 1-bit 权重的 Bonsai 系列模型，显著降低模型对内存、算力和能耗的需求。

1-bit Bonsai 8B 是首个商业可行的 1-bit 权重模型，仅需 1.15GB 内存，相比全精度 8B 模型减少 14 倍内存占用，运行速度提升 8 倍，能耗降低 5 倍，同时在多个基准测试中表现媲美主流 8B 模型，智能密度提升超过 10 倍。

1-bit Bonsai 4B 仅需 0.57GB 内存，可在 M4 Pro 芯片上实现每秒 132 个 token 的吞吐率，兼顾高准确率与能效，适用于实时性要求高的场景。

1-bit Bonsai 1.7B 仅占用 0.24GB 内存，可在 iPhone 17 Pro Max 上实现每秒 130 个 token 的速度，专为边缘设备设计，实现轻量级模型处理高负载任务。

所有模型均基于加州理工学院的前沿研究成果，强调“每比特智能密度”而非单纯扩大参数规模，重新定义模型设计范式。

PrismML 正在招聘 AI/ML 工程师，岗位聚焦大规模系统与边缘端消费级 AI，欢迎加入推动智能效率边界的技术团队。

HN 热度 398 points | 评论 148 comments | 作者：PrismML | 1 day ago #

https://news.ycombinator.com/item?id=47593422

1-bit Bonsai 模型在极低的硬件资源下表现出色，尽管模型仅 1-bit，但通过 FP16 scale factor 每 128 位进行补偿，实现了令人惊讶的性能。
该模型在本地 RTX 6000 Pro 显卡上运行极快，响应迅速，可支持实际应用如代码生成、LaTeX 公式编写和地理坐标查询脚本生成。
模型在生成 R 脚本和 LaTeX 文档方面表现良好，尽管存在一些非最优或轻微错误，但整体质量远超预期，尤其在模型极小（仅 1.15GB 内存占用）的情况下。
模型在处理常识推理问题（如“100 米远的洗车店该步行还是开车”）时仍会犯错，但其能进行基本逻辑推演已属技术奇迹。
有用户指出，模型的错误源于人类对情境的隐含假设，而非模型本身逻辑缺陷，说明其推理能力仍受限于上下文理解。
该模型基于 llama.cpp 的 PrismML 分支实现，用户通过克隆其仓库并编译后成功运行，M1 芯片设备也能实现 23 tokens/秒的推理速度。
有用户分享了 Google Colab 的可运行链接，方便更多人体验，但因流量大可能导致链接失效，建议作为备选方案。
该技术展示了 LLM 压缩与优化的巨大潜力，未来可能进一步缩小模型体积，甚至在 1990 年代的硬件上运行基础 LLM，前提是数学与算法突破。

8. CERN 推出新型超导卡丁车 (CERN levels up with new superconducting karts) #

https://home.cern/news/news/engineering/cern-levels-new-superconducting-karts

CERN 近日推出新型超导卡丁车，用于即将启动的大型强子对撞机（LHC）长期停机维护项目（LS3）。这些卡丁车将取代此前在 27 公里长的地下隧道中使用的自行车，大幅提升工程师和技术人员在隧道内移动的效率。

每辆卡丁车配备 64 台超导电机，当冷却至临界温度以下时，利用迈斯纳效应实现悬浮，从而高速行驶。早期测试已显示出显著的速度提升，项目负责人 Mario Idraulico 称其“超级棒”。

为确保安全，每位驾驶员将配备专为长时间地下作业设计的 SHELLS 安全装备。尽管有员工希望在隧道中携带香蕉，但安全协调员 Luigi Fratello 明确拒绝。

该技术灵感源自 CERN 园区内幼儿园儿童的设计创意，体现了 CERN 对青少年科学兴趣的培养。孩子们被亲切地称为“Luma”，其参与也推动了项目与欧洲初创企业 Quantum Mushroom 在航空航天和反重力车辆领域的合作探索。

该项目不仅服务于 LHC 升级为高亮度 LHC（HiLumi LHC）的工程需求，也展示了基础科研成果向社会应用转化的潜力。

HN 热度 380 points | 评论 85 comments | 作者：fnands | 16 hours ago #

https://news.ycombinator.com/item?id=47597935

这个玩笑让人想起当年室温超导体被误传时，人们反应的差异，反映出不同人的理性与期望。
有人认为，对室温超导体的狂热反应可以用来识别哪些人过于轻信，但这种判断方式本身存在逻辑谬误。
室温超导体并非“显然不可能”，而是材料科学难题，已有技术进步表明其可能性存在。
超导体在常压下实现室温超导更具挑战性，高压环境下的超导并不实用。
从物理角度看，提升超导临界温度涉及多个复杂因素的耦合，不是单一技术突破就能解决。
该玩笑的幽默之处在于角色命名（如马里奥、路易吉、碧琪公主）和细节设计，暗示其为愚人节恶搞。
项目负责人“马里奥·伊德拉乌利科”（意为“液压工”或“水管工”）和“路易吉·弗拉泰洛”（意为“兄弟路易吉”）是明显的游戏彩蛋。
该恶搞具有温和的幽默感，恰到好处地为沉重的世界氛围注入一丝轻松。
与过去某些公司愚人节玩笑相比，此项目无害且不误导，属于高质量的幽默。

9. 我退出了，齿轮党赢了 (I Quit. The Clankers Won) #

https://dbushell.com/2026/04/01/i-quit-the-clankers-won/

作者在博客中表达了对当前技术环境的深刻反思，尤其是人工智能对创作与个人表达的冲击。他认为，尽管 AI 技术看似强大，实则制造了大量平庸、缺乏灵魂的内容，正在侵蚀人类的创造力与真实声音。

作者指出，博客写作不仅未过时，反而比以往任何时候都更加重要。在信息被算法操控、隐私被侵蚀、原创性被剽窃的背景下，公开分享个人思考成为一种抵抗。写作能帮助理清思路、强化信念，同时为他人提供启发，哪怕受众很小，也可能产生深远影响。

他批评当前 AI 产业本质上是“99% 的炒作”，其商业模式如同赌场，以牺牲人类创造力为代价换取利润。生成式 AI 产出的内容虽可称为“艺术”，但只是低质、空洞的模仿，远不如人类创作中蕴含的情感与意义。

作者呼吁读者不要屈服于技术霸权，拒绝被 AI 工具驯化。真正的价值在于保持独立思考，坚持用自己的声音发声。他提倡回归“旧网络”“开放网络”“独立网络”的精神，用博客等自主平台构建有温度、有深度的数字空间。

最后，他强调：不要放弃自己的创造力，不要让 AI 取代你作为人类的独特性。真正的胜利，是选择不参与这场技术异化的游戏。

HN 热度 364 points | 评论 429 comments | 作者：domysee | 15 hours ago #

https://news.ycombinator.com/item?id=47598511

提升开发技能对公司的价值不被客户直接感知，公司更关注问题是否解决，而非工程师能力的提升。
一些公司意识到投资专业发展是明智之举，旨在通过提升工程师能力来优化运营效率。
当前企业对 AI 的快速采纳缺乏对人才发展的考量，反而可能促使开发者技能退化。
将编码工作交给 AI 工具，本质上是让开发者沦为“ beep boop”的操作者，而非创造者。
作者感到惋惜的是，自己过去 15 年将爱好当作职业，如今这种状态正在终结。
未来最重要的开发技能可能是如何高效使用编码代理（coding agents），而非传统编程能力。
类似于机器学习兴起时，掌握新工具和方法论成为关键，而非死守理论。
能够有效使用编码代理将成为基本技能，如同今天会用 Excel 一样。
即便能使用编码代理，真正区分优秀开发者的核心能力仍包括：代码审查、系统架构设计、安全漏洞防范、测试质量保障、业务需求理解与沟通能力。
代码审查等核心能力不会因 AI 普及而消失，反而在 AI 生成代码质量参差不齐的背景下更加重要。
当前 AI 生成代码的质量和可维护性仍需人工干预和验证，尤其是对复杂系统和关键业务。
如果未来完全依赖 AI 且无人审查，将导致系统性风险，如同缺乏监管的食品药品审批。
通过编写规范和约束条件，可以减少对人工审查的依赖，实现自动化验证和质量保障。
代码质量直接影响 AI 训练效果和后续迭代效率，缺乏代码上下文将导致无法有效指导 AI 改进。
即使 AI 能生成代码，开发者仍需具备第一手实现细节知识，才能发现并修复潜在问题。
AI 生成代码的可读性、可维护性和资源占用问题仍需人工把控，尤其在资源受限的系统中。
随着训练数据和提示工程的优化，AI 生成代码的质量有望提升，未来可能减少对人工干预的需求。

10. MiniStack：LocalStack 的免费替代品，专为本地开发与 CI/CD 设计 (MiniStack (replacement for LocalStack)) #

https://ministack.org/

MiniStack 是一个免费的 LocalStack 替代品，专为本地开发和 CI/CD 环境设计。它支持 34 个 AWS 服务，全部运行在单一端口 4566 上，无需账户、许可证或遥测。

启动仅需约 2 秒，空闲时内存占用仅约 30MB，Docker 镜像大小为 150MB，远低于 LocalStack 的 1GB。

核心优势在于“真实基础设施”：RDS 运行真实的 Postgres/MySQL 容器，ElastiCache 启动真实 Redis，ECS 可运行真实 Docker 容器，Athena 可通过 DuckDB 执行真实 SQL 查询（需额外安装）。

支持的 AWS 服务包括 S3、SQS、SNS、DynamoDB、Lambda、IAM、STS、Secrets Manager、CloudWatch Logs、SSM 参数、EventBridge、Kinesis、CloudWatch Metrics、SES、Step Functions、API Gateway v1/v2、RDS、ElastiCache、ECS、Glue、Firehose、Route53、Cognito、EC2、EMR、EBS、EFS、ALB/ELBv2、ACM、SES v2、WAF v2、CloudFormation 等。

与 LocalStack 对比，MiniStack 全功能免费，采用 MIT 开源许可证，无任何功能限制或付费墙。而 LocalStack 已将大部分核心服务转为付费，且使用 BSL 许可证限制使用。

兼容主流工具：boto3、AWS CLI、Terraform、CDK、Pulumi 等均可无缝使用。

只需一条命令即可启动：docker run -p 4566:4566 nahuelnucera/ministack

适用于开发者、团队和 CI/CD 流水线，提供与 AWS 完全一致的本地体验，且完全免费、无隐藏成本。

HN 热度 305 points | 评论 65 comments | 作者：kerblang | 1 day ago #

https://news.ycombinator.com/item?id=47593285

有网友表示对 MiniStack 在 DynamoDB 模拟上的缺陷感到不安，认为其无法准确反映服务异常和边缘情况。
另有观点认为 MiniStack 适用于集成测试，但对于需要准确 DynamoDB 行为的场景不适合。
一些用户提到，MiniStack 可以用作基础测试工具，以减少 AWS 的使用费用。
讨论中提到 LocalStack 的失败可能与其代码库混乱及难以吸引贡献者有关。
有网友认为，MiniStack 的出现可能得益于 AWS 的成熟和开发者寻找替代方案的需求。
对于 MiniStack 的定位，有人认为它并不打算完全取代 LocalStack，只专注于免费的核心服务。
一些用户希望 MiniStack 能够提供更多核心服务的兼容性和轻量级 GUI 界面。
讨论中提到 LocalStack 的兼容性问题，以及在真实环境中可能出现的意外情况。
有人指出，LocalStack 的成功与 AWS 的稳定性和功能覆盖面有关。
部分用户对 LocalStack 的未来表示担忧，认为其在竞争中缺乏优势。
网友提到 AI 工具的应用可能改变开发者在模拟服务方面的工作方式。
还有人认为，使用 AI 生成的代码缺乏质量控制，可能会导致安全问题。

Hacker News 精彩评论及翻译 #

OpenAI closes funding round at an $852B valuation #

https://news.ycombinator.com/item?id=47593513

No, they didn’t raise $122B as the HN title implies. A big chunk of that $122B is a “maybe” that depends on various things that need to happen in the future.

Oh, man… I can’t wait to see where this is going. Might not be pretty after all.

simonebrunozzi

不，正如HN标题暗示的那样，他们并没有筹集到1220亿美元。这1220亿美元中很大一部分属于“可能”，取决于未来是否会发生各种事情。

天哪……我迫不及待想看看接下来会发生什么。毕竟结局可能不会太漂亮。

SpaceX files to go public #

https://news.ycombinator.com/item?id=47605398

You don’t have to believe. If you have a 401k you will be an investor 15 days after launch.

The IPO will go great, because the company will float a fairly small issuance. The big shareholders will not immediately sell. They will hold on and maybe even buy to support the price.

Then, after 15 days, it will enter the indexes and everyone’s 401k will start auto-buying this stock.

You might say this is an obvious flaw in how the indexes work if they start immediately accept a brand new IPOed stock with limited float. You’d be right, which is why they won’t list for a year.

At least they wouldn’t until Elon got them to change their rules: https://www.bloomberg.com/news/articles/2026-03-30/nasdaq-clears-way-for-spacex-big-ipos-to-gain-fast-index-entry

jordanb

你不必信，如果你有401k账户，在上市15天后你将成为投资者。

IPO会非常顺利，因为公司发行的规模相当小。

大股东不会立即抛售，他们会持股观望，甚至可能会买入以托市。

然后，在15天后，该股票将进入指数，所有人的401k账户都会开始自动买入这只股票。

你可能会说，如果指数立即接受一只全新的IPO股票且流通盘有限，这显然是运作机制的一个漏洞。

你说得对，这也是为什么它不会在一年内上市。

除非埃隆让他们更改规则，否则至少他们不会这么做：[链接]

Claude wrote a full FreeBSD remote kernel RCE with… #

https://news.ycombinator.com/item?id=47598870

Key point is that Claude did not find the bug it exploits. It was given the CVE writeup 1 and was asked to write a program that could exploit the bug.

That said, given how things are I wouldn’t be surprised if you could let Claude or similar have a go at the source code of the kernel or core services, armed with some VMs for the try-fail iteration, and get it pumping out CVEs.

If not now, then surely not in a too distant future.

magicalhippo

关键点在于，Claude 并没有发现它所利用的那个漏洞。它只是被给了 CVE 漏洞描述 1，然后被要求写一个能够利用该漏洞的程序。

话虽如此，鉴于目前的形势，如果你给 Claude 或类似模型提供内核或核心服务的源代码，并给它配备一些虚拟机进行反复试错，让它不断生成 CVE，我对此也不会感到意外。

如果现在做不到，那在不久的将来肯定也能做到。

The Claude Code Source Leak: fake tools, frustrati… #

https://news.ycombinator.com/item?id=47591989

There are now several comments that (incorrectly?) interpret the undercover mode as only hiding internal information. Excerpts from the actual prompt 0:

NEVER include in commit messages or PR descriptions:

The phrase “Claude Code” or any mention that you are an AI
Co-Authored-By lines or any other attribution

BAD (never write these):

1-shotted by claude-opus-4-6
Generated with Claude Code
Co-Authored-By: Claude Opus 4.6 <…> This very much sounds like it does what it says on the tin, i.e. stays undercover and pretends to be a human. It’s especially worrying that the prompt is explicitly written for contributions to public repositories.

mzajc

现在有几条评论（可能是错误地？）将潜行模式解读为仅仅隐藏内部信息。以下是来自实际提示词 0的摘录：

在提交信息或 PR 描述中永远不要包含：

“Claude Code” 这个短语或任何提到你是一个 AI 的内容
“Co-Authored-By” 行或任何其他署名

错误（永远不要写这些）：

1-shotted by claude-opus-4-6
Generated with Claude Code
Co-Authored-By: Claude Opus 4.6 <…>

这听起来非常像是名副其实，即保持潜行并假装是人类的。尤其令人担忧的是，该提示词是专门为向公开代码库贡献而编写的。

OkCupid gave 3M dating-app photos to facial recogn… #

https://news.ycombinator.com/item?id=47591680

At this point, nearly every online service should be considered hostile. If they can make a small amount of money by compromising your privacy or your identity, they will. If they can make a small amount of money by stealing your attention and addicting you, they will.

Are there exceptions? I’m sure. Will I be erring sometimes by being cautious? Definitely. But, there is really not much of an alternative these days.

everdrive

如今，几乎所有在线服务都应被视为具有敌意。只要能通过侵犯你的隐私或冒用你的身份赚一点钱，他们就会。只要能通过窃取你的注意力并让你上瘾赚一点钱，他们也会。有例外吗？我确信。过于谨慎有时会出错吗？肯定会。但如今真的没有太多别的选择。

Microsoft: Copilot is for entertainment purposes o… #

https://news.ycombinator.com/item?id=47590473

Anthropic does a somewhat similar thing. If you visit their ToS (the one for Max/Pro plans) from a European IP address, they replace one section with this:

Non-commercial use only. You agree not to use our Services for any commercial or business purposes and we (and our Providers) have no liability to you for any loss of profit, loss of business, business interruption, or loss of business opportunity.

It’s funny that a plan called “Pro” cannot be used professionally.

https://www.anthropic.com/legal/consumer-terms

wowoc

Anthropic 也在做类似的事情。如果你从欧洲 IP 地址访问他们的 ToS（针对 Max/Pro 计划的那一个），他们会把其中一段替换成如下内容：

仅限非商业用途。你同意不得将我们的服务用于任何商业或商业目的，且我们（以及我们的提供商）不对因任何利润损失、业务中断或商业机会丧失而向您承担任何责任。

有趣的是，一个被称为 “Pro” 的计划却不能用于专业用途。

https://www.anthropic.com/legal/consumer-terms

Slop is not necessarily the future #

https://news.ycombinator.com/item?id=47591182

I find most developers fall into one of two camps:

You treat your code as a means to an end to make a product for a user.
You treat the code itself as your craft, with the product being a vector for your craft.

The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate on their product faster.

Personally, I fall into the first camp.

No one has ever made a purchasing decision based on how good your code is.

The general public does not care about anything other than the capabilities and limitations of your product. Sure, if you vibe code a massive bug into your product then that’ll manifest as an outcome that impacts the user negatively.

With that said, I do have respect for people in the latter camp. But they’re generally best fit for projects where that level of craftsmanship is actually useful (think: mission critical software, libraries us other devs depend on, etc).

I just feel like it’s hard to talk about this stuff if we’re not clear on which types of projects we’re talking about.

seamossfet

我发现大多数开发人员通常都分为两类：

第一类：你把代码视为达到目的的手段，通过代码为用户制作产品。

第二类：你把代码本身视为一门手艺，而产品则是展示这门手艺的载体。

那些通常对 AI 说出最消极言论的人，往往属于第二类，因为 AI 正在自动化他们视为自己“艺术”的很大一部分内容，同时却让第一类开发者能够更快地迭代他们的产品。

就我个人而言，我属于第一类。

从来没有人仅仅因为代码写得有多好而做出购买决定。

普通大众关心的只有你产品的功能和局限性，除此之外毫不在意。

当然，如果你凭感觉在产品里写进了一个巨大 Bug，那确实会导致糟糕的用户体验。

话虽如此，我确实对后者（第二类）开发者表示尊重。但对于那种特定精湛的技艺实际有用的项目，他们最为适合（例如：关键任务软件、我们其他开发者依赖的库等）。

我只是觉得，如果我们不清楚我们在讨论哪类项目，就很难讨论这个话题。

Axios compromised on NPM – Malicious versions drop… #

https://news.ycombinator.com/item?id=47584459

“Batteries included” ecosystems are the only persistent solution to the package manager problem.

If your first party tooling contains all the functionality you typically need, it’s possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won’t be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers. Everything depends on this stuff so the motivation for attacking these common surfaces is high.

I can literally count on one hand the number of 3rd party dependencies I’ve used in the last year. Dapper is the only regular thing I can come up with. Sometimes ScottPlot. Both of my SQL providers (MSSQL and SQLite) are first party as well. This is a major reason why they’re the only sql providers I use.

Maybe I am just so traumatized from compliance and auditing in regulated software business, but this feels like a happier way to build software too. My tools tend to stay right where I left them the previous day. I don’t have to worry about my hammer or screw drivers stealing all my bitcoin in the middle of the night.

bob1029

“自带组件”的生态系统是解决包管理器问题的唯一长久之计。

如果你的自带工具包含了通常所需的所有功能，那么完全可能在不使用任何第三方依赖的情况下高效编程。实际上你可能会用到一两个库，但像 HTTP、TCP、JSON、字符串清理、加密这类关键功能，你不会特意去剥离出来单独依赖。因为这些是攻击者的“显眼包”。既然所有东西都依赖这些组件，那么攻击这些常见接口的动机就非常高。

我可以一只手就数出来我在过去一年里用了多少个第三方依赖。Dapper 是我唯一想到的常用库。偶尔用一下 ScottPlot。我的两个 SQL 提供商（MSSQL 和 SQLite）也都是自带库。这就是为什么我只用这两个 SQL 提供商的主要原因。

也许我只是因为长期在受监管的软件行业经历了合规审查和审计的“折磨”，但这确实感觉像是构建软件的一种更快乐的方式。我的工具往往能安稳地留在原地，一切照旧。我不必担心我的锤子或螺丝刀在半夜偷偷溜走，把我的比特币卷走。

Slop is not necessarily the future #

https://news.ycombinator.com/item?id=47592437

You don’t have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work.

Exactly, thank you for putting it like that.

So far it’s been my observation that it’s only the people who think like the OP who put the situation in the terms they did. It’s a false dichotomy which has become a talking point. By framing it as “there are two camps, it’s just different, none of them is better”, it lends legitimacy to their position.

For an exaggerated, non-comparable example meant only to illustrate the power of such framing devices, one could say: “there are people who think guns should be regulated, and there are people who like freedom”. It puts the matter into an either/or situation. It’s a strategy to frame the conversation on one’s terms.

latexr

你没必要非要在两派之间站队。在我看来，如果你想要为用户打造一个优秀的产品，你也应该把你写出的代码视为一种手艺。高质量的工作成果是无法被替代的。

没错，谢谢你这么一说。

目前为止，我的观察是，只有那些和楼主想法一致的人才会把这种情况定义为那样。这是一种虚假的二分法，现在已经成为了一种常见的论调。通过将其构建为“有两个阵营，只是不同而已，没有谁比谁好”，这种说法反而给他们的立场增添了合法性。

为了用一个夸张且不可类比的例子来说明这种框架手段的威力，我们可以这样说：“有人认为应当管制枪支，还有人则崇尚自由”。这就把问题摆成了一种非此即彼的局面。这是一种将对话引导至对自己有利的框架下的策略。

Artemis II is not safe to fly #

https://news.ycombinator.com/item?id=47582655

I haven’t kept up with Artemis development but I’ve read extensively about Challenger and Columbia. These two parts of the article stood out to me:

Moon-to-Mars Deputy Administrator Amit Kshatriya said: “it was very small localized areas. Interestingly, it would be much easier for us to analyze if we had larger chunks and it was more defined”. A Lockheed Martin representative on the same call added that “there was a healthy margin remaining of that virgin Avcoat. So it wasn’t like there were large, large chunks.”

Followed by:

The Avcoat material is not designed to come out in chunks. It is supposed to char and flake off smoothly, maintaining the overall contours of the heat shield.

This is echoes both Shuttle incidents. Challenger: no gasses were supposed to make it past the o-rings no matter what, but when it became clear that gasses were escaping and the o-rings were being damaged, there was a push to suggest that it’s an acceptable level.

There was a similar situation with heat shield damage and Columbia.

In both cases some models were used to justify the decision, with wild extrapolations and fundamentally, a design that wasn’t expected to fail in that mode /at all/.

I know the points that astronauts make about the importance of manned space exploration, but I agree with this author that it seems to make sense to run this as an unmanned mission, and probably test the new heat shield which will replace the Artemis II design in an unmanned re-entry as well.

oritron

我没有紧跟阿尔忒弥斯计划的开发动态，但我广泛阅读过关于挑战者号和哥伦比亚号灾难的资料。文章中这两部分引起了我的注意：

月球至火星副署长阿米特·克什拉利亚亚说：“那是非常小的局部区域。有趣的是，如果我们有更大的碎片且界限更清晰，分析起来会容易得多。” 同一场通话中的洛克希德·马丁代表补充道，“那块原始的Avcoat材料还有很大的剩余量。所以根本不存在所谓的‘大片’碎片。”

随后：

“Avcoat材料并不是设计成以碎片形式脱落的。它应该以均匀烧蚀和剥落的方式工作，从而保持防热罩的整体外形。”

这与两起航天飞机灾难的情况如出一辙。挑战者号：无论发生什么，都不该有任何气体通过O型环，但当他们发现气体正在泄漏且O型环正在受损时，却有人试图暗示这是一个可接受的程度。哥伦比亚号在隔热罩受损方面也出现了类似的情况。在两种情况下，都利用某些模型来证明决定的合理性，结果出现了过度的推演，本质上，该设计根本未预想会在那种模式下发生故障/根本没发生这种故障的可能/。我知道宇航员们一直强调载人太空探索的重要性，但我同意这篇文章作者的看法，这似乎作为无人任务执行更为合理，并且最好在无人重返大气层时对将取代阿尔忒弥斯二号设计的新隔热罩进行测试。

The Claude Code Source Leak: fake tools, frustrati… #

https://news.ycombinator.com/item?id=47593501

I cringe every time I see Claude trying to co-author a commit. The git history is expected to track accountability and ownership, not your Bill of Tools. Should I also co-author my PRs with my linter, intellisense and IDE?

manbitesdog

每次看到 Claude 试图为提交共同署名，我都尴尬得不行。Git 历史理应记录责任归属，而不是你的工具清单。那我是否也应该连同我的 linter、智能感知和 IDE 一起在 PR 上共同署名？

GitHub backs down, kills Copilot pull-request ads … #

https://news.ycombinator.com/item?id=47587154

Because it’s Microsoft. Categorically incapable of respecting their users.

What’s interesting to me is how many people went like ‘Oh, Satya really gets open source, this time it will be different’.

https://news.ycombinator.com/item?id=17225599

jacquesm

因为是微软。他们绝对无法尊重他们的用户。

最有意思的是，有多少人竟然会觉得“噢，萨提亚真的很懂开源，这次会不一样”。

https://news.ycombinator.com/item?id=17225599

Universal Claude.md – cut Claude output tokens #

https://news.ycombinator.com/item?id=47581841

It seems the benchmarks here are heavily biased towards single-shot explanatory tasks, not agentic loops where code is generated: https://github.com/drona23/claude-token-efficient/blob/main/BENCHMARK.md

And I think this raises a really important question. When you’re deep into a project that’s iterating on a live codebase, does Claude’s default verbosity, where it’s allowed to expound on why it’s doing what it’s doing when it’s writing massive files, allow the session to remain more coherent and focused as context size grows? And in doing so, does it save overall tokens by making better, more grounded decisions?

The original link here has one rule that says: “No redundant context. Do not repeat information already established in the session.” To me, I want more of that. That’s goal-oriented quasi-reasoning tokens that I do want it to emit, visualize, and use, that very possibly keep it from getting “lost in the sauce.”

By all means, use this in environments where output tokens are expensive, and you’re processing lots of data in parallel. But I’m not sure there’s good data on this approach being effective for agentic coding.

btown

看来这里的基准测试很大程度上偏向于单次解释任务，而不是生成代码的智能体循环：https://github.com/drona23/claude-token-efficient/blob/main/BENCHMARK.md

而且我认为这提出了一个非常关键的问题。当你深入到一个正在对实时代码库进行迭代的项目中时，Claude 默认的啰嗦（即允许其在写入大量文件时解释其行为背后的原因），是否能让会话在上下文窗口变大时保持更连贯和聚焦？通过这种方式，它能否通过做出更优、更切实可行的决策从而节省总体 Token（令牌）？

原始链接中有一条规则写道：“无冗余上下文。不要重复会话中已确立的信息。” 对我来说，我更希望这样。那是面向目标的准推理代币，我确实希望它能发出、展示并加以利用，这很可能防止它“迷失方向”。

当然，务必在输出 Token 昂贵且你需要并行处理大量数据的环境中应用这种方法。但我不确定这种方法在智能体编程方面是否有效，目前并没有充分的数据支持这一点。