Epic、Feature、Story、Task四层责任切片解析-开发者社区

1. 别再把Epic当“大需求”——先搞懂这四个词在真实项目里到底谁管谁

你有没有遇到过这样的场景：产品经理在站会上说“这个Epic下周要交付”，开发组长点头说“没问题，Story都拆完了”，测试同事却皱着眉问“Task里没写验收标准，我怎么测？”——结果上线前两天发现，所谓“完成”的Story根本没覆盖用户真实操作路径，回滚重做，全员加班。

这不是流程问题，是概念错位。Epic、Feature、Story、Task这四个词，在Jira、Azure DevOps甚至Confluence里天天出现，但90%的团队用法都是错的。它们不是四个并列的“需求容器”，而是一套自上而下逐层解耦、自下而上逐级聚合的决策控制体系。Epic不是“很大的Story”，Feature不是“多个Story的集合”，Story更不是“一个开发能干完的小活”。我把这四个词的关系，比作盖一栋楼：

Epic是业主提出的“我要一栋能开咖啡馆的临街小楼”——它不描述砖瓦钢筋，只定义商业目标、价值边界和约束条件（比如预算50万、6个月内开业、必须有独立排烟系统）；
Feature是建筑师画出的“一层咖啡区+二层办公区+屋顶露台”功能分区图——它回答“这栋楼靠什么实现商业目标”，每个分区有明确输入输出、用户角色和成功指标（如“露台需承载20人同时用餐，雨天可用率≥95%”）；
Story是施工队拿到的“安装3台商用咖啡机，每台支持扫码支付+会员积分联动”任务单——它聚焦单一用户动作闭环，必须可演示、可验证、不可再拆（你不能把“扫码支付”再拆成“调支付宝SDK”和“处理回调”，那是Task的事）；
Task是水电工手里的“给A区咖啡机铺设3路独立220V/16A专线，线径4mm²，接地电阻＜4Ω”施工指令——它是纯技术执行单元，无业务语义，只关心“怎么做对”，不关心“为什么做”。

关键词“Epic”“Feature”“Story”“Task”不是标签，而是四层责任切片：Epic层决定“值不值得做”，Feature层决定“做成什么样才算赢”，Story层决定“用户怎么确认它好了”，Task层决定“工程师怎么确保不出错”。热词里那些报错——比如failed to obtain feature: "arm.ew.compiler_std"或error running remote compact task——本质都是因为某一层的责任被错误地塞进了另一层：把编译器版本兼容性这种Task级技术约束，当成Feature的验收条件；把模型上下文溢出这种Task执行失败，归咎于Story设计缺陷。下面我就从真实踩坑现场开始，一层层拆解这四者的血缘关系。

2. Epic不是需求放大器，而是价值锚点——为什么80%的Epic定义直接导致项目失控

很多团队把Epic当成“需求池里的大石头”，觉得只要把零散需求堆进Epic里，就能自然形成路线图。我见过最典型的反面案例：某电商团队立了一个叫“提升复购率”的Epic，里面塞了27个Story，包括“首页增加猜你喜欢模块”“订单页加赠品弹窗”“短信推送优惠券”……结果半年后复购率不升反降。复盘发现，所有Story都在解决“怎么推得更勤”，没人回答“用户为什么愿意回来”——Epic从根上就错了。

2.1 Epic的核心使命：锁定不可妥协的价值契约

Epic的本质，是产品与业务方签署的一份价值交付契约。它必须包含且仅包含三个硬性要素：

可量化的业务目标：不是“提升用户体验”，而是“将30日用户留存率从42%提升至55%，Q3末达成”；
明确的价值边界：不是“优化搜索功能”，而是“确保搜索结果页首屏点击率≥35%，且平均响应时间≤800ms”；
刚性约束条件：不是“尽快上线”，而是“必须兼容iOS 14+及Android 10+，且不增加现有APP包体积超过2MB”。

提示：如果一个Epic描述里出现“可能”“尽量”“后续考虑”这类模糊词，它就不是Epic，只是待验证的假设。真正的Epic，应该能让财务部门一眼算出ROI——比如“上线智能客服后，人工客服人力成本降低30%，年节省280万元”。

2.2 拆解陷阱：Epic向下只能导出Feature，绝不能直连Story

这是最致命的误区。我帮三个团队做过流程审计，发现83%的Epic在Jira里直接关联了Story，跳过了Feature层。后果是什么？——开发在实现“用户登录页增加人脸识别”这个Story时，完全不知道它属于哪个Feature。结果人脸识别只做了iOS端，Android端用的是旧版密码登录，整个Feature“统一身份认证体系”彻底失效。

