资料页面

AI项目官网-版本计划详细报告

来源：/Users/ljn/Desktop/自动化搭建/AI生产线知识库/raw/source_docs/8_AI项目官网-版本计划详细报告.md

AI项目官网-版本计划详细报告

一、文档目的&期望

1、围绕 AI 项目官网 demo 验收后的阶段性判断，做团队内部信息同步和目标对齐。

2、围绕下阶段高频迭代计划，确认未来一个月的版本目标、交付节奏和优先级取舍。

3、围绕项目方法论、关键验收标准、真实项目试运行、组织侧推动等事项，寻求伟华专家意见和管理支持（伟华业务副总 & 内部产品专家身份）。

二、伟华在后续项目执行过程中的角色与事务定位:

| 事务 | 伟华角色 | 频次 | 伟华参与事务边界 |

|-|-|-|-|

| AI 生成结果抽检 | 副总 | 按需 | 按需抽样判断 AI 输出是否接近可接受水平，但不作为日常审核人 |

| 试用反馈 | 副总 | 按需 | 按需体验产品并提出关键问题，团队判断哪些反馈进入版本计划 |

三、团队对AI项目官网的阶段性判断

| 序号 | 阶段性判断 | 详细思考 |

|-|-|-|

| 1 | 当前优先做 30 分版本，先跑起来，再快速迭代 | 1、当下公司及AI赋能下，我们优先保证最快速度做出来。能接受质量很差的30分版本，不追求完美，甚至不追求合格后再发布。 2、在30分的版本上，我们会以工程的思维，做进一步完善，从会影响AI产出质量的多个维度去做补齐建设，包含但不限于公司积累的事务方法、优质案例提炼、各类知识库搭建、外部专业知识等。以快速迭代的方式进行。 3、关于“做好”：没有标准答案，也是提醒我们不要局限于从某个群体、或者某个工具上就能一劳永逸，保持快速迭代且开放的状态去积极、大胆的尝试和验证。 |

| 2 | 平台要适配不同质量的前置输入，而不是要求用户一开始就给完美材料 | 1、不同的前置来源，是会影响AI表现。但我们允许用户在实际使用过程中，较为灵活的给予不同的前置输入（eg.一句话、一个会议纪要等） 2、核心上，我们要做的其实是可以灵活根据不同的输入模式，做AI的自动分析和信息补齐。分析节点上先把认为会影响到项目分析质量的环节，作为标准流程固化进去。然后每个环节达到一定质量分数后，再进入下个环节执行，如果用户的前置输入已经能满足某些节点的产出要求，则可以灵活跳过。 |

| 3 | AI 项目官网要同时承载项目规划和项目管理，但 V1.0 先聚焦可信规划闭环 | 这里涉及三层关系：公司层级对所有项目的管理、具体项目的规划、具体项目自身的管理。三者彼此影响。短期先验证输入、分析、立项、目标拆解、审核反馈这条可信规划闭环。 |

| 4 | AI 风险控制要基于“事项影响力 + AI 准确率”重新定义 | 1、以AI为主的执行，需要重新定义围绕AI的风险控制。 2、AI的风险控制一：事务&决策的影响力，不同影响力给予AI的授权不同（eg.战略级决策需要人把关、执行级事务可根据AI准确性积极放权） 3、AI的风险控制二：AI在各类事务上的准确率。根据不同准确率制定细分的授权方案（eg.纯AI自主、人抽检、AI自主+人抽查、人主导+AI辅助等） |

| 5 | 平台建设有两条路线 | 1、现有方法论严格复制进AI会在最短时间内建设完成。 2、除方法论复制外，在工程角度做相关的补齐建设后，就会立刻启动AI模式下的更优路线/方案的尝试和验证 |

| 6 | 方法论、skill、知识库是平台核心资产，需要分阶段拆分和沉淀 | 团队会先把关方法论、skill、知识库等建设质量，并定义彼此的逻辑与规则，且做有效公开呈现，便于按需验收。 |

| 7 | 信息整理/蒸馏流程本身也要纳入平台能力 | 目前判断会把“信息整理/蒸馏流程”作为标准的步骤和能力纳入 |

| 8 | 当前漏斗池定义为“项目建议漏斗池” | 这里定义所谓的项目漏斗池，指的是项目建议漏斗池。而不是具体的项目执行的需求漏斗池。鼓励任何人、任何信息，跟项目有关的，都可以作为一种建议性质的项目输入补充，由AI+决策团队做进一步分析判断是否采纳。采纳后，即可启动AI进行完整分析和结合。 |

