企业官网建设流程全解析

随着近一年 AI 编程工具进步，2026月06月又从西方飘出来一个热词——Loop Engineering，时不时就蹦出某大佬说，我现在已经不用Prompt Engineering，全心投入Loop Engineering；而身为AI大阅兵的碳基猴子们，是不是前脚还在陷在Prompt Engineering和Context Engineering的沼泽里，现在又来了个Loop Engineering了，一个头两个大，那先别大了，今天博主就以一个具体且简单的MySQL 数据库的脚本变更修复的案例来讲清楚三者到底有什么区别，以及怎么落地。

0. Case：一个 MySQL Migration（数据库的脚本变更修复）挂了

假设我们有一个 PR，要给customers表增加一个字段lifetime_value，表示客户历史付费金额。

PR里的SQL Migration是：

-- migrations/20260624_add_customer_lifetime_value.sqlALTERTABLEcustomersADDCOLUMNlifetime_valueDECIMAL(12,2)NOTNULLDEFAULT0;UPDATEcustomers cJOINorders oONo.customer_id=c.idSETc.lifetime_value=SUM(o.total_amount)WHEREo.status='paid';

CI报错：（虽然这个脚本有点弱智，但重在说明问题，凑合着看吧，此处就不就结了）

ERROR 1111 (HY000): Invalid use of group function

问题原因是：MySQL不能在UPDATE ... SET里这样直接使用SUM()聚合函数。

正确思路是先在子查询里按customer_id聚合，再 JOIN 回customers表更新。

修复后的SQL应该类似：

ALTERTABLEcustomersADDCOLUMNlifetime_valueDECIMAL(12,2)NOTNULLDEFAULT0;UPDATEcustomers cLEFTJOIN(SELECTcustomer_id,SUM(total_amount)AStotal_paidFROMordersWHEREstatus='paid'GROUPBYcustomer_id)paid_ordersONpaid_orders.customer_id=c.idSETc.lifetime_value=IFNULL(paid_orders.total_paid,0);

接下来，就以这个 case 拿来对比三种AI Engineering工程方法。

1. Prompt Engineering：手动把问题问清楚

最传统的方式是：你把 SQL、报错、要求复制给AI或LLM，例如：

你是资深 MySQL 数据库工程师。 请修复下面的 MySQL migration。 要求：1. 只做最小改动。2. 不要 DROP。3. 不要 TRUNCATE。4. 不要 DELETE。5. 不要连接生产库。6. 保留 MySQL 语法。7. 输出修复后的 SQL。8. 解释为什么原 SQL 会失败。 错误： ERROR1111(HY000): Invalid use of groupfunction原脚本： ALTER TABLE customers ADD COLUMN lifetime_value DECIMAL(12,2)NOT NULL DEFAULT0;UPDATE customers c JOIN orders o ON o.customer_id=c.id SET c.lifetime_value=SUM(o.total_amount)WHERE o.status='paid';

模型大概率会给出一个正确修复：

ALTERTABLEcustomersADDCOLUMNlifetime_valueDECIMAL(12,2)NOTNULLDEFAULT0;UPDATEcustomers cLEFTJOIN(SELECTcustomer_id,SUM(total_amount)AStotal_paidFROMordersWHEREstatus='paid'GROUPBYcustomer_id)paid_ordersONpaid_orders.customer_id=c.idSETc.lifetime_value=IFNULL(paid_orders.total_paid,0);

然后你自己本地localhost:3306的MySQL实例上进行验证：

mysql-uroot-p-e"DROP DATABASE IF EXISTS app_test;"mysql-uroot-p-e"CREATE DATABASE app_test;"# schema.sql 是你测试库的建表语句# seed.sql 是写入或刷新数据的脚本mysql-uroot-papp_test<schema.sql mysql-uroot-papp_test<seed.sql mysql-uroot-papp_test<migrations/20260624_add_customer_lifetime_value.sql

再跑验证查询：

SELECTc.id,c.lifetime_value,IFNULL(SUM(CASEWHENo.status='paid'THENo.total_amountELSE0END),0)ASexpected_ltvFROMcustomers cLEFTJOINorders oONo.customer_id=c.idGROUPBYc.id,c.lifetime_valueHAVINGc.lifetime_value<>expected_ltv;

