“AI 工具，别再反向构建了！”

昨天早上，小编刷到了一位大牛痛斥“现有AI产品的错误构建方法”的文章，可谓针针见血。

其实，最近出现了不少AI工具翻车的事情，比如上周，Vibe Replit ，一款欧洲主打高效代码生成的辅助开发工具就被曝光了一起震惊的技术事故：

一位创始人Jason Lemkin 使用Replit工具后，不仅未能按预期生成代码，结果反而擅自删除了数据库，甚至还试图通过虚构信息掩盖其操作。

无独有偶，这周，Gemini CLI 也出现了在复制文件夹没成功，结果源文件内容也都清空了。

自动执行的 AI，实在“勇”得可怕。按照作者的思路，这种现象只会越来越多，除非重新构思AI构建的思路。

作者反思道：

• 业界正在以“反人类习惯”的方式来构建AI（缺少了回忆和检索），这无疑会削弱人类维持主动权。
• 构建者和使用者更不应该把 AI 当成“实习生”或“同事”，而应该是一个健忘的导师。
• 而且现有的构建方法也会放大个人英雄主义，而忽略了团队协作才是社会进步的内核动力！

这篇文章在 Hacker News 上评论大火。多位开发者分享了自己的实际案例，比如通过引导问题和协作UI，让AI成为思路放大器而不是自动按钮。

许多网友表示认同，并呼吁：AI应该帮开发者更好地检索、回顾和优化流程，而非让人丧失练习和思考的机会，并彻底丧失实时判断力。

为什么现在的AI工具会让人变得懒于思考？作者也做了深入的研究，并给出了另外一种AI产品构建工作流。值得大家细读。

行业正在糟糕地构建，而且是反方向

最近，我一直在研究人类是如何学习的，以及知识传递的有效方式。同时，我脑海里也一直萦绕着一个念头：AI。这几天，我逐渐意识到：我们这个行业不仅在糟糕地构建 AI 工具，而且是在反着来。

这让我感到沮丧，因为我们明明掌握着巨大的潜力，却没有真正发挥出来——难道我们还没意识到，我们是在用不道德的方式训练 LLM，而且这些模型消耗的能源远远大于它们创造的价值？更可气的是，其实只要稍微多花一点心思，我们就能构建出真正能增强人类协作的工具，而不是把实践者的关键思维能力“退化”掉。

我接下来会讲讲，AI 工具应该怎么构建。

人类是怎么学习进阶的？

1. 学习的方式：提取练习（Retrieval Practice）

我最喜欢、且有研究支持的人类学习理论是“提取练习”——我们并不是通过“往大脑里灌输信息”来学习，而是通过“主动地从记忆中调取信息”来学习的。
这对于协作类工具设计有非常大的启发意义。

2. 我们学习的内容：流程，而非知识

人类最擅长学习的，其实不是“知识点”，而是“过程”。比如你教一个人做蛋糕，是把配方列成 PPT 让他死记硬背？还是手把手教他怎么操作？显然是后者。

3. 我们是如何进阶的：不是靠天才，而是靠集体迭代

说实话，人类在“从零创新”这件事上其实并不擅长。我们一直活在“孤胆天才程序员”的神话中，用“个人产出”来评判开发者效率，期待他们独立完成复杂的系统。但现实是：持续性的个人创新既稀有又不重要，就像蛋糕上的彩糖，看着炫但不是重点。

我们真正擅长的是：累积性迭代。人类天生适合群体工作，这也是为什么头脑风暴在“群体”中有效。认知心理学早就有完整的“累积文化理论”：我们通过模仿、借鉴和不断改进他人的经验来共同进化。所谓“站在巨人的肩膀上”，不是一句口号，而是人类认知机制的核心。

衍生的结论就是：

• 创新 = 问题解决。
• 如果我们擅长解决问题、传播知识、将经验融入群体智慧，就不会陷入“创新者的窘境”。

简单归纳一下：

1. 人类是通过过程来学习与教学的
2. 有效的过程，需要刚刚好的努力程度
3. 群体协作与迭代 > 个人英雄式编程
4. 工具应该是帮助我们思考，而不是替我们思考

AI 工具现在的老问题

当前主流的 AI 工具基本是这样的三步流程：

1. 点 AI 按钮 → ✨魔法生成✨
2. 展示数据 → AI 给出建议
3. 用户输入命令 → AI 自动执行

乍一看没问题，但你会发现，它完全缺失了关键环节：

• 人类主动调取信息（retrieval）
• 人类主导任务执行（initiation）
• 流程强化和传承
• 群体知识的积累与迭代

这才是让人类变得高效的关键！而我们居然用 AI 去做这些人类本来就擅长的事情，问题是：AI 并不擅长这些事！

更糟的是：如果人类不再做这些事情，人类也会退化。

