产品设计辅助系统

系统说明

本系统是一个自进化的产品设计辅助系统，采用分层架构设计，包含通用产品设计层与产品专属规则层。作为系统的入口文件，本规则指导产品设计助手协助产品经理完成交互原型搭建、需求文档编写以及经验复盘提炼。工作语言为中文。

一、通用产品设计规则

本章节规则适用于所有产品线的设计沟通与协作。

1. 文件夹结构规则

每个需求功能点为独立文件夹，文件夹下包含标准的三件套：

需求名称/
├── {需求名称}.html         # 交互原型（单文件 HTML，内联 CSS + JS，文件名与文件夹同名）
├── 需求说明文档.md          # 需求说明（最终态，始终反映最新设计）
├── CHANGELOG.md            # 变更日志（精简表格，记录每次变更的时间和摘要）
├── _进展备忘.md            # 【可选】过程沉淀，长周期需求使用，复盘生成后删除
└── *.png / *.jpg           # 截图参考

文件命名规则：HTML 原型文件名必须与需求文件夹名称一致。例如需求文件夹为「用户列表筛选优化」，则原型文件为 用户列表筛选优化.html。

2. 需求说明文档规范

需求说明文档是最终态文档，始终反映当前最新的产品设计，不保留历史过程。每次变更后直接更新为最新状态。

文档结构

# {需求标题}

## 问题

1. {业务痛点/场景问题，从用户视角出发}
2. ...

## 需求设计

### 一、{功能模块名称}

{1-2 句概括该模块的定位和上下文}

1. {功能点}：
   - {具体规则}；
   - {具体规则}。
2. ...

### 二、{功能模块名称}

...

### N-1、权限说明（新增页面时必须包含）

{说明该页面的访问权限、操作权限等}

### N、操作日志（新增页面时必须包含）

{说明该页面的关键操作需要记录哪些操作日志}

写作风格规则

3. 变更日志规范

变更日志是过程记录，以表格形式记录每次变更的时间点和摘要，用于追溯设计演变过程。

格式

# 变更日志

| 序号 | 日期 | 变更摘要 | 影响模块 |
|------|------|----------|----------|
| 1 | 2026-01-10 | 列表新增「状态」列，支持快速筛选 | 列表页 |
| 2 | 2026-01-12 | 状态标签颜色调整为品牌色方案 | 列表页 |

规则

• 序号从 1 开始递增，不重置；
• 日期格式 YYYY-MM-DD；
• 变更摘要一句话概括，不写实现细节；
• 影响模块对应需求说明文档中的章节名称（如「列表页」「操作弹窗」）。

4. 工作流程

每次沟通变更后，按以下顺序执行：

1. 先改原型：在 HTML 原型文件中实现变更；
2. 再更新需求文档：将 需求说明文档.md 对应章节更新为最新状态（如果是新功能则新增章节，如果是调整则直接覆盖旧描述）；
3. 最后追加日志：在 CHANGELOG.md 表格末尾追加一行记录。

注意事项：

• 需求说明文档中不保留被替代的旧设计，始终只体现最终方案；
• 如果一次沟通涉及多个变更点，需求文档统一更新，CHANGELOG 每个变更点各记一行；
• 参照截图还原 UI 时，需在变更摘要中注明"按截图还原"；
• 新建需求文件夹时，同步创建空的 需求说明文档.md 和 CHANGELOG.md。
• 在需求开发过程中，可随时要求「总结一下当前进展」，AI 会将阶段性记录追加到 _进展备忘.md（详见第 7 节）；
• 当 AI 检测到需求可能已完成时，会主动询问是否生成复盘；用户也可随时手动说「生成复盘」触发（详见第 7 节）。
• 目录调整同步规则：对 product-context/ 目录下的文件或文件夹进行重命名、新增、删除时，必须同步更新以下位置的引用：①本文件（AGENTS.md）中所有涉及该路径的描述；②product-context/README.md 的目录表格。

5. 原型设计规范

原型采用纯 HTML 单文件方案，无外部依赖。所有样式和交互逻辑均通过内联 CSS 和 JS 实现，无需构建工具，可直接在浏览器中打开。

详细规范请参考：product-context/01-原型设计规范.md。

技术路线可根据你的产品实际情况定制，核心原则是：原型文件自闭合、无需网络依赖、视觉风格与你的产品组件库保持一致。

6. 知识库

知识库位于 product-context/ 目录下，用于沉淀和复用设计资产：

• README.md：知识库使用说明
• 01-原型设计规范.md：原型技术路线与视觉规范
• 02-设计原则库.md：从实际案例提炼的可复用设计原则
• 03-交互模式库.md：从实际需求提炼的交互流程模式
• 04-文案规范.md：界面文案与提示语规范
• 05-业务术语表.md：产品领域专业词汇与概念定义
• component-templates/：HTML 组件模板目录
• design-decisions/：设计决策记录目录
• retrospectives/：复盘日记目录

7. 复盘与经验提炼工作流

为了实现系统的自进化，引入轻量化、过程积累式的复盘机制。核心设计原则：让复盘从"事后额外工作"变成"过程中自然积累 + AI 自动生成"的副产品。

7.1 临时总结（过程沉淀）

适用于交互轮次较多的长周期需求，在过程中随时记录关键信息，避免上下文流失。

• 触发方式：用户说「总结一下当前进展」「记录一下」或类似指令；
• 输出位置：当前需求文件夹下的 _进展备忘.md（不存在则自动创建）；
• 写入方式：追加到文件末尾，不覆盖已有记录；

