编辑导语：初级产品经理在工作过程中，可能会遇到许多问题。本篇文章中作者结合自身经验，从六个方面叙述了产品经理应该如何提升产品能力。感兴趣的小伙伴们快来一起看看吧，希望对你有所帮助。

产品经理容易有这样一个现象：看过很多的产品文章，学过一些产品课程，了解很多高大上的模型理论，每天关注互联网资讯，你跟他聊天的时候发现他什么都懂一点，但一上手就是不出活，暴露各种基本功不扎实的问题。

为什么看了那么多大咖的分享总结、方法论的文章，依然做不好需求？

结合我自己的经历，我把原因总结为两方面。

一方面，看的文章写的内容泛泛而谈不够干货，或者说通用性不强，仅适用于作者自己的项目和工作，难以进行学习模仿。

另一方面是你只是略读一遍，像看新闻一样，没有深入理解其中的精华，在实践的时候也没有运用上。

本文的主要内容是初级产品经理工作过程中各环节的技巧总结，我写的时候尽量是从现有工作内容中抽离，没有涉及到我的具体业务，因此不同细分领域的产品经理都可以通用。

为了区分什么是技巧、技能、能力，我这里做了如下定义：

技巧：是为了快速提升技能的手段，是技能的一部分，是可以学习复制的

技能：是具体的、全面的，是为了做好一项工作而需要具备的内容，是可以学习复制的

能力：是技能内化后的结果，是举一反三的驱动力，很难复制，需要靠自己总结提炼

由此可见，要提升产品能力，可以先从学习技巧开始，再掌握全面的技能，最后提炼出通用的能力，如此循序渐进。

一、初级产品经理必备素质

处在职场的不同阶段，聚焦点是不一样的。作为初级产品经理，需要明确自己的定位和目标，练好基本功，切勿好高骛远。

初级产品经理一般完整的负责一个功能模块或一个系统，首先，需要对自己负责的模块充分的熟悉然后了如指掌，让所有需要跟这个功能对接的人知道，有问题只要找你就解决了，这也是逐步建立影响力的过程；

其次，熟悉了模块之后，再深入思考该模块不同竞品做的怎么样，自己产品所在哪个档次，距离最好的产品差距有多少，如何基于公司的业务提高该模块的竞争力；

最后，在掌握了自己负责的内容后，以点带面，不断完善加深对公司产品和业务的理解，才能获得更多机会承担更重大的项目。

以上三个过程是一个递进的关系，也是初级产品经理在不同工作阶段的不同定位。

对于刚工作的前两年，对于个人能力的提升目标方面，应该着重关注执行力、沟通力、项目管理能力三大块，其中执行力包含了需求分析、产品设计、推进项目开始到上线过程的方方面面，这三大块内容是作为产品经理最基本的基本功。

产品经理对需求的管理就像厨师对食材的管理，厨师在众多食材中挑选合理的组合，加工成美味，产品经理在众多业务方提出的需求中进行组合设计，加工成产品功能。

好的需求池管理不仅是对需求进行过滤，也是对工作内容的精细化记录和总结，有利于有条不紊的项目管理和后期的复盘。我将对需求池的管理内容总结为三大部分：

判断并记录需求的真伪、重要性、紧急度、实现难度、业务价值、关联方

记录当前每个需求的项目实现状态

追踪需求实现后的用户及数据反馈情况

至于需求池的表格模板，我认为每个人的实际需求和习惯不同，也没有必要照搬别人的，只要覆盖了以上三大块内容，起到了需求池管理的作用即可。

一般刚入行的初级产品常常直接执行领导分配的任务，但并不代表优先级判断这件事对于初级产品不重要。需求优先级判断这个话题，网上一搜产品文章一大堆，各种四象限法、卡诺模型等等。

但每个人处于工作不同的时间状态，对公司及行业产品的理解层次是不一样的，所以就算你学完了背熟了产品课程中所有的需求分析方法论、或者优先级判断模型，你的判断的合理程度很难跟你的领导相比。

优先级判断属于洞察决策层面的高级能力，不是工作技巧，它的变量太多，需要多方权衡，比如业务重要程度、紧急程度、工作量、性价比、是否匹配系统当前所处的阶段、对系统的影响大小，甚至领导强势程度等等，不同行业不同公司情况，用一套模型和公式是无法解决的。

我这里想强调的是，不必拘泥于具体的判断方法和公式，而是一开始就养成对自己需求池进行优先级判断的习惯，也许一开始判断的结果并不准确，会踩过一些坑，但随着对业务和行业的逐渐熟悉，判断会越来越准确。

所以我建议忘掉别人总结的公式，建立自己的判断标准，并不断调整优化这个标准。

我将产品规划设计粗暴的分为前端页面设计和后端产品设计，这里的后端其实不是真正意义的后端产品经理才关注的，也会包含很多前端功能逻辑层面的设计。

