railway-new（Railway-新建Skill）Skill 是什么？

Railway-新建Skill：让 Railway 项目、服务和初始化配置一次做对

• 一句话定位：railway-new 是一个面向 Railway 平台的 AI 技能，帮助开发者在正确的前提下创建项目、添加服务、判断链接状态，并按框架与单仓库结构完成初始化配置。
• 核心价值：它不只是把 Railway CLI 命令包装起来，更内置了“先检查状态、再决定初始化还是链接、最后创建服务”的决策流程，减少误建项目、服务重名和配置返工。
• 安装前提：需要先安装并登录 Railway CLI；技能运行环境需要允许执行 railway、which、command、npm、npx 等相关命令。
• 最适场景：从零创建 Railway 项目、向已有项目添加服务、从 GitHub 仓库创建服务、处理父目录已链接、单仓库/多仓库配置等。
• 注意事项：数据库相关操作应交给 railway-railway-database 技能；用户说“deploy to railway”时，默认可能是向已链接项目添加服务，而不是新建项目。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

该技能的中文名是 Railway-新建Skill，英文名是 railway-new，技能 ID 为 12003。它主要解决 Railway 项目初始化与服务创建过程中的“上下文判断”问题：当前目录是否已链接项目？父目录是否已链接？应该新建项目还是链接现有项目？应该创建空服务、从 GitHub 配置源，还是直接部署代码？这些判断如果只靠手工执行 CLI，很容易出现误操作。

一键安装思路与步骤

1. 确认安装入口：在支持 AI 技能的平台或技能市场中，搜索技能英文名 railway-new、中文名 Railway-新建Skill 或技能 ID 12003，进入详情页后点击安装/启用。不同平台的入口名称和按钮位置不同，具体以官方说明为准。
2. 检查 Railway CLI 是否已安装：技能详情要求先确认 CLI 存在，可执行：

   command -v railway
   

   如果未安装，详情给出的安装方式为：

   npm install -g @railway/cli
   

   或：

   brew install railway
   

3. 完成 Railway 认证：执行：

   railway whoami --json
   

   如果未认证，运行：

   railway login
   

4. 确认技能权限：该技能声明的 allowed-tools 包括 Bash(railway:*)、Bash(which:*)、Bash(command:*)、Bash(npm:*)、Bash(npx:*)。如果平台对命令执行有额外授权限制，需要按平台提示开启。
5. 验证是否生效：在对话中输入“create a railway project”“deploy to railway”或“create a service”等触发语句，观察技能是否会先执行 railway status --json 检查链接状态，再给出 railway init、railway link 或 railway add --service 的下一步建议。如果没有触发，优先检查技能是否启用、CLI 是否在 PATH 中、平台是否允许执行相关命令。

2. 该技能的主要功能和特点

• 状态感知与链接判断：先执行 railway status --json 判断当前目录是否已链接项目；如果未链接，还会检查父目录是否已链接，避免在子目录中重复初始化。
• 新建项目与链接现有项目分流：用户明确说“new project”“init”时使用 railway init -n <名称>；用户命名现有项目时使用 railway link -p <项目>；目录名与现有项目匹配时会询问是链接还是新建。
• 服务创建标准化：项目链接后，通过 railway add --service <名称> 创建服务。应用名称如“my-api”“frontend”通常被视为服务名，而不是项目名。
• GitHub 仓库源处理建议：技能详情明确不建议使用 railway add --repo，而是先创建空服务，再通过 railway-environment 技能配置 source.repo 和 source.branch，最后应用更改触发部署。
• 框架与项目类型识别：根据 package.json、requirements.txt、pyproject.toml、go.mod、Cargo.toml、index.html 等文件判断 Node.js、Python、Go、Rust、静态站点等类型，并给出相应配置建议。
• 单仓库配置决策：区分“隔离单仓库”和“共享单仓库”。隔离单仓库通常设置 rootDirectory；共享单仓库通常不设置根目录，而是配置带包过滤的构建/启动命令，并设置监视路径。
• 多工作空间处理：当用户有多个工作空间时，railway init 需要 --workspace 参数；技能会引导从 railway whoami --json 的 workspaces 数组中匹配名称或 ID。
• 数据库场景转交：涉及 Postgres、Redis、MySQL、MongoDB 时，使用 railway-railway-database 技能处理数据库服务创建、变量引用和服务连接。
• 与其他技能组合：服务创建后，可接 railway-deploy 部署、railway-environment 做高级配置、railway-domain 获取域名、railway-status 检查状态、railway-service 做重命名/删除等操作。
• 错误提示明确：覆盖 CLI 未安装、未认证、无工作空间、项目名称已存在、服务名称已存在等常见问题，并给出可执行的下一步建议。

