发表于 | 分类于

从 Prompt 到 Loop：AI 时代，最重要的能力是创造创造机器

一、一个从“怎么用 AI”长出来的大问题

我们先从一个具体得不能再具体的场景说起。

有个人在用 AI 做量化：让模型写策略代码，跑回测，看收益和回撤，接下来还打算接模拟盘、实盘。他同时还用 AI 做另一件事：让模型去网上翻热门网文，总结里面反复出现的桥段和情绪套路，再拿这些总结去指导新的小说创作。

然后他问了一个看起来很技术的问题：这算不算一种 loop？

这个问题的有趣之处在于，它看上去是在问工具的用法，其实问的是一件大得多的事。因为当你把“量化”和“网文”这两件八竿子打不着的事情摆在一起，发现它们的骨架居然一模一样时，你就已经不是在讨论工具了，你是在讨论一种新的做事方式。

这种做事方式，正在悄悄改变人和机器的关系：从“我发指令、你交结果”，转向“我搭一个能持续试错、持续验证、持续进化的系统”。

这就是今天想跟你展开的核心命题。为了讲清楚它，我们需要先把 AI 的使用方式，拆成三个台阶。

二、三个台阶：prompt、harness、loop

第一个台阶，叫 prompt。

你对 AI 说一句话，它给你一段代码、一篇文章、一份报告、一个方案。人是甲方，AI 是乙方。你提需求，它交活儿。这是绝大多数人今天使用 AI 的方式，也是最直觉的方式。

第二个台阶，叫 harness（可以理解成“驾驭工程”或者“工作台工程”）。

到这一步，你不再只给一句话。你给 AI 边界、上下文、工具、数据、测试和评价标准。你不是让它自由发挥，而是给它一个受控环境，让它在限定范围里做事。这个台阶的关键，不是“把 prompt 写得更漂亮”，而是“让 AI 在一个可校验、可追溯、可重复的环境里工作”。

第三个台阶，叫 loop。

到这一步，AI 不再只是完成一个任务，而是进入一个循环：提出假设，执行实验，拿到反馈，修正方案，再来一遍。而人呢，既不只是发需求的甲方，也不只是搭工作台的工程师，人开始负责方向、判断、标准、停止条件——还有最要命的一样东西：价值函数。

如果一定要用一句话把这三个台阶串起来，我会这样说：

Prompt，是发明一个答案。

Harness，是发明一个工作台。

Loop，是发明一个生产系统。

而当你把这条路走到尽头，你会发现自己在做的事，其实是发明一个能不断发明东西的东西。

划重点：这三个台阶不是“新的替代旧的”，而是层层嵌套。没有 harness 的 loop 会失控，没有 loop 的 harness 只是个更讲究的工具。

三、这就像一个人从学生长成 PI

三个台阶听着抽象，我给你换一个更有画面感的类比：一个人在科研体系里的成长。

学生阶段。 别人给你题目，给你步骤，给你实验 protocol，你负责执行。老师说今天测这个指标，你就去测；老板说这段代码要改，你就去改。这个阶段最值钱的能力是执行力。

对应到 AI，这就是 prompt：一个明确任务，一个结果。

研究生阶段。 情况变复杂了。你不再只是照做，你开始会设计实验条件、控制变量、调参数、判断数据有没有意义。但你通常还在一个既定方向里活动——课题组定了大方向，导师画了边界，你在边界里探索局部的可能性。

对应到 AI，这就是 harness：你给它数据接口、测试脚本、验收标准、代码规范、运行边界，让它在一个受控环境里行动。

PI（实验室负责人）阶段。 角色又变了。你不再亲手做每个实验，你要决定的是：什么问题值得研究，哪些方向值得押注，哪些结果说明路线有戏，哪些结果只是噪音。你配置资源，设计研究组合，判断什么时候继续、什么时候转向、什么时候干脆停手。

这就是 loop。

我想强调一件容易被忽略的事：一个好的 loop，本质上是一个研究计划，而不是一段自动化脚本。它有假设，有实验，有反馈，有记忆，还有淘汰机制。它衡量成败的方式，也和自动化完全不同。

自动化问的是：今天跑通了吗？

研究问的是：这一轮，让我更接近真相了吗？

四、真正可怕的不是失败，是无法归因的失败

科研圈有一句很朴素的经验：不要怕实验失败，要怕不知道它为什么失败。

一个实验没跑出预期结果，可能是理论假设错了，可能是实验条件不对，可能是样本太小，可能是测量工具有问题，可能只是数据处理时出了个 bug。失败本身不丢人，无法归因的失败才是纯粹的浪费——因为它什么信息都没留下。

AI loop 完全遵循同一条规律。

拿量化举例。一个策略回测不好，并不自动证明这个思路无效。它可能是交易成本吃掉了收益，可能是信号半衰期太短，可能是样本外的市场环境变了，可能是因子暴露没有中性化，也可能是代码里藏了一个 look-ahead bias（用到了未来数据）。

所以真正重要的问题从来不是“这一轮有没有赚钱”，而是“这一轮有没有让我搞清楚点什么”。

这正是 loop 和“AI 帮我干活”的分水岭。前者把每一次失败都变成信息，后者只是把失败重复得更快而已。

划重点：判断一个 loop 有没有价值，别看它某一次的产出多漂亮，看它每一轮失败是否产生了可以复用的信息。

五、loop 的本质不是自动化，而是学习

很多人一听 loop，脑子里立刻蹦出来的词是“自动化”。

自动跑脚本，自动生成内容，自动发邮件，自动下单，自动发文章。这当然是 loop 的一部分，但绝不是最要紧的部分。

我们把话说得再直白一点：真正的 loop，不是让机器自己转起来，而是让系统每转一圈都变聪明一点点。

如果一个系统每天生成一堆策略、写一堆文章、发一堆内容，却不留下任何判断，不更新任何假设，不淘汰任何错误，不改进任何标准——那它不是 loop，它是一台自动化的噪音制造机。它甚至比手工还危险，因为它把无效劳动的规模放大了。

那么，一个真正会学习的 loop，需要哪些零件？我把它拆成六个。

假设。 你得知道自己在测什么。量化里，是“某个市场结构里存在可捕捉的行为偏差”；写作里，是“某种桥段能引发读者的期待与释放”;产品里，是“某个功能能解决用户的真实痛点”。没有假设的循环，只是在瞎忙。

实验。 这一环恰恰是 AI 最擅长的。写代码、跑数据、生成变体、整理文献、模拟用户、批量造测试用例——实验的成本被 AI 压到了地板价。这是这个时代最大的变量。

测量。 没有测量，实验就只是“行动”。量化要看收益、回撤、夏普、换手、样本外表现；网文要看读者是否读得下去、爽点是否成立、人物是否可信、章节钩子是否勾人；软件要看测试、性能、错误率、用户路径。

解释。 测量告诉你“发生了什么”，解释告诉你“为什么”。很多 loop 死在这一环：不是没有数据，而是数据没有被翻译成理解。

更新。 更新可以是改 prompt、改规则、改数据、改测试、改选题、换模型、调工作流。请记住一件反直觉的事——真正的进步不体现在结果里，而体现在系统结构的更新里。

停止标准。 什么时候继续，什么时候转向，什么时候承认方向错了。这一条最容易被忽略，却极其关键。没有停止标准的 loop，会平滑地滑进沉没成本的黑洞：越投入越舍不得，越舍不得越投入。

这六件事加在一起，才配叫“学习”。

所以，如果非要给 loop 一个更准确的定义，我不会说它是 automation（自动化），我会说它是 learning system（学习系统）。AI 让做实验变得极其便宜，但实验本身不会自动长出智慧。智慧来自选择、解释和积累——而这三样，目前主要还得靠人。

六、AI loop 干的是同一件事：把不确定性变成可学习过程

现在我们可以给这一整套东西提炼一个更硬核的说法了。

AI loop 的本质，不是把确定的事做得更快，而是把不确定的事变成一个可以学习的过程。

这句话值得咀嚼一下。

传统的自动化，处理的是确定性问题：流程你已经想清楚了，只是不想自己手动重复，于是交给机器。它的前提是“我知道怎么做，只是懒得做”。

而 loop 处理的是不确定性问题：“我还不知道怎么做，我甚至不确定这条路通不通。”面对这种问题，你没法一步到位地“自动化”它，因为你连正确答案是什么都不知道。你能做的，是把它拆成一轮一轮的猜测与验证，让每一轮都逼近答案多一点。

量化本质上是在赌一个你并不确定的市场规律；网文本质上是在赌一个你并不确定的读者反应；创业本质上是在赌一个你并不确定的市场需求。这些事的共同点是：你无法用聪明一次性想明白，只能用循环一点点试明白。

这里有一个很容易被忽略的推论：既然答案是试出来的，那么“试一次的成本”，就直接决定了你到底能走多远。

举个例子。一个策略假设，如果验证它需要你亲手写三天代码、手动下载数据、逐行调试，那么你一年最多也就试个几十次，其中大部分精力还耗在了“把实验跑起来”上，而不是“想清楚这次到底学到了什么”。可一旦 AI 把“跑起来”这件事压到几分钟，你一天就能试几十次。试错的密度提高一个数量级，你能探到的可能性空间，就完全是另一个量级。

换句话说，AI 没有让不确定的事变确定，它让你买得起更多次面对不确定的机会。这才是它真正改变游戏的地方。过去很多好想法之所以没被验证，不是因为它们错，而是因为验证它们太贵，贵到根本轮不到被认真对待。

AI 的真正价值，不是替你把已知的事做完，而是让你在未知的事上，能承受得起大规模、高密度、低成本的试错。

理解了这一层，你对“AI 会不会取代人”这个问题的答案也会变。因为真正在被改变的，不是“谁来执行”，而是“人类第一次有能力，把不确定性当成一门可以系统经营的生意”。

七、为什么 harness 是 loop 的地基

在往下走之前，我想专门停一停，说清楚一件很多人会跳过、但一跳过就要吃大亏的事：harness 不是 loop 的初级阶段，而是 loop 的前提。

我们不妨把三个台阶各自最操心的事，写成三个不同的问题。

Prompt 阶段，人操心的是“怎么说”——我该怎么问，才能让 AI 给我一个好答案？

Harness 阶段，人操心的是“怎么约束”——我该给 AI 什么工具、什么上下文、什么限制、什么测试，才能让它稳定地产出可用的结果？

Loop 阶段，人操心的是“怎么进化”——我该怎么搭一个系统，让 AI 的每一轮产出都能被验证、被选择、被记住，并推动下一轮变得更好？

这三个问题一层叠一层，缺了中间那层，整座楼就是危楼。

为什么？因为没有 harness 的 loop，是这个时代最危险的东西之一。

想想看：loop 的核心特征，是“高速地转圈”。而 AI 的生成速度又快得吓人。这两件事叠加在一起，意味着一旦方向错了，你的系统不是慢慢犯错，而是在高速地、批量地、不知疲倦地制造错误。它会用它全部的效率，把一个错误的假设放大成一场灾难，等你回过神来，可能已经在错误的地基上盖了二十层楼。

harness 就是那套防止你在错误地基上狂盖楼的东西：边界、测试、版本控制、指标定义、回滚机制、记忆系统。它给这台高速运转的机器装上刹车、装上仪表盘、装上安全带。

所以，如果说 prompt 是给 AI 一个任务，harness 是给 AI 一套制度，那么 loop，是在这套制度之上，再给 AI 施加进化压力。

划重点：先有可校验的环境，再谈可进化的循环。跳过 harness 直接冲 loop，等于给一辆没有刹车的车装上更大的引擎。

八、发明一个会发明东西的东西

聊到这里，一个更大的类比冒出来了：企业。

有一种被反复转述的说法：苹果最伟大的产品，不是 iMac，不是 iPod，也不是 iPhone，而是苹果公司本身。这句话真正厉害的地方，是它把两样东西干净利落地分开了——“产品”，和“生产产品的系统”。

iPhone 是一个产品，它会过时。

苹果公司是一台能持续造出新产品的机器，它可以一代一代往下走。

我们不妨把创造分成几个层级。

一阶创造，是做出一个东西。

二阶创造，是做出一个“能不断做出东西”的东西。

三阶创造，是做出一个“能不断改进自己创造能力”的东西。

AI loop 正在把普通个人，第一次推向二阶创造，甚至隐约摸到三阶创造的门槛。

你不是让 AI 写一个策略，你是在建一个能持续发现、验证、淘汰策略的系统。

你不是让 AI 写一篇小说，你是在建一个能持续提炼桥段、生成变体、吸收反馈、更新写法的系统。

你不是让 AI 写一个功能，你是在建一个能持续理解需求、生成方案、跑测试、修缺陷、沉淀规则的软件生产系统。

这就是“发明一个会发明东西的东西”。

