我用 FastAPI + Vue3 + LangChain，从零到一肝了个 AI 提示词优化器（附源码）-CSDN博客

本文链接：https://blog.csdn.net/qq_22017479/article/details/148826423

如果你也玩 AI，肯定听过一句话：“垃圾进，垃圾出”（Garbage In, Garbage Out）。这话太真实了。即使是 GPT-4、Claude 这种顶级大模型，你喂给它的提示词（Prompt）要是含糊不清，它吐出来的东西也基本没法看。我们心里明明知道想要什么，但就是不知道怎么跟 AI “说人话”，或者说，不知道怎么用它能听懂的“魔法咒语”来表达。

这个“提示词工程”的门槛，拦住了不少想把 AI 用好的人。我自己也深受其苦，于是萌生了一个想法：能不能做一个工具，帮我们把“大白话”翻译成 AI 爱听的“精确指令”？

这就是“AI 提示词优化器”这个开源项目的由来。所以，这篇文章，我想跟你完整地拆解一下这个项目从零到一的全过程，聊聊我的设计思路、技术选型、核心代码，当然还有未来的“野心”。希望能给同样在探索 LLM 应用的你一些启发。

一、灵感与初心：为什么要做一个提示词优化器？

为什么要做这个东西？说白了，就是看不惯现在很多提示词工具的“傻”。它们要么给你一堆模板让你套，要么就是简单粗暴地帮你改写几个词。但这些工具都回避了最核心的问题：我们作为用户，压根不知道 AI 到底需要哪些信息才能干出漂亮的活儿！

举个例子，你想让 AI 帮你写篇关于“人工智能在医疗领域的应用”的文章。你可能就只扔给它这么一句话。但 AI 心里苦啊，它会想：哥们，你这文章是给谁看的？科普还是论文？要不要提一提具体的案例？是聊技术还是聊伦理？你不说，它只能瞎猜，最后给你的多半是一篇泛泛而谈的空话。

所以我的想法很简单：好的提示词优化，不该是单向的“机器改写”，而应该是双向的“启发式对话”。这个优化器不会自作主张地帮你“润色”，而是会像一个聪明的助手一样，反过来问你问题，帮你挖掘那些被忽略的关键信息。

它会根据你最初的提示词，智能地生成一连串问题来引导你补充细节。你回答完这些问题，它再把这些信息“编织”进你的原始提示词里，最后生成一个信息量爆棚、精准无比的“超级提示词”。

这种模式，一下子就把提示词工程的门槛给拉下来了。你不需要懂什么复杂的技巧，就像跟人聊天一样，一问一答就行。这样不仅提示词质量上去了，AI 的输出也更靠谱了，真正做到了“好提示，好东西”。

二、项目概览：它是什么，能做什么？

“AI 提示词优化器”就是一个通过交互式问答，帮你把提示词打磨得更好的小工具。目前它还是个 MVP（最小可行产品），功能很专一，界面也力求简洁。

核心功能亮点：

交互式优化流程： 这绝对是灵魂。你给个想法，它提问题，你来回答，一步步把提示词喂饱。
多步骤优化： 不是一锤子买卖，通过几轮问答，确保关键信息不遗漏。
多模型支持： 后端设计得很灵活，想接 OpenAI 的 GPT，还是 Anthropic 的 Claude，或者其他兼容模型，都没问题。
纯 API 架构： 前后端分离，所有优化逻辑都封装在后端 API 里，方便以后扩展或被其他应用集成。
响应式前端界面： Vue.js 3 写的界面，在电脑和手机上看起来都很舒服，交互流畅。
解耦的提示词管理： 所有给 AI 下指令的系统提示词（System Prompt）都存在单独的文件里，想改 AI 的人设或任务，直接改文件就行，不用动代码。
模型配置动态加载： 通过一个 JSON 文件来管理支持的 AI 模型，增删改查都动态生效，告别硬编码。

关于 MVP 的定位：

说白了，目前这还是个 MVP，核心是验证“交互式优化”这个想法能不能跑通。它已经能提供一个完整的端到端体验了。当然，像会话保存、用户登录、高并发这些生产级的功能，暂时还没做，但它已经为后续的迭代打下了坚实的基础。

三、架构设计与技术选型

一个靠谱的系统，离不开合理的架构和明智的技术选型。我从一开始就定了前后端分离的原则，下面聊聊我选的这些“兵器”以及为什么选它们。

系统架构图：

数据流是这样的：

