写作与想法

网站上的跟读音频通常意味着有一台服务器：用户点播放，服务端跑 TTS、推流，或者至少从数据库里查一条录音。我想在这个站上也有音频——播放按钮和可选的按词高亮——但不加任何运行时。站点保持静态：每页预渲染，CDN 只负责发文件。没有函数调用，生产环境也没有 TTS 用的 API key。…

「在生产环境出错」是默认状态。坏链照样上线，主题描述里有个 typo 没人发现，frontmatter 少必填字段 build 照样跑——直到某页渲染错或 feed 崩了。错误在用户打开页面或你几周后才发现时出现，那时问题已经上线、被缓存，更难回溯。 改成在构建时失败。把校验当成内容流水线的一等公民。有问题就不让…

越来越多人倾向于在服务端动态渲染一切。Edge 来了之后，说法是动态渲染几乎免费：在 edge 跑个函数、毫秒级返回 HTML，用户无感。那还折腾静态生成干什么？ 但物理规律还在。再快的 edge function 也快不过从 CDN…

同一个站你看过一百遍了。一样的圆角、一样的灰底白卡、一样的渐变 hero 加 CTA。不难看，但也和上季度上线的每一个产品长得差不多。 这和内容上的老问题一样：没有约束的 agent 产出泛用文案。同样的逻辑正在 UI 上重演。默认组件库和没被教过你约束的…

常有人问 wchen.ai 怎么做多语言、怎么在英文、西语和中文之间保持同步而不靠复制粘贴。简短回答：站点围绕一套清晰的内容模型来建，两个 agent skill——website-content 和 content-translation——规定内容放在哪、如何扩散。架构负责重活，两个 skill…

技能里塞得越多就越有用——直到不再有用。一个 SKILL.md 想把每种内容类型、每种 schema、每种语气规则都写进去，可以轻松上百行。Agent 会一次性全加载。Token 预算被烧掉，真正和当前任务相关的部分淹没在噪音里。 我设计技能时，让主文件当路由器，不当垃圾桶。它告诉 agent…

你正在读的这篇博客是 AI 代理写的。但听起来像是我写的。 这不是巧合。我写了一个 skill——一套可复用的指令——教代理如何用我的口吻写、按我的内容 schema 来、按我会用的结构组织文章。这篇文章既是说明，也是证明。 真正的问题不是能力…

你可以跑一个带评论和动态的静态站，而不跑数据库也不跑 API。做法就是把 GitHub 当成你从不用运维的后端。 身份、存储、动态通常意味着鉴权、数据库和某种实时更新。对个人站或小项目来说，零件太多了。 我希望读者能评论，也希望展示近期工作——又不想再起一个服务或为评论 SaaS…

静态站不会在有人打开页面时跑代码，这正是目的。但 newsletter 需要动态：接收订阅、发确认邮件、处理点击、把联系人加进列表、发欢迎信。那怎么既保持站点静态，又完整掌控整个流程？ 我的做法是：用 Resend 发信，用 Cloudflare Pages Functions 提供那一小块 API。HTML…

多数「发定期摘要」的建议都假设你需要一个调度器：cron、定时触发的 Lambda，或托管服务「每周二 9 点跑」。如果你的内容在 CMS 里全天更新、你只想在固定时间抓一版，那没问题。但若站点是静态的、内容只在部署时变化，调度器就是错误的抽象。 我把摘要当成 CI 里的一步，紧接在站点 build 和 deploy…

我想在文章和项目页有评论区，但不想自己跑数据库或写 API。 静态站很好，直到你需要有地方存状态。评论就是这种——别人的数据，挂在你的内容上。常见选择要么很重（Disqus，广告和追踪），要么是坑（自建 Commento、审核、垃圾）。我不想再维护一个服务，也不想为评论 SaaS 付钱，免得以后不想管了还得惦记。…

给 newsletter 或营销 drip 选邮件服务商，听起来应该很简单：发邮件、收订阅、也许统计打开。市场很挤：Buttondown、Resend、ConvertKit、Mailgun 等一堆都说能搞定。…

给静态站加邮件本该是已解决的问题。 我只需要：收联系表单提交、用自己域名发回复。听起来简单，但现代邮件服务商生态感觉非常碎片化。 一开始试了 MailChannels，号称在反垃圾上比别家强。但物理规律不变——文档差、开发体验到处是摩擦，理论优势就没意义。我花在折腾配置上的时间比写代码还多。 Formspree…

我用 Netlify 用了好几年。它是第一个让部署静态站几乎零负担的平台——git push、等三十秒、完事。很长时间里这就够了。 后来不够了。 千刀万剐 Netlify 没有崩盘，是一点点被侵蚀。免费档限制悄悄变严，build 分钟数从可以忽略变成要盯着看，定价开始围着团队和企业转，单人开发体验——当年让…

每个项目都从同一个不起眼的决定开始：这东西到底跑在哪？ 多数开发者把托管当成一个勾选项。选默认、部署、继续。我以前也一样。但做得越久越清楚：托管平台不只是基础设施，它是架构约束，会塑造后面每一个决定。 这个站和我要发的东西，我都选了 Cloudflare。不是因为跟风，而是因为它和「软件该怎么工作」的想法一致。…

我不会在 Cursor 里开启一个新项目。我会先去 ChatGPT。 在 repo 出现之前，先有一个想法。在实现计划出现之前，通常只有一个半成形的直觉，在我脑子里听起来比它实际更聪明。我已经学会不相信那个第一版。所以现在我会把这个想法讲给一个…

第一次用 spec-kit 时，我塞进去一段含糊的需求就点了运行。出来的 spec 技术上成立——但 practically 没用：太宽、太野心、和编码代理一次会话里能执行的东西脱节。 问题不在工具，在我的输入。 在多个项目里跑了几十次 spec-kit…