如何为AI智能体编写一份好的规则说明书

“我听说了很多关于为AI代理编写良好规格的内容，但还没有找到一个坚实的框架。 我可以编写一个与RFC（请求注释）相媲美的规格，但在某个时候，背景变得过大，模型就会崩溃。”

许多开发人员都有同样的挫败感。简单地将大量规格抛给AI代理是行不通的——上下文窗口限制和模型的“注意力预算”会阻碍这一过程。关键是编写智能规格：能够清晰指导代理、保持在实际上下文大小内并随着项目演进的文档。该指南从我使用编码代理（包括Claude Code和Gemini CLI）中提炼出最佳实践，并将其凝练为一个规格编写框架，该框架可以让您的AI代理保持专注和高效。

我们将涵盖五个编写优秀AI代理规格的原则，每个原则都以加粗的要点开始。

1. 从高层次的愿景开始，让AI代理草拟细节

从简洁的高层次规格开始项目，然后让AI代理将其扩展为详细计划。

与其一开始就过度设计，不如从清晰的目标陈述和几个核心要求开始。将其视为“产品简介”，让代理根据此生成更详细的规格。这利用了AI代理在扩展细节方面的优势，同时您仍然控制着方向。这种方法在您尚未对技术要求有明确的预先设想时效果良好。

为什么这种方法有效： 基于LLM（大型语言模型）的代理在给定坚实的高层次指令时擅长填充细节，但它们需要明确的使命来避免偏离轨道。通过提供简短的轮廓或目标描述并要求AI代理生成完整的规格（例如，spec.md），您为代理创建了一个持久的参考。提前规划很重要，尤其是在使用代理时——您可以在将计划交给代理编写代码之前先迭代计划。规格成为您和AI代理共同构建的第一个文档。

实用方法： 在新的编码会话中，使用以下提示开始：“您是一名AI软件工程师。为[项目X]编写详细规格，涵盖目标、功能、约束和分步计划。”保持初始提示在高层次——例如，“构建一个允许用户跟踪任务（待办事项列表）的Web应用程序，具有用户帐户、数据库和简单的UI”。代理可能会用结构化的草拟规格做出响应：概述、功能列表、技术栈建议、数据模型等。然后，这个规格成为您和代理都可以参考的“真理来源”。GitHub的AI团队推广了规格驱动开发，其中“规格成为共享的真理来源……与项目一起演进的可执行文档”。在编写任何代码之前，请查看和完善AI代理的规格。确保它符合您的愿景，并纠正任何幻觉或偏离轨道的细节。

使用计划模式强制规划： 像Claude Code这样的工具提供了计划模式，该模式限制代理仅执行只读操作——它可以分析您的代码库并创建详细计划，但在您准备好之前不会编写任何代码。这是规划阶段的理想选择：在计划模式下开始（在Claude Code中使用Shift+Tab），描述您要构建的内容，并让代理草拟规格，同时探索您的现有代码。要求它通过询问您关于计划的不明确之处来澄清不明确之处。要求它审查计划的架构、最佳实践、安全风险和测试策略。目标是完善计划，直到没有误解的余地。只有到那时，您才会退出计划模式并让代理执行。这一工作流程可以防止直接跳入代码生成而没有坚实的规格的常见陷阱。

使用规格作为上下文： 一旦批准，请保存此规格（例如，作为SPEC.md）并根据需要将相关部分输入代理。许多使用强大模型的开发人员都这样做——规格文件在会话之间保持不变，稳定AI代理的工作。当对话历史变得太长或需要重新启动代理时，这可以减轻忘记的可能性。它类似于您在团队中使用产品需求文档（PRD）的方式：一个所有人（无论是人类还是AI）都可以参考以保持在正确轨道上的参考文档。经验丰富的开发人员经常“先编写良好的文档", 模型可能能够仅从该输入中构建匹配的实现”，正如一位工程师观察到的那样。规格就是那份文档。

保持目标导向： AI代理的高层次规格应关注“是什么”和“为什么”，而不是“怎么做”（至少最初如此）。可以把它看作用户故事和验收标准：谁是用户？用户需要什么？什么是成功的样子？（例如，“用户可以添加、编辑、完成任务；数据持久保存；应用程序响应迅速且安全”）。这使得AI代理的详细规格扎根于用户需求和结果，而不仅仅是技术待办事项。正如GitHub Spec Kit文档所述，请提供您正在构建的内容的高层次描述以及为什么要构建它，并让编码代理生成详细规格，重点关注用户体验和成功标准。从这种大局愿景开始可以防止代理在后期编码时迷失方向。

