# AI 创业平台助手：能力清单与优先级（产品层）

日期：2026-09-23。对象：平台内 AI 助手对用户能做什么、先做什么。**只到产品能力层**，技术模块映射另起一份（白晨 0923 定「先产品后技术」）。

**性质三分**：**白晨已定**／**本文提案**／**待白晨定**，每条标一种。出处另列，不与性质混写。**本文所有「白晨 0923 定」均为 2026-09-23 白晨与维护者会话内口头确认，无录音，按工作层（★★）记；**五问与答案见第 7 节，log 同日有条目。产品侧（吴梦赢）单方原话在权威度上不等于「白晨已定」，凡以吴梦赢原话为唯一依据的条目标「待白晨定（吴梦赢提法）」。

出处缩写：「0921 夜谈」＝`sources/会议对谈/2026-09-21-AI助手定位与首个验证场景之争（…深夜录音转写）.md`；「0922 转述」＝`…2026-09-22-伟华会转述…下午录音转写.md`；「0922 夜盘」＝`…2026-09-22-三个待办…深夜录音转写.md`（说话人 1＝吴梦赢、2＝白晨）。行号指转写文件。

**几个词的定义**（产品与上级都按这个读）：
- **项目对象**：助手替用户建的一条结构化记录（目标、验收标准、预算、期限、状态），摆在页面上，只有用户本人经确认才能改，助手与执行方只读。
- **执行方**：接下某个任务去干的一方，可以是平台上的 agent、接单者，**或用户本人**。
- **官方能力**：平台自己维护、对效果负责的几个 agent 或人工服务；它跑在哪按 0903 口径（能力运行时不放在本平台，`wiki/00`:56）与 75 页定，本文只定「平台对它们的效果负责」。
- **结算触发**：指走现有积分／金额流程；现行实现是提交即自动发尾款，助手不改这个时机（见第 6 节第 1 项）。

## 1. 骨架（白晨 0923 定，口头）

| 项 | 结论 | 出处 |
|---|---|---|
| 主干 | **陪跑为主，撮合是其中一环**：陪用户把一件事从想法做到完成；拆解与匹配只是中间一步 | 0922 转述:50-53（白晨「需求确认→项目管理」）；0922 夜盘:146（吴梦赢「项管＋私人秘书，拆任务只是很小的一个环节」）；`wiki/00`:44「平台价值＝组织能力」 |
| 执行归谁 | **助手调度供给，平台留官方能力兜底**：活派给执行方，用户只做决策与验收；供给不够时平台自己有几个打磨好的官方能力顶上 | 0922 夜盘:146（吴梦赢「调度那个人来做」）；0921 夜谈:569（白晨「会有官方的 agent」，转引 `wiki/76`:56）；0921 共识「初期只能靠打磨几个能力把用户留住」（`wiki/76`:114） |
| 与现有线的关系 | **叠在 9/21 已建流程之上，能代用户操作平台**：助手是新入口，聊完能替用户发任务、挑执行方、提醒验收、走结算；不另建第二套流程 | 0921 夜谈:20-23（白晨助手两重定位：用平台＋承担核心动作） |
| 清单切法 | **按陪跑阶段切**，贯穿项单列 | 与主干同构，对得上现有流程，优先级好排 |
| 控制权 | **方向盘在用户**：做什么、怎么做、用什么方案由助手推荐，最后决定权在用户 | 0922 转述:53 |

**上位约束**（`wiki/00`:43-44）：平台价值＝组织能力，**不创造核心内容**。助手任何一条能力超出这条就不是这个平台。

**与 V7.0 定义的张力（本文登记，待 Ricky／伟华层）**：`wiki/00`:43 引 V7.0（★★★）定义平台为「由 AI 进行任务自动化拆解与服务需求撮合的平台」；本文把撮合降为一环，是白晨工作层（★★）裁决，按权威度不能直接覆盖 V7.0，已登记 `wiki/03`。

