问题建模
先把决策变量、约束和验收样例写下来。写不出验收样例，说明问题还没想清楚，这时候不该开始求解。
从一句模糊的要求到能被调用的接口。
我的工作通常从业务方一句说不太清楚的要求开始，到生产系统里一个能被调用的接口结束。中间是建模和求解，但真正花时间的往往是最后一步：让看结果的人愿意照着执行。
求出答案只是其中一段。数据怎么进来、约束怎么解释、结果发出去之后谁来负责， 这几件事不解决，模型算得再准也停在报告里。
Trajectory
职业轨迹
求解器团队、制造企业，再到把决策接进生产系统。看着像三个行业，其实是同一个问题的三个环节。
- 2023杉数科技
运筹优化算法工程师
在求解器团队里做行业模型，把业务问题写成标准的数学形式。
- 按行业场景搭建运筹模型并调优求解参数
- 在真实业务约束下比较不同求解器的表现
- 2024 – 2026固特异轮胎
Data Scientist · Operations Research
在制造企业里做生产和供应链优化，约束来自车间和物流现场。
- 生产与供应链场景的优化建模，以及换一组假设后的情景对比
- 把预测接到优化前面，让计划对需求波动有反应
- 和业务方一起定指标口径与验收标准，这部分常常比建模更耗时
- 2026 – 至今大型农粮与消费品集团
AI 架构师
把单点求解能力做成能接进生产系统、也能持续改的架构。
- 决策服务与 TMS、订单系统、生产计划系统之间的接口契约和幂等设计
- 用结构化生成把业务描述转成能评审、能进版本库的模型规格
- 一套共用脚手架加自动化检查，支撑多个决策产品并行往前走
Capability matrix
能力构成
一个决策产品从提出到能用，要跨过这四关。前三关做得再漂亮，最后一关没人接受，前面就白做。
求解工程
从跑得通的启发式起步，有了基准再考虑换成混合整数规划。没有基准的优化只是换了个算法。
系统集成
幂等接口、批次能重放、失败带原因码。对接 TMS 和订单系统的时候，这几样比求解质量更早暴露问题。
决策交付
结果要说清楚为什么、和上一版差在哪、想改的话从哪改。只给一个数字，没人敢用。
Tracks
作品的三条主线
作品集按这三条主线组织，方便你从关心的角度直接切进去。
How I work
工作方法
- 先写下决策变量、约束、指标和验收样例，把问题变成能判定的
- 用能解释的基线建立反馈，再一步步提高求解质量
- 脱敏、测试、可观测性和人工干预从一开始就算进产品边界
- 实现和重构交给模型，判断与验收标准自己拿着
- 接口与求解测试
两个 Demo 后端各自带 pytest 用例，覆盖健康检查、正常求解与边界参数。 - 构建即校验
前端以 TypeScript 严格模式构建，类型不通过就产不出静态资源。 - 自动隐私扫描
scripts/privacy_check.py 扫描全部可发布文本，命中凭证、内部域名或业务标识就直接失败。 - 表述纪律
「可扩展能力」和「已上线成果」在数据模型里就是两个字段，演进方向没机会被写成既成事实。
Disclosure
公开边界
这个站点的每一处内容都经过脱敏，可以放心作为公开材料查阅。
- 全部演示数据由程序生成，不含真实订单、客户、坐标或物料编码
- 案例来源的现任雇主只写行业描述，避免公开案例和内部系统被对上号
- 案例页只讲通用架构与抽象约束，不提供表结构、平台标识或内部接口
- 「产业级可以做到什么」写的是现有扩展点上的演进方向，和已上线成果分开陈述
- 发布前跑一次自动隐私扫描，命中凭证或业务标识就中止发布