1. 金句：上下文是公共品，别浪费
Token 很贵，上下文是一种公共品。智能体需要的是能帮它完成任务的、尽可能小的文档单元。而这大概不是我们心目中对人「读起来舒服」的长文写法。
公共品的意思是：上下文窗口有限，塞进噪声，就挤掉别人真正需要的事实。写作者若按「越全越好」堆长文，对人可能像厚手册，对助手可能像昂贵垃圾——贵在占用，糟在截断与分心。窗口里的每一寸，都在跟真正能办事的步骤、限制、版本号抢位子。
不把「省 Token」吹成黑科技产品能力。能卖的是：拆得开、找得到、总结得短的已发布结构。省，来自结构纪律，不来自神秘压缩算法，也不来自「我们模型更省」的空洞承诺。结构纪律听起来土，却是唯一能在发布侧反复验收的东西：这一页是不是一个任务单元？限制齐不齐？能不能被单独检索命中？
国内团队常把「写全」当成责任心。责任心没错，错在把「全」理解成「塞进同一个 URL」。全，可以是体系全；喂给一次消费的，仍应是刚好办完这件事的那一块。公共品意识，是承认别人的窗口不是你们的网盘——你们没权利默认「多塞一点没关系」。
「多塞一点」在飞书收藏里几乎无成本；在助手上下文里，每一段都有机会把真正能办事的限制挤出去。成本不对称，正是公共品要被单独强调的原因：写作者感觉不到窗口变贵，消费侧却天天付账。
2. 长文对人友好，对 Agent 可能是噪音
给人扫读的长叙事、层层铺垫、章回伏笔、先讲故事再讲步骤，常常正是对 Agent 又贵又易截断的形态。公开观察里，已有约三成团队在补更小的显式块、让页面自包含——方向对准的是消费侧现实，不是反对写给人看。人可以滚动、可以回看、可以凭目录跳；助手常常一次吃一块，吃贵了还可能不自知地丢后半。
反对的不是「给人写得好读」，而是「默认把给人读的长形态，原封不动塞进机器的短窗口」。两种读者可以共用真源，不必共用同一次喂法。
国内帮助中心常见「一篇搞定」：概念、步骤、错误码、案例、注意事项、相关阅读全塞进同一 URL。人可以滚动；助手可能只吃到前半，或检索命中噪声段——命中了「活动说明」里的「导出」二字，却没命中真正的导出权限限制。你以为写得完整，机器侧却既贵又错。贵，是窗口被故事占满；错，是关键限制落在它没吃到的位置。
微内容 与知识片段 在这里不是碎片化表演，是任务完整前提下的最小可喂单元。微，是尺度；片段，是可检索、可引用的那一块事实。小，是为了省公共上下文；完整，是为了一次消费办得完。缺限制的小，是危险的短；带齐限制的小，才是公共品意识。为拆而拆的「十条半截 FAQ」，维护成本升、办事能力降，那是假节约。
再看一种国内现场：飞书里一篇万字「产品说明」，群里人人收藏，助手也接进去了。收藏很方便，检索却嘈杂——同一页里概念、营销口径、旧版步骤缠在一起。公共上下文被噪声填满时，模型不是更聪明，是更忙着在噪声里找针。
还有一种「好心办坏事」：为了怕助手漏看，把三份相近说明一起塞进上下文。「多喂一点更保险」在窗口有限时往往更糟——重复段落占位，真正的限制句被挤到后面或干脆进不了这一次消费。公共品意识要求的是挑选，不是堆叠。挑选的前提，是你们已经把可挑选的小单元发布出来。
对人友好的长文仍然可以存在；默认喂给到达层的，不应是那篇万字收藏。默认路径决定公共上下文被怎么花。
默认路径还可以更具体一点：站内搜索与 AI 客服优先命中任务型短页和 FAQ；通读型长文留给目录阅读与培训场景。同一真源，不同默认喂法——这才是在节约公共上下文，而不是在争论「还要不要写给人看」。
3. 小单元 ≠ 碎片化，是任务完整
为拆而拆会难维护。正确的小，是「一个任务所需刚好那么多」：适用场景、版本、步骤、限制、下一步。缺限制的小，是危险的短；带齐限制的小，才是对公共上下文负责。完整，指的是任务闭环，不是百科全书式完整。
拆的粒度可以用一句话验收：这一页被单独检索命中时，是否足够让人（或助手）办完或明确拒绝办理。办不完又不拒绝，就是半截单元——半截单元会浪费窗口，还会输出自信的错步骤。
提示工程 改变不了残缺事实。提示词再巧，也补不出你们没发布的权限边界；提示词再短，也救不了你们塞进窗口的万字噪声。文档侧先把单元做对，消费侧提示才有料可吃。邻近篇的 AI-Ready 总问法这里不展开；本篇只要求：长手册按版本与主题拆开，FAQ / 任务型短页优先可被检索；检索命中应落在能办事的块上，而不是落在故事段落上。
国内可执行：把万字「全能页」拆成任务页 + 概念页 + 参考表，标题像搜索词。维护成本短期上升，检索与问答的噪声会下降——那是在给公共上下文腾地方。腾地方的收益，往往先出现在客服与实施侧：更少「答了半截」、更少「点到旧活动页」、更少「助手把营销口径当规格」。
还有一条边界要讲清楚：小单元不等于禁止长文存在。长文可以给人通读、给培训用、给需要叙事的场景用；到达层优先喂的，应是可检索的任务单元。两种形态可以同源：长文由块组装，或块从长文拆出并单独发布——关键是机器侧默认吃块，而不是默认吞整本。
邻近篇会谈页如何自包含、如何对抗截断；本篇钉的是尺度伦理：别把别人的窗口当成你们的垃圾桶。AI-Ready 的总问法不在这里复述——这里只要求你们愿意把「全能页」拆开，并承认拆开是在节约公共上下文，不是在偷懒少写。
尺度伦理也可以写进评审话术：评审长页时先问「这一次消费默认会喂整页吗」。会，就继续问「噪声段能不能挪出默认路径」。问完再谈文笔。文笔服务人；默认喂法服务公共上下文。两边都要，顺序别反。
4. Baklib：拆得开、找得到、总结得短
Baklib 交付的是可检索的小而完整单元，以及只读已发布库的到达层——不是「自动帮你们省 Token」的黑盒口号。口号省不了窗口；结构才能。结构也不是一夜之间长出来：从最高频、最高风险的三问拆起，往往比「全面重构文档站」更可执行。
帮助中心 优先任务型短页与 FAQ；标题像任务，版本与限制写在页内。AI 客服 从已发布块检索再总结，而不是吞整站糊成一团；人能点回原文核对。长手册按版本与主题拆开，同源发布。不吹自动写长文，也不吹「省 Token 黑科技」——省下来的窗口，来自你们愿意把全能页拆开、把噪声挪出默认检索路径。
落地检查可以很短：这一页能否单独办完一件事？限制是否可能被截断仍留在页尾？检索标题是否像人会问的话？问答是否只读已发布库？过这四问，公共品意识就开始进发布单；不过这四问，再谈提示词优化，多半是在给噪声化妆。
从最高频三问拆起，往往比「全面重构」更像公共品实践：先让最贵、最容易答错的任务变成小而完整单元，再慢慢拆次要长文。公共品不是口号，是排期顺序。
上下文是公共品。别浪费在噪音上。小而能完成任务，才是对人和机器都诚实的写法。诚实，不是少写；是写对尺度，并把关键事实留在一次消费吃得到的地方。尺度对了，窗口才够用。
