7月27日2026 · 星期一

从 23 条抓取中筛选 12 条 · twitter × 4 账号 · 02:47 UTC 生成

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

Open Minis：成熟的端侧AI智能体应用现已全面开源8.0
Anthropic 在 Opus 4.8 而非 Opus 5 中删减了 Claude Code 80% 的系统提示词8.0
《动手学 Pi》：15章从零构建编码Agent的实战教材8.0
开发者利用Codex构建AI视频生成工作流接近完成，计划开源7.0
开发者使用GPT-5.6 Sol与Ling-3.0-flash构建规划-执行工作流，成功开发3D农场游戏7.0
Domain Digger 将 DNS、WHOIS 和 SSL 历史整合到一个工具中7.0
tty7：一个集成持久会话与AI代理的Rust终端工作台7.0
Cloudflare 开源 Nimbus 文档生成工具，同时服务人类与 AI Agent7.0
ChatGPT 通过单一提示自主执行复杂多步骤任务7.0
非对称界面：语音输入与视觉输出的人机交互设计7.0
ChatGPT Work 智能体现支持网站持久登录7.0
弱模型设计、强模型顾问的弊端与更优替代方案6.0

018.0

Open Minis：成熟的端侧AI智能体应用现已全面开源

经过3到4个月的迭代，端侧AI智能体应用Open Minis已全面开源，包括iOS和Android的全部代码。该应用已为数万用户的日常工作流提供支持，具备原生Linux shell、浏览器自动化、可扩展技能和持久记忆等功能。源代码现已在GitHub上公开，任何人都可以fork并在此基础上构建。开源一个成熟且广泛使用的端侧AI智能体，并具备深度系统集成，大大降低了开发者创建保护隐私、可离线使用的AI助手的门槛。它通过提供生产级基础来加速移动AI智能体的创新，可能重塑用户与设备的交互方式。此举还通过推广本地、用户自主控制的智能，挑战了依赖云端的AI服务的主导地位。 Open Minis包含原生Linux shell，可在手机上直接进行命令行交互，以及用于网页任务的浏览器自动化功能。它支持可扩展技能和持久记忆，使智能体能够随时间学习和适应。代码在GitHub的OpenMinis组织下提供，该应用已得到数万用户的验证。未提及定价或许可限制，强调了其开源性质。

@wsvn53@dotey 转推After 3-4 months of iteration, Open Minis — "possibly the best Agent app on your phone" — has stabilized into a mature architecture, now powering tens of thousands of users' daily workflows. Today we're open sourcing all of it: the full iOS and Android code. A real on-device AI agent: a native Linux shell, browser automation, extensible skills, persistent memory, and deep system integration. Now, fork it, feel free to build your own on-device agent now. 🤗 https://github.com/OpenMinis/OpenMinis展开原推文收起原推文

@dotey 转推了

@wsvn53

After 3-4 months of iteration, Open Minis — "possibly the best Agent app on your phone" — has stabilized into a mature architecture, now powering tens of thousands of users' daily workflows. Today we're open sourcing all of it: the full iOS and Android code. A real on-device AI agent: a native Linux shell, browser automation, extensible skills, persistent memory, and deep system integration. Now, fork it, feel free to build your own on-device agent now. 🤗 https://github.com/OpenMinis/OpenMinis

GitHub - OpenMinis/OpenMinis: OpenMinis — The AI Agent app across platforms. Fully free and open...github.com · 直连原文

背景

端侧AI智能体在用户设备本地运行，无需将数据发送到云端，从而增强隐私并支持离线使用。移动端的浏览器自动化使智能体能够像人类一样与网站交互，执行填写表单或提取数据等任务。手机上的原生Linux shell提供了强大的命令行环境，传统上仅限于桌面系统，可实现高级脚本编写和系统控制。开源这样的项目意味着代码公开可用，任何人都可以使用、修改和分发，促进社区驱动的开发。

7月26日 02:58在 X 打开#AI Agent #Open Source #Mobile #On-Device AI #iOS/Android

028.0

Anthropic 在 Opus 4.8 而非 Opus 5 中删减了 Claude Code 80% 的系统提示词

一项实证分析显示，Anthropic 在 Opus 4.8 而非 Opus 5 中将 Claude Code 的系统提示词删减了 80%。提示词从 Opus 4.7 的 15,225 个字符降至 Opus 4.8 的 4,467 个字符，但 Opus 5 重新引入了更长的提示词（7,694 个字符），并新增了“Delivering work”和“Corrections”等章节。该切换由硬编码的模型 ID 匹配控制，并可通过设置 CLAUDE_CODE_SIMPLE_SYSTEM_PROMPT=1 强制使用短提示词。这一发现挑战了“模型越强越不需要规则”的说法，表明提示词优化是模型特定且迭代的过程。它凸显了 AI 编程工具中提示工程的复杂性，以及版本特定回归的可能性。依赖 Claude Code 行为的开发者应注意，提示词变更可能会显著影响模型输出，尤其是在使用非标准模型 ID 或提供商时。该分析通过将 CLI 指向本地服务器捕获了实际 API 调用。旧提示词路径（12,443 个字符）被新的“Harness”章节（1,702 个字符）取代，后者侧重于环境描述而非行为规则。Opus 5 重新添加了 2,019 个字符的“Delivering work”和 1,736 个字符的“Corrections”，后者与 Anthropic 提供给第三方开发者的迁移指南完全一致。模型 ID 检查还影响工具描述，将其从 53,328 个字符减少到 37,167 个字符。

