雨碎江南

好的提示词现有的 LLM 的底层原理是一个超级强大的模式匹配器。下面的 4 种技巧可以显著提高 AI 的质量： 给充足的上下文：直接缩窄概率分布。在 prompt 中加入无关信息会显著降低输出质量，注意力机制会被无关内容分散。 Few-shot：本质还是“模式匹配”，模型与大，匹配能力越强，从几个例子中提取模式的效率更高。 CoT：即思维链，让 AI 一步步展示自己的思考过程而不是直接给出最终答案。这很反直觉（因为 AI 没有“更认真地想”），关键在于：当 AI 生成“第一步”的结果后，这个结果成了它生成“第二步”时的上下文。思维链本质上是在做这件事：把一个复杂的大问题拆成多个简单的小步骤，每一步的输出都成为下一步的上下文。AI 不需要在”一步到位”的巨大可能性空间中猜答案，而是在每一步的小范围内做高精度的匹配。更通俗地说：让 AI 直接跳到答案，就像让你从房间的一端蒙着眼睛直接走到对角——大概率会撞墙。但如果每走一步你都能睁眼确认一下方向，你就能顺利到达目的地。思维链就是让 AI...

你永远不可能真正了解一个人，除非你穿上他的鞋子走来走去，站在他的角度思考问题。可是真当你走过他的路时，你连路过都觉得难过。有时候，你所看到的，并非事情的真相，你了解的不过是浮在水面上的冰山一角。—— 《杀死一只知更鸟》 「没有启程的路才会遥不可及」，很多时候，困难只是我们给自己设下的心理障碍。

Etag 是 Entity Tag 的缩写，是内容缓存。 http 头 If-Modified-Since：请求头中可以指定资源修改时间，服务器判断如果没有更改则返回 304 状态，并且不携带消息体，更改了则返回 200 携带上最新的资源。常用于缓存控制。 Retry-After：响应头中可以指示客户端在多久后再次尝试请求。通常和 503(Service Unavailable) 或者 429(Too Many Requests) 一起使用，但也可以与其他一些表示暂时性失败的状态码配合使用。这个头部字段可以帮助服务器进行流控，尤其在高负载或者服务器维护期间。 Via：报文经过代理或者网关的时候，会先在首部字段 Via 中附加该服务器的信息，然后再进行转发。这个做法和 traceroute 以及电子邮件的 Received 首部的工作机制类似。首部 Via 不仅可以用于追踪报文的转发，还可以避免请求回环的发生，所以在经过代理的时候必须附加该首部。经常和 TRACE 方法一起使用，用于追踪报文的转发路径。 持久连接HTTP keep-alive...

Stay Foolish, Stay Hungry. 故善者因之，其次利道之，其次教诲之，其次整齐之，最下者与之争。 如何调动早期员工的积极性和解决大锅饭问题一家成功公司的早期员工是非常宝贵的财富。他们一般是非常冒险的人，否则他们不会选择加入新开办的，甚至还没有投资的小公司，他们的技术和能力非常强，常常可以独当一面，因为早期的公司要求员工什么都得干。他们同时对新技术非常敏感，否则他们就不会在众多新兴公司中挑选中那些日后能成功的。但是他们也有弱点：他们虽然善于开创，但是却不善于或不愿意守成，而后者对于一家大公司的发展至关重要！他们做事快，但是不够精细，因为在公司规模小的时候，抢时间比什么都重要！一般在公司发展到一定阶段的时候，他们会和新的管理层发生冲突 ——...

洋葱炒蛋准备工作： 3 个鸡蛋打到碗里，搅拌均匀 1 个洋葱切成丝 配菜少许青红椒切成丝 准备料汁： 生抽 + 耗油 + 盐 + 鸡精 + 一勺淀粉 + 一勺清水 将料汁搅拌均匀，在碗里备用 烹饪过程： 将锅烧热，加油适量，油开后加入蛋液，快速划熟划散后盛出备用 将洋葱丝和青红椒丝入锅，开大火翻炒 1 min，注意要加盐，否则会偏淡 倒入炒好的鸡蛋，淋上调好的料汁，大火随便翻炒几下入味即可