用户在前端输入原始提示词，点一下按钮，请求就发到后端了。
后端 FastAPI 接到请求，把它扔给 LangChain 工作流处理。
LangChain 工作流判断一下，是该提问题呢，还是该做总结了。
- 如果觉得信息不够，就调用“问题生成模块”，让 AI 想几个问题出来。
- 这些问题通过 API 返回给前端，展示给用户。
用户在前端回答问题，答案又通过 API 发回后端。
等信息收集得差不多了，“提示词优化模块”就把原始提示词和所有问答整合起来，再请 AI 出手，生成最终的优化版提示词。
优化后的提示词返回给前端，大功告成！
整个过程里，大模型（LLM）是核心大脑，提问题和做优化都靠它。

技术栈选型理由：

后端：FastAPI
- 为什么选它？
  - 快，就一个字： 基于 Starlette 和 Pydantic，天生异步，性能猛得一塌糊涂。对于我们这种需要频繁和外部 AI API 打交道的应用来说，性能就是生命线。
  - 天生异步： Python 的 async/await 在 FastAPI 里用起来丝般顺滑，处理网络 I/O 这种耗时操作简直是绝配。
  - 自带 Pydantic： 用 Pydantic 定义数据模型，API 的请求和响应数据验证、序列化、文档生成全自动搞定，代码又健壮又省心。
  - 自动生成文档： 写完 API，Swagger UI 和 ReDoc 文档自动就有了，联调、测试、给别人看都方便得不行。
  - 开发体验好： 语法简洁，写起来非常爽。
- 为什么不用 Flask 或 Django？
  - Flask： 轻量是轻量，但原生异步支持没 FastAPI 那么彻底，想实现类似的数据验证和文档功能得自己拼装一堆库，有点折腾。
  - Django： 太重了！ORM、Admin 后台……功能是全，但对我们这个纯 API 项目来说，简直是杀鸡用牛刀，引入了太多不必要的复杂性。
前端：Vue.js 3
- 为什么选它？
  - 组合式 API (Composition API)： 这是 Vue 3 的大杀器。组织和复用逻辑代码变得异常灵活，特别适合处理复杂的交互逻辑，代码清晰度和可维护性直接拉满。
  - Vite 的加持： 官方推荐的构建工具 Vite，开发服务器秒开，热更新快到飞起，开发体验一个字：爽！
  - 上手快： Vue 的学习曲线相对平缓，非常适合快速开发 MVP。
  - 响应式系统： Vue 3 的响应式系统既高效又直观，状态管理写起来很自然。
- 和 React 比呢？
  - React 当然也很牛，生态庞大。选 Vue 3 更多是个人偏好，我特别喜欢组合式 API 的写法。感觉 Vue 的语法对新手更友好一些，而组合式 API 提供了和 React Hooks 掰手腕的能力。对这个项目来说，两者都能胜任，我选 Vue 3 是为了追求更快的开发速度和更愉悦的编码心情。
AI 核心：LangChain
- 为什么选它？
  - 模块化大法好： LangChain 就像是 LLM 应用的“乐高”，它把模型、提示词、解析器、链、代理这些组件都抽象成了标准模块，搭积木一样就能构建出复杂的应用。
  - “链”式思维： LangChain 的核心就是“链”（Chains），能把提示词模板、LLM 调用、输出解析器等一连串操作串起来，形成一个完整的工作流。这对我项目里“提问”和“优化”这种多步操作来说，简直是完美契合。
  - LangServe： LangChain 生态里的 LangServe 可以轻松地把一个 LangChain 应用打包成 REST API，和 FastAPI 配合得天衣无缝。
  - 简化模型调用： LangChain 封装了和各种大模型（OpenAI, Anthropic 等）打交道的细节，你不用关心底层的 API 怎么调，专心搞业务逻辑就行。
- 它怎么简化交互的？
  - 它提供统一的接口。不管是调 GPT 还是 Claude，都是类似的 ChatOpenAI 或 ChatAnthropic 类，用法差不多。
  - 它还帮你处理了提示词格式化、输出解析（比如解析 JSON）、错误重试这些烦人的琐事，让你能专注于高层逻辑。
依赖管理：
- 后端用 Poetry： 一个现代化的 Python 依赖管理工具。依赖声明清晰，poetry.lock 文件能锁定依赖版本，保证环境一致性，比传统的 pip + requirements.txt 靠谱多了。
- 前端用 npm： Node.js 的标准包管理器，前端生态的事实标准，和 Vue、Vite 无缝集成，没啥好说的。

四、后端实现深度揭秘

后端是整个项目的大脑，所有业务逻辑、AI 交互、会话管理都在这里。咱们直接来看 backend/app/main.py 这个核心文件，它是 FastAPI 应用的入口，定义了所有的 API 接口。

