過去にAIのビデオクリップについて話していたとき、“自動カットできるかどうか”に焦点を当てがちでした。ビデオをアップロードし、AIがナンセンスを見つけ、自動的に削除し、シートをエクスポートしました。

実際に動画を見た人は、“何を切るか”は“どのように切るか”よりも難しい。

文は間違い、反復、通常の停止、または強調のために意図的に繰り返されるか。英語の単語が半分話されてからもう一度言われたら、最初の段落を削除するか、保持するか。AIが専門用語を聞き間違えた場合、字幕を直接修正すべきか、削除すべきかどうかを再判断すべきか？

これらの質問によって、AI編集ツールが“自動化されたおもちゃ”か、実際に生産プロセスに入るツールかが決まります。

chengfeng-videocut-skills アイデアは興味深い：AIに直接ハサミを持たせず、AIに判断を任せ、決定論的ランタイムに実行を任せ、ユーザーが重要なノードで監査を行うようにします。

GitHubプロジェクト-chengfeng-videocut-skills

1.それは何ですか。

chengfeng-videocut-skills Codexのためのマーケットプレイスプラグインのビデオクリップ。

スタンドアロンのビデオエディタではなく、FF mpegをパッケージ化して単純な“自動クリップスクリプト”を作成するのではなく、ビデオクリップをエージェントが呼び出すことができるビジネススキルのセットに分割します。

プロジェクトは現在、いくつかのコアリンクを中心に展開しています。

• カットアウト·ブロードキャスト：口の間違い、繰り返し、残文、英語のカード、マントラなどを識別し、削除された単語の帳簿を作成します。
• 字幕付き：クリップの結果を中心にタイトルを生成および処理します。
• 画面の表示：ビデオ内のビジュアルコンテンツとアニメーションを処理します。
• エクスポートエクスポートレビュー後の編集結果を実際に最終的な動画に変換します。
• バグ報告のお知らせ問題を非感作化され検証されたGitHub問題に整理します。
• アップデートの確認プラグインとランタイムが一致する信頼できるバージョン状態であることを確認します。

ここで最も重要なのは：

スキルは編集エンジンと同じではない。

スキルはセマンティック判断とプロセスオーケストレーションを担当します。プロジェクトステータス、カット、EDL、メディア処理、エクスポートに関する実際の作業は担当します。 chengfeng-videocut Runtime。

このアーキテクチャは、エージェント製品の方向性と非常によく一致しています。LLMが判断を行い、決定論的システムが実行を行う。

---

なぜ“直接カットしない”のか？

これは、プロジェクト全体で最も興味深いデザインの一つです。

従来のAIエージェントは簡単に間違いを犯します。

“ユーザーがこの文章を削除したいと思っているのはわかっていたので、動画を直接修正した。

問題は、ビデオファイルが物理的に変更されると、エラーのコストが高くなります。

そのため、プロジェクトは“意味的意思決定”と“物理的実行”を分離する。

“カットアウト”スキルでは、最終的な出力のコアはMP 4ではなく、コピーです。

手動でレビューされた削除元帳（カット+ EDL）。

つまり、AIが最初に答えたのは：

どの単語を削除すべきか？

代わりに：

今から動画をカットします。

これはプロセスの違いのように見えるかもしれませんが、実際には非常に重要なエンジニアリング境界です。

削除された元帳は繰り返し変更、レビュー、比較することができ、完了したメディアカットは不可逆的な文書変更を意味する可能性がある。

プロジェクトは明確に述べている：

“カット”はメディアをカットしません。

この段階では、AIは判断と記録のみを行い、ユーザーが監査し、その後のエクスポートスキルが実際の実行段階に入るまで続きます。

これにより、システム全体に1つの重要な機能が与えられます。

监査可能、ロールバック、検讨可能。

---

3.“カット”とは何か？

プロジェクトは非常に明確な組立ラインにカットカットを設計しました。