2. 以专业PRD（或SRS）风格结构化规格

将您的AI规格视为结构化文档（PRD），具有清晰的部分，而不是松散的笔记集。

许多开发人员将AI代理的规格视为传统的产品需求文档（PRD）或系统设计文档——全面、组织良好、易于“字面意义上”的AI代理解析。这种正式的方法为代理提供了蓝图并减少了模糊性。

六个核心领域： GitHub对2500多个代理配置文件的分析显示，有效规格遵循明确的模式：最有效的规格涵盖六个领域。使用此清单检查完整性：

1. 命令： 将可执行命令放在前面——不仅仅是工具名称，还包括带有标志的完整命令：npm test、pytest -v、npm run build。代理将不断引用这些命令。

2. 测试： 如何运行测试、使用哪种框架、测试文件的位置以及预期的覆盖率。

3. 项目结构： 源代码的位置、测试文件的位置、文档的位置。明确指出：“src/用于应用程序代码，tests/用于单元测试，docs/用于文档”。

4. 代码样式： 一个真正的代码片段展示您的样式胜过三段描述它。包括命名约定、格式规则和良好输出的示例。

5. Git工作流： 分支命名、提交消息格式、PR要求。代理可以遵循这些规则，如果您明确说明。

6. 边界： 代理永远不应该触摸的内容——机密信息、供应商目录、生产配置、特定文件夹。 “绝不提交机密信息”是GitHub研究中最常见的有用约束。

具体说明您的技术栈： 说“使用React 18、TypeScript、Vite和Tailwind CSS”而不是“React项目”。包括版本和关键依赖项。模糊的规格会产生模糊的代码。

使用一致的格式： 清晰是关键。许多开发人员使用Markdown标题甚至类似XML的标签来划分规格的部分，因为AI模型处理结构良好的文本比自由形式的散文更好。例如，您可能会以以下格式结构化规格：

# 项目规格：我的团队任务应用程序

## 目标
- 为小团队构建一个管理任务的Web应用程序...

## 技术栈
- React 18+、TypeScript、Vite、Tailwind CSS
- Node.js/Express后端、PostgreSQL、Prisma ORM

## 命令
- 构建：`npm run build`（编译TypeScript，输出到dist/）
- 测试：`npm test`（运行Jest，必须在提交之前通过）
- 格式化：`npm run lint --fix`（自动修复ESLint错误）

## 项目结构
- `src/` – 应用程序源代码
- `tests/` – 单元测试和集成测试
- `docs/` – 文档

## 边界
- ✅ 始终：在提交之前运行测试，遵循命名约定
- ⚠️ 请先询问：数据库模式更改、添加依赖项
- 🚫 绝不：提交机密信息、编辑node_modules/、修改CI配置

这种组织水平不仅帮助您清晰思考，还帮助AI代理找到信息。Anthropic的工程师建议将提示组织成不同的部分（例如 <background>、<instructions>、<tools>、<output_format> 等），正是出于这个原因——它为模型提供了强烈的提示，告诉它哪些信息是哪些。并且请记住，“最小并不一定意味着简短”——如果某些细节很重要，请不要害怕在规格中添加它们，但要保持专注。

将规格集成到您的工具链中： 将规格视为与版本控制和CI/CD绑定的“可执行文档”。GitHub Spec Kit使用一个四阶段、有门槛的工作流程，使您的规格成为您工程过程的中心。与其编写规格然后搁置不用，不如让规格驱动实现、清单和任务分解。您的主要角色是引导；编码代理执行大部分编写工作。每个阶段都有特定的工作，您不会在当前任务完全验证之前转到下一个阶段：

1. 规范： 您提供对所构建内容的高层次描述以及为什么要构建它，编码代理生成详细规格。这不是关于技术栈或应用程序设计——它是关于用户旅程、体验和成功的样子。谁将使用它？它解决什么问题？他们将如何与它交互？可以把它看作是您要创建的用户体验地图，并让编码代理填充细节。这成为一个随着您学习更多而演进的活文档。

2. 计划： 现在您可以变得技术化。您提供所需的技术栈、架构和约束，编码代理生成综合的技术计划。如果您的公司标准化了某些技术，这就是您说明的地方。如果您正在与遗留系统集成或有合规性要求，那么所有这些都在这里。您可以要求多个计划变体来比较方法。如果您使内部文档可用，代理可以直接将您的架构模式集成到计划中。

