AI编程实战：10分钟用Cursor和DeepSeek打造翻译软件

1. 开篇：从“不会前端”到“10分钟做出翻译软件”

我平时主要跟后端逻辑打交道，前端代码属于那种“看得懂、写不来”的水平。以前想做个小工具，一想到要先搭环境、再搞UI，最后还要处理各种兼容性问题，就干脆放弃了。直到最近把 AI 编程工具真正用进日常开发，事情才起了变化——上周末我花了一晚上，从零做出了一个能用的翻译软件，从有想法到能跑起来，前后不到 10 分钟。这篇文章就是把那次实战的完整过程、踩过的坑和我对 AI 编程这件事的想法，一次性讲清楚。

先说这个项目是什么：一个本地运行的 Web 翻译工具，支持粘贴长文本翻译、上传文件翻译、双语对照展示。核心技术栈非常朴素——前端就是一个 HTML 页面加原生 JavaScript，后端用 Python 写了一个几十行的代理服务，翻译能力对接的是大模型 API 的 DeepSeek 接口（支持 OpenAI 兼容格式，直接 curl 就能调）。整个过程用 AI 编程助手完成，我再强调一次：我本人没有手写过任何一段完整的核心逻辑，所有代码都是“我描述需求 + AI 生成代码 + 我改参数”这样磨出来的。

这东西适合谁参考？两类人。一类是完全零基础、想试试 AI 编程的新手，跟着文章走一遍，你会明白 AI 编程不是玄学，它就是“提需求、看输出、改问题”的循环。另一类是已经用 AI 写代码但效率不高的人，这 10 分钟的拆解里，有大量的提示词写法、工具选型和调试技巧，能从“AI 能写代码”升级到“AI 写代码又快又稳”。

下面我按实战顺序来拆，重点讲清楚每个选择背后的原因，不是让你照抄，而是让你知道为什么这么做。

2. 项目设计与技术选型思路

做任何工具类项目，第一件事不是写代码，而是想清楚这三个问题：给谁用、解决什么问题、在什么环境跑。我的应用场景非常具体：平时读英文技术文档、审阅外文邮件，在浏览器里选中一段文字翻译，或者把整篇文档丢进工具里快速翻译。这个场景决定了我的选型必须满足三个条件——跨平台、零部署成本、可离线使用。

2.1 为什么选“HTML 前端 + Python 后端代理”

一开始我考虑过直接用浏览器里的在线翻译接口，但很快否掉了。一是质量不稳定，术语翻译经常乱来；二是没有网页 UI 的情况下，长文本体验很差。后来我决定自己接大模型 API 来翻译，这样质量有保障，还能自定义翻译风格。

于是架构就清晰了：一个前端页面负责 UI 展示，一个后端小服务转发请求。为什么中间要多一层后端？两个原因：第一，大模型 API 的密钥如果直接暴露在前端，任何人拿到网页源码就能看得到，等于把自己的额度送人。第二，浏览器有跨域限制，直接从前端调 API 会遇到 CORS 拦截，而本地后端代理天然没有这个问题。用 Python 的http.server模块写这个代理，几十行代码就够了，不需要引入 Flask、FastAPI 这些框架，因为需求真的只有一个：接收前端 POST 请求，转发到大模型接口，再把结果返回。

前端也用不着 Vue、React 这一套，一个纯 HTML 文件 + 原生 JavaScript 就能做完整的交互界面。没有打包构建流程，双击就能打开，后期分发给别人用也极其省事——把index.html和后端脚本放到同一目录，运行后端脚本后浏览器直接访问即可。

2.2 翻译引擎的选择标准

翻译引擎是这个项目的核心，我梳理了几个硬性标准：

综合对比后我选择了 DeepSeek API。原因很实际：它是国内直连可用的服务，不需要额外的网络配置；兼容 OpenAI 的/chat/completions接口格式，参考文档成熟；价格便宜到几乎可以忽略——我手边一份大约 5000 字的文档翻译下来，成本只有几分钱。如果你手上有其他的大模型 API，比如通义千问、智谱 GLM，原理完全一样，只是接口地址和模型名称不同，照着修改即可。

