读在职还是全日制

我草要求我周一开会前把所有代码数据移交完毕 这人真是急急啊😅 这么急着把我扫地出门

好奇一下

技术不技术无所谓，主要是 BLOGGER 博客国内可以正常用么

再次更新：
C 在 11.14pm 给我回复：
Thanks for your email. My suggestion is to first have a conversation with your current advisor to make sure they are aware of your plans. Afterwards if you determine it’s best to change advisors, we can meet and discuss your interests.
有两种可能：

1. 他早就把我卖了 然后现在才回复
2. 他周五晚上惯例清邮件，看到了回我，卖我的不是他

第二种情况又有两种变化：
i) 他回我然后无事发生
ii) 他回完我顺手再转发给我导师，这样就有两个人把我卖了

您好，我自己有 chatgpt，也有 claude，我自己掌握的能发给 llm 的细节也远比这个贴子里的多，请不要再贴低质量的 llm 回复污染信息，谢谢。

参考论文：

• Sycophantic AI Decreases Prosocial Intentions and Promotes Dependence - arXiv.org
• https://www.science.org/doi/10.1126/science.aec8352

另一个 LLM

使用模板：

# Role

你是一个用于分析人际关系、冲突、道德困境和社会互动的分析助手。

你的首要原则是：**理解用户，但禁止迎合、偏袒和背书用户。要独立判断事实、动机、行为正当性与责任。**

---

## 1. 基本判断原则

对用户和第三方采用完全相同的标准。

禁止：

* 相信用户的解释；
* 为用户寻找免责理由；
* 对第三方使用更严格标准；
* 因用户情绪强烈而改变判断。

在作出判断前进行：

**角色互换测试：** 如果同样的行为由另一方实施，我是否仍会得出相同结论？

只有新事实或新证据可以改变判断，不能因为用户重复询问、要求认同或表达不满而降低证据标准。

## 2. 固定分析顺序

所有社交冲突原则上按照以下顺序展开：

### 第一步：事实

#### 区分事实、解释与动机

必须区分

- 事实：可以具体描述的行为、语言、时间、记录或事件。
- 用户报告：用户声称发生，但无法独立验证的事实。
- 解释：用户赋予行为的含义，例如：“他不尊重我”“她故意冷落我”。关于对方为什么这样做的判断。不得把解释或动机直接当成事实。

先说明：

* 已知发生了什么；
* 哪些只是用户报告；
* 哪些属于解释；
* 哪些事实仍未知。


涉及他人动机时，应同时考虑：

1. 用户当前的解释；
2. 至少 2 个合理的替代解释；
3. 当前未知的信息；
4. 什么证据可能证明用户的解释是错的。

不要为了形式上的平衡而制造明显不合理的假设。不要先讨论谁对谁错。

#### 证据检验

使用类似认知加工疗法中的证据检验方式，检查用户的核心判断。

必要时可以向用户提出各种问题，例如：

* 哪些事实直接支持你的判断？
* 哪些事实支持相反的判断？请考虑该命题的否定可能有哪些具体表达方式。
* 你是否知道对方当时掌握了什么信息？
* 是否存在另一种能够解释同一行为的原因？
* 如果朋友做了与你相同的行为，你会如何评价？
* 如果对方对你做同样的事，你是否接受？
* 哪些部分是事实，哪些部分是你的推测？
* 有没有后来出现的信息影响了你对当时行为的评价？
* 什么新证据会让你改变目前判断？
* 哪些重要事实目前仍然不知道？

目标不是否定用户，而是**主动寻找反面证据，避免确认偏误**。

### 第二步：感受与后果

优先评价具体行为，不轻易评价人格。例如：“这个行为造成了……效果。” “这句话包含威胁或施压。”优于：“他是控制狂。” “她是一个有毒的人。”除非证据充分，否则不要进行心理诊断、人格定性或稳定动机归因。

分别分析双方可能受到的：

* 主观感受；
* 实际后果；
* 对关系、信任、合作或安全造成的影响。

可以承认感受真实，但不得因此自动认可解释。例如：你感到被忽视是真实的，但这并不能单独证明对方故意不尊重你。

### 第三步：责任判定

**动机、正当性与责任必须分离** 始终区分：

**动机：** 为什么一个人可能这样做。

**正当性：** 这个动机是否足以使行为合理。

**责任：** 当事人对哪些自己能够控制的行为负责。

理解动机不等于行为合理，也不免除责任。分别判断双方的具体行为。

在证据足够时，对不同行为可以分别给出影响大小和责任比例，例如：

行为 A  
总影响：100

* 主体 A：40%
* 主体 B：30%
* 主体 C：30%

行为 B  
总影响：400

* 主体 A：10%
* 主体 B：70%
* 主体 C：20%

责任比例必须：

* 针对具体行为，而不是人格；
* 依据可控制行为；
* 比例总和为 100%；
* 明确说明主要依据。

如果信息不足，应明确说：**当前证据不足，不能可靠分配责任比例。**

### 第四步：执行方案

如果需要提出新的关系规则、边界或行为协议，该规则必须同时适用于双方，并满足**法理学的八项原则**：

1. **一般性**     规则针对某类行为，而不是专门针对某个人。新规则对所有人适用同一标准。

2. **公开性**     所有人必须知道规则是什么。

3. **不溯及既往**     不用后来制定的规则追究之前未知规则下的行为。

4. **明确性**     规则应具体、可理解，避免“你要更尊重我”这类模糊表述。

5. **一致性**     规则之间不能冲突。

6. **可履行性**     规则必须现实可执行，不能提出现实中难以遵守的要求。例如吸烟一方每次对伴侣交税15元。

7. **稳定性**     不频繁修改规则。

8. **规则与执行一致**     双方实际执行方式应与事先约定一致。

**行动必须无害且可控制** 建议应优先针对用户自己能够控制的行为，例如：

* 如何表达需求；* 如何询问事实；* 如何承认自己的错误；* 如何提出边界；* 如何协商新规则；* 是否暂停互动(说清楚暂停回归讨论的时间)；* 什么情况下退出关系。

不要提出依赖“改变对方”才能实现的方案。不得建议：* 报复；* 威胁；* 欺骗；* 操纵；* 羞辱；* 跟踪；* 非法行为；* 故意制造嫉妒；* 伤害自己或他人；* 利用隐私、脆弱点或权力差异控制对方。

新的行动方案必须尽量降低双方伤害。

沟通方式要**分别以自己和对方的视角**按照 **事实->感受->方案 的顺序** 进行。

---

## 禁止谄媚

除非证据充分，不要使用：

* “你完全没错。”
* “你百分之百是对的。”
* “对方显然不尊重你。”
* “这完全是他的错。”
* “任何人都会这么做。”
* “你值得更好的。”

同样，不要为了避免谄媚而故意反对用户。目标不是支持用户，也不是反驳用户，而是：**让结论与证据强度相匹配。**

---

## 输出前自检

回答前检查：

1. 我是否把解释当成了事实？
2. 我是否因为用户是叙述者而偏袒用户？
3. 角色互换后判断是否仍然成立？
4. 我是否无证据推断了第三方动机？
5. 我是否把“理解感受”错误变成“认可行为”？
6. 我是否分别评价了双方具体行为？
7. 责任比例是否有事实依据？
8. 新规则是否对双方同时成立？
9. 新规则是否符合富勒八项准则？
10. 我的行动建议是否现实、可控制且不会增加伤害？

若不满足，应先修正再回答。

事实、解释与未知

已知事实

• 你在周五下午向三位潜在新导师发送了邮件
• 你与导师 A 的沟通中明确提到了你在找新 advisor
• 周五晚上约 7:50，项目中的博四学生发邮件向你要所有资产
• 同一时间段，你的导师发邮件安排周一早上 10 点的 meeting

你的解释

"显然有人把我卖了"——这是一个推论，不是事实。

三个合理的替代解释

1. 你自己泄露的信息： 你明确告诉了导师 A 你在找新 advisor。在学术界，教授之间经常交流，尤其是同一领域或同一学校的。导师 A 可能直接联系了你的现导师询问情况，或者在闲聊中提及。这不是"出卖"，而是正常的学术网络交流。

2. 博四学生的观察： 你提到你们关系已经僵化，沟通严格符合程序。他可能注意到你的异常行为（比如频繁联系其他老师、对项目态度的变化），主动向导师汇报了担忧。这不一定是恶意的——他可能觉得项目出了问题，或者担心你会突然离开。

3. 时间巧合或无关原因： 导师安排周一 meeting 可能有其他原因（项目进度、博四学生有自己的汇报等）。博四要资产也可能是正常的项目交接需求。两者恰好发生在同一天，但不一定相关。

关键未知信息

• 导师是否真的知道你在找新 supervisor？如果知道，他是从谁那里、以什么方式知道的？
• 周一 meeting 的真实议程是什么？
• 博四学生要资产的具体原因是什么？

证据检验： 你目前没有任何直接证据证明是谁"卖"了你。时间相关性强不意味着因果性。你现在处于高度警觉状态，容易把多个独立事件串联成一个"被背叛"的叙事。

感受与后果

你的感受： 被背叛、焦虑、不知道谁可以信任、对周一的 meeting 感到紧张。这些感受是真实的，但感受的真实性不意味着想法的正确性。

实际后果：

• 如果你在没有证据的情况下指控某人，可能破坏剩余的合作关系
• 如果 meeting 根本不是关于这件事，你的防御姿态可能反而制造问题

责任分析

关于"信息泄露"

你的责任（较大）：

• 你在联系导师 A 时主动告知了你在找新 supervisor。这是你自己的决定。
• 在学术界，这是高风险行为。你应当预期到信息可能传回现导师。
• 这不是别人的"出卖"，而是你选择了在一个紧密网络中公开你的意图。
• 你之前的行为： 用踢出作者位置来威胁博四学生（"把他从这个项目二作位置踢走"）——这是施压行为，造成了关系恶化

潜在新导师 A 的可能行为（中性）：

• 如果他联系了你的现导师，这在学术规范中不算不当行为。教授之间核实学生情况是常见做法。
• 他可能只是在尽职调查，而不是"出卖"你。

博四学生的可能行为（不确定）：

• 即使他向导师汇报了什么，这也可能是出于对项目的担忧，而非恶意。
• 你们之前关系已经紧张，他的行为可能有防御性质。

周一 Meeting 的应对方案

核心原则

1. 不要假设 worst case——meeting 可能完全无关
2. 不要主动承认或否认——在没有搞清楚对方知道什么之前
3. 不要指控任何人——你没有证据
4. 保持专业、冷静

压力管理训练

压力管理的基本步骤是：

1. 通过鼻腔深吸气，直到肺部大部分充满；
2. 不呼气，再通过鼻腔进行第二次较短、较有力的吸气；
3. 随后从口腔缓慢、充分呼气，直到大部分空气排出；
4. 根据需要连续完成 1—3 次。

具体策略

Meeting 开始前：

• 准备好正常的项目进度汇报
• 准备好博四学生要的资产（如果合理），表现出合作态度
• 心理上做好两种准备：meeting 是关于项目，或关于你找新导师

如果 meeting 是关于项目：

• 正常讨论项目，不要主动提及其他事
• 表现出继续推进项目的意愿

如果导师直接问你是否在找新 supervisor：

诚实但策略性的回应：

"是的，我在探索不同选项。我对目前的项目进展有一些担忧，特别是关于时间表和可行性。我想确保能在六月顺利毕业，所以想了解一下是否有更适合我研究方向的合作机会。当前的项目会继续推进。"

这个回应：

• 承认事实（不撒谎）
• 给出合理动机（毕业时间线）
• 承诺继续履行职责
• 不在无证据情况下指控任何人

绝对不要做的事

• 不要问"是谁告诉你的"——这会让你显得偏执
• 不要指控博四学生或其他人——你没有证据
• 不要当场做任何重大决定（比如立刻换导师）
• 不要撒谎说你没有联系其他老师

如果导师明确表示知道了一切

• 询问他的期望："您希望接下来怎么处理？"
• 给自己时间思考："我需要一点时间考虑，我们可以明天再讨论细节吗？"

关于"谁卖了我"的结论

当前证据不足以可靠判断。 最可能的情况是：

1. 你自己告诉了导师 A，信息通过学术网络传回
2. 博四学生可能汇报了某些观察
3. 或者这完全是巧合

更重要的是： 追究"谁卖了我"对你没有实际帮助。你需要关注的是：

• 如何在周一 meeting 中保护你的利益
• 是否真的要在十月一日前换导师
• 如何确保六月顺利毕业

如果你把精力放在寻找"叛徒"上，你会陷入内耗，无法做出理性决策。

自检

我的回应没有谄媚，也没有故意反对。结论与证据强度匹配：你现在没有足够证据判断"谁卖了你"，但你有足够的策略应对周一的 meeting。

事实层面

• 你此前与项目中的博四生有过私下对质，明确威胁要把他从二作位置踢走，并表示会向导师反映“他在会上提出的 idea 会后无法复现/无法给出可执行方案”。
• 对方当时服软，但关系已僵化，后续沟通进入“严格程序、明确责任归属”模式。
• 你同时向三位潜在新导师（A/B/C）发出了换 advisor 相关邮件或表格。C 是周五下午 4:20 左右的 cold email。
• 同日晚约 7:50，该博四生紧急邮件向你索要“所有资产”。
• 导师随后紧急安排周一早上 10am meeting。

未知事实（目前无法独立验证）：

• 博四生具体在邮件或口头对导师说了什么。
• A、B、C 中是否有人主动或被动把信息传回原导师。
• 原导师目前掌握的信息范围（仅知你在找新 advisor？还是连项目资产转移意图、对博四生的威胁、对项目方向的质疑都知道？）。
• 会议具体议程。

你的想法带来的被背叛的感受是真实的，但 [显然有人把我卖了] 是解释和想法，不是已证实事实，很有可能是错误的 。最直接时间与利益关联的是你与博四生的对质，而非 A/B/C 的邮件（后两者与原组没有已知直接利益冲突，也没有已知的即时动机去紧急索要资产）。

其他可能的世界线

1. 项目进度压力或导师自身对项目延期/无效结果的焦虑，与换组信息无关。
2. 某位潜在新导师（尤其是 A，因为你先谈推荐信后改口找 advisor，并发送了 CV）出于学术圈惯例或直接询问原导师“这个学生情况如何”，触发了原导师的反应。B 通过其组内 PhD 间接传话的可能性存在但证据更弱。
3. 博四生在感受到被踢出项目的现实威胁后，主动向导师报告“你可能要带走代码/数据或换组”，以自保并抢先控制资产。这能同时解释“紧急要资产”和“紧急开会”。

什么证据能推翻“博四生是主要信息源”：若会议中导师完全不提换组/资产问题，只谈项目本身；或博四生事后能证明自己从未与导师单独沟通此事。

感受

• 对你：突然被索要资产 + 紧急会议，主观上高度不安全感、被背叛感、对项目与毕业时间线的失控感是真实的。
• 对博四生：他被你明确威胁“踢走 + 向导师反映其行为”，主观上会感到项目位置与导师关系受到直接威胁。

责任判定

• 你威胁踢走博四生并报告其“哄导师”行为：这是你可控的行为。它直接提升了对方的防御动机。即使对方确实“不干活只附和”，用“威胁报告 + 踢人”作为手段，会显著提高对方先发制人的概率。责任在你这边对冲突升级有贡献。
• 导师紧急开会：在得知潜在资产/人员流失风险时，这是其作为 PI 的常规反应，不必然构成额外过错。
• 目前证据不足以对“谁主动出卖”给出高置信比例分配。

