2026-第三十八周

该周报主要为各个地方内容的汇总整理

技术

实时与离线是同一个问题

本文比较 Verdant、TanStack DB 与 Zero 三种本地优先方案，作者通过构建 Verdant 离线 CRM 和 TanStack DB/React Admin 集成，发现离线与实时同步本质相同，核心都是调和分歧状态；现有库能提供即时 UI 与离线能力，但在客户端 ID、变更失败恢复、冲突解决和用户反馈方面仍不完整。

• 🧪 作者构建两个项目：Verdant 离线优先 CRM，以及 TanStack DB 接入 React Admin 的集成库，并用 Zero 的 CRM 测试作对比。
• 🌐 传统 Web 应用依赖请求/响应：UI 速度受网络限制，断网即不可用，多用户编辑靠锁，而锁又依赖持续连接。
• 🗃️ 本地优先数据库将读写放在浏览器 IndexedDB，UI 即时更新，后台同步层负责重试、一致性与冲突调和。
• 🌿 Verdant 是端到端方案：schema、存储、同步开箱即用，冲突策略称“冲突避免”，实际多为最后写入者胜。
• 🧱 TanStack DB 是通用响应式查询基础：提供 live collections，但同步层留给开发者，适合逐步搭建可替换后端。
• ⚡ Zero 是完整同步引擎：客户端 + Postgres 服务端缓存，内置认证、权限和双向同步。
• 🧩 TanStack DB 与 React Admin 范式不匹配：React Admin 的 data provider 是 Promise 异步函数，TanStack DB 是响应式集合，实时查询难以直接接入。
• ⚙️ 集成还遇到 react-query 双客户端问题：React Admin 需要 networkMode always，TanStack DB 需要默认队列行为，二者需分开配置。
• 🆔 本地变更要求客户端生成 ID：UUID/ULID/Nanoid 等更合适；若现有模型用服务器 ID，支持离线写往往需要破坏性迁移。
• 🧨 变更失败与恢复缺少内置支持：TanStack DB 无回滚/重试/通知，Zero 可能静默回滚，Verdant 同步失败也需自行处理。
• ⚔️ 冲突解决普遍是 last-write-wins：Verdant 与 Zero 大体如此，TanStack DB 不表态；可能丢失更新，且缺少冲突提示、合并或丢弃界面。
• 🔄 核心发现：离线与实时同步是同一个问题；差异只是断网时长，二者都需同步协议、乐观变更与分歧状态调和。
• 🎯 适用场景：弱网/现场作业、实时协作最明显；作者认为本地优先架构普遍值得，因为它迫使团队正视冲突并提升韧性。
• 🧭 结论：Verdant 省心但需接受其冲突策略；TanStack DB 灵活但不解决同步本身；当前库仍缺失败反馈与冲突合并路径，如何告知用户“两个真相不一致”仍是核心挑战。

抽象对人类和 AI 智能体的代价

过度抽象看似提升可维护性，实则给人类和 AI Agent 增加隐性成本；作者通过实验估计，过度抽象的代码库会让 AI Agent 成本与耗时增加约 30%，最差任务达 5 倍，因此应只在真正需要时抽象。

• 🧠 抽象是隐藏实现并提供可复用接口的边界，如函数、类、组件、CSS 类、文件、包等。
• ✅ 抽象对大型系统至关重要，可隐藏复杂度、命名和复用代码，但必须权衡成本与收益。
• ⚠️ 过度抽象很难察觉，会逐渐累积；开发者常因害怕修改旧抽象、时间压力、教育训练和团队文化而不断添加新层。
• 💸 每次抽象都带来间接成本：代码分散、跳转增多、心智负担上升；人类和 AI 每次读代码都要付出。
• 🤖 AI 从人类代码中学会过度抽象，因此也会复制这一反模式，并推高使用成本。
• 📊 实验用 4 个代码库、394 次 Agent 运行测量：过度抽象任务成本在 0.8x 到 5x 之间，最差是改按钮颜色，成本高 5 倍、时间高 4.3 倍。
• 🔍 成本主因不是代码量，而是跨文件抽象层：读取文件和模型往返轮次显著增加；同文件内抽象对 AI 几乎免费。
• 🧾 对真实中大型代码库的保守外推：过度抽象使 AI Agent 账单约增加 30%。
• 🧩 不应抽象的例子包括：无意义常量、静态 JSX 列表映射、简单工厂函数、多余 CSS 类、父组件提前消费 context、只做重命名的翻译层。
• 🛠️ 建议：用类型系统保护值表达式；从最接近使用处消费 context；遵循现有库/后端命名；优先共置代码，避免不必要跨文件边界。
• 🧭 结论：抽象不可少，但每个抽象都有成本；应“先思考再抽象”，在代码审查中识别过度使用，并明确指导团队和 AI Agent。
• 📜 作者公开了 no-over-abstraction.md 规则，希望降低人类心智负担和 AI 账单。

