可以放手让它做的四类活
把助手当成一个手速极快、但完全没有项目上下文的实习生，分工就清楚了。适合交出去的是：DTO 和 CRUD 样板、配置文件、正则和字符串处理、单元测试与 mock 数据、把一段陌生库的最小示例改成本地写法、给旧函数补类型和注释、小范围重构（同步改异步、抽函数）、写一次性脚本。这些活共同点是结果容易验证、错了代价低、有明确模式可循。让它一次只做一件事，别丢一句"把这个模块重构好"。
必须人工把关的红线
下面这几类生成物一律当"可疑初稿"，逐行读、跑测试、看 diff 才能合：鉴权与会话、权限判断、密码与加密相关代码（模型偏爱过期算法，甚至自己造轮子）；金额计算、浮点累加、并发扣减、分布式事务；拼接 SQL、反序列化、文件上传路径、SSRF 目标校验这类安全敏感逻辑；含内部业务规则和合规要求的分支；以及性能关键路径，它会给出"能跑但 O(n^2)"的版本。另外定一条硬规矩：密钥、生产数据、客户名单不进 prompt，内部仓库用本地模型或自建网关。
把项目约定写成文件喂给它
大部分"生成得不像本项目代码"的问题，是没给约束。在仓库根放 .cursorrules 或 .github/copilot-instructions.md，把框架版本、目录约定、命名风格、禁用库、错误处理方式、测试命令写清楚，比每次在对话里重复强得多。这份文件本身也要进 git、随项目演进更新。
# 项目约定
- PHP 7.4，不能用 8.x 语法（命名参数、match、联合类型）。
- 控制器放 apps/ 下，数据库字段白名单以 content_query_fields() 为准。
- 所有外部输入在边界处校验，SQL 一律参数绑定，禁止字符串拼接。
- 日志不打手机号、token、完整请求体。
- 提交前跑：php -l 改动文件 && vendor/bin/phpunit --filter Unit
- 不要引入新的 composer 依赖，除非先说明理由。验证闭环与几个真踩过的坑
让它生成功能的同时把测试也生成，按"编译或语法检查 → 单测 → lint → 类型检查"的顺序过一遍再人工看 diff。最容易被忽略的是幻觉包名：模型会写出看起来很合理但 registry 里根本不存在的包，比如凭空造一个工具库，装之前必须去 PyPI 或 npm 核实，这不只是报错问题，还是供应链攻击面。第二类坑是过时 API，训练截止早于框架版本，给出的写法已被废弃，去官方 changelog 核一次。第三类是上下文污染，开着一堆无关文件提问，答案会串到别处，先关掉无关标签、只引用相关文件。
php -l src/Controller.php
vendor/bin/phpunit --filter Unit
git diff --stat
python scripts/check_imports.py # 校验生成代码里的包名在 registry 中存在度量上记两个数：接受率，以及"合入后两小时内被改掉的比例"。后者一高，说明边界放得太宽，该收紧或者该补约定文件了。