2025-09-18 04:54:00
最近读完了 Generative AI with Amazon Bedrock: Build, scale, and secure generative AI applications using Amazon Bedrock。 在豆瓣已要求实名记录阅读的情况下，还是用博客写书评吧。
内容由 ChatGPT 生成，大纲是我提供的。
不必读，这本书内容已经过时。
这本书很好地体现了“时代的眼泪”——AI 领域出版物面临的最大挑战：时效性。 尽管它出版于 2023 年底，但短短几个月内就显得落伍，原因包括：
与其读书，不如：
这不仅是本书的问题，而是整个 AI 技术书籍领域的困境。 在快速演进的技术环境下，传统出版模式可能需要改变，例如：
在 AI 领域，持续学习与实践远比依赖书籍更重要。
2025-08-21 04:54:00
2025.08.08 是个值得纪念的大日子，基于此，这里更新下自己的 2025 计划 2024总结 并 2025规划。
这里重新列举下自己的2024计划。
Major tasks:
Accumulating tasks:
2025-08-16 04:54:00
很简短的一个博客，推荐下这本书《大规模语言模型：从理论到实践》.
最近读完了这本书，在豆瓣已经必须实名才能记录自己阅读的现在，还是用博客写书评吧。
这本书最好的一点就是有网络版，https://intro-llm.github.io/
事实上，我最先看的是去年的第一版，前几天搜了搜发现更新了第二版，而且作者提供了基于 GitHub 的 Issues 提交页面。
在大预言模型日新月异的现在，基本上，你今天掌握的具体的一些知识点过了六个月可能就过期了，这本书不断更新才是正确的方法。
回过头来说这本书，我觉得是中文领域少有的比较正规的大预言模型学习资料。正规的意思是这本书会按照特定的章法循序渐进地全面介绍一个领域，而不是过于看重细节，防止只见树叶不见泰山的问题。
这本书我推荐大家跳着读，读的时候先想一想如果你自己来写，你会介绍什么。对照着阅读就会发现自己没想道的知识点。不过没必要沮丧，这是完全正常的，学些下就行。
2025-01-01 04:54:00
2024 年就这么匆匆的过去，心中感慨万千，这里总结下自己的 2024，规划下 2025 的计划。
这里先写下这个总结，后面我再补充调整。
不停写博客的好处就是，如果你去翻看去年的这个总结，其实开头是一样的，只是改了年份，年年岁岁花相似，岁岁年年人不同。
直接从年初计划 2023总结 并 2024规划 和 2024Q1 总结 那拷贝下任务列表，
这里重新列举下自己的2024计划。
Major tasks:
Accumulating tasks:
2024-12-31 04:54:00
推荐一个网站，感觉非常有用。
HackWay 非常好的自学网站，主要参考了美国的 6 大名校的课程。
说实话，如果不是为了一个 CS 的学位，很多普通大学的课程即使是任课老师也没有这些课程的授课水平，非常推荐大家按照推荐去学习。
当然，这个是文火出慢工，如果面临面试，Leetcode 这些才是你的选择，毕竟 coding 题要是遇到原题，还是非常加分的，这个比较直接，立竿见影。
2024-10-20 23:54:00
最近下前段时间和老板 1:1 的总结，重点是如何正确的估计时间。
SDE 总是要经常估计项目需要多少时间的，这个问题其实很难，原因不复杂，如果这个项目是一个常规的项目，那么大多数时候，计算机的行业经验是把这个任务做成一个服务，然后发布出去。剩下的任务就是按部就班地按照文档操作，调用就行。这种时间估计一般是很靠谱的。
但是如果让你去做一个时间预估，那么这个时候，很大概率是涉及到不少的未知元素，所以大家不知道。那么你的预估其实就是基于你自己的经验去给一个大概的估计，这个准或者不准其实很大概率取决于你的经验和实际的项目难度。
举个例子，你认为数据已经在上游 team 那里准备好了，所以你估计了剩下的 ETL 的时间，但是你真的去做发现，上游 team 并没有把你需要的数据准备好，这个时候就需要和上游 team 沟通，cut ticket 或者开 Sync meetings，这个往往就时间无法控制了。但是你不真正去做这个项目很多时候又很难发现数据又问题。
那么是不是就没有方法去解决了呢？
也不是就没有方法，下面总结下我的一些看法。
你大概心中会有一个时间估计，但是不要直接给出具体的时间。因为往往你给出时间，大家就会认为这个时间是可靠的，即使你强调只是估计。很多时候你给具体时间，大家就会按照着这个时间来评价你的工作，这样你就必须 meet the deadline。但是很多时候很多东西是你无法掌控的，所以永远不要给出具体的时间。
你需要给出这个项目的具体 steps，然后对于每个 step 给出时间 range 的估计。这个 range 有一个比较方便的方法就是， time by 2 and plus 1，如果你觉得这个 step 需要 1 天，你就给 2 ～ 3 天。这样如果你提前完成，大家会非常喜欢和你合作。
很多时候如果你来不及给出 list 或者不清楚，你就说你需要时间来研究并且列出 steps 并且给出估计，然后说 later today or after this meeting，I will send the estimate doc to you 等等。
因为你列出了一系列的步骤，所以你后面也会比较方便找出你的问题，比如按照计划我今天需要拿到上游数据，但是没有，你就可以考虑是不是找对面的 on-call 或者 升级到找对方的上级来解决。
如果出现了很多重大的问题，或者你的 time line 拖的久了，不要自己干着急或者只是抓紧干活，及时 call out 并且找别人帮助。同时有时候这个问题你没办法解决，那就及时 reset time line。