2030-shaped software

文章认为：到 2030 年，AI 代理将成为软件的主要用户，因此现在就要按“代理优先”构建产品——让代理负责执行，人类专注判断、决策、信任与验证；聊天是入口，生成式 UI 与必要专用界面补足交互，并以云端和多触点实现无处不在。

• 🤖 核心判断：2030 年 AI 代理会成为软件的首要用户，要构建“2030-shaped software”，而不是只给现有产品加 AI。
• 🧠 人与代理分工：代理负责“做”，人类负责判断、决定、排序、消除歧义，以及理解与信任结果。
• 🧱 传统“操作型”UI 如按钮和表单将减少，转而支持审批、优先级、方向选择、验收与安全确认。
• 🛠️ 产品基础设施要代理优先：人类能做的事，代理也应能做，需完整 API、MCP 服务器、工具和权限。
• ⚠️ 缺少能力是失败模式：如果代理无法创建实验或完成关键步骤，就仍需人类补位，削弱代理价值。
• 🧩 不能只依赖模型提供商；自建代理运行框架可保证质量、保护品牌并持续改进，而上下文是护城河。
• 📚 上下文工程很关键：把源代码、使用数据、客户数据和产品技能，在合适时机输入代理。
• 💬 聊天是前门，生成式 UI 在内部：聊天适合指挥代理，但图表、开关等生成式 UI 能弥补文本低带宽问题。
• 📄 生成式 UI 大多一次性，部分会成为可保留、分享、复制的工件，如报告、文档、代码、PR、配置甚至应用。
• 🔍 文本不够时仍需专用 UI：信任与验证界面、分诊与收件箱界面，用于检查代理工作与处理需人类决策的事项。
• 🚩 不是简单删按钮：若只是查看状态，代理一句话即可；若涉及信任、判断或行动，应分别交给专用 UI 或代理能力。
• 🌐 代理不按应用方式工作：产品应主动到达用户，覆盖桌面、Slack、移动端、邮件、API、语音等。
• ☁️ 云优先是方向：人类与代理共享控制平面，薄客户端接共享后端，支持并发运行大量代理并随处优化输出。
• 🧪 云基础设施必须优秀：沙盒要快速、稳定、不崩溃，让应用无处不在而基础设施隐形。
• 🚀 落地策略：2026 不是 2030。PostHog 选择“半新”路线，先用现有数据与基础设施扩展 PostHog Desktop，再迁移其他界面。
• ⏳ 若不改变，风险是做出“2026 形态 + AI 补丁”的软件；2030 重要的公司会提前多年开始构建。

如何命名事物

命名是软件工程与知识工作的核心技能：清晰的语言几乎总意味着清晰的思考，而每次命名都是在与同事、未来的自己以及语言模型沟通。文章主张按事物本质而非即时需求来命名，把命名视为一种智力共情；坏名字往往暴露出模糊概念，甚至牵出真实缺陷。

• 🧠 命名是基础能力：清晰语言体现清晰思考，含糊命名通常意味着内部理解不清。
• 💬 每次命名都是沟通：变量、函数、字段、API、页面、数据库表和产品名都在传递语义。
• 🤖 LLM 依赖代码库清晰度：术语被“slop-fried”后模型表现会退化；减少、澄清、打磨术语就是控制系统复杂度。
• 🔍 DRY 是语义压缩而非位相同：相同值不一定是同一事实，应抽象事实，而非偶然相等的数字。
• ⚖️ 警惕“一致性”崇拜：Clean Code、OOP、FP 等像带承诺的产品，诱人用规则逃避深入思考。
• 🧩 要一致的是命名过程：综合考虑类型、用途、本质、对称性（如 src/dst）和读者，而非死守“缩写/长名”规则。
• ❤️ 命名是智力共情：不要按“我为什么需要它”命名；如 to-pixels 本质只是浮点转整数，像素叙事应放在调用处。
• 🗓️ 时间字段要看语义：created_at 常是默认，但 uploaded_at/issued_at 取决于行代表真实世界对象还是软件合成对象。
• 📦 名称问题常是模型问题：如 fallbackConfig 是否为 Option[Map] 取决于缺失语义，名称与数据形状应一起审视。
• 🗺️ 坏名会隐藏通用性：mergeTargetValuesIntoSourceTemplate 其实只是 Map 合并，应使用 template ++ values 等惯用法。
• 🧵 坏名常牵出真 bug：documentDate 同时表示文件日期、记录日期和到达日期，导致陈旧规则判断错误，改名还需迁移与回填。
• ✅ 好命名反向检验设计：设计未定型时难以命名是正常信号；好名字自然涌现则是高质量信号。
• 🎯 结论：命名要深思熟虑、整体权衡、按本质而非需求、像在乎一样对待。

