具体怎样写，为什么有效

这个 description 的用意很明确：它不是只写“用于制作视频”，而是枚举程序化渲染、镜头变化、发光叠加和具体画面症状。这样，执行者既可能从任务类型找到它，也可能在出现问题时找到它。

最值得细读的是那个看似琐碎的“只缩放十秒”。作者紧跟着说明，小任务也有静默失败，而且失败会浪费完整渲染。这比无理由地扩大调用范围更有说服力：执行者知道为什么这个场景值得读取规则。

可以借鉴“触发线索 + 被低估的情形 + 不读会怎样”。但原 description 很长，不意味着越长越好。哪些触发信息应留在入口，要结合宿主的发现机制与上下文成本决定；具体制作细节可以放正文。

具体怎样写，为什么有效

普通写法可能是最后补一句“音频未经试听”。鸭哥的写法更深入：先说明缺少听觉反馈，再推导出不要依赖反复试听调节的方法，优先选择能从输入预测输出结构的路径。因此，测量不再是可选收尾，而进入辅助脚本。

他还约束最终语言：可以说“10.00 秒”“无削波”“稀疏开场与 6 秒处增强符合要求”，不能由这些数字跳到“好听”。给出一条交付措辞示范，等于把抽象的诚实要求落实到最后一句话。

可学的是：写能力限制时，接着写“所以应改变什么”。需要保留边界：这是该工作流的能力假设，不是所有 Agent 永远不能听音；时长与包络也不能证明音乐审美。

具体怎样写，为什么有效

原文不是先介绍一长串工具，再让执行者猜怎么选。它先给一个决定性问题：是否必须命中特定时间码。需要卡点时，用 MIDI 写明确的音符事件；只需要氛围或特殊音色时，考虑生成路径。

作者紧跟一个失败证据：要求“两下独立音符，6 秒进入低音弦乐”，某次生成结果的每秒 RMS 却从头到尾都很响。把同一分镜写成 MIDI 后，包络符合了设想。证据解释了选择，不是只靠“推荐”二字。

这里也要会挑着学。一次服务调用的失败，支持当时这条路线的取舍，不能证明所有生成模型永久无法控制时间。我们应继承决策条件与验证思路，更新具体工具的能力判断。

具体怎样写，为什么有效

这段写法的关键，是先纠正一个直觉：输入的标称长度不等于输出的实际长度。fluidsynth 会继续输出尾音和混响，作者列出两次测量，让“为什么必须裁剪”变得具体。

接着，他对响度又作了类似区分：设置 loudnorm 目标不等于输出一定安全。原文记录一次目标设置后峰值仍到 1.092，因此最终峰值需要测。两段合在一起，教的是不要把“下了命令”当成“得到结果”。

可借鉴的句法是：工具实际会怎样 → 如果省略会坏在哪里 → 所以做这个动作 → 最后测这个结果。目标是让执行者理解规则适用的原因，不是把每个历史参数都写成永恒常量。

具体怎样写，为什么有效

shot.py 先定义物体和相机运动，再用 solve_time 求出物体经过屏幕中线的时刻，存为 E.cross。画面闪光和竖琴音符都依赖这个事件。标题每个字出现的时刻、共同淡出的区间也放在共享时间线上。

注意这比“把秒数集中放一个文件”又多走一步：时刻来自运动关系。修改运动后可以重新求解，而不是让集中保存的旧秒数继续失效。这是一种写进架构的防错方式。

在 Skill 写作上，值得学的是提供能执行的组织方式，而不只说“确保音画同步”。示例恰好证明了这套方式怎么用。但共同来源只能减少分叉，源数据和求解关系本身仍需验证。

具体怎样写，为什么有效

鸭哥先让执行者计算主体在画面中的像素大小，再要求输出时间、视场角、主体尺寸和关键物体所在行的表。坐标出框，就是镜头不成立的具体证据，不必等整段渲染完再判断。

更重要的是，他没有只报告“不可能”。窄视场指向高处时，无法同时容纳地面，原文给出拆成两个焦段、把主体安排在地平线附近、调整需求等方向。好的 Skill 在指出限制后，还应给可行的下一步。