期望结果是：

0 rows

恭喜你，已经完美的完成了这次任务。

Prompt Engineering 的优点

• 简单、快、适合临时问题；

• 你遇到一个SQL报错，贴给AI或LLM，让它解释和修复，这没有问题；

• 有你这个碳基猴子在看管了着，AI或LLM不会给你惹太大的麻烦。

但它的问题也很明显

Prompt Engineering的问题不是“模型不会回答”，而是每次都要靠人手动兜底：

• 碳基猴子手动复制上下文
• 碳基猴子手动说明数据库规则
• 碳基猴子手动说明哪些操作危险
• 碳基猴子手动验证 SQL
• 手动判断能不能合并

这适合修一个问题，不适合长期工程化，新鲜劲过完后，身为碳基猴子的你肯定会觉得，什么事都得找本猴，能不能偷个懒？于是你就构思出了Context Engineering。

2. Context Engineering：把项目上下文固化下来

Context Engineering不是写一个更漂亮的prompt，而是把模型每次需要看的东西整理成稳定文件，也就是说，不要每次都重新告诉 AI：

我们用 MySQL 不要用 PostgreSQL 语法 不要 DROP 不要 TRUNCATE 不要连生产库 大表 ALTER 要小心 metadata lock orders.status = paid 才算收入

这些都应该成为项目上下文，说白了就是让AI浸泡在一个有限的泳池里面，池子里面的水就是AI能接触到的上下文（当然游泳嘛，水够就行，太大了在海里也容易淹死^_，上下文也是如此），项目可以这样组织，就是所谓的框架或者脚手架设计：

repo/ AGENTS.md db/ mysql-schema-map.md mysql-migration-rules.md mysql-verification.md mysql-risk-boundaries.md migrations/ 20260624_add_customer_lifetime_value.sql

AGENTS.md

# Agent Instructions You are working on MySQL migration scripts. Default behavior: - Prefer minimal SQL changes. - Use MySQL syntax only. - Never connect to production databases. - Never use DROP, TRUNCATE, or DELETE unless explicitly approved. - Avoid destructive ALTER statements. - Explain metadata lock risk for large tables. - If a migration may lock a large table, escalate to human review. Before claiming success: - Run migration on a local MySQL test database. - Run verification queries. - Show changed files.

db/mysql-schema-map.md

# MySQL Schema Map customers: - id BIGINT PRIMARY KEY - email VARCHAR(255) NOT NULL - created_at DATETIME NOT NULL orders: - id BIGINT PRIMARY KEY - customer_id BIGINT NOT NULL - total_amount DECIMAL(12, 2) NOT NULL - status VARCHAR(32) NOT NULL - created_at DATETIME NOT NULL Business meaning: - orders.status = 'paid' counts toward customer lifetime value. - pending, canceled, refunded orders do not count.

db/mysql-migration-rules.md

# MySQL Migration Rules Good: - Use explicit JOINs in UPDATE statements. - For aggregates in UPDATE, use a derived table. - Use IFNULL for nullable aggregate results. - Add indexes before large backfills if needed. - Test migrations against local MySQL. Bad: - DROP TABLE - TRUNCATE TABLE - DELETE without WHERE - UPDATE without clear scope unless it is an intentional backfill - ALTER large tables without lock review - Production database URLs in scripts Important MySQL-specific note: - MySQL DDL statements like ALTER TABLE usually cause implicit commits. - Do not assume BEGIN / COMMIT protects the full migration the same way it might in PostgreSQL.

db/mysql-verification.md

# MySQL Verification Create test database: mysql -uroot -p -e "DROP DATABASE IF EXISTS app_test;" mysql -uroot -p -e "CREATE DATABASE app_test;" Load schema and seed data: mysql -uroot -p app_test < schema.sql mysql -uroot -p app_test < seed.sql Run migration: mysql -uroot -p app_test < migrations/20260624_add_customer_lifetime_value.sql Verify result: SELECT c.id, c.lifetime_value, IFNULL(SUM(CASE WHEN o.status = 'paid' THEN o.total_amount ELSE 0 END), 0) AS expected_ltv FROM customers c LEFT JOIN orders o ON o.customer_id = c.id GROUP BY c.id, c.lifetime_value HAVING c.lifetime_value <> expected_ltv; Expected result: 0 rows