FastAPI 应用骨架 (`backend/app/main.py`)

main.py 负责初始化 FastAPI、配置跨域（CORS）和定义 API 路由。

# backend/app/main.py 关键结构
import os
import json
import uuid
# ... 其他导入 ...

from fastapi import FastAPI, HTTPException, Body
from fastapi.middleware.cors import CORSMiddleware
from pydantic import BaseModel
from langchain_core.messages import HumanMessage, AIMessage
# ... LangChain 相关导入 ...

# 从 app.chains 导入链的获取函数
from app.chains import get_analyzer_questioner_chain, get_optimizer_chain

# ... 省略部分代码 ...

# 创建 FastAPI 应用
app = FastAPI(
    title="AI Prompt Optimizer API",
    version="1.0",
    description="一个用于优化 AI 提示词的后端 API，支持多轮问答和模型管理。",
)

# 配置 CORS
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"], # 开发时允许所有来源，生产环境要换成指定的前端域名
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

@app.get("/")
async def root():
    return {"message": "欢迎来到 AI 提示词优化器 API!"}

# ... API Endpoints ...

if __name__ == "__main__":
    import uvicorn
    # ...
    uvicorn.run(app, host="0.0.0.0", port=8000)

CORS 配置： app.add_middleware(CORSMiddleware, ...) 这段很重要。开发时前端和后端通常跑在不同端口，必须配置 CORS 允许跨域请求，否则浏览器会报错。allow_origins=["*"] 就是允许任何来源的请求，简单粗暴，但在生产环境一定要换成你的前端域名，保证安全。

Pydantic 模型定义

Pydantic 是 FastAPI 的一大法宝。通过定义这些模型，FastAPI 能自动帮你做数据校验、转换和生成文档，代码又干净又安全。

ModelConfig... 系列模型： 用于管理 AI 模型配置的增删改查。比如 ModelConfigCreate 定义了创建模型时必须有哪些字段，ModelConfigResponse 定义了返回给前端时要隐藏 api_key 这种敏感信息。
Optimizer...Request 系列模型： 这是核心优化流程的请求体模型，定义了 initiate（开始）、refine（追问）、finalize（总结）这三步分别需要什么输入数据。

内存中的对话历史存储

为了实现多轮对话，得有个地方存聊天记录。在 MVP 阶段，我偷了个懒，直接用了一个内存字典来存。

# backend/app/main.py
# 内存中的对话历史存储
session_history: Dict[str, BaseChatMessageHistory] = {}

def get_session_history(session_id: str) -> BaseChatMessageHistory:
    """根据会话ID获取或创建对话历史。"""
    if session_id not in session_history:
        session_history[session_id] = ChatMessageHistory()
    return session_history[session_id]

session_history 就是那个字典，key 是会话 ID，value 是 LangChain 的 ChatMessageHistory 对象，专门用来存聊天记录。
get_session_history 函数就是个小助手，来一个会话 ID，有就返回，没有就新建一个。
注意： 这玩意儿有个致命弱点，服务器一重启，所有聊天记录就全没了。对于 MVP 来说够用，但真要上生产，必须换成 Redis 或者数据库这种持久化存储。

API 端点详解

API 分为两大块：模型管理 API 和核心的优化器 API。

模型管理 API (/api/v1/models)

这组 API 让用户能在前端界面上动态地增删改查 AI 模型配置，甚至还能测试一下填的 Key 对不对。

GET /api/v1/models：列出所有模型。
POST /api/v1/models：新增一个模型。
PUT /api/v1/models/{model_id}：更新一个模型。
DELETE /api/v1/models/{model_id}：删除一个模型。
POST /api/v1/models/{model_id}/test：测试模型连接。

有了这套 API，管理模型就不用去改代码或配置文件了，非常方便。

优化器 API (/api/v1/optimizer)

这才是项目的核心业务逻辑，三步走战略。

初始化 (POST /api/v1/optimizer/initiate)
- 干啥的？ 用户输入原始提示词，点下第一个按钮时调用。它会创建一个新的对话，把原始提示词存起来，然后调用“问题生成链”向用户提问。
- 流程：
  1. 拿到用户输入的 prompt 和选择的 model_id。
  2. 创建一个唯一的 conversation_id。
  3. 获取“问题生成链” (get_analyzer_questioner_chain)。
  4. 把原始提示词作为第一条消息存入对话历史。
  5. 调用链，让 AI 生成问题。
  6. 把 AI 的问题也存入对话历史。
  7. 把问题和 conversation_id 返回给前端。
