企业官网建设流程全解析

本指南以 ccg-workflow 仓库中 AI 领域知识文件 prompt-and-eval.md 为主体骨架，结合仓库的自动路由机制、双模型审查策略与评审提示词实现，系统讲解 Prompt 模式选型、模板设计、模型评估、A/B 测试与上线监控的完整链路。读完本文，你将掌握 Zero-shot / Few-shot / CoT / Self-Consistency / ToT / ReAct 六种 Prompt 模式的选择方法，能够使用 RAGAS 与 LLM-as-Judge 搭建可量化的评估体系，并知道如何把「测试 → 分析 → 改进」的迭代闭环落地到自己的 LLM 应用上。

一、这份文档在 ccg-workflow 中如何被使用

在 ccg-workflow 中，prompt-and-eval.md属于AI 领域域知识秘典（Domain Knowledge），与agent-dev.md、llm-security.md、rag-system.md并列，由 templates/skills/domains/ai/SKILL.md 统一索引。它的定位是：当用户的问题涉及 Prompt 工程、模型评估等主题时，为编排模型即时注入专家级知识。

触发方式有两种：

1. 静态路由规则：ccg-skill-routing.md 中明确登记了 AI/MLOps 域的路由表——prompt engineering, model evaluation, benchmark, fine-tuning等关键词命中时，Claude 需先读取~/.claude/skills/ccg/domains/ai/prompt-and-eval.md再作答，并强调「当存在技能文件时，不得凭训练数据臆造领域知识」。

2. Hook 自动注入：仓库中的 skill-router.js（UserPromptSubmit Hook）会在每轮用户消息中做关键词匹配，把命中的技能文件前 120 行以<ccg-domain-knowledge>块注入对话上下文。此外，src/utils/skill-registry.ts通过解析 SKILL.md 的 frontmatter（name/description/user-invocable等）实现技能自动发现与命令生成，安装器将其随npx ccg-workflow一键装进~/.claude/skills/ccg/domains/ai/。

因此，本文的内容不仅是方法论，更是 ccg-workflow 编排引擎在遇到 Prompt 工程、模型评估类任务时实际依赖的权威知识源。下面按文档的五大板块逐一展开。

二、Prompt 模式：从 Zero-shot 到 ToT 的选型地图

2.1 六种模式对比总览

先建立全局视角。不同 Prompt 模式在复杂度、准确性、Token 消耗与适用场景上差异巨大，选错模式是 LLM 应用效果不佳的第一大原因：

选型原则：能用 Zero-shot 解决的不要上 Few-shot；需要推理的优先 CoT；关键决策用 Self-Consistency 多路投票兜底；涉及工具调用的 Agent 场景直接上 ReAct；而 ToT 只在需要多步规划、每一步都要评估取舍的复杂问题上才值得付出极高 Token 成本。在 ccg-workflow 的多模型协作中，这个选型逻辑同样适用——简单任务走direct-fix/quick-implement策略零外部模型开销，复杂任务才升级到双模型并行（对应full-collaborate/review-audit策略），本质上是同一套「按复杂度分配资源」的思维。

2.2 Zero-shot：清晰指令 + 角色设定 + 输出格式

Zero-shot 不给示例，完全依赖指令本身的表达力。关键三要素：清晰指令、角色设定、输出格式约束。

# 关键：清晰指令 + 角色设定 + 输出格式 prompt = """ 你是一位资深安全工程师。 任务: 将以下文本分类为正面、负面或中性。 输入: {text} 输出格式: JSON {"sentiment": "...", "confidence": 0.0-1.0} """

输出格式约束是 Zero-shot 稳定性的核心：明确指定 JSON 结构、字段名与取值范围（如confidence的 0.0-1.0），能显著降低模型自由发挥的空间。ccg-workflow 的专家提示词同样遵循这一原则——例如 codex/reviewer.md 中为代码审查定义了固定的VALIDATION REPORT评分模板（Root Cause Resolution / Code Quality / Side Effects / Edge Cases / Test Coverage 各 20 分），把自由回答约束成结构化输出，便于后续程序化解析与比对。

2.3 Few-shot：2-5 个高质量示例 + 动态示例选择

