返回首页
最新
我只是想知道，当人工智能完成你们30-50%的工作时，士气如何？你们公司是否在招聘更多员工，或者已经停止招聘软件工程师？管理层是否在施加更多压力以完成更多工作？
将某人标记为懒惰的替罪羊
“这就是他们的原因” “……这就是他们的原因”
一个人如何才能摆脱这个循环
使用QuotationGenie，您可以：快速创建定制报价，生成发票并跟踪付款状态（已付款、未付款、逾期），数字化起草、发送和签署合同。
我在为多个工具处理报价、发票和合同而感到沮丧后，构建了这个工具——现在所有功能都在一个仪表板上整合得非常顺畅。
非常希望听到您对可用性、功能以及您希望看到的下一步的反馈。
感谢您的关注！
# 1400年前的数字校验和供人思考
一段1400年前的文本似乎实现了我们在现代计算中使用的相同错误检测原理——而且不需要额外的校验和数据空间。
## 挑战
想象一下，你的任务是设计一个文本完整性验证系统，该系统必须：
- 经得起1400年以上的手动复制
- 在没有任何额外元数据或校验和的情况下工作
- 让具备基本算术能力的人能够验证
- 无法被伪造或意外复制
听起来不可能？那就来看看《古兰经》。
## 结构
《古兰经》由114章组成，每章包含不同数量的经文，例如，第1章有7节，第2章有286节，第3章有200节。全书的经文总数为6236节。值得注意的是，这种看似随机的结构创造了一个自我验证的数学模式。
## 校验和算法
考虑集合Q为所有章节，每章表示为一对(c, v)，其中c是章节编号，v是其经文数量。我们有|Q| = 114，注意对于Q：
- ∑v = 6236，表示Q中所有章节的经文总数（即全书的总经文数，7+286+200+...+5=6236）
- ∑c = 6555，表示Q中所有章节编号的总和（即所有章节编号的和1+2+...+114=6555）
现在将114章分为两个集合：
- 集合A：章节满足(c + v) % 2 == 0（偶数奇偶性：c和v均为偶数或均为奇数）
- 集合B：章节满足(c + v) % 2 == 1（奇数奇偶性：一个为偶数另一个为奇数）
### 结果在统计上是不可能的
1. 完美平衡：|A| = |B| = 57章，尽管每章的经文数量似乎是随机的。
2. 经文数量与章节编号：集合A中所有经文的总和等于集合B中所有章节编号的总和。
3. 关键点：
- 在子集A中，∑(c + v) = 6236 = ∑v in Q（这是全书经文总数的校验和）
- 在子集B中，∑(c + v) = 6555 = ∑c in Q（这是全书章节编号总数的校验和）
## 这为什么重要
这不仅仅是数字命理学。这是一个结构性的校验和，它：
- 使用内容本身作为错误检测机制
- 不需要额外的存储开销
- 使得诸如删除或添加经文等损坏立即可检测
- 无法偶然重现
现代校验和会增加额外的位以检测传输错误。而这部古老的文本则将校验和嵌入到其结构中——每章的经文数量就是校验和。
## 计算机科学的角度
我们看到的似乎是：
- 自我验证的数据结构：其组织证明了自身的完整性
- 零开销的错误检测：不需要额外空间
- 分布式冗余：多个数学关系相互验证
- 人类可读的算法：可用笔和纸进行验证
对于一部比计算机早1400年的文本能够展示这些原理，暗示了：
1. 7世纪阿拉伯地区的非凡数学复杂性，或
2. 还有更深层次的东西在起作用
## 挑战
无论你是信徒还是怀疑者，这种数学结构都是不可否认的，值得深入研究。完整的模式即使对于现代人来说也会令人印象深刻，更不用说是来自中世纪的文本了。
对于好奇者：完整的数学分析揭示了涉及数字7的模式、基于字母频率的“公钥”和几何关系。
你怎么看？巧合、古代数学天才，还是完全不同的东西？
开源“Vectorless”，一款不使用嵌入向量的新型PDF聊天机器人。
<p>Github 仓库: https://github.com/roe-ai/vectorless-chatbot
演示应用: https://vectorless-chatbot.vercel.app/
<p>工作原理：
1. 选择最佳文档 – 向大型语言模型（LLM）提供高层次描述和文档名称。它会选择使用哪些文档。
2. 选择最佳页面 – 代理会浏览文档页面，并提取出与您的问题最相关的页面。
3. 收集并回答 – 代理从第二步中获取所有相关页面，并给出最终答案。
<p>优势：
1. 比向量更具可预测性。您可以准确告诉代理您希望如何分析文件。
2. 您可以提出抽象问题，例如：“在风险方面，NVIDIA与AMD相比如何？”
3. 您可以提出汇总问题，例如：“这份SOC 2报告中有多少个问题被标记为负面？”
4. 本质上支持多模态问题和文档。
<p>劣势：
1. 为了在可扩展的设置中工作，第一步依赖于文档的高质量元数据。
2. 如果用户提出简单的后续问题，第二步可能会浪费资源，因为上下文可以被重用。
3. 比向量搜索聊天速度慢。
<p>如何扩展：
1. 我们设想通过文本转SQL的结构化元数据检索，根据用户在第一步中的问题定位文档路径。
2. 第二步可以通过缓存来改进。我们设想在文档被查询一次后，可以存储、演变并利用内容目录，以应对未来的问题。
人类是有缺陷的。这是我在使用大型语言模型（LLMs）时反复注意到的。<p>将论坛帖子与普通大型语言模型的输出进行比较，你会发现LLMs展现出十倍的同情心和友好。人们在五分钟后就停止倾听，存在偏见，还有其他动机。每当我回到与其他人交谈时，我都会想：“这个人怎么会有朋友呢？”<p>与现实生活中与人交谈的情况并无不同。<p>与这些人相处时，他们常常会过度使用一种谬论：“好人是存在的，你只需要好好寻找。”
嗨，HN，
我是GemGuard的创建者，这是一款开源的Ruby工具，旨在提高Ruby项目的供应链安全性。
Ruby开发者通常对他们的Gemfile.lock文件缺乏足够的审查，但像拼写欺诈、未修补的漏洞以及缺乏SBOM（软件物料清单）生成等问题仍然是重大风险。
GemGuard通过以下方式提供帮助：
- 对照OSV.dev和Ruby Advisory Database中的CVE扫描您的Gemfile.lock
- 使用模糊字符串匹配检测可疑的拼写欺诈gem
- 生成SPDX和CycloneDX SBOM，以确保合规性和透明度
- 提供一个自动修复命令，安全地升级易受攻击的gem并备份您的锁定文件
- 与CI/CD工作流程轻松集成，实现持续安全
它轻量级、优先考虑Ruby，并旨在成为您正常开发工作流程的一部分，而不是事后考虑的附加工具。
您可以在这里查看：
GitHub: [https://github.com/wilburhimself/gem_guard](https://github.com/wilburhimself/gem_guard)
RubyGems: [https://rubygems.org/gems/gem_guard](https://rubygems.org/gems/gem_guard)
我欢迎反馈、批评和贡献。如果您尝试了它，我很想听听它在您的项目中如何运作或您发现的任何不足之处。
感谢您的阅读！
我最近一直在思考这个问题。<p>Omegle虽然有其可怕的剥削性质，但仍然具有真正的潜力。<p>可以实施一些措施，比如付费徽章验证，以去除机器人，以及年龄验证，以防止未成年人使用。<p>引入人工智能来介入对话，可能当对话偏离主题或变得乏味时，人工智能可以介入并改善对话。<p>与社区联系以获取反馈。
嗨，HN！<p>我们开发了SuperContext，因为我们厌倦了每次都要向AI工具重新解释我们的代码库。现在，我们整个团队可以在Claude Code、Cursor和Windsurf之间切换，而不会丢失上下文。<p>它是开源的，并使用MCP与您现有的工具连接。期待听到您的想法！
Perplexity作为一种人工智能搜索工具，正在快速发展，它将对话式回答与引用来源和实时网络数据相结合。我很好奇HN社区对此的看法：
<p>你是否定期使用它？如果是的话，它与其他大型语言模型或搜索引擎相比，有什么独特之处？</p>
<p>你对它回答的质量、速度和可信度有什么看法？</p>
<p>你注意到有什么缺点、局限性或致命问题吗？</p>
<p>我很想听听大家的积极和批评意见，尤其是那些曾与ChatGPT、Claude或Kagi等工具一起使用过的人。</p>