最新

我开发了PlayMyMood，这是一个简单的网页应用，可以根据你的心情创建YouTube播放列表。<p>输入一种心情（比如“怀旧但充满希望”或“我想跳舞”），它会生成与之匹配的歌曲。<p>在这里试试：<a href="https://playmymood.com/" rel="nofollow">https://playmymood.com/</a><p>玩得开心！

我正在考虑构建一个基于大型语言模型（LLM）的自动纠正功能，它可以在我输入时纠正语法和自动修正，类似于Grammarly，但更依赖于LLM，并且托管在本地。<p>你接下来打算编写什么代码或者计划构建什么？

HN - 这是Rish。<p>我和Chase进行了两个小时的电话会议，最终决定开发Relaya来实现自动化。对于简单的任务（例如检查某样东西是否在店内、预订不在OpenTable上的餐位等），它会直接完成整个任务，无需拨打任何电话。<p>对于更复杂的任务，例如使用Chase Sapphire积分重新预订已有航班，它会逐步处理所有菜单和等待时间，并直接将你连接到客服代表。<p>至少，它只需与人类对话，将平均20-30分钟的通话时间缩短到2-3分钟（到目前为止已有20多人尝试过）。<p>接下来，我想它也能自动化一定比例的更复杂的电话任务。期待反馈。

我是一名工程负责人，正在思考一些关于人工智能编码助手（如Claude、Cursor等）如何改变……或不改变……我们团队构建软件方式的基本问题，我非常希望能听听社区的看法。 核心矛盾： 我们面临着采用更“初创公司式”方法的压力：更大的合并请求（PR）、更少的任务，个别工程师在AI的帮助下独自承担大量工作。论点是，AI工具使得一个工程师在5-6天内完成过去需要团队并行合作才能完成的工作。 但这似乎违反了核心的软件工程原则： - 知识孤岛：一个人变成了“GraphQL专家”，提交了8,000行的合并请求，几乎不可能进行有意义的审查。 - 缺乏知识共享：初级工程师无法通过参与工作来学习。 - 公交车因子：如果那个人离开了，会发生什么？ - 代码质量：你真的能审查一个8,000行的合并请求吗，还是变成了“先发布，后修复漏洞”？ 反论点： - 初创公司以这种方式迅速发展并取得成功。 - AI工具正在改变一切……也许我们坚持旧做法才是“使用打孔卡片”。 - 客户并不关心我们的内部代码质量，只关心功能是否能发布。 - 如果AI能够处理混乱的代码库，技术债务还有意义吗？ 我目前的想法： AI工具确实让我们更快，但它们是对现有技能的倍增。使用Claude的高级工程师可以在保持良好架构和模式的同时，速度提高10倍。而初级工程师可能只是更快地生成10倍的平庸代码。 我认为AI应该增强我们现有的工作流程……更好的任务规划、更快的小块实现、AI辅助的代码审查……而不是完全用“英雄工程”取代工作流程。 但我确实感到不确定： - 传统的敏捷实践（小任务、并行工作、彻底的代码审查、文档化的待办事项）是否正在变得过时？ - 这是一个真正的范式转变，还是我们只是重新发现了这些实践存在的原因？ - 在AI时代，如何平衡“快速行动”和“构建可维护软件”？ - 如果你能快速发布功能并让客户满意，代码质量还重要吗？ 背景： - 团队约有20名工程师，分为3个小组。 - 使用Claude Code、Cursor等工具。 - 来自领导层的压力，要求快速采用这种方法进行大规模实施。 - 一些工程师仍未有效（或根本未）使用AI工具。 有没有人成功地驾驭过这一转型？在2025年，使用这些工具的“良好”软件工程是什么样的？我是在固守过时的做法，还是“快速行动、大合并请求、后顾质量”的方法确实存在真实风险？

嘿，HN社区， 在我非常有限的空闲时间里，我一直在开发Pathwave.io——一个为人工智能自动化添加手动审批步骤的工具。 我今天发布的第一个版本专注于这个手动审批流程——目前还没有支付功能，只提供安全的“批准/拒绝”操作，可以通过我们的API从你的AI或后端触发。你可以在这里查看文档： [https://web.pathwave.io/docs](https://web.pathwave.io/docs) 它的工作原理如下： * 你的AI或应用通过我们的API发送审批请求 * 用户在Pathwave移动应用中收到推送通知 * 他们可以实时进行批准或拒绝 * 你的系统会立即获得结果 我们的目标是为AI操作创建一个信任层——首先是简单的审批，之后再扩展到金融和高风险操作。 我非常希望能得到HN社区的反馈，特别是在以下方面： * 你希望AI“先询问”的使用场景 * 对文档中开发者体验的看法 * 在扩展到支付集成之前的建议 感谢你的关注——你可以在这里试用或阅读快速入门指南：[https://web.pathwave.io/docs](https://web.pathwave.io/docs) —— Felipe

写这个是为了让我的框架保持安静（或者至少在必要时保持一个恒定的噪音水平）。你的体验可能会有所不同，但我真的很喜欢大部分时间关闭风扇。