Meta提示、上下文工程与规格驱动的开发系统

Meta提示、上下文工程与规格驱动的开发系统

基本信息

• 作者: stefankuehnel
• 评分: 76
• 评论数: 32
• 链接: https://github.com/gsd-build/get-shit-done
• HN 讨论: https://news.ycombinator.com/item?id=47417804

导语

在技术写作与复杂开发场景中，如何将模糊的需求转化为精确的代码始终是核心挑战。本文介绍了一套结合元提示词、上下文工程与规格驱动开发的系统，旨在通过结构化的流程提升交付质量。读者将了解到如何构建可复用的提示框架，以及如何利用上下文管理来减少模型幻觉，从而在实际项目中实现更可控的自动化开发。

评论

中心观点

该文章提出了一种基于规格驱动和上下文工程的元提示系统，旨在通过严格的文档化约束和自动化反馈循环，将大语言模型（LLM）从“聊天机器人”转变为高精度的“代码生成引擎”，以解决复杂开发任务中的不可控性和幻觉问题。

深入评价

1. 内容深度与论证严谨性

• 支撑理由（事实陈述/作者观点）： 文章深刻触及了当前LLM应用的核心痛点——上下文窗口的有效利用率与指令遵循的稳定性。它没有停留在简单的“Prompt Engineering”技巧层面，而是引入了软件工程中“规格说明书”的概念。论证逻辑非常严密：如果输入（Prompt/Context）是模糊的，输出必然是不可靠的；因此，必须通过形式化的Spec来约束LLM的行为。
• 反例/边界条件（你的推断）： 该方法在处理高度依赖“隐性知识”或“直觉”的任务时可能失效。例如，UI/UX设计往往需要非结构化的探索，过度严格的Spec可能会扼杀LLM的创造性发散能力。此外，该方法假设LLM具备极强的长文本记忆和逻辑推理能力，但在处理超大规模代码库（如百万行级别）时，上下文截断仍会导致逻辑断裂。

2. 实用价值与创新性

• 支撑理由（事实陈述）： 文章提出的“元提示”框架具有极高的实战价值。它将开发流程解耦为：User Intent -> Spec Writer -> Coder -> Reviewer。这种流水线作业模式，使得开发者可以通过调整中间环节来优化最终产出，而不是像传统Prompt那样“一次性赌博”。
• 支撑理由（作者观点）： “上下文工程”被提升到了与代码工程同等的高度。文章强调构建高质量的上下文包，这直接击中了RAG（检索增强生成）系统的软肋——检索质量往往决定生成上限。
• 反例/边界条件（你的推断）： 对于初创公司或快速原型开发，该流程显得过于沉重。编写详细的Spec本身就需要大量时间，如果任务是一次性的，这种投入产出比（ROI）可能为负。

3. 行业影响与争议点

• 支撑理由（你的推断）： 这篇文章预示了软件开发角色的转变：开发者将从“编写代码的人”变为“编写规格的人”和“审查代码的人”。它推动了行业从“手写Prompt”向“系统化Prompt工程”的范式转移。
• 争议点（作者观点 vs 行业现状）： 文章似乎暗示通过纯文本指令和Spec就能完全驱动开发，这可能低估了现有代码库的复杂性和遗留系统的依赖地狱。许多资深工程师认为，没有深层语义理解的LLM，仅靠Spec无法处理复杂的并发或底层系统优化。

实际应用建议

为了验证该文章提出的方法论，建议采取以下步骤：

1. 分层验证实验：

   • 对照组： 直接向GPT-4/Claude 3发送需求，让其一次性生成代码。
   • 实验组： 按照文章方法，先要求生成Spec，确认无误后再生成代码。
   • 观察窗口： 记录代码的一次通过率、人工修改的行数、以及逻辑错误的数量。通常实验组在复杂任务上的修改成本会显著降低。