| 9 | 内部验证成熟后，接入 OPEN-Q 对外服务 | 这里需要把AI员工一起结合进来看，本质是作为成熟的AI解决方案，对外以AI员工的形式做包装和销售。并且可以赋能和引流open-q平台。 |

四、后续一个月平台版本交付详细计划

详细版本路线总览（每个版本启动时会同步该版本日交付目标）

|-|-|-|-|

| V0.2 | 6/8-6/12 | 1.0 方法论与最小生产链路确定 | 1、迭代、编排并沉淀好各个关键事务的skill； 2、技术框架LangGraph的框架模块搭建、接入； 3、合并skill和技术框架，跑出生产级别测试demo样例； |

| V0.3 | 6/13-6/16 | 全量项目数据接入与批量 AI 生成 | 1、接入Rag，打通打通数据库，反哺意图识别源； 2、加入AI对抗性审核+人工介入节点接入+AI自我迭代机制构建； 3、接入顶层Agent 战略系统； 4、接入当前已有项目数据，完成全量项目 AI 分析、生成和初步质检 |

| V1.0 | 6/17-6/18 | 内部生产级 AI 项目官网正式发布 | 1、环境具备所有当前已有项目的 AI 生成数据，可正式开放内部使用 发布口径：真实项目数据可访问，核心 AI 生成链路可演示/可使用，项目管理含删除能力，生产环境、权限、数据备份、回滚方案、内部验收清单和发布说明齐备。 |

| V1.1 | 6/19-6/26 | 发布后质量优化与多项目管理增强 | 1、基于正式发布后的真实数据，优化方法论、工作流、权限、规则等 |

| V1.2 | 6/27-7/5 | 验收闭环 + AI 授权风险控制 + 试运行复盘 | 1、形成内部试运行闭环，并沉淀下一阶段优化方向 |

V0.2-1.0版本每日交付计划

|-|-|-|-|

| 6/8 周一 | 冻结 V0.2 范围与单一真相 | 1、复核 PM-04 / \_rebuild / 20-skill canon，确认最小链路只覆盖“战略意图到中短期验收闭环”的骨架； 2、将项目集治理链归入“项目集主数据与 scope 归属前置能力”； 3、临时插入“删除项目”功能：项目管理列表支持删除入口、二次确认、删除后列表刷新、避免误删提示；后端提供 DELETE /api/projects/{pid} 或等价能力。 | 形成 V0.2 范围裁决；最小链路节点、issue 依赖和删除项目临时插入项清晰可验收。 |

| 6/9 周二 | 方法论链路沉淀 | 1、把 20-skill canon 整理成最小生产链路版：战略意图、立项前置分析、立项章程、三根基、逐环审核、中短期/阶段/周/事务、验收与复盘； 2、明确每一步输入、输出、AI 角色、是否需要审核、是否会 interrupt； 3、将项目集 definition / boundary / strategy_focus 补充为 scope-judge 权威输入； | 交付《1.0 方法论最小链路说明》：每个节点有输入、输出、验收标准，可交给研发落图。 |

| 6/10 周三 | LangGraph 技术底座确定 | 1、确定 State、reducer、checkpointer、gateway node、PipelineStage 台账、SSE 的技术骨架； 2、确认 gateway.call 保护性平移，不引入 LangChain / PydanticAI； 3、定义 demo 图：manager_intent → scope_judge → charter_analysis → pool_score → charter_decide → project_create； 4、确认项目集元数据只先服务 scope-judge，删除项目作为管理端独立闭环，不阻塞 LangGraph 主链。 | 交付《LangGraph 最小生产链路技术方案》：包含图节点清单、State 字段、checkpointer/thread_id、计费台账、SSE 进度、<80 interrupt 处理。 |

| 6/11 周四 | 方法论 + 技术框架合并成 demo 链路 | 1、将最小链路图写成端到端验收脚本口径； 2、提交战略/管理者意图后，能完成项目集归属、立项分析、评分、章程、建母项目、三根基占位、中短期目标占位； 3、明确蓝海情报在 V0.2 的位置：作为立项前置分析/章程输入字段与 prompt 依赖，不追求外部情报系统全接入； 4、demo 数据至少包含 2 个 active 项目集 + 1 个 inactive 项目集，并验证 inactive 不参与路由； 5、增加管理端冒烟：新建/查看项目列表/删除测试项目/刷新后不可见。 | 交付《V0.2 Demo 验收脚本》：一条 happy path、一条 <80 awaiting-human path、一条 inactive portfolio 不路由 path、一条删除项目管理端冒烟。 |

