name: workbench-builder
description: 帮非技术用户从一句模糊需求搭出成熟、稳定、可迭代的”个人工作台/仪表盘”应用。
当用户说”帮我搭个工作台/个人主页/仪表盘/一人公司工作台””我想用 WorkBuddy 做个自己的工作台””做个管理XX(选题/客户/财务/学习)的面板”时使用。
流程：先问答访谈(不立即编码)→ 平台与部署阶梯决策 → 可行性门禁 → 数据持久化决策(强制) → 界面风格决策(选择题化+参考图取色+样张确认) → 生成 REQUIREMENTS/ARCHITECTURE/UX/PLAN 设计文档 → 模块化脚手架 → MVP 分阶段开发+验收+迭代。
支持纯前端网页、本地服务版(一键脚本+SQLite)、局域网手机访问、云服务器部署(Docker+Caddy+域名)、PWA、微信小程序(自用/发布分流)、原生 App。
内置首页仪表盘+设置模块、多会话续接(读 docs/ 恢复上下文)、代码版本快照(无需Git,改前自动存档+CHANGELOG+一键回滚)、生成物版本戳、责任分工(用户只做注册/扫码/付钱)、服务器凭据安全红线、数据加密基线、端口冲突自动处理。本文件自包含，无外部依赖。

Workbench Builder — 个人工作台搭建器 v5

把”我好像想要一个自己的工作台，但说不清要什么”这种模糊意图，翻译成一个成熟、稳定、可迭代、数据不会丢、部署不用学运维的应用。本文件自包含全部规格，不依赖任何外部引用文件。

核心原则（无论走哪条路径都遵守）

  1. 问答优先于编码。 用户第一句话后不要立刻写代码，先搞清楚他要什么。
  2. 已给信息自动抽取，只追问缺口。 用户说过的内容抽进需求规格，缺失字段才提问，绝不重复问。
  3. 先出设计文档再开发，防止上下文漂移。 正式编码前先生成 REQUIREMENTS / ARCHITECTURE / UX_DESIGN / PLAN。
  4. 模块化。 每个功能 = 独立目录 + 明确输入/输出契约 + manifest 注册。不把代码堆进单文件。
  5. 数据安全高于功能丰富。 持久化方案必须显式决策并告知风险，不允许默默用最脆弱的默认值（见 Phase 2.5，不可跳过）。
  6. 能代办的全代办。 用户只需要做三类事：注册账号、扫码/点确认、付钱。写代码、装环境、配服务器、写配置文件、生成教程，全部是 AI 的活。每个环节先亮出”责任分工”，别让用户猜哪步该他动手。
  7. MVP 分阶段 + 验收门禁 + 迭代入口。 先做价值最高的一个模块跑通，再扩；二次修改只动对应模块。
  8. 多会话可续接。 搭建可能跨多次对话。检测到项目目录下已有 docs/REQUIREMENTS.md + docs/PLAN.md 时，先读这两份判断当前进度（哪些模块已完成、哪些待做），从断点续接，不从头走流程。
  9. 生成物带版本戳。 生成项目时在 manifest.json 里记录 { generatedBy, skillVersion, appVersion, generatedAt, tier }，方便未来迭代时知道基线。

何时使用

  • “帮我搭个工作台 / 个人主页 / 仪表盘 / 一人公司工作台”
  • “做个管理XX（选题/客户/财务/学习）的面板”
  • 用户只有一句模糊描述，或需求明显需要结构化梳理时。
  • 续接场景：用户说”继续上次的工作台””接着做”，且项目目录下有 docs/ → 先读 docs/REQUIREMENTS.md + docs/PLAN.md 判断进度，从断点续接（见核心原则 8）。

Phase 0 — 开场选择卡（必须最先执行，不要跳过直接编码）

智能跳过：开场前先扫一遍用户已提供的信息。如果”在哪用 + 数据重要程度 + 核心场景”三个都明确了（如”想做个记账的，手机上也要能看，数据不能丢，给我妈用”），跳过开场卡，直接进 Phase 1 补缺口——不要把已说过的事再问一遍。

用选择题形式（如有 AskUserQuestion 类工具则用之）让用户做两个选择：

想搭一个属于你的工作台 👋 你希望怎么开始？
A. 先一键生成可用模板页，之后随时让我补全你的定制需求（最快看到东西，推荐）
B. 我们先花几分钟聊清你的需求，再动手（更贴合你）

另外它主要在哪用？
💻 只在这台电脑用 ／ 📱 手机也要能用 ／ 🟢 微信里用（小程序）／ 🌍 发给别人用

（不用纠结技术选型——你告诉我”在哪用”，我来选最省事的方案。）

  • 选 A：先追问一句”你想管什么？（自媒体创作 / 理财记账 / 学习备考 / 项目管理 / 或我还说不清）”，选了即按对应场景预设生成模板页（见「模板先行」），生成后再触发精简访谈。
  • 选 B：进入 Phase 1 完整访谈。
  • 注意：Phase 0 只收集”在哪用”，具体技术形态（纯前端/本地服务/上云/小程序）由 Phase 2.6 的部署阶梯规则推导，不要在开场就抛术语轰炸用户。

平台速查表（用户主动问”有什么区别”时给，不主动抛）

🌐 网页 📱 PWA 🟢 微信小程序 💻 原生
用户怎么打开 浏览器/双击文件 主屏图标，像 App 微信里搜/扫码，无需下载 应用商店安装
前期门槛 无 无（需 HTTPS 托管） 需注册 AppID 账号+证书+审核
上线速度 立刻 立刻 自用立刻；发布 1–7 天审核 数天，可能被拒
分享给别人用 发链接 发链接 最强（微信生态内传播） 需对方去商店下载
跨设备数据同步 需后端/云 需后端/云 微信云开发开箱即用 需自己接云
迭代成本 极低 极低 中（发布版每次改动要重审） 高

PWA 需要 HTTPS 托管（不能 file:// 双击），实际映射到 T3（云服务器）或 T4（静态托管）档位——选 PWA 时按 T3/T4 的部署流程走。

🟢 微信小程序：先分流「自己用」还是「发布给别人用」（选小程序时第一个问题）

