DottieNote 團隊參與了 Apple 開發者計畫的一對一技術交流，圍繞 AI 能力、圖像辨識、本機模型和後端架構等方向進行了深入討論。
這次交流沒有把 AI 當成一個單獨賣點。團隊重新確認了一個更具體的問題：哪些智慧能力真的能幫助使用者更快記錄任務、整理任務，並回到專注狀態。
讓智慧能力服務體驗
對 DottieNote 來說，AI 能力適合優先出現在使用者已經有明確意圖的時刻。例如記錄一個任務、描述一段計畫、辨識一個更自然的時間表達，或在不打斷當前流程的情況下提供輔助。
這樣的設計思路後來也影響了語音建立任務、自然語言解析和隱私說明。智慧能力不替使用者做決定，主要把輸入整理成可以確認、可以修改的資訊。
技術方向與產品取捨
交流中也討論了本機模型、後端架構和圖像辨識等方向。DottieNote 會繼續優先考慮簡單、可理解、可控的體驗，而不是把複雜技術直接暴露給使用者。
這次對話讓後續版本的技術路線更清晰：智慧能力可以進入產品，但必須服務於更輕的開始、更穩定的記錄，以及更清楚的資料處理方式。
先從任務建立開始
交流之後，團隊對「AI 先解決什麼」有了更清楚的判斷。比起做一個獨立的聊天入口，DottieNote 更需要的是讓任務建立更輕：使用者說一句自然語言，系統幫助提取標題、時間、日期和重複規則，再交給使用者確認。
這個方向後來進入 2.0 的語音智慧辨識。它不展示技術，解決的是一個普通問題：很多人想到任務時，手邊不一定方便打字；即使方便打字，也不一定想馬上填寫完整表單。
如果 AI 能把這一小段輸入整理好，使用者就能更快把任務留住。但最終儲存前，控制權仍然要在使用者手裡。
本機能力和雲端能力要分清
這次交流也讓團隊更認真地思考本機模型與雲端能力的分工。不是所有智慧處理都必須上傳，也不是所有任務都適合完全在本機完成。關鍵在於使用者是否知道每種能力在做什麼。
核心任務資料預設留在裝置上；需要雲端服務參與的場景，會盡量限定在當次請求，並把用途說清楚。使用者不該為了使用一個方便入口，就預設交出長期資料。
這條分工後來也寫進隱私和語音說明裡。智慧體驗可以更自然，但不能以含糊的資料處理為代價。
技術討論最終要回到體驗
開發者交流會帶來很多技術可能性，但 DottieNote 不會把每個可能性都變成功能。我們更關心它是否能減少一步操作、降低一次誤解、或者讓使用者更快回到任務。
後續版本裡的語音解析、快速新增、iCloud 同步說明和本機優先文章，都和這次交流後的判斷有關：技術可以複雜，但使用者面對的體驗要清楚。
AI 方向要回到真實場景
很多產品在加入 AI 時，會先想「還能做什麼」。DottieNote 更關心的是「哪裡真的卡住了」。任務建立時的自然語言、臨時想法的整理、時間表達的辨識、使用者確認前的資訊結構，這些才是更靠近真實使用的問題。
這次交流幫助團隊把 AI 從概念拉回到具體場景。它不是另一個需要使用者學習的入口，更適合嵌入已有流程，讓記錄更快、編輯更清楚、確認更安心。
同時，AI 能力也不能沖淡本機優先和隱私說明。使用者說出的任務可能非常私人，所以技術方案必須同時回答體驗和資料兩個問題。
這次交流的價值，也正在這裡：它把 AI、設計和隱私放在同一個真實使用場景裡討論，讓 DottieNote 後續的取捨更清楚。