首页 / 周报 / 留档模板

留档模板

新一周开工时把这个文件复制成 weekly/2026-W37.html, 改掉 data-page、标题、周期,然后逐段填。 下面每段都带填写说明,删掉说明即可用。

复制后必改的三处 ① <body data-page="weekly/2026-W37.html">(否则侧边栏高亮错)
② <title> 和 <h1> 的周次
③ assets/site.js 的 NAV「周报」组里加一行, assets/search-index.js 末尾加一条

1. 页面骨架

<!DOCTYPE html>
<html lang="zh-CN" data-theme="light">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>2026-W37 周报 · xcmskills</title>
<link rel="stylesheet" href="../assets/site.css">
</head>
<body data-root="../" data-page="weekly/2026-W37.html">
<div class="layout">
<nav class="sidebar"></nav>       <!-- JS 填充,不要手写 -->
<main class="main">

  <!-- 正文在这里 -->

</main>
<aside class="toc"></aside>        <!-- JS 填充目录 -->
</div>
<script src="../assets/search-index.js"></script>
<script src="../assets/site.js"></script>
</body>
</html>

2. 正文结构(四大类固定顺序)

第一层永远是四大类,顺序固定,编号跟着大类走: W{周}-R{序} 需求 · -B{序} Bug · -E{序} 经验 · -P{序} 复盘。 某一类本周为空也要保留段落,放一个 <div class="sec-none"> 说明为什么空。

#段落写什么小类怎么分能不能省
0概要头 + kindbar + 速览表 四类计数 + 一行一条:大类 / 序号 / 一句话。不出状态列——状态在卡片徽章上 — 不能
1需求 字段单元:需求 / 模块 / 实现细节(可选 总结) 不分小类,直接 1. 2. 3. 排 空也留段
2Bug 字段单元:模块 / 问题描述详细版本 / 原因 / 解决方案 / 总结;净耗时不到一天的就别配深度块——时序表 / 罪魁配置的信息压进「原因」一段,路径写进「起止」一行 不分小类,直接 1. 2. 3. 排 空也留段
3经验总结 只在用户明确提出时才写——不要自己往里加。要写就是 .tip 块,末尾必带 tip-src(来源 + 适用场景),只收模块知识 / 工具用法 不分小类,直接 1. 2. 3. 排 空也留段
4问题复盘 只在用户明确提出时才写——不要自己往里加。要写就是四段:当时怎么想的 / 实际 / 代价 / 下次怎么改,末尾不接纪律自查清单(见 §3.8) 不分小类,直接 1. 2. 3. 排 默认空
5飞书周报 .feishu 块,一键复制成飞书能直接贴的纯文本 — 可省
6下周待办 有主语有动作,别写「跟进一下」 — 不能
7footer 相关链接 链到涉及的模块页 — 可省
经验总结 / 问题复盘默认不写,等用户提 这两类不要自己往周报里加——用户会自己提出要沉淀哪条。 自己觉得「这个手法挺好该记一下」而加进去的,基本都是对自己行为的复述, 读的人得整块跳过去。
段落保留(四大类顺序固定),里面放 <div class="sec-none">本周无</div> 就行。 真正可复用的模块知识写进对应需求 / Bug 卡的「总结」单元,那里读者一定会看到。
引用别的条目写标题,不写「Bug 2」「复盘 1」 正文和下周待办里指别的条目,把标题写出来: <a href="#rec-w36-b01">坠落重生落点在门外</a>。
反例:「提交 Bug 3 的日志补充 + Bug 4 的注释修正」——读者不知道 Bug 3 是什么, 得翻回速览表数一遍;而且条目一增删,序号就全错位。序号是给这一页排版用的,不是条目的名字。
复盘不是自我检讨,是流程补丁 「下次怎么改」必须是可执行的动作,不是态度表态。 反例:「以后更加认真」。正例: 「报完成前先 grep 产物,搜不到就是没编译」。
上周开工、这周完成的任务写在哪 小耗时的只写完成周,正文加一行「起止」;大耗时的两周都写, 用 §3.7 的进度块。完整判据见 周报总览 §3.4。

