他用 Cursor 和 GPT-4o，一小时复刻了一个 Intercom

如果你还觉得「AI 客服」只是个接 OpenAI API 的聊天框，那这条视频会直接把你打醒。Mckay Wrigley 用 Cursor 从零搭出一个接近 Intercom 的 AI 客服系统：有 UI、有 Agent、有函数调用、能进数据库，甚至还能分流到 Slack。更狠的是，大部分代码不是“写”的，是“说”出来的。

最反直觉的地方：代码不是写出来的，是“指挥”出来的

视频一上来就抛出一个很颠覆的事实：真正耗时的，已经不是写代码，而是“告诉 AI 你想要什么”。Mckay 几乎没有手敲复杂逻辑，而是不断在 Cursor Composer 里用自然语言下指令——“给我一个 Intercom 式的右下角聊天按钮”“修一下点击区域的 bug”“把组件接进 layout”。

Cursor 并不是简单补全代码，而是在理解项目结构的前提下生成完整组件、文件、甚至目录。这意味着，工程师的角色正在从“实现者”变成“架构指挥官”。你不需要先把所有细节想清楚，只要不断校正方向，AI 会自己把代码往那个方向推。

一个细节很有代表性：Cursor 生成了新 components 文件夹，但不符合项目既有结构。Mckay 没有重写，而是顺手调整、再继续让 AI 接着干。这种“半自动 + 人类品味”的工作方式，才是现在最真实的 AI 编程状态。

这不是聊天机器人，而是一个真正的 AI 客服 Agent

很多人做 AI 客服，停留在“能对话”。但视频里真正拉开差距的，是 function calling。

Mckay 设计了一个非常关键的函数：让模型判断“问题是否已经解决”。如果没解决，继续对话；如果解决了，就给出收尾话术。这一步，直接把普通 Chatbot 拉升成了“Agent”。

他明确说了一点：所谓 AI Agent，并不是多神秘的东西，函数调用就是核心基础设施。模型一边对话，一边在后台做判断和决策，并把理由结构化地返回。

更现实的是，这套逻辑几乎完全来自 OpenAI 官方文档，复制、粘贴、稍作修改即可用。这里传递的信号非常清晰：AI Agent 的门槛，已经低到前端工程师也能轻松上手。真正的差异，不在 API，而在你有没有想清楚“这个 Agent 到底该帮人做什么决定”。

真正的复杂度：不是模型，而是“把系统接起来”

如果你以为难点在 GPT-4o，那你会在中段直接破防。真正花时间的，是最传统、也最容易被忽视的部分：数据持久化。

为了让聊天“像真的客服系统”，消息必须进数据库。Mckay 让 Cursor 直接根据现有模板风格，生成 chat 和 messages 的 schema、queries 和 actions。结果是：几十个文件一次性写完。

但这里也暴露了 AI 编程的现实边界——类型错误、导出遗漏、迁移失败，还是得人来兜底。他甚至明确说，这就是为什么你需要 prompt 文件：给 AI 提供最新、最准确的库上下文，否则它很容易在边缘问题上翻车。

这一段的价值在于，它非常真实地展示了“AI 没有消灭工程复杂度，只是把复杂度集中到了系统连接处”。会不会 debug、懂不懂全栈，依然决定了你能不能把 AI 写的代码真正跑起来。

从玩具到产品，只差这些“非模型”的细节

在视频最后，Mckay 做了一个很成熟的收尾：他并没有把这个项目包装成“生产级完美方案”，而是明确指出还有大量可以进化的空间。

比如：消息流式输出、更加自然的对话策略、异常时的退出机制、更丰富的 prompt 文件、以及和内部工具的深度集成。他甚至已经顺手做了一个 Slack 集成，用来自动分流和通知问题。

这其实点出了一个行业级趋势：未来 AI 产品的竞争力，很少来自“你用的是不是最新模型”，而是来自这些看起来很琐碎的工程与体验细节。模型负责智力下限，而产品能力，决定上限。

总结

这条视频真正值得 AI 从业者反复琢磨的，不是“怎么用 GPT-4o 写客服”，而是一个工作方式的转变：你不再需要从零实现复杂系统，但你必须更清楚自己在构建什么。

如果你是工程师，这意味着你该把时间花在系统设计和决策逻辑上，而不是纠结语法；如果你是产品或创业者，这意味着现在就能用极低成本验证一个“AI 客服/Agent”是否成立。

一个值得思考的问题是：当“写代码”越来越快，你真正的护城河，会不会变成“你知道该让 AI 决定什么”？

关键词： AI客服， AI Agent， Cursor， GPT-4o， 函数调用

事实核查备注： 需要核查：视频发布时间（2024-09-10）；使用的模型名称是否为 GPT-4o；是否明确使用 OpenAI function calling；是否提到 Slack 集成；Cursor Composer 的具体功能描述是否与视频一致