在实际工作中，复杂度上来后，各模块之间错综复杂，调用关系网千头万绪。即使有各种设计模式做指导，做出合理的设计也并不容易。程序员天天疲于应对层出不穷的变化，在不断紧逼的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、文字标注： 可以是表示不同节点上的概念的关系，也可以是对节点上的概念详细阐述，还可以是对整幅图的有关说明。

举例：

概念地图的优势

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

举例：

网站特点

发现一个帮助更好思考问题的工具「untools」，收集了各种思维工具和框架，可以帮助我们更好地理解问题、分析、决策，包括有常用的金字塔、鱼骨图、二阶思维等，类似于选择不同的思维模型来解决不同的问题。

网站结构

系统思考

• 概念地图（Concept map）: 形象地理解一个概念或系统，了解其实体之间的关系。
• 连接圈（Connection circles）:是一种将故事或系统中的关系可视化的工具。它们通过看到系统中的因果关系来帮助你理解复杂性。
• 冰山模型(Iceberg Model):通过查看隐藏的抽象级别来发现事件的根本原因。
• 平衡反馈回路(Balancing feedback loop):是一种机制，它抵制在一个方向的进一步变化。它以反方向的变化来对抗一个方向的变化。它试图稳定一个系统。
• 强化反馈回路(Reinforcing feedback loop):了解指数（复利）变化背后的力量。

在做中台设计的过程中，发现中台体系庞大，链路错综复杂，问题也很多。不过这些页面之间都存有一些共性，通过对页面特征的分析，总结出了三种典型的业务场景类型：信息列表类、规则配置类、场景联动类。

3. 场景联动类

在中台业务域中，有许多与C端紧密相关的场景，但我们似乎并未抓住这种适合互动的机会，前中后台之间缺乏沟通与联动。整个系统就像一座冰山，前台只是冰山一角，冰面之下隐藏着庞大的中台系统，这就形成了前后之间虽然关系紧密但彼此看不见的情况。