实际案例：

**实例背景：**某汽车互联网公司，领导对负责新车业务的产品经理X君、负责二手车业务的产品经理Y君提出需求：对新车APP和二手车APP销售线索数据指标进行数据监控，如有超过5%的数据变动，则需要向上级汇报波动数值以及波动原因。
名词注释：

• 销售线索：通过事件记录到用户有明确的购买意向，记录行为的事件例如：电话咨询、短信询价、加入心愿单、收藏、特别关注等类型事件。记录一个用户即代表一个线索。
• 数据波动：即(（当日数据-昨天数据）/昨日数据)*100%=环比数据波动

根据领导需求，假设定义短信砍价按钮与电话咨询按钮为销售线索指标，销售线索按钮页面的入口来源页面包含：页面A与页面B。
X君与Y君分别设计了埋点方案，如图所示：

单向依赖与单一职责原则(SRP)

单向依赖是最简单的依赖。

上述都是单向依赖的例子。其中，(1)是最理想的情况。当逻辑变复杂后，单个模块往往承担了过多的责任。即使模块之间可以保持简单的单向关系，模块内部各行为之间却形成高强度的耦合整体。根据单一职责原则(SRP)，这样的模块也是难以维护的，我们需要对模块做拆分。
在有多个模块的情况下，(2)的依赖关系显然要好于(3)，因为在(2)中模块的依赖关系要比(3)少。这样的解释过于抽象，我们用游戏中比较典型的一个应用场景来说明一下。

场景对象管理器GameObjectManager，管理着场景对象GameObjectInstance，而场景对象的构造需要资源AssetStore的支持。他们的调用关系，用(2)和(3)的模式分别实现一遍：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

//(2) GameObjectManager从AssetStore取资源数据，然后调用GameObjectInstnce的初始化流程
class GameObjectManager{
public:
    AssetForGameObject* GetAsset(DWORD dwID){m_Asset.GetAsset(dwID);}
    GameObjectInstance* Create(DWORD dwAssetID){
        AssetForGameObject* pAsset = GetAsset(dwAssetID);
        return m_GameObjects[dwNewID] = new GameObjectInstance(pAsset);
    }
    void TickGameObject(){foreach(auto go = m_GameObjects) go.Tick();}
private:
    AssetStore m_Asset;
    map<DWORD, GameObjectInstance*> m_GameObjects;
};

//(3) GameObjectInstance自己调用AssetStore的方法取资源数据，做初始化
class GameObjectManager{
public:
    GameObjectInstance* Create(AssetStore* pAssets, DWORD dwAssetID){
        GameObjectInstance* pGo = new GameObjectInstance();
        pGo->Init(pAssets, dwAssetID);
        return m_GameObjects[dwNewID] = pGo;
    }
private:
    AssetStore m_Asset;
    map<DWORD, GameObjectInstance*> m_GameObjects;
};

class GameObjectInstance{
public:
    void Init(AssetStore* pAssets, DWORD dwAssetID){
        m_Data = pAssets->GetAsset(dwAssetID);
    }
};

GameObjectInstance只需要依赖于AssetForGameObject，但是在依赖关系(3)中，却要依赖于一个范围更大的概念AssetStore。

在实际工作中，复杂度上来后，各模块之间错综复杂，调用关系网千头万绪。即使有各种设计模式做指导，做出合理的设计也并不容易。程序员天天疲于应对层出不穷的变化，在不断紧逼的deadline压力下，面对巨大的重构工作量往往感到心有余而力不足。
系统复杂度的根源除了业务本身的复杂度，就是设计了不恰当的耦合关系。本文试图探讨依赖关系的主要类型，并总结应对依赖的编程范式。

耦合：依赖和变化

耦合是一个有歧义的词语（为什么“耦合”概念该要摒弃）。当我们说“A和B耦合”的时候，我们是想表达A和B之间有紧密的联系。具体是什么，不容易讲清楚。
在我看来，耦合至少包含了两个方面的含义：依赖和变化。
业务逻辑固有的复杂度决定了，模块之间必然存在着依赖。规范模块间的依赖关系，就是梳理业务复杂度的过程。最终的成果反映在代码中，代表了对业务复杂度的一种认识。这种认识随着业务需求的变化而演化，随着设计者的能力提升而深化。依赖不能被消除，但是可以被优化。探讨一些应对的范式有助于规避已知的陷阱。
变化则来源于两个方面：发展中的用户需求，完善中的系统模型。用户的需求是我们努力的方向。系统模型则代表了我们对需求的理解，是经验和智慧的结晶。一个完善的系统模型，表达能力要足够强，对业务的适应能力要足够强。变化，意味着工作量，意味着成本，应该尽量降低。如果我们把“系统变更”和“业务需求变更”写成函数：
SystemChange = f(ReqirementChange)
我们希望自变量不变的情况下，“系统变更”这个函数值越小越好。特别是“业务需求变更”在当前系统设计假设条件下产生调整的时候，“系统变更”应该局限在很小的范围内。

