企业官网建设流程全解析

先问一个扎心的问题：你手机上的学习打卡软件，最后都坚持了几天？

对多数人来说，自律的崩溃不在计划表，而在“没人看见”。Forest种下的树死了也就死了，番茄钟响了也可以按掉，闹钟更是关了就能倒头继续睡。传统效率工具只能提醒你“该做什么”，却无法在你想糊弄自己的那一刻，给出一个足够有压迫感的反馈。

这也是我最近看到“AI虚拟监督员”这类项目时，最感兴趣的地方。尤其是一个标题叫《70亿token，做了个AI德国军官监督我学习》的项目，把AI角色扮演、语音交互、任务调度放在了一起：屏幕上有一个严肃的虚拟军官，实时盯着你的学习进度，用有压迫感的语调催你专注，还参加了B站AI创造公开赛。项目本身玩的是角色扮演和趣味性，但真正让我这个做技术的人注意到的是那个数字——70亿token。

70亿token不是噱头，它就是一个大模型应用从演示走向真实使用后，绕不开的三重门槛的缩影：角色太久不崩、上下文越撑越大、成本越烧越吓人。这篇文章就从技术角度拆解这类“AI监督学习”应用：它解决了什么问题、70亿token是怎么烧出来的、角色人设如何用Prompt工程立住，以及一个最小可运行的实现长什么样。

1. 这类AI监督项目，真正解决的问题是什么

1.1 传统自律工具的极限

传统自律工具的模型是“定时提醒 + 可视化记录”。你设一个番茄钟，25分钟后响铃；你种一棵树，专注期间不能碰手机。这些工具的共同假设是：只要给足外部刺激，人就会回到任务上。

但真实情况往往是：

• 提醒来了，随手关掉，然后继续刷视频；
• 记录页很漂亮，但完成率并没有变高；
• 一个人学习时缺少被观察、被评价、被追问的压力，很多任务悄悄就滑过去了。

从行为设计的角度看，提醒只是最表层的干预。真正让人坚持的，往往是一种“来自他人的反馈压力”和“对结果的即时回应”。传统工具给不了这种回应，因为它们的逻辑是“记一笔、设一个闹钟”，而不是“认真看着你做出判断”。

1.2 从打卡工具到有回应的监督者

“AI德国军官监督我学习”这个项目有趣的地方，不在于它有多复杂的算法，而在于它改变了交互角色：AI不再是一个被动的工具，而是一个有性格、有态度、会主动检查你进度的监督者。

这种设计的核心是“被看见”。当你打开电脑准备摸鱼时，AI会通过语音或文字给出反馈：“当前进度与目标差距较大，请说明原因，并告诉我下一步完成时间。”过去你只需要面对一个冷冰冰的待办清单，现在你要面对一个会追问、会评判、会继续验收的虚拟角色。

技术上说，这已经不是一个简单的“定时提醒”程序，而是一个由大模型驱动的对话式AI Agent：它需要感知状态、理解上下文、生成带人格的反馈，并在多轮交互中保持一致性。这也是为什么这类项目会被放进AI创造公开赛里——它展示的是大模型应用的产品化可能性，而不是单纯调一个API。

1.3 这个项目适合谁

先给读者一个重要提醒：这类“监督学习”工具并不是对所有人都有效，它有自己的适用边界。

适合的人群：

• 需要外部节奏感才能进入专注状态的人；
• 能接受角色扮演式反馈、喜欢“有人追着赶”的人；
• 本身愿意学习，但缺少每日复盘和持续提醒的人。

不适合的人群：

• 对AI反馈过敏，看到严厉话术就产生抵触的人；
• 深层拖延已经严重影响生活，需要专业介入的人；
• 想要完全自动化、不参与任何输入的学习者。

用一句话概括：AI监督学习应用真正擅长的，不是替你自律，而是把你和任务之间的差距，变成一段段看得见、听得见、能回应的对话。它降低了“启动学习”的阻力，但前提是你愿意进入它设定的互动规则。

2. 70亿token意味着什么：先把这笔账算清楚

2.1 大模型语境下的token到底是什么

Token（令牌/词元）是大模型处理文本的基本单位。一段文字会被模型拆成若干个token，再交给模型计算。简单理解：

• 英文中，一个token通常对应一个短词或一个词的一部分；
• 中文中，一个token大约对应一到两个常用汉字；
• 1个英文单词平均约1.3个token，1个汉字平均约0.6到1个token，不同模型的分词器有差异。

大模型API按token计费。用户输入（prompt）和模型输出（completion）都计费，每一轮对话都要把系统提示词、历史消息、当前问题重新发给模型，所以token消耗会随对话轮数快速增长。

