1. 从463条视频里榨出可复用的Skill我为什么干这件事去年年底整理硬盘的时候我发现自己过去一年多陆陆续续用AI生成的视频素材已经攒了463条。这个数字听起来挺唬人但真实情况是能直接拿出来用的不到三成剩下的要么人物动作崩了要么镜头语言完全不对要么就是提示语写得含糊导致模型自由发挥。更让我头疼的是每次想复刻某条效果不错的视频我都得翻聊天记录、翻笔记、翻各种临时文档才能勉强拼凑出当时用的那套提示语。这个痛点我相信做AI视频的人都懂。你调出一个满意的效果可能花了二三十次试错但过两周再想复现提示语早就散落在各个角落了。于是我做了一个决定把这463条视频全部拆解一遍把里面真正有效的提示语结构、参数组合、镜头描述方式提炼出来做成一套可复用的Skill和提示语模版然后全部开源。这里说的Skill不是某个平台专属的功能而是一套结构化的能力封装——把生成一条特定类型AI视频所需要的提示语骨架、参数建议、常见失败模式、修正策略打包成一个可调用的单元。你可以把它理解成给AI Agent准备的一份操作手册Agent拿到这个Skill就知道面对产品展示类短视频该用什么镜头语言、面对人物口播类该注意哪些面部细节、面对场景过渡类该怎么描述运动轨迹。为什么是463这个数字其实没什么玄学就是我实际攒下来的量。但拆解到第100条左右的时候我已经能明显感觉到规律了真正决定视频质量的往往不是模型本身而是提示语里那几个关键描述词的位置和组合方式。这个发现让我意识到与其继续盲目生成不如先把已有的经验结构化。这套东西适合谁如果你是刚接触AI视频的新手这些模版能帮你跳过大量无效试错如果你已经在做AI视频但苦于效果不稳定Skill里的失败模式清单和修正策略会很有用如果你在开发AI Agent这些Skill可以直接作为Agent的能力模块接入。接下来我会把整个拆解过程、Skill的设计逻辑、提示语模版的构建方法以及开源后的实际使用反馈完整地讲一遍。2. 463条视频的拆解方法从能看到能复用的筛选逻辑2.1 先给视频分档别急着提炼一开始我犯了个错误拿到视频就开始逐条分析提示语。结果分析了三十多条就发现很多视频本身质量就不行从它们身上提炼出来的经验其实是负面的。比如有一条视频人物手部严重变形我当时用的提示语里写了手自然放在桌面上这个描述本身没问题但模型就是处理不好。如果我把这条也当成有效样本就会得出不要描述手部动作这种错误结论。所以我重新设计了一套分档标准把463条视频分成四档档位判定标准处理方式A档可直接使用无需修改重点拆解提取完整提示语结构B档微调后可用问题在可修正范围拆解并记录修正前后的差异C档有明显缺陷但某个片段或某个元素值得保留只提取局部有效描述D档完全不可用仅记录失败原因不提取提示语分档之后A档有127条B档有189条C档有98条D档49条。真正值得深度拆解的是A档和B档加起来316条。C档里我主要看的是为什么某个元素效果好但整体不行这能帮我理解提示语各部分的独立作用。2.2 提示语的结构化拆解把一句话拆成六个维度一条AI视频的提示语表面上看是一段文字但实际上它包含了多个维度的信息。我把它拆成六个维度主体描述画面里有什么人、物、场景包括外观、材质、颜色动作与运动主体在做什么运动的方向、速度、幅度镜头语言景别远景/中景/特写、机位平视/俯视/仰视、运动推拉摇移跟光影与氛围光源方向、色温、对比度、整体情绪风格限定写实/动画/电影感/纪录片感等技术参数分辨率、帧率、时长、宽高比拆解的时候我把每条A档视频的原始提示语按这六个维度重新整理然后统计哪些维度的描述是必须有的哪些是有了更好但没有也行。结果很有意思镜头语言和光影氛围这两个维度在A档视频里的描述率超过90%而在D档视频里只有不到30%。也就是说很多人写提示语只关注画什么忽略了怎么拍。但AI视频模型对镜头语言的理解能力其实比我们想象的要强你写特写镜头浅景深背景虚化模型真的会给你一个特写。2.3 从提示语到Skill封装什么不封装什么拆解完提示语之后下一步是把它封装成Skill。这里有个关键决策Skill的粒度应该多大如果粒度太细比如生成一个微笑表情做成一个Skill那Skill数量会爆炸而且复用性很差。如果粒度太粗比如生成一条产品广告视频做成一个Skill那里面变量太多Agent根本不知道怎么填。我最后定的粒度是按视频类型分每个Skill对应一类常见的AI视频需求。比如产品展示类Skill人物口播类Skill场景过渡类Skill动态文字类Skill氛围空镜类Skill每个Skill里面包含提示语模版带可替换变量、参数建议表、常见失败模式及修正策略、2-3个实际案例。这样Agent拿到一个Skill就能直接套用不需要从零开始想提示语。不封装什么我刻意没有把具体的模型参数比如某个特定模型的seed值、CFG scale写死。因为不同模型、不同版本的参数差异很大写死了反而限制复用。我提供的是参数范围和建议逻辑具体数值让使用者根据自己用的工具去调。3. Skill和提示语模版的设计细节让Agent能看懂的写法3.1 提示语模版的变量设计哪些该留空哪些该写死设计模版的时候最容易犯的错是把所有东西都做成变量。我一开始也是这么干的结果模版变成了{{主体}}在{{场景}}里做{{动作}}{{镜头}}{{光影}}看起来灵活实际上Agent根本不知道该填什么填出来的东西也缺乏一致性。后来我改成分层变量的设计固定层这部分不随场景变化直接写死。比如电影感色调35mm镜头质感自然光——这些是保证视频质感的基础不需要每次改。半固定层提供几个预设选项Agent从选项里选。比如镜头景别我预设了特写/中景/全景三个选项每个选项对应一套完整的镜头描述。自由层这部分完全由使用者填写通常是主体和动作的具体描述。这样设计的好处是Agent不需要理解什么是电影感它只需要知道这个Skill的固定层已经包含了电影感描述我不用管。半固定层给了Agent选择空间但又不会让它自由发挥到跑偏。举个例子产品展示类Skill的提示语模版是这样的[固定层] 专业产品摄影风格柔和的侧逆光浅景深背景干净虚化画面锐利清晰 [半固定层-镜头] {特写环绕 / 中景平移 / 全景推近} [自由层] {产品名称}{产品外观描述}{展示动作描述} [固定层] 高细节8K质感无文字水印Agent拿到这个模版只需要填自由层和选半固定层出来的提示语就已经有基本质量保证了。3.2 失败模式清单比成功案例更有价值的部分我在每个Skill里都放了一个常见失败模式清单。这部分是我觉得整套东西里最有价值的内容因为成功案例告诉你怎么做对但失败模式告诉你怎么避免做错。以人物口播类Skill为例我记录了这些失败模式失败现象根本原因修正策略面部扭曲变形提示语中面部描述过于复杂或矛盾简化面部描述只保留自然表情面部清晰口型与语音不同步视频生成模型本身的口型同步能力限制在提示语中避免强调说话动作改用面对镜头手部动作僵硬手部描述过于具体改为手部自然放置或直接不描述手部背景人物干扰场景描述中包含了过多背景元素明确写背景简洁无其他人物画面闪烁光影描述前后矛盾统一光源方向避免同时出现侧光和顶光这个清单不是凭空想的是我从D档和C档视频的失败原因里统计出来的。每条失败模式都对应至少5条实际视频的翻车记录。3.3 Skill的元数据设计让Agent知道什么时候该用我一个Skill如果只有内容没有元数据Agent就不知道什么时候该调用它。所以我给每个Skill都加了一组元数据适用场景一句话描述这个Skill适合什么需求输入要求需要使用者提供哪些信息输出预期生成视频的大致效果和时长范围限制条件这个Skill不擅长什么什么情况下不该用比如场景过渡类Skill的元数据里限制条件写的是不适合需要精确控制过渡帧数的场景不适合包含复杂人物动作的过渡。这样Agent在遇到这类需求时就会知道该换别的Skill或者提醒使用者这个Skill可能达不到要求。元数据的设计逻辑是让Agent在做选择的时候有依据而不是靠猜。这比单纯给一堆提示语模版要有用得多。4. 开源之后实际使用中的反馈和迭代4.1 开源平台的选择和文件组织方式这套东西我最终放在了代码托管平台上开源。选择平台的时候主要考虑两点一是方便版本迭代二是方便非技术背景的人也能看懂。最后选了最主流的那个因为它的README渲染效果最好而且Issue功能方便收集反馈。文件组织上我没有把所有Skill塞进一个大文件而是按类型分目录/skills /product-showcase skill.md examples.md failure-modes.md /talking-head skill.md examples.md failure-modes.md /scene-transition ... /templates prompt-template-collection.md /README.md每个Skill一个目录里面三个文件skill.md是核心内容examples.md是实际案例failure-modes.md是失败模式清单。这样结构清晰也方便别人只取自己需要的部分。4.2 收到的反馈里哪些是我没想到的开源之后陆续收到了一些反馈有几个点是我自己没预料到的。第一个反馈是有人把Skill用在了AI视频之外的场景。比如有个做UI设计的朋友说他把镜头语言那部分拆出来用来描述界面动效的转场方式效果意外地好。这让我意识到Skill里封装的不只是AI视频知识更是一种结构化描述视觉内容的方法论可以迁移到其他领域。第二个反馈是有人反映失败模式清单太长了看不过来。我一开始觉得越长越全越好但实际使用中大家更想要的是最常踩的三个坑。所以后来我在每个failure-modes.md开头加了一个Top 3高频问题的摘要详细清单放在后面供查阅。第三个反馈是关于变量命名的。我一开始用的变量名是英文的比如{{subject}}、{{action}}但有反馈说中文使用者更习惯中文变量名。后来我改成了中英双语标注比如{{主体/subject}}这样两边都能看懂。4.3 从463到更多后续的扩展思路463条视频拆出来的Skill和模版覆盖了大部分常见场景但肯定不是终点。我后续打算从两个方向扩展一是按行业细分。现在的Skill是按视频类型分的但不同行业对同一类视频的要求差异很大。比如同样是产品展示美妆产品和数码产品的镜头语言就完全不同。后续可能会出行业特化版的Skill。二是加入更多失败模式的自动检测。现在失败模式清单是给人看的但如果在Agent里集成一个检测逻辑让Agent在生成提示语之前就自动规避已知的失败模式那实用性会更强。这个方向我还在摸索主要是怎么把失败模式转化成Agent能理解的规则。5. 如果你也想做类似的事几个实操建议5.1 别等攒够了再开始边做边拆我一开始想的是等攒够500条再系统拆解但实际到200条左右的时候我就发现很多规律已经重复出现了。所以如果你也想做类似的事情不用等数量攒够做到50条左右就可以开始拆解。拆解的过程本身会帮你优化后续的生成策略形成正向循环。具体操作上我建议每生成10条视频就花半小时做一次快速拆解记录这条视频用了什么提示语结构、效果如何、有没有值得保留的描述方式。这样积累下来到100条的时候你已经有了一套初步的模版。5.2 提示语模版要留白不要填满这是我踩过的一个坑。一开始我设计的模版特别详细恨不得把每个细节都写进去。结果发现模版越详细适用场景越窄。后来我学会了留白只写那些不写就会出问题的描述其他部分留给使用者根据具体情况补充。判断标准很简单如果去掉某个描述视频质量会明显下降那这个描述就该保留在模版里如果去掉之后影响不大那就把它移到可选描述里让使用者自己决定加不加。5.3 失败模式清单要持续更新失败模式清单不是一次性能写完的。我在开源之后陆续又收到了十几条新的失败模式反馈都是我自己没遇到过的。所以这个清单需要持续维护。我的做法是在项目里开了一个专门的Issue标签叫failure-mode任何人遇到新的失败情况都可以提我定期整理进清单里。另外失败模式的描述要具体不要写画面质量差这种模糊的说法。要写清楚什么情况下会出现什么具体现象比如当提示语中同时出现快速运动和浅景深时画面会出现明显的运动模糊和焦点漂移。越具体别人越容易对照排查。5.4 开源不是终点是迭代的起点最后说一点心态上的体会。我一开始觉得开源就是把做好的东西放出去但实际经历下来开源更像是把半成品放出去和大家一起完善。我放出去的Skill和模版在收到反馈之前只能算70分是后续的Issue、PR和讨论把它推到了85分以上。所以如果你也在考虑开源类似的东西不用等它完美。只要核心内容对别人有价值就可以先放出去然后在迭代中完善。开源社区里有很多愿意提意见、愿意贡献的人他们的反馈往往比你自己闷头优化要有效得多。这套Skill和提示语模版我还在持续维护后续如果有新的拆解成果或者收到有价值的反馈我会继续更新到项目里。如果你在用的时候遇到什么问题或者有新的失败模式要补充欢迎直接提Issue我基本都会看。
从463条AI视频中提炼可复用Skill与提示语模版的开源实践
1. 从463条视频里榨出可复用的Skill我为什么干这件事去年年底整理硬盘的时候我发现自己过去一年多陆陆续续用AI生成的视频素材已经攒了463条。这个数字听起来挺唬人但真实情况是能直接拿出来用的不到三成剩下的要么人物动作崩了要么镜头语言完全不对要么就是提示语写得含糊导致模型自由发挥。更让我头疼的是每次想复刻某条效果不错的视频我都得翻聊天记录、翻笔记、翻各种临时文档才能勉强拼凑出当时用的那套提示语。这个痛点我相信做AI视频的人都懂。你调出一个满意的效果可能花了二三十次试错但过两周再想复现提示语早就散落在各个角落了。于是我做了一个决定把这463条视频全部拆解一遍把里面真正有效的提示语结构、参数组合、镜头描述方式提炼出来做成一套可复用的Skill和提示语模版然后全部开源。这里说的Skill不是某个平台专属的功能而是一套结构化的能力封装——把生成一条特定类型AI视频所需要的提示语骨架、参数建议、常见失败模式、修正策略打包成一个可调用的单元。你可以把它理解成给AI Agent准备的一份操作手册Agent拿到这个Skill就知道面对产品展示类短视频该用什么镜头语言、面对人物口播类该注意哪些面部细节、面对场景过渡类该怎么描述运动轨迹。为什么是463这个数字其实没什么玄学就是我实际攒下来的量。但拆解到第100条左右的时候我已经能明显感觉到规律了真正决定视频质量的往往不是模型本身而是提示语里那几个关键描述词的位置和组合方式。这个发现让我意识到与其继续盲目生成不如先把已有的经验结构化。这套东西适合谁如果你是刚接触AI视频的新手这些模版能帮你跳过大量无效试错如果你已经在做AI视频但苦于效果不稳定Skill里的失败模式清单和修正策略会很有用如果你在开发AI Agent这些Skill可以直接作为Agent的能力模块接入。接下来我会把整个拆解过程、Skill的设计逻辑、提示语模版的构建方法以及开源后的实际使用反馈完整地讲一遍。2. 463条视频的拆解方法从能看到能复用的筛选逻辑2.1 先给视频分档别急着提炼一开始我犯了个错误拿到视频就开始逐条分析提示语。结果分析了三十多条就发现很多视频本身质量就不行从它们身上提炼出来的经验其实是负面的。比如有一条视频人物手部严重变形我当时用的提示语里写了手自然放在桌面上这个描述本身没问题但模型就是处理不好。如果我把这条也当成有效样本就会得出不要描述手部动作这种错误结论。所以我重新设计了一套分档标准把463条视频分成四档档位判定标准处理方式A档可直接使用无需修改重点拆解提取完整提示语结构B档微调后可用问题在可修正范围拆解并记录修正前后的差异C档有明显缺陷但某个片段或某个元素值得保留只提取局部有效描述D档完全不可用仅记录失败原因不提取提示语分档之后A档有127条B档有189条C档有98条D档49条。真正值得深度拆解的是A档和B档加起来316条。C档里我主要看的是为什么某个元素效果好但整体不行这能帮我理解提示语各部分的独立作用。2.2 提示语的结构化拆解把一句话拆成六个维度一条AI视频的提示语表面上看是一段文字但实际上它包含了多个维度的信息。我把它拆成六个维度主体描述画面里有什么人、物、场景包括外观、材质、颜色动作与运动主体在做什么运动的方向、速度、幅度镜头语言景别远景/中景/特写、机位平视/俯视/仰视、运动推拉摇移跟光影与氛围光源方向、色温、对比度、整体情绪风格限定写实/动画/电影感/纪录片感等技术参数分辨率、帧率、时长、宽高比拆解的时候我把每条A档视频的原始提示语按这六个维度重新整理然后统计哪些维度的描述是必须有的哪些是有了更好但没有也行。结果很有意思镜头语言和光影氛围这两个维度在A档视频里的描述率超过90%而在D档视频里只有不到30%。也就是说很多人写提示语只关注画什么忽略了怎么拍。但AI视频模型对镜头语言的理解能力其实比我们想象的要强你写特写镜头浅景深背景虚化模型真的会给你一个特写。2.3 从提示语到Skill封装什么不封装什么拆解完提示语之后下一步是把它封装成Skill。这里有个关键决策Skill的粒度应该多大如果粒度太细比如生成一个微笑表情做成一个Skill那Skill数量会爆炸而且复用性很差。如果粒度太粗比如生成一条产品广告视频做成一个Skill那里面变量太多Agent根本不知道怎么填。我最后定的粒度是按视频类型分每个Skill对应一类常见的AI视频需求。比如产品展示类Skill人物口播类Skill场景过渡类Skill动态文字类Skill氛围空镜类Skill每个Skill里面包含提示语模版带可替换变量、参数建议表、常见失败模式及修正策略、2-3个实际案例。这样Agent拿到一个Skill就能直接套用不需要从零开始想提示语。不封装什么我刻意没有把具体的模型参数比如某个特定模型的seed值、CFG scale写死。因为不同模型、不同版本的参数差异很大写死了反而限制复用。我提供的是参数范围和建议逻辑具体数值让使用者根据自己用的工具去调。3. Skill和提示语模版的设计细节让Agent能看懂的写法3.1 提示语模版的变量设计哪些该留空哪些该写死设计模版的时候最容易犯的错是把所有东西都做成变量。我一开始也是这么干的结果模版变成了{{主体}}在{{场景}}里做{{动作}}{{镜头}}{{光影}}看起来灵活实际上Agent根本不知道该填什么填出来的东西也缺乏一致性。后来我改成分层变量的设计固定层这部分不随场景变化直接写死。比如电影感色调35mm镜头质感自然光——这些是保证视频质感的基础不需要每次改。半固定层提供几个预设选项Agent从选项里选。比如镜头景别我预设了特写/中景/全景三个选项每个选项对应一套完整的镜头描述。自由层这部分完全由使用者填写通常是主体和动作的具体描述。这样设计的好处是Agent不需要理解什么是电影感它只需要知道这个Skill的固定层已经包含了电影感描述我不用管。半固定层给了Agent选择空间但又不会让它自由发挥到跑偏。举个例子产品展示类Skill的提示语模版是这样的[固定层] 专业产品摄影风格柔和的侧逆光浅景深背景干净虚化画面锐利清晰 [半固定层-镜头] {特写环绕 / 中景平移 / 全景推近} [自由层] {产品名称}{产品外观描述}{展示动作描述} [固定层] 高细节8K质感无文字水印Agent拿到这个模版只需要填自由层和选半固定层出来的提示语就已经有基本质量保证了。3.2 失败模式清单比成功案例更有价值的部分我在每个Skill里都放了一个常见失败模式清单。这部分是我觉得整套东西里最有价值的内容因为成功案例告诉你怎么做对但失败模式告诉你怎么避免做错。以人物口播类Skill为例我记录了这些失败模式失败现象根本原因修正策略面部扭曲变形提示语中面部描述过于复杂或矛盾简化面部描述只保留自然表情面部清晰口型与语音不同步视频生成模型本身的口型同步能力限制在提示语中避免强调说话动作改用面对镜头手部动作僵硬手部描述过于具体改为手部自然放置或直接不描述手部背景人物干扰场景描述中包含了过多背景元素明确写背景简洁无其他人物画面闪烁光影描述前后矛盾统一光源方向避免同时出现侧光和顶光这个清单不是凭空想的是我从D档和C档视频的失败原因里统计出来的。每条失败模式都对应至少5条实际视频的翻车记录。3.3 Skill的元数据设计让Agent知道什么时候该用我一个Skill如果只有内容没有元数据Agent就不知道什么时候该调用它。所以我给每个Skill都加了一组元数据适用场景一句话描述这个Skill适合什么需求输入要求需要使用者提供哪些信息输出预期生成视频的大致效果和时长范围限制条件这个Skill不擅长什么什么情况下不该用比如场景过渡类Skill的元数据里限制条件写的是不适合需要精确控制过渡帧数的场景不适合包含复杂人物动作的过渡。这样Agent在遇到这类需求时就会知道该换别的Skill或者提醒使用者这个Skill可能达不到要求。元数据的设计逻辑是让Agent在做选择的时候有依据而不是靠猜。这比单纯给一堆提示语模版要有用得多。4. 开源之后实际使用中的反馈和迭代4.1 开源平台的选择和文件组织方式这套东西我最终放在了代码托管平台上开源。选择平台的时候主要考虑两点一是方便版本迭代二是方便非技术背景的人也能看懂。最后选了最主流的那个因为它的README渲染效果最好而且Issue功能方便收集反馈。文件组织上我没有把所有Skill塞进一个大文件而是按类型分目录/skills /product-showcase skill.md examples.md failure-modes.md /talking-head skill.md examples.md failure-modes.md /scene-transition ... /templates prompt-template-collection.md /README.md每个Skill一个目录里面三个文件skill.md是核心内容examples.md是实际案例failure-modes.md是失败模式清单。这样结构清晰也方便别人只取自己需要的部分。4.2 收到的反馈里哪些是我没想到的开源之后陆续收到了一些反馈有几个点是我自己没预料到的。第一个反馈是有人把Skill用在了AI视频之外的场景。比如有个做UI设计的朋友说他把镜头语言那部分拆出来用来描述界面动效的转场方式效果意外地好。这让我意识到Skill里封装的不只是AI视频知识更是一种结构化描述视觉内容的方法论可以迁移到其他领域。第二个反馈是有人反映失败模式清单太长了看不过来。我一开始觉得越长越全越好但实际使用中大家更想要的是最常踩的三个坑。所以后来我在每个failure-modes.md开头加了一个Top 3高频问题的摘要详细清单放在后面供查阅。第三个反馈是关于变量命名的。我一开始用的变量名是英文的比如{{subject}}、{{action}}但有反馈说中文使用者更习惯中文变量名。后来我改成了中英双语标注比如{{主体/subject}}这样两边都能看懂。4.3 从463到更多后续的扩展思路463条视频拆出来的Skill和模版覆盖了大部分常见场景但肯定不是终点。我后续打算从两个方向扩展一是按行业细分。现在的Skill是按视频类型分的但不同行业对同一类视频的要求差异很大。比如同样是产品展示美妆产品和数码产品的镜头语言就完全不同。后续可能会出行业特化版的Skill。二是加入更多失败模式的自动检测。现在失败模式清单是给人看的但如果在Agent里集成一个检测逻辑让Agent在生成提示语之前就自动规避已知的失败模式那实用性会更强。这个方向我还在摸索主要是怎么把失败模式转化成Agent能理解的规则。5. 如果你也想做类似的事几个实操建议5.1 别等攒够了再开始边做边拆我一开始想的是等攒够500条再系统拆解但实际到200条左右的时候我就发现很多规律已经重复出现了。所以如果你也想做类似的事情不用等数量攒够做到50条左右就可以开始拆解。拆解的过程本身会帮你优化后续的生成策略形成正向循环。具体操作上我建议每生成10条视频就花半小时做一次快速拆解记录这条视频用了什么提示语结构、效果如何、有没有值得保留的描述方式。这样积累下来到100条的时候你已经有了一套初步的模版。5.2 提示语模版要留白不要填满这是我踩过的一个坑。一开始我设计的模版特别详细恨不得把每个细节都写进去。结果发现模版越详细适用场景越窄。后来我学会了留白只写那些不写就会出问题的描述其他部分留给使用者根据具体情况补充。判断标准很简单如果去掉某个描述视频质量会明显下降那这个描述就该保留在模版里如果去掉之后影响不大那就把它移到可选描述里让使用者自己决定加不加。5.3 失败模式清单要持续更新失败模式清单不是一次性能写完的。我在开源之后陆续又收到了十几条新的失败模式反馈都是我自己没遇到过的。所以这个清单需要持续维护。我的做法是在项目里开了一个专门的Issue标签叫failure-mode任何人遇到新的失败情况都可以提我定期整理进清单里。另外失败模式的描述要具体不要写画面质量差这种模糊的说法。要写清楚什么情况下会出现什么具体现象比如当提示语中同时出现快速运动和浅景深时画面会出现明显的运动模糊和焦点漂移。越具体别人越容易对照排查。5.4 开源不是终点是迭代的起点最后说一点心态上的体会。我一开始觉得开源就是把做好的东西放出去但实际经历下来开源更像是把半成品放出去和大家一起完善。我放出去的Skill和模版在收到反馈之前只能算70分是后续的Issue、PR和讨论把它推到了85分以上。所以如果你也在考虑开源类似的东西不用等它完美。只要核心内容对别人有价值就可以先放出去然后在迭代中完善。开源社区里有很多愿意提意见、愿意贡献的人他们的反馈往往比你自己闷头优化要有效得多。这套Skill和提示语模版我还在持续维护后续如果有新的拆解成果或者收到有价值的反馈我会继续更新到项目里。如果你在用的时候遇到什么问题或者有新的失败模式要补充欢迎直接提Issue我基本都会看。