工具

GitHub - argyleink/prop-for-that：JS 知道的，现在 CSS 也知道了 · GitHub

prop-for-that 是一个将 JavaScript 可读取、但 CSS 无法直接感知的运行时状态，写入 --live-* 与 --const-* CSS 自定义属性的库，让 CSS 通过 calc() 和 var() 直接组合、响应这些状态。它零依赖、TypeScript 编写、支持 ESM + CJS，并且 SSR 安全。

• 🎯 核心目标：把滑块值、指针位置、元素可见性、视口尺寸、电池、网络、传感器等状态暴露给 CSS。
• 📦 安装使用：npm i prop-for-that；最简单方式是 <script type="module">import 'prop-for-that/auto'</script>。
• 🏷️ 声明式绑定：元素添加 data-props-for="key …"，CSS 中读取对应 --live-* 属性。
• 🎨 示例：<input type="range"> 可通过 --live-value-pct 自绘，无需事件监听或手动渲染循环。
• 🔗 提升与样式查询：自定义属性只向下继承，@container style() 匹配祖先；可用 data-props-to="<selector>" 或 { to } 把值写到最近匹配祖先，供自身或兄弟元素响应。
• ⚡ 性能设计：每帧一次 requestAnimationFrame 刷新，无变化时空闲，标签页隐藏时冻结；写入变更 diff，并全页共享 ResizeObserver / IntersectionObserver。
• 🧠 采样策略：持续采样元素源在离屏时暂停；事件驱动源（表单、range、select 等）不受限制。
• 🧩 按需加载：内置 4 个核心源：viewport、元素尺寸、可见性、<input type="range"> 值；其他均为可选、可 tree-shake 插件，auto 下按 data-props-for 需求懒加载。
• 📡 插件能力：20+ 插件，包括指针、电池、网络/在线、页面焦点/可见性、导航类型、meta 标签、低熵 UA、FPS、时钟、滚动速度、设备方向/运动、定位、CPU 压力、软键盘几何、媒体播放、表单/字段状态、select/color-picker、文本截断、图像/视频主色与强调色、可种子随机数等。
• 🧱 平台整合：可选启用 typed @property 以支持插值，或使用 FOUC 安全常量在首绘前写入；体积小、无依赖、支持多种 bundle 格式。
• 🚪 入口点：prop-for-that/auto 零配置声明式；prop-for-that 提供命令式 API propsFor()、register()、configure()；prop-for-that/head 提供同步 FOUC 安全常量；prop-for-that/plugins 是插件目录。
• ⚠️ 注意事项：auto 只观察 light DOM，不处理 shadow roots，需用 propsFor(el, …)；auto 懒加载插件 chunk，CDN 应使用原样提供 dist 的 unpkg / jsDelivr。
• 📚 文档与 AI 参考：文档在 prop-for-that.netlify.app/docsite；llms.txt 提供单文件参考，并随 npm 包发布。
• 📈 仓库信息：MIT © Adam Argyle；约 904 stars、19 forks、6 watchers、3 issues、1 PR、41 commits。

Better Design

Better Design 是一个应用设计系统，帮助开发者用 AI 更快交付，同时通过 UI/UX 规则保持品牌一致性与产品质量，避免做出千篇一律的应用。

• 🎨 让应用拥有可信赖、易使用的品牌体验。
• ⚡ 借助 AI 加速交付，同时不牺牲质量。
• 🧩 从设计系统开始，连接编辑器即可使用。
• 💻 运行一条命令，兼容你的 agent，并自动更新。
• 🎯 选择设计系统：描述项目、比较匹配、选定一个。
• 📏 按规则构建：加载 UI 样式规则和 UX 行为规则。
• ✅ 自动检查间距、无障碍和文案。
• 🚫 停止发布看起来千篇一律的应用。
• 🆓 免费、无需账号，代码和仓库都归你。
• 🛠️ 用 Better Design 实现无妥协的 vibe coding。

Awesome GPT-6 Astra