也要核对范本：按原文近似公式，0.52÷52×1920＝19.2 像素，原文字例却写 11；3.1° 时约为 322.1 像素。此图使用复算值。这说明前置计算的方法值得学，但作者写出的数字仍然需要验证。此处是近似构图估算，不是通用精确投影模型。

具体怎样写，为什么有效

这部分来自一个明确失败：技术上干净的画面，仍然被认为俗套、廉价或单调。作者判断，继续调渲染参数解决不了“做错了影片方向”，于是把概念选择放在写渲染器之前。

他也没有停在“多找参考”。参考要提炼成具体评价标准和常见俗套；静帧要覆盖开场、转折和结尾，并达到最终质量；修改要优先改善材质与光，而不是靠增加元素制造忙碌感。每一步都有明确的判断对象。

写 Skill 时可借鉴“把主观词变成可观察依据，再用小样检验”。但 8–12 个参考、6–10 条标准、每轮审稿，是原制作场景的成本选择。风险较小、方向已确定的任务不必机械复制全部关卡；既有明确决定也应复用。

具体怎样写，为什么有效

这里最精彩的不只是“再叫一个 Agent”。作者让审查者脱离创作者的解释，只看观众可见画面与标准，减少作者用意图替代实际效果的倾向。模板还要求打开所有图片，必要时放大局部，并按最终观看尺寸判断。

输出的四部分各有作用：评分必须有证据，问题必须可定位、可修改，Protect 避免修坏已有优点，Re-check 让下一轮继承上一轮的问题清单。最后还限定建议应描述画面，不是泛泛地推荐工具或改流程。

我们写 Skill 时，应该学这种具体的协作接口，而不是简单加一句“交给专家审查”。独立审查有成本，也不保证审美结论正确；它的价值在于提供可复查的另一视角。

具体怎样写，为什么有效

“确认拿到新帧”是一条正确但脆弱的提醒：文件名和数量都可能与上一轮相同。鸭哥把风险写进 runner 的默认行为，非空目录拒绝执行，除非显式要求覆盖；同时记录本次开始时间，供后续检查文件是否属于本轮。

这套设计没有假装一个开关能消除所有风险。--overwrite 不会删除旧文件，新一轮没有覆盖到的帧仍可能残留，因此还要检查时间。它把失败机制拆开，分别提供保护。

值得借鉴的是“文档解释原因，工具承担默认约束，检查提供证据”。如果一种错误反复发生，只往正文追加“务必注意”通常不足以改变结果。

具体怎样写，为什么有效

脚本对三类失败给出不同反馈：削波建议降低增益或响度目标；时长不符提示检查裁剪；包络与分镜不符则要求改音符力度和起点，而不是乱调 loudnorm。这让检查结果直接指向错误层级。

非零返回值本身不能强迫所有调用者停下，调用流程仍须把它当作失败处理。但它提供了明确、可被程序消费的状态，比打印一句警告后正常结束更适合作为门槛。

细读实现也能防止过度总结：该脚本的 render 检查削波、时长与已配置分镜；measure 子命令仅因削波返回非零。不能因为文档写“会检查”就假定每个入口的行为都一样。

具体怎样写，为什么有效

作者记录的不只是“命令失败了”。更深的后果是，之前发给人试听的所谓颤音琴也可能一直是钢琴，已有反馈因而失去了可靠基础。这解释了为什么必须在让人比较之前确认差异。

参数化让变化成为显式输入，减少文本替换静默失败；指纹检查则防止“参数看起来改了，产物却没变”。两者分别保护意图与结果。Skill 写作的价值在于提炼这种可复发机制，而非记住当时用的是哪一个文本工具。

原文把相同指纹说得很确定，实践中应保留边界：时长、峰值、频谱质心是粗指纹，相同不严格等于文件完全相同，不同也不证明目标乐器正确。它适合抓明显的假变体，不能替代所有内容核验。

具体怎样写，为什么有效

上游解释了具体机制：相关双声道在特定混音路径中增大了幅度，结果测出 1.19 并误报削波。因此测量前不能简单降为单声道；文档还给出独立真峰值测量方式用于交叉核对。

修复没有只停在说明里。测试构造峰值 0.84 的双声道正弦波，调用真实 measure 命令，断言结果不含削波、包含正确峰值。一个已知会误杀的正常输入，成为以后防止复发的固定样本。