## 2. 能力清单（22 条）

### 2.1 前段：识别想法 → 需求确认 → 立项

| # | 能力 | 助手做什么 | 性质 | 出处 |
|---|---|---|---|---|
| A1 | 画像采集 | 知道用户会什么、做过什么、手上有什么资源。优先用平台已有数据（OpenQ 认证、接过的单、作品），不够再在对话里补问 | 白晨已定（0922 口述）；「优先用已有数据」为本文提案 | 0922 转述:50 |
| A2 | 想法识别 | 从对话里认出「这人有个事想做」，不等用户点「新建项目」 | 白晨已定（0922 口述） | 0922 转述:50 |
| A3 | 需求澄清 | 把模糊想法问成可执行目标。必问四项：做什么、做到什么程度算好、愿投多少钱和时间、有没有截止。**最多两轮**（一轮＝助手一次提问、用户一次回答），问不清就按已知先立项、缺口标「待补」 | 白晨已定（0921 口述、0923 认可两轮） | 0921 夜谈:20-23 |
| A4 | 立项 | 把澄清结果固化成**项目对象**（定义见页首） | 待白晨定（吴梦赢提法，0923 白晨会话认可） | 0921 夜谈:1025、:1031（说话人 3） |
| A5 | 可行性预判 | 立项时告诉用户：这事平台上现在有没有人／能力能接；没有则是等、换做法、还是先别立 | 本文提案；有伟华层依据（`wiki/00`:50「可行性判断归平台」）；白晨 0923 定优先级放低，**降级是工期原因不是依据不足** | 复盘:180-183 |

**设计要点**：A4 立项是助手相对通用聊天工具的第一个实质差别——聊完留下一个有状态、有验收标准、会自己往前走的对象。差别不在记忆，在有没有一个被管理的项目对象。

### 2.2 中段：拆解 → 匹配调度 → 推进

| # | 能力 | 助手做什么 | 性质 | 出处 |
|---|---|---|---|---|
| B1 | 任务拆解 | 把目标拆成能派出去的任务。粒度判据：一个任务＝能交给一个执行方、有明确交付物、能验收 | 白晨已定（0922「我们要帮他去拆解任务」）；粒度判据为本文提案 | 0922 转述:53 |
| B2 | 里程碑编排 | 任务排成有先后、有时间点的计划，用户看得见「现在走到哪」 | 待白晨定（吴梦赢提法） | 0921 夜谈:938、:944、:950（说话人 3） |
| B3 | 匹配与分档推荐 | 每个任务判断谁能做，给出几档：有成功经验的专家付费咨询 → 预算少则请资源方或 agent → 再省则 agent 直接回答，按预算和要求排 | 白晨已定（0921 分档背书原话） | 0921 夜谈:683 |
| B4 | 派活与交接 | 把任务真的发出去（落到现有发任务流程），执行方可以是 agent、接单者或**用户本人**（派给自己时助手只提醒）；并**把项目上下文一并传给执行方**——用户跟助手讲过的需求不让执行方再听一遍，换执行方时也不用 | 派活：待白晨定（吴梦赢提法「调度那个人来做」）；「用户本人可为执行方」与「上下文交接」为本文提案 | 0922 夜盘:146；0921 夜谈:629（「没有 AI 就让我来做」）；`wiki/76` 第七节候选假设 |
| B5 | 推进与提醒 | 跟踪每个任务状态，该催执行方的催，该用户做的提醒用户 | 待白晨定（吴梦赢提法） | 0921 夜谈:629（说话人 3） |
| B6 | 风险预警 | 进度要黄、预算要超、执行方没动静，提前说 | 白晨已定（0922 口述） | 0922 转述:53 |
| B7 | 决策点回收 | 该用户拍板的地方停下来问，用户说 OK 或不 OK，助手给下一步 | 白晨已定（控制权原则）；具体交互为吴梦赢提法 | 0922 转述:53；0922 夜盘:146 |

