AI 工具越强大关于“人的价值还剩什么”的讨论就越频繁。最近一段关于 Notion 产品负责人的讨论内容在开发者社区和产品社区被频繁转发核心观点落在“AI 时代比技能更值钱的是什么”这个问题上。这里说的“技能贬值”并不是指编程没有用了而是说当 Cursor、Notion AI、Copilot、各类大模型 Agent 已经能快速完成翻译、总结、写代码片段、整理表格这类“技能型任务”时一个人真正的竞争力开始从“会不会做”转向“知不知道做什么、怎样算做好”。这篇文章不打算转述访谈内容而是把这场讨论落成一套可练习、可自检、可复盘的能力框架帮助开发者和产品经理在真实项目中验证自己是否正在往正确的方向积累。1. 先理解这场讨论AI 时代“技能贬值”到底指什么1.1 技能与元能力的边界会写代码与会解决问题是两件事先做一个最简单的区分。技能指的是“按已知流程执行任务”的能力例如知道 Spring Boot 的启动流程、会写 SQL 联表查询、能配置 Nginx 反向代理、会用某一种框架完成 CRUD 接口。这些能力的特点是流程清晰、结果可预期、大量出现在教程和文档里恰好是 AI 训练数据最充足、生成最稳定的部分。元能力指的是“在未知条件下定义问题、选择目标、组织资源、判断结果”的能力。它不直接产出代码或文档但它决定 AI 产出什么、产出后是否可用。比如面对一个模糊需求是直接让 AI 生成页面还是先追问“这个页面给谁用、在什么场景下解决什么问题、数据从哪里来”这就是元能力。在实际项目中两者经常被混为一谈。很多人以为“会写代码”等于“能交付功能”但当 AI 能写出 80% 的常规代码后剩下的 20% 恰恰是最关键的需求是否被正确理解、边界条件是否覆盖、异常路径是否处理、性能是否符合预期。这 20% 靠的不是某个框架的语法熟练度而是对问题本身的理解深度。这里要特别注意一个容易误解的地方。技能贬值不等于基础不重要而是说基础变成了“必要条件”而不是“竞争优势”。你不会写代码就无法验证 AI 的输出但仅仅会写代码已经无法形成差异化。逻辑链路是基本功保证你不上当元能力保证你做对事两者是叠加关系不是替代关系。1.2 为什么产品负责人会先谈“判断力”而不是“提示词”这场讨论里出现频率最高的词是 judgment也就是判断力。原因不复杂AI 把执行成本压得很低之后整个工作流的瓶颈前移到了“下指令之前”和“收结果之后”。下指令之前你需要判断这个问题值不值得做、目标是质量还是速度、约束条件是什么。收结果之后你需要判断 AI 的输出是否偏离目标、有没有幻觉、有没有隐藏的维护成本。这两个环节恰恰是纯程序执行无法覆盖的。以 Notion AI 这类产品为例。它能把会议记录整理成待办、把零散笔记改写成结构文档、把数据库内容生成摘要。但这些输出有没有价值取决于使用者是否清楚自己的笔记要服务什么目标。同一个 AI给一个目标明确的人用能省一小时给一个目标混乱的人用只会多一篇看起来漂亮但没法落地的文档。这个差异不是 AI 造成的是使用者的判断力造成的。工程师这边也一样。用 Cursor 生成代码时AI 能给出可运行的版本但它不会告诉你这个方案是否贴合项目现有架构、是否引入过多依赖、是否适合团队长期维护。判断这些的仍然是人的领域经验。所以“比技能更值钱”的不是某种新技能而是判断力、品味、领域理解这类长期积累的元能力。1.3 一张速查表哪些能力在贬值哪些能力在升值能力类型典型行为AI 影响未来重要性工具操作记忆快捷键、配置语法、敲命令快速替代不必刻意记下降保留够用即可流程记忆记住框架标准写法、模板结构快速替代生成即所得下降但验证能力仍需要算法基础理解复杂度、数据结构和核心原理部分替代但排查时仍依赖保持属于基本功问题定义把模糊需求拆成可验证的目标无法替代显著上升结果判断识别幻觉、评估代码质量、验证交付标准无法替代显著上升取舍决策在成本、质量、风险之间做选择可以提供选项但选不了显著上升领域沉淀理解业务规则、用户习惯、行业约束无法替代显著上升这张表能解释很多现象为什么一个“API 记得不熟”的工程师可能比“什么语法都记得”的工程师在 AI 时代更有价值为什么一个懂业务流程的产品经理拿到 AI 工具后产出会明显超过只会罗列需求的新人。关键是不要把“熟练度”和“判断力”混在一起评估。2. 把“比技能更值钱的东西”拆成四项可练习的元能力2.1 问题定义把模糊诉求变成可执行命题AI 最容易暴露的一个问题是它对模糊指令会给出“平均化”答案。你说“帮我写一个用户登录功能”它会按最常见的方式写但你的项目可能已经用了特定权限框架、特定的密码策略、特定的错误码规范。问题定义能力的价值就是在给 AI 下指令前把这些上下文补齐。一个可练习的方法是每次动手前先写一段“问题定义”包括五个要素服务对象、使用场景、核心目标、约束条件、验收标准。这五要素不一定要写进提示词但必须在你自己的脑子里是清楚的。下面是一个可以直接用于需求澄清的模板## 问题定义模板 - 服务对象谁使用这个功能他们的技术水平和使用习惯是什么 - 使用场景在什么时间、什么设备、什么前置条件下使用 - 核心目标这个功能要改变用户当前遇到的哪个问题 - 约束条件技术栈边界、性能要求、合规要求、发布时间 - 验收标准满足什么条件才算完成边界情况和异常情况如何定义把这个模板当成“下指令前的一分钟检查”而不是额外负担。实际运行时你会发现很多在 AI 生成后才返工的场景问题都出在目标没有写清楚。比如“帮我总结这段会议纪要”听起来很简单但如果不说清楚总结给谁看、要什么粒度AI 给的可能是目录式要点而不是你要的决策摘要。2.2 品味与交付标准知道什么结果值得交付品味这个词听起来偏主观但在工程里它可以拆成可验证的标准这段代码是否容易给下一个人阅读这个接口的错误信息是否对调用方友好这个页面在数据为空、加载中、失败时是否都处理过这个文档的结论是否放在第一屏。AI 生成内容的一个特点是“形式上很完整”。代码有注释、文档有小节、接口有返回结构但形式的完整掩盖不了内容的空洞。判断力差的人会把“AI 生成了可运行代码”当成“功能完成”判断力好的人会继续问用户误操作会怎样、依赖升级后这段代码会不会坏、日志里能不能定位到问题。这里可以直接把“AI 幻觉”当成训练品味的机会。比如让大模型解释一段不熟悉的代码逻辑它可能编造一个看似合理但实际不存在的调用关系。此时如果只看表面流畅度就会被带偏如果习惯性回到源码、日志和数据流里验证就会慢慢形成“先怀疑、再验证”的交付标准。真正的交付标准应该是不只要看到符合预期的结果还要知道结果为什么正确、什么情况下会失败。2.3 取舍与约束判断在版本、成本、风险之间做决定AI 时代出现了很多新的约束变量这进一步放大了取舍能力的重要性。最典型的是模型选型和成本控制。现在很多 AI 平台上都有 credits 或 token 计费机制不同模型的价格、延迟、质量差异很大。无脑用最强模型成本可能爆炸全程用最便宜模型产出质量又不够。取舍判断不是背参数表而是建立一套决策顺序先确认任务类型再评估失败代价再选择工具和预算。比如内部文档初稿可以用便宜模型批量生成用户可见的对外文案或财务相关代码就要谨慎评估一次性的探索任务可以接受一定幻觉风险生产环境的代码就要求可复现、可测试、可回滚。这套逻辑和传统工程里的技术选型没有本质区别。过去选型要权衡框架生态、团队熟悉度、部署复杂度现在选型要多考虑模型能力、成本、数据隐私、输出可控性。对于工程团队来说应该把“AI 选型”纳入常规评审而不是让个人开发者凭感觉决定否则很容易出现“用了大模型但没人能解释为什么选它”的情况。2.4 学习与重构知识的能力把 AI 当脚手架而不是外脑很多人在 AI 时代陷入两个极端要么完全不学基础什么都让 AI 生成要么坚持“纯手写”把 AI 当敌人。更合理的定位是把 AI 当脚手架而不是外脑。脚手架的意思是它帮助你快速搭建和理解结构但你对结构的理解和重建能力必须保留。一个可复用的学习路径是拿到 AI 生成的结果后强制自己完成三件事——概括它解决问题的核心思路找出它做的一个关键决策并解释为什么尝试不借助 AI 把它重写或改造一遍。这三件事能确保你不是在“复制粘贴”而是在建立自己的知识结构。否则就会出现一个典型的困境遇到没见过的错误日志不知道把哪一段贴给 AI也不知道 AI 给的修复建议是否适用。知识重构能力还有一个实际价值当 AI 工具更新、模型替换、某个框架过时时你的知识骨架不会坍塌。技术细节会过时但你关于“如何学习一个陌生系统、如何定位问题、如何验证解决方案”的方法论不会这就是比技能更值钱的那一部分。3. 在真实工程场景中把这套判断用起来3.1 从“让 AI 写代码”升级到“让 AI 参与交付”如果只在“生成代码”这一步用 AI提升是有限的。更值得做的是把 AI 接入完整交付链路让每个环节都使用你的判断力做校准。下面是一个推荐的团队工作流需求阶段: - 用问题定义模板澄清目标 - 让 AI 列出可能的边界情况和风险点 - 人工确认优先级和验收标准 设计阶段: - 先给出自己倾向的方案 - 让 AI 补充替代方案并说明差异 - 把方案对比放进评审文档 编码阶段: - 用 AI 生成骨架代码 - 人工补齐异常处理和关键注释 - 用 AI 做代码审查再人工确认 测试阶段: - 让 AI 根据需求生成测试用例 - 人工补充业务规则相关的边界测试 - 运行结果必须有人验证 复盘阶段: - 让 AI 总结本次变更的变更点和风险 - 人工判断总结是否遗漏业务上下文 - 沉淀为团队知识库条目这个流程的关键不是每个环节都“用到了 AI”而是每个 AI 输出后面都跟着一道人工判断闸门。如果没有这道闸门AI 只是把错误更快地批量生产出来。一个具体的做法是在编码阶段使用结构化提示词把上下文补齐减少 AI 的猜测区间请为以下需求设计一个接口实现要求先给出设计思路再写代码。 背景这是一个内部订单管理系统使用 Spring Boot 3 和 MySQL。 需求订单取消后需要把库存数量回补并记录一条操作日志。 约束 1. 只有状态为 PENDING 的订单可以取消。 2. 库存回补和订单状态更新必须在同一事务中完成。 3. 操作日志字段包含 orderId、operator、action、time。 4. 请说明你处理并发取消的方式。 验收标准 - 并发请求同一条订单时只能成功取消一次。 - 失败时返回明确的错误码不出现库存多回补的情况。可以看到这里最重要的部分不是“请写代码”而是“背景、约束、验收标准”。这四项都是由人的判断力补充的AI 只负责执行。给的信息越具体AI 输出的可用性越高。3.2 用工作流复盘检查单验证能力提升能力提升无法只靠“感觉”。推荐每周或每个迭代结束后用一份复盘检查单做自评。这份清单的重点是区分“AI 帮了多少”和“你的判断补了多少”。## 每周 AI 协作复盘检查单 1. 本周有几个需求是从模糊诉求开始你做了哪些澄清 2. AI 生成的结果中哪些直接可用哪些返工了 3. 返工的根因是提示词不完整还是需求本身没想清楚 4. 哪一次你发现了 AI 的错误发现方式是什么 5. 哪个 AI 结论你验证后才敢用验证过程是什么 6. 本周在你的领域里你新增了哪一条别人不知道的认知 7. 有没有一个场景你不借助 AI 手工完成会更快 8. 下一次面对同类任务你的提示词会比这周好在哪里前四个问题排查效率问题后四个问题排查成长问题。如果没有一个问题是能答上来的说明 AI 使用还停留在“生成”层面没有进入“交付”层面。3.3 学习环境与生产环境的区别环境AI 使用策略关键注意点学习环境大量使用 AI 解释概念、生成示例、对比写法必须自己重写一遍不能只看生成结果开发环境用 AI 生成骨架、单测、文档人工负责架构和异常让 AI 输出设计思路不要只输出代码测试环境用 AI 生成用例矩阵、造数据、检查覆盖盲区业务规则必须人工补充AI 无法理解公司政策生产环境有限使用涉及数据、权限、资金的功能要人工重点审查保留完整日志和回滚方案AI 不能做最终裁决生产环境最重要的不是“用不用 AI”而是“出了问题能不能追溯”。所以凡是 AI 参与产出的内容都要有版本记录、生成记录、人工审核记录。否则一旦线上故障你无法回答“这段代码为什么长这样、是谁在什么背景下决定的”。4. 常见误区与排查路径4.1 误区一把提示词技巧当成核心能力现象大量学习提示词模板、收藏各种“高级 Prompt”认为掌握提示词就能提升 AI 产出质量。原因提示词只是沟通方式的一部分真正决定产出的是你的问题定义和领域上下文。同一个提示词给不同人用结果差别很大。检查方式回顾最近一次 AI 产出不满意的任务是提示词句子不漂亮还是你根本不清楚要什么结果。解决方式把注意力从“提示词写法”转移到“需求澄清”上。先用问题定义模板补齐上下文再写提示词。建议把 80% 的思考时间花在“我要什么”20% 花在“怎么问”。4.2 误区二大量生成却从不建立个人判断现象遇到问题第一反应是让 AI 生成方案拿到结果直接采用从不对结果做反向验证。原因生成动作的成本太低导致验证动作被跳过。长期下来个人判断力会因为缺少使用而退化。检查方式本周有没有一次任务是你先给出自己的判断再让 AI 补充意见的如果没有说明你在单向依赖 AI。解决方式强制要求自己“先答后问”。面对任何问题先在纸上写出自己的思路和答案再用 AI 验证或补全。即使你的答案不如 AI这个“先答”的动作也在训练判断力。4.3 误区三只追新模型不沉淀领域知识现象每次出现新模型就切换反复测试谁写代码更快、谁的文案更自然却很少深入理解自己所在业务领域的规则和约束。原因模型能力的提升会带来短期新鲜感而领域知识的积累是长期慢变量容易被忽视。检查方式你是否能清楚地讲出当前项目里最核心的一条业务规则、最容易被忽略的一个异常场景如果讲不出来说明领域积累不足。解决方式每周固定时间做“领域复盘”把项目里出现过的业务规则、用户反馈、故障案例整理进自己的知识库。这些内容 AI 替代不了它们才是你判断 AI 输出是否正确的依据。4.4 从结果倒推能力短板一条四层排查链路当 AI 合作结果不理想时不要直接归因于“AI 不行”按下面四层顺序排查能快速定位短板在哪个环节排查层问题常见现象处理方向输入层需求是否清晰上下文是否完整AI 输出偏泛、不贴合项目用问题定义模板补齐约束指令层提示词是否准确表达目标输出方向对但格式不对给出明确输出结构和验收条件执行层工具版本、上下文窗口、模型能力是否匹配代码报错、引用不存在检查模型选型和使用方式判断层人工是否完成了验证和交叉检查出现幻觉而未被发现建立“先怀疑、再验证”的交付检查绝大多数“AI 生成的东西不能用于生产”的情况问题不在表层报错而在输入层和判断层。输入层没想清楚AI 只能猜判断层不验证AI 幻觉就会直接进入代码库。把排查链路固定下来团队每次不满意的产出都能变成一轮能力补课而不是一次无效抱怨。5. 给开发者和产品经理的 AI 时代能力建设清单5.1 每天刻意练习的三件事第一先定义再提问。任何任务都先花一分钟写出目标、约束、验收标准再打开 AI 工具。一开始会慢但两周后会明显减少返工。第二先答后问。遇到技术问题先自己在文档、源码、日志里找线索形成初步假设再用 AI 验证。这个习惯能同时提升检索能力和判断力。第三复盘一次错误。每天找出一个 AI 输出中不准确、不完整、或上下文缺失的地方记录为什么出错以及你如何发现。这是训练“AI 幻觉识别力”最直接的方法。这三件事都不需要额外大块时间但需要刻意坚持。它们练的都不是“技能”而是“比技能更值钱”的判断和反思能力。5.2 生产环境底线清单在引入 AI 到生产环境前团队应该先约定底线避免个人使用习惯影响整体稳定性。## 生产环境 AI 使用底线清单 1. 涉及用户隐私、资金、权限的数据不得直接发送给外部 AI 服务。 2. AI 生成的代码必须经过人工评审评审记录留档。 3. 关键路径事务、支付、鉴权不允许直接使用未经验证的 AI 输出。 4. 所有 AI 参与生成的内容在发布说明里标注生成时间、模型、人工审核人。 5. 禁止在无法回滚的变更上使用 AI 自动修复。 6. 新的 AI 依赖工具上线前先做最小范围灰度验证。这份清单的目的不是限制使用而是让 AI 成为“可控的工具”而不是“不可解释的黑箱”。判断力强的人不会因为清单而降低效率反而会因为边界清晰而更敢用 AI。5.3 下一阶段从会用 AI 到能定义 AI 产品对已经比较擅长用 AI 的工程师和产品经理来说下一阶段的增长点不是“用得更熟练”而是“能定义工具本身”。这包括理解 AI Agent 的任务拆分方式、掌握 AI 应用开发中的测试策略、了解模型部署和成本控制甚至参与设计团队内部的 AI 工作流。具体可以参考下面几条路径把重复的提示词固化成团队模板减少个人差异带来的质量波动。记录典型的 AI 失败案例形成团队内部的“AI 输出审查指南”。从简单工具链开始尝试使用 Spring AI 或类似框架做一个小型 Agent 应用理解上下文管理和工具调用的工程难点。产品经理可以把自己最熟悉的业务闭环拆成“AI 能做什么、AI 不能做什么、数据从哪里来”这本身就是 AI 产品经理的核心能力。这个阶段的判断标准不再是“我让 AI 做了什么”而是“我能不能设计一套流程让团队里的每个人都能稳定地从 AI 中获得价值”。这也正是 Notion 这类产品本身的思路不是消灭人的判断而是把人从重复执行里释放出来把判断放在更重要的位置。回到开头那个问题。AI 时代比技能更值钱的不是某个具体的工具技巧而是对问题的理解、对结果的判断、在约束下的取舍以及持续重构自己知识结构的能力。这些能力无法靠购买更高配置的模型获得只能在一个个真实需求、一次次人工验证、一轮轮复盘里积累。对开发者而言现在就是开始练习的最好时机下一次按下“生成”按钮之前先花一分钟想清楚你要的到底是什么。