凡是属于用户可见可操作界面的部分为前端设计，不可见的逻辑及系统设计则为后端设计。

交互设计领域人机交互大师雅各布·尼尔森博士，在1995年提出的尼尔森十大可用性原则，对二十多年后今天的互联网产品设计仍然影响深远。

对于软件类着重页面设计的互联网产品来说，我提炼了其中4点：

包括了文案的简洁明了、功能玩法的易理解，在单个页面内减少过多不必要的信息。

当用户进行某个操作后，以合理的形式向用户反馈目前的状态，可能会发生什么。

用户走的每一条路都不能是死胡同，应该都能让他回到原点。

不同位置的相同功能保持一致，保证了产品设计统一，用户更易学习。

前端设计我只总结了以上4点，比较适用于产品原型的交互设计，但却是任何一个优秀的产品必不可少的核心设计原则。

后端设计的细节太多，没法像前端设计原则一样进行高度归纳，我这里也是根据自己大大小小的项目经验逐条进行总结，内容不够系统，可以当做几个关键点设计的参考。

（1）MECE原则，相互独立，完全穷尽

这个基本原则相信每个产品经理都知道，它是一个能让产品方案条理有序、不遗漏、不重复的重要标准。我这里主要强调一下它具体体现在了什么方面。

产品方案对标业务需求：

我们假设这里的业务需求都是相对合理的需要实现的。那设计的产品方案需要对应满足这些业务需求，不能遗漏任何一个，同时也不能让产品方案内部出现重叠的功能，而是刚好完美的满足了业务需求，也使开发的系统内部达到软件工程上的最优解，这就叫满足MECE原则。

落实到具体的执行，需求文档中描述功能时也需要尽量满足这个原则。首先做到描述不遗漏，充分考虑异常流、特殊逻辑；然后需要语言精简客观，对同一功能和模块不必重复赘述，对于有耦合关系的模块，用语言上的逻辑因果、时间先后来进行描述。

（2）强化对状态的认知

对于一个后台系统，状态无处不在，灵活多变的业务需求是靠一张张数据库的表在记录的，除了业务数据的记录，状态是非常重要的基础。

订单必须有状态，用于区分不同业务环节；一个上线的活动必须要有状态，是进行中、已暂停、还是已下线；一个员工账号也要有状态，是启用中、禁用中还是已注销。

设计一个功能或系统通常需要先绘制流程图，而流程图中一个个状态的连接支撑起了整个功能设计的骨架，然后才是具体细节的设计。

如何正确的强化对状态的认知和理解，我大概总结以下几点：

这点与上面说的唯一判断字段有点类似，但实际不是一回事。因为状态是用于描述不同业务节点的，每个状态要与实际业务的关键节点进行一一对应，状态之间不能出现二义性，否则会出现多个状态对应同一个业务关键节点，不但会造成理解混淆，还可能使系统做具体判断时出问题。

状态在时间维度上是稳定的：

这点其实也很好理解，一个具体业务的发展是有阶段性的，而状态就是在每个阶段取一个值，各个值连接起来就串联的业务，但如果状态的值取在各个阶段的临界点，这就很不好描述业务了。

比如一个运营活动，可以用"进行中"和"已下线"两个状态来区分发生和不发生两个阶段，这是合理的，但如果状态叫做"下线中"，这就不是处在一个稳定的状态，而像一个瞬时态，到底是上线还是下线，我们从状态命名中就感觉很模糊。

注意子状态和组合状态：

当业务相当复杂时，一个状态下面还可以设置子状态，比如单据的撤销状态，可以包括用户主动撤销、系统撤销、人工撤销，用于区分具体是怎么被撤销的。

而组合状态的意思是在用户侧展示的状态不单是订单表里存的状态名称，而是一个组合状态，比如在用户侧显示"已发货"，其实包含了订单状态为"创建成功"、支付状态为"已付款"、物流状态为"已出库"。

像比较复杂的保险订单状态，还会包含订单状态、支付状态、续保状态等，因此不能用一维的线性的来看待状态。

状态机图的确定，基本确定了系统和功能主体结构，各状态之间的起点终点、流转路线、判断条件决定了功能的玩法和限制，状态机图是梳理并对照实际业务的必备工具。

当业务有功能拓展时，首先查看状态机图是否满足，如何调整才能满足，已经涉及到哪些相关调整，都需要用到这个图。

合理的状态有利于数据统计：

当状态的设计都按照上述原则进行，状态与状态之间非常清晰，这对数据统计是非常有益的，因为很多的数据统计都强依赖对状态的定义，如果你在做数据统计的时候发现很难准确的提需求，或者发现无法按照业务需要的维度来进行统计，可以反思下系统的状态是否合理。