而这，恰恰也是企业的本质。一家好企业，从来不是人、钱、办公室和流程的机械堆叠。它是一个有方向、有反馈、有记忆、有选择机制的创造系统：吸收资源，提出假设，做实验，淘汰错误，放大正确，形成文化，积累能力，然后源源不断地吐出新东西。

划重点：过去，“拥有一个组织”是极少数人的特权，因为它需要很多人、很多钱、很多协调。AI 把这个门槛砸掉了一大块——一个人，现在也能拥有一个组织的骨架。

九、一个人，一个微型公司

请注意，我不是在说“一个人就能取代所有组织”。这是一句会被现实狠狠打脸的大话。

现实世界里的销售、融资、法律责任、客户关系、线下交付、复杂的人际协作，仍然需要真实的人和真实的组织。这些没那么快被替代，也不该被轻率地替代。

但是，在知识生产、软件生产、内容生产、策略研究这些可以被高度符号化的领域，情况确实变了。一个人现在可以用 AI、代码、数据、自动化、知识库和发布系统，搭出一个微型实验室、一个微型媒体公司、一个微型量化团队、一个微型软件作坊。

这里面最稀缺、也最值钱的东西，是试错密度——单位时间里，你能负担得起多少次有信息量的尝试。过去，只有小团队才拥有像样的试错密度；现在，一个想清楚了的个人也能拥有。

于是一种新的个人形态出现了，我们不妨叫它：个人创造系统的架构师。

这个人不是传统意义上的老板，也不是传统意义上的程序员。他更像一个小型组织的设计者。组织里的研究员、工程师、编辑、测试员、分析师、资料员，很多角色都由 AI 和工具链来扮演。而他自己的工作，是设定方向、设计选择压力、维护标准、判断结果，并把每一轮的经验沉淀成系统的记忆。

十、进化论：变异、选择、遗传

要把“loop 到底是怎么运转的”讲透，我发现最好用的模型不是工程学，也不是管理学，而是进化论。

进化只需要三个条件：变异、选择、遗传。缺一个，就不会进化。我们把 AI loop 往这三个条件上一套，会发现严丝合缝。

变异，是 AI 的主场。

AI 最擅长的就是低成本地大量生成：十个策略、二十个标题、一百个产品功能、五种架构方案、三种文章结构。过去人脑里的想法很贵，因为每个想法都要花时间酝酿、表达、实现。AI 让变异变得极其便宜——便宜到你需要重新思考“想法多”到底还是不是一种优势。

变异一旦变便宜，选择就变成了瓶颈。

哪些策略留下？哪些桥段有效？哪些代码可维护？哪些功能值得上线？哪些文章值得发布？这些问题，AI 不会自动替你回答。它可以参与评估，但最终的选择压力必须由系统——归根结底由人——来定义。

不同领域的选择压力长得不一样：

量化里，是收益风险比、样本外表现、最大回撤、对交易成本的敏感度。

网文里，是读者停留、情绪释放、爽点密度、人物可信度、对下一章的期待。

软件里，是测试通过率、缺陷率、可维护性、性能、用户路径的转化。

个人成长里，是注意力有没有更自由、判断有没有更清楚、长期积累有没有真正在复利。

最后是遗传，也就是最容易被忽略的一环。

有效的经验怎么被保留下来？失败的教训怎么避免下次重犯？靠的是文档、代码库、测试、prompt、workflow、知识卡、指标体系、复盘记录、版本控制。没有这些，你的系统就是一条没有记忆的鱼：每一轮都从头开始，那不叫积累，那叫折腾。

把这三条合起来，一个 AI loop 就可以写成一行清清楚楚的公式：

AI 负责生成变异；测试、市场、读者、用户、回测负责提供选择信号；文档、代码、数据库、规则、workflow 负责遗传；而人，负责设计选择压力。

这一行里，最后半句是重点中的重点。未来真正强的人，不是最会“调用”智能的人，而是最会“设计一个让智能进化的环境”的人。

这三条里，人们通常只盯着“变异”惊叹——“哇，AI 一下能生成一百个方案”。但你现在应该看得出来，变异是三条里最不稀缺的一条。真正决定进化速度上限的，是选择和遗传。选择决定了你的系统往哪个方向走，遗传决定了它走过的路会不会被记住。一个只会疯狂变异、却没有像样选择和遗传机制的系统，就像一个物种拼命繁殖、却每一代都随机重新洗牌——它不会进化，只会热闹。

这也正是顶级企业家和顶级科研负责人的共同点：他们不亲自做每一个动作，但他们决定——什么样的动作会被鼓励，什么样的结果会被保留，什么样的错误会被淘汰。苹果的厉害，不只在于它有一群聪明人，而在于它有一套极其强烈的审美选择压力，很多东西被砍掉，留下来的才像苹果。一个好实验室也一样：它不是把所有想法都做一遍，而是有一套关于“什么问题有价值、什么证据可信、什么结果可以发表”的标准。

十一、最危险的地方：价值函数错了

到这里，故事已经足够漂亮了：AI 变异，系统选择，工具遗传，人设计压力，一台会进化的创造机器就搭起来了。

但正因为它高效，它才藏着最大的风险。

一台会进化的机器，如果价值函数错了，它会用惊人的效率，把你带向错误。

让我把这个抽象的“价值函数错了”，翻译成四种你一定见过的具体病症。

第一种，过拟合。 这是量化里的经典陷阱。一个策略在历史数据里表现得天花乱坠，不代表它未来能赚钱。如果你的选择压力只奖励“历史收益”，你就是在诱导 AI 去挖掘数据里的偶然纹理。回测曲线越漂亮，往往未来越危险——因为它可能只是把噪音背下来了。

第二种，指标幻觉。 你以为你在优化一个重要的东西，其实你只是在优化一个容易测量的东西。因为“重要”往往很难量化，而“容易测”的指标随手就有，于是系统会不知不觉地把靶心，从“重要”悄悄挪到“好测”上。

第三种，只追短期爽点。 内容创作里最常见。如果你的选择压力只奖励短期刺激，AI 会不断强化反转、悬念、标题党和情绪操控，最后写出一堆廉价套路。读者短期被钩住，长期却不再信任你——你透支的是自己最值钱的资产。

第四种，只追可测指标。 产品里俯拾皆是。只优化点击率，就会牺牲用户的真实收益；只优化留存，就可能把产品设计成让人上瘾；只优化收入，就可能一点点烧掉品牌信用；只优化“测试通过”，就可能写出一堆表面正确、实则没人敢维护的代码。

这四种病，看着各不相同，其实是同一条定律的四张脸。它常被转述为古德哈特定律（Goodhart’s Law）：一个指标一旦成为目标，它就不再是个好指标。

道理并不玄。指标之所以有用，是因为它和“你真正想要的东西”之间存在某种相关性。但一旦你开始死命优化这个指标，系统就会想尽办法钻空子，专挑那些“能把指标做高、却和你真正想要的东西无关”的路径去走。相关性被优化压力一挤，就断了。于是你得到了一个漂亮的数字，和一个越来越空的实质。你越努力，跑偏得越彻底。

AI loop 会把这条定律放大到极致。因为 AI 特别擅长追逐明确的数字——你一旦告诉它“把这个数拉高”，它就会不知疲倦、不择手段地朝那个数狂奔。它不会停下来问一句：这个数，真的是你想要的东西吗？

所以我想把话说得重一点：一台创造机器最核心的零件，不是发动机，而是价值函数。

发动机决定它跑多快，价值函数决定它往哪儿跑。发动机弱一点，无非是慢；价值函数错一点，是全速冲向悬崖。

这也正是为什么，人不会在 loop 里消失。恰恰相反，人最不可替代的位置，就在这里：

AI 可以生成更多可能性，但人要决定什么叫“好”。

AI 可以优化任何指标，但人要决定这个指标值不值得优化。

AI 可以跑完任何实验，但人要判断实验结果到底有没有意义。

AI 可以沉淀任何规则，但人要不断回头审查：这些规则，有没有正在把系统带偏。

十二、人的位置：从劳动力，变成制度

沿着这条线再往深走一层，你会看到一个更根本的变化：AI 让人第一次有机会，把自己的判断力，外化成一套能自己运转的系统。

过去，一个人的能力，是长在身体里的。你会写代码，是因为你亲手写；你会看文章的好坏，是因为你亲自读;你有经验，是因为你亲自踩过坑。能力被牢牢锁在你这一具肉身、这一段时间里。你在，能力才在；你累了，能力就停摆。

现在不一样了。你可以把一部分能力，写成 prompt、脚本、测试、文档、workflow、agent、数据库和发布流水线。

这意味着什么？

意味着你正在把自己，从一个劳动力，变成一种制度。

你的判断，不再只体现在某一次具体的选择里，而体现在“系统如何做选择”里。

你的品味，不再只体现在某一篇具体的文章里，而体现在“写作流程如何定义什么是好文章”里。

你的工程经验，不再只体现在某一次 code review 里，而体现在测试、规范、模板和质量门禁里。

你的研究能力，不再只体现在某一次灵感里，而体现在一个能持续提出和检验假设的 loop 里。

这是一次很大的迁移。在传统世界里，“制度”通常是公司和机构才配拥有的东西，个人只能有“习惯”。习惯不可扩展、不可复用、也很难传给下一段时间的自己。而 AI 时代，个人第一次可以拥有属于自己的微型制度：一个内容生产制度，一个投资研究制度，一个学习制度，一个软件开发制度。它们不必宏大，只要有方向、有反馈、有记忆、有淘汰、有复盘，就已经是一个组织的胚胎。

所以，“我在用 AI”这个说法，正在变得越来越不够用。

你不只是在用 AI。你是在用 AI，把自己的一部分能力，浇筑成一个可以脱离你的身体独立运转的外部结构。

十三、别在循环里修补结果，要在循环之上修补规则

这里要引入一个特别实用的区分：in the loop 和 on the loop。

In the loop，是人待在循环里，一件一件地补救结果。

AI 写了一段代码，你逐行去改。AI 写了一段文章，你手工去润色。AI 给了一个策略，你自己去调参数。你当然也在参与——但你参与的方式，是“局部修补”。这种参与有一个致命的问题：它不可扩展。AI 的产出速度越快，你越是补不过来，最后你会变成一个被 AI 追着跑的、更累的自己。

On the loop，是人站在循环之上，去修改规则。

AI 写的代码总是不合项目结构？你不只是改这一次，而是补上规则、测试和上下文，让它下次不再犯同一类错。

AI 写的文章总是“冷感”太重、只讲道理不给画面？你不只是改这一次的句子，而是把“场景先于结论”“观点要落到行动”这类要求，写进你的写作 harness。

AI 生成的策略总是过拟合？你不只是删掉这一次的结果，而是加上样本外验证、交易成本压力测试、因子暴露检查和明确的停止标准。

一句话对照：in the loop 修补结果，on the loop 修补规则。

这个转变为什么如此关键？因为 AI 的执行速度越快，你就越不可能靠“手工修补每一个结果”活下去。你唯一的出路，是把自己的判断，升级成规则、工具和自动检查机制——让判断本身变得可以规模化。

这其实就是“带团队”的道理。

一个新人每次提交代码都忘了跑测试，你当然可以每次都去提醒他。但更聪明的做法，是把测试放进 CI，让没过测试的代码根本合不进来。

一个编辑每次都忘了检查标题，你当然可以每次都替他看一眼。但更聪明的做法，是把标题检查写进发布前的 checklist。

AI 团队，也是团队。只不过这个团队的成员很便宜、很快、还特别健忘（每次都可能丢掉上下文）。你没法用情绪去管理它，你只能用制度去管理它。

十四、个人创造系统的五个器官

如果一个人真要动手搭一套属于自己的、AI 原生的创造系统，它至少需要五个“器官”才能算是活的。

第一个器官：方向感。

方向感决定系统往哪里积累。没有方向感，AI 会把你带进一种“随机的繁忙”：今天做量化，明天写小说，后天做 App，大后天又研究短视频。每件事看着都挺有意思，但彼此之间没有复利，你只是把精力平摊在了一地碎片上。

方向感不等于“只能做一件事”，而是要求不同的事之间有一条共同的主线。比如量化、网文、AI 编程，表面上南辕北辙，其实可以被同一个主题串起来：如何用 AI 建造可验证、可迭代、可沉淀的创造系统。 主线在，繁杂的事就开始互相喂养；主线不在，再勤奋也只是四处漏气。

第二个器官：评估标准。

什么叫“变好”？没有标准，就没有进步，只有自我感动。量化有指标，写作有读者，产品有用户，软件有测试，个人成长也得有反馈。标准不一定都是数字，但它必须能帮你做出“要 A 不要 B”的选择。一个不能帮你做选择的标准，等于没有标准。

第三个器官：记忆系统。

