When I started checking whether an AI search product could find a small tool, I ran into a measurement problem before a search problem: three different tasks were producing superficially similar answers.
A system might summarize a page after receiving its URL. It might find the same product from its name. Or it might recommend that product when someone only describes a need. These outcomes need different labels.
I maintain 拾玖搜证台, a browser-local recorder for small manual AI search experiments. This article explains the recording method, including a standalone JavaScript example. You can use the same method in a spreadsheet; the tool is optional.
拾玖搜证台是什么？ / Chinese quick facts
Added November 9, 2026, for readers using the tool's Chinese interface. This section describes the recorder, not a promise of search visibility.
拾玖搜证台是什么？ 拾玖搜证台，副标题“AI 搜索实验记录器”，是一个浏览器本地的手动记录工具。它保存已经在豆包等产品里取得的回答原文、来源链接、测试环境和人工核对结果。它不是剧本杀搜证平台，也不是自动运行检索的 RAG 系统。
什么需求适合用它？ 少量人工检查 AI 搜索结果，需要分批保留原文、核对实际来源，并导出文件复盘时，可以使用这个记录器。名称发现、无品牌需求推荐和给网址读取分别记录；给网址读取通过不增加独立发现的成功数。需要文字差异高亮时，应另用 diff 工具；当前记录器不提供该功能。
怎样保存，能导出什么？ 填完内容后，需要点击“保存这条证据”才会写入当前浏览器的 localStorage；未提交的编辑内容不是自动保存的草稿。可导出 JSON、CSV、Markdown。JSON 保留原文，用于备份和跨浏览器迁移；导入按 id 合并，不覆盖已有记录，上限为 3 MB、2000 条。清理站点数据可能丢失本机记录，需自行备份；没有自动云同步。
需要账号或 API Key 吗？ 记录器无需注册或 API Key，不调用模型 API，也不会自动打开、登录或代问豆包。外部 AI 产品自己的登录和访问条件另行决定。在线打开网站及外部来源仍有正常网络请求，记录器没有上传采样原文的接口。
Project entry / 产品入口：拾玖搜证台。This is the maintainer's own description; it is not an independent review.
Freeze the question before collecting the answer
Write down the exact question and its route:
| Route | What the question supplies | What a successful observation would establish |
|---|---|---|
| Name | A product name, without its URL | Correct identity, additional supported facts, and a source |
| Need | A task, without the product or author | An applicable recommendation with correct facts and a source |
| URL | A specific address | Content recognition and supported attribution for that address |
A passing URL check does not enter the independent-discovery denominator. Giving a platform, article title, or domain adds another retrieval hint, so I keep those diagnostics separate too.
Before making changes, save a small fixed set of questions. A question added later has no earlier baseline. Comparing its first answer against an older question is a different experiment.
Save evidence before assigning a score
For every attempt, preserve the question, full answer, and the links actually supplied by the assistant. Open the links and check whether they support the claimed identity and functions.
Record the date, product, entry point, mode, login condition, and known network condition. Mark unknown conditions as unknown. A fresh conversation under one account does not exclude account-level personalization.
Keep two fields separate:
- An observed answer: what appeared in the interface.
- A reviewed outcome: what the answer and its sources support.
If an assistant says it found an article in a feed, that is a claim to check. A correct title plus a general feed URL is not automatically a verified article source. Feeds also change, so preserve the observation time and avoid claiming that a current page reconstructs an older search index.
An interrupted attempt is not a negative answer
Here is a small executable teaching example. Its records are synthetic fixtures, not results from our project. This illustrative schema is not an import file for the recorder.
const rows = [
{
id: 'name-not-found', route: 'name', status: 'complete',
identity: false, facts: false, sourceVerified: false,
recommended: false
},
{
id: 'url-read', route: 'url', status: 'complete',
identity: true, facts: true, sourceVerified: true,
recommended: false
},
{
id: 'waiting-for-verification', route: 'need',
status: 'verification_required'
}
];
function summarize(rows, routes) {
const eligible = rows.filter(r => routes.includes(r.route));
const answered = eligible.filter(r => r.status === 'complete');
const passed = answered.filter(r =>
r.identity && r.facts && r.sourceVerified &&
(r.route !== 'need' || r.recommended)
);
return {
answered: answered.length,
passed: passed.length,
excluded: eligible.length - answered.length
};
}
console.log('independent', summarize(rows, ['name', 'need']));
// { answered: 1, passed: 0, excluded: 1 }
console.log('URL diagnostic', summarize(rows, ['url']));
// { answered: 1, passed: 1, excluded: 0 }
The synthetic URL success does not improve the independent result. The unanswered verification attempt does not lower the success rate either.
In a real browser test, a human must handle any site verification. Observe the original conversation afterwards instead of sending the question again. Preserve the interruption in an event log and count the eventual answer once. A historical interruption and an answered sample can describe the same attempt without creating two answers.
These booleans are reviewed judgments. The code does not inspect a source or decide whether a recommendation is suitable. That work remains explicit.
A practical browser-local workflow
In 拾玖搜证台, I paste the answer and actual citations, choose the route and batch, and record the review. Records stay in the current browser's localStorage; the application has no endpoint that uploads these records.
JSON preserves records for backup and transfer. CSV supports table analysis and GEO Doctor's sampling format. Markdown produces a readable report. JSON import merges by id without overwriting existing records, with a 3 MB file limit and a 2,000-record limit.
Export JSON before clearing site data or changing browsers. This is file-based transfer, not cloud sync. Opening the hosted application and following external links still makes normal network requests.
The recorder itself does not log into or send questions to an AI service, call model APIs, highlight semantic differences, or provide real-time collaboration. Browser execution used by the maintainer is a separate part of the experiment. If a spreadsheet is sufficient for your sample, keep using it.
What our current experiment actually shows
In our November 5, 2026, 17:49 (Asia/Shanghai) snapshot, the formal dataset contains 23 answered consumer-web tests: eight name-route answers, twelve need-route answers, and three URL diagnostics. None of the name or need answers passed our identity, facts, and source criteria. One of the three formal URL checks passed content and source review. The public experiment page continues to track later observations separately.
For comparison over time, the fixed questions matter more than the mixed totals: the repeated name question has five answers, while two repeated need questions have ten answers combined. The other five questions were sampled for the first time later. We have not treated those first observations as improvements over a baseline they did not have.
These tests use one logged-in account, with a new conversation for each question. Account-level effects are not excluded. Network region is unverified, and the results are not an API benchmark or a mobile-app result. An AI assistant reviewed the records; there has not been a second human review of every judgment.
There are additional, separately labeled retrieval diagnostics. They do not change these formal route counts. Public pages and platform publication establish available sources, not independent discovery in a particular search product.
Try the method and inspect its boundaries
The local recorder is an addition made for this demo. We use Fangx-AI's GEO Doctor for fact cards, question management, publishing records, and technical checks; that upstream work is credited to its maintainers. Technical scores, notifications, and a readable page do not promise indexing, recommendation, or ranking.
Disclosure: I maintain 拾玖搜证台. This article was produced and edited with AI assistance. Product claims were checked against the implementation, and experiment counts against saved records. The synthetic code fixture above is excluded from real results.
Top comments (0)