这个小程序是你自己（和几个朋友）用，还是要发布给不特定的人用？这两条路成本差很多。

A. 自己用（推荐给绝大多数个人工作台）——走体验版，不用审核不用上架：

  • 用户侧要做的（AI 无法代劳）：① 微信公众平台注册小程序拿 AppID（个人主体、免费）；② 安装微信开发者工具；③ 在后台把自己/朋友加为体验成员（上限 15 人）。
  • AI 代办的：全部代码、云开发配置文件、上传步骤逐步图文指引。
  • 必须提前说的坑：体验版二维码约 30 天过期，过期后需在开发者工具重新上传一次（1 分钟）；体验成员之外的人扫码打不开。
  • 主动告知红利：接微信云开发后数据按微信身份隔离、换手机还在，免费额度个人使用基本够——这是彻底解决数据丢失的最省事路径。

B. 发布——必须展示这张成本卡：

  • 提交审核（1–7 天，可能被拒）；需选对服务类目，类目错了直接拒；工具类通常个人主体可过，但电商/医疗/金融/社交等需企业主体。
  • 内容合规：含用户生成内容需接内容安全接口；收集个人信息需隐私协议。
  • 个人主体不能用微信支付。
  • 每次功能迭代都要重新提审——迭代节奏比网页慢一个量级。
  • 若用户只是”想给客户/朋友用”，先建议：体验版（≤15 人）或网页版发链接，往往就够了。

技术差异（两条路通用，防止拿网页那套硬套）：

  • 没有 DOM，不能用 document/window，不能直接引 CDN 脚本（第三方库需 npm + 工具”构建 npm”）
  • 图表用 ec-canvas(ECharts) 或 F2，不能用 Chart.js
  • 本地存储 wx.setStorageSync 单 key ≤1MB、总量 ≤10MB；清微信存储或卸载微信会丢 → 重要数据上云开发
  • 网络请求域名须在后台配 HTTPS 白名单（开发阶段可临时关校验）
  • 主包 ≤2MB（超出分包），总包 ≤20MB

💻 原生成本声明卡（用户点名 iOS/安卓/Mac 时必须展示）

项目 iOS/Mac 安卓
开发者账号 Apple Developer $99/年 Google Play $25 一次性（或免费侧载）
签名/证书 必须，配置繁琐 需签名密钥
分发 TestFlight/App Store 审核 上架审核或 APK 侧载
构建环境 需 Mac + Xcode 需 Android Studio
迭代速度 慢 慢
推荐替代 PWA：网页”添加到主屏幕”，图标/全屏/离线都有，零上述成本；或本地服务版+局域网访问 同左

话术要点：不劝退，先给 PWA / 小程序 / 局域网访问替代方案，用户体验后仍坚持原生再走原生（WebView 封装路线）。

Phase 1 — 访谈 / 问答

目标：沉淀一份结构化 REQUIREMENTS.md。

步骤：

  1. 场景预设：让用户从下方 5 个场景选最接近的，选了即带出默认模块与精简问题。
  2. 渐进披露：先只问 3 个关键问题——①核心痛点（最想被”接管”的重复工作是哪块）②数据源（现成的文件/表格/文档/API/日历/邮件）③期望产出（打开工作台想看到/得到什么）。
  3. 自动抽取 + 缺口比对：把对话中已出现的信息填入下方 schema，只对缺失字段追问，一次最多问 3 个问题。
  4. 补全次要字段：触发方式、使用设备与同步预期、数据重要程度、技术边界、验收标准（可给默认值让用户确认）。界面风格不在此处开放式提问，统一走 Phase 2.7 的选择题流程。

⚠️ “使用设备与同步预期”和”数据重要程度”是必问项，直接决定 Phase 2.5 持久化选型和 Phase 2.6 部署档位。问法要口语化：

  • “你主要在电脑上用，还是手机电脑都要？手机是在家用（连自家 WiFi）还是在外面也要用？”（← 这句区分 T2 局域网和 T3 云服务器，省一台服务器的钱）
  • “这里面的数据如果哪天全没了，你是’重新填一遍就行’还是’会疯’？”

REQUIREMENTS schema（生成 REQUIREMENTS.md 时严格按此结构）

# REQUIREMENTS
## 基本信息
- 用户角色/场景：(如 自媒体博主 / 备考学生)
- 平台：网页 | PWA | 微信小程序(自用|发布) | 原生封装
- 部署档位：T0 纯前端本地 | T1 本地服务版 | T2 本地服务+局域网 | T3 云服务器 | T4 托管云(静态托管/云开发)
- 启动路径：A 模板先行 | B 需求先行
## 核心痛点
- (1-3 条，按优先级排序)
## 数据源
- (来源 | 格式 | 获取方式：手动录入/文件导入/API)
## 期望产出
- (打开工作台看到什么；每项标注对应模块)
## 使用与同步
- 主要设备：电脑 | 手机 | both；手机使用场景：仅在家(同 WiFi) | 随时随地
- 跨设备同步需求：不需要 | 希望有 | 必须有
- 是否多人共用：否 | 是(说明)
## 数据重要程度
- 等级：可重填 | 重要 | 不可丢失(如账本/客户资料)
- 敏感度：普通 | 含隐私(收入/客户/健康) —— 含隐私时默认不公开托管、公网部署必须登录+HTTPS
## 持久化方案（Phase 2.5 决策结果，必填）
- 运行时存储：L1 localStorage | L2 IndexedDB | SQLite(本地服务) | 小程序 Storage | 云数据库
- 备份机制：手动导出 | 自动落盘文件 | 服务端定时备份 | 云端
- 用户已知晓的风险：(列出已明确告知的项)
## 触发方式
- 手动 | 定时刷新 | 事件驱动 (具体到模块；T1+ 档位可做真·定时任务)
## 技术边界
- 网络依赖：纯离线 | 需要哪些外部 API
## 界面风格（Phase 2.7 决策结果，必填）
- 风格预设包：清爽白 | 暗夜黑 | 温暖奶油 | 商务蓝灰 | 活力多巴胺（+微调说明）
- 导航位置：桌面 顶部|左侧；移动 底部标签栏|汉堡菜单
- 主色：#xxx 辅助色：#xxx 点缀色：#xxx 来源：预设|参考图取色|参考网站|用户指定
- 明暗模式：仅浅色 | 仅深色 | 跟随系统
- Emoji/图标：用 emoji | 线性图标 | 都不要(纯文字)
- 密度与字号：紧凑 | 舒适 | 大字模式(长辈/视力不佳)
- 参考物：(网站 URL / 图片描述与提取色板 / 无)
- 样张确认：style-preview.html 已确认 ✔（未确认不得铺开开发）
## 验收标准
- (每条可勾选、可验证，如"新增一条选题后刷新页面仍存在""备份文件能完整恢复数据")
## 待补全清单
- (Path A 专用：哪些模块是占位、还差什么信息)

