返回首页
最新
一个分屏的Markdown编辑器，使用Tufte CSS进行实时预览。支持边注、边缘注释、引言、全宽图形和带自动完成功能的BibTeX引用——所有这些都在标准的Markdown扩展中实现。<p>文档为磁盘上的.md文件，图像为常规文件。可以导出为独立的HTML文件，内置Tufte CSS——我的使用场景是撰写论文并直接上传到我的个人网站。<p>零依赖，无需npm安装，无需账户，无需构建步骤。只需运行`node server.js`。总共约7个文件。<p>在自述文件中完全披露：我是一名研究人员，而不是JS开发者，代码是由AI生成的。欢迎贡献和代码审查。
嗨，HN — 我开发了 GPACalc，旨在帮助学生快速计算 GPA/CGPA，并在不同的评分系统（4.0、5.0 和 10.0）之间转换 GPA 为百分比。
它还允许您根据当前的 CGPA、已完成的学分和预期的学期成绩来估算累计成绩。这个工具是免费的，无需注册，并且适合移动设备使用。
我非常希望能收到关于以下方面的反馈：
- 缺失的评分标准或国家系统
- 用户体验中令人困惑的部分
- 可以让这个工具对学生/顾问更有用的功能
我还是个新手。提这个问题并不是为了引发争论。
我需要为公司搭建一个内部服务器。最初有8个4T的硬盘。未来，根据业务增长，可能会增加到32个或更多。
作为新手，我在网上学习了一些关于存储池的知识。只有两个方案符合要求：Softraid和LVM。然而，我无法确定哪一个更适合我的需求。此外，我注意到这两种技术已经很长时间没有重大功能升级了，似乎都相当成熟。
因此，我真诚地想请教一下，这两种技术中哪一种更适合我。
非常感谢。无论你更倾向于哪一种，请不要争论。再次感谢。
LanceCalc 是一款浏览器扩展工具，帮助自由职业者即时计算在扣除平台费用后他们能赚到多少钱。
嗨，HN，
我开发了 DocSync，因为我参与的每个团队都面临着同样的问题：文档在撰写时是准确的，但之后从未更新。
DocSync 使用 tree-sitter 来解析你的代码并提取符号（函数、类、类型）。在每次提交时，预提交钩子会将这些符号与现有文档进行比较。如果你添加了一个函数却没有进行文档记录，提交将被阻止。
工作原理：
1. `clawhub install docsync`（免费）
2. `docsync generate .` — 从你的代码生成文档
3. `docsync hooks install` — 安装 lefthook 预提交钩子
4. 从现在开始，每次提交都会检查文档漂移
关键设计决策：
- 100% 本地 — 没有代码离开你的机器。使用 tree-sitter 进行 AST 解析，而不是 LLM。
- 如果未安装 tree-sitter，则回退到正则表达式
- 使用 lefthook（而不是 husky）作为 git 钩子 — 它更快且与语言无关
- 许可证验证是离线的（签名的 JWT，无需联网）
- 免费版提供一次性文档生成。专业版（$29/用户/月）增加了钩子和漂移检测功能。
支持 TypeScript、JavaScript、Python、Rust、Go、Java、C/C++、Ruby、PHP、C#、Swift、Kotlin。
着陆页： [https://docsync-1q4.pages.dev](https://docsync-1q4.pages.dev)
希望能得到对这种方法的反馈。文档漂移检测是你们团队实际会使用的功能吗？
展示HN：AI生成的汇编与GCC -O3在真实代码库上的比较（300K模糊测试，0次失败）
从真实开源项目中提取的三个内核，使用AI生成的x86-64汇编进行优化，每个内核经过10万次差异模糊测试验证：
内核 AI策略 加速比 判决
Base64解码 SSSE3无查找表的pshufb查找 4.8–6.3x AI胜出
LZ4快速解码 SSE 16字节匹配复制 ~1.05x AI胜出（边际）
Redis SipHash 重排序的SIPROUND调度 0.97x GCC胜出
Base64胜出原因：GCC无法自动向量化256字节查找表（这是一个聚合模式）。AI用pshufb nibble技巧替代——在一条指令中进行16次并行查找，零次表访问。速度从1.8 GB/s提升至11.6 GB/s。
SipHash失利原因：在纯ALU内核（加法、旋转、异或）上，GCC的调度器已经接近最优。
总共进行了30万次模糊测试，零次不匹配。每个结果只需一条命令即可重现。
最近，我一直在学习基于大型语言模型（LLM）的ReAct架构，以设计软件解决方案。我还参与了这一方法的高规模生产实施，这让我思考过去构建的所有应用程序。
理论上，任何一个应用都可以使用ReAct架构来实现，但我仍在思考何时使用这种架构是合理的，何时又不合适。一些应用显然受益于LLM支持的推理，特别是那些业务逻辑繁重且频繁变化的应用。在这些情况下，更新提示可能替代代码更改，从而使产品团队能够直接影响系统行为，而无需工程师的参与。
另一方面，静态数据处理管道似乎不适合这种架构。当逻辑稳定且确定时，LLM推理的开销和不可预测性并不会带来价值。最佳应用场景似乎是业务规则快速演变的应用，而维护传统代码的成本超过了提示工程的复杂性。