企业官网建设流程全解析

1. 为什么“智能问数”成了AI落地的高价值场景

在传统BI工具的使用中，业务用户获取数据的方式通常是这样的：业务运营想要看“华东区上个月的销售额”，需要先找到数据分析师提需求，数据分析师根据维度、指标、时间范围写一段SQL，再跑到数据仓库里执行，最后把结果导出成Excel发回去。这个过程少则半天，多则两三天。如果数据口径不对、维度要调整，又得重新来一轮。

这种“人工取数”的模式，消耗的是数据分析师的时间，消耗的是业务等待的耐心，也直接拉低了企业数据决策的响应速度。很多公司的数据仓库里有大量报表，但业务真正想问的问题往往不在现成报表里，必须临时取数。于是，“智能问数”这个概念在AI大模型成熟之后迅速火了起来。

智能问数，本质上是利用大语言模型的语义理解能力和文本转SQL能力，让用户用自然语言提问，系统自动生成SQL并返回查询结果。它属于“生成式BI”的一个具体实现形态。所谓生成式BI，是指不再局限于预定义维度和指标，而是由AI根据用户的问题动态生成分析逻辑，输出新的查询、图表甚至分析结论。生成式BI不是传统的“看板式BI”，它强调的是“问”而不是“看”。

智能问数能解决什么问题？可以从三个层面来看：

• 取数效率：业务用户直接提问，系统自动出结果，不再需要排队等数。
• 数据民主化：非技术人员也能用自然语言访问数据仓库，降低数据使用门槛。
• 报表供给不足：不需要预先建好所有报表，长尾查询需求由AI动态满足。

从产品经理角度看，智能问数不是一个“炫技”项目，而是一个有明确ROI的数据产品项目。它要求产品经理既懂业务场景，又懂大模型能力边界，还要能把控从需求到落地的完整流程。这也是为什么“AI产品经理”这个角色在近两年越来越受关注。

2. 产品经理做智能问数，先在需求侧想清楚

很多团队启动智能问数项目时，第一反应是“先接入大模型，把SQL生成搞定再说”。这个思路大概率会踩坑。智能问数项目的难点，不在大模型本身，而在需求侧的理解和产品边界定义。

2.1 用户画像与使用场景

智能问数的目标用户，可以分为三类：

不同用户对答案的“严谨度”要求完全不同。管理层可能只需要一个趋势大数，运营则需要明细数据落地到Excel继续加工，财务等强管控场景则要求数据口径必须100%准确。产品经理如果要做一个“什么人都能用”的入口，最后往往什么人也服务不好。

比较务实的做法是：先选一个核心场景切入。比如“销售额查询”或“经营日报生成”，把用户范围、问题类型、数据范围都限定住，跑通之后再横向扩展表覆盖范围。

2.2 智能问数不等于“取代BI”

产品经理容易犯的第二个误区，是把智能问数当成BI系统的替代品。实际上，两者是互补关系。

传统BI擅长做固定报表、核心指标监控、数据下钻分析，这些场景数据口径稳定、图表交互复杂，用BI更合适。智能问数擅长的是临时性、长尾化、低复杂度的取数需求，比如“帮我看下昨天新客的客单价分布”。

所以智能问数产品的正确产品定位应该是：BI报表的补充入口，降低取数门槛，让业务自助解决简单查询，把数据分析师从重复取数中解放出来，去做更深度的分析。

2.3 非功能需求要提前定义

除了功能范围，产品经理在需求阶段就要明确以下非功能约束：

• 准确性：SQL生成准确率能否达到业务可用门槛？哪些场景不允许出错？
• 安全性：用户提问是否可能触发敏感数据泄露？如何做权限隔离？
• 可解释性：用户看到查询结果时，能否知道自己看的是什么口径？
• 响应时间：正常查询需要在多少秒内返回结果？
• 可回退性：结果错误时，用户如何反馈和修正？

这些约束会直接影响后续的模型选型、架构设计、提示词工程和评测方案。把需求侧定义清楚，再进入技术方案阶段，项目的成功率会高很多。