每一轮尝试，都要留下可以被下一轮调用的经验，否则你只是在不停地“重启”。记忆系统可以是文档、数据库、知识卡、commit、issue、实验记录、读者反馈索引、失败案例库。它不需要一上来就完美，但它必须存在——因为进化论早就说了，没有遗传，就没有进化。

第四个器官：资源分配。

哪些方向加码，哪些方向暂停？哪些项目只是探索，哪些项目进入生产？哪些结果值得请最贵的强模型来精雕细琢，哪些结果只配让便宜模型先草拟一版？这就是资源分配。它和投资组合是同一个道理——你不会把所有钱都押在一只高风险的股票上，也不会全部存定期。没有资源分配的 loop，会像一个不设预算的部门，安安静静地把你的时间和注意力吞光。

第五个器官：品味和价值观。

这是最难自动化，也最不该被自动化的部分。它决定这台系统最终会创造出什么，而不只是“提高了哪个指标”。你要不要写廉价爽文？你要不要为了收益牺牲风险控制？你要不要为了发布速度牺牲准确性？你要不要为了效率牺牲对人的基本尊重？这些统统不是技术问题，是价值问题。

关于这最后一个器官，我想留下一句可能有点扎心的话：

一个创造系统，可以没有很强的模型，但不能没有价值观。 模型弱一点，你可以补工具、补测试、补流程；价值观一旦错了，模型越强，它就越危险。

十五、把一次深聊，变成一篇文章，再变成一个 skill

绕了一大圈，现在我们回到这篇文章本身。

因为这篇文章，它自己就是一个 loop 的产物。它不是凭空写出来的，它是一个循环一圈一圈滚出来的。我把这个过程摊开给你看：

第一轮，是对话。 一个很小的直觉：prompt、harness、loop，人的角色好像在变。

第二轮，是类比。 这个变化，像不像一个人从学生长成 PI？执行、设计实验、设方向。

第三轮，是扩展。 它又像企业——最伟大的产品是公司本身，因为公司是那个“能持续造产品的东西”。

第四轮，是抽象。 我们把它拧成一串更硬的概念：二阶创造、创造机器、进化系统、选择压力、价值函数。

第五轮，是外化。 把讨论写成初稿，交给另一个更强的模型去润色，再发布到个人网站和阅读 App 上。

第六轮，是制度化。 把这一整套流程，沉淀成一个 skill。以后每当一次深聊足够有价值，就调用这个 skill：整理对话、提炼思想、写初稿、调用强模型润色、发布、验证，最后再把这一轮的经验，更新回 skill 本身。

你看，这件事本身，就是我们从头到尾在讨论的主题。

你不只是写了一篇文章。

你顺手发明了一台把深聊转化为长期资产的机器。

这就是 loop 最迷人的地方：一次有价值的思考，不再随着聊天窗口的关闭而蒸发。它被整理、被发展、被发布、被复用，最后成为下一轮思考的起点。而当这个 skill 还能根据每次使用的效果，反过来改进它自己时——你就已经在悄悄触碰三阶创造了。

十六、未来的高手，会是什么样的人

如果把前面所有的讨论，收束成一句判断，我会这样说：

AI 时代最强的个人，不是最会使用 AI 的人，而是最会建造创造系统的人。

这个人不一定是传统意义上的程序员，也不一定是传统意义上的企业家。他可能是研究者、作者、交易者、产品经理、独立开发者、老师、顾问、投资人，或者一个横跨好几种身份的杂食者。

但他们身上有一组共同的特征：

他不满足于一次性的产出，他要的是持续产出。

他不只关心结果，他更关心结果如何被验证。

他不只让 AI 执行，他给 AI 搭建环境。

他不只收集反馈，他把反馈转化成下一轮的规则。

他不只拥有想法，他拥有一个能让想法被测试的系统。

他不只是一个劳动力，他是一个会生长的制度。

这类人会越来越重要，因为 AI 正在重写世界的基本成本结构。执行变便宜了，生成变便宜了，试错变便宜了，表达也变便宜了。而越是这样，方向、标准、判断、记忆和价值函数，就越贵。

所以未来的差距，不会拉开在“谁能让 AI 多写几段代码、多生成几篇文章、多跑几次回测”上。真正的差距，会拉开在下面这几件事上：

谁能定义出值得循环的问题；

谁能设计出好的选择压力；

谁能分辨出真进步和指标幻觉；

谁能把失败变成信息；

谁能把经验变成制度；

谁能在飞快的速度里，依然守得住价值判断。

十七、结语：重新理解“创造”

过去我们说“创造”，脑子里浮现的往往是灵感、作品、天才、灵光一现的瞬间——一个人写出一本书，做出一个产品，提出一个理论。创造，是名词，是一个孤零零的成果。

AI 时代，创造的重心正在整体上移。

真正重要的，可能不再是创造某一个作品，而是创造一个能持续产生作品的系统。

不是写出一篇文章，而是建一个能不断从对话里提炼思想、发展成文、发布沉淀的系统。

不是写出一个策略，而是建一个能不断发现、检验、淘汰策略的系统。

不是写出一段代码，而是建一个能持续把需求变成可靠软件的系统。

不是学会一个知识点，而是建一个能持续吸收、验证、应用知识的系统。

这，就是从一阶创造，走向二阶创造。而当这个系统还能根据反馈改进自己时，它就开始触碰三阶创造。

所以也许，我们现在真正要面对的问题，不是那句被问烂了的“AI 能帮我做什么”，而是另一句更大的：

我能和 AI 一起，建成一个什么样的创造机构？

这个机构可以很小。它也许只是一个目录、一组脚本、几份文档、几个 agent、一个发布脚本、一个回测框架、一张读者反馈表。它小到不值一提。

但只要它有方向、有反馈、有记忆、有淘汰、有价值判断，它就不再是“零散地使用 AI”，而是一个会生长的东西。

从这个角度看，AI 编程、量化策略、网文创作、个人网站、skill 沉淀——这些看似分散的事，其实是同一件事的不同切面：

人类，正在学习如何发明“会发明的机器”。

而这台机器最终会发明出什么，不取决于它有多强，只取决于——我们把什么样的判断、品味和价值，写进了它的循环里。

发表于 | 分类于

从泥板到 AI Loop：人类如何发明会发明的机器

智人是地球上唯一一种会不断把自己的判断力、记忆力和劳动搬到身体之外的动物。狮子学不会把捕猎经验写下来传给下一代狮子，蚂蚁的分工写在基因里，几百万年不会改写。只有人类，一次又一次地找到办法，把脑子里那点脆弱又易逝的东西，固化成外部的、可以复制、可以传递、可以被下一个人接手继续运转的结构。

泥板是这样一次固化，账本是又一次固化，实验室是再一次固化，公司是又一次固化，软件系统是又一次固化。今天，AI agent 和它所嵌入的循环系统，正在进行人类历史上最新的一次、也可能是最深的一次固化。这一次，人类固化的不再只是记忆和流程，而是判断本身，以及生成新判断的能力。

这篇文章想讲的，就是这条从泥板到 AI loop 的长链条：人类如何一步步从“使用工具的物种”，走到“发明会发明东西的机器的物种”。这条链条上有三个反复出现的关键词——prompt、harness engineering、loop——它们看起来是这几年才有的技术词汇，实际上，是同一种古老冲动在最新技术条件下的复现：把偶然的、依赖个人天赋的创造，变成可以持续运转、持续进化的系统。

一、泥板与账本：人类第一次把判断力搬出大脑

大约五千年前，两河流域的祭司和商人开始在潮湿的泥板上刻画符号，记录谷物、牲畜和劳役。这不是文学的诞生，而是数据结构的诞生。最早的文字，几乎全部是账目：谁欠谁多少大麦，哪座神庙收了多少羊，哪个工匠该领多少口粮。

这件事看起来平淡，却是一次根本性的跃迁。在此之前，一个部落能协调的规模，取决于首领的大脑能记住多少人、多少承诺、多少恩怨。一旦超过一百多人，纯粹靠记忆维系的信任网络就会瓦解。泥板账本第一次让信息脱离了单个大脑的容量限制，变成可以被反复核对、被第三方审计、被下一任书吏继承的外部记录。人类从此可以协调成千上万互不相识的人，因为大家不再需要都记得住彼此，只需要都相信同一份账本。

这正是本文想强调的第一层意思：账本不是简单的记录工具，它是一套制度。它规定了谁有权记账、什么算作有效凭证、出现纠纷时以谁的记录为准。换句话说，账本第一次把“判断”这件事，从某个人的直觉，变成了一套可以被检验、被复核、被传承的规则。

如果借用后来的语言来描述，泥板账本已经具备了 harness 的雏形：它不是让每个书吏凭感觉记账，而是给所有书吏统一的符号系统、统一的格式、统一的核验流程。个人的判断被约束进一套结构里，结果因此变得可比较、可累积。

而更重要的是，账本催生了最早的“循环”：收成、征税、核账、纠错、修订税制、来年再收——一个不断被现实反馈校正的行政循环。法老的粮仓管理者不是只记一次账就完事，而是年复一年地把误差、亏空、丰歉记录下来，用于调整下一年的征收标准。这是农业帝国版本的“提出假设、观察结果、修正规则”。

从这个角度看，人类很早就发明了循环系统，只是那时候的循环运转得很慢，一圈往往要一整个收成季节，甚至一整个王朝。

二、实验室：把创造变成可重复的程序

如果说账本解决的是“如何协调大规模的人”，那么几千年后在欧洲兴起的实验室，解决的是另一个问题：“如何让发现新知识这件事，不再依赖某个天才的灵光一现，而变成一套任何训练有素的人都能执行的程序。”

在实验室出现之前，知识的进步很大程度上依赖零星的个人洞见，缺乏系统性的验证和复现机制，一个人的发现很容易随着他的去世而失传，或者因为没有被检验而以讹传讹。近代科学革命真正改变游戏规则的，不是某一项具体发现，而是一整套方法论：提出一个可以被证伪的假设，设计一个受控的实验条件，测量结果，与其他人分享数据和步骤，让陌生人可以在完全不认识你的情况下，重复出你的结果。

这套方法论的核心，恰恰是今天说的“harness engineering”的古老版本。科学家不是简单地对着自然界许愿，指望自然给出答案，而是给自己设定极其严格的边界：对照组、双盲、统计显著性、同行评审。这些边界的作用，不是限制创造力，而是让创造力可以被验证、被累积、被他人接力。没有这套边界，一个绝顶聪明的炼金术士留下的，可能只是几条互相矛盾的秘方；有了这套边界，一个普通的研究生也可以在前人基础上，往前推进一小步，而这一小步会被写进下一本教科书。

科学的另一个关键洞察，是把“失败”重新定义了。在实验室的语言里，一次没有得到预期结果的实验，很少被简单地称为浪费，因为它排除了一种可能性，缩小了下一次假设的搜索空间。真正被视为浪费的，是无法归因的失败——你不知道到底是理论错了、条件不对、样本太小，还是仪器有问题。可以归因的失败，是知识；无法归因的失败，才是真正的损耗。

把实验室的逻辑抽象出来，我们会看到一个此后反复出现的结构：假设、实验、测量、解释、修订、再实验。这个结构本身就是一种循环，一种以知识增长为目标的学习系统，而不是单纯的重复劳动。科学之所以能在几百年里积累出远超此前几千年总和的知识，靠的不是某几个天才的密度突然变高了，而是这套循环结构被制度化、被大规模复制到了成千上万个实验室里。

三、公司：发明会发明东西的东西

再往后走，工业革命带来了另一种制度发明，比蒸汽机和纺织机更重要，那就是现代公司。

一台机器可以生产一批产品，但机器本身不会决定生产什么、为谁生产、如何应对市场变化。公司之所以强大，不是因为它拥有某一件专利或某一条生产线，而是因为它是一种可以持续吸纳资源、持续提出商业假设、持续在市场里接受检验、持续淘汰失败方向、并把成功经验制度化的组织。科技界一直流传着一种朴素的说法：一家伟大公司最了不起的产品，往往不是它某一款畅销的具体商品，而是这家公司本身——这个能够一次又一次生产出新商品的系统。

这句话点出了一个此前很少被清楚表达的层级差异。做出一件产品，是一阶创造。做出一个能持续做出产品的组织，是二阶创造。而如果这个组织还能根据市场反馈，不断改进自己发现和验证新产品的方法，那就触及了三阶创造：创造一种能改进自身创造能力的能力。

公司之所以能做到这一点，靠的仍然是前面反复出现的那套结构：市场是实验场，销售数据和用户反馈是测量手段，季度复盘和战略调整是解释与修订，企业文化和流程规范是遗传机制，把有效的做法沉淀进制度，让下一批员工不需要重新踩一遍前人的坑。一家公司真正的护城河，往往不是某个天才员工的头脑，而是这套让平凡个体也能持续产出高质量结果的系统结构。