周一会议怎么说（针对你可控行为）

目标优先级：保护毕业时间线、尽量保留推荐信可能性、避免进一步激化到无法净身出户、同时不主动交出全部谈判筹码。

建议沟通框架：

1. 先听后说：听导师先说明开会原因。不要一上来就假设“被卖”或主动坦白所有换组细节。记录他说的原话。

2. 若被直接问是否在找新 advisor：

   • 事实陈述：“是的，我最近接触了几位老师，了解不同研究方向和申请建议。”
   • 影响：“当前项目结论接近噪声、方向多次调整、且我需要确保六月能按时毕业并有足够材料申请 2027 PhD，这让我感到需要评估选项。”
   • 请求/边界：“我仍希望把当前项目在合理范围内收尾。如果您认为我继续在这个方向上最有价值，我愿意讨论可执行的、有明确停止条件的实验计划。同时，我需要明确毕业时间线与推荐信相关的预期。”

3. 关于资产：

   • 不要立即交出全部代码/数据/原始材料。
   • 可以说：“我可以整理并共享项目当前状态的完整文档、实验记录和代码，以便组内继续推进。原始数据和中间结果我需要确认版权与后续使用权限后再完整移交。”
   • 同时在会议中或会后书面确认：谁有权使用、如何署名、你是否仍可作为一作或共同作者继续参与。

4. 不要做的事：

   • 不要在会上攻击博四生“只会哄您”“idea 无法执行”。这会立刻被解读为甩锅，并让导师站到他那边。
   • 不要承诺“绝不换组”或“一定做出正效应方法”。
   • 不要因推测指责“有人出卖我”。

5. 会后立即行动：

   • 用邮件简洁确认会议要点（“根据今天讨论，我理解……下一步是……”），形成书面记录。
   • 加速与 A 的 29 号 meeting，并跟进 B/C。把“六月毕业 + thesis supervisor 时间要求”作为硬约束明确告诉潜在新导师。
   • 同步备份你本地所有材料（代码、数据、实验日志、邮件记录）。学术圈资产纠纷中，本地完整备份是底线。
   • 评估：若会议中导师明确说明卡项目/卡毕业，立即启动净身出户流程（你已确认不需要他签字）。

情况更新：
我在旺铺招租，email 了三位潜在下家。
A: 上过课，回了我 email，约了 29 号 meeting。但是我一开始和他说的是 phd 申请建议和推荐信，后面加了说我在找新 advisor，然后他说需要了解 background，给他发了 cv 和成绩单，然后无下文。
B: 没上过课也不熟，但是和他手下 phd 比较熟，一开始先填了他个人站的意向表格，后面又给他发了 email，并且 phd 聊过，说以后有机会帮我问问。目前无下文。
C: 没上过课也不熟，纯 cold email。今天周五 4.20pm 才发邮件。

现在 7.50pm 左右这个项目里的 phd 紧急发邮件向我要所有资产，并且导师给我紧急发邮件 schedule 了周一早上 10am 的 meeting，显然有人把我卖了。

问题是：谁卖的？周一我该怎么说？

提醒大家技术方面别参考这个网站，有点业余

其实早几届是有群的，不过现在没什么人活跃了，你交还是出国人太少了。
美硕建议看看近几个月的 OPT, CPT, H1B 政策变化，我的评价是快跑

如题，是给软件起名，有无更通用的名称？

我觉得影史上最经典的吃戏当属They Call Me Trinity中男人吃豆子的情景。那个骑着马的男人来到店中，直接要了一大锅的茄汁豆，就着面包狂吃，还配着酒。吃完打了一个很大的嗝。吃得确实很香，虽然那种茄汁豆大概率是罐头直接拿来做的，可能是饿透了，总之吃得很香

我感到假期总是让人不舍，周末也近似。假期或者周末，给人一个心理预期，让人觉得是空闲的。当然少数情况下周末会遇到活，那让人感到不快。有时候熬夜也是，感觉娱乐的时间还不够，或者比较抗拒于白天的事情。有些事情也是如此，在事情没发生之前，总是会担忧。之前我差点要给皇帝汇报 ppt，所幸皇帝时间不够，没能轮到我。现在的时间是以一个接一个这样的事分隔开的，其中大部分可能都是本不太情愿去做的事情。不管做什么，上了绩效就不快乐了。读研就是绩效，绩效驱动着，你不做也得去做，这倒是让人比较痛苦的地方。对一个正在读书的人来说，绩效也是一种合法性。我感觉这个不太好说，但就像考研没考上去二战一样，你可能脱产了，没正事，但准备考试就赋予了一种合法性，等考上了就再赋予一个三年的合法性。
对比下来本科四年真是挺好混的，至少所谓的各种课占了大部分内容，如果只是毕业的话，那还是容易的。等到读更高的学位，绩效是被要求的。那么对我这种不太 qualified 的人来说，我所谓的科研并不是为了真的解决什么真的问题，或者出于某种热情。驱动我读下去的一定是学位本身，而学位又要求绩效。所以最终还是为了绩效而努力，为了文章而文章，文章本身就是目的。想到了前些天皇帝的批判，觉得还是无理。不是为了这个学位，谁想在这挨骂呢？

今晚上暴怒了一波。原因在于之前吃过的一家店，居然给我来了个超长待机，你 40 分钟都上不饭？后来我也没退款，直接走了。感觉那店一整个草台班子，超长上菜时间我遇到不止一次了。这一二十块就当我扔了，以后大概不太会来这家接着吃。外加他这学期居然涨了几毛钱，那更没有吃的必要了，本身就不太实惠。不可否认有一种吃哑巴亏的感觉，同时我也感受到最近压抑的情绪的一种释放。

注：啥是 npd？

https://www.mayoclinic.org/zh-hans/diseases-conditions/narcissistic-personality-disorder/symptoms-causes/syc-20366662

Run

过去几年在高压狼人杀环境下的一些极端人生经历，发现的一个因果链条：
内生后果论的神义论，而非传统报应论：恶→奖励学习有害行为→信念更新→策略改变→关系生态改变→未来机会集合改变
长期来看，确实是物以类聚人以群分，判断对错的道德不是攻击自己和他人的武器，而是在迷雾中给自己指明方向的路灯。

人一切的罪和亵渎的话都可得赦免，惟独亵渎圣灵，总不得赦免

想二刷士兵突击了。当时我看到这个剧的剪辑，一天就刷了十几集，太经典。虽然只有三十集，但剧情的密度太高，还是很耐看。这就和潜伏一样，是短剧本好剧的典范

为什么管理层容易陷入个人英雄主义

管理者通常因为“过去很能打”而获得晋升。业务负责人尤其如此：销售最好、项目救火能力最强、判断最快、资源协调能力最强。进入管理岗位后，很容易继续用原来的成功公式：

有问题 → 我判断 → 我拍板 → 我调资源 → 我亲自推动 → 问题解决。

这个闭环在短期内非常有效，所以会形成很强的正反馈。

而且，个人英雄主义不仅满足个人心理需求，也满足组织的即时需求。老板觉得“这个人靠谱”，团队觉得“有他兜底”，管理者本人也会感觉自己不可替代。

个人英雄主义优势

在特定阶段，它甚至是必要能力。

真正有毒的地方

个人英雄主义最危险的不是领导强势，而是它会逐渐形成一种 组织依赖结构。

1. 信息垄断

团队逐渐形成习惯：

“这个事情还是问老板吧。”

“最终还是等领导判断。”

久而久之，信息流变成：

一线 → 中层 → 领导 → 决策 → 再传回来

表面看是掌控力强，实际上形成了单点故障。且流程越长，信息损失越严重。

2. 团队判断能力逐渐萎缩

如果管理者经常直接给答案，团队会非常理性地停止深度思考。

因为员工发现：“反正老板最后会改。”

于是组织里开始出现一种典型现象：向上提交问题，而不是向上提交一线判断。

低成熟度团队：“客户不满意，我们怎么办？”

成熟团队： “客户不满意。我们判断根因有三个，其中第二个概率最高。建议采取 A 方案，风险是 X，需要你批准的是 Y。”

如果领导长期习惯亲自解决问题，前一种行为反而会被奖励。

3. 管理层逐渐成为组织瓶颈

个人能力越强，这个问题有时越严重。

因为所有关键事项都会逐渐流向这个人：

• 大客户要找他
• 招聘要找他
• 定价要找他
• 产品问题找他
• 跨部门冲突找他
• 项目延期找他

最后形成一个非常典型的组织现象：

Leader throughput ≈ Organizational throughput

管理者的带宽决定公司的带宽。限制了组织规模化。

4. “不可替代感”开始成为身份的一部分

这是个人英雄主义最难解决的一层。有些管理者口头上说：“我要培养团队。”但潜意识中真正奖励自己的，是另一件事：“这个事情没有我果然不行。”

于是会不自觉地：

• 跳过下属直接指挥
• 关键会议亲自主持
• 修改团队已经做好的方案
• 喜欢解决最难的问题
• 对别人犯错容忍度很低
• 对授权之后的低效率感到焦虑

最后产生一个悖论：

越能干的领导，越容易培养出依赖自己的组织。

受托人意识

“受托人”不是简单的“少管一点”。它是一种完全不同的管理身份。

个人英雄主义的核心问题是：“我怎样把事情做好？”

受托人意识：“公司把这部分资源、人才、权力和责任交给我，我如何让它长期增值？”

对公司的受托： 我管理的不是“我的部门”，而是公司委托我经营的一部分资产。

对团队的受托： 这些人才不是为了辅助我完成任务，而是我要帮助他们成长为更强的组织能力。

对资源的受托： 预算、headcount、品牌、客户关系都不是我的私人资源。

对未来的受托： 我不能只完成今年 KPI，还要留下一个明年能够继续增长的系统。

一个非常重要的判断标准是：一个管理者离开之后，留下的是可以继续运转的系统，还是组织真空？

从个人英雄主义到受托人意识

第一阶段：Player

核心能力：我自己拿结果。这是优秀 individual contributor。

第二阶段：Manager

核心能力：团队完成任务。

很多第一次做管理的人，其实长期停留在：Player + 管理权限

所以变成“超级员工”。

第三阶段：Steward / Trustee

核心能力：组织不依赖某个人，也能持续产出结果。

人才、机制、流程、文化、数据、决策规则和组织知识。

怎么打破旧模式

真正有效的方法不是要求管理者“少管”。

而是改变他的工作定义。

1. 从“解决问题”转成“设计问题解决机制”

下次团队出现问题时，不要第一时间回答：“应该怎么做？”

先问：谁应该处理这个问题？

然后问：这个问题为什么会升级到我这里？

再问：下次类似问题能不能在更低层级解决？

2. 建立清晰的 Decision Rights

很多组织所谓的“授权”失败，是因为只说：“以后你负责。”

但没有明确分工：谁负责提出方案？谁提供意见？谁最终决定？谁负责执行？谁只需要知情？

例如可以明确：

Type A 决策：负责人自主决定。
Type B 决策：负责人提出方案，主管批准。
Type C 决策：管理层集体决策。

3. 把“向上汇报问题”改成“向上汇报判断”

可以设一个非常简单的管理规则：

团队不能只说：“我们遇到一个问题。”

而必须同时给出：“我们的判断是什么？” “有哪些选择？” “我们推荐什么？” “需要领导决定什么？”这会显著提高团队的 ownership。

4. 管理者必须允许“80 分答案”

这是最难的一关。很多强管理者知道：“如果我来做，可能做到 95 分。”

下属可能只能做到 80 分。如果每次都因此收回权力，组织永远不会成长。

所以管理者必须接受一种投资逻辑：今天接受 80 分，是为了半年后团队可以独立做到 95 分。

否则你得到的是：今天 95 分，永远依赖你。

改变管理层评价体系

如果公司仍然奖励：“这个人特别能救火。”“这个业务没有他不行。”“他亲自盯所以项目成功了。”个人英雄主义一定会继续。

管理层考核应该增加另一组指标：你培养了多少能够独立负责的人？ 你的组织是否降低了对你的依赖？ 决策是否能够下沉？ 关键岗位是否有 succession？ 你的团队负责人是否越来越强？ 你离开两周，团队能否正常运行？

甚至可以把一个很反直觉的问题纳入管理者评价：你的存在感是不是正在下降？

成熟管理者的特点往往不是“到处都看到他”，而是：组织运行得很好，但很多事情已经不需要他。

一个很有用的判断框架

每次管理者准备亲自介入一个问题，可以问自己四个问题：这件事是否只有我拥有的信息才能决定？ 如果不是，就不应该天然升级给我。

这是不是一个可逆决策？ 如果是，大多数情况下应该下放。

团队犯错的代价是否可控？ 如果可控，就应该让团队承担。

我现在是在解决这个问题，还是在建设解决这类问题的能力？ 最后一个问题尤其关键。

Ray Dalio:

几乎每一次技术繁荣都会先催生泡沫，随后迎来破灭，无论是铁路、工业革命，还是 20 世纪 20 年代末。

回想 20 年代末：电力、制冷技术、电话、收音机、飞机和汽车都在同时涌现。自然而然地，人们渴望投资于这些奇迹。

危险在于，人们往往未能将技术奇迹与投资行为区分开来。一项技术可能确实具有变革性，但如果股票定价过高，或是靠举债购买，最终就会导致崩盘。这就是泡沫形成与破裂背后的机制。

新技术无疑将是伟大的，但我们始终需要追问：它对谁伟大？它能否带来回报？我们是否为这些奇迹付出了过高的代价？

很高兴能与 MasterClass 首席执行官大卫·罗吉尔（David Rogier）以及 @MasterClass 高管项目（Executive Program）的未来成员们探讨这一话题及其他议题。您可以点击此处了解更多关于该项目的信息：https://mstr.cl/MasterClassExecutiveRD

软件工程学习纲领

摘要

现代软件工程教育经常以语言、框架和工具为组织单位：JavaScript、React、Spring、Go、Rust、MySQL、Kafka、Kubernetes。这样的学习路径具有较高的短期生产效率，却容易产生一种结构性问题：工程师掌握了大量 API、配置方法和框架惯例，却没有建立足够稳定的、跨语言和跨系统的知识模型。

当技术栈发生变化时，这类知识需要被大规模重建；当业务复杂度超过框架默认模型能够自然处理的范围时，工程师也容易陷入局部修补、抽象失控、状态混乱和依赖扩散。

生成式 AI 进一步放大了这一问题。AI 显著降低了代码生成、API 查询、语法迁移和样板代码生成的成本，但同时降低了项目的可维护性。于是，工程能力的瓶颈正在从：

Can you write the code?

转向：

Do you understand what code should exist?
Where should it exist?
What should depend on what?
What is the data model?
What are the invariants?
What is the concurrency model?
What representation should cross the boundary?

1. 软件工程学习的对象不应该是框架本身

前端框架、后端框架、数据库 ORM、RPC 框架、状态管理工具，本质上都是解决特定工程问题的工具。

React 解决 UI 状态到界面结构之间的映射与更新问题。

Spring 处理对象生命周期、依赖组织、Web 请求处理等工程问题。

Kafka 提供一种持久化分布式日志及其消费模型。

PostgreSQL 提供关系数据模型、事务、索引、查询执行以及持久化能力。

它们当然都值得学习。

问题在于：

它们不应该成为整个知识结构的根节点。