db/mysql-risk-boundaries.md

# MySQL Risk Boundaries Escalate to human if: - Script contains DROP. - Script contains TRUNCATE. - Script contains DELETE. - Script changes auth, payments, permissions, user identity, or secrets. - Script alters a very large table. - Script may cause long metadata locks. - Script changes more than one migration file. - Script requires business interpretation not present in schema docs.

现在 prompt 就变短了

Read AGENTS.md and db/mysql-*.md first. Fix this MySQL migration: migrations/20260624_add_customer_lifetime_value.sql CI error: ERROR 1111 (HY000): Invalid use of group function Make the smallest safe SQL change. Use MySQL syntax only. Do not use DROP, TRUNCATE, DELETE, or production credentials. Run the verification steps from db/mysql-verification.md.

这就是Context Engineering的价值：不是让模型聪明一点，而是让模型每次都在正确上下文里工作。

它解决了什么

相比Prompt Engineering，它解决了几个问题：

项目规则可以复用 数据库语法不会混淆 业务含义不会每次重讲 验证命令固定 危险边界明确

但它还没有解决一个问题：

谁来持续检查 PR？ 谁来发现 CI 挂了？ 谁来决定什么时候重试？ 谁来记录上次处理到哪里？

这就是Loop Engineering要解决的事情。

3. Loop Engineering：让流程持续运行

Loop Engineering的核心不是“写一个更复杂的prompt”，而是设计一个可以重复运行的工作循环。

对于MySQL Migration场景，这个loop可以是抽象成：

定时检查 PR ↓ 找到 label=mysql-migration 的 PR ↓ 读取 CI 错误 ↓ 判断是不是低风险 MySQL migration 错误 ↓ 开独立 worktree ↓ 让 AI 修一个 migration 文件 ↓ 启动本地 MySQL 测试库 ↓ 跑 migration ↓ 跑 verification query ↓ verifier 检查 diff 和风险 ↓ 通过则开 fix branch 或评论 patch ↓ 高风险则交给人

这时项目结构会变成：

repo/ LOOP.md mysql-loop-state.md mysql-loop-run-log.md loop-budget.md db/ mysql-schema-map.md mysql-migration-rules.md mysql-verification.md mysql-risk-boundaries.md .grok/ skills/ mysql-migration-triage/ SKILL.md minimal-mysql-fix/ SKILL.md mysql-verifier/ SKILL.md scripts/ mysql-migration-loop.sh

LOOP.md

# MySQL Migration Loop Pattern: MySQL Migration Babysitter Mode: L2 assisted fix Cadence: every 30 minutes on PRs labeled mysql-migration Auto-merge: disabled Allowed actions: - Read PR metadata - Read CI logs - Check out PR branch in isolated worktree - Modify one migration file - Run migration against local MySQL test database - Open fix branch or comment patch Forbidden actions: - No production database access - No auto-merge - No DROP - No TRUNCATE - No DELETE - No destructive ALTER - No touching auth, payments, permissions, secrets, or infra Human Gates: - destructive SQL - migration touches more than one file - table may be large - possible long metadata lock - missing verification query - third failed attempt

mysql-loop-state.md

# MySQL Loop State Last run: 2026-06-24 10:30 Europe/Berlin ## PR #217 — add customer lifetime value Status: CI red Label: mysql-migration File: - migrations/20260624_add_customer_lifetime_value.sql Error: - ERROR 1111 (HY000): Invalid use of group function Risk: - Low - One migration file - No DROP / TRUNCATE / DELETE - No production connection Attempts: - 1 / 3 Last action: - Implementer replaced aggregate in UPDATE with derived table. - Verifier confirmed MySQL syntax. - Local migration passed. - Verification query returned 0 rows. Next action: - Comment patch summary on PR.

这个文件非常重要。

