| name | blog |
| description | 写/改 MedMe 公开开发日志(gh-pages 的 blog.html,专题卡片制)。当用户说「写篇 blog」「加个专题」「更新开发日志」「把这块写进 blog」时使用。 |
开发日志
公开出口是 gh-pages 分支的 blog.html,专题卡片制:一张卡片 = 一个真实难题,卡内按 PR 合并日期(UTC)倒序记迭代过程。
视角:有工程背景的 marketing。记录过程、经验、决定,不评判产品好坏。
现有专题
OCR / 抽取与术语 / 数据存在哪 / 给医生的那一页 / 系统设计(手机优先)
新内容优先并进已有专题的时间线,不要动辄开新卡 —— 只有真正独立的课题才开新专题。
怎么做
- 准备 worktree(gh-pages 不是日常工作分支):
git worktree add <tmp>/ghp gh-pages
- 派
blog-writer subagent 写。它自带全部语气与禁写规则(见 .claude/agents/blog-writer.md),把任务和素材来源给它:
- 要写的专题/条目
- 相关 PR 号(
gh pr list --state merged --json number,title,mergedAt)
docs/log/ 最新几条、相关 docs/ADR/
- 审核必须由另一个 subagent 做,不许自审。 要求逐条核到
file:line,判定证实/证伪/无法证实/表述过强,给改法。落实后再交付。
- 自检:标签配平、语言切换中英互斥、无横向溢出(可起
python3 -m http.server + playwright 实测)。
- 不推送。 推送(
git push origin gh-pages)由用户决定。
反复踩过的坑(别再踩)
- 把内部工程视角当用户视角:「还没做完/还没测够」被写成产品缺陷。
- 删了测试来源却留着测试结论 —— 变成没出处的负面断言,比原来更糟。
- 平台差异当成缺一块:先想清楚是「没做」还是「不需要做」(例:手机不阅片,自然不带 DICOM 像素解码)。
- 前后卡片自相矛盾:写「核心都在一份 Rust 代码里共用」时,忘了 OCR 在移动端走 Dart 原生。