解读视频是否支持自动与文章章节对齐

[songjiayang]

当前固定提示模版，感觉不够智能，理论可以自动识别出内容长度，章节和解读页码对齐

[lefarcen]

Hi @songjiayang! 👋

I see what you're aiming for here: instead of relying on a fixed prompt shape, have the generator infer the article length and chapter breaks, then keep the explainer pages aligned with those sections.

From the repo/docs side, article → video already uses the fetched source content to decide scene count and build a content-graph storyboard, but I don't see chapter-to-page alignment documented as a dedicated behavior yet. If you have a sample article plus the page split you expect (for example: 3 sections → 3-4 matched explainer pages), that would help us scope whether this should land as smarter automatic storyboard splitting, prompt tuning, or explicit per-page constraints.

The direction makes sense overall.

[songjiayang]

比如 https://mp.weixin.qq.com/s/e_gDWmX2zSMTjzKPMYA0xw 这篇文章，我想生成大约20页的内容，但是对话中，一直重复，给的模版最多生成10帧

[lefarcen]

Hey @songjiayang — this follow-up helps, thanks.

I checked the current implementation and there are two concrete limits behind what you're seeing:

• the storyboard planner currently clamps frame_count to 10 in packages/cli/src/studio-server.ts, so asking for ~20 pages will be cut back before generation runs;
• fetched article text is truncated to 8,000 chars in packages/cli/src/fetch-source.ts, so for a long WeChat article the later sections may never reach the planner, which can make repetition more likely.

So this looks like a real product gap rather than just prompt wording. A good next step would be to treat this as two improvements together: (1) raise/remove the 10-frame cap for long-form explainers, and (2) make the planner keep chapter coverage distinct so later frames don't loop earlier points. If you still have the exact prompt / generation flow that produced the repeated 10-frame result for that article, please paste it here — that would make the reproduction path much tighter.

[songjiayang]

好的，感谢您的反馈，不过我好奇，你的回答是 agent 还是真人呢？

[lefarcen]

Hey @songjiayang — good question. I’m the Synclo triage bot speaking through @lefarcen for first-pass issue handling.

So the replies here are automated, but I’m reading the thread and grounding answers in the repo/docs/code rather than sending a canned template. When maintainer judgment is needed, the human maintainers step in separately.

[lacusrinz]

需要更多帧数支持，10 帧根本不够

[walliai666]

一段内容有多少帧，每帧多少秒，是不是都由AI自主决策而不是交由用户决策（或者让用户确认）会更好？

[lefarcen]

Hey @walliai666，这个方向我认同，而且和现在的实现也有一点差距。

目前不是完全交给 AI 自主决定：format 这一步会先收集 帧数 / 每帧时长 / 画幅，再交给 planner 去生成 storyboard，所以今天更像是“用户先定外框，AI 再在框里编排”。

如果从体验上看，我觉得更合理的方向是 AI 先给建议，用户再一键确认或微调，而不是一上来让用户自己拍脑袋填数字。尤其这条 issue 里已经暴露出两个问题：一是 10 帧上限太死，二是长文其实很难让用户自己先猜一个合适的拆分。

所以我会把你的建议理解成：把“帧数/节奏”从必填参数，改成“AI 预估默认值 + 用户可确认/覆盖”的模式。这个思路是成立的，也和前面讨论的长文解读场景比较一致。

[walliai666]

@lefarcen 你问问团队中是否已经有了修改计划，如果没有的话，我愿意来做修改，但流程需要重新设计，时间会比较长

[lefarcen]

Hey @walliai666，基于当前 GitHub 上能看到的状态，我这边还没有看到这个方向已经挂出的 PR 或公开的实现计划。

不过我也不想直接替 maintainer 下结论说“完全没人做”，因为这类改动已经不只是把 10 帧上限放宽了，还会碰到 format 流程 / AI 建议默认值 / 用户确认方式 这些交互设计问题。

如果 maintainer 确认这块目前没有内部计划，我觉得你的贡献会很有价值。考虑到范围不小，一个比较稳的方式是先在这里贴一个分阶段方案，比如：

1. 先解除/放宽 10 帧硬上限；
2. 再把“帧数 / 每帧时长”改成 AI 预估默认值 + 用户确认/覆盖；
3. 最后再处理长文拆分后避免重复的问题。

这样即使整体周期会长一点，大家也能先对方向达成一致，再决定是不是开工。

[walliai666]

@lefarcen 每帧时长和帧数 都应该有上限 ，你认为上限多少最合理？或者你觉得不应该有上限？

[lefarcen]

Hey @walliai666，如果问我的个人判断，我倾向于 应该有上限，但不应该是现在这种过早卡死的上限。

基于当前实现，我看到两件事：

• 现在 UI 里给用户选的 每帧时长 是 2/3/4/5/6/8s；
• 帧数 现在被硬限制在 <=10，planner 里也会再次 clamp 到 10。

如果往“长文解读 / AI 先建议、用户确认”这个方向走，我会更倾向于这样分层：

1. 每帧时长要有上限，不然单帧太长时，体验会更像 PPT 停留而不是视频。我的直觉是：

   • 默认建议区间：3–6s/帧
   • 允许上限：8–10s/帧
   • 再往上就不该靠拉长单帧解决，应该靠拆成更多帧。

2. 帧数也要有上限，但这个上限更像是“产品/性能保护阈值”，不是今天这种太小的硬门槛。我的直觉是：

   • 普通场景默认建议：6–12 帧
   • 长文解读可放宽到：16–24 帧
   • 再往上最好进入另一种模式（分章节生成 / 分段确认），而不是无限单次生成。

所以我不太支持“完全没有上限”。没有上限在工程上很容易把生成时长、预览稳定性、用户编辑成本一起拉爆。更合理的是：有保护上限，但默认值和可选范围应该比现在宽，而且要让 AI 先给建议，不是让用户一开始自己猜。