Tracks
AI智能体基础知识
6小时
什么是 Cursor？
Cursor 起初是将 AI 功能缝合进 VS Code 的产物，表面上看仍是如此：编辑器、文件树、终端、扩展，全都很熟悉。
但底层假设已被重塑：AI 不再只是旁边回答问题，而是真正与您并肩工作。因此，您可以使用代理模式、代码库索引、可在会话中途切换前沿模型的选择器，以及基于您完整上下文预测下一步操作的内联补全。
如果您想进一步探索 Cursor 的最新功能，推荐阅读我们的 Cursor Automations 与 Cursor SDK 教程。
什么是 GPT-5.6？
GPT-5.6 是 OpenAI 最新一代模型，不是单一模型，而是三个：Sol、Terra 与 Luna。这些名称代表三个不同能力层级，取代了旧的“Instant”标签。
简要概览如下：
-
Sol 是旗舰，也是三者中最强的。它是唯一解锁全新
max推理强度与ultra模式的档位，且在编码、生物学与网络安全方面的提升最大。 -
Terra 是日常默认选择。OpenAI 将其定位为以大约半价与 GPT-5.5 竞争。
-
Luna 是用于高吞吐或低时延工作的快捷低价档位，实力超出价格所示。
在编程演示中，Sol 是关键档位，因此本文采用它。Sol 有两个新设置，值得区分您真正会用到哪个：max 是高于 xhigh 的推理强度，允许单个代理在一个难点上投入更长时间，是您在 Cursor 中可设置的最高梯级。ultra 会将工作拆分到并行子代理，OpenAI 公布的基准成绩最佳（Terminal-Bench 2.1 上 91.9%），但仅在 Codex 与 API 中可用，因此您不会在 Cursor 的选择器中看到它。
完整基准表与三档定价，请参阅我们的 GPT-5.6 Sol、Terra 与 Luna 指南。
如何在 Cursor 中访问并配置 GPT-5.6 Sol
GPT-5.6 Sol 可在 Cursor 模型选择器中选用，但有一点需事先了解：与 Cursor 近期的其他前沿模型类似，Sol 只在 Cursor 的Max 模式 下运行。这意味着它会使用完整上下文窗口与全部工具，并按用量计费而非按请求计费，因此在长时间运行时留意 Token 花费。
选择模型的步骤：
- 使用 Cmd+L（Mac）或 Ctrl+L（Windows/Linux）打开代理面板。
- 点击输入区域底部的 Model 按钮（其旁会显示当前模型名称与一个小图标）。
- 如果 Auto 处于开启状态，请将其关闭。
- 在列表中找到 GPT-5.6 Sol，点击其旁的 Edit。
- 右侧将打开一个面板，您可以独立设置上下文窗口、推理强度与快速模式开关。
选择合适的推理强度
选择 Sol 确定了模型；推理强度决定它在当前任务上花多少脑力。 您可以在以下选项间选择：
- None
- Low
- Medium
- High
- Extra High
- Max
None 与 Low 速度最快、成本最低，适用于自动补全或机械式重构，当您基本已经清楚想要什么时即可。
High 与 Extra High 会更慢，因为它会先认真思考问题。当您要求代理规划横跨多个文件的工作，或调试根因不明显的失败时，这种差异尤为明显。
Max 高于 Extra High，给单个代理最多时间攻克难题。Sol 的 ultra 多代理模式仅在 Codex 与 API 中存在，因此您不会在 Cursor 的选择器中看到它。
如果您从 GPT-5.5 迁移而来，要注意各级别并不一一对应。OpenAI 自身的建议是：在熟悉任务上，先比以往低一个档位，只有结果需要时再提高。本文后文也遵循这一点，因此有些步骤的强度低于 5.5 教程的对应环节。
在下面的上手步骤中，我会建议每个任务最合适的推理级别，但也欢迎您自行尝试不同设置，观察输出如何变化。
选择上下文窗口大小与速度模式
您还可以在 272K 与 1M 上下文窗口间选择，并可开启 Fast 模式，以大约 1.5 倍速度生成 Token，但消耗约 2.5 倍额度。在您等待回复的交互式往返中，开启 Fast 往往值得；对于您已交付、期间去做其他事的长任务，则可以关闭。
设置 Cursor
我们来在 Cursor 中设置项目。
先决条件与初始配置
要使用 GPT-5.6 Sol，您需要购买 Cursor 付费方案（Pro 或更高）。由于 Sol 运行在 Max 模式，您的账户需开启按用量计费。 本项目唯一的本地依赖是 Python 3.11+。如果尚未安装 Cursor，请前往 cursor.com 下载，登录，然后在终端中执行：
mkdir budget-api && cd budget-api
git init
cursor .
右侧是代理面板，左侧的文件资源管理器尚无文件——这正是您在让代理构建结构之前所希望的起点。
浏览 Cursor 的 AI 交互界面
在正式开始构建前，了解三种主要交互模式与各自适用场景很有价值，因为用错模式会带来完全可避免的摩擦。
内联补全 是后台自动补全层。您输入时，基于所写内容与文件上下文会出现灰色建议，按 Tab 接受。无需显式调用，它会自行出现。当您手写代码、希望模型减少击键且不打断流程时，这是正确模式。
Ask 模式 用于让模型阅读文件并回答问题，但不做任何修改。可将其视为请同事看一眼代码并给出看法。在陌生代码库、想理解某段代码为何如此编写，或在动手前先思考方案时，它尤其有用。
代理模式 驱动了整个教程。在代理会话中，模型会编辑文件、运行终端命令、安装依赖、执行测试套件、阅读输出，并在失败时自行回环，所有这些都在一个连续线程中完成。此模式下，您是把任务交付出去，而非仅仅发问；并且，您提供的上下文越充分，回收的成果质量越高。在上方截图中，您可在面板左下角看到代理模式选择器。
用 AGENTS.md 建立项目特定指导
这一步由您亲自编写文件，暂不使用模型。先将推理强度切换到 High，因为下一条提示会让代理读取它。多数代理会话跑偏，并非模型出错，而是它不了解项目特定约定而自行猜测：您的框架、命名规范、哪些文件不可更改、如何验证改动。
这正是 AGENTS.md 的作用：给代理看的 README，把对您而言显而易见、对模型却不可见的内容写下来。AGENTS.md 源于 2025 年的 OpenAI 倡议，如今已成为跨工具的代理指令文件标准（隶属 Linux 基金会的 Agentic AI Foundation，与 Anthropic 的 MCP 并列），所以值得一次学习、处处适用。
在项目根目录创建名为 AGENTS.md 的文件，写入以下内容以设定项目工具栈、编码规范与边界：
# AGENTS.md
## Stack
Python 3.11, FastAPI, SQLModel, SQLite (via aiosqlite), pytest, httpx
## Conventions
- All endpoints under /api/v1/
- Pydantic models in app/models.py
- Database logic in app/database.py
- Route handlers in app/routers/
- Type hints required on all function signatures
- Explicit imports only, no wildcards
## Boundaries
- Do not delete or modify any file in tests/ without asking first
- Do not change the DATABASE_URL; it reads from .env
- Never touch pyproject.toml dependencies without showing the diff first
## Verification
Before considering any task complete:
pytest tests/ -v
ruff check .
Both must pass.边界部分是人们最常跳过、却也最重要的。没有它，代理偶尔会“帮忙”去重组或清理您未要求触碰的内容。告诉模型哪些是禁区，与告诉它该做什么同样重要。
AGENTS.md 是跨工具标准，但如果您想使用 Cursor 原生、通过作用域化 .mdc 文件完成同样工作，我们在 Cursor Rules 教程中演示了如何为一个 Python Web 项目构建一套规则。
用 GPT-5.5 构建预算追踪 API
该项目是用于追踪个人预算条目的 REST API。您可以创建条目、支持按类别可选过滤地列出、删除条目，并获取按月支出汇总。
它足够简单，不会在业务逻辑中迷失；但实现涉及数据库层、输入校验、带类型的响应模型与多个路由处理器协作，足以展示代理在真实的多文件会话中如何工作。
步骤 1：搭建项目脚手架
打开代理面板，在发送任何指令前将推理强度设为 High。代理在写任何代码前产出的计划，其价值取决于背后的推理深度；此时给出浅显答案，意味着之后要去解开结构性决策的纠结。作为第一条提示，请发送：
Set up a FastAPI project for a budget tracker API using SQLModel with
async SQLite. Structure it with separate files for models, database, and
routes under an app/ directory. Set up pyproject.toml with uv, install
dependencies, and create a main.py that starts the app.
Before writing any code, show me the planned directory structure
and wait for my approval.最后一行建议在所有非平凡的代理提示中都保留。先要计划再执行，可能只多花您 15 秒阅读时间，却能在决定扩散到十几个文件之前就抓住结构性问题。
在 High 推理强度下，GPT-5.6 Sol 给出的计划足够具体，是真正有用的，而非含糊摘要。现在审阅结构，比日后再重组要快得多。
代理会提出项目布局，并在未写入任何文件前等待您的批准。
当您回复诸如“看起来不错，继续”的话，代理就会开始构建。您可以在左侧实时看到文件树逐步填充，同时底部终端显示 uv 正在安装依赖。
作为脚手架的一部分，代理创建了 pyproject.toml，新内容在编辑器中高亮展示。
脚手架完成后，在继续前花一分钟打开 app/models.py 与 app/database.py。确认 BudgetEntry 模型至少包含 id、amount、description、category 与 date 字段，且 database.py 正常设置了异步 SQLite 引擎，无异常配置。
若发现不妥，请在下一条消息中指出再继续。此阶段纠正成本很低；等到二十个文件都改过就不便宜了。
步骤 2：实现核心端点
保持 High，或者先尝试 Medium，因为 Sol 在 Medium 下即可胜任过去在 GPT-5.5 上需要 High 的多文件协作。 发送以下实现提示：
Implement endpoints for budget entries under /api/v1/entries/. Include:
- POST /api/v1/entries/ to create a new entry, returning 201
- GET /api/v1/entries/ to list all entries, with an optional ?category= filter
- DELETE /api/v1/entries/{id} to delete an entry, returning 404 if not found
Use typed Pydantic response models and dependency injection for the DB session.
After implementing, start the app and confirm the /docs endpoint loads.代理会在一次协调执行中修改 models.py、database.py、routers/entries.py 与 main.py。每个文件修改完成后，Cursor 会在编辑器中高亮新内容，便于您在接受前审阅。您会在每个已更改文件底部看到 Undo/Keep 控件。
截图展示了代理实现后的 entries.py 路由，以及其已启动服务器并成功加载 /docs 端点的确认信息。
在您接受实现并启动服务器后，打开 http://localhost:8000/docs 以确认各部分已正确连通。
FastAPI 在 /docs 的自动生成文档，显示三个端点均已正确注册。
步骤 3：添加类别校验
在第三步，您可以将推理强度降到 Low 或 Medium。添加一个枚举并写两个测试，足够自包含、可预期，无需模型额外的深度思考。
当前 API 接受任意字符串作为类别，数据很快就会不一致。我们来修正：
Budget entries should only accept these categories:
food, transport, housing, entertainment, health, other.
Reject any entry with an invalid category using a 422 status and a clear
error message. Use a Python Enum for the category type.
Add tests for both a valid category submission and an invalid one in tests/test_entries.py.代理会在 models.py 中添加类别枚举，并更新 Pydantic 模型以 使用它。由于 Pydantic 会自动基于枚举进行校验，无效类别会在路由处理器运行前被拦截。
它还应并列写两个测试：一个确认有效类别能正确保存，另一个确认无效类别会返回 422。
使用 @ 引用
接受这些更改后，试试 Cursor 的 @ 上下文功能，问一个快速校验问题：
@app/models.py Does the CategoryEnum cover all six categories I listed?在代理面板输入 @ 会打开文件选择器。一旦选择 app/models.py，该文件内容会直接被拉入提示中，代理无需搜索或猜测路径。
步骤 4：构建月度汇总端点
此处切回 High。聚合查询要求代理同时推理过滤、分组与响应模型设计，任何一处不当都意味着要再改三处。核心 CRUD 就绪后，添加汇总端点：
Add a GET /api/v1/entries/summary endpoint that accepts month (1-12) and year as query parameters.
It should return total spending per category for that month and an overall total.
Use a typed Pydantic response model.
If no entries exist for the requested month, return an empty summary with zero totals rather than a 404.这比简单查询更有意思，因为它需要带过滤与聚合。留意代理如何在 database.py 中组织查询；它应该使用 SQLModel 的查询接口而非原生 SQL，并让结果与 models.py 中定义的响应模型自然映射。
接受更改后，请在 test_entries.py 中手动写一个该端点的测试。创建某个月内的两个条目，调用该月的汇总端点，并断言总额匹配。手写这个测试有助于您熟悉测试客户端与 fixtures 的结构。
test_entries.py 展示了代理编写的类别校验测试与您手写的 test_monthly_summary 函数并列存在。
步骤 5：运行验证循环
Low 或 Medium 推理足够——运行测试与修复 Lint 问题是被动工作，代理是在阅读错误输出并进行针对性修复，而非做架构决策。将测试交还给代理：
Run pytest tests/ -v and fix any failing tests.
Do not modify test assertions to make them pass, fix the implementation instead.
Once all tests pass, run ruff check . and fix any linting issues.在代理面板中观察 pytest 的输出流。
若有失败，代理会阅读回溯、定位引入问题的文件并应用修复，全部在同一会话内完成。您无需复制错误再发新消息；调试与修复循环在一个连续线程内达成。
截图显示代理在完整验证循环后给出的反馈。本例中，ruff 检查遇到的是由本地机器 pyenv/.python-version 不匹配导致的解释器解析问题，而非代码问题。
值得注意的是：代理遇到了与我们编写代码无关的环境问题，推理其成因并在未被提示的情况下找到了解法。这类跨工具故障的情境化问题求解，正是 GPT-5.6 Sol 领先早期模型的地方。
另外，建议在每个验证提示中都包含“不要修改测试断言来让其通过”。没有这条，代理偶尔会选择阻力最小的路径，削弱测试检查力度，而不是修复实际行为。
步骤 6：代码审查
在发送此步骤前，将推理强度调回 High，或选择 Extra High/Max，让 Sol 深挖那些单次 High 可能略过的边界情况。此处浅层推理会制造虚假安全感；您需要模型真正通盘考虑潜在问题，而非仅做表层模式匹配。
在收尾前，用代理进行审查：
Review the current codebase and report on:
1. Query params or path params that are missing validation
2. Database sessions that might not be closing properly
3. Endpoints returning incorrect HTTP status codes
4. Any places where user input reaches the database without going
through the ORM
Do not make any changes yet. List each issue with file and line number.
代理发现 DELETE /api/v1/entries/{entry_id} 能正确返回 204 与 404（附 file:line 引用），GET 路由依赖正确的 200 默认值，并确认没有用户输入绕过 ORM 直接进入数据库。
审阅列表后，发送后续指令以应用修复：
Apply the fixes for the status code issues and the session handling.
Skip any rate-limiting suggestions, that's out of scope for this version.
Run the tests again after applying.步骤 7：README 与 CI 工作流
最后两笔收尾工作。两者都可以将推理强度降到 Low。README 结构可预测，CI 的 YAML 基本是样板，没有太多推理空间，在这里为高推理付费只是浪费额度。
Write a README.md with setup instructions, a table of all endpoints (method, path, description), and example curl commands for each endpoint.接着：
Create a .github/workflows/ci.yml that runs pytest and ruff on Python 3.11 for every push and pull request to main.完成七步后，项目结构如下：
结语
我们在这里构建的是一个小 API，但这套工作流程可无限扩展。
在代理接触任何文件之前，先把 AGENTS.md 准备好。任何非平凡任务都先要计划再执行。分阶段下达提示，让您拥有自然的检查点，而不是一次性审阅巨大的差异。针对具体文件想问的精准问题，用 @filename。并在收尾前做一遍审查，因为几乎总能再发现一些问题。
在 Cursor 中，GPT-5.6 Sol 比早期组合更擅长在长会话中保持专注、捕捉跨文件不一致，并在可能有破坏性的操作前选择暂停与确认。但模型只是整体的一部分。您一开始提供的上下文、过程中运行的验证循环，以及最后的审查，这些才是输出质量真正提升的来源。
关于推理级别的经验法则：在架构决策、多文件协作与非显而易见的调试中用 High；在文档、样板与单文件“代写”场景用 Medium 或 Low。在代码审查与“错误代价高于一次彻底代理执行”的场景，考虑使用 Extra High 或 Max。