2026-09-11 工作日志

物码早会：数据一致性监控早会

发言人：李亚洲、刘晓娜、孙东栋、邢健、王建朝等 7 人

主题摘要：本次会议同步了各模块项目进度，重点排查了数据一致性监控告警，并明确了数据差异清单输出、历史问题排查及异常修复计划等后续跟进事项。

小结

• 主计划与积分运营：主计划已由相关人员修订，要求今日完成更新、本周内重新发布；积分运营按既定排期推进，因无调整空间未逐一过会，有问题直接反馈。红运中心与数据权限模块进度正常。
• 告警现状：今日共 7 条告警，其中 3 条为常态化告警；新增 2 条「码状态表之间码状态不一致」异常告警。
• 历史告警修复进展：序号 714 告警属正常业务现象，后续需优化健康度规则；B 端出货明细表与盘点明细表的地址类为空问题已于 9 月 10 日按计划完成修复，今日需关注修复情况；流向查证明细表的地址类问题修复排期至 9 月 17 日。
• RPC 调用异常排查：需排查监控中的 RPC 调用异常是否导致产品编码或名称缺失，并寻找去年类似问题的处理记录。

待办

• 更新主计划，并于本周内重新发布。 — （原文未标注责任人）
• 输出夜奶的存量差异数据清单。 — （原文未标注责任人）
• 完成导购与经销商关系的 119 条差异数据的郑然、失效处理与达标处理。 — （原文未标注责任人）
• 针对序号 10 告警，探查具体原因并制定修复计划。 — （原文未标注责任人）
• 排查 RPC 调用异常问题，寻找去年类似问题的处理记录。 — @建朝（王建朝）@宋阳
• 排查 RPC 部分数据问题。 — @马奇
• 排查 RPC 部分数据问题。 — @王建朝

关联与提示

1. 高德故障链出现首个闭环信号：9.09 门店域评审定的 B 端出货明细表 4.2 万条退货地址空值修复，已于 9.10 完成（@潘玉平 采用"先筛临时表再精准修复"方案）。但流向查证明细表同类问题排到 9.17，且 9.08 那笔盘点数据丢失 1.8 万条（@余勇军）本场未提及。建议今日指定统一收口人，把三笔并成一张清单做验收确认。
2. 主计划已第三次提出"更新并重发"：9.08（中午前更新、下午重发）、9.09 结转、本场再提"今日更新、本周重发"。反复提及却始终未闭环，建议本次直接钉死责任人与发布时间，否则会持续变成背景噪音。
3. 告警口径需留痕：本场新增序号 10、并提到序号 714 属"正常业务现象"需优化健康度规则。延续此前提醒——凡是"调阈值/改规则忽略差异"的处置，每次都要记录为什么调、调到多少、何时回调，否则半年后监控阈值全是被人动过的，无人知晓原始口径。
4. RPC 待办重复且责任人交叉：末两条均为"排查 RPC 部分数据问题"，分别挂 @马奇 与 @王建朝；同时"RPC 调用异常"一条又挂 @王建朝 @宋阳。疑为转写重复或任务拆分，建议核对后合并，避免三人各查各的。
5. 转写存疑：「@宋阳」疑为全项目常见的「宋洋」，未合并；「郑然、失效处理与达标处理」语义不明（疑为"整然"或人名"郑然"+ 处理动作），原文保留未改写；导购与经销商关系差异 119 条系 9.07/9.08 结转任务（原 @邢健）的推进结果。

---

营销活动中心技术面试（录用结论）

发言人：（原文未列）

本场为 Java 后端岗位候选人筛选，两位候选人均评定为不通过。

候选人	结论	主要问题
张明伟	不通过	沟通能力不行
郑晓哲	不通过	技术细节讲不清

其中郑晓哲的完整面试记录见下一节。

---

Java后端开发技术面试

发言人：郑晓哲、张建利、王建朝、薛碧盈、马奇

主题摘要：本次面试围绕候选人在快看财务结算平台中的付款对接、分布式锁及存储选型展开，重点考察了三方接口幂等性设计与AI辅助编码实践，并指出了其在数据库底层原理上的认知盲区。

小结

