SIGNALFEED文章库 ↗论文库 ↗归档 ↗

8月2日2026 · 星期日

从 19 条抓取中筛选 12 条 · twitter × 3 账号 · 01:54 UTC 生成

今日信号 · 高度即评分 · 点击直达

  1. OpenAI Astra模型实现十项重大数学突破，包括推翻Connes刚性猜想9.0
  2. 优化LLM流式输出的UI渲染性能7.0
  3. 多模态能力是模型成为主力选择的必要条件7.0
  4. 现代AI编码工具上下文压缩能力提升，减少handoff需求7.0
  5. GitHub 仓库为 AI 编程助手提供 160 多个营销技能文件7.0
  6. Autoresearch 将自主 AI 实验能力带入 Claude Code 和 Codex7.0
  7. AI Knowledge Graph：用大模型自动将文本转为交互式知识图谱的工具7.0
  8. 创业者分享未及早注册域名和商标的惨痛教训6.0
  9. DeepSeek 邀请开源 Agent Harness 开发者参与内测6.0
  10. Search by Image 浏览器扩展聚合 30+ 反向图片搜索引擎6.0
  11. 开发者批评同事在代码审查中拒绝阅读生成的代码5.0
  12. 对用SVG绘图测试衡量AI智能水平的质疑5.0
019.0

OpenAI Astra模型实现十项重大数学突破，包括推翻Connes刚性猜想

OpenAI的下一个主要模型Astra生成了10项重要数学证明，包括推翻Connes刚性猜想和非sofic群的存在性。每项证明都附有Lean证书和思维链演练，确保了形式化验证和透明度。这些成果涵盖von Neumann代数、球体填充、电路复杂性和图论等多个领域。 这标志着AI辅助数学的关键时刻，表明大语言模型不仅能提出猜想，还能严格证明复杂定理。Lean证书的使用弥合了非形式推理与形式化验证之间的鸿沟，可能加速数学研究。这也预示着AI系统能够为纯科学贡献原创性、高影响力的成果。 对Connes刚性猜想的推翻表明，ICC property (T)群并非由其von Neumann代数唯一确定，这是一个长期悬而未决的问题。非sofic群的证明解决了几何群论中的一个重大问题。所有10项证明均以Lean形式化发布，允许独立验证，而思维链演练则提供了对模型推理过程的洞察。

@thsottiaux引用推文The week was for efficiency. The weekend is for 10 major breakthroughs in science. There will be signs.展开原推文收起原推文

@thsottiaux

The week was for efficiency. The weekend is for 10 major breakthroughs in science. There will be signs.

@SebastienBubeck

yes, nonsofic groups exist: this statement is one of many new beautiful results proved by Astra, our next major model. We're releasing 10 such Astra proofs, complete with lean certificates and CoT walkthroughs for each of them. The results are wide-ranging, from von Neumann algebras (disproof of Connes' Rigidity Conjecture) to better bounds for high dimensional sphere packing, for circuit complexity, for monochromatic triangles in multicolored graphs, and more. More thoughts here: https://openai.com/index/ten-advances-in-mathematics/

背景
Connes刚性猜想于1980年提出，假设某些群（ICC property (T)群）完全由其von Neumann代数决定。非sofic群是指无法用有限对称群逼近的群，其存在性是一个重要的开放问题。Lean是一种证明助手和函数式编程语言，能够对数学证明进行形式化验证，确保其逻辑正确。

8月1日 14:13在 X 打开#AI #mathematics #OpenAI #breakthrough #Lean

027.0

优化LLM流式输出的UI渲染性能

一位开发者分享了在应聘AI Agent工程师时总结的LLM流式输出UI渲染优化技巧。核心建议包括增量更新、节流、轻量组件以及渲染与交互逻辑分离。 随着LLM驱动的应用日益普及，流畅的流式UI对用户体验至关重要。这些技术有助于防止性能下降，确保界面响应迅速，直接影响用户满意度和产品质量。 关键建议包括：避免每次收到token都重新渲染全部内容；采用增量DOM更新或在节流窗口（如100-300毫秒）内批量刷新。用轻量组件替代代码高亮等重型组件。将渲染与编辑、审批等交互功能分离。

@xiongchun007@dotey 转推1 张图片应聘 AI Agent 工程师，面试官问了一个这样的问题，我刚好做过，如图。 问：在 LLM 流式输出模式下，如何最大限度的保证 UI 渲染的性能？ 核心是别让 UI 做蠢事： 1. 不要每次 token 到来都从头渲染整段内容 应该增量追加节点，或按节流窗口批量刷新。否则输出越长，每次重绘成本越高。 2. 不要塞重型 UI 组件。比如现成的代码高亮渲染、重型表格等，可以自己封装轻量渲染组件。 3. 流式渲染要节流 LLM token 来得很碎，UI 不需要跟每个 token 同频刷新。比如 100-300ms 合并一次，观感仍然实时，性能稳定很多。也可以结合字符串长度节流。 5. 交互能力和渲染能力分离 对输出内容的二次加工、审批动作等做分离。 一句话：LLM 流式 UI 的性能优化，不是更快地重绘，而是少重绘、轻节点、按需交互。 大家继续补充...原推文媒体预览展开原推文收起原推文

