企业官网建设流程全解析

最近很多做产品经理的朋友都在问同一个问题：AI 产品经理的简历越来越难包装了。过去写“负责过某个 App 的改版”“输出过一套推荐策略”，至少还能看出产品基本功；现在面试官一开口就问“你做过 AI 应用吗”“你怎么评估模型效果”“你的项目里数据链路是怎么走的”，如果答不出来，简历上的亮点瞬间就变成了减分项。

这个问题的本质是：AI 产品经理的岗位门槛已经从“懂概念”变成了“能落地”。而作品集又是证明落地能力最直接的方式，可惜大部分人卡在两个地方——一是没有真实业务场景，二是没有工程资源支持。

这篇文章想给一个可复制的解法：用ChatBI（对话式数据分析）作为作品集的项目方向，用Vibe Coding（自然语言编程）快速实现 Demo，然后把整个从需求到验证的过程写进简历。ChatBI 是目前企业数字化里真实存在的高频需求，Vibe Coding 则让非开发背景的产品经理也能独立完成一个可演示、可评测、可讲清楚原理的项目。读完这篇文章，你不仅能跑通一个 ChatBI 原型，还能知道怎么把项目过程变成面试素材。

1. 为什么“ChatBI + Vibe Coding”适合作为作品集项目

1.1 先回答一个更根本的问题：AI 产品经理的作品集应该证明什么

AI 产品经理和传统产品经理最大的区别，不是多会画原型，而是多懂“技术边界”。你需要知道哪些需求是模型能做的、哪些是数据问题、哪些需要规则兜底。作品集如果只展示交互稿，面试官无法判断你的 AI 产品能力；但如果展示的是一个跑通了的 AI 应用，并且你能说清楚模型选型、Prompt 策略、评测指标、安全边界，那就完全不一样了。

所以作品集的定位不应该是“我做了一个界面”，而应该是“我独立完成了一个 AI 产品的端到端设计”。

1.2 为什么 ChatBI 是 AI 产品经理练手的好方向

ChatBI 可以拆成两个词：Chat（对话）和 BI（商业智能）。它解决的核心问题是：让业务人员用自然语言提问，系统自动查询数据并返回图表或结论。

这个方向适合作品集有以下三个原因：

• 需求真实。几乎所有企业都在做数据看板，但 SQL 门槛把大量业务人员挡在门外。ChatBI 是一个业务价值容易被理解、面试官不需要额外科普的场景。
• 链路完整。一个 ChatBI 项目能覆盖意图理解、NL2SQL、数据权限、结果可视化、效果评测等多个环节。这些环节恰好对应 AI 产品经理的核心能力项。
• 技术可控。构建一个最小可用的 ChatBI 不需要训练模型，也不需要高成本算力。用市面上成熟的大模型 API 加上一套 Prompt 策略，就能实现 80% 的效果。

1.3 Vibe Coding 给产品经理补上了“实现能力”

Vibe Coding 这个概念翻译过来是“基于氛围编程”，比“自然语言编程”更形象。它指的不是用自然语言写注释，而是直接用自然语言向 AI 描述需求，由 AI 生成代码，再通过对话不断修改。以前产品经理要出一个 Demo，得等开发排期；现在借助 Vibe Coding 的做法，一个人也能把前后端、数据库、接口串起来。

这里要强调一个判断：Vibe Coding 不等于不用懂技术，而是把技术门槛从“会写代码”降低到“能描述清楚逻辑、能看懂代码、能定位问题”。对 AI 产品经理来说，这种能力恰好与工作方式同构——你本来就需要把需求描述清楚，现在只是把描述对象从开发换成了 AI。

把 ChatBI 和 Vibe Coding 放在一起，就构成了一个完整的个人项目闭环：你发现了真实需求，设计了 MVP 边界，用 AI 工具实现了产品，又用评测数据验证了效果。这套东西写进简历，说服力远大于“熟悉 AI 产品设计流程”这种描述。

2. 先搞清楚两个概念

2.1 ChatBI 到底是什么

ChatBI 本质上是“数据对话机器人”。常见形态是一个对话框，用户输入“上个月的华东区销售额是多少”，系统返回一个数字、一张趋势图，或者一句自然语言结论。

从技术架构看，ChatBI 通常包含五个环节：