我之前经常遇到一种情况，当我做一个功能上线之后，业务方有时会再提一个与这个非常类似的需求，有时候仅仅只是改动很少的内容。

如果在第一次设计时并没有预留可能的拓展性，就算只是很少的改动，还是要排期开发和测试，特别是有的功能还需回归测试，非常浪费开发资源，而且影响迭代速度。

这时就考验在设计之初能否大概看出可能有的拓展性，在开发工作量几乎不变的情况下预留一些类似的逻辑，这样会非常便于类似功能的迭代。

举个例子，对于一个人工审核的结论页，有多种状态，每种状态下结论页的不同模块的元素、文案、以及对用户的触达文案，都是首次开发时配置好的。

首次开发时业务方提出有三种状态，上线之后业务方说要再加一种特殊的状态，如果事先在状态机中预留了待定的状态，只需要把该待定状态下页面的元素、文案、对用户的触达进行设置即可，改动的工作量很小，可以快速的上线。

不过值得注意的一点是，在预留拓展性时尽量保证首次开发的工作量影响很小，如果为了暂时使用不到的预留需求消耗过多开发资源，就有点本末倒置了。

最好的针对复制一份代码、预留一个状态这种相似功能进行考虑。

对变量的抽象是一种模块化思维，能够减少很多重复的工作量，提高后期的开发效率，我将分成两种情况来描述。

一种是当多个页面都用到同一个内容时，该内容应该被抽象为公共变量，供各页面调用。

比如一个常用联系人组件包含姓名、证件类型、证件号码、性别、出生日期这五要素，那么可以把这五要素设置成一个公共变量模块，在不同产品下单需要用到时直接调用即可。

如果有的产品下单时只需要用到姓名、证件类型、证件号码三要素，则可以把五要素的变量模块拆细为五个变量元素，这样可以达到最大自由度的组合。

另一种情况是两个页面绝大部分内容相同，只有几个元素有差异时，这几个有差异的元素应该抽象为配置变量，做成一个配置文件或者管理后台，这样在调整该配置时就不用再写代码。

有的同学可能对配置文件不太懂，它可以理解为一段未被编译器编译的配置代码，是对一个软件运行时状态的本地储存形式，可以实现对软件灵活的实时调整。

比如同样一个商品的详情页需要在A平台是红色背景，有评论模块，在B平台是绿色背景，不要评论模块。

如果事先将背景色、有无评论模块这两个变量做成配置项，只需要更改配置文件或在管理后台做相应勾选即可。

5. 时刻考虑系统的灵活性

讲完两种基本的变量抽象方式，我再讲讲整个系统的灵活性。

比如一个普通的商品详情页，如果只给你1天时间从0到1来做这个页面，你会把页面的所有元素、逻辑写清楚，找到前端后端开发按照你的逻辑进行实现，然后发布上线。

如果你想修改一个banner图，必须要找前端开发从代码层面帮你换图，然后再发布，这时我们认为这个页面是非常不灵活的。

因此你把banner、标签、价格、尺码分类等等都抽象成了配置变量，就可以在管理后台灵活的调整这些内容，无需再发布，看起来非常灵活了。

但是当这个页面需要对不同商家显示不同商品时，你就需要再把这整个页面做成配置项，对每一个商家可以单独配置一套商品详情页。

接下来业务需求再进一步演化，每个商家想要自己去配置自己的商品详情页，这时你还需要把商品详情页的配置功能做成一个商家管理后台，让商家自己去灵活设置，这时候单是这个商品详情页就已经很复杂了。

如果每个商家还要对自己的员工分别配置权限，有的员工只能修改banner图和名称，有的员工可以修改商品sku、价格等等，那你还需要把这个商家的商品详情页配置功能结合账号权限再细分配置，让商家自己灵活勾选什么员工可以操作什么权限。

我这里只是简单的描述了一下电商平台商品详情页的配置演化路径，就可以看出，当业务需求越来越细化，对系统灵活性的要求就越来越高，也意味着系统的复杂程度越来越高。

为了尽可能充分的满足业务需求，我们需要时刻注意系统的灵活性，在每一版迭代的时候避免太多写死的逻辑。

6. 总结遇到的异常流

每做一个项目，在上线之后可能都会遇到反馈的线上问题，特别是一些在设计时考虑不全的异常逻辑，会在用户真正使用的时候暴露出来。

做完项目遇到这种情况并不可怕，因为人无完人，产品经理不是神，设计之初漏掉一些异常流是很正常的，但如果每次项目都漏掉一些，或者同样的异常问题多次出现，这就是产品经理的问题了。

我们可以认为，在业务拓展没那么快的情况下，软件层面的设计的异常流是很有限的，只要遇到一个就把它解决掉，总会消灭干净的。

