时间都去哪儿了？

前阵子我粗略算了一下过去 3 个月我光是手写 prompt、翻记录、拼周报差不多花了 12 个小时。平均下来每周 50 分钟左右。这里面写字的时间其实不多大头都花在找材料上翻 GitHub看这周提交了什么翻 Jira看哪些 ticket 还在自己手里最后再把这些碎片凑成一段还算体面的文字。有一次快写完的时候同事突然问我你这周 GitHub 上那个 PR 进度怎么样了我才发现那个 PR 被我漏掉了。不是没做也不是故意不写。就是翻到一半已经快到 deadline 了脑子开始只想赶紧交差于是漏了。结果周报看起来像是我这周只做了一个小需求。这件事挺小但让我开始认真想周报最累的地方可能不是写而是每周都要重新把自己做过的事捞一遍。什么是 loop简单说loop 就是让 AI 不只回答一次而是按一套流程反复跑直到条件满足才停。以前的做法是我写 promptAI 给结果然后结束。Loop Engineering 更像是我先设计一套流程让它定时拉数据、生成草稿、检查结果如果没过检查就停下来留下原因。所以它和 cron 不太一样。cron 只是到点执行脚本。它不关心脚本结果好不好也不会自己判断下一步该做什么。loop 里面多了一层判断现在拿到了什么数据够不够写哪里缺了能不能继续。这层判断很麻烦。也正是这层判断让它不只是定时跑一下 AI。你的任务适合做成 loop 吗不是所有重复任务都值得上 loop。我现在会先看四件事这件事是不是每周都会发生跑完之后能不能看出来成功还是失败中途失败后能不能从失败点接着来省下来的时间值不值得维护这套流程如果这四条里有两三条都说不清先别急着自动化。写个一次性脚本或者继续手动做可能更省心。周报这个场景比较适合。它每周发生输入数据也比较清楚GitHub、Jira、日历、文档。问题是这些数据分散在好几个地方人每周手动捞一遍很容易漏。5 个组件怎么落到周报场景Addy 的文章里提到 5 个组件再加一个贯穿全程的 MemoryAutomations、Worktrees、Skills、Plugins、Sub-agents以及 Memory。我第一次看这套东西时也有点头大。名词很多但放到周报里其实可以拆得很朴素什么时候跑、按什么模板写、从哪里拿数据、在哪里隔离运行、谁来检查、怎么记录上次失败。1 Automations每周五 18:00 跑一次Automation 就是闹钟。不过这里别手写一个看起来像配置文件的 YAML然后期待 Codex 自动识别。更稳的做法是在 Codex 桌面 App 里打开 Settings - Automations - New automation填这几项Nameweekly-report-loopSchedule每周五 18:00Workspace / CWD周报工作区比如~/weekly-report-loopExecution environment第一版先选localPrompt让 Codex 读取company-weekly-reportskill按>2 Skills把周报要求写清楚Skill 是这套流程的说明书。路径可以放在~/.codex/skills/company-weekly-report/SKILL.md。一个最小版本大概长这样--- name: company-weekly-report description: Generate a weekly company report draft from GitHub/Jira evidence, with source citations and a reviewer gate. --- # 目的 按公司周报模板把本周工作汇总成文档标注完成度与风险。 # 模板位置 - references/template.md # 公司模板10 段固定结构 # 数据源用 MCP不要让 Agent 自己爬网页 - GitHub connector / MCP本周 commits、PR、review、issue - Jira connector / MCP本周更新过、由我负责或参与的 tickets - 如果 Jira 没接好不要猜写入 [数据缺失需补充Jira] # 产物路径 - raw/week-{W}.json原始证据只放结构化数据和来源链接 - draft/week-{W}.md周报草稿 - review/verdict-{W}.jsonreviewer 的结论必须包含 pass 和 reasons - state/progress.md每次运行追加一段状态 # 写作约束 - 每条 bullet 必须有数据源引用 [src:github:abc123] - 数字必须从 connector / MCP 返回禁止 Agent 编造 - 不要写下周计划超过 5 条 # Gate - reviewer 必须检查全文每一段是否有来源 - review/verdict-{W}.json 里的 pass 不是 true就不要发布这里最值得花时间写的是两块数据源和写作约束。周报最怕的不是写得不漂亮而是 AI 很自然地补一句看似合理的话。尤其是数字没来源就别写。3 Plugins先把数据接上Plugins 或 MCP 连接器负责让 Codex 读到外部数据。周报里至少要接 GitHub。如果你们公司有 Jira/Atlassian connector或者内部 MCP再把 Jira 接上。# 先看当前 Codex 里有哪些插件 codex plugin list # 当前 Codex CLI 的安装命令是 add不是 install codex plugin add githubopenai-curated如果 Jira 不是插件市场里的现成 connector而是公司内部 MCP可以用这种方式接codex mcp add company-jira --url https://your-company.example.com/mcp装完先确认一下codex plugin list codex mcp list只读周报不应该给写权限。能读就够了。repo:write这种权限除非你真的要让它开 PR否则别给。4 Worktrees第一版不用急Worktrees 是隔离运行环境。要是这个 loop 会改代码、开 PR、跑测试那最好给每个 agent 单独的 worktree。但周报第一版只是读数据、写草稿用local就够了。等它稳定跑两三周再考虑改成 worktree 环境。先跑通比一上来把架构搭满更重要。5 Sub-agents把三步写进 prompt这里不用急着发明一套流水线配置。第一版最容易跑通的办法是在 automation prompt 里把三步写清楚请按三步执行 1.>6 Memory把上次失败记下来Memory 先别想复杂。第一版就放一个state/progress.md。# Weekly Report Loop State ## Last Run - week: 2026-W23 - raw_path: raw/week-2026-W23.json - draft_path: draft/week-2026-W23.md - verdict_path: review/verdict-2026-W23.json - gate_passed: true ## Backoff - consecutive_failures: 0 - next_attempt_at: 2026-06-12T18:00:0008:00 ## Failures Log - 2026-W19: gate_failed(reviewer caught hallucinated ticket count)不要默认 App 会帮你维护这个文件。把每次运行必须追加 state/progress.md写进 automation prompt 和 SKILL.md。下一次运行时先读上一次为什么失败再决定要不要继续。我踩过的 3 个坑跑起来之后我遇到过几个很烦的问题。不是大事故但足够让人不敢直接全自动发布。踩坑①安静失败Quiet Failure有一次周五 18:00 触发后Jira token 过期了。data-fetcher 没有明确报错只返回了空数据。drafter 看见空 raw就写了一句本周无 Jira 进展。reviewer 只检查引用是否一致所以也过了。周报发出去以后周一才发现少了一大块。后来我加了三条规则data-fetcher 失败时必须写state/fetch-error.md不写就当整个 loop 失败。connector 报错或返回结构异常时直接停止不进入 drafter。如果本周 commits 和 tickets 都是 0reviewer 要直接 fail除非 raw 里有明确的休假或停工证据。踩坑②周报幻觉Weekly Report Hallucination另一次模板里有用户增长段落但 GitHub 返回的只是后端 commits。drafter 顺手写了一句本周 DAU 上升 12%。这数字完全没来源。reviewer 当时没拦住因为它只检查了有引用的段落。没有引用的段落反而被跳过去了。后来我把规则改成没有原始数据的段落写[数据缺失需补充]。reviewer 扫全文不是只扫有引用的行。DAU、MAU、转化率这类业务指标只能来自数据看板 MCP不能从 commit 或 PR 里推断。踩坑③Token 失控Token Runaway还有一次reviewer fail 了。automation 重试时drafter 把上周 draft 当作上下文示例塞了进去。重试几次后token 消耗开始变得离谱。这类问题不一定马上炸但它会让你越来越不敢开自动化。