| 6/12 周五 | 周验收与下周承接 | 1、汇总本周方法论、技术底座、demo 链路、项目集治理前置能力； 2、标注 V0.2 达成项：方法论确定、LangGraph 关键模块确定、最小生产链路 demo 样例确定； 3、输出 V0.3 承接：RAG/数据库接入、AI 生成批量化、真实项目数据接入、全量质检； 4、更新风险：完整项目集管理全链如果全部做会膨胀，本周只保留项目集元数据与 active-only 路由价值进入 V0.2。 | 交付《6/8-6/12 V0.2 周验收报告》：包含完成清单、未纳入范围、V0.3 backlog、风险和决策记录。 |

| 6/13 周六 | V0.3 启动与数据接入底座 | 1、冻结 V0.3 范围：真实项目数据接入、RAG/数据库联通、批量 AI 生成、初步质检； 2、梳理当前已有项目数据字段，确定项目、项目集、前置信息、AI 输出物之间的映射关系； 3、打通数据库读取与 RAG 检索的最小路径，先服务意图识别、立项分析和项目上下文补齐； | 数据库/RAG 能读取至少一批真实或种子项目数据；字段映射表完成；删除项目能力在测试数据上通过冒烟且不影响主链数据。 |

| 6/14 周日 | 全量项目数据接入与首批 AI 分析 | 1、接入当前已有项目数据，完成首批项目入库、清洗、去重和基础校验； 2、跑通项目级 AI 分析：输入来源识别、项目归属判断、关键信息缺口、风险点和下一步建议； 3、形成缺失字段、异常项目、低置信度项目的问题清单； 4、定义人工介入触发规则：低分、缺字段、冲突信息、项目集归属不确定时进入待确认。 | 至少一批真实项目完成 AI 分析；每条输出可追溯输入来源；失败或低置信度项目进入问题清单并有重试/补数路径。 |

| 6/15 周一 | 批量 AI 生成与质检机制 | 1、在真实项目数据上批量生成项目规划输出物：立项分析、章程、三根基、中短期目标/阶段目标占位； 2、接入 AI 对抗性审核节点，对生成结果做事实一致性、目标完整性、风险遗漏、项目集归属合理性检查； 3、建立初版质检清单：通过、需人工补充、需重跑、暂不发布四类结果； 4、沉淀低质量样本，反向补充 prompt、skill 和知识库缺口。 | 代表性项目批量输出可查看；AI 质检能给出通过/不通过与原因；低质量样本进入优化 backlog；核心输出具备内部演示价值。 |

| 6/16 周二 | V0.3 验收与 V1.0 发布候选准备 | 1、完成 V0.3 周期验收：真实项目接入、批量生成、AI 质检、人工介入规则、删除项目回归； 2、冻结 6/18 发布范围，只保留影响内部生产级首版的 P0/P1 问题； 3、准备生产环境、权限、数据备份、回滚方案、监控项和发布检查清单； 4、明确 V1.0 不承诺复杂项目集全功能治理，只承诺真实数据可访问、核心 AI 链路可用、项目管理基础动作可用。 | 输出《V0.3 验收报告》和《V1.0 发布候选清单》；核心链路无 P0 阻塞；P1 问题有负责人、截止时间和降级方案。 |

| 6/17 周三 | V1.0 发布候选冻结与内部验收 | 1、冻结 V1.0 RC 版本，不再临时扩范围； 2、部署内部 RC 环境，完成登录/权限、项目列表、项目详情、AI 生成数据查看、删除项目、数据备份/回滚的端到端验收； 3、准备发布说明、内部使用口径、已知问题、反馈入口和应急联系人； 4、组织小范围内部试用，收集阻塞级反馈并当日修复或明确发布后处理。 | RC 环境可访问；内部验收清单通过；P0 清零，P1 有处理安排；发布说明和反馈通道准备完成。 |

| 6/18 周四 | 内部生产级 AI 项目官网正式发布 | 1、完成生产环境发布并开放内部使用； 2、验证真实项目数据可访问，核心 AI 生成链路可演示/可使用，批量生成结果可查看； 3、验证项目管理基础能力：项目列表、项目详情、删除项目二次确认与安全限制； 4、发布 V1.0 发布说明，建立当天监控、反馈收集、问题分级和回滚响应机制； 5、将发布后质量优化、多项目管理增强、权限/规则完善纳入 V1.1 backlog。 | 内部用户可进入平台并查看真实项目 AI 数据；核心链路可跑通；删除项目能力受控可用；监控、反馈、回滚责任人明确；V1.0 内部生产级首版发布完成。 |

