教育 · AI 协作PROJECT FIELDNOTES
← 项目总览DELIVERY ATLAS / 落地安排

从公司框架，
到协作落地。

先看清谁负责、业务怎么走，
再把任务交给平台。

当前：资料与框架对齐
查看落地全图 ↓
概念插图：人的规划通过协作流程，形成可检查的执行结果
协作概念示意 · 非实际部署图
说明网页与文档已建立真实调度与消息接入尚未实现
已选方向 / 内部 AI 协作

把落地安排，推进到第一轮试跑。

从一项真实需求出发，逐步完成任务拆解、执行与验收的交接。

进入项目推进 →
01

先交付三张相互对应的图

初始框架阶段的建议产物：职责图、业务流程图、平台协作图。

产物 01 / 公司职责图

标清职责与待认领岗位

方向判断岗位需求职责边界

对照现有人员，标出已明确与待确认的责任。

→责任落到业务
产物 02 / 业务流程图

标清每一环的交付

输入资料交接产物验收标准

以会议中的业务链为基础，补齐输入、产物与标准。

→规则进入平台
产物 03 / 平台协作图

标清任务如何流转

资料权限调度执行进度结果

映射业务环节，画出派发、检查、退回与汇报。

业务主链：内容触达 → 9.9 元入口 → 三天直播课 → 后续产品 / 陪跑 ↗
公司与组织背景 →业务方向与完整流程 →平台六项职责 →

初始框架与 Demo 需要王栋判断方向：A 00:24:00–00:24:56。三张图是整理建议，不代表岗位与方案已经确定。

02

按这条路线推进

点击阶段查看输入、动作与产物。顺序来自会议，具体展开为整理建议。

↳ 逐功能验收贯穿每次交付 ↲
01 / 资料与框架

把职责与规则对齐

  1. 整理资料业务 / 会议 / 设备
  2. 三层框架公司 / 业务 / 平台
  3. 方向反馈王栋参与判断
可检查的产物三层图 · 资料目录 · 未决问题

先明确负责人、输入、输出、检查标准与更新机制。未定项保留待确认。

展开动作、交付物与会议依据

原文依据：A 00:03:43–00:04:45、00:21:17–00:25:27。

会议要求

先了解既有业务和资料，把公司、人员、AI 及其工作规则写清楚；初始架构需要王栋介入判断。

需要准备

已有业务资料、五份会议转写、当前网页与文档，以及各设备中尚未梳理的内容。

具体展开 整理建议

  1. 按业务素材、个人资料和客户要求分别梳理，标出来源、缺失和前后变化。用公司、业务、平台三层图对齐职责与规则；每条流程补齐负责人、输入、输出、检查标准与更新机制，未确认项保持待定。
  2. 把人的职责关系与 AI 调度关系分开，写明谁做什么、产物怎么管理、为什么这样管理。
  3. 把知识库更新、权限、Agent 审核、故障兜底作为基础规则一起讨论。

可检查的产物 建议

建议形成资料目录、初始框架、规则说明及未决问题清单；这四项是为了落实会议诉求的文档组织方式。

参与与分工

由王栋判断框架是否对应真实诉求；落尘负责平台搭建，王子是 FDE；资料整理协作与业务确认由相关人员另行认领。

如何判断可以继续

能说明“做什么、怎么做、为什么这样做”，且框架方向得到明确反馈。现有说明页不等于已获确认。

02 / 结构 Demo

用一个任务展示全程

  1. 需求进入场景与资料
  2. 结构演示派发 / 检查 / 退回
  3. 结果展示进度 / 产物 / 反馈
可检查的产物可演示的结构 · 反馈清单

王栋判断是否符合诉求，再确认真实开发范围。结构 Demo 不代表功能已经实现。

展开动作、交付物与会议依据

原文依据：A 00:24:00–00:24:56。

会议要求

可以先做没有真实功能的结构 Demo，让王栋判断是不是想要的，再继续开发。

需要准备

已讨论的初始框架、老板需要看到的信息，以及 Demo 要展示的场景。

具体展开 整理建议

  1. 围绕一个具体需求展示业务环节、责任人、输入资料、任务派发、结果查看与退回路径；未确定的责任人明确标为待认领。
  2. 把进度与结果展示给王栋，解释哪些操作只是结构演示。
  3. 记录方向反馈，再决定修改什么、哪些功能进入开发。

可检查的产物 建议

建议交付可演示的结构页面、演示说明与反馈清单；不要用示例任务冒充已执行任务。

参与与分工

王栋参与结构判断；落尘负责平台 Demo 搭建；讲解安排与业务验收人另行确认。

如何判断可以继续

