| common/ai-workplace/AI工作空间创建指南.md | ●●●●● patch | view | raw | blame | history | |
| common/ai-workplace/目录导读.md | ●●●●● patch | view | raw | blame | history | |
| common/ana-doc/案例审核规范.md | ●●●●● patch | view | raw | blame | history | |
| common/dev-doc/编码规范.md | ●●●●● patch | view | raw | blame | history | |
| common/exp-doc/实验审核规范.md | ●●●●● patch | view | raw | blame | history | |
| common/pro-doc/mbx.system.yaml | ●●●●● patch | view | raw | blame | history | |
| common/project-doc/项目环境创建指南.md | ●●●●● patch | view | raw | blame | history | |
| common/project-doc/项目规范.md | ●●●●● patch | view | raw | blame | history | |
| common/project-doc/项目配置清单模版.md | ●●●●● patch | view | raw | blame | history | |
| 全局规范.md | ●●●●● patch | view | raw | blame | history | |
| 管理系统说明.md | ●●●●● patch | view | raw | blame | history |
common/ai-workplace/AI工作空间创建指南.md
@@ -1,9 +1,9 @@ # AI 工作空间创建指南 创建人员：Codex 文件职责：指导项目管理员在某个项目中为指定 AI 创建工作空间、分配一个或多个角色，并生成该 AI 的 `工作说明.md`。 文件职责：指导项目管理员在某个项目中为指定 AI 创建工作空间、分配一个或多个角色，并生成该 AI 的 `工作说明.md` 和 `项目问题反馈.md`。 管理规范/模板：../../全局规范.md；../project-doc/项目规范.md；../project-doc/项目配置清单模版.md。 引用文件：../../全局规范.md；../project-doc/项目规范.md；../project-doc/项目环境创建指南.md；../project-doc/项目配置清单模版.md。 引用文件：../../全局规范.md；../project-doc/项目规范.md；../project-doc/项目环境创建指南.md；../project-doc/项目配置清单模版.md；项目问题反馈范本.md。 记录方式：通用创建指南；AI 工作空间、角色分配、工作说明或校验口径变化时更新本文。 ## 1. 使用场景 @@ -14,6 +14,7 @@ 1. 在某个项目里创建该 AI 的工作空间。 2. 根据该 AI 在项目中的一个或多个角色，生成或更新入口索引型 `工作说明.md`，让该 AI 快速知道自己的职责边界、目录入口和必须阅读的体系文档。 3. 创建 `项目问题反馈.md`，供该 AI 反馈项目协作中的重大阻塞、权限/流程问题和反复返修问题；写法参考 `项目问题反馈范本.md`。 本指南不替代项目体系、需求体系、开发体系、实验体系、案例分析体系或数据体系的创建指南。它只负责“AI 人员入场和角色配置”。 @@ -131,6 +132,7 @@ 创建 ai-<ai_name>/draft/ 创建 ai-<ai_name>/worklog/ 创建 ai-<ai_name>/工作说明.md 创建 ai-<ai_name>/项目问题反馈.md ``` 目录职责： @@ -142,15 +144,37 @@ | `draft/` | 未进入正式体系的草稿 | | `worklog/` | AI 私有过程记录，不能替代正式执行日志 | | `工作说明.md` | 该 AI 在本项目里的角色入口卡和路由说明 | | `项目问题反馈.md` | 该 AI 私有的项目协作问题反馈入口，只记录影响项目或体系进展的重要问题 | AI 工作空间里的内容默认不是正式产物。任何内容要进入正式事项，必须迁入对应体系正式目录，并在对应总纲、设计、执行日志、结果索引或审计报告中记录。 ### 4.2 不能做的事 ### 4.2 项目问题反馈.md 使用边界 `项目问题反馈.md` 是 AI 私有反馈入口，不是正式审计报告，也不是项目级问题主账。它的项目治理规则以 `../project-doc/项目规范.md` 为准，写法参考 `项目问题反馈范本.md`。 适合写入： 1. AI 在项目协作中遇到的重大流程阻塞、权限边界不清、角色配置错误或体系入口缺失。 2. 会影响整个项目或某个体系推进的重要协作问题。 3. 审核员发现同一事项反复返修仍出现同类问题，通常大于等于 3 次，需要提醒项目管理员介入。 4. AI 首次阅读工作说明后发现的职责、权限、入口或规范引用不清问题。 不适合写入： 1. 普通小问题、一次性笔误、个人临时草稿事项。 2. 正式审计结论。正式审计结论仍写对应体系审计报告。 3. 非审计来源且需要项目级闭环的问题。此类问题仍写 `项目问题记录.md`，`项目问题反馈.md` 只可记录“已反馈给项目管理员”的线索。 4. 正式执行日志。正式执行节点仍写项目、需求、开发、实验或案例对应执行日志。 推荐初始化内容直接参考 `项目问题反馈范本.md`。创建项目内 `ai-<name>/项目问题反馈.md` 时，不要求逐字复制范本，但必须保留记录边界、append 写法，以及事项 ID、问题步骤、反复次数、证据路径、修复建议、是否需要完整方案和方案路径等关键追踪字段。 ### 4.3 不能做的事 1. 不得把正式文档长期留在 AI 工作空间里。 2. 不得让 AI 工作空间替代项目执行日志、实验执行日志、开发执行日志或案例执行日志。 3. 不得在 AI 工作空间内创建第二套项目规范、开发规范、实验规范等体系规范。 4. 不得只创建目录，不更新 `项目配置清单.md`。 5. 不得把 `项目问题反馈.md` 当成正式审计报告或项目级问题记录的替代品。 ## 5. 功能二：分配角色并生成工作说明 @@ -178,7 +202,7 @@ 5. 改变审核员身份。 6. 改变默认写权限边界。 同时应写入 `项目执行日志.md`，记录实际创建了哪些目录、改了哪些配置、生成了哪个 `工作说明.md`。 同时应写入 `项目执行日志.md`，记录实际创建了哪些目录、改了哪些配置、生成了哪个 `工作说明.md` 和 `项目问题反馈.md`。 如果角色调整本身是一个项目事项，还应在 `项目事项总纲.md`、`项目事项计划.md` 和 `项目事项审计报告.md` 中记录对应事项和审计结论。 @@ -247,8 +271,9 @@ 1. 私有草稿：`ai-<AI_NAME>/draft/` 2. 私有临时文件：`ai-<AI_NAME>/tmp/` 3. 私有过程记录：`ai-<AI_NAME>/worklog/` 4. 正式产物：<按角色列出正式目录；注明路径是否相对项目根目录> 5. 审计入口：<如有审核角色，列出对应审计报告；注明路径是否相对项目根目录> 4. 私有项目问题反馈：`ai-<AI_NAME>/项目问题反馈.md` 5. 正式产物：<按角色列出正式目录；注明路径是否相对项目根目录> 6. 审计入口：<如有审核角色，列出对应审计报告；注明路径是否相对项目根目录> ## 5. 任务入口路由 @@ -261,6 +286,7 @@ 1. 首次读取本文件后，在 `ai-<AI_NAME>/worklog/` 记录理解反馈。 2. 如果有不理解、冲突或不合理的地方，反馈给项目管理员，不要自行脑补执行。 3. 如果问题会影响项目协作、角色权限或体系推进，同步记录到 `ai-<AI_NAME>/项目问题反馈.md`。 ## 7. 审核边界 @@ -277,6 +303,7 @@ 2. 不得越权写未分配体系目录。 3. 不得绕过项目配置清单新增角色或权限。 4. 不得只在聊天里解释职责，不写入本文件。 5. 不得把 `项目问题反馈.md` 当成正式审计报告、正式问题记录或正式执行日志。 ``` ## 6. 创建 / 分配角色后的校验方案 @@ -290,8 +317,9 @@ 3. `ai-<ai_name>/draft/` 存在。 4. `ai-<ai_name>/worklog/` 存在。 5. `ai-<ai_name>/工作说明.md` 存在。 6. 没有创建裸 AI 名目录。 7. 工作空间内没有项目规范、体系规范、开发账本、实验账本等重复体系文件。 6. `ai-<ai_name>/项目问题反馈.md` 存在，并说明写法参考 `common/ai-workplace/项目问题反馈范本.md`。 7. 没有创建裸 AI 名目录。 8. 工作空间内没有项目规范、体系规范、开发账本、实验账本等重复体系文件。 ### 6.2 项目配置清单校验 @@ -337,6 +365,8 @@ 10. 如果是审核员，是否写清审核体系、审计报告入口、只读边界和不得直接修改被审计产物。 11. 如果是审核员，是否同时列出被审体系规范、审计规范 / 审计报告入口、被审对象账本入口。 12. 是否要求 AI 首次阅读后在 `worklog/` 记录理解反馈和疑问。 13. 是否写清 `项目问题反馈.md` 的入口和边界：只反馈重大协作问题，不替代正式审计报告、问题记录或执行日志。 14. 是否说明 `项目问题反馈.md` 的写法参考 `common/ai-workplace/项目问题反馈范本.md`。 组合角色还必须按角色类型做专项校验： @@ -362,10 +392,11 @@ 1. 工作空间目录完整。 2. `工作说明.md` 可让该 AI 快速了解职责边界、目录入口和应该阅读的体系文档。 3. `项目配置清单.md` 已更新，并且与 `工作说明.md` 一致。 4. 项目执行日志和项目变更记录已记录影响。 5. 未启用体系没有被越权写入正式权限。 6. 目标开发工作区没有被误创建成第二套开发体系。 3. `项目问题反馈.md` 已创建，且用途边界清楚，并说明写法参考 `common/ai-workplace/项目问题反馈范本.md`。 4. `项目配置清单.md` 已更新，并且与 `工作说明.md` 一致。 5. 项目执行日志和项目变更记录已记录影响。 6. 未启用体系没有被越权写入正式权限。 7. 目标开发工作区没有被误创建成第二套开发体系。 ## 7. 变更影响说明 @@ -382,6 +413,7 @@ ```text 项目配置清单.md -> ai-<name>/工作说明.md -> ai-<name>/项目问题反馈.md -> 项目执行日志.md -> 项目变更记录.md -> 必要时进入项目事项总纲 / 计划 / 审计报告 @@ -390,7 +422,7 @@ ## 8. 常见错误 1. 只创建 `ai-<name>/`，没更新项目配置清单。 2. 只更新项目配置清单，没生成 `工作说明.md`。 2. 只更新项目配置清单，没生成 `工作说明.md` 或 `项目问题反馈.md`。 3. 给 AI 分配实验员角色，但项目未启用实验体系。 4. 给开发 AI 写了 `dev/` 全目录权限，而不是绑定目标开发工作区。 5. 在 `dev-doc/<target>-doc/` 下复制第二套开发账本。 @@ -403,7 +435,8 @@ 12. 在 `工作说明.md` 里复制体系规范细节，导致工作说明变成第二套规范。 13. 审核员只列审计规范或审计报告，没列被审体系规范和被审对象账本入口。 14. AI 首次读取工作说明后没有留下理解反馈，导致后续误解无法追踪。 15. 把 `项目问题反馈.md` 当成正式审计报告、正式问题记录或正式执行日志。 ## 9. 一句话 AI 工作空间创建不是单纯建目录，而是“人员入场 + 角色授权 + 工作说明 + 项目配置清单 + 变更记录 + 校验”的完整动作。 AI 工作空间创建不是单纯建目录，而是“人员入场 + 角色授权 + 工作说明 + 项目问题反馈入口 + 项目配置清单 + 变更记录 + 校验”的完整动作。 common/ai-workplace/目录导读.md
@@ -3,19 +3,21 @@ 创建人员：Codex 文件职责：说明 `common/ai-workplace/` 下 AI 工作空间和角色指派相关通用文档的入口。 管理规范/模板：../../全局规范.md。 引用文件：AI工作空间创建指南.md。 引用文件：AI工作空间创建指南.md；项目问题反馈范本.md。 记录方式：目录导读；新增或删除本目录文件时更新。 ## 文件清单 | 文件 | 作用 | |---|---| | AI工作空间创建指南.md | 指导项目管理员创建 AI 工作空间、分配角色、生成工作说明并做校验 | | AI工作空间创建指南.md | 指导项目管理员创建 AI 工作空间、分配角色、生成工作说明和项目问题反馈入口并做校验 | | 项目问题反馈范本.md | 提供 `ai-<name>/项目问题反馈.md` 的参考写法，用于重大协作问题和反复返修问题反馈 | ## 使用顺序 1. 项目管理员先确认项目根目录和 `项目配置清单.md`。 2. 按 `AI工作空间创建指南.md` 创建 `ai-<name>/`。 3. 生成 `ai-<name>/工作说明.md`。 4. 同步更新 `项目配置清单.md`、`项目执行日志.md`、`项目变更记录.md`。 5. 按指南中的校验方案检查。 4. 参考 `项目问题反馈范本.md` 创建 `ai-<name>/项目问题反馈.md`。 5. 同步更新 `项目配置清单.md`、`项目执行日志.md`、`项目变更记录.md`。 6. 按指南中的校验方案检查。 common/ana-doc/案例审核规范.md
@@ -102,6 +102,15 @@ 如果案例分析事项包含案例分析开发，案例分析开发的方案审核、实现审核、测试验收和复审结论也统一写入 `ana-doc/案例审计报告.md`，不另写到 `dev-doc/开发审计报告.md`。 案例分析开发中的临时草稿脚本可以不做独立代码审核；但只要代码用于生成正式案例结论、案例筛选、图表证据、账户流水、验收包、结果包、审计辅助报告或可复用工具，就必须纳入案例审核。审核重点不是把轻量脚本套成重型开发流程，而是确认案例证据可信： 1. 输入案例、样本范围、过滤条件是否和案例设计一致。 2. 输出图片、表格、流水、summary、manifest 或等价结果包是否能和案例执行日志对上。 3. 候选、入选、买入、卖出、退出、结论标签是否和案例规则一致。 4. 代码是否改写原始证据、污染正式数据或覆盖不可变结果。 5. 至少抽查关键案例，必要时人工复算 1-3 个操作点或关键行。 6. 是否需要防未来函数或数据泄漏必须按案例目标判断；涉及交易、买卖、收益验证、实时判断或自动动作时必须检查，后验理解、图形归纳、案例复盘、方法论总结类案例可以不作为实盘时点安全审核，但结论必须降读。 只有问题需要跨轮跟踪、跨案例汇总或由案例分析员长期处理时，才在 `案例问题记录.md` 中建立索引或关联，不重复全文。 审核报告至少包含： common/dev-doc/编码规范.md
@@ -169,6 +169,8 @@ 这类任务通常不需要先写需求文档，也不需要写代码编写方案。 这类任务完成后通常不强制审核员审核，但必须自测并留下运行方式、输出位置和自测结果。如果代码开始影响核心流程、正式产物、长期接口或被其他事项复用，应升级到有需求文档的轻量实现或重型实现。 需求体系正式交付到开发的事项，默认不适用“无需求文档的轻量实现”。如果需求侧只给了口头要求或草案，应先回到需求流程形成可审计需求，再进入开发。 执行流程： @@ -208,7 +210,8 @@ 4. 写完后先做基础自测，例如语法、导入、最小样本、关键输出。 5. 自检：逐条对比需求文档和代码实现，确认是否有字段缺失、口径偏差、流程绕过、产物不一致。 6. 修掉自检发现的问题。 7. 输出验收结论，说明跑了什么测试、结果是什么、还有什么限制。 7. 交给审核员做轻量代码审核，重点检查需求-代码一致性、自测结果、关键输出、是否越权写正式产物、是否存在明显数据或流程风险。 8. 审核通过后输出验收结论，说明跑了什么测试、结果是什么、还有什么限制。 最低交付： @@ -216,7 +219,8 @@ 2. 对应需求文档。 3. 自测命令和结果。 4. 需求-代码自检结论。 5. 未解决问题或限制。 5. 审核员轻量审核结论。 6. 未解决问题或限制。 ### 5.3 有需求文档的重型实现
@@ -77,6 +77,15 @@ 如果实验事项包含实验开发，实验开发的方案审核、实现审核、测试验收和复审结论也统一写入 `exp-doc/实验审计报告.md`，不另写到 `dev-doc/开发审计报告.md`。 实验开发中的临时草稿脚本可以不做独立代码审核；但只要代码用于生成正式实验结果、候选池、收益统计、图表、验收包、结果包、结论 readout 或可复用工具，就必须纳入实验审核。审核重点不是把轻量脚本套成重型开发流程，而是确认结果可信： 1. 输入数据、样本范围、过滤条件是否和实验设计一致。 2. 输出表、图片、summary、manifest 或等价结果包是否能和执行日志对上。 3. 抽样、baseline、分组、统计口径、买卖规则或候选规则是否和实验目标一致。 4. 代码是否改写原始证据、污染正式数据或覆盖不可变结果。 5. 至少抽查关键样本，必要时人工复算 1-3 个样本或关键行。 6. 是否需要防未来函数必须按实验目标判断，具体按 2.5“未来函数按目标判断”执行。 以下内容默认不作为阻断问题： 1. 文案不漂亮。 common/pro-doc/mbx.system.yaml
@@ -10,13 +10,13 @@ audit_report: pro-doc/需求审计报告.md issue_record: pro-doc/需求问题记录.md default_roles: - product - requirement - reviewer roles: - role_key: product name: 产品 - role_key: requirement name: 需求员 workdir: pro-doc private_dir: ai-requirement-product private_dir: ai-requirement-owner docs_to_read: - 项目规范.md - 项目配置清单.md common/project-doc/项目环境创建指南.md
@@ -85,7 +85,7 @@ AI 工作空间目录必须统一使用 `ai-<name>/` 命名，`<name>` 使用稳定英文名或拼音小写，例如 `ai-andrew/`、`ai-codex/`。不得创建裸 AI 名目录。 创建或新增 AI 工作空间时，必须按 `../ai-workplace/AI工作空间创建指南.md` 执行：创建 `ai-<name>/tmp/`、`ai-<name>/draft/`、`ai-<name>/worklog/`、`ai-<name>/工作说明.md`，并同步更新 `项目配置清单.md`、项目执行日志和项目变更记录。 创建或新增 AI 工作空间时，必须按 `../ai-workplace/AI工作空间创建指南.md` 执行：创建 `ai-<name>/tmp/`、`ai-<name>/draft/`、`ai-<name>/worklog/`、`ai-<name>/工作说明.md`、`ai-<name>/项目问题反馈.md`，其中 `项目问题反馈.md` 写法参考 `../ai-workplace/项目问题反馈范本.md`；并同步更新 `项目配置清单.md`、项目执行日志和项目变更记录。 如果创建时暂时没有除项目管理员外的 AI，也至少要为项目管理员创建工作空间；后续新增 AI 时，也按 `../ai-workplace/AI工作空间创建指南.md` 执行。 @@ -183,7 +183,7 @@ 1. `项目配置清单.md` 已登记项目管理员、初始 AI、角色、权限、工作空间和启用体系。 2. `项目配置清单.md` 中登记的 AI 工作空间都已创建。 3. 每个已登记 AI 的 `工作说明.md` 已创建，且角色、权限与 `项目配置清单.md` 一致。 3. 每个已登记 AI 的 `工作说明.md` 和 `项目问题反馈.md` 已创建，且 `工作说明.md` 中的角色、权限与 `项目配置清单.md` 一致，`项目问题反馈.md` 已说明参考 `common/ai-workplace/项目问题反馈范本.md`。 4. 已启用体系的目录和本地规范存在；未启用体系没有被提前创建大量空目录。 5. 项目执行日志记录了初始化动作。 6. 如项目配置、角色、权限或目录在初始化中发生变化，项目变更记录已登记。 @@ -237,7 +237,7 @@ 2. 项目基础文档齐全，包含 `项目总览.md`。 3. 项目规范没有复制 common 正文。 4. 项目配置清单能解释启用体系、AI、角色、权限、目录和工作空间。 5. 项目配置清单中登记的 AI 工作空间已创建。 5. 项目配置清单中登记的 AI 工作空间已创建，且每个工作空间都有 `工作说明.md` 和 `项目问题反馈.md`。 6. 已启用体系的本地规范存在；开发体系根目录必须按 `common/dev-doc/开发环境创建指南.md` 的 `root_default` 模式创建完整根级账本，目标开发工作区创建后再要求目标级本地开发规范。 7. 开发体系默认根目录已创建，且未提前创建目标开发工作区。 8. 项目执行日志记录了初始化过程。 common/project-doc/项目规范.md
@@ -199,6 +199,42 @@ 项目级问题只记录项目治理问题。具体需求、代码、实验、案例分析问题，优先记录到对应体系的问题文档；如果这些问题影响项目级目录、权限、目标或体系启用，再同步登记项目级问题或变更。 ### 3.6 AI 工作空间问题反馈与反复返修升级 每个 AI 工作空间中的 `项目问题反馈.md` 是该 AI 向项目管理员反馈重大协作问题的私有入口。 它服务于项目治理，不替代正式审计报告、项目问题记录、体系问题记录或执行日志。 适合写入： 1. 角色权限、工作空间、体系入口、流程边界不清，已经影响项目或体系推进。 2. 同一事项或同类问题多轮返修后仍重复出现，通常大于等于 3 次。 3. 审核员判断需要项目管理员介入协调、收口口径、调整角色、调整流程或暂停扩展。 4. AI 首次阅读工作说明、项目配置清单或体系规范后，发现职责/权限/入口存在影响执行的重大不清楚。 审核员发现被审事项存在问题时，仍必须先把正式审计结论写入对应审计报告。 如果同一问题经过多轮返修仍重复出现，审核员应额外在自己工作空间的 `项目问题反馈.md` 追加一条反复返修问题反馈。 反复返修问题反馈必须尽量记录清楚： 1. 关联事项 ID。 2. 关联计划 ID 或设计 ID。 3. 关联执行日志 ID。 4. 关联审计报告 ID。 5. 问题发生步骤。 6. 反复次数。 7. 已要求修复内容。 8. 为什么判断为反复问题。 9. 影响范围。 10. 关联证据路径。 11. 建议项目管理员介入方式。 12. 修复建议。该字段必填，至少给出下一步应怎么收敛。 13. 是否需要完整方案。如果问题复杂、反复难修或涉及多模块/多流程，应标记为“是”。 14. 完整方案路径。需要完整方案时填写，例如代码修复方案、流程整改方案或专项收敛方案路径。 15. 方案摘要。需要完整方案时，摘要说明方案核心动作、责任边界和验收方式。 `项目问题反馈.md` 的写法参考 `common/ai-workplace/项目问题反馈范本.md`，但不要求逐字复制范本。项目文件只要保留关键字段、记录边界和 append 写法即可。 ## 4. 核心文档 ### 4.1 项目总览.md @@ -345,6 +381,36 @@ ## 7. 项目审计边界 ### 7.1 事项级整体审核原则 审核员审核事项时，必须以事项为基本单元，而不是以单个步骤、单个文件或单个输出为基本单元。 事项单元以对应体系总纲文档中的一个目标 / 事项条目为准。审核员应围绕该事项整体检查： 1. 目标是否清楚。 2. 设计 / 计划是否能支撑目标。 3. 执行日志是否覆盖关键节点。 4. 关键输入、关键输出、关键数据和关键产物是否可追踪。 5. 结论是否回写。 6. 问题是否闭环。 如果审核过程中发现关键节点、关键数据、关键产物或关键证据链缺失，应作为审计问题反馈。 审核员不得把不影响事项目标、结论、关键证据链或下游使用的边角料问题升级为阻断问题；不得通过拆分步骤审计的方式层层加码。 在不同体系中，事项单元对应如下： | 体系 | 审核事项单元 | |---|---| | 项目体系 | `项目事项总纲.md` 中的一个项目事项 | | 需求体系 | `需求总纲.md` 中的一个需求目标或需求事项 | | 开发体系 | `开发事项总纲.md` 中的一个开发事项 | | 实验体系 | `实验总纲.md` 中的一个实验目标或实验事项 | | 案例分析体系 | `案例总纲.md` 中的一个案例目标或案例事项 | | 数据体系 | 数据体系总纲或数据事项账本中的一个数据目标或数据事项 | ### 7.2 项目级审计边界 项目级审计重点看： 1. 项目是否有清晰目标和边界。 common/project-doc/项目配置清单模版.md
@@ -58,7 +58,7 @@ | dev/ | 开发代码根目录；目标开发代码放到 dev/<target>-dev/ | 开发 AI | 已创建 / 未创建 | 项目创建默认存在 | | dev-doc/ | 开发文档根目录；根级开发入口规范和唯一开发账本放在 dev-doc/，目标代码文档和方案附件放到 dev-doc/<target>-doc/ | 开发 AI | 已创建 / 未创建 | 项目创建默认存在 | | tmp/ | 项目级临时文件 | 项目管理员 | 已创建 / 未创建 | 临时产物不得当正式结果 | | ai-<AI_NAME>/ | AI 工作空间 | 对应 AI | 已创建 / 未创建 | 草稿和临时分析 | | ai-<AI_NAME>/ | AI 工作空间 | 对应 AI | 已创建 / 未创建 | 必须包含 `工作说明.md` 和 `项目问题反馈.md`；草稿和临时分析 | ## 6. 核心文档入口
@@ -3,7 +3,7 @@ 创建人员：Codex 文件职责：记录管理体系下所有项目、所有 AI、所有事项默认遵守的全局规则。 管理规范/模板：参考 `管理系统说明.md` 和 `体系说明.md`；本文件是全局执行规则，不是体系说明书。 引用文件：`管理系统说明.md`；`体系说明.md`；`体系创建流程.md`；`全局存储体系.md`；`全局数据格式.md`；`common/ai-workplace/AI工作空间创建指南.md`；`common/pro-doc/需求规范.md`；`common/pro-doc/需求规范.md`；`common/dev-doc/编码规范.md`；`common/exp-doc/实验规范.md`；`common/exp-doc/实验审核规范.md`。 引用文件：`管理系统说明.md`；`体系说明.md`；`体系创建流程.md`；`全局存储体系.md`；`全局数据格式.md`；`common/ai-workplace/AI工作空间创建指南.md`；`common/pro-doc/需求规范.md`；`common/dev-doc/编码规范.md`；`common/exp-doc/实验规范.md`；`common/exp-doc/实验审核规范.md`。 记录方式：本文件为全局规则文档；新增规则默认追加到对应章节，重大口径变化必须保留变更说明，不得静默覆盖历史原因。 ## 1. 文档定位 @@ -266,7 +266,7 @@ 工作空间目录必须统一使用 `ai-<name>/` 命名，`<name>` 使用稳定英文名或拼音小写。例如 Andrew 使用 `ai-andrew/`，Codex 使用 `ai-codex/`。禁止直接使用裸 AI 名目录，例如 `Andrew/`、`Codex/`。 创建 AI 工作空间、分配角色、生成 `工作说明.md` 时，按 `common/ai-workplace/AI工作空间创建指南.md` 执行，并同步更新项目根目录 `项目配置清单.md`、`项目执行日志.md` 和 `项目变更记录.md`。 创建 AI 工作空间、分配角色、生成 `工作说明.md` 和 `项目问题反馈.md` 时，按 `common/ai-workplace/AI工作空间创建指南.md` 执行，并同步更新项目根目录 `项目配置清单.md`、`项目执行日志.md` 和 `项目变更记录.md`。 工作空间用于： @@ -274,6 +274,9 @@ 2. 草稿。 3. 私有中间产物。 4. 未进入正式体系的探索材料。 5. 重大协作问题和反复返修问题的私有反馈入口。 `项目问题反馈.md` 不替代正式审计报告、项目问题记录或执行日志；具体边界按 `common/project-doc/项目规范.md` 和 `common/ai-workplace/AI工作空间创建指南.md` 执行。 AI 对自己的工作空间有读写权限。
@@ -154,10 +154,12 @@ #### AI工作空间 每一个AI，在项目里有一个自己的工作空间，比如AI名叫Andrew,那么就在 项目目录下创建一个 `ai-andrew/` 文件夹，该文件夹下就是 AI 的工作空间。工作空间目录必须统一使用 `ai-<name>/` 前缀。 AI工作空间下应该有一个 工作说明.md 通过该文档能够快速了解如下几点 1.AI工作空间下应该有一个 工作说明.md 通过该文档能够快速了解如下几点 -- 他的工作职责范围 -- 他的工作环境，以及工作方式和流程 2.AI工作空间里应该还有一个 叫 项目问题反馈.md 文档，该文档是让AI反馈在项目里协作问题的文档，该文档应该也是按append方式进行书写的，这个文档有几个主要作用 -- 汇报AI在整个工作流程里遇到的重要问题（该问题一定要是影响整个项目或者体系内部进展的，小问题，不重要的问题不要在这里汇报） -- 如果AI是审核员，发现自己审核的事项出现的问题，复返修复多次还是会出现同一个问题（最好大于等于3次），就需要汇报到这个文档里 ### data @@ -253,6 +255,10 @@ 5. 审计事项的设计和执行的过程是否和事项记录的聊天记录的需求一致，如果不一致一定要反馈出来 6. 审计过程发现文件有乱码一定要报告出来 7. 审计员不仅要审计事项的进行是否合理是否满足客户需求，还要审计事项的设计是否合理 8. 审计员发现自己审核的事项出现的问题，复返修复多次还是会出现同一个问题（最好大于等于3次），就需要汇报到自己项目里工作空间的 项目问题反馈.md 里，记录的信息要主要详细，保证项目管理员 到时候能追踪到具体的事项id以及有问题的步骤等等 9. 如果审核员发现的事项问题，反复修改多次还是反复出现同一个问题，那么在反馈内容里最好能附带解决问题的建议，甚至问题很麻烦的时候可以给完整的解决问题的方案(比如在修代码bug的时候的 代码修复方案） 10. 审核员在审核事项的时候，要以事项为单元（也就是以对应的体系的总纲文档里的一个目标为单元）来整体审查，不能单审查事项的某一个步骤，如在审查过程中发现关键节点有缺失也应该反馈成问题，但是不允许层层加码和吹毛求疵。 所有的审核文档里都检查下一定要保证以下原则： 1. 保证审核的内容的主要内容没问题 2. 对边角料非主要内容，不要吹毛求疵，层层加码，加大执行的难度 @@ -263,7 +269,7 @@ 下面所有的技能都不得违反全局规范.md的要求 2. 项目创建技能 以及 项目体系创建技能; 参考 章节体系管理员必须具备的能力 （属于common\project-doc\项目环境创建指南.md) 下面所有的技能都不得违反全局项目规范.md的要求 和 本地项目规范.md的要求 3. AI工作空间创建 以及 AI角色分配技能; 参考 章节体系管理员必须具备的能力（属于common\project-doc\AI工作空间创建指南.md) 3. AI工作空间创建 以及 AI角色分配技能; 参考 章节体系管理员必须具备的能力（属于common\ai-workplace\AI工作空间创建指南.md) 4. 实验技能（包括实验设计，到实验执行）; （属于common\exp-doc\实验规范.md 以及 项目本地 exp-doc\实验规范.md 两个共同作用的技能 ) 5. 实验审核技能（包括实验设计审核，以及实验全流程审核）;（属于common\exp-doc\实验审核规范.md 以及 项目本地 exp-doc\实验审核规范.md 两个共同作用的技能 ) 6. 需求文档编写技能(包括需求方案文档，以及需求文档修改和书写）;（属于common\pro-doc\需求规范.md 以及 项目本地 pro-doc\需求规范.md 两个共同作用的技能 )
