这篇能做出什么
照着做完，你会得到一条可复用的流水线：把一周的零散记录（Git 提交、待办清单、会议纪要）丢进一个本地目录，跑一条命令，产出一份 400～800 字的结构化周报。它满足三个可检查的标准：
- 每条产出都落到「动作 + 对象 + 数字 + 影响」四段式。例如：「把订单查询接口的缓存粒度从 5 分钟调到 30 秒，P95 延迟从 820ms 降到 340ms，覆盖每天约 12 万次调用。」
- 风险段落写清影响范围与需要的支持，而不是「继续跟进」这类无法验证的话。
- 全文控制在 1 分钟内读完，领导扫一眼就能看到数字和明确请求。
时间投入大致是这样：搭建流程约 30 分钟；之后每周约 10 分钟，其中 3 分钟收集素材、5 分钟人工核对数字、2 分钟微调措辞。相比从空白文档开始回忆一周干了什么，这条路径的差别在于——素材是现成的，AI 只负责排版和提炼，你负责核对事实。
前置条件清单
动手前先确认这几项：
1. 一个可调用的模型接口。可以是云端 API，也可以是本地部署的推理服务，只要提供 OpenAI 兼容的 chat/completions 接口即可。具体地址、模型名、计费方式以各服务商官方文档当前版本为准。
2. Python 3。用于跑收集、生成、校验三个脚本，版本以 Python 官方文档当前版本为准。只用标准库，不需要额外安装依赖。
3. 一个 Git 仓库。如果工作内容不在 Git 里，用任意文本文件代替也行，素材格式不影响流程。
4. 密钥管理方式。把密钥放进环境变量，不要写死在脚本里。
配置环境变量（bash）：
```bash
export LLM_API_KEY="你的密钥"
export LLM_BASE_URL="https://你的服务地址/v1" # 以官方文档为准
export LLM_MODEL="你的模型名" # 以官方文档为准
```
把这三行加到 ~/.bashrc 或 ~/.zshrc 末尾，之后新开的终端都能直接用。
目录结构建议这样组织：
```text
weekly/
├── prompt.md # 提示词模板
├── weekly.py # 生成脚本
├── check.py # 质量校验脚本
├── Makefile
├── raw/ # 原始素材
└── out/ # 生成的周报
```
先定义「领导爱看」的硬标准
「爱看」听起来主观，但拆开之后是可以打分的。用这五条约束模型输出，比反复调措辞有效：
- 结论前置：开头一句话说清本周整体状态，是「按计划」还是「有延期」。
- 数字先行：每条成果至少带一个可核对的数字，没有数字的写「待补充」。
- 状态分明：区分「已完成」「进行中」「受阻」，不要让三者混在一段里。
- 请求具体：需要支持时写清「谁、在什么时间前、给什么」。
- 篇幅有上限：超过 800 字就删，领导的注意力是有限资源。
这五条同时写进提示词和校验脚本，形成闭环。
建立素材池
周报写不出来，多数时候不是文笔问题，是一周的内容已经忘了。解决办法是让素材自动积累。
收集本周提交（bash）：
```bash
mkdir -p raw out
git log --since="7 days ago" \
--pretty=format:'%h %ad %s' --date=short \
> raw/git.log
```
统计代码改动量（bash）：
```bash
git log --since="7 days ago" --numstat --pretty=format:'--- %s' \
| awk '/^---/{msg=$0; next} NF==3 {add+=$1; del+=$2} END{print "新增行:", add, "删除行:", del}'
```
然后在 raw/week.md 里补三块内容，用纯文本写就行，不用讲究格式：
```markdown
本周任务
- 订单查询慢，排查到缓存粒度问题，已改配置并观察三天
- 对接支付渠道联调，卡在对方沙箱环境不稳定，已发邮件催
- 帮新同事过了一遍发布流程
会议要点
- 周三评审：下个迭代要接入对账系统，我负责接口部分
- 周五同步：运营反馈导出功能偶尔超时
零散数字
- 线上告警从 14 次降到 3 次
- 联调阻塞了 2 个工作日
```
这一步的关键是先记流水账，再让模型提炼。指望模型从「优化系统」四个字里写出量化成果，做不到。
写提示词模板
把 prompt.md 建好，内容如下（text）：
```text
你是一名严谨的汇报助理，只依据给定素材作答。
【写作要求】
1. 只使用素材中出现的数字、项目名、日期。素材里没有的数字一律写成「待补充」，
禁止推算、估算或补全。
2. 每条成果写成「动作 + 对象 + 量化结果 + 影响」四段式，一行一条。
3. 明确标注状态：已完成 / 进行中 / 受阻。
4. 风险部分必须写清三件事：影响范围、当前应对、需要谁在什么时间前给什么支持。
5. 全文控制在 800 字以内，用短句和列表。
6. 禁止使用「努力」「积极推进」「持续优化」「一定程度上」这类无法验证的词。
【输出格式】
一句话结论
本周产出
关键数字
风险与阻塞
下周计划（含预期完成时间）
需要的支持
【受众】
{{AUDIENCE}}
【原始素材】
{{RAW}}
```
{{AUDIENCE}} 是可变项，按汇报对象替换。给技术主管看，重点写技术方案和技术债；给业务主管看，重点写进度、影响面和交付时间；给更高层看，压缩到结果和资源请求。同一个素材，换一句话受众描述，输出结构会明显不同。
跑通生成脚本
weekly.py 只用标准库，直接调接口（python）：
```python
import os, sys, json, pathlib, urllib.request
API_KEY = os.environ["LLM_API_KEY"]
BASE_URL = os.environ.get("LLM_BASE_URL", "").rstrip("/")
MODEL = os.environ["LLM_MODEL"]
def call(prompt: str) -> str:
payload = {
"model": MODEL,
"messages": [
{"role": "system", "content": "你是一名严谨的汇报助理，只依据给定素材作答。"},
{"role": "user", "content": prompt},
],
"temperature": 0.3,
}
req = urllib.request.Request(
f"{BASE_URL}/chat/completions",
data=json.dumps(payload).encode("utf-8"),
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
},
)
with urllib.request.urlopen(req, timeout=120) as resp:
data = json.loads(resp.read().decode("utf-8"))
return data["choices"][0]["message"]["content"]
def main():
audience = sys.argv[1] if len(sys.argv) > 1 else "技术主管"
raw = pathlib.Path("raw/week.md").read_text(encoding="utf-8")
git = pathlib.Path("raw/git.log")
if git.exists():
raw += "\n\n## Git 提交\n" + git.read_text(encoding="utf-8")
tpl = pathlib.Path("prompt.md").read_text(encoding="utf-8")
prompt = tpl.replace("{{AUDIENCE}}", audience).replace("{{RAW}}", raw)
text = call(prompt)
pathlib.Path("out").mkdir(exist_ok=True)
out = pathlib.Path("out/report.md")
out.write_text(text, encoding="utf-8")
print(f"已写入 {out}，共 {len(text)} 字")
if __name__ == "__main__":
main()
```
运行（bash）：
```bash
python weekly.py "技术主管"
cat out/report.md
```
第一次建议先用自己上一周的真实素材试，比用示例数据更容易发现问题。
加一道质量校验
模型偶尔会漏掉数字，或者偷偷用上「持续优化」这类词。写个几十行的检查脚本兜住（python）：
```python
import re, sys, pathlib
text = pathlib.Path(sys.argv[1]).read_text(encoding="utf-8")
issues = []
量化密度：数字出现次数
nums = re.findall(r"\d+(?:\.\d+)?%?", text)
if len(nums) < 6:
issues.append(f"量化偏少：全文只有 {len(nums)} 处数字，建议每条成果都带数字")
不可验证措辞
filler = ["努力", "积极", "进一步", "一定程度上", "大力", "持续优化"]
hits = [w for w in filler if w in text]
if hits:
issues.append("含不可验证措辞：" + "、".join(hits))
待补占位
todo = text.count("待补充")
if todo:
issues.append(f"有 {todo} 处「待补充」，需要人工回填")
篇幅
if len(text) > 800:
issues.append(f"篇幅 {len(text)} 字，超过 800 字上限")
结构完整性
for section in ["一句话结论", "本周产出", "风险与阻塞", "下周计划"]:
if section not in text:
issues.append(f"缺少段落：{section}")
print("\n".join(issues) if issues else "检查通过")
```
运行（bash）：
```bash
python check.py out/report.md
```
校验只负责提醒，不负责改。看到「待补充」就去素材里翻，翻不到就删掉那条——宁可少写一条，也别放一个模糊的数字进去。
固化成一键流程
用 Makefile 把三步串起来（makefile）：
```makefile
.PHONY: collect report check all
collect:
mkdir -p raw out
git log --since="7 days ago" --pretty=format:'%h %ad %s' --date=short > raw/git.log
@echo "素材已收集，请补充 raw/week.md 中的任务与会议要点"
report:
python weekly.py "技术主管"
check: report
python check.py out/report.md
all: collect report check
```
每周五下午跑（bash）：
```bash
make all
```
屏幕上会先打印素材收集提示，再打印生成的周报，最后列出需要人工处理的问题。整个过程通常在一分钟内结束。
常见坑与排错
输出全是空话。 原因是素材太薄。检查 raw/week.md，如果只有三四行概括，模型只能把这几行换个说法。补足原始记录，尤其是数字和具体人名、系统名。
数字对不上。 模型有时会把「三天」和「3 次」串在一起。提示词里已经禁止推算，但仍要人工核对每个数字的来源。校验脚本报出的「待补充」必须逐个处理。
接口报 401 或 403。 多半是环境变量没生效。用 echo $LLM_API_KEY | head -c 6 确认前几位是否正常，注意新开的终端才会读到 ~/.bashrc 的新内容。
接口报 404。 LLM_BASE_URL 少了或多了 /v1，或者末尾多了斜杠。脚本里已经做了 rstrip("/")，剩下的按服务商文档核对路径。
超时。 素材太长时会更慢。urlopen 的 timeout 已经设成 120 秒，如果仍超时，先删掉 raw/git.log 里冗长的提交信息，只保留标题行。
内容不适合外发。 客户名、未公开的财务数据、内部代号不要直接传给第三方接口。写素材时用代号替换，或者在提示词里加一句「把方括号包裹的内容原样保留、不要改写」。对保密要求高的场景，改用本地部署的模型服务。
生成完就直接交。 留 5 分钟做三处人工干预：开头的一句话结论改成你自己的判断；风险段落里补上你才知道的背景；下周计划里把时间点写成具体日期。这五分钟决定了周报是「AI 味」还是「你的周报」。
下一步建议
- 按受众存多份提示词。
prompt-tech.md、prompt-biz.md、prompt-exec.md各存一份，脚本加个参数切换，同一周素材能产出三种版本。 - 做月度复盘。把四周的
out/report.md拼起来，用同一套流程生成月报，模板里把「下周计划」换成「趋势与偏差」。 - 接提醒机器人。用系统的定时任务在每周固定时间提醒收集素材，避免周五临时回忆。
- 建数字台账。把每周出现的关键指标记进一个 CSV，几个月后回看，述职和晋升材料基本就是现成的。
- 把模板纳入版本管理。提示词改了什么、效果如何，留个提交记录，团队里其他人也能复用。
流程搭好之后，周报的定位会变：它不再是每周五的负担，而是一周工作的自动留痕。你要做的只是保证素材真实、数字准确，剩下的交给脚本。