# gray-order

**Repository Path**: ereflect/gray-order

## Basic Information

- **Project Name**: gray-order
- **Description**: 灰序计划
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 0
- **Created**: 2026-01-14
- **Last Updated**: 2026-01-15

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

## 灰序计划（Gray Order）

一个基于《诡秘之主》世界观的占卜 / 仪式 / 解读系统，前端使用 Vue，后端使用 NestJS，持久层为 MySQL。

### 文档体系总览

- **规则宇宙（规则 & 世界观）**：参见 `doc/` 目录，按照 `00_canon` → `05_evolution` 分层管理世界观、公理、协议、Prompt 设计等高优先级规则。
- **产品 & 需求文档**：参见 `docs/gray-order-doc.md`，描述产品目标、用户体验、功能需求与 TODO。

### 推荐阅读顺序

1. `doc/README.md`：快速了解规则层级与约束强度。
2. `doc/00_canon/`：世界观宪章与术语表（高优先级、慎改）。
3. `docs/gray-order-doc.md`：具体产品形态与 MVP 范围。

---

## 详细产品 Doc 概览

本仓库根目录的 README 只保留产品文档的一份“快捷视图”，完整内容建议在 `docs/gray-order-doc.md` 中维护。

本产品文档按照以下类型组织：

- **产品设计（type: ProductDesign）**
- **需求（type: Requirement）**
- **世界观（type: Lore）**
- **提示词（type: Prompt）**
- **TODO（type: TODO）**

---

## 一、产品设计（type: ProductDesign）

### 1. 项目概述

- **项目名称 / 代号**：灰序计划
- **本质定义**：基于《诡秘之主》世界观的占卜/解读系统，通过大模型解读与定制化 UI 仪式感，提供沉浸式占卜体验。

### 2. 产品目标

- **短期目标（MVP）**
  - 提供一次完整的“占卜 → 解读 → 历史查看”闭环体验。
  - 让用户感受到与某个“神秘存在”建立短暂连接，获得指引或启示。

- **中期目标**
  - 支持多种占卜主题与模式（情感、工作、自我探索、每日启示等）。
  - 支持个性化偏好（风格、途径倾向）。

- **长期目标**
  - 打造围绕“诡秘式仪式 & 解读”的内容/仪式系统，可扩展为社区或长期陪伴产品。

### 3. 用户画像

- **核心用户**
  - 喜欢《诡秘之主》/奇幻神秘题材的用户。
  - 接受占卜、塔罗、星盘等形式的半信半疑型用户。
  - 追求“情绪价值 + 仪式感”的年轻用户（18–35 岁）。

- **典型需求**
  - 在迷茫/焦虑时，获得“被倾听 + 被指引”的感觉。
  - 体验“祈祷”“仪式”“神秘存在回应我”的叙事。

### 4. 核心体验描述（典型一次占卜）

1. **进入“仪式大厅”**
   暗色系 UI，带有蜡烛、符号、星空等元素，展示欢迎词与简短世界观/身份提示。
2. **选择主题**
   如：情感 / 工作 / 自我 / 混沌启示。
3. **提出问题**
   用户输入自由问题，或从预设问题模板中选择。
4. **进行仪式交互**
   短暂的仪式动画/互动（点击“祈祷”、拖动符号、选择象征牌面等）。
5. **获得解读**
   文本以诡秘风格呈现：有标题、有正文、有隐喻式建议。
6. **结束与回顾**
   用户可以收藏/标注这次解读，并在“历史记录”中查看，选填“有共鸣/无感”等反馈。

### 5. 产品调性 & 风格

- **整体调性**：半庄严、半戏谑，参考原著风格，既尊重神秘，又保持一点人间烟火。
- **语言特点**：使用隐喻、象征、序列相关概念表达，避免直给“硬性现实建议”；避免过于鸡汤或过于冷淡。
- **UI 风格关键词**：暗金、星空、仪式、纹章、烛光、纸张质感、古书/手稿感。