本目录是社区维护的 GPT-6 Astra 浏览器游戏与互动项目索引，收录 129 个可直接在浏览器试玩的作品，按类型组织，并与 OpenAI 无官方关联。

• 🎮 收录 129 款游戏/互动项目，涵盖三国领土策略、木制解谜、软体水果合并、程序化城市建造 2048、单键飞行、魔法地毯战斗、弹幕射击、岛屿电网塔防、荒野生存、水下捕鱼、寿司店经营、岛屿农场、卡丁车、海岸骑行、桌游 3D 化、3D 家居装饰、Orbital Garden 等。
• 🗂️ 分类包括动作街机、解谜与脑力、策略与模拟、RPG 与冒险、平台与竞速、实验与多人。
• 📅 目录更新于 2026-09-17；该日期代表目录维护记录，不代表所有游戏都重新试玩。
• 🆕 最新新增包括 9 月 16 日、15 日、12 日各 10 款，以及更早的 Barrelbound: The Lost Cargo 和 Tidehook，并提供多语言 README 条目。
• 🖱️ 点击标题即可在浏览器直接游玩；多数项目无需下载、安装或强制登录。
• 🧠 每个条目通常包含游戏与创作者、核心亮点、访问方式、真实截图、平台与要求、GPT-6 Astra 的贡献说明、源代码/技术等开发资源。
• 🛠️ 创作者可用浏览器游戏链接、截图和 GPT-6 Astra 使用说明提交项目；发现者也可推荐他人公开作品并注明创作者。
• 🔎 模型归属主要依据创作者或提交者公开说明；未确认信息会在条目中标出，不会把无依据声明当成已确认事实。
• 🤝 这是社区维护列表，与 OpenAI 无隶属；收录是探索邀请，不是基准测试或官方背书。
• 📜 原创整理文字和艺术以 CC0 1.0 公有领域贡献；链接的游戏、代码、图片、商标等第三方材料保留各自许可与权利。
• 🐞 可通过 issue 或 pull request 提交游戏、报告坏链、错误信息、归属问题或访问要求变化。

neat-annotations

neat-annotations 是一个纯 CSS 的手绘风格标注库，无需 JavaScript，只需一个小文件就能为网页元素添加箭头和手写标签。

• ✏️ 纯 CSS 实现，无 JavaScript，仅需一个小文件即可使用
• 📦 通过 CDN 引入样式表，或下载 neat-annotations.css 本地链接
• 🖋️ 可选加载手写字体 Shantell Sans，跳过则标签回退为 cursive 字体
• 🧭 支持指南针方向设置箭头指向（如 ann-n 表示北向）
• 🎨 提供五种颜色加动画彩虹色，以及暖灰色默认色
• 🌈 可通过 --ann-color 自定义任意 CSS 颜色
• 🔆 支持目标高亮，省略 data-note 可隐藏箭头和标签，仅作文字标记
• 📚 可嵌套标注，从不同方向指向同一目标
• 📏 长注释自动换行，可用 --ann-label-max-width 控制行宽
• 📄 采用 MIT 许可证，源码托管于 GitHub

fallow

Fallow 是面向 TypeScript 和 JavaScript 的代码库智能工具，提供免费的静态代码与样式分析，可检测未使用代码、重复、复杂度、架构漂移和设计系统一致性问题，并可选配运行时智能以了解生产环境中实际执行情况。

• 🚀 快速上手：无需安装，直接运行 npx fallow 即可，首次使用无需配置
• 🔍 静态分析能力：一次运行即可发现死代码、重复代码、复杂度和样式问题
• 🗑️ 删除冷代码：放心移除未使用的文件、导出和依赖
• ♻️ 减少重复：在重复逻辑扩散前将其找出
• 🎯 优先重构：利用复杂度和健康度分析聚焦清理工作
• 🧾 TypeScript 证据：确认具体符号使用、类契约、受影响文件和针对性测试
• ⏱️ 运行时证据：查看热路径、冷路径以及基于运行时的删除依据
• 💻 CLI 工作流：最佳起点，可在本地、CI 和代理循环中使用
• 🧩 VS Code 集成：编辑器内实时诊断、Code Lens 和一键修复
• 🤖 MCP 与代理：为 Claude Code、Cursor 等代理提供结构化工具调用
• 🧠 双层模型：静态分析回答“什么和什么相连”，运行时智能回答“实际运行了什么”，二者在 fallow health 中交汇
• 📚 常用页面：快速开始、配置、CI 集成、CLI 参考

GitHub - philipwalton/modern-web-types：适用于尚未加入 lib.dom 的新 Web 平台 API 的 TypeScript