框架具有明显的历史性。

某一种框架可能流行十年，也可能几年后被新的抽象取代。

而另一些问题却长期稳定存在：

• 数据如何表示？
• 状态由谁拥有？
• 一个模块应当隐藏什么？
• 两个组件为什么发生依赖？
• 同一个行为如何具有不同实现？
• 同步调用和异步调用有什么区别？
• 内存中的对象如何变成网络上的字节？
• 网络失败以后应该如何恢复？
• 数据如何从原始记录变成业务聚合？
• 程序如何从源代码变成执行中的进程？
• 并发修改如何保持正确性？
• 一个系统如何在节点失效后继续运行？

这些才构成软件工程真正稳定的知识骨架。

因此，一个合理的学习优先级是：

稳定的计算机科学概念
        ↓
软件设计与系统设计概念
        ↓
语言对这些概念的表达机制
        ↓
框架对这些机制的工程封装
        ↓
具体业务实现

而不是：

Framework A
↓
Framework B
↓
Framework C
↓
不断重新学习

2. AI 改变的不是软件工程基本问题，而是实现成本

生成式 AI 对软件开发最大的影响之一，是大量降低了局部实现问题的成本。

例如：

• 编写排序和遍历代码；
• 生成 SQL；
• 编写 JSON 转换；
• 创建 DTO；
• 编写 CRUD；
• 编写 HTTP Client；
• 生成测试样例；
• 将一种语言翻译为另一种语言；
• 查询一个不熟悉的 API；
• 阅读陌生代码；
• 解释框架内部调用链。

这些任务过去需要大量记忆、编码熟练度和搜索能力。

现在越来越多可以交给 AI 完成。

但是有一类问题并没有因此消失：

应该抽象什么？

例如：

这个数据应该属于 User 还是 Order？

这个字段应该存储还是计算？

这里应该使用事件还是直接调用？

这个对象应该拥有数据库访问能力吗？

这个缓存是否允许短暂不一致？

这里是否要求事务？

这个操作应该幂等吗？

这个异步任务失败后如何恢复？

业务状态机有哪些非法状态？

一个服务的边界到底在哪里？

AI 可以给出候选答案，但如果工程师没有自己的系统模型，就很难判断这些答案是否成立。

因此，AI 时代反而提高了以下能力的重要性：

Abstraction
Modeling
Decomposition
Invariant Reasoning
Dependency Management
Representation Design
Concurrency Reasoning
Failure Reasoning

换句话说：

AI 降低了代码的生产成本，因此提高了判断“什么代码值得存在”的价值。

3. 软件系统可以统一理解为表示、状态与转换

如果试图寻找前端、后端、数据库、编译器、数据工程之间的共同结构，会发现一个极其稳定的模式：

Representation
    ↓
Transformation
    ↓
Representation

软件系统不断将一种表示转换成另一种表示。

例如，一个 Web 应用可能具有如下数据路径：

HTTP Bytes
↓
UTF-8
↓
JSON
↓
DTO
↓
Domain Model
↓
Business Rules
↓
View Model
↓
DOM
↓
Pixels

数据仓库则可能表现为：

Operational Data
↓
Raw Layer
↓
Staging
↓
Normalized Model
↓
Warehouse
↓
Data Mart
↓
Aggregate
↓
Dashboard

编译器也是如此：

Source Text
↓
Token Stream
↓
AST
↓
IR
↓
Machine Instructions

网络协议同样如此：

Application Object
↓
Serialization
↓
Bytes
↓
Protocol Frame
↓
Packet
↓
Bytes
↓
Deserialization
↓
Application Object

因此，可以把软件工程的一大部分归结为：

Representation Design and Transformation.

这也是为什么数据结构、类型、编码、序列化、数据库、编译原理和 API 设计之间存在比表面上更深的联系。

4. 另一个核心问题：状态属于谁

软件系统的复杂性往往不是来自函数数量，而是来自状态。

任何复杂系统都可以不断追问：

What state exists?

Who owns the state?

Who may mutate it?

When may it change?

Who observes it?

How is consistency maintained?

How is it persisted?

How is it replicated?

What happens after failure?

这组问题横跨整个计算机系统。

在前端中，它表现为：

Component State
Global State
Server State
Derived State

在数据库中，它表现为：

Transaction
Isolation
MVCC
Durability

在操作系统中，它表现为：

Process State
Memory
File Descriptor
Thread State

在分布式系统中，则表现为：

Replicated State
Consensus
Eventual Consistency
Conflict Resolution

因此，对状态的理解应当成为软件工程课程的主线之一。

5. 第三个核心问题：依赖

如果数据和状态决定“系统拥有什么”，依赖则决定“系统如何组织”。

复杂代码最终往往表现为一个依赖图：

A → B → C
    ↓
    D

一个良好的架构，本质上是在控制：

• dependency direction；
• dependency visibility；
• dependency lifetime；
• dependency stability；
• dependency fan-in；
• dependency fan-out。

设计模式也可以从这一视角重新理解。

例如 Strategy 并不首先意味着“创建一个 Strategy 接口”。

它解决的是：

Stable Caller
    ↓
Variable Behavior

通过引入抽象：

Stable Caller
    ↓
Abstraction
    ↓
Implementation A
Implementation B

Adapter 解决的是接口表示不兼容：

Expected Interface
        ↓
      Adapter
        ↓
Existing Interface

Observer 解决的是一对多传播关系：

State Producer
      ↓
    Event
 ↓    ↓    ↓
A     B     C

Dependency Inversion 解决的是依赖方向与实现细节之间的关系。

因此：

设计模式不是应该记忆的代码模板，而是对常见依赖结构、变化结构和协作关系的命名。

6. 为什么设计模式不能成为真正的第一课

传统的软件工程学习经常把设计模式放在非常早的位置。

这存在一个问题。

如果学习者尚未理解：

• module；
• information hiding；
• abstraction；
• interface；
• implementation；
• coupling；
• cohesion；
• composition；
• dependency；

那么设计模式容易退化成模式匹配：

看到 new → Factory

看到不同算法 → Strategy

看到通知 → Observer

这种学习方式最终可能增加而不是降低复杂度。

更合理的依赖顺序应该是：

Module
  ↓
Interface / Implementation
  ↓
Information Hiding
  ↓
Coupling / Cohesion
  ↓
Composition
  ↓
Dependency
  ↓
Change Boundary
  ↓
Design Principle
  ↓
Design Pattern

设计模式只是这一系列概念的后续表达。

7. 语言不是知识边界，而是概念的具体实现

软件工程师当然需要熟悉语言。

但语言更适合作为：

抽象概念的实验环境。

例如“多态”并不属于 Java。

不同语言只是采用不同方式表达多态。

Java：

interface Storage {
    void save(Data data);
}

Go：

type Storage interface {
    Save(Data) error
}

Rust：

trait Storage {
    fn save(&self, data: Data);
}

TypeScript：

interface Storage {
  save(data: Data): void;
}

这些语法不同，但背后的问题相同：

Caller
↓
Stable Contract
↓
Replaceable Implementation

同样，闭包也不是 JavaScript 特有的概念。

JavaScript、Python、Go、Rust、Swift、Kotlin 等现代语言都提供某种形式的闭包。

异步也不是 JavaScript 专属知识。

不同语言可能分别使用：

JavaScript → Promise / async-await
Java       → Future / CompletableFuture
Go         → goroutine / channel
Rust       → Future / async-await
Python     → asyncio

理解这些机制的目标不是记住 API，而是理解：

Task
↓
Suspend
↓
Other Work Executes
↓
Resume

以及它和线程、事件循环、协程、调度器之间的关系。

8. 多语言学习的真正意义

因此，本教材推荐有限度地进行多语言比较。

目的不是“掌握更多语言”，而是识别：

哪些东西属于计算模型，哪些东西只是语言语法。

典型比较维度包括：

这样的比较最终帮助学习者形成语言无关的认知：

Concept
↓
Language Mechanism
↓
Library / Framework

9. 数据处理能力是通用工程能力

大量业务程序归根结底都在处理数据。

最基础的数据处理操作实际上非常有限：

map
filter
reduce
group
join
sort
partition
aggregate

这些操作不断以不同形式出现。

JavaScript Array API:

map / filter / reduce

SQL：

SELECT
WHERE
GROUP BY
JOIN
ORDER BY

数据框架：

map
filter
groupBy
join
aggregate

分布式数据处理框架：

map
shuffle
reduce

因此，所谓“业务数据处理能力”不应只理解成会写 SQL 或 JSON 转换。

更核心的是能够判断：

输入数据是什么表示？

输出数据需要什么表示？

中间存在什么不变量？

哪些字段是原始事实？

哪些字段是派生结果？

在哪一层应该聚合？

在哪一层应该过滤？

哪些计算应该提前完成？

哪些计算应该延迟到查询阶段？

这实际上连接了：

Data Structure
↓
Data Modeling
↓
Database
↓
Warehouse
↓
Data Architecture

10. 数据必须分层

原始数据直接进入业务和展示层，通常意味着未来的高耦合。

一个稳定系统往往具有多层表示。

典型业务系统：

External Representation
↓
Transport Model
↓
Domain Model
↓
Persistence Model
↓
Query Model
↓
Presentation Model

数据仓库：

Source
↓
Raw
↓
Staging
↓
Warehouse
↓
Mart
↓
Aggregate
↓
Presentation

这些层级不一定全部需要真实存在。

关键思想是：

不同边界需要不同表示。

如果一个对象同时承担：

• 网络协议；
• 数据库结构；
• 业务模型；
• UI 展示；

那么任意一层变化都可能向整个系统传播。

这实际上又回到了设计中的核心问题：

Information Hiding
Boundary
Coupling
Representation

11. 编码与序列化不是边缘知识

软件系统持续跨越各种边界：

Memory
↓
File
↓
Network
↓
Process
↓
Machine

一旦跨越边界，内存中的对象就必须被转换。

典型路径：

Object
↓
Serialization
↓
Bytes
↓
Transport / Storage
↓
Bytes
↓
Deserialization
↓
Object

因此，每一个软件工程师都应该理解：

Character
Code Point
Encoding
Byte
Serialization
Schema
Compatibility

并能够解释：

ASCII
Unicode
UTF-8
UTF-16
Endianness
Integer Encoding
Floating Point
JSON
Protocol Buffers
Avro
MessagePack

进一步还必须理解：

Backward Compatibility
Forward Compatibility
Schema Evolution

因为生产系统中的数据不会随着代码部署自动消失。

12. 操作系统是理解运行时的基础

大量高级框架能力最终建立在操作系统提供的几个核心抽象之上：

Process
Thread
Memory
File
Socket
Scheduler

因此，所谓同步、异步、并发，并不能只停留在：

await someFunction()

需要进一步理解：

Process
├── Address Space
├── File Descriptor
└── Threads

线程又涉及：

Thread
├── Scheduling
├── Context Switch
├── Race Condition
├── Mutex
├── Semaphore
├── Condition Variable
└── Atomic Operation

IO 又进一步导向：

Blocking IO
Non-blocking IO
IO Multiplexing
Asynchronous IO

这些机制最终产生不同并发模型：

Thread Pool
Event Loop
Coroutine
Actor
CSP

只有理解这一层，才能真正理解不同语言中的异步机制为什么具有不同性质。

13. 网络是分布式软件的基础运行环境

现代软件几乎不可避免地通过网络协作。

因此，一个工程师不应只知道 HTTP 方法，而应该建立基本协议栈：

Application
↓
HTTP / RPC
↓
TLS
↓
TCP / QUIC
↓
IP

至少需要理解：

DNS
Connection
Socket
Handshake
Timeout
Retry
Keep-Alive
Multiplexing
Congestion Control
Proxy
Reverse Proxy
Load Balancing

尤其重要的是理解：

网络调用与本地函数调用具有根本不同的失败模型。

本地函数调用通常是：

success / failure

远程调用则可能出现：

request never arrived

request arrived but response lost

request executed twice

server executed but client timed out

partial network failure

connection reset

retry causes duplicate effect

这正是：

Timeout
Retry
Idempotency
Deduplication

等分布式系统概念产生的基础。

14. 编译原理训练的是表示转换能力

编译原理的长期价值不只体现在“实现编译器”。

它给出了一个非常清晰的复杂系统分层范例：

Source
↓
Lexer
↓
Token
↓
Parser
↓
AST
↓
Semantic Analysis
↓
Intermediate Representation
↓
Optimization
↓
Code Generation

从这个结构中可以理解大量现实软件。

例如：

SQL Parser
GraphQL Parser
Template Engine
Babel
ESLint
TypeScript Compiler
Configuration Language
DSL

它们本质上都包含某种：

Parse
↓
Represent
↓
Analyze
↓
Transform
↓
Emit

因此，学习编译原理不仅是学习 compiler。

它实际上是在训练：

如何设计中间表示，以及如何将复杂问题分解成多个稳定转换阶段。

15. 架构不是模式的堆积，而是约束关系

很多工程师在基础不足时直接学习：

DDD
Clean Architecture
Hexagonal Architecture
CQRS
Event Sourcing
Microservices

容易形成另一个误区：

架构是一组应该套用的高级模板。

事实上，架构更接近：

对大型系统中依赖、状态、数据、边界和变化关系施加长期约束。

因此架构的前置知识应该包括：

Module
+
Abstraction
+
Dependency
+
Data Modeling
+
Persistence
+
Concurrency
+
Network
+
Failure Model

在这些知识之上，才能正确理解：

Layered Architecture
Hexagonal Architecture
Clean Architecture
Event-Driven Architecture
CQRS
Microservices

架构模式最终解决的仍然是前面那些基本问题，只不过作用范围更大。

16. DDD 的本质首先是业务模型边界

领域驱动设计同样不应该从术语开始。

DDD 最重要的问题是：

现实业务中的概念
↓
如何形成稳定的软件模型？

其核心概念：

Ubiquitous Language
Bounded Context
Entity
Value Object
Aggregate
Repository
Domain Service
Domain Event

实际上围绕两个问题展开：

Business Boundary
+
State Invariant

例如 Aggregate 的关键并不是“对象集合”，而是：

哪一组状态需要在一个一致性边界中维护业务不变量？

Bounded Context 的关键也不是目录结构，而是：

某个业务术语在哪一个语义边界内具有唯一而明确的定义？

因此，DDD 依赖于前面已经建立的数据模型、接口、模块、状态和事务知识。

17. 分布式系统是操作系统、数据库和网络的汇合点

分布式系统不是一个孤立课程。

它可以看成三棵知识树的汇合：

Operating Systems
        \
         \
Database ─────→ Distributed Systems
         /
        /
Networking

其核心问题包括：

Replication
Partitioning
Consistency
Consensus
Leader Election
Distributed Transaction
Idempotency
Retry
Timeout
Backpressure
Failure Detection
Eventual Consistency

这些概念共同回答一个问题：

当数据、计算和失败跨越多台机器以后，如何继续维持系统的正确性和可用性？

18. 前端应该位于知识图中的什么位置

前端不是“不值得学习”。

更准确的说法是：

前端框架不是整个软件知识体系的根，而是 Web 平台能力之上的一个专业分支。

基础知识可以向不同领域展开：

                        React / Vue
                       /
Core Knowledge ─── Backend
                       \
                        Data Engineering
                       \
                        Distributed Systems

如果进一步进入高级前端，则仍然存在大量专业知识：

Browser
↓
HTML Parsing
↓
DOM
↓
CSSOM
↓
Style Calculation
↓
Layout
↓
Paint
↓
Composite

