悟已往之不谏，知来者之可追

这是 AI炼金术的一期单口，我想聊聊 AI 原生组织转型。之所以聊这个，是因为最近来找我的朋友，话题已经从"用什么模型、要不要培训、大家怎么用"，变成了另一种。他们说，我们公司已经在用 AI 了，很多人用得还不错，但整个组织的效率好像并没有提升。更诡异的是，还有一些公司发现效率确实提升了，却没有多赚钱，有的甚至裁了员，省了一部分人力成本，最后利润也没涨。 这就是我想讲的那个鬼故事：学也学了，用也用了，每个人都觉得自己提效了，整体效率却没动；或者整体效率动了，钱却没多赚。今天就聊聊这个鬼故事是怎么发生的，以及有没有办法解决。 效率有三层，大部分人只盯着最不重要的那层 我的基本判断是，效率本身不是一件特别重要的事情，至少单点任务上的效率不重要。这里面有三个层次。 第一层是单点效率，一个具体的员工干一个具体的活、干得快不快。这件事对个人、对任何一个打工人或个体户都很重要，但对公司其实没那么重要。公司要做的是把很多个体的努力协调起来，把劲往一处使，产生整体效果。单兵能力和组织作战能力，很多时候是两回事。 第二层是组织协调层。哪怕你练出了协调能力，不再是一群武林高手各自为战，而成了一支井井有条的军队，能不能赚钱还取决于你打下来的是什么样的城市，有些仗打赢了也是亏的。 第三层是市场和战略层，你站的位置对不对，做出来的东西是不是市场要的、是不是稀缺的。如果你做了一堆市场不要的东西，或者做了有人要但竞争激烈的东西，那你只是卷得更狠而已。 从单点效率，到组织协调层的效率，再到能把产出在市场上变成钱，这中间有两个大台阶要上。但我们大部分时候只关注第一件事，就像打仗时只盯着士兵的单兵技能好不好。士兵的单兵技能其实没那么重要，关键在于组织怎么把士兵协调起来，以及打下来的城市有没有意义。 单点提效为什么带不来整体结果 光做第一层没什么用，这里有几个原因。 第一个是阿姆达尔定律。一件事要干成有好多个环节，你只优化其中一个，对整体的效果有限。我经常坐上海到北京的飞机，大概两个小时。假设飞机提速百分之三十，从一百三十分钟降到一百分钟，这是一个伟大的科技进步。但整体想一想，我得从家里出发、打车、提前去机场、留提前量、等安检，门到门可能要五个小时。你在飞行环节省掉半小时，对两个小时来说显得很了不起，对五个小时来说，不过是从五小时变成四个半小时，在我脑子里变化不大。 我自己做过非常多很漂亮的 demo，有些合作方都发了 PR 稿，大家一起庆祝，说我们好棒，汇报的 PPT 做得花团锦簇。过一段时间再问这东西后来有用吗，答案往往是其实也没什么用。在一个长流程里优化一个环节，经常就是这样。 更悲惨的情况是，你优化一个环节，连整体上一点进步都看不到。因为一个系统的表现，取决于中间那个最低效的瓶颈环节，而不取决于某个非瓶颈环节的提升。拿餐厅后厨打比方，有洗菜工、切菜工、厨子、端菜工。假如洗菜切菜的手速突然提高十倍，但厨子没增加，或者厨子增加了灶台没增加，只有四个灶台四口锅，那灶台就是瓶颈，你把菜洗得再快也只是堆在那里，整体可能只提升了百分之一。更夸张的是，就算灶台也加了、后厨整体快了十倍，但门口的人流量没增加，你照样赚不到钱。 第三个原因更根本。一个组织真正的损耗，很多时候不在于干活。我们听播客的大多是做知识工作的白领，知识工作里最大的时间、精力和资源消耗，大部分花在开会、对齐、协调对接交接、反反复复的往来上，而不是做事本身。我看过不同口径的报告，大致都是说，百分之六十的白领工作时间花在这种协调性、对齐性的工作上：听懂老板在说什么，把老板的话讲给下属听，跟兄弟部门对齐，以及等待某件事发生。有个流程那边卡两天，你做得再快，那边还是卡两天。工资越高的白领，这种对齐、协调、人和信息的交互就越多。 所以就算你把那百分之四十的干活时间优化到极致，顶了也就四成，大头没动。这才是组织真正的瓶颈。而且这里有两个麻烦，一是大量时间成本耗在这，二是只要这里断了，你单点再对也没用。那个经典的例子是 NASA 的火星气候轨道器，两家公司合作，一家用英制单位一家用公制，没对接上，探测器飞了九个半月、几亿英里，到了火星直接坠入大气层烧掉，一亿多美金打了水漂。各自做的都对，各自说不定还加班提效了，拼到一起就是个零。 以前我们干活慢，这个协调瓶颈被盖住了。现在干活快了，你很容易就发现，交接和对接才是组织真正的大头。 组织是上一个时代的发明 张一鸣说他把公司当作一个产品来打造。如果把组织当成产品，那什么是好组织？应该是协调得特别快、能更有效地调度资源、能自己进化的那种。重点在于能不能把单点配到一加一加一大于三，有综合性的效果，而单个单点做得多好反倒是次要的。单点很强而协调跟不上，其实没用。 我听过最恶毒的一个类比，是说很多公司搞 AI、买一堆系统上一堆 copilot，其实就是满清买铁甲舰。船坚炮利，军舰都是好军舰，但整个组织的协调机制没跟上，你买得来好军舰，做不出好海军，这是两件完全不同的事。大部分人还停留在北洋水师的水平。 要往下想，就得回到一个原点：组织到底是用来干嘛的。我们常把组织当成天经地义的东西，像天上有蓝天白云一样。考虑 AI 组织转型时也默认，我们就是有这么一个组织，把它转一转就能更好地用 AI，人还是这些人，还是好兄弟。但现代公司制度其实是一种发明，老板、科层制、部门、汇报线，都是很近代才有的东西，用来解决具体问题。它本来要解决的，一个是信息路由，让大家知道消息；一个是管控机制，让大家协调到一起干活。 顺着这条线看，组织本身是为达成特定目的而造出来的工具，我们未必一定要保留这个形态。为什么有层级？因为一个人管不过来，让你直接管一百个干不同活的人你看不过来。但如果 AI 让你看得过来呢？滴滴一个人能管上千个司机，因为全局谁送到哪、车上录音都看得到，这个前提假设就变了。为什么有部门？因为人脑有限，不可能既懂这个又懂那个，所以要把一堆专才塞到一起、搞一个统一的界面对外交互。但如果未来每个人都是通才，身边都有一个小秘书帮他做翻译，研发和产品、设计之间不再需要靠会议和接口来沟通，还需要部门这个设计吗？为什么要有流程、要有人来做管控、要有开会、要有 KPI？ 这么一个个问去，你会发现这些组织的零件大多是为解决某个特定问题、或者基于某种稀缺假设而设计的。当那个"搞不定"或者"资源一定稀缺"的假设不再成立，世界不一定还会这样运转。 AI 来了，有点像恐龙时代一颗小行星撞地球，整个生存环境已经变了。过去留下来的那些东西，我们可以当成化石。它有没有道理？当然有，但那是上一个时代的道理，适应的是上一个时代的生存结构和生产力。今天全都需要重新审视。我想到一个段子，有些地方坐月子讲究不能洗头，这在古代挺有道理，没有热水器、没有电吹风，热水容易凉、头发吹不干容易感冒。但现在有热水器、电吹风、青霉素，这就不是什么大问题了。我们很多时候要考虑的，与其说是这个东西经不经典，不如说是环境约束变量有没有变。变了，就该重新设计那些习以为常的组织结构和打法。 一句暴论：用 AI 替代组织，而不是让组织用 AI 前段时间我在一个会上突然想到一句暴论。做 AI 原生组织转型，与其把原来的组织转一转去更好地用 AI，不如想一想怎么用 AI 去替代原来组织的绝大部分功能。AI 不是组织的工具，AI 是组织的替代品。从这个角度，你可能会打开一些新的思路和空间。 这里面有三层思考。第一层，在原有组织里把 AI 装起来、用好。第二层，改我的组织去用好 AI。第三层才是我今天真正想讲的：组织原有的目的、原有的功能，能不能用 AI 更有效地完成。问题从"我的组织怎么用好 AI"，变成了"我如何用 AI 让组织原来的那些功能发挥得更好、让商业目的更有效地达成"。 落到打法上，我现在看到最先发生的是三件事：对齐、推进、闭环。对齐，是让所有人站在同一条线上做事，不要每个人看到的图都不一样、自己打自己。推进，是让 AI 来推动一件事从想法到商业结果、从生产资料到最终产出，把整条线推下去。闭环，是让 AI 帮我们沉淀组织能力，这次做成的下次能做得更好。今天嗓子有限，我主要讲对齐，再讲一点推进。...

