【无标题】当修仙遇上AI：HarmonyOS NEXT 打造「AI修仙功法」—— ArkTS 主题化开发实战

b66666661dd

206人浏览 · 2026-06-22 11:16:10

b66666661dd · 2026-06-22 11:16:10 发布

当修仙遇上AI：HarmonyOS NEXT 打造「AI修仙功法」—— ArkTS 主题化开发实战

一、引言：为什么要做「AI修仙功法」

1.1 修仙文化与现代生活的碰撞

近年来，修仙、修真、玄幻文化在年轻人中持续火爆。从网络小说到影视动漫，从游戏到短视频，"修仙"已经从一个文学题材演化成一种流行文化符号——人们用"渡劫"形容困难，用"飞升"描述成功，用"道心"指代初心。

与此同时，AI 聊天应用在 HarmonyOS NEXT 生态中正蓬勃发展。我们思考：能否将修仙文化的浪漫想象与 AI 助手的实用功能相结合？于是，「AI修仙功法」应运而生。

1.2 项目定位

「AI修仙功法」不是简单的修仙知识问答库，而是一个用修仙智慧解答现实问题的疗愈型 AI 助手。它的核心理念是：

将每个生活问题映射到一个修仙概念上，用修仙的视角重新审视，再回归到现实可操作的解决方案。

比如：

现实问题	修仙视角	解决方案
工作遇到瓶颈	修炼遇屏障，需突破境界	分析瓶颈根源 → 制定突破计划 → 坚持每日功课
总是分心走神	心念不纯，功法难入定	修炼专注功法 → 番茄工作法即为「入定法」
跟同事闹矛盾	道心受扰，需锤炼心性	理解对方立场 → 冷静沟通 → 此为「道心历练」
身体疲惫	肉身亏空，需淬体调理	规律作息为「筑基」 → 运动为「炼体」 → 饮食为「药膳」

这种类比不仅有趣，还能帮助用户从新的角度理解问题，减轻心理压力。

1.3 与之前版本的区别

本次项目是在「AI万能手册」（通用生活助手）的基础上，做了一次全面的主题化改造。同一套技术架构，同一套 AI 接口，但系统提示词和 UI 风格完全不同，这恰好展示了 ArkTS 开发的灵活性和可复用性。

二、项目架构与技术选型

2.1 整体架构

项目沿用了经典的两层分离架构：

entry/src/main/ets/pages/
├── AIChatService.ets    # AI 通信服务层（312 行）
└── Index.ets            # 修仙主题聊天界面（250 行）

2.2 技术栈

技术栈	选型	说明
语言	ArkTS（HarmonyOS NEXT）	鸿蒙原生声明式 UI 语言
构建	hvigor 6.26.1	官方构建系统
网络	`@kit.NetworkKit`	原生 HTTP 能力
AI 模型	DeepSeek-V3（API）	中文理解力强
传输协议	SSE（Server-Sent Events）	流式逐 token 输出
SDK 版本	API 24（Compatible 24.0.0）	广兼容

2.3 数据流

用户输入 → Index.ets（UI层）
         → queryAI() 调用
         → AIChatService.ets 构建请求体（含 SYSTEM_PROMPT）
         → POST https://api-ai.gitcode.com/v1/chat/completions
         → DeepSeek-V3 流式返回 SSE 数据
         → onData 回调逐 token 更新 UI
         → 用户看到修仙尊者实时"口述"回答

三、核心改动详解

3.1 系统提示词：修仙尊者的"人设"塑造

系统提示词（System Prompt）是 AI 角色的灵魂。本次改动最核心的部分就是重新设计提示词，让 AI 化身为一位修炼千年的「修仙功法尊者」。

3.1.1 角色设定

const SYSTEM_PROMPT: string =
  '你是一位修炼千年的「修仙功法尊者」，通晓天地至理、人情世故。' +
  '你擅长用修仙功法、修真境界、灵性修炼的比喻来解答用户在生活、工作、学习、' +
  '情感、健康、成长等方面遇到的实际问题，将高深的修仙智慧化为通俗易懂的人生道理。';

角色的设定有三个层次：

身份：修炼千年的尊者（权威感 + 岁月沉淀）
能力：通晓天地至理、人情世故（既懂大道也懂人情）
方法论：用修仙比喻解答现实问题（核心价值）