和普通命令行工具相比，它的差异化不在于“多几个命令”，而在于把 Railway 初始化过程中的上下文判断、框架识别、单仓库模式和错误处理组织成了一套可复用的流程，降低新手误操作概率，也让团队部署步骤更一致。

3. 如何使用该技能？

第一步：检查环境与认证

先确认 Railway CLI 已安装：

command -v railway

未安装时按详情提示安装：

npm install -g @railway/cli

或：

brew install railway

再检查认证状态：

railway whoami --json

未认证则执行：

railway login

第二步：判断当前目录是否已链接

railway status --json

如果已链接，默认进入“向现有项目添加服务”的流程；如果未链接，则继续检查父目录：

cd .. && railway status --json

父目录已链接时，不需要在子目录中重复初始化，而是创建服务、设置 rootDirectory，再从根目录部署。

第三步：决定新建项目还是链接现有项目

• 用户明确说“new project”“create a project”“init a project”时，使用：

  railway init -n <项目名称>
  

• 用户命名了现有项目时，使用：

  railway link -p <项目名称或ID>
  

• 如果目录名称与现有项目匹配，技能会询问是链接现有项目还是创建新项目，避免直接覆盖判断。

第四步：创建服务

项目链接后执行：

railway add --service <服务名称>

例如用户说“create a vite react service”，可先生成 Vite 项目：

npm create vite@latest frontend -- --template react

再创建服务：

railway add --service frontend

Vite 的 dist 输出通常可被 Railpack 自动检测，一般无需额外配置。若输出目录非标准，则通过 railway-environment 技能设置 RAILPACK_STATIC_FILE_ROOT，而不是直接使用 railway variables CLI。

第五步：按项目类型补充配置

• 静态站点：确认 index.html 或构建输出目录存在；非标准输出目录需配置静态文件根目录。
• Node.js SSR：检查 package.json 中是否有 start 脚本；需要自定义启动时，通过 railway-environment 技能设置 startCommand。
• Python：确认 requirements.txt 或 pyproject.toml 存在，FastAPI、Django、Flask 通常可由 Railpack 自动检测。
• Go：确认 go.mod 存在，通常无需额外配置。

第六步：处理单仓库

• 隔离单仓库：应用不共享代码时，设置根目录为子目录，例如 /frontend，并设置监视路径。
• 共享单仓库：存在 pnpm-workspace.yaml、package.json 的 workspaces 字段或 turbo.json 时，通常不设置根目录，而是配置带包过滤的构建/启动命令，例如 pnpm --filter <包> build、npm run build --workspace=packages/<包>、yarn workspace <包> build 或 turbo run build --filter=<包>。

输入输出示例

• 输入：“create a simple html site and deploy to railway”
  预期流程：检查状态 → 未链接则 railway init -n my-site → 指导创建 index.html → railway add --service my-site → 使用部署技能执行 railway up → 使用域名技能获取公共 URL。
• 输入：“add a python api to my project”
  预期流程：确认已链接 → 指导创建 main.py 和 requirements.txt → railway add --service api → 依赖自动检测 → 进入部署流程。