王栋能够判断是否符合诉求，团队明确下一步开发范围。Demo 展示通过与真实功能验收分别记录。

03 / AI-to-AI

跑通真实任务链

  1. 选定任务输入与结果标准
  2. 隔离执行按需配置 Agent
  3. 检查交付结果可追溯、可退回
可检查的产物一条实际任务链 · 执行与检查记录

岗位、群入口、权限隔离、并行需求分别确认；Agent 数量由实际任务决定。

展开动作、交付物与会议依据

原文依据：A 00:36:06–00:41:24；兜底见 A 00:14:42–00:15:51、00:44:11。

会议要求

优先 A-to-A，顺序推进并行开发；只有一个总头，负责派活和验收，不做具体工作。

需要准备

确认后的结构、一个待选择的真实任务、任务结果标准，以及可用的设备、模型和资料。

具体展开 整理建议

  1. 从人的需求出发，由总调度派发，执行任务相互隔离。分别确认业务岗位、消息入口、数据与权限隔离、并行需求，再决定执行 Agent 的数量和运行方式；会议确定的 AI-to-AI 优先方向保持不变。
  2. 按任务完成测试、审核；代码类任务还涉及仓库提交、合并与审批。
  3. 设置细分验收，汇总到总验收；不通过的结果退回修改。
  4. 保留故障兜底与人工介入，老板查看进度和结果，不亲自操作总调度。

可检查的产物 建议

建议用一条实际任务链展示需求、派活、执行产物、审核结果与退回记录；具体存储结构尚待设计。

参与与分工

落尘负责平台搭建及调度链实现；首轮围绕会议需求到执行验收展开，具体任务与业务验收人待确认。

如何判断可以继续

能看到实际派活和结果，并能在不满足要求时退回修改。AI 通过后，人的业务判断仍保留。

04 / 逐功能验收

贯穿每一次交付

  1. 对照需求检查实际产物
  2. 人的反馈通过 / 退回
  3. 更新规则修改后重新检查
可检查的产物验收记录 · 规则与流程修改项

AI 检查通过后仍保留人的业务判断；具体人工验收人与维护责任待确认。

展开动作、交付物与会议依据

原文依据：A 00:34:50–00:35:20、00:40:01–00:40:54。

会议要求

每个功能都要验收，也可以批量验收。AI 验收通过不等于人满意，仍需检查标准或执行环节。

需要准备

原需求、对应产物、AI 检查结果，以及实际使用者的反馈。

具体展开 整理建议

  1. 逐功能对照结果，而不是只看写了代码或运行了 Agent。
  2. 不满意时指出具体问题，例如配图、文案标准或格式，再交回修改。
  3. 区分需求标准不清、执行结果不符和审核失效，按问题继续优化。
  4. 每项结果得到确认后继续推进，并将有效反馈更新到对应规则或流程；维护责任待确认。该原则适用于每次交付，而非最后一次总验收。

可检查的产物 建议

建议记录功能名称、原需求、产物、检查结果、人的反馈、结论、修改事项、确认人和日期。

参与与分工

具体功能的人工验收人尚未指定；不能默认全部由老板逐条管理，也不能以 AI 自检替代人的结果判断。

如何判断可以继续

每项功能有通过或退回的明确反馈。当前没有真实平台功能通过验收的记录。

03

一个任务，怎样被完成

关系图按会议整理。总头负责派活和总验收，不承担具体执行。

人

提出需求 · 看进度与结果 · 反馈修改

↓ 需求与标准↑ 结果与待决事项
唯一总调度

拆解与派发 → 汇总检查 → 总验收

执行任务 A独立任务环境
执行任务 B按并行需求配置
细分检查测试 / 产物核对
↶ 不通过 → 退回修改 → 重新检查
故障兜底与人工介入贯穿执行。AI 通过后，人的业务判断仍保留。
会议依据与实现边界

A 00:14:42–00:15:51、00:36:06–00:41:24、00:44:11。当前未实现；代码任务另含 Git 提交、合并与审批。具体人工验收人待确认，不能默认老板逐条操作总调度。

用例

先选一个任务跑通

首轮已选内部 AI 协作：从会议需求到执行验收。公众号内容作为后续场景。

会议助手

首轮方向
  1. 01已有转写
  2. 02提炼需求
  3. 03参与人确认
  4. 04助理执行
  5. 05次日汇报

B 00:12:21–00:15:23。待明确会议、助理、接收确认与汇报方式。

公众号内容

后续场景
  1. 01账号与资料
  2. 02文章与配图
  3. 03检查标准
  4. 04反馈修改
  5. 05授权后发送

