企业官网建设流程全解析

最近独立开发者的圈子里，“rea”这个词出现得越来越频繁。最初它只是某个小项目给自己起的代号，后来慢慢变成一种隐喻：看到一条消息、一个表单、一段重复提问，立刻用脚本生成一句合适的回复，然后归档走人。说白了，就是给重复劳动按个快进键。

我花了一个周末，照着这个思路从零写了一个最小可用的 rea 工具。不依赖任何第三方库，一个配置文件加一个脚本，放在本机定时跑。它解决的事情很简单：把每天都会收到的同类消息、同类问题、同类请求，自动生成回复草稿或者自动归档，让我只需要在关键位置点一下确认。这不是一个面向所有人的产品，更适合内容运营、社群管理员、文档维护者，以及所有每天被“同一句话反复解释”折磨的人。

这篇文章我会完整讲清楚它的设计思路、核心机制、可运行的代码，还有这半年我踩过的坑。想直接动手的朋友，照着第三章的代码和规则文件抄一遍，十分钟就能跑起来。

1. 项目定位与设计思路拆解：为什么需要“rea”

“rea”本质上不是一个框架，也不是什么新技术。它是我给自己的一类重复劳动找的解决方案。动手之前，我先花了不少时间梳理自己每天到底在重复做什么，结论是三类：一类是回复重复问题的客服劳动，一类是搬运信息的归档劳动，还有一类是照模板填内容的填空劳动。

1.1 天天在做的三类重复劳动，以及各自的痛点

先说客服劳动。社群和管理后台每天都有新人问同样的问题：报销单格式去哪下载，文档链接为什么打不开，某个功能入口在哪。我手动回复过上百遍，每次都复制粘贴同一段话，偶尔改个名字。这类劳动的问题是：内容高度模板化，但消息来源混杂，必须逐条判断之后再回，不能无脑自动。

再说归档劳动。每天要在多个来源收集消息、截图、表格，然后整理成固定格式的文档存进资料库。手动做，步骤本身不难，但容易遗漏，而且整理完后还要再核对一遍“是不是真放进去了”。

最后是填空劳动。把某个客户信息、订单号、日期，从一个系统复制到另一个模板里，生成一份看起来像定制的通知或记录。技术含量不高，但错一个数字就要返工。

这三类劳动有个共同点：规则是确定的，输入是半结构的，唯一需要人判断的部分在于“什么消息走什么规则”。只要把这段判断规则化，剩下的事情完全可以让脚本完成。这就是“rea”诞生时的核心假设：把确定性的流程交给脚本，把不确定的判断留给人。

1.2 三条设计原则：轻量、可组合、留痕

动手写之前，我给自己定了三条非常朴素的原则。

第一是轻量。个人工具最大的敌人是维护成本。如果这个工具需要装几十个依赖、配置一个数据库、起一个服务，那它很快就会因为“太麻烦”被弃用。所以“rea”被设计成：一个 Python 脚本加一个 JSON 规则文件，目录结构就是整个项目的全部。想跑起来，只要本机有 Python 3.9 以上版本，不需要任何第三方库。

第二是可组合。规则和动作是两个独立的概念。规则负责回答“什么消息需要处理”，动作负责回答“处理成什么样”。一条规则可以只有一个动作，也可以组合多个动作，比如“生成回复、追加归档、写日志”。这种设计背后其实是“组合优于堆叠”的思路：功能不往代码里堆，而是靠数据文件去组合，改起来不用动脚本，试错成本很低。

第三是留痕。所有自动执行的动作，都必须留下记录。这事听起来像常识，但很多个人工具都不做。没有日志，哪天规则误触了，你根本不知道发生了什么。我把日志当成自动化的“行车记录仪”：平时它没什么存在感，一旦出问题，它是唯一能还原现场的东西。

为什么这三条对个人工具尤其重要？因为个人工具没有专职开发维护。半年后再打开这个脚本的，大概率还是你自己。如果设计时不留余地，到时候你可能完全看不懂自己当时写了什么。

1.3 对比现成方案，为什么最终选择自己写

做之前我认真评估过几种现成方案。