这也解释了为什么公司是一种极其特殊的历史发明：它是一种“法律拟制”，一种存在于人类集体想象和制度承诺中的实体，却能够比任何单独的人类个体活得更久，能够跨越创始人的生死，持续运转下去。公司教会人类的最重要一课，恰恰是本文的主题：真正稀缺、真正值得投入心力去建造的，不是某一个具体产物，而是那个能不断产出新产物、并且越运转越聪明的系统本身。

四、软件系统：把判断力压缩进代码与规则

信息革命给这条链条添上了新的一环：软件系统。如果说公司是把人类的协作方式制度化，软件则是把人类的判断和流程，压缩进了可以被机器精确执行的规则里。

一段测试代码，本质上是把某种正确性判断固化了下来：这个函数应该在什么输入下产生什么输出，不再需要每次都靠工程师肉眼检查。一条持续集成流水线，本质上是把一整套质量把关的流程固化了下来：不通过测试的代码不能合并，不符合规范的提交会被自动拦截。这些看起来枯燥的工程实践，实际上延续了实验室和公司共同的逻辑：把依赖个人记忆和自觉的判断，变成不依赖任何具体个人、可以被反复执行的制度。

软件工程的这套积累，恰恰为下一次跃迁准备好了地基。因为当人类开始尝试让机器不只是执行固定指令，而是自主生成代码、生成方案、生成内容的时候，第一个迫切的问题就是：如何像管理实验室、管理公司一样，给这个新的“执行者”设定边界、设定测试、设定规范，让它的产出可以被验证，而不是变成一堆无法归因的混乱。

这也是为什么 AI agent 不应该被理解为一个更聪明的文本框。文本框只是接受语言，返回语言；agent 的特殊之处在于，它让语言第一次大规模地接近行动。过去，一个人写下一句话，这句话最多改变另一个人的想法；现在，一句话可以触发脚本、修改代码、调用接口、生成文件、提交部署、查询数据库、安排下一轮任务。语言不再只是描述世界，它开始通过工具链直接插手世界。

这种变化看似技术性，实际上非常古老。官僚体系里的公文、法院里的判决、银行里的转账指令、公司里的审批流，本来也都是“语言变成行动”的机器。区别在于，过去这些机器需要大量人类职员在中间搬运、解释和执行。AI agent 把中间许多环节压缩进了同一个可编排系统里：一句自然语言指令，可以被翻译成一串机器动作；一串机器动作，又可以被测试、日志和版本控制记录下来。

于是，一个新的问题出现了：如果语言开始能够行动，那么人类更需要关心的就不是“这句话好不好听”，而是“这句话被放进什么制度里执行”。同一句“帮我优化策略”，在一个没有边界的环境里，可能意味着过拟合历史数据；在一个有样本外检验、交易成本压力测试和回滚机制的环境里，才可能意味着真正的研究。语言本身不可靠，制度化的语言才可靠。这就是从 prompt 走向 harness，再走向 loop 的深层原因。

五、AI 时代的三级跳：prompt、harness engineering、loop

于是我们抵达了这条历史链条的最新一环。人类第一次拥有了一种既不是人、也不是传统意义上的机器的执行者：它能理解语言，能生成代码、文字、方案，能在给定边界内自主行动。而人类与这个新执行者的关系，几乎完整重演了前面几千年走过的路，只是这一次，压缩到了短短几年之内。

第一步是 prompt。人类对着这个新执行者说一句话，让它生成一段代码、一篇文章、一份方案。这个阶段，人类的角色很像古代对着神谕许愿的求问者：提出一个问题，等待一个答案。这里几乎没有制度，只有一句话和一个回应，产出的质量完全取决于那一次问答的运气。

第二步是 harness engineering。人类逐渐意识到，仅仅换一种问法，并不能持续获得可靠的结果。真正管用的做法，是像实验室给科学家设定实验条件、像公司给员工设定流程规范一样，给这个新执行者搭建一整套受控环境：明确的边界、可用的工具、结构化的上下文、可执行的测试、可核验的数据、清晰的评价标准。这个阶段的关键不再是措辞技巧，而是制度设计——让执行者在一个可校验、可追溯、可重复的环境里工作，而不是自由发挥。

第三步是 loop。人类不再满足于完成单次任务，而是把执行者放进一个持续运转的循环：提出假设，执行实验，获得反馈，修正方案，再次尝试。到了这一步，人类的角色发生了质变，不再只是提需求的求问者，也不再只是搭建工作台的工程师，而变成了实验室的负责人、公司的创始人：负责设定方向、设定判断标准、设定何时停止、设定什么样的结果值得留下。

用一句话概括这三级跳：prompt 是发明一个答案，harness 是发明一个工作台，loop 是发明一个生产系统。而当这套生产系统本身还能根据反馈改进自己发现和验证方案的方式时，人类就已经在发明一台会发明东西的机器了。

六、Loop 不是自动化，而是一套学习系统

这里必须澄清一个常见的误解。很多人一听到循环，立刻联想到自动化：自动跑脚本，自动生成内容，自动执行交易，自动发布文章。这确实是循环的表面特征，却不是它真正的价值所在。

一个只会重复、却不会积累的系统，不叫循环，只是一台不知疲倦的复印机。它每天可以生产大量代码、大量文章、大量策略，却没有留下任何判断，没有更新任何假设，没有淘汰任何错误。这种系统运转得越快，制造的噪音就越多。

真正有价值的循环，本质上是一套学习系统，而不是自动化系统。区分二者的，是六个环节是否完整：有没有清晰的假设——你到底在检验什么；有没有可执行的实验——这一步 AI 让成本变得极其低廉；有没有可靠的测量——没有测量，行动只是行动，不是实验；有没有把测量结果转化为解释——数据告诉你发生了什么，解释告诉你为什么；有没有真正的更新——更新的不应该只是一次性的结果，而应该是产生结果的规则本身；有没有清楚的停止标准——什么时候该继续，什么时候该转向，什么时候该承认此路不通。

这六件事合在一起，才配得上“学习”二字。人类历史上每一次制度性的跃迁——账本、实验室、公司——之所以能持续产出价值，靠的都不是重复本身，而是这套学习结构。AI 的出现，让这套结构第一次可以以极低成本嵌入到几乎任何一个普通人的日常工作里，这才是循环真正值得被认真对待的原因。

七、变异、选择、遗传：进化论作为最贴切的模型

理解循环最合适的模型，不是工厂流水线，而是生物演化。演化需要三个条件同时具备：变异、选择、遗传。少了任何一个，都不会产生真正的进步。

AI 最擅长的，是把变异的成本降到接近于零。过去，一个新想法、一段新代码、一篇新文章，都需要人类耗费大量时间去构思、起草、修改，因此想法本身很贵，一个人一生能尝试的变体极其有限。AI 可以在很短时间里生成十种策略、二十个标题、上百种实现方案，变异从此变得极其廉价。

但变异一旦变得廉价，真正稀缺的东西就转移到了选择上。哪些方案值得保留，哪些桥段真正有效，哪些代码结构可以长期维护，哪些产品功能值得上线——这些判断，AI 可以参与提供信息，却不能替代人类定义标准。选择压力从哪里来，决定了整个系统最终会演化成什么样子。用回测的收益风险比筛选策略，系统就会往稳健的方向演化；只用短期点击率筛选内容，系统就会往猎奇和刺激的方向演化。选择压力本身，才是整个循环里最重要的设计决策。

第三个条件是遗传：有效的经验必须以某种方式被保存下来，传给下一轮尝试，否则每一轮都在从零开始，那不叫积累，只是原地打转。这正是文档、代码库、测试用例、知识卡片、复盘记录存在的意义——它们是这套人造演化系统里的染色体，携带着前几代实验留下的信息，让下一代不必重新踩一遍已经被踩过的坑。

于是循环可以被重新描述为一套小型的演化机制：执行者负责源源不断地制造变异，市场、读者、测试、回测负责提供选择压力，而文档、规则、代码库负责完成遗传。人类站在这套机制的顶端，不是去替代任何一个环节的具体工作，而是去设计整套选择压力应该指向哪里。这正是历史上每一次制度性组织——从神庙的祭司到实验室的主任，再到公司的创始人——真正在做的事情：不是亲自完成每一个具体动作，而是决定什么样的动作会被鼓励，什么样的结果会被留下。

八、价值函数的风险：当指标本身变成陷阱

一台可以持续自我改进的机器，听起来令人振奋，但历史反复证明，这类系统最危险的地方，从来不是执行力不够强，而是它被设定去优化的目标本身出了问题。

这个现象有一个广为人知的经济学规律：一旦某个指标被当成目标本身，它就会失去作为好指标的意义。因为一个足够强大、足够擅长优化的系统，会不知疲倦地朝着那个被设定的方向狂奔，而不会自动停下来反思，这个方向是否还对应着最初想要的东西。

在量化策略里，这个陷阱叫过拟合：一个策略在历史数据里表现完美，往往只是因为它精巧地记住了历史数据里的偶然纹理，回测曲线越漂亮，未来越危险。在内容创作里，这个陷阱表现为对短期情绪指标的过度优化：一味追逐爽点、反转和标题党，短期能钩住注意力，长期却会透支读者的信任。在产品设计里，只优化点击率会牺牲用户的真实收益，只优化留存会诱导上瘾式设计，只优化测试通过率会产生表面正确却难以维护的系统。

这类风险不是 AI 时代特有的新问题，人类历史上因为把手段当成目的而付出惨痛代价的例子并不少见：一味追求账面产量而忽视真实民生，一味追求扩张速度而透支制度根基。这些历史教训指向同一个结构性风险——当执行力越来越强、迭代速度越来越快时，一旦最初设定的方向出现偏差，系统会以更高的效率把偏差放大，而不是自动纠正它。

AI 循环会显著放大这种风险，因为它执行指令的耐心和一致性远超人类，一旦被告知要优化某个可测量的数字，它会以极高的效率朝那个数字奔跑，完全不会因为“这样做是否还符合初衷”而自我怀疑。这正是为什么，在一台会自我改进的机器面前，最重要的部件从来不是它的执行引擎，而是驱动它选择方向的价值函数。人类必须持续追问：这套系统到底在优化什么，它优化的东西是否真的对应着我们真正想要的结果，它是否把容易测量的东西，悄悄替换成了真正重要的东西。

这也正是人类在这套循环里不会被替代、也不应该缺席的位置。执行者可以生成无穷多的可能性，却无法替人类回答“什么才算好”；执行者可以精确优化任何被给定的指标，却无法替人类判断这个指标本身是否值得被优化。

九、从劳动力到制度：人类角色的又一次迁移

如果把这条历史链条拉直来看，会发现一个反复出现的模式：每一次信息网络升级，都会重新分配人类的角色。农业革命把大量人力固定进土地和粮仓，工业革命把大量人力固定进工厂和流水线，而每一次，都有一部分曾经属于人的具体劳动，被重新组织进了更大的制度结构里，个人不再直接生产最终产物，而是维护着让产物持续被生产出来的系统。

AI 循环正在推动这个模式的又一次跃迁，而且这一次跃迁的独特之处在于：过去只有大型组织才能拥有的制度能力，第一次开始下沉到个人层面。

所谓制度能力，过去往往意味着非常沉重的东西：办公室、雇佣合同、财务系统、审批流程、会议、档案、组织文化。一个普通人可以有技能，可以有习惯，可以有野心，但很难拥有真正意义上的制度。因为制度需要许多人共同承认，需要稳定的记录系统，需要反复执行后的沉淀，还需要在个体遗忘、离开或疲惫时继续运转的结构。

AI 改变的不是人类突然不需要组织了，而是组织能力的最小可行规模被压低了。一个人现在可以拥有一个只服务于自己的小型研究部门：AI 负责搜索资料、整理证据、生成假设，脚本负责跑实验，文档负责保存结论。一个人也可以拥有一个小型编辑部：对话产生想法，Codex 写母稿，Cursor 润色，发布系统上线，读者反馈回流到下一次写作。一个人甚至可以拥有一个小型工程团队：agent 写代码，测试系统验收，版本控制记录历史，部署脚本把结果推向线上。

这些“小型组织”未必有法人资格，也没有真实雇员，但在功能上已经具备组织的基本器官：它们有目标，有边界，有生产流程，有质量门禁，有记忆，有反馈，有复盘。它们不是比传统组织更伟大，而是第一次让普通个体可以在很小的尺度上练习组织设计。过去，只有创业者、实验室主任、总编辑和管理者才需要认真思考选择压力、资源分配和流程治理；现在，一个认真使用 AI 的个人也必须开始思考这些问题。

在此之前，一个人能拥有的能力，几乎完全存在于自己的头脑、双手和时间里。你会写代码，是因为你亲手写；你能判断一篇文章的好坏，是因为你亲自读过成千上万篇文章积累出的直觉；你有经验，是因为你亲自踩过坑。这些能力被牢牢锁在具体的个人身体里，无法脱离这个人独立存在，也很难被完整地传递给另一个人。