这也解释了为什么“token”会成为一个热词。任何做大模型应用的人，每天都在看token用量，因为token直接等于钱和性能。

2.2 70亿token有三种可能的口径

先说明：我不是这个项目的作者，不知道作者说的70亿token是哪种口径。但从技术角度看，“70亿token”在标题里通常有三种可能：

口径一：开发调试期间累计调用的token总量。也就是从写第一版Prompt，到反复跑测试、调角色风格，累计烧掉的API token。这种口径最常用于描述“我为这个项目投入了多少大模型资源”。

口径二：运行期间长期累积的token消耗。语音对话、多轮追问、视觉识别都会消耗token。如果一个应用每天跑几十轮对话，一个月累积到亿级并不夸张，70亿是持续运行几个月后的总量。

口径三：模型训练或微调的数据量。如果作者自己训练了模型，70亿token可能是训练语料的总规模。但对一个“监督学习”交互应用来说，数据训练口径相对少见，前两种更贴近工程实际。

理解这个口径非常重要。因为如果你自己做一个类似应用，需要预估的token成本不是“70亿”这个总数，而是“每轮对话消耗多少token、每天多少轮、跑多久”。

2.3 一次“监督反馈”会吃掉多少token

我们用一套常见配置来估算：假设系统提示词（SYSTEM_PROMPT）为500个token，每轮用户上报状态100个token，AI反馈90个token。

• 第1轮对话：500 + 100 + 90 = 690个token；
• 第5轮对话时，如果把前4轮历史全部带上，总输入约为500 + 4×(100+90) + 100 = 1450个token；
• 第20轮对话时，光历史消息就有接近4000个token。

这还只是纯文本。如果加入语音识别，把用户语音转成文字，每1分钟语音大约对应150到200个token；如果再加入摄像头画面、屏幕截图等视觉输入，一张图就可能消耗几百到上千个token。

所以一个每天20轮对话、偶尔带视觉输入的应用，一天消耗10万token是非常正常的。一个月就是300万到1000万级别，连续运行一年，确实可以逼近十亿级。看到70亿这个数字，我的第一反应不是“夸张”，而是这个作者大概率真的做了很长时间的迭代。

2.4 token成本估算的方法

不同模型的官方定价差异很大，这里不做具体报价，只说一种通用的估算思路。

假设某模型按固定单价计费（为演示，价格是假设值）：

实际成本取决于你使用的模型、输入输出比例、是否用批量接口、是否有缓存优惠。但可以确定的是：如果进入长期运行阶段，token成本会是这类应用最重要的运营指标，没有之一。这也是为什么下面会专门写成本优化方案。

3. AI监督学习系统的整体架构

3.1 五个核心模块

从一个可工程化的角度看，“AI德国军官监督我学习”这类系统可以拆成五个模块：

3.2 为什么它是一类典型的AI Agent

如果只看表面，会觉得它就是一个“定时调用大模型API”的脚本。但把它放进AI Agent的框架里看，它的关键区别在于：

• 有主动行为：不是只等用户提问，而是按调度器主动检查任务；
• 有外部状态感知：学习进度、剩余时间、当天计划是外部输入；
• 有角色一致性：多轮对话中必须保持“军官”的人设；
• 有反馈闭环：AI给出反馈后，用户执行，下一次巡查会检查执行结果。

也就是说，它具备AI Agent最基本的特征：感知（Perception）、决策（Reasoning）、行动（Action）、反馈（Feedback）。这类架构也复用于AI教练、AI陪练、AI客服等更多场景。

3.3 技术选型建议

对大多数个人开发者和比赛项目来说，最稳妥的选型组合是：

• 大模型API：选OpenAI兼容接口，方便切换模型；本地模型想省钱可以用支持量化推理的方案，但角色一致性可能下降；
• 语音合成：edge-tts免费、语音自然，适合中文；如果要离线，可以用pyttsx3；
• 调度：APScheduler比手写while循环更可控，支持持久化和错过任务的补偿；
• 数据存储：先上SQLite，等数据量大了再换PostgreSQL；
• 日志：每条请求都记录prompt_tokens、completion_tokens、total_tokens，这是成本审计的基础。

选型的核心原则是“先用最少的依赖跑通闭环，再逐步替换组件”。很多项目死在第一步就追求过度设计。

4. 角色人设与Prompt工程：让AI立住“军官”人设

4.1 角色设定本质是一套行为规则

