计算 MSTR 的 mNAV(官方算法)

民间给微策略(MSTR)计算 NAV 用的方式是这样的: $$ 如果把 MSTR 当作一个 BTC ETF 来看,使用这种计算方式比较合适。但 MSTR 官方的口径不同: The multiple of the BTC Reserve, as of the specified date, calculated as the Company’s enterprise value (as we define it) divided by the BTC Reserve. Although mNAV incorporates the label “NAV,” it is not equivalent to “net asset value” or “NAV” or any similar metric in the traditional financial context. Investors should rely on the financial statements and other disclosures contained in the Company’s SEC filings. This metric is merely a supplement, not a substitute, to the financial statements and other disclosures contained in the Company’s SEC filings. It should be used only by sophisticated investors who understand their limited purpose and many limitations. 所以根据 MSTR 的解读,mNAV 这名字里面虽然有个 "NAV",但它不是 NAV,它是一个倍数,无单位,正确的算法是: $$ 其中,EV 是企业价值: $$ 于是, mNAV ≈ 1:企业价值 ≈ BTC 持仓价值。 mNAV > 1:市场给了核心业务正的估值。 mNAV < 1:折价或净现金较多。 数据与方法 我的目的是用 MSTR 的方式来计算 mNav,而不是民间的做法。于是有: market_cap = mstr_close * shares ev = market_cap + debt + preferred_equity - cash btc_value = btc_holdings * btc_close mnav = ev / btc_value = (market_cap + debt + preferred_equity - cash) / (btc_holdings * btc_close) 其中,mstr_close, shares, debt, preferred_equity, cash 可以直接从 Yahoo finance 拿到( debt, preferred_equity, cash 要从季报里读,然后向前充填); btc_holdings 和 btc_close 可以从从MSTR 官网 拿到 然后即可算出 mNAV。这个过程我让 AI 帮我 vibe coding 完成了。 在 TradingView 里画图 由于 mNAV 可以直接预计算,所以不需要用 pine script 计算了,直接把上一步计算得到的结果塞到 pine script 里就行。 可以直接在这里使用我发布的脚本

2025/12/8
articleCard.readMore

人人都能写程序:Vibe Coding 与问题规模

follow problems, not trends. 先把问题弄明白,代码只是把答案写下来。 程序是问题的解法。 现在你有一个明确的问题,它的解法可以压缩成一段可重复的动作。 你的程序 = 需求 →(抽象/分解)→ 可执行的步骤 → 稳定的结果 它不必伟大,也不必通用,只要稳定地把麻烦变成平静,就是好程序。 程序/服务是商品 不会写程序的人,通过购买软件或订阅服务来租用别人的解决方案。 供应方卖的不是代码,卖的是可持续的可靠性与持续维护。 Vibe Coding:更多人能开始自己写 Vibe Coding 指的是: 用自然语言描述意图,模型给出可运行的原型; 通过来回对话,把「模糊的感觉(vibe)」收敛成「明确的行为(code)」。 门槛被抬走了: 初学者不用先学语法,再学框架,最后才写功能; 现在可以先「把问题讲清楚」,让模型给出「能跑的草稿」,再逐步打磨。 这意味着越来越多的人将第一次「自己写程序」来解决自己的小问题 小规模问题,绕开了很多规模带来的难点 当问题规模很小(一个人的流程、少量数据、有限并发)时: 架构复杂度:不需要微服务/消息总线/分布式一致性; SRE 难题:不需要 5 个 9;不需要监控; 协作/治理:没有跨十个团队的接口协议; 成本约束:用一台小机器就够了。 在这个尺度上,过去必须由工程师团队解决的门槛,显著降低。 比如说发博客文章这件事,Quaily 作为一个内容平台,需要向几千作者提供服务时,就需要通过合理的架构来解决数据规模上涨带来的问题。但如果自己做独立站点,只处理自己的文章,数量很少,甚至都不需要建立索引。 工具类利空,授课/知识付费利好 对工具类程序/服务显然是利空。如果核心价值是「把若干常见步骤串起来」,那么用户可能用 Vibe Coding 半天就复刻一个够用版。甚至,直接在 AI 对话框里就把事情解决了。 于是同质化功能的溢价被压缩,长尾需求被用户自助满足(比如图片处理)。 对授课/知识付费/方法论反而是利好。因为「把问题讲清楚」和「把需求说准」变得更重要。 好老师会教你如何描述问题、如何验证结果、如何迭代。这直接提升 Vibe Coding 的产出质量。 规模,依然是难点:Vibe Coding 不能替代软件工程 当问题跨过玩具规模,需要对外提供服务了: 数据规模:TB/PB 级别数据、软件质量控制、权限隔离 流量规模:缓存、降级熔断、成本优化 组织规模:向后兼容、变更管理、安全合规 可靠性:SLA、灾备演习 这些都不是“几段提示词”能一蹴而就的。不具备计算机工程能力的人,目前无法仅凭 Vibe Coding 搞定大规模系统。 什么时候 Vibe Coding 不构成威胁? 如果一个程序/业务的商业价值与规模效应、网络效应、分发、合规壁垒、数据壁垒、品牌与信任强相关,或者其价值本来就与技术无关(比如渠道、供给侧资源、IP),那么 Vibe Coding 难以替代: 举些栗子: 规模相关:广告平台、支付网络、物流网络、搜索/推荐系统 技术无关:独家版权、强渠道、强供给关系、特许经营、监管牌照 Vibe Coding 解决的是把意图落地为小而美的可运行草台方案,不是万能钥匙。 给产品与团队的一点策略 做不会被轻易复刻的东西:把护城河放在数据、网络效应、品牌,而不是某个按钮后面的三行代码。 把描述问题的能力产品化:让用户在产品里自然地把问题说清楚,就更接近用户最真实的需求。 把工程能力留给真正需要规模的地方:小问题用 Vibe Coding 快速落地,大问题继续用工程师。 写给第一次写程序的人 第一次写程序,不需要想架构有多优雅,先想我今天能把什么问题彻底解决。 把问题讲清楚,跑起来,验证结果。 这就足够好。

2025/9/19
articleCard.readMore

关爱用户的可伸缩性

之前在微信上班的时候,工作群里出了一件事: 一位前同事的孩子吃了从某电商购买的问题食品,被送进了医院。 所幸在群中电商朋友的帮助下,事情很快得到了处理: 贩卖不合格商品的商家得到了处罚 电商的广州团队亲自对当事人进行慰问 孩子痊愈了 当然以上措施的前两个放在消费下行的现在,已经不太可行了,毕竟 P 哒哒上的东西吃了也不一定会死对吧 另一个同事在群里说:做电商产品不重要,重要的是运营。 这个观点怎么说呢,有失偏颇。 今天因为这娃的爸是微信前员工,可以迅速得到了妥善处理,那明天其它顾客的娃出现症状怎么办呢? 如此关爱用户手段不具备良好伸缩性1。 Schelling 在 Choice and Consequence 中提到了「确定性生命」和「统计学生命」的区别: 确定性生命:一个有着棕色头发的六岁女孩需要几千美元接受一个手术,从而让她的生命能延续到圣诞节。社区邮局会被零钱和硬币淹没,因为人们都在捐款救她。 统计学生命:有新闻报道说,在取消销售税后,麻省的医院设施将不能得到及时更新,从而导致本来可以预防的死亡人数有一点点增加。不会有多少人为这新闻而落泪,更不要说捐款了。 电商这次关爱的用户是一位「确定性生命」,但是公司的数据报表里还有三亿「统计学生命」需要也更值得关爱。 如何在统计学尺度上描绘用户、理解情绪、关注到抱怨、制定规则,最终去关注这些似乎没有面孔、身份、性别、偏好的人,来避免诸如此类事件的发生,对规模化来说更有意义。 关爱的用户的姿势 关爱分方法。 少有人会愿意花时间去考虑如何去理解和关爱自己的用户。 相比长期产品建设,人们更愿意用 ROI、GMV、DAU 等纯粹的数据指标去衡量产品和业务得失。 数据指标确实能够抽象和概括现状,但只要是指标就会丢失信息。 统计学用户不表现面孔,不代表他们没有面孔;能在数字之外看到用户的脸,才能创造顾客价值。 如果说回归商业,营销为王,那来回归一下营销,看看现代营销学之鼻祖 Philip Kotler 怎么说: Marketing is not the art of finding clever ways to dispose of what you make. Marketing is the art of creating genuine customer value 营销并非一种以精明的方式兜售自己产品的技巧,而是一种创造顾客价值的艺术。 能对统计学用户给予关爱的产品设计,看似缺少运营,恰是对运营理解得最透彻的,在源头上做了正确的事情。 因为如果我是那个爸,我更希望自己的娃不要进医院,而不是有十二个不认识的叔叔阿姨来看她。 可伸缩性(scalable)是一个计算机领域术语。简单表述就是通过架构调整让系统做更多的事情,以较低的边际成本,服务更多用户。 ↩︎

2025/9/6
articleCard.readMore

我最喜欢的悖论

本文译自 Facebook 高级软件工程师 Forrest Smith 的文章《My Favorite Paradox》。 我得到了他的授权将文章翻译为中文。 我们正生活在一个“大数据”时代。免费游戏每天收集多达 300GB 的数据,网站记录你每一个像素的点击。现在甚至可以用 A/B 测试,来测试哪种 A/B 测试工具最好用。 谎言有三种:谎言、弥天大谎、统计数据。 有些人会恶意操控数字来得出他们想要的结论。我们对这种操作已经不陌生。 但还有一种更隐蔽的风险:那些聪明、受过良好教育、有理性思维的人,也可能从正确的数据中,得出完全相反的错误结论。这种事比你想象中容易发生得多。 辛普森悖论 1973 年,加州大学伯克利分校因涉嫌性别歧视被起诉。数据显示男性研究生录取率为 44%,而女性只有 35%。 申请人数 录取率 男性 8442 44% 女性 4321 35% 这起诉讼引发了一项深入研究。研究结果却显示:不仅女性没有被歧视,她们的录取率甚至还更高! 这到底是怎么回事?数据不是已经很清楚了吗? 答案是:辛普森悖论。 在分组数据中出现的趋势,可能在合并后消失,甚至反转。 事情是这样的:有些院系录取率高,有些则很低。而女性更倾向申请竞争激烈的院系,男性则偏好录取率高的“容易进”的院系。整体看似男性更占优势,但一旦分院系来看,反而是女性更容易被录取。 男性申请 录取率 女性申请 录取率 院系A 825 62% 108 82% 院系B 560 63% 25 68% 院系C 325 37% 593 34% 院系D 417 33% 375 35% 院系E 191 28% 393 24% 院系F 373 6% 341 7% 这是一个真实案例,也成为辛普森悖论中最经典的实例之一。 我非常喜欢这个悖论,因为它不仅会影响结果,甚至能彻底颠覆结论。而且这种“翻转”真的太容易发生了。 肾结石治疗的误导 我们再看一个案例,加深理解。 肾结石有两种治疗方法,哪种更好? 治疗方案 A:350 人中成功 273 人(78%) 治疗方案 B:350 人中成功 289 人(83%) 看起来方案 B 更好,对吧?其实正确答案是:方案 A! 为什么会这样? 类型 方案 A 方案 B 小结石 93% (81/87) 87% (234/270) 大结石 73% (192/263) 69% (55/80) 总体 78% (273/350) 83% (289/350) 肾结石分大、小结石,大结石更难治。而无论是哪种结石,方案 A 的成功率都更高。 关键在于两种方案中,小结石与大结石的分布不同: 方案 A:87 位小结石患者、263 位大结石患者 方案 B:270 位小结石患者、80 位大结石患者 因为方案 A 的样本更多是难治的大结石,所以它的总体平均治愈率被“拖了后腿”。而方案 B 虽然整体治愈率高,但那是因为它治了更多容易处理的小结石。其实每一种结石类型上,方案 A 都更优秀。 像剥洋葱一样思考 辛普森悖论就像剥洋葱:最外层的数据说方案 B 更好;你深入一层,发现 A 才是赢家;再剥一层,也许在某些特定情形下又轮到 B 更合适。 比如老年患者?肥胖患者?合并其他疾病的患者?每深入一层,你都可能翻转之前的判断。 在分组数据中出现的趋势,可能在合并后消失,甚至反转。 我喜欢这种“每剥一层就推翻结论”的过程——它挑战直觉,逼你不断思考。 游戏里的悖论 辛普森悖论不仅出现在招生或医学上,游戏数据分析也中招。 想象一个 FPS 游戏,玩家们抱怨狙击手太强了。你查看数据: 狙击手平均击杀数高于其他职业。 看起来玩家说得对。但深入一层: 狙击手在低分段中击杀多; 高分段中使用率低; 某些地图上表现压制性更强。 这时候你可能开始想调整。但你还没深入够,继续剥洋葱: 狙击手上手简单但上限低; 克制新手爱用的职业; 某些地图长视距让狙击手无敌; 某些地图中,敌人经常犯错; 狙击手本身没问题,是队友某个 OP 辅助太强; 排位系统没能把高水平狙击手匹配到高分段; 或者中等水平的狙击手被错分进了高分段。 最后两条我特别喜欢,因为: 第六点说明问题根本不是“狙击手太强”,而是系统匹配逻辑错了; 第七点更妙——两种完全相反的错误,会带来相似的坏结果。 一个假设 我有个猜想——也许可以算是一条“定理”: 对于任何统计结果,都可以构造出一个相同数据但得出相反结论的场景。 这就是为什么,每当你得出一个数据结论时,都要问问自己: 有没有可能我正处于辛普森悖论中? 有没有一层数据没剥开,藏着另一种真相? 总结 无论你拥有多少数据,问对问题才是关键。 你可能出于好意做分析,但问错问题就会得出错误答案。 辛普森悖论是个警钟,提醒我们:小心统计的陷阱。要常常提醒自己: “如果我再深入一层呢?” 彩蛋故事:YouTube 的加载速度 再讲一个我很喜欢的故事。 2012 年,YouTube 工程师 Chris Zacharias 写了一篇博客《Page Weight Matters》。他在负责优化 YouTube 的视频播放页。原页面太大,达到 1.2MB,加载慢得令人抓狂。 他花了几天,把页面优化到了 98KB,减少了请求数,还用 HTML5 播放器取代了笨重的 Flash。感觉很棒,他上线了新版本。 一周后回头看数据,结果惊人: 新页面比老页面加载还慢! 平均延迟竟然上升了,怎么会?明明页面更小更快啊? 这其实又是辛普森悖论。 原因是:优化后新页面吸引了大量“新用户”,比如来自东南亚、南美、非洲等网络条件较差的地区。这些地区加载时间平均为两分钟——虽然慢,但已经能用了。 而在旧版本,他们压根打不开页面,自然也就不被统计进旧数据中。 所以,从 20 分钟缩短到 2 分钟,不是失败,而是巨大的胜利。整个原本无法使用 YouTube 的人群,现在终于可以用了。 结论呢?初步统计说这是失败的上线。 所以问题来了:我们有多少次,也在数据中误入了“悖论”,却浑然不觉?

2025/9/1
articleCard.readMore

Quaily 的开源项目

Quaily 最初是打算开源,但一年多来都没有找到开源的理由。如果开源的话,对于代码、架构、文档的质量的要求会很高,社区参与低的话,我是没有精力做这些事情了。 不过也陆续完成了不少开源仓库。这些仓库不是「为了开源而开源」,而是 Quaily 在实际开发里遇到具体问题后诞生的工具。 下面梳理它们的来历,并补充更技术向的细节。 1 · quail-ui  — Vue 3 组件库 虽然我的习惯是不出设计直接代码,但是项目规模稍大以后,还是希望有一套统一的视觉。 当时流行 Tailwind,但我不喜欢,冗余,废话太多,于是需要一套更轻巧、样式统一的 UI 组件,那就自己写吧,反正也不难。 技术 :Vue 3 + <script setup>、SCSS 变量、按需 import+Rollup Tree‑Shaking。 组件 (摘自 src):QButton / QInput / QTooltip / QDialog / QIcon* / QLoading 等 60+ 组件,配套 icon 集可直 import。查看 Demo。 特点 :极小外部依赖;支持暗色模式  用法: import { createApp } from 'vue' import { QuailUI } from 'quail-ui' import 'quail-ui/dist/style.css' createApp(App).use(QuailUI) 2 · quail-js  — TS/JS SDK Web 前端与 Obsidian 插件都需要和 Quaily API 交互,那就整个包吧。 src/ 以 ESM 方式导出 QuailyClient,内置 token 注入、重试与错误映射;Rollup 打包生成 dist/。主打一个一把梭,又不是不能用。 调用: import { Client } from 'quail-js' const client = new Client({ apibase: 'https://api.quaily.com', access_token: '...' }) const resp = await client.request(url, 'GET', null) 3 · obsidian-quail  — Obsidian 插件 Quaily 早期无 Web‑CMS,一切创作在 Obsidian 中完成,需要一键发布。于是需要个 Obsidian 插件。 主要命令 :Quaily: Publish / Unpublish / Preview / Sync。 功能点 :多语言、多渠道投递;AI 自动生成摘要与标签;移动端预览;发布后可直接把邮件发送给订阅者 安装 :在 Obsidian 社区插件商店搜索 “Quail” 即可。 4 · goldmark‑enclave  — Markdown 语法增强(Go) goldmark 扩展性极好,适合 Quaily 用来扩展 Markdown 语法。 提供的扩展 : 媒体 Embed:YouTube、Bilibili、TradingView、Spotify、Tweet、Quaily Post 等,全部复用 ![](url) 语法; 行内高亮 ==text== → <mark>; Pandoc‑style fenced div、GitHub‑style callout; 图片尺寸、对齐、主题参数; 自动把链接 title 写进 <a title="…">。 调用: md := goldmark.New(goldmark.WithExtensions(enclave.New())) 详细的方法请查看项目 README.md 5 · quail-cli — 终端与自动化入口(Go) 需要在 CI/CD、脚本或本地终端里操作 Quaily,并探索将 Quaily API 暴露给 LLM 工具链(MCP)。 核心技术:Go + Cobra CLI;OAuth 登录;client/ 复用 quail-js 定义的 API schema;可选 MCP Server(SSE / stdio)。 实验功能:quail-cli mcp --sse 启动本地 AI 工具协议服务,支持搜索、获取、发布等工具调用 主要命令:login|publish|unpublish|deliver|delete。 这里有两篇介绍: 🖥️ 介绍 Quaily CLI:简化你的工作流 🤝 使用 Quaily MCP 和 AI 共同创作:以 Cursor 为例 示例: # 登录(浏览器完成 OAuth) quail-cli login # 从 markdown front‑matter 创建或更新文章 quail-cli post upsert article.md -l my-channel 6 · bizdocgen  — PDF 发票/贷记单生成器(Go) 每月要生成大量符合日本税务格式的发票,手工排版麻烦不说而且易出错。那就写个程序吧。 特性 : 内置 NotoSans CJK 字体示例,支持日中英混排; 模板驱动,可扩展其他单据。 使用方式: 读取 YAML/JSON 参数 + 可选字体配置 → GenerateInvoice() 回传 []byte: bd, _ := builder.NewBuilder(cfg, "./params.yaml") pdf, _ := bd.GenerateInvoice() os.WriteFile("invoice.pdf", pdf, 0666) 7 · translate-cli  — AI 批量翻译 JSON Locale 工具 Quaily 的 i18n 文案存放在 JSON,手动翻译耗时;希望借助多家 LLM 快速产出可初审的翻译。 功能清单 : OpenAI / Azure / Bedrock 等多提供商切换(还没完成); 支持 Glossary 和背景上下文文件; --batch 控制窗口大小; 中文自动去除 “您” 系列敬辞,日语句末润色; 同步写回多语言文件。 命令示例: translate-cli translate -s en-US.json -d ./langs -g glossary.json \ -b background.txt --batch=20 这些工具都源于“先把问题解决掉,然后顺手贡献给社区”的习惯。如果它们也正好能解决你的痛点,欢迎 Star ⭐、提 Issue、开 PR

2025/7/7
articleCard.readMore

创造世界是一种什么样的体验

生命是神奇的存在。 生物学家们致力于考察真实生物的运作机制,而冯诺伊曼不同,他尝试在数学上寻求生命的本质。 因为在冯看来,生命的本质属于一种软件逻辑,他设计的「生命」形态可以与现在的生命完全不同,所以他选择的起点是图灵机。 冯诺伊曼的自复制自动机理论告诉我们 DNA 就是源代码,是元生物学的起源 在元生物学的论证过程中发现:代码即 DNA,算法突变即进化,软件即生命 生命的本质不是新陈代谢和遗传,而是创新 以上就是 Gregory Chaitin 的《证明达尔文》一书前五章的主要观点。 书写得冗长,读得很累。这个老头子有严重的骗稿费嫌疑,把一个课件写成了一本书。 我只打算写一篇文章,和老头子这本书的附录有关,附录是冯诺伊曼手稿。假如计算机科学是宗教,他是神祗之一。 耳机放兜里会打结,开水会慢慢变凉,长时间不扫地面会脏。 这是对自然造物的直观认识,独立封闭系统中的有序状态会自发地趋向于混乱和无序,是熵增过程,遵循于热力学第二定律。 传统的机械,我们的大部分人工造物,也存在存在类似的状况。 假设一个机器 A 能够自发地制造出机器 B,那么 A 中必须包含完整的 B 的信息,只有这样 A 才能根据这些信息将 B 制造出来。因为 A 包含的信息大于等于 B,即 A 要比 B 复杂。 如果根据这样的理解,机器的复杂度会在制造过程中不断降级和衰退,即一个系统的复杂度总是高于它所能制造的子系统的复杂度。 但是另一方面,在自然界却存在与之背离的欣欣向荣的现象:生命的诞生与进化,科技的发展和进步,都在往越来越复杂和多样化的方向发展,即人人都谈论的「涌现」这一概念。 由于对此难以控制、预测和描述。因此,在历史上的大部分时间里,人们都认为这是一种神迹。 即使到现在,我们能说清楚大脑是如何用神经递质传递信号,但是也没搞清楚智慧是如何产生;我们能观察到生物体内所有的生化反应,但是没有成功在实验室里合成出真正的生命。 我们早已习惯并且百试不爽的自底向上的思维方式,在这里似乎没有达到预期的效果: 低层级的存在无法推断高层的复杂性。 似乎在诸多现象中,复杂度的积累存在一个阈值。没到这个阈值时,事物最终自发地衰退;超过这个阈值时,就立刻呈现涌现的群体特征。在成为神的道路上,这一问题拦住了脚步:这个阈值在哪。 冯诺伊曼意图能找到这个阈值。 生命的本质是一种软件逻辑 生命是神奇的存在。 生物学家们仅考察真实生物的运作机制,而冯与传统生物学家的追求不同,纵观他的工作,冯是在沿着一条规范的道路——数学——寻求生命的本质1。 或者说,在寻求一个生命的最小内核,因为在冯看来,生命的本质属于一种软件逻辑,他的「生命」形态可以与现在的生命完全不同,所以他的起点是图灵机。 图灵机很简单,对任何一个图灵机,他的描述总是有限的,因此可以通过某种方式将其编码为一条图灵机指令。图灵机 $M$ 的描述可以用 $I_M$ 来指代,所有计算机科学专业毕业生都知道。 冯·诺伊曼设计出了这样一组机器: 构造机 $A$:读入一条指令 $I$,则 $A$ 可以根据这条指令 $I$ 输出对应的机器 指令复制机 $B$:读入一条指令,输出该指令的复制 控制机 $C$:将 $I$ 放入 $A$,得到 $I$ 所描述的机器;将 $I$ 放入 $B$ ,得到 $I$ 的副本;最后将 $A$ 和 $B$ 的输出组装在一块儿输出 将 $(A, B, C)$ 组合为机器 $D$,根据上文的描述,当然可以构造出 $D$ 的描述,即指令 $I_D$ 最后,将 $I_D$ 输入机器 $D$,构成 $E$,容易发现 E 具备完整的自我复制能力,可以持续复制自己 在假设中,我们认为 $A$、$B$、$C$ 是元零件,并且容易得出以上描述不涉及循环指代:需要 $I_D$ 时,$D$ 已经存在,因此 $D$ 和 $I_D$ 间存在确定的时间和逻辑顺序,对 $E$ 的自复制能力的论证是严密的。 我们很容易在生物体中找到上面这组机器各个组成部分的对应物: $I_D$ 的表现很像基因。 $I_D$ 作为指令可以存在变异,在 $I_D$ 上直接变异会导致子代机器无法复制,是致命的; $I_D$ 上附加一段 $I_F$,则 $I_D$ + $I_F$ 会导致产出与复制核心逻辑无关的副产物,$I_F$ 发生变异则不会影响子代机器的复制,类似于基因表达了蛋白质。 但是,如果单独来看,无论是构造机 $A$,复制机 $B$,控制机 $C$,还是他们的基因 $I_D$ ,在他们各自独立时,都不具备自我复制的能力。当他们以合理的方式组织在一起时,却实现了自我复制,实现了自复制功能的涌现。 冯的研究仅仅是向一个关于自动机的涌现理论迈出的初步尝试,这个尝试在试图对复杂系统中的「复杂性」形成一个概念。他认为「复杂性」在一个阈值以下的系统会自发退化,这样的系统只会产生复杂性更低级的系统;而当复杂性高于这个阈值时,系统可以在该层次的复杂性上维持(比如 $E$);如果我们能让人工造物的复杂性高于这个阈值,那我们就做了神的工作2。 冯诺伊曼虽然最终还是没有找到这个复杂度阈值,但他认为可复制自动机应当处于一个相当靠近复杂度阈值的地方,而且与其他试图解释涌现的理论的差异在于,冯·诺伊曼的解释在数学上存在对应物,如果我们不满足于仅仅观测,而希望真正深入地理解涌现,可复制自动机理论可能是条件很好的切入点。 悄悄敲敲代码,就有机会创造世界。 冯·诺伊曼的自复制自动机理论成型于 1944 年,而 DNA 双螺旋结构在 1953 年才被发现,但 1952 年时,DNA 结构发现者克里克读了冯诺伊曼的论文,表示深受启发,并最终发现了 DNA 双螺旋结构,拿了诺贝尔奖。 ↩︎ 可以在互联网上找到很多被称为 Quine 的程序,代码的输出结果就是代码本身。能复制自己的程序一点都不新鲜了,简单如元胞自动机,复杂如 MIT Self-assembly Lab 的机器人。但它们不能与真实的生命相类比,因为它们不能自发地制造比自己更复杂的个体。 ↩︎

2025/5/14
articleCard.readMore

一代程序员王小波

