前言配套资源AI 辅助开发检查清单资源包适合把本文的流程直接落成开发前检查表和复盘模板。上一篇文章里我把 AI 工作流拆成了几类任务模式开发维护、探索学习、反馈确认。这个分类解决的是一个前置问题在使用 AI 之前先判断自己到底在做哪类任务。但只有任务分类还不够。尤其在开发维护类任务里AI 的速度很容易让人产生一种错觉只要模型足够强任务就可以一直往前推只要代码能跑起来这次迭代就算完成只要 AI 能继续改那就让它多试几轮。实际使用下来我越来越觉得AI 辅助开发真正难的地方已经不只是“让 AI 会写代码”而是“让整个协作过程不失控”。这篇文章想讨论的就是这个问题快速 AI 迭代仍然需要操作纪律。一次失配经验有一次我使用 AI 配合现有 skill 做项目重构。开始时预期很简单既然 AI 已经能读代码、改代码、解释代码那么让它处理一轮重构应该可以省掉不少时间。但实际推进中编码质量出现了明显下滑。这次问题不是单纯的“模型不行”而是几个因素叠在了一起当前使用的 skill 更适合小范围代码调整不适合大范围重构。重构任务本身边界不够清楚AI 很容易扩大改动面。一次性提交内容过多后续 review 和回滚成本明显上升。一些系统约定只存在于人的内部认知里AI 并不知道这些隐性前提。这次经历给我的提醒是AI 辅助开发的质量不只取决于模型能力还取决于任务切分、工具适配、上下文补充和提交策略。如果这些东西没有被控制住AI 的速度会把错误姿势放大。为什么速度会放大问题传统开发里很多问题会因为“慢”而自然暴露。你要自己读代码、自己改逻辑、自己整理提交所以在动手过程中会被迫停下来想这个模块能不能改这个接口有没有外部依赖这个数据结构是不是有历史包袱AI 介入以后很多步骤会被压缩。你可能只是描述一个目标AI 就能很快给出一组修改。再描述一个问题它又能继续补丁。这个过程很顺滑但也带来一个风险人可能从设计者退化成批准者。如果大部分时间都在做三件事同意 AI 执行动作看结果是否报错继续让 AI 修改那么开发节奏虽然快了但人的关键判断可能并没有同步发生。这也是我现在更警惕的点AI 的高速度会降低“停下来判断”的自然阻力所以我们需要主动把判断点加回来。AI 辅助开发里的四个常见失控点1. skill 和任务规模不匹配很多 AI 工具或 skill 都有自己的适用边界。有的适合小改动比如修一个函数、补一个测试、调整一个局部逻辑。有的适合解释代码、梳理文档、生成 checklist。有的可以参与重构但需要非常明确的边界和分阶段计划。问题在于使用时很容易默认沿用“顺手工具”。小改动时好用的 skill不一定适合大范围重构。它可能会过度关注局部代码风格忽略系统级约束也可能生成看起来很干净的代码但没有处理历史兼容和调用链影响。所以在让 AI 开始之前应该先问一句当前工具真的适合这次任务规模吗如果答案不确定就不要直接让 AI 大范围改代码先让它做阅读、评估和计划。2. 任务边界没有显式写出来AI 不怕干活多但工程上最怕无边界改动。如果你只说“帮我重构这个模块”AI 可能会顺手调整命名、抽函数、改数据结构、移动文件、补逻辑甚至处理一些它认为相关的问题。这些修改单独看可能都合理但合在一起就很难 review。更稳的做法是把任务边界显式写出来这次只改哪些文件或模块。哪些公共接口不能动。哪些行为必须保持兼容。哪些问题暂时不处理。这次完成后用什么方式验收。AI 可以帮你实现但任务边界应该先由人定清楚。3. 提交粒度过大AI 很容易一次性做很多事。这在 demo 或原型阶段很舒服但在真实项目里风险很高。一次提交里如果同时包含数据库结构、业务逻辑、接口行为、前端展示和测试调整后续出现问题时很难判断到底是哪一层引入的。尤其涉及数据库设计、历史数据迁移、权限关系、缓存更新这类任务时不建议把所有东西混在一个提交里。我现在更倾向于两阶段处理第一阶段结构性改动。比如表结构、字段、索引、迁移脚本、基础模型定义。这一阶段重点是让结构清楚、可回滚、可 review。第二阶段行为性改动。比如业务逻辑、接口流程、页面行为、权限判断、缓存更新。这一阶段再围绕具体业务结果做验证。这样拆开以后AI 仍然可以提速但人的 review 压力会小很多。4. 隐性上下文没有补齐很多系统真正难的地方不在代码表面而在历史约定。某个字段为什么不能改某个接口为什么保留旧行为某个数据状态为什么有特殊分支这些东西不一定写在代码里。人知道是因为经历过AI 不知道是因为上下文没有给。如果这些隐性信息没有显式化AI 很可能给出“技术上正确、业务上不安全”的修改。所以开发维护类任务里人要主动补三类上下文历史原因为什么当前逻辑长这样。风险边界哪些地方不能动哪些地方改了会影响线上。验收方式怎样证明这次修改没有破坏旧行为。这部分不能完全交给 AI 猜。一套更稳的 AI 辅助开发流程我现在会把 AI 辅助开发拆成 6 个阶段。阶段人要做什么AI 可以做什么关键产物任务定义说明目标、范围、验收标准复述任务、识别缺失信息任务 brief代码阅读指定模块和关注点梳理调用链、总结现有逻辑代码理解笔记风险评估确认不能改的边界列出影响面和潜在风险风险清单分阶段计划决定提交粒度拆解步骤和文件范围实施计划局部实现审核方案后允许修改生成代码、补测试、解释 diff小粒度变更验证复盘执行测试和人工验收汇总结果、生成复盘模板测试记录和复盘这个流程看起来比“直接让 AI 改”慢一点但它能换来两个好处第一人在关键节点仍然保持判断。第二每次任务结束后都会留下可复用的经验资产。一个开发前检查清单在真正让 AI 修改代码之前我建议至少过一遍下面这张清单。1. 这次任务属于小改、重构、修 bug还是新增功能 2. 当前使用的模型或 skill 是否适合这个任务规模 3. 是否已经明确本次只改哪些模块 4. 是否列出了不能改的接口、字段、行为或兼容逻辑 5. 是否需要先让 AI 读代码并输出理解而不是直接改 6. 是否涉及数据库结构、数据迁移、权限、缓存或外部接口 7. 如果涉及结构性改动是否需要拆成两阶段提交 8. 是否已经定义验收标准和测试方式 9. 是否能在一次 review 中看完这次 diff 10. 任务结束后是否需要沉淀成模板或 SOP这张清单的作用不是制造流程负担而是把原本藏在脑子里的判断显式化。AI 辅助开发越快这种显式化越重要。数据库相关改动要格外谨慎在所有开发任务里我认为数据库相关改动最需要操作纪律。原因很简单代码改错了可以回滚数据库结构和历史数据改坏了恢复成本往往更高。所以如果 AI 参与数据库相关任务我建议默认采用两阶段策略。第一阶段只处理结构表结构字段定义索引迁移脚本初始化逻辑第二阶段再处理行为业务读写逻辑接口返回权限判断缓存更新历史数据兼容不要让 AI 在同一次修改里既改表结构又改业务流程还顺手调整接口。这不是不信任 AI而是把工程风险拆小。人应该保留哪些判断AI 可以帮忙读代码、写代码、补测试、解释 diff但有些判断不应该轻易交出去。至少包括这些需求是否真的合理。本次任务边界是否应该扩大。是否接受某个设计方案。哪些历史兼容不能破坏。这次 diff 是否过大。是否需要拆提交。测试结果是否足以证明安全。是否可以上线或合并。这些判断不一定都很复杂但它们决定了 AI 产出的代码能不能进入真实工程环境。如果人完全不做这些判断只负责同意和试跑AI 辅助开发就很容易从“提效”变成“加速失控”。这篇文章配套的资源包为了让这件事不只停留在观点上我把这篇文章里的流程整理成一个小资源包里面包括AI 辅助开发任务 brief 模板AI 重构前风险评估表AI 开发前检查清单数据库改动两阶段检查清单AI 辅助开发复盘模板资源地址AI 辅助开发检查清单资源包这些模板可以在每次让 AI 参与开发前拿出来过一遍。它不解决所有工程问题但能帮你先把任务边界、风险点和验证方式写清楚。总结AI 可以把开发迭代推进得很快但速度本身不是工程质量。当模型、skill、任务规模和提交粒度不匹配时快速迭代会把复杂度一起放大。真正有价值的 AI 辅助开发不是一路同意也不是无限试错而是在关键节点保留人的判断。我的当前结论是AI 写代码越快人越需要操作纪律。先定义任务再评估风险再拆分步骤再局部实现最后验证和复盘。这样 AI 的速度才会变成稳定收益而不是更快地制造混乱。