开发功能
现在你已理解代码库，可以着手开发新功能了。
使用智能体开发功能的关键，是将工作拆分为智能体可自行验证的步骤。每项重要功能都应先制定方案，再设置适当的防护机制，让智能体能够发现并修复自身错误。
先制定方案
智能体可以在您开始编写代码前，帮助您梳理要构建的内容。
编写代码前，有许多决策需要考虑。如果您有一个功能想法，可能想先构建一个简单版本，之后再逐步迭代。或者，您可能需要权衡一些具体的设计决策。
您可以借助编码智能体，在编写代码前理清这些决策。使用 Cursor 的 Plan 模式，智能体会研究您的代码库、向您提出澄清性问题，并生成一份可供您编辑和调整的分步方案。
当您向 Plan 模式提交提示词时，智能体会先通过提问来明确需求：
您回答后，智能体会生成一份结构化方案，其中包含在构建功能过程中可审查和验证的里程碑。该方案可编辑，如果有任何不妥之处，您可以进行修改：
通知偏好
概述
在用户设置中添加通知偏好页面。用户可以按类别（营销、产品更新、安全警报）切换电子邮件、推送和应用内通知。偏好存储在数据库中，并采用乐观 UI 更新。
实施方法
任务
Cursor 会将较大的请求拆分为更小、可独立验证的步骤，让方案更实用。在每一步中，智能体都可以衡量进度、确认步骤是否已成功完成，然后继续下一步。
何时重新开始
有时，智能体构建出的内容并不符合预期。与其通过后续提示词尝试修复，不如回到方案。撤销更改，并在再次运行前细化方案，使其更加明确。
例如，如果遗漏了关键的架构或系统设计说明，方案可能会构建出错误的内容。从方案重新开始看似违反直觉，但往往比修补一个从一开始方向就错了的方法更快。
使用智能体进行测试驱动开发
智能体能判断自己的代码是否正确时，效果最佳。测试失败后，智能体可以了解问题所在并再次尝试。
工程师使用测试驱动开发已久，但它并非一直是最流行的编程方式。有了智能体，先编写测试变得容易得多，而且随着代码库不断扩大，这些测试的价值也会愈发明显。
- 先编写测试。 要求智能体根据预期的输入和输出编写测试。明确说明您在进行 TDD，避免它为尚不存在的代码创建模拟函数。
- 确认测试失败。 告诉智能体运行测试并验证其失败。此时并不需要编写功能代码。
- 提交测试。 当您对测试覆盖和质量感到满意后，提交测试。这会锁定需求，供智能体据此实现。
- 要求智能体编写代码。 告诉它在不修改测试的前提下让所有测试通过。不断迭代，直到全部通过。
- 提交代码。 评审输出，确认其行为符合预期，然后提交。
提交测试后，告诉智能体编写代码。明确说明它应在不修改测试的前提下让所有测试通过。
为什么这种方法如此有效？因为智能体可以运行测试、查看失败情况、调整代码，然后再次尝试。每次运行测试都会为智能体提供具体反馈。没有测试，它就无法知道自己所做的代码更改是否有效。
这种方法对后端代码尤其有价值，因为您无法通过查看屏幕来验证其正确性。您在测试中描述预期行为，智能体则编写与之匹配的代码。
在使用智能体的 TDD 工作流中，为什么应在要求智能体编写代码之前提交测试？
从设计到代码
智能体可以处理和理解图像。你可以直接将屏幕截图或设计稿粘贴到提示词输入框中，智能体会根据图像还原设计。
适用于：
- 设计稿：粘贴线框图或 Figma 导出内容，让智能体构建组件
- 视觉调试：截取非预期的 UI 状态，让智能体进行排查
- 迭代：截取当前结果的屏幕截图，并说明需要更改的内容
你还可以连接 Figma MCP 服务器，让智能体直接从你的 Figma 文件中提取设计 token、变量和组件规格。
集成浏览器可让你在智能体进行更改时预览效果。借助此浏览器，智能体可以浏览页面、截取屏幕截图并验证自己的视觉输出。这样你无需再手动将屏幕截图传回给智能体。
常见失败模式：开发时不做验证
快速开发功能时，最大的风险是跳过验证。智能体可以快速生成大量代码，但一味追求速度而不保证正确性，日后反而会增加工作量。
以下是帮助智能体验证其工作成果的具体方法：
- 验证逻辑和行为的测试
- 验证结构正确性的类型检查
- 强制执行代码风格和模式的 Linter
- 获取 UI 更改反馈的浏览器工具或 MCP 服务器
如果智能体无法验证其输出，后续你将花费更多时间进行修正。
下一步
你已完成一项功能的开发。但软件难免存在缺陷，其中有些很棘手。在下一章中，你将学习如何借助智能体，系统地发现并修复缺陷。