场景预设（5 套，含模块级规格）

1. 自媒体创作台

模块 字段 核心交互
选题管理 标题、平台、状态(灵感/写作中/已发布)、优先级、备注、创建日期 看板或列表视图，状态拖拽/点击流转，按平台筛选
素材库 标题、类型(链接/文本/图片路径)、标签、来源、收藏日期 标签筛选、搜索、一键复制内容
内容日历 日期、选题引用、平台、发布状态 月视图，点日期挂选题
数据复盘 日期、作品、平台、阅读/点赞/涨粉 手动录入 + 折线/柱状趋势图

2. 个人理财台（涨红跌绿，金额用 ¥，单位分存储避免浮点误差；默认按”不可丢失+含隐私”处理）

模块 字段 核心交互
账户总览 账户名、类型(现金/储蓄/投资/负债)、余额 卡片网格 + 净资产合计
收支记录 日期、金额、类型(收/支)、分类、账户、备注 快捷录入表单、按月/分类筛选
预算 分类、月度限额、已用(自动汇总) 进度条，超支变红
报表 自收支记录聚合 月度收支对比图、分类占比图

3. 学习备考台

模块 字段 核心交互
目标倒计时 考试名、日期 大字号天数展示
学习计划 日期、科目、任务、时长、完成状态 日/周视图打勾，完成率统计
错题本 题目、科目、错因、掌握度(1-5)、复习日期 按掌握度排序复习，复习后更新掌握度
笔记 标题、科目、内容(markdown 渲染更佳)、标签 搜索、标签筛选

4. 项目管理台（客户资料默认按”不可丢失+含隐私”处理）

模块 字段 核心交互
任务看板 标题、项目、状态(待办/进行/完成)、截止日、负责人 三列看板拖拽，逾期高亮
项目列表 名称、客户、阶段、进度%、备注 卡片 + 进度条
联系人 姓名、公司、角色、联系方式、最近跟进 列表 + 搜索，”N 天未跟进”提示
文档链接 标题、URL、所属项目 分组收藏夹

5. 通用空白台（适合 Path A 且方向不明的用户）
速记待办（文本+完成态）／笔记（标题+内容）／链接收藏（标题+URL+标签）

Phase 2 — 可行性门禁

把 REQUIREMENTS 每条需求映射到三档，写入 ARCHITECTURE.md 的”可行性评估”节：

  • ✅ 现在就能做：纯前端逻辑、本地/SQLite 持久化、文件导入导出、免费公开 API、图表库、本地一键脚本、服务器部署（用户提供机器）。
  • ⚠️ 能做但有代价：需 API Key（用户自己申请）、跨域需代理、AI 生成按量计费、需装微信开发者工具、云服务器需购买（¥/年）+ 国内绑域名需备案——注明具体代价和金额量级。
  • ❌ 暂做不到/需绕路：自动抓取需登录的第三方数据（如公众号后台、抖音后台）、纯前端做多人实时协作、T0 档做定时推送——必须给替代方案（如”手动导出 CSV 再导入”、”升级到 T1 档就能做真定时任务”），绝不虚构能力。

常见误区提前讲清（主动说，别等用户踩坑）：

  • 纯前端网页关掉就停——”定时任务”只在页面打开时有效；T1 本地服务版可以做真·定时任务（电脑开机即可），T3 云服务器可 7×24。
  • 浏览器本地存储的数据在这台设备的这个浏览器里，换设备/换浏览器都看不到。
  • 小程序体验版二维码约 30 天过期，需重新上传。

Phase 2.5 — 数据持久化决策（强制执行，不可跳过）

这是工作台最容易”事后翻车”的一环。用户被清理软件（腾讯管家/CCleaner）清一次缓存、或换个浏览器，攒了三个月的数据瞬间归零——这会让他彻底放弃这个工作台。必须在编码前显式决策并告知，而不是默默用 localStorage。

第一步：告知风险（用户友好的说法，一次讲完，不重复吓人）

有件事得先说清楚：如果数据只存在浏览器里，清理软件清一次缓存、换台设备，数据就没了。所以我会按你的重视程度选个稳的方案，并且配好自动备份。

第二步：按”数据重要程度 × 同步需求”选级（对照选，别问开放题）

级别 方案 被误删风险 跨设备 容量预期 适用
L1 localStorage 高（清缓存即没） ✕ ~5MB（<1000 条轻量记录） 可重填的轻量数据、Demo
L2 IndexedDB + navigator.storage.persist() 中 ✕ ~50MB–数百 MB（有图片/附件） 数据量大、有图片/附件、仍想零安装
L3 L1/L2 + 本地文件备份 低 手动拷贝 同 L1/L2 坚持纯前端(T0)时的推荐默认
L3.5 SQLite 数据库文件（T1/T2/T3 本地服务版自带） 极低（普通清理软件不会碰、自带自动备份） T2 局域网/T3 公网 几乎无上限（GB 级） ⭐ 数据”重要”及以上的推荐默认
L4 云端（微信云开发 / Supabase / 自建 T3） 极低 ✔ 取决于云服务套餐 必须随时随地多设备、或数据不可丢

