对话档案 D03 · 考研词汇记忆网站从零搭建（10-10）

一句话：照一份自写的《考研词汇记忆网站行动手册》，从零搭出一个可用的考研词汇站（Next.js + Prisma + DeepSeek，含词条页、全站点词、联想气泡、natapp 外网穿透、每日定时重启），8 天、23 条真实指令、768 次工具调用、8535 万 token，最终跑到外网可访问。

一、这段对话怎么走的

阶段	用户要求	产出	卡点
1. 按手册建站	贴入整份行动手册：功能、数据库、API、Prompt、界面、API Key 存放位置、验收清单	kaoyan-vocab 项目骨架，本地 3000 端口可跑	手册是理想态，实际依赖版本与 Next/Prisma 组合有摩擦
2. 数据库对齐	「按照白皮书提到的单词,帮我重构数据库」并贴回 prisma generate 的输出	Prisma schema 重构 + seed 脚本，把白皮书词表灌库	重构会清表，seed 必须一次跑通，否则页面空白
3. 全站点词	「加一条功能,网页内所有的英文单词都可以进行点击生成或者跳转」	正文英文词可点击：库内有则跳词条，无则调 API 生成后入库	要区分"该点"和"不该点"的词，否则整页都是链接
4. 外网穿透	「使用natapp对此网站进行内网穿透…token告诉我放在哪里就行,我会复制过去」	natapp 隧道配置说明 + 外网地址	隧道只认本机 3000，服务一挂外网即断
5. 手机适配与体验	「对这个网站进行手机端适配」；随后要求动画、视觉突出、全站工具栏（临时笔记/对比/联想）	响应式布局、动效、工具栏、联想气泡（按相似度大小泡泡排列）	气泡重叠、点开新页导致联想状态重置
6. 稳定性收尾	「制作一个重启器,每天固定12点重启服务器和natapp,正好一天两次」；「反复验证三次能确定重启器正常工作」	定时重启脚本 + 三次外网连通验证	首次重启后「并没有重新开启,目前无法访问」

时间线：2026-10-10 22:00 起，2026-10-18 10:00 结束，跨 8 天。单段会话，1 个 jsonl，无合并；其间 57 条消息是后台命令的完成/失败通知，不是用户发言。

二、用户的关键原话

原话：「下面这份可以直接复制给 WorkBuddy 执行。我把它整理成《考研词汇记忆网站行动手册》，包含功能、数据库、API、Prompt、界面、API Key 存放位置和验收清单。」

这是两个月里最成熟的一种开场：把需求写成给执行方的施工文档，连"验收清单"都提前列好。它直接决定了这段对话的形态——不是边聊边改，而是照图施工。代价是手册写的是理想态，实际会撞上依赖版本、端口占用这类工程细节，手册越完整，模型越容易在"照做"和"改做"之间犹豫。

原话：「使用natapp对此网站进行内网穿透. http://qc58a6ca.natappfree.cc token告诉我放在哪里就行,我会复制过去.」

「token 告诉我放在哪里就行」这句很关键：用户主动划走了密钥保管的责任，只让模型指位置。这是安全意识，也避免了密钥进对话历史。副作用是排障时模型看不到隧道侧状态，只能从"外网打不开"倒推。

原话：「这个版本随机复习单词功能每次都是同一个单词。」

一句话点破一个典型 bug：所谓"随机"取的是固定下标或首条记录。用户是自己点了几下发现的——这说明验收动作在用户侧，模型侧只验证了"接口返回 200"。这类"功能通但逻辑错"的问题，靠跑通不等于靠跑对。

原话：「让程序在每生成20次之后,自动更新白皮书内容; 为网页制作一揽子动画…制作所有页面可用的工具栏,工具栏包括临时笔记, 对比工具, 联想工具…按照联想相似度用大泡泡小泡泡进行排序…」

一条消息塞进五个功能，且每个都有交互细节（气泡排序、悬浮动画、点进去看联想原因）。这是需求演进的典型形态：站点能用之后，用户开始按"产品"而不是"工具"提要求。它把项目从 CRUD 推向了交互设计，也是后面气泡重叠、层级返回问题的源头。

三、成本与效率

指标	数值
token 总量	8535 万（0.853 亿）
其中输入 / 输出	8502 万 / 32.6 万
用户消息数	82 条（统计口径；其中真实指令 23 条，后台任务通知 57 条）
工具调用	768 次
API 调用	698 次
每条消息平均 token	104 万（真实指令口径 371 万）
平均每次工具调用 token	11.1 万

模型为 fast-model 与 deepseek-v4-pro 混用。输入输出比 261:1，说明绝大部分消耗在"把整个项目文件树和命令输出反复塞回上下文"，而不是生成代码。768 次工具调用对应 698 次 API，平均每次 API 只做 1.1 个动作——这是"一次命令一次往返"的碎步模式，不是批量执行。

四、曲折点与评判

1. npm run start 连续失败。 57 条后台通知里有大量 failed / killed，命令几乎都是同一条启动命令。根因是工具链：端口被上一次没退干净的进程占着，模型看到失败就重试，没有先查端口占用。正确顺序应是"先 netstat 看 3000 被谁占，杀进程，再启动"，一次就够。
2. 气泡重叠与层级重置返工。 用户先提"气泡过大导致重叠"，改完又发现"双击打开新页面后联想工具会重置"，要求改成叠加层 + 模糊背景 + 返回保留状态。根因是只验证一半：第一轮只看了静态排布，没走"点开—返回"的完整路径。
3. 随机复习永远是同一个词。 功能"能跑"就交付了，没人验证第二次点击的结果是否变化。根因是验收缺失，而且是最便宜就能补上的那种验收——连点三次即可。

曲折度：★★★★（工程摩擦密集，但每次返工范围可控，没有推倒重来）

五、提示词与流程改进

1. 反例：反复执行 npm run start，失败就重试。 正例：「启动前先检查 3000 端口占用，有残留进程先结束再启动；启动后用 curl 探一次首页状态码，再报成功。」 把"重试"换成"定位"，一次解决端口类问题。

2. 反例：「加一条功能,网页内所有的英文单词都可以进行点击生成或者跳转。」 正例：「正文英文词可点，但需排除代码块、公式、专有名词白名单；点击后行为分两种：库内有词条则跳转，无则后台生成并给出加载态；验收：任取 3 个词各点一次。」 功能描述要带排除项和验收动作，否则"所有"会变成"全部乱链"。

3. 反例：「先重新验证一下重启器的功能」（验证什么没说）。 正例：「重启后按三项验收：本机 3000 返回 200、natapp 外网地址返回 200、连续两次重启均成功，把三次结果贴给我。」 把"验证"变成可勾选的清单，才能避免"并没有重新开启"这种回退。

六、可复用结论

1. 用"行动手册 + 验收清单"开场是这类建站任务的最优解，但手册要留一句"遇阻先报告再改方案"，否则模型会在照做与改做之间反复。
2. 后台命令反复失败时，先查端口与残留进程，再谈重试；重试是掩盖，不是修复。
3. 带交互的功能必须走完整路径验收（点开—返回—再点开），只验证首次渲染等于没验证。