本仓库 philipwalton/modern-web-types 旨在为已在至少一个稳定浏览器中可用、但尚未进入 TypeScript 官方内置类型定义的 Web 平台 API 提供 TypeScript 类型；它复用 TypeScript 官方生成管线，输出完整 lib，可作为官方 DOM/Worker 类型的替代或补充。

• 📦 项目提供 modern-web-types，包含五个环境 lib：DOM、WebWorker、ServiceWorker、SharedWorker、AudioWorklet。
• 🧩 类型由与 TypeScript 官方相同的生成器生成，质量与正确性一致，区别只在于收录 API 的数量。
• 🎯 TypeScript 官方 lib.dom.d.ts 等只收录已在两个及以上浏览器引擎发布的特性，因此单引擎已可用且广泛使用的 API 会缺少官方类型。
• ⚙️ 推荐安装方式：npm install --save-dev @typescript/lib-dom@npm:modern-web-types，用别名替换 TypeScript 解析的 DOM 库。
• 🧷 TypeScript 6+ 需在 tsconfig.json 中启用 libReplacement: true；TypeScript 4.5–5.x 默认支持库替换。
• 👷 对 Worker 等环境，需从 lib 移除对应库，并在 types 中引用入口，如 modern-web-types/webworker。
• 📚 入口映射包括：modern-web-types / modern-web-types/dom 替代 DOM；webworker 替代 WebWorker；serviceworker、sharedworker、audioworklet 对应相应 @types 包。
• ⚠️ 若项目原本未设置 types，添加后 TypeScript 将只包含列出的 @types 包，不再自动包含 node_modules 中所有 @types/*。
• 🔄 更新机制：每周一 workflow 重新固定生成器和条目注册表到最新提交，重新生成全部五个 lib、运行测试，并自动开 PR。
• 🛠️ 生成流程：固定并补丁生成器，使引擎阈值可配置；用同一数据快照构建两次，分别为两引擎 baseline 和一引擎 full；再用 TypeScript 编译器 API 做结构化 diff；最后按环境生成完整 lib。
• 📝 report.md 列出官方类型与一引擎类型之间的差距，冒烟测试由当前 delta 自动生成；API 一旦升级到两引擎，就会移出 delta 和测试。
• 🧪 开发命令：npm run update 执行 fetch-upstream → fetch-registry → build → diff → emit-lib → emit-test → emit-readme → report；npm test 对每个生成 lib 做类型检查并限制增量大小。
• 🧰 同时安装 TypeScript 6 与 7：diff/emit 脚本用 TS 6，因为 TS 7 将编译器 API 移到 typescript/unstable/*；测试则在两个版本下检查生成输出。
• 🚀 发布由 pkg/package.json 的 version 驱动：合并到 main 且版本变化会触发 publish workflow，发布 pkg/ 到 npm 并打 tag；版本不变则不发布。
• 🧾 相关项目：lib.dom.d.ts / @types/web 是官方类型；@types/dom-* 是手写单特性补丁，本项目用生成的完整 lib 覆盖同类空白。
• 📜 许可证为 Apache-2.0，生成输出源自 TypeScript-DOM-lib-generator 和 webref 的 Web IDL。

更新

Chrome 154 beta

Chrome 154 beta 于 2026 年 9 月 2 日发布，面向 Android、ChromeOS、Linux、macOS 和 Windows 平台，带来 CSS/UI、JavaScript、Web API、WebGPU 等多方面更新，并新增源试验功能。

• 🚀 发布信息：Chrome 154 于 2026 年 9 月 2 日进入 beta 频道，可从 Google.com 或 Google Play 下载。
• 🎯 scroll-marker-group 模式：新增 links（默认，导航列表行为）和 tabs（标签页行为）两种模式，分别改变焦点顺序与无障碍行为。
• ✍️ text-decoration-inset：控制下划线、上划线、删除线相对文字边缘的内缩或外延距离，支持 auto、长度和百分比值。
• ␣ text-decoration-skip-spaces：控制装饰线是否跳过空白字符，避免在空格下方绘制装饰。
• 🧵 CSSStyleValue 暴露至 Worker：将 CSS Typed OM 的构造函数扩展到 Worker 全局作用域，符合规范与其他浏览器引擎。
• 🔤 FontFace width 与 font-width：作为 stretch 和 font-stretch 的别名，对齐最新 CSS 字体加载与 CSS Fonts 4 规范。
• 👆 Light dismiss 改进：popover 和 dialog 改用 click 事件触发关闭，触摸滚动和右键不再误触发。
• 🖼️ 响应式 iframe：允许站点启用响应式尺寸，避免子文档出现滚动条。
• 🔁 Iterator includes()：TC39 提案，为迭代器添加 includes() 方法，类似 Array.prototype.includes()。
• 🔌 WebSocket 构造函数选项包：支持传入 WebSocketInit 字典，可指定 protocols，并为未来选项预留扩展点。
• 🔐 WebCrypto 算法更新：新增后量子与对称 AEAD 算法，包括 ML-KEM、ML-DSA、ChaCha20-Poly1305 和 X-Wing。
• 🌐 Background Fetch 安全强化：强制 CORS，并限制对本地/回环服务器的访问，需相应 LNA 权限。
• 🛑 Fetch 转发中止原因：将 AbortController 的 abort reason 暴露给 Response 对象及其 ReadableStream。
• 📄 HTML 插入与流式方法：新增位置插入方法（before、after、append、prepend、replaceWith）与流式方法（streamAppendHTML 等）。
• 💳 安全支付确认语言验证：locale 字段无匹配语言时返回 NotSupportedError，未设置则跳过验证。
• 🌍 WebSocket targetAddressSpace：可将公共主机名连接视为本地或回环目标，绕过混合内容限制。
• 🎮 WebGPU WGSL 片段深度：允许为 @builtin(frag_depth) 添加 less/greater 修饰符，启用 early-Z 优化。
• 🪟 Window Shape API：ChromeOS 上获白名单的隔离 Web 应用可定制非矩形窗口形状，需 unframed 模式与 window-management 权限。
• 🧪 新源试验：Private Verification Tokens（PVT）在常规浏览中签发、隐私浏览中兑换，减少验证码摩擦。

Playwright v1.63.0

Playwright v1.63.0 发布，重点带来测试锁、跨 frame 定位、可见元素定位、步骤参数与副标题、trace 的 Aria/屏幕快照等能力，并扩展 API、报告器、CLI 与浏览器支持；同时宣布部分实验组件包停止更新及 Ubuntu 20.04 不再支持。

• 🔒 测试锁：访问共享资源的测试可声明命名锁，跨文件、worker、项目互不并发，其他测试仍并行；支持多个锁及 test.describe() 组级锁。
• 🪟 跨 frame 定位：page.frameLocator() 和 frame.frameLocator() 不传选择器时可在任意子 frame 中搜索，匹配多个 frame 会报错。
• 👁️ 可见定位器：新增 locator.visible()，仅匹配可见元素，推荐替代 :visible CSS 伪类。
• 🧾 步骤增强：Playwright API 步骤会报告目标定位器和调用参数；test.step() 支持 subtitle 和 params，报告器可读取并在 trace viewer/HTML 报告中展示。
• 🖼️ Trace 快照：tracing.start() 和 testOptions.trace 的 snapshots 可选择捕获 dom、aria、screen；trace viewer 新增 Display Aria 模式，可并排查看并悬停高亮。
• 🔐 认证扩展：httpCredentials 支持凭据数组，按请求 origin 匹配，无 origin 的条目可匹配任意请求。
• 🗂️ 存储状态：新增 opfs 选项，将 origin private file system 纳入 storage state，便于持久化与恢复。
• 🔔 新事件：page.on('dialogclosed') 和 browserContext.on('dialogclosed') 在 JS 对话框被接受、关闭或用户关闭时触发。
• 🧩 Aria API：新增 locator.ariaSnapshotJSON() 和 page.ariaSnapshotJSON()，以 JSON 返回 Aria 快照，支持 mode、depth、boxes。
• 🌐 请求类型化：apiRequestContext.get() 等请求方法支持类型参数，使 response.json() 返回指定类型。
• 🧪 测试选项：新增独立的 testOptions.reducedMotion、testOptions.forcedColors、testOptions.contrast。
• ➕ CLI 增强：--add-reporter 可追加报告器；npx playwright install --no-remove 保留其他 Playwright 安装的浏览器；codegen --http-credentials 支持录制 HTTP 认证页面。
• 🏷️ 报告器标签：list、line、dot、github、junit 报告器新增 omitTags，可抑制自动附加到测试标题的标签。
• 📈 报告与时间线：内置 perfetto 报告器输出 Trace Event Format 文件，可在 Perfetto UI 或 chrome://tracing 中查看；HTML 报告显示测试步骤时长瀑布。
• ⚠️ 重要公告：实验性 @playwright/experimental-ct-react、ct-react17、ct-vue 不再更新，需迁移到 stories 模型；Ubuntu 20.04 不再支持；Linux arm64 改用 Chrome for Testing 构建的 Chromium。
• 🌍 浏览器版本：Chromium 153.0.8010.12、Mozilla Firefox 155.0、WebKit 26.6；同时测试兼容 Google Chrome 153 和 Microsoft Edge 153。

设计

更好的图标和标签对齐

本文讨论一个常见却容易被忽略的列表设计问题：带图标的列表项在单行文本时图标居中尚可，但文本换行后仍居中就显得别扭；作者分别针对图标作为 HTML 元素和伪元素背景图两种情况，给出可随图标尺寸、字体大小与容器宽度自适应的对齐方案。

• 🧩 问题：列表项包含图标和文本，文本多行时图标垂直居中会显得不协调。
• 🧱 方案一：图标是 HTML 元素时，通常用 Flexbox 排列图标与文本。
• ⚙️ 用 align-items: center 会让多行文本旁的图标仍居中；改为 start 又会因字体行高留白而不完美。
• 🔧 固定 translateY(3px) 只能临时修补，图标尺寸、字体大小或容器宽度变化后会失效。
• 📏 动态修复：使用 --offset: calc((1lh - var(--icon-size)) / 2)，再配合 transform: translateY(var(--offset))。
• 🔄 这个公式能随字体、图标和容器变化自动调整，偏移量甚至可能为负值。
• 🖼️ 方案二：图标用伪元素背景图时，需要处理背景缩放和 Flex 收缩问题。
• ✅ 关键 CSS：background-size: contain、flex-shrink: 0、aspect-ratio: 1、height: auto。
• 🧮 伪元素也使用相同的 lh 与 calc() 偏移公式来实现垂直对齐。
• 🛠️ 最终方案综合使用 Flexbox、aspect-ratio、lh 单位、calc() 和 height: auto。
• 📚 文末作者推广其交互式 CSS 布局课程《The Layout Maestro》。

其他

与人工智能协作的五个软件工程职位

软件工程师与 AI 的协作仍在演化，已从更好的代码补全发展到能自主分诊缺陷、定位根因并部署修复的代理。作者用五种职业角色描绘人机交互光谱——观察者、技术主管、架构师、工程经理、产品经理；选择取决于对 AI 的信任、任务风险和技术上下文，并需始终对结果负责。

• 👀 观察者（结对程序员）：实时观看并审查 AI 写代码，可追问和纠错；适合起步或信任不足时，但易审查疲劳，可交替做驱动者。
• 🧭 技术主管：写技术规范，让代理并行实现，最后审查代码并反馈；通过自动化格式化、lint、测试覆盖减少审查负担，提升生产力。
• 🏗️ 架构师：聚焦系统布局、组件接口、基础设施与框架，主要看架构和日志而非代码；风险是远离代码，出问题缺乏底层知识，需抽查代码与测试。
• 🏭 工程经理：搭建“软件工厂”，定义流程（如 PRD→技术规范→实施计划），给代理分配任务和验收标准；风险是流程失灵时重启循环可能较慢。
• 🎯 产品经理：专注用户体验、界面和用户旅程，不关心实现细节，只要产品按预期工作；挑战是技术故障时难以修复，可能依赖他人。
• ⚙️ 自动化是关键：格式化、lint、测试与覆盖率要求越高，越能降低审查疲劳，增强对 AI 生成代码合并的信心。
• ⚠️ 主要权衡：越亲力亲为越可控但吞吐受限；越放手越高效但离代码越远，故障定位与修复能力越弱。
• ✅ 结论：五种角色没有绝对优劣，应按信任度、风险和技术背景有意识地选择，并随信心与 AI 能力提升沿光谱移动。
• 🔄 你可以在探索陌生代码库时当观察者，在协调多工作流时当技术主管，在重视用户体验时当产品经理，但不应放弃对结果的责任。

构建企业内部智能体：我们做对的 5 件事，以及我会换个方式做的 5 件事

这是一篇关于在 Bold.org 构建内部 AI 代理的实践回顾，作者分享了从可观测性项目演变为全公司使用的代理过程中的经验教训，包括 5 个正确决策和 5 个需要改进的地方。

• 🚀 代理最初源于可观测性项目，为 ClickHouse 中的结构化后端事件提供只读访问，后逐步连接 Slack、Linear、PostHog 和 Grafana 等系统
• ⏱️ 实际效果显著：原本需要数小时、跨 3-4 人获取权限的调查，现在通常可在 0-1 小时内完成，支持团队可自主调查客户报告
• 🔒 安全边界设计简单而有效：通过 Google 企业域名登录验证，所有远程访问均为只读，从根本上避免模型判断写入是否安全的问题
• 📊 系统每月消耗数十亿 token，这既是成本管理的重要信号，也证明工具已真正融入日常工作而非仅作演示
• 👀 做对的第一件事：尽早让使用可见——在 Slack 和 Linear 等人们已工作的场所展示代理，每次公开交互都成为基于真实问题的产品演示
• 🔗 做对的第二件事：连接公司已有工具——通过小型 CLI 工具封装 OpenAPI 端点，窄权限、结构化结果、凭证不暴露给模型，整合多系统上下文提升推理质量
• 📈 做对的第三件事：追踪实际使用方式——关注工具调用、token 消耗、重复工作流等聚合指标，用于改进产品而非监控员工
• 🔄 做对的第四件事：闭合反馈循环——让反馈易于分享并快速调整代理，配合简明文档（可访问范围、良好请求示例、已知限制、反馈方式）
• 🏢 做对的第五件事：面向全公司设计——产品、支持、运营、市场、增长团队的使用往往比工程团队更有价值，工程师反而因已有成熟工具链而更难说服
• 🖥️ 会改进的第一点：更早设计本地访问——理想方案不是强迫所有人使用同一界面，而是允许经批准的本地代理框架安全使用公司工具，同时不暴露凭证、不绕过权限
• 🏗️ 会改进的第二点：少花时间追求完美架构——代理工具变化太快，应选择支持当前用例的简单架构，保持连接器小巧、边界清晰，避免耦合到单一模型或框架
• 🤝 会改进的第三点：让贡献路径更明确——目前改进过度依赖少数人，缺乏明确的技能编写、连接器添加、指令改进的安全贡献指南
• 🧪 会改进的第四点：减少评估和追踪基础设施——内部工具不需要前沿实验室级别的评估体系，几个代表性工作流和权限测试足够，评估系统应从真实问题中成长
• 🧠 会改进的第五点：不要假设他人有 AI 先验知识——各部门 AI 采用程度差异巨大，应把抽象能力转化为可见功能，展示具体报告、问题调查或重复工作流自动化，让人们立即尝试
• 💡 核心教训：最佳决策是在代理感觉完成前就让人看到它被使用；反复出现的教训是——对构建者显而易见的事，对其他人很少显而易见

良好的企业文化是提升生产力的最大秘诀，而不是人工智能。

良好文化才是最大生产力提升手段，AI 只是放大器；若文化、流程和架构不佳，AI 会加速错误。文章主张不要只追 AI 工具，而要先建立信任、自主、清晰和协作的组织环境。

• 🏆 核心观点：良好文化比任何 AI 工具都更能提升生产力；AI 有用，但前提是文化正确。
• ⚠️“有了 AI 就不需要那么多人”会降低心理安全感，让员工担心被替代，尤其高管这样说危害更大。
• 🏗️ 引用康威定律：组织沟通结构会体现在产品设计中；文化差，产品差，文化好，产品通常也好。
• 🩺 文化像健康，是一切的前提；没有健康，其他事很难做好。
• 📉 CEO 因竞争对手“10x 生产力”报道而 FOMO、指责团队，会损害信任；许多 10x 声明背后是销售 AI 产品/合作，应先看激励。
• 🚀 AI 放大已有文化：好文化 + 好架构让 AI 更有效；坏沟通/坏架构会被 AI 放大，团队只会更快走错方向。
• ✅ 好文化自检：责任清晰、可自主决策、能安全挑战领导、团队互信、优先级清晰、建设性分歧、奖励成果、理解目标、从失败学习而非找替罪羊。
• 📋 作者提供工程组织 checklist/audit，用于评估和建设优秀工程组织。
• 🗣️ 正确传达 AI 采用：把 AI 当成另一种工具，鼓励学习使用来帮助团队和业务，绝不要提“替代”或“不再重要”。
• 🔄 AI 采用只能自下而上，不能自上而下；变化太快，需要持续知识交流，强制会适得其反。
• 🧭 AI 采用不是工具问题，而是领导力问题；目标不是提高 AI 使用率，而是业务成功与整体成果。
• 👥 反对用 AI 替代工程师：AI 时代更应招聘更多工程师，前提是文化到位，更多人可指数级提升生产力。
• ⏱️ 上市时间（TTM）关键：最快响应市场、提供最佳体验的公司会胜出；限制生产力和人才是长期负债。
• ❓ 领导者该问的不是“如何让所有人用 AI”，而是“如何让优秀人才做出最佳工作，再用 AI 倍增他们”。