@coze-arch/cli

中文文档
0.1.9发布于 2026/09/11MIT近 30 天下载 3092

coze 编码devtools cli

中文使用文档
文档目录8 节
  1. 安装
  2. 初始化项目
  3. 在项目中运行
  4. Web 云盘开发
  5. Windows 与 WSL
  6. 部署
  7. 模板开发
  8. 本地开发与验证

@coze-arch/cli

Coze Coding 的项目模板与本地运行 CLI。发布包名为 @coze-arch/cli,命令为 coze-dev。

安装

npm install -g @coze-arch/cli
coze-dev --help

也可以不全局安装:

npx @coze-arch/cli --help

初始化项目

coze-dev init my-app --template <template> --app-name my-app
coze-dev init --help

init 默认会渲染模板、安装依赖、初始化 Git、创建初始提交并启动开发服务。按需使用 --skip-install、--skip-git、--skip-commit、--skip-dev 跳过这些步骤。模板名称和 参数以 coze-dev init --help 的实时输出为准;未声明的参数会以 kebab-case 转为 camelCase 后传给模板。

在项目中运行

初始化产物根目录的 .coze 是统一命令契约:

coze-dev dev       # 读取 dev.run
coze-dev build     # 读取 deploy.build
coze-dev start     # 读取 deploy.run
coze-dev validate  # 读取 dev.validate

dev 和 build 在执行前会尝试应用模板补丁;补丁失败会记录调试信息,但不会阻止主命令。 子进程日志默认写入 ~/.coze-logs/dev.log,可用 --log-file <path> 覆盖。

Web 云盘开发

Vite、Next.js、Nuxt 的 Unix 开发 wrapper 在 COZE_DRIVE_ROOT(默认 /Coze/Drive)内通过 rsync 同步源码到本机临时目录 coze-web-<uid>/<source-path-hash>/,再安装依赖和执行。 prepare/dev 使用 dev 子目录,validate 使用独立的 check 子目录,避免类型生成干扰热更新。 依赖和开发编译产物留在本地;只有安装成功且云盘依赖输入未变化时才回写锁文件。所有修复仍在云盘完成。 dev 的 detached 进程持续同步,框架只监听本地镜像;同步失败或依赖输入变化时停止服务。

本地镜像仅用于 [dev].build/run/validate;部署配置、build.sh 和 start.sh 保持原流程。 普通本地目录和 Windows PowerShell 入口保持原流程。rsync 由开发环境提供,[dev].deps 仅作声明。 存量项目通过 coze-dev patch --dry-run / coze-dev patch 升级,沿用 patch 总开关。 仅升级完整匹配旧模板的三个 Unix 开发脚本并保留端口;自定义开发脚本、命令和同名 helper 会跳过。 只更新开发插件不会替换存量项目脚本。

Windows 与 WSL

原生 Windows(process.platform === "win32")优先使用 .coze 中非空的 Windows 覆盖命令;未配置时回退默认命令。WSL 被识别为 Linux,始终执行默认命令。

CLI 命令或场景默认字段Windows 覆盖字段
coze-dev devdev.rundev.run_win
coze-dev builddeploy.builddeploy.build_win
coze-dev startdeploy.rundeploy.run_win
coze-dev validatedev.validatedev.validate_win
coze-dev deploy 的本地打包dev.packdev.pack_win

已支持 Windows 的内置 Web 与 Phaser 模板将覆盖命令映射到 PowerShell 脚本,例如:

[dev]
run = ["bash", "./scripts/dev.sh"]
run_win = ["powershell.exe", "-NoProfile", "-ExecutionPolicy", "Bypass", "-File", "./scripts/dev.ps1"]

[deploy]
build = ["bash", "./scripts/build.sh"]
build_win = ["powershell.exe", "-NoProfile", "-ExecutionPolicy", "Bypass", "-File", "./scripts/build.ps1"]

部署

coze-dev deploy 内置于同一 CLI。认证优先读取 ~/.coze/desktop/runtime.beta.json,其次读取 ~/.coze/desktop/runtime.json; CLI 会依次验证候选 Token,收到 401 时继续尝试下一项,再回退到 COZE_API_TOKEN 和 ~/.coze/cli/config.json 登录态:

coze-dev deploy auth login
coze-dev deploy doctor
coze-dev deploy --source-root . --yes --wait

完整的应用、环境变量、Pages 和小程序命令说明见 部署文档。 dev.pack_win 是自定义模板可选的 Windows 打包覆盖;当前 Expo、Taro 和 Pi Agent 模板 不承诺 Windows 支持。

模板开发

模板位于 src/__templates__/,每个模板通过 template.config.ts 定义参数和渲染钩子, .coze 定义生成项目的运行命令。新增模板或修改模板目录后执行:

npm run prebuild

模板开发细节见 模板开发指南。仓库开发依赖由 Rush 管理,不要在本包目录单独执行 npm install 或 pnpm install。

本地开发与验证

源码入口支持直接运行,无需先构建:

node src/cli.js --help
npm run test
npm run build

端到端模板验证使用 npm run test:e2e,会真实安装模板依赖并启动服务。发布前需完成该验证。

Web 镜像集成测试使用 npm run test:integration:web,依赖 Node.js、bash、rsync 和临时 loopback 监听权限;包管理器和框架命令使用替身,验证目录、同步、锁文件与进程生命周期, 不替代真实框架 E2E。

版本与发布记录

@coze-arch/cli 共发布 404 个版本,首次发布于 2026/01/02;过去 12 个月发布了 404 个版本。

版本发布日期距今
0.1.9latest2026/09/111 个月前
0.1.9-alpha.ce005ealpha2026/09/102 个月前
0.1.9-alpha.01bd9e2026/09/102 个月前
0.1.8-alpha.7654a32026/09/092 个月前
0.1.8-alpha.2ee6692026/09/092 个月前
0.1.8-alpha.735a862026/09/092 个月前

其他发布通道:beta → 0.0.19-beta.1,alpha → 0.1.9-alpha.ce005e。

关于 @coze-arch/cli 的常见问题

@coze-arch/cli 是什么?

coze 编码devtools cli

如何安装 @coze-arch/cli?

在项目目录运行 npm install @coze-arch/cli,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 coze-dev,可以用 npx coze-dev 直接运行。

@coze-arch/cli 支持 TypeScript 吗?

该包的 package.json 没有声明类型入口。需要类型提示时,可以在 npm 上查找社区维护的 @types/coze-arch__cli 是否存在。

@coze-arch/cli 可以商用吗?

@coze-arch/cli 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@coze-arch/cli 的下载量有多少?

根据 npm 官方下载统计,@coze-arch/cli 在 2026/10/11 – 2026/11/09 这 30 天内被下载 3,092 次,日均约 103 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@coze-arch/cli 还在维护吗?

最新版本 0.1.9 发布于 2026/09/11(1 个月前);至今共发布 404 个版本,其中过去 12 个月发布了 404 个;首次发布于 2026/01/02。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。