Zui近这段时间，AI编程辅助工具简直火得一塌糊涂。不管是Cursor还是Claude Code，它们dou在试图重塑我们写代码的方式。不知道大家有没有发现，这些工具dou有一个特别“抓人”的特性：当你还在敲击键盘构思逻辑时它们就Yi经像读心术一样，实时把接下来的代码补全摆在你面前了。那种按下Tab键就Neng直接采纳建议的流畅感，一旦用惯了真的就回不去了。

这种体验太爽了以至于我脑子里冒出一个大胆的想法：Neng不Neng把这种Neng力搬到我的个人博客后台里？毕竟写技术博客和写代码在某种程度上是相通的，dou需要灵感的连续性。于是我决定动手，从零开始，用Next.js全栈技术，把Prompt工程、RAG、流式输出以及AI Copilot这些听起来hen高大上的概念，全部揉进一个博客项目里。今天这篇文章，我就把我在这个“填坑”过程中积累的经验和心得，毫无保留地分享给想要入门AI应用开发的朋友们。

一、 核心心法：Prompt工程是灵魂

在正式敲第一行代码之前，我们必须先达成一个共识：大模型应用开发，本质上就是“Prompt + API”的艺术。Prompt是什么？说白了就是你给大模型下的“指令”。你怎么问，它就怎么答。问得精准，它就是你的超级助手；问得含糊，它可Neng就给你一本正经地胡说八道。

hen多新手觉得写Prompt就是随便说句话，其实不然。一个高质量的Prompt，应该像一份严谨的工作文档。我在项目里采用的是一种“结构化提示词”的写法，效果非常不错。咱们来kan个实际的例子，这是我用来生成文章摘要的Prompt构建逻辑：

export function buildExcerptPrompt: string {
  return `# Role: 内容摘要撰写专家
## Profile
- Author: Spring Broken AI Blog
- Version: 1.0
- Language: 中文
- Description: 你是一位资深的内容编辑，擅长从长文中提取核心信息，撰写简洁有力的摘要。
## Rules
1. 摘要长度必须严格控制在50-100个汉字之间
2. 必须包含文章的核心观点和主要结论
3. 使用简洁、专业的语言，避免冗余表达
4. 只返回摘要文本，不要包含任何其他内容
## Workflow
1. 仔细阅读并理解完整的文章内容
2. 识别文章的核心主题和主要论点
3. 用简洁的语言组织摘要
4. 输出纯文本摘要
## Input
文章内容：${content.slice}
## Initialization
作为 ，严格遵守 ，按照  撰写摘要。`;
}

你kan，其实就是把“你是谁”、“要遵守什么规则”、“按什么流程Zuo事”、“输出什么格式”这几件事说清楚。把逻辑理顺了大模型输出的质量会有质的飞跃。这比直接扔给它一句“帮我写个摘要”要靠谱得多。

二、 打造AI Copilot：像VSCode一样写文章

这个功Neng是我觉得Zui有意思，也是挑战Zui大的部分。它的效果类似于GitHub Copilot，在你写文章的时候，实时给出补全建议。虽然kan起来简单，但实际Zuo起来坑真不少。

1. 基本原理：上下文续写

说穿了也不复杂：把文章当前的上下文 + 你的Prompt，一股脑丢给大模型，让它帮你续写。但这里有个关键点：补全建议不Neng直接写入文档，只Neng在视图层显示。也就是说它只是个“幽灵文本”，只有当你按下Tab键确认时才会真正变成文档内容。

2. 视觉实现：ProseMirror的Decoration机制

我用的编辑器是基于ProseMirror封装的Tiptap。ProseMirror有个非常强大的机制叫Decoration。它允许我们在视图层叠加显示内容，但完全不改变底层的文档结构。这简直是为AI补全量身定Zuo的。

我们Ke以创建一个灰色的、斜体的Span元素，把它插在光标后面：

// 创建补全建议的视觉装饰
const widget = document.createElement;
widget.className = "ai-completion-suggestion";
widget.style.cssText = 
  "color: #9ca3af; " + // 灰色
  "font-style: italic; " + // 斜体
  "pointer-events: none; " + // 不拦截鼠标事件
  "user-select: none;"; // 不可选中
widget.textContent = suggestion;
// 在光标位置显示
const decoration = Decoration.widget(position, widget, {
  side: 1, // 显示在光标后方
  ignoreSelection: true,
});

3. 避坑指南：防抖与竞态条件

这个功NengZuo出来容易，Zuo好难。我踩了两个大坑，大家一定要避开：

第一，防抖处理。 试想一下Ru果你的手指在键盘上飞舞，每敲击一下键位就触发一次API调用，那服务器恐怕瞬间就要崩溃了而且费用也吃不消。我的Zuo法是设置了500ms的防抖，只有当用户停下来半秒钟，系统才会觉得“哦，你是真的需要帮助了”，这时候再去请求接口。

第二，异步竞态问题。 这是个hen隐蔽的Bug。用户可Neng在API还没返回的时候，又把光标移到了别的地方继续打字。这时候，Ru果之前的请求回来了直接把补全内容显示出来位置就会错乱，甚至覆盖掉用户刚写的新内容。

为了解决这个问题，我参考了VSCode的Zuo法，Zuo了双重位置校验：

// 第一次校验：防抖回调执行时
const currentState = extension.editor.state;
if  {
  return; // 位置Yi改变，直接丢弃这次请求
}
// 调用 AI API...
// 第二次校验：API 返回结果后
const latestState = extension.editor.state;
if  {
  // 确认光标位置仍然一致，才geng新UI显示建议
} else {
  // 位置变了默默忽略返回结果
}

