从0到1搭建企业级Prompt管理与AI Agent平台：一个实习生的实战踩坑记录

本文记录了我在实习求职准备期间，独立设计并开发一个企业级Prompt管理与AI Agent智能助手平台的完整过程。文中会重点分享开发中遇到的真实坑点、AI Agent常见问题的定位与解决思路，以及我对AI产品的一些思考。AI在这个项目中是效率工具，业务设计、流程闭环、问题定位都由我自己把握。

前言

前段时间我做了一个"真东西"——一个同时覆盖Prompt工程全生命周期管理和具备工具调用+RAG+多轮对话的智能Agent的企业级平台。从业务分析、需求拆解、架构设计到编码实现、问题定位、效果验证，全程独立完成。

这篇文章不是教程，而是我的实战记录。里面有我踩过的坑、定位问题的思路、以及对AI产品的一些不成熟的思考。如果你也在准备AI相关的项目，希望能给你一些参考。

---

一、项目业务分析

1.1 业务背景

2023年以来大模型快速普及，企业开始大规模将AI引入日常工作。但在实际落地中，我观察到一个普遍现象：很多企业买了大模型账号，但用不起来。

用不起来的原因不是模型不够强，而是缺乏一套管理和治理体系。Prompt散落在每个人的文档里，好的经验无法沉淀；AI助手只能闲聊，不能真正解决业务问题；出了问题不知道是Prompt的问题还是模型的问题，无法定位和优化。

1.2 痛点分析

通过对身边使用大模型的同学和企业案例的观察，我总结出两个核心痛点：

痛点一：Prompt管理处于"原始状态"

问题	具体表现	影响
无法共享	每个人的Prompt存在自己的备忘录/聊天记录里	好的Prompt随人员流动流失
无法追溯	修改Prompt直接覆盖，没有历史记录	出问题不知道改了什么、谁改的
无法评测	改完Prompt凭感觉判断"好像变好了"	优化无量化依据，全靠拍脑袋
门槛高	非技术员工写不出高质量Prompt	大模型投入产出比低

痛点二：AI助手"中看不中用"

很多AI助手Demo界面炫酷，但实际企业可用性极低：

• 只能通用问答，不能调用企业内部工具和数据
• 回答企业内部问题严重依赖幻觉，瞎编比说不知道更可怕
• 没有执行记录，出了问题无法追溯

基于这两个痛点，我确定了项目方向：做一个同时解决Prompt管理和Agent能力的企业级平台。

---

二、需求分析：我要解决什么问题

2.1 Prompt管理侧需求

我把Prompt管理拆解为四个核心能力：

1. 模板库：分类存储企业所有Prompt，支持搜索、筛选。每条Prompt包含名称、分类、内容、创建人、版本号、时间戳。

2. 版本管理：每次修改自动保存历史版本，支持差异对比和一键回滚。这是企业级和个人用的核心区别——个人用改了就改了，企业必须可追溯。

3. 调试与评测：

• 单条调试：选中Prompt，输入测试问题，一键看输出效果
• 批量评测：同一问题跑多个版本，自动对比打分，用数据决定用哪个版本

4. 组件化：把高频Prompt封装成"填参数就能用"的组件，非技术员工无需懂Prompt。

2.2 Agent侧需求

Agent侧我设计了四个能力：

1. 多轮对话：支持上下文记忆，理解"他/她/这个/刚才"等指代性提问。

2. 工具调用（Function Call）：Agent自主判断是否需要调用工具、调用哪个。我设计了3个工具：

• 时间查询：返回当前日期时间
• 企业数据查询：查询员工信息、销售数据（内置示例数据）
• 计算器：执行数学计算

3. RAG知识库问答：基于企业内部文档回答问题，文档外的问题明确拒答，控制幻觉。

4. 执行日志：记录每一次完整执行链路（提问→是否调用工具→工具名→参数→返回→最终回答→耗时），用于调试和优化。

2.3 需求优先级