3. 智能问数核心链路与产品架构

从用户输入一句自然语言，到取数结果渲染在界面上，中间要经过六个环节。下面把每个环节的职责拆开看。

3.1 完整链路拆解

智能问数系统的处理流程可以概括为：

用户提问 -> 意图判断与问题改写 -> 检索相关表结构 -> 生成SQL -> 安全校验 -> 执行查询 -> 结果解释

意图判断与问题改写：大模型先判断用户是不是真的在问数据。比如“你好”这种闲聊，就不应该进入SQL生成环节。如果用户说的是“帮我查一下上个月每天的新增用户数”，模型需要把“上个月”转换为具体的日期范围，把“新增用户数”对齐到对应的指标口径。

检索相关表结构：企业数据仓库可能有几百张表，不可能把全部Schema塞给大模型。这一步通常依赖关键词匹配或向量检索，找出与当前问题相关的一批表和字段定义。

生成SQL：把用户的标准化问题、相关表结构、业务口径提示词组合成Prompt，交给大模型输出SQL。这是整个链路的核心步骤。

安全校验：至少做两道检查。第一道检查生成的SQL语法是否正确；第二道检查SQL是否越权，比如用户是否查询了权限范围外的表或字段，是否包含DELETE、UPDATE等危险操作。

执行查询：使用只读数据库账号执行SQL，并设置超时时间和返回行数限制。

结果解释：执行结果返回到大模型，让大模型根据问题和数据结果生成一段自然语言结论或解释，方便非技术用户理解。

3.2 产品与模型双视角的产品设计

智能问数产品从设计上可以拆成“模型侧”和“产品侧”两条线。

模型侧的任务是提升生成SQL的准确率，核心抓手包括：

• 表结构和字段注释的治理，字段名能不能清晰表达业务含义
• 语义层（指标字典、维度字典）的构建，让大模型能对齐口径
• 提示词模板的迭代，沉淀历史错误纠正策略
• Few-shot示例的选择和维护

产品侧的任务是提升用户的信任和体验，核心抓手包括：

• 展示“系统理解了什么”：让用户看到改写后的问题、识别出的条件和查询范围
• 展示“SQL长什么样”：给高级用户一个可校验的中间产物
• 一键反馈：结果不对时，用户可以标注错误原因
• 收藏与复用：常见问题沉淀成“快捷指令”，逐步减少重复问答

这两条线的工作可以并行推进，但产品经理需要有掌控力，因为很多模型侧的打磨体验最终要靠产品功能去承载。

3.3 技术选型的三种路线

从实现路径来看，智能问数项目有三种典型路线：

大多数企业的第一个版本建议走“RAG + 语义层”路线。它比纯Prompt更稳定，又比微调成本更低，适合快速验证业务价值。只有当准确性始终无法达标且积累了足够多的样本之后，才值得考虑微调方案。

4. 环境准备与项目结构

下面进入实战环节。我们搭一个最小可运行的智能问数Demo，重点演示核心链路和踩坑点。按照实际情况，示例代码使用Python + Flask实现HTTP接口，大模型调用采用OpenAI兼容接口。示例环境如下：

操作系统：Windows / macOS / Linux 均可 Python版本：3.9+ 数据库：MySQL 5.7 / 8.0 大模型：任何兼容OpenAI ChatCompletion接口的模型服务

版本不需要完全一致，重点是理解链路和可复现代码思路。如果还没有大模型API账号，可以用本地部署的Qwen、ChatGLM等开源模型的OpenAI兼容服务替代。

4.1 创建项目结构

先创建项目目录：

mkdir smart-bi-demo cd smart-bi-demo

项目文件结构如下：

smart-bi-demo/ ├── app.py # Flask入口，定义HTTP接口 ├── config.py # 配置项：数据库连接、模型API连接 ├── db_executor.py # 数据库连接与查询执行 ├── llm_client.py # 大模型调用封装 ├── prompts.py # 提示词模板 ├── schema.sql # 演示用的建表语句 └── requirements.txt

4.2 安装依赖

