吐槽下腾讯混元大模型的 API，不敢相信这是腾讯的水平

这不是腾讯稳定发挥吗

很正常，腾讯的文档不是一直出了名的烂吗

tx 的请求参数签名很多服务都有啊，不光是这个

@mmm159357456 之前对接过其它的服务，用的是 SDK ，不过这个混元大模型还没有官方 SDK ，也没有文档引导开发者去找以前的实现示例，单纯只是对接混元大模型的时候就就只能开发者自己去实现参数拼接和签名算法这部分了，毕竟新人也不清楚这个签名算法和其它服务的实现是不是一样的

@Bazingal 是我孤陋寡闻了

@me1onsoda

签名没问题，但关心 body 的格式和内容就过分了，谁设计的，不胜任，并且已经影响了商誉

还好吧，都没验证客户端时间戳，谈不上复杂。

祖传签名

腾讯传统。
另外，腾讯的文档烂 也是传统

正常，之前接微信支付和公众号的 API ，各种英文拼写错误和大小写不一致，可能腾讯就是不在乎给大家喂吧

腾讯很多业务都是外包的

腾讯是这样的，之前写微信小程序，踩了好多文档的坑

这才是腾讯啊，原来它的小程序、公众号就是这么设计的，文档也是这么烂的。

微信小程序的文档出了名的

看标题， [难以置信是腾讯的水平] ，我还以为你是要夸混元大模型 api 非常好呢。
腾讯 api 和文档烂是众所周知的事实。你肯定没开发过小程序和公众号

对接过微信 api 都应该知道腾讯是个什么勾吧

签名有 golang 的例子，此外还有 node 等
文档的确细节的确不够准确

你应该庆幸文档对应的功能存在，小程序这次隐私弹窗文档出来了但是背后的功能还没做完

这个产品应该是他们内部做的没错了，绝对不是外包的水平。

@cloudzqy 确是没开发过，算是第一次用腾讯的 API （短信除外）

你不觉得 tx 开发的东西都透露着一股二逼气息吗

你去看看腾讯小程序社区多少人骂的，简直离谱。

但凡有一点能力，会给互联网公认毒瘤卖命？

文档一般是实习生写的，真开发没有时间……

不幸在 16 年对结果 WX 的支付 API 和公众号 API ，那真不是一般的烂

习惯就好，tx 就连 DNSPod 的 api 文档也能出错，我记得好像文档上说是要写定 UA 才合法。但实际是不能加 UA ，否则 403 。

对比下火山或者头条的 api 差距真的是高下立判

腾讯的文档出了名的烂，不及时更新，返回数据不对版

签名是真的蠢，我看到这个签名想合到自己的项目里面都头大

正常现象，腾讯除非全力拿资源 all in 某件事情，会做的很认真，不然跟一般公司差别不大

腾讯文档，那就不奇怪了

之前第一次阅读微信支付的开发文档时，我发现官方的示例程序还需要修改才能编译成功时，我也是这么震惊的。。

签名算法倒没什么，但是文档烂开发者不友好这个是出名的，从没改过

有文档不错了。。你等他再迭代几版你可能用 API 都得靠猜了。

微信公众号 小程序的文档跟屎一样 有时候修改了特性不更新文档，以为是自己程序的问题，该死

看看 那个公众号 小程序的文档， 只有 php 代码示例，就是一群不知所谓的人在开发。

帮助文档里有些 url 跳转，点进去呢还 404 。

这业余程度，我直呼外行。

做微信小程序、开放平台开发形如吃屎，老传统了，你忍一下。

腾讯其实不能视作一个大公司，应该视作不同的小公司的集合。
从这个角度来看，应该很多东西就能说得通了

对接过法大大的 api ，竟然每个接口的签名是单独搞的(比如某一接口明确要求不要某个字段参与验签)

返回 code 有的是 int 有的是 string

请求的 url 有的是驼峰有的是蛇形还有的混用

签名没啥问题，虽然繁琐了一点，但一般是网关要求，锅不在业务身上
至于文档内容的烂，确实是超出了意料，腾讯是完全不打算做 2B 业务是么

我看目前没有 op 说的这些文档错误了，改的挺快的。以后上线了 sdk ，统一了 api 接口版本应该会好一点的吧。

工作需要对接企业微信和微信公众号，整个业务流程真是灾难级的难理解。

appid+appsecret+时间戳 加密后再编码倒是挺常见的了，不过 demo 和文档写成这样就是有点恶心人了

看过微信文档的都知道垃圾腾讯

@bookbox 刚看了下，确实是改了，上午还是错误的

我发送复杂点的提示词，直接返回签名错误（ 2001 ），当替换成“你是谁？”、“你能做什么？”的提示词后，可以正常返回。。

用的是 PHP 语言，拼接 message 字符串时，使用 json_encode('xx', JSON_UNESCAPED_UNICODE)，不清楚是哪里的问题、、

复杂提示（包含了换行符）：
```
The following production process records are summarized by extracting the goodsSpec, count, pici, receive, workName, and toWorkName from the text and outputting a JSON object containing an array of these entities using the following format:

---
example:

Input:
目检转入壳灌胶\nabc 6 只 2308 周 @张三 @李四

Output:
[
{
"product": "abc",
"count": "6",
"pici": "2308",
"receiver": "张三,李四",
"wn": "目检",
"toWN": "入壳灌胶",
"remark": ""
}
]

---
Input:
测试合格
abcd 2 只 2320 周
@王麻子

The Output is:
```

