企业官网建设流程全解析

做 AI 产品经理的朋友，最尴尬的场景是什么？面试聊产品方法论讲得头头是道，一说项目实践就只剩原型图和 PRD 截图。简历里堆了一排“负责设计 XX 功能”“推动 XX 上线”，面试官追问一句“这个功能怎么验证的”“数据链路怎么跑的”，马上冷场。

问题不在你能力不行，而是作品集里缺一个“能跑、能演示、能讲清楚业务价值”的项目。

这一篇不跟你聊虚的。我们直接围绕 AI 产品经理作品集这个主题，给出一条可执行的实操路径：用 Vibe Coding 的方式，快速搭建一个 ChatBI（聊天式商业智能）演示系统，做自然语言问数，跑通数据查询链路，再把整个项目整理成能写进简历的素材。

先说门槛：不用你手写全套后端，也不需要本地 GPU。ChatBI 这类 AI 应用，核心是用大模型 API 把用户问题转成 SQL，然后查询数据库返回结果。你负责的是需求拆解、提示词设计、链路串联和效果验收，这正是 AI 产品经理在真实项目里最常见的工作方式。

1. ChatBI 作品集核心能力速览

先给一张速览表，方便你判断这类项目值不值得投入时间。

这个配置说明一件事：ChatBI 是最适合 AI 产品经理做作品集的方向之一，因为它技术浓度适中，业务价值直观，面试官一听就明白，不会像图像生成那样变成“堆显卡跑模型”的纯技术展示。

2. 适用场景与使用边界

Vibe Coding 加 ChatBI 的组合，适合三类人。

第一类是正在找 AI 产品经理岗位的候选人。作品集里的项目不需要做成生产级系统，但要能证明你理解 LLM 应用的完整链路：用户问题进来，系统怎么理解意图，怎么调用模型，怎么生成 SQL，怎么校验结果，结果不对怎么办。这一条链路跑通了，比十张功能流程图都管用。

第二类是在企业内部推动 AI 问数落地的产品经理。业务方经常问“我们的销售数据怎么查”“本月各区域完成率是多少”，过去靠人工取数，现在想用对话式交互降低门槛。你做一个 ChatBI Demo，不用等开发资源，先验证查询效果和口径问题，再决定要不要推进到生产系统。

第三类是想从传统功能产品经理转型 AI 方向的从业者。Vibe Coding 让你不用从零学编程也能做原型，ChatBI 又让你能把“大模型能力”和“业务数据”结合起来，而不是只做套壳机器人。

使用边界也需要说清楚。

ChatBI Demo 不等于企业级 ChatBI。真实的落地系统会涉及数据权限、SQL 安全、查询超时、指标口径管理、模型评测、审计日志，这些是团队工程需要解决的问题。单个演示项目只需要让你理解核心链路，不能拿去冒充生产方案。

数据合规是最重要的一条边界。演示数据一定要脱敏，不要用真实客户数据、员工个人信息、内部经营数据上传到第三方 API。如果公司数据有保密要求，建议自己造一张模拟销售表，效果完全够用。

3. Vibe Coding 与 ChatBI 本地部署环境准备

这类项目不挑机器，但环境要干净，避免后面启动时反复踩依赖冲突。下面的检查清单按常见实践给出，具体版本可以根据你本机情况调整。

3.1 基础运行环境

• 操作系统：Windows / macOS / Linux 都可以，主要用命令行操作。
• Python 版本：建议 3.10 或 3.11，避免个别库版本不支持。
• 网络环境：需要能访问你选择的大模型 API 服务，这个按你实际使用的服务商开通。
• 包管理器：建议用 venv 或 conda 建独立虚拟环境，不要直接装在全局环境里。
• 代码编辑器：VS Code、Cursor 这类支持 AI 编程插件的编辑器都行，后面 Vibe Coding 部分会用到。

3.2 依赖包清单

# 创建虚拟环境 python -m venv chatbi_env # Windows 激活 chatbi_env\Scripts\activate # macOS / Linux 激活 source chatbi_env/bin/activate # 安装核心依赖 pip install streamlit pandas sqlite3-utils openai python-dotenv

