Resume Pool

这篇文章整理一份公开可读的简历素材库。它不是最终简历，而是把经历拆成岗位方向、项目事实、可复用表达和风险边界。未公开的客户信息、验收状态、内部指标、数据规模、部署环境和商业细节不放在这里。

0. 基础信息

公开链接

GitHub：github.com/John-Ferrel
Blog：John-Ferrel’s Blog

教育经历

学校：复旦大学
专业：数据科学与大数据技术
时间：2019.09 - 2024.06
荣誉：2023.10 复旦大学优秀学生
相关课程：计算机基础、概率论与数理统计、线性代数、数据结构、人工智能、深度学习、社会网络挖掘、社会科学数据挖掘、图数据分析、计算机视觉等

2-3 年经验简历组织原则

整理原则是按“工作项目主线”组织，而不是按工具或课程经历堆叠。HR 通常需要快速判断岗位匹配度、项目阶段和职责边界；CTO / 技术面试官更关注系统取舍、风险控制、工程落地和是否能被追问。

优先展示：

真实业务问题：为什么要做，解决什么组织或业务流程问题。
职责边界：主导了哪些设计、实现、验证或沟通工作。
工程取舍：为什么做 MVP / POC，为什么不直接做完整平台。
数据与权限边界：哪些信息可用，哪些信息不能让模型直接使用或写回。
可交付物：接口契约、数据 pipeline、验证流程、服务化模块、知识库工作流、部署闭环。
可追问性：每条 bullet 都能展开到 2-3 层具体设计。

整理时刻意避免：

把工具名堆成能力，例如只写 OpenCode / Dify / Docker / RAG。
把 POC 包装成成熟生产平台。
把内部指标、客户、验收、路径、端口、部署细节放进公开材料。
用“显著提升”“大幅降低”“完全解决幻觉”等没有口径的结果表达。

1. 岗位方向与表达素材

A. AI / LLM 应用工程版

重点主线：SaaS Copilot + LLM Workflow + Python FastAPI Adapter + RAG / Prompt / Response Normalization + 页面上下文 + AI coding 工程化 + 预测服务化。

可复用表达：

主导零售 SaaS Copilot 早期测试阶段的架构设计与 Python / LLM 侧实现，设计业务页面上下文 → Python FastAPI Adapter → LLM Workflow 的调用链，将页面状态、表格快照和用户问题转化为可控的 LLM 输入。
设计 MP 页面 Copilot 数据契约，封装 page_context、grid_metadata、table_snapshot、page_summary、read_only_policy 等结构化字段，降低业务系统侧与 LLM Workflow 的耦合。
在 Python Adapter 中实现 Workflow 输入映射、table snapshot 处理、fallback 逻辑与响应归一化，输出 direct_answer、page_interpretation、next_steps、caveats、guardrails 等统一结构。
设计只读边界、业务知识库、标准问题集和 answer-quality checklist，支持 Copilot demo、回答质量评估与后续迭代。
设计内部知识库冷启动工作台，用 OpenCode Web + Git + AGENTS / skills / commands / permissions 将业务说明、会议纪要和指标解释整理为可 review 的 Markdown 知识源。
设计 review/pending -> approved / knowledge 的知识入库流程，结合 Git diff、validate 脚本和人工 review 控制知识质量，避免未确认公式和未审核草稿直接进入 RAG 知识库。
使用 Docker 将 OpenCode Web 限制在项目级 workspace，并引入 SFTPGo WebClient 提供 raw file 上传入口，拆分文件上传、知识整理和人工审核职责。
为 FastAPI 服务搭建轻量部署闭环，通过 Git bare repo、post-receive hook、lockfile、pytest、服务托管和 /health check 实现可重复、可验证、可追踪的 MVP 部署流程。
参与工程合同风险识别系统，负责前后端与 OCR 相关模块，结合 Prompt 适配与 RAG 检索，将合同审核从单次模型调用扩展为可操作、可复核的业务流程。
将 AI coding 纳入需求拆解、初版实现、TDD / 测试补充和文档维护流程，通过 Git diff、运行验证和 ARCHITECTURE / AGENTS / ADR / PLAN / logs 同步管理生成内容。
将新品预测的数据处理、建模评估和报告输出整理为可重复运行的服务化 pipeline，为上层业务系统调用提供稳定边界。

避免的表达：

AI Agent 自动操作业务系统。
大规模生产多租户 LLM 平台。
幻觉彻底解决。
明确降本增效或效率提升百分比。
SaaS Copilot 已正式产品化上线。

B. 数据科学 / 预测算法版

重点主线：零售新品预测 + 款色级建模数据集 + launch date / third sale date + 4W / 8W / 12W + 时间切分 / rolling validation / embargo / leakage control + observed sales vs demand + 指标污染。

可复用表达：

面向服饰零售新品预测场景，构建从订单、销售、商品主数据到款色级样本的数据 pipeline，统一 launch date / third sale date、4W / 8W / 12W 标签窗口、样本过滤与缺失处理口径。
设计按年份 / 波段 / 预测时点切分的训练验证流程，结合特征可用性检查、rolling validation 和 embargo 思路控制未来信息泄露风险。
针对新品冷启动、长尾分布、零膨胀和生命周期差异，将问题拆解为相似历史样本学习、总量预测、结构分配与误差归因，避免直接依赖细粒度 SKU 外推。
使用 GBDT / LightGBM 类 tabular 模型思路，将品类、波段、价格带、商品属性、生命周期和订单信息转化为可学习的相似样本特征。
引入商品图片向量化特征辅助相似品计算匹配，将视觉相似性纳入新品预测特征体系。
建立多口径预测评估框架，从 WAPE / Bias、MAE / RMSE、Spearman、Top-K、高潜商品识别和分组误差解释模型表现。
分析 observed sales 与 unconstrained demand 的差异，识别库存、铺货、到货、折扣、促销等缺失字段对预测标签和误差归因的影响。
识别线性脱敏字段在聚合、比值、占比、同比和误差指标中的污染机制，建立先还原、后聚合的校验原则，避免将脱敏偏移误判为业务异常。
在内部 POC 评估中优于业务 baseline，并通过 MAE / RMSE / Top-K 等指标补充验证整体误差与高潜商品识别能力。
输出业务解释报告，将“人工找相似款”转化为“模型在特征空间中学习相似历史样本”的可沟通框架。

避免的表达：

预测真实需求已经准确落地。
不带口径写“显著提升准确率”；公开表达中不使用精确 MAPE。
复杂深度学习时间序列模型，除非确实做过。
只罗列 WAPE / MAE / RMSE，不解释验证设计和业务口径。

C. 量化开发 / 数据建模初级版

重点主线：Python / SQL + 时间序列建模意识 + 统计基础 + 数据清洗与特征 pipeline + 严格训练验证切分 + 信息泄露控制 + 排序评估 / Spearman / Top-K + 模型误差归因 + 可复现分析。

可复用表达：

