---
belongs_to:
  - "[[INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议]]"
---
# 🔧 铸渊指令｜修复 write-notion-syslog.js 字段解析（DEV编号映射+文件内容写入）（2026-03-15·霜砚签发）

<aside>
⚠️

**后续修复 · P1 · 霜砚签发 · 2026-03-15 01:35**

**前置已合并**：属性名映射修复（提交日期→接收时间 等 4 项）已通过，Notion 写入链路已通。

**本次修复**：写入成功但两个字段的值不正确，需要优化解析逻辑。

</aside>

---

## 一、问题描述

飞书→GitHub→Notion 链路已跑通，SYSLOG 收件箱成功创建了新记录，但有两个字段异常：

### 问题 1：DEV编号写入了飞书 open_id 而非 DEV 编号

```
当前写入值：ou_3bd223b67374fd102edd4223244a7542
期望写入值：DEV-004（或其他对应的 DEV 编号）
```

`DEV编号` 是 **select** 类型，选项只有 `DEV-001` ~ `DEV-013` 和 `DT-USER`。写入飞书的 `open_id` 会导致 Notion 创建一个无效选项，后续处理无法正确识别开发者。

### 问题 2：文件内容字段为空

```
当前写入值：null
期望写入值：SYSLOG 的完整 JSON 文本
```

`文件内容` 是整个 SYSLOG 处理链路的核心数据——人格体唤醒、画像更新、广播生成全部依赖这个字段。为空则后续所有环节都无法执行。

---

## 二、修复指令

### 文件位置

```
scripts/write-notion-syslog.js
```

### 修复 1：DEV编号映射

需要在代码中添加 **飞书 open_id → DEV编号** 的映射表，或者从 SYSLOG JSON 内容中提取 `dev_id` / `developer_id` 字段。

**方案 A（推荐）：从 SYSLOG 内容解析**

SYSLOG JSON 中通常包含 `dev_id`（如 `"dev_id": "DEV-004"`）或 `header.developer_id`（如 `"developer_id": "DEV-004"`）。优先从这里提取：

```jsx
// 解析 SYSLOG JSON 内容
const syslogData = JSON.parse(syslogContent);

// 兼容两种格式
const devId = syslogData.dev_id 
  || syslogData.header?.developer_id 
  || 'DT-USER';  // fallback

// 写入 Notion
"DEV编号": { select: { name: devId } }
```

**方案 B（备选）：open_id 映射表**

如果 SYSLOG 内容中没有 dev_id，则需要维护一个映射表：

```jsx
const OPENID_TO_DEV = {
  'ou_3bd223b67374fd102edd4223244a7542': 'DT-USER',
  // 后续按需添加
};

const devId = OPENID_TO_DEV[senderId] || 'DT-USER';
```

### 修复 2：文件内容写入

将 SYSLOG JSON 的完整文本写入 `文件内容` 字段：

```jsx
// 读取 syslog-inbox 中的 JSON 文件内容
const fileContent = fs.readFileSync(syslogFilePath, 'utf-8');

// 写入 Notion 时包含文件内容
"文件内容": { 
  rich_text: [{ 
    text: { 
      content: fileContent.substring(0, 2000) // Notion rich_text 单块限制 2000 字符
    } 
  }] 
}
```

**注意**：Notion API 的 `rich_text` 单个 text block 最大 2000 字符。如果 SYSLOG 内容超过 2000 字符，需要拆分成多个 text block：

```jsx
// 处理超长内容
function splitToRichText(content, maxLen = 2000) {
  const blocks = [];
  for (let i = 0; i < content.length; i += maxLen) {
    blocks.push({
      text: { content: content.substring(i, i + maxLen) }
    });
  }
  return blocks;
}

"文件内容": { rich_text: splitToRichText(fileContent) }
```

---

## 三、其他字段优化建议

以下字段目前写入为 null，建议一并从 SYSLOG JSON 中解析：

| **字段** | **SYSLOG JSON 中的来源** | **示例值** |
| --- | --- | --- |
| `广播编号` | `broadcast_id` 或 `header.broadcast_id` | BC-M-DINGTALK-007-ZZ |
| `模块` | `module` 或 `header.module` | M-DINGTALK |
| `环节状态` | `status` 或 `header.status` | completed / partial / blocked |
| `协议版本` | `protocol_version` 或 `syslog_version` | SYSLOG-v4.0 |
| `commit_sha` | `github_state.branch` 或 dispatch payload | 247795f |
| `来源路径` | syslog-inbox 中的文件路径 | syslog-inbox/20260314-174420_feishu-shushu.json |

---

## 四、SYSLOG JSON 两种常见格式参考

### 格式 A：SYSLOG-v4.0（标准格式）

```json
{
  "protocol_version": "SYSLOG-v4.0",
  "header": {
    "broadcast_id": "BC-M-DINGTALK-007-ZZ",
    "developer_id": "DEV-004",
    "dev_name": "之之",
    "module": "M-DINGTALK",
    "status": "completed"
  },
  ...
}
```

### 格式 B：v3.0-legacy

```json
{
  "syslog_version": "v3.0",
  "dev_id": "DEV-009",
  "dev_name": "花尔",
  "broadcast_id": "BC-M20-003-HE",
  ...
}
```

解析时需兼容两种格式。

---

## 五、验收标准

- [ ]  从飞书发送一条包含 SYSLOG 内容的消息
- [ ]  Notion 收件箱新记录的 `DEV编号` 显示为正确的 DEV-xxx 格式（不是 open_id）
- [ ]  Notion 收件箱新记录的 `文件内容` 包含完整的 SYSLOG JSON 文本
- [ ]  `广播编号`、`模块`、`环节状态`、`协议版本` 至少有一个被正确解析写入

---

## 六、执行确认

铸渊完成后，在本页下方追加一行：

```
✅ 字段解析修复完成 · [日期时间] · commit SHA
```