最近在上培训课的时候，老师在台上讲 STAR 法则（Situation、Task、Action、Result）。讲完之后，她来问我：

“如果让你给 STAR 这四个要素排个重要性顺序，你会怎么排？”

照我 ENTP 的性格，当然不会乖乖作答。我先把问题抛回去：“那你们内部的排序是什么？”

她想了想，说：“一般会看 A → T → R → S，主要看你做了什么（Action），至于情境（Situation），很多时候和 Task 是交叉的…………”

当时我其实很想现场开杠，但先忍住了。更让我在意的是，这个问题背后的前提：

——好像可以脱离岗位和时代背景，对 STAR 各要素做一个“通用排序”。

在“非 AI 时代”，这种想法也许勉强说得过去：一线和执行岗确实更看 Action 和 Result，管理层确实更看 Situation 和 Task。

但这几年，随着各种大模型、自动化工具冒出来，我越来越强烈地感到：

在 AI 时代，不论什么岗位，企业都应该把对人才的关注重心，从 Action 能力，移到对 Situation 能力的考察上来。

如果非要给 STAR 重排一次优先级，我会给出的答案是：

在 AI 时代，答案越来越便宜，情境越来越贵。

后面的全文，其实都在展开这句话。

一、为什么是 Situation？ #

先从一个朴素的观察说起：历史是高度重复的。

大多数人并不是在做“绝对创新”的工作。我们遇到的百分之七八十的问题，在别的公司、别的行业、甚至别的年代，基本都出现过某种变体。

真正决定你能不能搞定它的，往往不是“有没有答案”，而是：

• 你对当下情境看得有多清楚？
• 你能不能从眼前的混沌中，把关键变量捞出来？
• 你能不能判断：这事到底“像极了谁”？在哪些地方和旧问题“长得很像”，在哪些地方又很不一样？
• 你能不能把这些东西讲给别人听，或者讲给 AI 听？

很多时候，只要你把 Situation 拆得够细、看得够透，后面的 Task、Action、Result，反而是顺着逻辑自然长出来的。

在以前，这种“看局面、定义问题、构建情境”的活，更多默认是经理和高管的职责。一线员工被期待的是：你听安排，把事做好就行。

但现在，AI 正在把“执行”这件事，变成一个随手可用、越来越便宜的资源——写文案、写代码、写方案、做表格，通通可以丢给 AI 辅助。于是，那些能看清局面、能定义问题、能构建情境的人，整体溢价开始抬头。

要说清楚这件事，我们得先把“Situation 能力”本身拆一拆。

二、什么是 Situation 能力？ #

如果用一句话说清楚：

Situation 能力，就是在一团现实的混沌里，把“这到底是个什么局”看清楚并讲明白的能力。

它不是“顺手补两句背景介绍”那么简单，而是一整套组合能力：感知、抽象、建模，再加上可以被人和 AI 理解的表达。

细拆开来看，我会把它分成五块。

1. 场景感知与理解：从噪音里捞出关键变量 #

有些人描述问题，是这样一种画风：“最近用户一直在吐槽，群里很吵，销售也说不好卖，老板也不满意……”

信息很多，但全是“发生了什么”的流水账。

而另一些人，会下意识先问一句：**这堆现象里，真正重要的是什么？**他们会做一轮快速筛选：

• 哪些只是背景噪音？
• 哪些是一动就牵一发的关键变量？
• 这些变量之间有没有明显的关联？

比如同样面对“用户增长停滞”，不同人的第一反应完全不一样：

• 有人立刻想到：“做个活动吧、加点投放、搞个裂变。”
• 也有人会先追问：是新增停了，还是留存掉了？是哪一段漏斗卡住了？这段时间产品、渠道、竞品有没有结构性变化？

差别不在“有没有想法”，而在看局面的精度。在和 AI 协作时，这一块能力决定了：你是丢一句“帮我想个增长方案”，还是能给出一份清晰、可执行的背景说明。

2. 经验提炼与应用：从“故事”升级到“模式” #

