Shopee上货前把商品资料整理成一份源表

为什么需要一份源表

多数人对上货耗时的记忆是模糊的，只记得手一直没停过。真正花时间的地方是每次不知道该填什么的那几秒停顿。这些停顿散在整批商品里，加起来往往比打字更久。它们每一次都很短，短到不觉得算耗时。把一整批记下来再看，停顿常常占掉一半以上。

停顿的来源可以归成两类，一类是找不到，一类是不确定。找不到指的是图片在哪个文件夹、尺码表存在哪里，翻一下就有。不确定指的是这一类目怎么选、那一栏要不要填，翻也翻不出答案。两类停顿的处理方式完全不同，混在一起想就会觉得无从下手。分开看之后，能提前消掉的是前一类，后一类得靠事前定口径。

上货这个动作有个特点，同一件事要重复几十遍。找到一次不等于每次都记得，做到第十件的时候早忘了第一件的图放在哪。于是同一份信息被反复寻找，同一个疑问被反复提出。源表挡掉的正是这种重复，把找一次变成一直放在眼前。它不减少总工作量，只把散开的动作收拢到一处。

有源表和没有源表的人，动作看上去差不多，都是坐着点鼠标。差别在中间那一段。没有源表的人填到一半会切出去查，查完回来已经忘了填到哪一栏。有源表的人中间不切出去，一栏接一栏往下走，注意力不被打断。一次切换看着只花十几秒，几十次加起来就不是十几秒的量级了。

还有一种损失不体现在时间上。没有源表的时候整批商品各填各的，写法会随着状态漂移。前十件认真写，后面赶时间就开始简写。同一批商品在页面上呈现出两种风格，买家看不出你赶时间，只看得出这一家不太整齐。这种不整齐在上货时是省了几分钟，在页面上要一直留着。

有一个判断自己需不需要源表的办法。挑一批已经上完的商品，回想填写过程中的每一次停顿，数一数大概有多少次。超过十次就值得建表，因为每一次停顿都要重新在脑子里定位一遍，定位本身比填写更耗注意力。次数很少说明动线已经顺，不必额外花钱。

建表这个动作还有一个不常被提到的效果，就是把隐性的规则显性化。以前整批商品为什么这么填，答案在手上、在习惯里。写进列里之后，规则变成了看得见的文字。看得见才能被质疑，也才能被改，藏在习惯里的规则既改不动也传不下去。

做法上可以这样起步，拿上一批商品当样本，把每一件从打开页面到提交完成的动作写一遍。写的时候不看平台页面，只凭记忆写，写完再对着页面补。凭记忆写出来的那部分，正是你实际依赖的路径，它比照抄页面更贴近真实的动作。

写完之后把动作归并，重复出现三次以上的动作单独成一列。归并的标准是动作，不是信息的种类。同一个动作做了三次，说明它在整批里要重复几十次，值得占一列。只出现一次的动作可以先不写进表里，等它再出现再说。

最后一步是拿这份表和上一批的实际填写对照。对照的时候会发现有些列在想象中重要、实际却一次没用上。把这类列删掉，表的可用性会明显提升。第一版源表的目标不是全，是能用，能用的表才会被继续用下去。

见过一个很典型的情形。同一批十二件饰品，图片按拍摄时间命名，填第一件的时候找到了主图，填到第六件已经记不清哪张是哪个角度，只能把之前的商品页打开对照着找。找的时候容易点错，点错之后要回退，回退又得重新定位。一整批下来，光找图这件事就重复了十几次。

这个情形里没有一处是手速问题。每一次点击都很准，也没有卡顿，时间全部花在确认哪一张是对的上面。源表在这里的作用是把图片和商品的对应关系固定下来，让确认这件事在填写之前就完成。确认放在前面是一次性的，放在中间就是十几次。

还有一个更隐蔽的损耗是判断漂移。第六件商品的属性写法和第一件不同，不是因为两个商品不同，而是因为中途查过别人的页面，顺手把人家那套写法用上了。一批商品里出现两套写法，在页面上看不出来，在后面的数据里可能也看不出来，只有对着表回看才能发现。

