Pydantic AI 仓库贡献规范AI Agent 推送 PR 提交的完整工作流与质量闭环指南【免费下载链接】pydantic-aiHow Python does AI. Agents, realtime voice, image generation, embeddings. Every model, every interface, typed end to end.项目地址: https://gitcode.com/GitHub_Trending/py/pydantic-aiPydantic AI 仓库AGENTS.md为 AI Agent 定义了一套从「打开 PR」到「CI 变绿、评论清零、交还 PR」的完整贡献工作流本文是其中pushing-commits-to-the-repo技能.agents/skills/pushing-commits-to-the-repo/SKILL.md的深度解读。你将掌握PR 标题/正文的规范写法、标签治理、推送前的本地复查、推送后的 CI 与评论处理循环以及douwebot深度审查的运用时机从而让一次提交真正达到项目维护者的质量门槛。一、核心原则推送开启的是循环而不是任务的终点技能文档开篇即定调Pushing starts a loop; it does not end the task.推送提交只是开始只有当CI 全部通过green且没有任何评论处于未解决状态no comment is left unresolved时任务才算真正结束。这与根 AGENTS.md 中 Pushing changes 一节的表述完全一致Pushing is not the end of the task. After you push, do not go idle. The work is done whenCI is green and there are no unresolved comments。这一原则贯穿整个工作流不能推送后撒手不管推送之后 Agent 必须持续盯守 CI 状态、triage 每一条评论直到收敛不能留下未提交的工作根 AGENTS.md 同时要求 Do not leave work uncommitted除非用户明确指示否则不得以「存在未暂存/未提交的本地改动」结束一轮交互限制必须来自真实失败根 AGENTS.md 强调 A restriction is a conclusion you earn from a real failure, not a field you read——禁止仅凭元数据标志如maintainerCanModify: false、配置字段或文档声称就判断操作被阻止/不可用必须实际尝试并引用真实报错。该技能位于 .agents/skills/pushing-commits-to-the-repo/SKILL.mdfrontmatter 声明其适用时机是每次打开 PR 或向 PR 推送提交时。它是 Pydantic AI 仓库面向 AI Agent 的协作技能体系.agents/skills中的核心一环与complete-partial-pr、pre-push-review、address-feedback等技能相互配合。二、打开 PR标题与正文规范2.1 标题规则来自根 AGENTS.mdPR 标题会直接进入发布变更日志release changelog因此根 AGENTS.md 对标题有严格要求写成祈使句imperative sentence直接命名所做的变更例如Add support for ...不要加fix:/docs:/chore:这类前缀——那是 commit subject 的约定不属于 PR 标题所有代码标识符类名、关键字参数、模块路径、CLI 标志、环境变量、文件路径都必须用反引号包裹校验约定时应参考已合并 PRgh pr list --state merged --limit 20而非 commit subject因为两者遵循不同的规范。2.2 正文模板五段式结构与 40 行限制技能文档要求正文遵循根AGENTS.md的标题与模板规则同时明确可见正文内容控制在 40 行以内模板行和折叠的details内容不计入行数。对于功能或行为变更类 PR正文必须按以下顺序组织Why we make these changes为什么做这些改动——用几句话说明问题与决策并链接对应 issueNew public surface新增的公共 API 面——逐一列出每个新维护的符号没有时明确写noneUser-visible behavior用户可见行为变化——给出最小的 before/after 示例若调用链的变更更能解释行为则改用 call-path diff见第三节两者只取其一Verification验证——链接 PR diff 中能精确证明行为的测试仅当有助于 reviewer 复现时才在details中放最小可运行的 playgroundWhat changes for existing users对现有用户的影响——用一句话说明Nothing也是合法答案。折叠规范仅当 PR 包含多个相互独立的目标时才按目标各用一个折叠的details段落。琐碎 PR如拼写修正可以直接用「issue 链接 简短摘要 测试计划」三件套无需完整五段。仓库中的 .github/pull_request_template.md 提供了与之配套的模板骨架包括- Closes #issue声明 PR 关闭的 issue非平凡变更必须链接维护者已同意并指派的 issue未指派的 PR 可能被自动关闭ChecklistAI 生成代码必须经人类作者逐行审查并勾选不允许破坏版本策略docs/version-policy.md的破坏性变更若有兼容性影响需加标签、警告、迁移说明与 API 检查豁免Compatibility impact 警示块当 PR 带来版本策略允许的兼容性影响时须在开头说明影响面、为何能在 minor 版本发布以及迁移方案AI generated code 勾选框必须由用户在 UI 中手动勾选而不是由 Agent 勾选——技能文档第八节对此有专门交代。三、User-visible call-path diff用调用链树解释行为当调用链的变更比 before/after 示例更能解释用户可见行为时正文第三部分应改用user-visible call-path diff一段围栏内的diff树从公共入口指向被改变的可观察结果。格式要点如下每个节点格式为path/file.py :: Class.method()或path/file.py :: function()每个被调用者以└─缩进在其调用者下方保留足够多的未变更节点以展示每条边不相关的中间调用折叠为… unchanged machinery …仅当参数能解释变更时才包含参数仅在与结果相关的叶节点上包含结果共享的调用者前缀保持不标记只标记分叉节点、相关参数或结果fence 内目标 12 行内容绝不超过 20 行次要分支直接折叠。一个示意非仓库真实 diff仅演示格式pydantic_ai/agent.py :: Agent.run() └─ pydantic_ai/_agent_graph.py :: _AgentGraph.run() └─ pydantic_ai/_run_context.py :: RunContext.__init__() ├─ … unchanged machinery … └─ pydantic_ai/models/openai.py :: OpenAIModel.request() ← 变更点新增 timeout 参数 └─ result: 请求超时行为由「抛异常」变为「返回重试提示」四、应用标签先取真实列表再精准命中仓库通过标签进行 triage 和过滤例如 .github/workflows/ci.yml 中的ci:fast/ci:slow标签会决定测试矩阵是否路由到更快的 Ubicloud runner因此技能文档要求为 PR 应用合适的标签并强调先取真实列表再打标签# 先拉取仓库真实标签集合集合会变化猜出来的标签会静默应用失败 gh label list --limit 100 # 应用标签 gh pr edit number --add-label label选择策略分为两层类型标签选一个描述 PR是什么的标签——bug、feature、docs、chore、refactor主题标签在合适时追加一个主题标签如anthropic、MCP、evals等。需要注意的权限与边界打标签需要仓库的triage 权限Pydantic 团队成员及其 Agent 拥有若标签应用失败引用实际错误而不是直接断言我没有权限size 标签由系统自动应用不要手动设置。五、推送之前提交状态与 pre-push-review5.1 提交确切的状态提交你打算推送的那个精确状态。除非用户指令覆盖否则不得遗留任何 staged、unstaged 或未提交的改动根 AGENTS.md 同步要求不得在 turn 结束时留有未提交的本地改动。5.2 运行 pre-push-review直到零发现在首次推送 PR 之前以及之后每一次 PR 迭代推送之前都必须运行pre-push-review处理其每一条发现、提交修复然后重复复查直到它返回无发现pre-push-review的结论verdict只属于它读过的那个 diff任何后续提交都会使其失效必须针对新 diff 重新运行并在汇报时指明每个 verdict 覆盖的 commit 范围该复查技能位于 .claude/skills/pre-push-review/SKILL.md它使用本地可用的最强模型做高判断力审查是douwebot的本地对应物独立于 CI 通过后自动运行的CI Review。其方法论包括读取.github/workflows/bots.yml中douwebot审查 job 的prompt:作为审查标准评分规则、优先级、反馈质量读取根 AGENTS.md、agent_docs/index.md 及其主题指南、以及每个受改文件对应的目录级AGENTS.md通过gh pr view获取 PR 上下文并用git status --short、git diff base...HEAD --stat、git diff base...HEAD -W、git diff HEAD等命令收集本地 diff最后只返回可执行的文本发现file:line 问题 具体修复不在 GitHub 上发评论、不做 review、不改分支。5.3 绝不 force-push永远不要对开放的 PR 分支进行 force-push应推送后续提交follow-up commits使此前的 review 仍然有效——维护者合并时可以自行 squash。5.4 推送失败时读真实错误推送失败时读取真实报错信息不要因为某个 flag 或设置就预先断定自己没有权限再次呼应根 AGENTS.md 的 restriction is a conclusion you earn from a real failure 原则。六、推送之后CI 盯守与评论 Triage 循环技能文档把推送后的阶段定义为四步循环反复执行直到 CI 绿且无未解决评论1. 盯守 CI 直到终态。不要空转等待。CI 失败时先诊断若失败源于你的改动直接修复若属于已知 flake 或 main 分支上已存在的问题则附上证据说明。仓库 CI 定义在 .github/workflows/ci.yml其结构有助于理解CI 到终态意味着什么classifyjob 先对 PR 变更分类判断是否为纯文档变更、是否触及 pyright 输入决定后续 job 是否运行qualitylint / format / typecheck / 公共 API 兼容性检查、mypy、docs-assets文档链接与图片校验、docs-only仅 Markdown 变更时的轻量检查等质量关卡test矩阵覆盖 Python 3.10–3.14 与多种安装形态slim / evals / standard / all-extras另有test-durable-exec、test-lowest-versions、test-examples、test-fastmcp-4等专项 job最终由checkjob基于alls-greenaction汇总所有必需 job 的成败作为分支保护依据只有标签发布tag通过后才触发deploy-docs与release-build。2. Triage 每一条评论机器人与人类的评论一视同仁有效Valid→ 修复它然后回复说明改了什么并点 表情回应无效Invalid→ 用具体的代码证据回复解释为何不成立并点 表情回应绝不静默忽略评论也绝不在未回复的情况下 resolve 线程。配套的 .claude/skills/address-feedback/SKILL.md 把 triage 细化为fix/decline/escalate/file四类决策先读完整评论线程维护者或作者可能已解释为何不应采纳若发现声称存在缺陷在写修复前先复现它跑脚本、失败测试或代码片段无法复现则回复跑了什么、为何覆盖该路径并点 若修复会触碰 PR 原定范围之外的文件尤其是共享核心模块如pydantic_ai/_agent_graph.py、pydantic_ai/_run_context.py、pydantic_ai/messages.py、pydantic_ai/tools.py、基类、可序列化 dataclass则需按根 AGENTS.md 的规则评估是否扩大范围否则升级或另开 issue评论处理完毕后用 GraphQLresolveReviewThread关闭线程仅在等待决策或他人回应时才保持线程开启。3. 升级真实权衡不要猜测。若评论需要维护者决策设计选择、API 权衡、行为默认值在评论中给出背景、你的推理、需要做出的决策、各选项的利弊pros/cons、你的推荐。然后每 30 分钟轮询一次回复收到回复后继续。4. 重复直到 CI 全绿且没有任何未解决评论。七、循环结束后考虑 douwebot 深度审查仓库存在两个相互独立的标准审查者CI Review在 PR 当前 head 上CIworkflow 成功后自动运行拥有APPROVE/REQUEST_CHANGES结论流程更严格——严重度分级、子 Agent 扇出、逐条发现验证douwebot仅当应用了douwebot标签时运行使用更强的模型发布内联评论但不给结论完成时自行删除标签因此每次应用恰好买到一次针对当时那个 diff的审查。应用douwebot标签只是增加第二意见不会抑制或取代CI Review。决策要点最后应用而不是提前。它不会在后续推送时重跑因此对仍在变动的 PR 做深度审查是浪费成本。应在上述循环收敛CI 绿、评论全部 triage 完之后、交还 PR 或请求合并之前决定是否应用用判断力决定是否值得。高度确信无事可查时跳过拼写修正、依赖升级、机械性杂务实质变更——新功能、行为变更、公共 API 面、非平凡 bug 修复以及面向用户的文档它能抓到例如示例仍在使用过时模型的问题——务必应用。居中情况权衡成本与风险小 PR 审查更便宜不确定时倾向于应用命令gh pr edit number --add-label douwebot需要仓库 triage 权限Pydantic 团队成员及其 Agent失败时引用实际错误不要臆断无权限已知拒绝安全护栏若 PR 触及任意深度的AGENTS.md或CLAUDE.md、CLAUDE.local.md、.mcp.json或.claude/、.agents/、agent_docs/下的任何内容douwebot会不审查直接失败——这是防止 PR 篡改审查者自身指令的安全机制。对拥有仓库 write/admin 权限的作者会跳过该护栏。不要对护栏覆盖的 PR 应用该标签出现红色检查正是护栏在起作用之后重新进入循环douwebot发布的评论需要与其他评论一样的 triage 处理。八、交还 PR 前最终元数据检查在 CI、评论与如选用的douwebot审查全部尘埃落定后执行如下最终元数据检查派发一个未参与过该 PR 工作的全新 subagent给它 PR URL、关联 issue、当前base...HEADdiff、最终测试状态、标题与正文要求它只对照本节规则与根 AGENTS.md 检查标题与正文要求它给出结论要么是current要么是一份精确的替换标题与正文应用全部修正。代码改动会重启推送后循环纯元数据改动不会替换后用另一个全新 subagent 再重复一次检查只有在检查报告current之后才把 PR 交还单独报告 human-only 的 AI generated code 勾选框——该框必须由人类在 UI 中手动勾选见 .github/pull_request_template.md 的 checklist 及根 AGENTS.md 的 The AI generated code checkbox should always be checked manually by the user in the UIAgent 不得代勾。九、全流程速查阶段关键动作验收标准打开 PR按根 AGENTS.md 写祈使句标题正文按五段结构、40 行内标题/正文通过元数据检查打标签gh label list --limit 100取真实列表类型标签 主题标签gh pr edit number --add-label label标签真实存在且成功应用推送前提交确切状态运行pre-push-review至零发现不 force-pushreview verdict 覆盖当前 diff推送后盯守 CI 至终态triage 每条评论fix / 证据驳回权衡问题升级并每 30 分钟轮询CI 绿 零未解决评论深度审查可选循环收敛后按判断应用douwebot标签护栏覆盖的 PR 不应用获得一次针对当下 diff 的第二意见交还前全新 subagent 做元数据检查要求current或精确替换人工勾选 AI-code 框检查报告current方可交还这套规范的本质是把「推送」从一个动作改写成一个以质量收敛为终点的闭环协议每一次 push 都经过本地复查、CI 验证、评论 triage 与元数据校验四道闸门最终保证合并进 Pydantic AI 的任何变更都符合仓库对类型安全、测试覆盖、文档与 API 设计的高标准。对于向该仓库提交 PR 的开发者与驱动它们的 AI Agent 而言将 .agents/skills/pushing-commits-to-the-repo/SKILL.md、.claude/skills/pre-push-review/SKILL.md 与 .claude/skills/address-feedback/SKILL.md 三者配合使用即可完整覆盖从首次提交到最终合并的全生命周期。【免费下载链接】pydantic-aiHow Python does AI. Agents, realtime voice, image generation, embeddings. Every model, every interface, typed end to end.项目地址: https://gitcode.com/GitHub_Trending/py/pydantic-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Pydantic AI 仓库贡献规范：AI Agent 推送 PR 提交的完整工作流与质量闭环指南
Pydantic AI 仓库贡献规范AI Agent 推送 PR 提交的完整工作流与质量闭环指南【免费下载链接】pydantic-aiHow Python does AI. Agents, realtime voice, image generation, embeddings. Every model, every interface, typed end to end.项目地址: https://gitcode.com/GitHub_Trending/py/pydantic-aiPydantic AI 仓库AGENTS.md为 AI Agent 定义了一套从「打开 PR」到「CI 变绿、评论清零、交还 PR」的完整贡献工作流本文是其中pushing-commits-to-the-repo技能.agents/skills/pushing-commits-to-the-repo/SKILL.md的深度解读。你将掌握PR 标题/正文的规范写法、标签治理、推送前的本地复查、推送后的 CI 与评论处理循环以及douwebot深度审查的运用时机从而让一次提交真正达到项目维护者的质量门槛。一、核心原则推送开启的是循环而不是任务的终点技能文档开篇即定调Pushing starts a loop; it does not end the task.推送提交只是开始只有当CI 全部通过green且没有任何评论处于未解决状态no comment is left unresolved时任务才算真正结束。这与根 AGENTS.md 中 Pushing changes 一节的表述完全一致Pushing is not the end of the task. After you push, do not go idle. The work is done whenCI is green and there are no unresolved comments。这一原则贯穿整个工作流不能推送后撒手不管推送之后 Agent 必须持续盯守 CI 状态、triage 每一条评论直到收敛不能留下未提交的工作根 AGENTS.md 同时要求 Do not leave work uncommitted除非用户明确指示否则不得以「存在未暂存/未提交的本地改动」结束一轮交互限制必须来自真实失败根 AGENTS.md 强调 A restriction is a conclusion you earn from a real failure, not a field you read——禁止仅凭元数据标志如maintainerCanModify: false、配置字段或文档声称就判断操作被阻止/不可用必须实际尝试并引用真实报错。该技能位于 .agents/skills/pushing-commits-to-the-repo/SKILL.mdfrontmatter 声明其适用时机是每次打开 PR 或向 PR 推送提交时。它是 Pydantic AI 仓库面向 AI Agent 的协作技能体系.agents/skills中的核心一环与complete-partial-pr、pre-push-review、address-feedback等技能相互配合。二、打开 PR标题与正文规范2.1 标题规则来自根 AGENTS.mdPR 标题会直接进入发布变更日志release changelog因此根 AGENTS.md 对标题有严格要求写成祈使句imperative sentence直接命名所做的变更例如Add support for ...不要加fix:/docs:/chore:这类前缀——那是 commit subject 的约定不属于 PR 标题所有代码标识符类名、关键字参数、模块路径、CLI 标志、环境变量、文件路径都必须用反引号包裹校验约定时应参考已合并 PRgh pr list --state merged --limit 20而非 commit subject因为两者遵循不同的规范。2.2 正文模板五段式结构与 40 行限制技能文档要求正文遵循根AGENTS.md的标题与模板规则同时明确可见正文内容控制在 40 行以内模板行和折叠的details内容不计入行数。对于功能或行为变更类 PR正文必须按以下顺序组织Why we make these changes为什么做这些改动——用几句话说明问题与决策并链接对应 issueNew public surface新增的公共 API 面——逐一列出每个新维护的符号没有时明确写noneUser-visible behavior用户可见行为变化——给出最小的 before/after 示例若调用链的变更更能解释行为则改用 call-path diff见第三节两者只取其一Verification验证——链接 PR diff 中能精确证明行为的测试仅当有助于 reviewer 复现时才在details中放最小可运行的 playgroundWhat changes for existing users对现有用户的影响——用一句话说明Nothing也是合法答案。折叠规范仅当 PR 包含多个相互独立的目标时才按目标各用一个折叠的details段落。琐碎 PR如拼写修正可以直接用「issue 链接 简短摘要 测试计划」三件套无需完整五段。仓库中的 .github/pull_request_template.md 提供了与之配套的模板骨架包括- Closes #issue声明 PR 关闭的 issue非平凡变更必须链接维护者已同意并指派的 issue未指派的 PR 可能被自动关闭ChecklistAI 生成代码必须经人类作者逐行审查并勾选不允许破坏版本策略docs/version-policy.md的破坏性变更若有兼容性影响需加标签、警告、迁移说明与 API 检查豁免Compatibility impact 警示块当 PR 带来版本策略允许的兼容性影响时须在开头说明影响面、为何能在 minor 版本发布以及迁移方案AI generated code 勾选框必须由用户在 UI 中手动勾选而不是由 Agent 勾选——技能文档第八节对此有专门交代。三、User-visible call-path diff用调用链树解释行为当调用链的变更比 before/after 示例更能解释用户可见行为时正文第三部分应改用user-visible call-path diff一段围栏内的diff树从公共入口指向被改变的可观察结果。格式要点如下每个节点格式为path/file.py :: Class.method()或path/file.py :: function()每个被调用者以└─缩进在其调用者下方保留足够多的未变更节点以展示每条边不相关的中间调用折叠为… unchanged machinery …仅当参数能解释变更时才包含参数仅在与结果相关的叶节点上包含结果共享的调用者前缀保持不标记只标记分叉节点、相关参数或结果fence 内目标 12 行内容绝不超过 20 行次要分支直接折叠。一个示意非仓库真实 diff仅演示格式pydantic_ai/agent.py :: Agent.run() └─ pydantic_ai/_agent_graph.py :: _AgentGraph.run() └─ pydantic_ai/_run_context.py :: RunContext.__init__() ├─ … unchanged machinery … └─ pydantic_ai/models/openai.py :: OpenAIModel.request() ← 变更点新增 timeout 参数 └─ result: 请求超时行为由「抛异常」变为「返回重试提示」四、应用标签先取真实列表再精准命中仓库通过标签进行 triage 和过滤例如 .github/workflows/ci.yml 中的ci:fast/ci:slow标签会决定测试矩阵是否路由到更快的 Ubicloud runner因此技能文档要求为 PR 应用合适的标签并强调先取真实列表再打标签# 先拉取仓库真实标签集合集合会变化猜出来的标签会静默应用失败 gh label list --limit 100 # 应用标签 gh pr edit number --add-label label选择策略分为两层类型标签选一个描述 PR是什么的标签——bug、feature、docs、chore、refactor主题标签在合适时追加一个主题标签如anthropic、MCP、evals等。需要注意的权限与边界打标签需要仓库的triage 权限Pydantic 团队成员及其 Agent 拥有若标签应用失败引用实际错误而不是直接断言我没有权限size 标签由系统自动应用不要手动设置。五、推送之前提交状态与 pre-push-review5.1 提交确切的状态提交你打算推送的那个精确状态。除非用户指令覆盖否则不得遗留任何 staged、unstaged 或未提交的改动根 AGENTS.md 同步要求不得在 turn 结束时留有未提交的本地改动。5.2 运行 pre-push-review直到零发现在首次推送 PR 之前以及之后每一次 PR 迭代推送之前都必须运行pre-push-review处理其每一条发现、提交修复然后重复复查直到它返回无发现pre-push-review的结论verdict只属于它读过的那个 diff任何后续提交都会使其失效必须针对新 diff 重新运行并在汇报时指明每个 verdict 覆盖的 commit 范围该复查技能位于 .claude/skills/pre-push-review/SKILL.md它使用本地可用的最强模型做高判断力审查是douwebot的本地对应物独立于 CI 通过后自动运行的CI Review。其方法论包括读取.github/workflows/bots.yml中douwebot审查 job 的prompt:作为审查标准评分规则、优先级、反馈质量读取根 AGENTS.md、agent_docs/index.md 及其主题指南、以及每个受改文件对应的目录级AGENTS.md通过gh pr view获取 PR 上下文并用git status --short、git diff base...HEAD --stat、git diff base...HEAD -W、git diff HEAD等命令收集本地 diff最后只返回可执行的文本发现file:line 问题 具体修复不在 GitHub 上发评论、不做 review、不改分支。5.3 绝不 force-push永远不要对开放的 PR 分支进行 force-push应推送后续提交follow-up commits使此前的 review 仍然有效——维护者合并时可以自行 squash。5.4 推送失败时读真实错误推送失败时读取真实报错信息不要因为某个 flag 或设置就预先断定自己没有权限再次呼应根 AGENTS.md 的 restriction is a conclusion you earn from a real failure 原则。六、推送之后CI 盯守与评论 Triage 循环技能文档把推送后的阶段定义为四步循环反复执行直到 CI 绿且无未解决评论1. 盯守 CI 直到终态。不要空转等待。CI 失败时先诊断若失败源于你的改动直接修复若属于已知 flake 或 main 分支上已存在的问题则附上证据说明。仓库 CI 定义在 .github/workflows/ci.yml其结构有助于理解CI 到终态意味着什么classifyjob 先对 PR 变更分类判断是否为纯文档变更、是否触及 pyright 输入决定后续 job 是否运行qualitylint / format / typecheck / 公共 API 兼容性检查、mypy、docs-assets文档链接与图片校验、docs-only仅 Markdown 变更时的轻量检查等质量关卡test矩阵覆盖 Python 3.10–3.14 与多种安装形态slim / evals / standard / all-extras另有test-durable-exec、test-lowest-versions、test-examples、test-fastmcp-4等专项 job最终由checkjob基于alls-greenaction汇总所有必需 job 的成败作为分支保护依据只有标签发布tag通过后才触发deploy-docs与release-build。2. Triage 每一条评论机器人与人类的评论一视同仁有效Valid→ 修复它然后回复说明改了什么并点 表情回应无效Invalid→ 用具体的代码证据回复解释为何不成立并点 表情回应绝不静默忽略评论也绝不在未回复的情况下 resolve 线程。配套的 .claude/skills/address-feedback/SKILL.md 把 triage 细化为fix/decline/escalate/file四类决策先读完整评论线程维护者或作者可能已解释为何不应采纳若发现声称存在缺陷在写修复前先复现它跑脚本、失败测试或代码片段无法复现则回复跑了什么、为何覆盖该路径并点 若修复会触碰 PR 原定范围之外的文件尤其是共享核心模块如pydantic_ai/_agent_graph.py、pydantic_ai/_run_context.py、pydantic_ai/messages.py、pydantic_ai/tools.py、基类、可序列化 dataclass则需按根 AGENTS.md 的规则评估是否扩大范围否则升级或另开 issue评论处理完毕后用 GraphQLresolveReviewThread关闭线程仅在等待决策或他人回应时才保持线程开启。3. 升级真实权衡不要猜测。若评论需要维护者决策设计选择、API 权衡、行为默认值在评论中给出背景、你的推理、需要做出的决策、各选项的利弊pros/cons、你的推荐。然后每 30 分钟轮询一次回复收到回复后继续。4. 重复直到 CI 全绿且没有任何未解决评论。七、循环结束后考虑 douwebot 深度审查仓库存在两个相互独立的标准审查者CI Review在 PR 当前 head 上CIworkflow 成功后自动运行拥有APPROVE/REQUEST_CHANGES结论流程更严格——严重度分级、子 Agent 扇出、逐条发现验证douwebot仅当应用了douwebot标签时运行使用更强的模型发布内联评论但不给结论完成时自行删除标签因此每次应用恰好买到一次针对当时那个 diff的审查。应用douwebot标签只是增加第二意见不会抑制或取代CI Review。决策要点最后应用而不是提前。它不会在后续推送时重跑因此对仍在变动的 PR 做深度审查是浪费成本。应在上述循环收敛CI 绿、评论全部 triage 完之后、交还 PR 或请求合并之前决定是否应用用判断力决定是否值得。高度确信无事可查时跳过拼写修正、依赖升级、机械性杂务实质变更——新功能、行为变更、公共 API 面、非平凡 bug 修复以及面向用户的文档它能抓到例如示例仍在使用过时模型的问题——务必应用。居中情况权衡成本与风险小 PR 审查更便宜不确定时倾向于应用命令gh pr edit number --add-label douwebot需要仓库 triage 权限Pydantic 团队成员及其 Agent失败时引用实际错误不要臆断无权限已知拒绝安全护栏若 PR 触及任意深度的AGENTS.md或CLAUDE.md、CLAUDE.local.md、.mcp.json或.claude/、.agents/、agent_docs/下的任何内容douwebot会不审查直接失败——这是防止 PR 篡改审查者自身指令的安全机制。对拥有仓库 write/admin 权限的作者会跳过该护栏。不要对护栏覆盖的 PR 应用该标签出现红色检查正是护栏在起作用之后重新进入循环douwebot发布的评论需要与其他评论一样的 triage 处理。八、交还 PR 前最终元数据检查在 CI、评论与如选用的douwebot审查全部尘埃落定后执行如下最终元数据检查派发一个未参与过该 PR 工作的全新 subagent给它 PR URL、关联 issue、当前base...HEADdiff、最终测试状态、标题与正文要求它只对照本节规则与根 AGENTS.md 检查标题与正文要求它给出结论要么是current要么是一份精确的替换标题与正文应用全部修正。代码改动会重启推送后循环纯元数据改动不会替换后用另一个全新 subagent 再重复一次检查只有在检查报告current之后才把 PR 交还单独报告 human-only 的 AI generated code 勾选框——该框必须由人类在 UI 中手动勾选见 .github/pull_request_template.md 的 checklist 及根 AGENTS.md 的 The AI generated code checkbox should always be checked manually by the user in the UIAgent 不得代勾。九、全流程速查阶段关键动作验收标准打开 PR按根 AGENTS.md 写祈使句标题正文按五段结构、40 行内标题/正文通过元数据检查打标签gh label list --limit 100取真实列表类型标签 主题标签gh pr edit number --add-label label标签真实存在且成功应用推送前提交确切状态运行pre-push-review至零发现不 force-pushreview verdict 覆盖当前 diff推送后盯守 CI 至终态triage 每条评论fix / 证据驳回权衡问题升级并每 30 分钟轮询CI 绿 零未解决评论深度审查可选循环收敛后按判断应用douwebot标签护栏覆盖的 PR 不应用获得一次针对当下 diff 的第二意见交还前全新 subagent 做元数据检查要求current或精确替换人工勾选 AI-code 框检查报告current方可交还这套规范的本质是把「推送」从一个动作改写成一个以质量收敛为终点的闭环协议每一次 push 都经过本地复查、CI 验证、评论 triage 与元数据校验四道闸门最终保证合并进 Pydantic AI 的任何变更都符合仓库对类型安全、测试覆盖、文档与 API 设计的高标准。对于向该仓库提交 PR 的开发者与驱动它们的 AI Agent 而言将 .agents/skills/pushing-commits-to-the-repo/SKILL.md、.claude/skills/pre-push-review/SKILL.md 与 .claude/skills/address-feedback/SKILL.md 三者配合使用即可完整覆盖从首次提交到最终合并的全生命周期。【免费下载链接】pydantic-aiHow Python does AI. Agents, realtime voice, image generation, embeddings. Every model, every interface, typed end to end.项目地址: https://gitcode.com/GitHub_Trending/py/pydantic-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考