大多数人对过往经验的记忆方式是“故事体”：那一年，我们搞了一个什么活动，做了哪些动作，最后数据怎么样……

这样记当然可以，但故事停在故事，经验就很难迁移。

更高一层的做法，是事后多问自己两句：

• 这件事里，有没有什么可抽象的规律？
• 哪些做法只适用于当时的场景，哪些可以在别的地方“复用”？

时间长了，你会从“故事收藏家”，变成“模式设计师”。脑子里会自然长出一个小小“模式库”：

• 遇到某种局面，会反应过来：“这大概是我见过的第几号问题。”
• 以前遇到类似情况，我是怎么拆的、踩过什么坑，现在可以先试那一套。

这其实就是人类版的 few-shot learning（小样本学习）：不是把一堆散乱案例丢给 AI，而是先自己整理成可迁移的“小样本”。

3. 系统思考与整合：看到的是“系统”，不是单点 #

现实世界很少有“一按按钮就出结果”的事。更多时候，你动的是系统里的一个点，带来的是连锁反应。

• 你拉高一个 KPI，用户体验可能跟着跳水；
• 你砍掉一块成本，算完整体账，利润反而下降；
• 你优化了本部门指标，别的团队却被动背锅。

有些人做决策，只看眼前这一下：“这个动作本身划算就行。”

有些人则会下意识在脑中画一张“系统图”：

• 这一步会牵动哪些角色和环节？
• 会引发哪些正向反馈、反向反馈？
• 如果把这个动作放大 N 倍，会不会在别处爆雷？

他们不一定更聪明，但明显更有系统感。在和 AI 协作时，这种系统感会体现在：

你能明确告诉 AI：哪些是绝对不能牺牲的底线，哪些是只在特定区间内才成立的前提，哪些是可以试错的缓冲区。

AI 做的是“局部最优”的事，而系统思考是在守“整体不翻车”。

4. 机遇与风险识别：习惯多情景推演，而不是只看下一步 #

一个人的 Situation 能力，很大程度体现在：他怎么想未来。

面对一个决策，不同层级的思考大概是这样：

1. 第一层：“做还是不做？”
2. 稍微谨慎一点：“做了之后不顺利怎么办？”
3. **再往上一层：**自觉去推演几个情景版本：
   • 一切顺利时，会发展成什么样？
   • 普通发挥，大概会卡在哪？
   • 最坏情况下，我们会损失什么？能不能承受？
   • 为了应对最坏情况，现在能不能先布几个“安全垫”？

这种多情景推演不是什么高深战略工具，更多只是一种习惯：在按下执行键之前，先在脑子里过一遍“多结局电影”。

有了这个习惯，你在用 AI 时就不会满足于“一份完整方案”，而是会自然地要求：

• “请分别给出乐观 / 中性 / 悲观三种情景的方案和指标。”
• “如果指标 A 掉到什么程度，就触发备用预案。”

AI 帮你算的是“每个情景里怎么走”，你负责的是选哪条情景轴，在哪个点掉头。

5. 沟通表达与协作：把脑子里的局面翻译出来 #

很多人脑子里其实想得不差，一写文档、一开口，就变成一大坨：

• 背景和观点混在一起；
• 约束条件没说清楚；
• 目标模模糊糊；
• 别人听完只能猜你到底想干嘛。

结构化表达，本身就是 Situation 能力的外放。一个简单好用的套路是：

1. **先讲背景：**发生了什么，有哪些事实；
2. **再讲关键矛盾：**现在真正棘手的点是什么；
3. **再讲约束：**时间 / 预算 / 政策 / 人力有哪些硬边界；
4. **最后讲目标：**这次你最想优化的“那个指标”是什么。

你越能把这套东西讲清楚，和同事对齐理解就越快，把任务交给 AI 时，跑偏的概率也会大幅下降。

所谓 Context Engineering，落到地面上其实就是一句话：你解释清楚一点，大家就少踩很多坑。

小结：给 Situation 能力一个“公式” #

如果要把上面这些压成一行，我会这么写：

Situation = 场景感知 × 经验提炼 × 系统思考 × 多情景推演 × 结构化表达