产品经理每天的工作时间，可能会有一部分都是在处理自己留下的坑，但在填坑的时候我们能否不仅仅只为了填坑，能否思考是怎么漏掉这些异常流的，并一一总结出来，这样也许能大大提升产品设计的完整性。

项目管理之前应该先判断该项目的类型，不同的项目推进和管理的方式区别很大，根据项目大小与任务并行程度，我分为以下三类：

1. 周期较长的大项目管理

对于单个部门内部开发周期较长的项目（超过2周），我总结有以下项目管理的关键点：

（1）提前沟通开发方案

一般较大项目功能比较复杂，因此整体方案设计时需要预先跟开发人员沟通，明确一些关键限制因素和影响点，避免需求评审时方案不可行，或者调整太大，在评审会上难以达成一致。

（2）关注功能先后顺序

提前关注项目中不同功能的相互依赖性以及对外部系统依赖性，根据功能依赖的先后顺序确定项目的排期节奏，提高排期衔接程度，避免一个功能开发完很久之后还不能与其他功能联调，浪费开发资源。

（3）对项目的强推动力

每日跟进关键点的结果，尽早发现风险（日报、周报、晨会等形式）。

项目完成后回顾项目过程中哪些过程效率有待提高、哪些过程安排的不够合理，如何避免在下一个项目中继续出现。

2. 跨部门跨公司合作的项目管理

跨部门和跨公司合作的项目，开发量不一定很大，但由于牵连方较多，比起团队内开发有了更多的不确定因素，项目容易延期，因此在上述大项目的管理基础上需要额外关注这几点：

不管是跨部门还是跨公司合作，首先要明确对双方的关键利益点，并强调合作对对方的好处，才能获得对方的积极支持，否则很容易被踢皮球。

（2）书面确认详细事项

跨部门和跨公司合作，一般都是远程电话沟通，因此对会议上达成一致的点需要书面记录邮件至对方，对达成一致的点也需要记录并积极跟进对方的最新答复。

这一点主要是为了提高需求的确定性，明确双方职责，避免因为沟通没有记录影响项目开发进度。

3. 多个小项目并行的项目管理

对于互联网的敏捷开发模式，超过两三周的大项目少有，多个小项目并行才是更常见的状态，这里的小项目其实是单个很明确的需求，粒度比较小，这种状态下产品经理一周可能同时在跟进十多个需求在开发状态，这对多项目并行的考验很大，我总结了以下几点：

（1）更合理的排期节奏

由于项目太多，为了避免同一天过多需求同时在开发或者在测试，在排期的时候尽量均匀的分布，这样保证在一些需求已经进入测试或已发布，另外的项目刚进入开发，避免某一天的事情太多。

（2）每日tips跟进每个项目的状态

首先需要实时记录这些并行的需求的开发状态、开发人员，然后每天早晚跟对应的开发人员跟进需求状态，及时解决相关问题。

小需求上线一时爽，后期维护痛苦不已。每个小需求在开发过程中是独立的，但对于整个产品来说它是一个个的迭代，只有及时将这些迭代归档到对应的功能模块，才能后续方便的了解查询当前线上的产品规则是怎样的。否则后期连自己都忘了到底最新的迭代是什么，这个坑谁踩过谁就知道有多苦。

与项目管理类似，沟通之前我们要对沟通的对象进行分类，不同沟通对象需要注意的事项是不一样的。

（1）沟通方式的合理选择

一般与合作方很难面对面沟通，大多是电话和在线沟通，因此对于不同的事项要选择合适的沟通方式。

比如首次确认合作内容，需要电话详细说明合作细节，然后书面记录达成共识的事项；确认完合作内容后，有小的疑问点可以在线沟通。

有依赖合作方确认的事项或开发进度时，催进度是最频繁的事。但是催进度需要包含几个关键因素才能起到好的效果。

首先是良好的态度，对对方的尊称是必须的，就算对方态度比较冷淡也需要保持着热脸贴冷屁股的热情，因为在工作中，合作的顺利完成才是最重要的，这也是职场人的必备素质。

其次是明确具体内容和时间点，比如当希望对方对某个点反馈结果时，反面教材是这样的"请问你们这个功能可以快一点开发吗？"、"麻烦尽快确认下XXX这个点哦"，这样的询问都没有明确时间点，对方感受不到压力，催进度的效果不明显。

正确的方式是"请问某某负责人，针对这个三点事项（一一列举），您可以在今天下午5点之前确认吗，麻烦您了"。

再次是要找对关键人确认，比如你一直跟对方的一个开发人员催进度没什么用，需要直接找到对方的产品或项目负责人，甚至是对方领导。

（1）搞清需求方的本质诉求

需求方可能是运营、销售、客服，他们会根据自己当前遇到的问题直接跟产品经理提需求。

大家都知道快马和汽车的故事，需求方需要一匹快马，我们是直接按他说的给他快马，还是思考他提出这个需求的本质诉求是什么，能否转化成另一个需求，是否还有更合理的解决方案？

