创业平台首页工作台：首批场景与模块方案
2026-10-10。看板卡 AIC-2706（清单），开发见 AIC-2709（10/12～10/16，白晨）。底稿是 09-23 创业平台工作台模块清单（AIC-1902），该文的现状表仍成立（工作台代码 09-23 后未改），本文重定范围与优先级，并把每个模块的逻辑写到可开发的程度。 性质：10-10 的方案，白晨已基本认可，并于 10-10、10-11 拍板两批事项（见下方「白晨已定事项」）；10-11 按已定事项改正正文。拍板后的开发口径、排期与工作量以首批开发拆解（下称「拆解」）为准，两者冲突时以拆解为准。还要和吴梦赢确认的只剩第八节两项，10/12 当面过。标注【事实】有出处，【提案】本文建议，【已定】白晨 10-10 或 10-11 拍板，【待确认】要找吴梦赢或白晨确认。 范围（白晨 10-10 定）：只动首页上的模块；顶栏消息、团团入口、其他页面不动，「消息提醒」模块不做。 出处简写：「下午会:N」＝
knowledge/sources/会议对谈/2026-10-08-会议转写-团团演示与周目标复盘及10月16日结项范围-白晨吴梦赢林炜陈高武快速会议.md第 N 行；「分工会:N」＝knowledge/sources/会议对谈/2026-10-08-会议转写-10月16日前分工与本周设计任务-白晨林炜陈高武晚间快速会议.md第 N 行；「待办:N」＝docs/superpowers/plans/2026-10-08-创业平台10月16日结项待办.md第 N 行；「清单:N」＝09-23 模块清单第 N 行；api/＝apps/api/app/，WB/＝apps/web/src/features/workbench/。
白晨已定事项（以开发拆解为准）
下面几条改变了本文初稿的写法，正文已逐处改正；细节与代码证据见拆解 1.2 与第四节「已定」。
10-11 定：结算展示先不做。 白晨 10-11 在与 Claude 的会话中定了结算的未来口径（第九节）：任务完成后由需求方（发单人）验收，不再由系统自动验收，验收通过后尾款自动到账。这套逻辑做完之前，首页上「待到账」这类结算展示不成立，所以先不做：作品与积分的积分部分只显示可用积分，我的任务不显示结算阶段。它取代了下面 10-10 第 2 条，并改写了第 1 条。
10-10 定：
- 阶段只分「进行中／已完成」两档（10-11 改写）：按承接本身的状态分，不看交付与结算。今日行动每行不再挂阶段徽章：原定的「制作中」与「进行中」是同一状态，两处都用就是同一单两种叫法；行右上角改放需求方名字（与改版原型一致，拆解 D6、D10）。10-10 原定「制作中 → 尾款结算中 → 已完成，异常标结算待处理」，其中结算的两档随 10-11「结算展示先不做」去掉。进行中承接的交付在系统里一律是草稿，本来就分不出「未开始」和「交付草稿」（拆解 1.2 第 1 条）。
blocked归「结算待处理」，不计待到账- 作品不显示「是否公开」，入口进任务详情：接口拿不到作品的可见性，系统里也没有作品详情页；作品封面走作品封面接口（拆解 1.2 第 5、6 条）。
- 默认布局改为团团＋5 个 P0 模块，顺序与尺寸（宽×高）：团团 3×1、今日行动 2×4、我的任务 2×1、作品与积分 1×1、我能接的单 1×3、学习推荐 1×3，四列排满 5 行不留空。消息提醒、项目中心、行业资讯、日程移出默认，仍可从「添加模块」加回。只改默认，保存过布局的用户不受影响（拆解已定第 1 条、D4）。作品与积分 1×1 在首页只露可用积分，正好就是 10-11 定的积分展示范围；剩下的问题是最近作品要不要在首页一眼可见，待 10/12 确认会定（拆解「仍待」第 5 条，见第八节）。
- 今日行动「显示几项」2／4 本次做出来，默认 2×4，所以默认就显示 4 项（拆解已定第 2 条）。
- 作品取法：前端取最近 3
个已完成承接的交付详情，作品多了再补
/me/works接口（拆解 D2）。 - 公开任务：10/16 由前端翻页取全量后计算，「只返回未过期」的后端参数放下期第一项（拆解已定第 8 条）。
- 今日行动的来源只含平台任务与今日待办，外部日历本次不做；「有日期的待办并入今日行动」从 P1 首批里后移（拆解 WB-P1-5）。
- 排期与工作量（10-11 按结算展示先不做重算）：P0 共 17 项、9.25 人日（含测试改写），关键路径 3.5 人日；按理想并行最早 10/15 中午收口，现实预期 10/15 下班前收口，10/16 留出约半天按吴梦赢的反馈修。代码开工等 10/12 与吴梦赢确认后再开始，开工每晚半天收口就晚半天。P1 今日待办「尽量挤进」10/16（拆解〇、第三节）。
- 金额一律用接口下发的积分名称（
coin_name），不写死（拆解已定第 5 条）。
〇、一页结论
- 目标：结项目标 ③「个人 AI 工作台：集中掌握任务、认证、交付、积分和作品，从『人找事』到『事找人』」（待办:12，引自「月度结项目标 v1.0」，原文不在仓库；会议转写里没有「人找事、事找人」原话）。
- 两层（白晨「这个事情分 2
个吧」下午会:235；吴梦赢「16
号必须交付的先做」，深的拆一期二期三期，下午会:237）：
- 第一层 · 10/16 交付：吴梦赢列的范围——任务回首页，认证、交付、积分、作品上首页，今日行动，学习推荐（下午会:233～:259）；「你给我个前端我就能交付了」（下午会:259）。其中积分按白晨 10-11 口径只上可用积分，待到账等结算展示等需求方验收上线后再做。
- 第二层 · C 端抢跑：今日待办（白晨，分工会:57「C 端工作台某些功能的抢跑」），并让今日行动按多种来源一起排（吴梦赢，下午会:259）。
- 首批 6 个模块，全部改造现有类型，不新增类型：今日行动、我的任务、我能接的单、学习推荐、作品与积分（以上 P0），今日待办（P1）。消息提醒、项目中心、行业资讯、团团保持现状。
- 场景 7 个：P0 6 个，P1 1 个。三条核心链路：每日推进、事找人、成果沉淀。
- 工作量：P0 五个模块单看都不大（复用现有接口，前端为主），但加上改写存量端到端测试，拆解估 P0 共 9.25 人日（10-11 结算展示先不做后从 10 人日减下来），现实预期 10/15 下班前收口，10/16 留约半天缓冲；P1 今日待办要新建后端事项表，挤进子集 3 人日，P0 按理想收口时可在 10/16 上午收口。排期与工作量以拆解为准。
一、目标用户
平台角色只有普通用户与管理员，接单者、学习者是用户行为，不是角色【事实，docs/superpowers/specs/2026-09-13-9月21日用户与角色设计.md:33、:53-58】。首页
/home 登录后可见，面向普通用户。
| 画像 | 状态 | 打开首页最想知道 | 主要模块 |
|---|---|---|---|
| 接单者 | 有认证、有进行中的承接 | 今天要推进哪单、接的单到哪一步、挣了多少 | 今日行动、我的任务、作品与积分 |
| 学习者（含新用户） | 认证少或没有，暂无承接 | 我能接什么、还差什么认证、去哪学 | 我能接的单、学习推荐 |
二、核心链路
| 链路 | 串法 | 覆盖场景 |
|---|---|---|
| A 每日推进 | 今日行动（平台任务；今日待办并入后移）→ 任务详情里推进交付 → 我的任务状态更新 | S1、S2、S6 |
| B 事找人 | 我的认证 → 我能接的单（现在能接／差 1 个认证）→ 学习推荐（学哪个能多接几单）→ 认证页上传 → 回到能接 | S3、S4、S7 |
| C 成果沉淀 | 提交交付 →（现阶段）系统自动验收，承接转为已完成 → 生成作品，作品出现在作品与积分；尾款到账后可用积分变化 → 我的任务里这单进「已完成」 | S2、S5 |
提交交付即自动验收、发起尾款结算、生成作品，承接同时转为已完成【事实，api/workflows/submit.py:30-71；api/claims/service.py:470-478、api/acceptances/schemas.py:13-22】。这是现阶段的做法；白晨
10-11 定了未来改为需求方验收、验收通过后尾款自动到账（第九节），届时链路
C 中间多一步「等需求方验收」。
三、场景清单
| 编号 | 场景 | 用户价值（打开首页得到什么） | 画像 | 模块 | 优先级 |
|---|---|---|---|---|---|
| S1 | 每天打开：今天推进什么 | 逾期、今天到期、三天内到期的承接任务按紧急程度排好，一眼看到先做哪单 | 接单者 | 今日行动 | P0 |
| S2 | 我接的单到哪一步 | 每单是进行中还是已完成；结算进度先不在首页展示（白晨 10-11） | 接单者 | 我的任务 | P0 |
| S3 | 找下一单 | 现在就能接的任务按报酬排好；差一个认证就能接的单也列出来 | 两者 | 我能接的单 | P0 |
| S4 | 缺认证，学什么 | 推荐学哪个认证最划算（学完能多接几单、多少报酬），附学习链接 | 学习者 | 学习推荐 | P0 |
| S5 | 我挣了多少、做了什么 | 可用积分；最近的作品。待到账、本月到账先不做（白晨 10-11） | 接单者 | 作品与积分 | P0 |
| S6 | 平台之外的事一起排 | 自己记的待办与平台任务放进同一个「今天」 | 两者 | 今日待办＋今日行动 | P1 |
| S7 | 新用户第一次打开 | 没有承接、没有认证时，各模块的空态把人引到「能接什么、先学什么」 | 学习者 | 各模块空态 | P0 |
四、模块逻辑
通用约定【提案】：排序与推荐全部由代码按规则算，不调模型；首页只呈现和跳转，办理在原页面；金额一律显示
coins 与运营配置的
coin_name，不写死「贝壳」，不显示内部基础分
points【事实，api/settlements/models.py:66-69、api/settlements/schemas.py:66-85】。
4.1
今日行动（actions，改造）· P0
| 项 | 内容 |
|---|---|
| 解决什么 | S1：今天先推进哪单 |
| 显示 | 本人进行中的承接，每行：任务名、截止（剩余天数，逾期标红）、尾款金额（任务约定的报酬，不是结算进度），右上角是需求方名字。列表里全是进行中的承接，行上不挂阶段徽章，不用「制作中」这个叫法【已定】 |
| 数据 | GET /me/claims?status=active；截止取快照
due_at，进行中承接的 delivery_status 恒为
draft，分不出未开始与草稿，不据它分阶段【已定，拆解 1.2 第
1
条；事实，api/claims/schemas.py:28-49、:68-81；api/claims/router.py:292-313】。需求方名称
client_label 只在任务上、承接快照里没有，按
task_id 读 GET /tasks/{task_id}
取，只读显示的几行【事实，api/tasks/schemas.py:144；拆解
D10】 |
| 排序 | 先分组：已逾期 → 今天到期 → 3 天内 →
之后；组内按截止时间升序，同截止按承接时间【提案】。逾期没有状态位，前端按
due_at 与当前时间算【事实】 |
| 设置 | 「显示几项」（2／4）现有字段界面不生效，本次做出来，默认 2×4 使「4
项」生效【已定】；「显示产能」不做、界面隐藏，后端白名单不改【事实，api/workbench/schemas.py:67-73；清单:16】 |
| 空态 | 「今天没有要推进的任务」＋去「我能接的单」 |
| 点击 | 行进任务详情；标题进我的任务页 |
| 第二层 | 有日期的待办按同一分组规则并入、行首标来源（平台任务／我的待办），没日期的不进今日行动；这一步已从 P1 首批后移，今日待办先单独上线【已定，拆解 WB-P1-5】 |
| 现状 → 改动 | 现只按截止排、不分组（WB/logic.ts:182-191）→
加分组、金额、条数设置。工作量：小 |
4.2
我的任务（tasks，改造，原「任务清单」）· P0
| 项 | 内容 |
|---|---|
| 解决什么 | S2：接的单走到哪一步；吴梦赢要的「交付」放这里 |
| 显示 | 每个承接一行，带状态徽章（进行中／已完成）；进行中的行写截止与总报酬，已完成的行写总报酬（接口没有完成时间，首批不写完成日期，拆解
D11）；默认 2×1
只露当前筛选下排第一的那单，右侧放它的任务封面缩略图。按承接状态只分「进行中／已完成」两档；不显示尾款结算中、结算待处理等结算阶段【已定，白晨
10-11「结算展示先不做」】。结算进度仍可在任务详情与个人页看到，那两处现有展示不动【事实，apps/web/src/features/tasks/TaskRewardPanel.tsx、apps/web/src/features/claims/ReceivedTask.tsx】。需求方验收上线后再加「待验收」等阶段（第九节） |
| 阶段判定【已定，以拆解 WB-01 为准】 | 承接
status=active＝进行中，completed＝已完成；承接只有这两种状态【事实，api/claims/states.py:3】。10-10
定的按结算状态细分（尾款结算中、结算待处理）随 10-11 口径撤下 |
| 数据 | GET /me/claims（只用承接状态；接口里的
advance、final
结算字段首页暂不用）【事实，api/claims/schemas.py:68-81】 |
| 筛选 | 进行中／已完成两档，按钮上带各自单数（「进行中 N」「已完成 N」），不另设阶段计数；现有「我创建的」「团团协作」来源没有数据，界面隐藏，后端白名单不改【事实，清单:18】 |
| 空态 | 「还没有承接任务」＋去「我能接的单」 |
| 点击 | 行进任务详情或交付页 |
| 现状 → 改动 | 现显示已承接与预付尾款状态 → 去掉结算状态，改为进行中／已完成两档与筛选。工作量：小 |
4.3
我能接的单（inspiration，改造，原「灵感推荐」）· P0
| 项 | 内容 |
|---|---|
| 解决什么 | S3：事找人——平台按我的认证把能接的单送到眼前 |
| 显示 | 顶部一句「你现在能接 N 单」；两组：现在就能接、差 1 个认证（写明差哪个，附「去学习」） |
| 规则【提案】 | 对每个公开任务算「所需认证 − 我已有认证」：为空、未过期且金额不为空＝现在就能接（拆解 1.1）；只差 1 个＝差 1 个认证；差 2 个及以上不显示。现在就能接按总报酬降序，同报酬按截止近 |
| 数据 | GET /tasks（只列未被承接的任务，每页最多
50，需翻页取全；卡片自带 required_certifications 与
learning_links、total_coins、due_at、is_expired）＋GET /me/certifications【事实，api/tasks/router.py:372-405、api/tasks/schemas.py:201-235；api/courses/router.py:184】 |
| 空态 | 没有能接的：「先拿一个认证就能接单」＋指向学习推荐；完全没有公开任务：「暂时没有新任务」 |
| 点击 | 行进任务详情（承接在详情页办理）；「去学习」打开该认证的学习链接 |
| 现状 → 改动 | 现为公开任务与作品列表、不分人 → 去掉作品页签，改为按认证匹配。工作量：小（前端求差，不改接口） |
4.4
学习推荐（learning，改造，原「学习与能力」）· P0
| 项 | 内容 |
|---|---|
| 解决什么 | S4：缺认证时学哪个最划算；兼顾「认证」的集中掌握 |
| 显示 | 已获认证数／全部认证数；推荐学习 2～3 个：认证名、「学完可多接 N 单，共 X 积分」、学习链接 |
| 规则【提案】 | 对每个我还没有的认证，统计「拿到它后就能接」的公开任务数（该认证是该任务唯一缺的那个）与其总报酬；按可多接单数降序，同数按总报酬。可多接为 0 的认证不推荐 |
| 数据 | GET /certifications（含
learning_links）＋GET /me/certifications＋GET /tasks【事实，api/courses/router.py:148-165、api/courses/models.py:15-22】。没有独立课程实体，学习链接即课程入口；OpenQ
链接只是前端环境变量【事实，apps/web/.env.example:25-26】 |
| 空态 | 全部认证已获得：「认证已齐」；没有任何可解锁的任务：只显示已获认证 |
| 点击 | 认证名进认证页上传截图（上传即登记，无审核）【事实，api/courses/models.py:25-43】；学习链接新开 |
| 现状 → 改动 | 现只显示本人认证记录 → 加推荐计算。与「我能接的单」共用同一份任务与认证数据。工作量：小 |
4.5
作品与积分（profile，改造，原「我的记录」）· P0
| 项 | 内容 |
|---|---|
| 解决什么 | S5：挣了多少、做了什么；吴梦赢要的「积分」「作品」放这里，积分部分按白晨 10-11 口径只显示可用积分。名称回到阳光玻璃稿的「作品与积分」（清单:17、:79） |
| 显示 | 可用积分（余额）；最近 3 件作品（封面、标题）；认证数、承接数一行小字。不显示待到账、本月到账、「N 笔结算待处理」【已定，白晨 10-11】；不显示作品「是否公开」：接口拿不到可见性【已定】。默认 1×1 时卡片里只露可用积分，最近作品点开看（见第八节） |
| 计算 | 可用积分取
balance_coins，balance_status=unavailable
时显示「余额暂不可用」【已定】。待到账、本月到账的计算口径随
10-11「结算展示先不做」撤下，需求方验收上线后再定 |
| 数据 | GET /me/account（只用余额；账本、结算首页暂不用）【事实，api/settlements/router.py:67-95、api/settlements/schemas.py:47-85】；作品没有作者字段、也没有「我的作品」接口，只能经
/me/claims 已完成的承接逐条取
GET /me/claims/{id}/delivery 的
work【事实，api/works/models.py:20-28、api/deliveries/router.py:64-81】 |
| 作品取法【已定】 | 首批前端只取最近 3 个已完成承接的交付详情（3 次请求）；作品多了再补
/me/works 接口（后端中档） |
| 空态 | 无作品：「完成第一单后，作品会出现在这里」 |
| 点击 | 积分区进个人页；作品进任务详情（系统没有作品详情页【已定，拆解 1.2
第 6
条】；未公开的作品作者本人可看【事实，api/works/service.py:249】） |
| 现状 → 改动 | 现显示余额、认证数、承接数 → 加最近作品，改名，去掉「AI 员工可用贝壳」固定文案。工作量：小 |
4.6
今日待办（schedule，改造，原「日程」）· P1 · C 端抢跑
| 项 | 内容 |
|---|---|
| 解决什么 | S6：平台之外的事也记在这里，和平台任务一起排（白晨分工会:57；吴梦赢下午会:259） |
| 显示 | 今天的待办与未定日期的待办；输入框快速新增；勾选完成 |
| 规则【提案】 | 一件事只有一条记录，状态原地更新；有日期的待办以后进今日行动排序（4.1，已后移），不重复存储。字段是
C 端个人工作台待办（G03）的子集：以后迁移时 done_at
对应「完成」，没有「在等」「放弃」两种状态，日期按北京时间、不分用户时区（拆解附录
B） |
| 数据 | 后端目前没有任何待办、日程表或接口【事实，后端清点】；要新建事项域：表（标题、日期可选、完成状态、创建时间）、增删改与勾选接口、三层测试、验收场景（清单:13 已给同样设计） |
| 现状 → 改动 | 现为写死的 2 条示例 → 改为本人录入的待办；沿用 schedule
类型与「今天／本周」设置（清单:13）。工作量：中 |
4.7 不在本次范围
| 模块 | 处理 | 理由 |
|---|---|---|
| 消息提醒 | 保持现状，移出默认布局 | 白晨 10-10 定：消息在模块之外，本次不做 |
| 项目中心 | 保持现状，移出默认布局 | 不在吴梦赢 10-08 列的范围；09-23 定的独立项目对象（清单:14）后续再议 |
| 行业资讯 | 保持现状（示例），移出默认布局 | 吴梦赢「不能做拉倒，不能做就先放一放」（下午会:261）；内容源未定 |
| 团团 | 保持占位 | 交互重设计未定稿；白晨定不动入口 |
五、产品原则【提案】
- 只改模块，不改全局：不动顶栏消息、团团入口与其他页面。
- 复用现有模块类型：6
个模块全部是现有类型改造；新增类型要改前后端十几个文件并重生接口契约，且设置白名单拒收未知字段【事实，
api/workbench/schemas.py:11-22、:67-73】。 - 规则排序，不调模型：排序与推荐都由代码算，结果可解释、可复现。
- 首页只呈现和跳转：承接、交付、认证都回到原页面办理。
- 单一状态源：交付状态、待办状态各只存一处，首页只读。
六、为什么这么排
| 结项目标 ③ 要素 | 落在哪个模块 | 依据 |
|---|---|---|
| 任务 | 今日行动、我的任务 | 吴梦赢「任务的重点需要回到首页上」（下午会:233） |
| 认证 | 学习推荐 | 「认证交付积分作品」（下午会:253、:255） |
| 交付 | 我的任务（进行中／已完成） | 同上；交付状态挂在承接上，不另起卡片（单一状态源）【提案】；结算进度待需求方验收上线后再上首页 |
| 积分、作品 | 作品与积分（可用积分＋最近作品） | 同上；名称沿用阳光玻璃稿；积分只显示可用积分（白晨 10-11） |
| 事找人 | 我能接的单、学习推荐 | 结项目标原文（待办:12）；09-23 清单已把「我能接的单」列为工作量小、建议先做（清单:12、:33） |
| 今日待办（抢跑） | 今日待办、今日行动 | 白晨分工会:57；吴梦赢下午会:259 |
- 数据现成：P0 五个模块用的承接、账户余额、认证、任务接口都已存在，只有作品需要前端串联。
- 工期：开发窗口 10/12～10/16，白晨＋AI 代理（待办:3、:43；拆解文首），P0 必须以前端为主；今日待办要建后端域，放 P1。
七、开发顺序与工作量【已定，以拆解为准】
初稿这里是逐日排期，已被拆解取代，不再单列。要点（10-11 按「结算展示先不做」重算）：
- P0 共 17 项、9.25 人日，最大的一块是改写受影响的存量端到端测试（约 18～20 个场景，2 人日）；关键路径 3.5 人日。
- 按理想并行最早 10/15 中午收口，现实预期 10/15 下班前收口；10/16 上午给吴梦赢过，下午按反馈修，约有半天缓冲。
- 代码开工等 10/12 与吴梦赢确认后再开始；开工每晚半天，P0 收口跟着晚半天（拆解第三节「开工条件」）。
- P1 今日待办「尽量挤进」：挤进子集 5 项、3 人日，在独立分支上与 P0 并行；P0 按理想收口时可在 10/16 上午收口，P0 按现实收口时余下 1 人日正好占满 10/16、没有缓冲，再晚就下周一继续。
八、待确认
仍要和吴梦赢确认的两项（10/12 确认会，与拆解第四节「仍待」第 1、2 条一致）：
- 交付不单独成卡：交付并入「我的任务」，按承接状态显示进行中／已完成。推荐接受。
- 任务专属认证算不算「差 1 个认证」：推荐算，学习推荐里排在官方认证之后。吴梦赢回复前按推荐做，改口径只动一处。
另有一项待白晨在确认会上定（拆解「仍待」第 5 条）：作品与积分默认 1×1，首页只露可用积分，这与 10-11 定的积分展示范围一致；剩下的问题是最近作品要不要在首页一眼可见。推荐接受 1×1、最近作品点开看；另一选项是默认改 1×2 并重排默认布局，代价见拆解。
以下按本文理解执行，不再单列待确认：
- 最近作品保留：白晨 10-11 只说积分部分只显示可用积分，没说去掉作品；作品来自已生成的作品记录，不依赖结算，所以保留。
- 今日行动每行的尾款金额保留：它是任务约定的报酬，承接时就定了，不随结算进度变，不属于「待到账」这类结算展示。
- 「卡片能够被添加到首页」（吴梦赢，下午会:259）：理解为缺这几张卡片本身，首页编辑态已能从目录添加模块（
WB/WorkbenchToolbar.tsx:121-122）。若他指的是从任务页、作品页「加到首页」，要另加入口，不在 10/16 范围。 - **「人找事 → 事找人」**只能写作出自结项目标 v1.0；伟华 0910、0922 所说的「每天第一眼打开的聚合页」谈的是 C 端个人工作台，引用时要注明。
九、未来口径：需求方验收（白晨 10-11 定）
白晨 2026-10-11 在与 Claude
的会话中定了验收与结算的未来逻辑，知识库记录见
knowledge/wiki/00-口径与治理/00-当前权威口径.md 页首 10-11
块。
| 现阶段（代码现状） | 未来 | |
|---|---|---|
| 验收 | 接单即建交付草稿；接单者提交交付，系统当场自动验收，承接转为已完成【事实，api/deliveries/service.py:36-42、api/workflows/submit.py:30-71】 |
由需求方（发单人）验收，不再由系统自动验收 |
| 尾款 | 自动验收时同一事务里发起尾款结算【事实，同上】 | 需求方验收通过后尾款自动到账 |
| 首页 | 结算展示先不做：作品与积分只显示可用积分，我的任务只分进行中／已完成 | 我的任务加「待验收」等阶段；作品与积分再考虑待到账等结算展示，口径届时另定 |
需求方验收是一套新逻辑（发单人侧的验收入口、承接多一个「待验收」状态、验收通过才触发尾款），不在 10/16 范围，什么时候做、驳回怎么处理都还没定。