AI 研发 Skill 总体架构图，展示公司控制面、统一分发与发现、项目能力面、任务执行面和治理反馈面的完整闭环
总体架构主图先从公司公共入口识别项目，再进入项目完成任务；验证后的项目经验和公共能力沿两条回流路径进入下一次任务。
01 · 从公司总入口到项目沉淀

总入口如何进入项目，完成研发与沉淀

进入实际项目操作详解 查看项目如何初始化 查看目录设计原文

Agent 先通过公司公共入口识别项目，再进入仓库读取活动任务和项目事实；每次确认与纠偏写入项目文件，新窗口从最新交接继续；完成后通过门禁归档，并把验证过的经验回流到下一次任务。

LAYER 1

公司控制面

维护所有项目共用的规则、注册表和公共能力。

ai-engineering-playbook/company/

研发总纲 · 交付定义 · 安全 · Skill 治理

ai-engineering-playbook/project-registry/

登记项目路径、入口 Skill、状态与成熟度

ai-engineering-playbook/shared-skills/

当前保存项目初始化器 · 后续承载验证后的公共能力

ai-engineering-playbook/cross-project/ + scripts/

父级 Epic、跨项目活动索引、初始化、扫描和校验

LAYER 2

统一发现与路由

不同 Agent 从同一套公共 Skill 和项目注册表找到正确仓库。

Codex / Claude Code / 其他 Agent 输入：PRD、Bug、日志问题、多项目需求
公共 Skill 发现入口 ~/.agents/skills/ · ~/.codex/skills/ · Plugin（规划） 提供 PRD、估时、日志、SQL、初始化和沉淀能力
项目注册与任务路由 project-registry/projects.yaml 按当前目录、项目 ID、API/业务归属找到项目根目录和入口 Skill
LAYER 3

进入具体项目

每个项目保存自己的事实、限制、领域 Skill 和交付记录。

DGJ2

已接入 · 15 个项目 Skill
/dgj2.0 → dgj2-project-maintainer
  • AGENTS.md
  • doc/ai/index.md + project.yaml
  • doc/ai/skills/ + .agents/skills/

SAAS

已接入 · L2 与规划机制全量校验通过
/saas → saas-project-maintainer
  • AGENTS.md
  • doc/ai/index.md + project.yaml
  • 项目 Skill / 交付包 / 校验脚本

其他项目

按需初始化
/project → project-skill-initializer
  • 扫描仓库事实
  • 生成 L1 项目入口骨架
  • 真实任务审计后再晋级
LAYER 4

项目内执行

进入项目后先分流场景，再按风险与证据缺口选择能力和门禁。

1 识别项目 projects.yaml + active-tasks

按项目别名、仓库和活动任务定位一个或多个项目。

2 判断场景与风险 requirement / bug / incident / quick

先决定走完整、轻量、只读取证还是直接小改流程。

3 加载项目入口 AGENTS + doc/ai + project Skill

读取项目事实、限制、当前任务和对应场景工作流。

4 条件调用能力 code / DB / logs / API / tests

只加载完成当前证据链真正需要的通用与领域 Skill。

5 执行场景门禁 REQ-* / BUG-* / INC-* / no package

每类任务使用不同核心产物，交付项按影响 required 或 not_required。

6 验证并回流 delivery / project / skills / candidates

验证通过后归档任务，并让可复用经验进入下次发现路径。

LAYER 5

沉淀与回流

不同知识进入不同事实源，不把一次性信息变成长期规则。

留在项目 project/ · skills/ · candidates/

项目架构、业务规则、领域排障经验和首次经验候选。

↺ 回到该项目下一次任务
上升为公共能力 shared-skills/ · cross-project-skills/

多个项目都成立、已有真实证据的通用流程或跨仓链路。

↺ 回到所有项目的统一发现入口
发布给人阅读 jb2ai.ltd

完整架构、业务文档、复盘、发布手册和可检索证据。

↺ 用于讲解、交接与人工查阅
本次交付证据
只回流已验证、可复用、无秘密的信息
下一次任务直接加载
DIRECTORY MAP · COMPANY CONTROL PLANE

总目录：维护公司规则、项目路由与跨项目协作

总目录不保存某个项目的业务细节。它负责回答三件事：所有项目共同遵循什么、这次任务应该进入哪个项目、多个项目如何在同一个父级任务下协作。

