用 Warp Code 从自然语言 Prompt 走到代码提交

Warp Code 是 Warp 终端内置的 AI 编码系统，目标是把「用自然语言描述需求」到「代码进入版本库」这一段流程收在同一个窗口里完成。它把编码 Agent、行级 diff 审查面板、轻量代码编辑器和 Git 操作放在终端环境中，开发者不必在终端、编辑器、代码托管平台之间来回切换。适合已经习惯在终端里工作、希望让 AI 直接参与真实项目改动的开发者，也适合需要把 AI 辅助流程在团队内统一起来的工程团队。如果你只是想找一个网页版对话式助手，它并不是那类工具。站内也有对应的工具条目可以对照查看：Warp Code。

下面按「准备 → 操作 → 完整跑一遍 → 注意点」的顺序展开。文中涉及的具体模型、可用地区、套餐与配额，均以官网当前信息为准，本文不给出固定数字。

准备工作

安装客户端

Warp Code 依附于 Warp 终端，因此第一步是取得 Warp 客户端。到 Warp 官方网站的 Code 页面下载对应平台的安装包并完成安装。安装完成后首次启动会进入欢迎界面，此时可以登录账号，也可以先跳过、稍后再登录。

需要说明的是，Warp 是独立客户端而非某个编辑器里的插件，它自己就是一个终端窗口。安装后你原有的 shell 配置、环境变量、命令别名通常可以继续沿用，但具体行为取决于你的 shell 与配置方式，建议先在空目录里试跑几条命令确认环境正常。

准备一个 Git 仓库

Warp Code 的上下文感知能力依赖当前目录与 Git 状态，因此建议在一个已经初始化过 Git 的项目里使用。如果手上没有现成项目，可以先建一个空仓库：

mkdir warp-demo
cd warp-demo
git init
git commit --allow-empty -m "init"

有一个初始提交很重要：后续 Agent 生成的改动会以 diff 形式呈现，而没有基线提交时，diff 面板能对比的内容会受限，审查体验会打折扣。

确认账号与模型可用性

Warp Code 的 Agent 能力与账号绑定。登录后可以在设置里查看当前账号可用的模型范围。默认情况下模型由系统自动选择，也支持手动指定。Warp 支持接入当前主流的若干模型，但具体哪些模型对哪些账号开放、是否需要额外订阅，属于会变动的信息，请以官网与客户端内实际显示为准。

了解 WARP.md 的位置

WARP.md 是 Warp Code 的项目级配置文件，放在项目根目录。它兼容 Agents.md、Claude.md、Cursor 等常见的规则文件格式，也就是说如果你之前为别的 AI 编码工具写过规则文件，内容大体可以迁移过来。这一步不需要提前创建，后面用 /init 命令可以自动生成初版。

操作步骤

第一步：打开项目

启动 Warp 后，在欢迎界面选择打开仓库（Open Repository），选中你的项目文件夹。此后 Agent 生成的所有文件都会写入这个目录，所以务必确认选对了路径——选错目录是新手最常见的失误，生成的文件会散落到无关位置。

打开项目后，Warp 会自动加载 .git 上下文与已有的 WARP.md 配置。如果项目里已有规则文件，Agent 在后续对话中会参考这些规则。

第二步：用自然语言下 Prompt

在终端输入框里直接用自然语言描述任务即可，例如：

修复用户登录时的空指针异常

Warp 会识别这是一条自然语言指令而非 shell 命令，并启动编码 Agent。Agent 会先读取相关文件、定位问题，再给出改动方案。描述任务时把范围说清楚会明显提升效果，比如指明涉及哪个模块、期望的行为是什么、有没有不能改动的部分。

输入方式不限于键盘打字。Warp Code 支持语音输入与图片输入，适合口述需求或贴一张报错截图、设计稿让 Agent 理解意图。

第三步：在 diff 面板审查改动

Agent 产出改动后，右侧面板会显示行级 diff 对比。你可以逐行查看增删内容，对单行做编辑，也可以整体接受或拒绝这次变更。这一步是 Warp Code 与纯对话式工具的关键差别：审查发生在终端内，不需要切到代码托管平台去看 PR。

审查时的实用做法是先看文件清单，确认 Agent 改动的范围是否符合预期；再看具体 diff，重点检查边界条件、错误处理与命名风格。如果某处不满意，可以直接在面板里改，不必让 Agent 重来一遍。

第四步：在内置编辑器里继续修改

点击文件名即可在内置编辑器中打开该文件。编辑器支持标签式文件视图、语法高亮、文件树导航，以及 Vim 键位绑定（可自定义）。多标签、搜索、跳转这些基础能力都在，足以对 Agent 生成的代码做快速微调，或者直接手写新文件。

点击文件夹会展开项目结构，选中对应文件就能开始编辑。对于「Agent 生成骨架、人来补细节」这种分工，这个编辑器基本够用；如果要做大规模重构，仍然建议回到你惯用的完整 IDE。

第五步：用斜杠命令固化流程

斜杠命令是 Warp Code 里减少重复劳动的主要手段，常用命令包括：

• /init：初始化项目规则，生成 WARP.md 初版，把项目结构、技术栈、编码约定写进去。
• /add-rule：向规则文件追加一条约定，适合在协作中随时补充「不要用某个库」「测试必须放某个目录」这类约束。
• /add-server：连接 MCP（Model Context Protocol）服务，让 Agent 能调用外部工具与数据源。
• /save-prompt：把常用 Prompt 保存为模板，之后重复调用。

