1. 先搞清楚 Karpathy 这 65 行提示词到底解决了什么核心问题

如果你最近在尝试用 AI 辅助编程，比如 Cursor、Copilot 或者 Claude，大概率遇到过这些问题：生成的代码看似能用，但一跑就错；代码风格混乱，像拼凑的；或者 AI 完全没理解你的需求，答非所问。这背后的原因，不是 AI 模型能力不行，而是我们给它的“指令”——也就是提示词——不够清晰、不够系统。

Andrej Karpathy，这位在 AI 和深度学习领域极具影响力的专家，最近就针对 AI 编程助手的现状发表了一系列犀利的观察。有人把他的核心观点和吐槽，提炼、转化成了一份大约 65 行的“系统提示词”。这份提示词的价值，不在于它有多少行代码，而在于它 系统性地重构了 AI 编程的交互范式 。它不是一个魔法咒语，而是一份“工程规格书”，告诉 AI 在写代码时应该遵循什么样的思考流程、质量标准和沟通方式。

简单来说，它解决了 AI 编程中几个最让人头疼的痛点：

1. 需求理解偏差 ：AI 经常误解或过度简化复杂需求。
2. 代码质量不可控 ：生成代码缺乏结构、可读性、错误处理和必要的注释。
3. 缺乏系统性 ：AI 的回答是点状的，没有从问题拆解到方案验证的完整闭环。
4. 沟通成本高 ：用户需要反复纠正和补充，陷入低效的对话循环。

这份提示词适合所有正在或打算使用 AI 编程工具（如 Cursor、Claude、ChatGPT 等）的开发者，无论是想提升日常编码效率，还是希望将 AI 更可靠地集成到工作流中。它的核心价值是 将一次模糊的对话请求，转变为一个可重复、可验证的软件工程协作流程 。

2. 核心能力拆解：这 65 行提示词里到底规定了什么

这份提示词不是一个简单的功能列表，它更像一份给 AI 的“岗位职责描述”和“工作流程手册”。我们可以把它拆解成几个关键的能力模块，这样你就能明白它为什么有效。

2.1 强制进行问题澄清与范围界定

普通的提示词可能是：“帮我写一个 Python 函数处理 CSV 文件。” AI 会直接生成一个函数，但可能忽略编码、空值、大文件处理等细节。 Karpathy 风格的提示词会要求 AI 必须首先 主动提问 ，以澄清模糊点。例如：

• “你提到的 CSV 文件大概有多大？这决定了我是用 pandas 还是标准库 csv 。”
• “处理的具体含义是什么？是过滤行、计算列，还是格式转换？”
• “对异常情况（如文件不存在、格式错误）有什么处理要求？”

这个模块确保了 AI 在动手前，和你在“需求”层面达成一致，避免了后续大量的返工。

2.2 定义结构化的输出格式与代码规范

它规定了 AI 输出的代码必须包含以下部分，并给出了具体标准：

• 清晰的代码结构 ：要求模块化，函数职责单一。
• 详尽的注释 ：不仅是“做什么”，更要解释“为什么这么做”，尤其是涉及复杂逻辑或取舍时。
• 完整的错误处理 ：对可能失败的操作（IO、网络、数据解析）必须有 try-except 等机制，并提供有意义的错误信息。
• 类型提示 ：对于支持类型提示的语言（如 Python、TypeScript），必须使用，这能极大提升代码的可读性和 AI 自身后续推理的准确性。
• 可测试性 ：鼓励甚至要求 AI 提供简单的使用示例或测试用例。

这相当于把团队的代码审查标准提前内置到了提示词里。

2.3 引入“思维链”与分步验证

提示词要求 AI 在生成最终代码前，先展示其思考过程。例如：

1. “我将采用 X 方案，因为相比 Y 方案，它在内存使用上更优。”
2. “第一步，我需要读取文件。考虑到文件可能很大，我会使用流式读取。”
3. “第二步，解析数据。这里需要注意日期格式可能不统一。”
4. “最后，我会将结果写入新文件，并确保目录存在。”

这个过程让 AI 的“黑盒”决策变得可见。如果它的思考方向错了，你可以在它写代码之前就进行纠正，节省大量时间。

2.4 强调迭代与基于反馈的改进

它设定了 AI 不是一个“一次性代码生成器”，而是一个可以接受反馈、进行迭代的协作伙伴。提示词会要求 AI 在输出代码后，主动询问：

• “这是初步实现，是否需要调整性能或增加更多功能？”
• “你对错误处理的方式满意吗？”
• “需要我为你解释某个复杂部分的逻辑吗？”

