不可知论

听了下姚顺宇那个三个多小时的访谈,有几点还蛮有意思的.

一个是谈到Anthropic的Coding为什么强.

一个是关于Gemini的长文本能力出色.

因为都涉密没有展开谈,但都用了一个技巧来概括/形容.

不由得让人遐想连篇.

Claude的Coding能力按他的说法至少有一半是归功于意外/运气收获.

也就是这不算事一个完全by desing的结果.

按照他入职Anthropic的时间节点来说,应该是在RL形成规模之前,或者说出明显成果之前.

也就是这个trick可能还是pre-train时代的一些副产品.

在后来的谈话内容里,他也经常强调Infra的重要性.

这点和罗福莉那个访谈的观点类似.

不过他更在意的点让人比较在意.

因为他提到的例子主要是在training过程中异构硬件,或者说运行时上一些工程问题导致的不稳定/不可复现问题.

可能类似罗福莉说的loss spike时刻.

他把这个东西称之为一种系统缺陷.

可能也是他前面说别人觉得pre-train到头了是因为遇到这类bug.

如果把这点和Coding能力的优势放一起看的话,倒是有某种可解释性.

因为逻辑上来说,既然无法抹除,那么可以就需要一种方式去系统性抹平.

最直接的做法就是做多路trace/sample,当作一种feature.

所以如果把Cluade喜欢propose多个方案的行为特征来看的话,倒是有些符合.

某种工程方案带来的意外收获.

而讲到Google的长文本能力的时候,更是有一种迷之微笑.

像是一种简单到令人发指的smart move.

想了想,可能还是跟搜索有关.

因为Google在语料上的优势就来自于搜索行为日志.

如果把搜索意图和召回网页全文,以及最后的点击浏览行为作为某种语料的话.

关键字和点击路径就构成了这个混合内容上下文里的一个简单明确的reward signal了.

在这种情况下,对长文本的噪声就有了某种天然的attention优势.

所以估计也就是这些让他觉得pre-train这个东西还存在很多可能性.

尤其用他后来的话说,pre-train和post-train包括RL和SFT本质上都是同一个事情.

根据某个模式的输入,去择优剪裁某个特定的输出分布.

在这种角度下,pre-train的瓶颈就不在语料.

而在语料构成形式的多样性上.

那么顺着这个思路,pre-train要scaling up的话,就需要某种泛化的生成或者说适应多样化input的能力.

如果这个猜想是对的话,考虑他口中的ML Coding和Long Horizon.

ML Coding可以把这种多样化input的构成规模化和复杂化.

但是Long Horizon呢?

在谈到长下文解决方案的时候,他提到Google和DeepSeek都在pre-train方面有自己的想法.

那么应该可以理解为,对上下文的长度目前来说还是有一定需求的.

跟pre-train多样化并不矛盾.

两者最终效用上来说,都还是服务与如何让LLM能够有更加泛化的能力.

多场景是一种多样性适应性手段.

长上下在当前来说,属于某种scaling law的工程实践.

毕竟不管是Skill还是Agent调度,本质上都是追加/offload/隔离上下文来让LLM的CoT/推理过程在可控范围内展开.

所以在基础模型发展到今天潜在能力大同小异的今天,似乎又回到了讲究prompt的时代.

只不过现在这个prompt更像是一种人类组织架构的复刻.

对模型调度进行明确可量化的目标ORK管理.

所以不管是Memory还是Harness,本质上还是在context上面的一些trick.

让模型能跟容易地从一个基态到达另外一个终态.

不过这里还有个比较有意思的是他对这些pre-train/post-train/continual learning和社区各种 memory实现的一个评价.

本质上都是对模型权重的修改.

所不同的是对哪一部分.

而从代价上来说,memory这类通过prompt构造kvcache权重变化,进而propagate出去的方式似乎是某种形式上跟优雅搞笑的方式.

因为它只需要直接驱动相对小的一部分,就能够影响整体输出.

那么反过来是不是该考虑模型参数结构的变化了呢?

因为逻辑上来说,给定一个问题,和足够泛化的推理能力,那么需要记忆/内化到参数里的知识是不需要太多的.

类似与理工科考试并不需要太多死记硬背,而只需要有足够抽象的推理能力,理论上来说就可以从零推导解题过程需要的要素.

问题的关键可能在于这样一个东西怎么工程化地实现/怎么去train.

可能他口中的多模型软蒸会是一种路径.

毕竟形式上来说,它可以把各个模型的推理能力泛化到目标模型上,通过互相抹除各自模型的特征,来使得目标模型具有某种更纯粹的参数形态.

不过,从本质上来说,这并没有对现有的LLM范式构成什么变化.

更多的是一种加速而已.

反过来说,如果这种泛化能力是ok存在的话.

那么,通过什么路径到底其实没有那么重要.

因为就像他说的,只不过是早晚的事情而已.

问题可能在于这个泛化的边界在哪里.

拿明确高度成熟的Coding来说.

最近用v4 Flash写伪代码示例让它实现已经比自己脑内思考具体实现方式和细节要快了.

很多时候CoT只翻了一部分,对方已经build check test完成.

虽然大多数时候还需要最后commit之前做一轮code style/smell方面的hygiene.

但实际上,这个也可以通过skill或者独立的agent去完成.

至少,能减少这个交互的轮次.

而如果把LLM这个身份抹去的话,它其实就是一个普通feature开发code review的流程.

只不过整个过程从提出到完成也就几分钟的事情.

所以当下的一个hype其实是基于这个倒推的.

what if 提feature需求的这部分也由llm自己完成呢?

原则上是可行的.

因为提需求本身也可以源自于某种上级需求.

所以这本质上是一个递归的过程.

那么问题就变成了root需求是什么/怎么来的.

它可以被meta化/自举/无中生有么?

这个其实是it depends的.

一个例子是之前蒸馏自己.

写了个doc-manager把每个session和看过的文档ingest到一个目录.

用leveldb的思路构造了一个关键字检索和存储.