附件1：伟华在会议中提到的12个核心观点如下：

观点1：AI把项目“做出来”和“做好”是两回事

当前 demo 已经证明AI能生成项目内容，但下一步要回答的是：怎样的前置输入、方法论、知识库和人机协作机制，才能让 AI 生成的项目真正符合公司的项目管理逻辑。

观点2：AI的前置输入来源会决定 AI 后续表现，必须被追溯和比较

伟华特别关注项目输入到底来自哪里：临时想法、个人规划文档、批量历史会议/白皮书资料、经过标准化处理的 Markdown 文档等。不同输入会导致后续项目拆解变形，所以平台/团队要能判断哪种输入方式更适合做好项目。

观点3：项目规划和项目管理不能分开

伟华认为管理的本质是在“资源有限、风险存在、目标要达成”的情况下做判断、取舍和调整。所以项目规划阶段本身就已经包含项目管理逻辑，不能把规划和管理割裂

观点4：过去项目管理中的时间周期、阶段验收，本质是不信任带来的风险控制

他举“AI 分身金伟华”的例子，是想说明：如果足够信任执行主体，就不需要天天管理。现在之所以需要月度、周度、甚至日度检查，是因为人或 AI 的判断还没有被充分证明。所以项目管理机制要随着对 AI 的信任程度变化。

观点5：人在 AI 项目管理中的作用有三类

第一，把公司方法论给 AI；第二，把企业导向、业务边界、优势劣势、价值观、忌讳等知识/提示词体系给 AI；第三，在关键节点对 AI 输出进行调整、审核、批注。

观点6：伟华认为当前他不优先验收结果，而是优先验收“方法论有没有正确进进入AI

如果团队不能判断 skill/Markdown 是否符合公司方法论，那伟华就要亲自验收；如果团队有信心，他可以先信任团队，再通过抽检结果来反向追责。

观点7：AI 要被信任，需要前置满足三件事

伟华在建立一条信任链：先确认框架是否正确，再确认团队是否把方法论和知识库正确写入 AI，最后确认 AI 基于这些内容做出的判断是否接近正常 P7。

观点8：AI项目官网平台建设有两条路线，但当前先走保守可控路线

路线一：把现有公司方法论严格复制进 AI。

路线二：让 AI 基于公司情况和外部知识重新生成一套更好的项目管理方法论。

伟华本人认同第二种更理想，但判断团队目前未必具备直接做第二种的能力，所以决策是：先按第一种，把现有方法论分阶段、分 skill 严格落进去。

观点9：方法论不是一个简单的prompt，而是平台的核心资产，skill 必须分阶段拆开

伟华要求把理想化状态、中短期目标、子目标、版本计划、验收节点等拆成独立阶段，每个阶段有独立 skill 和知识库，这样后续调优只影响当前阶段，不会整体失控。

观点10：输入给AI的前置信息，包含原始 Markdown/信息梳理本身也是方法论的一部分

输入给 AI 的不只是原始信息，信息被整理、蒸馏、批注、确认、结构化成 Markdown 的过程，本身也是方法论的一部分。因此“项目信息如何被整理、批注、确认、归类”也要纳入平台前置流程。

观点11：任何人、任何信息都可以进入漏斗池，但不能直接改变项目，必须经过决策判断

项目成员、外部信息、会议讨论、AI 搜索到的新闻、领导一句话，都可以作为输入进入漏斗池。但是否接受、重要度如何、优先级如何、是否进入正式项目前置信息，需要由决策团队判断。只要进入正式前置信息，就意味着团队认为它是正确且有效的项目依据。

观点12：AI项目官网当前首先是公司级项目治理基础设施，但未来要具备对外开放能力

当前阶段，伟华认为平台的目标用户首先是公司，用来承载公司内部项目从信息输入、立项、规划、目标拆解到管理推进的完整逻辑。但从长期看，平台还需要考虑上架 OPEN-Q，开放给外部用户或企业建立自己的项目，成为项目立项与 AI 项目管理TO B服务。

附件2：团队针对伟华观点的详细思考：

| 伟华观点/需求 | 团队判断结论 | 团队详细思考 |

