17.c 起草官网条款攻略里带编号的条目，起草时该整条引用还是只取半句

本文速览 · 一图看懂

先把结论摆出来，细节都在后面各节展开，遇到具体稿子还是得对着看。

1. 条目里带「但」「除」「另有规定」这类转折或例外，整条搬，别省那半句。
2. 条目只是定义、口径、术语说明，截半句引用通常没问题，摘句控制在 25-60 字。
3. 你要的只是编号体例与行文节奏，只借结构，自己重写用词，并注明「体例参照」。
4. 任何引用都先记下版本与更新日期，编号条目跨版本变动的概率比想象中高。
5. 拿不准时按「多引半句」处理，稿子长一点比返工便宜。

先对齐概念17.c 起草官网编号条目怎么引用，先弄清「颗粒度」是什么

很多人一上来就问「整条还是半句」，其实问题问早了一步。真正要先定的是颗粒度——你打算把编号条目切到多细去用。切口越细，读起来越利落，但丢掉的条件也越多；切口越粗，安全，但稿子容易臃肿。这和切菜一个道理，切丝还是切块，得看你后面要做什么菜。

我们在17.c 起草官网的条款攻略里翻条目，习惯先看两件事：这条目是「下定义」的还是「下规矩」的。下定义的，比如术语解释、口径说明、字段含义，删掉修饰后核心意思不变，摘半句一般没问题。下规矩的，通常带条件、带例外、带责任划分，这时候截断风险就上来了。按我们的统计口径，条款攻略里大约六成条目属于前者，四成属于后者，四成里又有约七成带条件从句或例外说明——这七成就是不能随便截的那部分。

再说「引用」这个词本身。有人把「借体例」也叫引用，有人只认逐字照搬。我们内部是分开说的：逐字照搬叫原文引用，改写成自己的话但保留编号骨架叫体例参照。混着叫，后面沟通就会乱。你要是给同事留批注，最好也把这个区分写明，省得对方以为你让他照抄。

最后提一句时效。编号条目不是石碑，版本一更新，编号可能挪位置，内容也可能微调。所以任何引用动作之前，先把「这是哪一版」记在稿子边上。这件事听起来琐碎，但它能挡掉后面八成的返工。信息以官方与公开资料为准，我们不会替没有确认的版本号或更新日期编一个出来。

17.c 起草官网做法一整条搬：什么时候多抄半句反而保命

我在改稿时最怕看到一种引用：「依据某条款，应当……」后面就断了。断在哪不重要，重要的是读者不知道「应当」前面还有没有「在何种情形下」。这种半截话放出去，轻则被追问，重则被拿去当依据用错。整条搬的好处就在这里：它把前置条件、正文、例外说明一起端上桌，读者自己判断，你也不用承担截断的责任。

整条搬的代价是篇幅。一条完整条目常见在 60-140 字之间，长一点的能到 200 字。假设一篇稿子要引 5 条，整条搬就是 300-700 字，这还没算你自己的解释。如果稿子总长只有 1500 字，引文占比就冲到 40% 以上，读起来像抄书。我的经验是，引文占比控制在全文的 15%-25% 比较舒服，超过 30% 就该考虑换做法了。

具体哪些条目必须整条搬？我给你四类：一是带「但书」的，也就是「但……除外」这种结构；二是带责任划分的，比如谁承担、谁不承担；三是带时间或数量限定的，比如「自某节点起」「不超过若干」；四是带交叉指引的，比如「依另条处理」。这四类只要出现任意一类，别犹豫，整条搬。反过来，如果一个条目既没条件、也没例外、也没交叉指引，那它就是纯定义，可以让步给截半句。

有个细节值得说：整条搬不等于原文一整段照贴。你可以在引文里用省略号标出与本文无关的中间部分，但必须保留首尾的条件与结论。这种「掐头去尾保两端」的引法，在实务里比全贴更受欢迎，因为它既保住了逻辑闭环，又不占太多篇幅。前提是省略的部分确实无关，别把关键限定藏进省略号里。

做法二截半句：哪些条目适合摘句

