fix(smart-match): limit 算法取 segments.length 下限，保证每片段至少 1 个素材 #1600

Merged

xiaoxia merged 1 commits from fix/smart-match-limit-algorithm into develop 2026-09-01 12:22:30 +08:00

Conversation 3 Commits 1 Files Changed 1

+3 -2

xiaoxia commented 2026-09-01 12:11:48 +08:00

Owner

Copy Link

Copy Source

问题

computeLimitFromSegments 使用 Math.ceil(totalSeconds / 15) 估算素材数量。
14 秒模板（4 个片段）算出 Math.ceil(14/15) = 1，前端只向后端要 1 个素材，导致后端 4 个片段无法分配。

修复

L30 改为 Math.max(segments.length, Math.ceil(totalSeconds / SECONDS_PER_ASSET))，保证每个片段至少能分到 1 个素材。

改动

• apps/web/src/pages/generate/hooks/step2-materials/useSmartMatch.ts：一行代码 + 注释更新

## 问题 `computeLimitFromSegments` 使用 `Math.ceil(totalSeconds / 15)` 估算素材数量。 14 秒模板（4 个片段）算出 `Math.ceil(14/15) = 1`，前端只向后端要 1 个素材，导致后端 4 个片段无法分配。 ## 修复 L30 改为 `Math.max(segments.length, Math.ceil(totalSeconds / SECONDS_PER_ASSET))`，保证每个片段至少能分到 1 个素材。 ## 改动 - `apps/web/src/pages/generate/hooks/step2-materials/useSmartMatch.ts`：一行代码 + 注释更新

xiaoxia added 1 commit 2026-09-01 12:11:48 +08:00

fix(smart-match): limit 算法取 segments.length 下限，保证每片段至少 1 个素材 ... 318cffd35c

computeLimitFromSegments 原逻辑 Math.ceil(totalSeconds/15) 在短模板
（如 14s 模板 4 片段）下仅返回 1，导致后端只分配 1 个素材无法覆盖
全部片段。改为 Math.max(segments.length, ...) 保证每个片段至少能
分到 1 个素材。

auto-approve-bot commented 2026-09-01 12:16:17 +08:00

Collaborator

Copy Link

Copy Source

【阻塞级判定】

• 是否存在阻塞级问题：否
• 阻塞级问题数量：0 个

📊 审查概览

• 整体评价：通过
• 建议级问题数量：0 个

🔴 阻塞级问题（必须修复）

无

💡 改进建议（不阻塞合并）

无

✅ 良好实践

1. 逻辑优化：修改后的逻辑 Math.max(segments.length, ...) 很好地解决了极端情况（如片段数量多于基于时长估算的素材数），确保了每个片段至少能分配到一个素材，避免了素材分配不足导致的功能异常。
2. 注释同步：代码变更时同步更新了注释，清晰说明了“保证不少于片段数”的业务逻辑，有助于代码维护。
3. 边界保护：保留了 Math.max(1, Math.min(limit, 200)) 的钳制逻辑，有效防止了超出后端限制（200）或非法值（0/负数）的请求。

---

_{🤖 由 AI 代码审查机器人自动生成 | 2026-09-01 04:16:17 | 模型:}

### 【阻塞级判定】 - 是否存在阻塞级问题：否 - 阻塞级问题数量：0 个 ### 📊 审查概览 - 整体评价：通过 - 建议级问题数量：0 个 ### 🔴 阻塞级问题（必须修复） 无 ### 💡 改进建议（不阻塞合并） 无 ### ✅ 良好实践 1. **逻辑优化**：修改后的逻辑 `Math.max(segments.length, ...)` 很好地解决了极端情况（如片段数量多于基于时长估算的素材数），确保了每个片段至少能分配到一个素材，避免了素材分配不足导致的功能异常。 2. **注释同步**：代码变更时同步更新了注释，清晰说明了“保证不少于片段数”的业务逻辑，有助于代码维护。 3. **边界保护**：保留了 `Math.max(1, Math.min(limit, 200))` 的钳制逻辑，有效防止了超出后端限制（200）或非法值（0/负数）的请求。 --- _{🤖 由 AI 代码审查机器人自动生成 | 2026-09-01 04:16:17 | 模型:} <!-- AI_CODE_REVIEW_AUTO_COMMENT -->

gitea-actions bot commented 2026-09-01 12:18:27 +08:00

Copy Link

Copy Source

🚀 预览环境已部署

项目	详情
PR号	#1600
预览链接	https://pr-1600.preview.xiaoxiajianji.com
API环境	staging

💡 预览环境使用 staging API 数据，请勿在预览环境中操作重要数据。

🔄 每次提交新代码后预览环境会自动更新。

🗑️ PR 关闭或合并后，预览环境会自动清理。

🚀 **预览环境已部署** | 项目 | 详情 | |------|------| | PR号 | #1600 | | 预览链接 | [https://pr-1600.preview.xiaoxiajianji.com](https://pr-1600.preview.xiaoxiajianji.com) | | API环境 | staging | > 💡 预览环境使用 staging API 数据，请勿在预览环境中操作重要数据。 > > 🔄 每次提交新代码后预览环境会自动更新。 > > 🗑️ PR 关闭或合并后，预览环境会自动清理。

xiaoxia merged commit 24f1ca35d5 into develop 2026-09-01 12:22:30 +08:00

gitea-actions bot commented 2026-09-01 12:26:58 +08:00

Copy Link

Copy Source

🗑️ 预览环境已清理

PR #1600 已关闭或合并，对应的预览环境已被清理。

如有需要，可以重新打开 PR 来重新生成预览环境。

🗑️ **预览环境已清理** PR #1600 已关闭或合并，对应的预览环境已被清理。 > 如有需要，可以重新打开 PR 来重新生成预览环境。

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

P0

阻塞性，必须立即处理

P1

高优先级

P2

中优先级

P3

低优先级/后考虑

architecture

架构设计

backend

后端相关

blocked

阻塞中

bug

Bug修复

ci-bug

CI本身的bug

ci-optimization

CI优化类任务

ci-pipeline

CI流水线/workflow相关

cleanup

代码清理

devops

运维/部署/CI

documentation

文档相关

feature

新功能

frontend

前端相关

question

需要讨论确认

ready

PR CI通过，可合并

refactor

代码重构

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

auto-approve-bot xiaoxia

No Assignees

3 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: xiaoxia/xiaoxia-saas#1600