半天做一个企业AI问答助手：别一上来就RAG

Duty
Bloger
Page content

半天做一个企业AI问答助手：别一上来就RAG by AI Native启示录

封面

阅读提示：本文干货密集，文末附完整的 系统提示词 和Demo 源码（Python + Java）。建议先点赞 + 收藏，找个安静的时间细读。

系列导航：深入 LLM 本质、摸清 API 特性之后，你会发现应用层开发其实可以很简单。这也是我为什么一直推荐大家从 LLM 接口调用开始，手写自己的 AI Agent——只有亲手写过，才知道哪些复杂度是必要的，哪些是自己吓自己。

上面是理论和练习，本篇是实战——把学到的东西用在一个真实的企业场景里。

先说结论

这篇文章会告诉你三件事：

  1. 80% 的企业知识问答，不需要 RAG
  2. 一个极简架构，半天就能跑起来
  3. 为什么这比 RAG 更稳定

如果你只有 30 秒，记住这句话：不是 LLM 做不好问答，是我们把系统设计得太复杂了。

如果你想知道为什么，往下看。

一、别急着上 RAG

最近很多人问我：

企业知识问答是不是一定要上 RAG + 向量数据库 + embedding？

我的答案是：80% 的场景，根本不需要。

很多团队一上来就：

  • 向量数据库
  • embedding pipeline
  • chunk 切分
  • 召回排序
  • 多轮检索

结果呢？

系统还没上线，人已经累死了。

但如果你换一个思路，用AI Native的思路去设计，很多问题其实简单得多。

我最近做了一个企业员工问答助手 demo，只用了三样东西：

  • LLM
  • Skills（技能知识块）
  • 一个简单的 Orchestrator

半天跑起来，甚至连 RAG 都没用。

你的团队做企业问答系统，花了多久？评论区聊聊。

二、AI Native 的核心：LLM 不只是回答者

传统系统是这样设计的：

数据库 → 后端逻辑 → 接口 → 前端

AI Native 应用完全不同：

用户问题 → LLM 路由 → Skill（知识块） → LLM 生成回答

说人话：LLM 不只是那个回答问题的"打工仔"，它同时还是路由器、决策器、编排器。

这是思维方式的根本转变。

三、架构只有两步

整个系统只有两步。没有多余的东西。

第一步：意图识别 + Skill 路由

用户提问：

怎么申请 VPN？

LLM 根据 Skills 的 meta 信息判断该走哪个 Skill：

json
{
  "intent": "咨询如何申请公司VPN",
  "skill": "sk-it-helpdesk"
}

Skill 的 meta 信息很简单：

json
{
  "skill_id": "sk-it-helpdesk",
  "summary": "IT服务台工单、VPN申请、软件安装、设备问题",
  "keywords": ["VPN", "电脑", "软件安装", "IT工单"],
  "examples": [
    "怎么申请VPN？",
    "电脑坏了找谁修？"
  ]
}

LLM 只需要根据意图 + 示例 + 关键词做语义匹配。

就像一个智能路由器。

第二步：加载 Skill 内容，生成回答

选中 Skill 后，系统加载对应内容：

xml
<skill_content skill_id="sk-it-helpdesk">
VPN申请流程：
1. 登录IT自助平台
2. 选择VPN申请
3. 填写申请表
4. 审批后开通
</skill_content>

LLM 根据这些内容生成最终回答：

VPN 申请流程：

  1. 登录 IT 自助平台 https://it.example.com
  2. 进入 服务目录 → 网络服务 → VPN 开通申请
  3. 填写申请表（工号、部门、用途）
  4. 审批流程：直属主管 → IT 安全组

审批通过后 1 个工作日内开通。

整个过程：两次 LLM 调用。这就是完整系统。

四、为什么不需要 RAG

很多人一做知识问答就说：要上 RAG，不然 LLM 会胡说。

这是误解。

LLM 之所以"胡说"，大多数原因是：没有约束数据来源。

在这个系统里，我们做了一个简单规则：

规则
说明
LLM 只能回答 Skill 内容中的信息
不能编造
如果知识库里没有答案
必须回答"未在已加载知识中找到答案"

就这两条，幻觉基本就没了。

说人话：不是用更复杂的技术去"修"幻觉，而是从源头上不给 LLM 胡说的机会。

这比 RAG 更稳定、更可控。

我知道有人会反对："RAG 在大规模知识库场景下不可替代。" 没错。但你确定你的场景是"大规模"吗？评论区说说你的知识库有多大。

五、权限控制也可以很简单

企业知识里有很多敏感内容，并不是开放给所有员工提问的，如：薪资带宽、调薪比例、某些部门架构……

只需要在 Skill 内容里加一个标记，例如：

🔒 所需权限：salary_band_view

LLM 看到这个标记，就会调用权限校验工具：

python
check_user_permission(user_id, permission_type)

没有权限？AI 直接回答：