源表挡在这类漂移上，靠的是把取值固定在表里。填的时候照着表念，念的是同一组字符，不会因为中途看了别的页面而改口。这个效果不是来自自律，而是来自有个东西一直摆在眼前。靠记性维持一致，批次一大就守不住。

源表站在填写之前，它把填写时的难度提前消化掉

源表里要有哪几列

列怎么定，取决于这批商品在填写的时候会卡在哪里。把上一批卡过的点列出来，一个点对应一列。卡过一次的地方容易再卡第二次，因为卡住的原因不是不会填，而是信息不在手边。列定得对不对，看它能不能对上上一批真实卡过的位置。

第一类要有的列是整批取值相同的那些字段。同一个类目下的商品，很多属性取值是一致的，比如材质、适用人群、发货地。这些值写一次就能用一整批，放进源表就是让它们只被写一次。它们在表里看起来最不起眼，被用到的次数却往往最多。

第二类是要查了才知道的列。头部的价位落在什么区间、同类卖家用的是哪几个属性名、这个词近期的走势如何。这一类的值不在你手上，得从别处取回来。取回来之后放进表里，同一批甚至后面几批的同款商品就不用再取一遍。要判断一个词值不值得作为重点去写，看的是搜索端的量够不够，知虾看到的就是这一层，它给的是收窄的依据，不参与填写本身。

第三类是每件都要单独定的列，主要是名称和售价。这两列在表里不会被反复取用，每件只出现一次。它们放在源表里的意义是位置固定，写的时候不必重新决定写到哪一行。位置固定之后，写的动作就变单纯了，注意力可以全部放在内容上。

最后一类是记录来源的列。这一列写取值是从哪来的，是同类卖家的页面、是平台的规则说明、还是上一批的成稿。这一列平时用不上，出问题的时候用得上。写错一个属性要回溯它是怎么定下来的，有这一列就能查到，没有就只能凭印象猜。

整批相同的那一列怎么找，办法是把上一批商品的页面翻一遍，看哪些栏在所有商品上填的是同一个值。这类栏的效果最好，因为写一次管一整批。找的时候不要凭印象，印象里相同的东西实际常有例外，翻页面才看得出来。

要查的那一列怎么找，办法是看上一批自己在哪里开过新窗口、在哪里翻过别人的页面。开新窗口的地方基本就是要查的地方。把这几处写成一列，注明取值从哪来、什么时候取的。注明时间是因为这类取值会随时间变，去年查的价位今年不一定还成立。

单独定的那两列，写的时候建议先在表里填一个占位。占位不是正式内容，但它让这一行不是空的，填的时候不会跳过。跳过一行的位置比填错一行的位置更难找回来，因为填错还能在核对时看出来，跳过只能靠数总数才发现。

来源那一列写起来最省事，可以只用一个短标记，比如写同类页面、写平台说明、写上一批。标记的作用是回溯有方向，不需要写得很详细。写了标记之后，几个月后回头看某一件商品的属性从哪来，能有个线索去查。

列名也有讲究，建议用动作来命名而不是用字段名。写图片怎么排比写图片顺序更明确，写这一栏填什么比写属性取值更明确。动作式的列名让填的人知道自己该做什么，字段式的列名只说明这一列指什么，做起来还得自己翻译。

如果这一批的商品分属两个类目，建议不要硬塞进同一份表。两个类目的属性口径不同，硬合在一起，一半的列对另一半是空的。分开两份表各自建列，比一份表里塞两套逻辑清楚得多，也少了填错列的机会。

举一个具体的建列过程。一家做家居小件的店，上一批十八件商品，填的时候卡过四个地方。第一是材质那一栏不知道写棉还是写混纺，第二是尺寸单位到底是厘米还是英寸，第三是同类卖家的价位落在哪一段，第四是包装里的配件要不要单独列出来。这四个地方，前两个整批一样，后两个每件都不同。

于是表里长出来了四列。材质写成整批共用的一列，尺寸单位也写成共用的一列。价位这一段本批单独一列，注明是上货前取的、取的是哪个范围。配件那一列每行不同，因为有几件是带挂绳的、有几件不带。四列建完，这一批填写中途没有再为新问题停下来。