一次关于「把会议录音这件事收回到本地」的尝试：录制、转写、摘要、脑图、问答、笔记，一个窗口装下。 为什么要自己写一个 开会这件事的痛点很稳定：说了什么记不住，记了笔记又来不及听。 市面上的会议助手不少，但它们大多长一个样——注册、登录、把会议音频传到某个云端、等一个订阅制的转写额度。对于内容敏感的会议，「把录音上传到别人服务器」本身就是个需要犹豫三秒的动作；而对于只是想把每周例会的结论留个底的人来说，为这个装一个订阅制 SaaS 也未免太重。 所以我想要的东西很朴素： 录音和资料库在本地。 录下来的东西是我的文件，存在我选的目录里，索引也是本地一个 JSON。 转写和 AI 能力按需接。 用哪家的语音识别、用哪家的大模型，我自己填 Key，不绑定任何平台账号。 不配也能用。 没有 Key 的时候，它至少是个能录音、能播放、能记笔记的录音机，而不是一个打不开的空白页。 于是有了 有听有记 Voxi——一个 macOS 上的会议助手。整个项目 4800 行 Go（含测试），直接依赖只有两个：purego 和 mygo。 它长什么样 一个窗口，左边录音库，右边详情。 页签 做什么 转写 带时间戳的分段文字。点时间戳跳转播放、点文字就地改（自动保存）、点说话人改名（可只改这条，也可改全部同名） 摘要 「概览 + 关键要点 + 待办事项」，生成指令可自己改 脑图 把转写整理成可展开折叠的大纲树 问答 基于这条录音多轮提问，回答逐字流式返回 笔记 每条录音一段自由文本，随改随存 录制本身支持麦克风和系统输出（扬声器/耳机正在放的声音）两个源，可以只勾一个，也可以都勾——都勾就是一份「我的声音 + 对面/视频里的声音」的混合音轨。输出是 48 kHz 立体声、128 kbps 的 AAC（.m4a）。 三个真正的技术坑 界面是 mygo 画的，业务逻辑没什么新鲜的。有意思的是底下这三件事——每一件都是被 macOS 或者服务商的接口设计逼出来的。 一、纯 Go 捕获系统音频，一行 cgo 都没有 macOS 上要拿到「系统正在播放的声音」，正路是 ScreenCaptureKit。它是 Objective-C 的 API，常规做法是写一段 ObjC 桥接、开 cgo。...

