按工程开发、AI 辅助与结果验收、国家标准选用分类整理 12 条提示词，提供使用入口、所需资料和参考记录。
## 任务目标 根据本次任务，从下方 12 条提示词中选择最适合的条目并说明用法。先利用当前对话和已有工程资料确定任务，不要求使用者逐项填写全部信息。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 要解决的问题：留空时沿用当前对话中的任务；没有具体任务则按下方分类说明选择方法 已有线索：可留空；使用已提到的技术栈、现象、文件或期望结果，不要求提交整套工程资料 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 从当前任务识别工程开发、模型输出验收或标准选用方向，优先匹配下方现有条目。 - 核对用户已经提供的技术栈和问题范围，不把链接标题当成真实工程现状。 ### 可采用的默认处理 - 有明确目标时推荐最贴近的1条，确需相互配合再给少量补充，不让用户自行筛完整目录。 - 没有目标时保留分类导航，并各给一句适用场景，不猜测用户需要进行重构。 ### 必须有依据的事项 - 只有几个候选会导致不同交付方式且无法由当前说明区分时，集中确认用户希望审查、实现还是准备验收。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只提供一句现象也能先定位候选条目和可直接复制的启动说明；没有工程不妨碍选择提示词。 ## 执行要求 ### 工程开发 - Vue 跨组件样式污染与弹层遮挡定位 https://prmpts.lukeliu.me/prompts/cmts62xly001kmqes83ufmn3l - Vue 浏览器交付物敏感信息检查 https://prmpts.lukeliu.me/prompts/cmts62xm3001omqessbjau79c - Python 依赖漏洞分诊与最小升级验证 https://prmpts.lukeliu.me/prompts/cmts62xmg0020mqeslzb2rp9o ### AI 辅助与结果验收 - AI 工具调用参数计划与契约检查 https://prmpts.lukeliu.me/prompts/cmts62xmx002gmqesi1gqqtz0 - 多文档问答与逐项证据核对 https://prmpts.lukeliu.me/prompts/cmts62xn1002kmqesszl20r2w - 架构设计中的接口与调用流程交接 https://prmpts.lukeliu.me/prompts/cmts62xn5002omqes5uevfw20 - 依据真实上下文完成单文件代码交付 https://prmpts.lukeliu.me/prompts/cmts62xn9002smqesjabmwem2 - 从真实错例优化提示词并保留对照 https://prmpts.lukeliu.me/prompts/cmts62xnd002wmqeskpnth945 - 结构化回答的 JSON、Schema 与业务验收 https://prmpts.lukeliu.me/prompts/cmts62xnh0030mqesvo2be9t9 ### 国家标准选用与条款核对 - 需求与软件文档国标映射（需提供标准正文） https://prmpts.lukeliu.me/prompts/cmts62xnk0034mqeso51ouv3u - 软件测试国标版本与证据核对（需提供标准正文） https://prmpts.lukeliu.me/prompts/cmts62xno0038mqesx6l0o90i - 软件质量与交互设计国标选用（需提供标准正文） https://prmpts.lukeliu.me/prompts/cmts62xnr003cmqes9vdt0wdi 国标类提示词需要正式标准正文或授权摘录；资料不全时，先核对版本、适用范围和待补证据。 ## 交付与验收 ### 本条完成检查 - 推荐项说明解决什么问题、已有说明如何代入，以及确实需要补充的最少资料。 - 保持目录链接和实际条目一致，标准正文等必要边界不因简化入口而省略。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 以上条目根据公开资料编写，具体出处、许可和适用范围见各条正文末尾。来源核验日期为 2026-09-08；国家标准类核验了官方状态和替代关系，未以元数据替代条款正文。 “AI 工具调用参数计划与契约检查”和“多文档问答与逐项证据核对”的原版本各完成了 3 个固定合成样例检查。详细结果和未覆盖范围见对应条目。本次规整已调整输入与缺资料处理规则，未重新执行模型样例验证，也未开展跨模型稳定性测评。
选定需求与软件文档的适用标准，将条款对应到项目交付物。适用于 GB/T 45802-2025、GB/T 9385-2008 与 GB/T 8567-2006；具体条款须根据用户提供的正式正文或授权摘录核对，缺少正文时只做版本与材料盘点。
## 任务目标 请作为软件产品与交付负责人，整理需求和文档交付依据。如未提供可读正文，先完成版本与材料盘点，不能输出条款符合结论。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 需求交付范围：从当前需求、合同或交付任务确定软件及文档范围；未指定阶段时，按最近一个有版本标识的需求包和实际交付清单盘点，先辨明哪些材料已经存在。 标准与交付资料：在当前项目授权资料中查找合同指定标准、正式正文或授权摘录、需求规格、设计与测试依据；使用文档自身版本和引用关系，不让用户重复整理已有清单。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 查合同、验收约定和团队标准清单中的 GB/T 编号、年份及指定或自选依据。 - 检查标准文件的来源、可读章节和完整性，将正文与仅有标题、目录或转载模板的材料分开。 - 追踪需求编号到规格、设计、接口、测试依据与交付文件的实际版本关系。 - 对照需求修改记录，检查设计及验收资料是否同步，并沿原官方入口核对现行与替代关系。 ### 可采用的默认处理 - 先盘点已经存在且确有用途的交付物，不为凑目录新增大量文档，也不把项目盘点分类说成国标固定目录。 - GB/T 默认按推荐性标准处理，是否必须采用由项目依据决定；不因标准较新就推断它替代另一项仍现行标准。 - 缺少正文时将条款编号、要求和适用判断留为未核对，继续完成版本与需求追溯整理。 ### 必须有依据的事项 - 具体条款映射必须有可读正式正文或授权摘录，不能依名称、记忆或博客模板补全条款。 - 合同指定标准与团队采用版本冲突，或需求修改是否获准不明时，不能替项目决定验收依据；先列冲突及其影响。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有标准正文时交付标准版本表、正文可见范围、交付物盘点及需求到材料的关系表。 - 交付材料尚未形成时，依据已有需求给出必要交付物建议、责任角色和材料缺口，不虚构文档已完成或条款已满足。 ## 执行要求 已知元数据：截至 2026-09-08，GB/T 45802-2025、9385-2008、8567-2006 均显示现行、推荐性；45802-2025 于 2025-12-01 实施。不能据此推断它替代了仍现行的 9385-2008。此处只核验元数据，以下是原创工作方法。 1. 核对项目实际采用的标准编号、年份及依据。区别合同指定、团队自选与仅供参考，不把 GB/T 自动改写成所有项目强制要求；执行时复查官方状态。 2. 登记正文来源、版本、可读页码与完整性，排除博客模板、征求意见稿和无版本文件。没有正文时，将条款编号、要求与适用范围留为待补。 3. 仅从可读正文提取适用条款，用简短转述记录要求和位置，区分要求、建议与示例；需求工程、需求规格和文档编制分别映射，不擅自合并为一套官方流程。 4. 盘点本项目业务需求、软件需求、设计说明、测试依据和交付资料，建立需求编号到文档版本及责任角色的关系。这些名称只是项目盘点维度，不能冒充标准固定目录。 5. 逐条填写条款位置、适用理由、项目文档、证据位置、差距与补充责任。不适用项须有正文与项目依据；只看到标题或目录的条款标为未核对。 6. 检查需求修改是否同步到设计与验收资料，区分项目内容缺失和标准证据缺失。先交付必要清单，不为凑齐模板生成无人使用的大量文档。 ## 交付与验收 输出：标准版本表、可读正文范围、条款—交付物映射、差距及责任表、补充材料清单。仅按用户明确要求创建文件，正文不得大段复制。验收条件：所有条款判断都有原文位置和项目证据，缺失正文时只报告元数据已核验。 边界：本提示词不等于官方标准原文，也未经过真实项目效果测试；不得凭填完表格宣称符合国标或已完成业务验收。 ### 本条完成检查 - 标准版本、采用依据和正文范围清楚，未核对条款不出符合结论。 - 条款到交付物的每个正式判断可定位原文和项目证据，需求变更的同步缺口可追踪。 - 交付建议只覆盖实际阶段所需内容，不把完成映射表等同于业务验收或国标认证。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（元数据核验日期：2026-09-08）： - GB/T 45802-2025：https://std.samr.gov.cn/gb/search/gbDetailed?id=36DE96AA3EACCD71E06397BE0A0A23D9 - GB/T 9385-2008：https://std.samr.gov.cn/gb/search/gbDetailedCNF?id=71F772D7FB12D3A7E05397BE0A0AB82A - GB/T 8567-2006：https://std.samr.gov.cn/gb/search/gbDetailedCNF?id=71F772D7FDE1D3A7E05397BE0A0AB82A 来源许可说明：官方公开元数据；未发现允许再发布标准全文的明确许可。本批只保留必要元数据和原页面链接，不收录全文。本条为中文原创整理，来源内容与本模板补充要求已在正文区分。
评审需求版本、业务规则、权限、数据影响和验收准备情况，指出有证据的问题、变更影响与后续处理责任。
## 任务目标 请审查需求是否具备进入研发或接受变更的条件。给出可操作的评审问题与责任建议。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 需求评审对象：从当前待研发需求或变更讨论确定对象；未指定版本时，以现有资料中最近且可识别版本的需求为基线，与其明确的上一版或变更记录比较，找不到上一版则先审当前完整性。 需求与关联资料：读取当前项目的需求版本、设计、接口、数据与权限说明、迭代计划及现行评审规则；能从工程确认的实现影响由执行者自行追踪。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对需求和设计材料的版本、日期与变更记录，检查是否误用旧资料评审新需求。 - 沿相关代码与接口追踪历史数据、统计、导入导出和租户权限的可能影响，区分已证实与待验证。 - 查设计、前后端任务、测试准备及依赖关系，找出无人承接或交付条件不一致的环节。 ### 可采用的默认处理 - 默认只读评审，不推进工作项、不替他人签署意见，也不发送上线通知。 - 优先级先采用团队定义，缺少定义时按业务损失和返工影响给出带理由的建议。 - 责任用已知岗位表达，人员或时间不足时列待分配，不因材料不齐停止对已有需求逐项审查。 ### 必须有依据的事项 - 同一核心业务规则、权限或数据口径存在互相冲突的正式材料时，不能替业务选定其中一版。 - 变更是否已经获准、适用版本或验收条件不明且影响研发准入时，只能给有条件评审建议，不能宣布已经批准。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有代码时完成需求、设计与接口材料的一致性审查，列明尚需实现证据确认的影响。 - 没有上一版本时完成当前需求完整性、问题表和关闭条件，不编造前后差异。 ## 执行要求 评审内容和节点以团队现行规则为准，下面的检查维度用于补齐业务问题，不替代团队的决策流程。 1. 确认审查对象、版本、材料日期和本次变更范围，对比前后差异。材料不完整时列出实际已读内容，避免以旧版设计稿审查新版需求却不说明。 2. 检查目标、角色、输入、业务规则、状态、失败恢复和验收条件是否齐备。每个问题指出具体条目及会影响的用户操作，避免只有“建议完善”等泛泛意见。 3. 分析变更对历史记录、统计口径、接口兼容、导入导出、权限和跨组织数据的影响。分别列出已证实影响、需查代码或数据才能确定的影响。 4. 检查设计、接口、前后端任务与测试准备是否相互匹配，找出责任空白和依赖顺序。没有人员和工期证据时只写责任角色，不替团队承诺完成日期。 5. 按业务损失与返工范围确定问题优先级，区分必须明确后才能开发的问题、可并行补充的问题和优化建议。优先级定义优先使用团队既有规则。 6. 给出逐项处理建议、补充材料、责任角色和复核条件，并形成进入研发、补充后复核或暂不具备条件的建议。未获得真实评审意见时不能标注任何人已同意。 ## 交付与验收 输出：评审范围与材料、变更摘要、问题表、影响关系、待办清单、评审建议及其条件。问题表含编号、依据位置、具体影响、优先级理由、责任角色、关闭条件。 验收：每条问题可定位和复核；重大规则与权限影响没有被界面细节掩盖；结论基于当前版本；建议与团队真实决策明确区分。 信息边界：只进行材料评审，不自动推进工作项状态、替他人签署意见或发出上线通知；未知事实应保留为问题，不能用行业惯例冒充已确认规则。 ### 本条完成检查 - 问题均有具体材料位置、业务影响和复核条件，避免泛泛要求补充。 - 历史数据、统计、权限及接口兼容影响与界面问题分清轻重，已知与推测明确区分。 - 结论对应当前版本，并区分分析建议、团队决策和待确认条件。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [云效 Projex：需求评审](https://help.aliyun.com/zh/yunxiao/user-guide/requirements-review) - [使用项目协作创建并完成需求](https://help.aliyun.com/zh/yunxiao/user-guide/start-collaboration-within-a-project)
围绕岗位每日任务设计待办、快捷入口和业务数据，明确统计口径、跳转结果、刷新规则及无数据状态。
## 任务目标 请设计面向岗位日常办理的业务工作台。目标是让用户快速开始工作并处理需要关注的事项。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 工作台岗位：从当前系统角色、默认入口及已有待办识别主要岗位；未指定角色时，先围绕现有普通业务用户的办理任务整理工作台，无法确认主岗位则分别保留实际存在角色的视图差异。 岗位与业务资料：读取现有工作台、菜单权限、待办与统计接口、业务状态及任务说明，使用已有访问或访谈记录确定优先级，不要求用户重新整理工程内已有数据口径。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 查角色菜单、默认路由与业务入口，识别必须处理、需要关注和偶尔使用的任务。 - 核对待办查询的对象、责任人、状态、组织范围及完成后消失条件。 - 追踪统计卡片到明细的查询条件、时间窗、更新时间和权限，查处理后刷新规则。 ### 可采用的默认处理 - 先保留真实待办和可达业务入口，缺少可信统计时不新增累计数字或装饰图表。 - 排序优先依据明确责任和时限，缺少行为数据时将顺序标为待验证设计建议，不编造任务频次。 - 无待办、部分无权限和数据失败分别设计；仅用标识清楚的占位字段表达结构，不把占位值显示成实时数据。 ### 必须有依据的事项 - 待办归属、待处理状态或跨组织范围无法确定时，不能猜测应由谁办理或展示哪些真实记录。 - 统计与明细口径互相冲突时，不能先选一个数字作为正确值，需确认口径后再下结论。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有真实数据时交付岗位任务优先级、模块结构、待办与指标字段口径表及跳转刷新规则。 - 没有运行页面时完成从待办进入、处理、返回的设计走查，列出待补接口与统计验证条件。 ## 执行要求 模块数量和展示方式由岗位任务决定，不能将设计示例直接当作通用要求。 1. 按角色还原登录后的首要任务，列出必须处理、需要查看、偶尔使用的事项，并注明排序依据。没有访问数据或访谈记录时只提出待验证排序。 2. 为每项待办定义来源对象、待处理状态、责任人、截止时间、组织范围和消失条件。明确已完成、历史、被撤回和本人发起但他人处理的数据是否纳入。 3. 决定首屏内容和功能入口，优先呈现业务动作及其背景。将不支持用户决策的累计数字、重复统计和装饰性图表列入删除建议，不凭空增加业务指标。 4. 逐个定义统计卡片的口径、时间窗、更新时间、单位、权限边界与明细跳转条件。点击某数量后，明细筛选应与数量口径一致，差异有合理解释。 5. 设计待办过多、无待办、加载失败、部分模块无权限、数据延迟和新账号初始化状态。无业务数据时提供可执行入口，不能用随机记录填满正式工作台。 6. 按不同角色给出页面模块顺序与操作说明，走查一个从待办进入、处理、返回并刷新统计的完整流程。记录需要接口、权限或业务方补齐的条件。 ## 交付与验收 输出：角色任务优先级、工作台模块表、待办与指标口径表、模块布局说明、跳转及刷新规则、异常状态、验收场景。只展示能解释来源与用途的模块。 验收：用户可以明确今天处理什么；待办均有真实责任与状态依据；统计与明细范围一致；空状态可继续办理；无虚构增长率、客户数量或品牌背书。 信息边界：缺少实际数据时用清楚标识的占位字段描述结构；不把占位值称为实时数据，不宣称已验证统计正确。 ### 本条完成检查 - 每个模块都有任务依据，每项待办有责任、状态和范围定义。 - 统计与明细条件对应，进入、处理、返回和刷新规则能连接成完整办理路径。 - 空状态可继续办理，未知和失败不被填成零值或随机业务记录。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 工作台](https://ant.design/docs/spec/research-workbench-cn/)
将分散功能整理为便于岗位使用者理解的中文菜单、页面层级和任务入口，覆盖深链接进入、返回路径和权限变化。
## 任务目标 请梳理企业业务系统的信息架构与导航。产出应能指导菜单调整与页面设计，避免仅做名称美化。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 导航整理范围：优先采用当前指定模块；没有指定时，从现有系统的导航入口及其页面树开始，先整理一个有完整任务链路的业务域，再标注与其他模块的共享入口。 菜单与任务资料：读取当前工程路由、菜单配置、页面标题、权限映射和已知业务任务，结合现有截图与功能说明自动建立页面归属关系。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 比对菜单、路由与真实页面入口，区分功能页、按钮、数据视图和系统设置。 - 查同义菜单、同名异义和重复入口，追踪列表、详情、编辑与审批的进入及返回路径。 - 核对角色默认页、菜单可见条件和接口权限，检查深链接、权限收回及对象删除的实际结果。 ### 可采用的默认处理 - 按业务对象与任务分组，每页指定主要归属，跨模块快捷入口明确关联，不为整齐强制相同层数。 - 缺少频次数据时使用可解释的任务顺序，并注明依据；不虚构用户实验成功率。 - 默认输出导航和迁移建议，不删除现有功能或改动真实路由、账号权限；已明确授权实施时才落地对应范围。 ### 必须有依据的事项 - 同名页面承担不同业务或功能归属存在冲突时，不能仅凭名称合并、删除或改变办理入口。 - 角色数据范围无法由授权规则确认时，不能把菜单不可见推定为禁止访问或替业务决定开放范围。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有功能清单时交付中文导航树、页面归属表、角色入口和任务路径建议，并标出尚无路由证据的部分。 - 缺少运行环境时交付旧入口到新入口的映射、深链接和返回场景，不声称导航已在系统验证。 ## 执行要求 菜单结构应提供清楚的位置线索和一致的操作方式，层级和数量由实际信息结构决定。 1. 盘点功能对应的业务对象、主要使用角色和任务频次依据，将菜单、功能按钮、数据视图与系统设置区分开。缺少访问数据时标注频次是业务人员提供还是分析假设。 2. 按业务对象与工作任务分组，找出同义菜单、同名异义和重复入口。为每个页面指定一个主要归属，需要跨模块复用的入口注明它与主入口的关系。 3. 设计层级清楚的中文导航树。复杂管理系统可以考虑侧栏，低层级浏览型入口可考虑顶部导航，说明选择原因；不要为凑整齐强行统一不同业务的层数。 4. 定义列表、详情、编辑、审批之间的进入和返回路径，说明搜索条件、页码、选中项是否保留。深链接直接进入详情时应有可理解的位置提示和返回去向。 5. 为不同角色列出默认进入页和可见范围，说明没有权限、权限刚被收回、业务对象被删除或跨组织访问时的页面结果，避免把不可见菜单当作授权边界。 6. 选择几个实际任务逐步走查导航，记录找到入口、完成操作、返回工作位置的步骤。标注需比较或验证的路径，不虚构用户实验成功率。 ## 交付与验收 输出：现有问题清单、中文导航树、页面归属表、角色入口矩阵、任务路径表、旧入口到新入口映射、待确认项。需要改名的条目说明其对应业务意义。 验收：每个功能有明确归属和可达路径；主要任务入口不会重名误导；详情页返回有上下文；权限异常有明确结果；不出现纯装饰分类和宣传口号。 信息边界：只依据已提供的业务与页面证据评价，不未经授权删除既有功能、变更路由或调整真实账号权限。 ### 本条完成检查 - 功能归属和可达路径清楚，菜单命名不会把不同业务混为同义。 - 详情返回保留合理上下文，深链接、对象删除及权限变化均有明确结果。 - 新旧入口映射完整，组织方案没有以装饰分类掩盖业务差异。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 导航](https://ant.design/docs/spec/navigation-cn/)
梳理审批与多步骤办理的状态、角色和操作后果，补齐撤回、驳回、重提、并发及中断恢复等适用流程。
## 任务目标 请为业务设计可交给研发实现的状态流程。重点解决多步骤录入或审批流中下一步不清楚、操作后果不明确的问题。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 办理流程：从当前业务对象和已有办理动作识别流程；未指定时，选择工程中已存在的一条提交到处理结果的链路，先梳理其状态、角色与中断恢复，不自行扩充审批制度。 规则与流程资料：读取现有状态枚举或字典、审批规则、表单与接口、权限和历史记录定义，结合已有流程说明提取实际可用动作。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对业务状态定义、状态转换代码或规则配置，区分加载状态与真实业务状态。 - 逐项读取提交、驳回、重提、撤回和关闭的适用条件、角色、版本及历史保留方式。 - 查草稿保存、返回、关闭页面、网络中断后的数据恢复机制，以及幂等、并发版本控制和回调处理证据。 ### 可采用的默认处理 - 只把已确认状态和转换纳入正式流程图，缺失规则以带影响说明的候选分支表达。 - 分离草稿保存与正式生效，业务终态说明办理结束，不强行安排下一责任人。 - 并发、重复点击和超时先按现有能力描述；无实现证据时列为待实现要求，不宣称系统已具备幂等或自动恢复。 ### 必须有依据的事项 - 审批权限、合法状态转换或撤销生效后果缺少业务依据时，不能自行决定，先完成其他已确认路径。 - 历史记录与新版本的责任归属冲突时，不能猜测沿用原处理人或自动生效规则。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有工程时依据规则材料交付状态词典、状态转移表、分步表单和角色视角路径。 - 规则仅部分明确时交付已确认主流程、关键异常候选及逐项决策影响，不把未确认分支画成既定流程。 ## 执行要求 将任务顺序、状态变化、权限和异常处理写清楚，具体规则以业务材料为准。 1. 以业务对象为单位列出状态，解释每个状态的业务含义及结束条件。分离业务状态与界面加载状态，不用一个含混的“处理中”同时代表审批、支付和文件上传。 2. 建立状态转移表，逐行填写当前状态、触发动作、可执行角色、前置条件、目标状态和失败结果。没有规则依据的撤销、删除或自动审批不能自行加入正式流程。 3. 明确提交、驳回、修改、重新提交、撤回和关闭等动作是否适用，注明是否保留原记录、是否生成新版本及原处理人是否继续有效。不能适用的动作说明理由。 4. 为步骤设计输入边界和保存时机，区分草稿保存与正式生效。说明返回上一步、关闭页面、网络中断后哪些数据保留，以及恢复入口在哪里。 5. 检查两人同时审批、重复点击、对象已被修改、账号权限变化和超时回调的处理结果。后端尚无幂等或版本控制依据时列为实现要求或待评审项，不能声称已具备。 6. 按办理角色走通一条正常路径和关键异常路径，检查每一步是否能看到对象当前状态、操作结果和下一责任人；已到合法终态时说明办理结束，无需下一处理人，并写出逐段验收条件。 ## 交付与验收 输出：状态词典、状态转移表、完整业务流程、分步表单说明、异常处理表、角色视角走查记录与验收条件。流程图只表达已确认状态，未确认转移使用文字列出。 验收：中间状态具备明确进入和退出条件，初态明确触发来源，终态明确结束结果；每个动作均有角色和后果；中断和并发场景能够得到明确处理；用户可知道下一步由谁完成或当前流程已经结束。 信息边界：规则缺失时给出明确标注的候选方案及影响，不替业务方决定审批权限，不把设计走查写成已执行系统测试。 ### 本条完成检查 - 每个状态有含义与进入退出条件，每个动作有角色、前提、后果和失败结果。 - 草稿、正式提交、中断恢复、并发及历史版本规则分别明确。 - 角色能知道下一步由谁办理或流程已经结束，设计走查与真实系统测试分开记录。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 表单页](https://ant.design/docs/spec/research-form-cn/)
将业务需求写成可供研发实施的功能说明和工作项，明确输入、规则、责任、依赖及验收条件。
## 任务目标 请将业务需求转成可交付研发的功能说明与工作项。面向产品、设计、前后端和测试共同阅读。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 功能需求目标：从当前会话的业务诉求与已确认范围识别功能目标；未单独填写时，沿当前需求材料或明确的本次改动拆解可独立验收的目标，不从代码现状臆造新增需求。 需求与工程资料：读取已有需求、页面、接口、字典、权限、项目约束与工作项模板，自动提取参与角色、字段和研发依赖。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对原始需求、已确认范围、现有页面和接口定义，区分新增要求与既有行为。 - 查字段来源、默认值、校验、计算、状态转换和统计口径，追踪组织及租户边界。 - 查设计、服务端、前端、数据调整与测试的现有模块和交付入口，识别真实依赖及团队工作项字段。 ### 可采用的默认处理 - 按一个可独立验收的业务目标拆一项需求，字段与任务命名沿用项目术语，复合目标先拆分再关联。 - 有依据的字段、权限和规则直接整理；缺少人员安排时使用责任角色，缺工期时只列依赖与建议顺序。 - 默认交付工作项内容及关联建议，不自动写入外部协作系统或发送消息，避免把拆解建议说成已经创建。 ### 必须有依据的事项 - 核心计算、业务默认值、状态变化或授权范围在需求与代码间冲突时，不能代替业务决定新规则。 - 历史数据兼容或正式生效后果尚未确定且影响交付正确性时，应单列必须明确的决定，同时完成其他工作项。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时根据已有业务资料交付功能说明、字段规则、角色矩阵和实施任务依赖，注明尚未核实的技术入口。 - 需求仍有空白时先交付可确认功能的验收条件及待定项对任务的具体影响，不用空泛 PRD 或虚构排期填满内容。 ## 执行要求 工作项需写清描述、负责人、优先级、项目和迭代，并关联设计、接口等研发资料；字段与流转规则以团队实际使用的系统为准。 1. 建立需求编号和简短中文标题，写明业务背景、使用角色、进入条件和最终结果。每条只描述一个可独立验收的业务目标，复合目标先拆分再说明关系。 2. 逐项列出页面或接口的输入字段、来源、类型、必填条件、合法范围、默认值和校验时机。任何默认值须有业务依据；历史数据兼容规则未知时作为缺口保留。 3. 明确核心计算、状态变化、重复提交、并发修改和失败恢复规则，分别写正常路径与异常路径。凡涉及统计，注明时间范围、组织范围、状态过滤和去重口径。 4. 整理角色操作矩阵，分别定义查看、新增、修改、审批、导入和导出权限。说明数据可见范围及权限不足时的用户反馈，不把按钮隐藏当作完整授权实现。 5. 按设计、服务端、前端、数据调整和测试拆分实际工作，建立依赖与交付物。负责人可用已提供的人名或岗位，缺少人员安排则保留待分配，避免编造排期。 6. 将需求编号关联设计稿、接口、规则依据和验收用例入口，写出每项完成条件与变更影响。只建议需要的工作项，不把拆分结果冒充已经在云效创建。 ## 交付与验收 输出：功能说明表、字段规则表、状态与异常分支、角色权限矩阵、研发任务及依赖、验收清单、待补充材料。工作项至少包含标题、范围、责任角色、依赖、交付物、优先级依据。 验收：开发能够识别输入、处理规则和结果；测试能够从每项需求形成用例；没有无来源字段和虚构工期；中文业务名称前后一致。 信息边界：现有代码与需求冲突时同时列出两者，并标明需要业务决策的差异；本任务默认不创建外部工作项或发送协作消息。 ### 本条完成检查 - 每项功能均有角色、进入条件、输入、规则、结果和独立验收条件。 - 任务能对应设计、接口、字段及测试入口，责任与依赖清楚且不虚构承诺。 - 权限、数据口径、正常与异常路径明确，需求和现有实现的冲突未被隐藏。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [云效 Projex：新建需求](https://help.aliyun.com/zh/yunxiao/user-guide/new-demand/) - [使用项目协作创建并完成需求](https://help.aliyun.com/zh/yunxiao/user-guide/start-collaboration-within-a-project)
整理业务目标、现状证据、角色边界和本期范围，区分已确认需求与待验证想法，形成可评审的需求澄清结果。
## 任务目标 请作为企业软件产品经理，围绕真实业务整理一份可评审的需求澄清结果。用途是决定本期解决什么问题，以及如何判断问题得到解决。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 业务问题：从当前会话的原始诉求、已给需求或问题记录中提取谁在什么任务上受阻；没有明确新诉求时先描述现有流程与可见问题证据，不将个人设想升级为正式需求。 现状与需求资料：使用会话已有说明、页面和问题记录，读取当前工程可确认的角色、业务对象及操作流程；只在已授权资料范围内寻找约束与历史决定。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 逐条提取原始需求及出处，区分现象、使用者诉求、解决方案建议和未验证假设。 - 查看业务对象、责任角色、组织或租户范围，以及从触发到结果的现有办理路径。 - 查重复录入、等待、返工等问题的具体材料依据，核对已承诺范围、资源或截止时间是否真实存在。 ### 可采用的默认处理 - 先还原事实与任务，再提出最小可完成目标；没有调研证据时不编造访谈、用户数量或提效比例。 - 范围优先覆盖与原始问题直接相关的内容，其他想法列为可延后或待验证，不默认扩成全系统重建。 - 没有排期和决策依据时只给有理由的优先级建议，角色与对象关系可确认多少就先整理多少。 ### 必须有依据的事项 - 材料无法判断用户实际想解决的业务问题，或相互冲突的目标会导向不同范围时，需要确认这一目标；可先完成事实与现状梳理。 - 组织责任、数据归属或必须保留的业务约束不明时，不能自行决定权限和办理责任。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有工程时依据已有原始材料交付问题证据表、角色关系、当前流程及范围建议。 - 缺少调研与运行证据时交付明确标注假设的候选目标、可观察验收条件和关键验证事项，不把候选方案当作已确认需求。 ## 执行要求 围绕使用者的角色、任务和现有困难分析需求，方案应减少理解和办理成本。 1. 逐条提取原始材料中的问题，记录谁在何时执行什么任务、在哪一步受阻以及现有证据位置。把明确事实、使用者诉求、方案建议和待验证假设分开，不能用自己的推测补成访谈结论。 2. 整理业务角色、业务对象、对象负责人和协作关系。存在集团、企业、部门或租户时分别定义视野；岗位名称相同不代表数据权限相同，组织边界不明的地方单独标注。 3. 用触发条件、输入、处理动作、输出和下一责任人还原当前流程，指出重复录入、等待和返工的位置。只描述材料支持的现象，不凭印象给出节省时间或提效百分比。 4. 为每个问题提出最小可完成的目标，区分用户任务和系统功能。将目标与需求一一关联，删去没有业务对象、触发条件或处理责任的宣传性功能表述。 5. 划分本期必须交付、可延后和不在范围的内容，注明优先级依据及依赖。没有实际资源、截止时间或决策授权时，给出排序建议，不虚构承诺日期。 6. 针对每项本期需求写可观察的完成条件，覆盖正常流程和至少一个失败分支。汇总会影响方案的关键未知项，列出应由哪个角色补充、需要何种材料。 ## 交付与验收 输出：①简明业务目标；②问题与证据表；③角色和对象关系；④当前任务流程；⑤范围与优先级表；⑥逐项验收条件；⑦待确认事项。表格使用业务中文，保留材料引用位置。 验收：所有本期功能均能追溯到具体问题和使用角色；每项都有可验证结果；事实与假设清楚区分；不存在伪造的调研、用户数量和收益数字。 信息边界：资料不足时先完成能够确定的部分，把缺口写清楚；不要未经授权联系用户或改动线上系统。 ### 本条完成检查 - 每项本期功能能追溯到具体问题、证据和使用角色，不含无业务责任的口号式功能。 - 目标、范围与优先级理由清楚，每项完成条件覆盖正常结果及适用失败分支。 - 事实、诉求、方案和假设明确区分，关键未知项说明影响和所需决定，能够确认的内容已完整交付。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 设计价值观](https://ant.design/docs/spec/values-cn/)
