跳到正文
DEV Community· Oberon Lai·· 2 小時前AI 評分56

讓 AI 編碼智能體操作 WordPress 前的 5 項安全措施

5 safety steps before you let an AI coding agent touch WordPress

AI 導讀

Oberon Lai 提出讓 AI 編碼智能體操作 WordPress 前的 5 項安全措施,涵蓋本機或測試環境、工作目錄限制、備份及部署檢查。他建議每個工作階段前以 WP-CLI 匯出資料庫、每個步驟後提交檔案,並以小範圍要求逐輪檢查;上線前再檢視變更差異及站點設定。

正文

Disclosure: I make ShipPress, a Mac app, and I mention it briefly at the end. Everything before that works without my tool.

Claude Code, Codex and similar agents can now do a surprising amount of work on a WordPress theme or a set of pages. They also sometimes go a little past what you asked: they edit files they shouldn't touch, or write straight to the database. These are five things I wish I had done from day one after a few months of pairing AI agents with WordPress.

1. Work locally or on staging, never on production

It sounds obvious, and it's the one that saves you the most. Don't let the agent work over SSH on the live site. Make changes locally or on a staging copy, check them, then move them over.

wp-env, Local, Docker: it doesn't matter which. What matters is that it's a place where breaking things hurts nobody.

2. Limit the working directory

If you hand the agent the whole repo or the WordPress root, it will read wp-config.php and core files too. If you only want it working on the theme, start it inside the theme folder:

cd wp-content/themes/my-theme
claude   # or codex, etc.

With Claude Code, a CLAUDE.md in the project that spells out what's allowed helps a lot:

## Rules
- Only change files under wp-content/themes/my-theme
- Don't read or change wp-config.php or core files
- Suggest new plugins, don't install them yourself

3. Back up the database, not just the files

git can roll back files. But posts, pages, menus and block theme template edits live in the database, and git alone won't bring back a page the AI rewrote.

So export with WP-CLI before every session:

# before
wp db export backups/before-ai-$(date +%Y%m%d-%H%M).sql

# roll back if needed
wp db import backups/before-ai-20261028-1300.sql

And on the file side, commit after every step:

git add -A && git commit -m "before: ask agent to change header colour"

4. Keep each request small

"Build me the whole website" is much harder to review and undo than "build only the hero section of the home page". If you work in small rounds (request, check, snapshot), you can see right away which instruction broke something.

5. Read the diff before you deploy

Before anything goes live, I check at least this:

git diff --stat                  # which files changed
wp plugin list --status=active   # any plugins you don't recognise?
wp option get siteurl            # did the URL get rewritten?

If siteurl or home reaches production still set to your local URL, the site stops loading. That one is worth a second look.

Summary

  • Work locally or on staging
  • Limit where the agent can work
  • Back up files with git and the database with wp db export
  • Small requests, check after each one
  • Check the diff and settings before you deploy

Aside: an app that does this for you

Steps 1 to 3 were too much manual work for me every time, so I built a free Mac app called ShipPress. It sets up a local WordPress site, lets the AI CLI you already have (Claude Code, Codex, Grok Build, Antigravity CLI, Cursor CLI) build the site, and creates a restore point every time the AI changes something. You can publish through host integrations like InstaWP, over SSH, or as a static export.

Download: https://shippress.codotx.com/?ref=devto-en

If you have your own tricks for keeping AI agents safe around WordPress, I'd love to hear them in the comments.

Oberon Lai

來源:DEV Community · dev.to