⌂ai-engineering-playbook/
├── AGENTS.md 公共仓库入口
├── company/ 公司级治理规则
├── project-registry/projects.yaml 项目注册与路由
├── shared-skills/ 公司公共 Skill 源码
├── cross-project/ 跨项目任务控制面
└── scripts/ 确定性生成与校验
公共仓库入口01
AGENTS.md

规定公司规则、公共 Skill、跨项目任务和校验脚本分别从哪里读取。

何时使用：进入总目录时始终读取 提供结果：统一启动协议
公司级治理规则02
company/

研发宪法、交付完成定义、安全策略、Skill 治理和项目成熟度模型。

何时使用：所有项目初始化和交付时遵循 提供结果：跨项目一致的底线
项目注册与路由03
project-registry/projects.yaml

登记项目 ID、仓库根目录、doc/ai 位置、入口 Skill、接入状态和成熟度。

何时使用：任务未明确项目或涉及多项目时读取 提供结果：正确项目根目录与入口 Skill
公司公共 Skill 源码04
shared-skills/

当前保存项目初始化器；后续经过多项目验证的公共能力在这里统一维护和分发。

何时使用：新项目接入或公共流程命中时读取 提供结果：可复用的项目初始化能力
跨项目任务控制面05
cross-project/

保存父级 Epic、子项目关系、依赖、重叠触点以及自动生成的活动任务索引。

何时使用：同一需求影响两个以上项目时读取 提供结果：父级路线图与跨仓依赖
确定性生成与校验06
scripts/

生成跨项目活动索引，维护用户级 Skill 链接，避免依赖 Agent 临时手工整理。

何时使用：项目清单或跨项目任务变化后执行 提供结果：可复查的索引与链接结果
1 · AGENTS.md 加载公司约束
2 · project-registry 找到项目
3 · 进入项目自己的 AGENTS.md
4 · 跨项目时由 cross-project 聚合
公司层负责共用规则和公共能力，不保存具体项目业务事实。
项目注册表负责“找到项目”，项目入口 Skill 负责“进入项目后怎么做”。
项目 Skill 的源码留在项目 `doc/ai/skills/`，由 `.agents/skills/` 发现。
项目经验回到项目；跨项目能力上升到公共层；变更包通过门禁后留下归档事件。
02 · 从旧代码到可接收 PRD 的项目

一个只有旧代码的项目，如何接入统一 Skill 体系

初始化先固定可复现的代码起点，再只读识别仓库事实；初始化器生成 L1 入口、模板和确定性脚本，全量校验通过后提交基线。此时项目已经能接收第一个 PRD，但还没有凭空生成任何业务经验。

STEP 01 固定历史起点 git checkout <BASE_SHA>

从明确提交创建干净分支；不复制当前脏工作区和已有 AI 资料。

产物：旧代码 + 可复现实验起点
STEP 02 只读扫描仓库 inspect_repository.py <repo>

识别语言、框架、代码目录、测试，以及是否已有 AGENTS/doc/ai。

产物：仓库事实 JSON；业务代码 0 修改
STEP 03 生成 L1 骨架 initialize_project.py <repo>

保留已有人工文件，补统一入口、项目 Skill、模板、脚本和知识目录。

产物：AGENTS.md + .agents + doc/ai
STEP 04 重建并校验 rebuild_active_tasks.py → validate_ai_system.py

校验入口、软链接、规划状态、交付包、经验审计和敏感信息扫描。

产物：8 项 PASS 或明确失败原因
STEP 05 提交初始化基线 git commit -m 'initialize AI baseline'

把代码起点和 L1 产物固定成独立提交，后续实验分支都从这里开始。

产物：可重放、可对照的 BASELINE_SHA
STEP 06 进入第一个 PRD create_change_package.py prd REQ-ID 标题

新聊天自动读取项目入口，创建需求包并开始代码取证与多轮确认。