“简洁是一种伟大的美德，但要达到它需要辛勤的付出，而要真正欣赏它则有赖于良好的教育。更糟糕的是，复杂性往往更能卖得出去。”——艾兹赫尔·戴克斯特拉 我认为，有那么一种微妙的机制，正在悄然拖工程团队的后腿。在面试中、在晋升材料里、在设计评审中：那些过度设计的工程师总能讲出引人入胜的故事，而那些只交付最简单却能正常运行的方案的工程师，却往往一无所获。 当然，这绝非有意而为之。没有人会坐下来大声说：“咱们得确保那些把事情过度工程化的人升职！”但当公司对工作评价出现偏差时，这种情况就有可能发生——而且一次又一次地重演。 想象一下，同一团队中有两位工程师。工程师A被分配到一项功能开发任务。她仔细审视这个问题，权衡了几种方案，最终选择了最简单的那一个——一个直截了当的实现，大概只有50行代码。代码易于阅读、易于测试，也方便下一位接手的同事快速上手。这个功能运行得非常顺畅。她在短短几天内就完成了交付，然后继续推进下一个项目。 工程师B也获得了一项类似的功能。他同样审视了这个问题，却从中看到了打造一款更加“稳健”产品的契机。他引入了一层新的抽象层，为各组件之间的通信构建了一个发布/订阅系统，并添加了一个配置框架，使该功能在未来应对更多用例时具备“可扩展性”。整个过程耗时三周，期间提交了多条Pull Request。当他分享那篇详尽阐述这一切的文档时，大家纷纷发来大量兴奋的表情符号。 如今，晋升季又到了。工程师B的工作几乎可以自动写进晋升材料里：*“设计并实现了可扩展的事件驱动架构，引入了被多个团队采用的可复用抽象层，并构建了一个配置框架，为未来的扩展性奠定了基础。”*这简直是在明明白白地宣告：Staff+！ 但说到工程师A的工作，几乎没什么可说的。“实现了功能X。”三个字。她的工作做得更好，却因为太过简单而鲜为人知。你根本写不出一段引人入胜的故事来讲述那些你没有打造的东西。没人会因为避开了复杂性而获得晋升。 复杂性看似高明，倒不是因为它本身有多厉害，而是因为我们的体系天生就倾向于奖励复杂性。而这种激励机制的问题，并非始于晋升之时，甚至在你还没拿到这份工作之前就已经埋下了伏笔。 想想面试吧。你正在参加系统设计环节，提出了一套简单的解决方案：一个单一的数据库、一套直白的 API，也许再加一层缓存。面试官一听，立刻追问：“那 scalability 怎么办？要是用户达到一千万怎么办？”于是你开始添置服务、引入队列、进行分片，在白板上画上越来越多的方框。终于，面试官看起来满意多了。 你刚刚学到的一点是：复杂性往往能给人留下深刻印象。那个看似简单的答案本身并没有错，只是不够引人入胜。而这一课，或许会伴随你一路走向职业生涯。说实话，面试官有时确实有充分的理由追问规模问题——他们想观察你在压力下如何思考，以及你是否真正理解分布式系统。可如果对候选人而言，最终得出的结论只是“简单还不够”，那事情就有点不对劲了。 这在设计评审中也屡见不鲜。一位工程师提出了一种简洁明了的方案，却立刻被泼来一盆冷水：“我们是不是该为未来做好准备？”于是，他们只好回过头来，添上眼下根本用不上的层层抽象，为那些可能永远不会出现的问题构建复杂的抽象层，又为那些连用户都没提过的需求预留出无谓的灵活性。这么做并非因为问题本身需要如此，而是因为“领导”或“团队”期望如此。 我曾见过（自己也曾是）一些工程师为了避免重复几行代码而刻意构建抽象，结果却造出了一套比原本的重复代码还要难懂、更难维护的东西。每次做出这样的选择时，总觉得这是再正确不过的决定——代码看起来更“专业”，更像经过精心设计的工程产物。可用户不仅没因此更快地用上新功能，而且下一位接手修改的工程师，还得花上大半天时间去搞清楚这套抽象的来龙去脉，才能动得了一根手指。 现在，让我说明一点：有时候，复杂性反而是正确的选择。如果你要处理数以百万计的交易，或许就需要采用分布式系统；如果你有10个团队在开发同一款产品，那么很可能需要划定服务边界。当问题本身很复杂时，解决方案（大概）也该同样复杂！ 问题不在于复杂性本身，而在于无端生出的复杂性。*“我们已经触及数据库上限，需要进行分片”与“我们可能在三年后才会触及数据库上限，所以现在就先分片吧。”*这两者之间是有区别的。 有些工程师深谙此道。当你仔细审视他们的代码（以及架构）时，你会不禁感叹：“嗯，这当然啦。”其中既没有玄妙的魔法，也没有什么令人自惭形秽的巧思，更没有任何让你觉得自己当初没看懂而倍感愚蠢的地方。而这，正是关键所在。 通往资深之路的真正关键，并不是掌握更多工具和模式，而是懂得在何时不必使用它们。任何人都能添砖加瓦、堆砌复杂，但要懂得如何化繁为简，则需要丰富的经验和十足的自信。 那么，我们究竟该如何应对这个问题呢？毕竟，说“保持简单”容易，但改变激励机制却要难得多。 如果你是一名工程师,请明白：简洁性必须被清晰地展现出来。工作本身并不会自我说明——并非因为它不够好，而是因为大多数系统在设计时并未考虑到倾听它的声音。 先从你如何描述自己的工作说起。“实现了功能X”听起来没什么分量。但如果你说：“评估了包括事件驱动架构和自定义抽象层在内的三种方案，最终认定采用一种简洁直接的实现方式就能满足当前及未来的所有需求，并在短短两天内顺利上线，在长达六个月的时间里零故障运行”——同样是这项简单的工作，只是用更精准、更能凸显背后决策过程的方式来加以阐述。不去构建某样东西本身也是一种决策，而且是至关重要的决策！务必如实地将其记录下来。 在设计评审中，当有人问“我们是不是应该为未来做好准备？”时，别只是轻易妥协、一味地增加层层叠叠的复杂结构。不妨这样回应：*“如果我们将来真有需要，要追加这项功能的话，大概需要做这些工作；而我们现在就把它加进去，成本大概是这样。我觉得还是再等等吧。”*你并不是在硬抗，而是在表明自己已经做了充分的功课——你权衡了其中的复杂性，最终选择暂不接手。 是的，不妨和你的主管沟通这件事。你可以这样说：“我想确保自己记录工作的方式，能够真实反映我所做的决策，而不仅仅是我在写哪些代码。我们能不能聊聊，在下一次绩效评估中，该如何更好地呈现这一点？” 大多数主管都会很欣赏这种做法，因为你在帮他们省心——你为他们提供了可以用来为你发声的语言和框架。 现在，如果你把这一切都做到了，可你的团队依然只提拔那些打造最复杂系统的人……这也同样是一条很有价值的信息。它能让你看清自己所处的工作环境。有些文化真正崇尚简约；而另一些文化口头上说崇尚简约，实则却奖励截然相反的做法。如果你身处后者，要么就顺势而为，要么就另谋高就，去寻找一个真正赏识明智判断的地方。但至少，你心里会明白自己究竟身在何处。 如果你是一名工程领导者,这一点比任何人都更关乎你。无论你是否意识到，你都在制定激励机制。而问题在于，大多数晋升标准本质上都是为了奖励复杂性，即便它们本意并非如此。“影响力”往往以某人所打造之物的规模与覆盖范围来衡量——而这些指标往往至关重要！但同样重要的是，他们本该避免的问题也理应被纳入考量。 所以，不妨先从改变你提出的问题入手。在设计评审中，与其问“我们有没有考虑过规模问题？”，不如试试这样问：“我们能交付的最简单版本是什么？又有哪些具体的信号能告诉我们，我们需要更复杂的方案？” 仅仅这一句话，就能彻底改写游戏规则：它让简洁成为默认选项，把举证责任放在复杂性身上，而不是反过来！ 在晋升讨论中，当有人提交的方案基本上只是一长串听起来很唬人的系统列表时，不妨适时提出质疑：「这些东西真的都非用不可吗？我们这里到底是不是真的需要一个发布/订阅系统，还是说它只是在纸面上看起来很炫酷？」而当团队里的某位工程师交出了一套简洁明了的成果时，不妨帮他们把背后的故事讲得更精彩。「经过多方比选，最终选择了最简捷、却能完美解决问题的方案」——这样的表述本身固然算得上一份有力的晋升申请材料，但前提是你得真正把它当作一份值得认真对待的“故事”来打磨。 还有一件事：要留意你在公开场合庆祝什么。如果你的团队频道里每次点赞、表扬都只针对那些庞大而复杂的项目，大家自然就会把精力都放在这些项目上。不妨开始多关注那位删掉代码的工程师——正是他当时说“我们暂时用不着这个”，结果却一语中的。 归根结底，如果我们一味奖励复杂、忽视简单，那么最终得到的正是我们所期待的结果，也就不该感到意外。不过，解决问题的办法其实并不复杂——我想，这大概就是关键所在。 来源：Nobody Gets Promoted for Simplicity – Terrible Software

