★ FEATURED ARTICLE 最近很多做产品经理的朋友都在问同一个问题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 通常包含五个环节用户输入问题。系统理解意图识别用户想查哪个指标、哪个维度、哪个时间范围。将自然语言转换为 SQL 查询语句这一步就是 NL2SQL。在数据库上执行 SQL并校验权限和结果。将查询结果以图表、文本表格等形式返回给用户。传统 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 的完整请求链路由六个环节组成用户提问。意图预处理判断问题是否在支持范围内必要时改写为更清晰的查询表达。NL2SQL结合表结构信息和规则约束将自然语言转换为 SQL。安全校验检查 SQL 是否违规、是否越权。查询执行连接数据库执行 SQL获取结构化结果。结果呈现把结果转化为自然语言摘要和可视化图表。这个链路中产品经理最需要关注的是第 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 快速搭建 Demo5.1 环境准备与前置条件为了避免版本兼容问题这里先说明通用环境不做死版本绑定。实操时以你本机实际环境为准。建议环境操作系统Windows 10/11 或 macOS 均可。Python3.10 以上。数据库SQLite 或本机 MySQL。大模型接入任意支持 Chat Completions 接口的模型服务通过 API Key 调用。开发工具VS Code 或 Cursor 均可建议使用支持 AI 对话插件的 IDE。如果你完全没接触过 Vibe Coding建议先用一个最小任务试水让 AI 帮你生成“一个网页包含输入框、按钮和结果展示区域”。跑通这个流程后再开始完整项目。5.2 用对话迭代的方式描述需求Vibe Coding 能不能成功很大程度取决于你怎么描述需求。这里给出一个可复用的对话框架先描述最终目标不要写技术实现细节。再描述页面组成指明每个区域的用途。逐步补充交互逻辑例如“用户输入问题后显示加载状态接口返回后渲染结果”。出现报错时把完整报错信息复制进对话框要求 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_keyyour-api-key, base_urlyour-base-url) TABLE_SCHEMA_PROMPT 你是数据分析师根据表结构生成 SQL。 表结构 1. dim_regionregion_id, region_name, manager 2. dim_productproduct_id, product_name, category 3. fact_orderorder_id, order_date, region_id, product_id, sales_amount, order_count 只输出 SQL不输出解释。 def generate_sql(question: str) - str: response client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: TABLE_SCHEMA_PROMPT}, {role: user, content: question} ], temperature0 ) 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(port5001, debugTrue)运行方式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, layoutwide) 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 类产品推荐从四个维度评估指标计算方式说明SQL 生成准确率正确 SQL 数 / 总测试问题数用于判断模型是否理解业务口径结果一致性查询结果与预期值一致的占比直接反映用户拿到答案是否正确端到端成功率成功返回结果的问题数 / 总问题数受接口、权限、超时影响平均耗时从提问到返回结果的总时长体现产品可用性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 面试时一定会被追问的问题下面几个问题几乎必问建议提前准备。你的 NL2SQL 准确率是怎么保证的回答思路主要靠限定业务范围、清晰表结构和 Prompt 业务规则。再加评测集持续验证不追求万能问答。如果 SQL 生成错但用户没发现怎么办回答思路一是展示 SQL 给用户可确认二是在界面上加“数据更新时间与口径说明”三是对高风险问题做二次确认。数据权限怎么控制回答思路使用只读账号按用户归属组织设置行级权限所有生成语句经过安全过滤。涉及敏感数据严格遵循最小权限原则。Vibe Coding 这种方式适合生产项目吗回答思路适合原型和内部工具生产级系统仍需完整测试、代码评审和运维控制。作品集项目正好体现了这种边界判断。7.3 不要写什么不要在简历里写“基于大数据技术栈构建 ChatBI 平台”“支撑亿级数据实时查询”。没有真实项目依据的数字和规模在面试追问下会快速崩盘。宁可写“Demo 覆盖 Top10 问题”也不要写模糊的大词。8. 常见问题与排查思路8.1 常见问题表格问题现象可能原因排查方式解决方案接口返回 500数据库未初始化或连接串错误查看控制台完整报错确认sales.db存在路径正确SQL 生成准确率低表结构描述不清晰或缺少业务规则查看错误 SQL 集中分析在 Prompt 中补充字段口径的和规则示例生成 SQL 不是 SELECT模型被注入提示词攻击检查用户输入是否包含恶意指令加强安全校验并拒绝非 SELECT 开头语句查询结果与预期不一致日期窗口计算口径错误对比预期 SQL 和实际 SQL统一时间口径添加时间格式要求页面长时间无响应模型 API 响应慢或超时增加日志记录耗时设置超时时间并优化 Prompt 长度Vibe Coding 生成代码无法运行环境依赖不匹配查看 Traceback 中缺少的包名单独安装缺失依赖避免批量升级依赖8.2 排查路径如果项目跑不通先按下面顺序排查看后端接口是否启动成功访问http://localhost:5001是否能返回内容。看浏览器开发者工具中 Network 面板的请求状态码。看模型 API 返回内容是否包含非 SQL 文本例如 Markdown 代码块。看数据库查询语句是否执行成功是否报“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 跑通再回来完善评测和简历描述——只要开始动手这个作品集就不远了。
阅读完成 · 觉得有帮助？
