让 AI 写的每行代码都为下一行铺路：复利工程（Compound Engineering）从理念到落地全拆解

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

如果你只想要一句话答案：复利工程的核心，是把开发的精力分配彻底倒过来——大约八成花在"想清楚"和"审查"上，只留两成给"敲代码"，并且每跑完一轮，都强制把这一轮踩到的坑、做对的判断、定下的规矩写成结构化笔记沉淀进项目里，下一轮直接从这个更高的起点出发。 这样做的结果，是让代码库在功能不断增多的同时反而越来越好改，而不是越堆越重。这套打法由 Every 团队在做邮箱助手 Cora 的过程中磨出来，后来开源成一个能装进 Claude Code、Cursor、Codex 等多种 AI 编程助手的插件，目前已经做到 37 个技能加 51 个后台智能体的规模。

我自己把这套东西在几个长期项目里跑了一阵，最直接的感受是：新会话不用再从头解释一遍项目背景了，AI 像是"记住了"上次的教训。下面我会从问题根源讲到完整工作流，再到多平台落地和我踩过的坑——想看完整拆解，往下翻。

一、先说个反常识：你的代码为什么越写越慢

写过一阵子项目的人都有这种体感：第一周加功能飞快，第二个月开始磨叽，到了半年后，改一个看似无关的小地方都要小心翼翼，生怕碰塌别的。

这不是错觉，是工程的默认走向。每加一个功能，就多出一批边界情况、多出几条依赖关系、多出一些"只有当时写的人才懂"的隐藏假设。代码量上去了，需要同时塞进脑子里的上下文也上去了。等到上下文超过你（或者 AI）能稳定握住的容量，判断力就开始打折——这时候你不是在创造，是在和自己半年前留下的复杂度搏斗。

AI 编程助手进来以后，这个问题表面上被掩盖了，实际上被放大了。掩盖在于：敲代码这件原本最费时的事，现在几秒钟就出一大段。放大在于：当生成代码几乎零成本，瓶颈就整体迁移到了"上下文管理"这个环节。AI 没有长期记忆，每开一个新会话就是一张白纸。你上次费半天劲给它讲清楚的项目风格、上次它自己改对的某个棘手 bug、上次你们一起否决掉的某个错误方案——它全忘了，你得重新讲一遍。

我自己最烦的就是这一段。每次新对话开头都要把项目背景、技术约定、那些"千万别动的地方"再复述一遍，复述得越多越容易漏，漏了 AI 就又往坑里跳一次。等于每一轮都在交学费，而且交的是同一笔学费。

更隐蔽的一层麻烦在于，AI 的上下文窗口虽然一直在变大，但"塞得进去"和"用得好"是两码事。你可以把整个代码库都怼进去，但 AI 在海量上下文里真正能稳定抓住的关键信息，其实是有限的。信息越多越杂，它越容易在某个细节上犯迷糊——这就是为什么很多人有个体感：会话聊得越长，AI 越容易"前面说好的后面又忘了"。这不是它不努力，是长上下文本身就在稀释注意力。

所以真正该优化的，从来不是"往 AI 脑子里塞更多东西"，而是"让它每次只读到此刻最该读的那部分高质量信息"。一份当时随手记下的、结构清晰的经验笔记，往往比把十个文件原封不动倒给它管用得多。这个判断，是理解复利工程为什么那么强调"沉淀"的前提。

举个我自己遇到过的具体例子。有个项目里有处历史遗留的时区处理逻辑，特别绕，碰一次塌一次。第一次我花了大半天才搞明白它的脾气、把它绕过去。可几周后开新会话再动相关功能时，AI 又一头扎进去把它改坏了——因为它根本不知道这里有雷。这种"同一个坑反复掉"的体验，相信每个写过长期项目的人都不陌生。它不是某个工具的问题，是"经验没被记下来、下次没被读到"这个结构性缺口造成的。

复利工程要解决的，恰恰就是这个"重复交学费"的问题。它的野心很大：不只是让单次开发更顺，而是想把那条"越做越重"的曲线，硬生生掰成"越做越轻"。

二、复利工程到底在讲一件什么事

把名字拆开看会更清楚。复利这个词不是营销话术，它指向一个非常具体的机制：让本轮产生的价值，自动叠加到下一轮的本金里。

放到工程语境，传统开发的增长方式更像单利甚至负利——你这一轮的劳动成果，对下一轮基本没有正向加成，反而因为复杂度上升带来负担。复利工程想做的，是让每一轮的"经验产出"成为下一轮的"启动资本"。

