Arc 要彻底下线了，多好的浏览器啊~

读到一篇很有意思的文章，作者把自己这几年折腾的一堆项目串成了一条线，发现其实一直在做同一件事：如果互联网是 2026 年才被发明的，它应该长什么样？

他的规划相当彻底：HTTP 402 支付（把 Cloudflare×Coinbase 的 x402 和 Lightning 的 L402 抽象成一个 API，做成 crypto 版 Stripe）、按邓巴数（150 人）限流的社交网络、新的区块链域名体系 Dap（Blake3 PoW + VDF/VRF，取代有 pre-mine 和抢注问题的 Handshake）、自己造代码托管平台、订阅制短视频（视频最长 5 秒或 5 分钟，创作者拿 85%），甚至还有操作系统和模块化硬件。

最戳我的是那句"想法是免费的，执行才是一切"，以及"创新活在所有既有基础设施的约束之外"。虽然大概率是宏大叙事烂尾预定，但一个人把整个 stack 拆掉重来的冲动，挺迷人的。

来源：blog.webb.page

今天各种升级修复。。。幸好有ai

Deno 加入 Cloudflare、Bun 去了 Anthropic，运行时这一层看起来在收敛。

但看完 vlt 这篇写 Deno 的文章，反而更认同一件事：开源生态里，项目没赢，不等于想法输了。

Deno 没有替代 Node，甚至最终还是走向了 npm / Node 兼容；但 fetch、权限模型、TypeScript 直接跑、单文件分发这些能力，已经被带进了 Node 的默认体验。包管理也是一样：Yarn 的确定性安装、pnpm 的存储模型、Bun 的性能压力，以及各家对 install scripts 默认安全策略的推动，最后都在彼此影响。

成熟生态通常不缺好想法，缺的是把「以后再做」变成「现在必须做」的紧迫感。竞争者的价值，很多时候就在这里。

所以从工程视角看，保留选择和竞争，通常比押注某个唯一答案更重要。

原文：
www.vlt.io

企业接 Agent，我觉得最容易被低估的是数据准备和权限治理。

大家很容易先讨论用哪个模型、做哪个 demo；但真正难的是：哪些数据可以给 Agent 看，能看多少，能不能写回，谁来审批，出了问题怎么追。

而且组织数据越关键，Agent 带来的攻击面就越大。

所以 AI 落地的第一步可能不是接一个更强的模型，而是把数据、权限和审计先补齐。

这篇让我更确定一件事：以后 Agent 产品的差异，可能不主要在聊天框，也不只在模型分数。

真正的差异会在 harness。

工具怎么接、权限怎么管、子 Agent 怎么协作、过程怎么留痕、风险操作怎么审批，甚至人怎么在中途介入。

模型负责生成能力，harness 决定这套能力能不能稳定地进入真实工作。

一个我准备加进工作流里的习惯：让 Agent 写实现笔记。

不只是告诉我“做完了”，还要说清楚：
- 为什么这么做
- 哪些方案没选
- 依赖了什么假设
- 哪些边界没覆盖
- 还有什么需要我确认

很多 Agent 的问题不是完全不会做，而是它自己替你做了取舍。

代码是结果，实现笔记才是我判断它有没有做偏的依据。

AI 写代码时，effort 也不该无脑拉满。

做个 UI 原型、改个样式，low / medium 很可能就够了；但代码审查、安全、权限、生产 API 这种事，high 甚至 max 才有意义。

高 effort 很多时候不是让模型“更会写”，而是让它多花时间验证、补边界、反复检查。

所以重点不是永远用最强档，而是知道什么事情值得花这个成本。

和 Agent 协作，越来越觉得最难的不是把需求讲清楚，而是发现自己其实没想清楚什么。

很多时候不是模型能力不够，是我以为自己知道要什么，直到它给了结果，才发现：这不是我想要的。

所以现在比起直接让它开干，我更愿意先让它把假设、缺的信息、可能的分歧列出来。

把“未知项”提前摊开，应该是减少返工最便宜的方式。

我现在不太相信“prompt 不重要”这句话。

更准确地说，prompt 的格式没那么重要，但信息量很重要。

有时候我对着语音输入讲两分钟，背景、纠结点、例外情况全倒出来，效果反而比憋半天写一段工整的 prompt 好。

模型不缺漂亮格式，它缺的是我脑子里那些默认存在、但没有说出口的上下文。