- 后台全面引入 Naive UI 组件库,统一 UI 规范 - 前台 usePublicApi 切换到 API 调用(GET /api/content/[key]) - 前后台数据源统一(site_content 表) - 产品线统一管理(tour/camp/course 三套编辑器) - 产品数据归一化(itinerary/faq/pricing 格式统一) - 表单提交 API 改写入 submissions 表 - 新增 submissions 标记已读 API - site-content PUT 支持 upsert - 修复前台 bug(stories 路由冲突、占位符警告、selector breadcrumb) - 消除 PageHero 类型警告(useSEO reactive 修复) - 25 个前台页面全部 HTTP 200,展示效果不变 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1.9 KiB
1.9 KiB
PM 经验教训
2026-03-24
1. 有报告不用,执行脱节
- 问题:Phase 0 字段采集报告明确列出 summer-camp/winter-camp/courses 没有 versions 结构,但设计编辑器时只做了一套 versions 模式
- 教训:产出的分析报告必须在每一步执行时严格对照,不能做完报告就扔一边
2. 不查源码就下结论
- 问题:看到 usePublicApi('destinations') 没有被前台调用,就判断"数据没有前台页面使用",直接删除编辑器和侧栏入口
- 教训:数据存在数据库/JSON中就说明有用途。判断前先读 data/*.json 确认数据内容,读前台页面确认展示方式。不确定时读代码,不要猜
3. 编辑器字段必须对照数据源
- 问题:产品编辑器只覆盖了部分字段,大量前台展示字段落到 JSON 兜底
- 教训:每个编辑器的字段 = data/*.json 全部字段 = 前台页面渲染的全部字段。三者必须一一对应,做之前先列清单对照
4. 不要自行决定删除内容
- 问题:两次删除 destinations 编辑器又加回来
- 教训:遇到不确定的内容,先读源码确认。所有 data/*.json 中的数据都是为现有前台服务的,后台的职责就是维护这些数据,没有例外
5. 错误要即时记录
- 问题:犯了多次错误但没有记录任何教训,导致重复犯错
- 教训:每次出错后立即写入 lessons.md,不要拖延
6. Agent 产出要检查
- 问题:agent 重构 selector 页面时漏掉了 Naive UI import,导致样式全部丢失
- 教训:agent 完成后必须检查关键项:import 是否完整、组件是否正确引用、编译是否通过
7. 验证不能只看 build
- 问题:用 build 通过就认为功能正常,实际上多个页面有运行时错误(pricing 500、courses 500)
- 教训:验证必须启动 dev server,逐页请求确认 HTTP 200 + 数据正常渲染