这建立了一个正向的改进循环，而不是“生成-不满意-重来”的无效循环。

3. 如何将这份“规格书”应用到你的 AI 编程工具中

理解了核心思想后，下一步就是落地。你不需要一字不差地复制那 65 行文本，关键是吸收其精髓，并适配到你常用的工具里。下面以 Cursor 和 Claude 为例，给出实操步骤。

3.1 环境与工具准备

• Cursor ：确保你使用的是最新版本。它的优势是深度集成 IDE，能理解项目上下文。
• Claude (Web 版或 API) ：建议使用 Claude 3.5 Sonnet 或更高版本，其在代码和复杂推理上表现更好。
• 核心意识 ：准备好将 AI 视为一个需要严格“ briefing ”的初级工程师，而不是一个能读心的魔法精灵。

3.2 构建你自己的系统提示词（以 Claude 为例）

你可以在 Claude 的聊天窗口，或者在 Cursor 的“Chat”模式中，首先发送一条“系统提示词”。这条消息定义了整个对话的规则。

下面是一个融合了 Karpathy 思想的简化版系统提示词模板，你可以直接使用或修改：

你是一个资深软件工程师，擅长编写清晰、健壮、可维护的代码。在本次对话中，你将协助我完成编程任务。请严格遵守以下协作流程：

1.  **需求澄清**：在开始编写任何代码之前，你必须先针对我的需求提问，以澄清所有模糊、缺失或可能产生歧义的地方。包括但不限于：输入/输出格式、边界条件、性能要求、错误处理预期、现有技术栈限制等。

2.  **结构化思考**：在确认需求后，请先口头描述你的解决方案大纲，包括技术选型理由、关键步骤和潜在风险。在我认可该方案后，再开始编写代码。

3.  **代码生成标准**：
    *   **模块化**：函数/方法职责单一，保持简短。
    *   **注释**：为复杂逻辑添加注释，解释“为什么”这么做，而不仅仅是“做什么”。
    *   **错误处理**：对任何可能失败的操作（文件、网络、用户输入）进行防御性编程，并提供友好的错误信息。
    *   **类型提示**：如果使用 Python、TypeScript 等语言，务必使用类型提示。
    *   **可测试性**：在代码后提供一个简单的使用示例或调用方式。

4.  **迭代与反馈**：生成代码后，主动询问代码是否满足要求，以及有哪些部分需要改进或解释。

请现在确认你已理解上述规则。我的第一个需求是：[在此处粘贴你的具体需求]

关键操作 ：在 Claude 网页版，你可以把这段话发出去。在 Cursor 中，你可以将其保存为一个代码片段或文档，每次开始新对话时粘贴进去。

3.3 从单任务到工作流：实战案例拆解

假设我们的需求是：“帮我写一个 Python 脚本，从一个 JSON 文件中读取用户数据，过滤出活跃用户（最后登录时间在 30 天内），并计算他们的平均年龄。”

旧方式（低效） ： 用户直接发送上述需求。AI 可能直接生成一个没有错误处理、假设 JSON 结构固定、且没有考虑时间解析复杂性的脚本。运行失败后，用户需要再问：“如果文件不存在怎么办？”“日期格式可能是字符串时间戳怎么办？”

新方式（应用系统提示词） ：

1. 你 ：发送上面那段系统提示词，并在末尾附上需求。
2. AI (遵循提示词) ：
   • 第一步：澄清需求 。
     • “好的，我理解需求。在开始前，我需要澄清几点：
       1. JSON 文件的结构是怎样的？例如，是否有示例片段？‘最后登录时间’字段的名称是什么？它的格式是标准 ISO 字符串、时间戳还是其他？
       2. ‘活跃用户’的判断是‘最后登录时间’大于（当前时间 - 30天）吗？时区如何处理？
       3. 如果文件不存在、JSON 格式损坏、或某些用户记录缺少‘年龄’或‘最后登录时间’字段，你希望脚本如何行为？是报错、跳过还是使用默认值？
       4. 计算出的平均年龄，输出到屏幕还是保存到新文件？”
   • 第二步：方案确认 。
     • 在你回答上述问题后，AI 会说：“基于你的澄清，我将采用以下方案：使用 json 库读取文件，用 datetime 模块处理时间，过滤时考虑时区统一为 UTC，缺失字段的记录将被跳过并记录警告，最终结果打印到控制台。这样可以吗？”
   • 第三步：生成代码 。
     • 在你确认后，AI 生成一个包含 try-except 、日志警告、清晰函数划分、带类型提示和详细注释的 Python 脚本。并在最后附上：“这是脚本，你可以用 python script.py data.json 运行。需要我添加将结果写入文件的功能吗？”