如果来一个需求就做一个，缺乏对需求背后的思考，这不叫产品经理，叫需求实现师。

（2）明确产品和需求方的边界

当与需求方长期合作时，需要形成一个良好的沟通模式，明确各自的职责范围和边界。

比如与运营合作上线一个项目，哪些内容是运营需要明确的，哪些内容是产品可以有施展空间的，这个过程中，产品不能随意修改运营确认的规则，但也不能放任需求的不断变化，不能让运营直接干涉产品系统层面的影响。

优雅的把握好边界，相互尊重彼此的工作内容，能够减少很多扯皮，让合作效率更高。

对于初级产品经理偏重于项目执行，日常沟通的对象最多的一定是开发人员，如果沟通太少，要么是你需求文档完美无缺（几乎不可能），要么是你不够主动。

（1）跟开发大佬和开发小弟沟通的区别

开发大佬就是某条线的技术负责人，在有重大功能迭代的时候，可能会需要先跟他对方案。

与开发大佬沟通时最好是提前想好靠谱的方案，而不是偏差太大的天马行空，这样避免浪费双方时间，也能提高大佬对你的信任。

开发小弟就是除了大佬之外的开发同学，与他们沟通的核心技巧是要建立利益共同体，因为他们是具体做需求的人，你需要把需求的背景、实现后的价值讲给他们，以及上线之后的效果也要多同步给他们，提高他们的自豪感。

开发小弟也需要成功的项目来体现自己的价值，让他们感受到你们是一条线上，他们也会尽心尽力帮助把系统做的更好，开发过程中改点小需求也就不在话下了。

当然，这些技巧是要建立在需求文档质量合格的前提下。

产品立项时、项目开发过程中，对开发人员的预期管理是很有必要的。

有的开发觉得这个项目不是很重要，重视程度不够，最后导致延期；

有的开发对这个功能上线期待很高，最后上线后效果并不理想；

有的开发在立项时认为这个项目开发这些功能需要2周，但中途你又加了几个小需求导致开发时间压缩，开发人员非常不满。

这些都是实际的情况与开发人员预期情况产生较大不一致造成的。因此一些关键的事项，需要跟开发人员预期保持一致，我主要总结以下几点：

比如一个非常重要的项目，需要在2周内上线，预计可以获取新增用户10万个，这些明确的项目目标和价值需要在立项时及时同步给开发人员，有时候你的重视程度会影响开发的投入程度。

开发时间、转测时间、上线时间，几个关键的节点要时刻强调，建议直接写在项目群公告中，避免有的开发同学遗漏忽略。

项目可能产生的风险和备用解决办法，在立项时也应该跟开发同学保持同步，一些外部的不可控因素可能会产生什么影响。

比如一个项目可能临时更换合作方这种突发事项，提前同步可以让大家心里都有底，不至于发生时产生太多不利于合作的情绪。

（3）跟开发的工作氛围建设

除了工作中，工作之余与开发同学经常一起玩，开开玩笑，建立良好的工作氛围和私人关系也很有必要，会让工作的合作效率更高。

也许一个小需求对于关系一般太严肃的开发来说需要排期才能处理，但关系融洽的开发可能随手就帮你解决了。

1. 建立自己的能力模型

产品经理从第一天开始工作起，基于自己的工作内容和所在领域，就可以开始规划自己的能力模型，并不断的完善，这样一个能力模型既与工作内容相关，又是独立于当前的工作内容，是抽象出来的通用的能力模型，这样才能保证自己在产品经理这个岗位中的竞争力。

关于如何建立自己的能力模型，可直接查看我的这篇文章。

2. 注重思维方式的迭代

根据我个人建立的产品能力模型，相比于各种经验技巧方法论，我认为最底层的是思维方式，优秀的思维方式可以让你在面对不同工作内容时举一反三。

而产品经理到底要具备哪些思维方式？

这个问题我建议你也不要看别人直接输出的结论文章，我给出两点建议：

阅读经典的评分高的思维方式书籍，相比于产品同行写的产品思维的文章，优秀的思维方式书籍的含金量更高且内容更系统，更有利于对思维方式的学习。如《思考，快与慢》、《穷查理宝典》、《用理工科思维理解世界》。

根据自己实际的工作经历，复盘做得不好的项目各个环节欠缺哪些思考，回头看如何思考可以做得更好。而对于做得好的项目又是怎么思考的。以此进行演绎，形成自己认为重要的思维方式。

本文由 @拾二 原创发布于人人都是产品经理。未经许可，禁止转载。

文章约5600字，阅读约需要6-8分钟

温馨提示：本篇文章可能需要仔细、分节、多次、反复阅读，请大家做好心理准备。

第三节：四种直言命题；

