ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

DeepSeek Harness GUI PR 证据机制:基于 record-browser-gif 的演示 GIF 录制与孤儿 assets 分支发布实践

DeepSeek Harness GUI PR 证据机制:基于 record-browser-gif 的演示 GIF 录制与孤儿 assets 分支发布实践 DeepSeek Harness GUI PR 证据机制基于 record-browser-gif 的演示 GIF 录制与孤儿 assets 分支发布实践【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness在 DeepSeek HarnessEverything is a Plugin这样的开源仓库中每一次改变产品用户可见 GUI 行为的 Pull RequestPR都需要经得起评审。本文基于仓库归档决策文档 2026-07-26-gui-pr-gif-evidence-and-assets-branch.zh.md 及其后续演进完整剖析该项目如何用 record-browser-gif skill 录制来源必须真实的演示 GIF并通过专用的孤儿orphanassets 分支发布——既不污染代码历史又能让评审人无需重新构建分支即可看到变更的渲染结果。读完你将掌握为什么二进制媒体绝不能进入 PR 分支、assets 分支的完整发布与校验流程以及录制环节沉淀下来的全套防坑操作经验。问题GUI 变更的评审证据长期缺失仓库此前对改变 GUI 行为的 PR评审只能依赖文字描述和测试名称。二者都无法展示真实的渲染结果。虽然record-browser-gifskill 已经能生成真实可信的本地 GIF但它刻意止步于本地产物——于是每个想展示 GIF 的 PR 都得各自重新摸索发布方式。把 GIF 提交到 PR 分支从来不可接受进入历史的二进制媒体会永久增大之后每一次克隆的体积。演示 GIF 的价值止于评审那一刻而它留在 git 历史中的代价却永不消失。除了发布方式缺失录制流程本身也在靠一次次失败反复重新学习截图写到浏览器工具允许的根目录之外或写入不存在的目录会在截取时直接失败跨多次工具调用轮询瞬态 UI 状态会丢失因为调用之间轮次已经结算用子串匹配做完成判定会命中用户自己提示词的回显在编码器命令上内联赋值环境变量因参数先于赋值展开而不生效。这些问题在归档决策文档 2026-07-23-browser-demo-gif-recording.zh.md 和本决策中都被逐一定性、逐一定案。决策强制真实来源的 GIF 证据 孤儿 assets 分支发布该决策确立了三条硬性规则随后被 record-browser-gif skill 的现行契约完全承接每个改变产品用户可见 GUI 行为的 PR 都必须包含演示 GIF。GIF 的来源必须真实从该 PR 自身分支树启动的真实服务器、真实 API 密钥、真实的模型轮次并在嵌入处注明来源。只有当用户明确要求 fixture测试前置数据来源时才可使用 fixture。GIF 发布到专用的孤儿 assets 分支该分支没有父提交、只含媒体GIF 绝不进入 PR 自己的分支。一个 assets 分支服务整个 PR 系列仓库中现存code-mode-ui-assets、pr-613-assets等分支。录制与发布分离录制本身保持无副作用只产生本地文件发布是一个有边界的收尾步骤仅当任务包含把 GIF 附到 PR时才由 skill 执行。为什么是孤儿分支孤儿分支orphan branch没有父提交与主干历史完全隔离。发布在浅层单分支的临时克隆中进行提交信息形如assets: what it shows gif (#pr)PR 正文用带必需?rawtrue后缀的 blob URL 嵌入。关键约束是assets 分支只允许追加——已合并的 PR 正文会永远引用其 URL因此 assets 分支绝不重写、绝不删除、绝不 force-push。从源码看这条契约在 skill 的 SKILL.md 中被显式声明为发布步骤## Publish the GIF其开头即重申Never commit a GIF to the pull requests own branch or any branch that merges into a long-lived branch: binary media committed there bloats the repository history for every future clone.录制环节沉淀的操作经验skill 吸收了录制实践换来的全套操作经验这些经验如今以显式检查项写在 SKILL.md 中帧文件目录与写入权限帧文件放在仓库.gitignore忽略的.playwright-mcp/目录下并在截取前先创建运行目录——因为浏览器工具只能写入其允许的根目录相对文件名也相对仓库根目录解析。这样录制产物脚本、原始视频、时间记录、QA 帧、GIF不会弄脏 worktree。按 PR 隔离构建与运行每个 PR 从自己构建的分支树启动服务先要求干净的 worktree用git rev-parse HEAD记录确切提交再构建该提交树pnpm run build pnpm run build:web。配以全新的临时DSH_HOME、DSH_AGENTS_HOME、工作区与会话状态每个录制场景新开会话。若浏览器无法创建全新上下文则先清除该 origin 的 cookies 和站点存储再导航防止持久化的客户端状态影响证据。停止服务器时按 PID 精确匹配而不是用宽泛的进程名模式——宽泛的pkill -f可能匹配并杀掉启动它的 shell包括你自己的。瞬态状态的截取策略瞬态 UI 状态靠驱动一个缓慢的前台操作、并在同一次浏览器脚本调用内轮询具体的 DOM 标记来截取完成判定匹配精确文本元素而非子串exact: true避免命中提示词回显。录制开始前需确认 origin、构建或开发服务器、传输层及任何模式覆盖若生产默认打开自动化无法驱动的原生界面则通过正常应用配置选择官方可浏览器操作的 production 后端并披露该覆盖。编码器的确定性执行编码器在单独一行export GIF_SKILL_DIR之后运行内联赋值环境变量在参数展开前不生效逐帧时长让最终稳定状态停留最久并同时核对 JSON 摘要与目视检查编码后的 GIF。典型调用如下来自 SKILL.mdexport GIF_SKILL_DIR/absolute/path/to/this/skill python3 $GIF_SKILL_DIR/scripts/encode_gif.py \ /absolute/path/to/demo.webm \ /absolute/path/to/demo.gif \ --start 2 --end 32 --speed 2 --final-hold 3 \ --fps 10 --max-width 1200 --colors 128配套的 encode_gif.py 用ffprobe探测 WebM 容器时长先裁剪、调速再做调色板转换最后校验编码后的时长、动画、宽度与字节大小它会拒绝空区间或越界区间、少于两个输出帧的选择、模式不匹配的 flag 以及意外覆盖。默认字节上限为 5 MiB源码中的DEFAULT_MAX_BYTES 5 * 1024 * 1024体积过大时依次降低--max-width、--colors、--fps同时保持文字可读。帧目录模式则用--durations 1.5,1.5,1.5,3.5为每帧设定停留时长。该脚本自带单元测试test_encode_gif.py可用python3 -m unittest discover -s $GIF_SKILL_DIR/scripts -p test_*.py -v运行这些本地媒体测试不进入仓库 CI。发布工作流先 gh attach再 assets 分支回退skill 的发布步骤首选gh --attach它把 GIF 上传到 GitHub 并在一条命令内重写 PR 正文引用任何分支都不承载媒体。该路径要求ghv2.99.0 及以上、仓库位于 github.com不支持 GitHub Enterprise Server、具备仓库写权限、GIF 不超过 10 MB。gh pr create --body-file body.md --attach path/to/demo.gif # 新建 PR gh pr edit pr --body-file body.md --attach path/to/demo.gif # 编辑既有 PR正文中以普通本地路径引用 GIFgh会原地重写为上传 URL保留位置与 alt 文本alt text当gh --attach不可用GIF 仍超 10 MB、gh版本过旧、仓库不在 github.com时回退到 assets 分支流程git clone --branch assets-branch --single-branch --depth 1 repo-url /tmp/assets-checkout cp /absolute/path/to/demo.gif /tmp/assets-checkout/name.gif cd /tmp/assets-checkout git add name.gif git commit -m assets: what it shows gif (#pr) git push origin assets-branch新系列则先浅克隆、git switch --orphan assets-branch创建孤儿分支后再提交推送。PR 正文嵌入时必须使用带?rawtrue后缀的 blob URL——普通 blob URL 会渲染 GitHub 的文件页而非图片![alt text](https://github.com/owner/repo/blob/assets-branch/name.gif?rawtrue)发布后的双重复核无论走哪条路径发布后都要核验演示的 PR head 未移动 资产真实可达重新读取演示 PR 的 live head要求仍停留在录制时记录的提交通过 GitHub Markdown API 渲染正文确认出现预期的img抓取上传 URL 确认返回200与image/gif。私有仓库资产需用带认证的 API 或 raw 请求核验路径、字节大小、校验和、状态码与媒体类型——匿名的404不能证明私有仓库资产不可达。曾考虑的替代方案与取舍决策文档完整记录了六种被否决的方案每一条都对应一个明确的代价候选方案被否决的原因把 GIF 提交到 PR 分支合入默认分支的二进制媒体留在历史中影响之后每一次克隆和拉取价值止于评审代价永不消失作为 GitHub 附件上传拖拽产生的user-attachments上传对命令行工作流不可用无法从仓库重建或审计媒体生命周期脱离仓库控制用 Git LFS 存储 GIFLFS 仍把媒体耦合进代码分支历史给每次克隆和 CI 拉取增加基础设施依赖相比普通 git 即可支持的隔离分支无额外收益每个 PR 一个 assets 分支ref 命名空间蔓延且在一个系列内成倍增加临时克隆每系列一个分支让发布只需一次推送把发布留在录制 skill 之外保住了边界却让每个 PR 重新摸索同一套流程如今边界以显式条件保留让 GIF 在每个 PR 中保持可选可选的证据恰在最需要它的进度压力下消失没有录制的 GUI 变更评审等于要求评审人自行想象渲染结果或重新构建分支证据链的进一步收严该决策在 2026-08 又演化出一个分镜一条证据链的强化版契约见 2026-08-08-browser-gif-evidence-chain.md一次录制视为一条因果证据链钉死在精确的 PR head 上每个发布的帧必须来自同一个服务器与模型支撑场景运行捕获失败即丢弃该轮帧并从全新根状态重跑绝不拼接不同运行的帧。当声明涉及工具调用、拒绝或恢复时分镜必须包含展示工具身份、状态或稳定错误码及其下游结果的详情/轨迹帧聊天记录不能作为工具恢复的充分证据。最终编码后的 GIF 才是验证主体——若查看器只能显示首帧应从编码后的 GIF 解码代表帧检查而不是把源截图当作等价证据。后果与代价该机制落地后的净效果是每个 GUI PR 都携带注明来源的可视证据评审人无需重新构建分支即可看到变更仓库历史保持不含媒体。代价则被转移到只追加的 assets 分支上——它们会持续增长、可以低成本地浅克隆、且永远不能删除。强制的真实来源录制给每个 GUI PR 的工作流增加了一次真实密钥、真实模型轮次的运行这是有意为之因为这次运行本身就是证据。录制部分仍然在本地可撤销任务不包含附到 PR 的 GIF请求时工作流以已验证的本地产物结束不会产生任何远程副作用。对于希望在本仓库贡献 GUI 变更的开发者这套机制意味着用 record-browser-gif skill 从你自己的分支树录制真实演示把产物留在.playwright-mcp/下再按 skill 的发布步骤完成gh --attach或 assets 分支推送——三条原则始终不变来源真实、不入代码历史、只追加不重写。【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表