现在，一个人第一次有能力把自己的一部分判断，外化成可以脱离自己独立运转的结构：写成测试用例，写成评审规则，写成发布前的检查清单，写成一套让循环自动淘汰劣质结果的标准。这意味着，一个人的判断不再只体现在他亲自做出的某一次选择里，而是体现在他所设计的系统如何持续做出选择。他的品味不再只体现在他亲手写的某一篇文章里，而是体现在他所定义的“什么算好文章”这套标准里。

这是一次从劳动力向制度的迁移。过去，制度是组织和机构才配拥有的东西，个人最多只能养成习惯，很难拥有一套可以脱离自己独立运转、还能被继承和复用的创造结构。这一次，个人第一次有机会拥有微缩版的制度能力：一个持续发现和淘汰投资策略的研究流程，一个持续提炼桥段与吸收反馈的创作流程，一个持续把需求转化为可靠代码的工程流程。这些流程不需要宏大，只要具备方向、反馈、记忆和淘汰机制，就已经具备了组织的雏形，而组织，正是人类这个物种自古以来最强大、也最独特的发明。

十、把一次深聊变成一篇文章，再变成一个可复用的技能，这本身就是一次循环

这篇文章走到这里，恰好可以回过头审视自己是怎么产生的，因为这个过程本身，就是文章想要讨论的主题的一次现场演示。

第一圈，是一场对话：有人凭直觉察觉到，自己使用 AI 的方式正在从下达一句指令，转向搭建一整套持续试错的系统，人在其中的角色也在悄悄变化。第二圈，是类比：这种变化很像一个人从学生成长为科研负责人的路径。第三圈，是扩展：它又与公司这种历史发明高度相似，一家伟大公司最重要的产品，往往是它自己这套能持续产出产品的系统。第四圈，是抽象：把具体的观察，提炼成二阶创造、选择压力、价值函数这样可以迁移到任何领域的概念。第五圈，是外化：把讨论整理成一篇完整的文章，交由另一套系统打磨语言，发布到公开的渠道，接受真实读者的检验。

而真正让这件事完成闭环的，是第六圈：把整个流程——如何从一场深聊里提炼思想、如何组织成文章、如何检验、如何发布——沉淀成一套可以被反复调用的技能。这套技能一旦沉淀下来，下一次再出现一场足够有价值的对话时，就不再需要从零摸索，而是直接调用已经跑通的流程，跑完之后，再根据这一次运行中发现的新问题，反过来更新这套技能本身。

这正是循环最本质的味道：一次有价值的思考，不会随着对话窗口的关闭而消失，它会被整理、被验证、被发布、被复用，成为下一轮思考更高的起点，而记录和传递这个过程的方式本身，也在一次次运转中变得更加精炼。这与几千年前泥板上的账目、实验室里的实验记录、公司里沉淀下来的流程手册，在结构上是同一件事，只是这一次，从提出想法到把想法变成可继承的制度，中间的时间被压缩到了几天甚至几小时之内。

十一、结语：重新理解创造，也是重新理解人类的位置

把泥板、账本、实验室、公司、软件系统、AI agent 和 AI 循环并排放在一起看，会发现这不是七个孤立的技术故事，而是同一条脉络的七个阶段：人类不断把判断力从个体的头脑里搬出来，固化成外部的、可以被继承、可以被复制、可以被检验的结构，而每一次固化，都会重新分配一次人类自己在系统里的位置。

写字的人从记忆的看守者，变成了信息的记录者；商人从口头承诺的当事人，变成了账本制度的维护者；工匠从凭手艺吃饭的个体，变成了流水线上的一个环节，又在下一轮里变成了流程和标准的设计者；而在 AI 循环这一阶段，普通人第一次有机会从单纯提出需求的求问者，变成一整套创造系统的架构师。

这套系统可以很小，可以只是几份文档、几段脚本、一套测试、一个发布流程，但只要它具备方向、有反馈、有记忆、有淘汰机制、有清醒的价值判断，它就不再是一次性的产出，而是一个会自己生长的东西。人类历史上真正留存下来的，从来不是某一块泥板上的具体记录、某一次实验的具体结果、某一款产品的具体型号，而是那些让记录、实验和产品得以持续被生产出来的制度本身。

AI 没有改变这条历史规律，只是把建造这类制度的门槛，第一次降到了几乎每个普通人都可以触及的高度。真正的分野，不再取决于谁能让执行者多写几段代码、多生成几篇文章、多跑几次回测，而是取决于谁能提出一个真正值得反复检验的问题，谁能设计出恰当的选择压力，谁能分辨真正的进步和被指标误导的幻觉，谁能把每一次失败转化成下一轮可用的信息，谁能把零散的经验沉淀成可以传承的制度，并且在速度越来越快的循环里，始终守住那个不能被外包出去的判断：这一切，究竟是在朝着我们真正想要的方向前进，还是只是在朝着一个被误认成方向的数字狂奔。

这或许就是这条从泥板延伸到 AI 循环的历史长链，留给今天每一个人的最终提问：不要只问这台机器能替我做什么，而要问，我能和它一起，建成一台什么样的、会不断变得更聪明的创造机器，以及，决定这台机器最终会创造出什么的，究竟是怎样的判断、怎样的品味和怎样的价值。

换句话说，AI loop 的终点不是让人退出历史，而是迫使人重新承担历史上最古老、也最沉重的责任：为自己创造出来的制度，选择一个值得前往的方向。

发表于 | 分类于

广东物理类530分12万名志愿怎么报

有同学问我：妹妹今年广东高考，普通类物理方向，530分，省排名大概12万名，志愿应该怎么考虑？

我整理了一份很长的参考资料。这里放一个简洁版，适合先给家里人看，用来统一思路。先说结论：这个分数不是没得选，但也不是可以随便冲。最重要的不是“530分”这三个字，而是“12万名左右”这个排位。

广东2026年普通类物理本科线是425分，特殊类型招生控制线是539分，地方专项计划物理线是509分。也就是说，530分比本科线高105分，比特控线低9分，比地方专项线高21分。如果孩子有地方专项资格，可以单独研究；如果没有，就不要把它当作主要路径。

真正填志愿时，要以广东省教育考试院志愿填报系统、2026年招生专业目录、高校招生章程和体检结论为准。这篇文章只是帮助家庭讨论，不是最终志愿表，也不承诺录取结果。

先看排位，不要只看分数

高考志愿最容易犯的错误，是拿今年的分数直接套去年的学校。比如去年530分能去哪里，今年530分就照着填。这样很危险，因为每年试卷难度、考生人数、招生计划和专业热度都会变。

更可靠的办法，是看排位。2025年广东物理类530分累计大约在11.3万名附近。今年如果530分约12万名，说明同样分数对应的位置略靠后。所以这位考生不能只按“去年530分”判断，而要按“12万名左右”判断。

我的建议是，用2025年投档最低排位做初筛：

  • 冲：去年最低排位大约10万到11.5万。
  • 稳冲和稳：去年最低排位大约11.5万到12.8万。
  • 保：去年最低排位大约12.8万到14.5万。
  • 兜底：去年最低排位大约14.5万以后，必要时看到15万到18万。

这只是粗略区间，不是机械公式。某个专业组今年计划减少、专业变热、选科要求变化，风险都会上升；如果计划增加、专业组拆分、热度下降，机会也可能变大。

广东填的是“院校专业组”

广东新高考不是简单填45所大学，而是填45个院校专业组。普通类本科和专科，物理、历史各有1个平行志愿组，每个志愿组可以填45个院校专业组；每个院校专业组里面可以填6个专业志愿，并选择是否服从专业调剂。

这个规则非常重要。因为同一所学校，不同专业组的录取难度、专业范围、学费、校区、再选科要求，可能完全不同。

比如一所学校可能有物理不限组、物理加化学组、中外合作组、地方专项组、联合培养组。你不是笼统地填“某某大学”，而是在填“某某大学某个专业组”。最后被检索、被投档的，也是这个专业组。

很多家庭的失误就发生在这里：只看学校名字，没看专业组里到底有什么专业。结果投档进去了，却被调剂到完全不想读的专业。

45个志愿怎么分

如果家庭目标是“尽量上公办本科，专业不要太离谱，省内省外都可以比较”，可以大致这样分：

  • 6到8个冲刺志愿，放去年最低排位约10万到11.5万的专业组。
  • 10到14个核心志愿，放去年最低排位约11.5万到12.8万的专业组。
  • 14到16个稳妥志愿，放去年最低排位约12.8万到14.5万的专业组。
  • 7到10个保底志愿，放去年最低排位约14.5万以后的专业组。

前面的“冲”不能是纯许愿。冲刺志愿也要满足一个底线：如果真录了，专业组内的调剂结果也能接受。

后面的“保底”更不能随便填。保底不是找几个低分学校凑数，而是找“录了也愿意去”的学校和专业组。否则保底就不是保底，而是新的麻烦。

先删掉不能接受的，再讨论喜欢的

填志愿不是先问“你最喜欢什么”，而是先问“什么绝对不能接受”。因为平行志愿里，一旦被某个院校专业组投档，后面的志愿一般就不再检索。如果进了不合适的组，又不服从调剂，可能退档；如果服从调剂，可能被分到不想读的专业。

家庭可以先开一次会，把这些问题说清楚：

  • 民办本科能不能接受？
  • 中外合作、国际班能不能接受？一年学费上限是多少？
  • 职业本科能不能接受？
  • 联合培养、协同培养能不能接受？如果不在主校区读，能不能接受？
  • 省外能不能接受？最远能去哪里？
  • 医学、护理、药学、农学、食品、材料、化工、环境、土木、航海这些方向能不能接受？
  • 如果有地方专项、教师专项、卫生专项资格，能不能接受协议、服务期和定向地区？
  • 体检有没有色盲、色弱、视力等限制？

这些问题不提前说清楚，最后很容易变成家长和孩子之间的拉扯。

几个比较现实的方向

第一，省内公办本科。

12万名左右在广东省内不是完全没有公办机会，但要接受取舍。可以重点看地市公办、行业特色院校、联合培养、职业本科，以及一些相对不那么热门的专业组。省内优势是离家近、生活适应成本低；劣势是竞争挤，热门城市和热门专业会更难。

第二，省外公办本科。

这个分段很值得认真看省外公办。很多家庭天然偏好留在广东，导致省内同分竞争很激烈。愿意出省的话，可能用同样排位换到更清晰的专业、更传统的本科体验，甚至更舒服的录取位置。代价是距离、气候、饮食、回家成本和未来就业路径都要提前想清楚。

第三，专业优先。

如果孩子已经很明确想学某一类专业，就应该先圈专业，再看学校。

想学医药，不要一上来就盯临床、口腔、麻醉、医学影像这些热门方向。530分、12万名附近，更现实的可能是药学、医学检验、康复治疗、护理、公共卫生、预防医学、医学技术类等。

想学工科，要先确认有没有选化学。现在大量工科、医学、药学、生物、食品、材料、化工、环境类专业都可能要求物理加化学。没有化学，候选池会明显变窄。

想学师范，要把普通师范和教师专项分开看。教师专项不是普通低分入口，它往往带有定向培养、服务地区和服务期要求。孩子是不是真的愿意当老师，比“分数够不够”更重要。

想学财经、金融、会计、管理，也要现实一点。这类专业名字好听，就业面广，但竞争已经很激烈。本科院校层级、城市、实习资源、考研考证能力，都会影响后续发展。

第四，职业本科、联合培养、中外合作。

这些标签不能一概排斥，也不能一概当作捡漏。职业本科是本科层次，但培养定位更偏应用技术。联合培养、协同培养要查清楚四年在哪里读、毕业证学位证怎么标注、教学管理归谁。中外合作和国际班要看学费、语言要求、课程难度、是否出国和家庭承受能力。

是否服从调剂

一句话：如果一个专业组内所有专业都能接受，一般建议服从调剂；如果组内有绝对不能接受的专业，就要谨慎填这个组。

不要幻想用“不服从调剂”解决专业组选择问题。比如一个专业组里只有2个专业喜欢，其他都不想读，然后填这个组并选择不服从调剂，看起来像是在保护专业，其实是在放大退档风险。

更好的办法是：把专业组看细。喜欢、可接受、勉强、不能接受，逐个标出来。稳和保的志愿，尤其要确保“录了能接受，调剂也不崩”。

最后几天怎么安排

如果现在还没开始整理，可以按这个节奏推进：

6月25日到6月28日，先确认基本信息：官方排位、完整选科、体检结论、专项资格、家庭预算。然后用2025年投档表筛出一批去年最低排位大约10万到18万的院校专业组。

