Claude Code 礼貌地请求。Aye Chat 默认采取行动。
Source: Dev.to
我看到 Claude Code 的广告，心想：啊，是的，那位彬彬有礼的开发者工具管家。
“一个在行动前先解释思路的助手。”
它优雅、谨慎，像是会在重构前先把餐巾纸搭在手臂上的那种助手。
Aye Chat 并不是那样。
Aye Chat 是那位手持电钻的混乱‑善良实习生——只不过我们装上了一个巨大的红色 UNDO 按钮，并自行写好了保险政策。
权限是昂贵的用户界面
吃掉你午餐的那点小税。
先批准的工具感觉就像在餐馆点餐，服务员把整个供应链都念给你听：
You: “Could you rename this parameter?”
Tool: “Certainly. First I will analyze the repository. Then I will propose a plan. Then I will show you the plan. Then I will explain the plan. Then I will ask if you approve the plan… would you like me to proceed?”与此同时，你的咖啡变凉了，注意力开始漂移，大脑像一个不小心打开的浏览器标签页一样开始加载另一个任务。这不是道德上的缺失，而是物理规律。每一次“你确定吗？”的提示都是流程高速路上的减速带。
Aye Chat的赌注：带降落伞（还有备用）的乐观主义
Aye Chat围绕 乐观工作流 构建：
- AI 直接写入文件。
- 每次写入都会在本地 快照。
- 如果你不喜欢，你可以 立即撤销。
没有批准复选框。没有预审委员会会议。没有标题为 “提议的重命名计划（第一季度）” 的 12 张幻灯片。
只需要：
restore这就是诀窍。
我并不是说模型完美——那就像声称你的猫总是四脚着地 并且 能帮你报税。我在说更平凡、更实用的事：模型足够常正确，以至于 默认执行操作 更快…… 只要撤销是即时且可靠的。
所以我先造了降落伞。然后才开始跳伞。
为什么撤销比批准更好（大多数情况下）
Approval 感觉安全，因为它试图防止错误。
Undo 感觉安全，因为它让错误变得廉价，而廉价的错误正是软件编写的方式。
先批准的方式会在你甚至不知道改动是否重要之前，就把你推入审稿人的思维模式。先撤销的方式让你保持在构建者的思维模式：
- 提问。
- 获取改动。
- 运行测试 / 运行应用 / 执行命令。
- 保留或回滚。
这也是白板有效的原因：先写后擦。Git 基本上是文明对以下约定的实现：
“我们会做一些稍微冒险的事，但我们会保留凭证。”
Aye Chat 正是如此——只不过凭证会自动生成，钉在改动上，直接交到你手中。
“但是直接写入文件很可怕。”
Yes. So is using a table saw. That’s why table saws have guards, and why we treat snapshots like a seatbelt:
- 自动 (no remembering to commit/stash)
- 本地 (stored in
.aye/, not beamed into the void) - 即时 (restore is one command)
If the model goes off‑road, you don’t open a philosophical debate. You don’t negotiate with the GPS. You just take the last exit and try again.
用最通俗的英文说明真正的区别
Claude Code 的 UX 说：
“我先解释，你批准，然后我执行。”
Aye Chat 的 UX 说：
“我先执行，你再响应——如果出现诅咒，我们就把时间倒回去。”
不同的默认设置。不同的氛围。
Claude 是那个在移动椅子前先征求许可的助手。
Aye Chat 是那个把房间重新布局让一切变得合理的助手，如果你不喜欢，它会把一切恢复到原来的位置。
如果你在终端里工作，这个默认设置并非表面功夫。它决定了：
- 照看一个每拧一颗螺丝都要签名的助手，和
- 使用带有紧急停止和干净回滚功能的电动工具之间的区别。
停止批准。开始交付。保留降落伞。
关于 Aye Chat
Aye Chat 是一个开源的、AI 驱动的终端工作区，将 AI 直接引入命令行工作流。编辑文件、运行命令，并在不离开终端的情况下与代码库聊天——采用乐观的工作流，并由即时本地快照提供支持。
支持我们
给 GitHub 仓库加星：
传播这个信息。与在终端中工作的团队和朋友分享 Aye Chat。