提示词工程 on KnightLi的博客

Prompt Optimizer：开源提示词优化、测试与 MCP 工具

Fri, 01 May 2026 03:09:07 +0800

Prompt Optimizer 是一个开源的提示词优化工具，目标很直接：帮助你把一段粗糙的提示词改得更清晰、更稳定，也更容易被大语言模型执行。

它不只是一个“帮我润色 prompt”的页面。项目同时提供提示词优化、结果测试、对比评估、多模型接入、图像生成提示词处理，以及 MCP 集成。对经常写系统提示词、用户提示词、AI 工作流模板的人来说，它更像一个专门用来打磨提示词的工作台。

它解决什么问题

很多人使用 AI 时都会遇到类似问题：

提示词越写越长，但模型输出没有明显变好
同一个需求换个模型就表现不稳定
系统提示词和用户提示词混在一起，很难拆开调试
改了一版 prompt，不知道是不是真的比上一版更好
想复用变量模板，但每次都要手动替换和测试
想把提示词优化能力接入其他 AI 工具，却缺少标准接口

Prompt Optimizer 主要围绕这些问题设计。它把“写 prompt”拆成优化、测试、评估、对比、迭代几个环节，让提示词不再只靠感觉调整。

主要功能

1. 优化系统提示词和用户提示词

提示词并不只有一种。

系统提示词通常负责定义角色、目标、边界、输出规范和工作方法；用户提示词则更接近一次具体任务的输入。两者混在一起时，模型容易抓不住重点，后续复用也困难。

Prompt Optimizer 支持系统提示词优化和用户提示词优化。你可以分别处理长期复用的角色设定，也可以处理某次具体任务的输入表达。

这对下面几类场景比较有用：

写 AI 编程助手的工作规则
写客服、审稿、翻译、分析类角色提示词
优化文生图提示词
把临时需求整理成可复用模板
为不同模型准备不同风格的 prompt

2. 测试和对比输出

只优化提示词还不够，关键是要知道优化后有没有变好。

项目支持分析、单结果评估、多结果对比评估。也就是说，你可以把原始提示词和优化后的提示词放到同一个任务里跑，看模型输出是否更准确、更稳定、更符合目标。

这比单纯“看起来更专业”的 prompt 更实用。因为很多提示词表面上写得完整，实际输出却可能更啰嗦、更僵硬，甚至把模型引向错误方向。对比测试能帮助你尽早发现这种问题。

3. 支持多模型

README 中提到项目支持 OpenAI、Gemini、DeepSeek、智谱 AI、SiliconFlow 等模型服务，也支持自定义 OpenAI 兼容接口。

这点很重要。提示词效果和模型强相关，同一段 prompt 在不同模型上的表现可能差别很大。多模型测试可以帮助你判断：

是提示词本身写得不好
还是某个模型不适合这个任务
是否需要为不同模型准备不同版本
小模型能否通过更清晰的提示词接近可用效果

如果你在本地使用 Ollama，或者公司内部有兼容 OpenAI 接口的模型服务，也可以通过自定义接口接入。

4. 高级测试模式

项目提供上下文变量管理、多轮会话测试和 Function Calling 支持。

变量管理适合模板化任务。比如你有一套闲置交易回复、商品描述、邮件回复、代码审查或文档生成提示词，只需要替换商品、价格、语气、目标用户等变量，就能快速测试不同输入下的表现。

多轮会话测试适合验证长期对话能力。很多 prompt 在单轮问答里看起来不错，一旦进入多轮追问，就会忘记约束、偏离角色或重复解释。多轮测试可以更接近真实使用场景。

Function Calling 支持则适合更工程化的 AI 应用。它能帮助你验证模型在工具调用、参数生成和结构化输出上的表现。

5. 图像生成提示词

Prompt Optimizer 也支持文生图和图生图相关能力，README 中提到集成 Gemini、Seedream 等图像模型。

文生图提示词的优化重点和文本任务不同。它更关注主体、构图、空间关系、风格、材质、光线、情绪和限制条件。把一句很模糊的想法拆成更可控的视觉描述，通常比单纯加长提示词更有价值。

如果你经常需要生成产品图、封面、插画、主视觉或风格参考图，这类优化会比较实用。

使用方式

项目提供多种入口：

在线版本
Vercel 自部署
桌面应用
Chrome 插件
Docker 部署
Docker Compose 部署
MCP Server

