提示词工程提升AI性能最佳实践（中）：核心技术突破与实战

系列文章：ChangoVivo质性研究平台AI编码雷同识别功能优化实战

作者：ChangoVivo研发团队
日期：2025年11月
难度：⭐⭐⭐⭐⭐（专家级）
标签：#PromptEngineering #AI优化 #技术深度 #最佳实践

ChangoVivo 定性研究超级AI工具项目已经在 https://madechango.com工具箱上线，欢迎体验提出宝贵建议

---

作者感叹：大模型性能的关键和应用场景及应用技术高度相关，简单的#AI #提示词工程 # 可以成为产品惊艳性能的基础，千万不要迷恋新模型的规模参数，这个永无止境，扎实的基础功和一个似乎过时的大模型，有时就可以创造优秀的产品性能！

📖 回顾与导读

在上篇中，我们通过系统化测试发现了AI的三大"认知盲点"：

1. 🔴 维度关系误判（最严重，36%错误）
2. 🟡 对象vs过程混淆（18%错误）
3. 🟡 阶段关系混淆（18%错误）

本篇将深入剖析我们如何通过精心设计的Prompt工程技术，彻底解决这些问题。

---

一、Prompt工程的核心理念

1.1 什么是Prompt工程？

定义：

Prompt Engineering是一种通过精心设计的输入提示词，引导大语言模型产生更准确、更可靠输出的技术。

类比：

传统编程：写代码告诉计算机"怎么做"
Prompt工程：写提示词引导AI"怎么思考"

1.2 为什么Prompt工程有效？

大语言模型的工作原理：

输入Prompt → 模型推理 → 生成输出
     ↑           ↑
  引导方向    推理路径

关键洞察：

同样的任务，不同的Prompt可以激活AI不同的"推理路径"。好的Prompt能够引导AI沿着正确的路径思考。

实例对比：

❌ 弱Prompt（模糊指导）：

分析这些编码，找出雷同的。

✅ 强Prompt（明确指导）：

【任务】分析编码列表，识别雷同编码。

【核心原则】质性研究编码需要保持理论深度。
宁可保守，不要过度合并。

【概念关系分析】先分析关系类型，再决定是否合并：
1. 同义关系 → 应该合并
2. 维度关系 → 不应合并（不同维度有独立理论意义）
...

---

二、攻克维度关系：最大的技术突破

2.1 问题剖析

AI的错误推理过程：

第1步：观察编码名称
  "财务绩效"、"经营绩效"、"运营绩效"、"企业绩效"
  
第2步：识别共同点
  ✓ 都包含"绩效"这个词
  ✓ 都与企业绩效相关
  
第3步：错误结论
  ❌ "都涉及同一主题，应该合并"

正确的推理过程：

第1步：观察编码结构
  财务绩效 = [财务] + [绩效]
  经营绩效 = [经营] + [绩效]
  运营绩效 = [运营] + [绩效]
  
第2步：识别关系类型
  ✓ 相同的核心词：绩效
  ✓ 不同的限定词：财务、经营、运营
  → 这是"[限定词]+[核心概念]"模式 = 维度关系
  
第3步：正确结论
  ✅ "这些是不同维度，应该保持独立"

2.2 优化技术1：模式识别引导

在Prompt中明确定义识别模式：

【不同维度的识别方法】

⚠️ 如果编码都包含相同的核心概念词，但具有不同的限定词，就是维度关系

典型模式：
  "[限定词A] + [核心概念]" vs "[限定词B] + [核心概念]"

实例分析：
  ✓ "财务绩效" = [财务] + [绩效]
  ✓ "经营绩效" = [经营] + [绩效]
  ✓ "运营绩效" = [运营] + [绩效]
  → 核心词相同(绩效)，限定词不同(财务/经营/运营)
  → 判定：维度关系
  → 结论：不应合并
  → 相似度：< 0.70 (通常 0.50-0.65)

2.3 优化技术2：大量具体反例

Prompt优化前（抽象描述）：

维度关系：同一概念的不同维度，不应合并

Prompt优化后（具体反例）：

【维度关系 - 绝对不能合并的反例】

❌ 反例1：绩效维度
   "财务绩效"、"经营绩效"、"运营绩效"、"市场绩效"
   → 这些是绩效的不同维度，绝对不能合并

