目录:
上周，一个做 ToB SaaS 的朋友跟我吐槽：他花了两周让 AI 帮忙写了一套完整的 CRM 后端，代码质量不错，测试覆盖率也够。但上线三天就被叫停了——因为产品方向本身就是错的，客户根本不需要这个功能。
两周的 Token 消耗，毁于一个没被认真思考过的问题。
这不是个例。2026 年了，我见过太多团队掉进同一个坑：把 AI 当成万能螺丝刀，拿着它满世界找螺丝拧。 问题在于，很多时候你面前的根本不是螺丝，而是一颗钉子——甚至连"要不要固定这块板"这个前提都没想清楚。
三年 AI 原生工作实践下来，我逐渐形成了一条判断标准：不能被 Token 解决的问题，才配叫问题。
这句话听着像在抬杠，其实它是我用来做工作分配的核心心智模型。
Token 擅长什么：模式空间内的高效执行
先说 Token 的能力边界在哪。这不是贬低 AI，而是用好它的前提。
代码生成：从规格到实现的直线距离
我现在的开发流程里，大约 70% 的"写代码"环节已经被 AI 接管。举几个真实场景：
DingTalk 插件开发。 我维护一个 3800 行的钉钉消息处理插件。每次需要新增一种消息类型的处理逻辑，我只需要描述输入格式和期望行为，AI 就能生成符合项目既有模式的代码——包括错误处理、日志记录、类型定义，甚至单元测试。这类工作的特征是解空间被上下文高度约束，AI 在已有代码中学到了"这个项目是怎么做事的"。
数据处理管道。 一家做电商数据分析的客户，需要把十几种不同格式的供应商数据统一成内部格式。以前这种 ETL 脚本写起来枯燥且容易出错，现在直接丢几个样本文件给 AI，它能准确推断映射规则并生成转换代码。效率提升不是百分比能衡量的——是从"一个人干两天"到"半小时搞定"的质变。
测试用例补全。 某个项目的测试覆盖率从 40% 拉到 85%，核心工作不是我写的，是 AI 根据业务逻辑和边界条件批量生成的。我的工作是 review 这些测试是否真正测到了该测的东西——这个 review 环节，反而是 AI 做不好的。
这些场景的共同点：输入可以被清晰定义，输出有明确的评估标准，且解空间在训练数据的覆盖范围内。 简单说，这是"有标准答案的考试"，AI 是天生的应试高手。
信息处理：大规模模式匹配的降维打击
另一类 AI 擅长的工作是信息的搜集、整理和初步分析：
- 一份 50 页的行业报告，AI 10 分钟提取出所有关键数据点和趋势判断
- 一个 GitHub 仓库的 200 条 Issue，AI 自动分类、识别重复、标记优先级
- 用户反馈的语音记录，AI 转写后提取情感倾向和高频关键词
这些工作本质上是模式匹配。它们确实很重要、很耗时，但它们不是"问题"——它们是解决问题的原材料。
Token 的边界：模式空间之外的无人区
说完 AI 能做的，来看看那些真正需要人类智能的地方。
问题定义：最贵的认知劳动
这是我见过最被低估的能力。
一家在线教育公司找我咨询，说"完课率太低，只有 30%，想用 AI 做个智能督学系统"。表面看这是个明确的技术问题，可以用 Token 解决——做个 Agent 定时推送提醒、分析学习行为、个性化推荐内容。
但我问了几个问题：
- 用户买课的动机是什么？是真想学，还是冲动消费？
- 30% 的完课率在你们品类里算低吗？
- 完课的用户和没完课的用户，在续费率上有显著差异吗？
深挖后发现：他们 60% 的用户是被直播间冲动转化的，买课本身就没有强学习意愿。完课率低不是"学习体验差"的问题，而是流量质量和产品定位不匹配的问题。花三个月做 AI 督学，不如花三周调整投放策略和课程定价。
定义问题的能力，就是把钱花在对的地方的能力。 AI 可以帮你更快更好地解决一个问题，但它不会告诉你"你在解决一个错误的问题"。
架构决策：不可逆选择中的判断力
技术架构选型是另一个典型案例。
一个日活 50 万的社交产品，技术负责人在纠结要不要把消息系统从 MySQL 迁移到专门的消息队列架构。AI 可以：
- 详细对比 Kafka、Pulsar、RocketMQ 的技术指标
- 生成完整的迁移方案和代码
- 估算资源成本和迁移周期
但 AI 判断不了的是：
- 团队 8 个后端里只有 2 个人用过消息队列，培训周期和出错概率怎么算？
- 公司刚融了 A 轮，未来 12 个月的首要目标是用户增长而非技术稳定性，现在做这件事值不值？
- 如果 CTO 本人半年后可能离职，谁来为这个架构的长期演进负责？
这些因素没法被编码成 prompt。 它们涉及对人、对组织、对时机的综合判断——而这种判断力，恰恰是一个技术管理者最核心的价值。
利益博弈：人性不是参数
去年帮一个团队做技术选型，表面是"选 A 框架还是 B 框架"的问题，实际是两个技术 Leader 的路线之争。选 A 意味着甲方团队承担更多工作，选 B 意味着乙方团队要学新东西。技术指标上两者几乎打平。
最终决定选了 B，不是因为 B 在技术上更优，而是因为乙方团队 Leader 刚入职不久需要一个证明自己的机会，且甲方团队本身已经超负荷。
这种决策涉及的是组织政治、个人动机、团队士气——Token 对这些一无所知。
一个实用的思考框架
把上面的思考落地，我日常工作中用三个问题做快速筛选：
第一问：这件事的输入和输出能否被明确描述？
如果你能用一段话清楚说明"给 AI 什么、期望它产出什么"，大概率可以交给 Token。如果你自己都说不清楚期望什么结果，那你要做的第一件事是想清楚，而不是急着调用 API。
第二问：做错了的代价是什么？
写错了一个函数，跑一遍测试就知道了，成本是几分钟。但选错了技术方向、误判了市场需求、得罪了关键人物——这些错误的修复成本可能是几个月甚至不可逆的。高风险决策必须由人类来做。
第三问：这个问题是否可以被拆解为"人类定义 + AI 执行"？
大多数复杂工作都不是纯 Token 问题或纯人类问题，而是两者的组合。关键是找到切分点。比如写一篇技术博客：
| 环节 | 负责方 | 原因 |
|---|---|---|
| 选题和核心观点 | 人类 | 需要判断力和独特视角 |
| 资料搜集和整理 | AI | 模式匹配，大规模信息处理 |
| 大纲和初稿 | AI | 基于模式生成结构化内容 |
| 深度修改和润色 | 人类 | 加入经验、调整语气、强化逻辑 |
| 事实核查 | AI + 人类 | AI 初筛，人类终审 |
这篇文章本身就是这么写的。核心论点和案例来自我三年的实践经验，结构生成和初稿交给了 AI，最终的表达、判断和取舍是我自己的。
组织层面的启示
如果你带团队，这个框架意味着一些深层变化：
岗位价值需要重新评估。 如果一个人的工作内容 80% 是"能被 Token 解决的"，那这个岗位的价值支撑点在哪？不是说要裁人，而是要把人从低价值工作中释放出来，让他们去做问题定义、方案决策、关系建设这些真正有壁垒的事。
评估标准必须改变。 “写了多少代码"“处理了多少工单"这类执行指标越来越廉价。真正有价值的指标是：你定义了多少好问题？你做了多少影响深远的正确决策？你阻止了多少团队走弯路？
AI 基础设施要当一等公民。 团队的知识库、Prompt 模板库、AI 工作流——这些不是锦上添花，而是基础设施。就像十年前你不会让员工用记事本写代码一样，今天也不应该让他们裸手处理那些 AI 能轻松搞定的工作。
两个需要警惕的坑
坑一：AI 依赖症。 什么都问 AI，包括那些本应自己想清楚的问题。长此以往，判断力会退化。我见过有人连"今天中午吃什么"都要问 ChatGPT——这不是 AI 原生，这是思考懒惰。
坑二：AI 恐惧症。 因为 AI “不完美"就拒绝使用，坚持手动完成所有工作。这就像因为计算器"有时候按错键"就坚持用算盘。重点不是 AI 是否完美，而是它是否比你手动做更高效、更一致。
写在最后
“不能被 Token 解决的问题，才配叫问题”——这句话的潜台词是：你的时间和注意力是稀缺资源，要投入到投资回报率最高的地方。
能被 Token 解决的事，让 Token 去做。 不能被 Token 解决的事，才是你作为一个人、一个专业人士、一个决策者真正的战场。
当你下次接到一个任务时，先停三秒钟问自己：这是一个 Token 问题，还是一个真正的问题？
这三秒钟的思考，可能比之后三天的执行更有价值。