【共创季稿事节】物的第二人生：HarmonyOS 6.1 AI 物品流转地图全场景实战

一台闲置相机、一摞带着笔记的教材、一个仍然能正常工作的蓝牙音箱，常常在搬家、毕业或换新后被放进抽屉。它们不是垃圾，却因为缺少合适的下一站，逐渐退出生活。本文基于 second-life-demo，记录我如何用 HarmonyOS 6.1、ArkTS、ArkUI 与 AI 路线分析，完成一款“物的第二人生”应用：让用户看见物品剩余价值、附近循环网络、出售/捐赠/改造路线与可解释的环境影响。

文章重点讨论手机、平板、2in1/PC 如何承接同一份物品流转任务；如何用类型模型稳定 UI；如何设计地图、路线与 AI 的边界；以及从原型走向真实视觉识别、位置服务和循环网络时应补齐哪些工程能力。

图 1：首页不把闲置物品理解为“待处理清单”，而把它们呈现为等待被重新连接的资源。

---

一、问题不是“怎么卖掉”，而是“下一站在哪里”

多数闲置平台只解决交易：拍照、标价、聊天、发货。但并不是每件物品都适合出售。一本标满知识笔记的教材，可能更适合进入校园图书角；一台有使用痕迹的胶片相机，也许更适合给摄影新手；一只故障不严重的音箱，可以先进入维修工坊，再进入新的生活场景。

因此，“物的第二人生”没有把目标定义为做一个二手交易平台，而是回答一个更完整的问题：

这件物品现在处于什么状态？
        ↓
它还拥有什么可使用、可修复、可传递的价值？
        ↓
出售、捐赠、改造中，哪条路径更适合？
        ↓
附近有哪些真实的循环节点能承接它？
        ↓
怎样用最少操作完成一次有意义的流转？

这也是 AI 在此类应用中的恰当位置。AI 不应该替用户做价值判断，更不应凭一张照片断言物品的真实价格或安全性；它更适合归纳用户提供的物品状态，给出多条可解释路线，提示需要人工确认的事项，并把“处理闲置”转化为一个可以行动的流转任务。

项目设置三个页面：

页面	解决的问题	核心信息
物品	我有哪些等待新故事的物品	物品状态、估价区间、已避免碳排、快捷入口
流转	它能去哪里	旅程地图、附近循环网络、三条路线、时间线
AI 工作室	应该怎样选择	物品识别、状态分析、价值区间、路线建议

它们不是三个独立功能，而是同一条链路的三段：看见物品、理解去向、形成行动。

---

二、全场景设计：同一件物品在不同设备上的任务不同

HarmonyOS 的一多开发不应从“我要支持哪些屏幕”开始，而应从“用户在不同设备上会做什么”开始。物品流转就是很典型的全场景任务。

2.1 手机端：发现、拍摄与确认

手机永远是物品身边的设备。用户整理抽屉、搬家打包或走到社区捐赠点时，需要的是：拍一张照片、录入物品状态、快速确认路线、查看附近节点。因此手机端应该优先：

• 显示当前物品和最少必要状态；
• 让用户在一屏内看到出售、捐赠、改造的候选路线；
• 提供清晰的“开始 AI 路线分析”入口；
• 在地图上显示距离、需求和预估价值；
• 保持低干扰，避免把大量统计和长文本压到第一屏。

图 2：手机端的任务是快速决定下一步，而不是同时管理所有循环记录。

2.2 平板端：比较与批量整理

平板更适合整理一批物品。例如在毕业搬宿舍、家庭换季或工作室清仓时，用户可以一边看物品列表，一边比较路线和影响力。中屏可采用双列：左侧为待流转物品，右侧为当前物品的地图、路线卡和说明；或者左侧按品类筛选，右侧显示 AI 分析结果。

平板端的价值是“对比”。用户不只是处理某一件物品，而是能够判断：哪些适合捐赠，哪些值得出售，哪些先送去维修，哪些需要安全回收。