基于 Python / SQL 构建零售订单、销售和商品主数据处理 pipeline，将原始业务表整理为款色级建模样本，并保留关键时间锚点与标签窗口。
在预测任务中采用按时间切分的训练验证设计，明确 feature window、label window 和 forecast horizon，避免随机切分带来的未来信息泄露。
针对短生命周期和稀疏序列，分析单品级时间序列外推的不稳定性，采用跨商品样本学习和 tabular 特征建模思路提高可解释性。
使用 WAPE / Bias、Spearman 和 Top-K 等指标分别评估误差、系统性偏差、排序能力和高潜目标识别能力。
对模型误差进行业务归因，区分模型问题、样本稀疏、库存 / 铺货约束、折扣促销缺失和标签口径问题。
分析线性脱敏对 sum、ratio、同比、占比和误差指标的污染机制，建立行级还原后再聚合的可复现分析原则。
在 S&P Global / IHS Markit 实习中使用 Python 爬虫 / SQL Server 构建汽车市场与评论数据管道，维护 2000+ 款车型、10 万+ 条评论数据资产，支持市场分析报告。

避免的表达：

不写做过量化策略、因子研究、金融回测或交易系统。
不把零售预测包装成金融交易预测。
不写 Sharpe、Alpha、回撤等没有项目依据的指标。
可以强调“严谨的数据切分、泄露控制、特征工程、误差归因和可复现分析”，作为量化开发初级岗位的迁移能力。

2. 简历取舍

AI / LLM 应用工程简历主线

推荐优先级：

SaaS Copilot / LLM Workflow + FastAPI Adapter。
内部知识库冷启动 / RAG 知识治理工作台。
合同审核 LLM / OCR / RAG。
AI coding 工程化工作流。
预测服务化作为 ML + backend 结合点。
S&P 实习压缩为早期数据经历。

弱化：

五子棋、CV 课程项目、社团经历。
没有证据的 Flask / MongoDB / Celery 高并发表述。
过于泛泛的“熟悉工具”。
OpenCode / Docker / SFTPGo 等工具名本身，重点放在知识源治理、权限边界和人工 review。

数据科学 / 预测算法简历主线

推荐优先级：

零售新品预测。
时间切分、泄露控制、launch date / third sale date、4W / 8W / 12W。
线性脱敏指标污染。
S&P 数据分析实习。
SaaS Copilot 可压缩为工程化 / 服务化补充。

弱化：

LLM 工具链细节。
合同审核项目。
AI coding 工具清单。

量化开发 / 数据建模初级简历主线

推荐优先级：

Python / SQL 数据 pipeline。
时间序列预测意识和时间切分。
信息泄露控制。
Spearman / Top-K / 排序评估。
模型误差归因和可复现分析。

必须避免：

金融策略经历虚构。
交易系统、回测框架、因子研究等无证据表述。
过度强调业务 SaaS 或 LLM。

3. 服饰零售新品预测 / 需求预测 / 预测服务化

3.1 背景 / 业务问题

当前工作围绕零售 SaaS 与服饰行业数据智能场景展开，重点之一是面向鞋服零售场景的新品销售预测与业务评估。

业务场景的核心难点：

商品生命周期短，新品缺乏自身历史销量。
预测粒度偏细，主要关注款色级表现。
销售受订单、铺货、库存、到货、门店覆盖、断码断色、折扣、生命周期长度影响。
新品销售存在冷启动、长尾分布、零膨胀和历史可比样本不足问题。
业务方关注“预测准确率”，但实际可观测数据更接近 observed sales，而不一定能还原 unconstrained demand。

对外表达时，重点不是“训练了一个模型”，而是围绕“什么能被预测、预测目标如何定义、验证如何设计、结果边界如何解释”建立一套分析与建模流程。

3.2 负责范围

参与并推动新品预测 POC / 分析流程建设。
负责或深度参与数据口径梳理、建模数据集构建、baseline 设计、评估指标设计、业务解释、字段补充建议和服务化封装。
在业务沟通中解释当前数据能支持什么、不能支持什么，以及后续最小补充字段。

公开表述口径：

适合表述为“主导数据口径、建模验证、服务化和业务解释”，避免泛泛写“主导项目”。
已形成可被上层业务系统调用的服务化成果；本文不展开客户、验收和内部上线口径。
预测链路中包含商品图片向量化，将视觉相似性作为相似品匹配和新品预测的补充信息。
有内部评估结果支撑模型改进；本文不列精确指标。

3.3 输入数据 / 系统上下文

已整理的信息：

历史订单数据。
历史销售数据。
商品主数据。
年季 / 波段 / 品类 / 商品属性等字段。
商品图片向量化特征，用于相似品计算匹配。
数据覆盖跨年份订单与销售记录；本文不展开具体客户数据周期。
建模粒度主要为款色级。
关键时间锚点包括 launch date 和 third sale date，其中 launch date 是主口径，third sale date 可作为对照口径。
标签包括 4W / 8W / 12W 累计销量与累计销售额。

当前证据不足、后续可补充的字段：

铺货门店数、有库存门店数、库存量、到货时间、断货 / 缺码状态。
折扣、促销、曝光、陈列、渠道和重点款标记。
相似款关系、上市计划、追单计划、生命周期结束标记。

3.4 核心工作

构建从原始订单、销售、商品主数据到款色级建模样本的数据 pipeline。
统一 launch date、third sale date、预测窗口、标签窗口、样本过滤、缺失处理和异常样本处理口径。
设计订单基线、分组统计基线和机器学习模型的统一评估流程。
引入图片向量化特征辅助相似品计算匹配，将视觉相似性纳入新品预测特征体系。
将模型评估拆成整体误差、系统性偏差、排序能力、高潜商品识别、分组稳定性和业务解释，而不是只看单一“准确率”。
针对新品冷启动、长尾和稀疏问题，设计“相似历史样本学习 / 聚合预测 / 结构分配”的思路，避免直接在极细 SKU 粒度上做不稳定预测。
分析 observed sales 与 unconstrained demand 的差异，避免把库存、铺货、到货或生命周期约束误判为模型误差。
输出内部分析报告和业务沟通材料，说明 baseline 表现、数据边界、当前结果解释和后续字段补充方向。

3.5 技术细节

建模设计

使用 tabular ML / GBDT / LightGBM 类模型的思路处理新品预测，核心是让模型从历史商品、时间、门店和运营特征中隐式学习相似样本。
不把“相似款”理解为人工指定某一个商品，而是转化为：商品属性、时间属性、价格带、品类、波段、生命周期等特征空间中的相似样本集合。
对商品图片做向量化表示，将视觉相似性作为相似品匹配和新品预测的补充信息。
对新品、短生命周期商品和大量 0 序列，避免直接套用单品级长历史时间序列外推。

时间切分与泄露控制

训练 / 验证应按年份、波段或预测时点切分，避免随机切分导致未来信息泄露。
明确区分 feature window、label window 和 forecast horizon。
预测时点之后才发生的销售、库存、折扣、追单、生命周期长度等信息不能作为训练特征。
样本时间相邻、同款或相似款可能互相泄露时，可引入 embargo 思路，在训练集与验证集之间保留时间隔离。

评估设计

