案例 · 周报打磨：批量任务的 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。
改造：拆成 skills flow
三步：① 后台收集三仓库提交 → ② 逐期
/grill-with-docs打磨 → ③ 人工补「其它工作」。下面每步都是能直接跑的指令 + 提示词，可复制。
第 1 步 · 后台收集三仓库的逐周提交
三个仓库各发一个 /research（后台并行，不占主 context）。提示词结构相同，只换仓库路径和输出文件名：
# 〔services〕仓库 —— 逐周提交汇总
/research 汇总仓库 /mnt/wsl/gt-1/var/lib/workspace/es/es-center-server-services 自 2026-06-01 到 2026-07-27 的全部 git 提交，按这 9 周分组：06-01/06-08/06-15/06-22/06-29/07-06/07-13/07-20/07-27。每周列出每条提交：commit hash、摘要、改动意图（从 commit message 推断）。每条标注为〔设计/决策〕或〔代码实现〕。结果写到 .ai/doc/weekly/source-services.md，带 hash 引用。# 〔web-app〕仓库 —— 同上，换路径与输出名
/research 汇总仓库 /mnt/wsl/gt-1/var/lib/workspace/es/es-center-server-web-app 自 2026-06-01 到 2026-07-27 的全部 git 提交，按上述 9 周分组，每条给 hash、摘要、改动意图，标注〔设计/决策〕或〔代码实现〕。结果写到 .ai/doc/weekly/source-web-app.md。# 〔install-app〕仓库 —— 同上，换路径与输出名
/research 汇总仓库 /mnt/wsl/gt-1/var/lib/workspace/es/es-center-server-install-app 自 2026-06-01 到 2026-07-27 的全部 git 提交，按上述 9 周分组，每条给 hash、摘要、改动意图，标注〔设计/决策〕或〔代码实现〕。结果写到 .ai/doc/weekly/source-install-app.md。跑完，三份 md 就是后续打磨的 primary source（在文件里，不在主 context 里）。
第 2 步 · 逐期打磨（每期一次 /grill-with-docs）
约定（CONTEXT.md 的项目简写 / 活动标签 / 术语）和结构（08-03 范本）都在文件里，跨期复用。从最早一期开始，每期一次，提示词只换日期和路径：
# 打磨 06-01 这期周报
/grill-with-docs 打磨 app/03-work/01-weekly-report/2026/06-01/page.mdx 这期周报。
素材：.ai/doc/weekly/source-services.md、source-web-app.md、source-install-app.md 中属于 06-01 这周的三仓库提交。
依据：项目根 CONTEXT.md 的项目简写 / 活动标签 / 术语；结构对齐 app/03-work/01-weekly-report/2026/08-03/page.mdx 范本。
要求：工作量按「设计 vs 代码」拆分计量；重度拆条，用 8 个活动标签归类；「其它工作」区域留空，由我手填，你不要生成。磨完一期 → 提交 → /clear（接近 smart zone 就 /compact）→ 接下一期。CONTEXT.md 有要改进的地方，顺手用 /domain-modeling 更新（它是跨期复用的活约定）。
为什么用
/grill-with-docs而非/grill-me—— 周报在 repo 内、且要维护CONTEXT.md这份约定（改进时更新）。grill-with-docs 正是”在 working directory 里 + 留痕维护约定”的那个。（对照案例 · 测试手册的一次性产出，用 grill-me。）
第 3 步 · 人工补「其它工作」
每期 page.mdx 里留空的「其它工作」（逐日杂项、协作沟通、线上排障）由你自己填——这是 AI 不生成、也不该生成的部分。
为什么这样拆
| 步骤 | skill | 补的短板 |
|---|---|---|
| 三仓库逐周提交收集 | /research（后台并行） | 9 周 × 3 仓库提交是 context 黑洞；分仓丢后台 |
| 维护约定/术语/标签 | /domain-modeling（grill 内） | CONTEXT.md 是活约定，改进时更新 |
| 逐期打磨成周报 | /grill-with-docs | 按约定 + 范本磨成双用途叙述；维护 CONTEXT.md |
| 批量 9 期节奏 | phase boundary | 每期一个 phase，边界 /compact；约定在文件里跨期复用 |
收益
- Context 健康：9 周提交分仓丢后台，主 context 每次只磨一期。
- 解耦被强化：提示词”格式在
CONTEXT.md+ 范本”的设计被 skills 做实 ——CONTEXT.md成为真正跨期复用的活 primary source。 - 人机分工落地：“设计·代码拆分计量”是这条 flow 的内建属性（设计计给你、代码计给 AI）；“其它工作”显式留给人工。
验收（可复用的成功标准）
- 每期符合
CONTEXT.md约定（项目简写、活动标签、术语）。 - 每期结构与 08-03 范本一致。
- 工作量按「设计 vs 代码」正确拆分计量（呼应人机分工）。
- 重度拆条 + 8 活动标签覆盖到位。
- 回修项深查看：列步骤名 + diff 证据。
- 「其它工作」区域留空待人工补，AI 不越界生成。