Resume — Alex Chen

Location: Austin, TX Email: [e-mail] LinkedIn: linkedin.com/in/alexchen Portfolio: alexchen.dev GitHub: github.com/alexchen

Professional Summary

Full-stack AI engineer with 6 years building production ML systems. Led the ML platform at a Series B fintech (2020-2024), scaling from 2 models to 15+ in production. Built real-time fraud detection (99.7% precision, $2M/year saved), recommendation engine (18% uplift), and an internal MLOps platform serving 4 engineering teams.

Work Experience

TechFin Corp -- Austin, TX

Senior ML Engineer / ML Platform Lead 2020-2024

• Led ML platform team (3 engineers), built internal MLOps tooling: model registry, A/B testing framework, feature store
• Designed real-time fraud detection pipeline: Kafka → feature computation → model inference → decision engine. 99.7% precision at 50ms p99
• Built recommendation engine for lending products: collaborative filtering + LLM reranking. 18% conversion uplift
• Reduced model deployment time from 2 weeks to 4 hours with CI/CD pipeline (GitHub Actions + SageMaker)
• Established model monitoring: drift detection, performance dashboards (Grafana), automated retraining triggers

DataStartup Inc -- Remote

ML Engineer 2018-2020

• Built NLP pipeline for document classification (BERT fine-tuning, 94% accuracy on legal docs)
• Implemented search ranking with learning-to-rank models
• Set up experiment tracking with MLflow and model versioning

Projects

• FraudShield (Open Source) — Real-time fraud detection framework. Kafka Streams + feature store + model serving. 500+ GitHub stars
• LLM Eval Toolkit (Open Source) — Evaluation framework for LLM applications. Supports custom metrics, regression testing, CI integration

Education

• MS Computer Science, UT Austin (2018)
• BS Computer Science, UC Berkeley (2016)

Skills

• ML/AI: PyTorch, TensorFlow, scikit-learn, Hugging Face, LangChain
• MLOps: SageMaker, MLflow, Kubeflow, Airflow, Feature Store
• Infra: Kubernetes, Kafka, Redis, PostgreSQL, AWS
• Languages: Python, Go, TypeScript, SQL

## 逐节拆解：这个结构为什么长成这样

### 联系信息块：加粗键名 + 冒号 + 纯值