2.3 流式输出还是等待完整返回

初次调试时，我遇到一个体验问题：翻译一篇 3000 字的文档，等待时间大约 15 秒到 1 分钟，期间前端页面一片空白，用户完全不知道系统有没有在工作。解决方式是采用流式输出（SSE），让翻译结果像打字机一样逐字蹦出来。

流式输出的原理不复杂：大模型 API 支持stream: true参数，服务端会通过 SSE 格式不断推送增量内容，前端用EventSource或fetch的ReadableStream监听，每收到一段内容就追加到页面上。这个能力在 AI 编程普及之前自己实现还挺麻烦，但在 AI 编程助手的帮助下，只需要一句描述：“用流式输出显示翻译结果，效果要像打字机一样”，它就给你生成完整的解析代码。

3. AI 编程工具选型：四个“神队友”的实战对比

既然要分享 AI 编程实战，工具选择绕不开。最近“AI 编程助手大比拼：Cursor、Windsurf、VS Code Copilot 和 Trae，谁才是神队友”这个话题特别火，这次实战我把自己常用的几个工具都试了一圈，说点真实感受。

3.1 Cursor：全能型选手，我的主力选择

Cursor 是目前综合体验最好的 AI 编程 IDE。它最大的优势是深度理解整个项目的上下文——不是简单看你当前打开的文件，而是能阅读项目目录结构、相关引用文件，回答“这个报错可能在哪里产生”这类跨文件问题。我这次翻译软件的开发在 Cursor 里完成，体验相当流畅。

它的 Tab 补全能干到多夸张？我在调后端代理的 JSON 解析时，批注里写到“处理 response 里 choices[0].message.content 可能为空的情况”，它直接补全了空值判断、默认值设置、错误日志三行代码。这类“代码生成 + 逻辑补全”的组合能力，是传统 IDE 的自动补全完全无法比的。用 Tab 接受它的补全，速度比手动写代码快出好几倍。

3.2 Windsurf：精于理解意图，但引导成本稍高

Windsurf 的亮点是 Cascade 模式，它在“理解你的意图”上表现比较突出。我测试同一个需求——让它生成一个带深色主题的翻译界面——它给出的结果比 Cursor 更贴合审美，会自动处理间距、圆角、hover 效果这些细节。

但我的体感是 Windsurf 更依赖你把它“喂饱”。如果你描述含糊，它生成的东西会偏离方向。适合那种喜欢先详细写设计文档、再让 AI 实现的开发者。如果你习惯边写边改、即时反馈，Windsurf 不如 Cursor 顺手。

3.3 VS Code Copilot：老牌选手，简单任务效率极高

Copilot 的优势是集成在 VS Code 里，不需要切换 IDE，对日常开发干扰最小。它擅长内联补全和当前文件的修改，但多文件、跨模块的改造能力明显弱于 Cursor。在我这个项目里，它帮我写单个函数、调样式很利索，但让它“把整个代码重构为支持批量翻译的版本”，它就有点力不从心了。

适合人群很清楚：已有完整 VS Code 生态、不想换 IDE，且任务是局部修改而非从零搭建项目。

3.4 Trae：界面漂亮，但生态还在成长

Trae 的界面设计很现代，集成度也不错。但我这次实测时发现它的自动补全偶发性失效，有时同一句话重复触发也不给任何输出，需要重启 IDE。它目前适合尝鲜和小项目，做稍微复杂的项目容易卡壳，尤其处理长上下文时会显得迟钝。期待它后续版本优化。

3.5 “谁才是神队友”的结论

四个工具我轮流用了小半个月，最终结论是：没有“最强”，只有“最合适”。如果你主要在 IDE 内写代码、目标明确、改动范围可控，Copilot 够用；如果你从零搭建项目、需要 AI 深度理解整体结构、频繁跨文件修改，Cursor 体验最好；Windsurf 适合需求明确、愿意花时间写清 prompt 的开发者；Trae 建议等下一代版本。我最终全程使用 Cursor 完成的本次实战项目。

4. 10分钟实战拆解：从需求到能跑的翻译软件

现在进入正题。我按时间线把这次开发分成四个阶段，每段标注用时和关键操作，你可以完完整整复现一遍。