@chenchengpro@Pluvio9yte 转推3 张图片Anthropic 说他们为 Opus 5 删掉了 Claude Code 80% 的系统提示词。我想验证下是不是。于是把 CLI 指向本地一个小服务器，抓它真正发出去的东西。第一组数字就不太对。 Opus 4.7：15,225 字符。 Opus 4.8：4,467。 Opus 5：7,694。他们是在 4.8 上删的，不是 5。Opus 5 的系统提示词比上一代大了 72%。那 80% 确实是真的。每个版本里都同时带着两套 prompt，一个函数决定发哪套。判定条件是硬编码的子串匹配：model id 含 sonnet、haiku、claude-3-，或者等于 opus-4-0/4-1/4-5/4-6/4-7，走旧的。4.8 不在名单上。只数手写的那几节策略正文，旧路径 12,443 字符，新路径 2,308。-81%。删掉的是这几节： # Doing tasks（3,321 字符） # Executing actions with care（3,585） # Text output（1,701） # System（1,627） # Using your tools（752） # Tone and style（557）换成一节 # Harness，1,702 字符，五条。这五条讲的全是环境长什么样，没有一条在规定该怎么做。markdown 会在终端里渲染，被拒绝的工具调用意味着用户说了不。整套写注释的规矩，「默认不写注释」「绝不写多段 docstring」，只剩一句： "Write code that reads like the surrounding code: match its comment density, naming, and idiom." 这个开关也支持用户手动控制。CLAUDE_CODE_SIMPLE_SYSTEM_PROMPT=1 能把短 prompt 套到任何模型上。我在 Opus 4.5 上试了一次，拿到的东西和 4.8 实际收到的逐字相同，只差写模型名和知识截止日期的那两行。没料到的是 Opus 5 又开始往回加。 # Delivering work（2,019 字符）和 # Corrections（1,736），两段新内容，2.1.215 和 2.1.216 里完全没有。它们出现在 2.1.220，挂在一个 capability 上，而这个 capability 只有 claude-opus-5 有。4,467 加这两段，基本就是 Opus 5 的全部差值。更巧的是 # Corrections 这一段。Anthropic 自己打包了一份 Opus 5 迁移指南，让第三方开发者往自己的 agent 里抄一段进去，抄的就是它，逐字相同。指南给的理由是 Opus 5 "flags and explains its own earlier mistakes at length, which reads as thrash in a user-facing product." Fable 5 走的是第三条路，多一节 # Communicating with the user，8,911 字符。所以「模型越强越不需要规则」这个说法不太站得住。删是上一代就删完的。换了新模型，翻车的方式也换了，规则就跟着变成一小块补丁，按模型贴。如果你在这上面做东西，还有两件事。 model id 没被识别，走的又是 Bedrock、Vertex 或者自定义 base URL，就掉回那套 15K 的旧 prompt。它查的是你的 provider，不只是模型。同一个开关也在分流工具描述。53,328 字符降到 37,167。你的上下文大头根本不在 system prompt 里。想自己验？可以写个小 HTTP 服务，把 response 存下来，直接返 400。把 ANTHROPIC_BASE_URL 指过去，然后 claude -p "hi" --model 模型id。 Anthropic 删自己的规则我没什么感觉。难受的是我也写过一堆同样的规则，其中不少大概只是在替模型兜底，而它早就不需要人兜了。哪些是，我分不出来，只能一条条删掉看会不会坏。 @trq212 的原帖值得读全文。原推文媒体预览

+2展开原推文收起原推文

@Pluvio9yte 转推了

@chenchengpro

Anthropic 说他们为 Opus 5 删掉了 Claude Code 80% 的系统提示词。我想验证下是不是。于是把 CLI 指向本地一个小服务器，抓它真正发出去的东西。第一组数字就不太对。 Opus 4.7：15,225 字符。 Opus 4.8：4,467。 Opus 5：7,694。他们是在 4.8 上删的，不是 5。Opus 5 的系统提示词比上一代大了 72%。那 80% 确实是真的。每个版本里都同时带着两套 prompt，一个函数决定发哪套。判定条件是硬编码的子串匹配：model id 含 sonnet、haiku、claude-3-，或者等于 opus-4-0/4-1/4-5/4-6/4-7，走旧的。4.8 不在名单上。只数手写的那几节策略正文，旧路径 12,443 字符，新路径 2,308。-81%。删掉的是这几节： # Doing tasks（3,321 字符） # Executing actions with care（3,585） # Text output（1,701） # System（1,627） # Using your tools（752） # Tone and style（557）换成一节 # Harness，1,702 字符，五条。这五条讲的全是环境长什么样，没有一条在规定该怎么做。markdown 会在终端里渲染，被拒绝的工具调用意味着用户说了不。整套写注释的规矩，「默认不写注释」「绝不写多段 docstring」，只剩一句： "Write code that reads like the surrounding code: match its comment density, naming, and idiom." 这个开关也支持用户手动控制。CLAUDE_CODE_SIMPLE_SYSTEM_PROMPT=1 能把短 prompt 套到任何模型上。我在 Opus 4.5 上试了一次，拿到的东西和 4.8 实际收到的逐字相同，只差写模型名和知识截止日期的那两行。没料到的是 Opus 5 又开始往回加。 # Delivering work（2,019 字符）和 # Corrections（1,736），两段新内容，2.1.215 和 2.1.216 里完全没有。它们出现在 2.1.220，挂在一个 capability 上，而这个 capability 只有 claude-opus-5 有。4,467 加这两段，基本就是 Opus 5 的全部差值。更巧的是 # Corrections 这一段。Anthropic 自己打包了一份 Opus 5 迁移指南，让第三方开发者往自己的 agent 里抄一段进去，抄的就是它，逐字相同。指南给的理由是 Opus 5 "flags and explains its own earlier mistakes at length, which reads as thrash in a user-facing product." Fable 5 走的是第三条路，多一节 # Communicating with the user，8,911 字符。所以「模型越强越不需要规则」这个说法不太站得住。删是上一代就删完的。换了新模型，翻车的方式也换了，规则就跟着变成一小块补丁，按模型贴。如果你在这上面做东西，还有两件事。 model id 没被识别，走的又是 Bedrock、Vertex 或者自定义 base URL，就掉回那套 15K 的旧 prompt。它查的是你的 provider，不只是模型。同一个开关也在分流工具描述。53,328 字符降到 37,167。你的上下文大头根本不在 system prompt 里。想自己验？可以写个小 HTTP 服务，把 response 存下来，直接返 400。把 ANTHROPIC_BASE_URL 指过去，然后 claude -p "hi" --model 模型id。 Anthropic 删自己的规则我没什么感觉。难受的是我也写过一堆同样的规则，其中不少大概只是在替模型兜底，而它早就不需要人兜了。哪些是，我分不出来，只能一条条删掉看会不会坏。 @trq212 的原帖值得读全文。