2.3 PC / 2in1：管理循环网络与长期影响

电脑端更适合长时间的管理工作：导入大量物品、编辑详情、建立社区/校园循环点、查看月度碳减排、处理交接记录、审核 AI 生成的路线。理想的宽屏工作台可设计为：

左：物品库、分类、筛选、批量选择
中：流转地图、当前路线、节点详情
右：AI 分析、交接事项、影响力与历史记录

这样，手机负责“发现一件物品”，平板负责“比较一组物品”，PC 负责“组织一个循环系统”。三端共享的是 ItemRecord、路线选择和交接状态；不同的是信息密度与操作方式。

工程模块已声明：

"deviceTypes": ["phone", "tablet", "2in1"]

真正的一多适配不在这行配置，而在于后续布局是否让同一状态在不同容器中得到恰当表达。

---

三、领域建模：把“物品”从一张图片变成可流转的数据

当前原型使用 ItemRecord 描述物品：

interface ItemRecord {
  icon: string;
  name: string;
  type: string;
  condition: string;
  value: string;
  color: string;
  route: string;
}

它足以支持原型中的卡片、地图和 AI 工作室：

const ITEMS: ItemRecord[] = [
  { icon: '◉', name: '旧胶片相机', type: '数码 / 收藏',
    condition: '轻微使用痕迹', value: '¥ 320 - 480',
    color: '#E8A65B', route: '转赠给摄影新手' },
  { icon: '▣', name: '毕业季教材', type: '书籍 / 知识',
    condition: '8 成新，含笔记', value: '¥ 40 - 60',
    color: '#B287F4', route: '捐赠给校园图书角' }
];

但若要进入真实业务，这份模型需要更严谨。首先，value 不应是混合文本，而应拆成数值区间和货币；其次，物品状态要区分外观、功能、完整度与安全风险；再次，路线不是一段字符串，而应有明确状态机。一个可演进模型可写为：

type ItemCondition = 'excellent' | 'good' | 'repairable' | 'recycleOnly';
type TransferType = 'sell' | 'donate' | 'repair' | 'upcycle' | 'recycle';
type TransferStage = 'draft' | 'analysing' | 'listed' | 'matched' | 'handover' | 'completed';

interface ItemValue {
  min: number;
  max: number;
  currency: 'CNY';
  confidence: number;
}

interface CircularItem {
  id: string;
  name: string;
  category: string;
  condition: ItemCondition;
  images: string[];
  value?: ItemValue;
  selectedRoute?: TransferType;
  stage: TransferStage;
  createdAt: number;
}

为什么要这样拆？因为“建议卖 ¥420”不是永久事实，而是一个带来源、时间和置信度的估算；“轻微使用痕迹”不能自动说明电器安全；“等待交接”也不等于完成流转。类型模型越接近业务事实，AI、地图、统计和多端 UI 才越不容易互相误解。

---

四、ArkUI 状态管理：选择一件物品，三页同步变化

原型中最重要的状态是：

@State currentTab: number = 0;
@State selectedItem: number = 0;
@State selectedRoute: number = 0;
@State aiLoading: boolean = false;
@State aiVisible: boolean = false;
@State totalCarbon: number = 12.8;

这几个值对应真实用户动作：当前处在哪个任务阶段、正在处理哪件物品、选了哪条路线、AI 是否在分析、建议是否可见、循环影响力是否更新。

当用户在物品列表点击一张卡时：

.onClick(() => {
  this.selectedItem = index;
  this.currentTab = 1;
})

地图页和 AI 页不会各自保存一份物品信息，而是通过统一方法读取：

private currentItem(): ItemRecord {
  return ITEMS[this.selectedItem];
}

因此，地图中的物品图标、AI 工作室的标题、价值区间和最终建议都能随着 selectedItem 同步更新。这个模式看似简单，却是未来平板双列和 PC 三栏布局的基础：不同页面、不同设备不需要复制业务状态，只需要订阅同一个选中项。

