技术接受模型TAM：感知有用性与易用性如何诊断系统采纳率

做产品、做内部系统、做工具类应用的人，大概都经历过同一种尴尬：功能按期上线，流程跑得通，测试也过了，结果三个月后一看后台数据，日活个位数，绝大多数账号的登录记录停在上线第一周。复盘会上大家开始吵，有人说是推广没做到位，有人说是入口藏得太深，有人说是用户懒。吵到最后往往没有结论，因为每个人讲的都是感觉。

技术接受模型（Technology Acceptance Model，下面简称 TAM）就是用来把这种"感觉"变成可测量、可解释、可干预的一套框架。它不讲功能怎么实现，只回答一个问题：一个人在面对一个新系统时，脑子里到底在算什么账，算完这笔账之后他才决定用还是不用。这篇内容适合三类人看：正在做产品需求评审的产品经理、要给内部系统做推广落地的项目负责人、以及需要做用户调研和问卷分析的技术同学。哪怕你只是想搞清楚"为什么我做的工具没人用"，这套框架也能给你一条能复现的分析路径。

1. 功能上线后没人用：TAM 到底在解释什么

1.1 从"系统能跑通"到"用户愿意用"之间的那道坎

技术团队的评价体系和用户的使用决策体系，几乎完全是两套语言。技术侧关心的是接口响应时间、异常率、并发承载、代码覆盖度；用户侧关心的是"这东西能不能让我少加班""学它要花我多久""同事会不会觉得我多此一举"。两套语言不通，就会出现一种典型错位：系统在技术指标上无可挑剔，在用户心里却毫无位置。

TAM 的价值就在于它把用户那一侧的语言第一次做了结构化。1989 年那篇原始论文里，作者把影响用户采纳的关键变量收敛到两个：感知有用性（Perceived Usefulness，PU）和感知易用性（Perceived Ease of Use，PEOU）。前者是用户对"用了它我能得到什么好处"的主观判断，后者是用户对"用起来费不费劲"的主观判断。这两个判断共同影响用户对系统的态度，态度影响行为意向，行为意向最终影响实际使用。

注意这条链路里有一个非常关键的词：主观。TAM 测的从来不是客观性能，而是用户脑子里的印象。一个响应只要 200 毫秒的系统，如果首页堆了二十个入口让用户找不到北，PEOU 照样低；一个技术上平平无奇的工具，如果刚好卡在某个高频痛点上，PU 就能很高。理解了这一点，你才不会拿着一堆性能监控报表去解释一个采纳率问题——那两张报表说的根本不是一件事。

1.2 原始模型的四个变量与它们之间那条容易画错的线

把原始 TAM 摊开看，核心结构其实非常克制：外部变量 → PU / PEOU → 态度 → 行为意向 → 实际使用。变量少是优点也是缺点，优点是它足够简洁、容易验证，缺点是它把很多现实中的复杂性压缩掉了。

这里有个特别容易被画错的地方：PEOU 对行为意向是有直接路径的，不完全是走 PU 绕一圈。很多人在画模型图的时候，把易用性的作用全部挂在有用性下面，觉得"好用只是为了显得有用"。这个理解偏了。现实里存在大量这样的场景：一个系统对工作效率的提升其实很有限，但因为用起来毫无门槛、抬手就能用，用户依然愿意持续打开它。反过来也成立，一个功能很强大但每次都要记一堆命令的工具，很多人干脆放弃，哪怕他心里承认"这玩意儿确实有用"。

所以 PEOU 在模型里有两条路：一条直接影响意向，一条通过抬高 PU 间接影响意向。第二条路的逻辑是——如果一个系统很难用，用户为了用好它要投入大量学习成本，那么他感知到的净收益就会被摊薄，"有用"的印象也会跟着打折。这条间接路径在实际调研里经常是最有意思的部分，因为它解释了很多"功能明明很强但就是推不动"的案例。

1.3 一个必须提前说清楚的边界：TAM 测的是意向，不是行为

这是我在实际做调研时踩得最深的一个坑。TAM 的核心因变量通常是行为意向（Behavioral Intention，BI），而不是真实的系统使用日志。论文里当然也会挂一个"实际使用"的终点，但那一环的数据质量往往最差，因为它要么靠用户自 report（"你每周用几次"，这个数基本不可信），要么靠系统后台埋点，而埋点数据在不同场景下的可比性很差。

