LangGPT：把提示词变成一门「编程语言」的结构化范式

一、故事从一次翻车开始

想象一个场景：周一早上，你让大模型「帮我写一份周报」。它写得很漂亮，但格式全错、语气浮夸，还顺手编造了两条不存在的数据。你改提示词再试，它换了个毛病。你再改，它开始客套。三个来回，半小时过去——你不是在用 AI 干活，而是在跟一个记性很差的实习生拉锯。

2023 年 5 月，一位叫云中江树的中文 AI 社区作者把这个问题换了个问法：既然代码有语法、有结构、有工程规范，为什么提示词不能有？他动手写出了第一批带固定段落结构的中文提示词模板，放到 GitHub 上。这个仓库就是 LangGPT。

图：LangGPT 项目 Logo（取自仓库 imgs/logo.png）

三年多过去，它积累了 12,653 个 Star、约 800 位贡献者，成为中文 AI 圈里被引用最多的提示词方法论，并被完整写成学术论文发表在 arXiv（2402.16929）。项目作者后来把它形容为一种「已经被模型内化的母语」——你不必再给它贴模板，只要说一句「用 LangGPT 的方式写」，主流大模型就会自己吐出结构化提示词。

二、它到底解决什么

LangGPT 给出的是一套提示词的结构语法，而不是一堆零散的「技巧清单」。

传统提示词工程依赖散装经验：想让模型别编造？加一句「不要胡编」；想让格式稳定？再追一句「请用 Markdown 输出」。这些补丁互不兼容、越加越长，也没法沉淀成可复用的资产。

LangGPT 的做法是给提示词设计一套类似程序语言的层级结构。最基本的骨架长这样：

# Role: 角色名

## Profile
- Author / Version / Language / Description

## Goal
- Outcome：本次会话要交付的具体结果
- Done Criteria：判断完成的验收标准
- Non-Goals：明确不做的部分，防止范围蔓延

### Skill-1
1. 具体技能描述
2. 期望行为与输出

## Rules
1. 不破坏角色设定
2. 不编造事实

## Workflow
1. 分析用户输入与意图
2. 系统性调用相关技能
3. 交付结构化可执行结果

## Initialization
作为 <Role>，你必须遵循 <Rules>，用 <Language> 与用户对话，并先做自我介绍与工作流说明。

关键设计在于三点。

第一，Goal 段引入了「验收标准」与「非目标」这对工程化概念。 这是最容易被忽略、也最有效的一段。「Done Criteria」把模糊需求翻译成可判定的条件，「Non-Goals」则提前掐断模型最常见的一种失败模式——把一个小请求做成一个项目。

第二，用 <变量> 语法实现参数化复用。 同一套角色模板，换变量就能变成另一个角色的提示词，像函数一样被反复调用。模板仓库 LangGPT/templates/ 提供了 Role、autoGPT、baseRole 三套骨架，以及 miniRole 的 md / yaml / json 三种写法（作者明确建议程序员用 yaml/json，非程序员用 Markdown）。

第三，规则与工作流分离。 Rules 是不可逾越的硬约束，Workflow 是可执行的软流程——这个分层让提示词可以局部迭代而不破坏整体。

三、生活里的比喻

如果提示词是信，那 LangGPT 就是公文格式。写一封普通信，想怎么写怎么写；写公文，标题、主送、正文、落款各有其位，格式固定到可以互相套用。不是信的内容变好了，而是格式本身让内容不必每次重新发明表达方式。

再往前一层，LangGPT 与「提示词技巧」的关系，就像 SQL 与「查询数据库的小技巧」的关系——有了结构化语法，查询才可复用、可交接、可优化。

四、生态与落地形态

仓库的形态本身就说明了这是一套「知识资产」而非软件产品：

• Docs/ — 三十余篇提示词哲学长文，从《对话动力学》《五种理性》到《Prompt 的本质》《语言控制学》，后者甚至给出了五条公理、三十个定义、二十九条定理，把提示词当作一门形式系统来做
• Prompts/ 与 examples/ — 巴菲特 AI 分身、小红书爆款账号定位架构师、马斯克 AI 分身、数学导师等成套可抄模板
• LangGPT/ — 面向 GPT-3.5/4、Claude 2 的成品提示词与模板
• src/ — 两个实验性 Jupyter Notebook（YOLOv10、SAM 的图像提示词实验）外加一个 markdown→json 转换脚本
• PromptShow/ — 一个独立的 Next.js 12 站点，把提示词渲染成好看的分享图，在 show.langgpt.ai 上线
• langgpt.skill — 打包好的 Claude Code 技能，可直接解压到 ~/.claude/skills/ 使用，也上架了 Claude 官方插件市场

图：LangGPT 生态与社区宣传图（取自仓库 imgs/wx_tmp.jpg）

上手门槛极低，有四条路径：直接对模型说「用 LangGPT 的方式写」；用官方的 LangGPT GPTs / Kimi+ 版本自动生成；照着骨架模板改；或者从示例库挑一个改。

五、争议与局限

它没有在通用 NLP 基准上证明自己。 arXiv 论文给出的是设计范式与案例分析，而非严格的对照实验。与后续出现的各类 Agent 编排框架相比，LangGPT 停留在「单轮提示词结构」层面，缺少多轮状态管理、工具调用协议与执行闭环——这也是它的 Skill 模板里 Workflow 常常止步于「分析→计划→执行」三步的原因。

结构化并非对所有场景都最优。 对于需要发散 brainstorming 的任务，冗长的骨架反而会压缩模型的探索空间。作者自己也提醒：非程序员友好的是 Markdown，但形式越重，token 成本越高。

维护呈现「文档重、代码轻」的失衡。 主语言被 GitHub 统计为 Jupyter Notebook，但核心逻辑是 Markdown 文本；src/ 下两个 Notebook 体积接近 1MB 却与主线框架无耦合，更像是作者个人的图像提示实验。仓库中 LICENSE 是 Apache-2.0，而 README 顶部徽章写的是 MIT，且内置的 PromptShow 子项目又是独立的 MIT 许可——三处许可信息不一致，是开源合规上真实存在的瑕疵。

「已被模型内化」的叙事需要打折。 模型是否真的记住某个提示词框架，取决于训练语料覆盖与版本迭代，官方并无公开评测支撑「说出名字就能得到标准输出」这一强主张。把它当作优质模板库用，比当作咒语用要靠谱得多。

六、行业意义

LangGPT 真正的贡献是把提示词从「一次性文本」推向「可版本管理、可复用、可协作的工程资产」，并用论文和体系化文档为这条路线提供了中文学术背书。它与 CoT、ReAct 等英文社区方法论的最大区别在于：LangGPT 用一套人类可直接阅读的 Markdown 骨架，把提示词工程的门槛从「会写英文论文的人」拉到了「会用 Markdown 的中文产品经理」。

三年时间从 3,000 Star 涨到 12,653 Star、贡献者接近 800 人，PromptShow 独立成站、Claude Code 官方市场收录 Skill、作者出版《LangGPT 提示词》并推动「AI Native 组织」方法论——这条轨迹本身证明了：在模型能力快速商品化的同时，提示词层面的结构化设计仍然是高价值、可沉淀、且能跨越模型迭代周期的护城河。

对开发者的现实建议：不必迷信「LangGPT 方式」这个咒语，但值得抄走它的 Goal/Done Criteria/Non-Goals 三件套和规则-流程分离的结构——这两条几乎可以无成本嫁接到任何 Agent 提示词设计上。