2. 建立“上下文评分”机制：

   • 不要盲目把所有文档扔给LLM。在Prompt中加入一道“元指令”：“请列出你完成该任务所缺少的关键信息”。如果LLM列出的信息与你提供的上下文重叠度低，说明你的上下文工程是失败的。

3. 关注Token成本与延迟：

   • 这种方法会显著消耗输入Token。建议在实施前，针对特定模型（如Claude 3.5 Sonnet vs GPT-4o）建立成本监控仪表盘。如果一次迭代成本超过0.5美元，可能需要优化上下文压缩策略。

4. 人机回环检查：

   • 在“Reviewer”环节，强制要求LLM输出具体的测试用例，并在人类确认测试用例通过后，再进行下一轮迭代。这能有效防止LLM产生“自嗨型代码”（即代码看起来通顺，但逻辑错误）。

总结

这篇文章是一篇针对高级AI工程从业者的高质量技术指南。它不仅提供了方法论，更是一种思维模式的升级：从“与AI对话”转变为“管理AI员工”。虽然其重型流程可能不适合所有场景，但在构建高可靠性、企业级AI应用时，这种Spec-Driven的方法论代表了未来的方向。

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# 示例1：元提示词生成器
def generate_meta_prompt(task_description, context=""):
    """
    根据任务描述和上下文生成结构化的元提示词。
    :param task_description: 任务描述字符串
    :param context: 可选的上下文信息
    :return: 格式化的提示词字符串
    """
    prompt_template = f"""
    [角色设定]
    你是一个专业的开发助手，擅长解决以下类型的问题：
    {context if context else "通用开发任务"}

    [任务目标]
    {task_description}

    1. 提供完整可运行的代码
    2. 包含详细中文注释
    3. 说明实现思路

    [约束条件]
    - 遵循最佳实践
    - 考虑边界情况
    - 代码简洁易读
    """
    return prompt_template.strip()

# 使用示例
task = "实现一个快速排序算法"
prompt = generate_meta_prompt(task, "算法实现与优化")
print(prompt)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

# 示例2：上下文管理器
class DevelopmentContext:
    """
    开发上下文管理器，用于维护和传递开发过程中的关键信息。
    """
    def __init__(self):
        self.context = {
            "project_name": "",
            "tech_stack": [],
            "requirements": [],
            "constraints": []
        }
    
    def add_requirement(self, req):
        """添加需求到上下文"""
        self.context["requirements"].append(req)
    
    def set_tech_stack(self, *techs):
        """设置技术栈"""
        self.context["tech_stack"] = list(techs)
    
    def generate_spec(self):
        """生成规格说明文档"""
        return f"""
        项目规格说明
        ============
        项目名称: {self.context['project_name']}
        技术栈: {', '.join(self.context['tech_stack'])}
        主要需求:
        {chr(10).join(f"- {req}" for req in self.context['requirements'])}
        约束条件:
        {chr(10).join(f"- {c}" for c in self.context['constraints'])}
        """

# 使用示例
ctx = DevelopmentContext()
ctx.context["project_name"] = "电商系统"
ctx.set_tech_stack("Python", "Django", "PostgreSQL")
ctx.add_requirement("用户认证")
ctx.add_requirement("商品管理")
print(ctx.generate_spec())

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 示例3：规格驱动开发工具
def spec_driven_development(spec):
    """
    根据规格说明生成开发任务清单。
    :param spec: 包含项目规格的字典
    :return: 任务清单列表
    """
    tasks = []
    for key, value in spec.items():
        if isinstance(value, list):
            for item in value:
                tasks.append(f"实现 {key}: {item}")
        else:
            tasks.append(f"配置 {key}: {value}")
    return tasks

# 使用示例
spec = {
    "数据库": ["用户表", "订单表"],
    "API": ["RESTful接口", "认证中间件"],
    "前端": ["React组件", "状态管理"]
}
print(spec_driven_development(spec))

案例研究

1：某 Fintech 初创公司的内部效能提升