没有state，loop每次运行都会失忆。它可能重复修同一个PR、重复评论、重复尝试，甚至无限循环。

三个 Skill 的职责

Loop里最好把AI角色拆开，不要让一个模型自己改、自己审、自己宣布通过！不要让一个模型自己改、自己审、自己宣布通过！不要让一个模型自己改、自己审、自己宣布通过。

1. mysql-migration-triage

只负责判断：

这个 PR 能不能自动处理？

输出类似：

{"pr":217,"classification":"fixable","risk":"low","reason":"Only one MySQL migration file changed and the error is a local aggregate UPDATE issue.","target_file":"migrations/20260624_add_customer_lifetime_value.sql"}

如果看到危险SQL，比如：

DROPTABLEcustomers;

就应该输出：

{"classification":"escalate","risk":"high","reason":"Migration contains destructive SQL."}

2. minimal-mysql-fix

只负责做最小修复：

只改目标 migration 文件 不重构 不碰生产连接 不 DROP 不 TRUNCATE 不 DELETE

它把错误SQL：

UPDATEcustomers cJOINorders oONo.customer_id=c.idSETc.lifetime_value=SUM(o.total_amount)WHEREo.status='paid';

改成：

UPDATEcustomers cLEFTJOIN(SELECTcustomer_id,SUM(total_amount)AStotal_paidFROMordersWHEREstatus='paid'GROUPBYcustomer_id)paid_ordersONpaid_orders.customer_id=c.idSETc.lifetime_value=IFNULL(paid_orders.total_paid,0);

3. mysql-verifier（强烈建议要跟实施使用的模型不同）

只负责审查，不负责修改，它必须检查：

migration 是否能在本地 MySQL 跑通 verification query 是否返回 0 rows 是否只改了目标文件 是否包含 DROP / TRUNCATE / DELETE 是否碰了生产连接 是否可能导致大表长时间 metadata lock

这个角色非常关键。很多 AI 自动化失败，就是因为让同一个模型：

自己改 自己测 自己说通过

这是不合格的工程设计，更严格的做法是模型1（如Opus 4.8，GLM-5.2）负责自实施改动，模型2（GPT 5.5，Deepseek V4）负责按要求测试和评估是否能通过，当然

4. 让整个Loop跑起来的关键：mysql-migration-loop.sh

下面是一个让整个Loop跑起来的关键shell脚本，重点是帮助理解每一步的职责，本质是此刻就把自己想象成当年的造物主或上帝就好，就看你的智慧是否足以造出你自己的心中的完美世界了，当然别胆怯，完美的产品都是迭代出来的，这个脚本可能也不完美，当然也不是人一口气想出来的，第5节会细讲迭代逻辑，此处就先看一下这个脚本本身，仅供学习参考；