• 输入：“add a new api package to this turborepo”
  预期流程：识别共享单仓库 → 创建 packages/api → railway add --service api → 通过环境技能设置 buildCommand 和 startCommand，不设置 rootDirectory → 设置监视路径。

4. 同类型竞品对比分析

下表将 railway-new 与手工 Railway CLI、Vercel CLI、Render 控制台进行对比。竞品能力以各自官方说明为准，表中侧重定位与使用门槛差异。

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
railway-new（本技能）	面向 Railway 的 AI 初始化与服务创建技能	检查链接状态、判断 init/link、创建服务、识别框架、处理单仓库、错误提示、组合其他 Railway 技能	需安装技能、Railway CLI 并完成登录；平台需允许执行相关 Bash 命令	新建 Railway 项目、向已有项目加服务、从 GitHub 配置服务、单仓库部署	优势是决策流程化、减少误建项目和配置返工；不足是依赖技能平台与 CLI，数据库需转交专用技能
手工 Railway CLI	Railway 官方命令行工具	railway init、railway link、railway add、railway up 等	需安装 CLI、登录并熟悉命令与项目上下文	有经验的开发者、脚本化部署、需要精细控制命令	优势是直接灵活；不足是需自行判断链接状态、框架类型和单仓库模式，容易在子目录或已链接项目中误操作
Vercel CLI	前端部署平台命令行工具	项目初始化、部署、环境变量等前端部署相关能力	需安装 CLI 并登录 Vercel 账号	前端项目、静态站点、以 Vercel 平台为主的部署	优势是前端部署体验成熟；不足是并非 Railway 多服务与数据库场景的替代方案，跨平台迁移需重新配置
Render 控制台	托管平台 Web 控制台	通过图形界面创建服务、数据库和部署配置	浏览器操作，通常无需本地 CLI	偏好可视化操作、少量服务管理	优势是图形化直观；不足是自动化与 AI 对话式初始化能力较弱，复杂单仓库配置仍需手工判断

选择建议：如果你已经在使用 Railway，并希望用自然语言完成“检查状态—创建服务—按框架配置”的初始化流程，railway-new 更贴合；如果你需要完全手工控制命令，手工 Railway CLI 更直接；如果项目主要部署在 Vercel 或以图形化平台为主，则应优先评估对应平台的原生流程。

5. 该技能的典型应用场景与实际体验情况

场景一：前端开发者快速创建 Vite/React 服务

角色与痛点：前端开发者想快速把新项目部署到 Railway，但不清楚应该新建项目还是向已有项目添加服务，也容易把应用名误当成项目名。
使用方式：输入“create a vite react service”，技能会先检查链接状态，再生成 Vite 项目、执行 railway add --service frontend，并判断 Vite 输出是否可自动检测。
实际体验：流程比较清晰，上手难度中等偏低；关键是先确认当前目录或父目录是否已链接。注意 Vite 的 dist 通常可自动检测，非标准输出目录才需要额外设置静态文件根目录。

场景二：后端开发者向已有项目添加 Python API

角色与痛点：后端开发者已有一个 Railway 项目，想新增 FastAPI 服务，但不想重新初始化项目，也不确定 Python 依赖如何被识别。
使用方式：输入“add a python api to my project”，技能会确认项目已链接，指导创建 main.py 和 requirements.txt，再执行 railway add --service api。
实际体验：对 FastAPI、Django、Flask 等常见 Python 项目，技能倾向于依赖 Railpack 自动检测，减少手工配置。注意要确保依赖文件存在；如果启动方式特殊，再通过环境技能设置 startCommand。

场景三：单仓库团队添加新服务