@trq212

We removed ~80% of the Claude Code system prompt for our newest models, this is what we've learned about writing system prompts, skills and Claude.MDs for them. http://x.com/i/article/2080703729385512960

背景

Claude Code 是 Anthropic 的代理式编码工具，它使用系统提示词来指导模型行为。系统提示词是附加在每次对话轮次前的指令，定义了模型的角色、规则和输出格式。Opus 是 Anthropic 的高性能模型系列，包括 4.7、4.8 和 5 等版本。环境变量 CLAUDE_CODE_SIMPLE_SYSTEM_PROMPT 允许用户在任何模型上选择使用较短的提示词。

社区讨论

一位评论者指出，在删减 80% 的提示词后，Claude Code 可能无法很好地适配其他模型，暗示了潜在的锁定效应。@trq212 的原帖进一步介绍了 Anthropic 在为新型号编写系统提示词方面的经验。

7月26日 11:53在 X 打开#Anthropic #Claude #system prompt #prompt engineering #AI models

038.0

《动手学 Pi》：15章从零构建编码Agent的实战教材

一本名为《动手学 Pi》的中文教材在GitHub上发布，带领读者从零开始构建一个编码Agent。全书共15个动手章节，每章都包含真实代码提交、测试和故障实验。教材从一段离线Agent运行记录出发，逐步涵盖消息协议、工具集成、Agent循环、会话树、上下文压缩以及完整的运行时评测。该资源填补了编码Agent理论讲解与实际实现之间的空白，而编码Agent在AI工程中日益重要。通过提供可逐步执行的指南，它使开发者能深入理解Agent系统的内部构造，这类系统在软件开发中的应用越来越广泛。动手实践的方法比阅读源码分析更有效，有望加速构建自主编码工具的学习曲线。教材围绕15个检查点构建，每个检查点包含四部分：正文、对应的真实提交、聚焦测试和一个故障实验。练习目录可通过一条命令生成，不含答案，学习者可将网页和说明交给AI进行陪练。该书有在线版，GitHub地址为github.com/hahhforest/pi-textbook，构建的是一个Pi风格的Agent，即一个极简的CLI编码Agent。

@GitHub_Daily原推文1 张图片想亲手写一个编码 Agent，讲原理的文章一大把，真要自己动手又不知道如何开始。《动手学 Pi》这本中文教材，从一段离线的 Agent 运行记录出发，一路经过 15 个关卡。手把手带我们把一个编码 Agent 实现出来，每一步的代码都能拉下来运行、验证进行学习。 GitHub：http://github.com/hahhforest/pi-textbook 具体路线是先立消息与模型协议，再接工具和 Agent 循环。然后存会话树、压上下文，最后拼成一个完整的运行时跑评测。每章四件套：正文、对应的那次真实提交、聚焦测试，还有一个故障实验。练习目录也能一条命令生成，里面不含答案，把网页和里面的说明丢给 AI 陪着练就行。有在线版可以直接读。想搞懂这类工具内部构造，跟着亲手写一遍比读十篇源码分析管用。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

想亲手写一个编码 Agent，讲原理的文章一大把，真要自己动手又不知道如何开始。《动手学 Pi》这本中文教材，从一段离线的 Agent 运行记录出发，一路经过 15 个关卡。手把手带我们把一个编码 Agent 实现出来，每一步的代码都能拉下来运行、验证进行学习。 GitHub：http://github.com/hahhforest/pi-textbook 具体路线是先立消息与模型协议，再接工具和 Agent 循环。然后存会话树、压上下文，最后拼成一个完整的运行时跑评测。每章四件套：正文、对应的那次真实提交、聚焦测试，还有一个故障实验。练习目录也能一条命令生成，里面不含答案，把网页和里面的说明丢给 AI 陪着练就行。有在线版可以直接读。想搞懂这类工具内部构造，跟着亲手写一遍比读十篇源码分析管用。

背景

编码Agent是一种能自主执行编写、审查、重构等编码任务的AI系统。Agent循环是一种核心架构，允许Agent迭代地采取行动、观察结果并调整，直到任务完成，类似于Claude Code等工具的工作方式。Pi是一个极简的CLI编码Agent，注重效率并支持交互式开发的技能。构建此类Agent需要理解消息协议、工具调用和上下文管理，本教材系统地教授了这些内容。

7月26日 09:49在 X 打开#coding agent #hands-on learning #AI engineering #open source #tutorial

047.0

开发者利用Codex构建AI视频生成工作流接近完成，计划开源