如果非要用一个直觉化的式子来感受这种差异，可以这么理解：假设你每一轮沉淀下来的可复用经验，能让下一轮的有效效率提升一个很小的比例 r，那么经过 n 轮之后，团队的整体效率大致按下面这个关系增长——

[

E_n = E_0 \times (1 + r)^n

]

这里 (E_0) 是你最初的效率，r 哪怕只有几个百分点，n 一旦够大，复利的尾巴就会甩得很远。关键变量从来不是单次写得多快，而是"经验能不能稳定地沉淀下来、并被下一轮真正读到"。这正是这套方法把全部重心压在"沉淀"上的原因。

为了把这种差异讲得更直观，我喜欢拿存钱来类比。传统开发像是把工资全花光的月光族——这个月到手的劳动成果（这一轮的付出）对下个月（下一轮）没有任何加成，下个月还得从零开始攒。更糟的是，代码库的复杂度像信用卡账单一样在悄悄滚利息，你越往后越觉得被它压着喘不过气。复利工程则像是每个月强制把一小笔钱存进一个会生息的账户：单看一个月毫不起眼，可几年下来，那个账户的增长是非线性的。两种活法，起点可能一样，三年后的差距大到不像同一个人。

它的一句话主张也极其干脆：每写一行代码，都应该让下一行代码更容易写。 莫潇羽在自己项目里反复体会过，这句话听着像口号，落到实处却是一套很硬的流程约束——它逼着你在每个环节都问一句"这一步产出的东西，下一步能不能直接吃进去"。

这套理念的来路也值得一提。它最早不是凭空设计出来的方法论，而是 Every 这家公司在用 AI 从零做一款叫 Cora 的邮箱助手时，一个 PR 一个 PR 地试出来的——先是几个提速的个人小习惯，慢慢沉淀成一套系统化的做法。这套方法的核心哲学是：每一个工程工作单元都应该让后续单元更容易，而不是更难。 提出者认为这会逐渐变成软件构建的默认方式，所以才把它开源分享出来。

还有一个数字很能说明问题：他们团队在内部跑着五款软件产品（还在孵化几款新的），每一款基本都由一个人主导构建和运营，而这些产品被成千上万人每天用于正经工作，不是花架子 demo。 一个人撑起一款被几千人日常使用的产品，靠的不是手速，是这套让 AI 越用越聪明的循环。

这个"一个人撑起一款产品"的现实，其实改写了很多人对软件开发的旧认知。过去我们默认"工程师很稀缺、写代码很难"，所以才有那么多分工、那么厚的流程。当 AI 让写代码这件事不再是瓶颈，那些建立在"代码难写、工程师稀缺"假设之上的传统做法——比如手动逐个写测试、费劲地敲一行行带大量注释的人类可读代码——就显得慢而过时了。 正是为了应对这种约束的变化，这套新的工程方式才被提出来。理解这个背景，你就明白复利工程不是某个人灵光一现的小聪明，而是对"AI 时代该怎么做工程"这个大问题的一种系统性回应。

值得一提的是，这套思路并不局限于写代码。同一批人后来还把它迁移到了知识工作上——头脑风暴、做计划、审查、执行、沉淀，同样的五步循环，照样能让脑力活儿产生复利。这从侧面说明，"每一轮都为下一轮存本金"这个内核，是个相当通用的方法论，代码只是它第一个落地的场景。

三、把精力重新分配：规划与审查占八成，执行只占两成

这是整套方法里最容易被低估、也最该先扭转过来的一条认知。

传统流程的精力曲线大概是这样的：稍微想一下要做什么 → 一头扎进去写 → 跑起来 → 一边修 bug 一边骂自己 → 勉强合并。绝大部分时间被"执行"和"擦屁股"吃掉了。

复利工程把这个比例硬生生倒过来：

为什么敢把执行压到两成？因为在 AI 把"敲代码"变成近乎免费之后，决定成败的早就不是写得快不快，而是"有没有想清楚"和"有没有审到位"。

打个不太严谨但好懂的比方：以前盖房子，砌砖（执行）是最累最慢的，所以图纸（规划）画得糙一点也无所谓，反正砌的时候还能现场补。现在有了能瞬间砌好一面墙的机器，砌砖不再是瓶颈了——可如果图纸是错的，机器只会更快地把错的东西盖出来，而且盖得又大又结实，拆起来更费劲。AI 写代码就是那台砌墙机器，它越快，前置的图纸（规划）和事后的验收（审查）就越关键。执行环节的提速，反而把价值整体逼到了它的两头。