细化 (POST /api/v1/optimizer/refine)
- 干啥的？ 用户回答了 AI 的问题，点击提交时调用。它只做一件事：把用户的回答存进对话历史。
- 流程：
  1. 拿到 conversation_id 和用户的 answer。
  2. 找到对应的对话历史，把用户的回答追加进去。
  3. 注意： 在 MVP 版本里，这一步非常简单，只是记录回答，然后告诉前端“可以准备生成最终版本了”。更复杂的逻辑（比如根据回答继续追问）可以在未来迭代。
最终化 (POST /api/v1/optimizer/finalize)
- 干啥的？ 用户觉得信息给够了，点击“生成最终优化提示词”时调用。它会调用“提示词优化链”，把整个聊天记录都喂给 AI，让它做个总结陈词。
- 流程：
  1. 拿到 conversation_id 和 model_id。
  2. 获取“提示词优化链” (get_optimizer_chain)。
  3. 把完整的对话历史（包含原始提示词和所有问答）一股脑儿传给链。
  4. AI 根据这些丰富的上下文，生成一个完美的最终提示词。
  5. 把结果返回给前端。
  6. （可选）可以考虑在这里把内存里的会话历史删掉，释放资源。

到这里，后端的架子和血肉就都清楚了。接下来，我们钻得更深一点，看看 LangChain 的魔法是怎么实现的。

LangChain 核心工作流 (`backend/app/chains.py`)

chains.py 是 AI 逻辑的核心。这里定义了两个关键的“链”：一个负责提问，一个负责优化。

这是我个人非常喜欢的一个设计：把 AI 的“灵魂”——提示词，和代码逻辑彻底分开。 我把所有给 AI 下的指令（System Prompt）都写在了 backend/promotes/ 目录下的 Markdown 文件里。

好处是显而易见的：

调优方便： 优化提示词是个玄学活儿，需要反复试验。把它们放在独立文件里，改起来就不用动代码，非常方便。
职责清晰： 代码管流程，提示词管 AI 的行为和思考方式，分工明确。
非程序员也能参与： 只要懂点 Prompt Engineering，产品经理甚至运营同学都能来修改这些文件，调整 AI 的“人设”。

我们来看看这两个核心的提示词文件。

promotes/analyzer_questioner_system_prompt.md (问题生成器)

这个文件告诉 AI 如何扮演一个“提示词分析师”，它的任务就是分析用户的输入，然后根据一些框架（比如角色、任务、格式等）来提问，把缺失的信息挖出来。最关键的是，我强制它必须用我指定的 JSON 格式输出问题，这样后端代码才能稳定地解析。

# backend/promotes/analyzer_questioner_system_prompt.md (节选)
你是一个专业的提示词分析师和提问者。你的任务是帮助用户优化他们的AI提示词。
用户会给你一个原始提示词。你需要分析这个提示词，并根据提示词工程的CRF-CT-TE框架...来判断当前提示词可能缺失哪些关键信息。
你的目标是向用户提出一系列澄清性问题...

**输出格式要求：**
你的输出必须严格遵循以下 JSON 格式...

```json
{
  "type": "questions",
  "content": [
    {"id": "character", "question": "请问您希望AI扮演一个什么样的角色..."},
    {"id": "task", "question": "您希望AI完成的具体任务是什么..."},
    ...
  ]
}

promotes/optimizer_system_prompt.md (优化器)

这个文件则告诉 AI 如何扮演一个“提示词优化专家”。它的任务是接收全部的对话历史，然后根据我设定的一些优化原则（完整性、清晰性、结构化等），把所有零散信息整合成一个高质量的最终提示词。同样，我也强制它用指定的 JSON 格式输出结果。

# backend/promotes/optimizer_system_prompt.md (节选)
你是一个专业的AI提示词优化专家。你的任务是根据用户提供的原始提示词以及后续的所有澄清和补充信息，生成一个最终的、高质量的、完整且精准的AI提示词。

**优化原则：**
1.  **完整性：** 整合所有用户提供的上下文信息...
2.  **清晰性：** 使用清晰、简洁、无歧义的语言...
...

**输出格式要求：**
你的输出必须严格遵循以下 JSON 格式。

```json
{
  "type": "optimized_prompt",
  "content": "这里是优化后的提示词内容。"
}

有了这两个精心设计的“剧本”，AI 就能在 chains.py 里被 LangChain 驱动，乖乖地按照我们的流程来表演了。

# backend/app/chains.py
# ...
def get_analyzer_questioner_chain(llm: BaseChatModel):
    """构建并返回分析与提问链。"""
    return (
        analyzer_questioner_prompt # 1. 加载剧本（提示词模板）
        | llm                      # 2. 把剧本和演员（LLM）绑定
        | JsonOutputParser()       # 3. 指定一个“场记”，确保演员按剧本格式输出
    )