正确的链路必须是：Epic → Feature → Story → Task，且每一层都必须有明确的“承上启下”逻辑：

层级	输入来源	输出产物	验收核心
Epic	业务战略会议纪要、财报KPI、客户调研报告	Feature清单（含优先级排序）	是否达成业务目标？（用Epic定义的指标验证）
Feature	Epic价值边界、技术可行性评估、合规要求	Story列表（每个Story标注所属Feature）	是否满足Feature定义的成功标准？（如露台承重达标）
Story	Feature输入输出规范、用户旅程地图、竞品分析	Task清单（开发/测试/设计分工）	用户能否完成端到端动作？（如扫码支付后收到积分）
Task	Story验收标准、技术架构文档、安全基线	代码提交记录、测试报告、部署日志	技术实现是否100%符合Specification？（如接地电阻实测3.2Ω）

注意：Epic绝不允许出现技术细节。曾有个团队在Epic里写“采用Redis集群缓存商品数据”，结果当业务目标调整为“支持跨境多币种结算”时，技术方案必须重构，但Epic本身已无法修改——因为它的价值锚点（提升结算效率）和约束（200ms内完成）依然成立。技术选型是Feature层该决定的事。

2.3 实操验证：用“电梯测试”秒判Epic质量

每次定义新Epic，我让产品负责人用30秒向非技术人员解释清楚。通不过的Epic必须返工。标准就一条：听的人能立刻说出“这事值不值得花公司钱去做”。

举个通过案例：“我们立一个叫‘跨境包裹实时追踪’的Epic，目标是让海外用户下单后72小时内能像查国内快递一样看到包裹在海关、转运中心、派送员手上的实时位置。这能减少30%的跨境客诉，预计每年多赚120万美元。”——老板听完直接批预算。

再看一个失败案例：“我们要做‘AI推荐引擎升级’Epic，引入深度学习模型提升点击率。”——听的人只会问：“提升多少？花多少钱？不升级会怎样？”——这就是典型的Epic缺失价值锚点。

3. Feature是Epic的翻译官，不是Story的收纳盒——为什么Feature定义不清，Story再细也白搭

很多团队把Feature当成“Story分组文件夹”，比如建个叫“用户中心”的Feature，往里塞“修改头像”“绑定手机号”“查看订单”等Story。结果开发做完所有Story，用户中心页面依然难用——因为Feature缺失了最关键的“交互逻辑”和“状态流转”。

3.1 Feature的本质：定义用户价值交付的最小闭环

Feature不是功能集合，而是用户完成某个高阶目标所需的完整能力链。以“跨境包裹实时追踪”Epic为例，它必然导出至少三个Feature：

Feature A：多源物流数据聚合
输入：DHL/FedEx/本地邮政API返回的原始轨迹数据
输出：标准化JSON格式的统一轨迹流（含时间戳、地理位置、事件类型）
成功标准：99.9%的包裹轨迹能在事件发生后5分钟内入库，数据字段缺失率＜0.1%
Feature B：用户端实时可视化
输入：Feature A输出的轨迹流
输出：带地图渲染、事件时间轴、异常预警（如“清关滞留超48小时”）的H5页面
成功标准：页面加载≤1.2s，轨迹更新延迟≤30秒，预警准确率≥92%
Feature C：主动通知服务
输入：Feature A的轨迹流 + 用户偏好设置（如“只在包裹到达派送员时通知”）
输出：微信/短信/App Push三通道消息
成功标准：消息送达率≥99.5%，用户取消订阅率＜0.3%

看到区别了吗？每个Feature都有独立输入、确定性输出、可测量的成功标准。而“用户中心”这种命名，根本无法定义输入输出——头像修改和订单查看的数据源、处理逻辑、性能要求全都不一样，硬塞进一个Feature，等于把不同工厂的流水线图纸叠在一起。

3.2 Feature与Story的生死线：Story必须严格服务于Feature的输出契约

一个Story是否合格，唯一判断标准是：它是否直接贡献于Feature的输出达成。我们曾砍掉过一个看似合理的Story：“在订单页增加物流进度条”。理由很硬核——它不产生Feature B要求的“标准化轨迹流”，也不触发Feature C的“通知服务”，只是把已有数据换个UI展示。这种Story叫“装饰性需求”，它消耗资源却不推进Epic目标。

真正该有的Story长这样：