Karpathy 的 AI 辅助编程心法，总结下来有七个关键步骤 第一步：上下文拉满 (Stuff everything relevant into context) 这是基础。你需要把项目所有相关的信息都喂给 AI。对于大型项目，这可能需要花些时间。如果是小项目，可以直接打包所有相关文件。Karpathy 甚至给出了一个 files-to-prompt 工具的示例命令： files-to-prompt . -e ts -e tsx -e css -e md --cxml --ignore node_modules -o prompt.xml 这个命令大致意思是，将当前目录下所有的 .ts, .tsx, .css, .md 文件内容（忽略 node_modules 文件夹）打包成一个 XML 格式的 prompt 文件，供 AI 读取。核心思想是：给 AI 足够的全貌信息。 第二步：策略先行，而非代码 (Describe the next single, concrete incremental change) 明确你想要实现的下一个具体、增量的改动是什么。关键点来了：不要直接让 AI 写代码。相反，你应该要求 AI 提出几种实现该目标的高级方法，并分析各自的优缺点（pros/cons）。Karpathy 指出，LLM 的判断力并非总是最佳，通常实现一个功能有好几种方式，先看选项再决定。如果需要，可以再让 AI 把选定的方法具体化 第三步：选定方案，获取初稿 (Pick one approach, ask for first draft code)...