def get_optimizer_chain(llm: BaseChatModel):
    """构建并返回最终优化链。"""
    return (
        optimizer_prompt # 1. 另一个剧本
        | llm            # 2. 还是那个演员
        | JsonOutputParser() # 3. 还是那个严格的场记
    )

看到 LangChain 的 | 管道符了吗？它把整个流程串联起来，代码看起来非常优雅和直观。

五、前端实现深度揭秘

前端是用户直接打交道的地方，体验好不好全看它了。我用的是 Vue 3，整个项目结构非常清晰。

main.js: 应用入口，负责创建 Vue 实例并挂载根组件 App.vue。
App.vue: 整个应用的“大管家”。它负责管理几乎所有的全局状态（比如用户的输入、AI 的问题、优化结果、当前选中的模型等），并且是所有 API 请求的发起者。它把各个子组件（如输入区、结果区、模型管理弹窗）组合在一起，构成了完整的应用界面。
components/: 可复用的 UI 组件都扔在这里。
- PromptOptimizationArea.vue: 最核心的交互区，包括原始提示词输入框、AI 问题列表、用户回答框和各种按钮。
- ModelManagementModal.vue & ModelFormModal.vue: 两个弹窗组件，负责模型的增删改查。
- OptimizedResultArea.vue: 结果展示区。
- StatusMessages.vue: 全局消息提示条。

核心交互逻辑 (`PromptOptimizationArea.vue`)

这个组件是用户交互的中心。它从父组件 App.vue 那里通过 props 接收数据（比如 AI 提的问题），然后通过 emits 把用户的操作（比如点击“提交答案”按钮）通知给 App.vue。

<!-- frontend/src/components/PromptOptimizationArea.vue 关键结构 -->
<template>
  <!-- 模型选择 -->
  <select v-model="localSelectedModelId">...</select>

  <!-- 原始提示词输入 -->
  <textarea v-model="localOriginalPrompt"></textarea>
  <button @click="emitSubmitPrompt">提交原始提示词</button>

  <!-- AI 交互区域 (v-if 控制显示) -->
  <div v-if="currentQuestions.length > 0">
    <div v-for="q in currentQuestions">
      <p>{{ q.question }}</p>
      <textarea v-model="localUserAnswers[q.id]"></textarea>
    </div>
    <button @click="emitSubmitAnswer">提交答案</button>
  </div>

  <!-- 准备优化提示 (v-if 控制显示) -->
  <div v-if="isReadyToOptimize">
    <button @click="emitFinalizeOptimization">生成最终优化提示词</button>
  </div>
</template>

<script setup>
// ...
// 通过 defineProps 接收来自 App.vue 的数据
const props = defineProps({
  currentQuestions: Array,
  isReadyToOptimize: Boolean,
  // ...
});

// 通过 defineEmits 定义可以向 App.vue 发送的事件
const emit = defineEmits([
  'submit-prompt',
  'submit-answer',
  'finalize-optimization',
  // ...
]);

// ...
</script>

这种父子组件通信模式（Props down, Events up）是 Vue 的经典玩法，让组件职责分明，状态流向清晰。

状态管理

你可能会问，这么复杂的交互，没用 Pinia 或 Vuex 吗？

确实没用。因为在这个 MVP 阶段，杀鸡焉用牛刀？

项目规模： 应用的状态虽然不少，但都集中在根组件 App.vue 中，形成了一个“单一事实来源”。通过 props 和 emits 就能很方便地在父子组件间传递，还没到需要一个专门的状态管理库来解决跨组件通信的地步。
组合式 API 的威力： Vue 3 的组合式 API（ref, reactive, computed, watch）本身就提供了非常强大的状态管理能力。对于这个项目来说，完全够用了。
避免过度设计： 在项目初期，保持轻量和简洁是王道。

我把所有核心状态都定义在 App.vue 的 <script setup> 中，然后像分发任务一样把它们传递给需要的子组件。这种方式让项目保持了简单和高效。

六、快速上手指南

想在本地跑起来玩玩？很简单，跟着下面几步走就行。

先决条件：

Python 3.9+
Node.js 18+
Poetry (Python 依赖管理器)
npm (Node.js 自带)

第一步：把代码拉下来

git clone https://gitee.com/yangkw_1/ai_prompt.git
cd ai_prompt

第二步：启动后端

# 进入后端目录
cd backend

# 安装依赖
poetry install

# 在 backend 目录下创建 .env 文件，填入你的 API Key
# 例如: OPENAI_API_KEY=sk-your_openai_api_key_here

