目录

一、阶段目标与总体进展

D5 以“智能匹配与个人中心”为阶段目标。在 D4 已能申请、核验、归还和匿名沟通的基础上，本阶段让用户更容易找到候选物品，并能从个人中心查询自己的发布、成功找回、帮助归还和善意值。匹配负责提供可解释的线索，最终认领仍需双方核验，不能把相似度当成物品归属结论。

本阶段接通了“发布提交成功—异步重算—查询线索—查看匹配判据—进入物品详情”的路径。个人中心使用真实资料与统计接口，善意护照可以进入流水页，核对归还带来的余额变化。沿用现有 21 表，不新增生产 DDL；本人发布、认领和收到的申请继续复用已有接口与页面。

二、站会安排

讨论与核对事项

1. 分数与标签使用同一份样本。 核对物品的真实色码，异色样本不显示“颜色一致”，不能为了满足四项标签而改变输入数据。
2. 发布成功与线索生成分开观察。 发布提交后再异步重算；查询暂时为空时支持刷新，重算失败不撤销已成功的发布。
3. 个人中心只查询当前登录用户。 统计和流水不接受客户端指定他人身份；页面退出或换号后清空旧数据。
4. 善意值与归还结果共同核对。 一次归还应增加一次帮助归还数、10 点善意值和一笔流水，重复确认不能重复结算。
5. 明确验收层次。 后端测试、页面源码测试、MySQL／Redis HTTP 检查和微信设备操作分别记录，自动化通过不代表已完成真机视觉验收。

三、六人分工、进展与困难

六人职责沿用统一任务表。下表按任务归属整理成果，代码以合并提交交付；提交账号不等于六名成员各自独立签入，不能据此推断个人提交次数。

本日按统一台账记账 29 点。任务点数不因新增测试、格式整理和文档维护重复累加；刘伟鑫的整合协调计为协助，仍保持当天 0 点分配。未完成的设备验收和功能限制另行保留。

四、AI 技术员分工与协作

AI 辅助围绕当前源码、接口契约、匹配样本和测试记录展开。角色用于说明协作任务，最终业务规则和验收结论仍需成员根据代码与执行证据审核。

先核对样本，再确认“可解释”

初版样本曾将“蓝色耳机”传为黑色色码，虽然测试得到 100 分和四项判据，却没有验证故事中的异色情况。修正输入后，同类 35 分、颜色 0 分、同地点 25 分、时间相近 20 分，合计 80 分；另设真正同色样本验证 100 分分支。

这次修正说明，断言通过首先要建立在输入正确的基础上。页面标签只映射后端返回的命中编码，不能为凑齐四个标签补出“颜色一致”。AI 可以帮助比较数据与断言，但真实色码、计分规则和业务含义必须一起核对。

发布提交后异步生成线索

server/src/main/java/com/shiguang/match/event/MatchRecomputeListener.java 的关键声明为：