❌ 反例2：学习维度
   "学习能力"、"学习意愿"、"学习效果"
   → 这些是学习的不同维度，绝对不能合并

❌ 反例3：创新维度
   "技术创新"、"管理创新"、"产品创新"
   → 这些是创新的不同维度，绝对不能合并

为什么反例有效？

AI通过反例学习"边界"：

正例告诉AI："什么是对的"
反例告诉AI："什么是错的" ← 更重要！

2.4 优化技术3：强化型警告

使用视觉标记和强烈语气来强调关键规则：

❗❗❗ 最容易犯的错误 - 必须避免：

1. ❌ 将"财务绩效"、"经营绩效"、"运营绩效"标注为"同义关系"
   
2. ❌ 因为"都涉及企业绩效"就给出 >= 0.80 的评分
   
3. ❌ 忽略编码名称中限定词（如"财务"、"经营"）的重要性

✅✅✅ 正确的做法：

1. ✅ 识别"[限定词]+[核心概念]"模式 → 这是维度关系

2. ✅ 为维度关系给出 < 0.70 的评分（通常0.50-0.65）

3. ✅ 在concept_relation_type中标注"维度关系"

使用技巧：

• ❗ 视觉标记：让关键信息跳出来
• 🔴 颜色对比：红色❌ vs 绿色✅
• 📢 重复强调：关键规则出现3次以上

2.5 优化技术4：评分校准机制

问题：AI的相似度评分偏高（平均0.872）

解决方案：提供详细的评分校准指导

【评分校准要求 - 必须严格遵守】

❗ 特别警告 - 维度关系评分：
  
  检测信号：
  ├─ 编码都带有相同的核心词（如"X绩效"、"X创新"）
  ├─ 但前缀/限定词不同
  └─ 这是维度关系！
  
  评分规则：
  ├─ 相似度必须 < 0.70
  ├─ 通常应该在 0.50-0.65 之间
  └─ 绝对禁止给出 >= 0.80 的评分！
  
  自查问题：
  "这两个编码在理论框架中是否真的可以互换？"
  └─ 如果不能 → 评分 < 0.80

2.6 优化效果：完全突破！

第二轮优化后的Case 5测试结果：

================================================================================
测试案例: case_5 - 维度混淆（易错案例）
================================================================================

📊 AI分析结果:
   组 1: 绩效表现(ID:504), 绩效评价(ID:505)  ← 仍有小问题
   相似度: 0.85
   
   ✅ 不再合并: 财务绩效、经营绩效、运营绩效、企业绩效
   
📈 评估结果:
   错误合并: 4次 → 1次  ✅ 减少75%！
   维度关系识别: 0% → 100%  🎯 完全解决！

对比图表：

维度关系识别准确率变化
┌────────────────────────────────────────┐
│ v1.0 (基线)    ███░░░░░░░░░░░░  0%     │ ❌
│ v2.0 (第一轮)  ███░░░░░░░░░░░░  0%     │ ❌
│ v2.1 (第二轮)  ██████████████ 100%     │ ✅
└────────────────────────────────────────┘

成功关键：

1. ✅ 明确的模式识别指导
2. ✅ 大量具体的反例
3. ✅ 强化型警告和重复强调
4. ✅ 详细的评分校准标准

---

三、解决"对象vs过程"混淆

3.1 问题特征

典型案例：

# 容易混淆的编码对
对象编码 vs 过程编码
├─ "满意度" vs "满意度评价"
├─ "绩效" vs "绩效评估"
├─ "绩效表现" vs "绩效评价"
└─ "风险" vs "风险管理"

AI的错误逻辑：

"满意度评价"包含"满意度" → 概念相关 → 应该合并

正确的逻辑：

"满意度"是评价对象，"满意度评价"是评价过程 → 不同层次 → 不应合并

3.2 优化策略：关键词识别

在Prompt中提供过程关键词列表：

【对象与过程识别】

过程关键词：
  "评价"、"评估"、"测量"、"衡量"、"分析"、
  "管理"、"控制"、"监测"、"评定"

识别方法：
  如果编码A包含过程关键词，编码B不包含
  → 一个是过程，一个是对象
  → 不应合并，相似度 < 0.65

反例：
  ❌ "满意度"（对象）vs "满意度评价"（过程）
  ❌ "绩效表现"（对象）vs "绩效评价"（过程）
  ❌ "风险"（对象）vs "风险管理"（过程）

