聊天框只是 AI 的一种外形，不应该成为所有个人软件的默认答案。对我而言，更有趣的问题是：当模型退到界面背后，它能否像搜索、撤销或同步一样，成为一块可靠而克制的材料？
AI 最好的位置，不是替人决定，而是在意图与执行之间提供一层可协商的能力。
从命令走向意图
传统软件要求人先理解菜单和命令。AI 可以让用户直接表达“把这些零散记录整理成周报”，但这并不意味着系统应该立刻改写文件。一个稳妥的过程至少包含：
- 识别目标，而不是猜测未说出口的动机；
- 展示将使用哪些本地上下文；
- 先给出可编辑的建议或差异预览；
- 只有在明确确认后才执行；
- 为执行结果保留可靠的撤销入口。
我更愿意把模型输出叫作 proposal，而不是 result。这个命名会提醒开发者：它是一份提案，还不是事实。
| 任务 | AI 可以做什么 | 必须由用户确认什么 |
|---|---|---|
| 整理笔记 | 聚类、生成标题、发现重复 | 移动或删除原文件 |
| 回复邮件 | 提炼上下文、起草不同语气 | 收件人、附件与最终发送 |
| 安排行程 | 比较空档、给出路线 | 创建日历事件与邀请他人 |
| 修改代码 | 定位关联处、生成补丁 | 写入范围与测试结果 |
上下文、建议与执行三层模型
我把能力拆成三个独立阶段：上下文层只读取已授权的数据；建议层产生可检查的结构化变化；执行层只接受经过确认的命令。这样既能记录审计轨迹，也能在模型不可用时保留手动流程。
type PersonalCommand<TPreview> = {
id: string;
context: readonly string[];
preview(): Promise<TPreview>;
confirm(preview: TPreview): Promise<{ undoToken: string }>;
undo(token: string): Promise<void>;
};
本地优先不是口号
本地优先首先是一套故障策略：断网后还能否打开旧记录？模型超时后是否丢失输入？更换供应商时能否导出原始数据？这些问题比设置页面里的一句“隐私友好”更具体。
实践中，我会优先保证三件事：
- 原始文件使用公开格式；
- 索引可以删除并重新生成；
- 云端能力失效时，核心编辑功能仍然可用。
把最终决定留给人
好的个人软件并不需要表现得像另一个人。它可以承认不确定，显示来源，并允许用户改掉每一个建议。智能不应以神秘感来证明自己。
当 AI 安静地完成归类、补全和检索，却在真正改变世界之前停下来问一句，我才会相信它已经成为软件的一部分，而不是占据软件的主角。
