LutiveLab AI Guide · 把日常的小麻烦，做成顺手可用的软件

设计说明 · R9-C

给评审看，不属于页面。

R9-A 的单阶段工作台是骨架；R9-B 的真实内容只进入“数据”，不进入“版面”。四个案例在同一套交互里，用各自不同的功能清单、问题、改法和反馈。
前后步骤真正连起来：第 2 步留下的重功能，会在第 4 步变成 AI 画出来却点不动的按钮；第 2 步删掉的可选功能，第 4、5 步就不再出现对应的问题和改法。
两层体验明确分开：入门路线走完是“一轮”，不是“完成”；第 6 步的反馈可以把人送回第 5 步或第 2 步；“完整案例”是一块真实可走的第二层工作台，只讲《下班去哪儿》，并对其他案例说清楚这一点。

原型里的数据	含义	建议落点
`IDEAS[key]`	当前想法：烦恼、工具、真实证据、功能、载体、问题、改法、反馈	替换 `R9B_ROADMAP_CASES`，按同样字段扩展
`feats[].kind`	core / opt / heavy；heavy 带 `dep`、`btn`	由 `scopeItems` 扩展而来
`issues` / `fixes`	第 4 步可发现的问题、第 5 步对应改法和单步指令；`needs` 表示依赖哪项功能	由 `usableUpgrades` 扩展而来
`evidence.status`	real / rebuild / sim / plan	统一的内容状态标记
`RES[stage]`	“卡住了？”里的症状 → 资源	新内容只声明“阶段 + 症状 + 状态”，不加首页入口
`JOURNEY`	完整案例六步：问题、改动、原因、坑、指令	沿用 `LIVING_JOURNEY_STAGES`
`T`	页面上所有界面文案（标题、按钮、反馈、提示）	整体搬到 `src/content/zh/copy.ts`，人工改字不碰组件；案例内容放 `src/content/zh/cases/`
`WHO` / `q4Parts()`	第 4 步把前三步的选择拼成四色四问：情况←第 1 步，要求与边界←第 2 步，结果←第 3 步	与 AI Rules Lab 共用四问字段和配色，复制出的纯文本可以直接带进 Lab 继续练
`P[idea]`	每个想法各自的进度：删掉的功能、需求开关、已发现问题、已开改法、试用清单、下一版候选	组件内状态即可，无需账户或持久化