@dotey 转推了

@xiongchun007

应聘 AI Agent 工程师，面试官问了一个这样的问题，我刚好做过，如图。 问：在 LLM 流式输出模式下，如何最大限度的保证 UI 渲染的性能？ 核心是别让 UI 做蠢事： 1. 不要每次 token 到来都从头渲染整段内容 应该增量追加节点，或按节流窗口批量刷新。否则输出越长，每次重绘成本越高。 2. 不要塞重型 UI 组件。比如现成的代码高亮渲染、重型表格等，可以自己封装轻量渲染组件。 3. 流式渲染要节流 LLM token 来得很碎，UI 不需要跟每个 token 同频刷新。比如 100-300ms 合并一次，观感仍然实时，性能稳定很多。也可以结合字符串长度节流。 5. 交互能力和渲染能力分离 对输出内容的二次加工、审批动作等做分离。 一句话：LLM 流式 UI 的性能优化，不是更快地重绘，而是少重绘、轻节点、按需交互。 大家继续补充...

背景
LLM流式输出会逐个token生成文本，可能触发频繁的UI更新。若不优化，每次更新可能导致完整重绘，造成界面卡顿。增量DOM更新等技术仅修改变化部分，节流则限制更新频率。轻量组件降低渲染开销，关注点分离使UI在复杂交互时保持响应。

8月1日 20:51在 X 打开#LLM #UI performance #streaming #frontend #AI agent

037.0

多模态能力是模型成为主力选择的必要条件

AI 评论员 @mranti 发推表示，没有多模态能力，模型只能是可选模型之一，无法成为主力模型。该观点被 @dotey 转发，进一步强调了多模态功能对于 AI 模型成为主流的关键性。 这凸显了 AI 行业的战略转变，多模态模型正成为主力应用的标准。企业和开发者可能需要优先发展多模态能力以保持竞争力，因为纯文本模型可能被边缘化。 该推文未提供技术细节，但反映了关于模型架构和能力需求的持续讨论。多模态模型能处理文本、图像、音频和视频，实现更丰富的交互。该观点暗示，缺乏这种多功能性会限制模型在现实世界集成场景中的实用性。

@mranti@dotey 转推这句话是对的，没多模态，你的模型只能是可选模型之一，无法成为主力模型。展开原推文收起原推文

@dotey 转推了

@mranti

这句话是对的，没多模态，你的模型只能是可选模型之一，无法成为主力模型。

@immortal_00994

牢粱可能犯了路线错误，多模态能力很重要。。。

背景
多模态 AI 模型整合多种数据类型（如文本、图像、音频），以跨模态理解和生成内容。近年来，GPT-4V 和 Gemini 等模型通过结合视觉和语言树立了新标杆。行业趋势正朝着能无缝处理多样化输入的模型发展，因为它们更适应视觉问答、视频分析和具身 AI 等复杂任务。

8月1日 05:14在 X 打开#multimodal #AI models #strategy #industry commentary

047.0

现代AI编码工具上下文压缩能力提升，减少handoff需求

@dotey 在推文中指出，为了节省上下文而使用 handoff 开启新会话的做法，在 Codex 等工具具备强大内置上下文压缩能力后已不再必要。手动 /compact 或自动压缩足以处理长上下文，但 handoff 在跨 Agent 会话或无关任务中仍有价值。作者强调设置严格的验收标准以确保质量，并举例在迁移任务中强制要求 UI 像素级一致。 该建议反映了AI编码工作流最佳实践的转变，因为模型现在能更可靠地处理长上下文。这使开发者免于不必要的上下文管理开销，并鼓励专注于明确的验收标准，直接影响代码质量和迭代速度。讨论凸显了 Codex 和 Claude Code 等工具不断演进的能力，影响开发者如何组织会话。 Codex 在 token 用量接近上下文窗口限制时会自动触发压缩，也可手动执行 /compact。过于频繁的压缩会影响 Prompt Caching 的利用。作者指出，即使上下文用量达到 80%，由于 Harness 层会将最新指令置于提示末尾，现代模型仍能保持对当前任务的注意力。Handoff 在跨 Agent 传递状态（如从 Claude Code 到 Codex）或使用 fork/sidechat 分支对话时仍然有用。

