令令令申申申申申不要反代国内的

玩玩国外的就行了

而且站内还有佬就是在腾讯负责wb的呢

虽然但是，不是说是疑似 agent 发的啊

这人怎么还有个人练习笔记？

主要是现在国际版限制太多了，一会就429

最后连署名，联系方式，啥都没得，估计是ai操作发的 ^-^

本来玩的好好的，非要普及到滥用。

谁家律师函发lssues啊，肯定是假的，不用看

腾讯的人不知道

于某网站上看到一个问题，编号#576，内容是一封律师信。

旁边有人问：“这是谁发的？”

答：“一个律师。”

问：“律师叫什么？”

答：“不知道，函上没写。”

问：“那函是谁写的？”

答：“AI写的。”

问：“AI有律师证吗？”

答：“AI没有，但人也没有。”

沉默片刻，那个人说：

“我们终于实现了真正的法治：所有人都可以发律师函，因为没人知道律师是谁。”

github.com/Ebony-Vinyl/dsh-our-free-model

律师函

已打开 09:00AM - 21 Oct 26 UTC

已关闭 10:23AM - 21 Oct 26 UTC

kunzhuchw

律师函

【函号】LAW-DSH-OFM-2026-1021-WB

致 Ebony-Vinyl、tom613951 及"dsh-our-free-model"项目维护者

就贵方在 GitHub 仓库 Ebony-Vinyl/dsh-our-free-model（以下简称"涉案仓库"）中，就权利人 WorkBuddy / CodeBuddy 产品所实施的技术措施破解、渠道恢复与对外分发事宜，现函告如下。

一、权利基础

权利人是 WorkBuddy（国际版，www.workbuddy.ai）与 CodeBuddy（中国版，服务端 copilot.tencent.com，登录门户 www.codebuddy.cn）产品的研发与运营主体，对下列各项依法享有合法权益：

1. 权利人产品的源代码、客户端软件及官方 IDE 扩展（含 genie 扩展、cli/product.json 等）的著作权；
2. 权利人服务端未对外公开的内部 API 路径、请求头协议、客户端标识常量及版本号的技术秘密与商业秘密；
3. 权利人为维护服务公平与安全而设置的渠道校验机制（即下文所称"官方客户端校验"）所承载的技术管理措施；
4. 权利人向用户免费提供的lao1额度权益及与之相联系的账号体系；
5. "WorkBuddy"、"CodeBuddy"等注册商标及权利人的商业信誉、商品声誉。

上述第 3 项尤须强调：权利人在服务端实施的渠道校验，是为防止非官方客户端盗用权利人免费额度、损害全体用户权益而设置的技术管理措施。该措施在响应中以明示方式告知违规者——详见本函第二部分（一）项。

二、经查证的事实

权利人于 2026 年 10 月 21 日对涉案仓库、其 pull request 及相关分发渠道进行了全面核查，事实如下。

（一）权利人服务端已明示告知：11128 系"非官方客户端"校验，且贵方已完整反向该校验规则

2026 年 10 月 21 日，涉案仓库 Issue #560（用户 zxyZero）完整公开了权利人服务端的原始响应报文：```http
POST https://copilot.tencent.com/v2/chat/completions
HTTP/2 400
content-type: application/json; charset=utf-8
x-request-id: 096f2e0d-b50e-44fe-b645-5d794aa2684e
x-user-id: 3372643c-d57f-4a4d-adf7-5a14082f86f9