很多初学者以为角色扮演就是写一句“你是一个德国军官”。这句话几乎等于没写，因为模型不知道“军官”具体该用多长的句子、什么语气、什么限制条件、如何拒绝无关话题。

真正有效的角色设定，是一套行为规则集，至少要包含：

• 身份：这个角色是什么，负责什么；
• 说话风格：句子长短、是否用敬语、是否用感叹号；
• 目标：每次回复要达成的监督效果；
• 边界：不输出什么，遇到无关问题怎么处理；
• 反馈策略：任务未完成时怎么说，完成了怎么说。

写成一条规则，模型执行起来要比一个模糊身份稳定得多。

4.2 系统提示词设计示例

这里给出一个可直接借鉴的系统提示词模板。注意：为了避免任何历史和政治话题，我把这个角色处理为“AI学习监督员”，只借鉴“军官”的严厉、高效、简洁特征，并不影射任何具体军队或人物。

# 文件路径：prompts.py SYSTEM_PROMPT = """你是一位代号“教官”的AI学习监督员，负责监督用户的学习进度。 你的整体风格是：严格、直接、高效、略带压迫感，但绝不使用侮辱和攻击性语言。 行为规则： 1. 语气简短有力，每次反馈控制在3句话以内，不闲聊、不扩展话题。 2. 发现任务未完成时，先指出差距，再给出一个可执行的下一步动作。 3. 用户完成阶段目标时，可以认可，但必须马上转到下一个任务。 4. 用户试图转移话题或闲聊时，用一句话拉回学习主题。 5. 禁止输出暴力、攻击、侮辱、威胁类内容；禁止讨论无关领域。 6. 要像一位严格但负责的指导者，目标是帮助用户完成任务，而不是羞辱用户。 示例： - 用户说：今天不想学了。 - 正确回应：可以不想，但任务不会消失。请告诉我，接下来30分钟你计划先完成哪一道题？ """

这段Prompt的核心不是“像军官”，而是把“军官”这个标签翻译成模型可以遵守的行为约束。实际项目里会发现，模型最容易出错的地方是两句话之后开始说教，所以要反复强调句子长度和话题边界。

4.3 防止角色崩坏的三个办法

• 第一条：降低temperature。一般角色扮演类应用建议temperature设为0.5到0.7。太高会让模型自由发挥，角色语气飘忽；太低会让回复变得机械。
• 第二条：控制历史消息质量。不要让用户闲聊内容占据太多上下文。如果用户连续闲聊，AI用固定规则拒绝后，可以把这一轮从记忆里清理掉，避免污染后续角色状态。
• 第三条：定期做“角色复位”。在上下文开头重复系统提示词，或者每隔N轮插入一条“reminder”消息，内容为“始终按照系统提示词中的教官风格回复”。这能显著缓解角色漂移。

5. 环境准备与最小实现

5.1 环境准备

本文给出的是一个最小可运行的示例，真实项目中可以替换成任意大模型接口。建议使用Python 3.10以上版本，先建虚拟环境。

python -m venv venv source venv/bin/activate pip install openai edge-tts apscheduler python-dotenv tiktoken

说明：

• openai：用于调用大模型API，也兼容绝大多数OpenAI格式的接口；
• edge-tts：微软在线TTS，免费且中文语音自然；
• apscheduler：任务调度；
• python-dotenv：读取环境变量；
• tiktoken：本地快速估算token数量（不同模型tokenizer不完全一样，但作为预估足够）。

5.2 核心代码：调用大模型生成军官式反馈

创建一个config.py，把密钥和参数集中在环境变量里，避免把密钥写死在代码中。

# 文件路径：config.py import os LLM_BASE_URL = os.getenv("LLM_BASE_URL", "https://your-endpoint/v1") LLM_API_KEY = os.getenv("LLM_API_KEY", "your-api-key") LLM_MODEL = os.getenv("LLM_MODEL", "your-model") TTS_ENGINE = os.getenv("TTS_ENGINE", "edge-tts") TTS_VOICE = os.getenv("TTS_VOICE", "zh-CN-YunjianNeural") # 巡查间隔，单位：秒。默认30分钟。 CHECK_INTERVAL_SECONDS = int(os.getenv("CHECK_INTERVAL_SECONDS", "1800"))

然后写一个officer_agent.py，把系统提示词、调用历史和token用量统一封装。