4.1 阶段一：说清需求，打好第一个 Prompt（约 2 分钟）

AI 编程最核心的技巧不是写代码，而是描述需求。第一次用 AI 编程的人最容易犯的错是丢一句话“帮我做个翻译软件”，然后抱怨 AI 生成的代码乱七八糟。实际上这不是 AI 笨，是你没说清。

我在 Cursor 里写下第一个提示词，结构是这样拆的：

请帮我搭建一个本地翻译工具的完整项目，包含以下部分： 1. 后端：使用 Python 标准库编写 HTTP 服务，监听 8000 端口，提供 POST /api/translate 接口，接收 JSON 格式 {"text": "需要翻译的内容"}，调用 OpenAI 兼容格式的大模型接口， 模型选择 deepseek-chat，temperature 设置为 0.2，返回翻译结果。 2. 前端：一个 index.html 文件，包含文本框（输入原文）、按钮（翻译）、结果区域（输出译文）， ]]布局清晰，支持长文本滚动。 3. 接口密钥从环境变量 DEEPSEEK_API_KEY 读取，不要硬编码在代码里。 4. 项目要用流式输出，译文像打字机一样逐渐显示。

这个提示词的核心是“四要素”：做什么、怎么做、约束是什么、效果什么样。不要吝啬细节——模型、接口格式、端口、展示方式，全部写出来。AI 编程工具生成代码的质量，与你的提示词细节呈正相关。

约 2 分钟后，Cursor 生成了完整的项目骨架：server.py和index.html。目录结构如下：

translator/ ├── server.py # 后端代理与流式转发 └── index.html # 前端 UI

4.2 阶段二：迭代调优核心翻译逻辑（约 3 分钟）

首版代码能跑，但界面很简陋，翻译长文本时偶尔报错。我继续用自然语言提修改需求：“在原文和译文两侧加入对照滚动；当输入文本超过 2000 字时，自动分片请求并在全部完成后拼接。”AI 几秒内完成了对应修改。

这里有个关键技巧：给 AI 看真实的运行结果。报错信息、控制台日志、页面截图，直接粘贴给它，它基本能准确定位问题。有一次后端返回 502，我把完整报错贴过去，它立刻意识到是超时时间设置太短，自动把超时时间调长并加了重试逻辑。AI 编程的调试循环本质上就是“人工做集成测试，AI 负责修代码”，分工会让我非常省心。

为了让你理解核心逻辑，我把后端最关键的一段代码贴出来并逐行拆解。

# server.py 核心处理逻辑（由 AI 生成，我做了参数调整） import json, os, urllib.request DEEPSEEK_API_KEY = os.environ.get("DEEPSEEK_API_KEY") API_URL = "https://api.deepseek.com/chat/completions" def translate(text): prompt = f"翻译以下内容为简体中文，保持原有格式、代码块和换行：\n\n{text}" payload = { "model": "deepseek-chat", "messages": [ {"role": "system", "content": "你是一位专业翻译，精通中英文互译，尤其擅长技术文档。"}, {"role": "user", "content": prompt} ], "temperature": 0.2, # 低温度保证翻译一致性，避免随意发挥 "stream": True # 开启流式输出 } req = urllib.request.Request( API_URL, data=json.dumps(payload).encode(), headers={ "Content-Type": "application/json", "Authorization": f"Bearer {DEEPSEEK_API_KEY}" } ) # 后续处理 SSE 流并逐行返回增量内容

这里有个细节值得解释：temperature 参数为什么设置成 0.2？翻译场景需要的是稳定、忠实原文的产出，而不是创造性发挥。temperature 越高，模型输出越发散，可能会换词、改写甚至漏译；设置低值能锁定表达方式，确保同一术语全文翻译一致。

前端核心则是监听流式响应：

// index.html 中的流式渲染逻辑 async function handleTranslate() { const text = document.getElementById("inputText").value; const response = await fetch("/api/translate", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ text }), }); // 读取流式返回，边读边显示 const reader = response.body.getReader(); const decoder = new TextDecoder("utf-8"); let result = ""; while (true) { const { done, value } = await reader.read(); if (done) break; result += decoder.decode(value, { stream: true }); document.getElementById("outputText").innerText = result; } }