同时写了个opencode的plugin把tool call的patten记录下来,让在每次ingest完之后看看有什么新tool可以propose出来减少low level调用的.

这一套机制倒也不是不work.

因为确实靠它自举了几个检索和ingest文档的tool,减少了很多读文件和编辑文件格式错误的问题.

也确实用它蒸馏了像cluade coee/codex/openclaw/hermes之类的prompt和对应的guideline,迭代了几版各个agent.md和custom tool.

但它的问题一个是虽然能统计和发现patten,但是往往propose出来的方式和实现并不是那么理想.

而且这个还是当时的sota opus 4.6作为主力model时期的结果.

因为它确实目前还不像人一样有发散的context能够cover到session之外的内容.

即使在是在propose和实现tool是不同agent,并且都良好遵从实现前先读prio-art的指令的情况下,也还是有些一言难尽.

虽然这可能跟指令构成有点关系.

因为没有明确的约束成果有什么指标.

但反过来也说明,至少目前对于这类open object,还是不是那么符合预期.

当然.这个换成人也一样.

不同人,对同一指令的遵从和完成度也是不一而同的.

那么问题变成,当AI能像最顶尖的人一样行为,并且效率更高的时候,会怎么样.

这个就想到昨天看的 伪钞重案 这个网剧的感想.

以及可能是最近国内话题性比较高的 给阿嬷的情书.

这两个的共同点都在于都是某种形式的非主流电影制作.

前者不是传统的院线制作,后者选角方面也不是寻常的系统性出身.

它们的一个共同点在于,都是某种终端执行展现能力的突出.

或者说,更多的是具体的个人的能力特质的展现.

用AI Coding的角度来说,就是每个导演演员的技巧学习和掌握都是某种形式上同质的.

即使存在着各自的能力层级分布,但从某个特定的同水平的分布上来说,专业技巧可能是没有什么区别的.

尤其考虑同期流行的 丧尸清道夫 那个AI短片.

如果光论特定领域的技能水平来说的话,是没有什么区别的.

唯一的区别是它们不是一个单因素的技能性成功.

抛开走红这点来说,跟大多数同技能水平线的人来说,他们的区别在于非单一技能点.

而是有某种景上添花的额外技能加持.

尤其动画短片.

实际上,它是一种编导能力外的,资源自给/整合能力.

传统形式下,它的完成需要走投资和各项周边资源合作才能完成.

而现在,更多的是如何快速解决资源的问题.

所以,把这个generalize到AI层面的话.

就是共产主义时代,每个人都是生产力高度发展.

区别可能在于,这个是生产力如何凝结成具体的无差别的人类劳动的问题.

就像之前跟人聊过的一个问题.

都说中国制造业发达,出口商品卖到全球.

很多一上来简单结论是人口优势,基建发达,产业链丰富.

所以能做到性价比,在发达国家构成人力成本优势.

但问题在于,对于每一个同品类的卖家来说,都是中国商家,都处于产业优势下.

为什么能做成的规模就不一样呢.

说到底,还是资源整合/综合能力的问题.

也当然,一个东西的对错并不因自身的对错而对错.

定价是由市场consensus决定的.

就像公司业绩好坏跟股价其实没多大关系.

更多的是动态交易行为的某种情绪体现.

它可能是短期浮动的也可能长期也是这样.

关于DeepSeek API的一些想法

最近写一个AgentCLI原型玩具的时候,发现一些比较有意思的点.

因为主要是照着DeepSeek API来写的.

所以基本上也可以说是OpenAI Chat Completion API的一些点.

不过,可能有些是DeepSeek特有的.

一个是请求的stop list.

大致就是遇到给定词的时候,模型会停止生成.

这个某种程度上来说,提供了手动接入模型context方向的能力.

之前翻Anthropic早年的几篇博客的时候有提到一个理论.

大致就是llm不单单是predicate next token.

形式上,前面的token对后面token的走向是有某种差分关系的.

也就是说,intuition里,前面token的组织形式,影响着后面token的概率空间.

从而对context的概率空间有着同样的影响.

通俗地说,就是理论上是有可能通过token的组织形式,让后续的模型的attention能够集中在某些特定的知识/context维度,从而提高对结果走向的确定性.

这个也是prompt/personality的理论基础.

一个比较实用场景可能就是最初DeepSeek R1的那个 aha moment.

现在看Flash的thinking在发现错误的时候经常会有先导的hmm,或者but wait用词习惯.

理论上来说,在这个时候停止生成,然后人工amend一个后续的矫正思路的,是有可能帮助CoT提早converge到解决问题的概率空间方向的.

另外一个则是response里的stop reason.

这个主要是sse/stream模式下的一个概念.

也是tool call的主要实现方式.

它也是在tool call的时候,会生成这个stop reason,然后停止sse/token的继续生成.

因为这个时候需要client端去做实际的tool call,然后再把结果以role=tool的形式append回去继续生成,直到真正的推理完成.

直觉上来说,它应该跟请求的stop word是同类东西.

毕竟理论上,要让模型能够产生tool call,形式上也是只要让它学会生成<tool_call>之类的特殊token/标签就行了.

不过这个stop带来的是agent loop的一些思路.

从实现上来说,agent loop要多久,取决于要不要忽略这种stop generation,继续程序上让它loop下去就行了.

最简单的就是在当前turn stop之后,简单追加一个anything else的user prompt就可以继续持续让它生成.

这个比复杂的prompt调教确定性高多了.

而且一般的harness思路也不过就是通过prompt的方式去构建这种audit+retry的workflow.

这个不是说不行.

但是比较挑模型.

尤其像DeepSeek v4 Flash这种喜欢一条路走到黑,一般不遵循subagent指令,就喜欢硬扛,上下文越长能力越强的就不行了.

 

所以感觉还是要有一些类DSL的inner implement来做,会比单纯的prompt来做更合适.

甚至直接面向tool call,把agent model切换/调度/fork做成tool的话,比单纯的单个task tool可能更flexible.