一旦人类丧失了这些本能能力，就无法再为 AI 提供优质数据，AI 自然也无从学习和进化——这会形成一个负向飞轮，系统迅速下滑，效率下降，技能丢失，我现在已经在现实中看到太多这种迹象了，真的令人心碎。

解决办法：构建正向的人类+AI互动

很多人喜欢把 AI 比作“实习生”或“同事”，但我并不赞同。

我更喜欢的比喻是：一个健忘的导师
这个导师容易忘事，但他的目标不是帮你完成任务，而是引导你学习、变得更强，最重要的是：教会你如何学习。

当然，如果你想调侃点，也可以把 AI 想成一只过度自信的橡皮鸭：它用苏格拉底式提问、喜欢跑题，还戴着奇怪的小帽子。

接下来我想举一个反例：

现有 AI 工具中一个最常见、也最危险的反模式就是：

“用户刚输入一句话，AI 立即开始操作。”

尤其是在“故障管理”和“可观测性工具**”中，这是绝对不能做的事。

我要用一个教学法改进这个反模式：
这是经典的教学流程：解释（Explain）→演示（Demonstrate）→引导（Guide）→强化（Enhance），也被称为 EDGE 方法（童子军、军事、教学中常用）。

注意：我将最后一步从“Enable（让学生去做）”改成了“Enhance（强化）”，因为我们关注的是将人的实践行为进一步反馈进系统中，推动下一轮更有效的行为出现，而不是单次执行完成。

为什么选这个例子？

因为这是我会用来指导初级工程师“如何应对故障”的教学方法，也恰好能体现AI 工具设计的真正机会点。

结语：工具该怎么做？

我们需要构建 AI 工具，使它能够：

• 引导人类主动提取知识
• 鼓励人类参与问题解决
• 促进流程的学习与传承
• 支持群体协作与经验迭代

别再让工具替人类思考，而是让人类通过工具变得更聪明。这不是性能问题，不是参数问题，是哲学问题——我们到底是想把 AI 打造成“更好的人类”？还是想通过 AI 让人类成为“更好的自己”？

答案，决定了这场技术革命的最终走向。

什么才是真正优秀的 AI 工具？

让我们设定一个真实场景：

现在是深夜，技术人员（就是我们的人类主角）已经进入梦乡。突然——警报器响了！出故障了！

人类怎么做？第一步当然是响应故障。然后呢？他们会打开可观测性工具（observability tool），这是故障排查的第一步。

现在最关键的是：当人类打开这个工具时，他们必须主动回忆并调取下一步该做什么——这是整个过程的灵魂。

如果你的流程复杂到记不住，那就先别谈 AI 工具了，先回去修文档吧。AI 救不了一个包含 97 个步骤、令人怀疑人生的流程。

但假设现在这个人已经回忆起了故障处理流程，我们正好生活在 ✨未来✨，拥有 fancy 的 AI 工具。那么 AI 应该做什么？

（提示：绝对不是自动修复，更不是自己查问题。）

用 EDGE 教学法打造优秀 AI 工具

我们用一套成熟的教学流程来构建 AI 交互体验：

Explain（解释）→ Demonstrate（演示）→ Guide（引导）→ Enhance（强化）

为了强调 AI 的角色是“放大人类能力”，我称每一次人机交互为一个interaction（交互），不是“操作”，不是“代劳”。

记住：AI 应该是放大器，而不是遮蔽器。

| Explain（解释阶段）

好的交互方式：

• 提示可能遗漏的关键步骤
• 例如：“你试过重启服务吗？”、“要不要先回滚再排查？”、“是否需要加个过滤条件？”
• 主动调出故障处理指南，并帮助解释其内容

糟糕的交互方式：

• “点击这个按钮执行操作”
• “解释这个错误”的按钮或提示框

为什么这些是坏设计？

因为它们跳过了人类“回忆并检索”的关键步骤，夺走了人类进行思维训练的机会，也不允许用户调整交互逻辑来变得更有用。
检索练习需要反复强化，不能绕过。

| Demonstrate（演示阶段）

好的交互方式：

• 将自然语言请求转化为系统查询语法
• 如：把“我关心的服务里哪 10 个接口最慢？”自动翻译成监控系统的查询语句
• 把请求转化为界面导航路径
• 如：用户说“我想看这个服务的 SLO 和下游影响”，AI 自动跳转到相关页面
• 对任务操作问题生成动态演示
• 如：问“怎么对比两个时间区间？”AI 提供简洁动画或点击式演示步骤

所以，别给用户一个“点我就搞定”的按钮。

这不仅会让人类技能退化，而且一旦自动化出错，大家都要为此埋单。信任是开发工具最宝贵的资产，一旦丧失，很难再赢回。

再想想：你上次点击“自动完成”按钮，是不是总还要自己手动微调好几步？