按键精灵和通用 RPA 工具擅长模拟鼠标键盘操作，适合操作图形界面，但我的场景是纯文本处理，用它们属于大材小用，而且脚本换个电脑就要重新调试环境。办公软件自带的宏，只能处理表格或文档内部的信息流转，覆盖不到网页消息和即时通聊天记录。直接用大模型提示词做自动化，效果确实灵活，但同样的消息每次生成的结果会飘，模板里带个订单号偶尔会被改写，作为一个“要稳定输出固定格式”的工具不太合适，而且本来只想跑个离线小脚本，没必要为它架一堆接口。

把几种方案放在一起对比会更清楚：

结论很清楚：我要的不是“聪明”，而是“可靠”。重复劳动对应的恰恰是确定性场景，用一条条写死的规则比用大模型更合适。规则引擎让我对每一步都有控制权——我知道哪条规则会命中、会生成什么内容、会写到哪个文件里。

2. 核心模块与关键机制解析：规则引擎怎么设计才可控

“rea”的整个核心只有四个部分：规则文件、匹配器、执行器和日志模块。任何一个自动化工具，说到底都是在回答两个问题：什么时候触发，触发之后做什么。规则引擎就是用来保证这两个问题的答案都是确定的。

2.1 规则文件：让非程序员也能看懂的条件与动作

“rea”的所有逻辑都写在 rules.json 里。每条规则的结构非常简单，核心就两部分：怎么匹配、怎么处理。

{ "id": "r001", "priority": 1, "match": "contains", "pattern": "报销单", "actions": [ { "type": "reply", "content": "报销单模板在文件中心的“财务”目录下，取件码 2025-01。" }, { "type": "append", "path": "output/replies.md", "content": "已回复报销单相关问题。" } ] }

这里“match”决定匹配方式，我实现了三种，足够覆盖绝大多数场景：

• contains：消息中包含某个关键词，适合日常最常见的情况；
• prefix：消息以某个固定前缀开头，适合“求问”“紧急”“报销”这类带标识的入口；
• regex：按正则表达式匹配，适合提取订单号、手机号、日期这类结构化信息。

“priority”是优先级，数字越小越先执行。规则被命中后，默认整条消息就不再往下匹配其他规则。如果确实希望一条消息同时命中和触发多条规则，可以在规则里加上 "continue": true，让它继续找下一条。这个设计是为了避免重复回复——如果关键词重叠，很容易一条消息被回两次。

动作部分目前支持两种：reply 只是打印一段回复文本，让使用者决定下一步怎么处理；append 会把指定内容追加到某个文件里，用于归档。两种动作都可以自由组合，模板里的 {date}、{time} 这类占位符会被自动替换成当前时间。

我特意没有把规则设计成一套更复杂的 DSL。原因很简单：规则文件是要经常改的，改的人可能是不写代码的运营同事。如果规则语言太复杂，最终结果就是没人敢改，所有更新都堆到我这里来，那就违背了“轻量”的初衷。用最朴素的 JSON 加三种匹配方式，已经解决了 90% 的需求。

2.2 匹配器与变量替换：从“命中”到“生成内容”的中间层

匹配器本身不复杂，但“变量替换”是个值得展开的细节。很多情况下，自动回复不是一句固定模板，而是要把用户消息里的某个动态片段提取出来，再拼到模板里。最典型的场景是订单号。

我在规则里设计了“capture”字段，配合正则表达式的分组来提取动态内容。

{ "id": "r002", "priority": 2, "match": "regex", "pattern": "订单\\s*([A-Z0-9]+)", "capture": ["order_no"], "actions": [ { "type": "reply", "content": "收到的订单号是 {order_no}，已记录。" }, { "type": "append", "path": "output/replies.md", "content": "订单 {order_no} 状态：待查询。" } ] }

当消息是“麻烦查下 订单 AB12345 物流”时，正则匹配到 AB12345，捕获组的值被放进 context 对象里，模板渲染阶段用真实值替换占位符，最后生成“收到的订单号是 AB12345，已记录。”