3. 任务： 编码代理根据规格和计划将其分解为实际工作——可以独立实现和测试的小块，每个块解决问题的一个特定部分。每个任务都应该是您可以独立实现和测试的东西，几乎就像为AI代理使用测试驱动开发一样。与其说“构建身份验证”，不如说“创建一个用户注册端点，验证电子邮件格式”。

4. 实现： 您的编码代理逐一（或并行）处理任务。与其查看成千上万行代码转储，您可以查看专注的更改，这些更改解决特定的问题。代理知道要构建什么（规格）、如何构建（计划）以及要处理什么（任务）。关键是，您的角色是在每个阶段验证：规格是否捕捉到了您想要的内容？计划是否考虑了约束？AI是否错过了边缘情况？该过程建立了检查点，以便您批评、发现差距并在继续之前纠正。

这种有门槛的工作流程可以防止Willison所说的“纸牌屋代码”——脆弱的AI输出，在审查时会崩溃。Anthropic的技能系统提供了类似的模式，允许您定义可重用的基于Markdown的行为，代理可以调用。通过将您的规格嵌入这些工作流程中，您可以确保代理在规格验证之前无法继续，并且更改会自动传播到任务分解和测试中。

考虑用于专用角色的人工智能.md： 对于像GitHub Copilot这样的工具，您可以创建agents.md文件，这些文件定义了专门的代理角色——例如，@docs-agent用于技术写作，@test-agent用于QA，@security-agent用于代码审查。每个文件都作为该角色的行为、命令和边界的专用规格。这种方法在您想要为不同任务使用不同的代理，而不是一个通用代理时特别有用。

设计用于代理体验（AX）： 就像我们设计API以获得开发者体验（DX）一样，请考虑为“代理体验”设计规格。这意味着清洁、可解析的格式：API的OpenAPI模式，LLM的llms.txt文件，显式类型定义。Agentic AI Foundation（AAIF）正在标准化像MCP（模型上下文协议）这样的协议，以实现工具集成——遵循这些模式的规格更容易被代理可靠地使用和执行。

PRD与SRS思维方式： 借鉴既定的文档实践是有帮助的。对于AI代理规格，您通常会将这两者合并为一个文档（如上所示），但同时涵盖这两方面是有益的。以PRD的方式编写它可以确保您包含用户中心的上下文（“每个功能背后的原因”），以便AI代理不会优化错误的东西。以SRS的方式扩展它可以确保您确定AI代理实际生成正确代码所需的具体细节（例如，使用哪个数据库或API）。开发人员发现，这种额外的前期工作通过大大减少与代理的后期误解来获得回报。

使规格成为“活文档”： 不要写完就忘记。更新规格，因为您和代理做出决定或发现新信息。如果代理需要更改数据模型，或者您决定删除功能，请在规格中反映这一点，以便规格保持为真理来源。将其视为版本控制文档。在规格驱动工作流程中，规格驱动实现、测试和任务分解，您不会在规格验证之前转到编码阶段。这种习惯使项目保持一致，尤其是当您或代理稍后离开并返回时。请记住，规格不仅是为AI代理——它还帮助您作为开发人员保持监督并确保AI代理的工作符合实际要求。

3. 将任务分解为模块化提示和上下文，而不是一个大提示

将任务分解为更小的部分：一次给AI代理一个专注的任务，而不是一个包含所有内容的大提示。

经验丰富的AI工程师已经学会，试图将整个项目（所有要求、所有代码、所有指令）塞入一个单一的提示或代理消息，是一个灾难的根源。不仅您冒着达到令牌限制的风险，而且您还冒着模型因“指令诅咒”而失去焦点的风险——太多指令导致它无法很好地遵循任何一条指令。解决方案是以模块化的方式设计您的规格和工作流程，一次处理一个部分，并且只提供该部分所需的上下文。

过多上下文/指令的诅咒： 研究已经证实了许多开发人员的经历：随着您将更多指令或数据堆积到提示中，模型在遵循每个指令方面的性能会显著下降。 一项研究将其称为“指令诅咒”，并表明，即使是GPT-4和Claude，也会在被要求同时满足多个要求时挣扎。 在实践中，如果您提供10个详细规则的要点，AI代理可能会遵循前几个规则，但开始忽略其他规则。 更好的策略是迭代关注。 行业指南建议将复杂要求分解为顺序的简单指令作为最佳实践。 将AI代理的注意力集中在一个子问题上，完成后再转到下一个问题。 这可以保持质量高和错误可控。