前四项，决定你能不能把局面看清，最后一项，决定你能不能把局面讲明白——讲给人听，也讲给 AI 听。

三、为什么要从 Action 转向 Situation？ #

前面是在描摹“Situation 能力长什么样”，换一个角度问：

AI 时代到底发生了什么，让这件事比以前更重要？

我自己是从三个层面感受到变化的：技术、竞争环境和组织角色。

1. 技术层面：AI 是超级执行器，人要学会出题 #

先承认一点：在边界清晰、目标明确的任务上，AI 的执行能力的确远超大部分人。你给它一堆干净的数据、一条定义清楚的任务，它能在很短的时间里做出一个相当不错的东西。

问题不在这里，问题在于：现实世界的绝大多数问题，都是“糊的”。

• 信息残缺；
• 角色复杂；
• 目标含糊；
• 限制条件模糊。

如果你把这一团混沌原封不动地扔给 AI，只是相当于换了一个“更快的瞎忙工具”。

真正合理的分工应该是：

• 人先把混沌的现实，切成 AI 能执行的子任务；
• 把“意义”翻译成“数据结构”；
• 把隐含的假设、角色、约束，显性化地放进问题描述里。

AI 再在这个基础上去做“力气活”。从这个角度看，人机协作的本质，其实是：

人出题，AI 做题。你出题出得好不好，直接决定了 AI 的上限在哪里。

2. 竞争环境：执行越来越同质，洞察越来越稀缺 #

外部环境也在悄悄改变。

一方面，各种工具、SaaS、AI 套件越来越多。很多过去需要经验和技巧才能写出的方案，现在点几下按钮，或者给一个模糊指令，AI 就能产出一份“看上去还不错的东西”：PRD 模板、活动方案、邮件范文、汇报 PPT……

当大家都能轻轻松松做出 80 分的 Action 的时候，竞争的焦点自然就会偏移：

• 比的是谁先看到“真正的问题是什么”；
• 谁能更早识别出，哪里有结构性的机会，哪里在酝酿结构性的风险。

另一方面，环境变化的速度越来越快。很多时候，你的制度、流程、规范，还没来得及更新完，外部世界已经变了几轮。

纯粹的“执行力”在这种情况下，有点像一路踩着油门：方向错了，就只是“更快地去错的地方”。

越是这样的环境，越需要有人站在更高一点的位置上，去判断：

• 我们现在到底身处什么局？
• 这套动作放到整个系统里，是在修补，还是在掏地基？

这就是 Situation 能力真正开始溢价的地方。

3. 组织角色：不再是“将军看地图，士兵开枪” #

传统的组织分工比较清晰，高层负责看地图、定方向，基层和一线负责执行。

默认的游戏规则是：你把分内的事情做好，就算称职。

但在 AI 进入职场之后，这种分工结构正在被悄悄改写。

• 很多过去需要大量重复劳动的执行工作，开始可以由 AI 部分接手；
• 一线如果仍然只是“等指令的人”，某种程度上会被边缘化得越来越快。

组织里正在发生的一件事，是**“看地图”的责任在下沉**：

• 一线是“前线情境的感知者”；
• 中层要能把这些碎片抽象、翻译出来；
• 高层再把这些抽象整合成整体判断。

在这个结构里，一个错误的情境判断，一旦被 AI 高效率地执行，很可能变成一个被放大的错误——原来只是在角落里犯的小错，现在变成整个系统的系统性偏差。

于是，原来藏在后台的那一层能力——情境判断质量——开始有了非常高的杠杆效应。

四、从企业视角：AI 时代怎么选人、怎么育人？ #

说完“为什么”，就难免会被问：

“那企业具体该怎么做？”

大致可以分两块看：怎么选人，以及怎么把现有人慢慢推向 Situation 型人才。

1. 选拔：从“执行者”转向“问题定义者” #

如果我今天设计一套面试流程，一定会刻意安排几个**“模糊情境”**。

比如，给候选人一个非常常见、又非常模糊的问题：

“最近产品用户增长停滞了，你会怎么解决？”

