背景

2024 年底，团队在设计 AI 代码助手时，面临一个核心架构决策：

用户期望：

  • “AI 应该能自动完成整个功能”
  • “不想每次都手动确认”
  • “竞品都是一键完成，为什么你们要让我点那么多步骤？”

市场压力：

  • 所有竞品都在强调”全自动”
  • Demo Day 上，投资人对”一键生成”印象深刻
  • 用户调研显示，“便利性”总是排第一

技术现实：

  • GPT-4 在复杂代码任务上的准确率约为 75-80%
  • 错误类型不可预测：有时是语法错误，有时是逻辑漏洞，有时是安全隐患
  • 一旦用户习惯了”全自动”，就不再检查结果

这是一个典型的”便利性 vs 掌控感”的冲突。

可选方案

方案 A：全自动模式（Convenience-First）

设计流程：

用户描述需求 → AI 生成完整代码 → 自动插入到项目 → 完成

优点：

  • 用户体验丝滑，“魔法般”的感觉
  • Demo 效果惊艳，易于市场推广
  • 用户学习成本低

风险：

  • 当 AI 出错时，用户不知道哪里有问题
  • 错误可能在生产环境才暴露
  • 培养了”盲目信任 AI”的习惯

真实案例（来自竞品用户）：

某 AI 代码工具在自动重构时，认为一个配置文件是”重复代码”，删除了 production 数据库配置。用户在部署到生产后才发现。

方案 B：完全手动模式（Safety-First）

设计流程：

用户描述需求 → AI 生成代码 → 展示给用户 → 用户手动复制粘贴 → 手动测试

优点：

  • 用户完全掌控
  • 错误在接受前就能发现
  • 培养正确的使用心智

缺点：

  • 用户体验笨重，“不够智能”
  • 需要大量手动操作
  • 可能被视为”没有竞争力”

方案 C：分层确认模式（我们的选择）

设计流程：

用户描述需求
→ AI 生成执行计划（展示给用户）
→ 用户选择执行模式：
   - 🚀 信任模式：自动执行所有步骤
   - ⚡ 标准模式：在关键节点暂停确认
   - 🛡️ 谨慎模式：每步都需要确认
→ 执行
→ 提供完整的 Undo/Redo

核心理念：

  • 默认是”标准模式”
  • 在不可逆操作前自动暂停
  • 让用户看到 AI 的思考过程

判断逻辑

1. 长期用户价值 vs 短期爽感

我们做了一个 6 个月的对比模拟：

时间点全自动体验分层确认体验
第 1 次使用😍 惊艳：“太神奇了！”😐 普通：“还要确认？“
第 10 次使用😟 开始担心：“万一错了怎么办？”😊 建立信任：“我知道它在做什么”
第一次出错后😱 不敢再用：“差点出大事”🛠️ 知道如何修正：“还好我检查了”
6 个月后📉 用户流失📈 忠实用户

2. 用户不是铁板一块

通过用户访谈，我们发现了三类用户：

新手用户（~30%）：

  • 不理解 AI 的局限性
  • 害怕犯错
  • 需要引导和安全感

日常用户（~50%）：

  • 想要效率，但也要可控
  • 需要在速度和安全之间平衡

专家用户（~20%）：

  • 理解 AI 的能力边界
  • 愿意承担风险以换取速度
  • 需要完全自动化

全自动设计只服务了 20% 的专家用户，却让 80% 的用户感到不安。

3. 参考案例：Tesla Autopilot 的教训

Tesla 的早期策略：

  • 2016-2018：市场宣传”全自动驾驶”
  • 结果：用户过度信任 → 分心驾驶 → 多起事故
  • 现在：强制要求手放在方向盘上，定期检测注意力

关键洞察：

用户要的不是”自动化”，而是”增强的掌控感”。

4. 失败成本的非对称性

操作类型AI 出错成本（全自动）AI 出错成本（分层确认）
生成测试代码低（测试会发现）低（用户会审查）
删除文件高（数据丢失）低（确认前已警告）
修改配置高（服务中断）低（用户会检查）
发布代码极高（生产事故）低（多次确认）

在高风险操作上，“便利性”的代价是灾难性的。

决策

我们选择方案 C：分层确认模式

具体设计细节

1. 透明化 AI 的思考过程

📋 执行计划：

✓ Step 1: 分析现有代码结构 [已完成]
✓ Step 2: 生成新功能代码 [已完成]
⏸ Step 3: 修改 database schema [需要确认]
   ⚠️ 风险：会影响现有数据表结构
   🔍 查看变更 | ✅ 继续 | ✋ 跳过

