AI 助手 / 周报附件

AI 创业平台助手能力清单

取证快照 2026-09-28 · HEAD 0d539b1b · 文件提交 31e58a48

来源：docs/superpowers/specs/2026-09-23-AI创业平台助手能力清单-design.md

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＝白晨）。行号指转写文件。

几个词的定义（产品与上级都按这个读）：

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. 范围外（本轮不做，写明后果）

5. 与既有材料的关系

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 并行本轮不做、排序锚「能跟完一个真项目」、第一节与第二节能力表内容。

材料：

查看带行号的原始 Markdown（共 146 行）
1# AI 创业平台助手：能力清单与优先级（产品层）
2
3日期：2026-09-23。对象：平台内 AI 助手对用户能做什么、先做什么。**只到产品能力层**，技术模块映射另起一份（白晨 0923 定「先产品后技术」）。
4
5**性质三分**：**白晨已定**／**本文提案**／**待白晨定**，每条标一种。出处另列，不与性质混写。**本文所有「白晨 0923 定」均为 2026-09-23 白晨与维护者会话内口头确认，无录音，按工作层（★★）记；**五问与答案见第 7 节，log 同日有条目。产品侧（吴梦赢）单方原话在权威度上不等于「白晨已定」，凡以吴梦赢原话为唯一依据的条目标「待白晨定（吴梦赢提法）」。
6
7出处缩写：「0921 夜谈」＝`sources/会议对谈/2026-09-21-AI助手定位与首个验证场景之争（…深夜录音转写）.md`；「0922 转述」＝`…2026-09-22-伟华会转述…下午录音转写.md`；「0922 夜盘」＝`…2026-09-22-三个待办…深夜录音转写.md`（说话人 1＝吴梦赢、2＝白晨）。行号指转写文件。
8
9**几个词的定义**（产品与上级都按这个读）：
10- **项目对象**：助手替用户建的一条结构化记录（目标、验收标准、预算、期限、状态），摆在页面上，只有用户本人经确认才能改，助手与执行方只读。
11- **执行方**：接下某个任务去干的一方，可以是平台上的 agent、接单者，**或用户本人**。
12- **官方能力**：平台自己维护、对效果负责的几个 agent 或人工服务；它跑在哪按 0903 口径（能力运行时不放在本平台，`wiki/00`:56）与 75 页定，本文只定「平台对它们的效果负责」。
13- **结算触发**：指走现有积分／金额流程；现行实现是提交即自动发尾款，助手不改这个时机（见第 6 节第 1 项）。
14
15## 1. 骨架（白晨 0923 定，口头）
16
17| 项 | 结论 | 出处 |
18|---|---|---|
19| 主干 | **陪跑为主，撮合是其中一环**：陪用户把一件事从想法做到完成；拆解与匹配只是中间一步 | 0922 转述:50-53（白晨「需求确认→项目管理」）；0922 夜盘:146（吴梦赢「项管＋私人秘书，拆任务只是很小的一个环节」）；`wiki/00`:44「平台价值＝组织能力」 |
20| 执行归谁 | **助手调度供给，平台留官方能力兜底**：活派给执行方，用户只做决策与验收；供给不够时平台自己有几个打磨好的官方能力顶上 | 0922 夜盘:146（吴梦赢「调度那个人来做」）；0921 夜谈:569（白晨「会有官方的 agent」，转引 `wiki/76`:56）；0921 共识「初期只能靠打磨几个能力把用户留住」（`wiki/76`:114） |
21| 与现有线的关系 | **叠在 9/21 已建流程之上，能代用户操作平台**：助手是新入口，聊完能替用户发任务、挑执行方、提醒验收、走结算；不另建第二套流程 | 0921 夜谈:20-23（白晨助手两重定位：用平台＋承担核心动作） |
22| 清单切法 | **按陪跑阶段切**，贯穿项单列 | 与主干同构，对得上现有流程，优先级好排 |
23| 控制权 | **方向盘在用户**：做什么、怎么做、用什么方案由助手推荐，最后决定权在用户 | 0922 转述:53 |
24
25**上位约束**（`wiki/00`:43-44）：平台价值＝组织能力，**不创造核心内容**。助手任何一条能力超出这条就不是这个平台。
26
27**与 V7.0 定义的张力（本文登记，待 Ricky／伟华层）**：`wiki/00`:43 引 V7.0（★★★）定义平台为「由 AI 进行任务自动化拆解与服务需求撮合的平台」；本文把撮合降为一环，是白晨工作层（★★）裁决，按权威度不能直接覆盖 V7.0，已登记 `wiki/03`。
28
29## 2. 能力清单（22 条）
30
31### 2.1 前段：识别想法 → 需求确认 → 立项
32
33| # | 能力 | 助手做什么 | 性质 | 出处 |
34|---|---|---|---|---|
35| A1 | 画像采集 | 知道用户会什么、做过什么、手上有什么资源。优先用平台已有数据（OpenQ 认证、接过的单、作品），不够再在对话里补问 | 白晨已定（0922 口述）；「优先用已有数据」为本文提案 | 0922 转述:50 |
36| A2 | 想法识别 | 从对话里认出「这人有个事想做」，不等用户点「新建项目」 | 白晨已定（0922 口述） | 0922 转述:50 |
37| A3 | 需求澄清 | 把模糊想法问成可执行目标。必问四项：做什么、做到什么程度算好、愿投多少钱和时间、有没有截止。**最多两轮**（一轮＝助手一次提问、用户一次回答），问不清就按已知先立项、缺口标「待补」 | 白晨已定（0921 口述、0923 认可两轮） | 0921 夜谈:20-23 |
38| A4 | 立项 | 把澄清结果固化成**项目对象**（定义见页首） | 待白晨定（吴梦赢提法，0923 白晨会话认可） | 0921 夜谈:1025、:1031（说话人 3） |
39| A5 | 可行性预判 | 立项时告诉用户：这事平台上现在有没有人／能力能接；没有则是等、换做法、还是先别立 | 本文提案；有伟华层依据（`wiki/00`:50「可行性判断归平台」）；白晨 0923 定优先级放低，**降级是工期原因不是依据不足** | 复盘:180-183 |
40
41**设计要点**：A4 立项是助手相对通用聊天工具的第一个实质差别——聊完留下一个有状态、有验收标准、会自己往前走的对象。差别不在记忆，在有没有一个被管理的项目对象。
42
43### 2.2 中段：拆解 → 匹配调度 → 推进
44
45| # | 能力 | 助手做什么 | 性质 | 出处 |
46|---|---|---|---|---|
47| B1 | 任务拆解 | 把目标拆成能派出去的任务。粒度判据：一个任务＝能交给一个执行方、有明确交付物、能验收 | 白晨已定（0922「我们要帮他去拆解任务」）；粒度判据为本文提案 | 0922 转述:53 |
48| B2 | 里程碑编排 | 任务排成有先后、有时间点的计划，用户看得见「现在走到哪」 | 待白晨定（吴梦赢提法） | 0921 夜谈:938、:944、:950（说话人 3） |
49| B3 | 匹配与分档推荐 | 每个任务判断谁能做，给出几档：有成功经验的专家付费咨询 → 预算少则请资源方或 agent → 再省则 agent 直接回答，按预算和要求排 | 白晨已定（0921 分档背书原话） | 0921 夜谈:683 |
50| B4 | 派活与交接 | 把任务真的发出去（落到现有发任务流程），执行方可以是 agent、接单者或**用户本人**（派给自己时助手只提醒）；并**把项目上下文一并传给执行方**——用户跟助手讲过的需求不让执行方再听一遍，换执行方时也不用 | 派活：待白晨定（吴梦赢提法「调度那个人来做」）；「用户本人可为执行方」与「上下文交接」为本文提案 | 0922 夜盘:146；0921 夜谈:629（「没有 AI 就让我来做」）；`wiki/76` 第七节候选假设 |
51| B5 | 推进与提醒 | 跟踪每个任务状态，该催执行方的催，该用户做的提醒用户 | 待白晨定（吴梦赢提法） | 0921 夜谈:629（说话人 3） |
52| B6 | 风险预警 | 进度要黄、预算要超、执行方没动静，提前说 | 白晨已定（0922 口述） | 0922 转述:53 |
53| B7 | 决策点回收 | 该用户拍板的地方停下来问，用户说 OK 或不 OK，助手给下一步 | 白晨已定（控制权原则）；具体交互为吴梦赢提法 | 0922 转述:53；0922 夜盘:146 |
54
55**设计要点**：B4 的「上下文一并传给执行方」是最容易漏、也最值钱的一条——通用聊天工具没有执行方，也就没有交接这回事。
56
57**本轮不做**（白晨 0923 定）：多 agent 并行。同一任务不同时派给多个执行方；匹配给几档、用户选一个、跑一个。并行要先解决「结果怎么合、谁判优劣、多花的钱谁出」，不挡主干跑通。
58
59### 2.3 后段：验收 → 结算 → 沉淀
60
61| # | 能力 | 助手做什么 | 性质 | 出处 |
62|---|---|---|---|---|
63| C1 | 交付核对 | 执行方交东西回来，对照 A4 定的验收标准核一遍，告诉用户达没达到、差在哪。**注意**：现行流程提交即自动发尾款，C1 在现有实现上是事后评价，不能挡住付款（见第 6 节第 1 项） | 本文提案（由白晨 0922「项管角色…直到整个任务完成」延伸） | 0922 转述:53 |
64| C2 | 不达标的处置 | 退回重做／换执行方／降级接受，给用户几个选项而不是卡住 | 待白晨定（吴梦赢提法） | 0921 夜谈:1193（说话人 3） |
65| C3 | 结算触发 | 走现有积分／金额结算流程；助手**只记录与提醒**，不新建账、不改现行「提交即发尾款」的时机 | 白晨已定（0922 夜盘技术边界＋「叠在现有流程上」） | 0922 夜盘:101；`docs/superpowers/specs/2026-09-16-制作与交付全流程-design.md`:54 |
66| C4 | 项目收尾 | 产出归档成作品／资产，可展示、可被别人复用 | 本文提案 | 9/21 已有作品展示 |
67| C5 | 单项目复盘 | 这次哪步卡了、哪个执行方好用、实际花了多少、跟计划差多少 | 本文提案（由白晨 0922「根据完成情况适时调整」延伸） | 0922 转述:53 |
68| C6 | 跨项目沉淀 | 多个项目的结果攒成可复用经验：这类任务该找谁、什么做法效果好 | 待白晨定（吴梦赢提法） | 0921 夜谈:1145（说话人 3） |
69
70### 2.4 贯穿能力
71
72| # | 能力 | 是什么 | 性质 | 出处 |
73|---|---|---|---|---|
74| D1 | 项目记忆 | 项目对象＋上下文，跨会话、跨执行方不丢；B4 的底座 | 本文提案 | 0921 夜谈:653（白晨对「只靠记忆太弱」的质疑——记忆要挂在项目对象上才有差别） |
75| D2 | 质量与可信度管理 | 供给方的口碑、成功率、分档依据；差的能被筛掉 | 白晨已定（0921 承认平台须筛选质量） | 0921 夜谈:887；共识见 `wiki/76`:113 |
76| D3 | 证据与归因 | 每步的输入、选择、结果、耗时留痕，用来回答「平台到底帮了什么」 | 本文提案；有伟华层依据（`wiki/00`:44「执行验收记录」）；**白晨 0921 曾持相反立场**（:707、:1112「不可能每次都证明」「证明成本很高」），故最小版本随 P0 一事列第 6 节 | 0921 夜谈:1289（包蕾）；`wiki/76` 第七节 |
77| D4 | 边界与安全 | 方向盘在用户（不自动替用户花钱、签约、对外发布）；助手不被用户输入里的指令劫持；用户个人数据与项目记录分开存 | 控制权为白晨已定；后两条借用 `wiki/00`:91 对外技术方案稿的两条行文纪律，作为产品要求属本文提案 | 0922 转述:53；`wiki/00`:91 |
78
79## 3. 优先级（锚：能跟完一个真项目，白晨 0923 定）
80
81### P0 —— 缺一条这个项目就走不完（11 条）
82
83**入口**：A2 想法识别不进 P0，第一轮由用户主动点「新建项目」进入 A3。
84
85A3 需求澄清 → A4 立项 → B1 任务拆解 → B3 匹配（**简化版**：只给几个候选，不做完整三档）→ B4 派活与交接 → B5 推进与提醒 → B7 决策点回收 → C1 交付核对 → C3 结算记录；贯穿：D1 项目记忆、**D3 最小版本**（每步落一条「输入／选了谁／结果／耗时」）。
86
87**两条兜底**（P0 内必须有，否则线是断的）：派出去无人承接或承接后没动静时，助手提示用户**人工指定执行方**（B6 风险预警的完整版在 P1）；C1 核对不达标时，第一轮只提示用户、处置走人工（C2 在 P1）。
88
89串起来是一条完整的线：用户讲一个想法，最后拿到交付物、钱按现行流程结了。其中 **B4 与 D1 最容易被低估**——界面上看不见，少了它们整条线是断的。
90
91### P1 —— 凑合能跟完，但很快就要（7 条）
92
93A1 画像采集（先只用已有数据）、B2 里程碑编排（先只有任务列表）、B6 风险预警、C2 不达标处置、C4 项目收尾、C5 单项目复盘、D4 边界与安全。
94
95### P2 —— 以后做（6 条）
96
97A2 想法识别、A5 可行性预判、B3 完整三档分档、D2 质量与可信度管理（要有供给量才有意义）、C6 跨项目沉淀（要攒够项目）、多 agent 并行。
98
99### 若 10/16 前压不下（本文提案，待白晨定）
100
101P0 加现有流程对接、加助手交互载体，在约 9～12 个工作日且同期有工作台与交易两摊事的情况下，大概率做不完。**建议砍 B3**：P0 里 B3 的本质是「有一个执行方」而不是「匹配」，所以第一个项目可以直接**指定执行方**（官方能力或指定的人）替代匹配，力气全押「A4 立项 → B1 拆解 → B4 派活带上下文 → B5 跟踪 → C1 核对」这条骨架。匹配是撮合端的事，主干已定是陪跑。
102
103## 4. 范围外（本轮不做，写明后果）
104
105- 助手不做运营能力、不生产核心内容（`wiki/00`:44；白晨 0921 夜谈:515-524「碰了就不是 AI 创业平台了」）。
106- 不承诺经营结果（粉丝数、成交额），但要管质量与证据（0921 共识，`wiki/76`:113）。
107- **不做外部平台结果数据回流与定时触发**（吴梦赢 0921 夜谈:548、:629 提过「反馈是什么、定时发」）。后果：运营类项目的 C1 只能核「交付物有没有」，核不了「效果有没有」。
108- **接单者侧助手不做**（白晨 0921 夜谈:23 两重定位之「用平台：答疑、找适合我的单」）——本轮 22 条全是发单方视角。列第 6 节待定。
109- **用户上架自己的 agent／资源**不属助手能力，属供给侧（白晨 0921 夜谈:542、吴梦赢 :719）。
110- 「首要是足够聪明」（吴梦赢 0922 夜盘:146）是对助手理解力的要求，归技术模块映射文。
111- 不接支付宝／微信支付；结算走现有积分与金额对接（白晨 0922 夜盘:101）。
112- 助手跑在哪（运行底座）不在本文，原见分支 `docs/ai-assistant-runtime-reeval` 的 75 页（未合并；白晨 2026-09-24 表示这条分支不要了，已删除，最后提交 `6c911d40`）。
113- 助手的交互载体（对话框、画布、还是别的）不在本文，见第 6 节。
114
115## 5. 与既有材料的关系
116
117- **三种定位说法**（`wiki/03` 第 2026-09-22 节第 5 项）：本文以「陪跑为主、撮合一环」收口，**由白晨 0923 会话定**；0921「拆需求＋匹配是核心」的说法退为 B1／B3 两条能力，不再是主干。
118- **`wiki/76` 第三节四个无人回答的问题**：①拆解由谁负责 → 平台负责拆（B1，依据是白晨次日 0922 转述:53 的表态，不是 0921 那场的结论），拆得好不好进 D3 证据；②多 agent 汇聚 → 本轮不做；③只靠记忆太弱 → 答案是 A4 项目对象＋D1，不是记忆本身；④拆完效果不好怎么迭代 → C5／C6，本轮 P1／P2。
119- **包蕾的质询**（`wiki/76` 第四节）：「证明比直接用 ChatGPT 好」（:446）→ D3 承接归因；「告诉我最优路径并连接资源」（:611）→ 本轮不单列，并入 B1 拆解与 B3 匹配。
120- **吴梦赢的「运营工作台」描述**（:629）→ 拆进 B4「用户本人可为执行方」、B5 提醒、A4 项目对象三条；其中「反馈是什么」那一半按第 4 节不做。
121- **`wiki/76` 第七节「可验证增量价值」候选假设**：B4 上下文交接是它的直接落点，D3 是它的度量手段。
122
123## 6. 待白晨定
124
125| # | 问题 | 本文默认 | 备选 |
126|---|---|---|---|
127| 1 | **C1 与现行「提交即自动发尾款」的关系**：现有实现（制作与交付 spec:54）在提交事务里自动验收＋发尾款，助手的交付核对挡不住付款 | 不改结算时机，C1 退为事后评价，C3 只记录与提醒 | 恢复验收环节、尾款等 C1 通过后再发——需改 `2026-09-13-9月21日真实应用开发-design.md` 并登记 03 |
128| 2 | 10/16 前 P0 压不下时砍什么 | 砍 B3 匹配，指定执行方 | 砍 B5 提醒；或砍 C1 核对（只结算不核） |
129| 3 | 助手的交互载体 | 未定 | 对话框；白晨 0922 深夜提的画布（**若选画布，须同时重议多 agent 并行**——`wiki/80` 第 5.2 节已注两者是同一块问题）；两者都有 |
130| 4 | 第一个真项目是什么 | 未定；候选是教师伙伴自带运营预算发单（`wiki/80` 第四节） | 外包部任务；内部演示项目 |
131| 5 | 接单者侧助手（找适合我的单、平台答疑）做不做 | 本轮不做 | 加为贯穿项 |
132| 6 | D3 最小版本是否随 P0 | 是（理由：事后补不回来） | 严格按 P1（白晨 0921「证明成本很高」立场） |
133| 7 | 「官方能力兜底」第一批是哪几个 | 未定 | 按第一个真项目倒推 |
134| 8 | 吴梦赢提法的 6 条（A4／B2／B4 派活／B5／C2／C6）是否认领为已定 | 本文按待定 | 白晨一次性认领 |
135
136## 7. 依据
137
138**白晨 0923 会话五问与答案**（口头，无录音，工作层）：清单用途 → 先产品后技术；助手主干 → 陪跑为主、撮合一环；执行归谁 → 助手调度供给＋官方能力兜底；与现有线关系 → 叠在之上、能代用户操作平台；清单切法 → 按陪跑阶段。另认可：A3 两轮上限、A5 降级、多 agent 并行本轮不做、排序锚「能跟完一个真项目」、第一节与第二节能力表内容。
139
140**材料**：
141- `wiki/76-AI助手定位与首个验证场景之争-0921深夜对谈.md` 第三、四、七节
142- `wiki/77-伟华会转述-产品闭环与解耦工作台与10月16日节点-0922对谈.md` 第五节
143- `wiki/80-三个待办-工作台外部接入与交易与AI助手-0922深夜对谈.md` 第五节
144- `wiki/00-当前权威口径.md`:43-44、:50、:56、:91
145- `docs/superpowers/specs/2026-09-16-制作与交付全流程-design.md`:54（提交自动验收与尾款同事务）
146- 独立审查（2026-09-23 子代理，25 条发现：6 必须改／16 建议改／3 可不改，前两档已全部落实；要点见 `wiki/log.md` 同日条目）

2026 年 9 月 21—27 日工作汇报附件 · 取证日期 2026-09-28 · 原文 SHA-256：3c1acc975ba43900c406ee93e1e58646bcad5c74d3c7fc13afe7d166fbf40033