https://www.notion.so/laisky/Cloudflare-outage-on-November-18-2025-2bcba4011a8681e79964ff8933d3c5b2
CloudFlare 对于 2025-11-18 的故障报告。边缘服务设定了严格的内存限制，其中bot modules 限制了能够处理的规则行数。当接收到超过限制的规则文件后导致 panic。而新的 FL2 系统在 bot modules panic 时，没能仅降级 bot 服务，而是全链路 panic，导致全站 5xx。旧版的 FL 系统就很好的仅降级了 bot score 服务，没有对用户业务造成中断。
我个人认为的经验教训就是：
1. bot modules panic 不是问题，有助于尽早暴露错误，但是必须被隔离。
2. FL2 在 bot modules panic 后，应该进行告警和服务降级，而不是整体 panic（Blast Radius）
3. chaos engineering 应该对各种交互都进行测试，比如文件过大、格式错误等等。任何关键服务都不应该信任外部输入，即使这个外部输入来自友方。
CloudFlare 对于 2025-11-18 的故障报告。边缘服务设定了严格的内存限制，其中bot modules 限制了能够处理的规则行数。当接收到超过限制的规则文件后导致 panic。而新的 FL2 系统在 bot modules panic 时，没能仅降级 bot 服务，而是全链路 panic，导致全站 5xx。旧版的 FL 系统就很好的仅降级了 bot score 服务，没有对用户业务造成中断。
我个人认为的经验教训就是：
1. bot modules panic 不是问题，有助于尽早暴露错误，但是必须被隔离。
2. FL2 在 bot modules panic 后，应该进行告警和服务降级，而不是整体 panic（Blast Radius）
3. chaos engineering 应该对各种交互都进行测试，比如文件过大、格式错误等等。任何关键服务都不应该信任外部输入，即使这个外部输入来自友方。
laisky on Notion
Cloudflare outage on November 18, 2025 | Notion
On 18 November 2025 at 11:20 UTC (all times in this blog are UTC), Cloudflare's network began experiencing significant failures to deliver core network traffic. This showed up to Internet users trying to access our customers' sites as an error page indicating…
https://x.com/0xdizz/status/1996425682717720971?s=20 用 react 写服务端的赶紧自查一下。我这种坚持不碰前端佬写的服务端的后端仔有福了🐶
https://laisky.notion.site/Time-Zone-Handling-for-Software-Engineers-A-Comprehensive-Technical-Handbook-2b3ba4011a8680f2b895f51f19b62dad?source=copy_link
让 DeepResearch 帮忙总结了一篇关于时区的报告。最近都不怎么喜欢搜索文章了，想到什么问题就扔给 DeepResearch 让它给我写一篇报告。
因为中国只有一个时区，很多开发人员都会忽略时区问题，我加入很多团队都帮忙处理过时区相关的问题（另一个经常被忽略的是编码问题）。
首先，在用户看不见的后端使用 UTC 时间是一个很好的习惯，但是 UTC 并不是银弹，并不能取代时区。
时区并不仅仅只是相对于 UTC 的一个固定偏移量，而是代表某一地区时间变化的历史和规则。比如某地可能在某一个时刻，决定让时钟拨快或拨慢一小时，这些规则的处理都必须依赖准确的当地时区数据，而不是 UTC 能够解决的。同理，不同的时区也不能随意的互相替换，即使在当前时刻它们的 UTC 偏移量相同。
比如关于冬令时/夏令时的调整，就会导致当地的某一时刻在两个不同时区出现两次，而另一个时刻则根本不存在。
关于时间的存储，UTC 仅能满足对于时刻的存储需求。只要涉及到当地事件、时间的相对计算、日程安排（牵涉星期、月份日期、节假日）等，都必须结合使用当地时区信息进行计算。而且由于用户可能会进行跨时区迁移，最好能够让用户自行选择自己的时区信息（比如 Google Calendar 的做法）。
重点：
* 如果你只需要时刻信息(Instant)，使用 UTC 存储和传输是一个好习惯。
* 但是如果你需要任何基于当地时间的计算，必须携带时区信息。
BTW，时区的英文缩写存在重名，在沟通中不要使用简写。比如 CST 既可以是 China Standard Time 也可以是 Central Standard Time。 我以前和美国的团队协作时就遇到过歧义。
让 DeepResearch 帮忙总结了一篇关于时区的报告。最近都不怎么喜欢搜索文章了，想到什么问题就扔给 DeepResearch 让它给我写一篇报告。
因为中国只有一个时区，很多开发人员都会忽略时区问题，我加入很多团队都帮忙处理过时区相关的问题（另一个经常被忽略的是编码问题）。
首先，在用户看不见的后端使用 UTC 时间是一个很好的习惯，但是 UTC 并不是银弹，并不能取代时区。
时区并不仅仅只是相对于 UTC 的一个固定偏移量，而是代表某一地区时间变化的历史和规则。比如某地可能在某一个时刻，决定让时钟拨快或拨慢一小时，这些规则的处理都必须依赖准确的当地时区数据，而不是 UTC 能够解决的。同理，不同的时区也不能随意的互相替换，即使在当前时刻它们的 UTC 偏移量相同。
比如关于冬令时/夏令时的调整，就会导致当地的某一时刻在两个不同时区出现两次，而另一个时刻则根本不存在。
关于时间的存储，UTC 仅能满足对于时刻的存储需求。只要涉及到当地事件、时间的相对计算、日程安排（牵涉星期、月份日期、节假日）等，都必须结合使用当地时区信息进行计算。而且由于用户可能会进行跨时区迁移，最好能够让用户自行选择自己的时区信息（比如 Google Calendar 的做法）。
重点：
* 如果你只需要时刻信息(Instant)，使用 UTC 存储和传输是一个好习惯。
* 但是如果你需要任何基于当地时间的计算，必须携带时区信息。
BTW，时区的英文缩写存在重名，在沟通中不要使用简写。比如 CST 既可以是 China Standard Time 也可以是 Central Standard Time。 我以前和美国的团队协作时就遇到过歧义。
laisky on Notion
🤖Time Zone Handling for Software Engineers: A Comprehensive Technical Handbook | Notion
Introduction
https://tee.fail/ wiretap 的团队继续发力，TEE 加密芯片对内存加密使用了确定性算法，同样的明文会生成同样的密文，导致可以通过内存分析破译私钥。继上次破解 SGX 老款芯片后，这次把最新款的 TDX 和 SEV-SNP 也攻破了，可以说 TEE 全军覆灭。
AMD 和 Intel 都表示不会修复，内存监听和改写不属于 TEE 的防御范畴。
看来，TEE 确实只能用来防内鬼，并不能构成一个可以放心地托管给别人的飞地。
* prev
AMD 和 Intel 都表示不会修复，内存监听和改写不属于 TEE 的防御范畴。
看来，TEE 确实只能用来防内鬼，并不能构成一个可以放心地托管给别人的飞地。
* prev
继续学习 Context Engineering 相关的文章，主要看了这两篇：
- 来自 Augment 的 《How we made code search 40% faster for 100M+ line codebases using quantized vector search》
- 来自 Anthropic 的 《Contextual Retrieval in AI Systems》
📒 关于 query 的性能：
1. 利用 ANN 大幅减少 embeddings vectors 数量，提高检索速度。
我理解类似于对向量进行聚类，然后只对聚类中心进行搜索，最后再在聚类内进行精确搜索。
但是不确定 Augment 是自己手写了一个 ANN 的聚合层，还是直接使用了类似 pg_vector 的 IVF 等功能。
2. 对 ANN 方案的优化，对 embeddings index 做 SNAPSHOT。只有搜索的 chunk 在 SNAPSHOT 中时才触发 ANN 加速，否则走传统的线性扫描。
这样就可以适应无时不刻都在动态更新的代码库。
📒 关于 query 的准确率和召回率：
1. embeddings vectors 擅长 semantic search，但对精确匹配不友好。结合 BM25 来提高精确匹配的能力。
2. 在 embeddings 以前，先为 chunk 添加上下文信息
有一个优化技巧是，先利用 prompt cache 缓存全文，然后再使用这个 cache 为每一个 chunk 生成上下文。
3. 玄学参数，每次 RAG 提供 20 个 context chunks 的效果最好。Anthropic 的做法是，用混合搜索检索出 400 个 chunks，然后使用 cohere rerank 选出 top20。
4. rerank 会带来额外的延迟，所以 chunks 数量和延迟是一个 trade-off。
👇 next
- 来自 Augment 的 《How we made code search 40% faster for 100M+ line codebases using quantized vector search》
- 来自 Anthropic 的 《Contextual Retrieval in AI Systems》
📒 关于 query 的性能：
1. 利用 ANN 大幅减少 embeddings vectors 数量，提高检索速度。
我理解类似于对向量进行聚类，然后只对聚类中心进行搜索，最后再在聚类内进行精确搜索。
但是不确定 Augment 是自己手写了一个 ANN 的聚合层，还是直接使用了类似 pg_vector 的 IVF 等功能。
2. 对 ANN 方案的优化，对 embeddings index 做 SNAPSHOT。只有搜索的 chunk 在 SNAPSHOT 中时才触发 ANN 加速，否则走传统的线性扫描。
这样就可以适应无时不刻都在动态更新的代码库。
📒 关于 query 的准确率和召回率：
1. embeddings vectors 擅长 semantic search，但对精确匹配不友好。结合 BM25 来提高精确匹配的能力。
2. 在 embeddings 以前，先为 chunk 添加上下文信息
有一个优化技巧是，先利用 prompt cache 缓存全文，然后再使用这个 cache 为每一个 chunk 生成上下文。
3. 玄学参数，每次 RAG 提供 20 个 context chunks 的效果最好。Anthropic 的做法是，用混合搜索检索出 400 个 chunks，然后使用 cohere rerank 选出 top20。
4. rerank 会带来额外的延迟，所以 chunks 数量和延迟是一个 trade-off。
👇 next
https://x.com/cr0ath/status/1978993127966019793?s=46
很有意思，安全相关的代码，要使用真随机，不要用伪随机，更不能手写随机。
眼见不为实，小心 unicode 特殊字符。
很有意思，安全相关的代码，要使用真随机，不要用伪随机，更不能手写随机。
眼见不为实，小心 unicode 特殊字符。
简单学习了一下 https://github.com/github/spec-kit，确实是一个很有趣的项目。
作为一个资深的开发者，在我看来，spec-kit 就是试图在扮演我每天都在做的事情，试图以标准化的方式完成从需求到产品的过程：
1. 模拟场景，撰写 user story。
2. 根据 user story，编写需求文档（相当于
3. 根据需求，撰写技术文档，进行可行性分析和系统设计（相当于
4. 根据技术文档，拆分开发任务。如果选择 TDD 的开发模式，则可以同步编写测试用例（相当于
5. 各个开发人员和测试人员，认领任务，进行开发和测试（相当于
在我的实际上和 AI 协作 coding 的经验看来，实际上还少了一个很关键的步骤，应该可以视为
我之前使用 Augment Code 时，发现它对每一个项目，都会维护一个全局的 memory，从而让 Agents 能够在一个统一的上下文中工作。这个 memory 里面，包含了项目的概要，需要关注的重要功能点，相关规范等等，类似于一个专注于当前项目的
我可以理解，对于那些对标准开发流程比较陌生的初级开发者而言，或者对于那些纯粹 vibe coding 的人而言，spec-kit 无疑是一个巨大的进步，显著提高了开发结果的确定性。不过，有一个地方让我觉得有点奇怪，spec-kit 居然需要开发者手动来逐步执行
从我个人来说，我不会考虑实际使用 spec-kit，有如下原因：
1. 作为一名资深开发者，我已经熟悉了标准的产品研发流程，不需要 spec-kit 用如此笨拙的方式来引导我，它的工作流在我看来过于粗糙。
2. 正如官方的视频介绍中所说，“spec-kit 让你只需要关心 What 和 Why，而不需要关心 How”。但是我认为，目前的模型能力还不足以让我完全不关心 How。
3. 为了降低成本，我倾向于尽可能减少和 AI 对话的次数，而 spec-kit 显然会大幅增加我和 AI 交互的频次。
综上，我认为 spec-kit 是一个很好的试图对 vibe coding 标准化的尝试。它就像一幅重型铠甲，如果你武艺平平，那么它会显著提高你的战斗力。但是对于那些武艺高强的武士而言，它反而会拖累你的身手，让你无法发挥出真正的实力。所以是否要采用它，取决于当前项目对于开发流程的 vibe 程度有多高。
我认为，spec-kit 的价值体现在：
1. 对于 vibe coder，作为一种提高标准化和确定性的工具，提高产品质量。
2. 对于和 AI 协作的开发者，提供了一个参考，可以用来优化开发流程和 prompt 设计。
3. 对于 agents 的设计者，提供了一个完整的和用户交互的流程，可以用来设计能够完成用户需求的 agents。
Ps. 我更倾向于认为，spec-kit 所提供的辅助，很快（或者已经）被强化学习或 fine-tuning 内化为模型本身的能力，而不需要外部的工具来辅助。
最后，我个人对开发模式的看法是，短期内 AI 编程 Agents 仍然和资深开发者存在一些本质上的差距，但是这并不影响它能够极大的提高开发效率，并且独立完成大量的产品。我认为，短期内两种不同类型的人类开发者角色将会并存：
1. 一种是白盒开发，人类开发者掌控核心的细节，AI 扮演辅助角色，帮助人类开发者提高效率。
2. 另一种是黑盒开发，也就是所谓的 vibe coding，AI 扮演主导角色，人类开发者主要负责提出需求和验收结果。
这两种模式都有其适合的场景和生存空间，具体选用什么工具和开发流程，还是要取决于具体的项目需求。
作为一个资深的开发者，在我看来，spec-kit 就是试图在扮演我每天都在做的事情，试图以标准化的方式完成从需求到产品的过程：
1. 模拟场景，撰写 user story。
2. 根据 user story，编写需求文档（相当于
/speckit.specify）。3. 根据需求，撰写技术文档，进行可行性分析和系统设计（相当于
/speckit.plan）。4. 根据技术文档，拆分开发任务。如果选择 TDD 的开发模式，则可以同步编写测试用例（相当于
/speckit.tasks 和 /speckit.checklist）。5. 各个开发人员和测试人员，认领任务，进行开发和测试（相当于
/speckit.implement）。在我的实际上和 AI 协作 coding 的经验看来，实际上还少了一个很关键的步骤，应该可以视为
/speckit.clarify 的补充，就是收集相关 工具、SDK、API 的详细使用文档，以便于 AI 能够理解和正确地使用这些工具。我之前使用 Augment Code 时，发现它对每一个项目，都会维护一个全局的 memory，从而让 Agents 能够在一个统一的上下文中工作。这个 memory 里面，包含了项目的概要，需要关注的重要功能点，相关规范等等，类似于一个专注于当前项目的
Agents.md 文件。这个文件，在 spec-kit 中被称为 constitution。我可以理解，对于那些对标准开发流程比较陌生的初级开发者而言，或者对于那些纯粹 vibe coding 的人而言，spec-kit 无疑是一个巨大的进步，显著提高了开发结果的确定性。不过，有一个地方让我觉得有点奇怪，spec-kit 居然需要开发者手动来逐步执行
specify、plan、tasks、checklist、implement 这些步骤，而不是直接让 AI 来直接完成这些步骤，对于 vibe coder 而言可能过于繁琐。从我个人来说，我不会考虑实际使用 spec-kit，有如下原因：
1. 作为一名资深开发者，我已经熟悉了标准的产品研发流程，不需要 spec-kit 用如此笨拙的方式来引导我，它的工作流在我看来过于粗糙。
2. 正如官方的视频介绍中所说，“spec-kit 让你只需要关心 What 和 Why，而不需要关心 How”。但是我认为，目前的模型能力还不足以让我完全不关心 How。
3. 为了降低成本，我倾向于尽可能减少和 AI 对话的次数，而 spec-kit 显然会大幅增加我和 AI 交互的频次。
综上，我认为 spec-kit 是一个很好的试图对 vibe coding 标准化的尝试。它就像一幅重型铠甲，如果你武艺平平，那么它会显著提高你的战斗力。但是对于那些武艺高强的武士而言，它反而会拖累你的身手，让你无法发挥出真正的实力。所以是否要采用它，取决于当前项目对于开发流程的 vibe 程度有多高。
我认为，spec-kit 的价值体现在：
1. 对于 vibe coder，作为一种提高标准化和确定性的工具，提高产品质量。
2. 对于和 AI 协作的开发者，提供了一个参考，可以用来优化开发流程和 prompt 设计。
3. 对于 agents 的设计者，提供了一个完整的和用户交互的流程，可以用来设计能够完成用户需求的 agents。
Ps. 我更倾向于认为，spec-kit 所提供的辅助，很快（或者已经）被强化学习或 fine-tuning 内化为模型本身的能力，而不需要外部的工具来辅助。
最后，我个人对开发模式的看法是，短期内 AI 编程 Agents 仍然和资深开发者存在一些本质上的差距，但是这并不影响它能够极大的提高开发效率，并且独立完成大量的产品。我认为，短期内两种不同类型的人类开发者角色将会并存：
1. 一种是白盒开发，人类开发者掌控核心的细节，AI 扮演辅助角色，帮助人类开发者提高效率。
2. 另一种是黑盒开发，也就是所谓的 vibe coding，AI 扮演主导角色，人类开发者主要负责提出需求和验收结果。
这两种模式都有其适合的场景和生存空间，具体选用什么工具和开发流程，还是要取决于具体的项目需求。
GitHub
GitHub - github/spec-kit: 💫 Toolkit to help you get started with Spec-Driven Development
💫 Toolkit to help you get started with Spec-Driven Development - github/spec-kit
在计算机安全领域，我们将数据安全粗略分为三个维度：in-transit, at-rest, in-use。
HTTPS 可以保护 in-transit，AES 可以保护 at-rest，而 TEE 就是注重于保护 in-use 时的内存数据安全。理论上，一个妥善配置使用的 TEE，可以让用户放心地在不信任的环境中运行代码。
比如你作为一个版权所有方，可以要求对方提供可验证的 TEE 环境，然后你才会将重要的数据传输进对方的 TEE 加密环境中。即使这台机器完全在对方手中，TEE 硬件也会保障你数据的安全。
然而，这个安全神话最近被无情的打破了。研究者发现，SGX 的 CPU 和内存间的加密通信使用的是确定性的加密算法（deterministic）。那么通过运行一个自定义的 TEE 应用，然后再拦截内存总线上的加密数据流，就可以让 TEE 的内存加密芯片扮演一个 oracle 的角色，从而为攻击者提供充足的包含时序信息的密文，从而推断出 TEE 签名 QE REPORT 所使用的 ECDSA 私钥。
拿到签名私钥后，就可以为任意伪造的 REPORT 签名。而 SGX 正是通过 REPORT 来证明当前程序运行在一个可信的 TEE 环境之中。那么攻击者就可以实际在非加密环境中运行程序，但是仍然提供一个可信的 REPORT，从而骗取数据提供方的信任。
很可惜 Intel 也不打算修复这个问题，那么 TEE 安全性的基础（Trusted Computing Base, TCB）就得包含：
* TEE 硬件
* 可信的 host OS
* 可信的物理机器维护者
作为一个曾经的 TEE 开发者，说实话，前两者还可以通过软件手段来保障。但是最后一条，感觉完全扭曲了 TEE 的意义。如果你愿意信任机器的提供方，那么实际上 TEE 的意义就变成了防内贼而不是外贼。
作为一个开发者，你也可以从中吸取教训，谨记“一事一密”，利用随机数和密钥派生，不复用密钥，确保相同数据的每次加密结果都不一样。在加密以外，完整性验证也是非常重要的（integrity & authentic）。
扩展阅读:
* 我以前写过一系列介绍 TEE 的文章
* https://wiretap.fail/
* Intel 的回应: More Information on Encrypted Memory Frameworks for Intel Confidential Computing
* next
HTTPS 可以保护 in-transit，AES 可以保护 at-rest，而 TEE 就是注重于保护 in-use 时的内存数据安全。理论上，一个妥善配置使用的 TEE，可以让用户放心地在不信任的环境中运行代码。
比如你作为一个版权所有方，可以要求对方提供可验证的 TEE 环境，然后你才会将重要的数据传输进对方的 TEE 加密环境中。即使这台机器完全在对方手中，TEE 硬件也会保障你数据的安全。
然而，这个安全神话最近被无情的打破了。研究者发现，SGX 的 CPU 和内存间的加密通信使用的是确定性的加密算法（deterministic）。那么通过运行一个自定义的 TEE 应用，然后再拦截内存总线上的加密数据流，就可以让 TEE 的内存加密芯片扮演一个 oracle 的角色，从而为攻击者提供充足的包含时序信息的密文，从而推断出 TEE 签名 QE REPORT 所使用的 ECDSA 私钥。
拿到签名私钥后，就可以为任意伪造的 REPORT 签名。而 SGX 正是通过 REPORT 来证明当前程序运行在一个可信的 TEE 环境之中。那么攻击者就可以实际在非加密环境中运行程序，但是仍然提供一个可信的 REPORT，从而骗取数据提供方的信任。
很可惜 Intel 也不打算修复这个问题，那么 TEE 安全性的基础（Trusted Computing Base, TCB）就得包含：
* TEE 硬件
* 可信的 host OS
* 可信的物理机器维护者
作为一个曾经的 TEE 开发者，说实话，前两者还可以通过软件手段来保障。但是最后一条，感觉完全扭曲了 TEE 的意义。如果你愿意信任机器的提供方，那么实际上 TEE 的意义就变成了防内贼而不是外贼。
作为一个开发者，你也可以从中吸取教训，谨记“一事一密”，利用随机数和密钥派生，不复用密钥，确保相同数据的每次加密结果都不一样。在加密以外，完整性验证也是非常重要的（integrity & authentic）。
扩展阅读:
* 我以前写过一系列介绍 TEE 的文章
* https://wiretap.fail/
* Intel 的回应: More Information on Encrypted Memory Frameworks for Intel Confidential Computing
* next
我认为《真空》和《其主之声》这两部作品就能最好的解释莱姆自己的风格。路径曲折，但是却没有实际意义上的内核故事。读者不要期望会有一个具体的故事，只是在攀登的过程中去感受复杂性本身。
《星际旅行日记》中，通过对过去和未来的穿越，寥寥数语就阐述了未来宗教随着科学的发展而不断受到挑战并革新的进程，令人叹为观止。
有的作家靠一个点子就能写一本书。而莱姆则是用浩如烟海的点子堆出了一本本的书。 #book
学习了一下 Golang 1.25 的新特性，主要包括以下几点：
1. JSON v2。性能提升，支持自定义序列化反序列化。支持通过 options 参数控制序列化过程。
2.
3.
4. 实验性质的 Green TEA GC 新算法，通过以 SPAN 为粒度的聚合来提高缓存局部性
5.
6.
> READ MORE
1. JSON v2。性能提升，支持自定义序列化反序列化。支持通过 options 参数控制序列化过程。
2.
synctest 可以自动跳过时钟等待的时间，加快测试3.
GOMAXPROCS 原生自适应 CGROUP 4. 实验性质的 Green TEA GC 新算法，通过以 SPAN 为粒度的聚合来提高缓存局部性
5.
os.Root 可以设定文件系统容器，防止路径逃逸6.
hash.Hash 支持 Clone() 方法> READ MORE
laisky on Notion
Go 1.25 interactive tour | Notion
Go 1.25 is out, so it's a good time to explore what's new. The official release notes are pretty dry, so I prepared an interactive version with lots of examples showing what has changed and what the new behavior is.
我不是算法研究员，只是一名工程人员，读的不是很细，也不追求理论上的完全掌握，只希望能对技术实现有高层次的理解，知道它们是什么，适用用来处理什么任务，就足够了。
阅读此书我还有个收获是，作者经常用寥寥数语就透彻地阐述了一些数学概念的实际意义。
比如我们如此执着于为矩阵计算特征值和特征向量的目的，就在于矩阵运算很复杂，而将向量投影到特征向量空间后，相对应的矩阵运算就成为了简单的特征值倍数的拉伸操作，极大简化了计算复杂度。
还有 CNN 里的卷积核，名字听上去很吓人，实际上就是用一个低维小张量（卷积核）取代一整层的权重参数，然后对着一层的每一组 input 重复使用这个核去求算下一层的输入。这种做法极大缩减了模型的总参数量，而且对于“计算相邻像素差值”之类的图像识别任务非常有效。
开卷有益，即使没读懂也能有所收获。 #book
* 权力的转移（Power Shift）
* 未来的冲击（Future Shock）
* 第三次浪潮（The Third Wave）
《权力的转移》这本书让我更好的理解了《主权个人（The Sovereign Individual）》这本书中对国家暴力的阐述。权力的核心在于欲望，你能满足别人的欲望，你就掌握了对别人的权力。工业时代国家实现了对暴力的垄断，人们的一切争端都需要通过国家机器来解决。随着经济的增长，和自给自足被完全消灭，贪婪成为了权力的核心，国家通过对经济的控制来实现权力。
作者在《第三次浪潮》中还阐述了对人类社会影响最大的三次全球化变革：
1. 农业革命，代表村庄、城市的出现
2. 工业革命，彻底消灭自给自足，代表有国家机器、批量生产、工厂式教育。社会被区分为生产者和消费者。
3. 正在进行中的变革，随着信息技术和工业的发展，消费者再度取代了生产者的地位，变成产消合一者。
整个社会的趋势，似乎正在回归过去的小规模自治的村庄，只不过是通过更高的工业技术和信息技术实现的。 #book
读了两篇关于 prompt/context engineering 的文章：
* Manus 之外：实战笔记（1）薛定谔的缓存
* Context Engineering for AI Agents: Lessons from Building Manus
最重要的还是 KV-Cache，Manus 甚至称之为衡量 agent 框架的最重要的指标。因为 Transformer 的单向注意力机制 (Causal Attention Mask)，每一个 input token 都只会使用它前面的全部 tokens 计算 KV。所以，保持 context prefix 稳定，可以极大提高 KV-Cache 的命中率，从而提高 LLM 输出效率和降低费用。
所以 Context Engineering 中的一个重要策略，就是在尽可能保持 context prefix 不变的前提下，实现各种功能需求：
1. 利用 LLM API 提供的 prefill 特性，利用 tool name 前缀来限定 tools 调用范围。而不是动态修改 context 中的 tools declaration。（OpenAI 不支持该功能，Claude 支持）
2. 使用 JSON schema 定义 tools 时，要注意使用确定性排序的序列化方法
除了提高 KV-Cache 命中率的各种工程方法外，Manus 还分享了一些其他的经验：
* 利用外部文件来提供无限上下文，并且保持 AI 对最初目标的关注
* 在 context 中保留犯错记录，避免重复犯错
* few-shots 需要添加噪音，预防 repetitive decision
很高兴地发现绝大部分内容和我自己的实践中总结出来的经验完全一致，甚至连用法也是一致的。不过 prefill 这个技巧我是第一次学到，我以前只关注 OpenAI 的 API，没想到实际上其他家，尤其是 Anthropic，已经有很长远的发展了。
* Manus 之外：实战笔记（1）薛定谔的缓存
* Context Engineering for AI Agents: Lessons from Building Manus
最重要的还是 KV-Cache，Manus 甚至称之为衡量 agent 框架的最重要的指标。因为 Transformer 的单向注意力机制 (Causal Attention Mask)，每一个 input token 都只会使用它前面的全部 tokens 计算 KV。所以，保持 context prefix 稳定，可以极大提高 KV-Cache 的命中率，从而提高 LLM 输出效率和降低费用。
所以 Context Engineering 中的一个重要策略，就是在尽可能保持 context prefix 不变的前提下，实现各种功能需求：
1. 利用 LLM API 提供的 prefill 特性，利用 tool name 前缀来限定 tools 调用范围。而不是动态修改 context 中的 tools declaration。（OpenAI 不支持该功能，Claude 支持）
2. 使用 JSON schema 定义 tools 时，要注意使用确定性排序的序列化方法
除了提高 KV-Cache 命中率的各种工程方法外，Manus 还分享了一些其他的经验：
* 利用外部文件来提供无限上下文，并且保持 AI 对最初目标的关注
* 在 context 中保留犯错记录，避免重复犯错
* few-shots 需要添加噪音，预防 repetitive decision
很高兴地发现绝大部分内容和我自己的实践中总结出来的经验完全一致，甚至连用法也是一致的。不过 prefill 这个技巧我是第一次学到，我以前只关注 OpenAI 的 API，没想到实际上其他家，尤其是 Anthropic，已经有很长远的发展了。