你猜对接微信支付/小程序/公众号的开发者骂了腾讯多少年

让我想起来了 16 年刚接公众号和小程序的时候的往事，妈的安卓和 ios 版本 sdk 的 key 的大小写不一样你能信？我 debug 这个 bug 人都搞懵了，

挺好的啊，这是腾讯稳定发挥的水平，说明腾讯经历裁员风波并没有降低他们的相应的开发水平，应该给予鼓励和支持。

@s609926202 #47 替换了一下 message 字符串拼接方式正常了：

```
$str = '';
foreach ($val as $v) {
$str .= sprintf("{\"role\":\"%s\",\"content\":\"%s\"},", $v['role'], $v['content']);
}

$val = sprintf("[%s]", trim($str, ','));
```

之前看星火的 api 是 ws ，然后就放弃了。感觉没必要

这不就是腾讯这种烂厂的水平么。。。

说明还是人肉 Ctrl+C/V ，还没用 AI 来 Ctrl+C/V

腾讯和阿里的文档都不咋地.对接他们的服务和 SDK 很痛苦.难以相像这几个大厂的水平

1. 国内一互大的工程质量基本上就是门前两坨物品，一坨是屎，另一坨也是屎
2. HMAC 签名还是挺简单也挺实用的，不过我遇见太多只有别人手把手写好调用代码才会用的人

3. 看来厂家真的有人在技术社区潜水

腾讯 toB 或者 toD (developer) 的东西给我的感觉就是让二流外包公司做的 ...

@murmur 这个真的把我整笑了，一次次往后退，搞不定了，干脆自己整个系统弹框，苦了一大批拼命改的开发

试过讯飞的星火。。签名生成也好麻烦，给的 demo 都跑不了

这不应该是 TX 的正常表现吗，没必要大惊小怪的。千万别指望 TX 能做出惊为天人、引领行业的产品。

@mylxsw #46 有内鬼

腾讯的文档是出了名的垃圾，不过只要提出来修改的速度还是可以的，之前有提交过支付文档上的错误，下次看的时候就已经改正了

腾讯正常水平+1

我用他家位置服务 API 遇到 Bug 提了俩工单

一个告诉我该问题已在其他工单被处理就直接关了，你特么倒是给我解决方式啊？？？

一个明明在官方 Demo 里改几行代码就能复现，结果回了个我个人使用方式有问题就给关了

腾讯：每天有一亿人教我怎么写文档。O(∩_∩)O~

腾讯 的 精英 都在游戏部门

这个不是正常发挥吗？你看微信的接口就知道了，没有最烂，只有更烂。

嗯，这让我想起倒下的两个巨头：诺基亚和摩托罗拉，他们的代码比腾讯还烂 100 倍。

估计你第三方接口对接的少，哪有不需要签名的

之前写过自己公司的对外文档。怎么说呢，这个东西吃力不讨好，要写好非常耗时间（什么 api 规范化只能解决一部分问题），而且没收益。当然你会说写的好开发者接入的多，但说句实话你这开发者毫无价值。高价值的客户都是单独对接的，接口文档看不懂有问题都是 1 对 1 解决，而且别人还会夸你服务好，绩效就好。

巧了，你说的这几个里面，腾讯的 ai 水平确实就是倒数的

@okfun54573 好吧还以为吐槽模型垃圾呢

这个不算麻烦，当年对接微信支付的时候简直想一刀捅死张小龙

是这样的，毕竟小作坊

甲级战犯

你们都说腾讯烂, 那腾讯加班那么严重, 程序员们都在忙啥

签名没毛病，大多数都这样
写那么复杂就是因为写简单了有问题的人更多
毕竟很多人分不清字符串和对象的区别，有的甚至连 content-type 、url 编码是啥都不知道

看过小程序文档的都知道.

别人随便写写，你认真用了。请问你说是谁的问题

腾讯的开发者文档是我见过最差的（国内大厂之间）没有之一，就像我这个半吊子写的一样

小程序文档还接口还有拼音呢

你去看看 PAI 的签名方案，不是一样的嘛

昨天刚接，签名这的确是槽点比较多，首先这签名里参数是数组的格式化要求就比较奇怪，然后各语言示例又只给无关紧要的加密的例子，加密这种都是比较常见通用的了，最特别的奇怪的你不给，还得让开发者自已想办法仔细读仔细搞。

听起来有些离谱
但在腾讯
倒也正常

小程序的文档也是这样的

怕是没对接过微信支付 hhhh

我对接过微信系列的文档，也是文档做的最好的一个了，找啥都方便，比阿里的好很多，腾讯的就不太了解了。

另外签名设计 应该没啥大没问题，签名是防止消息篡改，这个是基本的安全设计，其实还少了一个客户端时间戳，会有重放攻击的可能。

但凡对接过微信支付、公众号开发、微信小程序开发中的一个的，都已经见怪不怪了
不要以为大厂的人代码就写得好，他们可能只是八股文背得熟

看过 移动云 eos 的文档吗？那是我见过最烂的了，按照官网的案例都走不下去，只能找客服

接过微信支付，很恶心，文档散乱，散乱也就算了，跳转链接都没有，只能出问题的时候去论坛查问答

当时接微信支付 gosdk, sdk 实体 和 实际返回不一致，报错找了半天真是要死了