3.1.2 五条原则

'1. 修仙隐喻：将每个生活问题与修仙概念对应 — 工作瓶颈是「修炼瓶颈」，学习是「功法领悟」，' +
'人际关系是「道心锤炼」，健康是「肉身淬炼」，情绪困扰是「心魔作祟」。\n' +
'2. 深入浅出：先给出「功法口诀」（核心结论），再展开「修炼详解」（具体步骤）。\n' +
'3. 因人而异：根据问题的性质调整语气 — 情感问题温柔点化，技术问题如传功法秘诀。\n' +
'4. 寓意深刻：每次回答末尾可赠一句「修行箴言」，让用户感悟回味。\n' +
'5. 注意边界：不提供医疗诊断、法律意见等专业资质结论，提醒用户「寻访世俗名医」。\n\n' +
'请用中文回复，语气如德高望重的仙尊在指点后辈弟子，亲切而不失庄重。';

每条原则都有明确的修仙映射：

原则 1 定义了世界观映射规则——确保回答始终在修仙框架内
原则 2 规定了回答结构——口诀 + 详解
原则 3 实现了语气适配——不同问题不同态度
原则 4 增加了情感价值——箴言让用户回味
原则 5 划定了安全边界——用修仙语言包装专业建议的免责

3.1.3 对比：两版提示词的设计差异

维度	AI万能手册	AI修仙功法
身份	热心生活助手	修炼千年的仙尊
语气	亲切、有条理	庄重又不失亲切
隐喻	无（直接回答）	全修仙映射
结构	先结论后细节	口诀 + 详解 + 箴言
情感收尾	鼓励或提醒	修行箴言
安全边界	咨询专业人士	寻访世俗名医

可以看出，主题化改造不是简单的找几个修仙词汇替换，而是从语气、结构、价值观到安全边界都做了系统性的修仙化重构。

3.2 界面改造：从科技蓝到古韵金

界面的主题化同样重要。我们将原先的蓝色科技风 UI 全面改造为金色古风。

3.2.1 色彩体系

// 原版（AI万能手册）—— 现代科技风
backgroundColor('#007AFF')      // 蓝色主题
.backgroundColor('#F5F5F5')     // 浅灰背景
.fontColor(Color.White)         // 白色文字

// 修仙版（AI修仙功法）—— 古韵金风
.backgroundColor('#4A2800')     // 深棕标题栏
.backgroundColor('#8B6914')     // 金色用户气泡 / 按钮
.backgroundColor('#F5F0E8')     // 古纸色背景
.backgroundColor('#FFF8E1')     // 米色 AI 气泡
.fontColor('#2C1810')           // 深褐文字
.fontColor('#FFF8E1')           // 标题栏浅金文字

色彩心理学角度：

深棕 #4A2800 → 沉稳、古老、有厚度
金色 #8B6914 → 尊贵、仙气、力量感
古纸色 #F5F0E8 → 古卷、竹简、书卷气

3.2.2 文本风格的修仙化

元素	原版	修仙版
标题	AI 万能手册	☯ AI 修仙功法
AI 名字	AI万能手册	修仙功法尊者
发送按钮	发送	问道
占位符	输入你的问题…	说出你的困惑，本尊为你指点…
错误文案	抱歉，遇到问题	道友勿忧，本尊修行遇阻
快速按钮	✨	📜

发送按钮名称从"发送"改为"问道"，是一个小而关键的变化。"发送"是功能性的操作指令，“问道"则是一次有仪式感的求教行为——用户不是在发消息，而是在"问道求法”。

3.2.3 快速问题的修仙化改造

// 原版
const quickQuestions = [
  '如何提高工作效率？',
  '怎样改善睡眠质量？',
  '和同事发生矛盾怎么办？',
];

// 修仙版
const quickQuestions = [
  '工作遇到瓶颈，如何突破修炼境界？',
  '总是分心走神，如何修炼专注功法？',
  '和同门（同事）有矛盾，如何锤炼道心？',
  '身体疲惫不堪，有何淬体之法？',
];

每个问题都保留了现实核心，但用修仙语言重新包装。用户选择这些问题时，已经在潜意识中完成了"现实问题 → 修仙视角"的转换，更容易进入 AI 设定的角色语境。