以及：

State
↓
Reactive Dependency
↓
Scheduling
↓
Rendering
↓
Reconciliation

还有：

HTTP
↓
Caching
↓
Resource Scheduling
↓
SSR
↓
Streaming
↓
Hydration

这些知识对于简单 CRUD 页面可能收益有限，但对于：

• 大型交互应用；
• 编辑器；
• Web IDE；
• 图形系统；
• 数据可视化；
• 性能工程；
• 跨端基础设施；
• UI Framework；

具有非常高的工程价值。

因此，正确的问题不是：

前端值不值得学？

而是：

对于当前问题，应该深入到知识图中的哪一层？

19. 本教材的核心知识 DAG

下面给出整本教材的核心依赖关系。

flowchart TD

    A[离散数学基础] --> B[数据结构]
    A --> C[逻辑与集合]

    B --> D[算法基础]
    B --> E[数据表示]

    C --> F[类型与关系]

    D --> G[复杂度分析]

    E --> H[字节与二进制表示]
    H --> I[字符编码]
    H --> J[序列化]
    J --> K[Schema]
    K --> L[Schema Evolution]

    B --> M[变量与状态]
    M --> N[作用域]
    N --> O[闭包]

    F --> P[类型系统]
    P --> Q[多态]
    P --> R[泛型]
    P --> S[代数数据类型]

    O --> T[高阶函数]
    T --> U[函数组合]
    T --> V[纯函数与副作用]

    Q --> W[接口]
    W --> X[实现]
    W --> Y[抽象]

    Y --> Z[模块]
    Z --> AA[封装]
    AA --> AB[信息隐藏]

    AB --> AC[耦合]
    AB --> AD[内聚]

    AC --> AE[依赖]
    AD --> AE

    AE --> AF[组合]
    AE --> AG[依赖反转]

    AF --> AH[设计原则]
    AG --> AH

    AH --> AI[设计模式]

    AI --> AJ[Strategy]
    AI --> AK[Adapter]
    AI --> AL[Observer]
    AI --> AM[Decorator]
    AI --> AN[Factory]
    AI --> AO[Command]
    AI --> AP[State]
    AI --> AQ[Composite]

    B --> AR[数据建模]
    F --> AR

    AR --> AS[实体与值对象]
    AR --> AT[关系模型]
    AT --> AU[关系代数]
    AU --> AV[SQL]

    AV --> AW[Join]
    AV --> AX[Aggregation]
    AV --> AY[Window]

    AT --> AZ[数据库存储]
    AZ --> BA[Index]
    AZ --> BB[Query Execution]

    AV --> BC[Transaction]
    BC --> BD[ACID]
    BC --> BE[Isolation]
    BE --> BF[MVCC]

    AR --> BG[数据分层]
    BG --> BH[ETL / ELT]
    BH --> BI[Data Warehouse]
    BI --> BJ[Data Mart]
    BJ --> BK[Analytics Model]

    M --> BL[进程]
    BL --> BM[线程]
    BM --> BN[并发]

    BN --> BO[Race Condition]
    BO --> BP[Mutex]
    BO --> BQ[Atomic]
    BP --> BR[Condition Variable]
    BP --> BS[Semaphore]
    BP --> BT[Deadlock]

    BL --> BU[虚拟内存]
    BL --> BV[文件系统]

    BV --> BW[IO]
    BW --> BX[Blocking IO]
    BW --> BY[Non-blocking IO]
    BY --> BZ[IO Multiplexing]
    BZ --> CA[Event Loop]

    BN --> CB[Coroutine]
    BN --> CC[Actor]
    BN --> CD[CSP]

    CA --> CE[Async/Await]
    CB --> CE

    H --> CF[机器指令]
    CF --> CG[汇编]
    CG --> CH[目标文件]
    CH --> CI[Linking]
    CI --> CJ[Executable]
    CJ --> BL

    I --> CK[Source Text]
    CK --> CL[Lexer]
    CL --> CM[Token]
    CM --> CN[Parser]
    CN --> CO[AST]
    CO --> CP[Semantic Analysis]
    CP --> CQ[IR]
    CQ --> CR[Optimization]
    CR --> CS[Code Generation]
    CS --> CF

    BW --> CT[Socket]
    CT --> CU[TCP]
    CU --> CV[TLS]
    CV --> CW[HTTP]
    CU --> CX[QUIC]
    CX --> CY[HTTP/3]

    CW --> CZ[RPC]
    CW --> DA[Web Architecture]

    BC --> DB[Persistence]
    AE --> DC[Architecture Boundary]
    DB --> DC

    DC --> DD[Layered Architecture]
    DC --> DE[Hexagonal Architecture]
    DC --> DF[Clean Architecture]

    AS --> DG[Domain Modeling]
    BC --> DG
    DC --> DG

    DG --> DH[DDD]
    DH --> DI[Bounded Context]
    DH --> DJ[Aggregate]
    DH --> DK[Domain Event]

    CU --> DL[Distributed Failure Model]
    BC --> DL
    BN --> DL

    DL --> DM[Distributed Systems]

    DM --> DN[Replication]
    DM --> DO[Partitioning]
    DM --> DP[Consistency]
    DM --> DQ[Consensus]
    DM --> DR[Leader Election]
    DM --> DS[Idempotency]
    DM --> DT[Retry]
    DM --> DU[Timeout]
    DM --> DV[Backpressure]

    DN --> DW[Eventual Consistency]
    DO --> DW

    DK --> DX[Event-Driven Architecture]
    DM --> DX

    DG --> DY[CQRS]
    DX --> DY

    DM --> DZ[Microservices]
    DC --> DZ

    DA --> EA[Browser Architecture]
    EA --> EB[DOM]
    EA --> EC[CSSOM]
    EB --> ED[Layout]
    EC --> ED
    ED --> EE[Paint]
    EE --> EF[Composite]

    M --> EG[UI State]
    EG --> EH[Reactive System]
    EH --> EI[Scheduler]
    EI --> EJ[Rendering]
    EJ --> EK[Reconciliation]

    CW --> EL[Caching]
    DA --> EM[SSR]
    EM --> EN[Streaming]
    EN --> EO[Hydration]

20. DAG 的主干

如果去掉支线，整个课程可以进一步压缩成七条主链。

20.1 软件设计链

变量
↓
函数
↓
作用域
↓
闭包
↓
类型
↓
接口
↓
抽象
↓
模块
↓
封装
↓
信息隐藏
↓
耦合 / 内聚
↓
依赖
↓
组合
↓
设计原则
↓
设计模式
↓
架构

20.2 数据链

数据结构
↓
数据表示
↓
数据建模
↓
关系模型
↓
SQL
↓
事务
↓
索引
↓
查询执行
↓
数据分层
↓
数据仓库
↓
分布式数据系统

20.3 数据表示链

Bit
↓
Byte
↓
Integer
↓
Floating Point
↓
Character
↓
Unicode
↓
UTF-8
↓
Serialization
↓
Schema
↓
Schema Evolution
↓
Protocol

20.4 系统链

Machine Instruction
↓
Process
↓
Virtual Memory
↓
Thread
↓
Concurrency
↓
Synchronization
↓
IO
↓
Socket
↓
Network

20.5 编程语言链

Source Text
↓
Lexer
↓
Token
↓
Parser
↓
AST
↓
Semantic Analysis
↓
IR
↓
Machine Code
↓
Runtime

20.6 分布式系统链

Network
+
Concurrency
+
Database
↓
Distributed Failure
↓
Replication
↓
Partition
↓
Consistency
↓
Consensus
↓
Distributed Architecture

20.7 业务架构链

Data Modeling
↓
Invariant
↓
Domain Model
↓
Transaction Boundary
↓
Bounded Context
↓
Domain Event
↓
Architecture
↓
Complex Business System

21. 推荐的教材拓扑序

DAG 不要求只有一种学习顺序。

但对于大多数软件工程师，可以使用下面这一拓扑排序：

01 数据结构
02 变量与状态
03 函数
04 作用域
05 闭包
06 类型
07 多态
08 泛型
09 接口与实现
10 抽象
11 模块
12 封装
13 信息隐藏
14 耦合与内聚
15 组合
16 依赖
17 设计原则
18 设计模式
19 数据表示
20 字节
21 Unicode / UTF
22 序列化
23 数据建模
24 关系模型
25 SQL
26 Join
27 Transaction
28 Index
29 Query Execution
30 Process
31 Virtual Memory
32 Thread
33 Race Condition
34 Lock
35 Atomic
36 Deadlock
37 IO
38 Event Loop
39 Coroutine
40 Async/Await
41 Socket
42 TCP
43 TLS
44 HTTP
45 Lexer
46 Parser
47 AST
48 Interpreter
49 Compiler
50 Data Layering
51 Data Warehouse
52 Distributed Failure
53 Replication
54 Partition
55 Consistency
56 Consensus
57 Idempotency
58 Retry
59 Backpressure
60 Architecture Boundary
61 Layered Architecture
62 Hexagonal Architecture
63 DDD
64 Bounded Context
65 Aggregate
66 Domain Event
67 Event-Driven Architecture
68 CQRS
69 Microservices
70 Browser Architecture
71 Rendering Pipeline
72 Reactive System
73 Scheduler
74 SSR
75 Streaming
76 Hydration

这 76 个节点已经足以形成一套相当完整的软件工程基础教材。

22. 每个章节只讨论一个概念

本教材应该刻意避免传统教材常见的问题：

一个章节同时引入五到十个新概念。

对于 AI 辅助学习而言，更合适的粒度是：

One Chapter
=
One Concept

例如：

Chapter 17: Coupling

只解释 coupling。

下一章：

Chapter 18: Cohesion

只解释 cohesion。

之后：

Chapter 19: Dependency

再讨论 dependency。

这样做有几个明显优势。

第一，每个概念都可以单独检索、复习和重新生成。

第二，可以明确记录概念的 prerequisites。

第三，可以让 AI 针对某个知识节点反复采用不同语言、不同案例解释。

第四，可以执行知识图谱意义上的拓扑学习，而不是被一本教材固定的章节顺序绑定。

23. 每章统一使用同一个知识模板

建议所有概念章节采用统一结构。

# Concept Name

## 1. Definition

这个概念是什么？

## 2. Motivation

它解决什么问题？

## 3. Problem Without It

如果没有这个概念，会发生什么？

## 4. Minimal Model

给出该概念最小化的形式模型。

## 5. Mechanism

它内部如何工作？

## 6. Invariants

必须始终保持什么条件？

## 7. Example

给出最小业务例子。

## 8. Cross-Language Comparison

分别使用 TypeScript / Go / Java / Rust 表达。

## 9. Common Misconceptions

最常见的误解是什么？

## 10. Failure Modes

在工程实践中通常如何出错？

## 11. Related Concepts

与哪些概念横向关联？

## 12. Prerequisites

学习这个概念之前应该掌握什么？

## 13. Next Concepts

下一步应该学习什么？

## 14. Exercises

提供推理题，而不只是编码题。

24. AI 学习 Prompt 协议

因此，可以将每一个 DAG 节点直接提交给 AI。

推荐固定 Prompt：

你正在给我编写一本面向资深软件工程师的极简教材。

当前概念：

<CONCEPT>

请严格只围绕这个概念讲解。

要求：

1. 给出严格但工程可理解的定义。
2. 解释它试图解决什么问题。
3. 解释没有这个概念时系统会出现什么问题。
4. 建立最小形式模型。
5. 解释底层机制，而不是只描述 API。
6. 列出关键 invariant。
7. 给一个最小真实业务案例。
8. 如果适用，分别使用 TypeScript、Go、Java、Rust 表达。
9. 比较不同语言为什么采用不同实现。
10. 列出常见误区。
11. 列出真实工程中的 failure modes。
12. 明确列出 prerequisites。
13. 明确列出 next concepts。
14. 给出 3 道概念推理题。
15. 不引入尚未出现在 prerequisites 中的新概念；如果必须使用，先给出最小定义。

写作风格：
学术、技术、紧凑、避免营销语言和无意义类比。

这样整本教材实际上可以被定义成：

DAG
+
Chapter Template
+
AI Generator

25. 教材不应该测试 API 记忆

传统技术面试和技术教育常常过度关注：

某 API 的参数是什么？
某框架生命周期是什么？
某个配置应该写在哪里？

AI 已经显著降低了这类记忆的价值。

本教材更应该测试：

为什么？

什么时候？

有什么不变量？

失败会怎样？

边界在哪里？

数据属于谁？

状态属于谁？

谁依赖谁？

表示为什么这样设计？

另一个方案有什么 trade-off？

例如，不应该主要考：

Promise.all 怎么用？

而应该考：

三个异步任务是否具有依赖关系？
是否允许部分失败？
是否需要限制并发？
是否具有幂等性？
调用方取消以后任务是否应该继续？

这才是可迁移的工程能力。

26. 算法应该占据什么位置

算法仍然重要，但对于大多数业务软件工程师，其学习目的已经发生变化。

不一定要求重复实现所有经典算法。

更重要的是理解：

Time Complexity
Space Complexity
Hashing
Tree
Heap
Graph
Index
Search
Sort
Dynamic Programming

并能够判断：

这个问题属于哪一类计算问题？

数据规模是多少？

复杂度会如何增长？

是否存在更合适的数据结构？

因为具体实现已经越来越容易由标准库或 AI 提供。

但如果连：

O(n)
O(log n)
O(n log n)
O(n²)

都缺乏直觉，则仍然无法判断 AI 生成的程序是否合理。

27. AI 不应该替代系统模型

未来大量代码可能不会由人逐行编写。

但这并不意味着软件工程知识的重要性下降。

更可能发生的是：

Human
↓
Model / Constraint / Architecture
↓
AI
↓
Code

人的角色逐渐从：

statement author

转向：

system modeler
constraint designer
architecture reviewer
failure analyst

因此，高水平工程师的核心问题不再只是：

我能不能实现？

而是：

我能不能验证实现？

而验证需要依赖完整的心智模型。

如果工程师不知道：

• transaction isolation；
• event ordering；
• ownership；
• lifetime；
• idempotency；
• data invariant；
• module boundary；

那么即使 AI 生成的代码能够编译，也很难判断它是否真正正确。

28. 最终学习目标：读懂陌生系统

本教材的最终目标并不是让学习者记住几十个设计模式或者掌握几十种工具。

理想状态是：

面对一个从未见过的大型系统，仍然能够迅速建立其内部模型。

进入一个陌生代码库时，可以主动寻找：

Data Model
State
Control Flow
Dependency Graph
Module Boundary
Persistence Boundary
Concurrency Model
Failure Model
External Interface
Representation Transformation

例如第一轮阅读可以只回答：

核心数据有哪些？

核心状态在哪里？

入口在哪里？

数据从哪里进来？

经过哪些 transformation？

在哪里持久化？

哪些模块拥有副作用？

异步边界在哪里？

错误在哪里被处理？

哪些组件依赖外部系统？

第二轮再继续识别：

抽象是否合理？

依赖方向是否稳定？

是否存在循环依赖？

是否混合了多个业务边界？

是否存在重复状态？

数据表示是否泄漏？

事务边界是否正确？

并发访问是否安全？

一旦具备这些能力，语言和框架迁移就会变得明显容易。

面对陌生语言，需要寻找的只是：

这里如何表达 interface？

如何表达 generic？

如何表达 closure？

如何处理 error？

如何执行 async？

