diff --git "a/docs/\346\235\202\350\260\210/\345\220\216\346\227\245\350\260\210/2024\345\271\264\347\247\213\346\213\233\350\256\260\345\275\225.md" "b/docs/\346\235\202\350\260\210/\345\220\216\346\227\245\350\260\210/2024\345\271\264\347\247\213\346\213\233\350\256\260\345\275\225.md"
new file mode 100644
index 0000000..9b92217
--- /dev/null
+++ "b/docs/\346\235\202\350\260\210/\345\220\216\346\227\245\350\260\210/2024\345\271\264\347\247\213\346\213\233\350\256\260\345\275\225.md"
@@ -0,0 +1,16 @@
+---
+title: 2024年秋招记录
+date: 2024-12-02 19:03:00
+updated:
+categories:
+- 其他
+tags:
+- 研究生
+keywords:
+- 研究生
+description: 秋招，寄！
+cover:
+top_img:
+---
+
+彻底完了，就这个大环境，已经完全找不到什么理想的工作了，明明去年还能看看什么好工作，现在就只能看自己能做的了，也没感觉自己哪里菜了，就是大环境整体都在收缩，企业也不好过，唉，就先这样吧……
diff --git "a/docs/\346\235\202\350\260\210/\345\257\271\344\272\216\345\244\247\346\250\241\345\236\213\347\273\230\345\210\266UML\345\233\276\347\232\204\350\260\203\347\240\224.md" "b/docs/\346\235\202\350\260\210/\345\257\271\344\272\216\345\244\247\346\250\241\345\236\213\347\273\230\345\210\266UML\345\233\276\347\232\204\350\260\203\347\240\224.md"
new file mode 100644
index 0000000..e3e2d85
--- /dev/null
+++ "b/docs/\346\235\202\350\260\210/\345\257\271\344\272\216\345\244\247\346\250\241\345\236\213\347\273\230\345\210\266UML\345\233\276\347\232\204\350\260\203\347\240\224.md"
@@ -0,0 +1,174 @@
+## 对于大模型绘制UML图的调研
+
+在2024年年底，我简单考察了市面上一些大模型对UML图绘制的能力。
+
+## 提示词
+
+提示词都是一样的：`画一个应用程序调用第三方支付接口的流程图`
+
+## 调研的大模型
+
+- [般若](https://banruoai.cn/)
+- [豆包](https://www.doubao.com/chat/)
+- [KIMI](https://kimi.moonshot.cn/)
+- [通义千问](https://tongyi.aliyun.com/)
+- [智谱清言](https://chatglm.cn/)
+- [ChatGPT](https://chatgpt.com/)
+
+### 般若
+
+这是**时序图**吧？我要的是**流程图**啊。不过般若能直接浏览，这挺好的。
+
+
+
+```mermaid
+sequenceDiagram
+ participant 用户
+ participant 应用程序
+ participant 第三方支付接口
+
+ 用户->>应用程序: 发起支付请求
+ 应用程序->>第三方支付接口: 调用支付接口
+ 第三方支付接口-->>应用程序: 返回支付页面URL
+ 应用程序->>用户: 跳转到支付页面
+ 用户->>第三方支付接口: 在支付页面完成支付
+ 第三方支付接口-->>应用程序: 支付结果通知
+ 应用程序->>用户: 显示支付结果
+```
+
+### 豆包
+
+比较符合，不过缺点就是不能预览。
+
+
+
+```mermaid
+graph TD;
+ A[用户在应用程序中发起支付请求] --> B[应用程序将支付请求信息发送给第三方支付接口];
+ B --> C[第三方支付接口验证请求信息合法性];
+ C -->|信息合法| D[第三方支付平台生成支付订单并跳转至支付页面（如收银台页面）];
+ D --> E[用户在支付页面选择支付方式（如银行卡、微信支付、支付宝支付等）];
+ E --> F[用户完成支付操作（输入密码、指纹验证等）];
+ F --> G[第三方支付平台将支付请求发送给相应支付渠道（如银行、微信支付服务器、支付宝服务器等）];
+ G --> H[支付渠道处理支付请求并进行资金结算等操作];
+ H --> I[支付渠道将支付结果反馈给第三方支付平台];
+ I --> J[第三方支付平台将支付结果更新到订单状态并通知应用程序];
+ J --> K[应用程序根据支付结果更新界面展示给用户（如显示支付成功或失败信息）];
+ C -->|信息不合法| L[第三方支付接口返回错误信息给应用程序];
+ L --> M[应用程序展示错误提示给用户];
+```
+
+### KIMI
+
+KIMI也不错，比般若体验更好，可以切换markdown的预览和源码，不过这个图严格来说是时序图吧
+
+
+
+```mermaid
+sequenceDiagram
+ participant A as 应用程序
+ participant B as 第三方支付平台
+ participant C as 用户
+ participant D as 银行
+
+ A->>C: 请求支付
+ Note over C: 用户输入支付信息
+ C->>A: 确认支付
+ A->>B: 发送支付请求
+ Note over B: 第三方支付平台验证请求
+ B->>D: 请求银行扣款
+ D->>B: 扣款成功
+ B->>A: 支付成功通知
+ A->>C: 显示支付结果
+
+```
+
+这个流程图描述了以下步骤：
+
+1. 应用程序（A）向用户（C）请求支付。
+2. 用户输入支付信息并确认支付。
+3. 应用程序发送支付请求到第三方支付平台（B）。
+4. 第三方支付平台验证请求的合法性。
+5. 第三方支付平台请求银行（D）扣款。
+6. 银行扣款成功后，通知第三方支付平台。
+7. 第三方支付平台将支付成功的通知发送给应用程序。
+8. 应用程序将支付结果展示给用户。
+
+请注意，实际的支付流程可能会更加复杂，涉及到更多的安全验证、错误处理和异步通信等步骤。这个流程图仅作为一个基本的参考。
+
+### 通义千问
+
+好家伙，直接玩拟人的了……
+
+
+
+```
++-------------------+ +---------------------+ +---------------------+
+| 用户选择支付 | | 应用程序准备支付 | | 应用程序调用支付 |
+| 方式并提交订单 | ----> | 请求（创建支付 | ----> | 接口，传递支付 |
+| | | 订单，获取支付参数）| | 参数 |
++-------------------+ +---------------------+ +---------------------+
+ |
+ v
+ +---------------------+
+ | 第三方支付平台处理 |
+ | 支付请求，返回支付 |
+ | 结果或重定向到支付 |
+ | 网关页面 |
+ +---------------------+
+ |
+ v
+ +---------------------+
+ | 用户完成支付 |
+ | （通过网银、移动支 |
+ | 付应用等） |
+ +---------------------+
+ |
+ v
+ +---------------------+
+ | 第三方支付平台通知 |
+ | 应用程序支付结果 |
+ +---------------------+
+ |
+ v
+ +---------------------+
+ | 应用程序验证支付结 |
+ | 果，并更新订单状 |
+ | 态 |
+ +---------------------+
+ |
+ v
+ +---------------------+
+ | 应用程序向用户显示 |
+ | 支付成功/失败信息 |
+ +---------------------+
+```
+
+这个流程图可以分为以下几个关键步骤：
+
+1. 用户在应用程序中选择支付方式并提交订单。
+2. 应用程序准备好支付请求，这通常包括创建一个支付订单，并从第三方支付平台获取必要的支付参数。
+3. 应用程序调用第三方支付接口，传递支付参数给支付平台。
+4. 第三方支付平台处理支付请求，这可能涉及到重定向用户到银行或其他支付网关的页面。
+5. 用户通过选定的方式完成支付过程。
+6. 第三方支付平台将支付结果通知给应用程序，这通常是通过回调URL或服务器间的通知来完成。
+7. 应用程序验证支付结果，并根据支付结果更新订单状态。
+8. 应用程序向用户展示支付成功的确认信息或支付失败的消息。
+
+当您绘制这个流程图时，确保使用清晰的箭头来表示数据流和控制流的方向，并且为每个步骤提供简短的描述。如果您需要更详细的流程或者针对特定支付平台的流程图，请提供更多的上下文信息。
+
+### 智谱清言
+
+这位更是重量级……而且图中的单词都是乱码
+
+
+
+### ChatGPT
+
+OpenAI也干了，不过图中的单词起码看得清……
+
+
+
+## 总结
+
+[般若](https://banruoai.cn/)、[豆包](https://www.doubao.com/chat/)、[KIMI](https://kimi.moonshot.cn/)都挺不错的，看得出对程序员的使用场景有特殊优化，对markdown语法的支持也比较好，反而是之前市面上比较火的通义和CHatGPT直接拉了，这是没想到的。
\ No newline at end of file
diff --git "a/docs/\346\235\202\350\260\210/\350\256\276\350\256\241\346\250\241\345\274\217\347\232\204\350\215\274\346\257\222\344\275\223\347\216\260\345\234\250\345\223\252.md" "b/docs/\346\235\202\350\260\210/\350\256\276\350\256\241\346\250\241\345\274\217\347\232\204\350\215\274\346\257\222\344\275\223\347\216\260\345\234\250\345\223\252.md"
new file mode 100644
index 0000000..ac935de
--- /dev/null
+++ "b/docs/\346\235\202\350\260\210/\350\256\276\350\256\241\346\250\241\345\274\217\347\232\204\350\215\274\346\257\222\344\275\223\347\216\260\345\234\250\345\223\252.md"
@@ -0,0 +1,51 @@
+## 什么是过度设计？
+
+假如我有一个加减乘除的方法，我可以这样写：
+
+
+
+但如果我希望后续支持更多的计算模式，用了策略模式后，就变成了这样，代码变多了，逻辑也复杂了很多：
+
+
+
+## 设计模式的荼毒体现在哪？
+
+设计模式本身是软件工程中的最佳实践，它们提供了解决常见问题的模板或蓝图。然而，当不恰当地使用或过度使用时，设计模式可能会带来一些负面效果，这可以被称为“设计模式的荼毒”。以下是几个体现：
+
+1. **过度设计**：开发人员可能倾向于为每一个小问题都应用设计模式，即使这些问题并不需要如此复杂的解决方案。这会导致代码变得过于复杂，难以理解和维护。
+
+2. **性能损失**：某些设计模式，如装饰器模式或代理模式，可能会引入额外的层次和间接性，从而导致性能下降。
+
+3. **学习曲线**：对于新手开发者来说，理解设计模式可能是一个陡峭的学习过程。如果项目中广泛使用了各种设计模式，那么新加入团队的成员可能需要花费大量时间来熟悉这些模式，从而降低了开发效率。
+
+4. **僵化的设计**：过度依赖设计模式可能导致系统设计变得僵化，限制了系统的灵活性和适应性。例如，严格遵循单一职责原则（SRP）可能会导致过多的小类，使得系统难以管理和扩展。
+
+5. **不必要的复杂性**：有时候，简单直接的解决方案会更加有效。而设计模式可能会增加不必要的抽象层，使得代码更难阅读和调试。
+
+6. **模式误用**：不正确地选择或实现设计模式可能会导致代码质量下降。例如，错误地使用工厂模式（Factory Pattern）可能导致紧耦合，而不是预期的松耦合。
+
+7. **忽视上下文**：设计模式通常是在特定上下文中提出的解决方案。如果不考虑实际的应用场景盲目套用，可能会适得其反。
+
+8. **沟通障碍**：团队成员之间对设计模式的理解可能存在差异，这可能导致沟通上的误解，影响协作效率。
+
+## 简化思维：避免不必要的复杂性
+
+把复杂问题搞简单，而不是把简单问题搞复杂，以下是两个例子，在考虑编写代码时，我们往往会陷入一种最优思维，这其实是没必要的，这会加重我们的思维负担。
+
+- 数据结构和算法－>大数据量问题：在考虑排序算法时，应该从数据量的角度去选择排序算法，如果数据量较小，则越简单越好。
+- 设计模式或代码设计－>复杂代码的问题：如果代码比较简单，业务变动大，完全没必要用设计模式。
+
+## 如何避免过度设计？
+
+1. 不要为了应用设计模式而应用，解决问题而不是炫技。
+2. 不以破坏代码可读性为前提，宁要可读不要优雅。
+3. 不要为了短期不存在的扩展而费神（YAGNI : You Ain't Gonna Need It）。
+4. 持续重构优于提前设计，发现问题，解决问题，不要试图一开始就打造完美代码。
+
+## 总结
+
+在使用设计模式时，重要的是要根据具体的情况权衡利弊，并且保持适度。
+
+设计模式应该是用来帮助解决问题的工具，而不是问题本身。
+
+在实际开发中，应该以简洁性和实用性为原则，避免为了模式而模式。
\ No newline at end of file