角色与痛点：团队使用 pnpm workspace 或 Turborepo，新增服务时容易错误设置 rootDirectory，导致共享包不可用或构建失败。
使用方式：输入“add a new api package to this turborepo”，技能会识别 turbo.json、pnpm-workspace.yaml 等文件，判断为共享单仓库，指导创建包并配置带过滤的构建/启动命令，而不是简单设置根目录。
实际体验：这是该技能价值较明显的场景。共享单仓库需要的是自定义命令和监视路径，而不是根目录隔离；如果团队把两种模式混用，容易出现构建上下文缺失。使用时需要准确说明包名和目录结构。

场景四：已有项目链接与 GitHub 仓库服务配置

角色与痛点：用户已有 Railway 项目，想从 GitHub 仓库创建服务，但直接使用 railway add --repo 可能因 GitHub 应用集成问题失败。
使用方式：技能建议先创建空服务，再通过 railway-environment 技能配置 source.repo 和 source.branch，最后应用更改触发部署。
实际体验：这种流程比直接执行一条 add --repo 更稳，但步骤稍多。注意事项是不要跳过空服务创建和源配置步骤；如果当前目录已在父目录链接，也不要在子目录重复初始化。

6. 该技能能为用户带来的价值

• 降低初始化门槛：把“先判断链接状态，再决定 init/link，最后 add service”的隐性经验变成显性流程，新手不必先熟读 Railway CLI 文档。
• 减少误操作与返工：在已链接项目、父目录已链接、子目录部署、单仓库等容易误判的场景中，技能会先检查再行动，降低误建项目、服务重名和根目录配置错误。
• 提升配置一致性：对 Vite、Next.js、FastAPI、Go、静态站点等常见项目给出相对统一的配置路径，团队可以复用同一套部署习惯。
• 减少上下文切换：用户用自然语言描述目标，技能负责组织 CLI 命令、判断项目类型，并在需要时衔接部署、环境、域名、状态、服务管理等其他技能。
• 长期可维护性：将项目初始化、服务创建和单仓库配置标准化后，后续排查部署问题时更容易定位是项目链接、服务配置还是构建命令的问题。
• 可量化收益的度量方式：团队可以统计初始化失败次数、服务创建返工次数、部署前检查耗时、配置错误工单数等指标，对比使用前后的变化。具体提升幅度取决于项目复杂度和团队熟练度，技能详情未提供固定数据，本文不做虚构承诺。

7. 常见问题 FAQ

Q1：怎么安装？需要先装 Railway CLI 吗？
A：需要。先在支持 AI 技能的平台上搜索 railway-new、Railway-新建Skill 或技能 ID 12003 并安装/启用；同时安装 Railway CLI 并完成 railway login。CLI 安装可使用 npm install -g @railway/cli 或 brew install railway，具体以官方说明为准。

Q2：这个技能收费吗？
A：技能详情标注许可证为 MIT。技能本身是否收费取决于安装平台；Railway 平台资源、CLI 使用等是否产生费用，以 Railway 官方说明为准。本文不提供价格承诺。

Q3：适合谁用？
A：适合正在使用 Railway、需要创建项目或添加服务、从 GitHub 配置服务、维护单仓库，并希望用自然语言减少手工判断的开发者与团队。完全不用 Railway，或需要复杂自定义基础设施编排的用户，收益会有限。

Q4：和手工 Railway CLI、Vercel CLI、Render 控制台怎么选？
A：如果你使用 Railway 且希望初始化过程有状态检查和决策引导，选 railway-new；如果你需要完全手工控制命令，手工 Railway CLI 更直接；如果项目主要部署在 Vercel，优先评估 Vercel CLI；如果偏好图形化操作，可考虑 Render 控制台。跨平台能力与计费均以各自官方说明为准。

Q5：为什么说“deploy to railway”有时是添加服务？数据库场景怎么办？
A：技能详情规定，当前目录已链接项目时，“deploy to railway”默认是向链接项目添加服务，除非用户明确说“new project”“create a project”等。数据库场景不要由本技能硬做，应使用 railway-railway-database 技能处理数据库服务创建、变量引用和服务连接。