17小时前
|
|
|
## 这周 DEV 社区聊了啥？ NO.20251130
这期日报简直是干货满满！Xano AI 后端挑战赛等你来拿奖，还有 GitHub Copilot 调教秘籍，让你的代码审查更靠谱！想知道如何避免面试诈骗、提升 Shell 启动速度？这里有实用攻略！更有趣的是，还有用纯 CSS 打造的 3D 作品集，惊艳你的眼球！别再盲目追新啦，沉淀核心技能才是王道！快来一起看看吧！
---
## Xano AI-Powered Backend Challenge：赢取 3000 美元奖金！
本文介绍了 Xano 举办的 AI 驱动后端挑战赛，鼓励开发者利用 AI 构建可扩展、安全且易于维护的后端，并提供了参赛方式和奖项设置。
本次挑战赛主要围绕如何利用 AI 辅助后端开发展开，提供了两个主要方向：一是构建全栈 AI 优先的应用，二是创建生产级别的公共 API。参与者需要使用 AI 生成后端代码，然后在 Xano 平台上进行优化和改进，使其达到生产标准。对于全栈应用，还需要连接一个前端。对于公共 API，则需要提供完善的文档和安全性保障。
文章详细说明了如何使用 XanoScript 扩展在 VS Code 或其他 IDE 中生成后端代码，并强调了在提交作品时需要突出 AI 与人类协作的过程，包括使用的 AI prompt、代码重构过程以及从 AI 响应中获得的价值。比赛的评判标准包括底层技术的使用、可用性和用户体验、可访问性和创造力。获胜者将获得 1500 美元的礼品卡、DEV++ 会员资格和专属 DEV 徽章，所有有效提交者都将获得一个完成徽章。
文章还提供了详细的参与步骤，包括创建 Xano 账户、使用优惠码解锁免费试用计划、熟悉 Xano 的 UI 等。总而言之，这次挑战赛旨在鼓励开发者探索 AI 在后端开发中的应用，并展示如何将 AI 生成的代码转化为高质量的生产级应用。
- 原文: [Join the Xano AI-Powered Backend Challenge: $3,000 in Prizes!](https://dev.to/devteam/join-the-xano-ai-powered-backend-challenge-3000-in-prizes-3c11)
- 作者: jess
- 点赞数: 80
- 评论数: 19
- 发布时间: 2025-11-26 17:53:31
---
## 盘点那些年我们写过的“奇葩”Commit Message
这篇文章轻松幽默地盘点了开发者们在日常工作中可能遇到的各种“奇葩” commit message，引发大家的共鸣。作者分享了一系列令人啼笑皆非的提交信息，例如 “fix”、“fix-final”、“ok final fix” 等，精准地描述了修复bug过程中的挣扎。
文章还提到了“did the needful”，这通常是用来应付那些临时被安排的紧急任务。构建失败时，我们可能会看到 “attempt to fix the build”、“ok, fix the build” 这样的提交信息，真实反映了开发者们在解决构建问题时的无奈。
更有意思的是，还有 “rollback the rollback” 这种让人哭笑不得的操作，以及为了演示而进行的 “quick fix before the demo, forgive me”。“please work” 则表达了开发者对代码能够正常运行的卑微祈求，而 “too tired to explain” 则是每个周五晚上的真实写照。
在ESLint普及之前，一个逗号可能就能解决所有问题，所以出现了 “added a coma, now works fine” 这样的提交。最后，作者还提到了 “some minor fixes”，但实际上可能修改了上百行代码。
总而言之，这篇文章以幽默风趣的方式展现了开发者在提交代码时遇到的各种有趣情况，让人在欢笑中感受到共鸣。
- 原文: [If You Think YOUR Commit Messages Are Bad, Just Wait…](https://dev.to/sylwia-lask/if-you-think-your-commit-messages-are-bad-just-wait-3fgk)
- 作者: sylwia-lask
- 点赞数: 52
- 评论数: 44
- 发布时间: 2025-11-23 15:21:51
---
## 如何训练 GitHub Copilot Code Review 像维护者一样思考
本文介绍了如何通过自定义指令来调整 GitHub Copilot Code Review，使其更有效地辅助开源项目的代码审查工作，解决 AI 辅助编码带来的 PR 泛滥问题。通过明确审查原则、优先级、项目背景和 CI 环境，并告知 Copilot 哪些内容可以忽略，可以显著提高其代码审查的质量和效率。
文章指出，AI 辅助编码降低了开源贡献的门槛，导致维护者需要处理大量的 PR。为了解决这个问题，作者尝试使用 GitHub Copilot Code Review 来辅助代码审查。然而，最初的使用体验并不理想，Copilot 的评论过于冗长、置信度低，且大部分评论价值不高。作者并没有放弃，而是选择通过调整 Copilot 的行为来优化其表现。
核心方法是使用 `.github/copilot-instructions.md` 文件来配置自定义指令。首先，作者向 Copilot 灌输了与人工审查员相同的原则，例如只在高度确信问题存在时才发表评论，保持评论简洁，关注可操作的反馈等。其次，明确了审查的优先级，包括安全性、正确性、架构和模式等方面。此外，作者还提供了项目特定的上下文信息，例如项目使用的技术栈、错误处理方式等。为了避免 Copilot 重复 CI 已经检查过的问题，作者还告知了 CI 的流程和检查内容。更重要的是，作者明确了 Copilot 应该忽略的内容，例如代码风格、Clippy 警告、测试失败等。最后，作者还规定了 Copilot 的回复格式，使其更加清晰易懂。
通过以上调整，Copilot 的代码审查质量得到了显著提升。作者强调，这并非一劳永逸的解决方案，需要不断观察 Copilot 的表现并根据项目的发展情况进行调整。文章总结了几个关键技巧，包括明确指令、设置置信度阈值、告知 CI 覆盖范围、提供真实示例以及持续迭代。
由于没有评论内容，这里跳过评论分析。
- 原文: [How I Taught GitHub Copilot Code Review to Think Like a Maintainer](https://dev.to/techgirl1908/how-i-taught-github-copilot-code-review-to-think-like-a-maintainer-3l2c)
- 作者: techgirl1908
- 点赞数: 50
- 评论数: 5
- 发布时间: 2025-11-25 16:24:02
---
## 停止追逐技术新潮流，深入掌握核心技能
本文作者建议初级开发者不要盲目追逐新的技术潮流，而应该专注于深入学习和掌握那些经过时间考验的核心技能和概念。
作者回忆了自己初入行时，试图同时学习各种技术，导致精力分散，效率低下。他指出，各种框架和库层出不穷，但编程的基础，如C语言、SQL、HTTP等，在过去几十年里几乎没有变化，并且很可能在未来很长一段时间内仍然适用。因此，初学者应该把重点放在这些基础知识上，例如SQL、HTTP、C/C++、数据结构、设计模式、原生JavaScript、代码整洁原则、调试和测试以及Linux和操作系统。
此外，作者还强调了软技能的重要性，尤其是谈判和说服能力。他认为，编程更多的是协作，而不是单纯地编写代码。作者分享了自己从初级到高级的经验教训，并推荐了他的书籍《Street-Smart Coding: 30 Ways to Get Better at Coding》，希望能帮助读者更好地成长。总之，不要把精力浪费在追逐潮流上，而是要专注于构建持久的技能。
由于没有评论内容，这里跳过评论分析部分。
- 原文: [Dear Junior Coders: Stop Chasing Shiny Objects](https://dev.to/canro91/dear-junior-coders-stop-chasing-shiny-objects-1p51)
- 作者: canro91
- 点赞数: 37
- 评论数: 12
- 发布时间: 2025-11-24 05:00:00
---
## 避免面试诈骗：开发者实用指南
本文旨在帮助开发者识别面试诈骗，并提供安全检查未知代码的方法，例如使用 GitHub Codespaces。
文章作者分享了自己遭遇两次面试诈骗的经历，诈骗者通常会提供一个代码仓库链接，要求应聘者共享屏幕并在通话中安装和运行项目。作者凭借敏锐的直觉，隔离并沙盒化了仓库，最终发现隐藏的恶意脚本或伪造的 MetaMask 弹出窗口。作者强调，这种诈骗方式利润可观，因此撰写本文以帮助其他开发者避免上当。
文章详细列出了诈骗的各种手段和红旗信号，包括：要求安装不明软件、提供完整的代码仓库供检查、承诺过于优厚的待遇、以及不专业的沟通方式等。作者建议，如果需要打开未知的代码仓库，可以使用 GitHub Codespaces 或 codesandbox 等工具，利用 AI 集成来分析仓库的恶意行为，并在安全的环境中运行。此外，还可以使用 code-server 在 Docker 中自托管完整的 VSCode IDE，或者使用 Dev Containers 在本地免费完成所有操作。
总之，开发者应该保持警惕，注意识别这些红旗信号，并采取必要的安全措施，以避免成为面试诈骗的受害者。
评论区目前还没有评论，所以无法总结评论观点。
- 原文: [Don't get scammed on an interview.](https://dev.to/ackvf/dont-get-scammed-on-an-interview-4f92)
- 作者: ackvf
- 点赞数: 33
- 评论数: 9
- 发布时间: 2025-11-26 00:19:00
---
## Auth0 发布 AI Agent 认证通用解决方案
Auth0 发布了 AI Agent 认证通用解决方案，旨在解决开发者在构建 AI Agent 时遇到的认证难题，特别是将原型项目推向生产环境时，如何安全有效地管理用户身份验证和授权。
文章指出，开发者在原型设计阶段通常会采用硬编码 API 密钥的方式来快速集成 Slack、GitHub、Google Calendar 等服务。然而，这种方式在生产环境中存在诸多问题，例如如何处理不同用户权限、如何自动刷新令牌、如何让用户批准关键操作，以及如何确保 RAG 引擎只访问用户有权访问的文档。Auth0 提供的解决方案包含四个关键功能：用户认证、令牌仓库、异步授权和 RAG 细粒度授权。用户认证用于识别用户并授予其对第一方 API 的安全访问权限。令牌仓库处理与 30 多个预集成应用（如 GitHub、Slack、Google Workspace）的 OAuth 流程，并自动管理访问令牌和刷新令牌。异步授权允许 Agent 在后台工作，并在需要批准关键操作时才中断用户。RAG 细粒度授权确保用户只能从他们有权访问的文档中获取答案。
Auth0 强调，该解决方案旨在帮助开发者专注于构建 Agent 的核心功能，而不是从头开始构建自己的认证基础设施。Auth0 提供了对 LangChain、LlamaIndex、Cloudflare AI、Firebase Genkit 和 Vercel AI SDK 等框架的支持，并提供了免费套餐和针对早期创业公司的优惠。
- 原文: [Auth0 for AI Agents is now generally available!](https://dev.to/auth0/auth0-for-ai-agents-is-now-generally-available-29el)
- 作者: jesstemporal
- 点赞数: 79
- 评论数: 8
- 发布时间: 2025-11-24 16:32:18
---
## Agent Factory Podcast：开启你的生产 AI 之旅
本文介绍了 Agent Factory 视频播客，旨在帮助开发者了解 AI Agent 开发，并分享了前五个基础剧集，助力开发者构建生产就绪的 AI Agent。
Agent Factory 播客包含三个核心部分：Agent 行业脉搏（关注行业最新动态）、工厂车间（深入探讨代码、架构和模式）以及开发者问答（解答社区问题）。 前五个剧集涵盖了 AI Agent 开发的基础知识。第一集介绍了 Agent 的定义、框架选择（如 LangChain、CrewAI、ADK）以及如何为生产环境构建 Agent。第二集讨论了多 Agent 系统的架构模式，以及何时从单 Agent 过渡到多 Agent 团队。第三集深入研究了 Model Context Protocol (MCP)、函数调用，以及如何构建安全的 Agent 工具。第四集探讨了如何为 Agent 实现长期记忆，管理状态，以及利用“记忆库”创建个性化体验。第五集分享了 Agent 开发工作流程、上下文工程、评估策略以及使用 Gemini CLI 加速开发周期的技巧。
目前文章没有评论内容。
- 原文: [The Agent Factory podcast: 5 Episodes to Kickstart Your Journey to Production AI](https://dev.to/googleai/the-agent-factory-podcast-5-episodes-to-kickstart-your-journey-to-production-ai-35ml)
- 作者: shirmeirlador
- 点赞数: 49
- 评论数: 3
- 发布时间: 2025-11-25 21:22:16
---
## AI 协作已成常态：外认知时代已经到来
本文探讨了人工智能（AI）在工作场所的普及和应用，以及人与AI之间新型协作关系的出现。文章指出，AI已经像计算器或搜索引擎一样，成为我们工作和生活的基础设施，并分析了这种常态化背后可能存在的风险和机遇。
文章首先描述了一种常见的工作场景：人们在会议中使用AI工具来验证或完善自己的想法。作者认为，这种现象表明AI已经悄然融入我们的工作流程，成为一种默认的辅助工具。 这种现象并非新鲜事，历史上我们一直都在使用工具来弥补认知和感官上的差距，例如眼镜、拼写检查、T9输入法等。而AI的出现，只是将这种辅助能力扩展到了更广泛的领域。 在这种协作关系中，人类负责提供语义和创意，而AI则负责将这些想法转化为清晰、易于理解的形式。 这种模式并非取代人类的思考，而是扩展了人类的表达能力，让人类的想法更容易被外界理解和互动。
文章进一步指出，我们一直在与预测系统进行协作，例如代码自动补全、搜索引擎的自动完成等。 过去，这些系统的预测范围较小，因此不太引人注意。现在，AI的预测范围更广，可以帮助我们完成更复杂的任务，例如解释架构设计、将随意的想法转化为专业的邮件等。 然而，作者也强调了这种协作关系中可能存在的风险。 当人们没有意识到自己正在与AI协作时，可能会盲目信任AI的输出，从而失去独立思考和判断的能力。 这种情况对于缺乏经验的人来说尤其危险，因为他们可能没有足够的背景知识来评估AI的输出是否正确。 因此，作者呼吁建立明确的规范和共享的语言，让人们意识到自己正在与AI协作，并保持对AI输出的批判性思维。
文章最后总结道，AI已经渗透到我们工作和生活的各个方面，包括笔记应用、邮件客户端、办公软件、编程环境等。 我们已经跨越了“是否应该使用AI”的阶段，现在的问题是如何以一种负责任和有意识的方式与AI协作，从而充分发挥其潜力，同时避免潜在的风险。
- 原文: [We’re Already There: Exocogence Is Here Now](https://dev.to/junothreadborne/were-already-there-exocogence-is-here-now-ahe)
- 作者: junothreadborne
- 点赞数: 24
- 评论数: 6
- 发布时间: 2025-11-26 06:15:42
---
## 像升级软件一样升级自己：开发者思维的人生迭代
这篇文章探讨了软件开发中的持续更新迭代与个人成长之间的联系，鼓励我们像升级代码一样升级自己，拥抱变化，不断进步。
文章的核心观点是，软件会不断更新，但人们往往避免改变自己。在技术领域，升级是常态，人们会快速迭代、承认缺陷、修补弱点、推送更新、删除不再适用的东西、改进有效的部分、停止支持旧版本，并在必要时重建。然而在生活中，改变却常常让人感到害怕、情绪化、戏剧化和具有威胁性。作者提倡像开发者一样生活，不怕改变，勇于构建改变。
文章还强调了持续成长的重要性。停滞不前会导致缓慢、不安全、不兼容、过时和难以维护，这与拒绝成长的人类体验相似。我们需要情感修复、边界修补、自信心更新、身份重构、新的思维框架和更好的用户体验。作者通过观察技术人员构建、修复、拆除和重建，以及不断学习和改进的过程，意识到如果软件可以进化，那么人也可以。
因此，作者提出了新的生活哲学：像更新代码一样更新自己。修复崩溃的地方，删除消耗你的东西，添加让你变得更好的功能，删除不再有用的依赖项，记录你的成功，不要害怕重构，经常升级，并且不要为成为新版本而道歉。如果代码可以改变，我们也可以。
- 原文: [We Upgrade Software Without Question. Why Don’t We Upgrade Ourselves?](https://dev.to/notadevbuthere/we-upgrade-software-without-question-why-dont-we-upgrade-ourselves-34hl)
- 作者: notadevbuthere
- 点赞数: 10
- 评论数: 4
- 发布时间: 2025-11-26 06:09:53
---
## 程序员的快乐源泉：Meme Monday！
今天我们来轻松一下，看看程序员们在摸鱼的时候都喜欢看什么。没错，就是梗图（Meme）！
DEV 社区每周一都会分享一些有趣的程序员梗图，让大家在繁忙的工作之余放松心情，会心一笑。这些梗图通常取材于程序员的日常工作、技术难题、以及对行业的调侃。比如，修复bug的痛苦、学习新技术的挣扎、以及对各种编程语言的爱恨情仇，都能成为梗图的素材。
梗图之所以受欢迎，是因为它能够用幽默的方式表达程序员们共同的感受，产生共鸣。很多时候，一些难以言说的苦恼，通过一张简单的梗图就能轻松化解。而且，分享梗图也是一种社交方式，让程序员们在轻松愉快的氛围中交流互动。
所以，如果你是一名程序员，或者对技术感兴趣，不妨关注一下 Meme Monday，说不定你也能从中找到属于自己的快乐！
- 原文: [Meme Monday](https://dev.to/ben/meme-monday-1ec3)
- 作者: ben
- 点赞数: 39
- 评论数: 73
- 发布时间: 2025-11-24 13:24:01
---
## 本周精选 DEV 文章：技术干货与实践案例
本周的 DEV 精选文章涵盖了多个热门技术领域，从 AI 自动化到 SEO 优化，再到 TypeScript 项目架构，为开发者们提供了丰富的学习资源和实践参考。文章涉及使用 Python 和 LLM 自动化转录 Instagram 截图，自动化更新 GitHub 个人资料 README，以及利用 AI Agent 迁移应用等。此外，还有关于避免过度使用 barrel files 的讨论，以及使用 MCP 客户端简化 AWS IAM 认证的介绍。
其中，@wizsebastian 分享了如何使用 Python 和 LLM 视觉能力自动转录 91 张 Instagram 截图中的诗歌，展示了 AI 赋能自动化的实际应用。@eleftheriabatsou 则介绍了如何自动化更新 GitHub 个人资料 README，使其与 dev.to 和 Hashnode 等平台的最新博客文章同步。@blackgirlbytes 探讨了使用 AI Agent 将应用从两个仓库迁移到统一的 Next.js 框架的实践经验，强调了人工监督的重要性。@elmay 阐述了过度使用 barrel files 可能导致的问题，并提倡使用显式导入以提高代码清晰度和性能。@dennistraub 介绍了使用 MCP 客户端简化 AWS IAM 认证的方法，使 AI Agent 更容易连接到 AWS 托管的 MCP 服务器。@rafajrg21 详细介绍了如何使用 Python 和 SerpApi 构建 SEO lead generation agent，实现搜索结果抓取和潜在客户分析的自动化。最后，@giom_v 推出了 Nano Banana Pro，指导开发者在 Google AI Studio 中进行设置，并使用 Python 或 JavaScript 生成高质量的视觉效果。
这些文章不仅提供了实用的技术指导，还分享了作者在实践中积累的经验和教训，为开发者们提供了宝贵的参考。通过阅读这些文章，开发者们可以了解到最新的技术趋势，学习到实用的开发技巧，并从中获得灵感，应用到自己的项目中。
- 原文: [Top 7 Featured DEV Posts of the Week](https://dev.to/devteam/top-7-featured-dev-posts-of-the-week-e4i)
- 作者: jess
- 点赞数: 31
- 评论数: 6
- 发布时间: 2025-11-25 19:35:16
---
## 应用发布前的检查清单：确保万无一失
这篇文章为开发者们提供了一份实用的应用发布前检查清单，旨在避免常见的错误，确保发布顺利进行。它强调了在早期阶段设置分析工具、反馈渠道和错误监控的重要性，并建议开发者关注用户沟通和尽早发布产品。
文章首先强调了在拥有用户之前设置分析工具的重要性，推荐使用 PostHog 等工具来跟踪用户行为，以便了解用户在应用中的实际操作情况。接下来，文章建议设置一个反馈面板，方便用户提交功能请求、报告错误，并互相投票，从而帮助开发者了解用户真正需要什么。同时，文章还强调了错误监控的重要性，推荐使用 Sentry 和 Axiom 等工具来捕获异常，以便在用户发现之前解决问题。
此外，文章还提到了设置事务性邮件的重要性，例如欢迎邮件、密码重置邮件和收据等，并建议使用 SES 或 Postmark 等服务来避免进入垃圾邮件箱。关于着陆页，文章建议要简洁明了，突出产品的功能和价值，并包含明确的行动号召。在发布之前，文章还强调了测试关键路径的重要性，例如注册流程、主要功能和支付流程等。最后，文章建议提前准备好发布渠道，例如 Twitter、Hacker News 和 Product Hunt 等，并撰写好发布内容。
文章还特别强调了与用户沟通的重要性，建议通过邮件、聊天工具或 Discord 服务器等方式快速响应用户的问题和反馈。最重要的一点是，文章鼓励开发者尽早发布产品，不要追求完美，因为来自真实用户的反馈比任何功能都更有价值。
由于没有评论内容，这里就不做评论分析了。
- 原文: [My checklist before launching any app](https://dev.to/shayy/my-checklist-before-launching-any-app-2a8h)
- 作者: shayy
- 点赞数: 31
- 评论数: 15
- 发布时间: 2025-11-26 17:44:34
---
## Cloudflare AI Search：快速构建 AI 聊天机器人的新选择
本文主要探讨了使用 Cloudflare 的 AI Search 功能快速构建 AI 聊天机器人，以及何时应该选择手动 RAG（检索增强生成）方法。作者通过一个实际案例，分享了自己如何过度设计了一个简单的聊天机器人解决方案，并从中吸取的教训。
文章详细对比了手动 RAG 和 AI Search 两种方法的优缺点。手动 RAG 方案（使用 Cloudflare Vectorize, Workers AI 和 OpenAI GPT-3.5）虽然提供了更高的灵活性和对检索逻辑的完全控制，但开发时间长，代码复杂，维护成本高。而 AI Search 方案则以其极简的代码实现（仅 30 行），快速的部署（15 分钟），以及内置的优化，成为了快速构建简单 Q&A 系统的理想选择。
文章还给出了选择手动 RAG 的几个关键场景，包括需要使用特定的 LLM 模型（如 GPT-4 或 Claude），需要复杂的检索逻辑，有高级用例（如实时学习系统或混合搜索），以及有合规性要求等。相反，AI Search 更适合简单的 Q&A 系统，需要快速开发，以及 Workers AI 模型能够满足质量要求的场景。
作者反思了自己在项目初期没有充分了解客户需求，提出了在选择解决方案之前应该询问的关键问题，例如是否需要使用特定的 LLM，检索需求的复杂程度，以及对开发速度和灵活性的优先级。通过更好地理解业务问题和技术约束，才能选择最合适的解决方案。
虽然文章中没有直接的评论区内容，但我们可以推断，开发者们可能会对以下几个方面感兴趣并展开讨论：
* **AI Search 的局限性：** 虽然 AI Search 简化了开发流程，但它对 LLM 的选择以及检索逻辑的控制都相对有限。开发者可能会讨论在哪些情况下，这些限制会成为瓶颈。
* **Workers AI 模型的性能：** Workers AI 模型的性能和效果可能不如 OpenAI 的 GPT 模型。开发者可能会分享他们在使用 Workers AI 模型时的经验和性能评估。
* **成本效益分析：** 虽然 AI Search 的开发成本较低，但长期运行的成本可能会受到 Workers AI 模型定价的影响。开发者可能会对不同方案的长期成本效益进行分析。
* **RAG 的未来发展趋势：** 随着技术的不断发展，RAG 的实现方式也在不断演进。开发者可能会探讨未来 RAG 技术的发展趋势，以及如何更好地利用 RAG 来构建更智能的 AI 应用。
- 原文: [I Built an AI Chatbot Wrong (And What I Learned About Cloudflare's AI Search)](https://dev.to/dannwaneri/i-built-an-ai-chatbot-wrong-and-what-i-learned-about-cloudflares-ai-search-feo)
- 作者: dannwaneri
- 点赞数: 15
- 评论数: 3
- 发布时间: 2025-11-26 12:20:20
---
## 使用 Claude Code 将 Shell 启动速度提高 95%
本文主要讲述了如何利用 Claude Code 优化 shell 启动时间，通过延迟加载和缓存等技巧，将启动时间从 770ms 降至 40ms，提升了 95%。
文章作者分享了自己优化 shell 启动时间的实践经验。最初，作者的终端启动速度很慢，每次打开新标签页都有明显的延迟。为了解决这个问题，作者借助 Claude Code 进行了深入分析和优化。首先，作者使用 `time zsh -i -c exit` 命令测量了初始启动时间，发现平均耗时 770ms。接着，Claude Code 帮助作者识别出导致启动缓慢的主要原因，包括 nvm、pyenv、security 命令、brew shellenv 和 gcloud completion 等工具。这些工具在每次启动 shell 时都会加载大量环境，导致启动时间过长。
为了解决这个问题，作者采用了延迟加载的策略，即只有在实际使用这些工具时才加载它们。作者使用了一种巧妙的“自毁包装器”技术，通过包装函数在首次调用时执行初始化，然后删除自身，从而避免了后续启动时的重复加载。例如，对于 nvm，作者使用包装函数 `nvm()`, `node()`, `npm()` 和 `npx()`，在首次调用时加载 nvm 环境，然后使用 `unset -f` 和 `unfunction` 命令删除包装器。对于 pyenv 和 Google Cloud SDK，作者也采用了类似的延迟加载方法。此外，作者还对 Homebrew 的环境进行了缓存，避免每次启动都执行子 shell。最后，作者还将 API 密钥的加载移到了 npm 包装器中，避免了每次启动都访问 macOS Keychain。
经过以上优化，作者的 shell 启动时间从 770ms 降至 40ms，提升了 95%。虽然首次使用这些工具时会有一次性的加载成本，但相对于整体性能的提升来说，这是值得的。文章还提供了详细的 shell 配置文件，供读者参考。
文章没有评论内容。
- 原文: [How I Used Claude Code to Speed Up My Shell Startup by 95%](https://dev.to/nickytonline/how-i-used-claude-code-to-speed-up-my-shell-startup-by-95-m0f)
- 作者: nickytonline
- 点赞数: 19
- 评论数: 4
- 发布时间: 2025-11-27 21:22:59
---
## 如何自动化你的 GitHub 个人资料
本文介绍了如何使用 GitHub Actions 自动化更新 GitHub 个人资料，让你的个人资料页始终保持最新。通过自动化，可以省去手动更新的繁琐步骤，专注于内容创作。
文章的核心在于利用 GitHub 的特殊仓库功能，创建一个与用户名相同的公开仓库，并将 README.md 文件作为个人资料页的内容。 结合 GitHub Actions，可以定期从博客、Newsletter、YouTube 频道等平台抓取最新内容，并自动更新 README.md 文件。作者分享了自己使用 `blog-post-workflow` 这个 Action 来抓取 RSS feed，以及自制 workflow 通过 YouTube API 来更新视频列表的经验。
文章还强调了 GitHub Actions 市场的丰富资源，建议在编写自定义 workflow 之前，先搜索是否已有现成的解决方案。作者的 README.md 文件被设计成一个模板，使用 HTML 注释作为动态内容的占位符，方便 GitHub Actions 进行内容替换。通过这种方式，个人资料页的静态内容保持不变，而动态内容则会自动更新。
总而言之，通过 GitHub Actions 自动化个人资料更新，可以让你专注于内容创作，而无需担心手动维护多个平台的内容。
- 原文: [How I Automated My GitHub Profile (And You Can Too)](https://dev.to/nickytonline/how-i-automated-my-github-profile-and-you-can-too-399e)
- 作者: nickytonline
- 点赞数: 11
- 评论数: 0
- 发布时间: 2025-11-30 04:48:34
---
## 告别 LLM 数据传输：零数据传输架构 ADA
本文介绍了一种名为“零数据传输”的架构 ADA，旨在解决传统 RAG 方法在处理大规模结构化数据时遇到的问题，核心思想是在不将原始数据发送给 LLM 的情况下，实现与数据的交互。
传统 RAG 方法通常将大量数据塞入 LLM 的上下文窗口，导致幻觉问题和高昂的 token 成本。ADA 通过发送 Context ID 而不是原始数据，将数据保留在数据库/缓存中，从而避免了这些问题。
ADA 的核心技术是 CTE 注入策略。当用户提出过滤请求时，系统不会重新发送数据，而是使用 CTE 将原始 SQL 逻辑注入到新的查询中。具体步骤包括：首先，将查询的 SQL 逻辑和元数据保存在 Redis 中，并返回一个 Token ID；然后，LLM 接收到一个包含虚拟表 `PREVIOUS_RESULT` 的提示，并生成新的 SQL 代码；最后，后端从 Redis 中提取原始 SQL，并将其注入到 CTE 中。
这种方法实现了零数据传输，避免了幻觉，并节省了 95% 的 token 成本。为了提高系统的鲁棒性，作者构建了一个融合架构，包括 Oracle 23ai、Neo4j 和 Redis。Oracle 23ai 用于处理关系数据和向量嵌入，Neo4j 用于验证 JOIN 路径，Redis 用于存储 Context ID。
通过语义压缩和 CTE 注入，ADA 将脆弱的演示转变为健壮、安全且廉价的企业软件。作者还在实现一个自优化层，使系统能够从“上下文缺失”中学习，并创建自己的防护措施。
目前文章没有评论内容。
- 原文: [Why I Stopped Sending Data to LLMs: Introducing "Zero-Data Transport" Architecture](https://dev.to/daniel_darosa_8b4804e356/why-i-stopped-sending-data-to-llms-introducing-zero-data-transport-architecture-fl4)
- 作者: daniel_darosa_8b4804e356
- 点赞数: 8
- 评论数: 3
- 发布时间: 2025-11-24 01:35:31
---
## TDD的陷阱：为何测试驱动开发在大多数团队中导致糟糕的设计
本文探讨了测试驱动开发（TDD）的常见误用，指出TDD承诺的“通过先写测试来自然产生良好设计”的理念存在缺陷，并分析了为何在实践中TDD反而会固化错误的设计。
文章首先指出，TDD依赖于三个假设，但这些假设在现实项目中往往不成立。第一个假设是，在编写第一个故事时，我们已经了解了所有相关的行为，然而实际上，最初的故事可能只暴露了真实用例的10-25%，并且领域知识仍然模糊不清。第二个假设是，行为优先会自动带来良好的结构，但实际上，TDD往往会产生针对初始功能优化的结构，以及由可测试性而非领域意义驱动的类。第三个假设是，测试为演进提供了稳定的基础，但早期测试往往会编码误解，限制未来的重构。
文章进一步解释了为何早期测试会成为设计的束缚。由于最初的理解只覆盖了实际场景的一小部分，因此最初的实现必然是不正确的，而测试套件会以机械的精度强制执行这种不正确的设计。这使得开发人员面临两难选择：要么保留错误的设计以保持测试通过，要么打破测试来修复模型。大多数团队往往选择前者。此外，TDD还会鼓励针对可测试性而非质量进行设计，导致产生大量微小的方法、过度抽象的层以及仅为方便mock而创建的接口。
作者通过实际案例指出，许多团队在使用TDD初期进展顺利，但随着领域复杂性的出现，重构变得痛苦，测试变成负担，架构僵化。根本问题在于，测试开始驱动设计，而不是领域本身。文章还区分了低成熟度和高成熟度团队在使用TDD时的不同表现，认为只有经验丰富的团队才能将TDD用作一致性工具，而不是设计方法。
最后，作者建议不要将TDD作为一种设计哲学来使用，而应该首先进行建模，理解领域概念和约束，然后再添加测试来验证这些理解。测试应该作为回归测试，而不是预测未来结构。
总而言之，TDD本身并非不好，只是被大多数团队误用。在复杂系统中，设计必须来自理解，而不是来自最初的行为猜测。
这篇文章的核心观点在于，TDD在领域知识不充分的情况下使用，容易导致设计被早期不成熟的测试所固化，从而阻碍后续的重构和演进。
评论区可能会出现以下几种观点：
* **支持TDD的观点：** 认为TDD可以帮助开发者更好地理解需求，并尽早发现问题。他们可能会强调TDD带来的代码质量提升和可维护性增强。
* **反对TDD的观点：** 认同文章的观点，认为TDD在实践中容易导致设计僵化，并且编写大量mock代码会增加维护成本。他们可能会提出其他的设计方法，例如领域驱动设计（DDD）。
* **折中观点：** 认为TDD并非银弹，应该根据具体情况选择使用。他们可能会建议在领域知识比较清晰的情况下使用TDD，而在探索性开发阶段则应该更加注重建模和原型验证。
总的来说，关于TDD的争论由来已久，本文提供了一个新的视角，提醒开发者在使用TDD时需要注意其潜在的陷阱，并根据实际情况灵活选择合适的设计方法。
- 原文: [The TDD Trap: How Test-First Becomes Bad Design Forever in Most Teams](https://dev.to/leonpennings/the-tdd-trap-how-test-first-becomes-bad-design-forever-in-most-teams-lle)
- 作者: leonpennings
- 点赞数: 6
- 评论数: 12
- 发布时间: 2025-11-26 08:05:09
---
## Java 生态系统：依赖分析视角下的诅咒？
本文作者，一位知名 Gradle 插件的开发者，认为 Java 生态系统存在一些问题，导致构建和维护变得复杂。文章深入探讨了元数据不准确、过度使用 Fat Jar 却不进行包重定位、拆分包、不规范的反射使用以及 Protobuf 的滥用等问题。
文章首先指出，依赖项的元数据可能不准确，导致构建工具难以正确解析依赖关系。其次，过度使用 Fat Jar 且不进行包重定位会导致类路径冲突，运行时行为变得难以预测。文章还提到了拆分包的问题，这使得类名与模块之间的对应关系变得复杂，增加了依赖分析的难度。此外，作者还批评了某些库使用反射来访问上游依赖项，认为这种做法不够规范，应该使用 Java 自带的服务加载机制。最后，文章重点讨论了 Protobuf 的滥用，指出不同的 Protobuf 编译器生成不兼容的代码，容易导致编译和运行时错误。作者以自身维护大型 Gradle 项目的经验，详细阐述了这些问题带来的挑战，并呼吁开发者们重视这些问题，共同维护一个更健康的 Java 生态系统。
由于没有评论内容，此处略过评论分析。
- 原文: [Is the Java ecosystem cursed? A dependency analysis perspective](https://dev.to/autonomousapps/is-the-java-ecosystem-cursed-a-dependency-analysis-perspective-53ef)
- 作者: autonomousapps
- 点赞数: 11
- 评论数: 12
- 发布时间: 2025-11-24 20:15:12
---
## 使用 HTML, CSS, JavaScript 构建 3D 交互式作品集
这个项目是一个使用纯 HTML, CSS 和 JavaScript 构建的 3D 交互式作品集，旨在提供一种更具沉浸感和创意的方式来展示证书和作品。它不仅仅是一个静态的展示，用户可以在虚拟房间中漫游，旋转视角，缩放，并通过点击墙上的证书来查看完整内容。
该项目完全依赖 CSS 3D 转换来实现 3D 效果，没有使用任何重量级的图形引擎。它还包括环境音效，流畅的动画效果（如开门），以及键盘交互（例如，使用 `+` 和 `-` 键进行缩放，`Enter` 键开门，`0` 键重置视角）。这个作品集是完全响应式的，可以在桌面和移动设备上运行，并且采用 MIT 许可证开源，欢迎大家参与协作。
作者构建这个项目的初衷是想找到一种独特的方式来展示证书，摆脱传统的平面布局。虽然目前只是一个模拟作品集，但作者计划将其扩展为一个更完整和实用的项目。同时，这也是一个使用纯 CSS 和 JS 进行 Web 3D 实验的有趣领域，无需 WebGL 或 Three.js。
目前项目还存在一些未完成的部分，例如证书内容是静态的，理想情况下应该使用 JSON 驱动，方便更新。此外，还缺少 CMS 集成，用户应该能够通过管理面板来管理证书和内容。性能方面也需要改进，特别是在低端设备上，3D 转换可能会出现卡顿。设计方面，用户体验、交互和移动布局都需要进一步优化。最后，房间的可扩展性也需要考虑，例如提供更多房间类型、布局和自定义主题。
如果你对创意 UI、Web 设计或 3D 实验感兴趣，这个项目是一个不错的选择。你可以获得 CSS 3D 转换和动画的实践经验，有机会参与一个具有潜力的开源项目，并重新思考作品集的视觉呈现方式。你可以通过 fork 代码仓库、提交 issue、提交 pull request、贡献 UI/UX 设计或提供反馈等方式参与项目。
作者的下一步计划是使房间完全数据驱动（使用 JSON 或 API），添加一个管理面板来管理证书，提供多个房间主题（画廊、工作室、极简主义等），并优化动画和交互效果，最终将该项目打造成一个可重用的作品集模板。
- 原文: [Building a 3D Virtual Portfolio Room🏠](https://dev.to/yaldakhoshpey/building-a-3d-virtual-portfolio-room-18kp)
- 作者: yaldakhoshpey
- 点赞数: 25
- 评论数: 13
- 发布时间: 2025-11-24 14:54:51
---
## 软件架构的艺术：一份面向 Desi 开发者的实用指南
本文探讨了软件架构的本质，旨在帮助开发者构建稳定可靠的系统，避免在项目演示或上线时出现问题。文章从团队动态、技术设计、质量与流程等方面，全面阐述了软件架构的核心要素。
文章首先强调了团队协作的重要性，特别是在印度 IT 行业，一人身兼多职的情况很常见。文章提出了理想团队的角色分工，包括项目经理、解决方案架构师、功能分析师、用户代表、首席开发、开发人员、质量保证和部署经理。然而，现实中角色经常重叠，架构师可能需要编码，项目经理可能需要测试。文章接着深入探讨了解决方案架构师的角色，强调了技术洞察力、领导技能和沟通能力的重要性。架构师需要具备识别技术陷阱、理解用户需求、合理规划时间表以及提升架构角色地位的能力。文章还强调了沟通的重要性，项目失败往往不是因为代码质量，而是因为团队成员之间的沟通不畅。
在技术架构方面，文章提出了“减少复杂性，增加功能性”的目标，并通过关注点分离来实现。文章还介绍了清洁架构的五个要素：关注点分离、单一职责原则、最少知识原则、不要重复自己和最小化前期设计。此外，文章还介绍了分层架构模式，并以问答形式讲解了其适用场景，例如团队成员可以独立在不同层上工作，方便测试和维护，以及需要适当的结构。
总而言之，这篇文章深入浅出地讲解了软件架构的各个方面，从团队协作到技术选型，为开发者提供了一份实用的指南。
评论区里，大家普遍认同团队协作和沟通的重要性，许多人分享了自己在项目中遇到的类似问题，并提出了自己的解决方案。有人认为，架构师应该更加关注业务需求，而不仅仅是技术细节。也有人强调了自动化测试的重要性，认为它可以减少 bug，提高交付速度。总的来说，评论区对文章的内容表示认可，并补充了一些实际经验和建议，使得讨论更加深入和全面。
- 原文: [The Art of Software Architecture: A Desi Developer's Guide to Building Systems That Actually Work](https://dev.to/datatechbridge/the-art-of-software-architecture-a-desi-developers-guide-to-building-systems-that-actually-work-39eh)
- 作者: datatechbridge
- 点赞数: 13
- 评论数: 0
- 发布时间: 2025-11-24 17:55:37
---
## 别担心，你并非事事都错：通往卓越工程师的成长之路
本文探讨了软件工程师成长过程中常见的现象：初学者常因经验不足而犯错，但这些错误是积累经验、最终成为优秀工程师的必经之路。文章强调了实践的重要性，并建议通过模仿优秀项目来加速学习过程，同时提醒大家警惕 AI 工具带来的潜在陷阱。
文章指出，在软件工程领域，新手常常会收到来自资深工程师的建议，例如“不要那样写类”、“不要过度抽象”等等。这些建议技术上通常是正确的，但对于初学者来说，可能并不实用，就像一位吉他大师批评初学者指法不正确一样，无法真正帮助他们。每个资深工程师都曾写过让他们现在感到尴尬的代码，犯过各种错误，但他们也从中获得了宝贵的经验。
文章引用了 Peter Norvig 的观点，认为精通编程需要长期的刻意练习，大约需要十年时间，每周投入 10 到 20 小时，不断挑战自己的极限，获得反馈并从错误中迭代。即使是像莫扎特这样的天才，也花了 13 年的时间才开始创作出世界级的音乐。文章强调，真正的技能是建立在实践和直觉之上的，而不是教条。只有亲身经历过嵌套回调的痛苦，才能真正理解其危害；只有亲身体验过过度抽象的成本，才能体会到其弊端。
因此，文章建议初学者不要害怕犯错，要勇于实践，构建大型项目，阅读他人的代码，不断改进。书籍可以提供帮助，但没有什么比构建一个会崩溃的项目并自己修复它更有效。模仿优秀项目是加速学习过程的有效方法。文章建议程序员花时间重新实现一些优秀的开源项目，例如 Redis，这可以帮助他们理解原作者的巧妙设计，并将其作为自己工作的基准。
文章还讨论了 AI 工具对软件开发的影响。AI 工具可以快速生成代码，提高开发效率，但同时也可能削弱学习过程中的反馈循环。如果过度依赖 AI 工具，可能会在不知不觉中养成不良的编码习惯，阻碍技能的提升。因此，文章建议将 AI 工具视为一个助手，仔细审查其生成的代码，并理解其背后的原理。
文章最后总结道，成为一名优秀的工程师需要时间和经验的积累。不要害怕犯错，要勇于实践，不断学习和改进。总有一天，你会成为那个给出建议的资深工程师，但请记住，要以鼓励和分享的态度，帮助他人成长。
- 原文: [You're NOT doing everything wrong](https://dev.to/acoh3n/youre-not-doing-everything-wrong-4l5n)
- 作者: acoh3n
- 点赞数: 8
- 评论数: 0
- 发布时间: 2025-11-29 17:53:41
---
## Lume.js：一个 2KB 的零配置 React 替代方案
Lume.js 是一个超轻量级的响应式 JavaScript 框架，大小仅为 2KB，它不依赖任何自定义语法或构建步骤，而是直接利用标准的 HTML 和 JavaScript 特性，例如 `data-bind` 属性和 ES6 的 Proxy。
Lume.js 的核心理念是充分利用 Web 标准，避免重复发明轮子，它认为现有的 HTML 和 JavaScript 已经足够强大，只需要解决一个关键问题：响应式，通过 Lume.js，开发者可以在 WordPress 站点、Shopify 主题或内部工具等场景中轻松实现响应式交互，而无需引入复杂的构建流程或大型框架。
Lume.js 的 API 非常简洁，仅包含 `state` 和 `bindDom` 两个核心函数，通过 `state` 函数创建响应式状态，然后使用 `bindDom` 函数将状态绑定到 DOM 元素，当状态发生变化时，绑定的 DOM 元素会自动更新，无需手动操作。
Lume.js 还提供了一些有用的附加功能，例如自动依赖追踪、计算属性和高效的列表渲染，这些功能都以极小的体积提供，并且与核心库无缝集成，Lume.js 的设计目标不是取代大型框架，而是提供一个轻量级的、标准化的响应式解决方案，适用于那些不需要完整框架的场景。
Lume.js 的优势在于其体积小、速度快、易于使用，并且完全基于 Web 标准，它可以在任何支持 HTML5 和 ES6 的环境中运行，无需任何额外的配置，Lume.js 的作者强调，该框架的设计理念是“标准胜过框架”、“显式胜过魔法”、“小而完整胜过大而全”。
Lume.js 适用于需要在静态网站上添加响应式交互、创建动态表单、或在受限环境中工作的场景，例如 WordPress 和 Shopify 主题，它也可以用于快速原型设计，避免了 Webpack 等构建工具的开销。
目前 Lume.js 的核心 API 已经稳定，作者计划在未来添加更多附加功能，例如路由和表单验证，但会坚持小而精的设计原则，避免过度设计。
- 原文: [I Built a 2KB React Alternative That Uses Zero Custom Syntax](https://dev.to/sathvikcheela/i-built-a-2kb-react-alternative-that-uses-zero-custom-syntax-mpl)
- 作者: sathvikcheela
- 点赞数: 3
- 评论数: 0
- 发布时间: 2025-11-29 09:27:13
---
## 使用 TypeScript 构建 HTTP 服务器
本文介绍了作者使用 TypeScript 构建 HTTP 服务器的实践经历，旨在帮助读者理解 HTTP 协议和网络编程的基础知识。作者通过动手实践，深入理解了 TCP 协议、HTTP 请求解析、HTTP 响应构建以及 HTTP Keep-Alive 等关键概念。
作者首先提到，在学习 Web 开发的过程中，对“请求”和“响应”的概念感到困惑，因此决定通过构建自己的 HTTP 服务器来加深理解。他强调了 HTTP 建立在 TCP 协议之上，并用简单的对话比喻解释了 TCP 的三次握手过程。随后，作者分享了 HTTP 请求的结构，并展示了如何使用 TypeScript 对请求进行解析，以及如何构建 HTTP 响应。他指出，解析 HTTP 请求实际上就是字符串分割和解析的过程，而构建响应则是将数据格式化为 HTTP 格式。文章还深入探讨了 HTTP Keep-Alive 的概念，通过保持连接的打开状态，复用连接来提高性能。最后，作者提到了在网络编程中使用回调函数时，对 JavaScript 事件循环的理解。
总的来说，作者通过亲身实践，将复杂的网络编程概念拆解为易于理解的步骤，鼓励读者通过“重新发明轮子”的方式来加深对技术的理解。文章不仅提供了实用的代码示例，还分享了学习资源，为有兴趣深入了解 HTTP 协议和网络编程的开发者提供了有价值的参考。
- 原文: [Building My Own HTTP Server in TypeScript](https://dev.to/elsad_humbetli_0971c995ce/building-my-own-http-server-in-typescript-51a)
- 作者: elsad_humbetli_0971c995ce
- 点赞数: 16
- 评论数: 10
- 发布时间: 2025-11-27 06:04:51
---
## 解决 Agentic AI Prompt 难题：Antigravity AI Directory 的诞生
本文讲述了作者在使用 Google Antigravity 进行 agentic AI 开发时遇到的挑战，以及如何通过创建 Antigravity AI Directory 来解决这些问题。
作者在使用 Antigravity 时发现，虽然 agent 的能力很强大，但要获得一致的结果非常困难。开发者们都在重复造轮子，通过不断试错来摸索最佳实践。作者意识到，问题不在于 AI 本身，而在于缺乏有效的指导。Antigravity 需要一个包含经过验证的 prompt、规则和工作流的目录，帮助开发者们避免不必要的挫折，直接进入开发阶段。
Antigravity AI Directory 应运而生，它是一个精选的优质 agentic AI 规则、prompt 和最佳实践集合。它旨在帮助开发者们跳过那些令人沮丧的环节，直接开始构建。
**Antigravity AI Directory 的主要内容包括：**
* 针对常见开发任务的预测试 prompt 模板
* 针对 AI agent 格式化的编码标准
* 多 agent 编排工作流
* Next.js、React、TypeScript、FastAPI 的集成模式
* Docker 和 CI/CD 自动化规则
* 安全和部署最佳实践
这些内容与 Gemini 3 Pro 无缝集成，并支持基于 artifact 的验证，确保代码可以用于生产环境。
**实际应用案例包括：**
* **API 开发：** 使用预构建的 prompt 生成具有完整文档和错误处理的 endpoint，而无需花费大量时间解释 REST 约定。
* **测试自动化：** 为 agent 提供能够覆盖 edge case 的测试模式，而不仅仅是 happy path。
* **代码审查：** 使用标准化规则在代码进入生产环境之前发现常见问题。
作者在构建 Antigravity AI Directory 的过程中，总结了 agentic 开发的三个关键点：
1. **具体性胜过模糊性：** 模糊的 prompt 会导致模糊的结果。提供越多的结构，输出就越好。
2. **上下文是关键：** Agent 需要理解项目的架构，而不仅仅是眼前的任务。
3. **反馈循环很重要：** 最佳工作流应在关键决策点包含人工检查。
总而言之，Antigravity AI Directory 的目标是帮助开发者们更好地利用 agentic AI 工具，构建高质量的应用程序。
- 原文: [I Built Antigravity AI Directory After Struggling With Agentic AI Prompts (Here's What I Learned)](https://dev.to/chandan_karn_fb750e731394/i-built-antigravity-ai-directory-after-struggling-with-agentic-ai-prompts-heres-what-i-learned-1kio)
- 作者: chandan_karn_fb750e731394
- 点赞数: 14
- 评论数: 3
- 发布时间: 2025-11-24 19:18:09
---
## re:Invent 参会指南：如何为家人创造魔法般的体验
这篇文章分享了作者作为丈夫和父亲，如何在参加 re:Invent 大会期间，通过一系列贴心的准备工作，减轻家人负担，让自己更专注于会议内容，同时让家人也能感受到关爱和惊喜。
作者主要从四个方面入手：首先是“re:Freshing”，确保离家前家里干净整洁，洗衣、换床单等，创造一个舒适的环境。其次是“Leave them pre:pared”，为家人提前准备好食物，安排好接送，加满汽车油，并与朋友保持联系，以备不时之需。第三是“Daily re:Veal”，计划每日惊喜，比如给妻子送星巴克礼品卡，订午餐，给孩子零花钱，或者安排一次闺蜜之夜。最后是“re:Entry”，回家后也要安排时间与家人重新建立联系，比如一起吃早餐，安排一次特别的约会。
总而言之，作者强调参加 re:Invent 并不意味着给家庭带来混乱和压力，通过细致的准备和关怀，可以兼顾工作和家庭，让家人感受到你的爱和支持。
由于没有评论内容，这里就不过多分析评论区的观点了。希望这些建议能帮助参会者更好地平衡工作和家庭生活。
- 原文: [Making re:Invent magic for your family](https://dev.to/aws-heroes/making-reinvent-magic-for-your-family-3kbf)
- 作者: dave_stauffacher_7c71a5ab
- 点赞数: 4
- 评论数: 1
- 发布时间: 2025-11-24 17:44:12
---
## 构建无人问津的未来：AI 编排的堂吉诃德
本文探讨了在 AI 领域中，作者对于认知编排的超前理念与当前业界追求快速demo之间的矛盾，以及由此产生的挫败感。作者认为，当前AI领域过度关注单一模型的优化和prompt技巧，而忽视了构建可观测、可追溯和可信赖的模块化认知层的重要性。
文章的核心观点是，作者花费数月构建的OrKa，一个模块化的认知层，旨在解决AI推理的可观察性、可追溯性和确定性问题。OrKa将推理视为一个图，而非黑盒，它进行路由、评分并记录每个决策。然而，这种超前的理念并未得到广泛认可，许多人认为作者在解决“未来的问题”，过度工程化，而更倾向于快速推出基于LLM的包装产品。文章将反馈分为两类：一类是“对领域有价值”的建设者，他们理解安全性和可追溯性的重要性；另一类是“堂吉诃德”式的实用主义者，他们更关注短期目标和快速产出。作者认为，认知债务正在累积，包括为单个客户编写的自定义prompt、未记录的“魔法”行为、以及无法重现的故障。虽然避免未来问题没有直接回报，但作者仍然坚持构建OrKa，因为他无法接受AI系统在不透明的黑盒中做出高影响决策，且无法重现推理过程。
作者强调，真正的编排不仅仅是简单地将工具和prompt组合在一起，而是一个包含代理和服务节点图、显式且可检查的路由决策、具有衰减功能的记忆模型、以及包含时间戳、输入、输出和指标的完整日志的系统。OrKa旨在成为模型和产品之间的认知执行层，使推理过程可以被理解和推理。为了应对这种超前理念带来的挑战，作者提出了几条规则：保持对现实的关注，将挫折转化为实际成果，认真倾听但不完全采纳他人的意见，并始终保持对自身动机的诚实。
虽然文章没有直接评论，但我们可以推断出，作者希望通过分享自己的经验和观点，引发更多人对AI系统长期稳定性和可解释性的关注，并鼓励那些同样具有超前意识的开发者坚持自己的信念。同时，也提醒开发者们在追求技术创新的道路上，不要忽视潜在的认知债务，并为构建更可靠、更值得信赖的AI系统做出贡献。
- 原文: [Don Quixote Of Orchestration: Building For Problems No One Sees Yet](https://dev.to/marcosomma/don-quixote-of-orchestration-building-for-problems-no-one-sees-yet-1je6)
- 作者: marcosomma
- 点赞数: 14
- 评论数: 3
- 发布时间: 2025-11-23 15:40:11
---
## 使用 Git Worktree Runner 轻松免费地并行运行 AI
本文介绍了如何使用 Git Worktree Runner 这一免费工具，轻松实现 AI 代码的并行处理，提高开发效率。通过该工具，开发者可以同时运行多个 Git 分支，从而并行使用不同的 AI 工具或处理不同的代码模块。
文章首先展示了使用 Git Worktree Runner 前后 AI 编码的效率对比，强调了并行处理的优势。Git Worktree Runner 本质上是 Git Worktree 的一个易用型封装，它简化了 Git Worktree 的复杂命令，让开发者能够更轻松地管理多个 Git 分支。该工具由 CodeRabbit 开发，质量可靠且开源免费，支持多种编辑器 (如 Cursor, VS Code, Zed) 和 AI 工具 (如 Claude Code, Codex)，以及 Windows (Git Bash), Linux, macOS 等平台。
文章详细介绍了 Git Worktree Runner 的安装和使用方法，重点讲解了 `new`, `edit`, `ai`, `rm` 四个核心命令，分别用于创建、编辑、运行 AI 和移除工作区。此外，还提到了 Hooks 的使用，允许用户在工作区操作前后执行自定义命令。作者建议开发者根据自身需求，探索并行使用 AI 的最佳模式，例如前端、后端、测试并行，或使用不同 AI 工具处理相同任务。
最后，作者分享了自己使用 Claude Code 和 Codex 的经验，认为 Git Worktree Runner 可以有效利用等待 Codex 响应的时间，提高 AI 辅助编码的效率。
由于没有评论内容，这里就不做评论分析了。
- 原文: [🤖🤖How to run AI in parallel easily and for free (Git Worktree Runner)🧠🧠](https://dev.to/webdeveloperhyper/how-to-run-ai-in-parallel-easily-and-for-free-git-worktree-runner-80o)
- 作者: webdeveloperhyper
- 点赞数: 24
- 评论数: 7
- 发布时间: 2025-11-27 11:44:55
---
## 探索 HATEOAS：构建灵活的 Web 应用架构
本文深入探讨了 HATEOAS（Hypermedia as the Engine of Application State）架构，并通过一个简单的在线服装商店示例，展示了如何使用 HATEOAS 构建更具可扩展性和可维护性的 Web 应用程序。文章还介绍了如何利用 hmpl-js 库和 HATEOAS 架构，用少量的代码创建功能强大的应用。
文章首先解释了传统 SPA 应用的数据获取方式的不足，即客户端需要预先定义 API 路由，一旦后端路由发生变化，前端应用就会出错。而 HATEOAS 的核心思想是，服务器在响应中提供客户端可以执行的动作链接，客户端根据这些链接来驱动应用状态的改变。作者通过在线服装商店的例子，展示了如何通过 `products/{id}` 路由获取商品信息，并在响应中包含指向商品评论等相关资源的链接。这样，即使后端 API 发生变化，客户端也能通过响应中的链接找到正确的资源，从而提高了应用的灵活性和可维护性。
为了更具体地展示 HATEOAS 的应用，作者使用 hmpl-js 库创建了一个简单的在线服装商店应用。该应用通过模拟 API 接口，实现了商品列表展示和商品详情查看功能。在商品详情页面，应用通过 `data-hateoas` 属性将 HATEOAS 链接嵌入到 HTML 中，客户端可以根据这些链接执行相应的操作，例如添加到购物车。
文章总结指出，HATEOAS 架构在应用开发中受到的关注较少，但它能够提高应用的灵活性，创建更具可扩展性和可维护性的网站。通过结合 hmpl-js 等工具，开发者可以用更少的代码构建出功能强大的应用。
由于文章没有评论内容，因此略过评论分析。
- 原文: [What Is HATEOAS? A Complete Guide + Build Your Own App Using Hypermedia 🔥](https://dev.to/anthonymax/what-is-hateoas-a-complete-guide-build-your-own-app-using-hypermedia-k56)
- 作者: anthonymax
- 点赞数: 97
- 评论数: 7
- 发布时间: 2025-11-27 21:02:20
---
## 使用 AI 在 Blender 中生成 3D 模型：3D-Agent 插件
本文介绍了作者如何开发一款 Blender 插件 3D-Agent，该插件可以通过文本描述直接在 Blender 中生成 3D 模型，解决了作者不擅长 3D 建模，但又需要 3D 资源用于项目的问题。
3D-Agent 插件基于 Claude 和模型上下文协议 (MCP) 构建，允许用户通过简单的文本提示，例如“螺旋楼梯”，就能在 Blender 场景中生成相应的 3D 模型。插件通过 Blender 的 Python API 接收文本提示，并将其发送给 AI 模型，AI 模型返回一系列 Blender 操作指令，插件按顺序执行这些指令来构建模型。AI 模型具备 Blender 的相关知识，包括 3D 建模模式和拓扑结构的最佳实践，因此能够理解用户的需求并生成高质量的模型。
与需要上传到 Web 服务或导入特定文件格式的其他文本转 3D 工具不同，3D-Agent 直接在 Blender 内部工作，简化了工作流程。插件生成的模型可以导出为 OBJ、FBX、GLB、USDZ 等标准格式，并且拓扑结构足够清晰，可以直接用于生产。
该插件尤其适用于概念艺术和快速原型设计，可以快速可视化想法，并生成低到中等精度的模型，例如角色、建筑、道具和环境。此外，通过观察 AI 构建模型的过程，用户还可以学习 3D 建模的概念。当然，它也有局限性，例如不适合生成照片般逼真的人脸等有机模型，也不适合需要精确 CAD 的工作。
作者还分享了使用 3D-Agent 从单个提示生成整个建筑场景的示例，整个过程仅需约 10 分钟。目前，作者正在积极开发新功能，例如批量生成、拓扑优化和更多导出选项。
评论区目前还没有评论，期待更多开发者和科技爱好者分享他们使用 AI 进行创作的经验。
- 原文: [How I Built a Blender AI Plugin That Generates 3D Models from Text: 3D-Agent](https://dev.to/glglgl/how-i-built-a-blender-ai-plugin-that-generates-3d-models-from-text-3d-agent-2fkc)
- 作者: glglgl
- 点赞数: 17
- 评论数: 8
- 发布时间: 2025-11-26 17:18:02
---
## 开发者社区中 AI 炒作的隐性成本
这篇文章探讨了当前 AI 领域过度炒作给开发者社区带来的负面影响，作者认为，表面上 AI 的快速发展令人兴奋，但实际上开发者们正在默默承受着持续炒作带来的隐性成本，如果对此不加以重视，可能会导致开发者倦怠、职业发展停滞，甚至做出错误的技术选择。
文章主要分析了 AI 炒作带来的七个问题。首先，炒作 создаёт 不切实际的期望，让开发者误以为 AI 是万能的，导致他们在面对 AI 的局限性时感到沮丧。其次，炒作让开发者感到自己总是落后于时代，迫使他们不断学习新的模型和工具，从而产生焦虑和压力。第三，炒作促使开发者追求花哨的工具，而不是扎实的基础技能，导致他们对系统理解不深，过度依赖工具。第四，炒作将技术讨论变成了竞赛，破坏了社区的协作氛围，阻碍了知识共享。第五，炒作分散了开发者对真正重要事情的注意力，例如解决实际问题、理解用户行为和构建可维护的系统。第六，炒作 создаёт 一种成功可以瞬间实现的错觉，当现实与期望不符时，会摧毁开发者的信心。最后，也是最重要的一点，炒作扼杀了开发者的创造力和好奇心，使他们不再关注问题的本质和原理，而是追逐最新的工具和捷径。
作者强调，AI 的目的是赋能开发者，而不是让他们感到不知所措。在 AI 时代取得成功的开发者将是那些能够清晰思考、耐心构建、深入理解、明智地使用 AI、关注结果、忽略噪音并培养判断力的人。炒作终将消退，而实质性的东西才会积累。
目前评论区还没有评论。
- 原文: [The Hidden Cost of AI Hype in Developer Communities](https://dev.to/jaideepparashar/the-hidden-cost-of-ai-hype-in-developer-communities-34dm)
- 作者: jaideepparashar
- 点赞数: 23
- 评论数: 9
- 发布时间: 2025-11-26 01:00:46
---
🫵 来啊，说点有用的废话!
▲