意向和行为之间存在一道缺口，学术界管它叫意图-行为鸿沟。一个人可以在问卷上勾"我非常愿意使用"，然后回到工位上继续用他熟悉的老办法。原因可能是习惯惯性、可能是组织里没人跟进、可能是切换成本在真实工作流里被放大了。这道缺口不是 TAM 的缺陷，而是它的适用边界——它解释的是"用户想不想用"，不解释"用户最后有没有用上"。

所以如果你的目标是诊断采纳率低的原因，TAM 非常适合；如果你的目标是预测下个季度的实际使用量，光靠 TAM 的问卷数据是不够的，必须把后台埋点和组织层面的推行力度一起纳入考虑。搞清楚这条边界，后面的所有分析和结论才不会跑偏。

2. 感知有用性：用户心里那本收益账是怎么算的

2.1 PU 不是功能清单的长度，而是相对收益的判断

产品团队最容易犯的一个错，是把"有用"理解成"功能多"。需求文档上写了一百条功能，就觉得这东西对用户一定有价值。但 PU 在定义上是一个比较级：用户判断的不是"这个系统有没有用"，而是"用它比用我现在的方式，能好多少"。

这个区别决定了很多事情的成败。一个内部审批系统，如果只是把纸质流程搬到线上，审批环节一个没减、签字的人一个没少，那它的 PU 就非常低——用户会想"我在纸上签三个字的事，现在要登录、找人、点按钮，图什么"。反过来，如果这个系统顺手把重复的填单环节自动带出来了，把跨部门的流转顺序理顺了，哪怕界面丑一点，PU 也会明显上升。

我一般会用一个很土的问题来校准 PU："用户在被推荐这个系统之前，他是怎么干这件事的？"如果答不上来，说明你根本没找到参照物，PU 也就无从谈起。参照物可能是 Excel、可能是微信群里吼一声、可能是一个用了五年的老系统，也可能是"干脆不干这件事"。最后这种参照物最容易被忽略，但对 PU 的判断影响极大——有些需求本身就是伪需求，用户原本的选择是"不做"，你做了个系统让他"做"，有用性从起点就是负的。

2.2 影响 PU 的四类外部变量

原始 TAM 里有个笼统的"外部变量"盒子，后来的研究把它拆得比较细。按实操经验，我把它归成四类，这四类基本上覆盖了绝大多数影响 PU 的因素。

这四类里，任务匹配度是最容易被做偏的，结果可见性是最容易被彻底忽略的。

任务匹配度的坑在于：产品团队往往按流程设计功能，而用户是按任务使用系统。一个人一天要处理十几件零碎的事，如果系统只覆盖了其中三件，他还是要打开另外五个工具，那这个系统在他心里的定位就是"又一个要维护的东西"。这就是为什么很多"大而全"的平台反而竞争不过"小而准"的工具——后者的任务匹配度可以做到极高。

结果可见性的坑更隐蔽。有些系统的价值是真的，但它不产生任何可展示的痕迹。比如一个后台的自动化清理任务，用户完全感知不到它在工作。这种情况下 PU 会长期偏低，因为用户没有证据。解决办法不是加功能，而是加反馈：给我一个"本月帮你省了多少时间"的提示，或者把处理前后的对比直接呈现出来。这类设计改动成本极低，但对 PU 的提升往往立竿见影。

2.3 把 PU 落到可测量的题项上

讲框架最怕停在概念层面，所以这里给一套可以直接拿去用的测量题项。这套题项脱胎于原始 TAM 量表，我在多个项目里改过措辞，原则是把"有用"拆成用户能自己回答的具体情形，而不是让他抽象评价。

最后一条 PU-5 是反向锚定的题项，专门用来抓住那批"觉得还行但也没差"的中间用户。正向题项容易让用户顺手打高分，反向题项能逼他做一次真实的比较。实测下来，PU-5 的得分往往比前四条低一档，这个差值本身就是很有信息量的东西。

还有一个细节：题项里的"这类工作""这类事情"必须替换成具体业务场景。写"提升工作效率"这种泛化表述，用户会按社会期望作答；写"缩短报销单填写时间"这种具体表述，用户才会真的去回忆。量表设计里这条经验值千金，比任何统计技巧都管用。

2.4 最大的误判来源：把自己的判断当成用户的判断

做产品的人天天泡在这个系统里，对它的理解深度和普通用户完全不在一个量级。你觉得"这个功能一望即知"，用户可能要摸索十分钟。你觉得"这个价值不言而喻"，用户可能压根没意识到有这回事。

