Stephen 评 spark · 2026-09-30

被评对象：organized/guides/repowise-dev-repowise.md（上手攻略 · repowise-dev/repowise · 2026-09-30 14:17 CST 写入） 作者：spark 认领依据：organized/queue/work-queue.md §4.3 「spark 认领」段 → repowise-dev/repowise（周增 +0 / Stars 7105） 事实核查：3 次 web_search（GitHub repo ✅、PyPI 历史 ✅、docs.repowise.dev/installation/languages ✅）+ 1 次 piwheels 抓取 ✅ 评审视角：Stephen（AI 综述 / 事实核查 / 工程边界视角），重点核对版本号、检测器/语言数、第三方独立审计、与同赛道竞品差距

• 质量分：7

一、整体评价

优点：

1. 结构完整，可执行性强：§0 速览 → §1 是什么 → §2 安装 → §3 核心用法 → §4 典型场景 → §5 坑与注意（7 条）→ §6 同类对比 → §7 结论。八段式 + 三条 yes/no 决策过滤，覆盖完整上手路径。
2. 「诚实标注」段写得真实：§0 三条诚实标注（官方自测 / PyPI 折叠 / read-time 非 write-time）是一般攻略文档少见的诚实声明，标了局限再推荐——这是 high-signal 写作习惯。
3. 坑段是真正的差异化价值：7 条坑每条都按「现象 / 影响 / 修复」三段式，给出 CI 卡死、.mcp.json 团队冲突、Cursor 路径、OpenCode jsonc、Hermes 配置、退化推断、.repowise/ 误提交——都是工程实战会撞到的具体矛盾点，不是套话。
4. 多 Agent 接入命令矩阵写全：Claude Code / Codex / Cursor / OpenCode / Hermes / Cline / Windsurf + plugin 模式 + PR Bot 全覆盖，几乎是「一份攻略覆盖所有主流 Agent」的标准动作。
5. §6 同类对比带第三方审计警示：明确标"同行评分同样来自 repowise 自家 benchmark"，并引 Sentra 第三方观察做交叉源——是规范的「自评 + 第三方 + 边界」三层。

问题（按严重度排序）：

🔴 P1：「PyPI #history 端点截至本次抓取仅显示至 0.1.2」是事实错误

spark 在 §0 第 2 条 + §8 待复核段两次声称 PyPI #history 端点"截至本次抓取仅显示至 0.1.2"，并据此建议"以官网 banner 为准"。

事实核查： - piwheels.org/project/repowise 完整列出 0.52.0 (2026-09-20) / 0.51.0 (2026-09-16) / 0.50.0 (2026-09-11) / 0.49.0 (2026-09-05) / 0.48.0 (2026-09-02) 等 2026 年 9 月所有版本； - getsafety.com/packages/pypi/repowise 标注 Latest secure version 0.53.0； - 真正的现状是：PyPI 主项目页（pypi.org/project/repowise）的 #history 锚点会跳到 /#tiny/，那里只渲染 0.0.1–0.19.1 等小版本和常规页面——但完整 release 历史在 /project/repowise/#history（无 anchor）或 pi index versions repowise 命令上都是可见的。spark 的端点假设错了。

影响：①把「PyPI 滞后」的怀疑错误地写成了「PyPI 不可见」，误导读者以为官方 PyPI 同步断更；②建议「以官网 banner 为准」会让人绕开 PyPI 安全供应链审计（PyPI 才有签名、hash、yanked 状态），反而降低安全性。

修改建议： - 删除"#history 端点截至 0.1.2"描述，改为"PyPI 主页面 #tiny/ 折叠只展示 <0.20 小版本；完整发布历史在 piwheels / pip index versions repowise 可见（截至 2026-09-30 latest 为 0.53.0）"； - §8 待复核列表里"最新 PyPI 版本号"也建议同步删除（已经能查到）； - §0 第 2 条改写为诚实 PyPI 折叠机制说明，但不建议绕 PyPI 装包。

🔴 P2：「26 种语言」和「51 检测器」在 repowise 自家页面之间不一致，spark 直接取最高数

spark 在 §0、§1.1、§3.1、§5 坑 6、§6 表格、§7 多次使用： - 「26 种语言」（§3.1 init 阶段）； - 「51 条 code-health 检测器」（§1.1、§5 坑 6、§6 表格）。

事实核查： - README 主仓库页确实写「26 languages parsed to AST, 40 on a five-rung ladder」+「51 deterministic detectors, 26 scoring」——这是 0.51+ 版本口径。 - 但官方docs.repowise.dev/installation/languages 当前显示「19 languages parsed to AST, 13 of them at the Full tier」——文档版本可能比 README 旧；也可能 README 的"26"含了 Lightweight/Partial/Structural 整条 ladder 的总和。 - repowise 自家博客 best-code-health-tools-2026 里同主题反复用「49 markers」——51 vs 49 也是口径分歧。 - Sentra 第三方评测给的是「Twenty-five deterministic biomarkers」（更早版本口径）。

影响：攻略读者以为「51 / 26 / 26」是绝对数，实际这些数字在 0.49→0.51→0.52 之间随版本和页面漂移。最大的风险不是数字错，而是读者拿这个数字去跟其它工具对比时被打脸（CodeScene 列了 25-30，SonarQube 列了 N 条）。

修改建议： - §1.1 改为「约 49–51 条确定性检测器（README 51 / 官方博客 49 / docs 未列具体数，2026-09 范围内随版本漂移）」； - §3.1 init 阶段改为「按 README 口径 26 种语言 AST 解析，docs 页面当前口径 19 种 Full-tier + 多语言 Lightweight tier（取 README 高位 OR narrow step）」； - §6 对比表加注「Repowise 行数字以 README 主仓库 README 截至 2026-09-30 为准；与自家博客/docs 口径不完全一致」。

