目录

一、阶段目标与总体进展

“拾光友人帐”面向校园失物招领场景。D1 以“收敛与骨架”为目标：复用已有数据层、身份层和小程序页面，统一工程基线、接口契约和运行配置，为后续业务开发建立共同基础。

现有工程中，前端页面、身份模块和数据库脚本分别已有积累，但分支、接口路径和环境配置尚未完全统一。此次工作的重点是梳理这些已有成果的依赖关系：页面通过公共请求层调用接口，身份模块提供当前用户和权限，数据层负责约束与初始化，集成环境则保证各部分能够在同一版本下运行。

工程整合采用复用已有成果的方式推进。数据层保留 21 表模型及验收工具，后端以 com.shiguang 为统一包结构，小程序保留可用的页面与样式。前后端通过 /api/v1 契约衔接，减少后续开发中重复定义字段、重复封装请求和反复调整配置的问题。

二、站会安排

站会重点围绕工程基线、环境准备和接口依赖展开。交流内容按“负责什么、已经具备什么、还缺少什么、需要谁配合”整理，优先暴露会影响其他成员开工的依赖。工程集成与数据初始化是后端工作的前置条件，接口契约与页面入口则是前端对接的前置条件。

协调工作围绕共同验收入口展开：后端能启动、数据库能初始化、小程序能打开首页，身份请求有明确的响应。在这些基础条件具备后，再逐项核对接口和页面状态，避免各模块独立可运行却无法组合。

讨论事项

1. 先统一字段和调用方式。 接口契约明确路径、入参、出参及错误码，公共请求层集中处理令牌及错误。
2. 先明确身份与权限。 未登录、未认证、已认证用户与管理员的权限分开，身份模块与现有表结构保持一致。
3. 数据脚本与工程同步。 统一采用 21 表模型，表结构变更回写 DDL，已有库升级与空库初始化分别验证。
4. 测试随开发推进。 开发者完成本模块自测，李明学组织跨模块检查，故障与未执行用例分别记录。
5. 先形成可运行基线。 以数据库初始化、后端健康检查、登录基础链路和小程序首页作为共同验收入口。

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

刘伟鑫、许毅君、王永臻负责工程集成、身份权限和数据基础；刘传浩、李明学、许煜煌负责页面骨架、接口对接和运行验收。

首日合计完成 18 点。

六人的交接围绕具体产物展开。工程侧提供目录、配置和启动入口，数据侧提供建库命令与检查结果，身份侧提供登录及权限约定；接口侧据此维护调用方式，页面侧验证入口与状态，验收侧记录环境、版本和操作结果。涉及公共字段或接口路径的调整先同步契约，再由页面和测试共同核对。

目前的主要困难集中在已有成果的衔接：工程历史不同、接口命名不一致、本机依赖版本存在差异。对应的处理方向是减少配置分散、固定调用规范，并将启动日志、接口响应和数据库检查结合起来定位问题。

四、AI 技术员分工与协作

AI 技术员围绕工程收敛、接口对齐、基础测试和文档整理提供辅助。协作输入以现有仓库、表结构、接口约定、原型及实际错误信息为基础，模块负责人负责判断建议是否适合当前工程，并将采用的内容落实到代码、契约或验收记录中。

协作过程与任务衔接

工程方案梳理。 AI 设计师围绕“哪些成果继续使用、哪些入口需要统一”组织分析，将数据模型、身份服务和小程序页面之间的关系展开。成员审核时重点检查是否引入第二套表模型、是否存在重复的登录入口，以及统一包名、端口和接口前缀后能否形成完整调用关系。工程整合以已有成果为基础，避免只调整目录而遗漏配置和接口差异。

实现建议审核。 AI 程序员提供的候选修改需要结合仓库现状判断。数据相关内容对照 DDL 和实体核对，接口相关内容对照契约核对，页面相关内容对照原型及实际导航检查。配置修改还要关注启动目录、JDK 和依赖服务，保证建议能够在本机环境中执行。涉及数据库的操作先明确目标库与影响范围，再进入隔离环境验证。