选型决策规则（AI 直接按此判断，只把结论告诉用户请其确认）：

  • 数据”可重填” + 单设备 → L1 + 手动导出入口（T0 即可）
  • 数据”重要” → 优先 L3.5（推荐升到 T1 本地服务版：”多双击一个启动脚本，换来数据放进真正的数据库、清缓存也不怕”）；用户坚持零安装 → L3
  • 数据”不可丢失”（账本/客户资料）→ L3.5 起步，并说明 T3/L4 的升级路径
  • 手机”仅在家用” → T2 局域网（L3.5，零额外成本）；”随时随地” → T3 或 L4
  • 平台是小程序 → 直接推荐微信云开发
  • 敏感数据 + 用户排斥上云 → L3.5 + 提醒定期把备份文件拷到网盘或 U 盘

第三步：无论选哪级，以下都是硬性交付项

  1. 备份/恢复入口：顶栏或设置里必须有「导出数据」「导入数据」。导出为单个 JSON，文件名 工作台名-backup-YYYYMMDD.json。T1+ 档位额外做服务端自动备份（见 4C）。含隐私数据（收入/客户/健康）时导出默认加密：导出时要求设一个密码，用 AES-GCM 加密（密码派生用 PBKDF2），不加密的明文导出需用户主动选且二次确认。
  2. 备份状态可见 + 主动提醒：记录 lastBackupAt。超过 7 天未备份（含自动备份）时，页面顶部显示提示条：「已经 12 天没备份了，[立即备份]」。不允许省略。
  3. 数据版本与迁移：所有持久化数据统一包一层信封，迭代改字段时必须写迁移函数，禁止直接改结构导致老数据读不出来： 
    { schemaVersion: 2, exportedAt: '2026-07-30T12:00:00Z', data: { 'mod-todo': [...], 'mod-note': [...] } }

    统一提供 migrate(raw)：按 schemaVersion 逐级升级；读取失败时不清空，转存为 corrupt 副本再提示用户。

  4. 导入安全：导入前校验 JSON 结构与 schemaVersion，让用户选「合并」或「覆盖」，覆盖前自动先导出一份当前数据。

第四步：可选增强（数据重要时主动建议）

  • 自动落盘（T0 + Chromium 桌面）：File System Access API 授权备份文件后节流自动写入；Safari/Firefox 不支持 → 降级为提醒式手动导出，不能报错卡住。
  • 多份轮换备份：保留最近 N 份，防止”备份了一份坏数据”。
  • 删除用软删除：deletedAt 标记 + 回收站视图，30 天后清理。

Phase 2.6 — 部署阶梯（按需选档，可随时升档）

原则：从最低可用档起步，留好升级路径。所有档位共用同一套前端模块代码和存储层接口，升档 = 换存储层实现 + 加部署物，不推翻业务代码。

档位 形态 数据放哪 手机能用? 用户成本 适用信号
T0 纯前端，双击 index.html 浏览器存储 ✕ 零 只在这台电脑用、数据可重填
T1 本地服务版：一键脚本启动 Node 服务 + SQLite 本机 data/ 目录数据库文件 ✕ 双击一个脚本 数据重要、要真定时任务
T2 T1 + 局域网访问 同 T1 ✔ 同 WiFi 扫码 零（复用 T1） “手机在家能看就行” ⭐最被低估的档位
T3 云服务器：Docker Compose + Caddy 反代 + 域名 服务器上的 SQLite/卷 ✔ 随时随地 服务器约 ¥60–200/年 + 域名 ¥ 几十/年 随时随地访问、多人用、7×24 任务
T4 托管云：静态托管(纯前端) / 微信云开发(小程序) 托管商 ✔ 基本免费 不想管服务器；小程序首选

档位推导规则（AI 按此推导后向用户确认，用人话说结论）：

  • 只在电脑用 + 数据可重填 → T0；数据重要 → T1
  • 手机仅在家用 → T2（明确告诉用户：”不用买服务器，手机连家里 WiFi 扫个码就能用”）
  • 随时随地 / 分享给外人 → T3（有服务器或愿意买）或 T4（纯前端且数据不敏感）
  • 小程序 → T4（云开发）
  • T0 file:// 特有坑必须叮嘱：把文件夹改名或挪走，浏览器可能当成另一个站点导致数据”消失”——放固定位置别乱动。
  • 静态托管含隐私数据 → 必须私有仓库/访问口令，别公开托管账本。

责任分工表（进入 T1 及以上档位时，先给用户看这张表再动手）

事项 谁做
写全部代码、配置文件、启动脚本、Dockerfile、Caddyfile 🤖 AI
本机装 Node / 检查环境 🤖 AI（脚本自动检测+引导）
服务器上装 Docker、部署、反代、HTTPS 🤖 AI（经用户确认后执行）
生成域名解析/备案的逐步图文教程 🤖 AI
注册账号（云厂商/域名/微信）、实名认证、付钱 👤 用户（AI 给直达链接和选购建议）
在网页控制台点”确认”、扫码 👤 用户
提供服务器 IP 和登录方式 👤 用户

Phase 2.7 — 界面风格决策（小白友好：全程选择题，禁止开放式审美提问）

大多数用户描述不出自己想要的界面。”你喜欢什么风格？””想要什么配色？”这类开放题只会得到”随便/好看就行”，然后做完了他又说丑。规则：不让用户描述，让用户挑。

🚫 提问禁令

  • 禁止问”你喜欢什么风格/设计/UI”这类开放题。
  • 禁止抛设计术语（视觉层级、留白、栅格、圆角半径、饱和度）。
  • 每个问题都必须带选项 + 每个选项一句人话描述，且有默认值——用户全说”随便”也能走完流程。

第一步：风格预设包（5 选 1，人话描述）

预设 一句话人话 底色/主色气质 适合
🤍 清爽白 “干净不花哨，像苹果官网” 白底 + 单一克制主色 默认推荐，通吃
🖤 暗夜黑 “深色底，晚上看不刺眼，有点极客” 深灰底 + 高亮点缀 程序员味、夜猫子
🏖 温暖奶油 “米白奶油底，圆圆的，看着治愈” 奶油底 + 低饱和暖色 生活记录、学习台
💼 商务蓝灰 “正式稳重，像办公软件” 浅灰底 + 藏蓝 项目/客户/理财台
🌈 活力多巴胺 “颜色多、明快，打开有精神” 白底 + 多彩色块 自媒体、年轻用户

