# 10 月目标、验收标准与模块拆分（2026-09-25）

> **来源与性质**：2026-09-25 白晨与维护者会话逐轮对齐的结果，白晨口头确认，无录音，按工作层（★★）记。**2026-09-26 白晨在会话里转述了吴梦赢对第五节八个问题的判断**（七个有答复，插件语言她也不知道），以及她对发单时要附哪些信息的判断；这些是吴梦赢的判断，白晨未逐条表态，同样按工作层记。同日补了 2.4 任务拆解（约 55 件），白晨「基本认可」；又按公司月度事务表格式归并成 2.5 的 17 条事务并估了工时。本文是给**吴梦赢**与**林炜**沟通用的底稿：目标与验收标准白晨已认可，模块拆分白晨已看过；**还没按人力做减法**，也还没排时间。
>
> **怎么读**：吴梦赢先看第一、二、五节；林炜先看第三、四节。每条标**已定**（白晨 0925 确认）、**吴梦赢判断**（白晨 0926 转述，白晨未逐条表态）或**提案**（维护者提出，白晨未逐条确认）；第五节是吴梦赢对八个问题的判断、判断对现状的影响，以及由此带出、还要定的事。
>
> **与 0922 执行清单的关系**：[《下一阶段要做什么（0922 夜盘，按执行方分工）》](2026-09-22-10月16日前待办-外部与内部分工.md)是按「谁做」切的待办；本文按「10 月要达成什么」切，是当前基线。0922 清单里已完成的几项（工作台模块清单 AIC-1902、交易对标调研 AIC-1906、助手能力清单与陪跑原型）是本文的输入。

## 〇、团队与节点

- **10 月人力（已定）**：白晨、林炜、陈高武、卓清香，四人是创业平台与 AI 工作台两边的总人力。
- **两个节点（已定）**：
  - **10/16 是每月例行的月度结项**（白晨 0925 说明；此前 [03 未决问题](../../../knowledge/wiki/00-口径与治理/03-未决问题.md) 第 28 项「10/16 出处待白晨说明」由此回答）。这一期以技术选型、调研、方案设计为主，但**必须交付一条能跑的基本流程**。
  - **10 月底**才出完整流程，把整条链串通。
- **本月两条线（已定）**：创业平台做 **AI 助手**（按 0923 陪跑原型的业务逻辑串起来）；AI 工作台搭**底座**（面向 C 端，与公司内另一业务方的工作台共用一份底座）。

## 一、目标与验收标准

### 1.1 创业平台：教师伙伴场景

**演示场景（已定）**：用 AI 教师伙伴。这个场景有两层，**两层都要做**：

1. **运营层**：用助手跑通教师伙伴小红书账号的运营。业务逻辑以 [陪跑流程原型](../../prototypes/2026-09-23-AI助手陪跑流程-教师伙伴运营/README.md) 为准。
2. **交易层**：教师伙伴项目在创业平台上发单，推广时让老师们过来接单、提交成果，平台给他们发钱。

**交易层放到 10 月底（已定）**：白晨判断交易层 10/16 前未必能走通。

**先用教师伙伴试跑（吴梦赢判断，0926）**：跑通之后，拿到漫剧的单也可以跑；只要有单，就能满足伟华的要求（伟华是否认可见 5.7）。

| 节点 | 验收标准 |
|---|---|
| **10/16** | **只验运营层**，真实接模型、不走固定剧本。走完这条链：①与团团对话说需求，问完四个预设问题（做什么、做到什么程度、预算、期限）；②生成项目摘要，用户点「开工」；③画布出现第一阶段任务（至少流程视图）；④至少一个任务派给**用户本人**执行；⑤用户回报完成后，状态回到画布。**验收方式**：由一个没参与开发的人自己走完这五步。（④选「派给用户本人」是为了不涉及付钱；吴梦赢 0926 判断的免费任务规则「没有 Agent 能执行就指派给用户」与它一致，见 5.1） |
| **10 月底** | ①**运营层完整**：原型的数据回报（上传截图）、团团自动改计划、风险预警与换人、阶段复盘（继续或结项）、结项报告都真实可用；②**交易层**（按吴梦赢 0926 的判断细化）：普通用户发单，附费用、接单期限、发单模式（5.4）→ 发单时冻结费用 → 老师经推广链接进来、手机号验证码登录、设头像和名称（5.3）、接单 → 提交成果 → **验收通过后发尾款**（5.2）；接单期限内没人接单，退款、单子取消。**资金怎么冻结、由谁托管还没定**：吴梦赢判断的情景与 0922 夜盘「不接支付宝和微信支付」的技术边界冲突，见 5.5；③**两层接起来**：团团派出的付费任务进入交易层，由老师接单完成；④**用户价值验证**（吴梦赢 0926 判断要进 10 月目标，5.6）：请没参与开发的真实用户走一遍，记录断点、看不懂的地方和流失点；某个环节有卡点时改用 planB 走通，并在记录里写明哪一环用了 planB。**例子**：教师伙伴账号在平台上真实跑完「起号期」一个阶段——全部任务经平台派发，至少一次改计划、一次复盘，结算记录与实际付款一致 |