我用"必须有/应该有/可以有"来划分优先级，确保Demo阶段聚焦核心价值：

• P0（必须有）：模板库、版本管理、单条调试、多轮对话、工具调用、RAG问答、执行日志
• P1（应该有）：批量评测、组件化、版本差异对比
• P2（可以有）：权限体系、审批流程、A/B测试（Demo阶段不做，在项目反思中说明）

---

三、整体实现思路

3.1 技术选型

层级	方案	选型理由
前端	HTML5 + CSS3 + 原生JavaScript	零依赖、双击即可运行、便于分享演示；聚焦产品逻辑，不把时间花在框架学习上
数据存储	localStorage（浏览器内置）	Demo阶段无需后端，刷新不丢数据；数据层统一封装，未来可迁移至MySQL/MongoDB
大模型	设计上支持API接入，Demo用模拟输出	演示阶段用模拟输出保证稳定，实际部署替换为真实API调用即可

关于选型的思考：我没有选React/Vue等框架，也没有搭后端。原因很简单——这个项目的核心价值是产品设计和业务逻辑，不是技术栈的复杂度。用最朴素的技术栈，把更多时间花在流程设计、问题定位、效果验证上，对AI产品经理岗位来说更有价值。

3.2 整体架构

系统采用三层架构：
┌─────────────────────────────────────────────┐
│ 展示层 │
│ Prompt 工作台 Tab │ Agent 助手 Tab │
└──────────────────────┬──────────────────────┘
│
┌──────────────────────▼──────────────────────┐
│ 业务逻辑层 │
│ Prompt 管理引擎 │ Agent 对话引擎 │ 工具路由器 │
└──────────────────────┬──────────────────────┘
│
┌──────────────────────▼──────────────────────┐
│ 数据持久层 │
│ 提示词表 │ 版本表 │ 评测表 │ 执行日志表 │
└─────────────────────────────────────────────┘

3.3 豆包在项目中的角色

这里我想明确说明一点：豆包在这个项目中是效率工具，不是"一键生成器"。

具体来说，豆包帮我做了这些事：

• 代码片段生成：某些重复的UI组件代码、数据操作函数，我描述需求后豆包给出初稿，我审核修改后使用
• 问题排查辅助：遇到报错时，把错误信息和相关代码贴给豆包，它帮我分析可能的原因，我自己验证和定位
• 文案和文档润色：项目文档、博客文章的文字润色

但以下核心环节完全由我自己把握：

• 业务需求分析和优先级排序
• 架构设计和技术选型决策
• 核心业务逻辑设计（尤其是版本不可变设计、幻觉控制机制、评测维度设计）
• 问题定位和根因分析（豆包给建议，我自己复现、验证、修正）
• 效果验证和流程闭环确认

我的认知：AI能提升编码效率，但不能替代产品思考。一个项目的价值不在于"代码是谁写的"，而在于"为什么这么设计、遇到问题怎么定位和解决、最终效果是否达到业务目标"。这些是AI替代不了的，也是我在这个项目中重点锻炼的能力。

---

四、开发实战踩坑记录

这部分是本文的重点。我记录了开发过程中遇到的四个真实坑点，以及我的定位和解决过程。

4.1 坑一：对话数据保存逻辑bug，Agent"假装回复"

现象：在Agent助手页面输入问题，点击发送后，界面显示"正在输入…“，然后typing动画消失，但没有任何AI回复出现。看起来Agent"假装思考了一下然后什么都没说”。

定位过程：

1. 首先检查 sendMessage 函数有没有被触发——加了console.log，确认函数执行了
2. 检查 processAgent 函数有没有返回结果——加了log，确认返回了正确的回复内容
3. 检查回复有没有被push到对话数组——加了log，确认push成功了
4. 检查 renderMessages 有没有正确渲染——加了log，发现渲染的是空数组

根因：问题出在数据保存逻辑。我的代码是这样写的：