1：某 Fintech 初创公司的内部效能提升

背景: 该公司正在开发一款复杂的金融合规 SaaS 平台，开发团队由 5 名高级工程师组成。由于业务逻辑极其复杂，涉及大量的监管文档和动态规则，传统的敏捷开发流程在处理需求变更时显得非常吃力。团队经常陷入“编码-等待反馈-重构”的循环，导致交付周期不可预测。

问题: 主要痛点在于需求规格说明书往往不够清晰，开发人员需要花费大量时间在 Slack 上反复确认业务细节。此外，AI 辅助编程工具（如 GitHub Copilot）虽然能补全代码，但在处理复杂的跨文件架构和严格的业务规则约束时，经常产生幻觉代码，导致后期集成成本高昂。

解决方案: 工程主管引入了一套基于“Spec-Driven（规格驱动）”的元提示系统。团队不再直接让 AI 写代码，而是先编写详细的 Markdown 格式技术规格书，利用元提示工程上下文，将整个项目的代码库结构、API 定义和业务规则注入到 LLM 的上下文窗口中。

具体操作是：

1. 将需求文档转化为结构化的 Prompt 模板。
2. 强制 LLM 先生成逻辑伪代码和架构图，经人工审核后才允许生成具体代码。
3. 利用上下文工程技术，确保 AI 生成的代码严格遵循现有的设计模式，而不是随意引入新库。

效果: 实施该系统后，需求澄清的时间减少了约 60%，因为规格书的编写过程本身就让逻辑漏洞暴露无遗。AI 生成的代码首次通过编译的成功率从 40% 提升到了 85%以上，极大地减少了调试和重构时间。团队最终将原本预计 3 个月的开发周期缩短至 6 周，且交付的代码完全符合合规要求。

2：某中型电商企业的遗留系统重构

2：某中型电商企业的遗留系统重构

背景: 该企业拥有一个运行了 7 年的订单管理系统（OMS），基于早期的 PHP 框架构建。由于维护人员离职和文档缺失，现有团队对业务逻辑的理解仅停留在“能跑就行”的层面。公司决定将其重构为基于 Go 语言的微服务架构，以应对大促流量。

问题: 最大的挑战在于“知识断层”。新团队成员不敢轻易修改核心逻辑，而 LLM 在面对这种缺乏文档且逻辑混乱的遗留代码时，往往无法理解真实的业务意图，生成的重构方案经常丢失关键的边缘业务逻辑（例如特殊的促销计算规则）。

解决方案: 技术团队采用“Context Engineering（上下文工程）”策略，构建了一个针对该项目的知识库 Prompt。

1. 他们利用 LLM 对旧系统进行了一次全面的“代码审计”，并生成了交互式的业务流程图，作为上下文的一部分。
2. 建立了一个元提示工作流：在生成新代码前，系统会强制检索旧代码中相关函数的逻辑，并要求 LLM 对比“旧逻辑”与“新需求”，列出所有潜在的兼容性风险清单。
3. 开发人员基于这份风险清单进行确认，再由 AI 生成符合新架构规范的 Go 语言代码。

效果: 这种“人机协同审计”的方式成功识别出了 20 多个在需求文档中未提及但在旧代码中实际存在的硬编码业务逻辑。重构后的系统上线后，没有出现任何因逻辑遗漏导致的订单事故。相比完全人工重构，这套系统节省了约 40% 的人力和时间成本，同时为团队补全了缺失多年的技术文档。

3：独立开发者的全栈 MVP 快速交付

3：独立开发者的全栈 MVP 快速交付

背景: 一位独立开发者致力于验证一个 B2B 自动化工具的市场需求。他需要在极短的时间内（2 周）上线一个功能完备的 MVP（最小可行性产品），包括前端、后端、数据库设计以及第三方 API 集成。