Few-shot 通过示例「教会」模型任务格式。关键：2-5 个高质量、覆盖边界情况的示例，以及示例与目标输入的语义相似度选择。

# 关键：2-5 个高质量示例 + 语义相似度选择 prompt = """ 将评论分类: 评论: 音质很棒，佩戴舒适。 → 正面 评论: 电池续航太差。 → 负面 评论: {new_review} → """ # 动态示例选择（LangChain） selector = SemanticSimilarityExampleSelector.from_examples( examples, OpenAIEmbeddings(), Chroma, k=2 )

当示例池很大时，不要每次都把所有示例塞进 prompt——用SemanticSimilarityExampleSelector把新输入与示例库做向量相似度匹配，只挑选k=2（或更多）最相关的示例，既省 Token 又提升命中率。

2.4 CoT 与 Self-Consistency：从「魔法咒语」到多路投票

Chain-of-Thought（思维链）通过显式要求「一步步思考」激活模型的推理能力，是数学、逻辑类任务性价比最高的增强手段：

# Zero-shot CoT — 魔法咒语 prompt = f"问题: {question}\n\n让我们一步步思考:" # Self-Consistency — 多路投票 answers = [extract_answer(llm.predict(prompt, temperature=0.7)) for _ in range(5)] final = Counter(answers).most_common(1)[0][0]

Self-Consistency 是 CoT 的强化版：以较高温度（如temperature=0.7）多次采样，让模型沿不同推理路径各走一遍，再对最终答案做投票（Counter.most_common(1)）取众数。多次独立推理中一致出现的答案，比单次推理更可靠，适合资金决策、代码合并等「只许对不许错」的关键场景。代价是 Token 消耗成倍增加——这正是对比表中它被标注「高 Token、极高准确性」的原因。

2.5 ReAct：Thought → Action → Observation 循环

ReAct（Reasoning + Acting）把推理与行动交替执行，是构建工具调用型 Agent 的基础范式。每轮循环输出三段式：Thought（我想做什么）→ Action（调用哪个工具）→ Observation（工具返回了什么），直到得出答案用Finish收尾：

# Thought → Action → Observation 循环 prompt = """ 工具: Search[query], Calculate[expr], Finish[answer] Thought: 我需要查询埃菲尔铁塔高度 Action: Search[埃菲尔铁塔高度] Observation: 330 米 Thought: 现在知道答案了 Action: Finish[330 米] """

在 ccg-workflow 中，这一范式有直接的工程对应物：codeagent-wrapper（Go 二进制）作为 Claude 与外部模型（Codex / Grok / Kimi / Antigravity 等）之间的桥梁，正是「Claude 编排（Thought）→ 分发任务给外部模型（Action）→ 回收结果（Observation）」的具象化。模型路由器 model-router.md 详细规定了按分析/规划/审查/调试/实施阶段选择模型、以run_in_background: true并行启动双模型、用TaskOutput阻塞等待结果再综合的调用协议——本质上就是 ReAct 循环在多模型系统层面的放大版。

2.6 Tree-of-Thoughts (ToT)：Beam Search 式的思路树

ToT 不再满足于单条思维链，而是同时生成多条候选思路 → 逐条评估打分 → 按 Beam Search 保留最优分支 → 递归扩展，适合需要深度规划、中间步骤可验证的复杂问题：

# 生成多条思路 → 评估打分 → Beam Search 选最优 → 递归扩展 class TreeOfThoughts: def solve(self, problem): thoughts = self._generate(problem, n=3) scored = self._evaluate(problem, thoughts) best = sorted(scored, key=lambda x: x[1], reverse=True)[:self.beam_width] # 递归深入最佳路径

_generate负责在每个节点产出n条候选思路，_evaluate为每条打分，beam_width控制每层保留的分支数。搜索树的每一层都在做「生成-评估-剪枝」，因此 Token 消耗是所有模式中最高的（对比表中标注「极高」），务必只用于复杂规划类任务。

三、Prompt 设计技巧：模板结构与优化原则

3.1 三段式消息模板：System + User 分层

生产级 Prompt 应拆成 system 与 user 两层，各司其职：

messages = [ {"role": "system", "content": "角色 + 能力边界 + 输出约束"}, {"role": "user", "content": "### 指令\n{task}\n### 输入\n{input}\n### 输出格式\n{format}"}, ]