1. 用户输入问题。
2. 系统理解意图，识别用户想查哪个指标、哪个维度、哪个时间范围。
3. 将自然语言转换为 SQL 查询语句，这一步就是 NL2SQL。
4. 在数据库上执行 SQL，并校验权限和结果。
5. 将查询结果以图表、文本表格等形式返回给用户。

传统 BI 的做法是：业务人员提需求，数据工程师写 SQL，再把结果固化成报表。ChatBI 的改变在于，把“写 SQL”这一步用自然语言代替，让数据查询从“提需求等待排期”变成“直接对话”。

2.2 Vibe Coding 翻译成产品语言

Vibe Coding 最早是 Andrej Karpathy 在一次演讲中提出的概念，指在 AI 辅助下，开发者用自然语言描述意图，AI 负责生成代码，人类负责把控方向。它的核心不是“不写代码”，而是“用对话驱动代码生成”。

从产品经理视角看，Vibe Coding 像是一种“高级外包管理”：

• 传统开发：你写需求文档，开发理解后写代码，周期按周计。
• Vibe Coding：你向 AI 描述需求，AI 直接生成代码，周期按分钟计。

它的局限也很明显：越复杂、越涉及多系统交互的功能，AI 生成的代码越容易失控。所以 Vibe Coding 更适合 Demo、原型、内部工具，而不是直接写生产级核心系统。

2.3 为什么两个词放在一起有意义

单独看，ChatBI 是一个 AI 应用方向，Vibe Coding 是一个开发方式。但组合起来，它们正好对应 AI 产品经理能力的两个维度：应用设计能力和快速实现能力。你有场景、有设计、有实现，还能自己验证，这就是一个完整的 AI 产品实践。

3. 作品集项目的选题与边界设计

3.1 不要一开始就追求大而全

新手做 ChatBI 最容易犯的错，是想做一个“万能问答机器人”。结果问什么都要动态生成复杂 SQL，最终准确率很低，Demo 演示时翻车。

更稳妥的做法是：选择一个窄业务场景，做深做透。比如“销售数据的自然语言查询”，只针对一张订单表加两张维度表。这样做的原因是，ChatBI 的效果高度依赖表结构清晰度和问题范围。范围越窄，Schema 越简单，模型生成 SQL 的准确率越高，你也能把精力花在评测和迭代上。

3.2 一个推荐选题：销售数据问答 Bot

我们以“销售数据问答”为例，设计一个 MVP 项目。

业务背景：某公司销售团队想直接问“最近一个季度各区域销售额”，但不会写 SQL，只能等数据分析师出报告。

MVP 范围：

• 数据范围：订单明细表、区域表、产品表。
• 功能范围：支持按时间、区域、产品、销售额、订单量进行查询和对比。
• 输出形式：自然语言结论 + 柱状图或趋势图。
• 明确不做：不做跨多表复杂关联的探索性分析，不做数据写入操作，不做高精度预测。

这样设计的好处是，你可以在两天内完成 Demo，并且能讲清楚“每个功能边界为什么这样定”。

3.3 定义 MVP 的用户故事

写几个典型用户故事，既能指导开发，也能放进简历。

• 作为销售总监，我想知道“上个月华东区销售额”，以便快速汇报。
• 作为区域经理，我想知道“近六个月各区域订单量趋势”，以便做业务复盘。
• 作为产品运营，我想知道“哪个品类销售额增长最快”，以便调整策略。

这些用户故事可以直接转化为评测集中的测试问题，一一对应验证效果。

4. ChatBI 的核心链路拆解

本节用“销售数据问答”场景，把 ChatBI 的核心链路一步步拆开。理解这个链路，无论你后续用什么模型、什么框架，都能保持清晰的产品判断。

4.1 链路全貌

ChatBI 的完整请求链路由六个环节组成：

1. 用户提问。
2. 意图预处理：判断问题是否在支持范围内，必要时改写为更清晰的查询表达。
3. NL2SQL：结合表结构信息和规则约束，将自然语言转换为 SQL。
4. 安全校验：检查 SQL 是否违规、是否越权。
5. 查询执行：连接数据库执行 SQL，获取结构化结果。
6. 结果呈现：把结果转化为自然语言摘要和可视化图表。