pip install flask pymysql openai

各依赖的用途：

• Flask：提供REST API服务。
• pymysql：连接MySQL，执行SQL。
• openai：调用兼容OpenAI接口的大模型服务。

requirements.txt内容如下：

flask>=2.0 pymysql>=1.0 openai>=1.0

5. 完整实战：搭建一个最小可运行的智能问数系统

5.1 设计数据库Schema

智能问数能生成正确SQL的前提，是数据库表结构和字段注释足够清晰。下面设计两张演示表：products（商品表）和orders（订单表）。

文件路径：schema.sql

CREATE DATABASE IF NOT EXISTS smart_bi_demo DEFAULT CHARSET utf8mb4; USE smart_bi_demo; CREATE TABLE IF NOT EXISTS products ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '商品ID', product_name VARCHAR(128) NOT NULL COMMENT '商品名称', category VARCHAR(64) NOT NULL COMMENT '商品类目', price DECIMAL(10,2) NOT NULL COMMENT '商品单价', created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' ) COMMENT='商品信息表'; CREATE TABLE IF NOT EXISTS orders ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '订单ID', order_no VARCHAR(32) NOT NULL COMMENT '订单编号', product_id INT NOT NULL COMMENT '商品ID', user_id INT NOT NULL COMMENT '用户ID', region VARCHAR(32) NOT NULL COMMENT '区域', quantity INT NOT NULL COMMENT '购买数量', amount DECIMAL(10,2) NOT NULL COMMENT '订单金额', status TINYINT NOT NULL COMMENT '订单状态：1-已完成 2-已取消 3-退款中', created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间' ) COMMENT='订单信息表'; INSERT INTO products (product_name, category, price) VALUES ('无线鼠标', '数码配件', 89.00), ('机械键盘', '数码配件', 299.00), ('显示器', '电脑办公', 1099.00), ('工学椅', '办公家具', 799.00); INSERT INTO orders (order_no, product_id, user_id, region, quantity, amount, status, created_at) VALUES ('D20250101001', 1, 101, '华东', 2, 178.00, 1, '2025-01-01 10:00:00'), ('D20250101002', 2, 102, '华东', 1, 299.00, 1, '2025-01-01 11:30:00'), ('D20250102001', 3, 103, '华南', 1, 1099.00, 1, '2025-01-02 09:20:00'), ('D20250102002', 1, 104, '华北', 5, 445.00, 1, '2025-01-02 14:00:00'), ('D20250103001', 4, 105, '华南', 2, 1598.00, 2, '2025-01-03 16:45:00'), ('D20250103002', 2, 106, '华北', 1, 299.00, 3, '2025-01-03 18:10:00');

需要注意的是，注释写得越清楚，大模型生成SQL的准确率越高。实际生产环境往往还需要额外维护一个字段字典或指标字典。

5.2 编写配置模块

文件路径：config.py

import os # 数据库配置 DB_CONFIG = { "host": os.getenv("DB_HOST", "localhost"), "port": int(os.getenv("DB_PORT", 3306)), "user": os.getenv("DB_USER", "root"), "password": os.getenv("DB_PASSWORD", "123456"), "database": os.getenv("DB_NAME", "smart_bi_demo"), "charset": "utf8mb4", } # 大模型配置 LLM_API_KEY = os.getenv("LLM_API_KEY", "your-api-key") LLM_BASE_URL = os.getenv("LLM_BASE_URL", "https://api.example.com/v1") LLM_MODEL = os.getenv("LLM_MODEL", "your-model-name")

这里使用环境变量的方式管理敏感配置，避免把密钥硬编码到代码里。实际项目中建议用配置文件加环境变量覆盖，或者接入配置中心。

5.3 编写数据库执行模块

文件路径：db_executor.py