• 候选人背景：6 年 Java 开发经验，历经云智慧、夸克、快看；栈为 Spring Boot / Spring Cloud / MyBatis，数据侧覆盖 MySQL、ClickHouse、ES、达梦，中间件用 Redis、RabbitMQ、Kafka。
• 快看财务结算平台：服务于漫画公司付费会员结算，含结算方管理、电子合同签署、账单生成、付款；本人负责合同管理、付款单生成，以及对用友付款平台、易签宝、钉钉等三方系统的对接。
• 三方付款的可靠性设计（较扎实）：超时采用重试 + 熔断 + 本地任务队列落失败数据 + 定时任务重推；客户端与服务端双层幂等，以唯一结算单号控制；超时超 5 次触发钉钉告警交人工处理。
• 并发控制：调三方接口前加 Redis 分布式锁，key 为「结算单号 + 机器 IP」，防定时任务多机并发重复推送；付款单状态流转用 MySQL 乐观锁（以原始状态为更新条件），理由是内部并发量不高、省开销。
• 存储选型：MySQL 存平台基础信息与账单等结构化数据；合同数据因含不同计算规则的 JSON 配置、量达千万级，为提升 JSON 查询效率并避免 MySQL 表冗余，选 MongoDB。候选人称写合同不涉及同时写其他 MySQL 表，故无跨数据源事务问题。
• AI 辅助编码实践：日常 70%—80% 代码量由腾讯 CodeBuddy 等工具生成；流程为 PRD → 技术文档 → AI 生成流程图 / 时序图 / 建表语句；AI 产出基础 CRUD、人工 Review 并补复杂逻辑；简单 CRUD 页面生成与人工审核时间比约 1:1；复杂业务流程 AI 只能给大致步骤，仍需人工完善。

面试问答要点

• 【王建朝问】 客户端调用服务端超时且未收到返回状态，客户端如何控制幂等？ 【郑晓哲答】 超时导致状态未变更时客户端会重复调用，此时客户端无法做到完全幂等，需依赖服务端基于结算单号拦截。
• 【王建朝追问】 那客户端做幂等的意义大不大？ 【郑晓哲答】 主要是避免在已知推送成功的情况下重复调用，减少对服务端的并发压力。
• 【张建利问】 为什么 MySQL 在 500 万到 1000 万数据量时查询效率会降低？ 【郑晓哲答】 不太清楚具体原因，只知道会有瓶颈，没有仔细了解过底层原理。 【张建利纠正】 千万级甚至上亿的数据 MySQL 也没问题，核心看表结构怎么设计、怎么用。

结论

• 候选人郑晓哲：不通过（技术细节讲不清）。本场无新增待办。

关联与提示

1. 与 9.07 两场面试构成同一批次：面试官班底一致（张建利、王建朝、薛碧盈），至今累计四位候选人（9.07 张玉龙、屈宗凯；今日张明伟、郑晓哲）。
2. 这位的短板比前两位更具体：9.07 两位是"能否从方案层上升到架构层"的问题；郑晓哲这边，工程落地（幂等双层设计、熔断+队列重推+告警升级、分布式锁 key 设计、按数据形态选 Mongo）其实做得对，卡在讲不清底层原理——MySQL 大表为何变慢答不上来。张建利那句纠正点到了根子上：数据量不是瓶颈，表结构设计才是。
3. 值得留意的一条信号：候选人自述 70%—80% 代码由 CodeBuddy 生成，生成与审核时间比 1:1。这说明 AI 编码在日常开发里已经是常态，同时也意味着**"人工 Review 的能力"正在变成核心能力**——如果团队里 AI 生成占比上去了，而 Review 只停留在"能跑就行"，那么像"表结构设计决定千万级性能"这类认知盲区会被 AI 生成的默认值悄悄固化。这跟我们做评审 Agent、技术方案自检清单是同一件事：AI 提高了产出速度，把关的活还在人身上。建议在团队 AI 编码规范里补一条——AI 产出的表结构、索引与关键链路，必须走一次人工设计评审。
4. 隐私提醒（第三次）：本文件位于 VitePress 文档站 docs/work-log/ 目录、会随站点构建发布，而本节含候选人姓名、项目经历、能力评价与明确的录用结论（不通过）。建议要么移出不发布的目录，要么做匿名化处理（如 A/B 候选人），并隐去"不通过"这类人事结论。

---

智能体建设规范体系与全流程管理（全员宣讲）

发言人：刘天垒、贺娟娟、包云杰

主题摘要：针对智能体建设"质量不可控、安全风险突出、标准缺失"三大痛点，正式发布覆盖全生命周期的分层规范体系，并同步 PRD 设计规范、技术安全总则、评测准出标准与安全红线清单，会后组织全员规范考试。

小结

