写提示词的功夫，代码都写出来了，还有必要用 AI 编程吗？

写提示词的功夫，代码都写出来了，还有必要用 AI 编程吗？

在使用 AI 编程时，我最常用到的是所谓的“Composer”功能。Composer 本来是 AI 编辑器 Cursor 的一个功能，通过在输入框中输入自然语言描述，引用上下文，编辑器会自动生成代码，并应用到相应的代码文件中。Composer 虽然是一个 AI 编辑器功能，但也可以借助其他 LLM 的聊天界面来实现，只是要有一些手动的复制粘贴操作，其实结果是一样的。

用好 Composer 的关键是要给 AI 足够的上下文（例如参考或引用的代码），描述清楚要实现的功能、逻辑以及输入和输出，让 AI 帮我生成对应的模块化代码。不过，我发现不少经验丰富的程序员对在编辑器中使用 Composer 的兴趣并不大。理由在于，如果要写一个实现模块的 Prompt，那么在他们看来，直接写出那部分代码可能耗时差不多，甚至更快。于是就觉得“何必何必脱裤子放屁多此一举呢？”

究竟有没有必要用自然语言 Prompt？

对于一些小功能或者你非常熟悉的代码模块，直接手写确实更快更直接；但在相当多的场景下，充分利用 Composer 所带来的高效性仍有巨大价值。尤其是当功能比较复杂、对某些库或框架不熟悉，或希望在开发初期快速验证思路时，“给足上下文+自然语言描述”往往能带来更快的产出和更好的扩展性。

一个具体场景：自动替换图片链接

下面我想以一个真实案例，展示一下 AI Composer 带来的效率优势。我的博客网站会翻译很多文章，有时文章中的插图由于外链原因，无法直接引用，需要手动下载后再重新上传到我自己的存储空间。虽然一篇文章的插图并不算多，但每次都要手动做这些重复操作，积累下来还是挺费劲的。

因此，我希望给后台增加一个自动化功能：

  1. 从文章中找到所有外链图片；

  2. 将它们批量下载并上传到我的存储空间；

  3. 最后替换原文章中的外链地址。

为什么不直接手写代码？

这个功能并不算很难，也不需要太多开发经验就能实现。简单来说，就是把编辑器中的所有图片找出来，逐个下载后上传，再把链接逐一替换。不过，这里我用的编辑器是 TipTap，我对它的 API 并不是十分熟悉，而且涉及到上传接口与文件名去重等繁琐逻辑，所以从无到有地手写代码可能需要边查文档边试错，也得花不少时间。

借助 AI Composer 的思路

但借助 AI 编程就不一样了，同样可以是自然语言描述，但是不需要关心太多细节。以前我在分享 AI 编程经验时，通常会建议每一次只实现一个小的独立的模块，这样结果会更好，所以我把这个功能拆分成了两个模块：

  1. 后端：实现一个新的下载并保存图片的 API 接口；

  2. 前端：在 TipTap 编辑器中遍历所有图片，并调用后端接口进行下载、替换，同时做一个简单的进度条显示上传状态。

后端 API 的实现

后端部分其实已经有一个“上传图片”的 API，可以用来参考和复用。我的思路是，把已存在的上传图片接口代码贴给 AI，并在 Prompt 中让它基于这段参考代码生成一个新的下载并上传的接口。

例如，我会告诉 AI：

  • 新增一个 endpoint：/api/download-and-save-image

  • 传入一个图片 URL，下载后保存到对象存储（R2）

  • 文件命名规则为“日期 + 原始文件名”，若重名则依次加数字后缀

  • 返回新的图片 URL

在 Prompt 中，我还会引用已有的 /api/upload-image 代码，帮助 AI 理解当前项目的结构和风格。这样，AI 就能很快根据现有的上传逻辑生成一个下载并上传的接口代码，甚至还能帮助把公共部分提炼成可复用的工具函数，方便后续维护和扩展。

前端组件的实现