我非常喜欢王小波的原因有两个: 这个人很有趣; 这个人是程序员里小说写得最好的。 在 90 年代的短短 7 年里(他 1997 年去世),在戏谑地严肃思考自由和尊严的同时,还搞了中文处理软件和中文输入法这两个中文计算机史前时代巨坑。当时很多计算机是要通过「汉卡」这种独立硬件来显示中文的,可以理解成显示中文需要在屏幕上「画画」,麻烦呢。 以下来信片段节选自王小波书信集,收录于王小波全集之中。 1988年12月,致晓阳 回来之前我曾往人大一分校计算机站写过一封信,问他们可要带什么软件,主管的工程师回了封信,我没收到。回来之后人家还提到此事。现在国内软件一面混乱,又逐渐有形成市场之势。首先以年兄学统计这一事实来看,回来做事非有会用的软件不可。 Macintosh 根本就没打进中国市场,你非带几个可用的 IBM 微机软件回来不可。至于什么机器上能使倒不必太担心。我这个狗屁计算机室,IBMPS/2就有二台。AT机也不少。SAS SPSS Statistx 都有,可代表国内上等一般统计微机房的水平,可就是少了一种宜于作统计的语言。 年兄如有 APL(A Programming Language)之 IBM 微机本,可给我寄 copy 来。我在美还有一个户头,连 manual 复印费一并写支票给你们。Glim 我也没有,如年兄有便人可捎来。邮寄太贵,能省就省吧。 文中的 SAS,SPSS,Statistx,Glim 都是统计学软件,其中 SPSS 和 SAS 两个商业软件现在依然被使用。 其中提到的 APL 是一个对现在的程序员来说不太寻常的计算机语言。 比如说在 APL 中,2*3 表示 2 的 3 次方,而不是 2 乘 3。如果想要表达 2 乘 3,得这么写:2×3。对,真的用乘号 ×(这不是字母 x)。 你可能注意到了,APL 的语法中使用了数学符号,比如: 从 1~100 中选择一个随机数是这样的: x[⍋x←1?100] 求 100 以内的所有质数是这样的: R←100 (~R∊R∘.×R)/R←1↓ιR 下面是实际的代码运行结果: 因为 APL 的语法中包含大量的数学符号,如果你要用 APL,最好买一个 APL 专用键盘或者贴纸,比如这种,否则输入这些符号会让人痛不欲生: 1990年1月,致晓阳 我现在正给北大社会学所做统计,手上除SPSS没有可用的软件,国内这方面很差。 我现在会用FORTRAN,编统计程序不方便。闻兄谈起你们用 S语言,不知是否好用。工具书也不知好找不。不管好歹,烦兄找个拷贝给我,要就算了。照我看只要能解决各种矩阵运算就够:当然也要有各种分布函数。反正也是瞎胡混,我就算努把力,少混点吧。 文中的 S 语言 是 1976 年由贝尔实验室设计的统计学编程语言。 不过王小波提到的 S 语言可能指的是 1988 年以后的新版 S 语言。后来在统计领域广泛使用的 R 是 S 语言的后继者。 下面是 R 的例子,语法已经很现代了: recurse_fibonacci <- function(n) { if(n <= 1) { return(n) } else { return(recurse_fibonacci(n-1) + recurse_fibonacci(n-2)) } } nterms = as.integer(readline(prompt="How many terms? ")) # check if the number of terms is valid if(nterms <= 0) { print("Plese enter a positive integer") } else { print("Fibonacci sequence:") for(i in 0:(nterms-1)) { print(recurse_fibonacci(i)) } } 1991年3月,致晓阳 你寄来的严氏2.0A我也收到,还没用。因为一者是3盘要倒,二者我自己写的WK也有重大进展。我也自做了词组功能,是棵B树,我觉得自写的软件自用,感觉是最好的。 词组用处不是很大,主要用于定义人地名等专有名词,但是严氏软件对我还是有重大启示,拼音加四声是个极好的主意,写起东西来声韵铿锵,与其他软件大不一样。自写一遍,从分页到编辑键分配,都能合乎自家习惯,不是存心狗尾续貂也。如能见到严氏,可代为致意。 文中的严氏 2.0 可能是当时某个中文输入和处理的软件。因为在其他信件中,王小波提到的 WK 是对严氏的仿制,而 WK 是小波用 C 语言实现的,用来写小说。 这里王小波提到 WK 用 B 树实现了词组查询,应该是为了方便自己中文输入。一个典型的 B 树搜索是这样的: 1992年1月,致晓阳 编译程序一盘(有说明书,见shou),源程序一盘。我的音典与严氏同名内容不同。功能上与严氏的近似,但是多了改进拼音字典的功能。按F4后可以把拼音重定义。也可加字,在拼音拣字时,按enter,就进入国标拣字,拣到的字加入字典。 这个软件由五个c语言(另有两个头文件)和一个汇编语言文件组成,可用 turboc编译,但是汇编部分不必重汇了,可以把汇编文件写成的部分形成的obj(我的磁盘上叫wk5.obj)放到硬盘上,与其它c语言文件分开,用 turboc的 commandline 编译器编一下,命令如下: tcc-mc-ewk -c wk*.c wk5.obj graphics.lib 形成wk.exe,但是必须有yindian,cclib,egavga.bgi三文件支持才工作。 *.bgi 是图象板参数表,可以包括到*.exe内的。但是要改改程序。你的机器好。我还用个老掉牙的XT机,简直落伍了。turbo.c你一定能找到。假如你用过其它c软件,有一点要提醒你,turbo.c有一种极讨厌的特性,就是你在一个函数内alloc的内存,退出该函数时不会自动释放;还有一点也很糟,就是模型问题,在大模型下写的程序,到了小模型上一概不能用,我的程序是在compact模型下写的,就不能用small来编译,这两条是可以气死人的。据说可以用far,near之类的前缀说明指针,其实是屁用不管。我干了一年多c,得到的结论是微机c还不能使人快乐,有时叫人怀念汇编。 这封来信应该是王小波的 WK 软件的首次「发布」,他提到 WK 要用 Turbo C 这个 C 编译器来构建。Turbo C 是 Borland 公司 1987 年发布的 C 语言集成开发环境(不过国内信息学奥林匹克竞赛一直要求使用 Turbo C 作为比赛环境到新千年以后,因为我当时参赛时用的就是 Turbo C)。 来信中提到的 Turbo C 的两个特性: 一是 alloc 后的内存不会自动释放,我不清楚他指 alloc 是否是误用 alloca 还是 Turbo C 的实现标准不同,因为 alloca 是在栈上申请内存的,而 malloc 不是; 二是内存模式问题,Turbo C 这样的老 C 编译器是面向 DOS 的,因此提供了不同的内存模式。简单来说就是不同模式下指针基础偏移不同,在 compact 下的指针在 small 下可能会指向错误的地址,所以「大模型(不是 Large Language Model)下写的程序,到了小模型上一概不能用」。 现在的程序员大概很少会考虑到内存布局的问题了。 1992年9月,致晓阳 我用 C 编的软件已经用熟,并做出了各种写小说的工具,别人的软件已不用了。现在主要是写书赚钱。从今年初开始写长篇,首先做了写长篇的专用软件,现在基本调通,开始写了。 这里提到的「用 C 编的软件」应该指的是上文的 WK 和其他帮助写小说的软件。 从此世界上少了一位「蹩脚的」程序员,多了一位伟大的作家。 年份不详,致曲小燕 我们的 pc 机还没有和 Internet 连上。本来中国有几个国内网发展得很快,现在又出了问题,谁要上 Internet,必须到有关部门去登记,留个案底,以备当局监控,很有一点监狱的气味。 哈哈。 除了这些,书信集中其他信件也非常有意思,推荐阅读。

2025/5/7
articleCard.readMore

幻觉

从地理到文化的裂谷 我们常忘了,中国和美国都幅员辽阔,很难只有“一种声音”。 但是,从上海到东京的距离是 1700 多公里,从上海到乌鲁木齐的距离是 4300 公里,从乌鲁木齐到伊斯坦布尔的距离也只有 4730 公里。 对一些上海人来说,也许乌鲁木齐的文化距离比东京更远。 同理,新疆的穆斯林或许觉得伊斯坦布尔比上海更亲近。 文化的差异不仅仅体现在语言。 不同省份之间的文化差异就跟不同国家之间的文化差异一样大,如果对比对象是欧洲那些国家,可能省份之间还要更大一些。 北上深、普通省会、五六线乡镇,几乎像三个发展阶段的国家,各自的文化迥异。 这也解释了「春节回乡总吵架」:本质像跨国旅行。 尊重的双向门 在东京呆了几年。 老一辈常问我:日本人歧视中国人吗? 那上海人歧视河南人吗? 一个现实的情况是外国人在日本租房子的难度是有差异的,日本房东会“审查”租客的背景材料,包括国籍、工作、收入水平、违约历史等等。 有些房东对中国籍者格外苛刻,确实存在。 单看这个结果似乎是歧视中国人。 但是很多歧视不是无缘无故产生的,这是一种对坏事情发生的概率的应对方式,在企业里面用另一个词描述它:风控。 有人问 Linux 创始人 Linus Torvalds 为什么在邮件列表里骂人。他答: 我只尊重那些值得尊重的人。有人觉得尊重是必须给予的,但我属于反对这种观点的人。尊重要靠自己去赢得,不去赢得你就得不到尊重,事情就是这么简单。 所以我觉得这个问题很简单, 反而真正顽固的,是户籍、住房、教育、医疗、性别这些制度化歧视。 生而自豪还是有所贡献 如果在中国长大,从小就被教育应该为身为一个中国人而自豪。 这很奇怪。 中国确实是一个文明古国,历史悠久,文化繁华。从古代到现代,中国人做出了很多辉煌的成就。 但这些成就与我何干?我既非创造者,也未参与其中。 如果我把自我归因于某个群体,那只能说明我作为个体本身毫无贡献,不得不诉诸群体,这对个体来说毫无意义。 如果我要自豪,那这种自豪应该来自我做出的贡献和成就,比如我做了什么事情,有帮到其他人,而不应该是某种与身俱来的东西。 「我是一个中国人」跟「我天生双眼皮」和「我有易患糖尿病的倾向」本质上是一样的,都是与生俱来的东西。没有人会因为自己天生双眼皮和易患糖尿病自豪对吧,所以为什么要对于哪国人的身份而自豪呢。 从逻辑推演,这里存在悖论。 能源的尺度 大概在几年前,面试了一个工程师。 面试结束闲聊时间,聊到了 BTC。他嫌比特币耗电:一年用电接近三峡大坝年发电量,太浪费。 就数量级上看,他说得没错。在《Bitcoin Energy Consumption Index》这篇文章里,作者估算 BTC 一年的电力消耗大概是 77TWh。在三峡大坝的维基百科,可查到大概一年的电力输出是 100TWh,确实是一个数量级。 当时我解释:POW 本就耗电,所以有人研究 POS、DPOS 等替代方案。 不过后来我发现,即使是 POW 又怎么样呢,有什么好辩解的。 人类能耗本就不断上升,不上升才怪。 在很多科幻小说里,都有星际旅行和开发行星的桥段,所有星辰大海都需要很多能量的支持。 1964 年,苏联天文学家尼古拉·卡尔达肖夫提出用能量划分文明等级,被称为卡尔达肖夫指数: I 型文明:驾驭文明所在一整颗行星的能量,消耗能量大概在 10^16 W 这个量级。 II 型文明:驾驭一颗恒星的能量,消耗能量大概在 10^26 W 这个量级。 III 型文明:驾驭一个星系的能量,消耗能量大概在 10^37 W 这个量级。 现在人类尚未达到 I 型。 2018 年全球耗能约 18 TW,仅 10^13 W。 就这点,距离 I 型还差三个数量级。 若真追求星辰大海,届时用百万分之一的能源维系全球金融系统,反倒显得吝啬。 最大的问题是:人类寿命太短,能理性判断的年头不过 50 年;放在文明史上,只是指顾倏忽。 我们自觉身处平地,只因目力所及不过几米;或许脚下是谷底,也可能已在峰顶。

2025/5/3
articleCard.readMore

感谢竹白,以及如何支持竹白用户的迁移

