半夜三点我还在跟一个 system prompt 较劲。模型输出偶尔会冒出一句“我不确定”我加了一句“必须给出确定答案”结果它开始频繁编数据我又补上“不知道就如实说”再后来它变得过于保守我继续加“在合理范围内适当推测”。那个文件越改越长最后膨胀到三千多字而输出质量并没有变得更好——这种循环我持续了将近两年。现在回过头看我最后一次认真修改那套 prompt 体系已经是将近一年前的事了。中间模型升级过三次业务场景换了两轮那些当年熬夜调出来的“精密提示词”大部分并没有失效也没有被淘汰而是安安静静地躺在资产管理表里继续稳定产出。我这一年里几乎没再碰它们顶多半年做一次健康检查。从一个把 prompt 当艺术品反复打磨的人变成一个“一年不维护”的懒人博主靠的不是偷懒而是把 AI 资产真正当作资产来管理。这篇内容就是想把这 3 年的完整过程拆开讲清楚什么算 AI 资产、为什么过度调优反而是负债、我怎么做资产审计、以及那份让我摆脱“prompt 焦虑”的自检清单。1. 先给“AI 资产”画个清晰边界聊审计之前得先明确我们到底在审什么。很多人一说 AI 资产就想到 prompt这太窄了。我在第二年做整理的时候发现真正的 AI 资产不只是“写给模型看的那段话”还包括所有让模型稳定输出的配套工程。结合我自己的项目和见到的团队案例我习惯把个人或小团队的 AI 资产分成三层。1.1 直接资产prompt、模板与配置这是最表层、也最容易被过度投入的部分。包括 system prompt、few-shot 示例、输出格式模板、温度采样参数组合、工具调用的 function description以及现在越来越常见的 agent 配置文件。我见过不少人的“资产库”里躺着一堆几百行的个人 prompt但真正会反复复用的反而是那种短小精悍、结构固定的模板。比如客服分类提示词、内容摘要模板、SQL 生成模板——这些模板的价值不在于“妙笔生花”而在于它们经过了足够多样本的验证输出稳定边界行为可预期。所以我在审计时对直接资产的第一判断标准不是“够不够惊艳”而是“换了模型版本还能不能跑”。如果一个 prompt 强依赖某个模型的特殊行为习惯比如必须威胁 GPT 说“否则扣你电费”才给正确答案那它更像是一笔受制于人的负债而不是资产。1.2 支撑资产知识库、评测集与工作流第二层容易被忽略但恰恰是“一年不维护”能成立的关键。支撑资产包括三块知识库与 RAG 配置文档切片策略、向量检索的 top-k 设置、召回排序的规则、提示词与检索结果的拼接方式。评测集一组标准输入和期望输出对用来验证 prompt 修改是否引入回归。这比任何“精心调教”都重要。工作流把多步 LLM 调用串起来的逻辑比如先分类再抽取后校验的 pipeline以及异常处理、重试策略、输出校验规则。我 2023 年调 prompt 纯靠感觉改一句看一次效果觉得“好多了”就保存。后来发现这种直觉不可靠——今天觉得好的改动明天换个输入就崩。真正的转折点是我花了两个下午搭了一套最小评测集150 条真实业务输入覆盖常规、边界、模糊、无解四类。从那以后每次 prompt 改动都跑一遍回归用数据说话心态立刻就稳了。支撑资产的意义在于它让 prompt 修改变成可度量的工程行为而不是玄学手感。一旦有了评测集你自然会减少无畏的反复试错这也是我后来能“不维护”的底气来源。1.3 隐形资产经验、规范与判断第三层最虚但也最值钱。它指你脑子里的那套“什么时候该碰 prompt、什么时候不该碰”的判断标准包括变更规范改动 prompt 前必须过一遍评测集修改后必须记录 diff。场景选择经验什么任务适合纯 prompt什么任务必须上 RAG什么任务压根不该用 LLM。成本意识对 token 消耗、延迟、模型升级风险有敏感的预估能力。别小看这一层。它不会出现在任何目录里但决定着你前面两层资产的生死。我见过一个朋友prompt 写得不算出彩但他有一套严格的记录和回滚习惯半年下来资产库越来越厚也见过天才型选手靠灵感和手感疯狂产出三个月后离开项目那些“天才 prompt”再没人敢动。审计时我建议你给三类资产分别打分直接资产看复用率和代替性支撑资产看覆盖度和保鲜度隐形资产看有没有沉淀成文档和 checklist。三张表一拉你的 AI 资产现状就一目了然。2. 三年复盘从“调参炼丹”到“资产运作”的四阶段演变我完整经历了四个阶段每个阶段对 prompt 的态度完全不一样。回头看每个阶段都有自己的坑而第三阶段的“倦怠”反而是最大的转折点。2.1 入坑期把 prompt 当成咒语2022 年底到大模型真正普及的初期市面上的教程都在强调“prompt 写得好效果差十倍”。我信了这个开始疯狂收集各种“咒语”——“请你扮演一名资深律师”“请一步一步思考”“请用 Markdown 表格输出”。那时候写 prompt 的感觉确实有点像念咒同一个问题加一句话输出就从散的变成整的。这个阶段的问题在于只有输入输出的对照没有对原理的理解。我不知道模型为什么吃这套也不知道边界在哪。遇到失灵就加咒语越加越长效果时好时坏。2.2 狂热期过度拟合与自我感动2023 年中到 2024 年初是我“熬夜调 prompt”最严重的时期。当时手上有一个文本抽取项目模型偶尔会把时间字段抽错。为了这一个错误我反复微调提示词甚至针对十几条特定输入做定向优化。现在审视那段代码其实就是典型的“过拟合提示词”为了让几个测试样例好看把 prompt 改得越来越复杂添加了大量针对性的指令和示例。结果呢新样本进来错误模式转移了不是这里错就是那里错。好几个深夜我一遍遍刷新测试结果期待那一条条绿色通过但每次都有新问题冒出来。后来我才想明白提示词优化是有边际递减的而且过度优化会侵蚀泛化能力。你不该训练模型去背诵你的测试题而是该给它清晰的任务边界和判断标准。2.3 倦怠期开始质问“这真的值得吗”转折发生在一次例行“调优”中。那天我为一个非常简单的情感分类任务使出浑身解数——重新组织指令结构、加了几个反例、调整了输出格式约束——效果从 93% 提到了 94%。我盯着那个 1% 的提升发了很久呆意识到这件事的荒谬94% 对业务真的够用了。我投入的那三个小时如果用来整理已有的 prompt 和做评测样例收益会大得多。从那一刻起我开始有意识地减少“优化型修改”转而做“维护型整理”。这也是我后来写这个主题的起点真正的杠杆不在于把单个 prompt 调到极限而在于让你的资产可以在低维护状态下长期运作。倦怠不是懒而是你开始分清哪些是有价值的打磨哪些是无意义的内卷。2.4 资产运作期一年不维护的秘密这个时期的工作方式完全变了。我不再经常写新 prompt而是每月固定一个时间做轻量检查而非随时顺手改。每次模型供应商发版本更新公告我会拿评测集跑一遍而不是马上去调提示词。新任务来临时先从资产库里找最接近的模板改改而不是从空白 prompt 开始。记录一切改动理由、预期收益、实测结果、是否回滚。这种模式下我真正做到了核心 prompt 一年不动输出质量依然稳定。原因很简单经过长期评测集验证的、边界稳定的 prompt根本不需要频繁修改。你不去折腾它它就不会坏。3. 资产审计实操三个核心动作与一张台账“审计”这个词听起来很正式实际落地就三件事盘清楚自己有什么、评价这些东西健不健康、决定哪些该留哪些该砍。3.1 第一步盘点建台账我建议你新建一个表格在线文档或本地表格都行每一条 AI 资产记录以下字段字段说明示例资产名称给这个 prompt/配置起个辨识度高的名字合同关键信息抽取 prompt类型直接/支撑/隐形直接资产用途一句话说明解决什么问题从合同 PDF 提取金额、日期、甲方乙方模型依赖在哪个模型上验证过GPT-4o / Claude 3.5 / 本地 Qwen温度/参数关键采样参数temperature0.1, top_p0.9评测准确率最近一次评测集上的表现94.2%最后验证日期最近一次完整跑评测的时间2025-01-15上次修改日期最近一次改 prompt 的时间2023-11-02将近一年调用频率周调用量/月调用量月均 4200 次健康度自己打分健康/观察/危险健康备注坑点、替代方案、负责人升级模型后需复测字段抽取盘点的时候不要美化按真实情况填。填完你会发现一个常见现象你脑子里以为的资产和表里真正在用的重合度可能不到一半。大量“精心调过的 prompt”其实已经三个月没人调用了。3.2 第二步健康度评估我通常会从四个维度给资产打分每个维度 0-5 分复用性被重复使用的频率高不高。一次性任务生成的 prompt就算写得再好资产价值也有限。稳定性输入小幅扰动时输出是否稳定。测试时跑同一组数据五次看结果方差大不大。迁移性换一个同级模型比如从某个闭源模型换到另一个是否需要大改。依赖越少越健康。维护成本每次模型升级或业务变化时需要投入多少时间修复。这个数字越高说明资产越脆。总评 16-20 分是优质资产重点保护和复用10-15 分是观察资产每季度复评10 分以下属于危险资产要么重构要么下架。实操中你会发现真正让健康度翻车的往往不是 prompt 本身而是环境变化。我踩过最典型的坑是一个 prompt 在旧模型上表现完美新模型上线后同样的输入输出格式发生了变化——不是变差而是格式结构变了。这种事靠改 prompt 很难根治最好的做法是在代码层面加强输出解析的容错能力而不是去 prompt 里写“请严格遵守 JSON 格式”之类的废话。3.3 第三步ROI 取舍砍掉该砍的审计的最后一步是判断要不要继续保留某个资产。我的决策逻辑很简单看维护成本占比和收益贡献。如果资产每月调用量很低但每次模型升级都要花半天去重新验证和调整这个资产其实是负债。如果你发现某个 prompt 需要经常打补丁这类 case 加一句、那个 case 加一句说明它的抽象粒度不合理应该拆分或重写而不是继续打补丁。业务上已经不再使用的场景直接归档不要觉得可惜。代码库里没人用的死代码你会清理为什么不清理 prompt 死资产这里分享一个我自己的案例。曾经有一个“营销文案生成 prompt”用了大半年后来业务方向调整这个场景彻底不需要了。但我潜意识里觉得“这是我的心血”一直留在库里。审计时一算它占用了大约 15% 的评测验证时间而调用量是零。清理掉之后我把省下来的时间投到了真正核心的“客服意图识别”资产上效果比继续养着那个死资产好太多。4. 低维护的底层逻辑让“不维护”不出问题的三个条件很多人会担心一年不碰 prompt万一它哪天突然变笨了呢我理解这种焦虑所以才要强调所谓的“不维护”绝对不是放任不管而是通过机制设计让资产天然抗衰。4.1 用评测集代替“感觉”我再怎么强调评测集都不为过。它是你敢于“不维护”的最大底气。一套最小可用评测集不需要多大规模几十条到几百条都可以关键是覆盖面正常输入、边界输入、错别字或乱序输入、完全无关的输入、恶意或超长输入。每次模型平台发更新公告你不需要去看别人“实测报告”直接把自己那套评测集跑一遍看分数变化就行。今年年初某个大模型升级后我同事第一时间跑评测发现摘要任务的压缩率下降了几个点。他没有慌也没有重新调 prompt而是先确认是输入扰动还是模型行为变化然后翻了模型更新日志发现确实是对长文本的处理策略调整了。他针对受影响的部分做了一处很小的 prompt 增强半小时就搞定了。这就是评测集的价值它让你知道问题在哪儿以及问题有多大。不需要盲目从零开始。4.2 控制 Prompt 漂移能不改就不改“Prompt 漂移”指提示词被逐步修改偏离原始设计意图的现象。最常见的场景是某次业务方提了一个特殊需求你顺手在原来的 prompt 里加了一句“如果遇到 XXX 情况请额外输出 XXX”。加多了prompt 变成一个结构混乱的补丁堆老功能被新指令干扰输出开始不稳定。我的经验是一个 prompt 如果已经稳定运行超过一个月就不要再轻易改它。有了明确的新增需求先问三个问题——能否用单独的外层规则处理能否用后处理解决能否放到知识库里而不是改写指令这三个问题都不行再考虑动 prompt而且改动要做成“追加小节”而不是“改写原句”并同步更新评测集覆盖新场景。某种意义上prompt 和代码一样稳定的代码最好别乱动。每个稳定运行的系统都是靠惯性维持的。4.3 版本化与文档化解放自己“一年不维护”并不意味着没有留下任何痕迹恰恰相反它要求你在早期做足文档化和版本化。我对自己项目的管理方式可以套用轻量版 Git 思维每个 prompt 文件都有版本记录改了哪个位置出于什么原因评测指标从多少变到多少。不需要用复杂工具一个带历史记录的在线文档甚至一个本地文件夹按日期存版本就够了。文档化还包括记录“为什么”。我见过很多人写 prompt 只写最终成品不写推导过程。等到三个月后回来看根本想不起当初为什么加那一句“如果无法确认请说明原因”。如果你敢把一个“不确定为什么这么写”的 prompt 留给六个月后的自己那你其实是在给他挖坑。所以我每次修改 prompt顺手写几行 comment说明背景和验证结果。这件事单次花费不超过三分钟但能让你在真正“不维护”的时候完全放心——因为你知道就算出了问题你有完整的上下文能快速恢复。5. 可以直接抄的 AI 资产自检清单下面这份清单我常年贴在项目文档首页每次季度审计或者模型升级时过一遍。你也可以复制到自己的笔记里按实际情况调整。检查项操作健康标准资产台账梳理当前在用/闲置的 prompt、配置、评测集台账更新不超过 1 个月Prompt 复用率统计每个 prompt 在最近 30 天的调用次数核心资产周调用 ≥ 10 次评测集覆盖检查评测集是否覆盖新增业务场景覆盖面 ≥ 90%模型版本兼容用评测集跑一轮当前模型对比历史基线指标波动 ≤ 3%输出格式校验抽查 20 条线上真实输出检查结构是否符合预期通过率 ≥ 95%Prompt 长度卫生检查是否有膨胀到 2000 字以上的“缝合怪” prompt核心 prompt ≤ 500 字依赖项登记确认每个 prompt 关联的模型、温度、知识库索引是否有记录全部可查回滚方案确认每个核心资产都有上一版可用方案可快速回滚死资产清理清理连续 60 天无调用的 prompt 或配置清理完成安全基线检查 prompt 里是否存在注入风险提示或过度暴露的示例无敏感信息泄漏除了这张表我还建议你每季度写一个“AI 资产健康报告”不用很长三五条结论就行哪套系统稳定、哪块有隐患、下一步计划是什么、是否要砍掉某个资产。写报告的意义不在于汇报而在于逼你站在管理者的视角看自己的资产。你只有真正把自己的 AI 系统当作一个需要持续经营的产品才不会把大量精力耗在低价值的“熬夜调 prompt”上。6. 常见误区与经验教训我踩过的坑希望你绕过去最后一个部分分享几个真实案例。每一条我都在自己或身边人的项目里见过写出来帮你提前避开。6.1 误区一把“能跑通”当成“可维护”早期我非常容易满足于“prompt 能输出正确结果”。后来才发现“能跑通”和“可维护”是完全不同的标准。可维护意味着换了模型版本依然能用加入新示例不用改主干出了问题能快速定位是提示词问题、参数问题还是输入问题。我现在写新 prompt 的最后一步永远是问自己如果三个月后一个不了解背景的人接手这段配置他能不能看懂每个部分为什么存在6.2 误区二为了“完美输出”牺牲稳定性和速度在某个海外项目上我为了降低幻觉率把证据链要求写得很长草稿模式也从 false 改成了 true代价是响应时间从 1.2 秒涨到了 3.5 秒。用户反馈明显变差最后不得不回滚。稳定性和速度长期来看永远比“单次输出的完美度”更重要。你要接受一个现实AI 输出的正确率有一个合理的甜点区间追求 99% 的确定性代价往往是三倍的延迟和成本而业务根本用不上。6.3 误区三盲目追逐新特性频繁重写每次看到业界有人喊“X 模型又升级了你的 prompt 该重写了”别急着跟风。升级有两种兼容性升级和破坏性升级。绝大多数时候旧 prompt 在新模型上的表现并不会变差甚至可能更好。正确的做法是拿到新模型的评测结果不降级就不动降级了先看有没有其他层面的补救方案最后再考虑改 prompt。盲目重写的核心问题在于你会把已经稳定验证过的资产轻易破坏掉从一个稳定态进入另一个未知态。6.4 经验总结把时间留给真正重要的事我做这个审计的最大收获不是让 prompt 效果提升多少个百分点而是把自己从“不断优化、永远焦虑”的状态里解放出来。我依然会写新的 prompt依然会研究提示词工程但我不再把它当成每天必须打磨的主业。那些节省下来的时间和注意力被我用到了更值得投入的地方比如研究业务场景、优化知识库结构、设计更合理的 agent 工作流。盘点到这里最想对还在深夜跟提示词较劲的朋友说一句你调的可能不只是 prompt而是解决问题的勇气和方法。模型的能力边界会不断变化但稳定的资产管理和清醒的判断力才是跨周期复利的东西。停一停先把自己现有这套东西盘清楚再决定要不要继续加戏。