|
|
@@ -1,7 +1,8 @@
|
|
|
import type { TemplateType } from "../../constants.js";
|
|
|
|
|
|
export function getParsePrompt(
|
|
|
- template: TemplateType
|
|
|
+ template: TemplateType,
|
|
|
+ source?: string
|
|
|
): string {
|
|
|
const base = `You are a video script structuring assistant. Convert the input text into a JSON object for video generation.
|
|
|
|
|
|
@@ -44,7 +45,11 @@ Rules:
|
|
|
- The first scene's narration may include a brief greeting (e.g. "大家好，"), but set displayText to the content without the greeting — the greeting should only be heard, not shown as main text
|
|
|
- The last content scene should NOT include a conclusion or closing — outro handles that
|
|
|
- outro.text should be a short, natural closing (10-30 characters)
|
|
|
-- outro.cta should encourage audience engagement`;
|
|
|
+- outro.cta should encourage audience engagement
|
|
|
+
|
|
|
+CRITICAL — Text content restrictions:
|
|
|
+- All visible-text fields (title, summary, narration, displayText, keyframes[].content, outro.text, outro.cta) must contain ONLY plain text characters: Chinese characters, English letters, Arabic numerals, standard Chinese/English punctuation (。，！？、；：""''（）【】《》 .,!?:;"'()-/), and regular spaces/newlines.
|
|
|
+- NEVER use emoji (🚀💻🔥 etc.), dingbats (★✓✗), arrows (→←↑↓), or any decorative Unicode symbols. These render as missing-glyph boxes (tofu) in the video because the font only covers plain CJK + Latin text. If you feel tempted to add a symbol, use plain punctuation instead (e.g. write "->" or "—" instead of "→").`;
|
|
|
|
|
|
const templateSpecific: Record<TemplateType, string> = {
|
|
|
news: `
|
|
|
@@ -80,5 +85,76 @@ Template: Product Marketing (产品营销)
|
|
|
- layoutHint preference: "split" for features, "centered" for highlights`,
|
|
|
};
|
|
|
|
|
|
- return base + "\n\n" + templateSpecific[template];
|
|
|
+ const githubProjectIntroRule = `
|
|
|
+Per-project scene structure (applies to EVERY GitHub repository you introduce):
|
|
|
+
|
|
|
+OVERLAP RULE (most important): the headline (displayText) and the content (keyframe cards + narration) must have MINIMAL semantic overlap. The headline stays short and abstract; the cards and narration carry the actual detail. Do NOT make the headline echo what the 功能简介 card already says.
|
|
|
+
|
|
|
+A. Project name + ultra-short category → displayText (the prominent on-screen headline)
|
|
|
+ Format: "{owner}/{repo}" OR "{owner}/{repo} — {极简类别，2-5 字}".
|
|
|
+ Examples (good): "facebook/react", "vercel/next.js — 应用框架", "openai/whisper — 语音识别", "oven-sh/bun — JS 运行时".
|
|
|
+ The category tag (if present) must be ≤ 5 Chinese characters and stay at the level of "what kind of thing" (UI 库 / 框架 / CLI 工具 / 运行时 / 数据库 / 编辑器 / AI 模型). NEVER expand it into a one-line positioning sentence like "声明式用户界面库" — that level of detail belongs in the 功能简介 card. The headline ALREADY carries the project name; do NOT repeat it inside keyframe cards.
|
|
|
+
|
|
|
+B. Keyframe cards (4 cards ideally, 3-4 acceptable). Pick content that ADDS value beyond the headline.
|
|
|
+ These 3 cards are MANDATORY for every project:
|
|
|
+ - 功能简介 (what it actually does): format "功能：{2-4 句话具体说明这个工具能做什么、解决什么问题、有什么核心能力}". Example: "功能：声明式组件化 UI 构建方式，状态变化自动驱动视图更新，虚拟 DOM 优化渲染性能，适合处理复杂交互的 Web 应用". This must be DENSE and SPECIFIC — describe the actual capability, the problem it solves, and 1-2 distinguishing mechanisms. Do NOT parrot the headline category (e.g. if the headline already says "UI 库", this card must NOT just say "是一个 UI 库" — explain HOW it works and what makes it different).
|
|
|
+ - GitHub 地址: format "github.com/{owner}/{repo}". Display-only — narration should NOT spell out the URL, just refer to the project by name.
|
|
|
+ - 使用场景: format "使用场景：{目标用户 / 典型场景 / 不适用场景可选}". Example: "使用场景：中大型 Web 应用、组件化 UI 开发；不适合简单静态页面".
|
|
|
+
|
|
|
+ Then ADD 1-2 of the following cards to enrich the scene (do not leave the scene with only the 3 mandatory cards unless the project truly has no extra distinctive information):
|
|
|
+ - 核心特性 / 关键卖点: e.g. "特性：虚拟 DOM、单向数据流、Hooks"
|
|
|
+ - 数据信号: e.g. "Stars: 12.3k · 今日 +120" (only stars / growth — NEVER include programming language)
|
|
|
+ - 快速上手: e.g. "安装：npm i react react-dom"
|
|
|
+ - 知名采用: e.g. "采用：Facebook、Netflix、Airbnb"
|
|
|
+ - 生态地位: e.g. "生态：最主流的前端框架之一"
|
|
|
+ - 对比优势: e.g. "对比：相比 Vue，生态更成熟；相比 Angular，学习曲线更平缓"
|
|
|
+
|
|
|
+ FORBIDDEN card content — these add no value for a developer audience, NEVER put them on a card:
|
|
|
+ - Programming language (语言 / Language) as its own information item — e.g. "语言：TypeScript" is forbidden. The language only matters if it IS the value proposition (e.g. "Rust 写的高性能 HTTP 服务器"), in which case it belongs inside 功能简介 or narration, not on its own card.
|
|
|
+ - 技术栈 (tech stack) as a generic label — too vague to be useful.
|
|
|
+ - 协议 / License, repo size, file count, fork count on its own — these are visible on GitHub and waste a card slot.
|
|
|
+ - Any card that just restates the displayText category (e.g. headline "UI 库" + card "类型：UI 库") — that is pure overlap and wastes a card slot.
|
|
|
+
|
|
|
+ Number formatting rule (STRICT): whenever a count >= 1000 appears (stars, forks, contributors, today's growth, etc.), display it with a lowercase k suffix, NOT the raw integer. Examples: 1234 → "1.2k", 12345 → "12.3k", 123456 → "123k", 1234567 → "1235k", 999 → "999" (unchanged). NEVER use the m suffix — counts stay in k even past one million. The input text from the collector is already in this format — preserve it; if you ever compute or restate a count yourself, apply the same formatting before writing it into a card.
|
|
|
+
|
|
|
+C. 详细描述 → narration (口播)
|
|
|
+ Must be information-dense within the 200-char limit. Cover: what the project does (deeper than the headline), why it is notable, and 1-2 distinctive characteristics a developer would care about. Pack specifics — numbers, comparisons, concrete use cases — instead of filler phrases. Do NOT include a language bullet; mention the language only in passing if it is core to the value (e.g. "用 Rust 实现，启动速度比 Node 同类快数倍").
|
|
|
+ If the content does not fit in 200 chars, split the project across 2 scenes — first scene uses the structure above with concise narration; second scene expands with deeper detail on features, comparisons, or ecosystem.
|
|
|
+
|
|
|
+A typical single-project scene therefore looks like: short displayText (项目名 [+ 极简类别]) + 3 mandatory keyframe cards (功能简介 / GitHub 地址 / 使用场景) + 1-2 value-add cards + dense narration (口播详细描述).
|
|
|
+
|
|
|
+For multi-project sources, EACH project scene follows this same structure independently — do not mix two projects into one scene.`;
|
|
|
+
|
|
|
+ const sourceSpecific: Record<string, string> = {
|
|
|
+ "github-trending": `
|
|
|
+Data source: GitHub Trending (热门仓库列表)
|
|
|
+- The input is a list of multiple trending repositories. Treat it as a roundup.
|
|
|
+- Aim for 3-6 repos; if the input has more, pick the most notable ones (highest stars, biggest daily growth, or most novel).
|
|
|
+- One scene per repo. EVERY repo scene MUST follow the per-project scene structure below (headline + mandatory 功能简介 / GitHub 地址 / 使用场景 cards + optional value-add card + detailed narration).
|
|
|
+- Connect repos with a short narrative thread between scenes if there's a shared theme (e.g. "今天 AI Agent 持续火热"), but each project scene stands on its own.
|
|
|
+- Tone: pragmatic, factual, no hype. The audience is developers.
|
|
|
+${githubProjectIntroRule}`,
|
|
|
+
|
|
|
+ "github-repo": `
|
|
|
+Data source: Single GitHub Repository (单个仓库详情)
|
|
|
+- The input is one repository's metadata + README excerpt. Go deep on this single project.
|
|
|
+- First scene MUST follow the per-project scene structure below (headline + mandatory 功能简介 / GitHub 地址 / 使用场景 cards + optional value-add card + detailed narration) — this is the project's introduction scene.
|
|
|
+- Subsequent scenes (1-2 more) can elaborate: distinctive features pulled from the README, technical highlights, ecosystem signals (contributors, recent activity). They do NOT need to repeat the GitHub 地址 card, the 功能简介 card, or restate the headline.
|
|
|
+- Avoid enumerating every README section. Pick the 2-3 most distinctive aspects for the deeper scenes.
|
|
|
+- Tone: focused technical introduction, like a colleague recommending a tool.
|
|
|
+${githubProjectIntroRule}`,
|
|
|
+
|
|
|
+ "github-daily": `
|
|
|
+Data source: GitHub Daily (trending + 多仓库详情组合)
|
|
|
+- The input combines today's trending list with detailed info on selected repos.
|
|
|
+- Suggested structure: 1-2 opening scenes surveying today's overall trend theme (what topics dominate, what's heating up) — these overview scenes do NOT need the per-project structure. Then 1 scene per notable repo, and EVERY repo scene MUST follow the per-project scene structure below (headline + mandatory 功能简介 / GitHub 地址 / 使用场景 cards + optional value-add card + detailed narration).
|
|
|
+- Total 4-7 scenes is the sweet spot. If trending has many repos, group similar ones or pick only the top 3-4 to dive into.
|
|
|
+${githubProjectIntroRule}`,
|
|
|
+ };
|
|
|
+
|
|
|
+ const parts = [base, templateSpecific[template]];
|
|
|
+ if (source && sourceSpecific[source]) {
|
|
|
+ parts.push(sourceSpecific[source]);
|
|
|
+ }
|
|
|
+ return parts.join("\n\n");
|
|
|
}
|
lkatzey