TIV期刊under review期间能否修改已提交的代码？

Question

在TIV（IEEE Transactions on Intelligent Vehicles）期刊投稿后进入under review阶段，作者常面临一个关键技术操作问题：**能否修改已提交的代码（如GitHub仓库、附录代码包或artifact submission）？** 答案是：**原则上不允许主动修改**。TIV遵循IEEE标准审稿流程，一旦稿件及配套材料（含代码、数据、README等）随初稿正式提交，即作为评审基准锁定。审稿人依据该版本评估可复现性与技术贡献。若作者单方面更新代码（如修复bug、优化注释或调整参数），将导致评审结果失准，甚至被视为学术不端。仅当编辑明确要求（如“revise and resubmit”阶段按意见补充/修正代码）、或发现严重安全漏洞/版权瑕疵并经编辑书面许可后，方可有限度更新，并须同步提交详细变更说明（diff log + rationale）。建议作者在投稿前严格完成代码自检、文档化与版本冻结（如打Git tag），避免under review期间陷入合规风险。

Answer 1

```html

一、基础认知：什么是“Under Review”阶段的代码锁定机制？

在TIV（IEEE Transactions on Intelligent Vehicles）投稿流程中，“Under Review”并非静态等待状态，而是一个具有法律与学术效力的**评审契约期**。此时稿件连同所有artifact（含GitHub仓库链接、ZIP代码包、Docker镜像哈希、附录中的伪代码/配置文件）共同构成IEEE认可的“评审基准快照”。该快照被分配唯一DOI前缀（如10.1109/TIV.2024.XXXXXX），并存档于IEEE Artifact Evaluation Portal。任何未经编辑部书面授权的代码变更，均违反IEEE出版伦理准则第3.2条关于“材料一致性”的强制性规定。

二、风险剖析：为何主动修改代码会触发多重合规危机？

• 可复现性失效：审稿人基于提交时commit hash（如git rev-parse HEAD → a1b2c3d）构建环境；若作者后续推送git push origin main --force，导致git clone获取到非评审版本，直接否定实验结论可信度
• 责任归属模糊化：若新代码修复了原版致命bug（如自动驾驶控制模块中的NaN传播），但未同步更新论文Method部分公式推导，则形成“论文-代码逻辑断层”，违反TIV《Author Guidelines》Section 4.3对“技术陈述完整性”的要求
• 学术不端定性风险：根据IEEE PSPB Operations Manual §8.2.3，单方面更新已归档artifact可能被认定为“data/code manipulation”，触发Editorial Board正式调查程序

三、例外路径：三种经编辑部批准的合法更新场景

场景类型	触发条件	必需动作	审批主体
修订响应型	收到“Revise and Resubmit”决定，且审稿意见明确要求修正代码缺陷（如“Algorithm 2存在边界溢出，请提供修复后实现”）	提交diff -u v1.0.0.tar.gz v1.0.1.tar.gz | gzip > patch_v1.0.1.diff.gz + 200字以内rationale说明	Associate Editor
安全紧急型	发现CVE-2024-XXXXX级漏洞（如ROS节点中硬编码API密钥泄露）或GPLv3许可证冲突	向[e-mail]发送加密邮件（PGP key ID: 0xABCDEF12），附NIST NVD报告链接及补丁commit hash	IEEE Publications Ethics Committee

四、工程实践：投稿前代码冻结的工业级Checklist

1. 执行git tag -a v1.0.0 -m "TIV-submission-freeze-$(date +%Y%m%d)"并git push --tags
2. 生成可验证归档：git archive --format=tar.gz --output=artifact-v1.0.0.tar.gz v1.0.0
3. 运行自动化校验脚本（Python 3.9+）：

   import hashlib
   with open("artifact-v1.0.0.tar.gz", "rb") as f:
       sha256 = hashlib.sha256(f.read()).hexdigest()
   print(f"TIV-SHA256: {sha256}")  # 投稿Cover Letter中必须声明此值
   

4. 在README.md顶部添加声明：⚠️ This repository is frozen for IEEE TIV review (Submission ID: TIV-2024-XXXXX). No commits will be pushed until decision.

五、决策流程图：代码更新请求的标准化处理路径

graph TD A[作者发现需修改代码] --> B{是否属于以下任一情形？
① 编辑部R&R意见明确要求
② CVE/NVD确认的安全漏洞
③ 版权/许可合规风险} B -->|否| C[立即停止操作
检查投稿系统中artifact状态] B -->|是| D[准备材料：
- diff log
- rationale说明
- 影响范围分析] D --> E[发送至[e-mail]
主题：URGENT: Code Update Request - TIV-2024-XXXXX] E --> F{编辑部2个工作日内响应} F -->|批准| G[按指定方式更新
并在投稿系统上传变更说明PDF] F -->|拒绝| H[接受当前版本作为最终评审依据]

六、深层启示：从TIV规范看智能网联汽车领域的科研基建范式演进

随着ISO/PAS 21448（SOTIF）和UNECE R156（CSMS）标准在车载AI系统中的强制落地，TIV对artifact的严苛管理实则是将期刊评审升级为“**科研质量审计**”。这要求作者具备三项跨界能力：① 将算法创新转化为符合ASPICE Level 2的可追溯开发包；② 在GitHub中构建满足ISO/IEC 27001 Annex A.8.2.3要求的代码访问控制策略；③ 使用Sigstore Cosign对容器镜像签名，实现从论文到部署的全链路可信验证。这种转变标志着智能车辆领域正从“成果发表导向”迈向“系统生命周期可信导向”。

```