2小时前
|
|
|
## 这周 DEV 社区聊了啥？ NO.20251109
这期日报干货满满！从 AI 智能体写代码的真实水平，到如何避免开发者倦怠，再到 jQuery 的“不老传说”，内容涵盖了开发者的方方面面。想知道 AI 到底能不能取代你？全栈疲劳是不是真的存在？怎么才能摆脱无休止的教程？还有，如何用纯 CSS 做出超惊悚的万圣节场景？快来一起看看，总有你感兴趣的话题！
---
## AI 智能体编写代码的现实：为什么人类开发者仍然不可或缺
Octomind 的文章探讨了当前 AI 智能体在代码编写方面的局限性，指出尽管 AI 在某些方面有所帮助，但距离完全取代人类开发者还很遥远。文章通过实际案例分析，揭示了 AI 在代码生成过程中存在的诸多问题。
文章作者分享了他们使用 Cursor、Claude Code 和 Windsurf 等 AI 工具进行代码开发的经验。他们尝试让 AI 独立完成一个 roadmap 功能的开发，但结果却不尽如人意。AI 生成的代码存在诸多问题，例如无法正确处理数据库 schema 变更、忽略基本编码规范、产生低效的数据库查询，以及不符合现有的设计和 UX 规范。即使将任务分解为更小的增量，AI 仍然难以胜任，生成的代码质量和效率都无法达到预期。
文章强调了 AI 在代码编写过程中存在的一些关键问题。首先是 AI 会导致开发者对代码的 mental model 丢失，难以理解和维护 AI 生成的代码。其次，AI 可能会引入安全漏洞和数据一致性问题，需要人工进行仔细审查。最后，AI 缺乏创造性和解决复杂问题的能力，无法应对软件开发中遇到的各种挑战。
作者认为，虽然 AI 在代码编写方面还有很长的路要走，但这并不意味着 AI 没有价值。AI 可以辅助开发者完成一些重复性的任务，例如生成单元测试、进行代码审查等。此外，AI 还可以帮助开发者进行 ideation，提供不同的解决方案。然而，在可预见的未来，人类开发者仍然是软件开发的核心力量。
文章通过实验得出结论，AI 智能体目前还无法像宣传的那样高效编写代码，人类开发者在理解、维护和保证代码质量方面仍然扮演着至关重要的角色。尽管 AI 工具在某些方面有所帮助，但完全依赖 AI 进行代码开发是不现实的。
- 原文: [Why agents DO NOT write most of our code - a reality check](https://dev.to/veith-octomind/why-agents-do-not-write-most-of-our-code-a-reality-check-87j)
- 作者: veith-octomind
- 点赞数: 42
- 评论数: 22
- 发布时间: 2025-11-03 09:38:49
---
## 使用AI构建前端应用：我的真实过程
本文主要探讨了如何利用AI工具辅助前端应用开发，重点在于作者分享了自己使用AI进行快速原型设计和迭代的经验，强调了在AI辅助下，工程师可以更专注于创意和用户体验。
作者分享了自己使用AI构建前端应用的经验，并坦诚地展示了自己略显混乱但高效的工作流程。她强调，AI在快速原型设计和创意探索方面具有显著优势，可以帮助开发者快速验证想法，从而节省大量时间和精力。文章详细描述了作者如何使用Claude Sonnet 4进行头脑风暴，并逐步完善最终的prompt，以便让AI代理生成符合需求的 landing page。作者还强调，在使用AI的过程中，保持批判性思维至关重要，不应盲目接受AI的输出，而是要根据自己的判断进行调整和优化。她还分享了自己与AI工具进行迭代的过程，包括如何根据反馈不断改进设计，以及如何将不同的想法融合在一起。最终，作者成功地构建了一个具有双重体验设计的 hackathon landing page，充分展示了AI在前端开发中的潜力。
文章中，作者特别提到了AI在设计方面的辅助作用，这对于不擅长设计的开发者来说非常有价值。她还强调了在与AI协作时，需要清晰地表达自己的需求，并对AI的输出进行细致的调整，才能获得最佳效果。
- 原文: [How I Use AI to Build Frontend Apps: My Candid, Messy Process](https://dev.to/blackgirlbytes/how-i-use-ai-to-build-frontend-apps-my-candid-messy-process-3ehk)
- 作者: blackgirlbytes
- 点赞数: 64
- 评论数: 17
- 发布时间: 2025-11-04 01:53:53
---
## 警惕隐形开发者倦怠：为何过度投入会耗尽你的热情
本文探讨了软件开发中一种特殊的倦怠感，这种倦怠感源于维护那些似乎无人关心的标准，以及在舒适的漠不关心环境中坚持投入所带来的隐形工作。这种倦怠感并非突如其来，而是逐渐积累，当你意识到你的标准已成为个人而非团队共识时，当你对精确的追求变成个人怪癖而非职业基线时，倦怠感便会悄然而至。
长期来看，深度投入比漠不关心消耗更多的能量。漠不关心是可再生的，它对你没有任何要求。但投入是一种消耗性资源，尤其是在一个无法补充它的环境中。最终，你不仅在做工作，还在承担着唯一一个仍然相信工艺重要性的人的负担。在代码中，投入体现在那些无人关注的细节之处，例如你精心设计的依赖项数组，你偏离现有模式以方便他人，以及你在 PR 评论中提出的关于潜在问题的警告。
没有人会庆祝你花一下午时间将三个几乎相同的实现合并为一个可重用模式，他们甚至不会注意到你花一个晚上追踪性能问题，最终发现是对 memoization 的基本误解。但这些悄无声息的改变却体现在代码库的灵魂中，体现在代码是低声细语还是尖叫，体现在代码是欢迎你回来还是让你夜不能寐。当你环顾四周，意识到你所珍视的工艺，在别人眼中却是可有可无，甚至被视为“过度工程”时，疲惫感便会涌上心头。
技术成熟往往会朝着“以前有效的方法”而非“更有效的方法”发展。战争故事堆积如山，教条主义开始盛行。“我们一直都是这样做的”变得与“这是正确的方法”难以区分。很快，本应使开发者更具思考力的经验，反而使他们更加确定、更加抵制，最终更加舒适。在这些环境中，共识取代了好奇心，新的方法被视为“不必要的复杂性”，不同的模式被视为“不符合我们的做事方式”。当所有衡量标准都是速度时，就会营造出一种“足够好”往往是值得晋升的成就，而真正的工艺则被视为代价高昂的放纵的环境。
作为一名开发者，正直意味着拒绝让投入悄无声息地消亡。这意味着即使其他人都满足于“随便”，也要继续追问“为什么”。这项工作是隐形的、不光彩的、常常是吃力不讨好的。你做出的那个避免了未来痛苦的谨慎架构决策？如果你做得好，甚至没有人会注意到。但这些决策成为了长期软件健康的连接组织。它们是代码库优雅老化和逐渐腐烂之间的区别。
如果你还在阅读本文，并且已经感到疲惫，那很好。疲惫证明你仍然在乎。漠不关心的人不会感到疲惫。那些已经放弃的人不会为依赖项数组而苦恼，他们不会为技术债务而失眠，当 PR 在没有经过有意义的审查的情况下被草率批准时，他们不会感到失望。他们已经与衰败达成了和解，因为舒适对你没有任何要求。
这种投入是罕见的，比你想象的还要罕见。虽然成为唯一一个坚持那些感觉越来越个人化而非文化标准的的人是令人疲惫的，但这种疲惫是有意义的。这意味着工艺仍然对你有着吸引力。这意味着你还没有决定冷漠更容易。你不需要赢得每一场争论，你不需要解决每一个问题，你不需要在所有事情上都是正确的，或者说服每个人你的方式更好。你只需要继续关心那些看不见的东西，继续像有人会阅读一样编写代码，继续像质量很重要一样审查代码，继续追问“为什么”，即使“因为”听起来已经足够。因为一旦投入变得可见，它就会吸引更多的投入。工艺并不意味着成为一个英雄，它只是意味着你不会放弃可能实现的目标。
（没有评论内容，跳过评论相关的输出。）
- 原文: [The Invisible Developer: Why Caring Burns You Out](https://dev.to/junothreadborne/the-invisible-developer-why-caring-burns-you-out-p8o)
- 作者: junothreadborne
- 点赞数: 48
- 评论数: 8
- 发布时间: 2025-11-05 03:26:44
---
## 本周 DEV 社区精选文章：开发者关注的热点话题
本周 DEV 社区精选了七篇文章，涵盖了全栈疲劳、敏捷开发的反思、GitHub 安全、前后端开发差异、git rebase 的使用、公开构建项目以及 PureScript 语言的介绍等多个方面。这些文章反映了开发者们对于技术发展趋势、开发流程、安全实践以及编程语言选择的思考和探索。
其中，关于“全栈疲劳”的文章引发了对现代全栈开发者所需技能广度的讨论，作者质疑这种广泛的要求是否对新人不友好。另一篇文章则批判了敏捷开发中存在的形式主义，呼吁开发者回归敏捷宣言的核心价值。GitHub 安全问题也受到了关注，有文章详细介绍了如何使用 GPG 签名 commit，以防止身份冒用。
此外，还有文章深入解析了前后端开发的差异，特别是 Vite 和 Express 在路由处理上的不同。关于 git rebase 的讨论则更加务实，作者认为过度使用 rebase 可能会增加不必要的风险和复杂性。一篇关于“公开构建”的文章分享了作者启动新项目的 Day Zero 目标、市场定位以及面临的挑战。最后，PureScript 作为一种纯函数式语言，被认为能够优雅地与 JavaScript 生态系统融合，为开发者提供了一种新的选择。
这些文章内容丰富，涵盖了开发者们在日常工作中可能遇到的各种问题和挑战，也为他们提供了新的思路和解决方案。
- 原文: [Top 7 Featured DEV Posts of the Week](https://dev.to/devteam/top-7-featured-dev-posts-of-the-week-1g8e)
- 作者: jess
- 点赞数: 38
- 评论数: 13
- 发布时间: 2025-11-04 18:14:13
---
## jQuery 的持久生命力：为何它能超越众多 JavaScript 框架
本文探讨了 jQuery 依然广泛存在的原因，即使在现代 JavaScript 框架层出不穷的今天，jQuery 仍然在大量网站中默默运行。文章认为，jQuery 并没有“活着”，而是被“安装”了，它早已完成了它的使命，现在处于长期维护模式，就像金融系统中的 COBOL 一样。
文章指出，尽管现代 JavaScript 已经弥补了 jQuery 曾经解决的许多问题，例如 DOM 操作、事件绑定和 AJAX 请求等，但修复旧代码的成本远高于构建新代码。许多 jQuery 代码并非“坏代码”，只是老旧、纠缠不清，并且难以一次性安全地替换。业务逻辑与 DOM 紧密结合、第三方插件缺乏 React/Vue/Svelte 版本、重写没有投资回报率以及 WordPress 等生态系统的依赖，都是 jQuery 难以被移除的原因。
作者对比了 JavaScript 框架和商业应用程序的平均寿命，发现框架的生命周期通常只有 5-7 年，而商业应用程序则长达 12-20 年。jQuery 虽然不再流行，但仍在生产服务器上运行，为盈利代码提供支持。文章建议初级开发者不应将 jQuery 作为入门工具，因为它无法教授组件、响应式、状态管理等现代前端概念。然而，资深开发者应该理解 jQuery，以便安全地删除它，而不是破坏生产环境。
完整的 jQuery 移除很少发生，通常只是将旧的 jQuery 模块与新的框架并行运行，然后逐渐封装、缩小和隔离它。WordPress 仍然依赖 jQuery，这也会延长其生命周期。最终，jQuery 仍然存在的原因是，删除它的成本高于保留它的成本，这是一个经济、风险管理和遗留熵的综合决策。文章最后总结说，现代前端开发需要同时具备构建新事物和理解旧事物的能力。
- 原文: [jQuery Will Outlive Half of Today’s JavaScript Frameworks - Here's Why](https://dev.to/sylwia-lask/jquery-will-outlive-half-of-todays-javascript-frameworks-heres-why-2mmd)
- 作者: sylwia-lask
- 点赞数: 49
- 评论数: 60
- 发布时间: 2025-11-05 13:09:13
---
## 摆脱教程陷阱：你的第一份开发工作才是最佳老师
文章指出，与其无休止地学习教程，不如直接开始第一份开发工作，因为实际工作环境能带来更快速的成长。很多初级开发者总觉得自己还没准备好，陷入不断学习“下一个课程”的循环，但真正的成长来自于实践。
文章强调了“准备好”的迷思，作者分享了自己当初觉得自己完全没准备好就去应聘第一份开发工作的经历。然而，入职后短短一个月内，他在版本控制、调试和阅读他人代码方面的进步，远超过去六个月在线课程的学习。这是因为教程无法模拟真实的工作场景，比如在晚上9点修复生产环境中的bug，或者在代码审查中解释你的逻辑。
文章进一步解释了为什么实际工作能带来如此大的改变。在真实的工作环境中，你需要学会阅读混乱的遗留代码并理解其含义，提出更有效、更精准的问题，以更成熟的心态接受反馈，以及在需求不明确时处理模糊性。这些都是真正的开发者教育，并且从入职的第一天就开始了。
文章还给出了寻找第一份工作的建议：不要盲目投简历，要寻找那些真正愿意投资于初级开发者的团队。绿色信号包括：结构化的入职培训、结对编程、定期的代码审查，以及愿意指导你的资深同事。红色信号则包括：缺乏文档、每个人都忙得不可开交、以及期望你入职第一天就能“立即上手”。
文章最后鼓励大家勇敢地去申请工作，即使你觉得自己还没准备好。那种觉得自己没准备好的感觉永远不会完全消失，即使是资深开发者也会有这种感觉。所以，不要再犹豫，开始行动吧！因为成长最快的方式是开始，而不是永远准备。通过实践、失败和改进，你终将成为一名优秀的开发者。
- 原文: [You’ll Learn More in 3 Months on the Job Than 2 Years of Tutorials](https://dev.to/tlorent/youll-learn-more-in-3-months-on-the-job-than-2-years-of-tutorials-5g9f)
- 作者: tlorent
- 点赞数: 28
- 评论数: 29
- 发布时间: 2025-11-04 08:58:44
---
## 开源项目 NocoBase：不靠 AI 也能年入百万美元
本文讲述了开源 no-code 平台 NocoBase 在 AI 热潮下，坚持自身发展道路，并在没有营销投入的情况下，取得 17K GitHub stars 和 145 万美元收入的成功故事。NocoBase 团队专注于产品开发，通过持续改进和用户积累，赢得了包括多家大型企业在内的客户，证明了即使在 AI 时代，专注和实用仍然是开源项目成功的关键。
NocoBase 团队规模不大，只有 14 个人，但他们注重工作与生活的平衡。作者分享了团队成员的生活状态，例如营销负责人 Lijia 热爱运动和旅行，作者本人也注重家庭生活，并与家人一起旅行和探索世界。这种积极的生活态度也反映在 NocoBase 的产品开发中，使产品不断改进，充满活力。
文章还探讨了 AI 是否会取代 NocoBase 的问题。作者认为，虽然 AI 在文档编写、代码编写等方面可以提供帮助，但 NocoBase 的核心价值在于其 no-code 理念和解决实际问题的能力。因此，NocoBase 2.0 在设计和开发中也融入了 AI 的能力，旨在更好地服务用户，而不是被 AI 取代。NocoBase 团队通过实践，理解了 AI 的优势和局限性，并将这些理解融入到产品设计中。
NocoBase 的成功并非偶然，而是团队长期坚持和努力的结果。他们专注于产品开发，注重用户体验，并通过积极的生活态度保持团队的活力。即使在 AI 时代，NocoBase 仍然能够保持竞争力，并取得持续的增长。
- 原文: [No AI, No VC, Just 17K Stars and Real Revenue](https://dev.to/nocobase/no-ai-no-vc-just-17k-stars-and-real-revenue-6ch)
- 作者: nocobase
- 点赞数: 44
- 评论数: 10
- 发布时间: 2025-11-04 03:33:49
---
## Chrome 扩展发布实战：Muscle Brain v4 的发布经验分享
本文作者分享了将脑力训练应用 Muscle Brain 发布为 Chrome 扩展的经验，对比了在 Microsoft Store、Google Play 和 App Store 发布应用的难度和成本，最终选择了 Chrome Web Store。文章详细介绍了 Chrome 扩展的制作和发布步骤，包括配置 `manifest.json`、解决 Next.js 兼容性问题以及在 Chrome Web Store 上架的流程。
作者最初尝试在 Reddit 上推广应用，但因新账号推广方式不当而被封禁。随后，作者对比了不同应用商店的优劣，发现 Chrome 扩展的发布相对简单且成本较低，只需一次性支付 5 美元的注册费。此外，Chrome 扩展不仅支持 Windows，还支持 macOS 和 Linux 系统，覆盖用户更广。
在制作 Chrome 扩展的过程中，作者使用 Next.js 构建应用，并使用 PWABuilder 将其转换为 MSIX 格式。为了兼容 Chrome 扩展，作者需要修改 Next.js 的配置，例如设置 `output: 'export'`，将 `_next` 文件夹重命名为 `next`，并将 React 数据从内联脚本移动到单独的文件中。
发布 Chrome 扩展的步骤包括：本地测试、注册开发者账号、上传应用压缩包和填写应用信息。作者建议先将应用设置为“未公开”，检查应用是否正常工作，然后再将其设置为“公开”。
Muscle Brain 是一款基于 N-back 方法的脑力训练游戏，旨在提高工作记忆能力。最新版本 v4.0.0 增加了每日连胜、ABC 模式以及英语/日语支持等新功能。该应用完全免费，无广告、无追踪、无需注册。
作者还计划未来制作着陆页，并将应用发布为 PWA (Progressive Web Apps)，以便在 Android 和 iOS 设备上使用。
由于没有评论内容，这里就不做评论分析啦。
- 原文: [🚀How I released Chrome Extensions (💪🧠Muscle Brain v4)](https://dev.to/webdeveloperhyper/how-i-released-chrome-extensions-muscle-brain-v4-3ijn)
- 作者: webdeveloperhyper
- 点赞数: 40
- 评论数: 30
- 发布时间: 2025-11-04 00:03:39
---
## Tailwind CSS 的崛起与 CSS 技能的流失
本文探讨了 Tailwind CSS 的广泛应用及其对开发者 CSS 技能的影响，指出过度依赖 Tailwind 可能会导致开发者忘记原生 CSS 的基础知识。
文章首先指出，越来越多的开发者习惯于使用 Tailwind CSS，甚至忘记了如何编写原始 CSS。Tailwind CSS 通过提供预定义的实用类，极大地提高了开发效率和一致性，避免了命名 CSS 类这种编程难题。它消除了样式冲突，让开发者无需在 HTML 和 CSS 文件之间切换，从而专注于构建用户界面。
然而，这种便利性也带来了一些问题。开发者可能会忽略 CSS 的基本概念，例如 Flexbox、Grid 和定位等。他们可能知道 Tailwind 中 `justify-content: space-between` 的作用，但无法用原生 CSS 编写相同的效果。此外，Tailwind CSS 可能会导致 HTML 文件变得臃肿，抵消了 CSS 文件体积缩小的优势。更重要的是，开发者会被锁定在 Tailwind 的生态系统中，迁移成本高昂。如果 Tailwind CSS 最终消失，可能会导致大量开发者缺乏足够的 CSS 技能来维护项目。
文章还指出，Tailwind CSS 就像自行车的辅助轮，开发者习惯于使用实用类，而没有真正学习和掌握 CSS 的核心概念。虽然 Tailwind CSS 支持一些新的 CSS 特性，但开发者学习的是实用类，而不是底层特性本身。
最后，作者建议在日常开发中继续使用 Tailwind CSS，但也要抽出时间练习原生 CSS，例如每周有一天完全不使用 Tailwind CSS，以保持和提高 CSS 技能。
- 原文: [Tailwind CSS Won the War... But We're the Losers](https://dev.to/elvissautet/tailwind-css-won-the-war-but-were-the-losers-4877)
- 作者: elvissautet
- 点赞数: 22
- 评论数: 5
- 发布时间: 2025-11-07 16:59:01
---
## Auth0 for AI Agents Challenge获奖者揭晓
本文宣布了 Auth0 for AI Agents Challenge 的获奖者，并展示了社区如何利用 Auth0 构建具有内置身份验证和安全性的 AI Agent。
该挑战赛收到了各种用例，展示了在身份验证和授权方面优先考虑安全性、用户控制和透明度的重要性。获奖项目包括：ESG Copilot、Assistant0 和 Study-Flow。
ESG Copilot 是一个自主的多代理 AI 系统，可自动执行中小型企业的 ESG 合规性，展示了 Auth0 安全堆栈的全部功能。它使用 Auth0 Universal Login 进行用户身份验证，Token Vault 用于保护 API 密钥，OpenFGA 用于细粒度的授权，确保公司之间零数据泄漏。
Assistant0 提供了一个安全的企业级 AI 助手，可以无缝管理 Gmail、Google Calendar、Web 搜索和文档访问，所有这些都通过 Auth0 的全面安全功能进行保护。它以其对客户端发起的反向通道身份验证 (CIBA) 的复杂实现而著称，对于高风险操作，需要明确的用户批准才能执行购买或发送电子邮件等操作，并利用 TokenVault 和带有 Okta 的 FGA。
Study-Flow 采用混合身份验证方法，将 Auth0 Token Vault 集成到现有的学习管理平台中，同时保持其原始的 Convex Auth 系统。这种方法突出了 Auth0 for AI Agents 的多功能性，以及使用 Token Vault 而不是手动令牌管理的好处。
这三位获奖者将分别获得 1,000 美元、一枚独家 DEV 徽章和一个 DEV++ 会员资格。所有提交有效作品的参与者都将获得一枚完成徽章。Auth0 赞助了本次挑战赛，为构建安全的 AI Agent 提供了工具。
由于文章没有评论，因此无法总结评论区的不同观点。
- 原文: [Congrats to the Winners of the Auth0 for AI Agents Challenge!](https://dev.to/devteam/congrats-to-the-winners-of-the-auth0-for-ai-agents-challenge-2jc8)
- 作者: thepracticaldev
- 点赞数: 41
- 评论数: 13
- 发布时间: 2025-11-06 23:16:49
---
## 每周日代码重构：一个程序员的习惯养成
本文作者分享了一个独特的习惯：每周日花时间重构旧代码，并非为了修复bug或添加新功能，而是通过阅读和改进之前的代码来提升自身技能。这个习惯帮助作者认识到代码的可读性、一致性的重要性，并体会到持续改进带来的长期收益。
作者的实践方法非常灵活，没有严格的流程或框架限制，随意选择之前的项目进行重构，可以是React应用、Python脚本，甚至是CSS艺术实验。重构的重点在于小的改进，例如重命名变量、删除不必要的代码、替换旧的逻辑、添加注释以及优化CSS样式。作者强调，重构不是要重写所有代码，而是通过小的改动与过去的自己对话，从中学习和成长。
作者还分享了从这个习惯中学到的经验：可读性比聪明更重要，一致性比复杂性更重要，小的重构随着时间的推移会产生巨大的影响，旧代码是成长的快照。为了避免倦怠，作者建议每次重构时间不超过2小时，并将其视为一种与过去连接的方式，而不是一项工作。作者鼓励开发者们通过重构旧代码来学习和进步，而不是一味地追求新的框架和技术。
评论区目前还没有评论，期待大家分享自己重构代码的经验和看法。你是否也有类似的习惯？或者你对重构有什么样的理解和技巧？欢迎在评论区交流！
- 原文: [Every Sunday, I Refactor Old Code and It’s the Smartest Habit I’ve Ever Built](https://dev.to/hadil/every-sunday-i-refactor-old-code-and-its-the-smartest-habit-ive-ever-built-2k7)
- 作者: hadil
- 点赞数: 80
- 评论数: 26
- 发布时间: 2025-11-04 06:44:03
---
## AnalogJS 2.0 发布：更快构建 Angular 应用
AnalogJS 2.0 版本正式发布，这是一个基于 Angular 的元框架，旨在帮助开发者更快速地构建网站和应用程序。新版本带来了诸多新特性和优化，包括内容资源、更小的安装包和捆绑包体积优化，以及 Vite 生态系统的升级。
AnalogJS 基于 Vite 和 Nitro 构建，提供诸如基于文件系统的路由、Markdown 支持、API/服务器路由支持、混合 SSR/SSG 以及对 Angular CLI/Nx 工作区的支持等功能。新版本引入了内容资源，方便开发者展示内容列表和文件。内容文件资源以信号的形式检索内容，与 Angular 的最新响应式原语集成。
为了优化项目，AnalogJS 2.0 减小了 Angular CLI 工作区的安装体积，所有 Angular 构建器都以 ESM 格式发布。同时，它还用 `tinyglobby` 替换了 `fast-glob` 等体积较大的依赖包，并直接使用 Vite CLI 进行服务和构建，使用 Vitest CLI 进行测试。这些优化使得全栈项目的捆绑包输出大小减少了 100Kb 以上，缩短了开发过程中的安装时间，并减少了构建和发布的代码量。
AnalogJS 2.0 还集成了最新的 Vite 生态系统，包括 Angular v17-v20（即将支持 v21）、Vite 6.x 和 7.x、Vitest 3.x 和 4.x、Nx 22.x 以及 Storybook 10.x。Angular v21 引入了对 Vitest 的稳定支持，Analog 和 Angular 都支持使用 Vitest 运行测试，但两者在功能上存在一些差异，开发者可以根据自身需求选择合适的方案。
AnalogJS 的发展离不开核心贡献者和社区的共同努力，感谢他们的代码、文档、测试以及对项目的尝试。目前，该项目在 GitHub 上拥有近 3000 个 star，在 Discord 上拥有 1000 多个成员，在 Twitter/X 上拥有 1000 多个关注者，并已入选首个 GitHub Accelerator Cohort。
- 原文: [Announcing AnalogJS 2.0 ⚡️](https://dev.to/analogjs/announcing-analogjs-20-348d)
- 作者: brandontroberts
- 点赞数: 38
- 评论数: 5
- 发布时间: 2025-11-03 15:20:19
---
## 公开构建的真相：你没听过的那些事
这篇文章探讨了“公开构建”的策略，揭示了其背后不为人知的压力和挑战，并强调了真诚分享和建立联系的重要性。
文章指出，公开构建不仅仅是分享成功，更重要的是分享过程中的挣扎、失败和学习。虽然公开构建可以带来诸多好处，例如吸引志同道合的人、获得早期反馈、建立信任和寻找合作者，但它也可能导致隐形的压力，让人为了“表演进步”而疲于奔命，甚至影响决策。文章作者分享了自己的经验，强调了从每日更新到每周反思的转变，以减轻压力，并建议关注更有意义的分享。此外，文章还提到了公开失败的恐惧，但同时也强调了公开分享失败的价值，因为它能让人们看到真实的成长过程。最终，文章呼吁开发者们为了自己而构建，为了他人而分享，但不要让观众决定自己的节奏。
由于没有评论内容，这里就不进行评论观点的总结了。
- 原文: [The Truth About ‘Building in Public’: What No One Tells You](https://dev.to/debuggingwithsim/the-truth-about-building-in-public-what-no-one-tells-you-2o2p)
- 作者: debuggingwithsim
- 点赞数: 11
- 评论数: 9
- 发布时间: 2025-11-08 05:52:13
---
## LLMs并非真AI：揭穿营销炒作，回归工具本质
这篇文章旨在纠正对大型语言模型（LLMs）的过度炒作，强调它们作为工具的价值，而非盲目吹捧为“人工智能”，避免不切实际的期望和错误决策。
文章首先批判了LinkedIn、Reddit等平台上的夸张言论，指出“AI将取代工程师”等说法纯粹是营销手段。作者强调，我们现在所说的“AI”实际上只是对“智能”的模拟，以LLM为例，它们本质上是基于大量数据训练的统计模型，而非具有意识的实体。图像生成器也面临类似的问题，即使技术不断进步，仍然难以生成复杂且细节准确的内容，因为它们只是模式匹配机器，缺乏真正的创造力。文章进一步解释了人类智能的多面性，包括推理、解决问题、创造力等，而LLM的“智能”是狭隘的，缺乏常识、直觉和真正的学习能力，因此会出现事实幻觉、代码错误等问题。
作者结合自身使用LLM的经验，肯定了LLM在研究、翻译、总结、代码解释等方面的辅助作用，但也指出它们不适合编写生产代码。即使有精确的提示，LLM生成的代码也常常不一致且质量低下。文章还反驳了“用不对”的说法，质疑了通过详细文档让AI自动生成代码的“vibe coding”方法，认为这种方法短期内可能带来快速结果，但长期来看会导致技术债务、调试困难、缺乏理解等问题，最终可能需要完全重写代码。作者还引用了一项研究，表明经验丰富的开发者在使用AI后，实际效率反而下降。
文章还提出了“初级开发者问题”，如果过度依赖AI生成代码，初级开发者将无法学习编程技能，最终可能只会prompt而不会编程。最后，文章指出LLM的训练依赖于大量数据的抓取，但高质量的训练数据正在耗尽，这限制了LLM的进一步发展。
- 原文: [Stop Calling LLMs AI](https://dev.to/sagiadinos/stop-calling-llms-ai-1ihk)
- 作者: sagiadinos
- 点赞数: 22
- 评论数: 17
- 发布时间: 2025-11-05 08:34:43
---
## 个性化 VS Code 设置：快速、安静且专注
本文分享了一套作者精心打造的 VS Code 设置，旨在提高开发效率，减少认知负担，并优化工作流程。核心理念是减少视觉干扰、自动化重复性任务，并加速常用操作。
作者通过调整编辑器体验，例如启用保存时自动格式化、激活括号配对引导线、禁用小地图和粘性滚动等，来减少视觉干扰，提高代码可读性。文件管理方面，启用了自动保存、插入/删除最终换行符和删除尾随空格等功能，保持代码库的整洁。在 Git 工作流中，允许强制推送、启用智能提交、使用状态栏显示 Blame 信息等，提高了代码提交和版本控制的效率。
此外，作者还分享了窗口和工作台的设置，例如禁用启动编辑器、在新窗口中打开文件/文件夹、调整目录树缩进等，以优化工作空间。AI 辅助方面，启用了聊天代理，但禁用了推测性的“下一步编辑”建议，保持对 AI 的主动控制。最后，作者还提供了一些可选的微优化建议和一个最小化的 `.editorconfig` 文件示例，方便读者参考和采用。
总而言之，这套 VS Code 设置强调个性化和精简，旨在打造一个高效、专注的开发环境。通过减少干扰、自动化任务和优化工作流程，帮助开发者更专注于创造性的编码工作。
- 原文: [My Opinionated VS Code Setup — Fast, Quiet, and Intentional](https://dev.to/ltsyqo/my-opinionated-vs-code-setup-fast-quiet-and-intentional-h81)
- 作者: ltsyqo
- 点赞数: 24
- 评论数: 3
- 发布时间: 2025-11-03 09:20:56
---
## 本周你的小成就
这周你有什么值得骄傲的事情吗？无论是大是小，都算数！
文章鼓励开发者们分享本周的成就，可以是升职加薪、启动新项目、修复了一个棘手的 Bug，甚至是成功搭建好开发环境而没有掀桌子。作者用一张熊猫掀桌子的 GIF 图，形象地表达了搭建开发环境的痛苦。文章旨在营造一个积极的氛围，让大家分享喜悦，互相鼓励。
文章没有评论，所以没有评论分析。
- 原文: [What was your win this week?](https://dev.to/devteam/what-was-your-win-this-week-41h2)
- 作者: jess
- 点赞数: 15
- 评论数: 5
- 发布时间: 2025-11-07 05:00:00
---
## 使用纯 CSS 创建惊悚万圣节场景
本文介绍了如何仅使用 HTML 和 CSS (没有 JavaScript!) 创建一个令人毛骨悚然的万圣节场景，灵感来源于恐怖电影中寂静的氛围和鬼屋的恐怖感。
文章作者分享了创作过程中的挑战和乐趣，包括使用 CSS 变换制作蜘蛛腿的动画，以及利用 `::before` 和 `::after` 伪元素简化 HTML 结构。作者还提到了血月脉动效果、随机眨眼的恶魔之眼等细节，这些都为场景增添了恐怖气氛。
在实现过程中，作者也遇到了一些 "Aha!" 时刻，例如使用 CSS 变量控制蜘蛛腿角度，以及使幽灵看起来漂浮不定的技巧。作者也反思了可以改进的地方，例如更好地组织动画和避免过度使用阴影。
总而言之，这个项目展示了 CSS 的强大功能，能够创造出生动的、令人印象深刻的视觉效果，即使没有 JavaScript 的帮助。作者将 CSS 比作 "数字巫术"，通过编写代码让事物移动、发光并栩栩如生。
- 原文: [CSS Nightmares: Building a Haunted Scene That Actually Creeped Me Out](https://dev.to/paulthedev/css-nightmares-building-a-haunted-scene-that-actually-creeped-me-out-1kbb)
- 作者: paulthedev
- 点赞数: 22
- 评论数: 5
- 发布时间: 2025-11-03 12:59:12
---
## AI 创业公司失败的主要原因及改进策略
本文探讨了 AI 创业公司在成立 12-24 个月内失败的常见原因，并提供了作者如果再次创业会采取的不同策略。文章指出，失败并非源于技术薄弱，而是由于基础不牢固。
文章首先指出，许多 AI 创业公司从工具入手，而不是从解决实际问题入手。作者强调，真正的吸引力来自于解决客户的痛点、实现可衡量的结果以及明确的支付意愿。其次，文章强调，仅仅使用 AI 已经不再是独特的卖点，差异化竞争优势应体现在更好的用户体验、工作流程集成、数据优势或利基市场专业化上。文章还强调了在构建产品之前进行验证的重要性，建议通过四周的循环验证来确保产品能够解决实际问题并获得用户付费意愿。此外，文章强调了分发渠道的重要性，认为 AI 创业公司失败的原因往往是缺乏分发渠道，而不是缺乏产品。最后，文章指出，AI 使得快速构建产品变得容易，但也容易导致功能爆炸，因此创业公司应该专注于一个能够带来变革性结果的旗舰用例。
总而言之，作者建议 AI 创业公司应该从一个受众和一个痛点入手，提供一个优雅的解决方案，并建立一个强大的分发渠道。先掌握这些基础，再考虑扩展。
- 原文: [Why Most AI Startups Fail (And What I’d Do Differently)](https://dev.to/jaideepparashar/why-most-ai-startups-fail-and-what-id-do-differently-4ph5)
- 作者: jaideepparashar
- 点赞数: 43
- 评论数: 36
- 发布时间: 2025-11-04 02:46:32
---
## 从怀疑到相信：AI 辅助开发的流程驱动方法
这篇文章主要介绍了作者通过与 Google Cloud 的 Keith Ballinger 的对话，转变了对 "vibe coding" 的看法，并分享了一种结构化的 AI 辅助开发流程模板。作者最初对 "vibe coding" 持负面态度，认为它会导致工程师草率提交有缺陷的代码。
但通过 Keith Ballinger 的演示，作者意识到 "vibe coding" 并非完全是混乱的，而是一种可以将模糊的想法转化为具体计划的结构化方法。这个模板包括以下几个步骤：首先，从用户角度出发，定义用户体验；其次，获取编程语言建议；然后，创建技术蓝图；接着，生成详细的、清单式的计划；最后，给 AI 提供关于如何工作的元指令，甚至可以添加个性化设置。
作者强调，这种方法适用于探索和加速两种场景。在不熟悉的领域，它可以作为探索工具，快速实验和迭代；在熟悉的领域，它可以作为加速工具，将开发者从繁琐的任务中解放出来。作者还分享了自己对流程的重视，并希望通过结构化的工作流程来提高协作和效率。总而言之，作者通过亲身实践和学习，从对 "vibe coding" 的怀疑转变为认可，并总结出一套可行的 AI 辅助开发流程。
- 原文: [From Skeptic to Believer: A Process-Driven Approach to Vibe Coding](https://dev.to/mollie_pettit_2fa2a4d10f7/a-skeptics-guide-to-vibe-coding-213p)
- 作者: mollie_pettit_2fa2a4d10f7
- 点赞数: 8
- 评论数: 2
- 发布时间: 2025-11-05 23:05:11
---
## 自托管AI代理的联邦应用商店
文章介绍了一个用于自托管AI代理的联邦应用商店，旨在解决企业自建代理或将数据发送给第三方服务器的问题。该应用商店允许用户发现由他人构建的AI代理，并在自己的基础设施（私有云、本地环境等）上运行它们，而无需将数据发送给第三方。
这个应用商店的关键架构包括：基于Git的联邦索引（采用fork机制，无需中心化的管理者），容器隔离和出口代理（用户可以配置代理可以访问的URL），凭据注入（API密钥在宿主机上配置，而不是在代理镜像中），模型抽象（支持Ollama本地模型、云API或混合模式），以及哈希链审计日志。
该平台目前已经可以工作，但代理索引的内容还比较少。作者希望有更多的代理开发者能够将他们的代理发布到这个应用商店中，同时也欢迎安全研究人员对该架构进行审查，以及寻找需要自托管AI基础设施的组织。该项目采用Apache-2.0开源协议，目前处于预发布阶段但功能可用。
由于没有评论内容，这里跳过评论分析。
- 原文: [Federated app store for self-hosted AI agents (Apache-2.0)](https://dev.to/agentsystems/federated-app-store-for-self-hosted-ai-agents-apache-20-19ka)
- 作者: agentsystems
- 点赞数: 4
- 评论数: 2
- 发布时间: 2025-11-05 06:31:30
---
## Build in Public: 第一周的开发实况记录
本文记录了作者在公开构建项目的第一周的进展，主要涉及后端技术选型、API 使用问题以及一些实际的花费。作者分享了团队在技术栈选择上的分歧，以及在使用 Bright Data 的 Instagram scraper 时遇到的问题。
文章详细介绍了项目初期遇到的挑战和进展。团队在后端技术选型上存在分歧，一位成员倾向于 Python，另一位则选择 Node.js。目前，他们同时维护了两个版本的后端，分别使用不同的技术栈。文章还提到了使用 Bright Data 的 Instagram API scraper 来获取 Instagram 数据的过程，以及使用 OpenRouter 和 Pydantic AI（Python 版本）或 LangChain（Node.js 版本）进行数据分析。作者分享了他们遇到的实际问题，比如 Bright Data 的 scraper 出现延迟，以及在 Google Workspace 上的意外花费。尽管遇到了一些挫折，但作者仍然保持乐观，并计划在下周继续改进项目，包括进行用户调研和优化 scraper 性能。此外，作者还分享了 Python 和 Node.js 版本的代码仓库，鼓励大家参与项目。
由于没有评论内容，这里跳过评论分析。
- 原文: [Build in Public: Week 1](https://dev.to/olgabraginskaya/build-in-public-week-1-o8a)
- 作者: olgabraginskaya
- 点赞数: 16
- 评论数: 5
- 发布时间: 2025-11-08 10:47:36
---
## 程序员的快乐源泉：Meme Monday
今天又到了程序员们喜闻乐见的 Meme Monday！本周的封面图片来自上周的帖子，DEV 社区一直致力于创建一个包容友好的环境，任何低俗的幽默都会被管理员反对。
如果你觉得一天一个 Meme 不够看，可以去 DUMB DEV 网站，那里每天都是 Meme Monday，保证让你乐开怀！这是一个专门分享各种编程梗图的地方，让你在繁忙的开发工作中也能找到一丝轻松和快乐。无论是遇到 Bug 时的无奈，还是成功解决问题后的喜悦，都能在这里找到共鸣。毕竟，程序员的生活除了代码，也需要一些幽默来调剂。所以，快去 DUMB DEV 看看，今天又有什么新的梗图让你会心一笑吧！
- 原文: [Meme Monday](https://dev.to/ben/meme-monday-4dha)
- 作者: ben
- 点赞数: 22
- 评论数: 91
- 发布时间: 2025-11-03 13:26:38
---
## 开发者为何讨厌会议？并非时间问题
这篇文章探讨了为什么软件开发者普遍反感参加会议，指出问题的关键不在于会议占用时间，而是会议本身对开发者工作效率的负面影响。
文章首先反驳了开发者不喜欢与人交流的刻板印象，强调简短高效的沟通对开发者非常有价值。真正让开发者深恶痛绝的是那些冗长、无意义的会议，例如本可以通过邮件解决的问题，或者反复讨论同一话题，以及与会者对会议内容一无所知的情况。作者以自身经历为例，说明作为高级开发者，常常因为会议过多而影响工作效率，甚至为了避免被打断而逃避复杂任务。
文章还驳斥了“多任务处理”的谬论，指出在会议中试图同时处理其他工作实际上是上下文切换，会极大地消耗脑力。开发者真正需要的是深度专注，进入心流状态才能高效解决问题。然而，频繁的会议打断了这种状态，导致开发者需要花费大量时间重新进入工作状态。
文章随后分享了一些提高会议效率的实用技巧，包括：在安排会议前自问是否真的需要会议，尽量只邀请必要的参会者，用一句话概括会议目标，将默认时长设置为15分钟，会议以事实开场，以明确的决策和负责人结束，并在会后发送简短的总结。此外，作者还建议在头脑风暴前进行异步准备工作，以便会议直接进入解决方案层面。
最后，作者鼓励读者分享本周因会议而损失的专注时间，共同探讨会议的真实成本。
- 原文: [The Real Reason Developers Hate Meetings (It’s Not Time) 🧠💥](https://dev.to/sylwia-lask/the-real-reason-developers-hate-meetings-its-not-time-31do)
- 作者: sylwia-lask
- 点赞数: 29
- 评论数: 28
- 发布时间: 2025-11-07 12:14:14
---
## Math.random 的缺陷与密码学安全
本文探讨了 `Math.random()` 的局限性，指出它并非真正的随机数生成器，而是确定性的，这意味着其输出是可以预测的。虽然在快速生成随机数的小应用中可能无关紧要，但在安全性至关重要的场景下，例如密码生成、数据加密等，`Math.random()` 的缺陷可能会导致严重的安全问题。
文章解释了为什么计算机难以生成真正的随机数，以及伪随机数生成器（PRNG）的原理。PRNG 虽然在很多情况下够用，但并非真正的随机，如果设计不安全，可能会被逆向工程破解。文章进一步阐述了密码学安全伪随机数生成器（CSPRNG）与普通 PRNG 的区别，CSPRNG 难以通过密码分析破解，即使其状态被泄露，也无法回溯到之前的值或预测未来的值。
`Math.random()` 在过去常常无法满足这些要求，因为它产生随机数时碰撞的频率过高，容易被破解。尽管现在已经改进，但通过了解生成器的初始或后续状态仍然可以预测其输出。
文章介绍了 `Crypto.getRandomValues()`，这是一个更安全的替代方案。它通过 API 调用，利用用户提供的种子来增加熵，从而生成更难以预测的伪随机数。在大多数浏览器中，"用户"指的是允许用户交互的服务，而不是直接操作键盘的人。这种方式使得生成器能够快速运行，而无需真正的随机数生成器。
最后，文章强调，在处理用户数据或需要加密的场景下，必须警惕 `Math.random()` 的风险，并建议使用 `Crypto.getRandomValues()`。对于不涉及安全性的简单应用，`Math.random()` 可能仍然适用，但过度复杂化代码也可能得不偿失。
总而言之，选择合适的随机数生成器取决于具体的应用场景和安全需求。了解 `Math.random()` 的局限性以及 `Crypto.getRandomValues()` 的优势，有助于开发者做出明智的决策，保护用户数据和系统安全。
- 原文: [Math.random, friend or foe?](https://dev.to/opbright/mathrandom-friend-or-foe-148o)
- 作者: opbright
- 点赞数: 8
- 评论数: 4
- 发布时间: 2025-11-04 08:16:53
---
## 使用 n8n 构建你自己的 AI Agent
本文介绍了如何使用 n8n 这一可视化工作流自动化工具，无需编写大量代码，就能构建属于自己的 AI Agent。文章详细讲解了 AI Agent 的功能，以及如何一步步使用 n8n 搭建一个简单的 AI Agent。
文章首先展示了作者构建的 AI Agent 的功能，例如查询天气、获取 YouTube 订阅者数量、查看 Strava 跑步数据，以及发送包含完整对话摘要的邮件。这些功能展示了将多个数据源结合，并让 AI 模型进行推理的可能性。
n8n 允许用户通过拖拽节点的方式创建自动化步骤，包括 AI 推理步骤。文章提供了一个快速入门指南，指导读者创建自己的 AI Agent。
首先，需要在 n8n 上创建一个免费账户。然后，创建一个新的工作流，并添加一个 AI Chat Trigger，这将提供一个公共聊天界面 URL。接下来，添加一个 AI 模型节点，可以选择 Google Gemini 或 OpenAI Chat Model，并设置一个系统提示，例如“你是一个可以回答问题并在需要时使用工具的私人助理”。
为了让 Agent 记住上下文，可以添加 Conversation Memory。最后，可以添加各种工具，例如 Weather API，YouTube Data API，Strava API，GitHub API，Gmail 节点等，来实现各种功能。
文章强调，构建 AI Agent 并不需要高级的开发技能，最困难的部分通常是获取和配置 API 凭证。一旦设置好这些，一切都会变得更容易。文章鼓励读者进行实验，尝试小的想法，并随着新需求的出现让 Agent 自然地成长。
目前还没有评论，无法分析评论区的观点。
- 原文: [I Built My Own AI Agent using n8n — And You Can Too](https://dev.to/debs_obrien/i-built-my-own-ai-agent-and-you-can-too-56l1)
- 作者: debs_obrien
- 点赞数: 17
- 评论数: 5
- 发布时间: 2025-11-06 16:09:14
---
## 停止使用“冒名顶替综合征”这个词
这篇文章指出，将职场中觉得自己不够好、害怕被揭穿的感觉归为“冒名顶替综合征”弊大于利。文章认为，这种感觉并非个人心理问题，而可能是对复杂工作环境的合理反应。
文章首先指出，软件开发领域变化迅速，知识更新迭代快，在这种环境下感到不确定是正常的，这代表你对领域范围有清晰的认知。真正的“冒名顶替者”反而是那些对自己的无知一无所知，盲目自信的人。其次，文章强调，将这种感觉称为“综合征”会将问题归咎于个人，而忽略了系统性问题。文章列举了模糊的任务要求、不合理的截止日期、团队中的偏见、不良的知识共享文化等例子，说明这些环境因素才是导致这种感觉的真正原因。
文章进一步指出，有毒的内卷文化、糟糕的入职和指导、缺乏心理安全感是导致这种感觉的三个主要因素。因此，文章建议用更准确的语言来描述这种感觉，例如“我正处于快速学习阶段”、“我正在经历成长的自然不适”、“我的工作场所缺乏心理安全感”等。这种语言的转变可以将问题从个人缺陷转变为外部挑战，从而促使人们寻求正确的解决方案。
文章最后呼吁进行系统性变革，管理者需要营造安全的氛围，让员工可以坦诚地说“我不知道”；资深开发者需要分享自己的挣扎和知识盲区；公司需要奖励可持续的协作工作，而不是不切实际的英雄主义。文章强调，这种感觉往往只是胜任者在要求高、变化快、管理不善的领域中的成长之痛，你应该关注环境的改变，而不是认为自己有问题。
- 原文: [We Need to Stop Calling It 'Imposter Syndrome'](https://dev.to/_boweii/we-need-to-stop-calling-it-imposter-syndrome-282i)
- 作者: _boweii
- 点赞数: 15
- 评论数: 11
- 发布时间: 2025-11-06 00:12:12
---
## 后端开发者SaaS主页设计之旅
本文讲述了一个后端开发者从零开始，通过不断迭代和接受反馈，最终设计出更吸引人的SaaS产品主页的历程。文章详细记录了主页的各个版本，以及作者如何根据用户反馈进行改进，包括色彩运用、动画效果和内容呈现方式。
作者最初的主页设计非常简单，只有黑红两色，功能列表和一个截图。随着SaaS版本的推出，作者尝试加入动画效果，并修改了标语，但效果并不理想。在Reddit上获得反馈后，作者意识到设计需要更多色彩，内容应该更关注用户而非产品本身。
为了改进设计，作者尝试在文本中使用更多颜色，但结果过于花哨。随后，他改变策略，在页面部分区域使用浅色背景，并用动态GIF替换了复杂的流程图，同时添加了通知渠道和使用案例等内容。为了增加趣味性，作者还在页眉、页面分隔处和通知区域添加了动画效果。
最终，作者尝试使用AI工具Copilot CLI来改进设计。通过输入提示语，AI能够针对每个组件和页面进行优化，最终效果显著提升，包括添加了面部动画和Hero区域的悬停效果。作者强调，持续学习和改进是关键，来自陌生人的反馈也起到了重要作用。
- 原文: [My SaaS homepage design journey as a backend developer](https://dev.to/vincentbean/my-saas-homepage-design-journey-as-a-backend-developer-32d4)
- 作者: vincentbean
- 点赞数: 12
- 评论数: 4
- 发布时间: 2025-11-06 15:05:11
---
## 使用 Go 语言和 SSH 构建多人贪吃蛇游戏：sshOuroboros
本文介绍了一款使用 Go 语言开发的，通过 SSH 终端进行多人在线游玩的贪吃蛇游戏 sshOuroboros。玩家在游戏中控制蛇，通过吞噬自己的尾巴或到达已占领的格子来扩张领地，并可以攻击其他玩家的蛇。
文章详细讲解了游戏的核心机制和实现原理。首先，玩家通过 SSH 连接到服务器，选择一个颜色作为自己的蛇。游戏世界由 35 万个格子组成，为了保证性能，作者没有采用传统的泛洪填充算法，而是设计了一种并发的简化实现方案，利用 Goroutine 并发探索领地。游戏中有大量的由 AI 控制的蛇，为了避免性能问题，作者将 AI 策略直接分配给玩家并在主循环中运行。文章还介绍了如何将庞大的游戏世界在终端上进行渲染，以及作者对未来功能的设想，例如添加 Lua 虚拟机以支持用户自定义 AI 策略。
作者开发此游戏的初衷是为了对抗 AI 将取代程序员的论调。在开发过程中，作者发现 AI 在解决泛洪填充和并发问题方面表现不佳，但在生成样板代码方面很有帮助。作者认为，虽然 AI 无法完全取代程序员，但可以作为一种辅助工具来提高开发效率。
由于没有评论内容，这里就不进行评论分析了。
- 原文: [sshOuroboros terminal multiplayer game written in goLang with ssh.](https://dev.to/mshel/sshouroboros-multiplayer-game-in-golang-with-ssh-and-the-story-1399)
- 作者: mshel
- 点赞数: 7
- 评论数: 6
- 发布时间: 2025-11-05 21:44:56
---
## Fortify：AI 驱动的安全分析平台
Fortify 是一个综合性的安全和合规分析平台，旨在帮助开发者识别漏洞、确保 SOC2 合规性，并提供可操作的建议，所有这些都由 AI 和现代架构驱动。它通过实时安全分析，解决了安全审计成本高、耗时且通常在开发周期中发生太晚的问题。
Fortify 提供了以下核心功能：漏洞检测（包括 SQL 注入、XSS 和硬编码密钥等）、合规性检查（SOC2 Type II 和 ISO 27001:2022 评估）、AI 驱动的修复建议（使用 Groq AI 生成上下文代码修复），健康评分（基于发现的动态安全评分）以及 GitHub 集成（通过 URL 分析整个存储库）。
该平台的技术栈包括前端的 Next.js 15、React 18、TypeScript 和 Tailwind CSS，后端的 Next.js API 路由（无服务器），AI 采用 Groq (llama-3.3-70b-versatile) 并带有 Perplexity 作为后备，部署在 AWS Amplify 上，数据库则使用 PostgreSQL。
Fortify 架构设计上可以利用 Tiger Agentic Postgres 的高级功能，例如使用时间序列分析进行会话管理，混合搜索进行漏洞检测，利用零拷贝快速 Fork 进行并行分析，使用流体存储实现高并发，以及通过 Tiger MCP 集成实现多代理分析。
具体来说，文章提到使用 Tiger Agentic Postgres 的时间序列分析来跟踪分析性能，识别瓶颈并优化分析流程。混合搜索则用于智能漏洞去重和类似问题检测。零拷贝 Fork 加速并行处理，而流体存储则支持高并发分析。Tiger MCP 则用于协调多代理工作流，实现状态管理和回滚。
- 原文: [Fortify - AI Powered Security Analysis Agent powered by Tiger Agentic Postgres](https://dev.to/abhinandan-r/fortify-ai-powered-security-analysis-platform-54i8)
- 作者: abhinandan-r
- 点赞数: 40
- 评论数: 2
- 发布时间: 2025-11-03 18:28:28
---
## GitHub Copilot 最新十大更新解读
本文总结了 GitHub Copilot 在 2025 年 10 月底发布的一系列重大更新，包括 Agent 机制、更智能的代码审查、嵌入、指标等。文章旨在帮助开发者快速了解并掌握这些新功能。
文章首先强调了安全检查的重要性，建议开发者移除不必要的高风险工具，限制 Token 权限，并增加人工审核环节。随后，文章详细介绍了 GitHub Universe 的更新，指出 GitHub 用户数量激增，AI 成为重要驱动力，Copilot 也因此获得大量升级。文章列举了十大更新，包括：Agent 机制的引入，将之前的“chat mode”替换为“agent”，并将其迁移到 `.github/agents/*.agent.md` 目录；新的 Agents 面板，方便用户管理和使用自定义 Agent；Copilot CLI 的增强，支持自定义 Agent，并改进了模型选择、图像支持和 UI；Coding agent 功能的扩展，可以处理任何打开的 Pull Request，并支持 Slack 和 Copilot CLI。此外，文章还提到了其他更新，如更智能的代码审查、嵌入、指标等，但没有详细展开。作者以幽默风趣的口吻，分享了自己在使用这些新功能时的体验和感受，并鼓励读者积极尝试并分享反馈。
由于缺乏评论数据，无法进行评论观点的总结和分析。
- 原文: [Top 10 GitHub Copilot Updates You Actually Need to Know About 💥](https://dev.to/anchildress1/top-10-github-copilot-updates-you-actually-need-to-know-about-297d)
- 作者: anchildress1
- 点赞数: 17
- 评论数: 4
- 发布时间: 2025-11-05 17:50:45
---
🫵 来啊，说点有用的废话!
▲