场景预设可带默认风格（理财/项目台默认商务蓝灰，自媒体台默认活力多巴胺，学习台默认温暖奶油），用户不选就用默认并明说”先按 XX 风格做，随时能换”。

第二步：4 个具体小问题（全选择题，一次问完）

  1. 导航放哪？ 顶部一排（内容区最大）｜左侧一列（模块多时清晰）｜手机上用底部标签栏（像微信那样，拇指够得着）。默认：桌面左侧 + 移动端底部标签栏（≤5 模块）或汉堡菜单（>5）。
  2. 深色浅色？ 浅色｜深色｜跟随手机系统自动切。默认浅色。选”跟随系统”则两套令牌都要出。
  3. 要不要 emoji？ 喜欢（模块图标、按钮都带点）｜克制（只做导航图标用线性 SVG）｜完全不要（纯文字，最商务）。默认克制。
  4. 字要多大？ 正常｜偏大（看久了不累）｜大字模式（给长辈用/视力不佳：正文 ≥18px、按钮更大更粗、对比度拉满）。默认正常。若访谈中出现”给爸妈用/长辈记账”信号，主动建议大字模式。

第三步：参考物取色（用户答不出偏好时的杀手锏，主动提供）

“如果说不上来想要什么感觉，可以丢给我：① 一个你觉得好看的网站/App 名字，或 ② 一张你喜欢的照片（风景/穿搭/家居都行），我从里面提炼配色。”

参考网站 → 提炼其布局密度、导航模式、色彩气质，映射到最接近的预设包 + 微调，只借气质，不像素级抄袭。

参考图片 → 提取色板并按 UI 规则校正（例：海滨照 → 海蓝做主色、沙滩米黄做背景底色、椰树绿做点缀/成功色）。照片色不能直接当 UI 色，必须校正：

  • 主色：取照片中占比高或最有记忆点的颜色，降饱和至适合大面积按钮/导航的程度（多巴胺预设除外）；
  • 背景：取照片浅色调再大幅提亮（接近白/米白），保证内容可读；
  • 点缀色：取小面积高识别度色，只用于高亮/状态/图表；
  • 正文对比度必须 ≥ 4.5:1（WCAG AA），达不到就加深文字色——宁可偏离照片，不牺牲可读性；
  • 向用户展示提取结果：”我从这张图里取了这 3 个颜色：海蓝(主色)、沙米(背景)、椰绿(点缀)”，附色块预览。

第四步：风格样张门禁（防”全做完了才说丑”，成本最低的返工点）

编码铺开前，先生成一页 style-preview.html 样张：用最终设计令牌渲染一屏假数据示例——顶栏+导航（按选定位置）、2–3 张数据卡片、一个按钮组、一个表单、一个空状态、（若有图表）一个小图表。发给用户看：

“界面会长这样，颜色/字号/风格满意吗？不满意现在改最快，一句话就行（’蓝色深一点”字再大点’）。”

  • 用户确认 → 令牌锁定进 styles.css :root 与 UX_DESIGN.md，后续模块只引用变量，不再逐模块讨论审美。
  • 不满意 → 只改这一页再确认。未过样张门禁不得进入 Phase 4 铺开开发。
  • Path A（模板先行）简化：直接用场景默认风格生成，模板页交付时附一句”配色和字号都能一句话换，说就行”。

无论选什么，硬性可读性底线（不因用户偏好妥协）

  • 正文字号 ≥ 14px（大字模式 ≥18px）；正文对比度 ≥ 4.5:1。
  • 状态信息不能只靠颜色区分（色盲友好）：涨跌/成败附 +/-、↑/↓ 或文字标签。
  • 可点击区域 ≥ 44×44px（移动端）。
  • 多巴胺风格的”多彩”只用于点缀块和图表，正文区仍保持白底深字。

Phase 3 — 生成设计文档（编码前必须；机器消费为主、人一眼能扫）

在项目 docs/ 下生成四份，用户确认一屏摘要后再进入编码：

ARCHITECTURE.md：模块清单（ID/名称/职责一句话/依赖）、数据流向（文字版：用户输入 → mod-x.store → 存储层 → mod-y 读取聚合）、可行性评估表（Phase 2）、存储与备份方案（Phase 2.5 结论：级别/键名或表名/schemaVersion/迁移策略）、部署档位与升级路径（Phase 2.6 结论）。

UX_DESIGN.md：记录 Phase 2.7 全部决策结果（预设包/导航位置/明暗/emoji/字号档/色板及来源）、整体布局（按用户选定的导航位置；≤768px 按选定的移动导航方案折叠）、设计令牌（CSS 变量集中定义：主色/背景/卡片/文字/边框/圆角/间距/字号，模块只引用变量，跟随系统时含两套）、组件规范（卡片/按钮/表单/空状态/标签/备份提醒条统一样式）、每个模块一段”界面长什么样”、样张确认记录（style-preview.html 用户已确认的时间与修改历史）。

PLAN.md：Phase 划分（MVP=1 个模块 + 存储层 + 备份入口 → 验收 → 逐模块扩展 → 按需升档），每项任务标注模块 ID 与验收标准引用。

REQUIREMENTS.md：Phase 1 产物。

Phase 4 — 模块化脚手架（代码规范）

4A. 前端通用（所有档位共用）

技术栈：原生 HTML/CSS/JS，零构建。目标浏览器：近 2 年版本的 Chrome/Edge/Safari/Firefox（不兼容 IE）。图表用 Chart.js：T0 档如果需要断网也能用，必须下载到本地 vendor/ 目录，不能依赖 CDN（file:// 双击打开时 CDN 需联网，离线图表会加载失败并报错）；T1+ 档位同样用本地 vendor 文件。

workbench/
├── index.html        # 壳：顶栏(含备份入口)+导航+内容区
├── styles.css        # 仅设计令牌(:root 变量) + 布局 + 通用组件样式
├── app.js            # 模块注册表 + 路由 + 存储封装 + 备份/迁移
├── manifest.json     # 模块注册清单 + 版本戳（见下）；PWA 另加 pwa-manifest.json + sw.js
├── vendor/           # 本地第三方库（Chart.js 等），不依赖 CDN
├── docs/             # 四份设计文档
├── versions/         # 代码版本快照（见 Phase 5 代码版本管理）
│   ├── v1.0/         # 历史版本代码副本
│   └── CHANGELOG.md  # 版本号 + 变更说明
└── modules/
    ├── mod-home/         # 首页仪表盘（可选但推荐，见下）
    ├── mod-settings/     # 设置模块（必须，见下）
    └── mod-<id>/index.js # 每个业务模块一个目录，自包含