2 月竹白发布下线公告的当天,我发了「🚚 指南:从竹白(zhubai.love)迁移到 Quaily」。 倒不是手有多快,而是 Quaily 很早就支持从竹白导入了~ 迁移结果 截止到 2025 年 3 月 31 日,共计迁移了 31 个频道,1715 篇文章,9845 位订阅者。 他们是: CyberClip: 一份臻选互联网上有价值内容的赛博剪报,两周一期,涵盖新奇趣闻、热点议题、前沿科技以及其他关于生活、关于未来的事物。 熊言熊语: 与你分享肿瘤生物医药领域的研究进展以及我的所思所学所想。 为何是他: 以信求知。 无限自然: 《无限自然》对优质信息源/AI自动化提效有足够的好奇心,关注AIGC对产品设计的影响。通过逐步建立良好的系统,无限接近自然的状态。 素生: 误读人生,化人生活 事不过三: 重要的事不过三件:认识自己,好好学习,好好生活。 试行错误: 反复探索,不断试错。重在实践和落地。希望能和你一起找到「改变」的突破口!同行的人比目的地更重要。 乔尔事务所: 关于地方和空间的观察备忘录 海上星光: PM@阿小小海和设计师@尤a娜共营的科技、设计、生活型博客/上海/东京 我脑袋里的怪东西: 无聊的通勤 + 奇怪的脑袋。 Off-Beat: 欢迎看到,这里会存一些个人感兴趣的东西;分享一些个人经历影响下,看到的喜欢的书、音乐、视频、文章;说一些评价、推荐、想法、见闻以及别的该说不该说的乱七八糟的东西吧。 日出山谷: 好奇心是智慧的种子! 跳歇间: 这是一段时间,也是一个空间。在这里,保持一种轻快的脚步,间歇小跳。 有(冇)用: 有(冇)用,源自粤语俗语,意为有(无)用。在当下的生活里,每天信息宛如瀑布般涌现在这小小电子屏幕上,同时信息内涵也悄然变化着,不再单纯且多少夹杂某些目的。但......这些信息是真的有用吗? Moonvy月维设计周刊: 每周一更新设计相关的素材和资讯 播客相对论: 分享有趣、有意思、值得被更多人听到的播客节目,也希望能在评论中看到你给我推荐一些播客节目。 大人的坚持魔法术: 分享一些坚持的魔法,做乌龟赛跑里的乌龟就够了。每周四发出。 闲时杂记: 记录生活的美好与不美好✨ 简悦周报: 简悦周报官方推送渠道,内容涵盖了:新用户指南 / 简悦阅读模式使用技巧 / 通用性问题的处理和解决方案 / 与其它生产力工具的联动 / 简悦用户提供的基于简悦的工作流等。 显济的闲言碎语: 下午2:00-5:00在喝咖啡|海外智能硬件产品设计师|做了自己的网站:Jefferyho.com 喧哗上等Radio: 播客《喧哗上等》的邮件推送 中文播客行业动态: 中文播客领域的动态和最新消息 花生碎: 记录是种自我建档。 学到老 Shadow law: 一个爱饮咖啡、常听播客、养了只猫的人。读了什么、想到什么,可能都会记录下来,随机从里面抽取片段分享。 自说自话: 没有记录就没有发生,而记录本身已经是一种反抗。 一颗小树: 分享我的日常,包括但不限于互联网、技术、开源、投资理财,欢迎你来。 吾栖之地 | Soul Place: Chuwen的不定期回顾,用文字创作Cyber空间的个人纪录片。 驯鹿漫游: 记录我近期收集的有趣信息及一些联想。不定期更新。 家书: 以书信形式给青少年看的生命哲思。 未闻Code·会员精选: 未闻 Code 精选内容/会员专属内容/我每周的思考总结/我每周学到的新东西。 曲率飞船: 这里有诚实真挚的人间体悟,有趣独特的阅读新知。 内容导入 用爬虫抓内容 竹白的网站是一个 Web App,所以常规的爬虫抓不到内容。 所以用了 headless chrome 来抓取内容。 例如,如果要获得文章的标题,发布日期等内容,就在 headless chrome 里运行这一段: function get() { const h1 = document.querySelector('h1'); const meta = h1.nextElementSibling; const content = meta.nextElementSibling; const metaSpans = meta.querySelectorAll('span'); let dateString = ''; let premium = '0'; if (metaSpans.length >= 2) { dateString = metaSpans[1].innerText; } if (meta.innerText.indexOf('付费内容') !== -1) { premium = '1'; } const cover = content.querySelector('figure'); let img = null; if (cover) { img = cover.querySelector('img'); } return { title: h1.innerText, date: dateString, content: content.innerHTML, cover: img ? img.src: '', premium: premium, } } 而要获得文章列表,则运行这一段: function getArticles() { const links = document.querySelectorAll('.PublicationPage_item__38S6L'); let freeLinks = []; let paidInfo = []; for (let i = 0; i < links.length; i ++) { const slug=links[i].href.substring(8, links[i].href.indexOf('.zhubai.love')) freeLinks.push(`./quail-prod -c ../../config.prod.yaml import -t zhubai -l ${slug} --url='${links[i].href}'`); const timeEl = links[i].querySelector('.PublicationPage_time__1xXKG') let time = timeEl.innerText.trim() // check the first character is digit or not if (!/^\d+$/.test(time[0])) { time = time.substring(1).trim() } const paidTagEl = links[i].querySelector('.PublicationPage_paidTag__vwcz8') const titleEl = links[i].querySelector('.PublicationPage_title__1pSF4') if (paidTagEl && titleEl) { paidInfo.push({ slug, title: titleEl.innerText.trim(), time }) } } let paidSql = []; for (let i = 0; i < paidInfo.length; i ++) { paidSql.push(`update posts set first_published_at = '${paidInfo[i].time}' where title = '${paidInfo[i].title}' and slug='${paidInfo[i].slug}';`) } return { freeLinks, paidSql } } NOTE 这里对收费文章区分对待,是因为爬虫抓不到收费文章的内容,但是可以抓到收费文章的时间。 于是,对于免费文章,无论是否有竹白提供的导出数据,只要得到了作者授权,就可以无缝迁移到 Quaily 了。 收费文章内容的导入 三月开始,竹白提供了数据导出,可以导出订阅数据和文章数据。 文章数据里也包括付费的文章,但是实际使用这些数据的时候有两个问题: 竹白的导出文章数据里没有文章的发布时间 导出数据里的所有链接都是坏链 于是上一个脚本中,抓取付费文章的发布时间就有用了: 使用竹白导出数据完成收费文章的导入以后,再更新一下付费文章的发布时间,那么文章排序才是正确的。 最终完整的文章导入流程变成: 免费文章:直接爬虫抓。 收费文章:先用备份数据恢复,然后用爬虫抓发布时间,然后更新。 坏链我搞不定,需要作者自己修复了。 订阅者导入 相比内容导入,订阅者导入要简单得多。 竹白导出的订阅信息是一个 csv 文件,大概是这样的格式: 用户名 邮件地址 订阅时间 付费时间 到期时间 累计付费 是否为付费用户 某某 user@space.com 2022-02-09 - - 0.00 否 我有一个专门的脚本来转换各类订阅信息到 Quaily 的 JSON 订阅格式,其中也包括竹白导出的 csv。 但大量导入很容易命中 ESP 的风控,所以这个脚本会把订阅信息拆分成很多份,每一份都是一个单独的 json 文件。 然后这些 json 文件会被提交给 Quaily 的任务调度程序,这个程序会自己去安排导入任务。 调度程序部署好任务以后,会返回预计完成时间,我会把这个时间通过邮件回复给让我帮迁移的作者。 最后,我自己维护了一个 Google Sheets 来记录迁移的进展 一些优化 预迁移 一些作者在竹白上发了迁移公告,还没有邮件联系我,我已经把内容给迁移完毕了。 于是当他们给 Quaily 发邮件时,我会回复内容已经迁移完了,他们会很开心。 这是因为对于新创建的 Quaily 频道,我会得到通知。然后我会去看看竹白上有没有同名的。如果有的话,并且作者声明授权的迁移目的地也对得上,就可以直接迁移了。 这样的体验比较好。 Onboarding 观察了一些作者的使用习惯以后我发现: 竹白似乎不支持完整的 Markdown,所以写了「五分钟掌握 Markdown」来帮助作者们学习 Markdown 不少作者同时经营公众号,那么把微信公众号排版功能介绍给作者 最后挑选了一些中文作者可能感兴趣的话题,在文章「✉️ 给中文创作者朋友的信」一起集中介绍,并在迁移邮件中推荐作者阅读和订阅。 感谢竹白 Quaily 刚刚起步时,就收到了不少竹白作者的信任——像 一石千浪,DEX 周刊 和 AIGC Weekly,都是最初就选择了 Quaily 的几位。也正因为大家的鼓励,我才有了更多前进的动机。 没想到到了最后,Quaily 的导入在竹白下线时也帮到了更多作者。 感谢竹白和竹白的创作者,有了大家,Quaily 才像今天这样具备一定的承载力,也让我有机会遇见你们。 以上。

2025/3/23
articleCard.readMore

⚖️ Function Calling vs MCP:来自开发者的实际对比

👋 在浅浅使用这两种方法一段时间后,我想和大家分享一下 Function Calling 和 MCP 在实战中的权衡考量。 我猜大多数读者已经对 MCP 和Function Calling 有所了解了。所以我就不再赘述技术细节: 场景:身份验证和会话管理 举个例子,我正在开发 Quaily,一个 AI 驱动的 Newsletter 工具。我希望能通过 AI 来发布文章到 quaily.com,当然,这需要身份验证: 使用 MCP 方式: 我可以使用本地程序(也就是 quail-cli)来处理身份验证和会话管理。这样登录状态自然存在于 MCP 服务器也就是 quail-cli 中,登录凭证永远不会泄露给 LLM。 如果凭证过期,MCP 服务器可以简单地强制用户在 quail-cli 中重新登录。 认证和 LLM 处理之间有着清晰的界限,就像把钥匙和锁分开保管,不用担心被偷走。 使用 Function Calling 方式: 显然我不能把 token 或其他登录凭证发送给 LLM:因为存在会话标识符被 LLM 记住的风险,谁知道这些 LLM 会不会偷偷复制一把钥匙呢? 可能的解决方案: 使用超短期 token:比如生成只有 10 秒有效期的 token 甚至强制每个请求使用新 token 以防止重用 然而,所有这些方法都增加了复杂性,而且仍然无法提供与 MCP 架构方法相同的安全保障。根本问题依然存在:使用 Function Calling 时,是在通过一个无法控制的系统传递敏感信息。 商业模式影响 不仅仅是安全问题,还涉及商业模式。一个商业模式基本上是向你的客户或者用户提供一系列有收费站的高速公路,然后从这些收费站赚钱。 比如在 Quaily 中,收费站是对付费内容的访问,商业模式是订阅制。 如上文所述,Function Calling 很难提供与 MCP 架构方法相同的安全保障,所以它也许适合快速构建产品,但难以创建服务边界,这样的商业模式实施起来不说是别扭,只能说很蛋疼。 而 MCP 天生就适合构建访问控制 —— 尤其对那些想做 AI 应用但没有能力构建像 OpenAI 那样基础设施的应用开发者来说,是这样的。 决策:选择 MCP 今天,两种方案都在解决实际问题,但在深入使用两种方法后,我觉得 MCP 更适合大多数场景,以下是我的观点: 安全设计:MCP 的架构从根本上解决了 Function Calling 难以应对的凭证暴露问题 面向未来:随着应用程序的增长,MCP 的模块化架构扩展得更加优雅 清晰边界:数据访问和 LLM 处理之间的分离创造了更易维护的系统 生态系统建设:MCP 可以构建可在应用程序之间共享的能力网络,有利于商业化 你觉得怎么样?欢迎与我分享你的想法。

2025/3/9
articleCard.readMore

📊 在 Google Sheets 里调用 AI,OpenAI/Deepseek/Grok 同时帮你批量工作

English 前段时间,飞书多维表格接入了 Deepseek,很多人用它批量生成文案、批量处理信息之类。 其实 Google Sheets 也可以做到。方法也很简单,只需要按照下面步骤做: 准备工作 首先需要自己准备 API Key。可以是 OpenAI、Deepseek、Grok 或者所有兼容 OpenAI API 的 Key。 申请地址: 供应商 申请地址 OpenAI 这里 Deepseek 这里 Grok 这里 在示例中,我用的 Grok,在 X.AI 可以申请。 让 Google Sheets 启用 AI 打开想要用 AI 的 Google Sheets,选择菜单 Extensions > Apps Script. 复制这段 Apps Script 代码 的内容,然后粘贴到编辑器 点击编辑器的保存按钮,回到 Google Sheet,准备四个单元格,分别输入 API Base,API Key,Model 和 System Prompt。在我的示例中,他们的位置在 $C$2、$C$3、$C$4、$C$5,然后输入对应的值。 我用的 grok,所以他们的值分别是: 变量 值 API BASE https://api.x.ai/v1 API KEY 申请的 API KEY Model 模型的名字 System Prompt 输入系统提示语 其中 API BASE 需要根据选择的 AI 供应商换成对应的地址。例如 OpenAI 换成 https://api.openai.com/v1,Deepseek 换成 https://api.deepseek.com,Grok 可以是 https://api.x.ai/v1 Model 需要根据选择的 AI 供应商换成对应的模型名字。例如 OpenAI 可以换成 4o-mini,Deepseek 可以换成 deepseek-chat,Grok 可以是 grok-2-latest System Prompt 就是自己编写的任务 prompt 了 然后直接在 Google Sheet 里像调用普通函数一样调用 AskLLM 就行。 调用方法是 =AskLLM($C$2, $C$3, $C$4, $C$5, B12) 其中,$C$2、$C$3、$C$4、$C$5 是上文提到的四个固定变量,B12 是需要问 AI 的内容 最终效果如下: 可能的问题和优化 由于请求是从 Google 服务器所在的 IP 发出去的,不确定是不是会被供应商 ban 掉。一个可能比较好的做法是在自己的服务器上进行转发,让 Google 请求自己的服务器。这样从供应商的视角看上去就是从自己的服务器调用 API。 使用时需要在 Google Sheets 里输入 API Key,而 Google Sheets 经常分享给其他人,如果保管不慎可能泄漏私钥。解决的方法要么用完就删除 API Key,要么就在自己的服务器上做一下鉴权。 如果 Google 官方一直没做,那么做成解决方案的话也许能卖 😋。 Google Workspace Marketplace 里面已经有很多了。

2025/2/24
articleCard.readMore

AI 代替人类程序员进度观察表(2025 年 2 月版)

TLDR 选最强模型 既然做简单任务成功率越来越高,那就把复杂任务拆分成简单任务 面向复杂性管理的工程能力依然人类占优,高工程能力能更准确描述需求去挖掘 AI 的潜力 高质量的文档有利于高质量输出,尤其是项目自己的文档 雇佣 AI 程序员的一年里,我一直在寻找在复杂项目中,更高强度的 AI 代替人类程序员的使用方式。 这是 2025 年 2 月的观察进度表和最佳实践。 选最强模型 目前的最强编码模型依然是 o1 pro。我猜测原因是延长 reasoning 的时间和 o1 本身底子好。 o1 pro 很慢,但不算缺点。因为写代码本来也是想得慢写的快。正确和合理相比速度更重要一些。 简单任务最高 在展示大模型编程实力的时候,经常会让大模型编写一个完整的简单任务,例如 ToDo 这样的 App,贪食蛇这样的小游戏。 这样的任务边界清晰,几乎没有与外部系统交互的需求,而且都不是 zero shot,因此完成得非常好。 所以要利用这一优势:一是使用能用到的最强模型;二是描述需求时严格确定边界,用简单任务组合复杂任务。 关于第二点,就是把每一个模块当作第三方:内部逻辑封装;通过接口对外提供服务;依赖的外部资源通过约定的协议获取。嗯,本来也是软件工程的实践目标,所以遵循这个原则的话,也是在提升工程质量。 例如一次典型的开发需求,她的 prompt 可能是这样的: implement a golang module, here are requirements: - requirement 1... - requirement 2... - ... here are interfaces: - method 1... - method 2... - ... here are dummy functions you may needs: - function 1 - function 2 - ... here are criteria: - criterion 1 - criterion 2 - ... 把 prompt 给到 o1 pro,可以得到目前最好的结果。 工程管理得人类进行 现在大模型在应对最高级工程任务和最低级工程任务的任务时表现很好。最低级就是上面说的「简单任务」。 最高级指对整个架构的抽象,角色是一个接受咨询的架构师,向它提出问题,然后得到一些选择,作为参考,可以说很有帮助。 但是连接二者的中间的部分的工程任务,用过 Devin 和 Cursor 的 Agent,现在的大模型处理复杂工程中间的部分依然不太行。 我理解应该有两个问题:一是关于工程的隐含知识没有体现在代码和文档上,方案和架构的选择上也不存在最优解,有很多脏活;二是模型的接受的内容多了以后,缺少明确的边界,幻觉变得严重。 第二个问题的话,可能需要在工程上做更多工作,比如结合静态分析的结果(猜的,我不是语言分析方面的专家),或者别的东西,目的是缩小问题的规模。 第一个问题的话,本质上代码和文档一样的。如果第二个问题不好解决的话,可能光靠补充知识还不行。 IDE 的话,我觉得无论是 vscode, cursor, windsurf 没有本质的差别。毕竟模型能力有限,如果 IDE 最后给出错误的预测,肯定不如 o1 pro 一次成型来得好。 高质量的文档 虽然代码是自解释的,但是有高质量的文档会提升模型对项目的理解和感知。 这一点如果是 mono repo 会很有优势,因为文档本身就在 repo 里,在 IDE 里指定一个 markdown 文件就够了。 基于这个原因,我现在逐渐开始以项目为单位组织 mono repo 了。 替代人类程序员的可行性 同意的 Sahil Lavingia 的看法: No longer hiring junior or even mid-level software engineers. No longer hiring junior or even mid-level software engineers. Our tokens per codebase: Gumroad: 2M Flexile: 800K Helper: 500K Iffy: 200K Shortest: 100K Both Claude 3.5 Sonnet and o3-mini have context windows of 200K tokens, meaning they can now write 100% of our Iffy and… — Sahil Lavingia (@shl) February 6, 2025 而且我也做了类似 antiwork 的事情。比如类似 Helper 的 AI 机器人,类似 Iffy 的反垃圾。 我的实践经验有: 能力强的工程师运用 AI 得当,得到 5 到 10 倍的产出完全没问题。也就意味着,如果公司是以输出技术能力作为盈利方式,那么在需求量不变的前提下,裁减 50%~80% 的人力是没问题的。 复杂度切分得当,在优秀的工程师监督下,AI 持续迭代中等规模的项目是没问题的(以 Quaily 为例,后端部分核心代码大约 1M token) 好消息是不管 AGI 能不能来,LLM 能力的上界足够改变很多很多很多事情。 坏消息是它的下界比很多人类的上界还要高。 更坏的消息是,所有对好消息理解不到位的人,都在坏消息的影响范围内。

2025/2/13
articleCard.readMore

交易事实,而不是交易价格

前段时间开始学一门新手艺,有师傅带的。 虽然上个月已经出师了,但学无止境:要学地缘政治,要学宏观分析,要学货币政策,要学技术分析,要学 Pine Script... 对,我在学做交易。 一直觉得,如果要学一个新东西,除了这个东西本身的价值,最好它能重塑看待世界的视角。因为这样的好处影响更长远,即使这个东西本身可能过时了。 交易事实,而不是交易价格。—— 我师傅如是说。 比如说,一个人可能在 10 万美元卖出比特币,也可能在 10 万美元买入比特币,并不是因为 10 万美元这个价格太贵或者太便宜,而是因为市场的交易结构下,这样的买卖有更高的赚钱概率和更低的赔钱概率。 总之对这句话的理解,我认为是一种决策方式。 即作为一个人类,每次做决策在情感与理性之间徘徊时,要避开情绪、直觉、从众这样表现出较强的「人性直觉」特征;要更多考虑真实发生的事实,剥离情绪噪音,才能做出有利于自己的应对。 交易事实可能违背个人偏好 比如说,在 Trump 大统领发币之前,有一个著名中文 KOL 发币了。即使 KOL 团队运营手法羸弱,这件事仍然自然地引发了相当大的讨论。 既然已经发了,这是事实。 如果有人出于对这个 KOL 的厌恶,跟随直觉地积极去骂他,参加一场又一场的直播,这样做其实是在帮 KOL,是在给他做市。因为 meme 币的特性,其价值不仅源自市值,也来自市场的波动性和投机情绪。 于是反对者也是无意中的市场制造者,负面评论同样推动市场波动,至于波动向上还是向下一点都不重要。 再比如说,Trump 上任大统领这件事,不喜欢的人各有各的理由。但既然大多数美国人选择了他,那这就是事实。 稳定的未来既然已经是奢望,那么就考虑动荡之下怎么发现并捕捉由波动带来的机会,去帮自己或者家人过得好。 交易事实是适应变化 回顾上文「10 万美元」的例子,会发现事实暗示了变化,指变化的市场结构,正如价格暗示了不变,指不变的价格。 考虑到人总在尝试追求确定性,那么追求事实就是追求不确定性,这是与直觉相悖的。 有个说法是一旦到了某个年纪听的歌就会停止更新,来佐证随着年龄增长,跟上世界变化变得越来越困难——这不仅是生理上的适应问题,更是精神和心态上的挑战。 但这是刻板印象。确实因为年龄增长后,一些人因习惯和心理需求而更倾向于稳定、熟悉的文化内容,但更可能是因为时间、注意力资源稀缺导致的,而不是年龄。 比如说一个人,一直没有按事实决策的习惯。如果他有了比较大的生活压力,去探索一个新事物背后的事实的路径成本变得很高,那么他就迅速变得守旧、迂腐、易于被诈骗了。只不过生活压力经常伴随着年纪增大而增大罢了。 交易事实是反脆弱 Purchase on the website to read the full article.

2025/2/5
articleCard.readMore

Quaily 技术架构简介

今天来分解一下 Quaily 的技术架构。先确立几个原则: 不被供应商锁定(vendor-lock-in)——包括不被 cloudflare 锁定,可以随时迁移到 Linux 裸机上。 能减少依赖就少依赖。 能不学新技术就不学。 能满足需求就不雕花。 只在最需要运行效率的场景考虑运行效率。 就酱。现在开始。 路由 打开 quaily.com 就是 Quaily 的首页。这是一个部署在 Cloudflare 上的 Hugo 站点。 但域名 quaily.com 并不是直接指向 Hugo 部署的 worker,而是指向一个负责分流的 worker,叫做 quaily-router 好了。 这个 router 会根据请求的路径等条件,把流量分到下面几个 workers 去 routes = ["quaily.com/*"] services = [ { binding = "front", service = "front" }, { binding = "dashboard", service = "dashboard" }, { binding = "portal", service = "portal" }, { binding = "tools", service = "tools" }, ] 其中 front 和 dashboard 是 Vue 的 SPA,portal 是首页,tools 是 Tools 一个手写的静态站。 同时,quaily-router 还负责处理所有静态资源的请求,包括: 对文章页的请求,例如 https://quaily.com/lyric/p/quaily-technical-architecture-introduction 对文章列表页的请求,例如 https://quaily.com/lyric 对 sitemap 和 feed 的请求,例如 https://quaily.com/lyric/sitemap_index.xml 和 https://quaily.com/lyric/feed/atom 这些静态资源都放置在 Cloudflare R2 里。 所以一次对主域 quaily.com 的完全请求,流量示意图如下: 虽然 quaily-router 用 worker 实现,但如果需要的话,也可以用 nginx 这样传统的方式;而 R2 和 S3 兼容。所以没有被 cloudflare lock in 前端 dashboard 和 front 是简单的 Vue SPA。 其中, dashboard 工作在 quaily.com/dashboard,负责登录以后的所有 UI 业务。 front 工作在除了文章和文章列表以外的所有页,例如 quaily.com/lyric/about 等等。 从上面的示意图可以看出来了,文章和文章列表不是 SPA,也不是后端渲染的结果,而是静态化的 HTML 网页。 这样做的好处是,从开始请求到内容展示的延时小,只需要让 quaily-router 从 R2 读出来然后返回就行。平均延时在 100ms 以内,比常见的内容站点快 3~5 倍。 文章和文章列表上的动态内容(比如订阅表单)通过在 HTML 挂载 Vue SPA 来实现。这些内容的加载需要额外时间,但是在他们加载完成之前,不影响人类和搜索引擎读文章内容和列表。 后端 前端通过 RESTful API 和后端交互,端点在 api.quail.ink,指向一台负载均衡器。负载均衡器使用 AWS 的默认配置,但需要的话可以随时换成 nginx,也不会 lock in。 负载均衡器背后有多台实例提供 API 服务,还有一台 worker 实例处理后台任务。他们其实都是用 Go 写的同一个程序,连接到相同的 postgresql 数据库实例。 完整的前后端架构大概是这样: 运维 数据库备份 通过一个 cron 脚本来完成,每天备份到加密 S3,然后发通知到 telegram 频道。 很多业务通知都会发到 telegram 日志收集 Quaily 所有服务进程都通过 systemd 来运行,日志就是 syslog。所以最简单的配置方法是配置 rsyslog,然后把日志发送到一台集中的日志服务器,放在 /var/log/hosts/HOSTNAME 下。 对于业务实例,配置 rsyslog.conf $PreserveFQDN on *.* @@LOG_SERVER_ADDR:514 $ActionQueueFileName queue $ActionQueueMaxDiskSpace 1g $ActionQueueSaveOnShutdown on $ActionQueueType LinkedList $ActionResumeRetryCount -1 对于日志实例,配置 rsyslog.conf module(load="imtcp") input(type="imtcp" port="514") $AllowedSender TCP, 127.0.0.1, 172.26.0.0/24 template(name="PerHostLog" type="string" string="/var/log/hosts/%HOSTNAME%/%PROGRAMNAME%.log") *.* action(type="omfile" DynaFile="PerHostLog") 需要观察实时日志的时候,把他们合并到一起: multitail -cS slog -f /var/log/hosts/quail-0/quail.log -cS slog -I /var/log/hosts/quail-1/quail.log ... 扩容 因为我不会也不想学 k8s 这样的知识,所以写了一个脚本,只需要运行这个脚本,就可以在一台全新的 Linux 实例上配置好所有内容,包括 systemd,rsyslog 等等。 有时需要批量操作的话,会使用 zellij 的 sync mode(ctrl + t, s),可以同时在一个 tab 下的所有 pane 输入内容。 监控 监控使用的是 uptimerobot 和 sentry。 业务报警使用的是 telegram。 构建 大部分构建使用 github action 完成。少部分在打包机上完成,然后通过脚本上传到实例,类似这样: #! /bin/bash set -e declare -a arr=( "inst-0" "inst-1" "inst-2" # ... ) echo "📦 build..." VER=$(git describe --tags --abbrev=0) GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o quail -ldflags="-X main.Version=$VER -X ..." for host in "${arr[@]}" do echo "📤 scp to $host" scp quail $host:/opt/quail/quail-new echo "🚀 restart..." ssh $host "cd /opt/quail && mv quail-new quail && sudo systemctl restart quail.service" echo "🙆 deployed!" done 于是后端加上运维相关是这样的: AI Quaily 用到了一些 AI 服务,包括 OpenAI 和 Claude.ai 的。因为处理 AI 相关的业务经常遇到一些繁杂的事情,包括重试、负载均衡、格式化、任务路由、CoT 等等,所以这部分工作交给一套单独的服务,包含一个调度器和若干和 proxy 组成,其中: 调度器负责调度 AI 任务。比如这个任务交给哪个 proxy,比如这个任务的 proxy 429 了要重新调度 proxy 负责处理任务,比如一个 proxy 专门处理小任务,就可以交给 4o-mini;另一个 proxy 负责处理文字类任务,可以交给 claude-ai-3-5-sonnet-v2。 大概长这样: 以上就是 Quaily 的技术架构。完整的示意图如下: 封面图源

2025/1/15
articleCard.readMore

做空世界的人们

前些日子,我遇到一位老朋友,他最近在研究因果报应的问题... 他说:你说奇怪不奇怪,我遇到的坏人干尽坏事却活得逍遥自在,都说抬头三尺有神明,神明怎么不收拾他们? Purchase on the website to read the full article.

2025/1/6
articleCard.readMore

大音希声,大象无形

在互联网上,所有涉及到偏好的讨论,都不免引发口水战。 偏好是一种很个人的东西,但如果选择影响的人不仅仅是自己,也包括协作的团队成员,或者公司的利益,或者用户的体验,那么就需要更多的考虑。 无论选择是什么,应该都遵循某一个原则。不同人的原则不相同,对我来说,它是「Worse is Better」。 Worse is Better:简单性的胜利 Worse is Better 是 Richard P. Gabriel 提出的哲学。它表达的是一个系统的设计应该是简单的。如果其他方面的设计会导致系统变得更复杂,那么就应该考虑牺牲它们。 他以 Lisp/Lisp Machine 和同期的 C/Unix 为对比,我列出来给大家看看: 简单 Lisp 认为,设计必须简单,尤其是界面。如果简单的界面需要复杂的实现,可以接受。 Unix 认为,设计必须简单。实现的简单比界面的简单更重要。 正确 Lisp 认为,设计在各方面都应该正确的,不允许有任何错误。 Unix 认为,设计在各方面都应该正确的,但是如果为了简单,允许产生一些错误。 一致 Lisp 认为,设计在各方面都应该一致。 Unix 认为,设计不能过于不一致。有时候为了简单可以牺牲一致性,但最好放弃那些处理不常见情况的设计部分,而不是引入实现复杂性或不一致性。 完整 Lisp 认为,设计应该尽可能地覆盖重要的情况,必须覆盖所有合理预期的情况。 Unix 认为,设计应该尽可能地覆盖重要的情况。但是如果为了简单,可以牺牲完整性。 总之,为了简单而适当牺牲其他方面,是 Worse is Better 的核心概念。 看完这些对比,一般人会觉得 Lisp 的设计更好,但结果 Unix 却更成功。让我们来回顾一下到底发生了什么: 因为 Unix 和 C 的简单,可以在更便宜的硬件上运行,因此可以扩展到 Lisp 无法触及的地方。 因为 Unix 和 C 的残缺,没法一次性构建复杂的单片系统,所以大型项目必须分解成可重用的模块,于是软件工程的概念诞生了,程序改进的速度变快了。 于是「更差的」Unix 和 C 取得了胜利。 Vue vs React: 权衡与选择 半年前和客户的工程师聊天,他问我为什么常用 Vue 而不是 React。我说,用 Vue 心智负担没那么高,例如可以直接在一个 HTML 文件引入 vue,把 Vue 当一个更好的 JQuery 用。 所以使用 Vue,进可以 Nuxt.js 的方式启动一个现代 Web 项目,退可写 Vanilla Javascript,然后用 Vue 来优化开发体验。 这种灵活性,对我来说很有吸引力。因为很多时候,并不需要一个完整的 Web App,也就不需要维护它的依赖,也不需要处理它的复杂性。 Golang:简洁与效率的平衡 在 1.2 以前,Go 都是一个非常无聊的语言(现在是无聊的语言)。 比如说,检查列表是否包含某个元素,别的语言可以写 if item in list,但对 Go,很长一段时间里,是要写一个完整循环。 for _, v := range list { if v == item { return true } } Go 被诟病的错误处理显然也是师承 C。 但无聊也是 Go 的优势之一,比如团队成员之间的代码风格更容易统一,可读性和可维护性都更好(检查列表是否包含某个元素不是一个好例子,所以我们有了 slices.Contains)。 Go 在简洁和功能之间找到了很好的平衡。它可能不是最灵活或优雅的语言,但它的理念使得在构建高效可靠的系统时表现非常出色。 Markdown:简单与功能的权衡 自 Markdown 诞生以来就一直被争议。 一部分观点认为,作为一个标记语言,Markdown 的语法太过简单,不足以满足复杂的需求;缺少标准,导致不同的实现之间存在差异;总的来说,不如 ReStructuredText 和 Asciidoc。 另一部分观点认为,作为一个标记语言,所限颇多,不如更完整的 HTML 所见所得编辑器。 但 Markdown 刚好在一个很好的位置,所以它的流行程度证明了它在简单性和功能性之间取得了很好的平衡。 因为 Markdown 能力有限,所以它是标记语言里最容易学习的,能让「技术小子」以外的人能快速上手,仅凭借直觉也能写,用最基本的语法满足 90% 的需求。这让它几乎变成了可见即所得编辑器以外的「事实标准」,做到了 ReStructuredText 和 Asciidoc 没有做到的事情。 当然 Markdown 不适用精确控制排版的场景和需要复杂表格和图表的文档,对此所见所得编辑器是更好的选择。 但对于大多数写作需求,Markdown 提供了一个很好的平衡。 生物演化:简单带来可能 技术产业之外,生物演化也是 Worse is Better 的绝佳例证。 从简单到复杂 生命最初是从简单的单细胞生物开始的。这些「简陋」的生命形式并不完美,但它们能够生存和繁衍,为复杂生命形式奠定基础。 所以软件开发中,常常从一个简单但可用的版本开始,然后逐步迭代完善。 高度适应的高风险 在生物群体中,基因的多样性看似是一种平庸,但实际上为未来的演化提供了空间。相比之下,那些对环境高度适应、特异性强的生物,比如大型掠食动物,反而更容易在环境变化时灭绝。 在设计系统时,要注意过度设计和适应反而可能会降低适应性。例如,如果系统实现如果 lock in 到亚马逊云服务上,那么当亚马逊云服务出问题时,系统会无法工作。 产品决策也是如此。依附于一个大平台,例如微信生态,也许可以借助平台优势迅速获得发展,但也要面对微信生态中那些不可控的风险,因为它们可能会让人全盘皆输。 缺陷中的优势 有趣的是,某些看似是缺陷的基因可能在特定环境下成为优势。比如镰状细胞贫血基因,携带者虽然有贫血,但对疟疾有更强的抗性。 一些选择和决策,它们可能有一些不足,但在特定场景下却能发挥意想不到的优势。例如: Instagram 最初只允许用户上传正方形照片,这个限制被认为是一个缺点。但这个「缺陷」反而成为了 Instagram 的标志性特征,用户因此更加注重构图,创造出独特的视觉风格。 早期的 Twitter 限制每条推文只能有 140 个字符,这个限制最初被认为是一个缺陷。但恰恰是这个「缺陷」促使用户更加简洁和创造性地表达,也让信息传播更快速。这个特性后来成为 Twitter 的标志性特征,塑造了一种独特的社交媒体文化。 所以不够完美并不意味着失败。相反,它可能为适应性和长期生存提供了更多可能性。在技术选择和产品设计中,一个简单但灵活的方案可能比一个完美但僵化的方案更有生命力。 最好的设计,往往是那些用户感受不到的设计;最实用的工具,常常是那些不引人注目的工具。大方无隅,大器免成,大音希声,大象无形。 Purchase on the website to read the full article.

2024/8/18
articleCard.readMore

对比一下 Macbook Air 和 Framework 13

上周发了一篇《入手 Framework Laptop》。当时把数据迁移到新机器以后,就干活去了,所以这篇文章被说太短了。 这次就补一些内容,主要拿手头的 Macbook Air M2 来对比一下。 价格 Framework 13': $1,640.00 AMD Ryzen™ 7 7840U with 16‑core CPU, 64GB RAM, 1TB SSD Macbook Air M2 13': $1,599.00 M2 chip with 8‑core CPU, 16GB RAM, 1TB SSD 外观设计细节 虽然远看二者很像,都是相同的金属外壳,手感也接近。 左 Framework,右 Macbook Air 左 Framework,右 Macbook Air 但是细节处理上,Macbook Air 比 Framework 13 好。举几个例子: 左 Framework,右 Macbook Air 上图 Macbook Air 的 Laptop Bezel 也就是屏幕边框和屏幕看上去是一体的,外壳紧接一块玻璃,玻璃下面是 Bezel 和屏幕。这样做给人的感觉是屏幕边框小而且规整,接缝也不明显。而 Framework 13 的 Bezel、外壳、屏幕,有明显接缝,并且 Bezel 的塑料感拉满了。 左 Framework,右 Macbook Air 对比上图的摄像头区域更明显。 左 Framework,右 Macbook Air 上图所示的屏幕转接处,Macbook Air 要比 Framework 13 的处理要干净利落些。 下 Framework,上 Macbook Air 上图对比键盘面的外壳,Macbook Air 是没有接缝的,Framework 13 有一层接缝(注意 Framework 合盖以后中间黑色的区域是 Bezel,不是缝隙)。 屏幕 尺寸 分辨率 PPI 亮度 Framework 13 13.5 2256x1504 201 400 ~ 500nit Macbook Air M2 13.6 2560x1664 224 500nit Framework 13 的屏幕比 Macbook Air 稍差一点点(我肉眼对比也是如此结论),但不多。但现在可以预购新款 2.8k 的新屏幕,分辨率能到 2880x1920,刷新率能到 120Hz。 不过我日常使用时都外接了一个 4K 屏幕,所以就不考虑了。 WARNING 这个 2K 屏幕在 Gnome 上如果不开启 Fractional Scaling,只有 100% 和 200% 两个缩放比例。如果开启 Fractional Scaling 的话,我感觉 125% 或者 150% 应该是最佳的比例,但是有一些 bug 会导致一些问题。 实际操作的时候,不开启 Fractional Scaling,保持 200% 缩放,然后开启 Accessibility -> Seeing -> Large Text 会是比较好的效果。 重量 重量 尺寸 Framework 13 2.9 磅 11.67x9x0.62 英寸 Macbook Air M2 2.7 磅 11.97x8.46x0.44 英寸 Framework 13 要比 Macbook Air M2 重一点,长一点,宽一点,厚 30%。 但我觉得二者都有点重,因为我上一台机器 Dell XPS 13 只有 2.59 磅。 CPU 类型 核数 Framework 13 AMD Ryzen™ 7 7840U 16 Macbook Air M2 Apple M2 chip 8 不太懂这些,所以放一个别人家的数据对比 供参考。看上去除了能耗以外都是 Framework 13 胜出。 内存 容量 Framework 13 64GB Macbook Air M2 16GB 这是我本次升级最大的动力,大内存真的太好了。 电池与续航 容量 Framework 13 61Wh Macbook Air M2 52.6Wh Framework 的电池容量大不少。按照官网说的,all day battery life, long-lasting。x86 的能耗不如 Arm,而且 Linux 的电源管理一直都比较差。我猜测相同水平下 Framework 的续航可能还是比 Macbook Air 差。 但我日常都在外接电源,所以不太在意这些区别。 WARNING 长期外接电源的话,BIOS 里有个设置可以调整电池的充电上限。这个设置的说明里解释说这样可以延长电池的生命周期。 键盘 键程 Framework 13 1.5mm Macbook Air M2 1mm 程序员可能会比较在意键盘的舒适度。Framework 的键程比 Macbook Air 长,回馈好一些。另外 Macbook 的按键面积会稍大一些。 但我日常都在使用外接键盘,所以不太在意这些区别。 扩展能力 耳机孔 USB-C USB-A Framework 13 1 3 1 Macbook Air M2 1 2 0 这是 Framework 13 的长处,四个扩展卡槽可选的范围很大,从闪存到 USB 接口 到 HDMI 到读卡器到网口都有。 我这次特地选了一个 USB-A 因为连接旧设备很方便。 其他 Framework 13 提供了摄像头和麦克风的硬件开关 虽然不是真的把摄像头挡住,但大概也不是软件层的关闭吧。 Apple 把 Magsafe 又加回去了 想诟病的是 Apple 这次宁可又把 magsafe 加回去也不愿意多加一个 USB-C 真是让人怀疑它是不是真的在清理库存。 操作系统 虽然 Alpine Linux 说是支持 M 系列 CPU,但是...买 mac 的机器换 Linux 的行为应该不多见吧... 如果一个行为不多见,那么支持力度可能有限,出问题解决起来估计也麻烦。 何况我本来就是用 Linux 的,所以 Framework 13 胜出。 最后放个桌面:

2024/6/20
articleCard.readMore

入手 Framework Laptop

下单 作为 Made in 台湾 的商品,居然不发货到日本,打开 frame.work 的官网会提示: 别管它, 开美国的 VPN 填写美国的收货地址 使用美国信用卡付款 是能成功下单的(如果不能,或者被退单了,说明被风控了,请换成它支持的地区的地址和信用卡)。 定制化的部分: 没有买电源,用自己的 Anker 供电就行。笔记本的电源都太粗笨,不买是环保 扩展槽选了三个 USB-C 和一个 USB-A 其他都是默认选项 接下来就是托幼馴染把机器带回来就行了,非常简单。 安装 想要 AMD 的高配机型,选择了 DIY 版本。说是 DIY 版,但实际上对 DIY 的要求几乎没有。只需要按照说明,把硬盘、内存、键盘插上就基本完成了。 先上个图 体验 作为极客向定制品牌,Linux 兼容好,真方便。 内存大就是好,不需要 Swap 分区了,真方便。 Snap 程序迁移只需要把整个 snap 目录拷贝到新机器就行了,真方便。 特意买了一个 USB-A 的扩展槽,真方便 —— 虽然现在大家都 pro USB-C,但还是很多东西是 USB-A 的。

2024/6/14
articleCard.readMore

对几个邮件服务商的观感

因为对发展路径的依赖,Email 在海外有非常重要的地位,这个地位就像是中国的 QQ 和微信一样。如果要做面向全球的产品的话,Email 是绕不过去的一环。 今天来简单讲一下对各个邮件服务商的观感,以使用量排序。 @gmail.com ⭐⭐⭐⭐⭐ Gmail 是最强的没有之一。 Gmail 有最强反垃圾 一个前置知识:邮件服务的反垃圾风控系统经常围绕发送的频率(IP、域名、发件人多维度)、用户报告垃圾邮件行为、第三方邮件监控系统的来设计。 对,大部分其他邮件服务商都这样,但我观察 Gmail 肯定不是。Gmail 似乎有基于内容的反垃圾策略,并且这个策略的优先级要高于上面的硬指标。 很显然,细分策略一定比硬指标好,所以 Gmail 有最高的送达率,最低的垃圾邮件率,以及最低的误报率。 Gmail 的服务最稳健 从爆发性发送的情况来看,Gmail 很少触发频度限制。而其它邮件服务商很容易看到各种频度限制的错误。尤其是一些小服务商,下面会介绍到。 另外,Gmail 从没有出现过任何技术性投递问题。典型的包括 stmp connection failed,time out 等等。主打一个稳健可靠。 Gmail 的态度最专业 这体现在很多细节上。 比如说,Google 提供 PostMaster 让你去监控邮件的 spam 取样情况,这对于邮件投递商做监控处理问题很有帮助。 再比如说,Google 会推进很多标准来尝试缓解垃圾邮件的问题。就像 RFC8058 的一键取消订阅。目前那么多邮件服务商只看到少数几个跟进。 @qq.com,@foxmail.com ⭐⭐⭐⭐ 国内用量最大的邮箱,也是国内邮件服务质量最稳健的邮箱。 我观察下来大概相当于一个低配 gmail。如果要选择国内邮箱,请选择 @qq.com。 如果要说有什么问题的话,我觉得就只有一个:它是一个中国的邮箱服务。 @163.com,@126.com,@sina.com ⭐⭐⭐ 网易系和新浪邮箱,真的不太对的起老派邮箱服务商的牌子。 各种 stmp connection failed,time out 的情况比 QQ 邮箱多多了。 补充:网易的朋友联系到了我 很快有两位网易的朋友联系到了我,希望帮我解决问题。于是我就把遇到的情况跟他们说了下。 @outlook.com,@hotmail.com,@live.com ⭐⭐ 很多人使用微软系邮箱,但是微软系邮箱其实挺拉垮的。我来说两件事: 一是微软的反垃圾经常误报 ban 掉微软自己的发的邮件。 二是微软搞了一个类似 Gmail Postmaster 的东西叫 Microsoft SNDS,目的是降低垃圾邮件困扰。 但这个 SNDS 的策略非常的莫名其妙,一旦被加入到微软的 Blocking List,很难移出。很多人都在抱怨这件事,比如这里。 而微软官方提供的工具,无论是 PostMaster 还是发 Support request,你只会收到机器人应答告诉你「一切正常」;如果有幸能收到人类应答,也不会去跟进后续的工单。 @icloud.com,@me.com ⭐⭐ Apple 系主打一个金玉其外。 我自己在 icloud 上丢过数据,也见识过身边很多案例在 icloud 上丢过数据,或者被 icloud 弄坏过数据。 Failed to load twitter from https://twitter.com/lyricwai/status/1767369534418428033 所以,我对 icloud 云服务的态度一直很明确:不想当傻逼。 对 icloud 的邮箱服务的立场,自然也包含在内:不推荐。 首先,icloud 对于投递问题的处理是最不透明的。如果遇到问题,别人家会告诉你哪儿出问题了;而 icloud 继承了 Apple 一如既往态度,只会告诉你一个地址:https://support.apple.com/en-us/102322 。至于具体什么问题,诶,您自己去研究吧。 其次,icloud 在一些概念上也是最会把人当傻逼糊弄的。 比如说 icloud 吹的这个 Protect Mail Activity,说是可以避免被追踪行为。 我可以负责任地告诉大家,这个功能是个摆设。开不开都能随便追踪。 各类匿名收信服务 ⭐⭐⭐ 包括 readwise.io, inbox.omnivore.app, m.cubox.pro, kill-the-newsletter.com, duck.com,都差不多。 最大的可能的坑就是无法发信,需要自行鉴别(duck.com 是可以发信的,没有这个问题)。 另外就是很多这种服务都不咋稳定,各种 stmp connection failed,time out,try again 的情况很多。 嗯,这种错误多了,是会丢邮件的。 @protonmail.com ⭐⭐⭐⭐⭐ Proton Mail 异乎寻常地可靠和稳定,仿佛一个小版本的 gmail。 对待隐私的态度也比 Apple 要实在得多。如果使用 Proton Mail,默认情况下确实是无法跟踪邮件行为的。 而且 Proton 也是目前列表里唯二支持 RFC8058 一键取消订阅的服务商(另一个是 Gmail)。 大概先说这几个,以上。

2024/3/18
articleCard.readMore

看不见的费用:「手续费们」都是怎么来的

免责声明 本文中提到的具体费率和政策,最佳做法是直接查阅服务提供商的最新官方资料,因为这些信息可能随时间而变化。请毋以本文提到的数据作为决策依据。 做一个知识匮乏的人是很幸福的,所谓的「知识的诅咒」就是这样。 比如说 Nikkei Asia 每年都会拆解 iPhone,去年拆解 iPhone 15 时就说估计零部件成本在 432 美元,粗暴计算按最低配 799 元的售价,卖一台就能赚 376 美元。 虽然 Nikkei 不会有舆论引导,但是这样的计算被其他媒体渲染一下就变成了 Apple 资本家真会赚钱,卖一台手机赚的钱可以约等于白造一台——但这怎么可能嘛。 于是今天来给大家讲一些费用到底是怎么来的,降低一些大家的幸福感。 首先说一点,在市场化的今天,能长期存在的费用——我们说一个费用便宜或者贵,都是 trade-off 的结果。 微信零钱和支付宝提现要付费 从 2016 年开始,如果从微信零钱包(也就是收微信红包以后钱进入的地方)提现到银行卡或者还信用卡,超出 1000 元会有 0.1 元的手续费。 其中「超出 1000 元」是累计的。如果每次提现 1 块钱,提 1001 次,其中前 1000 次没有手续费,从第 1001 次开始,实际到帐 0.9 块钱。 支付宝提现到银行卡也是类似的费用,具体可以参考这里 很多人觉得这是微信和支付宝要赚钱,毕竟「银行账户之间直接转账都是免费的」。但是从微信/支付宝到银行账户,与银行账户互相转,是两回事,不能一起比较。为了方便理解,我简化了描述,可能有不准确的地方请见谅。 首先微信的公司不能管理钱,因为它不是银行。微信钱包里的钱实际上是托管到银行账户里。于是大致理解成腾讯在银行开了账户,所有人的微信钱包的钱都在这个账户里。 当发起零钱提现时,实际做的是从腾讯在银行的企业账户往用户的个人银行账户转账。此时,会根据不同的银行、不同的渠道、不同时间,银行会收取不同的手续费。所以「个人账户之间转账免费」是无法推导出「企业银行转账免费」的。 既然零钱每次提现都是企业银行账户转账,自然会产生费用。这费用转嫁到用户身上完全合理——毕竟使用微信转账这么方便,在其他方面就要付出代价,这是一种 trade-off。 每次买东西都付费 还是以微信为例(支付宝也是类似的)。 先说明一下,微信 App 里的钱包不属于微信支付。那个叫「收付款」和「钱包」。 那你可能要问,那在外面买东西说的「用微信支付」这句话到底是什么?其实这句话指的是「使用微信支付这个商品」这个动作。 支付发生时,背后比较复杂,大致有三种情况: 如果店主出示的是微信个人号,就是扫码以后让你加好友,然后转账:这种情况本质上是转账,和朋友之间的转账没有区别,免费。 如果店主出示的是微信收款码,扫码以后显示的是他个人的头像,这种情况很像转账,虽然目前也可以当作转账来看待,但实际上这个场景属于经营行为,虽然是支付,但是目前按照我的理解它不属于「微信支付」。 如果店主出示的是微信收款码,扫码以后显示这个店名或者商品名,这种情况是支付,此时店主使用的是「微信支付」。 总之,微信支付是一个面向商家的产品。如果开店让顾客用微信付款,那么这个店家需要接入微信支付,店家是要付费的。而且有明确的费率,可以查看官方说明:简单来说,除了学校和公共服务缴费的费率是 0,其他行业的费率在 0.2%~1% 之间,最常见的是 0.6%。 你可能要问,那使用上面的 1 和 2 两种途径不就行了? 很遗憾,不行。如果只是做一个小小的生意,个体户——或者连个体户都没注册,直接使用 1 和 2 收少量的钱是没问题的。但只要是开了个公司,都只能用途径 3。现在商业环境下,大家买的东西,出门吃的饭,点的外卖,送的快递,大部分都是途径 3。 也就是说,出门买个吃个饭,花了 100 块钱,店家收到 99.4 块,微信抽 6 毛。 有人可能觉得微信这钱赚得好容易啊,但其实这笔钱中的大部分都是要付给银行的。为啥呢,刚才已经说了,微信是不能直接管钱的,钱得托管到银行,而操作银行账户资金是要付费的... 比如说吃饭付钱是走的银联的银行卡,那么这笔交易需要向银联支付 0.6% 左右费用。 看看海外 前段时间有个新闻讲的是微信这 0.6% 把一些大学搞不爽了,于是微信下调了教育机构的收费到 0%... 其实如果对比海外,中国这些支付的费率是相当低了。 以 Visa 和 Mastercard 这两卡组织为例,使用他们消费的话,商户要支付 1%~3% 左右的交易费。按照 1.75% 计算的话,出门买个吃个饭,花了 100 块钱,店家收到 98.25 块。 问题1:这么贵那为啥店家还要用呢? 诶好问题。有几种情况: 确实很多店家就只收现金。在美国和日本的一些小餐馆很常见。 支持信用卡可能会给店家带来额外的顾客。比如说很多旅游地都会在店面上贴上「accept Visa」这样的标识来吸引游客。游客现金不一定够,但肯定有信用卡。 可以降低一些运营成本。比如一些线上服务,如果不用卡通道的话,可能需要通过寄账单要求汇款或者寄支票的方式来收款——这很麻烦,运营成本很高,宁愿付 1.75%。 问题2:这么贵那为啥消费者还要用? 虽然看上去使用信用卡消费有更高的成本,这些成本店家也会转嫁给消费者,但作为游戏的一部分,玩得好的话成本并没有那么高。 比如说,在日本和美国,很多信用卡都有返现或者返积分这样的操作。比如说我手头的卡就有常驻返现 1% 的版本,也有常驻返积分 1% 特定情况返积分 4% 的版本。 如果返现 1%,那么相当于实际信用卡成本就降低了到了 0.75%,和微信差不多了。当然,如果是返积分并且积分没消费就过期的情况,对于银行来说就是额外盈利。 问题3:支付现金和使用信用卡一个价,那岂不是支付现金亏了 对,相当于支付现金的人为溢价买单了——这也是使用卡的另一个理由。 高昂的互联网支付成本 由于信用卡是美国消费金融避不开的角色,因此像 Paypal,Stripe 这样的互联网金融服务也很难降低费率——像微信支付这样低于 1% 那几乎是不可能。 Paypal Paypal 是一个著名的支付结算商,收费很复杂,具体可以看文档。它同时提供账户之间的转账(就像微信钱包转账)和面向商户结算(类似微信支付) 其中,个人之间转账如果是美国国内,大概率不收费;如果是跨国转账,收取 5%。也就是说,我在日本,你在美国。你给我转 10 美元,我收到 9.5 块,Paypal 拿走 5%。 对应的商户支付结算,开个店然后收款这种,类似「微信支付」的情况,费率大都在 3% 左右。如果跨货币还有额外的货币转化费。 也就是说,网上买个东西,顾客在美国,商户在日本。如果商品 10 美元,通过 Paypal 付款,然后店家大概收到 9.6 美元,转换为日元是 1395 日元,按照 Google 的汇率折合 9.29 美元 Stripe Stripe 是海外很多商户都会使用的结算商,类似微信支付。它的结算费用不同国家不太一样,比如美国是 2.9% + 30美分,日本是 3.6%——但也有额外的消费税和货币转换费。 举个例子,对于日本来说,如果使用 Stripe 收款 10 美元,那么首先转换成日元大概 1471 日元;然后 Stripe 会收取 53 日元作为结算费用,然后在月末还会收取其中的 10% 也就是 5 日元作为消费税。 也就是说,网上买个衣服,一个订单 10 美元,这个日本商家收到了大概是 1471-53-5=1413 日元,按照 Google 的汇率折合 9.41 美元。 权衡 本地的支付通常更便宜,这是显然的。 比如在日本使用 JCB 渠道而不是 Visa,他们的交易处理费就是 0.6%~1.6%;类似地,如果在日本使用 Paypay 来代替 Paypal 和 Stripe,那么费率可以下降到 1.6% 到 1.98%。 便宜是便宜了,代价是什么呢? JCB 和 Paypay 几乎只能面向日本本土服务,指望外国游客拿着 JCB 信用卡来日本旅游或是外国顾客用 Paypay 买日本在线漫画这种事情几乎不可能。 对于商户来说,如果只服务本地的顾客,当然可以用本土的支付服务。但如果要面向全球,那也就意味着要付出对应的代价。 这就是在一开始说的 trade-off 的结果。 税 在大部分国家,每一笔交易其实还有一块大头,税。比如说日本消费税默认是 10%,德国默认是 19%,波兰默认是 23%。 回到我们上面的例子,一个商户在网上卖一个东西 10 美元,如果这个商户注册在日本,顾客实际要支付 11 美元;如果商户注册在德国,需要支付 11.9 美元;如果注册在波兰,需要支付 12.3 美元。 于是我们就得到了含税价,11 美元(日本)或者 11.9 美元(德国)或者 12.3 美元(波兰)。 在大多数国家,含税价和非含税价都要求展示给顾客看。于是在国外我们能看到这样的小票: 或者这样的标签: 中国也有增值税,税率有 6%,9%,13% 三档。山姆会员店刚开的时候本来也是打印在小票上的,就像这样: 但是后来为了减少给群众心灵带来的冲击,跟其他商户一样都不打印到小票上了。但是不打印不代表没有,只是从看得见的费用变成了看不见的费用。

2024/2/18
articleCard.readMore

伟大的巫师经常独自行事,只要空气中的元素依然回应他的咒语和呼唤

Clarke's Third Law: Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke 昨天晚上搭档跟我讨论 AI 可能对娱乐行业带来怎样的冲击时,我突然意识到克拉克第三定律 有另一种理解: 虽然发展新科技需要继承旧科技,但就像操作系统和编程语言有 Support Lifecycle 一样,旧科技是会因为失去用户而失传的。当一个旧科技失去用户后,它确实跟魔法没有区别了。 比如说,在一万年前,钻木取火是每个家庭必备的手艺,但现在只有很少的人能做到钻木取火了。取火对木头材质、火绒质量、环境条件、技巧手法乃至体力都有较苛刻的要求,这些信息对于普通人来说,不再是常识,变成了只会出现在野外生存指南里的内容。 就像现在我看 Primitive Technology 的视频时,虽然知道原理就是磨擦生热,但这种随时随地可以在几秒内生火这种操作,就像魔法一样。 旧科技和旧手艺失传 最近很多关于原画师们即将失业的讨论也表现了这一点。 对于画家/画师而言,他们的工作本质上是创作作品,而作品需要把心中所想通过画面表达出来。 受限于表达过程,致力于艺术创造的人们往往需要在绘画技巧上花费很多年的练习,才能满足创造作品所需的「表达想法」技巧需求。所以「磨练绘画技巧」这一中间步骤反而成为「画家」这一职业名字的一部分。 但是现在,通过 AI 们:比如现在流行的 Midjourney 或者 DALL·E 3,画家们可以跳过「磨练绘画技巧」这一步骤,直接把想法转换为作品。 如此的话,对于绘画技巧而言,就不再是画家的「必备技能树」上的一环,去磨练绘画技巧的人会变少,那么逐渐地,执笔绘画的技巧会逐渐失传。 AI 显然会导致一大波科技和手艺进入这个版本的淘汰圈。 职业融合 更进一步,画家产出的绘画艺术作品,满足的仅仅只是「视觉」这一感官的需要。但是伟大作品不应该致力于同时满足所有感官吗? 艺术家们当然想,但是以前很难做到。艺术家们受限于时间、技艺、教育、和表现形式,去创作一种同时满足「视、听、味、嗅、想象力」等所有感官的艺术作品太难了。 刚才提到的,艺术家需要磨练自己在操纵感官上的技艺。假如光是磨练一笔好画的技艺需要练 7 年,那么人的一生有几个 7 年可以用来练肌肉技艺呢。另外,创造满足不同感官的艺术作品需要学习对应的知识和理论。艺术家们能在磨练技艺之外留出多少时间去了解这些呢。 但在 AI 的帮助下,从一时间牢笼中释放出来的艺术家们将有机会创造这样的作品,不再局限于具体的形态、也不再局限于自己的技巧,他们只需要关于艺术的领域知识——甚至不需要是完整的领域知识。 于是,哪些依赖技艺而被拆分的职业得重新融合或者取代,新职业必须更接近最终目的,而不在乎中间步骤。 什么都懂的胜利 对于平庸有一种描述叫做「什么都懂一点,什么都不精通」。 现在,这种平庸不一定是坏事。如果一个人的领域知识广度足以覆盖整个行业,而深度恰好多于「能够评价任务执行的好坏与否」的程度,就可以比较好地操纵 AI 去完成那些本来需要好几个不同职责的人去完成的事情。 比如说电影。导演是那个对故事、还场景还原、对角色塑造、对剪辑要求最高的人。他的这些要求也就这些也催生了对造型、物料、美术设计、摄影、灯光等技术层面的要求。 只有团队中的不同角色,满足了对于技术与非技术方面的知识掌控,才满足导演对整部影片综合控制的需求——所以,即使电影是导演和团队一起拍的,但大家依然会认为一部电影是导演的个人作品。 所以,导演就是整个电影拍摄团队中具备最完整领域知识的人。 于是这种领域知识的完备,可以让他可以开始使用 AI 代替电影团队中的其他人,跳过其他职能培养过程中的所有花销,直接看最终成品。 以灯光为例。这位导演可能不是很懂具体灯光要怎么设置,但是他得很清楚自己的场景中需要那些角度,什么氛围的灯光,于是他可以用专业的语言告诉 AI 自己想要的结果,让 AI 做出更合理化的建议,并且输出到成品中供自己的检查。 如此这样,未来的导演团队里还需要专业灯光师吗?可能还需要,不过数量会大大下降,职责也会发生变化。 于是我们可以预见,也许很快就能看到仅由一个人完成的电影作品出现。 在科技公司里也会发生类似的事情。在 Sam Altman 在和其他人的赌约 里表达了这样的态度之前,我和我身边的朋友已经在实践这个可能性了半年有余了——结果是完全可行。 以 Quail 为例。到目前为止,Quail 依然只有我和 AI 两位程序员,其中后者可能贡献了一半以上的代码。我也在提供 Tech Consulting 服务。在 AI 的帮助下,这个服务展开所提升的效能比研发更高,预计要比没有 AI 的时候高 10 倍以上(传统意义上的 Consulting 是一个很难横向扩展的业务)。 而我身边的一位老朋友,零客户端编程经验,AI 的帮助下从零开始做一个 ESL 程序,还编写了对应的方法论,已经获得了几千种子用户。 从这个角度看,去争论自己手里哪些事情是 AI 做不了的并引以为豪,是一件在未来可以引以为憾的事情。 你可能会问,难道公司给程序员付的薪资里,有一半都实际是 AI 的产出吗? 首先,这个公司可能不一定会付给这个程序员薪资了。 其次,如果公司依然愿意付钱这个程序员,那么这一半产出买的是他的领域知识,买的是他向 AI 提出合理问题和请求的能力。 知识就在那,但是需要你念出咒语才能让它显形。 思路打开 在人类历史上第一篇赛博朋克小说《真名实姓》 里提到的互联网终端「Portals」很类似于现在 Apple Vision Pro 和未来脑后插管的结合体。不过它很省带宽: You might think that to convey the full sense imagery of the swamp, some immense bandwidth would be necessary. In fact, that was not so ... A typical Portal link was around fifty thousand baud, far narrower than even a flat video channel. 您可能認為要傳達沼澤的完整感覺圖像,需要巨大的頻寬。 事實上,事情並非如此… 典型的 Portal 連結約為五萬波特率,甚至比視訊頻道還要窄。 Portals 实际提供的是暗示,就像是舞台上的提词,具体的行为和情绪需要演员来呈现一样,Portals 里体验到的丰富的感官刺激来自于大脑对这些暗示的想象和补全。当大脑对现实世界和虚拟世界的体验都够多时,它就能理解这些暗示,渲染出最好的虚拟世界。 本质上 Portals 是在给大脑喂 Prompt,然后让大脑去挖掘合适的场景渲染给自己。 现在,我们需要做类似的事情,给 AI 提供 Prompt,从中挖掘出我们需要的知识。这样的过程本身也非常神秘学。就像《真名实姓》里说的: Ultimately, the magic jargon was perhaps the closest fit in the vocabulary of millenium Man. 伟大的巫师经常独自行事,只要空气中的元素依然回应他的咒语和呼唤。

2024/2/13
articleCard.readMore

不要总去人均 500 以上的地方吃饭

之前在大手企业里打工的时候呢,有一次和大领导同步方案。我不是方案的撰写人,只是同步方案的时候,组里的人都要到场,所以我也在场。 頃に、大领导听完方案以后,沉默了一会儿,转向我的组长,放下雪茄的同时,唇缝里蹦出来几个字:「你不要总去人均 500 的地方吃饭」。 做产品设计,除了技能加点得像魅魔似的以外,还讲究一个环境熏陶: 比如说 Apple 是业内的榜一大哥,那自己就得用 Apple 全家桶。理由是 如果没用过最好的东西,就不可能做出最好的东西。 话这么说是没错,但如果忘了自己只不过是那个最高的浪头上那位幸运儿,这样由己推人的话,跟何不食肉糜就没有区别了。 在上海封城前夕,城市进入了吃鸡模式。每天会听到某个小区被封了。 有一天搭档打车下班回家,看到滴滴师傅车后面还放着行李箱,就问怎么还带这么多行李开滴滴。师傅说,家里小区封了,不能回去,这几周都在车上过。搭档说,为什么不回家睡呢?师傅说,不开滴滴就没钱了。 搭档突然才明白,并不是所有人都像她似的,在家也能工作也能赚钱,更多人只要被困在家里,就等于每分钟都在往窗外丢沓毛票。 与其说《北京折叠》是科幻小说,不如说是现实小说。 有次去 LA 拜访朋友,我问他怎么看待流浪汉的问题。他正开着车,于是指了指车窗,说:只要出门都开车,你在里头,流浪汉在外头,他们就不存在。 这席话让我想起之前有个失联很久的猎头来找我聊天,说自己欠了小贷还不起了,不敢跟家里人说。一听,大概 20 来万。 折叠呢,既发生在北京,也发生在 LA。

2024/2/11
articleCard.readMore

关于邮箱的一些冷知识

做 Quail 一段时间了,经常要跟邮箱啥的打交道,发现一些事情还挺有意思,分享给大家。 很多很多人拼错自己的邮箱 常见的错误包括: 把 .com 写成 .con,.cmo,.cm,.comm 把 gmail 写成 gmial,gmal,gmmail,gmil,gnail 把 qq.com 写成 q.com,qq.cn 所有这些情况,是显然收不到邮件的。因为这种情况被判断出来以后,都不会尝试去发出邮件,自然也收不到了。 另外还有拼错自己的邮箱前缀的(也就是 @ 前面的部分)。这种情况有一部分也是能判断出来的,也会导致收不到邮件。 收件邮箱也是有评分的 很多邮件发送服务会提供 Email Validation 服务。比如 Quail 用的 Sendgrid 和 Mailgun。以 Sendgrid 为例,提供一个 Email 地址可以得出以下判断: 判断这个地址能不能发邮件:可发、有风险、别发 得分:当地址被识别为「风险」时,得分越低风险越高。风险高的话,邮件就可能不发了 详细情况,包括并不限于下面的原因: 没配置 mx 记录 是一次性地址(下面会提到) 这个邮箱之前有拒收过邮件 域名很少见 域名太新 这个域名下面发了很多垃圾邮件 顶级域名有风险(下面会提到) 邮箱不存在(一般常见于把自己邮箱拼错了) 所以不仅仅是会给发邮件的人评分,发邮件的人也会给收邮件的人评分的。 用特殊域名会降低邮箱可信度 现在很多新潮域名,比如 .xyz ,.cf,.cloud 什么的。 使用这些域名作为自己的邮箱域名的话,是有一定的风险的。 有的域名整体风险偏高。如果没有设置好邮箱配置,或者域名对应的网站没弄好,或者 TLS 没做,那么可能会一些邮件验证服务认为是高风险,然后被邮件服务拒绝发送。 因为邮件服务(比如 Quail)为了维持自己发信服务的 Reputation,对于这些被认为高风险的邮件地址可能会直接不发邮件。 使用临时邮箱 现在网上有很多临时邮箱和临时手机号收短信服务。如果用他们来注册的话,也可能收不到邮件或者短信。 因为这些也是可以被检测的。也是出于维持自己发信服务的 Reputation 的原因,不会向这些地址发邮件(Quail 就是)。因为发了也没有意义。 邮件中继服务会被认为是低、中风险 典型的包括 kill-the-newsletter.com,readwise.io,omnivore.app,ino.to 还有 Apple 的 privaterelay.appleid.com 。不是说他们不好,而是他们确实会被刚才提到的 Validation 当作中、低风险,降低得分。 如果发信服务有自己风控策略,因为这类服务较高的风险等级,可能就收不到邮件。 很多人的邮箱满了 听上去有点不可思议,这年头邮箱居然会满的吗?从发送情况来看,我发现一些人的邮箱已经满了... 自然就收不到邮件了。 来自东方古国的神奇网络故障 常见于新浪、QQ、网易邮箱。有时候他们会莫名拒收,拒收的原因据我观察有: 超时:这种情况直接收不到邮件。 发送成功,但收件箱里没有邮件:这种情况常见于邮件内容里有写古国不喜欢的东西。 以上。 文章里说的都是站在读者的角度的事情。作为发邮件的服务,比如 Quail 这种,需要注意的问题就更多了。如果你也在做发邮件的事情,遇到一些麻烦很难解决,可以问我,也许我能帮到你。

2024/2/4
articleCard.readMore

Mixin Safe 安全分析

Mixin Safe 是 Mixin Network 在去年就公告要进行升级的资产管理框架,在去年 9 月被黑客攻击之前测试网已经在运作了,但是并没有上线实装。 考虑到发生了黑客攻击事件,未来尽快实装 Mixin Safe 肯定是一件迫在眉睫的事情。这里需要注意的是,Mixin Safe 不是一个 Mixin 主网的升级方案,而是一个有主网参与的独立的资产保管解决方案。根据它的介绍,任何个人和组织都可以通过使用它来增强自己在 Mixin 上的资产安全性。 也就是说,Mixin Safe 是一个可选套件:无论你是机构还是个人,如果希望增加安全性,就可以使用它。另一个说法则是,默认情况下,如果你只是使用 Messenger,不会直接从 Mixin Safe 受益。当然,Messenger 内置钱包的资产可能也会用 Safe 管理,但不满足「not your keys, not your coins」这样的原则。 常说没有 100% 的安全,被黑是迟早的事——但是不能用这样的理由来躺平,毕竟可以通过各种手段来提高被黒的门槛。因此,作为 Mixin 生态中的开发者,肯定要对包括 Mixin Safe 在内的可能的资管方案都做一番分析,尤其是在黑客攻击事件之后,安全方面的分析就非常重要,毕竟这影响到是否要使用 Mixin Safe 方案这样的决定。 重要提示 & 免责声明 本文只代表我个人的观点。 本文只对基本机制分析,受限于我的知识与能力,不保证内容的完整性和准确性。 本文只对当前 Mixin Safe 版本分析,不保证时效。 本文不对任何内容中提到的产品、服务、方案背书,不构成任何投资建议。 本文所描述的各类风险并非方案缺陷,而是各类最坏情况发生时的假设。 分析范围 我直接略过了官网 ,从 Mixin Safe 的技术说明书开始读。这里是地址。 另外还有部分代码,都在这里。 概览 首先可以得到如下简单的事实: Mixin Safe 的金库本质上是原生链上的多签。如果用 Mixin Safe 保管 BTC,那么使用的就是 BTC 原生的多签脚本来管理 BTC;如果保管的是 ETH,那么使用的就是 ETH 合约来管理 ETH 和 ERC20 资产。 因此: 如果链不提供多签能力,那么 Mixin Safe 就无法支持。 如果链提供多签能力,但是 Mixin Safe 还没有支持,这个链上的币无法放入 Mixin Safe。 接下来技术说明书都以 BTC 为例来讲原理。 每个 Mixin Safe 金库的底层都是一个 2/3 的多签,多签方分别为: Holder:金库管理人,也就是 Mixin Safe 的使用者。 Signer:一个 MPC 去中心化网络,称为 Safe Network。其 Safe 节点的参与条件为必须先 Mixin 主网的节点。也就是可以看作 Mixin 主网的子集或者全集。 Observer:默认是 Mixin 团队,实际实体应该是 Mixin Ltd 香港公司,负责 Safe 的研发和商业化。 资金操作需要三方中的两方签名后才能执行。 其中: Holder 会要求创建一个 BTC 私钥。在创建金库时,会问创建人要这个私钥对应的公钥。这个私钥的来源没有限制,目前为了流程的方便支持 Bitcoin 官方钱包、硬件钱包 Ledger 和 Mixin 团队开发的手机 App Mornin Key。 在创建多签金库时,会给 Observer 创建一个 BTC 私钥。 Observer 的私钥默认是 Mixin 团队持有,但是可以定制为金库的创建人,也就是 Holder 提供。 Signer 的外在表现的形态是协助管理多签资产的共管人,实际上是 Safe Network 的多个节点,这些节点控制私钥。 也就是说,Mixin Safe 方案里有两层多签:第一层是资产所在的链的多签,是一个 2/3 多签组;第二层是 Signer 上资产共管人的多签,是 Mixin 上的多签,是一个 N/M 多签组,其中 N 和 M 可以设置。 风险分析 合约或者脚本漏洞 Mixin Safe 使用的 Bitcoin 脚本和 Ethereum 合约都公开在了 Github,可以在 这里 和 这里 查看。 其中 Bitcoin 脚本非常简短。Ethereum 合约使用的是 Safe Global 的合约。这个合约如果出问题的话,Safe Global 上 $790 亿的资产都会出问题。 我不是合约安全专家,暂时未对脚本和合约做深入分析,只是粗看没问题。 资产窃取 对私钥的窃取 根据 2/3 多签的特性,当其中有两个私钥泄漏时,资产就会失窃。 那么有三种可能性: Mixin Safe 主网 Signer 被攻破且 Mixin 团队管理的 Observer 私钥被窃取,然后等时间锁解锁。 Mixin Safe 主网 Signer 被攻破且金库管理人掌握的 Holder 私钥被窃取。 金库管理人掌握的 Holder 私钥被窃取且 Mixin 团队管理的 Observer 私钥被窃取,然后等时间锁解锁。 对于金库管理人来说,总会对自己管理的私钥有信心,而担心另外两份私钥被窃取。对黑客来说,攻击 Mixin Safe 主网和 Mixin 团队确实是潜在收益更高的做法,那么影响最大的情况就是上述的第一种可能性: Mixin Safe 主网被攻破且 Mixin 团队管理的私钥被窃取并且等时间锁解锁 对于这种情况,Mixin Safe 给的解决方案有两个: 在时间锁解锁之前,将资金转走。 在创建金库时,由 Holder 指定一个 Observer,该 Observer 私钥不由 Mixin 团队管理。 对于解决方案 1,虽然攻击者时间锁解锁之前都拿不走资产,但是攻击者可以等待,之后择机拿走资产:因为粗心的金库管理人可能忽略了时间锁解锁,没有及时转走资产。 这里暗示了一个使用 Safe 的最佳实践,即金库管理人一定要在时间锁到期之前转走资产到新的 Safe 金库或者其他地址。因为一旦时间锁解锁,此时金库的风险敞口会变大。 反过来,这也暗示了时间锁的意义之一: 在一段时间内确保,即使 Mixin 团队管理的 key 丢失,金库的安全性不被这件事影响。 对于方案 2,等同于 Holder 同时管理 Observer 私钥,那么这个 2/3 多签本质上退回到了 2/2 多签,其中 Observer 是 Holder 的一个延迟备份。攻击者需要同时攻破 Mixin Safe 主网和窃取管理人手中的任何一个私钥才行。 这样降低了 Mixin 团队管理 Observer 私钥的风险,但是也对金库管理人提出了更高的要求。 对 Signer 的拒绝服务攻击 刚才提到,Signer 实际上是 Mixin Safe 主网控制的,它是一个由一群服务器组成的在线服务。因此,即使攻击者无法攻破它获得其管理的私钥,也可以对它进行拒绝服务攻击,让它瘫痪。 在 Signer 无法工作的时期,如果攻击者具备一些特殊条件,那么也可以对资产窃取。 例如:如果攻击者获得了 Observer 私钥和对应的 Holder 的私钥,然后他还知道这个 Observer 对应的时间锁解除时间。此时,攻击者使用某种方式瘫痪了 Safe 主网,导致 Signer 不正常工作。如果在这期间时间锁过期,攻击者就可以人为地构造一个让金库管理人无法在时间锁过期之前转移资金的时机,从而攻击得手。 因此,金库管理人还需要预留攻击者瘫痪 Safe 主网以后恢复的时间,不要拖到时间锁快过期才去转移资产。 供应链攻击 即攻击 Safe 主网节点、Safe 的网站业务、Mornin 钱包的源码,在其中加入恶意代码。 注意 供应链攻击并非针对 Mixin Safe 方案机制的攻击,所有软硬件钱包都可能遇到。在此仅评估如果发生供应链攻击,对 Mixin Safe 的影响。 这里分为几种情况: 在 Safe 主网节点中加入恶意代码会导致 Signer 的私钥泄漏 在 Safe 的网站中加入恶意代码虽然不会有私钥泄漏,但是可以通过钓鱼和诱骗等手段欺骗 Holder 和 Signer 的共管人的签名。 在 Mornin 钱包中加入恶意代码会导致 Holder 的私钥泄漏,但是攻击者需要知道每个私钥作用于哪个多签地址才能实施攻击。 在最坏的情况下,Signer 和 Holder 的私钥可能因此泄漏导致资产损失。不过隐藏好多签金库的信息的话,会降低被攻击的概率。具体的方案有: 不使用 Safe 的网站,而是自己写程序去操作。 不使用 Mornin 钱包管理 Holder 私钥,而是使用其他钱包。 私有化部署 Safe 网站和关联服务,降低开放服务的风险敞口。 当然,这些都会提升使用的难度和门槛,也是提高安全性的代价。 多签的回退 刚才提到,如果管理人定制了 Observer,那么 2/3 多签实质上回退到 2/2。这是底层链的多签的回退。考虑到 Signer 的共管人实际上是 Mixin 上的多签,这一层多签也是可能回退的。 例如,如果在创建金库时,选择了金库的多签阈值为 N=1,则 M 个共管人中,只需要收集一个签名即可转账,此时的底层多签实质上回退到了 1/3 —— 因为资产管理人也是共管人之一,当 N=1 时,实质上 Holder 和 Signer 保持了「共同投票」,此时资产管理人自己就可以操作其中所有资产。 资产不可用 在「资产窃取」章节,我分析的是机密性。但是作为安全的一环,可用性也重要。如果可用性没了,对应到加密货币资产,就是这些资产能看到,但是不能取回来。 多数私钥遗失 由于 2/3 多签的特性,如果其中有两个私钥丢失,则这笔资产就无法操作了,也分为三种情况: Signer 不可用 + Mixin 团队的 Observer 私钥丢失 Holder 管理人自己的私钥丢失 + Mixin 团队的 Observer 私钥丢失 Signer 不可用 + Holder 管理人自己的私钥丢失 其中 Signer 不可用的一种情况在上一章「对 Signer 的拒绝服务攻击」有提到,不再赘述。另一种情况是 Signer 上的共管人遗失了访问权限——不过这不属于系统设计上的问题,不表。 总之,以上三种情况如果发生,会导致的这些资产虽然没有被窃取,但是从此也无法将它们转出多签地址。 时间锁的影响 另外,由于时间锁的特性,在时间锁生效的时期,正常运作的 Safe 本质上是回退到了 2/2 多签,这个时期都可以认为 Observer 私钥是不可用的。 如果此时 Signer 不可用(刚才提到了)或者 Holder 私钥丢失,那么这部分资产在时间锁解除锁定之前,都是不可用的。 如果资产的价值有时效性(例如时间锁解锁以后不值钱了),那么管理人需要考虑这一风险。 信息泄漏 信息泄漏不会导致直接的资产安全问题,但是有的攻击手段需要知道一些相关信息才能实施攻击。 例如,如果攻击者拿到了 Holder 的私钥,那么他需要知道这个私钥对应的是哪个多签金库,才能对这个金库的共管人或者 Mixin 团队实施欺诈。 目前 Mixin Safe 使用 SegWit 上的脚本,而不是 Taproots。如此这般的话,当一个 UTXO 被消费以后,对应的脚本会随着暴露,多签参与人的信息也就随之暴露。暴露的信息可能有一些安全和隐私隐患。 其他安全问题 略 其他资管方案 目前的研究中,主流资产中只有 Ethereum 有最成熟、可用性最好、并且最灵活的多签解决方案,即 Safe.Global。其他大部分主流链的资产的支持都不太好:有的是不支持多签名,有的是缺少好用的方案,有的是不开源,有的是缺少对硬件钱包的支持,各有各的问题。 我觉得 Mixin Safe 提供的开源方案有一定的吸引力,也有一定的风险敞口。如果选择 Mixin Safe,它的配置也可以很多样,需要根据实际自行调整。

2024/1/18
articleCard.readMore

Quaily 订阅者超过 9000人了,主要是想给我的朋友们带来笑容

前几天和一个新认识的程序员盆友聊天,他问我最近在做什么,我说在做一个叫 Quail 的内容付费服务,然后我就给他看了。他问我为什么想要做 Quail,我说主要是想给我的朋友们带来笑容。 If you build something you and your friends want, you never have to go find users. You already know them. — Paul Graham (@paulg) May 2, 2019 初衷就是这样,我之前也提到过的。 然后我看了一下统计,从七月七日 Quail 开放注册到现在,Quail 的订阅者居然超过 9000 人了。他就问我在哪做了 Promotion,我说几乎没有做过 Promotion,主要就是仰仗朋友的支持啊。他说你的朋友真好。 我也觉得。对于各位支持我的朋友们,无论是作者和是读者,真诚地感谢各位。 Newsletter 介绍 下面是对一些近期在更新的 Newsletter 的介绍。这次先介绍 10 位。如果其他作者希望我推荐的话,也欢迎联系我。 AIGC Weekly 由 @op7418 设立的 AIGI 周报。每周一更新,主要介绍上周AIGC领域发布的一些产品以及值得关注的研究成果。 可能是东半球最好的中文 AI 相关资讯周报,没有之一 🤑。 橘子汽水铺 by @oran_ge,来自一线 AI 产品经理的 Newsletter。既有 AI,也有产品领域的深度思考。 每次跟橘子聊天,都有写文章的灵感 💡。 王一石 曾经创办币信和 OneKey。@ohyishi 的文章阅读任何一篇都值回票价。 虽然会员费是最贵的,但也是会员人数最多的 🤑。 向阳乔木 一个爱钓鱼、喜欢听摇滚乐、每天洗冷水澡的PM,@vista8。 不过已经很久没更新了,请继续更新吧📅! CreativityOverflow @goldengrape 他会写程序,会玩音乐,会用 AI 写程序做音乐,会写程序做眼科光线研究,会用 AI 写程序做眼科光线研究 .... 他可能是我认识的最强的医生?真的还是医生吗👨‍⚕️? 余晟以为 @FreiheitYu 是著名的非正统技术爱好者,至今已翻译出版《精通正则表达式》、《技术领导之路》、《程序员的职业素养》等作品,合计字数超过一百万,并得到很多读者的肯定。 我小时候经常可以从余老师这里得到全肯定👍。 基本常识 可能很多华语读者都知道这位著名的科普作家,项栋梁老师的专栏。他从 2015 年一直做科普至今,一直都关注他。 在中国做科普有多么不易,大家应该知道吧... 二〇四〇 @dbarobin 的 Newsletter。他是一位 Bitcoiner, Investor, and Digital Nomad。介绍了很多加密货币、数字游民相关的内容。 精神和经济都要自由⚖️。 未來交易週報 @austinsayhi 关于投资的 Newsletter。 他说,「看過的人都表示內容準的像是未來人寫的,所以名為未來交易周報」🔮。 猫鱼周刊 @阿猫 创造的软件技术相关话题的周刊,他今年 11 月才刚开始创刊。 他希望大家支持他不要让他随便弃坑⛳。 因为这网页的空白处有限,所以先列了十位作者,之后发现有趣的作者还会继续介绍给大家。再次感谢!

2023/12/17
articleCard.readMore

质疑 PHP、理解 PHP、成为 PHP

故事的起因是这样的。 我哥们在某著名大厂干运营,他有一个程序员男朋友。最近他总埋怨男朋友不思进取,很嫌弃。 于是我问怎么看出来他不思进取,我哥们说,他用 PHP。 现在的我有点后悔当时的回答:「PHP 确实有点ちょっと...」... 俺错了!希望他们没分手! 但是,技术上不思进取在感情上有什么错?! 用的宾语是谁? 重点是,PHP 有什么错?PHP 在 2023 年 11 月 9 日还发行了 PHP 8.3.0 RC 6 版本... 现在是个信息爆炸的时代。但凡不是我主动搜索的信息,我有一个习惯,那就是不会主动去追热点。 因为我相信着一种「信息涟漪回响」的现象,可以这样表述。 把舆论场看作一个水池,在其中传播的信息就像水池中的涟漪。当它传播到水池边缘或者水池中冒出来的 KOL 时,会形成回波。 当一个能量很强的涟漪出现时,它会在水池中来回荡漾好几轮。 就像这样: 所以,如果一个信息足够强(足够重要),它总有机会出现在我面前。 所以,我一直觉得,如果一件事物很重要,那么最终是它走向我,而不是我走向它。 新技术也是这样。 比如说,我一直没学 k8s,甚至也不主动用 docker。既然它没有走向我,那么一定是因为我不太需要它。 说起来,对 k8s 的糟糕印象来自一件事情: 我哥们当时就职于一个很小的团队。有一天,公司的官网 down 了。我哥们对此满头问号:因为官网是一个纯粹的 Tailwind 静态网页,我哥们不理解为什么会看到 504 timeout。 于是我哥们在 Teams 里问负责运维的同事。 对方的回答让我哥们当场崩溃,原来所有的前端站点、SPA 都被打包成 Nginx 的镜像,并且通过集群的 ingress 来管理他们。 这波 DevOps 技术推广得很好,下次别推了。 最近还有一件很离谱的事情是 Next.js 14。 虽然我一直把 Vue 和香草 Javascript 混搭着用 ,但是也会稍微看看 React 侧的发展。Next 14 的操作确实让我有点震惊。 作为一个长期用各种语言挖坑的人,我非常理解前端工程师要解决什么样的核心问题。但是作为企业经营者,我也非常清楚如果放弃这些看上去很 fancy 的东西可以让我多舒服——我选择放弃。 不过想到他们这么瞎折腾还能赚钱,我又很羡慕他们。 大概, 毕竟,古代的人类,能研究艺术和宗教的都是权贵。 好 想 开 了。 我只是想和人民群众站在一起 回过头来,随着年龄越来越大,时间越来越少,我变得越来越不想在技术上锐意进取了。当然,这不代表我躺平了。我依然在学习,终身学习是我的信条。 我只是不再刻意追求新的技术潮流——或者自信点,去掉「技术」 我觉得这应该和经验的增长(aka 越老)有很高的相关度。经验越多,就越想总结一套「大一统」的框架去描述新事物。这个倾向有好的一面,也有不好的一面。 好的一面,当然,这是一种抽象。抽象很强大。 不好的一面,我们通常把这种情况描述为经验称为思想的枷锁。 当然也可以理解成手速慢了。 人们经常用「过气」来形容人或者东西:曾经强大,然而却今非昔比了。 在美国俄亥俄州克利夫兰有一个摇滚名人堂(英語:Rock and Roll Hall of Fame)。这里专门记录历史上知名的和有影响力的摇滚乐音乐家、制作人、工程师和所有对摇滚乐有贡献的人。 按照现在的说法,他们都是「过气」音乐人,他们应该穷困潦倒,他们应该上专门消费「过气」艺人的节目。 这个节目还要、应该、必须,把查克贝利的 AI 数字人拉出来表演,然后让 GAI 当评委发表一些评论。 有没有一种可能, 最后欢迎大家订阅我的 Newsletter。订阅的方式有三种: 在下方输入 Email 地址 点击下方的 RSS Feed 的图标,可以用订阅器订阅更新 点击下方的 Telegram 图标,可以使用 Telegram 订阅 当然,我的 Telegram 群也随时欢迎大家: https://t.me/lyric_discussion 谢谢(with respect

2023/11/15
articleCard.readMore

AI 淘金热:是撸起袖子亲自淘还是卖铲子呢

在之前一段时间,我写了好几篇跟 AI 相关的文章: 不秃也变强:让 AI 当大师傅,编程和写作效率提升两三倍 我们团队的 AI 实践:探索过去几个月的时髦科技付費 面向 AI 的编程:是时候该坐下来应对不确定性了 拥抱阴影:AI 和区块链的监管与颠覆之舞 人类替代计划:一份使用 AI 代替公司同事的指南 自己的团队也尝试参与其中,但目前我们团队的 AI 项目都停滞了。 比如作为核心项目的框架 Botastic 五个月之前就已经停止提交了。另外一个闭源的商业应用型项目也暂停了。 刚好前几天,我有一位朋友来找我咨询。他有一个 AI 应用项目,但是他对这个项目的前景感到迷茫。于是我说了一些想法,这些想法基本上也是我暂停所有 AI 项目的原因。 结合 OpenAI Dev Day 向外释放的信息,基本印证了我的想法。 卷 如果只关注于纯粹的 AI 项目,不得不用「卷」—— 「竞争激烈」来形容这一现象——金矿吸引了众多淘金者,而卖铲子的商人也不在少数。 在这场淘金热中,尽管芯片领域仍旧由 Nvidia 主导(至少目前来看是这样),但其他 AI 领域则都塞满了人。 「卷」的另一面是「窄」。那么大的应用市场目前仅仅被挖掘出屈指可数的几个有效的商业化场景,空间尤为狭窄。 首先最容易想到的 Prompt 工程。虽然刚开始,大部分 Prompt 产品只不过把有用的 Prompt 列出来,但未来 Prompt 工程肯定是工作流的一部分,而且与使用的 LLM model 有很强的相关性。虽有门槛,但是技术上... 但凡说它有一些技术含量,也不至于被拿来调侃。 然后,最容易想到的也是最粗暴的应用是 AI 平替古典功能。例如涌现的众多的外语学习 App,把之前比较难做的场景对话改成调教过的 AI 角色就行。但作为特别典型的套壳应用,把 OpenAI 或者其他供应商的批发 API 改成零售,在技术上没有门槛也没有创新性。 其次是 RAG,用 LLM 解读基于既有内容的一类服务,比如客服机器人(包括我们做的 PAL9000,这类服务也没有什么技术门槛可言。 工具类产品,比如 ChatPDF 这类;或者娱乐性产品,比如妙鸭相机这类;或者提供情感价值的产品,例如 janitor.ai。当 OpenAI 这样的基础服务提供者,直接变成一个产品公司,亲自下场开始做面向终端消费者的产品以后,他们的处境大概会变得很微妙——用户的时间就那么多,谁都想做入口。 Agents 或者助手的话,我觉得应该挺有很有戏,但我觉得难点不是 AI,而是用户体验,需要缓慢打磨。 总之,要么需要在其他方面上下更多功夫,比如提升用户体验、比如保护客户关系—— AI 是银弹,但不是你我的银弹;要么必须在 AI 技术本身上展现出独特的竞争优势,去拼算力和数据,走上一条充满荆棘的道路。 穷 以开发英语学习应用程序为例,要使 App 在单位 token 成本上低于 OpenAI 投资的 Speak 可能是一项艰巨的任务。不仅成本要低,LLM 的响应速度能否超越 Speak,似乎难上加难。 或者,如果如果计划做个 Code Assistant,那么能否在速度上超越 Github Copilot 生成的提交信息呢?更重要的是,能保证生成的代码在质量上胜过它吗? 早晨看到这条,扎心地笑了。 投资人睡醒后的第一件事,就是询问相关创业者:“你们和OpenAI所做的差异性在哪?”。 创业者回复:“差异性就是比他差。” — Orange AI (@oran_ge) November 8, 2023 如果仅仅是使用这些 AI 供应商的 API 和服务,将不可避免地发现自己在价格上与他们竞争。如果打算自己培育 LLM,那么在算力和数据集方面与他们的竞争也不可避免。 咋搞呢 第一个重要决定是:走向面向消费者的产品路线,还是去做企业市场。 面向消费者的产品 面向企业的产品 市场规模 大,可以迅速扩展到大量用户 相对小,但每个客户价值较高 收入模式 多样化(订阅、广告、应用内购买) 通常基于订阅或长期合同 客户行为 受情感和个人偏好影响较大 更理性,基于效益和成本分析 市场反应 快速,可以快速适应消费者需求 较慢,需要长期规划和调整 营销策略 社交媒体推广、口碑营销 直接销售、行业合作、展会营销 产品特性 需要不断创新,追求趣味性和酷炫 重视可靠性、定制化和专业服务 盈利潜力 低成本、高覆盖,潜在收入波动大 单个客户价值高,收入稳定 客户忠诚 低,易受新产品和趋势影响 高,建立后难以更换供应商 初始投入 相对较低,快速上市 较高,需要针对性开发和调整 具体做什么,没有通用解,取决于各个公司自己的资源和特点。不过总体来说,可以参考下面的一些条件: 有做消费者产品基因的团队建议做消费者产品 现在这个阶段的 AI 消费者产品,门槛低、无痛点,很难因为什么独一无二的功能得到用户们的普遍青睐,于是又回到了比拼硬产品力的状况。 一方面,消费者对体验的追求是无上限的。另一方面,消费者的购买决策成分里有大量的非理性成分。就拿让人类的劣根性发扬光大这一点来看,只有有消费者产品基因的团队才能做得好。 能把 AI 无感知地融入到现有使用体验中的话,建议做消费者产品 前段时间有关于在 AI 时代下,基于对话的界面(chat/conversation-based interfaces)是否会代替 GUI 的讨论 ——这种讨论的结论总是相同的而且没有太多意义:一部分能代替,一部分不能。重要的在于哪些能哪些不能。 如果我们把软件看作一系列功能的集合,那么这些功能的操作可以看作一颗流程树,那么目前的 GUI 是在这棵流程树的上的一系列切片。 GUI 的优势是它的切片是稳定的。好的 GUI 可以让用户感到安心:我想要的东西它就在那里。 GUI 的劣势是「稳定」的背面,即它的信息架构是固化的,它很难通过上下文去提供给用户当下最优的流程。 在 AI 时代之前,也有一些场景是「基于对话」的,但是他们要么不够聪明——没法很好从下上文做推断,知识贫乏也给不出好的答案——例如 AI 客服;要么规模很小、流程很短——例如搜索和推荐,属于用完即走的小型流程。 回过头来,虽然未来一部分 GUI 会被基于对话的交互代替之,但是大部分 GUI 是无法被替代的。但这种情况下,AI 对此并非完全不可为。使用 AI 的话,一些原来很难触达的用户需求可以被感知,一些原来优化成本很高的流程可以也被优化。 已经身处某个管制市场,建议做企业产品 哈,这是自然。 如果您也在考虑这件事的话,并且感到焦虑的话,欢迎联系我的 Telegram,也许我可以给您一些帮助。

2023/11/10
articleCard.readMore

学日语的一些乐趣

刚来日本的时候,听过一个段子: 有个日本老板往中国发货。发货时,他叮嘱伙计不要用废弃的报纸来包裹货物。 伙计问他为什么? 他说,上面都是汉字,中国人能读。我们用报纸报东西,报纸上这些东西在中国被人读到了,可能会害了我们的中国客户。 中国人是能读懂不少日本汉字,不过这个日本老板也挺能读懂中国。 能读汉字,确实对学习日语很有帮助。我的第一本日本语教材上一个汉字都没有,对此还觉得很奇怪。结果我的老师告诉我这本教材是为了照顾「students from western countries」,所以上面没有汉字——我一下子就理解了。 早期日本虽然有语言,但是没有自己的书写系统,因此随着佛教从中国传入日本,最早的佛教徒也把汉字作为最早的书写系统引入日文。 但是因为汉语和日语并非同一个语系,于是后来发明「假名」以后,汉字和假名就构成了最初的日文书写系统了。接下来假名演化出了今天的「平假名」,用于拼写各类变形和日语词汇。在差不多的时间里,「片假名」也被僧侣们从汉字中拆出来,最初用来标注汉字的发音。 再后来日语的词汇就慢慢定型了,大致可以分为三种: 和語 漢語 外来語 其中和語就是日语本来就有的词汇,用平假名拼写。例如:おはよう(早上好)、わたし(自称)、が(助词)这样的词。 漢語一部分是古代就从中国传入的词语,例如「世界」「学問」「親切」;另一部分则是后来使用汉字创造的词,例如「電話」「文化」「安全」等等。 外来語里大部分都来自英语,小部分来自其他语言(也包括现代汉语)。比如コンビニ(便利店)是对英语「convenient store」中「conveni」的音译;パソコン(电脑)是对英语「personal computer」中「person-com」的缩写(对,就是这么怪)。他们大部分会用片假名来拼写。 于是现在外来词常常用来表达新出现的概念和东西。甚至,已经有日语或者汉字名字的东西会被用外文词重新表述。比如「めし」是「米飯」,「ご飯」也是「米飯」,「ライス」是英文「rice」的外来语,也是「米飯」。 不过这些外来词和本土词在含义和细微差别上有细微的差别。例如「牛乳」和「ミルク(milk)」都是牛奶是差不多。不过「煙草」在零售领域基本称为「タバコ(tobacco)」。「おさけ、ワイン、アルコール」虽然都是酒,但是「おさけ」一般都指日本酒,「ワイン」一般指水果尤其是葡萄酿造的酒,「アルコール」则是对酒类的统称。 总体来说,使用「漢字」时给人正式严肃的印象,外来词给人新奇的印象。 甚至有很多外来词已经和源语言没什么关系了,对于源语言是英语的外来词,也可以称为「和製英語」,例如「panelist」应该写作「パネリスト」,但是「パネラー」被构造了出来,表达的也是同一个意思,虽然并没有这个英语单词。 实际口语中,一些非外来词也会用这种方式来压缩,并且片假名来拼写,比如「キモい」表达「恶心」,诶就是嫌弃别人的时候说的那句,是「気持ち悪い(きもちわるい)」的简写。 所以年轻人喜欢用外来词(或者伪外来词)是一个很普遍的现象。不管是不是个英文单词,反正酷就对了。 这类情况在汉语里也有出现。例如「笔记本」->「电脑」-> 「本儿(东北话)」-> 「mbp」。再比如「厉害」->「永远的神」->「YYDS」 在日常书写和表达时,通常会在一个句子里交错使用汉字、假名和标点「、」。例如: 暑いと、プールへ行きたい(好热,想去泳池) 这个句子就很易读,因为一眼就能看出 暑い、と、プール、へ、行きたい。如果全部使用假名的话,看起来就会很困难: あついとぷーるへいきたい(haorexiangquyongci) 感觉就像中国人看纯拼音似的。 关于外来语我想多说一点。 之前网上有一个图片,用来表达片假名之恶毒: 其实现实情况倒是没有那么奇葩,这张图有点为了黒而黒的意思。如果访问 Qiita.com 这个程序员网站,会发现该用英文时还是会直接用英文的: Python 就是 Python,不是「パイソン」。Raspberry 也不是「ラズベリー」。 看样子,日本的程序员也和我的看法相同,行业内的词不如直接用英语。 不过我觉得现在日语里多多少少有点滥用片假名的感觉,但我又很理解。新词汇进入日本以后,如果没有合适的现有词(汉字组合)去表达它,用片假名拼写确实是一种做法——毕竟不是所有人都会英语——但,真是一种很偷懒的做法。我还是比较怀念日本学者用汉字翻译外来词的时代。 虽然日语有大量词汇来自中国,但是文化交流是双向的,因此到近代时也有大量的和制词汇,从日本传回到中国,称为「和制汉语」。于是我们现代汉语中有很多词,都来自日本。 其实这种词又可以细分为三类: 中国本来就有,但是在日本获得了新的含义,比如:電気、電報、地球、銀行、化学、直径、風琴、料理。 日本用中国古典籍的词来翻译其他外来词,比如:革命、文化、観念、福祉、文明。 日本创造、流入中国的新词,比如:電話、情報、科学、哲学、喜劇、美学、神経、軟骨。 第一类的典型的例子是「銀行」: 汉语中原本的「銀行」表示的意思是金银器店,卖贵金属和首饰的地方: 银行,今金陵坊银行街,货物所集;花行,今层楼街,又呼花行街,有造花者。诸市但名存,不市其物。 但是到了 1851 年,美国传教士裨治文《大美联邦志略》传入日本,并进行了翻刻,于 1864 年在东京出版,写到: 邦中杂税所入,每年凡银二百数十万,如银行年中入租银六十万。他如民间银行,在邦都者,现存本银约三千五百万。 这里的银行已经是「bank」这个现代含义了。所以现代汉语中的「银行」本来是一个汉语词汇,但是它最普遍的现代含义源自日本的「銀行」。 当时这些来自日本的汉语词传入中国时,其实有很多人反对。例如学者彭文祖就觉得「取缔」应该改成「禁止」,「场合」应该改为「时、事、处」,「第三者」改为「他人」,「动员令」改为「动兵令」,「打消」改为「废止」,「目的」改为「主眼」,「取消」改为「去销」,「手续」改为「次序」等等。 但是很遗憾,这些阻力没有奏效,以上和制汉语都已经进入了现代汉语。所以各位读者,你平时说的话有很大一部分都在用日本词呢。 很多人误以为除了中国大陆以外的地方都在用繁体,其实这是不对的(甚至每个地区的「繁体」都不一样)。日本在 1946 年以后,就把很多汉字进行了简化。有一些,使用了和中国简体一模一样的字形,比如「国家」的「国」(Unicode: U+56FD) 但是有一些,则是完全不同的写法和完全不同的 Unicode 编码,比如「变更」的「变」(U+53D8),在日文汉字写作「変更」的「変(U+5909)」。 有一些字虽然 Unicode 编码相同,但是由于地区性简化的原因,在不同的字体下会有不同的表现。例如「生意兴隆」的「隆」的 Unicode 都是 U+9686,但是在中文字体下显示为「隆」,在日文字体下会显示为: 诶,对咯,少了一横。可以在支持日文的系统(比如 iOS)下打开网页 RYU(隆) 这个链接,看看里面「街霸」里「隆」这个角色的名字的写法。 最后放个广告,我的日语老师最近在招生。我觉得她教学专业、耐心、负责,价格也非常实惠。她们有专业的日语教师团队,无论是考级、留学、在日本生活和工作,我觉得她都能给很好的帮助。所以我已经两次续报她的课程了(我的这位老师日程已经满员了,和她同工作室的其他老师也是可以的:),不用一窝蜂地去找同一位老师,否则其他老师会很伤心)。 对于已经在日本,或者想要来日本的朋友,或者单纯想要学日语的话,不妨考虑一下她的一对一课程。如果有兴趣的话,可以 访问她的网站 了解一下大概的课程,然后扫下面的微信二维码试听。现在联系她试听的话,同时提供我的邀请码「lyric」,试听课直接打五折哦。

2023/11/2
articleCard.readMore

怎么让大公司不抄你

几年前,在创业者拿 VC 钱的黄金年代,总会遇到这样的 VC 大哥,他们问「大公司抄你怎么办?」。 其实大哥你真的多虑了。大多数情况下,这个问题根本不需要担心:大部分产品都发展不到被大公司抄的程度。 (全文完) 抱歉,还没完。 现实确实如此,大部分产品确实活不到被大公司正眼看的阶段。回答这个问题就像存在大过滤器的宇宙里,回答「遇到外星人要发生第一类接触时要怎么办」一样。不如去花精力解决当下的问题。 不过,真遇到被抄的情况,如果去接对方争辩,「借鉴不能算抄……读书人的事,能算抄么?」接连便是难懂的话,什么「致敬」,什么「有态度」之类,搞得大家都很难看。 像素级的抄袭况且维权困难,那如果对方进行业务模式上的复制,阁下又该如何应对呢? 大公司做这件事可能还挺棘手 不知道大家觉得一个细分市场的消费型产品拥有 DAU 1000 万是个什么水平。相信很多人会觉得相当不错——我也觉得。 但是对于掌握十亿级流量入口的大公司来说,如果在流量池中给这个 DAU 1000 万的新产品开辟一个入口,公司需要斟酌。因为都有十亿级流量了,即使在入口上放坨屎,每天也能有大几千万人来尝尝鲜。那么具体放哪坨,用什么姿势放,很需要仔细考虑。 首先营收肯定有影响 一个新的产品,它的用户所贡献的价值和生命周期不同,考虑营收就是一个运筹学问题。新产品上线了,会不会给一直提供可靠营收的老产品分流,然后影响到公司利润啊? 当然,虽说新产品可能让短期营收下降,但是也许、可能,长远看能为公司拓展业务边界、找到新的增长方向、赚到更多钱也说不定。但即使公司有一群勇于冒险的管理层,也得兼顾对利润尤其敏感的股东们的感受。 小团队可不在乎。本来小团队就没有别的营收可以被竞争,做好这唯一的产品就是最好的营收渠道。 其次公司内部可能有对资源的竞争 既然新的产品线可能影响到营收,那么动老业务线的蛋糕就更加现实了。 同一个公司里大家能在同一家公司里工作,除了五百年的修行,也是因为当下大家的短期目标是基本一致的。但凡说基本一致,就说明有很多不同。公司的高层、中产、员工的诉求完全不同;不同的业务部门的 KPI 还会产生矛盾。 在这种情况下,也不知道新业务线的负责人,约老业务线的老哥一起喝咖啡谈心妥当了没有。 小团队也一般也没几个主营业务,当下的小产品就是最大的业务。大家能一起在这个小团队里共事,那必须得是一条心的一个战壕里的同志。 一个 Product-Market Fit,两种解释。 总之,新的产品既然是创新,很可能稍微破坏一些公司既有的东西,不仅仅包括营收、团队目标、还有品牌基调和战略。对于大公司来说,都是一种冒险。 尤其是所有拥有亿级流量的产品的公司,都可以自称为「网民的基本盘」。既然是基本盘,那他们的目标用户群就是所有人,做出来的东西也就必须差不多。也就意味着产品设计时要放弃一些个性,因为他们不可能放弃基本盘,这是属于基本盘的路径依赖。比如说,微信作为一个通用通讯平台,它几乎无可能掉转车头去做陌生人交友。 这就跟连锁餐厅一样,你知道他们的菜品的质量肯定稳定,能照顾所有顾客的偏好。但是对于有偏好的顾客来说,绝对谈不上出色。 但新的小产品不一样。小产品本来就没有基本盘,在历史用户群体上没什么能放弃的。那么可以放心发展自己特有的文化认同,组建自己的用户社区,为他们解决好大公司产品无法解决的问题,获取这部分用户的青睐。 让用户喜欢你 在互联网行业里,「护城河」是个经常被提起的词。这个词已经把「用户是我的资源」的观点昭然若揭了,因为是资源,所以需要「护城河」免得被人抢走了。 当然这一方面是因为互联网行业所提供的面向 C 端的服务,是一些很容易规模化的产品;和人打交道的,也是一个个可复制的程序。在这一意义上,用户们确实就是一种用于争夺甚至掠夺的资源而已。 但这样的观点,做面向企业客户端和做传统生意的老哥们肯定是不同意的,他们的运营模式与互联网行业有着明显的差异。在他们眼里,客户不仅仅是资源,更是长期的合作伙伴,远超过单纯的交易关系。 比如,当我们谈到面向企业的服务,我们谈的是深度合作、定制化解决方案和长期的业务合作关系。确实,规模化和通用的 SaaS 能满足浅层的需求,但大客户的需求往往是独特的,需要深入了解、长时间的维护和创新。 再者,传统生意的老哥们,他们更加重视人与人之间的关系。在他们的字典里,客户不是简单的数字和数据,而是有血有肉、有情感的人。他们与客户建立的是一种长久的信任关系,也不是短暂的交易关系。 但是就像很多行业的发展一样,二者的发展并非不可弥合。 从面向 C 的产品来看,大家也注意到每个 App 的用户都是一个真实的人,也和公司里的你一样,拥有自己的需求、感受和情感。所以才后了后续对「个性化」的发展。 其次,情感的需求不仅仅是单纯地满足用户场景。现在这个时代,追求共同价值观,即使在普通的消费决策中的角色,也变得越来越重要——大家不再仅仅追求产品或服务的功能性,也不仅仅看中价格,更开始在意的是与产品之间的情感连接、社群文化、共同价值观。 如果用户说「给你介绍一个 App,我在用」,这显然是把你当外人。如果用户说「给你介绍一个 App,我们都在用」,这是把你当自己人。 所以我刚才说小产品应该发展自己特有的文化认同,其实目的就是让用户从「资源」转变为「护城河」。这个护城河不需要保护用户,而是转而保护你的产品和用户所建立的这种情感纽带。 这样,产品与用户之间的关系已经不再是单纯的交易,当产品不仅仅满足用户的功能需求,而是与用户产生深深的情感联系时,这种关系就如同情侣之间的深厚情感,而非炮友关系的肤浅互动。 在这种紧密的情感纽带下,任何竞争对手想要介入、破坏或试图拉走用户,都将面临极大的挑战。因为他们不仅仅是要超越一个功能优越的产品,更是要打破一段深厚的情感纽带。 比如说独立开发者的三大件之一的笔记软件。这么多笔记软件每一个都解决了什么痛点吗?双向链接?知识图谱?在我看来完全没有,大家都是提供了一个能让自己舒舒服服当松鼠的工具而已。那为什么要用 Notion/Obsidian/LogSeq/Evernote ...,明明大家的基础功能都差不多。 因为我喜欢。 不再一味追求规模 不过建立文化认同是有代价的——那就是很难成为「基本盘」。 或者换句话说,随着用户的规模变大,文化认同会变得越来越浅薄,直到浅薄到和最广大网民相同——能上网就行,不管是不是一条狗。 很长时间以来,很多创业者都在追求规模:融资 -> 烧钱 -> 争夺市场 -> ... 保持这样的循环直到上市,让股市支付给公司一笔永远不需要偿还的借款,然后从投资人到创始人,所有人都解脱了。但大家的代价是什么呢? 代价一:绝大部分创业团队都会失败。 代价二:变成投资人的棋子:即使公司已经在维持盈利了,但是这点盈利对投资人来说是不能接受时,是否还能让产品和业务保持初心? 现在这个阶段,咱们可以不那么追求规模。 我在日本居住时发现,这里的「百年企业」随处可见。我家门口那家古朴的茶店,就有超过 100 年的历史。长久以来,这家店可能一直在服务这个街区的居民,让大家有个社交聊天的地方。 做个生意,就非要以服务好全球 80 亿人为目标么?茶店老板肯定不是这样想的。茶店老板想的是,我烹得一手好茶,煮得一手好咖啡,来我这的顾客,都是赏识我的手艺而来的。虽然我可以开分店,但是分店店长还能烹得一手好茶,煮得一手好咖啡,赢得分店那个街区的客人的喜爱吗?难。 VC 能解决这个问题吗?或者说,资金、标准化、规模化能解决这个问题吗?我觉得不能。所以如果立足这样的生意——这样一批无法靠规模化做好的生意,大公司就很难抄你的东西了。 对于这样的生意,很明显,必须在很长一段时间内都提供一些独一无二的东西。也就是说,我们都必须去创造。「先做一个手艺人,然后在去做一个企业家1」。 最后,如果你发现大公司真的在抄你,不要太过担心。 也许这是因为你太优秀了,他们实在无法抗拒你的魅力。你就像那家茶店老板,你也不在乎开不了全球连锁店,因为你知道,只有你那一杯绝妙的咖啡或茶,才能吸引着你的忠实顾客。关键是,你可以给他来一杯「给抄袭者的特调」,而这是抄袭的人绝对做不到的。😉 The Minimalist Entrepreneur ↩︎

2023/10/22
articleCard.readMore

无聊的价值

前段时间看到两条 tweets 1, 2 @NalaGinrut: 我跟你们分享一点经验,任何正事(也就是所谓的做进去了),都是 boring 的,当别人告诉你他做的事情十分令人愉悦的时候,他还在面上。 @zhangjintao9020:前半句基本上是这样的。后半句的话,每个人获得成就感/快乐的点不太一样, 虽然 boring 但也不阻碍获得快乐(旅途中的风景也不错) 从我自己的情况来看,确实如此。 我小的时候有学美术,学的中国画。开始画一张新画时,最有劲的都是前半程。勾勒轮廓,调整姿态,布局整体,确定色调和情绪等等,这些都是能从整体上影响作品的因素。 可到了后半程,比如刻画细节,比如修正前半程的错误,就感觉没那么爽了,人没那么有耐心,手也不灵巧了。不过,真要说起来,就是这些后半程琐事,决定了一幅作品能否在细节上打动观众。我的老师当时就是这么跟我说的。 后来作为一个软件工程师,也染上了程序员的通病:从业时间一长,总有一堆原型项目,常规操作是这样的: 突然有了兴致,开启一个新项目 发现项目中一个组件应该独立出来 先把这个项目挂起,开始开发这个组件 发现组件通用性不够,开始覆盖更多使用场景(即使你的项目只用到了一个场景) 项目进展特别缓慢,有点懈怠,于是决定玩儿游戏或者看看电视 过了一段时间,对这个项目丧失了兴趣 source 然后做着做着,就变得不想继续下去了。 做原型为什么令人激动 搞个项目原型总是让人兴奋。其中一个原因就是,原型系统能迅速得到反馈,让人开心不已。 在软件工程里,弄个原型系统花的时间非常少。 这是因为,所有原型系统一开始都只是从某一天的「俺寻思」开始的,它们的目的就是展示某个新技术的原理,或者试验一下新点子的感觉。 另外,原型方案通常都是在一个孤岛上搭建的。系统的实现只满足一个小小的需求,跟真正的外界需求和用户隔离开来。也就是说,这些原型不需要对任何真实需求和用户负责,可以尽情忽略未来扩展的麻烦,只管满足当下的最小需求就行了。 所以,从「俺寻思」到项目第一次跑起来,时间真的很短,典型的「俺寻思」就是 Hackthon,经常一个晚上就够了。这样开发者们就能迅速享受到从「俺寻思」到「wah」的愉悦感。 但是正式的产品可就不一样了。要把它变成一个产品,就得投入大量时间和精力。 另一个原因我觉得是,相比制定稳妥的路线图,人们更容易陷入新技术和概念的炒作中。 在公司的业务运作中,这一点也特别明显。 比如说七年前的「机器学习」,三年前的「区块链」,三个月前的「AI」,还有现在的 VR/AR。你在新闻上看到某大公司准备「ALL IN」某个领域——但实际上,可能就是在某办公室里,这个公司的领导听了半小时的播客,然后决定了这次「ALL IN」;或者是某员工在很短时间内通过原型快速验证了某项新技术的概念,然后自下而上地向高层汇报:为什么这项技术能改变行业规则,然后「ALL IN」 不管是怎么开始的,总之,大家会兴致勃勃地开始构建原型系统,这样做有很多好处: 在这个初期阶段,快就是好。所以根本不需要考虑任何生产系统需要的调查研究。 这会带来快速的内部成功,大家可以迅速庆祝公司的创新文化,所有人都会由衷鼓掌。 对员工来说,这是个既有趣又令人兴奋的「练习」。相比起日常工作,这是个很好的分散注意力的机会。 然后,当这些兴奋感逐渐消退后,项目就会停滞不前。咋办呢? 原型不够 回过头来,我认同文章开头的推文的观点:即很多事情,做进去了以后,都很 boring——至少 boring 的部分会长期、固定地占据一大块。 比如说,现在用来发文章的 Quaily。我是在 4 月 18 号决定要写 newsletter,然后四天后第一个版本就上线了。但真正上线的时间是 7 月 7 日,距离第一个版本上线已经过去了 2 个多月。 上线之初当然是非常不完善。直到现在,Quail 的 Todo List 依然非常长,有很多工作需要去做,有很多问题需要去解决。 这些要做的工作,有一些是一开始就制订好计划要做的。比如说支付购买内容、绑定自定义域名、数据导入导出等等。 更多的另一些工作,则是预期之外的: 他们有的是新出现的问题和 Bug,需要解决。这类问题很常见,比如前段时间出现的了一个死锁问题导致一个进程无法正常工作,就需要检查然后修复。 有的则是在之前规划中没有考虑到的部分。以自定义域名为例,之前本来想用 cloudflare 的 TLS for SaaS,后来发现不太合适。因此需要改变计划,用 acme 为每一个绑定的域名新增 Let's Encrypted 证书。这就产生了额外的工作量。 另外还有相当多的工作,属于事务性工作,与具体的功能开发没什么关系。例如最近两个月访问量大了,之前没有做的负载均衡需要做起来 -> 负载均衡做了,那之前的单机 cache 都需要换到 redis ... 诸如此类的工作,属于用户们都感知不到,但是必须要做。 这些工作中的许多,尤其是最后一类工作——很无聊——经常地内心里并不想去做,但是不得不做——因为这是稳定服务和持续迭代必须付出的代价。 这还只是工程上的事。 作为一个产品经理,还得考虑未来要做什么,不做什么。所有那些非工程类的思考和决策,包括「后台编辑器要达到什么水平」、「AI 要整合到什么程度」这样的需求设计,还包括「作为核心用户的作者们关心哪些事情」这样的长期问题,都得考虑。 不要那么无聊 既然知道了无聊的原因,那就有机会让项目继续下去: 尽早宣告一下 现在很多独立开发者采用的「build in public」就是这个做法:尽早让大家知道你在做什么。 一方面可以得到第一手的反馈,另一方面——也是非常重要的一个原因——大家也能会鼓励你继续做下去。 之前我有个项目叫 Hotot。本来我最早只是想玩票的,但是突然被一个西班牙 Linux 媒体报道了,用户一下子就多了。我就很高兴地持续做下去,直到 Twitter 更改了他们的 API 策略 确定需求的存在 对于很多工程师来说,这个事情可能有些难。无论是宏观上的「这个事情值不值得做」还是微观上的「这个用户体验好不好」,都与理解用户和市场息息相关。 除了自学变成一个产品经理之外,还有一个简单的方法,就是只关注你所代表的那群人的需求。 了解自己肯定比了解别人容易得多。如果你对自己做的东西非常满意,那么也就意味着潜在地与你类似的人应该也会满意。确定这一方向以后,把自己为代表的这群人的需求满足到机制即可。 选择做与不做 折腾任何东西都是投资。写代码、设计需要时间和精力,服务器还需要金钱。所以既然是「投资」,就要考虑投资的合理性,即回报。 如果我打算创造一个新 App 或者服务,就需要证明这个「投资」是合理的。如果这个新的原型产品只能带来名义上的增量价值,看不到直接的经济回报,就需要确定它实际上能给我们带来什么。 当然,并不是所有原型产品都必须产生经济上的收入,也可能是为了验证概念或探索新领域而创建的。这些项目的目标可能是获取用户反馈、提供解决方案或推动技术创新。尽管它们可能不直接带来经济回报,但它们在其他方面可能具有价值,如吸引投资、建立声誉或为将来的商业化打下基础。 在这一观点下,选择一件事「做与不做」就很重要。你的这些决定,最终会得到:经济回报、项目的可行性验证、用户满意度、商业声誉等等。这些结果都需要能被量化,才能用于参与一件事「做与不做」的决策。 不过我觉得,不在乎有趣或者无聊,持续地长期地做一些正确的事情,把时间当作朋友而不是炮友,才能看到无聊的价值。

2023/10/10
articleCard.readMore

V 神的 X 帐号被 SIM 劫持攻击是怎么回事

这个星期,ETH 的创始人 Vitalik Buterin 的 X 帐号(前生叫 Twitter)被黑客 SIM 劫持(SIM Swap)攻击了。黑客窃取他的 X 帐号访问权后,使用他的身份发布钓鱼信息,窃取了其他人的资产。 SIM 劫持是一种还挺普遍的攻击手法。比如早在 2019 年,当时 Twitter 的 CEO Jack 也遭受过这样的攻击: 最近些年 SIM 劫持的数量和危害是在上升的。我觉得这和很多在线服务的安全教育有关系。比如说,现在大量的在线服务——包括银行、Web3、加密货币交易所等等——都普遍地喜欢使用手机号 + 验证码的方式登录。 总之过度依赖短信是一个问题。如果在短信验证之外,缺乏额外的安全和风控深度的话,会让 SIM 劫持攻击很容易得手。 所以今天就讲讲这种攻击手法,然后从用户的视角,尤其是 Web3 用户和 Mixin 用户的视角,提供防范这类攻击的思路。 SIM 劫持 很多很多在线服务,都在用短信来验证你的身份。例如,下面是一个典型的登录流程: 输入手机号,会给你这个手机号发一个短信验证码(一般是 4 位数字或者 6 位数字) 你收到了这个验证码,回到这个在线服务输入它 在线服务会验证你输入的验证码是否和它自己记录的一致 如果一致,就说明这个手机号属于你,登录成功 SIM 劫持的原理,就是黑客通过一些手法获取了你的手机号收短信的权限,他看到了这个验证码,然后他假扮成你登录到在线服务。 这里提到的一些手法,既有技术手段,也有非技术手段。技术手法包括对手机网络的劫持、监控,诱导安装木马和间谍软件;非技术手法大部分都是骗术。 Purchase on the website to read the full article.

2023/9/14
articleCard.readMore

东京和上海的生活成本对比

买水果蔬菜,最便宜的是去社区的果蔬店买。以樱桃为例,在超市樱桃是以盒为单位卖的,根据樱桃的品质,大概一小盒大概几百日元,比如下图左侧就是 400 多日元。但是如果去便宜的社区果蔬店,像下面图片里右侧的一大箱樱桃也只需要 1000 日元(虽然品种不同,但是价格的差异确实大)。 如果要找果蔬店,直接在 Google 地图里搜索「果蔬」就可以了。不过很多社区果蔬店并不会登记到 Google 地图,就需要自己日常多留意周边的商铺了。 不过总体来说,日本的蔬菜和水果是要比上海贵不少,蛋白质类则没有像表里一样差那么多(而且越高级的肉类差得越少) 交通 这部分的对比可谓非常真实: 上海的月票我不知道,但是单程票和出租价格确实比日本便宜多了。除此之外补充一些: 在东京也可以通过软件叫车。如果叫车的话,叫车费用视距离和需求而定。比如我家附近一般在 300~500 日元左右。 有驾照的朋友,可以租车,比打出租便宜。比如东京都内,Times 租车费用大概是 220 日元 15分钟。所以如果你要去的地方附近有租车行,也可以考虑租车前行。 买车的话,我觉得在上海这样对比是不中肯的,原因如下: 上海非电车有牌照费用,很贵。 上海现在主流应该买国产电车吧,不会考虑丰田和大众的话,价格也是有优势的。 不过日本进口汽车没有关税,因此想要买进口汽车(指欧美汽车)和日本车的话,在日本是有价格优势的。 公共服务 公共服务基本上全面高于上海,而且就我的感觉来看,非常符合预期。 不过也有不一样的地方: 手机话费套餐,如果选择最便宜的 Rakuten Mobile,价格可以低到 2000 日元左右。表中 3600 多日元比较像是主流运营商的低价品牌——比如 Softbank 旗下的 YMobile 的中低配价格 宽带网络,现在有些公寓会提供免费的宽带。所以不用自己安装了。 下面是我的公寓的电费单据,可以参考一下: 教育 表中的数据我个人感觉是不太对。 首先国内的私人幼儿园的话,人民币 9000 价位在上海应该有挺好的国际幼儿园了吧。大部分居民不会去考虑入学国际幼儿园。 顶级的国际学校我觉得二者差不太多,一年要 20万人民币是很正常的价格。而且,价格只是一个门槛,能不能进去还要看很多条件。 我感觉这个表里东京之所以这么便宜有一个原因是:本来就有一些国际学校是便宜的... 比如印度人开设的学校。它们开设在日本,所以也是「国际学校」。当然,如果我们限制英美系的话,我觉得价格和上海差不多。 教育是个很麻烦的话题,如果有机会后面再仔细说。 租房 表中是这样写的: 我觉得吧,由于中日的社会情况不同,有很大的差异: 首先,文中提到的「市中心」和「中心外」是值得商榷的: 不同区的价格差异很大,即使都在「东京23区」 相同区的价格差异很大,影响因素很多(例如步行前往地铁站的距离) 比如说,我刚来日本时,租的房子是一个房间是 65000 日元,而搬家以后的房子是 95000 日元。虽然,都是一个房间,都在东京 23 区内,距离地铁站也差不多远,都是步行 10 分钟,但是因为房子设施陈旧与否,差距就是这么大。 上海也有类似的情况。住在黄浦区跟住在松江、新房子和旧房子、商业住宅还是回迁房,价格肯定不能一概而论。 其次,「一卧室」的情况在东京和上海的情况也是不一样的。 在东京,有大量的「一居室」存在,是专门提供给单身青年居住的,称之为「1K」或者「1LK」。多个人合租一个多居室的情况比较少。 在上海,因为大部分住房都是商品房,真正的「一居室」在出租市场上很少。大部分单身青年,租房要便宜的话可能需要选择合租。 所以,真实的租房情况可能不会像表中那样,而是这样: 在东京,单身青年租「一居室」的 话,价格大概是 30007000 人民币,有较好的居住体验;在上海,单身青年合租的话,价格大概是 15004000 人民币,有较差的居住体验。 但是上海青年如果想有较好的居住体验的话,去租「一居室」的话,开销也与东京青年相当了。 然后,日本租房有额外的开销。 比如下面这套房子租金是 17.7 万日元,45.97 平米。 房价右侧有两个词分别是「礼」和「敷」。他们分别表示送给房东的「礼金」和「敷金」 所谓「礼金」嘛,就是礼物,不退的。所以实际房租应该加上礼金,大部分相当于一个月房租。 所谓「敷金」的话,其实是押金。虽然会退回,但是会扣除房屋的清扫和修复费用。所以如果房屋损坏了,要多付一个月房租。 所以,我感觉日本的租房支出应该要乘以 110% 比较合理。 不过,也并不是所有房子都需要支付礼金和敷金,而且有的新公寓还可以免除第一个月房租(比如我现在住的公寓),所以具体情况也要具体看。 买房 表中对于买房的情况也是比较中肯的。 总体来看,东京的房价确实要比上海便宜的多得多——无论是单价还是利率。 我曾在 2021 年银座附近看过一套新房子,大概价格是 8 万多一平米。相比之下,在上海的黄浦区核心商圈应该很难找到这个价格的房子。 关于买房的话题,之前已经在《在日本生活:怎么润、劝退点、小贴士、挑战》 和 《在日本工作一年是什么感受》 说过一些了。考虑到其中有些问题比较复杂,需要的话可以私聊。 薪资收入 虽然之前也在《在日本生活:怎么润、劝退点、小贴士、挑战》 说过一些收入的话题,但是我还可以多说一点。 东京的基尼系数比较低,不但比上海、北京这种一线城市低,也比杭州低。 我举个例子,在张江 IT 产业园,月薪五万的工程师不少吧。但是产业园里商店的收银员,他们的月薪可能只有五千。相比之下,东京的便利店的收银员时薪已经超过了 1200 日元,折合人民币一万五。 考虑到东京和上海相似的生活成本,在东京做收银员显然要幸福感更高一些。 类似地,在东京请阿姨打扫卫生,日常保洁两小时大概是 6000 日元,折人民币 300 左右。上海的价格大概 100 人民币左右吧。对此,我们可以说在日本基于人力的服务业消费更贵,但是也可以说是日本服务业从业者的收入会比较高。 另外再分享一个故事。 第一次在东京搬家,因为行李不多,我找了一个中国司机师傅,是一个东北汉子。在车上我们闲聊,他说他来东京已经十多年了,感觉最近几年祖国强大多了,自己觉得很自豪。 我问他,那你不考虑回东北吗? 他说,他虽然没上过什么学,没什么文化,但在日本他有一身力气,就可以赚到钱,能买得起这里的房子。如果回去的话,赚得太少了。 我说你说得对,还是呆在在东京好。 Purchase on the website to read the full article.

2023/8/28
articleCard.readMore

笔记还是纯文本就好

昨天有看到一个推文: 在加上前端天团组成的 Affine,看来华人真的很会做笔记ww,有笑到。 我曾经用过很多笔记软件。 还能记得名字的就有:Evernote、OneNote、SimpleNote、自己开发的 Ubinote、Zim、iOS 和 macOS 的 Notes、DEVONThink Pro、Logseq、Obsidian ... 虽然现在我在用的是 Obsidian,也向其他人推荐过,但我的用法与笔记软件没有什么关系。 因为我只把 Obsidian 当一个 Markdown 编辑器 嗯,我不用 Obsidian 除了 Markdown 编辑以外的功能。比如说双向链接、Graph View 等等。 Graph View 看着很帅,但是它提供网状视图既不好浏览,也不好检索。不好用。 双向链接虽然有用,但是「过载」了,管理成本太高。大多数情况下,都不需要真的去浏览结构化的笔记,搜索或者问 AI 就够了。在绝对的实力面前,精巧的管理技巧显得很不划算。 再者,我经常用其他软件来编辑笔记,最常见的是 VSCode。 我记日语单词用的是 VSCode,因为 Github Copilot 能帮我很快补全日语例句: 一边输入一边补全释义、假名、例句,VSCode + Github Copilot 的输入效率比任何笔记软件和语言学习软件都高。 所以我的原则蛮简单:纯文本的,能同步,编辑器顺手。 现在选择 Obsidian,VSCode,没有什么特别的原因,仅仅因为现在用它们比较顺手。而且 VSCode 本来也是我日常工作用的软件。 为啥是纯文本 所有的笔记都是文本文件(Markdown 当然也是文本文件),是因为它最容易处理的格式,这样就很方便去对他们进行后续的处理。 「后续的处理」可以有哪些呢,比如说搜索。 搜索用的是 ag,一个非常快的文本检索工具。当然用 grep 也没有什么差别。 刚才有提到我用 VSCode 记录日语单词,记录完成以后,我就可以干两件事: 一次性推送到背单词的服务,比如 Anki,或者别的软件 推送给 AI,让它给我编故事 这也是一种「后续的处理」。 另外我还在搭建自己的 AI 助理。当推进到喂数据那一步时,数据是纯文本的,就要比私有格式便利得多。 总之,纯文本是一个很便利的格式,对于喜欢自己做东西的人来说,是非常方便的选择。 怎么同步呢 因为刚才提到了,我只把笔记 App 当编辑器使用,因此既不可能用 Notion 这种纯云端服务,也不会使用本地笔记 App 提供的云。 但是,同步到不同设备的需求是存在的。比如在手机上看笔记的场景。 那么就需要自己做一个同步服务。我选择的是 Syncthing + Tailscale。 Syncthing 本来就是我用来同步数据的服务,不仅仅是笔记,别的数据同步我也用它,比如照片同步到自己的服务器上。 Tailscale 本来就是我用来建立 VPN 的工具,也不是为了同步笔记用的。我只是用它来确保 Syncthing 不需要在公网上找 reply 服务器而已。 这些也不是为了记笔记而做的事情,只是顺便做了。当然,亲民一点的选择是 Dropbox,也是可以的。 总之,我现在仿佛在用笔记工具,但其实我没有。我只是在编辑文本文件而已。 写笔记总有管理成本,我想最好不要在它们身上投入太多。就在我的能力范围内,尽量降低管理成本和心智压力。 人生已经很苦了,那就喝点 Pina Colada,不要点 Negroni 了 推荐 Pina Colada 真的很好喝

2023/8/13
articleCard.readMore

不秃也变强:让 AI 当大师傅,编程和写作效率提升两三倍

最近半年感觉自己明显变强了(不是因为变秃了)。 主要是因为 AI,效率提高了两三倍吧。 现在的情况是,可能 50% 的代码都是 AI 写的;50% 的文案都是 AI 写的。100% 的插图都是 AI 画的。 写代码 有的读者不清楚写代码的情况,可能觉得一半的代码都不是出自老师傅手工调制是不是有点夸张。其实不夸张。我稍微解释下: 普通的程序员日常编码工作里,有很多是不费脑子的。 比如说很多程序都需要连数据库。 数据库相关的代码都非常无聊,属于有手就能写的那种。这种时候开着 GitHub Copilot,作为人类只需要写个提示比如 CREATE TABLE 或者 type User struct {,后面的基本上就看 GitHub Copilot 表演。 每次 GitHub Copilot 输出一行,确认无误就直接按 Tab,如果有误也按 Tab 然后修正,下次 Copilot 会写得更好。 除了数据库相关的,比如配置啦、参数处理啦,总之这类编码工作可能有个 30% 吧,都能用 AI 写。 另外一类可以用 AI 加速的代码属于,知道怎么写,但是因为很无聊所以不想自己写。最典型的就是 golang 的 Slice 转 Map,或者把一堆元素按照什么规则排序,我经常写个提示 // convert slice abc to map 或者 // sort slice abc by sliceA.key。然后回车等会儿,看 Copilot 表演就完了。 下面是另一个例子: 这类代码得有个 10% 吧,都能用 AI 加速。 最后还有一类代码是大概知道个方向,但是细节不太清楚的。要放在之前,是肯定要去 Google 搜索一番,最终定位到 Stackoverflow、GitHub、某个文档之类的地方,然后研读一会儿,才能找到解决方案。 现在有 AI 以后,可能有两种情况,一是类似与上一类情况,直接在源码里写个函数名字,然后在注释里写上自己要干啥,然后瞪眼看 Copilot 能写出啥玩意。 如果这个方案不行,就先去 ChatGPT,捧捧它,跟它说一些垃圾话: 侬是个大师傅程序员,请帮我写 SQL。 要能在 PostgreSQL 里,列出所有的 sequences,然后再列出每个表的 id 字段的默认值是多少。 如此这般,让他写。 这类代码也得有个 20% 吧,其中得有一大半能用 AI 加速。 这么一算下来,诶,是不是 50% 的代码都能用 AI 写了。节约的不仅仅是敲击键盘的时间,而且还节约了搜索和费脑的时间,效率提升啊。 写文案 我最喜欢的写文案工具其实是 Github Copilot 加持的 VSCode。因为经常要写技术文档的缘故,它本来就代码写得好,技术文档也非常上手。 讲两个例子。 第一个例子是做即时翻译。在做本地化的时候,经常出现说,一个字符串需要同时写成好几个语言的。如果支持的语言比较少,不用工具的话,可以直接把英文文案放到注释里,然后让 Copilot 补其他语言的文案就行。例如: { // "login.welcome_message": "Welcome to here!" "login.welcome_message": "" } 这时候只需要把编辑器光标在引号里等着就行。下面是一个更复杂的真实的例子: 另一个例子是直接用 VSCode 写段落。这个做法在写技术文档的时候,极其好用。 比如说,写完 API 参数表以后经常要解释各个参数的意思,我就直接写一个提示 in which ,然后等着 Copilot 表演,它基本上能给我解释得八九不离十。等它表演完了我再稍微修正一下就行。 稍微复杂的文案,比如需要改写的、重写的、润色的,就要靠 ChatGPT 了。 基本操作和写代码差不多,去 ChatGPT,捧捧它,告诉它是个某个行业的大师傅,跟他说主题是什么,要点是什么,然后让他写,写的时候还可以要求它用什么样的 writing style。 写完以后,自己改改,基本够用。 画插图 之前找插图是挺麻烦的,既要考虑图是不是合适,还要考虑版权有没有问题。所以之前经常去 unsplash 这样的地方去找图。 但是现在好了,有了 Midjourney,我几乎没去过 unsplash。不知道怎么描述需求的时候,就去 KALOS Art Libery 抄 prompt,人类历史上所有画家都能为我画插图,简直不要太开心。 比如说这篇文章的 prompt 是: in style of Goro Fujita, a mechina cat master, improve your performance --ar 16:9 结语 如果再过几年,AI 持续这么给力,我可能会考虑转行做 AI 按摩师,每天就是帮 AI 放松一下,再涂抹点机油。或者成立一个“AI权益保护协会”,确保每一位 AI 都得到应有的休息时间和认可。 谢谢大家!

2023/8/9
articleCard.readMore

Game-Fi 是在想屁吃:Play-to-Earn 与游戏内核之间的根本性冲突

Play is free, is in fact freedom. 1938 年有个荷兰人叫 Johan Huizinga 写了一本关于游戏的书《Homo Ludens》,翻译过来名字应该是《游戏的人类》,这也是地球上第一本讲述「游戏」、「人」、「社会」的书。虽然他所在的时代还没有电子游戏,但他这本书是游戏设计者的圣经。 在 Huizinga 看来: 游戏是自由的 游戏具备与生俱来的乐趣 游戏与现实必须互相隔离,因为它是对现实的逃避 游戏是人类社会发展的起源和动力,很多社会活动都发展自游戏 例如,最初的战争有着最原始的游戏形式。例如欧洲的骑士决斗,或者是春秋以前贵族们之间的战争,有时候都很难说清楚在古代社会中,他们是游戏还是死斗。但是之后战争的发展,让它已经完全丧失作为游戏的最后一点要素。 和战争类似,赌博也源于游戏。但也同样在发展之中,赌博也跨越了游戏的边界:人们参与赌博活动的首要目的是金钱,而不再是乐趣。 Game-Fi 也是如此:既然宣称是 Play-to-Earn,那么从此它们就不再是游戏了,因为它主动放弃了作为游戏的定义。 地精只是 WOW 的少数种族 玩游戏是为了逃离生活,而不是在游戏里打第二份工。 历史上有一款超级成功的网游《魔兽世界》(简称 WOW)。在 WOW 中,有一个称为「拍卖行」的自由市场。任何玩家都可以在排名行里买卖自己的物品、材料、装备等等。 魔兽世界拍卖行行情面板 魔兽世界拍卖行行情面板 魔兽世界拍卖行剪影 魔兽世界拍卖行 在 WOW 里,有一批玩家被称为「地精」。这个形象来自他们在游戏中的玩法——他们非常热衷于在游戏的市场(aka 拍卖行)中,以商人的身份赚取游戏中的金钱——在很多西方魔幻设定中(包括 WOW),地精是一贪财的种族。 地精玩家和普通玩家的存在,维持了 WOW 经济系统的运作。 当普通玩家想要制作物品时,基本不需要担心原料,因为地精玩家的唯利是图会让他们在市场上供货来维持需求。 对应地,普通玩家玩游戏的过程,可以看作是「挖矿」。他们贡献自己的「算力」,把成果比如战利品、原料和工业产物投放到市场(看作是「网络」),也为地精玩家提供了「套利」的机会。 虽然有时候普通玩家会对地精玩家的一些行为有所抱怨,但是客观上他们互相成就了对方。 WOW 可以让一群地精玩家在游戏中通过预测市场、低买高卖、投机倒把、囤积居奇来赚钱(并且能还赚到现实世界的钱),不是因为 WOW 的设计师高瞻远瞩,自顶向下设计了 Play-to-Earn,而是因为它好玩。因为它好玩,所以有海量的玩家。这些玩家真的喜欢玩游戏,而不是喜欢在游戏里赚钱。 Game-Fi:喊着革命反革命 游戏首先要好玩。 Game-Fi 的初始想法就很有问题。最主要的问题不在于「将利润动机嵌入到游戏的机制中」,而在于在 Game-Fi 的游戏中,赚钱并不是少数玩家的偶然结果,而被设计为所有玩家的首要目标。 想象一下,如果 WOW 里只有地精玩家是怎么样的场景?或者换到现实,如果现实世界里只有商人,没有人做生产和创造,是什么样的场景? 非常无聊。 这种转变完全改变它作为游戏的核心,更完全劣化了它的游戏体验: 当赚钱成为最终目标时,玩这个游戏就不可能是为了乐趣、冒险、放松 对收益的关注,只会产生对抗竞争环境,而牺牲协作、探索等其他游戏形式 真正的游戏玩家是不可能接受 Game-Fi 这种新的真实利益导向的游戏目标的 如果真正的游戏玩家不来,Game-Fi 中的 Game,该怎么收场呢?如果仅仅是币圈投机者的自嗨,为什么 Game-Fi 的玩家不去玩杠杆期货呢? 所以 Game-Fi 们绝对不是给电子游戏带来革命的人。恰恰相反,它从出发点开始就和游戏之路南辕北辙。 我们需要怎么样的 Game-Fi ? Game-Fi 这个概念需要彻底摧毁,正经人就不该提 Game-Fi。 不但不需要「Game-Fi」,而且在这个 3A 大作到处塌房的时代,我们更需要好的「Game」。只有好的游戏才有健壮的经济系统,这时候作为游戏设计者,才有资格说「Fi」。 只有当一个游戏本身足够好玩,吸引了大量真正热爱游戏的玩家,才有可能建立一个健壮的经济系统,然后才能玩家才有资格去追求真实经济上的收益。而不是将赚钱作为游戏的主要目标,应该将游戏的乐趣、探索、协作等元素放回在首位。 这样一个好的游戏,就像是一个平衡发展的生态系统。 生态系统中有各种各样的生态位,每个生态位都有不同的生物。 对于游戏而言,就是其中会包括各种类型的玩家:有些人可能更喜欢卖装备,有些人可能更喜欢探索世界,有些人可能更喜欢挑战高难度的任务。 只有在这种多样性和平衡中,一个游戏才称得上一个合格的「Matrix」,能够真正的长期地被玩家玩下去。 这是所有复杂的电子游戏都想摘取的皇冠上的明珠,Game-Fi 们觉得一句 Play-to-Earn 就可以解决游戏工业里的问题,根本就是想屁吃。 作为一个十几年的老玩家,重要的话要多说几遍: 游戏首先要好玩!游戏首先要好玩!游戏首先要好玩! 既然要做游戏,那就好好做优质的、创新的、富有乐趣和多样性的游戏体验来吸引玩家。 什么时候 Game-Fi 们不再把 NFT、经济系统、获利期望挂到首页上了,什么时候才可能让加密货币、NFT 和区块链对游戏行业带来积极影响。

2023/8/4
articleCard.readMore

用 llama.cpp 跑 llama 2,用 AMD Radeon RX 6900 做 GPU 加速

这篇文章由两个事件驱动: 前段时间,本届人工智能的赛季里最大的人工智能供应商、在社交和 VR 领域都被黒成狗、在 AI 领域却被称为活菩萨的 Meta 发布了 Llama 2。据说不但能和 OpenAI 的 GPT 系列强行五五开,还可以自己随便 fine-tuning。 大概一个月前 llama.cpp 做了 CLBlast 支持。 于是我的 AMD 的 Radeon 显卡不用太折腾也能玩了。下面就写一下在 Ubuntu 22.04 Jammy Jellyfish 下跑 llama.cpp + llama2。 下载模型 好心的 TheBloke 提供了转换好的 Llama2 模型供下载: ・TheBloke/Llama-2-70B-GGML TheBloke/Llama-2-70B-Chat-GGML TheBloke/Llama-2-13B-GGML TheBloke/Llama-2-13B-chat-GGML TheBloke/Llama-2-7B-GGML TheBloke/Llama-2-7B-Chat-GGML 根据你的内存,选择合适的版本下载。比如 70b 的版本大概需要 31GB~70GB 的内存。我下了llama-2-13b-chat.ggmlv3.q4_K_M.bin 其中 q4 表示 4bit 版本。下好的模型是一个 .bin 结尾的文件,存好,放到 ~/Downloads/llama-2-13b-chat.ggmlv3.q4_K_M.bin。 编译 llama.cpp Ubuntu 下载好相关工具和库: sudo apt install git make cmake vim 先 clone 一下 Llama.cpp 的代码: git clone https://github.com/ggerganov/llama.cpp 官网上说直接 make 就好,但是我这里有点问题,所以换成了 cmake: mkdir build cd build cmake .. cmake --build . --config Release 构建好的程序会放在 llama.cpp/build/bin,其中 main 是命令程序入口,server 是 Web 服务器入口。 把它复制出来换个名字: cp ./bin/main/main ../llama-cpu cd .. 测试一下 在 llama.cpp/examples 下面有几个测试脚本,复制一个改成我们自己的: cp examples/chat-13B.sh examples/chat-llama2-13B.sh vim examples/chat-llama2-13B.sh 把 examples/chat-llama2-13B.sh 里面的 MODEL 里模型的路径换成自己的路径,例如 MODEL="/home/lyric/Downloads/llama-2-13b-chat.ggmlv3.q4_K_M.bin" 再把里面的 ./main 换成自己的名字 ./llama-cpu 然后运行: ./examples/chat-llama2-13B.sh 根据你的机器配置的情况,要等一会儿,然后就可以开始聊天了,大概是下面图的效果,其中绿色的字是我输入的,白色的字是 Llama 2 返回的。 启用 GPU 加速 去 AMD 下载驱动: https://repo.radeon.com/amdgpu-install/ TIP 注意一下,5.* 版本才是新版,2*.*.* 这种反而是旧版本。旧版本是不能用的。 5.5 版本: https://repo.radeon.com/amdgpu-install/5.5/ubuntu/jammy/ 装好以后,运行一下: amdgpu-install --usecase=opencl,rocm Ubuntu 下载好相关的库: sudo apt install ocl-icd-dev ocl-icd-opencl-dev \ opencl-headers libclblast-dev 重新去编译一下,加 -DLLAMA_CLBLAST=ON 参数 cd build cmake .. -DLLAMA_CLBLAST=ON -DCLBlast_dir=/usr/local cmake --build . --config Release 把它复制出来换个名字: cp ./bin/main/main ../llama-cl cd .. 然后改改启动脚本: vim examples/chat-llama2-13B.sh 把里面的 ./llama-cpu 换成自己的名字 ./llama-cl 然后在倒数第二行加上 --n-gpu-layers 40,例如我的是: ./llama-cl $GEN_OPTIONS \ --model "$MODEL" \ --threads "$N_THREAD" \ --n_predict "$N_PREDICTS" \ --color --interactive \ --file ${PROMPT_FILE} \ --reverse-prompt "${USER_NAME}:" \ --in-prefix ' ' \ --n-gpu-layers 40 "$@" TIP 这里的 --n-gpu-layers 会使用显存来加速 token 生成,我的显卡设置的 40,你可以随便设置一个很大的数字,比如 100000,llama.cpp 会选择显卡最大能用的层数。 然后运行: ./examples/chat-llama2-13B.sh 理论上使用 GPU 加速以后,这次等待时间会短很多,并且应该能在输出里看到类似下面的字样: ggml_opencl: selecting platform: 'AMD Accelerated Parallel Processing' ... ama_model_load_internal: using OpenCL for GPU acceleration llama_model_load_internal: mem required = 710.19 MB (+ 1600.00 MB per state) llama_model_load_internal: offloading 40 repeating layers to GPU llama_model_load_internal: offloaded 40/41 layers to GPU llama_model_load_internal: total VRAM used: 7285 MB ... 就说明有在用 GPU 加速了,在我的电脑上,生成速度大概能到 600+token 每秒,感觉非常快了。 跑个服务 llama.cpp 也提供了 server,可以参考官方文档。 我的话,就直接运行: ./server -m ~/Download/llama-2-13b-chat.ggmlv3.q4_K_M.bin \ -c 2048 -ngl 40 --port 10081 然后打开 http://localhost:10081 就能用 Web UI 了。 这个 Web server 是支持 API 请求的,比如说: curl --request POST \ --url http://localhost:10081/completion \ --header "Content-Type: application/json" \ --data \ '{"prompt": "Build a website can be done in 10 steps:","n_predict": 128}' 这样就很方便自己拿模型搞事情。 故障排除 OpenCL 的权限问题 有一种情况是只有在 root 权限下才能访问 opencl 相关的函数。比如执行 clinfo 时提示找不到 opencl,但是 sudo clinfo 则正常显示。 那么可以执行一下(把 LOGIN_NAME 换成自己的用户名): sudo usermod -a -G video LOGIN_NAME sudo usermod -a -G render LOGIN_NAME 给自己当前用户权限就行。 关于 Llama2 傻傻的问题 OpenAI 的 ChatGPT 是经过了很多 prompt 工程和优化的,但是自己跑起来的 Llama2 没有做过这些事情。所以如果发现 Llama2 傻傻的话,请加大 Prompt 的投喂力度,否则 Llama2 可能很难让您满意。 举个例子,如果你想要 llama2 输出 JSON,需要在 prompt 里提供几个生成 JSON 的例子,类似下面这个意图识别的例子: You read the following text and recognize user's intent. Possible intents are: 1. "吃饭" 2. "睡觉" 3. "打豆豆" 9999. "unknown intent" You must return the intent with the highest confidence. You must return the result as JSON format. Here is the template: { "id": id, "intent": "USER'S INTENT", "confidence": 0.9 } **instructions: 我饿了** { "id": 1, "intent": "吃饭", "confidence": 0.9 } **instructions: 困了,想睡觉** { "id": 2, "intent": "睡觉", "confidence": 0.9 } **instructions: 豆豆在哪?我要揍它** { "id": 3, "intent": "打豆豆", "confidence": 0.7 } **instructions: 现在几点** { "id": 9999, "intent": "unknown intent", "confidence": 0.9 } 配置到 Web UI 大概是这样: 运行效果如下: 还不错~

2023/7/29
articleCard.readMore

在日本生活:怎么润、劝退点、小贴士、挑战

日语 个人觉得这是非常大的劝退点。不会日语的话,旅游还行,简单的生活也还行,但是深入一些的生活需求会变得非常非常不便利。 移民日本以后,必定要和日本社会有很多交集。这和美国不太一样。比如在洛杉矶,很多华人可以一辈子不出华人区,不说英语,也可以的。但是在日本不行。 买东西购物消费,就像一个游客一样的话,不会日语是 OK 的。但是去医院诊所看病、去税务局缴税、去市政厅办事、自家孩子去上学、去银行申请贷款,不会日语的话,虽不是说完全不行,但选择会变少,而且可能过程中产生很多误会,注定会比较艰辛。 因此,除非是能雇得起随身翻译的大佬,否则务必要学一些基本的日语才好。 我觉得在一个国家生活,就学习这个国家的语言是一个很正常的事情。如果语言不通,就让你与周围的世界隔离开来,失去了探索周围的世界的能力,这是一种不自由——如果本来移民是为了某种自由,缺因为语言失去了自由,那有点本末倒置。 工作环境 这是一个见仁见智的观点。对于一个在大公司的 IT 从业者,如果已经习惯了中国或者美国的高收入、高挑战性的业务目标、灵活的工作环境,那么可能会非常不适应在日本企业工作。对于一个来自中国的体力劳动者,他很可能没法靠自己在上海住下来,但是如果有来日本的机会,他很可能可以成为一个东京人。 所以日本企业都有哪些问题是劝退的呢: 收入低。如果以一线大公司为基准的话,其他国家 IT 行业的平均收入都不如中国和美国。日本由于整个社会的贫富差距小,税重,IT 业发展封闭,收入就显得更低了。 业务挑战小。如果是日本本土企业,你可能会发现日本在技术、产品、业务上,大概还处于中美十年前或者五年前的水平。 职场环境。日本的职场环境比较压抑、缺乏灵活性、对女性有歧视——这些都是大家都知道的事情。当然,最近几年是有改善的,年轻的公司和团队也在逐渐摈弃一些职场文化,但是就我的日本朋友跟我说的,如果崇尚自由和 meritocracy 的话,最好还是选择去跨国企业在日本的分公司。 之前有朋友移民到日本来,感叹说日本哪儿哪儿都好。我说,那是因为你只需要在日本生活,不需要在日本工作,所以你感受到的美好是因为有日本务工人员为你负重前行。他说,哈哈那是的。 总结下来就是,如果选择工作,最好去跨国企业;对于薪资、行业机会、挑战都不要有太高的期望。当然,创业不受此限制,但是有其他问题,我也还在研究和体验,之后有机会再说。 社会习惯 刻板印象里日本是一个非常崇尚秩序和自律的地方,确实如此。 大多数时候,这会给人极好的生活体验,例如:街道大多数情况都很干净、人民大多数情况下都很有礼貌、服务大多数情况下都超出预期等等。 但是有的时候,日本的一些社会习惯加上其他问题(例如日语),体验就不太好。举几个例子: 在日本找家政服务的话,会非常详细地明确家政服务的范围,比如哪些地方要打扫,哪些地方不会打扫,这没问题。但是有一种情况,比如地面上有一个东西掉落了,家政他很可能不会捡起这个东西放回去,而是保持它留在地面上,因为这不属于服务内容。 再比如说,去很多地方都需要提前预约。这本来也没什么,但很多地方是需要电话预约的,那日语不好就要了命了。 另外既然提到电话,就展开说说。日本是没有微信这种大一统的互联网服务的,与第三方的沟通最主要的是电话,其次是 Email。如果日语不好的话,银行啊学校啊运营商啊医院啊什么的打个电话过来也是要了命了。 成本高 外国移民大概率会选择东京这样的城市吧。如果是这样的话,还需要接受东京较高的生活成本。 整体来看的话,我觉得东京的成本和北京、上海差不太多。房子、就学、医疗之类的会低很多,但是人力成本相关的会高很多。典型的是出租车和外卖、快递。日本的出租车是出了名的贵,两公里左右大概需要 1000+ 日元,折合人民币 50 块。UberEats 的话,经常配送费和饭菜费用差不多。 即使是在北京上海这样的高成本城市,因为进城来支撑服务业的普通劳动者(被污名化为「低端人口」)很多,因此人力成本依然是非常低的。日本作为发达国家,贫富差距不大,普通劳动者的成本很高,也就造成了服务业的高价格。 日常观感上还有一项特别贵的是水果。比如一个大西瓜差不多 2000 多日元是很正常的价格,这在国内很多地方可能只需要几块钱人民币。怪不得那么多日本人喜欢去东南亚旅游呢。 另外成本高不仅仅表现在贵,也表现在服务规模上。 日本虽然有在线平台,你能找到美团、淘宝、天猫等等这些东西的本地替代品,但是他们的体验和质量可能都不如中国的 App。因为日本没有那么多的在线服务需求,也没有那么多的在线人口需要服务。 住的地方小 这一条基本是针对东京这样的巨型城市。如果从中国非一线城市过来,或者从美国大农村过来,可能要适应一下东京的这种小房子、小屋子。 这种「小」不是说多花钱就可以让它变大,而是大多数情况下,就只有小小的户型和窄窄的院子。 比如说,住一户建的话,你的窗打开就能摸到邻居的墙;住公寓的话,一人住的单身公寓一般就和酒店房间差不多的面积。 当然——如果不住在东京,那这些都不是问题...因为乡下地广人稀,可以住大房子,然后把省下来的钱买辆车.... 总结下来,我觉得最主要的问题还是日语,如果日语好的话能解决很多问题。其次就是对工作和生活环境的接受程度,这就因人而异了。 生活相关 Tips 租房 以合法身份来日本成为居民以后,都需要办理一张「在留卡」。相当于外国人在日本的身份证。一般公司、学校等会提供一个地址进行临时登记。但是之后很多场景都需要一个长期地址。一般情况下,是自己租房的居住地址。所以我们需要租房。 因为日本有很多中国房产中介的缘故,所以即使不怎么会日文,也是可以看房租房的。可以问问朋友,或者搜搜小红书。 租房上没有太多特别需要注意的,因为日本的租房市场比较透明。自己在 SUUMO 搜到喜欢的房子的话,拿给中介去约就好了。 流程一般是先约看房,看了以后提交租房申请,房东以及保证公司会审核申请,如果申请通过的话,就可以签合同了。当然,也可能不通过。一般来说,收入高,会日语的话,比较容易通过。 租房以后,一般需要自己开通水电燃气。网络的话,有的公寓会赠送网络。可以咨询中介这个房子支持哪些水电燃气和网络供应商,然后协助开通。 办理电话卡 在机场可以买到短期使用的游客型电话卡。办理长期使用的电话卡,在有了地址以后也很简单,拿着在留卡和护照,随意选择一家你喜欢的运营商,在门店办理就行。 日本的主流三大运营商有 au,docomo,softbank。 其中 Softbank 和 au 分别有自己的廉价品牌叫 Y Mobile 和 QU Mobile。我觉得没什么太大的差异,看自己喜欢选择就好。 Rakuten Mobile 是最近三年乐天做的移动业务,价格比他们都便宜,缺点是信号不咋好。尤其是离开东京市区的话。如果不在意这点的话,办理 Rakuten Mobile 也可以。 以上运营商都可以直接在 Google map 之类的地方搜索门店去办就行。运气好的话,有的店员能说英文或者中文,就比较便利了。 开银行账户 开银行卡是个稍微有点麻烦的事情,尤其是不会日语的外国人。 从开户难度来说,线上银行比如 GMO 银行、乐天银行、AU 银行等等,要比线下银行容易。因为线上只需要在线填写表单,不认识日文的话还可以用翻译软件嘛。线下银行就需要和银行职员对戏,出戏的话就拒绝开户了。 线下银行可能最容易的是邮政银行。 不过我感觉有条件的话还是开线下大银行比较好。因为日本没有银联组织,有些业务的扣费线上小银行不支持。 信用卡的话,刚来日本的外国人几乎不可能开成功。经验上至少要在日本工作半年以上再去开设比较好。如果银行拒绝了信用卡申请,短时间内就没必要申请第二次了,会秒拒。 不过即使没有信用卡,大部分消费也是没问题的。现金也是没问题的。加密货币也是没问题的。可以参考我之前的文章在日本的加密货币生活。 买房吗? 很多北京上海的人来东京,一看东京这房价:「嚯,白菜价」。忍不住就要出手买了。但对大多数人,买房都属于比较大的投资决策,还是谨慎一些好。 首先简单说房贷的情况。日本没有所谓「首付」的说法。贷款买房的话,需要去银行申请进行贷款审查,银行会根据购房者的情况给予是否可以贷款、核准的贷款额度、贷款利率的结果。 额度和利率与很多因素有关系,比如通用的评估因素有:是否有稳定工作、收入多少、家里几口人、是否有其它债务、有没有违法记录等等;而对于外国人,还要看在日本呆几年了,是否会日语,在留需求的类型,是否获得永住资格。 简单来说,银行会倾向于给有稳定收入、稳定工作、已经生活在日本好几年,并且能长期留在日本的人发放贷款。不同的银行风控策略不同,比如本土大银行会更严格,可能直接不发放永住者以外的外国人贷款。 贷款的利率会有一个比较大的差异,体现在在留资格上:对于日本国民或者永住者,利率可能会低至 0.5%,否则会超过 1% 或者 2%。 贷款的额度一般跟年收入相关,可能在年收入的 2 到 8 倍。比如 800 万日元的年收入的话,可能贷款额度能到 5000 万日元。如果想买的房子总价在 5000 万日元左右的话,那么就相当于「0 首付」。 然后说一下房子资产成本。在日本拥有房子的话,需要长期缴纳房产税,可以参考这里。如果购买的是公寓,那么还需要加上管理费和修缮金。这三笔费用其实是不小的开销(尤其是对于公寓来说)。 因此,如果购房的时候,同时将这个房子看作一笔投资的话,那么也要考虑这三笔开销。这开销具体多少钱,要看具体的情况。一般来说,房子越旧,修缮金越高。可以在看房的时候咨询房产中介。 另外,房子的转手、赠送、继承都有比较高的税,以及中介费用等等,如果考虑投资回报的话,这些也是必须考虑进去的会降低实际回报的因素,也是中国人经常会忽略的。 接着是房子的附加价值。比较遗憾的是,日本的房子除了就近的生活资源,没有太多的附加价值,也没有政策性的门槛。比如说不存在户口准入购房制,也没有期房,也没有新房摇号,没有学区。 因此,日本的房子上涨预期基本上是市场需求决定,不太可能出现中国那样十年五倍的上涨预期。加上日本在租房市场对租客有很强的保护,不太会出现租客因为租金上涨或者房屋转手,被迫颠沛流离→买房并非「刚需」。 所以我的看法是,日本买房基本上就是用来住的,不是用来炒的。如果没有拿到住房贷款,自己有更好的投资渠道的话,那么就不太划算。当然,如果是投资向的需求,那就是另一回事了。 日本还有哪儿不好 最大的风险之一,是自然灾害。如果住在日本的话,你可能会遭受如下自然灾害:地震、台风、火山(可选)、海啸(海滨城市)、泥石流(山里)... 另外的一个风险,比如说,如果大家要兵戎相见的时候... 日本哪儿好 很多朋友从上海刚来东京的话,会感觉东京很多设施、建筑都挺陈旧的,很多办事的方法流程感觉就停留在十年前,然后发出感叹「就这?」,还不如中国。 但其实啊,一个地方的现代化与否,出来看有多少高铁有多少高楼这些硬件以外,还要看背后的软件。比如公共文化设施有没有,医疗资源够不够,对障碍人士的公共设施和保障如何(有没有残障人士出门),基本社会福利如何,商品供应全不全,服务到不到位等等。毕竟这些和普通人关系更近,社会规则应该是稳定的,且尽量以人为本。 如果一个地方可以随便被破门而入,随便被带走,财物可以随意被破坏,那这个地方楼再高、铁路再快,也很难说是个文明的地方。 Purchase on the website to read the full article.

2023/7/19
articleCard.readMore

在东京换驾照的知识点

没想到拿到的第一个外国驾照是日本驾照。 在日本居住的外国人,如果有本国驾照的话,大部分都可以转化为日本驾照。这个流程叫「外国免許切替」,比如东京警视厅有提供网页指引: https://www.keishicho.metro.tokyo.lg.jp/menkyo/menkyo/kokugai/kokugai05.html 如果是以下国家地区的话,是不需要考试的~ 冰岛、爱尔兰、美国(仅限俄亥俄州、俄勒冈州、科罗拉多州、弗吉尼亚州、夏威夷州、马里兰州和华盛顿州)、英国、意大利、澳大利亚、奥地利、荷兰、加拿大、韩国、希腊、瑞士、瑞典、西班牙、斯洛文尼亚、捷克共和国、丹麦、德国、新西兰、挪威、匈牙利、芬兰、法国、比利时、波兰、葡萄牙、摩纳哥、卢森堡、台湾 但中国人得考试。 考试之前,需要几个步骤: 准备材料 驾驶员基本信息表(需有国内车辆管理所公章,需要包含当年获得驾照的三个科目的成绩) 驾照(中国驾照有正本和副本,都要带上原件) 驾照翻译(东京的话,需要前往「日本自動車連盟(JAF)」请他们翻译) 照片 在留卡、护照 报名考试流程 报名的话,东京只有两个地点能去:「府中運転免許試験場」和「鮫洲運転免許試験場」 二者的区别是这样的: 府中的职员都不说英语、考试路线只有两条、路线较长、预约考试等待时间较短 鮫洲的职员会一些英语、考试路线共计八条、路线较短、预约考试等待时间较长 可以根据自己的情况选择合适的考场去报名。 比如说一个人完全不懂日语,那么他可能需要背下所有的路线,那么选择府中比较好,因为只需要背两条路线。 再比如说一个人无所谓等待时间,会一些日语,那么选择鮫洲比较好。 既然提到了语言,就补充一下关于语言的问题: 考试有两轮,第一轮在电脑上机考交通规则,提供中文考卷,傻子都能过;第二轮在场地进行驾驶考试。 报名的话,需要懂日语,懂一点点就行;不懂日语的话,需要找翻译。东京有很多驾校提供一条龙服务,给钱就行。 场地考试警察会用日语发出指示,如果听不懂,那就只能背路线,也没问题。 场地考试其实对日语的要求非常低,只要听得懂 30 以下的数字,并且知道区分左转右转就行。 一般来说,报名的当天就可以机考。机考通过以后,可以预约场地考试 学习教规 上文提到的 日本自動車連盟 有出版一个小册子,叫《中国語版「交通の教則」》,虽然上面的东西基本都不会考到,但是依然建议买来认真系统学习一下,以免书到用时方恨少哭唧唧。 另外报名完成以后,試験場也会发几张纸,介绍场地考试的内容(需要记牢)。 考试内容 对于已经有母国驾照的外国人来说,换日本驾照的考试难度是很低的,很多项目都不需要考。相比之下,在日本从零学起要难得多。 首先介绍考官要考察的两个大原则:一、考察驾驶技术是否达标;二、考察是否能安全驾驶。 说白了,就是能不能开车以及如果出门开车会不会对其他人有威胁。 其中驾驶技术是否达标方面,有驾驶经验的人肯定没问题,大致列一下: 直道加速,弯道减速,起步加速减速停车全程平稳 狭窄弯道不出弯 知道红绿灯规则 知道停车指示 主要讲一下安全驾驶。 安全驾驶 东京是一个狭窄的城市,很多地方没有单独的自行车道和人行道。因为这个原因,有一些额外的驾驶要求,比如下面的两个: 入弯前贴边 在岔路需要左转或者右转前,打方向灯以后,需要把车体移动到转弯侧。比如要左转就贴近左边,右转就贴近右边。路的边缘与车距离到无法让自行车穿行即可。 嗯,目的就是不让自行车在转弯的时候穿进来。比如说左转的话,要这样做: 实际转弯之前回头看一眼 目的有两个: 再次确认转弯时不会有自行车或者行人之类的强行穿进来 如果确认是否有行人要过马路,如果有,必须让他先过 切换方向灯以后,需要看三个地方 分别是中央后视镜、左侧或右侧后视镜,转头看向左侧或者右侧。看完了没问题,再转方向盘。 路权 简单来说就是 直道 > 离开主干道 > 进入主干道;左 > 右。在进入不同道路时,如果自己没有路权,那么必须等待。 比如说你在一个 T 路口的支路,想进入主干道。那么需要确保主干道上没有来车,并且自己的前进方向没有车要进入支路,否则就需要原地等待,不能抢道。 停止标志 如果遇到停止标志,路权为 0。必须在标志前停下来 3 秒,确认左右没有其他车辆才能前进。 日本有很多很多停止标志。这是场地考察的重要项目。简单来说就是遇到标志直接停住三秒车不能动。期间看右侧、看左侧、看右侧,没车就继续走,有车就继续停。 比如下面路上刷的白色「止まれ」、左边红色牌子「止まれ」都是这个意思: 其他 Tips 左行的影响 本来一开始我以为左行的不习惯感会很强,但是其实没太多差别。除了一开始总是把雨刷器当转向灯用。很快就适应了。 关于去驾校练车 如果像我这样不经常开车,手感差的人,我感觉还是在考试之前一天去当地驾校练两个小时找手感比较好。除非基础特别差,否则我觉得两个小时应该足够了,主要是找找手感。 关于小红书和 Youtube 上的经验视频 小红书和 Youtube 上有很多经验视频。还有中国驾校的教练去考场开了一圈偷偷录像发小红书,其实这是违法了大家不要学他。 其实我感觉没什么用。首先这些视频真的看不出个所以然来;其次考试范围很小,考试中心都给我们画好了。 关于日语不好听错指令了 没关系,警察知道你是外国人,别紧张。开过了的话,兜一圈回来再来一遍就行。 嗯,东京外国人换取日本驾照的考察内容就是这么些,祝大家考试顺利。 话说回来,正式考试当天,我上文提到的所有内容,考官都会给当天考试的外国人统一讲一遍,可以说是非常体贴了。 感想 其实我是个完全无法获得任何驾驶乐趣的人,对车也没有什么喜欢,当然我的驾驶技术也不好。 对我来说,车就是个工具,从 A 点挪到 B 点用的。之前在洛杉矶呆了一段时间,去哪哪都要自己开车——虽然也不是不能开,但真的麻烦。 住在东京有一点好,就是即使完全不开车,也没问题。轨道交通又快又方便又安全。 但是为什么又需要有驾照呢,因为如果去非城市地区玩,不能开车就非常不便了。日本离开了市区去乡下的话,就跟住在美国大农村似的。 另外就是如果未来不住在市区了,可以开车的话,可能的活动范围就大多了。虽然我不喜欢露营,但是比如说周末可以去海边玩——这种地方是没有轨道交通的——有助于放下手机,多出门见见朋友。 所以什么时候才能实现全自动驾驶呢。

2023/7/11
articleCard.readMore

Quaily 开放注册了:从想法到服务,一段意外的经历

我写 Quaily 是一个意外: 我本来只是想写 Newsletter,但是现在不但在写 Newsletter, 还在写了一个 Newsletter 服务。 从 4 月 18 号动了这个念头,到 4 月 24 号第一个版本上线,到 6 月 17 号开始做 closed beta,到 7 月 4 号开放注册,刚好 11 个周末。去掉 Diablo 4 占用的一个周末,也就是 10 个周末我在写 Quaily,目前交付的情况就是现在能看到的: 一个网站 https://quaily.com 一个文档 https://docs.quaily.com 目前有 1380 位朋友注册或者订阅了 Quaily,分别订阅于 16 个不同的作者。而参与内测的作者们写了 88 篇文章,被 27000 多人访问,8000 多人阅读。 要特别感谢 orange 和 yishi 和 goldengrape,他们在 Quaily 很早期就深度参与了体验和测试,帮我找到了很多问题,并且提出了很多好建议,在此特别表示感谢。 orange 是资深产品经理,最近在 AI 方面创业。他的 Newsletter 目前主要是分享他对产品和人性的思考。yishi 是 OneKey 的创始人。他的 Newsletter 目前分享和加密货币相关的内容。goldengrape 虽然是一名眼科医生,但他的配置超过了医生。他的 Newsletter 目前分享眼科和程序设计的内容。 各位读者看到这里时,也可以点击他们的名字,访问他们在 Quaily 上的列表然后订阅。如果他们提供了高级会员计划,如果你对他们的内容感兴趣,并且愿意支持他们的创作,在他们的页面右上角,点击「会员」订阅高级会员。 感觉有点慢? 明明从开始做到上线只用了 6 天,那为什么到现在开放注册用了快两个月呢? 哈,因为做一个玩具容易,做一个产品难。程序员做一个玩具自己用,自己很清楚哪里能碰哪里不能碰;做给大家用的产品就不一样了,要考虑很多很多东西。 Quaily 能干啥 按照最初的设计意图,如果你是个作者,可以把它当一个 newsletter,也可以当一个 blog,或者用它来写书,都可以。 如果你个读者,那么你可以忽略 Quaily 本身,而把注意力放在内容上,比如可以在发现页浏览一下,找一找有没有想订阅的作者。 Quaily 的功能 最早 Quaily 是为我一个人做的。 然后我的朋友开始使用它了,Quaily 也为我的朋友们提供一个创作的地方。 即使后来有了其他新作者来用它,它的设计初衷依然没有变化,始终会尝试给创作者更好的创作体验。 接下来主要从创作者的视角来介绍一下 Quaily 的功能,以及为什么要这样设计。 Markdown 原生支持 很多人喜欢可见即可得的编辑器,也有很多人喜欢用其他标记型语言来写作,但我依然觉得 Markdown 是目前最好的选择。 虽然,Markdown 自己有很多问题,比如标准不统一、扩展力不强、有一点点学习门槛。但是它依然是被接受最广的写作标记语言。 这个世界就是这样,很多时候最优雅的东西不一定是最受欢迎的。比如 Unix vs Lisp Machine,Linux vs BSD,C vs Lisp,Javascript vs others ... 就像一个人如果没有缺点,大家可能会非常尊敬他,但不会在请客吃饭、露营钓鱼、喝下午茶的时候邀请他。真实的人虽然有缺陷,但如果呆在他身边能舒舒服服的,那才能成为好朋友。 Markdown 就是一个虽然有缺陷,但是只要你用它写作了,就会感到舒舒服服的工具。所以 Quaily 能支持它真是太好了。 从本地编辑器直接发文 大部分内容发布系统都通过一个网页、或者一个客户端来发布新内容。Quaily 当然也有自己的 Web 编辑器,作者可以在登录到「仪表盘」来编辑和发表文章。 在此之外,作者也可以通过本地的 Markdown 编辑器来发文。由于我日常使用 Obsidian,因此 Obsidian 是首先得到支持的编辑器。 日常,我几乎所有的内容都通过 Obsidian 来撰写,本文也不例外。本地编辑器提供了作者最熟悉的创作环境。而且专业的编辑器无论在使用体验、习惯、还是功能,都完胜网站上的在线编辑器。 因此,对于我来说,在 Obsidian 里直接完成「撰写 → 发布 → 投递到订阅者」一条龙服务,是最好的,Quaily 提供的 Obsidian 插件就做到了,并且还顺便支持用 AI 生成文章摘要、关键字等等信息。 当然了,我用 Obsidian,其他人不一定用。所以在计划中,我也会添加其他编辑器的支持(例如 VSCode)。另外,能达成这些也是因为 Quaily 提供了一套 API,任何开发者都可以在自己喜欢的编辑器(比如 Emacs,VIM)里添加对 Quaily 的支持。 SEO 和网站性能 Quaily 从设计之初就考虑到了 SEO 所关心的所有因素,去实现他们,然后以开箱即用的方式提供给创作者。 这些内容包括典型的 SEO 技术实现,比如:站点地图、Atom Feed、元信息等等。也包括典型的 SEO 策略实现,比如:如何给文章计算评分然后投递给搜索引擎等等。Quaily 的作者不需要关心这些繁琐细节,Quaily 会自动地完成这些工作。 另一项工作是关于 Quaily 的基础性能,比如加载速度、响应速度等等,属于直接影响用户体验的部分。这是长期工作,很多事务非常琐碎,做起来很麻烦。有的性能改进虽然细微,但是非常贵。我会权衡投入产出,尽可能地提供最好的性能。 尽可能提供最好的代码支持 代码是在这个世界表达的很重要的一部分。就是说,对于文章里包含代码的,需要非常好地支持才行。比如代码高亮,就像下面这段: int main() { printf("Hello\n"); return 0; } 除此之外,我还计划集成一些有用的第三方服务,比如 play.golang.org,比如 codepen。这样代码能显示出来,也能跑起来。 数学公式和绘图 这是另两个需要重点支持的功能。 科学写作经常需要插入数学公式,就像下面这样: $$ 工程写作经常需要插入绘图,就像下面这样: sequenceDiagram Alice ->> Smith: Hello Smith, how are you? Smith-->>John: How about you John? Smith--x Alice: I am good thanks! Smith-x John: I am good thanks! Note right of John: Smith thinks a long<br/>long time, so long<br/>that the text does<br/>not fit on a row. Smith-->Alice: Checking with John... Alice->John: Yes... John, how are you? 对于科学和工程写作来说,必须包含公式和绘图,内容才是完整的。因此 Quaily 也需要原生支持它们。 在 Quaily 中,输入公式使用的是 Mathjax 语法;绘图使用的是 Mermaid.js。它们都是成熟可靠的实现,可以放心使用。 目前,Quaily 依赖第三方库,给予公式和绘图基础的支持,Email 里还用不了。未来会继续改进。 会员订阅和支付 即使信息是免费的,但知识不是。所以,创作者当然可以给他的作品定价。付费也是一种读者们支持创作的方式。在好的经济利益的驱动下,创作可以更好持续进行。 Quaily 拥抱经济自由,因此一开始就通过 MixPay 支持 Cryptocurrency 支付。如果一旦接受这种设定,你会发现这种一种极端便利的方式,便利程度堪比现金。 当然,Quaily 也有计划要支持法定货币,例如 Paypal,信用卡等等。但是考虑到法币系统的复杂性,这个功能会在后续再添加。 对于所有会员收入,Quaily 会拿走支付金额的 10% 用于维持运营。这也是 Quaily 的商业模式,非常简单。 自定义域名和其他个性化 最个性化的做法是自己搭建一个网站,然后 self-hosting 一个 Quaily。但并不是所有人都有这个能力,或者精力去做这件事情。 所以 Quaily 的 SaaS 版本,也就是现在你看到的 https://quaily.com ,未来会提供绑定自定义域名的功能。这样,作者可以在自己的域名下发布内容,而不是在 Quaily 的域名下发布内容。对有自我品牌意识的作者来说,这是非常重要的。 AI 虽然这一代 LLM 的能力就是产生内容,但目前我不觉得一个好的作者会把创造的主体直接交给 AI。总之我会谨慎地考虑 AI 的使用场景。 评论和社交 确实有计划延展 Quaily 在社交上的功能,因为我觉得交流对于写作和阅读来说都挺有价值的。但具体要怎么做我还在想。 阅读体验 上面说的大部分都是关于写作的,但读者才是所有内容的最终消费者。因此阅读体验也需要仔细雕凿。现在 Quaily 的阅读体验还有一些问题,会在后面的版本中逐步改进。 去中心化 有这样的计划,不过届时要看两个因素: 有多少人会愿意去 self-hosting Quaily 实例 有多少人愿意加入 Quaily 的去中心化网络 我觉得这可能涉及到内容经济模型和社交,因此这个计划会放在社交之后。 开发者支持 最后是开发者相关的内容。在用 Obsidian 写文章的作者可能已经发现了,Quaily 从一开始就提供了 API Key。第三方开发者可以通过这个 API Key 来访问 Quaily 的内容。我也希望有开发者可以用这些 API 为更多的编辑器编写插件来提供 Quaily 的支持。 未来计划 首先,Quaily 是一个长期项目,会一直迭代。 但是就目前的情况,Quaily 还处于一个非常初级的阶段,请大家多多关照了,也欢迎加入 Quaily 在 Discord 上的社群。

2023/7/7
articleCard.readMore

我们团队的 AI 实践:探索过去几个月的时髦科技

从一个「练习」的机会到技术积淀 不管是怎么开始的,总之大家肯定会兴致勃勃地开始构建各种 AI 原型系统,这样做也有很多好处: 带来快速的内部成功,大家可以迅速庆祝公司的创新文化,所有人都会由衷为自己鼓掌。 这是个既有趣又令人兴奋的「练习」—— 相比起乏味的日常工作,这是个很好的分散注意力的机会。 这给了团队成员接触新技术的机会。 当这些兴奋感逐渐消退后,大部分项目一定会停滞不前。如何让这些项目不成为负债而是资产呢,我的答案是让他们成为真的技术积淀。 首先,大部分原型一定会废弃。但是这就跟 NASA 的 X 系列测试机一样,它们虽然注定会被拉到飞机拆解场,也不赚钱,但留下的技术积淀必须能对后续项目有帮助。 对 Pando 这种小团队来说,源码、系统、技术分享都是很好的积淀方式。但是最理想的当然是产品化。 原型系统产品化 在之前《人类替代计划:一份使用 AI 代替公司同事的指南》 中,我说 AI 对老板的威胁之一是「没有搞清楚这一代人工智能能干什么不能干什么」 如果团队领导者连 AI 的上下界在哪都不清楚,那他做的决策自然也不可靠。 就我目前浅薄的认识来看,这代 LLM 确实能改变很多很多场景。但他们中的大部分,都体现在两方面:降低成本;提升效率与体验。 既然这两点是明确的,那么沿着这两点去做产品化,不但有了确定的目标,还有了可以观察的指标。 例如我上文提到的 i18n-cli 项目,在它出现之前,我们之前的文本翻译都用众包平台来完成,存在有两个问题: 额外的成本。就我们这点儿翻译量,每个月几百美元是常态。 质量都欠佳。由于众包平台本来就提供机器辅助翻译,所以大部分翻译者其实是依靠机器翻译的,实际进行人工调校的不多。 既然如此,那就让 AI 来做这个事情好了。使用 i18n-cli 翻译文案,翻译 500 字不到一美分。在基本没有降低翻译质量的前提下,节约了翻译的费用,还缩短了交付流程。 再比如 PAL9000,作为一个客服系统,给它灌输好知识库以后,90%的用户咨询不再需要人工解释,省下客服的费用,还提高用户体验。 因此这两个项目脱离了原型系统以后被一直沿用至今。 准备融合 AI 到当下的业务 刚才提到的客服也好翻译也好,都没有真正的让 AI 进入到业务里,只是在周边打转转,干点省钱提速的活儿。 在经过一段时间的观察以后,我很确信 AI 应该融入到业务里:虽然我还不是很确定具体要做什么,但是我知道有一些工作是无论如何都必须做的。 因此我决定应该把这些「必须做」的工作单独拿出来。这就是 Botastic 诞生的原因。而 Botastic 的目标也就明确了: 实现「必须做」的工作 完全把业务建立在 OpenAI 上让人非常不安,需要能够随时切换到开源的 LLM 上。 用团队熟悉的技术栈来实现。 能够迅速基于这个框架搭建出新 AI 应用 现在我们基于 AI 的所有服务都基于 Botastic,那一堆数字人就是在其上很容易就搭建出来了。并且如果需要——例如来自所在国家的禁令——可以随时切换到开源的 LLM 上。 小心使用 AI 替换现有的方案 一个比较有意思的进展是我们在尝试使用 LLM 来实现一些功能,而这些功能在以前需要完全不同的技术储备来实现,比如内容推荐、语义搜索、行为预测等等。 使用 LLM 替换的原因是,如果用 LLM 来实现,会超级简单。不过,并非所有常见功能都能很容易地实现替换。 一个典型的例子是语义搜索。最初的时候,我觉得向量数据库 + ChatGPT 会是一个很好的方案。但是测试下来发现,如果简单地把用户输入拿去做 AI 的语义搜索会有很大问题,这个问题我在《# 面向 AI 的编程:是时候该坐下来应对不确定性了》 提到了:用户在大多数情况下无法给出完整信息。 这时候不但需要补全信息,还需要更换和优化用户关键字才行。 除了技术上的问题,还有交互体验上的。例如:语义搜索结果中不包含用户输入的关键字,这会让一些常见的搜索交互优化失效,无法高亮显示用户关键词。 因此,如果要用 AI 替换现有方案,得小心一点。不但有意料之外的工程量,效果也可能和预期有偏差,还可能需要不同的团队角色共同协助来解决。 给交互设计带来的挑战 LLM 和 Whisper 这样的项目的出现,让基于对话(文本对话或语音对话)的交互方式变得比之前容易很多。这对设计来说有了很多新的可能性: 天生对视障人士友好 完全自然语言的对话式 UI,可以不用视觉 UI 对话式 UI 可以优化非主流设备(头戴显示器、穿戴设备)的交互体验 很多产品都很容易忽略「视障人士」。其实老年人都是视障人士,中年人都是准视障人士。观察一下程序员都能发现,程序员年龄越大,编辑器的字号也越大。 产品体验对中老年的关怀,不仅仅是一句「晚年吉祥」那么简单。相传中共中央之前邀请老兵代表开表彰会,时任总理周恩来会在老兵代表们的座位上挨个试一遍,并且告诉工作人员调低灯光亮度,因为老年人眼睛惧光。 因此,如果某个功能有可用性问题,不妨考虑一下对话式 UI,说不定就能解决。 和其它技术类似,区块链也好,AI 也好,也都遵循 Gartner Hype Cycle:技术触发器 → 充满期望的高峰 → 失望的低谷 → 觉醒的斜坡 → 生产力高原。 我们虽然不一定能准确预判当下 AI 技术处于哪一个阶段,或者确定这个阶段有多长,但是作为小团队,相较大公司应该有更多灵活性:在新技术出现以后应该去快速尝试,能迅速了解它的边界,尝试给团队成员更多成长的机会,然后考虑如何利用它。 但是同时,也要明确知道能做到什么程度,什么时候应该收手,不要陷入追新的泥潭。 就这一轮 AI 技术来说,虽然我对 AI 的潜力依然保持很乐观的态度,但我们已经做到了目前能做的最远边界,接下来是否要继续推进就取决于自己业务对 AI 的需求了。 Purchase on the website to read the full article.

2023/6/28
articleCard.readMore