企业官网建设流程全解析

大家好，我是冰河~~

记得有天下午，测试同事小赵在群里发了张截图。订单表里某个状态的记录数比上一版多了三倍，他花了四十分钟才看出来。我问他怎么查的，他说手敲的 SQL，字段名还记错了一次。

这让我想起自己刚参加工作那年，每周至少有三四次打开数据库客户端，写差不多结构的查询。每次都从零开始，每次都怕写错，每次查完就忘。

后来我换了个做法。不再自己写 SQL，也不让 AI 随口编——我给它写了一份规矩，告诉它遇到什么情况该怎么查、什么绝对不能碰。之后我只需要说一句话，它就能按我定的流程走完。

这篇就讲讲这份规矩是怎么写的，以及为什么它比直接问 AI 更靠谱。

不写代码，那到底在写什么

一说“让 AI 自动化干活”，很多人会想到调接口、搭服务、写脚本。但我要说的这个办法，核心产物就是一个纯文本文件。

它是一份给 AI 看的操作手册。里面用大白话写清楚五件事：你是谁、你能干什么、你不能干什么、按什么顺序干、什么情况必须停下来。

AI 拿到这份手册之后，就像新员工拿到了岗位说明书。它不会自由发挥，也不会越界。因为每一个动作都被你提前写好了。

这份手册不需要跑起来，也不需要编译。写完之后放在 AI 能看到的地方，它自己就会在合适的时机调用。

第一步：先把它“不能做的事”写清楚

新手最容易踩的坑，是给 AI 开太大的权限。让它既能查又能改，最后它真的会改。

所以我的做法是反过来：先写清楚它绝对不能做什么。

绝对不能碰写操作。任何 INSERT、UPDATE、DELETE、DROP、TRUNCATE、ALTER，一个都不许。看到这些词，直接停下。

绝对不能碰生产库。只能查测试库和影子库，这个在配置里锁死。

绝对不能自动执行。它写出来的 SQL，必须我先看一眼、点个头，才能真的去数据库里跑。

把这三条写进手册最靠前的位置，你的安全底线就守住了。后面的所有步骤都建立在“它不会乱来”这个前提上。

第二步：把操作流程写成清单

边界定好了，接下来告诉它干活的具体顺序。

我写的流程一共六步，每一步都很简单：

第一步，复述问题。用户说要分析订单状态分布，它得先回一句“你是要看 orders 表里 status 字段各个取值的数量，对吗”。确认目标没歧义再往下走。

第二步，查表结构。不靠记忆写 SQL。先去读真实的表结构，拿到字段名和类型，再动笔。

第三步，写查询语句。写的时候加上注释，字段名用中文别名，方便我核对。

第四步，自己先检查一遍。看看有没有写关键字、有没有超出白名单的表。有问题就停下来告诉我，不许硬着头皮往下走。

第五步，给我看。把 SQL 和一句话解释一起展示出来，等我确认。

第六步，执行并解读。我点了确认之后，它在只读账号下跑，把结果整理成表格，然后指出有没有异常值。

这六步写清楚之后，AI 就不会跳步，也不会自己加戏。

第三步：把安全规则写成硬性条件

流程之外，还有一些零散的规则需要单独列出来：

碰到insert、update、delete、drop、truncate、alter这些词，不管出现在哪里，一律拒绝。

如果表里有手机号、身份证号这类字段，要么脱敏，要么直接排除，不许原样打印出来。

结果行数如果超过五千，先跑 COUNT 看看总数，再决定要不要抽样。不然一条查询可能把测试库拖慢。

这些规则不参与流程，但它们是一道防火墙。写进手册里，AI 每次执行前都会扫一遍。

把上面这些串起来：整成完整的SKILL

下面是这份手册的全文。我写得比较细，你可以直接拿去改。

--- name:>配套的配置：只读账号加白名单
手册写好了，但光有手册不够。你还需要给它一个安全的运行环境。
只读账号。找 DBA 申请一个只有 SELECT 权限的账号。授权范围只限测试库和影子库。别图省事给主账号。
白名单配置。在配置文件里列清楚允许访问的库和表。
allowed_databases:-test_order_db-shadow_user_dballowed_tables:-orders-user_action_log-payment_record
SQL 审核层。执行前再做一道关键字扫描。这一步可以写个几行的小脚本，也可以在流程里靠自检步骤加人工确认来兜底。
核心原则就一句：AI 写的 SQL 必须经人确认才执行。它快，但出了事是你担着。
用一个真实场景跑一遍
手册和配置都齐了，找个实际任务试一下。
任务：回归测试结束后，核对 orders 表里各个订单状态的数量分布，看看有没有异常堆积。
按手册的流程，AI 会这样走：
确认问题：它复述——“你要看 test_order_db 里 orders 表按 status 分组的数量和占比，对吗？”
读表结构：拿到字段列表：id、status、created_at。status 的取值有五种：待支付、已支付、已发货、已完成、已取消。
写 SQL：
-- 统计各订单状态的数量和占比，排查是否有异常堆积SELECTstatusAS订单状态,COUNT(*)AS订单数,ROUND(100.0*COUNT(*)/SUM(COUNT(*))OVER(),2)AS占比_百分比FROMordersGROUPBYstatusORDERBY订单数DESC;
安全自检：纯 SELECT，表在白名单里，不涉及敏感字段。通过。
提交确认：展示 SQL 和一句话解释：“这条语句按状态分组，统计每种状态的订单数量和占比。”
执行解读：返回表格，并提示：“已取消占比 42%，上一版本是 18%。建议排查取消流程是否有回归异常。”
从一句话到带结论的分析，全程可复现。下次换个问题，它还是按这套流程走。
三个我踩过的坑
第一个坑：AI 编字段名。
它有时候会凭印象写一个不存在的字段。解决办法很简单——强制它先读真实表结构，再写 SQL。手册里写清楚这一步不能跳。
第二个坑：图省事给了写权限。
我之前偷懒，直接用了主账号。结果有一次 AI 生成的 SQL 里混进了一个 UPDATE，差点出事。后来老老实实申请了只读账号。
第三个坑：敏感字段直接打出来。
有一次分析用户行为日志，结果里带着手机号。虽然是在测试库，但也不该这么干。后来把脱敏规则写进了安全红线。
你现在可以做的
上面这套东西不需要你写代码，也不需要搭服务。就是一份文本文件加一个只读账号的事。
你可以从最小版本开始：
先写清楚三条红线——只读、白名单、先审后执行。然后把六步流程列出来。最后接上只读账号，跑一个你每周都在手敲的查询。
跑通一次之后，你会发现原来那些重复劳动真的可以交出去。而且因为你提前写好了规矩，交出去之后也很放心。
好了，今天就到这儿吧，我是冰河，我们下期见~~
推荐阅读
给大家推荐一个AI短剧项目