5 款值得关注的 Prompt 管理工具评测

Hello, I'm Shrijith Venkatramana. I'm building git-lrc, an AI code reviewer that runs on every commit. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

We have excellent tooling for source code.

Git tracks it. Package managers organize it. Compilers validate it. Test frameworks catch regressions. CI tells us when a change breaks something.

Then we build an AI application and put the most important part of the system in a 400-line Python string.

prompt = """
You are a senior software engineer...

IMPORTANT:
- Be precise
- Don't hallucinate
- Review security issues
...
"""

Soon there are 30 such prompts.

Some are duplicated. Some have slightly different versions of the same instruction. Nobody knows which one is canonical. Changing one prompt requires hunting through the codebase. And testing whether the new version is actually better becomes a manual exercise.

This is why prompt management is becoming its own category of developer tooling.

There are already several projects attacking different parts of this problem. Some focus on organizing prompts as files, some on composition, some on testing and evaluation, and some on integrating prompts directly into GitHub workflows.

Here are five worth knowing about.

1. Prompty — Put Prompts in Proper Files

The simplest problem to solve is also the most common:

Stop burying prompts inside application code.

Prompty from Microsoft provides a structured .prompty format for representing prompts as standalone artifacts.

prompt = """
You are an expert code reviewer.
...
"""

you can have something like:

prompts/
└── code-review.prompty

with Markdown containing the human-readable prompt and YAML frontmatter describing metadata and inputs.

---
name: code-review
description: Review a code diff
inputs:
  diff:
    type: string
model:
  configuration:
    type: openai
    model: gpt-4o
---

You are an expert software engineer.

Review the following diff for:
- correctness
- security
- maintainability

<diff>
{{diff}}
</diff>

The immediate benefit is surprisingly large.

• independently versionable
• separable from application code

You can now review a prompt change as a normal Git diff.

When Prompty makes sense

Prompty is particularly attractive if your main problem is:

"We have prompts scattered throughout our application and need a standard format for managing them."

It is a good first step toward treating prompts as software artifacts.

2. PromptKit — Compose Prompts From Components

Once you have 50 prompts in a repository, another problem appears.

Suppose every prompt contains:

You are an experienced software engineer.

Be precise.
Do not invent facts.
Only make claims supported by the supplied code.

You don't want to copy that into 50 files.

You want reusable components.

PromptKit explores this model.

Instead of thinking of a prompt as one giant document:

Prompt

you can think of it as an assembly of components:

                    ┌── Persona
                    │
Task ───────────────┼── Protocol
                    │
                    ├── Format
                    │
                    └── Taxonomy

components/
├── personas/
│   └── senior-engineer
├── protocols/
│   ├── don't-hallucinate
│   └── security-review
└── formats/
    └── code-review

tasks/
└── review-security

The security-review prompt can then be composed from those pieces.

name: review-security

persona: senior-engineer

protocols:
  - don't-hallucinate
  - security-review

format: code-review

The library resolves those dependencies into the final prompt sent to the model.

This is where prompt management starts becoming interesting.

You're no longer merely storing prompts.

You're building prompts from reusable source components.

When PromptKit makes sense

PromptKit is interesting if your problem is:

"We have a growing prompt library and don't want to copy the same instructions everywhere."

It also introduces ideas such as dependencies, contracts and structured composition that become important as prompt repositories grow.

3. Promptfoo — Test Your Prompts Like Code

There is a fundamental problem with prompts that doesn't exist to the same degree with ordinary deterministic code:

A successful execution tells you almost nothing about whether the prompt is good.

Review this code for security vulnerabilities.

will execute successfully.

Review this code for security vulnerabilities.
Only report vulnerabilities that have a concrete exploit path.
Do not speculate.
Explain the affected code and remediation.

But which one performs better?

You need evaluations.

Promptfoo focuses heavily on this side of the problem.

You define prompts, test cases, model providers and assertions.

A simplified test might look like:

tests:
  - description: detects SQL injection
    vars:
      code: |
        db.query("SELECT * FROM users WHERE id=" + id)
    assert:
      - type: contains
        value: SQL injection

  - description: doesn't invent vulnerabilities
    vars:
      code: |
        const user = await db.users.findById(id)
    assert:
      - type: not-contains
        value: SQL injection

You can initialize a project with:

npx promptfoo@latest init

and run evaluations with:

npx promptfoo@latest eval

Then inspect the results with:

npx promptfoo@latest view

The interesting part is that Promptfoo allows you to compare different prompts and models against the same test suite.

You can therefore turn:

"I think this prompt is better"

into:

Prompt A → 82% evaluation score
Prompt B → 91% evaluation score

It can also run evaluations in CI, making prompt changes part of the normal software-development workflow.