这里的依赖是通用模板。如果你用其他大模型 SDK，就替换openai；如果你用 DuckDB，就把sqlite3-utils换成duckdb。关键是思路，不是固定版本。

3.3 准备一张业务数据表

ChatBI 项目不能没有数据。不建议用真实的业务数据，自己造一张销售订单表就行，字段控制在 6 到 8 个，覆盖维度、指标、时间、地域，方便设计不同查询问题。

示例表结构：

CREATE TABLE sales_orders ( order_id INTEGER PRIMARY KEY, order_date DATE, region TEXT, sales_person TEXT, category TEXT, amount REAL, quantity INTEGER );

这类数据表结构的好处是支持常见问题类型：

• 聚合查询：总营收、总订单量。
• 时间筛选：某月某季度销售额。
• 地域维度：某区域订单量。
• 人员维度：销售排名。
• 产品类目：不同品类占比。

准备好表结构和几行模拟数据后，把这个 SQL 文件放在项目目录里，后面提示词设计会用到。

3.4 确定技术链路

ChatBI 的核心链路可以拆成四步：

1. 用户输入自然语言问题。
2. 系统把问题、表结构描述、业务口径说明一起发给大模型。
3. 大模型返回 SQL 查询语句。
4. 系统执行 SQL，返回结果并格式化为回答。

这四步里，AI 产品经理的重点在第 2 步和第 4 步：表结构描述怎么写，模型才不容易生成错 SQL；结果怎么校验，才能发现模型“答非所问”。

4. Vibe Coding 实操：从需求描述到可运行 Demo

Vibe Coding 这个概念，简单说就是“用自然语言驱动 AI 写代码”，你负责描述需求和验收标准，AI 负责生成代码。它不是不写代码，而是把代码工作从“手写每一行”变成“说清楚要什么、检查生成结果、迭代指令”。

AI 产品经理用 Vibe Coding 做作品集，重点不是写一个多复杂的系统，而是把项目拆解成 AI 能理解的步骤。

4.1 第一轮指令：先搭骨架

打开 AI 编程工具，给一段需求描述，先用最粗的粒度把项目结构搭出来。

我需要做一个 ChatBI 演示项目，满足以下要求： 1. 使用 Python 和 SQLite。 2. 数据表 sales_orders 包含 order_id、order_date、region、 sales_person、category、amount、quantity 字段。 3. 使用大模型 API 做自然语言转 SQL，执行查询后返回结果。 4. 使用 Streamlit 做聊天界面，用户输入问题，页面显示回答。 5. 项目结构要清晰，先输出文件目录结构和依赖清单。 请先不要写全部业务逻辑，先搭一个最小可运行的项目骨架。

这里的关键是“先搭骨架”这四个字。AI 编程工具很容易一次生成几百行代码，其中很多是你不需要的。拆成小步推进，更容易掌控结果。

4.2 第二轮指令：补上核心查询链路

骨架确认后，让 AI 实现自然语言转 SQL 的模块。你需要把表结构信息放进提示词，这一步是 AI 产品经理最需要花心思的地方。

现在实现自然语言转 SQL 模块： - 读取项目中的数据库表结构。 - 调用大模型 API，把用户问题转换为 SQL。 - 为了让模型理解字段含义，请在提示词里加入字段注释。 - 生成 SQL 后先在本地检查关键字是否合法，再执行查询。 - 如果 SQL 执行失败，把错误信息返回给用户，不展示原始堆栈。

这一段指令覆盖了一个容易被忽略的问题：字段口径。sales_person是销售员姓名还是 ID？amount是订单金额还是毛利？AI 产品经理需要在提示词里写清楚，否则模型可能生成错误 SQL。

4.3 第三轮指令：加界面

最后让 AI 补一个 Streamlit 聊天界面，要求是“低代码、能演示、能录屏”。

给 ChatBI 项目加一个 Streamlit 页面： 1. 页面标题为“ChatBI 问数助手”。 2. 左侧显示历史提问记录。 3. 右侧是聊天区域，用户输入问题后调用查询模块。 4. 回答区域展示三部分：用户的问题、模型生成的 SQL、查询结果表格。 5. 不要做复杂的样式，保持清爽简洁。