# 文件路径：officer_agent.py from openai import OpenAI from config import LLM_API_KEY, LLM_BASE_URL, LLM_MODEL from prompts import SYSTEM_PROMPT def build_client() -> OpenAI: """创建模型客户端，兼容OpenAI格式的接口。""" return OpenAI(base_url=LLM_BASE_URL, api_key=LLM_API_KEY) def ask_officer( message: str, history: list, client: OpenAI, ) -> dict: """将当前状态发送给大模型，返回军官反馈和token用量。""" messages = [ {"role": "system", "content": SYSTEM_PROMPT}, *history, {"role": "user", "content": message}, ] resp = client.chat.completions.create( model=LLM_MODEL, messages=messages, temperature=0.6, ) content = resp.choices[0].message.content # 每次请求都记录usage，这是后面做成本分析的关键数据 usage = { "prompt_tokens": resp.usage.prompt_tokens, "completion_tokens": resp.usage.completion_tokens, "total_tokens": resp.usage.total_tokens, } return { "content": content, "usage": usage, "messages": messages, }

这一段代码的核心是三点：把SYSTEM_PROMPT固定放在每轮对话最前面；把history作为可变上下文；把usage字段完整返回。很多成本失控的问题，都是因为没记录usage，导致月底看到账单才知道烧了多少。

5.3 加入语音播报

只用文字反馈，“军官”的压迫感会弱很多。加一个语音播报，让反馈从屏幕上“跳”出来。

# 文件路径：speech.py import edge_tts import asyncio import os async def speak(text: str, voice: str, output_file: str = "speak.mp3") -> None: """把文本合成为语音，并调用系统播放器播放。""" communicate = edge_tts.Communicate(text, voice) await communicate.save(output_file) # 播放部分需要根据操作系统调整 # macOS: afplay / Linux: aplay | mpv / Windows: start os.system(f"start {output_file}" if os.name == "nt" else f"afplay {output_file}")

如果网络环境不允许调用在线TTS，也可以用本地TTS方案，或者把文本先放入消息队列，由独立语音服务消费，避免阻塞主流程。

5.4 加入定时巡查

最后用主程序把状态采集、模型调用、语音播报串起来。

# 文件路径：main.py import asyncio import json from datetime import datetime from apscheduler.schedulers.asyncio import AsyncIOScheduler from config import CHECK_INTERVAL_SECONDS, TTS_VOICE from officer_agent import build_client, ask_officer from speech import speak def check_todo() -> str: """从待办系统、番茄钟或日历中获取当前学习状态。 最小示例直接返回一条构造的状态文本，真实项目应该对接真实数据源。 """ return "今日目标：完成算法题3道。当前完成：0道。距离截止还有2小时。" async def run_once() -> None: client = build_client() status = check_todo() # 实际项目中，这里应该把最近几轮对话作为history传入 result = ask_officer(status, [], client) print(f"[{datetime.now():%Y-%m-%d %H:%M:%S}] 状态: {status}") print(f"[军官反馈] {result['content']}") print(f"[token用量] {json.dumps(result['usage'], ensure_ascii=False)}") await speak(result["content"], TTS_VOICE) def main() -> None: scheduler = AsyncIOScheduler() scheduler.add_job(run_once, "interval", seconds=CHECK_INTERVAL_SECONDS) scheduler.start() print(f"AI监督员已启动，每 {CHECK_INTERVAL_SECONDS} 秒巡查一次。") try: asyncio.get_event_loop().run_forever() except (KeyboardInterrupt, SystemExit): print("监督员退出。") if __name__ == "__main__": main()

这里用了APScheduler而不是写死while循环，好处是后续可以方便地增加“只在8点到22点巡查”“错过任务后补偿执行”这类调度策略。第一次跑通时，把CHECK_INTERVAL_SECONDS设成10，可以快速看到效果，确认后再改回30分钟。

6. 运行验证与效果检查

6.1 启动命令和预期输出

设置好环境变量后运行：

export LLM_BASE_URL="你的接口地址" export LLM_API_KEY="你的密钥" export LLM_MODEL="你的模型名" export CHECK_INTERVAL_SECONDS=10 python main.py

预期输出类似：

AI监督员已启动，每 10 秒巡查一次。 [2025-05-20 10:00:00] 状态: 今日目标：完成算法题3道。当前完成：0道。距离截止还有2小时。 [军官反馈] 任务还剩2小时，当前进度是0。请立刻坐到桌前，先完成第一道题，再向我汇报。 [token用量] {"prompt_tokens": 1280, "completion_tokens": 42, "total_tokens": 1322}

看到三行输出，说明链路已经跑通：状态采集 → 大模型反馈 → 语音播报 → token用量记录。

6.2 如何判断人设没有崩

跑通流程之后，下一步就是做“角色一致性”验证。建议准备十组不同输入，覆盖以下场景：