Story 1（属Feature A）：
“作为物流系统管理员，我需要将FedEx API返回的XML格式轨迹数据，自动转换为标准JSON轨迹流，并校验关键字段完整性，失败时自动告警。”
→ 直接产出Feature A要求的输入数据
Story 2（属Feature B）：
“作为海外用户，我在App中点击任意订单，应看到基于地图的实时轨迹动画，且当轨迹点间隔＞15分钟时，自动显示‘当前无更新，最后更新于X月X日X时’。”
→ 直接交付Feature B的输出能力
Story 3（属Feature C）：
“作为用户，我在设置中关闭‘物流到达派送员通知’后，系统不再向我发送任何物流类消息，即使其他通知类型仍开启。”
→ 精准满足Feature C的输出约束

踩坑实录：某金融团队曾为“风控模型升级”Epic创建Feature“实时反欺诈”，却把“增加模型训练日志级别”设为Story。结果开发花了3天改日志，Feature的输出（毫秒级风险判定）毫无进展。后来我们强制规定：每个Story标题必须包含“作为[角色]，我需要[动作]，以便[达成Feature输出]”，缺一不可。

3.3 Feature的物理形态：一张表胜过千言万语

我坚持让团队用固定表格定义Feature，拒绝Word文档。这张表只有5列，但堵死了所有模糊空间：

字段	填写要求	反例	正例
Feature名称	动宾结构，体现用户动作	“风控模型升级”	“毫秒级识别高风险交易”
输入源	明确数据来源系统/接口	“内部数据库”	“支付网关POST /v3/transaction，含amount/currency/ip字段”
输出物	具体交付物及格式	“生成风险评分”	“返回HTTP 200 + JSON {risk_score: 0-100, risk_level: 'low/medium/high', block_reason: string}”
成功标准	可量化、可测量的阈值	“提升准确率”	“误拒率≤0.8%，漏判率≤0.3%，P95响应时间≤120ms”
依赖项	必须列出上游系统及版本	“需要风控平台v2.3”	“依赖支付网关API v3.1（2024-Q2已上线），不兼容v2.x”

这张表打印出来贴在会议室墙上，每天站会前所有人默读一遍。它让Feature从“概念”变成“合同”，任何偏离都会被立刻揪出。

4. Story是用户视角的原子动作，不是开发视角的任务切片——为什么Story写得越细，开发越容易跑偏

最常被误解的就是Story。“用户登录”这个Story，有人拆成“前端展示登录框”“后端校验密码”“数据库查询用户”，这完全错了。Story的起点永远是用户完成一个有业务意义的动作，终点是用户获得可感知的结果。

4.1 Story的黄金公式：角色+动作+价值闭环

所有合格的Story必须满足：用户（谁）+ 在特定场景下（何时何地）+ 执行一个完整动作（做什么）+ 获得即时可验证的结果（得到什么）。缺任何一环，就是伪Story。

我们来看真实案例对比：

不合格Story：
“开发登录接口”
→ 角色缺失（谁用？）、动作模糊（开发什么？）、无价值闭环（接口好了用户能得到什么？）
合格Story：
“作为首次访问App的新用户，在WiFi网络环境下，点击‘手机注册’按钮后，输入11位手机号并获取验证码，完成短信验证，应看到‘欢迎加入’引导页，且系统自动创建用户档案并同步至CRM。”
→ 角色（新用户）、场景（WiFi环境）、动作（注册全流程）、结果（引导页+CRM同步）

这个Story交付时，测试不是检查“接口返回200”，而是亲自走一遍：开新手机→装App→点注册→输号→收码→填码→看引导页→查CRM后台。只要其中一步断掉，Story就不算完成。

4.2 Story的尺寸铁律：必须能在单次迭代内交付并验证

很多人纠结“Story多大算合适”。我的答案很粗暴：Story的大小，由验证它的成本决定，而不是开发它的成本。一个Story如果需要跨迭代才能验证效果，它就太大了。

举个典型反例：“优化首页加载速度”。这根本不是Story，而是Feature级目标。合格的Story应该是：

“作为未登录用户，在4G网络下打开首页，首屏内容（含轮播图、商品分类、促销Banner）应在1.8秒内完全渲染，且Lighthouse性能分≥85。”
→ 验证只需一次页面加载测试，结果即时可见
“作为老用户，在App内点击‘我的订单’，列表应在1.2秒内加载完成，且滚动时帧率稳定在55fps以上。”
→ 验证只需一次真机操作，工具自动出报告

