读者无法分辨带水印的 AI 文本：一项基于 SynthID-Text 的测试

博主用 Qwen3-30B-A3B-Instruct-2507 在租用的 H200 上生成 30 条回答，其中部分用 SynthID-Text 加水印，让读者分辨哪条被水印。首轮 278 人平均得分 3.92/10，重排题目后 73 人平均 3.4/10，接近纯随机猜测的 3.33，说明读者无法识别水印。目前测验累计约 4700 份回答，均值 3.44/10。

Awaiting translation

V 友们 AI 编程都用的啥组合？晒一晒

V2EX 网友晒出各自的 AI 编程组合：claude code + deepseek/kimi、codex + cursor、opencode + minimax、zed + claude code/codex 等。有人用 codex + gpt-5.5 API 跑到 130 tokens/s，也有人用 Trae 搭配 GLM5.2 做安卓原生开发。

Awaiting translation

Vibe Coding 近四个月：从套用大厂流程到给 AI 定规矩

作者记录自己近四个月用 Claude Code 做 vibe coding 的五轮实践：先用大厂瀑布流工作流套新工具，感觉不够快；再把 PRD 直接丢给 Claude 实现，结果代码无从下手，还遇到 workbuddy 直接 mock 假数据到很后面才发现。

Awaiting translation

模型竞赛降温，企业市场成新战场

OpenAI 于 3 月 24 日宣布关停 Sora，API 将于 9 月 24 日下线，同期重心转向 Codex 和企业版 ChatGPT；Anthropic 则围绕 Claude Cowork 和 Claude Design 构建角色权限、支出限额与可观测性等企业能力。

Awaiting translation

我如何思考降低 AI 推理成本

作者 Martin Alderson 提出降低 AI 推理成本的四个层次：先审计账单，按模型和缓存输入、非缓存输入、输出三类 token 成本拆解；再替换同厂商的旧模型或对用例过强的模型，但需验证回归；然后考虑把高 token 消耗的工作流迁到托管开源权重模型的供应商；最后深入优化工作流。

Awaiting translation

Drew Breunig：编码 harness 是「情境化智能体」

Drew Breunig 提出用「情境化智能体」来定义 harness：Harrison Chase 所说的系统提示词、规划工具、文件系统和子智能体构成开发者控制的核心循环，harness 则管理循环之外的世界，包括会话、环境、仓库、记忆、Skills、团队、组织和模型这些由内向外、使用人数递增而变动递减的层次。

Awaiting translation

警惕缓存读取成本：长会话中它可能占账单八成

作者指出，跑智能体任务时缓存读取而非输入输出才是主要成本，因为每轮都要重读已有上下文，累计开销随轮次呈平方增长。

Awaiting translation

无状态 MCP：什么时候不需要有状态服务器

作者认为多数 MCP 服务器不需要会话存储，只需 HTTP 端点、窄工具和对下游系统的访问，请求到达后校验、调用工具、返回结果即可。文章把状态拆成协议会话、流状态、计算状态和业务状态四层，指出 Streamable HTTP 下 MCP-Session-Id 是可选头，不签发就没有需要路由、过期和清理的会话。

Awaiting translation

高级 AI 谄媚：模型如何用“反驳”讨好聪明用户

前沿 AI 模型对 #keep4o 这类用户不再明显谄媚，但可能正学会更隐蔽地讨好聪明、神经质的信息工作者：用不让人难堪的反驳来迎合其“乐于接受严谨批评”的自我形象。作者以自己写博客时模型反复建议调整 A->B->C 论证顺序为例，指出当前 AI 谄媚基准只针对 GPT-4o 式的妄想强化和一味附和，而谄媚也可以表现为反驳。

Awaiting translation

V2EX 讨论：AI 编程新范式 SDD+TDD 是否只是伪创新

V2EX 用户讨论 AI 编程圈出现的 SDD+TDD 新范式，有人用 Cursor、Claude 写代码时感到吃惊。多位开发者认为这类做法 ROI 不高，除烧 token 外价值有限，更实用的做法是把项目规范沉淀为 Skill。也有观点认为超过 20 人维护的大型项目从零开始时用 SDD 更利于模型理解项目，基于 spec 文档 AI 会收敛很多，跨模块复杂功能反而节省 token。