一般的に理解できる。

真实视频
   ↓
逐词转录
   ↓
建立项目
   ↓
修正专业词
   ↓
五轮扫描口误
   ↓
生成删词表
   ↓
人工审核
   ↓
形成最终 Cuts + EDL
   ↓
交给后续导出流程

最も価値のあるのは、中間の3つのステップです。

修正、削除、レビュー。

---

第一に、“間違った言葉”を正しく修正する。

多くの自動編集システムには潜在的な問題があります。

ASRの転写結果を事実として直接扱います。

しかし、中国語放送の場合、ASRはしばしば専門用語、製品名、英語の単語認識エラーが発生します。

例えば：

用户真正说的是：

Grok

ASR 可能得到：

grock

後者のAIが誤ったテキストに基づいて直接判断を行うと、連鎖エラーが発生する可能性があります。

このプロジェクトでは、“削除”の前に“修正”を置きます。

AI Term Dictionaryのセットがあり、ユーザー独自の辞書もサポートしています。

流れは大体：

原始 Transcript
      ↓
通用词典
      ↓
用户词典
      ↓
修字表
      ↓
进入删词分析

ここに重要な原則があります

修正は文字表現のみを変更でき、時間、単語数、wordIdは変更できません。

これは、

错误词 → 正确词

修正可能です。

しかしながら、

错误词 → 修改时间戳
错误词 → 修改词序
错误词 → 添加不存在的词

起こるべきではない。

その後の動画編集はワードごとのタイムラインに依存するため、この制約は重要です。テキストとタイムラインがずれていると、後のクリップの結果が歪むことがあります。

---

2番目のゲート：“AIがゴミを見つけるために一度だけ”ではなく、スキャンの5ラウンド。

これも非常に価値のあるプロジェクトです。

AIクリップエージェントを初めて設計する人は、モデルに直接タスクを与えるかもしれません。

“すべての間違い、反復、ナンセンスを見つけるのを手伝ってください。

自然に見えますが問題は

一度に多くの型を判断させると、判断基準が互いに汚染されます。

このプロジェクトは全く異なるアプローチを取った。

5ラウンドスキャン

最初のラウンド：

繰り返します。

第2ラウンド：

残句と言い換え

第3ラウンド：

誤言を繰り返す

第4ラウンド：

英語のcachel

第5ラウンド：

言葉と言葉のトーン

つまり、各ラウンドには1つの判断しかありません。

最初のラウンドでは：

繰り返しがありますか？

同時に尋ねないでください

これはマントラですか？残句でしょうか。休憩を検討すべきか？

その利点は明らかです。

各ラウンドは、より小さく、より明確な問題になります。

---

なぜ“反復”と“反復”を区別するのか？

客観性が全く違うからです。

例えば：

“この機能は···この機能は···実はとても使いやすい”

この繰り返しは通常判断が容易です。

しかしながら：

“実は、これは本当に役に立つと思います。

“実際に”“それとも”は削除すべきではないのか？

答えは完全に客観的でない。

これはユーザーの個人的な表現習慣に関係している。

誰もがきれいな声を好む：

“この機能は非常に良い”。

他の人も考える：

“我吧，的。”

自然な会話に近い。

このプロジェクトはユーザーの嗜好言語判断システムに組み込まれています

優先順位は概ね：

用户偏好
   >
用户判例
   >
通用判例

つまり、AIクリップは単に“最短言語”を追求するのではなく、徐々に学習していきます。

このユーザーはどんな種類のメッセージを好むか。

---

“1回限りのAI意思決定”から“監査可能な削除元帳”へ

プロジェクトはAIに文を出力させません：

>> 37を削除する。

代わりに、構造化された削除要約表を作成する必要がある

例えば：

#	時間は	タイプの種類	削除する	残りの読書。	リスクは	ベースは
1	00:12	繰り返します。	この機能は？	この機能は実際に	低い。	ケースR 2
2	02:31	変更の変更	追跡させてください。	私はGrokを追跡する。	ハイ·ハイ	R 5のケース

