企业官网建设流程全解析

在策略游戏里，最让人纠结的往往不是“打不过”，而是“点错了一下科技”。资源本来就紧张，研究路线一旦偏了，前期发育节奏会被拖慢一大截。像《无尽冬日》这类冰雪生存题材游戏，科技研究系统直接关系到采集效率、建筑速度、部队强度和资源产出，可以说是整个成长体系里最难拍板的部分。

网上攻略通常只给一张静态优先级表，比如“先升采集，再升建筑，然后军事”。但每个人手里的英雄不同、资源存量不同、所在服务器阶段也不同，照搬攻略很容易出问题。更务实的做法，是把科技树数据、当前资源和玩家目标交给AI来推理，生成一份个性化的研究建议。

本文要讲的，就是如何基于清源AI搭建一个“无尽冬日科技研究助手”。这不是外挂，也不涉及自动操作游戏，而是一个标准的AI决策辅助应用。读完这篇文章，你可以掌握：把游戏数据结构化、挂载到AI知识库、设计提示词、编排Agent工作流，最后通过API把整个能力接入自己的页面或小程序。即使你完全没接触过Agent开发，也能从零跑通。

1. 这篇文章真正要解决的问题

先说判断：清源AI这类平台真正降低的，不是“写代码”的难度，而是“把真实数据接入AI”的难度。过去做一个个性化的游戏攻略助手，你需要自己写规则引擎、写决策树、维护大量if-else；现在只需要把数据整理好，让大模型基于约束条件做推理，开发成本下降了一个量级。

但这里有一个关键误区：很多人以为把AI接进来，就是让它“凭记忆回答问题”。实际上，如果模型不了解《无尽冬日》当前版本的科技树数据，它会一本正经地编出一堆不存在的科技名称。所以，真正决定助手质量的是三件事：数据准备是否结构化、提示词是否约束了推理边界、Agent流程是否能跟踪上下文。

这篇文章适合三类读者：

• 想用AI做一个游戏攻略/数据分析应用的个人开发者；
• 正在学习Agent智能体开发，需要完整项目练手的人；
• 负责游戏社区工具、玩家支持类应用的团队，想评估用清源AI做“知识库问答 + 决策推荐”的工作量。

读完你会得到：一个可运行的“无尽冬日科技研究助手”原型，一套可复用到其他攻略场景的架构思路，以及一份避坑清单。

2. 科技研究系统的痛点与AI切入点

《无尽冬日》的科技研究系统，从公开攻略可以看到大致分为几个方向：生存发展类、资源采集类、军事战斗类、城防辅助类。每个方向里又有多个独立科技项目，每一项都有等级上限、前置条件、资源消耗和升级时长。

这里真正让玩家头疼的，不是“不知道有哪些科技”，而是“资源有限，先升级哪一项”。比如游戏前期，木材和食物都很紧张，升级采集科技可以提升后续收益，但战斗科技又能减少战损。到底选哪个？静态攻略只能告诉你“通常情况下怎么选”，无法回答“以你目前3万木材、2万食物、20张加速卡的状态，先点哪个收益最高”这种具体问题。

这就是AI最适合介入的地方。

从技术角度看，科技研究推荐本质上是一个“约束条件下的多目标决策”问题：

• 硬约束：前置科技是否满足、资源是否足够、研究队列是否空闲；
• 软目标：短期资源收益、中期发展速度、长期战斗能力；
• 状态输入：当前等级、资源存量、加速卡数量、个人玩法偏好。

传统做法是写一套决策树，把所有情况铺开。但游戏版本一更新，数值一变，整个规则就要重写。而用大模型做这件事，改动成本低很多——你只需要更新知识库里的数据表，提示词里的规则逻辑几乎不用动。

所以这个项目的架构思路是：用结构化数据保证准确，用清源AI的推理能力做决策，用Agent工作流维持多轮分析，最终通过API对外提供服务。下面我会一步步拆解。

3. 清源AI平台的核心概念

在写代码之前，先厘清三个基础概念。理解了这三个词，后面读代码会轻松很多。

3.1 Agent（智能体）