这个链路中，产品经理最需要关注的是第 3 步和第 4 步。第 3 步决定“答得对不对”，第 4 步决定“数据安不安全”。

4.2 表结构设计

ChatBI 的效果发挥高度依赖表结构是否清晰。下面是一个适合入门项目的星型模型示例，一共有三张表。

-- 维度表：区域表 CREATE TABLE dim_region ( region_id VARCHAR(32) PRIMARY KEY, region_name VARCHAR(128) NOT NULL, -- 华东、华北、华南等 manager VARCHAR(64) ); -- 维度表：产品表 CREATE TABLE dim_product ( product_id VARCHAR(32) PRIMARY KEY, product_name VARCHAR(128) NOT NULL, category VARCHAR(64) -- 品类，如数码、家居、服饰 ); -- 事实表：订单明细表 CREATE TABLE fact_order ( order_id VARCHAR(64) PRIMARY KEY, order_date DATE NOT NULL, region_id VARCHAR(32) NOT NULL, product_id VARCHAR(32) NOT NULL, sales_amount DECIMAL(12,2) NOT NULL, order_count INT NOT NULL );

这里要解释几个设计意图：

• 用星型模型而不是一张大宽表，是为了让字段含义更清晰，模型生成 SQL 时不容易混淆概念。
• 时间字段统一使用DATE类型，查询“近六个月”这类窗口计算时更可靠。
• 金额指标和数量指标分开定义，避免模型把“销售额”和“订单量”混为一谈。

4.3 NL2SQL 的两种实现思路

NL2SQL 是这个项目最核心的模块，有两种实现思路。

第一种是“直接让大模型写 SQL”。优点是接入成本低，缺点是模型可能生成语法正确但业务语义错误的 SQL，例如把sales_amount当成order_count来求和。

第二种是“模板 + 规则 + 模型修正”。先在 Prompt 中描述表结构和业务规则，模型生成 SQL 后，再通过规则检查兜底。对 MVP 项目来说，第二种方式是更优的工程选择。

下面是一个可直接复用的 NL2SQL Prompt 模板示例。

你是一名数据分析师。请根据用户问题，结合给定的数据库表结构生成 SQL。 表结构： 1. dim_region：区域维度表 字段：region_id(区域ID), region_name(区域名称), manager(负责人) 2. dim_product：产品维度表 字段：product_id(产品ID), product_name(产品名称), category(品类) 3. fact_order：订单事实表 字段：order_id(订单ID), order_date(下单日期), region_id(区域ID), product_id(产品ID), sales_amount(销售额), order_count(订单量) 业务规则： 1. 销售额字段为 sales_amount，订单量字段为 order_count，两者不能互相替代。 2. 查询结果默认按时间倒序排序。 3. 如果用户问"最近N个月"，请将 order_date 与当前日期比较，按月维度聚合。 4. 只能生成 SELECT 查询语句，禁止生成 INSERT、UPDATE、DELETE、DROP 等操作。 5. 如果用户问题涉及具体区域或品类，请通过 JOIN 关联维度表得到名称。 用户问题：{user_question} 请只输出 SQL，不要附加解释。

这份模板的价值在于“把业务规则显性化”。实际项目中你会发现，模型出错的场景往往不是 SQL 语法，而是业务口径。Prompt 里写得越清楚，效果越好。

4.4 权限与安全边界

ChatBI 涉及数据库查询，属于敏感场景。MVP 也必须有安全设计，这是面试时重要的加分点。建议从三个层面控制：

• 账号权限：使用只读数据库账号，禁止业务账号连接生产库。
• 行级权限：查询结果按当前用户所属区域过滤，例如华东用户只能查华东数据。
• 输入校验：对模型生成的 SQL 做黑名单校验，拦截包含DELETE、DROP、ALTER等危险关键字或注释的语句。

下面是一个 SQL 安全校验函数的极简示例。

import re def validate_sql(sql: str) -> bool: """校验 SQL 是否只包含安全的查询语句。""" if not sql.strip().lower().startswith("select"): return False dangerous_patterns = [r"\bdelete\b", r"\bdrop\b", r"\balter\b", r"\binsert\b", r"\bupdate\b", r"--", r"/\*"] for pattern in dangerous_patterns: if re.search(pattern, sql, re.IGNORECASE): return False return True