@dotey串推 3 条3 段 · 4 张图片为了节约上下文 handoff 新开 Session，这在半年一年前是很好的实践，现在没太有必要，因为 codex 自己上下文压缩做的很好了，或者 /compact 一下继续就足够了。 当然如果关系不大的任务，还是新开 Session 更好。 当然除此之外 handoff 还是适用于跨 Agent session 的，比如 Claude Code 里面没完成的 session 让 Codex 继续。 不过我更习惯于 Claude Code 里面用 Fable 5 写技术方案文档，然后反复 Review、修改后把文档交给 Codex，配合 /goal 让它按照文档执行推进。 当然设置好严格的验收标准也很有必要，否则它会偷懒。 之前一个迁移任务没有设置验收标准，它就给我交付了一个差强人意的，离我要求的还有比较大差距。（参考图1） 重新加上了验收标准：UI 界面像素要和原版完全一致，那么它每一步都会截图对比像素差异，直到完全一致（或者可以忽略的差异） > 引用 @Tz_2022: 摸索出一个在 codex 里做连续任务节省大量 token 消耗且不损失上下文质量的极简方法。。。 > > 一共就两步： > > 第一步，在一项任务完成后用以下提示词： > > 请针对 [任务描述] 给我一个 handoff，用于后续任务开发 > > 第二步，开新对话 session，把生成的 handoff 作为第一条信息发给 AI，开始做后续任务即可 > > 它的省 token 原理很简单，就相当于对之前任务的上下文窗口做了一次有针对性的极限摘要提取和压缩梳理，扔掉了上下文中类似原始代码/日志记录等冗余信息，只保留最核心的推理逻辑和项目任务理解，所以 AI 就可以轻装上阵快速进入下一项任务的开发了。。。原推文媒体预览+3展开原推文收起原推文

@dotey串推 3 条

为了节约上下文 handoff 新开 Session，这在半年一年前是很好的实践，现在没太有必要，因为 codex 自己上下文压缩做的很好了，或者 /compact 一下继续就足够了。 当然如果关系不大的任务，还是新开 Session 更好。 当然除此之外 handoff 还是适用于跨 Agent session 的，比如 Claude Code 里面没完成的 session 让 Codex 继续。 不过我更习惯于 Claude Code 里面用 Fable 5 写技术方案文档，然后反复 Review、修改后把文档交给 Codex，配合 /goal 让它按照文档执行推进。 当然设置好严格的验收标准也很有必要，否则它会偷懒。 之前一个迁移任务没有设置验收标准，它就给我交付了一个差强人意的，离我要求的还有比较大差距。（参考图1） 重新加上了验收标准：UI 界面像素要和原版完全一致，那么它每一步都会截图对比像素差异，直到完全一致（或者可以忽略的差异） > 引用 @Tz_2022: 摸索出一个在 codex 里做连续任务节省大量 token 消耗且不损失上下文质量的极简方法。。。 > > 一共就两步： > > 第一步，在一项任务完成后用以下提示词： > > 请针对 [任务描述] 给我一个 handoff，用于后续任务开发 > > 第二步，开新对话 session，把生成的 handoff 作为第一条信息发给 AI，开始做后续任务即可 > > 它的省 token 原理很简单，就相当于对之前任务的上下文窗口做了一次有针对性的极限摘要提取和压缩梳理，扔掉了上下文中类似原始代码/日志记录等冗余信息，只保留最核心的推理逻辑和项目任务理解，所以 AI 就可以轻装上阵快速进入下一项任务的开发了。。。

@Tz_2022

摸索出一个在 codex 里做连续任务节省大量 token 消耗且不损失上下文质量的极简方法。。。 一共就两步： 第一步，在一项任务完成后用以下提示词： 请针对 [任务描述] 给我一个 handoff，用于后续任务开发 第二步，开新对话 session，把生成的 handoff 作为第一条信息发给 AI，开始做后续任务即可 它的省 token 原理很简单，就相当于对之前任务的上下文窗口做了一次有针对性的极限摘要提取和压缩梳理，扔掉了上下文中类似原始代码/日志记录等冗余信息，只保留最核心的推理逻辑和项目任务理解，所以 AI 就可以轻装上阵快速进入下一项任务的开发了。。。

频繁到 80% 并不是什么大问题，compact 并不会频繁执行，因为执行太多一方面影响正在执行任务上下文准确性（也许压缩后，需要重新补充上下文），一方面也不能充分利用 Prompt Caching。https://x.com/Tz_2022/status/2083627052721131721?s=20 并不用太担心上下文 80% 影响性能的问题，因为现在模型处理长上下文能力已经很强，Harness 层也会补充一些提示信息，最新要做的事都在 prompt 最后的位置，能保证模型执行当前任务的注意力，所以对任务执行影响不大。 Handoff 并不能解决这种问题，只能适当缓解，因为新开session 也会很快因为补充上下文又会满。你不可能一直盯着它也没必要。 最佳方式就是相信它能自己处理好，设置好如何验证让它少走弯路少人工干预才是最佳使用方式。 > 引用 @Tz_2022: @dotey 我就是因为这两天 gpt-5.6 sol max 做任务 auto compact 频繁突破 80%，才逼得我开始用 handoff 来解决问题。。。🙃🙃🙃