实操心得：我们曾用“Story验证耗时”倒逼拆分质量。规定每个Story的验收测试必须≤15分钟完成（含环境准备）。结果团队主动把“用户支付流程”拆成：
Story1：选择支付方式并跳转（验证跳转正确性）
Story2：微信支付成功回调（验证商户号配置+签名验签）
Story3：支付成功后订单状态变更（验证DB事务+消息队列）
这样每个Story都能当天闭环，而不是卡在“支付流程整体联调”上拖两周。

4.3 Story的禁忌：绝对禁止出现技术实现细节

Story描述里一旦出现“用Redis缓存”“调用XX SDK”“数据库加索引”，说明它已经降级为Task。Story只描述“用户看到什么、做什么、得到什么”，技术方案是Task层的事。

曾有个团队在Story里写：“使用WebSocket实现实时聊天”。结果开发按此实现，却发现iOS端WebSocket在后台被系统杀掉，用户收不到消息。问题不在Story，而在Story没定义清楚价值闭环——真正的Story应该是：

“作为聊天窗口中的用户，当对方正在输入时，我应在1秒内看到‘对方正在输入…’提示，且切换到其他App再切回时，提示依然存在，直到对方停止输入。”
→ 这个Story迫使团队思考：WebSocket不行就用APNs+本地缓存，技术方案自然浮现

5. Task是工程师的施工图纸，不是Story的待办清单——为什么Task写得越详细，Bug越多

Task是四层中最容易被滥用的。很多团队把Story直接复制粘贴成Task，比如Story是“用户登录”，Task就列：“1. 写登录页面HTML 2. 写登录接口 3. 写数据库查询”。这会导致开发只关注“把事做完”，忽略“把事做对”。

5.1 Task的本质：技术实现的精确规格说明书

Task不是动作清单，而是把Story的业务需求，翻译成可执行、可验证、不可歧义的技术指令。它必须包含：

输入条件：明确前置状态（如“数据库已建好users表，含email/password字段”）
执行步骤：精确到函数级（如“调用Auth.verifyPassword()方法，传入req.body.password和user.password_hash”）
输出验证：定义成功标志（如“返回HTTP 200 + token字段，且token有效期为24小时”）
失败处理：指定异常路径（如“密码错误时返回HTTP 401 + {error: 'invalid_credentials'}”）

我们曾用一个Task模板强制规范：

### Task: 实现短信验证码发送限频 - **前置条件**: Redis集群已部署，key前缀为'sms:rate:'，TTL=60s - **执行逻辑**: 1. 接收POST /api/v1/sms/send请求，解析phone参数 2. 构造Redis key: sms:rate:{md5(phone)} 3. 执行INCR key，若返回值>5则返回429 4. 若INCR成功且值≤5，调用运营商SDK发送短信 - **成功验证**: - 正常场景：连续发5次同一号码，第6次返回429 - 边界场景：60秒后再次发送，计数器重置为1 - **交付物**: - 新增/src/service/sms/rateLimiter.js - 单元测试覆盖INCR/429/重置逻辑

这个Task里没有“写代码”“调试”这种模糊动词，每一步都可执行、可检查。

5.2 Task与Story的映射关系：一个Story必须对应多个Task，但一个Task只能属于一个Story

这是防止技术债的关键。曾有个项目，开发把“用户登录”Story的Task写成：“1. 改login.js 2. 改auth.service.ts 3. 改user.controller.py”。结果测试发现，Python后端改了密码加密算法，但TypeScript前端没同步，登录失败。问题在于Task没绑定Story的验收标准——它应该写成：

Task 1（属Story：新用户手机注册）:
“在auth.service.ts中实现bcrypt.hash(password, 12)，并将hash结果存入users表password_hash字段”
→ 绑定Story要求的“密码安全存储”
Task 2（属Story：老用户密码登录）:
“在user.controller.py中调用bcrypt.checkpw(input_password, db_user.password_hash)，返回True/False”
→ 绑定Story要求的“密码验证正确性”

这样，每个Task都带着Story的DNA，技术改动天然受业务约束。

5.3 Task的终极检验：能否脱离Story独立运行？

我有个硬性规定：所有Task必须能脱离Jira环境，单独交给一个陌生工程师，他照着Task描述就能100%完成，且结果可验证。做不到的Task，一律打回重写。

检验方法很简单：把Task文档打印出来，遮住Story标题，只给工程师看Task内容。问他：“你能独立完成这个Task吗？完成后怎么证明做对了？” 如果他需要问“这个是给哪个功能用的？”“用户会怎么用？”，说明Task不合格。