// 有问题的代码
let conv = getCurrentConv();  // 从localStorage读取对话
conv.messages.push(aiReply);   // 修改conv对象
saveConversations(getConversations());  // 又从localStorage读取一遍来保存！

4.2 坑二：模拟大模型输出与输入完全无关，像 "人工智障"

现象：在 Prompt 工作台调试功能中，输入 "产品：可乐，卖点：物美价廉，受众：学生"，点击运行调试，输出的却是一段关于 "智能保温杯、24 小时保温、LED 温度显示" 的文案，和可乐完全无关。

定位过程：

1. 检查测试输入有没有正确传入 —— 加 log，确认输入参数正确
2. 检查 Prompt 模板有没有正确拼接 —— 确认拼接正确
3. 检查 simulateLLM 函数 —— 发现问题了

根因：我的 simulateLLM 函数写死了固定模板，完全没有使用传入的测试输入：

// 有问题的代码
function simulateLLM(prompt, question) {
  if (prompt.includes('文案')) {
    return '【产品推广文案】✨ 标题：一握温暖，全天相伴\n\nXXX智能保温杯，采用316不锈钢内胆...';
    // 永远返回保温杯文案，不管question是什么！
  }
}

这个函数只判断了 Prompt 的类型，然后返回对应类型的固定模板，完全忽略了用户的测试输入。所以不管输入可乐还是咖啡，输出都是保温杯。

解决方案：重写 simulateLLM，增加字段提取逻辑，从测试输入中解析产品名、卖点、受众等信息，然后动态生成输出：

// 修复后的代码（简化版）
function simulateLLM(prompt, question) {
  // 从测试输入中提取字段
  function extractField(text, keys) {
    for (const k of keys) {
      const re = new RegExp(k + '[：:]?\\s*([^\\n,，；;]+)');
      const m = text.match(re);
      if (m) return m[1].trim();
    }
    return '';
  }
  
  const product = extractField(question, ['产品名称', '产品', '商品']);
  const selling = extractField(question, ['核心卖点', '卖点', '优势']);
  const audience = extractField(question, ['目标受众', '受众', '用户']);
  
  // 用提取的信息动态生成输出
  if (prompt.includes('文案')) {
    return `【产品推广文案】\n\n✨ 标题：${product}——${selling.split('、')[0]}，值得拥有\n\n🎯 面向${audience}，${product}带来全新体验！\n\n${selling.split('、').map(s => '💎 ' + s).join('\n')}\n\n...`;
  }
}

修复后，输入 "产品：可乐，卖点：物美价廉，受众：学生"，输出会围绕可乐、物美价廉、学生群体展开，不再出现保温杯。

教训：模拟函数不能 "只判断类型返回模板"，必须真正使用输入参数。否则模拟就失去了意义，还会误导你以为流程有问题。

4.3 坑三：版本回滚设计的误区

现象：最初版本的回滚功能是 "把目标版本的内容直接覆盖到当前版本"，回滚后历史版本列表里最新版本号不变，但内容变了。

问题分析：这个实现虽然功能上 "能用"，但有两个严重问题：

1. 回滚操作本身不可追溯—— 从 v3 回滚到 v1 后，v3 的内容被覆盖了，你再也看不到 v3 原来是什么，也不知道 "什么时候回滚的"
2. 违反了版本不可变原则—— 版本记录应该是只增不改的，覆盖修改破坏了审计链路

解决方案：重新设计回滚逻辑 —— 回滚不是覆盖，而是把目标版本内容复制一份，作为新版本保存：

function rollback(promptId, targetVersion) {
  const target = DB.query('prompt_versions', {prompt_id: promptId, version: targetVersion})[0];
  const current = DB.findById('prompt_templates', promptId);
  const newVersion = current.current_version + 1;
  
  // 新增一条版本记录，内容和目标版本相同
  DB.insert('prompt_versions', {
    prompt_id: promptId,
    version: newVersion,
    content: target.content,
    editor: '当前用户',
    change_note: `回滚到v${targetVersion}`,  // 明确记录这是回滚操作
    created_at: now
  });
  
  // 更新主表当前版本指针
  DB.update('prompt_templates', promptId, {
    content: target.content,
    current_version: newVersion,
    updated_at: now
  });
}