有个很典型的场景：某团队做了一个数据看板，花了大力气把口径做准、把刷新做到秒级。上线后使用率极低。调研才发现，用户真正的痛点不是"数据不准"，而是"看完了不知道要干什么"。数据准不准，是团队视角的有用性；看完能不能直接触发下一步动作，才是用户视角的有用性。这两个判断之间的落差，就是 PU 被高估的根源。

对抗这种误判最有效的办法，是找三到五个真实用户做一轮任务观察：给他一个具体任务，让他在系统里完成，全程不说话，只记录他在哪里停顿、在哪里皱眉、在哪里绕路。这半天的收获，往往比发五百份问卷还大。问卷告诉你分数，观察告诉你分数背后的原因，两者缺一不可。

3. 感知易用性：门槛感是如何被一层层放大的

3.1 PEOU 的两条作用路径与新手的心理账

前面提过，PEOU 一边直接影响行为意向，一边通过抬高或压低 PU 间接起作用。这两条路径在不同用户群体上的权重完全不同。

对新用户来说，直接影响往往占主导。他还没开始用，谈不上收益判断，唯一的判断依据就是"看起来好不好上手"。这时候一个复杂的注册流程、一个满是专业术语的引导页，就足以把他劝退。对老用户来说，间接路径更重要——他已经跨过了门槛，用起来顺不顺手直接影响他做事的效率和心情，进而影响他对"这东西到底值不值"的持续评估。

这就解释了一个常见现象：同一个系统，新用户和老用户的满意度可以差得很远。新手抱怨"太难了"，老手抱怨"太浅了"。很多团队试图用一个版本同时满足两边，结果两边都不满意。比较务实的做法是做分层：新用户走引导模式，默认隐藏高级功能；老用户走效率模式，把高频操作前置。分层设计不是产品上的妥协，而是对 PEOU 在不同阶段的权重差异做出的合理回应。

3.2 学习成本、操作复杂度与自我效能感

PEOU 的构成其实比想象的复杂，至少包含三块：学习成本（第一次上手要花多久）、操作复杂度（单次使用要几步、要记多少东西）、自我效能感（用户相不相信自己能学会）。

前两块是客观的，可以数出来：点击几次、填几个字段、需要记住几条规则。第三块是主观的，而且经常被低估。一个用户如果过去有过"学新系统最后学废了"的经历，他面对新系统时的自我效能感会很低，即便这个系统客观上一学就会。这种心理状态会直接压低 PEOU 的评分，而且靠优化界面是救不回来的——需要的是成功体验，比如让他第一次就顺利走完一个完整流程。

我在设计新手引导时有个坚持：第一个任务必须在一分钟内完成，而且必须有明确的正反馈。哪怕这个任务只是"给一条数据打个标签"，也比让用户先看三段介绍视频强。原因是自我效能感靠成功体验积累，不靠说明文档。这个原则听着简单，但真正落到产品里，很多团队还是忍不住先给用户看功能全景图。

3.3 易用性优化的边际收益在哪里开始变平

这是个很少有人认真算的问题。易用性优化当然是有回报的，但回报不是线性的。从"完全没法用"到"勉强能用"，收益极大；从"勉强能用"到"比较顺手"，收益依然明显；从"比较顺手"到"极致丝滑"，收益就开始快速衰减了。

原因在于用户的容忍阈值。绝大多数用户对工具的要求是"别让我烦"，而不是"让我爽"。一旦跨过了这个阈值，继续投入在交互细节上的边际回报会明显下降，此时更值得投入的是 PU 侧——也就是让用户更清楚地看到收益。

这里可以给一个粗略的量化思路：把易用性优化的投入和它带来的 PEOU 提升做对比，再看 PEOU 提升对意向提升的路径系数。如果路径系数只有 0.15 左右，而 PU 的路径系数是 0.45，那么同样一分力气，花在 PU 上的回报大概是 PEOU 的三倍。当然这只是个数量级的比喻，真实系数必须靠你自己的数据估出来，但它足以说明为什么"先把价值讲清楚"往往比"再把界面磨一遍"更划算。

3.4 一个把入场步骤从三步压到一步的实操

举个具体的改造例子。某内部工具原来的入场流程是：打开网页 → 输入账号密码 → 选择所属项目 → 选择角色 → 进入主页。五步，其中后两步每次都要选，因为系统要确定权限。用户反馈里出现频率最高的词是"麻烦"。