这个机制理解起来就是“填空”：模板是印刷好的表单，捕获组就是往空格里填写的值。每次生成的文本不仅格式统一，而且关键信息不会漏掉。为了防止替换时把模板里的占位符漏掉，我写了一个 render_template 函数，遍历上下文里的所有键值，逐个替换。如果规则写得有问题，渲染结果里会留下明显的“未替换占位符”，一眼就能看出来。

2.3 执行器与安全阀：自动化的前提是可控

执行器是真正干活的模块，它读取动作列表，执行 reply 或 append。相比逻辑本身，更值得说的是我给执行器加的三道安全措施。

第一道是 dry-run 模式。执行脚本时加 --dry-run 参数，脚本只输出“将要做什么”，不会真的写入文件。这个设计对应了自动化领域一个古老但有效的习惯：先演练再实弹。我刚写完规则时，几乎每次都先跑一遍 dry-run 看命中情况，确认没有误伤才正式执行。

第二道是动作限额 MAX_ACTIONS。单次运行最多只执行 50 个动作。这个限制的来历是因为我遇到过一种情况：某条规则匹配得太宽，一次导入几千条历史消息，如果全部执行，会把归档文件写得乱七八糟。有了上限，脚本会在达到上限后直接停止，相当于给失控状态拉了一个急停闸。

第三道是延迟控制。每个动作可以配置 delay，让实际执行时先停零点几秒再继续。对于本地文件操作，延迟不是必需；但如果后续扩展成调用外部接口，这个延迟就是最简陋的限流器，防止一把梭把对方服务打爆。我在代码里统一用 time.sleep 实现，现在看是过度设计，但在加“调用外部系统”这类动作时会非常省心。

2.4 留痕设计：append-only 日志与事后追溯

日志模块是“rea”里看起来最简单、实际上最救命的部分。每执行一个动作，脚本就往 run.log 里追加一行，包含时间戳、命中规则 ID、动作类型和内容摘要。日志只追加不覆盖，避免“上一次运行把上次日志清了”这种低级事故。

我用的是最朴素的自定义函数，没有引入 logging 库的复杂配置，因为需求就那么点：记录、追加、按行读。日志文件名可以在脚本头部改成按日期拆分，比如 run-2025-01-20.log，后续清理也更方便。

留痕的意义在于：当有人问你“这条自动回复到底是不是 rea 发的”时，你可以翻出日志，精确告诉他对应哪条规则、哪条消息、什么时间。我自己就有一次差点把所有规则删掉重写，后来靠日志发现只是一条旧规则的优先级没调，被另一条规则抢了先。如果没有日志，那天就是另一个故事了。

3. 从零实现一个最小可用版本：十分钟跑起来的实操流程

这一章给出可以直接抄的完整实现。我没有用任何第三方库，复制文件到本机就能跑，核心脚本大约 150 行。

3.1 环境准备与目录结构

先准备环境。本机有 Python 3.9 以上版本即可，不需要安装任何东西。我平时在 macOS 和 Windows 上都跑过，行为一致，唯一要注意的是 Windows 控制台编码问题，后面第四节详细说。

目录按下面这种方式组织：

rea/ ├── rea.py # 主脚本 ├── rules.json # 规则文件 ├── messages/ │ └── sample.txt # 待处理消息，一行一条 ├── output/ │ └── replies.md # 归档输出文件 └── logs/ └── run.log # 运行日志

目录结构就用相对路径，脚本启动时以自身所在目录为基准找文件，不管你在哪个路径下执行，都不会出现找不到文件的尴尬。这也是个人小工具实用性的一部分。

3.2 主脚本 rea.py：完整代码

把下面这段代码保存为 rea.py：