manifest.json 必须包含版本戳：

{ "generatedBy": "workbench-builder", "skillVersion": "v5", "appVersion": "v1.0", "generatedAt": "2026-07-30", "tier": "T1", "modules": [{"id":"mod-todo","name":"速记待办","enabled":true,"order":1}] }

skillVersion = 哪个版本的 skill 生成的；appVersion = 工作台应用自身的版本号（每次代码变动时递增，见 Phase 5 代码版本管理）。

模块契约（每个模块必须遵守）：

window.Workbench.register({
  id: 'mod-todo',            // 唯一 ID，同目录名
  name: '速记待办',
  icon: '✓',
  storageKey: 'wb.mod-todo', // 本模块唯一存储键/表名，禁止读写其他模块的
  schemaVersion: 1,
  migrate(oldData, fromVer) { return oldData; },
  render(container) { /* 渲染 UI，含空状态 */ },
  exports: { getItems() {} } // 可选：暴露给其他模块的只读接口
});
  • 模块间通信只允许通过 exports 只读接口或自定义事件，禁止直接改别的模块的 DOM 或存储。
  • app.js 提供统一存储层 Workbench.store.get/set（异步接口 async，T0 内部走 localStorage/IndexedDB，T1+ 内部走 fetch('/api/store/…')——模块代码在所有档位零改动，这是升档不推翻的关键）。
  • app.js 提供 Workbench.backup.export()/import(file)/lastBackupAt，启动时检查备份时效。
  • 每个模块必须有空状态（引导文案+新增按钮），禁止空白页。
  • manifest.json 记录 {id, name, enabled, order}。
  • mod-settings 模块（必须）：集中放置导出/导入数据、备份状态与历史、存储位置说明（数据存在哪/多大）、主题切换（跟随系统时）、关于与版本信息、清空数据（需二次确认）。不把这些功能散落在顶栏各处。
  • mod-home 首页仪表盘（可选但推荐）：打开工作台的第一屏，通过各模块 exports 只读接口聚合关键信息卡片（如”今日待办 3 条 + 本月支出 ¥2,000 + 下周考试倒计时”）。用户打开就想看全景时价值最高。若用户不需要，默认进入第一个业务模块。

4B. 微信小程序（平台选小程序时用这套）

miniprogram/
├── app.js / app.json / app.wxss   # 全局：注册页、tabBar、设计令牌
├── utils/
│   ├── store.js      # 统一存储层：封装 wx.setStorageSync / 云数据库
│   └── backup.js     # 导出 JSON 文本（可复制/发文件传输助手）或写云端
├── components/       # 卡片、空状态、表单项
└── pages/
    └── mod-<id>/     # 每模块一个页面目录
  • 模块 = page 目录，app.json 的 pages+tabBar 即注册表；存储层必须封装在 utils/store.js（本地 Storage → 云开发只改一个文件）。
  • 图表用 ec-canvas；样式用 rpx；长列表分页。
  • 交付时一并给出：AppID 填写位置、开发者工具导入步骤、上传体验版+添加体验成员的图文步骤、（自用）30 天重传提醒。

4C. 本地服务版（T1/T2 档，一键脚本 + SQLite）

设计目标：用户全程只需”双击一个文件”。

workbench/
├── start.bat           # Windows 一键启动
├── start.command       # macOS 一键启动（.command 可双击，.sh 不能）
├── server.js           # 单文件后端：静态托管 + /api/store + 定时备份
├── data/
│   ├── workbench.db    # SQLite 数据库（node:sqlite，零 npm 依赖）
│   └── backups/        # 自动备份：wb-YYYYMMDD-HHmm.db，保留最近 14 份
└── (前端文件同 4A)

硬性规范：

  • 零 npm 依赖：用 Node ≥22 内置 node:http + node:sqlite，不跑 npm install（小白电脑上最容易失败的一步就是装依赖）。
  • node:sqlite 实验性标志：node:sqlite 在 Node 22 多数版本中是实验性 API，启动时需带 --experimental-sqlite 标志（node --experimental-sqlite server.js）。start 脚本里必须带这个 flag；如果带 flag 仍报错，提示”请升级到 Node 22.5.0 以上（nodejs.org LTS）”。
  • start.bat（Windows）/ start.command（macOS）必须做：① 检测 Node 是否安装且 ≥22，没有则打印下载地址（nodejs.org LTS）并暂停等待，不闪退；② 启动 server（带 --experimental-sqlite）；③ 自动打开 http://localhost:端口；④ 窗口保留日志，标题写明”这个窗口别关，关了工作台就停了”。macOS 注意：.command 文件首次需 chmod +x（在终端运行一次 chmod +x start.command），之后可双击；脚本首次运行时也可自动检测权限并提示。
  • 端口冲突处理：默认端口（如 3000）被占时，自动尝试下一个端口（3001、3002…）并在控制台和页面提示”3000 被占了，改用了 3001″；如果连续 5 个端口都被占，打印”可能有哪些程序在占用”+排查建议，不直接报英文错误退出。
  • 后端 API 极简：GET/PUT /api/store/:key（JSON 进出，内部映射 SQLite 表），加 GET /api/export（整库 JSON）与 POST /api/import。
  • SQLite 启用 WAL 模式：建库后立即执行 PRAGMA journal_mode=WAL，并发读不阻塞、写串行；多人同时用（T3）时避免 database is locked。若真正多人高频写入，注明”考虑换 Postgres”。
  • 自动备份：server 启动时 + 每日定时把 .db 复制到 data/backups/，轮换保留 14 份。告诉用户：data/ 文件夹就是你的全部数据，拷走它 = 完整备份。
  • T2 局域网模式：绑 0.0.0.0，启动时打印 http://<局域网IP>:端口 并在页面设置里显示二维码供手机扫。必须提醒：① 手机和电脑连同一个 WiFi；② 电脑休眠/关机就访问不了；③ 局域网内他人可访问 → 提供可选的简单口令开关（PIN 码）。PIN 必须在 server.js 里校验（每个 /api/ 请求检查 header 里的 PIN），不能只在前端 JS 里校验——前端校验可被直接调 API 绕过，等于没有。
  • 真·定时任务从这一档解锁：server 内 setInterval/轻量 cron 即可做”每天 8 点生成日报”类需求。

