Cursor AI编程实战：用自然语言描述需求自动生成PHP代码的正确姿势
用 Cursor 写 PHP，重点不在提示词写得多花哨，而在于把自然语言需求拆成函数签名、输入输出和边界条件，再让 AI 按文件补全。这套流程走顺了，生成结果才可控。
为什么一句"帮我写个 PHP 登录"通常拿不到能用的代码？
因为这类描述把三件事同时留白了：数据从哪来、失败怎么办、代码跑在什么环境里。模型只能按训练数据里最常见的写法猜——猜出来的可能是 Laravel 的 Facade 写法，而你的项目是原生 PHP 加 PDO；可能是明文比较密码，而你要求 password_verify。需求越模糊，AI 越倾向于输出"看起来对"的样板代码，你还得逐行改，反而更慢。
另一个常见问题是把整段业务描述塞进一次对话。上下文一长，模型对早先的约束就开始漂移，前一分钟说"用 PDO 预处理"，后一分钟又写成字符串拼接。所以正确姿势的第一条不是学提示词模板，而是控制单次任务的边界。
需求该怎么拆，才能让 AI 一次写对？
把一句话需求拆成四段写，基本能覆盖绝大多数场景：
- 签名与返回：函数名、参数类型、返回值类型。例如
function findUserByEmail(PDO $pdo, string $email): ?array。 - 输入输出样例：给一条真实数据，说明进来什么、出去什么。
- 边界与异常：空值、超长输入、数据库连接失败时分别怎么处理，抛异常还是返回 null。
- 约束条件：PHP 版本（8.1/8.2）、编码规范（PSR-12）、禁用函数、必须用预处理语句、依赖注入而不是全局变量。
这四段不用写得文绉绉，直接列要点即可。比如"用 PHP 8.2、PDO 预处理、查不到返回 null、不抛异常、参数用类型声明"，比"请写一个健壮优雅的用户查询函数"有效得多。
在 Cursor 里具体怎么落地？
先做项目级配置。在项目根目录建 .cursor/rules 目录（旧版本用 .cursorrules 文件），写清楚技术栈与硬性约定：
- PHP 8.2，禁用 eval 与 extract
- 统一使用 PDO 预处理，禁止字符串拼接 SQL
- 遵循 PSR-12，函数必须有参数与返回类型声明
- 业务逻辑放 Service 层，控制器只做参数校验与响应
这段配置会被自动带入每次对话，省掉反复声明。
再选对交互方式。小改动（补一个函数、加一段校验）用 Cmd/Ctrl + K 行内编辑，选中代码直接说"加邮箱格式校验，非法返回 400"；跨文件改造用 Cmd/Ctrl + L 打开对话，@文件名 指定上下文，@Codebase 让模型检索整个仓库。涉及新建多个文件的脚手架，用 Agent 模式让它自己跑，但每步都要看 diff 再接受。
最后是喂上下文的方式。与其贴一大段说明，不如先把相关的接口定义、数据表结构、已有工具类文件 @ 进去。模型看到真实的表字段名，生成的 SQL 才不会凭空造列。文件名和路径本身就是强上下文，别嫌麻烦。
复杂业务逻辑怎么分步喂？
拆成流水线，一次只让 AI 处理一层：
- 第一轮只写数据访问层：给定表结构，产出查询方法。
- 第二轮写业务层：调用上一步的方法，处理状态流转。
- 第三轮写入口层：控制器或命令行脚本，负责参数校验和输出格式。
- 第四轮补测试：贴出业务层方法，让它生成 PHPUnit 用例，重点覆盖异常分支。
每一轮都把上一轮的产出 @ 进去，保持接口一致。这样即使某轮结果不理想，回退成本也只是一个小文件，而不是整块业务重写。
生成之后，哪些地方必须人工复核？
AI 写 PHP 最容易出问题的位置比较固定，建议按这张清单过一遍：
- SQL 与用户输入：确认全部走预处理，没有把变量直接拼进语句。
- 权限与鉴权：AI 常常忘记在方法内校验当前用户是否有权操作该资源。
- 文件与命令执行：
include、exec、unlink这类调用要格外警惕，路径是否来自用户输入。 - 错误处理：是否泄露了堆栈或数据库结构给前端。
- 依赖与版本：生成的代码可能用了你没装的扩展或过新的语法。
工具侧至少跑三样：php -l 文件名.php 做语法检查，vendor/bin/phpcs 或 PHP-CS-Fixer 统一风格，PHPStan 或 Psalm 做静态分析。有条件再补一条集成测试。生成代码通不过 lint 和静态分析，就不要往主干合并。
这套流程的边界在哪？
Cursor 适合写有明确输入输出的代码：数据转换、CRUD、接口封装、脚本工具、单元测试。它不适合替你决定架构，也不适合处理依赖具体业务背景、文档里没写清楚的规则。把 AI 当打字速度很快的初级工程师用，而不是当技术负责人用，心态就对了。