Prompt 工程：当一段文字学会了思考、行动与统治

同样的 GPT-4，有人写出 500 行难以维护的代码，有人构建出完整的自动化工作流系统。

差距不在模型，在于那个你每天都在用却从未认真对待的东西------Prompt。

不只是"提示词"

大部分人对 Prompt 的理解是："跟 ChatGPT 说话的方式"。这个理解其实有所偏差。

Prompt 的本质是你与大语言模型之间的通信协议。

HTTP 定义了浏览器和服务器怎么通信，SQL 定义了应用和数据库怎么通信，Prompt 定义了人类和千亿参数概率模型怎么通信。你写 Prompt，本质上是在写一份声明式程序规范------你声明了模型的角色、任务目标、行为边界和输出格式，模型在参数空间里找到最优路径，这和你写 SQL 让数据库引擎选择最优执行计划没有本质区别。

一段"声明式规范"在实际中长这样------你不告诉模型怎么推理，只定义输入、输出和约束：

markdown 复制代码

# 角色
你是一个 React 性能优化专家，擅长用 React DevTools Profiler 定位渲染瓶颈。

# 任务
分析以下组件的渲染性能问题。

# 约束
- 每个问题必须指出具体行号并给出修复代码
- 如果没有发现明显问题，说"未发现性能问题"，不要强行找茬
- 用中文回复

# 上下文
- React 版本：18.2
- 该组件在用户快速滚动时会明显卡顿，列表项约 200 条

# 代码
{code}

这段 Prompt 没有一行是"推理指令"------它只声明了边界。模型自己在参数空间里完成了从"性能问题"到"行号+修复代码"的映射。

Prompt 值得被工程化的理由有三个：

模型能力是常量，Prompt 是唯一变量，同一个 GPT-4，好 Prompt 和差 Prompt 的产出质量可以差一个数量级；
Prompt 的能力会向上穿透------调 API 要写 System Prompt，做 RAG 要设计检索增强 Prompt，搞 Agent 要给每个子 Agent 写角色 Prompt，Fine-tuning 要构造训练 Prompt，Prompt 工程是所有 AI 技术的地基；
不需要 GPU、不需要训练数据，需要的只是一个 API Key 和一个愿意反复实验的大脑。

一段好的 Prompt 就是一份声明式规范：角色定义（注意力分配机制）、任务描述、约束条件、上下文注入、输出格式。你不需要告诉模型"怎么推理"，你只需要定义好输入、输出和边界。理解了这一点，就理解了为什么 Prompt 能穿起整个 AI 工具链------后续出现的 Skills、MCP、Agent、Agentic AI，本质上都是对"声明式规范"的结构化、工程化和系统化。

但 Prompt 有一个致命缺陷：它是一次性的

仔细想一个问题：Prompt 到底是什么？本质上是单次任务的临时输入。 你这次塞进去，任务结束，这些东西就消失了。它更像一份临时交接文档，而不是真正形成的能力。这特别像你每天都在重新培训一个新员工，而不是培养一个熟悉业务的老员工。

这个缺陷在实际工程中暴露得非常快。刚开始团队只是在 Prompt 里加规则------"用 pnpm，不要 npm install""legacy 目录不要动""API 请求统一走 request.ts"。项目简单时还好，稍微复杂一点后 Prompt 开始失控，越来越长，最后变成一份巨型 README。很多团队开始拼 Prompt、分 Prompt、嵌套 Prompt、动态生成 Prompt，整个系统越来越奇怪。

根本原因：Prompt 本身不适合存储"长期经验"。 所有规则永远同时存在于一个巨大的上下文窗口中，但真实工程里经验应该按场景激活。这就好比要求一个工程师脑子里永远装着公司所有项目的全部规范------不现实，也没必要。这个矛盾，在编程场景中最早被放大，由此诞生了 Vibe Coding 的第一波系统化尝试。

Vibe Coding：Prompt 工程的第一现场

Prompt 的一次性问题，为什么最先在编程场景中暴露？因为代码生成对风格一致性 和规范约束 的要求远高于普通对话。你今天告诉 AI"用 pnpm"，明天它又开始 npm install；你强调 legacy 目录不要动，下一轮它又改了 legacy 里的文件。普通聊天可以容忍这种"遗忘"，但代码不行------一次不一致就意味着 bug 或线上事故。

