一、整体流程
需求文档不完整，在软件开发中的常态下采用的提问策略：
第一步：让 Agent 帮你梳理现状
先把文档丢给 Agent，然后这样问：
"这是我收到的需求文档，里面有很多缺失和错误的地方。请你帮我做以下事情：
- 梳理出文档中明确的需求点有哪些
- 列出文档中缺失、模糊或矛盾的地方
- 针对每个缺失点，给出你需要我向用户确认的具体问题清单"
第二步：分模块逐步推进
不要一次性让 Agent 开发整个软件，而是按模块拆分：
"我们先从【XX模块】开始。基于目前文档中关于这个模块的信息，请你：
- 给出这个模块的技术方案设计
- 列出还需要补充哪些细节才能开始编码
- 对不确定的地方，给出 2-3 个合理的假设方案供我选择"
第三步：用假设驱动开发
对于缺失的内容，让 Agent 给出假设并推进：
"关于【XX功能】文档中没有说明，请你基于行业常见做法，给出一个合理的默认方案，并标注清楚哪些是假设的、后续需要用户确认的。然后按照这个方案开始写代码。"
第四步：持续迭代确认
每完成一个模块，让 Agent 帮你生成确认材料：
"请根据目前已完成的设计/代码，生成一份给用户的确认清单，用非技术语言描述关键决策点，方便我去找用户确认。"
💡 核心原则
- 先梳理，再开发：不要急着写代码，先让 Agent 帮你把需求缺口全部暴露出来
- 假设 + 标注：对缺失内容做合理假设继续推进，但明确标注"此处待确认"
- 小步快跑：每完成一小块就生成确认材料，避免最后大面积返工
- 让 Agent 帮你问：让 Agent 直接帮你起草需要问用户的问题，你只需要转发。
二、操作流程
如果你现在还没跟用户沟通过 ，建议选 A，先把问题清单整理出来发给用户，避免做了一堆假设最后全部返工。
如果你已经跟用户有过初步沟通 ，心里有数哪些模块是确定的，建议选 B，直接推进开发，效率更高。
先整理向用户确认的措辞
适用场景： 文档缺失/矛盾的地方太多，你不确定该怎么做决策，需要先找用户确认清楚再推进。
你可以这样回复 Agent：
"先帮我整理向用户确认的措辞。请把缺失和矛盾的问题按优先级排序，用非技术语言写成一份可以直接发给用户的确认清单。"
Agent 会帮你产出： 一份条理清晰、用户能看懂的问题清单，你复制粘贴发给用户即可。
我们先从【用户认证与安全】开始。基于目前./docs/features、guides、intro、需求确认清单.md文档中关于这个模块的信息，请你 ：
请基于现有 Django 项目的后端接口开发对应前端页面。后端接口代码位于 .\hk\apps\authentication
目录下，项目整体说明与结构介绍可查阅 .\hk\hk\docs 目录中的文档。
技术方案
实施文档
为这段超级管理员接口写上前端页面，后端页面所在位置E:\app\code\py_code\hk\hk\apps\super_admin，项目结构在E:\app\code\py_code\hk\hk\docs，生成的前端页面统一存放到E:\app\code\py_code\hk\hk\templates，系统基于Vue2+Axios+Django+DRF+JWT+MySQL主流技术栈开发，项目实施文档：E:\app\code\py_code\hk\hk\docs\技术方案_超级管理员模块_实施文档.md
优化超级管理员界面【UI/UX 问题。主要槽点在于：配色过于刺眼（高饱和度的粉紫背景）、布局松散、卡片风格过时（过大的圆角和渐变色显得廉价），以及文字排版缺乏层级感。
要将其改造成一个专业、现代、清爽的后台管理系统，建议从以下几个维度进行重构：
- 核心视觉规范重构 (Visual Identity)
背景色： 放弃大面积的高饱和度颜色。
推荐： 使用浅灰白作为全局背景（如 #f0f2f5 或 #f5f7fa），内容区域使用纯白卡片（#ffffff）。
主色调： 选择一个沉稳的品牌色。
推荐： 科技蓝（#1890ff）或 深靛青（#4f46e5），用于按钮、图标和高亮状态。
字体与排版：
标题： 加粗，字号适中（16px-18px），颜色深黑（#333）。
正文： 常规字重，颜色深灰（#666）。
辅助信息： 浅灰（#999），字号稍小。
- 页面布局优化 (Layout Strategy)
采用经典的左右结构或顶部导航+侧边栏结构：
A. 侧边导航栏 (Sidebar)
样式： 深色背景（如深蓝灰 #001529）或 纯白背景带阴影。
菜单项： 去除多余的英文翻译（除非必要），保持中文简洁。图标应统一风格（线性或面性），不要直接放 Emoji 或粗糙的 SVG。
层级： "权限管理"下包含"管理员申请"和"管理员管理"，应有明显的缩进关系。
B. 顶部栏 (Header)
功能： 放置面包屑导航（如：首页 / 概览）、全局搜索、通知铃铛、用户头像及下拉菜单。
高度： 固定高度（如 64px），底部加一条细微的分隔线。
C. 内容区域 (Main Content)
数据概览区（Dashboard Cards）：
改为单行排列的 4 个白色卡片。
去掉花哨的背景渐变，改为左侧显示数据，右侧显示浅色图标。
增加"较昨日/上周"的涨跌幅提示（红色/绿色箭头）。
列表/详情区：
下方分为左右两栏（比例 2:1 或 1:1）。
左侧："待审批申请"表格。
右侧："最近操作日志"时间轴或简略列表。】@skill:ui-designer @plugin:产品设计:产品设计
角色与任务 ：请你扮演一名资深后端架构师。当前需要为"普通管理员"模块设计并编写代码。
背景说明 ：我已经提供了参考文档路径 E:\app\code\py_code\hk\hk\docs，但经查阅，该文档中并未包含此模块的具体说明。
执行要求：
- 行业最佳实践：请基于主流后台管理系统的行业常见做法，为"普通管理员"模块提供一个合理的默认设计方案。
- 假设标注：在给出方案时，请务必清晰标注出哪些是基于行业经验做出的"假设"，以便我后续进行人工确认。
- 代码实现：方案确认后，请严格按照该方案直接开始编写代码。
/frontend-design 角色与任务：请你扮演一名资深后端架构师。当前需要为"普通管理员"模块设计并编写代码。
背景说明：
我已经提供了参考文档路径 E:\app\code\py_code\hk\hk\docs，但经查阅，该文档中并未包含此模块的具体说明。
执行要求： 行业最佳实践：请基于主流后台管理系统的行业常见做法，为"普通管理员"模块提供一个合理的默认设计方案。
假设标注：在给出方案时，请务必清晰标注出哪些是基于行业经验做出的"假设"，以便我后续进行人工确认。
代码实现：方案确认后，请严格按照该方案直接开始编写代码。
文档分析
基于 `技术方案_普通管理员模块.md` 文档分析，梳理明确需求、缺失点、矛盾点，列出需向用户确认的问题。
关于【普通管理员功能】文档中没有说明，请你基于行业常见做法，给出一个合理的默认方案，并标注清楚哪些是假设的、后续需要用户确认的。然后按照这个方案开始写代码。所有项目介绍文档所在位置【E:\app\code\py_code\hk\hk\docs】