关键要点
- 当您为工作流中的每条Prompt添加相同的3个以上组件时，构建自定义框架
- 使用3至6个组件：更少是技术方法，更多会产生阻力
- 文档化前在10条真实Prompt上进行测试
- 在GPT-4o和Claude 4.6 Sonnet上验证跨模型可靠性
- 将框架规格说明连同模板和3个带注释的示例一起存储在版本控制中
框架与技术的区别是什么？
📍 In One Sentence
Prompt框架是定义每条Prompt所需组件的结构模板；技术是在这些组件之一内应用的模式。
💬 In Plain Terms
框架是每条Prompt的脚手架——它决定了各个部分。技术是您在某个部分内所做的事情，例如要求模型逐步推理。
Prompt框架是定义每条Prompt所需组件的结构模板；技术是在这些组件之一内应用的模式。 思维链提示是一种技术——在框架的"任务"组件中应用。CO-STAR是一个框架——它定义了构建整个Prompt的6个组件。
这种区别很重要，因为框架和技术解决不同的问题。框架解决一致性问题：团队中每个人都用相同的结构生成Prompt。技术解决能力问题：它改变模型处理推理过程中特定步骤的方式。
当任务类型与框架的设计用途相符时，使用现有框架（CO-STAR、CRAFT、RISEN、RTF）。当您总是需要添加现有框架未包含的相同领域特定组件时，构建自定义框架。
📌 核心区别
框架解决团队内的一致性问题。技术解决单个Prompt步骤中的能力问题。两者都是必要的；一个不能替代另一个。
何时构建自定义Prompt框架
当您在特定工作流中对每条Prompt进行相同的3项以上修改时，就应该构建自定义框架。 如果您总是需要添加合规性约束、引用要求和术语表——这些应该成为自定义框架的正式组件，而不是手动添加项。
需要自定义框架的迹象：
- 您在每条Prompt中添加相同字段，而这些字段不在任何标准框架中
- 尽管使用CO-STAR或CRAFT，团队仍生成不一致的Prompt
- 新团队成员需要超过一周才能写出可接受的Prompt
- 由于一直解释相同的上下文，您的Prompt平均超过600个词
- 您创建了一个"基础Prompt"，每个人都在复制和手动修改
5步构建自定义Prompt框架
5步流程：定义目标 → 识别组件 → 在10条Prompt上测试 → 改进 → 文档化。 每步都有明确的完成标准。不要跳到第5步——对未经测试的框架进行文档化会产生虚假的信心。
- 1用一句话定义目标
Why it matters: 准确写出这个框架必须可靠生成的输出内容。这句话决定了每个组件的选择。 - 2识别3至6个必要组件
Why it matters: 列出此工作流中每条Prompt需要的输入要素。首先凭记忆写出5条Prompt，然后提取共同点。 - 3在10条真实Prompt上进行测试
Why it matters: 使用工作流中的实际Prompt——不要用虚构的例子。通过PromptQuorum在GPT-4o和Claude 4.6 Sonnet上测试，确认跨模型可靠性。 - 4改进组件列表
Why it matters: 删除在10条Prompt中出现少于7次的组件。添加在5次以上即兴加入的组件。用修订后的框架重新进行10条Prompt测试。 - 5文档化与标准化
Why it matters: 编写一页规格说明：框架名称、每个组件的定义、带占位符的填写模板和3个带注释的示例Prompt。存储在Git或PromptHub的版本控制中。
⚠️ 不要跳过第3步
不经过10条真实Prompt的测试，框架几乎总会包含在时间压力下被跳过的组件。先测试，再文档化。
示例：为支持团队构建框架
一个支持团队的自定义框架——命名为REPAIR——包含5个组件：Role、Escalation condition、Policy anchor、Action path、Intent confirmation。 CO-STAR和CRAFT等标准框架不包含每条支持Prompt都需要的升级逻辑和策略锚定。
REPAIR模板：
- R (Role): "You are a tier-1 support agent for Product. Your authority covers scope."
- E (Escalation): "If the issue involves condition, escalate to tier-2. Do not attempt resolution."
- P (Policy anchor): "Apply policy ID for issue type. Quote the relevant clause in your response."
- A (Action path): "Classify the issue, confirm understanding, propose resolution, request confirmation."
- I (Intent confirmation): "End every response with: 'Does this address your issue, or would you like me to escalate?'"
将REPAIR框架文档化并添加到团队的Prompt库后，新代理的入职时间从2周缩短至3天。Prompt一致性评分（通过Braintrust评估测量）在第一个月内从64%提升至89%。
💡 衡量影响
在部署自定义框架前后追踪入职时间和一致性评分。如果在4周内没有改善，框架需要改进，而不是更多文档。
构建自定义框架的常见错误
最常见的错误是在手动测试20条以上真实Prompt之前就构建框架。 从理论而非观察到的模式构建的框架包含听起来重要但实际上被跳过的组件。
❌ 组件过多（7个以上）
Why it hurts: 编写者在时间压力下跳过部分，破坏一致性。
Fix: 限制在6个组件内。将领域特定字段移到扩展中，而不是核心框架中。
❌ 复制标准框架并重命名
Why it hurts: 重命名的CO-STAR不是自定义框架。
Fix: 只有当您有至少2个任何标准框架中都不存在的组件时，才正式化框架。
❌ 文档化前没有测试集
Why it hurts: 您文档化了一个无法承受真实Prompt考验的框架。
Fix: 在编写规格说明前，运行10条真实Prompt通过草稿框架。
常见问题
什么是Prompt框架？
Prompt框架是一种结构化模板，定义了Prompt中应包含哪些组件及其顺序。框架提高了一致性，减少了从零开始编写Prompt的时间。
何时应该构建自定义框架？
当您为工作流中的每条Prompt对标准框架进行相同的3项以上修改时，请构建自定义框架。
自定义框架应该有多少个组件？
使用3至6个组件。少于3个是技术方法，超过6个会产生阻力。
如何命名自定义框架？
用首字母缩略词（如REPAIR）使其易于记忆。测试：新团队成员仅凭名称能记住所有组件吗？
如何对自定义框架进行版本控制？
将每个版本存储在带日期的文件中。重大变更为主版本，细化调整为次版本，并记录变更原因。
可以组合多个现有框架吗？
可以，但将结果视为新的自定义框架。命名、记录并测试它，就像它是原创的一样。
相关阅读
参考来源
常见问题
提示技巧和提示框架有什么区别?
技巧是单一指令或方法（如"逐步思考"）。框架是具有3+组件的可重用结构，定义如何构建提示。框架可重复使用；技巧是临时的。
何时应该构建自定义框架而不使用CO-STAR、CRAFT或RISEN?
当您为工作流中的每条提示重复对现有框架进行相同的3+修改时，构建一个。如果您始终向CO-STAR添加政策约束、领域术语和输出模式，这些应该成为您自己框架的组件。
自定义框架能在不同的AI模型上工作吗?
是的，如果设计正确。避免特定于模型的语法，围绕通用组件（任务、约束、输出格式）构建。在最终确定前在GPT-4o和Claude上测试。如果框架需要按型号重新措辞，请简化它。
我的自定义框架应该有多少个组件?
使用3-6个组件。少于3个是技巧，不是框架。超过6个会产生摩擦，编写者跳过部分。如果需要更多，将其分为两个针对不同任务类型的专用框架。
如何测试我的自定义框架是否真正有效?
将其应用于工作流中的10个代表性提示。根据三个标准对输出进行评分：（1）任务完成、（2）格式遵守、（3）质量一致。有效的框架在所有三个方面的评分应为8/10或更高。使用PromptQuorum跨多个模型进行测试。
我应该如何命名自定义框架?
使用映射到顺序中的组件的首字母缩略词（如REPAIR）。首字母缩略词测试：新团队成员仅从名称就能记住所有组件吗？如果不能，简化您的组件列表。
我能将CO-STAR、CRAFT和RISEN的组件结合起来吗?
可以，但将其视为新的自定义框架，而不是混合体。命名、记录和测试它，就像它是原创的一样。没有正式化，结合只会创建无文档的临时模式。
我应该如何对自定义框架进行版本管理?
将每个框架版本存储在日期文件（如repair-v1-2026-05.md）中。将重大更改（添加/删除的组件）标记为主要版本。将改进（定义更新）标记为次要版本。记录每个更改的原因。
我应该为我的自定义框架记录什么?
编写一份一页的规范：（1）框架名称和目标、（2）带示例的3-6组件定义、（3）填充模板、（4）3个使用框架的带注释的完整示例提示。将其保存在版本控制中，并在您的提示库旁边。
我如何让我的团队使用我创建的自定义框架?
从使用实际任务示例的30分钟演练开始。在2-3条提示上一起测试。创建可共享的一页规范。第一个月跟踪合规性和影响指标。根据反馈进行迭代。