这个过程说明列不是设计出来的，是撞出来的。撞过的地方记下来，下一批就提前躲开。有人一开始就想把表设计得很完整，结果设计出来的列和实际卡点对不上，填的时候没被用上，反而增加了横向滚动的次数。

还有一类列不必写在表里，就是那些页面上的常识。比如发货地、退换政策这类每件都一样的固定项。它们可以在对照表里写一句默认值，不必占源表的列。源表的列数有限，留给会变化、会卡住的地方更划算。

被用到最多的列，通常不是最显眼的那几列

一列对应一次填写

源表的设计逻辑可以用一句话概括，一列对应页面上的一次填写。表里的列不是按信息种类分的，是按填写动作分的。同一份信息如果在页面上要填三次，表里就该有一列，填的时候从这一列读三次。反过来，三处取值永远一样的内容，在表里并成一列就够了。

分开还是合并，判断标准是这一列的取值会不会在整批里变化。会变的独立成列，因为它每次都要重新读；不会变的并进去，因为它整批只读一次。这个标准简单，用起来却能把列数控制住。多数人建表建歪，都是因为按信息种类分列，而不是按填写动作分列。

合并还有一层好处，就是改的时候只改一处。分成三列的时候，改了两列忘了第三列，页面上就会出现一处和另外两处对不上的情况。这类不一致在提交的时候不会报错，往往要等到买家来问才发现。合并之后没有第三列可以忘。

列的顺序最好和填写顺序一致。表里从左到右看过去，就是页面上从上到下填下来的顺序。顺序一致的时候，填写的人不需要在表里来回找位置，眼睛的移动路径是直线。顺序不一致的时候，每一件商品都要在表里重新定位一次，这种重新定位很消耗注意力。

还有一类容易被漏掉的填写是图片的上传顺序。主图放第几张、细节图按什么顺序排，这在上货的时候也是一次一次点上去的。如果这一批有固定的排列逻辑，它也该在源表里占一列，写成一句话的规则。规则写清楚之后，排图这件事就不再需要每次重新想。

按填写动作分列的好处，可以拿一个常见的错法来说明。有人把材质、颜色、尺寸放成三列，看着很清楚。但填写时这一类的取值往往整批一样，三列其实只需要一列的读数动作，多做两列就是多两次读的动作。分的依据搞错了，列清楚了反而更慢。

反过来，把要查的价并进一列也有问题。有人的表里只有一列写着价格，同时装着同类的价位区间和本批自己的售价。这两件事来源不同、变化节奏也不同，并在一起之后，改售价的时候会顺手把区间也改掉，改了之后判断的依据就没了。

判断能不能并，可以问自己一句话，这两个值会不会出现一个变一个不变的情况。会，就该分两列；不会，就可以并。这个问法在具体一批商品上很好用，比抽象地讨论列该怎么分更容易得出答案。

顺序上还有一个细节，把每件都要单独定的列放在最后。整批相同的列放在前面，填的时候一眼扫过去就知道哪些是照抄、哪些要现想。前面照抄的部分填得快，注意力就能留到后面那几列真正需要思考的地方。

表里的行也要能对上商品。建议每行开头加一个自己的临时编号，这个编号和平台上的商品编号不同，它只是这一批内部的序号。有了它，核对的时候说第三行有问题，大家知道指的是哪一件。没有它，只能说那个蓝色的，一说不清就得多花时间找。

用一次实际的填写来理解这件事。打开一件商品的页面，从商品名称开始往下填，名称、类目、属性、规格、图片、描述、价格。这七个位置在页面上是分开的七次动作，源表里就该有对应的位置可以读。读的位置和写的位置一一对上，填的时候就不需要回忆。

如果表里的列和页面的栏对不上，会出现一种常见的情形。填到价格那一栏，表里没有对应的列，只能回头看上一件是怎么定的。回头看的时候上一件的页面已经关了，重新打开要等加载。这一次等待在整批里会重复很多次，而且每次都要重新定位到那一栏。

对上还有一个好处是可以分工。表里有列，就可以把填写拆成几个人做，一个人填前半段，另一个人填后半段，各自读自己那几列。没有列的时候职责分不清，两个人会同时盯着同一栏反复确认，或者以为对方会填，结果漏掉一栏。

