尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

基于用户影响的 PR 定价实践:解读 obsidian-copilot 的 pr-pricing 智能体(.claude/agents/pr-pricing.md)

基于用户影响的 PR 定价实践:解读 obsidian-copilot 的 pr-pricing 智能体(.claude/agents/pr-pricing.md) AI 应用大模型AI Agent交互助手RAG【免费下载链接】obsidian-copilotRun agents in Obsidian - OpenCode, Codex, Claude Code etc.项目地址https://gitcode.com/gh_mirrors/ob/obsidian-copilot点击查看免费下载导读本文围绕 obsidian-copilot在 Obsidian 中运行 OpenCode、Codex、Claude Code 等 Agent 的插件仓库内的 .claude/agents/pr-pricing.md 展开系统拆解这个 Claude Code 智能体的完整设计它如何以**用户可见影响user-facing impact**为第一原则用六档定价层级XS–XXL为每个 PR 定级定价并以统一的 Markdown 表格输出。读完本文你将掌握一套可直接复制到任何开源项目中的 PR 规模评估与定价方法论包括定档规则、校准样本、五步工作流和对应的ghCLI 命令。一、Agent 是什么一份 Markdown 定义文件背后的运行机制.claude/agents/pr-pricing.md是 Claude Code 生态中的智能体定义文件采用 YAML frontmatter 系统提示词的结构。文件头部声明了四个关键元数据--- name: pr-pricing description: Use this agent to size and price a PR (or list of PRs) based on the projects PR pricing tiers. Provide PR numbers as the prompt. Example: Price PRs #2100 #2101 #2102 model: sonnet color: green ---name智能体唯一标识也是被调用时的名称description注册给宿主模型的名片。它同时定义了触发条件对 PR 定价与调用方式直接把 PR 编号作为 prompt如Price PRs #2100 #2101 #2102支持一次对多个 PR 批量定价model指定运行该智能体时使用的模型本文件固定为sonnet保证定价结论的模型行为可复现color在交互界面中的展示颜色标识纯 UI 属性不影响逻辑。在同一个 .claude/agents 目录下还并列放置了 code-reviewer.md代码优雅性评审、prerelease.md预发布管理、release.md正式发布管理等同类智能体。可以看到 obsidian-copilot 把代码评审—PR 定价—发版编排成了一条完整的工程流水线pr-pricing负责在合并前对每个 PR 的工作量级与商业价值给出量化评估其输出可作为贡献者激励与排期优先级的依据。值得留意的是frontmatter 中的description出现在name之前、正文系统提示词之前是 Claude Code 读取智能体何时该被调用的入口。它的措辞Provide PR numbers as the prompt直接决定了使用者的交互方式因此在自定义智能体时应像写 API 文档一样认真打磨这段描述。二、定价第一原则用户影响优先于代码规模文档开篇用加粗强调的方式立下了整个定价体系的基石The most important factor isuser-facing impact— what changes for the user, not how many files were touched.即评估的是用户能感知到什么变化而不是改了多少个文件。这一原则具体化为三条操作规则默认取每个区间range的低端当 PR 还包含测试、文档、边界情况处理或高完成度打磨high polish时才向高端移动在两个档位之间拿不准时选更低的一档。这套规则的设计意图非常明确防止按代码量计费导致的两个失真——大段机械重构被高估改动大、用户无感小而精的功能被低估改动小、体验显著提升。它与仓库中 code-reviewer.md 反复强调的能少写就少写、每一行代码都要证明自己存在的价值在价值观上完全同构代码的价值由结果定义不由行数定义。从工程实践看这条原则还隐含一个可操作化的思路在阅读 PR 时先回答三个问题文档第 3 步原文——用户看到或体验到的差异是什么这是新工作流、对现有工作流的改进还是完全不可见invisible的内部改动与参考 PR 对照规模处于什么位置三、六档定价层级Tiers完整对照文档给出了完整的六档定价表从用户几乎无感的 XS 到足以支撑一个大版本号的 XXLSizeValueUser-Facing ImpactTechnical ScopeXS$25-50Users unlikely to notice (typo, tooltip, minor styling)Isolated 1-2 file changeS$50-150Fixes an annoyance or adds a minor optionSmall bug fix, config addition, no new workflowsM$150-300Noticeable improvement to an existing workflowMulti-file fix, simple feature, focused refactorL$300-600New capability users would highlight in a reviewStandalone feature, new UI component or systemXL$600-1,200Changes how users interact with a core part of the pluginLarge feature with new modules, core integrationXXL$1,200-2,000Flagship feature, could justify a major version bumpNew subsystem, deep cross-cutting integration逐档拆解其语义XS$25–50纯粹的低风险微调例如修正拼写、调整 tooltip、微小的样式改动。技术范围被限定在孤立的 1–2 个文件变更几乎不引入回归风险S$50–150修复一个恼人的小问题或新增一个次要选项。典型场景是小 bug 修复、配置项新增不引入新工作流M$150–300对现有工作流产生可感知的改进。技术形态是多文件修复、简单功能或聚焦的重构L$300–600用户会在 review 中主动点赞的新能力通常是一个独立的完整功能、新 UI 组件或新系统XL$600–1,200改变用户与插件核心部分的交互方式。往往伴随新模块引入与核心集成风险与价值同步上升XXL$1,200–2,000旗舰级功能足以支撑一次 major 版本号跃迁通常是全新子系统与深度的跨模块集成。观察档位划分可以提炼出两个隐含的判定坐标横轴是用户可感知度从无感到改变核心交互纵轴是技术辐射范围从单文件到跨模块子系统。两者并不总是同步——这正是档位判定需要人工判断、而非简单按 diff 行数自动计算的原因。四、用参考 PR 校准定价为了让档位判断具备可复现性文档内置了四个已定价的真实 PR 作为校准锚点它们均来自 obsidian-copilot 仓库历史PRTitleSizeValueRationale#2003Refactor model API key handlingS$50Internal cleanup, users see slightly better model filtering#2087File status and think block stateM$150Visible status badges fix for a noticeable streaming UX bug#2077Recent usage sorting for chat/projectM$150Improves existing workflow with sort options, not a new capability#1969System prompt management systemXL$900New user-facing system for creating/managing system prompts, includes 9 test files从当前仓库源码结构看这四条校准样本恰好能一一对应到真实模块可以作为理解为什么这么定档的旁证#2003S / $50模型 API Key 处理的重构。当前仓库中的 src/modelManagement/providers 目录集中了 ProviderRegistry、providerRequiresApiKey、selfHostPolicy 等模块——内部清理类改动用户侧只获得模型过滤更清晰这类隐性收益因此被压在 S 档低端#2087M / $150文件状态徽章 think block 状态修复。仓库中 ChatSingleMessage.tsx 与 ActivityGroupCard.tsx 等组件承载流式消息与状态渲染这类可见状态展示 流式体验 bug 修复的组合符合 M 档现有工作流的可感知改进定位#2077M / $150聊天/项目的近期使用排序。仓库中的 src/utils/recentUsageManager.ts 实现了SORT_STRATEGIES [recent, created, name, manual]四种排序策略及对应比较器是一个典型给现有列表加排序选项的功能——改进现有工作流而非新增能力恰好落在 M 档#1969XL / $900系统提示词管理系统。仓库中的 src/system-prompts 目录是完整的一等公民模块index.ts统一导出类型、常量、工具函数、状态管理、构建器与注册器SystemPromptRegister并附 migration.ts 承担从旧设置迁移的历史兼容。**新用户界面系统 9 个测试文件**正是 XL 档新模块 核心集成 高质量交付测试覆盖的完整写照。这套参考 PR 校准法的工程价值在于新 PR 定价时不需要从零抽象判断而是先与这四条基准线比对——它更像 #2087 还是更像 #1969从而显著降低不同分析师之间的定价漂移。五、五步定价工作流含完整 gh CLI 命令文档为每个传入的 PR 编号定义了严格的五步处理流程Step 1 — 拉取 PR 元数据gh pr view number --json title,additions,deletions,changedFiles,body一次调用即可拿到标题、增删行数、变更文件数与正文描述作为后续所有判断的输入。Step 2 — 检查是否含测试与文档gh pr view number --json files --jq .files[].path用--jq提取文件路径列表后过滤其中的 test/doc 文件。这一步对应向档位高端移动的加分级依据测试与文档的存在是向上调价的充分理由之一参考 #1969 明确注明includes 9 test files。Step 3 — 评估用户可见影响核心步骤文档强调这是首要定价因素并给出三个自问用户看到或体验到了什么不同这是新工作流、对现有工作流的改进还是完全不可见与参考 PR 对照如何校准Step 4 — 确定档位并给出具体金额先在 XS–XXL 六档中定位再在档位区间内选择一个具体美元值而非只写区间默认靠向低端。Step 5 — 一句话论证用一句话说明为什么落在该档必须引用用户影响作为依据例如新增了用户可见的状态徽章并修复了明显的流式 UX bug。这套流程的输入输出都是纯文本/JSON完全可由 CLI 驱动意味着它可以被脚本化、批量化执行——description中Price PRs #2100 #2101 #2102的多 PR 批量用法就是为这种场景设计的。六、输出格式一张可机器解析的定价表所有定价结论必须收敛为一张标准 Markdown 表格并在底部附加Total汇总行PRTitleSizeValueRationale#XXXX...M$150...随后是Total行这种输出设计的优点有三列结构固定PR / Title / Size / Value / Rationale便于后续脚本解析与归档Rationale 强制单句论证倒逼定价过程先定理由、后定价格Total 行提供批量汇总多个 PR 一起评估时可以直接得出总量服务于预算与排期决策。七、保守原则宁可低估不可高估文档结尾用Be conservative重申了整个定价体系的默认姿态默认取低端Default to the lower end只有出现明确的加分项才上移测试tests、文档docs、高完成度打磨high polish、显著 UX 影响significant UX impact两档之间拿不准时选更低的一档。与第 2 节的三条规则互为表里前者定义了何时上移的正向条件后者定义了何时下移的兜底规则。这套对称设计让定价行为在缺乏信息时自动偏向保守避免因高估而扭曲激励信号——也呼应了 release.md 中release notes 要诚实、不要过度推销的同类保守取向。八、把 pr-pricing 接入你的工作流在 obsidian-copilot 仓库中使用该智能体的方式是标准的 Claude Code Agent 调用由宿主模型根据description判断场景然后在对话中给出 PR 编号列表例如Price PRs #2100 #2101 #2102即可触发该智能体执行五步流程并返回定价表。值得注意的是定价结论仅依赖ghCLI 返回的公开 PR 数据不依赖任何本地私有状态因此同一 PR 在不同时间被评估只要输入数据一致结论可复现该智能体与同目录的 code-reviewer.md、prerelease.md、release.md 组合使用可形成评审 → 定价 → 发版的完整闭环如果你想在自己的项目复用这套方法论只需照搬 .claude/agents/pr-pricing.md 的 frontmatter 与正文模板并替换参考 PR 表格为你们仓库自己的历史样本——校准锚点必须来自目标项目否则档位判断会失真。小结.claude/agents/pr-pricing.md 虽然只有一屏篇幅却浓缩了一套完整的、可落地的开源 PR 定价方法论以用户可见影响为唯一核心坐标配合 XS–XXL 六档区间、四条历史校准锚点、五步gh工作流和强制表格化输出把这个 PR 值多少钱这一主观判断变成了可复现、可校准、可批量的工程流程。对于维护者而言它是贡献者激励与优先级排序的量化工具对于想自建评估体系的项目而言它是结构清晰、可直接移植的参考模板。进一步阅读若想理解该智能体所处的完整工程上下文可对照阅读 .claude/agents/release.md正式发布流程、.claude/agents/prerelease.md预发布流程、.claude/agents/code-reviewer.md代码评审以及本仓库的 RELEASES.md发布历史与 manifest.json插件版本元数据。赞分享AI 应用大模型AI Agent交互助手RAG【免费下载链接】obsidian-copilotRun agents in Obsidian - OpenCode, Codex, Claude Code etc.项目地址https://gitcode.com/gh_mirrors/ob/obsidian-copilot点击查看免费下载相关推荐claude-howto 项目实践基于 Claude Code 子 Agent 的 PR 性能影响分析指南claude howto 项目实践基于 Claude Code 子 Agent 的 PR 性能影响分析指南 导读 本文聚焦 claude howto 仓库中教程文档Claude Code PR 测试覆盖分析实战pr-test-analyzer 智能体完整指南Claude Code PR 测试覆盖分析实战pr test analyzer 智能体完整指南 导读 pr test analyzer 是 Claude CAI 应用AI 技能/插件开发工具Codex 上的 PR Babysitter基于 Loop Engineering 的 PR 看护与自动修复实践Codex 上的 PR Babysitter基于 Loop Engineering 的 PR 看护与自动修复实践 PR BabysitterPR 看护循环人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务上一篇如何快速集成React Native Push Notification iOS从零到一的完整教程下一篇【亲测免费】 Git 历史查看器 Git History 教程创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表