两周左右，我们做的不是把一堆规则包装成“智能”，而是让每一笔奖励都能被算清、被复核，也让暂时说不清的地方留在纸面上。
“想把公司的激励制度，按月统计，然后分发给员工。”
店铺先要过订单、增速、广告投入和利润质量几道门槛，奖励才能进入经营单元的奖金池；奖金池再经过分配比例与 KPI，最后才来到个人工资。
任何一处定义含糊，结果都可能看起来精确，却无法解释。原始材料里同时出现了新店、老店、亏损上限、订单利润分成等口径——它们不是可以被模型“猜对”的参数。
团队先把“月初—每周—次月初”的节奏摊开：数据从哪里来，计算发生在哪里，员工最终看到什么。
项目中段，工作没有急着向“完成”推进。规则冲突被整理成一份待确认清单，一项项留给客户和业务负责人。
不能因为表里出现一个暂定值，就默认为永远固定。
门槛影响店铺是否能拿到奖励。
暂定值是起点，还是长期上限，需要业务确认。
自动化的边界，必须与真实系统边界一致。
我们想留下的“真情实感”，不是一句感谢，而是这些认真对待客户规则的停顿。
确认员工激励、表格数据源、协同平台集成方向，以及要用脱敏业务样本完成 POC，而不是只做演示页面。
两张核心表浮出水面：店铺业绩表与员工薪资表。计算链路第一次有了可以核对的载体。
规则引擎、演示材料与试用资产被装进同一个交付包，问题从“能不能做”变成“哪些参数仍需确认”。
规则计算与协同平台的数据读取、文件发送、通知推送链路留下实测记录，团队同意先发客户试用。
Skill、产品需求说明、操作手册、测试表和演示视频被整理为客户可以继续试用与复核的一套资产。
0102030405这些数字只证明脱敏测试集上的计算一致性，不代表生产环境长期准确率，也不应被写成客户真实薪资规模。