3.3 欢迎消息与错误处理的角色感

3.3.1 欢迎消息

用户第一次进入应用，看到的不再是机械的问候，而是一段有角色感的开场白：

☯️ 有缘人，你来了。

吾乃修仙功法尊者，修行千载，通晓天地至理。

凡尘之事，无论工作瓶颈、学业困顿、情感纠葛、身心烦忧，
皆可用修仙之道点化解惑。

有何疑问，但说无妨，本尊为你指点迷津。

3.3.2 错误消息

当网络请求失败时，错误信息也做了角色化封装——不是冷冰冰的技术报错，而是符合仙尊语气的回应：

🙏 道友勿忧，本尊修行遇阻，待稍作调息再为你解答。

灵机受阻：<具体错误信息>

请稍后再试，或检查灵脉（网络）是否畅通。

“灵机受阻"替代"请求失败”，“灵脉"替代"网络”——这些小细节共同构建了沉浸式的修仙体验。

3.4 AI 流式输出的即时反馈

在流式输出场景中，每收到一个 token，就用 splice 更新消息列表。ArkTS 的响应式系统会重新渲染对应的 MessageBubble 子组件，用户看到的就是修仙尊者在逐字"口述"回答：

onData: (text: string) => {
  this.currentAIContent += text;
  this.messages.splice(aiMsgIndex, 1, {
    role: 'assistant',
    content: this.currentAIContent,
  });
  setTimeout(() => this.scroller.scrollEdge(Edge.End), 50);
},

配合 LoadingProgress 旋转指示器（金色 #D4A017），整体加载体验与主题保持一致。

四、ArkTS 主题化开发的关键技术

4.1 Prop 与状态管理

MessageBubble 子组件使用 @Prop 接收数据，实现单向数据流：

@Component
struct MessageBubble {
  @Prop message: MessageItem;  // 父组件驱动更新
  // ...
}

为什么不用 @Link？因为在 ForEach 循环中迭代的元素是值副本而非引用，@Link 无法建立双向绑定。而 @Prop 在这个场景中完全够用——子组件只需要展示消息，不会反向修改数据。

4.2 数组响应式更新的正确姿势

这是一个容易踩坑的点。ArkTS 中，以下写法不会触发 UI 更新：

// ❌ 不会触发重渲染
this.messages[aiMsgIndex] = newMsg;

正确的做法是使用数组的结构变化方法：

// ✅ 触发重渲染
this.messages.splice(aiMsgIndex, 1, newMsg);
// 或者
this.messages = [...this.messages];  // 替换整个数组引用

splice、push、pop 这些方法会触发 ArkTS 响应式系统的变更检测。

4.3 constraintSize 替代 maxWidth

ArkTS 中 Column 组件没有 maxWidth 属性，需要使用通用约束方法：

// ❌ 编译错误
.maxWidth('80%')

// ✅ 正确写法
.constraintSize({ maxWidth: '80%' })

constraintSize 支持 minWidth、maxWidth、minHeight、maxHeight 四个维度的约束。

4.4 对象字面量的类型标注

ArkTS 的类型检查比 TypeScript 更严格，对象字面量必须有明确的类型对应：

// ❌ 编译错误：Object literal must correspond to some explicitly declared class or interface
this.messages.map(msg => ({ role: msg.role, content: msg.content }));

// ✅ 正确写法
this.messages.map(msg => ({
  role: msg.role, content: msg.content
}) as ChatMessage);

五、构建与验证

5.1 构建命令

hvigorw --no-daemon -p product=default assembleHap

5.2 构建结果

BUILD SUCCESSFUL in 8 s 390 ms

阶段	耗时	状态
CompileArkTS	2.86s	✅ 0 error
CompileResource	249ms	✅
PackageHap	310ms	✅
总计	8.39s	SUCCESS

5.3 兼容性

API 24 编译通过 ✅
ArkTS 语法全部合规 ✅
@kit.NetworkKit 网络请求正常 ✅
声明式 UI 组件树正确 ✅

5.4 构建警告

WARN: 'on' has been deprecated.          → AIChatService.ets:234
WARN: ohos.permission.INTERNET           → 标准网络权限提示
WARN: No signingConfigs configured       → 签名配置可选

全部为无害警告，不影响应用运行。