1. 金句破题：上下文 > 代码
有句话在工程圈传得很开：我们不是用代码建起来的。我们是用上下文建起来的。
听起来像在贬低代码。其实不然。代码当然要写；只是当团队想用 AI 把入门、排障、配置向导「串起来」时，真正决定能不能用的，往往不是又多一层编排，而是模型能不能吃到正确、现行、自洽的产品事实——手册里的限制、FAQ 里的例外、更新说明里的变更、示例里的字段名。
行业公开观察里，不少「看起来很 AI」的能力，背后大量是文档与示例在喂，而不是无中生有的智能。没有好上下文，AI 很会制造另一种产出：看起来完整、审起来要命的草稿积压。提示词再巧，也补不上「现网到底允不允许这么配」这句硬事实。
对产品与研发负责人，这句话换成人话就是：你们若只投资「会叫的对话框」，却不投资「可维护的事实库」，等于在用代码和算力加速制造混乱。上下文不是再写一套编排；上下文是养分。编排可以周周迭代；养分若是雪花，迭代只是更贵地重复翻车。
上下文大于代码，不是号召少写代码，是提醒：编排再漂亮，吃错事实也会漂亮地做错。先问语料住在哪，再问要不要再加一层 Agent。
2. 提示词调不完，缺的是产品事实
上下文工程听起来玄，落到周报却很土：本周改了哪些产品事实、是否回到真源、对外库是否已发布。写不出这三行，所谓工程多半还停在调提示词。
国内团队调 AI 客服或内部助手，常见日程是这样的。
周一改系统提示：「你是严谨的产品专家，不确定就说不知道。」周二加几条 few-shot。周三发现它仍把标准版能力说成私有化能力，于是再加禁止清单。周四销售群里又冒出新口径，提示词来不及改。周五演示翻车——不是温度参数没调好，是帮助中心、飞书「最终说明」、方案 PDF 三套事实还在并行服役。下周一，又从改系统提示开始。
提示词像遥控器。遥控器再灵敏，电视信号源若是雪花，画面也好不到哪去。产品事实若只活在某位架构师的脑子里、某次发版的企微通知里、某份从未发布的飞书稿里，助手每一次回答都在碰运气。运气好，客户以为你们很稳；运气不好，售前要当场辟谣「助手说错了」——锅却记在模型头上。
真正省事的杠杆，常常土得令人失望：把手册、FAQ、更新说明建成可检索、可版本、可发布的语料；改默认值时回到同一处真源。提示词负责礼貌与拒答策略；上下文负责「对不对」。两件事绑在同一周的「调教」里，通常两件都做不好。可维护的语料，往往先拆成一份份知识片段与微内容——限制、步骤、例外各自可核，再按主题收进可发布的内容集合，而不是把整本 PDF 往对话框里一塞了事。
还有一种更隐蔽的「提示词债务」：每发现一次答错，就在系统提示里加一条禁止。禁止清单越来越长，像在用遥控器补偿信号源。清单能挡一时，挡不住销售群里下周又冒出的新口径。事实一变，禁止清单要人肉同步；同步不过来，助手就在旧禁止与新口述之间左右互搏。把力气从加禁止，挪回改真源，债务才会停利。
3. 坏上下文 = 评审债
评审债还会表现为「AI 写得越快，作者越不敢放假」。草稿队列堆积时，质量闸门若仍靠人肉逐行拆，自动化只是把瓶颈从写作挪到审核。语料自洽了，审核才可能变轻；语料分叉时，审核只会变重。
坏上下文的成本，很少立刻显示在 GPU 账单上。
它显示在评审队列里。AI 很快产了二十篇「看起来像帮助」的草稿：步骤齐全、语气专业、截图位置都标了——可对照现网，有一半字段名错了，有三分之一把内部路线图写成了已上线。技术作者从「写」变成「审」，审的却是更难拆的合成错误：错得圆，比错得明显更耗人。错得明显，一眼删；错得圆，要对着现网逐行拆，拆完还要解释「为什么看起来对」。
行业公开调研里，整篇完全交给 AI 写的人并不占多数；更多人用它起草、校对。杠杆往往在写之前与写之后——信息收得拢、变更看得见、对外口径对得上。坏上下文会把「写之前」省下的时间，加倍讨回到「写之后」的评审债里。
还有一种债更隐蔽：对内助手吃了未审核草稿，对外帮助中心仍是旧版；人以为「AI 已经会了」，客户侧搜到的仍是过期步骤。上下文分叉，等于同时养两套智能，两套都会理直气壮。国内实施周常见的画面是：顾问按助手口述配环境，客户按官网旧教程验收，两边都「有文档」，两边都不认账——评审债从写作台，蔓延到交付现场。交付现场的债，比写作台更贵：人天、差旅、客户耐心，都会进账单。
坏上下文还会污染「看起来已经 AI 化」的周报。团队可以汇报「助手覆盖了多少问题」，若语料仍是分叉的，覆盖率越高，错误传播越广。度量若只看回答条数，不看是否落在已发布现行页，评审债会被包装成效率。真正的效率，是答对且可点回原文；答得快却不可核，只是把债从写作台搬到客户侧。
4. Baklib：上下文仓库，而不是自动生成向导
视频教程与文字手册若讲同一任务，更要同源：口播可以活泼，限制与版本必须一致。示例字段名错了，演示越漂亮，评审债越厚。
Baklib 在这里的位置，更像上下文仓库，而不是「替你们生成一整套入门向导」的魔术师。
资源库收示例截图、演示视频与对外发过的材料；知识库把手册、FAQ、更新说明建成可协作、可审核的语料；体验库按场景发出去——Wiki 知识库、帮助中心，需要时再加视频教程门户一类叶子。建设侧模板可点亮 Docs、Help、Videos 等门脸；同一套内容给人读，也给AI 智能搜索与问答去检索总结——前提是已发布，而不是把草稿当口粮。
落地时不吹两件事：不把某家公司的 MCP 服务器故事写成 Baklib 开箱能力；也不写「接上 Baklib 就会自动长出入门向导」。能交付的是：产品事实有住所、有版本、能发布到稳定门口；Wiki 与帮助、手册同源，改一处，少漏三处。向导、Agent、编排，可以长在这层事实之上；没有这层，代码写得越多，幻觉与评审债往往越厚。
我们不是用代码建起来的——至少，不是只用代码。到了助手也来干活的年份，上下文才是那层决定「建得起来还是塌得更快」的地面。地面铺好了，代码才像在盖房子；地面是雪花，代码只是更贵的遥控器。先养语料，再谈编排；先发布，再让机器读——顺序反了，周会只会变成「再调一轮提示词」。
再补一句可验收的底线：Wiki 与帮助、手册是否同源；改默认值是否回到同一处；问答是否只吃已发布库。三件成立，上下文仓库才算立住；不成立，提示词周会只会无限开下去。代码与编排可以继续写——写在事实之上，而不是写在雪花信号源之上。