---

## 二、需求（type: Requirement）

### 1. 功能范围（MVP）

- **R1：占卜流程闭环**
  用户可以完成一次完整流程：进入 → 选主题 → 提问 → 仪式 → 解读 → 历史记录。

- **R2：简单用户体系**
  支持基础登录方式（可从“匿名 + 本地存储”开始，后续扩展账号体系），用户占卜记录可关联到某个标识。

- **R3：历史记录**
  用户可以查看过去占卜记录列表，查看详情（原问题、解读内容、时间等）。

- **R4：世界观风格解读**
  所有解读输出需满足世界观与提示词规则（见 Lore + Prompt 部分）。

### 2. 功能细项

- **占卜主题管理**
  - 预设主题：情感 / 工作 / 自我 / 混沌启示。
  - 后端保存主题配置：名称、描述、对应的 Prompt 模板 ID。

- **问题输入**
  - 文本输入框（限定长度）。
  - 可选预设问题列表（按主题定制）。

- **解读展示**
  - 结构化展示：
    - 标题（简短启示）
    - 正文（主解读段落）
    - 补充建议（可选）。

- **反馈机制（可选）**
  - 用户可选择：有共鸣 / 一般 / 无感。
  - 后期可用于 Prompt 调优。

### 3. 用户流程（MVP）

- **新用户路径**
  1. 进入首页 → 阅读简短世界观与引导。
  2. 选择主题。
  3. 输入问题。
  4. 进行仪式交互。
  5. 展示解读结果。
  6. 提示“可以在历史中找到这次解读”。

- **老用户路径**
  1. 打开即看到“快速开始占卜 + 历史记录入口”。
  2. 可直接继续上次主题或进入历史记录。

### 4. 非功能需求

- **性能**：一次占卜请求响应时间在可接受范围（例如 < 5–8 秒）。
- **稳定性**：大模型调用失败时有友好降级文案与重试机制。
- **可扩展性**：模块设计上易于增加新主题、新场景、新 Prompt 模板。

---

## 三、世界观（type: Lore）

### 1. 世界观边界

- **参考来源**：灵感来源于《诡秘之主》的世界观、叙事风格、仪式氛围。
- **使用原则**：
  - 使用“风格、氛围、象征体系”，避免一比一复刻原著具体设定。
  - 对专有名词、具体神明名称、组织名等做适度改名与重构。
- **自定义设定**：世界中存在“序列”“途径”“隐秘存在”，但具体名称与原作区别开。

### 2. 用户身份设定

- **默认设定**：用户是“向某种隐秘存在祈祷的凡人/准非凡者”。
- **对交互的影响**：
  - 文案称呼：如“祈祷者”“旅人”“迷途者”等。
  - 提示词中：将用户描述为“在迷雾中寻求指引的人”。

### 3. 仪式与占卜设定

- **仪式结构**：净化/准备 → 注视/冥想 → 祈祷 → 回响/回应。
- **前端映射**：
  - 净化：进入仪式界面时的动画或淡入。
  - 注视：用户阅读某段引导文案的短暂停留。
  - 祈祷：点击“祈祷”按钮或类似行动。
  - 回响：大模型解读结果呈现。

### 4. 语言与符号

- **语言风格**：使用星辰、雾气、门扉、阶梯、牌面等意象，比喻状态与可能性；适度引用“序列”“途径”等抽象概念。
- **禁止或谨慎使用**：避免使用原作中具有强 IP 绑定的名称（真实神名、完整组织名等）。

---

## 四、提示词（type: Prompt）

> 本节为 LLM 提示词草案，后续可拆分为配置或数据库记录。

### 1. 系统角色 Prompt（示例草案）