展示 SQL 这一步很关键。面试演示时，面试官能看到“大模型生成的 SQL 长什么样”，比只看一句回答数据更有说服力。

5. ChatBI 提示词设计与接口调用示例

Vibe Coding 能帮你把代码骨架搭起来，但 ChatBI 的效果上限，取决于提示词设计和接口调用方式。这一部分直接决定模型生成的 SQL 准不准。

5.1 提示词模板

一个基础的自然语言转 SQL 提示词模板，至少包含四部分：角色定义、表结构、业务口径、输出要求。

SYSTEM_PROMPT = """ 你是一个数据分析助手，负责把用户问题转换为 SQL 查询。 数据库表结构： {schema} 字段口径说明： - amount 表示订单金额，单位是元。 - quantity 表示订单商品数量。 - order_date 是订单日期，格式为 YYYY-MM-DD。 - region 是销售区域，取值为华东、华南、华北、西南等。 要求： 1. 只返回可执行的 SQL 语句，不要包含解释文字。 2. 不可以使用表结构中不存在的字段。 3. 如果用户问题不明确，先给出一个合理假设，再写出 SQL。 4. 当需要时间维度时，默认按自然年统计，除非用户明确说明。 """

这个模板的亮点在第三点：“如果用户问题不明确，先给出合理假设，再写出 SQL。”实际使用中，大部分查询错误不是模型不会写 SQL，而是业务口径没有对齐。

5.2 接口调用示例

下面给一个简化示例，说明前端问题怎么传给模型，又把结果怎么接回来。这里的地址和模型名需要替换成你实际使用的 API 配置。

import requests API_URL = "https://api.example.com/v1/chat/completions" API_KEY = "your_api_key_here" MODEL_NAME = "your_model_name" def chat_to_sql(user_query: str, schema_text: str) -> str: messages = [ {"role": "system", "content": SYSTEM_PROMPT.format(schema=schema_text)}, {"role": "user", "content": user_query} ] resp = requests.post( API_URL, headers={"Authorization": f"Bearer {API_KEY}"}, json={ "model": MODEL_NAME, "messages": messages, "temperature": 0 }, timeout=60 ) if resp.status_code != 200: raise RuntimeError(f"API 请求失败: {resp.status_code}") data = resp.json() return data["choices"][0]["message"]["content"]

注意temperature: 0，这是自然语言转 SQL 场景里的一个基本原则：宁可让模型选择保守输出，也不要让它自由发挥。SQL 生成不是创意写作，随机性越少越好。

5.3 执行查询并返回结果

拿到模型返回的 SQL 后，在本地数据库执行，需要注意打开方式。演示项目可以用只读模式打开数据库，降低误操作风险。

import sqlite3 import pandas as pd DB_PATH = "demo.db" def run_sql(sql_text: str): # 以只读模式连接，避免生成错误 SQL 后误改数据 conn = sqlite3.connect(f"file:{DB_PATH}?mode=ro", uri=True) try: df = pd.read_sql_query(sql_text, conn) return df except Exception as e: return {"error": str(e)} finally: conn.close()

这里有一个 AI 产品经理容易忽略的点：模型生成的 SQL 如果被执行，可能导致数据被修改。本地 Demo 里用只读模式，是安全习惯。

5.4 结果格式回传

查询结果可能是表格，也可能是聚合数字。回传到前端时，建议统一转成 Markdown 表格或 DataFrame，让用户在页面上直接看到结构化的结果。

def format_answer(df): if df is None or df.empty: return "没有查询到数据，请调整问题后重试。" return df.to_markdown(index=False)

这一层逻辑虽然简单，但它展示了产品经理思维方式：模型输出只是中间结果，用户看到的是最终格式化后的回答。

6. ChatBI 功能测试与效果验证

Demo 跑起来只是第一步，作品集真正值钱的地方在于验证过程。ChatBI 的验证不是“跑通就行”，而是设计一套测试问题集，持续迭代提示词，让准确率可衡量。