这样设计后，从 v3 回滚到 v1 会生成 v4（内容同 v1，变更说明为 "回滚到 v1"），完整历史链路保留，回滚操作本身也可审计。

教训：企业级系统的 "回滚" 不是 "撤销"，而是 "新增一个反向操作"。这和 Git 的 revert、数据库的回滚日志是同一个思路 —— 所有操作都是只增不改的，历史永远不可篡改。

4.4 坑四：localStorage 数据初始化的竞态问题

现象：偶尔刷新页面后，示例数据会重复出现，比如同一个提示词出现两条一模一样的记录。

定位过程：

1. 检查初始化函数 initData() 的执行时机 —— 发现它在 DOMContentLoaded 事件中执行
2. 检查初始化判断条件 ——if (localStorage.getItem('app_init')) return;
3. 复现问题 —— 快速连续刷新页面，偶尔能复现重复数据

根因：竞态条件。initData() 先检查 app_init 标记，发现不存在，然后开始写入 5 条提示词数据。但写入需要时间（虽然 localStorage 是同步的，但多条写入之间有时间窗口）。如果在第一条数据写入后、app_init 标记设置前，页面被刷新或另一个初始化逻辑触发，就会导致重复写入。

解决方案：把 "设置初始化标记" 放在数据写入之前，作为 "锁"：

function initData() {
  if (localStorage.getItem('app_init')) return;
  localStorage.setItem('app_init', '1');  // 先加锁，防止重复初始化
  try {
    // 写入示例数据
    samplePrompts.forEach(p => DB.insert('prompt_templates', p));
    // ... 其他初始化
  } catch (e) {
    // 如果初始化失败，清除锁，允许下次重试
    localStorage.removeItem('app_init');
    console.error('初始化失败', e);
  }
}

教训：凡是 "检查 - 然后 - 写入" 的模式，都存在竞态风险。关键操作要先加锁再执行，失败要释放锁。这在分布式系统中是基本常识，但在前端 localStorage 中同样适用。

---

五、AI Agent 常见问题与我的解决方案

Agent 开发是这个项目中技术含量最高的部分，也是坑最多的部分。我总结了四个 Agent 常见问题，以及我的解决思路。

5.1 问题一：工具调用不准确 —— 该调不调，不该调乱调

现象：

• 用户问 "现在几点了"，Agent 不调用时间工具，直接瞎编一个时间
• 用户问 "帮我写个文案"，Agent 却调用了计算器工具
• 工具调用准确率初期只有约 60%

原因分析：

1. 工具描述太笼统 —— 比如计算器工具只写了 "执行计算"，Agent 不知道什么场景该用
2. 系统提示词没有给明确的判断规则
3. 意图识别逻辑太简单，只靠关键词匹配，边界 case 处理不好

我的解决方案：

第一，优化工具描述，明确适用场景：

// 优化前
{ name: "计算器", description: "执行数学计算" }

// 优化后
{ 
  name: "计算器", 
  description: "执行数学表达式计算。当用户需要进行加减乘除、复杂表达式计算、百分比计算时调用。触发词：等于多少、帮我算、计算、算一下。" 
}

工具描述越具体，Agent 判断越准确。

第二，在系统提示词中增加判断规则和示例：

明确告诉 Agent：

• 什么情况必须调用工具（涉及实时数据、企业内部数据、数学计算）
• 什么情况不要调用工具（通用问答、闲聊、创意写作）
• 给出 few-shot 示例

第三，通过日志分析持续优化：

我把每一次工具调用都记录到日志中，然后定期分析：

• 哪些问题该调工具但没调？→ 优化工具描述或意图识别
• 哪些问题调错了工具？→ 明确工具之间的边界
• 哪些问题不需要调工具但调了？→ 优化判断规则