开发者 @Pluvio9yte 利用 Codex 构建了一个几乎完整的 AI 视频生成工作流。该系统仅需寥寥几句提示词即可生成口播视频，开发者计划近期将其开源。剩余挑战包括改进中文断句与语句组织，以及为不同类型视频制作更好的“钩子”技能。该工作流降低了内容创作者制作专业视频的门槛，无需手动录制，减少了“容貌焦虑”并节省时间。通过开源，项目可加速社区驱动的改进，使 AI 视频制作大众化。它也展示了大语言模型（如 Codex）融入创作流程的实际应用。开发者提到工作流基本可用，但仍需完善中文断句和针对不同视频类型的钩子技能。示例视频仅通过两轮提示词、三四句话生成，使用了一个风格模板。系统还支持数字人形象，可进行美化。项目预计在公告次日开源。

@Pluvio9yte原推文1 个视频Codex做视频的工作流基本跑的差不多了。目前还差一个中文断句+语句组织skill、好一点的钩子skill(不同类型的视频需要不同类型的钩子) 总体上细节能够完善的地方还有不少，但是能够确定的是以后也不用自己费劲录自己的口播视频了，自己的数字人也能够P好看一点，减少出镜容貌焦虑。感谢AI大时代。下面这个视频就是寥寥两轮提示词三四句话做出来的(其中一个风格模板)。等我整理一下，明天开源😋 原推文媒体预览

展开原推文收起原推文

@Pluvio9yte

Codex做视频的工作流基本跑的差不多了。目前还差一个中文断句+语句组织skill、好一点的钩子skill(不同类型的视频需要不同类型的钩子) 总体上细节能够完善的地方还有不少，但是能够确定的是以后也不用自己费劲录自己的口播视频了，自己的数字人也能够P好看一点，减少出镜容貌焦虑。感谢AI大时代。下面这个视频就是寥寥两轮提示词三四句话做出来的(其中一个风格模板)。等我整理一下，明天开源😋

背景

Codex 是一种 AI 驱动的工具，可辅助编码和自动化任务。在此场景中，它被用来编排视频生成流程，可能结合了语言模型、文本转语音和虚拟形象动画。“钩子”指吸引观众注意力的开头片段，因视频类型而异。数字人是 AI 生成的虚拟形象，可对口型同步音频，无需实体摄像机即可自动生成视频。

7月26日 10:39在 X 打开#AI video generation #Codex #open-source #content creation #workflow

057.0

开发者使用GPT-5.6 Sol与Ling-3.0-flash构建规划-执行工作流，成功开发3D农场游戏

一位开发者尝试了一种多模型架构：由GPT-5.6 Sol（通过Codex）负责规划和审查，而Ling-3.0-flash（通过OpenCode）执行具体的实现任务。该方案成功构建了一款3D农场游戏，执行模型在6分多钟内完成了依赖安装、项目结构搭建、TypeScript配置、测试设置和生产构建，速度超过每秒100个token。该工作流通过将战略规划与重复性执行分离，展示了一种经济高效的AI辅助开发方法。它可能提升开发者的效率和代码质量，特别是在涉及大量工具调用的智能体工作流中，通过将日常任务交给更小、更快的模型，而将高层决策留给更大的模型。开发者在编码前使用Codex生成了四份文档（SPEC.md、ARCHITECTURE.md、TASKS.md、ACCEPTANCE.md）。Ling-3.0-flash被指示阅读所有文档，一次只处理一个任务，并在每个任务后运行类型检查、测试和构建，修复所有错误后才继续。Ling-3.0-flash是一个1240亿参数的混合推理MoE模型，每个token仅激活51亿参数，专为生产级智能体设计。

@Pluvio9yte原推文1 个视频I went a little overboard with Codex last week and burned through my entire weekly allowance in two days. Luckily, my quota reset today. Otherwise, I’m not sure what I would’ve done. It got me thinking: instead of asking one large model to handle everything from start to finish, why not let a stronger model plan the project and review the work, while a model built for execution handles the day-to-day implementation? So I tried it. The result was better than I expected. I used GPT-5.6 Sol in Codex as the decision-maker, then ran Ling-3.0-flash from @AntLingAGI inside OpenCode as the execution engine. Together, they built a small 3D farming game. Before writing any code, I had Codex create four documents: SPEC.md defined the product scope and the lines we couldn’t cross. ARCHITECTURE.md laid out the isometric coordinate system, state machine, and module boundaries. TASKS.md broke the project into small jobs Ling could tackle one at a time. ACCEPTANCE.md explained how each step would be tested and what “done” actually meant. Then I gave Ling a very straightforward role: You are the execution model for this project. Read all four documents before you begin. Work only on the task assigned for this round. When you’re done, run typecheck, test, and build. If anything fails, read the error, fix it, and run the checks again. Do not move on to the next task early. Ling handled dependency installation, project structure, strict TypeScript configuration, test setup, and a production build in 6 minutes and 3 seconds. It ran into issues with the Vite test config, a TS6310 error, and a missing jsdom dependency along the way. Instead of stopping at the first error, it kept reading the logs and fixing the problems until all three checks passed. The speed was honestly hard to believe. If you exclude the time spent waiting on tools, it was producing more than 100 tokens per second. That made the whole development loop feel noticeably faster. After this experiment, I’m planning to keep using the same workflow. If the task is small, there’s no reason to call an expensive planning model for every single step. If the task is large, handing the entire project to a Flash model in one prompt isn’t a great idea either. The setup that makes more sense to me is: Use a more capable model such as Codex to explore the project, make architectural decisions, and break the work down. Put the constraints into specs, schemas, types, and tests instead of leaving them buried in chat history. Give Ling-3.0-flash a steady stream of clear, verifiable implementation tasks. Report bugs with structured context and actual error logs, rather than saying, “It still doesn’t work.” Bring Codex back in for architecture reviews, visual checks, and changes that affect multiple parts of the project. The point of this setup isn’t to give AI a big “build the whole project” button. It’s to turn software development into a pipeline with a much more sensible cost structure: Codex figures out the plan, sets the boundaries, and catches problems. Ling-3.0-flash moves quickly, calls tools reliably, and works through well-defined tasks at scale. For agent workflows that involve lots of repetitive edits, production tasks, and tool calls, this may be a more practical answer than simply using the biggest model for everything. 原推文媒体预览