这一条也解释了为什么源表要按填写顺序排。填写是线性的，从上面走到底。表如果按信息种类排，填的人就要在两处之间来回跳。跳一次不难，跳几十次就会开始出错，出错之后回头查的成本比省下的排序时间高得多。

源表怎么和平台字段对上

对不上通常有两种表现，一种是表里有列但页面上找不到对应的栏，另一种是页面有栏但表里没有写。前一种说明列建多了或者建错了，后一种说明填写的时候还要临时去想。两种都要在第一批跑完之后回头改，改的依据是填写时的实际手感。

对齐的办法不是去背平台上有哪些栏，而是在填写的时候随手记。填到哪一栏卡了，回头就在源表上加一列。填完一整批，表的列数就自然长得和这条动线匹配。这个办法慢一点，但长出来的表是贴着实际动作的，不是照着想象画出来的。

有些栏位之间存在依赖，前一栏选了某个值，后一栏的可选项就跟着变。这类栏位在表里最好挨着放，甚至合成一列写清楚对应关系。分开放在两处的时候，填写的人容易在第二栏找不到第一栏选的那个值，然后回头去改第一栏，一来一回就多出两次动作。

平台的栏位会调整，这种情况多数人是在填的时候才发现的。发现之后当天已经改不了几十件商品的填法，只能先按旧的口径填完这一批。这一类变动值得随手记一笔，攒到下一批一起处理。记下来之后，下次调整就不会再被打个措手不及。

还有一种对不上是口径上的，不是栏位上的。同一栏在你的表里写的是概括的说法，平台上要求的是它的选项列表里的一个。这类要在表里保留平台的原话，不要自己改写。自己改写的版本看着更顺，填的时候还得再翻回页面确认一遍，反而更慢。

实际操作的时候，可以把源表的一列和页面的一栏写成一张对照表，只写一次，后面每一批都照着用。对照表不需要覆盖所有栏位，只要覆盖那些容易填错的、需要查的、容易漏的。这三类之外的部分，填的时候顺手过一遍就行。

对照表里建议标出哪些栏是必填、哪些是选填。必填的先填，把必填的全部填完再回头处理选填。这个顺序的好处是，即使中途被打断，提交的底线也已经守住了。反过来先填选填，中途一打断，必填漏了会直接卡住提交，还得回头找。

页面上的栏位有依赖关系时，对照表里要把依赖写清楚。写成一栏取值定了之后，下一栏的可选项会跟着变，具体变成什么。这一栏写着感觉琐碎，实际能省掉不少来回。不写的时候，填到下一栏才发现对不上，只能回头改上一栏。

还要留一类是页面上的必填但表里没有的栏。这类通常是自己没意识到要填的，比如重量、发货时效、退换政策。发现一次就补一列，不要当次填完就忘。发现之后不补，下一批同一件事会重新来过一遍，等于每次都交一次学费。

对齐这件事不必一次做全。每批补一点，两三批之后覆盖度就够用了。追求一次对齐完整，会因为工作量太大而拖到一直没开始，最后连第一版都没有。宁可先对齐三栏，也不要等着一张完美的对照表出现。

对齐的动作建议在第一批就跑一遍完整的。做法是拿一件商品当样本，从打开页面到提交，把每一次要填的栏位念出来，同时看源表里有没有对应的列。念到没有对应列的栏位，就在表里加一列或加一条备注。

这一遍跑完，会得到一份贴着真实页面的对照关系。它可能只有十几条，也可能有三十几条，取决于类目的复杂程度。数量不重要，重要的是每一条都是填写时真正会经过的位置。凭想象写出来的对照表，往往漏掉那些不起眼但每次都填的栏。

对照关系写下来之后，建议放在源表的同一个文件里，放在另一个页签或者另一个区块。放在分开的文件里，用的时候要同时打开两个，容易只打开其中一个。放在一起还有一个好处，改栏位的时候顺手就把对照也改了，不会走散。

不同站点的栏位名可能不一样。多站经营的时候，对照关系要按站点分开写，不要合并成一份。合并之后会遇到同一个位置在两个站叫法不同、可选值也不同，填的时候还得自己判断该用哪一套，等于把省下的判断又还回去了。

