如果你去问一个刚接触 AI 两个月的朋友他多半会告诉你会写提示词就能变现。可真当你把一套需求丢给他让他稳定交付一个能用的结果时对方大概率会开始吞吞吐吐。原因很简单现在的 AI 工具越来越聪明但“聪明”是模型给的“能用”却要靠人来保证。Hacker News 上那个提问——Is there a marketable skill to using AI?——问到了点子上。市面上铺天盖地的教程都在教你怎么用 AI却很少有人认真回答一个问题当“使用 AI”本身不再是门槛时这项能力还值不值钱到底什么样的“会用 AI”才能变成别人愿意付费的技能我的判断是会问问题、会写提示词确实是一种能力但它离“可市场化”还有很长一段距离。可市场化的技能核心在于你能不能用 AI 稳定地交付确定的结果。这篇文章会从技能的定义说起拆解提示工程、Agent 工作流、模型评测和垂直业务落地的区别然后用一个完整示例说明如何把“会聊天”变成“能交付”最后给你一套适合当前环境的行动路径。1. 这个问题为什么值得认真回答先回答一个前置问题为什么“用 AI 的技能”需要被单独讨论过去我们说“技能”通常指某种工具的使用经验比如会用 Photoshop、会写 SQL、会配置 Nginx。这些技能之所以值钱是因为工具本身有学习曲线而且工具能产出的结果和操作者的水平高度相关。但 AI 不一样。大模型把自然语言变成了一种通用接口你不会写代码也能让它写诗、写文章、写 Python 脚本。学习曲线一下子被压得很低看起来谁都能用。但“看起来谁都能用”和“谁都能用好”是两回事。真正接触过生产环境的人都知道AI 输出质量极度不稳定。同一个提示词在同一个模型上两次结果可能完全不同同一个业务问题不同模型给出的答案深度和准确性也天差地别。知识库怎么组织上下文窗口怎么分配参数怎么调结果怎么校验这些都不是“问一句话”能解决的。还有一层原因值得注意AI 能力本身还在快速迭代。今天你掌握的某个模型的高阶用法下个版本发布后可能就过时了。如果把技能建立在“记住某个按钮、某个技巧”上这个技能就没有长期价值。真正能被市场认可的技能必须建立在模型底层原理和工程方法论之上而不是建立在某个版本的具体操作之上。所以这个问题值得认真回答不是因为它能帮你赚到钱而是因为它决定了你把学习时间花在哪里。如果你的目标是成为一个具备 AI 能力的工程师、产品经理或技术负责人你需要知道什么值得学、什么不值得学。2. 先厘清什么是“可市场化的技能”要判断“用 AI”能不能算可市场化的技能先要定义什么叫可市场化。我认为至少要满足三个条件第一可交付。技能的结果必须是一个别人能直接使用的东西比如一段可运行的程序、一份可发布的文案、一个能提升转化率的方案。不能只是“我知道怎么问 AI”。第二可评估。结果好坏有明确标准。是准确率高是质量稳定还是耗时更短如果好坏无法判断别人凭什么为你的技能付费。第三可复制。你今天能完成这个结果明天还能完成换个任务类型也能完成。靠撞运气得到的优秀输出不具备技能属性。从这个角度回头看普通用户“用 AI”和专业人士“用 AI”有本质区别。维度普通用户专业人士目的完成任务、获得答案交付可重复使用的结果方法临时提问、人工筛选结构化提示词 程序化调用 结果校验评估感觉差不多就行用指标衡量准确率、稳定性、成本可复制性不可复制每次重新想模板化、脚本化、可复用代价时间成本低质量波动大前期投入高后期收益稳定普通人用 AI 是“消费”模型的能力专业人士是在“生产”结果。消费和生产之间隔着一条完整的工程链路需求分析、任务拆解、提示词模板设计、代码接入、参数调优、结果解析、质量评估、异常处理。如果只把注意力放在提示词上做出来的东西依然只是“消费”只是消费得比普通人稍微好一点。正因如此我建议把“使用 AI”的技能拆成三层后面所有讨论都围绕这个模型展开第一层交互层。知道怎么向模型表达需求、怎么补充上下文、怎么约束输出。这是基础但不值钱。第二层工程层。能通过代码调用模型能处理输入输出能组建 Agent 工作流能设计评测方案。这一层开始有专业价值。第三层业务层。能把 AI 能力嵌入特定行业的具体流程能算清降本增效的账能处理边界和风险。这一层才是高价技能所在。越往上层越值钱也越依赖具体行业知识。提示词只是交互层的入门功夫真正的技能重心在工程层和业务层。3. 提示工程还值不值得学既然提示词只是交互层那提示工程是不是就不用学了也不是。它是一项必要的入门技能只是要分清哪些提示词技巧真正有用、哪些只是心理安慰。先说不值得学的东西各种“咒语式”的万能提示词。网上流传着大量“只要加上这句话AI 输出质量提升十倍”的模板比如“你是某领域的专家”“请一步步思考”“请用 Markdown 输出”。这些技巧有一定作用但作用非常有限。模型表现更多取决于你提供的信息质量和任务本身的难度而不是那句“魔法咒语”。值得学的是把需求转化成结构化表达的能力。举个例子如果直接问模型帮我写一个Python脚本处理CSV文件模型通常会给你一个能跑但未必符合需求的脚本。你需要追问一大堆问题CSV 有哪些列数据量多大需要处理哪些规则输出保存成什么格式性能和错误处理有什么要求这个问题看起来是提示词写得不好本质是需求理解不到位。真正好的提示词是把隐含的需求全部显性化。下面是一个对比同一需求两种问法版本 A 帮我分析一下用户评论的情绪。 版本 B 你是一名熟悉中文电商平台的文本分析助手。请分析下面的用户评论输出 JSON 格式结果。 输入数据 [ 物流很快但包装破损了, 商品质量不错客服态度很差, 第二次回购了依然满意 ] 要求 1. 对每条评论标注情绪positive、neutral、negative。 2. 标注情绪包含的方面维度物流、包装、商品质量、客服。 3. 只输出 JSON不要额外解释。 输出结构示例 { results: [ {text: 物流很快但包装破损了, sentiment: neutral, aspects: {物流: positive, 包装: negative}} ] }版本 B 之所以更可能产生高质量结果不是因为它加了“你是专家”而是因为它给出了明确的任务定义、输入格式、输出结构和示例。模型不知道你的数据库表结构不知道你的业务术语它只能根据你给的上下文推断。提示词工程的核心是沟通建模能力是管理者把需求说清楚的能力而不是话术。不过有一点要清醒即使提示词写得好也只能保证模型“理解了你想要什么”不能保证结果“一定是对”的。在关键生产流程里输出必须经过程序校验或人工抽查。这已经超出提示词本身进入工程层。4. 真正有市场价值的三个方向如果提示词只是基础那么什么方向的“用 AI”技能真正值钱结合当前 AI 应用开发的实际情况我认为有三个方向值得投入。4.1 模型选型与评测很多团队在引入 AI 时第一个问题不是“怎么写提示词”而是“该用哪个模型”。使用开源模型还是付费 API是追求速度还是追求效果是统一用一个模型还是按任务分模型这个决策看起来很轻实际上会直接影响成本、效果和开发周期。它需要一套可重复的评测方法选定测试集、定义评价指标、控制变量跑对比、统计结果并输出报告。如果你能建立一套针对具体业务的评测流程你就能帮团队或客户回答“每次模型升级后要不要切换”“某个垂类任务用哪个模型性价比最高”这些高频问题。这项工作比会写提示词值钱得多因为它是可复用的。评测脚本建立起来后每次模型版本更新、每次任务需求变化都可以重跑。它沉淀下来的是一套资产而不是一次性答案。4.2 Agent 与工作流工程化所谓 Agent简单理解是把大模型从“单次问答工具”变成“能自主完成任务的工作者”。它可以根据目标拆解步骤调用外部工具读取知识库执行程序然后根据中间结果调整下一步行动。真正有工程价值的地方不是搭一个花哨的 Agent Demo而是把多步任务编排成可靠工作流。这里涉及上下文管理、工具调用权限、失败重试、结果校验、安全边界等一系列工程细节。比如一个自动化客服 Agent它需要接收用户问题 - 判断是否触发人设 - 检索知识库 - 生成回复 - 检查是否包含敏感词 - 记录日志。每一步都可能出错每一步都要有兜底。能把这些环节设计清楚、跑得稳定的人交付的是整个系统而不是一句回答。4.3 垂直业务场景落地同一套大模型能力放在内容创作、法律文书、医疗辅助、教育培训、智能硬件等不同行业落地方式完全不同。垂直落地的核心不是模型有多强而是你懂不懂这个行业的真实流程。举个最典型的例子开发一个合同审查工具。看起来只需要把合同文字丢给大模型让它提取风险条款就行。但真实需求远不止这些合同文件有 PDF、扫描件、Word 各种格式需要预处理业务方需要的是“哪些条款偏离公司模板”而不是泛泛的“有哪些风险”敏感数据可能不能直接传给 API需要本地化部署或脱敏处理输出格式要能接入现有审批系统。这些工作任何一个都不是“会写提示词”能解决的。如果一个工程师能把大模型嵌入某个行业的老旧系统让原本需要人力处理几小时的工作变成自动化流程并且能证明质量达标、风险可控那这门技术就能卖出很好的价格。所以“用 AI 的技能”真正值钱的地方在于你能不能用它解决一个具体的、重复的、有成本和风险的问题。你能度量它带来的收益并且能承担结果的责任。5. 从“会用 AI”到“能交付”一个完整示例下面用一个具体场景把上面提到的三层技能串起来。假设你的任务是要做一个“批量生成产品卖点文案”的小工具。需求是输入商品的原始描述输出三条不同风格的卖点文案并按预设规则校验。首先看这个任务需要的环节。第一步把需求拆解成可执行步骤。第二步设计提示词模板。第三步写代码调用模型接口。第四步解析输出并校验。第五步记录日志和运行指标。任何一个环节缺失整个工具都无法在真实环境中使用。先看步骤一和步骤二。我们在文件里维护一个提示词模板而不是把提示词写死在代码里。这样做的好处是业务人员可以直接改模板不需要重新部署代码。# 文件路径prompts/selling_points.txt 你是一名电商文案专家。请根据商品描述生成 3 条卖点文案分别对应 1. 用户痛点导向强调商品解决什么问题。 2. 场景导向想象用户在什么场景下使用该商品。 3. 参数导向突出核心规格和优势。 商品描述 {{product_description}} 要求 - 每条文案不超过 50 字。 - 输出 JSON 格式键名为 style1、style2、style3。 - 不要输出其他解释。第三步写一个 Python 脚本调用模型接口。为了避免把 API Key 写进代码我们把它放到环境变量里。示例使用 openai 库调用 OpenAI 兼容的接口并设置了较低的温度让输出更稳定。# 文件路径src/generate_copy.py import os import json from openai import OpenAI client OpenAI( api_keyos.environ.get(OPENAI_API_KEY), base_urlos.environ.get(OPENAI_BASE_URL, None), # 使用兼容网关时配置 ) def load_prompt_template(file_path: str) - str: with open(file_path, r, encodingutf-8) as f: return f.read() def generate_copy(product_description: str) - dict: template load_prompt_template(prompts/selling_points.txt) prompt template.replace({{product_description}}, product_description) response client.chat.completions.create( modelos.environ.get(OPENAI_MODEL, gpt-4o-mini), temperature0.3, max_tokens600, messages[ {role: system, content: 你是电商文案助手只输出 JSON。}, {role: user, content: prompt}, ], ) content response.choices[0].message.content.strip() # 防御模型偶尔会输出 json 包裹先清理 if content.startswith(): content content.split(\n, 1)[1].rsplit(, 1)[0].strip() return json.loads(content) if __name__ __main__: product_desc 无线降噪耳机续航 30 小时支持主动降噪和蓝牙 5.3。 result generate_copy(product_desc) print(json.dumps(result, ensure_asciiFalse, indent2))第四步校验输出。大模型返回的 JSON 不一定符合预期不能直接把结果拿去用。这里需要一个简单的校验流程检查字段是否存在、文案长度是否超限。这一步往往是被初学者忽略的。你可能会想“模型一般不会出错吧”实际上只要长期跑批量任务你就会遇到吞字段、格式错误、内容超长等各种情况。没有校验生产环境就不可控。# 文件路径src/validate.py def validate_result(data: dict) - bool: required_keys {style1, style2, style3} if not required_keys.issubset(data.keys()): return False for key in required_keys: if not isinstance(data[key], str) or len(data[key]) 50: return False return True第五步记录日志。每次调用模型应该记录输入、输出、耗时、token 消耗方便后续统计成本和质量。这是一个很朴实但非常重要的工程习惯很多线上问题都是靠日志排查出来的。这个例子很简单但它已经包含了一个 AI 应用的最小闭环需求拆解、提示词模板化、代码接入、输出校验、日志记录。你能独立完成这个闭环并且保证它在每次运行中都稳定工作你就具备了一个可市场化的 AI 应用开发基础技能。6. 评估与迭代最容易忽略的核心环节很多人写完代码一看“能跑通”就结束了。但在真实交付里“能跑通”连起点都算不上。模型输出的质量波动很大今天这个场景效果好明天换一批数据可能就崩塌。所以你还需要一个评估环节这恰恰是最容易被忽略的。评估实践其实是这样的当你把一批测试数据准备好定义好什么算好、什么算坏然后用脚本跑批对比不同提示词、不同模型、不同参数的表现再把结果整理成报告或表格。如果你是在团队里工作这份评估报告就是你做技术决策的依据也是和业务方沟通的通用语言。一个最小可用的评测脚本可以长这样。这里用一个小批量样例人工标注期望方向然后统计“第一次输出是否合格”。# 文件路径evaluate/evaluate_copy.py import json from generate_copy import generate_copy test_cases [ { input: 无线降噪耳机续航 30 小时, expect_keywords: [降噪, 续航], }, { input: 便携咖啡机15 分钟萃取, expect_keywords: [便携, 咖啡], }, ] def evaluate(): results [] for case in test_cases: try: output generate_copy(case[input]) valid validate_result(output) keyword_hit any( kw in output[style1] or kw in output[style2] or kw in output[style3] for kw in case[expect_keywords] ) results.append({case: case[input], valid: valid, keyword_hit: keyword_hit, output: output}) except Exception as exc: results.append({case: case[input], error: str(exc)}) return results if __name__ __main__: results evaluate() print(json.dumps(results, ensure_asciiFalse, indent2))这个脚本非常粗糙但已经具备评估的骨架固定输入、定义标准、记录结果。真实场景里你还需要考虑人工抽检比例、成本上限、延迟指标等。能持续地做评估和迭代你的方案才可能从“偶尔好用”进化到“稳定可用”。这也解释了为什么“用 AI 的技能”很难被单一课程教会。它不是一套固定操作步骤而是一套在迭代中不断调整的方法论。模型在变、任务在变、评估标准也在变只有具备“快速建立评测体系”能力的人才能在每个新项目里快速找到效果最优解。7. 常见误区为什么很多人学了很久仍然无法交付我观察到很多开发者学 AI 应用开发投入时间不少但一直停留在“会聊天”的阶段。底下这些误区是比较常见的你可以对照着看看自己有没有踩中。误区表现后果把聊天当交付只在网页对话框里试用模型从不写代码无法处理批量任务无法对接系统只学提示词不学工程把全部精力花在提示词技巧上忽略输出校验、异常处理一次能跑通长期不稳定无法上线忽略模型差异不管任务类型只用同一个模型效果或成本不是最优团队难迭代过度使用 Agent什么任务都堆 Agent不考虑可控性流程复杂出错后难排查不问数据安全边界把机密数据直接传给外部 API合规风险对企业是致命问题不做评估凭“感觉差不多”判断效果无法证明收益也难以说服业务方这里我特别想展开说一下“过度使用 Agent”的问题。现在讨论 Agent 的人很多不少同学跃跃欲试拿到任务就设计一个“多智能体协作系统”。但实际工程里能用一个简单的函数加一个模型调用解决的问题绝不应该为了炫技去搭一套复杂流程。Agent 带来的额外不确定性、调试成本和 token 消耗是很高的。更稳妥的做法是先尝试最简单方案只有当任务确实需要多步推理、多个工具组合时才逐步引入 Agent 机制并且每一步都要有权限边界和失败重试逻辑。数据安全边界也是一个容易被忽视的坑。调用外部模型 API 时要确认当前数据是否可以出域是否需要对敏感字段做脱敏处理。如果数据合规约束很强可能要考虑本地部署开源模型而不是直接调用在线服务。这不是“会不会写代码”的问题而是责任心的问题。一个交付给生产系统的 AI 方案如果没有把安全和合规考虑进去迟早会带来大麻烦。8. 现在应该怎么开始积累 AI 技能聊了这么多落到最实际的问题现在开始应该怎么积累“可市场化”的 AI 技能我的建议不是再囤一堆课程而是直接进入一个小的完整项目在真实约束里把工程链路走通。第一步选一个频率高、重复度高的个人任务比如周报整理、会议纪要、价格监控、素材收集。先观察人类处理这个任务要几步再思考模型能替代哪几步。然后按第五节的思路写提示词模板写脚本调用 API解析结果记录日志。不要追求一步到位先把最简版本跑起来。第二步建立自己的评估集。把 10 到 20 个典型输入保存下来人工标注理想输出的关键要素。每次换模型、换提示词、换参数都在这套评估集上跑一遍记录效果变化。这个小动作会逼你把“感觉”变成“数据”。第三步把评估结果沉淀成文档。很多人学 AI 只记笔记不记数据。如果你能积累一份“这个任务在模型 A 上准确率如何、在模型 B 上成本如何”的对比表你在这个领域就已经超过大多数竞争者了。第四步把项目经验整理成可展示的案例。在简历或个人网站上不要写“熟悉提示词工程”而要写“开发了一个批量文案生成工具日均处理 500 条商品数据通过结构化校验和评测迭代将输出合格率从 70% 提升到 95%”。哪怕这个数字是来自你自建的小测试集它也比“会写提示词”更有说服力。还要养成一个习惯持续跟进模型迭代和开源工具变化。大模型领域变化快但底层的方法论是稳的比如如何拆任务、如何评测、如何做工程兜底。今天你掌握的这套流程换一个模型一样能用。9. 总结AI 技能的本质是“交付确定性”回顾 HN 上的那个问题我想你已经有了自己的答案。会“用 AI”当然可以成为技能但真正能拿到市场上换取回报的不是你写了多少漂亮的提示词也不是你追上了多少新功能而是你能不能稳定地输出别人需要的结果。可市场化的 AI 技能本质上是“交付确定性”的能力。它由一系列工程习惯构成需求拆解、提示词模板化、代码接入、输出校验、日志记录、评估迭代、安全边界控制。每一个环节单独拿出来都不难但组合在一起就把一次性的“灵光一现”变成了可复用的生产能力。如果你刚开始接触可以从第五节的示例入手把它改成你自己的任务场景。不要急着学太多新概念先把最小闭环跑通亲手感受一次“模型输出不可控”的麻烦再考虑引入评测、Agent 或更复杂的架构。这个过程中的每一次试错都会比十篇教程更值钱。更重要的是保持对人本身价值的清醒认识。模型负责理解语言、生成内容但决策、评估、风险控制仍然是人来负责。真正稀缺的从来不是“会用 AI”的人而是懂业务、有工程判断力、能对 AI 输出承担结果责任的人。往这个方向积累你的技能就不会被模型迭代淘汰反而会伴随工具升级越来越贵。 从提示词到工程化：如何让AI技能具备可交付价值
如果你去问一个刚接触 AI 两个月的朋友他多半会告诉你会写提示词就能变现。可真当你把一套需求丢给他让他稳定交付一个能用的结果时对方大概率会开始吞吞吐吐。原因很简单现在的 AI 工具越来越聪明但“聪明”是模型给的“能用”却要靠人来保证。Hacker News 上那个提问——Is there a marketable skill to using AI?——问到了点子上。市面上铺天盖地的教程都在教你怎么用 AI却很少有人认真回答一个问题当“使用 AI”本身不再是门槛时这项能力还值不值钱到底什么样的“会用 AI”才能变成别人愿意付费的技能我的判断是会问问题、会写提示词确实是一种能力但它离“可市场化”还有很长一段距离。可市场化的技能核心在于你能不能用 AI 稳定地交付确定的结果。这篇文章会从技能的定义说起拆解提示工程、Agent 工作流、模型评测和垂直业务落地的区别然后用一个完整示例说明如何把“会聊天”变成“能交付”最后给你一套适合当前环境的行动路径。1. 这个问题为什么值得认真回答先回答一个前置问题为什么“用 AI 的技能”需要被单独讨论过去我们说“技能”通常指某种工具的使用经验比如会用 Photoshop、会写 SQL、会配置 Nginx。这些技能之所以值钱是因为工具本身有学习曲线而且工具能产出的结果和操作者的水平高度相关。但 AI 不一样。大模型把自然语言变成了一种通用接口你不会写代码也能让它写诗、写文章、写 Python 脚本。学习曲线一下子被压得很低看起来谁都能用。但“看起来谁都能用”和“谁都能用好”是两回事。真正接触过生产环境的人都知道AI 输出质量极度不稳定。同一个提示词在同一个模型上两次结果可能完全不同同一个业务问题不同模型给出的答案深度和准确性也天差地别。知识库怎么组织上下文窗口怎么分配参数怎么调结果怎么校验这些都不是“问一句话”能解决的。还有一层原因值得注意AI 能力本身还在快速迭代。今天你掌握的某个模型的高阶用法下个版本发布后可能就过时了。如果把技能建立在“记住某个按钮、某个技巧”上这个技能就没有长期价值。真正能被市场认可的技能必须建立在模型底层原理和工程方法论之上而不是建立在某个版本的具体操作之上。所以这个问题值得认真回答不是因为它能帮你赚到钱而是因为它决定了你把学习时间花在哪里。如果你的目标是成为一个具备 AI 能力的工程师、产品经理或技术负责人你需要知道什么值得学、什么不值得学。2. 先厘清什么是“可市场化的技能”要判断“用 AI”能不能算可市场化的技能先要定义什么叫可市场化。我认为至少要满足三个条件第一可交付。技能的结果必须是一个别人能直接使用的东西比如一段可运行的程序、一份可发布的文案、一个能提升转化率的方案。不能只是“我知道怎么问 AI”。第二可评估。结果好坏有明确标准。是准确率高是质量稳定还是耗时更短如果好坏无法判断别人凭什么为你的技能付费。第三可复制。你今天能完成这个结果明天还能完成换个任务类型也能完成。靠撞运气得到的优秀输出不具备技能属性。从这个角度回头看普通用户“用 AI”和专业人士“用 AI”有本质区别。维度普通用户专业人士目的完成任务、获得答案交付可重复使用的结果方法临时提问、人工筛选结构化提示词 程序化调用 结果校验评估感觉差不多就行用指标衡量准确率、稳定性、成本可复制性不可复制每次重新想模板化、脚本化、可复用代价时间成本低质量波动大前期投入高后期收益稳定普通人用 AI 是“消费”模型的能力专业人士是在“生产”结果。消费和生产之间隔着一条完整的工程链路需求分析、任务拆解、提示词模板设计、代码接入、参数调优、结果解析、质量评估、异常处理。如果只把注意力放在提示词上做出来的东西依然只是“消费”只是消费得比普通人稍微好一点。正因如此我建议把“使用 AI”的技能拆成三层后面所有讨论都围绕这个模型展开第一层交互层。知道怎么向模型表达需求、怎么补充上下文、怎么约束输出。这是基础但不值钱。第二层工程层。能通过代码调用模型能处理输入输出能组建 Agent 工作流能设计评测方案。这一层开始有专业价值。第三层业务层。能把 AI 能力嵌入特定行业的具体流程能算清降本增效的账能处理边界和风险。这一层才是高价技能所在。越往上层越值钱也越依赖具体行业知识。提示词只是交互层的入门功夫真正的技能重心在工程层和业务层。3. 提示工程还值不值得学既然提示词只是交互层那提示工程是不是就不用学了也不是。它是一项必要的入门技能只是要分清哪些提示词技巧真正有用、哪些只是心理安慰。先说不值得学的东西各种“咒语式”的万能提示词。网上流传着大量“只要加上这句话AI 输出质量提升十倍”的模板比如“你是某领域的专家”“请一步步思考”“请用 Markdown 输出”。这些技巧有一定作用但作用非常有限。模型表现更多取决于你提供的信息质量和任务本身的难度而不是那句“魔法咒语”。值得学的是把需求转化成结构化表达的能力。举个例子如果直接问模型帮我写一个Python脚本处理CSV文件模型通常会给你一个能跑但未必符合需求的脚本。你需要追问一大堆问题CSV 有哪些列数据量多大需要处理哪些规则输出保存成什么格式性能和错误处理有什么要求这个问题看起来是提示词写得不好本质是需求理解不到位。真正好的提示词是把隐含的需求全部显性化。下面是一个对比同一需求两种问法版本 A 帮我分析一下用户评论的情绪。 版本 B 你是一名熟悉中文电商平台的文本分析助手。请分析下面的用户评论输出 JSON 格式结果。 输入数据 [ 物流很快但包装破损了, 商品质量不错客服态度很差, 第二次回购了依然满意 ] 要求 1. 对每条评论标注情绪positive、neutral、negative。 2. 标注情绪包含的方面维度物流、包装、商品质量、客服。 3. 只输出 JSON不要额外解释。 输出结构示例 { results: [ {text: 物流很快但包装破损了, sentiment: neutral, aspects: {物流: positive, 包装: negative}} ] }版本 B 之所以更可能产生高质量结果不是因为它加了“你是专家”而是因为它给出了明确的任务定义、输入格式、输出结构和示例。模型不知道你的数据库表结构不知道你的业务术语它只能根据你给的上下文推断。提示词工程的核心是沟通建模能力是管理者把需求说清楚的能力而不是话术。不过有一点要清醒即使提示词写得好也只能保证模型“理解了你想要什么”不能保证结果“一定是对”的。在关键生产流程里输出必须经过程序校验或人工抽查。这已经超出提示词本身进入工程层。4. 真正有市场价值的三个方向如果提示词只是基础那么什么方向的“用 AI”技能真正值钱结合当前 AI 应用开发的实际情况我认为有三个方向值得投入。4.1 模型选型与评测很多团队在引入 AI 时第一个问题不是“怎么写提示词”而是“该用哪个模型”。使用开源模型还是付费 API是追求速度还是追求效果是统一用一个模型还是按任务分模型这个决策看起来很轻实际上会直接影响成本、效果和开发周期。它需要一套可重复的评测方法选定测试集、定义评价指标、控制变量跑对比、统计结果并输出报告。如果你能建立一套针对具体业务的评测流程你就能帮团队或客户回答“每次模型升级后要不要切换”“某个垂类任务用哪个模型性价比最高”这些高频问题。这项工作比会写提示词值钱得多因为它是可复用的。评测脚本建立起来后每次模型版本更新、每次任务需求变化都可以重跑。它沉淀下来的是一套资产而不是一次性答案。4.2 Agent 与工作流工程化所谓 Agent简单理解是把大模型从“单次问答工具”变成“能自主完成任务的工作者”。它可以根据目标拆解步骤调用外部工具读取知识库执行程序然后根据中间结果调整下一步行动。真正有工程价值的地方不是搭一个花哨的 Agent Demo而是把多步任务编排成可靠工作流。这里涉及上下文管理、工具调用权限、失败重试、结果校验、安全边界等一系列工程细节。比如一个自动化客服 Agent它需要接收用户问题 - 判断是否触发人设 - 检索知识库 - 生成回复 - 检查是否包含敏感词 - 记录日志。每一步都可能出错每一步都要有兜底。能把这些环节设计清楚、跑得稳定的人交付的是整个系统而不是一句回答。4.3 垂直业务场景落地同一套大模型能力放在内容创作、法律文书、医疗辅助、教育培训、智能硬件等不同行业落地方式完全不同。垂直落地的核心不是模型有多强而是你懂不懂这个行业的真实流程。举个最典型的例子开发一个合同审查工具。看起来只需要把合同文字丢给大模型让它提取风险条款就行。但真实需求远不止这些合同文件有 PDF、扫描件、Word 各种格式需要预处理业务方需要的是“哪些条款偏离公司模板”而不是泛泛的“有哪些风险”敏感数据可能不能直接传给 API需要本地化部署或脱敏处理输出格式要能接入现有审批系统。这些工作任何一个都不是“会写提示词”能解决的。如果一个工程师能把大模型嵌入某个行业的老旧系统让原本需要人力处理几小时的工作变成自动化流程并且能证明质量达标、风险可控那这门技术就能卖出很好的价格。所以“用 AI 的技能”真正值钱的地方在于你能不能用它解决一个具体的、重复的、有成本和风险的问题。你能度量它带来的收益并且能承担结果的责任。5. 从“会用 AI”到“能交付”一个完整示例下面用一个具体场景把上面提到的三层技能串起来。假设你的任务是要做一个“批量生成产品卖点文案”的小工具。需求是输入商品的原始描述输出三条不同风格的卖点文案并按预设规则校验。首先看这个任务需要的环节。第一步把需求拆解成可执行步骤。第二步设计提示词模板。第三步写代码调用模型接口。第四步解析输出并校验。第五步记录日志和运行指标。任何一个环节缺失整个工具都无法在真实环境中使用。先看步骤一和步骤二。我们在文件里维护一个提示词模板而不是把提示词写死在代码里。这样做的好处是业务人员可以直接改模板不需要重新部署代码。# 文件路径prompts/selling_points.txt 你是一名电商文案专家。请根据商品描述生成 3 条卖点文案分别对应 1. 用户痛点导向强调商品解决什么问题。 2. 场景导向想象用户在什么场景下使用该商品。 3. 参数导向突出核心规格和优势。 商品描述 {{product_description}} 要求 - 每条文案不超过 50 字。 - 输出 JSON 格式键名为 style1、style2、style3。 - 不要输出其他解释。第三步写一个 Python 脚本调用模型接口。为了避免把 API Key 写进代码我们把它放到环境变量里。示例使用 openai 库调用 OpenAI 兼容的接口并设置了较低的温度让输出更稳定。# 文件路径src/generate_copy.py import os import json from openai import OpenAI client OpenAI( api_keyos.environ.get(OPENAI_API_KEY), base_urlos.environ.get(OPENAI_BASE_URL, None), # 使用兼容网关时配置 ) def load_prompt_template(file_path: str) - str: with open(file_path, r, encodingutf-8) as f: return f.read() def generate_copy(product_description: str) - dict: template load_prompt_template(prompts/selling_points.txt) prompt template.replace({{product_description}}, product_description) response client.chat.completions.create( modelos.environ.get(OPENAI_MODEL, gpt-4o-mini), temperature0.3, max_tokens600, messages[ {role: system, content: 你是电商文案助手只输出 JSON。}, {role: user, content: prompt}, ], ) content response.choices[0].message.content.strip() # 防御模型偶尔会输出 json 包裹先清理 if content.startswith(): content content.split(\n, 1)[1].rsplit(, 1)[0].strip() return json.loads(content) if __name__ __main__: product_desc 无线降噪耳机续航 30 小时支持主动降噪和蓝牙 5.3。 result generate_copy(product_desc) print(json.dumps(result, ensure_asciiFalse, indent2))第四步校验输出。大模型返回的 JSON 不一定符合预期不能直接把结果拿去用。这里需要一个简单的校验流程检查字段是否存在、文案长度是否超限。这一步往往是被初学者忽略的。你可能会想“模型一般不会出错吧”实际上只要长期跑批量任务你就会遇到吞字段、格式错误、内容超长等各种情况。没有校验生产环境就不可控。# 文件路径src/validate.py def validate_result(data: dict) - bool: required_keys {style1, style2, style3} if not required_keys.issubset(data.keys()): return False for key in required_keys: if not isinstance(data[key], str) or len(data[key]) 50: return False return True第五步记录日志。每次调用模型应该记录输入、输出、耗时、token 消耗方便后续统计成本和质量。这是一个很朴实但非常重要的工程习惯很多线上问题都是靠日志排查出来的。这个例子很简单但它已经包含了一个 AI 应用的最小闭环需求拆解、提示词模板化、代码接入、输出校验、日志记录。你能独立完成这个闭环并且保证它在每次运行中都稳定工作你就具备了一个可市场化的 AI 应用开发基础技能。6. 评估与迭代最容易忽略的核心环节很多人写完代码一看“能跑通”就结束了。但在真实交付里“能跑通”连起点都算不上。模型输出的质量波动很大今天这个场景效果好明天换一批数据可能就崩塌。所以你还需要一个评估环节这恰恰是最容易被忽略的。评估实践其实是这样的当你把一批测试数据准备好定义好什么算好、什么算坏然后用脚本跑批对比不同提示词、不同模型、不同参数的表现再把结果整理成报告或表格。如果你是在团队里工作这份评估报告就是你做技术决策的依据也是和业务方沟通的通用语言。一个最小可用的评测脚本可以长这样。这里用一个小批量样例人工标注期望方向然后统计“第一次输出是否合格”。# 文件路径evaluate/evaluate_copy.py import json from generate_copy import generate_copy test_cases [ { input: 无线降噪耳机续航 30 小时, expect_keywords: [降噪, 续航], }, { input: 便携咖啡机15 分钟萃取, expect_keywords: [便携, 咖啡], }, ] def evaluate(): results [] for case in test_cases: try: output generate_copy(case[input]) valid validate_result(output) keyword_hit any( kw in output[style1] or kw in output[style2] or kw in output[style3] for kw in case[expect_keywords] ) results.append({case: case[input], valid: valid, keyword_hit: keyword_hit, output: output}) except Exception as exc: results.append({case: case[input], error: str(exc)}) return results if __name__ __main__: results evaluate() print(json.dumps(results, ensure_asciiFalse, indent2))这个脚本非常粗糙但已经具备评估的骨架固定输入、定义标准、记录结果。真实场景里你还需要考虑人工抽检比例、成本上限、延迟指标等。能持续地做评估和迭代你的方案才可能从“偶尔好用”进化到“稳定可用”。这也解释了为什么“用 AI 的技能”很难被单一课程教会。它不是一套固定操作步骤而是一套在迭代中不断调整的方法论。模型在变、任务在变、评估标准也在变只有具备“快速建立评测体系”能力的人才能在每个新项目里快速找到效果最优解。7. 常见误区为什么很多人学了很久仍然无法交付我观察到很多开发者学 AI 应用开发投入时间不少但一直停留在“会聊天”的阶段。底下这些误区是比较常见的你可以对照着看看自己有没有踩中。误区表现后果把聊天当交付只在网页对话框里试用模型从不写代码无法处理批量任务无法对接系统只学提示词不学工程把全部精力花在提示词技巧上忽略输出校验、异常处理一次能跑通长期不稳定无法上线忽略模型差异不管任务类型只用同一个模型效果或成本不是最优团队难迭代过度使用 Agent什么任务都堆 Agent不考虑可控性流程复杂出错后难排查不问数据安全边界把机密数据直接传给外部 API合规风险对企业是致命问题不做评估凭“感觉差不多”判断效果无法证明收益也难以说服业务方这里我特别想展开说一下“过度使用 Agent”的问题。现在讨论 Agent 的人很多不少同学跃跃欲试拿到任务就设计一个“多智能体协作系统”。但实际工程里能用一个简单的函数加一个模型调用解决的问题绝不应该为了炫技去搭一套复杂流程。Agent 带来的额外不确定性、调试成本和 token 消耗是很高的。更稳妥的做法是先尝试最简单方案只有当任务确实需要多步推理、多个工具组合时才逐步引入 Agent 机制并且每一步都要有权限边界和失败重试逻辑。数据安全边界也是一个容易被忽视的坑。调用外部模型 API 时要确认当前数据是否可以出域是否需要对敏感字段做脱敏处理。如果数据合规约束很强可能要考虑本地部署开源模型而不是直接调用在线服务。这不是“会不会写代码”的问题而是责任心的问题。一个交付给生产系统的 AI 方案如果没有把安全和合规考虑进去迟早会带来大麻烦。8. 现在应该怎么开始积累 AI 技能聊了这么多落到最实际的问题现在开始应该怎么积累“可市场化”的 AI 技能我的建议不是再囤一堆课程而是直接进入一个小的完整项目在真实约束里把工程链路走通。第一步选一个频率高、重复度高的个人任务比如周报整理、会议纪要、价格监控、素材收集。先观察人类处理这个任务要几步再思考模型能替代哪几步。然后按第五节的思路写提示词模板写脚本调用 API解析结果记录日志。不要追求一步到位先把最简版本跑起来。第二步建立自己的评估集。把 10 到 20 个典型输入保存下来人工标注理想输出的关键要素。每次换模型、换提示词、换参数都在这套评估集上跑一遍记录效果变化。这个小动作会逼你把“感觉”变成“数据”。第三步把评估结果沉淀成文档。很多人学 AI 只记笔记不记数据。如果你能积累一份“这个任务在模型 A 上准确率如何、在模型 B 上成本如何”的对比表你在这个领域就已经超过大多数竞争者了。第四步把项目经验整理成可展示的案例。在简历或个人网站上不要写“熟悉提示词工程”而要写“开发了一个批量文案生成工具日均处理 500 条商品数据通过结构化校验和评测迭代将输出合格率从 70% 提升到 95%”。哪怕这个数字是来自你自建的小测试集它也比“会写提示词”更有说服力。还要养成一个习惯持续跟进模型迭代和开源工具变化。大模型领域变化快但底层的方法论是稳的比如如何拆任务、如何评测、如何做工程兜底。今天你掌握的这套流程换一个模型一样能用。9. 总结AI 技能的本质是“交付确定性”回顾 HN 上的那个问题我想你已经有了自己的答案。会“用 AI”当然可以成为技能但真正能拿到市场上换取回报的不是你写了多少漂亮的提示词也不是你追上了多少新功能而是你能不能稳定地输出别人需要的结果。可市场化的 AI 技能本质上是“交付确定性”的能力。它由一系列工程习惯构成需求拆解、提示词模板化、代码接入、输出校验、日志记录、评估迭代、安全边界控制。每一个环节单独拿出来都不难但组合在一起就把一次性的“灵光一现”变成了可复用的生产能力。如果你刚开始接触可以从第五节的示例入手把它改成你自己的任务场景。不要急着学太多新概念先把最小闭环跑通亲手感受一次“模型输出不可控”的麻烦再考虑引入评测、Agent 或更复杂的架构。这个过程中的每一次试错都会比十篇教程更值钱。更重要的是保持对人本身价值的清醒认识。模型负责理解语言、生成内容但决策、评估、风险控制仍然是人来负责。真正稀缺的从来不是“会用 AI”的人而是懂业务、有工程判断力、能对 AI 输出承担结果责任的人。往这个方向积累你的技能就不会被模型迭代淘汰反而会伴随工具升级越来越贵。