惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Cyberwarzone
Cyberwarzone
F
Full Disclosure
V
Visual Studio Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
有赞技术团队
有赞技术团队
J
Java Code Geeks
博客园 - 【当耐特】
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 叶小钗
L
LINUX DO - 最新话题
T
Threatpost
S
SegmentFault 最新的问题
Vercel News
Vercel News
云风的 BLOG
云风的 BLOG
C
Cyber Attacks, Cyber Crime and Cyber Security
Google DeepMind News
Google DeepMind News
Know Your Adversary
Know Your Adversary
S
Schneier on Security
V
Vulnerabilities – Threatpost
D
DataBreaches.Net
G
GRAHAM CLULEY
Latest news
Latest news
P
Privacy International News Feed
D
Darknet – Hacking Tools, Hacker News & Cyber Security
C
CXSECURITY Database RSS Feed - CXSecurity.com
Scott Helme
Scott Helme
L
Lohrmann on Cybersecurity
T
The Exploit Database - CXSecurity.com
Security Latest
Security Latest
G
Google Developers Blog
L
LangChain Blog
MyScale Blog
MyScale Blog
Project Zero
Project Zero
N
News and Events Feed by Topic
Hacker News - Newest:
Hacker News - Newest: "LLM"
大猫的无限游戏
大猫的无限游戏
P
Proofpoint News Feed
Blog — PlanetScale
Blog — PlanetScale
阮一峰的网络日志
阮一峰的网络日志
N
News | PayPal Newsroom
www.infosecurity-magazine.com
www.infosecurity-magazine.com
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
SecWiki News
SecWiki News
T
Tor Project blog
C
Check Point Blog
Google Online Security Blog
Google Online Security Blog
GbyAI
GbyAI
The Last Watchdog
The Last Watchdog
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
WordPress大学
WordPress大学

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
出海分析:如何多维度分析企业级软件的国际化需求?
豆哥Chloe · 2023-08-09 · via 人人都是产品经理

现在,不少企业都有开拓海外市场的意向,而这一趋向对软件设计都提出了新的要求。那么,怎样才能设计出具有全球适应性的软件产品?这篇文章里,作者从多个维度发表了他的看法,一起来看看吧。

在当今数字化高速发展的时代,企业数字化转型已经成为一种必然趋势。随着企业拓展国际市场的意愿日益增长,国际化改革成为数字化转型中不可忽视的一环。作为数字化的载体,企业级软件在实现出海战略中扮演着关键角色。

这篇文章将从以下几个角度展开,讨论如何分析企业级软件的国际化需求:

  1. 多语言支持
  2. 时区和日期处理
  3. 币种与货币转换
  4. 单位和度量标准
  5. 数据安全与隐私合规
  6. 财税合规
  7. 市场情况与用户偏好
  8. 敏感因素考虑

开始分析之前

在开始分析之前,首先我们要了解,针对一个国际化产品,到底应该寻求怎样的切入点进行需求分析。和普通业务需求不一样,国际化需求往往是跨功能性的,它不直接服务于某一具体业务场景,但它又影响着此业务在运营和IT层面的设计和实施。

回到国际化需求分析的场景中来,到底如何开始分析呢?一般我们要从业务的视角,先确定以下两个关键点:

1)确定推广的区域范围

任何一个产品,出海的第一步都是需要明确次产品推广的区域包含哪些。因国际上不同国家的制度、文化、法律等都有着巨大的差异,所以想要一次性推广至“全球”其实是一个几乎不可能完成的任务。但产品的推广可以先由部分地区进行试点,再逐步拓展至其他区域。

2)了解海外业务现状、面临的挑战

一般企业级系统出海之前,业务都会先一步在海外试点的地区进行一轮调研、评估,或者更有可能是直接线下先进行一定规模范围内的经营行为,那么了解海外业务的现状、业务量、和面临的挑战,可以帮助我们更好的理解产品的价值,以及调整系统设计的重心。

最后,在悉知以上内容之后,便可以直接来到具体业务场景的分析了。

一、多语言支持

随着企业进军全球市场,软件界面和用户体验的本地化也能更好地适应不同文化背景的用户,提升用户满意度和产品竞争力,多语言问题显而易见成为第一个重要的障碍。

不同国家使用不同的语言这个问题很容易被注意到,因此在产品调研分析的过程中,不论是关键用户代表、PO、PM还是BA,都能非常容易地联想出页面和数据翻译的解决方案。

但对于企业级软件,其用户对象可能是多样的,可能是企业内部人员,也可能是当地市场的普通消费者,所以,多语言需要面临的远不仅是翻译的问题,对系统语言和用户语言进行分开管理和使用是至关重要的

那么,什么是系统语言,又什么是用户语言呢?在系统设计的时候,又该如何使用呢?

  • 系统语言:是指用户在使用系统时所看到的界面语言。
  • 用户语言:是指系统需要与用户进行直接或间接交流时所选择的语言,例如发送短信、邮件或打印工单等。