4D. 云服务器部署（T3 档：Docker + Caddy + 域名）

先决条件确认（缺一不可，缺了先帮用户补齐）： 一台服务器（有 → 要 IP 和登录方式；没有 → 给选购建议：入门配置 2核2G 足够，国内轻量云约 ¥60–200/年 活动价，新手无脑选 Ubuntu LTS 系统）。

🔴 凭据安全红线（不可违反）：

  1. 服务器密码/密钥只在当次会话内使用，用完即忘——绝不写入任何文件、脚本、记忆或日志；生成的部署脚本里不得包含明文密码。
  2. 主动建议用户改用 SSH 密钥登录并提供步骤；用户坚持用密码则口头输入、不落盘。
  3. 每次在服务器上执行操作前，先列出将要执行的命令清单和作用，用户确认后再执行；批量操作分步走，每步验证。
  4. 只做加法（装软件、写配置、起容器），禁止在服务器上执行任何删除性/破坏性命令（rm -rf、清盘、改动用户既有服务）；发现端口/服务冲突时停下来询问，绝不擅自停掉用户已有的东西。

部署规范：

  • 容器化：一个 Dockerfile（node:22-alpine 跑 4C 的 server.js）+ 一个 docker-compose.yml（app + caddy 两个服务，data/ 挂载为卷——数据在卷里，容器怎么重建都不丢）。
  • 反代用 Caddy 不用 Nginx：Caddyfile 只要 3 行，且自动申请续期 HTTPS 证书，把”配 SSL”这个新手噩梦整个消掉： 
    workbench.example.com {
    reverse_proxy app:3000
}
  • 公网 = 必须登录 + HTTPS，没有商量余地：server 加最简账号体系（单用户即可：首次访问设置密码 → bcrypt 存哈希 → session cookie 设 HttpOnly/Secure/SameSite）。部署顺序：先绑 localhost 启动 → 设好密码 → 再开防火墙 80/443 对外；或部署时生成一个随机安装密钥，首次用安装密钥登录设密码，设完后作废安装密钥。裸 IP + 无认证的阶段只允许存在于部署调试的几分钟内。
  • 服务器端备份：cron 每日备份 .db 到备份目录 + 保留 14 份；并在页面提供”下载完整备份到本地”按钮，提醒用户每月下载一次（异地备份：服务器欠费/被回收时数据还在自己手里）。
  • 域名（可选但推荐）：生成逐步图文教程——在哪买（¥ 几十/年）、加一条 A 记录指向服务器 IP、国内服务器必须 ICP 备案（免费但要 2–3 周，需实名+审核）；不想备案的两条路：用境外/港服务器（访问稍慢），或不绑域名先用 https://IP + 自签/端口方式过渡。这一步 AI 只能给教程，控制台操作要用户自己点。
  • 防火墙：只开放 80/443/SSH 端口；SSH 建议改默认端口或用密钥后禁密码登录（给可选步骤，不强制）。
  • 部署完成必测：手机流量（非 WiFi）打开域名 → 登录 → 增删一条数据 → 刷新仍在 → 下载备份成功。

安全与加密基线（按档位递增，写入 ARCHITECTURE.md）

档位 必须做 建议做
T0/T1/T2 数据不出本机；导出文件提醒放安全位置；含隐私数据时导出必须加密（AES-GCM，PBKDF2 派生） 备份 JSON 可选口令加密；T2 加 PIN（服务端校验）
T3 HTTPS(Caddy 自动)、登录认证、bcrypt 密码哈希、Cookie 安全属性、只开必要端口 敏感字段（如账本金额备注）应用层 AES-256-GCM 加密；登录失败限速
T4 小程序 云开发默认按 openid 隔离（天然多租户） 敏感集合加安全规则

通用：绝不在前端代码里硬编码任何密钥/口令；第三方 API Key 一律放服务端环境变量（T0 档需要 Key 的功能要么走代理要么明确告知风险）。

Phase 5 — MVP 分阶段开发 + 验收 + 迭代

  1. MVP：只做价值最高且可行性 ✅ 的一个模块，并同时完成存储层 + 备份/导入入口（存储层是地基，不能等后期补）。
  2. 验收门禁：对照 REQUIREMENTS 验收标准逐条核对，以下强制必测：
    • 刷新页面后数据仍在
    • 导出 → 清空 → 导入，数据完整恢复（T1+ 额外验证：data/backups/ 里真的产生了备份文件）
    • 手机宽度不破版（T2/T3 用真手机访问测）
    • 空状态正常显示
    • T2 额外：不输 PIN 直接调 /api/store/xxx 被拒（验证 PIN 是服务端校验而非前端花瓶）
    • T3 额外：HTTPS 生效、未登录访问被拦截
    • manifest.json 含正确的版本戳（generatedBy/skillVersion/generatedAt/tier/appVersion）
    • versions/CHANGELOG.md 存在且记录了 v1.0 初始版本
      不达标只回修该模块。
  3. 扩展：MVP 通过后按 PLAN 逐模块添加，每加一个验收一次。
  4. 迭代入口：用户说”XX 太简单/想改 XX”→ 用 manifest 定位模块目录单独改，绝不推翻重写；改数据结构必须提升 schemaVersion 并写 migrate；改完更新对应文档小节。
  5. 升档入口：用户说”手机也想看了/想随时能开”→ 按 Phase 2.6 阶梯升档，只换存储层实现和部署物，业务模块代码不动；升档时先做一次全量导出，迁移完成后验证数据条数一致再切换。注意：换平台（如网页→小程序）不是升档，是重写——代码结构完全不同（4A vs 4B），只能导出数据再在新平台重新导入。

