【共创季稿事节】物的第二人生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描述物品interfaceItemRecord{icon:string;name:string;type:string;condition:string;value:string;color:string;route:string;}它足以支持原型中的卡片、地图和 AI 工作室constITEMS:ItemRecord[][{icon:◉,name:旧胶片相机,type:数码 / 收藏,condition:轻微使用痕迹,value:¥ 320 - 480,color:#E8A65B,route:转赠给摄影新手},{icon:▣,name:毕业季教材,type:书籍 / 知识,condition:8 成新含笔记,value:¥ 40 - 60,color:#B287F4,route:捐赠给校园图书角}];但若要进入真实业务这份模型需要更严谨。首先value不应是混合文本而应拆成数值区间和货币其次物品状态要区分外观、功能、完整度与安全风险再次路线不是一段字符串而应有明确状态机。一个可演进模型可写为typeItemConditionexcellent|good|repairable|recycleOnly;typeTransferTypesell|donate|repair|upcycle|recycle;typeTransferStagedraft|analysing|listed|matched|handover|completed;interfaceItemValue{min:number;max:number;currency:CNY;confidence:number;}interfaceCircularItem{id:string;name:string;category:string;condition:ItemCondition;images:string[];value?:ItemValue;selectedRoute?:TransferType;stage:TransferStage;createdAt:number;}为什么要这样拆因为“建议卖 ¥420”不是永久事实而是一个带来源、时间和置信度的估算“轻微使用痕迹”不能自动说明电器安全“等待交接”也不等于完成流转。类型模型越接近业务事实AI、地图、统计和多端 UI 才越不容易互相误解。四、ArkUI 状态管理选择一件物品三页同步变化原型中最重要的状态是StatecurrentTab:number0;StateselectedItem:number0;StateselectedRoute:number0;StateaiLoading:booleanfalse;StateaiVisible:booleanfalse;StatetotalCarbon:number12.8;这几个值对应真实用户动作当前处在哪个任务阶段、正在处理哪件物品、选了哪条路线、AI 是否在分析、建议是否可见、循环影响力是否更新。当用户在物品列表点击一张卡时.onClick((){this.selectedItemindex;this.currentTab1;})地图页和 AI 页不会各自保存一份物品信息而是通过统一方法读取privatecurrentItem():ItemRecord{returnITEMS[this.selectedItem];}因此地图中的物品图标、AI 工作室的标题、价值区间和最终建议都能随着selectedItem同步更新。这个模式看似简单却是未来平板双列和 PC 三栏布局的基础不同页面、不同设备不需要复制业务状态只需要订阅同一个选中项。4.1 为什么不能直接修改一段文案声明式 UI 的价值在于把“事实”与“显示”分开。比如路线选择.onClick((){this.selectedRouteindex;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描述interfaceRouteOption{icon:string;title:string;subtitle:string;impact:string;color:string;}impact的存在很重要。用户不应只看到“出售可以得到多少钱”还应看到“捐赠可以帮助谁”“改造能延长多久的使用寿命”。不过同样需要避免伪精确未经实际评估的“延长 18 个月”只能是原型演示不是承诺。真实服务可将影响显示为范围、估计依据和免责声明。路线选择后时间线会动态更新this.TimelineRow(下一步,this.routeTitle() · 完成信息确认,false)用户看到的不再是抽象建议而是接下来的具体行动。把 AI 的结果落成流程是“建议型应用”真正变得有用的关键。八、AI 工作室从照片理解到可执行路线AI 应该做什么AI 工作室是原型中的第三页。用户选中物品后先看它的类别、状态和基础信息再触发路线分析。当前版本通过本地异步状态模拟分析过程图 7分析过程需要可见的加载状态用户知道系统正在做什么才愿意等待并信任结果。privateGenerateAnalysis():void{if(this.aiLoading)return;this.aiLoadingtrue;setTimeout((){this.aiLoadingfalse;this.aiVisibletrue;this.totalCarbon0.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.currentTab0){this.HomeContent()}elseif(this.currentTab1){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 或适配不同设备时需要分别验证状态栏文字对比度、底部手势区、横向窗口、分屏模式和滚动末尾可达性。十二、构建、诊断与原型验证构建命令cdsecond-life-demounsetNODE_OPTIONSexportDEVECO_SDK_HOME/Applications/DevEco-Studio.app/Contents/sdkexportJAVA_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\--modemodule-pmoduleentrydefault-pproductdefault\-prequiredDeviceTypephone assembleHapHAP 输出second-life-demo/entry/build/default/outputs/default/entry-default-unsigned.hap开发中有一个典型 ArkTS 约束Builder内不适合随意声明局部业务对象并依赖它做响应式渲染。初版地图构建器中使用const item ITEMS[this.selectedItem]构建器语法与响应式表达会带来限制。修正方式是将读取收敛为方法privatecurrentItem():ItemRecord{returnITEMS[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 的设备角色安排不同的信息密度。真正高级的应用不只是页面华丽或模型回答流畅而是知道哪些事实应该由用户确认哪些建议需要保留不确定性哪些数据必须被保护哪些体验应在正确设备上发生。让物品继续流转也让技术回到它最应该服务的地方帮助人做出更有意义、更可持续的选择。