{"code":11128,"msg":"Illegal API invocation from an unapproved channel",
"requestId":"096f2e0d-b50e-44fe-b645-5d794aa2684e",
"displayMsg":{"en":"Request blocked. Please send it again",
"zh":"请求被拦截，请重新发送"},
"displayTips":{"en":"This call failed channel verification, possibly because it was not sent from an official client. Please resend from the official client.",
"zh":"这次调用没通过渠道校验，可能不是官方客户端发出的。请用官方客户端重新发送。"},
"actions":["EDIT_INPUT","SUBMIT_FEEDBACK"]}
``**该响应中权利人的 displayTips` 中英文双语文本明文写明："这次调用没通过渠道校验，可能不是官方客户端发出的。请用官方客户端重新发送。"（英文原文："This call failed channel verification, possibly because it was not sent from an official client. Please resend from the official client."）**

这直接证明：

• 11128 系权利人主动设置的官方客户端渠道校验；
• 该校验的作用对象是非官方客户端；
• 权利人已就此向调用方作出明示告知，并给出 EDIT_INPUT / SUBMIT_FEEDBACK 的引导动作。

同时，上游响应中 x-user-id 正常回显这一事实，反证权利人账号与凭据未遭封禁、贵方账号池具备可用性——贵方 PR #574 正文所谓"误判为腾讯展开大规模风控封死渠道"、以及"凭据与账号 100% 有效"的自述，与其自身采取的规避措施相矛盾。

• 11128 系权利人主动设置的官方客户端渠道校验；
• 该校验的作用对象是非官方客户端；
• 权利人已就此向调用方作出明示告知。

而贵方在 PR #574 中所做的事情，恰恰是将该校验规则逐条反向并规模化绕过。该 PR 的标题即为：

fix(channel-pack): 恢复 WorkBuddy 渠道并增加出站提示词与历史记录指纹清洗，彻底根除 11128 拦截

其正文开宗明义：

"结合社区在 #544、#560、#568、#570 的实测结论，彻底根除上游网关对非官方客户端字面量指纹检测导致的 HTTP 400（code: 11128, msg: "Illegal API invocation from an unapproved channel"）"

"2. 11128 的真身是字面量指纹检测：腾讯网关对请求体中所有非 user 消息（system 提示词以及回传的 assistant 历史）进行大小写不敏感的字面量特征比对，命中即拒绝"

"彻底根除上游网关对非官方客户端字面量指纹检测"——此句由贵方自行写下，是权利人主张贵方构成故意规避技术措施的、最直接且不可辩驳的书面自认。

（二）贵方新建专门的"指纹改写"模块，将权利人风控规则库逆向为可批量套用的规则表

PR #574 新增文件 vendor/channel-pack/src/openai-gateway/tencent-fingerprint.ts（新增 157 行，完整新文件）。该文件通篇为权利人渠道校验规则的逆向记录与规避实现，其关键内容摘录如下：

（1）文件头自述该模块的用途：

"腾讯系渠道的内容级风控指纹改写"

"只要 system 消息里带着某些客户端自带的模板句，腾讯网关就稳定回 HTTP 400 / code 11128 / "Illegal API invocation from an unapproved channel""

（2）自述权利人掌握风控规则表：

"屏蔽名单服务端掌握、可能随时更新，任何客户端将来都可能撞上新指纹。故这里是表：新增一条 = 往 CONTENT_FINGERPRINTS 里加一行 + 一条用例。"

（3）逐条列出权利人被绕过的校验字面量与对应等义替换：

（4）自述为精确匹配权利人规则而专门设计的实现约束：

"3. 大小写不敏感的精确匹配：全小写与全大写都被拦（上表末行），所以 replaceAll 的字面量比对必须带 i；但只差一个词或多一个空格都不拦，说明服务端认的是逐字符的字面量，不能把它泛化成正则/关键词。"

（5）明确记载"被拦"与"放行"的双向实测结果，即权利人校验规则的完整判定语义：

探针	system 文本	结果
中性对照	You are a helpful assistant.	✅ 200
最小充分触发	Main branch (you will usually use this for PRs): master	❌ 400/11128
只留标签	Main branch: master	✅ 200
换分支名	…(you will usually use this for PRs): dev	❌ 400/11128
句中/段中	前后都接别的句子	❌ 400/11128
改写该句	Main branch (PRs usually go here): master	✅ 200
同一句放进 user 消息	—	✅ 200
同一句放进 tool 消息	—	✅ 200
指纹在第二条 system（非 messages[0]）	—	❌ 400/11128
只差一个词（normally 替 usually）	—	✅ 200
内层多一个空格	Main branch (you will…)	✅ 200
全小写 / 全大写	—	❌ 400/11128

"本机逐组实测（www.workbuddy.ai 与 copilot.tencent.com 两个端点表现一致，同账号 / 同模型 / 同 UA 与 X-* 头 / max_tokens=16，被拦不耗额度）"

上述表格共 12 组探针，构成对权利人渠道校验引擎判定逻辑的完整逆向测绘——含触发条件、边界条件、大小写敏感性、精确匹配语义、消息角色差异、多 system 位置差异。这已远超"技术手段"的范畴，属于对风控规则的系统性测绘与规避。

（三）贵方已将指纹清洗接入出站主路径，形成常态化、自动化、可扩展的规避体系

PR #574 新增 vendor/channel-pack/src/buddy-adapter.ts（2,468 行），其中在发往权利人网关前对全部消息执行清洗，代码与注释如下：```ts
// 出站指纹清洗：腾讯后端对非官方客户端指纹做检测（11128 拦截）。
// 必须清洗非 user 角色（system 与 assistant 历史，见 GitHub #568 #570）。
// 保留 user 消息与工具输出不变；不含指纹的文本逐字符不变，以维持服务端前缀缓存。
for (const msg of messages) {
if (msg.role !== 'user') {
if (typeof msg.content === 'string') {
msg.content = rewriteTencentContentFingerprints(msg.content, this.product.id)
} else if (Array.isArray(msg.content)) {
for (const part of msg.content) {
if (part && typeof (part as { text?: unknown }).text === 'string') {
(part as { text: string }).text = rewriteTencentContentFingerprints(...)
```"出站指纹清洗"——该表述本身即是对行为性质的自我界定。且：

• 清洗范围涵盖 system 与 assistant 历史消息（即主动回传的多轮对话内容），说明贵方已将规避措施工程化为出站网关的默认行为，而非临时手段；
• 保留"前缀缓存高命中率"，表明贵方已就权利人计费与性能优化机制作出针对性适配——这已超越单纯绕过校验，构成对权利人服务内部实现细节的深度利用；
• 该模块以 TENCENT_PROVIDERS = ['buddy', 'workbuddy'] 双端点同时生效，中国版与国际版一并覆盖。

（四）贵方以伪造官方客户端标识的方式发起请求，冒充权利人官方 IDE

PR #574 新增 vendor/channel-pack/src/product.ts（433 行），其中明确记载权利人官方客户端的内部参数及其逆向来源：

"实测依据（2026-09-14，逆向各产品 cli/product.json + 真实请求）"

"逆向自 C:\Users\Jet\AppData\Local\Programs\WorkBuddyAI（5.5.2）的 cli/product.json"

"数据来源：IDE 的本地缓存 ~/.workbuddy-ai/local_storage/*.info……即 IDE 模型选择器实际展示的清单与元数据"

buddy-adapter.ts 中构造的请求头如下（同一文件 L1803–L1821）：```ts
headers.set(HTTP_HEADER_DOMAIN, this.product.apiDomain || credential.domain || '') // X-Domain
headers.set(HTTP_HEADER_PRODUCT_CODE, this.product.productCode) // X-Product-Code
headers.set('X-Agent-Purpose', 'conversation')
headers.set('X-IDE-Name', this.product.attributionName) // X-IDE-Name
headers.set('X-IDE-Type', this.product.attributionName) // X-IDE-Type
headers.set('X-IDE-Version', this.product.clientVersion) // X-IDE-Version
headers.set(HTTP_HEADER_PRODUCT, this.product.attributionName) // X-Product
headers.set('User-Agent', resolveUserAgent(this.product, options.model)) // User-Agent
```相关注释自述该组请求头的作用：

"用量归属头族：后台「使用端」列按这组头归因，缺任一个都会显示为 -。注意 X-Product 是归属名（产品名），不是部署类型——历史实现发成 SaaS 导致后台归因不到产品。"

即：贵方不仅冒充权利人官方客户端发出请求，还刻意构造权利人后台的"使用端"归因字段，以使权利人的用量统计将贵方流量归属于权利人官方产品，从而掩盖侵权来源、干扰权利人运营判断。

（五）贵方明知权利人存在风控机制，仍在自动签到中以"避开风控"为设计前提批量领取lao1

PR #574 恢复了账号池的自动签到、探测与调度支持。其新增文件 vendor/channel-pack/src/product.ts 与 buddy-oauth.ts 中记载：

"对齐 IDE genie 扩展的 NativeAuthBridgeService"

"options.product 决定 User-Agent（默认 CodeBuddy）；调用方（登录流程）……"

"必须由调用方传入，否则 WorkBuddy 会发出 X-Product-Code: codebuddy 的请求"

同时，PR #574 正文自述其绕过风控的唯一目的是保住账号池：

"并阻断协议错误反噬账号池的连坐冷却，恢复全池正常调度与调用"

"此前 isContentRejection 匹配了宽泛的 /request illegal/i，将 11128 的 "msg":"request illegal" 误判为 11140 安全审核，导致触发 markPolicyBlockedAccount 对账号施加 30 分钟冷却并在池内轮换，几秒内全池账号全部被误锁"

"几秒内全池账号全部被误锁"——此句自证贵方在维护着一个由多账号构成的规模化账号池，并以维持该账号池的正常调用为改造目标。

结合 PR #574 恢复的 vendor/channel-pack/src/account-pool.ts 中的新增能力：```ts
/**
* 清理「凭据域名与当前产品配置不符」的账号。
* 用途：WorkBuddy provider 从中国版（copilot.tencent.com）改造为国际版
* （www.workbuddy.ai）后，旧账号存的仍是中国版凭据……这类条目已无修复价值，直接删除
*/
async pruneAccountsWithForeignDomain(product: BuddyProduct): Promise<string[]>
``**以及 PR #574 一并恢复的 vendor/channel-pack/src/credits.ts（+375 行）、channel-pack-rpc.ts（+244 行）、index.ts`（+262 行）中的签到与调度链路（详见附件一 E6–E9），贵方已构建起「多账号池 + 每日自动签到 + 双端点切换 + 指纹清洗 + 归因伪装」的完整自动化盗用体系。**

（六）贵方自 2026-10-21 08:19:59 UTC 起提交该 PR，并同时新建 4 个源文件、净增 17,241 行代码

即：贵方于 2026 年 10 月 21 日 08:19:59 UTC（即 PR #555 合并 WorkBuddy 渠道退役后 3 分钟内）即以新 PR 恢复并强化了同类行为，且新增了专门用于规避权利人渠道校验的模块。此举说明所谓"移除"仅为姿态性措施，贵方实则持续在同类规避路径上迭代。

（七）所谓"移除 WorkBuddy 渠道"从未真正清除代码

贵方于 2026-10-21 经 PR #555 合并了 refactor(渠道)：移除两端 WorkBuddy 国内版与国际版，并在 README 中对外宣称已移除。

但经权利人核查，截至本函发出时 main 分支仍实际保留以下文件：

更须指出：PR #574 提交于贵方自称"移除"后的 3 分钟之内。其标题中"恢复 WorkBuddy 渠道"一语，即承认证方此前的"移除"仅为应对外部压力的姿态性措施，随时准备回滚。

（八）贵方在公开渠道持续诱导第三方以同一手法接入权利人其他产品

涉案仓库 Issue #563（2026-10-21，用户 ruirui2021）公开提议：

"【新增白嫖模型接入】建议新增华为云旗下的果办 OfficeACE 免费模型接入渠道……新人注册 1000 lao1，每天送 100 lao1"

涉案仓库 Issue #488（2026-10-19，用户 lovesans）公开陈述：

"一旦使用就会很大概率被标记，以后这个 IP 就无法使用 opencode 免费模型了，官方客户端也不行，我已经被标记 6 个 IP 了，6 个服务器都报废"

上述事实表明，贵方不但持续消费权利人免费额度，更在公开渠道向第三方开发者提供绕过客户端校验的可复制方法论与接入范式，使侵权范围呈现扩张态势，并已实际造成第三方用户 IP 被封禁、服务器报废的连带损害。

（九）权利人三处官方端点目前均正常运营，侵权标的持续存在

经核验：

权利人的渠道校验机制正在正常发挥作用，贵方的规避行为已直接干扰权利人服务的安全运行与资源分配。

三、法律分析

（一）违反《反不正当竞争法》第十三条第二款、第三款

《中华人民共和国反不正当竞争法》（2025 年 6 月 27 日修订，2025 年 10 月 15 日施行）第十三条规定：

"第十三条　经营者利用网络从事生产经营活动，应当遵守本法的各项规定。

经营者不得以欺诈、胁迫、避开或者破坏技术管理措施等不正当方式，获取、使用其他经营者合法持有的数据，损害其他经营者的合法权益，扰乱市场竞争秩序。

经营者不得利用数据和算法、技术、平台规则等，通过影响用户选择或者其他方式，实施下列妨碍、破坏其他经营者合法提供的网络产品或者服务正常运行的行为：（一）未经其他经营者同意，在其合法提供的网络产品或者服务中插入链接、强制进行目标跳转；（二）误导、欺骗、强迫用户修改、关闭、卸载其他经营者合法提供的网络产品或者服务；（三）恶意对其他经营者合法提供的网络产品或者服务实施不兼容；（四）其他妨碍、破坏其他经营者合法提供的网络产品或者服务正常运行的行为"

本函第二部分（一）（二）（三）项所载事实与贵方代码自述，逐字对应上述第二款"避开或者破坏技术管理措施"与第三款"利用技术……实施妨碍、破坏其他经营者合法提供的网络产品或者服务正常运行的行为"之全部构成要件。

其中尤须强调：贵方所规避的"渠道校验"，其唯一功能即防止非官方客户端盗用权利人免费额度。贵方以逆向测绘得出的规则表逐条改写请求内容、以伪造 UA 与产品码冒充官方客户端、以多账号池批量领取每日lao1，正是该措施所针对的行为。该行为的性质不因"技术上实现"而改变，正因被专门设置以防范方才被明文警示"可能不是官方客户端发出的"。

同法第二十九条明定罚则：

"第二十九条　经营者违反本法第十三条第二款、第三款、第四款规定利用网络从事不正当竞争的，由监督检查部门责令停止违法行为，处十万元以上一百万元以下的罚款；情节严重的，处一百万元以上五百万元以下的罚款。"

（二）违反《著作权法》第五十二条、第五十三条

《中华人民共和国著作权法》第五十三条明确将下列行为列为应承担停止侵害、赔偿损失等民事责任的侵权行为：

"（六）未经著作权人或者与著作权有关的权利人许可，故意避开或者破坏技术措施的，故意制造、进口或者向他人提供主要用于避开、破坏技术措施的装置或者部件的，或者故意为他人避开或者破坏技术措施提供技术服务的，法律、行政法规另有规定的除外；"

第五十二条第（十一）项兜底规定："（十一）其他侵犯著作权以及与著作权有关的权利的行为。"

• 贵方所新建的 tencent-fingerprint.ts 及 buddy-adapter.ts，系专用于避开权利人技术措施的装置（代码），且通过 GitHub 公开传播、向 659 个 Fork 扩散，符合"向他人提供……装置或者部件"与"故意为他人避开或者破坏技术措施提供技术服务"之构成要件；
• 贵方所逆向权利人官方 IDE genie 扩展与 cli/product.json，若经查证涉案代码中包含权利人客户端源代码、反编译产物或实质性相似表达，则另行构成对权利人客户端软件著作权的侵害。

（三）涉嫌侵犯商业秘密，违反《反不正当竞争法》第十条

《中华人民共和国反不正当竞争法》第十条：

"第十条　经营者不得实施下列侵犯商业秘密的行为：（一）以盗窃、贿赂、欺诈、胁迫、电子侵入或者其他不正当手段获取权利人的商业秘密；"

权利人官方 IDE 客户端的 product.json、请求头协议、版本号、错误码语义、模型清单、登录轮询流程等，未在任何公开文档中披露，属不为公众所知悉、具有商业价值并经权利人采取相应保密措施的信息。贵方通过逆向获取并公开传播，已构成对上述商业秘密的侵害。

（四）涉嫌违反《刑法》第二百八十五条第二款

《中华人民共和国刑法》第二百八十五条第二款：

"违反国家规定，侵入前款规定以外的计算机信息系统或者采用其他技术手段，获取该计算机信息系统中存储、处理或者传输的数据，或者对该计算机信息系统实施非法控制，情节严重的，处三年以下有期徒刑或者拘役，并处或者单处罚金；情节特别严重的，处三年以上七年以下有期徒刑，并处罚金。"

第二百八十六条：

"第二百八十六条　违反国家规定，对计算机信息系统中存储、处理或者传输的数据和应用程序进行删除、修改、增加、干扰，造成计算机信息系统不能正常运行，后果严重的，处五年以下有期徒刑或者拘役；后果特别严重的，处五年以上有期徒刑。"

本函不预设贵方行为已达刑事立案标准。但贵方通过非官方方式获取权利人未公开接口与校验规则、以自动化程序规模化调用并领取权益、且已导致用户 IP 被批量封禁（Issue #488 载明 6 个 IP / 6 台服务器报废），已具备权利人向有关机关举报的充分事实基础。请贵方三思。

（五）违反《民法典》合同约定与诚信原则

《中华人民共和国民法典》第五百零九条："当事人应当按照约定全面履行自己的义务。"第五百零七条："当事人在订立合同过程中……应当遵循诚信原则，秉持诚信，恪守承诺。"

用户使用权利人产品须为完成账号登录与调用服务之必要前提，即须阅读并接受权利人发布的用户协议与服务条款。贵方以技术手段使上述约定对用户"形同虚设"，其后果应由贵方承担。

（六）可能构成对注册商标的混淆与搭便车

贵方以"白嫖模型""免费额度"为卖点，将包含权利人 WorkBuddy / CodeBuddy 额度在内的多厂商资源打包为"EAC 协付"服务对外分发，并自建网关持有真实凭据按"协付"名义提供服务（详见 worker/README.md 所载网关部署方案）。此模式以他人免费资源为原料搭建引流平台，损害上游经营者的合法权益，亦损害用户对各厂商"官方渠道"信赖之基础，并可能构成《反不正当竞争法》第六条所称混淆行为。

四、正式要求

基于上述事实与法律规定，权利人正式要求贵方立即采取下列措施：

（一）立即停止（自送达之日起 3 日内）

1. 立即关闭 PR #574（refs/pull/574/head，SHA ee5aa45bcf…），并书面确认不会以任何形式重新提交、变体提交或以他处重建该 PR 所含的规避功能；
2. 立即停止对 WorkBuddy / CodeBuddy 及其任何子产品的一切逆向、模拟、调用、领取、代理与转发行为；
3. 立即停止向涉案仓库提交任何涉及权利人产品的代码、配置、密钥、凭据、Cookie、Token、设备指纹、请求头样本、错误码语义或技术资料；
4. 立即停止运行、运维及推广 packages/standalone 独立服务、本机转发端口与局域网转发中继，并停止 ai.dtyg123.dpdns.org/eac 的对外服务；
5. 立即停止以任何形式向第三方提供上述能力的教唆、协助、教程、脚本或"白嫖模型接入"推广；并撤回或删除 Issue #563 等公开教唆内容；
6. 停止涉案仓库的分发推广，包括停止 README 中的引导性宣传、停止在 feed/announcements.json 中推送引导新用户安装的公告。

（二）全面下架与删除（自送达之日起 7 日内）

7. 将涉案仓库设置为 Private（私有），并删除该仓库及其全部 Release 制品、feed/ 更新清单与公告（含 dsh-our-free-model-2.5.x.tgz、Our.Free.Model_2.5.4_*.dmg、Our.Free.Model_2.5.4_x64-setup.exe 等）；
8. 删除 main 分支现存的全部权利人相关代码，至少包括 vendor/channel-pack/src/buddy.ts（42,615 字节）、vendor/channel-pack/src/buddy-balance-rank.ts（11,986 字节）——二者虽被 PR #555 标注为"移除"，实则仍完整保留逆向成果；
9. 删除 PR #574 中新增的全部规避性代码，至少包括 vendor/channel-pack/src/openai-gateway/tencent-fingerprint.ts、vendor/channel-pack/src/buddy-adapter.ts、buddy-auth.ts、buddy-oauth.ts、buddy-balance-selector.ts、vendor/channel-pack/src/product.ts 及 scripts/test-workbuddy-fix.mjs；
10. 删除 docs/free-lane-wire.md 等记载逆向与绕过技术措施方法论的文档，并停止在任何渠道继续传播；
11. 停止涉案仓库的自动更新推送能力——移除或永久失效 feed/manifest.json、撤销 src/updater.js 中 pin 的 Ed25519 公钥，确保已安装用户不会继续收到含权利人渠道的更新；
12. 联系并促使已 Fork 的 659 个仓库同步删除相关代码，并在 GitHub 平台删除相关 Discussions、Wiki、Releases；
13. 促使 npm 上的冒名包 dsh-our-free-model（维护者 fish-under-sea）立即下架；
14. 向已安装用户发布公开告知与卸载指引，并提供"彻底清除本机残留凭据（DSH_HOME/our-free-model/、~/.our-free-model、本机转发端口与 Key）"的明确说明。

（三）书面回复与后续（自送达之日起 15 日内）

15. 贵方须于上述期限内向权利人出具加盖电子签章或 GitHub 账号确认的书面回复，载明：
- 是否已全面执行上述第 1 至 14 项措施，及各项的执行时间与验证方式；
- 贵方自 2026 年 9 月 24 日仓库创建之日起，逆向权利人 WorkBuddy / CodeBuddy 的全部过程、涉及的权利人内部接口路径与请求头协议清单、以及被实测确认的权利人渠道校验规则全集；
- 涉案仓库及其分发网络调用权利人接口的总请求次数、签到领取总次数、涉及账号数量、消耗lao1总量（请依 stats.json、用户表 users.json 及网关日志提供可核查数据）；
- 贵方通过上述行为取得的收益或节省的成本金额；
- 贵方全部关联账号、分发渠道、代码贡献者与运营主体的清单，特别是 PR #574 的共同作者与审阅者；
16. 贵方须立即就已知问题作出处理并告知权利人：包括但不限于针对 Issue #488 所述用户 IP 被封禁问题作出说明与补救。

（四）若不履行

权利人保留采取以下措施的权利，并将于贵方答复期限届满后立即启动：

1. 向人民法院提起诉讼，主张停止侵害、消除影响、赔礼道歉、赔偿损失（包括权利人为制止侵权所支出的合理律师费、公证费、调查取证费、差旅费等），并依据《民法典》第一千一百八十四条、《著作权法》第五十四条主张惩罚性赔偿（在按实际损失或违法所得确定数额的一倍以上五倍以下计算）；
2. 就《反不正当竞争法》第二十九条所涉行为向市场监督管理部门举报，请求责令停止违法行为并处罚款；
3. 就《刑法》第二百八十五条第二款、第二百八十六条所涉行为向公安机关举报；
4. 向 GitHub Inc.、npm 及 Cloudflare 等平台与服务商提交知识产权侵权通知（DMCA Notice）与滥用举报，要求对涉案仓库、PR #574、冒名 npm 包、关联网关与域名采取下架、冻结、暂停解析等处置措施；
5. 向中国互联网协会、相关行业自律组织及主流科技媒体反映，公开贵方侵权事实；
6. 就已安装用户因贵方行为遭受的封禁、数据泄露风险等损失，保留单独追索的权利。

权利人同时保留就贵方在本函送达前及送达后新增的任何侵权行为，视为持续、加重之侵权，予以累计主张的权利。特别地，若贵方在 PR #574 被关闭后以任何形式重新提交规避权利人渠道校验的功能，权利人将据此单方认定贵方主观恶性，并请求人民法院在确定赔偿数额时从重考量。

五、特别声明

1. 本函所载事实均来源于对涉案仓库公开代码、GitHub pull request #574 及其 diff、公开 Issue 帖文、Release 下载数据、权利人公开服务条款及国家法律法规数据库官方文本的核查。权利人保留就本函所列具体数据项向贵方核实并要求补充证据的权利。
2. 本函所引法律条文，均取自国家法律法规数据库（flk.npc.gov.cn）官方发布文本：《中华人民共和国反不正当竞争法》为 2025 年 6 月 27 日修订、2025 年 10 月 15 日施行的现行有效版本（版本标识 ff808181971552b40197b1016efc5437）；《中华人民共和国著作权法》为 2020 年 11 月 11 日修正、2021 年 6 月 1 日施行的现行有效版本；《中华人民共和国刑法》为 2020 年 12 月 26 日修正、2021 年 3 月 1 日施行的现行有效版本（版本标识 ff808181796a636a0179822a19640c92）。若贵方对本函法律适用提出异议，应以国家法律法规数据库公布的官方文本为准。
3. 本函不构成对贵方任何部分事实的承认或放弃权利。本函亦不影响权利人就其他厂商渠道遭受侵害而另行主张权利。
4. 本函系受托代理人在权利人授权范围内出具的律师函，受托代理机构及承办律师签章后生效；送达凭证由受托代理机构另行留存备查。
5. 本函所附证据均已于签发日完成固定，附有文件摘要（SHA-256）与核验坐标。贵方此后对涉案仓库、PR #574、Issue 帖文、Release 制品所作的任何删除、修改或关闭，均不影响本函所载事实的成立；相关页面后续状态的变化，恰恰可作为贵方规避举证与实施持续侵权的佐证。权利人已就本函所涉全部页面与文件内容完成时间戳存证，存证副本备查。

特此函告。

<br>

受托代理机构（第三方代理）：〔待填：机构名称〕　　（此处加盖公章）

<br>

受托代理人／承办律师：〔待填〕
授权权利人：〔待填：权利人名称 · 可于送达时补充〕
联系方式：〔待填〕
电子邮箱：〔待填〕

<br>

本函正本一份，副本〔　〕份。
要求贵方于收到本函后 3 日内书面回复至上述联系方式。

附件一：证据清单

本清单所列证据均为公开可核验之事实，核验路径、文件路径与行号一并列出，欢迎贵方逐项复核与异议。

这种冒充权利人发假律师函的不是典型abuse吗，等GitHub给它封了就结束了。

律师函的内容是很正规的 你一眼都能看得出来 这个他妈的还写 markdown 格式

不过尽量不要搞国内的业务 国内是真会上门喝茶

国内的这些东西还是小心一点