产物：Revision 1 + EVT + handoff + Markdown 计划包
初始化前：只有旧代码INPUT
legacy-project/
├── application/ 或 app/
├── config/
├── tests/
└── 没有 AGENTS.md / doc/ai / 项目 Skill
初始化后：L1 项目研发骨架OUTPUT
project/
├── AGENTS.md + Claude/Gemini/Copilot/Cursor 薄入口
├── .agents/skills/<project>-project-maintainer
└── doc/ai/
├── project/ + standards/ + runbooks/
├── templates/ + scripts/ + tests/
├── changes/ + active-tasks.*
└── skills/ + candidates/ + contracts/
自动入口 AGENTS.md · 薄适配器 · .agents/skills/

不同 Agent 进入仓库后都回到同一项目协议。

可恢复任务机制 templates/ · create/resume/checkpoint/validate/archive

第一个 PRD 起就能留下 Revision、事件和 handoff。

知识容器 project/ · skills/ · contracts/ · runbooks/ · candidates/

先生成空容器；真实业务知识只在后续验证后写入。

DGJ2.0 验证副本实测 PASS
旧代码 0e2e4fa3 → 初始化基线 272bea0636

CodeIgniter · PHP / Node.js；初始化前无 AGENTS/doc/ai；初始化后 8 项总校验 PASS

SAAS 验证副本实测 PASS
旧代码 43e167141 → 初始化基线 7bbb569fd

Hyperf · PHP；初始化前无 AGENTS/doc/ai；初始化后 8 项总校验 PASS

初始化完成只代表项目具备统一入口和可恢复研发机制，成熟度是 L1。领域规则、日志入口、数据库关系和排障经验必须经过真实任务与证据验证后，才能进入项目 Skill。
03 · 走进一个项目

以 DGJ2 为例：发现任务、恢复状态、继续实施

这些是 DGJ2 仓库中真实存在的文件和脚本。新 Agent 不依赖聊天记录：先发现活动任务，再恢复最新 Revision、交接内容和重叠任务。

DGJ2 真实需求调用链图，展示需求输入、项目启动、Skill 路由、PRD 提取、代码取证、差异审查、交付闸门与经验回流
真实需求调用链先看一次需求如何完整流转，再对照下方仓库级实现，理解 AGENTS.md、项目事实、入口 Skill、检查点、交付门禁和沉淀文件分别承担什么职责。
自动入口 AGENTS.md 先读 active-tasks.md、doc/ai/index.md、project.yaml 和项目入口 Skill
项目事实 doc/ai/index.md + project/ 架构 · 模块 · 代码 · 数据 · 集成 · 环境 · 日志 · 分支 · 保护文件
项目总入口 Skill dgj2-project-maintainer 按任务路由 PRD / Bug / 日志 / SQL / API / 发布 / 领域 Skill
01 · 发现并恢复 活动索引 → 最新交接 active-tasks.md · resume_prd.py · handoff.md

先恢复当前结论、Revision、下一步、问题和关联任务。

02 · 固化需求意图 提案 + 活需求 + 规格增量 proposal.md · requirement.md · spec-delta.md

把聊天里的确认结果写成 R-001，而不是保存聊天全文。

03 · 形成开发蓝图 现状取证 → 设计 → 原子任务 current-flow · impact · D-001 → T-001

需求、设计、任务和测试使用稳定 ID 连成可校验链路。

04 · 有效检查点 确认 / 纠偏 / 决策 → 新事件 checkpoint_prd.py · events/ · Revision

每次只追加事件；旧 Revision 写入会被拒绝，防止覆盖新结论。

05 · 验证、沉淀、归档 实现 → TC → delivery → archive validate_planning.py · delivery.yaml · archive_change.py

追踪断链或证据不足就阻断；通过后追加归档事件并移出活动索引。

DIRECTORY MAP · DGJ2 REPOSITORY

项目目录：保存项目事实、当前任务与可复用经验

项目目录跟随代码仓库版本管理。根目录只保留薄入口，所有可编辑的 AI 研发资产集中在 doc/ai；新窗口和其他 Agent 都从同一套文件恢复状态。

⌂dgj2.0/
├── AGENTS.md + 薄适配器 自动发现入口
├── .agents/skills/ 项目 Skill 发现目录
├── doc/ai/index.md + active-tasks.* 项目导航与活动索引
├── doc/ai/project/ · standards/ · contracts/ · runbooks/ 稳定项目事实
├── doc/ai/changes/active/ · archive/ 每条需求的持久状态
├── doc/ai/skills/ + skill-catalog.yaml 项目专属能力
└── doc/ai/scripts/ · templates/ · tests/ · candidates/ · reports/ 自动化与经验治理
自动发现入口01
AGENTS.md + 薄适配器