这里能学到三点：样本输入应有已知性质；测试要走真正可能出错的路径；断言对应那次失败，不笼统检查“命令成功”。测试能证明这一性质，并不能证明全部声音测量或听感都正确。

具体怎样写，为什么有效

鸭哥的路由表不是裸文件列表。它在 When 一列写任务条件、失败症状与所需能力。例如 lookdev 既在开工前触发，也在画面被评价为俗套或单调时触发；detail 则对应细节跨尺度显示的问题。

维护规则进一步要求入口保持一遍能读完，新的专属主题进入相应分册，分册范围改变时也更新路由。由此可以看出作者在同时管理两个东西：知识存放位置，以及执行者到达知识的路径。

可借鉴的是“公共约束常驻，专属内容按需读”。不要把核心限制藏进无人知道要读的附件，也不要为了看起来模块化而把短 Skill 拆碎。

具体怎样写，为什么有效

作者没有把每部片子的主题、着色和布局都抽成一个万能框架。他给公共库设了进入条件：真实影片里几乎一样重写过的东西，才适合放进去。这能减少为想象中的复用过早增加抽象。

公共 runner 还有一个具体选择：预览与成片调用同一个 render_frame。只用 --frames 选择少量帧，而不是再写一份预览循环。这样不会验证了一套代码，交付另一套。

最小示例的作用是把说明、库、脚本接成一个可运行的整体。学习写 Skill 时，要留意这种“用法证明”：只列资源名称不够，读者还需要看到它们如何组合。示例应小而完整，不必代表所有作品风格。

具体怎样写，为什么有效

很多 Skill 的异常处理只剩“安装依赖”或“自行解决”。这段文字更具体：缺 demucs 不意味着所有分析都停下，但歌词不能再依赖分离的人声校准；缺 librosa 则这条分析路径不成立；缺单线字体，画面风格会发生可见变化。

每个替代方案都伴随损失与后续动作。这样，执行者能够判断替代结果是否还满足当前目标，用户也不会收到一个被悄悄缩水却宣称完整的产物。

写 Skill 时，不必穷举所有故障。优先覆盖实际遇到、会改变交付性质的分支。降级不能绕过必需条件；安装、外部写入与发布仍服从宿主和用户授权。

具体怎样写，为什么有效

音频段落列出了用过的音色库与增益，但马上说明数字不通用：换库不测，可能很小声，也可能削波。它不是不提供经验值，而是把经验值连同失效条件一起提供。

作者还把“图像模型可做概念帧”标为未在该角色中验证，同时区分影片中的插图用法已实际用过。这样，执行者能分清实践结果和待试建议，不会因为它们出现在同一文件里就同等相信。

也应保持自己的判断。某些原文对工具能力和审美的措辞仍然很强，不能全部上升为通则。借鉴这份 Skill，既要学它如何建立证据，也要用同样标准复核它的数字、阈值和适用范围。

具体怎样写，为什么有效

连成一条规则：每轮渲染默认使用新目录，因为旧目录中的同名文件可能让你误看上一轮结果。确需复用时显式开启覆盖，记录本轮开始时间，并用 --since 核对帧的新鲜度；未通过的旧帧不能当作本轮成果审查，应先重新生成并复验。此段是依据原实现重新组织的写法示范。

回看裁剪尾音、旧帧保护、假 A/B 和双声道误报，能看见相似的生长方式：真实任务暴露失败，作者解释机制，把稳定部分写成规则，再选择用文字、脚本、示例或测试承接它。不是每条经验都要同时具备全部形式，但每种形式都有自己的职责。

作者在维护规则里甚至明确要求：Skill 正文写可复用规则，不写影片日记；尽可能给现实检查，案例保持简短。这也是本页的落点：学到的是他如何把经验压成可执行知识，而非复制一次影片的每个操作。

你可以从自己一个反复失败的点开始：描述触发条件，查明机制，选择最合适的保护，再用真实任务检验。若规则只增加篇幅，没有改变行为或证据，就值得重写。

本页整理于 2026-09-28。基于公开 MIT 许可项目静态阅读，原则为本文分析，未声称代表作者完整观点，也未声称本轮运行了上游全部测试。交互图仅解释相关机制。