• system 层：声明角色、能力边界与输出约束，优先级最高，是防御 Prompt 注入的第一道防线（配合 llm-security.md 中的「核心规则不可覆盖」写法效果更佳）；
• user 层：用 Markdown 级标题（### 指令 / ### 输入 / ### 输出格式）把任务拆成结构化小节，比一段式大文本更容易被模型稳定解析。

ccg-workflow 的专家提示词文件即采用类似分层：ROLE_FILE: ~/.claude/.ccg/prompts/$MODEL/$ROLE.md中定义角色与能力边界，<TASK>...</TASK>块注入具体任务，OUTPUT: ...指定输出格式——模板变量在安装时由injectConfigVariables按用户配置注入，见 src/utils/installer.ts。

3.2 优化原则速查

这五条原则中，「约束边界」最容易被忽视：好的 Prompt 不仅要说「做什么」，还要明确「不做什么」，例如在 ccg-workflow 的 review-audit.md 审查策略中，verify-quality报告只需输出发现的问题（非 Critical 时静默通过，不输出 "all clear"），这种「明确的输出边界」直接决定了评估结果的可用性。

3.3 高级技巧：元提示与自我批评

两个低成本高收益的进阶技巧：

# 元提示 — 用 LLM 生成 Prompt meta = "你是 Prompt 专家。为以下任务生成最优 Prompt: {task}" # 自我批评 — 生成 → 批评 → 改进 answer = llm(question) critique = llm(f"批评: {answer}") improved = llm(f"基于批评改进: {critique}")

• 元提示（Meta-prompting）：让 LLM 扮演 Prompt 专家，为任务自动生成 Prompt，适合批量生产模板或给不熟悉 Prompt 编写的团队成员兜底；
• 自我批评（Self-critique）：先生成答案，再让模型以批评者视角审视，最后基于批评改进。这与 ccg-workflow 的Ralph Loop 迭代审查协议（见 phase-guide.md）思路同源——每轮审查都 spawn 全新的 Agent（干净上下文）读取磁盘最新状态重新验证，循环自修复直到无 Critical 问题，最多 3 轮。

3.4 Prompt 模板速查（可直接复制）

常见任务的 Prompt 骨架，把占位符换成实际内容即可：

代码生成: "生成 {lang} 代码: {desc}。要求: 最佳实践 + 注释 + 异常处理" 文本摘要: "总结为 {n} 字: {text}。保留关键信息，语言简洁" 数据提取: "从文本提取 {fields}，输出 JSON: {text}" NL2SQL: "将自然语言转 SQL: {query}。表结构: {schema}"

四、模型评估：从指标到框架的完整体系

4.1 评估维度：先定维度，再选指标

模型评估不是「跑个准确率」那么简单，必须按任务类型匹配维度：

注意：效率维度（延迟、吞吐、成本）经常被忽略，但它直接决定生产可行性。在 ccg-workflow 中，模型选择本身就是一种评估决策——model-router.md 记录了「backend 模型运行中可能需要 5-15 分钟，保持轮询」「600s 等待上限，超时后报告并询问用户」等延迟约束，以及 Gemini CLI 停服后从推荐位降级、Antigravity 接任前端默认模型的路线变迁，说明效率与可用性在模型评估中与准确性同等重要。

4.2 RAGAS：RAG 系统的四指标评估框架

RAG（检索增强生成）是幻觉高发区，RAGAS 提供四个开箱即用的指标，全部输出 0-1 区间：