通过这种数据驱动的迭代，工具调用准确率从 60% 提升到了 95% 以上。

5.2 问题二：RAG 幻觉严重 —— 不知道的也瞎编

现象：用户问 "公司明年的战略规划是什么"，知识库中没有这个内容，但 Agent 一本正经地编了一段 "战略规划"，看起来像真的一样。

原因分析：

1. 检索阈值太低 —— 不相关的内容也被检索出来，给了 Agent"编" 的素材
2. 系统提示词没有硬约束 ——Agent 倾向于 "尽量回答"，而不是 "不知道就说不知道"
3. 没有对检索结果做相关性校验

我的解决方案：两层幻觉控制

第一层：检索阈值过滤

设置相似度阈值，低于阈值的内容不返回给大模型。避免 "勉强找一段不相关的内容让 Agent 硬编"。

function searchKB(query) {
  const results = vectorSearch(query);  // 向量检索
  const threshold = 0.5;  // 相似度阈值
  const filtered = results.filter(r => r.score >= threshold);
  return filtered.length > 0 ? filtered : [];  // 低于阈值返回空
}

第二层：系统提示词硬约束

在 Agent 的系统提示词中明确规定：

• 只能基于检索到的文档内容回答
• 检索结果为空时，必须回复 "抱歉，该问题不在当前知识库范围内"
• 禁止编造文档中没有的信息
• 回答中标注信息来源

# 知识库问答规则
当用户问题涉及企业内部信息时：
1. 只基于检索到的文档内容回答，不得编造文档中没有的信息
2. 如果检索结果为空或相似度低，必须回复："抱歉，该问题不在当前知识库范围内，建议咨询相关部门。"
3. 回答中关键信息后标注来源，如 [来源：员工手册]
4. 通用知识问题（不涉及企业内部）正常回答，不强制使用知识库

效果：优化后，知识库外问题的拒答率达到 100%，不再出现幻觉内容。

我的思考：很多人做 RAG 只关注 "检索准确率"，但忽略了 "拒答能力"。企业级场景下，AI 说 "我不知道" 比 AI 瞎编一个错误答案强一百倍。幻觉控制不是 "让 AI 更聪明"，而是 "让 AI 知道自己的边界"。

5.3 问题三：多轮对话指代理解失败 ——"他" 是谁？

现象：

• 用户："研发部有哪些人？" → Agent 正确返回王芳、赵强
• 用户："王芳的邮箱是多少？" → Agent 能理解，返回邮箱
• 用户："她什么时候入职的？" → Agent 懵了，不知道 "她" 指谁，或者返回错误信息

原因分析：

1. 每轮对话独立处理，没有把历史消息传入意图识别
2. 没有指代消解逻辑 —— 遇到 "他 / 她 / 它 / 这个" 时，不会回溯上文
3. 工具参数提取只看当前输入，不继承上一轮的查询上下文

我的解决方案：

第一，意图识别时传入完整对话历史：

async function processAgent(input, history) {
  // history是完整的对话历史，不只是当前输入
  const intent = detectIntent(input, history);
  // ...
}

第二，增加指代消解逻辑：

在 detectIntent 函数中，如果检测到指代性表达（他 / 她 / 它 / 这个 / 那个 / 刚才），回溯上一轮 AI 回复：

function detectIntent(input, history) {
  // ... 正常意图识别
  
  // 指代消解：如果当前输入有指代性表达，且上一轮调用了员工查询
  const lastAssistantMsg = [...history].reverse().find(m => m.role === 'assistant' && m.tool_name === 'query_employee');
  if (lastAssistantMsg && /他|她|它|这个|那个|联系方式|邮箱/.test(input)) {
    // 继承上一轮的查询参数
    const lastParams = JSON.parse(lastAssistantMsg.tool_params);
    return { type: 'employee', followUp: true, inheritedParams: lastParams };
  }
  
  // ...
}

第三，工具参数提取时优先继承上下文：

