В прошлом, когда мы говорим о видеоклипах ИИ, мы склонны сосредоточиться на «можем ли мы автоматически резать»: загрузить видео, ИИ найдет глупость, автоматически удалит и экспортирует его в виде фрагмента.
Но те, кто действительно делал устные видео, поймут,«Что вырезать» гораздо сложнее, чем «как вырезать»
Является ли слово ошибкой, повторением, нормальной паузой или преднамеренным повторением для подчеркнения?Следует ли исключить первую половину английского слова или сохранить его после того, как он произносится наполовину?ИИ неправильно услышал профессиональное существенное, следует ли изменить субтитры напрямую или пересмотреть вопрос о том, нужно ли удалить это слово?
Эти вопросы определяют, является ли инструмент редактирования искусственного интеллекта «автоматизированной игрушкой» или инструментом, который действительно может быть включен в производственный процесс.
chengfeng-videocut-skills Идея очень интересная:Вместо того, чтобы позволить ИИ взять ножницы напрямую, он должен отвечать за суждение, позволить определенному времени выполнения выполнять, чтобы пользователи могли проверить в ключевых узлах.
Проект GitHub: chengfeng-videocut-skills
Во-первых, что это вообще?
chengfeng-videocut-skills Это Marketplace Plugin для устного трансляции видеоклипов на китайском языке, ориентированного на Codex.
Это не самостоятельный видеоредактор, и вместо того, чтобы упаковать FFmpeg в простой «сценарий авторедактирования», он разделил видеоклипы на набор бизнес-навыков, которые могут быть вызваны агентом.
В настоящее время проект строится на нескольких основных направлениях:
- Вырезание: выявление словных ошибок, повторений, фрагментов, застрявшей английской фразы, мантры и т. д. и формирование списка очерченных слов
- Подписи: создание и обработка субтитров вокруг результатов клипа.
- Картина.: обрабатывает визуальный контент и анимацию в видео.
- ЭкспортПревратите результаты редактирования в окончательное видео.
- Ответить о bug- Составьте вопросы в десенсибилированные и подтвержденные GitHub Issue.
- Проверка обновленияПроверка того, что плагин и время выполнения находятся в совпадающем и надежном состоянии версии.
Самое важное здесь:
Навыки не равны движению редактирования.
Навыки в основном отвечают за семантические суждения и хореографию процессов; работа, связанная с состоянием проекта, вырезаниями, EDL, обработкой медиа и экспортом, передается chengfeng-videocut Runtime.
Такая архитектура вполне соответствует направлению развития продуктов агентов:LLM делают суждения, а определенные системы делают исполнение.
А почему «не разрезают»?
Это один из самых интересных дизайнов всего проекта.
Традиционные агенты искусственного интеллекта легко совершают одну ошибку:
«Я знаю, что пользователи хотят удалить это предложение, поэтому я просто изменил видео».
Проблема заключается в том, что стоимость ошибки, как только видеофайл будет физически изменен, будет высокой.
Таким образом, проект разделяет «семантическое принятие решений» и «физическое исполнение».
В этом навыке, основное, что в конечном итоге получается, это не MP4, а копии:
Проверенная вручную реестр вырезок (Cuts + EDL).
То есть, в первую очередь, AI ответил:
Какие слова должны быть исключены?
Вместо этого:
Сейчас я вырежу видео.
Это может показаться просто различием в процессе, на самом деле это очень важная инженерная граница.
В то время как запись о вырезанных словах может быть неоднократно изменена, проверена и сопоставлена, один вырезанный мультимедиа может означать необратимые изменения в документе.
В этой связи в проекте прямо говорится:
На этап «резания» медиа не вырезаются.
На этом этапе ИИ только делает суждения и записи, пока пользователь не пройдет аудит, последующий экспортируемый навык не перейдет в реальную фазу исполнения.
Это дает всей системе одну важную характеристику:
Ревизируемый, реверсируемый, проверяемый.
Что же происходит с «пересечением»?
Проекты проектируют подрезку как очень четкую сборочную линию
В целом можно понимать следующим образом:
真实视频
↓
逐词转录
↓
建立项目
↓
修正专业词
↓
五轮扫描口误
↓
生成删词表
↓
人工审核
↓
形成最终 Cuts + EDL
↓
交给后续导出流程
Наиболее важными из них являются три промежуточных шага:
Изменение, исключение, ревизия.
Первый шаг: исправить «неправильное слово»
Многие системы автоматического редактирования имеют потенциальную проблему:
Он принимает результаты транскрипции ASR непосредственно как факты.
Однако для устного вещания на китайском языке ASR часто появляются ошибки в распознавании профессиональных терминов, названий продуктов и английских слов.
Например:
用户真正说的是：
Grok
ASR 可能得到：
grock
Если последующий ИИ делает суждения непосредственно на основе ошибочного текста, может возникнуть цепочка ошибок.
Поэтому в данном проекте «изменение» помещено перед «удаление».
Он имеет словарь AI Term Dictionary и поддерживает собственный словарь пользователя.
Процесс в целом:
原始 Transcript
↓
通用词典
↓
用户词典
↓
修字表
↓
进入删词分析
И вот один очень важный принцип:
Изменение слов может изменить только выражение текста, но не время, количество слов и wordId.
Это означает, что
错误词 → 正确词
может быть изменено;
Но:
错误词 → 修改时间戳
错误词 → 修改词序
错误词 → 添加不存在的词
Этого не должно произойти.
Это ограничение имеет решающее значение, поскольку последующее редактирование видео зависит от словной временной шкалы.Если текст не связан со временной шкалой, результаты последующего редактирования могут быть искажены.
Вторая дверь: пять сканирования, а не «одноразовый поиск дерьма»
Это еще один очень ценный дизайн проекта.
Многие люди впервые разрабатывают AI Clipping Agent и могут задать непосредственно модели задачу:
«Пожалуйста, помогите мне выяснить все ошибки, повторения и глупости».
Это кажется естественным, но проблема в том, что:
Позвольте модели судить слишком много типов одновременно, чтобы критерии суждения загрязняли друг друга.
Этот проект был разработан совершенно по-другому:
Пять раундов сканирования
Первый раунд:
Повторение
Второй раунд:
Изменения и изменения
Третий раунд:
Ошибка повторяет
Четвертый раунд:
Английский кастрюль
Пятый раунд:
Условия и слова.
То есть, каждый раунд отвечает только за одно решение.
Например, в первом раунде задаются следующие вопросы:
Есть ли здесь повторение?
И одновременно не спрашивать:
Разве это манта?Разве это фраза?Стоит ли подумать о паузе?
Преимущества такого подхода очевидны.
Каждый раунд превращается в более мелкий, более четкий вопрос.
Почему «повторение» следует отделять от «манты»?
Потому что степень их объективности совершенно различна.
Например:
«Эта функция... эта функция... на самом деле очень полезна».
О таких повторениях, как правило, легче судить.
Однако:
"На самом деле, я думаю, что эта штука все равно полезна".
Действительно ли «на самом деле» или «не следует» убрать?
Ответ не является полностью объективным.
Это связано с личными привычками пользователя.
Кто-то любит чистую трансляцию:
«Эта функция работает очень хорошо».
Было также высказано мнение о том, что
«На самом деле, я думаю, что это очень полезно».
Говорят ближе к естественному.
Таким образом, проект будетУстановки пользователяВстроен в систему суждения о языке.
Приоритетными задачами являются следующие:
用户偏好
>
用户判例
>
通用判例
Это означает, что клипы ИИ не просто стремятся к «самым коротким языкам», а постепенно изучают:
Какой вид трансляции нравится пользователю.
Из «одноразового решения ИИ» в «поддающийся аудиту бухгалтерский учет»
Проекты не дают вывода ИИ:
«Рекомендуется исключить 37».
Вместо этого требуется структурированный глоссарий.
Например:
| # | Время | Тип | Удалить | Остальные читать. | Риски | Основания |
|---|---|---|---|---|---|---|
| 1 | 00:12 | Повторение | А эта функция? | Эта функция на самом деле | Низкий | Дело R2 |
| 2 | 02:31 | Изменение формулировки | Например, я позволяю ему следить. | Например, я позволяю Грок следить за мной. | Высокая | Дело R5 |
Это очень важно.
Потому что суждение AI от:
"Я думаю, что это должно быть исключено".
превращается в:
"Я считаю, что это относится к определенной категории, в соответствии с определенным правилом, и поэтому предлагаю исключить эти слова, и уровень риска является высоким".
Последний действительно имеет.Ревизия ценности。
Пользователям не нужно пересматривать все видео, чтобы понять, что делает ИИ, но вместо этого они могут проверить списки вычерков.
Для чего нужны «периодические предложения»?
Это очень детальный, но очень практичный дизайн.
В списке слова исключения можно указать только пользователю:
Какие слова были исключены?
Но если пользователь действительно записывает фразу три раза, проблема будет другой.
Например:
第一遍：因为今天有什么……
第二遍：因为今天有什么……
第三遍：因为今天有什么……
Вопросы, которые действительно нуждаются в ревизии, могут быть:
Какие три раза сохранить?
Так, проект дополнительно разработал «Таблицу повторяющихся предложений».
Например:
| Предложение | Я сказал несколько раз. | Какой раз сохранить | Сколько раз удалить? | Риски |
|---|---|---|---|---|
| Потому что сегодня что-то... | 3 | Третий раз. | Первый, второй раз | Низкий |
Это говорит о том, что проект не просто понимает клип как:
Исключить ряд слов.
Вместо этого, мы понимаем фрагмент как:
Восстановление более естественного пути выражения языка.
Когда пользователь будет вмешиваться?
Хороший агент не позволяет пользователям «не заботиться о чем-либо» или «подтверждать каждый шаг».
Проект фактически ограничивает точки вмешательства пользователя.
Пользователи в основном говорят в трех ключевых местах:
1.Выбор однородного проекта
Если это видео было вырезано ранее, пользователь должен выбрать:
Продолжить предыдущий проект или начать сначала?
2.Проверка Studio
После того, как ИИ завершает предложение, результаты передаются пользователям для проверки в Studio.
3.Завершение подтверждения
После подтверждения пользователем переход к последующему процессу исполнения.
Это очень типичное:
Низкочастотные, высокоценные ручные вмешательства.
Агент выполняет большое количество механических процессов самостоятельно, но оставляет узлы, которые действительно влияют на конечный результат.
Студия не создает собственную «страницу аудита».
Проект также имеет границу безопасности, которую легко игнорировать:
Если Runtime не установлен, Agent не может временно использовать замену «Рецензионной столы».
Это правило очень важно.
Поскольку с точки зрения агента наиболее легко возникает такое поведение:
Runtime 不存在
↓
Agent 想办法
↓
自己写一个 HTML
↓
做一个假的审核界面
↓
继续完成任务
На первый взгляд, это называется «умным».
Фактически, это может привести к расторжению всего контракта на продукцию.
В этой связи в проекте четко предусматривается:
Когда время выполнения отсутствует, следует остановить, а не создать несовместимую замену.
Это, на самом деле, отражает очень зрелую философию агента инженерии:
Границы возможностей агента должны зависеть от контракта на продукт.
И не «после того, как выполнить задачу».
Разделение Runtime и Skill
Вся архитектура может быть упрощена на:
Codex
│
┌───────┴────────┐
│ │
Skills Plugin UI
│
↓
业务判断 / 流程编排
│
↓
chengfeng-videocut Runtime
│
┌─────┼──────────────┐
│ │ │
项目 Cuts / EDL Studio
│
↓
媒体处理 / Render / Verify
Основная идея такого разделения состоит в следующем:
LLM не должен быть единственным менеджером состояния всей системы.
Состояние проекта, редакции, EDL, файлы мультимедиа, состояние сервиса и т. д. управляются временем выполнения.
Агент несет ответственность только за:
理解用户
↓
调用能力
↓
读取结果
↓
做判断
↓
组织下一步
Вместо того, чтобы тайно поддерживать набор «фальшивых статусов проекта».
XII. Почему в проекте особое внимание уделяется Revision и CAS?
Если внимательно посмотреть на дизайн проекта, то вы увидите, что он очень акцентирован на:
projectId- Стадия рабочего процесса
- Пересмотр проектов
- Пересмотр сокращений
- Редакция EditList
- КАС
Эти концепции показывают, что разработчики думают не только о «успехе одного запуска», но и о:
Как избежать ошибочного переопределения состояния при повторении действий агента на реальный проект?
Например:
Agent A
读取 revision = 12
用户同时修改项目
revision = 13
Agent A
尝试基于 revision 12 写入
Если в системе нет контроля версий, Агент А, скорее всего, перезапишет новые изменения пользователя.
Таким образом, revision / CAS позволяет системе знать:
«Вы уже не работаете с той версией, которую вы только что видели. »
Это очень важно для продуктов агента.
Поскольку традиционное программное обеспечение GUI обычно имеет четкие границы состояния и действий пользователя, агент является асинхронным, повторным и автоматизированным агентом, который может повторяться вызыванием инструментов.
Без управления версиями состояния агенты легко записывают старые состояния обратно в новый проект.
В дизайне установки также отражены «приоритет определенности».
Проект не просто говорит пользователям:
npm install xxx
Затем заканчивается.
Он также устанавливает строгие ограничения на установку времени выполнения.
Например, фиксированные версии времени выполнения:
Plugin 0.10.8
↓
Runtime v0.4.8
Вместо этого:
latest
Почему?
Потому что latest Они будут дрейфуть.
Время выполнения, установленное сегодня, и Время выполнения, установленное завтра, могут быть не одно и то же.
Это очень опасно для плагина агента, который зависит от строгого контракта продукта.
В этой связи в проекте подчеркивается:
Фиксированная версия + выпуск + проверка SHA-256 + проверка доктора.
Это можно понимать как:
发现 Runtime
↓
检查版本
↓
确认 Release
↓
下载
↓
SHA-256 校验
↓
安装
↓
doctor
↓
确认服务健康
Skill продолжает работать только после создания всей ссылки.
14 Почему услуги не могут быть доступны nohup？
В проекте также конкретно говорится, что плагины не должны использоваться непосредственно:
launchctl
nohup
foreground server
Тайно управлять продуктами и услугами.
Runtime несет ответственность за жизненный цикл обслуживания.
Используйте LaunchAgent на уровне пользователя в macOS и Windows Task в Windows.
Это означает, что
Текущий терминал Codex не является владельцем жизненного цикла сервиса продукта.
В противном случае легко появится:
终端关闭
↓
服务消失
Codex 重启
↓
又启动一个服务
第二个服务
↓
端口冲突
В итоге весь рабочий процесс агента становится очень нестабильным.
Таким образом, в проекте используются следующие методы:
Заявление ensure-running.
Агент должен просто сказать продукту:
Убедитесь, что сервис доступен.
Что касается того, как сервис запускается, как он находится и как восстанавливается, то время выполнения управляет самим.
15. Что означает поддержка Windows?
Этот проект не является сценарием только для macOS.
В README четко указано, что Runtime официально поддерживает Windows с версии 0.4.2 и выполняет проверку ссылок для установки, постоянного обслуживания, самовосстановки, перезагрузки, архивирования и экспорта.
Смысл этого заключается в том, что:
Он начал эволюционировать от «инструмента для разработчиков» до «настоящего кроссплатформенного агента».
В частности, в области обработки видеозаписей такие задачи включают:
- FFmpeg
- FFprobe
- Bun
- Node.js
- Chrome
- Локальный документ
- Бун-офис
- визуализация в браузере
Ненадлежащая обработка любого элемента между платформами в конечном итоге делает поведение агента непредсказуемым.
Таким образом, включение этих зависимостей в управляемые каталоги времени выполнения, а не заставление плагинов искать окружающую среду системы, является более надежным подходом к продуктам.
Реальная ценность этого проекта - это не «ИИ может резать видео».
Если посмотреть только на поверхность, то это кажется только одним:
«ИИ автоматически разрезает устные китайские видео»
Проекты.
Но, если смотреть на это с инженерной точки зрения, то, что это действительно ценно, это еще три ключевых слова:
1.Разделение суждений и исполнения
AI:
决定删什么
Время работы:
决定怎么安全地执行
2.ИИ рекомендует разъединение с ручным подтверждением
AI:
提出删词方案
Пользователи:
确认删什么
Системы:
执行最终版本
3.Разделение естественного языка от определенных состояний
Agent:
理解“帮我继续剪上一版”
Время работы:
projectId = xxx
revision = 17
cuts = ...
EDL = ...
Эти три уровня разделения, на самом деле, заслуживают большего внимания, чем "какая модель используется".
Это также представляет собой новый подход к проектированию инструментов ИИ.
Традиционное программное обеспечение обычно:
用户
↓
按钮
↓
程序
↓
结果
Программное обеспечение Agent ближе к:
用户自然语言
↓
Agent
↓
Skill
↓
工具/API
↓
确定性 Runtime
↓
结果
Изменились и проблемы.
Наиболее важными в традиционном программном обеспечении являются:
А у вас есть дизайн?
Более важными проблемами программного обеспечения агента стали:
Соблюдает ли агент правильные границы операций?
Например:
- Можно ли создать видео, когда нет реального видео?
- Можно ли создать собственную замену, если время выполнения не существует?
- Может ли старый пересмотр перезаписывать новый?
- Может ли пользователь вырезать сразу, если он не подтвердил?
- Обновление тайно переключается на неизвестную версию?
- А. С. ошибается, можно ли догадаться?
- Будет ли после неудачи тайно переключить порт и запустить другой сервис?
На самом деле, это «границы безопасности» продуктов агентов.
и chengfeng-videocut-skills Многие дизайны отвечают на эти вопросы.
Какие перспективы можно увидеть в этом проекте?
Если вы сделаете еще один шаг вперед, то в будущем действительно зрелые продукты могут не быть:
"ИИ поможет вам автоматически вырезать видео".
Скорее всего, это:
«ИИ понимает ваши привычки редактирования, предлагает объясняемую, проверяемую и ретроактивную программу редактирования, которая затем выполняется определенным механизмом редактирования».
Пользователям даже не нужно говорить AI каждый раз:
«Немного меньше слов».
Система может постепенно формироваться из исторического подтверждения:
用户偏好
+
用户判例
+
通用规则
В конечном счете формируется индивидуальный стиль клипа.
Таким образом, «AI Clipping» превратился из единовременной автоматической функции в:
Агент, который все больше и больше понимает ваш клип.
Подлинно зрелый ИИ - это не «выполнение», а «знание того, когда остановиться и спросить вас».
chengfeng-videocut-skills Не то, сколько навыков он имеет, и не то, что он может вызвать FFmpeg, ASR или Studio.
По-настоящему стоит отметить, что он устанавливает очень четкий набор границ:
ИИ отвечает за понимание и суждение.
Время выполнения отвечает за определённое выполнение.
Система версии отвечает за состояние защиты.
Пользователи несут ответственность за принятие важнейших решений.
Результаты аудита становятся опытом для следующего раунда суждения ИИ.
Этот дизайн превращает видеоклипы из задачи «позволить ИИ манипулировать с мультимедийными файлами» в отслеживаемую, проверяемую, восстанавливаемую и устойчивую обучаемую производственную линию.
Для тех, кто изучает сочетание Agent + Professional, этот проект является отличным примером:
Не позволяйте агенту заменить весь продукт.
Сделайте агента интеллектуальным ореографическим слоем над продуктом.
Возможно, это самое лучшее направление, которое стоит изучить в будущем для нативных профессиональных инструментов искусственного интеллекта.