在线版本适合快速体验。项目说明中提到它是纯前端应用，数据存储在浏览器本地，并直接与 AI 服务商交互。

桌面应用适合需要直接连接各种模型 API 的用户。浏览器环境容易遇到跨域限制，桌面应用可以绕过这类问题，尤其适合连接本地 Ollama 或一些跨域策略严格的商业 API。

Docker 部署适合放在自己的服务器或内网环境里使用。README 给出的基础命令如下：

`1`	`docker run -d -p 8081:80 --restart unless-stopped --name prompt-optimizer linshen/prompt-optimizer`

如果要配置 API 密钥和访问密码，可以通过环境变量传入：

docker run -d -p 8081:80 \
  -e VITE_OPENAI_API_KEY=your_key \
  -e ACCESS_USERNAME=your_username \
  -e ACCESS_PASSWORD=your_password \
  --restart unless-stopped \
  --name prompt-optimizer \
  linshen/prompt-optimizer

国内访问 Docker Hub 较慢时，项目也提供了阿里云镜像地址，可按 README 中的说明替换镜像名。

MCP 能做什么

Prompt Optimizer 支持 Model Context Protocol，也就是 MCP。

通过 Docker 运行时，MCP 服务可以和 Web 应用一起启动，并通过 /mcp 路径访问。这样它就不只是一个网页工具，而是可以被 Claude Desktop 等支持 MCP 的应用调用。

README 中列出的 MCP 工具包括：

optimize-user-prompt：优化用户提示词
optimize-system-prompt：优化系统提示词
iterate-prompt：对已有提示词做定向迭代

这类接口很适合放进 AI 工作流里。比如你在写复杂任务提示词时，可以让支持 MCP 的客户端直接调用提示词优化能力，而不必每次打开网页手动复制。

和普通聊天工具有什么区别

普通聊天工具当然也能帮你改 prompt，但它通常缺少几个环节：

不方便保存和对比多个版本
不方便同时测试多个模型
不方便把变量模板化
不方便做多轮会话验证
不方便接入 MCP 或部署到自己的环境

Prompt Optimizer 的价值在于把提示词优化做成一个可重复的流程。它不只是给你一版“看起来更完整”的文本，而是让你围绕实际输出持续调整。

适合谁使用

如果你符合下面几种情况，可以重点关注这个项目：

经常写系统提示词
经常为 AI 应用设计角色和输出格式
需要比较不同模型的输出效果
想把 prompt 做成可复用模板
需要测试多轮对话或工具调用
想把提示词优化能力接入 MCP 工作流
希望在本地或内网部署提示词工具

如果你只是偶尔问 AI 一个简单问题，用普通聊天页面就够了。这个工具更适合那些把提示词当成可维护资产的人。

使用时要注意什么

第一，不要把优化结果当成绝对正确。

提示词优化工具可以提高表达质量，但不能保证模型一定不会误解。重要任务仍然需要测试样例、人工检查和版本对比。

第二，不要只追求更长。

好的 prompt 不一定更长。它应该更清晰地表达目标、边界、输入输出格式和判断标准。无意义的规则堆叠反而会让模型抓不住重点。

第三，要按模型调 prompt。

不同模型对角色设定、格式约束、推理步骤和示例的敏感度不同。一个在大模型上表现很好的提示词，不一定适合小模型。多模型测试正是这个工具值得使用的原因之一。

第四，部署时要考虑密钥和访问控制。

如果你把它部署到公网，应该配置访问密码，并谨慎处理 API key。项目支持通过环境变量配置访问控制，不要把敏感配置直接写到公开仓库里。

参考

linshenkx/prompt-optimizer

最后一句

Prompt Optimizer 适合用来把提示词从“临时手写的一段话”整理成“可以测试、可以比较、可以迭代的工作资产”。

当你开始在多个模型、多个场景、多个版本之间维护 prompt 时，这类工具会比普通聊天窗口更顺手。

Karpathy 的 65 行 CLAUDE.md：让 AI 编程少犯三类错误

Sun, 19 Apr 2026 18:27:23 +0800

最近 GitHub 上有一个围绕 AI 编程的项目很火，核心其实只是一个大约 65 行的 CLAUDE.md 文件。它之所以能拿到大量 star，不是因为技术实现复杂，而是因为它抓住了很多人使用 AI 写代码时反复遇到的问题。