**设计要点**：B4 的「上下文一并传给执行方」是最容易漏、也最值钱的一条——通用聊天工具没有执行方，也就没有交接这回事。

**本轮不做**（白晨 0923 定）：多 agent 并行。同一任务不同时派给多个执行方；匹配给几档、用户选一个、跑一个。并行要先解决「结果怎么合、谁判优劣、多花的钱谁出」，不挡主干跑通。

### 2.3 后段：验收 → 结算 → 沉淀

| # | 能力 | 助手做什么 | 性质 | 出处 |
|---|---|---|---|---|
| C1 | 交付核对 | 执行方交东西回来，对照 A4 定的验收标准核一遍，告诉用户达没达到、差在哪。**注意**：现行流程提交即自动发尾款，C1 在现有实现上是事后评价，不能挡住付款（见第 6 节第 1 项） | 本文提案（由白晨 0922「项管角色…直到整个任务完成」延伸） | 0922 转述:53 |
| C2 | 不达标的处置 | 退回重做／换执行方／降级接受，给用户几个选项而不是卡住 | 待白晨定（吴梦赢提法） | 0921 夜谈:1193（说话人 3） |
| C3 | 结算触发 | 走现有积分／金额结算流程；助手**只记录与提醒**，不新建账、不改现行「提交即发尾款」的时机 | 白晨已定（0922 夜盘技术边界＋「叠在现有流程上」） | 0922 夜盘:101；`docs/superpowers/specs/2026-09-16-制作与交付全流程-design.md`:54 |
| C4 | 项目收尾 | 产出归档成作品／资产，可展示、可被别人复用 | 本文提案 | 9/21 已有作品展示 |
| C5 | 单项目复盘 | 这次哪步卡了、哪个执行方好用、实际花了多少、跟计划差多少 | 本文提案（由白晨 0922「根据完成情况适时调整」延伸） | 0922 转述:53 |
| C6 | 跨项目沉淀 | 多个项目的结果攒成可复用经验：这类任务该找谁、什么做法效果好 | 待白晨定（吴梦赢提法） | 0921 夜谈:1145（说话人 3） |

### 2.4 贯穿能力

| # | 能力 | 是什么 | 性质 | 出处 |
|---|---|---|---|---|
| D1 | 项目记忆 | 项目对象＋上下文，跨会话、跨执行方不丢；B4 的底座 | 本文提案 | 0921 夜谈:653（白晨对「只靠记忆太弱」的质疑——记忆要挂在项目对象上才有差别） |
| D2 | 质量与可信度管理 | 供给方的口碑、成功率、分档依据；差的能被筛掉 | 白晨已定（0921 承认平台须筛选质量） | 0921 夜谈:887；共识见 `wiki/76`:113 |
| D3 | 证据与归因 | 每步的输入、选择、结果、耗时留痕，用来回答「平台到底帮了什么」 | 本文提案；有伟华层依据（`wiki/00`:44「执行验收记录」）；**白晨 0921 曾持相反立场**（:707、:1112「不可能每次都证明」「证明成本很高」），故最小版本随 P0 一事列第 6 节 | 0921 夜谈:1289（包蕾）；`wiki/76` 第七节 |
| D4 | 边界与安全 | 方向盘在用户（不自动替用户花钱、签约、对外发布）；助手不被用户输入里的指令劫持；用户个人数据与项目记录分开存 | 控制权为白晨已定；后两条借用 `wiki/00`:91 对外技术方案稿的两条行文纪律，作为产品要求属本文提案 | 0922 转述:53；`wiki/00`:91 |

## 3. 优先级（锚：能跟完一个真项目，白晨 0923 定）

### P0 —— 缺一条这个项目就走不完（11 条）

**入口**：A2 想法识别不进 P0，第一轮由用户主动点「新建项目」进入 A3。