然后不要急着听方案，而是看他的第一反应。

有人会毫不犹豫地说：“做个活动试试”“加点投放”“搞个裂变”“我们可以做会员体系”。会发现，他脑子里已经预设了问题类型，几乎没有对情境本身提出任何疑问。

也有人会停顿一下，先把问题掰开：停滞具体是指什么？是新增卡住了，还是留存掉了？是哪一段漏斗出了问题？竞品这段时间做了什么动作？最近有没有渠道、产品、价格上的结构性变化？

两类人对组织的价值完全不一样：前者往往战术勤奋，后者更有问题意识。

类似的设计还可以继续：

在追问过往项目经验时，不要只听“你做了什么（Action）”，要刻意问几句“你从里面抽象出了什么可复用的东西”：这件事如果换一个行业，你觉得你的思路还能用吗？哪些部分是只对当时的情境有效的？哪些部分是更一般性的？

给一个复杂业务痛点，让候选人先列“要搞清楚哪些变量和限制条件”，而不是抢着给方案。

安排一段简单的“AI 协作演示”：先给一个场景，让候选人当场写一段给 AI 的说明，看他怎么描述背景、目标、约束，看当 AI 输出第一轮内容之后，他会如何调整、补充、纠偏。

这些设计的共同点，是把注意力从 “你过去做过什么漂亮动作（Action）” 挪到 “你怎么看问题、怎么构建情境、怎么指挥 AI 做事（Situation）”。

2. 培养：从“教你一招”转向“重建思考脚手架” #

筛完人之后，还有一个更难的问题：

“怎样把现有团队，一点点往 Situation 型人才的方向推？”

我自己会从三件小事入手。

（1）把框架培训当“思维体操”，而不是背口诀

很多公司都有 PEST、SWOT、波特五力之类的分析框架培训，但用法上停留在“背口诀”。

我更喜欢的做法，是：拿真实的业务问题来做演练/逼大家用这些框架重新整理一次当时的情境/看看会不会得出一些和当时不同的认识。

（2）调整复盘会的时间配比

很多团队开复盘，习惯按照“背景—过程—结果—教训”这样的套路走，但真正花时间的，往往是“我们做了什么”。可以做一个小小的时间重构，规定至少有一半时间，用来讨论：当时外部和内部的情境怎么变了？我们基于什么判断做出那个选择？当时漏掉了哪些变量？事后有哪些判断被事实推翻了？

复盘的重点，从“动作复述”变成“情境再建模”。

（3）在日常沟通里，增加一点点“结构化要求”

你可以很简单地要求，遇到重要问题，请至少用四行写清楚：

1. 现在发生了什么（事实，而不是情绪）；
2. 谁受影响（用户、同事、老板、合作方，各是哪一类）；
3. 有哪些硬约束（时间、预算、政策、资源…）；
4. 哪些地方是我们都不确定的。

时间久了，大家自然会把这套表达方式，内化成自己的思考脚手架。

知识管理也可以顺势升级一下，与其继续累积一个以“结果”和“方案”为主的文档堆，不如刻意把“情境”和“方案”绑在一起存：

• 当时是在什么业务阶段？
• 外部环境怎样？
• 内部资源状况怎样？
• 关键判断是什么？
• 后来是被哪些事实验证或推翻的？

长久来看，你得到的是一个“情境—方案”的映射库，而不只是一个“方案收藏夹”。

最后，还可以鼓励大家用 AI 来照镜子，不是教他们怎么用 AI 写文案，而是教他们怎么用 AI 来发现自己对情境理解的盲区。先把自己理解的情境和目标写出来丢给 AI，再问它：“你觉得这里有哪些信息缺失？”“你有哪些地方看不懂？”

如果 AI 提出来的问题本身有价值，那么补全这些问题的答案，就是对 Situation 的一次升级。

五、从个人视角：普通职场人怎么练 Situation 能力？ #

从企业视角再回到个人视角。如果你现在在一个普通岗位上，很自然会问：

“我做什么能提升自己的Situation能力呢？”

我自己的感受是，可以从三组具体动作包开始。