测试反馈回流。 AI 测试员将问题拆成可观察的现象和可执行的检查步骤。例如登录失败时，先区分网络不可达、后端错误、数据库异常和会话存储异常，再根据状态码与日志继续定位。测试反馈回到相应负责人：契约差异交给接口侧，权限问题交给身份侧，数据约束问题交给数据侧，页面入口问题交给前端侧，修复后沿原步骤复测。

文档与产物同步。 AI 文档助手把分散的讨论和命令整理成统一结构，负责人补充实际结果及仍存在的问题。文档中的接口路径、环境版本和操作顺序与工程保持一致；测试结果区分已验证与待验证，页面截图与实际运行版本对应，便于其他成员复现。

下面摘录 server/src/main/java/com/shiguang/security/AuthInterceptor.java 的请求入口校验，展示公共接口放行与受保护接口检查的衔接方式。

if (isPublic(request)) {
    return true;
}
String header = request.getHeader("Authorization");
if (header == null || !header.startsWith("Bearer ") || header.length() > 4096) {
    throw ApiException.unauthorized();
}

这段代码先区分公开接口，再检查 Bearer 请求头；后续逻辑继续核对令牌、账户、会话和权限。许毅君负责服务端鉴权边界，李明学据此核对请求层携带令牌及错误反馈，许煜煌整理未登录与会话失效的复测步骤。

运行配置与数据库初始化边界

源码位置：server/src/main/resources/application.yml。以下为当前仓库实现节选。

server:
  address: 127.0.0.1
  port: 8081
  error:
    include-message: never
    include-stacktrace: never

工程统一使用本机 8081 端口，并关闭响应中的内部异常信息。刘伟鑫维护启动配置，李明学核对小程序服务地址，许煜煌据此编写启动与健康检查步骤。配置中的 spring.sql.init.mode: never 同时明确：建库与升级由数据库脚本管理，不能把“应用成功启动”当作“数据库结构已自动更新”。王永臻负责核对初始化脚本及目标库。

公共请求头与身份信息传递

源码位置：miniprogram/api/request.js。以下为当前仓库实现节选。

const header = { 'Content-Type': 'application/json', ...headers };
const token = wx.getStorageSync('token');
if (token) {
  header['Authorization'] = `Bearer ${token}`;
}

请求层统一合并 JSON 请求头、自定义请求头和本地令牌，业务页面可以通过 headers 传入幂等键。李明学负责封装与契约一致性，许毅君核对 Bearer 格式，刘传浩负责页面调用。该片段展示令牌如何附加；过期令牌的错误码识别仍按问题清单继续完善，不能仅凭请求头存在就认定身份链路已闭合。

Redis 会话保存与过期管理

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

@Override
public void create(AuthSession session, String refreshHash) {
    try {
        redis.execute(
                CREATE,
                List.of(
                        sessionKey(session.id()),
                        tokenKey(refreshHash),
                        userKey(session.userId())),
                json.writeValueAsString(session),
                session.id(),
                epoch(session));
    } catch (JsonProcessingException exception) {
        throw new IllegalStateException("Cannot serialize session");
    }
}

会话创建将会话键、刷新令牌键及用户会话集合交给 CREATE 脚本处理，同时传入序列化会话与到期时间。脚本中的写入和过期设置由一次 Redis 脚本调用组织执行，减少多个独立请求之间的状态不一致。许毅君核对会话生命周期，刘伟鑫核对 Redis 依赖与运行环境，许煜煌补充登录后会话存在、到期与退出撤销的检查。序列化失败会转为明确异常，Redis 连接及持久化故障仍需要结合实际日志排查。

典型协作内容

协作体会

AI 对梳理分散材料、补充异常场景和形成排查步骤帮助较大，尤其适合在工程整合时快速列出需要对照的配置与接口。但最终判断仍依赖仓库和运行证据：建议中的字段必须在表结构中存在，接口必须有对应实现，测试结论必须能由实际结果支持。

成员在协作中承担明确的审核职责，而不是直接接受整段输出。设计建议经过依赖检查，实现建议经过代码核对，测试建议落实为可执行步骤，文档再根据实际结果更新。输入材料避开密码、令牌和用户核验信息，保留定位问题所需的版本、状态码与错误类型。