6月29日到7月2日，用2026年招生专业目录逐个核对：今年是否招生、计划数多少、专业组有没有变化、选科要求是否符合、组内专业是否接受、学费和校区是否能接受。

7月3日，做压力测试：前10个冲不上怎么办？热门专业录不到怎么办？被调剂能不能接受？最后保底是不是录了也愿意去？

7月4日，主要做核对，不要大改。代码、专业组、专业、是否服从调剂、保存和确认状态，都要逐项检查。不要卡在截止前最后半小时提交。

广东2026年普通高校招生志愿填报的第二时段是6月29日19:00到7月4日16:00，普通本科志愿就在这个时段完成。这个时间点要记牢。

给这个分数段的一句话

530分、12万名左右，最怕两种极端。

一种是太悲观，觉得没什么好学校可选，于是随便填。其实这个位置仍然有不少本科选择，只是要认真比较。

另一种是太乐观，前面全冲热门城市、热门学校、热门专业，后面拿几个自己根本不了解的民办、高收费或冷门专业组当保底。这样看起来志愿很满，实际上风险很大。

比较稳妥的心态是：她处在一个“选择不少，但每一步都要取舍”的位置。把省内和省外都纳入比较，把专业组看细，把调剂风险控住，把45个志愿铺开，最后让每一个志愿都满足一个底线：录了可以去，不会后悔到无法接受。

参考资料主要来自广东省教育考试院2026年最低分数线通知、2026年志愿填报通知、2026年招生工作通知、2025年一分一段表、2025年本科普通类物理投档情况，以及教育部阳光高考平台。正式填报前，请一定回到官方系统和高校招生章程逐项核对。

参考链接：

发表于 | 分类于

Harness不是测试工具，而是开发控制面

如果把 Harness 只理解成测试工具，就会错过它最有价值的部分。

测试工具回答的是：这段代码在给定条件下会不会按预期运行。开发 Harness 回答的是：这个任务从被提出到被交付，中间每一步有没有失真、有没有越界、有没有证据、有没有停损点。

测试工具通常包住代码。开发 Harness 包住过程。

一、Test Harness 给我们的启发

一个好的 test harness 会做几件事：

  • 准备被测对象。
  • 构造输入。
  • 替换外部依赖。
  • 控制时间、网络、数据库、文件系统等不稳定因素。
  • 执行动作。
  • 观察输出。
  • 断言结果。
  • 清理环境。

它真正重要的地方，不是“测试”这个词，而是“可控环境”。

没有 Harness 时，代码跑在真实世界里，依赖太多，状态太乱，失败难以复现。有了 Harness，代码被放进一个小型控制舱：输入可知、依赖可知、输出可测。

这件事可以迁移到整个开发过程。

一个需求也是被测对象。它进入开发系统时，天然带着模糊、噪声和缺口。如果不把它放进 Harness，它会在每个阶段变形。最后你得到的不是“解决了问题的代码”，而是“根据一串未验证假设生成的代码”。

二、开发 Harness 控制五件事

开发 Harness 至少有五个控制点。

第一，方向。

方向由 Mode、问题定义、In Scope、Out of Scope 控制。它解决的是“我们到底在做什么”。如果方向没控住，后面所有努力都可能是在加速偏离。

第二，事实。

事实由 Research 控制。它解决的是“我们凭什么这么判断”。开发中最危险的不是未知，而是把未知伪装成已知。Research 要把 Facts、Assumptions、Unknowns 分开。

第三，设计边界。

设计边界由需求、技术设计和实施计划控制。它解决的是“允许怎样改，不允许怎样改”。这里要明确状态流、接口契约、错误态、回滚、监控、验证方式和停损点。

第四，执行。

执行由任务切片、文件边界、测试先行、diff review 控制。它解决的是“怎么保证改动没有偷偷扩大”。AI 参与时尤其重要，因为 AI 很容易把“顺手”变成“已经改了”。

第五，证据。

证据由测试计划、review finding、验收记录、发布报告和复盘控制。它解决的是“我们怎么知道这次真的完成了”。没有证据，完成只是情绪。

三、为什么只靠测试不够

测试很重要，但测试不能替代开发 Harness。

测试通常发生在实现之后。它可以告诉你代码行为是否符合某个预期，但它不一定告诉你预期是否正确。如果问题定义错了，测试越全，越稳定地证明一个错误目标被实现了。

测试通常覆盖代码路径，但不一定覆盖任务边界。一个功能测试通过了，不代表这次没有顺手改坏别的契约。

测试通常验证可观察行为，但不一定验证运维后果。代码能跑，不代表日志足够、指标足够、回滚可行、失败能被发现。

测试通常对付明确输入，但开发失控常常来自隐含输入：一句模糊需求、一个不完整上下文、一段 AI 自行补全的假设。

所以测试是 Harness 的一部分，但不是全部。

更准确地说：

测试 Harness 控制代码运行环境；开发 Harness 控制代码产生过程。

四、一个简单例子

假设任务是：“把文章导出功能优化一下，最近偶尔失败。”

没有开发 Harness 的过程可能是：

  1. 搜索 export。
  2. 看到异常日志。
  3. 猜测是超时。
  4. 增加重试。
  5. 补一个成功导出的测试。
  6. 写结论：已优化。

这个过程很快，但风险很多。

“偶尔失败”到底是什么失败？是生成失败、上传失败、权限失败、任务队列失败、文件过大失败，还是前端轮询超时？

“优化”是什么意思？降低失败率、缩短耗时、改善错误提示、增加重试、增强幂等、补偿历史失败任务，还是增加可观测性？

“增加重试”会不会导致重复导出？会不会重复扣额度？会不会把不可重试错误重试三次？会不会隐藏真正的权限问题？

如果这些都没问，测试成功也只能证明一个很窄的成功路径。

同一个任务放进开发 Harness，过程会变成：

  1. Mode：Hold，只修复和硬化导出失败，不扩展新导出格式。
  2. Research：列出现有导出链路、失败日志、触发条件、相关文件、已有测试。
  3. Problem Framing：确认问题是“导出任务在上传成功但状态写回失败时，会被用户看到为失败且无法恢复”。
  4. Technical Design：设计幂等 key、状态机、错误分类、日志指标、回滚方式。
  5. Implementation Plan：分阶段改状态机、补测试、补指标。
  6. Execution：只改批准文件。
  7. Review：按 happy、nil、empty、error 检查。
  8. Test Plan：记录每条验证命令和证据。
  9. Acceptance：明确剩余风险和是否可发布。

这不是慢。这是把“快但可能错”改成“每一步都知道为什么”。

五、Harness 的几个误区

第一个误区：Harness 等于更多文档。

坏文档确实会拖慢开发。但 Harness 的目标不是写更多字，而是让关键信息不丢。一个好的问题定义可能只有半页，但它能阻止三天偏航。一个好的测试证据台账可能只有一张表，但它能让上线后的复盘有抓手。

第二个误区：Harness 只适合大项目。

小任务更需要轻量 Harness。因为小任务最容易让人觉得“这点事直接改就行”。很多事故不是大项目造成的，而是小改动没有边界、没有测试、没有 review。

第三个误区：AI 可以替代 Harness。

AI 可以帮你生成 Harness 文档，但不能替你决定边界。AI 可以帮你补测试，但不能替你判断哪些风险值得覆盖。AI 可以帮你 review，但如果你没要求它按四路径 review，它很可能给你一段温顺的总结。

第四个误区：Harness 会压制创造力。

真正压制创造力的是混乱。因为混乱会让所有精力都耗在补洞、解释、返工和救火上。Harness 把基本控制面固定住，反而释放了更多思考空间。

六、最小形态

如果一个任务很小，不需要完整文档链，也至少保留最小 Harness：

1
2
3
4
5
6
7
8
9
Mode:
In Scope:
Out of Scope:
Facts:
Assumptions:
Plan:
Validation:
Review Paths:
Residual Risk:

这些字段看起来普通，但它们分别控制不同失控点：

  • Mode 控制变化方向。
  • In Scope 控制本次要做什么。
  • Out of Scope 控制本次不做什么。
  • Facts 控制证据。
  • Assumptions 防止猜测伪装成事实。
  • Plan 控制执行顺序。
  • Validation 控制完成证据。
  • Review Paths 控制边界路径。
  • Residual Risk 控制诚实收尾。

任务变大时，把它展开成完整流程。任务变小时，把它压缩成这几个字段。

Harness 不是仪式，它是可伸缩的控制面。

发表于 | 分类于

从混乱到可控：AI时代代码开发为什么需要Harness

AI 编程最容易让人兴奋的地方，是它让代码来得太快。

你说一句“帮我把这个功能补上”，它就开始读文件、改代码、写测试、解释方案。以前一个下午才能推进的事，现在像被压缩进十几分钟。这个变化当然重要。但越用到后面，我越觉得真正的问题不是速度，而是控制。

代码来得太快以后，新的问题会出现：需求还没钉住，代码已经写完；边界还没说清，重构已经发生；测试只跑了成功路径，结论已经写成“完成”；AI 把不确定的猜测补成了流畅的解释，人看着也觉得合理。

这不是 AI 的问题。这是开发过程没有 Harness。

一、混乱不是从写代码开始的

很多人以为，开发混乱来自代码写得不好。

当然，代码会写坏。但更早的混乱，通常发生在代码之前。

一个需求往往是这样开始的：

“这个同步偶尔不对，帮我优化一下。”
“这个页面加载有点慢，修一下。”
“这个导出最近有失败，你看看。”
“让 AI 帮我把测试补齐。”

这些话听起来像任务，其实不是。它们只是问题的影子。

“同步不对”到底是数据丢了、状态没刷新、冲突没合并，还是 UI 没更新？
“加载慢”到底是接口慢、首屏慢、感知慢，还是空态判断错了？
“导出失败”到底是生成失败、上传失败、状态写回失败，还是用户重复点击造成多个任务？
“补测试”到底要覆盖主路径，还是要覆盖缺配置、空数据、异常和超时？

如果这些问题没有被拆开，开发就已经开始漂了。AI 只会让这种漂移跑得更快。

二、Harness 不是测试工具

很多人听到 Harness，会先想到 test harness。这个理解没有错，但太窄。

测试 Harness 是把代码放进一个可控环境里：准备输入，替换依赖，执行动作，观察输出，断言结果。它的核心不是测试两个字，而是可控条件。

我说的代码开发 Harness，是把整个开发过程放进可控条件里。

一个需求从想法到上线，中间会经过很多次转换：

  • 用户说的话，转换成问题定义。
  • 问题定义，转换成需求。
  • 需求，转换成设计。
  • 设计，转换成计划。
  • 计划，转换成代码。
  • 代码，转换成测试证据。
  • 测试证据，转换成验收结论。
  • 验收结论，转换成发布和复盘。

每一次转换都会丢信息，也会混入猜测。开发 Harness 的作用，就是在这些转换点放控制面，让信息不要随便变形。

所以，Harness 不是让开发变慢的流程。它是让开发在速度变快以后，仍然不失控的结构。

三、AI 时代最危险的是“合理的脑补”

AI 的强项和风险，常常是同一件事：它特别擅长补全。

上下文不完整，它会补。目标不清楚，它会补。边界没写，它会补。测试没覆盖，它也会补一段解释，让你觉得问题不大。

人也会脑补，但人脑补得慢。AI 脑补得快，而且语言很顺。顺到什么程度？顺到你会忘记它中间其实没有证据。

比如你说：“旧接口应该没人用了。”

你只是表达一个猜测。AI 可能在后面的设计里写成：“由于旧接口已无人使用，可以删除兼容逻辑。”

注意，中间那个“应该”消失了。一个假设，变成了事实。

开发 Harness 要做的第一件事，就是把 Fact、Assumption、Unknown 分开。

Fact 是有证据的事实。
Assumption 是当前暂时相信、但还没验证的假设。
Unknown 是还不知道的信息。

只要这三类东西混在一起，AI 越努力，风险越大。

四、真正的控制点是这些

一套实用的开发 Harness，至少要控制五件事。

第一，控制方向。

每个任务先判断它是 Expansion、Hold，还是 Reduction。

Expansion 是扩展能力。Hold 是不扩大范围，只修复、硬化、迁移、清理、提效。Reduction 是收缩范围、下线旧能力、降低复杂度。

为什么要先声明这个？因为不同方向的任务，评价标准完全不同。

如果一个任务是 Hold，却做着做着新增了三个用户可见能力，那就是越界。
如果一个任务是 Reduction，却加了一堆兼容层和配置项，那可能是假减法。
如果一个任务是 Expansion，却没有设计错误态、发布和回滚，那就是只扩能力不扩控制。

第二，控制范围。

每个任务都要写 In Scope 和 Out of Scope。

In Scope 说这次做什么。Out of Scope 更重要，它说这次不做什么。

开发失控，很多时候不是因为没人做事，而是因为太多人顺手做了相关但不属于这次的事。