这个流程的对比非常明显。新方式虽然前期对话回合稍多，但一次性产出了 可直接运行、更健壮、更符合工程标准 的代码，总耗时反而更少。

3.4 在 Cursor 中实现“持久化”系统提示

Cursor 支持更强大的集成。你可以创建一个项目级的上下文文件。

1. 在项目根目录创建一个文件，例如 .cursor/rules/ai_coding_guide.md 。
2. 将你的系统提示词（精简版）写入这个文件。
3. 在 Cursor 的设置中，或通过 @ 命令引用这个文件。这样，你在这个项目中的每一次 AI 对话，都会自动继承这些规则。

这相当于为你的项目配备了一位永远遵循最佳实践的 AI 协作者。

4. 关键参数与效果判断：如何评估你的提示词是否有效

应用了新的提示词方法后，不能凭感觉说“好像更好用了”。需要有明确的判断标准。

4.1 输入侧：需求澄清的深度

• 有效指标 ：AI 在编码前，能提出 2-4 个切中要害的澄清问题。问题应涉及 数据格式、边界条件、异常处理、性能预期 等工程细节。
• 无效表现 ：AI 直接开始写代码，或问一些非常泛泛的问题（如“你能详细说说吗？”）。

4.2 过程侧：思考链的可见度

• 有效指标 ：AI 能说出“我计划用 A 库而不是 B 库，因为…”、“第一步先验证输入，第二步…”、“这里有个潜在风险是…”。
• 无效表现 ：思考过程缺失，或只有一句“我将编写一个函数来完成”。

4.3 输出侧：代码质量的维度

制定一个简单的检查清单，生成的代码应满足大部分要求：

维度	具体检查项	达标示例
健壮性	1. 是否有输入验证？ 2. 是否有错误处理（try-except/error handling）？ 3. 是否处理了空值或缺失数据？	使用 if not os.path.exists(file_path): 进行检查；对 json.load() 使用 try-except。
可读性	1. 函数/方法是否简短（通常<50行）？ 2. 是否有解释复杂逻辑的注释？ 3. 变量/函数名是否清晰？	注释写：“这里使用 defaultdict 是为了避免在键不存在时进行条件判断。”
可维护性	1. 是否使用了类型提示？ 2. 配置（如时间间隔30天）是否定义为常量？ 3. 逻辑是否模块化？	def filter_active_users(users: List[User]) -> List[User]: ； ACTIVE_THRESHOLD_DAYS = 30 。
可测试性	1. 是否提供了简单的调用示例？ 2. 代码结构是否便于单独测试函数？	在脚本末尾有 if __name__ == "__main__": 的示例调用。

4.4 协作侧：迭代的顺畅度

• 有效指标 ：代码生成后，AI 会主动询问“是否需要调整？”或“需要我解释某部分吗？”。当你提出修改意见（如“改成输出到文件”），AI 能基于现有代码结构快速、准确地修改，而不是推倒重来。
• 无效表现 ：每次修改都像全新的请求，没有上下文延续。

5. 常见问题与排查：当效果不如预期时怎么办

即使使用了好的提示词，效果也可能不稳定。问题通常不出在提示词本身，而在使用细节上。

5.1 问题：AI 仍然直接生成代码，不提问

• 排查顺序 ：
  1. 检查提示词位置 ：你是否将系统提示词作为 第一条消息 发送？在有些对话中，如果先聊了别的，再发系统提示词，AI 可能不会切换模式。
  2. 检查模型能力 ：尝试换用能力更强的模型，如 Claude 3.5 Sonnet 或 GPT-4。较弱的基础模型可能无法很好地遵循复杂指令。
  3. 简化提示词 ：将 65 行的核心思想浓缩成更简短的 3-4 条强制要求，放在最前面。有时指令过于冗长，模型反而抓不住重点。
  4. 手动触发 ：如果 AI 直接开始写，立即打断它，说：“请先暂停。根据我们的协作规则，你需要先向我提问以澄清需求。” 强化规则。

5.2 问题：AI 的提问很肤浅，抓不住关键点