import pymysql from config import DB_CONFIG def get_connection(): """创建数据库连接""" return pymysql.connect( host=DB_CONFIG["host"], port=DB_CONFIG["port"], user=DB_CONFIG["user"], password=DB_CONFIG["password"], database=DB_CONFIG["database"], charset=DB_CONFIG["charset"], cursorclass=pymysql.cursors.DictCursor ) def get_table_schema(): """获取数据库表结构信息，用于拼接到Prompt中""" conn = get_connection() cursor = conn.cursor() try: # 获取表列表和建表语句 cursor.execute("SHOW TABLE STATUS") tables = cursor.fetchall() schema_parts = [] for table in tables: table_name = table["Name"] table_comment = table.get("Comment", "") cursor.execute(f"SHOW FULL COLUMNS FROM `{table_name}`") columns = cursor.fetchall() col_desc = [] for col in columns: col_desc.append(f"- {col['Field']} ({col['Type']})：{col.get('Comment', '')}") col_str = "\n".join(col_desc) schema_parts.append( f"表名: {table_name}\n表注释: {table_comment}\n字段:\n{col_str}" ) return "\n\n".join(schema_parts) finally: cursor.close() conn.close() def execute_sql(sql): """执行查询SQL，返回结果列表""" conn = get_connection() cursor = conn.cursor() try: cursor.execute(sql) rows = cursor.fetchall() return rows finally: cursor.close() conn.close()

这里有一个安全意识很重要：execute_sql内部只接受从大模型生成后经过校验的SQL，而且连接数据库的账号应该使用只读权限专用账号，并限制可访问的库表，这样即使大模型生成了意外的SQL，也不会对生产数据造成破坏。

5.4 编写大模型调用模块

文件路径：llm_client.py

from openai import OpenAI from config import LLM_API_KEY, LLM_BASE_URL, LLM_MODEL class LLMClient: def __init__(self): self.client = OpenAI(api_key=LLM_API_KEY, base_url=LLM_BASE_URL) self.model = LLM_MODEL def chat(self, messages, temperature=0.1): """调用大模型对话接口""" response = self.client.chat.completions.create( model=self.model, messages=messages, temperature=temperature, ) return response.choices[0].message.content llm_client = LLMClient()

temperature设置为0.1，是为了让大模型的输出更稳定，减少随机性。SQL生成任务对确定性要求很高，不建议使用高温度。

5.5 编写提示词模板

提示词是智能问数项目最核心的“代码”。同一个数据库，不同的提示词写法，生成SQL的准确率差异巨大。

文件路径：prompts.py

SYSTEM_PROMPT = """你是一个精通SQL的数据库助手。请根据用户的问题，结合给定的数据库表结构，生成对应的SQL查询语句。 要求： 1. 只生成SELECT查询语句，禁止生成INSERT、UPDATE、DELETE等操作。 2. 只使用给定表结构中出现的表和字段，禁止编造表和字段。 3. 如果问题含义不明确，尽量根据字段注释推测合理口径。 4. 必须使用当前日期作为参考日期来计算相对时间。 5. 输出JSON格式，包含sql和explanation两个字段。 示例： 用户问题：上个月各区域的订单金额 SQL输出：{"sql": "SELECT region, SUM(amount) AS total_amount FROM orders WHERE created_at >= DATE_FORMAT(CURRENT_DATE - INTERVAL 1 MONTH, '%Y-%m-01') AND created_at < DATE_FORMAT(CURRENT_DATE, '%Y-%m-01') GROUP BY region", "explanation": "按区域汇总上个月的订单金额"} 当前日期：{current_date} 数据库表结构： {schema} """ def build_generate_sql_prompt(question, schema, current_date): """构造生成SQL的Prompt""" messages = [ {"role": "system", "content": SYSTEM_PROMPT.format(current_date=current_date, schema=schema)}, {"role": "user", "content": f"用户问题：{question}\n请直接输出JSON结果。"} ] return messages def build_explain_prompt(question, sql, query_result): """构造结果解释的Prompt""" content = f"""用户的问题是：{question} 生成的SQL是：{sql} 查询结果如下： {query_result} 请用通俗易懂的话回答用户的问题，并对结果做简单解读。注意不要编造结果中不存在的数据。""" messages = [ {"role": "system", "content": "你是一个数据分析助手，请根据查询结果回答用户问题，语言简洁准确。"}, {"role": "user", "content": content} ] return messages

