夜雨聆风
如何为 AI 编程智能体编写 PRD
当 GitHub 工程团队在 9 月宣布“规范（Specification）将成为事实来源并决定构建内容”时，他们预示了一场重新定义产品经理（PM）产出物的范式转移。传统的产品需求文档（PRD）是人类之间的协作产物：一种经过协商的共同理解，由软件工程师进行解读、质疑并转化为代码。然而，AI 编程智能体需要的规范必须能作为编程接口运行。这些规范需要足够精确以供执行，结构清晰以供排序，约束严密以防止范围蔓延，同时还要支持 AI 独立探索最佳实现路径。
完善 AI 智能体开发的 PRD 至关重要。根据 Stack Overflow 2025 年开发者调查，84% 的开发者正在或计划在开发流程中使用 AI 工具，其中 51% 每天都在使用。2025 年企业在代码生成 AI 上的支出达到 40 亿美元，占部门 AI 总支出的 55%，同比增长 4.1 倍。GitHub 报告称，90% 的财富 100 强企业已采用智能体化编程，AI 现在编写了开发者约一半的代码。然而，普及并不等同于满意。同一份调查发现，三分之二的开发者对“几乎正确但又不完全正确”的 AI 解决方案感到沮丧。这种大规模普及与普遍沮丧并存的悖论，指向的是规范问题而非能力问题。AI 编程智能体已变得异常强大，但往往缺乏精确的指令和相关的上下文。
Andrew Ng 在 2025 年 7 月的 Y Combinator AI 创业学校观察到：“我看到这种比例正在发生变化。我有生以来第一次看到管理者提议 PM 的人数是工程师的两倍。我认为这是世界走向的一个信号。”编写 PRD 等核心 PM 实践需求依然旺盛，但需要转化为 AI 编程智能体能够可靠执行的格式。在这里，我总结了目前在 AI 智能体软件开发 PRD 方面学到的经验。
新的规范范式：发生了哪些变化
从单体文档转向阶段性开发
传统 PRD 侧重于人类理解、利益相关者对齐和文档化。它们通常整体性地呈现功能，让工程师在深入定义实现细节之前掌握完整愿景。相比之下，AI 编程智能体在具有依赖顺序、可测试的阶段任务中表现更好，这些阶段在构建上层功能之前会先明确基础。
2025 年 7 月发布的 METR 开发者生产力研究发现，经验丰富的开发者在自己的代码库中使用 AI 工具时速度反而变慢了。研究人员将其归因于几个因素：花费在提示和等待 AI 响应上的时间、审查和纠正 AI 生成代码的精力，以及在编码和 AI 交互之间切换的认知开销。作为 PM，这向我暗示了规范的结构化方式和向 LLM 交付上下文的方式，对开发者生产力、开发者体验（DX）以及生成的 AI 代码质量起着至关重要的作用。
各大 AI 平台已经出现了一种四阶段模式：
明确规范 (Specify) → 制定计划 (Plan) → 分解任务 (Tasks) → 执行实现 (Implement)
GitHub 在 2025 年 9 月发布的开源 Spec Kit 框架正式化了这一流程。GitHub 工程团队写道：“我们正在从‘代码是事实来源’转向‘意图是事实来源’。有了 AI，规范就成了事实来源，并决定了构建的内容。”
以一个实际例子来看其中的差异。传统 PRD 可能会这样规定：
“系统必须允许用户上传、组织和播放音频文件，并具备实时频率可视化和播放列表管理功能。”
针对 AI 优化的规范会将此重构为序列化的阶段：
阶段 1：数据库模式和存储配置
阶段 2：音频上传和库管理 API
阶段 3：带传输控制的播放引擎
阶段 4：可视化集成
阶段 5：播放列表管理
阶段 6：UI 润色和错误处理
每个阶段都有明确的依赖关系（阶段 4 需要阶段 3 的音频上下文）、可测试的结果（阶段 2 以工作的上传端点结束）以及受限的范围（阶段 6 不修改数据库模式）。智能体完成一个阶段，我作为 PM 验证结果，然后才提示开始下一个阶段。
阶段大小遵循一个实用的启发式方法：截至 2026 年初，像使用 Opus 4.5 的 Claude 这样前沿的 LLM 系统已经足够强大，每个阶段应代表智能体 5-15 分钟的工作量，并以 PM 可以手动验证的功能结束。过大的阶段仍会引入过多变量和依赖，难以调试；过小的阶段则会产生不必要的交接开销和上下文切换效率低下。
规范编写前的调研
平台能力的变化速度超过了 LLM 的预训练及其依赖的语料库。2026 年 1 月在 2025 年预训练的 LLM 帮助下为 Replit Agent 编写的规范，很可能会引用已弃用的服务、失去支持的框架，或者新版智能体处理方式不同的 API 规范。Claude Code 的官方工作流通过 Explore-Plan-Code-Commit 模式解决了这个问题。第一步指令要求用户“让 Claude 阅读相关文件、图像和 URL”并进行在线调研，明确规定此时不要编写代码。只有在调研阶段结束后才开始实现。同样，JetBrains 为其 Junie AI 助手编写的文档也明确要求调研阶段：“让 AI 智能体阅读你的 requirements.md 文件并创建一个详细的实现计划……你不是在要求它开始编码，而是要求它先思考。”
为什么这对 AI 编程智能体如此重要？人类开发者可以在中途调试配置失败，意识到外部服务需要不同的身份验证，或者包版本引入了破坏性更改。AI 智能体目前缺乏这种自适应调试和调研能力。它们按书面规范执行，不完整的调研可能会演变成实现失败。此外，如前所述，用于编写 PRD 的 LLM 存在知识截止日期，经常引用过时的文档。因此，预先根据用户引导的在线调研来锚定和更新模型可用的信息至关重要。
任何平台的实用调研清单包括：
1. 验证当前 API 文档和身份验证要求。
2. 检查所选框架或库中的破坏性更改。
3. 确认平台原生服务的可用性（例如 Replit 数据库 vs 外部 PostgreSQL）。
4. 识别所需的各种环境变量和秘密密钥。
可测试的检查点与回滚策略
Replit 的检查点系统体现了智能体开发的最佳实践。他们的文档将检查点描述为“像视频游戏中的存档点一样的完整快照”，同时捕获代码更改、工作区内容、AI 对话上下文和连接的数据库。当智能体引入回归错误时（这种情况确实会发生），PM 或工程师可以恢复到已知的良好状态，而不是尝试调试他们可能并不完全理解的 AI 生成代码。与仅跟踪代码更改的传统 Git 提交不同，Replit 检查点保留了整个开发上下文，包括生成该代码的 AI 对话状态。
CodeRabbit 在 2025 年 12 月发布的《AI 与人类代码生成现状》报告发现，AI 生成的拉取请求（PR）包含的问题大约是人类编写 PR 的 1.7 倍，其中逻辑和正确性问题增加了 75%，安全漏洞高出 1.5-2 倍。这一发现强调了调研充分的规范和检查点纪律的重要性。
“无死角”原则自然随之而来：每个阶段必须让代码库处于可运行状态。半实现的功能、注释掉的代码块或占位符函数会给后续阶段带来歧义。智能体无法区分不完整的代码是代表正在进行的工作还是刻意的脚手架。因此，规范必须将每个阶段定义为一个完整的单元，并带有明确的验证标准。
保护模式：约束 AI 的作用域
从业者总结出的一个反直觉经验是：必须设定明确的约束。AI 编程智能体经过海量代码库训练并以“乐于助人”为优化目标，会尝试完成训练暗示的未说明需求。如果不加约束，它们可能会将工作的代码“改进”为损坏的代码，将稳定的模式重构为新颖的架构，并将范围扩展到规范意图之外。
因此，“请勿更改 (DO NOT CHANGE)”模式已成为关键的保障措施。领先的从业者建议“在添加新功能时，明确说明哪些内容不应更改”。现在的规范通常包含明确的保护部分：
### 保护模式
-**请勿更改**现有的身份验证中间件。
-**请勿修改** `db/schema.ts` 中的数据库模式。
-**保持**当前的 Tailwind 配置和设计令牌。
-**不要重构** `utils/legacy_parser.js`，即使它触发了 lint 警告。
这种模式承认 AI 智能体缺乏上下文判断力，无法始终区分“这段代码可以更好”和“这段代码必须保持稳定”。人类工程师通过组织知识、代码审查规范和风险评估来做出这种区分。2026 年初的 AI 智能体则受益于更明确的指令。
在 AI 编程智能体规范中，非目标（Non-goals）变得更加关键。传统 PRD 通常通过省略来暗示范围边界，但 AI 无法从省略中推断。如果规范没有明确说明“在此阶段不要实现用户身份验证”，智能体可能会理所当然地添加身份验证，因为大多数 Web 应用程序都需要它。因此，每个边界都必须正面陈述。
HumanLayer 在 2025 年的研究表明，前沿 LLM 在性能下降前可以保持一致地遵循大约 150-200 条指令。这为规范长度设定了一个实际的（尽管是暂时的）上限，并强化了分阶段方法的价值。与其编写一个包含 300 条要求的大型规范，不如将工作结构化为 5-6 个阶段，每个阶段包含 30-50 条要求。
经久不衰的实践：保持不变的内容
OpenAI 产品负责人 Miqdad Jaffer 在 2025 年 8 月强调：“过去构成一份优秀 PRD 的要素现在依然有效：对变化的假设、它如何契合整体战略、是全量推送还是 A/B 测试、什么是通过指标、什么是非目标。”
用户需求与战略对齐
AI 智能体本质上并不理解它们所创建软件的用户。它们可以编写实现登录表单的代码，但无法评估该表单是否会产生降低转化率的摩擦。待办任务（Jobs-to-be-done）、共情地图、用户旅程地图、痛点识别……所有这些框架在 PM 领域依然至关重要。改变的是这些理解如何被编码进规范中。
战略对齐的重要性同样持久。我们为什么要构建这个？它如何连接到更广泛的组织目标？我们考虑过哪些替代方案？独特的价值差异化和护城河是什么？我们如何创造、交付和捕获价值？所有这些上下文对于业务成功仍然至关重要，必须与利益相关者讨论，即使实现规范已演变为针对 AI 消费优化的格式。因此，现在的 PRD 服务于双重受众：人类（用于对齐和决策）和 AI 智能体（用于实现）。战略叙述可以保留在散文和幻灯片中，而实现规范必须变得更加结构化。
验收标准——为机器翻译
验收标准依然存在，但必须变得可供机器验证。请看这种转化：
表 1 | 验收标准从人类可解读格式到机器可验证格式的转化。传统标准依赖专业判断和上下文解读；针对 AI 优化的标准则规定了量化阈值、明确行为和可测试条件。
第一列代表有效的人类验收标准——工程师可以通过专业判断和用户测试来解读“容易”、“快速”和“直观”。AI 智能体本质上无法做到这一点。它们需要量化的阈值、具体的行为，以及在它们的环境、工具调用能力和上下文窗口内可测试的条件。
增加 AI 特定内容的成功指标
量化结果依然是产品成功的北极星。对于包含机器学习（ML）和 AI 的产品，变化在于增加了传统 PRD 不需要考虑的 AI 特定指标。Jaffer 的 AI PRD 模板包含了诸如“AI 必须在 10,000 个标记查询中达到 ≥90% 的准确率，将幻觉率限制在 <2%”之类的要求。
对于包含 AI 功能的特性，规范现在必须解决：
– 针对标记数据集的准确率目标
– 幻觉率限制
– 负载下的延迟要求
– 偏见审计标准
– AI 组件失效时的优雅降级
这些指标需要持续监控，因为模型会随时间漂移，检索系统或数据管道的上游更改可能会悄无声息地降低性能。即使是由 AI 智能体实现的特性（而非包含 AI 功能），成功指标也应包括代码质量衡量标准：测试覆盖率阈值、lint 合规性、文档完整性和性能基准。
平台特性：实用对比
尽管表面上存在差异，主要的 AI 编程平台在规范理念上正在趋同。每个平台都维护一个配置文件，为 AI 智能体提供持久的项目上下文，并且每个平台都执行某种版本的“先计划后构建”工作流。然而，实现细节对于有效编写规范至关重要。
表 2 | 主要 AI 编程平台的配置文件概览（截至 2026 年 1 月）。尽管命名约定和存储位置各异，所有平台都维护持久的项目上下文文件。2025 年底由 Google、OpenAI 等联合推出的 AGENTS.md 格式代表了一种新兴的跨平台标准。
2025 年底出现了一项重大的标准化努力，Google、OpenAI、Factory、Sourcegraph 和 Cursor 联合推出了 AGENTS.md 开放标准，这是一种供应商中立的 Markdown 文件，旨在取代碎片化的工具特定格式。GitHub 对 2,500 多个代码库的分析确定了有效规范文件必须解决的 6 个核心领域：带标志的命令、测试预期、项目结构、带示例的代码风格、Git 工作流和明确的边界。
Replit Agent：计划-构建范式
Replit 的实现提供了战略计划与实现执行之间最清晰的分离。计划模式 (Plan Mode) 允许在不修改任何代码的情况下讨论架构、技术选择和需求澄清。智能体提出方法、询问澄清问题并建立理解，这一切都发生在任何文件更改之前。计划模式不产生费用，从而激励了彻底的前期规范编写。
当开发者选择“开始构建”时，构建模式 (Build Mode) 激活。智能体现在修改代码，并在重大更改后自动创建检查点。社区最佳实践强调提示一个功能，测试它，然后添加下一个。“这比一次性请求所有功能更便宜且更不容易出错。”
Replit 的文档还证实了优先选择原生服务而非外部集成的原则。Replit Database (PostgreSQL) 和 Replit App Storage 被明确推荐为首选方案，具备自动备份和简化配置的优势。AWS S3 等外部服务或第三方数据库会引入智能体处理起来不太可靠的配置复杂性。
一份实用的 Replit 规范遵循以下结构：
### 战略目标
[描述“为什么”和业务价值]
### 调研任务
-搜索最新的 [库名] 文档。
-验证 Replit 部署令牌的兼容性。
### 实施阶段
-阶段 1: [详细步骤]
-阶段 2: [详细步骤]
在智能体确认理解后，后续提示遵循构建模板：
现在开始构建阶段 [X]。
-遵循 AGENTS.md 中的编码标准。
-完成后运行 `npm test`。
-如果测试通过，请创建一个检查点。
Claude Code：Skills 与渐进式披露
Claude Code 通过 CLAUDE.md 文件和 Agent Skills 框架来处理规范。CLAUDE.md 文件提供每次会话都会加载的项目上下文——编码规范、目录结构、常用命令和工作流偏好。最佳实践建议将此文件保持在 500 行以内以保证上下文效率。
更具特色的功能是 Agent Skills：Claude 在相关时可以调用的可复用程序性知识包。与静态配置不同，Skills 教会 Claude 如何处理特定类型的任务。例如，一个用于生成 Replit PRD 的 Skill 会编码“先调研后规范”的工作流、阶段结构、模板格式以及针对项目中期变化的适应模式。
Skills 使用渐进式披露设计。启动时仅加载极少的元数据，大约 100 个 token 描述 Skill 的适用场景。只有当 Claude 确定相关性时，才会加载完整的指令和支持文件。这在需要深度程序性知识时保持了上下文窗口的高效。
Skills 与 MCP（模型上下文协议）的关系阐明了一个有用的心理模型：“MCP 提供工具；Skills 教会如何使用它们。”MCP 实现了与数据库、API 和文件系统等外部系统的安全连接。Skills 则编码了在特定上下文中有效使用这些连接的程序性知识。
Claude Code 还引入了用于扩展推理的“think”关键字层级：
– “think” —— 标准反思
– “think hard” —— 更深层的分析
– “think harder” —— 扩展思考
– “ultrathink” —— 最大推理深度
对于需要架构决策的复杂规范，指示 Claude 在提出任何建议之前对数据库模式进行“ultrathink”，会比直接进入实现产出更深思熟虑的结果。
Cursor：规则与 Composer 模式
Cursor 通过 .cursorrules 文件和规则目录来构建项目上下文。规则可以使用 glob 模式限定范围，从而为不同的文件类型提供不同的指导。匹配 *.test.ts 的规则可以规定测试规范，而匹配 src/components/*.tsx 的规则可以规定组件模式。
Composer 模式通过明确的“计划-批评-执行”模式实现多文件编辑。智能体提出跨多个文件的更改，提交计划供审查，并在批准后才执行。对于大型重构任务，Cursor 2.0 最近引入了并行运行多达 8 个智能体的能力，每个智能体在隔离的工作树中工作以防止冲突。
.cursorrules 文件通常包括：
– 技术栈和版本约束
– 带有具体示例的编码风格
– 测试要求和模式
– 文件组织规范
– 要避免的常见陷阱
OpenAI Codex：AGENTS.md 标准
OpenAI Codex 支持新兴的 AGENTS.md 标准，这是一种旨在跨工具移植的跨平台规范文件。GPT-5-Codex 提示指南强调让模型在受限规范内处理计划，并明确指示“避免过于详细的提示”，以免限制智能体寻找最佳解决方案的能力。
Codex Artifacts 代表智能体在执行前计划的任务序列，提供了一个类似于 Replit 计划模式的审查点，但它集成在执行流中而非作为独立模式分离。
Google Antigravity：任务控制与任务 Artifacts
Google 最近推出的 Antigravity 智能体编程平台引入了 Mission Control，用于在复杂项目中编排多个智能体。Antigravity 不是由单个智能体执行序列化阶段，而是可以派遣多个智能体并行处理独立任务，然后协调它们的产出。Planning Mode 在生成任何代码之前产出任务 Artifacts 和实现计划。每个智能体在隔离的工作树中工作以防止冲突。来自多个智能体的相关更改被分组为逻辑提交。
对于具有大量可并行工作量的企业级项目，Antigravity 的方法可能提供效率提升，但需要更复杂的规范来定义任务边界和集成点。
Lovable：设计驱动的规范
Lovable 强调“设计到代码”的工作流，视觉规范与功能要求并行。组件库引用、设计系统令牌和布局规范直接集成到智能体的上下文中。
该平台针对视觉保真度至关重要的应用进行了优化，例如需要给投资者留下深刻印象的 MVP、品牌表达至关重要的消费产品，或具有强设计协作的项目。功能规范通常包括上传设计文件（如通过 Figma），并遵循与其他平台类似的模式，但特别关注设计系统的合规性和视觉一致性。
构建可复用的 Skills：Anthropic 框架
好消息是，产品经理可以轻松地将编写 AI 智能体编程 PRD 的最佳实践编码为可复用的 Skills，供 Claude 及其他采用该标准的智能体自动调用。Anthropic 的 Agent Skills 框架提供了一种系统化的方法来打包这些工作流。Skills 充当 AI 智能体的程序性知识包。如果说 CLAUDE.md 等配置文件提供的是上下文（关于项目的事实），那么 Skills 提供的是过程（如何处理特定任务）。因此，一个用于编写 PRD 的 Skill 不仅仅描述一份好的 PRD 包含什么，它还会引导智能体完成调研、澄清、排序和交付阶段。
Skills 框架已获得快速普及。Microsoft、OpenAI、Atlassian、Figma、Stripe、Notion 等都已采用 Agent Skills 标准。SkillsMP 等社区市场现在托管了超过 25,000 个 Skills，形成了一个不断增长的可复用程序性知识生态系统。
Skill 的结构与剖析
一个 Skill 仅仅是一个包含 SKILL.md 文件的目录，该文件带有 YAML 前置内容和 Markdown 指令：
name:replit-prd-generator
description:用于为 Replit Agent 创建分阶段、调研驱动的 PRD。
version:1.0.0
SKILL.md 文件遵循以下结构：
# Replit PRD 生成器 Skill
## 激活触发器
当用户要求“为 Replit 编写 PRD”或提到“Vibe Coding”时激活。
## 工作流步骤
1. 调研：使用 MCP 搜索工具验证当前的库版本。
2. 澄清：询问 3-5 个关于数据持久性和 UI 偏好的关键问题。
3. 排序：将需求分解为 5-15 分钟的阶段。
4. 交付：输出符合 AGENTS.md 标准的规范。
前置内容的描述字段对于激活至关重要。应包含用户可能自然说出的触发词：“用 Replit 构建”、“Replit Agent”、“Vibe Coding”、“Replit 的 PRD”。Claude 会将这些词与用户请求匹配以确定 Skill 的相关性。
Skills 的存储位置
Skills 可以存储在多个维度：
表 3 | Agent Skills 存储位置及其对应范围。存储在个人范围的 Skills 仅供个人用户使用；项目范围的 Skills 随代码库进行版本控制；组织范围的 Skills 适用于 Claude.ai 团队或企业账户下的所有项目。
建议从个人 Skills 开始实验。当某个 Skill 证明有价值时，将其提升到项目范围供团队采用。企业团队可以部署组织范围的 Skills，使所有项目的工作流标准化。
实例：Replit PRD Skill
replit-prd Skill 在实践中展示了这些原则。其 SKILL.md 文件确立了工作流：
1. 调研：检查 Replit 部署目标和数据库限制。
2. 计划：定义 5-8 个功能阶段。
3. 保护：识别不应更改的核心文件。
4. 验证：为每个阶段定义可测试的检查点。
参考文件提供了详细的模板、调研清单和适应模式。Skill 仅在需要时加载这些内容，保持初始上下文开销最小。
创建你自己的 PRD Skill
我鼓励你使用 Claude Opus 4.5 为你的场景构建一个 Skill。Claude 系统会自动利用“Skill 构建 Skill”来生成 .zip 格式的包。以下是我建议的步骤：
- 识别模式：你在不同项目中重复哪些规范工作流？你总是问哪些问题？什么样的结构适合你的领域？
- 记录调研阶段：在编写规范之前必须验证什么？平台能力、技术兼容性、组织约束？
- 定义阶段：典型项目的依赖顺序是什么？在开发功能之前必须存在哪些基础？
- 创建模板：什么样的结构适合你的智能体和团队？包含优秀规范的示例。
- 添加适应模式：你想如何处理项目中的变更？你使用哪些保护模式？
- 测试与迭代：在实际项目中使用该 Skill。记录 Claude 在哪里遇到困难或产生误解。根据失败情况完善指令并修订 Skill。
保持 SKILL.md 文件在 150 行以内以提高 token 效率。使用参考文件存放详细内容。设计渐进式披露：Skill 描述触发加载，但详细指令仅在 Claude 开始执行时加载。
结论：作为规范架构师的 PM
过去 12 个月改变了产品经理规范软件的方式。证据表明，相较于为人类阅读编写的单体文档，分阶段的方法更有效，并建议强制执行“先调研后规范”、在实现阶段之间设置可测试的检查点、明确保护现有功能，并优先选择平台原生服务。
这种转型建立在传统 PM 实践之上。用户需求、验收标准、成功指标和战略对齐对于“构建什么”依然至关重要。然而，“如何构建”现在需要转化为更易于机器解读、token 效率更高且包含 AI 特定要求的格式。PRD 编写任务演变为规范架构（Specification Architecting）：精确地结构化意图，使 AI 编程智能体能够可靠地实现它，同时保留定义高效产品管理所需的战略判断、业务上下文和用户共情。
最近的生产力数据表明这种投入是值得的。麦肯锡 2025 年 11 月的研究发现，表现优异的产品与工程团队通过 AI 编程工具实现了 16-30% 的生产力提升，软件质量提高了 31-45%。这些收益与采用深度直接相关：开发者采用率达到 80-100% 的公司，收益超过 110%，而表面化的采用效果微乎其微。优秀团队的差异化因素可以说就是 PRD 规范的质量。
对于 PM 来说，任务很明确。首先为你最常见的项目类型构建自己的 PRD Skill。在实际项目中测试它。根据你选择的智能体编程系统的薄弱环节进行迭代。与团队分享 Skill 和心得并共同完善。从文档到规范的转型正在进行中。掌握这一范式转移的人将能够支持团队构建更好、更快、更安全的软件，从而创造并捕获价值。