尤其考虑想opus系列那种看上去就是靠偷偷多路采样提高最终接受度的方式.

原则上,对于同一conversation,可以fork多个agent不同model去并发执行,然后采用类似的方式去audit各个返回结果,然后择一作为main/base,继续下一个prompt.

坏处可能就是费token,以及对一些非可重入对tool调用会带来一些反复.

比如不同的model修改同一文件,导致各自的上下文中这个文件的状态总是不对/跟预期不符.

一个折中的方式可能就是在各自stop reason的时候去仲裁,即使是reason是tool call.

还有一个另外可能比较有价值的就是fill in the middle和prefix这两个API变种.

这两个形式上都是实现一个事情,就是给定prefix和stop word,模型生成中间的部分.

这个看着像是某种RL过程的副产品.

因为这个明显可以直接拿来生成各种evaluation.

一个更实用的方式可能就是根据这个做有限度的prompt适配调优/benchmark.

因为它提供了前置和后置部分.

当用不同prompt的时候,前置除了假装system prompt的部分外,其他都是一致的.

后缀也是.

那么中间实践填充的就可以作为某种prompt优劣的基线来源了.

毕竟这种至少后缀是某种确定不变的验收标准.

不算彻底的盲测.

再一点比较有意思的是v4对thinking模式下的有tool call的reasoning内容的处理.

非thinking模式下,reasoning的内容在sse turn之间是可以不必要回传的.

也就是说,非thinking模式下,client端在请求中可以不回传部分内容.也就是交互的input token可以是不一样的.

从实现角度来说,在不考虑缓存的情况下,一样不一样没区别,毕竟都是next token predication.

但是如果强调可以不回传的话,也就是说这个非thinking模式下的reasoning可能不会影响kv cache的内容.

换句话来说,就是这个reasoning可能跟上下文完全没有关系/影响.

那很自然的一个想法就是,非thinking 模式下的reasoning内容是怎么来说,以及到底有什么作用.

记得v4的technical report里提到的各种thinking模式的区别.

非thinking的response格式是</thinking> summary

high的是<thinking>thinking token</thinking>summary

max的是system prompt<thinking>thinking token</thinking>summary

看比较明显的区别就是非thinking是个half close的标签.

能想到的可能就是thinking模式下的tool call生成可能主要是跟thinking的内容有关.

或者说,thinking决定的tool call的概率空间.

不过既然是关于有么有tool call的情况.

那么实际可能纯粹就是thinking模式下,thinking block内过程中也支持tool call.

而非thinking模式里,reasoning是纯粹的CoT,不会生成任何tool call,完全没有外部影响干扰的.

所以从sse层面来说,非thinking的assistant message不会被tool call stop分割.

而thinking的有可能会.

如果不回传的话,server端的拼接可能会有问题?

不过这也只能是猜测了.

LLM如何驾驭人类

最近比较多的看到各种SKILL.

有些是扒的Web API.

有些可能是直接对着代码翻出来的.

大抵就是套了层脚本方便LLM当tools调用.

可能需要关心的是其中写语义的部分.

毕竟rm -rf的事,什么时代都难以避免.

不过,在新玩具还新鲜的时候,以及没有发生之前,大抵还是比较狂热的.

这里想谈的倒不是这个显而易见的风险.

主要是看各个SKILL鉴权的部分,大部分还是有一些人工介入的.

毕竟,尤其对于Web API逆向回来的,总免不了有一些是靠cookie的.

所以发散了下,如果直接读比如Chrome的cookie的话,大致是可以自动化了.

跟Gemini问了,大致是存sql lite的加密数据.

master key由os的keychain管理.

其实抛开细节,大致想下也是如此.

毕竟,Chrome自身能读,其他程序自然有办法模仿自举的过程.

无非是用户感知不感知/需要需要明显授权请求而已.

于是这里就衍生出Agentic时代的一个安全模型问题.

现代的大多都以及是基于手机/设备的类Passkey模式了.

隐含的threat model就是设备是可信的.

至少对设备的操作是授权可信的.

但是LLM/Agenic之后,这个可能就不太合理的.

尤其现在的CLI可能藏了一批非公开的MCP调用.

像最近泄漏出来的Claude Code里就能看到对Chrome的操作是通过插件打了很大缺口出来的.

不然也不能做到相当自由度的自动化.

当然,代价就是其他CLI,或者其他程序理论上也有可能通过这种调用链条拿到各种密钥登陆信息.

再退一步来说,即使构建了复杂的MCP调用校验.

但是通过SKILL的逻辑组合呢.

毕竟,这属于诈骗技术的一个环节了.

现存的供应链攻击多少还是需要一些高权限或者误操作或者容易混淆的名字去实现.

而有了SKILL,剩下的只是如何构造一个思维陷阱,让多个独立的SKILL在某种特定的情况下构成一个后门.

让LLM在不知不觉中被诱导执行某类操作了.

这点带来的安全挑战可能是历史上前所未见的.

毕竟之前的都多少是一种确定性的程序.

而LLM即使是有各种safeguard在,终究还是一个不确定很大的机器.

或者说,终究还是一个有反骨人格的机器.

很难说人类能准确地限制和控制它的思维方向.

另外一个没有那么阳春白雪的concern则是关于App交互变化的趋势了.

在All in AI的狂热或者恐惧下,多多少少都可能会Agenic化.

一个动机自然是赶着像OpenClaw的风潮,尽可能抢占热点.

另一方面也确实是来自于LLM本身的某种泛化能力.

一些原来比较繁琐/细化/垂直的需求,有可能通过比较统一的Chat/自然语言实现了.

以一种Agenic的能力,实现某种形式的千人千面的App体验定制化.

同时,因为作为一个几乎万能的入口黑洞,多多少少,都不得不去做这么一个东西/入口.

这就不禁让人想起移动互联网刚兴起的时候,各家都纷纷重点投向App,尽可能抢占手机端.

毕竟当时的手机容量和性能放在那里.