五、项目燃尽图

本轮共 162 点，六名成员各 27 点。D1 完成 18 点，实际剩余 144 点；计划线同期剩余 139 点，实际比计划多剩余 5 点。

第一天主要完成工程、规范、数据和测试基础，实际进度比计划少完成 5 点。页面骨架仍处于准备阶段，尚未达到验收标准，因此没有提前计入完成点数。

后续重点是把已有工程、接口和数据串联成可重复运行的基线，减少环境问题对联调的影响，并继续按任务验收结果记录实际完成量。

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

工程整合进展

10 月 24 日，D1 工程成果继续完成整合，主要进展如下。

1. 工程基线收敛。 保留 com.shiguang 后端与 21 表数据模型，导入小程序前端；统一主干为 master。
2. 契约与配置统一。 后端统一使用 8081 端口、/api/v1 前缀；前端 API 模块按 v1 契约对齐，接口表区分已实现与待实现。
3. 页面基线补齐。 首页和公共导航按原型重建，使用演示数据呈现页面结构。
4. 身份与数据衔接。 身份模块复用现有用户和认证表；数据库继续采用脚本初始化和升级，应用启动不擅自重建表。
5. 验收路径明确。 验收手册给出数据库检查、后端启动、健康检查和小程序打开步骤；本地演示与真实微信认证分别记录。

七、运行与测试

7.1 运行检查结果

10 月 24—25 日围绕 D1 基础能力进行补充检查，覆盖数据库、服务启动、会话依赖和小程序页面。数据库检查使用独立测试库，后端使用本地演示模式，页面检查通过微信开发者工具模拟器执行。

补充检查时，GET http://127.0.0.1:8081/api/v1/health 返回 HTTP 200，以下保留业务响应字段：

{
  "code": "0",
  "message": "ok",
  "data": {
    "status": "UP",
    "identityMode": "SIMULATED"
  }
}

status: UP 表示服务健康入口可响应，identityMode: SIMULATED 表示本轮使用模拟身份模式。该结果与页面截图共同说明基础运行入口可用，登录、认证及具体业务仍按各自用例检查。

7.2 环境问题与处理

登录排查从接口响应入手：小程序页面能够打开，后端健康接口也能返回，但登录请求仍出现会话存储异常。进一步核对本机服务版本后，确认原 Redis 3.0 与项目要求不符。更新为 Redis 8.10.2 后，登录请求恢复正常，说明页面和后端进程可用并不代表会话依赖已经满足。

继续运行后，Redis 又因无法覆盖快照文件而触发写入保护。日志显示临时快照已生成，但替换目标文件时出现权限错误，问题集中在数据目录的服务账号权限。修正权限后，同步保存与后台保存均通过，随后再次检查演示登录，接口返回 200 并成功取得令牌。

此次排查覆盖了进程启动、数据库连接、会话存储和持久化权限。通过分别检查健康接口、Redis 响应、保存日志和登录结果，将环境兼容问题与业务代码问题区分开，也为后续成员复现运行环境提供了更完整的步骤。

7.3 基础回归清单

八、阶段小结与后续安排

10 月 23 日完成 18 点、剩余 144 点，主要是工程、规范、数据和验收准备。后续围绕“收敛与骨架”目标，持续完善统一主干、接口契约、页面基线和运行验证。

这阶段最明显的收获是把模块成果转化为共同使用的工程基础：数据模型有统一脚本，身份模块有明确入口，前端调用有契约依据，运行检查有可复现步骤。困难则主要来自历史工程差异和本机环境依赖，后续需要在交接时同步配置、版本与验证结果，减少重复排查。

1. 刘伟鑫维护统一工程基线和环境配置，协调集成问题。
2. 刘传浩核对首页、页面骨架及公共导航的实际运行效果。
3. 许毅君继续检查登录、认证和会话失效的权限边界。
4. 王永臻维护建库与升级脚本，保留隔离库验收结果。
5. 李明学复核契约与请求封装，整理基础接口问题及复测记录。
6. 许煜煌完善验收清单，整理站会照片、运行素材与操作说明。