这些命令的价值在于把「每次都要重新解释一遍」的东西沉淀下来。团队里多人使用同一个仓库时，WARP.md 里的规则对所有人生效，AI 辅助开发的行为因此趋于一致。

第六步：提交代码

审查无误后，直接在终端里执行常规 Git 命令完成闭环：

git add .
git commit -m "fix: 修复登录空指针异常"

Warp Code 不改变 Git 本身的工作方式，它只是把生成、审查、编辑、提交压缩在同一界面内。因此你原有的分支策略、提交规范、钩子脚本都可以照常使用。

第七步：并行处理多个子任务

Warp Code 支持同时运行多个 Agent，分别处理不同的子任务，并通过通知机制提示进度。典型用法是一个 Agent 在改业务逻辑，另一个在补测试或更新文档。并行时要注意任务之间不要改同一批文件，否则合并改动会很麻烦。

一个完整示例

下面从一个空仓库开始，走完「描述需求 → 生成代码 → 审查 → 编辑 → 提交」的全流程。示例任务是用 Rust 写一个最小的 HTTP 服务器，这个任务规模适中，便于观察每一步的实际产出。

1. 建仓库并打开

mkdir rust-http-demo
cd rust-http-demo
git init
git commit --allow-empty -m "init"

在 Warp 欢迎界面选择 Open Repository，指向 rust-http-demo 目录。

2. 初始化项目规则

在输入框执行：

/init

Warp 会扫描当前目录并生成 WARP.md。此时目录还是空的，生成的内容会比较简略，可以手动补上技术栈与约定，例如要求使用某个 Rust 版本、错误处理统一用某种方式、不要引入额外依赖等。规则写得越具体，后续 Agent 的产出越贴近预期。

3. 下 Prompt 生成代码

输入：

用 Rust 实现一个 HTTP 服务器，监听本地端口，对 GET / 返回一段文本，对其它路径返回 404，并附上单元测试

Agent 会创建 Cargo.toml、src/main.rs 等文件，并给出实现。生成过程中可以在右侧看到文件逐个出现。

4. 审查 diff

在右侧面板逐行检查改动。重点看三处：端口是否写死、404 分支是否覆盖、测试是否真的能跑。发现不合适的地方直接在该行编辑，或拒绝整块改动让 Agent 重做。

5. 在内置编辑器里补细节

点击 src/main.rs 打开编辑器，把端口改成从环境变量读取，补上启动日志。标签式视图让你可以在 main.rs 与测试文件之间来回切换。

6. 本地验证

在同一个终端里直接跑：

cargo test
cargo run

另开一个终端窗口用 curl 验证根路径与 404 分支。如果编译报错，把错误信息贴回输入框，Agent 会基于当前上下文继续修。

7. 提交

git add .
git commit -m "feat: 最小 HTTP 服务器与单元测试"

到这里一个完整闭环就走完了。整个过程没有离开终端窗口，也没有切到浏览器去看代码。

典型场景与做法

场景	做法
漏洞快速修复	输入「修复 XX 漏洞」，Agent 定位问题并生成补丁，审查后直接提交
新功能开发	描述功能需求，Agent 生成完整模块代码，开发者只做微调
代码审查协作	团队成员在 Warp 内直接评论、修改 AI 生成的代码，减少 PR 往返
项目初始化	用 /init 搭建项目结构、配置依赖与 CI/CD
学习与教学	输入「用某语言实现某功能」，即时获得可运行示例并当场调试

注意事项

上下文来自当前环境

Warp Code 会把当前目录、Git 状态、环境变量以及 Warp Drive 笔记本作为 AI 上下文。这既是优势也是风险：环境变量里如果有密钥、令牌，可能被带入上下文。在敏感项目里使用前，先确认哪些变量会暴露，必要时在启动前清理。

规则文件要跟着项目走

WARP.md 应当提交进版本库，这样团队每个人的 Agent 行为一致。但规则文件里不要写内部地址、账号信息这类内容。规则越具体越有用，堆砌空泛的「写高质量代码」没有实际约束力。

diff 审查不能省

Agent 生成的代码看起来合理但实际有边界问题，是这类工具的常态。行级 diff 面板的存在就是为了让你逐行确认。整体接受之前，至少扫一遍改动涉及的文件范围，确认没有动到不该动的文件。

并行 Agent 要划分文件边界

多个 Agent 同时工作时，让它们各自负责不同的文件集合。如果两个 Agent 改同一个文件，后合并的一方需要人工处理冲突，反而更慢。

模型选择与可用性会变

默认自动选择模型，也可以手动指定。哪些模型可用、是否需要额外订阅、各套餐的调用配额，都属于会调整的信息，使用前请以官网当前信息为准。基准测试排名同样会随时间变化，不宜当作长期结论。

终端仍是终端

Warp 底层用 Rust 构建，主打低延迟与稳定性，但它终究是一个终端。内置编辑器定位是轻量编辑，适合微调与快速查看；大规模重构、复杂调试仍然建议用完整 IDE。把 Warp Code 当作「终端里的 AI 协作层」而不是替代整个开发环境，预期会更准确。