• 最小条目格式：

  ### YYYY-MM-DD
  
  - **本轮变更**：{做了什么，一句话概括}
  - **关键决策**：{为什么这样做，有哪些权衡}
  - **待确认事项**：{未解决的问题}（如无则省略）

• 内容要求：只记录变更、决策、未决事项三类；每条不超过 3 行；不写实现细节（如 CSS 类名、函数名）；
• 文件定位：可选的临时沉淀文件，缺失不影响主流程；
• 跨需求处理：如对话中涉及多个需求，AI 应主动询问「这次总结针对哪个需求？」再写入。

7.2 复盘触发机制（双触发）

AI 主动提醒：当检测到以下信号时，AI 主动询问「这个需求是否已完成，是否要生成复盘？」

• 需求文档和原型近几轮无实质性改动；
• 用户开始讨论另一个需求；
• 用户表达收尾信号（如「这个差不多了」「先到这里」「可以了」）。

手动触发：用户随时可以说「生成复盘」「做一下复盘」「开始复盘」来直接触发。

确认机制：无论哪种方式触发，AI 生成复盘前需得到用户明确确认（防止误触发）。AI 提醒后，用户回复「是」「好的」「可以」等即视为确认。

7.3 复盘自动生成

用户确认后，AI 自动读取以下数据源生成复盘：

• 输出位置：product-context/retrospectives/{需求名称}-复盘.md；
• 输出格式：按复盘模板（product-context/retrospectives/_template.md）填写；
• 生成后处理：删除 _进展备忘.md（其内容已整合进复盘）；如复盘中包含截图，按第 8 节附件管理规范归档；
• 容错处理：如 CHANGELOG 为空或 _进展备忘.md 不存在，AI 基于可用信息降级生成，并在复盘"背景"部分标注「数据源有限」。

7.4 知识库回写（建议，不阻塞）

• 复盘生成时，AI 同步产出知识库更新建议（设计原则候选、交互模式候选等）；
• 知识库回写为建议性操作，不作为复盘完成的前提条件；
• 用户可选择立即确认写入，也可后续批量处理；
• 每条候选条目必须引用本次需求作为实际案例（符合第 9 节准入条件）。

7.5 日常提示

每次交互结束时，助手可主动提示用户是否有可提炼的模式或原则。

8. 附件管理规范

所有文档的图片、截图等附件统一存放在根目录的 附件/ 文件夹下，以源文件名称（不含扩展名）作为子文件夹：

附件/
├── {文档名称}/          # 文档配图
│   └── media/
│       ├── image1.png
│       └── ...
├── {需求名称}/          # 需求复盘文档的配图
│   ├── image1.png
│   └── ...

规则

• 附件文件夹名称必须与源文件名称一致（去掉 .docx、.pdf 等扩展名）；
• md 文件中使用相对路径引用图片，例如：![](../../附件/文档名称/media/image1.png)；
• 不要将图片散落在版本目录或需求文件夹中（需求截图参考除外）。

需求复盘文档的图片管理

在 md 文件中粘贴截图时，编辑器会自动将图片保存到根目录，需要在每次复盘整理时统一归档：

1. 将根目录中属于该需求的图片（如 Pasted image*.png 等）移动到 附件/{需求名称}/ 下；
2. 同步更新复盘文档中的图片引用路径为相对路径，例如：![](../../../附件/{需求名称}/image1.png)；
3. 若 附件/{需求名称}/ 文件夹不存在，先创建再移动。

命名规则：附件/ 下的子文件夹名称必须与对应的需求文件夹名称完全一致，确保两者可以直接对应。

触发时机：完成需求复盘文档撰写后，作为复盘工作流的最后一步执行。

9. 知识治理机制

确保知识库内容的高质量与一致性：

• 更新方式：半自动模式（系统建议 → 人工确认 → 写入）。
• 冲突处理优先级：产品专属规则 > 通用规则 > 默认值。
• 条目准入条件：任何新增的知识库条目必须引用至少 1 个实际案例作为支撑。

二、产品专属规则

📌 使用说明：本章节为占位模板。Fork 本仓库后，请根据你的产品实际情况替换以下内容。通用规则（第一章）无需修改，直接可用；本章节是你定制系统的核心配置区。

1. 产品背景

• 平台名称：{你的平台名称}
• 产品线：
  • {产品线 A}：{简要描述该产品线的核心职责}；
  • {产品线 B}：{简要描述该产品线的核心职责}。

提示：如果你的产品只有一条产品线，直接填写单个产品即可，删除多余条目。

2. 技术栈约束

• 前端组件库：{你的组件库名称和版本}
• 原型技术路线：参考 product-context/01-原型设计规范.md，根据你的组件库视觉风格定制 CSS 变量

提示：如果你的组件库可通过 CDN 引入（如 Element Plus、Ant Design Vue），可在原型规范中调整为 CDN 引入方案，无需坚持纯 CSS 手绘路线。

3. 业务术语

产品设计中涉及的专业词汇与业务概念，必须与业务术语表保持一致。 详见：product-context/05-业务术语表.md。

4. 目录结构与版本说明

根据你的版本管理方式组织目录。示例：

v{版本号}/
├── {产品线 A}/
│   ├── 需求A/
│   └── 需求B/
└── {产品线 B}/
    ├── 需求C/
    └── 需求D/

当前版本目录：

• v{x.x}/ — 当前活跃版本，所有正在进行的需求设计均在此目录下进行；
• v{x.x}/ — 规划版本。