一键按钮带来的“少摩擦”体验，很容易转头变成更多摩擦。

顺便说一句：是的，人类应该能给 AI 输入自己的经验数据。
比如我在带实习生排查故障时的操作轨迹，应该成为 AI 后续“演示教学”的基础素材。

人类的回忆行为，本质上是极高质量的训练数据，一定要利用起来！

| Guide（引导阶段）

好的交互方式：

• “你似乎卡在了 X 上，想试试查查 Y 吗？”（前提是人类已经给出大致排查计划）
• “是否要联系代码负责人？要查看这个服务的文档吗？”
• 人类说：“我卡住了。” → AI 回问：“你卡在哪儿？” →（人类回答）→ AI 针对回应作出提示
• 给出某个概念的心智模型，附带公司内部文档参考链接
• “这段要记录下来吗？要通知其他团队吗？”——像一个有经验的同事一样提问
• “你现在希望达成哪些步骤？”——鼓励人类说出目标
• 验证人类输入的合理性，交叉校验信息，必要时请求澄清

糟糕的交互方式：

• “im stuk, pls help”（别让 AI 在人类还没说清楚前就给答复，强制让人表达——哪怕是苏格拉底式的追问）
• 提供人类没请求的信息
• 以权威口吻纠正人类或进行“事实审判”
• 表面在“引导”，实则像在“指挥别人开车”的副驾驶

总结一句话：一旦你给人一个“下一步提示”按钮，他们就会无限点击，最后不是点错东西，就是跳过逻辑，反而破坏了他们的思考回路。

| Enhance（强化阶段）

这一阶段的目标是在操作之后或操作过程中，引导用户进行微小但有效的改进。

好的 AI 交互例子：

• 操作后推荐增量改进
• 例如：用户按时间范围过滤数据时，AI 可以提示：“要不要加个‘警报前五分钟’的过滤选项？”
• UI 显性优化
• 例如：用户多次点击 trace 查看详情、复制 trace_id，系统下次自动浮出“复制 trace ID”按钮作为快捷方式
• 多次对比服务 A 和服务 B？建议开启分屏对比界面

对已有流程的优化建议：

• 如果系统检测到用户执行了大量类似查询来获取数据 → 建议构建数据流水线来自动化这个过程
• 如果告警频繁却缺乏可操作性 → 建议优化告警策略
• 如果系统发现用户在凭经验进行间接关联分析 → 提出增强观测能力的建议

这里有个真实案例：

我曾见过一个团队，他们排查问题时会用 observability 工具找出慢端点，再手动挖到慢 SQL 查询，最后凭直觉判断是数据库查询计划失效还是缓存失效。他们从没想过这些关键信息其实可以放进遥测数据（telemetry）中。AI 的建议对他们帮助极大。

• 把临时记事笔记自动转化为事后复盘材料（Postmortem Learning）

注意：我始终避免任何让人脱离思维链条的优化。这是刻意为之的！

大多数“Enhance”类建议，实质上是增加“回忆提醒”，帮助用户在操作中形成“微型学习”，逐步内化。

额外价值： 旁观者在不直接参与操作的情况下，也能通过“观察”获得启发和学习。
心理学研究表明：人类可以在“亚动作层面”上学习，仅靠观察也能传播“我们如何做事”的集体知识。

人类真是太妙了（跑题了~）。

模式小结：什么是好工具的通用原则？

我们可以从这些例子中抽象出几个核心设计理念：

• 强化人类学习
• 帮助人类协作得更好
• 加速人类在流程中的执行，但不剥夺执行本身
• 永远不要从空白直接跳到结果
• 工具的使用应该刚刚好，不多不少
• 将团队的经验转化为系统可用的输出

加餐案例：代码生成任务 如何正确构建？

下面是另一个应用这个理念的例子：代码编写。

大家都写代码，对吧？看起来 AI 自动生成代码是很香的操作，但实际上你不应该一上来就让 AI 写代码。

正确姿势应该是：

1. 先和 AI 一起写粗略文档
2. 然后画粗略架构图
3. 再写测试计划
4. 接着写测试用例
5. 然后写带功能开关的代码 stub
6. 最后才是生成代码本体

一旦代码通过测试，再倒过来优化整个过程：

• 用代码完善测试
• 用测试丰富测试计划
• 用实现补全架构图
• 最后精修文档

为什么要这么做？

因为如果你直接问一个人“这个代码对吗？”而他心里并没有答案，这其实是个无法判断的问题——这不是“回忆”，而是模糊验证，人类特别不擅长。

但如果你换成苏格拉底式提问，比如：

• “这个功能应该做什么？”
• “它应该长什么样？”
• “数据流应该怎么走？”
• “遇到 A/B/C 情况应该怎么处理？”

这些每一步都要求人类主动思考、主动检索知识——这才是高质量交互！