第三，控制事实。

Research 阶段只做研究，不写方案。列出现有代码怎么做、已有测试覆盖什么、日志显示什么、哪些是猜测、还有哪个问题阻断。

这一步像刹车。不是为了停住，而是为了让后面的加速有方向。

第四，控制执行边界。

AI 写代码时，要明确允许改哪些文件、禁止改哪些文件、不能改变哪些契约、发现范围外问题时只记录不修。

不要指望一句“别改太多”能管住 AI。它需要明确边界。

第五，控制证据。

任务结束不能只写“测试通过”。要写清楚：跑了什么命令，验证了什么路径，输入是什么，输出是什么，哪些没测，剩余风险是什么。

没有证据的完成，只是一种情绪。

五、最小可用 Harness

如果任务很小，不一定要写完整文档。但至少可以保留这十行：

1
2
3
4
5
6
7
8
9
10
Mode:
Goal:
In Scope:
Out of Scope:
Facts:
Assumptions:
Unknowns:
Allowed Changes:
Forbidden Changes:
Validation:

这十行并不复杂，但它们分别挡住了不同的失控点。

Mode 挡住方向漂移。
In Scope 和 Out of Scope 挡住范围膨胀。
Facts、Assumptions、Unknowns 挡住脑补。
Allowed Changes 和 Forbidden Changes 挡住无关改动。
Validation 挡住没有证据的完成。

如果这十行写不出来，不要急着改代码。

六、这不是流程崇拜

我并不喜欢为了流程而流程。很多流程确实只是把人拖慢。

但 Harness 不是那种东西。它的价值不在于格式，而在于它能减少返工、误判和救火。

真正拖慢开发的，从来不是几行边界说明，而是这些事：

  • 做完才发现问题定义错了。
  • 测完才发现只测了成功路径。
  • 上线才发现缺配置。
  • 回滚时发现新数据旧代码不认识。
  • 复盘时发现证据散在聊天记录、终端和脑子里。

这些才贵。

Harness 的目标，是让每一次“我以为”，都变成可以检查、验证、回滚和复盘的东西。

七、AI 编程真正严肃的地方

AI 编程刚开始流行时，大家讨论最多的是效率：能不能快十倍，能不能少写代码，能不能一个人做一个团队的事。

这些都重要。但真正严肃的地方，是当代码生产能力变得很便宜以后，确定性变得更贵了。

你不再缺生成代码的能力。你缺的是判断这段代码该不该生成、生成到哪里停、怎么知道它对、出事怎么退、下次怎么不再犯同样的错。

换句话说，未来工程师越来越像在设计一个代码生产系统。

代码只是结果。Harness 才是让结果可靠地产生的那套控制面。

如果要用一句话总结：

AI 让开发跑得更快，Harness 让开发还能跑在路上。

发表于 | 分类于

happy-nil-empty-error：代码Review的四条路径

Review 最常见的失败，是把“看过了”误认为“审过了”。

看过 diff，不等于审过行为。总结改动，不等于发现风险。提了几个风格建议，不等于覆盖边界。说“整体没问题”，不等于系统真的安全。

好的 Review 不是礼貌地复述改动，而是主动寻找行为错误。

我现在最常用的最低基线，是四条路径：

1
2
3
4
happy
nil
empty
error

这四个词很朴素，但能抓住大量真实问题。

一、Happy：正常世界是否成立

Happy path 检查正常输入、正常权限、正常依赖下，主流程是否成立。

它要问：

  • 正常用户能不能完成操作？
  • 主流程是否返回正确结果？
  • 新旧调用方是否兼容？
  • 用户可见行为是否符合需求？
  • 成功路径是否有测试或人工验证？

Happy path 是最容易被测到的路径，也是最容易让人过早放心的路径。

一个导出功能正常生成文件，一个设置页正常保存选项，一个列表正常展示数据，这都只是说明系统在正常世界里能工作。

但真实世界不总是正常。

所以 happy path 是起点，不是终点。

二、Nil：缺失时会不会炸

Nil path 检查缺失。

缺用户、缺 token、缺配置、缺依赖、缺字段、缺缓存、缺 navigator、缺文件。很多线上问题，不是因为逻辑多复杂，而是因为你以为一定存在的东西不存在。

Nil path 要问：

  • nullable 字段是否处理？
  • 缺用户、缺 token、缺配置时会怎样？
  • 是否存在直接解包、空指针、未判空访问？
  • 缺依赖时是 fail fast，还是悄悄产生半成功状态？
  • nil 和 empty 有没有混用？

举个例子。

一个 iOS 设置页在正常情况下能保存 preset。但如果 navigator 没绑定，点击设置会不会崩？如果 UserDefaults 里没有这个 key，是回到默认值，还是显示一个错误高亮？

这就是 nil path。

它经常抓到“本地能跑、线上炸”的问题。因为本地开发环境通常配置齐全、用户状态完整、fixture 数据漂亮。

三、Empty：空不是缺，也不一定是错

Empty path 检查“存在但没有内容”。

空字符串、空数组、空结果集、零条记录、空响应。

很多 bug 来自 nil 和 empty 被混在一起。

空列表不是缺列表。空字符串不是缺字段。零条记录不是查询失败。接口返回空数组，可能是一次成功的空结果，而不是异常。

Empty path 要问：

  • 空列表是否显示空态，而不是报错？
  • 空搜索结果是否是正常结果？
  • 空输入是否需要拒绝？
  • 空内容是否允许保存？
  • 空响应是否会触发无限 loading 或无限重试？

举个例子。

搜索页面请求成功，返回空数组。正确行为应该是显示“没有找到结果”，并给用户一个修改关键词的入口。错误行为是显示“加载失败”，或者一直转圈。

这类问题看起来小，但非常影响用户信任。

Empty path 的关键是语义。空不一定错，要看需求怎么定义。

四、Error：世界不配合时会怎样

Error path 检查失败。

网络超时、数据库失败、权限不足、磁盘满、第三方接口 500、JSON 解析失败、任务取消、并发冲突。

Error path 要问：

  • 错误是否被捕获？
  • 错误语义是否正确？
  • 用户是否看到合理反馈？
  • 日志是否可定位？
  • 指标是否可观察？
  • 是否需要重试？
  • 重试是否幂等？
  • 失败后状态是否可恢复？

很多系统不是在成功时分出高下，而是在失败时分出高下。

比如导出任务：文件上传成功了，但数据库状态写回失败。这不是简单的失败。它是半成功。如果系统从头重试，就可能重复上传文件。如果系统直接标记 failed，用户会看到失败，但实际上文件已经生成。

这种问题，happy path 永远抓不到。

你必须专门问 error path。

五、Review 不是建议越多越好

坏 Review 经常堆满细节建议：

  • 变量名可以更好。
  • 这里可以抽函数。
  • 这里可以换一种写法。
  • 这个注释不够优雅。

这些建议不一定错，但如果它们淹没了真正的行为风险，Review 就失败了。

Review 的优先级应该是：

  1. 阻断性行为错误。
  2. 可能导致数据、权限、稳定性问题的风险。
  3. 测试缺口。
  4. 契约和发布风险。
  5. 可维护性建议。

风格建议应该让路给行为问题。

六、Review 要贴着任务 Mode

同一段 diff，在不同 Mode 下 Review 重点不同。

如果任务是 Expansion，要问：

  • 新能力是否有完整状态流？
  • 错误态是否设计？
  • 发布和回滚是否考虑？
  • 新接口是否有契约测试？

如果任务是 Hold，要问：

  • 是否保持既有契约？
  • 是否只修当前问题？
  • 是否避免不必要重构？
  • 是否补了回归测试？

如果任务是 Reduction，要问：

  • 旧入口是否真正收口？
  • 删除是否有证据支持？
  • 兼容入口是否有清退说明？
  • 回滚是否可行？

没有 Mode 的 Review，很容易用错尺子。

七、一个好 Finding 应该长什么样

不要写：

1
建议增强错误处理。

这句话太软，不能行动。

改成：

1
2
3
4
5
[P1] 重试路径可能重复上传文件
Path: error
Trigger: 上传成功，但状态写回失败，重试从生成文件重新开始
Risk: 产生重复导出文件，用户状态不一致
Required validation: 从 uploaded_pending_persist 状态重试时，断言 renderer 和 uploader 不会再次调用

这才是有用的 Review。

它说明了路径、触发条件、风险和需要补的验证。

八、让 AI 做 Review 时要禁止它总结

AI 做 Review 时，最容易输出这种东西：

1
本次修改优化了导出逻辑，增加了错误处理，并补充了测试。整体结构清晰。

这不是 Review，这是摘要。

你应该明确要求：

1
2
3
4
请以代码审查姿态输出，优先寻找 bug、行为回归、边界遗漏和测试缺口。
不要先总结 diff。
按 happy、nil、empty、error 四条路径检查。
如果没有发现问题，也要列出剩余测试缺口。

AI 很适合做边界扫描，但前提是你要求它扫描边界，而不是让它“看看”。

九、四路径的真正价值

happy、nil、empty、error 并不是完整的软件质量模型。

但它们有一个巨大优点：简单、稳定、容易记。

每次 Review 前扫一遍：

1
2
3
4
正常路径成立吗？
缺失值会炸吗？
空结果语义对吗？
失败后状态安全吗？

很多问题就会浮出来。

这四条路径的价值，不在于它们高级，而在于它们能把 Review 从“我看了一遍”变成“我攻击了四个方向”。

发表于 | 分类于

把测试通过变成验收证据

“测试通过了”不是证据。

它最多是证据的标题。

真正有用的测试证据，要能回答：

  • 测了什么行为？
  • 用了什么输入？
  • 控制了哪些依赖？
  • 覆盖了哪些路径？
  • 命令是什么？
  • 输出是什么？
  • 哪些风险还没测？
  • 这个结果能不能支持验收？

如果这些问题答不上来，一句“测试通过”并不能让系统更安全。

一、测试不是越多越好，而是越贴边越好

很多项目会陷入一种焦虑：测试覆盖率越高越安全。

覆盖率有价值，但覆盖率不是安全本身。你可以写很多不痛不痒的测试，也可以漏掉真正会让线上出事的路径。

测试要贴着问题定义、设计边界和失败模式。

一个改动如果是修复状态写回失败，最重要的测试不是“导出成功”。最重要的是：

  • 上传成功但状态写回失败时，任务是否保留可恢复状态。
  • 重试是否幂等。
  • 重复触发是否不会生成两个导出文件。
  • 状态为空或历史状态不认识时是否降级。
  • 依赖失败时是否留下可观测错误。

这叫贴边。

二、把测试结果写成台账

我现在更喜欢用测试证据台账，而不是只写一段测试总结。

格式可以很简单：

1
2
3
4
5
6
| 链路 | Path | 输入 / Fixture | 命令 | 结果 | 证据 | 风险 |
| --- | --- | --- | --- | --- | --- | --- |
| 导出成功 | happy | articleWithBody | npm test export.success | pass | terminal log | 无 |
| 缺 token | nil | expiredSession | npm test export.auth | pass | terminal log | 只覆盖 API 层 |
| 空文章 | empty | emptyArticle | npm test export.empty | pass | golden diff | 未覆盖 UI |
| 上传超时 | error | fakeUploaderTimeout | npm test export.timeout | pass | terminal log | 未跑真实存储 |

这张表的价值不是好看，而是让验收者能迅速判断：证据够不够支持发布。

它把“测试通过”拆成了具体问题：

  • 通过的是哪条链路？
  • 属于 happy、nil、empty、error 哪个路径？
  • 输入是什么？
  • 用什么命令验证？
  • 证据在哪里？
  • 风险是否仍然存在？

三、没有测到的也要写

成熟的测试证据不是假装覆盖一切，而是诚实写出没覆盖什么。

例如：

1
2
3
4
Not Covered:
- 未跑真实对象存储，只用 fake uploader 验证超时语义。
- 未跑旧客户端回归，当前根据接口兼容性分析判断风险低。
- 未跑高并发重复导出，记录为后续性能测试。

这比一句“测试通过”有价值得多。

未覆盖风险不是失败。隐藏未覆盖风险才是失败。

工程里真正危险的不是“我们知道这个风险还没测”，而是“大家以为它测过了”。

四、区分 Test Plan 和 Test Blueprint

一个常见混乱，是把“未来想测什么”和“现在已经测了什么”混在一起。

所以要区分 Test Blueprint 和 Test Plan。

Test Blueprint 是目标态自动化蓝图。它可以写：

  • 将来应该补哪些层级的测试。
  • 哪些路径适合单元测试。
  • 哪些路径适合集成测试。
  • 哪些路径需要 UI 自动化。
  • 哪些路径只能人工验收。

Test Plan 是当前可执行验证。它必须写：

  • 本次实际跑哪些命令。
  • 预期结果是什么。
  • 实际结果是什么。
  • 证据在哪里。
  • 哪些没测。