@Async(MatchAsyncConfig.MATCH_EXECUTOR)
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT, fallbackExecution = true)
public void onItemPublished(ItemPublishedEvent event) {

发布事务提交后，独立执行器调用 matches.recompute(event.itemId())。若在事务尚未提交时让另一线程查库，新物品可能不可见，导致错误的零线索结果。监听器捕获重算异常并记日志，发布成功不因后续匹配失败而改写。

匹配记录在单独事务中完成候选打分、达阈值更新和旧线索失效。寻物重算只处理该寻物单的记录，招领重算只处理该招领单的记录，避免更新一件招领物品时误使其他候选失效。重复计算保留物品对的唯一关系，原有且仍命中的线索不反复标为新线索。

配置失败回落默认值

server/src/main/java/com/shiguang/match/service/MatchConfigProvider.java 在无法取得有效配置时执行：

if (loaded == null) {
    current = MatchWeights.defaults();
    log.warn("未取到可用的匹配方案，回落到默认权重 {}", current);
    return current;
}

配置表不可读、无生效方案或权重不合法时，都回落默认值并告警。这里不能写成“沿用上一次有效配置”：已被停用的方案若继续使用，会让配置修改与实际计算不一致。目前启动自动加载一次，配置维护后的刷新入口仍需后续接通。

善意值按本人查询，余额与流水共同回读

server/src/main/java/com/shiguang/mine/service/MineService.java 使用只读事务读取余额与分页流水，查询限定 user_id，再按时间和 ID 倒序：

@Transactional(readOnly = true)
public Goodwill goodwill(long userId, int page, int pageSize) {
    int p = Math.max(1, page), size = Math.min(100, Math.max(1, pageSize));
    var overview = overview(userId);
    var result =
            kindness.selectPage(
                    new Page<KindnessRecord>(p, size),
                    new QueryWrapper<KindnessRecord>()
                            .eq("user_id", userId)
                            .orderByDesc("create_time")
                            .orderByDesc("id"));

接口层从当前登录身份提供 userId，客户端不能借查询参数切换到其他用户。流水与认领 ID 使用字符串返回；查询本身不增加善意值，归还事务仍是本阶段验收中的结算来源。

页面请求同时检查身份与顺序

页面采用稳定用户身份和请求序号共同判断响应是否有效。用户 A 的请求返回前若切换为 B，旧结果必须丢弃；如果仍是 A，只是自动重登更换令牌，则不应把正常响应误判成换号。刷新、切换物品或离开页面后，也要避免旧请求覆盖新状态。

匹配列表和流水追加失败时保留已有内容，重试仍请求原失败页；重算期间防止重复触发。个人统计失败明确展示错误，不把请求失败解释成数据库中的零值。零统计只用于真实查询返回零的情况。

协作体会

本阶段最有价值的检查，是把发布样本、计分结果、页面标签和数据库记录串起来。只验证接口返回成功，不能发现色码与标题矛盾；只观察个人中心数字变化，也不能发现重复确认产生两笔流水。AI 的分析需要落到可复测的输入、身份和断言，才能支持完成结论。

五、项目燃尽图

本轮总计 162 点，六名成员各 27 点。D5 记账 29 点，累计记账 122 点，当前剩余 40 点。计划线同期剩余 46 点，实际记账比计划少剩余 6 点。

点数表示既有任务组的记账进展，不替代功能验收。成员当天任务点数记完后，仍需参与交叉复核与缺陷修复；校区匹配、真机操作、配置刷新及 D4 保留差异继续跟踪，不因曲线领先而宣称全部完成。

六、代表性提交与分工关联

功能整合进展

1. 发布与匹配衔接。 发布事务提交后异步生成候选线索，重算失败不改变已成功的发布结果。
2. 分数与判据一致。 匹配页展示真实返回值，异色耳机样本为 80 分、三项命中，同色对照覆盖四项判据。
3. 个人数据真实回读。 个人中心连接本人概览与善意护照，流水页支持分页、刷新和失败重试。
4. 身份与异步结果隔离。 切换账号、切换物品或刷新后拒绝旧响应，同用户自动重登仍能正常完成查询。
5. 归还结果可追溯。 通过多账号联调核对帮助归还次数、善意值与单笔流水，重复确认不重复结算。

七、运行与测试

运行检查结果

本轮覆盖默认后端测试、页面源码回归，以及 MySQL 8 隔离库与 Redis 上的真实 HTTP 主流程。实库检查使用本机 3307 的 shiguang_c_d1_test、6379 的 Redis 和临时 8082 后端，身份为 local 模拟登录，会话使用随机测试前缀。后端默认测试使用 H2 与测试内存会话；页面回归直接执行源码并使用可控异步响应，真实微信登录、真机交互与完整视觉仍待验收。

整理随笔时另行复跑 D5 匹配页面 9 项与个人中心 10 项，19 项全部通过；其余结果沿用本轮已有执行记录。测试结束后已关闭临时后端与本轮启动的 MySQL，保留原 Redis 服务。清理仅针对脚本创建的用户、物品及关联记录，不清空团队库，不执行 Redis FLUSHDB。

问题定位与处理

样本颜色与验收描述不一致。 初版将“蓝色耳机”传入黑色色码，得到四项命中但没有覆盖实际异色情况。修正为真实色码后，类别 35 分、颜色 0 分、地点 25 分、时间 20 分，合计 80 分，判据为 [1,3,4]；另外保留同色对照，验证 100 分与四项判据。标题关键词判据当前未实现。

异步重算可能读不到刚发布的物品。 发布事务尚未提交时，另一线程无法稳定读取新记录。现改为提交后触发异步重算，避免将未提交数据误判为零线索。已有异常注入检查中，重算失败不改变发布成功结果，匹配事务无半成品，移除故障后可手动补算。

重算与配置需要明确边界。 按寻物或招领方向限定失效范围，避免误使其他物品的线索失效；重复重算保持物品对唯一。配置不可读、无生效行或权重不合法时回落默认值并告警，不继续沿用已失效方案。配置维护后的刷新入口仍待接通。

个人统计不能用演示值掩盖查询失败。 概览和善意流水均从当前登录用户的实际记录查询，失败时显示错误，只有真实查询返回零时才展示零统计。流水查询保持只读，归还事务仍负责结算；重复确认后核对余额与单笔流水，避免只看页面数字变化。

换号与自动重登需要分别处理。 用户切换后旧请求不得回填，但同一用户更换令牌后仍应正常显示结果。页面按稳定 userId 判断身份，结合请求序号处理刷新、切换与离开页面；分页失败保留已有内容，重试原失败页。

现有验收仍有边界。 发布链路尚未写入校区字段，校区预筛不能视为已生效；候选上限 200、线索上限 50，无长尾续算。新线索尚无独立阅读回执，相似提醒开关与真实推送未闭环；对侧下架后的线索数量口径仍需对齐。收藏列表、收纳点和设置保留待开放提示，旧数值 ID 的遗留问题继续跟踪。当前未补 D5 真机与完整视觉素材，D4 的独立双向确认和取消等计划差异继续保留。

匹配与个人中心回归清单

八、阶段小结与后续安排

D5 将匹配结果接入页面，并使个人中心能够回读本人真实业务记录。发布后自动生成候选、命中判据可解释、归还后善意值可追溯，三者都有对应测试或联调记录。本日记账 29 点，累计 122 点，剩余 40 点。

本阶段的体会是，真实数据不仅要求接口查库，也要求输入、状态和展示含义一致。异色样本不能展示颜色命中，请求失败不能显示为零统计，令牌变化也不能直接等同于用户切换。把这些边界写入用例与验收说明，才能让功能在反复进入、刷新和多账号操作后仍保持可信。

1. 刘伟鑫协调 D6 首页聚合、接口口径与交付候选版本，整理使用说明和集合随笔入口。
2. 刘传浩继续补设备布局、下拉刷新、长列表与跳转返回的连续操作，修复主流程页面问题。
3. 许毅君推进认证审核、收纳点与必要举报处理，复核权限变化和旧会话影响。
4. 王永臻配合补发布校区、配置刷新与匹配数据一致性，准备最终建库、事务和善意值复验。
5. 李明学维护跨阶段自动化与实库回归，整理测试随笔和共享评审表，分类记录失败、阻塞与未执行项。
6. 许煜煌补真实站会和运行素材，整理固定样本、使用说明、PPT 及演示脚本，开展完整主流程彩排。