A3 需求澄清 → A4 立项 → B1 任务拆解 → B3 匹配（**简化版**：只给几个候选，不做完整三档）→ B4 派活与交接 → B5 推进与提醒 → B7 决策点回收 → C1 交付核对 → C3 结算记录；贯穿：D1 项目记忆、**D3 最小版本**（每步落一条「输入／选了谁／结果／耗时」）。

**两条兜底**（P0 内必须有，否则线是断的）：派出去无人承接或承接后没动静时，助手提示用户**人工指定执行方**（B6 风险预警的完整版在 P1）；C1 核对不达标时，第一轮只提示用户、处置走人工（C2 在 P1）。

串起来是一条完整的线：用户讲一个想法，最后拿到交付物、钱按现行流程结了。其中 **B4 与 D1 最容易被低估**——界面上看不见，少了它们整条线是断的。

### P1 —— 凑合能跟完，但很快就要（7 条）

A1 画像采集（先只用已有数据）、B2 里程碑编排（先只有任务列表）、B6 风险预警、C2 不达标处置、C4 项目收尾、C5 单项目复盘、D4 边界与安全。

### P2 —— 以后做（6 条）

A2 想法识别、A5 可行性预判、B3 完整三档分档、D2 质量与可信度管理（要有供给量才有意义）、C6 跨项目沉淀（要攒够项目）、多 agent 并行。

### 若 10/16 前压不下（本文提案，待白晨定）

P0 加现有流程对接、加助手交互载体，在约 9～12 个工作日且同期有工作台与交易两摊事的情况下，大概率做不完。**建议砍 B3**：P0 里 B3 的本质是「有一个执行方」而不是「匹配」，所以第一个项目可以直接**指定执行方**（官方能力或指定的人）替代匹配，力气全押「A4 立项 → B1 拆解 → B4 派活带上下文 → B5 跟踪 → C1 核对」这条骨架。匹配是撮合端的事，主干已定是陪跑。

## 4. 范围外（本轮不做，写明后果）

- 助手不做运营能力、不生产核心内容（`wiki/00`:44；白晨 0921 夜谈:515-524「碰了就不是 AI 创业平台了」）。
- 不承诺经营结果（粉丝数、成交额），但要管质量与证据（0921 共识，`wiki/76`:113）。
- **不做外部平台结果数据回流与定时触发**（吴梦赢 0921 夜谈:548、:629 提过「反馈是什么、定时发」）。后果：运营类项目的 C1 只能核「交付物有没有」，核不了「效果有没有」。
- **接单者侧助手不做**（白晨 0921 夜谈:23 两重定位之「用平台：答疑、找适合我的单」）——本轮 22 条全是发单方视角。列第 6 节待定。
- **用户上架自己的 agent／资源**不属助手能力，属供给侧（白晨 0921 夜谈:542、吴梦赢 :719）。
- 「首要是足够聪明」（吴梦赢 0922 夜盘:146）是对助手理解力的要求，归技术模块映射文。
- 不接支付宝／微信支付；结算走现有积分与金额对接（白晨 0922 夜盘:101）。
- 助手跑在哪（运行底座）不在本文，原见分支 `docs/ai-assistant-runtime-reeval` 的 75 页（未合并；白晨 2026-09-24 表示这条分支不要了，已删除，最后提交 `6c911d40`）。
- 助手的交互载体（对话框、画布、还是别的）不在本文，见第 6 节。

## 5. 与既有材料的关系