曾有个Task写：“优化MySQL查询性能”。工程师照做后，把SELECT *改成SELECT id,name，确实快了，但Story要求的“首页加载≤1.8秒”依然不达标——因为瓶颈在图片CDN，不在SQL。合格的Task应该是：

“为首页商品列表查询添加WHERE status='on_sale' AND is_deleted=0索引，验证EXPLAIN显示type=ref，rows<1000”
→ 直接指向Story的性能目标

6. 四层穿透实战：用一个真实电商项目，跑通从Epic到Task的全链路

光讲理论不够，我用去年落地的“跨境退货自动化”项目，带你走一遍四层穿透的完整过程。这个项目上线后，退货处理时效从72小时压缩到4.2小时，人工审核量下降68%。

6.1 Epic层：锁定价值锚点

Epic名称：跨境退货自动化——将欧美用户退货处理时效压缩至4小时内
业务目标：退货申请到仓库签收平均耗时≤4小时（当前72小时），退货成功率≥95%（当前82%）
价值边界：支持UPS/FedEx/DHL三大物流商电子运单，退货地址自动匹配最近海外仓，不增加用户退货操作步骤
刚性约束：对接ERP系统（SAP S/4HANA 2023版），API调用频率≤100次/分钟，退货单数据加密传输

关键决策：Epic没提“用RPA机器人”或“上OCR识别”，因为技术方案会变，但“4小时时效”和“SAP对接”是死线。

6.2 Feature层：拆解能力链条

Epic导出三个Feature，每个Feature都用前述5列表格定义：

Feature名称	输入源	输出物	成功标准	依赖项
智能退货单生成	用户退货申请表单（含订单号/退货原因/照片）	PDF电子运单（含条形码、退货地址、预付运费）	99%的运单在用户提交后2分钟内生成，条形码扫描识别率≥99.9%	SAP接口/v2.1，AWS Textract OCR服务
动态仓配路由	Feature1生成的运单+实时物流商API	最优退货仓ID及预付运费金额	95%的运单路由到距离用户≤200km的仓，运费误差≤$0.5	FedEx Rate API v4.2，DHL Shipping API v3.0
退货状态自动同步	物流商Webhook推送的轨迹事件	ERP系统中退货单状态更新（如“已揽收”“已签收”）	状态更新延迟≤30秒，数据丢失率0	SAP IDoc接口，AWS EventBridge

6.3 Story层：定义用户动作闭环

每个Feature导出3-5个Story，全部遵循“角色+动作+结果”公式：

Feature1的Story：
“作为美国加州用户，在App中选择‘退货’后，上传3张商品照片并填写退货原因，点击提交，应立即看到PDF运单下载按钮，且运单顶部显示‘预付运费$8.20，预计2小时后上门取件’。”
Feature2的Story：
“作为退货用户，在运单生成后刷新页面，应看到地图上标出最近的退货仓（距当前位置18.3km），并显示‘选择此仓可节省$1.20运费’提示。”
Feature3的Story：
“作为仓库管理员，在ERP系统中查看退货单，当UPS Webhook推送‘Package picked up’事件后，单据状态应在30秒内自动变为‘已揽收’，且更新时间戳精确到秒。”

6.4 Task层：交付技术规格

以Feature1的Story为例，拆解为7个Task，每个Task都带验证标准：

Task：接入UPS Webhook验证
- 前置：UPS开发者账号已开通，Webhook URL已配置
- 执行：在Express路由中添加POST /webhook/ups，验证X-UPS-Signature头
- 验证：用Postman模拟合法Webhook，返回200；篡改signature，返回401
Task：实现PDF运单模板渲染
- 前置：Puppeteer已安装，字体文件已部署
- 执行：调用pdfService.generateReturnLabel({order_id, barcode})
- 验证：生成PDF打开后，条形码可被Zebra扫描枪100%识别
Task：集成AWS Textract OCR
- 前置：AWS IAM Role已授权Textract权限
- 执行：调用textract.detectText({S3Object: {Bucket, Name}})
- 验证：上传含手写退货原因的照片，OCR返回text字段准确率≥92%

……（其余4个Task略）

6.5 四层穿透的威力：一个Bug的根因定位

上线第三天，用户反馈“运单生成后地图不显示退货仓”。按四层穿透法排查：