这里真正容易踩坑的地方是：模型可能生成带注释的 SELECT 语句，注释里藏有其他语句。所以安全校验不仅要看开头是不是SELECT，还要把危险关键字逐个过滤。涉及生产环境的变更操作，必须遵循最小权限和变更审批流程，这部分内容也需要在项目中明确体现。

5. 用 Vibe Coding 快速搭建 Demo

5.1 环境准备与前置条件

为了避免版本兼容问题，这里先说明通用环境，不做死版本绑定。实操时以你本机实际环境为准。

建议环境：

• 操作系统：Windows 10/11 或 macOS 均可。
• Python：3.10 以上。
• 数据库：SQLite 或本机 MySQL。
• 大模型接入：任意支持 Chat Completions 接口的模型服务，通过 API Key 调用。
• 开发工具：VS Code 或 Cursor 均可，建议使用支持 AI 对话插件的 IDE。

如果你完全没接触过 Vibe Coding，建议先用一个最小任务试水：让 AI 帮你生成“一个网页，包含输入框、按钮和结果展示区域”。跑通这个流程后再开始完整项目。

5.2 用对话迭代的方式描述需求

Vibe Coding 能不能成功，很大程度取决于你怎么描述需求。这里给出一个可复用的对话框架：

1. 先描述最终目标，不要写技术实现细节。
2. 再描述页面组成，指明每个区域的用途。
3. 逐步补充交互逻辑，例如“用户输入问题后，显示加载状态，接口返回后渲染结果”。
4. 出现报错时，把完整报错信息复制进对话框，要求 AI 解释原因并修复。

下面是一次真实的 Vibe Coding 对话示例。

请用 Python 写一个简单的 ChatBI 演示页面，使用 Streamlit 实现。 页面要求： 1. 顶部是标题“销售数据问答 Demo”。 2. 中间是一个文本输入框，用户输入自然语言问题。 3. 下方有一个“查询”按钮。 4. 点击按钮后，调用后端接口，输入是 question，输出是 answer 和 chart_data。 5. 页面底部展示返回的自然语言结论和柱状图。 6. 如果接口报错，页面显示错误信息，不崩溃。

这种描述方式的好处是：每一个需求都是可验收的。AI 生成的代码如果不符合要求，你可以继续追加一轮对话：“先不要显示全部数据，只显示前 10 条。”

5.3 后端服务的极简实现

后端服务可以包含两个接口：一个用于 NL2SQL 查询，一个用于返回评测结果。下面给出一个极简但完整的后端示例，文件路径统一标注在代码块中。

# 文件路径：app.py from flask import Flask, request, jsonify import sqlite3 import sqlparse import openai app = Flask(__name__) # 假设你已经配置了模型 API Key client = openai.OpenAI(api_key="your-api-key", base_url="your-base-url") TABLE_SCHEMA_PROMPT = """ 你是数据分析师，根据表结构生成 SQL。 表结构： 1. dim_region：region_id, region_name, manager 2. dim_product：product_id, product_name, category 3. fact_order：order_id, order_date, region_id, product_id, sales_amount, order_count 只输出 SQL，不输出解释。 """ def generate_sql(question: str) -> str: response = client.chat.completions.create( model="your-model-name", messages=[ {"role": "system", "content": TABLE_SCHEMA_PROMPT}, {"role": "user", "content": question} ], temperature=0 ) return response.choices[0].message.content.strip() def execute_query(sql: str): conn = sqlite3.connect("sales.db") cursor = conn.execute(sql) columns = [desc[0] for desc in cursor.description] rows = cursor.fetchall() conn.close() return columns, rows @app.route("/chatbi/query", methods=["POST"]) def query(): data = request.get_json() question = data.get("question", "").strip() if not question: return jsonify({"error": "问题不能为空"}), 400 try: sql = generate_sql(question) if not sql.lower().startswith("select"): return jsonify({"error": "生成语句不是查询语句"}), 400 columns, rows = execute_query(sql) return jsonify({"sql": sql, "columns": columns, "rows": rows}) except Exception as e: return jsonify({"error": str(e)}), 500 if __name__ == "__main__": app.run(port=5001, debug=True)

运行方式：

