企业官网建设流程全解析

Anarlog 1.3.5 版本解读：会议摘要兜底保障、笔记即时操作与多设备同步状态追踪

【免费下载链接】anarlogOpen source Granola AI Alternative项目地址: https://gitcode.com/GitHub_Trending/hy/anarlog

Anarlog 1.3.5 是围绕"可靠性"与"即时反馈"两个主题发布的版本：它保证会议结束后必然生成自动摘要（即使实时转写中途卡顿也会从录音重建）、让笔记删除/撤销/日历事件忽略等操作获得瞬时响应，并新增了锚定在引用文本上的共享笔记评论与一眼可见的同步状态指示器。读完本文，你将完整掌握 1.3.5 在会议、笔记、聊天、共享与同步四个模块的改进细节，以及这些能力背后的实现逻辑与仓库中的对应源码位置。

版本概览

本更新说明文件位于 packages/changelog/content/1.3.5.md，发布日期为 2026-07-22。仓库将版本更新说明以 Markdown 文档形式存放在packages/changelog/content/目录下（每个版本一个文件），并通过 packages/changelog/src/process.ts 解析 frontmatter（提取date与summary字段），再由 packages/changelog/src/renderer.tsx 与 packages/changelog/src/components.tsx 渲染为应用内可读的界面组件。

1.3.5 的官方摘要将其定位为："guarantees post-meeting summaries, makes note deletion and undo instant, and adds anchored shared-note comments plus a sync status menu"（保证会后摘要生成、让笔记删除与撤销即时生效，并新增锚定的共享笔记评论与同步状态菜单）。下面按原文档的四个板块逐一展开。

会议与摘要：让"会后必有摘要"成为可靠承诺

本节对应原文档## Meetings & summaries的全部改进点，核心目标是消除"会议结束了却没有摘要"这一最令用户沮丧的体验。

转写中断时，从录音重建转写并强制生成摘要

Always generate the automatic summary when listening stops — if live transcription stalls mid-meeting, the transcript is rebuilt from the recording

当监听（listening）结束时，系统总是尝试生成自动摘要；如果实时转写（live transcription）在会议中途停滞，则会从录音（recording）重建转写文本，再基于重建结果生成摘要。这意味着摘要生成不再依赖实时转写链路是否全程健康，录音成为兜底数据源。

从仓库结构看，该能力与crates/下的转写与音频链路密切相关：crates/transcribe-core、crates/transcribe-proxy、crates/owhisper-client、crates/whisper-local等 crate 共同构成了实时转写与离线重建转写的能力栈，而crates/audio-sync、crates/audio-snapshot等负责音频数据的持久化与同步。可以推断 1.3.5 在"监听停止"这一时机上增加了转写完整性检查与录音重建的回退路径。

摘要长度随会议时长缩放

Scale summary length with the length of the meeting

自动摘要不再是固定长度的输出，而是根据会议时长动态缩放。短会得到精炼摘要，长会把关键信息容纳进更长的摘要中，避免长会信息被压缩丢失或短会摘要显得空洞。这与 Anarlog 摘要配置体系（见 docs/customize-summaries.mdx）的定制方向一致——用户在原有自定义摘要规则的基础上，现在还能获得与时长匹配的默认输出规模。

实时转写部分丢失时保留录音

Keep the recording whenever part of the live transcript could not be saved, so nothing is lost

只要实时转写中存在未能保存的部分，录音就会保留在本机，确保"任何内容都不丢失"。这与上一节形成配套：录音既是重建转写的兜底，也是用户事后手动回听、人工补全的原始素材。

静音状态下也能检测转写停滞

Detect stalls even while your mic is muted and speaker audio keeps playing

转写停滞检测不再依赖麦克风输入。当用户静音、扬声器音频持续播放时，系统依然能感知实时转写是否推进异常。这从实现上说明停滞检测基于系统级音频流状态（而非单纯的麦克风音量），与仓库中的crates/audio-device、crates/detect（会议检测）等音频采集与状态监测模块直接相关。

新增"录音保留时长"设置

Choose how long recorded meeting audio is kept on this device from the new Meetings settings section

1.3.5 在应用的 Meetings 设置区新增了录音保留时长选项，用户可以自行决定已录制的会议音频在本机保留多久。这既是对隐私/存储空间的控制，也是上述"保留录音"策略的可配置化：默认保留策略保证不丢数据，而用户可按需设置清理周期。对应设置界面位于 apps/desktop/src/settings 目录下。

笔记与时间线：删除、撤销与忽略全部即时生效

本节对应原文档## Notes & timeline。

删除、撤销删除与忽略日历事件获得即时反馈

Delete notes, undo deletions, and ignore calendar events with instant feedback

删除笔记、撤销删除、忽略日历事件这三类操作全部改为即时反馈：界面先响应，后台再完成持久化。同时：

Date edits, participant chips, upgrades, and integration buttons respond immediately and can no longer double-trigger