6.1 测试用例设计

建议按问题类型设计测试用例，每类覆盖 2 到 3 个问题。

记录每个问题的执行结果，分成三类：正确、错误、需要修正。如果某个问题连续两次生成错误 SQL，把错误 SQL 加进提示词里的“反例区”，告诉模型不要这样写。

6.2 完整测试流程

启动项目后，按下面顺序验证。

# 启动 Streamlit 页面 streamlit run app.py

打开浏览器访问默认地址，一般会在终端显示http://127.0.0.1:8501。页面打开后，逐条输入上表的问题，观察三部分内容：SQL 是否合法、SQL 是否查到了预期数据、结果是否与预期一致。

出现错误时不要急着改代码，先查日志。Streamlit 页面下方会显示 Python 执行输出，API 请求的错误信息也会在这里列出来。把错误信息复制出来，连同问题描述一起发给 AI 编程工具，让它修正提示词或处理逻辑。

6.3 批量评测建议

如果你想在作品集里展示“系统化评测”能力，可以把测试问题做成一个 JSON 文件，循环调用查询模块，自动记录结果。

{ "test_cases": [ { "id": 1, "question": "2024 年总营收是多少", "expected_result": "总营收聚合值" }, { "id": 2, "question": "各区域销售额对比", "expected_result": "按区域分组的聚合表" } ] }

用类似的脚本批量跑一遍，把每个问题的 SQL 和结果存下来。这个“测试文件”本身就是很好的作品集附件，说明你有通过用例驱动提示词迭代的意识。

7. 把 ChatBI 项目写进简历

项目跑通了，下一步就是写进简历。AI 产品经理的作品集项目，简历描述和普通开发项目不一样，要突出“你为什么做”“你怎么验证”“结果如何被衡量”。

7.1 项目描述示例

下面是一段可以参考的简历措辞，实际使用时把指标替换成你真实的数据。

ChatBI 问数助手项目 | 独立完成 - 负责需求拆解与链路设计，基于大模型 API 实现自然语言转 SQL 的数据查询 Demo。 - 通过 Vibe Coding 方式快速搭建 Streamlit 交互界面与查询模块，将人工取数过程缩短为对话式实时查询。 - 设计覆盖聚合、筛选、分组、排序、口径澄清的测试用例集，迭代优化提示词，输出可量化的评测记录。 - 项目文档包含需求说明、提示词模板、测试用例和执行结果，可在面试时全程演示。

再补一条价值描述：

该项目的核心价值是通过自然语言交互降低业务方取数门槛，减少对数据分析师的重复取数依赖。

注意简历措辞有两个原则：第一，不要写“开发了系统”，而是写“设计了链路”和“验证了效果”，体现产品思维；第二，不要夸大，“缩短为对话式实时查询”是 Demo 效果，不是生产指标，面试官追问时要能解释清楚。

7.2 面试展示顺序

面试官问到这个项目时，按四层结构讲：

1. 业务背景：业务方查数效率低，重复取数请求多。
2. 产品设计：设计自然语言问数流程，定义字段口径和问题类型。
3. 技术链路：用户问题进入模型，生成 SQL，执行查询，返回结果。
4. 验证过程：用测试用例集迭代提示词，记录错误修正过程。

讲的时候带上录屏或直接打开本地 Demo，现场演示“2024 年第一季度华东区销售额是多少”，比任何语言描述都更有说服力。

8. 常见问题与排查方法

Vibe Coding 生成代码的过程中，大概率会遇到下面这些问题，给出一套通用排查思路。

几个排查要点展开说明。

依赖安装失败，最常见的原因是没激活虚拟环境。命令行里如果python指向的不是chatbi_env，装再多次也装不对。先激活环境，再执行安装命令。

API Key 泄露风险也要注意。不要把 Key 写死在代码里，用python-dotenv放到.env文件并加入.gitignore。如果项目要放公网展示，更要把 Key 放到服务端环境变量里，不能出现在前端代码中。

模型生成 SQL 不稳定时，不要频繁换大模型，先检查是提示词问题还是接口参数问题。绝大多数情况是提示词里的表结构和字段口径描述不够完整。