这里有两个关键设计：

第一，强制JSON输出。把SQL和解释封装成结构化JSON，方便后端解析和处理。

第二，给出Few-shot示例。示例的作用不仅是告诉模型“输出格式长什么样”，还暗含了“时间计算风格”。比如上个月的逻辑，在示例中就体现为使用DATE_FORMAT(CURRENT_DATE - INTERVAL 1 MONTH, '%Y-%m-01')这样的表达，模型会模仿这种写法。

5.6 编写主应用

文件路径：app.py

import json import re from datetime import date from flask import Flask, request, jsonify from db_executor import get_table_schema, execute_sql from llm_client import llm_client from prompts import build_generate_sql_prompt, build_explain_prompt app = Flask(__name__) def parse_model_response(content): """解析大模型返回内容，提取JSON中的sql字段""" # 有些模型会在JSON外面包一层```json标记，这里做兼容处理 content = content.strip() json_match = re.search(r"\{.*\}", content, re.DOTALL) if not json_match: raise ValueError("模型返回内容中未找到JSON格式数据") data = json.loads(json_match.group()) return data["sql"] def is_safe_sql(sql): """校验SQL是否安全：只允许单条SELECT语句""" sql_strip = sql.strip().rstrip(";") # 提取SQL主体，判断是否为SELECT开头 # 这里用简单方式：将注释和字符串先去掉判断，避免被注释绕过 without_comment = re.sub(r"/\*.*?\*/", "", sql_strip, flags=re.DOTALL) without_comment = re.sub(r"--.*?$", "", without_comment, flags=re.MULTILINE) first_keyword = without_comment.strip().split()[0].upper() if first_keyword != "SELECT": return False # 禁止分号 if ";" in sql_strip: return False return True @app.route("/api/ask", methods=["POST"]) def ask(): """智能问数核心接口""" data = request.get_json() question = data.get("question", "").strip() if not question: return jsonify({"error": "问题不能为空"}), 400 try: # Step1: 获取数据库Schema schema = get_table_schema() # Step2: 生成SQL messages = build_generate_sql_prompt(question, schema, date.today().isoformat()) model_output = llm_client.chat(messages) sql = parse_model_response(model_output) # Step3: 安全校验 if not is_safe_sql(sql): return jsonify({"error": "系统无法处理该查询，请换个问法"}), 400 # Step4: 执行SQL result_rows = execute_sql(sql) # Step5: 解释结果 explain_messages = build_explain_prompt(question, sql, json.dumps(result_rows, ensure_ascii=False)) explanation = llm_client.chat(explain_messages, temperature=0.3) return jsonify({ "sql": sql, "result": result_rows, "explanation": explanation }) except Exception as e: return jsonify({"error": f"处理失败：{str(e)}"}), 500 @app.route("/api/schema", methods=["GET"]) def schema_api(): """查看当前表结构，便于调试""" try: schema = get_table_schema() return jsonify({"schema": schema}) except Exception as e: return jsonify({"error": str(e)}), 500 if __name__ == "__main__": app.run(host="0.0.0.0", port=8000, debug=True)

parse_model_response用正则提取JSON部分，是为了兼容模型输出中可能混入的多余文本。is_safe_sql做了两层简单校验：一是必须SELECT开头；二是不允许出现分号。

5.7 运行与验证

启动服务：

python app.py

使用curl发起请求：

curl -X POST http://localhost:8000/api/ask \ -H "Content-Type: application/json" \ -d '{"question": "华东区已完成订单的总金额是多少？"}'

预期返回的效果大致如下：

{ "sql": "SELECT SUM(amount) AS total_amount FROM orders WHERE region = '华东' AND status = 1", "result": [ { "total_amount": 477.00 } ], "explanation": "华东区已完成订单的总金额是477元。" }

这里要说明一点：不同大模型生成的SQL风格会有差异，但只要语义正确，结果应该一致。如果模型返回的SQL使用了大写或不同的别名，不影响执行结果。