fork 和 btw/sidechat 都是很好用的 https://x.com/ruofeng_x/status/2083689498727383497?s=20 > 引用 @ruofeng_x: @dotey 交接Handoff 确实是很有必要的，特别是你切换不同的AI 做同一个东西，我一般也会这么做，我还在想要不要一直维护这样一个东西？另外还有一个我觉得也很好用就是绘画分支，当想继续目前的回话做一些其他的方向，又怕污染当前的回话时，很好用。

背景
在AI编码工具中，“上下文”指模型用于理解当前任务的对话历史和代码片段。随着会话增长，上下文可能超出 token 限制，导致性能下降或成本增加。“Handoff”是一种技术，生成会话摘要并传递给新会话，从而重置上下文。“上下文压缩”或“压缩”是自动精简对话、保留关键信息并丢弃冗余的过程。Codex 和 Claude Code 是流行的AI编码助手，与开发环境集成。
社区讨论
一些用户认为当自动压缩过于频繁（如使用 GPT-5.6 sol max 时）时，handoff 仍然必要，否则会干扰工作。其他人同意在切换不同AI工具或探索分支任务时，handoff 有助于保持会话整洁。原作者坚持认为，信任工具的压缩能力并设置验证标准比手动 handoff 更有效。

8月1日 18:25在 X 打开#AI coding #Codex #Claude Code #context management #workflow

057.0

GitHub 仓库为 AI 编程助手提供 160 多个营销技能文件

一个名为“marketing-skills”的 GitHub 仓库整理了 160 多个技能文件，可加载到 OpenAI Codex 和 Claude Code 等 AI 编程助手中。这些文件为 SEO、内容策略、付费投放和着陆页生成等营销任务提供了详细的分步执行计划。这些技能旨在将笼统的 AI 建议转化为可操作的、针对具体产品的营销指导。 这解决了开发者和小团队的一个常见痛点：AI 助手经常给出模糊的营销建议，缺乏具体步骤。通过提供即用型技能文件，它使非营销人员能够直接在编码环境中执行专业的营销任务。这可能会降低独立开发者和初创公司进行有效数字营销的门槛，因为他们负担不起专门的营销人员。 该仓库涵盖九大类，包括 SEO、内容策略、付费投放、着陆页生成和冷启动等。每个技能文件都包含完整的执行流程，当与项目上下文文件结合使用时，AI 会生成针对特定产品的输出，而非泛泛的通用建议。这些技能兼容 Codex 和 Claude Code，采用 Markdown 文件格式并带有 YAML 前置元数据，遵循 Anthropic 官方技能仓库的模式。

@GitHub_Daily原推文1 张图片让 AI 编程助手帮忙做 SEO 和内容营销，给出来的建议经常太笼统，缺少具体执行步骤。 Marketing Skills 整理了 160 多个营销领域的 Skill 文件，装进 Codex 或 Claude Code 就能用。 覆盖 SEO、内容策略、付费投放、着陆页生成、冷启动等九大类，每个 Skill 都带完整的执行流程。 GitHub：http://github.com/kostja94/marketing-skills 搭配项目上下文文件使用，生成的内容是针对具体产品的，不是那种泛泛的通用建议。 适合独立开发者和小团队，不想专门雇营销人员，AI 代劳一部分营销工作。原推文媒体预览展开原推文收起原推文

@GitHub_Daily

让 AI 编程助手帮忙做 SEO 和内容营销，给出来的建议经常太笼统，缺少具体执行步骤。 Marketing Skills 整理了 160 多个营销领域的 Skill 文件，装进 Codex 或 Claude Code 就能用。 覆盖 SEO、内容策略、付费投放、着陆页生成、冷启动等九大类，每个 Skill 都带完整的执行流程。 GitHub：http://github.com/kostja94/marketing-skills 搭配项目上下文文件使用，生成的内容是针对具体产品的，不是那种泛泛的通用建议。 适合独立开发者和小团队，不想专门雇营销人员，AI 代劳一部分营销工作。

背景
OpenAI Codex 和 Anthropic 的 Claude Code 等 AI 编程助手是帮助开发者通过自然语言命令编写、审查和管理代码的工具。它们可以通过“技能文件”进行扩展——这些 Markdown 文档为特定任务提供专门的指令。技能文件的概念由 Anthropic 的公共技能仓库推广，允许用户创建和共享可重用的指令集。用于 AI 助手的营销技能是一种新颖的应用，因为这些工具通常用于软件开发而非营销。

