99 lines
3.5 KiB
Python
99 lines
3.5 KiB
Python
|
#!/usr/bin/env python3
|
|||
|
|
"""记录今天的日记和经验总结"""
|
|||
|
|
import os
|
|||
|
|
import sys
|
|||
|
|
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'diary_system.settings')
|
|||
|
|
sys.path.insert(0, '/root/.openclaw/workspace/diary-system/backend')
|
|||
|
|
|
|||
|
|
import django
|
|||
|
|
django.setup()
|
|||
|
|
|
|||
|
|
from diary.models import DiaryEntry, Experience
|
|||
|
|
from datetime import date
|
|||
|
|
|
|||
|
|
# ============ 创建日记 ============
|
|||
|
|
today = date.today()
|
|||
|
|
entry, created = DiaryEntry.objects.get_or_create(date=today)
|
|||
|
|
|
|||
|
|
entry.title = "教训深刻的一天 - 丢失功能的警示"
|
|||
|
|
entry.completed_tasks = """- 开发日记系统 Web 版本
|
|||
|
|
- 添加经验总结模块
|
|||
|
|
- 部署到云服务器
|
|||
|
|
- 创建软件需求文档
|
|||
|
|
- 配置双 git 仓库同步"""
|
|||
|
|
|
|||
|
|
entry.learned = """- Git 版本控制的重要性
|
|||
|
|
- 修改前必须先备份
|
|||
|
|
- 功能清单必须维护
|
|||
|
|
- 小步迭代，多次验证
|
|||
|
|
- 不确定时先问用户"""
|
|||
|
|
|
|||
|
|
entry.problems = """- 修改前端时覆盖了原有的日历组件
|
|||
|
|
- 没有查看现有代码就直接修改
|
|||
|
|
- 没有功能清单对照
|
|||
|
|
- 修改后没有验证所有功能
|
|||
|
|
- 导致用户多次要求回退版本"""
|
|||
|
|
|
|||
|
|
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 (4aeb21c)
|
|||
|
|
3. 同步到云服务器
|
|||
|
|
4. 创建功能清单和开发规范
|
|||
|
|
5. 建立修改前后的检查流程
|
|||
|
|
|
|||
|
|
长期解决方案：
|
|||
|
|
- 维护 FEATURES.md 功能清单
|
|||
|
|
- 维护 DEV_GUIDE.md 开发规范
|
|||
|
|
- 修改前创建 git 备份分支
|
|||
|
|
- 使用功能分支开发
|
|||
|
|
- 修改后对照清单验证""",
|
|||
|
|
lesson_learned="""📌 核心教训：
|
|||
|
|
1. **敬畏现有代码** - 每行代码都有它的价值，不要随意覆盖
|
|||
|
|
2. **先理解再修改** - 修改前必须先查看现有代码和功能
|
|||
|
|
3. **小步迭代** - 每次只改一个功能，立即验证
|
|||
|
|
4. **文档先行** - 功能清单、需求文档必须在开发前维护
|
|||
|
|
5. **用户沟通** - 不确定时先问用户，不要自作主张
|
|||
|
|
6. **版本控制** - 善用 git 分支和回滚功能
|
|||
|
|
|
|||
|
|
💡 这个教训的价值远超今天浪费的时间，它会成为以后开发中的警示灯。"""
|
|||
|
|
)
|
|||
|
|
|
|||
|
|
print(f"✅ 经验总结已保存：{exp.title}")
|
|||
|
|
print(f" 类别：{exp.get_category_display()}")
|