这个项目的背景，要从 Andrej Karpathy 对 AI 编程的观察说起。Karpathy 是 AI 领域很有影响力的教育者和工程师：斯坦福博士，参与过 OpenAI 早期工作，也曾在 Tesla 负责 Autopilot 视觉系统。后来他持续分享对大模型、教育和 AI 工具的理解，所以他对编程方式变化的判断，总会引起很多开发者关注。

他在一次分享中提到，自己使用 Claude Code 几周后，编程方式发生了明显变化：过去大概是 80% 手写代码、20% AI 辅助，现在更接近 80% 让 AI 写代码，自己做 20% 修改。他形容这像是“用英语编程”，通过自然语言告诉 LLM 要写什么。

但他也指出了 AI 编程的几个典型问题。

01 错误假设

第一个问题是模型很容易替用户做假设，然后沿着这个假设一路写下去。它不一定会主动管理自己的困惑，也不一定会在需求含糊时停下来追问。

比如用户只说“添加用户导出功能”，模型可能会默认导出全部用户，默认输出 JSON，默认写成本地文件，默认权限和字段都不需要再确认。等代码写完，用户才发现它理解的需求和真实场景并不一致。

更好的做法应该是先把不确定点列出来：导出全部用户还是筛选结果？是浏览器下载还是后台任务？需要哪些字段？数据量大不大？是否有权限限制？这些问题不问清楚，后面写得越快，偏得也越远。

02 过度复杂化

第二个问题是模型很容易把简单问题写复杂。一个函数能解决的问题，它可能加上抽象类、策略模式、工厂模式、配置层和一堆“未来可能有用”的扩展点。

这类代码看起来很工程化，实际却增加了维护负担。AI 尤其擅长快速生成大量结构，但并不总能判断这些结构是否真的必要。结果就是一百行能解决的任务，被膨胀成一千行。

判断标准其实很直接：一个资深工程师看到这段改动，会不会觉得它过度设计？如果答案是会，就应该删掉多余层次，用最少的代码解决当前问题。

03 附带伤害

第三个问题是模型有时会修改或删除自己没有充分理解的代码。它可能在修一个小 bug 的时候顺手改注释、重排格式、清理看似无用的 import，甚至动到和当前任务无关的逻辑。

这类“顺手优化”很危险，因为它扩大了变更范围，也让 review 变得更困难。用户本来只想修复一个空邮件导致验证器崩溃的问题，结果模型顺便增强了邮件验证、加了用户名校验、改了文档字符串，最后很难判断到底哪一行影响了行为。

更稳妥的原则是：只动必须动的代码，只清理自己造成的问题。原本就存在的死代码、格式问题或历史包袱，除非任务明确要求处理，否则最多提醒一句，不要直接改。

04 把吐槽变成 CLAUDE.md

在 Karpathy 的观点被大量传播后，开发者 Forrest Cheung 做了一件很聪明的事：他把这些吐槽整理成可以执行的行为准则，写进一个 CLAUDE.md 文件。

这个项目没有复杂代码，关键就是把 AI 编程中最容易出问题的地方，转成明确的工作规则。大致可以概括为四条。

第一条是先想再写。不要默默假设，不要隐藏困惑；如果需求有多种理解，就把它们列出来；如果存在更简单的方案，也要说出来；该追问时追问，该反驳时反驳。

第二条是简单优先。不添加没被要求的功能，不为一次性代码做抽象，不加入多余配置，也不为极小概率场景写大量防御代码。如果 50 行能解决，就不要写成 200 行。

第三条是精准修改。每一行改动都应该能直接追溯到用户请求。不要顺手改善邻近代码，不要重构没坏的东西，尽量匹配项目既有风格。

第四条是目标驱动。不要只给模型一个模糊指令，而是给它可验证的成功标准。比如“修复 bug”可以变成“先写一个能复现 bug 的测试，再让测试通过”；“添加校验”可以变成“写无效输入测试并通过”。成功标准越清楚，模型越容易自己循环到完成。

05 为什么它会火

这个项目能火，不是因为内容很玄，而是因为它足够贴近真实开发。

很多人用 AI 编程时都经历过类似场景：模型自信地误解需求，代码越写越复杂，或者在不该动的地方动手。CLAUDE.md 的价值，是把这些经验变成可以放进项目里的协作规则。

它的门槛也很低：一个文件就能开始生效，不需要复杂接入。再加上 Karpathy 本人的影响力，以及项目里有实战对比案例，它很自然会在 Claude Code 用户和 AI 编程社区里传播开来。