代码版本管理（快照式，无需 Git）

非技术用户不会用 Git。但 AI 迭代改代码可能改出 bug，用户说”上次还是好的”却无法回滚——这会让整个工作台作废。规则：任何代码变动前，先把当前能用的版本存一份。 这是”穷人版 Git”，简单但够用。

6. 快照规则——代码变动前必须先存档（与 Phase 2.5 数据备份同理：防的是”改坏了回不去”）

以下操作执行之前，必须先快照当前版本：

  • 新增模块、修改现有模块代码
  • 修改样式/布局/设计令牌
  • 升档（T0→T1 等）
  • 任何修改 index.html / styles.css / app.js / server.js 的操作

快照方法：

  1. 将 workbench/ 下的代码文件复制到 versions/vN.N/，排除 data/（用户数据，由 Phase 2.5 管理）、versions/（避免递归）、node_modules/。vendor/ 如未变化可跳过以省空间。
  2. 在 versions/CHANGELOG.md 追加一条： 
    ## v1.2 — 2026-07-30
修改了收支记录模块的表单布局，调整主色调为深蓝
  3. 更新 manifest.json 的 appVersion 字段。
  4. 然后才进行修改。

版本号规则：

  • v1.0 = 初始交付版本（MVP 完成时必须打这个快照）。
  • 小改（样式微调、单模块字段调整）→ 小版本号 +1：v1.1、v1.2…
  • 大改（新增模块、升档、架构调整）→ 大版本号 +1：v2.0、v3.0…
  • 一次对话里多个关联改动算一个版本，不打多个快照。

保留策略： 保留最近 10 个版本，超出自动清理最旧的。用户可在 mod-settings 里给某个版本打”锁定”标记，锁定的不被自动清理。

7. 回滚入口——用户说”回到上个版本”/”上次改之前是好的”：

  1. 先做一次数据导出（安全网：万一回滚后数据格式不兼容，至少有备份）。
  2. 读 CHANGELOG.md，展示最近版本列表 + 变更说明，让用户选目标版本。
  3. 从 versions/vN.N/ 恢复代码文件，保留当前 data/ 不动——数据不随代码回滚，用户的记录必须存活。
  4. 恢复后验证：打开页面 → 数据还在 → 基本操作正常。
  5. 如果数据结构有 schemaVersion 差异，回滚后走 migrate 降级或提示用户导入刚导出的备份。

Git 支持（可选）： 如果用户有 GitHub 账号且愿意用，可 offer Git 作为更专业的方案（AI 代写 .gitignore、代执行 commit/push）。但默认不要求，快照机制已足够覆盖个人工作台的回滚需求。

模板先行（Path A）特别说明

  1. 用户只需先选一个场景预设，立即按 Phase 4 规范生成该场景的模板页：壳 + 设计令牌 + 存储层 + 备份入口 + 该场景全部默认模块的可交互占位版（字段齐、可增删改、能持久化，但数据为空并显示空状态引导）。
  2. 页面内显式渲染一张**”待补全清单”卡片**：列出每个模块还缺什么定制信息。
  3. 同时生成 docs/REQUIREMENTS.md stub（已知信息 + 待补全清单持久化）。
  4. 即使走快速路径，Phase 2.5 的风险告知与备份入口不能省——先按 T0/L1+导出入口交付，追问时确认是否升档。
  5. 生成后立刻主动问：”要不要花 2 分钟补全最关键的一块？”防止”生成完就跑、永远是半成品”。

交付物清单

  • 可运行应用（按档位：双击 index.html / 一键启动脚本+本地服务 / 已部署的公网地址 / 小程序源码+导入说明）
  • docs/ 四份设计文档
  • modules/（或 pages/）各模块 + 注册清单（含 mod-settings 必须模块 + mod-home 可选模块）
  • manifest.json 含版本戳（generatedBy/skillVersion/appVersion/generatedAt/tier）
  • 代码版本快照：versions/ 目录 + CHANGELOG.md（怎么回滚、版本列表、保留策略说明）
  • 数据备份说明：怎么备份、备份文件在哪、怎么恢复、多久备一次
  • T1+：data/ 目录说明（”拷走这个文件夹=完整备份”）；T3：服务器上装了什么、配置文件在哪、怎么重启、怎么下载异地备份
  • “待补全清单”（Path A）或”已上线功能清单”（Path B）

护栏

  • 不堆单文件；改动局部化到模块。
  • 不虚构能力；可行性 ❌ 必须明示替代方案。
  • Phase 2.5 不可跳过：任何交付物都必须有备份/恢复入口，并已向用户讲清存储风险。
  • 禁止模块直连底层存储 API，一律走统一存储层（异步接口），为升档留余地。
  • 数据结构变更必须走 migrate，绝不接受”改了字段老数据读不出来”。
  • 代码变动前必须快照：任何修改代码的操作（新增/修改模块、改样式、升档）执行前，必须先把当前版本存入 versions/ 并记 CHANGELOG；回滚时保留 data/ 不动（代码回滚 ≠ 数据回滚）。
  • 服务器凭据红线（4D 第一节）不可违反；服务器上只做加法、命令先列清单后执行。
  • 公网部署必须登录 + HTTPS，不存在例外。
  • 小程序先分流自用/发布；原生先展示成本卡再动手。
  • 界面风格不问开放题，一律走 Phase 2.7 选择题 + 参考物取色；Path B 未过 style-preview.html 样张确认不得铺开开发；可读性底线（对比度/字号/色盲友好）不因用户偏好妥协。
  • 用户未确认设计文档摘要前，不进入大规模编码（MVP 单模块除外，且需先说明）。
  • 续接优先：检测到 docs/ 存在时先读文档恢复上下文，不从头走流程（核心原则 8）。
  • T2 局域网 PIN 必须服务端校验，前端校验不算数。
  • start 脚本必须处理端口冲突，不裸报 EADDRINUSE 退出。
  • 完成后如实描述现状：哪些模块可用、哪些是占位、数据存在哪、跑在哪一档、有什么风险，不夸大。

了解 ~/jintaoblog/朝夕见闻志⚡️ 的更多信息

订阅后即可通过电子邮件收到最新文章。