通用数字产品 产品需求文档docs01-通用数字产品-PRD
该 DOCX 包含不完整的 Office 元数据关系，已使用兼容模式恢复正文和媒体。
通用数字产品 个人数字创作与成长网站
产品需求文档 PRD
0. 文档基本信息
| 项目 | 内容 |
|---|---|
| 项目名称 | 通用数字产品 个人数字创作与成长网站 |
| 产品简称 | 通用数字产品 |
| 文档类型 | 产品需求文档 PRD |
| 文档版本 | V1.0 |
| 产品阶段 | 第一版正式网站规划 |
| 产品所有者 | 网站创建者本人 |
| 主要语言 | 简体中文 |
| 目标终端 | 电脑网页、手机网页、平板网页 |
| 首版形态 | 可长期维护的个人内容网站 |
| 后续形态 | 内容管理端、PWA、移动客户端、实验室互动空间 |
| 数据归属 | 用户本人 |
| 部署原则 | 自有域名、自有服务器、可迁移、可备份、可回滚 |
| 核心限制 | 不依赖不可替换的收费平台，不使用强绑定的专属运行环境 |
| 文档状态 | 正式规划稿 |
一、什么是这份 PRD
PRD 是 Product Requirements Document 的缩写，即“产品需求文档”。
它主要回答以下问题：
这个网站为什么要做；
网站是为谁做的；
用户进入后能做什么；
第一版必须完成什么；
哪些功能暂时不做；
每个功能达到什么程度才算完成；
项目如何避免越做越复杂；
开发人员或 AI 应该按照什么边界执行。
本 PRD 只定义“网站要实现什么”，不会详细规定：
具体代码怎么写；
每个组件使用什么技术；
每个页面精确到多少像素；
服务器执行什么命令；
Nginx 如何配置。
这些内容分别放入：
01-PRD.md02-TECHNICAL-SOLUTION.md03-PAGE-INVENTORY.md04-DESIGN-SYSTEM.md05-DEPLOYMENT-MANUAL.md
二、项目背景
2.1 项目起因
网站创建者正在通过 AI 辅助完成网站、工具、本地大模型、多端应用及其他数字项目。
在这一过程中产生了大量内容：
建站过程记录；
AI 协作经验；
技术学习笔记；
开发踩坑；
成功和失败的实验；
已完成项目；
开发中的项目；
暂停或废弃的项目；
本地工具；
页面设计稿；
产品脑洞；
可以复用的资源；
对 AI 产品和软件开发的思考。
目前这些内容分散在：
聊天记录；
本地文件夹；
Word 文档；
Markdown 文件；
项目目录；
图片文件；
临时 Demo；
不同开发工具；
服务器网站；
未完成应用。
这导致以下问题：
很多内容做过以后难以查找；
项目做到一半容易转向其他想法；
完成过程没有形成清楚记录；
优秀的半成品没有合适的展示位置；
网站视觉尝试很多，但内容发布闭环不够顺畅；
网站、客户端、后台和实验空间容易同时开工；
AI 在长对话或上下文压缩后容易遗忘项目规则；
用户无法随时清楚判断“网站现在做到哪里”；
内容无法稳定地发布到自己的网站；
网站可能因平台、工具或技术变化而难以迁移。
因此，需要建设一个以内容为基础、能够长期维护的个人网站，先完成可靠的公开内容入口，再逐步承载项目、工具、实验和互动体验。
2.2 项目核心问题
通用数字产品 第一版需要解决的不是“如何做出最炫的网站”，而是下面四个核心问题。
问题一：个人内容没有统一归档入口
文章、项目、工具、实验和脑洞目前缺乏统一的信息结构。
问题二：内容制作与正式发布之间存在断层
内容已经存在，但从“写完”到“网站上线”的流程不够简单、稳定和清楚。
问题三：项目范围容易不断扩张
网站容易从个人博客扩展成：
互动实验室；
网站后台；
手机客户端；
用户社区；
多端应用；
本地 AI；
内容平台。
如果第一版同时开发这些内容，项目将很难真正完成。
问题四：网站需要长期自主可控
网站不能因为更换 AI、开发工具、服务器或平台而失去维护能力。
因此，项目需要满足：
源代码可获得；
内容可导出；
数据可备份；
服务器可更换；
域名可迁移；
项目结构有文档；
其他开发者或 AI 可以继续接手。
三、优秀案例参考与产品启发
本项目不直接复制某个个人网站，而是从不同优秀案例中分别提取适合 通用数字产品 的部分。
3.1 张鑫旭个人网站：内容分区与工具沉淀
张鑫旭个人网站将前端技术文章、生活创作、代码片段、在线资源、出版作品和在线工具分别组织，而不是把所有内容混在同一个博客列表中。
对 通用数字产品 的启发
通用数字产品 应当把不同性质的内容分别放入：
文章；
项目；
工具；
资源；
实验；
关于。
不能把所有内容都叫作“博客”。
3.2 Anthony Fu：个人身份与项目品牌结合
Anthony Fu 的网站首页先说明个人身份、当前工作和代表项目，再将访问者引导到 Blog、Projects、Talks 和 Sponsors 等不同内容入口；项目页面又按照当前重点、生态和工具类型继续分类。
对 通用数字产品 的启发
首页不需要展示所有内容。
首页主要回答：
通用数字产品 是什么；
网站主人是谁；
现在主要在做什么；
最值得查看的内容是什么；
用户应该从哪里继续浏览。
3.3 Maggie Appleton：数字花园与内容成熟度
Maggie Appleton 将成熟长文、尚未完全理解的笔记、设计模式、小内容碎片、演讲和阅读资料分别组织，并将数字花园描述为一组会随时间慢慢生长的不完美笔记、文章和想法。
对 通用数字产品 的启发
网站不应该只允许“完美完成品”出现。
但不同成熟程度的内容必须有明确标记，例如：
灵感；
整理中；
实验中；
可使用；
已完成；
已暂停；
已归档。
这样既能保留成长过程，也不会让访问者误以为所有内容都是正式产品。
3.4 Derek Sivers：个人网站作为长期数字总部
Derek Sivers 的网站将个人简介、当前状态、文章、书籍、阅读笔记、访谈和项目集中在自己的站点中，同时设置独立的 /now 页面说明当前正在做什么。
对 通用数字产品 的启发
通用数字产品 应成为个人数字内容的主要归档中心。
其他社交平台可以用来传播内容，但网站本身应保存：
正式原文；
项目说明；
创作记录；
资源索引；
当前工作状态；
长期个人档案。
3.5 谢益辉个人网站：开源项目与长期轨迹
谢益辉的网站将中英文介绍、博客和长期开发的软件项目集中在个人站点中，形成个人经历、开源成果和持续写作的长期档案。
对 通用数字产品 的启发
项目页面不应只有一张效果图，还应记录：
为什么开始；
使用了什么方法；
经历了什么问题；
当前做到什么程度；
是否仍在维护；
最终得到了什么经验。
3.6 通用数字产品 最终采用的组合
张鑫旭→ 学习内容、工具、项目分频道管理Anthony Fu→ 首页快速说明身份和重点成果Maggie Appleton→ 接纳实验、笔记和不完整想法Derek Sivers→ 自有域名作为长期数字内容中心谢益辉→ 保留项目历史、技术轨迹和长期档案
不采用的部分：
不复制其他网站的视觉外观；
不照搬栏目名称；
不复制文章内容；
不在第一版建设复杂商业系统；
不把整站制作成高成本的 3D 世界；
不为了显得专业而加入没有实际内容的栏目。
四、产品定义
4.1 产品名称
正式名称：
通用数字产品
产品描述名称：
通用数字产品 个人数字创作与成长网站
第一版产品定位：
一个用于记录 AI 协作、软件开发、个人项目、实验过程与成长轨迹的长期个人网站。
4.2 一句话产品定位
通用数字产品 是一个由非专业程序开发者自主建设的个人数字空间，用来公开记录 AI 协作、建站实践、项目实验、工具成果和从想法到落地的真实过程。
4.3 核心价值
对网站主人
统一保存个人内容；
形成长期成长档案；
降低发布内容的难度；
避免项目和素材散落；
展示真实项目能力；
建立个人品牌；
保持数据和技术自主权。
对普通访问者
阅读真实的 AI 协作和开发记录；
查看项目从想法到结果的过程；
获取有价值的工具、经验和资源；
了解非专业开发者如何使用 AI 完成项目；
从失败和踩坑中获得参考。
对招聘者或潜在合作方
快速了解网站主人是谁；
查看实际完成的项目；
了解产品思考能力；
了解 AI 协作和项目推进能力；
判断学习能力、执行能力和表达能力；
找到明确的联系入口。
4.4 产品核心原则
原则一：先可用，再丰富
第一版优先保证：
能打开；
能阅读；
能发布；
能维护；
能备份；
能迁移。
视觉特效不能阻碍这些基础能力。
原则二：内容优先
网站的长期价值来自：
文章；
项目；
工具；
经验；
成长记录。
视觉设计负责提升体验，但不能替代内容。
原则三：公开内容与内部资料分离
正式网站不能直接出现：
AI 指令；
密码；
服务器信息；
私人文件路径；
未经整理的聊天内容；
内部测试数据；
未确认事实。
原则四：允许不完美，但必须标记状态
实验和半成品可以公开，但必须明确告诉访问者：
当前状态；
是否可使用；
是否仍在维护；
是否存在已知问题。
原则五：自主可控
核心内容不得只能存在于某一家平台。
网站必须做到：
可导出；
可迁移；
可备份；
可恢复；
可由其他工具继续维护。
原则六：主站与实验体验分层
主站承担：
阅读；
导航；
搜索；
项目展示；
内容归档。
实验室空间承担：
品牌个性；
互动体验；
彩蛋；
创意展示。
不能让实验室互动成为访问文章和项目的唯一方式。
五、产品目标
5.1 第一版核心目标
G01：完成正式个人网站入口
访问者进入首页后，应能够快速明白：
网站叫什么；
网站记录什么；
网站主人主要在做什么；
可以查看哪些内容。
G02：建立内容发布闭环
网站主人应能够完成：
整理内容→ 添加到网站→ 本地预览→ 检查内容→ 发布上线→ 验证结果
不允许把“直接登录服务器修改正式文件”作为日常发布方式。
G03：建立文章归档系统
文章可以按照：
发布时间；
分类；
标签； -关键词；
进行浏览或查找。
第一版至少保证按时间浏览，分类和标签应保留完整数据结构。
G04：建立项目展示系统
每个项目不仅展示结果，还要展示：
项目背景；
解决的问题；
当前状态；
开发过程；
主要功能；
使用平台；
遇到的问题；
最终结果；
后续计划。
G05：适配手机访问
手机用户必须可以正常：
打开导航；
阅读文章；
浏览项目；
查看图片；
点击链接；
返回上一层；
联系网站主人。
G06：建立长期维护基础
项目必须具备：
清楚的目录；
完整文档；
版本记录；
备份机制；
上线流程；
回滚机制；
项目状态文件。
5.2 可量化目标
第一版正式上线时，应满足：
| 指标 | 目标 |
|---|---|
| 正式页面可访问率 | 100% |
| 主要导航有效率 | 100% |
| 手机端核心功能可用率 | 100% |
| 站内严重失效链接 | 0 |
| 未处理控制台严重错误 | 0 |
| 暴露密码、密钥、内部路径 | 0 |
| 正式内容中的测试占位符 | 0 |
| 核心内容依赖外部收费服务 | 0 |
| 日常发布需要直接修改线上文件 | 否 |
| 网站是否可整体备份 | 是 |
| 网站是否可迁移至其他服务器 | 是 |
| 是否存在明确回滚方式 | 是 |
| 代表页面 Lighthouse 目标 | 四项均不低于 90 |
| 访问重点内容的最大层级 | 原则上不超过 3 次点击 |
Lighthouse 指标为项目目标值，不代表所有设备和网络环境下都必须获得完全相同的分数。
六、非目标范围
以下内容不是第一版必须完成的功能。
6.1 V1 明确不做
面向公众的用户注册；
用户账号体系；
用户个人主页；
复杂评论社区；
在线支付；
会员订阅；
积分和等级；
实时聊天；
私信；
多人协同编辑；
电商商城；
广告系统；
全站 3D 场景；
原生 Android 应用；
原生 iOS 应用；
原生鸿蒙应用；
复杂云端内容管理系统；
AI 在线客服；
自动抓取并直接发布外部内容；
多语言完整站点；
面向公众开放的文件上传。
6.2 可以预留但不开发
开发时可以保留合理扩展能力，但不能为了未来功能提前建设大型系统。
可以预留：
评论接口位置；
登录入口位置；
管理后台接口；
API 层；
App 内容接口；
多语言字段；
内容搜索；
订阅；
实验室入口；
项目下载；
用户收藏。
“预留”表示数据结构和页面布局不堵死未来扩展，不表示第一版需要开发空壳系统。
七、目标用户
7.1 用户角色 A：网站主人
特征
网站唯一管理者；
不以手写代码作为主要工作方式；
使用 AI 协助规划、开发和维护；
希望所有内容和程序自主可控；
同时存在很多项目和想法；
需要清楚、低风险的操作流程；
更容易理解具象步骤，而不是抽象技术名词。
核心需求
快速发布文章；
管理项目状态；
清楚看到当前进度；
不直接操作生产环境；
修改失败后可以恢复；
更换 AI 后项目仍能继续；
内容不会被某个工具锁死；
可以逐步扩展至手机管理端。
最大痛点
技术概念不熟；
项目容易扩大；
AI 可能擅自改动；
文档散落；
发布流程复杂；
不容易判断开发是否真的完成。
7.2 用户角色 B：普通读者
访问目的
阅读 AI、网站、软件开发相关记录；
查看有趣的实验；
获取资源或工具；
了解项目过程；
阅读个人成长内容。
核心需求
首页能看懂；
内容分类清楚；
文章容易阅读；
手机体验良好；
不需要先注册；
不被复杂动画阻碍；
能找到相关文章或项目。
7.3 用户角色 C：招聘者或合作方
访问目的
判断网站主人的能力；
查看代表项目；
查看实际成果；
了解思考和执行过程；
获取联系方式。
核心需求
快速找到代表项目；
看懂项目由本人完成了什么；
分清已完成和未完成内容；
看到真实问题和解决过程；
获取简洁、可信的个人介绍；
可以方便联系。
7.4 用户角色 D：后续接手的开发者或 AI
访问内容
该角色不一定通过公开网页操作，而是通过项目文档和代码目录接手维护。
核心需求
看懂产品目标；
知道当前技术栈；
知道哪些文件可修改；
知道当前版本状态；
知道如何运行；
知道如何测试；
知道如何部署；
知道哪些内容禁止修改。
八、典型使用场景
8.1 场景一：读者第一次进入首页
打开首页→ 看到网站名称和一句话介绍→ 看到最新文章、代表项目和当前状态→ 选择感兴趣的内容→ 进入文章或项目详情→ 继续查看相关内容
成功标准：
不依赖说明教程；
十秒左右可以理解网站主题；
首屏不能只有抽象口号；
重要内容入口清楚。
8.2 场景二：招聘者查看项目
打开首页→ 点击代表项目→ 查看项目背景和结果→ 查看开发过程及本人承担部分→ 查看其他相关项目→ 进入关于页面→ 获取联系方式
成功标准：
项目状态明确；
不将概念图冒充成完成产品；
截图和文字能够证明实际成果；
联系入口容易找到。
8.3 场景三：读者通过分享链接进入文章
打开文章链接→ 阅读标题、摘要和发布时间→ 阅读正文→ 查看分类与标签→ 查看相关文章或项目→ 返回文章列表或首页
成功标准：
即使没有先访问首页，也能知道文章来自 通用数字产品；
页面有清楚导航；
手机阅读不需要横向缩放；
分享预览包含正确标题和摘要。
8.4 场景四：网站主人发布文章
创建文章→ 填写标题、摘要、分类和标签→ 编写正文→ 添加图片→ 本地预览→ 自动或人工检查→ 生成正式版本→ 发布上线→ 检查正式链接→ 记录本次更新
成功标准：
不需要直接修改服务器生产目录；
发布失败不会破坏现有网站；
正式发布前可以预览；
旧版本可以恢复；
发布记录可以查找。
8.5 场景五：网站主人更新项目状态
找到项目内容文件→ 修改项目状态→ 补充进展→ 更新截图或版本→ 预览→ 发布
项目状态更新后，应在：
项目列表；
项目详情；
首页相关区域；
保持一致。
九、产品信息架构
9.1 V1 正式结构
通用数字产品│├── 首页│├── 文章│ ├── 文章列表│ └── 文章详情│├── 项目│ ├── 项目列表│ └── 项目详情│├── 资源│├── 关于│└── 系统页面 ├── 404 ├── 错误状态 └── 无内容状态
9.2 内容分类建议
第一版文章不需要建立过多一级栏目。
推荐使用以下内容分类：
| 分类 | 用途 |
|---|---|
| 战斗日志 | 建站、开发和解决问题的真实过程 |
| AI 协作 | 使用不同 AI 完成任务的经验 |
| 技术学习 | 对技术概念的理解和学习记录 |
| 产品思考 | 产品、交互、商业和开发方法思考 |
| 脑洞实验 | 尚未完全验证的想法和试验 |
| 个人记录 | 与成长过程相关的正式内容 |
分类数量原则上控制在 4—8 个。
标签用于更细的主题，例如：
Astro本地大模型大型科技企业鸿蒙网站部署AI编程Codex产品设计移动端隐私开源
9.3 V1.5 扩展结构
在第一版稳定后，可以加入：
通用数字产品│├── 工具箱│ ├── 可使用│ ├── 测试中│ └── 已停止维护│├── 实验室│ ├── AI实验│ ├── 网页实验│ └── 本地应用实验│├── 当前状态│ └── 我现在正在做什么│├── 时间线│ └── 项目与成长记录│└── 搜索
9.4 V2 及以后
通用数字产品│├── 内容管理端├── 手机发布端├── 评论├── 登录├── 订阅├── PWA├── 移动客户端└── 沉浸式实验室空间
以上内容不能影响 V1 上线。
十、页面级产品要求
本章节只定义每个页面承担的产品职责，具体组件、布局和视觉参数将在《页面清单》和《设计规范》中展开。
10.1 首页
页面目标
让第一次访问的用户快速理解网站，并进入最重要的内容。
必须包含
网站名称；
一句话定位；
简短补充说明；
最新文章；
精选项目；
当前正在做的事情；
关于入口；
全局导航；
页脚；
联系或社交入口。
首页不应包含
大量无意义宣传文案；
超过正常阅读需要的复杂动画；
所有历史文章；
所有项目；
大量技术名词；
尚未开发却可以点击的假入口；
需要用户猜测的导航。
验收要求
用户不点击其他页面也能知道网站主题；
每个按钮都有真实去向；
手机首屏不被巨大装饰完全占据；
首页内容由真实数据生成，而不是重复手写。
10.2 文章列表页
页面目标
帮助用户浏览、发现和筛选文章。
必须包含
页面标题；
页面说明；
文章列表；
文章标题；
摘要；
发布时间；
分类；
标签；
无内容状态；
返回首页入口。
第一版功能
按发布时间倒序；
草稿不公开；
点击进入文章详情；
支持正常分页或合理的分批加载方式。
后续功能
搜索；
分类筛选；
标签筛选；
排序切换；
阅读状态。
10.3 文章详情页
页面目标
提供稳定、舒适、可信的长文阅读体验。
必须包含
标题；
摘要；
发布时间；
更新时间；
分类；
标签；
正文；
图片；
返回文章列表；
上一篇或下一篇；
相关文章；
分享信息；
页脚。
内容规则
文章标题只能有一个一级标题；
正文标题层级必须连续；
图片需要替代文字；
代码块不能导致手机横向溢出；
外部引用必须注明来源；
AI 生成内容必须经过作者审核；
不公开内部命令、密钥和私人路径。
10.4 项目列表页
页面目标
让用户快速了解项目类型、状态和价值。
每个项目卡片必须包含
项目名称；
一句话介绍；
项目封面；
项目类型；
当前状态；
主要平台；
更新时间；
查看详情入口。
项目状态
构思中开发中可体验已完成暂停已归档停止维护
“已完成”不能用于只有概念图或静态 Demo 的项目。
10.5 项目详情页
页面目标
完整展示项目从想法到结果的过程。
推荐内容结构
项目概览；
项目背景；
解决的问题；
目标用户；
核心功能；
使用平台；
开发过程；
关键决策；
主要困难；
解决方案；
当前成果；
图片或演示；
已知问题；
当前状态；
后续计划；
相关日志；
版本记录；
访问、下载或源码入口。
真实性要求
必须区分：
设计稿；
可点击原型；
前端 Demo；
本地可运行版本；
已部署网站；
已打包应用；
已上架应用。
不能统一描述为“项目已经完成”。
10.6 资源页
页面目标
整理和分享对项目真正有帮助的资源。
资源类型
开源项目；
网站模板；
学习资料；
设计素材；
开发工具；
本地软件；
文档；
自制资源。
每条资源建议包含
名称；
简介；
类型；
适用人群；
是否免费；
是否开源；
是否需要注册；
是否存在平台绑定；
外部链接；
添加时间；
使用备注。
资源发布规则
不直接转载未经授权的文件；
外部资源需要注明来源；
失效链接需要定期清理；
收费资源必须明确标记；
不把推荐描述成绝对安全或绝对可靠；
不上传包含恶意代码或版权风险的内容。
10.7 关于页面
页面目标
让访问者了解网站主人和建设 通用数字产品 的原因。
推荐内容
简短自我介绍；
为什么建立网站；
当前在做什么；
主要关注方向；
项目成长时间线；
使用 AI 的方式；
对自主可控的理解；
联系方式；
内容版权说明。
表达要求
真实；
不过度包装；
不自我贬低；
不将“不会写代码”表达成没有能力；
强调实际行动、学习过程和真实成果；
不公开过度私密的信息。
推荐表达方向：
我不是从传统程序开发路径开始，而是在持续使用 AI 建设真实项目的过程中，逐步理解产品、设计、技术、部署和维护之间的关系。
10.8 404 页面
页面目标
告诉用户页面不存在，并帮助用户继续浏览。
必须包含
明确的错误说明；
返回首页；
返回文章列表；
返回项目列表；
与品牌一致的视觉。
可以具有个性
可以使用“实验故障”“工业废料”“页面失踪”等 通用数字产品 品牌表达，但不能只显示玩笑而不提供解决入口。
十一、核心功能需求
优先级说明：
| 优先级 | 含义 |
|---|---|
| P0 | 缺少该功能不能正式上线 |
| P1 | 上线后应优先补充 |
| P2 | 体验增强 |
| P3 | 未来规划 |
FR-001 全局导航
优先级：P0
需求
网站所有公开页面应提供一致的主导航。
导航至少包含
首页；
文章；
项目；
资源；
关于。
验收
当前页面有可识别状态；
手机端导航可正常展开和关闭；
键盘可以操作；
不遮挡正文；
没有无效入口。
FR-002 文章内容管理
优先级：P0
需求
网站主人可以通过结构化内容文件创建、修改、预览和发布文章。
文章字段
| 字段 | 必填 | 说明 |
|---|---|---|
| title | 是 | 文章标题 |
| description | 是 | 摘要 |
| publishDate | 是 | 首次发布时间 |
| updatedDate | 否 | 更新时间 |
| category | 是 | 主分类 |
| tags | 否 | 标签 |
| cover | 否 | 封面图片 |
| draft | 是 | 是否草稿 |
| featured | 否 | 是否精选 |
| author | 否 | 默认网站主人 |
| relatedProjects | 否 | 关联项目 |
| content | 是 | 正文 |
验收
缺少必填字段时不能静默发布；
草稿不会出现在正式网站；
日期格式错误时应提示；
内容文件损坏时应定位问题；
文章能够本地预览。
FR-003 项目内容管理
优先级：P0
项目字段
| 字段 | 必填 | 说明 |
|---|---|---|
| title | 是 | 项目名称 |
| description | 是 | 一句话介绍 |
| status | 是 | 项目状态 |
| projectType | 是 | 网站、工具、应用等 |
| platforms | 否 | Web、Windows、Android 等 |
| startDate | 否 | 开始时间 |
| updatedDate | 是 | 最近更新 |
| cover | 否 | 封面 |
| screenshots | 否 | 截图 |
| featured | 否 | 是否精选 |
| version | 否 | 当前版本 |
| demoUrl | 否 | 演示地址 |
| sourceUrl | 否 | 源码地址 |
| content | 是 | 项目详细说明 |
验收
项目状态在列表和详情页一致；
项目链接失效时不应造成页面错误；
没有截图时提供正常占位状态；
暂停或停止维护项目有明确说明。
FR-004 内容分类和标签
优先级：P0/P1
第一版必须保存分类和标签数据。
P0：
正确显示分类；
正确显示标签；
分类和标签名称统一；
禁止同义词重复。
P1：
点击分类查看相关文章；
点击标签查看相关文章；
支持筛选。
FR-005 搜索
优先级：P1
搜索范围
文章标题；
文章摘要；
分类；
标签；
项目名称；
项目简介。
验收
中文关键词可以匹配；
没有结果时提供说明；
搜索不会发送私人内容到不明第三方；
搜索失败不影响普通浏览。
FR-006 内容状态
优先级：P0
文章状态
草稿；
已发布；
已更新；
已归档。
项目状态
构思中；
开发中；
可体验；
已完成；
暂停；
已归档；
停止维护。
资源状态
可用；
待验证；
已失效；
已归档。
不同内容类型不能共用一套含义模糊的状态。
FR-007 本地预览
优先级：P0
需求
正式发布前，网站主人必须能够看到接近正式网站的预览结果。
验收
预览不影响线上网站；
草稿可以预览；
图片和链接可以检查；
预览和正式构建使用相同内容来源；
预览失败时提供可理解的错误提示。
FR-008 发布与回滚
优先级：P0
发布要求
本地检查→ 正式构建→ 上传待发布目录→ 验证→ 切换版本→ 线上检查
回滚要求
保留上一正式版本；
发布失败不得破坏当前网站；
可以恢复到上一版本；
每次发布有版本标识；
每次发布有变更记录。
FR-009 响应式适配
优先级：P0
目标终端
360px 左右窄屏手机；
常见 Android 和 HarmonyOS 手机；
平板；
普通笔记本；
1920×1080 桌面显示器。
验收
页面不出现整体横向滚动；
正文不被遮挡；
导航可以操作；
按钮点击区域足够；
图片不严重变形；
代码块可以独立横向滚动；
文字无需放大才能阅读。
FR-010 SEO 基础能力
优先级：P0
必须包含
每页独立标题；
每页独立描述；
canonical 地址；
Open Graph 信息；
网站图标；
sitemap；
robots；
规范标题层级；
文章结构化信息；
图片替代文字；
正确的正式域名配置。
验收
不出现大量页面共用同一个标题；
草稿不进入 sitemap；
404 不进入搜索索引；
分享文章时能显示正确标题和摘要。
FR-011 RSS
优先级：P1
提供文章更新订阅。
验收
RSS 只包含已发布内容；
标题、摘要、时间和链接正确；
正式域名正确；
内容更新后 RSS 同步更新。
FR-012 联系入口
优先级：P0
需求
网站提供安全、明确的联系入口。
可选方式
公开邮箱；
GitHub；
其他公开社交平台；
联系表单。
第一版优先使用简单、可控的公开联系方式，不急于开发复杂表单后端。
安全要求
不公开私人手机号；
不暴露管理账号；
联系方式由网站主人确认后发布；
外部链接明确提示跳转。
FR-013 访问统计
优先级：P2
访问统计不是上线阻塞项。
如后续增加，应优先满足：
隐私友好；
数据最小化；
不影响页面性能；
可以移除；
不成为网站运行的必要条件；
明确说明是否使用 Cookie。
FR-014 评论
优先级：P3
第一版不开放评论。
后续评论系统必须满足：
垃圾信息处理；
内容审核；
删除机制；
隐私政策；
用户身份说明；
数据导出；
数据备份；
不强绑定单一外部平台。
十二、内容规范
12.1 内容类型
网站正式内容分为：
文章项目资源关于信息系统文案
实验、工具和脑洞在 V1 可以分别作为文章分类或项目类型存在，不急于增加一级页面。
12.2 正式内容与内部内容分离
可以公开
整理后的成长记录；
开发经验；
错误分析；
项目截图；
已确认的技术信息；
可公开的 AI 协作方法；
自制工具；
合法授权资源。
禁止公开
密码；
API Key；
SSH 私钥；
服务器内部账号；
真实身份证件；
精确家庭地址；
私人电话号码；
未处理的聊天记录；
他人的私人信息；
未授权文件；
可能造成安全风险的配置；
含有本地用户名的绝对路径；
测试环境敏感数据。
12.3 AI 内容发布规则
AI 可以帮助：
整理结构；
修改语句；
生成摘要；
检查错别字；
提供标题建议；
转换格式；
检查文章完整性。
AI 不能自动决定：
是否正式发布；
是否公开私人经历；
是否公开服务器信息；
是否将未经验证的事实写成结论；
是否使用存在版权风险的内容。
正式发布前必须由网站主人完成最终审核。
12.4 内容真实性分级
项目内容应使用以下标记：
| 标记 | 含义 |
|---|---|
| 想法 | 只有概念，尚未开发 |
| 设计 | 已有结构或界面方案 |
| 原型 | 可以演示流程，但不是正式产品 |
| 本地运行 | 仅在本地设备运行 |
| 已部署 | 已在服务器或测试环境运行 |
| 可下载 | 已提供安装包 |
| 已上架 | 已通过正式应用市场发布 |
| 停止维护 | 不再继续更新 |
12.5 图片规范
每张正式图片应尽量具备：
明确文件名；
合理尺寸；
压缩版本；
替代文字；
来源记录；
使用权限说明；
与内容匹配的比例。
禁止使用：
最终版.png最新最终版2.png未命名-1.jpg123456.png
推荐：
通用数字产品-homepage-hero.webplocal-ai-mobile-interface.webpastro-deployment-error-example.webp
十三、用户体验要求
13.1 清楚优先
任何页面首先要让用户知道：
我在哪里；
这里有什么；
我能做什么；
下一步可以去哪里。
13.2 克制使用动画
动画只能用于：
页面状态变化；
导航展开；
轻微悬停反馈；
品牌氛围；
重点内容提示；
特殊实验页面。
禁止：
动画阻塞阅读；
所有元素持续漂浮；
大面积自动移动导致注意力分散；
用户无法关闭的声音；
长时间入场动画；
手机端高性能消耗特效。
13.3 视觉层级
页面需要明确区分：
页面标题；
内容标题；
正文；
辅助信息；
操作按钮；
标签；
状态；
警告；
外部链接。
不能仅依靠颜色表达重要状态。
13.4 阅读体验
长文章应满足：
正文宽度适中；
行距舒适；
段落不拥挤；
标题层级清楚；
图片可辨认；
代码块可阅读；
手机端字号合理；
不使用大面积低对比度文字。
13.5 品牌氛围
通用数字产品 的第一版视觉关键词：
干净克制治愈轻微梦幻具有个人感有探索感成熟不幼稚留白充足
可以保留：
星光；
月光紫；
柔和渐变；
轻微磨砂；
扁平立体感；
小型实验室符号；
蒸汽机器人品牌角色。
但不能让这些元素破坏：
可读性；
页面速度；
移动端适配；
内容层级。
十四、非功能需求
NFR-001 性能
首页不得加载大量无用资源；
普通文章阅读不依赖复杂 JavaScript；
图片使用合理格式和尺寸；
非首屏图片可延迟加载；
动画不能明显造成卡顿；
代表页面 Lighthouse Performance 目标不低于 90。
NFR-002 可访问性
支持键盘操作；
图片有替代文字；
表单有明确标签；
焦点状态可见；
文字和背景对比清楚；
不使用闪烁动画；
支持用户的减少动态效果设置；
代表页面 Accessibility 目标不低于 90。
NFR-003 浏览器兼容
优先支持：
最新稳定版 Chrome；
最新稳定版 Edge；
常见手机浏览器；
HarmonyOS 系统自带浏览器的基本浏览能力；
Safari 的常规网页浏览。
不要求为了非常旧的浏览器牺牲整体维护性。
NFR-004 安全
不在前端代码保存秘密；
不提交真实密钥；
生产服务器不使用个人主账号作为日常部署账号；
网站目录使用最小权限；
部署账号不能随意修改历史版本；
所有公开访问使用 HTTPS；
外部输入在进入系统前进行校验；
上传功能未完成安全设计前不得开放。
NFR-005 可维护性
页面共用组件；
样式使用统一变量；
内容与页面结构分离；
项目状态有文档；
变更有记录；
AI 修改有边界；
不随意增加用途重复的依赖；
不能把核心逻辑散落在大量临时脚本中。
NFR-006 可迁移性
网站更换服务器时，应能够通过以下资料完成恢复：
源代码；
内容文件；
静态资源；
配置模板；
构建说明；
部署说明；
域名配置说明；
备份文件。
核心内容不得只能从某个平台后台手动复制。
NFR-007 可恢复性
保留最近正式版本；
发布失败可以回滚；
删除内容前有备份；
备份可实际恢复；
网站源代码与线上构建文件分开管理；
不直接在生产目录开发。
十五、发布流程需求
15.1 标准发布流程
新建或修改内容 ↓本地预览 ↓内容检查 ↓代码与构建检查 ↓生成正式构建 ↓上传待发布目录 ↓服务器侧验证 ↓创建新版本目录 ↓切换正式版本 ↓线上回归检查 ↓更新项目状态和变更记录
15.2 发布前检查
每次发布前至少确认：
标题正确；
日期正确；
图片正常；
链接正常；
草稿未公开；
没有敏感信息；
手机端基本正常；
构建成功；
本次修改范围明确；
有可回滚版本。
15.3 发布失败处理
出现以下情况时，停止切换正式版本：
构建失败；
关键页面打不开；
首页空白；
样式资源缺失；
文章路径错误；
HTTPS 异常；
发现敏感信息；
版本无法回滚。
十六、项目验收标准
16.1 产品验收
网站定位清楚；
V1 页面完整；
首页能够说明网站主题；
文章可以正常浏览；
项目可以正常浏览；
资源和关于页面有正式内容；
404 页面有效；
所有导航可用；
没有假按钮；
没有明显占位内容。
16.2 内容验收
至少存在正式首页文案；
至少存在正式关于内容；
至少存在一篇正式文章；
至少存在一个正式项目；
所有公开内容经过人工审核；
草稿不会公开；
项目状态真实；
图片来源和使用权限清楚。
最低内容数量只是上线测试底线，不代表网站长期内容目标。
16.3 技术结果验收
开发检查通过；
类型检查通过；
正式构建通过；
所有正式路由可访问；
404 正常；
HTTPS 正常；
手机端无严重错位；
控制台无严重错误；
没有敏感信息泄漏；
sitemap 和 robots 正常；
能完成备份和回滚。
16.4 维护验收
一个不了解此前聊天内容的开发者或 AI，仅阅读项目文档后，应能够知道：
项目是什么；
当前做到哪里；
如何启动；
如何添加文章；
如何添加项目；
如何检查；
如何构建；
如何部署；
如何回滚；
哪些内容禁止修改。
十七、项目完成定义
只有同时满足以下条件，才能将 V1 标记为“正式完成”：
产品范围完成+正式内容完成+页面功能完成+手机适配完成+测试通过+正式域名上线+HTTPS正常+发布流程可用+备份与回滚可用+项目文档完整
以下情况不能称为“网站已经完成”：
只有设计图；
只有首页；
只有本地 Demo；
页面可以看但不能构建；
电脑可用但手机无法操作；
可以上线但无法更新；
可以更新但没有回滚；
依赖某个临时开发平台才能运行；
没有正式内容；
大量按钮尚未实现。
十八、版本规划
V1.0：正式内容网站
目标：
先建立稳定、清晰、可发布、可维护的个人网站。
包含：
首页；
文章列表与详情；
项目列表与详情；
资源；
关于；
404；
手机适配；
SEO；
正式部署；
发布和回滚流程。
V1.1：内容发现增强
包含：
分类页；
标签页；
搜索；
RSS；
阅读进度；
文章目录；
相关文章；
项目关联日志。
V1.2：个人内容管理增强
目标：
降低网站主人发布内容的操作难度。
可能包含：
本地内容管理界面；
文章新建和编辑；
项目状态管理；
图片选择；
本地预览；
发布前检查；
一键生成发布包；
发布记录。
该版本优先与已有 通用数字产品 Studio 本地项目进行评估，而不是重复开发另一套后台。
V2.0：跨设备管理
可能包含：
PWA；
手机端管理页面；
局域网发布；
安全的远程发布；
内容 API；
多设备同步。
必须先完成权限、身份验证和数据安全设计。
V3.0：实验室世界
可能包含：
互动实验室入口；
实验室地图；
维修台；
工业废料区；
项目展厅；
蒸汽机器人角色；
隐藏彩蛋；
互动故事。
实验室世界应作为可选体验存在。
即使实验室功能损坏，用户仍应可以通过普通导航阅读文章和项目。
十九、主要风险与应对策略
风险一：范围再次扩大
表现
同时增加网站、后台、App、AI 和社区；
V1 未上线就开始 V2；
每看到一个案例就增加一个栏目。
应对
严格执行版本边界；
新想法进入 Backlog；
P0 未完成前不开发 P2、P3；
每个开发任务只解决一个问题。
风险二：视觉设计不断推翻
表现
频繁更换整体风格；
为了单张参考图重构整个页面；
追求效果图与网页完全一致。
应对
先完成设计规范；
先制作组件，再组装页面；
第一版限定一套主风格；
新风格只能进入实验页或后续版本。
风险三：AI 擅自扩大修改范围
表现
修改无关文件；
更换技术栈；
删除已有功能；
增加不必要依赖；
修改服务器配置。
应对
每次任务明确：
本次目标；
允许修改的文件；
禁止事项；
测试要求；
完成后暂停；
更新项目状态。
风险四：内容很多但无法发布
表现
文章一直停留在聊天记录；
发布步骤太复杂；
必须操作大量命令；
手机无法发布。
应对
V1 先形成稳定发布流程；
V1.2 建设本地内容管理工具；
建立文章模板；
建立发布前自动检查；
不直接编辑线上文件。
风险五：平台绑定
表现
网站依赖某一家平台专属数据库；
导出后无法运行；
核心内容只能在平台后台访问；
取消付费后功能消失。
应对
核心内容保存为通用文件；
使用可替换技术；
保留完整源代码；
定期测试备份恢复；
外部服务不得成为核心阅读功能的必要条件。
风险六：公开敏感信息
表现
截图包含服务器 IP、账号或密钥；
文章粘贴完整终端记录；
项目文件中包含环境变量；
AI 将内部聊天直接整理为文章。
应对
发布前执行敏感信息检查；
图片发布前检查并打码；
环境变量使用示例文件；
正式内容必须人工审核。
风险七：项目状态失真
表现
原型被写成正式应用；
静态界面被写成完整客户端；
已暂停项目仍显示“开发中”；
下载链接失效。
应对
统一项目状态；
每次更新填写更新时间；
定期检查外部链接；
明确区分设计、原型、本地运行、部署和上架。
二十、默认产品决策
为避免开发阶段反复询问，第一版默认采用以下决策：
| 问题 | V1 默认决定 |
|---|---|
| 网站语言 | 简体中文 |
| 是否开放注册 | 否 |
| 是否开放评论 | 否 |
| 是否建设在线后台 | 否 |
| 是否支持手机浏览 | 是，P0 |
| 是否支持手机发布 | V1 不做，V1.2/V2 规划 |
| 是否建设全站 3D | 否 |
| 是否保留实验室概念 | 是，但不影响主站 |
| 是否使用正式域名 | 是 |
| 是否允许外部收费平台成为核心依赖 | 否 |
| 是否公开源代码 | 由网站主人逐项目决定 |
| 是否展示失败项目 | 可以，但必须标记状态 |
| 是否允许 AI 自动发布 | 否 |
| 是否要求发布前预览 | 是 |
| 是否必须支持回滚 | 是 |
| 是否保留旧版本 | 是 |
| 是否允许直接修改线上正式目录 | 否 |
| 网站核心内容保存位置 | 自有项目和备份中 |
二十一、AI 与开发者执行规则
21.1 开发前必须阅读
PRD；
技术方案；
页面清单；
设计规范；
项目状态；
当前任务说明。
21.2 每次任务必须明确
任务目标允许修改范围禁止修改范围输入资料输出结果测试方式验收条件是否更新文档完成后是否暂停
21.3 禁止行为
未经允许更换技术栈；
未经允许重构整个项目；
未经允许删除已有功能；
未经允许修改生产服务器；
未经允许加入收费服务；
未经允许加入平台专属能力；
为了消除报错而关闭检查；
用假数据掩盖功能未完成；
将测试通过描述为功能已完整；
未验证便声称已经上线；
将设计稿描述为正式应用。
21.4 每次任务完成报告
必须报告：
完成了什么；
修改了哪些文件；
为什么这样修改；
是否增加依赖；
是否修改配置；
运行了哪些检查；
检查结果；
是否存在遗留问题；
是否可以回滚；
下一步建议；
是否更新项目状态文件。
二十二、待后续文档细化的内容
本 PRD 确认产品方向和需求边界。
以下内容将在后续文档中展开。
《技术方案》
负责说明：
技术栈；
项目架构；
目录结构；
内容模型；
构建方式；
数据流；
测试体系；
安全设计；
发布架构；
未来后台和 App 如何连接。
《页面清单》
负责说明：
每一个页面；
页面路由；
页面模块；
页面入口和出口；
正常状态；
空状态；
错误状态；
手机端变化；
页面验收标准。
《设计规范》
负责说明：
品牌风格；
色彩；
字体；
圆角；
阴影；
间距；
栅格；
按钮；
卡片；
动效；
响应式规则；
无障碍要求。
《部署手册》
负责说明：
本地构建；
发布包；
服务器目录；
权限；
Nginx；
HTTPS；
DNS；
上传；
版本切换；
回滚；
日志；
备份；
故障处理。
二十三、最终产品愿景
通用数字产品 不只是一个展示最终成果的网站。
它应当成为一个可以长期生长的个人数字空间：
完整作品可以被看见；
半成品可以被正确归档；
失败过程可以转化为经验；
开发记录可以形成文章；
工具可以持续迭代；
脑洞可以先被保存；
网站主人能够清楚看到自己的成长；
访问者能够从真实过程获得帮助；
所有内容和技术始终掌握在网站主人手中。
第一版最重要的目标不是证明网站能够做得多复杂，而是证明：
通用数字产品 已经拥有一个真正可以持续写、持续发布、持续维护、持续扩展，并且不会轻易失去控制的数字家园。