可根据学习水平自行跳转相应部分。

在网上冲浪的愉快之旅中，我们总能碰到各式各样的观点：或鞭辟入里，或温暖坚定，或整个好活儿。在这些观点中，我们往往倾向于认同一些观点，否定另一些观点。这不仅能让我们在思考中加深自己对这一问题的理解，构筑自己的观点，也能让我们获得情感支持。

从这一角度看，无论某一观点是在事实、认知或情感等方式是多么不合理或不可接受，它的存在本身就有意义。但这是否能说明，我们可以随意地提出并使用任意观点呢？

让我们来设想这样一种情况：在某一群体中，人们可以自由发表看法，也可以对别人的观点表示赞同或反对，并采取“少数服从多数”的原则进行重大事件决议。这个群体的未来会是怎样的？

由于缺乏判断观点的客观标准，人们之间的沟通交流变成了“巧了，你也是这么想的”的结缘活动，我们不能保证每一个被广泛认同的观点都对群体有益。整个群体的未来就极度的不确定了。那有什么办法能得到一个正确，或者说是在某个角度上是正确的观点呢？

值得庆幸的是，办法总归是有的！只是需要智商。我们需要引入一对概念：“真”与“假”。引入这一对概念后，我们至少在使用观点时拥有了客观判断的工具。

显然，与客观事实不符的观点，我们往往认为它是假的。但有大量的观点是不能通过观察客观事实直接得出的：如，明年今天会下雨。（时间限制导致的无法得知）美国的空气是甜的。（空间限制导致的无法得知）神是存在的。（概念本身难以得知）我们需要大量利用推理来进行论证。

例如，因为空气几乎不可能是甜的，所以美国的空气几乎不可能是甜的。（但在1919年的波士顿北部，空气的确香甜）我们需要一种帮助我们进行判断的艺术，就如同上面的例子一般。

让我们来认识一下推理的艺术吧！还记得我们上文提到的智商吗？现在就要开始使用它了！别担心，毕竟我也没有。

首先，让我们认识命题。任何一个命题都断定了事情是什么样的。

这些都是命题。我们可以肯定或否定一个命题，但任何命题都断定了某件事物是什么样的，或者不是什么样的。而这些断定总是与客观事实相符或相悖的，所以每一个命题都要么是真的，要么是假的，不存在既真又假的命题。

当然，有些命题的真假是难以确定的。比如，就我们目前的知识，“有外星人存在”这个命题，它的真假就是未知的。但这个命题和其它命题一样，要么是真的，要么是假的，不可能是既真又假的。

显而易见，问题、命令和感叹虽然都是句子，但都不可能是命题。比如：“看到这里了，你头疼吗？”、“搞快点！”、“我的麻鸭！”都没有断定任何东西，都是非真非假的。

紧接着，让我们认识一下四种直言命题。

直言命题也被称作性质命题，是断定对象具有或不具有某种性质的命题。以下几个命题都是直言命题。

①APC联盟是很棒的科普组织。

④有的学生不喜欢学形式逻辑。

直言命题是以主谓式语句表达的，由量项、主项、联项、谓项四个部分组成。

主项是指明断定对象的项。在上面的命题中，“APC联盟”、“狗”、“苹果”、“学生”都是主项。它们通常都长得很像语法概念中的主语。

谓项是描述对象性质的项。在上面的命题中，“很棒的科普组织”、“人”、“被做成Bad Apple!!”、“学形式逻辑”都是谓项。它们通常都长得很像语法概念中的谓语。

联项是联接主项和谓项的词。在上面的命题中，表示“具有”和“不具有”的差别，决定了一个命题是肯定命题还是否定命题。肯定命题的联项通常用“是”这个判断词，否定命题的联项通常用“不是”这个判断词。上文说到，一个命题要么断定了事物具有某种性质，是肯定的；要么断定了事物不具有某种性质，是否定的。所以每个命题都有联项，而且联项必须是要么肯定的，要么否定的，不能既肯定又否定。在上面的命题中，①和③中含有肯定的联项“是”，②和④中含有否定的联项“不是”。

量项是表示主项被断定的范围的项。主项的范围被全部断定的量项叫全称量项，通常用“所有”、“全部”、“任何一个”等表示。全称量项可以被省略，比如将命题②表述为“狗不是人”也说得通。主项的范围被部分断定的量项叫特称量项，也叫存在量项，通常用“有的”、“部分”、“其中一些”等来表示。需要注意的是，特称量项不可以省略。命题③和④中的“有的”绝对不能被删去，否则就改变了命题的含义。含有全称量项的命题被称为全称命题，含有特称量项的命题被称为特称命题。在这里要特别明确一点，特称量项“有的”的确切含义应被理解成“至少存在一个”，而不是“有一些而且只有一些”。比如，在命题④中，不喜欢学习逻辑学的学生数量是没有上限的（或者说，这个数量至多可以是全部）。可能全体学生都不喜欢学形式逻辑，但我们仍然可以描述成“有的学生不喜欢学形式逻辑”。命题④并不断定“有的学生不喜欢学形式逻辑”。