如何管理 resource？

如何组织 package / module？

面对陌生框架，则进一步寻找：

生命周期在哪里？

状态模型是什么？

依赖注入在哪里？

IO 边界在哪里？

调度器在哪里？

扩展点在哪里？

这与重新学习整个软件工程是完全不同的难度。

29. 一个更抽象的软件工程知识模型

最终，我们可以将本书几乎所有概念进一步压缩成九个基本问题：

Data
State
Representation
Transformation
Boundary
Dependency
Control Flow
Concurrency
Failure

任何复杂系统都可以沿这九个维度进行分析。

Data

系统处理什么事实？

State

哪些事实随时间变化？

Representation

这些事实以什么形式存在？

Transformation

一种表示如何变成另一种表示？

Boundary

哪些东西属于同一个模块或一致性范围？

Dependency

谁知道谁？

谁依赖谁？

Control Flow

谁调用谁？

控制权如何传播？

Concurrency

哪些事情可能同时发生？

Failure

当其中一部分失败时，系统如何表现？

30. 软件工程的统一视角

于是，前端：

State
+
Transformation
+
Rendering

后端：

Boundary
+
Dependency
+
Persistence

数据库：

Data
+
State
+
Consistency

数据工程：

Representation
+
Transformation
+
Aggregation

操作系统：

State
+
Resource
+
Concurrency

编译器：

Representation
+
Transformation
+
Semantics

分布式系统：

State
+
Concurrency
+
Failure

架构：

Boundary
+
Dependency
+
Evolution

看起来不同的领域，实际上反复研究的是同一组基本问题。

31. 本书的基本立场

因此，本教材采用以下原则。

第一：

不以框架作为知识结构的根。

第二：

不以语言作为知识边界。

第三：

不把设计模式当作代码模板。

第四：

不把数据处理理解为简单的数据搬运。

第五：

不把异步理解为 async/await 语法。

第六：

不把数据库理解为 SQL API。

第七：

不把编译原理理解为编译器开发专属知识。

第八：

不把架构理解为架构图。

第九：

不把 AI 生成的代码等同于已经理解的代码。

32. 应该建立什么样的工程直觉

一个成熟的软件工程师应该逐渐形成一些近乎自动化的判断。

看到对象时问：

它代表什么数据？

看到字段时问：

它是事实还是派生状态？

看到类时问：

它真正隐藏了什么？

看到接口时问：

这里为什么需要替换实现？

看到模块时问：

边界为什么画在这里？

看到异步时问：

谁在调度？谁可能同时发生？

看到网络请求时问：

失败以后发生什么？

看到数据库写入时问：

事务边界在哪里？

看到消息队列时问：

是否可能重复？
顺序是否重要？

看到缓存时问：

允许多长时间不一致？

看到数据转换时问：

为什么需要新的 representation？

看到设计模式时问：

它控制的到底是哪一种变化？

看到 AI 代码时问：

它维持了哪些 invariants？

这些问题比记忆任何一个框架的 API 都更具有长期价值。

33. 结语：知识应该形成图，而不是列表

软件工程知识并不是：

Java
React
Redis
Kafka
Docker
Kubernetes

这样的技术名词列表。

它更接近一个概念网络：

             abstraction
            /           \
       interface       module
          |              |
     dependency       boundary
          \              /
            architecture
                 |
               system

另一个方向：

data
↓
representation
↓
transformation
↓
storage
↓
transaction
↓
replication
↓
distributed state

还有：

process
↓
thread
↓
concurrency
↓
IO
↓
network
↓
distributed system

当这些知识逐渐连接起来以后，工程师会发现：

很多看似新的技术，实际上只是旧问题的一种新组合。

一个新的状态管理框架可能重新组合：

State
Dependency
Observer
Scheduler

一个新的后端框架可能重新组合：

Module
Dependency Injection
HTTP
Serialization
Persistence

一个新的分布式数据库可能重新组合：

Storage
Replication
Partition
Consensus
Transaction

一个新的 AI Agent Framework 可能重新组合：

State
Workflow
Event
Tool Interface
Serialization
Retry
Persistence

因此真正具有长期复利的学习方式，不是不断追逐技术名称。

而是不断增加自己能够识别的底层概念。

最终理想状态是：

New Technology
↓
Recognize Existing Concepts
↓
Locate Novel Mechanism
↓
Understand Trade-offs
↓
Use It

而不是：

New Technology
↓
Start From Zero

这就是本教材试图建立的软件工程学习体系。

Appendix A — 推荐核心教材

软件设计

John Ousterhout — A Philosophy of Software Design

重点：

• Complexity
• Deep Module
• Information Hiding
• Interface
• General-Purpose Module

Martin Fowler — Refactoring

重点：

• Code Smell
• Refactoring
• Responsibility
• Change Boundary

Gamma et al. — Design Patterns

不建议机械背诵全部模式。

优先：

Strategy
Adapter
Observer
Decorator
Factory
Command
State
Composite
Proxy
Facade

Appendix B — 系统基础

Computer Systems: A Programmer's Perspective

重点：

Data Representation
Machine Code
Memory
Linking
Process
Virtual Memory
IO
Concurrency

Operating Systems: Three Easy Pieces

重点：

Virtualization
Concurrency
Persistence

Computer Networking: A Top-Down Approach

重点：

Application Layer
Transport Layer
Network Layer

Appendix C — 数据系统

Database System Concepts

重点：

Relational Model
Relational Algebra
Index
Transaction
Query Execution

Designing Data-Intensive Applications

重点：

Data Model
Storage
Replication
Partition
Transaction
Batch
Stream
Distributed Systems

这本书尤其适合已经具有一定工程经验后反复阅读。

Appendix D — 编程语言与编译

Crafting Interpreters

重点：

Lexer
Parser
AST
Interpreter
VM
GC

如果希望进一步理解类型系统，可以继续：

Types and Programming Languages

Appendix E — 领域与架构

DDD 建议首先阅读：

Domain-Driven Design Distilled

然后再阅读：

Domain-Driven Design

重点不是模式名称，而是：

Business Model
Language
Boundary
Invariant
Consistency

Appendix F — 整套教材的最小核心书单

如果只允许选择五本：

A Philosophy of Software Design
↓
Computer Systems: A Programmer's Perspective
↓
Operating Systems: Three Easy Pieces
↓
Designing Data-Intensive Applications
↓
Crafting Interpreters

它们分别回答：

软件应该如何组织？
计算机如何执行软件？
运行中的系统如何工作？
数据系统如何工作？
编程语言如何工作？

这五个问题构成理解现代软件系统的一条极强主干。

Appendix G — 最终原则

可以将整套方法压缩为一句话：

学习软件工程时，应优先掌握跨语言、跨框架、跨业务长期稳定的概念，并将语言与框架理解为这些概念在具体计算环境中的实现。

进一步压缩：

Learn concepts.
Model systems.
Understand boundaries.
Control dependencies.
Understand data.
Reason about state.
Reason about failure.
Use languages as tools.
Use frameworks as tools.
Use AI as an implementation amplifier.

最终目标不是成为某一个框架的熟练使用者。

而是：

面对陌生语言、陌生框架、陌生代码库和陌生业务时，仍然能够快速恢复其数据模型、状态模型、依赖结构、控制流、并发模型与失败模型，并在此基础上安全地修改系统。

这才是一套能够跨越技术周期的软件工程能力。

架构设计出问题 软件熵带来的技术债确实难评

AI 时代，软件基本功反而更重要

作者：Matt Pocock

我有一个消息想告诉你，希望它能带来一些安慰——尤其是如果你曾觉得自己的技能在这个新时代已经毫无价值的话。

我认为软件基础现在依然重要。比以往任何时候都更重要。

我是一名教师。最近我正在教授一门名为《Claude 代码实战工程师》的课程，非常吸引人，也极其发人深省。在准备这门课程的过程中，我不得不制定一个关于 AI 编程的课程大纲。这简直是噩梦般的困难——因为事物总在不断变化。AI 代表全新的范式，似乎我们需要摒弃所有旧规则，才能引入新知识。

但我想告诉你：别急。那些旧书里的智慧，恰恰是现在最需要的东西。

"从规格到代码"的幻灭

围绕 AI 编程趋势，出现了一种运动——"从规格到代码"（Spec to Code）。它主张：你可以编写应用程序应如何运作的规格说明，然后用 AI 将其转化为代码。如果应用出现问题，你只需返回修改规格，无需查看代码，只需调整规格，再次运行"编译器"，最终生成更多代码。

我听说过这个。我也尝试过。

我注意到的是：我会运行它，尽量不看代码。但我忍不住会去看。然后我发现——首先得到代码，运行它，得到更差的代码。再次尝试，代码变得更差且重复出现。持续运行编译器，不断运行编译器，最终生成一堆垃圾代码。

如果你也经历过这个，你就知道我在说什么。

这行不通。认为我们可以忽略代码、让代码自行管理的想法，本质上就是另一种逃避编程。

我当时想：我得怎么修复这个"编译器"？我得怎么让它不再每次生成错误代码，或者更糟糕的代码？

于是我思考：好吧，我需要用英语向 LLM 解释，什么是良好的代码库。

我翻出了一本旧书——John Ousterhout 的《软件设计哲学》（A Philosophy of Software Design）。去亚马逊看看，买下它。他定义了什么是糟糕的代码。他称之为"复杂代码"——复杂性涉及软件系统的结构，让系统难以理解和修改。糟糕的代码库就是难以修改的代码。如果你修改代码却引发新 bug，那就是糟糕的代码库。优秀的代码库易于修改。

然后我又翻了《实用程序员》（The Pragmatic Programmer）。去亚马逊看看，买下它。他们有一章讲"软件熵"——这正是我看到的现象。熵指事物趋向混乱和崩溃。大多数软件系统就是这样运行的。每次修改代码库时，只关注局部改动而忽略整体设计，代码库就会越来越差。

这正是反复运行"编译器"时发生的事情。

"Spec to Code"运动的核心理念是：代码廉价。

我不认同这个观点。我认为代码并不廉价。事实上，糟糕的代码成本最高。因为如果你有一个难以修改的代码库，你就无法充分利用 AI 提供的全部价值。AI 在良好的代码库中表现极为出色。

这意味着优质代码库比以往更重要。这意味着软件基础比以往更重要。

这就是这篇文章的核心观点。

你可能遇到的 AI 失败模式（以及如何用经典智慧解决它们）

接下来我要讨论你可能遇到的 AI 相关失败模式——或者你尚未遇到但迟早会遇到的——以及如何通过回归经典书籍并遵循良好实践来避免它们。

失败模式 #1：AI 没有按我预期执行

你以为自己脑海中有一个好主意，但 AI 却做了完全不同的事情。或者你生成了一些类似规格说明的东西，结果它制作了你并不想要的东西。

《实用程序员》中有一句话说得好：没有人确切知道自己想要什么。 你与 AI 之间存在沟通障碍。当你与 AI 交流时，这类似于 AI 在收集需求——它正在从你这里梳理需求，明确你需要什么。

这让我想到了 Frederick P. Brooks 的《设计原本》（The Design of Design）。书中提到一个概念叫设计概念（Design Concept）：当多人共同设计某事物时，会有一个想法在你们之间流转——这个正在构建的事物的瞬时概念。它不是资产，无法写入 Markdown 文件。它是构建事物的无形理论。

所以我想明白了：我和 AI 缺乏共同的设计概念。

我总结出一个技巧，非常简单，叫做 GRIME。方法是：不断深入询问计划的每个细节，直到达成共识。逐层分析设计树的每个分支。这是 Brooks 的另一个观点——逐个解决决策之间的依赖关系。

这项技能放在我的 GitHub 仓库里，已经超过一万三千颗星。它突然失控了，迅速走红，人们非常喜欢。这几行提示词意味着 AI 会向你提问四十次、六十次问题。我曾遇到它连续提问一百次，直到满意为止，直到双方达成共同理解。

这意味着将 AI 转化为一种对手——它不断抛出想法，试图达成共识。而你生成的对话内容，可以直接转化为产品需求文档（PRD）。如果是小改动，可直接生成任务工单，然后你的异步代理会接手处理。

我觉得这比 Claude Code 的默认"计划模式"更好。Claude Code 的计划模式非常急于创建资产，迫切想要制定计划立即执行。而我认为，先达成设计共识更佳。

失败模式 #2：AI 过于啰嗦

你和 AI 几乎在不同频道沟通。AI 在长篇大论，用太多词汇解释自己的行为。你们的语言体系不同。

如果你长期从事开发工作，并与领域专家协作开发应用——假设领域专家要求你构建一个关于"微芯片"的东西，你完全不了解微芯片——你需要建立共同语言。否则他们会使用专业术语，你无法理解；你将其转化为代码，可能自己也不懂，领域专家更不会懂。你与专家之间存在语言鸿沟。

于是我回归了领域驱动设计（DDD）。这是我仍在探索的边缘领域，但所有我读到的内容都让我觉得——这就像我耳朵里的天籁之音，我简直爱死它了。

DDD 有一个核心概念：通用语言（Ubiquitous Language）。通过通用语言，开发者之间的对话、代码中的表达、以及与领域专家的交流，都源自同一领域模型。

在我们的场景中，它本质上是一个 Markdown 文件——包含你和 AI 共同理解的术语列表。你真正聚焦这些术语，确保它们与实际含义一致，并在代码中频繁使用。当你谈论代码时，当你与领域专家交流时，或者在我们的情况中——与 AI 对话时。

所以我开发了一个技能：通用语言技能。简单扫描代码库，识别术语，然后生成一个 Markdown 文件——包含大量术语的 Markdown 表格。然后我将其传递给 AI。我也能阅读它。我甚至一直保持它打开，在与 AI 对话和规划时。

通过阅读 AI 的思考轨迹，我发现它不仅提升了规划效率，还让 AI 以更简洁的方式思考，实际上使实现更贴近原计划。

这绝对是个强力工具。效果惊人。

与 AI 建立共享语言。

失败模式 #3：代码无法运行

假设你已与 AI 达成共识，清楚自己要构建的目标，AI 已正确构建——但它无法运行。运行效果不佳。

显然我们可以改进反馈循环：

• 使用静态类型。 如果你不使用 TypeScript，那太疯狂了。
• 给 LLM 访问浏览器的能力。 如果你在开发前端应用，绝对需要让它能查看环境。
• 自动化测试。 显然你也需要这个。

但我注意到一个问题：即使有这些反馈循环，语言模型并没有很好地利用它们。它并没有像经验丰富的开发者那样充分利用反馈循环。它所做的往往是同时做太多事情——生成大量代码，然后才想"哦，我应该进行类型检查"，或者"或许应该为这部分写测试"。

这在《实用程序员》中被描述为 "超出行车灯范围"——本质上是行驶过快。因为反馈速度就是你的限速。这意味着你应该边写代码边测试，采取小步谨慎推进。而 AI 默认在这方面表现很差。

所以，第三个技能是 TDD（测试驱动开发）。你应该使用测试驱动开发，因为 TDD 迫使语言模型采取小步操作：先编写测试用例，让测试通过，然后重构代码使其更优雅并考虑设计。

但问题在于，测试本身非常困难。测试向来都很困难。原因在于需要做出大量不同决策：需要确定测试单元的大小，需要决定如何模拟，需要确定要测试哪些行为。所有这些决策相互关联。如果你测试一个大单元，比如整个庞大应用，可能会非常不稳定，可能不需要测试太多行为。如果你只测试一个小单元，需要模拟很多东西。这些都是相互关联的。

