Airship 可视化编辑器怎么用
Airship 把本地 dev server 页面投到无限画布，选中元素描述改动，由 Claude Code 或 Codex 改源码。附 CLI 参数与 doctor 自检。
本地 npm run dev 跑着，你在浏览器里改 UI 还要来回切终端描述元素。airship 可视化编辑器是什么？它是 @airshiplabs/cli 提供的无限画布层，对接你本机 dev server，点选 DOM 元素后直接让 coding agent 改源码。
它解决哪类痛点
传统 vibe coding 的流程是：截图或口述「把右上角按钮改成红色」，Agent 猜 selector，经常改错文件或改错组件。Airship 在 dev server 页面上叠一层可选中元素的画布，选中后把元素上下文（标签、类名、路径线索）带给 Agent，减少「描述不准」这一环。
项目本身不注入依赖，不需要改 package.json。CLI 启动后连到你指定的本地端口，页面在 canvas 模式或 inline 模式里渲染。2026 年 8 月 Show HN 上公开，作者定位是早期开源实验工具，API 和交互还可能变。HN 讨论里有人把它和「浏览器里直接改 React 组件」的旧方案对比，差异在于 Airship 不 fork 你的构建链，只加一层可选 UI。
一条命令连本地服务
最简启动：
npx @airshiplabs/cli --target 3000
--target 填你 dev server 监听的端口，Next.js 默认 3000，Vite 常见 5173。CLI 拉起可视化层，浏览器里看到的就是 localhost 上的页面，只是多了元素选择与 Agent 面板。
常用附加参数：
npx @airshiplabs/cli --target 3000 --agent claude --safe --exec
--agent 指定后端 coding agent，README 列出 Claude Code、Codex、OpenCode 等。--safe 限制危险操作范围。--exec 允许 Agent 直接执行改文件命令而不只给建议。版本迭代快，装前先看仓库 release note 里的参数表。
选中元素到改代码的路径
工作流分四步：本地照常起 dev server；另开终端跑 Airship CLI 指向该端口；在画布上点要选中的 UI 元素；用自然语言描述改动，Agent 根据元素上下文定位源码并修改。
和纯 Claude Code CLI 入门 的区别在于：CLI 模式靠你口述文件路径或 @ 引用，Airship 多了一层视觉锚点。适合组件树深、class 名不直观的页面，不适合纯后端脚本或没有 UI 的任务。
数据流在本地闭环。README 强调不上传页面内容到云端画布服务，选中信息与改动指令交给本机已安装的 Agent 运行时。团队有源码保密要求时，仍要核对 Agent 后端是否走第三方 API。
选中后描述改动宜具体：别说「改好看点」，说「padding 从 8px 改 16px、主色用 design token --color-primary」。Airship 传的是 DOM 线索，审美判断仍靠你口述。Tailwind 项目里 class 列表较长时，Agent 常能直接定位到 tsx 里的 JSX，比纯截图对话少一轮追问。
自检与排错
装完或换 agent 后跑：
airship doctor
doctor 检查 CLI 版本、agent 可执行文件是否在 PATH、端口是否可达。连不上 dev server 时先确认 --target 与真实端口一致，以及 dev server 绑定的是 0.0.0.0 还是仅 127.0.0.1（部分框架默认只监听 localhost，Airship 同机访问一般没问题）。
Agent 改错文件时，常见原因是 monorepo 里 dev server 根目录与 git 根不一致。和 Cursor 新手指南 里「工作区根开在哪一层」是同类坑：先在 IDE 里确认 workspace 根，再让 Airship 连对应 package 的 dev 端口。
canvas 与 inline 两种视图
README 区分 canvas 与 inline 两种渲染模式。canvas 把页面放进无限画布，适合同时看多个断点或并排对比改前改后；inline 更贴近原生浏览器标签，占用资源少，笔记本上长时间开更稳。第一次试用建议 inline，确认 selector 传递准确后再切 canvas 做大幅布局调整。
两种模式共享同一套元素选中协议：点击 DOM 节点后，CLI 侧收到元素路径、可见文本、关键 class。React 或 Vue 组件若用了 CSS module，class 名可能是 hash，这时 Airship 仍可通过 DOM 树层级帮 Agent 缩小文件范围，但你要在描述里补一句组件名，避免 Agent 只改到 styled wrapper。
和后端 Agent 怎么配合
Airship 本身不写模型，它是视觉前端加上下文采集器。后端必须本机已装 Claude Code、Codex CLI 或 OpenCode 之一，并在 PATH 里可调用。--agent claude 走的是 Claude Code 那套权限与 .claude 配置；换 Codex 则走 OpenAI 侧的沙箱规则。
和纯终端流对比：Airship 适合 UI 微调，CLI 适合跨文件重构。一轮 session 里可以混用，先在 Airship 里改按钮样式，再切终端跑测试，但两个入口不会自动共享同一会话 ID，上下文要靠 git diff 衔接。
适用边界
适合：前端页面微调、布局间距、文案替换、样式快速试错、设计稿对照时的像素级调整。不适合：数据库迁移、CI 配置、无 DOM 的后端逻辑、需要批量改几十个组件的重构。它是 UI 层的可视化入口，不是替代完整 IDE 或 Cloud Agent 交接 那类远程流水线。
Show HN 讨论里有人提到和 Figma MCP 的互补：设计稿在 Figma，跑通代码在 Airship，各管一端。国内网络环境下，dev server 本地访问不受阻，但 Agent 若走海外 API，延迟仍在 Agent 侧，不在 Airship 画布层。
早期工具意味着：issue 多、文档短、agent 适配矩阵随时增删。生产项目里建议先在分支或 throwaway 仓库试一轮，确认 diff 质量再接到日常流。遇到 CLI 起不来，先 airship doctor，再对照 README 的 Node 版本要求。