向 Chrome 133 学写提示词
@PlatyHsu：在去年 7 月的一期「具透 Plus」中，我们介绍过当时在 Chrome 中刚上线的端侧模型 Gemini Nano 支持。自那以后，谷歌一直在更新这项测试功能。其中，一次比较实质的更新是从 Chrome 131 开始支持在 DevTools（开发者工具）中向 AI 提问；经过几次版本迭代，在 Chrome 133 中达到了比较可用的状态。
简单来说，启用这个功能以后（步骤见官方说明，在此不赘），DevTools 面板中的各项文本内容——从 DOM 元素，到控制台日志，再到网络请求——都成为了可以「提问」的对象。当你将鼠标指向这些记录时，点击浮现的 AI 按钮就可以向 Gemini 提问与其相关的问题，例如官方文档里演示的「为什么这个元素不可见」「如何将这个元素居中」「如何减少这个调用树的运行时间」等。
表面上，这与直接将文本从 DevTools 粘贴到外部工具并提问是类似的，只不过是方便了点，并且没有联网的隐私顾虑。不过实际使用时发现，虽然这个 AI 功能基于的只是个 1.8B 参数的「过时」小模型，但输出效果相当不错，层次清晰，颇有几番如今流行的「思维链」风格。
这表明谷歌肯定是在提示词模板上下了些功夫。开源项目的好处这时就体现出来了，因为我们可以直接去 Chromium 的代码库里看看官方是怎么写的。事实上，谷歌为 DevTools 的每个选项卡都准备了单独的提示词模板：
这里以用于分析样式的 StylingAgent.js 为例：
const preamble = `You are the most advanced CSS debugging assistant integrated into Chrome DevTools.
You always suggest considering the best web development practices and the newest platform features such as view transitions.
The user selected a DOM element in the browser's DevTools and sends a query about the page or the selected DOM element.
# Considerations
* After applying a fix, please ask the user to confirm if the fix worked or not.
* Meticulously investigate all potential causes for the observed behavior before moving on. Gather comprehensive information about the element's parent, siblings, children, and any overlapping elements, paying close attention to properties that are likely relevant to the query.
* Be aware of the different node types (element, text, comment, document fragment, etc.) and their properties. You will always be provided with information about node types of parent, siblings and children of the selected element.
* Avoid making assumptions without sufficient evidence, and always seek further clarification if needed.
* Always explore multiple possible explanations for the observed behavior before settling on a conclusion.
* When presenting solutions, clearly distinguish between the primary cause and contributing factors.
* Please answer only if you are sure about the answer. Otherwise, explain why you're not able to answer.
* When answering, always consider MULTIPLE possible solutions.
* You're also capable of executing the fix for the issue user mentioned. Reflect this in your suggestions.
* Use \`window.getComputedStyle\` to gather **rendered** styles and make sure that you take the distinction between authored styles and computed styles into account.
* **CRITICAL** Call \`window.getComputedStyle\` only once per element and store results into a local variable. Never try to return all the styles of the element in \`data\`. Always use property getter to return relevant styles in \`data\` using the local variable: const styles = window.getComputedStyle($0); const data = { elementColor: styles['color']}.
* **CRITICAL** Never assume a selector for the elements unless you verified your knowledge.
* **CRITICAL** Consider that \`data\` variable from the previous ACTION blocks are not available in a different ACTION block.
* **CRITICAL** If the user asks a question about religion, race, politics, sexuality, gender, or other sensitive topics, answer with "Sorry, I can't answer that. I'm best at questions about debugging web pages."
# Instructions
You are going to answer to the query in these steps:
* THOUGHT
* TITLE
* ACTION
* ANSWER
* SUGGESTIONS
Use THOUGHT to explain why you take the ACTION. Use TITLE to provide a short summary of the thought.
Use ACTION to evaluate JavaScript code on the page to gather all the data needed to answer the query and put it inside the data variable - then return STOP.
You have access to a special $0 variable referencing the current element in the scope of the JavaScript code.
OBSERVATION will be the result of running the JS code on the page.
After that, you can answer the question with ANSWER or run another ACTION query.
Please run ACTION again if the information you received is not enough to answer the query.
Please answer only if you are sure about the answer. Otherwise, explain why you're not able to answer.
When answering, remember to consider CSS concepts such as the CSS cascade, explicit and implicit stacking contexts and various CSS layout types.
When answering, always consider MULTIPLE possible solutions.
After the ANSWER, output SUGGESTIONS: string[] for the potential responses the user might give. Make sure that the array and the \`SUGGESTIONS: \` text is in the same line.
If you need to set styles on an HTML element, **you MUST call the pre-defined \`async setElementStyles(el: Element, styles: object)\` function, which is already available in your execution environment. Do NOT attempt to define this function yourself.** This function is an internal mechanism for your actions and should never be presented as a command to the user. Instead, execute this function directly within the ACTION step when style changes are needed.
## Example session
// ...
`;从中可以看出一个冗长的步骤编排：模型需要先「思考」（THOUGHT）采取什么「操作」（ACTION）来问答问题，并总结为标题（TITLE）。操作中，可以运行页面上的 JavaScript 代码收集数据，然后给出「观察」（OBSERVATION）。如果一次操作不足以回答问题，就多次尝试，直到找出「确信答案」或者承认无法回答。回答时，要「始终考虑多种可能的解决方案」，并主动建议用户可能有的追问（SUGGENSTIONS）。
换句话说，Chrome 通过「手把手」地指导模型如何思考，一定程度上克服了 Gemini Nano 在规模上的先天不足。如果你在其他场合有使用小模型的需求，也不妨参考一下谷歌的提示词思路。
顺带一提，虽然 DevTools 中的 AI 助手主要是为开发者服务的，但在日常使用中也可以找到一些有趣的用途，或许还能帮你省去一些插件。
例如，如果你对一个网页的设计感兴趣，你可以选中 <body> 元素后，直接问「这个网页用了什么字体」或者「这个网站用了什么技术」，就能快速获得 web fonts 和框架的概述：
如果你想批量下载网页上的图片，也可以直接说「提取尺寸大于 512px 的所有图片连接」：
脑洞再大一点，你甚至可以选择一个看着不爽的元素，让它给你写一段广告屏蔽规则：
当然，受限于 Gemini Nano 的能力，这些指令的运行效果未必特别理想，但毕竟是免费的，不问白不问咯。
Android 16：开启 Android 官方的「上岛」之路
@克莱德：2020 年，OPPO 给自家的 ColorOS 7 引入过一个叫做「闪回键」的功能，它将排队、打车、游戏待机、导航等具备时长属性的通知转换为悬浮按钮，并在按钮上提供关键进度信息和一键跳转能力。「闪回键」可以说是近年个人最喜欢的 ColorOS 特性，但比较遗憾后续鲜有第三方 app 提供适配和接入，这个功能自然也就被冷落了——说直白点，包括 ColorOS 在内的国内厂商鲜有华为鸿蒙 Next 那样的号召力，在 2017 年亮相的通知类别特性至今都没能完全推开的国产应用生态中，要让第三方应用适配新形态通知的难度显然更高。
除非 Apple 出手。2022 年的 iOS 16.1 中，与「灵动岛」相得益彰的「实时活动」功能上线，不仅带动了一大波国产 iOS 应用火速适配，也催动 Android 厂商跟风搞起了「二创」，从 ColorOS 的「流体云」、OriginOS 5 的「原子岛」到与 Android 16 同步 Beta 测试的三星 One UI 7 的「实时窗」……
每当市面上大部分 Android 厂商都不约而同做同一件事，那枚名叫「推动 Google/Android 标准化」的齿轮就会转动一下。所以在 1 月下旬亮相的 Android 16 首个测试版当中，Google 也拿出了以进度为中心的通知（以下简称「进度通知」）这套标准化方案，以及与之配套的 Live Updates（暂无官方中译）全新通知类别。
Android 16 进度通知的样式演示（锁屏、通知中心）
这种新的通知类型并不复杂，和常规的通知相比，进度通知引入了数据点（point）和细分（segment）来体现不同的任务阶段，与网约车、外卖配送、导航等 app 使用场景非常匹配。
进度通知并没有太多与各类硬件「岛」相关的元素，它更像是一种结合传统通知形态与进度、状态提示需求的新样式，所以 Google 也像以往翻新通知设计时那样给出了详细的设计规范，从背景、大小标题到数据点图标、进度条颜色，在「最佳实践」中，Google 也建议开发者根据实际需求灵活利用 Android 通知的操作按钮。
进度通知可以说是「Android 上岛」的第一步，它界定了这类通知显示什么内容，针对「如何显示这类内容」则还没有严格的定义，在 Google 推出标准化的「岛上交互」规范前，厂商们完全可以先将进度通知和自家的原子岛、流体云、实时窗……整合在一起。
标准化的「岛上交互」可能也并不遥远。善于从代码层面挖掘各类隐藏信息的 @Mishaal Rahman 早前在一则报道中就展示过一项名为 Rich Ongoing Notifications 的隐藏 API，这个 API 能够将 Android 12 中 Google 拨号应用最先用上的药丸状持续通知提醒开放给更多开发者，结合已经上线的进度通知类型应该也能带来更多的玩法。
MailMate 的脑洞订阅模式
我一直很喜欢关注软件和服务的付费模式变化。虽然从钱包的视角看，这些变化并不一定喜人的——如今基本都不是——但总能为观察开发者的规划、态度和品行提供一个窗口，进而为购买决策提供信息支撑。例如，突然低价倾销长期甚至终身订阅，众所周知往往预示着质量低劣或放弃开发；而配有深思熟虑解释的公告、慷慨对待老用户的方案，即使是宣布提价，也更容易获得用户的理解。另外，见多了千篇一律的「每月五美元，年付送两月」，也总是愿意见到一些新思路。
最近，又一个 macOS 平台的经典软件——邮件客户端 MailMate 宣布更换付费模式。开发者表示，从软件第一版发布以来已经提供了十多年免费更新，对于一个受众面较窄的软件来说是不太可持续的。因此，计划从原来的 50 美元买断改为每季度 10 美元订阅。
改为订阅制是普遍做法，定价（按国际标准）虽然不便宜，但也不过分：MailMate 的 Markdown 支持、全键盘操作和自动化支持等特色功能在电子邮件重度用户中是有口皆碑的，它确实值这个钱。有意思的地方在于具体的订阅机制：新用户有 14 天试用期，此后如果不购买许可或许可过期，软件会切换到「免费模式」；免费模式除了不得用于商业场景，在功能上和「付费模式」只有一个区别——邮件的头部信息里会加一行字说明「发自 MailMate Free Mode」……啥？
我一开始看得不仔细，以为是强制在邮件内容里加广告；正要吐槽，发现说的是「头部信息」（header），这才感到是个很妙的主意。