4.1 为什么不能直接修改一段文案

声明式 UI 的价值在于把“事实”与“显示”分开。比如路线选择：

.onClick(() => {
  this.selectedRoute = index;
  promptAction.showToast({ message: '已选择：' + route.title, duration: 1100 });
})

路线卡的边框、已选择 标签和时间线下一步内容都由 selectedRoute 推导。如果未来需要在 PC 端同时更新地图路径、交接清单和碳影响预估，只要状态变化，所有视图都可以重新计算，而不是在每个点击事件里手动找控件改文本。

---

五、首页设计：用“影响力”代替处理压力

闲置管理类产品很容易把用户推向焦虑：“你还有 24 件物品未处理”“请立即清理”。第二人生选择了另一种表达：展示“12.8 kg CO₂e 已避免”“3 件物品延寿”“8 个新故事连接”。

首页的 EarthHero 使用 Stack 叠放星点、核心数字和标签：

Stack({ alignContent: Alignment.Center }) {
  Text('✦').fontSize(165).fontColor('#2E5F3B')
  Text('✦').fontSize(102).fontColor('#406E49')
  Column() {
    Text('12.8').fontSize(50).fontWeight(FontWeight.Bold)
    Text('kg CO₂e 已避免')
  }
}

这不是严格的碳核算组件。真实碳影响必须基于物品类别、重量、替代购买概率、运输距离、维修成本和权威生命周期数据；原型中的数字仅用于验证“循环影响力”这一信息层级。文章必须明确区分 UI 原型数值和可用于环境声明的核算结果。

对用户体验而言，首页应让人先看见“这件物品还有价值”，再进入出售、捐赠或改造的操作。技术服务于这一叙事，而不是把物品变成冷冰冰的库存编号。

---

六、物品流转地图：地图不是装饰，而是承接行动的网络

流转页由三层组成：当前物品的旅程概览、附近循环网络地图、路线选择与时间线。

地图原型没有接真实地图 SDK，而用 Stack 构建一个可解释的本地循环网络。道路纹理、虚线连接和节点标签共同形成信息图：

this.MapPin('⌂', '我的位置', '#C7F69A', 24, 103)
this.MapPin('♧', '社区捐赠点', '#B287F4', 195, 28)
this.MapPin('◉', '循环市集', '#E8A65B', 211, 129)
this.MapPin('♻', '维修工坊', '#53D7C7', 103, 48)

并展示当前模拟数据：最近捐赠点 1.2 km、正在寻找该类物品 3 人、本地估价 ¥420。这三项数据对应三个真实决策维度：可达性、需求、价值。

距离回答：我是否能方便地完成交接？
需求回答：这件物品是否真有人需要？
估价回答：出售是否值得投入时间？

在真实应用中，这个页面需要接入位置权限、地图服务和可信节点数据。不能把静态地图上的“社区捐赠点”伪装成实时服务。正确的演进顺序是：先在原型中验证用户是否理解节点与路线，再接入受审核的公益组织、循环市集和维修商家数据。

---

七、三条路线：出售、捐赠与改造不该互相竞争

传统二手产品默认“出售”是唯一正确路线。但第二人生把三种路线并列：

• 循环出售：适合状态良好、存在市场需求的物品；
• 公益捐赠：适合教育、生活、社区场景可继续使用的物品；
• 创意改造：适合有修复价值或材料价值的物品。

路线卡由 RouteOption 描述：

interface RouteOption {
  icon: string;
  title: string;
  subtitle: string;
  impact: string;
  color: string;
}

impact 的存在很重要。用户不应只看到“出售可以得到多少钱”，还应看到“捐赠可以帮助谁”“改造能延长多久的使用寿命”。不过同样需要避免伪精确：未经实际评估的“延长 18 个月”只能是原型演示，不是承诺。真实服务可将影响显示为范围、估计依据和免责声明。