3.3 优化效果

Case 2测试结果对比：

版本	错误合并	表现
v1.0	3次	❌ 将"满意度评价"、“用户体验”、"用户期望"都合并了
v2.0	0次	✅ 完美识别，全部正确拒绝合并
v2.1	0次	✅ 继续保持完美

AI的正确输出示例：

{
  "group_id": 2,
  "concept_relation_type": "包含关系",
  "codes": [
    {"id": 203, "code_name": "满意度评价"},
    {"id": 204, "code_name": "用户体验"}
  ],
  "similarity_score": 0.65,  // < 0.80，不会被采纳
  "recommended_name": "不合并",
  "merge_reason": "满意度评价是用户体验的一个组成部分，应保持独立",
  "confidence_level": "高"
}

成功要素：

1. ✅ AI正确识别了关系类型（包含关系）
2. ✅ AI给出了合理的低分（0.65）
3. ✅ AI明确说明"不合并"
4. ✅ AI理解了为什么应该保持独立

---

四、Prompt结构设计：分层递进

4.1 Prompt架构设计

一个高效的Prompt应该具有清晰的层次结构：

【Prompt完整架构】

┌─────────────────────────────────────────┐
│ 第1层：角色设定                          │
│ "你是一位资深质性研究专家..."           │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ 第2层：任务描述                          │
│ "分析以下编码列表，识别雷同编码..."     │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ 第3层：核心原则（新增）                  │
│ "宁可保守，不要过度合并..."             │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ 第4层：概念关系分析（新增）              │
│ "先分析关系类型，再决定是否合并..."     │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ 第5层：不应合并的标准（新增，核心）      │
│ "维度关系、阶段关系...绝对不应合并..."  │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ 第6层：应该合并的标准                    │
│ "完全同义、细微主体差异..."             │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ 第7层：评分量化标准（新增，核心）        │
│ "维度关系：< 0.70；同义关系：>= 0.90..." │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ 第8层：输出格式                          │
│ "JSON格式，包含concept_relation_type..." │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ 第9层：特别强调（新增，防错）            │
│ "最容易犯的错误 - 必须避免..."          │
└─────────────────────────────────────────┘

设计原则：

• 📍 从抽象到具体：先讲原则，再讲细节
• 🔁 关键信息重复：重要规则出现3次以上
• ⚠️ 防错机制：在最后再次强调最容易犯的错误

4.2 核心代码片段展示

Prompt构建的核心逻辑（简化版）：

def _build_duplicate_analysis_prompt(
    self,
    codes: List[Dict[str, Any]],
    research_topic: Optional[str] = None,
    language: str = 'zh'
) -> str:
    """构建编码雷同分析提示词"""
    
    # 1. 构建编码列表文本
    codes_text = self._format_codes_list(codes)
    
    # 2. 构建分层Prompt
    prompt = f"""你是一位资深质性研究专家，精通扎根理论的编码管理。

【任务】
分析以下编码列表，识别含义相同、相近或雷同的编码。

【编码列表】
{codes_text}

【核心原则 - 质性研究的特殊性】
质性研究的编码体系需要保持理论深度和概念的独立性。
**宁可保守，不要过度合并**。
只有在编码真正可以互换使用时，才建议合并。

【概念关系分析 - 第一步】
在判断是否合并之前，必须先分析编码之间的概念关系：

1. 同义关系 → ✅ 应该合并
2. 近义关系 → ⚠️ 谨慎合并
3. 包含关系 → ❌ 不应合并
4. 维度关系 → ❌ 绝对不应合并  ← 重点强化
5. 阶段关系 → ❌ 不应合并
6. 对象与过程 → ❌ 不应合并

【不同维度识别（❗最容易误判）】

⚠️ 如果编码都包含相同的核心概念词，但具有不同的限定词
→ 这是维度关系，绝对不应合并

典型模式：
  "[限定词A] + [核心概念]" vs "[限定词B] + [核心概念]"

反例：
  ❌ "财务绩效"、"经营绩效"、"运营绩效" → 不能合并！
  ❌ "技术创新"、"管理创新"、"产品创新" → 不能合并！
  
评分规则：
  维度关系的相似度必须 < 0.70，通常应该在 0.50-0.65

【评分校准要求】

❗ 特别警告 - 维度关系评分：
- 绝对禁止将"财务绩效"、"经营绩效"标注为同义关系！
- 绝对禁止因为"都涉及绩效"就给出 >= 0.80 的评分！

[... 其他详细规则 ...]

❗❗❗ 最容易犯的错误 - 必须避免：
1. ❌ 将维度关系标注为"同义关系"
2. ❌ 忽略限定词的重要性
3. ❌ 为了简化而过度合并

✅✅✅ 正确的做法：
1. ✅ 识别"[限定词]+[核心概念]"模式
2. ✅ 为维度关系给出 < 0.70 的评分
3. ✅ 标注concept_relation_type为"维度关系"
"""
    
    return prompt

