如果你最近一直在关注大模型可能已经注意到一个有趣的现象今天的人工智能可以写出结构完整的论文、可以生成风格统一的代码、可以在各种考试中拿到高分但你让它回答“杯子里有一半水把杯子倒过来水会怎样”这种三岁小孩都能答对的问题它却可能给出一个离谱的答案。这不是模型不够聪明而是因为它缺少一种人类最基础的认知能力——常识。更值得注意的是早在半个多世纪以前就有人把这个问题当作人工智能的核心命题正式提了出来。这个人就是 John McCarthy人工智能这个领域的命名者、LISP 语言的发明人、1971 年图灵奖得主。他一生中反复追问的一个问题是能不能用逻辑的方法把人类的常识形式化让机器可以理解和推理这篇文章不打算写成一篇历史人物传记而是想借 McCarthy 的学术遗产回答一个今天依然困扰很多 AI 工程师的问题为什么大模型看起来很聪明却依然缺乏真正的理解能力逻辑和常识形式化到底在今天的 AI 工程中还有没有用如果有用我们应该怎么用在展开之前先给一个明确判断逻辑并没有过时。恰恰相反它正在成为下一阶段 AI 系统补齐认知短板的必要基础设施。读完这篇文章你会理解 McCarthy 提出的“常识形式化”到底指什么知道为什么过去几十年它没有完全成功也能看到今天我们应该如何把它与大模型、知识图谱、规则引擎等技术结合起来。在技术圈里搜索“Logic”这个词时很容易搜到逻辑分析仪、数字电路调试等硬件方向的内容。本文讨论的是另一个语境下的 Logic——数理逻辑与人工智能中的知识表示。两者不要混淆。1. 为什么今天必须重看 McCarthy 的常识形式化先说一个很多人对 McCarthy 的误解以为他只是个研究符号逻辑的老派学者他的工作在深度学习时代已经没有参考价值了。实际情况恰恰相反。从 2023 年到现在的多轮大模型技术迭代中业界的核心焦虑逐渐从“模型生成能力不够强”转向“模型是否具备稳健的推理能力、是否能在复杂任务中不出错”。在大量真实业务场景中大模型的文本生成能力早就够用了真正限制它落地的是稳定性、可控性和对基础的因果关系建模。这些问题的本质都与 McCarthy 当年提出的问题高度重合。所谓“常识形式化”通俗地说就是把人类默认知道、无需言明的那些背景知识用计算机可以处理的逻辑结构表达出来。比如“东西掉到地上通常会碎”“人进入房间之后如果不出来就还在房间里”“鸟通常能飞企鹅不能飞”这些再普通不过的规则。如果只靠大规模语料统计模型确实能学到很多常识的“统计相关性”。比如它知道“杯子”和“碎”经常同时出现。但相关性不等于因果也不等于逻辑约束。在关键业务系统里我们需要的是可解释、可验证、可回滚的规则而不是一个概率性的建议。所以这篇文章的核心任务是把 McCarthy 的学术思想翻译成今天工程师能理解、能落地的语言。我们既讲概念也会给出可运行的代码示例让你看到一个用逻辑表示常识并完成推理的最小系统是什么样子。2. 麦卡锡是谁AI 与逻辑的起点1956 年达特茅斯学院。一群年轻学者聚在一起讨论一个新奇的想法能不能让机器模拟智能John McCarthy 是这个会议的发起人之一正是这次会议正式使用了“Artificial Intelligence”这个术语。所以说 McCarthy 是“AI 的命名者”并不夸张。除了命名之外McCarthy 还有几个关键贡献值得记住第一他发明了 LISP。这是继 FORTRAN 之后最古老的编程语言之一也是符号 AI 长期使用的主力语言。LISP 对后来的人工智能研究影响深远很多早期的专家系统、自然语言理解系统都是基于 LISP 开发的。第二他提出了“情景演算”Situation Calculus。这是用一阶逻辑描述动作和状态变化的一个框架专门用来解决“机器人在执行动作之后世界状态如何变化”的推理问题。今天的机器人规划、智能体任务规划领域依然能看到情景演算的影子。第三他从 1959 年就开始写关于“程序员智能程序需要常识”的文章。其中最有名的一篇题目就叫Programs with Common Sense在这篇文章里他提出了“咨询系统”Advice Taker的构想一个可以用逻辑语句接收建议、并通过演绎推理执行行动的程序。如果你去看那篇文章会发现里面的设想非常超前。他设想系统内部不是硬编码每一步怎么做而是维护一个形式化的知识库系统通过逻辑推导来决定行动。这个思想本质上就是今天基于知识图谱或规则引擎的智能体的雏形。理解 McCarthy 的贡献关键不在于记住人名和年代而在于看清一条技术路径他选择用逻辑作为 AI 的底层语言。这种思路后来被概括为“符号主义”。与今天主流的“连接主义”神经网络相比符号主义的优势是精确、可解释、有严格的形式化基础劣势是脆、难以处理模糊和不确定性。“逻辑”这个词在 McCarthy 的工作里是指数理逻辑尤其是谓词逻辑Predicate Logic。它不是我们日常说的“这件事合不合逻辑”那种模糊概念而是一种严格的语言系统有明确的语法、语义和推理规则。3. 常识形式化三个被误解的核心概念在开始写代码之前必须先把 McCarthy 体系中三个最核心、也最容易被搞混的概念讲清楚。因为很多人在阅读相关资料时正是被这些术语劝退的。3.1 常识形式化Formalizing Common Sense这是 McCarthy 学术生涯的主题词。形式化意味着把自然语言中含糊的表述转写成严格的逻辑公式。比如“鸟会飞”这个常识在逻辑中不会直接表达成“Bird(x) - Fly(x)”因为这样不够完整还需要考虑例外。一个更贴近实际的形式化是加入“正常条件”Bird(x) ∧ Normal(x) → Fly(x)意思就是如果 x 是鸟且 x 处于正常状态那么 x 会飞。这里“正常状态”就是一个需要进一步定义或默认假设的约束。这样就把常识变成了可推理的规则。有人会问把常识形式化和写规则引擎有什么区别答案是没有本质区别规则引擎就是常识形式化的一种工程化实现。区别在于 McCarthy 的野心更大他想建立一套统一的逻辑框架让系统可以自动处理不一致、例外和状态变化而不只是简单地做 if-then 匹配。3.2 情景演算Situation Calculus情景演算主要解决“动态世界中的推理”问题。核心思想是引入一个“情景”Situation的概念表示世界在某个时间点的状态。动作被建模为从一个情景到另一个情景的转换函数。经典的表示方式包括do(action, situation)表示在某个情景下执行动作之后产生的新情景。poss(action, situation)表示某个动作在某个情景下是否可行。效应公理描述动作对世界状态的影响。例如机器人开门这个动作可以写成poss(open_door, s) ↔ door_closed(s)意思是在情景 s 中打开门是可行的当且仅当门在情景 s 中是关着的且没有锁住。情景演算早期有一个著名难题——“框架问题”Frame Problem如何在动作执行后只更新受动作影响的状态而默认其它状态不变。这个问题看似简单但在一阶逻辑中直接表达非常麻烦。McCarthy 的解决思路之一是引入“最小实体”思想只假设那些被逻辑公式强制为真的状态变化其它都保持不变。3.3 非单调逻辑Non-monotonic Logic传统逻辑是单调的已知事实和规则增加只会带来更多的结论不会推翻旧结论。但人类的常识推理不是这样的。当你说“鸟会飞”然后告诉你“这是一只企鹅”你立刻会改变结论企鹅不会飞。这就是非单调推理。McCarthy 提出过“默认逻辑”Default Logic专门用来处理这类“在没有反例时默认成立”的规则。默认逻辑里有一条典型的默认规则Bird(x) : M Fly(x) / Fly(x)这个公式的含义是如果 x 是鸟并且“x 会飞”和当前已知知识不矛盾那么就可以默认推出 x 会飞。一旦后来加入了“Penguin(x)”和“Penguin(x) → ¬Fly(x)”默认结论就会被撤销。这三个概念合在一起构成了 McCarthy 心中“会思考的程序”的蓝图用谓词逻辑表达知识用情景演算处理变化用默认逻辑容忍例外。概念解决的问题一句话理解典型应用常识形式化知识表达把“人人都知道的事”写成机器能用的规则知识图谱、规则引擎情景演算动态推理描述动作执行后世界怎么变机器人规划、智能体任务规划非单调逻辑例外处理默认成立但可通过新信息推翻法律推理、医疗诊断、业务规则4. 现代 AI 缺的不是算力是常识现在回到现实问题今天的 AI 系统到底缺什么从技术角度看今天的深度学习模型是一个巨大的“函数逼近器”。它从海量数据中学到输入到输出的映射关系这种方式在感知任务上效果极好但在需要严格逻辑推导、需要组合多个步骤、需要遵守业务约束的任务上经常暴露出结构性的弱点。举几个真实场景场景一客服机器人。用户说“我买的东西三天没到”。机器人如果只知道关键词匹配可能会直接回复物流信息查询方式。但如果它具备常识推理应该能想到三天没到是否正常要取决于商家承诺的时效、发货城市和目的地距离、当前是否节假日。这个推理过程涉及大量背景知识仅靠统计模型很难稳定完成。场景二自动驾驶。自动驾车系统识别出路边的锥桶很容易。但要理解“锥桶可能意味着前方施工施工可能有工人工人可能突然走到路上”这就不是简单的目标检测能完成的。它需要把一个感知事件放到一组因果链中推断。场景三智能文档处理。合同审核系统需要理解“如果甲方逾期付款乙方有权解除合同”这样的条款。这里涉及法律领域的时间和事件推理逾期多久算违约解除合同之后已经履行的部分怎么处理这类问题不能靠文本分类模型给出可靠的输出。这些场景共同的特点是问题需要在知识约束下做多步推理并且推理过程必须可审查、可回滚。深度学习模型擅长的是“感知”——识别模式、生成文本、分类图像而在“推理”这个环节目前的神经网络仍然不能保证正确性。McCarthy 当年选择逻辑正是因为他看到了感知之外的另一半哪怕机器能完美地感知世界如果无法在已有知识基础上做出合乎逻辑的决策它依然算不上真正的智能。这里需要澄清一个常见的误区逻辑和深度学习不是“非此即彼”的对立关系。恰恰相反两者解决的是不同层次的问题。McCarthy 的常识形式化思想在今天最有价值的落点是与深度学习系统组成混合架构而不是取代深度学习。5. 逻辑在当代 AI 的回归路线神经符号与知识工程既然逻辑如此重要为什么过去几十年符号主义会式微原因并不复杂人工构建大规模常识知识库的成本极高而且很难覆盖真实世界的开放性。相比之下神经网络可以用数据驱动的方式自动学习特征效果提升明显。但最近几年出现了一个明显的趋势“神经符号”Neuro-Symbolic方法开始回归。各大研究机构都在尝试把神经网络的感知能力和符号系统的推理能力结合起来。这个方向与 McCarthy 的思想一脉相承。以下是当前常见的三种融合方式方式一规则约束模型输出。在深度模型的训练或推理阶段加入业务规则作为约束。比如法律问答系统在模型生成回答前先用规则引擎判断案件类型再用大模型生成具体回复。这样输出既符合事实约束又具有生成灵活性。方式二知识增强检索。在 RAG检索增强生成架构中把企业知识库中的规则、产品手册、约束条款预先用逻辑结构组织起来作为检索和校验的依据。当大模型生成结果时系统用规则库做一致性校验发现问题就触发重新生成或人工介入。方式三符号推理作为验证层。把大模型当作一个“假设生成器”生成多个候选答案再用符号推理引擎如规则引擎、定理证明器验证哪个候选答案在逻辑上成立。这个思路已经在部分自动化数据分析、代码生成产品中开始落地。这类架构中McCarthy 当年提出的情景演算和非单调逻辑不是作为“理论装饰”而是作为规则引擎底层的推理语义在发挥作用。为了让你对“逻辑与 AI 结合”的工程实现有直观感受下面几节将给出一个最小但完整的推理系统示例。我们不依赖任何重型框架直接用 Python 标准库实现一个前向链推理器用来证明“人能推理”这件事可以用代码表达。6. 环境准备与工具选型本文的代码示例只需要一个 Python 3.8 以上的环境不需要安装第三方依赖。你可以用任何操作系统在任意 IDE 或命令行环境中运行。为什么要选择纯标准库实现有两个原因第一它能清楚地展示逻辑推理的底层机制而不被框架 API 掩盖。第二在企业项目中如果我们只是想验证某个推理思路是否可行直接用标准库做原型往往最快。如果你打算在真实项目中搭建基于逻辑的知识推理体系业界有更成熟的工具可以选择这里列出几个常见方向作为参考工具/库类型适用场景Prolog逻辑编程语言学术原型、规则推理、自然语言语义分析CLIPS专家系统工具传统专家系统、业务规则引擎DroolsJava 规则引擎企业级业务规则、风控、审批流JenaJava 知识图谱框架RDF/OWL 数据上的语义推理Neo4j图数据库知识图谱存储与图查询Python 标准库通用语言原型验证、教学、简单规则系统这里强调一点本文中的 Python 示例只是为了说明推理机制它不是要替代任何成熟的规则引擎。在真实生产环境中推荐根据语言栈和业务场景选择合适的专业工具。版本选择请以实际项目为准本文重点展示通用思路。7. 完整示例用 Python 写一个前向链推理器前向链推理Forward Chaining是规则引擎最基础的算法之一已知一组事实和一组规则不断匹配规则前件如果前件满足就执行规则后件把新结论加入事实库直到无法推出新结论为止。我们用这个机制表达一组非常简单的常识所有人都会死。苏格拉底是人。因此苏格拉底会死。这看起来很简单但它包含了一个逻辑推理系统的全部核心要素事实、规则、匹配、结论生成。先给出完整代码# 文件路径forward_chain.py from typing import Set, Tuple, List # 用字符串表示事实 Fact str # 规则前件是事实集合后件是结论 Rule Tuple[Set[Fact], Fact] def forward_chain(facts: Set[Fact], rules: List[Rule]) - Set[Fact]: 前向链推理 从已知事实出发反复应用规则直到没有新事实产生。 known_facts: Set[Fact] set(facts) changed True while changed: changed False for premises, conclusion in rules: if premises.issubset(known_facts) and conclusion not in known_facts: known_facts.add(conclusion) changed True print(f规则命中: {premises} - {conclusion}) return known_facts if __name__ __main__: # 初始事实 fact_set: Set[Fact] {Socrates_is_human} # 规则库 rule_list: List[Rule] [ ({Socrates_is_human}, Socrates_is_mortal), ({Socrates_is_mortal}, Socrates_dies), ] result forward_chain(fact_set, rule_list) print(最终事实库, result)这个代码的核心逻辑在forward_chain函数中。复制一份初始事实集合known_facts作为推理的起点。用 while 循环反复扫描规则列表。如果某条规则的所有前件都出现在已知事实中并且后件还没被推出来就把后件加入事实库并标记本轮有变化。一轮扫描后如果没有新事实产生说明推理达到不动点Fixpoint退出循环。运行方式python forward_chain.py预期输出规则命中: {Socrates_is_human} - Socrates_is_mortal 规则命中: {Socrates_is_mortal} - Socrates_dies 最终事实库 {Socrates_is_mortal, Socrates_is_human, Socrates_dies}这个结果说明系统从“苏格拉底是人”这个事实出发自动推导出了“苏格拉底会死”和“苏格拉底会死亡”。你可能觉得这没什么了不起但它回答了一个关键问题机器确实可以在不预先把答案写死的情况下通过规则在运行期推出新结论。这正是 McCarthy 所说的“程序获得常识”的最低成本版本。接下来我们在这个最小推理器之上加入一个更接近真实常识推理的特征规则可以有条件触发且可以处理“正常情况默认成立”的行为。我们扩展一下规则格式增加“否定前件”的处理用非单调的方式演示一个简单的例外场景。这个示例展示的是“鸟通常能飞但企鹅不会飞”的经典非单调推理问题。我们依然不引入外部依赖直接用 Python 代码维护一个带“优先级”的规则系统。# 文件路径default_logic_demo.py from typing import Dict, List, Set # 定义规则为字典方便表达优先级 # 每条规则包含前件、结论、是否默认规则、优先级 RuleDict Dict[str, object] class DefaultLogicSystem: def __init__(self): self.facts: Set[str] set() # 规则按优先级排序高优先级在前 self.rules: List[RuleDict] [] def add_fact(self, fact: str): self.facts.add(fact) def add_rule(self, rule: RuleDict): self.rules.append(rule) self.rules.sort(keylambda r: r.get(priority, 0), reverseTrue) def infer(self) - Set[str]: changed True while changed: changed False for rule in self.rules: premises rule[premises] conclusion rule[conclusion] exceptions rule.get(exceptions, []) # 前件全部满足 if not premises.issubset(self.facts): continue # 例外条件存在时跳过该规则 if any(exp in self.facts for exp in exceptions): continue if conclusion not in self.facts: self.facts.add(conclusion) changed True print(f推出新事实: {conclusion} (规则: {rule[name]})) return self.facts if __name__ __main__: system DefaultLogicSystem() # 加入常识鸟通常能飞默认规则优先级较低 system.add_rule({ name: bird_fly_default, premises: {Bird}, conclusion: Fly, exceptions: [Penguin, BrokenWing], priority: 1, }) # 加入严格规则企鹅不会飞优先级更高 system.add_rule({ name: penguin_not_fly, premises: {Penguin}, conclusion: NotFly, exceptions: [], priority: 10, }) system.add_fact(Bird) system.add_fact(Penguin) system.add_fact(Animal) result system.infer() print(最终事实库, result)运行python default_logic_demo.py预期输出推出新事实: NotFly (规则: penguin_not_fly) 最终事实库 {Penguin, NotFly, Bird, Animal}注意观察系统中同时存在“鸟会飞”的规则但因为“Penguin”这个例外条件已经进入事实库默认规则被跳过。这就是非单调性的一个直观体现新增信息不仅可能推出新结论还可能阻止旧结论的产生。这个行为在传统单调逻辑里是做不到的。这个示例非常小但它回答了一个大问题常识推理不是“全有或全无”的判断而是一个“在默认假设下成立但在特定证据下被推翻”的动态过程。McCarthy 主张的“默认逻辑”解决的就是这个问题。8. 情景演算与动作推理再进一步如果前两个示例让你对“静态常识推理”有了概念那么第三个示例将把问题推向 McCarthy 体系中最具前瞻性的部分动作和状态变化推理。在智能体应用中系统不仅要回答“现在什么是真的”还要回答“如果我执行某个动作接下来什么会变成真的”。这种推理模式正是情景演算要处理的。我们用 Python 实现一个最简版的情景演算模型世界有两个状态——门关着和门开着。机器人在某个状态下执行“开门”动作产生新状态。系统需要根据状态约束判断动作是否可行。# 文件路径situation_calculus_demo.py from typing import Dict, List, Tuple # 状态用字典表示key 是命题value 是布尔值 State Dict[str, bool] # 动作执行器输入状态和动作名输出新状态或抛出异常 def execute_action(state: State, action: str) - State: new_state state.copy() if action open_door: # 前置条件门是关着的且没有锁住 if state.get(door_locked, False): raise ValueError(门已锁定无法打开) if not state.get(door_open, True): # 这里用 True 作为默认值有点怪下面会修正 pass # 更严谨的写法是检查关闭状态 if state.get(door_open, False): raise ValueError(门已经是打开的) new_state[door_open] True new_state[door_locked] False # 开门后锁的状态通常保持不变这里简化为演示 elif action lock_door: # 前置条件门是关闭的 if state.get(door_open, True): raise ValueError(门是打开的无法上锁) new_state[door_locked] True else: raise ValueError(f未知动作: {action}) return new_state def poss(state: State, action: str) - Tuple[bool, str]: 检查动作是否可行返回 (是否可行, 原因) try: execute_action(state, action) return True, except ValueError as e: return False, str(e) if __name__ __main__: # 初始状态门关着未锁定 s0: State {door_open: False, door_locked: False} print(初始状态, s0) # 检查开门是否可行 ok, reason poss(s0, open_door) print(fopen_door 是否可行: {ok} {reason}) if ok: s1 execute_action(s0, open_door) print(执行 open_door 后, s1) # 在门开着的状态下尝试上锁 ok2, reason2 poss(s1, lock_door) print(flock_door 是否可行: {ok2} {reason2}) # 在门开着的状态下开门会怎样 ok3, reason3 poss(s1, open_door) print(f再次 open_door 是否可行: {ok3} {reason3})运行python situation_calculus_demo.py预期输出初始状态 {door_open: False, door_locked: False} open_door 是否可行: True 执行 open_door 后 {door_open: True, door_locked: False} lock_door 是否可行: False 门是打开的无法上锁 再次 open_door 是否可行: False 门已经是打开的这个示例虽然简单但演示了情景演算最重要的两个机制动作的前提条件检查poss函数。动作之后状态的变化execute_action返回新状态。更完整的场景中你还需要引入“框架公理”frame axioms来显式声明哪些状态没有发生变化避免在每个动作后重新计算整个世界的状态。这也是 McCarthy 当年面对“框架问题”时给出的核心思路用最小变化原则默认不动的东西就不动。在真实业务系统中这种“动作可行性 状态转移”的建模方式可以被用来处理订单状态机、权限审批流、设备控制指令校验等场景。它的好处是状态转换是完全可预测、可审计的不像直接写 if-else 那样容易在复杂分支中遗漏边界条件。9. 常见问题与排查思路在学习和使用逻辑推理相关技术时工程师最常遇到的问题往往不是理论难而是“理论与工程之间的翻译层”出了问题。下面整理几个高频问题问题现象可能原因排查方式解决方案推理结果不更新规则前件中的事实拼写不一致打印规则前件和已知事实集合对比字符串统一事实命名建立事实字典默认规则被错误触发例外条件没有正确加入事实库检查exceptions列表是否覆盖所有例外场景在规则中加入显式的优先级和例外条件动作执行不符合预期前置条件检查不完整单步调试poss函数打印状态快照为每个动作补充完整的前置条件与效应公理循环推理死循环规则之间存在循环依赖且没有去重在添加新事实前检查是否已存在设置最大迭代次数或在进入循环前检查去重知识库规模过大时性能差每次扫描所有规则复杂度高分析规则数量与事实数量引入规则索引或改用手写 forward chaining 引擎 / 图数据库与深度学习模型结合时冲突逻辑规则与模型输出矛盾对比规则输出与模型输出的置信度将规则作为硬约束模型输出作为候选假设如果你在运行前两节代码时遇到问题优先检查两个地方一是 Python 版本是否为 3.8二是是否在同一个文件目录下运行命令避免路径错误。10. 最佳实践与工程建议最后把 McCarthy 的思想落地到实际项目时有几个工程原则能显著提高成功率。10.1 先界定“常识”的范围不要试图把整个世界都形式化。企业系统中的“常识”通常是很窄的一组规则例如业务状态机、领域约束、行业规范。先定义一个最小但完整的问题边界再逐步扩展。10.2 规则与事实分离把规则、事实、推理引擎三个层次分开设计。规则由业务人员维护事实由系统运行时产生推理引擎是通用组件。这样当业务规则变化时不需要改代码。10.3 与大模型配合时逻辑层负责“硬约束”如果你正在构建一个“大模型 逻辑”的混合系统建议把逻辑推理放在大模型之前或之后而不是指望大模型自己完成逻辑推导。常见做法是先用规则引擎做事实检查和状态校验再让大模型生成自然语言回复或者先让大模型生成候选答案再用规则引擎校验。10.4 保留人工审查入口在涉及合同、医疗、法律等高风险领域逻辑推理的结果必须保留人工审核环节。McCarthy 的设想是机器具备常识但工程系统的责任边界依然要由人来界定。10.5 日志与可解释性逻辑推理的优点之一是可解释。你需要记录每一次规则匹配的完整路径哪条规则被触发、输入是什么、为什么被触发。一旦线上出现错误决策这个日志就是排查的核心依据。11. 总结与后续学习方向McCarthy 的“常识形式化”并不是一个过时的理论包袱而是一份还没有被完全兑现的技术蓝图。今天的深度学习已经解决了感知层面的很多问题而常识推理这个麦卡锡几十年前就钉在 AI 路线图上的难题现在才刚刚显示出它的紧迫性。如果你想继续深入这个方向我建议按下面的路径走手写一个更完善的前向/反向链推理器自己设计规则集合并测试。学习谓词逻辑语法与语义掌握量词、蕴含、合取、析取的标准表达。阅读 McCarthy 的原始论文重点是Programs with Common Sense和Some Philosophical Problems from the Standpoint of Artificial Intelligence。了解 RAG 与规则引擎的结合方式在真实项目中做一个最小原型。研究知识图谱、OWL 与描述逻辑理解现代语义网与 McCarthy 思想之间的传承关系。最后给一个实用建议不要试图一开始就构建一个“全知全能”的常识知识库。从一个只包含几条规则的最小系统开始先跑通推理链路再逐步增加规则。你会发现真正困难的地方不是规则的写法而是如何判断哪些知识是值得形式化的、哪些知识用统计方法处理就够了。这条边界正是未来 AI 工程中最重要的判断力之一。
麦卡锡的常识形式化：逻辑如何补齐大模型推理短板
如果你最近一直在关注大模型可能已经注意到一个有趣的现象今天的人工智能可以写出结构完整的论文、可以生成风格统一的代码、可以在各种考试中拿到高分但你让它回答“杯子里有一半水把杯子倒过来水会怎样”这种三岁小孩都能答对的问题它却可能给出一个离谱的答案。这不是模型不够聪明而是因为它缺少一种人类最基础的认知能力——常识。更值得注意的是早在半个多世纪以前就有人把这个问题当作人工智能的核心命题正式提了出来。这个人就是 John McCarthy人工智能这个领域的命名者、LISP 语言的发明人、1971 年图灵奖得主。他一生中反复追问的一个问题是能不能用逻辑的方法把人类的常识形式化让机器可以理解和推理这篇文章不打算写成一篇历史人物传记而是想借 McCarthy 的学术遗产回答一个今天依然困扰很多 AI 工程师的问题为什么大模型看起来很聪明却依然缺乏真正的理解能力逻辑和常识形式化到底在今天的 AI 工程中还有没有用如果有用我们应该怎么用在展开之前先给一个明确判断逻辑并没有过时。恰恰相反它正在成为下一阶段 AI 系统补齐认知短板的必要基础设施。读完这篇文章你会理解 McCarthy 提出的“常识形式化”到底指什么知道为什么过去几十年它没有完全成功也能看到今天我们应该如何把它与大模型、知识图谱、规则引擎等技术结合起来。在技术圈里搜索“Logic”这个词时很容易搜到逻辑分析仪、数字电路调试等硬件方向的内容。本文讨论的是另一个语境下的 Logic——数理逻辑与人工智能中的知识表示。两者不要混淆。1. 为什么今天必须重看 McCarthy 的常识形式化先说一个很多人对 McCarthy 的误解以为他只是个研究符号逻辑的老派学者他的工作在深度学习时代已经没有参考价值了。实际情况恰恰相反。从 2023 年到现在的多轮大模型技术迭代中业界的核心焦虑逐渐从“模型生成能力不够强”转向“模型是否具备稳健的推理能力、是否能在复杂任务中不出错”。在大量真实业务场景中大模型的文本生成能力早就够用了真正限制它落地的是稳定性、可控性和对基础的因果关系建模。这些问题的本质都与 McCarthy 当年提出的问题高度重合。所谓“常识形式化”通俗地说就是把人类默认知道、无需言明的那些背景知识用计算机可以处理的逻辑结构表达出来。比如“东西掉到地上通常会碎”“人进入房间之后如果不出来就还在房间里”“鸟通常能飞企鹅不能飞”这些再普通不过的规则。如果只靠大规模语料统计模型确实能学到很多常识的“统计相关性”。比如它知道“杯子”和“碎”经常同时出现。但相关性不等于因果也不等于逻辑约束。在关键业务系统里我们需要的是可解释、可验证、可回滚的规则而不是一个概率性的建议。所以这篇文章的核心任务是把 McCarthy 的学术思想翻译成今天工程师能理解、能落地的语言。我们既讲概念也会给出可运行的代码示例让你看到一个用逻辑表示常识并完成推理的最小系统是什么样子。2. 麦卡锡是谁AI 与逻辑的起点1956 年达特茅斯学院。一群年轻学者聚在一起讨论一个新奇的想法能不能让机器模拟智能John McCarthy 是这个会议的发起人之一正是这次会议正式使用了“Artificial Intelligence”这个术语。所以说 McCarthy 是“AI 的命名者”并不夸张。除了命名之外McCarthy 还有几个关键贡献值得记住第一他发明了 LISP。这是继 FORTRAN 之后最古老的编程语言之一也是符号 AI 长期使用的主力语言。LISP 对后来的人工智能研究影响深远很多早期的专家系统、自然语言理解系统都是基于 LISP 开发的。第二他提出了“情景演算”Situation Calculus。这是用一阶逻辑描述动作和状态变化的一个框架专门用来解决“机器人在执行动作之后世界状态如何变化”的推理问题。今天的机器人规划、智能体任务规划领域依然能看到情景演算的影子。第三他从 1959 年就开始写关于“程序员智能程序需要常识”的文章。其中最有名的一篇题目就叫Programs with Common Sense在这篇文章里他提出了“咨询系统”Advice Taker的构想一个可以用逻辑语句接收建议、并通过演绎推理执行行动的程序。如果你去看那篇文章会发现里面的设想非常超前。他设想系统内部不是硬编码每一步怎么做而是维护一个形式化的知识库系统通过逻辑推导来决定行动。这个思想本质上就是今天基于知识图谱或规则引擎的智能体的雏形。理解 McCarthy 的贡献关键不在于记住人名和年代而在于看清一条技术路径他选择用逻辑作为 AI 的底层语言。这种思路后来被概括为“符号主义”。与今天主流的“连接主义”神经网络相比符号主义的优势是精确、可解释、有严格的形式化基础劣势是脆、难以处理模糊和不确定性。“逻辑”这个词在 McCarthy 的工作里是指数理逻辑尤其是谓词逻辑Predicate Logic。它不是我们日常说的“这件事合不合逻辑”那种模糊概念而是一种严格的语言系统有明确的语法、语义和推理规则。3. 常识形式化三个被误解的核心概念在开始写代码之前必须先把 McCarthy 体系中三个最核心、也最容易被搞混的概念讲清楚。因为很多人在阅读相关资料时正是被这些术语劝退的。3.1 常识形式化Formalizing Common Sense这是 McCarthy 学术生涯的主题词。形式化意味着把自然语言中含糊的表述转写成严格的逻辑公式。比如“鸟会飞”这个常识在逻辑中不会直接表达成“Bird(x) - Fly(x)”因为这样不够完整还需要考虑例外。一个更贴近实际的形式化是加入“正常条件”Bird(x) ∧ Normal(x) → Fly(x)意思就是如果 x 是鸟且 x 处于正常状态那么 x 会飞。这里“正常状态”就是一个需要进一步定义或默认假设的约束。这样就把常识变成了可推理的规则。有人会问把常识形式化和写规则引擎有什么区别答案是没有本质区别规则引擎就是常识形式化的一种工程化实现。区别在于 McCarthy 的野心更大他想建立一套统一的逻辑框架让系统可以自动处理不一致、例外和状态变化而不只是简单地做 if-then 匹配。3.2 情景演算Situation Calculus情景演算主要解决“动态世界中的推理”问题。核心思想是引入一个“情景”Situation的概念表示世界在某个时间点的状态。动作被建模为从一个情景到另一个情景的转换函数。经典的表示方式包括do(action, situation)表示在某个情景下执行动作之后产生的新情景。poss(action, situation)表示某个动作在某个情景下是否可行。效应公理描述动作对世界状态的影响。例如机器人开门这个动作可以写成poss(open_door, s) ↔ door_closed(s)意思是在情景 s 中打开门是可行的当且仅当门在情景 s 中是关着的且没有锁住。情景演算早期有一个著名难题——“框架问题”Frame Problem如何在动作执行后只更新受动作影响的状态而默认其它状态不变。这个问题看似简单但在一阶逻辑中直接表达非常麻烦。McCarthy 的解决思路之一是引入“最小实体”思想只假设那些被逻辑公式强制为真的状态变化其它都保持不变。3.3 非单调逻辑Non-monotonic Logic传统逻辑是单调的已知事实和规则增加只会带来更多的结论不会推翻旧结论。但人类的常识推理不是这样的。当你说“鸟会飞”然后告诉你“这是一只企鹅”你立刻会改变结论企鹅不会飞。这就是非单调推理。McCarthy 提出过“默认逻辑”Default Logic专门用来处理这类“在没有反例时默认成立”的规则。默认逻辑里有一条典型的默认规则Bird(x) : M Fly(x) / Fly(x)这个公式的含义是如果 x 是鸟并且“x 会飞”和当前已知知识不矛盾那么就可以默认推出 x 会飞。一旦后来加入了“Penguin(x)”和“Penguin(x) → ¬Fly(x)”默认结论就会被撤销。这三个概念合在一起构成了 McCarthy 心中“会思考的程序”的蓝图用谓词逻辑表达知识用情景演算处理变化用默认逻辑容忍例外。概念解决的问题一句话理解典型应用常识形式化知识表达把“人人都知道的事”写成机器能用的规则知识图谱、规则引擎情景演算动态推理描述动作执行后世界怎么变机器人规划、智能体任务规划非单调逻辑例外处理默认成立但可通过新信息推翻法律推理、医疗诊断、业务规则4. 现代 AI 缺的不是算力是常识现在回到现实问题今天的 AI 系统到底缺什么从技术角度看今天的深度学习模型是一个巨大的“函数逼近器”。它从海量数据中学到输入到输出的映射关系这种方式在感知任务上效果极好但在需要严格逻辑推导、需要组合多个步骤、需要遵守业务约束的任务上经常暴露出结构性的弱点。举几个真实场景场景一客服机器人。用户说“我买的东西三天没到”。机器人如果只知道关键词匹配可能会直接回复物流信息查询方式。但如果它具备常识推理应该能想到三天没到是否正常要取决于商家承诺的时效、发货城市和目的地距离、当前是否节假日。这个推理过程涉及大量背景知识仅靠统计模型很难稳定完成。场景二自动驾驶。自动驾车系统识别出路边的锥桶很容易。但要理解“锥桶可能意味着前方施工施工可能有工人工人可能突然走到路上”这就不是简单的目标检测能完成的。它需要把一个感知事件放到一组因果链中推断。场景三智能文档处理。合同审核系统需要理解“如果甲方逾期付款乙方有权解除合同”这样的条款。这里涉及法律领域的时间和事件推理逾期多久算违约解除合同之后已经履行的部分怎么处理这类问题不能靠文本分类模型给出可靠的输出。这些场景共同的特点是问题需要在知识约束下做多步推理并且推理过程必须可审查、可回滚。深度学习模型擅长的是“感知”——识别模式、生成文本、分类图像而在“推理”这个环节目前的神经网络仍然不能保证正确性。McCarthy 当年选择逻辑正是因为他看到了感知之外的另一半哪怕机器能完美地感知世界如果无法在已有知识基础上做出合乎逻辑的决策它依然算不上真正的智能。这里需要澄清一个常见的误区逻辑和深度学习不是“非此即彼”的对立关系。恰恰相反两者解决的是不同层次的问题。McCarthy 的常识形式化思想在今天最有价值的落点是与深度学习系统组成混合架构而不是取代深度学习。5. 逻辑在当代 AI 的回归路线神经符号与知识工程既然逻辑如此重要为什么过去几十年符号主义会式微原因并不复杂人工构建大规模常识知识库的成本极高而且很难覆盖真实世界的开放性。相比之下神经网络可以用数据驱动的方式自动学习特征效果提升明显。但最近几年出现了一个明显的趋势“神经符号”Neuro-Symbolic方法开始回归。各大研究机构都在尝试把神经网络的感知能力和符号系统的推理能力结合起来。这个方向与 McCarthy 的思想一脉相承。以下是当前常见的三种融合方式方式一规则约束模型输出。在深度模型的训练或推理阶段加入业务规则作为约束。比如法律问答系统在模型生成回答前先用规则引擎判断案件类型再用大模型生成具体回复。这样输出既符合事实约束又具有生成灵活性。方式二知识增强检索。在 RAG检索增强生成架构中把企业知识库中的规则、产品手册、约束条款预先用逻辑结构组织起来作为检索和校验的依据。当大模型生成结果时系统用规则库做一致性校验发现问题就触发重新生成或人工介入。方式三符号推理作为验证层。把大模型当作一个“假设生成器”生成多个候选答案再用符号推理引擎如规则引擎、定理证明器验证哪个候选答案在逻辑上成立。这个思路已经在部分自动化数据分析、代码生成产品中开始落地。这类架构中McCarthy 当年提出的情景演算和非单调逻辑不是作为“理论装饰”而是作为规则引擎底层的推理语义在发挥作用。为了让你对“逻辑与 AI 结合”的工程实现有直观感受下面几节将给出一个最小但完整的推理系统示例。我们不依赖任何重型框架直接用 Python 标准库实现一个前向链推理器用来证明“人能推理”这件事可以用代码表达。6. 环境准备与工具选型本文的代码示例只需要一个 Python 3.8 以上的环境不需要安装第三方依赖。你可以用任何操作系统在任意 IDE 或命令行环境中运行。为什么要选择纯标准库实现有两个原因第一它能清楚地展示逻辑推理的底层机制而不被框架 API 掩盖。第二在企业项目中如果我们只是想验证某个推理思路是否可行直接用标准库做原型往往最快。如果你打算在真实项目中搭建基于逻辑的知识推理体系业界有更成熟的工具可以选择这里列出几个常见方向作为参考工具/库类型适用场景Prolog逻辑编程语言学术原型、规则推理、自然语言语义分析CLIPS专家系统工具传统专家系统、业务规则引擎DroolsJava 规则引擎企业级业务规则、风控、审批流JenaJava 知识图谱框架RDF/OWL 数据上的语义推理Neo4j图数据库知识图谱存储与图查询Python 标准库通用语言原型验证、教学、简单规则系统这里强调一点本文中的 Python 示例只是为了说明推理机制它不是要替代任何成熟的规则引擎。在真实生产环境中推荐根据语言栈和业务场景选择合适的专业工具。版本选择请以实际项目为准本文重点展示通用思路。7. 完整示例用 Python 写一个前向链推理器前向链推理Forward Chaining是规则引擎最基础的算法之一已知一组事实和一组规则不断匹配规则前件如果前件满足就执行规则后件把新结论加入事实库直到无法推出新结论为止。我们用这个机制表达一组非常简单的常识所有人都会死。苏格拉底是人。因此苏格拉底会死。这看起来很简单但它包含了一个逻辑推理系统的全部核心要素事实、规则、匹配、结论生成。先给出完整代码# 文件路径forward_chain.py from typing import Set, Tuple, List # 用字符串表示事实 Fact str # 规则前件是事实集合后件是结论 Rule Tuple[Set[Fact], Fact] def forward_chain(facts: Set[Fact], rules: List[Rule]) - Set[Fact]: 前向链推理 从已知事实出发反复应用规则直到没有新事实产生。 known_facts: Set[Fact] set(facts) changed True while changed: changed False for premises, conclusion in rules: if premises.issubset(known_facts) and conclusion not in known_facts: known_facts.add(conclusion) changed True print(f规则命中: {premises} - {conclusion}) return known_facts if __name__ __main__: # 初始事实 fact_set: Set[Fact] {Socrates_is_human} # 规则库 rule_list: List[Rule] [ ({Socrates_is_human}, Socrates_is_mortal), ({Socrates_is_mortal}, Socrates_dies), ] result forward_chain(fact_set, rule_list) print(最终事实库, result)这个代码的核心逻辑在forward_chain函数中。复制一份初始事实集合known_facts作为推理的起点。用 while 循环反复扫描规则列表。如果某条规则的所有前件都出现在已知事实中并且后件还没被推出来就把后件加入事实库并标记本轮有变化。一轮扫描后如果没有新事实产生说明推理达到不动点Fixpoint退出循环。运行方式python forward_chain.py预期输出规则命中: {Socrates_is_human} - Socrates_is_mortal 规则命中: {Socrates_is_mortal} - Socrates_dies 最终事实库 {Socrates_is_mortal, Socrates_is_human, Socrates_dies}这个结果说明系统从“苏格拉底是人”这个事实出发自动推导出了“苏格拉底会死”和“苏格拉底会死亡”。你可能觉得这没什么了不起但它回答了一个关键问题机器确实可以在不预先把答案写死的情况下通过规则在运行期推出新结论。这正是 McCarthy 所说的“程序获得常识”的最低成本版本。接下来我们在这个最小推理器之上加入一个更接近真实常识推理的特征规则可以有条件触发且可以处理“正常情况默认成立”的行为。我们扩展一下规则格式增加“否定前件”的处理用非单调的方式演示一个简单的例外场景。这个示例展示的是“鸟通常能飞但企鹅不会飞”的经典非单调推理问题。我们依然不引入外部依赖直接用 Python 代码维护一个带“优先级”的规则系统。# 文件路径default_logic_demo.py from typing import Dict, List, Set # 定义规则为字典方便表达优先级 # 每条规则包含前件、结论、是否默认规则、优先级 RuleDict Dict[str, object] class DefaultLogicSystem: def __init__(self): self.facts: Set[str] set() # 规则按优先级排序高优先级在前 self.rules: List[RuleDict] [] def add_fact(self, fact: str): self.facts.add(fact) def add_rule(self, rule: RuleDict): self.rules.append(rule) self.rules.sort(keylambda r: r.get(priority, 0), reverseTrue) def infer(self) - Set[str]: changed True while changed: changed False for rule in self.rules: premises rule[premises] conclusion rule[conclusion] exceptions rule.get(exceptions, []) # 前件全部满足 if not premises.issubset(self.facts): continue # 例外条件存在时跳过该规则 if any(exp in self.facts for exp in exceptions): continue if conclusion not in self.facts: self.facts.add(conclusion) changed True print(f推出新事实: {conclusion} (规则: {rule[name]})) return self.facts if __name__ __main__: system DefaultLogicSystem() # 加入常识鸟通常能飞默认规则优先级较低 system.add_rule({ name: bird_fly_default, premises: {Bird}, conclusion: Fly, exceptions: [Penguin, BrokenWing], priority: 1, }) # 加入严格规则企鹅不会飞优先级更高 system.add_rule({ name: penguin_not_fly, premises: {Penguin}, conclusion: NotFly, exceptions: [], priority: 10, }) system.add_fact(Bird) system.add_fact(Penguin) system.add_fact(Animal) result system.infer() print(最终事实库, result)运行python default_logic_demo.py预期输出推出新事实: NotFly (规则: penguin_not_fly) 最终事实库 {Penguin, NotFly, Bird, Animal}注意观察系统中同时存在“鸟会飞”的规则但因为“Penguin”这个例外条件已经进入事实库默认规则被跳过。这就是非单调性的一个直观体现新增信息不仅可能推出新结论还可能阻止旧结论的产生。这个行为在传统单调逻辑里是做不到的。这个示例非常小但它回答了一个大问题常识推理不是“全有或全无”的判断而是一个“在默认假设下成立但在特定证据下被推翻”的动态过程。McCarthy 主张的“默认逻辑”解决的就是这个问题。8. 情景演算与动作推理再进一步如果前两个示例让你对“静态常识推理”有了概念那么第三个示例将把问题推向 McCarthy 体系中最具前瞻性的部分动作和状态变化推理。在智能体应用中系统不仅要回答“现在什么是真的”还要回答“如果我执行某个动作接下来什么会变成真的”。这种推理模式正是情景演算要处理的。我们用 Python 实现一个最简版的情景演算模型世界有两个状态——门关着和门开着。机器人在某个状态下执行“开门”动作产生新状态。系统需要根据状态约束判断动作是否可行。# 文件路径situation_calculus_demo.py from typing import Dict, List, Tuple # 状态用字典表示key 是命题value 是布尔值 State Dict[str, bool] # 动作执行器输入状态和动作名输出新状态或抛出异常 def execute_action(state: State, action: str) - State: new_state state.copy() if action open_door: # 前置条件门是关着的且没有锁住 if state.get(door_locked, False): raise ValueError(门已锁定无法打开) if not state.get(door_open, True): # 这里用 True 作为默认值有点怪下面会修正 pass # 更严谨的写法是检查关闭状态 if state.get(door_open, False): raise ValueError(门已经是打开的) new_state[door_open] True new_state[door_locked] False # 开门后锁的状态通常保持不变这里简化为演示 elif action lock_door: # 前置条件门是关闭的 if state.get(door_open, True): raise ValueError(门是打开的无法上锁) new_state[door_locked] True else: raise ValueError(f未知动作: {action}) return new_state def poss(state: State, action: str) - Tuple[bool, str]: 检查动作是否可行返回 (是否可行, 原因) try: execute_action(state, action) return True, except ValueError as e: return False, str(e) if __name__ __main__: # 初始状态门关着未锁定 s0: State {door_open: False, door_locked: False} print(初始状态, s0) # 检查开门是否可行 ok, reason poss(s0, open_door) print(fopen_door 是否可行: {ok} {reason}) if ok: s1 execute_action(s0, open_door) print(执行 open_door 后, s1) # 在门开着的状态下尝试上锁 ok2, reason2 poss(s1, lock_door) print(flock_door 是否可行: {ok2} {reason2}) # 在门开着的状态下开门会怎样 ok3, reason3 poss(s1, open_door) print(f再次 open_door 是否可行: {ok3} {reason3})运行python situation_calculus_demo.py预期输出初始状态 {door_open: False, door_locked: False} open_door 是否可行: True 执行 open_door 后 {door_open: True, door_locked: False} lock_door 是否可行: False 门是打开的无法上锁 再次 open_door 是否可行: False 门已经是打开的这个示例虽然简单但演示了情景演算最重要的两个机制动作的前提条件检查poss函数。动作之后状态的变化execute_action返回新状态。更完整的场景中你还需要引入“框架公理”frame axioms来显式声明哪些状态没有发生变化避免在每个动作后重新计算整个世界的状态。这也是 McCarthy 当年面对“框架问题”时给出的核心思路用最小变化原则默认不动的东西就不动。在真实业务系统中这种“动作可行性 状态转移”的建模方式可以被用来处理订单状态机、权限审批流、设备控制指令校验等场景。它的好处是状态转换是完全可预测、可审计的不像直接写 if-else 那样容易在复杂分支中遗漏边界条件。9. 常见问题与排查思路在学习和使用逻辑推理相关技术时工程师最常遇到的问题往往不是理论难而是“理论与工程之间的翻译层”出了问题。下面整理几个高频问题问题现象可能原因排查方式解决方案推理结果不更新规则前件中的事实拼写不一致打印规则前件和已知事实集合对比字符串统一事实命名建立事实字典默认规则被错误触发例外条件没有正确加入事实库检查exceptions列表是否覆盖所有例外场景在规则中加入显式的优先级和例外条件动作执行不符合预期前置条件检查不完整单步调试poss函数打印状态快照为每个动作补充完整的前置条件与效应公理循环推理死循环规则之间存在循环依赖且没有去重在添加新事实前检查是否已存在设置最大迭代次数或在进入循环前检查去重知识库规模过大时性能差每次扫描所有规则复杂度高分析规则数量与事实数量引入规则索引或改用手写 forward chaining 引擎 / 图数据库与深度学习模型结合时冲突逻辑规则与模型输出矛盾对比规则输出与模型输出的置信度将规则作为硬约束模型输出作为候选假设如果你在运行前两节代码时遇到问题优先检查两个地方一是 Python 版本是否为 3.8二是是否在同一个文件目录下运行命令避免路径错误。10. 最佳实践与工程建议最后把 McCarthy 的思想落地到实际项目时有几个工程原则能显著提高成功率。10.1 先界定“常识”的范围不要试图把整个世界都形式化。企业系统中的“常识”通常是很窄的一组规则例如业务状态机、领域约束、行业规范。先定义一个最小但完整的问题边界再逐步扩展。10.2 规则与事实分离把规则、事实、推理引擎三个层次分开设计。规则由业务人员维护事实由系统运行时产生推理引擎是通用组件。这样当业务规则变化时不需要改代码。10.3 与大模型配合时逻辑层负责“硬约束”如果你正在构建一个“大模型 逻辑”的混合系统建议把逻辑推理放在大模型之前或之后而不是指望大模型自己完成逻辑推导。常见做法是先用规则引擎做事实检查和状态校验再让大模型生成自然语言回复或者先让大模型生成候选答案再用规则引擎校验。10.4 保留人工审查入口在涉及合同、医疗、法律等高风险领域逻辑推理的结果必须保留人工审核环节。McCarthy 的设想是机器具备常识但工程系统的责任边界依然要由人来界定。10.5 日志与可解释性逻辑推理的优点之一是可解释。你需要记录每一次规则匹配的完整路径哪条规则被触发、输入是什么、为什么被触发。一旦线上出现错误决策这个日志就是排查的核心依据。11. 总结与后续学习方向McCarthy 的“常识形式化”并不是一个过时的理论包袱而是一份还没有被完全兑现的技术蓝图。今天的深度学习已经解决了感知层面的很多问题而常识推理这个麦卡锡几十年前就钉在 AI 路线图上的难题现在才刚刚显示出它的紧迫性。如果你想继续深入这个方向我建议按下面的路径走手写一个更完善的前向/反向链推理器自己设计规则集合并测试。学习谓词逻辑语法与语义掌握量词、蕴含、合取、析取的标准表达。阅读 McCarthy 的原始论文重点是Programs with Common Sense和Some Philosophical Problems from the Standpoint of Artificial Intelligence。了解 RAG 与规则引擎的结合方式在真实项目中做一个最小原型。研究知识图谱、OWL 与描述逻辑理解现代语义网与 McCarthy 思想之间的传承关系。最后给一个实用建议不要试图一开始就构建一个“全知全能”的常识知识库。从一个只包含几条规则的最小系统开始先跑通推理链路再逐步增加规则。你会发现真正困难的地方不是规则的写法而是如何判断哪些知识是值得形式化的、哪些知识用统计方法处理就够了。这条边界正是未来 AI 工程中最重要的判断力之一。