问题: 开发者擅长产品设计和逻辑构思，但在编写后端样板代码（如 CRUD 操作、身份验证中间件、数据库迁移脚本）方面效率较低。如果使用传统的 AI 聊天助手，往往需要反复复制粘贴代码片段，且容易出现版本冲突和依赖管理混乱，导致开发环境经常崩溃。

解决方案: 他采用了一套“Get Shit Done”风格的自动化脚本和元提示库。

1. 他定义了一套严格的项目结构模板。
2. 编写了一个主控脚本，通过元提示将高层级的用户故事（例如“用户需要通过 Google 登录并导出 CSV”）拆解为具体的任务列表。
3. 系统自动调用不同的 Prompt 模板来生成数据库 Schema、后端 API 接口代码以及前端组件，并自动将这些代码注入到项目的正确目录下。

效果: 开发者在 10 天内完成了 MVP 的开发并成功上线。该系统让他能够专注于核心业务逻辑的实现，而将 80% 的重复性编码工作交给了元提示系统处理。由于代码是根据统一规范生成的，各个模块之间的集成非常顺畅，几乎没有出现兼容性问题。

最佳实践

最佳实践指南

实践 1：基于规格说明书的开发

说明: 将开发过程从“即兴编写”转变为“严格遵循规格”。在编写代码之前，必须先编写详细的技术规格文档。这不仅是给人类看的，更是给 AI 看的上下文基础。规格文档应包含功能需求、数据结构、API 接口定义和边缘情况处理。

实施步骤:

1. 在开始任何编码任务前，强制要求生成或更新 SPEC.md 文件。
2. 使用结构化的模板（如 State-Context 或 RFC 格式）来定义规格。
3. 确保规格中明确列出了“输入”和“预期输出”的示例。
4. 在提示词中明确指示 AI：“请严格遵循 SPEC.md 中的定义进行实现，不要自行发挥。”

注意事项:

• 规格一旦确定，中途变更需重新审视上下文。
• 避免在规格中使用模糊不清的词汇（如“等”、“大概”），必须精确。

实践 2：模块化上下文注入

说明: 不要将所有上下文（代码库、历史记录、需求）一次性塞给模型。采用“上下文工程”策略，按需动态加载相关的上下文模块。这可以减少 Token 消耗并提高响应的准确性。

实施步骤:

1. 将项目知识库拆分为独立的文件（如 db_schema.sql, api_rules.md, core_logic.js）。
2. 在提示词系统中建立索引或映射关系，根据任务类型检索相关文件。
3. 在构建 Prompt 时，仅引用与当前任务直接相关的文件内容。
4. 使用类似 @file_reference 的语法在提示词中挂载上下文。

注意事项:

• 确保引用的文件内容是最新的，避免上下文过时。
• 注意上下文窗口的极限，必要时对过长的上下文进行摘要处理。

实践 3：元提示词系统设计

说明: 构建一个“提示词之母”或“元提示词”，用于生成其他具体的任务提示词。这个元系统包含编码风格、错误处理原则和项目特定的约束条件。它负责将模糊的用户意图转化为 AI 可执行的高质量指令。

实施步骤:

1. 创建一个 SYSTEM_PROMPT.txt，定义全局约束（例如：“使用 TypeScript”，“必须包含错误处理”）。
2. 编写一个脚本或工具，接收用户输入，结合 SYSTEM_PROMPT 和相关上下文，组装成最终发送给 LLM 的完整 Prompt。
3. 确保元提示词包含“思维链”指令，要求 AI 在编写代码前先解释逻辑。

注意事项:

• 定期审查元提示词的有效性，根据 AI 的输出质量进行微调。
• 保持元提示词的版本控制，以便回滚到更有效的版本。

实践 4：增量式与验证驱动开发

说明: 不要试图一次性让 AI 生成整个系统。采用“小步快跑”的策略，一次只生成一个功能或一个函数，并立即进行验证。这符合“Spec-Driven”的理念，即逐步实现规格中的每一个部分。

实施步骤:

1. 将大的 Issue 拆解为原子化的任务卡片。
2. 每个任务完成后，要求 AI 生成对应的单元测试或集成测试。
3. 运行测试套件，只有测试通过后才被视为任务完成。
4. 将验证通过的代码合并回主分支，并更新上下文库。

注意事项:

• 严格拒绝“未经验证”的代码块。
• 如果测试失败，将错误信息回传给 AI 进行修复，而不是人工修复。

实践 5：严格的上下文隔离与去噪

说明: AI 容易被无关的噪音干扰。在发送请求时，必须剔除无关的依赖、注释或过时的文档。确保发送给 AI 的每一个 Token 都是为了解决当前问题而存在的。

实施步骤:

1. 在构建上下文时，使用工具自动剔除 console.log、调试代码和无用的注释。
2. 如果修改特定模块，只提供该模块的接口定义，而不是其内部实现细节（除非是重构）。
3. 明确告诉 AI 忽略项目中的某些配置文件或目录（如 .git, node_modules）。

注意事项:

• 过度精简可能导致丢失关键逻辑，需要在“简洁”和“完整”之间找到平衡。
• 始终包含必要的类型定义，否则 AI 会因缺乏类型信息而产生幻觉。

实践 6：反馈循环与上下文刷新

说明: 建立一个闭环系统，将 AI 的输出结果（无论是代码还是文档）反馈回上下文库。随着项目的推进，AI 的知识库应该自动更新，以防止它在后续任务中产生与之前代码不一致的冲突。

实施步骤:

1. 每次成功生成的代码，自动更新其对应的文档摘要或接口定义。
2. 维护一个 CHANGELOG.md，由 AI 自动生成变更条目。

学习要点

• 通过“元提示”策略将复杂任务拆解为规划、编码和测试三个阶段，利用AI自我修正和迭代优化大幅提升开发效率。
• 采用“上下文工程”方法，通过模块化提示词和动态上下文注入，确保AI理解任务全貌并减少重复输入。
• 建立基于规范的开发流程，将需求文档转化为可执行的AI指令，实现从需求到代码的自动化转换。
• 利用AI的代码生成和审查能力，结合人类监督，形成“AI主导、人工辅助”的高效协作模式。
• 通过持续反馈循环和版本控制集成，确保AI生成代码的质量与项目需求的一致性。
• 强调“快速迭代”原则，优先完成核心功能再逐步优化，避免过度设计导致的效率损失。

常见问题

1: 什么是 “Get Shit Done” (GSD) 系统？

1: 什么是 “Get Shit Done” (GSD) 系统？

A: “Get Shit Done” 是一种结合了元提示、上下文工程和规格驱动开发的 AI 辅助编程方法论。它不仅仅是一个简单的提示词，而是一套完整的系统，旨在通过提供高度结构化的上下文和明确的规格说明，来引导大型语言模型（LLM）生成高质量、可用且无需大量修改的代码。该系统的核心理念是将软件开发中的“做什么”和“怎么做”进行严格的工程化拆解，从而让 AI 能够像一名高级工程师一样理解任务并执行。

2: 在该系统中，“规格驱动开发”具体是如何运作的？

2: 在该系统中，“规格驱动开发”具体是如何运作的？

A: 在规格驱动开发中，开发者在请求 AI 编写代码之前，必须先定义一个清晰、无歧义的功能规格书。这通常包括：功能的详细描述、输入输出的数据结构定义、边缘情况的处理逻辑、技术栈的限制以及必须遵循的代码规范。GSD 系统强制要求将这个规格书作为上下文的一部分输入给 AI。这样，AI 的任务就从“自由创作”转变为“根据规格实现”，极大地减少了幻觉和逻辑错误，确保生成的代码符合预期的业务逻辑。

3: 什么是“上下文工程”，为什么它比简单的提示词更重要？

3: 什么是“上下文工程”，为什么它比简单的提示词更重要？