强制先读取项目导航、活动任务和入口 Skill；Claude、Gemini、Copilot、Cursor 只转回同一协议。

何时使用：进入 DGJ2 仓库时始终读取 提供结果：项目启动顺序与强制门禁
项目 Skill 发现目录02
.agents/skills/

只保存指向 doc/ai/skills 的相对软链接，让 Agent 自动发现项目入口、领域和验证 Skill。

何时使用：任务描述命中某个 Skill 时读取 提供结果：唯一源码的发现入口
项目导航与活动索引03
doc/ai/index.md + active-tasks.*

index.md 告诉 Agent 从哪里开始；active-tasks 汇总当前 REQ/BUG、Revision、依赖和重叠触点。

何时使用：每个实质任务开始或切换窗口时读取 提供结果：当前任务、关联任务和恢复入口
稳定项目事实04
doc/ai/project/ · standards/ · contracts/ · runbooks/

保存架构、代码、数据、环境、日志、分支、保护文件、研发标准、有效契约和操作手册。

何时使用：按当前任务阶段和领域按需读取 提供结果：设计与实施所需的项目上下文
每条需求的持久状态05
doc/ai/changes/active/ · archive/

活动包保存 requirement、design、tasks、事件、Revision、handoff、测试和 delivery；通过门禁后移入 archive。

何时使用：创建、恢复、纠偏、实施和交付时持续更新 提供结果：可换窗口、可追踪、可归档的任务事实
项目专属能力06
doc/ai/skills/ + skill-catalog.yaml

项目入口 Skill 负责路由；领域 Skill 保存重复且已验证的业务规则、排查路径和验证脚本。

何时使用：任务类型或业务线索命中时读取 提供结果：本项目下一次可直接复用的执行方法
自动化与经验治理07
doc/ai/scripts/ · templates/ · tests/ · candidates/ · reports/

脚本负责 create/resume/checkpoint/validate/archive；模板统一产物；测试做前向验证；候选池保存尚未晋级的经验。

何时使用：执行确定性动作或任务收尾时使用 提供结果：稳定工具、验证证据与经验晋级记录
1 · AGENTS.md 进入项目
2 · active-tasks 恢复任务
3 · project + Skill 获取上下文
4 · changes 持续记录与交付
5 · scripts 验证后沉淀归档
04 · 场景编排与公共能力

先选流程，再按条件加载能力

需求、Bug、线上排查和低风险小改不是同一套流程。总入口先判断场景与风险，再进入对应工作流；数据库、日志、Apipost 等是能力库，只在任务确实需要时调用。

通用 Skill 能力库不是每次全跑；由场景、风险和证据缺口条件调用
项目路由注册表 · 活动任务 · Resume
需求读取Axure · 工时 · 原子需求
代码取证当前链路 · 旧逻辑 · 影响面
数据取证表结构 · 只读 SQL · 分库分表
日志排查Kibana · 预发 · 堡垒机
API 文档本地契约 · Apipost · 读回
测试审查单测 · 回归 · Code Review
发布回滚SQL · 配置 · 观察 · 回滚
经验沉淀项目事实 · Skill · 候选池
完整流程 · 设计确认后编码

需求开发

requirement-development.md
REQ-* 完整需求包
结构化需求
真实代码与旧链路
确认设计
开发回归
按需交付门禁
Axure / PRD
→
可开发、可估时、可验收的交付包
轻量流程 · 根因成立后编码

Bug 修复

bug-fix.md
BUG-* 轻量任务包
记录现象
复现或替代证据
证明根因
最小修复
针对性回归
可复现缺陷
→
根因、修复和验证可追踪
证据流程 · 不直接改代码

线上问题排查

incident-investigation.md
单次可无包；持续跟进建 INC-*
限定时间与环境
只读日志/数据
代码互证
输出结论
需修复则转 BUG
订单号 / request_id
→
只读取证，不在排查阶段改线上
最短流程 · 风险升高即转轨

低风险快速变更

quick-change.md
默认无包
确认范围
局部修改
最小验证
发现风险立即升级
文案 / 注释 / 小文档
→
直接完成，不套完整需求流程
05 · DGJ2 可重复实战