源表的维护成本

源表不是建完就完事的东西，它要跟着动线一起改。每跑完一批，总会发现有一列没用上、有一列缺了。改一次的成本不大，麻烦的是改完之后要通知所有用这份表的人。一个人做店的时候这个问题不存在，有帮手的时候就得说清楚改了什么。

维护成本里最容易被低估的是合并与拆分。一开始列分得细，用起来发现大部分时候它们取值相同，就想合并；合并之后某一批又出现了差异，只好再拆开。来回改两次，用的人就不愿意照表填了，觉得还不如凭手感快。列的稳定比列的精确更影响一份表能不能用下去。

避免反复改的办法是把觉得别扭的地方先记下来再一起改。跑三批，把三批里所有不顺手的地方攒成一张单子，一次性调整。调整之后跑一批验证，确认顺了再定下来。频繁小改的成本不在于改本身，而在于用的人要不断重新熟悉新的列。

表里还要留一栏记版本。哪一版加了什么列、哪一版合并了什么，一句话写清楚。不写版本的时候，两个人手里拿着两份不一样的源表填同一批商品，最后对起来会发现同一件商品在两处的写法不同，查起来很费劲。版本这一栏平时空着也没关系，改动的时候必须填。

维护成本要拿收益来抵。判断的办法是把填一批的时间前后比一比。建表之后如果比之前更慢，说明表里的列和实际动线没对上，要么列太多，要么顺序不对。这时候应该先减列，不要急着给表加新功能。减列比加列更能提升填写速度。

一个具体的成本估法是看每一批要花多少时间在改表上。如果改表的时间开始超过它省下来的填写时间，说明表的结构出问题了。改表的时间应该随着批次推进逐步下降，因为该改的地方前面已经改过，后面主要是照用。

还有一个隐形成本是新人上手。一份列名含糊、顺序跳跃的表，交给别人用的时候要花很长时间解释。解释的成本常常被忽略，因为一个人做的时候它不出现。表里有版本栏、列名用动作命名、顺序和填写顺序一致，这三点能让解释时间明显缩短。

表存哪里也影响维护成本。存在本地一个固定位置，用的时候直接打开，成本最低。存在几个地方各一份，很快就会分不清哪份最新，改了其中一份另一份还是旧的。同一份资料只留一个正本，其余都是副本，副本上可以标日期但不改内容。

每批做完留一个副本，命名带上批次编号。回看的时候按批次找，比按日期找更清楚，因为日期容易记混，批次编号是你自己排的。副本不需要长期保留，有价值的是最近几批，更早的可以定期清理，腾出来的注意力比空间重要。

维护的心态上，建议把表当成一直在修的草稿。它没有定稿那一版，每一批都会露出一点新的不合适。接受这一点之后，改表就不会被当成额外负担，而是当成填写这件事本身的组成部分，做起来也就顺手了。

一个可以让成本变低的习惯是改表只在新批次开始时进行。跑批的中途发现列不合适，先记在旁边，不要当场改。中途改表会让这一批商品前后两半用的不是同一套列，核对的时候自己都说不清哪件是按哪版填的。

另一个习惯是每次改动写一句话说明。改了什么、为什么改，一句话就够。这些话攒起来就是表的履历，几个月后回头看能知道某一列的来历。不写的话，回头看到一列会想不起当时为什么加它，只好再试一遍，试的过程又要花一批的时间。

表里的内容也要定期清一次。上一批的价位区间、上一批的词，留到这一批可能已经不适用。清的方式不是删掉，而是标上日期。有日期的旧值可以直接判断还能不能用，没日期的旧值只能凭感觉，凭感觉的时候人倾向于沿用，沿用错的值比没有值更危险。

如果这张表要给别人用，还要多一步。把列里的缩写和代号解释清楚，或者干脆不用代号，直接用全称。代号在一个人手里省地方，在两个人之间就是额外的沟通成本。表是拿来用的，不是拿来省版面的，能写清楚就不要压缩。

源表能吞掉的是填写，吞不掉的是取值本身

什么情况下不用源表