不要对一个程序员说：你的代码有bug。 他的第一反应是： 你的环境有问题吧； 傻逼你会用吗。 如果你委婉的说：你这个程序和预期的有点不一致，你看是不是我的使用方法有问题。 他本能会想：操，是不是出bug了！ 🤔 思考： 只图一时爽快，是短视的行为。对自己的成长和做人没有任何好处 自嘲自贬是最简单的高情商

背景 一直以来对微信公众号文章的链接比较疑惑有时候很短，有时候很长，有时候保存的文章链接还会失效。 最近在看github 上的etrobot/chatgptSummary 里面有对链接的解析。自己试了下发现有些问题。所以借此机会搞清楚微信文章链接的一些概念 三种链接形式 短链接 https://mp.weixin.qq.com/s/LmWJGCLyddA9sAM7arYpag 由微信客户端生成，长度较短，链接的值或许为某种变种的base64，其长度恒定为22个字符。其中不带有可用与追踪用户身份的参数。只能通过微信客户端的「复制链接」或「在浏览器打开」功能获取这种链接。 完整链接 https://mp.weixin.qq.com/s?__biz=MzIyODI1MzYyNA==&mid=2653546018&idx=1&sn=69ff3b17631b8a88b7e96b7a971c5850 这是最常见的公众号文章链接格式，通常在浏览器中打开文章时可以看到(指手机客户端，在mac 客户端用浏览器打开是短链接)。 公众号文章会设置一个全局的JavaScript变量msg_link，它的值就是完整链接格式的文章URL。这个变量可直接在文章的HTML代码中找到。（使用时需要对其进行HTML entity decode，将&替换为&） 几个参数的含义： __biz可以认为是微信公众平台对外公布的公众帐号的唯一id mid是图文消息id idx是发布的第几条消息(1就代表是头条位置消息) sn是一个随机加密串(对于一篇图文消息是唯一的) 临时链接 https://mp.weixin.qq.com/s?src=11&timestamp=1712886908&ver=5195&signature=0M-muFRrcH94BrNld9FV6XZyD4uU503p-4G31bXv2Kum2toGDV9VMfHjuJhOc8gJwQ96kwenaMX1QKfs51js8rHRkbBJlM2gBCOke59WFxT9WodpTV8KDo4OPshf8YW1&new=1 使用搜狗的微信搜索得到的链接。有效期应为6小时，到期后只能通过微信客户端才能查看。 src，显然指”source”。目前发现的值有3和11两种，含义未知。 timestamp，生成这个链接时的UNIX Timestamp，在服务器返回查询结果时便已确定，即按下搜索键或翻页的时刻。 ver，显然指”version”。可能是生成下面signature使用的算法版本，每个数字会使用一段时间，可能不超过一天。 signature，某种签名。长度恒定为128个字符，其中带有星号。 参考 微信公众号文章URL的种类与结构 | 咸湖的盐鱼 秘塔AI搜索(微信公众号链接中 __biz，mid，idx，sn 四个参数的意义) 解读微信公众平台图文消息的链接组成 - 菲比寻常 - 博客园