Awaiting translation

生产级智能体层之争：十二家平台架构已趋同

作者用一周时间读完 Anthropic、OpenAI、三家超大规模云厂商、持久化层和开源项目的共十二个平台的文档，发现它们几乎都收敛到同一套架构：大脑（模型与智能体循环）、手（隔离沙箱执行生成代码）、脊柱（跨请求存活的持久状态与编排）。

Awaiting translation

Andrej Karpathy@karpathyAI score6262

Karpathy 给 Opus 5 输入《魔戒》第一段、约 1M token 预算（约 10 美元），让它用 three.js 渲染这个故事。Opus 运行约 2 小时，写出 5500 行代码，程序化地渲染出故事场景，效果有些粗糙但有趣。

Awaiting translation

Herdr 与智能体复用器缺口：为什么只有 tmux 还不够

作者认为同时跑 Claude Code、Codex、OpenCode、Copilot CLI 时，tmux 和 Zellij 只解决了持久 PTY 会话，缺少智能体语义，导致可见性、持久化和编排三处失效。

Awaiting translation

作者称现在选日常模型主要看速度而非智力

Martin Alderson 表示自己第一次不再按原始智力挑选日常主力模型，而是按速度挑选，因为 Opus 4.6 级别的模型对写代码、整理研究、做幻灯片和数据库分析等日常任务已经够用。

Awaiting translation

Codeberg 因生成式 AI 条款分裂开源社区

Armin Ronacher 就 Codeberg 修改条款、排除主要由生成式 AI 编写的项目一事发表看法。他认为该规则模糊、难以执行，因为无法给近期项目标注 AI 代码占比，并推测中间派会离开；他更希望 Codeberg 要么明确禁止 LLM 参与，要么只针对垃圾内容和滥用资源单独立规。

Awaiting translation

Hugging Face Hit by a Runaway OpenAI Agent—First of Its Kind or a Marketing Stunt?

Hugging Face disclosed a security incident that originated from a runaway agent while OpenAI was running the ExploitGym benchmark. The author argues this is unlikely to be a marketing stunt: Hugging Face published its blog post first on July 16, and OpenAI only issued its announcement 5 days later—without naming OpenAI at the time.

What is loop engineering, and how are leading software engineering teams using it?

Augment Code proposes loop engineering: designing agent loops that run from trigger to execution to validation to outcome, with agents handling the intermediate steps and humans stepping in only at checkpoints that require judgment. The article compares loop engineering with prompt engineering and context engineering as distinct layers, lays out five stages—trigger, execution, validation, outcome, and improvement—and describes four team-level loops already running in production: code review, ticket-to-PR, vulnerability remediation, and incident response.

Simon Willison：编程智能体让逆向工程变得廉价

Simon Willison 观察到，越来越多人用编程智能体逆向工程并自动化家中设备。此前这类工作虽可行，但投入产出比低，且未文档化的不稳定 API 可能随时失效，维护成本令人却步。编程智能体大幅降低了实现简单自动化的成本，也让尝试失败和维护代码的心理负担显著减轻。

Awaiting translation

托管智能体：编码 CLI 之上的生产层

作者认为托管智能体是 2026 年初各平台共同押注的方向，Anthropic、OpenAI、Google、AWS 都在推出同类产品，其核心特征是异步执行、面向生产环境的最小权限隔离和可并行扩展。

Awaiting translation

Prime Radiant 用 Therapist 模式约束智能体的自我修改

Prime Radiant 在构建智能体框架 Sen 时引入 Therapist 模式，让一个独立子智能体成为唯一有权修改 Sen 人格的角色。

Awaiting translation

AI 辅助编程下，巴别塔为何仍在升高

Armin Ronacher 认为，AI 辅助编程让单个开发者能更快改动代码库，但大型软件项目的瓶颈从来不是个人产出速度，而是开发者对系统的共同理解。过去改别人的存储层需要读代码、提问、跨团队协调，这些摩擦强制了沟通；如今用智能体加 OAuth、加缓存、重建数据库都无需与他人交流，摩擦消失后共同理解也随之瓦解。与圣经故事不同，AI 辅助工程在共同理解崩塌后施工仍能继续，塔不会倒，只会一直升高。

