10 月目标、验收标准与模块拆分（2026-09-25）
来源与性质：2026-09-25 白晨与维护者会话逐轮对齐的结果，白晨口头确认，无录音，按工作层（★★）记。2026-09-26 白晨在会话里转述了吴梦赢对第五节八个问题的判断（七个有答复，插件语言她也不知道），以及她对发单时要附哪些信息的判断；这些是吴梦赢的判断，白晨未逐条表态，同样按工作层记。同日补了 2.4 任务拆解（约 55 件），白晨「基本认可」；又按公司月度事务表格式归并成 2.5 的 17 条事务并估了工时。本文是给吴梦赢与林炜沟通用的底稿：目标与验收标准白晨已认可，模块拆分白晨已看过；还没按人力做减法，也还没排时间。
怎么读：吴梦赢先看第一、二、五节；林炜先看第三、四节。每条标已定（白晨 0925 确认）、吴梦赢判断（白晨 0926 转述，白晨未逐条表态）或提案（维护者提出，白晨未逐条确认）；第五节是吴梦赢对八个问题的判断、判断对现状的影响，以及由此带出、还要定的事。
与 0922 执行清单的关系：《下一阶段要做什么（0922 夜盘，按执行方分工）》〈仓库引用；未随包提供〉是按「谁做」切的待办；本文按「10 月要达成什么」切，是当前基线。0922 清单里已完成的几项（工作台模块清单 AIC-1902、交易对标调研 AIC-1906、助手能力清单与陪跑原型）是本文的输入。
〇、团队与节点
- 10 月人力（已定）：白晨、林炜、陈高武、卓清香，四人是创业平台与 AI 工作台两边的总人力。
- 两个节点（已定）：
- 10/16 是每月例行的月度结项（白晨 0925 说明；此前 03 未决问题〈仓库引用；未随包提供〉 第 28 项「10/16 出处待白晨说明」由此回答）。这一期以技术选型、调研、方案设计为主，但必须交付一条能跑的基本流程。
- 10 月底才出完整流程，把整条链串通。
- 本月两条线（已定）：创业平台做 AI 助手（按 0923 陪跑原型的业务逻辑串起来）；AI 工作台搭底座（面向 C 端，与公司内另一业务方的工作台共用一份底座）。
一、目标与验收标准
1.1 创业平台：教师伙伴场景
演示场景（已定）：用 AI 教师伙伴。这个场景有两层，两层都要做：
- 运营层：用助手跑通教师伙伴小红书账号的运营。业务逻辑以 陪跑流程原型 为准。
- 交易层：教师伙伴项目在创业平台上发单，推广时让老师们过来接单、提交成果，平台给他们发钱。
交易层放到 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 个）
测试与验收场景不单列，算作每个模块完成的一部分（本仓库按 工程标准〈仓库引用；未随包提供〉 要求三层测试加业务验收场景）。
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 的项目对象与工作台模块清单里「项目中心先独立做」（模块清单置顶总表）是同一个对象。
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 助手技术底座
- 〔10/16〕助手运行框架选型，出技术方案。由林炜判断，候选名单与 0921 调研见第三节。
- 〔10/16〕接通公司模型网关（AI Gateway）。网关密钥 30 天轮换，要有更换密钥的办法。
- 〔10/16〕流式对话：团团栏 ↔ 后端 SSE（仓库已定用 FastAPI 内置 SSE）。
- 〔10/16 起步〕把平台功能注册成助手可调用的工具，如建项目、建任务、派活。花钱、对外发布、改目标或验收标准、换人、结项五类事必须弹确认。
- 〔10 月底〕主动唤醒：到时间或有事件发生时（逾期、快到期等），触发团团做判断。
P2 需求确认与立项（10/16 全部完成）
- 项目对象（数据与接口）：目标、验收标准、预算、期限、状态、待补项。
- 需求对话：必问四项（做什么、做到什么程度、预算、期限）加自由追问，「团团已了解」逐项亮起，问到够开工就停。
- 项目摘要：没问到的项标「待补」。
- 开工确认：用户点「开工」后，项目进入实施阶段，交给 P3 排任务。
P3 项目画布与任务管理
- 〔10/16〕任务对象：状态、执行方（用户本人、他人、Agent、接单者）、所属阶段、先后关系。
- 〔10/16〕开工时，团团按项目摘要排出第一阶段任务。
- 〔10/16〕流程视图画布。
- 〔10/16〕派活给用户本人，用户回报完成（口述或截图）后，状态回到画布。
- 〔10 月底〕团团栏的确认卡，以及改动记录抽屉：每次改动都有记录，团团新增、还没开始的任务可以撤回。
- 〔10 月底〕时间轴、看板两个视图，与流程视图共用同一份数据。
- 〔10 月底〕付费任务派给接单者，也就是转成交易层的单，接 P5。
- 〔10 月底〕〔吴梦赢判断〕〔待定〕免费任务的三种去向：用户自己执行、指派给人、创建 Agent。「创建 Agent、验证后交付平台换激励」做到哪一步待定（5.1）。
P4 运营推进（10 月底）
- 数据回报：上传截图或直接报数，团团识别出关键数字。
- 自动改计划：看到信号就增删调任务，要花钱的弹确认。
- 风险预警与换人：接单者逾期或不回消息时预警；换人时退回原预付，由新人接手。退款依赖 P5。
- 阶段复盘：列出判断依据，给出继续、调整打法、暂停、结项四个选项。
- 结项判断与结项报告：各项指标、阶段回顾、团团做了什么，打法存为经验。
- 用真实账号跑完起号期。前提是业务侧定下谁发帖、谁回报数据（2.3）。
P5 交易（10 月底；大部分标〔吴梦赢判断〕，细节〔待定〕见 5.2～5.5）
- 普通用户发单：发单页（需求说明、费用、接单期限、发单模式），以及发单方身份。
- 费用冻结与到期退款：冻结后要么退款、要么放款；接单期限到了没人接，自动退款并取消。钱放在哪里托管，要法务确认后才能动真钱（5.5）。
- 三种发单模式：自动接受（现有实现就是这种）、竞聘（有申请列表，发单方挑一个）、需求方同意（逐个审批）。
- 老师登录：接教师伙伴登录组件，手机号验证码登录，首次登录设头像和名称；推广链接直达对应任务。
- 验收后放款：把「提交即验收」改为由发单方验收，通过就发尾款，不通过就打回。
- 金额结算记录与对账：结算加上金额字段，与实际付款对得上。
- 与运营层接通：团团派出的付费任务自动变成交易层的单，完成后状态回到画布。
跨模块：用户价值验证（〔10 月底〕〔吴梦赢判断〕，5.6）
- 找没参与开发的发单方与老师来走一遍，记录断点、看不懂的地方、流失点。
- 列出 planB 清单：哪个环节可能卡住，卡住了用什么替代。
AI 工作台底座（新仓库）
W1 协议与规范
- 〔10/16〕插件清单格式 v0：名称、版本、权限、数据接口、展示模块。
- 〔10/16〕数据接口规范：用 Schema 说明字段含义，覆盖查询、增删改、事件。
- 〔10/16〕展示模块规范：尺寸，以及能用的交互（点击、流式输出、动画等）。
- 〔10 月底〕按共建方接入的反馈修订。
W2 插件宿主
- 〔10/16〕安装插件：按清单安装并校验。
- 〔10/16〕子进程运行插件，请求链路走通：前台动作 → 宿主 → 插件 → 外部接口 → 返回。
- 〔10/16〕远程调试：开发者本地的插件能连到宿主上跑。
- 〔10/16〕凭据：按用户加密保存，请求时交给插件，由宿主编排 OAuth 授权（这套做法是提案，见 4.1）。
- 〔10/16〕对外接口，给顶层应用调用。
- 〔10 月底〕事件推送。
W3 开发套件与样例插件（10/16 全部完成）
- 开发工具包。〔待定〕插件用什么语言还没定（5.8），这件卡住整个 W3。
- 项目模板与脚手架。
- 开发文档：从零写一个插件，到装进宿主跑起来。
- 两个样例插件，接什么可以换。
- 验收：共建方只看文档，自己写出一个插件。
W4 前端渲染
- 〔10/16〕声明式渲染器：插件给数据和组件描述，由工作台用自己的组件渲染。
- 〔10/16〕演示宿主页：能装插件、渲染默认模块、点击后取回数据。
- 〔10 月底〕代码档沙箱：审核过的插件提交的 HTML，在隔离框里运行。
W5 上架与市场
- 〔10/16〕清单格式校验。
- 〔10 月底〕签名。
- 〔10 月底〕审核后台，完整走一遍上架流程。
- 〔10 月底〕市场页：可浏览、可安装（给副总看）。
W6 创业平台工作台接入（10 月底，代码在本仓库）
- 至少 2 个模块改为经底座插件取数据。
- 演示「新建一个组件」：基于某个插件的数据接口生成一套皮肤，并上架到市场。
拆完看到的三件事（维护者判断）
- 10/16 的关键路径是 P1 选型 → 模型接通 → P2 → P3。 模型网关密钥（2.3 第一行）不到位，整条链都动不了，应该最先去要。
- W3 被「插件用什么语言」卡住，而 10/16 的验收就是共建方自己写出插件。 要在开工第一周问清共建方的技术栈，不能等到 10 月底。
- 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〈仓库引用；未随包提供〉。表是这份数据的唯一正文，本节只记口径与结论。
- 口径（提案，白晨未确认）：优先级 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「本轮定下的产品规则」。
- 产品层能力清单：AI 创业平台助手能力清单，22 条、P0 11 条；0923 夜谈基本认可原型，对外叫法口头定为「创业教练」（0923 夜谈页〈仓库引用；未随包提供〉）。
四、AI 工作台底座：分层与已定原则
4.1 分层（白晨 0925 口述，维护者合并整理）
底座（新仓库，与另一业务方共建，已定）：
| 层 | 做什么 |
|---|---|
| ① 插件宿主 | 参考 Dify 的 plugin daemon：第三方上架插件就是把插件安装进宿主；前台触发一个动作（如查看数据）时，请求打到宿主里对应的插件，宿主起子进程或其他形式执行插件、拿到数据再返回。底座是轻的 |
| ② 凭据 | 插件怎么对接飞书、公司事务池，由插件自己决定。凭据的保管方式为提案：宿主按用户加密保存、每次请求时交给插件，插件不存；OAuth 授权由宿主编排（照 Dify 做法，改为按用户） |
| ③ 数据接口协议 | 不做统一数据模型：飞书就是飞书的接口。只规定格式——用 Schema 说明每个字段的含义，帮助上游封装与理解，不规定内容。包括查、增删改与事件推送 |
| ④ 展示模块规范 | 类似 iOS 界定小组件支持哪些交互，规定模块的尺寸、交互、能力（点击、流式输出、动画等），保证插件装上后稳定 |
| ⑤ 上架与市场 | 插件＝数据接口＋可视化模块。用户在市场里看到的是可视化模块；底层数据接口让上层 agent 能组装，这是 AI 工作台与传统工作台的区别——用户有自定义模块的权利 |
顶层应用（不在底座仓库里，已定）：
- 顶层有一个 Agent Runtime，响应「给我找一个组件」「添加一个组件」「新建一个组件」，并按用户记忆实时推荐。
- AI 生成的是展示层，数据层复用；生成的模块存在哪、用什么风格，由顶层应用决定。顶层应用觉得某套皮肤好，就把它上架。
4.2 本次已定的原则
- 协议是私有协议，不用 MCP，为的是别人上架时能做审核、验证。（已定）
- 展示层声明式与代码档都做：声明式是插件给数据＋一段组件描述、由工作台用自己的组件渲染；代码档是审核过的插件提交 HTML 页面、在隔离框里运行。（已定；维护者原建议 10 月只做声明式，白晨未采纳）代码档沙箱放 10 月底、10/16 先做声明式。（提案，白晨回复「基本认可」）
- 10 月隔离做第一档：每个插件一个进程、不设沙箱，只接我们自己和共建方的插件；对第三方开放上架前升到第二档（每插件一个容器，只许访问声明过的域名）；第三档（每用户每插件一个沙箱）先不做。（已定）
- 底座仓库不写顶层 Agent Runtime 的代码。（已定）
4.3 两份调研（2026-09-25）
- 插件宿主调研：Dify plugin daemon：请求链路、子进程运行、清单与 Schema 写法、签名上架、凭据与隔离；末尾「照搬／改造／不要」三栏。
- 工作台模块运行时与交互规范调研：WidgetKit／Glance／飞书卡片／Adaptive Cards（声明式）对照 MCP Apps／Apps SDK／Figma（代码沙箱），交互能力清单、尺寸体系、AI 生成皮肤的两条路，末尾 14 章规范骨架。
- 前序材料：插件定义与工作台交互（0912 附件一，插件十项要素、十二种交互）〈仓库引用；未随包提供〉、苹果小组件开发者规范演进（0913）〈仓库引用；未随包提供〉。
五、八个问题：吴梦赢的判断（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 可以执行」的 Agent 从哪来：外部接入的 AI 员工、用户创建后交付给平台的 Agent，还是两者都算。
- 「指派给人执行」是指派给用户自己找的人（站外），还是在平台上发单给接单者。
- 在哪里创建 Agent，「验证有效」由谁、按什么标准来验。
- 激励是什么（积分、贝壳还是分成），以及这一段 10 月做不做。
5.2 尾款什么时候发
- 答复：验收通过之后发。
- 影响：要改 9/21 的开发依据和已上线的流程——现在提交的同一个事务里就自动验收并发尾款（制作与交付设计〈仓库引用；未随包提供〉 3.3 节，
apps/api/app/workflows/submit.py:53）。改完后，助手的「交付核对」就能挡住付款了，03 第 18 项有了她的答复，未关闭。 - 还要定：
- 谁来验收：发单方本人，还是可以先交给团团核对。
- 验收不通过怎么办：打回修改几次、能不能取消、钱怎么处理。
- 发单方一直不验收怎么办。三家对标平台都设了超时自动验收：猪八戒网 7 天，闲鱼 10 天（交易机制对标调研一页结论第 1 条）。
- 预付款是否仍在接单时发（现在是）。
5.3 老师怎么登录
- 答复：直接复用教师伙伴的登录组件。可以用手机号获取验证码登录，登录后设置头像和名称。
- 影响：
- 仓库
AGENTS.md的「鉴权」行现在写的是「不自建登录，跳公司统一 UC」，并规定改栈要先改那一节。实施前要先改它，本轮没改。 - 现在的姓名从 UC 用户资料里取、头像用 UC 的头像地址（
AGENTS.md「鉴权」行）。改成用户自己设置后，平台要自己存名称和头像（推断：头像按现有做法存进 CS 内容服务）。
- 仓库
- 还要定：
- 这个组件归谁维护、找谁对接。
- 它背后是不是同一套 UC（
cn.ndhy.com）账号。是，老师和现有用户就是同一种身份；不是，平台上就有两套账号，要定怎么对应。 - 已经有 UC 账号的用户，是否也可以用手机号登录。
5.4 发单
- 答复：开放普通用户发单。发单时，除了需求说明，还要附上：
- 费用；
- 接单期限：这个时间内没人接单，钱退给发单的用户，单子取消；
- 发单模式：有人接单自动接受、需要竞聘、需要需求方同意，三选一。
- 影响：现状只有管理员能发单、只有「自动接受」一种模式、截止时间只有一个
due_at（第二节「代码现状」）。要新做的有：发单页面与权限；发单方身份（现在需求方只是一个文本字段）；接单期限与到期退款；竞聘和需求方同意两种模式要有申请列表和选人。 - 还要定：
- 接单期限和交付期限是否分开（维护者建议分开：现在的
due_at同时管着两件事）。 - 竞聘和需求方同意的区别。维护者的理解是：竞聘是一段时间内收多份申请，发单方挑一个；需求方同意是来一份申请批一份，先批先得。待确认。
- 费用是否仍拆成预付和尾款两段（现有任务是两段）。
- 普通用户发的单要不要平台审核；发单方要不要认证标识（对标调研第三节「第三方发单合规」行建议加，用来防止有人冒充发单方行骗）。
- 接单期限和交付期限是否分开（维护者建议分开：现在的
5.5 资金凭证
- 答复：先不管公司内部的外包流程。先满足这样一个情景：有人愿意出钱，也愿意让平台冻结这笔钱；验收通过后，平台把冻结的钱发给接单者。要注意资金安全与合规。
- 影响（维护者提示，要法务确认）：
- 「平台收下付款方的钱、冻结、再转给个人」正是 0924 对标调研写的红线形态：资金先进平台账户、再由平台结算给个人，对应人民银行认定的「二清」，落在《非银行支付机构监督管理条例》「变相从事支付业务」之内（调研一页结论第 5 条；该调研声明不是法律意见）。所以冻结的钱不能放在平台自己的账户里。
- 符合这个情景、又避开红线的做法只有一类：钱放在持牌机构（支付宝或微信支付的担保、分账，或银行存管），平台只记账，并下「冻结、退款、放款」的指令（调研第四节方案 ⑤）。
- 这要打破 0922 夜盘「不直接对接支付宝或微信支付」的技术边界（03 第 14 项），而且商户进件周期长。
- 被「先不管」的，正是调研推荐的方案 ①（平台只记账，钱走公司外包合同）。
- 不论最后选哪条路，平台账本里「冻结 → 退款或放款」这套状态都要做（推断）。
- 还要定：
- 是否接受打破「不接支付」的边界、接持牌机构。
- 接哪一家、谁去办商户进件、要多久——这决定 10 月底能不能用真钱。
- 进件赶不上时的 planB，和 5.6 一起定。
- 接单者的个税代扣与发票（调研附录 D）。
- 是否还要报伟华批准。
5.6 用户价值验证进不进 10 月目标
- 答复：要进。部分环节有卡点的，采用 planB。
- 影响：10 月底验收加了第 ④ 条（第一节 1.1）。03 第 38 项有了她的答复，未关闭。
- 还要定：
- 找谁来走（教师伙伴的发单方、接单的老师，各几个人），由谁去找。
- 按环节列出 planB：哪些环节可能卡住，各自用什么替代。目前看得到的卡点是老师登录（5.3）、真钱托管（5.5）和真实账号运营的业务配合（2.3）。
5.7 教师伙伴场景与伟华「只谈漫剧」的关系
- 答复：先用教师伙伴的情景试跑。跑通了，拿到漫剧的单也可以跑。只要有单，就可以满足伟华的需求。
- 影响：对 03 第 26、37 项里的张力，吴梦赢的看法是平台流程和场景无关，漫剧只差订单。
- 还要定：
- 这是吴梦赢的判断。伟华的原话是要在漫剧场景里找三类用户走一遍（03 第 23 项），他是否认可「有单就行」，还没确认。
- 漫剧的单从哪来。伟华提过的候选是漫剧创作团队把分镜拆给多人做（03 第 24 项）。
5.8 插件用什么语言写（仍待定）
吴梦赢 0926：不知道，待定。
- 背景：底座要给共建方和第三方提供插件开发工具包（W3）。Dify 的插件用 Python 写，宿主按 Python 环境拉起子进程（插件宿主调研 第 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，实施前改）；制作与交付设计〈仓库引用；未随包提供〉 3.3 节「提交即完成」（5.2，动 P5 前改）。