AI时代比技能更值钱的是定义问题、构建上下文与评判结果的能力

最近在开发者社区里一个问题被反复追问当 AI 已经能在几分钟内完成一个初级程序员几天的编码任务我们每天花那么多时间背 API、记语法、调框架细节到底还有没有意义这个焦虑不是空穴来风。Notion 产品负责人在公开分享中给过一个更直接的判断AI 时代比技能更值钱的是另一些东西。这期内容传播度很高但很多人只记住了“技能不值钱”这句结论反而更焦虑了。这篇文章不打算复述那场分享的金句而是想把它翻译成技术人员能落地的能力框架。结合提示词工程、AI Agent 开发、知识库检索、模型本地化部署、效果评测这些这两年非常热的技术方向聊聊一个普通技术人应该怎么重新配置自己的时间和能力结构。核心观点很明确技能并没有变得不重要而是它的稀缺性变了。真正拉开差距的是对问题的定义能力、对上下文的构建能力和对结果的评判能力。1. AI 时代的焦虑技能贬值是真的吗先承认一个事实AI 对技能型工作的冲击确实比我们想象中更快。过去一个初级翻译靠语感吃饭一个初级文案靠模板套路吃饭一个初级开发靠“知道某个框架怎么用”吃饭。现在这些技能都被大模型快速覆盖。翻译有大模型实时翻译文案有 AI 生成润色基础代码生成已经渗透到主流编辑器。你花六个月掌握了一个框架的基础用法AI 更新的速度可能比你学习的速度还快。这种贬值速度会让人觉得那我是不是不用学技能了反正在 AI 面前学什么都会过时。这是最危险的误解。技能贬值不等于技能无用。真正发生变化的是技能在个人竞争力中的权重。以前技能是决定性的会不会某个技术栈直接决定了你能不能做好一个项目。现在 AI 承担了大量“执行技能”的部分个人技能不再是唯一杠杆而更像一个让人具备“判断和筛选能力”的底座。举个例子。现在很多团队在接 AI 编程工具比如 Cursor、GitHub Copilot 这类助手。你会发现一个很明显的变化同样一个需求会写提示词的人和不写提示词的人产出质量完全不同懂代码评审的人和不评审的人最终交付结果完全不同。AI 能不能给出正确答案是一回事你能不能判断它给出的答案是否合理是另一回事。所以技能贬值是真实的但贬值的是“单纯靠记忆和执行换取薪水”的那部分。而判断力、领域经验、对上下文的理解这些很难被 AI 快速替代的能力正在成为新的稀缺资源。这也是 Notion 产品负责人那期分享的核心信息。它不是在否定技能而是在提醒大家如果你把全部筹码押在“我会用某个工具”上那 AI 时代确实会让你感到极大的不安全感。2. 核心判断AI 锁定的是技能而不是能力2.1 为什么技能会加速贬值要理解这个问题得先分清“技能”和“能力”。技能是可以被标准化、流程化、被工具替代的操作性知识。比如熟悉某个框架的注解、知道某个函数的参数顺序、记住某种配置文件的写法。这些知识在大模型训练时已经被大量吸收变成了模型本身的能力。能力则是综合性的、需要结合实际场景判断的素质。比如面对一个模糊的业务需求你能否把它拆解成清晰的 AI 任务拿到 AI 生成的结果你能否识别出逻辑漏洞和潜在风险一个大型项目里你能否找到核心阻塞点并把它转化为一个可执行的 AI 协作方案。大模型最擅长替代的恰恰是第一种。你写代码时模型会补全你查资料时模型会总结你写日报时模型会润色。当这些执行层面的技能被工具吸收后人需要聚焦的就只有更高维度的东西。这个维度里包含三个关键词目标定义、上下文构建、结果判断。2.2 比技能更值钱的三种能力第一是定义问题的能力。同样一句话需求有人直接扔给 AI 问“帮我写个登录功能”有人会先确认需求边界、约束条件、目标用户、异常场景然后再告诉 AI。后者得到的回答质量一定远超前者。因为 AI 生成结果的高度取决于它接收到的指令质量而指令质量又取决于你自己是否真的想清楚了问题。第二是构建上下文的能力。AI 模型本身缺乏你项目的背景知识它不知道你的业务是做什么的不知道你代码库里的命名规范更不知道你这次修改为什么需要兼容老版本。所以你需要把散落在文档、代码、需求单里的信息组织成模型能理解的结构化上下文。这就是为什么这两年 RAG检索增强生成、知识库、向量检索这些概念会火起来。它们解决的都是同一个问题让 AI 获得更完整的上下文。第三是评判结果的能力。大模型有幻觉有输出不稳定的问题有理解偏差的可能。生产环境里你不可能百分之百信任模型生成的内容。所以怎么验证答案的正确性、怎么设计评测集、怎么对失败的 case 做回归分析这些能力正在从“测试工程师的专利”变成所有 AI 应用开发者的基本功。2.3 观点落到技术上是什么Notion 产品负责人说的是产品与组织的观察但落到技术层面它其实指向一个清晰的转型方向从“我会用某技术栈写某功能”转向“我能定义清楚问题、组织好上下文、判断好模型输出并把这一切工程化”。这也是为什么现在很多人在研究 AI Agent、本地部署、AI 应用开发框架像 Spring AI、各类 Agent 框架、提示词管理工具等等。它们本质上都是为了让个人或小团队具备“构建 AI 应用”的能力而不是被 AI 工具替代。3. 开发者视角能力模型需要重新配比如果你是一个后端工程师或全栈工程师过去你的能力模型大概是这样能力维度具体表现语言基础Java / Python / Go 语法与核心库框架使用Spring Boot、MyBatis、JPA 等中间件Redis、MQ、数据库、缓存工程实践代码规范、Git 流程、CI/CD业务理解理解业务规则并转化为代码这套模型没有过时但在 AI 时代需要加入新的维度新增能力维度具体表现问题拆解把模糊需求拆成可执行的 AI 任务链上下文设计设计 prompt、组织检索内容、设计知识库结构评测与验证构造评测集、识别幻觉、评估生成质量模型与工具选型选择合适的大模型 API 或本地部署方案AI 工程化接入、监控、降级、成本控制你可以看到原来的技能并没有消失而是变成了“基础配置”。新的能力则是让你在 AI 时代的竞争力多了一个乘数。举个例子。你想给公司做一个内部知识库问答机器人。如果只知道“调用大模型 API 就能问答”那做出来的东西大概率是一个“ChatGPT 套壳”只能回答通用问题无法回答“公司报销流程是什么”“这个项目的部署文档在哪”。但如果你会拆解问题把知识库问答拆成内容入库、文档切分、向量化、召回、重排、生成答案这几个环节然后再结合 RAG 技术、向量数据库和 prompt 调优才能真正交付一个可用的产品。这里的差异不在于你会不会某一门语言而在于你能不能把 AI 能力嵌入到一个具体业务场景中。4. 从观点到实践五个具体动作知道“比技能更值钱的是判断力和上下文”还停留在认知层面。真正有价值的是把这个认知转化成日常开发中的具体动作。下面五个事情是目前技术环境下比较能检验个人竞争力的方向。4.1 把提示词当需求文档写很多人对提示词的理解是“一句话让 AI 干活”。真正高质量的提示词更像一份需求文档它包含角色设定、任务目标、输入格式、输出约束、边界条件和参考示例。你可以从今天开始做一个练习把自己平时发给 AI 的指令升级成结构化模板。比如你想让 AI 写一段 Java 代码不要只说“帮我写一个接口”而是明确说明技术栈、版本、异常处理方式、入参出参格式、代码风格要求。4.2 构建自己的知识库与上下文无论是个人笔记还是团队文档都可以用“上下文思维”重新组织。你的碎片笔记、收藏的文章、沉淀的复盘其实都是未来给 AI 使用的上下文素材。如果你想做个人知识助手那么数据清洗、文档切分、索引构建这些思路就是绕不开的。4.3 本地部署与隐私意识现在越来越多场景要求“数据不出内网”尤其是企业内部文档和用户隐私数据。这就要求开发者至少了解模型本地化部署的基本逻辑需要什么样的 GPU、用哪种推理框架、模型怎么量化、接口怎么封装。了解这些不是为了让你成为算法工程师而是让你在 AI 落地方案选型时不会只会说“叫外部 API”这一个选项。4.4 建立评测习惯对抗 AI 幻觉AI 应用上线前的评测很大程度上决定了它在生产环境里能不能真正用起来。你会不会构造一个几十条问题的评测集你会不会统计不同 prompt 版本的正确率你会不会针对失败的 bad case 做分析这些能力一旦建立你和普通“调 API 的人”之间就拉开了差距。4.5 训练跨领域迁移能力AI 时代最大的红利来自把某个领域的方法迁移到另一个领域。比如你懂数据库索引就能理解向量检索的索引结构你懂缓存就能理解模型输出缓存的设计你懂事务就能理解 Agent 任务链的失败回滚。这种迁移能力会让你的技术积累在 AI 时代产生复利效应。5. 完整示例从提示词到最小 AI 应用工程闭环说了这么多观念下面用一个具体的例子把它串起来。假设我们要做一个内部技术文档问答助手。它解决的问题是让新员工把“问老同事”变成“问文档助手”。这个例子里我们不会依赖特定的商业产品而是演示一套可以跑通的工程思路。5.1 示例一结构化提示词模板先不说代码先写一个高质量的提示词模板。把它保存为prompt_template.md# 角色 你是一个企业内部文档问答助手只依据提供的文档内容回答问题。 # 任务 用户会提交一个问题你需要根据检索到的文档内容生成回答。 # 输入格式 用户输入 问题{question} 参考资料 {context} # 输出要求 1. 如果参考资料能回答问题用清晰的条目输出答案。 2. 如果参考资料不能回答问题直接回答“当前文档中没有相关内容”。 3. 不要编造文档中不存在的结论。 4. 引用来源时标注参考文档的标题或编号。这个模板的价值在于第一它明确限制了模型的角色避免它“自由发挥”第二它要求模型在信息不足时承认不知道显著降低幻觉第三它强制要求引用来源方便使用方核验。你可能会觉得这很简单。但实际效果往往比“帮我查一下文档里的内容”这种模糊指令好很多。因为模型明确知道自己的信息边界在哪里。5.2 示例二Python 调用大模型 API 并注入上下文下面是一个demo_query.py示例用最通用的 HTTP 请求调用兼容 OpenAI 格式的模型接口。这样做的好处是不绑定特定 SDK本地模型服务和云端 API 都能用。# 文件路径demo_query.py import os import requests API_URL os.getenv(LLM_API_URL, http://localhost:8000/v1/chat/completions) API_KEY os.getenv(LLM_API_KEY, EMPTY) def build_prompt(question: str, context: str) - str: 根据模板生成最终发送给模型的 prompt with open(prompt_template.md, r, encodingutf-8) as f: template f.read() return template.replace({question}, question).replace({context}, context) def query_model(prompt: str) - str: 调用模型服务返回回答内容 payload { model: qwen2.5:7b, # 模型名称以你实际部署的模型为准 messages: [ {role: system, content: 你是一个严谨的企业文档问答助手。}, {role: user, content: prompt}, ], temperature: 0.1, } headers {Authorization: fBearer {API_KEY}} resp requests.post(API_URL, jsonpayload, headersheaders, timeout120) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: question 新员工的报销流程是什么 context 标题员工报销流程 内容员工在财务系统提交报销单上传发票截图部门主管审批后 财务在三个工作日内完成打款。新员工入职后需要在人事系统完成银行信息登记。 prompt build_prompt(question, context) answer query_model(prompt) print(问题, question) print(回答, answer)这段代码里有几个值得注意的工程细节。temperature被设置成了0.1因为文档问答追求确定性不希望模型自由发挥。API_URL可以指向本地推理服务也可以指向云端方便在不同环境切换。prompt 模板与代码分离后续调优 prompt 时不需要改代码。5.3 示例三最小可运行的检索增强实现上面的例子中context是手动填的。真实场景里文档会有很多篇你需要从里面找到最相关的一段。下面是一个不依赖外部向量数据库的最小检索示例用 TF-IDF 和余弦相似度实现一个简单的召回逻辑。生产环境建议用向量数据库替换但理解这个最小逻辑有助于理解 RAG 的原理。# 文件路径simple_retriever.py from collections import Counter import math import re def tokenize(text: str) - list[str]: 简单中文分词按非中文字符切分保留中文片段 text text.lower() # 这里仅做演示生产环境建议用 jieba 等分词库 parts re.findall(r[\u4e00-\u9fa5]|[a-z0-9], text) tokens [] for part in parts: if re.match(r[\u4e00-\u9fa5], part): # 对中文做简单的二元切分模拟词边界 for i in range(len(part) - 1): tokens.append(part[i:i 2]) else: tokens.append(part) return tokens def tf(text: str) - Counter: tokens tokenize(text) return Counter(tokens) def idf(docs: list[str]) - dict[str, float]: total len(docs) df: dict[str, int] {} for doc in docs: for term in set(tokenize(doc)): df[term] df.get(term, 0) 1 return {term: math.log((1 total) / (1 count)) 1 for term, count in df.items()} def cosine_similarity(vec1: Counter, vec2: Counter) - float: common set(vec1.keys()) set(vec2.keys()) dot sum(vec1[k] * vec2[k] for k in common) norm1 math.sqrt(sum(v * v for v in vec1.values())) norm2 math.sqrt(sum(v * v for v in vec2.values())) if norm1 0 or norm2 0: return 0.0 return dot / (norm1 * norm2) def retrieve(question: str, docs: list[str], top_k: int 1) - list[int]: doc_tfs [tf(doc) for doc in docs] idf_map idf(docs) q_tf tf(question) scores [] for doc_tf in doc_tfs: q_vec {term: q_tf[term] * idf_map.get(term, 1) for term in q_tf} d_vec {term: doc_tf[term] * idf_map.get(term, 1) for term in doc_tf} scores.append(cosine_similarity(Counter(q_vec), Counter(d_vec))) # 返回分数最高的 top_k 个文档下标 return sorted(range(len(scores)), keylambda i: scores[i], reverseTrue)[:top_k] if __name__ __main__: docs [ 员工报销流程员工在财务系统提交报销单上传发票截图主管审批后财务打款。, 入职流程新员工需要准备身份证、银行卡并在人事系统登记个人信息。, 休假制度员工请假需要提前一天在系统中提交申请部门负责人审批。, ] question 报销单在哪里提交 idx_list retrieve(question, docs) print(命中文档, [docs[i] for i in idx_list])运行这段代码预期输出是命中文档 [员工报销流程员工在财务系统提交报销单上传发票截图主管审批后财务打款。]这里面的分词逻辑非常简单只是用二元切分来模拟中文词边界。生产环境请使用成熟的分词工具。但你从这个最小实现里能理解 RAG 最关键的一环把用户的 query 和候选文档做相似度计算选出最相关的片段再交给大模型生成答案。5.4 示例四AI 输出评测脚本最后一个是评测脚本。当你有多个 prompt 模板或模型版本时用它可以快速对比效果。先准备一个eval_data.json[ { question: 报销需要上传什么附件, reference: 发票截图, min_length: 4 }, { question: 请假需要提前多久申请, reference: 提前一天, min_length: 4 } ]然后写一个简单的评测脚本# 文件路径eval_basic.py import json from demo_query import query_model def evaluate(): with open(eval_data.json, r, encodingutf-8) as f: cases json.load(f) hit 0 for case in cases: question case[question] answer query_model(question) # 评测规则答案包含参考关键词且长度不低于阈值 passed case[reference] in answer and len(answer) case[min_length] hit int(passed) print(f问题{question}) print(f回答{answer}) print(f通过{passed}\n) accuracy hit / len(cases) print(f总通过率{accuracy * 100:.2f}%) if __name__ __main__: evaluate()这个脚本虽然简陋但它是评测意识的最小体现。真正的生产环境评测要复杂得多会区分精确匹配、语义相似度、人工评估等多个维度。关键在于如果你连最小评测集都没有就无法判断一次 prompt 修改到底是变好还是变坏。6. 常见误区与排查思路下面整理一些 AI 时代技术人容易遇到的问题以及对应的排查思路。问题现象可能原因排查方式解决方案AI 回答与文档无关检索召回内容不准确打印检索到的文档片段检查切分粒度是否过细或过粗优化文档切分逻辑增加重排策略模型生成内容出现幻觉提示词缺少边界约束检查提示词是否明确要求“无法回答时说明不知道”在提示词中加入信息边界限制并降低 temperature不同请求结果不稳定温度参数过高或模型版本变化对比同一样例多次输出调低 temperature固定模型版本本地推理响应慢模型过大或未量化查看 GPU 显存占用和推理耗时换小模型或对模型做量化部署API 调用报错请求格式与接口不匹配查看错误码和返回体对照接口文档调整 messages、model 字段知识库匹配质量差文本分块没有语义边界检查切分位置是否有标题被拆散按标题、段落切分保留元数据权限问题导致越权数据权限没接入检索链路审查检索接口是否有人级权限过滤在检索前强制注入用户身份过滤条件在实际项目中最容易被忽视的其实是“权限问题”。很多团队的 RAG 系统上线后只关注回答准确率忘了做细粒度的权限控制。一个没有权限意识的检索系统可能会把 A 部门的人员信息回答给 B 部门的人。这个风险必须在一开始就纳入设计。7. 最佳实践与工程建议如果要把“AI 时代的能力”落到真实工程里下面这些经验值得参考。提示词与代码分离。不要把长提示词硬编码在业务代码里。用独立的模板文件、配置中心或提示词管理平台来管理让产品、测试甚至运营同学也能参与调优而不需要每次改代码发布。上下文先于模型。选大模型之前先问自己我的上下文数据是否准备好了文档清洗过没有有没有知识库的更新机制很多项目上线后效果差不是模型不够强而是给的上下文太弱。评测集要持续维护。每次修改 prompt、升级模型、调整切分策略都要跑一遍评测集记录通过率和 bad case。没有评测集的迭代都是感觉驱动很容易改回去。成本与延迟要提前估算。调用云端大模型 API 时需要注意 credits、token 用量和计费方式。如果是一个高频回复场景要设计输出缓存如果是内部高频问答要考虑本地部署的性价比。本地部署不是万能选项。本地部署能解决隐私问题但也会带来 GPU 资源、运维复杂度、模型更新延迟等问题。稳妥的做法是根据数据敏感度、调用频率、token 成本综合考虑而不是一上来就追求私有化。安全边界要早于功能上线。涉及内部数据、用户信息的 AI 应用必须做权限校验、prompt 注入防护和输出内容审计。AI Agent 如果具备调用外部工具的能力要给工具调用加“人工审核”或“最小权限”机制。8. 总结与后续学习方向回到开头那个问题AI 时代比技能更值钱的是什么从 Notion 产品负责人的判断到实际开发中的体验答案已经很清楚技能仍然必要但它不再是你职业护城河的终点。定义问题的能力、构建高质量上下文的能力、评判模型输出的能力才是 AI 时代真正稀缺的东西。对技术人员来说下一步的实践路径其实很明确。先尝试把日常与 AI 协作的指令结构化变成可复用的提示词模板再选择一个真实场景做一个带知识库的最小问答应用然后给这个应用设计一套最简单的评测集最后逐步把检索、权限、成本控制、效果分析这些工程细节补齐。整个过程不需要你成为算法专家但它会让你从一个“使用 AI 的人”变成一个“构建 AI 应用的人”。如果你的团队恰好也在做 AI 相关产品建议尽早建立三条规则所有模型输出必须可追溯所有提示词修改必须过评测集所有涉及用户数据的 AI 功能必须做权限设计。这三条规则不会让项目变慢但会让你少走很多弯路。