目录

一、阶段目标与总体进展

在工程骨架、身份模块和数据模型完成整合的基础上，D2 将重点转向发布主链路：用户选择寻物或招领类型，填写物品信息，保存草稿或提交发布，由后端生成编号、写入数据，再通过列表展示结果。

发布链路同时涉及页面、身份、图片、数据与反馈。页面需要采集类别、地点、时间和描述；身份模块判断用户是否具备发布权限；后端决定编号、初始状态和记录归属；公共请求层负责传递令牌与幂等键。任何一处字段或状态不一致，都可能表现为发布失败、列表为空或跳转后找不到刚提交的信息。

本阶段围绕现有 21 表模型进行增量开发，发布与草稿分别使用 t_item、t_draft，没有另外引入单表业务模型。仓库已提交发布服务、编号生成、幂等处理、草稿接口、图片上传以及列表查询，前端同步接入发布表单和招领列表。后续检查仍发现本人发布入口、草稿恢复和上传限制等问题，完整验收继续推进。

二、站会安排

站会安排围绕发布链路的交接依赖展开。前端需要明确哪些字段必填、字典传什么值、时间使用什么格式；后端需要明确记录归属、初始状态和重复请求的处理方式；验收侧则关注用户能否从打开表单一直走到看到发布结果。

联调以同一份字段契约为依据，页面传字典 code，展示时转换为对应文案。图片上传、草稿保存与正式发布分别记录请求和结果，避免把上传成功当作发布成功，或者将草稿写入公开物品列表。

讨论事项

1. 两类发布共用一套数据入口。 寻物与招领统一调用 POST /api/v1/items，通过 itemType 区分，减少页面与服务重复实现。
2. 编号与状态由服务端决定。 前端提交物品信息，后端生成 LOST-MMDD-NNN 或 FOUND-MMDD-NNN；寻物初始为“寻找中”，招领初始为“待认领”。
3. 草稿与正式记录分开。 草稿按当前用户保存，正式发布时才生成物品记录；重新进入表单时需要恢复类型、字段与开关。
4. 错误必须能反馈给用户。 未登录、未认证、上传失败和打开页面失败分别给出提示，避免用户点击后无法判断是否生效。
5. 发布与展示连续检查。 提交成功后继续核对落库、列表刷新和分类；本人发布列表及详情等未闭合环节单独跟踪。

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

后端与数据任务由刘伟鑫、许毅君、王永臻分别承担集成环境、身份授权和持久化规则；前端与联调任务由刘传浩、李明学、许煜煌分别承担页面实现、接口对接和交互验收。跨前后端的发布问题按请求、服务和页面反馈共同定位。

六人的协作围绕一条请求展开：页面侧准备输入与操作步骤，接口侧检查实际请求，身份侧核对用户权限，数据侧核对写入结果，集成侧保证依赖可用，验收侧检查操作结果能否被用户理解。反馈尽量落到具体字段、请求或页面状态，减少笼统的“发布不了”“没有显示”。

四、AI 技术员分工与协作

AI 技术员的辅助重点从工程结构转向发布流程。输入材料包括现有接口契约、发布 DTO、表结构、页面代码与错误现象；输出主要用于梳理调用顺序、定位字段差异、补充异常用例和整理复测记录，采用前由对应负责人核对。

协作过程与任务衔接

发布流程分析。 AI 设计师按“选择类型—填写字段—选择照片—登录与认证—提交—查看结果”展开流程，同时保留独立的存稿分支。成员核对时重点检查表单字段是否能映射到既有模型、登录权限是否在服务端落实，以及上传成功和正式发布成功是否有清晰区别。

数据规则核对。 AI 程序员辅助对照请求字段与 t_item 的约束。颜色在页面为可选项，而数据列不能为空，当前实现使用字典中的“其他”作为缺省值；物品编号、当前用户与初始状态由服务端设置。编号冲突、幂等回放和失败释放则结合已有测试检查，避免只覆盖正常插入。

页面问题分析。 对于“按钮点击后没有反应”“底部操作栏被遮挡”等现象，分析范围同时覆盖页面路由、tabBar 配置、导航 API 与布局。发布页改为二级页面后，入口使用对应的跳转方式，失败时增加明确提示；验收侧继续核对表单是否能够滚动、返回和提交，而不是只看静态截图。

测试与文档反馈。 AI 测试员将成功、失败和边界情况拆成可重复操作步骤，文档助手再整理到问题记录中。接口存在、单元测试通过和完整模拟器链路通过分别记录；对于尚未完成的本人发布列表、草稿完整恢复等环节，保留具体问题和下一步验证方向。

下面摘录 server/src/main/java/com/shiguang/item/service/ItemService.java 中 buildItem 的字段组装逻辑，展示表单与持久化规则的对应关系。

item.itemType = request.itemType();
item.title = request.title().trim();
item.category = request.category();
// 颜色在原型里是可选字段，但 t_item.color 是 NOT NULL；
// 缺省记为字典里的「其他(10)」，避免可选项把整条发布打挂
item.color = (request.color() == null || request.color().isBlank())
        ? DEFAULT_COLOR : request.color();