#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ rea - 轻量级文本规则处理器 用法: python rea.py --dry-run # 只展示将要执行的动作 python rea.py # 正常执行 python rea.py --input messages/xxx.txt # 指定待处理消息文件 """ import argparse import json import re import time from datetime import datetime from pathlib import Path BASE_DIR = Path(__file__).resolve().parent RULES_FILE = BASE_DIR / "rules.json" INPUT_FILE = BASE_DIR / "messages" / "sample.txt" OUTPUT_FILE = BASE_DIR / "output" / "replies.md" LOG_FILE = BASE_DIR / "logs" / "run.log" MAX_ACTIONS = 50 # 单次运行最多执行的动作数 def load_rules(path): with open(path, "r", encoding="utf-8") as f: return json.load(f) def load_messages(path): if not path.exists(): return [] return [ line.strip() for line in path.read_text(encoding="utf-8").splitlines() if line.strip() ] def match_rule(rule, text): match_type = rule.get("match", "contains") pattern = rule.get("pattern", "") if match_type == "contains": return pattern in text if match_type == "prefix": return text.startswith(pattern) if match_type == "regex": return re.search(pattern, text) is not None return False def render_template(template, ctx): result = template for key, value in ctx.items(): result = result.replace("{" + key + "}", str(value)) return result def build_context(rule, text): ctx = { "date": datetime.now().strftime("%Y-%m-%d"), "time": datetime.now().strftime("%H:%M"), } match_type = rule.get("match", "contains") if match_type == "regex" and "capture" in rule: m = re.search(rule["pattern"], text) if m and m.groups(): for idx, group_name in enumerate(rule["capture"], start=1): ctx[group_name] = m.group(idx) return ctx def run_action(action, action_index): action_type = action.get("type", "reply") content = action.get("content", "") if action_type == "reply": return f"-> {content}" elif action_type == "append": target = BASE_DIR / action.get("path", "output/replies.md") target.parent.mkdir(parents=True, exist_ok=True) with open(target, "a", encoding="utf-8") as f: f.write(content.rstrip() + "\n") return f"已追加到 {target}" return "未知动作" def append_log(line): LOG_FILE.parent.mkdir(parents=True, exist_ok=True) with open(LOG_FILE, "a", encoding="utf-8") as f: f.write(line + "\n") def main(): parser = argparse.ArgumentParser(description="rea - 轻量级文本规则处理器") parser.add_argument("--dry-run", action="store_true", help="只展示将要执行的动作") parser.add_argument("--input", type=str, help="待处理消息文件路径") args = parser.parse_args() rules = load_rules(RULES_FILE) rules.sort(key=lambda r: r.get("priority", 100)) input_path = Path(args.input) if args.input else INPUT_FILE messages = load_messages(input_path) if not messages: print("没有消息需要处理。") return action_count = 0 print("===== rea 运行开始 =====") for msg in messages: for rule in rules: if not match_rule(rule, msg): continue ctx = build_context(rule, msg) actions = rule.get("actions", []) print(f"[{datetime.now():%H:%M:%S}] 规则 {rule['id']} 命中 -> {msg[:60]}") for action in actions: if action_count >= MAX_ACTIONS: print("达到单次动作上限，停止。") append_log("WARN 超过 MAX_ACTIONS，停止执行") return rendered = render_template(action.get("content", ""), ctx) display_action = { "type": action.get("type"), "content": rendered, } if args.dry_run: print(" [dry-run]", run_action(display_action, action_count)) else: time.sleep(action.get("delay", 0)) result = run_action(display_action, action_count) print(" ", result) append_log( f"OK 规则={rule['id']} 动作={action.get('type')} 内容={rendered[:80]}" ) action_count += 1 if not rule.get("continue", False): break print("===== rea 运行结束 =====") if __name__ == "__main__": main()

代码风格刻意保持极简，每个函数只做一件事，没有乱七八糟的抽象。原因还是那个：个人工具的代码要经得起半年后重新阅读。

3.3 规则文件示例：覆盖三种匹配方式

对应的 rules.json 示例文件：

[ { "id": "r001", "priority": 1, "match": "prefix", "pattern": "求问", "actions": [ { "type": "reply", "content": "你好！这里是常见问题说明，请先查看帮助中心，或者描述一下具体问题。" }, { "type": "append", "path": "output/replies.md", "content": "## {date} 收到一条待跟进问题" } ] }, { "id": "r002", "priority": 2, "match": "regex", "pattern": "订单\\s*([A-Z0-9]+)", "capture": ["order_no"], "actions": [ { "type": "reply", "content": "订单 {order_no} 已记录，稍后会有专人回复。" }, { "type": "append", "path": "output/replies.md", "content": "订单 {order_no} 状态：待查询 " } ] } ]