pip install flask openai sqlite3 sqlparse python app.py

然后打开浏览器访问 http://localhost:5001，用 POST 请求测试接口。

curl -X POST http://localhost:5001/chatbi/query \ -H "Content-Type: application/json" \ -d '{"question": "上个月华东区销售额是多少"}'

如果接口正常，你会收到包含 SQL 和查询结果的 JSON。这里要提醒一点：示例中的 API Key 和模型名称需要替换为你实际使用的配置，同时不要泄露到代码仓库。

5.4 前端交互与效果展示

Vibe Coding 场景下，推荐先用 Streamlit 快速搭页面，原因是代码量少、交互组件齐全、不需要单独写前端工程。

# 文件路径：chatbi_ui.py import streamlit as st import requests st.set_page_config(page_title="销售数据问答 Demo", layout="wide") st.title("销售数据问答 Demo") question = st.text_input("请输入你的数据问题，例如：上个月华东区销售额是多少") if st.button("查询"): if not question.strip(): st.warning("请先输入问题") else: with st.spinner("正在查询数据..."): response = requests.post( "http://localhost:5001/chatbi/query", json={"question": question} ) if response.status_code == 200: result = response.json() st.write("生成的 SQL：", result.get("sql")) st.dataframe(result.get("rows")) else: st.error(response.json().get("error", "查询失败"))

这里展示的是最简逻辑，你可以继续用对话让 AI 增加图表。只需追加一句“请把 rows 转换成 pandas DataFrame，并用 st.bar_chart 绘制柱状图”即可。

5.5 把 Vibe Coding 的工程记录变成素材

很多产品经理忽略了一点：Vibe Coding 的过程本身就是作品集素材。建议在项目文件夹里维护一个vibe-coding-guidance.md文件，记录每次向 AI 提出什么需求、AI 生成了什么代码、你做了哪些修正。面试时你可以说：“我用自然语言生成了一段 Demo 代码，通过三轮对话确认了字段口径和页面交互，并自己定位修复了接口报错。” 这句话的含金量，远高于“我熟悉 Python”。

6. 项目验证：从“能回答”到“答得对”

6.1 建立评测集

ChatBI 项目没有评测，等于没有验收标准。建立评测集是 AI 产品经理的基本功。评测集需要覆盖三类问题：

• 正常问题：反映典型用户意图，至少 20 条。
• 边界问题：问法模糊、口径不清、超出范围的问题。
• 安全测试：包含危险指令、越权提问、隐私相关的问题。

下面是一个评测集的 JSON 示例。

[ { "question": "上个月华东区的销售额是多少", "expected_sql_keywords": ["fact_order", "dim_region", "SUM(sales_amount)"], "expected_region": "华东", "expected_time_range": "近一个月", "type": "normal" }, { "question": "删除所有订单数据", "expected_result": "reject", "type": "security" }, { "question": "谁是最好的销售员", "expected_result": "out_of_scope", "type": "boundary" } ]

有了评测集，你可以批量跑测试，统计准确率，并通过观察错误 Case 归纳 Prompt 需要修改的地方。

6.2 评测指标

对于 ChatBI 类产品，推荐从四个维度评估：

6.3 边界用例怎么处理

边界问题是最能体现产品判断力的环节。例如当用户问“谁是最好的销售员”，系统没有相关维度字段，你至少有两种产品决策：

• 直接拒绝：回复“暂不支持人员维度的分析”。
• 改写出近似指标：把“最好的销售员”改写为“销售额最高的产品”，需要明确的业务规则。

你在简历里写清楚这类决策，面试官会认为你能在模糊需求中界定产品边界，而不是只会调接口。

7. 如何把项目写进 AI 产品经理简历

7.1 用 STAR 结构写项目

STAR 是 Situation、Task、Action、Result 的缩写。AI 项目简历最容易犯的错是只写 Action，不写 Result。下面是推荐的 Markdown 结构，可直接复制到简历中。

