夜雨聆风目录1. 业务场景一句话 2. 30 秒开场（面试先用这段） 3. 整体架构（面试画板用） 4. 核心概念速查（面试前必背） 5. 具体怎么用（分 4 块讲） 5.1 Skills：把「团队规范」变成 AI 的 SOP 5.2 Rules：AI 编码的「质量门禁」 5.3 Commands + OpenSpec：规格驱动，限制 AI 乱改 5.4 LLM 知识库平台：代码 → 业务文档 6. 技术难点 & 解决方案（面试高频） 难点1：LLM 幻觉 — 指标口径、血缘讲错 难点2：长脚本超出上下文 / Prompt 过长 难点3：Cursor SDK 集成踩坑（Windows 环境） 难点4：AI 生成的 ETL 能跑但不符团队规范 难点5：500+ 脚本文档化 — 成本与增量 难点6：Shell 里 SQL 难解析（regex 局限） 7. 面试模拟 Q&A Q1：你的 AI 辅助开发和直接用 ChatGPT 有什么区别？ Q2：Skills 和 Rules 有什么区别？ Q3：知识库平台的技术架构是什么？ Q4：这和 RAG 有什么关系？ Q5：MCP 你实际用过吗？ Q6：怎么衡量 AI 提效？ Q7：AI 会不会替代数仓工程师？ Q8：遇到的最大坑是什么？ Q9：如果让你从零再做一遍，会怎么改进？ Q10：OpenSpec 在实际需求里怎么用？ 8. 1 分钟版 vs 3 分钟版 1 分钟版 3 分钟版 9. 速记清单（面试前 5 分钟） 10. 相关文件索引（面试时可提及）
对应简历：项目一「AI 辅助数仓开发体系 + 企业级离线数仓平台」相关仓库：
datawarehouse_manager（Skills/Rules/Commands）、dw-knowledge-base（LLM 知识库平台）
1. 业务场景一句话
不是简单「用 ChatGPT 写 SQL」，而是把 数仓团队的规范、模板、文档标准编码成 AI 可执行的约束，再搭建 代码 → 结构化解析 → LLM 生成业务文档 的自动化链路，实现「规范编码化 + 文档自动化 + 规格驱动交付」。
2. 30 秒开场（面试先用这段）
我做 AI 辅助开发，不是简单「用 ChatGPT 写 SQL」，而是把 数仓团队的规范、模板、文档标准编码成 AI 可执行的约束，再搭一条 代码 → 结构化解析 → LLM 生成业务文档 的自动化链路。
日常开发在 Cursor 里用 Skills + Rules + Commands 约束 AI 产出；文档侧自研了 FastAPI + Cursor SDK 知识库平台，对 500+ 数仓脚本做增量文档化。核心是：人定规范，AI 执行，关键节点人工校验。
3. 整体架构（面试画板用）
┌─────────────────────────────────────────────────────────┐│ 日常开发（Cursor IDE） ││ Rules（底线约束）→ Skills（领域知识）→ Commands（流程） ││ 人提需求 → AI 生成/改 ETL → 人 Review → 上线 │└─────────────────────────────────────────────────────────┘┌─────────────────────────────────────────────────────────┐│ 知识库平台（dw-knowledge-base） ││ Git/文件变更感知 → Python 解析器 → Prompt 组装 ││ ↓ regex 快速文档 ↓ skill 脚本走 LLM 高质量文档 ││ Web 浏览 / 搜索 / 一键刷新 │└─────────────────────────────────────────────────────────┘定位：
Cursor 侧：解决「怎么写得规范、写得快」
知识库平台：解决「怎么让业务/新人看得懂、文档跟得上代码」
4. 核心概念速查（面试前必背）
概念 | 是什么 | 作用 |
|---|---|---|
Skills |
| 领域 SOP：何时触发、按什么流程、引用哪些模板 |
Rules |
| 常驻约束：脚本头、flag 检查、分区剪裁等底线 |
Commands |
| 斜杠命令：如 |
OpenSpec |
| 规格驱动：proposal → design → tasks → apply → archive |
双轨文档 | regex + skill | 普通脚本快速生成；核心表走 LLM 高质量生成 |
增量感知 |
| 只处理 hash 变更的脚本，不全量重跑 |
5. 具体怎么用（分 4 块讲）
5.1 Skills：把「团队规范」变成 AI 的 SOP
机制： Cursor Agent 根据 Skill 的 description 自动加载对应 SKILL.md，按其中工作流和模板产出。
Skill | 触发场景 | 实际效果 |
|---|---|---|
| 新建/改造 ETL 脚本 | 按 Shell 模板起稿：引 |
| 解读脚本、生成表文档 | 固定输出：表概览 → Mermaid 血缘 → 业务规则 → 指标字典 |
| 写 Doris DDL/查询 | 遵循分区分桶、Duplicate Key、Colocate Join 等规范 |
举例（面试话术）：
我要新建一张 DWS 月表，会对 Cursor 说：「按 dw-dev-standard，基于 job_template 新建
pro_dws_xxx_mi.sh」。AI 会先读 Skill，再读模板，产出带#target_table、#source_table头注释的脚本，而不是随便写一段 SQL。
5.2 Rules：AI 编码的「质量门禁」
机制： Rules 常驻注入 AI 上下文，比 Skill 更「硬」，相当于 linter 规则。
Rule | 约束内容 |
|---|---|
开发规范 | 脚本头、 |
SQL 优化 | 先过滤后 JOIN、复杂 SQL 拆临时表、避免全表窗口 |
代码片段 | 指向 |
变量速查 |
|
举例（面试话术）：
以前 AI 容易漏
flag=$?检查，或 WHERE 里写substr(datestr,1,6)导致分区剪裁失效。Rules 常驻后，生成代码会默认带上这些底线，Review 时主要看业务逻辑而不是格式问题。
5.3 Commands + OpenSpec：规格驱动，限制 AI 乱改
流程：
新需求 →
/opsx:propose：写 Why、What、Impact拆 design / tasks
/opsx:apply按 task 逐项改代码完成后 archive，留变更记录
价值（面试话术）：
数仓脚本动辄几百行，如果让 AI「自由发挥」，很容易改错上下游口径。OpenSpec 相当于给 AI 划边界：只改这次 Spec 里声明的文件和范围，减少幻觉和过度修改。
5.4 LLM 知识库平台：代码 → 业务文档
技术链路：
数仓 Git 仓库 (datawarehouse_manager) ↓【变更感知】metadata.json 存 file_hash，对比 MD5 找变更脚本 ↓【双轨生成】 ├─ regex 轨：parser.py 正则提取 → generator.py 拼 Markdown（快、稳） └─ skill 轨：llm_generator.py → 组装 Prompt → Cursor SDK (Node) → LLM 生成（质量高） ↓【落盘】docs/dw-dws/xxx.md ↓【Web】FastAPI 分层浏览、全文搜索、一键 refreshPrompt 组装（Prompt Engineering 亮点）：
角色设定：「你是数仓文档专家，面向业务人员」
硬约束：全中文、CASE WHEN 译成业务语言、必须 Mermaid 血缘、
${std_db_dws}→dwsSkill 注入：
dw-script-doc的 SKILL.md（截断 4000 字）+ 输出模板脚本全文：作为上下文输入
双轨设计原因：
500+ 脚本全走 LLM：慢、贵、不稳定
regex 轨：变更脚本快速出「结构正确」的文档（表名、JOIN、字段）
skill 轨：
skill_scripts.json配置的核心表，走 LLM 出「业务语义准确」的文档
Web 端使用：
业务/新人打开知识库 → 按 ODS/DWD/DWS 分层找表 → 看血缘和指标口径；改完脚本点「拉取并刷新」，只处理 hash 变化的脚本，不用全量重跑。
refresh 两阶段（/api/refresh）：
Phase 1：
skill_scripts.json白名单 → Cursor SDK → LLM 文档（已生成且 gen_type=skill 的 skip）Phase 2：其余脚本 hash 变更 → regex 解析 → 快速文档
6. 技术难点 & 解决方案（面试高频）
难点 1：LLM 幻觉 — 指标口径、血缘讲错
现象： 直接丢脚本给模型，会编造不存在的源表，或把 CASE WHEN 解释错。
解法：
Prompt 注入 Skill 模板 + 输出结构约束
Python 解析器先抽
#target_table、JOIN、CASE WHEN、分区字段regex 轨提供「结构化事实骨架」
人机协同：LLM 文档必须人工 spot check
核心表走 skill 轨，普通表走 regex 轨
话术：
我们没有追求 100% 全自动，而是 「解析器提供事实骨架，LLM 填业务语义，人做最后校验」。
难点 2：长脚本超出上下文 / Prompt 过长
现象： 单脚本 500～1000 行，SQL 嵌在 Shell 字符串里，token 爆掉或回答截断。
解法：
Skill 说明截断到 4000 字符，模板单独注入
解析器只把关键 SQL 块、DDL、CASE WHEN 结构化提取
LLM 调用设 900 秒 timeout，失败进 errors 列表，不阻塞整批
难点 3：Cursor SDK 集成踩坑（Windows 环境）
现象： Python 调 LLM 需 subprocess 调 Node.js + @cursor/sdk；Windows 上 npm/node 路径、API Key、模型名易出问题。
实际处理：
_find_npm()/_find_node()多路径探测首次运行自动
npm install @cursor/sdk.env里CURSOR_MODEL=default比指定 composer 模型更稳API Key 从
.env加载，避免系统环境变量旧值覆盖
话术：
这部分让我理解了 LLM 应用不只是 Prompt，还有运行时、依赖、超时、错误隔离 等工程问题。
难点 4：AI 生成的 ETL 能跑但不符团队规范
现象： SQL 逻辑对，但缺脚本头、日期变量命名不对、没分区剪裁。
解法：
Rules 常驻 + Skill 工作流（先模板后改）
OpenSpec task 里明确「必须满足 dev-rules 自检清单」
仍坚持 人工 Review + 测试环境跑批
难点 5：500+ 脚本文档化 — 成本与增量
现象： 全量 LLM 生成耗时长、占 Cursor 账号额度。
解法：
MD5 hash 增量：只处理 hash 变化的脚本
skill 文档生成后标记
gen_type=skill，默认 skip 不重复生成force 刷新只清 regex 文档，skill 文档保护不删
双轨：大批量 regex，重点表 LLM
难点 6：Shell 里 SQL 难解析（regex 局限）
现象： SQL 在 "..." 多行字符串、变量拼接、动态 SQL，正则提取 JOIN/CASE WHEN 会漏。
解法：
话术：
regex 解析不是银弹，所以我们用 「规范写脚本 + 双轨生成 + 人工补洞」 组合，而不是追求全自动完美解析。
7. 面试模拟 Q&A
Q1：你的 AI 辅助开发和直接用 ChatGPT 有什么区别？
核心区别是 规范产品化。ChatGPT 是通用模型，不知道我们团队的 Shell 模板、分区字段命名、flag 检查等约定。我把这些写进 Skills 和 Rules，AI 在 Cursor 里会自动加载，产出更接近「团队内资深同事写的代码」。另外还有 OpenSpec 控改动范围、知识库平台做文档自动化，是完整工程链路，不是单次对话。
Q2：Skills 和 Rules 有什么区别？
Rules 是常驻底线，不管问什么都会生效，比如必须有
#target_table、必须分区剪裁。Skills 是按场景触发的领域知识，比如「新建 DWS 脚本」才加载 dw-dev-standard，「生成表文档」才加载 dw-script-doc。可以理解为 Rules 是 linter，Skills 是 playbook。
Q3：知识库平台的技术架构是什么？
FastAPI 提供 Web 和 API；Python
parser.py用正则从 Shell 脚本提取元信息、DDL、JOIN、CASE WHEN；generator.py拼 regex 文档；核心表走llm_generator.py，组装 Prompt 后 subprocess 调 Node.js 的 Cursor SDK 生成 LLM 文档。变更感知靠metadata.json存 MD5，refresh 时只处理变更脚本。Skill 模板和说明直接从数仓仓库的.cursor/skills/dw-script-doc/读取，保证 Prompt 和 IDE 里用的是同一套规范。
Q4：这和 RAG 有什么关系？
本质是 RAG 思路的变体：检索的是「脚本全文 + 解析器抽的结构化片段 + Skill 模板」，再组装 Prompt 给 LLM。检索源目前是 Git 仓库里的代码文件，不是向量库；后续可以演进成 embedding 检索相似脚本作 few-shot，或接 MCP 查 metastore 血缘。
Q5：MCP 你实际用过吗？
目前主链路是 Cursor Skills/Rules + 自研 FastAPI 平台。MCP 我了解其 「工具协议化接入 Agent」 的思路，例如把元数据查询、血缘查询封装成 MCP Server，Agent 按需调用——这是探索方向，简历里写的是认知层面，避免夸大已上线。
Q6：怎么衡量 AI 提效？
三个指标：① 新人上手从约 2 周降到 3–5 天；② 单表文档从 2–4 小时降到约 15 分钟（生成+校验）；③ ETL 一次通过率提升（少犯分区、flag 等低级错误）。数仓稳定性（任务失败率）仍是传统工程化贡献，AI 主要提效在规范和文档。
Q7：AI 会不会替代数仓工程师？
不会替代，而是 把重复劳动自动化：模板化脚本、文档翻译、规范检查。复杂口径、跨表血缘、性能调优、和业务/财务对齐，仍要人判断。我的定位是 「懂数仓的人 + 会把规范产品化的人」。
Q8：遇到的最大坑是什么？
Cursor SDK 在 Windows 下的工程集成。不是调个 API 就完事，要处理 Node 依赖、npm 路径、模型选择、900 秒超时、单脚本失败不拖垮整批。第二个坑是 幻觉，靠双轨生成 + 人工校验解决，不盲目追求全自动。
Q9：如果让你从零再做一遍，会怎么改进？
① 先 Rules/Skills 再 LLM 平台；② 强制脚本头 metadata，降低解析失败率；③ 核心表白名单走 LLM，其余 regex；④ 加文档质量抽检（解析器抽的血缘字段数 vs LLM 输出对比）；⑤ 评估 MCP 接 hive metastore / 调度系统；⑥ 考虑 Hooks 在保存/提交时触发规范检查（目前未落地）。
Q10：OpenSpec 在实际需求里怎么用？
比如要新增一张 DWS 业绩表：先
/opsx:propose写需求和影响面，再拆 design（表结构、上游依赖）和 tasks（建表 DDL、ETL 脚本、hive2mysql）。AI 按 task 逐项实现，每步可对照 Spec 检查是否越界。做完 archive，以后查变更历史也有据可查。适合 中等以上复杂度、涉及多文件 的需求，小改直接改脚本即可。
8. 1 分钟版 vs 3 分钟版
1 分钟版
Skills/Rules 规范 AI 写 ETL → OpenSpec 控范围 → 自研知识库 Git 增量 + 双轨文档 → 难题是幻觉和 SDK 工程集成，用解析器+模板+人工校验解决。人定规范，AI 执行，关键节点人审。
3 分钟版
在 1 分钟版基础上补充：
举一个 Skill 例子（dw-dev-standard 新建脚本）
举一个 Rule 例子（flag 检查、分区剪裁）
讲知识库 refresh 两阶段（skill LLM + regex 增量）
讲 2 个难题（幻觉、Cursor SDK Windows 集成）及解法
给一个量化成果（500+ 脚本、15 分钟/表）
9. 速记清单（面试前 5 分钟）
定位：规范编码化 + 文档自动化 + 规格驱动，不是裸聊 ChatGPT
Cursor 三板斧：Skills（SOP）/ Rules（底线）/ Commands（OpenSpec 流程）
3 套 Skill：dw-dev-standard / dw-script-doc / doris-dev
知识库双轨：regex 快 + LLM 准，MD5 增量
Prompt 四件套：角色 + 硬约束 + Skill 模板 + 脚本全文
六大难题：幻觉、上下文、SDK 集成、规范不符、成本增量、regex 局限
核心原则：解析器给骨架，LLM 填语义，人做校验
量化：2 周→3-5 天、2-4 小时→15 分钟、500+ 脚本
诚实边界：MCP/Hooks 是认知或规划，未夸大已上线
金句：人定规范，AI 执行，关键节点人工校验
10. 相关文件索引（面试时可提及）
路径 | 说明 |
|---|---|
| ETL 开发 Skill |
| 文档生成 Skill |
| 开发规范 Rule |
| OpenSpec 变更目录 |
| LLM 文档生成器 |
| Shell/SQL 正则解析器 |
| FastAPI + refresh 两阶段逻辑 |
