我创建了可复用的 Claude Code 技能，以更快发布生产网站

大多数由 AI 生成的网站，失败并不是因为首页不好看，而是因为所有那些无聊的生产环节都被跳过了。

比如这些：

• SEO 元数据
• 预渲染
• 分析统计
• 社交分享图
• CSP 响应头
• Lighthouse 优化
• 移动端打磨
• sitemap 生成
• robots.txt
• 部署配置
• IndexNow
• 缓存
• 环境搭建

如今真正的 React 组件，往往已经是最简单的部分。

依然在拖慢一切的，是运维层面的基础设施。

用 Claude Code 做了几个 AI 辅助项目之后，我意识到自己在反反复复解决同样的问题——不只是视觉上的，更是运维上的。

于是我没有去写更长的提示词，而是开始构建可复用的 Claude Code skill。

结果变成了一个面向生产工作流的开源仓库：GitHub 上的 senternet-site-skills。这个仓库收录了一批面向生产、可复用的 skill，覆盖 SEO、预渲染、移动端优化、社交分享、CSP 配置、Lighthouse 调优、分析统计接入、部署流程等等。

「凭感觉写代码」的问题

我其实很喜欢 AI 辅助开发。非常喜欢。

在快速迭代、生成前端、重构布局、写工具代码、接入 API 和搭建内容骨架上，Claude Code 强大得惊人。

但最初的兴奋劲过去之后，一个规律浮现出来：AI 生成页面的速度，快过你把它们投入生产的速度。

于是你会把大量时间花在修这些东西上：

• SEO 问题
• 部署不一致
• 坏掉的元数据
• 糟糕的移动端表现
• 缺失的分析统计
• 性能回退
• 社交预览的问题
• 不完整的生产配置

讽刺的是，这些往往正是人类最不愿意反复手动去做的事。而这恰恰让它们成了可复用 skill 的完美候选。

从巨型提示词，到可复用的工作流

起初我试图用越写越长的提示词来解决。比如：

「请确保这个页面是移动端自适应的、为 SEO 做了优化、使用了预渲染、有正确的元数据、支持社交分享、带 CSP 响应头、接入了分析统计，并且部署设置在生产环境下是安全的……」

这个办法很快就变得不可靠。

Claude 会重点盯着其中一条指令，同时悄悄忽略另一条。有时它把功能实现了一半。有时它一边「帮忙」，一边把本来能用的东西弄坏了。

突破发生在我不再把提示词当作对话，而开始把它们当作基础设施的时候。

我不再写巨型提示词，而是创建了一批聚焦、可复用的 skill：

• senternet-site-metatags
• senternet-site-prerender
• senternet-site-mobile-optimize
• senternet-site-share-images
• senternet-site-csp
• senternet-site-lighthouse
• senternet-site-indexnow
• senternet-site-firebase

每个 skill 都有范围收窄的职责、确定性的预期、运维上的护栏，以及可复用的实现逻辑。产出的稳定性因此显著提升。

最重要的想法：运维上的一致性

AI 在生成组件上出奇地好，但在跨多个项目持续维护生产基础设施上，就差得多了。

人类天然会记得这类事情：

• 「我们加 OpenGraph 标签了吗？」
• 「这条路由做预渲染了吗？」
• 「robots.txt 配好了吗？」
• 「这张社交图裁切会正常吗？」
• 「Lighthouse 分数还在可接受范围内吗？」
• 「分析统计加进生产布局了吗？」

除非被明确引导，AI 往往会把这些细节忘得一干二净。这正是可复用 skill 显出威力的地方。运维标准不再依赖记忆或反复提示，而是被编码进可复用的工作流里。

目标从来不是完全自动化，而是减少被遗漏的工作。

「超级 skill」这个概念

最有用的模式之一，最后变成了我开始称之为「超级 skill」的东西。它们不处理单一孤立的任务，而是把多个配置步骤编排在一起。例如：

• 检测哪些东西已经配置好了
• 跳过已完成的配置
• 识别缺失的生产功能
• 只做增量式改进
• 避免破坏性的重写

最后这一条尤其重要。AI 编程工具最大的失败模式之一，就是你要求改一处，却得到一次意外的全项目重构。这些 skill 在很大程度上约束住了这种行为。

真正改善的是什么

最大的收获不是写代码更快，不是生成更漂亮的组件，也不是少敲几个键。最大的收获是：

• 更少的功能回退
• 更少被遗忘的部署细节
• 更少的 SEO 错误
• 更少重复的配置工作
• 更一致的生产就绪度
• 更轻的决策疲劳

换句话说：一旦工作流变得更有结构，AI 就变得更有用了。

真实世界中的使用

这些工作流最终成为了以下项目生产流程的一部分：

• StockCar（stockcar.app）
• BeeReady（beeready.buzz）

两个项目都受益于反复施加同一套运维标准：元数据处理、移动端优化、分享图流程、SEO 结构、部署一致性和性能优化。如果没有可复用的 skill，我就得在每个项目上把同样的基础设施问题重新解一遍。

AI 辅助开发仍然吃力的地方

即便有了可复用的 skill，局限依然明显。Claude Code 仍然可能：

• 对本来能用的代码过度重构
• 凭空编造架构决策
• 把自适应布局改坏
• 发明不必要的抽象
• 只执行了一部分指令
• 漏掉细微的体验不一致

前端的打磨依然需要人的判断，而且需要很多。但结构化的工作流，能把混乱大幅压下去。

我目前的看法

我越来越觉得，AI 辅助开发的未来，看起来不太像「写提示词」，而更像「运维工程」。拿到最好结果的开发者，多半不会是那些写最长提示词、把所有约束都拿掉，或者一味追逐全自主智能体的人。

而会是那些构建可复用工作流、受约束的系统、可组合的工具、确定性的基础设施和运维护栏的人。真正的杠杆来自把一致性编码下来，而不只是生成代码。

最后一点想法

AI 编程工具已经非常能干了。但「做出一个演示」与「反复交付可上线的生产网站」之间，依然有着巨大的差距。

对我来说，可复用的 Claude Code skill，成了跨过这道差距的方式。它并不取代工程上的自律，而是让这份自律更容易被一致地施行。