critique

critique 技能概览

critique 是做什么的

critique 技能是一套评审工作流，用多个专门评审者、辩论和共识机制来评估已完成的工作。它适用于 code review 以及其他变更评审场景，尤其是在你不满足于单次判断、希望得到更充分结论的时候。

适合谁用

如果你希望 agent 在合并前评估正确性、质量以及遗漏问题，就该用 critique。它适合 reviewer、maintainer 和 builder，尤其适合那些需要结构化 critique 技能，而不是一个普通的 Code Review 提示词的人。

为什么它重要

它的核心价值在于：在不确定条件下保持一致性。不同评审者会独立检查工作、验证自己的发现，并协调分歧。这能减少流于表面的夸赞、盲点，以及单一维度的反馈。

最适合用在什么场景

这个技能最强的场景，是工作已经完成、你要做的是判断它，而不是重写它。如果你需要实现、重构或自动修复，critique 就不是合适的工具。

如何使用 critique 技能

安装 critique 技能

使用 npx skills add NeoLabHQ/context-engineering-kit --skill critique 安装。仓库路径是 plugins/reflexion/skills/critique，所以这个技能是为该 context-engineering kit 内部使用而设计的，而不是一个独立工具。

给 critique 一个明确的评审目标

critique 的使用方式在你提供具体范围时效果最好：例如改动文件、commit 范围、PR 链接，或者某个明确关注点。内置提示支持文件路径、commit 或上下文；如果你什么都不提供，它才会默认只看最近的改动。

先从正确的文件开始看

先读 SKILL.md，再检查仓库里附近的 workflow 或 metadata 文件。在这个 plugin 里没有 scripts/、references/、resources/ 或 rules/ 这类辅助文件，所以核心操作说明都写在 skill 文件本身。

用明确的 review 意图来写提示词

更强的请求会像这样：“Critique src/auth.ts 和 src/session.ts，重点看 security、回归风险和测试覆盖缺口。”而像“review this code”这种弱请求，会让评审者猜测到底哪些标准最重要，进而降低 critique guide 的价值。

critique 技能 FAQ

critique 只适合 code review 吗？

不是。它比简单的 code review 更广泛，可以评估已完成的工作、设计决策或实现质量。不过，它最适合的输出形式是 review report，而不是补丁。

critique 和普通提示词有什么区别？

普通提示词通常只会产出一个观点。critique 技能增加了结构化的多 agent 流程、独立验证和共识构建；当你重视可靠性以及不同解释之间的比较时，它会更合适。

critique 适合新手吗？

适合，只要范围足够具体。新手如果能明确写出具体文件或变更集，并要求最重要的评估标准，通常会得到更好的结果，而不是指望技能自己把所有信息都推断出来。

什么时候不该用 critique？

当你需要自动应用修改、任务非常简单，或者 review 范围太模糊、无法公平评估时，就不要用它。在这些情况下，直接写 implementation 提示词，或者走定向的 lint/test 工作流，会更快。

如何改进 critique 技能

提供更强的评审标准

质量提升最大的一步，是告诉 critique 你要优化什么：正确性、security、性能、可维护性、API 兼容性，还是测试完整性。没有这些信息，评审者可能会过度关注显而易见的问题，却忽略你真正关心的风险。

在提问前先收窄范围

如果 review 目标很大，先拆成一个 commit、一个 module，或者一个 feature slice。critique 技能在输入边界清晰时表现更好，因为讨论可以聚焦在真实权衡上，而不是把整个仓库概括一遍。

提供评审者可以核查的证据

给出相关文件路径、预期行为、约束条件，以及已知失败模式。这能帮助 critique 技能验证判断而不是猜测意图，这一点在用于 Code Review 的 critique 场景里尤其重要。

基于第一轮报告继续迭代

先用第一轮找出分歧，再针对最高风险的发现，或者证据较弱的部分请求第二次 critique。这样的迭代循环，能把 critique 技能从一次性的摘要，变成更锋利的决策辅助工具。