INDEPENDENT PRACTICE / 2026 — ONGOING
FROM DESIGN
TO REALITY.
从设计作品到个人品牌
我如何用 GPT + Codex，从 0 到 1 搭建自己的作品集网站。
一次从产品构思、体验设计到 AI 协作开发与网站部署的完整实践。
作品之外，建立自己的表达。
不止展示完成了什么，也让人看见我如何思考。
搭建个人网站，最初是为了求职展示。随着项目盘点展开，它逐渐成为组织设计经验、表达专业判断和建立个人品牌的载体。
我需要决定项目的优先级、阅读路径与信息层级，让浏览者在有限时间内理解项目背景、设计贡献和实际价值。
这也是一次把设计交付向前推进的尝试：从定义体验，走到组件、代码、调试与部署环境。
先整理故事，再组织页面。
定位与架构
围绕求职展示与个人品牌，组织首页、项目案例、实验与关于。
项目与证据
以 NIO Power Map 为核心，整理 Athena、OCC 的问题、过程与成果。
资产与规范
通过 Asset Master List 核对素材，建立深色视觉体系、MiSans 字体与统一间距。
探索与取舍
分析视觉参考，探索设计时空首页与 3D 场景；构想与已实现页面分别呈现。
让讨论，进入实现。
GPT把问题说清楚。
产品需求分析 · 网站信息架构 · 项目内容规划
设计讨论 · 开发指令整理 · 技术问题分析
Codex把想法做出来。
本地项目读取 · Next.js 页面开发 · React 组件实现
TypeScript 修改 · 视觉调整 · 功能调试与修复
人工判断，贯穿协作闭环。
- 01需求提出
- 02GPT 分析与规划
- 03形成开发指令
- 04Codex 理解代码
- 05本地开发
- 06浏览器预览
- 07人工设计验收
- 08持续迭代
各司其职，才是完整的系统。
设计、开发、部署与数据服务，是相互连接的不同层次。
Figma → 图片素材 → 网站内容
设计稿与素材管理，先整理内容，再进入页面
GPT ↔ Codex → 本地代码
GPT：需求分析、设计讨论与指令整理；Codex：理解项目、开发与调试
Next.js + React + TypeScript + Tailwind CSS
应用框架 / 页面组件 / 类型管理 / 样式实现
Git → GitHub
本地版本管理与远程代码托管
GitHub → Vercel ／ 腾讯云 EdgeOne Pages
Vercel：初始部署；EdgeOne Pages：迁移测试，非正式上线结论
Neon PostgreSQL ／ 腾讯云 COS ／ QQ SMTP
分别承担数据库存储、对象存储与邮件服务方案
xushumin.cn → 部署环境
独立域名；域名、备案及访问验证持续完善
技术关系示意，非自动部署配置。数据库与对象存储独立于托管平台；QQ SMTP 为邮件服务方案。专题不会修改这些服务。
一个网站，逐步成为现实。
按阶段记录网站从规划、开发到部署测试与持续迭代的过程。
先定义，要做怎样的作品集
定位、项目盘点与网站架构规划
GPT / Figma明确求职展示与个人品牌的双重目标
让设计进入真实的浏览器
视觉设计、本地开发与 AI 协作，建立代码管理流程
GPT / Codex / GitHub把页面构想转为可运行的组件
把项目组织成一个完整的故事
NIO MAP 案例整理、素材管理、页面迭代与版本对比
Figma / Codex从素材堆叠转向有层次的案例表达
从本地走向部署环境
Vercel 初始部署、EdgeOne 迁移测试，数据库、COS 与独立域名配置
Vercel / EdgeOne / Neon / COS形成部署与数据服务方案；测试部署不等于生产上线
继续探索，也面对工具的边界
设计时空首页规划、3D 场景构想、连接问题排查与工程优化
GPT / Codex梳理体验方向与开发中的限制
把持续迭代变成工作方式
访问环境优化、后台与部署配置完善，持续检查页面体验
Codex / Git / 浏览器当前本地版本可预览；域名与生产环境持续完善
真正的实践，也包含不顺利。
不把待验证写成已完成，也不把测试成功写成正式上线。
连接中断，任务如何继续？
持续观察 · 待补充连接日志
- 问题
- Codex 长时间 Reconnecting，打断开发节奏
- 排查
- 复核连接状态、任务上下文与已落盘的文件，区分连接故障和代码错误
- 处理
- 保留任务清单与阶段结果，从最后可验证的状态继续
- 经验
- 让任务可以恢复，而不是依赖一次对话完成
本地和线上，为什么不是同一版？
流程完善中
- 问题
- 本地页面与线上版本不一致
- 排查
- 核对项目目录、Git 状态、部署来源与环境配置
- 处理
- 固定当前开发目录，并在发布前核对版本；本专题不触发发布
- 经验
- 预览、测试与生产应有清晰的版本边界
AI 修改，怎样守住范围？
本次采用增量实现
- 问题
- 局部调整可能扩大为不必要的结构修改
- 排查
- 先看差异，识别共享组件与页面专属样式
- 处理
- 先列文件范围，增量修改，保留已有未提交内容
- 经验
- 由人定义边界，也由人完成设计验收
部署迁移，并非换一个平台
迁移测试 · 待补充验证截图
- 问题
- Vercel 与 EdgeOne 的运行环境可能存在兼容差异
- 排查
- 逐项检查构建方式、路由、环境变量与服务依赖
- 处理
- 依据现有迁移清单继续验证，不将测试结果写成正式上线
- 经验
- 兼容性需要逐项验证与记录
代码齐了，素材却没有齐
待补充迁移包修复对比
- 问题
- 迁移包可能缺少 public 中的部分素材
- 排查
- 比对素材路径、打包规则与实际请求
- 处理
- 建立素材清单，检查打包产物与图片请求
- 经验
- 代码与素材必须一起验收
数据库，也有资源边界
持续处理中 · 待补充用量记录
- 问题
- Neon 公网流量达到月度额度，影响服务使用
- 排查
- 检查用量、请求模式与数据库连接方式
- 处理
- 继续评估访问策略与流量控制；目前没有足够证据确认问题已消除
- 经验
- 把服务额度纳入工程设计
能打开，不代表所有环境都能打开
持续处理中
- 问题
- 域名、备案以及国内外访问需要分别验证
- 排查
- 区分 DNS、HTTPS、备案与不同网络环境的访问结果
- 处理
- 保留独立域名方案，持续完善访问与生产配置
- 经验
- 测试部署、域名可用与正式上线是不同阶段
从设计能力，到实现能力。
已建立的工作基础
网站产品定位与信息架构
核心项目内容规划与统一视觉规范
GPT + Codex 协作开发
Git 与 GitHub 代码管理流程
持续完善的产品环境
Vercel 初始部署与 EdgeOne 测试部署的阶段回顾
数据库与对象存储方案
域名、访问环境与后台配置持续完善
I don’t just design ideas.
I build them.
不只是设计一个想法，而是尝试亲手把它实现出来。
返回首页 ↗