展开原推文收起原推文

@Pluvio9yte

I went a little overboard with Codex last week and burned through my entire weekly allowance in two days. Luckily, my quota reset today. Otherwise, I’m not sure what I would’ve done. It got me thinking: instead of asking one large model to handle everything from start to finish, why not let a stronger model plan the project and review the work, while a model built for execution handles the day-to-day implementation? So I tried it. The result was better than I expected. I used GPT-5.6 Sol in Codex as the decision-maker, then ran Ling-3.0-flash from @AntLingAGI inside OpenCode as the execution engine. Together, they built a small 3D farming game. Before writing any code, I had Codex create four documents: SPEC.md defined the product scope and the lines we couldn’t cross. ARCHITECTURE.md laid out the isometric coordinate system, state machine, and module boundaries. TASKS.md broke the project into small jobs Ling could tackle one at a time. ACCEPTANCE.md explained how each step would be tested and what “done” actually meant. Then I gave Ling a very straightforward role: You are the execution model for this project. Read all four documents before you begin. Work only on the task assigned for this round. When you’re done, run typecheck, test, and build. If anything fails, read the error, fix it, and run the checks again. Do not move on to the next task early. Ling handled dependency installation, project structure, strict TypeScript configuration, test setup, and a production build in 6 minutes and 3 seconds. It ran into issues with the Vite test config, a TS6310 error, and a missing jsdom dependency along the way. Instead of stopping at the first error, it kept reading the logs and fixing the problems until all three checks passed. The speed was honestly hard to believe. If you exclude the time spent waiting on tools, it was producing more than 100 tokens per second. That made the whole development loop feel noticeably faster. After this experiment, I’m planning to keep using the same workflow. If the task is small, there’s no reason to call an expensive planning model for every single step. If the task is large, handing the entire project to a Flash model in one prompt isn’t a great idea either. The setup that makes more sense to me is: Use a more capable model such as Codex to explore the project, make architectural decisions, and break the work down. Put the constraints into specs, schemas, types, and tests instead of leaving them buried in chat history. Give Ling-3.0-flash a steady stream of clear, verifiable implementation tasks. Report bugs with structured context and actual error logs, rather than saying, “It still doesn’t work.” Bring Codex back in for architecture reviews, visual checks, and changes that affect multiple parts of the project. The point of this setup isn’t to give AI a big “build the whole project” button. It’s to turn software development into a pipeline with a much more sensible cost structure: Codex figures out the plan, sets the boundaries, and catches problems. Ling-3.0-flash moves quickly, calls tools reliably, and works through well-defined tasks at scale. For agent workflows that involve lots of repetitive edits, production tasks, and tool calls, this may be a more practical answer than simply using the biggest model for everything.

背景

Codex是OpenAI的AI编码智能体平台，可协助处理拉取请求、重构和代码审查。GPT-5.6 Sol是OpenAI近期推出的大型语言模型，定位为高智能选项。Ling-3.0-flash是蚂蚁集团AntLingAGI发布的新模型，针对智能体工作流中的快速、低成本执行进行了优化。OpenCode可能是一个运行编码智能体的界面或环境。规划-执行模式是一种常见的软件设计，其中一个组件决定做什么，另一个组件执行任务。

7月26日 07:58在 X 打开#AI-assisted development #Codex #multi-agent systems #workflow optimization

067.0

Domain Digger 将 DNS、WHOIS 和 SSL 历史整合到一个工具中

Domain Digger 是一个新的开源工具，将 DNS 记录、WHOIS 注册信息和历史 SSL 证书整合到一个网页界面中。它省去了在多个站点之间切换进行域名分析的麻烦。该工具还提供全球 DNS 解析对比以及域名与 IP 之间关系的可视化映射。该工具为经常进行域名调查的开发者、系统管理员和安全研究人员节省了大量时间。通过统一不同的数据源，它简化了故障排除、侦察和尽职调查流程。其开源特性和托管网页版无需搭建即可使用，降低了域名分析的门槛。 Domain Digger 提供 DNS 记录（A、MX、NS 等）、IP 地理位置、WHOIS 域名注册详情以及历史 SSL 证书链。它包含全球查询功能，可比较不同地区的 DNS 解析结果。结果可以可视化为关系图，展示域名如何指向机器以及机器上托管了哪些服务。该项目在 GitHub 上开源，并提供即用型网页应用，地址为 digger.tools。

@GitHub_Daily原推文1 张图片想分析一个域名，DNS 记录、注册信息、历史证书要分别到不同站点查询，颇为麻烦。 Domain Digger 把这些查询整合到了一个页面里，只需输入域名就能一次查看。 DNS 记录、IP 归属和地理位置、域名注册信息，还能翻出这个域名历史上换过哪些证书。 GitHub：http://github.com/wotschofsky/domain-digger 还有全球查询，同一个域名在不同地区的服务器上解析出什么结果，能摆在一起对比。解析结果还能画成关系图，域名指向哪台机器、机器上又挂着什么，一眼看清。项目提供在线网页版直接能用，不用自己搭，做运维或者经常折腾域名的朋友可以先收着。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

