2026年09月工作日报 📌

这里按天记录工作内容、遇到的问题和当天的一点想法，方便月底回看。

2026/09/15 今天做了啥？ ✨

今天主要是在把 5 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成美容美体题库导入链路排查与热修提交，确认问题是 CP 对新工作表展示名识别不足、后端又要求覆盖旧根场景；已保留未知 key、重复 key 和 sceneId 不匹配的拦截，并将后端与 CP 的最小改动推送到热修分支。
定位预发导入 500 的根因，确认热修代码已部署，但数据库缺少 scene_tree_head 等场景树迁移表；故障发生在首次查表阶段，尚未进入删旧题库或写新题库，原有 68 题未被覆盖。Excel 解析预览已通过，覆盖范围为 32 个场景、27 个叶子场景、150 题。
完成正式生题失败分型：任务 47 的容量拒绝、任务 48 的 CONTEXT_SCHEMA_INVALID 已分别收敛。后者落在 questions.claimRefs 的结构化结果校验，相关 Schema/提示词的最小基线测试 16 条通过；同时识别出通用修复提示混入正式链路规则的回归风险，暂未合入。
梳理 QA-SC 任务 51 的执行状态和并发来源，确认任务不是卡死，而是单 Pod、实际并发 1 下按机会项串行执行；最终已进入 pending_review，不能据此误判为全成功。进一步确认基准 QA 的配置值 4 并未作用于 QA-SC 项目运行 Pod，配置源需要按项目环境重新对齐。
完成多仓未提交改动审计与分支基线整理，确认 72 个改动属于不同主题，不能整包提交；合并三个独立仓的最新 master 时已处理冲突并完成后端全 Reactor 编译，保留各仓原有未提交改动的边界。

🧩 困难/需要帮助

预发确认覆盖导入前，仍需确认 V37、V38 场景树迁移已按顺序落库，并回读 scene_tree_head、scene_tree_revision 等表；目前只能确认解析校验通过，不能确认安全导入。
QA-SC 并发配置需要在项目级 SCM/运行实例重新核对并经滚动重建生效；不宜直接把长 Agent SDK 会话并发调到 10。
正式生题的 claimRefs 修复需要把正式链路专属提示与通用 analysis 修复提示拆开，再进行最小提交和回归验证。

💭 感想

今天主要是在把题库导入和正式生题两个问题从“页面现象”往真实的代码、数据迁移和运行配置上收敛。预览通过、Pod Ready、任务待审核都只是阶段信号，真正可放行仍要把迁移、配置来源和最终业务回读逐项补齐。

2026/09/16 今天做了啥？ ✨

今天主要是在把 6 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成题库画像主链升级，新增 qb-core-202609-v2 并切换生题链路；正式题目支持 customer_persona，兼容旧三项空画像与新四项解析，只投影当前机会绑定的唯一画像，旧版 v1 保持不变。
完成画像链路定向验证，165 项测试全部通过；全量基线为 2559 通过、124 跳过，69 个失败均收敛到旧 /draft 断言、过期 direct-context 契约和日志捕获，未混入本次验收。
对齐画像发布依赖，确认 applied_persona_id 必须先落库，发布顺序固定为“DDL → AI v2（兼容旧任务）→ Knowledge 写四项”，避免新链路早于数据结构启用。
收口商家经营助手方案与 Buzzy 项目材料，明确“Supervisor → 专项 Agent → Domain Skills → Business CLI → 经营系统/联网信息源”分层，补齐业务流程、任务路由和职责边界，避免把工具层误写成 Agent 或虚构底层实现。
补全 CLI 场景化回归评测口径，固定“CLI 变更 → 飞书评测机器人 → 经营场景矩阵 → Dubbo 重复调用 → 结构化结论”链路；指标聚焦关键断言一致率、场景覆盖和跨场景兼容风险。
整理并锁定 Buzzy 主线简历材料，移除 KFC/点餐残留；主简历 15 条亮点均满足字数限制，成品已设为不可变保护。

🧩 困难/需要帮助