9. 最佳实践与使用建议

从 Demo 到作品集，可以按下面几个工程化习惯来推进。

9.1 先跑最小闭环，再扩展功能

第一次做这个项目，不需要一上来就支持几十张表。一张销售订单表够用。先跑通一个问题的完整链路：输入问题，拿到 SQL，执行查询，展示结果。链路通了再扩展多张表、多字段、复杂口径。

9.2 项目目录分清楚

至少分四个目录：

chatbi_project/ ├── data/ # 数据库文件和模拟数据 ├── prompts/ # 提示词模板，按版本编号 ├── test_cases/ # 测试用例 JSON 文件 ├── app/ # 主程序代码 └── outputs/ # 查询结果和评测记录

测试用例和提示词模板单独存，是为了方便迭代。你可以在prompts/v1和prompts/v2之间对比效果，面试时直接展示优化过程。

9.3 记录交互日志

每跑一个测试问题，把输入、生成的 SQL、执行结果、是否正确这四个信息记录下来。

[2025-06-01 14:20] 问题：2024 年总营收是多少 SQL：SELECT SUM(amount) FROM sales_orders WHERE order_date BETWEEN '2024-01-01' AND '2024-12-31'; 结果：1245000 判定：正确

这份日志是作品集最有说服力的附件之一。它展示了你有数据化思维，不是做完一个 Demo 就结束了，而是有评估和迭代闭环。

9.4 数据安全与合规边界

• 演示数据必须脱敏，禁止把真实客户数据、员工个人信息发送到公网 API。
• 如果公司数据有保密要求，一律用自己的模拟数据。
• 上传代码到公开仓库前，检查.env、API Key、数据库文件中是否包含业务信息。
• 如果项目要展示给外部面试官，不要开放“可修改数据”的接口。

这些是底线，不是可选项。

9.5 选择合适的模型

自然语言转 SQL 对模型能力要求不低。开源模型和商用模型的 SQL 生成质量有差异，实际效果需要按你本地情况实测。建议先用一个主流商用 API 跑通链路，再尝试用本地模型替代，对比两者在同样测试用例集上的表现差异。

如果本机能跑本地模型，可以把它理解成一个“低成本版本”。展示时说明两者的成本、延迟、准确率差异，这也是产品经理视角的评价能力。

10. 总结与下一步

ChatBI 是 AI 产品经理作品集里性价比很高的一类项目。原因很简单：业务价值好讲、技术链路清晰、不需要昂贵硬件、可以用 Vibe Coding 快速完成，而且很容易扩展成多个版本，从单表查询做到多轮对话、意图识别、口径管理。

这套作品的竞争力不取决于代码质量有多高，而取决于你手上能跑通一条完整链路，测试记录可追溯，面试时能现场演示两分钟。

如果你打算现在就动手，第一步先做两件事：造一张模拟销售表，配好大模型 API Key。然后让 AI 编程工具按“项目骨架、查询模块、页面展示”的顺序生成代码。不要一次生成整套系统，分步推进，每一步都跑通再进入下一步。

最值得先验证的功能是“自然语言转 SQL 的准确性”，先跑 10 个问题，记录错误类型，再迭代提示词。这一轮迭代做完，你的作品集里就不只是“参与过一个 AI 项目”，而是“独立设计、验证并迭代了一个 ChatBI 问数系统”。

最容易踩的坑是三个：API Key 没配好、表结构没在提示词里写清楚、测试用例没有记录。前两个影响 Demo 能不能跑通，第三个影响作品集能不能讲出深度。

后续扩展方向也有不少：加多轮对话追问、支持多表 join、增加权限控制、接入指标口径中心、做查询缓存、加图表可视化。任何一项补进去，都能让这个项目从“Demo”往“产品化”再走一步。

最后建议，把项目录一段两分钟的演示视频，从输入问题到返回结果一气呵成。面试时先放视频，再打开本地页面现场演示，再把测试记录和提示词版本迭代拿出来。这个组合，基本可以支撑一整段完整的项目深挖问答。