想分析一个域名，DNS 记录、注册信息、历史证书要分别到不同站点查询，颇为麻烦。 Domain Digger 把这些查询整合到了一个页面里，只需输入域名就能一次查看。 DNS 记录、IP 归属和地理位置、域名注册信息，还能翻出这个域名历史上换过哪些证书。 GitHub：http://github.com/wotschofsky/domain-digger 还有全球查询，同一个域名在不同地区的服务器上解析出什么结果，能摆在一起对比。解析结果还能画成关系图，域名指向哪台机器、机器上又挂着什么，一眼看清。项目提供在线网页版直接能用，不用自己搭，做运维或者经常折腾域名的朋友可以先收着。

背景

域名分析通常需要使用不同的工具：DNS 查询服务获取记录，WHOIS 数据库获取注册信息，SSL 证书日志获取历史证书。DNS（域名系统）将域名转换为 IP 地址。WHOIS 是一种用于查询域名所有权和注册详情的协议。SSL/TLS 证书用于保护网站安全，其签发历史可以揭示过去的配置或所有权变更。Domain Digger 将这些功能整合到一个界面中，简化了工作流程。

7月27日 01:53在 X 打开#domain analysis #DNS #tool #devops #open source

077.0

tty7：一个集成持久会话与AI代理的Rust终端工作台

tty7 是一个全新的开源终端工作台，采用 Rust 编写，将命令行、会话管理、远程登录和 Claude Code 等编码代理集成到单一界面中。它引入了持久会话功能，即使关闭窗口或重启机器，会话仍能继续运行，无需再使用 tmux。该工具还提供类似编辑器的输入体验，包括语法高亮、Tab 补全和多行编辑，并通过托盘图标提示哪个代理正在等待输入。该工具解决了开发者在终端中同时运行多个 AI 编码代理时常见的痛点，使管理和监控变得更加轻松。通过集成持久会话和代理感知的 UI 提示，tty7 能显著提升工作流效率，尤其适合重度使用代理式编码工具的用户。其跨平台支持和流行 Shell 的零配置设置降低了使用门槛。 tty7 完全使用 Rust 构建，并提供 macOS、Windows 和 Linux 的原生安装包。它包含一套自定义的远程登录实现，支持将凭证存储在系统钥匙串中，并带有文件传输面板、端口转发和跳板机功能。输入体验模拟代码编辑器，具备历史建议、Tab 补全、语法高亮和多行编辑，开箱即支持 zsh、bash 和 fish。

@GitHub_Daily原推文1 张图片在终端里开好几个 Claude Code 同时跑任务，来回切窗口找哪个在等输入，挺费神。 tty7，一个纯 Rust 写的终端工作台，把命令行、会话、远程登录、编码 Agent 整合一块。哪个 Agent 在等我们输入，托盘图标会亮，重启之后会话还能接着恢复。 GitHub：http://github.com/l0ng-ai/tty7 会话是常驻的，关掉窗口或者重启机器，里面的命令行照样在跑，不用再套一层 tmux。输入体验做得像编辑器，历史建议、按 Tab 键补全、语法高亮、多行编辑都内置，zsh、bash、fish 零配置。远程登录也是自己实现的一套，配置存进钥匙串，还带文件传输面板、端口转发和跳板机。提供 macOS、Windows、Linux 原生安装包，经常在终端里使用 Agent 的朋友可以试试。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

在终端里开好几个 Claude Code 同时跑任务，来回切窗口找哪个在等输入，挺费神。 tty7，一个纯 Rust 写的终端工作台，把命令行、会话、远程登录、编码 Agent 整合一块。哪个 Agent 在等我们输入，托盘图标会亮，重启之后会话还能接着恢复。 GitHub：http://github.com/l0ng-ai/tty7 会话是常驻的，关掉窗口或者重启机器，里面的命令行照样在跑，不用再套一层 tmux。输入体验做得像编辑器，历史建议、按 Tab 键补全、语法高亮、多行编辑都内置，zsh、bash、fish 零配置。远程登录也是自己实现的一套，配置存进钥匙串，还带文件传输面板、端口转发和跳板机。提供 macOS、Windows、Linux 原生安装包，经常在终端里使用 Agent 的朋友可以试试。

背景

Claude Code 是 Anthropic 推出的代理式编码工具，运行在终端中，允许开发者与能够理解代码库、编辑文件和运行命令的 AI 进行交互。开发者经常同时运行多个此类代理实例，因此需要在终端窗口之间切换并追踪哪个代理需要输入。tmux 是一种流行的终端复用器，可实现持久会话，但需要手动设置和管理。tty7 旨在提供一个更集成、更用户友好的替代方案。

7月26日 13:30在 X 打开#terminal #Rust #developer-tools #AI-agents #open-source

087.0

Cloudflare 开源 Nimbus 文档生成工具，同时服务人类与 AI Agent

Cloudflare 发布了 Nimbus，一个基于 Astro 的开源文档生成工具。它能生成静态 HTML 站点，并附带适合 AI 阅读的纯文本版本、全文搜索和多版本支持。用户可以直接修改所有文件，因为该工具没有隐藏的依赖项。 Nimbus 满足了日益增长的需求，即文档既能被人类阅读，也能被 AI Agent 访问，从而改善开发者工作流和 AI 集成。其静态输出和轻松部署到 Cloudflare 服务的特点，降低了维护高质量文档的门槛。这可能会影响开源项目和企业如何在 AI 驱动的生态系统中处理文档。 Nimbus 基于 Astro 构建，Astro 是一个以输出极简 JavaScript 著称的现代静态站点生成器。每个页面都包含纯文本版本和专为 AI 模型准备的文件，以及站点地图和社交分享预览图。它支持全文搜索、明暗主题、层级导航和移动端侧边栏。生成的站点是纯静态 HTML，可通过一条命令部署到 Cloudflare。