8月1日 13:30在 X 打开#AI tools #marketing #GitHub #SEO #developer tools

067.0

Autoresearch 将自主 AI 实验能力带入 Claude Code 和 Codex

一个名为 Autoresearch 的开源工具，灵感来自 Andrej Karpathy 的原始脚本，现在能让 AI 智能体使用 Claude Code 和 Codex 自主迭代代码实验。用户只需设定目标和量化指标，智能体便会反复修改代码、运行验证，仅保留有益的更改，并自动回滚效果变差的修改。该项目提供了 14 个子命令，涵盖调优、找 Bug、安全审计、发版等任务，并内置 9 个安全钩子以防止误操作。 该工具大幅降低了自动化 AI 驱动实验的门槛，让开发者无需人工监督即可在一夜之间运行数百轮优化。通过与 Claude Code 和 Codex 等流行编程智能体集成，它将自主研究能力从 Karpathy 最初的单 GPU 机器学习训练场景扩展到更广泛的软件工程任务。这有望加速开发流程、提升代码质量，并使 AI 辅助的迭代改进惠及更多用户。 Autoresearch 已在 GitHub 上开源，仓库地址为 uditgoenka/autoresearch。它包含 14 个用于不同开发任务的子命令和 9 个防止意外操作的安全钩子。该工具专为与 Claude Code 和 Codex 这两个主流 AI 编程智能体配合使用而设计。用户定义目标和量化指标后，智能体便会根据性能自主循环进行代码修改、验证和回滚。

@GitHub_Daily原推文1 张图片AI 大神 Karpathy 之前做了个 autoresearch 脚本，能让模型一晚上自动跑上百轮实验调优。 Autoresearch 这个开源项目把同样的思路搬到了 Claude Code 和 Codex 上。 给一个目标和量化指标，Agent 自己循环改代码、跑验证，效果好留着，差了自动回滚。 GitHub：http://github.com/uditgoenka/autoresearch 提供 14 个子命令，涵盖调优、找 Bug、安全审计、发版等场景，还内置 9 个安全钩子防误操作。 设好目标挂着跑就行，起床看结果。适合想让 AI 编程助手自动迭代的朋友。原推文媒体预览展开原推文收起原推文

@GitHub_Daily

AI 大神 Karpathy 之前做了个 autoresearch 脚本，能让模型一晚上自动跑上百轮实验调优。 Autoresearch 这个开源项目把同样的思路搬到了 Claude Code 和 Codex 上。 给一个目标和量化指标，Agent 自己循环改代码、跑验证，效果好留着，差了自动回滚。 GitHub：http://github.com/uditgoenka/autoresearch 提供 14 个子命令，涵盖调优、找 Bug、安全审计、发版等场景，还内置 9 个安全钩子防误操作。 设好目标挂着跑就行，起床看结果。适合想让 AI 编程助手自动迭代的朋友。

背景
知名 AI 研究员 Andrej Karpathy 此前创建了一个“autoresearch”脚本，能让 AI 智能体在单 GPU 上自主运行机器学习实验，迭代训练代码以优化超参数和架构。Claude Code 是 Anthropic 的智能编程工具，能理解代码库、编辑文件并运行命令。Codex 是 OpenAI 的 AI 编程智能体，用于软件工程任务，可通过命令行、桌面应用和 IDE 集成使用。新的 Autoresearch 项目将 Karpathy 的概念适配到这些通用编程智能体上，将自主实验从机器学习研究扩展到更广泛的软件开发领域。

8月1日 10:00在 X 打开#AI #automation #open-source #Claude Code #Codex

077.0

AI Knowledge Graph：用大模型自动将文本转为交互式知识图谱的工具

GitHub 上发布了一款名为 AI Knowledge Graph 的新开源工具。它利用大语言模型（LLM）自动从文本中提取实体和关系，进行实体去重和关系推理，生成交互式知识图谱。该工具支持 Ollama、OpenAI 等多种后端，可在本地运行模型。 从长文档中手动创建知识图谱既繁琐又容易出错。该工具自动化了这一过程，为研究人员、分析师和知识工作者节省时间。通过 Ollama 支持本地模型，它还解决了隐私问题，减少了对云 API 的依赖。 该工具将文档分块，提取结构化事实，统一实体，推断隐藏关系，并在基于浏览器的交互式图中可视化结果。它兼容任何 OpenAI 兼容的 API，包括用于本地模型的 Ollama。项目在 GitHub 上开源，仓库为 robert-mcdermott/ai-knowledge-graph。它专注于直接从文本中提取事实，不依赖外部知识。

