openyida 2026.9.13 → 2026.9.14

package/yida-skills/skills/yida-prd/workflow/step-2-information-architecture.md

@@ -13,7 +13,7 @@
 
 自定义导航将每个入口的用途、目标资源和打开方式写清：管理视图走 `workbench/{formUuid}`，直接填写走 `submission/{formUuid}`；同一表单可对应两个独立入口，不重复创建表单。保留自绘导航时，表单在主内容区 iframe 打开；跨真实页面默认当前标签跳转；页面内新增/详情按钮使用抽屉。参数与路由规则见 [链接参考](../../../references/field-and-url-reference.md)。
 
-已确认的自定义顶部导航默认浮导，侧边或顶部＋侧边导航必须支持折叠/展开、恢复宽度和拖拽调宽；将这些交互写入 PRD，视觉细节交给 `design.md`。按 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md) 的场景与骨架引导设计，不把 CLI 导航组件当作固定 UI，不追加导航样式确认。
+已确认的自定义顶部导航默认浮导，侧边或顶部＋侧边导航必须支持折叠/展开、恢复宽度和拖拽调宽；将这些交互写入 PRD，视觉细节交给 `design.md`。按 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md) 的场景与骨架引导设计，代码示例按需参考。
 
 ## 列资源清单
 
@@ -63,7 +63,7 @@
 
 默认规则：
 