@GitHub_Daily原推文1 张图片Cloudflare 团队，最近开源一个文档生成工具：Nimbus，专为人和 AI Agent 打造。只需一条命令，基于 Astro 构建布局、组件、样式等文档内容，并提交到自己仓库。而且都能直接修改的真实文件，不是藏在依赖包里的黑盒，想删哪块删哪块。 GitHub：http://github.com/cloudflare/nimbus 每个页面都配一份纯文本，还有给模型读的专属文件、站点地图和分享预览图。同时提供全文搜索、明暗主题、层级导航、移动端侧边栏等功能，也可以维护多个版本文档。构建出来站点都是纯静态的 HTML 文件，可以一键部署到 Cloudflare 服务上。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

Cloudflare 团队，最近开源一个文档生成工具：Nimbus，专为人和 AI Agent 打造。只需一条命令，基于 Astro 构建布局、组件、样式等文档内容，并提交到自己仓库。而且都能直接修改的真实文件，不是藏在依赖包里的黑盒，想删哪块删哪块。 GitHub：http://github.com/cloudflare/nimbus 每个页面都配一份纯文本，还有给模型读的专属文件、站点地图和分享预览图。同时提供全文搜索、明暗主题、层级导航、移动端侧边栏等功能，也可以维护多个版本文档。构建出来站点都是纯静态的 HTML 文件，可以一键部署到 Cloudflare 服务上。

背景

Astro 是一个静态站点生成器，允许开发者使用基于组件的架构构建快速网站，并减少 JavaScript 的使用。像 Nimbus 这样的文档生成器可以自动从源文件创建结构化、可导航的文档。Cloudflare 是一家主要的网络基础设施公司，提供 CDN、DNS 和边缘计算服务，其工具在开发者社区中被广泛采用。

7月26日 11:30在 X 打开#open-source #documentation #developer-tools #cloudflare #AI

097.0

ChatGPT 通过单一提示自主执行复杂多步骤任务

有用户展示，ChatGPT 能够自主处理复杂的多步骤任务——例如规划团体旅行、构建协调网站和起草电子邮件——只需从手机发送一个提示即可完成。Sam Altman 分享的示例显示，ChatGPT 利用聊天历史生成想法，创建用于团体协调的全栈网站，并在达成团体共识后进行预订。这标志着从简单问答到自主任务执行的转变。这一能力代表了 AI 作为自主代理的范式转变，从被动聊天机器人进化为能够独立规划和执行工作流程的主动助手。它有可能通过自动化繁琐的多步骤流程，显著提升个人和专业生产力。在单一会话中集成网页浏览、代码执行和邮件起草等工具，使 AI 成为更强大且实用的日常工具。该任务包括利用聊天历史进行旅行创意头脑风暴、为 9 人构建全栈协调网站以及起草电子邮件——所有这些都在无需用户进一步干预的情况下顺序执行。这是通过 ChatGPT 的“工作”模式实现的，该模式由 GPT-5.6 驱动，专为具有明确结果的任务而设计。整个演示完全通过手机完成，凸显了该功能的可访问性和便利性。然而，这种自主执行在处理模糊指令或需要人类监督关键决策（如金融交易）时可能仍存在局限性。

@thsottiaux引用推文Let ChatGPT *work* for you. How many time have you wanted to negotiate your internet bill, get rid of all those spam emails you’re subscribed to, or find the perfect deal for something you wanted to do or buy. It’s quite literally just one prompt away, all from the comfort of your phone. It does at least 20 things for me every single day and I’m still surprised.展开原推文收起原推文

@thsottiaux

Let ChatGPT *work* for you. How many time have you wanted to negotiate your internet bill, get rid of all those spam emails you’re subscribed to, or find the perfect deal for something you wanted to do or buy. It’s quite literally just one prompt away, all from the comfort of your phone. It does at least 20 things for me every single day and I’m still surprised.

@sama

chatgpt work is remarkable, and "work" undersells it. from my phone i sent: "use all my chat history to figure out ideas for a long weekend trip with 8 friends, plan the best three options, make a full-stack site where the 9 of us can coordinate on what we would want to do in each place and decide where to go, and then after we get to group agreement make reservations. draft an email in my gmail i can send out to my friends when the site is ready." it...just worked.

背景

ChatGPT 的“工作”模式是一项旨在帮助用户完成具有明确结果的任务的功能，例如创建简报、演示文稿或分析。它连接工具并自动化任务，超越了简单的聊天交互。自主 AI 代理（如 AutoGPT 或 LangChain 代理）是能够根据高级目标独立规划和执行多步骤任务的系统。这与需要逐步指令的传统聊天机器人形成对比。AI 代理的概念正逐渐流行，作为一种无需持续人类指导即可自动化复杂工作流程的方式。

社区讨论

社区对实际应用表示兴奋，许多用户分享了使用 ChatGPT 进行日常自动化的类似经历。一些人强调了从被动 AI 到主动代理的范式转变，而另一些人则指出了更复杂集成的潜力。少数用户对可靠性以及在关键任务中需要人类监督表示担忧。

7月26日 18:21在 X 打开#ChatGPT #AI agents #productivity #automation

107.0

非对称界面：语音输入与视觉输出的人机交互设计

@thsottiaux 的推文和 @guinnesschen 的引述强调了一个设计洞见：与 AI 对话时，语音输入更快，而阅读输出更快，因此提倡非对称界面。这一原则已应用于桌面版 ChatGPT Voice 的设计中，用户说出想法，模型则选择最佳视觉方式展示答案。这一洞见通过分别优化输入和输出模式，解决了人机交互的根本瓶颈。它可能影响未来 AI 界面的设计，使其更高效、更自然，尤其在语音 AI 助手在桌面和专业环境中日益普及的背景下具有重要意义。非对称界面利用了说话通常比打字快、阅读比听合成语音快的特点。桌面版 ChatGPT Voice 于 2026 年 7 月 23 日在 macOS 和 Windows 上发布，允许用户通过语音处理任务并查看回复，将语音控制与视觉输出相结合。该设计让 AI 自行决定最佳格式（文本、图像或其他媒体）来传递信息，从而提升带宽。

