987 字
5 分钟
2026.04.02
前言
今天不是只做了 CutX，而是把我整套 AI 工作流又往前推进了一步： 从「skills 管理」到「浏览器联网能力验证」，再到「视频裁剪系统重构、仓库重建、规则沉淀、博客发布」。 核心目标很明确：让系统更懂我，并且每次都能直接产出可用结果。
今天做了什么
1. 技能体系与记忆机制梳理
- 检索和导出本机 skills，确认当前可用能力边界。
- 明确了「记录」和「推送」两类触发动作的优先级与用途：
记录：沉淀偏好与规则，让模型持续贴合工作方式。推送：把当日结果通过 Bark 输出成可读总结。
- 重点推动“跨 session 学习”思路，不只依赖当前上下文，要求能结合历史会话持续进化。
2. 联网与浏览器能力验证（web-access / dev-browser）
- 反复验证了浏览器连接与可见操作链路，确保不是“口头调用”，而是真实可执行。
- 在多个站点场景下测试了检索、跳转、内容提取与故障重试，补齐了“连得上但看不到结果”的断点。
3. CutX 项目重构与全流程实跑
- 重新定义核心剪辑原则：
- 用「重来」做分割信号；
- 全局判断，不做段位硬编码；
- 重复表达保留后面的正确版本。
- 反复用原视频 + SRT 对比回归，针对误删/漏删/重复保留问题做多轮规则修正。
- 连续输出并复核
final.srt、final_cut.mp4、decision_report.md，直到关键错误被消掉。
4. GitHub 仓库重建与清理
- 远端仓库清理后，重建私有仓库并重新连接本地
cutx。 - 完成首推后，按“只保留代码”原则做二次清理：
- 移除 draft 产物、音视频文件、缓存文件；
- 更新
.gitignore，防止后续再把产物推上去。
5. Skill 指向修正
- 发现本机
cutxskill 仍指向旧路径（历史工程），已切换到当前项目路径与当前运行方式，避免后续调用跑偏。
今天学到了什么
-
“能跑通”不等于“可交付” 指标过关（例如 near-dup=0）并不代表语义上没有问题，最终必须回到逐句业务判断。
-
硬编码最容易在边界场景翻车 一旦按“尾段/中段”这种位置假设做判断，遇到新语料就会错；全局规则 + 可解释决策才更稳。
-
仓库治理是产品体验的一部分 产物文件、缓存文件混进仓库，会直接拉低协作效率；“代码仓库”和“运行产物”必须分层。
-
记忆机制要服务执行，而不是增加负担 记录不是为了堆文档，而是为了下一次执行更快、更准、更少反复。
今天的感悟
今天最有价值的一点是： 我不是在“修一个脚本”，而是在训练一套长期可复用的个人工作系统。
当我把标准说清楚（比如“重来分割 + 后者优先 + 不硬编码”）， 系统就能逐步从“会执行”变成“会按我的判断方式执行”。
这才是我真正要的 AI 协作状态。
明天计划
- 把 CutX 所有阈值参数外置到配置文件，减少代码内硬编码。
- 增加一套自动回归样例（固定视频片段 + 期望 SRT）做快速验收。
- 把“记录 + 推送 + 博客发布”做成每日固定闭环，减少人工整理成本。
- 继续优化技能调用前置判断，让常用 skill 在高频场景下更稳定触发。
一句话总结
今天把“技能系统、视频自动剪辑、仓库治理、知识沉淀”串成了一条闭环：从能做，到稳定可复用。