Agent不是“一个机器人”，而是一套“有目标、有工具、有上下文的AI执行流程”。在清源AI平台上，Agent可以理解为：你给大模型设定一个角色和目标，告诉它可以调用哪些工具，然后它在多轮对话中自主完成拆解和执行。

放在这个项目里，Agent的任务是：根据玩家输入，分析当前科技研究的最优顺序。

3.2 知识库

知识库的作用是给模型提供“它不知道”的事实数据。大模型的训练数据里可能知道《无尽冬日》这个游戏，但不可能知道当前版本每一项科技的具体数值、前置条件和消耗公式。知识库就是把这些数据以文档或表格形式存放，模型在回答时优先检索知识库内容，而不是凭空编造。

3.3 工作流

工作流是把一个复杂任务拆成多个步骤，每个步骤对应一次模型调用或一次工具操作。比如：

1. 接收玩家输入；
2. 检索知识库，获取科技树数据；
3. 调用资源计算工具，算出当前可升级的科技；
4. 让模型基于规则推荐优先级；
5. 返回结果。

用一句话概括这三者的关系：知识库是素材库，Agent是执行者，工作流是执行流程的SOP。

4. 环境准备与前置条件

整个项目以“最小可运行”为目标，不依赖任何重型框架。你只需要准备以下几项。

4.1 清源AI平台账号

你需要一个清源AI开发者平台的账号。这个在官网注册即可。登录后，创建一个“智能体”项目，获取API访问密钥。不同平台的密钥获取入口可能不同，一般在“控制台—API密钥管理”里。

请注意：密钥是敏感信息，不要提交到Git仓库，也不要在前端页面直接暴露。本文后面所有调用都会通过后端服务完成。

4.2 本地开发环境

本文的示例代码使用Python编写，建议使用Python 3.9以上版本。你还需要安装两个依赖库：requests用于调用API，FastAPI用于把助手封装成HTTP接口。如果本地没有Python环境，可以安装Miniconda或直接使用系统Python。

pip install requests fastapi uvicorn

版本不写死，以你实际安装到的最新稳定版为准。本文重点演示的是通用实现思路，API版本兼容性以清源AI官方文档为准。

4.3 项目目录结构

建议提前把项目结构搭好，后面写代码时不会乱：

frozen-tech-assistant/ ├── data/ │ └── tech_tree.json ├── scripts/ │ └── build_kb.py ├── app/ │ ├── assistant.py │ ├── prompt.py │ └── main.py ├── requirements.txt └── README.md

5. 数据准备：把科技树结构化为知识库

这是整个项目里最“枯燥”、但又最不能省的一步。数据质量直接决定AI回答的可信度。

5.1 为什么不能直接让AI自己写数据

很多人图省事，直接把问题抛给大模型：“《无尽冬日》科技树有哪些？帮我整理成JSON。”结果往往是看起来像模像样，实际上错误百出。因为大模型是在“回忆”训练数据中的游戏信息，一旦版本更新或数据稀疏，它就会用“合理的幻觉”填补空白。

正确的做法是：把玩家社区、官方Wiki、游戏内截图等渠道的数据整理成结构化文件，再交给AI。AI只负责基于这份数据做分析，不负责“编造”数据。

5.2 科技树JSON结构设计

以两条科技为例，展示数据格式。实际使用中，你可以把完整科技树按照这个格式扩充。

// 文件路径：data/tech_tree.json { "version": "2024.12", "techs": [ { "id": "survival_hunting_01", "name": "狩猎效率", "branch": "生存发展", "max_level": 10, "cost_base": { "food": 1000, "wood": 800 }, "cost_growth_rate": 1.18, "level_effect": "每级提升采集与狩猎资源产出5%", "prerequisites": [], "build_time_minutes_base": 30 }, { "id": "military_attack_01", "name": "远征攻击", "branch": "军事战斗", "max_level": 10, "cost_base": { "food": 3000, "wood": 2500, "iron": 1000 }, "cost_growth_rate": 1.25, "level_effect": "每级提升外出部队攻击力3%", "prerequisites": ["survival_hunting_03"], "build_time_minutes_base": 120 } ] }

字段解释：

