我主力维护一个 Laravel 业务项目（B2B 工业品采购平台），日常更新靠 GitHub 拉取。项目有个演示站跑在本机，我对 AI 的授权边界画得非常窄：只许碰演示站的 DevOps——拉取、构建、重启、验证；业务代码一行不许动。
约束越具体，协作越快
"别乱动"不是约束，是焦虑。真正的约束要落到文件上。于是整个运维流程被压缩成两个批处理：
:: 拉取部署：git pull → 依赖安装 → 配置缓存 → 重启
git pull origin main
composer install --no-interaction
php artisan config:cache && php artisan route:cache
php artisan serve --port=8000:: 一键冷启动：MySQL → Laravel → Cloudflare Tunnel
:: 三件套全起，演示站从零到可访问日常指挥退化成一句话："拉取项目最新状态并部署"。AI 每次执行完交结构化报告，关键验证结果用表格——能不能访问、哪些端口活着、公网通不通。
点开即用，拒绝开机自启
两个脚本都做成桌面双击即用，并且刻意不做开机自启。这台机器是我的工具，不是我的房间——服务什么时候起、什么时候停，应该由我决定。批处理是 Windows 上最被低估的"自动化"：它丑，但它十年不用维护，而且任何人双击就能复现整个过程。
边界换来的东西
有人会问：既然 AI 能写代码，为什么不放开让它改业务？
因为演示站的存在意义是"永远能演示"。AI 写代码很强，但业务代码的每一行变更都需要人类的业务判断背书。把它锁在 DevOps 的笼子里，它反而成了最可靠的运维：每次部署有报告、每次故障有排查记录、每次经验沉淀进技能文件下次复用。
这个个人站上的多篇文章（字体子集化、终端阅读、reduced-motion 调试）都来自另一条更宽的边界——在个人站这个"练手场"里，AI 获得了完整的开发授权。宽窄两条边界并存，才是人和 AI 协作的合理形态：一个项目拿来信任，一个项目拿来实验。