feat: 初始化 AI 助手记忆仓库
上传核心文件: - IDENTITY.md, USER.md, SOUL.md, AGENTS.md, TOOLS.md, HEARTBEAT.md, MEMORY.md - memory/: 日志和工作记录 - skills/: 技能配置 - .gitignore
This commit is contained in:
84
memory/2026-03-31.md
Normal file
84
memory/2026-03-31.md
Normal file
@@ -0,0 +1,84 @@
|
||||
|
||||
## OA审批查询
|
||||
|
||||
- 罗小寸共有 **22 个 OA 流程待审核**
|
||||
- 查询接口:`GetUserTodoTaskSum`(钉钉 workflow API)
|
||||
- API 返回:`{"success":true,"userId":"121922510028034588","count":0,"detail":{"result":22}}`
|
||||
- 注意:count 字段为 0,但 result 字段为 22,实际数量以 result 为准
|
||||
- 查询时间:2026-03-31 10:45
|
||||
|
||||
**问题**:无法获取 22 个审批的具体列表
|
||||
- ListTodoWorkRecords API 返回 503 错误(服务器临时故障)
|
||||
- 其他 API 因权限问题或参数错误无法调用
|
||||
- 待进一步排查或用户手动在钉钉客户端查看
|
||||
|
||||
## 时间戳计算错误记录(2026-03-31)
|
||||
|
||||
### 问题
|
||||
在查询钉钉日历时,传入的 startTime 时间戳错误:
|
||||
- 错误值:`1746134400000`(毫秒)= 2025-05-02 05:20:00 北京时间
|
||||
- 正确值:`1774972800000`(毫秒)= 2026-04-01 00:00:00 北京时间
|
||||
- **差了约 333.78 天(约 11 个月)**
|
||||
|
||||
### 根本原因
|
||||
使用了 `date(2026, 4, 1).strftime('%s')` 或类似的手动计算方法,这种方式:
|
||||
1. 依赖于系统时区设置
|
||||
2. 容易在日期计算时出现偏差
|
||||
3. 不直观,难以验证
|
||||
|
||||
### 正确做法
|
||||
使用 Python datetime 模块,明确指定时区:
|
||||
|
||||
```python
|
||||
from datetime import datetime, timezone, timedelta
|
||||
|
||||
# 方法1:明确指定北京时间 (UTC+8)
|
||||
beijing_tz = timezone(timedelta(hours=8))
|
||||
dt = datetime(2026, 4, 1, 0, 0, 0, tzinfo=beijing_tz)
|
||||
ts_ms = int(dt.timestamp() * 1000) # 毫秒
|
||||
print(ts_ms) # 1774972800000
|
||||
|
||||
# 方法2:直接构造 UTC 时间再转换
|
||||
dt_utc = datetime(2026, 3, 31, 16, 0, 0, tzinfo=timezone.utc)
|
||||
ts_ms = int(dt_utc.timestamp() * 1000)
|
||||
print(ts_ms) # 1774972800000
|
||||
```
|
||||
|
||||
### 验证
|
||||
```python
|
||||
import datetime
|
||||
# 2026-04-01 00:00:00 北京时间
|
||||
beijing_tz = datetime.timezone(datetime.timedelta(hours=8))
|
||||
dt = datetime.datetime(2026, 4, 1, 0, 0, 0, tzinfo=beijing_tz)
|
||||
print(int(dt.timestamp() * 1000)) # 1774972800000 ✅
|
||||
```
|
||||
|
||||
### 教训
|
||||
- ❌ 不要手动计算 Unix 时间戳
|
||||
- ❌ 不要依赖 `date.strftime('%s')` 这种方法
|
||||
- ✅ 始终使用 `datetime` + `timezone` 明确处理时区
|
||||
- ✅ 计算完成后用 `datetime.fromtimestamp()` 反向验证
|
||||
|
||||
## 钉钉日志 MCP 查询教训(2026-03-31)
|
||||
|
||||
### 问题
|
||||
查询"最近一周提交的日志",我查到了 1 篇,但你实际提交了 2 篇。
|
||||
|
||||
### 根本原因
|
||||
API 时间范围是 **左闭右开** 的,即 `[startTime, endTime)`:
|
||||
- 我设的 endTime = `1774886400000` = 2026-03-31 00:00:00
|
||||
- 你第二篇日志时间 = `1774894433000` = 2026-03-31 02:13:53
|
||||
- 因为 endTime 不包含 03-31 当天的日志,所以第二篇没查到
|
||||
|
||||
### 正确做法
|
||||
如果要查询**当天**的日志,endTime 应该设为**明天**的 00:00:00:
|
||||
```python
|
||||
# 查询 3月24日 到 3月31日(包含31日当天)
|
||||
startTime = 2026-03-24 00:00:00 # 毫秒时间戳
|
||||
endTime = 2026-04-01 00:00:00 # 注意:是明天,不是当天 00:00:00
|
||||
```
|
||||
|
||||
### 教训
|
||||
- ❌ 查询当天日志时,endTime 不能设为当天 00:00:00
|
||||
- ✅ endTime 应该设为**明天**的 00:00:00
|
||||
- ✅ 始终用 `datetime.fromtimestamp()` 反向验证时间戳是否正确
|
||||
Reference in New Issue
Block a user