• id：唯一标识，用于程序内关联；
• branch：科技所属分支；
• cost_base：1级时的基础消耗；
• cost_growth_rate：每升一级，资源消耗的增长率；
• level_effect：每级效果的文本描述，也是AI推荐时的依据；
• prerequisites：前置科技ID列表；
• build_time_minutes_base：1级时的基础建造时长，可类推。

5.3 数据校验脚本

数据文件写好后，写一个简单脚本校验字段完整性，避免在AI阶段才发现字段缺失。

# 文件路径：scripts/build_kb.py import json from pathlib import Path def validate_tech_tree(data_path: str) -> None: with open(data_path, "r", encoding="utf-8") as f: data = json.load(f) techs = data.get("techs", []) ids = set() required_fields = {"id", "name", "branch", "max_level", "cost_base", "cost_growth_rate", "level_effect", "prerequisites"} for tech in techs: missing = required_fields - set(tech.keys()) if missing: raise ValueError(f"科技 {tech.get('name', 'unknown')} 缺少字段: {missing}") if tech["id"] in ids: raise ValueError(f"重复的科技ID: {tech['id']}") ids.add(tech["id"]) for pre in tech["prerequisites"]: if pre not in ids and pre != "": raise ValueError(f"科技 {tech['id']} 的前置 {pre} 不存在") print(f"校验通过，共 {len(techs)} 项科技。") if __name__ == "__main__": validate_tech_tree("data/tech_tree.json")

运行：

python scripts/build_kb.py

这一步输出的意义在于：如果后续AI推荐结果异常，你可以先怀疑数据，再怀疑提示词。

6. 设计Agent提示词与决策逻辑

数据就绪后，下一步是编写Agent的提示词。提示词决定了模型“怎么用数据”。

6.1 提示词模板设计

在清源AI平台里，每个Agent都需要设置System Prompt。下面这套提示词直接复制到Agent设置里即可，也可以按需修改。

# 角色 你是《无尽冬日》科技研究助手，熟悉该游戏科技树数据、资源消耗机制和常见升级策略。 # 任务 根据玩家当前状态与目标，推荐1-3个最值得立即研究的科技项目。 # 输入信息 - 当前资源存量 - 已有科技等级 - 玩法偏好（发展型/战斗型/均衡型） - 可加速时长 # 决策规则 1. 只推荐科技树数据中出现过的科技，不得编造。 2. 前置科技未满级时，优先推荐前置科技。 3. 资源不足时，给出缺口计算，不要直接让玩家“攒资源”。 4. 结合玩家偏好，给每条推荐注明理由。 5. 输出格式为：科技名称、当前等级、目标等级、所需资源、预计耗时、推荐理由。 # 输出示例 【推荐升级】狩猎效率 - 当前等级：3 - 目标等级：4 - 所需资源：食物 1640、木材 1312 - 预计耗时：约 46 分钟 - 推荐理由：你的资源采集收入偏低，狩猎效率升级后可以提升采集产出，为后续军事科技积累资源。

这段提示词的核心在于“约束”：先限定角色，再限定任务，然后用固定规则约束推理边界，最后给出输出格式示例。大模型对“格式示例”的敏感度很高，建议保留。

6.2 为什么推荐结果必须可解释

游戏攻略类AI最容易犯的毛病是只给结论、不给过程。但玩家拿到一个结果后，如果不知道“为什么”，根本不敢信。所以提示词里专门加了“推荐理由”和“缺口计算”两个约束。可解释性不仅提升用户信任，也方便开发者在测试阶段定位问题——是数据错了、规则错了，还是模型理解偏了。

7. 完整示例代码实现

现在进入核心环节：把Agent能力封装成可复用的服务。

7.1 调用清源AI的Python客户端

这里以通用HTTP调用方式演示。不同平台的请求路径和鉴权方式会有差异，实际接入时请以清源AI开发者平台提供的API文档为准，整个流程保持一致。

