archify-review 是什么？
archify-review 是 tt-a1i/archify 仓库内置的 Agent Skill，文件路径为 .agents/skills/archify-review/SKILL.md [citation:1][citation:9]。它的官方描述是：“Review Archify issues, PRs, or code through value, cost, and impact to support evidence-based maintenance decisions. Use for issue triage, change reviews, and code quality assessments.” [citation:1]
它和 Archify 主技能（生成可交互架构图）是同一仓库中的两个独立技能。archify-review 不渲染图、不写 JSON、不产出 HTML。它的工作对象是变更本身——一个 issue 是否值得处理，一个 PR 的方案是否合理，一段代码是否值得引入新的耦合。
值得注意的是，根据仓库的测试记录，archify-review 被标记为“贡献者内部技能”（contributor review skill is internal），不会在未过滤的消费者安装中默认提供 [citation:6]。它主要面向 Archify 仓库的维护者和贡献者，用于审查该仓库自身的 issue、PR 和代码质量。
archify-review 的主要功能
三维评审框架。Skill 的核心是一个固定的三个维度 [citation:1][citation:2]：
| 维度 | 核心问题 | 考察内容 |
|---|---|---|
| Value（价值） | 这个问题值得现在解决吗？ | 真实问题是什么、谁受益、发生频率、后果严重性 |
| Cost（成本） | 这个方案的代价是什么？ | 实现和验证工作量、未来理解/修改/维护成本；优先使用现有能力，方案与问题成比例 |
| Impact（影响） | 这个变更会波及什么？ | 受影响的行为和模块、对用户和未来开发的影响、是否改善可维护性还是增加耦合和约束 |
证据锚定纪律。Skill 明确要求所有判断必须基于证据：验证目标修订版本和相关事实，区分直接验证、已有证据和假设，选择能解决关键不确定性的检查 [citation:1][citation:9]。
输出要求。必须解释：工作是否值得做、方案的成本和影响、是否有更好的替代方案、以及影响决策的未解决问题。理由要充分，细节程度与每个关注点的重要性成比例 [citation:1]。
archify-review 的核心特色
评审的是“决策”，不是“代码”。大多数 code review 工具检查的是语法、风格、bug。archify-review 检查的是决策质量：这个变更有没有解决真实问题？有没有更小的方案？引入的维护负担是否合理？它的输出不是“LGTM”，而是“值不值得做，为什么”。
仓库特定的评审流程。Skill 会引用仓库根目录的 REVIEWING.md 和 CONTRIBUTING.md，获取该仓库特定的评审和贡献要求 [citation:1][citation:5]。这意味着它不是通用评审模板，而是嵌入了 Archify 仓库自身的治理规则。
“内部技能”的定位。archify-review 被设计为贡献者内部使用的技能，不会进入普通用户的安装流程 [citation:6]。它的引用路径包含 ../../../REVIEWING.md 和 ../../../CONTRIBUTING.md，说明它预期在仓库的完整上下文中运行，而非作为独立发布的消费级 Skill。
archify-review 可以用来做什么？
Issue 分级（Triage）。当一个 issue 被提出时，用三维框架判断它值不值得现在处理、有没有更简单的替代方案、会波及什么。
PR 评审。对一个 pull request 做变更评审，重点不是代码风格，而是方案决策：它是否解决了真实问题、成本和影响是否成比例、是否引入了不必要的耦合 [citation:5]。
代码质量评估。对一段代码或一个模块做维护性审查，判断它是否值得继续维护、是否应该重构或替换。
不适合的场景：生成架构图（用 archify 主技能）、代码格式化、lint 检查、自动化测试运行。这些是工具的工作，不是评审框架的工作。
archify-review 适合哪些人？
- Archify 仓库的维护者和贡献者：这是 Skill 的首要受众。它嵌入仓库自身的 REVIEWING.md 和 CONTRIBUTING.md 规则。
- 需要结构化评审框架的团队：三维框架本身是通用的，可以借鉴到其他项目的评审流程中。
- 用 AI Agent 做 issue/PR 分级的开发者：如果 Agent 支持 SKILL.md 格式，可以手动复制这个 Skill 到自己的技能目录中使用。
不太适合：需要通用 code review 工具的普通开发者（archify-review 是仓库特定的）、不需要“该不该做”决策的场景、以及期待 Skill 直接修复代码的人。
archify-review 如何安装？
archify-review 是贡献者内部技能，不通过常规的消费者安装流程提供 [citation:6]。但如果你需要手动使用它，可以按以下方式获取：
方式一：克隆仓库后复制（手动）
git clone --depth 1 https://github.com/tt-a1i/archify.git /tmp/archify
mkdir -p .claude/skills
cp -r /tmp/archify/.agents/skills/archify-review .claude/skills/archify-review复制后重启 Claude Code 以加载新技能 [citation:2]。
方式二：通过 skills CLI（如果可用）
部分第三方导航站提供了安装命令，但需注意这可能绕过仓库对“内部技能”的过滤 [citation:4][citation:7]：
npx skills add tt-a1i/archify --skill archify-review注意：archify-review 引用了仓库根目录的 REVIEWING.md 和 CONTRIBUTING.md。如果你不在 Archify 仓库的上下文中运行它，这些引用可能无法解析。它的完整功能依赖于仓库的特定治理文件 [citation:1][citation:6]。
archify-review 怎么使用？
基本流程（对维护者而言）：
- 确定要评审的目标：一个 issue、一个 PR、或一段代码。
- 记录当前 main/base 版本和候选 head 版本 [citation:5]。
- 阅读链接的 issue 或约定范围，在可行的情况下检查当前 main 的行为 [citation:5]。
- 用三维框架分析：Value（真实问题、受益人、频率、后果）、Cost（实现/验证工作量、未来维护成本）、Impact（受影响的行为和模块、对用户和未来开发的影响）[citation:1]。
- 锚定证据：区分直接验证和已有证据，选择能解决关键不确定性的检查 [citation:1]。
- 输出判断：值不值得做、方案的成本和影响、替代方案、未解决问题 [citation:1]。
触发场景：Issue triage、Change reviews、Code quality assessments [citation:1][citation:7]。
archify-review 使用技巧
先问“值不值得”，再问“怎么做”。Skill 的核心逻辑是：如果一个问题不值得现在解决，那么再漂亮的方案也是浪费。三维框架中 Value 是第一位，Cost 和 Impact 是后续判断。
区分“直接验证”和“已有证据”。Skill 明确要求这种区分 [citation:1]。直接验证是你亲自运行测试、检查代码得到的事实；已有证据是别人提供的结果；假设是你推断的。评审结论的可信度取决于你能否清楚标记这三者的边界。
优先考虑现有能力。Cost 维度中有一条明确指导：“Prefer existing capabilities and keep the solution proportional to the problem” [citation:1]。在评审 PR 时，先问“现有功能能不能解决”，再问“需不需要新增代码”。
把“未解决问题”写出来。Skill 要求输出中必须包含“unresolved questions that matter to the decision” [citation:1]。这比给出一个假装确定的结论更有价值。
archify-review 收费吗？
免费且开源。archify-review 是 tt-a1i/archify 仓库的一部分，采用 MIT 许可证 [citation:1][citation:13]。Skill 本身不收取费用。Archify 项目整体也是开源免费的，官方明确说明“Archify 开源免费” [citation:17]。
archify-review 的优点与缺点
| 维度 | 优点 | 缺点 |
|---|---|---|
| 决策导向 | 评审的是“该不该做”和“值不值得维护”，而非代码风格 | 不是通用 code review 工具，不检查语法或 bug |
| 框架清晰 | 价值/成本/影响三维度提供结构化的评审语言 | 框架本身不执行自动化检查，依赖评审者的判断 |
| 证据纪律 | 强制区分直接验证、已有证据和假设，减少臆断 | 证据锚定需要额外工作，可能增加评审时间 |
| 仓库特定 | 嵌入 REVIEWING.md 和 CONTRIBUTING.md，与仓库治理规则一致 | 作为“内部技能”，通用性有限；离开仓库上下文后引用可能失效 |
| 定位克制 | 不试图替代工具，只做评审决策框架 | 不提供自动化修复或建议，需要评审者自己执行 |
archify-review 与同类工具对比
vs 通用 Code Review 工具（CodeRabbit、GitHub Copilot PR Review）。这些工具检查代码质量、风格、潜在 bug，输出的是“代码问题清单”。archify-review 检查的是决策质量，输出的是“值不值得做、方案是否合理”。两者互补：工具检查“做得好不好”，archify-review 检查“该不该做”。
vs 通用“act as a code reviewer”提示词。通用提示词没有固定的评审框架，输出随机且不一致。archify-review 提供了明确的三维度框架和证据锚定纪律，输出更结构化、更可重复。
vs 项目自己的 CONTRIBUTING.md。CONTRIBUTING.md 定义了贡献规则，但它是静态文档，需要人工阅读和解释。archify-review 把这个规则转化为 Agent 可执行的评审流程，自动引用相关的治理文件 [citation:1][citation:5]。
archify-review 常见问题 FAQ
Q：archify-review 和 archify 主技能有什么区别？
archify 主技能负责生成可交互架构图（从描述或仓库出发，输出 HTML/JSON）。archify-review 负责评审 Archify 仓库的 issue、PR 和代码质量。两者是同一仓库中的不同技能，用途完全不同。
Q：我是普通用户，能安装 archify-review 吗？
技术上可以手动复制 SKILL.md，但它被设计为贡献者内部技能 [citation:6]，并且引用了仓库根目录的 REVIEWING.md 和 CONTRIBUTING.md。离开 Archify 仓库上下文后，这些引用可能无法解析。
Q：它会自动帮我修代码吗？
不会。archify-review 是评审框架，不是修复工具。它输出的是判断和理由，不是代码变更。
Q：三维框架可以用于其他项目吗？
可以借鉴。价值/成本/影响是一个通用的评审框架，不限于 Archify。但 Skill 本身的实现与 Archify 仓库的治理文件绑定。
Q：为什么它强调“证据”？
因为评审决策最容易出错的地方是把假设当事实。Skill 要求明确区分直接验证（你亲自做的检查）、已有证据（别人提供的结果）和假设（你的推断）[citation:1]。
archify-review 综合评价
archify-review 解决的是一个评审定位问题：大多数 review 工具关心“代码写得好不好”，但一个变更最大的浪费不是写得差，而是不值得写。archify-review 的价值在于它把评审的第一问从“代码有没有问题”扭转为“这个问题值不值得解决”。
它的三维框架——价值、成本、影响——本身不复杂，但它在 Agent Skill 中嵌入了两个关键纪律：证据锚定（区分事实、证据和假设）和成比例（方案不能比问题更复杂）。这两个纪律让评审输出从“我觉得”变成“有依据的判断”。
它的局限在于它是一个内部工具。它绑定 Archify 仓库的治理文件，面向该仓库的贡献者。对于外部用户，它的价值更多在于框架的借鉴意义：价值/成本/影响的三维评审语言，以及“先问值不值得”的评审哲学，可以迁移到任何项目的维护决策中。
对于 Archify 仓库的维护者，archify-review 提供了结构化的评审流程。对于其他项目的评审者，它的框架值得参考，但不要期待它作为一个通用工具直接使用。它的本质是一套评审纪律的 Agent 实现，而非一个即插即用的评审产品。
◯ 评论 0