研发协作CASE 01
会议里第一次听到 Redis，需要立刻学会写吗？
用户正在做什么
设计师参与架构讨论，需要理解登录会话和缓存方案。
业务会出什么问题
所有概念都按同一深度学习，会陷入细节并失去全景。
技术怎样介入
用 Competency Level 区分听懂、会解释、会使用、会实现和会设计，先补 Breadth 再按任务增加 Depth。
产品与设计怎样落地
记录这个概念影响的业务状态和设计决策，暂时不必学习底层源码。
M6 · Chapter 17
设计师应该深入到什么程度？
建立个人学习边界，从能听懂走向能独立开发。
先看哪些场景
研发协作、项目与协作、部署与云、异步任务
它是什么
全栈学习可以分成识别、连接、使用、实现和架构判断五个层级。
为什么需要
广度建立坐标，深度服务目标。所有技术都学到底会造成长期分散和低反馈。
位于哪一层
课程出口，用于把知识地图转化为个人学习与项目计划。
和谁连接
前端、后端、数据库、AI、部署、工程协作和架构认知。
项目里怎么出现
设计师可以先做到看懂系统，再选择前端、全栈产品或 AI 应用作为主线。
Learning Outcomes
学完这一章，你应该能
- 判断每个领域需要达到的掌握层级
- 形成设计师友好的全栈主线
- 用真实项目串起技术学习
- 建立 AI 协作与代码判断能力
17.01
五个掌握层级
同一个概念可以只需识别，也可以深入到独立设计和实现。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
识别是知道名词位于哪里；连接是知道上下游；使用是能配置和调用；实现是能独立编码与调试；判断是能比较方案和承担架构结果。
Kubernetes 可以停在识别和连接，React 与 API 可以进入实现，数据库和安全至少要达到使用与判断基础。
Recognize → Connect → Use → Implement → Decide
System View
看见能认出
能解释为何存在
能在项目里使用
能独立实现和调试
能做方案取舍
Designer Lens
给每个知识点标记目标层级，可以防止课程越学越散。
BreadthDepthCompetency Level
17.02
设计师建议深入掌握的主线
前端、API、数据和 AI 应用最能直接连接设计优势。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
项目与协作CASE 01
设计师想独立做一个业务产品，最值得深入哪条主线？
用户正在做什么
目标是把项目管理系统从设计做到可上线版本。
业务会出什么问题
只学界面难以接入真实数据，平均用力学习所有基础设施也难以形成产出。
技术怎样介入
深入 TypeScript、Full-stack Framework、HTTP、数据库和认证，逐步形成 Product Engineer 能力。
产品与设计怎样落地
每学一个技术都放回列表、详情、表单、权限和异常流程。
HTML、CSS、TypeScript、React、组件、状态、路由和可访问性建议达到独立实现。HTTP、REST API、Node.js 后端和 PostgreSQL建议达到可开发完整产品。
Git、测试、认证、文件存储和部署需要能实际使用。AI API、Structured Output、RAG 和 Tool Calling 可以作为现代全栈重点。
Design System → Frontend → API → Backend → Database → AI → Deploy
System View
必须会实现：前端与交互
主线会开发：API、后端、数据库
必须会使用：Git、认证、存储、部署
现代重点：AI 应用与工具调用
Designer Lens
你的优势在界面、系统结构和表达，学习重点是把这些能力延伸到可运行产品。
TypeScriptFull-stack FrameworkProduct Engineer
17.03
哪些先做到会用？
大量工程能力无需从零实现，但要能正确配置、观察和排错。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
部署与云CASE 01
数据库和登录能否先用托管平台完成？
用户正在做什么
个人项目需要快速上线账号、数据和文件功能。
业务会出什么问题
从零维护服务器会让学习主线被运维细节打断。
技术怎样介入
先使用 Managed Platform，通过 Configuration 完成能力；遇到问题练习 Troubleshooting，再决定是否深入实现。
产品与设计怎样落地
选择平台时看数据导出、权限、成本和迁移限制。
身份服务、对象存储、Redis、云数据库、CI/CD、Docker 和监控平台可以先使用托管方案。重点理解配置项、权限、成本和故障表现。
会用意味着你可以完成接入、阅读日志、修改配置、验证结果并知道何时需要专家。
Managed Service / Tool → Configure → Integrate → Observe → Troubleshoot
System View
认证服务
对象存储
云数据库
Redis
CI/CD 平台
Docker
错误监控
部署平台
Designer Lens
AI 生成配置后，要能识别密钥泄露、权限过大、环境错位和不可回滚。
Managed PlatformConfigurationTroubleshooting
17.04
哪些先建立认知？
复杂基础设施和分布式技术先理解位置、用途和风险。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
异步任务CASE 01
还没有百万消息时，需要先深入 Kafka 吗？
用户正在做什么
个人项目只有少量通知任务，但课程里已经遇到 Kafka。
业务会出什么问题
提前钻研复杂分布式细节会占用大量时间，也缺少真实问题支撑。
技术怎样介入
先建立 Architecture Literacy 和 Trade-off Awareness；真正出现吞吐、重放或多消费者需求时再 Just-in-time Learning。
产品与设计怎样落地
当前只需知道它会带来异步状态、延迟和失败处理。
Kafka、Kubernetes、Service Discovery、分布式事务、跨区域容灾和大规模数据平台可以停在认知层。真实项目出现明确需求后再深入。
能够听懂会议、看懂架构图、提出边界和成本问题，已经会显著提升跨团队协作。
Recognize Purpose + Position + Trade-off → Deepen When Needed
System View
消息流平台
容器集群
服务发现
分布式事务
跨地域架构
数据仓库
基础设施即代码
复杂安全治理
Designer Lens
不写 Kubernetes 配置，也可以准确说明它负责容器调度，不负责业务逻辑。
Just-in-time LearningTrade-off AwarenessArchitecture Literacy
17.05
用一个产品贯穿学习
真实项目让抽象概念在需要出现时自然连接。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
项目与协作CASE 01
怎样用一个项目管理产品贯穿全栈学习？
用户正在做什么
先做项目列表，再逐步加入详情、成员、权限、文件和通知。
业务会出什么问题
按技术章节分别做零散 Demo，很难理解它们如何协作。
技术怎样介入
每次完成一个 Vertical Slice：页面、API、数据库和状态一起跑通；从 CRUD 开始持续 Iteration。
产品与设计怎样落地
每轮迭代都补一个真实业务问题和对应异常状态。
建议选择一个中等复杂度 SaaS，例如项目管理、课程平台或内容工作台。先做界面与状态，再接 API、数据库、登录、文件和部署。
第二轮增加搜索、异步任务和 AI，第三轮补测试、监控和性能。每次只增加一个系统维度，并保留可运行版本。
UI Prototype → Real Data → Auth → Files → Deploy → Async → AI → Reliability
System View
第 1 版：静态前端
第 2 版：真实 CRUD
第 3 版：登录与权限
第 4 版：文件与部署
第 5 版：异步与 AI
第 6 版：测试与监控
Designer Lens
持续围绕同一个产品，可以同时训练产品建模、设计系统、前端与工程判断。
CRUDVertical SliceIteration
17.06
AI 时代应该练什么？
重点从代码记忆转向结构理解、约束表达、调试和验收。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
研发协作CASE 01
AI 已经能写代码，设计师还要练什么？
用户正在做什么
AI 生成了登录和权限代码，但页面偶发越权且测试不完整。
业务会出什么问题
复制代码不等于理解，错误可能隐藏在状态、数据和边界条件中。
技术怎样介入
学会读 Diff、定位 Debugging 线索，并通过测试、文档和真实场景做 Verification。
产品与设计怎样落地
要求 AI 解释业务链路、失败路径和安全假设，再决定是否接受代码。
你要能让 AI 解释仓库、定位代码、生成小步变更、编写测试和分析错误。每次修改都要先确认目标、影响文件、数据变化和验收方式。
代码阅读、Network、日志、数据库和 Git Diff 是判断 AI 是否正确的关键工具。生成速度越快，验证能力越重要。
Intent → Plan → AI Change → Diff → Run → Test → Review → Commit
System View
明确任务
→
让 AI 解释现状
→
限制修改范围
→
生成代码
→
运行与观察
→
测试与走查
→
提交版本
Designer Lens
把设计规范、组件资产、业务规则和验收标准整理成 AI 可读取上下文，会放大你的结构化能力。
DiffDebuggingVerification
17.07
一条可执行的学习路线
先完成全景浏览，再用三轮项目建立实现能力。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
项目与协作CASE 01
怎样把全景知识变成持续可执行的学习路线？
用户正在做什么
学习者容易在前端、Docker、微服务和 AI 之间频繁跳转。
业务会出什么问题
缺少闭环会积累名词，却没有可运行成果和判断能力。
技术怎样介入
建立 Learning Loop：选一个 Portfolio Project，完成一段垂直功能，记录问题，补知识，再做 Retrospective。
产品与设计怎样落地
课程进度以能解释和完成真实场景为准，不以看完视频数量为准。
第一轮用一周快速浏览全部章节，为名词建立位置。第二轮用前端项目练组件、状态、路由和 API。第三轮补后端、数据库、权限和部署。
第四轮加入 AI、异步和文件；第五轮回到架构、性能和稳定性。每轮都产出可演示版本、系统图和复盘。
Map → Frontend Slice → Full-stack Slice → AI Slice → Engineering Quality
System View
全景认知
前端实现
全栈 CRUD
权限与部署
AI 与异步
测试、性能与架构复盘
Designer Lens
学习成果用“能解释、能画图、能运行、能排错、能迭代”衡量。
Learning LoopPortfolio ProjectRetrospective
Chapter Recap
本章小结
- 01学习目标分成识别、连接、使用、实现和判断。
- 02设计师主线适合前端、API、数据库和 AI 应用。
- 03复杂基础设施先建立认知，真实需求出现后再深入。
- 04围绕一个产品迭代，并把 AI 用于解释、修改、测试和调试。
Practice
把认知变成一张图
为自己制作一张技能雷达：把课程全部领域标成识别、连接、使用、实现、判断五个目标层级，并选一个 6 周项目主线。
Quick Check
随堂检查
QUESTION 01
Kubernetes 对大多数设计师的初始目标层级更适合是什么？
先建立架构认知，真实项目需要时再深入实现。
QUESTION 02
AI 生成代码后最重要的下一步是什么？
AI 时代的核心能力包括验证、调试和版本控制。