AI管理体系建议

创建人员：Codex

文件职责：记录对 D:\manage_system AI 工作流程管理体系的关键建议，用于后续讨论、整改和落地设计。

管理规范：本文只记录关键建议和主干设计，不记录边角料。后续如果形成正式方案，应同步到对应的体系说明、模板、规范文档中。

参考文件：

• 管理系统说明.md
• 管理体系说明.vsdx

1. 总体判断

当前体系方向是对的。

这不是普通项目管理工具，而是“AI 工作可审计系统”。核心价值不是只记录任务，而是让每个 AI 做过什么、为什么做、做到哪、产物在哪、谁审计过、问题有没有闭环，都能被追踪和复核。

当前文档已经覆盖：

• 公共文档目录
• 项目目录
• 数据归档
• 事项总纲
• 事项计划
• 工作日志
• 审计
• 存储体系
• 审核员规则
• AI 技能体系

下一步重点不是继续扩概念，而是把“事项从创建到审计关闭”的最小闭环跑通。

2. 先冻结事项数据模型

建议先把“事项”定义成系统里的第一主对象。

每个事项至少要有：

• matter_id：事项唯一 ID，长度不要太长。
• matter_name：事项名。
• background：事项背景和由来。
• goal：事项目标，必须能判断是否完成。
• source_chat_record：事项由来的完整聊天记录或引用路径。
• owner_ai：执行负责人。
• reviewer_ai：审核负责人。
• status：事项状态。
• current_conclusion：当前结论。
• current_blocker：当前阻塞原因。
• key_artifacts：关键产物路径。
• audit_status：审计状态。
• issue_refs：关联问题。

没有稳定的事项模型，后面的总纲、计划、日志、审计报告都会散。

3. 明确事项状态机

当前状态只写“暂停、进行中、未开始、完成、取消”还不够。

AI 协作里最关键的是审计和返工，所以建议冻结为：

未开始
-> 进行中
-> 待审计
-> 审计通过 -> 完成
-> 审计不通过 -> 修复中 -> 待复审 -> 审计通过 / 审计不通过
-> 暂停
-> 取消

建议状态字段不要自由填写，必须枚举化。

关键状态解释：

• 待审计：执行方认为事项已完成，等待审核。
• 审计不通过：存在阻断级问题或影响结论的问题。
• 修复中：执行方正在处理审计问题。
• 待复审：修复完成，等待审核员再次检查。
• 完成：审计通过且产物归档完成。

4. 总纲、计划、日志、审计报告要分工清楚

建议明确这些文档的边界：

事项总纲

回答：

• 为什么做？
• 要解决什么问题？
• 背景和原理是什么？
• 目标是什么？
• 当前结论是什么？

事项总纲不负责记录每一步细节。

事项计划

回答：

• 怎么拆步骤？
• 每一步谁做？
• 每一步目标是什么？
• 每一步状态是什么？
• 每一步产物是什么？

事项计划不负责写长篇实验结果。

工作日志

回答：

• 实际执行过程中发生了什么？
• 哪些关键节点完成了？
• 哪些临时判断发生了变化？
• 哪些异常、返工、阻塞出现过？

工作日志是过程痕迹，不替代最终结论。

审计报告

回答：

• 审计范围是什么？
• 审计依据是什么？
• 有什么问题？
• 问题是否阻断结论？
• 是否通过？
• 如果不通过，修复建议是什么？

审计报告必须区分真问题和非阻断建议。

数据归档

回答：

• 原始数据在哪里？
• 中间数据在哪里？
• 最终数据在哪里？
• 图、表、日志、压缩包在哪里？
• 哪些产物可以复现结论？

数据归档不是写结论，而是让结论能被追溯。

5. 增加机器可读总索引

Markdown 适合人看，但 AI 调度和全局查询最好有机器可读总表。

建议至少维护 3 张总表：

事项总表

建议文件：

data/matter_index.csv

核心字段：

• matter_id
• matter_name
• project_id
• owner_ai
• reviewer_ai
• status
• goal
• current_conclusion
• current_blocker
• matter_doc_path
• plan_doc_path
• audit_doc_path
• updated_at

步骤总表

建议文件：

data/step_index.csv

核心字段：

• step_id
• matter_id
• step_name
• owner_ai
• status
• goal
• result
• artifact_paths
• created_at
• updated_at

问题总表

建议文件：

data/issue_index.csv

核心字段：