聊到一半换窗口，如何不从头再问？

DGJ2 PRD 规划持续沉淀与跨窗口恢复。这个案例验证的不是模型记忆，而是新窗口能否只靠仓库文件恢复，以及并行 Agent 会不会覆盖较新的结论。

01 · 创建变更包 自动生成 proposal、delta、Revision 1、首事件和 handoff。
02 · 多轮确认 每次有效纠偏形成独立 EVT；重要原因写入不可变 ADR。
03 · 进入新窗口 resume 读取最新快照、结论、待办和相关并行任务。
04 · 恢复生成视图 即使 planning-state 被删除，也能从最后事件自动修复。
05 · 并发写保护 另一 Agent 基于旧 Revision 写入时稳定返回 stale revision。
06 · 追踪门禁 R → D → T → TC 断链时不能进入最终交付。
A · 第一次建立需求 proposal + requirement + delta
EVT-... · Revision 1

先把目标、范围和首批问题放进变更包。

B · 多轮对话纠偏 新 EVT + ADR
state / handoff → Revision 2

只记录确认后的结论、理由和下一步，原事件不改写。

C · 新窗口继续 active-tasks → resume
latest event → handoff

新 Agent 先恢复最新状态，再读取本阶段所需文档。

D · 并行写入保护 expected r1 ≠ current r2
拒绝 → resume → reconcile

旧窗口不能静默覆盖新确认，必须先合并差异。

恢复成功 · 陈旧写入被拒绝
新窗口从事件、状态和 handoff 继续；使用旧 Revision 的 Agent 无法覆盖新结论。
doc/ai/changes/archive/2026/REQ-AI-PRD-CONTINUITY-PRD规划持续沉淀与跨窗口续聊/
06 · 多项目协同

一个父级 Epic，自动关联各项目活动任务

公司层父级 Epic 记录共同目标和依赖；DGJ2、SAAS 各自保存变更包和 Revision；跨项目索引按 parent_epic 聚合，最终由同一集成门收口。

EPIC-AI-PRD-CONTINUITYroadmap.yaml
共同目标 · 项目清单
依赖 · 集成验收
DGJ2 子任务独立 planning-state
独立 events / handoff
项目内门禁
SAAS 子任务独立 planning-state
独立 events / handoff
项目内门禁
Playbook / 初始化器生成同一套协议
跨项目索引
新项目复用
跨项目活动索引 / 集成门自动聚合同一 Epic
冲突与依赖可见
各项目通过后统一验收
可以并行：各仓库只读分析、日志/SQL/MQ 取证、独立项目实现和项目内测试。
必须串行：业务口径、契约定稿、共享数据结构、数据库迁移、最终集成与发布。
07 · 多 Agent 使用

核心资料不绑定工具，入口做薄适配

项目事实、任务状态和交付证据统一使用 Markdown、YAML 和脚本。不同 Agent 只有发现入口不同，进入后全部读取同一 `AGENTS.md + doc/ai + CLI`。

Codex AGENTS.md + .agents/skills/ 当前 DGJ2 已完整自动发现
工具无关核心 active-tasks
planning-state + events
handoff + delivery
通用 Python CLI
Claude · Gemini · Copilot · Cursor CLAUDE.md · GEMINI.md · .github/ · .cursor/ 四类薄入口已实现；只负责进入共享核心
08 · 远期目标

先释放重复劳动，再打造更理解自己的 AI Agent

远期不只追求生成代码，而是让 Agent 逐步覆盖需求理解、项目开发、上线前审查、线上发现、远端排查和经验回流。人保留目标与关键决策，Agent 承担可重复、可验证的执行。

先提升一部分效率，解放更多时间。

从常用 Skill 和项目架构开始，把能力逐步延伸到上线前审查、Kibana 自动发现、远端排查与经验自我更新。

北极星目标 个人研发 Agent

理解我负责的项目、业务规则、当前任务、工作习惯与风险偏好，并始终用当前代码和证据校正历史经验。

STEP 01 图形化需求

把 PRD 转成业务流程、状态、影响项目和待确认问题。

产物：可确认需求图
STEP 02 项目架构开发

自动路由项目，读取旧链路，形成设计、任务和代码修改。

产物：可执行任务包
STEP 03 上线前 Code Review