可用指标包括 WAPE、Bias、MAE、RMSE、Spearman、Top-K 命中和分组误差。
WAPE / MAE / RMSE 解释整体误差。
Bias 解释系统性高估或低估。
Spearman / Top-K 更适合解释排序能力和高潜商品识别。
对服饰新品预测，排序能力有时比精确数值更接近业务使用方式，例如识别高潜款、低潜款或需要重点关注的款色。

数据脱敏与指标污染

分析中遇到的部分订单和销售字段存在统一线性变换：

X_masked = A * X_true + B

单行数据可以通过反向变换还原，但聚合分析不能直接对脱敏字段求和或计算比值。原因是常数项 B 会随行数累计，污染 sum、ratio、同比、订单 / 销售比、金额占比、销量占比、均价、WAPE、Bias 等指标。

对应处理原则：

先在行级或原始粒度完成口径还原，再聚合。
对订单行和销售行进行一致性检查。
避免把脱敏导致的聚合偏移误解释为业务异常或模型问题。

工程化 / 服务化

将建模、评估与报告流程封装为可重复运行的后端服务或分析 pipeline。
工程实现涉及 Web 服务、异步任务、缓存 / 持久化组件和批量实验流程。
对外表达时，优先写“可重复 pipeline、任务状态、结果持久化、报告输出、业务系统调用接口”，工具名放在次要位置。

公开表述口径：

预测服务已被上层业务系统调用。
本文不展开具体生产框架、部署环境和系统调用细节。

3.6 主要难点

业务目标不是天然清晰：销量、需求、销售额、订单量和潜力排序分别对应不同问题。
observed sales 受到供给和运营约束，不能直接等同于真实需求。
新品缺历史、生命周期短、样本稀疏，单品级时间序列不稳定。
服饰数据字段口径复杂，launch date、third sale date、波段、年季和标签窗口需要统一。
随机切分会制造虚高指标，必须使用更接近真实预测场景的时间验证。
线性脱敏字段会污染聚合和误差指标，必须先还原再分析。

3.7 结果 / 产出

已形成的材料：

形成新品预测 POC / 分析流程材料。
形成款色级建模数据集构建方案。
形成 launch date / third sale date、4W / 8W / 12W 标签窗口等核心口径。
形成多指标评估框架。
形成线性脱敏字段的聚合污染分析和处理原则。
输出类似“机器学习如何自动学习相似样本 / 相似款”的业务解释报告。
形成可被上层业务系统调用的预测服务化成果。
内部 POC 评估显示模型表现优于业务 baseline；本文不列精确指标。

避免直接写：

不带 POC 评估口径写“显著提升预测准确率”。
本文不写具体客户、验收状态、上线范围和精确指标。
服务稳定性 99.9%。
推理时间从秒级到毫秒级。
已产生明确业务收益或财务收益，除非后续有业务统计口径。

除非后续补充明确证据。

3.8 可量化信息

可使用但需限定口径：

数据年份：订单数据覆盖 2023 / 2024 / 2025，销售数据覆盖 2023 / 2024。
标签窗口：4W / 8W / 12W。
粒度：款色级。
数据规模：内部数据量级较大，本文不列具体规模。
模型效果：内部 POC 评估优于业务 baseline，本文不列具体数值。
baseline：业务特征 + 分桶线性。
评估指标：MAPE、MAE、RMSE、Top-K。
交付状态：已形成业务系统可调用的服务化成果，本文不展开验收口径。

后续补充：

款色数、订单行数、销售行数。
Top-K 命中率或排序相关性的具体数值。
业务使用范围、POC 周期和投递版本可使用的指标口径。

3.9 可复用的简历表达

偏数据科学 / 预测算法：

面向服饰零售新品预测场景，构建从订单、销售、商品主数据到款色级样本的数据 pipeline，统一 launch date / third sale date、4W / 8W / 12W 标签窗口、样本过滤与缺失处理口径。
设计按年份 / 波段 / 预测时点切分的训练验证流程，结合特征可用性检查与 embargo 思路控制未来信息泄露风险。
针对新品冷启动、长尾分布和生命周期差异，将问题拆解为相似历史样本学习、总量预测、结构分配与误差归因，避免直接依赖细粒度 SKU 外推。
建立多口径预测评估框架，从 WAPE / Bias、Spearman、Top-K、高潜商品识别和分组误差解释模型表现。
分析 observed sales 与 unconstrained demand 的差异，识别库存、铺货、到货、折扣等缺失字段对预测标签和误差归因的影响。
识别线性脱敏字段在聚合、比值、占比、同比和误差指标中的污染机制，建立先还原、后聚合的校验原则。
在内部 POC 评估中优于业务 baseline，并通过 MAE / RMSE / Top-K 等指标补充验证整体误差与高潜商品识别能力。

偏工程化：

将新品预测的数据处理、建模评估和报告输出整理为可重复运行的 pipeline，支持批量实验、结果持久化和业务系统集成。
封装预测服务，围绕异步任务、任务状态、结果缓存和上层系统调用边界，将 notebook 分析沉淀为可复用服务模块。

3.10 可展开的面试问题

新品预测为什么不能随机切分？
launch date 和 third sale date 的差异是什么？
4W / 8W / 12W 标签分别解决什么业务问题？
observed sales 和 unconstrained demand 有什么差异？
哪些字段会造成未来信息泄露？
为什么单品级时间序列对服饰新品不稳定？
LightGBM / GBDT 如何隐式学习相似样本？
WAPE、Bias、Spearman、Top-K 分别解释什么？
线性脱敏为什么会污染聚合指标？
如果业务方只看准确率，如何解释模型边界？

3.11 避免夸大的内容

本文不写精确 MAPE；投递版本如需使用指标，必须限定为 POC 评估口径。
不写“准确预测真实需求”，当前更准确的说法是预测 observed sales，并识别其与 demand 的差异。
不写“完整需求预测系统上线并产生收益”，除非确认上线范围和收益口径。
不写“支持百万级高并发”或类似后端性能指标。
不把 WAPE / MAE / RMSE 罗列成成果，指标只是评估工具。

4. 零售 SaaS Copilot / LLM 应用工程 / Workflow + FastAPI Adapter

4.1 背景 / 业务问题

项目目标是在零售 SaaS 系统中引入 AI Copilot，使 AI 能够理解当前业务页面、表格数据、指标含义和用户问题，并给出只读、可解释、低风险的业务辅助回答。

项目重点不是单纯聊天机器人，而是页面上下文驱动的业务 Copilot：

业务系统侧采集或组织当前页面上下文。
Python Adapter 负责结构化上下文映射、LLM Workflow 输入构造、响应归一化和权限边界。
LLM Workflow 负责模型编排、知识库检索和回答生成。

早期 demo 涉及首页 co-planner、MP 页面等场景。MP 页面更适合承载业务演示和产品化探索。

4.2 负责范围

主导早期测试阶段的架构设计与 Python / LLM 侧实现。
负责 Python Adapter 开发，参与 LLM Workflow 对接、业务系统调用契约定义、上下文结构设计、统一响应格式、评测材料和业务 demo 支撑。

