构建论证

从假设经由推理到具体证据构建严谨的论证。每个有说服力的技术主张都遵循相同的三元组：一个清晰的假设陈述你相信什么，一个论证解释为什么它成立，以及示例证明它确实成立。本技能教你将该结构应用于代码审查、设计决策、研究写作以及任何需要论证的场景。

适用场景

• 编写或审查提出技术变更的 PR 描述
• 在 ADR（架构决策记录）中论证设计决策
• 在代码审查中构建超越"我不喜欢这个"的反馈
• 编写研究论证或技术提案
• 在技术讨论中挑战或捍卫某种方法

输入

• 必需：需要论证的主张或立场
• 必需：上下文（代码审查、设计决策、研究、文档）
• 可选：受众（同行开发者、审查者、利益相关者、研究者）
• 可选：需要回应的反论点或替代立场
• 可选：可用于支持主张的证据或数据

步骤

第 1 步：制定假设

将你的主张表述为一个清晰、可证伪的假设。假设不是意见或偏好——它是一个可以用证据检验的具体断言。

1. 用一句话写出主张
2. 应用可证伪性测试：有人能用证据证明这是错的吗？
3. 窄化范围：限定在特定上下文、代码库或领域
4. 通过检查可测试的标准来区分意见

可证伪与不可证伪：

不可证伪（意见）	可证伪（假设）
"这段代码很差"	"这个函数的复杂度为 O(n^2)，而 O(n) 是可实现的"
"我们应该用 TypeScript"	"TypeScript 的类型系统将捕获导致我们最近 6 次生产事故中 4 次的空引用 bug 类别"
"API 设计更干净"	"用单个参数化端点替换 5 个端点变体将公共 API 表面减少 60%"
"这种研究方法更好"	"方法 A 在数据集 X 上以 95% 置信水平实现了比方法 B 更高的精度"

预期结果： 一个具体、有范围、可证伪的一句话假设。阅读者可以立即想象什么证据可以确认或反驳它。

失败处理： 如果假设感觉模糊，应用"我如何反驳这个？"测试。如果你无法想象反证据，该主张是意见而非假设。缩小范围或添加可衡量的标准直到它变得可测试。

第 2 步：识别论证类型

选择最能支持假设的逻辑结构。不同的主张需要不同的推理策略。

1. 审视四种论证类型：

类型	结构	最适用于
演绎	如果 A 则 B；A 为真；因此 B	形式证明、类型安全主张
归纳	在 N 个案例中观察到的模式；因此可能普遍成立	性能数据、测试结果
类比	X 在相关方面类似于 Y；Y 具有属性 P；因此 X 可能也有 P	设计决策、技术选择
证据性	证据 E 在假设 H1 下比 H2 下更可能；因此 H1 得到支持	研究发现、A/B 测试结果

2. 将假设匹配到最强的论证类型：

   • 主张某事必须为真？使用演绎
   • 主张某事基于观察倾向于为真？使用归纳
   • 主张某事基于类似先例可能有效？使用类比
   • 主张一种解释比替代方案更符合数据？使用证据性

3. 考虑组合类型以获得更强的论证（例如类比推理辅以归纳证据）

预期结果： 一个选定的论证类型（或组合），附有清晰的理由说明为何适合该假设。

失败处理： 如果没有单一类型清晰适用，假设可能需要拆分为子主张。将其分解为各自具有自然论证结构的部分。

第 3 步：构建论证

建立连接假设与其论证的逻辑链。

1. 陈述前提（你出发的事实或假设）
2. 展示逻辑连接（前提如何导向结论）
3. 钢化最强的反论点：在反驳之前以最佳形式陈述最强的反对意见
4. 用证据或推理直接回应反论点

工作示例——代码审查（演绎 + 归纳）：

假设："将验证逻辑提取到共享模块中将减少三个 API 处理程序之间的 bug 重复。"

前提：

• 三个处理程序（createUser、updateUser、deleteUser）各自实现相同的输入验证，略有变化（在 src/handlers/ 中观察到）
• 在过去 6 个月中，5 个验证 bug 中有 3 个在一个处理程序中修复但未传播到其他处理程序（见 issue #42、#57、#61）
• 共享模块强制逻辑的单一真实来源（演绎：如果只有一个实现，则只有一个修复点）

