AGI 未来之门

主题

AI 周报生成器实战 ​

写周报的真实流程是：翻 Git 记录回忆这周干了什么 → 翻任务系统确认哪些完成 → 翻聊天记录找遗漏 → 组织语言。80% 的时间花在收集，不是写作。这是典型的可自动化场景：数据源固定、格式固定、每周重复。

本教程委托 AI Agent 实现一个周报生成脚本：每周五自动收集 Git 提交、任务状态和会议纪要，合并成"事实清单"，再让模型按团队格式写成周报草稿发到你邮箱——人扫一眼、转发，全程 2 分钟。

1. 先看最终效果 ​

周五 16:00，邮箱收到：

text
主题：周报草稿-请过目（2026-09-14 ~ 2026-09-18）

本周完成
- 完成用户登录接口限流改造（#8823 相关，4 次提交合并）
- 修复订单状态机并发问题，补充 6 个回归用例

进行中
- 公共鉴权中间件提取，预计下周二提测

下周计划
- 支付模块联调（依赖风控侧接口，已约定 9.23 对齐）

风险与求助
- 测试环境证书周五过期，需要运维协助续期

你核对一遍事实，改动不超过一两句，转发。一个月后回看：因为内容全部来自事实清单，被打回次数应该是 0。

2. 项目边界与验收标准 ​

text
输入：Git 提交记录、任务系统状态（或手写任务清单）、3 行会议纪要。
输出：Markdown + 纯文本周报草稿，发送到自己的邮箱。
脚本负责：采集、去重、合并事实清单、调模型、发邮件。
模型负责：只根据事实清单"表达"，禁止添加清单之外的工作项。
人负责：核对事实、转发、维护自己的提交信息质量。

不做：自动发送给领导、读取聊天记录、爬取公司内部系统。

验收标准：

  • [ ] 草稿中每一个工作项都能在事实清单里找到出处；
  • [ ] 同一需求的多次提交合并成一句话，不同需求禁止合并；
  • [ ] 模型不可用时，脚本仍能发出"原始事实清单"版邮件（降级可用）；
  • [ ] 定时触发准确，日志可查。

3. 委托 Agent 实现 ​

在任意目录启动你的 AI 编程 Agent（选型见《60 秒选型》），粘贴这份委托提示词：

text
在当前目录实现一个"AI 周报生成器"Python 项目，请先给方案再写代码。

## 功能
1. collect.py：用 git log --all --author=我 --since="7 days ago"
   --pretty=format:"%ad | %s" --date=short 拉取本周提交；
   读取 todos.txt（每行一条任务状态，我手写）和 notes.txt（会议纪要）。
2. merge：三源合并为一个"事实清单"文本块，分三节：本周代码提交 /
   本周任务状态 / 本周会议与事件，去重。
3. generate：调 OpenAI 兼容接口生成周报。系统提示词规则按顺序：
   (1) 只使用事实清单中出现的内容，严禁编造或推测任何工作项；
   (2) 按"本周完成 / 进行中 / 下周计划 / 风险与求助"四段输出；
   (3) 同一需求的多次提交归为一句话，不同需求禁止合并；
   (4) 动词开头的工作描述；总长 300 字以内。
   temperature=0.3。BASE_URL / API_KEY / MODEL 全部走环境变量。
4. send：SMTP 发纯文本邮件到 REPORT_TO（默认发我自己，
   主题带"草稿-请过目"）。SMTP 密码走环境变量，禁止硬编码。
5. 降级：模型调用失败时，直接把事实清单原文作为邮件正文发出，
   主题标注"[降级] 未生成，仅事实清单"。
6. 日志：每次运行追加 run.log，含开始时间、各步骤耗时、成败。

## 交付物
- 可运行代码 + requirements.txt + .gitignore（排除 .env、run.log）
- README：环境变量表 + crontab 配置示例（每周五 16:00）
- 单元测试：事实清单合并的去重逻辑、降级路径（mock 模型失败）

## 验收方式
我会准备一个测试 git 仓库和 3 行 todos.txt 跑全流程核对。

Agent 给出方案后先过一遍人工闸门：确认降级路径和"禁止编造"的提示词位置（必须在规则第一条）再放行。

4. 配置与首次运行 ​

bash
pip install -r requirements.txt

export REPORT_BASE_URL="https://你的中转站/v1"   # 或 http://localhost:11434/v1
export REPORT_API_KEY="sk-xxxxxxxx"
export REPORT_MODEL="gpt-5.5"                    # 以你的服务商为准
export REPORT_TO="me@company.com"

python main.py

打开邮箱核对草稿。重点核对三处：

  1. 有没有清单之外的工作项（有 = 提示词编造限制失效，回给 Agent 修）；
  2. 有没有把两个不相关需求合并成一句（语义错误，让 Agent 在提示词里加重申）；
  3. 动词开头、300 字内（格式纪律）。

5. 定时运行 ​

bash
# crontab -e（macOS/Linux，每周五 16:00）
0 16 * * 5 cd /path/to/weekly-bot && ./run.sh >> run.log 2>&1

Windows 用任务计划程序，脚本环境变量写在 run.sh / run.bat 里并加入 .gitignore。

6. 三个真实踩坑（提前规避） ​

  1. 提交信息质量决定周报质量。fix bug 喂给模型也写不出东西。给自己立规矩：提交信息按 type: 描述 写（feat/fix/test/refactor），一个月后周报质量自动上一个台阶；
  2. 模型会把不相关需求"合并同类项"。两条 fix 合成一句，语义就错了。对策在委托提示词里已写死（不同需求禁止合并），上线后仍要人工抽查前两周产出；
  3. 日历没有 API 就别硬接。用每周手写 3 行 notes.txt 代替，成本可控。为小收益过度工程是自动化最常见的失败方式，见《发现第一条工作流》。

7. 度量与迁移 ​

  • [ ] 记录自动化前的真实基线：写一次周报耗时多少分钟；
  • [ ] 跑满 4 周，统计被领导打回次数和你的平均核对耗时；
  • [ ] 用《工作流效果看板》的方法算收益：每周省下的分钟数 × 频率，对比维护成本。

跑稳之后这套"事实清单 → 模型表达 → 人确认"的模式可以直接迁移到日报、月报、述职材料——换的只是数据源和格式模板，脚本骨架不变。数据源也可以扩展：《n8n 邮件分类》归档的客户支持记录，就是支持工作量的天然事实来源。

8. 完成标准 ​

  • [ ] Agent 方案经人工闸门确认后才进入实现；
  • [ ] 草稿零编造（抽查 2 周 × 每条可溯源）；
  • [ ] 拔掉模型服务，降级邮件正常到达；
  • [ ] crontab 连续 2 周准点触发，run.log 无未处理报错；
  • [ ] 记录了基线耗时和 4 周后的实测耗时。

先找工作，再找工具。

AGI 未来之门