案例 · 周报打磨：批量任务的 context 黑洞
原提示词：
gt-main-site-web-app/.ai/prompt/2026/0724/0909/plan-01.md—— 周报打磨。
这份提示词在做什么
- 输入：9 期周报目录（06-01 ~ 07-27）+ 三仓库 git 提交（services / web-app / install-app，简写见
CONTEXT.md）。 - 约定：写法约定在项目根
CONTEXT.md，格式范本在app/03-work/01-weekly-report/2026/08-03/page.mdx。约定或范本改进时提示词无需改，只改「目标」日期。← 已把格式解耦。 - 人机边界：「其它工作」（逐日杂项、协作沟通、线上排障）由人工维护，AI 不自动生成。← 已划人机边界。
- 产物：9 期打磨后的
page.mdx。
它比案例 · 测试手册成熟：已经把格式解耦、也划了人机边界。剩下的短板全在执行。
诊断：执行上的两个坑
- 9 周 × 3 仓库的提交是 context 黑洞 —— 提示词把”三仓库逐周映射”当素材，一次性全读进主 context，9 周提交会撑爆 smart zone。
- 批量 9 期一口气磨完会糊 —— 9 期周报不该在一个 context 里连磨，该按期切 phase。
改造：编成可闭环的脚本，照着走、不临时问
心法：任务开始前把整条流程编成可复制粘贴的脚本，强迫自己按产出质量最好的方式走——「问太多、精力不够、context 不够」从源头消失。
三步：① 后台收集三仓库提交 → ② 逐期
/grill-with-docs打磨 → ③ 人工补「其它工作」。下面每个区块的标题就是在哪个会话跑——别在错的会话里粘。产物放.ai/doc/weekly/<YYYY-MM>/——.ai/doc/是长期文档目录（非.scratch/临时区），按月分目录，不同月份不覆盖、可回查。本次实例分为.ai/doc/weekly/2026-06/与.ai/doc/weekly/2026-07/。
【当前会话 · 一次性】准备 + 后台收集
# 准备：约定与范本在文件里、跨期复用，改约定不用改本脚本。
# 项目简写 / 活动标签 / 术语 → 项目根 CONTEXT.md
# 结构范本 → app/03-work/01-weekly-report/2026/08-03/page.mdx
# 后台按月收集各仓库提交：每个月分别运行多个 /research，结果落文件、不占主 context。
/research 汇总仓库 /mnt/wsl/gt-1/var/lib/workspace/es/es-center-server-services 自 {{月初}} 至 {{下月月初}} 的全部提交；每条给 hash、摘要、改动意图，标注〔设计/决策〕或〔代码实现〕。写到 .ai/doc/weekly/{{YYYY-MM}}/source-es-center-server-services.md。
/research 汇总仓库 /mnt/wsl/gt-1/var/lib/workspace/es/es-center-server-web-app，同上范围与标注。写到 .ai/doc/weekly/{{YYYY-MM}}/source-es-center-server-web-app.md。
/research 汇总仓库 /mnt/wsl/gt-1/var/lib/workspace/es/es-center-server-install-app，同上。写到 .ai/doc/weekly/{{YYYY-MM}}/source-es-center-server-install-app.md。
/research 汇总仓库 /mnt/wsl/gt-1/var/lib/workspace/es/es-ext-doc-website，同上。写到 .ai/doc/weekly/{{YYYY-MM}}/source-es-ext-doc-website.md。
/research 汇总仓库 /mnt/wsl/gt-1/var/lib/workspace/es/es-center-server-agent，同上。写到 .ai/doc/weekly/{{YYYY-MM}}/source-es-center-server-agent.md。
/research 汇总仓库 /mnt/wsl/gt-1/var/lib/workspace/es/es-qt-tools-map，同上。写到 .ai/doc/weekly/{{YYYY-MM}}/source-es-qt-tools-map.md。当月各仓库 md 齐了，本会话即可结束——后续每期另开新会话，不在当前会话里接着磨（避免收集阶段的 context 污染打磨）。
编排脚本别让人枚举 AI 能算的数据 —— 起止日期给了，「按周分组」就交 AI 推算，不让人手敲 9 个周一（费时、易漏易错）。判据：AI 能确定性理解、不跑偏的机械计算 / 枚举，就交给它；人只提供起止这类少量、不易错的锚点。进度台账的期号同理——让 AI 按起止日期生成，人只勾 ☐ / ✅。
【每期开一个新会话】逐期打磨
# 从最早一期起；把下面整段粘进【新会话】，只改 {{期号}} {{日期}}。
/grill-with-docs 打磨 app/03-work/01-weekly-report/2026/{{期号}}/page.mdx。
素材：.ai/doc/weekly/*/source-*.md 中属于 {{日期}} 这周的多仓库提交。
依据：项目根 CONTEXT.md 的项目简写 / 活动标签 / 术语；结构对齐 app/03-work/01-weekly-report/2026/08-03/page.mdx 范本。
要求：工作量按「设计 vs 代码」拆分计量；重度拆条，用活动标签归类；「其它工作」区域的具体内容由我手填（git 上无记录的杂项，如与人沟通、服务器运维、线上排障等），已有内容不要删除，仅润色通顺。
# 磨完 → git 提交 → /clear → 改 {{期号}} 粘进下一个新会话。CONTEXT.md 要改进，顺手 /domain-modeling 更新（跨期复用的活约定）。为什么用
/grill-with-docs而非/grill-me—— 周报在 repo 内、且要维护CONTEXT.md这份约定（改进时更新）。grill-with-docs 正是”在 working directory 里 + 留痕维护约定”的那个。（对照案例 · 测试手册的一次性产出，用 grill-me。）
【人工 · 无需 AI】补「其它工作」
每期 page.mdx 里留空的「其它工作」（逐日杂项、协作沟通、线上排障）由你自己填——这是 AI 不生成、也不该生成的部分。
git 存结果不存过程，「其它工作」是过程性隐性工作量的出口 —— 一次部署上线，git 上只有最终那次提交，而自测服务器 → 自测 → 测试服务器 → 向测试人员提供测试手册与版本更新日志（告知本次测什么）→ 测试中多次沟通这一整条过程，git 一行不记。它们既不是设计文档、也不是代码实现，“设计·代码拆分计量”量不到——正是 AI 时代仍由人做、却易被周报漏记的隐性贡献。「其它工作」交人工手填，正是为这部分过程性工作量兜底。测试手册与版本更新日志同出一条 flow，版本更新日志即测试手册的第一层（案例 · 测试手册）。
进度台账（续接锚点）
# 进度台账：期号由 AI 按起止日期生成，人只把 ☐ 改 ✅；开新会话前先看这里，定从哪期续。
# 06-01 ☐ │ 06-08 ☐ │ 06-15 ☐ │ 06-22 ☐ │ 06-29 ☐ │ 07-06 ☐ │ 07-13 ☐ │ 07-20 ☐ │ 07-27 ☐续接：能轻就轻，没更轻替代才上
/handoff—— 正常续接靠文件化状态：进度台账（上）+ 各期page.mdx+ source +CONTEXT.md全在文件里，新会话/clear+ 读文件起步即可——状态已落盘、没东西要搬运，这是/handoff的轻量等价替代。只有两种情况才升级到/handoff：① 打磨中途被迫换会话、且 grill 决策还没固化（够固化就先/to-spec，更轻——见常见困境第 4 条）；② 跨 harness / 跨人交接（/handoff买的是可移植性，这是它的本职）。判据照深入的 phase-boundary 决策树：没东西要移动，就不用它。
为什么这样拆
| 步骤 | skill | 补的短板 |
|---|---|---|
| 三仓库逐周提交收集 | /research（后台并行） | 9 周 × 3 仓库提交是 context 黑洞；分仓丢后台 |
| 维护约定/术语/标签 | /domain-modeling（grill 内） | CONTEXT.md 是活约定，改进时更新 |
| 逐期打磨成周报 | /grill-with-docs | 按约定 + 范本磨成双用途叙述；维护 CONTEXT.md |
| 批量 9 期节奏 | 每期一会话 + 进度台账 | 不在一锅 context 连磨；台账保证续接不丢期 |
收益
- Context 健康：9 周提交分仓丢后台，主 context 每次只磨一期。
- 解耦被强化：提示词”格式在
CONTEXT.md+ 范本”的设计被 skills 做实 ——CONTEXT.md成为真正跨期复用的活 primary source。 - 人机分工落地：“设计·代码拆分计量”是这条 flow 的内建属性（设计计给你、代码计给 AI）；“其它工作”显式留给人工。
- 留档即素材：source 按月留档在
.ai/doc/weekly/，年终总结、项目复盘时就是现成的事实底稿，不必重新挖。
验收（可复用的成功标准）
- 每期符合
CONTEXT.md约定（项目简写、活动标签、术语）。 - 每期结构与 08-03 范本一致。
- 工作量按「设计 vs 代码」正确拆分计量（呼应人机分工）。
- 重度拆条 + 8 活动标签覆盖到位。
- 回修项深查看：列步骤名 + diff 证据。
- 「其它工作」区域留空待人工补，AI 不越界生成。
上一篇：案例 · 测试手册 · 下一篇：案例 · 年度总结 →