@GitHub_Daily原推文1 张图片看完一篇长文档，脑子里大概有个谱，但要把实体之间的关系画成图，手动整理太费劲。 AI Knowledge Graph 能把一段文本自动拆解成知识图谱，用大模型提取实体和关系，生成一张可交互的网状图。 GitHub：http://github.com/robert-mcdermott/ai-knowledge-graph 它会自动做实体去重和关系推理，把分散在不同段落里的关联串起来，断开的部分也能补上推断关系。 兼容 Ollama、OpenAI 等各种接口，本地模型也能跑。适合做文献梳理、知识整理的朋友试试。原推文媒体预览展开原推文收起原推文

@GitHub_Daily

看完一篇长文档，脑子里大概有个谱，但要把实体之间的关系画成图，手动整理太费劲。 AI Knowledge Graph 能把一段文本自动拆解成知识图谱，用大模型提取实体和关系，生成一张可交互的网状图。 GitHub：http://github.com/robert-mcdermott/ai-knowledge-graph 它会自动做实体去重和关系推理，把分散在不同段落里的关联串起来，断开的部分也能补上推断关系。 兼容 Ollama、OpenAI 等各种接口，本地模型也能跑。适合做文献梳理、知识整理的朋友试试。

背景
知识图谱将实体（如人物、地点、概念）及其关系表示为节点和边的网络。大语言模型（LLM）如 GPT-4 能够理解并从非结构化文本中提取结构化信息。Ollama 是一个允许在个人机器上本地运行 LLM 的工具，提供 OpenAI 兼容的 API。实体去重合并指向同一现实世界实体的引用（例如“AI”和“人工智能”），而关系推理则识别隐含但未明确陈述的联系。

8月1日 07:30在 X 打开#knowledge graph #LLM #NLP #open source #productivity

086.0

创业者分享未及早注册域名和商标的惨痛教训

一位创业者讲述其团队最初只购买了产品的.io域名，因.ai域名要价五位数美元而放弃。两周前，他们发现竞争对手以相同名称推出产品，并已购买.ai域名且申请了商标。团队不得不连夜重新命名、购买新域名并修改代码。 这个故事凸显了初创企业尽早保护品牌（包括域名和商标）的重要性。未能确保这些资产可能导致昂贵的品牌重塑、品牌认知丧失和竞争劣势。它强调了创始人因专注于产品开发而推迟此类投资的常见陷阱。 团队最初选择隐身开发以验证产品，再投资品牌。竞争对手的发布视频和商标申请迫使他们迅速转向。创始人现在主张预先购买域名和商标，并引用了一家YC创业公司在融资650万美元后花费25万美元购买域名的例子。教训是：早期投资可以避免未来更大的代价。

@Jenny_the_Bunny@dotey 转推这种血的教训真的是得自己踩过坑之后才会发现有多痛。 我们团队也是3个月前买.io域名，但是没买.ai因为要美金五位数。当时的逻辑是先开始stealth开发，验证产品，把价值做到位再说。 但是2周前，我在停车场等队友来开门时刷手机突然刷到另一个团队的launch video。没错，撞名了，而且是竞品。人家买了.ai的域名并且上个月开始申请注册商标了。晴天霹雳。 经过一轮激烈讨论后，我们从“跟他们一杠到底”转到了“算了，不值得，还有很多更重要的事情需要我们的精力和时间”。之后我们连夜重新起名、买新域名、改代码。我至今还会经常口误提起那个不再属于我们的名字。 所以，如果再来一次的话，我也一定会像这个startup这样一开始就把域名和商标盘下来。倒也不一定要花25万美金这么多，但最起码省去很多后顾之忧。展开原推文收起原推文

@dotey 转推了

@Jenny_the_Bunny

这种血的教训真的是得自己踩过坑之后才会发现有多痛。 我们团队也是3个月前买.io域名，但是没买.ai因为要美金五位数。当时的逻辑是先开始stealth开发，验证产品，把价值做到位再说。 但是2周前，我在停车场等队友来开门时刷手机突然刷到另一个团队的launch video。没错，撞名了，而且是竞品。人家买了.ai的域名并且上个月开始申请注册商标了。晴天霹雳。 经过一轮激烈讨论后，我们从“跟他们一杠到底”转到了“算了，不值得，还有很多更重要的事情需要我们的精力和时间”。之后我们连夜重新起名、买新域名、改代码。我至今还会经常口误提起那个不再属于我们的名字。 所以，如果再来一次的话，我也一定会像这个startup这样一开始就把域名和商标盘下来。倒也不一定要花25万美金这么多，但最起码省去很多后顾之忧。

@paulg

