ahang1598 write阶段语言闸门
本参考只服务 make write 前后的正文清洁，不负责章节结构、文献检索或飞书交付。它检查一件事：.workflow/paper_draft.md 是否像可继续验收的中文论文正文，而不是模型过程稿、模板扩写稿或格式事故现场。
一、进入 write 前的判断顺序
先看事实是否保住，再看证据是否对应，再看判断是否有边界，最后才处理句式。任何降 AI 处理如果导致术语漂移、事实丢失、逻辑断裂或语体过低，立即放弃该改法。
正式正文不使用 Markdown 加粗、斜体、emoji 或项目符号制造重点。提示词、用户要求、AI 来源说明、计算纠错、自我修正和待替换说明不得进入论文正文。
二、语言闸门
2.1 拦截对象
本文件不列同义词替换表，只拦截三类会让 check_draft.py 通过后仍不可用的语言问题：
- 空壳连接：首先、其次、最后、此外、总之、值得注意的是、需要指出的是等词如果只承担排版作用，删除或改成真实因果、转折、限定关系。
- 无证强判断：显著、主流、最具代表性、有效、鲁棒、重要价值等判断必须有数据、文献或明确范围；没有证据就降级。
- 生成式扩写：进一步提升、有效增强、能够更好地、实验结果表明、这说明等句式必须回到具体对象、指标、条件和边界。
处理方式不是简单同义词替换，而是追问：这句话具体依赖什么对象、条件、数据或边界？如果没有，就降级为限定表达或删除。能用段落关系自然承接时，不要为了“完整”补入空壳连接词。
Draft Mode 语言闸门：生成完整初稿后，至少检查摘要、引言、贡献段、实验结论和结论五处。若同一处同时出现成组排序词、生成式扩写和无支撑强判断，不能直接交付为“完整初稿”；先改写为“对象/条件/证据/边界”驱动的句子，或在初稿说明中标注为待改风险。
2.2 高风险句式处理
摘要、引言、讨论和结论中出现下列结构时，按右侧动作改写：
- 宏大开场：不写“X是重要领域/关键环节”，直接写本文对象、场景、样本、任务或技术约束。
- 问题清单：不写“传统方法存在A、B、C”，改写为某类方法在某个条件下的具体失效模式。
- 固定转折：不写“针对……挑战，本文提出……”，改写为“本文处理的是……条件下的……问题，方法设计集中在……”。
- 表格复述：不写“从表X可以看出”，只解释最关键趋势、异常值、机制或边界。
- 成果宣传：不写“这主要得益于”，改写为“该增益可能来自……，但仍受……限制”。
- 结论列表：不复述摘要，用连续段落回收已证明内容、限制和下一步。
2.3 数字复述与引用计数门控
- 实验正文不得逐行朗读表格。禁止把表中每一行都写成“从 A 提升到 B，提升 C 个百分点”；正文只保留最能支撑判断的一两个差异，并解释其条件、异常或边界。
- 若结果表使用
PLANNING DATA，正文不得写“实验结果表明”“结果验证了”“显著优于”“充分证明”“全面验证”。改用“基于规划数据的初稿分析显示”“预期趋势为”“待真实实验验证的是”。 - 文献综述正文不得写“获得 X 次引用”“高被引 X 次”等具体引用次数，除非用户要求文献计量分析且 evidence map 中有可核验计量来源。普通综述应按方法家族、问题条件和结论边界组织，而不是按被引次数排序。
- “保信息”不等于保句式。保留对象、条件、数据、指标和边界后，必须改掉过度规整的段首、句尾、贡献句和表格复述结构。
2.4 痕迹处理动作
发现英文直译腔时，先改语序，不先换高级词。发现“背景-方法-结果-意义”固定节奏时，插入真实对象、条件、证据和边界。发现方法段像百科词条时，回到本文为什么这样设计、解决哪类局部问题、对应哪项实验或材料。发现讨论段像宣传稿时，改写为成立条件、异常结果、失败可能和后续补强。摘要、引言、讨论和结论若重复同一价值判断，按各自功能重写，而不是换词。
2.5 重复骨架检查
中文论文的 AI 痕迹常常来自同一段或相邻段反复套用同一种表达，而不是来自某个句式本身。以 A 作为 B、通过 A 实现 B、用于 C、引入 A 等都是正常学术表达，不能机械禁用。
检查重点：
- 同一段是否连续使用相同段首、句尾或贡献句结构。
- 句子是否只有“显著、有效、重要、提升”等判断，却没有对象、数据、条件或边界。
- 文献句是否只是逐篇套“已有研究表明”，没有综合问题、方法和局限。
- 方法句是否只罗列模块名称，没有输入、处理、输出和设计理由。
处理方式：优先补对象、条件、证据和边界；必要时调整语序。不要为了降 AI 痕迹把标准学术表达强行改成粗糙口语。
2.6 重复复述与段落功能
摘要、引言、讨论和结论可以围绕同一研究结果，但不能承担同一功能：
- 摘要：报告研究对象、方法、关键结果和限定范围。
- 引言：说明问题压力、现有路径、具体缺口和本文定位。
- 讨论：解释结果为什么成立、在哪些条件下可能失效。
- 结论：收束正文已完成的判断及适用边界；后续工作仅在前文缺口自然产生时加入，不重新宣传意义。
如果同一判断在多个位置出现，先判断各位置的功能是否重复。只有功能不同，才允许保留；若只是换词复述，应合并、删减或改写为边界说明。
2.7 直白但严谨
可以把过度精致、过度对称的句子改得更直白，但不能降成口语、病句或事实漂移。好的降档是让读者更快看清对象、动作、证据和边界；坏的降档只是把正式词换成粗糙词。
- 可以使用“用、加上、说明、显示、问题、范围、条件”等普通词，但不要全文反复套同一种低阶表达。
- 保留专业术语、模型名、变量名、指标、数据集、引用编号和结论限定。
- 不为追求“人工感”故意制造语病、断句或低质量口语。
- 高水平期刊、学位论文模板或用户指定语体优先；需要正式表达时，只降低模板感，不降低严谨度。
三、中文论文的自然度
中文期刊论文允许较长句和必要承接。自然表达通常先交代研究对象、资料范围或问题背景，再说明处理方法、结果现象和判断边界。去 AI 化不是删除修饰语，而是删除没有对象、条件和证据支撑的整齐句式。
正文段落优先连续叙述，段落之间空一行。同一段保留一个中心判断，可以有解释和限定；若短段像提纲就合并，若长段混入多个中心就拆开。列表只用于计划、任务卡、检查清单、参数配置和操作步骤；论文正文除非模板允许，否则不用列表堆观点。
四、check_draft 可见格式事故
本文件只管会污染正文或触发 make write 风险的格式事故，公式、表格和图占位的生成细则交给 writing-chapters/SKILL.md。
- 标题最多三层，章节标题独立成行，不与正文第一句粘连。
- 正文不留
**...**、__...__、_..._、emoji、<sub>、<sup>或 AI 过程说明。 - 参考文献逐条换行，不把多个编号挤在同一段。
- 中文正文不无故夹杂英文普通词；必要术语首次出现时给中文译名和英文括注。
- 正式正文和结尾不保留“部分内容由 AI 生成”等披露提示；若用户要求披露，按目标期刊规范单独处理。
五、段落构建规则
一个可提交段落通常包含：
- 中心判断：本段要说明的具体关系。
- 支撑信息：文献、数据、现象、方法条件或对比。
- 边界或过渡：说明判断范围、限制、下一段为何接上。
段落不设固定字数。判断标准是中心是否单一、证据是否足够、关系是否清楚；若段落太短导致像提纲，合并；若段落过长导致多个中心混杂，拆分。
六、列表转正文
列表进入正文时必须补足主语、动作、条件和关系。贡献、步骤或变量分层可以保留编号，但每一项都要接具体对象、证据位置或适用边界；否则改成连续段落，避免“提出新方法、完成流程、验证有效性”这类空壳清单。
七、引用、事实与实验判断
写作和改写时执行三条轻量门控：
- 不编造文献、数据、图表或实验结果。
- 含结论性表述时，优先给出处、数据、图表或明确边界。
- 不把仓库、博客、模型记忆、普通搜索工具、CrossRef、Semantic Scholar、OpenAlex 等后台检索/API 元数据当作正式论文来支撑学术判断；英文文献的
scholar_search元数据可用于正式参考文献、文内引用和元数据层判断，但若要支撑方法细节、实验效果或局限边界，仍需补摘要、DOI/出版社页面、arXiv 页面、browser-task 页面可见内容或用户材料。
强判断降级示例：
- “YOLOv8 是最新版本” → “YOLOv8 是 YOLO 系列中被广泛使用的版本之一；若讨论最新进展，需结合后续版本或最新文献核验。”
- “显著优于多种主流算法” → “在本文报告的实验设置下，该方法在 mAP@0.5 指标上高于所列对比方法；是否具有统计显著性仍需更多实验或检验支撑。”
- “具有重要工程应用价值” → “该结果说明方法在当前数据集和速度约束下具有一定应用潜力，但仍需在真实产线数据上进一步验证。”
八、make write 前证据化自检
凡进入paper-write-zh的新增正文任务，无论段落、章节或整篇，都必须写入.workflow/paper_draft.md并交给make write。只有提纲或纯语言润色应在父路由转paper-shape后直接对话交付。人工自检不能替代脚本结论。
自检输出必须带证据，不写“已检查无问题”这种空话：
- 计数证据：报告
**、__、_..._、emoji、HTML上下标、模板连接词的命中次数；非零时贴出命中句并修复。 - 骨架证据：抽取相邻小节的段首切入、主句式和结句；若三项连续雷同，先改段落功能再改词。
- 判断证据：列出最新、主流、显著、代表性、全面验证等强判断，逐条补证据或降级。
- 状态证据：确认正文没有提示词、AI来源说明、计算纠错、自我修正、待替换说明；Draft Mode 的规划数据必须保留
PLANNING DATA - replace before submission。
自检失败时直接改正文；改完再运行 make write。脚本失败按 .workflow/draft_check.json 和终端 failures 修，不回头修改检查脚本。
九、完整写作中的语言收尾
本参考只承担 paper-write-zh 完整正文或章节写作中的中文细则。语言收尾先读取 ../../../paper-shape/references/polish.md 的通用工作流，再用本文件处理中文模板腔、翻译腔、审稿回复口吻、格式和段落重复。收尾结果直接并入论文正文，不额外输出修改日志或信息检查表。
用户只要求对已有文本做润色、改自然或中译英时，转同级 paper-shape，不进入本 Makefile。
十、豆包执行边界
局部或整篇正文都不额外运行临时扫描脚本，而是统一由make write运行本Skill自带的check_draft.py。若用户提供文件路径，当前环境能读取就必须读取；读不到才要求用户粘贴或上传正文。不要探测本地隐藏技能目录、IDE规则目录或运行目录。
十一、交付要求
本参考被用于完整写作时，最终回复只按 paper-write-zh 的三态口径报告交付状态和仍存在的文献、事实、实验、图表或终稿风险，不单独输出语言处理报告。
- 本轮新增正文是否已写入
.workflow/paper_draft.md并通过make write，不因篇幅短跳过。