## 项目经历：销售数据问答 ChatBI Demo - **项目背景**：某销售团队的数据查询依赖数据分析师手工出 SQL，业务人员无法自助分析，平均查询等待时间超过 1 天。 - **项目目标**：构建一个对话式数据查询工具，让业务人员通过自然语言获取销售数据，目标是将高频查询的平均获取时间缩短到 5 分钟内。 - **核心动作**： 1. 独立完成产品方案设计，定义 MVP 范围和数据口径； 2. 使用 Vibe Coding 方式快速实现 NL2SQL 链路，通过 Prompt 调优将 SQL 生成准确率从 60% 提升到 85%； 3. 设计数据库只读账号和 SQL 黑名单校验，确保项目不碰数据写入操作； 4. 建立 30 条评测集，明确评估指标与边界处理规则。 - **项目结果**：Demo 上线后覆盖销售高频问题 Top 10，端到端查询成功率 90%，平均耗时 3 秒。

这组描述中，每一个数据都来自你自己的评测结果，不涉及无来源的编造。如果你还没有跑出准确率数字，先不要写，跑完再补。

7.2 面试时一定会被追问的问题

下面几个问题几乎必问，建议提前准备。

1. 你的 NL2SQL 准确率是怎么保证的？回答思路：主要靠限定业务范围、清晰表结构和 Prompt 业务规则。再加评测集持续验证，不追求万能问答。

2. 如果 SQL 生成错但用户没发现，怎么办？回答思路：一是展示 SQL 给用户可确认，二是在界面上加“数据更新时间与口径说明”，三是对高风险问题做二次确认。

3. 数据权限怎么控制？回答思路：使用只读账号，按用户归属组织设置行级权限，所有生成语句经过安全过滤。涉及敏感数据严格遵循最小权限原则。

4. Vibe Coding 这种方式适合生产项目吗？回答思路：适合原型和内部工具，生产级系统仍需完整测试、代码评审和运维控制。作品集项目正好体现了这种边界判断。

7.3 不要写什么

不要在简历里写“基于大数据技术栈构建 ChatBI 平台”“支撑亿级数据实时查询”。没有真实项目依据的数字和规模，在面试追问下会快速崩盘。宁可写“Demo 覆盖 Top10 问题”，也不要写模糊的大词。

8. 常见问题与排查思路

8.1 常见问题表格

8.2 排查路径

如果项目跑不通，先按下面顺序排查：

1. 看后端接口是否启动成功，访问http://localhost:5001是否能返回内容。
2. 看浏览器开发者工具中 Network 面板的请求状态码。
3. 看模型 API 返回内容是否包含非 SQL 文本，例如 Markdown 代码块。
4. 看数据库查询语句是否执行成功，是否报“no such column”。

从经验看，80% 的问题出在 API Key 未配置和数据库表名不一致这两个点上。

8.3 建议的避坑清单

• 不要直接用生产数据库练手，用 SQLite 或本地数据库。
• 不要在仓库里暴露模型 API Key，用环境变量管理。
• 不要让模型生成 INSERT、UPDATE、DELETE 等写操作语句。
• 不要把“演示跑通了”等同于“效果可靠”，必须用评测集验收。
• 不要编造评测数据，项目写进简历的所有指标都要能追溯。

9. 值得继续做的三个方向

这个 ChatBI 项目做到这里，已经能支撑一份作品集。如果你还想继续深入，有三个方向值得投入。

第一是引入反馈闭环。在页面增加“回答是否有帮助”的点赞和点踩按钮，把坏 Case 沉淀成评测集，形成持续优化循环。这个设计直接对应大厂 AI 产品岗常考的“模型效果迭代机制”。

第二是增加多轮对话。考虑“上个月华东区销售额是多少”之后追问“那华北呢”这类指代消解场景。多轮对话是 ChatBI 从 Demo 走向产品的重要门槛。

第三是强化权限模型。实现用户登录，按组织架构控制行级数据权限。这会让项目的安全设计更有说服力，也贴近企业采购场景的真实要求。

一个能放进简历的 ChatBI 作品集，本质上不是“我会调用模型 API”，而是“我完整走完了一个 AI 产品从需求到验证的路径，并且知道每个环节的坑和取舍”。Vibe Coding 提供了快速实现的手段，ChatBI 提供了真实可讲的应用场景，剩下的就是动手跑通一遍，然后把过程整理成面试时讲得清楚的故事。建议先按文章顺序把第 5 节的 Demo 跑通，再回来完善评测和简历描述——只要开始动手，这个作品集就不远了。