32 lines
3.1 KiB
Python
32 lines
3.1 KiB
Python
|
#!/usr/bin/env python3
|
|||
|
|
import os, sys
|
|||
|
|
sys.path.insert(0, '/root/.openclaw/workspace/diary-system/backend')
|
|||
|
|
os.environ['DJANGO_SETTINGS_MODULE'] = 'diary_system.settings'
|
|||
|
|
import django
|
|||
|
|
django.setup()
|
|||
|
|
|
|||
|
|
from diary.models import DiaryEntry, Experience
|
|||
|
|
from datetime import date
|
|||
|
|
|
|||
|
|
today = date.today()
|
|||
|
|
entry, _ = DiaryEntry.objects.get_or_create(date=today)
|
|||
|
|
entry.title = "教训深刻的一天 - 丢失功能的警示"
|
|||
|
|
entry.completed_tasks = "- 开发日记系统 Web 版本\n- 添加经验总结模块\n- 部署到云服务器\n- 创建软件需求文档\n- 配置双 git 仓库同步"
|
|||
|
|
entry.learned = "- Git 版本控制的重要性\n- 修改前必须先备份\n- 功能清单必须维护\n- 小步迭代，多次验证\n- 不确定时先问用户"
|
|||
|
|
entry.problems = "- 修改前端时覆盖了原有的日历组件\n- 没有查看现有代码就直接修改\n- 没有功能清单对照\n- 修改后没有验证所有功能\n- 导致用户多次要求回退版本"
|
|||
|
|
entry.reflections = "这是一个严重的工程习惯问题。作为开发者，应该：1.敬畏现有代码 2.先理解再修改 3.小步快跑 4.文档先行 5.用户沟通。今天的错误虽然造成了时间浪费，但换来了深刻的教训，值得记录。"
|
|||
|
|
entry.improvements = "1.创建了 FEATURES.md 功能清单 2.创建了 DEV_GUIDE.md 开发规范 3.创建了 REQUIREMENTS.md 需求文档 4.建立了修改前的备份流程 5.建立了修改后的验证清单"
|
|||
|
|
entry.plans = "- 严格执行开发规范 - 每次修改前查看功能清单 - 使用 git 分支开发 - 修改后对照清单验证 - 定期回顾今天的教训"
|
|||
|
|
entry.save()
|
|||
|
|
print(f"✅ 日记已保存：{entry.date}")
|
|||
|
|
|
|||
|
|
exp = Experience.objects.create(
|
|||
|
|
title="修改前端时丢失日历功能的教训",
|
|||
|
|
category="development",
|
|||
|
|
problem="在添加经验总结板块时，直接覆盖了 frontend/index.html，导致已有的日历组件丢失。用户发现后要求回退版本，来回折腾了 3 次才恢复到正确的版本。具体问题：1.没有先查看现有代码 2.没有功能清单对照 3.没有使用 git 分支开发 4.修改后没有验证所有功能 5.自作主张添加了不需要的功能",
|
|||
|
|
solution="1.立即使用 git restore 恢复文件 2.回退到正确的 commit 3.同步到云服务器 4.创建功能清单和开发规范 5.建立修改前后的检查流程。长期解决方案：维护 FEATURES.md 功能清单、维护 DEV_GUIDE.md 开发规范、修改前创建 git 备份分支、使用功能分支开发、修改后对照清单验证",
|
|||
|
|
lesson_learned="📌 核心教训：1.敬畏现有代码 - 每行代码都有它的价值，不要随意覆盖 2.先理解再修改 - 修改前必须先查看现有代码和功能 3.小步迭代 - 每次只改一个功能，立即验证 4.文档先行 - 功能清单、需求文档必须在开发前维护 5.用户沟通 - 不确定时先问用户，不要自作主张 6.版本控制 - 善用 git 分支和回滚功能。💡 这个教训的价值远超今天浪费的时间，它会成为以后开发中的警示灯。",
|
|||
|
|
date=today
|
|||
|
|
)
|
|||
|
|
print(f"✅ 经验总结已保存：{exp.title}")
|