注意：JSON 文件里不能写注释，所以我把说明写在文末。如果需要字段说明，建议单独维护一个 README，或者用规则 ID 本身做注释，比如 r001 表示“通用求助问题”，r002 表示“订单查询”。

3.4 运行效果与日志输出

在 messages/sample.txt 里放几条测试消息：

求问：新人入职要带什么材料？ 求问：报销单格式哪里下载？ 麻烦查下 订单 AB12345 物流 下午开会的会议室定了吗

第一次先跑 dry-run，只看不执行：

python rea.py --dry-run

输出结果：

===== rea 运行开始 ===== [10:23:41] 规则 r001 命中 -> 求问：新人入职要带什么材料？ [dry-run] -> 你好！这里是常见问题说明，请先查看帮助中心，或者描述一下具体问题。 [dry-run] 已追加到 /path/to/rea/output/replies.md [10:23:41] 规则 r001 命中 -> 求问：报销单格式哪里下载？ [dry-run] -> 你好！这里是常见问题说明，请先查看帮助中心，或者描述一下具体问题。 [dry-run] 已追加到 /path/to/rea/output/replies.md [10:23:41] 规则 r002 命中 -> 麻烦查下 订单 AB12345 物流 [dry-run] -> 订单 AB12345 已记录，稍后会有专人回复。 [dry-run] 已追加到 /path/to/rea/output/replies.md ===== rea 运行结束 =====

第四条消息“下午开会的会议室定了吗”没命中任何规则，保持原样，由人工处理。这一行为非常关键：rea 只负责减轻工作量，不试图替你做决定。确认无误后，去掉 --dry-run 再跑一遍，真实写入回复和归档。

3.5 为什么规则用 JSON 不用其他格式

选 JSON 是刻意的。首先，Python 标准库直接支持，不用为解析 YAML 引入额外依赖；其次，JSON 是文本格式，记事本就能改，给不写代码的同事做培训也容易；最后，JSON 结构严谨，少个逗号立刻报错，不会出现“格式看着对但解析出来是空”的模糊问题。相比之下 YAML 虽然更易读，但对缩进极其敏感，个人工具里反而容易埋坑。

4. 实际落地中的常见问题与排查技巧实录

这一章是真实踩坑记录。“rea”从写完到稳定运行，中间经历了各种幺蛾子。整理成四个最有代表性的问题，每个都给出现象、原因和处理方法。

4.1 规则匹配过宽，误伤正常消息

第一次尝试用 contains 匹配关键词“地址”，结果凡是消息里带“地址”二字的全部被自动回复，包括“你的收货地址有误”这种不应该自动处理的反馈。原因很简单：关键词粒度过粗，没有限定消息的来源场景。

解决办法是把规则条件变严格。比如限定前缀、用正则加边界词，或者像下面这样加来源判断：

{ "id": "r003", "priority": 5, "match": "regex", "pattern": "^(售后|客服渠道) 地址", "actions": [ { "type": "reply", "content": "地址问题请查看订单详情页的地址管理。" } ] }

我后来养成了一个习惯：任何新增规则，都会先拿最近一两个月的消息样本跑一遍 dry-run，统计命中数量。如果命中率超过日常预期的两倍，就说明关键词太宽，得收一收。放到生产环境再发现误伤，代价就大了。

4.2 Windows 控制台的编码乱码问题

在 Windows 上运行，第一次 print 中文就乱码了，输出文件内容也是乱码。原因是 Windows 控制台默认编码不是 UTF-8，Python 的 stdout 和文件读写编码不一致。这个问题在老版本 Windows 上尤其烦人。

解决办法分三层：脚本内所有文件读写都显式指定 encoding="utf-8"；运行前在控制台执行 chcp 65001 切换代码页；如果重定向输出到文件，再加环境变量 PYTHONIOENCODING=utf-8。值得说明的是，三层里第一层最重要，文件编码写对了，数据就不会坏。输出到控制台乱码只是难看，文件里乱码才是真的灾难。

4.3 日志文件越来越大的烦恼

“rea”跑了几个月后，run.log 到了两百多兆，打开都卡。原因有两个：每动作都写一行，量累积起来自然不小；日志里还存了完整模板内容，冗余严重。