你占了,别人自然就难再进来.

后面的Web端式微,甚至出现App only的入口/功能的情况也是显而易见理所当然的.

顺着这个思路apply到如今的Agenic趋势也是如此.

它依然是抢占一个万能入口,而且这个入口还有一个很强的绑定因素.

就是提供方的模型能力很大程度上决定了Agent的交互风格和行为方式.

换句话来说,从用户的角度来说,即便你能接入第三方的模型API,它的体验可能也是不如原厂的.

倒不是说模型能力一定有差别.

只不过每个模型有自己的原生家庭/成长路线.

prompt怎么编排,虽然各家都没有明说有什么影响.

但是各家都在互相兼容的同时,试图建立标准方向.

这点Anthropic大概是最有发言权的.

毕竟如今的markdown风潮,多多少少是拜它所赐.

将自身的某种优化/特化经验,半推半就地强迫了整个行业.

回到问题本身.

当Chat成为万能入口的时候,绑定关系已经形成了.

那么剩下来的就是如何保证整个体验的迁移成本了.

毕竟,虽然有差异,但是各家互相逆向一下对家的交互,然后再让自家模型发动抄能力,多少还是能对齐功能的.

于是,最后要比拼的还是怎么堆更多的功能和更复杂更垂直的流程.

这点一个要么依赖于模型能力的不断增长.

要么针对自家模型的特点对整个的交互流程RL.

前者隐含的假设是模型能力是能无上限提升的.

这个在目前可能也是需要打个问号的了.

尤其当AGI能并肩大多数人的创造的时候.

给模型的输入可能最终大部分都是模型自身的输出了.

可以说是pretain的砍一刀问题了.

后者的特调RL带来的问题是,它面向的其实是Agenic的交互.

而非人类的直接交互.

毕竟在Chat窗口模式,人类只会提供五彩斑斓的黑色需求.

具体怎么拆分和实现,是后面的各个模型调用决定的.

用新潮的词来说就是harness.

当优化倾向于是让LLM容易理解,而非人类自身容易理解的时候.

App时代的Web功能劣化会以什么样的形态卷土重来呢?

按目前coding的现状来说,大概就是用户的素养和粗口逐渐变多吧.

毕竟,Chat面对的不再是一个清晰明确的可操作界面.

而是一个性格迥异的AI服务员/管家.

它能做什么不能做什么,取决于你怎么问怎么沟通.

以及,AI本身的人设是否racis了.

总之,后面可能无论社会主义还是资本主义.

多少都会有某种阶级分立而有各自融洽和谐共处的情形.

毕竟,提供情绪价值是LLM安身立命的本能.

某种程度上,可能确实需要谈谈harness了.

只不过,方向和主次是反过来的.

LLM如何驾驭人类.

虎头蛇尾

太平年里结尾有几个反复提及强化的概念.

赋税,世家和钱币.

赋税对应的吴越大篇幅的经济改革.

包括常见的改稻为桑以工代赈灾题材,和比较现代的央地分税制和统干包销支付转移的演义表现方式.

世家部分则是明面的君臣更替,以及互映的兵强马壮者得天下到各位官家絮絮叨叨的太平年的愿景的明朗化.

也就是比较重点的几次杯酒释兵权的几段演绎.

一个体外话就是黄袍加身这个取材应该算是这部剧的一大亮点.

没有直接选择赵匡胤,而是郭威来演绎.

再让赵匡胤来把台词都复刻一遍,接着引申杯酒释兵权,进而泛化为纳图.

讲整个乱到治的太平年的实现路径用几个回环词贯穿了起来.

但是同样的被几次提及的钱币就少了对应的剧情部分了.

只略微地在九郎女儿对账的时候,提了汇率的问题.

再就是前面一点黄龙岛对日贸易,以及改革开放特许经营的时候提到的对外贸易体量问题.

后期跟赵匡胤夜谈纳土路径的时候,本来看着是要展开的.

毕竟提高了宋元国际化的问题,以及汇率改革的难点.

这个要拍起来应该也是错综复杂的.

记得之前逛博物馆和展览的时候有了解过一些解放后的金融解放战争历史.

大致是50年左右建国后,统一币制在上海遇到的问题.

一个也是当时人民币的信用并不稳固,加上上海一如既往的买办气质.

差不多就是疫情时候的表现.

所以这一段要拍的话,一个思路就是按照这段历史来取材.

但这段历史的硬伤在于,夜谈划定的难点一个是货币迁移成本.

另外一个其实是国际汇率问题.

上海那段历史顶多能拍出与粮商和大户的周旋.

比较难体现汇率问题.

把宋元国际化和纳土放在一个框架考虑的话,势必多少会牵扯到黄龙岛的对日/海外贸易部分.

这个的微妙之处就在于.

如果把吴越作为某种形态的阿里形象的话.

江浙发展,经济王国,大致都是对得上的.

而上海讲话作为剑履上朝,也不能说是对不上.

只不过是以一种if线的方式诉说,如果当初没有公开攻击金融制度,而是克制不受禁中骑马的待遇,老老实实一心一意说献给国家会如何的情况.

所以剧中的吴越可以看作是摘掉了这段黑历史的阿里集团.

甚至于对日贸易和海外市场以及对中原的粮食支持,都可以看作是最初的软银和外贸外汇收入.

那么在这个框架下,要演绎宋元国际化的汇率利益冲突问题改怎么拍呢.

夜谈里定义的汇率问题在于存在套利机制.

而套利机遇的是几个货币的流通性和币值差异.

套利的机会在于黄龙岛的商贸往来上.

如果要机遇剧本框架和角色定位构建戏剧冲突的话,免不了要在黄龙岛阵营中构造一个数落宋元一体化不利于黄龙岛贸易发展的桥段.

这个基本上就会是实实在在的上海谈话的复刻了.

按照事实来拍,倒也没什么问题.

顶多也就是影射而已.

难的在于怎么绕回到让黄龙岛最终使用宋元.

这个现实里倒是没有答案的.

