不知道今天吃什么
决策成本
在库存、口味和时间之间反复比较，最后又回到“随便吃点”或点外卖。
02 / CONTEXT
做饭之前，
已经做了太多选择。
为什么需要这个产品？
家庭饮食不只是做一道菜。从冰箱里有什么，到今晚有多少时间、想吃什么、该怎么搭配，一顿饭之前，是一连串需要自己完成的判断。
AI 私厨管家从一个工作日晚餐场景出发：让想在家好好吃饭的人，少一点搜索和犹豫，多一点可以立即开始的行动。
- 打开冰箱
食材零散，不知道它们能组成哪一餐。
- 下班回家
时间有限，不想再翻几十份菜谱。
- 站到灶台前
双手被占用，需要看得懂、跟得上的指导。
项目路径
定义一餐的边界 → 组织核心链路 → 用可运行原型验证
03 / PROBLEM
困难不只在「怎么做」。
一道菜，从选择到坚持，跨过的是三种不同的成本。
知道吃什么，
却不一定能做好
执行成本
菜谱提供了步骤，却未必解释火候、时机与替代方案。每一次不确定，都会打断烹饪。
知道要健康，
却很难长期坚持
长期习惯成本
记录与计划需要额外精力，单次做饭没有成为下一次选择的有效反馈。
用户真正缺少的不是更多菜谱，
而是一条从食材到完成一顿饭的低决策路径。
04 / RESEARCH & INSIGHT
把「找答案」，
变成「能开始」。
从典型用户的厨房场景出发，理解行为背后的阻力与现有工具留下的空缺。
依据：现有项目文档、用户场景与原型分析。以下为设计阶段的定性判断与待验证假设，不代表量化用户研究结果。
WHO / 为谁设计
想好好吃饭，
却没有太多余力的人。
- 20–35 岁独居青年与上班族
- 希望减少试错的烹饪新手
- 关注饮食质量，但难以持续规划的人
共同点是时间碎片化、依赖手机获取信息，也需要在双手忙碌时获得帮助。
OBSERVATION / 场景里的阻力
- 有食材，缺组合
- 从现有库存出发，比从海量菜谱开始更容易行动。
- 有步骤，缺判断
- 推荐要说明为什么适合；指导要告诉用户眼前该做什么。
- 有意愿，缺连续性
- 让完成记录自然接入下一次推荐，降低额外维护成本。
MARKET GAP / 三种解决问题的方式
从内容工具，走向厨房里的任务助手。
比较的是交互模式与本项目的设计目标，不是各产品当前功能的支持清单。
| 比较维度 | 菜谱平台 | 通用 AI | AI 私厨管家 · 设计目标 |
|---|---|---|---|
| 从哪里开始 | 搜索菜名、浏览内容 | 描述需求、组织提问 | 拍下现有食材，补充偏好 |
| 如何做选择 | 用户比较不同菜谱 | 通过对话逐步收敛 | 同时展示库存、时间与推荐依据 |
| 如何完成 | 跟随图文或视频教程 | 在对话中继续追问 | 步骤、语音、计时在一条任务里衔接 |
| 如何延续 | 收藏与再次搜索 | 继续提供个人上下文 | 记录一餐，逐步沉淀偏好与反馈 |
FROM
→Search & Choose
找到一道菜OPPORTUNITY
Understand & Assist
帮助完成一顿饭查看项目依据与验证边界 文档 → 流程 → 原型
本案例的依据是可检查的项目文档与可运行原型；识别、推荐及营养数据使用本地模拟，不将设计目标等同于已上线能力。
| 工作层 | 项目依据 | 产出与验证 |
|---|---|---|
| 产品定义 | PRODUCT.md · 开发版 PRD | 目标用户、核心价值、北极星指标与明确的非目标 |
| MVP 收敛 | 产品结构 · 页面清单 · 优先级 | 从长期产品版图中收敛出一条最短可验证做饭闭环 |
| 体验设计 | 用户流程 · 状态逻辑 · 文案规则 | 识别确认、推荐解释、步骤指导、记录与健康反馈 |
| 视觉系统 | IP 资产 · 厨房背景 · 菜谱摄影 | 暖橙、奶油白、健康绿与“小厨”角色组成统一品牌语言 |
| 原型实现 | React · HTML/CSS/JS · Android 构建 | 独立 HTML 可运行原型与 Android 测试包，用真实流程检查设计 |
05 / STRATEGY
AI 的价值，
发生在每一次衔接里。
把“今天吃什么”变成一条可执行路径。面向独居青年、上班族与烹饪新手，从现有食材出发，把晚餐带到完成。
- SEE
看见食材
识别现有库存，允许确认与修正。
- UNDERSTAND
理解当下
结合用户、时间、健康目标、偏好和库存。
- DECIDE
帮助选择
收敛候选，用具体依据解释推荐。
- ASSIST
陪伴执行
用语音、计时与分步指导连接每个动作。
- LEARN
持续理解
记录口味和完成反馈，服务下一餐。
降低选择成本
用库存、时间与偏好收敛候选，不让用户在海量菜谱里继续做选择题。
降低烹饪门槛
把准备、火候、计时与调味拆成单手可读、可暂停的操作步骤。
提高食材利用率
识别冰箱中的现有食材，优先推荐能直接开做或只缺少少量食材的方案。
形成长期反馈
通过记录、收藏、口味与健康目标，让下一次推荐更贴近真实生活。
让 AI 能力变成厨房里的确定感。
- 推荐为什么值得信任？
- 显示命中食材、缺料、耗时与推荐理由，让用户能判断，也能更改选择。
- 双手忙碌时如何继续？
- 一步一重点，保留语音、计时、暂停和回看，减少厨房里的操作中断。
- 如何守住 MVP 边界？
- 先验证一次做饭闭环。社区、商城与高级 IoT 能力留到后续，不稀释首版目标。
06 / ARCHITECTURE
导航服务日常，
流程服务做饭。
五项底部导航承载高频日常；识别确认、智能匹配、菜谱详情与烹饪模式组成连续任务。
AI PRIVATE CHEF五个日常入口
首页
今日最佳匹配拍照 / 手动添加智能匹配 / 清冰箱购物与健康入口菜谱
真实菜谱库按食材搜索菜谱详情收藏与开做拍照
相机取景食材标注识别确认进入智能匹配记录
做饭日记完成菜品用时与口味饮食趋势我的
饮食偏好健康目标我的库存收藏与设置一次任务跨越多个入口，但不要求用户反复回到首页重新开始。
07 / CORE JOURNEY
一条从冰箱走到餐桌的完整路径。
从识别手边的食材开始，把选择、烹饪与反馈连成一次可以走通的任务。
01拍照识别对准食材，支持相册与手电筒02确认食材发现 4 种食材，检查数量与状态03生成智能推荐比较匹配度、缺料、时间与理由04查看菜谱详情材料、步骤、难度与预计用时05AI 烹饪陪伴语音提示与分步陪伴，帮助跟上步骤06
完成料理获得美味成就感，完成一道菜07沉淀饮食记录记录热量、营养与个人偏好08查看健康分析查看趋势与可执行健康建议
完成料理获得美味成就感，完成一道菜07沉淀饮食记录记录热量、营养与个人偏好08查看健康分析查看趋势与可执行健康建议起点足够轻
拍一下或手动补充，不要求先维护复杂库存。
结果可判断
匹配度、命中与缺料信息帮助用户快速选择。
过程能执行
步骤、火候、计时和语音入口围绕真实厨房操作。
反馈有边界
健康数据为估算建议，并明确标注仅供参考。
08 / KEY EXPERIENCE
把一餐的阻力，
拆成三个可行动的时刻。
INPUT → DECISION → EXECUTION。从眼前食材，到可解释的选择，再到可跟随的操作。
01 / 拍照识别
让冰箱里的东西，
成为最轻的输入。
用户已经站在食材面前。Camera 将逐项输入食材名称，变为一次拍摄；相册与手动输入为拍摄不便、权限未开放的情况保留入口。
- 看见过程明确显示正在识别，提示稳定与遮挡问题。
- 确认结果先检查食材与数量，再用于菜谱匹配。
- 允许修正识别错了可以改、漏掉可以加，不需要从头开始。
AI 识别结果是待确认的输入，不是不可修改的答案。
查看确认与修正机制 →02 / AI 智能推荐
在选择之前，
把依据摆在桌面上。
匹配度负责快速筛选，食材、缺料、时间和健康信息负责帮助判断。自然语言理由把这些条件连起来，让推荐可以被理解、比较和拒绝。
DECISION / 推荐信息结构示例
蒜蓉西兰花虾仁
- 匹配度
- 92%
- 已有食材
- 西兰花、虾仁
- 缺少食材
- 蒜末 · 1 项
- 预计时间
- 15 分钟
- 健康信息
- 蔬菜 + 蛋白质搭配
- 用户偏好
- 快手、清淡
为什么推荐命中两种现有食材，只需补充蒜末；做法简单，适合时间有限的一餐。
匹配度为原型示例，不代表识别置信度；营养建议仅供参考。03 / 语音伴厨
双手在做饭，
下一步依然触手可及。
手湿、拿着刀、正在看火时，语音承担高频控制。界面一次聚焦一个步骤，暂停、继续、重复和计时始终可见，语音与触屏可以互相接替。
Voice 的价值是减少厨房操作成本。
单步任务 · 本地交互演示
02 / 04 · 翻炒下入虾仁，
翻炒至两面变色。
中火 · 注意观察颜色，不确定时可以先暂停。
等待开始。可尝试暂停、继续与重复步骤。
此处模拟语音指令反馈，不调用麦克风。09 / UI EXPLORATION
设计判断，
体现在删改之间。
对比信息结构，解释为什么改变。Final 使用当前项目真实 UI，Early 使用用于讨论取舍的简化线框。
素材说明：未找到可核实的三组独立 Early 稿。以下 Early 均标注为 Exploration Reconstruction，不作为历史版本证据，也不据此声称已完成用户测试。
PROBLEM
菜名、图片和标签告诉用户这是什么，却没有解释为什么适合现在。
DECISION
把推荐依据前置到卡片，不要求进入详情再比较。
CHANGE
增加匹配、库存命中、缺料、时间与自然语言理由。
EARLY · Exploration Reconstruction
菜品图片
蒜蓉西兰花虾仁
家常菜 清淡 快手
查看菜谱
缺少“我现在能不能做”的决策信息。
PROBLEM
识别后直接推荐，会把错误输入带进结果，用户不知道从哪里改。
DECISION
在 AI 输出与推荐之间，明确设置用户确认环节。
CHANGE
识别 → 确认 → 修改 → 推荐；增加、删除与重识别都有入口。
EARLY · Exploration Reconstruction
- 拍下食材
- AI 识别完成
- 直接进入推荐
缺少检查与修正路径。
PROBLEM
信息完整，但阅读、滚动与点击同时争夺厨房里的注意力。
DECISION
将正在进行的任务与完整教程分层，让控制保持可达。
CHANGE
突出单步任务、大尺寸控制、Voice 与 Timer；完整步骤仍可回看。
EARLY · Exploration Reconstruction
全部烹饪步骤
- 准备食材与调味
- 预热锅具并下入食材
- 翻炒、调味并观察火候
- 装盘与整理
每个步骤同等突出，操作分散。
FINAL / 当前真实产品 UIprivate-chef / recommend
真实素材：screen-recommend.png。对照卡片中的匹配、缺料与推荐理由。
展开当前方案的完整设计说明
10 / DESIGN SYSTEM
从行动色，
到厨房里的陪伴感。
统一基础规则、可操作组件、影像语言与小厨角色，让体验中的每一次反馈使用同一套语言。
10.1 Foundation
行动橙#F56600主操作与进度
健康绿#37B26C完成与营养反馈
AI 蓝#3A7BFF识别与智能状态
厨房底色#FFF8EF
卡片白#FFFFFF
主文字#2B1B12
次文字#786658
TYPOGRAPHY
好好吃饭。Cook with confidence. 012345
延续品牌中的思源黑体 / DIN Next 字体方向。当前网页使用系统无衬线回退，中文优先 PingFang / Microsoft YaHei，计时数字使用等宽数字。
SPACING & RADIUS
4812162432
以 4px 为基础递进。组件内部紧凑，任务之间拉开距离；延续 14px 产品圆角与 52px 主操作高度，长篇展示区域保持开放。
10.2 Components
组件不只是外观。焦点、按下、选中与反馈一起定义下一步。以下为可操作的 HTML 示例。
BUTTON / INPUT / CHIP
选择标签，查看选中反馈。
SEARCH / RECIPE CARD
蒜蓉西兰花虾仁
15 分钟 · 缺料 1 项
没有匹配菜谱，试试“西兰花”或清空搜索。
AI RECOMMENDATION
匹配度 92%
命中西兰花和虾仁，补齐蒜末即可开做。
- WHY
- 库存、时间与清淡偏好
- DECIDE
- 缺料 1 项 · 15 分钟
- DO
- 下入虾仁，观察颜色后进入下一步
VOICE CONTROL
一步一重点，随时可暂停。
本地控制示例，不调用麦克风。
10.3 Visual Language
温暖、聪明、可靠，亲切但不幼稚。早期的绿色未来感让位于自然厨房光线、真实食物与家庭场景：Warm / Smart / Reliable / Kitchen-first / Food-led。
10.4 Brand & AI Character
AI 私厨管家懂你口味，智做每一餐
IP 是 AI 状态与反馈的视觉载体。
帽子建立厨房识别，橙色指向下一步，智能信号说明当前状态。小厨在首页、识别、推荐、语音陪伴与记录中出现，解释状态、给予鼓励，功能信息仍由清晰组件承担。
明亮橙发、白色厨师帽与围裙保留亲切的专业感。表情传递鼓励，状态文字说明当前进度和下一步。
推荐给出今日选择识别说明当前进度提醒解释匹配依据陪伴庆祝料理完成
COOK WITH CONFIDENCE · 温暖陪伴，智能作厨
“需要我推荐今晚的菜谱吗？”
同一角色，承接推荐与语音陪伴。
11 / AI EXPERIENCE
让用户理解 AI，
也能纠正 AI。
把状态、确定性、修正权和推荐依据放到使用路径里。AI 负责降低负担，用户保有最终判断。
交互示例使用本地模拟。番茄 92%、牛肉 87% 是置信度展示样例，不是模型实测准确率；与菜谱匹配度分别表达。
01 / UNDERSTANDING
AI 正在做什么？
用明确的动词说明当前工作，不把不同阶段都压成一个“加载中”。
02
正在识别食材...请保持稳定，避免遮挡
识别进行中
用短反馈说明正在识别食材，避免无信息等待。
同一个等待，不同的含义。
选择一项，查看系统状态。
完成后说明发现了什么，并给出可执行的下一步；需要更久时保留当前上下文。
02 / CONFIDENCE
AI 有多确定？
成功不等于绝对正确。以食材为单位表达置信度，并让每一项都能确认和修改。
03
✓
识别出 5 种食材
🥬🍄🍅🥚🥩
识别成功
先告诉用户发现几种食材，再进入逐项确认。
逐项确认识别结果
以下两项为独立的置信度交互示例。
请检查食材名称，再确认用于推荐。
03 / CORRECTION
AI 错了怎么办？
Human in the Loop：编辑入口就放在结果旁边，修改后保留已经完成的输入。
04
✓番茄⌕
✓鸡蛋⌕
×洋葱替换
＋添加食材
确认与修正
识别结果允许检查、补充和更改，不要求盲信 AI。
04 / TRUST
为什么做出这个推荐？
Explainability：把依据放到结果附近，使用户能够检查条件、判断适配度，而不是只相信一个分数。
05
92%匹配度
智能匹配
候选菜谱同时展示匹配度、缺料、时间和难度。
06
AI
根据你已有的番茄、鸡蛋等食材，推荐「番茄炒蛋」，利用现有食材、耗时短，步骤清晰。
推荐理由
用自然语言解释命中食材与当前推荐依据。
- 已有食材
- 先利用库存，明确命中项
- 缺少食材
- 先知道还要准备什么
- 烹饪时间
- 是否适合当前可用时间
- 健康指标
- 解释搭配方向与估算边界
- 用户偏好
- 清淡、快手等已表达条件
- 推荐依据
- 用自然语言串联以上因素
识别置信度回答“认得有多确定”；匹配度回答“与条件有多适合”。两者不能混为准确率。
任务进行中与完成后，反馈仍要连续。
Execution Feedback → Long-term Feedback。让计时解释眼前的进度，让健康反馈服务下一餐。
07
03:00剩余时间
1预热锅具 ✓2下入食材 ●3翻炒调味 ○
烹饪计时
火候、预计时间、倒计时和步骤状态集中呈现。
08
82健康评分
♡ 营养均衡♧ 低油低盐✚ 多蔬果
数据仅供参考
健康估算
先给整体判断与行动建议，并明确数据仅供参考。
12 / INTERACTIVE PROTOTYPE
让设计，
真正走到可以使用。
设计最终没有停留在一组静态界面里。我把核心路径真正做成了可以点击、切换和验证的产品。
TRY THIS FLOW
- 拍照识别
- 确认食材
- 智能推荐
- 健康反馈
下方轻量 Demo 用于检验导航、搜索筛选、模块切换与数据状态。确认、修改食材的可操作示例位于 AI Experience →。快速入口可直接切换下方 Demo 的对应模块。
首页推荐
真实菜谱6
库存命中92%
健康评分82
原型中的识别、推荐和营养数据为本地模拟，用于验证产品流程与交互，不代表已接入生产级 AI 服务。
LOCAL PROTOTYPE SIMULATION
AI / Voice / Nutrition 均为本地原型模拟，不代表 Production AI Service。匹配度与健康评分是演示数据，不是模型准确率或用户研究结果。
SCENARIO / 29 SECONDS
从打开冰箱，
到完成一餐。
打开冰箱 → 识别现有食材 → 根据理由选菜 → 跟随步骤与计时 → 记录一餐。视频让这条连续路径回到真实生活的语境。
AI PRIVATE CHEF · FILM 01一次晚餐，
从犹豫到完成。用 29 秒，看小厨如何从识别食材开始，陪用户把这一餐真正做完。
从犹豫到完成。用 29 秒，看小厨如何从识别食材开始，陪用户把这一餐真正做完。
00:00--:--
第一次使用，先讲清四件事 ONBOARDING NOTES
- 认识小厨说明助手能做什么，也说明能力边界。
- 从食材开始用拍照降低输入成本，保留确认和修正。
- 看懂推荐依据用库存、时间和偏好帮助用户作出选择。
- 完成后的反馈把一餐记录连接到下一次理解与饮食习惯。
13 / IMPLEMENTATION
把设计判断，
带进实现与验证。
以 AI Full-Stack Designer 的视角，从产品行为定义，走到任务拆解、协同编码与浏览器检查。用可核验的文件和可操作的状态，连接设计判断与最终交付。
- 01 / DESIGN
先定义体验
Product Logic
UX Flow
UI System - 02 / AI COLLABORATION
共同拆解实现
Task Breakdown
Prompt Definition
Codex Implementation
Iteration / Debug - 03 / FRONT-END
让行为运行
HTML / CSS / JS
React
Responsive / Interaction - 04 / VALIDATION
在浏览器检验
Browser / Mobile
State / Interaction
Compare / Fix - 05 / DELIVERY
留下可检验交付
Web Prototype
Existing Android Test Build
Portfolio Case Study
DESIGN → CODE
先定义什么是正确，
再让 AI 参与实现。
AI 不直接替代设计过程。产品目标、交互边界和验收条件先被写清，Codex 负责把约束转成代码，再通过真实浏览器逐项比较与修正。
实际开发约束 · 节选
“不要使用整张参考图作为页面。”
“文字必须是真 DOM。”
“移动端必须真实重排。”
“现有 Demo 不允许被破坏。”
- 明确产品行为先写清输入、状态、反馈与异常出口。
- 拆分 Section / Component划定内容边界，复用原有组件与资产。
- 定义开发约束真实 DOM、响应式重排、保护既有交互。
- Codex 实现围绕具体任务生成、修改和连接代码。
- Browser Test检验宽度、文字、点击、状态与键盘行为。
- Compare / Fix / Iterate对照目标定位问题，修正后再次验证。
TECHNICAL EVIDENCE
交付背后，
有可以核验的文件。
区分“文件存在”“交互通过验证”和“生产能力已上线”，让证据保持准确。
- 产品与流程
- PRODUCT.md、开发版 PRD，以及拍照识别到烹饪、语音打断与补救等用户体验地图。
- Web 与 React
- 独立 HTML 原型、React 的 App.jsx / main.jsx 与 Vite 项目配置均有实际文件；本页使用 HTML / CSS / JS。本轮未重新构建 React 项目。
- Existing Android Test Build
- 现有测试 APK：私厨管家-Android测试版-20260817.apk（158.2 MiB）。已核验文件存在；本轮未安装或进行真机测试。
- 浏览器与状态
- 本页以 1440、1024、768、390 四档宽度检查；Demo、搜索、状态切换、弹窗和视频作为可复验入口。
查看证据文件索引
以下是项目内实际路径的精简索引，分别属于产品项目与作品集。
私厨管家项目 / PRODUCT.md 私厨管家项目 / AI私厨管家.html.html 私厨管家项目 / ai私厨管家 / src / App.jsx 私厨管家项目 / ai私厨管家 / src / main.jsx 私厨管家项目 / ai私厨管家 / 修改文件 / package.json 私厨管家项目 / 私厨管家-Android测试版-20260817.apk 作品集 / 项目 / APP详情页 / app详情页.html 作品集 / 项目 / APP详情页 / AI_Private_Chef_Case_assets / case-study-phase-three.js查看文件大小与 SHA-256 核验记录 ↗
14 / VALIDATION
用实际问题，
检验设计是否成立。
DESIGN QA / SELF VALIDATION / PROTOTYPE VALIDATION
这里记录的是设计与原型的自检，不是外部用户研究。没有使用未经验证的用户数量、提升百分比、满意度或商业 KPI。
以下 Before / After 为已发生的实现差异摘要，不是历史界面截图。依据来自原页面代码与前两阶段重构记录。
01 / INFORMATION HIERARCHY
从整张展板，
到可阅读的网页。
- 问题
- 桌面端用 reference PNG 替代真实内容，文字和信息层级随整图缩放，难以适应不同宽度。
- 修改依据
- 保留设计语义，把标题、结论与图表关系还给 DOM，让内容在浏览器中自然组织。
After · 真实 DOM 与内容驱动高度，让信息在不同宽度重新组织。
原实现 · 桌面替换逻辑
一张图承担整段内容
.positioning-reference
.evidence-reference
.architecture-reference图片显示时，原有标题、表格与架构内容被隐藏。
02 / AI CORRECTION
把“可以纠错”，
变成真的可以操作。
- 问题
- 原 Case Study 的识别确认状态展示了“替换”，但只是静态文字，无法检验用户如何收回控制权。
- 设计判断
- 识别结果需要用户确认。补上修改、删除、增加与重新识别，让 Human in the Loop 成为可操作路径。
After · 确认、增删、修改和重新识别都有可操作反馈。
原状态示例 · 静态呈现
有修正提示，没有操作反馈
<em>替换</em>这里描述的是原 Case Study 状态示例，不代表产品历史版本完全没有纠错能力。
03 / COOKING CONTROL
从展示计时状态，
到检验伴厨控制。
- 场景问题
- 厨房里双手占用、湿手和注意力有限，仅展示完整信息不足以证明操作是否清晰。
- 设计判断
- 突出单步任务与大尺寸控制，提供暂停、继续、重复、语音提问和计时反馈；Voice 在本地模拟中验证交互意图。
After · 单步任务、暂停、继续与本地计时形成连续控制。
原状态示例 · 静态计时
03:00 是显示值
<b>03:00</b>产品记录中已有当前步骤与计时设计；本次比较的是 Case Study 如何证明交互，而非声称新发明了这些功能。
RESPONSIVE QA
同一份内容，
在不同宽度重新组织。
通过内容重排适配屏幕，而不是把固定设计稿等比例缩小。移动端无需 Hover 或 Sticky 即可阅读全部内容。
- 1440Desktop · 双栏与横向工作流
- 1024Laptop · 收敛间距与列数
- 768Tablet · 普通文档流
- 390Mobile · 纵向阅读与可触控操作
15 / REFLECTION
让 AI 的能力，
成为用户的确定感。
WHAT WORKED
让 AI 进入每一次衔接。
AI 没有被做成一个独立聊天入口，而是进入识别、决策、执行与反馈。每一步围绕用户此刻的任务，提供下一步可采取的行动。
这是本项目形成的产品设计判断；实际使用效果仍需要真实用户与真实模型验证。
WHAT I LEARNED
AI 产品最重要的并不是让 AI 看起来有多聪明，而是让用户知道它正在做什么、为什么这样判断，以及判断错了以后怎么办。
- Visibility
- 让系统状态可见。
- Explainability
- 让判断依据可理解。
- Correction
- 让结果可以被修正。
- Trust
- 用清楚的边界建立信任。
WHAT’S NEXT