了解完量项、主项、联项、谓项，我们很容易的发现：主项和谓项的位置上可以任意填充不同的内容，而量项的位置上只能填“所有”或“有的”，联项的位置上只能填“是”或“否”。所以，我们把主项和谓项称作直言命题的变项，把量项和联项称作直言命题的常项。

所以，为了减少我们死掉的脑细胞，为了让我们更好地研究这些直言命题，我们选择了一些更简单的方式——符号化。

我们发现，两个变项（主项和谓项）的内容往往千变万化，而两个常项（量项和联项）两两配对只有2×2＝4种情况。那么，为什么不把量项和联项的不同组合作为我们描述一个直言命题的重点呢？

而且，我们也观察到，任意一个直言命题的形式总是这样的：

（量项）+主项+（联项）+谓项

在任意一个直言命题中，四个部分缺一不可。“（）”仅表示在上文叙述的部分情况中，它们可以在日常用语中省略。比如，将日常语句“人都会长大”省略的项补全，就是“所有的人都是会长大的”。

综上，我们用S和P来表示主项和谓项，用A、E、I、O来表示量项和联项之间不同的组合情况。可表示为：

SAP——全称肯定命题（所有……是……）

SEP——全称否定命题（所有……不是……）

SIP——特称肯定命题（有的……是……）

SOP——特称否定命题（有的……不是……）

上文中的命题①、②、③、④刚好分别是SAP、SEP、SIP、SOP的形式。请大家一定要记住它们。

（重要的事情要说三遍，所以第四行被删掉了）

好了，大家记住了吗？让我们开启下面的愉快冒险吧！

千呼万唤始出来！欢迎来到三段论的世界！

相信大家总能看到这种形式的推理：

我们一起来观察这一推理。

在这组直言命题中，有两个直言命题位于分割线上面，有一个直言命题位于分割线下面。由上面两个命题推理出了下面两个命题。有三个词（猫猫、人、皮蛋）出现在这一组直言命题里，分别出现了两次。

我们把这种形式的推理称为直言三段论。它通常由三个直言命题组成：包括两个直言命题作为前提，一个直言命题作为结论。其中，有且只有三个词出现在其中，每个词在其构成命题中恰好出现两次。

要得到更加准确的分析，这样的推理就必须以标准形式出现。（脑容量友好协议）直言三段论的标准形式必须满足以下两个条件：

a. 其前提和结论必须都是标准直言命题（A、E、I、O）

b. 这些命题必须以特殊的顺序出现。（前提——结论，后文会有更详细的补充）

与我们划定直言命题的四个部分（主项、谓项、量项、联项）类似，我们可以对直言三段论的三个词作出命名。以例子中的直言三段论Ⅰ为例，我们发现它包含了三个词：人、猫猫、皮蛋。

要通过名称指认出这三个词，我们一般先观察结论。直言三段论Ⅰ的结论是一个O命题（SOP）：“有人不是猫猫。”结论的主项（人）被称为直言三段论的小项，结论的谓项（猫猫）被称为直言三段论的大项。在结论中不出现，而在前提中出现两次的项（皮蛋），即直言三段论的第三个项，被称为中项。

直言三段论的前提也有名称，它们因其中出现的项而得名。大项和小项必须出现在不同的命题中，包含大项的前提被称为大前提。直言三段论Ⅰ中，“猫猫”是大项，所以包含“猫猫”的前提——“没有猫猫喜欢吃皮蛋”——是大前提。

包含小项的前提被称为小前提。直言三段论Ⅰ中，“人”是小项，所以包含“人”的前提——“有人喜欢吃皮蛋”——是小前提。

需要注意的是，这两个命题称为大前提或小前提，并不是因为它们出现的顺序，而是因为它们包含的是大项还是小项。无论这两个前提以何种顺序排列，含大项的前提都是大前提，反之亦然。

如果一个三段论的前提以标准形式排列，就称其为直言三段论的标准形式。还记得上文提到的“直言三段论的标准形式的条件b”吗（希望你不会被绕晕，毕竟下文还有更晕的）？现在我们就来正式描述这个标准顺序：

在标准式直言三段论中，大前提处在第一位，小前提处在第二位，结论在最后。是的，你没有看错，就是这么简单！请牢牢记住它！

接下来，我们来讨论直言三段论的式与格。（放松下大脑再开始吧，凡人！）

