返回首页
最新
美国劳动部发布每个H-1B签证申请的基本薪资数据，已经持续了19年。这些数据通常对谈判薪资、研究公司或对行业薪资感到好奇的人非常有用。
h1bsalaries.fyi 允许您通过公司名称、职位和地点快速搜索这庞大的薪资数据，无需担心其他类似网站常见的恼人广告、弹窗和干扰元素。
换句话说，这里只有H-1B薪资数据。没有废话。
欢迎提出想法、评论和反馈。
在阅读了一些与谷歌新推出的A2A相关的内容后，我仍然没有搞明白它与MCP有什么不同。能否请有人用简单易懂的方式解释一下，并给个好的例子？<p>在我看来，我仍然是在用MCP来设计东西。甚至两个代理之间的通信也可以被建模为具有某些能力的MCP。
我正在处理一个相当常见的问题：
- 我有结构化数据存储在 JSONL 文件中（in.jsonl，out.jsonl）
- 我通过一个键匹配行
- 我将它们转换为（文本，嵌入）对
- 我可选地对它们进行过滤/映射
- 我将它们批处理（每批 50 个）
- 我将每批推送到外部系统（例如，向量数据库，Chroma）
就这样。听起来很简单。但它很快就变成了丑陋的命令式 Python 代码：嵌套的 for 循环、全局索引、+=、手动批处理、逐行处理、低级 JSON 解析。
在 Python 中，它通常看起来是这样的：
```python
with open("in.json", "r") as fin:
with open("out.json", "r") as fout:
for in_line, out_line in zip(fin, fout):
in_data = json.loads(in_line)
out_data = json.loads(out_line)
if in_data["custom_id"] != out_data["custom_id"]:
raise Exception...
texts = in_data["body"]["input"]
embeddings = [d["embedding"] for d in out_data["response"]["body"]["data"]]
for i in range(len(texts)):
doc = texts[i]
emb = embeddings[i]
metadata = {
"source": f"chunk-{global_ids}",
```
我们已经到了 2025 年，这就是我们将数据接入 API 的方式。
---
为什么我们要容忍这种情况？
这是一个声明式、流式的数据处理问题。为什么我们不使用更优雅的方式？更具组合性的方式，比如函数式管道？
我在想：为什么我们没有一个可组合的、流式的、函数式的领域特定语言（DSL）来处理这种任务？
---
为什么不像 Unix 管道那样构建它？
我想要的是一种感觉像这样的方式：
```bash
cat input.jsonl \
| match output.jsonl on custom_id \
| extract (text, embedding) \
| filter not-empty \
| batch 50 \
| send-to-chroma
```
---
在 Lisp / Clojure 中：
```clojure
(->> (zip input output)
(filter (= :custom_id))
(mapcat (fn [[in out]] (zip (:input in) (:embedding out))))
(partition-all 50)
(map send-to-chroma))
```
---
在 Elixir + Broadway 中：
```elixir
Broadway
|> read_stream("in.jsonl", "out.jsonl")
|> match_on(:custom_id)
|> map(&{&1.text, &1.embedding})
|> batch_every(50)
|> send_to_chroma()
```
---
现在，回到 Python...
我们被困在写命令式的代码或构建一些像这样的 hacky DSL 中：
```python
load_json_pairs() \
| where(is_valid) \
| select(to_embedding_record) \
| batch(50) \
| foreach(send_to_chroma)
```
...或者，更现实地，写成成千上万行的 `with open(...) as f`。
尽管像 tf.data.Dataset、dask.bag、pandas 或 pipe 这样的库存在，但它们都没有以连贯和富有表现力的方式真正解决这个用例。它们都专注于表格数据、大数据或机器学习输入管道——而不是这种“结构化数据 -> 转换 -> 推送到 API”的模式。
---
现在，尤其是当每个人都在做 RAG 时，这种情况显得尤为荒谬。
随着检索增强生成（RAG）成为常态，我们都在解析文件、提取嵌入、丰富元数据、批处理并插入向量存储。
为什么我们都在写相同的低级、临时代码来完成这些？
难道不应该由适当的 DSL/框架来解决这一整类工作吗？
---
建立以下内容难道不合理吗...
- 一个用于 JSON 到嵌入到 API 管道的函数式 DSL？
- 或者一个具有适当的映射、过滤、批处理、管道、接收语义的 Python 库？
- 甚至一个像 Elixir Broadway 或最小的函数式 Rx 风格图的流式运行时？
即使是 R 语言中的 dplyr 也有比我们在 Python 中为这些工作所做的更优雅的转换表达方式。
---
我是不是遗漏了什么？
有没有工具、语言或框架能够真正很好地解决这个问题？
还是说这只是工具生态系统中尚未填补的一个空白？
我很想听听其他人的做法——如果有人已经在研究这样的解决方案，那就更好了。
谢谢。
嘿，HN！<p>我正在开发一款名为 Balance 的 iOS 应用，它简化了净资产的跟踪，通过报告您在多个身份和货币下的账户、资产和债务。<p>Balance 完全使用 SwiftUI 和 SwiftData 构建，专注于隐私和安全。您所有的财务信息都保留在本地，安全地存储在设备上，并通过生物识别认证进行保护。<p>我即将发布这款应用，非常期待您的反馈！<p>核心功能：
+ 现代、直观的界面，使用 SwiftUI 构建
+ 管理多个账户、资产、债务和身份
+ 支持多种货币，满足全球财务需求
+ 针对敏感数据的生物识别认证
+ 使用 SwiftData 进行私密的本地数据存储<p>您可以如何帮助：
+ 设计与营销 - 如果您在 iOS 应用设计或发布材料方面有经验，我非常希望能与您合作。
+ 发布建议 - 欢迎提供 ASO 提示、媒体推广想法或任何营销建议。<p>试用该应用：
<a href="https://testflight.apple.com/join/NXM39cys" rel="nofollow">https://testflight.apple.com/join/NXM39cys</a><p>有反馈或合作想法吗？请联系我： inbox@cris.mx。<p>感谢您关注 Balance！