画像上线前仍需 DBA 确认并落地 applied_persona_id 列，才能按既定顺序启用新链路。
AI 仓全量基线仍有 69 个既存失败，需要与本次画像变更分开治理，避免验收口径混淆。
微信工作群正文尚未形成可可靠引用的工作证据，本次不据此补充具体群消息。

💭 感想

今天主要是在把画像生题、发布依赖和经营助手材料都往真实代码链路与可验证口径上收敛。画像功能已经完成兼容与定向验证，后续关键是守住 DDL 前置和历史基线噪音的边界。

2026/09/17 今天做了啥？ ✨

今天主要是在把 7 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成“题目治理→历史资料”在 Knowledge 与 CP 的 QA-SC 交付，补齐商家/文件名分页、资料历史、分析批次、独立问题与生成题目三类明细，并冻结资料版本和历史统计；发布后接口验证通过，浏览器端到端验收待补。
完成客户画像同步故障修复与真实回归，补齐 backend 与 QA March 的缺失 Key；同时对齐正式生题按冻结画像逐一判定、每个适用画像产出一题，并将 appliedPersonaId 下沉到题目。
推进任务 53 的正式生题排查，9 个独立问题中 7 个成功生成 29 道待审核题；已收敛 2 个失败项，其中一项为 DIRECT_SESSION_TIMEOUT，约 600 秒后终止。
定位商家后台“操作过于频繁”根因，滑块验证已通过，实际由上游 uic-captcha 的短信限频返回错误码 135900005，排除 PC 前端、backend 与 knowledge 的业务限流。
修复本地正式生题的 INVALID_PARAM 启动边界，补齐运行模式与操作人身份配置后恢复请求发起；问题不在题目生成参数本身，而在本地身份上下文不完整。
完成题目驳回重生的基础事务与幂等回执能力，重复驳回返回原回执；专项 7 项、旧链路 51 项及 AI 原基线 83 项验证通过，完整快照、重生任务和前台交互仍需继续补齐。
完成话术范例库草稿，沉淀 9 个行业共 180 条题目，并明确行业→场景两层路由、每场景最多 5 题、缺题不跨行业凑数以及读取失败/重试/审计规则；当前尚未接入正式生题主链。

🧩 困难/需要帮助

任务 53 仍有 2 个独立问题失败，已证实一项为 DIRECT_SESSION_TIMEOUT；需要继续确认另一项根因，并收敛超时重试与补偿边界。
历史资料接口已完成发布验证，但本机浏览器端到端访问曾超时；需要在可达 QA 链路补齐前端完整验收。
话术范例库仍是本地草稿，需要继续明确生产接入范围、版本冻结与 Good/Bad Case 治理节奏。

💭 感想

今天主要是在把题库治理从页面状态收敛到真实历史证据、冻结版本和发布接口，同时把登录、生题与短信限制问题下钻到上游服务和运行身份边界。主链方向已经比较明确，但任务超时、QA 前端可达性和范例库生产接入还需要继续按可回放、可验证的边界推进。

2026/09/21 今天做了啥？ ✨

今天主要是在把 6 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成正式生题任务 62（run 3810）逐项失败分析，确认 10 条机会均未进入 pending_review：7 条约 600 秒触发 DIRECT_SESSION_TIMEOUT、2 条约 552 秒触发 SDK_TIMEOUT、1 条因 CONTEXT_INVALID 被验收拦截；问题不是单一汇总状态能解释的“全部失败”。
梳理正式生题容量链路，确认不同 Context 会直接并发启动长耗时执行会话，缺少全局与 Pod 级背压；大批量提交会把会话同时压入同一运行单元，后续应按持久化任务、全局准入和已验证速率出队，而不是继续放大并发。
对齐 QA-SC 路由与配置时序，确认任务 62 经内部兼容网关访问 doubao-seed-2-1-pro，不能简单归因为协议不兼容；配置更新不会动态刷新已启动服务，run 3812 与截图请求的路由、Trace 时序仍需逐条闭环。
梳理“上传资料—分析会话 A—确认独立问题—正式生题会话 B”边界：上传不启动执行会话，B 不复用 A 的原始记录，而是读取已持久化的分析和证据后重新冻结 Context，明确了两段链路的输入与可复现口径。
完成题库资料分析页交互修复：修正主按钮文字被样式缓存覆盖的问题，阻断勾选历史资料后自动跳转“结果查看”，并增加“全选本页/取消本页”且保留跨页选择；契约测试 51/51 通过。
完成微店 AI 副店长的简历与方案材料梳理，明确调价安全闭环属于当前可支撑的能力，ERP 和真实电商接入仍是规划；评测指标统一按受控 Mock 口径表达，避免把方案写成线上事实。

