---
title: "为什么定义很重要"
author: "Shawn Jiang"
lang: zh
date: 2026-08-29
canonical: https://tplog.dev/zh/essay/why-definitions-matter/
translations:
  en: https://tplog.dev/en/essay/why-definitions-matter/
  ja: https://tplog.dev/ja/essay/why-definitions-matter/
---

# 为什么定义很重要

学习一个东西，最好的方式之一，是回到它最基本的定义。

不要因为一个概念看起来像常识，就停止追问：它到底是什么？能不能用一句话说清楚？

这个问题看似简单，实际上很难。我们经常会使用一个词，却未必真正理解它。我们知道它通常在什么场合出现，见过别人怎么说，也能模仿着使用。但一旦被要求给出定义，理解中的空白就会暴露出来。

比如 Git 里的“冲突”。

冲突不等于 main 向前推进了，也不等于双方修改了同一个文件。更准确地说：

> 当 Git 尝试整合两条开发历史时，发现某些修改无法自动合并，因此需要由人决定最终结果。

假设我基于旧版本修改了一段代码。与此同时，main 也改动了同一处。当 Git 尝试把两边的修改放在一起时，它知道双方分别做了什么，却无法判断最终应该采用哪种结果。

它不能替我选择。

<figure class="figure">
  <img src="/images/essay/why-definitions-matter/git-conflict.jpeg" alt="main 与我的 commit 修改了同一处，Git 无法替人选择最终结果" width="2560" height="1429" loading="lazy" decoding="async" />
  <figcaption class="figure-caption">Git 能找出两边互不兼容的修改，但不能替人决定最终结果</figcaption>
</figure>

于是 Git 停下来，标出冲突的位置，把决定权交给我：保留 main 的版本，保留我的版本，还是把两边重新整理成第三种结果。

一旦明确了这个定义，许多问题也随之变得清楚。

main 有了新提交，不一定会产生冲突。双方修改了同一个文件，也不一定会产生冲突。只要改动发生在不同位置，或者 Git 能判断它们应该如何共存，就仍然可以自动合并。

真正的冲突发生在：两边的修改无法被 Git 自动整理成一个确定的结果。

## 先把边界划清楚

一个好的定义不仅告诉我们某个东西是什么，也告诉我们它不是什么。它帮助我们区分表面上相似、实际上不同的情况。

如果没有这条边界，我们可能会把“main 更新了”“同一个文件被修改了”和“发生冲突”混为一谈。遇到问题时，也就容易找错原因：以为只要别人提交了代码，自己的分支就一定会冲突；或者为了避免冲突，不敢修改别人碰过的文件。

定义让我们知道，真正需要关注的不是“有没有人改过”，而是“这些修改能不能被自动合并”。

## 让结论有来路

理解一个概念，不只是记住一句解释，而是能够从这句话继续往下推。

既然冲突意味着 Git 无法自动决定最终结果，那么解决冲突的本质，就不是消除几行特殊标记，而是替 Git 做出判断。你需要理解两边的修改分别想解决什么问题，再决定最终代码应该是什么样子。

由此还可以继续推导：能够通过编译，不代表冲突已经被正确解决；把其中一边全部删除，也不一定是正确答案；冲突标记消失，只能说明 Git 接受了你的选择，不能说明这个选择符合代码原本的意图。

这些结论不需要逐条背诵。只要理解定义，就能顺着它推出来。

很多知识之所以显得零散，是因为我们记住了大量结论，却没有找到产生这些结论的起点。定义就像一棵树的根。根抓得越稳，后来遇到的新问题越容易被放进同一个结构里理解。

## 先确认说的是同一件事

很多争论表面上是在讨论结论，实际上是双方使用了同一个词，却赋予它不同的含义。

有人说一个产品“简单”，指的是功能少；有人指的是第一次使用时容易理解；还有人指的是长期使用时不需要反复维护。三个人都在谈“简单”，讨论的却不是同一件事。

类似的词还有很多：效率、质量、完成、稳定、风险、自由、公平。

这些词越常见，我们越容易误以为大家已经理解彼此。可一旦进入具体讨论，隐藏在词语背后的差异就会出现。一个人说“这个功能已经完成”，可能只是指代码写完了；另一个人理解的完成，则包括测试、文档、上线和监控。

如果不先澄清定义，后面的讨论越深入，偏差可能越大。

因此，在重要的讨论里，追问“你说的这个词具体指什么”，并不是咬文嚼字。它是在确认双方是否站在同一块地面上。

## 你真的理解了吗

模糊的理解往往让人感觉良好。只要不需要解释，我们很容易认为自己已经懂了。

给出定义却迫使我们做出选择：哪些特征是核心，哪些只是经常伴随出现；哪些情况应该包括，哪些情况应该排除；如果拿掉某个条件，这个概念是否还成立？

这也是为什么“用自己的话解释一遍”是一种有效的学习方法。它不是把原文换一种说法，而是在测试我们能否抓住概念中不可缺少的部分。

当然，用一句话说清楚，并不意味着把所有复杂性都塞进一句话。

定义不是对现实的完整描述，而是进入现实的一扇门。它必须足够简洁，让人抓住核心；也必须足够准确，不把重要的区别抹掉。过于宽泛的定义没有区分能力，过于狭窄的定义又会把真实情况排除在外。

更重要的是，定义也有适用范围。

日常交流中的“冲突”，与 Git 中的“冲突”并不相同；法律、数学和哲学对同一个词也可能有各自的定义。我们不能脱离语境，寻找一句永远正确、适用于所有场合的话。

## 别把定义当成答案

定义不是讨论的终点，也不能代替观察、实践和判断。真实世界经常存在边缘情况，旧定义也可能随着知识的发展而被修正。定义的价值，不是把复杂事物永远固定下来，而是给当前的思考提供一个清楚、可检验的起点。

当一个问题变得混乱时，不妨先退一步：我们说的这个东西，到底是什么？

许多问题不会因为找到定义就自动消失。但有了定义，我们至少知道自己在讨论什么，问题发生在哪里，以及下一步应该往哪个方向思考。

这已经是理解一件事的重要开始。