对照 PRD、Diff、公共文件、接口、SQL、测试和回滚门禁审查。

产物：PASS / BLOCK / 风险清单
STEP 04 发布与观察

按发布清单执行，关联版本、配置、指标和观察时间窗。

产物：可追踪交付证据
STEP 05 Kibana 自动发现

从异常、接口、订单号和时间窗自动扩展检索，串联 request_id 与上下游错误。

产物：只读日志证据链
STEP 06 本地 / 快小六排查

本地复现；需要远端时由快小六在受控范围取证、查询和协同处理。

产物：根因、修复与补偿方案
STEP 07 经验回流

把验证结论沉淀到项目地图、Runbook、已有 Skill 或候选区。

产物：下一次自动召回

Kibana 自动发现不是只搜一个关键词

输入：现象 / API / 订单号 / request_id / 时间窗

  1. 识别项目、环境和日志索引
  2. 扩展稳定业务键与上下游关键词
  3. 按时间线关联入口、异常、MQ 和回调
  4. 回到代码确认根因，不把日志猜测当结论
输出：脱敏证据链 + 可能根因 + 下一步只读查询

Code Review 是上线前的强制质量门

输入：PRD 任务包 + Git Diff + 项目规范 + 发布清单

  1. R → D → T → TC 是否全部追踪
  2. 共享旧链路与兼容边界是否受保护
  3. API / SQL / 配置 / MQ / 权限是否交付完整
  4. 失败、回归、发布观察和回滚是否可执行
输出：通过、阻断项、风险项及文件级证据
阶段一 · 先提效

减少重复理解与重复操作

  • 常用 Skill 持续沉淀
  • 项目架构直接用于 PRD 开发
  • 本地、预发、线上问题排查
  • 上线前 Code Review 标准检查
阶段结果：释放更多研发时间
阶段二 · 再协同

让复杂任务跨环境、跨项目流转

  • Kibana 自动发现与日志关联
  • 远端线上问题由快小六受控协同
  • 自动项目路由与多项目任务拆分
  • 跨窗口、跨 Agent 连续执行
阶段结果：复杂任务可以并行推进
阶段三 · 更懂自己

形成可持续进化的个人研发 Agent

  • 图形化呈现需求、链路和风险
  • 主动发现遗漏、冲突和历史故障
  • 经验防过期、验证后自动晋升
  • 用纠正轮数、恢复时间和命中率度量
阶段结果：从被动工具走向主动研发伙伴
09 · 落地路线

当前基线已可运行，下一步做团队分发与量化验证

DGJ2、SAAS、初始化器和父级 Epic 已接入同一协议。仍然把“代码已实现”和“团队已推广”分开，避免把规划写成现状。

现在

两项目与初始化器已运行

  • DGJ2 / SAAS 可恢复规划
  • 历史包非破坏迁移
  • Revision 并发保护
  • 追踪、交付与归档门禁
下一步

跨项目链路已形成基线

  • 父级 Epic Roadmap
  • 项目注册表聚合
  • 跨项目活动索引
  • handoff 与独立项目门禁
推广

团队正式分发与度量

  • 公共仓库远端与版本
  • 公司 Plugin 分发
  • GitLab/Jenkins 门禁
  • 轮次下降与纠正率指标
GitHub Spec Kit clarify → analyze → implement → converge

已映射为 R/D/T/TC 追踪校验、实施前分析和交付收敛门禁。

查看 GitHub 来源 →
OpenSpec proposal / specs / tasks → archive

已采用变更包、规格增量和门禁归档；父级 Epic 处理跨仓规划。

查看 GitHub 来源 →
OpenAI Codex AGENTS.md 分层发现 + 项目 Skills

项目入口放在仓库内；AGENTS 只做规则和路由，事实留在 doc/ai。

查看 GitHub 来源 →
Gas Town / Beads 持久化 ledger + handoff + dependency

用不可变事件、状态快照、交接文件和 parent_epic 实现轻量版本。

查看 GitHub 来源 →
Superpowers 流程 Skill + 场景测试 + 验证后完成

初始化器自测与规划单测已接入；下一步补无历史 Agent 压力测试。

查看 GitHub 来源 →
按步骤验证 PRD 经验沉淀 查看完整目录与治理规范 查看 DGJ2 项目 Skill 架构
1 / 7