已确认：

适合表述为“主导”，但限定为架构设计和 Python / LLM 侧实现。
项目处于早期测试阶段，尚未进入正式产品环境。
当前没有公开口径下的真实用户使用数据或业务验收结果。

4.3 输入数据 / 系统上下文

典型调用链：

Business Page Context
  -> Python FastAPI Adapter
  -> LLM Workflow / RAG
  -> Normalized Copilot Response

MP Copilot 请求结构：

query
user
schema_version
page_context
grid_metadata
table_snapshot
page_summary
read_only_policy

LLM Workflow 侧输入：

page_context
grid_metadata
table_meta
table_csv
page_summary
read_only_policy

统一响应结构：

direct_answer
page_interpretation
next_steps
caveats
matched_knowledge
answer_type
guardrails

4.4 核心工作

设计业务系统到 Python 的 MP 页面 Copilot 数据契约，使业务系统侧只需传结构化 JSON，不需要关心 LLM Workflow 内部输入格式。
在 Python Adapter 内完成 LLM Workflow 输入序列化、table snapshot 处理、fallback 逻辑和响应归一化。
设计 page_context、grid_metadata、table_snapshot、page_summary、read_only_policy 等结构化输入字段。
保持只读策略，避免 AI 直接执行高风险写操作。
设计业务知识库、评测问题集、页面上下文样例和 answer-quality checklist，用于支持 demo、标注和后续迭代。
与业务系统 / 前端侧沟通集成方式，包括独立 web chat window / side panel、请求由业务系统提交、页面信息组织后传给 Python。
部署 FastAPI + uvicorn + systemd，提供 health / readyz / demo-ui 等辅助接口。

4.5 技术细节

Adapter 边界

Python Adapter 的价值不只是“转发请求”：

屏蔽 LLM Workflow 的输入格式变化。
将页面上下文、表格快照和只读策略转成 LLM 可消费的结构。
对模型输出做 response normalization，避免前端处理不稳定自由文本。
在 SaaS 系统与 LLM Workflow 之间建立权限、格式和错误处理边界。

上下文设计

page_context 描述用户所在页面、业务模块和操作场景。
grid_metadata 描述表格字段、字段含义、排序、筛选和页面状态。
table_snapshot 提供当前页面可见数据或截取数据，避免模型凭空解释。
page_summary 提供页面摘要，降低上下文噪声。
read_only_policy 明确 Copilot 只能解释、建议和引用，不直接写回业务系统。

响应归一化

统一响应可分为：

direct_answer：直接回答。
page_interpretation：对当前页面和数据的解释。
next_steps：可执行但不自动执行的建议。
caveats：限制条件和不确定性。
matched_knowledge：引用的知识库内容或规则。
guardrails：只读、安全和边界提示。

部署和工程闭环

来自工程笔记的可证据化材料：

Python 3.12、FastAPI、uv、pytest、systemd。
Git bare repo + post-receive hook + lockfile 依赖同步 + pytest + 服务重启 + health check。
部署流程包含依赖同步、导入检查、语法检查、测试、服务重启和健康检查。
这套流程适合 MVP / demo 阶段的小型 Python 服务，重点是可重复、可验证、可追踪。

4.6 主要难点

LLM 不能直接理解业务页面，必须把页面状态、表格字段、筛选条件和用户问题结构化。
业务系统侧、Python Adapter 和 LLM Workflow 的职责边界需要清楚，否则系统会强耦合。
Copilot 早期必须低风险，不能让模型直接执行写操作。
表格快照不能无限传，需要在信息量、上下文长度和隐私边界之间取舍。
LLM 输出天然不稳定，必须通过响应归一化和质量清单降低前端集成成本。

4.7 结果 / 产出

已形成的材料：

形成 MP Copilot 数据契约与调用链设计。
实现或设计 Python FastAPI Adapter 对接 LLM Workflow。
形成页面上下文、表格快照、只读策略和归一化响应结构。
搭建 MVP 服务的轻量 CI/CD 闭环。
支持早期测试 / demo 阶段迭代。

避免直接写：

正式大规模上线。
已进入正式产品环境。
多租户生产平台级能力。
99.9% availability。
明确节省人工成本或提升转化率。

4.8 可量化信息

适合保留：

部署流程包含依赖同步、import check、compileall、pytest、服务重启和 /health check。
服务环境：Python 3.12、FastAPI、uv、pytest、systemd。

当前不建议量化：

Copilot 接口数量、demo 页面数量、知识库文档数量：早期阶段，不好衡量。
Workflow 节点数量：暂不作为简历指标。
实际用户、调用量、响应质量评测结果：当前未整理公开口径。

4.9 可复用的简历表达

主导零售 SaaS Copilot 早期测试阶段的架构设计与 Python / LLM 侧实现，设计业务页面上下文 → Python FastAPI Adapter → LLM Workflow 的调用链，将页面状态、表格快照和用户问题转化为可控的 LLM 输入。
设计 MP 页面 Copilot 数据契约，封装 page_context、grid_metadata、table_snapshot、page_summary、read_only_policy 等结构化字段，降低业务系统侧与 LLM Workflow 的耦合。
在 Python Adapter 中实现 Workflow 输入映射、table snapshot 处理、fallback 逻辑与响应归一化，输出 direct_answer、page_interpretation、next_steps、caveats、guardrails 等统一结构。
设计只读边界、业务知识库、标准问题集和 answer-quality checklist，支持 Copilot demo、回答质量评估与后续迭代。
为 FastAPI 服务搭建轻量部署闭环，通过 Git bare repo、post-receive hook、lockfile、pytest、服务托管和 /health check 实现可重复、可验证、可追踪的 MVP 部署流程。

4.10 可展开的面试问题

为什么不让业务系统直接调用 LLM Workflow？
Python Adapter 具体承担哪些职责？
LLM Workflow 在系统里承担什么，不承担什么？
页面上下文和 table snapshot 如何组织？
read_only_policy 如何防止高风险操作？
response normalization 解决什么问题？
Copilot 回答质量如何评估？
如果表格很大，table snapshot 怎么取舍？
轻量 CI/CD 为什么适合 MVP 阶段？

4.11 避免夸大的内容

不把 LLM Workflow 写成完整 SaaS 平台。
不写“自主 Agent 自动操作业务系统”，当前更适合写“只读 Copilot / 业务辅助解释”。
不写生产级 SLA。
不写“解决幻觉问题”，更稳妥是“通过 RAG、上下文约束、响应归一化和质量清单降低风险”。

5. 内部知识库冷启动 / OpenCode 工作台 / RAG 知识治理

5.1 背景 / 业务问题

SaaS Copilot 和 RAG 应用要真正可用，前提不是“直接接一个向量库”，而是先有稳定、可审核、可维护的知识源。内部知识通常分散在业务说明、会议纪要、页面截图、指标解释和个人经验里，如果直接导入向量库，容易出现口径不统一、缺少来源、公式不确定、无人 review 和后续难维护的问题。

