在和AI一起编程的日子里，我踩过不少坑：让AI写代码，要么跑偏需求，要么改一个bug又造出三个，返工起来比自己写还累，AI的健忘症、钻头不顾腚的毛病折磨的我怀疑人生。后来我慢慢总结出一套"偷懒思路"------真正的"懒人"从不是啥都不做，而是用最省劲儿的方法做对事，避免无用功。
比如，直接甩给AI一句"帮我写个订单系统"，然后花一下午改bug，这不是懒，是瞎忙；但如果先让AI出方案、定好边界、分步实现，一次成型不用返工，这才是聪明的懒人智慧------先想清楚，再做对的事，省下来的时间才是自己的。
三大懒人法则（核心纲领，记牢少走弯路）
法则1：先想清楚，再让AI动手（想清楚一步，少做两遍功）
法则2：改哪里说哪里，圈外不动（改得越少，错得越少）
法则3：先跑通主干，再完善枝叶（先能用，再好用，不做无用优化）
20条大懒人工作模式
一、需求与设计阶段（懒在动工前，避免返工）
模式1：思路先行
核心原则：先出方案，再写代码
懒人逻辑：方案错了，写再多代码都是白搭。花5分钟和AI确认方案，能省2小时返工时间，这笔账很划算。
❌ 反面案例（真实踩坑）：
我："帮我写一个用户积分系统。"
AI：直接生成500行代码，包含注册、登录、积分增减、排行榜，甚至加了社区签到功能。
我："我要的是电商积分（下单返积分、积分抵现金），不是社区积分啊！"
结果：500行代码全白费，只能从头再来，白白浪费1小时。
✅ 正面案例（懒人正确操作）：
我："请先输出电商用户积分系统的设计方案，不要写代码，重点说清楚这5点：
-
积分怎么来？（下单满100返10积分、邀请好友返20积分）
-
积分怎么用？（下单直接抵扣，100积分抵10元，不找零）
-
积分会过期吗？（自到账之日起1年过期）
-
要不要记录积分变动？（比如"2026-04-19 下单返10积分"）
-
预估有多少用户用？（大概1000个活跃用户）"
AI：输出清晰的方案，甚至补充了"积分过期提醒"的小建议。
我：确认方案和我要的一致，再让AI生成代码。
结果：一次生成就可用，只微调了2处细节，省了大量返工时间。
模式2：逆向评审
核心原则：让AI先挑刺，再动手写代码
懒人逻辑：AI懂的编程漏洞比我们多，让它先找出方案里的坑，比自己踩坑后再修，省事多了。
❌ 反面案例（真实踩坑）：
我："帮我实现一个转账功能，从A账户转钱到B账户，简单点就行。"
AI：生成代码：A.balance -= amount; B.balance += amount;
我直接上线，结果有一次用户转账时，系统突然崩溃------A账户的钱扣了，但B账户没收到，用户投诉，只能紧急回滚，还得手动对账，忙到半夜。
✅ 正面案例（懒人正确操作）：
我："这是我做用户转账的实现思路，你作为资深后端工程师，帮我找出潜在漏洞，只说问题，不写代码：
-
先检查A账户余额够不够转账金额；
-
A账户余额减去转账金额；
-
B账户余额加上转账金额；
-
返回转账成功。"
AI：很快指出4个坑：
-
没有事务保护，中间系统崩溃，会出现A扣钱、B没收到的情况（就是我之前踩的坑）；
-
没有防并发，比如A同时转两笔钱，可能出现余额负数；
-
没有记录转账流水，后续对账、用户查账都没法弄；
-
没处理A和B是同一个账户的情况，会白白扣手续费。
我：按这些建议完善方案，再让AI写代码。
结果：上线后0故障，不用再半夜处理对账问题。
模式3：方案对比
核心原则：让AI给多个方案，你只负责选，把纠结的事交给AI
懒人逻辑：AI擅长枚举各种实现方式，而我们擅长根据自己的场景做选择，分工明确，不用自己查资料、纠结半天。
❌ 反面案例（真实踩坑）：
我："用Redis实现一个API限流功能，防止别人刷接口。"
AI：直接用了令牌桶算法，写了一堆复杂代码。
我："我只是个小项目，不需要这么复杂，我想要简单好维护的滑动窗口算法啊！"
结果：只能让AI重写，浪费半小时。
✅ 正面案例（懒人正确操作）：
我："请给我3种用Redis实现API限流的方式，重点说清楚优缺点和适用场景，我是小项目，优先选简单好维护的。"
AI：清晰输出3种方案，还标了重点：
-
固定窗口：实现最简单（几行代码），但有边界突刺（比如每分钟限流100次，59秒刷100次，1秒又刷100次），适合小项目、对限流精度要求不高的场景；
-
滑动窗口：限流精准，没有边界问题，但内存占用比固定窗口大，适合对精度有要求的中型项目；
-
令牌桶：允许突发请求（比如突然来了10个请求，只要有令牌就能处理），但实现复杂，适合高并发场景。
我：直接选固定窗口，让AI动手实现。
结果：一次选对，代码简单，维护起来也省心。
模式4：任务拆解
核心原则：把大需求拆成小任务，一次只让AI做一件事
懒人逻辑：大需求太复杂，AI容易混乱，写出来的代码bug多、逻辑乱；拆成小任务，AI能专注做好，你也不用费脑子梳理复杂逻辑，一举两得。
❌ 反面案例（真实踩坑）：
我："帮我写一个完整的电商订单系统，包含下单、支付、库存扣减、退款、物流跟踪，越快越好。"
AI：花了10分钟，生成了2000行代码，把所有功能混在一个文件里，下单逻辑和物流逻辑缠在一起，还有很多语法错误。
我：看着一堆混乱的代码，根本没法改，只能放弃，重新拆解任务。
✅ 正面案例（懒人正确操作）：
我："请把电商订单系统拆成5个子任务，按顺序逐个实现，每完成一个，等我确认后再做下一个：
-
先定义订单的数据结构（比如订单号、用户ID、商品列表、金额、订单状态）；
-
实现创建订单的接口（用户提交订单，生成订单号）；
-
实现库存扣减逻辑（下单时，对应商品库存减1）；
-
实现支付回调处理（用户支付成功后，把订单状态改成"已支付"）；
-
实现订单状态机（待支付→已支付→已发货→已完成→已取消）。"
结果：每一步都清晰，AI做出来的代码逻辑工整，没有混乱，逐步集成后，直接就能用。
二、编码实施阶段（懒在精准，避免擦屁股）
模式5：圈定边界
核心原则：明确告诉AI"能改什么、不能改什么"，改内不改外
懒人逻辑：AI有个坏毛病，改代码时爱"顺手牵羊"，比如你让它改一个小函数，它可能顺便重构其他代码、重命名变量，结果把好的代码改崩，你还得花时间排查、擦屁股。提前圈好边界，就能避免这种麻烦。
❌ 反面案例（真实踩坑）：
我："帮我修复登录失败时没有错误提示的问题，比如用户输错密码，页面只显示'登录失败'，要改成'密码错误，请重新输入'。"
AI：改了login函数的错误提示，还顺手重构了session管理代码、重命名了3个变量，甚至调整了整个文件的代码缩进。
我：测试时发现，用户登录后session失效，根本无法正常使用。查了半天，才知道是AI"顺手"改崩了session管理代码，又花了2小时恢复。
✅ 正面案例（懒人正确操作）：
我："明确以下规则，只改指定内容，其他一律不动：
�� 冻结区域（绝对不能改）：
-
SessionManager 类（负责用户登录会话管理）；
-
数据库连接池相关代码；
-
所有配置文件（比如数据库地址、端口）。
�� 可修改区域：
- user_service.py 文件中的 login() 函数。
修改任务：修复登录失败的错误提示------输错密码显示"密码错误，请重新输入"，账号不存在显示"账号未注册"，其他错误显示"登录异常，请稍后再试"。
约束：不得修改冻结区域，若必须改动，先告诉我。"
结果：AI只改了login函数里的错误提示语句，其他代码完好无损，测试一次通过，不用擦屁股。
模式6：最小补丁
核心原则：让AI只输出修改的代码片段，不要输出整个文件
懒人逻辑：如果AI输出整个文件，你得一行一行比对，才能找到它改了哪里，浪费时间；只输出修改片段，一眼就能看清，省下来的时间能多摸鱼。
❌ 反面案例（真实踩坑）：
我："帮我给order_service.py里的calculate_total函数，加一个折扣参数，比如用户有折扣券，就能按折扣计算总价。"
AI：直接输出了整个order_service.py文件（500多行代码）。
我："你到底改了哪里？我得一行一行比对，生怕你改了其他地方。"
结果：花了10分钟比对，才找到修改的3行代码，纯属浪费时间。
✅ 正面案例（懒人正确操作）：
我："只修改order_service.py中的calculate_total()函数，其他部分保持不变，只输出修改前后的片段，不要输出整个文件。
修改前：
def calculate_total(price, quantity):
return price * quantity
修改要求：加一个折扣参数discount，默认值是1.0（无折扣），总价=价格×数量×折扣。"
AI：只输出修改后的片段：
def calculate_total(price, quantity, discount=1.0):
return price * quantity * discount
结果：一眼就看清修改内容，确认无误后直接复制粘贴，不用比对，省时又放心。
模式7：伪代码翻译
核心原则：你用中文讲清楚逻辑（伪代码），让AI翻译成对应语言的代码
懒人逻辑：很多时候，我们懂业务逻辑，但记不住某些编程语言的语法（比如Rust、Go），与其花时间查语法，不如让AI当"翻译"，你只负责说逻辑，省心又高效。
❌ 反面案例（真实踩坑）：
我："用Rust写一个读取配置文件的函数，读取config.json里的内容。"
AI：生成了一堆包含所有权、生命周期的复杂代码，全是我看不懂的语法。
我："这代码对不对？有没有bug？我完全不知道，不敢用。"
结果：只能放弃，自己查Rust语法，花了半小时才写出来。
✅ 正面案例（懒人正确操作）：
我："我用中文描述逻辑，你帮我翻译成Rust代码，变量名要易懂，关键步骤加注释，不用写太复杂：
-
尝试打开当前目录下的config.json文件；
-
如果文件不存在，就返回默认配置（比如数据库地址是localhost，端口是3306）；
-
如果文件存在，就读取文件里的JSON内容，解析成配置对象；
-
如果JSON格式错误（比如少个逗号），就返回错误提示，不要崩溃。"
AI：生成的代码带详细注释，逻辑和我描述的完全一致，还处理了异常情况。
结果：我虽然不懂Rust，但能看懂注释和逻辑，确认没问题后直接用，不用查语法。
模式8：红绿蓝
核心原则：先写测试用例（红），再实现代码（绿），最后优化代码（蓝）
懒人逻辑：与其写完代码再花时间找bug、修bug，不如先写好测试用例，让AI实现的代码"必须通过测试"，bug自动现形，省得反复修改。
❌ 反面案例（真实踩坑）：
我："帮我写一个计算订单折扣的函数，规则是：满100减10，满200减30，不满100无折扣。"
AI：生成函数后，我直接用了，结果测试时发现：满200的时候，只减了10，没减30；不满100的时候，居然也减了10。
我：反复让AI修改，改了3轮才改对，修bug的时间比写代码还长。
✅ 正面案例（懒人正确操作）：
我："按'红绿蓝'步骤来，一步一步做，每步完成等我确认：
第一步（红）：先写4个测试用例，覆盖所有场景，不用写实现代码：
-
订单总价99元 → 折扣后99元（无折扣）；
-
订单总价100元 → 折扣后90元（减10）；
-
订单总价199元 → 折扣后189元（减10）；
-
订单总价200元 → 折扣后170元（减30）。
第二步（绿）：实现能通过这4个测试用例的最小代码，不用优化，能跑通就行。
第三步（蓝）：保持测试用例全部通过，再优化代码结构（比如简化判断逻辑）。"
结果：AI第二步写的代码就通过了所有测试，第三步优化也很顺利，一次到位，不用修bug。
模式9：单一职责
核心原则：一次只给AI一个任务，不混在一起说
懒人逻辑：一次让AI做几件事（比如"修bug+优化性能+加日志"），AI容易混乱，哪件事都做不好，你还得反复沟通；一次只做一件事，AI能专注做好，你也不用费脑子跟进多个任务。
❌ 反面案例（真实踩坑）：
我："帮我优化一下订单模块的性能，顺便修复'订单金额计算错误'的bug，再加个请求日志，对了，把代码格式也整理一下。"
AI：改了一堆代码，性能没优化多少，bug还在，日志加得乱七八糟，代码格式也没整理好。
我："你到底改了啥？哪件事都没做好！"
结果：又花了1小时，逐个核对、修改，比自己做还累。
✅ 正面案例（懒人正确操作）：
我："本次任务：只修复订单金额计算错误的bug（具体问题：满减后金额为负数），其他什么都不用做。"
（AI完成后，我确认bug修复）
我："本次任务：只给订单模块的create_order接口加请求日志，记录请求参数和请求时间，不修改其他逻辑。"
（AI完成后，我确认日志正常）
结果：每个任务都完成得很完美，不用反复沟通、返工。
三、迭代与优化阶段（懒在安全，避免出乱子）
模式10：主线优先
核心原则：先实现最基础的主线功能，跑通后再优化细节
懒人逻辑：完美主义最费时间------一开始就想实现所有细节（比如文件上传要支持断点续传、进度条、格式校验），AI写起来复杂，还容易跑不通，你会越做越焦虑。先实现主线功能，有个能用的版本，再慢慢加细节，心里踏实，也更省劲儿。
❌ 反面案例（真实踩坑）：
我："帮我写一个文件上传功能，要支持断点续传（中途断网能继续传）、秒传（相同文件不用重复传）、进度条（显示上传百分比）、多种格式校验（只能传jpg、png、pdf），还要兼容手机和电脑。"
AI：写了3天，代码越写越复杂，最后还是跑不通，连最基础的文件上传都做不到。
我："搞了这么久，连个能用的版本都没有，白忙活了。"
结果：放弃原有代码，重新简化需求。
✅ 正面案例（懒人正确操作）：
我："分三个阶段实现文件上传功能，每阶段只做一件事，确认可用后再进行下一个阶段：
第一阶段：只实现最基础的文件上传（能把本地文件传到服务器，不管格式、不管进度），忽略断点续传、进度条、格式校验，只要能传成功就行。
（AI完成后，我测试能正常上传文件，确认通过）
第二阶段：加上文件类型校验，只允许上传jpg、png、pdf三种格式，其他格式提示"不支持的文件类型"。
（确认通过后）
第三阶段：加上上传进度条，显示上传百分比（比如"上传中：30%"）。"
结果：每个阶段都有可用的版本，心里踏实，而且AI写起来简单，不容易出错，最后逐步完善，完美实现所有需求。
模式11：渐进对话
核心原则：从简单到复杂，逐步给AI加需求，不一次性丢给它复杂任务
懒人逻辑：一口吃不成胖子，一次也写不出完美的复杂代码。逐步加需求，AI能慢慢适应，问题也容易定位；一次性丢复杂需求，AI容易混乱，你也没法排查问题。
❌ 反面案例（真实踩坑）：
我："帮我写一个用户列表API，要支持缓存（Redis）、分页（每页10条）、排序（按注册时间倒序）、过滤（按用户名模糊查询）、软删除（删除后不显示，但不删除数据库数据）。"
AI：生成了一堆复杂代码，测试时发现，分页和过滤冲突（过滤后分页数量不对），缓存也没生效，排查了半天也找不到问题。
结果：只能拆成小步骤，重新让AI实现。
✅ 正面案例（懒人正确操作）：
我："按步骤实现用户列表API，每步完成后我确认，再进行下一步：
Step 1：先实现最简单的用户列表查询，只查询所有未删除的用户，不用分页、排序、过滤、缓存。
Step 2：在Step 1的基础上，加上分页功能，每页显示10条，支持页码参数（比如page=1，显示前10条）。
Step 3：加上按用户名模糊过滤功能（比如输入"张"，显示所有用户名包含"张"的用户），不影响分页。
Step 4：加上按注册时间倒序排序，最新注册的用户排在前面。
Step 5：加上Redis缓存，查询结果缓存10分钟，减少数据库压力。"
结果：每步都很简单，AI实现起来没压力，而且如果某一步出问题，能快速定位（比如分页有问题，只需要看Step 2的代码），不用排查整个复杂代码。
模式12：外科手术
核心原则：修改核心代码前，先让AI评估影响范围，再动手修改
懒人逻辑：核心代码（比如用户ID、订单状态）关联很多模块，一旦改崩，整个系统都要修，通宵加班都有可能。先让AI评估影响范围，制定迁移计划，平稳过渡，不用事后擦屁股。
❌ 反面案例（真实踩坑）：
我："帮我把User类的id字段从int类型改成string类型，比如原来的123，改成'user_123'，看着更规范。"
AI：直接改了User类的id字段，没管其他模块。
我：上线后发现，订单模块（Order.user_id）、支付模块（Payment.user_id）、日志模块（Log.user_id）全崩了------这些模块都引用了User.id，原来的int类型和现在的string类型不兼容。
结果：通宵修改所有关联模块，累得半死，还影响了用户使用。
✅ 正面案例（懒人正确操作）：
我："第一步：帮我分析影响范围------如果把User类的id字段从int改成string（比如123改成'user_123'），会影响哪些模块和代码？列出来，越详细越好。"
AI：很快列出影响范围：
-
订单模块：Order表的user_id字段（关联User.id），需要同步改成string；
-
支付模块：Payment表的user_id字段，需要同步修改；
-
日志模块：Log表的user_id字段，需要同步修改；
-
所有查询User.id的SQL语句，需要调整（比如where id=123改成where id='user_123'）；
-
前端页面：显示用户ID的地方，需要调整格式。
我："第二步：制定迁移计划，如何平稳修改，不影响线上用户？"
AI：给出详细计划（先新增string类型的user_id_new字段，同步数据，再逐步替换关联模块，最后删除原来的int类型id字段）。
我："第三步：按迁移计划，逐步修改，每修改一个模块，我确认后再改下一个。"
结果：平稳过渡，没有影响线上用户，也不用通宵修bug。
四、调试与维护阶段（懒在高效，避免瞎忙活）
模式13：侦探破案
核心原则：遇到bug，先让AI诊断原因，再让它修复，不盲目修改
懒人逻辑：不知道bug原因就瞎改，改到天荒地老也未必能好；先让AI当"侦探"，找出病根，再精准修复，一针见效，省得瞎忙活。
❌ 反面案例（真实踩坑）：
我："订单支付成功后，状态还是'待支付'，帮我修一下。"
AI：没诊断原因，直接猜测是订单状态机逻辑有问题，重写了状态机代码。
我：测试后发现，还是不对。
AI：又猜测是数据库查询有问题，改了查询逻辑。
结果：改了5轮，还是没解决问题，浪费了1小时。
✅ 正面案例（懒人正确操作）：
我："第一步：诊断bug，不要给修复代码，一步步推理原因：
错误现象：用户支付成功后，订单状态仍为'待支付'，支付记录显示支付成功，数据库里的支付状态也是'已支付'。
请分析：为什么订单状态没更新？可能的原因有哪些？"
AI：逐步推理，最后得出结论：支付回调接口没有调用订单状态更新的函数，因为回调请求的签名验证失败（前端传的签名和后端计算的不一致），导致回调逻辑没执行。
我："第二步：确认原因，只修复签名验证的问题，不要修改其他逻辑。"
结果：一次修复，问题解决，不用瞎试，省时又高效。
模式14：代码考古
核心原则：修改遗留代码前，先让AI解释清楚逻辑，再动手修改
懒人逻辑：很多遗留代码（比如前人写的、或者自己很久前写的）很复杂，不理解就盲目修改，很容易改错核心逻辑，引入新bug。花5分钟让AI解释清楚，省1小时迷茫和返工。
❌ 反面案例（真实踩坑）：
我："这段遗留代码有个bug------订单状态不更新，帮我修一下。"（这段代码用了xxl-job定时任务，我看不懂）
AI：也没理解代码逻辑，猜测是定时任务没执行，改了3处代码。
我：测试后发现，bug没修复，反而把定时任务搞崩了------原来AI改的是核心执行逻辑。
结果：又花了1小时恢复代码，重新排查。
✅ 正面案例（懒人正确操作）：
我："这段遗留代码是处理订单状态更新的，用了xxl-job定时任务，我看不懂，帮我做3件事，不要改代码：
-
用通俗的话解释一下，这段代码的业务逻辑是什么（比如"每5分钟查询一次待支付订单，超过30分钟未支付就改成'已取消'"）；
-
指出哪些是核心逻辑（不能改的），哪些是历史遗留的冗余代码（可以改的）；
-
如果要修复"订单状态不更新"的bug，最可能的问题在哪里？"
AI：用通俗的话解释清楚逻辑，指出核心逻辑是"定时查询订单+状态判断"，冗余代码是"过时的日志打印"，并定位到bug原因------定时任务的执行时间配置错了（每5小时执行一次，不是每5分钟）。
我：确认原因后，只修改定时任务的执行时间配置。
结果：精准修改，没有误碰核心逻辑，bug一次性解决。
模式15：边界测试
核心原则：让AI主动找出自己写的代码的漏洞，提前修复
懒人逻辑：代码上线后，被用户发现bug，不仅要返工，还要被投诉，太麻烦。让AI自己找自己的茬，提前修复边界漏洞，上线后省心，不用应对投诉。
❌ 反面案例（真实踩坑）：
我："帮我写一个解析日期字符串的函数，支持YYYY-MM-DD格式，比如'2026-04-19'。"
AI：写了代码，测试了几个正常日期，没问题，我就上线了。
结果：上线后，有用户输入"2024-02-30"（2月没有30号），函数直接崩溃，用户投诉，我只能紧急修复。
✅ 正面案例（懒人正确操作）：
我："你刚才写的日期解析函数，帮我做两件事：
- 找出3种能让它崩溃的输入（边界情况），比如：
-
不存在的日期（如2024-02-30、2026-02-30）；
-
格式错误的字符串（如2026/04/19、20260419、abc123）；
-
空字符串或null（比如用户没输入日期）。
- 修复这些问题，确保遇到这些输入时，不崩溃，返回明确的错误提示。"
AI：找出了边界漏洞，还修复了代码，遇到无效日期时，返回"日期无效，请输入YYYY-MM-DD格式的有效日期"。
结果：代码上线后，没有出现崩溃问题，也没有用户投诉，省心又省力。
五、质量与工程化阶段（懒在持久，避免后续麻烦）
模式16：回归校验
核心原则：AI改完代码后，让它自己做回归校验，确认没有破坏原有功能
懒人逻辑：AI改代码时，很容易"顺手"破坏原有功能，你不一定能及时发现，等上线后出问题，又要返工。让AI改完后自己检查，提前发现问题，避免被坑。
❌ 反面案例（真实踩坑）：
我："帮我给订单模块加一个'备注'字段，用户下单时可以填写备注。"
AI：加了备注字段，修改了订单创建接口，但忘了更新API的序列化逻辑（把数据库里的备注字段返回给前端）。
我：上线后，测试发现，用户填写的备注，前端看不到，只能重新让AI修改序列化逻辑。
结果：来回沟通，浪费时间，还影响测试进度。
✅ 正面案例（懒人正确操作）：
我："修改完成后，请输出一份回归校验报告，回答3个问题：
-
本次修改（加订单备注字段）影响了哪些逻辑？（比如订单创建接口、订单查询接口）；
-
原有功能（比如订单支付、库存扣减、订单状态更新）是否可能被破坏？
-
是否引入了新风险？（比如备注字段过长导致数据库报错）。"
AI：输出校验报告，指出"忘记更新API序列化逻辑，前端无法获取备注字段"，还提醒"备注字段建议限制长度为500字，避免过长"。
我：让AI同步修改序列化逻辑和字段长度限制。
结果：一次性完整修改，没有遗漏，不用后续返工。
模式17：文档同步
核心原则：让AI写代码的同时，同步输出文档，不拖延
懒人逻辑：现在不写文档，三个月后，你自己都忘了代码的逻辑（比如"这个函数为什么这么写？""这个参数是什么意思？"），更别说其他人接手了。让AI顺手输出文档，省得以后花时间回忆、补文档。
❌ 反面案例（真实踩坑）：
我："帮我实现一个复杂的价格计算引擎，包含满减、折扣、优惠券、会员价，多种规则叠加。"
AI：实现了代码，逻辑很复杂，我当时看懂了，就没让AI写文档。
三个月后：用户反馈价格计算错误，我打开代码，发现自己完全看不懂了------不知道各种规则的优先级，不知道每个函数的作用，只能重新梳理逻辑，花了2小时才找到问题。
结果：代码成了"遗产"，维护成本极高。
✅ 正面案例（懒人正确操作）：
我："请实现价格计算引擎（满减、折扣、优惠券、会员价叠加），同时输出3份文档，和代码同步完成：
-
函数注释：每个函数的作用、参数含义、返回值、异常情况；
-
使用示例：比如"会员价100元+满100减10+9折优惠券，最终价格=（100-10）×0.9=81元"；
-
计算规则说明：各种优惠的优先级（会员价>满减>优惠券）、叠加规则。"
结果：代码和文档同步产出，三个月后再看，不用回忆，直接就能看懂，维护起来很省心，其他人接手也很方便。
模式18：约束内化
核心原则：把编程规则（比如"订单总价不能为负数"）写入代码断言，让代码自己守规矩
懒人逻辑：你反复提醒AI"记住，订单总价不能为负数"，但AI会忘（比如下次对话就忘了），还得反复提醒。把规则写入代码，AI忘了，代码也不会忘，不用你天天盯着。
❌ 反面案例（真实踩坑）：
我："帮我写订单计算逻辑，记住两个规则：1. 订单总价不能为负数；2. 折扣不能超过100%（也就是折扣值不能大于1.0）。"
AI："记住了。"然后生成了代码。
下次我让AI优化订单逻辑时，它忘了这两个规则，生成的代码允许订单总价为负数，折扣值为1.5（150%）。
结果：我测试时发现问题，只能让AI重新修改，反复提醒规则，很麻烦。
✅ 正面案例（懒人正确操作）：
我："帮我写订单计算逻辑，同时把以下两个规则写入代码断言，确保不会违反：
-
订单总价不能为负数：assert order.total >= 0, "订单总价不能为负数"；
-
折扣不能超过100%：assert order.discount <= 1, "折扣不能超过100%"。
如果违反规则，直接抛出错误，提醒开发者。"
结果：规则固化在代码里，不管AI下次有没有记住，代码都会自动校验，不会出现违反规则的情况，不用我反复提醒。
模式19：分层实现
核心原则：让AI按工程分层组织代码，不混在一起
懒人逻辑：不分层的代码就是一坨"垃圾"------路由、业务逻辑、SQL查询、配置混在一个文件里，改一行代码要翻半天，维护起来特别费劲儿。按层组织代码，想改哪层改哪层，省得拆垃圾。
❌ 反面案例（真实踩坑）：
我："帮我写一个订单API，能创建订单、查询订单。"
AI：把路由（接收前端请求）、业务逻辑（计算订单金额）、SQL查询（操作数据库）、配置（数据库地址）全写在一个文件里，共300多行代码，乱七八糟。
后来我要修改订单金额的计算逻辑，找了半小时才找到对应的代码，还不小心改到了SQL查询逻辑，引入了新bug。
结果：维护成本极高，每次修改都要小心翼翼。
✅ 正面案例（懒人正确操作）：
我："请按以下分层组织订单API的代码，每个分层放在对应的文件夹里，不要混在一起：
-
router/：存放API路由（接收前端请求，比如/create_order、/get_order）；
-
service/：存放业务逻辑（比如计算订单金额、判断库存是否充足）；
-
repository/：存放数据访问逻辑（比如SQL查询、数据库操作）；
-
model/：存放数据模型（比如订单、商品的数据结构）；
-
config/：存放配置文件（比如数据库地址、端口、日志配置）。"
结果：代码结构清晰，想修改业务逻辑就去service文件夹，想修改SQL就去repository文件夹，不用翻来翻去，维护起来特别省心。
模式20：版本隔离
核心原则：修改代码时，不覆盖原有版本，保留历史版本，方便回滚
懒人逻辑：改代码时，万一改崩了，又找不到原来的代码，只能重新写，后悔都来不及。保留历史版本，改错了能一键回滚，比后悔药管用，省得重新返工。
❌ 反面案例（真实踩坑）：
我："帮我优化一下支付模块的性能，现在支付响应太慢了。"
AI：改了很多代码，优化了数据库查询和缓存逻辑。
我：测试后发现，性能没提升多少，反而导致部分用户支付失败，而且原来的代码已经被覆盖了，找不回来了。
结果：只能重新写支付模块，浪费了2小时，特别后悔。
✅ 正面案例（懒人正确操作）：
我："按以下规则优化支付模块，保留历史版本：
-
当前版本：payment_v2.py（正在使用的稳定版本）；
-
优化后的版本：payment_v3.py（新文件，不覆盖v2）；
输出内容：
-
新文件：payment_v3.py（优化后的代码）；
-
变更日志：详细说明v2→v3改了哪些地方（比如"优化了支付回调的数据库查询，减少响应时间"）；
-
保留payment_v2.py不变，不要删除或修改。"
结果：测试发现v3有问题，直接放弃v3，继续使用v2，不用重新写代码，也不用后悔，无后顾之忧。
大懒人速查表（一眼看懂，直接照做）
|----|-------|-----------|
| # | 模式 | 懒人一句话 |
| 1 | 思路先行 | 想清楚就不用做两遍 |
| 2 | 逆向评审 | 让AI帮你踩坑 |
| 3 | 方案对比 | 把纠结交给AI |
| 4 | 任务拆解 | 一次只烦一件事 |
| 5 | 圈定边界 | 圈好就不用擦屁股 |
| 6 | 最小补丁 | 一眼看清改了啥 |
| 7 | 伪代码翻译 | 不用背语法 |
| 8 | 红绿蓝 | 让bug自己现形 |
| 9 | 单一职责 | 一次只说一件事 |
| 10 | 主线优先 | 先能用，再好用 |
| 11 | 渐进对话 | 慢慢来比较快 |
| 12 | 外科手术 | 别修一个崩十个 |
| 13 | 侦探破案 | 找到病根再下药 |
| 14 | 代码考古 | 先看懂再动手 |
| 15 | 边界测试 | 自己找茬省心 |
| 16 | 回归校验 | 改完自己检查 |
| 17 | 文档同步 | 现在不写以后更累 |
| 18 | 约束内化 | 让代码自己守规矩 |
| 19 | 分层实现 | 想改哪层改哪层 |
| 20 | 版本隔离 | 后悔有药 |