一、全栈全景 —— 一次请求的完整旅程（约 0.5h）

目标：跟着一个请求从头走到尾，建立"全栈有哪些层、每层程序怎么组织、数据怎么流"的直觉认知。

以一个典型的"列表加载"请求为例，现场用 DevTools Network 抓请求：

1. 请求发起：浏览器 / App 发 HTTP 请求（URL 结构、GET/POST/PUT/DELETE）

2. 路由分发：路由层根据 URL 和方法匹配到 Controller

3. 分层处理（Controller→Service→Repository）：改业务不改接口，改数据库不影响业务

4. 数据库查询：ORM 把方法调用翻译成 SQL，避免手写 SQL 的拼写错误和注入风险

5. 响应返回与客户端渲染：JSON 序列化+状态码返回；前端更新组件状态、Android 端 ViewModel 更新 LiveData

二、后端视角 —— 服务端的程序结构（约 2h）

目标：建立后端知识全貌和掌握路径，补齐前端 / 运维背景学员的判断力。

1. 后端知识全貌及掌握路径：主框架（FastAPI）、各类库（SQLAlchemy、Pydantic）、代码设计（三层结构）、契约与集成（RESTful）、安全（JWT）、可观测性（日志、traceId）；三阶段掌握路径

2. 认知顺序：① 路由机制 → ② 三层结构 → ③ 持久化与 ORM；横切关注点（读到哪层顺手认）：契约、安全、可观测性

3. 技术决策判断力

(1) 硬技术决策（通常有对错）：如 Token 刷新策略——内部后台可宽松，涉支付/敏感数据则是安全红线；依据项目非功能需求（是否对外、合规、并发规模）

(2) 代码设计判断（没有绝对对错）：如业务规则放 Controller 还是 Service——依据单一职责和分层惯例；重复逻辑要不要抽方法——依据"重复次数 vs 抽象成本"

(3) 判断依据 = 项目设计规范和已沉淀决策，不是抽象的"好不好"

4. 规范清单：状态码规范（200/400/401/403/404/500）；日志规范（不能裸标准输出）；安全规范（密码类字段不落库、不进日志，Token 不硬编码）

5. 【练习】挑一段后端 diff 的方案问题：业务逻辑该不该下沉到 Service？该复用却新写了吗？是不是"能跑但只适合玩具项目"的做法（没分页、异常吞掉、配置写死）？属于硬技术决策还是代码设计判断？

三、Web 视角 —— 浏览器端的程序结构（约 1h）

目标：建立 Web 端知识全貌和掌握路径，补齐后端 / 运维背景学员的判断力；讲清怎么借 Agent 结合 design-system 把需求变成原型。

1. Web 知识全貌及掌握路径：主框架（Vue3）、各类库（Vite、Pinia、Router）、代码设计（组件拆分、Design Token）、契约与集成（props/emit、JSBridge）、安全（登录态存储）、可观测性（三态处理）

2. 认知顺序：① 组件组织 → ② 组件通信（props/emit）→ ③ 响应式 → ④ 路由 → ⑤ 跨组件状态共享；横切关注点：契约、安全、可观测性

3. 技术决策判断力

(1) 硬技术决策：登录态存 Cookie 还是 LocalStorage——涉及用户身份或支付信息的系统选错就是 XSS/CSRF 风险来源

(2) 代码设计判断：状态放组件内部还是全局 Store——依据是否跨组件消费

4. 规范清单：页面/复用组件/跨组件状态分目录；色值间距字体必须引用设计 Token；loading/error/empty 三态必须处理

5. 【练习】挑一段 Web diff 的方案问题：组件是不是重复实现了请求封装、没复用 Store/API 层？该放 Store 的状态写进组件内部了吗？

6. 需求到原型：用 Agent + Design System 快速出图

(1) 核心思路：先把设计系统（Token、约束、页面规则）注入上下文，再让 Agent 在约束内生成，避免"能看但不合规"的原型

(2) 现场演示：给 Agent 一句模糊需求，走一遍流程——Agent 先读设计系统文件、需求模糊时先追问、生成时强制引用 Token 不硬编码、生成后跑合规校验脚本

(3) 人的判断点：生成的原型是复用了已有页面模式还是重新发明一套？新增的约束该不该反哺回设计系统？

四、App（Android）视角 —— 客户端的程序结构（约 1h）

目标：建立 Android 端知识全貌和掌握路径，补齐 Web / 后端背景学员的判断力。

1. App 知识全貌及掌握路径：主框架（生命周期、ViewModel、Navigation）、各类库（ExoPlayer、网络库）、代码设计（分层）、契约与集成（JSBridge）、安全（加密存储）、可观测性（异常、崩溃监控）

2. 认知顺序：① 项目结构 → ② 布局 → ③ 状态管理（ViewModel+LiveData）→ ④ 跳转（Navigation）→ ⑤ 发请求；横切关注点：生命周期、契约（JSBridge）、安全（加密存储）

3. 技术决策判断力

(1) 硬技术决策：敏感数据用明文还是加密存储——涉及账号或支付凭证的正式产品直接决定能否通过安全合规审查

(2) 代码设计判断：跳转逻辑放 Fragment 还是 ViewModel——依据是"UI 决策"还是"业务决策"

4. 规范清单：Fragment 只做 UI 绑定，ViewModel 管理状态和业务逻辑，Repository 封装数据源；避免错误生命周期阶段持有 Context；Token 等敏感信息禁止明文存储

5. 【练习】挑一段 App diff 的方案问题：业务逻辑是不是写进了 Fragment？跳转是不是绕过 Navigation 直接用 Intent？敏感信息存储方式对吗？

七、借助知识工程扩展 SDD 适配全栈开发（约 1h）

目标：讲清前面各部分的判断力怎么变成知识，怎么借 Router 或 OpenSpec 自定义 Schema 让 Agent 自动加载，而不是每次口头提醒。

1. 判断力对应哪类知识

(1) Agent 只看得到 Context 和 Instructions；Skill 只定义推理模式，领域内容要单独存成 Knowledge

(2) "认知顺序"→结构知识；"规范清单"→编码规范；"技术决策判断力"→设计决策；练习中挑出的坑→任务经验；与项目无关的外部规范→领域知识

2. Router：把任务路由到该加载的知识

(1) 三个职责：选择器（哪个端的任务）、加载器（该加载哪些知识文件）、精化器（专属步骤约束，如"先说明是设计决策还是实现步骤"）

(2) 不放进 Skill：每加一个端都要改一次 Skill；不放进 Knowledge：内容文件会被污染成路由配置

3. 用 OpenSpec 自定义 Schema 实现 Router

(1) Schema 名称是选择器，config.yaml 的 context 是加载器，各 artifact 的 instruction 是精化器，不用单独维护 Router 文件

(2) 换项目只需 fork 新 schema、改 instruction，Skill 不用动

4. 【演示】适配全栈开发的 SDD 工具使用体验

(1) 关注对技术决策的识别/解释/提问，选择对项目的适配性