item.place = request.place();
item.occurTime = request.occurTime();
item.detail = request.detail();
item.status = request.itemType() == TYPE_LOST ? STATUS_SEEKING : STATUS_PENDING_CLAIM;
item.userId = userId;
item.anonymous = request.anonymous() == null ? 0 : request.anonymous();
item.notifySimilar = request.notifySimilar() == null ? 1 : request.notifySimilar();
item.coverUrl = firstPhoto(request.photoUrls());
item.photoUrls = writeJson(request.photoUrls() == null ? List.of() : request.photoUrls());

类型来自表单选择，初始状态由服务端按类型确定，发布用户来自当前登录上下文；颜色、匿名与相似提醒具有明确的缺省值，首张照片作为封面。刘传浩与李明学核对页面字段和请求数据，王永臻检查默认值及落库规则，许毅君检查用户身份来源，许煜煌据此整理两类发布和可选字段的回归用例。编号生成、幂等处理与正式写入在后续流程中完成，字段组装本身不代表事务与并发验证已通过。

发布请求的幂等入口

源码位置：server/src/main/java/com/shiguang/item/service/ItemService.java。以下为当前仓库实现节选。

boolean idempotent = idempotencyKey != null && !idempotencyKey.isBlank();
if (idempotent) {
    // api_code 受列宽 16 限制，用设计文档里的接口编号；request_hash 用于识别「同 key 不同体」
    boolean first = idempotency.tryAcquire(
            userId, idempotencyKey, "API-07", md5(fingerprint(request)));
    if (!first) {
        return idempotency.replay(userId, idempotencyKey)
                .map(this::readCreated)
                .orElseThrow(() -> ApiException.conflict("重复请求，已忽略"));
    }
}

客户端提供幂等键时，服务端以当前用户、接口编号和请求指纹申请占位；重复请求进入结果回放，暂时没有可回放结果时返回冲突。王永臻负责幂等与数据写入规则，李明学核对请求头，刘传浩配合提交中状态减少重复点击。当前实现允许不带幂等键的请求，因此调用方是否稳定携带同一重试键也属于验收范围。

编号冲突的有限重试

源码位置：server/src/main/java/com/shiguang/item/service/ItemService.java。以下为当前仓库实现节选。

private void insertWithRetry(Item item) {
    LocalDate today = LocalDate.now();
    for (int attempt = 1; attempt <= MAX_NO_RETRY; attempt++) {
        long next = noGenerator.currentSequence(itemMapper, item.itemType, today) + attempt;
        item.itemNo = noGenerator.format(item.itemType, today, next);
        try {
            itemMapper.insert(item);
            return;
        } catch (DuplicateKeyException ignored) {
            // 并发下算出了同一个号，换下一个序号重试
        }
    }
    throw ApiException.conflict("编号生成冲突，请稍后重试");
}

编号在服务端按类型与日期生成，插入遇到唯一键冲突后尝试下一个序号，超过上限返回可识别的冲突信息。王永臻核对编号与唯一约束，刘伟鑫保障联调数据库可用，许煜煌整理冲突与失败重试用例。代码捕获的是 DuplicateKeyException，实际并发验收还需确认冲突来源及事务行为，不能把有限重试机制等同于并发验证完成。

重复请求不重复写入的测试断言

源码位置：server/src/test/java/com/shiguang/item/service/ItemServiceTest.java。以下为当前仓库实现节选。

@Test
@DisplayName("重复的 Idempotency-Key 回放首次结果，不再落库")
void replaysIdempotentRequest() {
    when(idempotency.tryAcquire(eq(3L), eq("key-2"), eq("API-07"), anyString())).thenReturn(false);
    when(idempotency.replay(3L, "key-2"))
            .thenReturn(Optional.of("{\"id\":11,\"itemNo\":\"FOUND-1024-003\",\"status\":1}"));

    ItemCreated created = service.create(request(2, "蓝杯"), 3L, "key-2");

    assertEquals(11L, created.id());
    assertEquals("FOUND-1024-003", created.itemNo());
    verify(itemMapper, never()).insert(any(Item.class));
}

测试预设幂等占位已存在，并返回第一次发布的结果；断言既检查返回编号，也通过 never() 确认没有再次调用插入。李明学负责核对接口预期，王永臻复核数据行为，许煜煌把这一规则转成重复点击与网络重试的页面用例。这里使用 Mock，验证的是服务分支；真实数据库唯一约束、事务及 Redis 依赖仍须通过联调补充验证。

典型协作内容

协作体会

AI 对跨文件核对和异常分支梳理帮助较大。发布问题经常同时涉及表单、身份、接口、数据库和列表，先把依赖与字段对应关系展开，比只在页面上反复尝试更容易缩小范围。