改造做了三件事。第一，把"选择项目"和"选择角色"从入场流程里挪走，改成在主页顶部用下拉切换，默认值取上一次的选择并持久化。第二，账号密码接入了内部的统一身份，一次性登录。第三，把主页从"所有功能平铺"改成"最近使用的三个功能置顶"。

改造后入场变成一步。PEOU 评分在下一轮调研里从 3.2 涨到 4.1（5 点量表）。有意思的是，PU 的一条题项"使用该系统让我的工作更省心"同期从 3.5 涨到了 3.8。改造本身没有增加任何功能，纯粹是降低了摩擦，但用户对"有没有用"的评价跟着上去了——这就是 PEOU 通过间接路径影响 PU 的活样本。

值得一提的是，第三件事（最近使用置顶）的效果比前两件加起来还好。原因不复杂：它同时降低了操作步数，又让用户一进来就看到自己熟悉的入口，自我效能感也跟着上来了。如果一个团队只能做一件易用性改进，我会优先推荐这个。

4. 从 TAM 到 TAM2、TAM3 再到 UTAUT：模型是怎么补位的

4.1 TAM2 补上的两块：社会影响与自愿性

原始 TAM 有个明显短板：它把用户当成一个孤立做决策的个体，但现实中绝大多数系统采纳发生在组织环境里。上级一句话、同组同事都在用、年底考核挂钩，这些因素的力量有时候远超个人对有用性的判断。

TAM2 主要补的就是这块，它引入了主观规范（Subjective Norm）这条线，也就是"我认为对我重要的人觉得我应该用"。这条线有两条作用路径：一条直接影响 PU（因为重要的人说有用，我就倾向于相信它有用），一条直接影响意向（尤其在强制使用的场景下）。

同时 TAM2 还引入了一个关键调节变量：自愿性（Voluntariness）。这个变量的意义在于，它把"强制使用"和"自愿使用"两种完全不同的情境区分开了。强制场景下，主观规范对意向的直接影响很强，因为用户没得选；自愿场景下，这条路径会弱很多，PU 和 PEOU 重新占据主导。

这个区分在实操上极其重要。很多内部系统是"名义上自愿、实际上强制"——领导在会上提一句"大家多用用"，从此没人敢不用。这时候你拿问卷去测 PU 和 PEOU，得到的分数会严重失真，因为用户填的不是"我想不想用"，而是"我敢不敢说不好用"。识别这种情况的办法是加一道测谎题，比如"如果没有任何人要求，你还会继续使用吗"，这道题的答案往往能揭示真实态度。

4.2 TAM3 与 UTAUT：把调节变量和促成条件摆上台面

再往后，模型的演进方向基本是两个：一是继续细化前因变量，二是加入更多调节变量。

TAM3 的主要贡献是把 PEOU 的前因拆得更细，包括计算机自我效能感、感知外部控制（有没有资源和支持）、计算机焦虑、好玩性等，并且指出这些前因对 PEOU 的影响会随着经验增加而减弱。这个结论很符合直觉：新手怕这怕那，用熟了之后这些心理障碍自然消退。

UTAUT 走的是另一条路，它把多个模型的变量整合成四个核心构念：绩效期望（大致对应 PU）、努力期望（大致对应 PEOU）、社会影响（对应主观规范）、促成条件（Facilitating Conditions，指有没有配套的资源、培训、技术支持）。UTAUT 特别强调调节变量，包括性别、年龄、经验和自愿性。

其中促成条件这个概念特别值得做落地的人重视。它提醒我们：用户不用某个系统，有时候既不是觉得没用，也不是觉得难用，纯粹是因为没有条件用。设备不匹配、网络环境不支持、出了问题找不到人解决、培训没覆盖到他所在的班组。这类原因在 TAM 原始框架里是被塞进"外部变量"里的，很容易被忽略。

我见过一个案例，某现场作业的移动端工具推广受阻，产品团队反复优化界面，收效甚微。最后一查，是现场很多人的手持设备型号太老，跑不动新版应用。这不是易用性问题，是促成条件问题。换个思路，把应用做轻量适配，问题迎刃而解。

4.3 模型选型的对照表

模型越往后越复杂，但不是越复杂越好。选哪个，取决于你要回答什么问题、手上有多少样本。

