目录

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. 核心概念速查（面试前必背）

5. 具体怎么用（分 4 块讲）

5.1 Skills：把「团队规范」变成 AI 的 SOP

机制： Cursor Agent 根据 Skill 的 description 自动加载对应 SKILL.md，按其中工作流和模板产出。

举例（面试话术）：

我要新建一张 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 规则。

举例（面试话术）：

以前 AI 容易漏 flag=$? 检查，或 WHERE 里写 substr(datestr,1,6) 导致分区剪裁失效。Rules 常驻后，生成代码会默认带上这些底线，Review 时主要看业务逻辑而不是格式问题。

5.3 Commands + OpenSpec：规格驱动，限制 AI 乱改

流程：

1. 新需求 → /opsx:propose：写 Why、What、Impact

2. 拆 design / tasks

3. /opsx:apply 按 task 逐项改代码

4. 完成后 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 分层浏览、全文搜索、一键 refresh

Prompt 组装（Prompt Engineering 亮点）：

1. 角色设定：「你是数仓文档专家，面向业务人员」

2. 硬约束：全中文、CASE WHEN 译成业务语言、必须 Mermaid 血缘、${std_db_dws}→dws

3. Skill 注入：dw-script-doc 的 SKILL.md（截断 4000 字）+ 输出模板

4. 脚本全文：作为上下文输入

双轨设计原因：

• 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 会漏。

解法：

• 依赖脚本头 **#target_table / #source_table** 规范

• 复杂脚本优先走 LLM skill 轨，regex 作兜底

• 解析失败在 Web 端进 errors，人工补文档

话术：

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 分钟）

1. 定位：规范编码化 + 文档自动化 + 规格驱动，不是裸聊 ChatGPT

2. Cursor 三板斧：Skills（SOP）/ Rules（底线）/ Commands（OpenSpec 流程）

3. 3 套 Skill：dw-dev-standard / dw-script-doc / doris-dev

4. 知识库双轨：regex 快 + LLM 准，MD5 增量

5. Prompt 四件套：角色 + 硬约束 + Skill 模板 + 脚本全文

6. 六大难题：幻觉、上下文、SDK 集成、规范不符、成本增量、regex 局限

7. 核心原则：解析器给骨架，LLM 填语义，人做校验

8. 量化：2 周→3-5 天、2-4 小时→15 分钟、500+ 脚本

9. 诚实边界：MCP/Hooks 是认知或规划，未夸大已上线

10. 金句：人定规范，AI 执行，关键节点人工校验

10. 相关文件索引（面试时可提及）