将规格分解为阶段或组件： 如果您的规格文档很长或涵盖了很多内容，请考虑将其分成部分（要么是物理上独立的文件，要么是明确独立的部分）。例如，您可能有一个“后端API规格”部分和一个“前端UI规格”部分。您不需要在代理处理后端时总是将前端规格提供给它，反之亦然。许多使用多代理设置的开发人员甚至为每个部分创建单独的代理或子过程——例如，一个代理处理数据库/模式，另一个代理处理API逻辑，另一个代理处理前端——每个代理都有相关的规格部分。即使您使用单个代理，您也可以通过复制相关规格部分到提示中来模拟这种行为。避免上下文过载：不要将身份验证任务与数据库模式更改混合在一起，因为DigitalOcean AI指南警告说这样做会导致混乱。将每个提示的范围限定在当前目标。

大规格的扩展TOC/摘要： 一个巧妙的技巧是让代理为规格构建一个带有摘要的扩展表格。它本质上是一个“规格摘要”，该摘要将每个部分浓缩为几个关键点或关键词，并引用详细信息的位置。例如，如果您的完整规格有一个关于“安全要求”的部分，跨越500个字，您可能会让代理将其总结为：“安全：使用HTTPS，保护API密钥，实施输入验证（见完整规格§4.2）”。通过在规划阶段创建一个分层摘要，您可以获得一个鸟瞰图，该图可以保持在提示中，而细节可以在需要时提取。该扩展TOC充当索引：代理可以参考它并说“啊，有一个安全部分我应该查看”，然后您可以提供该部分以供参考。这类似于人类开发人员在处理特定部分时浏览大纲然后翻到规格文档的相关页面。

要实现这一点，您可以在编写规格后提示代理：“总结上述规格为一个非常简洁的概要，包括每个部分的关键点和一个引用标签。”结果可能是一个带有简要摘要的部分列表。该摘要可以保留在系统或助手消息中，以指导代理的关注点，而不会占用太多令牌。这种分层摘要方法已被证明可以帮助LLM维持长期上下文，方法是关注高层次结构。代理带有一个关于规格的“精神地图”。

利用子代理或“技能”处理不同规格部分： 另一种高级方法是使用多个专门的代理（Anthropic称之为子代理或您可能称之为“技能”）。每个子代理针对特定领域进行配置，并提供该领域相关的规格部分。例如，您可能有一个数据库设计子代理，它只知道规格的数据模型部分，或者有一个API编码子代理，它知道API端点规格。主代理（或编排器）可以自动将任务路由到适合的子代理。这种方法的好处是每个代理都有一个较小的上下文窗口来处理，并且有一个更集中的角色，这可以提高准确性并允许在独立任务上进行并行工作。Anthropic的Claude Code支持此功能，允许您定义具有自己系统提示和工具的子代理。“每个子代理都有特定的目的和专业领域，使用自己的上下文窗口与主对话分开，并且有一个自定义的系统提示来指导其行为”，正如他们的文档所述。当出现与子代理领域匹配的任务时，Claude可以将该任务委托给它，子代理独立返回结果。

并行代理以提高吞吐量： 并行运行多个代理的方法正在成为开发人员生产力的“下一个大事”。与其等待一个代理完成然后再开始另一个任务，不如同时启动多个代理来处理不重叠的工作。Willison将其描述为“接受并行编码代理”，并指出“这令人惊讶地有效，但在精神上却很耗费”。关键是将任务范围限定在代理不会相互干扰的范围内——一个代理编码一个功能，而另一个代理编写测试，或者独立组件同时构建。或者，编排框架如LangGraph或OpenAI Swarm可以帮助协调这些代理，而共享内存（如向量数据库Chroma）允许它们访问共同的上下文，而无需冗余的提示。

单代理与多代理：何时使用每种

方面	单代理	并行/多代理
优点	设置更简单；开销更低；更容易调试和跟踪	更高的吞吐量；处理复杂的相互依赖；每个领域都有专家
挑战	大项目上下文过载；迭代更慢；单点故障	协调开销；潜在冲突；需要共享内存（例如，向量数据库）
最佳适用场景	隔离的模块；小型至中型项目；早期原型设计	大型代码库；编码+测试+审查；独立功能
提示	使用规格摘要；刷新每个任务的上下文；经常启动新会话	最初限制为2-3个代理；使用MCP进行工具共享；定义明确的边界