• issue_id
• matter_id
• step_id
• issue_type
• severity
• description
• impact
• fix_suggestion
• owner_ai
• status
• created_at
• closed_at

文档负责解释，表负责检索、汇总和 AI 自动检查。

6. 审核员规则要加“真问题优先”

当前审核要求里“不要吹毛求疵”是对的，建议进一步冻结成硬规则：

审核只报会影响以下内容的问题：

• 事项目标是否达成。
• 结论是否可信。
• 流程是否闭环。
• 数据和产物是否可追踪。
• 是否存在未来函数、样本污染、关键逻辑错误。
• 是否存在无法复现或无法审计的问题。

不应把以下内容作为阻断问题：

• 命名轻微不统一但不影响追踪。
• 文档格式不够漂亮。
• 字段别名不同但语义可明确映射。
• 不影响结论的小型可读性问题。
• 可以后续优化的边角功能。

审核员输出问题时建议分级：

P0：阻断问题，必须修，否则结论不能用。
P1：高风险问题，影响结论可信度或后续复用。
P2：中低风险问题，建议修，但不阻断当前结论。
P3：可读性 / 优化建议，不进入修复阻断链。

7. 最小可运行闭环

建议 P0 阶段只做最小闭环，不要一开始做重系统。

最小闭环如下：

创建事项
-> 写事项总纲
-> 拆事项计划
-> 执行步骤并写工作日志
-> 归档产物和数据
-> 审核员审计
-> 发现问题则进入问题总表
-> 执行方修复
-> 审核员复审
-> 审计通过后关闭事项

P0 阶段需要的东西：

• 事项总纲模板。
• 事项计划模板。
• 工作日志模板。
• 审计报告模板。
• 数据归档模板。
• 事项总表。
• 步骤总表。
• 问题总表。
• 全局规范。

不建议 P0 就做复杂 UI、权限系统、自动调度器、数据库平台。

8. 分阶段落地建议

P0：文档和表格闭环

目标：不用开发复杂系统，也能跑通事项管理。

产物：

• 标准目录。
• 标准模板。
• 三张机器可读总表。
• 一套事项状态机。
• 一套审计分级规则。

P1：半自动生成

目标：AI 可以根据用户输入自动创建事项、计划、日志和审计模板。

产物：

• 创建事项脚本。
• 更新事项状态脚本。
• 新增问题脚本。
• 关闭事项脚本。

P2：仪表盘

目标：人能快速看到所有项目、事项、问题、阻塞、审计状态。

产物：

• 项目看板。
• 事项看板。
• 问题看板。
• AI 工作量和阻塞看板。

P3：调度和权限

目标：多个 AI 可以被系统调度，且不同项目、角色、文件有权限边界。

产物：

• AI 任务分配器。
• 审计分派器。
• 权限和锁机制。
• 自动归档和提醒。

9. 关键风险

风险 1：文档太多但没有主索引

如果没有总表，AI 每次都要翻大量 Markdown，容易漏。

处理建议：先建 matter_index.csv / step_index.csv / issue_index.csv。

风险 2：审计变成吹毛求疵

如果审核员把小格式、小命名都当 bug，系统会越跑越慢。

处理建议：审核问题必须按 P0-P3 分级，P2/P3 不得阻断事项关闭。

风险 3：事项没有目标就开始执行

没有目标就无法判断实验、开发、案例是否成功。

处理建议：事项总纲里的 goal 必填；目标不清时不得进入执行。

风险 4：产物归档但无法复现

只存最终结论，不存数据、脚本、日志，会导致无法审计。

处理建议：每个事项关闭前必须完成数据归档检查。

风险 5：AI 之间职责不清

执行 AI、审核 AI、观察员、代码 AI 如果职责混用，会导致谁都能改、谁都能判定通过。

处理建议：事项级明确 owner_ai 和 reviewer_ai，执行和审核尽量分离。

10. 当前最建议先做的事

下一步不要继续扩概念，建议先补 4 个模板和 3 张表：

模板

• common/pro-doc/事项总纲模板.md
• common/pro-doc/事项计划模板.md
• common/pro-doc/审计报告模板.md
• common/data-doc/数据归档模板.md

总表

• data/matter_index.csv
• data/step_index.csv
• data/issue_index.csv

然后用一个真实小事项跑一遍完整流程，验证是否能做到：

• 人能看懂。
• AI 能继续接力。
• 审核员能审计。
• 问题能闭环。
• 产物能归档。