### 1.2 AI 工作台：底座

| 节点 | 验收标准 |
|---|---|
| **10/16** | **底座能「给别人用」**。新仓库里有：插件宿主（本地子进程＋远程调试两种运行方式）、协议 v0 文档（插件清单、数据接口 Schema、事件、展示模块规范）、插件开发工具包与项目模板；两个样例插件（**接什么可以换**，已定）；一个最小演示宿主页，能装插件、渲染插件的默认模块，点击后请求经宿主到插件、再到外部接口取回数据；上架时有基本的清单格式校验。**验收方式**：共建方的开发只看文档、不找我们，自己写出一个插件，装进宿主跑通 |
| **10 月底** | **给副总看的完整样子**：创业平台工作台作为第一个顶层应用，至少 2 个模块改为经底座插件取数据；插件市场页可浏览、安装；上架审核走一遍完整流程；代码档沙箱可用；顶层应用演示一次「新建一个组件」——基于某个插件的数据接口生成一套皮肤，并上架到市场（这一条属顶层应用，代码在创业平台仓库） |

## 二、模块拆分（11 个）

测试与验收场景不单列，算作每个模块完成的一部分（本仓库按 [工程标准](../../standards/2026-09-13-仓库工程标准-可维护性与测试体系.md) 要求三层测试加业务验收场景）。

### 2.1 创业平台（本仓库）

| 模块 | 包含 | 10/16 做到 | 10 月底做到 |
|---|---|---|---|
| **P1 助手技术底座** | 技术选型、技术方案、接模型与流式对话、主动唤醒 | 选型与方案定稿（林炜判断）；模型接通、能流式对话 | 主动唤醒：到时间或有事件发生时触发团团做判断 |
| **P2 需求确认与立项** | 需求对话、项目对象（目标、验收标准、预算、期限、状态）、项目摘要、开工确认 | 全部 | — |
| **P3 项目画布与任务管理** | 任务拆解、画布、团团侧栏、确认与改动记录、派活、状态回流；没有 Agent 能执行的任务派给用户，用户三选一：自己执行、指派给人、创建 Agent（吴梦赢 0926 判断，5.1） | 流程视图；派活给用户本人；回报后状态回画布 | 补时间轴、看板视图；派活给接单者。「创建 Agent、验证后交付平台换激励」这一段 10 月做到哪一步**待定** |
| **P4 运营推进** | 数据回报、自动改计划、风险预警与换人、阶段复盘、结项报告 | — | 全部；用真实账号跑完起号期 |
| **P5 交易** | 普通用户发单（费用、接单期限、三种发单模式）、费用冻结与到期退款、老师进入与手机号登录、接单到验收后放款全流程、金额与对账、与运营层接通（按吴梦赢 0926 判断细化，5.2～5.5） | — | 全部；前提见 2.3 |

代码现状（2026-09-25 核对，0926 补）：后端没有接任何大模型；只有管理员能发任务（`apps/api/app/tasks/router.py:182` 的 `POST /admin/tasks`），任务上的需求方只是一个文本字段（`apps/api/app/tasks/models.py:26`）；结算只有积分、没有金额字段（`apps/api/app/settlements/`）。和吴梦赢 0926 判断的交易规则相比，现状还差这几处：
- **只有「自动接受」一种发单模式**：一个任务只能被一人承接（`apps/api/app/claims/models.py:19` 的唯一约束），确认即成交，同时发预付（`apps/api/app/workflows/claim.py:29-48`）；
- **截止时间只有一个**：`due_at` 过了就不能再承接（`apps/api/app/claims/service.py:341`），任务页却把它显示成「交付时间」（`apps/web/src/features/tasks/TaskDetailPage.tsx:230`），也就是一个字段同时管着接单期限和交付期限；
- **提交即验收**：提交的同一个事务里自动验收并发尾款（`apps/api/app/workflows/submit.py:53`）；
- **登录只接公司统一登录（UC）**。