これはとても重要です。

AIの判断から：

“ここはカットすべきだと思う”。

となった。

“ここはある種のルールに基づいていると思うので、リスクが高いという言葉を削除することをお勧めします。

後者は本当に存在する。監査価値。

AIが何をしているのかを理解するために動画全体を見る必要はなく、削除された単語を確認できます。

---

なぜ“繰り返し”が必要なのでしょうか？

非常に詳細ですが、非常に実用的なデザインです。

単語の削除はユーザーにしか伝えられません：

どの単語が削除されますか？

しかし、ユーザーが実際に文を3回録音すると、問題は異なります。

例えば：

第一遍：因为今天有什么……
第二遍：因为今天有什么……
第三遍：因为今天有什么……

レビューが必要な本当に問題は次のとおりです。

3回はどれを維持するか。

そこで、プロジェクトは“繰り返し文リスト”を追加しました。

例えば：

文の意味	何度も言った。	いつ保存するか。	何回削除する？	リスクは
今日は何があるから···	3	3回目。	1回か2回目	低い。

つまり、プロジェクトは単にクリップを以下のように解釈しません。

単語を削除する。

代わりにクリップを理解する：

より自然な言語表現の経路を再構築する。

---

ユーザーはいつ関与しますか？

優れたエージェントは、ユーザーに“何でも”させたり、“すべてのステップで確認”させたりするものではない。

プロジェクトは実際にユーザーの介入ポイントを制限します。

ユーザーは主に3つの重要な場所で話します。

1.同一プロジェクトの選択

この動画が以前にカットされた場合は、ユーザーが選択する必要があります。

前のプロジェクトを継続するか、また始めるか。

2. Studio監査

AIが提案を完成させると，結果をユーザに渡してStudioでチェックする.

3.完了確認済み

ユーザが確認した後、後続の実行フローに入ります。

これは非常に典型的です：

低周波、高価値の人工介入。

エージェントは多くの機械的プロセスを自分で行いますが、最終結果に影響を与えるノードは人間に任せます。

---

StudioはAI自体が“レビューページを作成する”のではない

このプロジェクトには見落とされがちなセキュリティ境界もあります。

Runtimeがインストールされていない場合、エージェントは一時的に代替品の“ベンチ”をスワイプできません。

このルールはとても重要です。

エージェントの観点からは、次のような振る舞いが最も起こりやすいからです。

Runtime 不存在
      ↓
Agent 想办法
      ↓
自己写一个 HTML
      ↓
做一个假的审核界面
      ↓
继续完成任务

表面上、これは“スマート”と呼ばれます。

実際には、製品契約全体が無効になります。

プロジェクトの要件は：

互換性のない代替品を作るのではなく、ランタイムが欠けている場合は停止します。

これは非常に成熟したエージェントエンジニアリングコンセプトを反映しています。

エージェントの能力境界は製品契約に従う必要があります。

“仕事ができる限り”ではない。

---

11.ランタイムとスキルの階層化

全体の構造は以下のように単純化できる。

             Codex
               │
       ┌───────┴────────┐
       │                │
     Skills          Plugin UI
       │
       ↓
业务判断 / 流程编排
       │
       ↓
chengfeng-videocut Runtime
       │
 ┌─────┼──────────────┐
 │     │              │
项目   Cuts / EDL     Studio
 │
 ↓
媒体处理 / Render / Verify

この階層化の中心的な考え方は、

LLMはシステム全体の唯一の状態マネージャであるべきではない。

プロジェクトの状態、リビジョン、EDL、メディアファイル、サービスの状態などは、Runtimeによって管理されます。

エージェントのみが担当する：

理解用户
↓
调用能力
↓
读取结果
↓
做判断
↓
组织下一步