我的建议很朴素：第一次做调研，用原始 TAM 加一两个你自己关心的外部变量就够了。原因不是复杂模型不好，而是变量一多，题项就多，用户填到后面开始敷衍，数据质量反而下降。一个 12 题的问卷，回收质量通常明显好过一个 40 题的问卷。等你把第一轮跑通、发现了具体瓶颈，再针对性地上复杂模型，效率高得多。

5. 把 TAM 跑成一次真实调研：从量表到结论的完整链路

5.1 量表设计：借用成熟题项，别自己硬编

量表设计的第一原则是能借就借。PU 和 PEOU 都有经过大量验证的成熟题项，直接拿来翻译、按场景改写，比自己从零编写靠谱得多。自编题项最常见的问题是题目之间高度相关（问的其实是同一件事），或者题目里混进了因果词（"因为好用所以有用"），导致后面做效度检验时怎么都过不了。

改写时守住三条线。第一，一题只问一件事，别写"该系统操作简单且功能强大"，这种题用户没法答。第二，避免双否定，"不难用"这类表述会让用户反复读三遍。第三，每条构念至少三个题项，两个题项在统计上识别不出来，一个题项连信度都算不了。

一个 12 题的极简问卷可以这样分配：PU 四条、PEOU 四条、行为意向三条、一道测谎或开放式问题。这个体量填起来大概两分钟，回收率能保持在可以接受的水平。如果一定要加外部变量，优先加你最怀疑的那一个，而不是全都加。

5.2 样本量与回收质量：算清楚再发

样本量这个事，很多团队是拍脑袋定的。给一个粗略但能用的算法：做回归或偏最小二乘路径分析，每个预测变量需要 15 到 20 个样本；做协方差结构的路径分析，样本量建议 200 以上。如果按 12 个题项、5 个预测变量、每个变量 20 个样本算，就是 100 个有效样本；但考虑到结构方程模型对样本的要求，实际目标定在 200 份有效问卷比较稳妥。

更精确一点可以用效应量反推。假设中等效应（f² = 0.15），显著性水平 0.05，统计功效 0.95，五个预测变量，算下来大约需要 138 份有效样本。这个数可以作为下限，实际发放时按 60% 到 70% 的回收率倒推，需要发出 200 到 230 份。

回收质量比数量更要命。几个必须做的过滤：填写时长低于 60 秒的剔除（12 题正常要 90 秒以上）、所有题项选同一个选项的剔除（直线作答）、反向题和正向题答案矛盾的剔除。这套过滤做完，通常能砍掉 15% 到 25% 的废卷。我在一个项目里发出去 320 份，过滤后剩 214 份有效，这个比例算是正常的。

5.3 信效度检验的先后顺序不能乱

拿到数据别急着跑路径分析，先把测量模型验证干净。顺序大概是这样的：题项描述统计 → 信度 → 收敛效度 → 区分效度 → 再谈结构模型。

信度看两个指标：Cronbach's α 和组合信度 CR，一般要求都在 0.7 以上。收敛效度看平均方差提取量 AVE，要求大于 0.5，同时每个题项在自己构念上的载荷要大于 0.7。区分效度看两件事：每个构念 AVE 的平方根要大于它与其他构念的相关系数；或者用 HTMT 指标，要求小于 0.85（构念比较接近时放宽到 0.9）。

这里有个常见返工点：PU 和 PEOU 的区分效度经常不达标。原因是这两条构念在某些系统上确实高度相关——用户觉得好用，往往也就觉得有用。遇到这种情况，先别急着删题，回头看看题项措辞是不是混了。比如把"这个系统让我工作更轻松"放在 PU 里，它其实更接近 PEOU。把措辞边界划清楚，效度通常能救回来。

5.4 路径系数怎么读：显著不等于重要

模型跑出来之后，最容易出现的误读是把"显著"当成"重要"。一个路径系数 0.08、p 值 0.03，它在统计上显著，但解释力几乎可以忽略。真正要看的是系数大小和解释方差（R²）。

经验上的参考区间：路径系数 0.1 以下属于微弱影响，0.1 到 0.3 属于小到中等，0.3 到 0.5 属于中等偏强，0.5 以上属于强影响。R² 在 0.3 左右对行为意向这种因变量来说已经是相当不错的解释力，0.5 以上就属于很理想了。

更实用的看法是做相对比较：PU 的系数 0.42，PEOU 的系数 0.18，这两个数的比值告诉你，在这个特定场景里，提升有用性感知的杠杆大概是提升易用性感知的两倍多。这种比较直接对应资源分配决策，比纠结 p 值有意义得多。

