我是安徽最忧郁程序员无隅前言AI 已经完成代码功能可以运行解释也能够听懂。几天之后需求增加了一个条件你能判断原来的实现是否仍然成立吗一次开发任务结束时除了可以运行的功能我们还需要留下能够支持下一次修改的判断依据。订单写入超时后的重试就是一个适合检查这种能力的具体问题。一、功能完成之后哪些知识还没有掌握自己处理一个陌生需求时知识缺口通常会直接影响进度。接口调用失败需要查清参数数据出现重复需要检查写入过程一个修改引发其他错误需要重新理解模块之间的关系。查阅文档、阅读代码和观察运行结果都会让原来的认识接受检验。AI 可以协助完成这些工作。我们还在阅读错误信息它已经找到了相关文件我们还在理解设计它已经提交了能够运行的实现。随后再阅读一份完整解释很容易产生“这部分已经掌握”的感觉。这里需要分别检查两件事情功能是否满足要求以及自己是否具备修改它所需的知识。两者各有证据。前者可以通过需求验收和运行结果检查后者需要观察自己能否解释关键机制、预测条件变化后的行为以及找到验证判断的具体位置。例如你知道重试代码会再次发送请求也能够解释每个参数的用途。但当“创建订单成功客户端没有收到响应”这个条件出现时你是否知道接下来应该检查什么如果只能再次等待 AI 给出解释当前的理解还没有覆盖这项维护责任。开发经验会体现在下一次检查中相似问题出现时能够主动识别关键条件知道需要哪些证据。这也帮助我们确定“理解债务”的范围在需要负责的功能中那些已经影响判断、修改或维护却仍然没有查清的必要知识。这个词可以用来记录具体缺口例如“尚未确认重试是否复用业务请求标识”并据此安排学习。阅读一个成熟库时我们可以通过公开接口和文档使用它。涉及自己负责的写入保证时则需要知道接口承诺依靠什么成立。学习范围应当随责任确定否则很容易在无关细节中消耗时间同时遗漏真正需要检查的机制。二、围绕当前任务确定需要理解的范围面对 AI 生成的一组文件逐行阅读往往缺少明确目标。可以从当前正在修改的能力出发分别追问业务需求和支撑机制。向上理解需求谁在使用这个能力它必须提供什么保证假设你正在为 Agent 工具增加重试。首先需要查清工具做的是查询还是写入一次调用表达了什么业务意图以及调用者如何理解最终结果。创建订单、发送通知、扣减库存都可能产生新的效果重复调用时的业务后果也各有差异。对于创建订单可以把要求写成一个可检查的句子“同一次下单意图发生多次网络请求时最多创建一笔订单调用者能够确认这笔订单的结果。”这句话同时给出了写入要求和结果要求。向下理解机制这些保证依靠什么成立哪些条件变化会影响它们接下来需要沿着调用过程找到事实请求标识在哪里生成后端读取哪个字段重复请求怎样处理相关状态保存在哪里。只要其中一个必要条件还没有确定就无法解释整个保证。下面的表格可以作为阅读代码时的问题清单观察位置需要查清的问题可以寻找的证据业务入口哪些网络请求属于同一次下单意图调用参数、业务编号、入口逻辑重试过程每次发送是否保留同一个去重标识标识的生成位置、各次请求记录后端写入重复请求到达后怎样阻止第二次创建去重记录、写入逻辑、数据库约束状态保存并发执行和服务重启后保证是否仍然成立原子操作、持久化方式、状态有效期结果返回后端已经成功时调用者怎样确认结果接口约定、订单查询、返回内容上下相邻的职责可以帮助确定阅读起点。如果保证依赖更深的事务或并发行为就继续查阅相关实现和文档直到能够说明关键条件。有经验的开发者看到重试可能会立即检查重复执行和状态保存。新人需要通过当前任务建立这种联系。“负责架构和代码审查”本身不会提供判断依据这些依据仍然要通过具体问题、证据和反馈逐渐形成。三、通过预测和实验检验自己的理解阅读解释时推理过程已经由别人组织好了。检验理解则需要自己完成一次推理写下输入和条件说明预期结果再用实际证据检查它。可以把这个过程安排为四个连续动作写下预测。说明当前条件下会发生什么以及判断依赖的前提。设计验证。确定怎样触发这些条件观察哪些请求、日志和数据。解释结果。检查结果是否符合预测找到真正决定结果的代码或约束。改变条件。更换一个有关的条件重新预测并验证检查理解能否用于新情况。下图中实线表示个人预测与验证的顺序虚线表示 AI 提供的资料和日志帮助。改变条件后流程回到预测环节。这个循环要求再次写出自己的判断并找到支持结果的证据。预测需要足够具体。“这个实现应该安全”很难检验“第一次写入已经提交第二次请求携带相同去重标识因此后端应返回已有订单订单数量保持一笔”就包含了可以核查的条件和结果。AI 在这个过程中可以协助查找代码、说明文档、设计实验步骤、整理日志。自己则要保留判断的位置先独立写下预测再阅读它的分析先检查真实请求和数据库记录再讨论解释。给 AI 的问题也可以包含自己的前提和证据我的预测是第二次请求更换去重标识后会产生第二笔订单。实际查询仍然只有一笔。请结合写入代码、数据库约束和两次请求参数指出哪个条件限制了第二次写入并给出对应位置。这样得到的分析可以直接针对理解缺口。检查时也有明确对象证据中的限制是否存在它是否确实参与了这次执行。预测正确之后还要解释正确的原因。如果去重逻辑存在缺口但另一项业务唯一约束阻止了重复写入那么“最终只有一笔订单”这个结果还不足以证明原先对去重逻辑的理解成立。测试通过提供了已覆盖场景中的行为证据。学习是否发生还需要检查自己在测试之前怎样预测、测试之后怎样解释以及条件改变之后能否继续判断。四、具体案例订单写入超时后重试会发生什么以下使用一个假设的订单接口分析判断过程。这里给出的是机制推演和验证设计具体系统的结果需要结合其真实接口、代码和数据库检查。先查清超时发生时哪些事情已经完成假设一次调用经历了这些事件客户端发送创建订单请求携带去重标识K1。后端创建订单O1数据库事务完成提交。响应传输出现延迟客户端达到等待时限。客户端准备再次发送请求。在这个条件下客户端没有得到响应数据库中却已经存在订单。AWS 对安全重试的讨论也指出未收到响应会使调用者无法确认操作是否已经完成直接重复创建可能产生额外效果。AWSMaking retries safe with idempotent APIs因此需要把“请求有没有返回”和“业务写入有没有完成”分别检查。如果实验只在发送请求之前制造失败就没有覆盖本例中最关键的条件第一次业务写入已经提交。复用标识之后后端还需要完成哪些工作幂等性Idempotency在这个例子中的含义是同一次业务操作被重复请求时额外请求不会再创建第二笔订单。去重标识为后端提供了识别同一次操作的依据。这里的K1指后端实际用来识别重复业务操作的标识。日志中的跟踪编号可能只用于区分每次网络调用需要阅读实现才能确定它与业务去重的关系。假设后端按“调用者身份与去重标识”保存处理记录。第一次请求完成后记录能够关联到O1重试仍然携带K1后端找到原记录再按接口约定返回已有订单结果。下图展示这一假设过程注意数据库提交完成与客户端等待超时发生的位置。图中重试查询到了O1说明同一次业务操作需要在两次网络请求之间保持可识别的身份后端也需要保留有效的处理记录。这个推演依赖多个条件两次请求表达同一个业务意图标识保持一致后端去重记录仍然有效重复处理不会再次执行订单创建并且记录与订单写入之间具备一致性保证。对于相同标识携带不同参数的情况也需要明确接口如何处理。Stripe 的官方文档提供了一个具体参照相同幂等键的后续请求会得到已保存的结果同时检查请求参数是否一致键被清理后再次使用会被视为新的请求。这说明检查去重时还需要关注参数约定和记录有效期。StripeIdempotent requests更换标识之后需要继续检查业务约束现在改变一个条件重试代码生成了新的去重标识K2。如果后端仅依靠这个标识识别重复操作那么K2无法直接命中K1的处理记录。在没有其他限制的前提下第二次请求可能再次创建订单。不过系统也可能具有独立的业务唯一约束。例如同一次下单意图还携带固定业务编号B1订单表要求同一用户的B1只能出现一次。即使去重标识发生变化第二次写入仍可能因业务编号重复而受到限制。因此需要确认每个编号的生成时机和用途。每次写入都重新生成的订单主键可以区分不同数据行表达同一次下单意图的固定业务编号才能让对应的唯一约束识别这两次写入之间的业务关系。PostgreSQL 文档说明唯一约束可以限制单列或多列组合的重复值。用于此类业务约束时还要检查字段是否允许空值默认情况下唯一约束会把空值视为彼此不同。PostgreSQLUnique Constraints检查结果时也要区分“第二次写入受到限制”和“调用者拿到了正确结果”。数据库报告唯一约束冲突之后接口仍需要按照已有约定提供明确结果才能完成整个业务要求。并发和重启会改变哪些前提继续改变条件两个携带K1的请求同时到达。如果后端执行的是“先查询是否存在再创建订单”两个执行过程可能都在查询时看见记录不存在随后分别进入创建流程。这时需要查清系统有没有原子性的占用、对应的唯一约束或其他并发控制以及重复请求处理中怎样返回结果。还需要检查去重记录与业务写入之间的一致性。订单已经提交、去重记录尚未保存时发生进程崩溃重试可能无法识别先前的效果去重记录已经保存、业务写入没有完成时发生错误也可能留下无法正确说明的状态。AWS 文档将记录请求标识与相关修改作为需要原子性保证的过程讨论。AWSMaking retries safe with idempotent APIs如果去重状态只保存在进程内存中服务重启后这些状态通常不会保留不同服务实例也未必共享它们。此时必须检查持久化状态和数据库约束是否仍然能够识别原来的业务操作。把几个条件放在一起可以得到一份具体的验证表改变的条件应当观察的内容需要解释的机制第一次提交后客户端响应超时提交记录、重试参数、最终订单数量超时与业务完成的关系重试保留K1去重记录、关联订单、接口返回结果相同操作怎样得到识别重试改用K2业务编号保留B1两种标识、唯一约束、写入结果哪项机制阻止重复写入两个K1请求并发到达实际执行时序、写入次数、返回结果并发控制怎样成立提交后重启再携带K1请求重启前后状态、已有订单、重试结果去重保证依赖的保存位置在测试环境中执行第一项验证时可以使用真实服务和独立测试数据让请求经过实际写入过程再通过可控的网络延迟使客户端在提交后达到等待时限。需要用数据库记录和服务日志确认这个先后关系随后检查重试发送的标识、最终订单数量与接口结果。其余项目同样应当先确认条件确实触发再解释观察结果。这组问题的学习价值在于它把“重试是否安全”转化成了能够查找和验证的具体条件。下一次遇到类似代码时你可以主动检查业务意图、去重标识、写入约束和状态保存。五、把一次任务中的判断带到下一次开发学习记录可以围绕一个真实的认识变化组织。记录时保留当时的预测、检查到的证据和最终确认的条件篇幅由问题本身决定。下面是一份供填写的记录结构记录项目需要写清的内容当前问题哪个功能行为需要由自己判断原先预测在明确条件下预计会发生什么观察证据哪些请求、日志、数据或文档支持实际结果机制解释哪段代码或哪项约束决定了结果成立条件标识、参数、并发、保存位置和有效期有哪些要求下次检查再遇到相似问题时首先检查什么例如订单重试问题可以形成这样一个下次检查的问题“同一次下单意图在重试时如何保持可识别的身份后端依靠哪项约束阻止重复效果这项保证在并发和重启后是否仍然成立”记录完成后可以用另一处实际调用检验迁移能力。调用对象换成库存扣减时先说明重复执行可能产生的业务后果再找到它的请求身份和写入机制。相似之处能够帮助确定检查方向具体保证仍然需要从当前实现中获得证据。当多个任务都涉及超时、重复执行和事务边界就可以把这些案例放在一起学习网络结果为什么存在不确定性哪些写入可以安全重试去重状态怎样与业务状态保持一致。每个概念都有已经遇到的问题作为入口也有后续任务可以检验理解。涉及权限、写入和状态一致性的关键知识需要在交付之前查清。对尚未确定的保证应当结合文档、运行证据和代码审查完成检查。学习安排也需要包含这些检查所需的时间。下次修改功能之前尝试在阅读 AI 的分析之前写下自己的预测执行之后用代码、日志和数据说明结果。每完成一次这样的过程就留下一个具体的判断依据供后续开发继续使用。参考资料学习方法参考所提供的图文文章《AI 写完的代码如何变成你的经验》。AWSMaking retries safe with idempotent APIs用于核查请求身份、重复执行和原子性要求。StripeIdempotent requests用于核查幂等键、参数一致性和记录有效期的具体接口约定。PostgreSQLUnique Constraints用于核查唯一约束及其空值行为。