Ilence Ye

链接

  • Building a Serverless Blog with Astro, Cloudflare, and Zero Monthly Cost | Scope Creep Labs Blog

    问题：如何构建一个零月费、可部署在边缘网络的技术博客。 方法：使用 Astro 的 hybrid rendering (SSG + SSR) 架构，在 Cloudflare Pages 上部署，公开博客路由使用 SSG，后台管理路由使用 SSR，并结合 D1 (SQLite) 与 R2 组成 serverless 架构。

    问题：如何在无外部 CMS 的情况下实现自定义博客管理后台。 方法：在 Astro 中实现 /admin/* SSR 页面作为自建 CMS，通过 Cloudflare Worker 运行时访问 D1 数据库，使用 Basic Auth 中间件进行简单鉴权，并通过 API 路由处理文章与资源管理。

    问题：如何实现 Markdown 编辑器中的粘贴即上传图片并自动压缩。 方法：在浏览器端监听 paste 事件，使用 OffscreenCanvas 将图片压缩为 WebP 后上传到 Cloudflare R2，再将返回的 URL 自动插入 Markdown。

    #tutorial

  • seo for astro sites — what actually matters — friquelme.dev

    Make the site discoverable by search engines, shareable on social platforms, and subscribable via RSS …

    The SEO layer has five parts:

    • Sitemap — auto-generated XML for crawlers
    • Meta tags — open graph and twitter cards for social sharing
    • Canonical URLs — one true URL per page
    • JSON-LD — structured data for rich search results
    • RSS — feed for subscribers and aggregators
    #tutorial

  • Hosting images on my Astro blog with Cloudflare R2

    问题：Astro 博客图片存储在 GitHub 仓库导致仓库体积和带宽成本不断增长。 方法：将图片迁移到 Cloudflare 的 Cloudflare R2 对象存储，通过自定义 CDN 域名提供图片访问以降低存储与带宽成本。

    问题：使用 R2 等对象存储后缺少 Astro 内置的图片优化 (responsive images、格式转换)。 方法：使用脚本 + Sharp 生成多尺寸 (640 / 1200 / 1920 px) 的 .webp 图片，并通过 <picture> / srcset 在组件中实现 responsive images。

    问题：Markdown 图片语法无法直接支持 CDN 响应式图片与尺寸控制。 方法：创建自定义 ImageCdn 组件生成 R2 CDN 图片 URL，并通过脚本将 Markdown ![]() 批量转换为组件调用以统一渲染逻辑。

    #tutorial

  • Better defaults for popovers - Manuel Matuzovic

    问题：HTML popover 默认定位在 viewport 中央 ( 类似 dialog )，不符合多数需要贴近触发按钮的 UI 场景。 方法：利用 CSS Anchor Positioning ( popover 自带 implicit anchor )，通过 position-area 将 popover 相对于触发元素定位。

    问题：popover 在靠近 viewport 边缘时可能发生溢出。 方法：使用 position-try-fallbacks 让 popover 在 inline / block 轴上自动翻转位置。

    问题：部分浏览器 ( 如 Safari ) 尚不支持 CSS Anchor Positioning。 方法：使用 @supports feature query，仅在支持 position-area 时启用相关定位规则。

    #tutorial

  • How I Use Claude Code | Boris Tane

    本文作者分享了使用 AI 编程工具 Claude Code 长达 9 个月后形成的一套独特工作流。其核心原则是在审核并批准书面计划之前，绝不允许 AI 编写任何代码，通过严格分离规划与执行来提升开发质量。

    作者的工作流分为三大阶段。首先是研究阶段，作者要求 Claude 深入阅读代码库的相关部分，理解其细节和特异性，并将所有发现写入一个持久的 research.md 文件中，供作者审查。这一步旨在确保 AI 真正理解现有系统，防止后续实现破坏现有功能。第二阶段是规划阶段，作者要求 Claude 基于研究撰写一份详细的 plan.md，包含具体方法、代码片段、待修改文件路径和权衡考虑。随后，最关键的标注循环 开始：作者在编辑器中审阅计划，直接在文档中添加内联注释，以纠正假设、拒绝错误方法或补充领域知识，然后让 Claude 根据这些注释更新计划。这个循环会重复 1 到 6 次，直到计划完美无缺。最后是实施阶段，作者会用一个包含明确指令（如全部实现、标记完成、不停止、维护代码风格、持续运行类型检查）的标准化提示，让 Claude 按照最终确定的计划一次性执行所有任务。作者作为监督者，在实施过程中仅通过简短的指令进行微调或纠正。

    这个工作流的关键在于利用 Markdown 文件作为人与 AI 之间的共享可变状态，让作者能够以结构化、渐进的方式注入自己的判断和领域知识，将 AI 的创造力引导至正确的方向。作者认为，这种方法能有效避免因 AI 早期错误假设而导致的无效工作和返工，最终交付更高质量、更贴合项目需求的代码。

    #article

  • “Why would anybody start a website?” - daverupert.com

    本文作者 Dave Rupert 围绕 Nilay Patel 在 Decoder 访谈中提出的问题 “为什么现在还有人会创建网站” 展开讨论。文章从微软 CTO Kevin Scott 介绍的 NLWeb 项目切入，该项目旨在让小型网站拥有自己的本地搜索索引，供大型 AI 平台调用，以替代当前“全面抓取”的模式。随后，作者重点剖析了 Nilay Patel 的观点：在当前环境下，创建网站的主要动机仅剩电子商务和应用开发，而新兴的创作路径是先做 TikTok 或 YouTube 等平台，再考虑网站。对此，Dave Rupert 表达了不同看法。他认为，尽管赚钱不易，但创建网站的理由依然众多且充满价值。网站是承载长内容、非竖屏视频、大尺寸图片、活动信息的最佳载体；拥有网站意味着你可以摆脱算法控制、通过 RSS 重塑注意力、真正拥有自己的内容、追求反商业理想或进行商业活动，甚至可以保持匿名和分享知识。最终，作者强调，创建网站的根本动力在于内心的热爱。

    #article

  • How the hell are you supposed to have a career in tech in 2026? - Anil Dash

    本文是 Anil Dash 在 2026 年初对科技行业从业者的一封公开信。他指出，尽管AI领域投资巨大，但科技行业正经历前所未有的动荡，自ChatGPT发布以来已有50万从业者被裁，市场环境恶劣。许多有才华、有思想的员工感到迷茫和沮丧。

    文章认为，问题的根源在于行业领袖的价值观沦丧：产品不再可靠，公司放弃道德责任，转向谄媚权贵，纵容歧视和腐败。这导致曾经以创造未来为荣的从业者失去了工作的自豪感和信念。

    面对这种困境，作者首先安慰读者“你并不疯狂”，这是系统性的问题，并非个人失败。随后，他提出了应对策略：

    1. 理解系统：要认清自己在组织系统中的真实角色，系统只在乎“效率”，可能导致个人技能被忽视。应从系统层面思考如何创造不可替代的价值。
    2. 理解权力：权力是控制预算、决策、人事的能力。个体需通过团结同事、创建新系统来巩固和行使权力，为自己创造更多选择。
    3. 拓宽视野：真正的机会不只存在于硅谷巨头或初创公司，大多数技术在传统行业或非营利组织中被应用。这些地方的文化往往更健康，也急需技术人才。
    4. 长期规划：保持终身学习的习惯，积极参与社区，分享知识，建立人脉。机会来临时，这些投资会带来回报。

    最后，作者强调，这不是一个能立刻解决的问题，而是一个持续演化的过程。通过关注可控的小事，坚持理想，团结协作，真正创造价值的技术工作者终将掌握行业的主导权。

    #article

  • Why We've Tried to Replace Developers Every Decade

    本文探讨了软件开发领域一个持续了五十多年的现象：每隔十年左右，就会出现一种旨在简化或取代专业开发者工作的新技术或方法。从 1960-70 年代的 COBOL 语言，到 1980 年代的计算机辅助软件工程工具，再到 1990 年代的 Visual Basic 和 Delphi，以及 2000 年代以来的各种低代码/无代码平台和如今的 AI 编码助手，这个循环不断重演。尽管这些工具每次都承诺能让业务人员直接编写程序，从而减少对专业开发者的依赖，但最终结果都未能完全实现这一目标。

    作者指出，这个模式之所以反复出现，是因为人们误以为软件开发的复杂性主要来自语法或编码过程本身。然而，真正的复杂性在于处理业务逻辑的细节、边缘情况、系统集成、安全性和长期维护等需要深度思考的问题。无论是用 COBOL、可视化工具还是 AI 提示，都无法消除这种固有的逻辑复杂性。

    文章的核心观点是，这些新技术工具真正带来的价值并非取代开发者，而是让他们能更高效地工作，将精力从重复性劳动中解放出来，专注于解决更独特的挑战。AI 也不例外，它改变了开发者工作的方式，但并未消除对人类判断力的需求。

    最后，作者为领导者提供了建议：与其期待新工具能彻底解决问题，不如提出更务实的问题，例如它能否帮助团队更有效地处理复杂问题，或减少重复性工作。投资于培养开发者清晰思考复杂问题的能力，才是长久之计。这个不断重现的“取代梦”本身并非错误，它反映了对更高效软件创建方式的真实需求，并持续推动着工具的创新和进步。

    #article