Skip to content

2026-08-25 工作日志 ​

物码早会 ​

本会议为项目日常跟进会,重点同步了PC端P级指标、门店积分、监控告警及数据一致性等模块进度,明确了核心数据表货权问题的修复方案与排期调整要求。

小结 ​

1. PC端P级指标与营销拦截表

  • 依赖任务延期:流向准确率P级指标依赖于营销活动中心提供的拦截表,因开发进度影响,原定本周五完成的任务预计推迟至下周。
  • 业务发版风险:若本周无法完成,将导致业务侧9月16日的版本交付延期。

2. 门店积分与盘点任务UI

  • UI输出进度:各端UI设计稿已基本输出,盘点任务的页面此前仅通过原型展示,尚未飞出UI图。
  • 评审安排:需拉取业务方对盘点任务页面进行UI评审,晓娜需在今天完成该页面的UI设计并通知亚洲。

3. 智慧门店与数据一致性改造

  • 智慧门店数据修复:业内事业部门店与经销商关系的历史数据修复方案,待人员出差回来后拉回沟通。
  • 内部人员数据一致性方案延期:原定上周五完成的内部人员数据一致性改造方案设计已延期,技术侧今明两天出新排期。
  • 营销活动5段围栏问题:计划今日解决两湖区域5段围栏的数据一致性问题,并持续跟进报错处理。

4. 监控告警与货权数据处理

  • 告警状态分析:昨日验证过的10条告警均包含在存量问题中,近期无新增告警,主要聚焦于B端出货、流向、盘点及消费者中奖明细表的货权分析。
  • 财务失效致空值问题:部分货权数据为空系主数据财务失效所致,当前逻辑直接取值导致异常。
    • 涉及核心表:B端出货表、流向表、盘点表及消费者中奖明细表。
    • 微信工具码不违规:微信扫码工具产生的7条数据不会进入违规物码销售表,可忽略不影响整体结论。
  • 修复方案调整:930发版拟将经销商5段信息存至码上,后续直接读取而非实时查询,以规避失效问题。
  • 发版时间争议:会议指出9月30日临近假期存在运维风险,要求相关团队重新评估并调整发版时间。

5. 其他跟进事项

  • 晓娜线上功能:84号需求对应的两个功能点已于昨日上线,今日继续观察运行情况。
  • 小志监控规则配置:昨日已完成三个主题域的监控规则配置,今日继续推进其余配置工作。

待办 ​

  • 沟通确认营销活动中心拦截表进度,如有结论随时同步。 — @建新
  • 创建项目任务并在值班登记中记录给晓娜。 — @东栋
  • 完成盘点任务页面的UI设计并通知亚洲进行业务评审。 — @晓娜
  • 反馈内部人员数据一致性改造的最新排期和方案。 — @陈思
  • 今日拉会对齐营销活动中心的5段围栏数据一致性问题。 — @建新
  • 重新评估930发版时间并做出调整,规避假期前后运维风险。 — 团队

计费中心-奶酪:冷饮事业部3.1.2迭代营销活动PRD评审 ​

本会议为冷饮事业部3.1.2迭代营销活动PRD评审,明确了计费模块对接营销活动中心及营销天网支付通道的核心逻辑,确立了自动提现与余额手动提现机制,并针对接口兼容性、对账范围及测试排期等事项达成了明确结论。

小结 ​

1. 冷饮事业部营销活动PRD核心逻辑

  • 新增事业部枚举:在计费系统多事业部基础上新增"冷饮事业部"枚举,所有记账单、提现单据及记账户均通过多事业部实现数据分权。
  • 账期关闭机制:本期活动奖励关闭账期概念,所有记账单均设为长期有效状态,不再存在红包失效场景。
  • 收款方角色限定:本期仅支持店主、店长、店员三类门店类角色参与雾码营销活动收款。
  • 品牌出资与支付通道:出资方限定为品牌出资,统一走营销天网支付通道发放红包,不支持银联支付或数字化结案通道。

2. 系统对接与功能模块

  • 对接营销活动中心:计费通过原有接口接收营销活动中心推送的活动规则数据(不创建修改)及记账流水数据,用于记账落库与后续红包发放。
    • 活动规则同步:沿用原有接口,仅在事业部字段增加冷饮枚举。
    • 记账流水推送:沿用原有同步记账流水接口,字段无变化,生成记账单后自动触发提现动作。
  • 主数据对接:沿用现有推送与查询接口获取5类视图基础数据(销售区域、客户、门店人员信息、产品信息等),仅扩充冷饮事业部数据,未新增模型。
  • 对账功能复用:计费侧保留两套对账逻辑,分别基于上游营销活动中心记账单维度、下游营销天网支付单据维度进行对比,本期仅按冷饮事业部枚举过滤数据。

3. 自动提现与钱包管理

  • 自动提现触发机制:基于门店类角色,营销活动中心记账成功后系统自动生成提现单据并调用营销天网接口执行自动提现。
  • 失败重试与余额兜底:根据营销天网返回的支付结果判断提现状态,部分场景(如接口限流)会重试,其余失败场景不进行重试并将金额退回用户可提现余额。
  • 手动提现流程:用户可在智慧门店小程序钱包内查看余额发起全额手动提现,系统校验后调用营销天网接口执行,成功则更新状态并回调通知。
  • 钱包前端展示:冷饮事业部钱包仅展示红包相关Tab,无积分与卡券;提现记录模块结构不变,按冷饮事业部与门店类角色区分。
  • 大额拆单规则:继承原有系统逻辑,当提现金额超过200元时系统自动拆分处理,需在PRD中补充说明该通用拆单规则。