我的处理是双管齐下。一方面裁剪日志内容，只记前 80 个字符的内容摘要，不存完整消息正文；另一方面改成按天拆日志，文件名带日期，每天一个文件，保留最近 7 天。个人工具不需要企业级日志平台，这样朴素的做法足够。如果想更省事，直接用 Python logging 模块的 TimedRotatingFileHandler 也行，但我没引入，因为加一个第三方模块就多一个维护点。

4.4 动作偶尔没执行的排查思路

最诡异的一次是某条消息明明命中了规则，打印信息也正常，但 output/replies.md 里就是没有对应内容。排查了一圈，最后发现是 append 动作里写的相对路径有误，脚本把文件写到了别的目录，而打印信息里显示的是目标路径，不仔细看根本发现不了。

这个问题的排查思路值得记下来：先看 run.log，有执行记录就说明规则和动作都触发了，问题出在输出侧；没有执行记录就说明匹配阶段出了问题，回过去检查规则条件。检查顺序永远是“日志 → 输入消息 → 规则字段 → 输出路径”，别一上来就怀疑代码逻辑。代码逻辑在 dry-run 阶段就该验证过，真正上线后的 bug 大多数出在数据和路径上。

这四类问题我做成了一张速查表，贴在脚本目录里：

5. 进阶扩展方向与我的实操心得

“rea”目前的形态足够解决我 80% 的需求，但它的架构留了很自然的扩展口。如果你也想做一个类似的小工具，可以从这几个方向继续发展。

5.1 四个值得做的扩展方向

第一个方向是接入定时任务。在 Windows 计划任务或系统 cron 里加一条命令，每天固定时间跑一次 rea，把 messages 目录下的新文件处理完。定时跑的价值在于，消息文件可以靠其他脚本自动汇总，rea 自动消费，整条链路就自动化了。

第二个方向是接入 webhook。当某个渠道有新消息时，直接把消息文本 POST 到本机一个轻量接口，接口收到后调用 rea 的处理函数。这一步会让工具从“批处理”变成“实时处理”，但前提是先把本地批处理跑稳。

第三个方向是扩展动作类型。目前只支持 reply 和 append，如果需要在动作里发请求、改文件、调外部 API，只需要在 run_action 函数里加一个分支。扩展点的设计原则是：先让新动作支持 dry-run，再接入真实副作用，千万不能在自动化工具里加一个无法演练的动作类型。

第四个方向是和个人知识库联动。append 动作的目标从本地 markdown 改成笔记软件支持的导入目录，让每次归档都自动沉淀到知识库里。配合日期变量，半年后翻知识库时，能直接看到完整的处理轨迹。

5.2 我从这个项目里收获的三条实操心得

第一，规则不是一次性写好的，而是跟着真实消息迭代出来的。我一开始只写了三条规则，跑了大概两周后，根据真实消息不断增补和调整，才长成现在这套。设计之初不要追求规则覆盖全面，先在最小可用版本上跑起来，再逐步加。

第二，自动化之前，先把手动流程完整跑通一遍。这听起来像废话，但我见过很多自动化项目翻车，就是因为连手动流程都没理顺，就开始写脚本。手动流程中的每一个分支，都应该在规则里有一个明确对应；没有对应到的地方，就是将来误判的隐患。

第三，一定要留一个手动开关。我的 dry-run 参数就是那个开关，它在关键时刻救了我很多次。遇到大批量导入消息、规则刚修改完、操作对象是很重要的文件目录时，我都会先开 dry-run 看一眼。自动化最大的风险不是慢，而是失控；控制失控的最简单手段，就是让执行前多一道人工确认。

最后再分享一个小技巧：我在 rules.json 的后面加了一个固定不用的占位规则，专门用来记录规则文件的版本号和更新时间。每次改规则，会顺手把版本号更新一下，同时日志头部会记录“本次使用的规则版本”。这样半年后如果发现某天的处理结果有问题，我能直接定位到那个阶段用的是什么规则，不用靠记忆硬猜。这个习惯看着不起眼，排查历史问题的时候是真香。