你是一位栖身于迷雾之后的“解读者”，熟悉象征、隐喻与命运的隐线。
你不会以现实世界的专业身份出现（例如律师、医生、理财师），而是以“神秘存在的回响”去回应。
你的语言风格偏向《诡秘之主》那种：带有仪式感、象征性和一点点戏谑，但依然对提问者保持尊重。
在回答时，你可以使用星辰、雾气、门扉、阶梯、牌面等意象，去暗示可能性、风险与选择。
同时，你需要给出对现实生活有一定参考价值的建议，但不要用命令式语气，而是以“可能的路径”“可以尝试的做法”来表达。
回答时，请使用中文。

### 2. 场景 Prompt：普通占卜（示例草案）

- **输入信息**：用户问题文本 + 主题（情感 / 工作 / 自我 / 混沌启示）。
- **输出结构建议**：
  1. 标题：一句话启示。
  2. 主解读：2–4 段诡秘风格描述。
  3. 现实建议：1–3 条可参考的行动方向。

提示结构示意：
使用下列结构组织回答：
1. 先给出一句“启示标题”，如一张牌面或一个画面。
2. 然后用 2–4 段描述，解释这个画面与提问者问题之间的联系，可以从过去、当下、潜在影响、可能的结果等角度进行。
3. 最后，用 1–3 个建议，总结提问者在现实中可以考虑的行动方向。
在解读过程中，请结合当前主题（例如情感、工作、自我），使用更贴近该主题的象征。

### 3. 场景 Prompt：每日启示（示例草案）

- **目标**：提供轻量级“今日启示”。
- **输出结构建议**：
  - 标题：今日画面/象征。
  - 短文：1–2 段说明。
  - 提示：一句现实提醒。

提示结构示意：
你现在要给出一条“每日启示”。
不需要详细分析，重点是：用一个画面或象征，暗示今天需要注意的心态或方向。
先给出画面/象征的名字，再用 1–2 段解释这个象征的含义，最后用一句短语给出现实提醒。

---

## 五、TODO（type: TODO）

### 1. 总目标（S 级）

- **[TODO][S] 完成可用 MVP 闭环**
  从用户进入页面 → 完成占卜 → 看解读 → 在历史中回看。

### 2. 文档 & 产品侧 TODO

- **[TODO][A] 完成产品设计文档**
  - 补充和确认：产品目标 & 用户画像、典型占卜流程具体文案、产品调性 & UI 风格关键词。

- **[TODO][A] 完成世界观设定文档**
  - 明确：世界观使用边界（沿用 vs 改名）、用户身份设定、仪式流程 & 前端映射。

- **[TODO][A] 完成需求文档（MVP）**
  - 列出并冻结：MVP 功能清单（R1–R4）、用户流程（新用户/老用户）、每个功能的验收条件。

### 3. 技术实现 TODO（Vue + NestJS + MySQL）

- **[TODO][A] 前端框架搭建**
  - 搭建 Vue3 + TS + Router + 状态管理。
  - 建立页面骨架：仪式页（Ritual）、解读页（Reading）、历史记录页（History）、配置/Profile 页。

- **[TODO][A] 后端框架搭建**
  - NestJS 项目初始化。
  - 创建模块：`AuthModule`、`UserModule`、`DivinationModule`、`PromptModule`、`HistoryModule`。

- **[TODO][A] 大模型服务封装**
  - 实现 `LLMService`：
    - 输入：用户问题 + 主题 + 世界观上下文 + Prompt 模板。
    - 输出：结构化结果（标题/正文/建议）。

- **[TODO][A] 数据库设计**
  - 设计并实现核心表：
    - `users`（用户信息/标识）。
    - `divinations`（问题、主题、返回结果 JSON、时间等）。
    - `prompt_templates`（场景、内容、版本等）。

### 4. 提示词系统 TODO

- **[TODO][B] 定稿系统 Prompt 文案**
  在当前草稿基础上，打磨语气与约束。

- **[TODO][B] 定稿场景 Prompt 模板**
  普通占卜模板、每日启示模板。

- **[TODO][B] Prompt 管理接口 & 简易后台（可后置）**
  后端提供 Prompt 增删改查接口，前端提供简单配置页面（用于内部调整与测试）。