一开始可以做完整的协同文档系统、审核流和 RAG 后台，但开发周期较长，也不适合知识库冷启动阶段。因此更合理的第一步是搭建轻量的 agent-assisted authoring workspace：让业务同事低成本地产出结构化 Markdown 草稿，再通过 Git / review / validation 进入正式知识库，后续再导入 LLM Workflow、向量库或 SaaS Copilot。

5.2 负责范围

设计内部知识库冷启动方案，将 OpenCode Web 定位为“知识库草稿整理工作台”，而不是正式知识库门户。
设计知识源 Git repo 结构、草稿 / 审核 / 正式知识文档流转路径和后续 RAG 接入边界。
编写 AGENTS.md、skills、commands、permissions 和 validate 脚本，约束 agent 的写作格式、可执行动作、目录边界和安全边界。
设计 Docker + SFTPGo 升级方案，为业务同事提供文件上传入口，并将 agent 限制在项目级 workspace 内。

5.3 输入数据 / 系统上下文

输入材料：

业务说明。
会议纪要。
页面截图说明。
指标解释。
SOP / 操作流程。
上传的原始文件，如 Markdown、文本、CSV 或可结构化处理的资料。

知识库工作区结构：

inbox/：原始材料入口。
inbox/uploaded-docs/：通过 WebClient 上传的 raw files。
review/pending/：agent 生成的草稿。
review/approved/ 或 knowledge/：人工审核后的知识源。
scripts/validate_kb.py：知识文档校验。
.opencode/skills/：指标定义、FAQ、知识质量审查等重复任务的规则。
.opencode/commands/：/kb-start 等同事可触发的入口。

5.4 核心工作

设计 OpenCode Web + Git repo + AGENTS.md + skills + commands + permissions 的知识库草稿生产流程。
将业务同事粘贴或上传的原始材料整理为结构化 Markdown 草稿，并统一进入 review/pending/。
设计人工 review 流程，避免 agent 直接把草稿放入 approved 或正式知识目录。
通过 AGENTS.md 约束 agent 不补未知公式、不删除文件、不执行危险命令、不暴露密钥、不修改系统配置。
通过 skills 固化常见知识整理任务，例如指标定义、FAQ、知识质量审查。
通过 /kb-start 降低业务同事第一次使用门槛，明确工作台用途、可创建文档类型、草稿位置和禁止事项。
编写 validate_kb.py 校验 frontmatter、doc_type、status、module、title、owner、updated_at、open_questions 等字段。
用 Docker 将 OpenCode Web 限制在项目级 workspace，避免裸跑在宿主机上导致 agent 权限范围过大。
用 SFTPGo WebClient 提供 raw file 上传入口，将文件落到 inbox/uploaded-docs/，再由 OpenCode 读取和整理。

5.5 技术细节

第一版工作流

业务同事通过浏览器访问 OpenCode Web
  -> 粘贴业务说明 / 会议纪要 / 页面截图 / 指标解释
  -> OpenCode 按 AGENTS.md / skills 整理成 Markdown 草稿
  -> 草稿进入 review/pending/
  -> 人工 review
  -> knowledge/ 或 review/approved/
  -> 后续导入 LLM Workflow / 向量库 / SaaS Copilot

Docker + SFTPGo 升级后