更重要的是，这类规则不是只适用于 Claude Code。无论使用哪种 AI 编程工具，本质问题都很相似：模型需要知道什么时候该问、什么时候该简化、什么时候该停手、怎样判断任务已经完成。

06 对普通开发者的启发

这件事给普通开发者的启发很简单：AI 编程不是把一句需求丢给模型，然后等待奇迹发生。真正有效的方式，是给模型建立边界。

需求不清楚时，让它先暴露假设。实现方案变复杂时，让它主动回到最小可行解。修改代码时，让它只围绕任务目标行动。完成任务时，用测试、命令或明确检查点来验证结果。

AI 写代码的能力已经很强，但它仍然需要好的协作约束。一个短小的 CLAUDE.md 能获得大量关注，说明开发者真正需要的并不只是更聪明的模型，也包括更可靠的工作方式。

简单总结：

先想再写，减少错误假设。
简单优先，避免过度设计。
精准修改，控制变更范围。
目标驱动，用可验证标准推动完成。

这四条并不复杂，却很实用。AI 编程真正提升效率的前提，不是让模型写得更多，而是让它写得更准、更少、更可控。

什么是 Agent Skills：从设计理念到上下文优化

Sat, 28 Mar 2026 00:00:00 +0000

Agent Skills 是一种将程序性知识标准化封装的方式。简而言之，它解决的不是“有没有工具”，而是“如何把工具用对、用好”。

1. 核心设计理念

Agent Skills 的核心价值在于沉淀“方法论”：

提供领域知识，指导智能体在具体场景下如何组合与调用工具。
约束执行路径，减少试错成本，提升任务完成的一致性。
让复杂流程可复用、可迭代，逐步形成稳定 SOP。

如果把工具能力比作“硬件接口”，那么 Skills 更像“操作说明书”与“最佳实践集合”，定义的是“该怎么做”。

2. 渐进式披露：破解上下文困境

Agent Skills 最核心的创新是渐进式披露（Progressive Disclosure）：按需加载信息，避免一次性把大量内容塞进上下文窗口。

2.1 第一层：元数据（Metadata）

每个技能通常位于独立文件夹中，核心文件是 SKILL.md。该文件以 YAML Frontmatter 开头，定义技能基础信息。

智能体启动时，只读取所有技能的 Frontmatter 并注入系统提示词。根据实践经验：

单个技能元数据消耗约 100 tokens
50 个技能约消耗 5,000 tokens

2.2 第二层：技能主体（Instructions）

当某个技能被判断为与当前任务高度相关时，智能体才会读取完整 SKILL.md，加载详细指令、注意事项和示例。

这部分 token 消耗通常与技能复杂度相关，常见范围为：

1,000 到 5,000 tokens

2.3 第三层：附加资源（Scripts & References）

复杂技能可在 SKILL.md 中引用脚本、配置和参考文档，仅在需要时加载。

示例目录结构：

skills/pdf-processing/
├── SKILL.md                 # 主技能文件
├── parse_pdf.py             # PDF 解析脚本
├── forms.md                 # 表单填写指南（仅在填表任务时加载）
└── templates/
    ├── invoice.pdf
    └── report.pdf

典型调用方式：

需要解析 PDF 时，执行 parse_pdf.py
遇到填表任务时，再加载 forms.md
模板文件仅在输出特定格式文档时访问

3. 为什么这种设计有效

3.1 可扩展的知识容量

通过“脚本 + 外部文件”，技能可携带远超上下文窗口容量的知识。例如，一个数据分析技能可以附带 1GB 数据文件和查询脚本，智能体通过执行脚本访问数据，而不是把整份数据集直接塞进上下文。

3.2 更强的确定性

将复杂计算、数据转换、格式解析交给代码执行，可以显著降低 LLM 在纯文本生成中的不确定性与幻觉风险。

4. 实际效果：从 16k 到 500 Token

社区实践显示，渐进式披露能显著降低初始上下文开销：

传统 MCP 方式：直接连接包含大量工具定义的 MCP 服务，初始化约 16,000 tokens
Skills 包装后：先用轻量 Skill 作为“网关”，仅通过 Frontmatter 描述能力，初始化约 500 tokens

当任务真正需要时，再按需加载详细指令与附加资源。这样既降低了初始成本，也让对话过程中的上下文管理更精准。

总结

