尧图网页设计 
social-auto-upload 浏览器平台 CLI 统一设计抖音、快手、小红书共用一套主线契约【免费下载链接】social-auto-upload自动化上传视频到社交媒体抖音、小红书、视频号、tiktok、youtube、bilibili项目地址: https://gitcode.com/GitHub_Trending/so/social-auto-upload本文基于 social-auto-upload 仓库中的设计文档 2026-03-25-browser-cli-unification-design.md详解抖音、快手、小红书三家浏览器自动化平台的sauCLI 统一契约是如何设计的统一的动作集合、title desc tags视频与title note tags图文主线参数模型、request dataclass 数据模型以及 CLI 到各平台 uploader 的映射关系。读完本篇你可以直接复制运行三家平台的登录、校验、视频与图文上传命令并理解每条参数在 sau_cli.py 中如何被解析、校验并最终路由到对应的 uploader 类。为什么要做浏览器平台 CLI 统一在统一之前仓库中三个浏览器平台的主线能力存在明显不一致平台视频 CLI 现状图文 CLI 现状抖音--title、--tags无--desc--note、--tags快手--title、--tags无--desc--note、--tags小红书尚无 CLI / skill 接口尚无 CLI / skill 接口也就是说视频描述没有统一暴露为desc图文正文是否沿用note语义在平台之间也没有统一。同时小红书虽然已经具备可用的浏览器 uploader登录、cookie 校验、视频上传、图文上传、定时发布但还没有接入sauCLI也没有对应 skill。设计文档给出的目标是明确的收口而不是重写给小红书补齐主线 CLIlogin、check、upload-video、upload-note统一三家浏览器平台的 CLI 上传参数模型补齐小红书 skill、示例脚本、README、CLI 文档、安装/更新文档修正抖音、快手现有 CLI 契约里缺失的desc能力保持现有 uploader 主体逻辑不大改不做过度封装。对应的非目标同样清晰不重构 uploader 架构、不改 Web 旧路径、不改 Bilibili 上传契约、不做浏览器集成测试、不保留旧的模糊公开契约。统一后的对外入口固定为sau douyin ...sau kuaishou ...sau xiaohongshu ...统一后的 CLI三个平台 × 四个动作每个浏览器平台统一支持四个动作login启动登录流程为指定账号生成或刷新 cookie 文件check校验 cookie 是否可用输出valid或invalidupload-video上传一条视频upload-note上传一条图文。账号模型是统一契约的重要一环--account传的是用户自定义的account_name而不是固定叫creator一个account_name对应一个账号文件可用于多账号隔离和并发任务。这一约定在 CLI 契约、docs/CLI.md 中都有明确说明。视频上传统一命令sau platform upload-video \ --account account_name \ --file video-path \ --title title \ [--desc description] \ [--tags tag1,tag2] \ [--schedule YYYY-MM-DD HH:MM] \ [平台特有参数...]统一规则--title必填--desc选填--tags选填--schedule选填平台特有参数抖音--thumbnail、--product-link、--product-title快手--thumbnail小红书--thumbnail图文上传统一命令sau platform upload-note \ --account account_name \ --images image-1 [image-2 ...] \ --title title \ [--note content] \ [--tags tag1,tag2] \ [--schedule YYYY-MM-DD HH:MM]统一规则--images必填--title必填--note选填--tags选填--schedule选填这里有一个刻意做出的命名决定图文主线正文统一叫note视频主线描述统一叫desc。文档、skill、示例统一使用「视频--title --desc --tags」「图文--title --note --tags」。这样避免了一部分文档把图文正文写成--note、另一部分写成--desc的混乱状态。三家平台可直接运行的命令按 docs/CLI.md 的口径统一后的命令如下sau douyin login --account account_name sau douyin check --account account_name sau douyin upload-video --account account_name --file videos/demo.mp4 --title 示例标题 --desc 示例简介 --tags 运动,训练 sau douyin upload-note --account account_name --images videos/1.png videos/2.png --title 图文标题 --note 图文示例 --tags 图文,测试 sau kuaishou login --account account_name sau kuaishou check --account account_name sau kuaishou upload-video --account account_name --file videos/demo.mp4 --title 示例标题 --desc 示例简介 --tags 运动,训练 sau kuaishou upload-note --account account_name --images videos/1.png videos/2.png videos/3.png --title 图文标题 --note 图文示例 --tags 图文,测试 sau xiaohongshu login --account account_name sau xiaohongshu check --account account_name sau xiaohongshu upload-video --account account_name --file videos/demo.mp4 --title 示例标题 --desc 示例简介 --tags 小红书,视频 sau xiaohongshu upload-note --account account_name --images videos/1.png videos/2.png videos/3.png --title 图文标题 --note 图文示例 --tags 图文,测试三个平台的所有命令还共享一组运行时标志由 sau_cli.py 中的add_runtime_flags统一注入--debug开启调试模式--headless/--headed互斥参数控制是否带浏览器 UI 运行默认headlessparser.set_defaults(headlessTrue)。数据模型设计request dataclass 是 CLI 与 uploader 之间的契约为了让 CLI 层和 uploader 层映射清晰设计采用「每个平台保持各自的 request dataclass但字段命名统一」的方案。这些 dataclass 都定义在 sau_cli.py 中字段与设计文档一一对应。视频请求对象统一字段account_namevideo_filetitledescriptiontagspublish_datepublish_strategydebugheadless平台特有字段保留抖音thumbnail_file/product_link/product_title快手与小红书thumbnail_file。以 XiaohongshuVideoUploadRequest 为例dataclass(slotsTrue) class XiaohongshuVideoUploadRequest: account_name: str video_file: Path title: str description: str tags: list[str] publish_date: datetime | int thumbnail_file: Path | None None publish_strategy: str XIAOHONGSHU_PUBLISH_STRATEGY_IMMEDIATE debug: bool True headless: bool True注意两个细节CLI 层的--desc映射到 dataclass 的description字段命名转换在 CLI 层完成publish_date的类型是datetime | int——由 parse_schedule 决定未提供--schedule时返回0表示立即发布提供时按%Y-%m-%d %H:%M格式解析为datetime。对应的策略常量由各 uploader 定义例如 XIAOHONGSHU_PUBLISH_STRATEGY_IMMEDIATE / SCHEDULED 的取值为immediate与scheduled抖音、快手侧也各自有同名的immediate / scheduled常量。图文请求对象统一字段account_nameimage_filestitlenotetagspublish_datepublish_strategydebugheadless这里刻意保留note字段因为它更符合图文正文语义不应强行复用视频里的description / desc命名。XiaohongshuNoteUploadRequest 与上述字段完全一致。与现有 uploader 的映射设计文档强调「不大改现有 uploader」映射方式如下抖音视频上传继续复用 DouYinVideo本次补齐desc输入映射——在 upload_video 中request.description通过descrequest.description传给DouYinVideo图文上传显式接收title note tagsnote在 upload_note 中映射到DouYinNote的图文正文输入。快手视频上传复用 KSVideoupload_kuaishou_video 中descrequest.description完成了desc补齐图文上传复用 KSNote在 upload_kuaishou_note 中接收title note tags。小红书登录、校验直接接 xiaohongshu_setup / cookie_authlogin走xiaohongshu_setup(account_file, handleTrue, return_detailTrue, headless...)check先判断账号文件是否存在、再调cookie_auth视频上传复用 XiaoHongShuVideo图文上传复用 XiaoHongShuNote因为小红书 uploader 内部本来就把图文正文存为self.note且desc缺省时回退为noteCLI 层把note稳定映射到图文正文即可。小红书 upload 入口在 upload_xiaohongshu_video 与 upload_xiaohongshu_note两者都先经xiaohongshu_setup(account_file, handleFalse)确认 cookie 就绪若失败则抛出带有可操作提示的RuntimeError提示先执行sau xiaohongshu login。从源码看 CLI 解析与路由细节设计文档中的「参数级错误由 CLI parser 负责」在源码中有具体落点文件不存在--file、--images、--thumbnail都使用 existing_file_path 作为type在解析阶段就抛出argparse.ArgumentTypeError: File not found时间格式非法schedule_value 把--schedule解析失败转换为Invalid schedule .... Expected format: %Y-%m-%d %H:%M的报错缺少--title/--images通过requiredTrue由 argparse 直接拒绝。另外两个值得注意的实现细节标签解析parse_tags 按逗号切分、去除空白和前置#所以--tags #a, b与--tags a,b等价。小红书分支还额外做了上限校验在 dispatch 中upload-video/upload-note都会先检查len(parsed_tags) 10超限则向 stderr 输出「小红书标签最多 10 个」并以退出码 1 结束——这是小红书平台侧的真实限制在 CLI 层的提前拦截。发布策略推导三家平台在 dispatch 中都是同一句逻辑例如 小红书分支XIAOHONGSHU_PUBLISH_STRATEGY_SCHEDULED if args.schedule else XIAOHONGSHU_PUBLISH_STRATEGY_IMMEDIATE。也就是说--schedule是否提供直接决定了immediate还是scheduled策略无需用户单独传策略参数。账号文件机制由 resolve_account_file 实现{BASE_DIR}/cookies/{platform}_{account_name}.json并自动创建cookies目录。这解释了为什么「一个account_name对应一个账号文件可多账号隔离并发」——不同账号名会落到不同文件互不干扰。兼容与迁移策略直接统一不留模糊契约这次采用「直接统一不保留旧的模糊公开契约」的策略。具体表现README.mddocs/CLI.mddocs/install.mddocs/update.mdskills/douyin-upload/...skills/kuaishou-upload/...新增skills/xiaohongshu-upload/...scripts/examples/...都会在同一轮里切换到新契约避免出现一部分文档把图文正文写成--note、一部分写成--desc的情况。代价是旧示例命令会失效换来的是主线契约彻底统一视频永远是desc图文永远是note从当前仓库看这一策略已经落地docs/CLI.md 中抖音、快手、小红书三节的示例命令均按「视频--desc、图文--note」的新口径书写skills/xiaohongshu-upload/references/cli-contract.md 也按同一契约列出了必填/可选参数。Skill 设计让 Agent 优先走 sau新增的小红书 skill 与其他平台保持同构的文件组织skills/xiaohongshu-upload/SKILL.mdskills/xiaohongshu-upload/references/cli-contract.mdskills/xiaohongshu-upload/references/runtime-requirements.mdskills/xiaohongshu-upload/references/troubleshooting.mdskills/xiaohongshu-upload/scripts/examples/xiaohongshu_commands.ps1skills/xiaohongshu-upload/scripts/examples/xiaohongshu_commands.shskills/xiaohongshu-upload/scripts/examples/xiaohongshu_cli_template.py并同步更新了 skills/douyin-upload/SKILL.md、skills/kuaishou-upload/SKILL.md 及其各自的references/cli-contract.md。skill 原则继续保持四条优先走sauagent 不要先读 uploader 源码CLI 失败时再看 troubleshooting登录二维码图片优先直接展示给用户扫码。以小红书契约文档为例cli-contract.md 对每个动作都给出了命令模板、必填/可选参数清单并明确「如果登录过程中生成本地二维码图片agent 应优先直接把图片展示/发送给用户扫码而不是只回传路径」。错误处理分层与二维码口径设计把错误分成两层参数级错误由 CLI parser 负责文件不存在、时间格式非法、缺少--title、缺少--images即上一节所述的existing_file_path、schedule_value与requiredTrue业务级错误由 uploader 和现有校验负责cookie 不存在、cookie 已失效、上传失败、页面结构异常。业务级错误在 CLI 层的典型形态是 cookie 前置检查三个上传入口upload_xiaohongshu_video、快手、抖音同理都会在实例化 uploader 之前调用platform_setup(account_file, handleFalse)探测就绪状态未就绪时抛出形如Xiaohongshu cookie is missing or expired: {account_file}. Run sau xiaohongshu login --account name first.的错误——错误信息本身携带了修复动作便于人或 agent 直接照做。二维码口径是三家浏览器平台统一保留的说明如果登录流程生成了本地二维码图片agent 应优先直接展示/发送图片给用户扫码而不是只返回路径。小红书 uploader 的 _save_xhs_qrcode 与 _emit_qrcode_callback 正是这一机制的落点登录过程中提取二维码并保存为本地图片、通过回调上报。测试策略最小但有价值的 CLI 级验证设计明确这次只做 CLI 级验证不做浏览器集成测试。这些测试全部落在 tests/test_sau_browser_cli.py 中与设计文档列出的清单逐条对应parser 能识别xiaohongshutest_build_parser_accepts_xiaohongshu_login验证sau_cli.build_parser()解析[xiaohongshu, login, --account, creator]后args.platform xiaohongshu、args.action login新契约能正确解析test_douyin_upload_video_accepts_desc验证抖音upload-video接受--desctest_kuaishou_upload_note_accepts_title_and_note验证快手upload-note接受--title --notedispatch 能正确把参数转成对应 requesttest_dispatch_douyin_upload_note_uses_new_request_fields、test_dispatch_xiaohongshu_upload_note_uses_headless_request等用例通过 mock 上传函数断言request.title、request.note、request.headless等字段被正确填充小红书四个动作能被正确路由test_dispatch_xiaohongshu_check_prints_valid验证check分支返回 0test_dispatch_xiaohongshu_upload_video_uses_headed_request验证upload-video分支把headlessFalse透传到 request。其中几个用例还覆盖了运行时标志语义test_xiaohongshu_upload_video_defaults_to_headless确认不传任何标志时headless默认为Truetest_xiaohongshu_upload_note_accepts_headed确认--headed会把headless翻转为False。原有的 uploader 级测试 tests/test_xiaohongshu_uploader.py 则保留不动。实现顺序与结论设计文档给出的推荐实现顺序是先改 sau_cli.py 和 request 模型接上小红书 CLI 路由给抖音、快手补desc/ 图文新字段映射补 CLI 单测新增小红书 skill更新抖音、快手 skill 契约更新 README / CLI / install / update 文档更新 examples。最终结论可以概括为四点三家浏览器平台统一成同一套 CLI 动作login、check、upload-video、upload-note三家浏览器平台统一成同一套主线元数据模型视频title desc tags图文title note tags小红书补齐 CLI 与 skill抖音、快手补齐desc能力并统一图文正文字段为note。实现保持轻量不做过度封装CLI 层只做参数解析、校验与账号文件管理把真正的工作交给各平台既有的 uploader 类。这套「统一契约 各自 dataclass 薄 dispatch」的分层方式也是后续新增浏览器平台时可以参照的模板。【免费下载链接】social-auto-upload自动化上传视频到社交媒体抖音、小红书、视频号、tiktok、youtube、bilibili项目地址: https://gitcode.com/GitHub_Trending/so/social-auto-upload创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 social-auto-upload 浏览器平台 CLI 统一设计：抖音、快手、小红书共用一套主线契约
social-auto-upload 浏览器平台 CLI 统一设计抖音、快手、小红书共用一套主线契约【免费下载链接】social-auto-upload自动化上传视频到社交媒体抖音、小红书、视频号、tiktok、youtube、bilibili项目地址: https://gitcode.com/GitHub_Trending/so/social-auto-upload本文基于 social-auto-upload 仓库中的设计文档 2026-03-25-browser-cli-unification-design.md详解抖音、快手、小红书三家浏览器自动化平台的sauCLI 统一契约是如何设计的统一的动作集合、title desc tags视频与title note tags图文主线参数模型、request dataclass 数据模型以及 CLI 到各平台 uploader 的映射关系。读完本篇你可以直接复制运行三家平台的登录、校验、视频与图文上传命令并理解每条参数在 sau_cli.py 中如何被解析、校验并最终路由到对应的 uploader 类。为什么要做浏览器平台 CLI 统一在统一之前仓库中三个浏览器平台的主线能力存在明显不一致平台视频 CLI 现状图文 CLI 现状抖音--title、--tags无--desc--note、--tags快手--title、--tags无--desc--note、--tags小红书尚无 CLI / skill 接口尚无 CLI / skill 接口也就是说视频描述没有统一暴露为desc图文正文是否沿用note语义在平台之间也没有统一。同时小红书虽然已经具备可用的浏览器 uploader登录、cookie 校验、视频上传、图文上传、定时发布但还没有接入sauCLI也没有对应 skill。设计文档给出的目标是明确的收口而不是重写给小红书补齐主线 CLIlogin、check、upload-video、upload-note统一三家浏览器平台的 CLI 上传参数模型补齐小红书 skill、示例脚本、README、CLI 文档、安装/更新文档修正抖音、快手现有 CLI 契约里缺失的desc能力保持现有 uploader 主体逻辑不大改不做过度封装。对应的非目标同样清晰不重构 uploader 架构、不改 Web 旧路径、不改 Bilibili 上传契约、不做浏览器集成测试、不保留旧的模糊公开契约。统一后的对外入口固定为sau douyin ...sau kuaishou ...sau xiaohongshu ...统一后的 CLI三个平台 × 四个动作每个浏览器平台统一支持四个动作login启动登录流程为指定账号生成或刷新 cookie 文件check校验 cookie 是否可用输出valid或invalidupload-video上传一条视频upload-note上传一条图文。账号模型是统一契约的重要一环--account传的是用户自定义的account_name而不是固定叫creator一个account_name对应一个账号文件可用于多账号隔离和并发任务。这一约定在 CLI 契约、docs/CLI.md 中都有明确说明。视频上传统一命令sau platform upload-video \ --account account_name \ --file video-path \ --title title \ [--desc description] \ [--tags tag1,tag2] \ [--schedule YYYY-MM-DD HH:MM] \ [平台特有参数...]统一规则--title必填--desc选填--tags选填--schedule选填平台特有参数抖音--thumbnail、--product-link、--product-title快手--thumbnail小红书--thumbnail图文上传统一命令sau platform upload-note \ --account account_name \ --images image-1 [image-2 ...] \ --title title \ [--note content] \ [--tags tag1,tag2] \ [--schedule YYYY-MM-DD HH:MM]统一规则--images必填--title必填--note选填--tags选填--schedule选填这里有一个刻意做出的命名决定图文主线正文统一叫note视频主线描述统一叫desc。文档、skill、示例统一使用「视频--title --desc --tags」「图文--title --note --tags」。这样避免了一部分文档把图文正文写成--note、另一部分写成--desc的混乱状态。三家平台可直接运行的命令按 docs/CLI.md 的口径统一后的命令如下sau douyin login --account account_name sau douyin check --account account_name sau douyin upload-video --account account_name --file videos/demo.mp4 --title 示例标题 --desc 示例简介 --tags 运动,训练 sau douyin upload-note --account account_name --images videos/1.png videos/2.png --title 图文标题 --note 图文示例 --tags 图文,测试 sau kuaishou login --account account_name sau kuaishou check --account account_name sau kuaishou upload-video --account account_name --file videos/demo.mp4 --title 示例标题 --desc 示例简介 --tags 运动,训练 sau kuaishou upload-note --account account_name --images videos/1.png videos/2.png videos/3.png --title 图文标题 --note 图文示例 --tags 图文,测试 sau xiaohongshu login --account account_name sau xiaohongshu check --account account_name sau xiaohongshu upload-video --account account_name --file videos/demo.mp4 --title 示例标题 --desc 示例简介 --tags 小红书,视频 sau xiaohongshu upload-note --account account_name --images videos/1.png videos/2.png videos/3.png --title 图文标题 --note 图文示例 --tags 图文,测试三个平台的所有命令还共享一组运行时标志由 sau_cli.py 中的add_runtime_flags统一注入--debug开启调试模式--headless/--headed互斥参数控制是否带浏览器 UI 运行默认headlessparser.set_defaults(headlessTrue)。数据模型设计request dataclass 是 CLI 与 uploader 之间的契约为了让 CLI 层和 uploader 层映射清晰设计采用「每个平台保持各自的 request dataclass但字段命名统一」的方案。这些 dataclass 都定义在 sau_cli.py 中字段与设计文档一一对应。视频请求对象统一字段account_namevideo_filetitledescriptiontagspublish_datepublish_strategydebugheadless平台特有字段保留抖音thumbnail_file/product_link/product_title快手与小红书thumbnail_file。以 XiaohongshuVideoUploadRequest 为例dataclass(slotsTrue) class XiaohongshuVideoUploadRequest: account_name: str video_file: Path title: str description: str tags: list[str] publish_date: datetime | int thumbnail_file: Path | None None publish_strategy: str XIAOHONGSHU_PUBLISH_STRATEGY_IMMEDIATE debug: bool True headless: bool True注意两个细节CLI 层的--desc映射到 dataclass 的description字段命名转换在 CLI 层完成publish_date的类型是datetime | int——由 parse_schedule 决定未提供--schedule时返回0表示立即发布提供时按%Y-%m-%d %H:%M格式解析为datetime。对应的策略常量由各 uploader 定义例如 XIAOHONGSHU_PUBLISH_STRATEGY_IMMEDIATE / SCHEDULED 的取值为immediate与scheduled抖音、快手侧也各自有同名的immediate / scheduled常量。图文请求对象统一字段account_nameimage_filestitlenotetagspublish_datepublish_strategydebugheadless这里刻意保留note字段因为它更符合图文正文语义不应强行复用视频里的description / desc命名。XiaohongshuNoteUploadRequest 与上述字段完全一致。与现有 uploader 的映射设计文档强调「不大改现有 uploader」映射方式如下抖音视频上传继续复用 DouYinVideo本次补齐desc输入映射——在 upload_video 中request.description通过descrequest.description传给DouYinVideo图文上传显式接收title note tagsnote在 upload_note 中映射到DouYinNote的图文正文输入。快手视频上传复用 KSVideoupload_kuaishou_video 中descrequest.description完成了desc补齐图文上传复用 KSNote在 upload_kuaishou_note 中接收title note tags。小红书登录、校验直接接 xiaohongshu_setup / cookie_authlogin走xiaohongshu_setup(account_file, handleTrue, return_detailTrue, headless...)check先判断账号文件是否存在、再调cookie_auth视频上传复用 XiaoHongShuVideo图文上传复用 XiaoHongShuNote因为小红书 uploader 内部本来就把图文正文存为self.note且desc缺省时回退为noteCLI 层把note稳定映射到图文正文即可。小红书 upload 入口在 upload_xiaohongshu_video 与 upload_xiaohongshu_note两者都先经xiaohongshu_setup(account_file, handleFalse)确认 cookie 就绪若失败则抛出带有可操作提示的RuntimeError提示先执行sau xiaohongshu login。从源码看 CLI 解析与路由细节设计文档中的「参数级错误由 CLI parser 负责」在源码中有具体落点文件不存在--file、--images、--thumbnail都使用 existing_file_path 作为type在解析阶段就抛出argparse.ArgumentTypeError: File not found时间格式非法schedule_value 把--schedule解析失败转换为Invalid schedule .... Expected format: %Y-%m-%d %H:%M的报错缺少--title/--images通过requiredTrue由 argparse 直接拒绝。另外两个值得注意的实现细节标签解析parse_tags 按逗号切分、去除空白和前置#所以--tags #a, b与--tags a,b等价。小红书分支还额外做了上限校验在 dispatch 中upload-video/upload-note都会先检查len(parsed_tags) 10超限则向 stderr 输出「小红书标签最多 10 个」并以退出码 1 结束——这是小红书平台侧的真实限制在 CLI 层的提前拦截。发布策略推导三家平台在 dispatch 中都是同一句逻辑例如 小红书分支XIAOHONGSHU_PUBLISH_STRATEGY_SCHEDULED if args.schedule else XIAOHONGSHU_PUBLISH_STRATEGY_IMMEDIATE。也就是说--schedule是否提供直接决定了immediate还是scheduled策略无需用户单独传策略参数。账号文件机制由 resolve_account_file 实现{BASE_DIR}/cookies/{platform}_{account_name}.json并自动创建cookies目录。这解释了为什么「一个account_name对应一个账号文件可多账号隔离并发」——不同账号名会落到不同文件互不干扰。兼容与迁移策略直接统一不留模糊契约这次采用「直接统一不保留旧的模糊公开契约」的策略。具体表现README.mddocs/CLI.mddocs/install.mddocs/update.mdskills/douyin-upload/...skills/kuaishou-upload/...新增skills/xiaohongshu-upload/...scripts/examples/...都会在同一轮里切换到新契约避免出现一部分文档把图文正文写成--note、一部分写成--desc的情况。代价是旧示例命令会失效换来的是主线契约彻底统一视频永远是desc图文永远是note从当前仓库看这一策略已经落地docs/CLI.md 中抖音、快手、小红书三节的示例命令均按「视频--desc、图文--note」的新口径书写skills/xiaohongshu-upload/references/cli-contract.md 也按同一契约列出了必填/可选参数。Skill 设计让 Agent 优先走 sau新增的小红书 skill 与其他平台保持同构的文件组织skills/xiaohongshu-upload/SKILL.mdskills/xiaohongshu-upload/references/cli-contract.mdskills/xiaohongshu-upload/references/runtime-requirements.mdskills/xiaohongshu-upload/references/troubleshooting.mdskills/xiaohongshu-upload/scripts/examples/xiaohongshu_commands.ps1skills/xiaohongshu-upload/scripts/examples/xiaohongshu_commands.shskills/xiaohongshu-upload/scripts/examples/xiaohongshu_cli_template.py并同步更新了 skills/douyin-upload/SKILL.md、skills/kuaishou-upload/SKILL.md 及其各自的references/cli-contract.md。skill 原则继续保持四条优先走sauagent 不要先读 uploader 源码CLI 失败时再看 troubleshooting登录二维码图片优先直接展示给用户扫码。以小红书契约文档为例cli-contract.md 对每个动作都给出了命令模板、必填/可选参数清单并明确「如果登录过程中生成本地二维码图片agent 应优先直接把图片展示/发送给用户扫码而不是只回传路径」。错误处理分层与二维码口径设计把错误分成两层参数级错误由 CLI parser 负责文件不存在、时间格式非法、缺少--title、缺少--images即上一节所述的existing_file_path、schedule_value与requiredTrue业务级错误由 uploader 和现有校验负责cookie 不存在、cookie 已失效、上传失败、页面结构异常。业务级错误在 CLI 层的典型形态是 cookie 前置检查三个上传入口upload_xiaohongshu_video、快手、抖音同理都会在实例化 uploader 之前调用platform_setup(account_file, handleFalse)探测就绪状态未就绪时抛出形如Xiaohongshu cookie is missing or expired: {account_file}. Run sau xiaohongshu login --account name first.的错误——错误信息本身携带了修复动作便于人或 agent 直接照做。二维码口径是三家浏览器平台统一保留的说明如果登录流程生成了本地二维码图片agent 应优先直接展示/发送图片给用户扫码而不是只返回路径。小红书 uploader 的 _save_xhs_qrcode 与 _emit_qrcode_callback 正是这一机制的落点登录过程中提取二维码并保存为本地图片、通过回调上报。测试策略最小但有价值的 CLI 级验证设计明确这次只做 CLI 级验证不做浏览器集成测试。这些测试全部落在 tests/test_sau_browser_cli.py 中与设计文档列出的清单逐条对应parser 能识别xiaohongshutest_build_parser_accepts_xiaohongshu_login验证sau_cli.build_parser()解析[xiaohongshu, login, --account, creator]后args.platform xiaohongshu、args.action login新契约能正确解析test_douyin_upload_video_accepts_desc验证抖音upload-video接受--desctest_kuaishou_upload_note_accepts_title_and_note验证快手upload-note接受--title --notedispatch 能正确把参数转成对应 requesttest_dispatch_douyin_upload_note_uses_new_request_fields、test_dispatch_xiaohongshu_upload_note_uses_headless_request等用例通过 mock 上传函数断言request.title、request.note、request.headless等字段被正确填充小红书四个动作能被正确路由test_dispatch_xiaohongshu_check_prints_valid验证check分支返回 0test_dispatch_xiaohongshu_upload_video_uses_headed_request验证upload-video分支把headlessFalse透传到 request。其中几个用例还覆盖了运行时标志语义test_xiaohongshu_upload_video_defaults_to_headless确认不传任何标志时headless默认为Truetest_xiaohongshu_upload_note_accepts_headed确认--headed会把headless翻转为False。原有的 uploader 级测试 tests/test_xiaohongshu_uploader.py 则保留不动。实现顺序与结论设计文档给出的推荐实现顺序是先改 sau_cli.py 和 request 模型接上小红书 CLI 路由给抖音、快手补desc/ 图文新字段映射补 CLI 单测新增小红书 skill更新抖音、快手 skill 契约更新 README / CLI / install / update 文档更新 examples。最终结论可以概括为四点三家浏览器平台统一成同一套 CLI 动作login、check、upload-video、upload-note三家浏览器平台统一成同一套主线元数据模型视频title desc tags图文title note tags小红书补齐 CLI 与 skill抖音、快手补齐desc能力并统一图文正文字段为note。实现保持轻量不做过度封装CLI 层只做参数解析、校验与账号文件管理把真正的工作交给各平台既有的 uploader 类。这套「统一契约 各自 dataclass 薄 dispatch」的分层方式也是后续新增浏览器平台时可以参照的模板。【免费下载链接】social-auto-upload自动化上传视频到社交媒体抖音、小红书、视频号、tiktok、youtube、bilibili项目地址: https://gitcode.com/GitHub_Trending/so/social-auto-upload创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考