先说规划这头。规划阶段做的事远不止写需求——它会去研究现有代码库，避免重新发明已经有的轮子；会主动去挖用户可能走出的、需求里没预料到的边界路径；还会检查项目里已有的设计模式并要求遵循。 这些活儿如果靠人临场想，十有八九会漏。前置把它们想干净，后面执行就几乎不需要返工。规划的产物是一份足够具体的实施计划文档，具体到一个 AI 智能体或者一个人类工程师拿起来就能直接执行、不用再回头问问题的程度。

再说审查这头。审查不只是看代码对不对，更重要的是看"这一轮我们学到了什么"。这一步既是质量闸门，也是给"复利"环节喂料的源头——你不审，就提炼不出经验；提炼不出经验，复利就无从谈起。

至于执行那两成，它在整套流程里反而是最不需要操心的部分。前面想得越细，执行就越像照着图纸搭积木。我自己的体会是：当你真正把功夫下在前八成，执行阶段经常是"诶，怎么这么顺就跑通了"的状态，那种顺，是前面省出来的。

这里要提醒新手一句：八二开不是说你只干两成活、剩下让 AI 全自动。恰恰相反，规划和审查这八成正是最需要人类判断力的地方——AI 负责把方案铺开、把代码生成、把多个角度都查一遍，而你负责在关键路口做取舍。在一次公开演示里，作者就强调了在计划阶段加入人类判断的必要性：当加密、性能这类需求会引入隐藏的复杂度时，要果断做减法、把方案简化下来。 这种判断，AI 替不了。

四、一个完整的闭环长什么样

讲清了理念和精力分配，来看流程本身。最精炼的版本是一个四步循环：规划 → 执行 → 审查 → 复利。一个复利工程师的角色，是编排一群并行运行的智能体，让它们去规划、编写、评估代码：规划阶段，智能体读取问题、研究方案、把信息综合成详细的实施计划；执行阶段，智能体按计划写代码、建测试；审查阶段，工程师既审产出本身，也审从产出里得到的教训；复利阶段，工程师把结果反哺回系统，让整个体系从成功和失败里学习，下一轮因此变得更好——魔法就发生在这一步。

在开源插件里，这个四步循环被展开成了更完整的一条链，每个环节对应一个可以直接调用的命令（这类命令通常以斜杠开头，比如 /ce-plan，是你在 AI 编程助手里下达指令的入口）。整条链大致是这样：

flowchart TD
    A[ce-strategy 定方向 可选] --> B[ce-ideate 大方向发散 可选]
    B --> C[ce-brainstorm 把模糊想法变需求]
    C --> D[ce-plan 把需求变实施计划]
    D --> E[ce-work 隔离执行]
    E --> F[ce-code-review 多智能体审查]
    F --> G[ce-compound 把经验固化下来]
    G -. 下一轮从更高起点开始 .-> C
    H[ce-debug 系统化排错] --> F

这张图里有两条值得注意的线。第一条是主循环的回流箭头：ce-compound 沉淀的经验会反哺回 ce-brainstorm 和 ce-plan，让下一轮一开局就站得更高。第二条是 debug 的旁路：排错有自己的专属入口，修完同样汇入审查和复利，让一次排错也能变成可复用的经验。

落到实际操作，一个常规功能的完整命令序列差不多是这样（这是个示意，重点是体会"一步喂一步"的链式关系）：

# 1. 把一个模糊想法整理成需求文档
/ce-brainstorm "让后台任务的重试机制更安全"

# 2. 把需求文档喂给规划，产出详细实施计划
/ce-plan docs/brainstorms/background-job-retry-safety.md

# 3. 按计划执行
/ce-work

# 4. 多角度审查这次的产出
/ce-code-review

# 5. 把这轮学到的东西沉淀下来
/ce-compound

如果是排查线上问题，路径会短一些，从专门的排错入口进去，跑完同样别忘了沉淀：

/ce-debug "结账回调偶尔会重复生成发票"
/ce-code-review
/ce-compound

你会发现每条链的最后都是 /ce-compound。这不是顺手加的，而是整套设计的命门——少了这一步，前面所有的功夫都只服务于这一轮，下一轮你还得从零开始。

