1. 任务拆解不是AI的默认能力，而是你必须亲手校准的决策点
大多数人第一次用 Claude Code 写一个“给用户发邮件并记录日志”的功能时，会直接丢过去一句：“帮我实现一个发送邮件的服务”。结果它生成了 300 行带 SMTP 配置、模板渲染、异步队列、重试逻辑、日志埋点的完整类——而你其实只想在本地测试下邮箱配置是否通。
这不是模型太强，是它根本没被教会“此刻该做什么粒度的事”。
我见过三个项目因此返工：一个后端团队用 Claude Code 自动生成微服务接口，结果每个接口都自带 OAuth2 审核流和审计日志中间件，最终上线前删掉了 65% 的代码；一个前端组让 AI 基于 Figma 设计稿生成 Vue3 组件，AI 自动把所有按钮都包进了<PermissionGuard>，但权限系统压根还没接入；还有一个嵌入式小组，让 Claude Code 写 STM32 的 UART 接收中断处理，它顺手加了 JSON 解析和 MQTT 上报——而硬件连 Wi-Fi 模块都没焊。
这些不是 prompt 写得不够好，而是任务边界在输入那一刻就模糊了。Claude Code 不会主动问你：“这个功能当前只跑在开发环境，要不要跳过鉴权？”它也不会判断：“你刚改完build.gradle，接下来应该先验证依赖解析，而不是直接写业务逻辑。”
任务拆解，本质上是你在和 AI 共同定义工作流的“控制权交接点”。它不发生在 prompt 里，而发生在你按下回车前的 0.8 秒犹豫中：这一段，是我来划边界，还是让它自由发挥？
本文讲的不是“怎么写更好的 prompt”，而是你在个人提效工作流中，必须