路线选择后，时间线会动态更新：

this.TimelineRow('下一步', this.routeTitle() + ' · 完成信息确认', false)

用户看到的不再是抽象建议，而是接下来的具体行动。把 AI 的结果落成流程，是“建议型应用”真正变得有用的关键。

---

八、AI 工作室：从照片理解到可执行路线，AI 应该做什么

AI 工作室是原型中的第三页。用户选中物品后，先看它的类别、状态和基础信息，再触发路线分析。

当前版本通过本地异步状态模拟分析过程：

图 7：分析过程需要可见的加载状态；用户知道系统正在做什么，才愿意等待并信任结果。

private GenerateAnalysis(): void {
  if (this.aiLoading) return;
  this.aiLoading = true;
  setTimeout(() => {
    this.aiLoading = false;
    this.aiVisible = true;
    this.totalCarbon += 0.8;
    promptAction.showToast({ message: 'AI 已为它规划新的旅程', duration: 1400 });
  }, 950);
}

这不是把本地规则冒充成大模型，而是先完成交互验证：按钮是否防重复点击、用户是否理解“分析中”、结果应该放在哪里、重新分析时如何覆盖旧建议。先解决这些产品问题，再接入模型，通常比“先接 API 再想 UI”更可靠。

图 8：结果页不是展示一段模型长文，而是把推荐路径和用户下一步操作组织为稳定信息模块。

真实 AI 分析可分为四个层次：

视觉/文本识别：识别类别、外观、配件、明显损伤
       ↓
规则校验：危险品、隐私设备、不可流转品、安全风险
       ↓
路线匹配：市场需求、公益需求、维修可行性、距离
       ↓
生成解释：以结构化 JSON 给出路线、理由和待确认事项

例如，AI 不应仅说“建议出售”，而应说明“功能完整、市场存在入门摄影需求、预计价值区间；请确认快门和电池仓状态”。这既有解释，也保留用户和专业人员的确认空间。

---

九、真实模型接入：结构化输出、服务端安全与本地降级

真实系统不能将模型 Key 写在 HarmonyOS 客户端。推荐架构为：

HarmonyOS App
    ↓ HTTPS
业务服务端
    ├─ 用户鉴权、限流与隐私脱敏
    ├─ 物品图片与文本预处理
    ├─ 调用视觉/语言模型
    ├─ 规则校验与路线筛选
    ├─ JSON Schema 校验
    └─ 返回受控结果

客户端请求：

{
  "item": {
    "name": "旧胶片相机",
    "category": "camera",
    "conditionNote": "轻微使用痕迹，功能待确认",
    "images": ["https://example.com/object.jpg"]
  },
  "location": {"city": "深圳", "district": "南山区"},
  "preferences": {"allowSell": true, "allowDonate": true}
}

服务端响应应是稳定契约：

{
  "summary": "物品具有继续使用价值，建议优先循环出售。",
  "condition": {"level": "good", "needsConfirmation": ["快门", "电池仓"]},
  "value": {"min": 320, "max": 480, "currency": "CNY", "confidence": 0.62},
  "routes": [
    {"type": "sell", "score": 0.82, "reason": "摄影入门需求稳定", "nextAction": "补拍功能演示"},
    {"type": "donate", "score": 0.65, "reason": "可进入校园摄影社", "nextAction": "联系捐赠点"}
  ],
  "safetyNotice": "估价仅供参考，电池与存储介质请先自行处理。"
}

端侧再把 JSON 映射成 RouteOption、地图节点和行动清单。模型输出不是可信事实：可能缺字段、返回 Markdown、超时或产生不合理建议。因此服务端必须做 Schema 校验，端侧也必须有默认值、错误页和本地规则降级。若模型不可用，应用仍可以基于物品类别、状态和用户偏好给出“优先捐赠/维修/回收”的基础路径。

---

十、手机、平板、PC 的布局实现策略