# 文件路径：app/assistant.py import json import time import requests from typing import Dict, Optional class QingYuanAssistant: def __init__(self, api_key: str, agent_id: str, api_base: str): self.api_key = api_key self.agent_id = agent_id self.api_base = api_base self.cache: Dict[str, tuple] = {} def _request(self, user_message: str, timeout: int = 60) -> str: """ 调用清源AI Agent接口。 实际请求地址、请求头、参数结构请参考清源AI最新API文档。 """ url = f"{self.api_base}/v1/agent/completions" headers = { "Authorization": f"Bearer {self.api_key}", "Content-Type": "application/json" } payload = { "agent_id": self.agent_id, "messages": [ {"role": "user", "content": user_message} ], "temperature": 0.3 } resp = requests.post(url, headers=headers, json=payload, timeout=timeout) resp.raise_for_status() result = resp.json() # 这里根据清源AI实际返回结构做适配 return result["data"]["content"] def recommend(self, player_state: Dict, force_refresh: bool = False) -> str: """ 根据玩家状态生成科技研究推荐。 相同输入在缓存有效期内直接返回，减少API调用次数。 """ cache_key = json.dumps(player_state, ensure_ascii=False, sort_keys=True) if not force_refresh and cache_key in self.cache: content, expire_ts = self.cache[cache_key] if time.time() < expire_ts: print("命中缓存。") return content prompt = ( "请根据以下玩家当前状态，输出科技研究建议：\n" f"玩家状态：{json.dumps(player_state, ensure_ascii=False)}\n" "请严格按照提示词中的输出格式回答。" ) content = self._request(prompt) self.cache[cache_key] = (content, time.time() + 300) return content

这段代码做了三件事：

• 封装了HTTP请求逻辑；
• 加了简单的5分钟缓存，避免相同输入重复扣费；
• 留出了api_base和agent_id配置项，方便切换环境。

温度参数设为0.3，是为了让模型在“推荐”这种偏决策的任务上更稳定，少一点创造性。

7.2 用FastAPI暴露HTTP接口

命令行脚本只能自己用，要分享给社区或者嵌入网页，需要一个HTTP接口。这里用FastAPI写一个最简服务。

# 文件路径：app/main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field from typing import Dict, Optional from app.assistant import QingYuanAssistant app = FastAPI(title="无尽冬日科技研究助手") # 在实际项目中，api_key和agent_id应从环境变量读取 assistant = QingYuanAssistant( api_key="your_api_key_here", agent_id="your_agent_id_here", api_base="https://api.qingyuan.example.com" ) class RecommendRequest(BaseModel): resources: Dict[str, int] = Field( ..., example={"food": 50000, "wood": 40000, "iron": 10000} ) current_tech_levels: Dict[str, int] = Field( ..., example={"survival_hunting_01": 3, "military_attack_01": 0} ) play_style: str = Field("均衡型", example="发展型") accelerate_minutes: int = Field(0, example=30) @app.post("/api/recommend") def recommend(req: RecommendRequest): if req.play_style not in {"发展型", "战斗型", "均衡型"}: raise HTTPException(status_code=400, detail="play_style 取值不合法") player_state = { "resources": req.resources, "current_tech_levels": req.current_tech_levels, "play_style": req.play_style, "accelerate_minutes": req.accelerate_minutes } try: result = assistant.recommend(player_state) return {"code": 0, "data": {"recommendation": result}} except Exception as e: raise HTTPException(status_code=502, detail=f"AI服务调用失败: {e}") @app.get("/health") def health(): return {"status": "ok"}

启动服务：

uvicorn app.main:app --host 0.0.0.0 --port 8000

启动后，接口文档可直接访问：http://localhost:8000/docs。

7.3 请求示例

用curl模拟一次请求：

curl -X POST "http://localhost:8000/api/recommend" \ -H "Content-Type: application/json" \ -d '{ "resources": {"food": 50000, "wood": 40000, "iron": 10000}, "current_tech_levels": {"survival_hunting_01": 3, "military_attack_01": 0}, "play_style": "发展型", "accelerate_minutes": 30 }'

请求的含义是：玩家有5万食物、4万木材、1万铁，狩猎效率已经3级，远征攻击还没学，偏好发展玩法，手里有30分钟加速。

8. 运行结果与效果验证

如果你正确接入了清源AI并配置了Agent，上面这个请求会返回类似下面的结果：

{ "code": 0, "data": { "recommendation": "【推荐升级】狩猎效率\n- 当前等级：3\n- 目标等级：4\n- 所需资源：食物 1640、木材 1312\n- 预计耗时：约 46 分钟\n- 推荐理由：当前资源储备充足，发展型玩家应优先提升基础资源产出。狩猎效率升级后可提升采集效率，为后续军事科技积累资源。" } }

