6.2 KiB
改进周报 (2026-W38)
周期： 2026-09-14 ~ 2026-09-16（本周至今，周三）
生成方式： self-improving-agent 技能
数据来源： .learnings/ 日志、会话 transcript、workspace 配置文件实测
一、本周概览
| 指标 | 数量 |
|---|---|
| 新增学习条目 (LRN) | 5 |
| 新增错误条目 (ERR) | 1 |
| 新增需求条目 (FEAT) | 0 |
| 已解决 | 3 |
| 已升级到配置文档 | 1 条（涉及 TOOLS.md、MEMORY.md 两个文件） |
| 待处理 | 2 |
说明：
.learnings/本周首次启用（此前不存在），因此本轮为回溯补录—— 把此前散落在会话中的教训固化下来，避免下次再踩。
二、关键发现
🔴 1. 陈旧路径导致「技能找不到」假象
类型： correction ｜ 状态： ✅ 已修复
AGENTS.md 指向 skills/weekly-report-g5/SKILL.md，该路径不存在（实测返回 ENOENT）。
在用技能实际是 skills/weekly-report/SKILL.md；weekly-report-g5 只存在于 Skill Workshop 提案目录。
- 影响： AGENTS.md 是每次会话必读文件，错误路径会浪费工具调用，更可能让后续会话误判「技能不存在」而重复造轮子。
- 动作： 已修正路径，并补登自我改进技能条目。
🟠 2. 文档描述与实际行为不符
类型： correction ｜ 状态： ✅ 已升级
TOOLS.md / MEMORY.md 曾称 send_weekly_report.py 会「同步元数据到 db」。逐条核对脚本行为后确认：该脚本从不写 SQLite，只有两个落盘动作——
| 动作 | 目标 |
|---|---|
archive_report() |
Markdown → weekly-reports/YYYY/ |
sync_to_mysql() |
MySQL resume 库 |
- 风险： 后续会话会误以为 SQLite 已自动入库，从而漏跑
sync_reports_db.py，造成本地索引与 Markdown 静默不一致。 - 动作： 已修正两份文档表述。
🟡 3. shell 日期推导会「静默算错」
类型： knowledge_gap ｜ 状态： 待处理
2026-09-16（周三）实测：
| 表达式 | 结果 | 判定 |
|---|---|---|
date -d 'monday this week' |
2026-09-21 |
❌ 下周一 |
date -d 'last monday' |
2026-09-14 |
✅ 本周一 |
- 风险： 不报错、直接算出一周之后的区间，属「静默错误」，比崩溃更难发现。
- 对策： 周报日期范围一律以用户提供的任务日期为准，不用表达式推导。
🟡 4. 【已更正】我曾把「非待处理」误判为「待处理」
类型： correction ｜ 状态： ✅ 已更正
⚠️ 本条是本次复盘中最值得记的教训：我自己犯了一个「读错来源」的错。
首轮我报告「Skill Workshop 有两个 pending 的 weekly-report-g5 提案，虚高待办数」。该结论不成立——我读的是提案目录里 PROPOSAL.md 头部自带的 status: proposal，那只是静态正文标记，不代表生命周期状态。用权威入口核实后：
| 提案 | 真实状态 |
|---|---|
weekly-report-g5-20260626… (v1) |
stale（基线变动，无法再应用） |
weekly-report-g5-20260821… (v2) |
applied（内容确已并入在用技能） |
list --status pending |
No skill proposals matched |
- 正确做法： 判断提案状态只用
skill_workshop list。同理，任何「状态类」结论都应以对应工具/接口为准，而非文件表面内容。 - 动作： 已更正本条与
.learnings记录。经复核无需清理提案——本就不存在 pending，删除反而会丢掉 v2 已应用的历史记录。 - 副产品： 顺带确认这两个目录现仅存
PROPOSAL.md，原proposal.json/rollback.json已不在（2026-08-28 时还在），说明其间有 skill-collection-review 自动化做过迁移清理。
🎯 这正是本技能的价值所在：如果不做这轮复盘，这个误判会一直留在记录里，下次还可能照着错误结论去删东西。
🟢 5. 中文检索召回不可靠
类型： knowledge_gap ｜ 状态： 待处理
sessions_search 两次中文错误关键词查询均返回空，但同一会话 transcript 中确实存在对应内容。
- 风险： 会给出「什么都没发生」的假信号，让复盘遗漏真实错误。
- 对策： 错误复盘以
.learnings/为主数据源，sessions_search空结果不当作「无此事」。
三、本周已修复的错误
| 编号 | 问题 | 结果 |
|---|---|---|
| ERR-20260916-001 | /tmp 下运行脚本报 ModuleNotFoundError |
✅ 已解决（用 PYTHONPATH 指定模块路径） |
根因： Python 只把脚本所在目录加入 sys.path，cwd 不在其中。
教训： 临时脚本要么写在 workspace 内，要么运行前显式设 PYTHONPATH。
四、下周改进重点
- 已完事项复核 —— 本周两项均已当场完成：AGENTS.md 技能路径与格式残留已修正；提案核实后确认无需清理（不存在 pending）。
- 沉淀状态判断约定 —— 把「状态类结论只以工具/接口为准」写入规范：提案查
skill_workshop list、周报日期以用户提供为准。 - 沉淀运行约定 —— 把「PYTHONPATH / 脚本位置」、
date -d 'last monday'写进周报技能，避免下次再撞。 - 持续记录 —— 本周起
.learnings/已常态化启用，后续教训即时入账，不再依赖回溯补录。
五、方法论沉淀
本轮确立的复盘原则：
- 只用可核实证据 —— 每条结论都有实测输出或文件依据，不写推测性「体会」。
- 状态只看权威入口 —— 文件表面的
status字段不代表真实生命周期状态（本轮实际踩坑）。 - 区分「报错」与「静默错误」 —— 静默错误优先级更高，因为它不会被发现。
- 能修就当场修 —— 陈旧路径、文档不符等确定性缺陷直接修复，不留到「下次」。
- 结论需自检 —— 把误判写进记录后再核实，是有效的纠错方式（本轮靠它推翻了自身结论）。
归档时间：2026-09-16
日志位置：.learnings/LEARNINGS.md、.learnings/ERRORS.md