当前工程以手机三栏交互为主，并为 phone、tablet、2in1 声明了支持。真正的全场景演进应复用领域状态，不复用固定 UI。

10.1 手机：单列，快速完成一件事

手机端以 Scroll + BottomBar 组织页面。根部通过 Stack 将底栏置于内容上层：

Stack({ alignContent: Alignment.Bottom }) {
  if (this.currentTab === 0) {
    this.HomeContent()
  } else if (this.currentTab === 1) {
    this.MapContent()
  } else {
    this.AiContent()
  }
  this.BottomBar()
}

每个内容页预留 bottom: 105，避免 78px 高的固定导航遮挡最后一项。这个空隙不是视觉浪费，而是移动端叠层布局的安全区。

10.2 平板：双列，比较物品与路线

中屏可设计为左侧物品库、右侧流转详情：

左：物品分类、缩略图、状态、批量选择
右：地图、路线比较、预计价值、交接事项

用户点击左侧卡片只更新 selectedItem；右侧所有内容根据 currentItem() 刷新。这样单列手机与双列平板共享同一业务状态。

10.3 PC/2in1：三栏，管理完整循环流程

宽屏可进一步拆为：

左：物品库与筛选
中：地图、附近节点、路线和时间线
右：AI 分析、图片检查、交接记录、影响力统计

PC 不应只把手机卡片放大。它的优势是同时展示“我有什么”“它能去哪”“我接下来做什么”，减少在列表、地图和聊天建议之间反复切换。

建议按窗口宽度划分等级：窄屏单列、中屏双列、宽屏三栏。实际阈值可根据内容调整；真正重要的是：改变容器结构而不是盲目压缩字体或拉宽卡片。

---

十一、沉浸式窗口与系统栏：全屏不等于隐藏一切

应用使用深色生态视觉。若系统状态栏和导航栏保持默认浅色，页面会出现明显“白边”。但直接隐藏系统栏在模拟器和不同设备上可能造成手势区域异常。因此工程采用更稳妥的策略：内容延展到窗口，保留系统栏，并设置相同的深色背景。

mainWindow.setWindowLayoutFullScreen(true);
mainWindow.setWindowSystemBarEnable(['status', 'navigation']);
mainWindow.setWindowSystemBarProperties({
  statusBarColor: '#07131F',
  navigationBarColor: '#07131F',
  statusBarContentColor: '#FFFFFF',
  navigationBarContentColor: '#FFFFFF'
});

这里有三个层级：窗口是否沉浸、系统栏是否可用、内容是否避开固定导航。它们不能混为一谈。升级 HarmonyOS 6.1 或适配不同设备时，需要分别验证状态栏文字对比度、底部手势区、横向窗口、分屏模式和滚动末尾可达性。

---

十二、构建、诊断与原型验证

构建命令：

cd second-life-demo
unset NODE_OPTIONS
export DEVECO_SDK_HOME="/Applications/DevEco-Studio.app/Contents/sdk"
export JAVA_HOME="/Applications/DevEco-Studio.app/Contents/jbr/Contents/Home"

/Applications/DevEco-Studio.app/Contents/tools/node/bin/node \
  /Applications/DevEco-Studio.app/Contents/tools/hvigor/bin/hvigorw.js \
  --mode module -p module=entry@default -p product=default \
  -p requiredDeviceType=phone assembleHap

HAP 输出：

second-life-demo/entry/build/default/outputs/default/entry-default-unsigned.hap

开发中有一个典型 ArkTS 约束：@Builder 内不适合随意声明局部业务对象并依赖它做响应式渲染。初版地图构建器中使用 const item = ITEMS[this.selectedItem]，构建器语法与响应式表达会带来限制。修正方式是将读取收敛为方法：

private currentItem(): ItemRecord {
  return ITEMS[this.selectedItem];
}

