返回首页
最新
我36岁，单身，目前失业，和父母住在我的祖国。我正处于一个可能决定我未来十年生活的关键时刻。我在两条完全不同的道路之间挣扎，面临着不同类型的安全感选择。
选项A：搬到南欧（葡萄牙）
收入：一份低技能的远程工作（内容分析），夜班（太平洋时间），薪资约为1100欧元。我还有一些被动收入来补充。
生活方式：在一个小型的葡萄牙城镇中住在一间单间或小公寓，租金大约为800欧元。
前景：这次搬迁并不是为了某个具体的职业目标或护照，而是为了更高的生活标准、安全感以及西欧稳定的社会环境。
权衡：我将远离年迈的父母。我将从事一份没有技能的工作，这份工作无法积累职业资本，可能在36岁时仍住在单间，这在夜班期间可能会感到孤独。
选项B：留在我的祖国（土耳其安卡拉）
工作与安全：为一家中小企业担任财务/会计职位。我在这里拥有自己的公寓，因此没有住房成本。
职业发展：追求CPA等效的认证。这需要三年的实习和考试承诺，最终获得法律签字权，并在积累足够的经验和人脉后能够开设自己的事务所。
背景：土耳其面临经济不稳定、高通胀和政治动荡。
权衡：虽然我可以靠近父母并建立一个受保护的职业头衔，但我将留在一个高压力、不确定的环境中。
财务负担：
我已经为选项A的搬迁过程花费了大约1万欧元（签证、顾问等）。
困境：
一条道路提供了在一个挣扎且不稳定国家的声望高、抗衰退的职业。另一条道路则在一个稳定的国家提供简单、舒适的生活，生活标准“还不错”，但没有职业发展。
在36岁时，投资三年时间获得专业执照以扎根更明智，还是为了更好的生活质量而跳出舒适区，即使工作是低技能的，你会怎么选择？
谢谢！
我一直遇到同样的问题：想找一些新的观看内容，打开多个流媒体应用，逐个在谷歌上搜索标题，因为这些应用并不会告诉你某个内容是否值得观看。
因此，我创建了“What to Watch”，它汇集了主要流媒体服务的内容，并通过IMDb和社区评分将发现过程简化为简单的“观看”或“跳过”决策。
自高中以来我就没有写过代码——这个项目是在大约400次迭代中使用Claude和Replit构建的。
目前还处于早期阶段，我主要在尝试了解人们是如何决定观看什么的，以及这个使用场景的广泛性。非常希望能得到HN社区的反馈。
大家好，
我们一直在思考当前移动AI助手的一个核心局限性：
大多数系统（例如，Apple Intelligence、Google Assistant风格的集成）依赖于预定义的架构和协调的API。应用程序必须明确实现助手的规范。这限制了可扩展性，并使生态系统受到严格控制。
另一方面，基于图形用户界面的代理（例如，AppAgent、AutoDroid、droidrun）依赖于屏幕截图和无障碍功能，这虽然赋予了广泛的能力，但能力边界却较弱。
因此，我们构建了Mobile-MCP，这是一个基于Android的模型上下文协议（MCP）实现，使用了Intent框架。
关键思想：
- 应用程序在其清单中声明MCP风格的能力（使用自然语言描述）。
- 基于大语言模型（LLM）的助手可以通过PackageManager自主发现设备上所有暴露的能力。
- LLM选择要调用的API，并根据自然语言描述生成参数。
- 调用通过标准的Android服务绑定/Intent进行。
与Apple/Android风格的协调集成不同：
- 没有预定义的动作领域。
- 每个助手没有集中式架构。
- 不需要每个助手的自定义集成。
- 工具可以动态添加并独立演变。
助手不需要事先了解特定应用程序——它在运行时发现并推理能力。
我们已经构建了一个可工作的原型，并发布了规范和演示：
GitHub: https://github.com/system-pclub/mobile-mcp
规范: https://github.com/system-pclub/mobile-mcp/blob/main/spec/mobile-mcp_spec_v1.md
演示: https://www.youtube.com/watch?v=Bc2LG3sR1NY&feature=youtu.be
论文: https://github.com/system-pclub/mobile-mcp/blob/main/paper/mobile_mcp.pdf
我们很想知道大家的看法：
操作系统原生能力广播 + LLM推理是否比固定助手架构或图形用户界面自动化更具可扩展性？
希望能得到从事移动代理、安全、MCP工具或Android系统设计的朋友们的反馈。
嗨，HN，我是ORBTX的创始人。
我创建这个工具是因为大多数天体动力学工具要么是过于简单的网页计算器，要么是看起来像90年代产物的笨重、昂贵的传统软件。我想要创建一个“中间地带”：专业级的轨道计算，快速、直观，并以API为优先。
技术栈：
前端：Next.js 和 React。
3D引擎：使用Three.js（React Three Fiber）进行实时轨迹渲染。
物理：自定义引擎处理经典的双体力学（霍曼转移和双椭圆转移）。
主要挑战：
其中一个主要难点是在浏览器环境中保持天文距离的浮点精度，同时确保3D可视化以60帧每秒流畅运行。目前，我正在优化传播器，以便在未来的更新中处理更复杂的扰动。
目标：
将轨道力学从“Excel工程”转变为现代化、开发者友好的基础设施。可以把它看作是朝着“轨道力学的Figma”迈出的一步。
无需注册，现已开放测试。我很想听听你们对物理实现、API结构或你们发现的任何边缘案例的看法！