我常用的 ai大模型网站和工具 更新说明 2024.04.06，第一版 AI 搜索引擎 Perplexity：全世界最出名的，支持中文，综合体验良好，就是在国内有时候会抽风，短链接：pplx.ai 秘塔AI搜索：国内类似工具，体验也不错，还有小程序 Devv AI：面向程序员的 AI 搜索引擎，可以搜索技术类问题 其他 ThinkAny - AI 搜索引擎：@ArronYoung的作品 Lepton Search：贾扬清的开源作品 AI对话大模型 chatgpt、文心一言等就不列举了 Kimi.ai - 帮你看更大的世界：最近很火的长文本 ai 大模型，我用来总结文章和资料挺好用 Poe：集合了多家大模型的网站，有免费额度 DeepSeek：国内量化基金幻方量化的作品，用的少但是体验流畅，支持通用对话和代码助手。 AI bot 开发平台 用来开发和展示类似于 GPTs的自定义 AI bot 的平台 扣子 - AI 智能体开发平台：字节产品，国内版本，开发流程和使用体验很好。但自己的云雀大模型拉胯 Coze: Next-Gen AI Chatbot Developing Platform：字节国外版本，免费使用 gpt4，就问你爽不爽 灵境矩阵 | 想象即现实：百度的基于文心大模型的智能体平台，支持 prompt 编排 百度智能云千帆AppBuilder：百度的 ai 原生应用开发平台，支持多个模型，支持多个框架和组件，相比灵境矩阵更底层一些。 AI 工具大全｜导航 AIbase - 智能匹配最适合您的AI产品和网站：有排行榜 AI帮个忙 | 多功能AI小帮手：即刻出品的 AI工具集 | 700+ AI工具集合官网，国内外AI工具集导航大全：这个比较常用 爱AI：配置好的AI bot比较多，比如OKR 专家，小说助手等，还支持画画...