P2 的项目对象与工作台模块清单里「项目中心先独立做」（[模块清单](../../AI工作台/规格与计划/2026-09-23-创业平台工作台模块清单.md)置顶总表）是同一个对象。

### 2.2 AI 工作台底座（新仓库）

| 模块 | 包含 | 10/16 做到 | 10 月底做到 |
|---|---|---|---|
| **W1 协议与规范** | 插件清单、数据接口、事件、展示模块规范 | v0 | 按接入反馈修订 |
| **W2 插件宿主** | 子进程运行、远程调试、凭据、对外接口、事件推送 | 除事件推送外全部 | 事件推送 |
| **W3 开发套件与样例插件** | 开发工具包、项目模板、文档、2 个样例插件（可换） | 全部；共建方独立写出一个插件 | — |
| **W4 前端渲染** | 声明式渲染器、演示宿主页、代码档沙箱 | 声明式渲染器＋演示页 | 代码档沙箱 |
| **W5 上架与市场** | 格式校验、签名、审核后台、市场页 | 格式校验 | 签名、审核、市场页（给副总看） |
| **W6 创业平台工作台接入** | 至少 2 个模块经插件取数据、AI 生成皮肤并上架 | — | 全部（代码在创业平台仓库） |

### 2.3 卡住模块的前提（不属于任何模块）

| 前提 | 卡住 |
|---|---|
| 公司 AI Gateway（模型网关）密钥；它 30 天轮换 | P1 及之后所有接模型的事 |
| 正式环境上线（0922 时卡在外部依赖卡 AIC-1755，现状未核实） | P4 的真实账号运营、P5 |
| 新仓库的共建约定：权限、代码评审；测试标准是否沿用本仓库三层合计 300%、变异 80% | W1～W5 的工作量 |
| 资金冻结与放款的合规落地方式：吴梦赢 0926 判断「先不管公司外包流程」，改为平台冻结、验收后放款；要定钱放在哪里托管，并经法务、财务确认（5.5）。是否还要报伟华批准，她没有提到 | P5 的冻结、退款、放款 |
| 教师伙伴登录组件的接入：组件归谁、找谁对接，背后是不是同一套 UC 账号（5.3） | P5 的老师登录 |
| 真实账号运营的业务配合：谁发帖、谁回报数据 | P4 |

### 2.4 任务拆解（初步，2026-09-26）

**状态**：维护者按上面 11 个模块拆的初稿，白晨 0926「基本认可」；**还没排人、没做减法、没排时间**。粒度到「做完能看得见的一件事」，约 55 件，不到开发任务那一级。

**怎么读**：
- 每件事前面标节点：〔10/16〕、〔10 月底〕。
- 标〔待定〕的，依赖还没拍板的事。
- 标〔吴梦赢判断〕的，来自第五节吴梦赢的判断，白晨未逐条表态。
- 测试与业务验收场景算在每件事里面，不单列（见本节开头）。

#### 创业平台（本仓库）

**P1 助手技术底座**
1. 〔10/16〕助手运行框架选型，出技术方案。由林炜判断，候选名单与 0921 调研见第三节。
2. 〔10/16〕接通公司模型网关（AI Gateway）。网关密钥 30 天轮换，要有更换密钥的办法。
3. 〔10/16〕流式对话：团团栏 ↔ 后端 SSE（仓库已定用 FastAPI 内置 SSE）。
4. 〔10/16 起步〕把平台功能注册成助手可调用的工具，如建项目、建任务、派活。花钱、对外发布、改目标或验收标准、换人、结项五类事必须弹确认。
5. 〔10 月底〕主动唤醒：到时间或有事件发生时（逾期、快到期等），触发团团做判断。

**P2 需求确认与立项**（10/16 全部完成）
1. 项目对象（数据与接口）：目标、验收标准、预算、期限、状态、待补项。
2. 需求对话：必问四项（做什么、做到什么程度、预算、期限）加自由追问，「团团已了解」逐项亮起，问到够开工就停。
3. 项目摘要：没问到的项标「待补」。
4. 开工确认：用户点「开工」后，项目进入实施阶段，交给 P3 排任务。

**P3 项目画布与任务管理**
1. 〔10/16〕任务对象：状态、执行方（用户本人、他人、Agent、接单者）、所属阶段、先后关系。
2. 〔10/16〕开工时，团团按项目摘要排出第一阶段任务。
3. 〔10/16〕流程视图画布。
4. 〔10/16〕派活给用户本人，用户回报完成（口述或截图）后，状态回到画布。
5. 〔10 月底〕团团栏的确认卡，以及改动记录抽屉：每次改动都有记录，团团新增、还没开始的任务可以撤回。
6. 〔10 月底〕时间轴、看板两个视图，与流程视图共用同一份数据。
7. 〔10 月底〕付费任务派给接单者，也就是转成交易层的单，接 P5。
8. 〔10 月底〕〔吴梦赢判断〕〔待定〕免费任务的三种去向：用户自己执行、指派给人、创建 Agent。「创建 Agent、验证后交付平台换激励」做到哪一步待定（5.1）。