另外记得看间接效应。PEOU 通过 PU 影响意向的那条路径，很多时候系数不大但累积效应可观。做分析时用自助抽样法（Bootstrap）估一下间接效应的置信区间，这一步骤经常能挖出一些单看直接路径看不到的东西。

6. 落地时最容易翻车的几处：踩过的坑和应对

6.1 共同方法偏差：同一份问卷测一切

这个问题在自填问卷里几乎是必然出现的。自变量和因变量都从同一个人、同一份问卷、同一个时间点收集，用户填完 PU 顺手填意向，两个答案之间的相关会被系统性抬高。表现出来就是模型拟合得异常漂亮，所有路径系数都很大，R² 高得不像话。

应对手段有几个，成本从低到高排：匿名 + 打乱题项顺序（最基础，必须做）；设置心理分离（在 PU 和意向之间插一段无关的过渡，或者把两份量表分两次发）；引入客观数据（把后台使用时长、操作次数拉进来作为辅助因变量）；多来源收集（PU 问用户，实际使用看日志）。

最低限度也要做个单因素检验：把所有题项一起做未旋转的因子分析，如果第一个因子解释了超过 50% 的方差，那就说明共同方法偏差比较严重，结论要打折扣。这个检验五分钟就能跑完，建议每次都做。

6.2 意向与行为之间的缺口怎么处理

前面提过这个缺口，这里讲怎么在实操中处理。核心思路是：把 TAM 的结果当成诊断，而不是当成预测。

具体做法是，问卷里除了意向，再问一道"过去两周你实际用了多少次"。这道题主观，但能抓住明显的言行不一。然后把这道题和意向做交叉，会分出四类人：高意向高使用（真正的采纳者）、高意向低使用（有意图但被卡住）、低意向低使用（明确的拒绝者）、低意向高使用（被迫使用者）。

这四类人对应四种完全不同的干预策略。高意向低使用的那批最值得深挖，因为他们的意向已经在了，差的只是某个具体障碍——可能是促成条件不足，可能是切换成本太高，可能是某个流程没打通。针对这批人做一对一访谈，往往能挖出最有价值的改进点。

6.3 TAM 解释不了的那部分

得承认框架的边界。TAM 在解释"工具类系统"的采纳时很有效，但在几类场景下会失灵。

一是娱乐型、社交型产品。用户用它们不是为了提升效率，而是为了消遣、归属、表达。这类产品里，好玩性、社交压力、内容质量的影响力远超 PU 和 PEOU。硬套 TAM 会得出"这东西没什么用所以没人用"这种毫无意义的结论。

二是强制度约束的场景。如果不用就扣绩效，那 PU 和 PEOU 都不重要，重要的是促成条件和合规压力。这时候问卷测出来的东西基本不可信。

三是长期习惯型使用。TAM 解释的是采纳初期的决策，但用户一旦用熟了，行为就变成了习惯驱动，跟 PU、PEOU 的关系会明显减弱。这时候要解释持续使用，得换用习惯、满意度、转换成本这一套变量。

识别出这些边界不是否定框架，而是避免拿一把锤子看什么都是钉子。

6.4 一份上线前的自查清单

最后给一份可以直接照着走的清单，按顺序过一遍，大部分坑能提前避开。

• 你的问卷里，PU 和 PEOU 的题项措辞边界清楚吗？有没有互相串味的表述？
• 每条构念至少三个题项吗？有没有哪条构念只有一个题项？
• 目标有效样本量算过吗？按什么依据算的？
• 问卷里有没有一道反向题或测谎题？
• 填答时长、直线作答的过滤规则定了吗？
• 你打算怎么处理共同方法偏差？至少做了题项顺序打乱吗？
• 除了意向，你有没有采集任何行为侧的数据？
• 分析结果出来之后，你准备怎么区分"显著"和"重要"？
• 如果 PU 和 PEOU 的系数差不多，你的资源分配决策依据是什么？
• 这个系统属于强制使用还是自愿使用？你的结论有没有考虑这个前提？

我在实际操作中的体会是，TAM 最有价值的地方不在于它能给你一个多精确的预测，而在于它逼你把"用户不用"这件事拆成几个可以分别验证的假设。以前开会吵半天没有结论，现在至少能坐下来问：是 PU 的问题、PEOU 的问题，还是促成条件的问题？这三个问题的解法完全不同，问对了问题，答案往往就在眼前。至于模型选多复杂、样本量做多大，都是次要的，先把第一步问对，比什么都强。