Agent Skills 的关键意义在于：把“工具可用”升级为“能力可复用”。通过渐进式披露，系统可以在保持能力深度的同时，显著优化 token 成本与执行稳定性。

普通人如何指挥 AI 干活：从图片中提取图形与数学公式（实战示例）

Thu, 26 Mar 2026 00:00:00 +0000

前提条件

安装 VS Code，并安装 Codex 插件，可参考 VS Code Codex使用的文章。
使用这些工具并不要求你有编程经验。VS Code 在这里主要用于组织文件；你只需提出需求，AI 就会自动编写程序并执行。
本文记录完整操作过程，目的是抛砖引玉，探索更多 AI 的实用方法，让更多普通人受益。

任务目标

准备一张同时包含数学公式和示意图形的图片：

我们希望实现三件事：

将图形切分成干净的小图。
识别公式并转换为 LaTeX，便于后续修改。
将图形与对应公式建立关联。

过程

先识别图片，生成 Markdown 文档，并将公式转换为 LaTeX

转换结果：

# 1.png 识别结果

## 几何公式（LaTeX）

1. 三角形面积（边长与外接圆半径）：

$$
S = \frac{abc}{4R}
$$

2. 三角形面积（内切圆半径与半周长）：

$$
S = pr
$$

3. 圆台体积：

$$
V = \frac{\pi\left(r^2 + Rr + R^2\right)h}{3}
$$

4. 圆台侧面积：

$$
S = \pi a(R + r)
$$

5. 圆柱体积：

$$
V = \pi r^2 h
$$

6. 圆柱侧面积：

$$
S = 2\pi rh
$$

7. 球体积：

$$
V = \frac{4}{3}\pi R^3
$$

8. 球表面积：

$$
S = 4\pi R^2
$$

9. 正弦定理：

$$
\frac{a}{\sin A}=\frac{b}{\sin B}=\frac{c}{\sin C}=2R
$$

10. 余弦定理：

$$
a^2=b^2+c^2-2bc\cos A
$$

$$
b^2=a^2+c^2-2ac\cos B
$$

$$
c^2=a^2+b^2-2ab\cos C
$$

公式都被识别出来了，AI 还自动补充了公式名称，效果很好；但此时还没有完成小图裁剪。

尝试让 AI 裁剪图片

# 1.png 识别结果（图文并排，精修裁图）

<table>
  <tr>
    <td>![](crops/01_triangle_circum.png)</td>
    <td>

$$
S = \frac{abc}{4R}
$$

</td>
  </tr>
  <tr>
    <td>![](crops/02_triangle_incircle.png)</td>
    <td>

$$
S = pr
$$

</td>
  </tr>
  <tr>
    <td>![](crops/03_frustum.png)</td>
    <td>

$$
V = \frac{\pi\left(r^2 + Rr + R^2\right)h}{3}
$$

$$
S = \pi a(R + r)
$$

</td>
  </tr>
  <tr>
    <td>![](crops/04_cylinder.png)</td>
    <td>

$$
V = \pi r^2 h
$$

$$
S = 2\pi rh
$$

</td>
  </tr>
  <tr>
    <td>![](crops/05_sphere.png)</td>
    <td>

$$
V = \frac{4}{3}\pi R^3
$$

$$
S = 4\pi R^2
$$

</td>
  </tr>
  <tr>
    <td>![](crops/06_laws.png)</td>
    <td>

$$
\frac{a}{\sin A}=\frac{b}{\sin B}=\frac{c}{\sin C}=2R
$$

$$
a^2=b^2+c^2-2bc\cos A
$$

$$
b^2=a^2+c^2-2ac\cos B
$$

$$
c^2=a^2+b^2-2ab\cos C
$$

</td>
  </tr>
</table>

结果：图片已经裁剪并放到了对应位置，但仍有干扰区域，裁剪边缘不够干净。

修正“裁切过度”问题：先尽量保留完整图形，再手工去除多余部分
这一步的效果还不稳定，目前不确定是提示词问题，还是模型在视觉定位上的波动。

总结

使用 Codex 和直接在 chatgpt.com 对话，体验明显不同。
在 chatgpt.com 中，更像是 AI 在指导你完成工作；而在 Codex 中，更像是 AI 按照你的要求去执行工作。
当你提出需求后，AI 会生成程序、运行程序并完成任务，你会更明显地感受到“自己在指挥 AI 干活”。
整个流程对编程基础要求并不高，普通人也可以逐步上手并产出成果。