夜雨聆风很多 AI Coding 翻车，都是从一句很顺手的话开始的：
帮我做完这个功能。
这句话听起来没问题。
你有一个需求，AI 会写代码，让它帮你做完，好像很自然。
但在真实项目里，这句话往往太大了。
因为“做完”两个字，里面藏了太多没有说清楚的判断。
这个功能的入口在哪里？应该复用哪个已有模式？哪些文件不能动？权限规则是什么？老数据要不要兼容？做到什么程度才算完成？
如果这些都没说，AI 就只能自己补。
它不是故意乱来。
它只是会把一个模糊愿望，自动翻译成一套它认为完整的方案。
你说“帮我做一个权限系统”，它可能会自己设计角色、菜单、资源、接口和数据库表。
你说“帮我重构这个后台”，它可能会顺手改目录、抽组件、换状态管理、调整请求封装。
你说“帮我优化这个页面”，它可能会把样式、交互、请求、缓存一起动了。
最后你得到一堆代码。
看起来很完整。
但你很难判断：哪些是这次真正需要的，哪些只是 AI 为了把事情“做完整”自己补出来的。
这就是“帮我做完”最危险的地方。
它不是让 AI 执行任务。
它是在让 AI 替你做一堆工程判断。
大任务不是不能交给 AI
我不是说复杂任务不能用 AI。
恰恰相反，复杂任务更适合用 AI。
AI 很适合读代码、找入口、梳理调用链、对比现有实现、生成候选方案、补测试、整理验证步骤。
问题在于，你不能一上来就把整件事扔给它。
大任务最大的问题，不是 AI 写不出来。
而是反馈太晚。
等它写完几百行代码，你才发现：
入口理解错了。权限模型不对。接口风格和项目不一致。老数据兼容漏了。它顺手做了一堆无关重构。
这时候你要么硬着头皮改它生成的代码，要么让它重来。
两种都很浪费。
所以我现在更喜欢把 AI 任务拆成几个阶段：
先理解。再方案。再实现。最后验证。
每个阶段都可以停下来检查一次。
如果 AI 一开始就找错了文件，在“理解阶段”就能发现。
如果方案太大，在“方案阶段”就能压回去。
如果实现有风险，在“验证阶段”就会露出来。
不要等它写完一大堆代码以后，才开始 Review 它到底理解对没有。
那时候已经太晚了。
拆任务，不是把一句话拆成十句话
很多人误解了任务拆解。
任务拆解不是把“做一个功能”改成：
先做按钮。再做接口。再做页面。最后调样式。
这只是把工作量切小了，但不一定把风险切小。
真正有效的拆解，是按风险顺序拆。
哪里最不确定，就先让 AI 去确认哪里。
哪里最容易影响系统，就先让 AI 说明影响范围。
哪里最容易被误解，就先把规则写清楚。
比如你要做一个导出功能，表面上看可以拆成按钮、接口、文件生成、权限控制。
但更重要的拆法可能是：
先确认项目里有没有已有导出模式。再确认哪些角色能导出。再确认导出的数据范围。再确认文件生成走同步还是异步。最后才是具体实现。
这种拆法不是按代码层次拆，而是按决策顺序拆。
AI 擅长执行，但它不应该替你做所有决策。
你要先把关键决策点暴露出来，再决定哪些交给 AI 执行。
把“帮我做完”改成四步
如果我要让 AI 做一个导出功能，我现在不会直接说：
帮我加一个导出功能。
我会写成这样：
先不要写代码。我们要做一个导出功能。第一步：请先阅读项目里已有的导出功能，说明它们的入口、权限、接口和文件生成方式。第二步：基于现有模式，给出最小实现方案。不要新增架构，不要改变已有接口风格，不要做无关重构。第三步：列出需要我确认的业务规则。如果规则不明确，先停下来，不要自己脑补。第四步：等我确认后再实现。实现后给出验证步骤，包括有权限、无权限、空数据、大数据量和失败提示。这段话不复杂，但它解决了几个关键问题。
它让 AI 先找现有模式，而不是自己发明一套。
它限制了方案范围，不让任务自然膨胀。
它把业务判断留给人，而不是让 AI 靠常识猜。
它还提前把验收场景放进任务里。
这就是任务拆解的价值。
不是为了显得专业，而是为了让 AI 的每一步都有边界。
不要用“完整一点”诱导 AI 过度设计
我以前也会对 AI 说：
方案完整一点。
后来发现这句话很危险。
因为 AI 对“完整”的理解，往往是把所有可能性都补上。
它会考虑配置、扩展、多语言、插件化、异常处理、通用抽象。
看起来很周到。
但很多时候，你只是要修一个具体问题。
工程里有一种浪费，叫提前完整。
尤其是在已有项目里，过度完整会带来额外复杂度。
代码多了，测试面变大了，Review 成本上去了，后面维护的人还要理解这一套新抽象到底为什么存在。
所以我现在更常用的词是：
最小可验证。
不是最小可用，也不是完整方案，而是最小可验证。
它意味着这次改动要足够小，小到你能看清楚；也要足够完整，完整到能证明它解决了当前问题。
AI 任务应该像工单，而不是愿望
一个好的 AI Coding 任务，应该更像一张工程工单。
它至少要写清楚五件事：
背景：为什么要做？范围：这次做到哪里为止？约束：哪些不能碰？交付物：最后要产出什么？验收：怎么证明做对了？背景告诉 AI 为什么做。
范围告诉 AI 做到哪里为止。
约束告诉 AI 哪些不能碰。
交付物告诉 AI 最后要产出什么。
验收方式告诉 AI 如何证明做对了。
如果这些都没有，AI 就只能靠猜。
而一个靠猜完成的功能，即使表面能跑，也很难让人放心。
最后
AI Coding 的提效，不是来自“把更大的任务交给 AI”。
恰恰相反，它来自把任务拆得更清楚。
拆到 AI 能稳定执行，拆到人能快速判断，拆到每一步都有反馈。
下次你想说“帮我做完这个功能”的时候，可以先停一下。
把它改成：
先帮我读懂这个功能。再帮我找现有模式。再给我最小方案。等我确认后，再开始实现。
这不是降低 AI 的能力。
这是把 AI 放回工程流程里。
当你不再把需求当愿望，而是把它拆成一组可验证的小任务，AI Coding 才会从偶尔惊艳，变成稳定可用。
