技术长文编辑核查清单

一篇 15000+ 字的技术长文写完不是终点，修改才是。本文提炼一套系统化的核查清单，确保长文的计算准确、逻辑自洽、表述规范。

背景

技术长文（尤其是含案例推演、公式计算的策略/教程类文章）最容易出问题的不是结构或立意，而是**细节**——计算抄错、百分比与绝对值不对应、案例前后矛盾、术语在 50 页后换了个叫法。这些错误读者一眼就能看出，但作者自己因沉浸式写作反而视而不见。

本文从实际修改 一篇 1500 行交易系统设计手记 的经验中提炼，形成可复用的六维核查清单。

核查清单

一、计算与数据校验（⚠️ 中等严重度）

含公式和数值推演的文章必须逐行校验，错一个数字就破坏整篇的可信度。

经验：计算验证不能靠"看起来差不多"，必须用计算器逐项验算。

二、案例逻辑一致性（⚠️ 中等严重度）

案例是技术文章中最有说服力的部分，也是矛盾最容易藏身的地方。

经验：案例修改后必须重读整段结论段落——数据变了，论点可能也需要变。

三、公式与参数边界（🔴 高严重度）

公式写得再漂亮，边界条件不清晰就是埋雷。

经验：每个"魔术数字"（2%、3:1、30%、3 次）都必须有推导或经验来源说明。

四、表述规范性（🟡 低严重度）

表述问题不影响内容正确性，但累积起来会让文章显得不专业。

经验：术语统一用全文搜索解决（grep 每个候选词），单位统一用"确定主单位→全局替换"策略。

五、策略/系统的完整性（🔴 高严重度）

对于"设计类"文章，读者看完会问"那我怎么用？"——没回答这个问题就是缺口。

经验：写完用读者视角提问"我拿着这篇文章能直接执行吗？"——每一个答不上来的点就是一个缺口。

六、MkDocs Material 博客维护技巧

修改工作流

对一篇技术长文做系统修改时的执行顺序：

┌─────────────────┐
│ 1. 全局搜索修正   │ → 术语统一、单位统一、全局替换错误值
└────────┬────────┘
         ▼
┌─────────────────┐
│ 2. 计算校验       │ → 所有含数字的公式、表格、案例逐项验算
└────────┬────────┘
         ▼
┌─────────────────┐
│ 3. 案例逻辑修复   │ → 补充缺失的推导链、解释矛盾、透明化计算
└────────┬────────┘
         ▼
┌─────────────────┐
│ 4. 策略缺口补充   │ → 读者视角提问，补充启动条件/异常路径/边界说明
└────────┬────────┘
         ▼
┌─────────────────┐
│ 5. 结论一致性     │ → 数据改了结论是否也要改？重读所有总结段落
└────────┬────────┘
         ▼
┌─────────────────┐
│ 6. 前后交叉验证   │ → 前面提到的参数后面是否还在用？规则是否前后矛盾？
└─────────────────┘

注意事项

• ✅ 优先修计算和数据错误——这些是硬伤，改了内容才可信
• ✅ 第二个修逻辑断链——读者看不懂时最容易放弃
• ✅ 策略完整性补充要克制——加太多会让文章臃肿，用 admonition 折叠收纳
• ⚠️ 不要边改边写新的长段落——先修完原始问题，再决定是否扩写
• ⚠️ 结论段落最容易遗留旧数据——修改数据后必须全文搜索旧数值

延伸阅读

• 博客：当趋势策略遇上震荡市：一套全天候复合交易系统的设计手记（本次编辑的实战案例）
• 相关方法：结构化读书笔记写作框架

维护人：yiiewang · 最后更新：2026-07-08

评论