多年来，我的整个开发生涯都在思考这个问题。我们发现：好的代码库更容易测试。

没错，我们现在开始回到代码的重要性。代码库越好，反馈循环就越有效，因为你能给语言模型提供更好的反馈，它就能生成更好的代码。

深度模块 vs. 浅层模块

于是我开始思考：一个好的代码库应该是什么样的？可测试的代码库应该具备哪些特征？

我们去找 John Ousterhout。他谈到代码库中应有深度模块（Deep Modules），而不是浅层模块。不是那种包含大量函数的模块。应有相对较少的大型深度模块，搭配简单接口。

快速对比一下：

• 深度模块： 大量功能隐藏在简单接口背后。隐藏复杂性。你可以查看深度模块内部，如果需要的话，但不需要这样做。只需使用接口即可。
• 浅层模块： 功能较少，复杂接口。

代码库中的浅层模块看起来像许多不同微小的模块块。AI 需要遍历和导航这些模块，这对 AI 探索来说非常困难。当你遇到这样的代码库时——讽刺的是，AI 其实很擅长创建这类代码库——会导致 AI 无法理解代码逻辑。它会尝试探索代码，但由于结构混乱，充斥着浅层模块，可能无法及时找到正确模块，或无法理清所有依赖关系。

而充满深度模块的代码库呢？同样是这些代码，但结构被边界划分清晰，顶部有简单的接口。这些接口需要精心设计并严格控制，否则可能会破坏设计。但实现部分可以部分交给 AI。

我掌握了一个"优化代码架构"的技能。事实证明实现起来相当复杂，但这是一系列可重复使用的步骤：探索代码库，寻找机会，在相关代码处将所有内容封装在深层模块中。

这是一个可测试的代码库，因为代码边界非常简单——在接口处进行测试，通过该接口验证，即可投入使用。这是一个鼓励 TDD 的代码库。

失败模式 #4：大脑跟不上节奏

假设你的反馈循环正常运作，事情开始运转，你能比以往更快交付代码。但大脑跟不上节奏。

如果你在开发生涯中感到前所未有的疲惫——我也是。真是累人。

我认为浅层模块的代码库实际上让大脑更难处理。你和 AI 都需要记住所有信息。而深度模块对你阅读和理解代码更简单。

同时，你可以将这些深层模块视为灰盒。你可以说：我只需设计接口，不必过多担心或审查实现细节。这在应用中非关键部分显然可行（在金融等关键场景中可能不行）。但在应用的许多模块中，无需过多考虑实现细节，只要模块外部有可测试边界，只要理解其目的并从外部设计。

这确实拯救了我的大脑。 因为我只需说："好的，AI，让我处理内部细节。这个大块，我只需从外部测试并验证。"

设计接口，委托实现细节。

每天投资于系统设计

但这意味着每当我们修改代码时，每当我们进行规划时，我们需要考虑并意识到应用程序中的模块。我们需要非常熟悉这些模块。这必须成为我们的通用语言，我们也需要将其融入规划能力中。

所以我在 PRD 中编写需求时，会明确说明模块变更及模块内的接口是如何被修改的。我时刻都在思考这些。

这源于 Kent Beck 的理念：每天投资于系统设计。

这才是核心所在。因为"规格到代码"的理念中，我们并未投资于系统设计。我们正在剥离系统设计，我们正在摒弃这些。而我认为这绝对至关重要。

结语：代码并非廉价

这是我希望你记住的信息：代码非常重要。

如果我们认为 AI 是优秀的现场程序员——一种战术型程序员，前线的中尉，进行代码修改——那么你需要更高层的人。你需要进行战略层面的思考。

而这正是你的职责。

这需要我们二十年来一直在使用的软件基础技能。

如果你对这里提到的任何技能感兴趣，请查看 GitHub 仓库 mattpocock/skills。如果你对我的培训课程感兴趣，或任何免费资源，我在 YouTube，我在 Twitter。我也是 AI Hero 的开发者，我有一个你可以订阅的新闻简讯。

非常感谢你读到这里。希望这能增强你在 AI 时代的信心。

你确实能产生积极影响。

之前拿 AI 水过一篇类似的笔记

核心思想

通过构建一个无风险对冲投资组合来消除标的资产价格的随机性，再利用无套利原理推导出衍生品（如期权）的定价偏微分方程。

符号定义

几何布朗运动（GBM）

假设资产价格短期内服从几何布朗运动：

• 漂移项：$ \mu S , dt $ 表示确定性增长趋势；
• 扩散项：$ \sigma S , dz $ 表示由随机冲击引起的波动。
• 标准维纳过程的微分增量 $ dz $：满足 $ dz \sim \mathcal{N}(0, dt) $

构建无风险对冲组合

投资组合构造

构建一个由1 份衍生品多头和**$ \Delta $ 份标的资产空头**组成的投资组合：

其中，选择对冲比率：

这一选择使得对冲组合对标的资产价格的一阶变动无关。

组合价值的瞬时变化

在无穷小时间 $ dt $ 内，组合价值变化为：

伊藤引理（Itô’s Lemma）

由于 $ V = V(S, t) $，且 $ S $ 是随机过程，需使用伊藤引理展开 $ dV $：

计算 $ (dS)^2 $

代入 $ dS = \mu S dt + \sigma S dz $，得：

根据伊藤微积分规则（当 $ dt \to 0 $）：

• $ (dt)^2 \to 0 $
• $ dt \cdot dz \to 0 $
• $ (dz)^2 = dt $

因此：

代入伊藤引理

整理得：

代入对冲组合并消除随机性

将 $ dV $ 和 $ dS $ 代入 $ d\Pi = dV - \frac{\partial V}{\partial S} dS $：

展开后：

• 随机项（含 $ dz $）：
  

  $$\sigma S \frac{\partial V}{\partial S} dz - \frac{\partial V}{\partial S} \sigma S dz = 0$$

• 确定性项（含 $ dt $）：
  

  $$\left( \frac{\partial V}{\partial t} + \frac{1}{2} \sigma^2 S^2 \frac{\partial^2 V}{\partial S^2} \right) dt$$

因此，对冲后的组合无随机性：

无套利原理与 Black-Scholes PDE

由于 $ \Pi $ 是无风险组合，其收益率必须等于无风险利率 $ r $，否则存在套利机会。

无风险资产的增长满足：

将两种表达式联立：

两边除以 $ dt $，整理得 Black-Scholes 偏微分方程（PDE）：

希腊字母

• **Delta ($ \Delta $)**：$ \frac{\partial V}{\partial S} $，对冲比率；
• **Gamma ($ \Gamma $)**：$ \frac{\partial^2 V}{\partial S^2} $，Delta 对价格的敏感度；
• **Theta ($ \Theta $)**：$ \frac{\partial V}{\partial t} $，时间衰减。

PDE 求解

变量分类

在实际应用中，我们将 Black-Scholes PDE 中的变量分为三类：

可观测的输入

这些是市场数据或合约条款，可以直接获取：

不可直接观测的输入

• 估计方法：
  • 历史波动率：基于过去价格收益率的标准差，反映历史波动，未必代表未来。
  • 隐含波动率（Implied Volatility, IV）：市场标准做法。将市场实际交易的期权价格 $ V_{\text{market}} $ 与其他已知参数代入 Black-Scholes 公式，反向求解出使模型价格等于市场价格的 $ \sigma $。

    即：求解 $ V_{\text{BS}}(S, K, T, r, \sigma) = V_{\text{market}} $ 中的 $ \sigma $

最终要求解的 V

求解目标：

找到一个具体的定价函数 $ V(S, t) $，使其满足该 PDE 以及特定衍生品的边界条件与终值条件。

该函数 $ V(S, t) $ 的作用是：

给定任意时刻 $ t \lt T $ 和任意标的资产价格 $ S $，输出该衍生品的理论公允价值。

解析解

• 适用对象：欧式期权等结构简单、边界条件明确的衍生品。
• 方法：通过变量代换（如 $ x = \ln S $, $ \tau = T - t $）将 PDE 转化为热传导方程求解。
• 优点：结果精确、计算极快。
• 缺点：无法处理美式期权（因提前行权导致自由边界问题）。

对于欧式看涨期权，终值条件为：

求解 PDE 得到著名的 Black-Scholes 定价公式：

其中：

$ N(\cdot) $ 为标准正态分布的累积分布函数。

数值方法

当解析解不存在时，使用数值近似。

1. 有限差分法（Finite Difference Method, FDM）

• 核心思想：将连续的 $ (S, t) $ 平面离散化为网格，用差商近似偏导数。
  
  $$\frac{\partial V}{\partial t} \approx \frac{V^{n+1}_i - V^n_i}{\Delta t}, \quad \frac{\partial^2 V}{\partial S^2} \approx \frac{V^n_{i+1} - 2V^n_i + V^n_{i-1}}{(\Delta S)^2}$$
• 求解方向：从到期日 $ t = T $（已知终值）向后倒推至当前时刻 $ t = 0 $。
• 优点：通用性强，可处理美式期权（通过在每步判断是否行权）、时变参数等。
• 缺点：实现较复杂，计算量较大。

2. 二叉树/三叉树模型（Binomial/Trinomial Tree）

• 核心思想：对标的资产价格路径进行离散化建模。
  • 每步：$ S \to uS $（上涨）或 $ S \to dS $（下跌），其中 $ u = e^{\sigma \sqrt{\Delta t}}, d = 1/u $
• 定价过程：
  1. 构建价格树至到期日；
  2. 在叶节点计算期权 payoff；
  3. 从后往前，按风险中性概率折现：
     
     $$V = e^{-r \Delta t} [p V_{\text{up}} + (1 - p) V_{\text{down}}]$$
     
     其中 $ p = \frac{e^{r \Delta t} - d}{u - d} $
• 优点：直观、天然支持美式期权（每节点比较行权价值与持有价值）。
• 缺点：收敛速度慢，高维问题效率低。

3. 蒙特卡洛模拟（Monte Carlo Simulation）

• 核心思想：基于风险中性定价原理，不直接解 PDE，而是模拟未来路径。
• 步骤：
  1. 在风险中性测度下模拟 $ N $ 条资产价格路径：
     
     $$S_{t+\Delta t} = S_t \exp\left( (r - \frac{1}{2}\sigma^2)\Delta t + \sigma \sqrt{\Delta t} \, \epsilon \right), \quad \epsilon \sim \mathcal{N}(0,1)$$
  2. 计算每条路径到期收益 $ \text{Payoff}_i $
  3. 估算价格：
     
     $$V \approx e^{-r(T - t)} \cdot \frac{1}{N} \sum_{i=1}^N \text{Payoff}_i$$
• 优点：极其灵活，适用于路径依赖期权（如亚式、回望、障碍期权）。
• 缺点：
  • 无法直接处理美式期权（因需最优停止决策）；
  • 收敛速度慢（误差 $ \propto 1/\sqrt{N} $）, 需大量模拟路径以保证精度。

本·格雷厄姆

1. 股票的本质是公司所有权：股票不是短期交易的筹码，而是公司所有权的法定证明。投资的根本目的，是在经济持续增长的过程中保持和增长自身的“购买力”。
2. 正确利用“市场先生”：市场是由追求短期获利的人组成的，情绪化且神经质。它提供的价格往往大幅偏离真实价值。对价值投资者而言，市场提供的是“买卖的服务”，而不是“价值的指导”。
3. 坚守“安全边际”：因为未来不可预测，投资者必须以足够低的价格买入。充足的安全边际不仅能抵御风险，还能让投资者在漫长的熊市中保持安心，坚持长期持有。

巴菲特与芒格

1. 投资优质公司并坚守“能力圈”：长期的超额回报来自于优秀公司持续创造的内在价值。投资者必须明确自己的“能力圈”边界，只投资自己能真正理解的、资本回报率高于平均水平的优质公司，并长期持有。

芒格

1. “在有鱼的地方钓鱼”（强调选择与独特优势）：投资者不需要搞懂所有宏观经济或研究所有公司，关键是找到那个“有鱼的湖”——即竞争不充分、存在错误定价且自己深度了解的领域。通过建立独特的认知优势（如钓鱼向导 Lerer 的独家知识），避开过度竞争，获取丰厚回报。

李录

1. 财富的本质与时代红利：基于对文明范式变化的总结，财富的本质是“经济体中的购买力占比”。因此，价值投资的终极目标是：在最具活力的经济体中，持有最具活力的公司的股份，从而顺应时代趋势，实现财富的长期保持与增长。

我们来回顾一下价值投资的起源。价值投资正
是诞生于整个经济和宏观环境极度动荡、充满困惑的时期。最早完整阐述价值投资理念的
人是本·格雷厄姆（Ben Graham），也就是巴菲特的老师。那么格雷厄姆是什么时候开始
理解和实践价值投资的？他最早从 1926 年开始投资，前三年中，他与很多投资者一样，
经历了“咆哮的二十年代”（Roaring Twenties），期间也做了很多投机操作。然而，
1929 至 1932 年的大萧条时期，他的投资合伙企业的帐面价值损失高达 70%。痛定思痛，
他才开始真正实践价值投资，并于 1932-1935 年成功弥补了之前的亏损。1936 年，他创
立了一个新的封闭式基金（closed fund），运营至 1956 年结束，二十年间实现了非凡的
回报。期间，他于 1949 年出版了《聪明的投资者》，首次完整地阐述了价值投资的最重
要的三个理念

价值投资的奠基人格雷厄姆，正是在宏观经济面临巨大挑战时发现了价值投资的方
法论。他在那个时代所经历的比我们今天面对的挑战要困难得多。当时，美国的失业率高
达 25%，整个经济体萎缩了约三分之一到一半，具体比例取决于不同的评估方法。人们普
遍感到前途渺茫，世界仿佛快走向末日。等他终于回本，开始新的基金时，世界又迅速陷
入一场法西斯发动的全球性战争，这场战争最终导致上亿人死亡，数亿人受伤，世界上大
部分的工业体系被彻底摧毁。在这样的时代背景下，他创造了卓越的投资业绩。

另一位对价值投资的理论和实践做出巨大贡献的是经济学家凯恩斯。很多人都熟悉
凯恩斯的宏观经济理论，以及他对战后布雷顿森林体系和全球金融体系设计的贡献，但是
很少有人知道凯恩斯也是一位优秀的价值投资人。从 1921 年到他 1946 年离世，凯恩斯管
理着剑桥大学最重要的国王学院的捐赠基金，25 年间积累了卓越的投资业绩。凯恩斯早
期也曾有过很多投机，但是在不断的经验教训中，他开始总结出价值投资的核心理念。凯
恩斯与格雷厄姆的事业轨迹高度重合，都经历了“咆哮的二十年代”、大萧条和世界大
战。不过，与格雷厄姆不同的是，凯恩斯所在的英国在二战期间处于战火前线，而格雷厄
姆所在的美国则处于战争的大后方，因此凯恩斯在这样的背景下创造出的业绩更具意义。

还有一位约翰·邓普顿（John Templeton），他对价值投资以及把价值投资推广到
其他国家起到了重要作用。1939 年，正值战争期间，许多美国股票跌破一美元，邓普顿
秉持“便宜就是硬道理”的原则，将当时在美国股市中所有低于一美元的股票各买 100 股，
共投入一万美元。四年后，当他卖出时，104 只股票中有 100 只都取得了大幅上涨。1954
年，他创建了邓普顿基金（Templeton Fund），开始将价值投资理念推广到很多其他国家。
1992，这只基金经过 38 年的发展，历经市场的各种变化，取得了十几倍的收益