依赖的种类

在UML类图中，依赖关系被标记为<>。A依赖B意味着，A模块可以调用B模块暴露的API，但B模块绝不允许调用A模块的API（IBM Knowledge Center）。
在类图中，依赖关系是指更改一个类（供应者）可能会导致更改另一个类（客户）。供应者是独立的，这是因为更改使用者并不会影响供应者。
例如，Cart 类依赖于 Product 类，因为 Product 类被用作 Cart 类中的“添加”操作的参数。在类图中，依赖关系是从 Cart 类指向 Product 类。换句话说，Cart 类是使用者元素，而 Product 类是供应者元素。更改 Product 类可能会导致更改 Cart 类。
在类图中，C/C++ 应用程序中的依赖关系将两个类连接起来，以指示这两个类之间存在连接，并且该连接比关联关系更加具有临时性。依赖关系是指使用者类执行下列其中一项操作：

• 临时使用具有全局作用域的供应者类，
• 将供应者类临时用作它的某个操作的参数，
• 将供应者类临时用作它的某个操作的局部变量，
• 将消息发送至供应者类。

模块之间产生依赖的主要方式是数据引用和函数调用。检验模块依赖程度是否合理，则主要看“变更”的容易程度。软件模块之间的调用方式可以分为三种：同步调用、回调和异步调用（异步消息的传递－回调机制）。同步调用是一种单向依赖关系。回调是一种双向依赖关系。异步调用往往伴随着消息注册操作，所以本质上也是一种双向依赖。

有一种观点将“依赖”直接总结为人脑中的依赖（为什么“耦合”概念该要摒弃）。文中提到：

只要程序员编写模块A时，需要知道模块B的存在，需要知道模块B提供哪些功能，A对B依赖就存在。甚至就算通过所谓的依赖注入、命名查找之类的“解耦”手段，让模块A不需要import B或者include “B.h”，人脑中的依赖仍旧一点都没有变化。唯一的作用是会骗过后文会提到的代码打分工具，让工具误以为两个模块间没有依赖。

代码的复杂度更主要的体现在阅读和理解，如果只是纠结于编译器所看到的依赖，实在是分错了主次，误入了歧途。

埋点概述

数据埋点是数据产品经理、数据运营以及数据分析师，基于业务需求（例如：CPC点击付费广告中统计每一个广告位的点击次数），产品需求（例如：推荐系统中推荐商品的曝光次数以及点击的人数）对用户行为的每一个事件对应的位置进行开发埋点，并通过SDK上报埋点的数据结果，记录数据汇总后进行分析，推动产品优化或指导运营。
埋点分析，是网站分析的一种常用的数据采集方法。数据埋点分为初级、中级、高级三种方式。数据埋点主流部署的方式有：

• 私有化部署（即部署在自己公司的服务器上，如果期望提高数据安全性，或者定制化的埋点方案较多，则适合私有部署，并开发一套针对自己公司定制化的数据后台查询系统保证数据的安全性和精确性，缺点是成本较高）。
• 接入第三方服务，比如国内的某盟和国外的GA（Google Analytics）统计，在以后的文章中会单独介绍，此处不再展开。（优点是成本较低，部分基础服务免费，缺点是：数据会存在不安全的风险，另外一个就是只能进行通用的简单分析，无法定制化埋点方案）
  此处只展开初级：在产品、服务转化关键点植入统计代码，据其独立ID确保数据采集不重复（如收藏按钮点击率）；

主要的埋点事件分类：

点击事件：

点击事件，用户点击按钮即算点击事件，不管点击后有无结果；

曝光事件：

成功打开一次页面记一次，刷新页面一次记一次，加载下一页新页，加载一次记一次。home键切换到后台再进入页面，曝光事件不记；

页面停留时间事件：

表示一个用户在X页面的停留时长记为停留时长。例如：小明9:00访问了X网站首页，此时分析工具则开始为小明这个访问者记录1个Session（会话）。接着9:01小明又浏览了另外一个页面列表页，然后离开了网站（离开网站可以是通过关闭浏览器，或在地址栏键入一个不同的网址，或是点击了你网站上链接到其他网站的链接……）为了简单，我们把这个过程当做一个Session。
则最终小明在首页的页面停留时间：
（Time on Page，简称Tp）Tp(首页) = 9:01 – 9:00 = 1 分钟

推荐一个从零开始学正则表达式的网站，一步步，交互式，支持中文，方便学。非常不错的网站：regexlearn.com

背景

37signals 是一间芝加哥互联网应用公司，著名产品如 Basecamp，并以开发 Rails 框架著称。下面是他们公司公布的决策原则。

决策原则

