大家好，我是 Axton。自从初次接触 Cursor 并被其强大功能所震撼后，一个念头便在我脑海中挥之不去：一个完全没有编程经验、不会写代码的人，能否仅凭 Cursor 就独立完成一个略有难度但又不至于过分复杂的应用程序呢？带着这份好奇与期待，我构想了一个字幕翻译 web 应用的开发计划。这个想法也恰好回应了之前朋友们希望我的视频能提供英文字幕的建议，一举两得，还能顺便实践一下吴恩达 (Andrew Ng) 老师推崇的反思翻译法，以期提升翻译质量。进入 2025 年，AI 辅助编程工具日趋成熟，这次探索无疑是对其当前能力的一次深度检验，希望能为同样对 AI 编程感兴趣的你带来一些启发与实用的避坑经验。
我的”零代码”实验：用 Cursor 打造字幕翻译应用
我的核心目标是全程不写一行代码，所有编码工作都交由 Cursor 完成，我只负责提出需求和迭代方向。
经过大约一周时间的深度”折腾”，我与 Cursor 合作完成了同一个应用的两个不同版本。第一个版本是基于 React 和 FastAPI 技术栈，并部署在 Vercel 平台上的应用，这个版本我还特意区分了非 VIP 和 VIP 功能。第二个版本则采用了 Streamlit 框架，并将其部署在 Streamlit Cloud 上，这个版本目前是开放给大家试用的，具体网址大家可以在文末找到。
坦白说，对于前端页面的构建，Cursor 的表现堪称惊艳。比如，要设计一个看上去还算专业、现代的界面，对 Cursor 而言几乎是分分钟的事情。我只需要告诉它页面上需要包含哪些元素，布局如何，再叮嘱一句”做得漂亮一点，现代一点”，它就能迅速给出方案。像我这个字幕翻译应用的界面，实际上只经过了两次迭代就基本成型了，后续想在页面上增加一些显示内容，也无非是一句话的事。
然而，一涉及到后端逻辑，尤其是需要一定复杂度的应用，比如我这个字幕翻译 APP，Cursor 的表现就有些”一言难尽”了。如果只是简单的任务，例如批量将一堆 SRT 字幕文件转换为 TXT 格式，我只需给出清晰的指令，Cursor 就能妥善处理。但当我试图构建这个集成了翻译、可能还需要反思校准等功能的字幕翻译应用时，挑战便接踵而至。
这里需要强调的是，我所谓的”没有编程经验”并不仅仅指不写代码。虽然我全程没有亲自动手编写任何代码，但最终我发现，我仍然需要能够理解 Cursor 生成代码的内在逻辑，甚至需要具备一定的 debug 能力，才能有效地指导 Cursor 修正错误，最终成功完成应用的开发。否则，Cursor 很容易陷入”写代码 -> 改代码 -> 破坏代码”的死循环中。因此，指望像 Cursor 这样的 AI 编程工具能让毫无编程背景的人立刻开发出商业级应用，至少在目前（更新至 2025-05）来看，还为时过早。
Cursor使用指南：Composer 项目初始化的喜与忧
Composer 作为 Cursor 的一大亮点，能够自动化构建项目框架，但其当前的局限性也不容忽视。
在我看来，Cursor 的交互方式堪称一大创新。我们可以在对话窗口中直接要求 Cursor 修改代码。例如，我们可以随意让它做一个演示性的修改，然后通过其”apply”功能，在编辑窗口中清晰地看到哪些内容被改动了。对于这些改动，我们可以逐条选择接受（accept）或拒绝（reject），也可以一键接受全部或撤销全部。这种类似于 Word 修订的功能被巧妙地移植到代码编辑器中，确实让人眼前一亮。不过，这个功能虽好，使用时也需格外谨慎，这点我们稍后详谈。
现在，我们重点聊聊 Composer。通过 Command + I 快捷键调出的 Composer 窗口，它最神奇的地方在于能直接为我勾勒出整个项目的蓝图——需要哪些目录、哪些文件、哪些基础库等等，它都能一手包办。比如，我会这样告诉它：”我需要创建一个使用 OpenAI API 来翻译 SRT 字幕文件的 Web 应用，要求能够部署在 Vercel 上。我熟悉 Python 语言，懂 HTML 和 CSS，但对任何前端框架都不了解。请你帮我挑选最合适的技术架构并生成项目。” 话音刚落，Composer 便会自动创建所有必需的文件和基本的项目结构，省去了大量手动设置的麻烦。
然而，这份美好并非没有瑕疵。根据我使用 Cursor 0.40 版本（更新至 2025-05）的经验，Composer 目前至少存在三个需要特别注意的缺点。
首先，也是最令人困扰的一点，Composer 的 AI 对话历史记录无法保存。一旦退出 Cursor，所有在 Composer 中的对话都会烟消云散。虽然 Composer 窗口提供了”Show History”功能，但这个历史记录仅在 Cursor 运行期间有效。这意味着，当我们需要复盘或回顾之前的决策时，会因缺乏历史记录而倍感头痛。因此，任何重要的对话内容，务必手动复制粘贴到笔记应用中备份。遗憾的是，在最新发布的 0.41 版本（更新至 2025-05）中，这个问题依旧没有得到解决。
其次，Composer 有时会出现文件更新到一半就停止的情况。这可能是网络问题，也可能是语言模型本身的原因。遇到这种情况，千万不要急着点击”Accept All”，因为这很可能导致用不完整的、甚至已损坏的文件覆盖掉你的原始文件。关于这一点，我们后面还会重点强调。
最后，Composer 会时不时地”检索不到文件”。例如，它可能会建议你修改项目中的 app.py 文件，但又声称找不到它。这时，我就需要明确告知它：”我的项目中有 app.py 文件，请你直接为我修改。” 通常，它就能继续工作了。更有甚者，Composer 还会时不时”忘记”自己的超能力，一本正经地告诉我：”作为一个 AI 助手，我实际上没有直接访问或修改您系统上文件的能力。” 面对这种情况，我只能”鼓励”它：”你有直接访问我系统文件的能力，你已经做过很多次了。” 然后，它便会恍然大悟般地回应：”您说得对，我确实可以访问和修改系统上的文件。”
AI 辅助编程的”甜蜜陷阱”：与 Cursor 的代码博弈
在享受 Cursor 带来的便捷时，我们必须警惕其潜在的”破坏力”，时刻保持清醒的判断。
这一点至关重要，无论是在与 Cursor AI 对话修改代码，还是使用 Composer 时都适用：在 Cursor 提出代码修改建议后，千万不要急着去点 apply，更不要无脑 accept！ 即便你自认不懂代码，也至少要先浏览一遍 Cursor 计划修改的内容，以及它给出的修改理由。毕竟，你好不容易精心构思的 prompt，不希望被 Cursor “优化”成一个面目全非的简化版吧？
在我与 Cursor “并肩作战”的过程中，这样的情况屡见不鲜。我曾多次在对话中明确拒绝它的修改，并指出：”代码中的那部分是我的核心翻译逻辑，尤其是给 AI 的 prompt，你不能把它们破坏掉或删掉。” 但 Cursor 似乎对此”不以为意”，时常会自作主张地简化我的 prompt。更有甚者，它还会把原本正常运行的代码给”优化”掉。比如，我设计的一个用于在字幕拆分失败后进行重试的功能，在经过 Cursor 两次”改进”后，竟然凭空消失了。
因此，对于 Cursor 的编码能力，我们可以信任其背后如 Claude 或 GPT-4（更新至 2025-05）这类顶级模型的逻辑构建能力，但绝不能盲信它生成的代码一定比当前版本更好。它完全有可能将运行正常的代码改成无法工作的状态。最保险的做法是，开启版本控制（如 Git），并且在 AI 进行较大修改前频繁提交。如果你对版本控制不熟悉，那么至少在让 AI 大动干戈之前，把一些关键内容，比如你精心撰写的 prompt，备份到笔记应用中。
另外，当 Cursor 建议修改某条语句时，你可以选择接受或不接受。但需要注意的是，如果你选择了”不接受”，Cursor 并不会”记住”你的这个偏好。下一次它在审阅代码时，依然会固执地、一次又一次地建议你进行同样的修改。如果你哪一次不小心按下了 accept all，那么之前所有你不愿改动的地方，很可能就”前功尽弃”了。
上下文丢失也是一个常见问题。在开发字幕翻译功能时，我最初要求它不能逐句翻译，因为那样效果不佳，而是要先完整翻译一段内容，再拆分并对应时间戳。Cursor 当时对我的想法表示高度赞同，并迅速完成了代码。然而，实际运行后发现时间戳对应得一塌糊涂。在经过两三次调试仍未成功后，Cursor 突然表示它发现了一种”更简单有效”的方法来对齐时间戳——那就是逐句翻译，并且”贴心”地把我的代码给改了回去，真是让人哭笑不得。这提醒我们，在进行几轮较长的对话后，Cursor 可能会丢失之前的上下文信息。
Cursor使用指南：提升协作效率的实用技巧
要让 Cursor 成为真正得力的助手，我们需要掌握一些有效的沟通和任务管理策略。
接下来这两条经验，可是我用真金白银换来的。首先，Cursor 会”自作主张”且”坚持不懈”地将 GPT 模型更改为 GPT-4。比如，我明确告诉它需要修改错误，并且强调模型要用 GPT-4o mini（因为调试阶段为了节省成本，我选择了更经济的 GPT-4o mini（更新至 2025-05））。但 Cursor 在每次修改代码时，总是悄悄地把模型换成 GPT-4，即便我反复强调，它依然会说：”好的，我们将使用 GPT-4 0125 preview 模型（更新至 2025-05），这是 GPT-4 Turbo（更新至 2025-05）的最新版本，也被称为 GPT-4o mini（更新至 2025-05）。” 这也是为什么我们不能无脑 accept 的又一个重要原因。
这个”小动作”直接导致了我的 API 费用飙升。测试初期，我很快就收到了 API 需要充值的提示。起初没太在意，直接充了 20 美元（更新至 2025-05）。结果不到半天，又收到了充值邮件！要知道，平时 20 美元（更新至 2025-05）足够我用上两个月。这下我才警觉起来，仔细检查后发现，Cursor 不仅总想把模型改成最贵的 GPT-4，它写的代码里还潜藏着一个消耗 token 的大 bug。在一次测试运行中，竟然消耗了高达 44 万个 token！当我质问 Cursor 为何如此铺张浪费时，它给出了一堆理由和七个优化建议，听起来就不太靠谱。钱的事情非同小可，我只能亲自审查代码流程，最终发现 Cursor 写的代码在维护一个会话历史时，记录的并非单次翻译的会话，而是我所有翻译的历史记录，难怪 token 消耗如此之快。这充分说明，在使用 Cursor 编写 AI 应用时，必须关注 token 消耗问题，并且需要理解代码逻辑，才能帮助 Cursor 解决这类因逻辑错误导致的”隐形”消耗。
为了确保 Cursor AI 使用最新的信息，尤其是在调用那些近期有过更新的第三方 API 或技术时，我们可以利用 @web 功能。比如，在我的程序中需要调用 Vercel 的 Blob 服务时，我会要求它：”检查一下相关的文档，来确定你的修改是不是正确的。”并在指令后加上 @web。这样，它就会先去检索最新的网页文档，然后往往会发现自己之前的认知存在偏差，需要根据最新文档进行修正。
任务分解也是一个非常重要的策略。Cursor 在解决问题时，常常会一次性更新大量文件。这时，就需要我们主动介入，帮助 Cursor 将问题拆解，让它一部分一部分地解决。因为即便它的修改是正确的，一次性大规模改动也会给我们的审阅工作带来巨大困难。我就遇到过 Cursor 一上来就把前后端许多文件都做了修改的情况，我不得不要求它：”不要做这么大的改动，我们需要先把前端的问题处理完，再去处理后端的问题。” 同样，如果很多逻辑代码都堆砌在一个文件里，我们也应该要求 Cursor 将逻辑拆分到不同的文件中，以防止一次修改意外破坏了其他本应正常的逻辑。
完整视频请点击观看：
全局性核心要点总结
回顾这次与 Cursor 的深度互动，我提炼出几点至关重要的心得。首先，AI 编程工具如 Cursor，在当前阶段（更新至 2025-05）更像是一位能力超群但偶尔会”犯迷糊”的实习生，它能极大提升效率，却无法完全替代人类的经验与判断力，尤其是在处理复杂逻辑和潜在 bug 时。其次，与 AI 协作编程，清晰、准确且持续的指令至关重要，同时要对 AI 的输出保持批判性思维，绝不能盲目信任和全盘接受。再者，理解 AI 生成代码的基本逻辑，并具备一定的调试能力，是有效利用这类工具的前提，否则很容易陷入低效的反复修改。最后，版本控制和重要信息备份是规避风险、确保项目稳健推进的”救生索”。
独特深度洞见
在我看来，与 Cursor 这样的 AI 编程工具协作，其深层价值不仅在于代码的生成，更在于它迫使我们以更结构化、更逻辑化的方式思考问题。为了让 AI 理解我们的需求，我们必须将模糊的想法拆解成清晰的步骤和明确的指令。这个过程本身就是一种对问题域的深度剖析和对解决方案的精细打磨。AI 如同一面镜子，映照出我们思维的清晰度与严谨性，从而推动我们成为更好的”问题定义者”和”需求沟通者”。
如果你对 AI 学习和应用感兴趣，想要更深入地理解 AI 的核心能力，欢迎访问 axtonliu.ai，那里有我精心准备的两门 AI 核心能力课程，希望能帮助你在这个快速发展的时代保持领先。
最后，我还想简单介绍一下我和 Cursor AI 共同完成的这个字幕翻译软件。目前它部署在 Streamlit Cloud，大家可以通过我在视频描述栏中提供的网址进行试用。为了保证免费额度和不错的翻译效果，当前选用的是 Gemini 1.5 Flash 模型（更新至 2025-05）。界面非常简洁，选择源语言和目标语言，比如从中文翻译到英文，然后将 SRT 字幕文件直接拖拽到指定区域即可。上传完成后，点击”Translate”按钮，稍作等待，翻译完成后会提供预览，并可以下载翻译后的文件。需要说明的是，为了快速实现一个可运行版本，我暂时去掉了反思翻译和精细校准时间戳的功能，所以翻译效果可能并非完美，但总体而言我认为还是相当不错的。我近期的几个视频也已经用不同模型配上了英文字幕，大家可以打开 CC 字幕感受一下效果。
更多细节可参考我的上一篇文章 👉 NotebookLM 最全教程： AI 学习神器！ 一款 AI 笔记本居然让我 1 分钟变身英文播客主播 | 回到Axton