6. 评测怎么做：智能问数项目最容易被忽视的一环

很多团队智能问数项目“感觉能用”，但一上生产就被业务挑出一堆毛病。核心原因是在上线之前没有建立评测机制。

6.1 为什么必须有评测集

智能问数项目的模型效果不是一个静态结果。今天换了一个模型版本，或者改了一句业务口径的提示词，整体准确率就可能变化。没有评测集，就没办法量化这种变化，每个需求都靠人工一条条验证，既慢又不标准。

更关键的是，提示词的重构、语义层的调整，需要有一个判断“改得更好还是更差”的锚点。评测集就是团队的锚点。

6.2 评测指标的三个层级

智能问数项目的评测可以从三个层级展开：

SQL可执行率最容易提升，通常用一个小规模测试集就能快速发现大模型的致命问题。SQL语义准确率是核心指标，需要人工标注。比如用户问“上个月的销售额”，标准答案是按订单创建时间汇总指定月份的金额，模型生成的SQL如果条件写错一个月，依然可执行，但结果错误，这种情况要人工判断。用户满意度则更偏产品体验层，需要留存用户反馈数据。

6.3 小规模评测脚本示例

下面给一个简单的评测脚本框架，核心思路是：准备一批测试问题，调用大模型生成SQL，先做语法校验，再人工比对结果。

文件路径：evaluate.py

import json import re from datetime import date from db_executor import get_table_schema, execute_sql from llm_client import llm_client from prompts import build_generate_sql_prompt # 测试用例集，期望sql为参考 test_cases = [ { "question": "华东区已完成订单的总金额是多少？", "expect": "SELECT SUM(amount) FROM orders WHERE region='华东' AND status=1" }, { "question": "各个类目的商品数量", "expect": "SELECT category, COUNT(*) FROM products GROUP BY category" }, { "question": "上个月每个区域的订单数", "expect": "SELECT region, COUNT(*) FROM orders WHERE created_at >= 上月第一天 AND created_at < 本月第一天 GROUP BY region" }, ] def extract_sql(content): content = content.strip() json_match = re.search(r"\{.*\}", content, re.DOTALL) if not json_match: return None data = json.loads(json_match.group()) return data.get("sql") def evaluate(): schema = get_table_schema() exec_ok = 0 total = len(test_cases) for case in test_cases: question = case["question"] messages = build_generate_sql_prompt(question, schema, date.today().isoformat()) output = llm_client.chat(messages) sql = extract_sql(output) print(f"问题：{question}") print(f"生成SQL：{sql}") try: result = execute_sql(sql) print(f"查询结果行数：{len(result)}") exec_ok += 1 except Exception as e: print(f"执行失败：{e}") print("-" * 50) print(f"SQL可执行率：{exec_ok}/{total} = {exec_ok / total * 100:.1f}%") if __name__ == "__main__": evaluate()

评测集构建没有捷径，建议从历史取数工单里整理高频问题，每个问题配标准答案SQL。刚开始50条就够用，但要注意覆盖不同问题类型，比如时间条件、分组聚合、多表关联、排序限制等。

7. 常见问题与排查思路

智能问数项目上线过程中，会遇到大量实际问题。下面把高频问题和排查思路整理成表格。

从实际项目经验来看，“字段含义不清”是准确率低下的最大来源。很多企业的数据库字段名是拼音缩写，没有注释，大模型再强也猜不对。这个问题的解法不在模型侧，而在数据治理侧。如果生产环境字段无法立即改善，至少要在语义层维护一份“字段别名映射字典”，也就是把业务叫法和物理字段对应起来，让大模型在生成SQL之前先做一次术语映射。

8. 最佳实践与工程建议

智能问数从Demo到生产环境，需要跨过很多工程门槛。下面给出几个关键建议。

8.1 安全边界是上线底线

智能问数系统的安全校验不能只靠大模型“自觉”。必须做到：