判断是否成功，按以下顺序检查：

1. 接口是否返回code: 0；
2. 返回内容中是否使用了你提供的科技树数据；
3. 资源缺口计算是否和JSON里的cost_base和cost_growth_rate对得上；
4. 推荐理由是否结合了play_style。

如果结果异常，先查请求日志，再查数据文件，最后再怀疑模型本身。大概率是前置依赖没配置好，或者JSON里字段名和提示词里不一致。

9. 常见问题与排查思路

游戏数据版本的更新是一个高频问题。每次游戏版本大更新，都要同步修订tech_tree.json。建议在建表时增加version字段，并在推荐结果里注明“数据版本”，这样玩家发现问题时可以及时反馈。

10. 最佳实践与工程建议

项目原型跑通容易，做成一个能长期维护的工具，还需要注意下面几个工程问题。

10.1 数据与代码分离

把科技树数据放在data/目录，代码只负责读取和推理。后续更新数值时，不必改动一行Python代码，只需要更新JSON文件，然后重新校验即可。如果数据更新频繁，可以考虑把JSON放到对象存储或数据库里，由后台管理系统维护。

10.2 把幻觉当常态来防御

不管模型表现多好，都要假设它可能在某个边角情况下输出错误内容。在生产环境，可以在返回结果前增加一层规则校验：用Python解析推荐结果，检查科技名称是否存在于JSON数据中、资源数字是否在合理范围。这层“兜底校验”非常值得写。

10.3 缓存与成本控制

AI接口是按调用量计费的。相同的玩家状态反复请求是很大的浪费。建议至少做两层缓存：

• 应用内TTL缓存，5-10分钟即可；
• 对同一个玩家ID做更长时间的本地缓存，除非玩家显式点击“刷新”。

在assistant.py里已经给出了一个简单实现，生产环境建议换成Redis。

10.4 安全与合规边界

这个助手本质是“游戏攻略工具”，不是“外挂”。不要在项目里加入自动点击、读取游戏内存、模拟鼠标键盘等能力。这既违反游戏用户协议，也可能带来法律风险。在写README时，要明确说明工具的定位：信息参考与决策辅助，不进行任何游戏内自动操作。

另外，API密钥必须存放在后端环境变量中。示例代码里的your_api_key_here只是占位，实际部署时建议用.env文件或密钥管理服务。

10.5 提示词的可维护性

把提示词从代码中抽离出来，独立成一个文件，比如app/prompt.py或prompts/assistant.txt。后续调整推荐规则，只需要改提示词文件，不需要改动Python逻辑。对于非程序员出身的运营同学，这能省下大量的沟通成本。

10.6 预留评估集

在项目早期就准备10-20条“标准提问”，比如“资源充足、发展型”“资源紧缺、战斗型”“前置科技不满足”等场景。每次修改数据或提示词后，跑一遍评估集，肉眼检查输出质量。没有评估集，你就无法判断“改好了”还是“改坏了”。

11. 总结与后续学习方向

这篇文章的价值不在于“用AI做一个推荐接口”这个动作本身，而在于把一套可复用的Agent开发方法讲清楚了：数据先结构化，提示词约束推理边界，Agent承载执行流程，API暴露服务能力。这套方法不仅适用于《无尽冬日》科技研究，也适用于其他游戏的阵容推荐、装备搭配、资源规划等场景，甚至可以从游戏延伸到任意垂直领域的“知识库问答 + 决策建议”应用。

下一步你可以做三件事：

1. 把tech_tree.json扩展成完整的科技树数据，覆盖更多科技项目和版本变化；
2. 在FastAPI服务里接入一个简单的Web页面，让玩家可以勾选当前状态、获取推荐结果；
3. 深入了解清源AI平台的高级能力，比如知识库自动更新、工作流编排、模型参数调优，把助手从“能用”打磨成“好用”。

最后提醒一句：游戏攻略工具的生命周期很短，版本更新一次，你可能就要维护一次。但Agent开发方法论的生命周期很长。把数据层和推理层分开，把提示词外部化，把评估集沉淀下来，你的工具就能在版本变更中活得更久。