用 Laravel Boost 给编程智能体补齐上下文

AI 编程助手能很快写出 Laravel 的控制器、迁移和测试，也可能调用当前版本不存在的方法，最后在没运行任何检查的情况下宣布完成。原文的判断是：结果好不好，关键在于项目上下文、验证手段，以及它能碰到哪些东西。

作者给出了一套以 Laravel Boost 为入口的开发流程：让助手读取真实项目，小步修改，每步检查，再由开发者审查提交。对使用 Laravel 的全栈开发者，最有用的是配置细节和权限边界；但原文没有效率对照实验，不能据此判断某款助手更强。

Boost 补上的，是项目事实和运行现场

通用模型学到的 Laravel 知识混杂着不同版本。它可能拿旧 API 写新项目，按猜测中的表结构生成查询，或者在现有代码旁边另起一套风格。运行时信息也有类似缺口：日志里的异常、数据库里的真实列、上一次请求的返回结果，都不能靠训练数据补齐。

Laravel Boost 是官方提供的开发辅助包，包含项目指南、技能和连接运行中应用的 MCP 服务器。MCP 可以理解为助手调用项目工具的接口，让它有机会检查事实，再决定怎么改代码。

安装时将它放进开发依赖：

composer require laravel/boost --dev
php artisan boost:install

注意第一行的 --dev，这是开发工具的安装范围。安装器会询问使用哪些助手、配置哪些部分，也可以通过 --guidelines、--skills、--mcp 分别设置。

按原文引用的源码，Boost v2.10.4 发布于 2026 年 10 月 29 日，要求 PHP 8.2 或更新版本，支持 Laravel 11、12、13。它识别 Claude Code、Codex、Copilot、Cursor、Junie、Kiro、OpenCode、Zed、Amp、Antigravity、Grok Build 和 Pi。

部分助手的指南写入项目根目录的 AGENTS.md。Claude Code 已有 CLAUDE.md 时使用该文件，否则使用 AGENTS.md；技能进入 .claude/skills，MCP 配置进入 .mcp.json。

这些生成的指南应提交到版本库。升级 Laravel 或增加依赖后，运行 php artisan boost:update 更新，使用 php artisan boost:list-skills 查看技能。

不过，原文在介绍 MCP 工具时没有附上完整工具列表，只说明旧的 application-info 已在 v2.10.4 移除。因此，具体工具名不能照搬旧教程，给定材料也不足以还原全部能力。

为什么要把一个需求拆成几次可检查的修改

作者建议先要计划，明确涉及哪些文件、路由和测试，暂时不要写实现。计划阶段纠正误解，通常比面对一大批生成代码更容易。

接着写当前会失败的功能测试，再逐步实现迁移、模型和控制器动作。这里的重点不是步骤多，而是每一步都有清晰的验收对象。

助手说完成，只是一次状态汇报；检查输出才是证据。

例如发票导出功能，原文要求运行 php artisan test --filter=InvoiceExportTest 检查目标测试，再用 ./vendor/bin/pint --dirty 格式化变更文件，并读取输出。提交前，开发者仍要逐行查看 diff。

下面这段原文提示词，把数据库事实、修改范围、恢复行为测试和迁移预览放进了同一项任务：

Add soft deletes to the Project model.
- Check the real projects table schema first.
- Create the migration and update the model.
- Update the existing ProjectTest so it covers restoring a project.
- Run php artisan test and fix failures. Do not change unrelated files.
- Show me the migration SQL with php artisan migrate --pretend before running it.

要留意最后一行：php artisan migrate --pretend 只打印迁移将执行的 SQL，不执行迁移。它给开发者留出了检查机会，尤其适合发现意外删列或类型变更。

工具能读数据库，不代表只能读数据库

原文最需要认真看的边界，是查询工具与 Tinker 的区别：查询工具只读，但 Tinker 可以执行任意 PHP，也包括写操作。不能因为其中一个入口只读，就推断整个助手没有修改数据的能力。

作者要求把助手连接到使用假数据的本地数据库，不提供生产凭据，也不要把 .env 内容粘进对话。

Boost 的服务启动条件同样需要看清：按原文源码描述，应用环境为 local，或者 APP_DEBUG 为 true，都能满足启动条件。生产环境如果误开 APP_DEBUG=true，也会落入其中。生产部署应排除开发依赖，并正确设置环境和调试配置。

人工审查则集中在容易「看着对、实际错」的位置：policies 和 gates 的授权检查、验证规则、批量赋值设置、文件上传，以及列表查询中的 N+1。N+1 指先查一批记录，再为每条记录额外查询，数据越多，查询次数越容易失控。

测试通过也有边界。缺少授权检查，只有写了对应测试才可能被发现；助手同时生成实现和测试，还可能把同一个误解写进两边。断言必须读，迁移也必须审。分支开发、每个可用步骤提交一次，则为回退提供了明确位置。

我的判断

我认同这套流程对事实检查和修改范围的重视。比起不断补充一个超长提示词，让助手先读真实表结构、运行检查、展示迁移 SQL，更容易形成可审查的结果。

但原文没有给出团队实测数据、耗时对照或缺陷统计。「小步检查能得到更稳定的结果」在这里属于经验建议，不能当成经过量化验证的结论。作者也明确表示，没有证据证明某款助手明显领先，建议按终端、编辑器或 IDE 的使用习惯选择，再拿自己的真实小任务比较两个候选。

这套流程还有一个前提：开发者知道应该检查什么。已有测试薄弱时，补一条成功路径测试，无法覆盖权限、异常和数据边界；看到迁移 SQL，也需要理解它对表和业务的影响。

Boost 并非使用 AI 编程助手的必要条件。普通助手也能改 Laravel 文件，它增加的是项目上下文和运行工具。另一个容易混淆的产品是 Laravel AI SDK：Boost 服务于开发过程，SDK 用于在应用里构建客服助手、工具调用工作流等功能，两者用途不同。

能拿来做什么

• 给现有 Laravel 项目接入 Boost 时，先确认 PHP 和 Laravel 版本，再安装开发依赖，将生成的指南提交到仓库，并把 boost:update 纳入升级依赖后的维护步骤。
• 下一次让助手修改接口时，把任务写成可验收的几步：先查现有实现和表结构，再列计划、补失败测试、小步实现，最后运行明确的检查命令并展示输出。
• 涉及迁移时，要求先展示 php artisan migrate --pretend 的结果；涉及授权、验证、上传或批量赋值时，人工阅读实现和测试断言，确认业务限制确实被覆盖。
• 比较两个编程助手时，使用自己项目中的同一个小任务，观察它们是否遵守现有结构、检查真实信息、运行测试并控制 diff 范围，再决定哪个更适合日常工作。