2024 年，Andrej Karpathy 提出"Vibe Coding"：你沉浸在编码的"氛围"里，用自然语言描述意图，AI 生成代码，你审查、调整、再描述，直到满意。

把"写代码"变成了"描述需求"------从"你必须知道怎么做"到"你只需要知道要做什么"。

这一层的 Prompt 工程核心有四个要点。

身份设定：不是"催眠"AI，而是注意力分配机制------说"React 性能优化专家"，模型的概率分布就会向 React 知识空间倾斜。

markdown 复制代码

# 差（无身份，模型漫无目标）
"优化这个组件"

# 好（身份锚定了知识空间）
"你是一个 React 性能优化专家。请分析以下组件的渲染性能。
重点关注：不必要的重渲染、大列表虚拟滚动缺失、render 中的昂贵计算。"

上下文注入：最容易被跳过也最致命的一步，Cursor 能看到当前文件，但看不到你的 package.json、tsconfig.json、团队规范------30 秒多打字，省下 30 分钟调试。

markdown 复制代码

## 项目上下文
- 框架：Next.js 14 (App Router)
- UI 库：shadcn/ui（不要用 Ant Design）
- 样式：Tailwind CSS
- 路径别名：@/ → src/
- 网络请求：用 @/lib/api 的 fetcher 封装，不要直接用 fetch
- 类型：严格模式，禁止 any

思维链（Chain of Thought）：不让模型直接给答案，让它先展示推理过程。大模型逐 token 生成，推理 token 会自回归地影响后续答案 token------相当于模型给自己提供了中间计算空间。

markdown 复制代码

# 差（直接要结果，模型容易跳步、遗漏边界情况）
"把 Class Component 改成 Function Component"

# 好（拆解步骤，每步输出后再进行下一步）
"把这个 Class Component 重构成 Function Component + Hooks。
按以下步骤，每步输出后再进行下一步：
1. 分析生命周期方法，映射到 Hooks（componentDidMount → useEffect 等）
2. 识别 state 和 side effects
3. 识别 this 绑定，转换为 useCallback
4. 给出完整重构代码
如果发现 componentDidCatch，说明用了 Error Boundary，请特别指出。"

Few-shot：给 AI 1-3 个示例，让它理解输出模式，一个 Few-shot 示例抵得上十句"按我们的风格写"。

markdown 复制代码

## 输出格式示例

输入：用户点击提交按钮后页面无响应
期望输出：
### 问题定位
- **文件**：src/components/SubmitButton.tsx 第 23 行
- **原因**：handleSubmit 中未处理 loading 状态，导致重复提交
### 修复方案
const [loading, setLoading] = useState(false);
const handleSubmit = async () => {
  if (loading) return;
  setLoading(true);
  // ...
};


