In the past, when we talked about AI video editing, it was easy to focus on "whether it can be automatically cut": upload a video, AI finds the nonsense, automatically deletes it, and then export a piece.
But those who have actually made oral videos will find that"What to cut" is far more difficult than "how to cut".
Is a sentence a slip of the tongue, repetition, normal pause, or is it deliberately repeated for emphasis? An English word is said halfway and then said again. Should the first half be deleted or kept? AI misheard a professional term. Should we directly modify the subtitles or re-judge whether this sentence needs to be deleted?
These issues determine whether an AI editing tool is an "automated toy" or a tool that can truly enter the production process.
chengfeng-videocut-skills The idea is very interesting:Instead of letting AI directly hold scissors, AI is responsible for judgment, deterministic Runtime is responsible for execution, and users are allowed to conduct audits at key nodes.
GitHub project: chengfeng-videocut-skills
1. What is it?
chengfeng-videocut-skills It is a Chinese oral video clip Marketplace Plugin for Codex.
It is not a stand-alone video editor, nor does it wrap FFmpeg to make a simple "automatic clip script". Instead, it breaks up video clips into a set of business skills that can be called by Agents.
The project currently revolves around several core links:
- Jiankou sowing: Identify slip of the tongue, repetition, broken sentences, English jams, mantra, etc., and form a ledger of deleted words.
- subtitles: Generate and process subtitles around the editing results.
- picture: Handle visual content and animation in videos.
- derived: Really turn the review editing results into the final video.
- Report bugs: Organize questions into desensitized and confirmed GitHub Issues.
- check for updates: Check that the Plugin and Runtime are in matching, trusted version states.
The most important point here is:
Skill is not equal to editing engine.
Skill is mainly responsible for semantic judgment and process choreography; work that really involves project status, Cuts, EDL, media processing and export is assigned to chengfeng-videocut Runtime。
This architecture is actually very consistent with the development direction of Agent products:LLM makes judgment and deterministic systems make execution.
2. Why not let AI cut directly?
This is one of the most noteworthy designs in the entire project.
Traditional AI agents can easily make one mistake:
"I know the user wants to delete this sentence, so I directly modify the video."
The problem is that once a video file is physically modified, the cost of errors is high.
Therefore, the project separates "semantic decision-making" from "physical execution."
In the skill of "cutting mouth broadcasting", the core thing that is ultimately produced is not an MP4, but an:
Manually reviewed deleted word ledger (Cuts + EDL).
In other words, AI's first answer is:
Which words should be deleted?
Instead of:
I will cut the video now.
This may seem to be just a process difference, but it is actually a very important engineering boundary.
Because a deleted ledger can be revised, reviewed, and compared repeatedly; while a completed media cut may mean irreversible document changes.
Therefore, the project clearly stipulates:
There is no media cut during the "cutting and broadcasting" stage.
AI only makes judgments and records at this stage. Until the user passes the review, the subsequent export skills will not enter the real execution stage.
This gives the entire system a very important feature:
Can be audited, rolled back, and reviewed.
3. What exactly happens in a "cutting broadcast"?
The project designed cutting mouth broadcasting into a very clear assembly line.
It can be roughly understood as:
真实视频
↓
逐词转录
↓
建立项目
↓
修正专业词
↓
五轮扫描口误
↓
生成删词表
↓
人工审核
↓
形成最终 Cuts + EDL
↓
交给后续导出流程
Among them, the most worthy of carrying out are the three steps in the middle:
Revision, deletion, review.
4. The first gate: first correct the "wrong word" correctly
There is a potential problem with many automated editing systems:
It treats the ASR transcription results directly as fact.
However, for Chinese oral broadcasts, ASR often suffers from recognition errors in professional terms, product names, and English words.
For example:
用户真正说的是：
Grok
ASR 可能得到：
grock
If the latter AI makes judgments directly based on the error text, chain errors may occur.
So this project puts "word revision" before "word deletion".
It has an AI Term Dictionary and also supports users 'own dictionaries.
The process is roughly as follows:
原始 Transcript
↓
通用词典
↓
用户词典
↓
修字表
↓
进入删词分析
And here's an important principle:
The revision of characters can only change the expression of words, but cannot change the time, number of words and wordId.
This means:
错误词 → 正确词
can be modified;
But:
错误词 → 修改时间戳
错误词 → 修改词序
错误词 → 添加不存在的词
It should not happen.
This constraint is critical because subsequent video editing relies on a word-by-word Timeline. If the text is out of touch with the Timeline, subsequent editing results may be distorted.
5. The second gate: five rounds of scanning, rather than "letting AI find nonsense at once"
This is another design that is very worth learning from for the project.
Many people design AI editing agents for the first time and may directly give the model a task:
"Please help me find out all slips of the tongue, repetitions and nonsense."
It seems natural, but the problem is:
Allowing the model to judge too many types at once will cause the judgment standards to contaminate each other.
This project takes a completely different approach:
Five rounds of scanning
First round:
repeated
Second round:
Remnant sentences and corrections
Third round:
misspeak
Fourth round:
English stuck
Fifth round:
Manchphrases and modal particles
In other words, each round is only responsible for one judgment.
For example, the first round only asked:
Is there a repetition here?
Instead of asking:
Is this a mantra? Is it a residual sentence? Should we consider pause?
The benefits of doing so are obvious.
Each round becomes a smaller, clearer question.
6. Why should "repetition" be separated from "mantra"?
Because their objectivity is completely different.
For example:
"This function... This function... It's actually very easy to use."
This repetition is usually easier to judge.
But:
"Actually, I think this thing is still very useful."
Should the words "actually","bar" and "or" here be deleted?
The answer is not entirely objective.
It is related to the user's personal expression habits.
Some people like a clean and neat oral broadcast:
"This function works well."
Others believe that:
"Actually, I think this function is still very useful."
Speaking closer to nature.
So the project putsuser preferencesinto the semantic judgment system.
The priorities are roughly:
用户偏好
>
用户判例
>
通用判例
This means that AI editing is not simply pursuing the "shortest language", but is gradually learning:
What kind of oral broadcasts does this user like?
7. From "one-time AI decision-making" to "auditable word deletion ledger"
The project did not ask the AI to output a sentence:
"It is recommended to delete 37 places."
Instead, it requires the formation of a structured summary of word deletions.
For example:
| # | time | type | delete | The rest is read | risk | basis |
|---|---|---|---|---|---|---|
| 1 | 00:12 | repeated | What about this function? | This function, it actually | low | Case R2 |
| 2 | 02:31 | changed his mouth | For example, I asked him to follow | Like I had Grok follow | high | Case R5 |
This matter is very important.
Because AI's judgment comes from:
"I think this should be deleted."
became:
"I think this belongs to a certain type, according to a certain rule, so I suggest deleting these words, the risk level is high."
The latter truly hasaudit value。
Users do not need to watch the entire video again to understand what the AI is doing, but can check the list of deletions.
8. Why do I still need a "repetitive sentence list"?
This is a very detailed but very practical design.
The word-by-word deletion list can only tell users:
Which words were deleted.
But if the user actually records a sentence three times, the problem is different.
For example:
第一遍：因为今天有什么……
第二遍：因为今天有什么……
第三遍：因为今天有什么……
The issues that really need to be reviewed may be:
Which one of the three times should I keep it?
Therefore, the project additionally designed a "repeated sentence table".
For example:
| sentence | A few times | Keep it for which time | How many times do you delete it? | risk |
|---|---|---|---|---|
| Because what is today... | 3 | pass 3 | 1st and 2nd | low |
This shows that the project does not simply understand editing as:
Delete some words.
Instead, oral editing is understood as:
Rebuild a more natural language expression path.
9. When will users intervene?
A good Agent does not ask users to "ignore everything", nor does it ask users to "confirm every step."
The project actually limits user intervention points.
Users mainly speak in three key positions:
1. Same-origin project selection
If this video has been cut before, the user needs to choose:
Continue with the previous project or start over?
2. Studio review
After the AI completes the proposal, it sends the results to the user for review in Studio.
3. completion confirmation
After the user confirms, the subsequent execution process will be entered.
This is a very typical one:
Low-frequency, high-value manual intervention.
Agents complete a large number of mechanical processes themselves, but leave the nodes that truly affect the final result to others.
10. Studio is not the AI itself that "creates a review page"
The project also has a security boundary that can easily be ignored:
If the Runtime is not installed properly, the Agent does not allow itself to temporarily hand-use a "review desk" to replace the product.
This rule is very important.
Because from an Agent's perspective, this behavior is most likely to occur:
Runtime 不存在
↓
Agent 想办法
↓
自己写一个 HTML
↓
做一个假的审核界面
↓
继续完成任务
On the surface, this is called "intelligence".
In fact, it may invalidate the entire product contract.
The project therefore clearly requires:
You should stop when the Runtime is missing, rather than making an incompatible replacement yourself.
This actually reflects a very mature Agent engineering concept:
The ability boundary of an Agent must obey the product contract.
It's not "as long as you can complete the task."
11. Hierarchy of Runtime and Skill
The entire architecture can be simplified to:
Codex
│
┌───────┴────────┐
│ │
Skills Plugin UI
│
↓
业务判断 / 流程编排
│
↓
chengfeng-videocut Runtime
│
┌─────┼──────────────┐
│ │ │
项目 Cuts / EDL Studio
│
↓
媒体处理 / Render / Verify
The core idea of this stratification is:
LLM should not be the only state manager for the entire system.
Project status, revisions, EDL, media files, service status, etc. are all managed by Runtime.
The Agent is only responsible for:
理解用户
↓
调用能力
↓
读取结果
↓
做判断
↓
组织下一步
Instead of secretly maintaining a "false project status" yourself.
12. Why does the project place special emphasis on Revision and CAS?
If you look closely at the project design, you will find that it attaches great importance to:
projectId- workflow stage
- Project revision
- Cuts revision
- EditList revision
- CAS
These concepts show that developers are not just thinking about "single run success", but rather:
How to avoid state being overwritten by errors when an Agent repeatedly operates on a real project?
For example:
Agent A
读取 revision = 12
用户同时修改项目
revision = 13
Agent A
尝试基于 revision 12 写入
If the system is not version controlled, Agent A is likely to overwrite new changes made by users.
Therefore, revision/CAS can let the system know:
"What you are operating now is no longer the version you saw just now."
This is very important for Agent products.
Because traditional GUI software usually has clear state and user action boundaries, an Agent is an automated subject that is asynchronous, retryable, and may call tools repeatedly.
Without state version control, it is easy for Agents to write old states back to new projects.
13. The installation design also reflects "deterministic priority"
This project does not simply tell users:
npm install xxx
Then it ends.
It also places strict restrictions on Runtime installations.
For example, fixed Runtime versions:
Plugin 0.10.8
↓
Runtime v0.4.8
Instead of:
latest
Why?
because latest It will drift.
The Runtime installed today and the Runtime installed tomorrow may not be the same thing.
For an Agent Plugin that relies on strict product contracts, this is very dangerous.
Therefore, the project emphasizes:
Fixed version + Release + SHA-256 check + doctor check.
It can be understood as:
发现 Runtime
↓
检查版本
↓
确认 Release
↓
下载
↓
SHA-256 校验
↓
安装
↓
doctor
↓
确认服务健康
Skill continues to work only if the entire link is established.
14. Why cannot services be casual nohup？
The project also specifically stipulates that Plugin should not be used directly:
launchctl
nohup
foreground server
To secretly manage products and services.
Runtime is responsible for its own service life cycle.
Use user-level LaunchAgent on macOS and Windows Task on Windows.
This means:
Codex's current terminal is not the life cycle owner of the product and service.
Otherwise, it is easy to appear:
终端关闭
↓
服务消失
Codex 重启
↓
又启动一个服务
第二个服务
↓
端口冲突
Eventually the entire Agent workflow became very unstable.
Therefore, the project adopts:
Declarative ensure-running.
The Agent only needs to tell the product:
Ensure that services are available.
As for how to start, resident, and restore the service, it is managed by the Runtime itself.
15. What does Windows support mean?
This project is not just a script for macOS.
The README clearly states that the Runtime officially supports Windows starting from v0.4.2, and carries out link verification for installation, resident services, crash healing, restart and self-start, archiving and export.
The meaning behind this is:
It began to evolve from a "developer tool" to a "true cross-platform Agent product."
In particular, tasks such as Media Processing Service involve:
- FFmpeg
- FFprobe
- Bun
- Node.js
- Chrome
- local file
- background service
- browser rendering
If any link is not handled properly across platforms, it will eventually make the Agent's behavior unpredictable.
Therefore, incorporating these dependencies into the Runtime's managed directory, rather than having Plugin look around for system environments, is a more reliable product idea.
16. The real value of this project is not that "AI can cut videos"
If you just look at the surface, this seems to be just one:
"AI automatically cuts Chinese oral videos"
project.
But from an engineering perspective, its real value is actually three other keywords:
1. Separation of judgment and execution
AI：
决定删什么
Runtime：
决定怎么安全地执行
2. Separating AI recommendations from manual confirmation
AI：
提出删词方案
User:
确认删什么
System:
执行最终版本
3. Separation of natural language and deterministic states
Agent：
理解“帮我继续剪上一版”
Runtime：
projectId = xxx
revision = 17
cuts = ...
EDL = ...
These three levels of separation are actually more worthy of attention than "what model was used."
17. It also represents a new way of designing AI tools
Traditional software is usually:
用户
↓
按钮
↓
程序
↓
结果
Agent software is closer to:
用户自然语言
↓
Agent
↓
Skill
↓
工具/API
↓
确定性 Runtime
↓
结果
The problem also changes.
The most important things about traditional software are:
Is the UI designed well?
The more important question for Agent software becomes:
Does the Agent adhere to the correct operating boundaries?
For example:
- Can I make up a real video when there is no real video?
- Can I make my own replacement when the Runtime doesn't exist?
- Can an old revision overwrite a new revision?
- Can the user cut it directly without confirmation?
- Did the update secretly switch to an unknown version?
- Can I guess directly if ASR is wrong?
- Will I secretly change the port to start another service after failing?
These are actually the "security boundaries" of Agent products.
and chengfeng-videocut-skills Many designs are just answering these questions.
18. What future can we see from this project?
If we push "AI video editing" one step further, the truly mature products in the future may not be:
"AI will help you automatically cut the video."
It is more likely:
"AI understands your editing habits, proposes an interpretable, reviewable, and traceable editing plan, and then executes it by a deterministic editing engine."
Users don't even need to tell AI every time:
"Less mantra."
Systems can gradually form from historical confirmation:
用户偏好
+
用户判例
+
通用规则
Eventually, a personalized editing style was formed.
So "AI editing" changed from a one-time automated function to:
An editing Agent who understands you more and more.
Conclusion: A truly mature AI is not to "do it for you", but to "know when to stop and ask you"
chengfeng-videocut-skills The most worth studying is not how many skills it has, nor how many skills it can call FFmpeg, ASR, or Studio.
What's really noteworthy is that it establishes a very clear set of boundaries:
AI is responsible for understanding and judgment.
Runtime is responsible for deterministic execution.
The version system is responsible for protecting state.
Users are responsible for key decisions.
The review results will become the experience for the next round of AI judgment.
This design has transformed video editing from a task of "letting AI manipulate media files at will" to a production line that can be traced, reviewed, rolled back, and sustainably learned.
For those who are exploring the combination of Agent + professional software, this project provides a great example:
Don't let Agents replace the entire product.
Let Agents become intelligent orchestration layers on top of products.
And this may be the most worthy direction for future AI-native professional tools.