2作者: pavelparma7 个月前原帖
嗨,HN!我是Pelyos的开发者,这是一款简约的任务管理应用,旨在帮助个人减轻日常压力,提高思维清晰度。 我在面对不断增长的冗长待办事项清单时感到不堪重负,因此开发了Pelyos。我希望能有一个基于时间线的、简单且更具意识的工具,而不是一个复杂的团队工具或杂乱的应用。 我非常希望能听到你们的反馈,了解哪些地方运作良好,哪些地方让人困惑,以及哪些功能能让这个应用对你们更有帮助。目前我正在独立开发这个项目,希望能真正为知识工作者、创始人和生产力爱好者提供帮助。 感谢你们的关注!
2作者: sarabande7 个月前原帖
我有一个现有的手写知识库,其中包含应用程序的截图,还有一个包含标准CI/CD管道的代码库,以及一个根据OpenAPI规范自动生成文档的API。<p>现在有没有方便的方法将软件串联起来,以便在新的代码库提交时,产品文档(包括截图)能够完全自动生成?有没有人尝试过一些工具链,包括付费工具,能够在实际应用中成功运行?
1作者: KaoruAK7 个月前原帖
我开发了一种新的公钥加密方案(DIAC),该方案使用多维高精度复杂密钥空间和模块化陷门函数,以实现超高熵和量子抗性。代码、基准测试和研究论文(PDF)均为开源:<a href="https:&#x2F;&#x2F;osf.io&#x2F;mvkcq&#x2F;" rel="nofollow">https:&#x2F;&#x2F;osf.io&#x2F;mvkcq&#x2F;</a> 欢迎反馈、提问或进行密码分析!
1作者: knrz7 个月前原帖
我已经构建AI系统一段时间了,但总是遇到同样的问题——提示工程感觉就像是字符串拼接的地狱。每一个复杂的提示都变成了维护的噩梦,充斥着f-strings和模板字面量。 所以我构建了LLML——可以把它想象成提示的React。正如React是数据 => UI,LLML则是数据 => 提示。 问题: ```python # 我们都写过这样的代码... prompt = f"角色: {role}\n" prompt += f"上下文: {json.dumps(context)}\n" for i, rule in enumerate(rules): prompt += f"{i+1}. {rule}\n" # 解决方案: from zenbase_llml import llml # 通过组合数据来构建提示 context = get_user_context() prompt = llml({ "角色": "高级工程师", "上下文": context, "规则": ["永远不要跳过测试", "始终审查依赖"], "任务": "安全地部署服务" }) # 输出: <角色>高级工程师</角色> <上下文> ... </上下文> <规则> <规则-1>永远不要跳过测试</规则-1> <规则-2>始终审查依赖</规则-2> </规则> <任务>安全地部署服务</任务> ``` 为什么使用类似XML的格式?我们发现LLM在解析具有明确边界的结构化格式(<tag>content</tag>)时,比JSON或YAML更可靠。编号列表(<规则-1>,<规则-2>)可以防止顺序混淆。 在Python和TypeScript中可用: ```bash pip/poetry/uv/rye install zenbase-llml npm/pnpm/yarn/bun install @zenbase/llml ``` 对于喜欢冒险的人,还有实验性的Rust和Go实现 :) 主要特点: ```plaintext - ≤1个依赖 - 可扩展的格式化器系统(为你的领域对象创建自定义格式化器) - 100%测试覆盖(TypeScript),92%(Python) - 所有语言实现的输出一致 ``` 格式化器系统特别好用——你可以覆盖任何数据类型的序列化方式,使处理特定领域对象或敏感数据变得简单。 GitHub: [https://github.com/zenbase-ai/llml](https://github.com/zenbase-ai/llml) 希望听到其他人是否也遇到过类似的提示工程挑战,以及你们是如何解决的!
1作者: bmahir7 个月前原帖
注册人数上升,月经常性收入(MRR)增长,因此我们认为一切运转良好。<p>市场营销部门说是LinkedIn的功劳,销售部门则认为是外部拓展,产品团队则指向新的用户引导流程。<p>每个人都在争功,但没有人能提供证据。<p>我们在盲目操作,无法将收入与真实来源联系起来。<p>kruxel.com解决了这个问题。<p>它追踪每一美元,从首次接触到最终付款,涵盖广告、产品和销售。一个提示可以显示出究竟是谁推动了结果。
34作者: ayaros7 个月前原帖
这是我用原生 JavaScript 编写的一个网页操作系统,它的外观类似于苹果 Lisa 办公系统(1983-1985),并受到其他同时期的影响,同时还进行了额外的改进和功能扩展。目前它处于 alpha 阶段,远未达到无bug的状态。我一直在等待将其发布到这里,直到它变得相对可用和美观。请注意,Lisa 在桌面隐喻方面比大多数现代图形用户界面更为字面化——一些重要的区别在自述文件中提到。 这是一个用 JavaScript 完全重建的用户界面;所有内容都渲染到一个单一的画布元素上。这不是一个 CSS 主题,也不是移植到 JavaScript 的模拟器。代码中没有任何部分是由苹果公司编写的。我很乐意在评论中进一步详细说明,但简而言之,整个用户界面是使用 JavaScript 对象在 DOM 外部定义的。因此,每个界面元素——菜单、窗口、控件,甚至字体——都是从头开始重建的。没有字体文件——我编写了自己的排版系统,支持组合多种文本样式,并实时生成新的字形变体。 我做出的许多技术决策都是出于希望在每个浏览器中都能保持相同外观的考虑。用 DOM 和 CSS 实现这一点更难,因此我尽可能将逻辑移到 JavaScript 中。此外,项目中唯一不属于原生 JavaScript 和标准网页 API 的部分是 Gulp 工具包,我将其用作压缩/构建工具。这个项目没有使用任何 vibe 编码! 这个系统基于80年代的用户界面,不适合在手机上良好运行。如果你坚持要以这种方式运行,请在偏好设置应用的触摸屏设置面板中启用触控板模式。为了获得最佳效果,请将其安装为渐进式网页应用(PWA)(添加到主屏幕)。另外,在 Android 上存在一些奇怪的 bug;原生触摸屏键盘目前无法使用,并且在拖动窗口时光标存在问题。 我意识到目前在 LisaGUI 中可做的事情不多;我有一个很长的额外功能和应用程序的列表,将在未来添加。我已经在这个项目上工作了一段时间,期待听到大家的反馈,并回答有关它的问题。