再在构建器中调用 this.currentItem()。这不是机械规避语法，而是让“当前物品”有唯一来源，后续无论换成 Store、网络数据还是跨设备状态，都能集中修改。

验证不应只看应用能打开，至少包括：

• 选中不同物品后，地图和 AI 工作室是否同步；
• 点击路线后，卡片高亮和时间线是否更新；
• AI 分析中是否禁止重复点击；
• 分析完成后，建议、价值和影响力是否合理变化；
• 长页面滚到底部时是否被导航遮挡；
• 系统栏是否与页面背景连续；
• 平板/2in1 窗口下是否仍有可扩展的布局边界。

---

十三、隐私、安全与循环伦理：比 UI 更重要的边界

物品流转涉及图片、位置、交易价值和用户联系方式。AI 与地图能力越强，越需要克制。

第一，照片可能包含住址、快递单、证件、屏幕内容或人脸。上传前应提供裁剪、模糊和风险提示；服务端应最小化保存，明确删除策略。

第二，位置不应默认精确公开。用户可先选择城市或区域，只有决定交接后再按需授权精确地点；捐赠点和维修点应来自可信来源，并有审核、营业状态和联系人验证。

第三，AI 估价是辅助信息，不能被表述为市场保证。不同城市、成色、配件、季节和交易渠道都会影响价格。应用应展示区间、置信度和依据，并允许用户修改。

第四，电器、电池、存储介质和危险品存在安全与隐私风险。系统应优先提示清除数据、检查电池、分类回收，而不是一味推荐继续流转。

第五，公益捐赠必须尊重受赠方需求。不是所有旧物都适合捐赠；“捐出去”不应成为把处理成本转移给他人的借口。AI 应推荐真正被需要的物品、清洁标准和交接方式。

---

十四、后续演进：从视觉原型到真实循环网络

当前版本完成了物品、地图、路线与 AI 交互闭环。下一步可按以下顺序演进。

14.1 Preferences 持久化

保存物品库、选中路线、AI 分析记录、影响力统计和用户偏好。不要持久化每次 UI 动画或临时 loading 状态，只保存能被用户恢复的业务事实。

14.2 视觉 AI 与表单校验

接入端侧或云侧视觉能力识别类别、品牌、配件与表面损伤，但必须让用户确认识别结果。图片识别是候选输入，不应覆盖用户对物品真实状态的描述。

14.3 地图与可信节点

引入地图 SDK、Location Kit 或受控位置服务，展示校园图书角、公益组织、维修点、循环市集。节点信息需要可验证、可举报、可更新，不能仅依赖 AI 生成。

14.4 分布式协同

手机用于拍摄与确认；平板用于整理多个物品；PC 用于管理社区/家庭物品库和批量路线。跨设备同步的应是物品状态、分析结果和交接计划，不是完整页面截图。

14.5 影响力核算

与权威生命周期数据库或循环机构建立依据，明确不同类别物品的估算边界。页面可展示“估算减少”而非绝对碳减排，并让用户看到计算来源。

---

结语：循环的不是物品，而是价值

“物的第二人生”并不试图告诉用户所有旧物都值得留下，也不把出售当成唯一正确答案。它想做的是让用户在丢弃之前，多看见一次价值：可能是下一位使用者的需要，可能是社区共享的知识，也可能是一次维修和改造后继续工作的机会。

对 HarmonyOS 开发而言，这个项目也展示了一条完整的实践线：用 ArkTS 建模物品和路线，用 ArkUI 管理选中状态和三页交互，用地图让循环网络可视化，用 AI 把复杂判断转成可解释建议，再根据手机、平板、PC 的设备角色安排不同的信息密度。

真正高级的应用，不只是页面华丽或模型回答流畅，而是知道哪些事实应该由用户确认，哪些建议需要保留不确定性，哪些数据必须被保护，哪些体验应在正确设备上发生。让物品继续流转，也让技术回到它最应该服务的地方：帮助人做出更有意义、更可持续的选择。