这段逻辑实现了关键词要的“打字机效果”：每拿到一片增量文本就立刻渲染到页面上，长文本翻译不再是无反馈的等待。

4.3 阶段三：打磨 UI 细节（约 3 分钟）

我用一句话继续优化界面：“仿照在线文档编辑器的布局，头部放工具名，主体是左右两栏对照，底部放状态提示，整体用简约风格。”AI 给出了完整 CSS，包括响应式布局、护眼背景色、按钮悬浮效果等。

期间遇到一个问题：页面在宽屏下两侧太宽，窄屏下挤在一起。我告诉 AI“加入栅格布局，宽度小于 800px 时上下堆叠”，它立刻补上了媒体查询。整个过程我没有打开 CSS 属性表查过一个值。这就是 AI 编程对非前端开发者的价值——把设计稿转成代码的过程被完全压缩掉了。

4.4 阶段四：联调、测试、收尾（约 2 分钟）

最后是跑通全流程：设置环境变量DEEPSEEK_API_KEY，启动后端服务，浏览器打开页面，粘贴测试文本，点击翻译。

顺手还加了两个实用功能：清空按钮和示例文本按钮，用于快速验证。全部完成后，我做了 5 组翻译质量测试——英译中技术文档、中译英邮件、带格式的 Markdown 文本、纯文本长文、代码注释翻译，质量都过关，特别是术语一致性表现优于我预期。

时间汇总：

5. 核心难点拆解与避坑指南

10 分钟做成一个翻译软件，听起来轻松，实际上有几个隐蔽的坑。不懂原理的话，随便踩一个就足够让你卡半小时。

5.1 API Key 保护：千万不要硬编码在前端

很多第一次玩 API 的人，图省事直接把 key 写进前端 JavaScript。这个操作的危险程度相当于把银行卡密码贴在门上——任何打开网页源码的人都能看到你的 key，并盗刷你的额度。

正确做法是交给后端使用环境变量。Cursor 生成的代码里，默认就是os.environ.get("DEEPSEEK_API_KEY")，不会写死。运行前在命令行设置好：Windows 用set DEEPSEEK_API_KEY=你的key，macOS 和 Linux 用export DEEPSEEK_API_KEY=你的key。如果你不希望每次开终端都重新设置，可以写一个.env文件并加一行读取代码，AI 编程助手可以直接帮你生成读取.env的模块。

5.2 长文本分片策略：不能一封到底

大模型 API 对单次请求的 token 数量有上限，一次翻译 8000 字的长文一定会报错。我的分片策略是：按字符数切块，每块控制在 1500 字以内，逐块请求翻译，最后合并输出。

但简单按字符硬切有个副作用——可能从段落中间切断，导致译文上下文不连贯。我让 AI 加了一个“智能断点”：优先在段落结尾、句号、换行符附近切分。实测下来效果立竿见影，即使每片独立翻译，合并后的文章也基本没有断裂感。

不要轻易用“循环遍历分片相互独立”的方案，有些大模型在翻译带 Markdown 格式的长文档时，前一板块结尾和后一板块开头的格式会不统一。建议让 AI 在提示词里写明：“保持原有 Markdown 格式，不要增加多余标题”。这是我在第一批测试时踩到的坑，改了一行提示词后问题彻底消失。

5.3 SSE 流式解析：小心半个字符

流式输出的数据是分块到达的，后端在转发时如果处理不当，可能出现“半个字符”问题——一个 UTF-8 编码的中文字符被截在两次网络包之间，解析时直接乱码。AI 生成的代码中，我特意检查了这块逻辑，后端用TextDecoder("utf-8", { fatal: false })，前端用decoder.decode(value, { stream: true })保留未完成的字节，确保不会出现半个字符的拼接错误。

这个细节新手几乎不会注意到，但表现很突出——你会看到译文中有随机出现的一个“�”字。如果出现这个现象，优先检查文本解码逻辑。

5.4 翻译质量不稳？先调 temperature，再调提示词