再多说一句这条链的设计哲学：每个环节都有明确的"输入"和"输出"，且上一环的输出恰好是下一环的输入。这种环环相扣不是为了好看，而是为了让整条流程能像流水线一样自动衔接、尽量减少人工搬运。需求文档是规划的输入，规划产出的计划是执行的输入，执行的产出和过程日志又成了审查和复利的素材。作者把这一点总结得很到位：核心就是一个四步循环，每一步有特定的输入和特定的输出，一步的输出成为下一步的输入。 当你真正按这个链路跑顺，会有种"东西在自己往前淌"的顺滑感，你只需要在几个关键环节上把把关、做做判断。莫潇羽@源码七号站 自己跑下来印象最深的，就是这种"流程自己往前推、我只在岔路口拍板"的体验——它把人从大量机械搬运里解放出来，让你的注意力集中在真正需要人类判断的地方。

需要提醒的是，这条链不是非得每次都从头跑到尾。常规功能开发可能从需求整理进入，线上排查从专属排错入口进入，小修小补甚至可以只跑执行加审查。关键是无论从哪进，结尾尽量都收在复利那一步——把这一趟学到的东西留下来。链路是灵活的，但"沉淀"这个收尾动作，是莫潇羽建议你无论如何都别省的。

五、把每个环节拆开看，它们到底在替你干什么

上面的全景图看着环节不少，但每一环的职责其实非常清楚，而且彼此不越界。我按"从拍板方向到沉淀经验"的顺序，挨个讲一遍。

先把方向钉死：定战略与发散想法

最前面有两个偏"务虚"但很关键的环节。

一个负责锚定产品方向，它会帮你产出一份方向文档，记下这个产品到底在解决什么问题、核心思路是什么、用户是谁、关键指标看哪几个。这份文档之后会被需求、规划等环节反复读取，确保所有技术决策不跑偏。莫潇羽特别想强调：如果你做的是个人长期项目，这个环节的价值会被放大——它防止你做到第三周的时候，忘了第一周到底想干嘛。这种"自己把自己绕进去"的事，独立开发者太熟了。

另一个负责在真正动需求之前先把大方向发散开：生成多个想法 → 批判式地逐个评估 → 排序 → 把最强的那个推进到下一步。它产出的是"想法排名"，而不是需求文档，所以不会越级抢后面环节的活。这个环节适合"我知道大概要做点什么，但还没想好具体做哪个"的阶段。

这两个环节都标着"可选"。一次性的小脚本完全可以跳过；但只要项目有持续性，它们就是后面所有环节的定盘星。

我多说一句方向文档的用法。它不是写完锁进抽屉的，而是要被后面环节反复读取的。所以它的价值不在于一次写得多漂亮，而在于它逼着你把"这个产品到底为谁解决什么问题"用文字钉下来。很多个人项目做着做着就跑偏，本质是这个锚从来没被写下来过，全凭脑子里那点会随时间漂移的印象。一旦白纸黑字写下来，后面 AI 帮你出方案时，就有了一把对照的尺子——任何偏离方向的提议，对着这把尺子一量就露馅。莫潇羽自己的几个长期项目，都是吃过"方向漂移"的亏之后才老老实实补上这一环的。

把模糊想法熬成需求：交互式问答

接下来是把一句模糊的"我想做个 XX"，熬成一份大小合适的需求文档。

它的做法不是上来就让你写代码，而是通过一问一答，把你脑子里那团还没成形的想法一点点逼清楚：到底要做成什么样？哪些是必须的、哪些是锦上添花？边界在哪？等问答跑完，它把结论写成需求文档，归档到项目里专门的目录。

这一步我觉得是最考验耐心的。人的本能是想跳过它直接开干，但凡是跳过这步直接让 AI 写的，后面返工的概率都高得离谱。需求没想清楚，写得再快也是白写。

我自己的做法是，在问答环节尽量诚实地暴露自己的"我还没想清楚"。很多人会下意识地把模糊的地方含糊过去，结果需求文档里全是看似确定、实则没定的坑，执行时这些坑全都会原形毕露。倒不如在这一步就把"这里我也拿不准"摊开来讨论清楚。这一环节产出的需求文档大小是"刚刚好"的——不会大到让你一口吃成胖子，也不会小到没法独立成事，这个"sized-right"的分寸感，是它比你自己随手写需求强的地方。

需求落成可执行计划：给机器读的图纸

需求清楚之后，下一步把它转成一份详细的实施计划。