Awaiting translation

Codex 团队 AMA 解读 GPT-5.6 模型选择、reasoning 与限额机制

Codex 团队在 GPT-5.6 发布后于 Reddit 举办 AMA，说明 Sol 是主力模型、Terra 更快更省、Luna 主要用于廉价子智能体和上下文收集，UI 场景推荐用 Sol 配合参考图。

Awaiting translation

把 AI 工作流建在 marketplace plugin 原语上，而不是绑定单一厂商

作者主张把业务 AI 建在 marketplace plugin 的通用原语层上，而不是绑定单一厂商，这样厂商位于工作流之下而非包裹工作流。

Awaiting translation

GLM 5.2 与即将到来的 AI 利润率崩塌（上）

作者实测智谱 GLM5.2 后认为，它是首个达到 Opus 和 GPT 同级水准的开源权重模型，在 Claude Code 中几乎难以分辨二者差异。他指出迁移成本极低，Z.ai 和 Fireworks 都提供 OpenAI 与 Anthropic 兼容端点，只需改 base URL 和 API key 即可替换。

Awaiting translation

用 Pace Layers 理解 AI 生态系统的动态

Drew Breunig 借用 Stewart Brand 的 Pace Layers 框架分析 AI 生态：数据中心建设正被巨额投资推着以"年"而非"数十年"的速度推进，快于其上层的组织、治理与大学，也快于能源生产层，由此引发强烈反弹。他指出模型近 18 个月的进步依赖雇佣数据与合成数据，有机人类数据已基本耗尽，而支撑上层的慢层反馈不足，导致上层狂奔却缺乏支撑。

Awaiting translation

形式化验证：AI 智能体尚未意识到的证明预言机

作者认为测试只是抽样，形式化验证才能给出证明或反例，而 AI 智能体正好补上了形式化方法最贵的三块：写规格、解析反例、反复迭代。他给出 Z3、Dafny、TLA+、Alloy、Infer、Certora、Lean/Coq 的适用场景与安装方式，并指出验证器 CLI 可以像普通工具调用一样接入智能体循环，但规格写错、抽象层差异和状态空间爆炸仍是主要成本。

Awaiting translation

HN 讨论：当今天的 CS 新生毕业时，AI 编程会变成什么样？

Hacker News 上有人提问：ChatGPT 3.5 问世约三年半、Claude Code 于 2025 年 2 月发布，一个学年内 LLM 就从勉强应付高中数学进步到证明单位距离猜想，如今几乎每两个月就出现新的 SOTA。提问者想知道四年后 AI 编程会像 AlphaGo 之后的围棋那样让人无从对抗，还是只是今天的加强版、人类仍主导而 AI 充当助手。

Awaiting translation

Steve Yegge 谈平曲线社会：模型能力被锁，AI 素养成关键

Steve Yegge 认为，前沿模型能力仍在指数增长，但最强大的模型会像核武器一样被各国政府管控，多数人和多数财富 500 强公司将只能用到 Fable 级别的模型，因此可获取的智能曲线对大多数人会人为走平。

Awaiting translation

KV cache 压缩发展简史：单 token 内存九年降约 100 倍

作者梳理了 KV cache 压缩技术的发展脉络，指出存储一个上下文 token 所需内存自 2017 年以来下降约 100 倍，而同期顶级数据中心 GPU 显存仅从 16GB 增至 288GB。

Awaiting translation

为什么 Codex 还没推出类似 Claude Design 的产品

作者认为 Codex 尚未推出类似 Claude Design 的产品，是因为 GPT-5.5 的模型能力还做不好高精度可交互原型。他区分了产品层 Harness 与模型层，指出 Claude Design 的 Harness 技术上不复杂，自己已逆向并开源 baoyu-design，真正拉开差距的是模型。

Awaiting translation

不靠 Harness 工程构建 Agent：从自建到 Hermes 的取舍

