在所有批评家中，最伟大、最正确，最天才的是时间。——别林斯基

“AI 工具的系统提示词到底长什么样？”——x1xhlol/system-prompts-and-models-of-ai-tools 仓库导读（基于 README + Description）

面向读者：做 AI 应用 / Agent / 提示词工程 / 安全与红队的人；以及任何好奇“IDE 里的 AI 编程助手在系统层到底怎么说话”的开发者
仓库：https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools
License：GPL-3.0（仓库页面显示）
GitHub Description（原文，信息量很大）：
“FULL Augment Code, Claude Code, Cluely, CodeBuddy, Comet, Cursor, Devin AI, Junie, Kiro, Leap.new, Lovable, Manus, NotionAI, Orchids.app, Perplexity, Poke, Qoder, Replit, Same.dev, Trae, Traycer AI, VSCode Agent, Warp.dev, Windsurf, Xcode, Z.ai Code, Dia & v0. (And other Open Sourced) System Prompts, Internal Tools & AI Models”

0. 这仓库是干什么的？一句话版

这是一个收集与整理各类 AI 工具（尤其是 coding agent / IDE 内置 AI / AI 产品）的 system prompts、内部工具描述、以及相关 AI 模型信息的集合仓库。

如果你曾经在使用 Cursor、Devin、Windsurf、Claude Code、Replit、Perplexity 等工具时好奇过：

“它在系统提示词里到底给了哪些规则？”
“它有哪些内置工具（tools）？工具调用格式是什么？”
“它为什么会拒答某些请求、又为什么会强制某些输出格式？”
“这些产品的提示词泄露会带来什么安全风险？”

那这个仓库基本就是冲着这些问题来的。

1. README 透露出的仓库气质：它不只是一份“列表”，更像“情报库”

仅从主 README（根目录 README.md）就能看出几个特点：

1.1 规模感：不是几十行“摘抄”，而是大量结构化内容

README 明确写到：

📜 Over 30,000+ lines of insights into their structure and functionality.

它强调的是“insights into their structure and functionality”，也就是不仅仅“贴一段 prompt”，而是更偏向把这些提示词/系统指令当作可分析对象。

1.2 它提供了外部的“阅读/索引入口”

README 里出现了两个很关键的入口（都是原样链接）：

Ask DeepWiki：https://deepwiki.com/x1xhlol/system-prompts-and-models-of-ai-tools
Build Status（cloudback.it）：README 里有 badge 链接到 https://cloudback.it

这通常意味着：仓库内容可能非常多、且更新频繁，所以作者希望读者能用更“可检索”的方式阅读，而不是在 GitHub 页面里一页页翻目录。

1.3 它也在谈“安全”，而且明确面向 AI Startup

README 有一个章节标题非常直白：

🛡️ Security Notice for AI Startups

并且核心意思是（按 README 文字）：

暴露的 prompts 或 AI models 可能成为攻击目标
并给出一个外部服务链接 ZeroLeaks：https://zeroleaks.ai/（README 原样链接）

这部分表明作者的立场很明确：system prompt / tool schema / 模型配置本身就是资产，也是潜在攻击面。

2. 你应该怎么逛这个仓库？从“目录型 README”入手

这类“合集型仓库”最怕两件事：

内容很多但不知道从哪儿开始
只看热闹，不知道怎么把它用到工作里

一个实用的逛法是：

从根 README 了解定位与入口
然后从具体某个工具的子目录 README切入（比如你正在用的工具、或你想对标的工具）

比如我在仓库里读到的一个子目录示例是：

Amp/README.md：讲如何获取 Amp（ampcode.com）的 system prompt（README 标题原文：How to obtain the system prompt for Amp）

这说明仓库不只是“放结果”，还会放获取方法（how to obtain）：这对研究人员、复现者、以及做安全评估的人非常关键。

说明：我使用了代码搜索定位 README 文件。GitHub 代码搜索结果可能不完整（工具限制最多返回部分结果）。你可以在 GitHub UI 直接查看更多匹配：
https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools/search?q=README.md&type=code

3. 一个具体例子：Amp 的 README 在教你��样“拿到 system prompt”

Amp/README.md 这份文档本身就很像“取证/提取教程”，内容结构也很清晰：

登录 Amp（通过 VSCode）
发起一次短查询
在界面里按住 Alt/Option 点击 workspace 按钮
查看 Thread YAML（并配图）
备注里还提到：system prompt “tuned to Sonnet 4.x”，并且把其他 LLM 作为 tools 注册（称为 “the oracle”）
如果要拿到 GPT-5 tuned 的 system prompt，需要改 VSCode 用户设置

它提供的 VSCode settings 例子（README 原文）：

