用途：日常交付与月度结算 • 三件单据构成"任务 → 验收 → 付费"的完整证据链 版本：v1.0 ⚠️ 这三张表是整套人天计价机制的落地载体。 缺任何一张，结算就会有争议。
════════════════════════════════════════════════════════
任务卡 #[编号] 状态：☐待领取 ☐进行中 ☐待验收 ☐已验收 ☐已关闭
════════════════════════════════════════════════════════
【基本信息】
标题：______________________________________________
申请方（业务方）：__________ 派发人（TL）：__________
工程师：__________ 要求等级：☐L1 ☐L2 ☐L3
创建日期：__________ 截止日期：__________
所属模块/迭代：__________________
【估算当量】（三点估算，加权 = (乐观 + 4×最可能 + 悲观) ÷ 6）
乐观：____ 人天 最可能：____ 人天 悲观：____ 人天
加权当量：____ 人天
锁定确认：工程师签字 ____ TL 签字 ____ 日期 ____
【背景】
（为什么做这件事？现状有什么问题？相关背景链接）
【目标】
（做完之后，什么会变得不一样？用可观测的方式描述）
【交付物清单】
1.
2.
3.
【验收标准 DoD】（必须逐条可判定，不允许出现"优化""完善""尽量"等模糊词）
☐ 1.
☐ 2.
☐ 3.
☐ 4. 代码已合入（经 TL review，不得自审自合）
☐ 5. 有文档产出（接口文档 / 使用说明 / 变更记录，三选一）
☐ 6. 有自测记录（截图 / 日志 / 测试报告，三选一）
☐ 7. 无调试残留、无注释掉的代码、无硬编码配置
【依赖与前置条件】
（需要谁提供什么？没有这些会阻塞）
- 依赖：
- 提供人：
- 提供时间：
【明确不做的事】（范围边界，防止范围蔓延）
-
-
【风险与已知不确定】
-
【需求方联系人】（仅用于澄清，不用于派活）
姓名：______ 沟通方式：______
【不计入结算的部分】（写进卡片，避免事后争议）
- 因需求变更导致的返工（由我方承担，另行开卡）
- 因质量问题导致的返工（不额外付费）
- 学生自愿的额外学习时间
════════════════════════════════════════════════════════
【验收记录】（验收时填写）
════════════════════════════════════════════════════════
验收人：______ 验收日期：______
逐条核验结果：
DoD 1：☐通过 ☐不通过 说明：
DoD 2：☐通过 ☐不通过 说明：
DoD 3：☐通过 ☐不通过 说明：
DoD 4：☐通过 ☐不通过 说明：
DoD 5：☐通过 ☐不通过 说明：
DoD 6：☐通过 ☐不通过 说明：
DoD 7：☐通过 ☐不通过 说明：
验收结论：☐一次通过 ☐退回修改后通过 ☐重做
本次计入结算当量：____ 人天
返工是否因我方需求变更：☐是 ☐否 （是→另行开卡计入结算）
工程师确认签字：______ 日期：______
════════════════════════════════════════════════════════
| 等级 | 单卡规模上限 | 典型任务 |
|---|---|---|
| L1 | 1 人天 | 修一个明确 bug、补一组单测、还原一个静态页面、撰写一份文档 |
| L2 | 3 人天 | 一个完整接口、一个带交互的页面、一个测试模块、一份需求文档 + 线框图 |
| L3 | 5-8 人天（须拆子任务） | 一个模块的设计与实现、跨端联调、技术攻关、带新人完成一个模块 |
超限处理：超过上限的任务必须拆分。拆不动说明需求本身没想清楚，回到需求澄清环节。
| 反模式 | 后果 | 正确做法 |
|---|---|---|
| "把这个页面做得好看一点" | 无法验收、无尽返工 | 改成可判定的具体条目（如"在 1280px 和 375px 宽度下均无横向滚动条"） |
| "优化一下这个接口的性能" | 无法验收 | "接口 P95 响应时间从 800ms 降到 300ms 以内，附压测数据" |
| "顺便把相关的也改一改" | 范围蔓延 | 另开卡 |
| 口头派活，事后补卡 | 结算争议 | 先开卡再派活 |
| 验收标准里写"尽量""大约""基本" | 必然扯皮 | 换成数字或明确的通过/不通过条件 |
| 截止日期未考虑考试周 | 必然逾期 | 排期前先查校历关键节点表 |
任务只有在以下全部满足时才算完成，方可进入结算：
| # | 条件 | 判定方式 | 不满足时 |
|---|---|---|---|
| 1 | 代码已合入主干（经 TL review） | 查看 PR 合并记录 | 不算完成 |
| 2 | 有测试或明确的验证手段且通过 | 查看测试报告/自测记录 | 不算完成 |
| 3 | 有文档产出 | 查看文档链接 | 不算完成 |
| 4 | 有自测记录（截图/日志/报告） | 查看附件 | 不算完成 |
| 5 | 无调试残留（print/console.log/TODO/注释代码） | 代码搜索 | 退回修改 |
| 6 | 无硬编码配置（密钥、地址、账号） | 代码审查 | 退回修改 |
| 7 | 任务卡状态已更新，剩余风险已说明 | 查看卡片 | 不算完成 |
| 8 | 不得自审自合（提交者与 reviewer 必须是不同人） | 查看 PR | 不算完成 |
| 说法 | 为什么不算完成 |
|---|---|
| "代码写完了" | 没测、没文档、没 review |
| "在我这儿能跑" | 无法自测记录证明，且未在约定环境验证 |
| "PR 提交了，还没人 review" | 未合入 = 未完成 |
| "文档后面补" | 后面永远不会补 |
| "测试通过率 100%" | 如果只测了成功路径，100% 没有意义 |
| "基本实现了" | "基本"不是验收标准 |
每周五由 TL 填写并公示（仅公示本人与当周汇总，不公示他人明细），月末汇总成结算依据。
周期：____ 年 __ 月 __ 日（周一） ~ __ 月 __ 日（周日） TL：______ 填表日期：______
| 姓名 | 等级 | 任务卡号 | 任务标题 | 模式 | 投入人天 | 验收当量人天 | 团队贡献人天 | 当日认定人天 | 验收状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
| L1 | 交付 | ☐已验收 ☐退回 ☐进行中 | ||||||||
| L1 | 交付 | |||||||||
| L2 | 交付 | |||||||||
| L2 | 培养 | — | — | ☐培养期 | ||||||
| L2 | （讲席主讲） | 团队贡献 | — | — | 0.25 | 0.25 | ☐已确认 | |||
| L3 | 交付 |
模式说明：
培养 = 入组前 4 周，按投入人天计，单价 × 60%，每周上限 2 人天交付 = 第 5 周起，按已验收当量人天计，单价 × 100%团队贡献 = 讲席主讲、review 他人 PR、整理文档、带新人，每人每周 ≤0.25 人天，单价 × 100%| 姓名 | 本周认定人天 | 累计（本月） | 是否超封顶（2 人天/周） |
|---|---|---|---|
| ☐正常 ☐已封顶 | |||
| 合计 |
| 姓名 | 异常情况 | 处理方式 |
|---|---|---|
| 任务退回（DoD 未达标） | 不计入结算；已记录 | |
| 请假/考试周 | 当期计划降载，不视为违约 | |
| 超时未交付 | 空转时间不计入；需在周会说明 | |
TL 签字：______ 日期：______
结算周期：____ 年 __ 月 团队人数：__ 人 TL：______
| 序号 | 姓名 | 等级 | 培养期认定人天 | 交付期认定人天 | 团队贡献人天 | 单价（元/人天） | 应付金额（元） | 个税预扣（元） | 实付金额（元） | 学生确认 |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | L1 | 280（培养期 168） | ☐ | |||||||
| 2 | L1 | 280（培养期 168） | ☐ | |||||||
| 3 | L2 | 380（培养期 228） | ☐ | |||||||
| 4 | L2 | 380（培养期 228） | ☐ | |||||||
| 5 | L2 | 380（培养期 228） | ☐ | |||||||
| 6 | L2 | 380（培养期 228） | ☐ | |||||||
| 7 | L3 | 500（培养期 300） | ☐ | |||||||
| 8 | L3 | 500（培养期 300） | ☐ | |||||||
| — | 组长津贴 | — | — | — | — | — | 1,000 | ☐ | ||
| 合计 |
| 指标 | 数值 | 目标 | 达标 |
|---|---|---|---|
| 团队总认定人天 | — | — | |
| 人均认定人天 | ≥5.5 | ☐ | |
| 任务按期验收率 | ≥80% | ☐ | |
| 因质量返工率 | ≤15% | ☐ | |
| 团队贡献人天占比 | 5%-10% | ☐ | |
| 单位有效人天成本 | 逐月下降 | ☐ | |
| 本月流失人数 | 0-1 | ☐ |
| 角色 | 签字 | 日期 |
|---|---|---|
| TL（编制） | ||
| 技术负责人（审核） | ||
| 财务（复核并付款） | ||
| 学生本人（确认明细） |
付款时限（v1.1 修正）：当月工作量在当月 25 日预结 70%，次月 15 日结清 30%。⚠️ v1.0 的"次月 15 日前一次结清"对学生太慢（他们要交学费、买设备、可能垫钱）——学生现金流是留存的第一变量。学生确认环节不可省——省略则后续必生争议。
质保金（v1.1 新增）：每个模块预留 10-20%，在上线 30 天无 P1/P2 缺陷后释放。这一条同时解决三件事：① 补齐与外包的可比口径（外包报价含质保期）② 把结算挂到上线后的真实质量 ③ 给学生"上线后表现"的激励。
交接抓手（v1.1 新增）：最后一期款项在"离场交接清单"验收通过后支付。v1.0 只写了"提前 2 周告知"，没有财务抓手。
⚠️ 具体金额待定。示例仅演示计算规则，所有"应付/预扣/实付"数字在费率定稿后填入。
示例 1 · L1 学生，第 1 个月（培养期）——计算规则演示
| 项目 | 数据 |
|---|---|
| 第 1 周投入 | 1.0 人天（环境搭建、读文档） |
| 第 2 周投入 | 1.5 人天 |
| 第 3 周投入 | 1.75 人天 |
| 第 4 周投入 | 1.75 人天 |
| 合计投入 | 6.0 人天 |
| 单价 | L1 培养期 = L1 单价 × 60%（金额【待定】） |
| 应付 | 合计投入人天 × 单价（金额【待定】） |
| 个税预扣 | 按劳务报酬预扣规则计算（金额【待定】） |
| 实付 | 应付 − 预扣（金额【待定】） |
| 次年汇算 | 年收入 < 6 万免征额 → 预扣可全额退回 |
示例 2 · L2 学生，第 2 个月（交付期）——计算规则演示
| 项目 | 数据 |
|---|---|
| 完成任务卡 | #0512（2.0 人天，已验收）、#0518（1.5 人天，已验收）、#0523（2.0 人天，1 次退回后通过） |
| 交付期认定当量 | 2.0 + 1.5 + 2.0 = 5.5 人天 |
| 团队贡献 | 主讲技术讲席 1 次 = 0.25 人天 |
| 单价 | L2 交付期单价（金额【待定】） |
| 应付 | 认定当量 × 单价（金额【待定】） |
| 个税预扣 | 按劳务报酬预扣规则计算（金额【待定】） |
| 实付 | 应付 − 预扣（金额【待定】） |
示例 3 · 争议场景
学生认为 #0523 实际花了 5 小时，应按 3 人天算，而不是卡上锁定的 2.0 人天。
处理：
规则一句话：锁定的当量不追溯，但估算偏差要沉淀为基线改进。 这是让学生不觉得"吃亏"、同时防止当量通胀的唯一平衡点。