如果译文风格不稳定，比如同样的术语有时候翻成“接口”有时候翻成“端口”，第一反应不要改代码，而是调节 temperature 参数。翻译场景建议保持在 0.1 到 0.3 之间，不要超过 0.5。其次，在 system prompt 里加上术语约束，比如“将 API 统一翻译为‘接口’，不要使用音译”。

我做了一组对照测试，同一句话在 temperature=0.2 和 temperature=1.0 下输出明显不同。前者稳定但略显机械，后者灵活但有概率漏词。翻译工具追求忠实，低 temperature 是正确选择。9. 常见问题速查表与现场实录

实战过程中我记录了 6 个高频问题，整理成表格，方便你对照排查：

第 6 个问题在测试时真实发生过：我手机上想试用这个工具，但怎么都连不上笔记本上的服务。后来才发现，http.server默认只监听127.0.0.1，外部设备无法访问。改成0.0.0.0后解决，同时要注意绑定后服务暴露在局域网内，不要在不信任的网络环境开启。

6. AI 编程的本质思考：它到底是“工具”还是“队友”

最后聊点体会。这次 10 分钟项目做完后，我对热词“AI 编程”有了更具体的理解。过去很多人担心“AI 编程会取代程序员”，但我实际用下来，感觉更像给每个程序员配了一个反应快、知识面广但必须由你拿主意的实习生。

你需要做的不是一句命令甩过去然后干等，而是像带新人一样说清楚上下文、边界条件、预期效果。你的判断力决定产出质量——比如我坚持让它在后端代理 API 而不是前端直连，这个决定 AI 不会替你做；我要求低 temperature 保证翻译稳定，这个参数选择 AI 也不会主动优化。AI 提升的是“码代码”的速度，而“定方案、做取舍”这件事，责任永远在开发者身上。

6.1 关于“提示词”的一点真心话

网上有很多“万能提示词模板”，照着抄就行。我的真实体验是：模板只有参考价值，真正好用的话都是结合项目现状写出来的。最有效的提示词往往包含当前报错的信息、你的判断、你试过哪些方法。比如下面这个修改请求：

当前 /api/translate 返回的 JSON 中，偶尔会出现 content 字段为 null 的情况， 我怀疑是模型返回内容被截断。请在代码里增加空值兜底逻辑， 并在截断时打印日志，提示我检查分片长度。

这样的提示词，比“优化一下翻译接口”有效十倍。因为它给了 AI 可用的上下文：现状、猜测、期望的行为。写提示词翻译成一句话就是：想办法把“你知道但 AI 不知道的信息”尽可能说清楚。

6.2 免费工具和收费工具体验差异

试用了一圈之后，补充一个关于“免费的 AI 编程工具”的观察。免费方案（比如 Copilot 的免费层、Trae 的免费额度）应对简单任务足够，但遇到多文件项目、复杂重构时，额度消耗快、响应质量也打折扣。我的建议是：日常小需求用免费版没问题，正式项目值当投入——省下的时间远超订阅费。工具越贵，越要让它干活，别让它吃灰。

6.3 项目后续可以怎么扩展

这个翻译软件的改进空间还很大，我列出几个我能想到的方向，也给你们留个思考空间：

一是增加术语表上传功能，让翻译结果强制遵循特定术语，适合专业领域；二是支持批量文件翻译，拖拽文件夹进来递归处理；三是加入语言自动检测，不用手动指定源语言和目标语言；四是打包成桌面应用，通过 Electron 套一层壳，做到双击即用，无需手动启动后端服务。

我现在最推荐先做第四项，因为每次使用先敲命令行很影响体验。AI 编程时代，产品迭代的速度被大幅加快，想到什么就去做，做完发现效果不差，这种正反馈会推着你不断往下走。

最后分享一个我个人真实的体会：10 分钟做一个翻译软件，看起来像是秀效率，实际上这 10 分钟背后是我对“需求拆解、接口对接、参数调优、异常处理”这些基础功底的积累。AI 编程并没有让这些能力变得不重要，相反，正因为 AI 能快速执行，我的判断力才更需要跟得上它的速度。如果你还没尝试过 AI 编程，别犹豫，找个周末选个小工具试试，先跑起来，再跑好，你会打开一扇新的门。