**P4 运营推进**（10 月底）
1. 数据回报：上传截图或直接报数，团团识别出关键数字。
2. 自动改计划：看到信号就增删调任务，要花钱的弹确认。
3. 风险预警与换人：接单者逾期或不回消息时预警；换人时退回原预付，由新人接手。退款依赖 P5。
4. 阶段复盘：列出判断依据，给出继续、调整打法、暂停、结项四个选项。
5. 结项判断与结项报告：各项指标、阶段回顾、团团做了什么，打法存为经验。
6. 用真实账号跑完起号期。前提是业务侧定下谁发帖、谁回报数据（2.3）。

**P5 交易**（10 月底；大部分标〔吴梦赢判断〕，细节〔待定〕见 5.2～5.5）
1. 普通用户发单：发单页（需求说明、费用、接单期限、发单模式），以及发单方身份。
2. 费用冻结与到期退款：冻结后要么退款、要么放款；接单期限到了没人接，自动退款并取消。**钱放在哪里托管，要法务确认后才能动真钱**（5.5）。
3. 三种发单模式：自动接受（现有实现就是这种）、竞聘（有申请列表，发单方挑一个）、需求方同意（逐个审批）。
4. 老师登录：接教师伙伴登录组件，手机号验证码登录，首次登录设头像和名称；推广链接直达对应任务。
5. 验收后放款：把「提交即验收」改为由发单方验收，通过就发尾款，不通过就打回。
6. 金额结算记录与对账：结算加上金额字段，与实际付款对得上。
7. 与运营层接通：团团派出的付费任务自动变成交易层的单，完成后状态回到画布。

**跨模块：用户价值验证**（〔10 月底〕〔吴梦赢判断〕，5.6）
1. 找没参与开发的发单方与老师来走一遍，记录断点、看不懂的地方、流失点。
2. 列出 planB 清单：哪个环节可能卡住，卡住了用什么替代。

#### AI 工作台底座（新仓库）

**W1 协议与规范**
1. 〔10/16〕插件清单格式 v0：名称、版本、权限、数据接口、展示模块。
2. 〔10/16〕数据接口规范：用 Schema 说明字段含义，覆盖查询、增删改、事件。
3. 〔10/16〕展示模块规范：尺寸，以及能用的交互（点击、流式输出、动画等）。
4. 〔10 月底〕按共建方接入的反馈修订。

**W2 插件宿主**
1. 〔10/16〕安装插件：按清单安装并校验。
2. 〔10/16〕子进程运行插件，请求链路走通：前台动作 → 宿主 → 插件 → 外部接口 → 返回。
3. 〔10/16〕远程调试：开发者本地的插件能连到宿主上跑。
4. 〔10/16〕凭据：按用户加密保存，请求时交给插件，由宿主编排 OAuth 授权（这套做法是提案，见 4.1）。
5. 〔10/16〕对外接口，给顶层应用调用。
6. 〔10 月底〕事件推送。

**W3 开发套件与样例插件**（10/16 全部完成）
1. 开发工具包。〔待定〕插件用什么语言还没定（5.8），这件卡住整个 W3。
2. 项目模板与脚手架。
3. 开发文档：从零写一个插件，到装进宿主跑起来。
4. 两个样例插件，接什么可以换。
5. 验收：共建方只看文档，自己写出一个插件。

**W4 前端渲染**
1. 〔10/16〕声明式渲染器：插件给数据和组件描述，由工作台用自己的组件渲染。
2. 〔10/16〕演示宿主页：能装插件、渲染默认模块、点击后取回数据。
3. 〔10 月底〕代码档沙箱：审核过的插件提交的 HTML，在隔离框里运行。

**W5 上架与市场**
1. 〔10/16〕清单格式校验。
2. 〔10 月底〕签名。
3. 〔10 月底〕审核后台，完整走一遍上架流程。
4. 〔10 月底〕市场页：可浏览、可安装（给副总看）。

**W6 创业平台工作台接入**（10 月底，代码在本仓库）
1. 至少 2 个模块改为经底座插件取数据。
2. 演示「新建一个组件」：基于某个插件的数据接口生成一套皮肤，并上架到市场。