依赖注入是 Nest.js 的核心，使得开发者可以轻松管理应用程序中的依赖关系，提高代码的可测试性和可维护性。DI 是一种设计模式，它可以用来实现控制反转（IoC）—— 对象的创建和依赖关系的管理交给框架来处理而不是在代码中硬编码。 它的依赖注入主要有 3 个核心概念： Provider: 用于创建和管理的服务、仓库、工厂等的类，使用 @Injectable 装饰器进行标记，并可以在模块中注册。 Injection: 将提供者的实例自动传递给需要它们的类（如控制器、服务等）,通过构造函数注入来实现这一点。 Module: NestJS 应用程序的基本组织单元，每个模块可以包含多个提供者，并且可以在其他模块中导入和使用这些提供者。 依赖注入的优势： 解耦：类之间的依赖关系更加松散，减少了代码的耦合度，提高了代码的可维护性 可测试性：通过依赖注入，可以轻松在测试中替换依赖项，使用模拟对象进行单元测试 可拓展性：新功能可以通过添加新的提供者来实现，而不需要修改现有代码

组件是 React.js 的基础 next.js 默认使用 page.tsx 作为入口 12/ -> app/page.tsx/test -> app/test/page.tsx React HooksuseState 回调函数只有在第一次渲染的时候才会执行。 1234const [state, setState] = useState(() => { const expensiveValue = computeExpensiveValue(); // 只会在首次渲染时执行 return expensiveValue;}); 父子组件的通信请记住单向数据流。 父组件 -> 子组件：通过 props 属性传递 子组件 -> 父组件：通过 props 传递函数，触发父组件中的状态更新 在 vue 中父组件将 props 传递给子组件，子组件如果想要更改父组件中的值是通过抛出一个事件$emit通知父组件v-on来进行的。和原生 DOM...

这是我在面试一个后端 node.js 工程师的时候遇到的一个场景题目（公司是做 AI 知识库的，可能遇到这些问题）。 我当时回答了如下内容： 每一篇文档有 id, 作者，内容，版本号, 状态(编辑中，已发布) 用户在进入页面的时候，会从 DB 中拉取最新的版本，编辑的时候会向服务器发送一个请求，这个时候服务器将状态改变为编辑中，同时将版本号加一，通知其他所有客户端。将这个改动记录到日志中，便于回档。 其他用户收到消息的时候重新渲染页面。 这个结果的正确性应该是可以保证的，可以通过乐观锁的机制来保证旧版本不会覆盖新版本数据。问题是每次更新都是全量的，多客户端修改频繁，网络 IO, 频繁的 DB 修改都是问题。 抛开性能问题不谈？上面的方案有个核心问题：其他用户怎么看到当前用户的鼠标位置？ 优化的一个方案就是只做增量修改，这方面可以联想到 rsync 的增量同步， git 中的 diff 算法。 下面搜索答案，其实业界有现成的算法 OT (Operational Transformation)广泛应用在 Goole Docs...

加密算法对称加密的局限性在对称加密（例如：AES）中，加/解密使用相同的秘钥。这会带来 2 个问题： 秘钥分发问题：发送方和接受方必须通过某种安全方式共享秘钥。如果秘钥在传输时被截获，通信安全性就会被破坏。 秘钥管理问题：如果有多对用户需要通信，每对用户都需要一个独立的秘钥，秘钥数量会随着用户规模急剧增加(10个用户需要 45 个秘钥， n*(n-1)/2...

特点 精确判断不存在，但是可能会误判一个不在集合中的元素为存在（即：假阳） 不支持删除元素（几个 hash 函数计算出来的下标可能别的 key 也用到了） 总结来说就是：判断不存在的时候一定不存在，判断存在的时候大概率存在。 误判率可以通过调整参数来降低，但是无法完全消除。 数据结构的组成布隆过滤器由一个 bitSet 和一组 hash 函数组成，是一种空间效率非常高的概率算法和数据结构。在初始化的时候，bitSet 的每一位被初始化为 0，同时会定义一组 hash函数，例如有 3 组 hash 函数，hash1，hash2，hash3. 写入流程当我们要写入一个值时，过程如下，以“jionghui”为例： 首先将“jionghui”跟3组 Hash 函数分别计算，得到 bitSet 的下标为：1、7、10。 将 bitSet 的这3个下标标记为1。 假设我们还有另外两个值：java 和 diaosi，按上面的流程跟 3组 Hash 函数分别计算，结果如下： java：Hash 函数计算 bitSet 下标为：1、7、11 diaosi：Hash 函数计算 bitSet...