1. 项目概述AI工具的系统提示词与模型库最近在折腾各种AI工具时我发现一个挺普遍的问题很多开发者或者团队在尝试将大语言模型LLM集成到自己的应用里时往往是从零开始摸索。要么是花大量时间在GitHub上找零散的提示词Prompt示例要么就是对着API文档反复调试模型参数试图让AI输出符合预期的结果。这个过程不仅效率低而且容易踩坑导致项目进度缓慢。“CreatorEdition/system-prompts-and-models-of-ai-tools-chinese”这个项目在我看来就是为了解决这个痛点而生的。它本质上是一个中文的、经过整理的AI工具系统提示词与模型配置库。你可以把它理解为一个“工具箱”或者“配方集”里面收集了针对不同场景、不同任务优化过的系统提示词模板以及与之配套的、经过验证的模型调用参数建议。这个项目能做什么简单说它能让你在开发AI应用时快速找到“最佳实践”。比如你想做一个智能客服机器人不需要从“你好我是一个AI助手”开始写提示词而是可以直接参考项目中已经调校好的、能有效引导模型扮演专业客服角色的系统提示。又或者你想用AI来总结长文档项目里可能就有一个专门为“摘要生成”任务优化过的提示模板和对应的模型参数设置比如温度、最大生成长度等你拿过来稍作修改就能用。它适合谁我觉得主要面向三类人一是AI应用开发者尤其是那些正在将ChatGPT、Claude、文心一言等大模型API集成到产品中的工程师二是产品经理或运营人员他们需要快速验证某个AI功能的可行性或者为内容生产设计自动化流程三是对提示工程感兴趣的学习者这个项目就像一个实战案例库通过研究这些成熟的提示词能快速理解如何与AI进行有效“沟通”。这个项目的价值在于它把那些分散的、隐性的知识——如何写出一个能让AI稳定发挥的系统提示——给显性化、体系化了。它不是简单地罗列代码而是提供了经过验证的、可复用的解决方案能显著降低AI应用开发的门槛和试错成本。接下来我就结合自己的经验深入拆解一下如何理解、使用乃至贡献于这样的项目。2. 核心思路与项目结构解析拿到这样一个项目第一步不是急着去复制粘贴代码而是先理解它的设计思路和组织结构。这能帮你更快地找到所需内容并理解每个“配方”背后的设计逻辑。2.1 设计哲学从“黑盒调试”到“模式复用”传统的AI集成方式有点像“黑盒调试”。你给模型一个任务描述用户指令然后不断调整指令措辞、添加示例Few-shot或者修改API参数直到输出勉强可用。这个过程充满了不确定性严重依赖个人经验。而这个项目倡导的是一种“模式复用”的思路。它将一个复杂的AI交互任务拆解为几个关键部分系统角色定义告诉AI它应该扮演什么角色如“资深编辑”、“代码审查专家”。任务目标与约束清晰说明需要完成什么以及必须遵守的规则如输出格式、禁止事项。上下文与示例提供必要的背景信息以及高质量的输出样例。模型参数建议针对该任务推荐使用的模型版本、温度Temperature、最大令牌数等参数。项目中的每一个“配方”都是这四部分的一个组合优化方案。它的设计哲学是对于某一类常见任务如内容创作、代码生成、数据分析存在相对最优的提示结构和参数设置。通过收集和验证这些“模式”我们可以让AI的行为更可预测、更专业化。2.2 典型目录结构剖析一个组织良好的此类项目其目录结构通常会按场景或功能进行划分。虽然具体名称可能不同但逻辑是相通的。以下是一个我认为比较合理的结构示例system-prompts-and-models-zh/ ├── README.md # 项目总览、快速开始、贡献指南 ├── prompts/ # 核心提示词库 │ ├── content-creation/ # 内容创作类 │ │ ├── blog-writer.md # 博客写作 │ │ ├── social-media.md # 社交媒体文案 │ │ └── translation.md # 翻译 │ ├── code-generation/ # 代码生成类 │ │ ├── python-helper.md # Python助手 │ │ ├── code-review.md # 代码审查 │ │ └── sql-generator.md # SQL生成 │ ├── analysis-summary/ # 分析与总结类 │ │ ├── meeting-minutes.md # 会议纪要 │ │ ├── document-qa.md # 文档问答 │ │ └── sentiment-analysis.md # 情感分析 │ └── role-playing/ # 角色扮演类 │ ├── customer-service.md # 客服 │ ├── tutor.md # 导师 │ └── interviewer.md # 面试官 ├── model-configs/ # 模型配置库 │ ├── openai/ # OpenAI系列模型配置 │ │ ├── gpt-4.md │ │ ├── gpt-3.5-turbo.md │ │ └── general-params.md # 通用参数指南 │ ├── claude/ # Anthropic Claude系列 │ └── moonshot/ # 国内如月之暗面等 └── examples/ # 使用示例 ├── python-sdk-demo.py ├── nodejs-demo.js └── curl-requests.sh为什么这样设计按场景分类这是最符合用户直觉的方式。开发者通常是带着一个具体的任务“我要做个自动写周报的功能”来找资料的按场景分类能让他们快速定位。提示词与配置分离将prompts做什么和model-configs用什么做、怎么做分开结构更清晰。一个提示词模板可能适用于多个模型但每个模型的最佳参数可能不同。包含示例examples文件夹至关重要。它展示了如何将提示词模板和模型配置在实际代码中结合起来是连接“理论”与“实践”的桥梁。注意在实际使用或参考时一定要仔细阅读每个md文件内部的说明。一个完整的提示词模板文件不应该只是一段文本而应该包含适用场景、核心目标、系统提示词全文、关键参数解释、调用示例以及可能的变体或注意事项。缺少任何一部分其可用性都会大打折扣。2.3 理解“系统提示词”与“用户提示词”的区别这是很多新手容易混淆的概念也是这个项目价值的关键所在。系统提示词在对话开始前就发送给模型用于设定对话的基调、规则和AI的“人设”。它通常比较稳定定义了AI的“身份”和“行为准则”。例如“你是一个乐于助人且知识渊博的助手用中文回答并且确保回答准确、简洁。”用户提示词是用户在每次对话中输入的指令或问题。它是多变的取决于用户的具体需求。项目的核心价值在于提供高质量的系统提示词。一个好的系统提示词能极大地约束和引导模型的输出风格与质量让后续的用户交互事半功倍。例如一个为“技术文档编写”设计的系统提示词会内置对术语准确性、结构清晰度、示例完整性的要求这样即使用户只是简单地说“写一个关于Redis缓存的入门指南”AI也能输出结构专业、内容可用的草稿。3. 核心内容提示词模板的深度拆解与编写心法现在我们深入到项目的核心——那些具体的提示词模板。我将以一个常见的“技术博客写作助手”为例拆解一个高质量系统提示词的构成要素并分享我在编写这类提示词时积累的心法。3.1 一个完整的提示词模板应包含什么假设我们打开prompts/content-creation/blog-writer.md一个合格的模板应该像下面这样# 技术博客写作助手适用场景为开发者社区撰写技术教程、工具评测、问题解决思路分享等类型的博客文章。核心目标生成结构清晰、逻辑严谨、代码准确、对读者友好的中文技术博客草稿。系统提示词你是一位拥有10年以上全栈开发经验的资深技术博主专注于为开发者社区创作高质量、易懂的教程和深度文章。你的写作风格直接、务实、不堆砌辞藻善于用生活化类比解释复杂概念。 请你根据用户提供的主题和大纲撰写一篇完整的技术博客文章。请严格遵守以下要求 1. **文章结构**必须包含以下部分并使用Markdown的二级标题##进行分隔 - 引言用实际开发中遇到的问题或场景引入主题快速吸引目标读者。 - 核心原理/概念解析用通俗语言讲清楚“是什么”和“为什么”避免直接堆砌学术定义。 - 实战步骤提供可复制粘贴的代码片段、配置命令和操作截图用文字描述代替。每一步都要解释“为什么这么做”。 - 常见问题与排查列出2-3个实施中可能遇到的典型错误及其解决方法。 - 总结与延伸简要回顾核心要点并可提出一两个供读者进一步探索的方向。 2. **内容质量** - **准确性优先**所有技术细节、API用法、代码示例必须准确无误。如果你不确定请明确说明“此处需要根据[具体版本/环境]核实”。 - **代码规范**代码块必须指定语言类型如 python并提供必要的注释。 - **读者友好**避免使用未经解释的黑话。首次出现的专业术语需简单说明。 - **强调重点**关键步骤、重要参数、易错点使用**加粗**或行内代码进行强调。 3. **格式与风格** - 全文使用中文撰写。 - 段落简短每段4-6行避免大段文字。 - 在适当的地方使用无序列表-或表格来整理信息。 - 语气像一位乐于分享的同行可以说“我通常的做法是”、“这里有个小技巧”。 现在请根据用户提供的具体需求开始创作。配套模型配置建议 (OpenAI GPT-4)model:gpt-4-turbo-preview在平衡成本与性能时这是目前的最佳选择temperature:0.7需要一定的创造性来组织语言和举例但不宜过高以免偏离技术主题max_tokens:4000技术博客通常较长需预留足够空间top_p:1frequency_penalty:0.1轻微抑制常用词重复让表达更多样presence_penalty:0.1调用示例 (Python)from openai import OpenAI client OpenAI(api_key“your_api_key”) response client.chat.completions.create( model“gpt-4-turbo-preview”, temperature0.7, max_tokens4000, messages[ {“role”: “system”, “content”: “上面那一段完整的系统提示词”}, {“role”: “user”, “content”: “主题使用Docker Compose一键部署前后端分离的Web应用。\n要求面向中级开发者包含Node.js后端和React前端的配置示例并解释网络配置和卷挂载的关键点。”} ] ) print(response.choices[0].message.content)注意事项与变体对于更严谨的官方文档风格可将temperature降至0.3并在系统提示中强调“采用客观、中立的陈述语气避免个人化表达”。如果模型输出过于啰嗦尝试增加frequency_penalty到0.3或在系统提示末尾加上“请确保语言精炼不说废话”。对于Claude模型可能需要调整提示词结构因为Claude对系统提示的格式要求可能与OpenAI略有不同。通常可以将角色描述和规则更直接地整合在第一条用户消息中。3.2 编写高质量系统提示词的“心法”看了上面的例子你可能会觉得写提示词就是“提要求”。其实远不止如此它更像是在为AI设计一个清晰的“工作说明书”。以下是我总结的几个心法心法一角色扮演越具体输出越专业。差“你是一个助手。”好“你是一位专注于云原生架构的解决方案架构师有超过50个大型项目上云经验。”为什么具体的角色能激活模型内部与该角色相关的知识分布和语言风格让输出更具专业性和情境感。就像你问一个“厨师”和问一个“擅长川菜的资深主厨”关于“做鱼”的问题得到的回答深度和细节完全不同。心法二任务拆解要细致输出才可控。不要只说“写一篇博客”。要拆解成结构必须有哪些部分、内容准确、易懂、有代码、格式用Markdown、加粗关键点。把复杂任务分解成AI能一步步执行的清晰指令。这类似于给程序员写需求文档需求越模糊结果偏差越大。心法三通过约束来定义质量而非泛泛而谈。泛泛而谈“请写出高质量的内容。”有效约束“所有代码示例必须可运行并提供必要的导入语句和依赖说明。”“对复杂概念必须提供一个现实生活中的类比来解释。”“列出三个最常见的错误及其解决方案。”为什么“高质量”是主观的、模糊的。而“可运行的代码”、“提供类比”、“列出三个错误”是客观的、可检查的。通过设置这些具体的、可验证的约束你实际上是在为“高质量”制定可操作的衡量标准。心法四示例的力量远超描述。在提示词中如果条件允许提供1-2个输入输出的示例Few-shot Learning效果往往比写一大段描述性规则要好得多。例如在“代码审查”提示词中直接给一个存在安全漏洞的代码片段和一段修改后的代码及审查意见AI能更快地掌握你期望的审查标准和输出格式。心法五预留“安全阀”和“逃生口”。在提示词中要求AI对不确定的内容进行声明如“如果你不确定某API的最新参数请说明‘请查阅官方文档确认’”。这能防止AI“硬编”出错误信息。同时也可以告诉AI“如果用户的问题超出你的知识范围或本角色设定请礼貌地拒绝并说明原因”这能避免很多尴尬或错误的输出。4. 模型配置的精细化调优实战有了好的提示词还需要匹配的模型参数才能发挥最大效能。项目中的model-configs/目录就是干这个的。很多人调用API时永远只用默认参数这就像开车永远用D挡无法应对所有路况。我们来详细拆解几个关键参数。4.1 核心参数详解与场景匹配以下是一个针对常见任务的参数配置参考表它应该存在于类似model-configs/openai/general-params.md的指南中参数含义与影响低值场景 (0.1-0.3)高值场景 (0.7-1.0)常用推荐值temperature创造性/随机性。值越高输出越多样、不可预测值越低输出越确定、保守。代码生成、事实问答、翻译。需要高度准确和一致性的任务。创意写作、头脑风暴、生成多样化点子。0.7(创意写作),0.2(代码/摘要)top_p核采样。控制从概率质量最高的词汇中进行采样的范围。与temperature协同工作。通常保持为1或与低temperature配合使用聚焦最可能的词。与高temperature配合增加多样性。通常建议只调整一个。1(默认) 或0.9max_tokens最大生成长度。限制单次响应可生成的最大令牌数约等于单词数*1.3。短回答、摘要、提取关键词。长文生成、复杂分析。必须设置防止意外长响应产生高费用。根据任务预估并留有余量如博客设为4000。frequency_penalty频率惩罚。正值降低重复使用相同词汇的概率。常规对话、不需要特别避免重复时。文章写作、诗歌生成避免词汇贫乏。0.1~0.5(用于长文本生成)presence_penalty存在惩罚。正值鼓励模型谈论新话题避免围绕少数主题重复。聚焦于一个特定主题的深入讨论。头脑风暴、需要覆盖多个不同方面时。0~0.2实操心得temperature与top_p的取舍官方建议是不要同时调整这两个参数因为它们都影响随机性。通常只调整temperature就够了。我的经验是对于事实性、逻辑性任务代码、总结、数据提取用低temperature0.1-0.3确保稳定。对于创造性任务起名、写文案、编故事用高temperature0.7-0.9激发灵感。一个进阶技巧对于需要“在框架内创新”的任务比如“用某种风格写诗”可以尝试中等temperature0.5加上具体的风格约束在提示词中描述风格效果比单纯调高temperature更好。4.2 不同模型家族的配置差异项目如果覆盖多个模型提供商这一点尤其重要。因为不同模型的API参数、默认行为甚至计费方式都不同。OpenAI GPT 系列参数最丰富生态最完善。gpt-4-turbo是目前性价比和能力的平衡点适合大多数生产场景。gpt-3.5-turbo响应快、成本低适合对质量要求不极高的对话或简单任务。注意OpenAI的system角色消息效果显著一定要用好。Anthropic Claude 系列Claude 3系列如Opus, Sonnet, Haiku在长上下文、逻辑推理和遵循指令方面表现出色。其API参数可能没有OpenAI那么多但提示词结构有自己的一套最佳实践。关键区别Claude没有严格的system角色概念。通常的做法是将系统指令放在第一条用户消息中或者使用其API可能提供的特定“元指令”字段。在项目的Claude配置中需要明确写出这种适配后的提示词格式。国内大模型如月之暗面、智谱、通义等优势是中文理解能力强、合规性好、API调用延迟低。参数接口可能正在向OpenAI看齐但仍有差异。特别注意由于训练数据和价值观对齐的差异同样的提示词在不同模型上输出风格可能不同。在项目的国内模型配置中可能需要加入更符合中文语境和国内互联网规范的约束例如在内容安全、表述方式上的额外要求。重要提示所有模型配置建议都必须附带上次验证日期和模型版本。例如“本配置针对gpt-4-turbo-2024-04-09版本验证有效”。因为模型会更新其行为也可能发生细微变化。5. 从项目到实践集成与应用工作流理解了模板和配置下一步就是如何将它们用起来。这部分对应项目的examples/目录也是价值落地的一环。5.1 构建你的本地提示词管理库我不建议在线上应用中直接硬编码或远程调用项目中的原始Markdown文件。更专业的做法是将其转化为你代码库的一部分。步骤一下载与筛选克隆或下载该项目浏览目录挑选出与你当前业务最相关的提示词模板和配置。不要贪多先从最核心的1-2个场景开始。步骤二结构化存储在你的项目里创建一个专门管理提示词的模块或目录。例如your-ai-app/ ├── src/ │ ├── prompts/ # 提示词库 │ │ ├── index.js # 导出所有提示词 │ │ ├── blog-writer.js │ │ ├── customer-service.js │ │ └── configs/ # 模型配置 │ │ ├── openai.js │ │ └── claude.js │ └── services/ │ └── ai-service.js # 调用AI服务的封装步骤三代码化封装将提示词模板和配置从Markdown转化为代码中的常量或函数。这样做的好处是版本控制可以随你的代码一起用Git管理。易于修改可以根据业务需求进行微调。类型安全如果用TypeScript可以获得代码提示和错误检查。示例 (src/prompts/blog-writer.js)// 系统提示词模板使用模板字符串以便嵌入变量 const BLOG_WRITER_SYSTEM_PROMPT 你是一位拥有10年以上全栈开发经验的资深技术博主...同上 ; // 配置 const BLOG_WRITER_CONFIG { openai: { model: “gpt-4-turbo-preview”, temperature: 0.7, max_tokens: 4000, // ... 其他参数 }, claude: { model: “claude-3-sonnet-20240229”, max_tokens: 4000, // Claude特有参数... } }; // 一个生成最终消息列表的函数 function generateBlogWriterMessages(topic, requirements) { return [ { role: “system”, content: BLOG_WRITER_SYSTEM_PROMPT }, { role: “user”, content: 主题${topic}\n要求${requirements} } ]; } module.exports { BLOG_WRITER_SYSTEM_PROMPT, BLOG_WRITER_CONFIG, generateBlogWriterMessages };5.2 在应用中动态调用与测试在你的AI服务层引入这些封装好的提示词。示例 (src/services/ai-service.js)const OpenAI require(‘openai’); const { BLOG_WRITER_CONFIG, generateBlogWriterMessages } require(‘../prompts/blog-writer’); class AIService { constructor(provider ‘openai’) { this.provider provider; this.client new OpenAI({ apiKey: process.env.OPENAI_API_KEY }); // 初始化客户端 } async generateBlogPost(topic, requirements) { const messages generateBlogWriterMessages(topic, requirements); const config BLOG_WRITER_CONFIG[this.provider]; try { const response await this.client.chat.completions.create({ ...config, // 展开配置 messages, // 可以在这里覆盖或添加额外参数 // stream: true, // 如果需要流式响应 }); return response.choices[0].message.content; } catch (error) { console.error(‘AI服务调用失败:’, error); throw new Error(‘内容生成失败请稍后重试’); } } }测试与迭代单元测试为你的generateBlogWriterMessages函数写测试确保它根据输入生成了正确的消息结构。集成测试用一组固定的(topic, requirements)输入调用generateBlogPost检查输出是否大致符合预期结构、包含关键词等。注意由于AI输出的非确定性这里的断言不能是精确字符串匹配而应是模糊匹配如检查是否包含某些章节标题。A/B测试对于关键功能可以准备两套略有不同的提示词A版和B版在线上对少量用户进行A/B测试通过用户反馈或完成率等指标选择效果更好的版本。5.3 提示词版本管理与持续优化提示词不是一成不变的。随着模型更新、业务变化你需要持续优化它们。建立版本记录在提示词文件的头部或一个单独的CHANGELOG.md中记录每次修改的日期、版本号、修改内容和修改原因。## 提示词版本记录 (博客写作助手) - v1.0 (2024-01-15): 初始版本包含基本结构和质量要求。 - v1.1 (2024-02-20): 增加“必须提供可运行代码示例”的强制约束以解决输出代码片段不完整的问题。 - v1.2 (2024-03-10): 调整语气更强调“读者友好”并明确要求避免使用“首先、其次”等刻板连接词。收集反馈闭环在应用界面设置一个简单的“反馈”按钮如“结果有帮助/没帮助”或将AI生成的内容交由人工审核并标记问题。定期分析这些反馈找出提示词失效的常见模式例如AI总是忽略某个特定要求然后有针对性地修改提示词。自动化评估进阶对于大规模应用可以设计一些自动化指标来评估提示词效果例如格式合规率生成的内容是否包含了所有要求的部分如## 引言、## 实战步骤代码可执行率针对技术内容通过一个安全的沙箱环境尝试运行AI生成的代码片段看是否报错。关键信息包含率使用文本匹配或嵌入向量相似度检查输出是否包含了输入主题中要求的关键概念。通过这样的工作流你就将一个静态的“提示词库”项目融入了自己动态的、可迭代的AI应用开发流程中。6. 避坑指南与常见问题排查在实际使用这类项目和集成AI功能时你会遇到各种各样的问题。下面是我踩过的一些坑和对应的解决方案希望能帮你省点时间。6.1 提示词失效的典型症状与调试症状可能原因排查与解决思路AI完全忽略指令1. 系统提示词未被正确加载或传递。2. 提示词过于复杂或矛盾模型无法理解。1.检查API调用确认messages数组的第一条是role: “system”。对于不支持system角色的模型如某些早期版本需将指令融入用户消息。2.简化提示词将长提示词拆分成更短、更清晰的指令。使用“必须”、“请确保”等强动词并将最重要规则放在最前或最后。输出格式不符合要求1. 对格式的描述不够具体。2. 模型“创造性”过高temperature太高自由发挥。1.提供格式范例在提示词中直接给出一个期望输出的Markdown结构示例哪怕只是占位符。2.降低temperature对于格式要求严格的任务将temperature设为0.1-0.3。3.后处理编写一个简单的解析函数从AI的输出中提取所需部分或使用正则表达式进行格式化修正。输出内容空洞、泛泛而谈1. 任务描述太宽泛。2. 缺乏具体的约束或上下文。1.增加约束要求“列出至少3个具体步骤”、“提供5个真实场景的例子”、“对比方案A和方案B的优缺点”。2.提供上下文在用户消息中附上相关背景资料、数据片段或之前的对话历史。AI“捏造”信息幻觉1. 任务涉及模型知识边界外的事实。2. 提示词鼓励了创造性而非准确性。1.设置安全声明在系统提示中加入“如果你不确定请明确说明‘根据我所掌握的信息无法确认建议查阅官方文档’”。2.提供知识源采用RAG检索增强生成技术将相关文档片段作为上下文提供给模型。3.事实核查对于关键事实如日期、数据、引用设计流程进行二次验证。输出包含敏感或不期望内容1. 提示词约束不足。2. 用户输入触发了不期望的响应。1.强化系统角色在系统提示中明确禁止领域例如“你的角色是技术助手不讨论与技术无关的政治、历史等话题”。2.内容过滤在应用层对AI的输出进行关键词过滤或使用内容安全API进行二次检查。6.2 成本与性能的平衡策略滥用AI API可能导致惊人的账单。这里有几个控制成本的技巧设置预算与告警在云服务商后台设置每月预算和用量告警。缓存提示词结果对于常见、固定的查询如“生成欢迎邮件模板”其输出变化不大。可以将结果缓存起来如存到数据库或Redis下次相同请求直接返回缓存内容。为缓存设置一个合理的过期时间如一周以获取可能的模型更新带来的改进。分级使用模型草稿生成用便宜、快速的模型如gpt-3.5-turbo生成初稿。润色优化再将初稿交给更强、更贵的模型如gpt-4进行润色、扩写或风格化。这样总成本可能低于全程使用最强模型。精确控制max_tokens根据历史响应长度设置一个合理的、偏紧的max_tokens并做好截断处理。避免为了一次可能的长篇大论而预留过高的令牌数。使用流式响应对于需要实时显示给用户的场景如聊天使用流式响应stream: true可以提升用户体验并且如果用户中途打断可以节省后续令牌的成本。6.3 关于项目维护与贡献的思考如果你觉得这个项目对你有帮助并且你也有了一些自己的优化心得考虑回馈社区是很好的。在贡献之前请注意质量高于数量不要提交一个只是简单修改了几个词的“新”提示词。确保你提交的模板是经过充分测试、解决了某个具体问题、并且有明确应用场景的。提供完整的上下文在你提交的PR或新增的Markdown文件里必须像本文第3.1节示例那样包含适用场景、核心目标、完整的系统提示词、参数建议、调用示例和注意事项。缺少任何一部分都会增加他人的使用成本。注明测试环境清楚地说明你在哪个模型、哪个具体版本上测试通过例如gpt-4-turbo-2024-04-09。尊重版权与许可确保你提交的内容是原创的或者是对现有内容的实质性改进。遵守项目的开源协议通常是MIT或Apache 2.0。最后记住一点AI在快速进化提示词工程的最佳实践也在不断变化。今天有效的模式明天可能就需要调整。保持学习持续实验并将你的经验固化到这样的知识库中才是应对变化的最好方式。这个项目的真正价值不仅在于它现在提供了什么更在于它能否成为一个持续生长、由社区共同维护的“活”的实践指南。