点点记团队参与了 Apple 开发者计划的一对一技术交流，围绕 AI 能力、图像识别、本地模型和后端架构等方向进行了深入讨论。
这次交流没有把 AI 当成一个单独卖点。团队重新确认了一个更具体的问题：哪些智能能力真的能帮助用户更快记录任务、整理任务，并回到专注状态。
让智能能力服务体验
对点点记来说，AI 能力适合优先出现在用户已经有明确意图的时刻。例如记录一个任务、描述一段计划、识别一个更自然的时间表达，或在不打断当前流程的情况下提供辅助。
这样的设计思路后来也影响了语音创建任务、自然语言解析和隐私说明。智能能力不替用户做决定，主要把输入整理成可以确认、可以修改的信息。
技术方向与产品取舍
交流中也讨论了本地模型、后端架构和图像识别等方向。点点记会继续优先考虑简单、可理解、可控的体验，而不是把复杂技术直接暴露给用户。
这次对话让后续版本的技术路线更清晰：智能能力可以进入产品，但必须服务于更轻的开始、更稳定的记录，以及更清楚的数据处理方式。
先从任务创建开始
交流之后，团队对“AI 先解决什么”有了更清楚的判断。比起做一个独立的聊天入口，DottieNote 更需要的是让任务创建更轻：用户说一句自然语言，系统帮助提取标题、时间、日期和重复规则，再交给用户确认。
这个方向后来进入 2.0 的语音智能识别。它不展示技术，解决的是一个普通问题：很多人想到任务时，手边不一定方便打字；即使方便打字，也不一定想马上填写完整表单。
如果 AI 能把这一段输入整理好，用户就能更快把任务留住。但最终保存前，控制权仍然要在用户手里。
本地能力和云端能力要分清
这次交流也让团队更认真地思考本地模型与云端能力的分工。不是所有智能处理都必须上传，也不是所有任务都适合完全在本地完成。关键在于用户是否知道每种能力在做什么。
核心任务数据默认留在设备上；需要云服务参与的场景，会尽量限定在当次请求，并把用途说清楚。用户不该为了使用一个方便入口，就默认交出长期数据。
这条分工后来也写进隐私和语音说明里。智能体验可以更自然，但不能以含糊的数据处理为代价。
技术讨论最终要回到体验
开发者交流会带来很多技术可能性，但 DottieNote 不会把每个可能性都变成功能。我们更关心它是否能减少一步操作、降低一次误解、或者让用户更快回到任务。
后续版本里的语音解析、快速添加、iCloud 同步说明和本地优先文章，都和这次交流后的判断有关：技术可以复杂，但用户面对的体验要清楚。
AI 方向要回到真实场景
很多产品在加入 AI 时，会先想“还能做什么”。DottieNote 更关心的是“哪里真的卡住了”。任务创建时的自然语言、临时想法的整理、时间表达的识别、用户确认前的信息结构，这些才是更靠近真实使用的问题。
这次交流帮助团队把 AI 从概念拉回到具体场景。它不是另一个需要用户学习的入口，更适合嵌入已有流程，让记录更快、编辑更清楚、确认更安心。
同时，AI 能力也不能冲淡本地优先和隐私说明。用户说出的任务可能非常私人，所以技术方案必须同时回答体验和数据两个问题。
这次交流的价值，也正在这里：它把 AI、设计和隐私放在同一个真实使用场景里讨论，让 DottieNote 后续的取舍更清楚。