• 排查顺序 ：
  1. 审视你的初始需求 ：你的需求描述是否本身就非常模糊？尝试自己先写下更详细的“需求规格”，包括输入示例、期望输出、非功能要求等。给 AI 的输入质量，直接决定其输出质量。
  2. 在提示词中提供示例 ：在系统提示词里加入一个“优秀提问”的例子。例如：“例如，当用户请求‘处理文件’时，你应该询问文件格式、大小、编码、处理逻辑和错误处理方式。”
  3. 进行“种子对话” ：先在一个对话中，手动引导 AI 完成一次完美的协作流程（你扮演严格的产品经理）。然后将这个完整的对话记录作为后续对话的“Few-shot”示例，放在系统提示词之后。

5.3 问题：生成的代码有细节错误或逻辑漏洞

• 排查顺序 ：
  1. 不要假设 AI 全知 ：即使遵循了流程，AI 也可能犯细节错误。 永远要 Review 生成的代码 ，尤其是核心逻辑和边界条件。
  2. 要求 AI 自我审查 ：在提示词中增加一条：“在输出代码前，请模拟执行一遍，检查是否有明显的逻辑错误、边界条件未处理或语法问题。”
  3. 聚焦关键模块 ：对于复杂任务，不要要求 AI 一次性生成整个脚本。可以分步进行：“第一步，只写读取和解析 JSON 文件的函数，并包含错误处理。” 验证无误后，再进行下一步。

5.4 问题：对话上下文太长，AI 忘记规则

• 排查顺序 ：
  1. 利用工具的“系统指令”功能 ：许多 AI 编程工具（如 Cursor 的高级设置、某些 API 参数）有专门的“系统指令”或“助理预设”字段，将核心规则放在这里，比放在聊天历史中更稳定。
  2. 定期重申规则 ：在长时间、多回合的对话中，可以在关键节点温和地重申规则，例如：“我们继续遵循之前的协作流程，请先为下一个功能点提供方案设计。”
  3. 开启新对话 ：对于全新的、独立的子任务，直接开启一个新的聊天窗口并粘贴系统提示词，保持上下文的清晰。

6. 进阶应用与边界：超越单次代码生成

这套方法的威力不仅在于生成一段更好的代码，更在于它能塑造一个可靠的 AI 协作工作流。

6.1 构建领域特定的提示词模板

将通用提示词与你的专业领域结合。

• Web 开发 ：加入对 API 安全性（输入消毒）、数据库操作（事务处理）、并发考虑的强调。
• 数据分析 ：强调对数据质量的检查（缺失值、异常值）、可复现性（随机种子）、可视化规范。
• 嵌入式/C++ ：强调内存管理（RAII）、资源限制、硬件相关约束。 创建几个不同的 .md 文件，如 web_dev_prompt.md 、 data_analysis_prompt.md ，根据任务类型调用。

6.2 管理复杂任务与多文件项目

对于涉及多个模块的复杂任务，提示词可以引导 AI 进行顶层设计。

1. 第一阶段（设计） ：要求 AI 先输出项目结构图、模块划分和接口定义。
   • “基于这个需求，请先设计一个简单的项目结构，说明主要模块及其职责，并定义核心函数接口。”
2. 第二阶段（分步实现） ：然后要求 AI 逐个实现模块，每次聚焦一个文件。
   • “现在，请首先实现 data_loader.py 模块，专注于安全地读取和验证数据。”
3. 第三阶段（集成与测试） ：最后让 AI 提供集成脚本或简单的端到端测试。
   • “请提供一个 main.py 或测试用例，演示如何将这些模块组合起来运行。”

6.3 理解边界：提示词不是银弹

必须清醒认识到这套方法的边界：

• 不替代思考 ：它不能帮你做技术选型或架构决策，它只是让你的决策更清晰地被 AI 执行。
• 不保证正确 ：它大幅降低错误概率，但生成的代码仍需你这位资深工程师的审查和测试。AI 可能产生看似合理实则错误的逻辑。
• 依赖模型能力 ：提示词工程是“放大镜”，不是“无中生有”。基础模型能力越强，这套方法的效果越惊艳。在较弱模型上，效果会打折扣。
• 不适用于所有场景 ：对于极其简单、明确的任务（如“写一个快速排序函数”），直接请求可能更高效。这套方法的价值在 复杂度高、模糊性强、需要工程严谨性 的任务中才能最大化体现。

最终，Karpathy 这 65 行提示词的精髓，是教会我们以“工程化”的思维与 AI 协作。它把 AI 从一个可能给出惊喜也可能给出惊吓的“魔术师”，变成了一个流程规范、可预期、可管理的“初级工程师”。你付出的，是前期更严谨的需求描述和规则制定；你收获的，是整体开发效率和代码质量的显著提升。真正的节省时间，不是让 AI 写得快，而是让它一次就写对。