商品数量很少的时候，源表的收益会被成本吃掉。五六件商品一眼能看全，写在纸上或者记在脑子里就够了。这时候建一份完整的表，花的力气比省下来的还多。可以先不做，等数量涨上来再说，不必为了形式上的规范先付这份成本。

只有一种商品、而且反复上同一件的时候，表的意义也不大。整批的取值完全一样，源表就退化成一张写死的说明。这张说明当然要留着，但它更像一份备忘，不必按行按列组织成表格。表格的结构是为差异准备的，没有差异的时候结构就是空转。

偶尔试一下的类目，也不太值得为它专门建表。这类尝试本来就是短期的，跑完这一批可能就不做了。为它建一份表，用一次就废弃，成本没有回收的地方。这类可以用临时的一页纸代替，用完就丢，不必并进长期的那份表里。

反过来有两类情况即使商品少也值得建表，一类是频繁要回到旧资料上改动，另一类是要和帮手分工。这两种的共同点是资料会被反复取用，而反复取用正是源表擅长的地方。数量不是判断的标准，被取用的次数才是。同一份资料被翻的次数越多，把它集中放在一处的收益就越大。

还有一类情况是表建了也起不到作用，就是取值本身还没定。价位没想清楚、属性口径还没确认的时候建表，填进去的全是待定。这时候该先做的是把取值定下来，而不是把待定项整理得更整齐。整理待定项不会让它们变成已定项，只是把同一件没做完的事挪了个地方放。

有一个判断的简单办法，看这批商品的填写过程会不会用到上一批的东西。会用到，建表划算，因为表可以让上一批的成果留下来。完全不会用到，说明这两批之间没有可复用的部分，表的价值就只在这一批内部，收益会小很多。

还有一种情况是商品本身差异极大，比如一批里既有服饰又有电子配件。这两种商品的属性口径几乎不重叠，一份表里一半的列对另一半是空的。这种情况分开建两份小表比合并成一份大表好用，哪怕两份表加起来列数更多。

试水阶段还有一种替代方式，就是不建表，改成一次只上一两件。数量少，卡点也少，边做边想还能应付。这种方式的问题是它没法放量，一旦想从试水转成常规，还是得回到建表这一步。可以先这样过渡，但心里要清楚它是一次性的。

不建表的时候，另一样东西必须留，就是填写过程中的那一次判断结果。价位定在哪个档、这一类目用什么属性名，这些判断即使没进表，也要在某个地方留个记录。不留的话，下一批遇到同一件事会重新判断一遍，判断的结果还可能和上一次不一样。

说到底，源表是一种把过程中的判断固定下来的手段，不是仅有的一条路。一页纸、一个便签、一段语音都能起到同样作用。判断要不要上表，看的是这个动作会不会重复、重复的频率有多高。频率高的时候，结构化的载体比随手记更靠得住。

一个明确的边界是短促的补货动作。某件商品卖得好，要补几个变体，这时候上货量很小，商品之间的差异也小，靠对照上一件的页面就能填完。为这几件商品专门建表或者改表，花的时间比省下来的多，直接拿上一件当模板更快。

另一个边界是内容已经全部确认、只差提交的情形。资料在一次会议上已经统一过，图片也早就处理好，剩下的只是照着填。这种时候表的作用已经被会议记录替代了，再建一份表属于重复。会议记录和源表最好不要同时存在，两份并存时人会不知道该信哪一份。

还有一个边界是遇到平台规则的临时变化。规则刚变的时候，旧表的取值可能已经不作数，这时候应该先确认新规则，而不是急着把表更新一遍。规则没确认就更新，很可能更新出来的还是错的，白改一次，还让后来的人以为这份表是新的。

边界也要允许被推翻。原本觉得不用建表的类目，跑了几批发现卡点开始重复出现，那就该建了。判断标准一直是卡的次数，不是类目本身。同一个类目在小批量时不用表、放大之后需要表，这种情况很常见，不必觉得前后不一致。

补上要查的那几列之后，停下来查的次数降得比填写耗时更快

从少量商品开始建