○ Step 4: 更新测试用例 [待执行]
○ Step 5: 更新文档 [待执行]

2. 风险分级系统

风险等级操作类型默认行为
🟢 低风险查询、搜索、生成自动执行
🟡 中风险修改代码、重命名标准模式下自动，谨慎模式下确认
🔴 高风险删除、发布、修改配置所有模式都需要确认

3. 可撤销设计

  • 所有操作都有 Undo/Redo
  • 提供完整的”操作历史”面板
  • 关键操作支持 24 小时回滚

4. 用户模式切换

用户可以随时切换模式：

  • 🚀 信任模式：适合专家用户，承担全部风险
  • ⚡ 标准模式（默认）：在高风险操作前暂停
  • 🛡️ 谨慎模式：每步都确认

第一次使用时，强制使用”谨慎模式”，完成 3 次任务后才能切换。

后果与反思

3 个月后的数据

用户留存：

  • 标准模式用户：83% 月留存
  • 信任模式用户：61% 月留存
  • 谨慎模式用户：88% 月留存（新手居多）

NPS（净推荐值）：

  • 我们：68
  • 全自动竞品：54

用户反馈（原话）：

正面：

“第一次用的时候觉得麻烦，但有一次 AI 要删一个重要文件，我看到确认框才发现。现在我很感激这个设计。” - 后端工程师

“我可以放心让 AI 做重复性工作，因为我知道关键步骤它会问我。” - 前端开发者

负面：

“为什么不能完全自动？我就是想要快。” - 约 15% 的用户

我们的回应： 为这 15% 的用户提供了”信任模式”，但默认仍是标准模式。

意外收获

1. 用户教育效果

因为用户能看到 AI 的执行计划，他们学会了：

  • 如何写更清晰的需求描述
  • AI 的能力边界在哪里
  • 如何更好地与 AI 协作

2. Bug 报告质量提升

以前的 Bug 报告：

“AI 生成的代码有问题。”

现在的 Bug 报告：

“在 Step 3 ‘修改 API 路由’ 这一步，AI 没有考虑到现有的中间件逻辑，导致鉴权失效。”

精准度提升了 3 倍。

3. 差异化竞争力

在”全自动 AI”泛滥的市场中，我们的”可控自动化”成为了特色，而非劣势。

用户评价：

“其他工具像是黑盒，这个工具像是副驾驶。“

如果重来一次

我会做得更好：

  1. 更早引入用户分层

    现在才意识到不同用户需要完全不同的体验。应该在设计初期就做好分层。

  2. 更明确的心智模型引导

    很多用户最初的期望是”全自动魔法”。需要更好的 onboarding 来建立正确预期。

  3. 更激进的可撤销设计

    24 小时回滚窗口不够长。应该支持无限期历史记录（像 Git 一样）。

我绝对不会改变：

  • 默认标准模式（而非信任模式）
  • 在高风险操作前强制确认
  • 透明化 AI 的执行计划

更深层的思考：Agency vs Convenience

这个决策背后，是两种不同的产品哲学：

Convenience-First（便利至上）：

  • 人类应该从繁琐任务中解放
  • AI 越智能，人类越不需要思考
  • 终极目标：人类什么都不用做

Agency-First（能动性至上）：

  • 人类应该有更强的执行能力
  • AI 是工具，增强人的能力，而非替代人
  • 终极目标：人类能做更复杂、更有意义的事

我的信念：

好的 AI 工具不是让人变懒，而是让人变强。

设计哲学：

  • 不是”AI 替你做”，而是”AI 帮你做得更好”
  • 不是”减少用户操作”，而是”提升操作的质量”
  • 不是”自动化一切”，而是”自动化值得自动化的部分”

延伸思考：掌控感的本质

为什么用户需要掌控感？

不是因为他们不信任 AI，而是因为：

  1. 责任归属：出错时，用户需要知道”这不是我的错”还是”我应该检查但没检查”
  2. 学习机会：通过观察 AI 的决策，用户在学习
  3. 安全感：知道自己可以随时介入，本身就是一种心理需求

反例：

全自动的 AI 工具剥夺了这三者，即使它 95% 的时候是对的，用户仍然会感到不安。

Decision Date: January 5, 2025 Decision Maker: Product Lead + Engineering Lead Stakeholders: 全体工程团队、10 位 Beta 用户 Status: ✅ Validated（3 个月数据证明决策正确） Next Review: April 2025 Related Decisions: [[2025-02-build-vs-integrate-tradeoffs]]