如果当前输入没有明确提到姓名 / 部门，但上一轮查过员工信息，就继承上一轮的查询参数。

效果：优化后，三轮以上的连续追问（如 "研发部有哪些人→王芳的邮箱→她什么时候入职的"）能 100% 正确理解指代。

我的思考：多轮对话的核心不是 "记住历史"，而是 "理解指代"。很多 Demo 号称支持多轮对话，但只是把历史消息拼进去，没有真正的指代消解。真正的多轮对话需要处理 "他是谁"" 这个指什么 " 这类问题，这才是 Agent 能力的体现。

5.4 问题四：执行链路不可观测 —— 出了问题无法定位

现象：Agent 回答错了，但不知道是哪里错了 —— 是意图识别错了？工具调用错了？参数提取错了？还是结果整理错了？完全黑盒。

原因分析：没有日志系统，每一步的中间结果都没有记录。

我的解决方案：完整执行链路日志

为每一轮对话记录完整的执行链路：

字段	说明
时间戳	对话发生时间
用户提问	原始输入
意图识别结果	判定的意图类型
是否调用工具	是 / 否
调用工具名称	如 get_current_time
工具参数	JSON 格式
工具返回结果	原始返回
最终回答	AI 整理后的回复
响应耗时	毫秒级

日志面板支持：

• 统计概览（总对话数、工具调用率、平均耗时）
• 按日期 / 关键词筛选
• 点击展开查看完整链路
• 导出 JSON

效果：有了日志后，定位问题从 "猜" 变成了 "看"。比如 Agent 回答错误，打开日志一看 —— 哦，意图识别把 "研发部有哪些人" 识别成了 "通用对话"，没有调用工具。问题一目了然，直接去优化意图识别逻辑。

我的思考：可观测性不是 "锦上添花" 的功能，而是 AI 系统的 "第二生命线"。传统软件出 bug 了可以复现、可以打断点，但 AI 系统的输出是概率性的、不可控的，没有日志就无法定位问题、无法持续优化。我在项目早期就把日志系统作为 P0 需求来设计，而不是最后再加。

---

六、问题定位与 Agent 工作流调整

6.1 我的问题定位方法论

在开发 Agent 的过程中，我总结了一套问题定位的方法：

第一步：复现问题

• 记录导致问题的具体输入
• 多次复现，确认是稳定问题还是偶发问题
• 检查是否和上下文有关（单轮没问题但多轮有问题？）

第二步：查看执行日志

• 找到对应对话的完整执行链路
• 逐环节检查：意图识别→工具选择→参数提取→工具执行→结果整理
• 定位是哪个环节出了问题

第三步：假设根因

• 根据出错环节，假设可能的根因
• 比如意图识别错了→可能是关键词匹配规则有漏洞，或者工具描述不够明确

第四步：验证假设

• 针对性地修改（比如增加关键词、优化工具描述）
• 用同样的输入测试，确认问题是否解决
• 用更多边界 case 测试，确认没有引入新问题

第五步：回归验证

• 跑一遍之前的测试用例，确认修改没有破坏已有功能

6.2 工作流调整实例：从 "单轮问答" 到 "意图识别→工具路由→结果整理"

初始工作流（有问题的版本）：

用户输入 → 直接传给大模型 → 大模型输出 → 回复用户

这个工作流的问题：大模型自己决定要不要 "模拟" 调用工具，结果就是 —— 有时候调用了，有时候没调用，完全不可控。

调整后的工作流：

用户输入 + 对话历史
    ↓
意图识别（关键词匹配 + 上下文继承）
    ↓
┌─────────┬──────────┬──────────┬──────────┐
↓         ↓          ↓          ↓          ↓
时间意图  数据意图   计算意图   知识库意图  通用对话
↓         ↓          ↓          ↓          ↓
时间工具  数据工具   计算器     RAG检索    通用回复
↓         ↓          ↓          ↓          ↓
结果整理为自然语言
    ↓