“偽のプロジェクトステータス”を維持する代わりに。

---

なぜRevisionとCASを重視するのですか？

プロジェクトデザインをよく見ると、以下を重視していることがわかります。

• projectId
• ワークフローステージ
• プロジェクトの改訂
• Cuts Revision
• EditList revision
• CAS

これらの概念は、開発者が“単一の実行の成功”だけでなく、考えることを示しています。

エージェントが実際のプロジェクトで繰り返し操作するときに、状態が誤って上書きされないようにするには？

例えば：

Agent A
读取 revision = 12

用户同时修改项目

revision = 13

Agent A
尝试基于 revision 12 写入

システムにバージョン管理がない場合、エージェントAはユーザーの新しい変更を上書きする可能性があります。

Revision/CASはシステムに次のことを知らせる。

“あなたが今やっているのは、今見たバージョンではありません。

これはエージェント製品にとって非常に重要です。

従来のGUIソフトウェアは一般的に明確な状態とユーザー操作の境界を持つのに対し、エージェントは非同期で再試行可能で、ツールを繰り返し呼び出す自動化された主体である。

状態のバージョン管理がなければ、エージェントは古い状態を新しいプロジェクトに簡単に書き戻します。

---

13、設置設計も“決定的優先”を反映している

このプロジェクトはユーザーに伝えません。

npm install xxx

そして終わり。

また、ランタイムのインストールにも厳しい制限があります。

固定ランタイムの例：

Plugin 0.10.8
        ↓
Runtime v0.4.8

代わりに：

latest

なんで？

なぜなら、 latest 漂流します。

今日インストールされるランタイムと明日インストールされるランタイムは同じではありません。

これは、厳格な製品契約に依存するAgent Pluginにとって非常に危険です。

そのため、プロジェクトは

修正バージョン+リリース+SHA-256チェック+ doctorチェック。

理解できるのは

发现 Runtime
   ↓
检查版本
   ↓
确认 Release
   ↓
下载
   ↓
SHA-256 校验
   ↓
安装
   ↓
doctor
   ↓
确认服务健康

スキルはリンク全体が確立された場合にのみ動作します。

---

14.なぜサービスがないのか nohup？

また、プラグインを直接使用しないことも明記しています。

launchctl
nohup
foreground server

製品サービスを管理する。

Runtimeは、サービスのライフサイクルに責任を持ちます。

macOSではユーザーレベルのLaunchAgentを、WindowsではWindows Taskを使用します。

これは、

Codex現在の端末は製品サービスのライフサイクル所有者ではありません。

簡単に現れます：

终端关闭
   ↓
服务消失

Codex 重启
   ↓
又启动一个服务

第二个服务
   ↓
端口冲突

最終的に、エージェントのワークフロー全体が非常に不安定になります。

そのため、プロジェクトは：

宣言式 ensure-running。

エージェントは製品に伝えるだけです。

サービスが使用可能な状態であることを確認します。

サービスの開始方法、維持方法、復旧方法は、ランタイム自身によって管理されます。

---

Windowsサポートとは何ですか？

このプロジェクトは、単にmacOS向けのスクリプトではない。

READMEでは、Runtimeはv 0.4.2からWindowsを正式にサポートしており、インストール、常駐サービス、クラッシュ修復、再起動、アーカイブ、エクスポートのリンク検証が可能であることが明記されている。

その背後にある意味：

“開発者ツール”から“真のクロスプラットフォームエージェント製品”へと進化し始めました。

特に、ビデオ処理は以下を含むタスクです。

• FF mpeg
• FFprobe
• BUNさん
• Node.js
• Chromeは
• ローカルファイル
• バックグラウンドサービス
• ブラウザレンダリング[ブラウザレンダリング]

プラットフォーム間で不適切に扱われると、エージェントの動作が予測不可能になります。

プラグインがシステム環境を探すのではなく、これらの依存関係をランタイムの管理ディレクトリに含めることが、より信頼性の高い製品化のアイデアです。