3. 现成积木

3.1 概要头

周期09/07 – 09/13
需求0 个
Bug0 条
经验总结0 条
问题复盘0 条
分支zhaozibo_071
<div class="wk-head">
<!-- 四大类各一格,顺序固定,0 也要写出来 -->
<div><span class="wk-head-k">周期</span><span class="wk-head-v">09/07 – 09/13</span></div>
</div>

紧跟在概要头后面的是 kindbar 四大类跳转条:

<div class="kindbar">
<!-- k-req / k-bug / k-exp / k-post 决定配色,顺序不能改 -->
<a class="kind k-req" href="#req">
  <span class="kind-n">01</span>
  <span class="kind-t">需求</span>
  <span class="kind-c">1 个 · 关卡工具</span>
</a>
</div>

3.2 需求卡

固定四段背景 / 做法 / 影响面 / 验收,缺一段都不算留档。 真实例子见 W36-R01。

W37-R01 【模块名】需求一句话(做了什么,不是为什么)
背景
策划原来配不出什么 / 现在只能怎么绕。一句话说清痛点,别写需求文档全文
做法
改了哪几层、参照了哪个已有实现。照抄某个同类实现的,把那个实现的文件行号写上
影响面
动了什么、没动什么。存量配置是否受影响必须明确写
验收
怎么验的,具体到命令和产物。「编译通过」不算验收,要写「产物里搜到了 + 重启后策划看到了」
起止
提出 W37(09/07)· 交付 W37(09/09)· 净投入 1 天
「验收」这一段是最容易糊弄自己的地方 本项目 TS 改动必须编译产物才生效(npm run compile-base -- tsconfig.json if-log), tsc --noEmit 只做类型检查、一个文件都不写。 编辑器 Scheme 类改动还要重启编辑器(DynamicScheme 的 IsInit 缓存下拉列表)。 --noEmit EXIT=0 不是交付依据。

3.3 Bug 留档卡

W37-01 问题一句话标题(现象,不是结论) 排查中
现象
QA 报的原话 + 复现步骤 + 必现/偶现
环境
关卡 Id · UID · 服务器时间 · 分支
修法
具体到文件行号或配置字段
<div class="rec">
<div class="rec-top">
<span class="rec-id">W37-01</span>
<span class="rec-t">标题</span>
</div>
<div class="rec-body">
<div class="rec-f"><span class="rec-fk">现象</span>
  <div class="rec-fv">...</div></div>
</div></div>

3.4 时序表

18:20:42.850普通节点
18:25:02.613关键节点(红点)
18:25:05.800结束节点(绿点)
<div class="tl">
<!-- t-key = 红点关键节点,t-ok = 绿点,不加 = 灰点 -->
<div class="tl-row t-key">
  <span class="tl-time">18:25:02.613</span>
  <span class="tl-d">发生了什么</span>
</div></div>
时序表的时间戳必须来自日志原文 不要凭记忆写「大概三秒后」。把日志时间戳原样抄进来, 后面算「这一段耗了多久」才有依据,也才能区分「代码慢」和「玩家自己磨蹭」。

3.5 经验 tip 块

§3 经验总结用这个。tip-src 不许省—— 没有「来源 + 适用场景」的经验,三周后自己都想不起来在说什么。

W37-E01 · 一句话说清这条经验是什么
具体做法写在这里。要能照着做,不是感想。 命令、文件路径、判据都直接写出来。
来源:哪条 Bug / 复盘 · 适用:什么场景下能用

加 t-warn 变成警告色,用于「不这么做会出事」的那类:

W37-E02 · 这条是坑,不照做会踩
例:tsc --noEmit 不产出文件,改完必须跑真编译。
来源:W36-R01 · 适用:所有客户端 TS 改动
<div class="tip">              <!-- t-warn = 警告色 -->
<div class="tip-t">W37-E01 · 标题</div>
<div class="tip-d">具体做法</div>
<div class="tip-src">来源:... · 适用:...</div>  <!-- 必填 -->
</div>

3.6 复盘块