```markdown
**Location:** Austin, TX
**Email:** [e-mail]

联系信息用"加粗键名 + 冒号"的 Markdown 惯例，五个字段（Location / Email / LinkedIn / Portfolio / GitHub）覆盖了简历评估与后续申请流程需要触达候选人的最小集合。注意样例刻意用 --（双连字符）而非 em-dash 书写公司名与城市（TechFin Corp -- Austin, TX），以及用普通连字符写年份区间（2020-2024）——这与仓库的 ATS 归一化约定一致，下文会专门讲。

Professional Summary：三段式浓缩，全部可验证

摘要不是自我评价，而是三句带数字的"简历预告片"：

1. 总量声明——"6 年生产级 ML 系统经验"；
2. 规模声明——"从 2 个模型扩到 15+ 个生产模型"；
3. 结果声明——"99.7% 精度、每年节省 $2M"、"18% 转化提升"、"服务 4 个工程团队"。

这一写法对应 examples/ats-normalization-test.md 中被明令禁止的套话清单——"passionate about machine learning"、"results-oriented professional with a proven track record"、"5+ years of experience in artificial intelligence" 等空洞表述在生成内容中"从一开始就不该出现"。对比之下，样例摘要里的每个形容词背后都挂着一个可复核的数字。

同时，AGENTS.md 对写作有硬性的事实约束：任何量化声明必须能溯源到主文件（cv.md、config/profile.yml、modes/_profile.md 等），衍生文件（如面试准备文档）中的数字不能反哺为主事实。因此写摘要时，先保证这些数字在你自己经历里真实存在，才值得写进来。

Work Experience：标题块 + 全量化 bullet

每段经历的排版遵循固定四元组：

• ### 三级标题 = 公司名 + 城市/远程标记；
• 加粗行 = 职位（**Senior ML Engineer / ML Platform Lead**）；
• 独立一行 = 时间段（2020-2024）；
• 其下是 bullet 列表。

看 TechFin Corp 的 5 条 bullet，可以提炼出 career-ops 示范的"证明点"句式：

bullet	结构	证明点
带领 3 人团队构建 MLOps 工具链	职责 + 交付物	model registry、A/B testing framework、feature store
实时反欺诈管道	架构 + 指标	Kafka → 特征计算 → 模型推理 → 决策引擎，99.7% 精度 @ 50ms p99
贷款产品推荐引擎	技术路线 + 业务指标	协同过滤 + LLM 重排，18% 转化提升
部署时间从 2 周降到 4 小时	前后对比	CI/CD（GitHub Actions + SageMaker）
模型监控体系	持续性工程	漂移检测、Grafana 面板、自动重训触发

每一条都是"做了什么 + 用了什么 + 结果量化"的三段式，没有一条停留在"负责……相关工作"这种无法被 ATS 关键词匹配、也无法被评估模型判分的描述。第二条 bullet 里的 → 箭头是刻意的：它用 ASCII 可读的方式表达管道流向，而在导出 PDF 时会被归一化为英文介词（见下文 ATS 一节）。

Projects：开源项目承担"作者身份"证明

- **FraudShield** (Open Source) — Real-time fraud detection framework. ... 500+ GitHub stars
- **LLM Eval Toolkit** (Open Source) — Evaluation framework for LLM applications. ...

Projects 在 resume 变体中只保留两个开源项目，各带一条"能力声明 + 技术栈 + 可验证规模"。这里要特别注意 AGENTS.md 中的红线：作者身份声明不可谈判——除非 cv.md 或 article-digest.md 明确把某个项目归属于你，任何下游流程都不允许声称你 author 了某个仓库/框架/工具；"用过 X" 不等于 "造了 X"。因此样例把开源项目放在 Projects 而非 Experience 里，让归属关系一目了然。

Skills：按维度分组，而不是平铺关键词

- **ML/AI:** PyTorch, TensorFlow, scikit-learn, Hugging Face, LangChain
- **MLOps:** SageMaker, MLflow, Kubeflow, Airflow, Feature Store
- **Infra:** Kubernetes, Kafka, Redis, PostgreSQL, AWS
- **Languages:** Python, Go, TypeScript, SQL

技能按 ML/AI、MLOps、Infra、Languages 四个维度分组并加粗前缀。这种分组不是美观问题，而是下游工具链的输入格式：upskill.mjs 会从 cv.md / config/profile.yml 提取"已知技能"来做加权技能差距图；jd-skill-gap.mjs 是零 LLM 的 JD 技能分类器，对照 cv.md 输出 existing / supportedByResume / gap 三态，且永远不会自动往 cv.md 里加声明。技能条目越具体（Kubeflow 而非"分布式系统"），这些离线工具的可匹配性越高。

ATS 友好书写：为什么样例避开了花哨 Unicode

examples/ats-normalization-test.md 是 generate-pdf.mjs 文本归一化通道的回归夹具，列出了所有会导致 ATS 解析错误或乱码的 Unicode 码点：

名称	码点	归一化结果
Em-dash	U+2014	-
En-dash	U+2013	-
弯引号（双/单）	U+201C/D、U+2018/9	" / '
省略号	U+2026	...
零宽空格等	U+200B 等	删除
不换行空格	U+00A0	普通空格

而实现位于 generate-pdf.mjs 的 sanitizeText 函数中，它在上面之外还处理了两类 PDF 文本提取器容易丢失的字符：

// Arrows often stripped by PDF text extractors — replace with ASCII for ATS safety.
t = t.replace(/\s*\u2192\s*/g, () => { bump('right-arrow', 1); return ' to '; });
t = t.replace(/\s*\u2190\s*/g, () => { bump('left-arrow', 1); return ' from '; });
// Middle dot and bullet glyphs garble in some extractors — replace with pipe.
t = t.replace(/\s*\u00B7\s*/g, () => { bump('middot', 1); return ' | '; });
t = t.replace(/\s*\u00B7\s*/g, () => { bump('middot', 1); return ' | '; });

（见 generate-pdf.mjs。）每次替换都会计入统计，生成 PDF 时日志会打印类似 🧹 ATS normalization: N replacements (em-dash=X, smart-double-quote=Y, ...) 的行——examples/ats-normalization-test.md 末尾给出了端到端验证命令：node generate-pdf.mjs /tmp/dirty-cv.html /tmp/clean-cv.pdf --format=a4。

回到样例简历：Kafka → feature computation → model inference → decision engine 这条 bullet 在 PDF 导出后会变成 Kafka to feature computation to model inference to decision engine，在 ATS 纯文本检索中依然能命中 "Kafka"、"inference" 等关键词。这说明两件事：

1. 在源 Markdown 里用 → 是安全的（导出层会兜底归一化），但用 -- 写年份区间和公司分隔、避免弯引号和 em-dash 则是"从源头零替换"的最稳写法；
2. 归一化只修字符，不修文风——examples/ats-normalization-test.md 明确写道 "The normalizer does NOT fix writing style"，空洞套话属于写作期就被 modes/_shared.md 规则禁止的内容。

career-ops 如何消费这份文件：从模板到流水线输入

定位与归属：User Layer 的规范事实源

在 career-ops 的分层模型里，cv.md 属于 User Layer（永不自动更新的个人层），与 config/profile.yml、modes/_profile.md 并列，AGENTS.md 将其列为个性化数据的核心。AGENTS.md 进一步明确："项目根目录的 cv.md 是规范 CV"。也就是说：examples/resume-example.md 只是模板，你基于它写出的根目录 cv.md 才是整个系统的事实源。

首次使用：doctor 检查 + 结构化建档

examples/README.md 给出的落地路径只有四步：

1. npm run doctor 检查前置条件；
2. 以 cv-example.md（或本文件的 resume 变体）为结构指南写出 cv.md；
3. 可选：用 article-digest-example.md 作为 article-digest.md 的模板（能提升评估质量）；
4. 职业跨越两个典型画像（如工程师 + 讲师）时，参考 examples/dual-track-engineer-instructor/ 的完整配置。

AGENTS.md 定义了 cv.md 缺失时的建档流程：Agent 会请求你粘贴现有简历、LinkedIn 信息或口述经历，然后"从你提供的任何材料创建 cv.md——干净的 Markdown，带标准分区（Summary、Experience、Projects、Education、Skills）"。这份样例的五级结构（Professional Summary / Work Experience / Projects / Education / Skills）正是该流程的目标形态。

分区顺序有守卫：不能随意调序

cv.md 的分区标题不是装饰，导出 HTML/PDF 时其顺序会被校验。tests/cv-section-order.test.mjs 中固定的期望顺序是：

const expected = ['Professional Summary', 'Work Experience', 'Projects', 'Skills', 'Certifications', 'Education'];