# 学会 10 个 AI 工具，不如解决一个真实问题

- URL: https://davidyin.dev/writing/ai-solution-looking-for-problem/
- 作者: David Yin
- 发布: 2026-06-05
- 标签: ai、productivity、x-article
- 摘要: 一个认识的技术朋友，去年花了不少时间学 Cursor、Claude Code，然后搭了一套 workflow：自动拉数据、处理格式、发到 Slack。看起来挺像回事。

一个认识的技术朋友，去年花了不少时间学 Cursor、Claude Code，然后搭了一套 workflow：自动拉数据、处理格式、发到 Slack。看起来挺像回事。

三个月后我问他：这个 workflow 到底省了你多少事？

他想了一下说，「也还好……那个数据其实不太重要，以前两周看一次，现在每天自动发，但我还是两周才看一次。」

**他学会了锤子，但他找的那颗钉子，其实不值得敲。**

## 「会用工具」已经不是稀缺能力

这件事一年前还不一样。「会用 Cursor」「会搭 n8n workflow」在某种程度上确实算个门槛。现在不是了。

根据 Stack Overflow 2025 Developer Survey（getpanto.ai 做过统计汇总），84% 的开发者在用或准备用 AI 工具，51% 已经每天在用。B 站教程、GitHub 模板、公司内训课——在开发者群体里，AI 工具从少数人的新鲜玩意变成大量人日常接触的基础工具。

**对技术人和知识工作者来说，「会用 AI」，正在从竞争优势变成入场资格。**

会用工具的人越来越多，下一个问题就暴露了：你知道用它来解决什么吗？很多人在这里卡住了。不是技术不够，是压根没想过这个问题。

## 手里有锤子，找不到那颗钉子

英文里有个说法叫 "solution looking for a problem"——手里有了解法，但问题在哪，不知道。这正是现在 AI 使用的真实处境。

Slack CMO Ryan Gavin（Slack 隶属 Salesforce）今年初接受 Axios 采访时说了一句话，我觉得很准：「2026 年是孤独 agent 年（the year of the lonely agent）。」很多公司都在试 agent，但不少 agent 没有被交代真正值得解决的任务。

个人也一样。每周都有人分享 AI workflow 截图：自动分类邮件、自动生成日报、自动汇总笔记。看起来很酷。但问一句「这帮你创造了多少具体的业务价值」，往往答不上来。

**AI 的能力储备已经远超大多数人对它的使用，真正缺口不在工具端，在问题端——而找到那个问题，才是真正的门槛。**

## 值得解决的问题，必须过四关

不是所有问题都值得用 AI 解。我自己判断一个业务问题是否值得，用四个条件：

**高频**：至少每周多次、流程相似，才值得自动化。一年就发生几次的例外情况，不该先上复杂 workflow。

**可衡量**：业务收益或结果指标能否量化——处理时长、错误率、通过率，总要有一个数字告诉你它做得好不好。

**可闭环**：AI 的输出是否接入真实业务流程，错了会产生后果、能被发现、有人改。不是靠感觉评价，是有真实代价倒逼闭环。

**责任边界清楚**：谁发现、谁改、谁拥有这个指标。没有责任主体的 AI 项目，大概率变成无人维护的僵尸。

反例：让 AI 写没人真正阅读、也不影响决策的个人周报。频次够了，但「写得好不好」是主观判断，没有可量化的质量标准，出错也没有明确的业务代价——四个条件里少了三个。搭一套复杂 workflow 自动整理会议纪要、自动发日报，本质上也是同样的问题：在自动化一件本来就低价值的事。

正例：客服工单分类。一天几百条（高频）、有标准的问题类型（可衡量）、错误分类会导致响应延误且可以被追踪（可闭环）、客服团队负责跟进（责任清楚）。这才是值得敲的钉子。类似的还有销售线索初筛、合同关键信息提取（金额/期限/主体/违约条款抽取准确率是硬指标）、系统异常告警归因——共同点是频次高、对不对有标准、错了有人负责。

**少得越多，就越不该急着上复杂 AI workflow；先把问题和价值试清楚。**

## 技术人被漏掉的那一步

技术教育教的是「怎么做」：算法、数据结构、系统设计、接口调用。商业培训教的是市场分析和财务模型。

但「怎么把一个业务问题翻译成 AI 可以执行、可以验收的形态」——这件事，两边都没教。

DataCamp 2026 年的《State of Data & AI Literacy Report》里有个数字说明的是培训覆盖不等于能力补齐：82% 的企业在提供 AI 培训，但 59% 的企业依然报告存在 AI 技能缺口。落到 AI 项目里，我更愿意把这个缺口理解成：培训的是工具操作，缺的是问题发现和价值判断。

技术人会问「用什么模型」「搭什么架构」「prompt 怎么写」，但不会问「这个问题值不值得解」「解了以后用什么衡量」「谁来验收结果」。这不是技术能力不够，是根本没被训练过这种思维。

**训练了怎么做，没训练做什么、值不值。** 这个缺口，比工具使用的缺口，难补得多。

## 别再收藏第 11 个工具了

你的 AI 工具列表，大概已经够长了。Cursor、Claude Code、Copilot、Dify、n8n——收藏了多少，不是重点。

下一步不是再找第 11 个工具。是在你当前岗位里，找出一个符合上面四个条件的具体问题：高频 + 可衡量 + 可闭环 + 责任清楚。一个就够。把它搞定，比学会十个工具更值。

**怎么找**：翻过去两周的工作记录，找重复出现、做完有明确对错判断、目前靠人工做的节点。如果有多个候选，先选错误代价最高、最有人在乎、最容易被验收的，不是最容易自动化的。

这件事比学新工具难。因为它不是技术问题，是业务建模问题——要求你对自己的岗位足够熟，知道哪里是真正的瓶颈、哪里的错误有真实代价、谁在乎结果。

**真正学会用 AI，是从想清楚「解决什么」开始的，不是从学工具开始的。**