回复用户 + 记录完整日志

关键调整点：

1. 意图识别前置：不让大模型决定要不要调工具，而是由明确的意图识别逻辑先判断
2. 工具路由显式化：每种意图对应明确的工具，不再是大模型 "自由发挥"
3. 结果整理标准化：工具返回的原始数据（JSON / 数组）统一整理为自然语言再回复
4. 日志贯穿全链路：每个环节的中间结果都记录

调整前后效果对比：

指标	调整前	调整后
工具调用准确率	~60%	95%+
多轮指代理解成功率	~40%	90%+
知识库幻觉率	~30%	0%（明确拒答）
问题定位时间	不确定（靠猜）	<1 分钟（看日志）

【此处插入 Agent 工作流调整前后对比图】

6.3 一个具体的调整案例

问题：用户问 "帮我算一下如果每个月目标 50 万，上半年实际完成 330 万，完成率是多少"，Agent 没有调用计算器，而是用通用对话回复了一段不相关的内容。

日志定位：打开日志，发现意图识别把这个问题识别成了 "通用对话"，没有触发计算器意图。

根因分析：计算器意图的关键词匹配规则只匹配了 "等于多少"" 计算 "等直接表达，但这个问题用的是" 完成率是多少 "，没有直接触发计算关键词。

调整：

1. 在计算器意图的关键词中增加 "完成率"" 占比 ""比例"" 率是多少 " 等表达
2. 增加正则匹配：如果输入中包含数字和数学关系描述（如 "目标 X，实际 Y"），也触发计算意图
3. 在结果整理中，对 "完成率" 类问题自动计算并给出百分比

验证：用同样的输入测试，Agent 正确调用计算器，返回 "完成率 = 330 / (50×6) = 110%"。再用更多边界 case 测试，确认没有误触发。

这个案例让我深刻体会到：Agent 的优化是数据驱动的持续迭代过程，不是一次设计就能完美的。日志系统是这个迭代过程的基础设施。

---

七、系统运行效果

7.1 Prompt 工作台效果

Prompt 工作台实现了三栏布局：

• 左侧：分类列表 + 新建按钮 + 组件库
• 中间：提示词卡片网格，支持搜索、排序、视图切换
• 右侧：调试 / 版本 / 评测三个 Tab 面板

核心功能全部可用：

• 提示词的增删改查
• 版本自动保存、差异对比、一键回滚（不可变设计）
• 单条调试、批量评测（三维度自动打分）
• 3 个组件化 Prompt（文案生成 / 数据分析 / 代码调试）

7.2 Agent 助手效果

Agent 助手实现了：

• 多轮对话，支持指代理解
• 3 个工具自主调用（时间 / 数据 / 计算器）
• RAG 知识库问答（5 篇企业文档，幻觉控制）
• 完整执行链路日志

实际测试效果：

• 工具调用准确率 95%+
• 多轮连续追问（3 轮以上）指代理解成功率 90%+
• 知识库外问题 100% 明确拒答
• 平均响应时间 < 2 秒

7.3 执行日志效果

日志面板实现了：

• 统计卡片（总对话数、工具调用次数、平均耗时）
• 日志列表（时间、提问、工具、耗时）
• 点击展开完整执行链路
• 日期筛选、关键词搜索
• 导出 JSON

---

八、项目反思：AI Agent 做这个项目的优势与局限

8.1 优势

1. 快速验证产品想法

有了 AI 作为效率工具，我可以在很短的时间内把产品想法变成可运行的 Demo。如果纯手写代码，这个项目可能需要 2-3 周；用 AI 辅助编码，我把更多时间花在设计和问题定位上，一周左右就完成了核心功能。

2. 降低技术门槛，聚焦产品思考

我不是专业前端开发，某些复杂的 UI 组件和交互效果手写会很耗时。AI 可以快速给出代码初稿，我审核修改后使用。这让我能把精力集中在产品逻辑、业务流程、用户体验这些核心能力上，而不是纠结于 CSS 细节。

