项目使用指南与文件夹重梳理方案

项目使用指南与文件夹重梳理方案

一句话说明

zhctprompt 是团队的 AI Native 项目控制台：它不替代业务代码、不替代企业微信微盘、不替代云效，而是把三者连接起来，形成可恢复、可验收、可考核的工作证据链。

你每天怎么用

管理者

  1. 打开 AI_NATIVE_PROJECT_CONTROL_CONSOLE.md 看总入口。
  2. 打开 tasks/QUEUE.md 看当前 Ready / Blocked / Done。
  3. 打开 control/task-index/tasks.tsv 看任务证据、MR、状态和技能。
  4. 打开本目录的 team-performance-first-pass.csv 看绩效证据缺口。

产品 / UI / 方案

  1. 先用 PROJECT_IPO_USAGE_GUIDE.md 把需求填成 IPO。
  2. 产品战略和方案进入 modules/product/。
  3. 客户场景、项目资料和微盘资料进入 modules/project/。
  4. 每个成果必须留下来源、结论、验收口径和可复用资产。

研发 / 测试 / AI 工程

  1. 代码仍在 zhctproject/<repo>，不要复制到 zhctprompt。
  2. 控制资料写进对应 work_<project>/ 或 work/YYYY-MM-DD-topic/。
  3. 云效任务、分支、提交、MR、测试结果要写回 control/task-index/。
  4. AI 相关经验要沉淀到 standards-stack/agent-skills/ 或 standards-stack/ai-engineering/。

交付 / 销售 / 商务

  1. 客户项目资料按售前、交付、售后三阶段进入微盘；项目内只保存索引。
  2. 报价前必须补软件模块、硬件设备、客户节点、验收指标和责任边界。
  3. 销售承诺必须能回到产品/研发排期确认，不能只靠口头节点。

文件夹重新理解

类别 当前问题 新读法 后续动作
work/YYYY-MM-DD-topic/ 数量多，像流水账 一次任务的证据包 保留原状；每次新增必须有 summary.md 和 source-index.csv
work_<project>/ 项目边界不一 长期受控项目资料区 每个目录补 README.md、项目地图、证据入口
modules/ 已有但团队不一定知道 产品/项目两大导航层 作为普通成员查资料的默认入口
standards-stack/ 规则和 skill 太多 稳定制度、技能、知识库 只放经过验证或长期复用的规则
control/ 偏工程化 当前任务、路径、脚本、状态 新增绩效控制入口，不再让管理只看工作目录
work_company_knowledge/ 微盘索引庞大 企业微盘派生知识库 不复制原件，只定向抽取和引用源路径

重梳理原则

  1. 不大规模移动历史目录，避免破坏证据路径。
  2. 新增顶层控制台，把使用入口压缩到一页。
  3. 新增绩效框架，把“人、任务、证据、结果”连起来。
  4. 历史目录只做索引和归档标签，不做人工重命名风暴。
  5. 后续每个新任务必须同时产出：来源索引、结果 summary、人审页或可验收证据、任务索引条目。

建议新增的长期入口

入口 用途 状态
AI_NATIVE_PROJECT_CONTROL_CONSOLE.md/html 给所有人看的项目首页 已新增 Markdown；HTML 由 Pandoc 生成
control/project-usage-reorg-performance/README.md 本次重梳理和绩效考核控制入口 已新增
work/2026-06-02-project-usage-reorg-performance/ 本次任务证据包 已新增

后续 7 天落地动作

优先级 动作 验收
P0 每位成员按统一公式补本周输入 每人至少 1 条结构化周输入
P0 把 A1 石家庄、A5 国庆、A6 滨州写成可验收任务 三个任务有负责人、节点、验收指标和风险
P0 绩效表按周更新一次 每周生成 team-performance-YYYY-WW.csv
P1 给 19 个 work* 顶层目录补用途索引 每个目录至少有 README 或进入总索引
P1 把销售/交付/商务输入纳入同一张表 项目节点和研发排期能互相追溯