#### 拆完看到的三件事（维护者判断）

1. **10/16 的关键路径是 P1 选型 → 模型接通 → P2 → P3。** 模型网关密钥（2.3 第一行）不到位，整条链都动不了，应该最先去要。
2. **W3 被「插件用什么语言」卡住，而 10/16 的验收就是共建方自己写出插件。** 要在开工第一周问清共建方的技术栈，不能等到 10 月底。
3. **P5 的 7 件事几乎都挂着待定项**（资金托管、登录组件、发单细节）。把这些决定本身当成最先做的任务，排在 10 月上半月，否则 10 月底来不及。

### 2.5 月度事务表（2026-09-26）

把 2.4 按「创业平台」「AI 工作台」两个大模块归并成 13 条核心事务（创业平台 9 条、工作台 4 条），照公司月度事务表的列（模块、核心事务、预计完成时间、细项比例、验收标准、季度、优先级、月度、开发工时）填好，存为 CSV（UTF-8 带 BOM，Excel 双击可开）[2026-09-26-10月事务拆解.csv](2026-09-26-10月事务拆解.csv)。**表是这份数据的唯一正文，本节只记口径与结论。**

- **口径（提案，白晨未确认）**：优先级 7＝10/16 必交，6＝10 月底必交；完成时间按 10/16、10/31 两个节点填，插件开发语言在事务里注明 10/9 前定；细项比例口径不明，留空；工时为粗估（一人带 AI 编码一天算一人日，含三层测试，误差可达 ±50%），「创建 Agent」等待定项未计。
- **结论**：合计约 141 人日（创业平台 84、工作台 57），其中 10/16 前约 70.5。按国庆 10/1～10/7 放假、10/10 补班估（未核实），9/28～10/31 四人约 84 人日，10/16 前约 44。按 2.4 细项看，10 月底里可以减的（时间轴与看板视图、竞聘与需求方同意两种发单模式、代码档沙箱、AI 生成组件等）合计约 28，全减仍超；**10/16 的缺口不在这些可减项里，减法要从 10/16 的范围做起**。

## 三、创业平台助手：给林炜的材料

**原则（已定）**：技术上怎么做由林炜判断；本节只整理已有材料与需求，**不带维护者的倾向**。

- **白晨的初步设想**：平台内的助手自研，基于某个开源框架（候选如 Pydantic AI、LangGraph），要做选型。另一类选项是基于 AgentHub 的 NDClaw，或 cc、Hermes 改造；白晨认为它们有缺点——运行时成本，以及用户初次进入时等待太久，不符合初衷。
- **9/21 的调研**：白晨 2026-09-21 做过一轮「AI 助手运行底座重评」，12 份报告在已删分支上，**用 `git show 6c911d40:<路径>` 取回**（目录 `docs/reports/2026-09-21-AI助手运行底座重评/`，主文件 `汇报提纲-v1.md`，候选库对照在 `附录B-进程内薄harness候选调研.md`，ndclaw 成本与首响在 `附录A-ndclaw运行时成本与延迟考古.md`）。当时比较了四类运行位置与七个候选库，**LangGraph 不在那次的打分表里**。
- **白晨给林炜的两条建议，请林炜判断是否采用**（出自 0921 调研，当时写作「已定」，0925 白晨改为建议）：①助手的工具就是平台函数（Pydantic 入参、说明、错误响应齐全，直接注册给对话循环）；②运行助手的服务本身不持有业务数据库凭据，要动数据时回到平台服务执行。
- **陪跑原型带来的新需求**（9/21 调研时还没有）：团团不只一问一答，它会看信号自己改计划、预警风险、判断什么时候结项，一个项目可跑几十天（原型里 62 天）；五类事必须用户确认（花钱、对外发布、改目标或验收标准、换人、结项），团团自己能做的只有增删调任务、指派官方 agent、催办提醒，每次都进改动记录。规则全文见 [原型 README「本轮定下的产品规则」](../../prototypes/2026-09-23-AI助手陪跑流程-教师伙伴运营/README.md)。
- **产品层能力清单**：[AI 创业平台助手能力清单](../specs/2026-09-23-AI创业平台助手能力清单-design.md)，22 条、P0 11 条；0923 夜谈基本认可原型，对外叫法口头定为「创业教练」（[0923 夜谈页](../../../knowledge/wiki/60-会议对谈/2026-09-23-创业教练定位与创业平台工作台拆分.md)）。

## 四、AI 工作台底座：分层与已定原则

### 4.1 分层（白晨 0925 口述，维护者合并整理）