举一个实例,瑞士当地有4种官方语言,德语、法语、意大利语和罗曼什语,对于在德语区接受服务的消费者而言,企业给他们推送的内容,包含短信、邮件等,如果是意大利语或者罗曼什语,那他们很有可能无法阅读此类信息,从而降低了企业服务或推广的质量。

二、时区和日期处理

除开多语言,第二个能被业务人员及BA快速识别的国际化差异,应该就是时区及日期的处理问题了吧。全球各地存在多个时区和日期格式,软件产品应该能够根据用户所在地的时区和日期格式来显示时间和日期。此外,夏令时、冬令时、各地不同的节假日等特殊情况也应考虑在内,确保软件在不同时区和日期情况下可以正常运行。

对于绝大多数时区问题,我们推荐以下办法进行系统设计,则不管此国家是只有一个时区,还是多个时区,问题都很容易被解决。

使用UTC时间

  • 对于跨时区的应用和功能,建议在后台或底层处理过程中使用UTC时间作为统一的时间基准。
  • 在用户界面和用户交互方面,可以根据用户所在的时区进行时区转换,并以当地时区时间呈现给用户,以提供更符合用户习惯和期望的体验。

但有一些特殊的场景,特别是因为系统实现成本限制、或历史数据质量问题的影响,无法使用通用方案进行解决的话,仍然需要case by case 的进行设计和分析。但通常遇到时区的问题,都是产品现有的实现没有考虑到多时区的问题,导致存的为非零时区数据,系统的逻辑修改和数据清理会面临巨大的挑战,从而可能需要从业务的角度上共同思考解决方案。

三、币种和货币转换

软件产品应该能够支持不同国家和地区使用不同的货币,并具备货币转换的功能。系统可以根据业务所在地的货币单位来调整货币的显示和计算方式,方便用户进行交易和财务管理。

在这里,有以下三个比较典型的问题需要在需求分析时被考虑进去。

1. 币种和币种精度

  • 在系统设计中,应该考虑支持多种货币,并确保能够正确显示和处理各种币种符号、格式和精度。
  • 对于某些币种(如印尼盾),其货币单位不需要展示小数点后的数字。因此,在设计界面和数据显示时,需要根据币种的特点进行适当的处理和格式化,以满足不同地区的需求。

2. 汇率转换

  • 在涉及到货币转换的情况下,需要考虑汇率的转换计算。汇率可以通过外部数据源获取,如金融机构的汇率接口或实时汇率数据供应商。
  • 系统应该具备汇率管理功能,包括汇率的更新、历史记录和验证机制,以确保准确性和可靠性。

3. 区分零售货币、结算货币和出货货币

  • 需要明确区分什么场景下使用什么样的币种,因为不一定每一个业务都会明确的告诉你,不同的交易场景,使用的是不同的货币。零售货币是指用户在购买商品或服务时实际使用的货币;结算货币是指用于结算交易和核算的货币;出货货币是指货物出售时使用的货币。
  • 在系统设计中,应该清晰区分这些不同的货币,并根据业务需求和地区要求进行相应的处理和计算。
  • 对于跨国交易和跨货币结算的情况,需要确保正确计算汇率和货币转换,并提供清晰的结算明细和报表。

四、单位和度量标准

因文化、历史原因和习惯的不同,不同国家地区的人们习惯使用不同的单位和度量标准。因此,软件产品也应该能够支持不同的度量单位,例如,长度可以使用英寸或厘米,重量可以使用磅或千克等。

虽然此需求重要,但它不会像上面提到的多语言、时区、币种等需求那样一定要实现,否则无法开展正常的工作,但只有处理好单位和度量标准的转换,才能更好地实现产品的国际化处理。

五、数据安全与隐私合规

其实,数据安全与隐私合规的问题并不容易被“总部”的业务人员发现,如果在业务规划或者产品设计的阶段,没有法务人员的介入,相关隐患是很难被发现的。

国际化改革必须适应不同国家和地区的法律法规要求。各个国家和地区对于数据隐私、安全性、合规性等方面都有不同的规定和标准。合规性的功能设计、数据保护机制的优化以及遵循当地法律法规的规范操作,具体可以参考以下几点。

1. 最小化数据收集

  • 在设计和开发阶段,应该遵循最小化数据收集原则,只收集必要的个人信息,并确保明确的目的和合法基础来收集和处理数据。
  • 需要仔细评估每个数据收集点,确保只收集与所提供服务相关的必要信息,并避免过度收集个人数据。

2. 数据访问和保护

  • 设计系统时,应采取适当的安全措施来保护个人隐私数据,包括加密、访问控制、身份验证和审计等措施,以防止未经授权的访问和数据泄露。
  • 确保仅授权的人员可以访问敏感数据,并根据需要设置数据访问权限。

3. 隐私数据处理与存储期限

  • 确定隐私数据的存储期限,仅在必要的时间内保留数据,并在达到存储期限后安全地删除或匿名化数据。
  • 设计数据管理策略,包括数据保留政策和定期清理机制,以确保数据按照法律和合规要求进行处理和删除。