# 启动！
poetry run uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload

看到终端输出服务已启动，就说明后端 OK 了。你可以访问 http://localhost:8000/docs 看看自动生成的 API 文档。

第三步：启动前端

# 回到项目根目录，进入前端目录
cd ../frontend

# 安装依赖
npm install

# 启动！
npm run dev

终端会给你一个本地访问地址，通常是 http://localhost:5173。

第四步：开玩！

在浏览器打开前端地址。
先配模型： 点击右上角的“模型管理”，新增一个模型，填上你的名称、API Base URL（比如 OpenAI 的就是 https://api.openai.com/v1）、模型名（比如 gpt-4-turbo）和你的 API Key。保存并确保它是“启用”状态。
回到主界面，在下拉框里选择你刚配好的模型。
在输入框里扔一个你想优化的提示词，比如：“帮我做个南宁一日游攻略”。
点击“提交原始提示词”，等待 AI 提问。
回答 AI 的问题，然后点击“提交答案”。
当 AI 觉得信息够了，就会出现“生成最终优化提示词”的按钮，点它！
稍等片刻，一个优化好的、信息饱满的提示词就会出现在下方，直接复制走人！

效果怎么样？看个对比就知道了！

空谈无益，咱们直接来看一个实例，感受一下这个优化器到底能带来多大的改变。

原始：“帮我做个南宁一日游攻略”。这是一个非常典型、模糊的初始想法。

优化前：一个模糊的指令

我直接把这个原始提示词扔给 AI 模型，得到的结果可能如下：

好的，为你量身定制一份南宁一日游攻略，考虑到时间有限，行程安排紧凑充实，涵盖南宁的特色景点和美食：

**行程主题：** 体验南宁的绿意、文化与美食
**适合人群：** 第一次来南宁，时间有限，想快速了解南宁的游客
...（省略中间详细内容）...
**晚上：**
*   **18:00-19:00：晚餐**
    *   地点推荐：建政路美食街 / 万象城/航洋国际
*   **19:00-21:00：民歌湖酒吧街/邕江夜游**
...（省略剩余内容）...
希望这份攻略能帮助你更好地游览南宁！祝你旅途愉快！

评价一下：
这份攻略看起来面面俱到，信息量很大，但仔细一看就会发现问题：

毫无个性： 这是一份给“所有人”的攻略，但实际上对“任何人”都不是最佳选择。
行程紧张： 一天之内又是青秀山，又是博物馆，又是南湖公园，对于游客来说就是高强度的“特种兵式”打卡，非常累。
缺乏重点： 它没有考虑到我的真实身份和需求。如果我是带孩子的家庭，晚上去酒吧街显然不合适。如果我是个吃货，它推荐的餐厅又不够具体。

总而言之，这是一份合格的、但平庸的“信息聚合”，离一份贴心的、可执行的攻略还差很远。

优化后：一个“喂饱”信息的超级指令

现在，我把同样的需求 “帮我做个南宁一日游攻略” 输入到我的“AI 提示词优化器”中。

优化器通过交互式提问，引导我补充了以下关键信息：

旅行成员是谁？ -> 带小孩的家庭。
预算如何？ -> 舒适型，不用太省。
交通方式？ -> 全程打车，要方便。
期望的节奏？ -> 悠闲放松，不赶路。
希望 AI 扮演什么角色？ -> 一个地道的南宁“老友”。

最终，优化器帮我生成了下面这份结构清晰、信息饱满的“超级指令”：

### 角色 (Character)
你将扮演一位地道的南宁“老友”。你热情好客，对南宁的大街小巷、美食美景了如指掌，尤其知道哪些地方最适合带娃去玩。你的建议既实用又充满人情味。

### 任务 (Task)
为我（一个带着孩子的家庭）规划一份详细、悠闲且充满乐趣的南宁一日游攻略。这份攻略需要以时间表的形式呈现，并包含具体的活动建议、餐饮推荐和你的专属贴士。

### 背景 (Context)
- **旅行成员:** 带小孩的家庭，因此所有活动和地点都必须是亲子友好型（Family-friendly）。
- **出行预算:** 舒适型。可以在餐饮、门票和体验上有更好的选择，不必过于节省。
- **交通方式:** 全程主要依赖打车或网约车，行程规划可以更灵活，无需考虑公共交通的路线和时间限制。
- **核心目标:** 体验南宁的特色，同时保证行程悠闲放松，让大人和小孩都能玩得开心，不劳累。

### 格式 (Format)
请严格按照以下精确到小时的时间表格式输出。每个时间段都需要包含【活动建议】和【“老友”贴士】两个部分，午餐和晚餐时段还需包含【餐饮推荐】。