常用的影视资源信息，包括网盘搜索、在线/app观看、下载等 当前更新于：2024.04.05 更新说明 2024.04.05，第一版 2024.04.06，新增奇乐搜 简单说下 看视频我一直习惯「先存后看」：之前是BT下载到本地，现在是转存到阿里网盘(虽然最后很可能变成只存不看😂)。 网盘搜索 各种资源都可以搜索，不只影视 网盘导航 - 奔跑中的奶酪：奶大的网盘搜索导航贴，很不错 阿里云盘资源搜索引擎 - 阿里搜：顾名思义，只搜索阿里云盘 小云搜索 - 阿里云盘夸克网盘搜索神器 蓝奏云搜索：这个不错，搜了几个都能找到 皮卡搜索：支持阿里、百度、夸克、蓝奏云等多个网盘 咔帕搜索 - 资源超丰富的综合云盘资源搜索网站！：同上支持多个。但默认的「智能搜索」太拉胯，需要改成「精准搜索」 盘友圈：支持阿里、百度和夸克，用的少，但好像还挺好用。 奇妙搜索：曾经最常用的，奇妙应用作者的项目。目前已经关了，但我直觉还会回来。 奇乐搜 - 阿里云盘、夸克网盘综合搜索网站：提供热门资源榜单 在线视频网站 影视森林：视频网站导航 BTNULL 无名小站：片库网，提供视频在线观看、磁力下载网盘下载和 vip 解析 获取网址：发送主题包含”最新网址“的邮件给get@btnull.org，会自动回复包含最新网址信息的邮件。 视频解析-全民解析-vip视频解析-在线视频解析：vip 视频解析 91毒舌电影：收录了国内外、爱奇艺、优酷、腾讯、Netflix等等VIP平台热门的欧美日韩剧等影视资源，提供了网页和 app，网站干净无广告，而且有各种专题。 南柯电影网-追最新电视剧-看热门电影：差不多 人人影视 - 人人影视PRO - 聚合全网高清影视在线观看 学霸网盘影视 - 阿里云盘,百度网盘,夸克网盘下载 奈飞工厂-一个致力于免费提供Netflix影剧动漫的流媒体播放平台：专门的网飞视频网站 只下载 电影天堂_电影下载_高清首发 体育直播 178直播-欧洲杯直播_足球即时比分直播_足球比赛直播_NBA篮球比分直播_欧洲杯直播_欧洲杯视频直播_足球直播_足球比分直播 JRS低调看球-JRS直播NBA无插件|低调看直播|足球直播吧|世界杯直播吧 看球通体育_NBA直播吧_足球直播_篮球直播_英超直播_欧洲杯直播_体育直播_纬来体育 app 这类 app 其实很多，但是经常会用不了，我目前的措施是使用「app 壳」+「视频源」的方案，可在手机和电视上直接观看。 参考网站： TVBox Android TV 版 - 家用安卓电视盒子 - 小众软件 o0HalfLife0o/TVBoxOSC(官方) TG 频道：TVBox开发版 盒子地窖：各种 app 和视频源

宝宝生病，前后折腾了半个多月，列张表格复盘一下，总结经验教训。

发现美，欣赏美，理解美。 刘亦菲参加迪士尼《星愿》首映礼，值得发一篇文。