- **三种定位说法**（`wiki/03` 第 2026-09-22 节第 5 项）：本文以「陪跑为主、撮合一环」收口，**由白晨 0923 会话定**；0921「拆需求＋匹配是核心」的说法退为 B1／B3 两条能力，不再是主干。
- **`wiki/76` 第三节四个无人回答的问题**：①拆解由谁负责 → 平台负责拆（B1，依据是白晨次日 0922 转述:53 的表态，不是 0921 那场的结论），拆得好不好进 D3 证据；②多 agent 汇聚 → 本轮不做；③只靠记忆太弱 → 答案是 A4 项目对象＋D1，不是记忆本身；④拆完效果不好怎么迭代 → C5／C6，本轮 P1／P2。
- **包蕾的质询**（`wiki/76` 第四节）：「证明比直接用 ChatGPT 好」（:446）→ D3 承接归因；「告诉我最优路径并连接资源」（:611）→ 本轮不单列，并入 B1 拆解与 B3 匹配。
- **吴梦赢的「运营工作台」描述**（:629）→ 拆进 B4「用户本人可为执行方」、B5 提醒、A4 项目对象三条；其中「反馈是什么」那一半按第 4 节不做。
- **`wiki/76` 第七节「可验证增量价值」候选假设**：B4 上下文交接是它的直接落点，D3 是它的度量手段。

## 6. 待白晨定

| # | 问题 | 本文默认 | 备选 |
|---|---|---|---|
| 1 | **C1 与现行「提交即自动发尾款」的关系**：现有实现（制作与交付 spec:54）在提交事务里自动验收＋发尾款，助手的交付核对挡不住付款 | 不改结算时机，C1 退为事后评价，C3 只记录与提醒 | 恢复验收环节、尾款等 C1 通过后再发——需改 `2026-09-13-9月21日真实应用开发-design.md` 并登记 03 |
| 2 | 10/16 前 P0 压不下时砍什么 | 砍 B3 匹配，指定执行方 | 砍 B5 提醒；或砍 C1 核对（只结算不核） |
| 3 | 助手的交互载体 | 未定 | 对话框；白晨 0922 深夜提的画布（**若选画布，须同时重议多 agent 并行**——`wiki/80` 第 5.2 节已注两者是同一块问题）；两者都有 |
| 4 | 第一个真项目是什么 | 未定；候选是教师伙伴自带运营预算发单（`wiki/80` 第四节） | 外包部任务；内部演示项目 |
| 5 | 接单者侧助手（找适合我的单、平台答疑）做不做 | 本轮不做 | 加为贯穿项 |
| 6 | D3 最小版本是否随 P0 | 是（理由：事后补不回来） | 严格按 P1（白晨 0921「证明成本很高」立场） |
| 7 | 「官方能力兜底」第一批是哪几个 | 未定 | 按第一个真项目倒推 |
| 8 | 吴梦赢提法的 6 条（A4／B2／B4 派活／B5／C2／C6）是否认领为已定 | 本文按待定 | 白晨一次性认领 |

## 7. 依据

**白晨 0923 会话五问与答案**（口头，无录音，工作层）：清单用途 → 先产品后技术；助手主干 → 陪跑为主、撮合一环；执行归谁 → 助手调度供给＋官方能力兜底；与现有线关系 → 叠在之上、能代用户操作平台；清单切法 → 按陪跑阶段。另认可：A3 两轮上限、A5 降级、多 agent 并行本轮不做、排序锚「能跟完一个真项目」、第一节与第二节能力表内容。

**材料**：
- `wiki/76-AI助手定位与首个验证场景之争-0921深夜对谈.md` 第三、四、七节
- `wiki/77-伟华会转述-产品闭环与解耦工作台与10月16日节点-0922对谈.md` 第五节
- `wiki/80-三个待办-工作台外部接入与交易与AI助手-0922深夜对谈.md` 第五节
- `wiki/00-当前权威口径.md`:43-44、:50、:56、:91
- `docs/superpowers/specs/2026-09-16-制作与交付全流程-design.md`:54（提交自动验收与尾款同事务）
- 独立审查（2026-09-23 子代理，25 条发现：6 必须改／16 建议改／3 可不改，前两档已全部落实；要点见 `wiki/log.md` 同日条目）