HELLO / 你好
2027届 · 北京 · 数据分析 / AI应用
把复杂业务问题，
变成可验证、可复用的数据与AI方案。
我是张婕，中国矿业大学（北京）计算数学硕士。擅长从指标口径与SQL数据底座出发，完成经营分析、异常归因和业务交付，并通过RAG、Text-to-SQL与Agent评测探索AI在数据工作中的实际应用。
211计算数学硕士
3段连续数据实践
端到端SQL → BI → 决策
DATA ANALYST张婕 / ZHANG JIE
01 / POSITIONING
我不是只会“取数”的分析师
我更关注一条完整链路：先把数据与口径做可靠，再用分析定位问题，把结论交给业务使用，并根据反馈继续迭代。
02 / FEATURED CASE
猎聘 ToB 销售经营分析闭环
一个案例讲清楚：业务为什么提需求、数据怎样建设、分析如何交付，以及结果怎样继续迭代。
真实实习项目 · 脱敏呈现
从分散取数，到可复用的经营数据底座
销售运营需要频繁查询回款、客户覆盖、过程行为和续约，但数据散落在多张主题表，类似指标又因套餐与统计场景存在不同口径。
- 我的角色
- 主体SQL、口径梳理、数据校验、BI与分析交付
- 技术环境
- Hive / Spark SQL · BI · Excel · Python
- 业务使用方
- 销售运营、销售主管与客户运营
BUSINESS OUTCOME
最终交付的不是一张表，而是一套可持续使用的经营分析链路
- 日常监控：运营在BI查看回款、覆盖、触达和续约，并下钻到组织与个人
- 主管复盘：用分层名单区分标杆、高动低产、续约风险和新人观察对象
- 客户洞察：将DID研究转成传统行业和新一线城市的AI人才趋势材料
- 知识复用：指标白皮书继续作为DataAgent知识库与SQL生成依据
01
BUSINESS QUESTION
业务为什么需要这套数据？
销售运营日常需要回答“本月回款如何、客户覆盖是否充分、续约有没有风险、销售动作是否正常”。原有信息分散在人事、合同、回款、客户、触达和续约等主题表，同名指标还会因为套餐和统计场景不同而含义不同。每次临时需求都要重新找表、问口径、写SQL。
02
MY WORK
我不是接到字段就写SQL，而是先还原指标
分层方向由领导提出、评分权重由带教确定；我负责把方案真正落成数据产品：翻查历史SQL、向带教确认指标定义，完成主体SQL、清洗、指标选择、评分分层、Excel报告和结论汇报。
- 以“月份 × 销售人员”为统一粒度，分别聚合后再关联，避免一对多Join造成回款翻倍
- 整合基础属性、业绩结果、过程行为和客户质量四类指标
- 处理空值、重复记录、历史组织变化及不同套餐口径差异
- 通过总量核对、唯一键检查和单人抽样验证结果
01口径梳理找表、读历史SQL、确认定义
→02宽表建设聚合、关联、清洗、校验
→03BI与Excel汇总、下钻、明细交付
→04经营分析评分、分层、问题标签
→05业务沟通解释口径、回答追问
03
KEY FINDING
从“谁业绩差”推进到“为什么业绩差”
对779名销售，从业绩、行为和续约三个维度评分，并将KA与中小客户销售分开比较。结果中最值得继续诊断的是331名B层销售：其行为得分与A层接近，但业绩得分明显偏弱，说明这批人不能简单归因为“不努力”，更可能卡在客户质量、商机推进或成交转化。
331B层销售
63.4B层行为得分
63.7A层行为得分
45.4B层业绩得分
04
DELIVERY & USE
业务拿到的不是一个总分，而是一套可继续追问的经营视图
交付给销售运营的内容包括经营宽表、BI看板、销售分层Excel、组织汇总与指标口径说明。运营可先看组织整体的回款、动作和续约，再下钻到团队与个人；分层结果则用于识别标杆、高动低产和风险人员，并作为主管复盘的分析输入。
经营宽表BI看板个人分层组织汇总指标白皮书结论汇报
05
FEEDBACK & ITERATION
业务反馈没有停留在“挺好”，而是推动了两轮改版
宽表 / BI反馈
指标太多、重点不清，相似指标容易产生口径争议
我据此把BI重构为业绩、行为、续约三层：顶部保留关键指标，中间支持组织与销售类型筛选，底部保留个人明细；同时制作指标白皮书，写清业务含义、来源表、统计粒度、计算逻辑和SQL。运营再次使用后，提需求会进一步确认窗口、客户范围和使用场景，减少反复确认。
销售分层反馈
S/A/B/C过粗，同层销售需要不同管理动作
同为B层，既有“动作充分但转化弱”，也有“续约风险”和“均衡待观察”。我在等级之外补充问题类型标签，并分开KA与中小客户口径、增加组织汇总，让运营能判断先支持哪个团队、采用哪种动作。
06
BUSINESS ACTION
业务拿到结果后，真正改变的是复盘方式
过去主管复盘容易集中在“本月回款多少”；分层交付后，运营可以把结果、过程和续约放在一起看，并针对不同名单采取不同动作。数据分析不替主管下结论，而是把问题人群、诊断方向和需要继续核查的证据提前整理出来。
S / A标杆复盘客户跟进节奏、录音和成交过程，沉淀可复制打法
B层高动低产逐人检查客户覆盖、商机质量、推进环节与成交转化
续约风险拉取到期客户清单，由主管提前介入重点客户
C层与新人区分资源、能力和意愿；新人优先观察动作达标与学习曲线
03 / AI APPLICATION CASE
DataAgent智能取数与评测系统
这不是一个只调用大模型的聊天页面，而是一个覆盖知识约束、SQL生成、安全执行、结果评测和人工复核的Text-to-SQL原型。
业务问题
业务人员用自然语言描述指标、对象与时间范围。
知识检索
从Schema、字段说明、指标口径与相似样例中召回限定上下文。
ChromaDB · bge-small-zh-v1.5生成与执行
DeepSeek生成SQL；只允许SELECT/WITH，并以SQLite只读连接执行。
拦截写操作 · PRAGMA · 多语句结果复核
同时展示结果、SQL与口径解释，重要结论保留人工复核节点。
分层评测题
正确率
SQL执行成功率
复核通过
口径说明：人工语义复核与严格自动正确率是两套独立口径。3道严格评测未通过题为输出列结构、辅助列数量或标签表达差异，人工复核结果不计入自动正确率。
EVALUATION-DRIVEN ITERATION
不是展示一次结果，而是用失败案例推动迭代
通过执行生成SQL与参考SQL并比较实际查询结果开展评估。针对时间窗口、逐人平均、维度字段映射和复杂续约口径补充业务规则，使严格自动正确率由Baseline的50%提升至85%，最终SQL执行成功率达到100%。
Baseline Schema + 关键词口径RAG v1 语义检索与相似样例最终版 RAG + 业务口径规则
WHY IT IS RELATIVELY RELIABLE
可信来自约束、执行和评测，而不是“模型看起来聪明”
- 知识约束Schema、指标定义与样例限定生成范围
- 执行防线只读SQL校验与只读数据库连接
- 评测闭环比较实际查询结果，而非SQL字符串
- 边界说明重要业务结论仍需数据人员复核
04 / PROJECT MAP
同一条业务主线上的四层能力
这些不是四个孤立项目，而是从数据建设到分析复用的递进关系。
05 / OTHER EXPERIENCE
另外两段经历，也说明我能处理不同类型的数据
猎聘展示业务闭环；另外两段更侧重复杂数据处理、异常归因与模型评估。
CASE 02
时空数据 · 异常归因北京融信数联
从千万级轨迹数据中解释：哪里变了，为什么变
业务问题
政府与交通规划客户看到通勤时长、职住匹配度发生波动，需要判断是数据异常，还是政策、交通建设与区域变化造成的真实异动。
01轨迹清洗
识别缺失、偏移与异常记录，为空间评估建立可靠数据输入。
02多维归因
按时间、区域和人群拆解，并与真实业务变量交叉验证。
03空间表达
使用QGIS与Excel呈现区域差异，输出归因分析报告。
交付结果
客户不仅能看到“哪个区域变了”，还能理解变化的可能驱动因素，为后续交通和空间策略调整提供依据。
CASE 03
时序建模 · AI评估知洲数联
围绕“环境评估可靠性”开展的三条数据工作线
共同目标
这不是一个从数据库自然走到Agent的单一项目，而是三项并行工作：分别解决环境数据可用、预测结果稳定和建筑评分可复核的问题。
01数据可用
参与MySQL至InfluxDB的流转，以Python与SQL处理长周期缺失和偏差。
02预测稳定
构建多区域热湿耦合模型，以遗传算法、动态修正和残差补偿优化极端场景表现。
03评分可复核
大模型解析非结构化描述并提取特征，数学公式承担确定性量化计算。
核心判断
AI适合处理语言理解，但数值评分应交给明确公式。这样的职责拆分能降低计算幻觉，同时保留评估过程的可解释性。
同道猎聘集团 · 数据分析实习生
主案例：ToB经营数据底座、销售分层、DID行业洞察与DataAgent探索。
北京融信数联 · 数据分析实习生
千万级时空轨迹数据、异常检测、空间评估与异动归因。
知洲数联 · 研究助理（数据方向）
时序数据治理、机器学习模型与可复核的AI评估链路。
06 / CONTACT
如果你正在寻找一名
能把数据讲清楚的分析师
欢迎联系我，进一步查看项目细节、脱敏材料与完整简历。