01
手工计划总是被打乱
每当班次、访问、配送或订单变化，就有人重新调整计划。
数理系统开发
人们每天反复调整的计划，让系统来思考
排班、访问日程、车辆调度、工序和负责人分配。我们把依赖 Excel 和熟练人员的复杂判断转化为数理模型，再实现为现场可用的 Web 和应用系统。
最快 2 周试作
Web、iOS、Android
支持现场专属规则
约束求解器
已优化 · 0.38 秒
访问日程 / 6月20日
最快 2 周试作
青木
伊藤
佐藤
林
09:00
V-012北部 / 护理
V-008东部 / 康复
11:00
V-003中部 / 心理
V-021西部 / 儿童照护
13:00
V-017北部 / 康复
V-026南部 / 心理
约束问题
0 项
总移动时间
84 分钟
分配率
100%
min Σ cᵢxᵢ + λΣ vⱼ
s.t. Ax ≤ b
我们解决的问题
当业务充满约束时，普通系统开发容易错过核心。
Finite Field 处理的是约束过多、简单表单系统不够、通用 SaaS 也难以覆盖的业务。
02
规则难以看清
技能、容量、地点、期限和优先级规则存在，但散落在表格和人的记忆中。
03
复杂性由专家吸收
同一份数据在 Excel、聊天和系统之间复制，最后仍由同一位专家修正。
04
系统没有参与判断
已有系统只记录结果，真正困难的判断仍在系统外完成。
答案不只是更好看的画面，而是能够判断并解释的模型。
我们把这些问题当作数理系统处理：建模判断，测试约束，解释结果，并围绕这套逻辑构建运营界面。
从业务规则到系统模型
当判断不断重复时，系统需要一个数理层。
Finite Field 不从画面清单开始，而是先把现场判断拆解成变量、约束、目标和解释要求，再设计系统。
变量
人员、访问、设备、订单、车辆、时间段、技能、容量和日期都成为明确数据。
约束
技能、期限、地点、负荷上限、优先级、不可用时间和业务例外会被写成规则。
目标
减少移动、平衡工作量、提高偏好匹配、保护交期，或让运营人员看清权衡。
我们不是从画面清单开始，而是先定义决策变量、约束、目标和解释要求，再把它们落到团队能够运营的产品中。
分配演示
试试看，充满约束的排程在变成数理模型后会怎样变化。
这个浏览器演示只用于说明，不会把数据发送到页面之外。
访问排程规划器
切换目标并运行规划器。
手工方案: 2 项约束需要修正
示例: 9 次访问 / 5 名人员
解决领域
我们围绕判断本身构建，而不是围绕通用画面分类构建。
我们重点处理每天都要反复调整的计划业务，例如排班、访问、车辆调度、工序和负责人分配。
排班
班次与人员配置优化
把技能、时间段、休息规则和公平性转化为可检查的排班计划。
现场业务
访问与巡回排程
在移动、技能匹配、偏好人员和时间窗之间，分配访问和现场任务。
路线
车辆路线与配送计划
在容量、顺序和服务约束下规划车辆、配送和停靠点。
匹配
分配与匹配系统
用可解释的优先级和例外规则，匹配人员、案件、订单或资源。
交付流程
先建模，再做原型；适配清楚后再进入正式开发。
在投入生产系统之前，我们先把范围缩小到足以验证模型的程度。
01
盘点规则和数据
收集当前表格、规则、案例和例外，找出真正发生判断的位置。
02
构建模型
把业务拆成变量、约束、目标和解释要求，形成可以审查的模型。
03
制作运营原型
围绕模型制作小型界面，让运营人员可以操作并发现遗漏规则。
04
规划正式开发
等数据、模型、易用性和风险前提都清楚后，再决定正式开发范围。
第一步
先小范围开始，再判断是否开发完整系统。
面对不确定的业务，我们从窄范围原型开始：建模规则，制作小型 UI，验证这套逻辑是否值得进入正式开发。
原型 ¥298,000 起
原型用于明确可行性和范围，并不保证业务效果。
规则和数据盘点
小型优化或匹配模型
可操作的业务原型
包含风险和前提的下一步范围建议
从研究到产品
建模、验证、运营
NPA
验证
产品
Math Lab
让研究靠近实现。
Math Lab 连接数理建模、证明导向思考与软件交付。首页介绍方向，并把希望深入了解技术的读者引向 NPA 等内容。
研究内容用于支持工程判断，并不是生产验证或形式化证明工具的替代品。
阅读 NPAFAQ
初次咨询前的常见问题
面向正在考虑是否把运营判断系统化的团队，整理初次咨询前常见问题。
什么业务可以做成数理系统？
排程、分配、路线、匹配、生产计划等有大量约束的业务都适合。我们会先把业务规则变成小模型，再判断应该开发什么。
会保证业务效果吗？
不保证。原型和演示用于确认可行逻辑、所需数据和使用体验，不承诺成本下降、销售增长或其他业务效果。
需求还没完全确定也能开始吗？
可以。通常先从小范围开始，包括数据检查、规则梳理和可操作原型。模型与运营方式确认后，再进入正式开发。