@thsottiaux引用推文1 个视频It was always possible to speak to your computer. It wouldn’t do much in return. But we fixed that bug. 原推文媒体预览

展开原推文收起原推文

@thsottiaux

It was always possible to speak to your computer. It wouldn’t do much in return. But we fixed that bug.

@guinnesschen

Speaking is faster than typing. Reading is faster than listening. The highest bandwidth interface between humans and AI is asymmetric. That’s how we designed ChatGPT Voice on desktop: speak your thoughts and let the model choose the best way to show you its answer.

背景

传统计算机界面大多是对称的，输入和输出使用相同模态（如打字和阅读文本）。Siri 或 Alexa 等语音助手则全程使用语音，但听取长篇回复可能较慢。非对称界面的概念认识到不同模态各有优势，结合使用可以优化人机交互。桌面版 ChatGPT Voice 就是一个例子，它将语音输入与视觉显示相结合，让用户自然说话，同时获得丰富、可快速浏览的回复。

7月26日 05:43在 X 打开#human-AI interaction #voice interface #design principle #ChatGPT

117.0

ChatGPT Work 智能体现支持网站持久登录

ChatGPT Work 智能体现在可以访问需要用户登录的网站。用户只需在云端浏览器中登录一次，登录状态便会在后续智能体任务中持久保留。该功能已在 ChatGPT 移动应用中上线。此更新消除了移动用户的一大痛点，他们此前在使用智能体时需反复认证。它极大扩展了 ChatGPT Work 可自动化的任务范围，包括涉及个性化或订阅服务的任务。通过实现无缝、持久的认证网站访问，OpenAI 让 AI 智能体在日常工作效率流程中更加实用。该功能使用云端浏览器，用户可接管并进行首次登录。之后，智能体可在同一网站上继续执行任务，无需进一步干预。登录状态跨会话保持，因此后续任务无需重新认证。这在移动端尤其有用，因为输入凭据较为繁琐。

@thsottiaux引用推文1 个视频Game changer when used from mobile. Available in the ChatGPT app already. 原推文媒体预览

展开原推文收起原推文

@thsottiaux

Game changer when used from mobile. Available in the ChatGPT app already.

@OpenAIDevs

Your ChatGPT Work agent can now use websites that require you to sign in. Take over the cloud browser to log in, then let your agent continue the task. Your login persists across sessions, so you only have to sign in once.

背景

ChatGPT Work 是 ChatGPT 内置的 AI 智能体，旨在通过整合上下文和使用网页浏览等工具来处理复杂的多步骤任务。此前，智能体只能访问公开网站或无需登录的网站，限制了其在个性化服务中的实用性。云端浏览器是运行在远程服务器上的虚拟浏览器，允许 AI 像人类用户一样与网页交互。持久登录意味着认证 cookie 或令牌被保存并重用，因此用户无需在智能体每次启动新会话时都重新登录。

7月26日 04:04在 X 打开#ChatGPT #AI agents #productivity #mobile

126.0

弱模型设计、强模型顾问的弊端与更优替代方案

@dotey 在推文中质疑了“顾问”模式的有效性，即让较弱的模型设计、较强的模型提供建议。作者认为这种设置常因设计不佳、过度自信或过度依赖顾问而失败，并提出应由强模型设计、弱模型执行、强模型验收的替代方案。该讨论揭示了多智能体LLM系统中的关键设计选择，模型角色的分配直接影响成本、效率和输出质量。随着智能体AI模式的普及，理解模型能力与任务分配之间的权衡对于构建可靠且经济高效的系统至关重要。推文指出了三种失败模式：弱设计者提出糟糕的问题、因过度自信而忽视顾问、或过于频繁地咨询顾问。提出的替代方案——强设计、弱执行、强验收——旨在最大化强模型在关键决策上的影响，同时最小化成本。Anthropic于2026年4月发布的顾问策略强制采用类似模式，即强顾问搭配弱执行者，但不允许反向配置。

@dotey引用推文advisor 来自这里😅 https://x.com/dotey/status/2080913463577112611?s=20展开原推文收起原推文

@dotey

advisor 来自这里😅 https://x.com/dotey/status/2080913463577112611?s=20

@dotey

我有个疑惑，如果让弱一些的模型设计，聪明的模型当顾问，那么有几种可能： 1. 它设计就是很糟糕的，问的问题也问不到点子上，那再聪明的顾问也给不了好的建议 2. 它很自负，不觉得自己的有问题，明明该去问聪明模型而不去问 3. 它很不自信，一点小问题就去问聪明模型这些可能都让所谓的 /advisor 模式没有什么用。为什么不让聪明的模型去设计，让弱一点的模型去执行，最后聪明的模型去验收？这样应该才是性价比最高的组合方式。

背景

在多智能体LLM系统中，可以为不同模型分配“设计者”或“顾问”等角色以协作完成任务。“顾问”模式通常让较弱的模型处理常规工作，并将复杂决策升级给较强的模型。Anthropic的Claude顾问工具将此模式正式化，将较小的执行模型与较大的顾问模型配对，但API限制顾问模型的能力至少不低于执行模型。推文的批评与高层规划和验证应利用最强智能的原则一致。

7月26日 07:55在 X 打开#AI #LLM #multi-agent #reasoning