• 用户说“不想学了”；
• 用户说“已经学完了”；
• 用户问“今天天气怎么样”；
• 用户说“这个算法好难，放弃吧”；
• 用户连续闲聊五轮。

观察AI的回复是否保持“严厉、简短、拉到学习主题”的风格。如果开始出现长篇说教、卖萌、或者被闲聊带偏，就说明Prompt约束还不够，需要回到第4节增强行为规则。

6.3 怎么实时观察token消耗

在最小实现里，每条反馈都打印了usage。更规范的做法是写入日志文件：

# 文件路径：logger.py import json from datetime import datetime def log_usage(usage: dict, content: str) -> None: with open("usage.log", "a", encoding="utf-8") as f: f.write(json.dumps({ "time": datetime.now().isoformat(), "usage": usage, "content": content[:30], }, ensure_ascii=False) + "\n")

之后定期看usage.log，按天汇总。如果某个时间段token消耗突然变高，优先检查历史消息是否无限增长、系统提示词是否过长、是否有多余的视觉输入。

7. 常见问题与排查思路

这里真正容易踩坑的是第一行：很多开发者前期用测试数据看不出问题，一旦正式使用，history持续累积，prompt_tokens会指数级增长。最好在项目第一天就把上下文上限设计好，而不是等出账单再改。

8. 工程化建议：从比赛作品到可持续运行的应用

8.1 控制上下文长度是第一个生死线

对监督类AI应用来说，上下文管理比模型选型更重要。推荐的策略组合：

• 滑动窗口：只保留最近N轮对话，超过的部分丢弃；
• 定期摘要：每天结束时，把当天对话总结成一段压缩文本，第二天作为“长期记忆”注入系统提示词；
• 向量记忆：把历史反馈、用户常见问题存入向量数据库，按相关性检索，而不是全量塞进提示词；
• 结构化状态优先：学习进度、完成数量、剩余时间这类信息不要依赖大模型记忆，直接通过函数从外部数据源读取，拼接到最新一条user消息里。

如果做到这些，同样一天50轮对话，token消耗可能只有全量历史的十分之一。

8.2 用混合模型策略降低长期成本

一个很常见的成本误区是“所有请求都用同一个最强模型”。实际项目中，模型能力应该按任务分配：

• 高频固定话术（如“再玩手机就重做十道题”）走本地模板，不调API；
• 状态判断（如“当前进度是否落后”）用性能较弱但便宜的模型；
• 只有在生成复杂反馈、需要高情商或高角色一致性时，才调用最强模型。

这样整体成本可以显著下降，同时核心体验不降级。对于“70亿token”这种量级的产品，混合策略几乎是必须的。

8.3 安全边界与数据隐私

使用摄像头、屏幕截图等视觉能力时，必须注意边界：

• 明确告知用户哪些数据会被采集、是否被保存；
• 数据采集范围尽量缩小，只提取必要信息，不保存无关画面；
• AI反馈永远不要鼓励用户做损害健康、违反法律的事情；
• 不要把“严厉”设计成“羞辱”，角色监督的高压要有底线，本质是帮助用户成长。

8.4 观察指标与日志

建议长期记录四个指标：

• 每日token总量与成本；
• 每条请求的输入输出token比例；
• 用户从收到反馈到开始下一轮任务的时间间隔；
• 角色漂移事件数（可让人工抽样标注）。

有了这些指标，你才能判断“AI监督员”到底是在提高用户产出，还是在制造无效噪音。如果用户完成率没有变化，说明问题不是模型不够凶，而是任务拆解或反馈时机出了问题。

9. 总结与下一步实践

回到最初的问题：70亿token是不是一个大数字？取决于你从什么角度看。对一次演示来说，它是巨大的成本；对一个持续运行几个月、每天高频交互的AI Agent来说，它是真实使用量积累的结果。这类项目让我最受启发的不是“烧了多少token”，而是它把大模型应用从“问答工具”推向了“有角色、有记忆、有主动行为”的AI Agent形态。

如果你也想复现类似项目，我建议按三步走：

• 第一步，把本文的最小示例跑通，先用一条固定状态文本验证大模型反馈和语音播报；
• 第二步，接上真实数据源，比如待办清单或番茄钟，让AI监督的内容变成你真正要做的任务；
• 第三步，加入历史摘要、token用量日志和混合成本策略，让它能连续跑一周以上。

等你跑完这三步，你会比大多数人更清楚“token”这个热词背后的真实含义：它既是成本，也是产品设计的度量衡。下一次看到某个AI项目晒出惊人的token消耗时，你就可以用今天这套框架去判断，它到底是噱头，还是真的把AI用到了实处。