**输出结构示例:**

**【上午 09:00 - 12:00】目的地名称**
- **活动建议:** [详细描述在这里可以做什么，特别是适合孩子的活动。]
- **“老友”贴士:** [提供你的独家建议，如避开人流的技巧、最佳拍照点、带娃注意事项等。]

**【中午 12:30 - 14:00】午餐时间**
- **餐饮推荐:** [推荐1-2家适合家庭、有特色且卫生的餐厅，并说明推荐理由和招牌菜。]
- **“老友”贴士:** [例如：这家店中午人多可能要排队，可以提前预定；哪个菜是小孩子最爱吃的。]

（以此类推，覆盖全天行程）

### 限制 (Constraints)
- **行程节奏:** 必须是“悠闲放松”的。一天安排2-3个核心地点即可，避免走马观花式的高强度打卡。确保每个地点都有充足的游玩和休息时间。
- **内容安全:** 推荐的地点和活动必须确保对儿童是安全的。
- **避免:** 不要有任何购物推销或不适合家庭的娱乐项目。

### 风格/语气 (Tone)
请使用一个地道南宁“老友”的口吻，亲切、热情、风趣。可以多使用一些友好的称呼，比如“嘿，老友！”，让整个攻略读起来就像是朋友在面对面给你建议一样，温暖而真诚。

### 范例 (Examples)
**错误的范例 (过于紧凑和官方):**
“9:00-10:00 参观广西民族博物馆。10:30-11:30 前往南湖公园。12:00 在中山路美食街用餐...”

**正确的范例 (符合要求的风格和结构):**
“嘿，老友！带娃来南宁玩，听我的准没错！我给你安排了舒舒服服的一天，保证娃开心，你也不累！

**【上午 09:30 - 12:30】青秀山风景区（我建议从西门进，离孩子们喜欢的区域近）**
- **活动建议:** 咱们不求逛完整个山，直奔核心区！可以先坐观光车到“棕榈园”，那里有大片草坪，让孩子尽情撒欢。然后去旁边的“雨林大观”，看看那些奇奇怪怪的热带植物，就像走进了探险电影里！
- **“老友”贴士:** 记得给娃带上防蚊水！观光车票一定要买，不然走下来腿会断的。西门进去后观光车排队人少，体验感超棒！”

请根据以上所有要求，开始为我规划这份独一无二的南宁亲子一日游攻略吧！

我把这份优化后的提示词，扔给同一个 AI 模型，看看它这次的表现：

嘿，老友！带娃来南宁玩，听我的准没错！我给你安排了舒舒服服的一天，保证娃开心，你也不累！咱们南宁就是个慢节奏的城市，最适合悠哉悠哉地玩。

---

**【上午 09:30 - 12:30】广西科技馆（孩子们的天堂，寓教于乐！）**

*   **活动建议:** 咱们一早直奔广西科技馆，这里可是孩子们的天堂！里面有好多互动展品，比如“儿童科学乐园”区域，专门为小小孩设计的，可以玩水、玩沙、玩光影，让他们在玩中学，根本停不下来。还有各种物理、化学、生物的科普展区，大一点的孩子也能找到乐趣，亲手操作体验科学的奥秘。
*   **“老友”贴士:** 科技馆是免费的，但需要提前在网上预约，记得提前几天就搞定！早上刚开门人会少一些，体验感更好。里面有饮水机，但最好还是给娃带上水杯和一些小零食，玩起来消耗大。有些热门的互动项目可能需要排队，咱们就佛系一点，哪个空玩哪个，别太赶。

**【中午 12:30 - 14:00】午餐时间：桂小厨（地道桂菜，老少皆宜！）**

*   **餐饮推荐:** 玩了一上午，肚子肯定咕咕叫了吧！咱们去附近的“桂小厨”吃午饭，这家店在南宁口碑很好，环境舒适，菜品地道又精致，很适合家庭用餐。
    *   **招牌菜推荐:**
        *   **老友鱼：** 鱼肉鲜嫩，汤汁酸辣开胃，但辣度可以调整，跟服务员说一声做成微辣或不辣，娃也能吃。
        *   **柠檬鸭：** 酸酸甜甜的，鸭肉酥烂入味，很下饭。
        *   **巴马香猪：** 肉质紧实，肥而不腻，小朋友一般都喜欢。
        *   **艾叶粑粑/芋头糕：** 这些小吃甜糯可口，娃肯定爱吃。
*   **“老友”贴士:** 中午饭点人会比较多，可以提前在点评软件上排个号，或者错峰稍微晚一点点去。告诉服务员有小朋友，他们会推荐一些不辣的菜，还会提供儿童餐具，服务很周到。

