如何真正使用 Buildmate（实用指南）

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。

那么，你已经安装了它，现在怎么办？

也许你已经阅读了我关于 Buildmate 的第一篇文章，或者你只是偶然发现了 GitHub 仓库并想，“不错，我来试试”。不管是哪种情况——你已经把它装好了，但现在正盯着终端，心里想，“……我到底该怎么用这个东西？”

文档固然重要，但有时候你只想看别人是怎么实际使用这个工具的。这就是那种内容。真实的工作流。真实的命令。每天我都会用到的东西。

开始吧。

快速设置（如果你跳过了）

如果你已经完成了这些步骤，请直接跳过。否则请按以下操作：

git clone https://github.com/vadim7j7/buildmate.git
cd buildmate
python3 -m venv .venv && .venv/bin/pip install -e .

然后为你的项目进行引导：

# 选择技术栈
buildmate rails /path/to/my-app
buildmate nextjs /path/to/my-app --ui=tailwind
buildmate rails+nextjs /path/to/my-app

# 或者直接使用预设
buildmate --profile saas /path/to/my-app

不确定有哪些可用的技术栈？可以使用以下命令查看：

buildmate --list           # 所有技术栈
buildmate --profiles       # 预设组合
buildmate --options nextjs # 某个技术栈的可选项

完成后，你将在项目根目录看到一个 .claude/ 文件夹，里面包含所有代理相关的内容。就这样——你已经准备就绪。

您的第一个 /pm 命令

/pm 是主命令。PM 代表 Project Manager（项目经理）。它启动整个工作流——规划、构建、测试、审查，全部环节。

1. 打开您的项目并运行 claude。
2. 输入：

/pm Build a user profile page with avatar, bio, and edit functionality

第 1 阶段 – 规划（交互式）

PM: 好的，关于用户资料页，我的想法是：

    需求：
    - 资料页显示头像、姓名、简介
    - 编辑模式用于更新信息
    - 头像上传（还是 URL？）
    - 保存/取消按钮

    问题：
    - 头像是文件上传还是仅输入 URL？
    - 这个页面放在哪里？/profile？/settings？
    - 需要创建 User 模型还是已经存在？

You: 现在先用 URL 就行。/profile 路由。User 模型已经存在。

PM: 好的，计划如下：
    [显示包含所有细节的特性文件]

    准备构建吗？

You: 好的，开始

第 2‑5 阶段 – 自动化

从此以后由代理程序接管：

[Phase 2: Implementation]
→ Spawning backend‑developer...
→ Creating ProfileController
→ Adding routes
→ Spawning frontend‑developer...
→ Creating ProfilePage component
→ Creating EditProfileForm component

[Phase 3: Testing]
→ Spawning testers...
→ Writing controller specs
→ Writing component tests
→ Running quality gates...
→ Grind agent fixing 2 lint errors...

[Phase 4: Review]
→ Spawning reviewers...
→ Backend review: APPROVED
→ Frontend review: APPROVED

[Phase 5: Verification]
→ Starting dev server...
→ Testing /profile route...
→ Component renders ✓
→ Form submits ✓

Done! Score: 0.89 (B+)

您现在拥有一个可用的个人资料页——包括测试、审查和验证。

注意： 这看起来像魔法，但实际上只是一组按顺序工作的专用代理。后端开发者编写后端代码，前端开发者编写 UI，测试人员编写测试，等等。

代理（谁负责什么？）

代理位于 .claude/agents/ 中，作为 markdown 文件。随意阅读或编辑——稍后会有更多说明。

实际会用到的指令

/pm "task"

最重要的指令。触发完整的工作流。

/pm Add pagination to the products list
/pm Fix the login bug where sessions expire too fast
/pm Build checkout flow with Stripe integration

用于任何重要的工作：新功能、大幅修复、新页面等。

/verify

运行代码进行测试。这个是较新的指令，我经常使用。

/verify                              # 测试最近的更改
/verify --component Navbar           # 测试特定组件
/verify --endpoint POST /api/users   # 测试特定接口
/verify --page /dashboard            # 测试整个页面

如果出现失败，系统会自动尝试修复（最多三次）。

/new-model 和 /new-component

快速脚手架，创建 模型/组件 并自动生成测试和模板代码。

/new-model Product name:string price:decimal active:boolean
/new-component ProductCard
/new-component forms/CheckoutForm

遵循项目约定，省去大量手动工作。

/parallel

有独立的任务吗？同时并行执行它们。

/parallel "Add user avatars" "Add product images" "Add company logos"

概述

使用独立的 Git 工作树，在每个工作树中运行代理，完成后进行合并。当你有大量相似任务时，这非常方便。

/security

安全审计 – 请在部署前运行。

/security

检查注入、身份验证问题、XSS、CSRF，以及其他 OWASP 关注点。

/eval

想要快速得分而不进行完整工作流吗？

/eval

返回一个等级——用于检查自己的工作很有用。

/test 和 /review

只运行你需要的内容：

