<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>桌宠 on heyaohua's Blog</title><link>https://blog.heyaohua.com/tags/%E6%A1%8C%E5%AE%A0/</link><description>Recent content in 桌宠 on heyaohua's Blog</description><image><title>heyaohua's Blog</title><url>https://blog.heyaohua.com/og-image.png</url><link>https://blog.heyaohua.com/og-image.png</link></image><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Thu, 22 Oct 2026 10:00:00 +0800</lastBuildDate><atom:link href="https://blog.heyaohua.com/tags/%E6%A1%8C%E5%AE%A0/index.xml" rel="self" type="application/rss+xml"/><item><title>ESP32 小团还能怎么玩</title><link>https://blog.heyaohua.com/posts/2026/10/esp32-codex-assistant-next-ideas/</link><pubDate>Thu, 22 Oct 2026 10:00:00 +0800</pubDate><guid>https://blog.heyaohua.com/posts/2026/10/esp32-codex-assistant-next-ideas/</guid><description>基于 ESP32 桌面助手小团，构思专注花园、Codex 任务小剧场、中断便签和桌宠成长等玩法。区分已实现能力与未来设想，讨论如何用现有屏幕和按键先验证体验，再逐步扩展。</description><content:encoded><![CDATA[<p>在<a href="/posts/2026/10/esp32-codex-personal-assistant/">小团的项目记录</a>里，我介绍了已经接入的 Codex 额度、聊天提醒、飞书 @ 计数，以及活动和喝水提醒。它有一块小屏幕、四个按键、声音和一些桌宠互动，已经具备继续探索的基础。</p>
<p>接下来还能怎么玩？一个值得尝试的方向，是让小团参与一天的工作节奏：陪着开始一段专注，在等待时表现工作状态，被打断后帮助找回上下文，收工时留下一点变化。</p>
<p>下面是一份迭代构思。专注花园、任务小剧场、中断便签等都是未来候选玩法，尚未实现，也不代表已经承诺的开发排期。</p>
<h2 id="专注花园让一段工作留下变化">专注花园让一段工作留下变化</h2>
<p>可以给小团加一个主动开启的专注回合。开始前，在 Mac 上写下这一轮要做的小事，例如“把文章开头改清楚”，再选择一段时间。屏幕上出现一颗种子，小团坐在旁边照看它。</p>
<p>时间推进，种子慢慢长出嫩芽；这一轮结束后，由人选择“完成了”“还要继续”或“中途停下”。花园记录的是这次选择，不能仅凭倒计时结束就认定任务完成。</p>
<p>例如，一个设想中的过程可以是：</p>
<blockquote>
<p>开始一轮 25 分钟专注 → 小团照看幼苗 → 普通提醒暂存 → 回合结束后查看汇总 → 确认这一轮的结果。</p>
</blockquote>
<p>25 分钟只是示例设置。阅读、写代码、整理照片需要的节奏可能不同，时长应能调整，也能随时暂停。中断后保留这次生长进度，回来再继续；离开几天，也不会让植物枯死或让小团惩罚性地掉状态。</p>
<p>现有久坐、喝水提醒已经有计时和暂停逻辑。专注花园新增的是人主动发起的一轮工作，以及结束时的反馈；两套时间规则如何配合，需要在试用中检查，避免专注结束、活动和喝水三种提示同时响起来。</p>
<p>第一版甚至只需要一颗种子、一个回合和三个结束选项。先看这种变化是否让人愿意使用，再决定要不要做一整座花园。</p>
<h2 id="codex-任务小剧场让等待有不同表情">Codex 任务小剧场让等待有不同表情</h2>
<p>当前小团的精神状态主要对应 Codex 剩余额度。后续可以增加一个独立的任务场景，让动作表达眼下正在发生什么。</p>
<table>
	<thead>
			<tr>
					<th>取得的状态</th>
					<th>候选画面</th>
					<th>需要保留的含义</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>确认一轮已经开始</td>
					<td>小团翻开本子或敲小键盘</td>
					<td>这一轮正在进行</td>
			</tr>
			<tr>
					<td>需要人回答问题</td>
					<td>小团举起小旗</td>
					<td>等待输入</td>
			</tr>
			<tr>
					<td>收到本轮结束状态</td>
					<td>小团放下本子，提示查看</td>
					<td>结果仍要打开确认</td>
			</tr>
			<tr>
					<td>连接失效或状态未知</td>
					<td>小团守着一封未送达的信</td>
					<td>当前无法确认进展</td>
			</tr>
	</tbody>