该信息属于薪酬敏感数据，仅 HRBP 或薪酬管理角色可查看。

建议联系 HRBP 或薪酬福利组。

六、真实对话长什么样

光说思路和架构不够直观，先看一下 Python 版本和 Java 版本跑起来的实际效果：

普通问题

员工：我的电脑VPN不能登录了

image-20260314011939328

敏感问题

员工：各职级薪资范围是多少？

image-20260314012121615

Java端的使用截图

java

七、Skill 也可以让 AI 生成

很多人看到 Skill 会觉得：维护知识库很麻烦。

其实现在可以直接让 AI 生成。

用 Claude Code / AI Agent 自动把文档转成 Skill：

  • 员工手册 → Skill
  • IT 指南 → Skill
  • 报销制度 → Skill
  • 行政流程 → Skill

全部自动整理，甚至可以自动拆章节。

这些工作用现成的 AI Agent 或工具就能完成。

我见过有团队把"自动生成 Skill"也做成了系统的一部分——文档上传、自动解析、自动入库、自动更新。看起来很自动化，但代价是系统复杂度翻了好几倍。

ROI （投资回报率）很重要。不是所有自动化都值得做到系统里。

有些事情频率低、变化少，用工具手动跑一次就行了。把它做成系统功能，看起来高大上，但投资回报率极低。

八、这只是"半 AI Native"

我为什么说这只是半 AI Native？

因为真正的 AI Native，根本不会等员工来问问题。

想想看：员工为什么要问"怎么申请 VPN"？

因为他不知道流程。但公司明明有文档，只是他找不到、懒得找、或者根本不知道该找什么。

全 AI Native 的做法是：在问题发生之前就主动解决它。

比如：

  • 新员工入职第一天，AI 主动推送：这是你需要的 VPN、邮箱、工牌申请流程
  • 员工调岗，AI 自动提醒：你的权限需要变更，这是操作指引
  • 报销季到了，AI 提前告诉你：截止日期、注意事项、常见被退回的原因
事件触发 → Agent 感知 → 主动推送解决方案 → 员工根本不用问

最好的问答系统，是让人不需要问。

但这需要打通更多系统（HR、OA、日历……），工程量不小。所以现阶段，"半 AI Native"的问答助手，已经是性价比最高的选择。

但对于 80% 的企业问答场景，"半 AI Native"已经够用了。

九、很多人把简单问题做复杂了

我见过太多团队这样做企业问答：

RAG + 向量数据库 + embedding pipeline + chunk + rerank

然后一个简单的问题——"怎么申请 VPN"——系统要跑：

embedding → 检索 → 排序 → 拼 prompt → 生成

工程复杂度直接爆炸。

但实际上：一个 Skill 就够了。

方案
开发时间
维护成本
回答质量
RAG 全套
2-4 周
高
取决于检索质量
Skill 方案
半天
低
稳定可控

说人话：不是说 RAG 没用，而是你可能根本不需要用那么重的方案。

十、AI Native 的关键不是技术

而是思维方式。

传统开发思维
AI Native 思维
先设计系统，再接 AI
先让 AI 解决问题，再补系统
架构驱动
问题驱动
复杂度优先
简单优先

很多应用，其实只需要：

LLM + Skills + Orchestrator

三样东西，就能跑起来。

最后

这个员工问答助手：

  • 开发时间
    半天
  • 核心组件
    LLM + Skills + Orchestrator
  • 没有
    向量数据库、embedding pipeline、RAG 复杂架构

但已经可以解决HR 政策、IT 问题、行政流程、财务报销、组织架构等 80% 的员工问题。

不是 LLM 做不好问答，是我们把系统设计得太复杂了。

AI Native 的世界里，有时候最好的架构是：简单。

关于代码

这个案例的完整系统提示词和代码我放在了 GitHub 上，Python 和 Java 两个版本都有。

但我要先说清楚：Demo 的代码是故意写得简单的。

因为我的目的是让你看到思路，而不是给你一个可以直接上生产的系统。

实际落地的时候，你可能需要：

  • 用数据库存储 Skill 和对话记录
  • 集成公司内部的 REST 接口
  • 对接文件系统、OA、HR 系统
  • 加上用户认证和审计日志

这些都是工程问题，大家各自发挥。

但我想强调一点：

有些问答场景，你乍一看觉得搞不定——别急着放弃。

很多时候，只需要再加一层 LLM 分析编排，或者集成一个 Tool Calling，问题就解决了。

说人话：就像软件架构里那句经典的话——"没有什么问题是加一层解决不了的"。AI 应用也一样。

所以不要被 demo 代码限制了思路。我放出代码，是让大家有个直观感受，也让这篇文章不至于"空谈"，但希望不要限制了大家的想象空间。

代码在 GitHub 上，感兴趣的自取：

https://github.com/goeasyway/qa_assistant_without_rag

遇到问题欢迎评论区交流。

这是「AI Native 实战」系列文章。

原文链接