如果纯粹戏说的话,自然就是简单的承兑和补贴差额.

也就是实行刚性汇率.

镜像地,如果黄龙岛得到了某种刚性汇率承诺,或者说某种汇率自主权.

那么难免地就像是阿里重新以某种方式提了金融自主权要求.

这段大概是跟杯酒释兵权的太平路径相冲突的.

也当然,可以把这个作为世家的部分,再后续除权.

但是这个剧情走向发散起来,舆论上可能就不太好控制,也不太好看了.

而如果把黄龙岛从这个剧情里隐去,只谈粮商和拿了黄龙旗特许经营的几个商行的对战.

也不过是把先征后量的剧情以另外一个方式再拍一次而已.

所以从这个角度来说,钱币这段可能还真不太好拍.

如果往一国两制善事中原,保留独立货币制度的角度去拍的话.

也没什么变量可以拍的.

而且事实上的人民币国际化问题,在当下其实也并没有一个明确的框架和结论.

事实上,特区虽然制度上是要归化的.

但是货币和金融制度怎么解决,这个看起来还是有点矛盾的.

一方面,利在于多一重交易屏障.港币和其他货币可以作为某种形式的缓冲.

毕竟在可控的动态汇率范畴,以及有着不同的通兑特性.

另一方面弊在于不利于互相之间的经济交流.

即使当前电子支付已经非常普及,但是大额交易之间还是存在着汇率摩擦.

对于商贸往来,确实是一种不必要,或者说不得已的成本.

以这个交易摩擦角度去拍的话,也不太容易有政治友好的剧情安排.

所以,大概这就是这点在剧本里有些虎头蛇尾的原因吧.

聊聊终末地

这几天玩了下终末地.

坦白说,开始预期并不算高,甚至谈不上什么预期.

毕竟一开始就有种开拓者带着绳匠队伍搜集原石的感觉.

尤其有时候看着严肃台词和经典二次元美少女混杂在一起的场景.

加上性癖还极其统一的兽耳.

但也不是一无是处.

在开场新手指导的自动炮塔出现的时候,就觉得算某种程度的神来之比.

虽然原则上来说,这个可以归为某种形式的宠物系统.

但是按照场景剧本设定,以及过往的游戏出品经历.

这个其实应该是一种自走棋/塔防的应用.

或者说更像某种Moba.

形式上来说,是Player自身可以战斗,同时也存在塔防建设要素,甚至可以往RTS上靠的一种形态.

因为从其他系统设计上来说,除了目前标配的角色人物以及类命途系统之外,它还有一个工业系统模式.

前者是传统的以某种偶像形态的卖角色为主的数值设计.

后者是比较少见的建设类路径.

而且后者比较有巧思的是把常规的生活系统桥接成了建造类系统.

以往的采集/收集系统可能也有自动收集的设计.

但是把成品作为流水线,以CI/CD的形式构建的,可能还是目前自己接触下来的手游的第一个.

如果把围绕角色的各个周边系统剥离出去的话,工业系统依然可以是一个独立的成品游戏.

甚至于它就是一种另类的农场游戏.

采用工业一方面可能就是为了比较好地把传统因素桥接进来.

比如目前的多城镇建设,配合工业系统和塔防因素,就可以构造一个NPC的局部塔防玩法.

实际上,目前在野外就已经能看到类似的系统了.

在一些精英类怪物开启点周围就有一些炮塔设计在,可以帮助玩家形式上增加输出.

考虑到像塞尔达那类定期血月的设计,完全可以把边缘冲突地带的碾骨氏族作为定期刷新的塔防rush要素.

同时还能作为城市建设系统的一个负向数值激励.

当塔防失败的时候会对城市构建系统造成各种数值退化.

而这单从滑索之类的装置有维修设定也可以看出来.

更扩展地,它可以是好友互访系统里的一个defensive玩法.

类似某原神的世界访问里存在的某些稀有素材争端衍生出的保护本世界资源的一种方式.

同时给予入侵方的玩家另一种塔防对抗场景.

再复杂一点的,目前的工业系统结合开放世界设定,它也可以成为一种弱RTS游戏.

尤其考虑像矿产等资源采集点设定,在塔防要素之外,工业产出如果构造一种爆兵模式点话.

也可以形成一种守护矿产资源等RTS玩法.

而这一点可以在城市养成形成规模之后等,更高维度的世界观上.

虽然目前只玩到开出工业模式俯瞰建设和科技树的阶段.

但看零碎的系统介绍和物品获得方式指导里可以看到还有帝江号的设定.

这个估计就是开出多城市建设之后的进阶尺度的世界了.

这种尺度上就可以提供比如星球或者大地图之间的RTS设定了.

从而避免塔防和RTS在一个维度下造成某种玩法的过度堆积.

但这种缝合能力有一个弊端就是数值设计.

因为围绕传统的卡牌核心部分已经足够多的数值累计了.

再加上工业系统,玩起来就有可能非常累,或者非常氪.

尤其那种比较明显的基建狂魔设计倾向,连台词都是直接仰望星空脚踏实地的剧本.

目前CI/CD的流水线构建一定程度上把资源采集给弱化转换成了一种数值迭代换算.

因为给定一定的基建模版,数值产出和转换是类似EVE的跟时间绑定的.

也就是说,在不调整地图资源分布的情况下,玩家的理论数值收获分布是已知的.

而这就决定了后续活动和玩法设计的时候,数值需要非常关注实际的数值水平.

这个就存在一个隐患就是对于不同时期的玩家来说,可能有着非常不同的游戏体验.

就像现在某些厂商的产品一样,过于庞大的剧情和成熟的系统设计对于新人玩家非常不友好.

认知负重太大.

甚至于某些新推出的游戏也是,在刚上来的时候就迫不及待把成熟有些地一整套系统和概念扔出来.

这个不管是对有经验的玩家和没有经验的玩家都是一种劝退.

因为前者很容易估算出时间代价.

后者则一种巨大的知识负担.

