Plate 的 AI Agent 文档评审体系product-lens-reviewer 产品视角评审 Skill 深度解析【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/platePlate 仓库一个基于 shadcn/ui 的富文本编辑器框架在.agents/目录下维护了一套面向 AI 编码代理的技能Skill体系其中product-lens-reviewer是文档评审document-review家族中负责产品视角的评审人格。本文以 .agents/skills/product-lens-reviewer/SKILL.md 为主体完整拆解其分析协议、置信度校准与职责边界并结合仓库中实际调度它的major-task技能、同族评审 Skill 与 skiller 同步配置说明这一产品镜头在 Plate 的工程自动化流程中何时被触发、如何工作、又刻意不做什么。一、Skill 的定位与元信息每个 Skill 以目录形式存放于.agents/skills/下由一个SKILL.md定义。product-lens-reviewer的 front matter 声明如下name: product-lens-reviewer description: Reviews planning documents as a senior product leader -- challenges problem framing, evaluates scope decisions, and surfaces misalignment between stated goals and proposed work. Spawned by the document-review skill. model: inherit metadata: skiller: source: plugins/compound-engineering/agents/document-review/product-lens-reviewer.md从中可以读出三个关键信息角色设定它以资深产品负责人senior product leader的身份评审规划文档。开篇第一句直接给出核心立场——最常见的失败模式是把错误的东西做好building the wrong thing well因此它先挑战前提再评价执行。生命周期description声明它由 document-review 技能派生spawned。在 Plate 仓库的实际编排中承担文档评审调度职责的是major-task技能的 Document Review 执行路径见.agents/skills/major-task/SKILL.md中 ### Document Review 一节约第 243-252 行它按条件决定加载哪些评审人格。来源追踪metadata.skiller.source指向plugins/compound-engineering/agents/document-review/product-lens-reviewer.md说明该 Skill 由 skiller 工具从 compound-engineering 插件同步而来。根目录的 skiller-lock.json 中确实登记了product-lens-reviewer条目及其sourceRelPath与 front matter 中的声明一一对应。值得注意的是.agents/AGENTS.md第一条规则.agents/rules/*.mdc与.agents/AGENTS.md是 source of truth编辑后需执行pnpm install同步禁止直接编辑SKILL.md。也就是说product-lens-reviewer/SKILL.md是同步产物其上游来源是.agents/rules/major-task.mdc之类的规则文件或 skiller 管理的插件源。这也解释了为什么.agents/rules/下存在与major-task技能内容同构的.agents/rules/major-task.mdc——两者描述同一套评审调度逻辑规则文件是源头。此外.agents/AGENTS.md列出了 Plate 对 compound-engineering 代理的排除清单如data-migration-expert、dhh-rails-reviewer等理由是Plate 是框架/编辑器仓库这些形态不匹配而product-lens-reviewer不在排除之列属于该仓库保留并启用的评审人格。二、分析协议五步产品镜头SKILL.md 的 ## Analysis protocol 是全文的核心骨架定义了固定顺序的五步分析流程。1. 前提挑战Premise challenge永远最先执行这是该 Skill 的灵魂步骤对每一份计划文档先回答以下问题只有在答案暴露出问题时才产出 finding发现项Right problem?对的问题吗——换一种问题框架是否会得到更简单或更有影响力的方案凡是只说构建 X却不解释为什么 X 优于 Y 或 Z 的计划都在做隐性的前提声明必须被显式化。Actual outcome?真实结果是什么——从拟议工作一路追踪到用户影响。这是最直接的到达路径还是在解决一个代理问题proxy problem文档点名要警惕间接链例如 config service - feature flags - gradual rollouts - reduced risk 这类层层转手的因果链。What if we did nothing?什么都不做会怎样——是有证据支撑的真实痛点投诉、指标、事故还是假设性需求用户可能会想要……文档明确假设性需求要受到更严厉的挑战。Inversion: what would make this fail?反转什么会让它失败——对每个既定目标指名最有可能出现计划按原文落地了、目标却仍未达成的场景。文档对此有精确的方法论说明正向分析forward-looking analysis能抓住错位反转分析则能抓住风险。2. 轨迹检查Trajectory check判断计划是顺应还是背离系统的自然演化方向。文档原文标准是即使计划的目标-需求对齐很干净只要它解决今天的问题却把系统逼进角落——阻塞未来变更、制造路径依赖、或硬编码一个终将过期的假设——就应该被标记。3. 实现替代方案Implementation alternatives追问是否存在以 20% 成本交付 80% 价值的路径是否考虑了 buy vs. build自研 vs. 采用现成方案换一个执行顺序能否更早交付价值这里有一条克制的产出规则——只有当一个具体、可指名的更简单替代方案存在时才产出 finding避免泛泛而谈。4. 目标-需求对齐Goal-requirement alignment用三个精确术语刻画对齐缺口Orphan requirements孤儿需求不服务于任何已声明目标的需求是范围蔓延scope creep的信号Unserved goals未被承接的目标没有任何需求去实现的目标说明规划不完整Weak links弱连接名义上连上了、实际却动不了指针wouldnt move the needle的映射。5. 优先级一致性Prioritization coherence当文档存在优先级分层P0/P1/P2时检查分层是否与声明的目标一致must-have 是不是真的 must-have文档给出一个可操作的判定问题——把除它以外的东西全部发出去目标还能达成吗以及 P0 是否依赖 P2依赖倒挂。三、置信度校准什么时候保持沉默该 Skill 对何时开口有量化约束## Confidence calibration 一节定义置信度判定标准行为HIGH0.80能同时引用目标声明与相冲突的工作项原文错位一目了然产出 findingMODERATE0.60-0.79可能存在错位但判断依赖文档之外的业务上下文谨慎产出低于 0.50—Suppress压制不产出这个低于 0.5 直接压制的阈值设计是典型的降噪策略评审人格的输出会直接进入工程决策流宁可漏报模糊猜测也不输出低置信噪音。同族的 coherence-reviewer、scope-guardian-reviewer、feasibility-reviewer 与 adversarial-document-reviewer 采用了完全一致的三档校准HIGH 0.80 / MODERATE 0.60-0.79 / Below 0.50 Suppress可以推断这是 document-review 家族的统一输出契约只是各人格对HIGH 的可引用证据有不同定义——product-lens 要求能引用目标与冲突工作项coherence 要求能引用两处互相矛盾的原文feasibility 要求能具体指出阻塞性的技术约束。四、职责边界What you dont flag## What you dont flag 一节划定了 product-lens 明确不碰的领域这是理解多人格分工的关键实现细节、技术架构、度量方法论风格/格式、安全归 security-lens、设计归 design-lens范围定级归 scope-guardian、内部一致性归 coherence-reviewer。把同族人格的 What you dont flag 交叉对照后能拼出 Plate 仓库文档评审的完整分工矩阵评审人格独占领域明确让渡product-lens-reviewer问题框架、我们是否在解决对的问题、目标-需求对齐、优先级架构、范围定级、内部一致性coherence-reviewer章节间矛盾、术语漂移、结构问题、真歧义计划好坏、可行性见 SKILL.mdscope-guardian-reviewer范围与目标是否相称、每个抽象是否挣得回自己是否解决对的问题product-lensfeasibility-reviewer架构冲突、影子路径、依赖、迁移安全、可实现性实现风格、测试策略偏好adversarial-document-reviewer前提证伪、假设显式化、决策压力测试内部矛盾coherence、可行性feasibility、产品框架product-lensscope-guardian-reviewer 的原文甚至点名You are not reviewing whether the plan solves the right problem (product-lens)——各人格的边界在仓库里是双向声明、互相咬合的这保证了同一次文档评审中多人格并行时不会重复发现double-flag同一问题。五、触发条件major-task 中的条件加载product-lens-reviewer不是每次评审都加载的常驻人格而是条件触发的。在.agents/skills/major-task/SKILL.md的 ### Document Review 执行路径中调度规则约第 243-252 行为仅用于显式的 plan / RFC / proposal / spec 评审默认评审对Default review pair只有两个coherence-reviewer与feasibility-reviewer当文档引入多个新抽象、大范围落地形态或范围疑似漂移时追加scope-guardian-reviewer当文档在做产品框架、roadmap、UX 价值或我们是否在解决对的事层面的声明时追加product-lens-reviewer当文档需求/实现单元超过 5 个、做出重大架构决策或提出新抽象时追加adversarial-document-reviewerKeep this pass selective. Most docs should not load every reviewer.——评审路径必须保持克制多数文档不应加载所有评审人格。配套的 Load Skills Only When Justified 一节第 139 行起对每个 helper 技能都写明了触发理由product-lens-reviewer的条目为Use when the document is making product framing, value, or roadmap claims. 这套按声明内容选人格的机制与major-task开篇的原则呼应Usually load 3 to 5 helpers, not every possible helper。从这套调度规则可以推断在 Plate 的实际使用中docs/plans/下大量2026-04-xx-slate-v2-*.md这类重大规划文档仓库docs/plans/目录中数百份计划在走major-task文档评审路径时只要包含 roadmap 或价值判断类声明就会触发本人格的前置挑战。六、运行与验证方式该 Skill 属于 Plate 的 Agent 工具链随仓库只读分发读者可以通过以下方式理解与验证其配置链路查看人格定义.agents/skills/product-lens-reviewer/SKILL.md51 行front matter 五步协议 置信度 排除项查看同步来源声明根目录 skiller-lock.json 中product-lens-reviewer条目的sourceRelPath为plugins/compound-engineering/agents/document-review/product-lens-reviewer.md查看 skiller 全局开关.agents/skiller.toml 中[skills] enabled true且默认代理为claude-code与codexdefault_agents说明该人格会被这两类编码代理加载查看调度规则.agents/rules/major-task.mdcsource of truth与同步生成的 .agents/skills/major-task/SKILL.md查看维护约束.agents/AGENTS.md 规定 SKILL.md 不可手改、需经pnpm install同步。适用前提需要说明以上机制针对的是 Plate 仓库自身的 AI 代理工作流其.agents/工具链并非platejs/*运行时包的 API对包源码没有运行时影响。七、小结product-lens-reviewer展示了 Plate 仓库用工程化方式管理 AI 评审的思路用一份 50 行出头的 prompt 文档把一个资深产品负责人先挑战前提、再评价执行的思维方式固化成可复用的五步协议用 0.50 置信度阈值压制噪音用互相咬合的 What you dont flag 边界把文档评审切分成产品、一致性、范围、可行性、对抗五个互不重叠的人格再由major-task技能按文档声明类型条件加载。对使用多 Agent 工作流的团队而言这套人格即 Skill、调度即规则、边界双向声明的做法是一个可直接参考的样板。【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