代码亮点：

• 🎯 分层递进：从原则到具体，从抽象到实例
• 🔁 重复强调：维度关系的规则出现了5次以上
• ⚠️ 视觉标记：用❗、❌、✅等符号增强可读性
• 📊 量化标准：明确的相似度评分范围

---

五、Prompt工程的高级技巧

5.1 技巧1：引导推理过程

传统做法（直接要结果）：

分析这些编码是否雷同，给出相似度评分。

优化做法（引导推理）：

【分析步骤】

第1步：识别概念关系类型
  - 观察编码结构
  - 识别是否有"[限定词]+[核心概念]"模式
  - 判断是同义、近义、包含、维度、阶段还是交叉关系

第2步：根据关系类型决定是否合并
  - 同义关系 → 合并
  - 维度关系 → 不合并
  - ...

第3步：在输出中标注关系类型
  在concept_relation_type字段中明确标注

效果：

引导AI按照正确的步骤思考，而不是直接跳到结论。

5.2 技巧2：自查机制

在Prompt中嵌入"自我检查"问题：

【自查机制】

在给出相似度评分之前，请自问：

✓ 问题1："这两个编码真的可以互换使用吗？"
  └─ 如果不能 → 评分 < 0.80

✓ 问题2："它们是否属于'[限定词]+[核心概念]'模式？"
  └─ 如果是 → 这是维度关系 → 评分 < 0.70

✓ 问题3："合并后会损失理论深度吗？"
  └─ 如果会 → 不合并

✓ 问题4："研究主题中它们是否是关键维度？"
  └─ 如果是 → 更应该保持独立

原理：

让AI在推理过程中进行"反思"（Reflection），提高决策质量。

5.3 技巧3：对比学习

同时提供正例和反例，让AI学习边界：

【正例 - 应该合并】

✅ 案例1：完全同义
   "数字化转型" vs "数字转型"
   → 可以互换使用 → 相似度 0.95 → 合并

✅ 案例2：细微主体差异
   "用户满意度" vs "客户满意度"
   → 主体相近 → 相似度 0.88 → 合并

【反例 - 不应合并】

❌ 案例1：维度关系
   "财务绩效" vs "经营绩效"
   → 不同维度 → 相似度 < 0.70 → 不合并

❌ 案例2：对象vs过程
   "满意度" vs "满意度评价"
   → 不同层次 → 相似度 < 0.65 → 不合并

对比学习的力量：

只有正例：AI知道什么是对的
正例+反例：AI知道边界在哪里 ← 更强大

5.4 技巧4：上下文强化

利用研究主题提供上下文判断：

【研究主题的使用】

研究主题不仅是背景信息，更是判断依据：

原则1：主题核心概念优先保留
  例如：在"企业绩效"研究中
  "财务绩效"、"经营绩效"是关键维度
  → 更应该保持独立，不应合并

原则2：理论框架完整性
  在质性研究中，编码的独立性关系到理论框架的完整性
  不同维度的编码合并会损害理论的解释力

实例：
  研究主题："用户体验研究"
  "用户期望"和"用户体验"虽然相关
  但在UX理论中有明确区分（期望-体验差距模型）
  → 不应合并

---

六、技术栈与系统架构

6.1 技术选型