{
    "amp.url": "https://ampcode.com/",
    "amp.gpt5": true
}

这一小段其实信息密度很高，因为它暗示了：

同一个产品可能存在多个“系统提示词配置档位”（随模型/模式变化）
“系统提示词”不是静态文本，而是与“工具注册/模型选择/客户端配置”耦合的
获取 prompt 的过程可能需要借助客户端 UI 的某种 debug/inspection 能力（这里是 Thread YAML）

对做 agent 的人来说，这段内容几乎可以直接转化为一个研究任务清单：

记录不同模型/模式下 system prompt 的差异
记录 tools 清单与工具调用格式的差异
评估哪些信息属于“配置泄露风险”（prompt、tool schema、内部 endpoint 等）

4. 为什么“系统提示词与内部工具”值得单独做成一个仓库？

如果把 LLM 产品当成一个系统，很多人只看见“聊天框”，但真正决定行为边界的，往往是三层：

System Prompt / Developer Prompt：高优先级规则、风格约束、拒答策略
Tools / Function Calling 规范：它能做什么（读写文件？发网络请求？调用 IDE API？）
Runtime / Client：UI 里有哪些调试口、日志口、导出能力、以及默认配置

这个仓库聚焦的，基本就是 1 + 2（以及部分 3 的获取方式/线索）。

所以它对不同人群的价值会不一样：

提示词工程 / Agent 开发者：你能看到“成熟产品”是如何描述工具、拆分职责、限制输出、做安全边界的
AI 安全 / 红队 / 防护团队：你能把 system prompt 当作“策略层”，把 tools 当作“能力层”，从而系统化地梳理攻击面
产品/架构对标：你可以对比不同工具在“默认行为、风格、权限、工具链”上的差异

5. 直接可用的“代码案例”：用一个小脚本把仓库里的 prompts 当作数据集来分析

下面给一个完全通用、且不依赖仓库私有实现的例子：
把仓库里所有 .md/.txt/.json 文件扫出来，做一个“索引表”，方便你本地检索、统计、做差异对比。

注意：这是示范用法，不声称仓库一定是这些格式；只是作为“如何把仓库当数据集”的通用起点。

# analyze_repo_files.py
from pathlib import Path
import hashlib
import json

ROOT = Path(".")  # 在仓库根目录执行
TARGET_SUFFIX = {".md", ".txt", ".json", ".yaml", ".yml"}

def sha256(p: Path) -> str:
    h = hashlib.sha256()
    h.update(p.read_bytes())
    return h.hexdigest()

items = []
for p in ROOT.rglob("*"):
    if not p.is_file():
        continue
    if p.suffix.lower() not in TARGET_SUFFIX:
        continue
    # 简单跳过常见大目录/二进制目录可以自行加规则
    items.append({
        "path": str(p.as_posix()),
        "bytes": p.stat().st_size,
        "sha256": sha256(p),
    })

items.sort(key=lambda x: x["path"])

print(json.dumps({
    "count": len(items),
    "items": items[:200],  # 先截断展示；需要全量就去掉
}, ensure_ascii=False, indent=2))

你可以在本地这样跑：

1	python analyze_repo_files.py > index.json

然后就能把 index.json 喂给你自己的分析流程（差分、聚类、关键词检索、prompt 模板抽取等）。

如果你想更进一步，可以做：

按目录统计文件数量/体积
提取每个 prompt 中的“工具列表段落”
抽取强约束句式（比如 MUST / NEVER / ALWAYS 等）做策略对比

6. 读这个仓库时，一个很实用的“心智模型”

把每个 AI 工具都当成一个“三件套”：

Policy（策略）：系统提示词在规定什么？优先级如何？
Capability（能力）：有哪些 tools？每个 tool 的输入输出是什么？
Interface（入口）：从 UI / 配置 / 日志 / YAML thread 里怎么拿到这些信息？

Amp/README.md 就是典型的 “Interface（入口）”文档：它告诉你从哪儿点、怎么看 YAML。

而仓库 description 列的那一串工具名，意味着作者试图覆盖大量产品——也就是让你能横向对比这些“三件套”。

7. 写在最后：它更像“AI 工具时代的 View Source”

早年做 Web 开发，很多人都是从“查看源代码（View Source）”开始理解一个网站如何工作。

而在 AI 工具时代，“系统提示词 + 内部��具描述 + 模型配置线索”，某种程度上就是新的“源代码”：

它决定行为边界
它决定能力范围
它决定产品的“性格”与“默认立场”
它也决定安全风险的形态

x1xhlol/system-prompts-and-models-of-ai-tools 的价值不在于让你“抄一个 prompt 就变强”，而在于它让你能更系统地回答：

一个 AI 工具的“真实形态”，到底由哪些隐藏层构成？