**底座**（新仓库，与另一业务方共建，**已定**）：

| 层 | 做什么 |
|---|---|
| ① 插件宿主 | 参考 Dify 的 plugin daemon：第三方上架插件就是把插件安装进宿主；前台触发一个动作（如查看数据）时，请求打到宿主里对应的插件，宿主起子进程或其他形式执行插件、拿到数据再返回。底座是轻的 |
| ② 凭据 | 插件怎么对接飞书、公司事务池，由插件自己决定。凭据的保管方式为**提案**：宿主按用户加密保存、每次请求时交给插件，插件不存；OAuth 授权由宿主编排（照 Dify 做法，改为按用户） |
| ③ 数据接口协议 | **不做统一数据模型**：飞书就是飞书的接口。只规定格式——用 Schema 说明每个字段的含义，帮助上游封装与理解，不规定内容。包括查、增删改与事件推送 |
| ④ 展示模块规范 | 类似 iOS 界定小组件支持哪些交互，规定模块的尺寸、交互、能力（点击、流式输出、动画等），保证插件装上后稳定 |
| ⑤ 上架与市场 | 插件＝数据接口＋可视化模块。用户在市场里看到的是可视化模块；底层数据接口让上层 agent 能组装，这是 AI 工作台与传统工作台的区别——用户有自定义模块的权利 |

**顶层应用**（不在底座仓库里，**已定**）：
- 顶层有一个 Agent Runtime，响应「给我找一个组件」「添加一个组件」「新建一个组件」，并按用户记忆实时推荐。
- AI 生成的是**展示层**，数据层复用；生成的模块存在哪、用什么风格，由顶层应用决定。顶层应用觉得某套皮肤好，就把它上架。

### 4.2 本次已定的原则

1. **协议是私有协议，不用 MCP**，为的是别人上架时能做审核、验证。（已定）
2. **展示层声明式与代码档都做**：声明式是插件给数据＋一段组件描述、由工作台用自己的组件渲染；代码档是审核过的插件提交 HTML 页面、在隔离框里运行。（已定；维护者原建议 10 月只做声明式，白晨未采纳）代码档沙箱放 10 月底、10/16 先做声明式。（提案，白晨回复「基本认可」）
3. **10 月隔离做第一档**：每个插件一个进程、不设沙箱，**只接我们自己和共建方的插件**；对第三方开放上架前升到第二档（每插件一个容器，只许访问声明过的域名）；第三档（每用户每插件一个沙箱）先不做。（已定）
4. **底座仓库不写顶层 Agent Runtime 的代码**。（已定）

### 4.3 两份调研（2026-09-25）

- [插件宿主调研：Dify plugin daemon](../../AI工作台/报告/2026-09-25-插件宿主调研-Dify-plugin-daemon.md)：请求链路、子进程运行、清单与 Schema 写法、签名上架、凭据与隔离；末尾「照搬／改造／不要」三栏。
- [工作台模块运行时与交互规范调研](../../AI工作台/报告/2026-09-25-工作台模块运行时与交互规范调研.md)：WidgetKit／Glance／飞书卡片／Adaptive Cards（声明式）对照 MCP Apps／Apps SDK／Figma（代码沙箱），交互能力清单、尺寸体系、AI 生成皮肤的两条路，末尾 14 章规范骨架。
- 前序材料：[插件定义与工作台交互（0912 附件一，插件十项要素、十二种交互）](../../AI工作台/报告/2026-09-12-个人AI工作台两条路径能力拆解-附件-插件定义与工作台交互.md)、[苹果小组件开发者规范演进（0913）](../../AI工作台/报告/2026-09-13-苹果小组件开发者规范演进与AI工作台借鉴.md)。

## 五、八个问题：吴梦赢的判断（2026-09-26）

白晨 0926 在会话里转述了吴梦赢对这八个问题的判断：5.1～5.7 有答复，5.8 她也不知道、仍待定。**这些是吴梦赢的判断，白晨未逐条表态，不等于已定。**每条写三件事：**答复**（吴梦赢的判断，按白晨转述整理）、**影响**（和现状或既有结论哪里对不上）、**还要定**（答复带出的新问题，未定）。0925 版的背景与冲突分析见 `git show 6d2529ff:docs/superpowers/plans/2026-09-25-10月目标与模块拆分.md` 第五节。

### 5.1 免费任务谁执行

