# 切任务时按什么切：从“它要改哪几个文件”到“哪一步能自己跑起来”
从按层切为什么每片都悬空，到最薄竖切的三问自查与排序规则，以及什么情况下整块交更划算
> 任务规划 · AI 编程协作 · 长任务可靠性 · 约 6 分钟 · 10 月 21 日
## 本篇要点
1. 决定切分方式的不是文件数量，而是这一片单独存在时能不能被观察和判定；按层切出来的每一片都不产生可观察行为。
2. 可观察行为只存在于贯通所有层的路径上，所以切分单位应是最薄的竖切：跨数据库、后端、页面，但每层只动最少的一点。
3. 三问自查：只做这一片系统会不会坏、能不能用一句可执行的话说出怎么验证、还能不能再抽出更小的一片。
4. 排序上把最不确定的部分做成前置探针，先接通只读的最短路径，再补写操作、筛选和边界规则，边界要紧跟 happy path 而不是推后。
5. 一片的下限是值一次提交加一次审查；一句话能描述完的改动直接整块交。
---
你已经能把一句模糊需求补成五个槽位，也能让 AI 先交一份计划再动手。现在卡在中间那一层：计划批了，这一大块活儿，是整块丢给它，还是自己先切成几段？
假设任务是：给一个内部待办小工具加标签，能打标签、能按标签筛选。你先让它出计划，它回了一份清单：
```
migrations/003_add_tags.sql（新）
models.py
views.py
templates/list.html
tests/test_tags.py
```
看起来很像路线图，于是你让它“一项一项做”。问题不在于清单对不对，而在于你把“它要碰哪些文件”当成了“按什么顺序推进”。
## 按文件切，每一片都是悬空的
照这份清单做，四步各自能验证到什么：迁移写完，只能验证它没报错，别的跑不起来；模型函数加单元测试，验证的是“函数按我以为的方式工作”，但这些函数从没被真实请求调用过；视图改完，页面还没有标签，跑一遍只能说“没报错”；模板改完，直到这一刻你才第一次看见标签显示出来。
这种切法在工程上叫**按层切**（horizontal slice）：每一片只穿过一层，共同特征是**单独拿出来都不产生可观察的行为**——表结构自己不做任何事，接口自己没人看得见，页面自己没有数据可显示 [2][3]。
致命的地方在假设。层与层之间默认了一堆东西：字段叫 `name` 还是 `title`、筛选接口返回数组还是带分页的对象、没有标签时返回空数组还是 `null`。这些假设在做前几片时没机会被检验，因为在最后一步之前它们根本不碰面，于是所有不匹配同时堆到最后一刻爆发，而那时你已经写了三片“看起来完成”的代码 [1]。
对 AI 来说还有一层坏处：它在每一片结束时都需要一个信号（上一篇里那条检查命令）。按层切时，前三片能给的信号只有“没报错”和“单元测试绿了”，这两个都不回答“功能通了吗”。于是它只剩猜，你只剩信。
## 换一种切法：每一片都从入口穿到存储
同一个任务，跨层切是这样几片。
**第 0 片，探针**：先回答一个不确定的问题——项目没有迁移工具，加一张表该怎么加？用几十行一次性代码验证，验证完就丢。
**第 1 片，只读通路**：建标签表，写个临时的脚本把标签挂到某个任务上，任务列表页显示标签。验证只有一句：跑脚本，打开页面，看到“工作”两个字。这一片横跨数据库、查询、模板三层，但每层只动最少的一点。
**第 2 片，能写**：页面上加输入框，给任务追加标签并保存。验证：点一遍，标签出现在列表里，刷新还在。
**第 3 片，筛选**：按标签过滤列表。验证：点标签，列表只剩带它的任务。
**第 4 片，规则与边界**：同名标签不重复、空标签拒绝、超长标签报错。验证：三条各自对应的测试。
第 1 片先做“只读”不是随手排的：它是最短的一条贯通路径，会在第一时间把三层之间的接口钉死——字段名、返回结构、空值怎么表示。接口被真实调用过一次之后，后面几片都是在这个确定的基础上加，而不是各自再猜一遍。这种切法叫**最薄的竖切**（thin vertical slice）：切过所有层，但每层只切一点点 [1][3]。
分界就在这儿：**可观察的行为只存在于一条贯通所有层的路径上，按改动清单切出来的碎片不在任何一条这样的路径上。**
## 三问：这一片切对了吗
把一个任务切成几片后，逐片自查：
1. **完整性**：如果这是最后一次改动、以后永远没人再碰这个项目，系统会坏吗？会坏，说明这一片还得靠下一片才能工作，那它仍然是按层切出来的。
2. **可判定性**：能不能用一句可执行的话回答“怎么知道它对了”——跑哪条命令，或者打开哪个页面看什么？答案只能是“代码写完了”，就切错了。（原版这条问的是“对用户有价值吗”；和 AI 协作时，能不能当场判定更要紧，因为判定是它继续干活的前提 [3]。）
3. **细度**：还能从中抽出更小的一片吗？能，就再抽。
```mermaid
flowchart LR
A["切出一片"] --> B{"只做这一片、
不接下一步，
系统会坏吗？"}
B -->|"会"| C["还是按层切
重新跨层切"]
B -->|"不会"| D{"能用一句可执行的话
说出怎么验证吗？"}
D -->|"说不出"| C
D -->|"能"| E{"还能抽出
更小的一片吗？"}
E -->|"能"| A
E -->|"不能"| F["这一片可以交给它了"]
```
## 排序：最不确定的先问，能看的先跑通
**最不确定的排最前。** 不确定性会让切分失效：那个库若压根不支持你要的用法，第 3 片整片都要推倒。所以先做探针，代价只是丢掉几十行。
**先读后写，先通后全。** 先把最短路径接通，再加能力，最后补规则。但规则和错误处理不能无限推后，要排在 happy path 的下一片，而不是记进“以后再说” [1]：否则它永远排不上，而 AI 生成的代码在边界上恰恰最需要你补。
**接口在前一片结束时定下来。** 每一片其实交付两样东西：一段能跑的代码，和下一片要遵守的接口约定。把第二样写进下一片的指令，它就不用再猜。
## 什么时候整块交更划算
不是所有任务都值得切。如果这次改动你一句话就能描述完（改个文案、加一行日志、重命名一个变量），切成两片只是给自己找事——规划和切分本身也是开销 [4]。
下限大致是：**一片得值一次提交加一次审查。** 切到每片都要重新交代上下文、重跑全套检查、重读一遍 diff，协调成本就超过收益了。这条和原子提交那条判据其实是同一个：这一片，是不是一个能独立解释、独立回滚的意图。
切分也不是什么新动作，它就是把需求那五个槽位和计划里那几件事分配到每一步：每一片只带自己那一小份完成标准。发指令时照这个模板写：
> 只做第 1 片：在任务列表页显示标签，数据用我给你的脚本塞进去。不要动路由和筛选，不要格式化无关文件。改完跑 `make check`，并把页面上看到标签的截图贴回来。先别提交。
范围、边界、验证方式、停手点，四样齐了，它才可能第一次就做对。
## 术语表
- 按层切（horizontal slice）：一个任务按数据库、后端、页面这样的层拆开，每片只碰一层；特点是每片单独都跑不起来，层与层之间的假设要等到最后才碰面。
- 最薄的竖切（thin vertical slice）：切过所有层、但每层只切一点点的一小片功能，做完就能从头到尾跑通并被验证。
- 探针（spike）：为回答一个不确定的技术问题而写的一次性最小实验，验证完就丢，不进产品代码。
## 来源
1. [MinimumCD: Work Decomposition — 竖切与按层切的对照，以及每片以小时计、合并后主干可用、边界案例紧跟 happy path 的分解准则](https://beyond.minimumcd.org/docs/migrate-to-cd/foundations/work-decomposition/)
2. [MinimumCD: Horizontal Slicing — 为什么按层切的每一片都没有可观察行为，集成风险为何集中到最后一步](https://beyond.minimumcd.org/docs/anti-patterns/team-workflow/horizontal-slicing/)
3. [Tom Dalling: Work In Thin Vertical Slices — 竖切的三项检验（价值、完整性、细度）及与按层切的逐条对比](https://www.tomdalling.com/blog/work-in-thin-vertical-slices/)
4. [Claude Code 官方最佳实践 — 先给可运行的验证手段，以及“一句话能描述出 diff 就跳过规划”的取舍](https://code.claude.com/docs/en/best-practices)
---
原文：https://pangzhengboyin.com/articles/slicing-tasks-for-ai-vertical-slices-8b24ee35
> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com