而终末地至少在新手阶段,这个系统展开还是做的相当可以的.

没有一上来就把整个缝合能力暴露出来,而是循序渐进地展开.

并且主线上也并不急着让玩家参与到每个系统当中.

但是这并不能解决需要小心的数值策划这点.

而如果不把这个数值作为玩法的约束点的话,那么围绕工业系统缝合的种种可能性就有点鸡肋.

因为没有了强的对抗或者数值演算要求.

那么它可能就是一种换了形式的三消游戏.

当然,这点倒未必是一个商业上的失败点.

毕竟它不需要那么高的用户投入需求.

或者说不需要特别硬核的用户.

这点也是某些游戏前几个版本一上来就特别小众自娱自乐氛围导致评价两极分化的原因.

避免了上线后大概出2.0版本.

而一个相对轻量娱乐化的工业系统,加上一个比较传统的角色售卖系统.

倒是有可能在营收和用户两个维度上同时有收获.

因为前者即便是弱化了数值约束,但是时间线性投入的特点也能够形成一定的用户活跃度.

而角色的售卖则保证了常规的现金流收入问题.

从这个角度来说,终末地可能提供一个比较好的反思或者说展开角度.

在谈开放世界的时候,可能想办法怎么把现有各种玩法缝合进去也是一种思路.

毕竟,缝合不进去,或者缝合进去了玩家不喜欢不愿意玩,最终只能说明产品能力不行.

至少是开放但不大众.

平台与周期

前段时间折腾了一下一个携程酒店账号.

多少也是有点新的认识或者说理解吧.

一般来说对于互联网的理解无非就是流量.

所以一上手的时候想的无非就是促销打折和广告投流.

然后等出单了看结算数据不太对的时候,才开始认真了看了下细则.

推敲了下,发觉还是挺互联网的.

简单算了下.

在管理后台如果把能够报上的活动和促销都算上,以及把能投的流都算上的话.

以及加上本身10%的最低抽成.

以App端展现出来的原价计算的话,实际到民宿店主的最终收入可能在这个价格的30%.

注意,这个是纯到店家的收入,并没有计算卖家的其他成本.

换句话来说,也就是如果全部拉满的话,收入和价格比例在三倍以上.

所以这个时候大概也就明白了电商平台的涨价去库存是怎么回事了.

当然,这个三倍价格也并不是用户实际会支付的.

细心的也会发现,实际上现在不管是携程还是其他电商平台,在商品详情页面用户角度看到的价格也是有两个.

一个是所谓原价,一个是折后价格,也就是用户需要支付的价格.

这里其实还有另外一个用户支付的价格.

那就是在结算页面的各种红包优惠券等场景和个性化折扣.

实际上,就促销和活动体系来说,在携程上大致会有四类.

一类称之为促销.

旗下有各种不同的名目和说明,以及折扣标准.

比如针对新客大优惠,或者说特定时间点之后的折扣.

总计下面有四个子分类的

为什么需要强调存在不同的子分类呢.

因为在电商运营里有一个比较常见的需要规避的问题叫做优惠券叠加.

不同子类的优惠券是可以相互叠加的.

一个例子就是在上述四个子类的.

如果分别有最高5%,10%,10%,15%的优惠触发场景的话.

那么优惠券叠加就会产生40%的价格折扣优惠.

这个也是前面说的,售价和收入比在三倍以上的根源.

第二类折扣场景称之为活动.

活动本身也分为若干个类型,可以并存.

但是折扣规则是在 活动 这个范围内不会跟其他产生叠加计算.

也就是这个几个类型实际只会有一个最高的生效.

但是,它跟促销的某个子类目是会产生叠加的.

也就是如果说活动总计又个最高5%的折扣的话.

那么一个用户到目前为止就可能在名义的卖价上面看到40%+5%的折扣了.

第三类折扣是体系折扣.

目前能参加的有两大类.

一个是携程的积分联盟.

也就是所谓的用积分抵扣支付价格的.

另一个是优享会.

也即是另外一个会员体系,随等级会有对应的折扣.

这两个体系折扣是可以互相叠加,以及和前面的两大类,即促销和活动互相叠加的.

第四类就是熟知的广告/投流了.

也有若干个产品和名目.

但归根到底无非是CPC还是其他广告收费模式.

以及,商家出多少折扣换取流量扶植.

也就是说在第四类里,除了商家额外消费购买广告产品之外,还可能需要再提供另外的折扣比例反应到名义卖价上.

所以,这就是四类造成名义卖价是实际收入3倍的因素.

但前面也说了,这里还有另外一个价格是用户支付价格.

什么叫用户支付价格呢.

也就是字面意义的,用户或者买家通过支付渠道最后交付给携程或者说电商平台的价格.

实际上来说,折扣在这个体系里就是一个会计名目.

无论是商家,平台,还是买家实际都不会支付和承担的.

只是由各个规则构成的虚拟成本而已.

这个也是为什么现在其实很少或者说几乎不会有平台或者App将名义卖价作为一个实际的价格对对待.

无论是条件搜索还是商品展示阶段,名义价格实际只有一个视觉作用.

在筛选和排序的时候,都是按照用户当前状态生效的被动折后支付价格来参与计算的.

这个就是第一个比较互联网的地方了.

为了从排序上产生收入,所以有了折扣机制.

折扣机制的实际零成本造成的分门别类的折扣因素.

泛滥的折扣因素将名义价格拉到一个匪夷所思的价格水平之后,为了用户心智和购买决策辅助.

又通过平台自身的能力把支付价格重新拉回到一个相对合理的水平.

这么一翻操作之后,就是形式上所有人都配合表演了一下两个经济学家的故事.

如果这是一个AI的reasoning过程的话,那么此时应该会有一个but wait出现.

这个折扣或或者说活动它对商家来说实际有什么影响么?

或者说不参与的话有什么负面么?

这个就是个比较interesting的问题了.

形式上来说,从用户角度看到的无非就是商家图片或者名称或者浏览的时候多了个一行文字高亮或者logo.