A: 上下文工程是指精心选择和组织输入给 AI 的背景信息，以最大化其输出的相关性。与简单的提示词（例如“帮我写一个贪吃蛇游戏”）不同，上下文工程涉及到将项目的文件结构、现有的代码库风格、依赖库的文档片段以及之前的对话历史整合到一个结构化的提示框架中。在 GSD 系统中，上下文工程确保 AI 拥有“全知视角”的项目背景，从而生成能够无缝集成到现有系统中的代码，而不是孤立的、风格不一致的代码片段。

4: GSD 系统中的“元提示”是指什么？

4: GSD 系统中的“元提示”是指什么？

A: 元提示是 GSD 系统的“控制中枢”。它是一段预定义的高层级指令，用于告诉 AI 如何扮演特定的角色（如资深架构师或全栈工程师），以及如何处理后续的输入。元提示通常包含思维链的引导，要求 AI 在编写代码前先进行推理、规划步骤或检查约束条件。它设定了交互的规则，确保 AI 在面对复杂任务时，能够保持逻辑的一致性，并严格按照开发者提供的规格进行工作，而不是偏离主题。

5: 使用这种系统化的开发方式主要解决了什么痛点？

5: 使用这种系统化的开发方式主要解决了什么痛点？

A: 该系统主要解决了 AI 编程中常见的“一次性代码”和“上下文丢失”问题。

1. 减少迭代轮数：通过提供详尽的规格和上下文，AI 生成的代码往往一次就能通过编译和基本测试，减少了开发者反复修正和调试的时间。
2. 代码可维护性：强制要求 AI 遵循规格和现有风格，使得生成的代码易于阅读和后续维护。
3. 降低认知负荷：开发者不需要在每次对话中重复解释项目背景，元提示和上下文机制会自动处理这些信息。

6: 对于初学者来说，实施 GSD 系统最大的难点是什么？

6: 对于初学者来说，实施 GSD 系统最大的难点是什么？

A: 最大的难点在于编写高质量的规格书。许多开发者习惯于模糊的需求描述（例如“做一个好看的登录页”），而 GSD 系统要求将需求转化为精确的技术规格（例如“使用 React Hook Form，验证邮箱格式，错误信息显示在输入框下方，且按钮在请求期间禁用”）。如果规格书写得不清楚或存在逻辑漏洞，AI 生成的代码也会相应地出现问题。因此，使用该系统实际上对开发者的需求分析能力和系统设计能力提出了更高的要求。

7: 这种方法适用于所有类型的编程任务吗？

7: 这种方法适用于所有类型的编程任务吗？

A: 并不完全适用。GSD 系统最适合处理具有明确逻辑、特定输入输出定义以及一定复杂度的功能模块开发，例如编写 API 端点、数据处理脚本或特定的 UI 组件。对于探索性编程、快速原型验证或需要高度创造性设计的任务，这种严格的规格驱动流程可能会显得过于繁琐和僵化，反而会降低开发效率。

思考题

## 挑战与思考题

### 挑战 1: 基础提示词构建

问题**：

在“Get Shit Done”系统中，上下文工程是核心。假设你需要让 AI 编写一个 Python 脚本来抓取特定网站的天气数据。请设计一个包含“角色定义”、“任务描述”和“约束条件”的基础提示词结构，确保 AI 不会凭空捏造不存在的 Python 库。

提示**：

引用

• 原文链接: https://github.com/gsd-build/get-shit-done
• HN 讨论: https://news.ycombinator.com/item?id=47417804

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

• 分类： AI 工程 / 效率与方法论
• 标签： Meta Prompting / 上下文工程 / 规格驱动开发 / LLM / Prompt Engineering / 开发工作流 / 自动化 / 系统设计
• 场景： 大语言模型

相关文章

• 夜间自主运行的智能体系统
• 睡眠期间自动运行的智能体系统
• 夜间自主运行的智能体系统
• 夜间自动运行的智能体系统
• 编码代理的成功对通用AI系统的启示 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。