/test          # just run tests
/review        # just review current changes

Source:

Git 工作流（/branch → /ship 流程）

与其在脑子已经疲惫的下午 5 点手动创建分支、编写提交信息、推送代码并起草 PR 描述，不如直接：

/branch user-auth          # 创建 feature/user-auth
# … 完成你的工作或使用 /pm …
/ship                      # 提交、推送、创建 PR

• 自动从你的更改中生成提交信息。
• 为你编写 PR 描述。
• 在发布前运行质量检查。

更多示例

/branch login-fix --type fix          # 创建 fix/login-fix
/branch user-auth --issue 42          # 关联 GitHub issue #42
/sync                                 # 若落后于 main 则进行 rebase
/ship --draft                         # 创建草稿 PR

同步

/sync                    # 对 main 进行 rebase
/sync --merge            # 使用 merge 而非 rebase
/sync --base develop     # 与 develop 分支同步

发布

/ship                    # 提交 + 推送 + 创建 PR
/ship --draft            # 同上，但创建草稿 PR
/ship --no-pr            # 仅提交并推送，不创建 PR

不再有“等一下，我忘了推送”的尴尬，也不必盯着 PR 模板回想自己改了什么——这些命令全部帮你搞定。

定制您的设置

编辑代理

代理是普通的 markdown 文件。编辑它们以适应您的工作流程。

.claude/agents/
├── orchestrator.md          # the PM brain
├── backend-developer.md    # Rails/FastAPI dev
├── frontend-developer.md
├── grind.md
└── …

打开任意文件即可查看说明、模式、该做和不该做的事项。随意更改您想要的内容。

示例： 强制后端开发者始终使用特定的 gem。

# backend-developer.md (excerpt)

首选 gems

• my-special-gem (>= 2.0)

Feel free to tailor each agent’s behavior to match your team’s conventions.

#### 规则  

- 始终使用 **Pagy** 进行分页（not Kaminari）  
- 始终使用 **Pundit** 进行授权  
- …  

### 添加 Patterns  

Got coding patterns you always follow? Add them to `.claude/patterns/`.  
These are reference docs the agents read—e.g., “how we structure services” or “our API response format”.

### 更改 Quality Gates  

In the stack config you can change what commands run:

```yaml
quality_gates:
  lint:
    command: bundle exec rubocop
    fix_command: bundle exec rubocop -A
  tests:
    command: bundle exec rspec

Add more, remove some, or change commands—whatever works for your project.

我实际使用的工作流

构建新功能

这是我约 80 % 工作的流程：

1. /pm Build [feature description]
2. Answer a few questions about requirements
3. Approve the plan
4. Go get coffee
5. Come back – it’s done
6. Maybe tweak something small manually
7. Commit and push

大多数功能现在只需 10‑15 分钟，而不是半天。

修复 Bug

1. /pm Fix [describe the bug and where it is]
2. Agent reads the code, finds the issue
3. Fixes it
4. Writes a test so it doesn’t happen again
5. Done

对于小 bug，我有时会自己修复，因为更快；但遇到棘手的情况，我会让代理处理。

向已有代码添加功能

1. /pm Add [thing] to [existing feature]
2. Agent reads the existing code first
3. Follows the patterns already there
4. Adds the new thing in the same style

代理会读取你的代码并匹配风格，这样就不会出现“这段新代码和其他所有代码完全不一样”的情况。

快速脚手架日

当我在搭建新项目时，会一次性发出一堆指令：

/new-model User email:string name:string
/new-model Product title:string price:decimal
/new-model Order user:references total:decimal
/new-component Navbar
/new-component Footer
/new-component ProductCard
...

砰——所有内容（包括测试）在大约五分钟内就完成脚手架搭建。

常见问题（以及如何解决）

实际使用此工具的技巧

• 在提示中要具体。 “构建登录页面”可以接受；“构建带有电子邮件/密码、记住我复选框、忘记密码链接，并在登录后重定向到仪表盘的登录页面”更好。
• 回答规划问题。 不要只说“随便”。提供更多上下文 → 更好的输出。
• 经常使用 /verify。 在你看到错误之前捕获愚蠢的失误。
• 阅读特性文件。 它们位于 .claude/context/features/，对于记住构建了什么以及原因非常有帮助。
• 编辑代理。 说真的——让它们成为你的。添加你的模式、规则和偏好。
• 信任但要验证。 代码通常不错，但在发布前总要快速检查一下。
• 使用 Git 流程。 /branch → 开始工作 → /ship。再也不用在下午5点手动编写 PR 描述了。

接下来

我正在开发一个网站克隆工具：把它指向任意站点，它就会使用你的 UI 库生成你自己的版本。这将会是另一篇文章的主题。

现在，你可以去尝试这些东西。弄坏它们。修复它们。告诉我哪些可行，哪些不可行。

GitHub:

觉得这有用吗？

如果这为您节省了一些时间，或许可以请我喝杯咖啡？

☕ 请我喝咖啡

现在去构建一些酷东西吧。

— Vadim