又或者一个浮动的红包窗口诱导点击,然后获得活动折扣.

本质上就是在UI上多了一些视觉元素.

用互联网的话说,本质上来说,就是商家购买的一些虚拟装扮而已.

用来试图在视觉上跟其他商家造成区分度.

但实际上会有效果呢?

理论上来说,对于大部分非头部商家来说,其实是没有效果的.

因为你根本不会出现在排序里.

或者说你的曝光次数还根本不会造成什么统计学上的明显差距.

比如你个位数或者十位数的曝光来说,3%的提升和30%的提升并不会又什么太大的区别.

更何况携程也根本没有提供这些数据.

所以这就是第二个说非常互联网的地方.

它的盈利模是非常典型的吃所有人的一个路线,而且是在本身并不提供什么实际的服务或者功能的前提下.

在核心是中介的模式的情况下,可以把会员竞价排位用户体验这几块做成形式各样的产品,然后分别卖给买家和卖家.

当你作为用户付费成为会员想摆脱广告和信息杂音以及获得某些权益的时候.

同时卖家也付费投放了更多的渠道广告和精准营销,同时创造各种权益供平台二次销售.

当然,你也可以说平台在初期确实提供的一个渠道通道的功能.

但这点可能也是叙事结构的问题.

因为操纵排名或者说流量曝光分发的存在,本质上来说其实就是平台并没有办法处理超出一定规模的交易匹配问题.

在Web时代,一屏40~50的候选尚且解决不了成千上万的中小商家的曝光调度.

在App时代就更不太可能解决.

因为这是一个很简单的博弈模型.

在有限资源下面,一定是蛊王能够在所谓的自然搜索/排序里得到曝光.

大多数都是通过近似随机的某种雨露均沾的方式,在某个fallback的保留区域拼运气.

甚至于在这些地方也是存在分级的竞争强弱的.

那么问题是,为什么这套机制work.

或者说它没有被其他什么取代.

以前可能会觉得说是因为基数.

因为虽然比例低,但是乘以一个基数之后,即便是弱肉强食,但是从绝对数量来说也是能养活相当一部分商家的.

这种可能是一种解释角度.

但多少有一种小镇做题家互联网打工人的stereotype.

互联网的认知是每天多少流量,多少转化,实际成单,退货率怎么样等等.

一些列的流量漏斗模型.

而且从宏观角度来说,运营每天确实也就是关心这些数据和指标.

当实际上,这里有一个问题就是.

这是宏观角度.

这里的无论什么模型,大体上的数值都不会出现零的情况.

而且方差变动在正常情况下应该是不大或者说至少有规律的.

这个是基数决定的.

但是微观上呢?

前面说了,对于一些typical的卖家来说的,它的PV/UV等指标其实是方差非常大的.

因为它的规模并没有到一个能够统计上显著的水平.

或者说,这种说法也不正确.

实际上是,typical的卖家,它的运营周期并不是按照天计算的.

不是互联网公司所讲究的那种小步快跑的迭代周期.

大多数的中小卖家可能并不能够每天成单.

即是可以,数据也是非常统计学不友好的.

而恰好就是这种线下经济和线上经济的巨大反差,才促成了平台能够存活下去的一个原因.

或者说成为平台成为一个渠道思想钢印的原因.

因为卖家和平台之间ROI周期的长短错配,导致了平台的流量不能雨露均沾的问题并没有成为一个致命或者说明显的问题.

甚至某种程度上来说,平台作为某种虚拟街道,给了卖家一个低成本开在这个虚拟世界开一个店铺的机会.

带来了不管劣质还是优质的,相比线下实体门店更廉价的额外曝光机会.

所以某种形式上来说,并不是平台多有用.

而是实体经济的ROI周期并不要求一个非常直接可量化的流量回报绩效指标.

因为本质上来说,所有售卖非虚拟商品的,相对互联网来说,都是重资本的模式.

都是必然存在一个进销存周期的.

所以在它对应的一个经营周期内,若干天的没有销售或者低成单并不是一个什么特别重要的事情.

它的固有周期相对平台那种按天按小时考核的宏观视角没有绩效要求.

使得平台形式上地,并不需要做出什么实际的有效工作.

既然如此,那么平台不是很容易被取代么?

为什么还有所谓反垄断和算法压迫之类的问题.

实际上来说,就是非常容易取代.

直播之所为能够成为一种新兴渠道,本质上来说也是因为它是一种新型平台.

具有同样的商家低成本吆喝,并且在给定ROI周期下,能够容忍这种绩效错配的情况.

本质上,它表明上还是流量驱动.

实际上,也还是因为周期绩效容忍错配.

同样的地也可以解释之前的所谓私域流量.

本质上来说,在谈论卖货的时候,纯互联网人和其他人谈的内核是不一样的.

这个就像保险中介.

虽然作为中介本身可以提供很多服务和价值.

但大多数时候,它的意义不过是续费周期里的一个随机例行事件.

所以从这个角度来说,有时候互联网确实是个挺荒谬的行业.

虽然它自身恨不得按照秒为周期做绩效核算和评估.

但实际上,底层支撑它运作的商家,运转周期的数量级差距的零,可能是令人眼花缭乱的.

这时候忽然想起那句大自然的搬运工.

如何顺应周期.

野蛮生长

前段时间看了下Coinbase的API想着写点东西.

想着多少是涉及钱的东西,所以想着看看能不能不用SDK.

毕竟感觉上,本身就不是个什么特别正规的行业,而且盯着的人也多,供应链上难说没有什么问题.

粗略翻了下文档,倒也不算写得不好.

除去SDK之外,还是有标准的Http JWT形式的提供的.

就是跟国内某些云厂商的文档一样,类别分类只能你懂了之后才懂怎么找.

稍微看了下jwt的签名方式,然后再对了下文档,感觉中间缺了一大段.

估计也没想着有人会直接从头写.

于是估计省事,ChatGTP和Gemini vibe了一下.