动作一：先学会把情境写清楚（四行模版） #

下次再遇到一个问题，哪怕你已经隐约有了解决方案，也先按住那只蠢蠢欲动的手，给自己五分钟时间，把情境写一写。你可以直接照着下面四行模版填：

1. **现在发生了什么？**尽量用事实，而不是情绪和评价。
2. **谁会受到影响？**用户 / 同事 / 老板 / 合作方，分别是哪一类、大概有多大范围。
3. **有哪些硬约束？**时间、预算、人力、政策、技术边界……
4. **有哪些地方是我自己也不太确定的？**直接写成问题：比如“我们其实不知道 A 还是 B 是主因”。

写完这四行之后，再去：丢给 AI，或者去找别人讨论，或者开始构思方案。

你会发现，光是这个动作，就已经筛掉了大量“无效忙碌”。

动作二：把 AI 当“思维镜子”，而不是“答案机器” #

很多人用 AI 的默认姿势，是一上来就说：“帮我写个 xx。”、“给我想几个方案。”

这当然也能用，只是有点浪费。不妨换一个玩法：把 AI 当成一个永远不会烦你的笨同事。

具体可以这样来一轮：

1. 先尽你所能，把背景、目标、冲突、限制条件写出来；
2. 然后问它两个简单的问题：你有没有哪儿看不懂？如果你是我，还希望补充哪些信息？

AI 的回答未必条条都重要，但它提出来的问题，本身就是对你情境理解的一次检查。你会很直观地看到：原来你压根没说某个重要约束，原来目标表述得模糊，原来你前后两处假设是互相矛盾的。

在一次次“补洞”的过程中，你的表达能力会被顺带锤炼，Situation 能力也会慢慢长起来。

动作三：刻意练习“跨情境找同构” #

最后这一块稍微高级一点——但也最有意思。简单说，就是试着在不同领域、不同问题之间，寻找“长得很像的结构”。比如：

• 你看一本讲生物进化的书，可以问自己：“这里的‘适者生存’‘生态位竞争’，有没有和我所在行业类似的地方？”
• 你看一本讲城市规划的书，可以看看：城市里的交通流、信息流、物流，是不是和你所在公司里的信息流、决策流结构很相似？

反过来，当你遇到一个棘手问题时，可以问自己：

• “我在哪本书、哪个行业、哪个案例里，看过类似的‘局面’？”
• “那些人当时是怎么处理的？”
• “哪些做法能迁移过来，哪些完全不适用？”

这种跨情境的同构感一旦开始被你察觉出来，你对现实的理解就不再被局限在某一个小圈子里。你会越来越常有这种感觉：哦，原来这也是那种情况。而不是每遇到一个新问题，都从零开始瞎摸索。

这部分能力，目前仍然很难完全教给 AI，也很难完全被 AI 替代。

结尾：答案越来越便宜，情境越来越贵 #

最后，用一句话把前面所有内容收一下：

在 AI 时代，答案变得极其廉价——你随手打开一个窗口，就能拿到一份“看起来还不错的方案”；真正贵的是那个能把问题定义清楚的人，是那个愿意花时间把情境看清楚、讲明白的人。

对企业来说，问题不只是：要不要用 AI 提升效率？更是：我们有没有在有意识地寻找、培养那些擅长构建 Situation 的人？

对个人来说，问题也不只是：会不会被 AI 替代？而是：我有没有在刻意练习自己看清情境、表达情境的能力？

下一次，当你准备向 AI 丢出一句“帮我写点什么”的时候，不妨先停一下，给自己五分钟，把 Situation 写一写。

也许从这五分钟开始，你就已经在做一件，未来几年里会越来越值钱的事。

后记 #

原文创作于2025年3月，上海。介于原文行文风格过于ENTP，且充斥着大量的术语 比如**同构性 (Isomorphism)、思维模型（Mental Models）**等，且后来 Context Engineering等概念越来越火，于2025年12月修改第二版本，比如，主融合了 Context Engineering概念，优化了行文风格（更口语化、去除强entp风格和过多的术语）。