🧩 困难/需要帮助

正式生题的安全并发阈值仍缺网关性能、CPU、数据库连接等运行指标，当前不能把瓶颈直接定责给单一运行单元或上游服务。
run 3812、网关路由与 Trace 的时间关系尚未逐条对齐，需要补齐同一请求的链路证据后再判断配置是否生效。
全局准入和排队策略还需结合持久化任务的重试、租约和发布验证进一步确认，避免“忙碌”状态被误记为“生成中”。

💭 感想

今天主要是在把正式生题从“任务失败/执行慢”的笼统描述，收敛到逐机会超时、无背压准入和配置时序三层事实。页面交互和双会话职责也落到了可验证的规则上；方向已经明确，但容量阈值和路由证据还需要继续补齐。

2026/09/22 今天做了啥？ ✨

今天主要是在把 6 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成正式生题任务 67 的机会级复盘，确认 10 个独立问题均已终态、未产出待审核题；失败拆分为 6 条执行超时（含 DIRECT_SESSION_TIMEOUT、SDK_TIMEOUT）和 4 条结果校验拦截，避免再把 completedOpportunityCount 当成成功数。
推进正式生题 V5 收敛，服务端一次性组装冻结 ContextPack，模型改为单次结构化生成，不再在会话内逐个读取 Skill 或无限修复；引用改由 evidenceRef 回填冻结证据。任务 68 现场验证后，已将 max_turns 从 1 调整为 2，避免正常结构化终态被内部回合上限误杀。
补齐正式生题 SDK 可观测链路，记录 capacity_wait_ms、context/task/opportunity/attempt 关联和 session_key；同时确认旧 asset trace 只是组包审计，不能当作 SDK 调用，为后续区分排队、单次生成与校验耗时建立口径。
定位 CP 创建正式生题时的 400 包装链路，确认 Tether 到上游 Dubbo Provider 超时后返回纯文本 context deadline exceeded，CP 的 dubbo_invoke.js 将其按 JSON 解析才形成 400；当前进一步收敛到 wakeDispatch 在 Dubbo 请求线程逐条等待 Python 异步受理回执，而非 Node 自身超时。
完成“资料→独立问题→题库”技术链路及应用边界梳理：当前可用入口为 sellai-train-cp-admin，经 sellai-train-knowledge、sellai-train-ai 到 sellai-train-backend；商家后台的生题/审核代码尚未挂总路由，小程序 BFF 不参与该链路。
梳理 QA-SC 到 Prod 的发布范围，明确不复制 QA 业务数据；Question Case 最小主链只涉及 question_case 新表和 question 的 4 个围栏字段，Prod 还需按当前代码逐项补齐 SCM 与资源前置。

🧩 困难/需要帮助

任务 68 在新路径已生效时仍出现 SDK_MAX_TURNS_EXCEEDED；max_turns 已调整，但尚无本轮完整候选题落库成功证据，新增黑盒回归也受本机缺少 pytest 入口限制，需在项目环境验证。
当前 Backend migration 存在 V37/V38/V39 同号文件冲突，不能全量自动执行；需按确认功能拆成显式 DDL、逐表回读，并补齐首发保持关闭的 SCM 开关、AI 预算、cursor keyring 与最小 DB 权限。
CP 400 目前只证明到 Tether/Provider deadline；仍需用同一请求的 CP URL、耗时与 TraceId 关联 Provider 记录，才能判定究竟慢在受理、Provider 还是下游依赖。

💭 感想

