|
|
@@ -2610,3 +2610,20 @@
|
|
|
|
|
|
**仍未做**:浏览器端到端(用户实测后改了两次数据源/字段,尚未再走一遍浏览器)。
|
|
|
|
|
|
+### 续 4:确认 `c_tag_name` 不承担语义(用户 2026-09-18)
|
|
|
+
|
|
|
+用户问「c_tag_name 存分类了吗,或者说有分类吗」。全表核查(1886 共约 1986 行)结论:
|
|
|
+
|
|
|
+- **分类不在 1886**,在 **1888** 的六个 `c_tag_*` 字段(宇树:`c_tag_honor` = `["中国独角兽企业","国家级高新技术企业"]`)
|
|
|
+- 1886 的 `c_tag_name` **只有宇树 20 行有值**,且值与 `c_honor` 完全相同
|
|
|
+ —— 是**中间版本**(荣誉名写在 c_tag_name 的那版)留下的残留;
|
|
|
+ `author_name=ams_user` 是**建行的人**、不是最后改的人(DMS 的 author 创建即定死)
|
|
|
+- 后端也没有「每条荣誉 → 分类标签」的映射(分类接口的资质荣誉角度是企业级的,宇树只有 2 个标签),
|
|
|
+ 所以 1886 天然没有可写的分类
|
|
|
+
|
|
|
+**用户拍板:不用它、也不用清理**(「不用吧」)。因此:
|
|
|
+
|
|
|
+- 代码**不改**:`c_tag_name` 既不再写、也不清理;读取荣誉名时仍保留它作为中间回退项
|
|
|
+ (`c_honor → c_tag_name → title`)——留着比删掉更稳,万一还有别的行是中间版本写的
|
|
|
+- 已把这条决定写进 `DMS_COLUMNS.md` 的 1886 字段说明,免得下次有人再问「这列怎么没人写」
|
|
|
+
|