后端接口就绪后，前端就可以愉快地配合使用了。我会告诉 AI，前端使用 React + TypeScript + ShadcnUI，编辑器使用 TipTap，接下来希望它帮忙生成一个组件，包含以下功能：

  1. 一个按钮 + 进度条或提示信息；

  2. 点击按钮时，遍历编辑器中的所有图片（editor.getJSON()），过滤出以 http:// 或 https:// 开头的链接；

  3. 调用刚才新建的后端接口批量下载和上传图片；

  4. 将上传成功的图片链接替换回编辑器，同时更新进度条。

Prompt 中，我会附上后端接口的请求与响应格式，主要包含：

  • POST 方法，Body 中是 { url: string }

  • 成功时返回新图片的地址；

  • 失败时返回错误信息。

基于这些信息，AI 可以自动生成相对完整、可直接拿来测试的前端组件代码，一次性就能把后台下载、上传、替换操作都整合进去。很多时候，你甚至能在这个过程中发现一些隐藏的逻辑问题，然后在 Prompt 中再补充或修改，AI 很快就会给出更新后的代码。

为什么用自然语言写 Prompt 而不是直接写代码？

很多程序员排斥自然语言写提示词，觉得用代码逻辑直接表达更精准，也不会有歧义。但实际上，自然语言也有它的优势：

  1. 更通用、更灵活
    自然语言虽然看似含糊，但如果上下文给得足，AI 就能生成完整的代码实现。而且对于跨语言、跨框架的需求，或在你并不熟悉的领域里，自然语言可以让你快速表达想做的事情，不用去纠结具体的语法或第三方库的写法。

  2. 不需要过度精确，也能逐步完善
    你并不需要在第一版 Prompt 里就写到每一个细节。写完第一轮后，AI 生成的代码可能与你的期望有一定差距，你可以继续补充或修正。如此迭代几次，最终往往能得到满意的结果。

  3. 可以写出超出自身水平的代码
    借助现有的参考代码和 AI 的知识库，你往往能生成一些你原本不太熟悉领域的实现方法。在这个过程中还能提升自己的技能，学到新东西。

  4. 心智负担更小，便于高维度思考
    直接去写业务逻辑细节，有时会让你陷入繁琐的编码细节，而忽略了整体架构。而用自然语言描述需求时，你更容易关注更大范围的问题：数据结构如何设计？模块间关系如何抽象？如此也能让你从更高层面来审视代码结构和业务流程。

  5. 更容易复用与修改
    Prompt 本质上就是对功能需求的系统化描述，你可以很方便地在后续迭代中做调整，而不必一行一行地找代码、改代码。

哪些场景适合用 AI Composer？

  • 重构代码：通过提示词让 AI 帮你把旧的冗余代码拆分、重组，更清晰。

  • 写测试：很多重复性测试逻辑，可以让 AI 依据功能需求自动生成。

  • 写 UI：常见的按钮、表单、弹窗等组件，可以让 AI 先搭建框架结构，再根据需要微调。

  • 跨语言或跨端编程：前端工程师需要写后端代码，或后端工程师需要做前端页面时，Composer 可以帮助减少查文档的时间。

总结

用自然语言给 AI 编程，确实比直接写代码多了一步“描述需求”的过程，看上去似乎“麻烦”，但当你的需求场景复杂或涉及不熟悉的框架/API 时，这种方法常常能为你省去查文档、调试和思考细节的时间。更重要的是，你会在与 AI 的对话中收获新的思路和更好的架构设计。

如果你还没尝试过这种工作方式，不妨花点时间试试。给 AI 足够的上下文，再用自然语言把自己想做的事情说清楚，看看它能帮你完成多少工作。也许初次尝试时，你会觉得还不够完美，但随着不断迭代和完善 Prompt，你会发现 Composer 不仅能减轻繁琐编码负担，也会在不经意间拓展你的技术边界。

祝你在 AI 编程之路上有所收获！

See all posts