夜雨聆风它能在我喝完一杯咖啡前写完上千行代码，但问题是，其中不少行都错得自信而流畅。
代码能编译通过，读起来也像模像样，仿佛出自一位细心的工程师之手。但可能早在三个函数之前，它就已经悄无声息地假设错了前提。而现在，你只能亲自去排查，它到底是在哪里开始跑偏的。
所以，当有人告诉我，解决问题的关键只是一个Markdown格式的规则文件时，我忍不住翻了个白眼。用一份文本文件去教一个大模型“守规矩”，听起来就像在飓风身上贴一张“请保持整洁”的便利贴一样不靠谱。
然而，在仔细研究了几份这样的文件后，我自己也动手做了一个。就是这个文件，帮我成功实现了一种新的量化方法，在关键指标上击败了QuaRot——一个已经发表、经过同行评审的算法。整个构建过程只花了一个周末，而不是一个月，而且代码几乎没有Bug。那张“便利贴”，竟然真的起了大作用。
下面，我就来拆解一下这份文件里到底写了什么，以及为什么每一部分都至关重要。
AI编程助手没有跨会话的记忆能力。每打开一次新的对话，它对你项目的规范、你的编码习惯，或者你昨天刚修复的Bug都一无所知。
Andrej Karpathy（OpenAI联合创始人）有一个很形象的比喻：把大模型想象成CPU，它的上下文窗口就是内存。模型只能处理当前加载到“内存”里的信息，窗口之外的内容，对它来说就跟不存在一样。
这个比喻重新定义了我们的工作：关键不在于写出一句多么巧妙的提示词，而在于在模型开始工作之前，就把对的上下文“加载”进去。Karpathy等人把这称为“上下文工程”。这个叫法很贴切，因为提示词只是一个指令，而上下文是让模型完美执行指令所需的全部信息。
而CLAUDE.md，就是“上下文工程”最朴实、也最持久的形态。它是一个Markdown文件，AI助手会在每次会话开始时自动读取。无论谁在使用，无论状态如何，它都是项目的“长期有效指令”，每次都会被执行。
我使用的这个文件，开头就明确了四条行为准则。它们源于对AI编程助手失败模式的观察，每一条都精准地解决了常见问题。
先思考，再编码：动手前，先大声说出你的假设。如果需求有歧义，别自作主张，要指出来并提供多种解读。如果存在更简单的方案，要主动提出来。遇到不明确的地方，必须停下来提问。这能解决最昂贵的问题——AI选错了理解方向，然后在你反应过来之前，就已经写了200行自信满满但完全错误的代码。
简单至上：编写能解决问题的最小实现。不要画蛇添足地加功能，不要为只用一次的代码写抽象层，也不要处理不可能发生的错误。文件中有一个很直观的检验标准：如果一位资深工程师会觉得“过度设计”了，那就必须删掉。这能根治那种“要一个脚本，结果它给了一个带插件系统的类层次结构”的毛病。
手术式精准修改：只改动任务要求的部分。别去“优化”旁边的代码，别重新格式化已有功能，即使你习惯不同，也要遵循项目现有的代码风格。这能防止“顺手牵羊”式的编辑，避免一个三行的修复最终变成几百行的差异对比，让代码审查变得痛苦不堪。
目标驱动执行：把每个任务都转化为可验证的目标。“添加校验”要变成“为无效输入编写测试，并让测试通过”；“修复Bug”要变成“写一个能复现该Bug的测试，再让测试通过”。模糊的目标会让AI不断问你“做完了吗”，而清晰的目标能让它自己检查工作。
这些规则本身并不新奇，这正是它们的力量所在。它们是优秀工程师无需思考就会遵循的习惯，现在被写下来，让模型也照着做。
如果说四条规则是良好的“教养”，那么验证马鞍（Harness） 才是真正的引擎。
什么是“马鞍”？它是围绕模型运行的所有外部工具：测试命令、代码检查工具、类型检查器——总之，就是那个能给出“通过”或“失败”结果的东西。“目标驱动”规则的核心，就是让AI与这个“马鞍”挂钩，这样它就能自己判断刚才的改动是否有效。
想象一下两种安排装修师傅的方式：
“让房间舒服点。”——这很模糊。师傅凭感觉弄完，你回来发现太冷，反复沟通，无尽循环。
“把室温控制在21度。”——这是一个清晰的标准，一个“马鞍”。现在，一个恒温器就能替你自动完成这个循环，不需要你时刻盯着。
CLAUDE.md的任务，就是把所有指令推向第二种模式。
文件对此有严格规定：
要求AI定义一个可验证的最终状态。
然后进入循环：构建、运行检查、修复、重新运行，直到检查通过。
严禁对无法程序化检查的工作进行循环，比如：主观判断、设计决策、长时间的训练任务。这些必须由人来决定或由专门的脚本来执行。
强制使用独立的Git分支并设置迭代上限，防止死循环。
如果AI卡住了，它必须停止并报告阻塞它的原因，而不是胡乱尝试。
这个循环就是全部诀窍：我们不能盲目信任模型，它还不够聪明。但它足够聪明，能在我们设置好的“围栏”内工作，并被围栏及时捕获错误。
这个模版基于 gstack，也就是Y Combinator首席执行官Garry Tan今年早些时候开源的一套Claude Code配置。它在几周内就在GitHub上获得了超过10万颗星，可见有多少人都在默默与同样的问题作斗争。
gstack的设计理念是“轻量级马鞍，重量级技能”。框架本身很轻巧，真正的“智能”蕴藏在那些观点鲜明的Markdown文件中。
它将AI助手划分为不同的角色，通过斜杠命令（/command）来调用，整个工作流模拟了一个创业公司的冲刺流程：思考、计划、构建、审查、测试、交付、复盘。
/office-hours 命令会在你写任何代码之前，先“拷问”你的想法。
/review 命令会专门搜寻不必要的复杂性和越界修改。
/ship 命令如果没有通过测试，就不会放行代码。
而CLAUDE.md就是连接这一切的“结缔组织”：技能是各个领域的专家，而这个文件是所有专家都必须遵守的“基本法”。
我也得承认，批评的声音是有道理的。怀疑者会说gstack“不过是一个文本文件里的一堆提示词”。从技术层面看，确实如此。没有什么新奇的架构，每个技能就是Markdown加上系统提示词。但“只是一个文本文件”这种说法，严重低估了一份好的文本文件对模型行为的影响——这也正是我写下这篇文章的原因。
现在，来说说让我彻底信服的部分：我利用这套方案构建了ApexQuant，一种无需重新训练就能将神经网络权重压缩到极低精度的方法。
简单背景如下：大模型通常用16或32位来存储一个数字。量化技术则将这些数字压缩到4位甚至2位，让模型更小、运行成本更低。问题在于，模型中偶尔会出现一些异常巨大的数字（“异常值”），它们会破坏压缩过程。为了容纳它们，你不得不把整个数值范围拉大，导致所有正常数字都挤在一起，精度尽失。
我要挑战的QuaRot，有一个精妙的解决方案。它对每个数据块应用随机旋转。这种旋转能“抹匀”异常值，将它们的影响分散到众多数值中，而且从数学上保证不改变模型的最终输出结果（这被称为“计算不变性”）。一旦异常值被分散开，普通的等间距网格就能完美地进行量化了。这是一个非常强大、实至名归的成果，也是我努力超越的标杆。
ApexQuant在此基础上增加了一个洞察（受TurboQuant启发）：这些数值的分布呈现可预测的钟形，并且只取决于每一行的数据量。这个形状在统计学上被称为Beta分布。因此，不是像QuaRot那样使用均匀网格，而是根据数值实际集中的位置来精准放置量化级别。匹配数据的网格，效果自然优于一刀切的均匀网格。
坦诚地说，这个技巧依赖于行长度。当一个层的每行有数百个数字时，这个匹配网格优势巨大。但当每行只有9个数字时（比如某些移动端模型里的极小型深度卷积核），这个假设就不成立了，ApexQuant的性能就只能打平甚至落后。所以，该方法自带一个审计功能，会在运行前检查每一层，并给出GOOD（良好）、MARGINAL（临界）或BAD（糟糕） 的评估。
以下是在最关键指标上的对比，无需训练，无需校准数据：
数据不会说谎，尤其在2位和3位这种极致压缩下，ApexQuant的表现全面超越了QuaRot。
这并非魔法，而是严格的工程纪律：先验证想法，再编写代码，让机器自己证明它做对了。
当然，它并不完美，分享几个观察：
它只能在你擅长的事情上加速，无法弥补能力缺失。 如果连正常工作的代码长什么样都不知道，你就无法判断AI的输出是否正确。它是个强大的副驾驶，但前提是你自己得会“开车”。
规则需要与你的项目匹配。 “简单至上”在不同语境下含义不同。一个内部原型和一个生产级SDK，对“简单”的定义截然不同。你可以调整规则，但必须确保其清晰可执行。
测试是“马鞍”的命脉。 如果没有一套像样的测试，整个“目标驱动”的循环就会崩溃。在让AI使用这套流程之前，确保你的项目有基本的测试覆盖率。
“思考”环节并非万能。 让AI陈述假设和备选方案，确实能减少误解，但它不会替你进行深度的系统架构设计。这种高层次的设计决策，依然需要人来完成。
如果任务无法程序化验证，别用这套循环。 文章里也提到过，比如主观的设计选择，或耗时巨大的模型训练，让AI在这里无限循环只会浪费时间和金钱。
如果你也在用AI编程助手，却还没给它准备一份CLAUDE.md，那你真的错过了一个最容易的提升机会。
不是因为这个文件有多神奇，而是因为它把那些你心里清楚“本该如此”的纪律，白纸黑字地写了下来，并在每一次会话中强制执行。如果没有它，AI会毫不犹豫地走捷径。
去复制一份gstack的模版，填入适配你技术栈的“马鞍”命令（这部分只能由你来写），并保留那四条核心规则。然后，你会发现AI助手不再凭空猜测，不再四处“捞过界”，而是开始学会自己检查工作了。
事实证明，贴在飓风身上的那张“便利贴”，其实是一道坚实的围栏。对于一个快速、流畅但偶尔会犯错的机器来说，一道围栏，就是它最需要的东西。