每个直言三段论都有一个式。三段论的式由其所含标准直言命题而定（以A、E、I、O为标志）。每个三段论的式都由三个按特定顺序排列的字母组成。第一个字母指的是大前提的类型，第二个字母指的是小前提的类型，第三个字母指的是结论的类型。如，在直言三段论Ⅰ中，大前提（“没有猫猫喜欢吃皮蛋”）是一个E命题（SEP形式），小前提（“有人喜欢吃皮蛋”）是一个I命题（SIP形式），结论（“有人不是猫猫”）是一个O命题（SOP形式）。所以，这个直言三段论的式就是EIO式的。我们可以列举出4×4×4＝64种不同式的直言三段论。

只有式，我们还不能完全刻画标准直言三段论的形式。这一点可以通过比较两个有相同的式的直言三段论表明，它们在逻辑上天差地别。

所有干饭人是快乐的人。

所以，有的学生是快乐的人。

两者都是AII式，但直言三段论Ⅱ是无效的，直言三段论Ⅲ是有效的。我们如果能展示出它们的“骨架”，就能十分清晰地揭示出其形式上的不同之处。把小项记为S，大项记为P，中项记为M，“所以”记为“∴”，我们得到了这样两个直言三段论的“骨架”：

两者很不同。在直言三段论Ⅱ中，中项在两个前提中都作谓项；在直言三段论Ⅲ中，中项在两个前提中都作主项。直言三段论Ⅲ被视为有效论证，而直言三段论Ⅱ无效。

这个两个例子表明，尽管直言三段论的形式可以部分地用式来描述（两个例子都是AII式），但相同式的直言三段论在形式上还有其它的重要区别，这就需要关注中项的相对位置。为了完整地描述直言三段论的形式，我们不仅需要写出它的式（代表其三个命题的三个字母），还需要写出它的格——中项在前提中的位置。

直言三段论有且只有四种不同的格：

1. 中项在大前提中作主项，在小前提中作谓项；

2. 中项在两个前提中都作谓项；

3. 中项在两个前提中都作主项；

4. 中项在大前提中作谓项，在小前提中作主项。

中项的这些可能组合分别构成了直言三段论的第一、二、三、四格。任何一个直言三段论都有且只有这四种格中的一种。为了便于记忆（请先确认一下自己的大脑温度，避免烧坏），我们将优化这四种格的呈现方式。下面的组合中，只显示了中项的相对位置，而隐藏了它们的式，量项和联项也都没有显示。

至此，只要指明标准直言三段论的式与格，就能完整地描述它的形式。我们以直言三段论Ⅰ为例，它属于第二格，因为它的中项“皮蛋”是两个前提的谓项。它的式，则是上文指出的EIO式。所以，这个标准直言三段论应该被完整描述为EIO-2形式。这是一个有效的三段论。

我们在上文中已经计算出，直言三段论会有64种不同的式，而直言三段论又有四种不同的格，所以标准式的直言三段论就必然有64×4=256种形式。

但正如我们所看到的，这其中绝大部分形式是无效的，只有15个形式在任何情况下都有效。

尤其要牢记的是：只有作前提的两个直言命题都是真的，直言三段论的形式也是有效的，结论才必然是真的。

如，人教版高中语文必修四（实验教科书，即老教材）在《逻辑与语文学习》这一单元中，在介绍推理的时候，将“人非圣贤，孰能无过？”解释为一个省略了的直言三段论，并将它还原为：

所以，我们不是不会有过错的（我们都是会出错的）。

其实，这是一个大前提错误且形式无效的三段论。“圣贤是不会有过错的”不符合历史事实和常识——古往今来的任何圣贤都犯过错；这个三段论属于AOO-1形式，形式本身无效。

我们的传统形式逻辑之旅圆满结束！希望大家以后看到与自己相同或不同的观点后，不再站队，多多运用本文试图阐明的一些基本方法加以判断、思考（而不是站队或对线）。

而这，也正是推理的艺术——证明论证是合理的。

（好了，我要去喝点冰阔乐了，给自己的大脑降降温QAQ）

1. 本文为快进到三段论的有效形式，省略了大量传统形式逻辑的内容。这些重要的内容主要包括：概念（语词）、对当方阵、换质位法、属加种差概念、周延、直言三段论的基本规则、传统解释与布尔解释、标准直言三段论15个有效形式的证明。

2. 本文没有涉及日常用语中的谬误和非形式逻辑情况，读者可自行了解。比较重要的谬误有：诉诸情感、诉诸暴力、红鲱鱼、稻草人、歧义等。

3. 本文部分用词不准确。比如，语词这一概念未被明确。这是因讲解而作出的妥协，读者可自行了解。

4. 现代形式逻辑（数理逻辑）与辩证逻辑未被本文涉及，读者可自行了解。

5. 逻辑作为一种思维工具，不能替代其它学科的重要地位，也不可用于撼动良善的价值观或谋求真理之外的利益。敬请谨记！

近期热门文章Top10

特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。