你有没有想过，一个汉字里能藏着多少秘密？

这就是我最近搭建的智能体：”迎春：一字测福”。

智能体的体验链接在文章最后。

nerror="javascript:errorimg.call(this);">

还有1个半月就是春节了。在这个时间节点，我开始思考一个问题：当打工人纷纷归巢，回到家乡与长辈、亲戚团聚时，用什么方式能够和家里的长辈、亲戚们互动升温呢？

这个场景的价值：

• 共同话题：测字是一个老少皆宜的话题，长辈熟悉传统文化，年轻人对AI感兴趣，可以一起讨论
• 互动性强：可以一家人围在一起，每个人测一个字，互相分享解读结果，增加互动和话题
• 文化传承：在互动中，长辈可以分享他们对传统文化的理解，年轻人可以了解测字文化的深度
• 轻松有趣：不需要严肃的讨论，只需要输入一个字，就能获得一份有趣的解读，让聚会更有意思

既然是”迎春”主题，节日氛围的营造就至关重要。我在产品设计中做了几个关键决策：

在用户输入之前，我先展示一张”一字测福”的节日氛围图。这不仅仅是视觉上的烘托，更有一个实用的考虑：

• 烘托节日氛围让用户一进入就能感受到浓浓的春节气息
• 规避等待时间大模型判断文字是否为单个汉字需要一定时间，展示图片可以让用户在等待过程中感受到产品的用心，而不是干巴巴的等待

在生成完字运解码报告和祝福诗后，我展示了一张珠光宝气的祝福图。这进一步强化了节日氛围，让整个体验在视觉和情感上都达到高潮。

目标用户：春节期间想要讨个好彩头的用户、对传统文化感兴趣的人、喜欢分享个性化内容的人

整体交互设计

工作流架构设计

工作流整体架构

输入节点（用户输入一个字） ↓ 输入验证节点（LLM） ↓ JSON解析节点（Python代码） ↓ 条件分支：有效 → 直接进入报告生成 | 无效 → 推荐字选择器 ↓ 拆解报告生成节点（LLM，直接输出Markdown）

nerror="javascript:errorimg.call(this);">

节点1：开始节点（用户输入/欢迎界面）

问候语（首次交互时显示）：

设计要点：

• 欢迎语必须是一个句子，不支持多行格式化（平台限制）
• 明确告诉用户要输入什么、会得到什么
• 提及“传统测字法”、“时辰节气”、“五大维度”，让用户感受到专业性
• 使用emoji增加节日氛围，但要适度

节点2：输入验证节点

功能：判断用户输入是否为一个字，如果不是，推荐合适的字供用户选择

user_input

输出变量：

(String): LLM输出的JSON字符串

输出格式（JSON）：

“is_valid”:true或false,

“context_data”:{

“recommended_chars”:[“如果is_valid为false，这里是推荐字数组；如果is_valid为true，这里是空数组”],

“recommended_chars_with_hints”:[

“char”:”推荐字1″,

“hint”:”推荐理由或寓意（简短，10-20字）”

]

}

节点2.1：输入验证JSON解析节点

功能：解析LLM输出的JSON，提取验证结果和推荐字

节点3：推荐字选择器节点

功能：让用户从推荐字中选择一个字

节点4：拆解报告生成节点

功能：针对一个字，从多个维度进行拆解，生成解码报告

validated_char

current_time

输出变量：

(String): LLM直接输出的Markdown格式的拆解报告

1.简洁喜庆：

• 每个部分严格控制字数，不要冗长
• 用词要充满年味，喜庆、正向、吉祥
• 避免复杂术语，用通俗易懂的语言

3.时间因素应用：

• 结合当前时间分析年份、月份、日期、节气、季节
• 是否在守岁时间（23：00-01：00）
• 是否在节日期间（春节、元宵、中秋等）
• 让解读更加精准和个性化

# 你的专属字运解码

你书写的字：**福** | 五行：**水** | 笔画：**13画**

—

#

[基于字的字形/谐音/五行等特点解读财运，一句话概括 + 一句话建议，共25-35字，要喜庆专业]

## 姻缘

[基于字的字形/谐音/五行等特点解读姻缘，一句话概括 + 一句话建议，共25-35字，要喜庆专业]

## 事业

[基于字的字形/谐音/五行等特点解读事业，一句话概括 + 一句话建议，共25-35字，要喜庆专业]

## 健康

#

## 福气

—

– [第一条建议，10-15字，结合当前时间]

– [第三条建议，10-15字，结合当前时间]

—

**{{卦象名称}}** → [一句话解释，要喜庆吉祥，15-25字]

> 愿此字运解码为您带来吉祥与好运！新年快乐！

