目前公认的编程界翘楚就是 Opus4.6 和 GPT5.4但是到底谁更强一些众说纷纭无论内网外网都有人觉得 GPT5.4 要比 Opus4.6 强当然也有人觉得 Opus4.6 明显要比 GPT5.4 强如果只是隔空对战其实很难分出胜负。我们要有一个具体的场景才能分胜负。我发现我最近测试的例子非常好很能区分实力等级。所以今天就来看一下 Opus4.6 和 GPT5.4 的开发实战情况。下面先看基准再看例子然后对比最后发表一下我自己感受按GPT一贯的表述风格结论先行GPT5.4能力还行但是有点“自以为是”。1、基准数据为了让大家对这两个模型了解的更加透彻以及对比基准和实战差异。我先给大家整理一下基准数据整理这数据真是一个头两个大。这两家也是牛逼我发的基准你不发你不发的基准我来发尤其是编程这一块一个发 SWE-Bench Verified另一个发 SWE-Bench Pro还有一些是基准参数或者基准版本不同……凑合看吧我们还是实际效果为主。2、测试场景基准看完了我们来看一下我的测试场景。我的测试场景是我正在开发一个 Coding Plan 的测试平台。可以管理各种平台的 API。可以一键批量测试不同的平台的速度、tokens 消耗、回答内容等。可以进行单聊和群聊。可以进行系统提示词和角色提示词的管理。目前已经具备把不同平台的模型拉到同一个群里面的功能。但是我希望更进一步。我希望扩展角色功能然后让角色进行群聊而不是直接拉平台去群聊。这样自由度和可玩性就大大提高了。然后我希望AI能帮我完成这次功能升级这次测试和从头开始不一样当前已经有一定的上下文我统计了一下源代码有 60 个文件总共 6682 行。src/ ├── app/ # 页面和 API 路由 │ ├── api/ # 后端 API (chat, roles, platforms, upload, test...) │ ├── chat/ # 群聊页面 │ ├── single-chat/ # 单聊页面 │ ├── platforms/ # 平台管理页面 │ ├── settings/ # 系统设置页面 │ ├── test/ # 批量测试页面 │ └── history/ # 测试历史页面 ├── components/ # React 组件 │ ├── ui/ # 通用 UI 组件 (shadcn 自定义) │ ├── platforms/ # 平台相关组件 │ ├── layout/ # 布局组件 │ └── test/ # 测试相关组件 ├── lib/ │ ├── types.ts # 所有类型定义 │ ├── prompt-builder.ts # 4 层提示词组合 │ ├── store/ # 数据 CRUD (JSON 文件读写) │ └── api-clients/ # 统一 API 客户端 data/ # 数据文件 (platforms.json, roles.json, chat-sessions/, ...) public/avatars/ # 角色头像上传目录除了有一定的代码方面的上下文之外这次还涉及到数据结构和业务逻辑的修改。同时涉及到多个功能页面的修改虽然这不是什么高精尖的系统但是这次的修改还是有一定的难度。如果这个需求能被轻松搞定那么证明这个模型已经有一定的工程实战能力。如果完美完成没有遗漏就证明有一定的“心智”。目前做最好的是 Opus4.6其次是 GLM5……号称编程和智能体 SOTA 的 MiniMax 最拉跨这个事情我要说很久因为它吹了最厉害的牛逼。今天虽然叫巅峰对决其实主要是看 GPT5.4 表现然后把 Opus4.6 拿过来对比一下3、测试结果基于相同的 Base 代码GPT5.4 的结果已经出来了。我们还是用三个步骤来评判能不能用好不好用全不全面能不能用第一个问题是能不能用这个很关键首先我可以明确的告诉大家GPT5.4一次搞定的结果是完全可以使用的。系统设计中的角色功能已经升级现在包含了头像平台模型内容。而且增删改查都没有任何问题。也对原始数据进行了升级加载没有平台的数据也不会出错。好不好用基本是好用的但是有些细节需要提升。你们看头像这个字段它居然让我填写 URL这是什么魔鬼体验~~。而且我提示词里面明确说了这个头像需要能上传需要有预设如果我都不选那么应该有默认。这一点需求实现的不是很好。除此之外基本体验还是不错的。全不全面我这个需求里其实有一个隐藏考点。这个考点就是能不能主动删除冗余功能。冗余未必是坏事儿但是在我这个系统里面一旦角色功能升级之后。平台管理里面就没必要也不应该留角色设置的选项了。平台只负责管理平台相关的内容比如API接口模型协议等。这个地方GPT5.4并没有考虑到也没有询问我。4、对话过程这部分我会分享一下我是如何写提示词的它又是如何回答的。但是不会讲一行代码因为我们用“自然语言”编程。主要是考验模型对需求的理解能力和实现能力。我的需求目前群聊接力的时候可以选择平台管理中的模型也可以对这些模型预先配置系统提示词和角色提示词这样已经可以通过系统提示词来个性化聊天了。但是通过平台配置里面绑定角色比较有局限性——这样一个平台就只能是一个角色。 我希望换另外一种设置**角色里面选模型**然后群聊开始的时候我可以直接选平台也可以直接选角色。角色的管理还是在系统设置的角色管理中进行。 为了实现上面的需求角色功能需要升级 - 除了可以设置提示词之外还得能**选择平台和模型** - 另外还能**设置头像** - 如果设置了头像群聊的时候就显示自定义头像如果没有设置头像就用对应模型平台的 logo 作为头像 我的需求大概是这样。说说你对这个需求的理解不急着写代码GPT5.4 的分析这会带来两个很重要的产品变化 - “平台”回到基础设施层只负责连接能力和模型列表 - “角色”变成业务层身份同一个平台可以派生出多个不同角色因为每个角色都能选自己的模型和提示词 不再受“一个平台只能绑一个角色”的限制 关于头像我理解你的规则是 - 角色配置了头像群聊里显示角色头像 - 角色没配置头像回退显示其所绑定平台的 logo - 直接选平台参会时还是显示平台 logo 再往下落到聊天行为上我的理解是 - 如果群聊里选的是“角色”真正调用接口时仍然走它绑定的平台和模型 - 但前端展示、会话身份、接力队列里的名字应该优先按“角色名”显示而不是平台名 - 平台名更像底层来源信息模型名仍可作为附加信息展示 我还顺手确认了当前实现现状也和你的判断一致 - src/lib/types.ts 里 Role 目前只有 name content - src/lib/prompt-builder.ts 现在是把“平台默认角色”拼进系统提示词 - src/app/chat/page.tsx 和 src/components/ui/chat-message.tsx 当前也都是以“平台”为参会主体 如果继续往下做我下一步会先把这个需求拆成一份实现方案重点明确 - 数据结构怎么改 - 群聊参与者到底用“平台项”和“角色项”怎样统一建模 - 旧数据如何兼容迁移 这轮结果我已经按仓库规则写入 docs/chatlogs.md。这个环节 GPT5.4 分析的已经很全面了而且它代码也看了所以并不是单纯建议而是结合了需求和现有代码给出了它的理解。这一点是做的很好的。并且做了下一步的规划。这一点也是对的。但是它其实忘了一个很关键的问题询问我的意见如果是 Opus 系列的模型就会找我确认关键需求了。三、待确认的问题 1. 角色与平台的关系一个角色绑定一个平台一个模型对吗还是说一个角色可以绑定多个平台我理解应该是一对一一个角色 一个人格 一个特定的平台/模型 2. 群聊中混合选择是否允许同一个群聊里既选了几个裸平台又选了几个角色比如群里有角色A用 GPT-4o角色B用 Claude裸的 Gemini 平台 3. 同模型多角色是否允许同一个模型被多个角色使用比如严谨学者和搞笑段子手都绑定 GPT-4o在同一个群聊里同时出现 4. 头像格式自定义头像是上传图片文件还是选择预设图标/emoji还是都支持 5. 平台上原有的 defaultRoleId 字段是否要废弃掉既然角色不再绑定在平台上平台配置表单里的默认角色选择器是不是可以移除了 但是 GPT5.4 似乎没有这个想法它完全没有要询问我的意思而是直接说它准备干什么了我下一步会先把这个需求拆成一份实现方案重点明确 - 数据结构怎么改 - 群聊参与者到底用“平台项”和“角色项”怎样统一建模 - 旧数据如何兼容迁移注意这些句子是没有问号的是陈述也就是它已经打定主意了要这么干。除非我直接阻止它它既然不问我也就不提了让他继续。我提了那就变成我的功劳了然后它做了一个开发方案。方案做的挺好的--除了没考虑的问题之外你永远不用怀疑GPT5.4做方案的能力。做完方案就直接开始写代码了。整个过程吧还算丝滑先分析问题再做执行方案然后开始执行。对小白来说是不是非常好的体验 你就说两个继续就可以了。但是……我要说这个世界上的所有业务都包含了大量的逻辑分支。所有的程序员在开发之前都必须确认很多需求。越是老程序员越明白这个道理。否则……结果……很严重。GPT5.4不问就干其实多少有点“自以为是”了我们来看看结果吧结果就是测完之后可以发现好几个问题。基本不是技术问题而是业务逻辑问题。第一个问题平台和角色群聊。因为它没有询问我所以它不知道我希望的是平台和角色一定要分清楚。不应该把角色和平台混在一起聊天他们是互斥的选项。选了平台就不允许选角色选了角色就不允许选平台。万幸的是它在实现过程中并没有 bug这个功能是可以用的还是有点东西的。但是我要再次强调我绝对不允许我的程序员这么处理业务逻辑的。通过对比你可以明显感觉到GPT5.4 和 Opus4.6 的处理过程是完全不一样的。侧面也可以印证 GLM、Kimi、MiniMax 全“借鉴”了 Opus4.6 的模式。因为它们处理问题的过程几乎一模一样只是具体的能力有差别而已。GPT5.4 这次开发基本是成功的代码方面没有明显的 bug。但是相比 Opus4.6 有三个问题第一个头像要有上传功能这一点执行没有做到位体验没有做好。第二个角色和平台互斥它没有做到。Opus4.6 一脉的全部询问并做到了。第三个平台管理里的冗余选项没有删除处理不够全面。那么为什么会导致这个问题呢就是因为它“自以为是”但凡它问一句就不会是这个结果。翻看 Opus4.6 的开发过程可以发现上面的三个问题全部考虑到了进行了询问确认而且给了很详细的建议。那么问题来了为什么 Opus4.6 一拿到这个需求他就能意识到必须要问这些问题呢这就是久经战场的老兵和新兵蛋子的最大差别。当然这只是一个例子而已不能说明一切仅供参考。5、我的感受GPT系列模型整体实力肯定不弱的绝对是一线水平。我对 GPT 的整体感觉是下限比较高大部分常规问题能 hold 住比较稳。让它帮你出方案也是一套一套的考虑非常全面甚至过度全面。但是它那个网页版我是用的越来越少了。很多人都感觉它“爹味”太重我也是同感ChatGPT 给人的感觉是非常照顾你的感受非常愿意指引你关爱你。刚开始使用感觉尚可但是久而久之就会很难受。换个角度看其实它是把你当弱智和缺爱儿童一般对待这就是一种自以为是的傲慢自以为所有人都需要它的帮助自以为它全知全能自以为所有人都爱看它长篇大论。我在网页对话的时候随便一个问题它都洋洋洒洒一大片生怕我不知道它多厉害多专业。还有它那套话术……我不喜欢这样的人我也不喜欢这种AI。所以自从用了 Claude 之后我就很少用 ChatGPT只有在配额消耗完成之后或者 tokens 消耗巨大的场景才会用一下。整体来说 GPT-Codex 系列会比网页版的GPT好一些在 Codex 中把模型换成 GPT5.4-Codex然后调整到 High 再加上 Fast。目前体验还可以它终于会在每次修改之前用中文说清楚它大概是在做什么了这个界面清晰了很多。过度设计、过度输出的问题也有改善很多另外 GPT 这一系列还有一个优点比较容易用上不容易封号GPT能力还可以配额又多那么自然对很多人来说都是最优选择了。但是的实际使用的感受是在编程方面上限有限总的来说找毛病一流干开发二流。还是有点慢不够犀利。最后我的原则是有得选的话选最终聪明最能干的。我觉得这个“人”是 Opus4.6最后我已经把CodingPlan的这个base版本发不到github上面了大家有兴趣的可以在自己电脑上测试。地址https://github.com/JarvisPMS/codingplan另外关于Opus4.6和GPT5.4 的9个例子的对比可以看这里https://topai.tonyhub.xyz/收工收工
巅峰对决：Opus4.6又赢了，GPT5.4还差点意思！
发布时间：2026/7/15 13:39:18
目前公认的编程界翘楚就是 Opus4.6 和 GPT5.4但是到底谁更强一些众说纷纭无论内网外网都有人觉得 GPT5.4 要比 Opus4.6 强当然也有人觉得 Opus4.6 明显要比 GPT5.4 强如果只是隔空对战其实很难分出胜负。我们要有一个具体的场景才能分胜负。我发现我最近测试的例子非常好很能区分实力等级。所以今天就来看一下 Opus4.6 和 GPT5.4 的开发实战情况。下面先看基准再看例子然后对比最后发表一下我自己感受按GPT一贯的表述风格结论先行GPT5.4能力还行但是有点“自以为是”。1、基准数据为了让大家对这两个模型了解的更加透彻以及对比基准和实战差异。我先给大家整理一下基准数据整理这数据真是一个头两个大。这两家也是牛逼我发的基准你不发你不发的基准我来发尤其是编程这一块一个发 SWE-Bench Verified另一个发 SWE-Bench Pro还有一些是基准参数或者基准版本不同……凑合看吧我们还是实际效果为主。2、测试场景基准看完了我们来看一下我的测试场景。我的测试场景是我正在开发一个 Coding Plan 的测试平台。可以管理各种平台的 API。可以一键批量测试不同的平台的速度、tokens 消耗、回答内容等。可以进行单聊和群聊。可以进行系统提示词和角色提示词的管理。目前已经具备把不同平台的模型拉到同一个群里面的功能。但是我希望更进一步。我希望扩展角色功能然后让角色进行群聊而不是直接拉平台去群聊。这样自由度和可玩性就大大提高了。然后我希望AI能帮我完成这次功能升级这次测试和从头开始不一样当前已经有一定的上下文我统计了一下源代码有 60 个文件总共 6682 行。src/ ├── app/ # 页面和 API 路由 │ ├── api/ # 后端 API (chat, roles, platforms, upload, test...) │ ├── chat/ # 群聊页面 │ ├── single-chat/ # 单聊页面 │ ├── platforms/ # 平台管理页面 │ ├── settings/ # 系统设置页面 │ ├── test/ # 批量测试页面 │ └── history/ # 测试历史页面 ├── components/ # React 组件 │ ├── ui/ # 通用 UI 组件 (shadcn 自定义) │ ├── platforms/ # 平台相关组件 │ ├── layout/ # 布局组件 │ └── test/ # 测试相关组件 ├── lib/ │ ├── types.ts # 所有类型定义 │ ├── prompt-builder.ts # 4 层提示词组合 │ ├── store/ # 数据 CRUD (JSON 文件读写) │ └── api-clients/ # 统一 API 客户端 data/ # 数据文件 (platforms.json, roles.json, chat-sessions/, ...) public/avatars/ # 角色头像上传目录除了有一定的代码方面的上下文之外这次还涉及到数据结构和业务逻辑的修改。同时涉及到多个功能页面的修改虽然这不是什么高精尖的系统但是这次的修改还是有一定的难度。如果这个需求能被轻松搞定那么证明这个模型已经有一定的工程实战能力。如果完美完成没有遗漏就证明有一定的“心智”。目前做最好的是 Opus4.6其次是 GLM5……号称编程和智能体 SOTA 的 MiniMax 最拉跨这个事情我要说很久因为它吹了最厉害的牛逼。今天虽然叫巅峰对决其实主要是看 GPT5.4 表现然后把 Opus4.6 拿过来对比一下3、测试结果基于相同的 Base 代码GPT5.4 的结果已经出来了。我们还是用三个步骤来评判能不能用好不好用全不全面能不能用第一个问题是能不能用这个很关键首先我可以明确的告诉大家GPT5.4一次搞定的结果是完全可以使用的。系统设计中的角色功能已经升级现在包含了头像平台模型内容。而且增删改查都没有任何问题。也对原始数据进行了升级加载没有平台的数据也不会出错。好不好用基本是好用的但是有些细节需要提升。你们看头像这个字段它居然让我填写 URL这是什么魔鬼体验~~。而且我提示词里面明确说了这个头像需要能上传需要有预设如果我都不选那么应该有默认。这一点需求实现的不是很好。除此之外基本体验还是不错的。全不全面我这个需求里其实有一个隐藏考点。这个考点就是能不能主动删除冗余功能。冗余未必是坏事儿但是在我这个系统里面一旦角色功能升级之后。平台管理里面就没必要也不应该留角色设置的选项了。平台只负责管理平台相关的内容比如API接口模型协议等。这个地方GPT5.4并没有考虑到也没有询问我。4、对话过程这部分我会分享一下我是如何写提示词的它又是如何回答的。但是不会讲一行代码因为我们用“自然语言”编程。主要是考验模型对需求的理解能力和实现能力。我的需求目前群聊接力的时候可以选择平台管理中的模型也可以对这些模型预先配置系统提示词和角色提示词这样已经可以通过系统提示词来个性化聊天了。但是通过平台配置里面绑定角色比较有局限性——这样一个平台就只能是一个角色。 我希望换另外一种设置**角色里面选模型**然后群聊开始的时候我可以直接选平台也可以直接选角色。角色的管理还是在系统设置的角色管理中进行。 为了实现上面的需求角色功能需要升级 - 除了可以设置提示词之外还得能**选择平台和模型** - 另外还能**设置头像** - 如果设置了头像群聊的时候就显示自定义头像如果没有设置头像就用对应模型平台的 logo 作为头像 我的需求大概是这样。说说你对这个需求的理解不急着写代码GPT5.4 的分析这会带来两个很重要的产品变化 - “平台”回到基础设施层只负责连接能力和模型列表 - “角色”变成业务层身份同一个平台可以派生出多个不同角色因为每个角色都能选自己的模型和提示词 不再受“一个平台只能绑一个角色”的限制 关于头像我理解你的规则是 - 角色配置了头像群聊里显示角色头像 - 角色没配置头像回退显示其所绑定平台的 logo - 直接选平台参会时还是显示平台 logo 再往下落到聊天行为上我的理解是 - 如果群聊里选的是“角色”真正调用接口时仍然走它绑定的平台和模型 - 但前端展示、会话身份、接力队列里的名字应该优先按“角色名”显示而不是平台名 - 平台名更像底层来源信息模型名仍可作为附加信息展示 我还顺手确认了当前实现现状也和你的判断一致 - src/lib/types.ts 里 Role 目前只有 name content - src/lib/prompt-builder.ts 现在是把“平台默认角色”拼进系统提示词 - src/app/chat/page.tsx 和 src/components/ui/chat-message.tsx 当前也都是以“平台”为参会主体 如果继续往下做我下一步会先把这个需求拆成一份实现方案重点明确 - 数据结构怎么改 - 群聊参与者到底用“平台项”和“角色项”怎样统一建模 - 旧数据如何兼容迁移 这轮结果我已经按仓库规则写入 docs/chatlogs.md。这个环节 GPT5.4 分析的已经很全面了而且它代码也看了所以并不是单纯建议而是结合了需求和现有代码给出了它的理解。这一点是做的很好的。并且做了下一步的规划。这一点也是对的。但是它其实忘了一个很关键的问题询问我的意见如果是 Opus 系列的模型就会找我确认关键需求了。三、待确认的问题 1. 角色与平台的关系一个角色绑定一个平台一个模型对吗还是说一个角色可以绑定多个平台我理解应该是一对一一个角色 一个人格 一个特定的平台/模型 2. 群聊中混合选择是否允许同一个群聊里既选了几个裸平台又选了几个角色比如群里有角色A用 GPT-4o角色B用 Claude裸的 Gemini 平台 3. 同模型多角色是否允许同一个模型被多个角色使用比如严谨学者和搞笑段子手都绑定 GPT-4o在同一个群聊里同时出现 4. 头像格式自定义头像是上传图片文件还是选择预设图标/emoji还是都支持 5. 平台上原有的 defaultRoleId 字段是否要废弃掉既然角色不再绑定在平台上平台配置表单里的默认角色选择器是不是可以移除了 但是 GPT5.4 似乎没有这个想法它完全没有要询问我的意思而是直接说它准备干什么了我下一步会先把这个需求拆成一份实现方案重点明确 - 数据结构怎么改 - 群聊参与者到底用“平台项”和“角色项”怎样统一建模 - 旧数据如何兼容迁移注意这些句子是没有问号的是陈述也就是它已经打定主意了要这么干。除非我直接阻止它它既然不问我也就不提了让他继续。我提了那就变成我的功劳了然后它做了一个开发方案。方案做的挺好的--除了没考虑的问题之外你永远不用怀疑GPT5.4做方案的能力。做完方案就直接开始写代码了。整个过程吧还算丝滑先分析问题再做执行方案然后开始执行。对小白来说是不是非常好的体验 你就说两个继续就可以了。但是……我要说这个世界上的所有业务都包含了大量的逻辑分支。所有的程序员在开发之前都必须确认很多需求。越是老程序员越明白这个道理。否则……结果……很严重。GPT5.4不问就干其实多少有点“自以为是”了我们来看看结果吧结果就是测完之后可以发现好几个问题。基本不是技术问题而是业务逻辑问题。第一个问题平台和角色群聊。因为它没有询问我所以它不知道我希望的是平台和角色一定要分清楚。不应该把角色和平台混在一起聊天他们是互斥的选项。选了平台就不允许选角色选了角色就不允许选平台。万幸的是它在实现过程中并没有 bug这个功能是可以用的还是有点东西的。但是我要再次强调我绝对不允许我的程序员这么处理业务逻辑的。通过对比你可以明显感觉到GPT5.4 和 Opus4.6 的处理过程是完全不一样的。侧面也可以印证 GLM、Kimi、MiniMax 全“借鉴”了 Opus4.6 的模式。因为它们处理问题的过程几乎一模一样只是具体的能力有差别而已。GPT5.4 这次开发基本是成功的代码方面没有明显的 bug。但是相比 Opus4.6 有三个问题第一个头像要有上传功能这一点执行没有做到位体验没有做好。第二个角色和平台互斥它没有做到。Opus4.6 一脉的全部询问并做到了。第三个平台管理里的冗余选项没有删除处理不够全面。那么为什么会导致这个问题呢就是因为它“自以为是”但凡它问一句就不会是这个结果。翻看 Opus4.6 的开发过程可以发现上面的三个问题全部考虑到了进行了询问确认而且给了很详细的建议。那么问题来了为什么 Opus4.6 一拿到这个需求他就能意识到必须要问这些问题呢这就是久经战场的老兵和新兵蛋子的最大差别。当然这只是一个例子而已不能说明一切仅供参考。5、我的感受GPT系列模型整体实力肯定不弱的绝对是一线水平。我对 GPT 的整体感觉是下限比较高大部分常规问题能 hold 住比较稳。让它帮你出方案也是一套一套的考虑非常全面甚至过度全面。但是它那个网页版我是用的越来越少了。很多人都感觉它“爹味”太重我也是同感ChatGPT 给人的感觉是非常照顾你的感受非常愿意指引你关爱你。刚开始使用感觉尚可但是久而久之就会很难受。换个角度看其实它是把你当弱智和缺爱儿童一般对待这就是一种自以为是的傲慢自以为所有人都需要它的帮助自以为它全知全能自以为所有人都爱看它长篇大论。我在网页对话的时候随便一个问题它都洋洋洒洒一大片生怕我不知道它多厉害多专业。还有它那套话术……我不喜欢这样的人我也不喜欢这种AI。所以自从用了 Claude 之后我就很少用 ChatGPT只有在配额消耗完成之后或者 tokens 消耗巨大的场景才会用一下。整体来说 GPT-Codex 系列会比网页版的GPT好一些在 Codex 中把模型换成 GPT5.4-Codex然后调整到 High 再加上 Fast。目前体验还可以它终于会在每次修改之前用中文说清楚它大概是在做什么了这个界面清晰了很多。过度设计、过度输出的问题也有改善很多另外 GPT 这一系列还有一个优点比较容易用上不容易封号GPT能力还可以配额又多那么自然对很多人来说都是最优选择了。但是的实际使用的感受是在编程方面上限有限总的来说找毛病一流干开发二流。还是有点慢不够犀利。最后我的原则是有得选的话选最终聪明最能干的。我觉得这个“人”是 Opus4.6最后我已经把CodingPlan的这个base版本发不到github上面了大家有兴趣的可以在自己电脑上测试。地址https://github.com/JarvisPMS/codingplan另外关于Opus4.6和GPT5.4 的9个例子的对比可以看这里https://topai.tonyhub.xyz/收工收工
 + 自研状态快照工具链（附GitHub私有仓库邀请码）)