在实践中，使用子代理或特定于技能的提示可能类似于：您维护多个规格文件（或提示模板）——例如，SPEC_backend.md、SPEC_frontend.md——并且您告诉AI代理，“对于后端任务，请参考SPEC_backend；对于前端任务，请参考SPEC_frontend”。或者，在像Cursor/Claude这样的工具中，您实际上为每个部分启动一个子代理。这当然比单代理循环更复杂，但它模仿了人类开发人员的做法——我们在脑海中将大规格分解为相关的部分（您不会同时在脑海中记住整个50页规格；您会回忆您需要的部分来处理任务，并且对整体架构有一个大致的了解）。挑战，如前所述，是管理相互依赖性：子代理仍然必须协调（前端需要知道后端规格中的API契约等）。一个中心概述（或“架构师”代理）可以通过引用子规格并确保一致性来提供帮助。

专注于每个提示的一个任务/部分： 即使没有花哨的多代理设置，您也可以手动强制模块化。例如，在编写规格后，您的下一步可能是：“步骤1：实现数据库模式。”您只提供规格的数据库部分以及规格中的任何全局约束（例如，技术栈）。代理处理该任务。然后，对于步骤2，“现在实现身份验证功能”，您提供规格的身份验证部分以及可能需要的相关模式部分。通过刷新每个主要任务的上下文，您可以确保模型不会携带大量过时或不相关的信息，这些信息可能会分散它的注意力。正如一份指南所建议的：“从头开始：开始新会话以清除上下文，当切换到主要功能时”。您可以随时提醒代理关键的全局规则（来自规格的约束部分），但不要在不需要时将整个规格塞入其中。

使用内联指令和代码TODO： 另一个模块化技巧是将您的代码或规格用作对话的积极部分。例如，使用// TODO注释来描述需要完成的内容，并让代理一一填充这些注释。每个TODO本质上都是小任务的微型规格。它可以让AI代理保持高度专注（“根据此规格片段实现此特定函数”），您可以在紧密的循环中迭代。

总而言之，小而集中的上下文优于一个巨大的提示。这种方法可以提高质量，并防止AI代理因同时处理太多信息而感到不知所措。通过将规格分解为模块，并使用诸如规格摘要或子规格代理等策略，您可以绕过上下文大小限制和AI代理的短期内存限制。请记住，一个精心设计的AI代理就像一个精心设计的函数一样：只提供它需要的输入来完成工作。

4. 构建自我检查、约束和人类专业知识

让您的规格不仅成为代理的待办事项清单，也成为质量控制的指南——并且不要害怕注入自己的专业知识。

一个好的AI代理规格预测了AI代理可能出错的地方，并设置了防护栏。它还利用了您所知道的内容（领域知识、边缘情况、“陷阱”），以便AI代理不会在真空中运行。可以把规格看作是AI代理的教练和裁判：它应该鼓励正确的方法并指出错误。

使用三层边界： GitHub对2500多个代理文件的分析发现，有效的规格使用三层边界系统，而不是简单的不允许列表。这种方法为代理提供了更明确的指导，告诉它何时继续、暂停和停止：

✅ 始终执行： 代理无需询问即可执行的操作。“始终在提交之前运行测试。”“始终遵循样式指南中的命名约定。”“始终将错误记录到监控服务中。”

⚠️ 请先询问： 需要人类批准的操作。“在修改数据库模式之前请先询问。”“在添加新依赖项之前请先询问。”“在更改CI/CD配置之前请先询问。”这一层可以捕捉到可能没问题但需要人类检查的高影响力更改。

🚫 绝不执行： 硬性限制。“绝不提交机密信息或API密钥。”“绝不编辑node_modules/或vendor/。”“绝不删除失败的测试，除非有明确的批准。”“绝不提交机密信息”是研究中最常见的有用约束。

这种三层方法比平面的规则列表更细致。它承认某些操作始终是安全的，某些操作需要监督，而某些操作是绝对禁止的。代理可以自信地执行“始终”操作，对“请先询问”操作提出疑问，并对“绝不”操作进行硬性停止。

鼓励自我验证： 一个强大的模式是让代理自动验证其工作成果与规格。 如果您的工具允许，您可以集成代理在生成代码后可以运行的检查，例如单元测试或格式化。 但是，即使在规格/提示级别，您也可以指示代理自我检查：例如，“在实现后，将结果与规格进行比较，并确认所有要求都已满足。 列出任何未解决的规格项。” 这会促使LLM反思其输出与规格的关系，从而捕捉到遗漏。 这是一种内置于流程中的自我审计。