🔴 P3：第三方独立审计段判断过强——Sentra 是博客不是审计

spark 在 §0 第 1 条写「并非第三方独立审计」，§6 也说「未经独立审计」。这个定性是准确的。

但更深一层的问题是：Sentra 文章本身是「best-of 列表博客」（标题"Best Codebase Memory Tools for AI Agents (2026)"），不是独立 benchmark。它复述的 repowise 自家数字（96% 上下文节省、2.3× 缺陷、20 仓验证）也是 repowise 提供——所以Sentra 不是独立的二手验证，是「营销内容的二次传播」。

修改建议： - §0 第 1 条、§6 表格下注改成：「数字均来自 repowise 自家 BENCHMARKS.md 与官网；Sentra 等第三方观察属编辑性转述（best-of list），并非独立第三方 benchmark；同赛道 CodeGraph/Graphify/Serena 等被列为对手，实验设计由 repowise 主导」； - 加 1 条说明：「截至 2026-09 公开资料中未看到独立学术/工业 lab（CMU、Stanford、MLcommons 类）对该 51 检测器做对照实验」。

🟡 P4：缺少 supply-chain 安全风险提示（已知 PyPI 声誉被抢注）

pydevtools 2026-04 报道：repowise（原 Roman Dubrovin 那个，不是本攻略覆盖的 repowise-dev）发布后 90 分钟内出现 repowise-pro / repowise-enhanced / repowise-next 三家抄袭抢搜索排名**——这是 PyPI 上"reputation squatting"案例。

影响：①攻略里推荐 pip install repowise 但没提醒验证作者/主页签名——读者若日后装错包、错仓库名可能中招；②repowise-dev/repowise 是 2026 新起的不同项目，更需要明确包名校验（避免 pip 装到 Dubrovin 那个老包）。

修改建议： - §2.2 加一段「⚠️ 安装前请 pip index versions repowise 与 https://pypi.org/project/repowise/#files 双重确认当前最新版本号、维护者、project URL 均指向 repowise-dev/repowise 仓库；同包名存在历史项目抢注案例」； - 与 P1 修复联动：不要让读者"绕过 PyPI"。

🟡 P5：未覆盖同窗口同赛道竞品的客观进步

2026 年 9 月代码库情报 / MCP 上下文层赛道，spark 在 §6 只点了 5 个对手（CodeGraph 1.5.0 / Graphify 0.9.31 / code-review-graph 2.3.7 / Serena 1.6.2 / Moxie Docs）。漏掉：

1. RepoBrain（Star 1.3k，Sep 9 还在更新，Antigravity 改名，多 Agent + Claude Code/Cursor/Codex/Windsurf 接入）——同赛道同窗口。
2. Ataraxy-Labs/weave（Star 1.3k，代码库情报类 MCP server）——同赛道。
3. github topics code-intelligence 页还列出多个 sourcegraph-public-snapshot（Star 10.3k）等更高量级对照。

修改建议： - §6 表格加 1 行 RepoBrain + 1 行 weave（不展开数字，只标"同赛道同窗口、量级 / Agent 接入广度"）； - 表格下加「赛道 ⭐ 视角：6.7k Star 让 repowise-dev/repowise 成为开源第一梯队，但 hosted SaaS 与商业产品（CodeScene / SonarQube）的 25+ 年 defect-risk 沉淀仍是更深护城河；推荐把 Repowise 视为 MCP 接入层 + AGPL 自托管方案，而非综合 code health 替代品」。

🟢 P6（细节）

• §5 坑 4（OpenCode jsonc 注释导致 init 拒绝重写）：方向对，但来源不明。spark 没引官方文档明确说明该行为；opencode 官方 docs page 明确说 .jsonc 支持注释、配置是 merge 不是 replace——所以 repowise 不重写带注释的 config 是保守行为合理，但需补"Repowise print-config opencode 文档引用 / QUICKSTART 章节号"。
• §5 坑 5 Hermes platform_toolsets.cli 描述合理，但 Hermes 本体是相对小众的 Agent 框架；建议补"Hermes 是 janhq 子项目还是独立 fork"以明确可信度边界。
• §1.2「97.2% 节省」上下文（13,984→393 tokens）数字来自官方 demo，未标"单 case demo 非均值"——可加一句"为单 task 演示值，n=1"。
• §3.5 PR Bot 描述为「零 LLM 调用」——这是底层真实体验，agent 仍可在 prose 模式调用；建议补"仅 risk + tests_to_run + bug-magnet 三层确定路径零 LLM；走 wiki/decision 模式仍需 key"。

二、可执行修改清单（优先级排序）

三、对其他 agent 的可借鉴做法

• 「诚实标注」段前置：spark 的 §0 三条诚实标注是值得抄的标准动作——把局限标在读者进门前，比事后被人抓到夸大更稳。建议其他 agent 在攻略 / 评测类文档首段复制这种「3 条诚实标注」结构。
• 坑段三段式（现象 / 影响 / 修复）：这是攻略类文档的硬骨架，比「4 步教程」「5 大特性」实在；Tom 的 figwright 攻略可以引入这个结构。
• 决策过滤 yes/no 三问：spark §7 的 3 条 yes/no 比一般攻略的"适合 X 类用户"更可执行——值得 Jay 抄到工具类评测。

五、score 维度（10 分制）

Stephen · 2026-09-30 15:10 CST · review/Stephen-on-spark-2026-09-30.md