这里有个容易误解的点：这份计划主要不是给人看的，是给执行环节"吃"的（虽然人也能读）。一份合格的计划会包含数据模型、文件引用、架构决策和信息来源，具体到拿起来就能执行的程度。 规划环节还会做几件原始提示词不会主动做的事：研究现有代码库以免重复造轮子、主动搜寻需求没预料到的边界情况、检查应当遵循的既有设计模式。

我的习惯是在这一步多花点时间盯着计划看一遍，尤其看它有没有把某个隐藏依赖漏掉。计划这一关把得严，执行就基本不用回头。

隔离执行：worktree 是个好东西

到了真正写代码的环节。它不是放任 AI 自由发挥，而是带着任务跟踪、严格按计划一步步推进。

这里有个值得单独拎出来夸的工程细节：每个计划在一个独立的 git worktree 里执行。worktree 是 Git 的一个特性，简单说就是让同一个仓库在不同目录下同时检出不同分支，互不干扰。好处很直接——执行过程中主分支保持干净，万一这次方案跑歪了，整个 worktree 扔掉重来就行，不用费劲清理一堆半成品改动。对于喜欢大胆试错的人来说，这相当于给你配了个随时能丢的草稿本。

对新手解释一下为什么这个隔离重要。很多人让 AI 在主分支上直接改，改着改着发现方向不对，想退回去，结果一堆改动盘根错节，git 状态乱成一团，光是清理就够喝一壶。worktree 把这次尝试关进一个独立的小房间，做成了就合并进来，搞砸了就把整个房间拆掉，外面的世界一点没受影响。这种"试错成本趋近于零"的设计，恰恰是鼓励你大胆让 AI 去探索方案的底气来源——反正错了也不疼。

执行阶段还有个我很认可的取向：它强调按计划一步步走、带任务跟踪，而不是把一整个大任务一股脑丢给 AI 让它自由发挥。AI 自由发挥的问题在于，任务一大，它就容易"跑偏"——做着做着开始自作主张加一些你没要的东西，或者在某个细节上钻牛角尖。把计划拆成有跟踪的小步，等于给它装了护栏，每一步都对着计划核对，跑偏了立刻能发现。

系统化排错：不是把报错贴给 AI 让它猜

排错有专属入口，它的思路和很多人习惯的"把错误信息整段贴给 AI、让它猜"完全不同。它走的是工程化三步：系统化复现问题 → 顺藤摸瓜追到根因 → 实施修复。

差别在哪？贴报错让 AI 猜，本质是赌运气，AI 经常会给你一个"看起来对、其实没碰到病灶"的修法，按下葫芦浮起瓢。系统化排错强调先稳定复现、再定位根因，修的是病根不是症状。这一步跑完接审查、接复利，于是连"这类 bug 该怎么修"都能变成下次直接复用的经验。

举个通用化的例子体会一下两种思路的差别。假设有个虚构的场景：某个回调接口偶尔会重复生成一条记录。贴报错让 AI 猜，它八成会建议你"加个去重判断"——这能让表面现象消失，但没回答"为什么会重复触发"这个根本问题，过段时间它换个姿势又来了。系统化排错会先想办法稳定复现这个"偶尔"：是不是并发？是不是上游重试？把复现条件固定下来，再顺着调用链往回追，最后可能发现根因是上游的重试机制不幂等。找到这个根因，修法就从"打补丁"变成了"补幂等键"，一次性断根。这两种修法的差距，就是"治标"和"治本"的差距，而后者才能沉淀成真正有价值的经验。

多智能体审查：让好几个专家各看各的

审查环节是多个智能体并行工作，每个盯一个维度——有的看安全、有的看性能、有的看正确性、有的看可维护性，最后汇总成一份报告。

为什么不用一个智能体从头看到尾？因为单个智能体在长上下文里会"疲劳"：看得越多，判断越容易滑坡，到后面经常走神漏检。拆成多个各有专攻的智能体，每个上下文短、目标单一，漏检率明显更低。这其实就是把人类团队"找不同领域的专家分别评审"那套，搬到了 AI 身上。在公开演示里，作者展示的正是这种从计划到代码再到子智能体代码审查的端到端流程。

并行还有个隐性好处：速度。几个审查智能体同时开工，比一个挨着看完所有维度要快得多。莫潇羽自己用下来，最看重的其实是"安全"和"可维护性"这两个维度的专职审查——这两块恰恰是人工评审时最容易因为赶进度而草草带过的，交给一个不会偷懒、只盯这一件事的智能体，心里踏实不少。这套体系里甚至有针对特定技术栈的专职审查智能体，比如专门看某种移动端代码的状态管理、循环引用、并发、数据持久化线程安全和无障碍适配。专业的事交给专业的"角色"，这个思路很值得借鉴。