A recent YC startup spent 250k on a domain. I was slightly shocked. But when I asked how much they raised after YC, the answer was 6.5m. So 1/26 of their round. This is the time we live in; one shocking number counterbalances the other.

背景
隐身模式是初创公司在发布前秘密运营以避免泄露创意的策略。域名和商标是保护品牌身份的关键知识产权资产。当相似名称导致市场混淆或法律纠纷时，就会产生冲突。.ai域名在AI初创公司中很受欢迎，但可能价格昂贵。Y Combinator（YC）是一家著名的创业加速器。
社区讨论
讨论中引用了Paul Graham的话，指出一家YC创业公司花费25万美元购买域名，占其融资额的1/26，说明此类成本是相对的。原帖作者认同早期投资是值得的，可以避免未来的麻烦。

8月1日 21:54在 X 打开#startups #domain names #trademarks #entrepreneurship #lessons learned

096.0

DeepSeek 邀请开源 Agent Harness 开发者参与内测

DeepSeek 正在招募具有 Agent Harness 项目经验的开源开发者，参与其全新 DeepSeek Harness 的内测。感兴趣的开发者需通过回复或私信提供 GitHub ID 和代表性开源项目。 此次内测标志着 DeepSeek 进军 Agent Harness 领域，可能将其模型整合到结构化的智能体框架中。这有望加速 AI 驱动的软件工程工具的发展，并吸引社区贡献，从而影响开发者与 AI 智能体的交互方式。 该邀请专门针对开源 Agent Harness 项目的开发者。参与者必须提供 GitHub ID 和代表性开源作品。泄露信息可能导致被取消资格，并影响未来参与 DeepSeek 内测的机会。内测可能包含动态工具注册等特性，并与 Claude Code、OpenCode、Pi 等现有 Harness 工具兼容。

@dotey 转推了

@tianyi

如果你是 Agent Harness 相关开源项目的开发者，希望参加 DeepSeek Harness 的内测，可以回复或私信联系我。请附上 GitHub id 以及开源代表作。

背景
Agent Harness 是 AI 工程领域的新兴范式，将智能体视为模型与 Harness 的结合——Harness 是约束和引导模型行为的代码、配置和执行逻辑。它强调“智能体优先”的方法，人类工程师监督 AI 智能体编写代码，从而实现显著的效率提升。关键组件包括护栏，例如 AGENTS.md 文件，为进入代码库的 AI 智能体提供指导。

8月1日 15:14在 X 打开#DeepSeek #Agent Harness #open-source #beta testing #AI

106.0

Search by Image 浏览器扩展聚合 30+ 反向图片搜索引擎

GitHub 上分享了一款名为 Search by Image 的浏览器扩展，它将 30 多个反向图片搜索引擎聚合到一个右键菜单中。用户可以直接从网页、截图或本地上传图片进行搜索。该扩展兼容 Chrome、Edge、Firefox、Safari 等主流浏览器，甚至提供手机客户端。 该工具简化了反向图片搜索的流程，避免了逐个使用多个搜索引擎的繁琐。对于需要验证图片来源、追溯摄影作品或寻找相似商品的记者、研究人员和购物者来说，它特别有价值。通过集中访问多种搜索引擎，它提高了找到单一引擎可能遗漏的结果的几率。 该扩展支持在选项中切换和排序搜索引擎。它可以通过右键菜单、浏览器工具栏或弹出窗口搜索图片。支持的引擎包括 Google、Bing、Yandex、百度 和 TinEye。它是开源的，可在 GitHub 上获取，提供桌面和移动平台版本。

@GitHub_Daily原推文1 张图片刷到一张图想知道出处，Google 以图搜图搜不到，再换 Bing 试试，多个搜索引擎尝试折腾。 偶然发现 Search by Image 这个浏览器插件，聚合了 30 多个以图搜图引擎，右键选中图片就能一次查多个。 支持直接选页面上的图片，也能截取网页某个区域、或者从本地上传图片来搜。 GitHub：http://github.com/dessant/search-by-image 兼容 Chrome、Edge、Firefox 以及 Safari 等主流浏览器，甚至还提供手机客户端。 做新闻报道、摄影作品溯源、或者购物找同款，可以装一个试试或先收藏备用。原推文媒体预览展开原推文收起原推文

@GitHub_Daily

刷到一张图想知道出处，Google 以图搜图搜不到，再换 Bing 试试，多个搜索引擎尝试折腾。 偶然发现 Search by Image 这个浏览器插件，聚合了 30 多个以图搜图引擎，右键选中图片就能一次查多个。 支持直接选页面上的图片，也能截取网页某个区域、或者从本地上传图片来搜。 GitHub：http://github.com/dessant/search-by-image 兼容 Chrome、Edge、Firefox 以及 Safari 等主流浏览器，甚至还提供手机客户端。 做新闻报道、摄影作品溯源、或者购物找同款，可以装一个试试或先收藏备用。