- **答复**：创业助手本身不直接执行任务。有新任务、但没有 Agent 可以执行时，指派给用户。用户有三种选择：自己直接执行、指派给人执行、创建一个 Agent 执行。选第三种的，Agent 验证有效之后，可以交付给平台，从而获得一定的激励。
- **影响**：
  - 平台不提供「官方 agent」兜底。这与 0923 夜谈「我们不提供能力」一致（`../../../knowledge/sources/会议对谈/2026-09-23-会议转写-创业教练定位与创业平台工作台拆分-陈洁等四人晚间录音.md:44`），[03 未决问题](../../../knowledge/wiki/00-口径与治理/03-未决问题.md) 第 29 项有了她的答复，未关闭。
  - [陪跑原型](../../prototypes/2026-09-23-AI助手陪跑流程-教师伙伴运营/README.md)里团团把免费任务「直接交给官方 agent」、团团有权「指派官方 agent」，以及[能力清单](../specs/2026-09-23-AI创业平台助手能力清单-design.md)第 1 节「平台留官方能力兜底」，都和这条不一致。两份文件本轮**没改**。
  - 10/16 验收的「派给用户本人」就在这条规则里，不用改。
- **还要定**：
  1. 「有 Agent 可以执行」的 Agent 从哪来：外部接入的 AI 员工、用户创建后交付给平台的 Agent，还是两者都算。
  2. 「指派给人执行」是指派给用户自己找的人（站外），还是在平台上发单给接单者。
  3. 在哪里创建 Agent，「验证有效」由谁、按什么标准来验。
  4. 激励是什么（积分、贝壳还是分成），以及这一段 10 月做不做。

### 5.2 尾款什么时候发

- **答复**：验收通过之后发。
- **影响**：要改 9/21 的开发依据和已上线的流程——现在提交的同一个事务里就自动验收并发尾款（[制作与交付设计](../specs/2026-09-16-制作与交付全流程-design.md) 3.3 节，`apps/api/app/workflows/submit.py:53`）。改完后，助手的「交付核对」就能挡住付款了，03 第 18 项有了她的答复，未关闭。
- **还要定**：
  1. 谁来验收：发单方本人，还是可以先交给团团核对。
  2. 验收不通过怎么办：打回修改几次、能不能取消、钱怎么处理。
  3. 发单方一直不验收怎么办。三家对标平台都设了超时自动验收：猪八戒网 7 天，闲鱼 10 天（[交易机制对标调研](../../reports/2026-09-24-交易机制对标调研-猪八戒淘宝闲鱼/交易机制对标调研.md)一页结论第 1 条）。
  4. 预付款是否仍在接单时发（现在是）。

### 5.3 老师怎么登录

- **答复**：直接复用教师伙伴的登录组件。可以用手机号获取验证码登录，登录后设置头像和名称。
- **影响**：
  - 仓库 `AGENTS.md` 的「鉴权」行现在写的是「不自建登录，跳公司统一 UC」，并规定改栈要先改那一节。实施前要先改它，本轮**没改**。
  - 现在的姓名从 UC 用户资料里取、头像用 UC 的头像地址（`AGENTS.md`「鉴权」行）。改成用户自己设置后，平台要自己存名称和头像（推断：头像按现有做法存进 CS 内容服务）。
- **还要定**：
  1. 这个组件归谁维护、找谁对接。
  2. 它背后是不是同一套 UC（`cn.ndhy.com`）账号。是，老师和现有用户就是同一种身份；不是，平台上就有两套账号，要定怎么对应。
  3. 已经有 UC 账号的用户，是否也可以用手机号登录。

### 5.4 发单

- **答复**：开放普通用户发单。发单时，除了需求说明，还要附上：
  - **费用**；
  - **接单期限**：这个时间内没人接单，钱退给发单的用户，单子取消；
  - **发单模式**：有人接单自动接受、需要竞聘、需要需求方同意，三选一。
- **影响**：现状只有管理员能发单、只有「自动接受」一种模式、截止时间只有一个 `due_at`（第二节「代码现状」）。要新做的有：发单页面与权限；发单方身份（现在需求方只是一个文本字段）；接单期限与到期退款；竞聘和需求方同意两种模式要有申请列表和选人。
- **还要定**：
  1. 接单期限和交付期限是否分开（**维护者建议分开**：现在的 `due_at` 同时管着两件事）。
  2. 竞聘和需求方同意的区别。维护者的理解是：竞聘是一段时间内收多份申请，发单方挑一个；需求方同意是来一份申请批一份，先批先得。待确认。
  3. 费用是否仍拆成预付和尾款两段（现有任务是两段）。
  4. 普通用户发的单要不要平台审核；发单方要不要认证标识（对标调研第三节「第三方发单合规」行建议加，用来防止有人冒充发单方行骗）。