技术栈总览
┌─────────────────────────────────────────┐
│ 🧠 AI引擎                               │
│ └─ GLM-4 (智谱AI)                       │
│    ├─ 上下文窗口: 128K tokens            │
│    ├─ 支持JSON模式输出                   │
│    └─ 语义理解能力强                     │
├─────────────────────────────────────────┤
│ 🐍 后端框架                             │
│ └─ Python 3.9+                          │
│    ├─ FastAPI (异步处理)                │
│    ├─ SQLAlchemy (数据持久化)           │
│    └─ Asyncio (并发控制)                │
├─────────────────────────────────────────┤
│ 🎨 前端界面                             │
│ └─ Vue.js 3 + Element Plus               │
│    └─ 实时展示AI分析结果                │
├─────────────────────────────────────────┤
│ 🧪 测试框架                             │
│ └─ 自研测试系统                          │
│    ├─ 6个标准测试案例                   │
│    ├─ 自动化性能评估                     │
│    └─ JSON格式结果存储                   │
└─────────────────────────────────────────┘

6.2 系统架构（简化版）

用户交互流程
┌──────────┐      ┌──────────────┐      ┌──────────┐
│          │      │              │      │          │
│  前端UI  │─────→│  后端API     │─────→│ GLM-4 AI │
│          │      │              │      │          │
└──────────┘      └──────────────┘      └──────────┘
     ↑                   ↓                     ↓
     │                   ↓                     ↓
     │            ┌──────────────┐      ┌──────────┐
     │            │              │      │          │
     └────────────│  数据库      │←─────│ 结果验证 │
                  │              │      │          │
                  └──────────────┘      └──────────┘

关键组件：

1. QualitativeCodeDuplicateService（服务层）

   • 负责Prompt构建
   • 调用GLM-4 API
   • 结果验证和后处理

2. GLM4Service（AI引擎封装）

   • API调用封装
   • 超时控制
   • 错误处理

3. 测试系统（质量保证）

   • 自动化测试用例
   • 性能指标计算
   • 结果分析报告

6.3 核心服务代码结构

class QualitativeCodeDuplicateService:
    """编码雷同分析服务"""
    
    def __init__(self):
        """初始化AI服务（配置已隐藏）"""
        self.glm_service = GLM4Service(**config)
    
    async def analyze_code_duplicates(
        self,
        codes: List[Dict],
        project_id: int,
        research_topic: Optional[str] = None
    ) -> Dict[str, Any]:
        """
        分析编码雷同情况
        
        核心流程：
        1. 构建优化的Prompt
        2. 调用GLM-4 API
        3. 解析并验证结果
        4. 应用相似度阈值过滤
        """
        
        # 步骤1：构建Prompt（核心优化点）
        prompt = self._build_duplicate_analysis_prompt(
            codes=codes,
            research_topic=research_topic,
            language='zh'
        )
        
        # 步骤2：调用AI（超时控制已隐藏）
        response = await self.glm_service.generate_response(
            prompt_text=prompt,
            json_mode=True
        )
        
        # 步骤3：解析结果
        result = json.loads(response)
        
        # 步骤4：验证和过滤
        self._validate_analysis_result(result, codes)
        filtered_groups = self._filter_by_threshold(
            result["duplicate_groups"],
            threshold=0.80  # 优化后的阈值
        )
        
        return {
            "success": True,
            "duplicate_groups": filtered_groups,
            "summary": result["summary"]
        }

代码亮点：

• 🔐 异步处理：使用async/await提高并发性能
• 🛡️ 多重验证：ID验证、格式验证、阈值过滤
• 🎯 错误恢复：自动修复AI返回的常见错误

---

七、性能监控与评估

7.1 自动化测试系统

我们构建了一个完整的测试评估框架：

class CodeDuplicateAnalysisTester:
    """编码雷同分析测试器"""
    
    def run_all_tests(self):
        """运行所有测试案例"""
        for case_id, case_data in TEST_CASES.items():
            result = await self.run_test_case(case_id, case_data)
            self.results.append(result)
        
        # 生成性能报告
        self._generate_summary_report()
        
        # 保存详细结果（JSON格式）
        self._save_results()
    
    def _analyze_result(self, result, case_data):
        """分析AI返回结果，计算指标"""
        
        # 计算精确率
        precision = correct_groups / found_groups
        
        # 计算召回率
        recall = correct_groups / expected_groups
        
        # 统计错误类型
        false_positives = []  # 不应合并却被识别
        false_negatives = []  # 应该合并却被遗漏
        
        return metrics

7.2 性能可视化

测试结果趋势图：