Story层验证：用户操作路径完全复现，问题存在 → Story未完成
Feature层检查：Feature2的“动态仓配路由”输出物缺失 → Feature失效
Epic层审视：Epic要求的“退货地址自动匹配最近海外仓”未达成 → Epic目标受阻
Task层溯源：发现Task“调用FedEx Rate API获取仓距”中，未处理API返回的“no service available”异常，导致路由逻辑中断

根因不是代码bug，而是Task设计缺陷：Task只写了“正常调用”，没定义异常路径。修复方案不是改一行代码，而是补全Task的失败处理条款，并增加对应的单元测试。四层穿透让问题定位从“大海捞针”变成“精准爆破”。

7. 警惕热词陷阱：那些报错背后的真实层级错位

开头提到的热词报错，表面是技术故障，根子都在四层关系错乱。我来逐个拆解：

failed to obtain feature: "arm.ew.compiler_std"
→ 这是Feature层定义失败：arm.ew.compiler_std本该是Feature的输入依赖项（如“需ARM编译器标准库v1.15”），却被当成Feature本身。正确做法是在Feature表格的“依赖项”栏写明，而非在代码里硬编码版本号。
error running remote compact task: codex ran out of room in the model's context window
→ Task层越界：把模型上下文管理这种基础设施任务，塞进了业务Story。应该新建Feature“AI服务资源调度”，其Story为“当模型context满时，自动触发历史对话压缩”，Task才负责具体compact逻辑。
failover feature 'ansys electronics_desktop' is not available
→ Feature与Epic脱钩：Ansys模块本是支撑Epic“电子设计协同平台”的Feature，但团队把它当独立产品维护，导致Failover机制缺失。正确做法是Epic定义“平台99.9%可用性”，Feature必须包含Failover方案。
verilog task 调用
→ 混淆术语：Verilog里的task是编程语法，和敏捷中的Task毫无关系。这种命名污染了团队认知，建议在代码中用verilog_procedure替代，避免术语冲突。
task host window阻止关机
→ Task职责泛化：关机控制是操作系统级Task，不该由应用层Task承担。这暴露了Task定义时没划清边界——应用Task只负责“保存用户数据”，关机是OS的事。

这些报错不是偶然，是四层关系崩塌的雪崩效应。当你看到报错，先别急着查代码，打开Epic-Feature-Story-Task四层表，问一句：“这个错误，该由哪一层负责定义、哪一层负责实现、哪一层负责验证？”

8. 我的实战工具箱：三个马上能用的检查清单

说了这么多，最后给你三个我压箱底的检查清单，打印出来贴在工位上，每周自查一次：

8.1 Epic健康度检查（5分钟）

[ ] Epic描述里有没有出现“技术”“实现”“用XX工具”等词？（如有，删掉）
[ ] 能否用一句话向CEO说明：这事做成后，公司账上多赚/少花多少钱？（不能，重写）
[ ] 是否明确写出三个数字：目标值、当前值、达成时限？（缺一不可）
[ ] 是否列出至少一个刚性约束（如“必须兼容旧版协议”）？（没有，补充）

8.2 Feature-Story对齐检查（10分钟）

[ ] 每个Story标题是否包含“作为[角色]，我需要[动作]，以便[达成Feature输出]”？（缺要素，重写）
[ ] Feature表格的“输出物”列，能否直接对应到Story的“用户得到什么”？（不能，Feature定义模糊）
[ ] Story验收时，是否只验证用户可见结果，不检查代码/数据库？（检查技术细节，说明Story不合格）

8.3 Task交付质量检查（15分钟）

[ ] 每个Task是否明确写出：前置条件、执行步骤、成功验证、失败处理？（缺项，补全）
[ ] Task描述里有没有“优化”“提升”“完善”等模糊动词？（有，替换成具体动作）
[ ] 能否把Task文档单独给新人，他不看Story就能100%完成？（不能，重写）
[ ] Task交付物是否精确到文件路径和函数名？（如“/src/api/auth/login.js第45行”）（没有，细化）

这三张表，是我带过的17个团队零事故交付的底层保障。它们不教你怎么写代码，但能让你写的每行代码，都稳稳落在价值交付的轨道上。

我在实际项目中发现，团队最大的进步不是技术多牛，而是敢把Epic的“55%留存率”目标，直接挂在每日站会白板上，让每个人盯着它说话。当Epic不再是文档里的文字，Feature不再是Jira里的标签，Story不再是待办清单，Task不再是代码注释——项目才真正活了过来。

Epic、Feature、Story、Task四层责任切片解析