2023 年前后有那么一段时间，提示词工程感觉像炼金术。只要找到正确的咒语——那句魔法短语、指令的完美排序——一个一直给你产出烂泥的模型就会突然吐出黄金。COSTAR 这类框架正是在那个世界里诞生的。Sheila Teo 的 COSTAR（Context、Objective、Style、Tone、Audience、Response）赢下了新加坡首届 GPT-4 提示词工程大赛，赢得有道理：它给一个原本全凭试错的过程强加了秩序。
三年过去，这些框架还在。COSTAR 依然是流传最广的结构之一。但它们有效的原因已经悄悄变了——如果你还把它们当性能外挂来用，你解决的是一个基本不复存在的问题。
这些框架当年到底在干什么
结构化提示最初的卖点是解锁能力。早期模型需要你把一切说透。不声明受众，就得到千篇一律的输出。不指定格式，就得到一堵散文墙。COSTAR 的六个槽位，恰好对应 2023 年那代模型会猜错的六件事。
这让结构显得像承重墙。去掉”Audience”这个字段，输出会明显变差。于是人们内化了一条规则：结构越多，输出越好。以当时的证据来看，很合理。
什么变了
2026 年的前沿模型能自己推断出其中大部分脚手架。让一个能干的模型”给供应商写一封礼貌的拒绝邮件”，它已经会自己挑一个合理的文风、一个恰当的语气、一个干净的格式——你一个都不用点名。你过去手动填的槽位，现在由模型自己的判断力来填。
这不代表 COSTAR 错了。而是对能干的模型和直白的任务来说，它的一部分变得多余了。当模型本来就会选”专业”的时候，声明”Tone: professional”的边际价值已经趋近于零。在简单请求上摆出完整的六段式脚手架，如今多半是仪式——花了力气，却推不动输出。
有意思的细节是：这件事取决于模型。最近一篇关于 COSTAR-A 的论文发现，原始框架对大模型仍能提升清晰度，但对更小的、本地优化过的模型效果不稳定——尤其在需要受约束、指令式输出的任务上。如果你在自己的硬件上跑一个 8B 级的微调模型，旧规则大体上仍然适用，你甚至可能需要比 COSTAR 更强的指令式结构。所谓”框架过时了”，其实是”前沿模型变强了”，这个结论并不能干净地迁移到小模型的世界。
仍然值回票价的那部分
留下来的是什么？而且是值得留的：框架是一份防遗忘的检查清单。
2026 年，一条结构化提示词之所以胜过一条偷懒的，通常不在结构本身，而在于过一遍槽位会逼你把真正还能推动质量的东西补齐——而这些东西集中在三处：
- 上下文（Context）——杠杆最高的单一输入。大多数糟糕的输出追根溯源都是缺上下文，不是缺结构。模型无法推断你从没告诉它的事。
- 目标（Objective）——一个具体、明确的任务，而不是含糊地朝任务比划一下。
- 输出形态（Response）——输出的形状。强制一个可解析、可预测的结构，才让提示词能安全地跑在流水线里。
Style、Tone、Audience 仍然重要，但要看场合。在面向客户和品牌口吻的工作里，它们值回票价——那里的文字必须在规模上保持特定的腔调。而对代码审查或技术分析来说，它们大体是噪音——一个在审查你 auth 处理器的模型，不需要语气指令。
所以正确的心智模型不是”每次把六个格子填满”，而是”把格子当备忘，然后狠狠地删”。留下对你的任务承重的部分，扔掉其余的。
一个你真会用的模板
下面是作为工作检查清单、而非强制表格的 COSTAR。注意有多少被标成了可删：
/* ============================================================
* TL;DR: COSTAR as a checklist, not an incantation.
* On capable 2026 models, Context + Objective + Response do
* most of the work. Style/Tone/Audience matter for prose at
* scale, less for code. Keep what's load-bearing, cut the rest.
* ============================================================ */
# CONTEXT — highest leverage; never skip
You are reviewing a Hono route handler in a TypeScript monorepo
on Cloudflare Workers + Supabase.
# OBJECTIVE — be specific and concrete
Find auth-bypass risks in this handler and list each one.
# STYLE — often inferable for technical work; drop if obvious
Terse, senior-engineer register.
# TONE — usually noise for code; matters for user-facing copy
(omit)
# AUDIENCE — shapes assumed knowledge and depth
A backend dev who already knows JWT and RLS.
# RESPONSE — high leverage; forces predictable, parseable output
Markdown list: finding -> severity -> one-line fix. No preamble.结构仍然完胜的地方
有一处，检查清单式的纪律不是可选项：那些你写一次、要跑很多次的提示词。系统提示、自动化流程、RAG 流水线——任何你没机会逐次迭代的地方。交互式聊天允许你把一个乱糟糟的请求丢给模型，它理解偏了再纠正。流水线不行。当提示词必须在数千条输入上一次到位时，框架强制的完整性就不再是仪式，而是保险。
诚实的结论
COSTAR 和它的表亲们没有变差，而是被降级了——从咒语降为纪律。它们不再解锁模型原本够不到的能力。它们仍然做到的，是逼你写出一条完整的提示词，而一条完整的提示词会产出更好的结果，无论你是靠哪个缩写词走到这一步的。
把框架当成你思考的脚手架，而不是对模型施法的咒语。填上对眼前任务承重的槽位，删掉不承重的，然后把省下来的力气花在那个没有任何框架能替你提供的输入上：模型根本无从知晓的上下文。