日期编辑、参与者标签（participant chips）、升级入口与集成按钮同样即时响应，并修复了"重复触发"（double-trigger）问题。这说明 1.3.5 对笔记时间线交互层做了系统性的防抖/幂等处理，避免快速点击造成多次副作用。

完全离线删除，共享链接后台撤销

Delete notes fully offline — shared notes' links are revoked in the background, even if you quit right after deleting

删除笔记可以在完全离线状态下完成；对于已共享的笔记，其共享链接会在后台撤销，即使删除后立刻退出应用，撤销动作也会继续完成。这依赖仓库中的同步与撤销机制——crates/db-sync、crates/api-sync与crates/cloudsync提供了本地优先（local-first）的数据同步能力，共享撤销请求被持久化后可在联网时补发。

聊天：消息即时上屏与失败回合恢复

Show sent chat messages instantly instead of after they save, and recover turns whose save failed

发送的聊天消息改为即时显示（先上屏、后保存），不再等待保存成功才渲染；同时，对于保存失败的回合（turn），系统支持恢复。该能力与apps/mobile/src、apps/desktop/src中的聊天界面以及packages/agent-core的会话管理逻辑相关，属于典型的"乐观更新 + 失败补偿"模式：UI 层乐观渲染用户输入，数据层在失败时保留可重试状态。

共享与同步：锚定评论与多设备同步状态

本节对应原文档## Sharing & sync，是 1.3.5 的另一大亮点。

共享笔记评论锚定到引用文本

See comments on shared notes anchored to the quoted text across the app

共享笔记上的评论现在可以锚定（anchor）到被引用的文本片段上，并在整个应用中一致地展示。也就是说，评论不再漂浮在笔记末尾，而是与评论者引用的原文段落绑定，读者在阅读到对应段落时即可看到相关讨论。

新增同步状态指示器与菜单（最多 5 台设备）

Track sync at a glance with the new sync status indicator and menu, supporting up to 5 devices

新增的同步状态指示器让用户"一眼"掌握当前同步状态，并配套提供状态菜单，支持最多 5 台设备同时参与同步。

仓库源码为这一能力提供了直接的实现证据。在 apps/desktop/src/session-sharing/sync-state.ts 中，定义了SessionShareSyncStatus类型，取值仅为"clean" | "conflict"：

• clean：共享会话的同步状态健康、无冲突；
• conflict：检测到同步冲突。

其实现通过useLiveQuery查询session_share_sync_state表，按viewer_user_id + share_id + session_id组合定位当前查看者的同步状态行，并对非法状态值抛错（"Invalid shared-note sync status"），保证状态机严格收敛到这两个合法值。状态菜单与展示逻辑位于 apps/desktop/src/session-sharing/sync.tsx，相关状态计算与测试见 apps/desktop/src/session-sharing/sync-state.test.tsx 与 apps/desktop/src/session-sharing/index.test.tsx。此外 apps/desktop/src/settings/sync/index.tsx 提供同步设置界面，"最多 5 台设备"即在该同步体系下的设备配额约束。

更新说明的工程化组织方式

如果你希望在自己的应用中复用 Anarlog 这种"按版本维护更新说明"的工程模式，可以参考本仓库的做法：

• 每个版本一个 Markdown 文件，命名如1.3.5.md，置于packages/changelog/content/；
• 文件头部使用 frontmatter 记录date与summary，正文按功能板块（Meetings、Notes、Chat、Sharing 等）组织要点；
• 渲染侧由 packages/changelog/src/process.ts 负责解析 frontmatter 与图片 URL 修正，由 packages/changelog/src/renderer.tsx + packages/changelog/src/components.tsx 以定制组件渲染（标题、列表、代码、banner 等均有独立样式与暗色模式适配），并支持通过components属性覆盖默认组件。

这种"内容与渲染分离"的结构，让更新说明既能被应用内界面优雅展示，也能被搜索引擎与文档工具直接检索，是值得借鉴的实践。

小结

Anarlog 1.3.5 的核心价值可以概括为三条主线：

1. 可靠性兜底：实时转写停滞时从录音重建并强制生成摘要、部分转写丢失时保留录音、静音状态下仍能检测停滞——"会后必有摘要"成为可兑现的承诺；
2. 即时交互：删除/撤销/忽略日历事件、日期编辑、聊天消息发送全部即时反馈，并消除重复触发，交互体验由"等待保存"转变为"先响应后落盘"；
3. 协作与可观测：共享笔记评论锚定到引用文本，同步状态以clean/conflict状态机形式呈现于指示器与菜单，多设备（最多 5 台）同步状态一目了然。

结合仓库源码可以看到，这些改进分别落实在转写/音频 crate 栈、本地优先同步体系（db-sync、cloudsync）以及桌面端session-sharing模块中，既有面向用户的功能价值，也有清晰的工程实现支撑。

【免费下载链接】anarlogOpen source Granola AI Alternative项目地址: https://gitcode.com/GitHub_Trending/hy/anarlog