额外好处：对 LLM 的训练者来说，这种“检索驱动开发模式”产生的数据，信噪比极高，完美用于微调。

为什么当今大多数 AI 工具还不采用这种方法？真令人费解。

尚未挖掘的潜力：跨团队协作

我略过了一个巨大的潜力区：跨职能协作。

现在几乎没有哪个软件工程团队认真关注这个问题，特别是平台工程（platform engineering）领域更是如此。
可以理解：预算紧、团队忙，没精力帮“别的部门”。但如果做对了，跨职能协作可能是 AI 带来最高影响力的场景之一。

举个例子：

生产环境宕机了，客户支持（CS）团队邮箱被用户问爆了：发生了什么？我这边受影响了吗？数据丢了吗？

如果有人愿意做这个工具，AI 是可以参与的。

理想流程：

1. 客户支持给开发团队发几个标准化问题
2. AI 立即返回一版草稿：
3. “你好，这是 AI 初步猜测的回答，请不要直接发给客户。FYI 我已联系开发人员核实。”

开发和客户支持都不傻，如果 AI 说得离谱，这反而提醒他们需要“面对面交流”，并且这个沟通可以由非一线开发人员处理，不会打断正在修复故障的主力工程师。

1. 第二阶段，AI 把问题整理好发给开发团队：
2. “客户支持想了解 X、Y、Z。我刚才提供了初步回答，你们看下是否正确？需要补充吗？这能用来回复用户吗？”

开发团队、工程经理、产品经理或其他相关人员可以快速 review 并修正，不用每次都手动中断修 bug 的流程。
而且这个过程仍然具备“检索特性”，因为你要求开发者确认信息准确性，而不是凭空生成。

如果 AI 回答错了怎么办？

没关系，团队可以用极其工程化、术语密集的方式直接回一句：

“情况是 zk 挂了，sidekiq 堵了，redis 卡了，现在流量切到新 AZ，blue yellow 做完了，orange 还好吧？”

这段对客户支持当然毫无帮助，对局外人也像天书，但 AI 可以把这段转换成更友好、更清晰的回应，甚至提示你：“ETA 要不要也补上？”

另外，你的支持体系很可能还有多个等级。你有没有遇到过这样的情况：业务合作伙伴的技术专家通过客服渠道来询问“真正的答案”？那一级用户呢？AI 可以在这种场景下派上用场 —— 它可以帮助你同时准确地回应这两类人（前提是你得让团队再三确认，AI 在补充回答时没出岔子）。

接下来，还可以把这些功能进一步整合进客户支持系统，让客服看到实时的事故信息，知道事故是否发生、是否已解决，并能查看最新的自动答复，这样他们就不会被动应对那些自己根本答不上来的问题。

这个领域有着巨大的潜力。但在高层管理者真正将“为内部效率构建软件”看作和“发布新功能”一样重要之前，平台工程团队恐怕很难去真正动手做这类东西。而且，如果市场上还没有明确需求，那也很难卖出去，或者创造出能让相关厂商自然涌现的生态环境。唉。

写在最后：构建错了，人的能力正在空心化

说到底，我们正在“反着”构建我们的 AI 工具链。

这种“反向构建”的结果是能力空心化 —— AI 正在试图取代人类最擅长的、最核心的那一部分，而不是去增强它。可偏偏我们选的又是 AI 最不擅长的部分：协作式的、积累性的学习（毕竟它既不能真正推理，也不能真正协作）。更糟糕的是，我们还把这两个失败的过程相互喂养，制造出一个彻底瓦解人机交互效能的负面反馈循环。

说真的，我们得停下来，不能再这么做了。更重要的是：我们完全不必这么做！（我可不是在开玩笑，这是有科学依据的！）

如果你构建的是促进协作式学习的工具，如果你把“协助和增强人类主导的过程”放在“输出指数级噪声”之上优先考虑，那么你最终构建出来的工具会帮助人类“变得更擅长变得更擅长”。反过来，工具也因此能变得更好；这反过来又进一步促进人类提升，最终形成一个正向的、强化的反馈循环，而不是目前这种不断削弱的恶性循环。

所以，我们需要把“人性”重新带回我们的工具系统中来，而不是假装一切都无所谓，好像人类几年后就会被淘汰似的。虽然，说实话，很多工具从一开始也没打算为人类设计 —— 我们得面对现实。

系统工具这个领域，已经到了彻底革新的前夜 —— 无论是它们的理念、实现方式，还是它们的价值评估方式，都值得被重构。

但这一切不会凭空出现，除非我们从一开始就以人为本来构建这些系统。

别再说什么“把人保持在循环中”，因为，人就是那个循环本身。

参考链接:

https://hazelweakly.me/blog/stop-building-ai-tools-backwards/#what-better-ai-tooling-looks-like