§4 问题复盘用这个。四段固定: 当时怎么想的 → 实际 → 代价 → 下次怎么改。 前两段是 rec-f,后两段是 post-cl 里的两个 post-cell。

W37-P01 我哪一步做错了(写动作,不写现象) 白花时间
当时怎么想的
当时的推理链,包括那个错误假设。这段最有价值,别美化
实际
真相是什么,怎么发现错的
代价 花了多久 / 返工几次 / 有没有让别人白等。写实际损失,不写「浪费了一些时间」
下次怎么改 可执行的流程补丁,编号分条。不是「以后更仔细」,是「报完成前先 grep 产物」
<div class="post" id="post-p01">
<div class="post-top">
  <span class="rec-id">W37-P01</span>
  <span class="post-t">标题</span>
  <!-- b-warn 白花时间 / b-err 方向全错 -->
  <span class="badge b-warn">白花时间</span>
</div>
<div class="post-body">
  <!-- rec-f ×2:当时怎么想的 / 实际 -->
  <div class="post-cl">
    <div class="post-cell pc-cost"><span class="post-ck">代价</span>...</div>
    <div class="post-cell pc-fix"><span class="post-ck">下次怎么改</span>...</div>
  </div>
</div></div>

3.7 附件路径

日志C:\Users\zhaozibo\Downloads\Client-backup-xxx.logcompr
视频未录制
配置Source/Config/...
3.8 纪律自查清单——有,但不写进周报 交付标准是功能模块界面遵循的东西, 自己照着逐条过,但不要把清单贴进周报——十行勾选框插在复盘后面,读的人得跳过去才能接着看, 影响阅读。真有没做到的,直接写进对应那条复盘的「下次怎么改」。

3.6 截图

<figure class="shot">
<!-- 图还没放进来时留这个占位,放好后删掉 -->
<div class="shot-miss">把截图放到 weekly/img/w37-01-xxx.png</div>
<img src="img/w37-01-xxx.png" alt="描述">
<figcaption><b>什么时候的图</b>:看点在哪</figcaption>
</figure>

3.7 跨周任务的进度块

只有大耗时跨周任务才用这个(判定见 周报总览 §3.4)。小任务只在完成周写一行「起止」就够。

W36-09 第 2 周 / 共 3 周 进行周的卡长这样 进行中
进度
65% 本周投入 3 天 累计 5 天 已完成:写清楚做完了哪几块 下周做:写清楚下周动哪几块
<!-- 编号沿用首次出现那周,不随周次变 -->
<span class="rec-id">W36-09</span>
<span class="rec-span s-cont">第 2 周 / 共 3 周</span>  <!-- 完成周去掉 s-cont -->

<div class="prog">
  <div class="prog-bar"><div class="prog-fill" style="width:65%"></div></div>
  <!-- prog-fill p-block = 红(卡住),p-done = 绿(本周做完) -->
  <div class="prog-meta">
    <span class="prog-pct">65%</span>
    <span>本周投入 3 天</span><span>累计 5 天</span>
    <span class="prog-line"><b>已完成:</b>...</span>
    <span class="prog-line"><b>下周做:</b>...</span>
  </div>
</div>
同一个任务两周的卡要能对上 完成周那张卡的「已完成」必须覆盖上一周写的「下周做」。 对不上说明中途换了方向——那就在卡里写明为什么换,别悄悄改。

4. 写完自查

[ ]
每个问题都有明确的根因结论,不留「待确认」 根因未闭环就标明待验证,不当作已解决
[ ]
时序表的时间戳来自日志原文,不是估的
[ ]
修法具体到文件行号或配置字段,不写「优化一下」
[ ]
走过的弯路写了 这是周报里唯一别人拿不到的东西,比结论值钱
[ ]
跨周的任务归周归对了 §3.4 · 小耗时只记完成周;大耗时两周都记 + 带进度
[ ]
records.html 加了索引卡,大类、问题类型和模块标签与周报一致
[ ]
site.js 的 NAV 加了这一周,search-index.js 加了条目
[ ]
下周待办有主语有动作,能判断做完没做完