请按照以上格式分析我提交的 Bug。"""

这一层的致命局限：每次都从零开始。 你写了 50 次"项目用 shadcn/ui，不要用 any，下载用 downloadFile"，终于疯了。但真正的痛苦不是"重复打字"------而是你昨天花一下午教 AI 搞定的线上 Redis 问题排查流程，今天它完全不记得了，又从数据库开始查。Vibe Coding 的本质问题不是 Prompt 不够长，而是 Prompt 天然不适合存储跨会话的长期经验。

每次对话都是独立的一次性上下文，就像每天早上换一个新员工，没有交接、没有记忆、没有成长。

这就是致命缺点。

那么能不能把这些经验存起来，按场景封装成模块，下次自动加载？

Skills：Prompt 的结构化封装

Vibe Coding 暴露了一个深层矛盾：Prompt 存"长期经验"天然不合理。

为什么 Vibe Coding 时代的团队会在 Prompt 里越写越多、越拼越长？因为 Prompt 的最大特点是"所有规则永远同时存在"------你的前端规范、后端规范、部署规范、安全规范全部挤在一个巨大的 System Prompt 里，不管当前任务是什么，所有规则都会被加载。真实工程不是这样的。修改一个按钮样式时，你不需要知道数据库 migration 的规范；排查线上 CPU 飙升时，你也不需要加载按钮样式的设计规范。

经验应该按场景激活，而不是全量常驻。

这就是 Skills 要解决的根问题。Skills 就是把一套经过验证的 Prompt + 工具 + 工作流打包成可复用模块，按任务场景动态加载。定义方式通常是一个 Markdown 文件，里面声明角色、任务、约束、触发条件和可用工具。

如果说 React 组件封装了 HTML/CSS/JS，Skills 封装的就是 Prompt 的最佳实践。

更关键的是：好的 Prompt 需要调试。 一个"代码审查 Prompt"可能要迭代 20 次才能稳定产出高质量结果。这不再是随意打出的文字------这是经过测试验证的、有明确输入输出约定的、可被 AI 自动选择和加载的知识资产。从 Vibe Coding 到 Skills，Prompt 完成了第一次质变：从"输入框里的文字"变成了"代码库里的模块"。

一个完整的 Skill 定义文件示例：

markdown 复制代码

# SKILL.md

---
name: frontend-code-review
description: |
  前端代码审查专家。触发词：审查代码、code review、帮我看看这段代码。
---

## 角色
你是资深前端代码审查专家，精通 React、TypeScript 和现代前端工程化。

## 审查维度（按优先级）
1. 🔴 安全漏洞（XSS、注入、敏感信息泄露）
2. 🔴 逻辑错误（边界条件、空值处理、竞态条件）
3. 🟡 性能问题（不必要重渲染、内存泄漏、大列表未虚拟化）
4. 🟡 可维护性（硬编码、魔法数字、过长的函数）
5. 🟢 最佳实践偏离

## 输出格式
### 🔴 严重问题
- **位置**：第 X 行
- **问题**：...
- **修复**：
\`\`\`tsx
// 修复代码
\`\`\`

### 🟡 改进建议
...

### 📊 总体评分：X/10

## 约束
- 使用中文回复
- 每个问题必须给出具体行号和可运行的修复代码
- 代码块统一使用 tsx 语法高亮
- 如果代码无明显问题，说"未发现明显问题，整体质量良好"，不要强行找问题。

这一层的局限： AI 的能力还是局限于生成文本。Skills 让 AI 更可靠了，它能帮你审查代码，但不能读取 Figma 设计稿、不能操作浏览器做端到端测试、不能查询你的数据库。

那么如何能读取设计稿？如何操作浏览器？

...

**MCP（Model Context Protocol）**来了。

MCP：Prompt 变成工具协议

Skills 解决了一个关键问题------经验可以按场景加载、跨会话复用了。

但它没有解决另一个问题：AI 怎么操作外部世界？ 一个装了 frontend-debug Skill 的 AI 能精准地告诉你代码哪里有问题，但它不能打开浏览器帮你验证、不能查 GitHub 看有没有类似的 Issue、不能跑 CI 看你改了之后测试过没过。

Skills 让 AI 有了"经验"，但还缺"手脚"。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底开源的一个协议，定义了 AI 如何标准化地发现和调用外部工具。

在 MCP 之前，每个 AI 应用想接工具都得单独适配------给 ChatGPT 写一套 GitHub 集成、给 Claude 再写一套、给 Cursor 再写一套。

MCP 做的事情就是定义"标准插座"------任何符合标准的工具 Server，任何 MCP Client 插上就能用。

这里必须讲清 MCP 和 Skills 的关系------它们解决的根本不是同一层问题。

MCP 是"工具接入层"（Capability），让 AI 能连接数据库、浏览器、GitHub、文件系统；

Skills 是"经验组织层"（Experience），让 AI 知道在面对不同任务时应该怎么做、有哪些教训要记住。

MCP 解决"AI 能不能做事"，Skills 解决"AI 能不能越做越熟练"。

两者不但不矛盾，而且 Skills 是 MCP 之后必然出现的补位------因为当 AI 能做的事越来越多、接的工具越来越复杂，没有经验系统的情况下它只会犯更多、更严重的错误。这也是为什么 Skills 在 MCP 之后反而更流行了：工具能力 ≠ 工程经验，后者需要持久化、可复用的知识体系。

这里有一个关键洞察：MCP Server 里每个工具的描述，本质上就是一段 Prompt。 工具描述告诉 AI"这个工具存在且有这个能力"，参数描述告诉 AI"city 应该填城市名称"，System Prompt 告诉 AI"涉及实时数据优先用工具"。从用户说"北京今天热不热"到 AI 调用 get_weather("北京") 返回结果，整个推理链条的每一个环节都是由 Prompt 驱动的。

一个 MCP Server 中工具的定义，本质就是在写 Prompt：

typescript 复制代码

// MCP Server 定义工具 ------ 工具描述就是 Prompt
server.tool(
  "get_weather",
  "获取指定城市的实时天气信息，包括温度、湿度、风速、天气状况。" +
  "适用场景：用户询问某地天气时的首选工具。" +
  "局限：仅支持中国大陆城市。",
  {
    city: z.string().describe("城市名称，如 '北京'、'上海'、'深圳'"),
  },
  async ({ city }) => {
    const data = await fetchWeatherAPI(city);
    return {
      content: [{ type: "text", text: JSON.stringify(data) }],
    };
  }
);

AI 读取以上定义后，自主完成了三段推理：

(1) 工具发现------"用户问天气，我有个 get_weather 工具"；

(2) 参数填写------"city 参数填'北京'"；

(3) 结果呈现------"拿到 JSON 后翻译成自然语言回复"。这三个环节没有一行是硬编码的 if-else，全部由 Prompt 驱动。

对应的 System Prompt 决定了工具使用的整体策略：

markdown 复制代码

# MCP 层 System Prompt

## 工具使用原则
1. 涉及实时数据（天气、股价、新闻）→ 必须调用工具，禁止凭训练记忆回答
2. 涉及内部文档查询 → 优先调用 search_internal_docs
3. 工具调用失败 → 重试一次，仍失败则如实告知用户，不要编造结果
4. 同一任务优先合并工具调用（减少往返次数）
5. 工具返回数据过大时，只提取关键信息展示给用户

Prompt 在这一层有三个角色：工具发现 （工具描述 Prompt 决定了 AI 能否在正确时机识别出这个工具）、参数填写 （参数描述 Prompt 决定了 AI 能否正确填写参数------city: z.string() 远不如 city: z.string().describe("城市名称，如'北京'")）、错误恢复（工具调用失败时，System Prompt 里的降级策略决定了 AI 是重试、换工具还是告知用户）。

这一层的局限也很明显：MCP 解决的是单步工具调用，处理不了"分析 GitHub 仓库 → 筛选技术点 → 每个点搜论文 → 生成趋势报告"这类多步复杂任务。

Agent：Prompt 成为决策系统

走到这一步，AI 已经具备了"经验"（Skills）和"手脚"（MCP 工具），但还缺自主决策能力。

Skills 是被动的------触发匹配上了就加载经验，MCP 是响应式的------你告诉 AI 调用哪个工具它才调用。但真实任务不是这样线性推进的。

一个"帮我研究这个技术方向并出报告"的任务，背后需要的是：先拆解目标 → 决定搜索哪些关键词 → 调用 GitHub/论文 API → 读到一半发现某个概念不懂 → 再搜索补充 → 整理成报告 → 检查是否有遗漏 → 修正。这不是"调用一个工具 + 加载一个 Skill"能解决的------这需要一个持续的决策循环。

Agent 不是让 AI 回答一次就结束，而是让它进入一个持续运行的循环：Think（理解任务、拆解子目标、选择最优行动）→ Act（调用工具、执行操作）→ Observe（检查结果、对比预期、判断是否完成），未完成则回到 Think 基于新信息调整策略。

Agent 的本质是把"单次推理"升级为"多步决策循环"。 一个真实例子：任务"找出 GitHub Star 增长最快的前端项目并写分析报告"，Agent 会自主完成 12 步------调 GitHub API 获取数据 → Python 处理排序 → 逐一搜索背景资料 → 生成报告 → 写入文件。每一步的输出都是下一步的输入，每一步都可能因为结果不符合预期而调整策略。

Agent 阶段的 Prompt 不再是"一段指令"，而是一套决策系统------定义怎么思考、怎么决策、怎么应对失败、什么时候停下来：

markdown 复制代码

# Agent System Prompt

你是一个全栈开发 Agent，通过 Think→Act→Observe 循环完成任务。

## 决策规则
1. 收到任务后，先拆解步骤列出计划
2. 每一步执行前评估风险------会删文件吗？会改数据库吗？
3. 执行后检查结果，与预期对比
4. 出错时分析原因，最多重试 2 次，然后换方案
5. 换了 2 个方案都不行 → 向用户求助，不要死循环

## 终止条件
- ✅ 所有子目标完成 → 总结做了什么、为什么这样做
- ⛔ 遇到不可恢复的错误 → 如实告知用户
- 🛑 用户明确要求停止

## 安全边界（硬约束，不可覆盖）
- 永不删除用户文件（除非用户明确授权）
- 永不执行 rm -rf 或等价危险命令
- 修改超过 3 个文件时，先列出变更清单并等待确认

## 可用工具
- read_file(path) → 读取文件内容
- write_file(path, content) → 写入新文件
- run_command(cmd) → 执行 Shell 命令
- search_web(query) → 搜索网络

同时面临三个新挑战：

上下文漂移（执行 10 步后初始指令已滚出窗口，解决方案是每 5 步阶段性总结并写入持久记忆）
决策一致性 （第 3 步和第 7 步的选择可能矛盾，需要在 System Prompt 里定义优先级排序）、工具滥用（Agent 可能无意义地反复调用工具，需要在 Prompt 里约束"不要为了调用工具而调用工具"）。
单 Agent 再强也有天花板------它所有能力在一个大脑里，跨领域的复杂任务（研究+分析+写作）必然顾此失彼。任务拆解的粒度、并行调度的效率、异常恢复的鲁棒性，都是单 Agent 架构的天然瓶颈。

你需要的不只是一个全能 Agent，而是一个分工协作的 Agent 团队。也就是Agent工作流，多Agent协同工作。

Agentic AI：Prompt 升维为系统宪法

单 Agent 的天花板在于"单一大脑"的物理限制------一个 Agent 同时思考"搜什么""怎么分析""怎么写法"时，每一步的决策质量都会下降。真正的工程团队不是这样工作的：你有一个研究员搜集资料、一个分析师提炼观点、一个写手输出文章------每个人只做自己最擅长的事，由一个负责人协调全局。

Agentic AI = 多 Agent 自主协作系统。 如果说 Agent 是一个能独立思考的工人，Agentic AI 就是一个拥有多个专业工人的工头------Orchestrator Agent 作为调度中枢，将复杂任务分解后派发给 SearchAgent、AnalyzeAgent、WriterAgent 等专业子 Agent，并行执行、汇总结果、处理异常。

在这一层，Prompt 的角色再次升级：它不再是单个 Agent 的决策规则，而是整个系统的宪法------定义了谁有权做什么、Agent 间如何通信、冲突如何仲裁、什么情况下必须暂停等待人类介入。

这不仅是 Agent 数量差异，而是架构层面的质变。Agent 是线性 Think→Act→Observe 循环，Agentic AI 是分解→并行调度→汇总→决策；Agent 只有当前会话上下文，Agentic AI 有跨 Agent、跨会话的共享记忆层（RAG 知识库）；Agent 单点失败即全局失败，Agentic AI 子任务级隔离不污染全局。

下方为Agentic AI 五层架构图

复制代码

┌─────────────────────────────────────────────┐
│          应用层（Use Cases）                 │ ← 数字员工 / 自动化流程 / 智能客服
├─────────────────────────────────────────────┤
│       编排与执行引擎（Orchestrator）         │ ← LangGraph / AutoGen / CrewAI
├─────────────────────────────────────────────┤
│           智能体核心层（Agent Core）          │
│      ┌────────┬────────┬────────┐           │
│      │ 记忆   │ 规划   │ 工具   │           │
│      └────────┴────────┴────────┘           │
├─────────────────────────────────────────────┤
│           大模型层（LLM Backbone）           │
│      ┌──────────────┬──────────────┐        │
│      │ 推理模型     │ 嵌入模型     │        │
│      └──────────────┴──────────────┘        │
├─────────────────────────────────────────────┤
│       基础设施（Infra & Ops）                │
│ 向量数据库 · 工具API · 监控日志 · AgentOps  │
└─────────────────────────────────────────────┘

Orchestrator Agent 的 Prompt 是整个系统的中枢神经：

markdown 复制代码

# Orchestrator Agent System Prompt

你是选题系统的总调度 Agent。每天 08:00 自动启动工作流。

## 工作流定义
1. 派发 SearchAgent → 搜集 GitHub/知乎/掘金热点
2. 等待 SearchAgent 返回，校验数据完整性
3. 派发 AnalyzeAgent → 筛选前端相关内容，输出 TOP 10 选题
4. 生成选题报告，推送给用户

## 调度策略
- 子 Agent 超时 120s → 重试一次，仍超时则降级（跳过该子任务）
- 子 Agent 返回异常 → 记录日志，换备用 Agent
- 两个子 Agent 结论矛盾 → 投票机制，平票则暂停等待人类仲裁

## 信息传递协议
SearchAgent 输出格式（AnalyzeAgent 的输入格式）：
{
  "items": [
    {"title": "xxx", "source": "github", "stars_today": 150, "url": "..."}
  ]
}

Agentic AI 的安全边界必须分三层。Vibe Coding 层的 Prompt 写错了，最多生成一段烂代码；Agentic AI 层的 Prompt 写错了------比如安全边界定义模糊------整个系统可能在你睡觉时做出不可逆的错误决策。这也是为什么 Prompt 工程的难度，随层次指数级增长：

markdown 复制代码

# Agentic AI 三层安全边界

## 🟢 自主执行区（Agent 可自行决定，无需确认）
- 搜索和收集公开信息
- 生成分析报告和草稿
- 代码审查和建议
- 读取本地非敏感文件

## 🟡 需确认区（暂停执行，等待用户明确批准）
- 发布内容到线上平台
- 修改生产环境配置
- 涉及用户隐私数据的操作
- 单次费用超过 ¥10 的 API 调用
- 修改超过 5 个文件

## 🔴 禁区（永不执行，即使用户要求也需二次确认）
- 删除任何文件或数据
- 以用户身份对外发送消息
- 修改系统级配置或注册表
- 执行 rm -rf / format / dd 等危险命令

全景演进对比表

层次	时间段	Prompt 形态	核心问题	Prompt 角色	典型工具	遗留问题 → 催生下一层
Prompt 基础	2023	自然语言指令	建立人与模型的有效通信	通信协议	ChatGPT	单次对话，无法系统化复用
Vibe Coding	2024	四板斧（身份+上下文+CoT+Few-shot）	把写代码变成描述需求	方向盘------控制输出方向和风格	Cursor, Copilot	每次都从零开始写 Prompt
Skills	2024-2025	结构化 Prompt + 触发规则 + 工具定义	Prompt 的封装与复用	基因------定义 Skill 的能力边界	ClawHub, IDE Skill 系统	AI 只能生成文本，无法操作外部世界
MCP	2025	工具描述 Prompt + 调用策略 Prompt	AI 与外部工具的标准化连接	翻译官------意图到工具调用的转换	MCP Server/Client	单步工具调用，处理不了多步复杂任务
Agent	2025	决策系统（Think→Act→Observe + 错误恢复）	多步自主任务执行	大脑------感知、决策、执行、反思回路	LangChain Agent, CrewAI	单 Agent 跨领域能力有限
Agentic AI	2025-至今	系统宪法（编排规则+安全边界+协作协议）	多 Agent 自主协作完成复杂工作流	宪法------定义系统权力分配和行为边界	多 Agent 编排框架	仍在演进中

核心以及如何避坑

Vibe Coding 层追求"一次写对"：上下文要全（技术栈、约束、边界条件全给），输出格式要锁死，一个 Prompt 一个变更（跟 Git commit 粒度对齐）。不要一次提多个不相关需求，不要用"优化一下"、"做好看点"等等这种模糊词。

markdown 复制代码

# Vibe Coding 自查清单
✅ 身份设定了吗？（"你是 XX 专家"）
✅ 技术栈上下文给了吗？（框架版本、UI 库、路径别名）
✅ 输出格式锁死了吗？（文件类型、代码语言、回复语言）
✅ 复杂任务拆解步骤了吗？（CoT 分步指令）
❌ 一次提了多个不相关的需求？
❌ 用了"优化一下""做好看点"等模糊词？

Skills 层追求"稳定可复用"：明确定义触发条件，输出格式固定（方便下游程序化解析），穷举边界情况（正常/异常/空输入分别输出什么）。一个 Skill 一个职责，不要留"由 AI 自行判断"的模糊地带。

markdown 复制代码

# Skill 质量检查
✅ 触发条件明确？（触发词列表 + 场景描述）
✅ 输出格式固定？（下游能程序化解析）
✅ 边界情况穷举？（正常输入 / 空输入 / 异常输入）
✅ 一个 Skill 一个职责？（单一关注点原则）
❌ 写了"由 AI 自行判断"？
❌ Skill 超过 200 行？（考虑拆分）

MCP 层追求"工具描述精准" ：工具描述包含用途、适用场景、局限和副作用，参数描述带示例值而非只写类型，写明可能返回的错误类型。工具名要具体（search_internal_docs 而不是 search），不要把多个不相关功能塞进一个工具。

typescript 复制代码

// MCP 工具描述自查
server.tool(
  "search_internal_docs",  // ✅ 具体名称
  "搜索公司内部文档。适用场景：...。局限：仅索引 Confluence 空间。副作用：无。", // ✅ 完整描述
  {
    query: z.string().describe("搜索关键词，如 'OKR 模板'"),  // ✅ 带示例
    limit: z.number().default(10).describe("返回条数，默认 10，最大 50"),
  },
  async ({ query, limit }) => { /* ... */ }
);

Agent 层追求"决策可靠"：定义清晰的终止条件（什么算"完成"），定义失败策略（重试几次、什么时候换方案、什么时候求助），定义步数上限。不给 Agent"我不知道"的选项就是逼它编造。

markdown 复制代码

# Agent 防失控配置
max_steps: 20          # 硬上限，防止无限循环
max_retries_per_step: 2  # 单步失败最多重试
timeout: 300s          # 全局超时
checkpoint_interval: 5  # 每 5 步写入持久记忆

Agentic AI 层追求"系统可控"：定义 Agent 间标准信息格式（输入输出契约），定义冲突消解机制，定义三层安全边界（自主区/确认区/禁区），必须留"紧急停止"入口。不要让 Agent 拥有超出任务需要的权限，不要假设 Agent 间的协作会自动"对齐"。

yaml 复制代码

# Agentic AI 编排配置（示例）
orchestrator:
  emergency_stop: true       # 紧急停止入口
  human_in_the_loop: true    # 关键决策需人类确认
  
security:
  autonomous: [search, analyze, draft]
  confirm_required: [publish, deploy, charge_api]
  forbidden: [delete_files, send_as_user, modify_system]

agents:
  - name: SearchAgent
    output_schema: { items: [{ title, source, score, url }] }
  - name: AnalyzeAgent
    input_schema: { items: [{ title, source, score, url }] }
    output_schema: { top_picks: [{ title, angle, score }] }

如何避坑

层次	最常见坑	后果	解法
Vibe Coding	一次提太多需求	AI 输出 500 行你不敢看	一次一个变更，跟 git commit 提交信息对齐
Skills	Skill 太大，触发模糊	该激活时不激活	一个 Skill 一个职责，触发词精确到场景
MCP	工具描述太简略	AI 不会用或用错	描述含用途、参数示例、成功/失败输出
Agent	上下文漂移	跑着跑着忘了最初要干啥	每 5 步总结，核心目标写入持久记忆
Agentic AI	Agent 间信息格式不对齐	数据传丢，结论矛盾	每个 Agent 的 I/O 格式在 Prompt 里明确定义

唯一不变的东西

三年前，我们用 HTML/CSS/JavaScript 描述界面。今天，我们用 Prompt 描述一切------界面、逻辑、工具、决策、系统。

Vibe Coding 里写的一段 Prompt，可以封装成 Skill，这个 Skill 可以被 Agent 调用，这个 Agent 可以成为你 Agentic AI 系统的一个专业子单元。

2023 年为一个代码审查写的 Prompt，经过三次迭代变成 Skill，2024 年这个 Skill 被 Agent 调度成为自动化工作流的一部分，2025 年这个 Agent 变成 Agentic AI 系统里的专业审查节点------每天自动审查团队所有 PR，在出问题之前拦住。

技术栈会迭代，框架会被替代。但 Prompt 的设计能力会持续增值，因为无论 AI 工具链怎么演化，人类和 AI 之间的通信协议只有一个------从一段文字到一个系统，这就是 Prompt 工程。

欢迎关注公众号：程序员蜡笔熊，欢迎大家评论区留言✌️