• 痛点与总目标：直指质量不可控、安全风险突出、标准缺失三大问题，建立"总规范 + 子规范"的分层结构——总规范管全流程节点与责任主体，下设 PRD 模板、技术设计规范、评测规范三个子规范。
• 配套技术标准：同步发布技术选型指南（明确语言与框架）、工程开发规范（代码与低代码平台）、以及 Dify 平台搭建规范（原文记作"DeFi 平台"，按上下文确认为低代码智能体搭建平台 Dify）。
• 六大阶段 23 个节点：需求设计 → 技术设计 → 开发实现 → 评测验证 → 上线交付 → 运营。PRD 评审、测试集评审为关键门禁节点，未过不得进入下一阶段。
• 测试集必须前置到需求阶段：测试集即验收标准，开发与测试全程以它为准——这是本次流程里改动最大的一条，等于把"先开发后补测"的路堵死。
• 环境与版本管理：开发、测试、预生产严格隔离；代码、Prompt、知识库配置、工具清单四类资产一律纳入版本化管理（Prompt 与知识库首次被挂版本，是最容易漏的两项）。
• 开发自测下限：业务正确性维度用例覆盖率 ≥ 40%，意图识别类 ≥ 20%；这是准入下限而非目标值。
• PRD 七章要求（刘天垒）：必须论证为何用智能体而非传统数字化方案，防止为用而用；大模型选型走业务能力满足度、成本（Token 单价与调用量预估）、安全合规（数据分级与 SaaS 调用限制）、版本迭代兼容性四维度；需定义智能体角色（如数字员工）与任务故事（人机协同下的目标、能力、约束）；PRD 必须含培育与运营机制，设计用户反馈回流、数据回流与评估体系。
• 技术设计八大总则（贺娟娟）：可控——关键环节人工介入、高危操作人工确认，智能体定位为辅助工具，最终决策权归人类；可观测可追责——关键决策与工具调用全程留痕，日志留存内部 3 个月、外部 6 个月，责任主体必须明确为人类；最小权限与默认安全——按需授权、默认拒绝，智能体权限不得突破用户原有权限。
• 数据安全分级：L1/L2 可经 API 网关调用外部模型；L3/L4（秘密/机密）必须私有化部署；绝密数据严禁用于智能体建设；涉及个人信息必须脱敏。
• 记忆与提示词安全：记忆存储不得含敏感信息；提示词严禁直接拼接用户输入、严禁包含密钥，需结构完整并含角色任务约束。
• 评测六维度（包云杰）：业务准确性（权重最高）、意图识别、鲁棒性、安全合规性（一票否决）、可靠性、性能（端到端耗时）。测试集须来源真实业务日志占比 40%—50%，判定标准明确，建立 Bad Case 回流机制，严禁全量 AI 生成。
• 三重评测与防衰减：自动化机评 + 人工复评（抽检 ≥ 50%）+ 报告评审；每月全量回归，指标衰减 >5% 需修复，>10% 或安全指标衰减必须启动回滚评估。
• 上线准出：生产发版须达成"四个 100%"（维度覆盖率、执行率、达标率、修复率），并通过 8 个强控指标考核。
• 安全红线四类 12 条：严禁直连模型供应商或自建网关，一律走集团统一模型网关；高代码 Agent 必须全员码交付、低代码必须在指定平台构建；绝密数据不建智能体、L3/L4 用私有化模型、个人信息脱敏、高危操作人工确认；密钥口令严禁写入代码、Prompt、工作流或知识库；评测集 100% 覆盖六维度且 100% 执行、安全防护率 100%、必须通过业务用户验收。

待办

• 会后组织规范考试，需全员通过。 — @全体参会人员

关联与提示