|-|-|-|

| AI 把项目做出来和做好是两回事 | 认同观点，同时做补充说明 | 1、当下公司及AI赋能下，我们优先保证最快速度做出来。能接受质量很差的30分版本，不追求完美，甚至不追求合格后再发布。 2、在30分的版本上，我们会以工程的思维，做进一步完善，从会影响AI产出质量的多个维度去做补齐建设，包含但不限于公司积累的事务方法、优质案例提炼、各类知识库搭建、外部专业知识等。以快速迭代的方式进行。 3、关于“做好”：没有标准答案，也是提醒我们不要局限于从某个群体、或者某个工具上就能一劳永逸，保持快速迭代且开放的状态去积极、大胆的尝试和验证。 |

| 前置输入来源会影响 AI 表现 | 认同这个说法，同步补齐更多的逻辑 | 1、不同的前置来源，是会影响AI表现。但我们允许用户在实际使用过程中，较为灵活的给予不同的前置输入（eg.一句话、一个会议纪要等） 2、核心上，我们要做的其实是可以灵活根据不同的输入模式，做AI的自动分析和信息补齐。分析节点上先把认为会影响到项目分析质量的环节，作为标准流程固化进去。然后每个环节达到一定质量分数后，再进入下个环节执行，如果用户的前置输入已经能满足某些节点的产出要求，则可以灵活跳过。 |

| 项目规划和项目管理不能分开 | 认同 | 1、这里其实有三个概念，公司层级对所有项目的管理、具体项目的规划、具体项目自身的管理 2、这三个关系彼此影响。 |

| 时间周期和阶段验收本质是不信任人带来的风险控制 | 认同说法，并补齐团队观点 | 1、以AI为主的执行，需要重新定义围绕AI的风险控制。 2、AI的风险控制一：事务&决策的影响力，不同影响力给予AI的授权不同（eg.战略级决策需要人把关、执行级事务可根据AI准确性积极放权） 3、AI的风险控制二：AI在各类事务上的准确率。根据不同准确率制定细分的授权方案（eg.纯AI自主、人抽检、AI自主+人抽查、人主导+AI辅助等） |

| 人在 AI 项目管理中有三类作用 | 认同，并补齐团队观点 | 1、核心是我们追求极致碎片化的工程思路，认同并坚信碎片化下的AI能进一步可控和提质。 2、除了把公司方法论教给AI、把相关信息/体系给AI、对AI做调整/审核/批注外，还有一块是要保证用的AI技术是最新最强的。 |

| 当前优先验收方法论是否进入 AI | 认同 | 团队会先把关方法论、skill、知识库等建设质量，并定义彼此的逻辑与规则，且做有效公开呈现，便于按需验收。 |

| AI 被信任需要三层信任链 | 认同，并补齐团队观点 | 围绕信任的判断，需要进一步补齐标准与逻辑，更多以实际数据/案例为主做客观分析和持续监测，而不完全只把专家的主观结论做标准。 |

| 平台建设有两条路线 | 认同方向 | 1、现有方法论严格复制进AI会在最短时间内建设完成。 2、除方法论复制外，在工程角度做相关的补齐建设后，就会立刻启动AI模式下的更优路线/方案的尝试和验证 |

| 方法论是核心资产，skill 要分阶段拆 | 认同方向 | 认同不能用一个大 prompt 承载全部项目管理逻辑。后续需要按关键阶段拆 skill。并且这些Skill应该是平台核心资产之一。 |

| Markdown/信息整理本身也是方法论 | 认同，本质上分析步骤&方法之一 | 目前判断会把“信息整理/蒸馏流程”作为标准的步骤和能力纳入 |

| 任何人、任何信息都可以进入项目漏斗池 | 认同方向，并补齐团队观点 | 这里定义所谓的项目漏斗池，指的是项目建议漏斗池。而不是具体的项目执行的需求漏斗池。鼓励任何人、任何信息，跟项目有关的，都可以作为一种建议性质的项目输入补充，由AI+决策团队做进一步分析判断是否采纳。采纳后，即可启动AI进行完整分析和结合。 |

| 当前内部使用，未来上架 OPEN-Q | 作为远期方向 | 这里需要把AI员工一起结合进来看，本质是作为成熟的AI解决方案，对外以AI员工的形式做包装和销售。并且可以赋能和引流open-q平台。 |

附件3：文档版本管理记录

|-|-|-|-|-|

| 暂无 | | | | |