1. 换口吻：写作 = 喂上下文，不是填栏目
多数技术作者的周报，还是按栏目写的。
帮助中心缺「导出报表」就补一页；开发者文档缺错误码就补一张表；产品改了默认超时，再在飞书里开一篇「本周变更说明」。写完、挂上、打勾——这一套在「给人读」的时代说得通。
现在多了一层读者，而且它不翻目录。
实施同事把帮助中心丢进内部助手；客户在 IDE 里问编码助手「这个 webhook 失败怎么重试」；售前把文档站某一节贴进方案书，客户侧的机器人再总结一遍。同一份事实被拆、被截、被转述，却仍然要在下一步操作上站得住。
行业公开调研里，真正把整篇文档完全交给 AI 写的人并不多——大约四分之一。更多人用它起草、校对、对风格。杠杆往往不在「谁写得更快」，而在语料本身：自不自洽、有没有版本、发没发到对外库。有人把「智能体答错」说成另一件事：它其实在饿，缺的是上下文——本篇不展开那套治理长论，只落到作者桌上：你喂了什么。
所谓提示工程，通俗讲就是怎么把问题说清楚、把约束写进提示，让模型少跑偏。对文档作者来说，比再精修一条系统提示更管用的，常常是把可被检索的事实页写扎实——提示再巧，抽到的若是过期碎片，答案仍会飘。
对作者来说，这不是要你改成「提示词工程师」。是换问法：这页写完之后，机器下次抽到它，能不能单独成立？还是必须先读完左边三章、再翻飞书群里那条口述？
栏目还是要填。填完之后多问一句——你喂出去的，是一口能咽的粮，还是一堆要靠人脑拼接的碎片。
2. Agent 读的是你发出去的那一版
人还能问「这篇是不是旧的」。
智能体通常不问。它吃到什么，就按什么答。
常见翻车长这样：产品上周把「免费席位」改成了「试用席位」，官网文案改了，帮助中心还停在旧名；客服在企微群里已经按新说法答了三天。某天客户侧助手从帮助中心抽了一段旧文，信誓旦旦说「点免费席位即可」。实施按这句话走，现场对不上现网——锅很少记在「语料没发布」头上，多半记成「AI 不靠谱」或「你们产品忽悠人」。
另一类更隐蔽。作者在飞书里写了一版「最终说明」，群里点了赞，却从未点发布。站内 AI 智能搜索——按已发布内容检索再给出答案的那一层能力——对外帮助中心、伙伴拿到的 PDF，各自还在吃上一版。人以为「大家心里有数」，机器只认它够得着的那份 URL 和那份已审核正文。
所以对作者最狠、也最有用的纪律其实很土：
Agent 读的不是你脑子里的最新认知，也不是群聊里的共识，而是你点过发布、进过对外库的那一版。
草稿可以很精彩。未发布的精彩，对智能体等于不存在——或者更糟，它去抓公网常识、抓竞品文档、抓去年的镜像站，拼出一个听起来很圆的答案。
这里还有一层内容复用：同一段参数说明、同一张错误码表，应能从真源发出去，而不是在飞书、方案书、帮助页各抄一版。抄多了，你自己都分不清哪次改漏了；助手更分不清，只会把抄散的几份一起采进总结。
3. 什么页喂得进去
不是每一页都适合当口粮。机器友好的页，通常长得不像「章节小说」，更像能独立打开的任务卡。
自包含。打开这一页，目标读者（人或助手）不必先读完「总则」才能动手。前置条件、操作步骤、失败时会看到什么、相关接口或设置项叫什么，尽量写在同一页或明确链到固定锚点。少写「如上所述」「见上文」——上文对爬虫和截断窗口来说，常常等于没有。
有版本。标题或元数据里能看出现网对应哪一版产品；废弃步骤标清楚，别让 2023 年的截图和 2026 年的按钮名混在一篇「活文档」里假装同步。多产品线更要分开：SaaS 标准版和私有化交付若共用一个模糊栏目，助手会把两套限制搅成一套。
已审核。对外库只收过审内容。未过审的「可能正确」草稿，人可以在飞书里讨论；放进会被检索的发布面，就等于授权机器对外说话。国内现场里，最容易踩的坑是：群文件里那份
手册_最终_可用.pdf 人人转发，正式帮助中心却没人改——助手若只连了正式站，答的是旧的；若误连了网盘镜像，又可能答到半成品。另外还有粒度。给人扫读的长篇「从入门到精通」仍然有用；给 Agent 用的单元，往往要再切一刀。所谓知识片段，就是把一段能单独成立的事实——一个错误码、一个配置项、一个任务步骤——从长文里拆成可检索、可复用的块。切太碎会难维护，切太粗会被静默截断——「对人好」和「对机器好」怎么折中，邻近篇会写。这里只先认：你今天发出去的每一页，都在决定明天助手抽到什么。
上午销售在方案里引用了「Webhook 重试三次」；下午研发把默认改成五次，只在企微发版群刷了一句；晚上客户助手仍从帮助中心旧页答「三次」。没有人故意撒谎，只是写进对外库的那一版，没人认领更新。作者若仍只按「栏目有没有空格子」交差，喂出去的就会一直是过期口粮。
4. Baklib：资源→知识→Help/Docs/Chat，写作即喂已发布上下文
Baklib 不把作者的工作重新包装成「每天多写十篇」。我们更常说的是一条发布链。
资源库收截图、视频、品牌包和对外发过的文件，避免素材满天飞。知识库里，口径、手册、帮助、政策写成可协作、可审核的知识，而不是聊天记录。体验库按场景送出去：帮助中心 讲「此刻怎么做完」，文档站讲规格与概念，Wiki 知识库 收可协作的真源，需要时再开 AI 客服——建设侧已有一批场景模板可点亮这些叶子，Chat 只是其中一片，不是另起炉灶的说明书。
对作者落地时，顺序通常是这样。
先写进真源，再点发布。飞书里可以打草稿，终稿进知识库；未审核的就待在草稿，别混进对外库。帮助中心与文档站吃同一棵树上的果子，改一个默认值，回到同一处改，再发到该亮的门口。同一事实能复用出去，就少抄一遍，也少一分叉。
再让检索与问答只读已发布面。站内智能搜索、AI 客服一类能力，应建立在已经发布的帮助与文档上：检索到相关页，再总结给提问者；人最好还能点回原文核对。我们不把「模型凭常识编产品参数」当成功能，也不把「每一句都有法庭级溯源高亮」写成交付承诺——作者仍对终稿负责。工具加速的是收集与起草，不是把签字权交给对话框。
最后才谈「喂得更细」。FAQ、任务型帮助页、带版本的手册、可单独检索的知识片段，比一篇十万字的 PDF 更容易被人和机器共用。缺的往往不是再多一个栏目，而是：这页能不能单独成立、有没有进对外库、助手下次会不会饿着肚子去编。
写文档，从来不只是填栏目。到了助手也来读的年份，更直白的说法是：你每发出一页，都在决定智能体下次能不能答对。口粮干净，对话才站得住；口粮分叉，再聪明的模型也只是把版本冲突说得更流利。
