125 lines
6.2 KiB
Markdown
125 lines
6.2 KiB
Markdown
# 改进周报 (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`。
|
||
|
||
---
|
||
|
||
## 四、下周改进重点
|
||
|
||
1. **已完事项复核** —— 本周两项均已当场完成：AGENTS.md 技能路径与格式残留已修正；提案核实后确认**无需清理**（不存在 pending）。
|
||
2. **沉淀状态判断约定** —— 把「状态类结论只以工具/接口为准」写入规范：提案查 `skill_workshop list`、周报日期以用户提供为准。
|
||
3. **沉淀运行约定** —— 把「PYTHONPATH / 脚本位置」、`date -d 'last monday'` 写进周报技能，避免下次再撞。
|
||
4. **持续记录** —— 本周起 `.learnings/` 已常态化启用，后续教训即时入账，不再依赖回溯补录。
|
||
|
||
---
|
||
|
||
## 五、方法论沉淀
|
||
|
||
本轮确立的复盘原则：
|
||
|
||
- **只用可核实证据** —— 每条结论都有实测输出或文件依据，不写推测性「体会」。
|
||
- **状态只看权威入口** —— 文件表面的 `status` 字段不代表真实生命周期状态（本轮实际踩坑）。
|
||
- **区分「报错」与「静默错误」** —— 静默错误优先级更高，因为它不会被发现。
|
||
- **能修就当场修** —— 陈旧路径、文档不符等确定性缺陷直接修复，不留到「下次」。
|
||
- **结论需自检** —— 把误判写进记录后再核实，是有效的纠错方式（本轮靠它推翻了自身结论）。
|
||
|
||
---
|
||
|
||
*归档时间：2026-09-16*
|
||
*日志位置：`.learnings/LEARNINGS.md`、`.learnings/ERRORS.md`*
|