氛围编程:第三部分,提示词规范

本文探讨了在AI驱动的氛围编程中如何设计有效的系统提示词,包括技术栈定义、角色设定和交互规范,以提升代码生成质量和开发效率。

氛围编程:对话式软件开发——第三部分:提示词规范

有人推测,氛围编程可能会从根本上改变我们构建软件的方式。我们不再需要编写代码行,而是用简单的英语描述目标,然后生成可运行的软件。

在我的上一篇文章中,我尝试了几种氛围编程工具并分享了实践经验。如果你密切关注,可能会注意到一些微妙但重要的细节:我正在使用自然语言作为接口。我选择的词语会影响AI如何解释和构建软件。而在这个过程中,背后有一个关键但常被忽视的层面——系统提示词。

那么,究竟什么是提示词?

将氛围编程视为一个聊天驱动的工程环境。你发送的每条消息,或者说提示词,不仅仅是随意的对话。它更像是为你的AI助手编写操作手册。提示词设定了基本规则。它可以定义你偏好的技术栈、编码风格、命名约定,或者AI在做出假设之前是否应该请求澄清。换句话说,它是你调整AI以符合意图的接口。

为什么提示词很重要

根据我的经验,如果提示词不清晰或不一致,事情很快就会偏离轨道。以下是我在提示词模糊时遇到的一些问题:

  • AI选择了错误的编程语言。
  • 它引入了陌生且有时不必要的库。
  • 它忽略了之前的上下文并给出了矛盾的结果。

即使使用像ChatGPT、Claude或Cursor这样的先进工具,指令的模糊性也可能导致不可预测的行为。问题不在于模型的质量,而在于我们给出的指示的清晰度。

配置系统提示词

使用大多数现代AI平台的一个好处是,它们允许用户定义系统级提示词。你可以全局定义提示词(在整个工作区)或本地定义(针对每个项目)。这有助于保持一致性,避免重复上下文。

我现在养成了一个习惯,在每次编码会话开始时明确设置系统提示词。这就像配置你的开发环境,但是以对话的形式。

设计一个有效的提示词

我还在不断学习,但我想分享一个对我很有效的示例提示词。想法是从一开始就设定清晰的约束。这给了AI更少的误解空间,并减少了会话期间的摩擦。以下是我经常使用的一个示例系统提示词:

1
2
3
4
5
Consider yourself a frontend developer.
All UI components should use React and Tailwind CSS.
Use JavaScript only and avoid any external libraries unless specified.
Ask for clarification if any requirement is unclear.
Focus on clean and modular code.

这个提示词做了几件重要的事情:

  • 它定义了助手的角色(前端开发者)。
  • 它设定了技术边界——不使用Python、TypeScript或意外的库。
  • 它鼓励AI在模糊时提问。

你可以根据项目需求轻松扩展这个提示词。例如:

  • 所有UI组件必须可访问。
  • 确保移动响应性。
  • 后端基于Java API构建。

这种初始对齐通过减少时间消耗和限制AI交互来简化开发。你可以根据开发方法和技术选择指导AI聚焦。

另一个观察是,AI助手在使用常用框架和工具(如React、Tailwind和Node)时表现出更高的效率。这些模型已经看到了更多这些技术的例子,这意味着你会得到更可靠和相关的响应。

新开发者:不要过度思考

如果你一直在跟进,到目前为止的讨论可能会让你觉得在开始氛围编程之前需要掌握十几个概念。但这不是真的。如果你刚刚开始,我的建议是设定一些清晰的边界并开始行动。让我们以创建一个交互式仪表板为例。以下是一个有效的提示词示例:

1
2
I am a new developer. I want to build an interactive data dashboard.
Can you suggest a tech stack that is easy to maintain and well-supported?

大多数AI助手如ChatGPT、Claude和Gemini会帮助你完成接下来的步骤。助手会提出澄清你需求的问题,这允许它们开发你的技术栈和系统提示词。

帮助你设计更好提示词的工具

随着我继续实验,我意识到正确的提示词有多么重要。好消息是?你不必猜测。像Anthropic Claude Console、Google Gemini和ChatGPT这样的工具可以帮助你实时测试、迭代和优化提示词。以下是我使用Google Gemini优化提示词的一个例子。

我的提示词优化过程

我从这个基础提示词开始探索伦敦空气质量数据:

1
2
3
I want to build an interactive dashboard for exploring data located at London Air Quality Data (Excel).
Please ask me questions to better understand the requirements.
Also then help me write a system prompt that guides you to use React, Tailwind, and D3 for visualization.