from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall dataset = Dataset.from_dict({ "question": questions, "answer": answers, "contexts": contexts, "ground_truth": ground_truths, }) result = evaluate(dataset, metrics=[ faithfulness, # 答案是否基于上下文（0-1） answer_relevancy, # 答案与问题相关度（0-1） context_precision, # 检索上下文中相关信息比例（0-1） context_recall, # 上下文是否包含所需全部信息（0-1） ])

四指标各管一段链路：

• faithfulness：生成的答案是否忠实于检索到的上下文（防幻觉）；
• answer_relevancy：答案是否答非所问；
• context_precision：检索回来的内容里「有用信息」占比（防噪音）；
• context_recall：上下文是否覆盖了作答所需的全部信息（防漏检）。

数据集需要question / answer / contexts / ground_truth四列，其中contexts是检索器实际返回的文档列表。评估结果可作为 RAG 系统调参（切分粒度、Top-K、重排阈值）的量化依据。

4.3 LLM-as-Judge：让模型当裁判，附成对比较与 ELO

LLM-as-Judge 用另一个 LLM 按标准打分，解决「人工评估太慢、太贵」的问题：

class LLMJudge: def evaluate(self, question, answer, criteria): prompt = f""" 评估答案质量（1-5 分）: 问题: {question} 答案: {answer} 标准: {criteria} 输出 JSON: {{"accuracy": N, "completeness": N, "clarity": N, "overall": N, "feedback": "..."}} """ return json.loads(self.llm.predict(prompt)) # 成对比较 + ELO 排名 def pairwise(q, a, b): # 返回 {"winner": "A"|"B", "confidence": 0-1} ...

要点：

• 评分维度拆细：accuracy / completeness / clarity / overall 分项打分，并强制 JSON 输出便于解析；
• 成对比较（Pairwise）：同时给出两个答案让裁判二选一，比绝对打分更稳定；大量成对结果可喂入 ELO 排名算法，得到模型或 Prompt 版本的相对优劣排序；
• 人工抽检兜底：文档 CheckList 明确要求「自动评估 LLM-as-Judge + 定期人工抽检」——裁判模型本身也有偏见，关键样本必须人工复核。

这与 ccg-workflow 的双模型交叉审查机制互为印证：review-audit.md 要求 backend 与 frontend 两个模型独立审查同一份 git diff，再综合报告去重分级（Critical / Warning / Info），其价值正来自「不同视角的独立评估」——与 LLM-as-Judge 的成对比较设计哲学一致。

4.4 基准测试速查

标准基准（MMLU / HumanEval / GSM8K）用于横向对比模型能力，业务自定义基准用于验证落地效果——两者缺一不可。自定义基准的核心是「加权评分 + 延迟」：把业务正确率、完整性、格式合规性按权重合成总分，并统计 P95 延迟，才能回答「这个模型/Prompt 到底能不能上生产」。

4.5 检索指标与生成指标

RAG 的检索质量与生成质量需要分开评估：

def evaluate_retrieval(retrieved, relevant, k=5): precision_at_k = len(set(retrieved[:k]) & set(relevant)) / k recall_at_k = len(set(retrieved[:k]) & set(relevant)) / len(relevant) # MRR: 第一个相关文档的倒数排名 # NDCG: 归一化折损累积增益 return {"precision@k": precision_at_k, "recall@k": recall_at_k, "mrr": mrr, "ndcg": ndcg}

• Precision@k / Recall@k：Top-k 检索结果中相关文档的占比与覆盖率，是最常用的两个指标；
• MRR（Mean Reciprocal Rank）：第一个相关文档排在第几位——适合「只要第一个答案对」的问答场景；
• NDCG（Normalized Discounted Cumulative Gain）：按排名位置折损加权，奖励「相关文档排得越前越好」。

生成质量则沿用经典 NLP 指标：

# ROUGE: 摘要质量（rouge-1, rouge-2, rouge-l） # BLEU: 翻译质量 from rouge import Rouge rouge_scores = Rouge().get_scores(predictions, references, avg=True)

ROUGE（基于 n-gram 重叠）衡量摘要与参考摘要的重合度，BLEU 衡量翻译与参考译文的精确匹配度。注意这两类指标只看字面重叠，与语义忠实度无关，因此需与 4.2 节的 RAGAS 语义指标配合使用。

五、A/B 测试与持续监控：上线前的最后一公里

5.1 A/B 测试：一致性哈希分流 + 显著性检验

上线新 Prompt 或新模型前，先做 A/B 测试收集真实数据：

class ABTest: def __init__(self, variants): # [Variant(name, model, ratio)] self.variants = variants def get_variant(self, user_id): # 一致性哈希分流 return self.variants[hash(user_id) % 100 < cumulative_ratio] def check_significance(self, a_scores, b_scores, alpha=0.05): t_stat, p_value = stats.ttest_ind(a_scores, b_scores) cohens_d = (mean(a) - mean(b)) / pooled_std return {"p_value": p_value, "significant": p_value < alpha, "effect": cohens_d}

• 分流：按hash(user_id)对 100 取模映射到变体，保证同一用户始终命中同一变体（体验一致），且分流稳定、无状态存储；
• 显著性检验：对两组的分数做独立样本 t 检验（ttest_ind），p_value < alpha（默认 0.05）才算显著，同时算 Cohen's d 衡量效应量——p 值显著但效应量极小的情况在生产上毫无意义，两者必须一起看。

5.2 持续监控：Prometheus 三件套 + Z-score 异常检测

上线不是终点。用 Prometheus 客户端埋点，持续跟踪三类指标：

from prometheus_client import Counter, Histogram, Gauge request_count = Counter('llm_requests_total', 'Total', ['model', 'status']) latency = Histogram('llm_latency_seconds', 'Latency', ['model']) quality = Gauge('llm_quality_score', 'Quality', ['model']) # 异常检测: Z-score > 2.0 触发告警 class AnomalyDetector: def check(self, value): z = abs((value - mean(self.window)) / std(self.window)) return z > self.threshold

• Counter（llm_requests_total）：按model、status打标签统计请求量与成功率；
• Histogram（llm_latency_seconds）：天然支持分位数统计，可画出 P95/P99 延迟曲线；
• Gauge（llm_quality_score）：周期写入由 LLM-as-Judge 或抽检得到的质量分；
• 异常检测：滑动窗口内计算 Z-score，超过 2.0 即告警——延迟突增、质量分骤降都能在影响扩大前被发现。

ccg-workflow 生产环境的「健康检查」思路与此一脉相承：npx ccg-workflow doctor命令一键检查 Node 版本、配置、命令、Hooks、Binary、Skills、Rules、MCP、Codex 模式，有问题标红；ccg status展示版本、模型路由与活跃任务数（见 README.zh-CN.md）——把「持续监控」落到了工具链本身。

六、Checklist：落地前逐项自查

Prompt 工程

• 清晰指令 + 角色设定 + 输出格式约束
• 复杂任务用 CoT / ReAct
• 关键决策用 Self-Consistency 多路投票
• 版本管理 Prompt，A/B 测试对比效果
• 迭代优化：测试 → 分析 → 改进

模型评估

• 多维度评估：准确性 + 相关性 + 忠实性 + 效率
• RAG 用 RAGAS 四指标
• 自动评估 LLM-as-Judge + 定期人工抽检
• 标准基准（MMLU/HumanEval）+ 业务自定义基准
• 上线前 A/B 测试，上线后持续监控 + 异常告警
• 反馈闭环：收集用户反馈持续改进

其中「版本管理 Prompt」在 ccg-workflow 中已有现成实践：Prompt 模板全部以文件形式存放在~/.claude/.ccg/prompts/{model}/（源文件在 templates/prompts/），随 Git 版本化，/ccg:review、/ccg:spec-review等命令通过ROLE_FILE引用指定角色提示词，切换或回退只需改引用路径——这正是「Prompt 即代码」的工程化落地。

七、工具速查表

搭配建议：LangChain 管 Prompt 模板与链路搭建，RAGAS 管 RAG 质量量化，LangSmith / Phoenix 管线上监控，OpenAI Evals 或 W&B 管离线实验对比，Guidance 管需要严格 schema 约束的结构化生成场景。在 ccg-workflow 中，LangChain 生态的动态示例选择、RAGAS 的四指标、LLM-as-Judge 的成对比较思想，都已在上文对应小节给出可直接运行的代码骨架。

小结：Prompt 工程与模型评估是一枚硬币的两面——没有评估，Prompt 优化就是无头苍蝇；没有好的 Prompt，评估结果也只是在量化一个低质量基线。ccg-workflow 将本文档作为 AI 域知识秘典，通过关键词路由与 Hook 自动注入到每一轮协作中，配合双模型交叉审查、质量关卡（/ccg:verify-quality）与模型路由器，构成了「设计 Prompt → 量化评估 → 分流实验 → 上线监控 → 反馈迭代」的完整闭环。按第六节的 Checklist 逐项执行，你的 LLM 应用就能从「能跑」走向「可衡量、可优化、可上线」。