逻辑链：因为三个处理程序重复了相同的验证（前提 1），在一个中修复的 bug 在其他中被遗漏（前提 2，从 3/5 案例归纳）。共享模块意味着修复一次即适用于所有调用者（从共享模块语义演绎）。因此，提取将减少 bug 重复。

反论点（钢化版）："共享模块引入耦合——对一个处理程序验证的更改可能破坏其他处理程序。"

反驳：处理程序已经共享相同的验证意图；耦合是隐式的且更难维护。通过带参数化选项的共享模块（例如 validate(input, { requireEmail: true })）使其显式化，使耦合可见且可测试。当前的隐式重复风险更大，因为它隐藏了依赖关系。

工作示例——研究（证据性）：

假设："对于生物医学 NER，在领域特定语料库上预训练比增加通用语料库规模更能改善下游任务性能。"

前提：

• 在 PubMed（45 亿词）上预训练的 BioBERT 在 6/6 个生物医学 NER 基准上优于在通用英语（160 亿词）上预训练的 BERT-Large（Lee et al., 2020）
• 在 Semantic Scholar（31 亿词）上预训练的 SciBERT 在 SciERC 和 JNLPBA 上优于 BERT-Base，尽管预训练语料库更小
• 通用领域扩展（BERT-Base 到 BERT-Large，3 倍参数）在生物医学 NER 上的收益小于领域适配（BERT-Base 到 BioBERT，相同参数）

逻辑链：证据一致表明领域语料库选择比语料库规模对生物医学 NER 更重要（证据性：如果领域特异性比规模更重要，这些结果更为可能）。三个独立比较指向同一方向，增强了归纳论证。

反论点（钢化版）："这些结果可能无法推广到生物医学 NER 之外——生物医学具有异常专业化的词汇，这夸大了领域适配的优势。"

反驳：有效的局限性。假设专门限定于生物医学 NER。然而，在法律 NLP（Legal-BERT）和金融 NLP（FinBERT）中也出现了类似的领域适配收益，表明该模式可能推广到其他专业领域，尽管那是需要自己证据的单独主张。

预期结果： 完整的论证链，包含前提、逻辑连接、钢化的反论点和反驳。读者可以逐步跟随推理。

失败处理： 如果论证感觉薄弱，检查前提。薄弱的论证通常源于不受支持的前提，而非有缺陷的逻辑。为每个前提寻找证据或承认它是假设。如果反论点比反驳更强，假设可能需要修改。

第 4 步：提供具体示例

用可独立验证的证据支持论证。示例不是例证——它们是使论证可测试的实证基础。

1. 提供至少一个正面示例来确认假设
2. 提供至少一个边界情况或极端示例来测试极限
3. 确保每个示例可独立验证：他人可以不依赖你的解释来重现或检查
4. 对于代码主张，引用具体文件、行号或提交
5. 对于研究主张，引用具体论文、数据集或实验结果

示例选择标准：

标准	好的示例	差的示例
可独立验证	"Issue #42 显示 bug 在处理程序 A 中修复但未在 B 中修复"	"我们以前见过这类 bug"
具体	"createUser 第 47 行重新实现了与 updateUser 第 23 行相同的正则表达式"	"代码库中有重复"
有代表性	"过去 6 个月中 5 个验证 bug 中有 3 个遵循此模式"	"我曾经见过类似的 bug"
包含边界情况	"此模式对字符串输入成立，但不适用于文件上传验证，后者有处理程序特定的约束"	（未提及限制）

预期结果： 读者可以独立验证的具体示例。至少一个正面示例和一个边界情况。每个引用具体的制品（文件、行、issue、论文、数据集）。

失败处理： 如果示例难以找到，假设可能过于宽泛或未基于可观察的现实。将范围缩小到你实际能指向的内容。缺少示例是信号，不是用模糊引用掩盖的空白。

第 5 步：组装完整论证

将假设、论证和示例组合为适合上下文的格式。

1. 对于代码审查——将评论结构化为：

   [S] <建议的一句话摘要>
   
   **假设**: <你认为应该改变什么以及为什么>
   
   **论证**: <逻辑论证，包含前提>
   
   **证据**: <具体文件、行、issue 或指标>
   
   **建议**: <具体的代码修改或方法>
   

