geelaw

发布文章有内部性和外部性，外部性很好理解，别人可以来看、来读、来学习，作者可以获得评价，无论正面或是负面。如果你认为一个话题 ChatGPT 写出来的内容已经可以实现够好的外部性，那么最简单的发布方式是留下 ChatGPT 聊天记录的链接，而不是复制一份，后者纯粹是浪费资源。然而，如此作出的内容，我认为发布人的参与较少，如果是我，我会不好意思署名。

内部性在这里是指创作文章的过程对作者自己的作用。校园学习里面为什么有人要记笔记？为什么上课学过的内容，下课要做习题？为什么数学证明在思考完成后需要写下来确保正确？为什么科研人员必备的技能之一包括写作？为什么费曼学习法要求用自己的话重新把知识表达出来？很多时候，单纯阅读会让人进入全盘接受的状态，毕竟这是一种很“舒服”的做法。然而很多东西听起来正确，实际上似是而非，这种错误需要勤加思考才能发现，从“舒服”的状态进入思考，是有点“痛苦”的。

从人类思维到媒介（书面或口头）的转化过程要求作者不断厘清思维的每个细节，思维良好的人或许思考一个数学问题可以诈和，但是写到纸面上时就很容易发现错误（思考比书写更容易跳步，跳步是各种错误的源泉）。我自己写论文的时候，通常也会对认为已经想好的问题有新的理解。

给 ChatGPT 一个话题，然后阅读它的回答，最后把它拼拼凑凑弄成一篇文章，很容易陷入全盘接受似是而非的东西的状态，除非反复提醒批判性阅读、思维足够清醒。我自觉无法抵抗这种“舒服”的诱惑，加之 LLM 的胡编乱造能力很强（有人戏称 GPT 是“狗屁通”），所以我拒绝问 LLM 事实性问题——我只能接受 LLM 提供参考资料，然后再从人类写出来的参考资料中学习——当然，人类写的东西也会有错误，所以依然需要遵循 媒介—思维—媒介 过滤的方法。

假设 dev_1.1 是

B -> C1 -> C2 -> C3 -> C4 -> C5 = dev_1.1

并且假设 C2 、C4 要被撤销，那么

git checkout -b new dev_1.1
git revert --no-commit C4

解决冲突，并 git add 好

git revert --no-commit C2

解决冲突，并 git add 好

git commit --edit

编辑消息，说明要暂缓某功能，并且实际操作是撤销了 C4 、C2 ，并记录冲突是如何解决的。

git checkout -b dev_1.1_bak dev_1.1
git merge -s ours --edit new

编辑消息，说明这是为了恢复暂缓功能的代码，同时实现“当前 commit 是撤销后 commit 的后代”和“blame 可以得到正确历史记录”。

git push
git checkout dev_1.1
git merge --ff-only new
git push
git branch -d new

到此为止：

- dev_1.1 是暂缓功能代码删去的状态
- dev_1.1_bak 是没有删去的状态，且是 dev_1.1 的后代
- 如果 dev_1.1 继续开发，可以在 dev_1.1_bak 上 merge dev_1.1 ，并且 merge 的时候不会删去暂缓功能的代码

告知我们文件内容对 merge 的行为分析是次要的——merge 首先考量的是历史关系，在历史关系的基础上才考虑内容变化。我们需要知道每个 ref 的 commit hash 以及这些 commit 之间的图关系才能告诉你为什么看起来 merge 什么事情都没发生。

运用 psychic debugging 的技巧，最简单的解释是本地的 master 是 origin2/master 基础上新做了几次 commit 的结果，而在 descendant 上 git merge ancestor 的效果是没有任何效果。

这个叫做 single/double-storey ，小写拉丁字母 a g 的两种变体，推荐阅读 https://www.thetype.com/2013/05/6161/

@liemehoc #2 首先的猜想是

1. 校验数据应该和数据整体有关系

然后观察数据

2. 高位是 00 时值为低位（表达简单的候选：加法、异或、或）
3. 高位是 0? 时最高位匹配（不能是加法，因为不进位）
4. FFFF 的结果是 FF （不能是异或）

想出候选之后验算一下。

DoorDash 的自助流程可以直接退款。另外有些客服部门有子部门，即使机器客服需要转人工，它也有更大希望直接转到正确的部门。

首先，楼主发现的三件事情是同一件事情……

假设 data 、checksum1 、checksum2 永远是 4 位十六进制数，那么观察可以发现

[1] (data ^ checksum2).low = (data ^ checksum2).high = (data.high | data.low)
[2] checksum1.low = (data ^ checksum2).low
[3] (data ^ checksum1).low = (data ^ checksum1).high

于是计算方法是

checksum2
= data ^ (data ^ checksum2)
= data ^ ((data.high | data.low) * 0x0101)

checksum1
= data ^ (data ^ checksum1)
= data ^ ((data.low ^ checksum1.low) * 0x0101)
= data ^ (checksum2.low * 0x0101)

其中 high/low 表示高、低二位。