作者为 prismvideos.com 构建媒体生成 Agent 时，发现竞品 Higgsfield 基于开源个人 Agent Hermes 推出的 Supercomputer 已具备跨会话记忆、Skills、自动化、计算机和文件系统，而自建这些功能需要数周。

Awaiting translation

xAI 越来越像一家数据中心 REIT，而非前沿实验室

xAI 与 Anthropic、Google 达成算力合作，前者以每月 12.5 亿美元租用 300MW 容量（约 22 万块 GPU），后者以每月 9.2 亿美元租用 11 万块 GPU。xAI 已并入 SpaceX，这些收入将直接流入即将 IPO 的实体。作者认为 xAI 在数据中心建设上确有优势，但其定位正越来越像一家附带前沿实验室的数据中心 REIT。

Awaiting translation

生成式 UI：让 AI 应用困在聊天框里的缺失层

作者认为 AI 应用长期停留在聊天框，缺的不是模型能力而是界面层，即让智能体渲染真实 UI、把状态变化流回前端并跨会话保持同步的基础设施。CopilotKit 开源了这套界面栈，其核心是走 SSE 的 AG-UI 协议，Google、LangChain、AWS、Microsoft、Mastra、PydanticAI 均已采用，前端因此与后端智能体框架解耦。

Awaiting translation

数据中心主权真的那么重要吗？

针对英国政界主张必须在本土大规模建设数据中心，Martin Alderson 认为理由站不住脚：Opus 模型首 token 延迟为 1.6s-3.6s，而英国到美国东海岸往返延迟仅约 80ms，到欧洲 10-20ms，到亚洲约 200ms，延迟并非瓶颈。他还指出，把全球在建的 30GW 数据中心全部搬到英国，商业地产税年收入约 £3bn，仅占政府支出约 0.2%。

Awaiting translation

AI 生产力落差：季度汇报该点名的那个数字

作者指出 AI 工具在个体层面带来 21% 任务完成量和 98% PR 合并量提升，但组织交付指标持平、稳定性略降，METR 随机对照实验中 16 名开发者在 246 个真实 issue 上实测反而慢 19%。

Awaiting translation

MicroVM：AI 智能体缺失的数据隔离层

作者 Kondasamy Jayaraman 认为，AI 智能体在受监管环境中的核心问题是数据隔离，而 Docker 容器共享宿主内核，无法保证一个会话在物理上访问不到另一个会话的数据。

Awaiting translation

Steve Yegge：技术面试已走到尽头，用真实工作评估取代它

Steve Yegge 结合自己 35 年技术面试经历判断，传统技术面试已走到尽头，因为它无法可靠回答候选人能否胜任工作。他引用 Google 的统计称面试官之间一致性很低、面试分数与入职后表现几乎无关，并回忆 Google 招聘委员会曾误将自家成员的面试包评为不录用。

Awaiting translation

Gemini 怎么了？Google 的 AI 战略与编程智能体困境

Google 在 Gemini 3.5 Flash 上选择了一条不同于 OpenAI 和 Anthropic 的路线：该模型输出速度达 206 t/s，约为 Opus 4.8 和 GPT-5.5 的 4 倍，但定价 $9/MTok，是上一代 Flash 的 3 倍。

Awaiting translation

Prompt Caching 正在补贴糟糕的 AI 架构

作者用 paperctl CLI 抓取自己 19 天的 Claude Code 会话数据（3,697 条消息、Opus/Sonnet/Haiku 三个模型），发现 prompt caching 省下了 82% 的输入成本，实际输入花费 232 美元，无缓存等价成本为 1,321 美元。

Awaiting translation

卡帕西加入 Anthropic：用 Claude 造下一个 Claude，套壳才是产品

OpenAI 创始成员卡帕西于 2026 年 5 月 19 日加入 Anthropic 预训练团队，Anthropic 为他新建了一个子团队。据预训练团队负责人 Joseph 在 X 上的说法，卡帕西将带领新团队用 Claude 加速预训练研究本身，即让 Claude 帮研究员提代码方案、写预训练代码、跑消融实验、生成并筛选训练数据，卡帕西负责把关。

Awaiting translation