截半句不是偷懒，是有条件的省略。判断标准很简单：你把想删的那半句遮住，剩下的话还成立吗？如果成立，且意思没跑偏，那就删；如果不成立，或者读者会误解适用范围，那就留着。这个「遮住测试」我用了好几年，比什么口诀都实用。

适合截半句的典型场景有三类。第一类是把条目当作论据来用，你只需要它证明某个常识性判断，不需要它承担全部义务。第二类是条目本身在讲工具性内容，比如字段怎么填、格式怎么排，这类条目往往前半句是「是什么」，后半句是补充说明，取前半句足够。第三类是你要在有限的篇幅里做对比，比如把三条相似条目的关键差异并列，这时每条都只取差异点，读起来才清爽。

不适合的也说说。带列举的条目尽量别截，因为列举项常常是穷尽式的，你删掉几项，读者会以为只剩这些。带程度词的条目也要小心，「原则上」「一般」「通常」这些词删掉后，语气会从软变硬，等于你替原文加了码。还有一种最隐蔽：条目里前后两个分句用了同一个词但含义不同，你只截一半，读者会按另一半的意思理解。这种我吃过亏，现在遇到就整条搬。

再补一个操作建议。摘句时把省略掉的成分用一句话交代清楚，比如「该条另有例外，此处仅引主干」。这句话很短，但能让读者知道你是有意识地截断，而不是抄漏了。同时它也让复核的人省事，不用再回头翻原文猜你到底删了什么。

17.c 起草官网做法三只借结构：不抄原文也能借来行文节奏

有些稿子压根不需要原文，它需要的是那个「编号感」。比如你要列一份内部说明，用「一、二、三」还是用「(1)(2)(3)」，用「应当」还是用「可以」，这些选择影响的是稿子的正式程度，而不是内容来源。这时候你去抄条目原文，反而别扭——原文的措辞是给条款用的，搬到说明文里会显得端着。

只借结构的做法是：看条目怎么分层、怎么用连接词、怎么处理例外，然后把这套骨架套到自己的内容上。举个例子，条目常用「在……情形下，应当……；但……除外」的结构，你写内部说明时也用这个结构，把情形和例外换成你自己的场景，一句话就立住了。这种写法在读者看来是「像条款一样清楚」，而不是「抄了条款」。

要注意的是标注。只借结构虽然不算原文引用，但如果你的稿子通篇都是条款腔，读者容易以为你在逐字引用。加一句「体例参照条款攻略，表述为本组重写」就解决了。这句话不占地方，但它把责任说清楚了，也避免后面有人拿你的稿子当原文依据。

这套做法特别适合三类稿：一是给外行看的解释稿，需要正式但不必拘泥原文；二是内部流程说明，追求可执行而非可引用；三是培训材料，需要把条款逻辑拆成可教的步骤。三类稿子的共同点是「读者要的是方法，不是出处」。反过来，如果稿子本身要接受审查、要作为依据留档，那就别只借结构，老老实实整条搬。

横向对比三种做法横向对比

把三种做法摆到一张表里，很多纠结会自己消解。下表是我们编辑组内部用的对比口径，字数区间来自近两年的改稿记录，属于经验值，不是硬标准。

看表有个窍门：先看「适合文稿」，再看「逻辑完整性」。如果你的稿子属于依据类，那逻辑完整性必须是高，其他列都可以让步；如果属于解释类，那篇幅压力更重要，宁可只借结构。中间那档最难判断，通常出现在论据类稿子里——你既要它当论据，又不想它占太多地方，这时候用截半句加一句说明，往往是最优解。

还有一点别忽略：三种做法可以混用。一篇稿子里，核心论点处整条搬，辅助论据处截半句，方法说明处只借结构，这样既保住了关键逻辑，又控住了篇幅。我们实际改稿时，一篇 3000 字左右的文章里通常会混用两到三种做法，很少从头到尾只用一种。

字数与区间17.c 起草官网条款攻略摘句，字数与区间怎么拿捏

摘句的字数不是越短越好。太短，信息不够，读者还得回头翻；太长，等于整条搬，不如直接引全。我们的经验区间是 25-60 字，落在这一段里，摘句通常既保留了主干，又不会显得拖沓。低于 20 字的摘句，我们内部叫「断句」，只适合做小标题或提示语，不适合当依据。

