產品
逐字稿頁面重做了：從一份紀錄，變成一個查得到的記憶庫
存下逐字稿很容易。難的是三個月後還找得到。
一份 142 段的逐字稿，存在那裡的時候是資產，要找的時候是負擔。你記得談過那件事，記得大概是春天，但不記得是哪一場、房號幾號、跟誰。於是你一份一份打開來看。
我們把逐字稿頁面重做了一遍。它現在要回答的不是「紀錄還在嗎」，而是我上次跟某某人談的那件事，是哪一場？
每一場都有標題、重點和參與者
一場結束後，系統會讀過整份逐字稿，寫出標題、幾個重點、做過的決定，還有待辦事項。列表上你看到的不再是「房號 4821 · 8 月 3 日 · 142 段」，而是這場在講什麼。
摘要只做一次，存進資料庫。之後每次打開讀的都是同一份，不會重算，也不會每次給你一個不太一樣的答案。
長的場次會送前 14,000 字加最後 6,000 字，中間留一個明顯的缺口。這是刻意的：決定通常是在最後做的，只讀開頭的摘要會漂亮地報告一場沒有結論的會議。
參與者指的是有開口的人
這是整個功能裡最有價值、也最容易做壞的一個欄位。
如果「參與者」把被提到的人也算進去，那「我跟誰談過什麼」就會答錯 —— 而且錯得很難發現。你查到一場，打開一看，那個人根本沒來，只是被引用了一句話。一旦發生過一次，這份名單就不能再信任了，整個功能也就沒有意義。
所以規則是硬的：必須有這個人開口的證據，找不到就回空名單。空的是正確答案。
我們拿兩份真實文字稿測過。一支從頭到尾只有一個人講話的 vlog，回傳空名單。一場刻意有兩個陷阱的會議 —— 一位請假的設計師，他負責的部分由同事代為報告；一位行銷同事，他算的數字被重新核算過的人引用 —— 結果只列出真正發言的三個人。
在任何一場點下參與者的名字，清單就會篩成他參與過的場次。這是這個頁面上最值得的一次點擊。
一個列表，三個來源
- 存在帳戶裡的逐字稿
- 只存在這台瀏覽器裡的
- 錄音轉文字上傳的檔案
同一場直播如果兩邊都有，它是一列，帶兩個標記。列成兩列會讓人以為自己有兩份紀錄。
上傳的錄音則永遠不會被併進直播那一列：一個是現場說出來的話，一個是一個檔案，看起來像同一場也不是同一件事。
找下一場的時候，不會弄丟這一場
列表平常每一場只佔一行。點開才展開摘要，閱讀在右邊的欄位進行（畫面夠寬時分左右兩欄，窄的時候上下疊）。
這個安排只為了一件事：在清單裡找下一場，不必離開正在讀的這一場。
直播的「版本」是它的各種語言，上傳錄音的版本是修潤稿與原始稿，兩種都在同一個面板裡讀。
字幕是段落，不是一行一行
即時字幕是一塊一塊產生的，一個句子常常被切在中間，甚至切在一個字中間。原樣列出來，讀起來是碎的。
所以同一句話的區塊會被接回成一段，段落之間空一行。下載下來的檔案也是同樣的形狀。
時間戳收在選單裡
時間是經過時間，不是時鐘時間 —— 你想知道的是「這句話在第幾分鐘」。它收在一個 ⋯ 選單後面，因為多數時候你在讀內容，不是在對時間軸。
這裡有一個誠實的限制：錄音轉文字的時間戳只有原始稿有，而且只有 2026 年 8 月 6 日之後轉的錄音才有。供應商在工作完成時就把逐字級的時間資料刪掉了，更早的錄音要不回來。修潤稿也永遠不會有，因為 AI 修潤的過程會重新分段。選單裡會直接寫出來，而不是給你一個按了沒反應的開關。
存在哪裡，你決定
預設情況下，逐字稿只存在你錄的那台瀏覽器裡，我們的伺服器沒有。你可以在帳戶設定打開「把逐字稿存到帳號」，之後就能在別的裝置上讀。
打開這個設定會連之前錄的那些一起往上補，不只是從打開的那一刻算起。開啟一個設定，本來就該套用到你已經有的東西。
瀏覽器端保留最近 50 場，帳戶沒有上限。
有一個看起來矛盾但重要的細節：只存在裝置上的那些逐字稿，它們的摘要是存在我們這裡的。稿不留，摘要留。這是為了讓你在任何一台裝置上都看得到自己的索引，而摘要本身不是會議紀錄，也不能還原原文。
摘要用你的語言寫，不是用那場的語言
如果你這週開了一場日文會議和一場英文演講，你想要的是一份可以一眼掃過去的清單，而不是兩種語言混在一起。所以摘要寫成你在帳戶設定選的語言，目前有 60 種可以選。
人名和地名維持原文 —— 翻譯掉的話，這個索引就搜不到了。
逐字稿頁面在 帳戶中心。如果你已經開過幾場，現在打開應該就會看到它們各自的標題了。