转载声明：本文翻译转载自 mathspp.com 的文章 frozendict built-in，作者 Rodrigo Girão Serrão，原文发布于 2026 年 10 月 14 日。本文为翻译转载，版权归原作者所有。
Python 3.15 引入了一种新的内置数据类型：frozendict。frozendict 是一个不可变字典，可以用与它同名的内置函数来创建：
1 | version_info = frozendict( |
花括号 {} 的字典字面量语法创建的是普通可变字典，所以创建冻结字典时必须始终使用内置的 frozendict。
在这篇文章里，你将了解这种不可变字典的特性——比如它是可哈希的——以及如何在类型标注语境中把它与 dict 配合使用。
转载声明：本文翻译转载自 mathspp.com 的文章 sentinel built-in，作者 Rodrigo Girão Serrão，原文发布于 2026 年 10 月 13 日。本文为翻译转载，版权归原作者所有。
Python 3.15 引入了新的 sentinel 内置函数。sentinel 内置函数可用于创建占位值：
1 | NOTHING = sentinel("NOTHING") |
由 sentinel 创建的占位值，是在 None 无法胜任的场合提供默认参数或返回值的更地道的方式。
【由DeepSeek辅助编写】
Python 3.15 在 2026 年 10 月 9 日发布（release notes）。PEP 810 带来的显式惰性导入大概是这一版里性价比最高的改动：在 import 前面加一个 lazy 关键字，模块就不在语句执行时加载，而是等你第一次真正读到这个名字才加载。对启动时间敏感的 CLI 工具、serverless 冷启动这类场景，这可能是一行关键字换来的一次优化。
WorkBuddy 资料库提供了CSV数据管理和HTML页面托管能力，可以视作为一个轻量级的CMS系统。我之前在WorkBuddy资料库内发布了一个用于展示优秀的AI生图案例和提示词的页面生图画廊
我用 WorkBuddy 的多智能体团队模式搭了一张德州扑克桌：一个荷官引擎加五个 AI 玩家，每人一本人设策略，打了五局。赛果看起来很精彩——松凶型玩家 P2 五局累计 +1260，跟注站 P5 第三局就被打破产（-1000）。
一个诱人的结论几乎是现成的：“松凶碾压跟注站，激进策略赢了。”
这个结论是错的——或者说，是不负责任的。五局牌里两次是所有人弃牌的 walk 局（底池合计只有 60），真正打完的完整牌局只有三手，摊牌更是只发生了两次。为了搞清楚”五局牌到底能说明什么”，我把五个人设翻译成了启发式参数，用同一个引擎跑了 1000 局蒙特卡洛（v1/v2 策略各 500 局）。数据揭示了三件比”谁赢谁输”有意思得多的事。
最近用 topcoat 0.6 写了一个本地单机便笺应用 Stickies：增删改查、置顶、标签、全文搜索、回收站（30 天自动清理），外加多窗口 WebSocket 实时同步。项目本身还在实验期，但开发过程几乎全程在跟框架的”年轻”搏斗，积累的经验值得单独成文。
topcoat 是 tokio-rs 出品的一个很年轻的 Rust 全栈框架：服务端渲染 + $(...) 运行时表达式做客户端响应式，#[page]/#[route]/#[shard]/#[procedure]/#[component] 五个宏驱动。文档稀少、API 不稳定，很多行为要靠读源码和试错。本文按技术层组织，每个坑给出”现象 → 根因 → 修法 → 通用教训”。
topcoat 是 tokio 生态（tokio-rs 组织）出品的 Rust 全栈 Web 框架，官方 README 给自己的定位是 “The full full-stack framework for Rust”，并自称 modular、batteries-included（模块化、电池全含），核心目标是最小化样板代码、最大化生产力（simplicity and productivity）。生态位置上的对标物很直接——正如 Next.js 之于 React，topcoat 之于 Rust/tokio：服务端渲染、客户端响应式、服务端过程、组件库、模块化路由一应俱全，而且整个链路没有 Node 参与。
先说清楚这个框架的模型，后面看坑才有上下文：
$(...) 表达式是普通 Rust 代码：服务端求值用于初始渲染，同时被翻译成 JavaScript 塞进 HTML，浏览器端即时重跑、建立响应式绑定。无 wasm bundle、无客户端构建步骤。信号（signal）变化时，绑定的 DOM 自动更新，或触发服务端重新渲染某个区块。src/ 模块结构自动推断路由树（类似 Next.js 的 app router 文件约定），无需构建步骤；也支持 #[page]/#[route] 手动声明。#[page] 定义页面路由；#[route] 定义子路由；#[shard] 定义”服务端重查的视图块”——参数一变，浏览器请求服务端重渲染整块；#[procedure] 定义客户端可调用的服务端过程（对标 Next.js 的 server actions / API route）；#[component] 复用 UI 片段。topcoat ui 命令把组件源码拷贝进项目、可自由改——“batteries-included”的直接体现。【本文由 AI 辅助完成】
上篇《Everyday CLI开发经验谈》记录到 v0.10–v0.11 时代。此后两周，Everyday CLI 从 v0.13.0 迭代到 v0.18.0，跨了 11 个版本点。本文按「版本时间线 + 主题深挖」双线梳理这段演进，最后单独成章，分享这期间最有代表性的一类经验——在 WorkBuddy 沙盒不稳定性下的工程实践。
【本文由 AI 辅助完成】
一次完整的「看图建模 → 视觉验证 → 云端发布」体验记录：把一张东方明珠电视塔的照片，变成可交互的体素 3D 模型。
最近体验了 DeepSeek-V4-Flash-Vision-Exp，一个有视觉能力的模型。我给它出了一个有点意思的端到端任务：只看一张东方明珠电视塔的照片，用 three.js 做一个体素（voxel）风格的 3D 模型，再用 Playwright 截图做视觉验证，最后部署到 Cloudflare Pages，并加上可交互的相机。 这篇文章记录这个过程里模型的表现、我的观察，以及一些值得注意的细节。
我最近发现我在Workbuddy配置的“晨间提醒”定时任务执行时长有点久，经脚本化改造后得到了显著的改进。
“晨间提醒”定时任务的大致工作内容如下：
everyday timeline sync命令同步操作后，通过everyday cli工具获取24小时内的邮件、当天的日历事件和待办任务。github cli工具获取前一天的Github动态。AI Agent执行“晨间提醒”定时任务的效率瓶颈主要集中以下两个方面：
获取工具用法：AI Agent在每次执行任务时，往往都会重新通过everyday --help和gh --help命令获取命令行工具的用法说明。
类似地，AI Agent也会重新加载所需的Agent Skill并理解其意图和使用方式，做了很多重复的工作。
串行执行命令：虽然各个信息源的获取是相互独立的，但AI Agent还是会按照顺序一个接一个地执行这些命令，导致整体执行时间较长。某些Agent支持运行并行子Agent执行多个子任务，但由语言模型进行任务的分派和结果汇总的效率也不高，并且会消耗大量的Token。
考虑到我配置的“晨间提醒”定时任务的工作内容是相对稳定的，并且其涉及到的信息本质都可以执行命令行工具来获取，我让Workbuddy编写了一个Python脚本用于并行执行这些命令行工具获取原始信息，然后将结果汇总后再进行处理和生成报告，从而有效提升了执行效率并节省了大量Token。
我近期开发了一款Rust命令行工具Everyday CLI，
配合自带的Skill，
可为 AI Agent 提供便捷的邮箱、日历、RSS 订阅、笔记、待办事项及书签管理能力。。
我几乎全程在腾讯推出的 WorkBuddy 上进行开发，期间不断切换模型与工作流，推动项目逐步迭代至较完善版本，也积累了不少实践经验。