例如，您可能会在提示中追加：“（在编写函数后，查看上述要求列表并确保每个要求都得到满足，标记任何缺失的项）。”模型然后理想地输出代码，后面跟着一个简短的清单，指示它是否满足每个要求。这种方法可以减少模型在您甚至运行测试之前忘记某些东西的可能性。它不是万无一失的，但它有帮助。

LLM作为法官用于主观检查： 对于难以自动测试的标准（例如代码样式、可读性、遵循架构模式），请考虑使用“LLM作为法官”。这意味着让第二个代理（或单独的提示）根据您的规格的质量指南审查第一个代理的输出。Anthropic和其他公司发现这种方法很有效。您可能会提示：“审查此代码以确保其符合我们的样式指南。标记任何违规行为。”审查代理返回反馈，这些反馈可以被纳入或触发修订。这种语义评估层超出了语法检查。

一致性测试： Willison提倡构建一致性套件——语言无关的测试（通常基于YAML），任何实现都必须通过这些测试。这些测试充当合同：如果您正在构建API，一致性套件指定预期的输入/输出，并且代理的代码必须满足所有情况。这种方法比临时的单元测试更严格，因为它直接来自规格，可以在实现之间重用。在规格的成功标准部分，您可能会说“必须通过conformance/api-tests.yaml中的所有情况”。包括一致性标准在您的规格中，并让代理运行它们。

利用规格中的测试： 如果可能，请在您的规格和提示流程中包含测试计划或实际测试。与传统开发一样，我们使用TDD或编写测试用例来阐明要求——您可以对AI代理做同样的事情。例如，在规格的成功标准部分，您可能会说“这些示例输入应该产生这些输出...”或“以下单元测试应该通过”。代理可以被提示在脑海中运行这些案例，或者如果它有能力的话，实际执行它们。Simon Willison指出，拥有一个健全的测试套件就像给代理超能力一样——它可以快速验证和迭代，当测试失败时。与AI编码上下文类似，在规格中为测试或预期结果编写一些伪代码可以指导代理的实现。此外，您可以使用专用的“测试代理”在子代理设置中，该代理接受规格的标准并不断验证“代码代理”的输出。

注入领域知识： 您的规格应该反映出只有经验丰富的开发人员或具有上下文的人才能知道的见解。例如，如果您正在构建一个电子商务代理，并且您知道“产品”和“类别”之间存在多对多的关系，请明确说明（不要假设AI代理会推断出来——它可能不会）。如果某个库特别棘手，请提及要避免的陷阱。基本上，将您的指导融入规格中。规格可以包含诸如“如果使用库X，请注意版本Y中的内存泄漏问题（应用修复Z）”的建议。这种细节水平可以将普通的AI输出转化为真正强大的解决方案，因为您已经引导AI代理避免了常见的陷阱。

此外，如果您有偏好或样式指南（例如，“在React中使用函数组件而不是类组件”），请在规格中编码这些指南。然后，AI代理将模仿您的样式。许多工程师甚至在规格中包含小示例，例如：“所有API响应都应为JSON。例如，{"error": "message"}用于错误。”通过提供快速示例，您可以将AI代理固定在您想要的确切格式上。

简单任务的极简主义： 虽然我们提倡全面规格，但专业知识的关键部分是知道何时保持简单。对于相对简单、独立的任务，过于庞大的规格实际上可能会造成更多的混乱而不是帮助。例如，如果您要求代理执行简单的任务（例如“将div居中在页面上”），您可能只需要说“确保解决方案简洁，不要添加不必要的标记或样式”。在这种情况下不需要完整的PRD。相反，对于复杂任务（例如“实现具有令牌刷新和错误处理的OAuth流程”），这就是您需要详细规格的时候。一个好的经验法则是：根据任务的复杂性调整规格的详细程度。不要为简单的问题编写过于复杂的规格，也不要为困难的问题编写过于简单的规格。

保持AI代理的“人格”（如果需要）： 有时，您的规格的一部分是定义AI代理应该如何表现或响应，特别是当代理与用户交互时。例如，如果您正在构建客户支持代理，您的规格可能包括诸如“使用友好和专业的语气”或“如果您不知道答案，请询问澄清或提出跟进，而不是猜测”等指南。这些规则（通常包含在系统提示中）有助于保持AI代理的