---

このプロジェクトの本当の価値は“AIが動画をカットする”ことではない

表面だけを見ると、これは1つだけのように見えます：

“AIは自動的に中国語の動画をカット”

プロジェクトの一つ。

しかし、エンジニアリングの観点から本当に価値があるのは、他の3つのキーワードです。

1.判断と実行の分離

AIより：

决定删什么

Runtime：

决定怎么安全地执行

---

2. AIアドバイスと人間確認の分離

AIより：

提出删词方案

ユーザー：

确认删什么

システム：：

执行最终版本

---

3.自然言語と決定論的状態の分離

エージェント：

理解“帮我继续剪上一版”

Runtime：

projectId = xxx
revision = 17
cuts = ...
EDL = ...

この3層の分離は、実際には“どのモデルを使用するか”よりも注目に値します。

---

また、AIツールを設計する新しい方法も表しています。

従来のソフトウェアは：

用户
 ↓
按钮
 ↓
程序
 ↓
结果

エージェントソフトウェアは次のように近い。

用户自然语言
 ↓
Agent
 ↓
Skill
 ↓
工具/API
 ↓
确定性 Runtime
 ↓
结果

問題も変わります。

従来のソフトウェアで最も重要なのは：

UIはよく設計されているか？

エージェントソフトウェアのより重要な問題は次のとおりです。

エージェントは適切な運用境界を守っているか。

例えば：

• 本物のビデオがないときに作成できますか？
• ランタイムが存在しない場合、代替品を作成できますか？
• 古いリビジョンは新しいリビジョンを上書きできますか？
• ユーザーが確認できない場合はカットできますか？
• アップデートは密かに未知のバージョンに切り替わりましたか？
• ASRは間違っていますか？
• 失敗後、別のサービスを起動するためにポートを変更しますか？

これらはエージェント製品の“セキュリティ境界”です。

そして、 chengfeng-videocut-skills 多くのデザインはこれらの質問に答える。

---

18このプロジェクトの未来は何でしょうか。

“AIビデオクリップ”をさらに一歩進めると、将来の真に成熟した製品は次のようにはならないかもしれません。

“AIが動画を自動的にカットしてくれる”

そしておそらく、より：

“AIはあなたの編集習慣を理解し、解釈可能で、レビュー可能で、追跡可能な編集提案を作成し、それを決定論的編集エンジンが実行します。

ユーザーは毎回AIに言う必要はありません。

“Put Less a Put”

システムは履歴確認から徐々に形成できます。

用户偏好
+
用户判例
+
通用规则

最終的には個人的な編集スタイルになる。

したがって、“AIクリップ”は1回限りの自動化機能から次のようになります。

あなたの編集エージェントをますます理解しています。

---

真の成熟したAIとは、“自分のためにやる”ことではなく、“いつ立ち止まって聞くべきかを知る”ことです。

chengfeng-videocut-skills 最も興味深いのは、スキルの数やFF mpeg、ASR、Studioを呼び出すことができることではありません。

本当に注目すべきは、非常に明確な境界線を設定していることです。

AIは理解と判断を担当します。

Runtimeは決定的実行を担当します。

バージョンシステムは状態を保護する責任がある。

ユーザーは重要な意思決定を行う。

監査結果は、次のAI 判断ラウンドの経験となります。

この設計により、ビデオクリップは“AIがメディアファイルを操作できるようにする”というタスクから、追跡可能、監査可能、ロールバック可能、持続可能な学習パイプラインに変わります。

エージェントとプロフェッショナルソフトウェアの組み合わせを探している人にとって、このプロジェクトは素晴らしい例です。

エージェントに製品全体を置き換えさせないでください。

エージェントを製品上のインテリジェントオーケストレーションレイヤーにします。

これは、将来のAIネイティブプロフェッショナルツールの最も価値のある方向性かもしれません。