3. 辅助问题排查

遇到报错时，把错误信息和相关代码贴给 AI，它能快速给出可能的原因和排查方向。虽然最终的验证和根因分析需要我自己做，但 AI 帮我缩小了排查范围，提升了效率。

8.2 局限性

1. AI 生成的代码有 "看起来对但其实有坑" 的问题

比如本文记录的 "对话数据保存 bug"，AI 生成的初稿逻辑看起来没问题，但实际运行时因为引用问题导致数据丢失。这种问题 AI 自己发现不了，必须靠人去复现、定位、修正。

2. AI 不理解业务上下文

AI 可以生成 "版本回滚" 的代码，但它不会想到 "企业级回滚应该是新增版本而不是覆盖" 这种业务决策。这种设计决策必须由人来做，AI 只是执行工具。

3. AI 无法做端到端的流程验证

AI 可以帮你写每个功能的代码，但 "整个流程能不能跑通、数据能不能正确流转、边界 case 有没有覆盖" 这些必须由人来测试和验证。我在项目中遇到的多个 bug（竞态条件、指代理解失败）都是在端到端测试中发现的，AI 在编码阶段完全没有预警。

4. AI 倾向于 "给答案" 而不是 "提问题"

当我描述需求时，AI 倾向于直接给实现方案，而不会质疑 "这个需求合理吗"" 有没有更好的方案 ""这个设计有什么风险"。人的核心价值之一是提出好问题、做正确的决策，这是 AI 替代不了的。

8.3 我的核心认知

做完这个项目，我对 "AI 在产品开发中的角色" 有了明确的认知：

AI 是效率工具，不是决策者。业务校验、流程闭环、设计决策由人把握。

具体来说：

• AI 可以提升编码效率，但产品设计、架构选型、业务逻辑设计必须由人主导
• AI 可以辅助问题排查，但根因分析、验证确认、回归测试必须由人完成
• AI 可以生成初稿，但质量把控、效果验证、流程闭环必须由人负责
• AI 可以给建议，但最终决策、优先级排序、风险判断必须由人拍板

---

九、项目总结：这个项目让我收获了什么

1. 完整的 AI 产品从 0 到 1 经验

从业务分析、需求拆解、架构设计到编码实现、问题定位、效果验证，我完整走了一遍 AI 产品的开发流程。这种端到端的经验比 "调一个 API 做个 Demo" 有价值得多。

2. 对 Prompt 工程的深度理解

通过设计版本管理、评测体系、组件化，我对 Prompt 工程的理解从 "写好提示词" 升级到了 "Prompt 全生命周期治理"—— 创建、版本、评测、上线、优化，每个环节都有明确的方法论。

3. 对 Agent 开发的实战经验

通过解决工具调用、RAG 幻觉、多轮指代、可观测性等问题，我对 Agent 开发的核心挑战有了实战经验，而不是停留在概念层面。

4. 问题定位和调试能力

项目中踩的四个坑、Agent 的四个常见问题，每一个都经历了 "复现→定位→假设→验证→修正→回归" 的完整过程。这种问题定位能力是工程师和产品经理的基本功。

5. 对 AI 角色的清晰认知

明确了 AI 是效率工具而非决策者，人必须把握业务校验和流程闭环。

---

写在最后

这个项目从想法到落地，我花了大约五天时间。它不是一个完美的产品，还有很多局限（单用户、无权限体系、模拟大模型等），但它是我独立思考、独立设计、独立解决问题的完整记录。

AI 时代，工具会越来越强大，编码门槛会越来越低。但发现问题的能力、设计解决方案的能力、定位和解决问题的能力、对业务的深度理解—— 这些是 AI 替代不了的，也是我在这个项目中重点锻炼的能力。

如果你看到这里，希望这篇文章对你有帮助。也欢迎在评论区交流你的 AI 项目经验。

---

本文为个人项目实战记录，欢迎转载，转载请注明出处。