最近在 AI 编程圈子里一个关于“Karpathy 的 65 行提示词”的话题被反复提及。很多开发者都在好奇这位 AI 领域的顶尖专家究竟用短短几十行文字揭示了哪些行业“秘密”这背后指向的其实是提示词工程Prompt Engineering从“玄学”走向“工程化”的关键一步。本文将从 Karpathy 的视角出发为你系统拆解高效提示词的核心原则、设计模式与实战技巧让你不仅能看懂这“65行”的精髓更能将其应用到日常与大模型LLM协作的每一个环节中无论是代码生成、问题解答还是复杂任务拆解都能事半功倍。1. 背景与核心概念为什么是“65行提示词”在深入技术细节之前我们首先要理解这个事件的背景。Andrej Karpathy 是 OpenAI 的创始成员之一也是特斯拉前 AI 总监在深度学习和大语言模型领域有着极高的声誉。他提出的“65行提示词”并非一个具体的、可复制的65行代码文件而是一个高度凝练的、用于指导大语言模型如 Claude、GPT-4进行高效编程协作的行为准则集合。这“65行”的本质是将他对 LLM 编程助手如 GitHub Copilot、Cursor、Claude Code长期使用经验的观察抽象成了一套可执行的“原则”或“技能”Skills。其核心价值在于揭示行业痛点传统的人机交互如搜索引擎、命令行是确定性的而与大模型的交互是概率性的、对话式的。很多开发者不习惯这种新模式导致提问低效、结果不佳。提供工程化解决方案Karpathy 将这些最佳实践固化为一套清晰的指令相当于为 LLM 编程助手制定了一份“岗位说明书”或“协作协议”使其行为更可预测、更符合工程师的期望。推动范式转变它标志着我们与 AI 协作的方式正在从零散的、试探性的“聊天”转向有结构、有策略的“工程化提示”。简单来说这“65行提示词”扒光的不是某个具体算法而是大多数人在使用 AI 编程助手时低效、盲目的现状并提供了一个清晰的优化路径。2. 环境准备与思想转变在实践具体的提示词技巧前我们需要做好两方面的准备工具环境和更重要的——协作思维的转变。2.1 工具与环境本文的示例和原则适用于所有主流的、支持长上下文和代码生成的 LLM 及集成环境例如云服务/聊天界面OpenAI ChatGPT (GPT-4), Anthropic Claude (Claude 3), DeepSeek, 文心一言等。代码编辑器集成Cursor: 深度集成 AI 的编辑器是实践这些原则的绝佳环境。GitHub Copilot: Visual Studio Code 等编辑器中的代码补全和聊天插件。Claude Code: 专为编码优化的 Claude 版本或插件。操作系统Windows, macOS, Linux 均可无特殊要求。版本说明本文讨论的原则是通用性的不依赖于特定模型版本。但为了获得最佳效果建议使用能力较强的模型如 GPT-4、Claude 3 Opus/Sonnet 等。2.2 协作思维的转变从“下命令”到“提供上下文”传统编程中我们给计算机的指令是精确的if (x 0) { ... }。但与 LLM 协作时我们需要从“指挥官”转变为“项目经理”或“资深同事”。旧思维“写一个快速排序函数。”新思维“我正在实现一个内存受限的嵌入式系统数据排序模块。目标平台是 C99没有动态内存分配。请提供一个针对整数数组的、原地操作的快速排序实现并附上针对已排序和逆序数组的边缘情况测试。请用中文注释解释分区逻辑。”后者的提示包含了角色、上下文、约束、具体任务和交付标准这能极大提升 LLM 输出结果的质量和相关性。Karpathy 的“65行”正是系统化地阐述了如何构建这样的高质量提示。3. Karpathy 提示词核心原则拆解虽然我们无法获得那“65行”提示词的全部原文但根据其思想及相关资料如 “Andrej Karpathy Skills” 插件我们可以提炼出四大核心原则。这些原则是构建高效提示词的基石。3.1 原则一清晰定义角色与边界 (Role Boundaries)核心思想在对话开始时就明确告诉 AI 它应该扮演什么角色以及它的能力边界是什么。这能有效防止 AI “胡思乱想”或做出超出范围的假设。为什么重要LLM 是通才默认会以“乐于助人的助手”角色回应。但对于专业任务我们需要它聚焦。示例与应用【低效提示】 帮我看看这段代码有什么问题。 【高效提示 - 应用原则一】 请你扮演一位经验丰富的 Python 后端架构师专注于代码性能、可维护性和安全性。你的知识截止日期是 2023年7月。请仅基于提供的代码和公认的最佳实践进行分析不要假设或编造不存在的库或API。关键点角色Python 后端架构师专注领域性能、可维护性、安全性知识边界截止2023年7月行为边界仅基于提供代码不编造3.2 原则二提供丰富、结构化的上下文 (Rich, Structured Context)核心思想LLM 的表现严重依赖于输入信息。提供相关的代码片段、错误信息、文档链接、数据结构定义等就像给人类同事提供需求文档一样。为什么重要缺乏上下文是 AI 输出“幻觉”编造信息或无关内容的主要原因。示例与应用【低效提示】 我的API报500错误怎么办 【高效提示 - 应用原则二】 我正在开发一个用户注册接口。下面是我的 Spring Boot 控制器代码、相关的 User 实体类定义以及从日志中截取的完整错误堆栈信息。 【控制器代码】 java PostMapping(/register) public ResponseEntityUser registerUser(RequestBody UserDto userDto) { // ... 业务逻辑 }【实体类定义】Entity public class User { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; Column(unique true) private String username; // ... 其他字段 }【错误日志】org.hibernate.exception.ConstraintViolationException: could not execute statement SQL Error: 1062, SQLState: 23000 Duplicate entry john_doe for key user.username_unique根据以上信息请分析最可能的根本原因并提供具体的修复步骤。**关键点**将问题相关的所有信息代码、数据模型、错误日志**结构化地、完整地**提供给 AI。 ### 3.3 原则三明确任务步骤与输出格式 (Step-by-Step Output Format) **核心思想**将复杂任务分解为清晰的步骤并明确指定你期望的输出格式如代码块、列表、表格、JSON。鼓励 AI “逐步思考”Chain-of-Thought。 **为什么重要**这能引导 AI 的推理过程使其逻辑更清晰并确保输出结果可以直接被你使用减少后续处理成本。 **示例与应用** markdown 【低效提示】 给我设计一个数据库表。 【高效提示 - 应用原则三】 任务为博客系统设计核心数据库表。 请按以下步骤进行并严格按照要求格式输出 1. **步骤一识别核心实体**。列出系统必须包含的至少4个核心实体如 User, Post, Comment, Category。 2. **步骤二设计表结构**。为每个实体设计 SQL CREATE TABLE 语句。 * 包含主键、外键如适用、必要的索引。 * 字段需注明数据类型如 VARCHAR(255), TEXT, DATETIME和约束如 NOT NULL, UNIQUE。 * 考虑性能为 Post 表的 created_at 字段添加索引。 3. **步骤三输出格式**。 * 用 Markdown 表格列出每个表的核心字段。 * 在表格后提供完整的、可执行的 SQL 代码块。 请开始你的逐步分析。关键点步骤一步骤二输出格式Markdown 表格SQL 代码块。3.4 原则四迭代式精炼与反馈 (Iterative Refinement)核心思想与 AI 的对话应该是迭代的。基于它的第一次输出提供具体的反馈要求其调整、修正或深入。使用如“继续”、“重写第三部分”、“从安全角度重新评估”等指令。为什么重要很少有任务能通过单次完美提示完成。迭代是获得理想结果的关键。示例与应用第一轮AI 生成了一个函数。第二轮反馈“函数逻辑正确但请添加详细的异常处理特别是网络超时和 JSON 解析错误的情况。另外将硬编码的 API URL 改为可从环境变量读取。”第三轮反馈“很好。现在请为这个函数编写三个单元测试用例分别覆盖成功请求、网络错误和无效响应的情况。”关键点反馈要具体指向代码行或特定要求而不是模糊的“不好”、“再改改”。4. 完整实战案例构建一个配置管理模块让我们通过一个完整的例子将上述原则融会贯通。假设我们要使用 Python 构建一个简单的配置文件管理模块。4.1 任务定义与初始提示我们首先应用原则一和原则三给出一个清晰的初始提示。请你扮演一位注重代码健壮性和可测试性的 Python 高级开发工程师。你的任务是帮助我创建一个用于管理 YAML 格式配置文件的 Python 模块。 请遵循以下步骤并确保最终输出是可直接复制运行的完整代码 1. **步骤一设计模块接口**。设计一个 ConfigManager 类它应包含以下方法 * __init__(self, config_path: str): 初始化接受配置文件路径。 * load(self) - dict: 加载并解析 YAML 文件返回配置字典。如果文件不存在或格式错误应抛出清晰的异常。 * get(self, key: str, defaultNone): 支持点分隔符如 database.host获取嵌套配置值。 * set(self, key: str, value): 支持点分隔符设置值并**立即**写回文件。 * save(self): 将当前配置字典写回文件。 2. **步骤二实现核心逻辑**。实现上述类注意 * 使用 PyYAML 库处理 YAML。 * 实现 get 和 set 中的点分隔符解析逻辑。 * 考虑线程安全如果多个线程可能操作同一实例。 * 添加适当的日志记录使用 logging 模块。 3. **步骤三提供使用示例**。编写一个 if __name__ __main__: 部分演示模块的完整用法包括加载、读取、修改、保存和异常处理。 4. **输出格式**请提供一个完整的 Python 文件内容。4.2 AI 生成代码与初步审查基于以上提示AI 可能会生成一个初步版本的config_manager.py。作为开发者我们需要审查这段代码。假设我们发现它没有处理配置项不存在时get方法的优雅降级并且set方法在修改嵌套字典时逻辑复杂。4.3 应用原则四迭代精炼我们给出具体的反馈引导 AI 改进。感谢你提供的代码基础结构很好。现在请基于以下反馈进行改进 1. **get 方法增强**当前 get 方法在 key 路径不存在时会抛出 KeyError。请修改它使其在路径不存在时能够安静地返回 default 值而不是抛出异常。这更符合配置获取的常见习惯。 2. **set 方法优化**你实现的点分隔符设置逻辑在处理深层嵌套时有些冗长。请参考 dpath 库的思路但不要直接引入该库或者实现一个更简洁的递归或循环方法来设置嵌套字典的值。 3. **添加类型提示**为所有公共方法添加完整的 Python 类型提示Type Hints以提高代码可读性和 IDE 支持。 4. **增强异常信息**在 load 方法中当 YAML 解析失败时除了抛出 YAMLError最好能在异常信息中包含出错的配置文件路径和行号如果可能。 请重写 ConfigManager 类并更新使用示例以展示新的 get 方法的默认值特性。4.4 最终代码与验证经过迭代我们获得了一个更健壮的版本。以下是可能的核心代码片段# config_manager.py import yaml import logging from typing import Any, Optional from pathlib import Path logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) class ConfigManager: 管理 YAML 配置文件的类。 def __init__(self, config_path: str) - None: self.config_path Path(config_path) self._config: dict {} self._lock threading.RLock() # 简单的可重入锁用于线程安全 def load(self) - dict: 加载并解析 YAML 配置文件。 with self._lock: if not self.config_path.exists(): raise FileNotFoundError(f配置文件不存在: {self.config_path}) try: with open(self.config_path, r, encodingutf-8) as f: self._config yaml.safe_load(f) or {} logger.info(f成功加载配置文件: {self.config_path}) return self._config.copy() except yaml.YAMLError as e: # 尝试提供更详细的错误信息 mark getattr(e, problem_mark, None) err_msg fYAML 解析错误于 {self.config_path} if mark: err_msg f (行:{mark.line1}, 列:{mark.column1}) logger.error(err_msg) raise ValueError(err_msg) from e def get(self, key: str, default: Optional[Any] None) - Any: 使用点分隔符获取配置值。如果路径不存在返回默认值。 keys key.split(.) value self._config try: for k in keys: value value[k] return value except (KeyError, TypeError): # KeyError: 键不存在TypeError: 值不是字典但还在尝试索引 logger.debug(f配置键 {key} 不存在返回默认值 {default}) return default def _set_nested(self, d: dict, keys: list, value: Any) - None: 递归设置嵌套字典的值。 current_key keys[0] if len(keys) 1: d[current_key] value else: if current_key not in d or not isinstance(d[current_key], dict): d[current_key] {} self._set_nested(d[current_key], keys[1:], value) def set(self, key: str, value: Any) - None: 使用点分隔符设置配置值并立即保存。 with self._lock: keys key.split(.) self._set_nested(self._config, keys, value) self.save() def save(self) - None: 将当前配置写回文件。 with self._lock: try: with open(self.config_path, w, encodingutf-8) as f: yaml.dump(self._config, f, default_flow_styleFalse, allow_unicodeTrue) logger.info(f配置已保存至: {self.config_path}) except IOError as e: logger.error(f保存配置文件失败: {e}) raise if __name__ __main__: # 使用示例 manager ConfigManager(config.yaml) try: config manager.load() print(数据库主机:, manager.get(database.host, localhost)) print(不存在的键:, manager.get(some.deep.nonexistent.key, 默认值)) manager.set(app.debug, True) manager.set(database.connection.pool_size, 20) print(修改后的配置:, manager._config) except Exception as e: print(f操作失败: {e})通过这个案例我们完整演示了如何从任务定义、到 AI 生成、再到人工审查和迭代精炼的全过程这正是 Karpathy 所倡导的工程化协作流程。5. 常见问题与排查思路在与 LLM 协作编程时你可能会遇到一些典型问题。下表列出了常见问题及其解决思路。问题现象可能原因解决思路AI 输出无关内容或“幻觉”提示词过于宽泛缺乏上下文和约束。应用原则一和原则二。明确角色、边界并提供具体的代码、错误信息等上下文。在提示中要求 AI “仅基于提供的信息”。代码看似正确但运行报错AI 可能使用了过时的 API 或忽略了运行环境差异。1.检查版本在提示中声明你的环境如 Python 3.9, PyTorch 2.0。2.要求解释让 AI 逐步解释关键代码段暴露其潜在假设。3.提供错误将完整的报错信息粘贴给 AI 分析。AI 无法完成复杂任务单次提示任务过于宏大AI 难以分解。应用原则三。将大任务拆解为多个清晰的子步骤分多次对话完成。例如先设计接口再实现函数最后写测试。输出格式混乱未指定期望的输出格式。在提示词结尾明确要求格式如“请将最终结果以 JSON 格式输出”或“请用三个反引号包裹代码”。迭代后效果变差反馈指令模糊或上下文过长导致 AI 遗忘早期指令。1.反馈要具体指向行号或具体功能点。2.开启新对话对于重大方向调整开启新对话并携带精简后的核心指令和代码比在冗长旧对话中继续更有效。生成的代码有安全漏洞AI 基于通用模式生成未考虑特定安全场景。在提示中加入安全约束如“请避免 SQL 注入风险”、“对用户输入进行严格验证”、“使用参数化查询”。6. 最佳实践与工程建议将提示词工程融入日常开发需要建立一些最佳实践。6.1 创建并复用提示词模板不要每次都从零开始。为你常用的任务类型创建模板。代码审查模板角色资深[语言]开发工程师 任务审查以下[语言]代码重点关注[性能/安全/可读性]。 代码[粘贴代码]请按以下步骤输出 1. 潜在问题与风险列表。 2. 具体的优化建议列表。 3. 重构后的代码片段可选。API 设计模板角色系统架构师 任务设计一个满足以下需求的 RESTful API。 需求描述[描述] 约束[技术栈、数据库、认证方式] 请输出 1. 资源列表与 URI 设计。 2. 关键端点Endpoint的 HTTP 方法与请求/响应示例JSON格式。 3. 可能的状态码与错误处理。6.2 管理对话上下文重要信息前置在长对话中将核心指令角色、任务、约束放在最前面因为 AI 对上下文开头和结尾的信息更敏感。适时总结与重启当对话变得冗长且低效时可以手动总结当前状态“目前我们有一个实现了 X 功能的类但 Y 问题尚未解决”然后开启一个新对话将总结和剩余任务作为新的起点。使用“系统提示”功能如果所用工具支持如 ChatGPT 的“自定义指令”某些插件的系统角色设置将不变的原则如角色、响应格式偏好设置在系统级别为每次对话节省 Token 并保持一致性。6.3 结合传统开发流程需求分析阶段用 AI 进行头脑风暴生成用户故事、功能列表或数据模型草案。设计阶段用 AI 生成技术方案对比、API 设计草案、数据库 Schema 草图。实现阶段如本文案例所示用于生成样板代码、复杂算法、单元测试。测试与调试让 AI 分析错误日志、生成测试用例、解释测试失败原因。文档阶段基于代码生成注释、API 文档、项目 README。关键提醒AI 是强大的副驾驶但你永远是机长。所有 AI 生成的代码、设计都必须经过你的仔细审查、测试和理解后才能并入项目。切勿盲目信任。7. 总结与学习路线Andrej Karpathy 的“65行提示词”之所以引起震动是因为它精准地指出了从“随意聊天”到“工程化协作”的鸿沟并提供了一套可操作的跨越方法。掌握这套方法意味着你能将大语言模型的潜力更稳定、更高效地转化为生产力。回顾核心要点思维转变从下命令变为提供丰富上下文和清晰约束的协作。四大原则定义角色、提供上下文、分解任务、迭代精炼。实战流程定义任务 - 生成初稿 - 审查反馈 - 迭代优化。工具化建立自己的提示词模板库管理好对话上下文。下一步学习建议深入特定领域将上述原则应用到你的主要技术栈前端、后端、数据科学、运维等探索领域特定的提示模式。学习高级技巧了解更高级的概念如思维链Chain-of-Thought、少样本提示Few-Shot Prompting、ReAct 框架推理行动等。关注工具生态了解如LangChain、LlamaIndex等用于构建复杂 LLM 应用的开源框架。实践与反思在日常编码中坚持使用并反思每次交互。记录下哪些提示词效果好哪些不好不断优化你自己的“提示词工具箱”。技术的本质是杠杆。提示词工程就是让我们学会如何更有效地按下大语言模型这个超级杠杆的支点。希望本文能成为你掌握这门新工程艺术的实用指南。如果在实践中遇到具体问题欢迎在评论区交流探讨。
Karpathy 65行提示词揭秘：从玄学到工程化的AI编程协作指南
发布时间：2026/7/28 6:47:08
最近在 AI 编程圈子里一个关于“Karpathy 的 65 行提示词”的话题被反复提及。很多开发者都在好奇这位 AI 领域的顶尖专家究竟用短短几十行文字揭示了哪些行业“秘密”这背后指向的其实是提示词工程Prompt Engineering从“玄学”走向“工程化”的关键一步。本文将从 Karpathy 的视角出发为你系统拆解高效提示词的核心原则、设计模式与实战技巧让你不仅能看懂这“65行”的精髓更能将其应用到日常与大模型LLM协作的每一个环节中无论是代码生成、问题解答还是复杂任务拆解都能事半功倍。1. 背景与核心概念为什么是“65行提示词”在深入技术细节之前我们首先要理解这个事件的背景。Andrej Karpathy 是 OpenAI 的创始成员之一也是特斯拉前 AI 总监在深度学习和大语言模型领域有着极高的声誉。他提出的“65行提示词”并非一个具体的、可复制的65行代码文件而是一个高度凝练的、用于指导大语言模型如 Claude、GPT-4进行高效编程协作的行为准则集合。这“65行”的本质是将他对 LLM 编程助手如 GitHub Copilot、Cursor、Claude Code长期使用经验的观察抽象成了一套可执行的“原则”或“技能”Skills。其核心价值在于揭示行业痛点传统的人机交互如搜索引擎、命令行是确定性的而与大模型的交互是概率性的、对话式的。很多开发者不习惯这种新模式导致提问低效、结果不佳。提供工程化解决方案Karpathy 将这些最佳实践固化为一套清晰的指令相当于为 LLM 编程助手制定了一份“岗位说明书”或“协作协议”使其行为更可预测、更符合工程师的期望。推动范式转变它标志着我们与 AI 协作的方式正在从零散的、试探性的“聊天”转向有结构、有策略的“工程化提示”。简单来说这“65行提示词”扒光的不是某个具体算法而是大多数人在使用 AI 编程助手时低效、盲目的现状并提供了一个清晰的优化路径。2. 环境准备与思想转变在实践具体的提示词技巧前我们需要做好两方面的准备工具环境和更重要的——协作思维的转变。2.1 工具与环境本文的示例和原则适用于所有主流的、支持长上下文和代码生成的 LLM 及集成环境例如云服务/聊天界面OpenAI ChatGPT (GPT-4), Anthropic Claude (Claude 3), DeepSeek, 文心一言等。代码编辑器集成Cursor: 深度集成 AI 的编辑器是实践这些原则的绝佳环境。GitHub Copilot: Visual Studio Code 等编辑器中的代码补全和聊天插件。Claude Code: 专为编码优化的 Claude 版本或插件。操作系统Windows, macOS, Linux 均可无特殊要求。版本说明本文讨论的原则是通用性的不依赖于特定模型版本。但为了获得最佳效果建议使用能力较强的模型如 GPT-4、Claude 3 Opus/Sonnet 等。2.2 协作思维的转变从“下命令”到“提供上下文”传统编程中我们给计算机的指令是精确的if (x 0) { ... }。但与 LLM 协作时我们需要从“指挥官”转变为“项目经理”或“资深同事”。旧思维“写一个快速排序函数。”新思维“我正在实现一个内存受限的嵌入式系统数据排序模块。目标平台是 C99没有动态内存分配。请提供一个针对整数数组的、原地操作的快速排序实现并附上针对已排序和逆序数组的边缘情况测试。请用中文注释解释分区逻辑。”后者的提示包含了角色、上下文、约束、具体任务和交付标准这能极大提升 LLM 输出结果的质量和相关性。Karpathy 的“65行”正是系统化地阐述了如何构建这样的高质量提示。3. Karpathy 提示词核心原则拆解虽然我们无法获得那“65行”提示词的全部原文但根据其思想及相关资料如 “Andrej Karpathy Skills” 插件我们可以提炼出四大核心原则。这些原则是构建高效提示词的基石。3.1 原则一清晰定义角色与边界 (Role Boundaries)核心思想在对话开始时就明确告诉 AI 它应该扮演什么角色以及它的能力边界是什么。这能有效防止 AI “胡思乱想”或做出超出范围的假设。为什么重要LLM 是通才默认会以“乐于助人的助手”角色回应。但对于专业任务我们需要它聚焦。示例与应用【低效提示】 帮我看看这段代码有什么问题。 【高效提示 - 应用原则一】 请你扮演一位经验丰富的 Python 后端架构师专注于代码性能、可维护性和安全性。你的知识截止日期是 2023年7月。请仅基于提供的代码和公认的最佳实践进行分析不要假设或编造不存在的库或API。关键点角色Python 后端架构师专注领域性能、可维护性、安全性知识边界截止2023年7月行为边界仅基于提供代码不编造3.2 原则二提供丰富、结构化的上下文 (Rich, Structured Context)核心思想LLM 的表现严重依赖于输入信息。提供相关的代码片段、错误信息、文档链接、数据结构定义等就像给人类同事提供需求文档一样。为什么重要缺乏上下文是 AI 输出“幻觉”编造信息或无关内容的主要原因。示例与应用【低效提示】 我的API报500错误怎么办 【高效提示 - 应用原则二】 我正在开发一个用户注册接口。下面是我的 Spring Boot 控制器代码、相关的 User 实体类定义以及从日志中截取的完整错误堆栈信息。 【控制器代码】 java PostMapping(/register) public ResponseEntityUser registerUser(RequestBody UserDto userDto) { // ... 业务逻辑 }【实体类定义】Entity public class User { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; Column(unique true) private String username; // ... 其他字段 }【错误日志】org.hibernate.exception.ConstraintViolationException: could not execute statement SQL Error: 1062, SQLState: 23000 Duplicate entry john_doe for key user.username_unique根据以上信息请分析最可能的根本原因并提供具体的修复步骤。**关键点**将问题相关的所有信息代码、数据模型、错误日志**结构化地、完整地**提供给 AI。 ### 3.3 原则三明确任务步骤与输出格式 (Step-by-Step Output Format) **核心思想**将复杂任务分解为清晰的步骤并明确指定你期望的输出格式如代码块、列表、表格、JSON。鼓励 AI “逐步思考”Chain-of-Thought。 **为什么重要**这能引导 AI 的推理过程使其逻辑更清晰并确保输出结果可以直接被你使用减少后续处理成本。 **示例与应用** markdown 【低效提示】 给我设计一个数据库表。 【高效提示 - 应用原则三】 任务为博客系统设计核心数据库表。 请按以下步骤进行并严格按照要求格式输出 1. **步骤一识别核心实体**。列出系统必须包含的至少4个核心实体如 User, Post, Comment, Category。 2. **步骤二设计表结构**。为每个实体设计 SQL CREATE TABLE 语句。 * 包含主键、外键如适用、必要的索引。 * 字段需注明数据类型如 VARCHAR(255), TEXT, DATETIME和约束如 NOT NULL, UNIQUE。 * 考虑性能为 Post 表的 created_at 字段添加索引。 3. **步骤三输出格式**。 * 用 Markdown 表格列出每个表的核心字段。 * 在表格后提供完整的、可执行的 SQL 代码块。 请开始你的逐步分析。关键点步骤一步骤二输出格式Markdown 表格SQL 代码块。3.4 原则四迭代式精炼与反馈 (Iterative Refinement)核心思想与 AI 的对话应该是迭代的。基于它的第一次输出提供具体的反馈要求其调整、修正或深入。使用如“继续”、“重写第三部分”、“从安全角度重新评估”等指令。为什么重要很少有任务能通过单次完美提示完成。迭代是获得理想结果的关键。示例与应用第一轮AI 生成了一个函数。第二轮反馈“函数逻辑正确但请添加详细的异常处理特别是网络超时和 JSON 解析错误的情况。另外将硬编码的 API URL 改为可从环境变量读取。”第三轮反馈“很好。现在请为这个函数编写三个单元测试用例分别覆盖成功请求、网络错误和无效响应的情况。”关键点反馈要具体指向代码行或特定要求而不是模糊的“不好”、“再改改”。4. 完整实战案例构建一个配置管理模块让我们通过一个完整的例子将上述原则融会贯通。假设我们要使用 Python 构建一个简单的配置文件管理模块。4.1 任务定义与初始提示我们首先应用原则一和原则三给出一个清晰的初始提示。请你扮演一位注重代码健壮性和可测试性的 Python 高级开发工程师。你的任务是帮助我创建一个用于管理 YAML 格式配置文件的 Python 模块。 请遵循以下步骤并确保最终输出是可直接复制运行的完整代码 1. **步骤一设计模块接口**。设计一个 ConfigManager 类它应包含以下方法 * __init__(self, config_path: str): 初始化接受配置文件路径。 * load(self) - dict: 加载并解析 YAML 文件返回配置字典。如果文件不存在或格式错误应抛出清晰的异常。 * get(self, key: str, defaultNone): 支持点分隔符如 database.host获取嵌套配置值。 * set(self, key: str, value): 支持点分隔符设置值并**立即**写回文件。 * save(self): 将当前配置字典写回文件。 2. **步骤二实现核心逻辑**。实现上述类注意 * 使用 PyYAML 库处理 YAML。 * 实现 get 和 set 中的点分隔符解析逻辑。 * 考虑线程安全如果多个线程可能操作同一实例。 * 添加适当的日志记录使用 logging 模块。 3. **步骤三提供使用示例**。编写一个 if __name__ __main__: 部分演示模块的完整用法包括加载、读取、修改、保存和异常处理。 4. **输出格式**请提供一个完整的 Python 文件内容。4.2 AI 生成代码与初步审查基于以上提示AI 可能会生成一个初步版本的config_manager.py。作为开发者我们需要审查这段代码。假设我们发现它没有处理配置项不存在时get方法的优雅降级并且set方法在修改嵌套字典时逻辑复杂。4.3 应用原则四迭代精炼我们给出具体的反馈引导 AI 改进。感谢你提供的代码基础结构很好。现在请基于以下反馈进行改进 1. **get 方法增强**当前 get 方法在 key 路径不存在时会抛出 KeyError。请修改它使其在路径不存在时能够安静地返回 default 值而不是抛出异常。这更符合配置获取的常见习惯。 2. **set 方法优化**你实现的点分隔符设置逻辑在处理深层嵌套时有些冗长。请参考 dpath 库的思路但不要直接引入该库或者实现一个更简洁的递归或循环方法来设置嵌套字典的值。 3. **添加类型提示**为所有公共方法添加完整的 Python 类型提示Type Hints以提高代码可读性和 IDE 支持。 4. **增强异常信息**在 load 方法中当 YAML 解析失败时除了抛出 YAMLError最好能在异常信息中包含出错的配置文件路径和行号如果可能。 请重写 ConfigManager 类并更新使用示例以展示新的 get 方法的默认值特性。4.4 最终代码与验证经过迭代我们获得了一个更健壮的版本。以下是可能的核心代码片段# config_manager.py import yaml import logging from typing import Any, Optional from pathlib import Path logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) class ConfigManager: 管理 YAML 配置文件的类。 def __init__(self, config_path: str) - None: self.config_path Path(config_path) self._config: dict {} self._lock threading.RLock() # 简单的可重入锁用于线程安全 def load(self) - dict: 加载并解析 YAML 配置文件。 with self._lock: if not self.config_path.exists(): raise FileNotFoundError(f配置文件不存在: {self.config_path}) try: with open(self.config_path, r, encodingutf-8) as f: self._config yaml.safe_load(f) or {} logger.info(f成功加载配置文件: {self.config_path}) return self._config.copy() except yaml.YAMLError as e: # 尝试提供更详细的错误信息 mark getattr(e, problem_mark, None) err_msg fYAML 解析错误于 {self.config_path} if mark: err_msg f (行:{mark.line1}, 列:{mark.column1}) logger.error(err_msg) raise ValueError(err_msg) from e def get(self, key: str, default: Optional[Any] None) - Any: 使用点分隔符获取配置值。如果路径不存在返回默认值。 keys key.split(.) value self._config try: for k in keys: value value[k] return value except (KeyError, TypeError): # KeyError: 键不存在TypeError: 值不是字典但还在尝试索引 logger.debug(f配置键 {key} 不存在返回默认值 {default}) return default def _set_nested(self, d: dict, keys: list, value: Any) - None: 递归设置嵌套字典的值。 current_key keys[0] if len(keys) 1: d[current_key] value else: if current_key not in d or not isinstance(d[current_key], dict): d[current_key] {} self._set_nested(d[current_key], keys[1:], value) def set(self, key: str, value: Any) - None: 使用点分隔符设置配置值并立即保存。 with self._lock: keys key.split(.) self._set_nested(self._config, keys, value) self.save() def save(self) - None: 将当前配置写回文件。 with self._lock: try: with open(self.config_path, w, encodingutf-8) as f: yaml.dump(self._config, f, default_flow_styleFalse, allow_unicodeTrue) logger.info(f配置已保存至: {self.config_path}) except IOError as e: logger.error(f保存配置文件失败: {e}) raise if __name__ __main__: # 使用示例 manager ConfigManager(config.yaml) try: config manager.load() print(数据库主机:, manager.get(database.host, localhost)) print(不存在的键:, manager.get(some.deep.nonexistent.key, 默认值)) manager.set(app.debug, True) manager.set(database.connection.pool_size, 20) print(修改后的配置:, manager._config) except Exception as e: print(f操作失败: {e})通过这个案例我们完整演示了如何从任务定义、到 AI 生成、再到人工审查和迭代精炼的全过程这正是 Karpathy 所倡导的工程化协作流程。5. 常见问题与排查思路在与 LLM 协作编程时你可能会遇到一些典型问题。下表列出了常见问题及其解决思路。问题现象可能原因解决思路AI 输出无关内容或“幻觉”提示词过于宽泛缺乏上下文和约束。应用原则一和原则二。明确角色、边界并提供具体的代码、错误信息等上下文。在提示中要求 AI “仅基于提供的信息”。代码看似正确但运行报错AI 可能使用了过时的 API 或忽略了运行环境差异。1.检查版本在提示中声明你的环境如 Python 3.9, PyTorch 2.0。2.要求解释让 AI 逐步解释关键代码段暴露其潜在假设。3.提供错误将完整的报错信息粘贴给 AI 分析。AI 无法完成复杂任务单次提示任务过于宏大AI 难以分解。应用原则三。将大任务拆解为多个清晰的子步骤分多次对话完成。例如先设计接口再实现函数最后写测试。输出格式混乱未指定期望的输出格式。在提示词结尾明确要求格式如“请将最终结果以 JSON 格式输出”或“请用三个反引号包裹代码”。迭代后效果变差反馈指令模糊或上下文过长导致 AI 遗忘早期指令。1.反馈要具体指向行号或具体功能点。2.开启新对话对于重大方向调整开启新对话并携带精简后的核心指令和代码比在冗长旧对话中继续更有效。生成的代码有安全漏洞AI 基于通用模式生成未考虑特定安全场景。在提示中加入安全约束如“请避免 SQL 注入风险”、“对用户输入进行严格验证”、“使用参数化查询”。6. 最佳实践与工程建议将提示词工程融入日常开发需要建立一些最佳实践。6.1 创建并复用提示词模板不要每次都从零开始。为你常用的任务类型创建模板。代码审查模板角色资深[语言]开发工程师 任务审查以下[语言]代码重点关注[性能/安全/可读性]。 代码[粘贴代码]请按以下步骤输出 1. 潜在问题与风险列表。 2. 具体的优化建议列表。 3. 重构后的代码片段可选。API 设计模板角色系统架构师 任务设计一个满足以下需求的 RESTful API。 需求描述[描述] 约束[技术栈、数据库、认证方式] 请输出 1. 资源列表与 URI 设计。 2. 关键端点Endpoint的 HTTP 方法与请求/响应示例JSON格式。 3. 可能的状态码与错误处理。6.2 管理对话上下文重要信息前置在长对话中将核心指令角色、任务、约束放在最前面因为 AI 对上下文开头和结尾的信息更敏感。适时总结与重启当对话变得冗长且低效时可以手动总结当前状态“目前我们有一个实现了 X 功能的类但 Y 问题尚未解决”然后开启一个新对话将总结和剩余任务作为新的起点。使用“系统提示”功能如果所用工具支持如 ChatGPT 的“自定义指令”某些插件的系统角色设置将不变的原则如角色、响应格式偏好设置在系统级别为每次对话节省 Token 并保持一致性。6.3 结合传统开发流程需求分析阶段用 AI 进行头脑风暴生成用户故事、功能列表或数据模型草案。设计阶段用 AI 生成技术方案对比、API 设计草案、数据库 Schema 草图。实现阶段如本文案例所示用于生成样板代码、复杂算法、单元测试。测试与调试让 AI 分析错误日志、生成测试用例、解释测试失败原因。文档阶段基于代码生成注释、API 文档、项目 README。关键提醒AI 是强大的副驾驶但你永远是机长。所有 AI 生成的代码、设计都必须经过你的仔细审查、测试和理解后才能并入项目。切勿盲目信任。7. 总结与学习路线Andrej Karpathy 的“65行提示词”之所以引起震动是因为它精准地指出了从“随意聊天”到“工程化协作”的鸿沟并提供了一套可操作的跨越方法。掌握这套方法意味着你能将大语言模型的潜力更稳定、更高效地转化为生产力。回顾核心要点思维转变从下命令变为提供丰富上下文和清晰约束的协作。四大原则定义角色、提供上下文、分解任务、迭代精炼。实战流程定义任务 - 生成初稿 - 审查反馈 - 迭代优化。工具化建立自己的提示词模板库管理好对话上下文。下一步学习建议深入特定领域将上述原则应用到你的主要技术栈前端、后端、数据科学、运维等探索领域特定的提示模式。学习高级技巧了解更高级的概念如思维链Chain-of-Thought、少样本提示Few-Shot Prompting、ReAct 框架推理行动等。关注工具生态了解如LangChain、LlamaIndex等用于构建复杂 LLM 应用的开源框架。实践与反思在日常编码中坚持使用并反思每次交互。记录下哪些提示词效果好哪些不好不断优化你自己的“提示词工具箱”。技术的本质是杠杆。提示词工程就是让我们学会如何更有效地按下大语言模型这个超级杠杆的支点。希望本文能成为你掌握这门新工程艺术的实用指南。如果在实践中遇到具体问题欢迎在评论区交流探讨。