起步的时候不要一次把列想全。想全的结果通常是列太多，填的时候被无关的列干扰。比较省事的做法是先建三列，把最常卡住的三个点写进去。跑一批，看这三列有没有真的让中间停下来的次数变少，再决定下一步加什么。

第一版的三列可以这样选，一列放整批相同的取值，一列放要查才知道的价，一列放每件都要单独定的名称。这三列覆盖了一整批填写里最常回头的三个地方。跑完之后往往会发现，真正被反复用的就是前两列，第三列用得最少但删不掉。

三列跑顺之后，加列要看有没有出现新的卡点。没有新卡点就不加，表越短越容易坚持。人的注意力有限，一份二十列的表填到第三批就会开始漏填，而且漏的是哪几列看不出来。一份七八列的表反而能长期用下去。

起步阶段还要防止一件事，就是把表当成成果。表建得再漂亮，它也只是为填写服务的。判断标准只有一个，拿这份表去填一批，中途停下来想事情的次数有没有变少。次数没变少，表就该改，而不是继续美化它。表是可用的工具，不是要交出去的作业。

建表的时机也不是越早越好。刚开始做店的那几批，动作本身还没定型，这时候定下来的列很快就会过时。跑过三五批，摸清自己每次都卡在哪一步，再动手建，这份表的寿命会长很多。先有动作再有表，顺序反了就会建出一份自己都不愿意填的表。

可以从一个最小版本开始，只含三列，先用五件商品试。试的时候不看结果好不好看，只看填的时候有没有比平时少切几次窗口。切窗口的次数是这件事最直观的检验标准，它直接对应被中断的次数。

五件跑完之后，把这一批里最费劲的那一步写下来。这一步就是下一列要放的内容。每跑一批加一列，加到七八列的时候通常会稳定下来。稳定之后就不必再加，加了也未必用得上，反而让表变长。

如果同一批里有几件商品特别像，可以考虑把它们并成一组处理，共用的那一列只写一次，后面注明这几件共用。这种处理能减少重复填写，代价是核对的时候要多看一眼共用标记，确认这一件确实在共用范围内。

从少量开始还有一个好处是可以试错。三列的表改起来成本很低，改错了重来也不心疼。等表长到十几列再发现方向错了，改起来就是大工程了，很多人到这一步就直接放弃不做了。小步试错让这份表能活下来。

起步阶段建议每批结束后花十分钟回头看一遍这一批用表的情况，哪一列一次没用、哪一列用了很多次。把一次没用的列标出来，连续两批都没用就删掉。删列的动作要有，只加不减的表会越来越重，最后没人愿意打开它。

最后记住一点，源表是为填写服务的，它的好坏的唯一标准是填得更顺。表本身不产出结果，产出结果是页面上线。花在表上的时间如果换来的是上线节奏更稳、整批写法更齐，这份时间就花得值。上得快只是前半段，上得值才是技巧的落点。

一个具体的起步例子。一家做手机配件的小店，第一批只上了六件。店主建了两列，一列写清适配机型，一列写清颜色分类。这两列是因为上一批填的时候在这两处反复停下来查。建完跑第二批，六件商品的填写时间比第一批短了近一半。

第二批跑完，店主加了第三列，写包装里含哪些配件。这一列是因为有买家来问，说明页面上讲得不清楚。加了这一列之后，同类问题没有再出现过。列不是坐着想出来的，是被实际发生的问题逼出来的，加得晚一点反而更准。

三列跑稳之后，店主想加第四列写关键词。加的时候拿不准该放哪些词，就去看了搜索端的量和供需关系，知虾站在上货之前这一步，给的是收窄的依据，用不用、用几个还是自己定。词定下来之后才写进表里，没有先写一堆再筛。

这个例子的顺序值得记住，先用起来，再补列，再定取值。反过来先定全套取值、再建表、再用起来的顺序，多数会卡在第一步，因为一开始根本不知道该定什么。用起来之后问题才会具体，具体的问题才有具体的答案。

最后一步是把这份表固定成常规动作。每批开始前先照表过一遍有没有要改的，改完了再动手填。这个不起眼的顺序，决定了这份表是被用下去还是被丢掉。表被丢掉通常不是因为不好用，而是因为没有固定的使用时机。

常见问题（FAQ）