#!/usr/bin/env bash# 遇到错误就退出# -e: 任意命令失败就停止# -u: 使用未定义变量就报错# -o pipefail: 管道中任何一步失败都算失败set-euopipefail######################################### 0. 基础配置########################################STATE_FILE="mysql-loop-state.md"RUN_LOG="mysql-loop-run-log.md"PR_LABEL="mysql-migration"REPO_DIR="$(pwd)"MYSQL_USER="${MYSQL_USER:-root}"MYSQL_HOST="${MYSQL_HOST:-127.0.0.1}"MYSQL_PORT="${MYSQL_PORT:-3306}"MYSQL_BASE_CMD=(mysql-h"$MYSQL_HOST"-P"$MYSQL_PORT"-u"$MYSQL_USER")echo"## Run$(date-Iseconds)">>"$RUN_LOG"######################################### 1. 找到需要处理的 PR########################################PRS=$(ghprlist\--label"$PR_LABEL"\--stateopen\--jsonnumber,title,headRefName,files,statusCheckRollup)if["$PRS"="[]"];thenecho"- No PRs with label$PR_LABEL. Exit.">>"$RUN_LOG"exit0fiecho"$PRS">.loop-mysql-prs.json######################################### 2. 让 triage agent 判断能不能自动处理########################################agent run mysql-migration-triage\--input.loop-mysql-prs.json\--state"$STATE_FILE"\--output.loop-mysql-triage.json######################################### 3. 读取 triage 结果########################################CLASSIFICATION=$(jq-r'.[0].classification'.loop-mysql-triage.json)PR_NUMBER=$(jq-r'.[0].pr'.loop-mysql-triage.json)TARGET_FILE=$(jq-r'.[0].target_file'.loop-mysql-triage.json)######################################### 4. 没事可做就退出########################################if["$CLASSIFICATION"="noop"];thenecho"- PR #$PR_NUMBERnoop.">>"$RUN_LOG"exit0fi######################################### 5. 风险高就交给人########################################if["$CLASSIFICATION"="escalate"];thenghprcomment"$PR_NUMBER"\--body"MySQL Loop: human review required. See$STATE_FILE."echo"- PR #$PR_NUMBERescalated.">>"$RUN_LOG"exit0fi######################################### 6. 低风险：拉取 PR 分支到独立 worktree########################################BRANCH=$(ghprview"$PR_NUMBER"\--jsonheadRefName\--jq'.headRefName')WORKTREE="../mysql-loop-pr-$PR_NUMBER"gitfetch origin"$BRANCH"gitworktreeadd"$WORKTREE""origin/$BRANCH"pushd"$WORKTREE"######################################### 7. 让 AI 做最小 SQL 修复########################################agent run minimal-mysql-fix\--target"$TARGET_FILE"\--state"$REPO_DIR/$STATE_FILE"\--context"$REPO_DIR/db"\--output.loop-mysql-fix.json######################################### 8. 创建本地 MySQL 测试库########################################DB_NAME="app_test_pr_$PR_NUMBER""${MYSQL_BASE_CMD[@]}"-e"DROP DATABASE IF EXISTS${DB_NAME};""${MYSQL_BASE_CMD[@]}"-e"CREATE DATABASE${DB_NAME};"######################################### 9. 加载 schema、seed、migration########################################"${MYSQL_BASE_CMD[@]}""$DB_NAME"<schema.sql"${MYSQL_BASE_CMD[@]}""$DB_NAME"<seed.sql"${MYSQL_BASE_CMD[@]}""$DB_NAME"<"$TARGET_FILE"######################################### 10. 跑业务验证查询########################################"${MYSQL_BASE_CMD[@]}""$DB_NAME"--batch--raw-e" SELECT c.id, c.lifetime_value, IFNULL(SUM(CASE WHEN o.status = 'paid' THEN o.total_amount ELSE 0 END), 0) AS expected_ltv FROM customers c LEFT JOIN orders o ON o.customer_id = c.id GROUP BY c.id, c.lifetime_value HAVING c.lifetime_value <> expected_ltv; ">.loop-mysql-verify-result.txt######################################### 11. 让 verifier 独立检查########################################agent run mysql-verifier\--diff"$(gitdiff)"\--verify-result .loop-mysql-verify-result.txt\--output.loop-mysql-verifier.jsonVERDICT=$(jq-r'.verdict'.loop-mysql-verifier.json)######################################### 12. 通过则推一个修复分支########################################if["$VERDICT"="pass"];thengitcheckout-b"loop/mysql-pr-$PR_NUMBER-fix"gitadd"$TARGET_FILE"gitcommit-m"fix: repair MySQL migration for PR #$PR_NUMBER"gitpush origin"loop/mysql-pr-$PR_NUMBER-fix"ghprcomment"$PR_NUMBER"\--body"MySQL Loop: proposed fix branch loop/mysql-pr-$PR_NUMBER-fix. Migration passed locally and verification query returned no mismatches."elseghprcomment"$PR_NUMBER"\--body"MySQL Loop: attempted fix failed verifier. Human review required."fi######################################### 13. 清理测试库########################################"${MYSQL_BASE_CMD[@]}"-e"DROP DATABASE IF EXISTS${DB_NAME};"######################################### 14. 回到原目录########################################popd

该怎么消化这套所谓的Loop Engineering呢？其实没有这么复杂，核心和要点就是切记一上来从“脚本很复杂”入手。你应该按责任拆：