实际使用中仍需要人工确认约束是否生效。例如幂等服务存在，不代表实库并发已经验证；页面有草稿入口，也不代表所有字段都能恢复。成员根据仓库代码、测试结果和页面观察共同判断完成状态，采用的建议落实到具体修改与复测步骤，避免把分析建议直接写成已完成成果。

五、项目燃尽图

本轮总计 162 点，六名成员各 27 点。D1 完成 18 点、剩余 144 点；D2 记账 18 点，累计完成 36 点，实际剩余 126 点。计划线同期剩余 116 点，实际比计划多剩余 10 点。

点数按统一任务台账换算，功能验收继续按当前实现逐项检查。T07 中的详情、T08 中的收纳点授权和 T09 中的 Outbox 联动尚未完整落地，相关任务组仍有待闭合子项。当前发布、列表和草稿已有代码基础，本人发布入口、完整恢复与异常边界继续完善。

与 D1 相比，工作已从基础建设推进到真实接口和数据写入。后续优先收敛影响用户完成流程的缺陷，补齐验证记录，减少因环境、字段和页面反馈不一致造成的重复排查。

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

功能整合进展

1. 发布入口落地。 寻物与招领共用发布接口，DTO 校验标题、类别、地点、时间、开关及图片数量；服务端写入当前用户、编号和初始状态。
2. 草稿独立保存。 草稿接口按当前用户保存或读取一份 payload，正式物品与草稿分表存储；页面已接入保存和读取。
3. 图片与列表接入。 图片经本地上传获得相对路径，列表返回统一分页结构，页面按字典显示地点与类别。
4. 身份入口衔接。 小程序增加演示登录及校园认证入口，认证成功后重新登录取得对应权限；真实身份服务仍需独立验证。
5. 交互问题持续修复。 发布页调整为二级页，配套修改导航和提交栏；针对图片兜底、分类跳转、列表刷新和失败提示进行迭代。

七、运行与测试

7.1 运行检查结果

10 月 24 日提交发布与配套代码，10 月 25 日继续开展本机检查和补充修复。已有检查覆盖构建、登录、公开列表、权限响应和部分页面操作，尚未完成两类发布、图片、草稿及本人列表的完整模拟器验收。

7.2 问题定位与处理

提交栏与导航冲突。 自定义 tabBar 曾遮挡底部按钮并影响页面滚动。仓库调整了发布页层级与导航方式，同时补充失败兜底提示。后续检查需要覆盖不同入口进入发布页、返回以及底部按钮操作，防止配置更新与缓存页面不一致。

表单可选值与数据约束不一致。 颜色在表单中可不选，但数据库字段不能为空。当前服务将未选择颜色映射为“其他”，避免可选项影响整条发布；类似默认值仍需在 DTO、页面和数据库之间保持一致。

列表看似无数据。 10 月 25 日补充修复针对 undefined 被序列化为筛选值的问题，前端按需传参，后端清理缺省值，并补充测试。该修复后本机列表接口返回 7 条记录，但列表返回成功仍不等同于本人发布入口已经完成。

草稿和登录状态仍有缺口。 定向源码检查显示，草稿恢复未完整恢复类型与匿名开关；请求层尚未统一识别实际的 40101，过期 token 可能持续保留。招领页已缓存时，也存在发布后未消费目标分类的情况，需要分别修复并补模拟器复测。

上传限制需要统一。 页面按单图 10MB 处理，而上传控制器仍限制 5MB；当前实现主要按扩展名筛选格式，实际文件内容校验还需补充。图片持久化已采用本地目录与相对路径，后续重点检查大小边界、失败提示及更换服务地址后的展示。

本人发布与后续联动待完善。 /me/items 接口已经存在，但“我的发布与草稿”目前仍打开发布表单；详情接口、收纳点授权及发布后的 Outbox 联动未形成完整实现。后续按照实际接口和页面补齐，不以菜单入口或表实体代替功能验收。

7.3 发布回归清单

八、阶段小结与后续安排

D2 完成发布主链路及配套接口的主要代码提交，开发重点从“工程可运行”转向“输入能够被服务接收、保存并展示”。本日按任务表记账 18 点，累计完成 36 点、剩余 126 点，完整验收仍有待补齐环节。

本阶段的主要体会是，链路是否顺畅取决于多个模块能否连续配合：表单字段需要满足数据约束，认证状态需要转换为有效权限，成功响应需要落到正确分类和本人记录，错误也需要有明确反馈。单个接口或页面完成后，仍要沿用户操作继续检查。

1. 刘伟鑫继续核对启动入口和配置读取，维护可重复使用的联调环境。
2. 刘传浩完善发布页交互，补齐本人发布列表入口并检查发布后的连续操作。
3. 许毅君统一登录失效处理，复核认证后权限与本人草稿边界。
4. 王永臻补实库幂等、失败回滚和数据归属检查，继续完善后续事件联动。
5. 李明学修正草稿完整恢复、列表参数和缓存分类刷新，维护接口与页面一致性。
6. 许煜煌完成两类发布、图片和草稿的模拟器回归，整理运行素材及缺陷复测结果。