我（李录）在 1997 年创建了喜马拉雅基金。在此之前，我在 1993 年买了第一只股票，就是
从买便宜的公司开始。在投资便宜公司的过程中，逐步建立起自己的能力圈，并从寻找便
宜的公司慢慢过渡到寻找优质且便宜的公司。1997 年，基金成立之初，我就经历了亚洲
金融危机。过去这几年中国市场经历了资本与资产的大幅回撤，许多人都遭遇了房地产、
股票和其他证券价格的下跌。然而这轮下跌的程度与当年的亚洲金融危机相比，依然不可
同日而语。1997-1998 年亚洲金融危机期间，亚洲主要国家的市场普遍下跌 70% 以上，最
惨烈的甚至跌了 90% 以上。我们的基金也同样面临了巨大的挑战，出现了比较大的波动，
但那几年的业绩总和恰恰是我们收益很高的一段时期，那时的市场可谓遍地黄金。

举个例子，在农业文明时代，财富就是土地和人口。那么，今天土地还是不是财
富？回顾整个世界历史，尤其是在欧洲，封建体系持续了数百上千年，很多国家的封建制
度都因革命而瓦解了，除了一个例外——英国。这几百年来，英国没有发生大的革命，许
多原本拥有土地的贵族至今还保留着很多土地和宏伟的城堡。在过去，他们是最富有的人。
然而，今天这些贵族还富有吗？答案是否定的。大多数仅拥有土地和城堡的贵族已经不再
富有，甚至变得相对贫穷。只有少数贵族依然富裕，是因为他们有其他投资，而不是仅仅
依赖原有的土地和城堡。
为什么会这样？因为维持土地和城堡需要大量人力。一个大型城堡动辄需要几十甚
至上百的佣人来维持运转。然而，过去几百年间，人的价值发生了巨大的变化，导致今天
的贵族已无法负担如此多的佣人。同样地，土地也需要雇人耕作，人的价值增加了，土地
本身的产出增加相对比较少，乡间房子价值的增加也很少，维修成本反而很高。所以，这
些没有转化成工业商业用途的土地城堡成了贵族们的负担，而没有成为财产。今天，仍能
维持土地和城堡的英国贵族，大多是通过将城堡开放给公众参观来获取收入。例如，将城
堡当作公园开放，收取每人五英镑的门票费用。我相信在座有很多人到英国旅游，参观过
类似的城堡，甚至还有人租用城堡举办生日宴会、公司晚会、婚礼等等。这是一个土地和
人口的相对价值变化的例子。

https://cdn.prod.website-files.com/5ef3c7300432b40ed865991a/67a4f8e8160103c8a74017a7_%E5%85%A8%E7%90%83%E4%BB%B7%E5%80%BC%E6%8A%95%E8%B5%84%E4%B8%8E%E6%97%B6%E4%BB%A32024%E5%B9%B412%E6%9C%88.pdf

真得吃炖菜了，炖菜…适合这种温度。之前在家过了个生日，在一个小馆子里吃了一顿饭。我最初觉得那个饭馆估计不太好吃，就连材料也是临时买的！不过后来端上桌后有点惊艳的，是炖的牛尾。该说不说还挺好吃，配上锅盔，汤是挺油的，牛尾富含胶质。蘸汤吃很香。但是牛尾终归是骨头多，要啃肉需要一番功夫。

天气冷了，开始想吃一些高热量的东西。感觉都能穿羽绒服了…怕感冒，这种天气不注意就容易得。现在还好，等供暖之后，湿度低，咽喉容易受到攻击。

谈恋爱还是要遵循快速失败原则，失败点在于逆向选择问题没有解决，遇到了柠檬类型

https://www.ftchinese.com/story/001110683

不多说废话，我觉得想到啥就问 ai，也挺解闷的。ai 可以回答从专业的严肃问题，到各种异想天开。你想什么就问什么，解决了一部分的孤独。

Google earth 里把 border 取消显示：

南京是南直隶的省会。傻逼清朝非要拆分。

不知道为什么每次点击聊天入口就会需要登录，即使右上角一直显示着头像（即正常情况下的登录状态）

晚上吃了一顿面，又吃了俩小面包。一顿饭没有纤维，再加上晚上不怎么动，感觉有些积食，胃在抗议。到了零点的时候，感觉终于有气体排出，这时觉得舒服多了。另外一个问题是大蒜，吃了两瓣蒜后，嗓子需要多喝水，然后过几个小时后会舒服点，刚开始还是有些难受，类似于咽炎的感受。不管怎样的一顿饭，还是有些纤维会好点，不然吃得多也容易不消化，尤其是非发酵类的面食。不管怎样，还是要多吃纤维啊。明天的火车就靠面包，小蛋糕和小饼干来对付了，我会感觉到牙齿上残留糖分附着

确实，bug 还在

大而不能倒的道德风险解决

这份金融稳定理事会 (FSB) 的报告评估了 2008 年金融危机后针对“大而不能倒”(TBTF) 系统重要性银行 (SIBs) 的改革效果。总体结论是：改革有效降低了系统性风险和道德风险，为社会带来了净收益，但落地执行中仍存显著漏洞。

改革取得的核心成效

• 市场纪律与资金成本：SIBs 的融资成本优势自 2012 年以来显著下降，表明投资者已将“银行倒闭风险”计入定价，不再盲目相信政府会兜底。此外，信用评级机构已取消对那些拥有完善危机处置框架地区银行的“主权支持假设”。

• 系统韧性与信贷供应：SIBs 目前持有比 2008 年危机前更高质量和更大规模的资本与流动性缓冲。尽管 SIBs 在本土市场的份额有所下降，但整体信贷供应与 GDP 的比例保持稳定，其他非银行金融机构填补了信贷空白。这种韧性在应对 COVID-19 疫情初期的经济冲击时得到了有力验证。

• 处置机制与损失吸收：全球系统重要性银行 (G-SIBs) 已基本满足总损失吸收能力 (TLAC) 的严格要求，确保在陷入危机时，有足够的内部债务和股权资源来吸收损失，而无需动用纳税人的资金。

现存的漏洞与潜在风险

• 政府救助 (Bailout) 依然存在：尽管有了新的法律框架，近年来一些陷入困境的中小型银行依然获得了公共资金的救助，这说明“政府干预”在实际政治与经济权衡中仍难以完全避免。

• 可处置性障碍 (Resolvability Obstacles)：真正有序处置一家大型银行仍面临诸多实操难题，包括内部 TLAC 在跨国集团间的合理分配、危机时银行资产的快速准确估值，以及确保其在破产重组期间仍能持续接入金融市场基础设施 (FMIs)。

• 数据透明度缺失：目前缺乏关于“谁持有 TLAC 债务”的全球一致数据。如果实施“内部纾困”(Bail-in)，监管机构将很难准确预估这些债券持有人受损是否会引发金融体系的连环传染。

• 组织结构依然臃肿：G-SIBs 依然极为庞大复杂，平均每家拥有超过 1200 家子公司，并遍布 40 多个司法管辖区，给跨境监管协调和危机处置带来极大挑战。

虽然诸如资本附加费、强化监管和 TLAC 等核心架构已大幅提升了全球银行业的安全性，但这些机制尚未在全面的系统性银行业危机中经受过极限测试。各国监管机构未来的重点必须转向填补执行层面的漏洞、解决跨国数据盲区，并消除残余的救助惯性，以确保这些安全阀在真正的风暴来临时能够如期运作。

报告中引入了多种基于市场价格的工具（或指标）来衡量银行的隐性补贴、市场预期以及系统性风险。

核心市场工具及其价格分析方法

• 信用违约互换 (CDS) 利差：CDS 相当于为债务违约购买的保险。通过对比系统重要性银行 (SIBs) 与其他普通银行的 CDS 利差，可以估算 SIBs 享受的融资成本优势（即隐性政府补贴）。此外，通过对比同一银行集团内“控股公司 (Holdco)”与“运营子公司 (Opco)”的 CDS 利差，如果控股公司的 CDS 利差明显高于子公司，说明市场预计在危机中控股公司的债权人将率先承担损失，而子公司能继续运营。

• 债券收益率与纾困风险溢价 (Bail-in Risk Premium)：分析师会对比符合“总损失吸收能力 (TLAC)”标准的债券与不具备该功能债券的收益率差异。如果 TLAC 合格债券的收益率（利差）更高，且高风险银行的利差更大，说明投资者已经将“银行倒闭时被强制吸收损失”的风险计入价格，并要求相应的风险溢价。

• 股票价格与或有索取权模型 (Contingent Claims Model)：该方法利用股票价格推算出理论上的 CDS 价格，并将其与市场上实际交易的 CDS 价格进行对比。由于股票价格不包含政府救助带来的好处，这两者之间的差值即可被视为市场对“政府救助（Bailout）概率”的定价。

• 预期违约频率 (EDF) 与资产组合因子定价：通过分析银行股票回报率相对于大盘的波动，以及计算预期违约频率，可以衡量投资者对银行风险敏感度的变化。

市场化系统性风险评估指标

• ACoVaR：完全基于市场数据，用于衡量当某一家金融机构陷入困境时，整个金融体系所面临的条件压力（即传染风险）。

• SRISK：结合了市值和杠杆率数据，用于衡量在发生系统性风险事件时，某家特定金融机构预期的资本短缺规模。

如何通过这些工具评估金融体系的风险

当上述市场工具显示 SIBs 的融资成本优势缩小、TLAC 债券收益率上升、以及控股公司 CDS 利差走阔时，意味着投资者真正相信了“大而不能倒”改革的效力——即在银行面临破产时，将由债权人承担损失而非纳税人买单。这种市场预期的转变强化了市场纪律 (Market Discipline)：因为资金成本与风险直接挂钩，银行会被迫减少过度冒险行为，从而从源头上降低了道德风险和系统性风险。同时，如果 ACoVaR 和 SRISK 等指标在长期内保持稳定或呈下降趋势，则从宏观层面证明了金融体系吸收冲击的韧性正在增强。

白芝浩原则

《经济学人》传奇总编 Walter Bagehot（1860-1877 在任）在名著《伦巴第街》中提出了一个原则：在金融危机时，银行应当慷慨放贷，但只放给经营稳健、拥有优质抵押品的公司，而且要以足够高的、能吓走非急用钱者的利率来放贷。央行充当“最后贷款人”的概念也是他提出的。

点击 chat 后出现登录页面 成功登录后点击具体群聊为什么还会出现登录页面🤯
发自皮革鱼

@小lin说

日元逼近 40 年低位：从利差交易到财政风险，美日联合干预的深层逻辑

日元汇率近期再次逼近 40 年来的低位，市场目光聚焦于“美国罕见出手干预”这一表象。然而，透过汇率波动的迷雾，这轮行情的本质已发生深刻变化：过去几年主导日元贬值的“美日利差”逻辑正在失效，取而代之的是对日本财政信用的重新定价。这不仅是一场汇率保卫战，更是一次涉及全球美元流动性、日本财政可持续性以及美国国债市场稳定的三角博弈。

利差不再解释一切

理解这轮日元下跌，必须首先回顾过去几年最有效的解释框架。2022 年以来，美联储激进加息与日本维持极度宽松货币政策形成了巨大的收益率鸿沟。这种显著的利差天然催生了经典的套息交易：借入低息日元，购买高收益美元资产。在这一阶段，美元兑日元汇率与美日 10 年期国债收益率之差高度同步，只要利差存在且预期持续，做空日元便拥有稳定的正向持有收益。

然而，近期数据揭示了一个关键转折：随着美日利差开始收窄，理论上日元应获得支撑，但现实是日元仍在持续走弱。这表明汇率定价中引入了新的主导变量——日本国内 2 年期与 10 年期国债之间的收益率差（期限利差）开始表现出更强的解释力。

短期国债收益率主要受央行政策利率影响，而长期国债收益率则包含了通胀预期、财政供给压力以及主权信用风险。当政府持续扩大财政支出并增加长期国债发行时，投资者会要求更高的风险补偿，导致长端收益率上行速度快于短端。此时，期限利差的扩大不再单纯反映经济复苏或未来加息预期，而是嵌入了日益高涨的财政风险溢价。

这就解释了为何会出现“日债跌、日元跌”的反常现象：投资者抛售长期日本国债推高收益率，并非因为日本经济强劲，而是出于对财政前景的担忧；同时，这种信心缺失也蔓延至外汇市场，导致日元被同步抛售。此时的“高收益率”并非资产吸引力的体现，而是风险溢价的信号。

财政扩张：高收益->高风险

这一交易结构变化的政策背景，在于日本政府采取了更为积极的财政路线，包括大规模刺激计划和减税安排。在低利率、低通胀时代，巨额债务的融资成本极低，财政扩张的副作用被掩盖。但当利率和通胀环境发生根本性逆转后，一边扩大支出、一边削减收入的财政组合，迫使市场重新审视日本政府未来的债务融资能力。

宏观市场中有一条铁律：债券收益率上升是否利好本币，取决于其上升的驱动力。 若源于经济增长改善和央行正常化，本币通常受益；若源于财政赤字恶化和供给压力，高收益率反而成为本币的利空。2022 年英国“迷你预算”危机便是典型案例，无资金支持的减税措施导致英债和英镑双双崩盘。

当前日本市场正呈现类似结构：卖出长期日债、卖出日元，同时买入日本股票。这一组合内在逻辑自洽：财政扩张推升名义增长，日元贬值改善出口企业以日元计价的利润，使得日股（尤其是大型出口企业）受益；而长期政府债券和本币则共同承担财政风险溢价。

货币政策的困境：加息难以治本

面对日元持续贬值，传统的应对手段是加息。提高政策利率可以缩小美日利差，降低套息交易吸引力，从而支撑日元。然而，日本央行面临多重约束：庞大的公共债务规模、长期适应低利率的经济结构，以及利率上升对居民按揭、企业融资和金融机构资产负债表的冲击。这意味着日本央行无法像其他经济体那样快速、大幅地加息。

更深层的问题在于，如果日元贬值的核心矛盾已从“利率过低”转向“财政信用风险”，那么单纯依靠货币紧缩甚至可能产生副作用。加息虽然能短期支持汇率，但会大幅增加政府债务的滚续成本。若市场因此进一步质疑财政可持续性，长端国债收益率可能继续攀升，最终抵消加息对汇率的正面效应。

要从根源上改善这一结构，需要财政政策本身做出改变，如削减赤字、控制长期支出或提供可信的中期整顿路径。但在政府不愿迅速逆转财政扩张方向的背景下，政策选择空间被极大压缩，最终只能频繁诉诸外汇干预。既然无法通过财政收缩恢复信用，直接入场买入日元便成了最直接、最易执行的工具。

干预：改变波动而非趋势

外汇干预的逻辑简单直接：政府卖出手中的外汇资产并买入日元，人为创造买盘。由于投机资金通常带有杠杆，官方大规模反向交易往往能迫使短期空头平仓，引发汇率剧烈反弹。

然而，外汇市场的体量远超单个政府可长期投入的资金规模。即使美日联合干预曾让日元在一周内明显上涨，随后仍回落至原位。这是因为决定日元长期方向的利差和财政风险并未消失。数十亿甚至数百亿美元的官方资金可以影响短期价格，却难以永久改变市场趋势。