1. 这条线走了两个多月，今天终于落地：8.07 专项周会由贺娟娟承接 Agent 建设规范完善（当时定 8.11 二次会议）→ 8.21 周报口径为"规范基本定稿，近两周内准备全员宣讲及试行版发布" → 9.11 正式发布。注意 8.21 说的是"近两周"，实际推迟了约三周，中间缺少可见的里程碑回执，下次同类交付建议中途设一次检查点。
2. 最大落地风险：存量智能体要不要回炉。按这个准出标准，已上线或已试点的设备智管、IoT 物联、间接物料采购定价智脑、OA 流程审批、权限小助理、内容运营六个智能体，几乎没有一个做过"来自真实日志的测试集 + 六维度机评 + 50% 人工复评 + 四个 100%"。规范里没写老项目怎么过渡——是限期补测、还是豁免、还是新项目才适用？这个口子不回答，规范要么沦为纸面，要么让六个已上线智能体全部变成违规在线。
3. 「测试集 40%—50% 来自真实业务日志、严禁全量 AI 生成」，与昨天面试那条信号正好是同一件事的两面。郑晓哲自述 70%—80% 代码由 AI 生成、审核环节实际只到"能不能跑"这一层。规范现在把"AI 生成不得作为验收依据"写成了硬约束，但没给"人工审什么、审到什么颗粒度"的标准。建议在咱团队 AI 编码规范里补一条呼应条款：AI 产出的表结构、索引、关键链路与测试集，必须走一次人工设计评审并留痕。
4. 「智能体权限不得突破用户原有权限」与此前 EdBody 口径需合并校验。9.03 EdBody 宣讲确定了"平台仅透传用户身份、权限校验由 MCP 工具侧自行实现"（已入项目原则第 8 条）。本次把边界讲得更严了一层——不突破用户权限。这意味着工具侧不能只做"身份是谁"，还要做"这个人本来有没有权看这条数据"。建议拉一次核查：现有 MCP 工具里，只验身份未按用户权限收口的，逐条列出整改清单，否则 MCP 工具会成为这套权限原则最大的漏洞面。
5. 数据分级的落地前提是"我们有哪些数据、各是哪一级"。这条口径目前似乎没有一张全量清单。营销活动中心侧涉及门店、经销商、店主、导购的个人信息，按"涉及个人信息必须脱敏"和"高危操作人工确认"，建议先把营销域的数据分级表补出来，再反推哪些智能体需要改成私有化模型。
6. 密钥红线要落到存量：严禁写进代码/Prompt/工作流/知识库——这与之前 MCP Server 安全设计（签名验证 + NetID 绑定）是同一要求。建议把这条做成一次全仓扫描动作，而不是靠宣讲让人自觉；Prompt 和知识库配置这两处最容易被忽略，且通常不在代码扫描范围内。
7. 三件"定了要求没定人"的事：① 日志留存内部 3 个月、外部 6 个月——谁存、存哪、到期谁删没明确；② 每月全量回归——谁跑、成本谁担、结果向谁汇报没明确；③ 8 个强控指标——文件里只给了数量，指标清单未见。这三件最容易在三个月后变成"大家都以为别人在做"。
8. 与专项五的关系没说破：这套规范是治理对象，而"构建技术管理 Agent 服务"恰恰可以成为它的日常执行体，而不是全靠人工抽查。建议明确一点：评审/自检 Agent 自身也要过这套评测与红线，否则会出现"用 Agent 审 Agent 合规，但审人的 Agent 反而没人审"。
9. 术语存疑：原文"DeFi 平台搭建规范"，结合低代码平台上下文判断为 Dify，已在正文中更正并括注；如需准确请以原始材料为准。

---

RPC 问题沟通

发言人：王建朝、潘玉平、李明非、马奇、张喜（会议 15:44—15:55，发起人马奇，会议号 389247415）

主题摘要：复盘 RPC 调用异常导致的积分退款数据不一致问题，明确了"按原订单汇率退还积分"的原则，并要求建立 RPC 异常处理 SOP 与统一问题管理台账，杜绝长期依赖中台或业务反馈驱动修复。

小结

• 根因定位（潘玉平）：806 版本发版期间调用 data 服务写入数据，调用异常被捕获后后续逻辑未再执行，导致部分字段未设置就被发送到 MQ，最终只写入一部分数据。
• 李明非补充归因：该问题应归类为主数据那一块的服务在 806 时停掉所致，而非泛化的"RPC 问题"。
• 王建朝对归因口径的批评：用「RPC」这种技术大类词描述原因会误导——"你只要用 dubbo 的服务都是 RPC，用 Spring Cloud 的服务都是 RPC，都能叫 RPC"，给人感觉同一类故障在频繁发生，实际可能压根不是一个问题。要求故障原因细化到具体服务与代码层面。
• 806 遗留拖期：王建朝指出 806 那次 RPC 问题至今已一个月才想起修复，暴露出对 RPC 异常的处理缺少机制、敏感度不足。
• 积分退款汇率原则（潘玉平）：京东侧支持分时间段设置汇率；若退款时按当前实时汇率计算会算错。确定原则为——按原订单创建时间所处的汇率阶段退还，"当时消耗了多少积分就退多少积分"，最后以京东创建时间去分配核算。
• 混合支付拆分：现金 + 积分混合支付时分别退还——现金部分按原金额退（京东侧退），积分部分退对应的积分。
• 数据修复现状：本批异常是数据中台监控发现的（非业务反馈），因排期一直未排上导致修复延迟较晚；已于昨日（9.10）紧急修复，将正确数据存入指定表，并会把活动、支付活动、订单编号等信息告知业务侧做核对。
• 拆单延迟风险（潘玉平）：拆单本身有延迟，若退款时尚未拆单，则对方给的指定物料在物料域找不到，导致退款失败/数据丢失 → 需等拆单完成后再执行退款逻辑。
• 要求建立 RPC 异常处理 SOP（王建朝）：不能老等用户或中台反馈才排查。初步构想的流程为——① 解决异常、恢复生产 → ② 识别影响范围（哪些业务线需要修复）→ ③ 把修复任务关联进后续待办，形成可查询的闭环。
• 统一问题管理台账：当前"每个人反馈出去的口子都不一样"，要求把所有问题（RPC 异常、业务反馈等）统一记录到一张 Excel 表。由李明非牵头整理，先发给王建朝审核格式。

