产品需求总览

本页用途

本页是产品需求的统一导航入口，帮助项目负责人、Agent 和初级维护者快速回答：项目有哪些长期需求、当前状态是什么、详细规则和实施证据在哪里。

本页只保存稳定摘要、状态和链接，不复制完整工单、主题文档或聊天内容。需求详情仍在对应事实来源维护，避免形成两份不一致的正式需求。

事实来源边界

信息	唯一事实来源	本页怎样记录
项目目标、用户、范围和技术基线	Project-Profile	链接和一句话摘要
长期功能需求、业务规则和系统边界	对应 Wiki 主题页	需求领域和详情链接
单次实现范围、变化和验收标准	Gitea 单元任务工单	工单编号和当前状态
已完成方案、测试和遗留问题	Wiki 任务归档	验收入口
与版本绑定的原型、设计图或交互稿	Git 中的 `design/` 或 `prototypes/`	路径、版本和确认状态
外部原型	原型平台	链接、版本或确认日期；重要版本保留可追溯快照

不保存完整聊天记录、Agent 内部推理、密码、令牌、个人数据或生产数据。

当前需求索引

需求领域	用户与场景	状态	版本 / MVP	详细说明	实施工单	原型	验收入口
文档事实来源与需求追溯	负责人和 Agent 需要从需求到实现、验收可追溯	已交付	模板核心	开发工作流	#1、#10、#14	无（流程文档）	#1 归档、#10 归档、#14 归档
初级维护者文档	初级程序员需要理解项目并处理简单修改	已交付	模板核心	项目档案、代码地图、常见修改	#2、#3	无（流程文档）	#2 归档、#3 归档
Agent 范围、效率和 Claude 协作	Agent 按确认范围实施并选择合适模型	开发中（原型门禁）	模板核心	开发工作流、仓库 `AGENTS.md` 和 `CLAUDE.md`	#4–#9、#19	无（流程文档）	对应 `Task-4` 至 `Task-9` Wiki 归档；#19 实施中
交付文档	其他岗位和客户需要与版本匹配的使用、部署或支持说明	待验收	模板核心	交付文档指南、岗位文档模板	#11	无（文档模板）	#11 归档
已有项目和多交付单元接入	维护者需要在保留历史和项目规则的前提下接入 DevHarness	已交付	模板核心	已有项目接入指南	#12、#13	无（流程文档）	#12 归档、#13 归档
建设基线与后续升级	新项目和已有项目需要选择、记录并升级可复现的 DevHarness 或开源基线	待验收（升级规范）	模板核心	新项目文档初始化、已有项目接入指南	#15、#16	无（流程文档）	#15 归档、#16 归档
产品需求与原型索引	负责人、Agent 和初级维护者需要从一个入口找到需求和证据	待验收	模板核心	本页	#18	无（当前任务没有产品界面）	#18 归档

基础设施迁移、一次性排错和普通小缺陷不作为长期产品需求单独占一行；只有它们改变长期能力、边界或使用方式时，才更新对应需求领域。

登记规则

每一行代表一项长期需求或稳定需求领域，不代表一个普通 Bug。至少填写：

清楚、稳定的需求名称；
谁在什么场景下需要它；
当前状态和所属版本、MVP 或发布范围；
唯一的详细 Wiki 页面；
当前或主要实施工单；
原型状态或明确写“无”；
已交付时的任务归档或验收入口。

需求正文、接口细节、业务规则和验收标准只在各自事实来源修改。本页使用一至两句话摘要并链接过去，不复制大段内容。

原型与设计资产

原型门禁

先选择最低成本、足以确认需求的设计证据：

修改类型	是否建单	原型或替代证据
纯界面显示文案，且不改变语义、流程、权限、状态、接口、高风险文字、国际化键、程序标识符、布局或可访问性	否	无原型，只做最小界面检查
现有界面的小范围样式或布局调整	是	标注截图、低保真图或明确复用的现有规范
新组件但沿用现有设计体系	是	组件状态和边界说明，按需提供低保真图
新页面、独立用户功能、重大交互或导航变化	是	Quant-UX 或其他工具制作并经用户确认的可审阅原型
后端、接口、数据或定时任务	是	架构、API、数据、状态或流程设计，不强制 UI 原型
恢复既有确认行为的 Bug	是	原设计、截图、复现步骤或已有验收证据

“文字豁免”只指用户看到的显示文案，不包括代码组件名、类名、变量、API 字段、数据库字段或国际化键。任何条件不明确时都要建单。

新增页面、独立用户功能、重大交互或导航变化的顺序固定为：确认文字需求 → 制作可审阅原型 → 用户确认原型和覆盖范围 → 建立或放行实现工单 → 编写生产代码。原型发生影响页面结构、主要流程、状态、权限、异常处理或验收结果的变化时，必须重新确认。

原型确认记录

原型或替代设计证据至少记录链接/路径、版本/revision或确认日期、状态、确认人、确认时间和覆盖范围。外部原型需要保留可追溯版本；重要已确认版本按需保存快照。没有 UI 原型时，记录采用的技术设计或无需原型的原因。

与代码版本绑定的图片、HTML 交互稿和设计源文件放入 Git 的 design/ 或 prototypes/，不要手工放入 Wiki 镜像目录 docs/。
外部 Figma 等原型记录可访问链接、版本或确认日期、负责人和适用需求；重要的已确认版本保留可追溯快照。
原型必须标记“草稿、已确认、已废弃”之一。草稿不能作为正式实现依据；已废弃原型保留状态和替代入口，不让 Agent 误用。
原型只表达界面和交互意图，不能代替文字业务规则、安全边界、异常处理和验收标准。
没有原型时写“无”和原因，不创建空图片、空目录或占位原型。
原型包含账号、个人信息或生产数据时必须先脱敏；凭据不得进入原型或截图。

状态规则

需求状态使用：待确认、已确认、开发中、待验收、已交付、已停止。

方案未确认时为“待确认”；用户确认后才能进入“已确认”。
开始执行单元任务后为“开发中”；实现完成并等待用户确认时为“待验收”。
用户明确验收后改为“已交付”。
需求取消或被替代时改为“已停止”，并链接原因和替代需求，不删除历史记录。
一个需求领域包含多个任务时，以尚未完成的关键任务决定状态，并在状态中简短说明。

更新时机

以下情况必须更新本页：

用户确认新的长期产品需求或新需求领域；
需求进入开发、待验收、已交付或已停止；
需求的正式 Wiki、主要工单、原型或验收入口变化；
原型从草稿变为已确认或已废弃；
MVP、版本范围或用户场景发生变化。

普通内部重构、小缺陷和不改变长期能力的任务只保留在工单，不必进入本页。

最小验收清单

新成员能从本页找到每项长期需求的详细说明。
状态与相关 Gitea 工单一致。
每项已交付需求具有验收入口。
原型具有路径或链接、版本和确认状态，或者明确写“无”。
本页没有复制完整工单或主题文档。
草稿原型没有被描述为正式需求。
不包含凭据、个人数据或生产数据。

9.5 KiB Raw Blame History Unescape Escape