2. 对于 PR 描述——将正文结构化为：

   ## Why
   
   <假设：这解决了什么问题以及具体的改进主张>
   
   ## Approach
   
   <论证：为什么选择此方法而非替代方案>
   
   ## Evidence
   
   <示例：基准测试、bug 引用、前后对比>
   

3. 对于 ADR（架构决策记录）——使用标准 ADR 格式，将三元组映射到 Context（假设）、Decision（论证）和 Consequences（预期结果的示例/证据）

4. 对于研究写作——映射到标准结构：Introduction 陈述假设，Methods/Results 提供论证和示例，Discussion 回应反论点

5. 审查组装的论证，检查：

   • 逻辑空白（结论是否确实从前提得出？）
   • 缺失的证据（是否有不受支持的前提？）
   • 未回应的反论点（最强的反对意见是否已回答？）
   • 范围蔓延（论证是否停留在假设范围内？）

预期结果： 一个完整的、适合其上下文的格式化论证。读者可以评估假设、跟随推理、检查证据并考虑反论点——全部在一个连贯的结构中。

失败处理： 如果组装的论证感觉不连贯，假设可能过于宽泛。将其拆分为聚焦的子论证，每个都有自己的假设-论证-示例三元组。两个紧凑的论证强于一个冗长的论证。

Composition: Argumentation + Advocatus Diaboli

For high-stakes decisions, compose this skill with the advocatus-diaboli agent to form a pre-decision review loop. The pattern:

1. Structure via argumentation -- build the hypothesis-argument-example triad
2. Stress-test via advocatus-diaboli -- steelman the proposal, then challenge each assumption with specific questions. Flag severity: Critical (redesign or abandon), Medium (adjust), Low (note and proceed)
3. Revise based on findings -- critical findings trigger redesign; medium findings trigger adjustment; low findings are noted

When to compose vs. use alone:

• Use argumentation alone when constructing a proposal, PR description, or design justification
• Use advocatus-diaboli alone when reviewing someone else's existing argument
• Compose both when you are both the proposer and need adversarial self-review before committing

验证清单

• 假设是可证伪的（有人可以用证据反驳它）
• 假设限定在特定上下文，不是普遍主张
• 论证类型已识别且适合该主张
• 前提被明确陈述，而非假设为共识
• 逻辑链无空白地连接前提到结论
• 最强的反论点已被钢化并回应
• 至少一个正面示例支持假设
• 至少承认一个边界情况或局限性
• 所有示例可独立验证（提供了引用）
• 输出格式匹配上下文（代码审查、PR、ADR、研究）
• 无逻辑谬误（诉诸权威、虚假二分法、稻草人）

常见问题

• 将意见表述为假设："这段代码很乱"是偏好，不是假设。改写为可测试的主张："该模块有 4 个职责应该按单一职责原则分离，其 6 个公共方法跨越 3 个不相关领域可证明这点。"
• 跳过反论点：未回应的反对意见会削弱论证，即使读者从未提出。始终钢化——在反驳之前以最佳形式陈述最强的反对意见
• 模糊的示例："我们以前见过这种模式"不是证据。指向具体的 issue、提交、行、论文或数据集。如果找不到具体示例，你的假设可能基础不牢
• 诉诸权威："高级工程师这样说了"或"Google 这样做"不是逻辑论证。权威可以激发调查，但论证必须凭自身的证据和推理站住脚
• 结论中的范围蔓延：得出比证据支持更广泛的结论。如果你的示例涵盖 3 个 API 处理程序，不要对整个代码库下结论。将结论范围与证据范围匹配
• 混淆论证类型：对演绎主张（"必须"）使用归纳语言（"倾向于"），反之亦然。精确表述结论的强度——演绎论证给出确定性，归纳论证给出概率

相关技能

• review-pull-request — 将论证应用于结构化的代码审查反馈
• review-research — 在研究上下文中构建基于证据的论证
• review-software-architecture — 使用假设-论证-示例三元组论证架构决策
• create-skill — 技能本身是关于如何完成任务的结构化论证
• write-claude-md — 记录受益于清晰论证的惯例和决策