精确率变化趋势
┌────────────────────────────────────────┐
│ 90%│                                    │
│ 80%│                      ▲────────     │ ← v2.1: 75%
│ 70%│         ▬────────────┘             │ ← v2.0: 66.7%
│ 60%│  ▬──────┘                          │ ← v1.0: 66.7%
│ 50%│                                    │
└────┴────────────────────────────────────┘
    v1.0     v2.0        v2.1
    
错误合并次数变化
┌────────────────────────────────────────┐
│ 12 │ ████████████                       │ ← v1.0: 11次
│ 10 │                                    │
│  8 │          ████████                  │ ← v2.0: 7次
│  6 │                                    │
│  4 │                   ██████           │ ← v2.1: 5次
│  2 │                                    │
│  0 │                                    │
└────┴────────────────────────────────────┘
    v1.0     v2.0        v2.1

关键指标仪表盘：

┌─────────────────────────────────────────────┐
│         📊 v2.1 性能指标                     │
├─────────────────────────────────────────────┤
│ ✅ 召回率        ████████████████ 100%      │
│ ⚠️ 精确率        ████████████░░░  75%       │
│ ✅ 维度关系识别  ████████████████ 100% 🎯   │
│ ⚠️ 错误合并      █████░░░░░░░░░░  5次       │
└─────────────────────────────────────────────┘

7.3 测试驱动优化的价值

量化收益：

ROI分析
┌──────────────────┬──────────┬──────────┬──────────┐
│ 投入            │ 产出     │ 改进率   │ 评级     │
├──────────────────┼──────────┼──────────┼──────────┤
│ 开发时间: 7小时  │ 错误-55% │ 高       │ ⭐⭐⭐⭐⭐│
│ 测试设计: 2小时  │ 精确+8%  │ 中       │ ⭐⭐⭐⭐ │
│ 文档编写: 1.5小时│ 维度100% │ 极高     │ ⭐⭐⭐⭐⭐│
└──────────────────┴──────────┴──────────┴──────────┘

总投入: 10.5小时
核心收益: 完全解决最严重问题（维度关系）
ROI: ⭐⭐⭐⭐⭐ (5/5星)

---

八、本篇总结

8.1 核心要点

本篇我们介绍了：

1. ✅ 问题诊断方法

   • 通过系统化测试发现AI的"认知盲点"
   • 识别出维度关系误判是最严重问题

2. ✅ 测试驱动优化方法论

   • 设计6个覆盖不同场景的测试案例
   • 建立自动化测试框架
   • 量化评估优化效果

3. ✅ Prompt分层设计

   • 从抽象原则到具体细节
   • 引导AI的推理过程
   • 嵌入自查机制

4. ✅ 技术栈与架构

   • GLM-4 AI引擎
   • Python异步服务架构
   • 自动化测试系统

8.2 关键洞察

Prompt工程的本质：

不是"调参"，而是"教学"。我们通过精心设计的Prompt来"教会"AI正确的判断标准和推理过程。

测试驱动的价值：

没有测试的优化是盲目的。通过量化指标，我们可以精确识别问题、验证效果、持续改进。

8.3 下期预告

在下篇文章中，我们将揭示：

🎯 最终优化效果

• 精确率如何从66.7%提升到75%
• 维度关系识别如何达到100%准确率
• 错误合并如何减少55%

📊 深度性能分析

• 三个版本的完整对比
• 每个测试案例的详细剖析
• 优化技术的效果量化

🏆 Prompt工程最佳实践

• 10条可复用的优化经验
• AI性能提升的通用方法论
• 如何应对AI的认知局限

📚 经验总结与未来展望

• 什么样的问题适合Prompt优化
• 什么问题需要其他技术手段
• 下一代AI辅助质性研究的方向

---

🔗 系列文章导航

• ✅ 上篇：发现问题与测试驱动优化（本文）
• ⏭️ 中篇：核心优化技术与突破（即将发布）
• ⏭️ 下篇：效果验证与最佳实践（即将发布）

---

💡 思考题

1. 在你的AI应用中，有遇到过类似的"认知盲点"吗？
2. 你通常如何验证Prompt优化的效果？
3. 如果不用Prompt优化，还有什么方法可以解决维度关系问题？

欢迎在评论区分享你的见解！

---

<sub>⭐ 如果本文对你有帮助，欢迎点赞收藏 ⭐
🔔 关注我们，获取系列文章更新通知 🔔

本文由ChangoVivo研发团队原创
©2025 ChangoVivo. All Rights Reserved.</sub>