为什么下限是 25 字而不是 10 字？因为中文条款的主干往往包含「主体 + 情形 + 动作」三要素，这三要素写全，基本就 20 字往上了。你压到 10 字以内，通常只剩「动作」，主体和情形都得靠读者脑补，这就是误读的起点。上限 60 字则和阅读节奏有关：一段引文超过 60 字，读者会开始跳读，引文的警示作用就没了。

再说引文占比。一篇稿子的引文总量，我一般控制在 15%-25%。这个区间有两个好处：一是读起来不像抄书，二是留给自己的分析空间够。假如一篇 3000 字的稿子，引文 600-750 字，剩下 2250-2400 字是你的解读，比例就比较健康。如果引文占比冲到 35% 以上，读者会觉得你在堆料，停留时间反而下降——这个结论来自我们自己的内容观察，不是平台数据。

还有个小技巧：把多条摘句排在一起时，尽量让每条的字数接近，视觉上会整齐很多。比如三条摘句分别是 28 字、31 字、26 字，排出来就舒服；如果一条 55 字、一条 18 字，版面就会跳。这个细节不影响内容，但影响阅读体验，值得花两分钟调一调。

判断四步17.c 起草官网条款引用颗粒度，判断的四步法

前面讲的是原则，这里给一套能直接上手的四步法。我改稿时基本按这个顺序过一遍，多数情况下能在一两分钟内定下颗粒度。

1. 第一步：看条目有没有「例外」出现「但」「除」「另有规定」这类词，直接整条搬，不再往下判断。
2. 第二步：看条目是不是纯定义如果删掉修饰后意思不变，进入截半句候选；如果删掉后适用范围变宽或变窄，退回整条搬。
3. 第三步：看稿子要不要原文如果只需要体例节奏，转只借结构；如果需要原文当依据，留在前两种做法里选。
4. 第四步：做遮住测试把准备删的部分遮住，读剩下的句子，读得通且不误导，就删；读不通或会误导，就留。

这四步的关键在第一步和第四步。第一步是硬筛，能挡掉大部分风险；第四步是软校，能救回被误判的条目。中间两步更多是效率工具，帮你快速分类，省得每条都纠结半天。

有个例外情况要说明：如果条目本身极短，比如只有二十来个字，而且没有例外结构，那它其实整条就是一句话，整条搬和截半句没区别，直接照抄即可，不用套流程。流程是给长条目用的，短条目别自己给自己加戏。

另外，四步法不是一次性的。稿子改到第三稿，引文可能被挪了位置、被合并、被拆分，这时候要重跑一遍。我们内部规定，凡是对引文做过结构性调整的稿子，都要重过四步法，避免改着改着把条件改没了。

17.c 起草官网排查常见的四种误用与排查

误用一：把「原则上」删掉。这个词看着软，其实是限定适用范围的关键。删掉后，条目的约束力从「有例外」变成「一律」，等于你替原文加码。排查办法很简单，搜一下你稿子里的引文，看看原文有没有程度词，有就补回去。

误用二：把列举项截成「等」。原文列了五项，你引三项加个「等」，读者会以为还有别的没列，实际可能就是这五项。这种截法在实务里最容易被抓，因为对照原文一眼就能看出来。遇到列举，要么全引，要么改写成「包括但不限于」并说明是概括，别用「等」蒙过去。

误用三：把交叉指引当成结论。有些条目写「依另条处理」，你只引这半句，读者会以为结论就在这里，实际得跳过去看那条。这种情况必须整条搬，并在引文后补一句「具体处理另见相关条目」，把路标立好。

误用四：把不同版本的条目混着引。这个最隐蔽，因为两条单看都对，放一起才打架。排查办法是给你的每条引文标注版本与日期，排在一起时扫一眼，版本不一致就重核。我们组内现在要求所有引文都带一个括号注，写清出处版本，虽然啰嗦，但省了后面无数解释。