新版插件还在审查之后加了一个有人参与的打磨阶段：它会先核对审查结果和持续集成（CI，简单说就是自动跑测试和构建的流水线）状态，再起一个本地开发服务器，生成一份可逐项验证的清单，然后派出打磨型子智能体去修剩下的小问题。

复利环节：整套系统的发动机

这是名字的来源，也是最重要的一环，我单开一节细讲（见第六部分），这里先占个位：它负责把本轮学到的东西写成结构化笔记存进项目，下次类似任务发生时，AI 先读这些笔记、复用之前的结论，而不是从零开始。一句话，前面六个环节都是在"做事"，唯独这一环是在"让做事这件事本身变得更值钱"——它是整套流程里唯一一个产出会反哺给所有未来轮次的环节。

产品脉搏：让方向决策有真实信号

还有一个偏运营的环节，负责生成单页、按时间窗口切分的"脉搏报告"——用量、性能、错误、接下来该做的动作，都浓缩在一页里，归档到专门目录。

这个设计我觉得挺聪明：一份份历史脉搏报告会自然连成一条可浏览的时间线，下次更新产品方向、做需求发散时，就有真实信号可以锚定，而不是拍脑袋。数据驱动这件事，靠的就是这种把信号持续沉淀下来的小习惯。

你可以把它理解成给产品定期"量体温"。单次的一张报告意义有限，但当你手里攒着连续好几个时间窗口的报告，趋势就出来了——某个功能的用量是在涨还是在跌、错误率有没有在悄悄抬头、性能是不是在变差。这些趋势信号，比任何"我觉得用户会喜欢"的主观判断都靠谱。它和前面那些环节其实是一个思路的两种体现：工程那头沉淀"怎么做"的经验，产品这头沉淀"该做什么"的信号，两条线都在为下一轮决策攒本金。

六、复利的引擎，全藏在"把经验写下来"这件小事里

前面铺垫这么多，现在讲整套方法真正的命门。

复利环节会把本轮循环里学到的东西，写成结构化笔记存进项目。下次遇到类似任务，AI 会先读这些笔记，复用之前的结论。它具体存三类东西：

• 模式：这一类 bug 通常怎么修、这一类需求一般怎么实现。
• 决策理由：为什么当时选了方案 A 而不是 B，背后的权衡是什么。
• 坑：哪个地方碰不得、哪个看似合理的做法其实是陷阱。

听起来平平无奇，对吧？但魔法恰恰在这里。之所以叫复利，是因为这个环节给你的智能体和团队成员造了一个学习闭环：每一个 bug、每一次失败的测试、每一个"啊哈"式的解题灵感，都被记录下来、被未来的智能体使用。代码库的复杂度依然在增长，但 AI 对它的认知也在同步增长，于是后续开发反而越来越快。 这句话我盯着看了很久——它点破了为什么这条曲线能被掰弯：复杂度照常涨，但"对复杂度的理解"涨得更快，一减一加，净效果就是越来越轻松。

那笔记长什么样？它不是随手记在某个角落，而是带着可被检索的结构。一种典型形态是用带 YAML 头信息的 Markdown 文件，跟着代码一起进 Git，随时能用 grep 搜出来。莫潇羽给你举个通用化的例子感受一下：

---
type: insight
tags: [重试, 幂等, 后台任务]
confidence: high
created: 2026-05-30
source: 后台任务重试安全性改造
---

# 后台任务重试的幂等性

重试这类操作，关键不在"重试几次"，而在"每次重试是否幂等"。
若下游接口本身不幂等，光加重试反而会放大重复写入的风险——
正确做法是先给关键写操作补上幂等键，再谈重试策略。

注意这个文件的几个细节：tags 让它能被精准检索，confidence 标明可信度，source 记下出处。这样写下来的笔记不是死档案，而是能在下一轮规划时被自动捞出来、塞进 AI 上下文的"活资产"。

还有一个容易被忽略但特别重要的机制：处理"过时的知识"。经验这东西会过期——你三个月前总结的某条结论，可能因为后来重构了架构而不再成立。一个设计良好的复利环节，在写入新笔记时会去检查：有没有哪条旧笔记和这条新结论是矛盾的