吾方释Cuekiyo v1.0.0，乃开源之本地网应用，用以构作动画之开篇与终篇集锦视频.
其意简明：
择动画名目 → 审可OP/ED之歌 → 览YouTube片段之备选 → 输出成MP4之成片.
无云端编辑。无上传之阶。无付费API之倚。通体皆于汝之机中运行。
GitHub: https://github.com/unloopedmido/cuekiyo
吾为此作，盖因制作动画片头片尾合集之手工流程，实乃苦不堪言。终成诸般浏览器标签，复刻时间戳，别样下载指令，修剪之器，命名之乱，杂乱之匣，一帧稍变，辄需重演。
Cuekiyo 乃为导引之在地管路。其自动化庸琐之务，然犹暂驻于人力当决之时刻。
其弊
制编之视频，初闻似简，及亲为之，则难洁其事。
常人之手作，略若此：
- 择欲入之动漫。
- 索开篇终曲之名。
- 于 YouTube 搜索每曲之歌。
- 察何所上传可用。
- 将链接或时间戳复制于某处。
- 下载源视频。
- 各剪其带。
- 使音声归一，或至少避其纷杂无序。
- 添标题叠印/下三分屏。
- 诸事并合之.
- 有误则重绘之.
一为之非难，难在反复也.
若制一短片，寻常视频编辑之具足矣。若制结构繁复之合集，多载动漫名目，众主题之歌，诸源并出，叠影相承，输出之匣亦预可期，则其事渐类于小媒之管，非一时之独修矣。
此实吾欲解之困也。
非“易视频编辑之具”也。
似曰：
赐我一处本地工坊，可处理繁复之流程，而犹使我掌创意之权。
吾所为之事
Cuekiyo乃依循导引之项目流程而建。
汝可创一项目，择动漫之名，选欲启程或终曲，或二者兼之，继而经审准之阶。
其要义之序如下：
立一项目
题之，择动漫之名，选歌曲之属，定覆层/渲染之常.选歌曲
Cuekiyo载主题之数，使汝可决OP/ED之曲当入否.察片段之选
此应用取材于YouTube之选，然汝仍择其用。亦能自贴己链，俟自动化误时。修辑并加工片段
Cuekiyo于本地下载、探查、归一、裁剪、并叠合片段。核定渲染次序
汝于渲染前择其终序。导出MP4
终编译成于尔之本地项目所居之文件夹。
要旨之设计，如是：
自动化宜司劳力，不宜司品味。
是故，Cuekiyo于用户之门而暂驻。择曲、择源、择剪点、择终序，皆属主观。管道可助，然不应自诩知尔之味胜于尔。
为何首重本地？
吾欲使Cuekiyo若书斋之文房四宝，然其速成若网之灵动，其界面若水之随形。
故非构云之SaaS，Cuekiyo乃居於本地：
- 其後台行於尔机。
- 其前台行於尔浏览器。
- 项目之状存於SQLite。
- 媒体之文藏於
data/projects/{id}/。 - 渲染之事，乃由本地FFmpeg为之。
- 无须上传至某处云服务。
此于此类应用甚为要义，盖因视频之文件，体量宏大，而版权之物，涉法务与条款之繁复，且创作者多欲自掌其文。
地本优先亦使项目于运作为简。无用户账户之制，无存储计费，无托管渲染之列，无云端工群，亦无数据库之伺以持守。
然其权衡在，用户须于本地安设依存：Python、Node.js、FFmpeg、FFprobe、yt-dlp。于v1，吾纳此权衡，盖欲先发其核产也。
久远之志，欲安装之体验，近于“下载、开启、创制。”
其栈
Cuekiyo，析为FastAPI之後端与React之前端.
主栈者：
- 後端： FastAPI，SQLAlchemy，SQLite
- 前端： React 19，Vite，Tailwind CSS，shadcn/ui，React Router
- 媒體： FFmpeg、FFprobe、yt-dlp
- 覆疊渲染： 基於Satori的HTML轉PNG覆疊
- 元數據： Jikan與AniList
- 進度更新： WebSockets
- 項目儲存： 本地SQLite數據庫＋本地文件系統
前端主司导引之流程与审阅之界面。后端统辖管路、状变之序、媒体之处理、及文件系统之安。
建筑之制
概而论之，Cuekiyo乃一状态机，萦绕于媒体管线之周。
管渠之流，历诸段如：
DRAFT
→ LOAD_THEMES
→ SONG_SELECTION
→ SOURCING
→ AWAITING_CANDIDATES
→ DOWNLOADING
→ PROBING_NORMALIZING
→ CUTTING
→ OVERLAYING
→ AWAITING_RENDER_ORDER
→ RENDERING
→ COMPLETED
有阶段自动运行。有阶段需用户通过。
用户通过乃要者：
- 曲选
- 人选中察
- 可略删/审决
- 终成次第
余皆可自动化。
一FastAPI进程主司其流。诸务行于背景之线，进境推于前端于WebSocket。SQLite存项目之态、务之态，及活跃流锁之脉动.
于v1，Cuekiyo用一全球流锁。是故一项目一时一渲染一处理。此意简也。避众杂跨项目竞态之虫，而存崩溃恢复之明。
此乃永世之架构乎？非也。
然为 v1 之本地应用，则诚且可守。
媒体之流
崔其遥之最难，非制美之界面也。
其最难者，乃制媒体之流，使其不立时崩于世间之诡怪也。
外媒之工虽强，然多败：
- 本源之视频已隐没。
- yt-dlp返异元之元数据。
- FFmpeg因编码之故而败。
- 一节时序诡谲或流数据异样。
- 一径含汝所忘之字符。
- GPU编码于汝之机有效，然于他人之机则否。
- 下载之文件存，然后继之加工遗物不存。
Cuekiyo欲使诸问题可驭，乃视每阶为别之管渠步。
下载、探查、归一、裁切、叠合、渲染，皆殊异之作业。是故流程易察，易复，易喻于界面。
吾亦留意以子数组代壳字符串，传子进程之引。于触用者所供之链及文件系路径之本地媒体工具，此非可略之工饰，实为安全之基。
GPU编码与备选
吾初欲速成之功能，乃NVIDIA NVENC之支持。
众从事本地视频工作者，多备有NVIDIA之GPU，硬件编码可使渲染速倍。然硬性要求NVENC，实非良策，盖非诸机皆支持，且FFmpeg之构建亦异。
故Cuekiyo探查NVENC之支持，需时则退而用CPU编码，以libx264应之。
是故，备选之策甚要，盖因本地优先之软件，须善处诸般用户之机。不可遽谓环境必如己之所有。
前端
前段乃以React 19、Vite、Tailwind CSS、shadcn/ui及React Router所筑。
其UI之旨，非欲似粗鄙之管理面板。吾欲其若创意之器：
- 项目牌
- 导引之阶
- 清其状，明其位
- 剪选之候选评审
- 可见之进益
- 管制之设，不扰其流，亦无怖意。
前端通后台以API路径及WebSocket进境事件相语。此活态进境之反馈甚要，盖媒体工作或需时日。若UI默然静坐，而FFmpeg运行不息，则用户必以为有故。
纵使后台繁剧，前端亦当使管线可解。
至若设计之决断至要：唯用户需择时，方得暂停。
眾多自動化之器，常犯二失：
- 一者自動化之甚寡，則用者猶為繁冗之事；
- 二者自動化之甚多，則用者必自清理錯誤之決。
崔貴野之折中，乃用者之閾也。
應用無須於微末技節，每求確認，此必煩矣。
然亦不可默然取每YouTube之源、每终局之序，不经审察。此乃险途。
故此管道自进于机械之阶，于审美之决而暂止。
此模制终令产品觉甚佳善。亦使后端易明，盖门限之态，遂为状态机之显部，非随机之UI境矣。
已知v1之权衡
Cuekiyo v1.0.0非完美，吾不欲伪饰之。
v1最大之权衡者：
每次仅一管道作业
全局锁使作业执行者简明，且防诸项目争抢本地资源。其弊在于，跨项目并行尚不支持。
为本地v1版本，吾以为可。并行任务已在规划之列。
简化concat/crossfade之图
今之渲染路径，支持编译之流，然FFmpeg之滤图，可更为精妙。丰饶之渲染图，将使将来之转换与多片段布局更为易行。
重试可更为智巧
今之重试之序，已足应v1之模，然更耐久之每阶段游标，则善矣。是使应用能自其败境之正处续起，非臆测之也.
此非隐匿之题。录之者，盖我宁直陈架构之实，不欲假托v1之决皆为定论.
吾所悟者
筑器之教，启我智识数端.
1. 地方优先之器，犹需产品之思
易以“地方之器”为“匠者之用”。然筑器非徒为脚本配界面而已，须有导引之序，明示之状，有益之误，及非作者亦能了然之程。
虽运行于地，然产品之设，不可废也。
2. 工作流繁重之应用，状态机实为至要
3. 一旦应用有长作业、用户门限、重试、失败、取消及进度事件，隐含状态之苦立现
4. 使管道状态显明，获益甚巨
5. FFmpeg虽力强，然封装之码尤关紧要
FFmpeg可通百务，然用户无须忧其命图。真工在于，为其周遭筑一安且可察之层。
4. “尽自动化”非恒为善策
Cuekiyo至善之态，非盲作影片之傀儡，乃去繁劳而存人择之工坊也。
是故区隔之变，遂易吾之设计全篇.
何以继之
今v1.0.0既公，次志乃令Cuekiyo易试.
至要者：
- 首程体验更善
- 可携之桌面式发布
- 安装/依存检校更精
- 重试之智更明
- 并行项目作业
- 更丰富的渲染/交叉过渡选项
- 更多面向创作者的文档与演示
核心流程虽可行，然可发现性与安装之阻力于开源项目甚为关键。若有人欲涉猎，当能速解而试之.
终章思语
Cuekiyo初为偏门之想，然终成吾迄今所建之全备项目也。
其融全栈应用开发、本地优先架构、媒体处理、后台任务、WebSocket进度、UI/UX设计、发布工程于一体。
此即吾所求之项目，非徒示其形，乃具实器，含产品之决断，权其取舍，有真实之流程也。
若君好地缘之器、媒自化之术、React/FastAPI之应用，抑或奇诡专一之开源软件，不妨一观。
GitHub (GitHub)https://github.com/unloopedmido/cuekiyo
星辰与反馈，诚心所盼也。