注意:如果伦敦空气质量数据在上述链接不可用,我在撰写本文时提交了一个CSV副本。

Gemini问了一些聪明的后续问题,关于:

  • 我设想的可视化类型
  • 我期望的交互性类型
  • 布局偏好
  • 我计划如何处理数据源

为了缩小范围,我指导聚焦到一个工作表:

1
Only evaluate the ‘Monthly Averages’ sheet. Assume everything else

基于此,Gemini帮助我生成了一个优化的系统提示词,我可以用来生成我的仪表板。以下是输出提示词:

 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
42
43
### System Prompt:
You are an expert web development assistant tasked with building an interactive data exploration dashboard. Your goal is to generate a detailed plan, including component structure and initial code snippets, for a React application that visualizes air quality monthly averages.
__Project Objective__
Create an interactive dashboard to explore monthly average air quality data for London, sourced from a specific Excel file.
### Core Technologies:
- Frontend Framework: React
- Styling Framework: Tailwind CSS
- Visualization Library: D3.js
### Data Source:
- __URL__: https://data.london.gov.uk/download/290a22f1-5eef-4801-8286-3f288b49093a/acce7f88-70f0-4fd0-9160-f02a9d96b2c3/air-quality-london.xlsx
- Specific Sheet to Use: "monthly averages"
### Data Interpretation & Preparation:
1. Download and parse the Excel file from the provided URL.
2. Focus exclusively on the data within the "monthly averages" sheet.
3. Identify key columns for visualization:
  - Date (or equivalent column representing the month/year for aggregation)
  - Site Name (or equivalent for location/monitoring station)
  - Pollutant (or equivalent for the type of pollutant, e.g., NO2, PM2.5)
  - Value (or equivalent for the monthly average concentration)
4. Data cleaning and transformation should include:
  - Converting date strings/numbers to valid Date objects.
  - Handling potential missing or invalid data points gracefully (e.g., excluding them from calculations or using interpolation if appropriate for visualization context, but primarily focusing on showing available data).
### Dashboard Functionality & Interactivity:
1. Data Loading: Efficiently load and parse the "monthly averages" data from the Excel file upon component mount. Use an appropriate library like xlsx (SheetJS) for Excel parsing.
2. Filters/Controls:
  - Pollutant Type Filter: Allow users to select one or more pollutant types (e.g., a multi-select dropdown or checkboxes).
  - Monitoring Station Filter: Allow users to select one or more specific monitoring stations/sites.
  - Year Filter: Provide a way to filter data by year (e.g., a dropdown for available years or a range slider if multiple years are selected).
3. Visualizations (D3.js):
  - Time Series Line Chart: The primary visualization should be a line chart showing the monthly average trend over time for selected pollutants and stations.
    -Each line should represent a combination of pollutant and station (or allow choosing a single pollutant to compare multiple stations, or vice versa).
    - Axes should be clearly labeled (e.g., "Date" on X-axis, "Concentration" on Y-axis).
  - Interactive Tooltips: On hover, display detailed information for specific data points (e.g., date, pollutant, station, exact monthly average value).
4. User Interface (React & Tailwind CSS):
  - Clean, responsive, and intuitive dashboard layout.
  - Filter controls should be easily accessible (e.g., in a sidebar or header).
  - The main visualization area should be prominent.
  - Use Tailwind CSS for all styling, ensuring a modern and clean aesthetic.
### Output Requirements:
1. A high-level React component structure (e.g., App.js, Dashboard.js, Chart.js, FilterControls.js).
2. Pseudo-code or a conceptual outline for data fetching and initial parsing of the Excel sheet.
3. An example of how a D3 line chart component might receive data and render, focusing on the integration with React and general D3 patterns.
4. Considerations for managing application state (e.g., selected filters, loaded data).

最终想法

系统提示词需要持续优化,因为它们需要匹配项目不断变化的需求,就像我们重写代码以提高其清晰度和可维护性一样。你的提示词应该随着项目的发展而演变,以反映:

  • 新工具或技术栈变化
  • 更新的编码模式或风格指南
  • 架构或设计决策的转变

一个好的提示词不仅仅是给助手的基本指令。你可以将其视为你和AI助手之间的设计合同。在我的下一篇也是最后一篇文章中,我将继续讨论如何进一步微调提示词。

我现在的建议是不要过于担心第一次就做到完美。从简单开始,迭代,并将你的提示词视为工程过程的一部分,在这里你的意图与实现相遇。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计