SIGMOD Writing Style 是一个面向 SIGMOD 研究论文写作与修改的写作风格技能，其核心主张是：SIGMOD 的正文是工程论证。读者本身是数据库系统构建者，读完第一页就应知道当下什么会失效、作者构建了什么机制、用什么测量证明它。资料把这一技能拆为若干可操作的规范。
一、首页约定。第一页内需按某种顺序出现：使问题此刻成立的工作负载或应用压力；现有技术在压力点上的失效原因（尽量带数字）；用一句具体的话概括本文机制；带实验设置的核心测量结果；以读者可验证的产物形式陈述的贡献清单（算法、系统组件、证明、评测）。资料明确反对以“数据量呈指数增长”开篇，主张直接切入具体瓶颈。
二、运行示例。这是资料所称最易识别的 SIGMOD 文体装置：一个小而具体的例子（表、查询、工作负载片段）在第 1 或第 2 节引入，并在各设计章节中贯穿使用，每个算子、数据结构或协议步骤都展示其在该例上的作用。若三行两表就能说明的连接算法只用符号讲解，即使读者能读懂符号，也会得到“难以跟随”的评审意见。
三、系统数字的声明限定。资料用对照表说明："Up to 10x faster than X" 应写成具体设置下的数值（如倾斜读、某 scale factor 下 10x，均匀写下 1.3x，并指向图号）；"Scales linearly" 应改为到多少核近似线性、此后竞争导致趋缓；"Negligible overhead" 应给出所测混合负载下 p99 延迟的百分比开销并指向表号；"Guarantees consistency" 应说明隔离级别与为实现更强级别付出的代价；"First system to..." 必须精确限定否则删除。原则是每个最高级表述都绑定图表、工作负载与边界；数据库审稿人尊重写明的局限，并会去找未写明的局限。
四、架构先于代数。早放一张系统总览图，图中组件在正文与评测中的命名保持一致，资料指出 12 页内的命名漂移是真实且常见的缺陷。只为核心机制写伪代码，次级例程用文字加指向产物的说明。正确性论证在正文给证明梗概、完整细节放扩展报告，但不变量本身必须在正文精确陈述。设计决策段落（“我们选 B 而非 A 因为……”）不是填充，而是工业界读者引用论文的理由。
五、匿名安全口吻。对作者此前的系统用第三人称书写，清除可识别痕迹：写“we extend the engine of [12]”而非“our engine [12]”；不使用搜索引擎可映射到公司的内部代号；避免“deployed at a major cloud provider”之类把作者集合缩小到两个团队的说法。这些规则在整个多轮评审期间（包括修改稿）均有效。
六、12 页配额。资料给出页面分配建议：第 1 页问题、现有方案失效、机制、核心数字；第 2-3 页背景与运行示例；第 4-7 页设计（架构图、核心算法、不变量）；第 8 页正确性与复杂度梗概；第 9-11 页评测（先设置表，再按图序陈述结论）；第 12 页对比式相关工作、局限与结论。评测设置那半页被视为不可移动：硬件、数据集、工作负载、基线、调参来源；删它救设计小节，是用清晰度意见换证据质疑，资料称在此审稿池中是不划算的交易。
七、标题与摘要。系统论文惯用系统名加冒号限定承诺的结构，靠精确的机制从句而非宏大措辞赢得名字；摘要至少含一个带设置的数字，零测量的摘要会被读作立场文章；避免 novel、framework、holistic 三个词；摘要末句应说明发布了什么（代码、数据、脚本），在 PACMMOD 的共享期待下，沉默很显眼。
八、句子习惯。系统行为用现在时，实验做过的事用过去时；用数字而非程度词（2.1x 而非 significantly，p99 而非 tail）；精确点名对手（log-structured merge amplification 优于“现有方法的性能问题”）。
九、输出格式。该技能按固定清单产出：首页审计（压力、现有方案失效、机制、数字是否齐备）；运行示例是否存在并贯穿设计章节；声明台账（每个最高级表述对应图、工作负载、边界）；口吻排查（第三人称自引、代号泄露）；预算核对（章节分配对照 12 页计划）；按优先级排序的改写清单。
资料未提供该技能的安装方式、价格、适用平台或运行环境信息。