把整张表塞进上下文。
能用,而且一直能用 —— 直到不能用的那一刻。注意力被摊到几千行它当下并不需要判断的数据上, 早先那些行滑出窗口,而且失败是无声的:不报错、不抛异常,只是答案开始漂。而会话一结束,这次跑批也跟着结束。
给 coding agent 的耐久数据管线
50 行时很聪明。到第 5000 行是另一回事。
你的 agent 领一小批、交上去、再领下一批 —— 管线的状态存在服务端, 不在它的上下文里,所以一次跑批能活过开它的那次会话。每一次尝试、每个模型、每次规则 改动都落在同一本账上。
115 行原始 → 62 行净表 → 租出 62 行到本地 → 提交 → 被拒 → 第 2 次尝试接着同一个批次跑,从服务端状态续上,不是重开一次 → 62 行落库 · 录制时门是开着的 ↓
会话重放 · 录于 2026-07-28claude-code + tablize skill
>
生产线 · 供应商初筛 = tablize lineage
■已是最新
3 张表
采集 ┄ 账外
源表
Supplier listings · raw
115行
append-only · 保留重复
按 url 去重
折叠 −53
加工
Supplier listings · clean
62行
首次出现的留下 · id 稳定
AI 提取
由你的 agent 执行
过程表
Supplier category
124条记录
每一次尝试都在账上
已验收版 · 镜头
■62 行已验收
claude-sonnet-4.5 · 第 2 次
过程表的一个读法 —— 不是第四张表
验收门
4 条隐藏检查样本 · 门:开
■
4/4 · 第 2 次
放行 62 ·
拦下 62 次
拦下 62 次
消费 ┄ 账外
在哪儿跑
在你自己的机器上,用你自己的模型 key。Tablize 不提供模型,也不提供运行时。
agent 一次拿多少
只有租给它的那一批,从来不是整张表。它没在处理的那些行留在服务端,所以表越长, 它的注意力也不会被摊薄。
明天会怎样
下一次会话从账上续跑 —— 未完的批次、租约、判决都在,不用靠一份聊天记录重建现场。
那道门是干什么的
没给金标,就没有门。给了金标文件,一道 agent 读不到的检查就会判每一批 —— 错一条拒整批, 而每一次拒批都留在账上。
01 / 失效模式
两条死路,和第三条出路。
能把 50 行读明白的模型,读第 5000 行一样明白 —— 变的是它读的时候手里还攥着多少跟这行无关的表。
写个脚本绕开模型。
便宜、快、可重复 —— 代价是本该由模型做的语义判断,被压成了字符串匹配。「这家公司是制造商 还是贸易商?」变成拿公司名跑正则。这时脚本成了规则的唯一表述,没人复核过它, 而它判错的那些行,长得跟判对的一模一样。
把流程固化到服务端,再把活派出去。
你的 agent 要下一批、算完、交上去、再要一批:语义判断仍然由模型做, 但它手里从来只有派给它的那几行。而且既然算力是你的 agent 出的, 包月的 coding agent 订阅就顶下了原本要按 token 付的 API 账单。
要选的从来不是「模型还是脚本」。要选的是:这套流程活在一个会遗忘的上下文 窗口里,还是活在一个不会遗忘的结构里。
02 / 为什么要一本账
记忆不是账。
这一节讲的是一次运行里,裁判、状态和理由,三样东西全住在干活的那个人身上。
提取逻辑和它的测试,是同一个作者写的。
agent 在这次会话里写了提取逻辑。某一行看起来不对的时候,同一个 agent 去调 校验器 —— 于是这批就过了。没有任何东西能拦住这件事,因为没有任何东西在 agent 之外。
上下文一消失,状态就没了。
哪些行领出去了、哪些交回来了、哪些被拒了、为什么 —— 全在一份转录里。 新会话看到的是文件和半成品,只能从蛛丝马迹里重建这次运行,而不是接着跑。
三周以后,没人答得上来。
这一行是按哪个版本的标准收的?哪个模型产出的?它之前被拒过吗? 如果答案是「翻一下聊天记录」,那就没有账,只有回忆。
如果干活的人能改裁判,你就没有一道门。你只有另一个 prompt。
03 / 受管的那一段
只管很窄的一段,并且说清每一头归谁。
Tablize 管四步,其余的一概不认领。看每个框最下面那一行 —— 它写着这一步是你的还是我们的。
原始证据
append-only 的源行 —— 一次爬取、一份导出、一个手工拼的 CSV。重复会保留: 那是关于采集的事实,不是错误。
由你或你的 agent采集 · Tablize 不去抓
agent 的尝试
你的 agent 领一个有界的批次到磁盘上,用你的模型跑你的 prompt, 然后把结果作为一个批次交回来,附上模型和 prompt hash。
跑在你的机器、你的模型 key 上 · Tablize 不提供模型
金标门
建线时不给金标,这条线就没有门:什么都不判决,行落下来标记为 未验收。给了金标,已知答案的检查样本就混进每一批 —— 期望值只存在服务端、领活时从不下发,错一条,整批被拒。
这条线配了金标之后由 Tablize 持有 · 交活的 agent 永远既读不到也批不了
结果版
不是第四张表 —— 是过程表的一个读法,显示每个源行最近的那一行。门开着时它只显示通过验收的, 被拒的尝试推不动任何东西;没有门的时候它显示落下来的行,并标记为未验收。
由 Tablize 投影 · 下游有没有真的用它,由你判断
唯一一件没有 CLI 命令的事:在开了门的边上,当检查样本是你的 agent 自己写的,这条线会以草稿状态建出来,在有人进画布把门打开之前,一行活都不往外发。 这就是上面重放里那个 403 · pending_signoff。 一个能批准自己答案的 agent,等于没被任何人检查过。 没开门的边根本走不到这个问题:它立刻开始派活,并把落下来的行标记为未验收。
04 / 那道你自己拧紧的门
行是你的 agent 产出的。谁检查过?
在你把那道检查写出来之前,没有人。这里没有一个「先关着」的开关: 拿你还没准备好写的验收样本搭起来的门是一道噪声门,而噪声门比没有门更糟。档位在建线时就定死了,所以要拧紧就意味着重建这条线: 这是一个要专门去做的动作,等这条管线值得保护了再做。老线已经产出的结果原样留着。
还没有门 —— 没有东西在检查。
账一分没少:每一批、每个模型、每一版判读标准、每个时间点都记着。缺的是那道检查 —— 没有任何东西拿结果去比对人确认过的答案,所以它们交上来就是未验收的。 这一档是第一次跑对的选择,最后一次跑错的选择。
只看不拦 —— 一批都不拦。
每一批都拿验收样本比过,分数也记下了 —— 但没有任何一批被拦住,所以结果仍然是未验收的, 哪怕这一批金标全过也一样:门不具约束力的时候,一次通过是测量,不是认证。 先用这些分数判断样本配得对不对,再让它们真的拦人。
错一条,整批被拒。
验收样本是隐藏的,而且有约束力。抽检没过就拒掉整批,连续被拒会让这条边停下来, 而不是让它空转。只有 enforce 能授予「已验收」 —— 这正是这个词到今天还值钱的 全部原因。
门是账上第一个可以拧紧的件。让管线耐久的不是它 —— 那部分在一条没有门的线上 就已经在跑了。
05 / 产品实物
去看机制本身,别看承诺。
同一次运行,在应用里的样子,录制时门是开着的(enforce) —— 也正因为这样,拒批才看得见。未修图,100% 缩放,只在每张图头写明的地方做了裁切。
A / 产线
通过验收的行,始终连着它的来源。
整条边在一张画布上:115 行原始数据、按 url 折叠掉 53 条、62 行净表、提取,以及那道门。
门那条边上的文字是产品自己的标签,不是我们写的说明: 放行 62 · 拦下 62 次。记了但没晋升,直接画在线上。
app.tablize.com · 工作区画布2026-07-28 · 100% 缩放
B / 批次账
每一次尝试都保有自己的身份。
一行就承载了一个批次的全部账:批次 id、领了多少行、隐藏检查得分、 哪个模型产出的,以及它一共被提交了几次。
下面那条状态筛条把被拒 62 和已验收 62 并排列着。 在这个产品里,被拒是一等状态,不是等着被清掉的错误日志。
过程表 · 批次与状态浅色主题 · 已裁切,不含行
C / 被拒的行
一行被拒,不等于它蒸发了。
筛到被拒,那 62 行还在 —— 公司名、模型选的分类, 以及它据以判断的那段证据文本。
这就是下一次尝试能「讲道理」而不是「猜」的原因: 你可以先读弱模型到底说了什么,再决定改什么。
过程表 · 筛到被拒浅色主题 · 裁在系统列左侧
截图来自 2026-07-28 的一台本机实例。机制、id、计数、判决和系统列都是产品自己的状态; 供应商那几行是为那次走查生成的样本数据。B、C 两张拍摄于产品的浅色主题,在两个站点主题下都照原样显示 —— 我们宁可给截图打标签,也不给证据加滤镜。这一页没有任何客户 logo,因为目前确实没有可展示的。
06 / 我该用吗?
大多数数据活儿这一整套都不需要。
一个 agent、一个下午、错了也不贵 —— 那么一个 CSV 就是正确答案, 上账本纯属额外开销。勾选真正符合你情况的那几条。
成立的条件
0/ 10
还没作答
勾选符合你实际情况的那几条。结果是一个建议, 而三个结果里有一个是「先别用」。
下一步 —— 装之前,先把下面那节边界读完。
07 / 边界
一行「落库」到底意味着什么,和不意味着什么。
这是整页最吃重的一节。一本夸大自己覆盖范围的账,比没有账更糟 —— 因为人会因此停止检查它从来就没管过的那一段。
这一段之内
Tablize 保证
标着「已验收」的行意味着它通过了当时那个版本的标准和检查样本,并且版本被记了下来。 标着未验收的行从来没被判决过 —— 标记本身会告诉你手上是哪一种。
每一次尝试、每一个批次、每个模型、每次标准变更,都有账 —— 谁、什么时候、按哪一版。
失败的尝试留着且读得到,并且永远进不了已验收版。没有门的时候没有拒批可留 —— 什么都不判决,自然什么都不会被拒。
下一次运行从服务端状态接着跑 —— 未完的批次、租约、判决都在,不需要任何转录。
这一段之外
Tablize 不保证
源数据本身是真的、是全的。源行里从来就没有的证据,在门这里补不回来。
你定义的字段就是下游真正需要的字段。Tablize 执行你的契约,但不替你发现它。
结果真的被谁用了。在我们自己第一个跑通全流程的租户那里, 136 行里有 128 行通过验收之后从来没被下游取走过 —— 连续五轮,没人察觉,而账本自始至终是准的。
你的 agent 不往 Tablize 之外写东西。它有你的机器和你的 key; 这本账管的是一段边,不是这个 agent。
08 / 怎么开始
给你的 agent 一条活得比这次对话更久的管线。
四条命令。不用注册表单,不用看一遍控制台, 也不用把一个长期有效的密钥粘进终端。
~/your-project · 安装
$ npm i -g @tablize/cli $ tablize install $ tablize login --url https://api.tablize.com $ tablize doctor
给 Claude Code / Codex 的 prompt
把 Tablize 接成这个项目 clean → extract → accept 这一段的耐久管线。要点是:流程状态存在服务端,不在你的上下文里。 1. 运行 `npm i -g @tablize/cli`,再运行 `tablize install` 把自带的 agent skill 铺下去。 2. 运行 `tablize login --url https://api.tablize.com`,然后叫我在浏览器里确认配对。 3. 运行 `tablize doctor`,把版本、skill、服务端、工作区的任何不一致修掉。 4. 读一遍这个项目,先提出原始证据的契约和提取结果的 schema,再建管线。 5. 第一次跑,提取边就建成不带金标文件的 —— 它跑在 `none` 档:不判决、行标是「未验收」。不要为了填满某个字段去编金标。 6. 按小批干活:`batch pull`、算、`batch submit`,然后再来一批。永远不要把整张表读进上下文;要续跑就读 `tablize context`,不是读这段对话。 7. 信一行数据之前,先用 `tablize transform show` 读它的 `gateMode`:只有 `enforce` 会把行标成「已验收」。档位在建线时就定死,所以要切到 `observe` 或 `enforce` 就得新建一条线 —— 等这条管线值得保护了再提,而且先问我,因为金标由我签字,不是你。 8. 绝不为了躲开一直过不去的金标,把线重建成 `none` 档。那是门在干它该干的事。 9. 明确把「采集是否完整」和「下游有没有真的用上」留在 Tablize 的保证范围之外。
为什么是浏览器配对,而不是一个填 API key 的输入框: 这里的命令由 agent 执行的次数不比人少,而 agent 没有浏览器、也没有密码。 配对让它靠一次人工点击就拿到可用凭证 —— 而这个密钥从头到尾没有出现在网页、 剪贴板或者你的 shell history 里。
实际会发生什么 · CLI 与浏览器的真实输出
终端打出一个短码,然后等着。
🔐 Sign in to tablize Opening: https://app.tablize.com/cli-login?code=… Confirm this code matches: BFTK-9QDX Waiting for approval....
此刻还什么都没授出去。没人确认的话,这个请求会自己过期。
浏览器写清是哪个客户端,以及具体授了什么。
允许这个命令行登录? 有一个命令行客户端请求连接到你的账户。 客户端 tablize CLI · your-mac · you 校验码 BFTK-9QDX 它将能做什么 读写你的数据。它不能管理成员、策略或账单, 并且不会过期 —— 想断开,随时到 个人资料 → API keys 里吊销。 [ 允许 ] [ 拒绝 ]
确认之前,你要把这个校验码和自己终端里的那个对一遍。 点拒绝不会授出任何东西,并且正在等待的终端会收到通知、停下来。
CLI 收到密钥,doctor 查三层。
$ tablize doctor
{
"summary": { "ok": 9, "warn": 0, "fail": 0 },
"message": "all three layers healthy against
https://api.tablize.com (9 ok, 0 warn) —
this verdict covers that server only",
"next": "tablize context # open tasks, recipes, rules"
}
装的和跑的是同一个吗?skill 和 CLI 对得上吗?服务端能力在线吗? 任何一项不过,回执里都带着那一条的 fix 命令, 所以 agent 可以自己修,不用回头问你。