Problem
页面越多，越容易风格失控
如果每次新开网页都从 page.tsx 开始堆，会越来越依赖单页手工调整，最后样式和内容混在一起，难维护。
PRIVATE HIRING ROUTE · DATA / SKIN SPLIT
Zon
Product Narrative Systems · Design x Engineering Delivery · AI Workflow That Ships
这个页面本身就是样板：内容在 data 层，皮肤在 theme token 层，route 只负责组装。以后要改信息，改 data；要改风格，改 theme；要换展示方式，改 renderer。
NoindexTheme SwitchableBlack / White SystemSingle Source Data
Try: ?theme=noir, ?theme=paper, ?theme=frame
ABOUT
这次先把结构做对，再谈页面迭代
目标不是再做一个漂亮版本，而是建立以后都能复用的网页生产方式。
你现在已经有一个接近诉求的求职页，但它本质上还是某个版本页面本身。真正需要沉淀的是：如何让“一个页面版本”升级为“一个稳定的系统”。
这个系统至少要有三层：内容 schema、主题 token、页面 renderer。内容只描述事实和结构，不描述视觉；主题只描述皮肤与节奏，不放业务 copy；renderer 只负责把两者组合成可读页面。
这样做的结果是，你以后做新网站，不需要从零想版式，只要提供结构化数据，再选择黑底或白底等皮肤，就能稳定产出。
SYSTEM PROOF
这套方式解决的不是美观，而是复用、维护与扩展
Decision
统一 schema + theme + renderer
把内容抽成 data object，把黑白皮肤抽成 theme tokens，把页面结构收敛成一套 renderer，未来新增页面只是在填表与选皮肤。
Impact
同一份内容可以快速切换皮肤
这一页支持 query theme 切换，证明数据不需要跟着样式改；styles 页也能直接复用同一套 token 和组件。
SELECTED SIGNALS
希望招聘方先看到可验证信号
不先堆功能，不先堆履历，而是先给“可验证能力”。
产品视角
能把模糊需求拆成路径
Problem -> Decision -> Impact -> Learning
前端交付
能把抽象系统做成页面
从 schema 到 route 的落地能力
系统意识
先做可复用底座
主题、组件、数据三层分离
AI 工作流
能把能力固化成 skill
让后续交付越来越便宜
BEFORE / AFTER
这次不是多做一页，而是把做页方式升级了
招聘方如果要快速判断，这一块比单纯“会做页面”更能说明问题。
Topic
单页思路
系统思路
内容维护
改一处文案，经常要重新找 JSX 和样式混写的位置。
页面事实集中在一个 SiteDocument，改数据即可。
风格切换
要黑底/白底时，容易复制一份页面再改样式。
直接切 theme token，同一份内容继续复用。
新页面生产
每次都从 page.tsx 起手，版式越来越分叉。
优先复用 renderer 和 section kind，新增页面更便宜。
EXPERIENCE
经历更适合放到结构化时间线，而不是长段自述
2025 - Now
独立实践 · 产品 / 设计 / 前端
公开作品与自驱交付
围绕个人生产力、信息产品与内容系统持续交付可用版本，把产出沉淀成可复用工作流。
- 建立多个可公开访问的项目入口与内容站点
- 用 AI + 自动化把检索、结构化、输出、发布连成闭环
- 从单个页面走向可复制的网页系统
2023 - 2024
AI 产品探索 · 体验 / 原型 / 实现
小团队 / 自驱项目
关注 AI 产品输入约束、原型效率与闭环交付，强调最小可用版本和快速验证。
- 原型驱动验证，不先写大方案
- 把编程、工作流和内容生产统一到一套实践中
2018 - 2022
高级交互设计师
大型互联网公司（电商 / 增长）
长期做复杂业务的信息结构、关键路径与跨团队落地，习惯在多限制环境里做高密度决策。
- 节点会场、优惠与增长链路、多版本协同
- 把体验争议转成可验证假设与复盘沉淀
FAQ
如果对这个页面系统本身有疑问，先看这里
这部分不是为了自问自答，而是把最容易追问的维护问题提前说明。
以后如果我要做另一个个人页，是不是还得重写这一页？OPEN
不用。优先新建一个 data/sites/<slug>.ts，把新的 hero 和 section 顺序填进去；如果结构没变，就继续用同一个 renderer。
如果以后我要做白底版、打印版、或者更系统感的版本呢？OPEN
先看是否只需要换 theme token。只要内容结构不变，就不该复制 route；这也是 theme layer 存在的意义。
什么时候才值得新增 section kind？OPEN
只有当结构真的不同，比如要做 FAQ、对照表、CTA 强调区，而不是只想把同一段话换个写法时。
PLAYBOOK
以后新页面就按这个顺序生产
STEP 01
Step 01 · 先写数据
在 data/sites 下新建一个 SiteDocument，只写页面事实、结构、链接和顺序，不碰 className 与视觉描述。
STEP 02
Step 02 · 再选皮肤
从 noir / paper / frame 里选一个，或者新增一个 theme token 对象；theme 只决定背景、边框、面板、按钮与节奏。
STEP 03
Step 03 · route 只负责装配
app/<slug>/page.tsx 只 import data 和 renderer。页面本身不再承载真实 copy，避免越写越散。
STEP 04
Step 04 · 要上子域时走 host switch
像 motion.zondev.top 一样，通过 host 判断把同一个项目映射成 styles.zondev.top 之类的新入口。
PRINCIPLE
判断标准
先定义问题与结构，再定义皮肤。先让内容可迁移，再让视觉可升级。
这是这次重构最重要的约束。
NEXT ACTION
如果你要看的是“这个人会不会把抽象系统做成可验证交付”，这页本身就是证据
这块应该承担 CTA 和结论，而不是再写一段普通自述。
这个 route 不只是展示经历，它同时展示了一种生产方式：如何把求职页、介绍页、样式站和未来更多站点收束到一套可维护结构里。对需要判断“能不能把系统做出来”的团队来说，这比另一个更花的页面版本更有信息量。
Docs Site
Expanded
Styles 已升级成 overview + components + schema + recipes
Subsite Routing
Middleware
styles / motion 现在不只根页可访问
CONTACT
联系与入口
如果要展示不同皮肤，直接给同一路由追加 ?theme=paper 或 ?theme=frame。