待办

• 整理并输出 RPC 异常处理 SOP 文档及统一问题管理 Excel 台账，先发给王建朝审核格式。 — @李明非（牵头，与马奇同步）
• 重写故障原因描述，将笼统的"RPC 异常"细化为具体的服务或代码问题，并更新到故障表。 — @马奇（转写口径为李明非重写、马奇贴入故障表，建议确认最终责任人）

关联与提示

1. 这是今早物码早会那条 RPC 待办的答案。早会里"排查 RPC 调用异常是否导致产品编码或名称缺失、并寻找去年类似问题处理记录"，当时拆成三条挂给 @王建朝 @宋阳、@马奇、@王建朝（我当时标过"疑为转写重复"）。本场给出了根因：806 发版期间 data 服务调用异常 → catch 后中断后续赋值 → MQ 里只写了一半字段。建议把早会那三条重复待办合并到本场结论下并标记为已定位，别再让三个人各查各的。
2. 「故障原因禁止使用技术大类词」值得沉淀成原则。王建朝这段话点得很准：用 RPC / 超时 / 网络抖动这类词描述根因，等于没描述——它既定位不到服务和代码，也会让故障表看起来像同一类问题反复发作，进而掩盖真正的频次与趋势。建议故障表强制填写「具体服务 + 具体接口 + 具体代码分支」三要素。这与此前沉淀的「操作数据库的 SQL 必须带分区键、评审材料里没写等于没评审」是同一类把关动作。
3. 806 拖一个月，代价正是 SOP 里第二步缺位：不是发现不了（这批是数据中台监控发现的），而是发现了没人认领、没人排期。所以台账的价值不在"记录"，在于每条必须带责任人和排期。建议台账字段至少含：发现来源（监控/业务/用户）、影响范围（业务线 + 数据量）、根因（服务 + 接口 + 代码）、责任人、排期、关联待办编号——否则又会变成一张无人回看的静态表。
4. SOP 第二步"识别影响范围"必须产出可交付物，否则流程文档会空转。建议固化为一份标准清单：受影响业务线 → 涉及数据表与条数 → 修复 SQL 的时间范围与分区键 → 回滚/兜底方案。这样第三步"关联待办"才有东西可挂，也才能直接对接我们已有的数据修复评审口径（先堵后修、SQL 必带分区键）。
5. 积分退款"按原订单时间汇率"这条原则，需要回扫积分体系当前实现。这与门店积分正在做的有效期、批次扣减顺序、跨产品扣减是同一套账务口径；若现有实现按实时汇率或按当前批次价值退，混合支付场景会出现退多或退少。另外"现金京东退、积分京东退"的说法在转写里前后不一，需与京东侧接口确认到底谁退哪一部分，避免重复退或漏退。
6. 拆单延迟导致的退款物料缺失，是典型的异步依赖未做前置等待。建议确认退款链路是否已有"拆单未完成则排队/延后重试"的机制；如果没有，这条会比 RPC 异常更频繁地复现，且同样会被笼统归因成"退款失败"。
7. 转写串台提醒：会议中段王建朝把话题错接到昨天评的 **store_distance（签收距离）**上（转写作 "distinct / distance"），潘玉平随后澄清"咱这就不考虑这个汇率了"并拉回积分退款。两件事不要混进同一条待办——9.10 那份 store_distance 修复 243 单的方案已被判不通过、需小范围重评，与本场不是一回事。
8. 转写存疑（原文保留）：「零角 RPC / 发零六版本」按上下文判断为 806 版本；「金老师 / 建超老师 / 建朝老师」均指 王建朝；「亚亚洲」指早会发言人 李亚洲（早会那句"去年也发现过 RPC"即出自他，王建朝在本场复述）；「罗罗斌」疑为 罗斌（反馈数据修复问题的一方）。