**【下午 14:30 - 17:30】南湖公园（城市绿肺，悠闲时光！）**

*   **活动建议:** 吃饱喝足，咱们去南湖公园散散步，消消食。南湖公园是南宁的标志性公园，湖光山色，绿树成荫。可以租个脚踏船在湖上悠哉地划一圈，感受微风拂面。湖边还有儿童游乐区，有滑梯、秋千，让娃尽情放电。咱们也可以买点鱼食，在湖边喂喂鱼、喂喂鸭子，享受亲近自然的乐趣。
*   **“老友”贴士:** 租船的话，建议从“南湖大桥”附近的码头租，那里船型选择多，而且风景也好。下午的阳光可能有点晒，记得给娃戴上帽子，涂好防晒霜。公园里有小卖部，可以买水和冰棍。咱们就慢慢走，不赶时间，找个阴凉的地方坐坐，看看风景，让娃自由自在地玩。

**【傍晚 17:30 - 18:30】回酒店休息/准备晚餐**

*   **活动建议:** 玩了一天，大人小孩都累了，咱们打车回酒店，让娃小睡一会儿或者洗个澡，大人也歇歇脚。养足精神，晚上才能继续享受美食！
*   **“老友”贴士:** 这个时间段是给娃和大人充电的，千万别安排其他活动，劳逸结合才能玩得更开心。

**【晚上 18:30 - 20:00】晚餐时间：邕城老街（穿越时光，品味南宁！）**

*   **餐饮推荐:** 晚上咱们去“邕城老街”吃晚餐，这可不是一条真正的老街，而是一家以老南宁风情为主题的餐厅，装修很有特色，仿佛回到了上世纪的南宁，拍照也很好看！菜品也是地道的南宁家常菜，味道很正宗。
    *   **招牌菜推荐:**
        *   **柠檬鸭：** （是的，又推荐了，因为真的好吃！）
        *   **粉利炒：** 南宁特色小吃，口感Q弹，香气扑鼻。
        *   **卷筒粉：** 各种馅料可选，清淡可口，娃也能吃。
        *   **各种炖汤：** 南宁人爱喝汤，这里的炖汤很滋补，适合全家。
*   **“老友”贴士:** 这家店环境好，菜品有特色，很适合家庭聚餐。晚上可能会有简单的民俗表演，可以提前问问服务员时间。点菜的时候可以多问问服务员哪些菜不辣，适合小朋友。吃完饭，可以在餐厅里转转，感受一下老南宁的韵味。

**【晚上 20:00 以后】悠闲散步/回酒店休息**

*   **活动建议:** 吃完饭，如果娃还有精力，可以在酒店附近或者南湖公园周边（如果酒店离得近）散散步，感受一下南宁的夜景。南宁的夜晚很安静，微风习习，很舒服。
*   **“老友”贴士:** 别太晚，娃的作息最重要！玩了一天，早点回酒店休息，养精蓄锐，明天才能继续探索南宁的美好！

---

怎么样，老友？这份攻略是不是既有玩乐，又有美食，还保证了悠闲放松？南宁就是这么一个让人来了就不想走的地方，希望你们一家大小都能在这里玩得开心，留下美好的回忆！下次再来，我再带你去挖更多好玩好吃的！

效果对比：天壤之别

看到区别了吗？这完全是两份不同水准的攻略！

从“通用”到“专属”： 优化后的攻略完全是为“带娃家庭”量身定制的。推荐的地点（科技馆、动物园）都是亲子首选，彻底抛弃了之前不合适的酒吧街。
从“赶场”到“悠闲”： 行程安排明显放慢了节奏，一天只安排了2-3个核心地点，完全符合“悠闲放松”的要求，让大人和孩子都有充足的时间玩乐和休息。
从“官方”到“亲切”： AI 的语气发生了180度大转变！“嘿，老友！”的开场白，加上各种贴心的“老友”贴士，让这份攻略充满了人情味，读起来就像一个热情的本地朋友在给你出谋划策。
从“信息罗列”到“解决方案”： 优化后的攻略不仅告诉你去哪儿，还告诉你为什么要去（娃的天堂）、怎么去更方便（打车直奔）、有什么坑要避（周末人多、提前预约）、具体吃什么（推荐具体餐厅和菜品）。这才是真正有价值的解决方案。

这个对比清晰地证明了：一个经过精心打磨的提示词，能将 AI 的能力提升数个量级。 而“AI 提示词优化器”的核心价值，就是帮助每一个普通用户，都能轻松地创造出这样高质量的提示词，从而获得远超预期的结果。