-- 默认保留平台应用导航。
+- 沿用 brief 的导航决策；未明确时按 [导航设计](../../yida-requirement-analysis/workflow/prepare-brief.md#导航设计) 补齐。
 - 页面内 tab、分段、筛选、卡片切换只是当前页内容结构。
 - 只说「工作台 / 门户 / 看板 / 大屏 / 首页」不是隐藏导航信号。
 - 同应用跨页面入口优先进入平台导航或导航分组。

package/yida-skills/skills/yida-requirement-analysis/SKILL.md

@@ -32,7 +32,7 @@ description: 识别并读取需求来源，理解和澄清用户需求，输出
 | `pageScenes` | 已确认的页面与表单范围，数组；记录稳定 key、name、kind、purpose 及已有细项 |
 | `intake` | 首次搭建判断、来源详细程度、搭建方式和需求确认状态 |
 | `visualSelection` | 已确认风格及其主题、主色、导航明暗映射；Plan 初始化前必须含非空 `themeId` |
-| `navigation` | 用户仅选择宜搭原生导航（即平台导航）或自定义导航；Agent 按场景确定布局并在 `reason` 区分选择与推断。应用导航决策：`type` 只能是 `platform-l-shape/platform-top/platform-side/custom`，并记录 `source/reason`；自定义导航增加 `variant: side/top/mixed/dock`；未决时 type 为 null，规划前补齐 |
+| `navigation` | AI 按场景判断导航方式与布局，用户明确要求优先。判断规则见 [整理需求事实](workflow/prepare-brief.md#导航设计)，`source` 区分 `ai_default` 与 `user_selected`。应用导航决策：`type` 只能是 `platform-l-shape/platform-top/platform-side/custom`，并记录 `source/reason`；自定义导航增加 `variant: side/top/mixed/dock`；未决时 type 为 null，规划前补齐 |
 | `resourceContext` | 已确认可复用的 app/page/form/process 业务上下文，不写猜测 ID |
 | `explicitScope` | 用户明确指定的页面、表单、流程、报表、导航项和本轮交付；明确窄范围时写对应数组及 `allowInferredResources:false`，没有时为 `null` |
 | `brandHints` / `colorHints` | 明确的品牌、参考页面、已有主题、偏好色与避用色 |

package/yida-skills/skills/yida-requirement-analysis/workflow/prepare-brief.md

@@ -14,37 +14,34 @@
 
 ## 2. 确认首次搭建的未决事项
 
-先分析再提问。用户已明确的信息直接采用；同一次搭建已回答的问题直接复用。首次提问必须在同一轮一次性收集所有尚未明确的搭建方式（Fast / Plan）、业务模块、页面与表单范围、导航归属（宜搭原生导航或自定义导航）和设计风格。不要先问模块、导航和风格，收到回答后再另起一轮补问模式、导航位置或页面。
+先分析再提问。用户已明确的信息直接采用；同一次搭建已回答的问题直接复用。首次提问必须在同一轮一次性收集所有尚未明确的搭建方式（Fast / Plan）、业务模块、页面与表单范围和设计风格。不要先问模块和风格，收到回答后再另起一轮补问模式或页面。导航方式及布局由 AI 按下方规则判断。
 
 先锁定用户已经明确的搭建方式：用户写明 `Plan`、先出 PRD/方案并确认后搭建时，立即把草稿的 `intake.designMode` 设为 `plan`；用户写明 `Fast` 或直接快速搭建时设为 `fast`。已锁定的搭建方式不再进入提问选项。后续 `ask_human` 只补齐其他未决事项，合并回答时必须保留已有 `intake.designMode`；不能因为回答里没有重复提到模式、结构化问题被合并、上下文压缩或重新生成 brief 而回退到 Fast。只有用户明确说“改用 Fast/Plan”时才能切换，并以最后一次明确选择为准。
 
-将整组问题放在一次结构化提问调用中。宿主限制问题数量时，合并为“搭建方式”“导航归属”“业务模块、页面与风格”等复合问题；选项数量或多选能力不足时，用允许自由输入的同组问题列出完整选择。不得因为工具数量限制而拆成多轮。只有回答遗漏、互相冲突或产生新的关键业务疑问时才针对性追问。
+将整组问题放在一次结构化提问调用中。宿主限制问题数量时，合并为“搭建方式”“业务模块、页面与风格”等复合问题；选项数量或多选能力不足时，用允许自由输入的同组问题列出完整选择。不得因为工具数量限制而拆成多轮。只有回答遗漏、互相冲突或产生新的关键业务疑问时才针对性追问。
 
 | 事项 | 何时询问 | 用户可见问题与选项 |
 | --- | --- | --- |
 | 搭建方式 | 用户未选择方式，且已提供详细计划 | “是否根据你提供的需求，整理一份应用 PRD 计划供你确认？” 是：计划更清晰详细，耗时更长；否：按现有需求快速搭建 |
 | 搭建方式 | 用户未选择方式，且需求细节不足 | “希望用哪种方式搭建？” Fast（快速搭建）；Plan（先生成 PRD，确认后再搭建，耗时更长） |
-| 导航归属 | 用户未明确宜搭原生导航或自定义导航 | “你希望应用使用哪种导航菜单？” 仅提供“宜搭原生导航”和“自定义导航”两个选项，并附下表说明。宜搭原生导航就是平台导航；归属已明确时不再询问，顶部、侧边、L 型等布局根据场景选择，不进入 `ask_human` |
 | 业务模块 | 用户未明确业务范围 | “应用需要包含哪些业务模块？” 根据业务列出具体模块及用途，支持多选或自行补充；不要只用“标准4-5模块”代替具体模块清单 |
 | 应用设计风格 | 用户未提及 | 根据业务提供简短的配色与界面风格选项，并允许描述自己的偏好；已有品牌或参考图时沿用 |
 | 页面范围 | 用户未明确页面与表单 | “这次需要哪些页面和表单？” 同轮按候选业务模块列出页面和表单及用途，支持多选或自行补充，例如“工作台：汇总待办”“活动报名表：填写报名信息”；可与业务模块合成一题，不等模块回答后再问，也不要只用“标准4页”代替页面清单 |
 
-### 导航选项说明
+搭建模式选项平等说明，不推荐、不预选，不添加“（推荐）”或“默认”。详细计划问题的“是”对应 Plan，“否”对应 Fast；两者都复用已有需求。用户明确要求代为决定模式时，记录选择和依据。
 
-导航 `ask_human` 仅有以下两个选项，不把布局或呈现样式拆成选项，也不追加布局问题。选项名称与说明一起呈现；支持 `description` 时写入该字段，否则在选项名称后用括号备注。
+### 导航设计
 
-| 导航选项 | 必须附带的说明 |
-| --- | --- |
-| 宜搭原生导航 | 使用宜搭自带的导航菜单。 |
-| 自定义导航 | 在自定义页面里定制菜单的样式和操作方式，替代宜搭自带的导航菜单。 |
+Fast 与 Plan 均由 AI 根据业务场景确定导航方式、布局和呈现样式。
 
-需要解释布局时，统一使用：“菜单放在顶部、左侧，还是顶部加左侧，会根据应用场景安排，你不用再选。” 面向用户不使用“导航归属”“布局枚举”等内部术语。
-
-模式和导航归属选项平等说明，不推荐、不预选，不添加“（推荐）”或“默认”。详细计划问题的“是”对应 Plan，“否”对应 Fast；两者都复用已有需求。用户明确要求代为决定时，记录选择和依据。
+1. 用户已明确要求宜搭原生导航、自定义导航或具体布局时优先沿用；只说“平台导航”视为宜搭原生导航，只指定顶部、侧边或 L 型时保留布局，由 AI 补齐导航方式。后续阶段沿用同一决策，不因默认规则覆盖用户要求。
+2. 已有业务应用的局部增改沿用现有导航；显式窄范围遵守上文执行边界，不因 AI 判断扩大资源范围或修改应用设置。
+3. 新建完整应用以原生表单、审批、数据管理和多模块业务操作为主，且平台导航能满足入口组织时，采用宜搭原生导航。需要在同一自定义页面中持续保留菜单和内容状态，或业务要求品牌化菜单、特殊导航交互时，可采用自定义导航，并在 `reason` 写明需求依据。仅出现“门户 / 看板 / 首页”或页面内 tab 不足以判定需要自定义应用导航；信息不足以支持自绘时采用宜搭原生导航。
+4. 将导航方式、布局和判断依据写入 brief，交给 PRD 与视觉设计共用。Plan 将导航方案纳入整体方案展示和最终确认；Fast 按已记录的判断继续实施。
 
 ### 根据场景确定导航布局
 
-用户只选择导航归属。Agent 在该归属内，结合业务模块数量、层级、切换频率、内容宽度和目标设备确定布局；用户已明确布局或提供参考时优先沿用。用户只说“平台导航”视为已选“宜搭原生导航”；只指定顶部、侧边或 L 型但未明确归属时，保留布局要求，仅询问上述两个归属选项。
+AI 在已确定的导航方式内，结合业务模块数量、层级、切换频率、内容宽度和目标设备确定布局；用户已明确布局或提供参考时优先沿用。
 
 | 场景 | 宜搭原生导航（平台导航） | 自定义导航 |
 | --- | --- | --- |
@@ -53,7 +50,7 @@
 | 业务域与域内模块形成两级导航 | L 型：`platform-l-shape` | 顶部＋侧边：`custom` + `variant: mixed` |
 | 少量高频入口的移动端轻量门户或沉浸展示 | 按实际层级选顶部或侧边 | 可选底部悬浮菜单：`custom` + `variant: dock` |
 
-这些是布局判断依据，不是固定模板或用户问卷；不得为适配布局增删业务模块，也不能因布局偏好改变已选导航归属。自定义形态细化参考 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md)。自定义顶部未指定样式时默认浮导；侧边及顶部＋侧边在 PRD/design 中写入折叠/展开和拖拽调宽，不另行提问。
+这些是布局判断依据，不是固定模板或用户问卷；不得为适配布局增删业务模块，也不能因布局偏好改变已选导航归属。自定义形态细化参考 [导航壳形态目录](../../yida-nav-shell/references/nav-shell-patterns.md)。自定义顶部未指定样式时默认浮导；侧边及顶部＋侧边在 PRD/design 中写入折叠/展开和拖拽调宽。
 
 额外只补问影响搭建的关键疑问：给谁使用、主要解决什么问题、创建还是复用应用、数据可见范围、关键审批规则、必要的外部数据来源。能够从需求和资源上下文确定的内容直接记录；一般字段和布局细节交给后续规划。
 
@@ -72,7 +69,7 @@
 - 已有确认记录且需求未变化时直接复用；后续只补充已确定的视觉映射或更新用户变更涉及的字段，不因阶段切换重写全文或重新生成页面 key。
 
 - `intake` 记录 `firstBuild`、`sourceDetail`（`detailed/brief`）、`designMode`（`fast/plan`）、`confirmed`。未决事项处理完毕后才将 confirmed 设为 true。
-- `navigation` 记录 `type/source/reason`；归属由用户选择时 `source` 为 `user_selected`，`reason` 分别写清用户选择的归属、Agent 根据场景确定的布局及依据，不将推断布局记成用户指定。归属也由用户授权代选时标记 `ai_default`。保存 confirmed brief 前按上表补齐可执行的布局枚举，不把中文选项名或笼统的 `platform` 写入 `type`，不因缺少布局再次提问；自定义导航的 `variant` 为 `side/top/mixed/dock`。顶部浮导使用 `top`，默认浮导或用户指定的通栏样式写入 `reason`，PRD 与视觉设计共同沿用；`dock` 表示底部悬浮胶囊。导航明暗由视觉选择记录。
+- `navigation` 记录 `type/source/reason`；用户明确指定导航方式时 `source` 为 `user_selected`；AI 判断方式时标记 `ai_default`。`reason` 区分用户明确要求与 AI 对方式、布局的判断依据，不将推断记成用户指定。保存 confirmed brief 前按上表补齐可执行的布局枚举，`type` 使用精确枚举；自定义导航的 `variant` 为 `side/top/mixed/dock`。顶部浮导使用 `top`，默认浮导或用户指定的通栏样式写入 `reason`，PRD 与视觉设计共同沿用；`dock` 表示底部悬浮胶囊。导航明暗由视觉选择记录。
 - 业务模块答案写入 `coreFunctions/businessObjects/explicitScope`；与页面范围合问时，分别保存模块事实与 `pageScenes`，不要只保留模块或页面数量。
 - `targetUsers/businessGoals/coreFunctions/businessObjects/pageScenes` 一律保持数组类型；单个目标也写成单元素数组。Plan 的 `visualSelection.themeId` 在保存 confirmed brief 前补齐；导航 type 使用 `platform-l-shape/platform-top/platform-side/custom` 精确枚举。
 - 用户先用“应用/系统”描述背景、后续又明确“只完成/随后完成一个”具体资源并交付时，以具体资源作为本轮执行边界。`explicitScope` 写对应的 forms/processes/reports/pages/delivery 数组并设置 `allowInferredResources:false`；不把“应用”自动扩展为示例数据、工作台、自定义列表或其他未点名资源。
@@ -88,7 +85,7 @@ Plan 的视觉选择直接使用下面的对象结构，不另写 `styleDescript
   "themeId": "airy-structured-clarity",
   "visualDirection": {"label": "轻盈结构", "description": "清晰、简洁、适合持续业务操作", "source": "requirement"},
   "colorStrategy": {"primaryColor": "#1677FF", "primaryColorName": "专业蓝", "source": "requirement", "usage": "主操作与选中态", "surfaceTone": "brand-tinted"},
-  "navigationStyle": {"structure": "side", "tone": "light", "source": "ai_default", "selectionReason": "用户选择宜搭原生导航；模块分组较多，采用平台侧边布局与浅色导航"}
+  "navigationStyle": {"structure": "side", "tone": "light", "source": "ai_default", "selectionReason": "以原生表单操作为主且模块分组较多，AI 采用平台侧边布局与浅色导航"}
 }
 ```