三、 RAG与向量数据库：让AI“读懂”你的博客

大模型虽然聪明，但它有个致命的缺陷：它不知道你博客里具体写了什么。你问它“我之前那篇关于Prompt工程的文章讲了什么？”，它只Neng根据训练数据里的通用知识瞎猜。这显然不是我们想要的。

为了解决这个问题，我们需要引入RAG技术。简单来说就是给大模型开卷考试的机会：先从你的数据库里找到相关的资料，然后让大模型基于这些资料来回答问题。

1. 为什么需要向量数据库？

传统的数据库，比如MySQL，擅长处理精确匹配。但AI领域有个难题：语义相似度。比如“如何写好Prompt”和“Prompt工程技巧”，这两个句子的关键词完全不同，但意思是一样的。传统数据库对此束手无策。

向量数据库就是为了解决这个问题而生的。它把文本转化成向量，意思相近的文本，在向量空间里的距离就会hen近。我选用了ChromaDB，因为它开源、免费，而且足够轻量，非常适合个人项目。

2. 数据分块的学问

在把文章存进向量数据库之前，必须先进行“分块”。这一步我踩了不少坑。

一开始我想简单点，按固定字符数切，比如每500字一块。结果发现灾难性的问题：句子被截断了段落被腰斩了检索的时候经常匹配到不完整的片段，导致AI回答得莫名其妙。

后来我改成了语义分块。逻辑大概是这样的：

// 语义分块的核心逻辑
export function chunkPost {
  const maxChars = options.maxChars || 500; // Ollama模型通常有长度限制
  const chunks = ;
  // 优先按段落分割
  const paragraphs = content.split.filter => p.trim);
  for  {
    if  {
      // Ru果段落太长，再按句子分割
      splitBySentence;
    } else {
      chunks.push;
    }
  }
  return chunks;
}

还有一个坑是Ollama的nomic-embed-text模型有硬性的字符限制。超过这个长度它直接报错，连个面子dou不给。所以Ru果一个块太长，我必须把它切成多个子块，每个子块单独生成向量并存储。虽然麻烦点，但至少信息不会丢。

四、 流式输出：拒绝枯燥的等待

Ru果你用过ChatGPT，肯定对那个打字机效果印象深刻。AI的回答不是一下子全出来的，而是一个字一个字蹦出来的。这不仅仅是为了好kan，geng重要的是为了用户体验。

试想一下Ru果你问个问题，然后盯着屏幕干等10秒钟，Zui后才kan到一大段文字，那种焦虑感是hen强的。流式输出Neng让用户立刻kan到反馈，感觉系统响应hen快，心理上的等待时间会大幅缩短。

1. 技术实现：SSE

流式输出的核心技术是SSE。传统的HTTP请求是“发请求 -> 等待 -> 收到完整响应”，而SSE是“发请求 -> 保持连接 -> 服务器持续推送数据 -> Zui后关闭连接”。

在Next.js里我们Ke以利用ReadableStream来实现：

// 创建 SSE 流
const stream = new ReadableStream({
  async start {
    const sendEvent =  => {
      const message = `event: ${type}
data: ${JSON.stringify}

`;
      controller.enqueue);
    };
    // 调用 Kimi API，流式返回
    await aiClient.chatStream => {
      // 每收到一个文本块，就立刻推送给前端
      sendEvent;
    });
    // 完成后关闭连接
    sendEvent;
    controller.close;
  },
});
return new Response(stream, {
  headers: {
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    Connection: "keep-alive",
  },
});

前端这边，用fetch配合ReadableStream来读取：

const response = await fetch("/api/ai/rag/stream", {
  method: "POST",
  body: JSON.stringify,
});
const reader = response.body.getReader;
const decoder = new TextDecoder;
while  {
  const { done, value } = await reader.read;
  if  break;
  const text = decoder.decode;
  // 解析 SSE 格式，geng新 UI
  parseSSE => {
    setContent => prev + chunk); // 追加文本，实现打字机效果
  });
}

五、 系统稳定性：优雅降级

Zuo全栈开发，尤其是依赖外部API的时候，必须要考虑服务不可用的情况。Ru果RAG服务挂了你的整个博客是不是就瘫痪了？

我在设计时Zuo了降级处理Ru果检测到RAG服务不可用，系统会自动退化成纯LLM模式。虽然这时候AI回答的准确性会下降，但至少功Neng还Neng用，用户不会kan到一个报错页面。这种“有总比没有强”的策略，在实际产品中非常重要。

Zuo完这个项目，我Zui大的感受就是：大模型应用开发并没有想象中那么高不可攀。hen多kan似复杂的功Neng，剥去外壳，核心逻辑往往hen朴素。

当然这个项目还有hen多Ke以深挖的方向。比如如何进一步优化Prompt的模板？如何引入geng复杂的Agent机制，让AINeng自动调用工具去搜索资料？如何利用LangChain来简化流程编排？这些dou是未来Ke以探索的领域。

Ru果你对Next.js全栈开发感兴趣，或者想kankan这些功Neng是如何在代码中落地的，欢迎去GitHub上kankan这个项目。虽然它还处在初期阶段，但Yi经是一个Neng跑、Neng用的AI智Neng博客系统了。

希望这篇文章Neng给你带来一些启发。别光kan着Cursor眼馋，动手试试吧，构建属于自己的AI应用，真的hen有趣！

---