• 数据库连接使用只读账号，权限最小化。
• 在SQL执行层拦截非SELECT语句，防止注入绕过。
• 设置查询超时时间，避免长SQL拖垮数据库。
• 单次查询限制返回行数，例如LIMIT 200。
• 在SQL生成阶段注入数据权限条件，例如“用户只能看自己部门的数据”，不能把权限完全交给大模型判断。

要注意，大模型生成的SQL可能不够规范，可能有注释绕过，所以在安全校验时，最好把SQL解析成AST（抽象语法树）后做结构检查，比单纯字符串匹配可靠得多。Demo代码里的正则校验只是最基础的一层，生产环境建议引入SQL解析库。

8.2 语义层比模型更重要

“智能问数”项目的准确率，很大程度上取决于业务口径在语义层中定义得是否清楚。

什么是一个好的语义层？它应该包含：

• 指标字典：每个指标对应哪个表、哪个字段、用什么聚合方式、有哪些过滤条件。
• 维度字典：常见的维度值，比如“华东区”在数据库里是region='华东'还是region_code='HD'。
• 表关系：哪些表通过哪些键关联，避免大模型在多表JOIN时猜错关联条件。
• 时间口径：自然语言中的“本月”“上季度”统一换算成什么规则。

这个语义层不需要一开始做得很完整，但数据结构上要能持续积累。产品经理要和数据分析师一起，把口径一条条沉淀下来。

8.3 提示词模块化管理

Prompt不要散落在各个代码文件里。建议集中管理，并用版本化方式迭代。例如所有提示词模板统一放在prompts/目录下，修改时保留历史版本，方便对比不同版本对准确率的影响。

另外，Prompt不是一次写好的，要根据评测集的失败案例持续迭代。每一次Prompt调整，都建议跑一遍评测集，用数据说话，而不是“感觉变好了”。

8.4 数据、日志和反馈闭环

生产环境要记录每一次问答的以下信息：

• 用户问题
• 生成的SQL
• 执行结果摘要
• 是否有用户反馈（点赞/点踩/纠错）
• 模型版本和Prompt版本

这些数据是后续评测集扩充和模型优化的原料。智能问数是一个需要持续运营的产品，上线不是终点，而是数据积累的起点。

8.5 冷启动阶段不要做大而全

最稳妥的落地策略是：选择一个业务线、几张核心表、一批高频问题，先跑通再扩大范围。目录上要克制，因为每增加一张表，模型的决策空间就变大，准确率就可能下降。把“少而精”做到稳定，再横向扩展覆盖范围，是智能问数项目管理节奏的关键。

9. 总结与学习路线

本文围绕“AI产品经理如何落地智能问数项目”这一主题，拆解了三个层面：

第一层是需求与场景定义。智能问数不是把大模型接进BI系统那么简单，它要求产品经理明确目标用户、核心场景、准确率门槛和安全边界。

第二层是技术链路与代码实现。通过一个最小可运行的Flask示例，走通了“自然语言 -> 生成SQL -> 安全校验 -> 执行查询 -> 结果解释”的完整链路。代码可以直接下载运行，也可以在这个基础上继续扩展。

第三层是评测与工程化。智能问数项目的难点不在写代码，而在持续提升准确率、建立评测集、维护语义层、保障数据安全。

接下来可以继续学习的方向包括：

• RAG在智能问数中的应用：向Prompt中只注入相关表结构，解决表过多问题。
• 复杂SQL任务：多表JOIN、窗口函数、同比环比计算的提示词设计。
• 语义层的产品化设计：如何把指标口径管理做成一个可持续维护的产品模块。
• 微调路线：当提示词工程和RAG无法满足准确率要求时，如何准备训练数据和评估微调收益。

智能问数是一个典型的“看起来简单、做起来极深”的AI落地场景。它同时考验产品经理对大模型能力的理解、对数据业务场景的嗅觉，以及对工程边界的把控。建议你先从本文的小Demo入手，配好数据库，跑通几个问题，再结合自己公司的真实表结构和业务口径做扩展。只有在真实数据上踩过坑，才能真正理解智能问数项目里那些决定成败的细节。如果这篇文章对你有帮助，可以先收藏备用，动手搭一个最小系统再回来对照排查。