技术实现细节

1. LLM节点的输出结构设计

为什么选择JSON格式：

结构设计的考虑：

2）user_message字段：字符串，直接展示给用户，包含友好的提示信息（如果输入无效）

这样的结构设计既满足了数据传递的需求，又保证了用户体验的友好性。

节点2（输入验证）：输出JSON格式字符串，需要节点2.1进行JSON解析

JSON解析节点的通用代码：

import re

input_str = params.get(‘llm_output’) or params.get(‘input’, ”)

return {}

input_str = re.sub(r’^“`json\s*’, ”, input_str, flags=re.MULTILINE)

input_str = input_str.strip

parsed_data = json.loads(input_str)

user_message = parsed_data.get(‘user_message’, ”)

‘context_data’: context_data,

‘user_message’: user_message

except json.JSONDecodeError:

return {}

3. 用户没有按要求输入一个文字的交互设计

输入验证逻辑：

推荐字生成策略：

推荐字选择器交互：

这样的交互设计既保证了输入要求的严格性，又通过友好的引导和智能推荐，让用户感受到产品的用心，而不是被冷冰冰的错误提示拒之门外。

每个LLM节点都有详细的提示词，包含：

节点4（拆解报告生成）的关键部分：

• 角色设定：专业的测字解签师
• 核心要求：简洁、喜庆、易读
• 五福维度解读：必须基于字本身的特点，不能泛泛而谈
• 时间因素应用：结合当前时辰、节气、季节等时间信息
• 输出格式：严格要求Markdown格式，提供完整模板

体验思考

1. 节日氛围的营造

视觉层面：

• 开场图片：烘托节日氛围，同时规避等待时间
• 结尾图片：进一步强化节日氛围，让体验在视觉和情感上都达到高潮
• 报告中的emoji使用：、、、、等，增加视觉吸引力

体验层面：

• 仪式感：通过单字输入、多维度拆解、卦象解读的完整流程，营造仪式感
• 期待感：输入阶段不做即时解读，保持神秘感和期待感
• 正向激励：所有解读都必须是吉祥、正向的，给用户带来心理慰藉

这个产品与春节场景高度契合：

社交契合：

• 春节期间，人们喜欢分享祝福和好运
• 生成的报告可以朋友圈，增强社交互动
• 个性化的解读让每个用户都感受到专属感

输入体验：

• 欢迎语要清晰明了，告诉用户要输入什么、会得到什么
• 如果输入无效，友好提示并推荐吉祥字，而不是冷冰冰的错误提示
• 推荐字选择器要清晰展示每个字的提示信息，帮助用户选择

输出体验：

• 报告要简洁、喜庆、易读，让用户轻松阅读
• 严格控制字数，避免冗长
• 结尾的祝福语，让用户感受到温暖和祝福

体验一个完整流程后，用户能够：

• 了解这个字在财运、姻缘、事业、健康、福气五大维度的运势解读
• 获得具体的开运建议（吉时、方位、宜行之事等）
• 了解年度卦象，获得整体运势预测
• 感受到传统文化的深度和春节的仪式感

为了让用户感受到正向激励，我在提示词中强调：

• 所有解读都必须是吉祥、正向的，不能有任何负面解读
• 即使输入”穷”、”病”等字，也要转化为吉祥含义，例如”穷”可以解为”穷则思变，蓄势待发”
• 用词要充满年味，喜庆、正向、吉祥，让用户感受到春节特有的氛围

为了让解读更精准、更个性化，我在提示词中强调：

• 结合当前时辰：分析当前时辰对运势的影响
• 结合当前节日：如果是春节、元宵等节日，自动加入节日元素和祝福
• 守岁时间特殊处理：23:00-01:00期间触发”守岁签”，运势加成

时间信息的获取使用了元器的系统参数SYS.CurrentTime，这个参数会在工作流执行时自动获取当前系统时间（格式：YYYY-MM-DD HH:mm:ss），并传递给拆解报告生成节点。在提示词中，我将这个时间信息作为上下文传递给LLM。

关于智能体平台

最关键的是，你可以把搭建好的智能体直接发布到小程序，不需要自己搞备案、买服务器，用户体验流畅，价值完全不同。

nerror="javascript:errorimg.call(this);">

这个智能体的核心价值不在于技术有多复杂，而在于它把”传统测字”这件事的门槛降低了，同时保持了传统文化的深度和仪式感。

如果你也想搭建类似的智能体，或者对技术实现细节感兴趣，欢迎交流。

https://yuanqi.tencent.com/webim/?sessionid=#/chat/ckmjis?appid=2006289267510340608&experience=true

题图来自Unsplash，基于CC0协议