我们发现了什么
方向观察：MaruCheck——为 AI 生成代码提供独立 QA。原文包含第三方或历史项目线索，暂不能归属于本产品，需核对完整来源。
- 来源：Hacker News（发现于 2026-09-11）
- 证据等级：D · 包含历史项目、第三方案例或未来计划；不能作为当前项目收入证据。
- 商业模式：待核验
- 主题：独立产品
- 初筛评分：22.3/100 · 收录 1 次
证据，比故事更重要。
规则清洗与初筛，未经人工商业核验。原文语境、实际客户和付费情况仍需自行验证。
引用与数字披露
来源类型（原作者自述／第三方测算／媒体转引）需采集端标注，本版尚未落字段。
- 作者
- 未标注
- 抓取日期
- 来源类型
- 未标注
- 币种
- 未标注
- 口径
- 未标注
- 披露主体
- 未标注
- 披露日期
- 未标注
中文辅助译文（全文）
HN 大家好，我一直在做 MaruCheck，一个独立、开源的 QA 验证工具，旨在解决 codex、claude、cursor 等编程智能体产生语义问题所带来的严重影响。举个例子，需求文档说免费用户可以上传 5 次，而代码把这个行为改成了 10 次。基于实现生成的测试可能就会开始预期 10 次。但 Marucheck 会把已批准的现有需求视为独立证据，并标记出这种行为变更。目前已实现的部分功能包括：质量契约（Quality contracts）、仓库与技术栈扫描、Git diff/变更影响分析、基于风险的分析、语义漂移检测、用于记录过往缺陷/回归的 QA Memory、CLI 工作流、面向编程智能体的集成、GitHub/CI 验证等等。我正在尝试的另一个方向是 QA Memory。假设六个月前出现过一个 bug——用户可以通过修改发票 ID 访问其他客户的发票——MaruCheck 能把这个回归与相关的文件/契约关联起来。如果这些区域之后再次发生变更，之前的失败就会成为新验证计划的一部分。该项目以本地优先（local-first）为原则，我尽量不无谓地重复造轮子。思路是去编排 Playwright/Vitest/security/Jest 等现有工具，而不是从零再造一套浏览器自动化框架。目前它已经发布在 NPM 上，你可以通过 npx 或 npm 运行，命令是 npx --yes marucheck@0.3.0 init，所有信息和文档都可以在网站 marucheck.dev 找到。我决定以开放的方式开发它，我对各方面的反馈都非常欢迎。
也非常欢迎贡献者——提交 issue、适配器、测试、文档、bug 报告、架构方面的批评意见，都可以。谢谢
译文由上游机器翻译生成，可能有误；判断请以英文原文为准。
英文原文（来源本站未改写）
Hi HN, I've been building MaruCheck, an independent, open-source QA verification tool aimed to solve the issues that arise when coding agents like codex, claude, cursor make semantic issues that has heavy ramifications.Take the example where the requirements says a free user gets 5 uploads.The code changes this behavior to 10.Test generated from the implementation may simply start expecting 10.But Marucheck treats the existing approved requirements as a separate evidence and flags the behavior change.
Some of the things implemented currently are Quality contracts, repository and stack scanning, Git diff/change- impact analysis, risk based analysis, semantic drift detection, QA memory for previous bugs/regression, CLI workflows, integration for coding agents, Github/CI verification etc etc..Another area I’m experimenting with is QA Memory.If six months ago a bug existed because users could access another customer’s invoice by changing an invoice ID, MaruCheck can associate that regression with the relevant files/contracts.If those areas change again later, that previous failure becomes part of the new verification plan.
The project is local-first and I’m trying not to reinvent existing testing infrastructure unnecessarily.The idea is to orchestrate tools like Playwright/Vitest/security/Jest tooling rather than build another browser automation framework from scratch.Currently it's on NPM and you can runit using npx or npm by writiing npx --yes marucheck@0.3.0 init and all the information and docs are available on the site marucheck.dev.I have decided to build it in the open and I'm especially interested in feedback on all aspects.Contributors are very welcome as well - issues, adapters, testing, docs, bug reports, architecture criticisms, all of it.Thanks
这条还缺什么证据？
下面每条都由本条已有字段推出（等级、理由、商业模式、来源次数、是否演示）， 本站不生成推测性结论；通用验证方法放在方法论页。
- 可核验的收入或付费证据查官网定价页与付费口径；第三方数据源（如 GetLatka）只作旁证，需标注来源与时点。
- 商业模式未定确认按席位／按用量／授权还是开源托管版收费；开源项目另查 LICENSE 与是否存在付费版。
- 只有单一来源找一手站点或其他渠道是否重复出现同一产品；社区热帖数量不等于商业进展。
通用验证清单（谁有这个问题／谁愿意付费／一个人能交付哪一小步）见我们的筛选方法。