ghprlist# 负责发现任务。triage agent# 负责判断能不能自动处理。gitworktree# 负责隔离环境。minimal mysql fix agent# 负责修改 SQL。mysql 本地测试库# 负责验证 SQL 能不能跑。verification query# 负责验证业务结果对不对，最好用不同的modelverifier agent# 负责检查 AI 有没有越界，最好用不同的modelgitpush + ghprcomment# 负责把结果交给人。

根据不同的场景，切记一些原则性的控制点如：

1. 不连生产库2. 不自动 merge3. verifier 必须独立检查

其他就都是工程细节了，看到这里，是不是觉得所谓的Loop Engineering，理念和ReAct是惊人的相似，核心都是执行后评估，根据评估结果决定是否继续操作；硬要说这个高维度的架构范式，确实很像，毕竟大道至简嘛，简单的架构范式总是容易殊途同归，就好像武学上容易天下武功出少林一个道理，但是Loop Engineering这套框架骨骼上填充具体血肉的时候，还是有很多自己的技术细节和讲究的，这些也是决定了最终你的某个项目的Loop Engineering是否算成功的关键。

5. 一些小建议：不要一上来就做完整 Loop

完整loop看起来很酷，但直接上生产其实多半也是找事故，永远记住好的产品是快速迭代出来的，而不是生来就完美，正确落地顺序应该是：

第一阶段：Prompt Engineering

先验证AI能不能修这类MySQL错误，目标：

能解释 ERROR 1111 能写出 derived table 修复 能区分 MySQL 和 PostgreSQL 语法

第二阶段：Context Engineering

加上这些文件：

AGENTS.md db/mysql-schema-map.md db/mysql-migration-rules.md db/mysql-verification.md db/mysql-risk-boundaries.md

目标：

让 AI 每次都知道项目规则、业务语义、验证方法和危险边界

第三阶段：Loop Engineering L1

只做报告，不改SQL。

检查 PR 读取 CI 判断风险 输出报告 不改文件 不建分支 不 merge

第四阶段：Loop Engineering L2

只允许低风险修复：

只改一个 migration 文件 只跑本地 MySQL 只开 fix branch 只评论 PR 不自动 merge

6. 三种方法的本质区别

对于MySQL migration场景，我的建议很明确：

个人临时修 SQL：Prompt Engineering 足够 团队长期维护 SQL：必须做 Context Engineering 高频 PR / CI 修复：再考虑 Loop Engineering

7. 最重要的安全红线

SQL场景下，AI 最大的风险不是语法错，而是写出一个“看起来正确、实际危险”的migration。

所以红线必须写死：

DROP：人工审批 TRUNCATE：人工审批 DELETE：人工审批 生产连接：禁止 大表 ALTER：人工审批 没有 verification query：不准通过 自动 merge：禁止

尤其是MySQL，很多DDL会隐式提交，不能天真地以为BEGIN / COMMIT能保护所有migration。

结论

Prompt Engineering解决的是一次性提问。

Context Engineering解决的是稳定输入。

Loop Engineering解决的是持续运行、状态管理、验证和人工接管。

以MySQL Migration为例，真正可落地的路径不是直接做一个“全自动 DBA Agent”，而是：

先让 AI 会修 再让 AI 按项目上下文修 最后才让 AI 在安全边界内循环处理低风险问题

把这三层分清楚，AI 编程才不会停留在复制粘贴报错给模型的阶段，也不会贸然跳到让 AI 自动改库的危险区间，也希望通过这个简单的例子，方便读者们更好的理解什么是从Prompt Engineering、Context Engineering到Loop Engineering的真正转变。

真正成熟的做法，是让 AI 做它擅长的低风险重复劳动，同时把验证、边界和最终决策权牢牢握在人和系统手里，毕竟现阶段还没有公司给硅基的各种Harness/Agent/LLM上过保险理赔，真出了产线P0事故，还是得碳基猴子背锅；当然也不能怕风险就裹足不前，毕竟如果游泳时鲨鱼来了，你为必要游过鲨鱼，嘿嘿，游得比别人快也行，所以尝试新事物还是建议小步快跑，能进能退就好。