对话档案 D10 · 站点通用化改造（11-11）
一句话：把「考研学习导航」这块牌子从三个站点的界面上摘下来，换成中性的「学习导航」，全程只动文案不动结构，靠「先列清单、逐条确认」把一次品牌替换做成了 20 余处精确改动。
一、这段对话怎么走的
这是 11-11 主会话（cwd C:/Users/cag/WorkBuddy/2026-11-11-09-21-47）的第 1 条指令，也是整场 7.67 亿 token 长跑的热身段。用户在开头就把边界划死了：只改固有文本、不大修大改、先找出来再一条条批。
| 阶段 | 用户要求 | 产出 | 卡点 |
|---|---|---|---|
| 1 勘察 | 「找到需要修改的东西，然后申请我一个个决策」 | 全站「考研 / KAOYAN」字样清单，按站点分组 | 门户 5 页 + 词汇站 Next 代码 + 笔记站贴纸库，三套技术栈分散 |
| 2 逐条决策 | 一条条确认改或不改 | 决策记录（改 / 不改及理由） | 「考研」在部分位置是内部标识（目录名、AI 提示词），改了会连带故障 |
| 3 执行 | 按批准清单改文案 | 门户 index/login/register/me/notices.html 五页品牌；portal/index.html hero 徽标 KAOYAN · STUDY PORTAL → STUDY PORTAL、大标题改「学习导航主页」；portal/assets/guide.js 引导气泡；词汇站 layout.tsx 标题、page.tsx hero、Navbar 品牌；notes/lib/stickers.ts 贴纸词「毕业 考研 学位」→「毕业 学习 学位」 | 词汇站与笔记站是生产模式 Next，改完必须 rebuild |
| 4 构建重启 | 无（默认按部署铁律走） | next build（vocab + notes）→ 重启计划任务 KaoyanNextServer / KaoyanNotes；门户静态服务无需重启 | 生产模式不能在服务运行时 build |
| 5 验证 | 无（自检） | cag.quest 首页与 /vocab/ 均 200，页面已无「考研 / KAOYAN」字样 | 无 |
改名的颗粒度值得记一笔：门户首页两个功能卡从「考研词汇」类表述改成「词汇记忆站」「概率勇者 · 概率秘境」，词汇站词条页的「熟词僻义（重点）」和输入框 placeholder 里嵌的「考研写作」也被挑了出来——这类藏在 placeholder、<title>、引导气泡里的词，靠全局搜索 考研 才捞得干净。
有意保留的三处同样重要：portal/server.js 里的注释与 PROB_DIR 内部路径、实际目录名 kaoyan-vocab、lib/ 下的 AI 提示词。前两个改了会让服务找不到文件，第三个会改变生成风格——用户要的是「对外看不见考研」，不是「系统里消灭这个词」。
二、用户的关键原话
「过往任务中的网站结构中，可以把设计页面中关于考研的印象去掉，变成通用型的网站。只需要修改固有的一些文本即可，不要大修大改。找到需要修改的东西，然后申请我一个个决策。」
这句话里塞了四层约束：范围（设计页面）、深度（只改固有文本）、禁令（不要大修大改）、流程（先列清单再逐个批）。四层约束合起来，等于把一次可能演变成「重构品牌系统」的任务，压成了一次可验收的文本替换。
「找到需要修改的东西，然后申请我一个个决策。」
重复出现的「一个个」是这位用户最稳定的工作习惯：不接受「我顺手都改了」，要求每处改动都有一次明确授权。代价是交互轮次变多，收益是零返工——本段没有出现「改错了再改回来」。
「有些新问题：笔记站读取不到主页登陆的信息。复现：主页登陆，笔记站导入私密笔记，失败：因为需要先登陆。期望：登陆信息全站共享。」
改造刚收尾，用户立刻带着复现步骤报下一个问题。这种「现象 + 复现路径 + 期望」的三段式报障，在后三天的对话里反复出现，是把排障成本压到最低的关键写法。
三、成本与效率
去考研化本身没有独立的 token 计量——它与后续 20 余项任务共用同一个会话（tmp-scan.json 中该会话 tokTotal = 767,433,000，133 条用户消息，4914 次工具调用，4539 次 API 请求）。按用户消息序位判断，本段是整场会话最前段，工具调用量最小。
可核的整段数据：平均每条用户消息摊 575 万 token，每次工具调用摊 15.6 万 token。这两个数字在 D10 这个阶段还只是「正常偏大」，到 D11 的表格与白皮书阶段才真正失控。
从改动量看，本段效率很高：改动集中在 8 个文件、约 20 处字符串，一次 build 一次重启即收敛，没有二次返工。真正的成本不在改，而在「确认哪些不该改」——kaoyan-vocab 目录名和 AI 提示词这两处，是靠人判断保下来的，不是靠搜索能自动得出的结论。
四、曲折点与评判
1. 「考研」的双重身份（★★★★☆）
这个词既是界面文案，也是目录名、环境变量路径、提示词语料。全局替换会把后者一起打碎。处理方式是分类而非一刀切：面向用户的文案全改，内部标识全留，并在日志里写明「未动（有意保留）」及理由。这个「显式记录不改」的动作，比改本身更有价值——三天后回看仍能说清为什么 kaoyan-vocab 还在。
2. 生产模式的重启纪律（★★★☆☆）
词汇站与笔记站跑的是 next start，不是 dev。改完必须 Stop-ScheduledTask → next build → Start-ScheduledTask，顺序错了会 ChunkLoadError。这条纪律在本段第一次被踩实，之后三天反复引用（11-12 日志里还专门记了 LastTaskResult 267009 = 正常、267014 = 连停连起导致的时序问题）。
3. 品牌词的残留面（★★★★☆）
首轮搜索容易只扫 page.tsx，漏掉 layout.tsx 的 metadata、guide.js 的气泡文案、stickers.ts 的关键词表、以及输入框 placeholder。本段最后靠「搜 考研、搜 KAOYAN、再人工过一遍页面」三层才收干净，验证口径是「页面已无该字样」而不是「代码里搜不到」。
五、提示词与流程改进
反例：「把网站里关于考研的内容都去掉，改成通用的。」 问题在于没有范围（设计页面还是全部代码）、没有深度（改文案还是改结构）、没有流程（直接改还是先确认）。模型极可能顺手重构品牌组件、重命名目录，然后站点起不来。
正例（即用户原话）：「只需要修改固有的一些文本即可，不要大修大改。找到需要修改的东西，然后申请我一个个决策。」 补一条更省事的写法：「先输出一份清单（文件 / 行 / 原文 / 建议改法 / 风险），我批完再动手。」把「一个个决策」的交互成本前移到一次性评审，能省掉十几轮往返。
反例：「改完重启一下。」 正例：「生产模式：先 Stop 计划任务，再 build，再 Start；build 期间不要有其他会话在跑验收。」把部署顺序写进指令，比事后从 ChunkLoadError 反推要便宜得多。
六、可复用结论
- 品牌替换的本质是分类，不是替换。 先分「对外文案 / 内部标识 / 影响行为的语料」三类，只改第一类，并在日志里显式写下后两类为什么不改。
- 「先列清单再逐条批」适合不可逆或跨栈的改动。 一次评审换零返工，比「边改边问」省 token 也省心。
- 验收口径要落在用户可见层。 「页面已无该字样 + 首页与 /vocab/ 均 200」比「代码里搜不到」更接近真实目标。