昨晚10点，我萌生了一个模糊的想法，想把Directus部署变成销售资产。今早7点，我已经有了Railway上运行的管理后台、三个实时仪表板、一个包含五篇文章的公开演示博客、一篇2400字的销售支柱内容来推销整个项目作为服务，还有三个我在午夜捕获并修复的生产bug。总基础设施成本：每月5美元。总耗时：跨越一个夜晚和一个清晨，大约9小时的专注工作。
这就是案例研究。构建了什么、什么出了问题、我学到了什么，以及这个项目背后的实际数据。如果你在评估是否为你的业务委托类似的项目，下面的数据点是我能提供的最诚实的参考。
我打算做的事
三个目标，按优先级排列。
首先，部署Directus并连接到我现有的Supabase Postgres数据库。目标：一个指向我的自定义Astro管理后台已经管理的相同数据的通用CRUD管理界面。原因：不是为了替换自定义管理后台（团队喜欢它的Monday风格的行内编辑），而是为了添加自定义管理后台没有的操作层。批量编辑、保存的视图、基于角色的权限、schema浏览器、Insights仪表板。
其次，建立我六个月来一直想要的仪表板。三个板块：内容管道（博客发布速度、选题队列深度）、SEO 健康度（排名位置、AI Overview 出现率、意图分布）、工具使用情况（AEO 工具搜索、品牌工具搜索、顾问使用情况）。周一一眼就能看到的具体数字，让我知道引擎是否在正常运转。
第三，把整个构建变成销售资产。我为自己部署的 Directus 管理后台与我为客户部署的完全相同。所以部署本身就成了演示。潜在客户在我的销售页面上点击一个按钮，进入一个填充了真实数据的真实 Directus 管理后台，在富文本编辑器中输入内容，看到保存的视图如何工作，然后回到页面预约通话。整个演示流程的摩擦：从登陆页面到实时编辑器大约十五秒。
第 0 到 4 小时：部署
Railway 爱好计划、官方 Directus 模板、一键部署。该模板包含 Directus 加 Redis 加捆绑的 PostGIS 数据库加 S3 兼容存储桶。从空白 Railway 账户到登录管理后台的总部署时间（包括配置）：35 分钟。
第一个意外：Directus 模板通过指向捆绑 PostGIS 服务的引用变量连接其数据库，而不是通过单个的主机/端口/用户/密码字段。要将 Directus 重定向到我的外部 Supabase Postgres，我需要找到连接字符串变量（DB_CONNECTION_STRING）并粘贴我的 Supabase Session 池化程序 URL 和凭证。
第二个意外：我的 Supabase 数据库密码包含字符"#"。在 Postgres 连接字符串中用 URL 编码表示为 %23。没有编码的话，URL 解析器会在 # 处切断字符串，因为井号表示 URL 片段。Directus 记录了 ECONNREFUSED::1:5432，因为连接字符串格式不正确时它回退到了本地主机。折腾了半小时后，我把密码改为仅包含字母数字，连接就建立了。
Directus 连接后，我的 Supabase 数据库中全部 12 个表都自动导入为 Directus Collections。零模式迁移、零数据移动、零停机时间。自定义 Astro 管理后台和 Directus 管理后台都看到相同的数据，都可以写入，都能立即反映彼此的变化。
第 4 到 12 小时：配置、配置、配置
大部分工作不是部署。而是字段级配置，让 Directus 表现得像一个精致的管理后台，而不是原始数据库浏览器。每一列都需要接口元数据、显示格式、排序顺序、宽度、分组和可见性决策。默认 Directus 显示所有内容；精致版本只显示团队需要的内容。
这个阶段有三个观察。
通过 Directus 管理界面点击完成这项工作很慢。大约每个字段需要两分钟，跨十二个集合的九十多个字段，总点击时间接近三小时。我委托给一个浏览器驱动的 AI 代理（Chrome 中的 Claude），它转而使用 Directus REST API 进行批量配置。该代理按顺序发送 PATCH /fields/{collection}/{field} 调用，完整的 meta 对象作为载荷。每个集合三分钟，而不是四十分钟。整个配置阶段从三小时压缩到四十分钟。
REST API 方法还给了我可重现性。每个 PATCH 都是一个等效的 curl 命令，我可以在一个新的 Directus 部署上重新运行它以恢复相同的配置。配置实际上是代码，而不是脆弱的 UI 点击堆积。
这个阶段的最后四分之一是构建三个 Insights 仪表板。每个面板都是一个发送到 POST /panels 的 JSON 配置。一旦字段元数据就位，仪表板在大约二十分钟内完成。三个面板，六个面板，真实数据呈现。我六个月来一直在猜测的数字终于出现在屏幕上。
第 12 到 18 小时：耗时最多的三个 bug
没有构建是真实的，直到它在生产环境中崩溃。我部署到主分支并刷新实时网站后，三个 bug 出现了。
Bug 1：Spline 场景被 CSP 阻止，三个堆叠的原因
我还发布了一个以 Spline NEXBOT 机器人英雄为特色的 3D 优先网络支柱。部署后，机器人在生产环境中不可见，但在本地有效。三个堆叠的问题依次出现。
一：使用 define:vars 的脚本标签被 Astro 内联，这意味着 Vite 没有捆绑 @splinetool/viewer 的动态导入，这意味着浏览器中无法解析裸模块说明符。二：修复后，spline-viewer 元素在升级时位于具有隐藏属性的父元素内，因此 Lit 自定义元素以 0x0 尺寸初始化，永远无法恢复。三：修复后，Spline 查看器在场景加载时从 unpkg.com 获取其建模 WASM，我的 CSP 没有将其列入白名单。每个修复都暴露了下一个 bug。总调试时间：九十分钟。
仅生产环境调试是一门独立的学科。开发服务器解析裸导入的方式不同于生产构建。开发环境有一个更宽松的默认 CSP。没有实际的生产部署，这两个 bug 都不可能暴露。我的心得：即使本地工作正常，也要尽早部署到真实环境。
Bug 2：AI Overview 布尔值和 Postgres avg()
一个 Insights 面板想要显示"追踪的 SERP 运行中有多少百分比呈现 AI Overview"。seo_serp_runs 表有一个布尔型列 ai_overview_present。直觉想法：对该列求 avg()，乘以 100，渲染为百分比。
Postgres 对布尔值求 avg() 时报错。该类型不存在这个函数。几次尝试的解决方案都失败了：Directus 没有暴露"percentage"聚合函数、硬编码分母的真值计数会随着新行数据到达而漂移、查询时强制类型转换没有通过 Insights 面板选项暴露。
有效的修复方案：添加一个生成列 ai_overview_present_int，计算逻辑为 case when ai_overview_present then 100 else 0 end。对整数列求 avg() 简单有效，直接产生百分比结果。一行 SQL 迁移，零应用代码改动。
Bug 3：CSP 中的图像主机
我用五个 Unsplash 图片 URL 填充了演示博客。浏览器无声地阻止了它们，因为 images.unsplash.com 没有在 img-src 中被白名单化。公开演示博客上的图像卡是纯黑色的。我把 Unsplash 加入 CSP，图像渲染了，然后我意识到我刚刚违反了自己不可妥协的规则——对所有存储在 Supabase Storage 中的图像都要使用 FAL。
正确的修复方案：一个脚本遍历每一行 demo_posts，通过 FAL flux-pro/v1.1-ultra 为每个分类生成编辑图片，用 sharp 重新编码为 WebP 质量 82、最大宽度 1600，上传到一个公开的 Supabase Storage 存储桶，更新 featured_image 为存储 CDN URL。二十分钟的构建，五次 FAL 生成费用不到一英镑。从 CSP 中移除 Unsplash。图像现在存在我自己的基础设施中，没有外部依赖，没有持续的逐主机 CSP 更新问题。
第 18 到 24 小时：销售支柱
Directus 运行正常，演示博客渲染正确后，我在 /solutions/headless-cms-and-admin-tools/ 撰写了销售支柱。四个服务层（CMS、内部运营管理、目录、定制开发），用美元标价并在括号中附英镑，六个常见问题，一个对比表格对标 WordPress、HubSpot、Notion 和 Airtable，一个"我不会接的项目"部分以提前淘汰不适合的客户。
支柱直接链接到实时演示。点击"打开编辑器"的潜在客户进入实际的 Directus 管理后台，显示他们可以粘贴的凭证。几秒钟后他们在一个真实的编辑器中编辑一个真实的帖子。演示流程从页面加载到实时编辑只需十五秒。
支柱页面总时间：九十分钟的写作加三十分钟的 schema 标记、内部链接和视觉润饰。这个页面的花费时间比三个 bug 中的两个还少。
数字
构建成本明细，因为这是案例研究文章，这是潜在客户会问的问题。
Railway Hobby 计划（Directus + Redis + 存储桶）：每月 $5，按月计费。前 30 天免费。
Supabase Postgres：现有基础设施，无新增成本。已在使用 Pro 计划，数据库费用约为每月 $25。
FAL API 用于五张主图：总计不足一英镑，约 $1 美元。
DataForSEO 用于回溯填充 42 个关键词（搜索量 + 意图 + 难度）：总计 $0.04。
我的时间，从头到尾包括修复 bug 和撰写：九小时专注工作。按我的咨询日费率约 $1,500/天，约等于 $1,700 的机会成本。
交付可用销售资产的总现金支出：基础设施边际成本约 $6 加 API 费用 $1。包括时间的真实总成本：约 $1,700。
参考对比：一家代理机构报价"无头 CMS 管理工具构建"项目通常会为相同范围收费 $8,000 到 $15,000 美元。我在自己的服务页面上收费 $8,000 到 $19,000 美元。构建成本和销售价格之间的差距就是代理机构工作的整个经济引擎。这个案例研究证明了构建成本数字是真实的。
这向潜在客户证明了什么
三件事，都可以在接下来的十分钟内验证。
第一，这个构建是真实的。点击销售页面上的"打开编辑器"按钮。在富文本编辑器中输入内容。安排一篇文章发布。查看仪表板。这个东西确实存在。它不是模型，不是 Figma 文件，不是截图。它就是我会为你的业务部署的那个软件。
第二，速度是真实的。从"模糊的想法"到"生产环境部署的销售资产，带有实时演示"，只需二十四小时。客户项目不会以这个速度进行，因为客户项目包括需求发现、设计审查、利益相关者批准和安全审计。但底层的构建速度决定了六周的时间表是诚实的还是乐观的。二十四小时的个人构建工作量，折算成标准代理商项目的时间（包括开销）大约是三周。这个数学关系就是产生六到八周一级时间表的原因。
第三，失败模式是真实的。三个生产环境的 bug 在实时中被捕获和修复了。CSP 问题、动态导入捆绑、生成列算术。这些是在客户项目中出现的同样的 bug。我在实时网站上捕获并解决它们这一事实，就是能力的实际演示。一个没有 bug 的精致案例研究才是可疑的。
我会做不同的地方
三个小反思，按有用程度排列。
我应该在 Unsplash 变通方案之前就开始 FAL 图像生成脚本。CSP 更新然后回滚的舞蹈浪费了十分钟的不必要的折腾。关于 FAL 图像的不可协商的规则之所以存在，就是因为这个原因，我应该先听从它。
我应该从一开始就使用 REST API 方法来配置 Directus，而不是尝试 UI 点击。代理驱动的 REST 调用序列快了三倍，并产生了可重现的配置。这个教训推广到 Directus 之外：任何暴露了完整 REST API 的管理工具都应该通过那个 API 来配置，而不是通过它的 UI。
我应该更早写这篇案例研究文章。这篇文章是在构建完成后大约十二小时写的。到我写这篇文章的时候，一些失败模式已经从记忆中开始淡去了。诚实的案例研究就是在与构建同一天写的那一篇，那时 bug 还够新鲜可以准确描述。
接下来去哪里
如果你正在评估你的业务是否应该委托进行类似的开发，演示循环是获得有用答案的最快途径。打开 /solutions/headless-cms-and-admin-tools/，点击演示按钮，使用显示的凭证登录，花十五分钟四处点击。到最后你会清楚了解这种工具是否适合你的团队。
如果是的话，预订该页面上链接的三十分钟通话。告诉我你现有的技术栈、你的团队规模、你的数据结构。通话结束时，你将有一个级别选择、一个价格范围和一个交付周期。我接手的大多数项目运行六到十二周，费用为 8,000 到 50,000 美元，具体取决于范围。我不接手的那一半，我会在通话中告诉你原因。
如果你想要完整的销售演讲，支柱页面在 /solutions/headless-cms-and-admin-tools/。如果你想跳过直接看实时演示，凭证在该页面上。如果你想要下一个案例研究，下一篇博文可能是关于亚洲走廊制造商的开发或同一模式应用于不同垂直领域。告诉我哪个对你更有用。