Evilom
52 lines
3.7 KiB
Markdown
52 lines
3.7 KiB
Markdown
# Gh8cw3QnJiplq1k2lmFcajidnHl
|
|
|
|
Source: https://dianchukeji.feishu.cn/wiki/Gh8cw3QnJiplq1k2lmFcajidnHl
|
|
|
|
|
|
# 一.工作内容概述
|
|
- 开始账号数据框架搭建，完善体力系统相关功能
|
|
- 工作流优化探索，尝试引入Codex审查步骤；结合Obsidian进行相关文档、开发日志整理。
|
|
# 二.工作流优化探索相关
|
|
## 尝试使用 Codex 插件进行功能审查
|
|
### 背景与痛点
|
|
目前中大型功能由 Agent Team 协作完成后直接提交，缺少独立的外部审查环节，即使原流程中已经有审查验证步骤，还是会有BUG遗漏。
|
|
### 今日实践
|
|
在ClaudeCode里安装了Codex插件，在体力系统代码完成后，执行了 /codex:review。Codex 作为"外部 reviewer"，从第三方视角审查了工作树 diff，审查范围覆盖全部变更文件。
|
|
### 效果评估
|
|
- **效果&成本收益：**审查耗时约 3-5 分钟，成功发现4个有效问题。
|
|
- **后续考虑：**将这一步骤作为复杂功能（涉及多文件改动）的固定收尾步骤
|
|
### 待优化点
|
|
- **触发方式：**目前 Codex review 是手动触发（/codex:review），后续可考虑写入rules，在AgentTeam交付后自动提醒是否要启动Codex review
|
|
|
|
## Obsidian 文档与开发日志体系
|
|
### 背景与痛点
|
|
项目文档和开发日志之前分散在三个地方：
|
|
- CLAUDE.md：项目总体说明，更新频率低
|
|
- memory 文件：对话上下文中的记忆片段，跨 session 易丢失
|
|
- 对话上下文：即时讨论，压缩后不可回溯
|
|
这种分散导致：
|
|
- 跨 session 复盘困难，需要翻阅多段对话才能还原完整上下文
|
|
- 技术决策缺少归档，后续重复讨论同样问题
|
|
- 待办事项散落在各处，容易遗漏
|
|
### 今日实践
|
|
**Obsidian Vault 与项目仓库联动**
|
|
- 将 Obsidian-Vault/ 目录纳入项目仓库，实现文档与代码版本同步
|
|
- 开发日志按日期归档，命名格式 YYYY-MM-DD.md，便于按时间线回溯
|
|
**开发日志自动维护规则**
|
|
- 触发时机：每次 session 结束、上下文压缩时写入开发日志
|
|
- 格式规范：
|
|
- 今日日志完整记录了体力系统的全部改动（5 个文件的具体修改点）和 Codex review 结果（4 个问题及修复状态）
|
|
**上下文压缩后的日志补写机制**
|
|
- **问题发现：**
|
|
- 上下文压缩由系统自动触发，恢复对话后ClaudeCode没有把"恢复信号"和"日志写入"正确关联，错误地将其当成了"继续同一个 session"，没有识别出这是一个需要执行日志写入的边界点。从而导致遗漏了一次日志写入，手动要求后进行补写。
|
|
- **修复措施：**
|
|
- 立即补写 2026-04-30.md 的开发日志
|
|
- 在 memory 中建立了反馈规则：每次压缩上下文后，先检查当天日志是否完整，缺失则立即补写。
|
|
### 效果评估
|
|
- **可执行性：**开发日志变为实际可执行、可回溯的产出，方便进行复盘。
|
|
- **结构清晰：**跨 session 时，记忆（memory，快速上下文）+ 日志（Obsidian，结构化归档）+ 代码（git，具体实现）三层体系形成互补结构
|
|
### 待优化点
|
|
- **自动化程度：**开发日志目前需要手动整理后写入，后续可以探索让 Agent 在关键节点自动追加（如每完成一个文件修改时自动写入 ## 文件改动 小节）
|
|
- **日志拆分：**当日志内容过长，可以考虑对其进行进一步拆分，方便定位不同模块的信息。
|
|
- **模板化：**为不同类型的 session 定义模板（开发 session / review session / 规划 session等），减少生成时间成本
|
|
 |