四种误用里，前两种靠自查就能发现，后两种得靠交叉核对。我给的建议是：单人作业时至少隔一天再回看引文部分，隔夜之后你对原文的记忆会淡，反而更容易发现截断问题；多人协作时，让没参与初稿的人专门核一遍引文，效果更好。

版本协同17.c 起草官网版本改动后，编号条目怎么重核

编号条目最麻烦的地方不在引用那一刻，而在版本更新之后。你已经引完、稿子已发，结果新版本里那条编号挪了位，或者内容微调了。这时候要不要回头改？我的判断是：看改动是否影响判断结论。如果只是措辞润色，结论没变，可以不动；如果条件、例外、时限有任何一处变化，必须回头改，并在文末加一句修订说明。

重核的顺序建议从粗到细。先扫一遍你引过的所有编号，看编号本身还在不在；再看编号对应的内容有没有变；最后看这些变化是否影响你稿子里的论证链。三步走完，多数情况十几分钟能搞定。如果稿子引了十条以上，建议做个简表，左边写原编号，右边写新编号，中间写变化类型，一目了然。

还有一个常被忽略的点：版本更新有时会新增条目，而新条目可能正好和你稿子里的判断相关。所以重核不只是核对旧的，还要扫一眼新增的部分。我们的习惯是每次版本更新后，把新增条目快速过一遍，看看有没有需要补充进稿子的内容。这个动作花不了多少时间，但能让稿子保持新鲜。

至于多久重核一次，得看你的稿子寿命。短期稿子，比如一周内就过时的资讯，重核一次足够；长期稿子，比如常驻的攻略页，建议每个版本周期跟一次。我们自己的节奏是跟着版本评测栏目的更新走，那边更新了，这边就顺手核一遍，两个栏目互相咬合，省得另设提醒。

工作流编辑组的工作流：我们实际怎么改稿

说说我们组的实际做法，可能比抽象原则更好用。一篇稿子进来，先由初稿人标出所有引文位置，用不同颜色区分「整条搬」和「截半句」。这一步不判断对错，只做标记，目的是让引文显形——很多问题是在标记过程中自己冒出来的。

标记完，第二个人做交叉核对，重点看两件事：一是被截的条目有没有丢条件，二是引文的版本标注全不全。这一步通常花二十分钟到半小时，视稿子长度而定。核对人不需要重写，只需要在有问题的地方留批注，写明「建议整条搬」或「此处可截半句」。

第三个人做通读，这次不看引文对错，只看行文节奏。因为前两步已经把准确性守住了，第三步要解决的是「读起来顺不顺」。通读时常会发现某些引文太长、某些摘句太碎，这时候做的是增删调整，而不是准确性返工。三步下来，一篇三千字的稿子大概需要两到三个小时，比一个人从头改到尾要稳。

多人协作的代价是会引入风格差异。三个人改出来的稿子，引文处理方式可能不统一。我们的解决办法是维护一份内部口径清单，把「哪类条目整条搬、哪类可截半句」写成几条硬规则，新人照着做就行。清单不长，一页纸，但省了很多来回解释。

操作清单17.c 起草官网编号条目怎么引用，几条操作清单

把前面的内容压成一份清单，改稿时可以直接对着过。清单不长，但每一条都是从返工里换来的。

• 先定版本，再动笔。引文边上写清出处版本与日期，一句括号注就够。
• 有例外、责任、时限、交叉指引的条目，整条搬，不做截断尝试。
• 纯定义类条目可截半句，摘句控制在 25-60 字，删掉的部分用一句话交代。
• 只需体例时只借结构，重写用词，标「体例参照」，不冒称原文引用。
• 全篇引文占比控制在 15%-25%，超过 30% 就该考虑换做法或删减。
• 列举项不截、程度词不删、交叉指引不省略，这三条是红线。
• 改到第三稿时重跑一遍四步法，结构动过就必须重核。
• 版本更新后，先核编号在不在，再核内容变没变，最后核论证链受不受影响。

这份清单的本质是把判断前置。多数返工不是因为不会判断，而是因为没在合适的时候判断。清单逼你在动笔前、改稿中、定稿前各过一遍，把问题挡在发布之前。