4. 数据跨境传输和合规要求

  • 根据不同地区和国家的数据保护法规,了解并遵守相应的数据跨境传输要求。
  • 对于欧盟、北美、东南亚、中国、印度等地区,了解各自的数据保护法规,并相应地采取措施,如签署适当的数据处理协议(如欧盟标准合同条款)或依据特定国家的法律要求进行数据局部化或数据分区存储。

5. 特殊数据的处理

IMEI和SN号几乎是所有电子硬件产品都有的唯一标识,甚至被很多法务人员称为“电子指纹”,但大部分业务人员,是无法意识到硬件设备的IMEI、SN号是被视为个人隐私数据的,从而在业务架构设计的时候经常将业务数据强关联到IMEI或者SN上,并允许海外业务对IMEI/SN进行跨境访问。

这样做有较大法律风险,因个人隐私数据在各地都被严格保护,要求不允许跨境、或仅允许特定条件下的出境。若把业务数据强关联至IMEI或者SN上,极有可能导致出海业务受阻。所以在做业务或是系统设计的时候,都应该考虑IMEI/SN在出海时的特殊性。

六、财税合规

和数据安全与隐私一样,财税的合法合规在系统实现上也尤为重要,一旦出现财税不合规的情况,可能会直接导致业务在当地的失败;但因为我个人并不熟悉财税相关领域的专业知识,只能从个人的项目经理浅薄的提一些能在系统设计层面考虑的问题。

1. 税务规定和要求

在系统进行计价的时候,税务逻辑应该如何合规,是需要当地财务人员给到输入的,如在印度,税收需要以物品的原价计税;货物的运输需要货票通行,否则将面临罚款。

2. 财务报告和合规性

  • 不同国家和地区有各自的财务报告要求和合规性要求。
  • 在需求分析中,需要确保软件产品能够生成符合目标市场要求的财务报告,包括资产负债表、利润表、现金流量表等,并满足相应的合规性标准。

3. 税收透明度和合规性监管

  • 全球范围内对税收透明度和合规性监管的要求越来越高,包括自动交换税收信息(AEOI)和国际税收合规要求等。
  • 在需求分析中,需要考虑软件产品对税收透明度和合规性监管的支持,确保数据的准确性、完整性和合规性。

4. 更新和调整机制

  • 税法和财税规定会随着时间变化而调整,因此软件产品需要具备更新和调整的机制,及时反映最新的税务和财税要求。
  • 在需求分析中,需要考虑软件产品的灵活性和可扩展性,以便根据变化的法规和要求进行相应的调整和更新。

七、市场情况与用户偏好

此外,国际化的产品设计还需要考虑不同国家和地区的市场习惯和偏好。企业级软件在设计和功能上应该具备灵活性,以满足不同地区的需求。例如,一些国家和地区可能更注重移动端应用,而另一些地区则更偏好桌面应用;再者,一些经济欠发达的地方,可能使用的硬件设备屏幕分辨率不够、或者性能不足等,导致无法支撑一些复杂功能的实现。

1. 移动端还是PC端

  • 根据目标市场的趋势和用户习惯,确定软件产品是以移动端还是PC端为主要平台。
  • 分析用户使用场景和需求,考虑是否需要开发移动应用程序或响应式网页设计,以满足用户在不同设备上的使用习惯和便利性。

2. 硬件设备性能

  • 针对目标市场的硬件设备特性,考虑软件在不同设备上的性能要求。
  • 考虑硬件设备的分辨率、屏幕尺寸、处理能力、电池寿命和通信情况等因素,以确保软件在各种设备上运行顺畅,并提供良好的用户体验。

3. 当地文化

  • 在设计软件界面、内容和功能时,考虑目标市场的文化背景和习惯。
  • 确保软件在用户界面的语言、图标、颜色、图像等方面符合当地文化和审美标准,以增强用户的亲切感和接受度。
  • 理解当地的社会礼仪和商业惯例,确保软件在功能和服务方面符合当地习俗和法规。

八、敏感因素考虑

在不同国家和地区开展业务时,敏感因素也都应该完全被考虑进去,纵使这很大程度上是业务运营人员需要考虑的战略问题,但是企业的数字化变革是需要带来业务变革效果的,所以为了更好地向业务方交付价值,我们必须要在系统设计的时候就为客户考虑周到,如何避免敏感信息的展示和传播,如何能在遇到冲突的时候通过系统进行保全,如何选择支撑系统的工具等。

但此议题过于敏感,我就不多展开了,且需要考虑的点大多已经完全分散在上面7个议题当中,做好以上内容的需求分析,再综合考虑敏感因素的影响,相信一定可以一定程度上解决企业真正的难题。

写在最后

聊了这么多,总结一下,要开发一款具有全球适应性的软件产品,项目人员应该灵活运用国际化和本地化的技术手段,确保软件产品能够满足不同国家和地区的用户需求。同时,持续关注全球化趋势的发展,及时更新和优化软件产品,以适应不断变化的国际市场。

以上都仅是我个人非常非常浅薄且有限的经验和观点,希望在大家日后的工作中可以起到抛砖引玉的作用。

本文由 @豆哥Chloe 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。