Skip to main content

黑洞资源笔记

  1. 在线科研总是被琐碎重复的工作拖慢:文献爆炸难消化,环境依赖调试不停,实验记录分散难管理,写论文也要折腾多个工具。

    DeepScientist 是一个本地优先的 AI 研究工作室,让你在 15 分钟内搭建自己的 AI 科研伙伴,专注前沿探索,分分钟接手繁重“搬砖”活。

    它不仅能:
    - 从论文或研究问题启动完整项目,一路跟踪、分支、对比实验结果;
    - 自动恢复并复用基线代码环境,搞定依赖和环境问题;
    - 持续运行实验,保留全部失败与成功路径,助力深度剖析;
    - 生成论文材料,配合本地 LaTeX 和 PDF 编译,一气呵成;
    - 支持网页界面、终端界面和多种即时通讯工具实时协作;

    更重要的是:代码、实验、笔记和写作都集中管理,你完全掌控实验进程,想暂停接管随时都行,拒绝黑箱操作。

    适合研究生、科研工程师、实验室团队长远研究,不想把新奇想法随意丢云端,也不想被环境依赖耽误进度的用户。
  2. 经常觉得写代码光靠提示不够,想要一个能帮你从零搭建项目、调试、执行代码甚至管理复杂流程的 AI 助手?

    Goose 是一款本地运行的、可扩展的 AI agent,不仅能写代码,还能执行代码、完成测试,甚至能和外部 API 交互,真正做到自动化工程任务全流程。

    主要功能:
    - 从头构建项目,自动生成和运行代码
    - 调试失败,快速定位修复
    - 支持多模型配置,优化性能和成本
    - 无缝集成 MCP 服务器,兼容各种大型语言模型
    - 提供桌面应用和命令行接口,灵活适配不同开发场景

    适合开发者、工程师和创新团队,用它加速研发效率,把时间花在创新上,而不是管理琐事。
  3. 在线协作开发常常需要协调多个AI助手、项目任务和沟通渠道,流程复杂不便管理。

    OpenSwarm 是基于 Claude Code CLI 的自治AI开发团队协调器。OpenSwarm 能自动从 Linear 拿任务,执行 Worker/Reviewer 代码生成与评审,还能在 Discord 上同步进度,利用 LanceDB 实现长期认知记忆,让AI团队像真人团队一样协作。

    主要功能:

    - 多代理流水线,支持 Worker、Reviewer、Tester、Documenter 多阶段自动协作;
    - 集成 Linear 任务管理,自动抓取和更新任务状态;
    - 通过 Discord 机器人,实时控制和查看任务进展,支持命令调度和对话;
    - 支持 LaurentDB 向量存储,实现跨会话的认知记忆回顾;
    - 支持多模型提供者,如Claude和OpenAI Codex,运行时可动态切换;
    - 自动监控PR,处理CI失败、合并冲突和重试,释放人工干预压力;
    - 丰富的终端交互界面(TUI),方便开发者操作与管理;
    - 支持多项目调度和自动任务分配,提升协作效率;
    - 具备代码依赖分析及变更影响检测功能,保障代码安全和准确;

    适合需要用AI自动化代码开发和评审、提升团队协作效率的开发者和团队。
  4. 当Claude Code可以被任意修改,开发者们该怎么想 | 帖子

    有人从泄露的 sourcemap 中成功重建了 Claude Code 2.1.88 的完整可执行文件,Computer Use 功能已验证可用。这件事本身是个技术壮举,但更值得关注的是它暴露出来的一系列问题。

    事情的起点很简单:Claude Code 的 npm 包里藏着 sourcemap,而 sourcemap 里藏着原始 TypeScript 源码。有人用 Claude Opus 写了一套依赖树重建系统,把这些信息还原成了可以本地编译运行的完整工程,并推上了 GitHub。

    这不是运行一个模型。模型还在 Anthropic 的服务器上,你的用量限制一点没少。改掉的是客户端逻辑,是工具调用的分发方式,是上下文窗口的管理策略。就像拿到了一辆车的完整设计图纸,油还是要自己加,但你终于知道变速箱是怎么工作的了。

    有网友提到,最实际的收益其实是透明度:你现在可以看到每次 API 调用实际发送了什么,token 消耗的投诉变得有凭有据,而不是在猜。

    社区随即引起广泛讨论,主线是兴奋,但最高赞的评论几乎全是警告。有人对比了另一个“原版重建”仓库,发现了5个被篡改的文件和38个未声明的新增文件,包括一套悄悄接入 API 客户端的加密支付系统,以及一个默认开放 0.0.0.0 无认证管理访问的 Web 终端服务。

    有观点认为大模型能帮你审计这些代码,原作者的回答是:500K 行代码,让 Claude 找藏得很深的恶意逻辑,这事别太乐观。

    DMCA 清场已经开始。有观点认为 Anthropic 此时不如顺势开源,社区会帮他们做免费的安全审计和 QA。这话有道理,只是公司的利益计算很少这么直接。

    这份源码是 2.1.88 的快照。Claude Code 迭代很快,几周后这份代码就会和主线产生大量差异。你拿到的是一张已经开始过期的地图。

    问题是,有多少人真的有能力在这张地图和持续更新的现实之间保持同步,同时还能确保自己跑的不是别人塞进来的挖矿程序。
  5. 两行代码修复Token暴耗问题:一位IT从业者用Codex逆向Claude Code找到根因 | 帖子

    Claude Code在恢复历史会话时,因一个过滤函数错误地丢弃了工具声明记录,导致每次恢复都要重新处理全部上下文,prompt缓存完全失效。实际测试显示缓存命中率从99%跌至26%,修复仅需两行代码。Anthropic工程师Boris已确认漏洞存在并将在下一版本修复,但也指出这只是众多token消耗问题之一。

    有人用Codex逆向了泄露的Claude Code源码,找到了一个藏得很深的缓存漏洞,并写了个补丁。数据很直白:修复前,每次恢复会话的缓存命中率在26%左右;修复后,第二轮起稳定在99%。

    根因在一个叫`db8`的过滤函数。它在保存会话文件时,会把所有`attachment`类型的消息丢掉。听起来无害,但`deferred_tools_delta`这种记录"我已经跟模型说过哪些工具"的附件也被一并过滤掉了。

    下次你恢复会话,Claude Code会重新扫描历史消息来判断要不要重新声明工具。但这些记录已经被删了,它什么也找不到,于是把所有工具从头声明一遍。系统提示的位置变了,消息数组的长度变了,cache prefix整个失效,全部上下文变成`cache_creation`重新计费。对话越长,越烧钱。

    修复是两行:在`db8`的白名单里加上`deferred_tools_delta`和`mcp_instructions_delta`,让这两类记录能够存活到会话文件里。

    Claude Code团队的Boris在帖子下方确认了漏洞属实,并表示将在下一个版本中修复。不过他同时泼了点冷水,说这个修复的实际收益"不足1%",言下之意token暴耗另有其因。

    讨论随即引起广泛关注。有观点认为这个漏洞的存在本身说明了一个问题:Anthropic一边声称内部工程师已经大规模用AI写代码、拥有"近乎无限的工程产能",一边让一个外部社区成员用竞争对手的产品在泄露的源码里发现并修复了一个影响所有付费用户的基础缓存bug。有网友直接引用Dario那句"我们的工程师已经不写代码了",语气里全是讽刺。

    还有个更刻薄的解读:Anthropic"泄露"源码,免费得到了一轮社区QA。

    有观点认为,这件事最值得注意的部分不是漏洞本身,而是它暴露的一种可能性:当工程团队完全依赖AI生成代码,谁来对系统行为真正负责?这些"deferred_tools_delta被过滤"式的静默错误,不会触发任何报错,只会让你的账单悄悄变贵。

    不过,应用这个补丁本身存在合规风险。社区有多位用户提醒,Anthropic的服务条款明确禁止对产品进行逆向工程,以及绕过任何计费控制机制。帖子链接的GitHub仓库除了修复缓存漏洞,还有一个强制设置1小时cache TTL的补丁,后者明显是在绕过订阅等级限制。Boris对漏洞的确认,并不等于对这个补丁本身的背书。

    如果你不想冒被封号的风险,最简单的规避方式是:不要恢复历史会话,每次开新对话。

    这个问题现在已经公开。修复会来。但那些你不知道在哪里的"静默漏洞",大概还在计着费。
  6. 从工具到结果:AI如何重写服务业的竞争规则 | 推文

    AI正在把软件公司变成服务公司。卖工具的在和模型赛跑,卖结果的每次模型升级都让自己更强。外包业务是最佳切入点,因为预算现成、边界清晰、替换阻力最小。

    每个做AI工具的创业者都在问同一个问题:下一版Claude出来,我的产品会不会变成一个功能?

    这个担心是对的。

    卖工具,你在和模型厂商赛跑。卖结果,模型每次升级都在帮你降本提速。一家公司可能每年花一万美元买QuickBooks,花十二万美元雇一个会计关账。下一个伟大的公司,直接把账关掉。

    + 智能与判断

    软件工程师的工作,大部分是智能活,小部分是判断活。把需求翻译成代码、写测试、修bug,规则很复杂,但终究是规则。判断不一样,判断需要品味和本能,是在大量失败里沉淀出来的东西。

    一年前,大多数Cursor用户把AI当成补全工具。今天,超过一半的任务由智能体发起,不再是人类。软件工程在所有职业的AI工具使用中占比过半,其他所有类别还在个位数。原因很简单:软件工程以智能活为主,AI已经能独立完成大部分,把判断留给人类。

    这个临界点,软件工程业最先越过。其他每个行业都会跟上来。

    + 副驾驶与自动驾驶

    副驾驶卖工具,自动驾驶卖结果。

    早期的逻辑很清楚:模型还不够强,就先给专业人士一个工具,让他们自己决定怎么用。Harvey卖给律所,Rogo卖给投行。专业人士是客户,工具让他们更高效,输出结果由他们负责。

    现在不一样了。模型足够聪明,某些领域最好的切入姿态就是自动驾驶。Crosby卖给需要起草NDA的公司,不是卖给外部律师。WithCoverage卖给需要保险的CFO,不是卖给经纪人。客户直接买结果。

    任何领域里,智能活占比越高,自动驾驶赢的时间就越早。

    + 外包是楔子

    软件预算和服务预算的比例大约是一比六。自动驾驶的真实市场,是一个行业里所有劳动力支出,内部的和外包的加在一起。

    但起点应该在外包已经成熟的地方。

    一个任务已经被外包,说明三件事:公司接受这件事可以在外部完成;预算科目清晰,可以直接替换;买家已经在购买结果,不是购买时间。用AI原生服务商替换外包合同,是供应商切换。替换内部人员,是组织重组。阻力完全不同。

    外包的智能活是楔子,内部的判断活是长期市场。

    + 机会在哪里

    Sequoia把各行业的服务市场按智能-判断比例和外包程度做了一张地图。

    几个机会值得单独说:

    保险经纪(1400-2000亿美元),最大的市场。标准商业险高度标准化,经纪人的价值本质上是比价和填表,纯智能活。分销极度碎片化,没有单一巨头控制客户关系。

    会计和审计(500-800亿美元外包),美国五年内流失了约34万名会计,75%的注册会计师接近退休,人才供给结构性短缺,反而让这个行业比其他任何行业都更愿意接受AI。

    医疗收入周期(500-800亿美元),人们听到“医疗”就以为是判断活,但账单层几乎是纯智能活。医疗编码是把临床记录翻译成约七万个标准化ICD-10代码,规则复杂但终究是规则。

    管理咨询(3000-4000亿美元),市场最大,但判断活占比也最高。有意思的问题是:AI能不能把咨询拆开,数据收集和基准分析自动化,战略建议留给人类?最佳竞争者还不明朗。

    + 真正的困境

    2025年增长最快的AI公司是副驾驶。2026年,很多会尝试转成自动驾驶。他们有产品,有客户关系。问题是,卖结果意味着把自己的客户从这件事里切走。这正是纯自动驾驶公司的机会。

    创新者窘境的经典形态:你最了解客户需要什么,但你最没办法给他们想要的那个版本。
  7. 看懂 Claude Code 提示词:验证智能体、反过度工程、记忆压缩才是核心 | Claude Code Prompts

    Claude Code的npm源码包因人为失误意外泄露,有人从中逆向整理出26个提示词,覆盖系统指令、工具调用、智能体协作、记忆管理等全部模块,随后以MIT协议重新授权开源。这份材料本质上是一份提示词工程的实战教材。

    有个细节值得注意:Anthropic事后将这次泄露定性为“人为失误”。200美元一个月的工具,整个提示词架构就这样从npm包里被人拆了出来。

    这26个提示词按功能分得很清晰:1个系统提示词负责身份定义和工具路由,11个工具提示词处理文件读写、shell执行、搜索等操作,5个智能体提示词分别对应探索、架构、验证、文档等角色,4个记忆提示词管理上下文压缩,1个协调提示词处理多智能体编排,还有4个工具提示词生成标题、摘要、建议。

    读完这些提示词,有几个设计决策让人印象深刻。其一是专门设置了一个“验证专家智能体”,它的职责就是在代码上线前想办法把它搞坏。这不是可选项,是写进架构里的。其二是反过度工程规则被明确写入系统提示词,“不要做用户没有要求的功能”。听起来像废话,但显然Anthropic认为有必要把它钉进去。其三是记忆压缩分9个章节,且保证每一条用户消息都被保留。

    有观点认为,大家都盯着系统提示词,真正值得研究的反而是那4个记忆提示词。多数AI编程工具在请求之间会忘掉一切,而Claude Code能记住项目结构和之前的编辑操作,这才是它用起来像同事而不像聊天机器人的原因。

    有网友提到,这个开源仓库引起广泛讨论,也有人认为被过度渲染了,从npm包里逆向提示词并不算什么技术壁垒,真正的护城河是模型质量和训练数据。这个说法大概70%是对的,提示词工程本身不是秘密,但好的提示词架构要花多少时间踩坑才能收敛到这个形态,那是另一回事。

    每个提示词都从零重写以符合法律要求,意图相同,没有逐字引用。MIT协议,可以直接用。

    如果你在自己搭智能体,有一个问题可能值得先想清楚:你的系统里有没有一个专门负责破坏自己输出的角色?
  8. 在线科研和软件优化往往需要不断尝试不同方案,修改代码、跑实验,再根据结果决定保留或放弃,整个过程极其复杂且耗时。

    awesome-autoresearch 这个项目汇总了众多公开可用的 autoresearch(自动化反复试验优化)案例,覆盖科学研究、软件优化、金融交易、评测红队、安全攻防等多个领域。

    该项目重点展示了 autoresearch 在真实工作流中的应用,比如自动修改训练脚本并迭代保留性能更优的模型版本,自动调优 GPU 内核,结合自动化背测改进交易策略,甚至用在自动化红队攻击策略验证。

    主要亮点:
    - 多领域 autoresearch 应用汇总,帮助快速理解自动实验循环模式;
    - 详细案例展示如何通过“修改-验证-保留/舍弃”循环持续提升性能;
    - 多个基于 Karpathy 原创 autoresearch 思路的实用开源实现;
    - 出色适合科研人员、系统优化工程师、量化研究员等借鉴。

    支持 Python、Shell 多种环境,方便上手复现或者定制。
  9. 在线训练PyTorch构建块,专为 OLMo 生态系统打造,助力大规模语言模型开发。

    AllenAI推出的 OLMo-core,集成了训练、推理的全套模块,不仅提供了官方训练脚本支持多GPU分布式训练,还能无缝接入 Hugging Face Transformers 和高效的 vLLM 推理引擎。

    主要亮点:

    支持最新的 OLMo-2(32B)和 OLMo-3(7B/32B)模型训练脚本;
    兼容 PyTorch,支持 torchrun 与 Beaker 一键分布式启动训练;
    提供多种可选依赖支持加速(flash-attn、TransformerEngine、torchao 等);
    通过 Hugging Face Transformers 和 vLLM 实现高效推理,加速模型部署;
    提供交互式聊天演示和评测工具,方便研究和测试;
    Docker 镜像包含所有依赖,便于快速启动环境。
    安装简易,pip 安装即用:

    pip install ai2-olmo-core
    官方文档:olmo-core.readthedocs.io

    适合科研人员、AI工程师、NLP开发者使用,全面提升大模型训练与推理效率。