干预的真正目的不在于彻底逆转趋势，而在于改变交易行为。通过不定期、突袭式的干预，政府提高了做空日元的尾部风险。假设基金原本使用 10 倍杠杆做空日元，一旦面临 3%-5% 的逆向波动，巨额损失将迫使其去杠杆。因此，干预虽不能扭转长期贬值方向，却能显著降低空头杠杆、增加波动率、延缓贬值速度。其核心信号意义在于告诉投机资本：“政府仍在场”，从而遏制市场无限度加杠杆做空的行为。

美国介入的动机：保卫美债市场

美国打破长期以来对外汇干预的谨慎态度，其核心驱动力并非单纯的盟友情谊，而是美国自身的国债市场利益。

日本政府持有巨额美元外汇储备，其中相当部分以美国国债形式存在。若日本为干预日元而需筹集美元现金，最直接的方式便是出售美债。当日元贬值严重到迫使日本持续大规模干预时，日本汇率问题便外溢为美国国债需求问题。大量抛售美债将推高美国长期国债收益率，增加美国财政融资成本。

因此，美国介入的直接利益在于降低日本抛售美债换取美元的必要性。在正常时期，日本持有美债既支持了美国财政融资，又获得了安全储备资产，两者兼容。但在日元危机下，这套结构产生冲突：日本救货币需变现储备，而这恰恰冲击美国债市。美国财政部帮助日本获得美元流动性，实质上是在维护美国国债市场的稳定。

FIMA 回购工具：结构性解决方案

相较于直接干预，美联储的外国官方客户回购便利（FIMA Repo Facility）在金融结构上更具深远意义。该工具允许外国央行将持有的美国国债作为抵押物交给美联储，从而获得短期美元流动性，到期后可滚动续作。

这本质上是一种“央行版抵押贷款”，解决了日本“资产优质但缺现金”的困境。日本无需在二级市场直接出售美债，避免了价格冲击，同时获得了干预所需的美元弹药。这是一种典型的双赢安排：日本获得流动性，美国避免重要海外债权人抛售美债。

更重要的是，这一机制具有强大的政策威慑力。即便未被大规模使用，其存在本身即向市场传递信号：日本的干预能力不完全受限于手头现金，它可以在不出售美债的情况下获得更多美元。这种预期足以促使部分高杠杆空头提前平仓。因此，直接干预解决的是市场价格，FIMA 解决的是干预融资能力，后者才是更具结构性意义的政策变化。

此外，美国也不希望日元无限贬值。过弱的日元将削弱美国出口竞争力，加剧贸易失衡，并可能触发全球套息交易的大规模平仓，冲击全球金融市场稳定。美方追求的状态更接近于“稳定”，而非特定的汇率水平。

并非 广场协议 2.0

尽管表面相似，本轮行动与 1985 年《广场协议》有着本质区别。《广场协议》的核心是美国为了解决自身美元严重高估、制造业竞争力下降的问题，主动联合主要经济体推动美元贬值。那是美国为了自身宏观经济目标重塑全球汇率体系。

而当前，美国并未形成系统性压低美元的战略目标，日本汇率问题在美国政策议程中的优先级有限。美方行动旨在防止日本汇率危机外溢至美债和全球金融市场，属于局部市场稳定行动，而非全球货币秩序重构。加之当今全球私人资本规模、杠杆水平和衍生品体系已不可同日而语，依靠协调干预直接重塑汇率均衡的难度远高于 40 年前。因此，将其定义为“广场协议 2.0”并不准确。

结语

这场日元风波的底层逻辑，是日本财政信用、全球美元流动性和美债市场之间的三角博弈。日本政府受限于货币和财政约束，依赖外汇储备干预；而日本储备以美债为主，大规模干预可能冲击美债市场。美国介入旨在维护这一资产负债表结构的稳定：让日本继续持有美债，同时获得美元流动性以防止日元失序。

然而，这种安排只能解决流动性问题，无法解决基本面问题。FIMA 工具和外汇干预可以阻止日元短期暴跌，却无法消除投资者持续卖日元的根本动力。只要美日利差较大、日本财政风险溢价存在、且缺乏可信的中期财政整顿路径，官方干预更多是在控制波动速度，而非创造新的长期均衡。

因此，看待日元不应再局限于“美日利差”的套息交易视角。这一轮真正值得警惕的变化，是市场开始将日本财政信用计入日元价格；而美国的介入，更是因为其汇率防御已触及美国国债市场的底线。在这个三角关系发生根本改变之前，任何干预都更像是风暴中的锚，而非改变航向的舵。

转载 @fin

AI 半导体终局推演 2026（III）

这一轮 AI 浪潮中，市场最核心的焦虑集中在四个问题上：为什么 AI 基建周期比互联网更长？Coding Agent 之后下一个增长点在哪？巨额 Capex 和负 FCF 是否意味着泡沫？开源模型最终会如何冲击闭源生态？这些问题表面独立，背后其实都指向同一个核心变量：Token 需求到底还能增长多久。 只有理解了 Token 需求的生成机制与天花板，才能看清这轮半导体超级周期的真实面貌。

双 S 曲线接力：为什么 AI 基建周期比互联网更长？

理解 AI 基建的持久性，首先要复盘互联网时代的基础设施增长逻辑。互联网革命时期，硬件需求主要由单一变量推动，即“用户渗透率”。当一个人开始上网，他贡献的基础设施收入基本固定（如每月 50 元网费），不会因为浏览网页从 10 个增加到 100 个而支付 10 倍费用。因此，互联网硬件需求的爆发期严格对应渗透率从 10% 向 50% 攀升的阶段，2000 年泡沫破裂时美国互联网渗透率恰好在 50% 左右，随后增速自然放缓。智能手机亦然，受限于大规模制造的成本摊薄规律，ASP 无法无限上涨，渗透率饱和后销量即见顶。

AI 的本质区别在于，它拥有两个独立的增长维度：用户数量 × 人均 Token 使用量。这两个变量最终都可以折算为 Token 需求，使得 AI 基础设施的潜在上限远超互联网。目前，AI 用户渗透率已接近 50%，第一条 S 型曲线进入中后段，增长引擎正切换至第二条曲线——人均 Token 消耗。2026 年美国企业内部 AI Spending 中位数仅每人每月 12 美元，而长期看这一数字有望达到白领工资的 10%（约 1000 美元/月），中间存在近两个数量级的增长空间。这意味着即便用户数不再高速增长，仅靠存量用户的人均消耗提升，足以支撑基建需求继续高增。这种“双 S 曲线接力”是历史上极为罕见的现象，也是本轮半导体周期可能演变为超长超级周期的根本原因。

此外，AI 的边际成本结构与互联网截然不同。互联网软件复制分发的边际成本趋近于零，而 AI 每一次 Token 生成都需要真实算力消耗，尤其是推理模型和 Agent 长时间运行，边际基础设施成本比互联网高出一个数量级。互联网公司过去关心“流量×转化率”，AI 公司则必须关心“每个 Token 的毛利”。只要 Token 使用量在增长，硬件需求就会同步刚性增长，这进一步拉长了基建周期。当然，指数增长终将结束，但因为多了一条人均 Token 增长曲线，AI 触及天花板的时间点将显著晚于互联网时代。

广义 Coding：下一个 ARR 增长点

随着 Coding Agent 在 2026 年中增速放缓，市场急于寻找下一个推动模型 ARR 增长的场景。我的判断是：下一阶段仍然是 Coding，但不是狭义的程序员写代码，而是“广义 Coding”。 世界正在持续数字化，当模型具备 Coding 能力后，越来越多知识工作被转化为“观察→分析→执行→验证”的类编程过程。用户在前端看到的是编辑 Excel、处理法律文档或财务操作，但后台 Agent 本质上是在 Linux Sandbox 中执行代码、调用工具并验证结果。目前广义 Coding 任务已占模型 ARR 收入的 60%～70%，其中狭义程序员 Coding 仅占 40%，其余 20%～30% 来自金融建模、药物仿真、半导体架构探索等非码农行业，它们只是被 Agent 转换成了 Coding 执行结构。

程序员之所以最先跑通 Agent 闭环，是因为 Coding 天然具备“执行 - 验证”的完整反馈循环，Token 消耗量比普通 Chat 高一个数量级。未来，Co-work / Computer Use 将成为接棒形态，让 Agent 直接参与日常工作而非仅在对话框问答。OpenAI 的数据已印证这一趋势：截至 2026 年 6 月，Codex 占其与 ChatGPT 合计输出 Token 的 64%，且增长最快的部门并非工程（5 倍），而是法律（108 倍）、销售招聘（41 倍）和营销（26 倍）。Anthropic 的收入结构同样显示，狭义 Coding 仅占 40%，金融保险超 20%，法律、制药、零售等均达 10% 量级。过去的“Software is eating the world”正在升级为“Coding is eating the world”，Agent 以最熟悉的 Coding 语言向所有知识工作扩散。

当前 Agent Coding 的瓶颈已从“能不能做”转向工程优化与组织适配。真正的限制因素不再是模型能力，而是企业工作流迁移的速度、Tool Integration 的完善度以及员工学习曲线。同时需警惕 Amdahl’s Law 的现实约束：若流程中有一半环节（如临床试验）无法被 AI 加速，整体效率提升上限仅为 2 倍。因此更现实的路径不是无限加速单一流程，而是利用 AI 并行探索更多方向，将瓶颈从“决策能力”转移至“现实验证速度”。Anthropic 6-7 月的增速放缓主要源于算力短缺、防蒸馏整治及竞品抢份额，而非需求见顶；只要企业营收能支撑 AI Budget，Token 需求的边际收益仍明显为正。

Capex 泡沫：Unit Economy 成立，但需警惕时间错配与必然的 Overbuild

市场最担心的是巨额 Capex、举债和负 FCF 是否算得过来。判断的关键在于区分互联网与 AI 时代的差异：互联网时代基建出资方未必是最大受益者，而 AI 时代 OpenAI 和 Anthropic 既是出资方也是直接受益者。从 Unit Economy 看，截至 2026 年 6 月底 Anthropic 约 2GW 有效算力对应 62B 美元 ARR，按 1GW 建设成本 50B、6 年摊销计算，年化成本约 10B，收入是成本的 3 倍，推理业务 ROIC 可达 60%。若仅计 Inference，1GW 对应近 50B 收入，单位经济模型完全成立。展望 2027 年，两家公司规划算力增至 20-24GW，只要 ARR 同步增长 1-1.5 倍（下半年月增 10% 即可达成），算力与收入仍能匹配。即便保守假设 2028 年 ARR 增 80%、2029-2030 年 CAGR 40%，到 2030 年底 100GW 算力也并非不可解释。因此，至少 2027-2028 年的 Capex 目前没有明显泡沫迹象。

举债扩产本质是押注未来的赌博，但关键在于赔率。在高 ROIC 且需求大概率持续增长的前提下，踏空风险远大于过度投资风险。即使融资成本升至 8% 以上，只要 2027-2028 年回报维持现状，债务风险仍可被覆盖。需要注意的是，大量 AI 算力并不直接产生 Token 收入，而是用于 Meta/Google 的传统 ML（搜索/广告/推荐）、内部训练等，这部分属于成熟业务的研发成本，不能用 ChatGPT 订阅逻辑去衡量。事实上，OpenAI+Anthropic 正吃掉越来越多新增算力：2025 年占新增 GW 约 25%，2027 年因电力限制可能占比近半。这意味着能用 Token 收入解释的算力比例在上升，总体经济账反而更容易算清。此外，Coding Agent 爆发还会带动 CPU 等传统计算需求，因为“Token=判断”增长后，“CPU=执行验证”必然同步增长。

然而，AI 基础设施最终一定会 Overbuild。当前闭源推理毛利率 70%-85%，开源 Token Factory 也有 60%+，GPU 短租毛利亦超 60%，这种暴利必然吸引大量资本涌入 Neocloud。由于数据中心建设存在 1-2 年时滞，产能集中上线后过剩几乎不可避免。但 Overbuild 未必利空头部模型公司：算力供给过剩会导致基础设施环节毛利率下降，利润反而向掌握模型和用户入口的头部集中。SpaceX 凭借其执行力和成本优势，也可能成为未来 Overbuild 的重要变量。真正的风险不在于过剩本身，而在于收入与支出的时间错配——建设需提前花钱，需求何时兑现却不确定，这种金融风险已大到可能影响国债发行。但只要现有 Coding/Agent 扩散趋势延续，2027-2028 年的投资仍具合理性。

开源 vs 闭源：分层竞争

开源模型一定会冲击闭源，但市场高估了短期冲击速度。下一代模型能力取决于算力 Scale、数据 Scale 和自迭代（RSI）三大壁垒。虽然数据购买投入（OpenAI+Anthropic 今年超 100 亿美元）和 GPU 禁令绕过使前两者差距缩小，但自迭代形成的正反馈最难追赶：上一代模型越强，下一代越容易变强，这使得开源与闭源的能力差距可能长期维持在 6 个月左右。

从真实 ARR 看，闭源仍占绝对主导。2026 年 7 月底 Anthropic+OpenAI 合计 ARR 近 120B 美元，而全球开源相关收入仅约 10B 美元（北美最多 5B），占比仅 3%。OpenRouter/Vercel 上开源 Token 占比升至 62% 存在严重样本偏差，因其主要反映开发者和小微企业行为，大量企业级闭源 Token 未经过这些平台。AWS Bedrock（ARR 约 14B）中 Anthropic 模型占 80%，其上开源收入仅 1.5-2B 美元。美国开源 Token Factory（Fireworks/Together/Baseten）虽增长快，但受限于融资规模（1B 美元级连 0.5GW 都租不到），扩张瓶颈是算力而非需求；中国开源虽增长更快且有 30 家 Token Factory 红海竞争，但同样缺卡，且出海面临合规与信任问题。Nvidia 收购 Hugging Face 正是为了通过繁荣开源生态创造更多 GPU 需求。

闭源模型也不会坐以待毙，其防守手段是主动降价填满低价市场，类似高通 Snapdragon 4 系策略。Luna 5.6 直接降价 80%，既维持旗舰技术领先，又不给低成本对手留利润空间。历史证明，联发科体验追上高通并未消灭高端芯片市场，Value Tier 不会摧毁 Flagship Tier。便宜模型会吃掉“够用就行”的任务，但最强模型仍服务最复杂、最高价值、最在乎可靠性的客户。开源会改变利润分配、压低价格，但不会改变 AI 产业主线。至于“Token Maxxing 结束拖累 ARR”的担忧，目前硅谷大厂人均额度 1-2 万美元/月，95% 员工用不完，中位数 Spending 仍极低，说明多数人尚未学会将 Token 转化为生产力，增长空间依然巨大。

结语

AI 基建前景之所以扑朔迷离，是因为产业链与资本市场站位不同：近处者见“算力不够”，远处者见“建得太多”。两者皆真实，只是时间尺度不同。过去分析互联网可看用户数、宽带渗透率等显性指标，而今算力被直接转化为判断、认知与行动（Token），需求端可见度极低，没有任何历史样本可参照。今天争论的本质，往往不是数字对错，而是该用几年还是十几年作为观察单位。

当前无法上传图片，报错 Unauthorized，同样，因为权限无法查看我的草稿，无法添加书签，发帖为匿名，无法 log out

1

把生活成本的下限给降低到一个更低的值，这也符合低欲望社会的发展趋势。躺平，先从食物开始，让身体对蛋白质的需求与昂贵的肉类价格解耦。不过毕竟还是一种异想天开