原研究时间：2026-10-07；2026-10-13 核对修订。研究对象：Mxucc/xianyu-super-butler。本文只核查这一 fork，不混同上游作者或其他同名工具。
为什么暂停真实账号接入
这是一个包含多账号、自动回复、AI 议价和自动发货的项目。功能清单值得研究，但许可证表述、来源授权和真实账户动作需要先澄清。
原稿用“徽章说谎”“破解版”“回避投诉”直接下了结论，证据不够，现撤回这些定性。我仍不建议在授权与动作边界不清时接真实账户；原因是存在未解决的问题，不是已证明作者侵权。 仓库公开、stars 多或有免责声明，都不能替代核查。
七个核查点（事实与疑问分开）
①：解密文件确实存在，但不能仅凭名称判侵权
目录中有 secure_confirm_decrypted.py 和 secure_freeshipping_decrypted.py。前者源码开头自称自动确认发货模块的“解密版本”，这是可确认的文件描述。
但本次未取得能证明其权利归属、原保护方式、是否获得解密/再分发许可、是否存在付费限制的材料，也没有权利人投诉或司法认定证据。“decrypted” 是待追查来源的线索，不是“未经许可破解、盗版”的充分证据。
②：许可证表述不完整且有歧义，不等于假徽章已坐实
仓库 API返回 license: null；本次读取的完整目录树未见独立 LICENSE/COPYING/NOTICE 文件。但 README 原文不只有徽章：底部另有 MIT License 链接，同时又写“仅供学习研究，严禁商业用途”。
GitHub 的许可字段来自自动识别，README 也可能承载许可声明，详见 GitHub 官方许可说明。所以不能把 null 翻译成“任何人都没有合法使用权”，也不能凭 MIT 图标认定全部文件已获得清楚、完整的 MIT 授权。
需要维护者澄清：MIT 声明的适用文件与权利人、上游及第三方通知如何保留，以及“禁商用”与 MIT 表述的关系。在此之前，不把它当作可放心商业打包的标准许可样本。
③：Issues 确实关闭，关闭动机未知
API 的 has_issues: false 可以支持“当前没有仓库内 Issues 入口”。它不能证明作者为了屏蔽版权投诉，也不能证明不存在其他反馈渠道。README 仍写欢迎 Issue/PR，至少说明文档与当前设置需要协调。
④：免责声明不能当免责或合规凭证
README 写学习用途、禁止商用及用户自行承担后果。作者写了这些，不能保证具体行为已获平台允许，也不能由此确定责任在法律上如何分配。
原稿把警告长短换算成“合规强 10 倍”没有意义。要检查的是实际接口、凭证、数据、商品和动作，而不是警告框够不够大。
⑤：滑块“99%”是项目自述，未验证
README 宣传滑块验证成功率 99%，没有本次可复现的样本、环境、失败定义或测试记录，不能作为效果结论。浏览器、Cookie、多账号和自动发货涉及外部副作用；本次未独立比对全部现行闲鱼规则，不能仅据功能名称断言行为合法或必然违规。
也不把“解决验证失败”自动写成恶意动机，不给封号概率或与其他工具的概率排名。
⑥：fork 链并非完全不透明
API 显示直接 parent/source 为 23Star/xianyu-super-butler。README 顶部仓库徽章、Star History 和底部署名都指向 23Star，同时注明更早基于 zhinianboke/xianyu-auto-reply。
因此，“README 刻意隐藏中间上游”的指控不成立于现有材料。当前更准确的问题是：继承的来源说明有保留，但各层授权与 fork 的具体改动尚未完整核对。来源可见也不自动证明所有授权齐全。
⑦：作者资料不支持诚信或公司关系判断
followers、注册时间、公开仓库数量和个人资料中的公司名称，不能证明作者可信、不可信、批量搬运，或与上游有商业关系。删去这些人格与商业推断，只保留维护账号用于辨认研究对象。
跟 Ydisks-Xianyu 的对比（比较检查项，不评合规分）
| 检查项 | Ydisks-Xianyu | 本文 fork |
|---|---|---|
| 代码许可材料 | 有 Apache-2.0 LICENSE | README MIT 与禁商用表述并存，未见独立 LICENSE |
| 平台风险文字 | 明确自述非公开接口与风险 | 有学习用途/责任声明，仍需具体核查 |
| 来源 | 看其自身来源记录 | 直接 23Star、较早 zhinianboke，均有可见线索 |
| 真实动作 | 均需确认账户、平台、商品及数据权限 | 均需确认账户、平台、商品及数据权限 |
有独立许可证或更长的警告，不代表更低封号率或获得平台运营资格。不将 Ydisks-Xianyu 推荐为“合规替代品”。
我的明确建议
先不部署或输入真实 Cookie，不触发回复、议价、发货和订单更新。可以离线阅读架构，用合成数据研究状态机与失败处理。
如有业务需求，先查平台当前确实提供、且对你开放的正式工具或授权接口，不预设每类闲鱼账号都有可调用的官方 API。任何方案都应先核商品权益、用户数据和交易规则，不能拿“自托管”“仅学习”代替这些条件。
仍无法回答的问题
- 这些“解密版本”由谁生成，基于何种授权发布？
- README 的 MIT 声明覆盖哪些文件，与禁商用文字如何协调？
- fork 对上游改动了哪些核心逻辑，依赖和第三方代码的许可通知是否齐全？
- 平台动作在当前协议、账号类型和商品场景下是否获准？
- 99% 指标的测试条件和原始结果在哪里？
未知就留作未知。没有拿到授权证据，既不能宣布“当然合法”，也不能反过来宣布“已证实盗版”。
元教训
以后看到 license: null、解密文件、关闭 Issues 或多层 fork，应该启动证据核查，不是启动人格判断。把事实、作者自述、推断和未解问题分开，比“终止流程 + 吐槽”更能帮助下一步决策。
2026-10-13 资料核对说明： 实际读取该 fork 的 README、仓库 API、未截断的递归文件树及 secure_confirm_decrypted.py 开头和相关函数；另读 GitHub 官方许可识别说明。未运行软件、验证滑块成功率、登录账户或触发交易；未取得完整上游授权链或侵权认定材料。原稿的侵权、撒谎、投诉动机及风险排名均已撤回，不把未核验当已证伪。