AI 功能的风险不在聊天界面，而在聊天被允许做什么。
给助手工具，很容易让它显得强大。通过 Vercel AI SDK，它可以读数据、准备改动、调用操作并用自然语言解释结果。这很有用，也可能成为进入重要产品行为的隐蔽侧门。
我倾向把 AI 工具当作产品边界。每个工具应有 schema、权限检查、明确结果，并决定它是只读还是会修改数据。
const DraftChangeSchema = z.object({
recordId: z.string(),
summary: z.string(),
proposedValue: z.string(),
});schema 不只提供 TypeScript 便利，也描述助手被允许请求什么，并限制服务器接受什么。
重要改动需要确认：助手草拟并解释原因，用户审阅摘要后决定是否应用。在确认之前，不改变重要数据。
助手：准备修改
用户看到：摘要、受影响记录、建议值
用户选择：确认或取消
服务器记录：谁在何时确认，具体改了什么这比直接执行慢，正是目的所在。涉及持久数据、权限、计费、文档和流程状态时，一点阻力有价值。
只读工具适合作为第一步，助手可以回答而不修改。即便如此，权限仍然重要：普通界面无权读取的数据，助手也无权读。
确认文案也不能含糊。高风险动作只写“应用”不够，面板应以日常语言说明对象、建议修改与后果。
AI 介入后，审计更重要。应记录助手提出什么、用户批准什么，不是因为 AI 神奇，而是路径比普通表单更间接，未来调试需要还原过程。
代价是产品速度。确认太多会烦人，太少又不安全。我愿先严格，再只对风险低、可逆且已充分理解的动作放宽。
不要从把全部工具交给 AI 开始。先做一个狭窄任务：读用户本就可见的记录，用严格 schema 草拟修改，展示将发生什么，写入前确认，并记录结果。
边界未来应如何变化，仍是开放问题。有些动作可能逐渐适合直接执行，有些则始终需要审阅。答案不只在技术，还取决于信任、可逆性和错误代价。