### 5.5 资金凭证

- **答复**：先不管公司内部的外包流程。先满足这样一个情景：有人愿意出钱，也愿意让平台冻结这笔钱；验收通过后，平台把冻结的钱发给接单者。要注意资金安全与合规。
- **影响（维护者提示，要法务确认）**：
  - 「平台收下付款方的钱、冻结、再转给个人」正是 0924 对标调研写的红线形态：资金先进平台账户、再由平台结算给个人，对应人民银行认定的「二清」，落在《非银行支付机构监督管理条例》「变相从事支付业务」之内（调研一页结论第 5 条；该调研声明不是法律意见）。所以冻结的钱**不能放在平台自己的账户里**。
  - 符合这个情景、又避开红线的做法只有一类：钱放在持牌机构（支付宝或微信支付的担保、分账，或银行存管），平台只记账，并下「冻结、退款、放款」的指令（调研第四节方案 ⑤）。
  - 这要打破 0922 夜盘「不直接对接支付宝或微信支付」的技术边界（03 第 14 项），而且商户进件周期长。
  - 被「先不管」的，正是调研推荐的方案 ①（平台只记账，钱走公司外包合同）。
  - 不论最后选哪条路，平台账本里「冻结 → 退款或放款」这套状态都要做（推断）。
- **还要定**：
  1. 是否接受打破「不接支付」的边界、接持牌机构。
  2. 接哪一家、谁去办商户进件、要多久——这决定 10 月底能不能用真钱。
  3. 进件赶不上时的 planB，和 5.6 一起定。
  4. 接单者的个税代扣与发票（调研附录 D）。
  5. 是否还要报伟华批准。

### 5.6 用户价值验证进不进 10 月目标

- **答复**：要进。部分环节有卡点的，采用 planB。
- **影响**：10 月底验收加了第 ④ 条（第一节 1.1）。03 第 38 项有了她的答复，未关闭。
- **还要定**：
  1. 找谁来走（教师伙伴的发单方、接单的老师，各几个人），由谁去找。
  2. 按环节列出 planB：哪些环节可能卡住，各自用什么替代。目前看得到的卡点是老师登录（5.3）、真钱托管（5.5）和真实账号运营的业务配合（2.3）。

### 5.7 教师伙伴场景与伟华「只谈漫剧」的关系

- **答复**：先用教师伙伴的情景试跑。跑通了，拿到漫剧的单也可以跑。只要有单，就可以满足伟华的需求。
- **影响**：对 03 第 26、37 项里的张力，吴梦赢的看法是平台流程和场景无关，漫剧只差订单。
- **还要定**：
  1. 这是吴梦赢的判断。伟华的原话是要在漫剧场景里找三类用户走一遍（03 第 23 项），他是否认可「有单就行」，还没确认。
  2. 漫剧的单从哪来。伟华提过的候选是漫剧创作团队把分镜拆给多人做（03 第 24 项）。

### 5.8 插件用什么语言写（仍待定）

吴梦赢 0926：不知道，待定。

- **背景**：底座要给共建方和第三方提供插件开发工具包（W3）。Dify 的插件用 Python 写，宿主按 Python 环境拉起子进程（[插件宿主调研](../../AI工作台/报告/2026-09-25-插件宿主调研-Dify-plugin-daemon.md) 第 2 节）；本仓库的后端是 Python、前端是 TypeScript。
- **缺口**：共建方用什么技术栈、习惯写什么语言，还不知道。
- **不定会怎样**：语言决定开发工具包先做哪一种，以及宿主要支持哪几种运行环境（W2）。只支持一种最省事；同时支持两种，工作量接近翻倍。10/16 的验收是「共建方只看文档就能自己写出一个插件」，语言选得不合对方习惯，这条就很难过。

## 六、还没做的

- **减法**：按四人人力，在 2.4 的约 55 件里排优先级、决定保留与延后，下一步做。2.5 已估出缺口（约 141 人日对约 84 人日），先减 10/16 的范围。
- **时间排期**：白晨 0925 要求先不关心时间节点。
- **看板建卡**：减法之后，按 2.4 的任务建卡。
- **吴梦赢的判断若被采纳，要跟着改的文件**（本轮没改）：陪跑原型 README 与能力清单里「官方 agent 兜底」「提交即发尾款」的描述（5.1、5.2）；仓库 `AGENTS.md` 的「鉴权」行（5.3，实施前改）；[制作与交付设计](../specs/2026-09-16-制作与交付全流程-design.md) 3.3 节「提交即完成」（5.2，动 P5 前改）。