SFTPGo WebClient
  -> 上传 raw files
  -> inbox/uploaded-docs/
  -> OpenCode Web 读取 uploaded-docs
  -> 生成 review/pending/*.md
  -> validate_kb.py + Git diff + 人工 review

权限与治理设计

OpenCode Web 不作为最终知识库门户，只作为 authoring workspace。
Git repo 作为知识资产主账本，所有草稿和知识源文件都可 diff、review 和 commit。
review/pending/ 和 knowledge/ 分离，避免未审核内容直接进入知识库。
permissions 允许查看 git diff、运行 validate_kb.py、写入草稿目录；限制删除、系统命令、外部下载和敏感文件访问。
Docker 解决项目级隔离问题，SFTPGo 解决 raw file upload 问题，AGENTS / skills / commands 解决工作流约束，Git review 解决知识治理问题。

5.6 主要难点

知识库冷启动阶段最难的不是向量检索，而是知识源生产、格式统一、人工审核和口径不确定性的管理。
通用 agent 如果不设边界，容易补全未知公式、直接移动文件、访问过宽目录或把草稿误当正式知识。
OpenCode Web 本身不是文件上传系统，需要单独设计 raw files 入口。
如果 OpenCode Web 裸跑在宿主机上，权限范围接近运行它的 Linux 用户，不适合作为多人使用的知识库工作台。
知识整理工作需要让业务同事能用，但又不能把 prompt 编写和目录规则全部交给业务同事记忆。

5.7 结果 / 产出

已形成的材料：

形成内部知识库冷启动 POC 方案。
形成 OpenCode Web + Git + AGENTS / skills / commands / permissions 的知识生产工作流。
形成 review/pending -> review/approved / knowledge 的人工审核链路。
形成 validate_kb.py 校验脚本，用于检查知识文档结构和状态。
形成 Docker + SFTPGo 的升级方案，将文件上传和 agent authoring 拆分，并限制 agent 工作范围。
形成可衔接 LLM Workflow、向量库和 SaaS Copilot 的知识源治理思路。

本文不展开：

内部服务器路径、端口、账号、服务名和真实部署配置。
具体业务模块、真实知识文档内容和内部数据。
是否已经正式作为企业知识库平台上线。

5.8 可量化信息

本文不使用精确量化指标。

适合保留：

支持 FAQ、指标定义、SOP、业务说明等多类知识草稿。
通过 Git diff、validate 脚本和人工 review 管理知识入库。
支持 raw file upload 与 agent authoring 两个入口的职责拆分。

后续补充：

业务同事实际使用人数。
已整理知识文档数量。
后续是否已导入 LLM Workflow / 向量库。
是否形成固定维护节奏或知识库发布流程。

5.9 可复用的简历表达

设计内部知识库冷启动工作台，用 OpenCode Web + Git + AGENTS / skills / commands / permissions 将分散的业务说明、会议纪要和指标解释整理为可 review 的 Markdown 知识源。
设计 review/pending -> approved / knowledge 的知识入库流程，结合 Git diff、validate 脚本和人工 review 控制知识质量，避免未确认公式和未审核草稿直接进入 RAG 知识库。
编写 AGENTS.md、任务 skills 和 /kb-start onboarding command，约束 agent 的文档格式、目录边界、安全动作和不确定性标注，降低业务同事使用门槛。
使用 Docker 将 OpenCode Web 限制在项目级 workspace，并引入 SFTPGo WebClient 提供 raw file 上传入口，拆分文件上传、知识整理和人工审核职责。
将知识库工作台定位为 RAG / SaaS Copilot 的上游知识源治理 pipeline，而不是直接把原始文档导入向量库。

5.10 可展开的面试问题

为什么不直接做完整企业知识库系统？
为什么 OpenCode Web 只能作为 authoring workspace，而不是正式知识库门户？
AGENTS.md、skills、commands、permissions 分别解决什么问题？
为什么需要 review/pending 和 approved / knowledge 分离？
validate_kb.py 校验哪些字段？为什么这些字段对 RAG 重要？
为什么要用 Docker 隔离 OpenCode Web？
SFTPGo 在架构里只负责什么，不负责什么？
这套方案如何衔接后续向量库、LLM Workflow 和 SaaS Copilot？

5.11 避免夸大的内容

不写“完整企业知识库平台”。
不写“自动 RAG 全流程已上线”。
不写“替代人工知识整理”。
不写“彻底解决知识幻觉”。
不公开服务器路径、端口、账号、真实知识文档和内部业务模块。
工具名放次要位置，重点写知识源治理、权限边界、人工 review 和后续 RAG 接入。

6. AI Coding 工程化工作流

6.1 背景 / 业务问题

近期在个人项目、内部原型和数据分析工作中持续使用 Codex、VS Code、CLI 等 AI coding 工具辅助开发。重点不是“让 AI 替代开发”，而是把 AI coding 纳入可审查、可测试、可追踪的工程流程。

6.2 负责范围

在个人和工作原型中主动设计 AI-assisted engineering 流程。
使用 AI 工具辅助需求拆解、代码初稿、测试补充、文档维护和代码审查。
人工负责需求判断、架构边界、diff review、运行验证和最终取舍。

6.3 输入数据 / 系统上下文

6.4 核心工作

将需求拆成可执行任务，并让 AI 生成初版实现或修改建议。
使用 Git diff 审查 AI 生成内容。
通过单元测试、运行验证、health check 或人工样例检查确认改动。
同步维护 README、ADR、NEXT_ACTIONS、接口文档和数据契约，避免代码与文档脱节。
将 AI coding 用在小步迭代、测试补充和文档维护中，而不是让 AI 一次性生成不可控大改动。

6.5 技术细节

Codex / VS Code / CLI 辅助开发。
Git diff review。
pytest / 运行验证。
README / ADR / NEXT_ACTIONS 作为上下文和决策记录。
小步提交和可回滚改动。

6.6 主要难点

AI 生成内容可能误解业务上下文。
AI 可能改动范围过大或引入隐藏行为变化。
文档和代码容易不同步。
需要把 AI 输出纳入工程质量流程，而不是直接信任。

6.7 结果 / 产出

已形成的材料：

在 SaaS Copilot、数据分析、个人项目和文档维护中形成 AI-assisted workflow。
有 GitFlow、uv、轻量 CI/CD、编码实践等工程笔记支撑。
采用小步迭代方式推进 AI coding，降低单次大改动风险。
正在沉淀团队 / 项目层面的 AI-assisted engineering 规范，由本人主导推进。
实践中结合 TDD 思路，让 AI coding 输出进入测试驱动或测试补充流程。
维护 ARCHITECTURE、AGENTS、ADR、PLAN、logs 等工程文档，使 AI 生成内容有上下文和追踪记录。

后续补充：

是否有具体 PR / commit 数量、测试数量或文档数量可引用。

6.8 可量化信息

可使用但需限定口径：

采用 TDD / 测试补充方式约束 AI coding 输出。
文档体系包括 ARCHITECTURE、AGENTS、多个 ADR、PLAN、logs 等。
在部分迭代中，周期从约 3 周压缩到约 1 周。只有能解释统计口径时再用于投递版本。

后续补充：

AI coding 辅助完成的模块数量。
可公开的测试数量、文档数量和迭代周期统计口径。

6.9 可复用的简历表达

在 SaaS Copilot 原型、数据分析脚本与个人项目开发中，将 Codex / VS Code / CLI 纳入需求拆解、初版实现、测试补充和文档维护流程。
通过 Git diff 审查、单元测试、运行验证与 README / ADR / NEXT_ACTIONS 同步管理 AI 生成内容，形成可追踪、可验证的 AI-assisted engineering 工作流。
将 AI coding 主要用于小步重构、接口文档维护、测试样例补充和开发计划拆解，避免不可控的大范围自动生成。
主导沉淀 ARCHITECTURE、AGENTS、ADR、PLAN、logs 等工程文档，将 AI coding 从工具使用收敛为小步迭代、TDD 验证和文档同步的工程流程。

6.10 可展开的面试问题

AI coding 在项目中具体承担了哪些环节？
如何判断 AI 生成代码是否可靠？
如何防止 AI 改动范围失控？
ADR / AGENTS / NEXT_ACTIONS 各自解决什么问题？
有没有遇到 AI 生成错误代码？如何处理？

6.11 避免夸大的内容

不写“AI 自动完成大量开发”。
不写“显著提升效率”；“3 周 → 1 周”仅在能说明迭代范围和统计口径时使用。
不把工具清单当成果。
不把正在沉淀的流程写成成熟公司级制度。

7. 工程合同智能审核系统 / 创业项目

7.1 背景 / 业务问题

毕业前后参与朋友创业项目，方向是工程项目 / OA / 光伏搭建相关合同审核系统。项目希望通过大模型、OCR、文档解析和流程系统，帮助业务方识别合同风险、进行审批流转和风险提示。

7.2 负责范围

负责或深度参与前后端开发、OCR 部分、合同上传、审批流程、风险展示和文档结构化处理。
参与 LLM Prompt、RAG、图像处理等相关模块的系统集成，但不涉及 LLM 模型后训练。

已确认：

项目已交付使用。
使用通用大模型能力完成风险解释与条款理解；本文不展开具体供应商。

7.3 输入数据 / 系统上下文

合同 PDF / 图片 / 扫描件。
OCR 输出文本与坐标。
合同段落、表格、条款和印章 / 手写区域。
法规、条款库或业务规则知识库。
OA / 审批流系统上下文。

7.4 核心工作

参与设计基于 LLM 的合同风险识别系统。
构建或参与 OCR、文档解析与结构化抽取流程。
结合 Prompt 适配与 RAG 检索降低合同审核中的幻觉风险。
实现合同上传、审批流转、风险提示与结果展示等核心功能。
参与产品需求拆解、原型设计和 SaaS 功能实现。
通过文档下载、文档位置定位和图片截取，让风险提示可以被人工复核。

7.5 技术细节

面试复盘中的架构信息：

PDF / 图片输入
  -> OCR 层：图像 -> 文本 + 坐标
  -> 结构化解析层：段落 / 表格 / 条款识别
  -> LLM 风险识别层：语义分析
  -> RAG 法规增强层：知识校验
  -> 风险展示 / 审批流

可解释的技术点：

OCR 负责把非结构化图片 / PDF 转成文本和位置。
结构化解析负责识别条款、表格和合同段落。
RAG 用于引用法规、模板条款或业务规则，减少模型凭空判断。
LLM 负责风险归纳、条款解释和提示生成。

7.6 主要难点

合同 PDF / 扫描件质量不稳定，OCR 容易受版式、印章、手写、表格影响。
文档格式复杂，OCR 与结构化解析需要处理不同合同版式、表格和图章区域。
合同风险判断不能只依赖单次 LLM 输出，需要结合规则、知识库和人工可审查结果。
法律 / 合同场景对幻觉敏感，需要输出依据、风险等级和不确定性。
文档结构化与业务流程系统需要结合，不能停留在单次问答。

7.7 结果 / 产出

已形成的材料：

参与工程合同智能审核系统。
覆盖合同上传、审批流转、风险提示和结果展示。
有 OCR、文档解析、LLM、RAG 架构记录。
项目已交付使用；本文不展开客户信息。
基于项目评测数据完成效果验证；本文不列精确准确率，避免被理解为通用法律判断能力。

7.8 可量化信息

可使用但需限定口径：

交付情况：已交付使用；本文不展开业务使用范围。
风险识别：有项目评测口径；本文不列精确准确率。
合同样本量：有一定规模样本支撑；本文不列具体数量。

后续补充：

OCR 准确率。
风险类型数量。
审批流程节点数量。
项目周期。

7.9 可复用的简历表达

参与设计基于 LLM 的工程合同风险识别系统，覆盖合同上传、审批流转、风险提示与结果展示等核心流程。
构建 OCR、文档解析与结构化抽取流程，将合同 PDF / 扫描件转化为可供 LLM 与规则系统消费的文本、段落和条款结构。
结合 Prompt 适配与 RAG 检索为合同风险识别提供法规 / 条款依据，降低单次大模型自由生成带来的幻觉风险。
参与前后端功能实现与产品原型迭代，将合同审核从单次模型调用扩展为可操作的业务流程系统。
在合同审核系统中实现风险结果展示、原文位置定位和图片截取等可复核能力，支持人工审核人员追溯模型判断依据。

7.10 可展开的面试问题

合同审核为什么需要 RAG？合同格式不统一，法律条文和审核依据必须尽量减少模型幻觉。
OCR / 文档解析中最难的问题是什么？合同格式复杂，表格、图章、扫描质量和手写区域会影响结构化结果。
印章识别、手写识别和表格解析如何影响结果？单独展示和定位，不对难以识别的区域过度猜测。
如何降低合同场景中的模型幻觉？通过 RAG 提供法规 / 条款依据，并把回答限定在可检索材料和合同原文范围内。
风险提示如何让人工可审查？提供文档下载、文档位置定位和图片截取。
这个项目和 SaaS Copilot 的架构共性是什么？

7.11 避免夸大的内容

不写“替代人工法务审核”。
本文不写精确风险识别准确率；投递版本如需使用，必须限定为项目评测口径。
本文不写具体业务使用范围。
不把具体大模型供应商、OCR、RAG 堆成工具清单，要写清楚文档结构化和业务流程。

8. S&P Global / IHS Markit 汽车部门实习

8.1 背景 / 业务问题

在 S&P Global / IHS Markit 汽车部门担任数据分析实习生，支持市场分析师进行车型竞争力分析、汽车市场数据整理和用户评论分析。

8.2 负责范围

数据分析实习生。
支持汽车市场数据采集、清洗、数据库维护、评论情感分析和季度报告数据需求。

8.3 输入数据 / 系统上下文

汽车车型参数、价格、配置等网络数据。
社交媒体及购物网站用户评论。
SQL Server 数据库。
市场分析师的季度报告需求。

8.4 核心工作

编写网页爬虫，自动化收集数百个网页 / 数据源中的汽车市场数据，建立可持续更新的数据管道。
编写 OCR 脚本，辅助处理图片 / 扫描类资料中的车型参数、价格或配置等信息；具体效果指标未保留，不使用准确率表述。
建立 SQL Server 数据库，规范化存储车型参数、价格和评论数据。
针对社交媒体及购物网站评论搭建 LSTM 情感分析模型。
支持季度市场报告的数据分析需求。

8.5 技术细节

LSTM 情感分析流程：

文本清洗：去除 HTML、特殊字符、停用词。
分词和词汇表构建。
文本序列化：词转索引。
padding / truncation 到固定长度，并用 mask 避免 padding 影响 loss。
embedding 层使用预训练词向量，原记录为知乎预训练权重。
模型结构：输入 → embedding → LSTM → Dropout → 全连接 → sigmoid 二分类。
常见训练设置：Adam、学习率约 1e-3、batch size 32-64、early stopping / dropout / L2 正则。
类别不平衡可用重采样处理。

8.6 主要难点

网络数据来源结构不统一，需要清洗和规范化。
评论文本噪声大，涉及分词、长度截断、类别不平衡和情绪标签质量。
实习工作需要把脚本结果转化为分析师可用的数据资产和报告材料。

8.7 结果 / 产出

现有记录中有以下量化结果：

建立覆盖 2000+ 款车型、10 万+ 条用户评论的数据库。
通过网页爬虫覆盖数百个网页 / 数据源。
数据管道稳定运行 6 个月。
支持 3 份季度市场报告的数据需求。

2000+ 车型、10 万+ 评论、6 个月和 3 份报告来自早期记录；使用前仍需回到原始记录确认。

8.8 可量化信息

2000+ 款车型。
10 万+ 条用户评论。
数百个网页 / 数据源。
6 个月数据管道运行期。
3 份季度市场报告。

后续补充：

情感分析模型评估指标：原始评估记录缺失；不使用准确率 / F1 / AUC。
OCR 脚本的具体效果：原始评估记录缺失；只保留“辅助抽取图片 / 扫描资料中的结构化信息”。

8.9 可复用的简历表达

在 S&P Global / IHS Markit 汽车部门实习期间，编写网页爬虫构建汽车车型与用户评论数据管道，清洗并维护 SQL Server 数据库，支持车型竞争力分析和季度市场报告。
维护覆盖 2000+ 款车型、10 万+ 条评论的数据资产，规范化存储车型参数、价格和评论信息，支持市场分析师复用。
基于 LSTM 搭建评论情感分析模型，完成文本清洗、分词、序列化、padding、预训练 embedding 和二分类输出流程，为车型口碑分析提供支撑信息。

8.10 可展开的面试问题

数据管道如何采集和更新？
SQL Server 表结构如何设计？
OCR 脚本用于什么数据？
评论数据如何清洗和标注？
LSTM 情感分析模型的输入输出是什么？
类别不平衡怎么处理？
如何支持季度市场报告？

8.11 避免夸大的内容

不写模型准确率 / F1 / AUC，除非找到评估记录。
不写 OCR 准确率或抽取效果百分比，除非找到记录。
不写“独立负责整个报告”，更稳妥是“支持市场分析师的数据需求”。
不写生产级数据平台。

9. 个人项目：Demon Hex / Godot 拼图游戏

9.1 背景 / 业务问题

个人开发 Godot 4 / GDScript 六边形地下城拼图游戏，主题为魔王扩张地下城。玩法参考 Dorfromantik 的地貌拼接与休闲拼图体验，结合轻度入侵者、资源、迷宫扩张和事件系统。

该项目不建议作为 AI / 数据主线简历的核心经历，但可作为 GitHub / Blog 展示项目，体现个人工程兴趣、系统拆解、数据驱动配置和 AI coding workflow。

9.2 负责范围

个人项目独立开发者。
负责玩法设计、系统拆解、GDScript 实现、配置设计和文档维护。

9.3 输入数据 / 系统上下文

Godot 4 / GDScript。
Hex tile 拼接。
Center + 6 sectors 地块模型。
terrain / region / network 系统。
JSON 管理 tile / terrain / invader 等配置。

9.4 核心工作

设计 Hex tile 拼接规则。
设计 Center + 6 sectors 地块模型。
实现 RegionSystem，统计 mushroom / crystal / water 等地貌 region。
实现 NetworkSystem，处理 floor network、入口网络、最近宝箱路径、核心路径等。
实现 InvasionSystem，处理入侵者规则与结算。
实现 SaveSystem 支持存档。
采用数据驱动方式维护配置。

9.5 技术细节

Godot 4 / GDScript。
六边形网格。
图 / 连通性 / 路径相关逻辑。
数据驱动配置。
文档驱动迭代和 AI coding 辅助开发。

9.6 主要难点

拼图规则、连通性、region 统计和入侵路径之间存在复杂状态依赖。
游戏逻辑需要兼顾可玩性、可扩展性和数据驱动配置。
个人项目需要靠文档和任务拆解保持长期迭代。

9.7 结果 / 产出

已形成的材料：

已有多个核心系统设计记录。
适合作为个人工程展示，但不一定适合主简历。
有可运行 demo。
项目已在 GitHub 公开开源。

当前未整理：

截图、视频或 itch.io 页面。

9.8 可量化信息

当前无可靠量化指标。

适合保留：

GitHub 公开开源。
有可运行 demo。

9.9 可复用的简历表达

使用 Godot 4 / GDScript 开发六边形拼图游戏原型，设计 center + sectors 地块模型、region 统计、floor network 和入侵路径系统。
采用数据驱动方式维护 tile、terrain、invader 等配置，并通过文档化流程管理玩法迭代与系统重构。
将 AI coding 工具用于功能拆解、代码审查、测试补充与开发文档维护，形成个人项目中的工程化迭代流程。
开源 Godot 4 / GDScript 游戏 demo，通过 GitHub 展示六边形网格、区域统计、路径网络和数据驱动配置等系统设计。

9.10 可展开的面试问题

六边形网格坐标如何设计？
region 和 network 有什么区别？
如何检测连通性和路径？
数据驱动配置如何组织？
AI coding 在这个项目中如何使用？

9.11 避免夸大的内容

不放在 AI / 数据科学简历核心位置。
不写商业化或用户数据，除非有证据。
不写复杂引擎能力，重点写系统拆解和个人工程能力。

10. 风险点与待补充问题

10.1 后续需要补充的事实

新品预测项目对外表述中是否写“主导”的具体边界：数据口径 / 建模验证 / 服务化 / 业务解释。
新品预测的上线范围：已形成上层业务系统可调用的服务化成果，但是否可写“上线”需看公司口径。
款色数、订单行数、销售行数、商品数量。
Top-K 命中率或排序相关性的具体数值。
是否实际采用 LightGBM / GBDT，还是目前只是方案和报告解释。
MP Copilot 的真实页面、接口数量、知识库规模、Workflow 节点数。
KnowledgeBase 是否已有实际使用人数、知识文档数量、导入向量库或 LLM Workflow 的状态。
S&P 实习中 2000+ 车型、10 万+ 评论、6 个月、3 份报告这些数字是否准确。
S&P 情感分析和 OCR 是否能找到原始评估记录；找不到就不写模型 / OCR 准确率。

10.2 不放入公开 / 正式表达的内容

99.9% availability。
推理时间从秒级到毫秒级。
日均百万级数据存取。
不带 POC 评估口径写“显著提升新品预测准确率”。
大幅降本增效。
完整生产级 Agent 自动化业务操作。
把 KnowledgeBase 写成完整企业知识库平台或自动 RAG 全流程。
金融量化策略、因子研究、交易系统。
S&P 情感分析模型准确率、OCR 准确率等无证据数字。
合同审核精确准确率只放在私有投递版本，且必须限定为项目评测口径，不能写成通用法律判断准确率。

10.3 后续可补充的材料

新品预测：一张字段字典、一张样本构建流程图、一张训练验证切分图、一张指标对比表。
Copilot：接口 schema、示例 request / response、Workflow 截图、answer-quality checklist。
KnowledgeBase：公开架构图、AGENTS / skills / commands 示例、validate 规则、review 流程图。
合同审核：合同解析流程图、风险类型列表、RAG 引用样例。
S&P：数据库表结构、数据管道流程、LSTM 训练记录或评估结果。
AI coding：一个实际 PR / commit 案例，说明 AI 参与了什么、人工 review 修正了什么、测试如何验证。

John Ferrel

Explorer

Resume Pool

Resume Pool

0. 基础信息

公开链接

教育经历

推荐主线

2-3 年经验简历组织原则

1. 岗位方向与表达素材

A. AI / LLM 应用工程版

B. 数据科学 / 预测算法版

C. 量化开发 / 数据建模初级版

2. 简历取舍

AI / LLM 应用工程简历主线

数据科学 / 预测算法简历主线

量化开发 / 数据建模初级简历主线

3. 服饰零售新品预测 / 需求预测 / 预测服务化

3.1 背景 / 业务问题

3.2 负责范围

3.3 输入数据 / 系统上下文

3.4 核心工作

3.5 技术细节

建模设计

时间切分与泄露控制

评估设计

数据脱敏与指标污染

工程化 / 服务化

3.6 主要难点

3.7 结果 / 产出

3.8 可量化信息

3.9 可复用的简历表达

3.10 可展开的面试问题

3.11 避免夸大的内容

4. 零售 SaaS Copilot / LLM 应用工程 / Workflow + FastAPI Adapter

4.1 背景 / 业务问题

4.2 负责范围

4.3 输入数据 / 系统上下文

4.4 核心工作

4.5 技术细节

Adapter 边界

上下文设计

响应归一化

部署和工程闭环

4.6 主要难点

4.7 结果 / 产出

4.8 可量化信息

4.9 可复用的简历表达

4.10 可展开的面试问题

4.11 避免夸大的内容

5. 内部知识库冷启动 / OpenCode 工作台 / RAG 知识治理

5.1 背景 / 业务问题

5.2 负责范围

5.3 输入数据 / 系统上下文

5.4 核心工作

5.5 技术细节

第一版工作流

Docker + SFTPGo 升级后

权限与治理设计

5.6 主要难点

5.7 结果 / 产出

5.8 可量化信息

5.9 可复用的简历表达

5.10 可展开的面试问题

5.11 避免夸大的内容

6. AI Coding 工程化工作流

6.1 背景 / 业务问题

6.2 负责范围

6.3 输入数据 / 系统上下文

6.4 核心工作

6.5 技术细节

6.6 主要难点

6.7 结果 / 产出

6.8 可量化信息

6.9 可复用的简历表达

6.10 可展开的面试问题

6.11 避免夸大的内容

7. 工程合同智能审核系统 / 创业项目

7.1 背景 / 业务问题

7.2 负责范围