某个周五晚上我在 GitHub 上瞎逛，刷到 context-engineering-kit 这个名字。不瞒你说，那一瞬间我甚至有点感动。我捣鼓了大半年 vibe coding，卡得最死的从来不是工具不够聪明，而是我脑子里的那些约束——哪些表不能碰、哪段逻辑是事故换来的教训、灰度做到什么程度才算完——到底怎么喂给 agent。上下文工程，听起来就是我一直在干的那点破事终于有名字了。
然后我点开了 README。
好家伙。这哪是正名，这是往我脸上拍了一份《成功学宣言》。
先说我腰闪得最厉害的几个数。Review 插件自称是 CodeRabbit 的开源替代品。现在只要免费，谁都可以是“XX 的开源替代品”，这词已经从技术描述堕落成营销话术了。v2.0.0 讲重写了规格驱动开发插件，让它在生产项目上 99% 的情况能生成可用代码。再往前翻一个版本：100%。Reflexion 插件也来凑热闹，说引入反馈循环能让输出质量提升 8% 到 21%。
8% 到 21%。区间跨度快三倍了。谁要是拿这个数来糊弄我说“效果提升 8% 到 21%”，我一定追问他到底是多少——报不出数才拿区间遮脸。
看到 100% 的时候我基本已经麻了。哪个在真实项目里写过代码的人，敢对“可用代码”下这种结论？能编译就叫可用，测试跑通也叫可用，可要是只处理了 happy path、边界情况全漏呢？“看起来能跑”和“真的能用”中间那条沟，能埋掉一整支团队。
可我还真压着火把它的插件架构翻完了。Reflexion、Spec-Driven Development、Review、TDD、Subagent-Driven Development，是按插件思路认真组织的，不是一坨几千行没人敢碰的配置文件。这一点它的用心我认。
往下翻，我慢慢意识到一件事：它想解决的那个问题是真的，只是解法开始跑偏。
问题真在哪？它自己公布过一条我很买账的数据：一次性提示在改动文件超过 20 个的时候，全准确率只剩 1% 到 20%。这跟我自己的手感完全对得上。改动面一大，单次提问必然崩，上下文传着传着就散了，最后 agent 只记得最近那几句话。所有把 AI 当实习生用过的人都撞过这堵墙，别人只是骂完就算，它好歹把墙的高度量出来贴墙上了。就冲这点，我敬它是条汉子。
Run 偏在哪呢？它的核心思路是把对上下文工程的所有答案都做成一堆规范文档，然后往 context 里塞。Reflexion 插件美其名曰基于 Self-Refine 那几篇论文，扒开看，本质就是把论文思想翻译成给 agent 的反馈循环提示词。这件事本身没什么不行，我自己写 prompt 也常干——“你再看一眼，刚才这段哪里不对，重写一遍” ——只是我不会管这个叫 Reflexion，不然显得我像个被 token 价格冲昏了头的项目经理。
真正让我愣住的是 FPF 插件。First Principles Framework，一个俄罗斯学者提的框架，它把它做成了插件，把核心规范塞进子代理里跑。那套规范大概多少？六十万 token。官方建议拿 Sonnet 1m 来跑。
我盯着“60 万 token”这几个字看了半分钟。一份比三本长篇小说还厚的规范文档，指望 agent 在里头“基于第一性原理”做开发决策。可它不是人。人拿到超长文档会跳读、会找自己需要的章节、会带着怀疑去读每一条“你必须遵守”，模型不会。六十万 token 对它来说，跟六十字的 prompt 没有本质区别——都会被平均掉。上下文越长，关键约束的信息密度越低，越容易被淹没在无关细节里。这不是模型笨，这是人类语言和信息论早就标好的物理边界。
画外音：把一份六十万 token 的规范文件命名为“第一性原理”，可能是第一性原理今年被黑得最惨的一次。
还有个 Agent ESLint Config，号称一百多条规则，要强制生成低复杂度、高可读性的代码。规则列表我没去数，光“强制”这两个字就够我乐一晚上。ESLint 能检查缩进、检查函数长度、检查圈复杂度，可“可读性”它拿什么查？这东西是人在各种破项目里摸爬滚打练出来的手感，长在变量命名的习惯里、长在注释跟代码的关系里、长在“这段为什么这么丑但我必须留着”的背景故事里——不在任何 lint 的规则模式里。让 lint 去强制可读性，跟我让我家猫看门一样：岗位是设了，效果随缘。
那天晚上我关掉页面的时候，是真想直接拉黑。它比那些“为追新而换工具”的坑高级——它试图把所有 prompt 技巧、代码审查流程、规范意识打包成一键安装的插件，仿佛上下文工程这门手艺可以被装进一个包里发出去。
结果两天后我又回去了。因为冷静下来我不得不承认，这项目最招我烦的地方，恰好是我没法否认它的地方。它把“先写清楚规格，再让 agent 干活”这件事做成了正式插件，而这事我自己靠着一个 CLAUDE.md 和一堆备忘录干了小半年，每次新开一个项目就得翻出来手动铺一遍。它把那些本该散落在各处的规范收拢成开箱即用的工具，这是工程化的正路——反观我自己那套连测试都没有的 prompt 片段，才是真正的草台班子。
所以绕了一圈，我对它的态度变成了一个相当拧巴的结论：方向是对的，产品是拧巴的，数字是骗外行的。它像个把内功心法写成三千页大部头、还给每页都印了二维码的师傅。你不能说这书没用，可你要真把它塞给一个刚入门、本来只需要三句话点拨的徒弟，徒弟只会被压死。
这个项目的价值从来不在那个 99%，也不在“开源替代 CodeRabbit”这种口号，而在它把“上下文工程”从玄学变成一个能被摊开来讨论的东西——尽管那东西长得像一头喂得太胖的鲸鱼。真正的上下文工程，永远是挑压强最高的那几条约束钉在最前面，而不是堆一份越厚越好的规范大全。这个道理我早该想明白，省得每次让 agent 开工前，还要先烧掉大半 token budget 喂它读企业文化手册。
本期缴税：别把“上下文工程”外包成一次插件安装。规则得自己写、自己懂，因为整套系统里唯一长脑子的那个，始终是你。