When Promptfoo makes sense

Promptfoo is particularly useful when your problem is:

"We change prompts frequently and need to know whether we're introducing regressions."

It is less about organizing the source files and more about measuring what those prompts actually do.

4. GitHub .prompt.yaml — Store Prompts Alongside Your Code

GitHub has also moved toward treating prompts as repository artifacts.

With GitHub Models, prompts can be stored in a repository using .prompt.yml or .prompt.yaml files.

A simplified example:

name: explain-code
description: Explain a code snippet

model:
  api: chat
  parameters:
    temperature: 0.2

messages:
  - role: system
    content: |
      You are an expert software engineer.
      Explain code precisely and concisely.

  - role: user
    content: |
      Explain this code:

      {{code}}

The important idea here isn't the particular YAML syntax.

prompt
   │
   ▼
Git repository
   │
   ├── pull request
   ├── review
   ├── history
   ├── branches
   └── CI

Your prompt becomes a first-class part of the repository.

That means a prompt change can go through the same process as a code change:

Developer changes prompt
        ↓
Git diff
        ↓
Pull request
        ↓
Review
        ↓
Tests / evaluation
        ↓
Merge

This is particularly attractive for teams that already live inside GitHub and don't want another prompt-management system.

When .prompt.yaml makes sense

It makes sense if your primary requirement is:

"I want prompts version-controlled and integrated with the same GitHub workflow as the rest of my application."

5. OpenAI Prompt Management — Manage Prompts Outside Application Code

A different approach is to move prompt management into the model platform itself.

OpenAI's API provides prompt management through reusable, versioned prompts that can be referenced from API requests rather than embedding the complete prompt in application code.

The conceptual workflow becomes:

Application
    │
    │ prompt ID + variables
    ▼
Prompt registry
    │
    ▼
Versioned prompt
    │
    ▼
OpenAI model

This can be useful when prompts are changing frequently and you want to decouple prompt iteration from application deployments.

For example, application code can conceptually do:

response = client.responses.create(
    prompt={
        "id": "pmpt_...",
        "version": "3",
        "variables": {
            "code": source_code
        }
    }
)

The application doesn't need to contain the complete prompt.

This introduces a different trade-off from the Git-based approaches.

With repository-based prompt management:

Git repository
      ↓
prompt source
      ↓
application

With platform-managed prompts:

application ──────► prompt registry
                         │
                         ▼
                       model

The latter can make experimentation and centralized prompt operations easier, especially when prompts are managed by people who aren't modifying application code directly.

These projects aren't necessarily competitors.

They address different layers of the problem:

You can visualize the overall space like this:

                 PROMPT ENGINEERING
                        │
        ┌───────────────┼────────────────┐
        │               │                │
     Storage         Composition       Testing
        │               │                │
     Prompty        PromptKit        Promptfoo
        │
        │
     Workflow
        │
   GitHub prompts
        │
        │
   Runtime / Registry
        │
 OpenAI Prompt Management

And there is still a lot of room for tooling.

A mature prompt-development stack could eventually look more like a compiler toolchain:

                   prompt source
                        │
                        ▼
                     parser
                        │
                        ▼
                  dependency graph
                        │
                        ▼
                   composition
                        │
                        ▼
                    validation
                        │
                        ▼
                    compiler
                        │
                        ▼
                 evaluation suite
                        │
                        ▼
                  model runtime

At that point, prompts have:

That is a very different world from putting a multiline string in app.py.

Prompt management is still a young category, and there isn't one universally accepted abstraction yet.

Some tools treat a prompt as a structured document. Others treat it as a composable program. Others focus on testing. Others integrate it into an existing model or Git platform.

That fragmentation is probably healthy.

The underlying problem is real: as AI applications become larger, prompts are becoming software artifacts, and software artifacts need engineering infrastructure.

If you're building an AI application today, a reasonable progression is:

Small project
    → prompt files

Growing project
    → structured prompt format

Many prompts
    → composition + reuse

Frequent changes
    → evaluation tests

Large team
    → Git + CI + versioning

The interesting question is where this ends.

Do prompts eventually need something analogous to a programming language—imports, types, dependency graphs, compilation and static analysis—or will Markdown/YAML plus good testing remain enough?

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

Free, Micro AI Code Reviews That Run on Git Commit

| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 | 🇮🇳 हिन्दी |

Free, Micro AI Code Reviews That Run on Commit

GenAI today is a race car without brakes. It accelerates fast -- you describe something, and large blocks of code appear instantly. But AI agents silently break things: they remove logic, relax constraints, introduce expensive cloud calls, leak credentials, and change behavior -- without telling you. You often find out in production.

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

For further actions, you may consider blocking this person and/or reporting abuse