对话档案 D11 · 笔记站功能大迭代（11-11~11-14）
一句话：三天半、一个会话、7.67 亿 token，把一套只能看笔记的小站改成了带表格引擎、白皮书体系、14 篇说明书、权限模型和版本治理的完整产品——这是全项目最贵的一段，也是唯一一段「写完还要自己证明能用」的工程。
一、这段对话怎么走的
本段与 D10 同属 11-11 主会话（cwd = C:/Users/cag/WorkBuddy/2026-11-11-09-21-47，tokTotal = 767,433,000，133 条用户消息，4914 次工具，4539 次 API，跨度 11-11 09:21 至 11-14 11:02），加上 11-12、11-13 两段续会话（1127.8 万 + 130.7 万）。任务不是按「天」推进的，是按「簇」——每簇围绕一个能力面，做到验收通过才收手。
扫描数据只有会话级 tokTotal，切不出每一簇的 token。因此下表用证据密度（记忆日志条目数、验收断言数、涉及文件数）标注体量，token 一栏只给整段值，不编造分摊。
最费 token 的三簇，以及为什么
第一是 C 表格。它包含一次完整的方案评审（notes/表格功能方案.md 439 行，含四方案对比与 Q1–Q7 决策清单）、三轮 P1/P2/P3 落地、以及之后五次形态追加（逐边边框、裸表、文件夹、折行对齐、版本清理）。每加一层都要重跑全套断言——累计 210 条，且每次都要 next build + Playwright 截图 + 人眼比对。表格是所有功能里唯一「渲染结果必须像素级正确」的，table-layout:fixed + <colgroup> 显式列宽 + 只画合并锚点格这三条铁律，是踩了「合并单元格错位」「手机端列宽失真」之后才定下来的。
第二是 D 手册。14 篇正文、约 8.5 万字、89 张配图（notes/manuals/*.md 实测），每篇 11 条验收断言。成本不在写，在配图流水线：scroll-behavior:smooth 让坐标量偏、clip 是文档坐标而 boundingBox 是视口坐标混算必错、贴视口边缘的角标会被裁掉——三个坑各修一次，才跑通「注入红框 + 编号角标 + 裁切」的自动化。
第三是 G 隧道。它是唯一「改代码没用」的簇：本机配置、证书链、frpc 全部正确，故障在平台侧 443 屏蔽与 Windows 优先使用 IPv6 DNS（fe80::1 → 路由器缓存旧 IP 184）。这一段跨 11-13 16:35 到 11-14 全天，中间全是无效分支（改代理名复现、TXT 验证、双隧道并存），token 花在反复验证「我这边没问题」上。
二、用户的关键原话
「有些新问题：笔记站读取不到主页登陆的信息。复现：主页登陆，笔记站导入私密笔记，失败：因为需要先登陆。期望：登陆信息全站共享。此外，用户生成的笔记要允许登陆用户设置为私密。」
现象、复现、期望，三段齐全，还顺手把下一个需求（私密开关）挂在同一条消息里。结果是同一个根因（密钥缓存）被一次定位，两个需求一起进设计。
「下面这些需要逐个依次处理,针对每一条都要进行扩展决策后再进行。」
一句话定下了整场迭代的节奏：批量提问题，但要求逐条扩展、逐条决策。这是 D10「一个个确认」的升级版——问题可以一次给 8 条，决策必须一条一条来。
「给词汇站和笔记站做一个简要但全面的功能介绍。此外，要求每篇笔记更新版本的时候，允许添加自己想要的方向。1. 允许用户添加关键词……2. 允许用户引导格式白皮书……3. 笔记内有多版本的时候，要提供差异化同屏功能。」
一段话里塞了功能介绍、关键字字典、白皮书模板、差异同屏四件事，且每件都给了验收标准（「一次只展示两个版本左右对照」「左右都允许修改」）。这种「需求 + 判定条件」的写法，直接决定了后续能不能自动验收。
「总结上下文,生成新的笔记型交接白皮书。」
七个字触发了整个白皮书体系从「功能」变成「产品」：白皮书不再只是提示词容器，而是可以入库、评分、迭代、挂子篇、被检索的笔记。
三、成本与效率
整段 7.67 亿 token，占全库 15.7 亿的 49%——四天吃掉整个项目一半的消耗。拆开看更刺眼：tokIn 7.674 亿，tokOut 仅 265 万，输出占比 0.35%。4539 次 API 请求，平均每次带入 16.9 万 token 上下文。
这个比例说明成本结构：钱几乎全花在「把已有上下文重新讲一遍」，而不是「生成新代码」。4914 次工具调用，平均每次工具调用摊 15.6 万 token——每次读文件、跑 build、截图，都要连带重放一遍对话历史。这也解释了为什么「同一个会话干三天」比「三个会话各干一天」贵得多。
折算到任务粒度：133 条用户消息，平均每条 575 万 token。最贵的不是最长的那条指令，而是「验收—失败—修—再验收」的循环，一轮 3 到 5 次 API 调用，每条断言都在这个循环里被重放。
四、曲折点与评判
1. Prisma 引擎 DLL 被锁，输出目录迁了四次（★★☆☆☆）
3102 端口有个 SYSTEM 级孤儿进程锁着 query_engine DLL，普通权限 taskkill 拒绝访问，prisma generate 持续 EPERM。应对是不断换输出目录：generated/prisma → generated/db → generated/db2 → generated/db3，每换一次同步改 schema.prisma 的 output 与 lib/db.ts 的 import。这是典型的「绕过而非解决」，当时保住了进度，但留下了四个目录的技术债。正确做法应是先定位持锁进程（handle.exe / 重启服务）再 generate。
2. 层叠上下文把弹窗封印（★★★★☆）
入库弹窗被顶栏压住，查了半天 z-index 数值，真因是 main.page-shell 写了 position:relative; z-index:1——创建了层叠上下文，里面所有 fixed 弹窗对外只算 z-1，顶栏 sticky z-40 永远赢。改法是 z-index:1 → auto，一处修好同类问题。教训写进了日志：全局容器慎用 z-index，fixed 弹窗的层级要在 body 层比较。
3. 编辑器与渲染的度量差 9%（★★★★★）
用户报「编辑不折行、页面折行」。实测两处根因：autoFitGrid 用 'Segoe UI' 字体栈量字得 34.1px，页面实际是 ui-sans-serif, system-ui 栈加 .md table 的 13.5px→14px，实得 37.3px；内边距一边 7px×2、一边 9px×2。修法是抽 SHEET_FONT_FAMILY / SHEET_FONT_PX 常量、FIT_PAD_X=18、两端 CSS 强制同字体同字号同 padding，再写 scripts/sheet-refit.ts 对存量 19 张表重算（每张 +1 版本并注明）。这是全段最漂亮的一次排障：不猜、量出来、两端对齐、存量补救。
4. PassNAT 双坑：443 与 IPv6 DNS（★★★★☆）
节点 114.66.28.184 的 80/8500/15682 全开，唯独 443 TCP 超时，走代理外部视角同样不通——本机无解，换到 .183 节点即通。刚修完又断，第二层是 Windows 优先用网卡 IPv6 DNS fe80::1（路由器 RA 下发），IPv4 DNS 改了不代表 IPv6 改了。修法 netsh interface ipv6 set dnsservers name="以太网" source=static address=2400:3200::1。诊断工具链值得记：curl --resolve 强制 SNI+IP、curl --doh-url 绕运营商缓存、Get-DnsClientServerAddress 按 AddressFamily 分开看。
五、提示词与流程改进
反例：「把表格功能做好，参考 WPS。」 四个环节（存储/录入/引用/输出）混在一起，模型只能猜。实际产出会是「又一个能编辑但不能复制的网格」。
正例：先说清约束再选型——「真相只能有一份，出口可以有很多；渲染必须 DOM 不能 Canvas，因为 Canvas 表复制不进 WPS；WPS 双向通道都走剪贴板 text/html。」这三条一给，方案空间立刻收敛到 D 案（JSON 真相 + DOM 渲染 + 多出口），省掉一整轮试错。
反例：「检查一下手机端有没有问题。」
正例：「390×844 下巡查这 9 个页面，报每页 scrollWidth-clientWidth，非 0 就是横向溢出。」给了视口、给了页面清单、给了量化指标，验收才能自动跑。
反例：「验收一下。」
正例：「每篇 11 条断言：i 按钮唯一且带 ?from=manual:、跳转 200、返回条文案、手册页不再显示 i、配图 N/N 解码、0 个 4xx、0 JS 报错。」断言列表本身就是可执行规格。
六、可复用结论
- 成本在上下文重放，不在生成。 输出只占 0.35%，说明优化方向是「减少重放」——把长会话切成任务簇、每簇结束落一份交接白皮书，比换更便宜的模型有效得多。
- 像素级功能必须两端同源。 编辑器和渲染器一旦各自算字体、字号、padding，9% 的偏差就会变成「编辑不折行」。常量抽出来共享，比调参数可靠。
- 验收断言要写进任务里。 210 条表格断言、14×11 条手册断言，是这段迭代唯一能收敛的原因；没有断言的「优化」会无限延长。