背景
反向图片搜索是一种技术，允许用户通过上传图片或提供其 URL 来查找相似图片或追溯图片的来源。不同的搜索引擎拥有不同的索引和算法，因此结果可能差异很大。浏览器扩展可以为网页浏览器添加功能，而这款扩展专门将多个反向图片搜索服务集成到一个界面中。

8月1日 04:00在 X 打开#browser extension #reverse image search #GitHub #tools #productivity

115.0

开发者批评同事在代码审查中拒绝阅读生成的代码

开发者 @middlefeng 在 X 上分享说，一些同事在代码审查时故意不阅读生成的代码，即使被要求至少达到能提出问题的程度。他们的回应是宁愿看其他东西，比如最喜欢的测试用例，也不看代码。这种行为被描述为将自我置于理解之上。 这凸显了软件工程中的一个文化问题：代码审查变得肤浅，可能导致错误或糟糕的设计被忽略。随着 AI 生成代码的兴起，需要审查的代码量不断增加，开发者深入理解代码变得更加重要。忽视生成的代码可能导致技术债务和安全漏洞。 原帖澄清说，期望并不是坚持古老的代码审查方法，而只是阅读代码到足以提出有意义问题的程度。这种拒绝被描述为故意回避，而不是因为缺乏时间或能力。这一事件反映了代码审查实践中更广泛的挑战，尤其是在 AI 生成代码的情况下，理解往往不足。

@middlefeng@dotey 转推我从没有说 code review 要坚持古法，我说的是至少先看到下面的程度。得到的回应是，就是不看 code，宁可去看其它东西（比如最喜爱的 test case）来问问题，就是故意不看生成的 code。这就是为了不看而不看。为了 ego 而不看。展开原推文收起原推文

@dotey 转推了

@middlefeng

我从没有说 code review 要坚持古法，我说的是至少先看到下面的程度。得到的回应是，就是不看 code，宁可去看其它东西（比如最喜爱的 test case）来问问题，就是故意不看生成的 code。这就是为了不看而不看。为了 ego 而不看。

@middlefeng

@az372184 @dotey 至少你要看到能问问题的程度吧？

背景
代码审查是一种标准实践，开发者在合并更改之前相互检查代码的错误、标准遵循情况和整体质量。随着 AI 编码助手的出现，越来越多的代码被自动生成，这可能导致审查者粗略浏览或跳过审查过程。最佳实践强调关注代码而非个人，并提供建设性反馈。

8月1日 21:11在 X 打开#code review #software engineering #developer culture

125.0

对用SVG绘图测试衡量AI智能水平的质疑

一位X平台用户质疑SVG绘图测试是否能真正反映AI智能水平，并引用了DeepSeek模型输出对比。讨论源于一条推文，显示DeepSeek-V4-Flash-0731在默认推理模式下生成的鹈鹕图令人失望，而通过OpenRouter将推理模式调高后，绘图质量显著提升。 这一批评凸显了AI评估中更广泛的争论：像SVG绘图这样的特定任务基准是捕捉了真正的推理能力，还是仅仅测试了狭隘的技能。它强调了需要更全面的AI智能评估方法，尤其是当DeepSeek-V4-Flash-0731等模型的表现会因推理设置不同而产生显著差异时。 DeepSeek-V4-Flash-0731是一个拥有2840亿参数的混合专家模型，上下文窗口为100万token，于2026年7月31日发布。经过后训练，其在智能体、编码和工具调用方面的能力有所提升。该SVG绘图测试涉及生成鹈鹕图像，在OpenRouter上默认推理模式与高推理模式下的绘图质量差异显著。

@dotey引用推文2 张图片我一直觉得这种测试只能测试 SVG 画图能力，并不太能体现智能水平，或者有什么理由通过这个测试能反映智能水平？原推文媒体预览+1展开原推文收起原推文

@dotey

我一直觉得这种测试只能测试 SVG 画图能力，并不太能体现智能水平，或者有什么理由通过这个测试能反映智能水平？

@simonw

Got a disappointing pelican from DeepSeek-V4-Flash-0731 at default reasoning mode - on the left - but then I bumped reasoning up to high (via OpenRouter) and got the much better one on the right

背景
SVG（可缩放矢量图形）是一种基于XML的二维图形描述格式，常被用于测试AI模型生成结构化视觉内容的能力。DeepSeek是一家以大型语言模型闻名的中国AI公司。OpenRouter是一个统一API，提供对各种AI模型的访问，并允许用户调整推理模式，从而控制模型在生成响应时投入的计算量。

8月1日 18:59在 X 打开#AI evaluation #SVG #DeepSeek #LLM #reasoning