my-content-review

# 内容审查（Content Review） 对 MathRepo 的 Typst 数学笔记（以及其他内容文件）执行**"先报告、后修改"的两阶段审查**。审查范围由用户给定；审查者负责定位范围、逐维度检查、输出报告，并在用户确认后实施修改。 ## 工作流总则：两阶段强制门禁 **审查阶段只读不改。** 审查报告必须先完整输出给用户；只有用户明确确认（可全部或部分采纳）后，才允许进入修改阶段。未获确认前，禁止对任何文件执行写入操作。 ### 阶段一：审查（只读） 1. **确定范围** - 用户可能给出：文件路径、Part / Chapter / Section 名称、行号区间或主题关键词。 - 用 Read / Grep / Glob 定位范围的精确边界（如某 Part 的起止行）。 - 范围模糊或有歧义时，先向用户确认，不要擅自猜测。 2. **通读与定位** - 通读范围内全部内容。 - 扫读范围外内容，用于：确认交叉引用目标存在、检查"延迟证明"类承诺的兑现点、掌握全篇符号体系与既有风格。 3. **按审查维度逐项检查**（维度清单见下节；报告开头须先列出本次采用的维度及取舍理由）。 4. **编译验证** - 若范围涉及 `.typ` 文件，运行： ```bash typst compile "<subject>/initial.typ" "<subject>/initial.pdf" --root . ``` （工作目录必须是仓库根目录；始终编译 `initial.typ` 入口。） - 确认 exit code 为 0、无警告、无悬空引用。 5. **输出审查报告**（格式见下节），然后**等待用户确认**。 ### 阶段二：修改（需用户确认） 用户确认后： 1. 按确认的清单逐项实施修改；严格遵循相关技能： - `typst-edit-consistency`：符号体系与写作风格不变，扩展而非重写； - `typst-writing-conventions`：Typst 数学语法规范； - `proof-reviewer`：数学证明的细粒度检查清单。 2. 每完成一批修改立即编译验证，不要攒到最后一次性验证。 3. 全部完成后：编译通过。**提交改为可选**：仅当用户明确要求提交（或仓库 `.trae/rules/git-commit-message.md` 存在且用户确认）时，按该规范提交（中文 Conventional Commits，只提交自己修改的文件，工作区中他人的未提交改动不得夹带）；用户未要求提交时跳过提交，并在修改汇总中说明未提交。 4. 输出修改汇总： - 逐项说明"改了什么、怎么改的"（附位置链接）； - 对用户未采纳的项，说明保留原样的原因； - 对做了轻量化/折中处理（未完全按建议执行）的项，必须显式指出并说明理由。 ## 审查维度 按以下七个维度审查。每次审查按范围特点增删维度，但**报告开头必须明确列出本次采用的维度**。 ### 1. 数学严谨性 - **定理-证明对应**：每个 theorem / proposition / lemma / corollary 是否有证明区块，或显式的延迟说明（"证明见某 Part"）； - **证明步骤链**：每步推理是否从已知假设或已证结论出发；"显然""容易看出"是否真的显然； - **隐含假设与边界条件**：除零、级数/积分收敛性、量词顺序（∀∃ 混淆）、求和/并交指标范围、$P(B) > 0$ 类前提遗漏； - **数值核验**：所有数值结果（概率值、极限、近似值）逐项独立验算，不得跳过。 - **例子/反例真实性核验**：对每个例子/反例，除数值外还必须核验其声称的"适用性/不适用性"——例如声称"某定理不适用"时必须实际检查定理前提（如 LDCT 不适用须检查是否存在可积支配函数、非 Vitali 覆盖须按定义逐条验证），声称"某性质成立"时须按定义逐条确认。不得只验算数值而放过假例子。 ### 2. 逻辑连贯性 - **依赖顺序**：定义/定理是否先于使用；证明中引用的命题是否已在之前陈述（前向依赖是重点检查项）； - **前向引用治理**：不可避免的前向引用是否有显式标注（deferred / promise 机制）或前向链接； - **承诺-兑现**：文中所有"proof deferred to …""to be proved in …"的承诺，逐一核对兑现点，报告以**"承诺位置 → 兑现位置"对照表**输出；无兑现点（如目标 Part 尚为空壳）时标注"未兑现（空壳/蓝图）"。 - **结构过渡**：章节间的桥接段落是否成立；正文安排与文件尾部的设计蓝图/注释是否一致。 ### 3. 术语与符号一致性 - 术语是否符合学界标准用法（如上连续/下连续、field 与 σ-field 的区分）； - 同一概念全篇符号统一（同一对象的记号、参数取值范围如 $(0,1)$ vs $[0,1]$、连字符/破折号等排版细节）； - **人名拼写符合用户偏好约定**（如俄国人用西里尔字母：Марков、Его́ров、Чебышёв、Лузин、Суслин；德语传统拼写如 Gauβ/Gauß），同一人名全篇统一；用 `Select-String -Pattern 'Markov|Egorov|Chebyshev|Lusin|Suslin'` 扫描常见拉丁残留并人工判定； - 与仓库其他笔记的符号约定兼容（跨笔记引用时符号不冲突）。 ### 4. 模板与格式规范 - **组件职责**：`#definition` / `#theorem` / `#property` / `#example` / `#note` / `#caution` 是否按模板约定使用（绿♣定义、红♥定理、蓝♠命题）；定义块内是否混入推导、解释或动机（应移至块后正文）；property 是否被滥用为"万能包装器"； - **双语规范**：正文不得出现中文（扫描：逐行去除 `//` 注释后检查 CJK 字符，PowerShell `Select-String -Pattern '[\u4e00-\u9fff]'` 定位后人工核对是否落在注释内）；标题带 `// 中文注释`，不得出现双 `//`； - **数学语法**：符合 `typst-writing-conventions`（符号映射、`abs()` 写法、分数括号、dif、display 公式标点在环境内等）；绝对值统一 `abs()`（扫描 `\|[^|]*\|` 行内配对；集合描述 `{|f| > M}`、`|->` 映射箭头、迹代数 `cal(S)|E`、函数限制 `f|_F` 保留原样）。**强制扫描下标吞括号**：正则 `_[a-zA-Z]+\(`（如 `mu_X(B)` → 必须 `mu_(X)(B)`），命中即为错误，上报必改项。 ### 5. 引用完整性 - `@label` 与 `#link(<label>)` 是否全部有效（以编译验证为准）； - 引用显示文本与目标内容是否匹配（如链接文字说"第一对"实际指向别处）； - 图表是否被正文引用（定义了却从未引用的图是次要问题）； - 标签命名符合前缀约定（`fig:` / `thm:` / `def:` / `prop:` / `ex:` / `lem:` / `cor:`）； - 跨笔记引用遵守内容职责原则（SRP）：不重复其他笔记已给出的定义与证明，只做职责内引用。 ### 6. 内容覆盖度 - 对照文件尾部的设计蓝图/注释清单（如"目录蓝图"注释块），核对知识点是否齐全、位置安排是否与蓝图一致； - 蓝图与正文不一致时，判断是正文该调整还是蓝图该更新，报告两种方案供用户选择。 ### 7. 编译健康度 - exit code、警告信息； - 渲染隐患：超宽公式、表格单元格语法、图片缺失等。 > 维度取舍示例：审查非数学内容（如 README、注释块）时，维度 1、7 可裁剪，维度 2、3、5 保留；审查单个 Chapter 时七个维度全部适用。 ## 审查报告格式 1. **审查范围与维度**：范围（文件 + 起止位置）；本次采用的维度清单及增删理由； 2. **总体评价**：先列做对的地方（验算正确的结果、良好的机制设计、清晰的职责边界），再给总体结论——先肯定后批评； 3. **问题清单**：按严重程度分级，每条给出**位置（可点击的行号链接）、问题描述、修改建议**： - 🔴 主要问题：实质错误、会误导读者、承诺未兑现、声称与内容不符； - 🟡 次要问题：精确性瑕疵、风格与一致性、命名与措辞； 4. **优先级汇总**：分**必改 / 应改 / 可选**三档，说明分档理由，并以问题编号引用前文，方便用户逐项回复"采纳/不采纳"。 ## 禁止事项 - 未获用户确认前修改任何文件； - 审查报告中不做验算就直接断言"正确"； - 修改阶段引入新的前向依赖，或改动用户已有的符号体系与写作风格； - 提交时夹带非本次审查产生的文件改动。