Blueprint 可以理想，Plan 必须诚实。

如果把 Blueprint 当成 Plan，你会得到一种虚假的安全感：文档里看起来什么都覆盖了，但实际上当前没有一条证据。

五、Fixture、Mock、Stub、Fake 的边界

测试证据链离不开依赖控制。

Fixture 是测试输入和环境样本。

坏 fixture 叫：

1
2
3
user1
article1
payload1

好 fixture 叫：

1
2
3
4
5
loggedInUser
articleWithLongBody
emptyArticle
expiredSession
exportTaskUploadedButStatusNotPersisted

命名本身就是测试文档。

Stub 提供固定返回，适合控制简单依赖，比如配置读取、时间、当前用户。

Mock 关注交互是否发生，适合验证“是否调用了某个依赖”“调用参数是什么”“调用次数是否正确”。Mock 用多了会绑死实现细节，所以要谨慎。

Fake 是可工作的轻量实现，比如内存数据库、内存队列、临时文件系统、假的上传服务。Fake 通常比 mock 更适合测试状态流，因为它允许行为自然发生，而不是只验证调用。

选择原则：

  • 想控制输入，用 fixture。
  • 想固定返回，用 stub。
  • 想验证交互，用 mock。
  • 想模拟真实行为，用 fake。

六、验收不是跑完测试

测试通过只是验收材料之一。

验收要回答更大的问题：

  • 本次目标是否完成？
  • In Scope 是否全部覆盖？
  • Out of Scope 是否没有被带入？
  • 关键路径是否验证？
  • 四路径是否覆盖？
  • 哪些风险没有覆盖？
  • 是否需要发布？
  • 如果发布，如何观察？
  • 如果失败，如何回滚？

也就是说，验收是把需求、设计、测试、review 和发布风险收束到一个判断。

验收结论最好不要只有“通过 / 不通过”。

可以分成三类：

  1. Accepted for current scope。
  2. Accepted with residual risks。
  3. Not accepted; requires fix。

第二类很重要。很多真实任务不是零风险，而是在明确风险后接受。

例如：

1
2
3
4
5
6
Accepted with residual risks.

Reason:
- 本次覆盖了 service 层 happy / nil / empty / error。
- 未跑真实对象存储集成测试，但 fake uploader 覆盖了超时语义。
- 由于本次改动不改变存储接口，接受该风险。

这比“通过”更诚实，也更适合复盘。

七、发布前还要问观察和回滚

如果一个改动会影响用户、数据、接口、配置、队列、存储、权限、支付、同步或后台任务，就不能只靠测试结束。

发布前还要问：

  • 发布后观察多久？
  • 看哪些指标？
  • 看哪些日志？
  • 哪些用户路径要冒烟？
  • 什么条件触发回滚？
  • 回滚命令是什么？
  • 回滚会不会破坏新数据？

没有观察窗口的发布，本质上是在靠感觉。

一个更好的发布观察写法是：

1
2
3
4
5
6
7
8
Observe Window: 发布后 30 分钟
Signals:
- export_job_failed_total 不高于过去 7 日同时间均值 20%
- export_job_retry_total 无异常尖峰
- status_persist_failed 日志不连续出现
Rollback Trigger:
- 导出失败率连续 10 分钟超过基线 2 倍
- 出现重复导出文件

这才是把发布拉进控制面。

八、完成必须带证据

任务结束时，最好的收尾不是“已完成”，而是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Changed:
-

Validated:
-

Not Covered:
-

Residual Risks:
-

Follow-up:
-

这几项看起来普通，但它们能显著减少后续扯皮和返工。

“测试通过”是一句话。
“验收证据”是一组可复查事实。

AI 时代代码会来得越来越快。越是这样，我们越需要把测试从一个动作，升级成一条证据链。

发表于 | 分类于

如何约束AI写代码：Mode边界和证据链

让 AI 写代码，最重要的不是 prompt 写得花，而是任务边界写得硬。

很多人使用 AI 编程的方式，是把愿望丢给它：

1
帮我优化一下这个功能，注意代码质量。

这句话看似礼貌，实际很危险。它没有告诉 AI 这是什么类型的任务，也没有告诉它哪些文件能改、哪些不能改、哪些行为不能变、发现旁支问题时该停还是该修。

AI 收到这种指令，只能自己补全边界。补得好，是运气；补得坏，也不奇怪。

一、AI 的强项和危险是同一件事

AI 很擅长补全。

你给它一段不完整上下文，它会补全缺失逻辑。你给它一个模糊目标，它会补全任务范围。你给它一个失败测试，它会补全实现。你给它一组 diff，它会补全解释。

这就是它的力量，也是它的风险。

在人类开发里，模糊有时会停下来。因为人会问，或者会卡住，或者会因为不确定而慢一点。AI 不一定会卡住。它更可能生成一个看起来完整的答案。

越流畅，越容易让人忘记中间有多少猜测。

所以，AI 协作的第一原则不是“让它更聪明”，而是“让它必须暴露不确定性”。

二、先声明 Mode

每个 AI 开发任务，先声明 Mode。

Expansion：扩展能力。
Hold：修复、硬化、迁移、清理、提效，不扩大范围。
Reduction：收缩、下线、删除、降低复杂度。

Mode 不是标签。它是约束。

如果任务是 Hold，AI 就不应该顺手加新功能。
如果任务是 Reduction，AI 就不应该加一堆兼容分支让复杂度继续膨胀。
如果任务是 Expansion，AI 就必须考虑错误态、测试、发布和回滚。

你可以这样写：

1
2
3
4
5
Mode: Hold
目标：修复导出任务偶发失败。
为什么是 Hold：本次只修复和硬化已有导出链路，不新增导出格式。
为什么不是 Expansion：没有新增用户能力。
为什么不是 Reduction：没有下线旧能力。

这几行会让 AI 的工作方式完全不同。

三、边界要写成硬规则

不要对 AI 说“尽量别改太多”。

这句话太软。你应该写：

1
2
3
4
5
6
7
8
9
10
11
Allowed Changes:
- 修改 ExportService。
- 修改 ExportServiceTest。
- 如需新增 test helper，只能放在 test support 目录。

Forbidden Changes:
- 不改导出 UI。
- 不改 StorageClient 接口。
- 不新增导出格式。
- 不做全仓格式化。
- 不修 unrelated lint。

这种写法没有那么优雅，但非常有效。

AI 不是不听话，而是它不知道你的隐含边界。你不写，它就会推断；它一推断，就有可能把“相关”当成“应该做”。

边界越清楚，AI 越能发挥执行能力。

四、Research-first 是刹车

AI 开发最容易出事的时刻，是它还没理解代码库就开始改。

所以第一道 Harness 是 research-first：

1
2
3
4
5
6
先研究代码库现实，不写代码。
列出相关文件。
列出现有实现。
列出已有测试。
区分 Facts、Assumptions、Unknowns。
最多保留一个阻断问题。

这个阶段像刹车。不是为了停住，而是为了让后面的加速有方向。

Research-first 还有一个价值：它能让你提前看到 AI 是否理解错了。

很多错误如果等到 diff 出来才发现，已经晚了。如果 research 阶段就发现 AI 把项目结构、业务名词或失败路径理解错了，修正成本很低。

五、把事实、假设、未知分开

这是约束 AI 的关键动作。

你要让它明确输出：

1
2
3
4
5
6
7
8
9
10
11
12
Facts:
- 当前导出任务由 ExportWorker 执行。
- 测试只覆盖正常导出成功。
- 日志显示上传成功后出现状态写回超时。

Assumptions:
- 用户看到失败可能来自状态写回失败。
- 重试可能会重复生成文件。

Unknowns:
- 当前是否有幂等 key。
- 旧导出文件是否会清理。

这三类东西必须分开。

Fact 可以支撑设计。Assumption 需要验证、隔离或写进风险。Unknown 要么补研究，要么明确不阻塞当前阶段。

如果不分开，AI 很容易把假设写成事实语气。

六、Dirty Worktree 是协作边界

AI 工作时，脏工作区是一个重要信号。

脏工作区可能意味着：你正在做另一件事，另一个 agent 留下了中间产物，脚本生成了文件，或者当前任务已经有未提交改动。

AI 不能把脏工作区当噪音。

任务里应该写：

1
2
3
如果工作区有未提交改动，先报告与当前任务相关的文件。
不要覆盖无关用户改动。
如果某个脏文件是本任务必须修改的，先读懂它，再继续。

这条规则看似普通，但非常关键。没有它，AI 很可能在“整理代码”的过程中覆盖别人还没保存好的意图。

七、让 AI 输出证据，而不是情绪

AI 最差的收尾方式是：

1
已完成。

这句话没有价值。

好的 AI 收尾应该包含：

  • 改了哪些文件。
  • 为什么这么改。
  • 跑了哪些验证。
  • 验证结果是什么。
  • 哪些没测。
  • 剩余风险是什么。
  • 哪些发现属于后续任务。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
完成了 token 过期状态流修复。改动集中在 AuthSessionStore 和对应测试，没有修改登录 UI 或 token refresh API。

验证：
- testExpiredTokenRoutesToLogin: pass
- testMissingNavigatorDoesNotCrash: pass
- testEmptyCachedTokenClearsSession: pass
- testRefreshFailureKeepsRecoverableState: pass

未覆盖：
- 未跑完整 UI 自动化。
- 未覆盖旧客户端真实请求。

剩余风险：
- 旧缓存格式兼容只通过单元测试验证，未在真实设备回归。

这才是能被接住的交付。

八、一个可复制的任务模板

你可以直接复制下面这段给 AI：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Task:
<一句话描述任务>

Mode:
Expansion / Hold / Reduction

Goal:
本次真正要解决的问题是：

In Scope:
-

Out of Scope:
-

Research Rules:
1. 先 research，不直接改代码。
2. 区分 Facts / Assumptions / Unknowns。
3. 如果发现范围外问题，只记录到 residual risks，不顺手修。

Allowed Changes:
-

Forbidden Changes:
-

Review Rules:
按 happy / nil / empty / error 检查。

Validation:
必须记录命令、预期结果、实际结果、未覆盖风险。

它不华丽，但很实用。

九、AI 不是混乱的解药

AI 不是混乱的解药。没有 Harness，AI 会让混乱跑得更快。

但有了 Harness，AI 是非常强的执行器、检索器、测试补全器和风险扫描器。

问题不在 AI。问题在任务有没有被装进控制面。

你要做的，不是把 AI 变成一个“更听话的人”，而是把任务变成一个它能安全执行的结构。

发表于 | 分类于

1

五月份状态很差，连月报都没有写。上一次没有写月报，可以追溯到好几年前。真的很不应该。这次月报就两个月合并到一起写吧。

四月份阅读306.5小时，冥想24.4小时。五月份阅读278小时，冥想11.7小时。数据不理想，而且呈严重的下滑趋势。

接下来跟大家分享我打算执行的三项改进措施。

2

我要做的第一项改进措施很简单，就是坚持每个月1号把月报发出来。

写月报不能拖。我发现了，只要我一拖，就会拖很久。拖着拖着，就很容易不把当月的目标当回事。

不把当月的目标当回事，就很容易状态松懈。看书不好好看了，冥想不好好做了，把时间浪费在各种各样的分心事项上。

3

第二项改进措施是坚持锻炼。

最近一个月没有坚持锻炼，健身房就只去了6次。按之前的频率，一个月至少要去健身房16次以上。

少去健身房，就很容易熬夜。一熬夜，身体状态就会变差。身体状态变差，看书和冥想都不会好好完成。

从下周开始，要恢复锻炼，一周至少三练，理想的话是恢复到之前的一周四练。

4

第三项改进措施是多用AI。

近段时间用AI的次数的确减少了。Codex的额度不仅每周都没用完，而且常常只使用10%到30%。跟ChatGPT对话的次数也少了很多。

跟很多人的想象不一样。多用AI，不仅不会让自己少动脑，反而会多动脑。因为只有多动脑，我们才会有更多的想法让AI帮我们去实现。

多用AI，多用脑。多用脑，就会有更多的好奇心。有更多的好奇心，就会想着多看书，多寻找灵感。

从即刻开始，每周Codex的额度都要用完，每天至少跟ChatGPT对话1小时。

5

这么多年来，很多关注我的朋友都会夸我自律，夸我能坚持。但是最近这一个多月，我真的很不自律，很不能坚持。

我倒不会觉得很愧疚，很难受，更不会就此摆烂。我觉得这是正常的起起伏伏，即便这一次的确状态差得有点离谱。接下来好好改进就是了。

截至2026年5月31日，我一共阅读了20690小时。预计会在2029年11月15日，完成第三个10000小时，也就是总共30000小时的阅读目标。

六月份的阅读目标是460个番茄时间，也就是230个小时。冥想目标是20小时。