</table>
<p>动作可以有趣，进度含义要准确。如果拿不到可计算的完成比例，就采用循环动画，不画一个不断逼近 100% 的假进度条。运行中的状态也不能单凭“暂时没有新消息”来推断。</p>
<p>若以后由自建客户端通过 App Server 管理部分 Codex 会话，可以评估接入官方的轮次开始、结束和工具事件。<a href="https://learn.chatgpt.com/docs/app-server">OpenAI Docs 的 App Server 文档</a>列出了这些协议，结束事件还区分完成、中断和失败。文档描述的是客户端接入能力，不能直接推成已经能监听桌面应用里的全部聊天。</p>
<p>小团目前的聊天提醒仍是本地记录适配。这项构思需要先确定状态从哪里来、覆盖哪些会话，再设计动画。工具调用成功，也不能直接画成整项工作已经验收通过。</p>
<p>另一个小细节是区分两种“能量”：配额数字属于账号，专注状态属于人。可以让配额保留在一个小角标里，由当前模式决定主画面，避免小团趴下时让人分不清是额度不足，还是这一轮正在休息。</p>
<h2 id="中断便签帮助回来后接着做">中断便签帮助回来后接着做</h2>
<p>开发时常见的中断，并不都值得再开一个任务系统。一个很小的“暂停卡片”也许就有用：离开前留一句话，回来时看见下一步。</p>
<p>比如卡片上只保留“待确认：第二张图的说明”，或者“下一步：看失败用例的第一条输出”。内容在 Mac 上手动填写，小团只显示简短摘要。更长的记录继续留在电脑里。</p>
<p>这项玩法不必依靠自动截屏、记录完整聊天或猜测正在编辑的内容。先把“主动留下一句下一步”做顺，才知道是否需要更复杂的采集。</p>
<p>按键可以成为请求入口：查看当前卡片、切换下一张，或者请求在 Mac 上打开对应条目。但设备上已经有喂食、陪玩、确认和睡眠的按键职责，新增操作应放进单独模式，或从 Mac 菜单进入，避免随手按一下就改变工作状态。</p>
<p>当前按键确认提醒，只代表已经看过。要扩展成对电脑发指令，需要新增一条有回执的交互：设备发出请求，Mac 确认接收和执行，屏幕再显示结果。重连、重试或连续按键时，同一个请求也不能执行多次。</p>
<p>适合先尝试的是查看便签、暂缓提示这类可逆操作。需要阅读完整上下文的 Codex 提问与权限选择，继续回到电脑处理。</p>
<h2 id="小团的房间和每日收工仪式">小团的房间和每日收工仪式</h2>
<p>桌宠成长可以围绕日常互动展开。例如，完成一个自己确认的专注回合，给房间添一片叶子；收工时选一张心情贴纸；周末给小团换一个背景。</p>
<p>这些变化可以只保存在本机。没有连续签到排名，也不用按 token 消耗、工作时长或飞书消息数量发奖励。多调用模型、多收消息，并不等于这一天做得更好。</p>
<p>更轻的一版是“收工卡”：显示今天开始过几轮专注、留下几张便签，再问一句明天准备先做什么。数字只描述记录，不据此给人的效率打分。</p>
<p>还有几个适合以后试的小玩法：</p>
<ul>
<li><strong>主题房间</strong>：写作时坐在小书桌前，摄影整理时待在暗房背景里。先让人手动切换主题，验证画面和阅读体验。</li>
<li><strong>本地事件彩蛋</strong>：用户确认一个里程碑后，播放一次短动画。触发原因可以回看，同一事件只庆祝一次。</li>
<li><strong>结对开工</strong>：两个人自愿共享“专注中”“可以交流”这类状态，两只小团同时点亮一盏小灯。跨设备、跨网络需要额外通信方案，当前 Mac 与设备的 BLE 直连不会自然获得这种能力。</li>
</ul>
<p>共享状态尤其适合从少量、主动选择的信息开始，没必要把任务名称、聊天内容和全天活动都变成可见动态。</p>
<h2 id="几种玩法需要同一个提醒节奏">几种玩法需要同一个提醒节奏</h2>
<p>专注、休息和开会时，人能接受的打断方式不同。可以为小团设计一层统一的提醒调度，让模式决定何时出声、何时只亮一个标记，以及何时把几条消息合并成一次汇总。</p>
<p>例如在候选的专注模式里，普通事件先放进收件箱；需要本人回答的问题保留醒目的视觉提示，是否出声由用户设置。健康提示可以稍后处理，但不能被一个一直续期的专注回合无限压住。</p>
<p>汇总前还要检查事件是否仍然有效。当前飞书来源只能提供计数变化，过期的变化不能在专注结束后重新当作新消息播报；这层调度也无法弥补计数来源本身的漏报。</p>
<p>当前 Codex 与健康提示已经有部分优先关系，飞书走独立语音路径。要实现跨来源的调度，需要把这些规则真正整合起来；仅给界面增加一个“专注”图标还不够。</p>
<p>断线时的行为也应属于玩法的一部分：花园可以继续本地计时，电脑相关的状态改成未知；回连后再核对当前有效的请求和提醒。这样才能分清“这段时间很安静”和“同步已经中断”。</p>
<h2 id="先试一个小回合再扩展">先试一个小回合再扩展</h2>
<p>这几类构思可以分成三轮探索，每轮都留下明确的试用问题。</p>
<p><img alt="小团未来迭代的三轮探索：先试单轮专注花园与提醒调度，再试有可靠数据来源的任务小剧场和暂停便签，最后扩展房间主题及自愿共享状态。图中全部为未来构思，不是现有功能或交付排期。" loading="lazy" src="/images/posts/esp32-codex-assistant-next-ideas/iteration-map.svg"></p>
<p><em>自绘候选路线图，全部为未来构思，不是固件界面或已完成的功能。</em></p>
<table>
	<thead>
			<tr>
					<th>探索顺序</th>
					<th>最小范围</th>
					<th>试用时要回答的问题</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>第一轮</td>
					<td>一颗种子、一段专注、回合结束反馈；整合这一模式下的提醒</td>
					<td>暂停是否容易，是否漏掉需要回答的问题，是否值得每天主动打开</td>
			</tr>
			<tr>
					<td>第二轮</td>
					<td>一种可靠来源的任务场景、一张手动暂停便签</td>
					<td>未知状态是否诚实，回来后是否更容易接着做，请求是否有回执</td>
			</tr>
			<tr>
					<td>第三轮</td>
					<td>少量房间主题，再单独试自愿共享状态</td>
					<td>长期使用是否仍轻松，维护与连接成本是否值得</td>
			</tr>
	</tbody>
</table>
<p>先做专注花园，能同时检验几个核心问题：小屏幕是否值得看，实体操作是否顺手，提醒是否合时宜，以及一点点成长是否有陪伴感。任务小剧场和双设备互动，可以在这些基础成立后再展开。</p>
<p>每轮试用除了记录用过几次，也应记下误报、漏报、重复播报和觉得被打断的时刻。这样的记录比单纯增加动画数量，更能说明下一次该改哪里。</p>
]]></content:encoded></item></channel></rss>