4. 接口兼容性与性能评估

  • 接口复用策略:对外接口保持原有多事业部兼容设计,未单独复制接口,仅在参数中增加冷饮事业部枚举。
  • 夜奶回归验证:需回归验证夜奶事业部原有业务是否因接口复用受影响。
  • 性能评估要求:需结合夜奶与奶酪事业部的历史业务量(如码量翻倍情况),评估当前生产环境流量并发能力,输出分析依据。

5. 测试排期与协同确认

  • 测试人员分配:丁聪已参与智慧门店钱包开发,需明确其与另一测试人员的职责划分与排期计划。
  • 对账接口确认:需与明飞团队确认冷饮事业部对账所涉的三套活动模块接口来源,避免遗漏或提供错误接口。

待办 ​

  • 在PRD中补充提现超200元自动拆单的规则说明。 — @赵敏
  • 安排测试人员验证提现失败场景及相关功能点。 — @丁聪
  • 回归验证夜奶事业部原有业务是否受本次接口复用影响。 — @王军
  • 结合夜奶与奶酪的历史业务量评估当前生产环境流量并发能力,并输出分析依据。 — @王军
  • 将PRD排期发给李强审核。 — @李强
  • 与明飞团队确认冷饮事业部对账涉及的三套活动模块接口来源。 — @王军

AI时代数据运营与组织变革分享会 ​

本会议分享了企业在AI时代的数据运营、人机协作模式及AI价值衡量等实践,并探讨了AI在组织变革中的应用。

小结 ​

1. 数据运营与AI应用

  • 差异化数据运营策略:针对不同规模客户(如C端、大B端经销商)需采用差异化策略,核心在于增强对少数据场景的感知力。
  • 多源数据采集与激励:已通过门店拍照、工牌录音、全链路扫码等方式采集数据,并设置激励措施保证数据质量。
  • 渠道运营以规则引擎为主:在渠道运营中,AI应用更侧重于规则引擎和传统算法模型,而非大规模生成式AI。

2. AI赋能组织与人机协作

  • 员工AI分身辅助汇报:为每位员工建立AI分身用于辅助汇报,通过模拟领导的AI分身进行反馈,以提升汇报质量。
  • AI价值衡量新视角:除提升效率外,更应关注AI能否在资本与成本间形成杠杆效应。
  • 人机协作模式重构:AI主导感知、生成和评估,决策与行动仍由人类负责。

3. AI价值衡量与组织布道

  • 商业杠杆价值:AI价值不仅体现在效率提升,更在于能否创造新的商业杠杆。
  • 组织布道与AI分身推广:通过认证AI讲师和公司内部的AI路演等形式积极进行AI组织布道,鼓励员工创建AI分身。

待办 ​

  • 进一步探讨AI能否决策公司费用分配等核心问题,以验证其在资本与成本间形成杠杆效应的价值。 — (待定)

营销活动中心接入TTS码保质期字段需求评审 ​

本会议讨论了营销活动中心接入TTS码质保期字段的需求,明确了新字段的格式与取值逻辑,并确认了该改动仅影响扫码出货、查证盘点及消费者中奖等过期判断场景,不影响报表数据。

小结 ​

1. TTS码保质期字段对接需求

  • 新增字段背景:TTS码数据增加了码质保期字段,营销活动中心需在码数据查询功能页面对接该字段。
  • 取值逻辑:若TTS未维护该字段,则码保质期为空;若传值,则直接作为码的有效期,不再自行计算。
  • 字段格式明确:TTS传递的码保质期为具体日期(年月日),不带时分秒,示例格式为20260825或带横杠的年月日格式。
  • 统一命名规范:文档中需将"码质保期"统一表述为"码保质期"。

2. 业务场景与逻辑判断

  • 核心影响范围:该字段仅用于扫码业务的过期时间判断,不影响任何报表数据的取数逻辑。
    • 扫码出货签收:扫码时若当前年月日大于码保质期则视为过期,不允许操作。
    • 查证与盘点:在查证明细表及盘点任务中,若码保质期满已维护数值则取该具体时间,否则沿用原有产品保质期计算逻辑兜底。
    • 消费者中奖:消费者扫码中奖场景同样限制码保质期,过期码无法参与抽奖。
  • 原有逻辑保留:当TTS未传入码保质期的具体日期时,系统仍沿用原有的计算逻辑(即码生产日期加上产品保质期)进行过期判断。
  • 盘点任务调整:盘点任务中无需再展示产品的保质期信息,仅需保留任务所属月份等基础信息,相关字段需从系统中删除。

3. 接口与文档更新

  • 接口保持不变:线上已有的码数据查询接口地址不变,仅在其中增加码保质期的对应信息字段。
  • 补充使用场景:需将扫码出货签收、查证、盘点及消费者中奖四个限制保质期的业务场景补充至需求文档说明中。
  • 遗留问题跟进:关于消费者中奖是否真正限制保质期尚存疑,需后续进一步向建新或产品经理确认并更新文档。

待办 ​

  • 修改文档中"码质保期"为"码保质期",并统一TTS传递日期的格式描述。 — @赵化龙
  • 将扫码出货签收、查证、盘点及消费者中奖四个业务场景补充至需求文档中。 — @赵化龙
  • 确认消费者扫码中奖是否限制码保质期,并在文档中更新最终结论。 — @赵化龙