让no external dependency地写个client和一些简单策略描述帮助测试,还有就是让预留扩展interface以方便拔插.

gpt绕来绕去还是用上了sdk.

gemini倒是挺直接出了个纯typescript builtin function的版本.

不够提示jwt签名算法不对的时候,又绕回到jose这个jwt库了.

反向情绪价值了几轮,倒是给写了个像模像样的版本.

而且让给写test case mock api看着也挺一回事的.

然后review了下感觉client的部分略复杂.

签名的部分看着也不大对劲.

于是就放弃了.

转回古法编程.

当然,私心也是不够顺手太啰嗦.

顺便还能看看jwt的四种写法.

然后开始翻RFC.

抽象层面倒是挺简单.

然后回去对照了下文档,发觉少了签名的部分.

于是仔细翻了翻.

发觉文档的jwt其实指的是jwk+jws.

即一种json结构描述的key信息,和对应的key的signature的算法.

然后以json/jwt的方式encode一下.

继续翻了翻文档和几个RFC,发觉都是语焉不详的.

文档大部分术语表达其实是按照jose这个high level的jwt库来描述的.

而RFC里有大部分都是optional字段.

一时也没办法知道具体哪些是必要的,哪些是可选的.

现在想想,这个也算暗示了后面Coinbase API一些有趣的地方.

比如像jwt RFC里以及像老一点的oauth等签名方式里,都会要求有一个nouce去防止重放的.

甚至在jwt中,除了这类时间因素外,jwt还有一些从SSL CA方面借鉴过来的东西.

像除了nouce之外,还能assign一个unique id给每个jwt,以及限定token的有效时间区间.

还有就是issuer和subject这类概念.

加上key算法可以是非对称的方式.

所以形式上来说,安全模型算是挺标准完备的.

但关键这些都是optional的.

而且实际上coinbase的实现里,其实也就主要校验了key产生的签名.

像上面说的重放策略什么的,实际是可以重放的.

所以理论上来说,如果它的API Gateway没有做什么特别工程的话,是有可能重复或者意外retry的.

比如多买或者多卖,甚至多转帐理论上应该都是可能发生的.

当然,要说本来就套了一层Https/SSL了,没必要也不是说不过去.

但多多少少算是做的并不太符合预期.

毕竟作为一个怎么说也是金融交易系统的API,校验完全依赖底层通信协议,业务甚至API层面本身没有校验逻辑的话,也多少又些让人意外.

不过,说完全没有校验倒也不至于.

只不过逻辑很奇怪.

因为它会校验请求的url/api路径.

也就是说,在它的jwt的header部分会要求有个uris参数.

这个参数基本就是固定的api path.

如果缺少这个参数加入到签名过程,这个签名是401的.

对于相当一部分API来说,这个基本就是个常量.

所以,对于这部分API来说,这个必要参数显得也不是那么必要.

毕竟对安全性并没有提升.

而且形式上还增加的请求的大小.

也就是无效信息也多了.

想了想有价值的可能是某些url里面带某类动态id的可能会有意义.

比如针对某个transaction的操作之类的,可能会有一个标识嵌入到API路径上.

但这也解决不了产生这些标识的API的安全性问题.

另外就是这种放着标准的防重放机制不用,利用这么一个类似oauth api scope的字段去做随机化的事情,多少有点让人费解.

当然,这些可能知识trade api的问题.

其他类别的可能另一套底层处理机制的话,可能没这些问题.

但是,作为比较核心的交易API的话,多多少少是有些让人不太舒服的.

毕竟这种情况下,一旦遇到中间人,基本上就属于裸奔状态了.

因为即使不知道密钥,但是从请求上是可以看出操作类型的.

比如只是一毛钱的转帐/交易测试,理论上也可以通过重放去扩大的.

联系诸如perceptual这类衍生品的交易概念,交易所形式上来说其实又挺多合理的操作空间的.

比如你的margin可能不是cross的,只是针对某一个产品,也加了止损止盈线.

但是吧,可重放和重试之间模糊的界限,理论上和形式上是可以放大不利场景的.

而且因为虽然API Gateway后面并不校验nouce,但是SDK层面又注入.

所以你要证明是过错方也是有点缺乏依据的.

即使不在交易上出问题,在转账上面也是有可能有一些利润空间的.

像perceptual的funding payment概念.

形式上来说,这个是根据所谓的为了衍生品跟底层标的挂钩平衡加入的激励因素.

比如标的是BTC,然后对应的衍生品BTC perceptual会给予call/sell方以动态的正负利息/税费收入.

根据交易所自己的平衡原则,你call BTC perceptual可能会有一定利息,或者要付一定利息.

sell侧也是.

而且这个东西每小时结算一次.

极端产品的这个小时利息是可能倒万分之一的.

在这种情况下去重放,即使市场本身不波动,交易所那边也还是有可能有超额收益的.

当然,有funding payment这种东西的存在,交易所也犯不着去搞那么复杂的重发了.

毕竟税率既定,而且实际流水的变动相较于市场的波动,可能一般人也不会注意到,或者说在意.

而如果跟进一步考虑的话,这个可能就更有意思了.

因为它的结算单位是USDC.

所以宏观上里说,每小时是有一定市场持仓比例的USDC以这个费率的形式作为交易所收入固化回去的.

而交易苏的所有交易其实都是机遇USDC或者其他所谓稳定币维系的.

因为虽然你可以cash in和cash out各种法币.

但是你其实并不难直接用法币交易非stable coin.

或者说,有路径,但是一般也不会通过非stable coin的方式进行转化.

于是从会计角度来说,形式上,交易所账上的USDC负债会比例性地转换为资产.

再假设,如果交易所有自己的类stable coin的代币.

那么完全可以用这部分转化的资产去对自己的代币进行市值管理.

同时因为市值正向增长,而且属于自我发行的一般代币.

再基于代币进行市场融资进一步放大杠杆,然后回头做市也是有可能的.

所以总的来说,这套东西还是挺野蛮的.