A 00:40:25–00:40:54。讨论示例；账号接口、内容标准与发布权限待确认。

04

开工前，把任务与资源落实

落尘负责平台搭建；以下准备动作需落实具体任务、业务验收人与日期。

01 / 认领任务

明确谁执行、谁验收、谁维护

按具体模块认领责任，再商定交付物和日期。

检查结果：每项任务都有责任人与验收人
02 / 确认环境

从现有设备中选择试跑环境

核对配置、占用、既有资料和可使用范围，再安排任务。

检查结果：目标环境和使用权限已确认
03 / 验证接入

核验会员、接口与账号

核对会员有效期、席位与使用权限；分别验证 API 权限和实际消息链。

检查结果：留下可核对的连接与试跑结果
查看公司状况与人员职责 →查看已有设备与数量 →查看会员与账号资源 →

准备动作依据 A 00:36:46、00:43:44–00:44:11；B 00:25:31–00:26:04、00:46:25–00:46:57。检查结果为整理建议，平台搭建已由落尘认领，实际环境与接口仍待验证。

飞书 / 微信接入：已有线索与核验事项

会议将飞书和微信作为入口讨论，未确定接入先后顺序或统一产品版本。

飞书 / 微信 → 中间件 → 执行端

会议比较过多层转发与直接通过“CC contact”连接 Codex 的做法。

中间件准确名称、版本、部署位置仍需确认；会议名称不能直接当成已选定产品。

依据：A 00:06:28–00:08:30。

已有第三方微信接口

会议称第三方提供接口，需要继续调试、测试和开发。

接口供应商、授权范围、收发能力及测试结果待核验；没有本项目已接通的证据。

依据：B 00:46:25–00:46:57。

05

验收之后，才有下一步

每个功能都对照原需求与实际产物；当前尚无真实功能验收通过记录。

  1. 原需求与产物对照检查
  2. AI 检查细分与总验收
  3. 人的结果判断通过或提出修改
✓

通过

记录结果 → 继续推进

↶

退回

标准 / 执行 / 审核问题 → 修改 → 重新检查

首期范围与后续方向

基础框架：权限、兜底、资料规则、Agent 审核。

优先：AI-to-AI 派活、执行与验收。

首轮：会议需求到执行验收；内容、客服与考核后续确认。

暂缓：成本审计；转写复用，不优先提速。

后续业务：录播课、社群与客户在线平台，功能和日期未定。

A 00:34:50–00:35:20、00:36:25、00:37:19、00:40:01–00:40:54；B 00:14:35–00:15:23；D 00:06:26–00:07:55。

查看六项需求的当前验收状态
N01会议共识与任务跟进已在会议提出；本仓库未实现
N02AI-to-AI 派活、执行与验收已在会议提出；本仓库未实现
N03资料与输出管理已在会议提出；本仓库未实现
N04权限、兜底与 Agent 审核已在会议提出；本仓库未实现
N05高频工作与内容协作已在会议提出；本仓库未实现
N06进度、日报与考核已在会议提出；本仓库未实现

建议记录：功能、原需求、产物、检查结果、人的反馈、结论、修改项、确认人、日期。

下一次对齐

六件事，持续对齐

平台负责人和首轮方向已明确，继续落实样本、验收、资源与时间。约两周是会议估计，未形成个人截止日。

Q01

资料与框架

资料完整性 / 方向反馈

待确认
Q02

人员分工

平台搭建：落尘；业务验收 / 维护待明确

部分明确
Q03

首轮试跑

会议需求 → 执行验收；具体任务待填写

方向已定
Q04

验收标准

通过条件 / 退回规则

待确认
Q05

接入与资源

中间件 / 设备 / 权限

待确认
Q06

范围与时间

版本范围 / 认领后的安排

待确认

文档与原文依据

落地安排文稿 ↗会议对照规划 ↗待确认清单 ↗需求与验收记录 ↗公司与设备清单 ↗
查看会议来源与核对说明

A · 《AI公司搭建AI管理系统项目沟通讨论》

B · 《AI项目团队开发讨论与业务规划会议记录》

C · 《AI时代的创业、教育与行业变革讨论》

D · 《线下聚餐讨论AI创业、项目搭建与行业见闻》

E · 《对AI服务行业割韭菜乱象与合规风险的讨论》

全部为 2026-09-26 本地会议转写。正文以原文时间定位；身份以用户补充为准，不跨录音按说话人编号认人。E 用于核对交付背景，未将闲聊中的行业或法律判断写成平台制度。原始转写不上传仓库。

文档链接指向私有仓库，需要访问权限。本页用于查阅，不会实际派发任务或修改验收状态。