大模型会聊天，但不会干活。真正让 AI Agent 能接住复杂任务的，不是模型有多聪明，而是外面裹着的那层"缰绳"——Harness。

AI 写前端，最常见的问题往往不是功能跑不起来，而是页面“看起来不像你想要的东西”：颜色不对、字体随意、间距没有节奏、组件圆角到处变化。你在一次对话里解释过设计规范，下一次对话却还要从头解释；截图、Figma 链接和口头描述也很难成为稳定的项目上下文。

Google Labs 的 DESIGN.md 试图解决的就是这个问题：用一个放在代码仓库里的纯文本文件，把设计系统和设计意图交给 AI coding agent 反复读取。

中文多模态里，Chinese-CLIP 一直是一个很实用但也很容易被“半懂不懂地使用”的模型。很多人知道它能做图文检索、零样本分类，也知道它有 ViT-B/16、ViT-L/14、ViT-H/14 这些规模，但一旦往工程里落，问题马上就会变具体：

• 我到底应该用 cn_clip 官方 API，还是直接走 Hugging Face 的 ChineseCLIPModel？
• 训练是不是只能全量训？有没有更省资源的办法？
• 它官方支持到什么程度？哪些压缩/量化路线是 Chinese-CLIP 原生支持，哪些只是通用工具链“理论可套”？

我把公开资料重新过了一遍，尽量只看原作者和主流官方工具链的第一手文档。下面这篇，等价于一个截至 2026 年 7 月 21 日 的“Chinese-CLIP 可落地方法地图”。

2026 年，开源 TTS 领域迎来一个重要节点：阿里通义千问团队正式开源了 Qwen3-TTS 系列模型。这是目前开源社区中功能最全面的 TTS 方案之一，支持语音克隆、语音设计、指令控制情绪语速，并且模型完全开放下载。

我花了一些时间把 Qwen3-TTS 的公开资料、官方文档、定价信息和竞品对比整理了一遍，尽量把"能跑起来"和"能落地到产品里"这两件事分清楚。

这两年桌面应用开发一直在两条路之间摇摆。

一条路是 Electron，生态成熟、前端团队上手快，但大家对它的抱怨也很稳定：包体偏大、内存占用高、冷启动不够利落。另一条路是 Tauri，它把 Chromium 换成系统 WebView，再加上 Rust 后端，明显把体积和资源占用压下来了，但 WebView 本身依然会带来平台差异和能力边界。

现在 Vercel Labs 推出的 Native SDK，想走的是第三条路：不带浏览器，不依赖 WebView，也不靠 JavaScript 运行时，而是直接用自己的原生渲染引擎来画界面。

如果只看第一眼数据，这条路线确实很猛。

• 示例应用体积大约在 3.4 MB 到 5.7 MB
• 常见启动时间在 100 ms 左右，官方展示里温启动约 71 ms 到 131 ms
• 目标覆盖 macOS、Windows、Linux，同时也在尝试 iOS 和 Android

这组数据足够吸引人，但真正值得关心的不是“它是不是更快更小”，而是：它到底解决了什么问题，又会把新的成本转移到哪里。

过去一年，很多团队都在研究怎么把大模型变成 Agent：给它工具，给它权限，给它任务，让它能自己跑起来。

于是大家开始关注 Prompt、Context、Tool Use、Workflow、Harness。可是当 Agent 真的开始进入开发、运维、研究、文档和业务流程以后，一个更底层的问题浮出来了：Agent 到底工作在一个什么环境里？

这就是 Environment Engineering 想解决的问题。

如果说 Harness 解决的是“怎么管住 Agent”，那么 Environment 解决的是“Agent 面对的世界是否可靠”。前者更像运行时控制系统，后者更像训练场、考场和工作制度。

autoSSL 这种桌面工具，如果只有“本地能跑”，其实离真正可交付还差一步。尤其是面向 Windows 用户时，团队里不可能永远靠某一台开发机手工打包，再靠聊天工具传安装包。只要产品准备进入更稳定的迭代阶段，GitHub 上可重复执行的 Windows 打包链路就会变成基础设施，而不是可选项。

这次我给 autoSSL 做的事情并不复杂，但很实用：把原来停留在本地 electron-builder 的打包方式，推进成了两条 GitHub Actions 工作流。一条负责在 windows-latest 上生成可下载的 Windows 构建产物，另一条负责在打 tag 或手动触发时生成 draft release。过程中还顺手处理了一个很典型的工程问题：项目里依赖了本地 file: 包，开发机没问题，到了 GitHub runner 却会直接装不上。

后续更新： 这套链路已经在 GitHub 上真实跑通，macOS 和 Windows 安装包都已产出，并且已经发布为公开 release。 为了避免后续每次发版都手改文章入口，这里直接放最新版本下载页： https://github.com/zzhi191/autossl-downloads/releases/latest

做 LLM 应用的人大概都遇到过同一个头疼问题：用户丢过来一个 PDF、一个 Word、一张截图、一段录音，然后问你"能不能帮我总结一下？"

每种格式都要找对应的解析库，PDF 用 PyMuPDF、Word 用 python-docx、Excel 用 openpyxl、图片还得上 Tesseract OCR……写完一堆胶水代码，发现提取出来的文本结构全丢了——标题变普通段落、表格变乱码、链接直接蒸发。

微软开源的 MarkItDown 就是来解决这个问题的。

上篇写了 MarkItDown，微软出的通用文件转Markdown 工具。今天这篇聊 MinerU——一个更专注、更狠的文档解析引擎。

如果说 MarkItDown 是"瑞士军刀"，什么格式都能转；那 MinerU 就是"手术刀"，专门对付最难啃的 PDF——扫描件、多栏排版、跨页表格、数学公式、手写体，这些让普通解析器哭出来的场景。