如果你所在的团队人多，建议把清单做成稿子模板的一部分，附在开头，谁接手都能看见。我们试过把清单放在内部文档里，结果没人翻；改成附在模板开头后，使用率明显上来了。工具放在手边才有人用，这个道理放在哪都成立。

17.c 起草官网编辑态度关于边界：哪些我们不做

最后说点编辑态度上的事。我们整理条款攻略、写这类方法论文章，有一条自我约束：信息以官方与公开资料为准，没确认的版本号、更新时间、具体数量不臆造，宁可留空也不猜一个填上。这条约束看着保守，但它让稿子经得起回头核对。

同样地，我们不提供任何未授权资源的获取入口，也不替读者判断某个具体做法「一定没问题」。条款怎么用、引用到什么程度，最终得由使用场景和审查口径决定，我们能做的是把判断方法和边界讲清楚，把选择权交回给读者。

还有一点关于数据。文中的字数区间、比例区间、引文占比，都是我们编辑组的经验口径，不是平台统计，也不是行业标准。写出来是为了让判断有个参照，不是让你当硬指标去卡。真实改稿时，还是得看具体条目和具体稿子，灵活处理。

说这些不是要显得谨慎，而是这类工作本来就需要一点克制。条款是拿来用的，引用是拿来说清楚的，两者之间隔着一层判断。把判断讲透，比给一个标准答案更有用。

问答常见问题解答

延伸阅读相关文章

• 17.c 起草官网资讯栏和条款攻略撞车时，哪边先看能少走弯路先看哪栏不白费工夫，顺序一换省下大半天。
• 17.c 起草官网资讯栏里的旧答复，过了几个月还能照着做吗时效怎么判，几个信号帮你下决定。
• 17.c 起草官网条款攻略和资讯栏同时开两个标签页，怎么摆才不混乱屏幕怎么分，眼睛才不用来回找。
• 17.c 起草官网版本评测的末尾附注，起草人该怎么读才不白翻附注常被跳过，恰恰藏着关键改动。
• 17.c 起草官网的条款攻略按文档类型分堆读，实务里怎么归类最省事按类型分堆，翻找时间明显缩短。
• 17.c 起草官网版本评测更新到10月底，起草人该盯哪几个变化点几个重点栏位，扫一眼就够。

17.c 起草官网标签索引多维标签索引墙

按三个维度分层找内容：先看主题方向，再按更新节奏，最后按阅读深度。三层交叉，基本能找到你要的那篇。

谁在写编辑组里都是些什么人

拾柒号草案馆的人不多，一个条款攻略组、一个资讯组、一个版本核对组，加起来十来个人。平时各管一摊，遇到引用颗粒度这类跨栏目问题就凑一起改稿。放几张卡片，认识一下常写这类文章的人。

• 

  程疏桐

  资讯栏目记者

  条款攻略引用颗粒度
• 

  周砚秋

  版本核对组

  版本评测编号核对
• 

  林见鹿

  条款攻略组

  条款语气摘句

以上成员为本站编辑角色设定，虚拟角色，不代表真实履历。

上述数字仅描述本站内容口径与编辑规范，不代表真实用户量、访问量、排名或第三方背书。

17.c 起草官网写这篇的人关于作者

程疏桐

资讯栏目记者

在拾柒号草案馆负责资讯栏目，常年跟条款攻略与版本变动的衔接问题打交道。相信把判断讲透比给标准答案更有用，写稿时习惯先问「这条能不能截」，再动笔。

读者说读者评论

• 
  老周改稿2026-11-01

  整条搬还是截半句这个纠结我也有过，按你文中说的「先看条件从句在不在」去试，改稿返工明显少了。

• 
  荔湾小陈2026-11-01

  只借结构那条以前没想过，把编号体例借过来但话自己写，确实比硬抄一句更自然。

• 
  纸边茶2026-11-01

  希望后面能补一篇讲编号条目跨版本变动怎么标注的，摘句最怕版本对不上。

• 
  夜航起草2026-11-01

  对比表那几列很实用，尤其是整条搬的字数区间，我按这个估稿子篇幅省了不少来回。