今天主要是在把正式生题从“生成慢、任务失败”的笼统现象，收敛到机会级终态、会话回合和冻结上下文三个可验证层面。V5 的方向已从让会话自己找资料、反复修复，转为服务端先固定输入、模型只生成、服务端确定性验收；接下来关键是用实际成功率和耗时验证改造，而不是只看链路已经切换。

2026/09/23 今天做了啥？ ✨

今天主要是在把 7 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成正式生题任务 71 的机会级复盘，确认 10 条机会均已终态、没有题目进入待审核：3 条 DIRECT_SESSION_TIMEOUT、4 条 CONTEXT_SCHEMA_INVALID、1 条 SDK_TIMEOUT，另有 2 条在 Knowledge Verdict 的 verify 阶段被拦截。
定位 V5 候选题验收拦截根因：QA-SC Knowledge 1bd441e3 将第 5 次调用固定校验为 allowed_card_evidence，实际成功回执为 generation_requirement；两次证据调用的返回数与引用数分别为 8/8、3/3，需求回执均为 1 条且无需引用。
完成 Knowledge 本地修复，AiOwnedV4TraceVerifier 已接受 V5 第 5 次 generation_requirement 回执，同时保留 V4 与记忆回执规则；定向 Maven 测试 10/10 通过。
完成 AI 服务会话时限与结构校验可观测性修复：首次调用和修复轮共享总时限，ContextPack 准备耗时纳入预算，日志补充稳定规则代号且不记录业务正文；目标分支定向测试 43 项通过、git diff --check 通过，当前未提交、未推送、未发布。
定位预发 pre/bjh AI 服务启动失败，新的 Pod 因 SCM 三项变量被注入空字符串而触发布尔/数值校验并进入 CrashLoopBackOff；旧 Pod 仍 Ready，应用汇总态存在误导风险。
定位 Backend 定时任务 SQL 报错，QA 的 sellai_train 尚未执行 V44，运行代码已使用缺失的 profile_rebuild_pending 字段；两个 March Key 缺失是独立配置问题，不能混为同一根因。
梳理 QA-SC 到 master 的二方包依赖与发布顺序，确认 6 个仓的 change 最新提交均已进入主干；代码合并状态不能替代实际 Pod 版本和运行验证。

🧩 困难/需要帮助

任务 71 的两个 Verdict 门禁问题已有本地修复，但其余 8 条超时/结构校验失败仍需按真实错误分型继续处理，不能把局部修复写成全量恢复。
预发需确认 SCM 三项配置的实际业务取值并修正空字符串，再验证新 Pod Ready；旧 Pod Ready 不能替代本次配置恢复验证。
QA 需补齐 V44 迁移，并继续确认两个 March Key 的用途与配置边界，避免把数据库迁移缺失误判为配置问题。

💭 感想

今天主要是在把正式生题失败从统一失败态收敛到机会级、验收级和运行环境级的具体证据。修复边界已经更清楚，但配置恢复、迁移执行和真实回归还要分别闭环，不能靠单个成功信号下结论。

2026/09/25 今天做了啥？ ✨

今天主要是在把 6 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成 WeKnora 接入现状与三仓同名分支梳理，确认当前已落地的是“商家资料入库与解析”，从 WeKnora 检索内容并生成题目的后半段尚未接通。
对齐资料导入主链：CP 管理台负责文件直传七牛、资料登记和发起导入，浏览器不直连知识库；CP 再通过 Dubbo 调用 Knowledge，由 Knowledge 使用服务端配置调用 WeKnora API。
定位“基于 WeKnora 生题”入口的边界问题，CP 侧请求与 Knowledge 分支 Dubbo 入参目前不一致，现有代码不能据此认定生题链路已经可用。
核对 CP、Backend、Knowledge 三仓分支提交与改动范围，确认 Backend 同名分支未保留可合入的 WeKnora 实现，避免把无关功能一起带入目标分支。
推进 Knowledge 的 change 分支合入 WeKnora 资料导入提交，合并过程无冲突；当前仍在等待编译验证结果，不把合入本身当作可运行结论。
核实 CP 管理台合入基线，当前工作区干净且与远端一致，已按题库页面和 Node 接口两个方向检查潜在冲突，最终合入结果待回收。