以下是我们在37signals做决定时努力牢记的一些一般原则。它们不是要求，这也不是我们在面临选择时的全面清单，但它们可以作为我们在做每天都需要做的一件事时的框架、考虑和共同做法：决定。

1. 为什么我们要做这个决定，为什么要现在做这个决定? Why are we deciding anything at all? Does a decision actually need to be made here?
2. 是否是正确的人来做这个决定？谁是拥有正确信息、背景和洞察里的正确人选（不是角色）？谁只是在插嘴？ Is the right person making this decision? Not the right role, but the right person with the right information, context, and insight? Who’s merely chiming in?
3. 如果忽略眼前利益，我们一年以后还会对这个决定有什么感觉？ If we remove the immediate impact, how do we think we’ll feel about this decision a year from now?
4. 为什么还没有做出决定？为什么我们之前没有决定？ Why hasn’t this decision been made already? Why didn’t we decide before?
5. 为什么我们要花这么长时间做这个决定，我们在犹豫什么？这说明什么？ What’s taking so long to make this decision? Why are we hesitating? What does that reveal?

@RickYU写了个小项目 BriefGPT，抓取 Arxiv AI 领域论文，通过 GPT 生成中文标题和论文概要，高亮顶会论文，方便快速筛选。
网站：https://briefgpt.xyz

推荐一个我正在用的 Prompts 网站，https://prompthero.com/ ，适用于 ChatGPT、Midjourney、Stable Diffusion，最近用 Midjourney 比较多，找见想要风格的图片，直接复制 Prompts 就可以，效果还是不错的。

引言：

《通用人工智能的火花：GPT-4早期实验》是3月最重要的一篇论文，引起了广泛的关注和讨论，但是论文长达 154页，中文版本还无人翻译。

本文挑选了论文中的重点结论并进行翻译，虽然已经是精选，但仍然超过万字。但考虑到 GPT5 明年才能面世，这篇文章在今年什么时候看都不晚。

微软的研究院在很早期就接触到了 GPT-4 的非多模态版本，并对齐进行了详尽的测试。这篇论文就是整个的测试过程和结论。不管是测试方法还是结论都非常精彩，强烈推荐看一遍，传送门在此 。https://arxiv.org/pdf/2303.12712v1.pdf

本文的翻译没有添加任何夸张的修辞（DeepL和ChatGPT贡献也很大），但文中透露的信息本身已足够震撼。

本文目的是和大家分享当前AI最新的进展，欢迎分享转发，如需转载，只需要注明作者信息 orange.ai 和原始链接 https://orangeblog.notion.site/GPT-4-8fc50010291d47efb92cbbd668c8c893

什么是概念地图？

约瑟夫·D·诺瓦克（Joseph D.Novak）于20世纪70年代，在康奈尔大学（Cornell University）发展出概念图绘制技巧。当时，Novak将这种技巧应用在科学教学上，做为一种增进理解的教学技术。Novak的设计是基于大卫·奥苏伯尔（David Ausubel）的同化理论（assimilation theory）。奥苏伯尔根据建构式学习（constructivism learning）的观点，强调先前知识（prior knowledge）是学习新知识的基础框架（framework），并有不可取代的重要性。在Novak的著作《习得学习》（Learning to Learn）中，指出“有意义的学习，涉及将新概念与命题的同化于既有的认知架构中。”
Novak教授认为，概念图是某个主题的概念及其关系的图形化表示，概念图是用来组织和表征知识的工具。它通常将某一主题的有关概念置于圆圈或方框之中，然后用连线将相关的概念和命题连接，连线上标明两个概念之间的意义关系。概念图又可称为概念构图（concept mapping）或概念地图（concept maps）。前者注重概念图制作的具体过程，后者注重概念图制作的最后结果。现在一般把概念构图和概念地图统称为概念图而不加于严格的区别。
在概念图中，由方形表示概念，如“狗”和“动物”等等。概念间的关系则以标名(labelled)的箭头线段连结，箭头的方向表示往下发展的层次。这些线段会像是：“引发”、“导致”、“需要”、“提供”等等。

概念图的组织结构

“概念图”是一种知识以及知识之间的关系的网络图形化表征，也是思维可视化的表征。一幅概念图一般由“节点”、“链接”和“有关文字标注”组成。

1、节点： 由几何图形、图案、文字等表示某个概念，每个节点表示一个概念，一般同一层级的概念用同种的符号（图形）标识。概念是可以用于交流的指代明确的符号（词汇、语言等形式）。
2、链接： 表示不同节点间的有意义的关系，常用各种形式的线链接不同节点，这其中表达了构图者对概念的理解程度。
3、文字标注： 可以是表示不同节点上的概念的关系，也可以是对节点上的概念详细阐述，还可以是对整幅图的有关说明。

举例：

概念地图的优势

• 层次结构明显
• 长程连接更容易看到
• 维基融合，主动性导航型知识库

举例：