给业务负责人、项目负责人和工程师使用
人的界面
门户、看板、控制台、审批台和监控视图负责阅读、判断、确认和操作。
预约架构诊断Veda Harness
把分散的代码、数据、文档、任务、Git 历史、语义检索、运行时和 AI Agent 整理成一套可治理架构。人通过界面协作，AI 通过受控 API、脚本和工具合同工作。
人的界面
文档门户
项目看板
数据控制台
审批台
AI 的接口
lookup CLI
CDB index
Data service API
Agent Gateway
共同事实层
CDB
确定性路由
术语、别名、事实源、生产者与消费者
向量数据库
语义检索层
召回文档、代码、历史案例和运行记录
Git
版本骨架
分支、提交、评审、发布标签和回滚
Org-mode
任务计划
NEXT、WAIT、DONE、阻塞、里程碑和 agenda
六层架构把人、AI 和事实源分开
人看到的是业务界面和审批视图，AI 看到的是可验证、可授权、可审计的接口。 CDB、向量数据库、Git 和 Org-mode 则分别承担不同事实层，不能互相替代。
给 Agent 和自动化工具调用
AI 的接口
CLI、API、脚本入口、Gateway 和审计事件形成可控工具合同。
回答这个词到底指向哪里
CDB 确定性索引
术语、别名、项目归属、事实源、生产者和消费者边界不靠记忆猜。
语义检索层
向量数据库
召回相似文档、历史案例、代码上下文、运行记录和审计笔记。
让变更有历史、评审和回滚
Git 版本管理
仓库、分支、提交、评审、发布标签和回滚边界是 AI 协作前置能力。
管理计划、里程碑和阻塞
Org-mode 任务计划
NEXT、WAIT、DONE、deadline、agenda 和 blocker 让任务语义可读可追踪。
人的界面 vs AI 的接口
同一个系统必须同时服务人和 AI，但两者入口不能混在一起。人的界面用于理解和决策， AI 的接口用于查询、执行和留下证据。
人的界面
文档门户
让人阅读项目规则、架构说明、运行手册和客户交付资料。
项目看板
把任务、进度、阻塞、文档健康和运行信号放在同一视图。
数据控制台
管理数据同步、业务状态、维护任务和运行结果。
审批与监控
让生产变更、密钥使用和调度操作先被人确认。
AI 的接口
lookup CLI
从口语词、旧名和业务词进入确定性项目路由。
CDB index
用只读索引返回项目、事实源、生产者和消费者边界。
Data service API
让 Agent 通过稳定接口读取数据，而不是直接猜文件。
Agent Gateway
用授权、审批、短期令牌和审计约束工具调用。
CDB + 向量数据库
CDB 是确定性根索引，用来回答“这个词到底指向哪个事实源”。向量数据库作为语义检索层， 用来补足相似上下文、历史案例和相关说明的召回。
CDB
确定性路由
术语、别名、项目归属、事实源、生产者和消费者边界进入只读索引，避免靠记忆猜项目。
语义检索层
向量数据库
对文档、代码摘要、运行手册、历史问题、审计笔记和示例做语义召回，补足 CDB 的精确匹配边界。
Git + Org-mode
AI 不是先接入工具就能安全工作。企业需要先让代码和文档进入版本管理， 让计划、里程碑和阻塞进入可读任务系统。
branch -> review -> release
Git 版本管理
用仓库、分支、提交、评审、发布标签和回滚记录，让每一次 AI 或人工改动都可追溯。
NEXTWAITDONE
Org-mode 任务计划
用任务状态、项目归属、阻塞、截止日期和 agenda，把人的计划变成 AI 可读取的上下文。
从口语需求到审计沉淀
这条链路把“用户随口说的业务词”变成可定位、可验证、可回滚、可审计的工程变更。
01口语需求
02CDB 定位
03向量召回上下文
04Org 确认任务
05文档确认
06Git 分支变更
07脚本发布
08运行验证
09审计沉淀
文档中心
每个子项目对应一个文档中心入口，记录用途、负责人、代码仓库、开发版本、生产入口、数据归属和发布方式。
代码中心
每个子项目对应一个代码仓库或代码目录，并固定主分支、开发分支、评审规则、dev 版本和发布清单。
术语表 / CDB
每个子项目对应一个标准名，再把旧名、简称、业务叫法和客户口语写成别名，生成可查询 CDB。
第一阶段交付物
输出 01
子项目登记表：每个项目的标准名、负责人、代码中心、文档中心、术语表名称和 dev 版本。
输出 02
开发版本清单：每个项目的 dev 环境、验收入口、发布脚本、回滚方式和生产对应关系。
输出 03
CDB 查询验收：用客户真实叫法查询，能返回标准项目名、文档入口、代码事实源和验证顺序。
每个子项目一张登记卡
Veda Harness 不是先做一堆大平台，而是先把每个子项目登记清楚： 一个标准名、一个代码事实源、一个开发版本、一个文档入口、一个 CDB 查询入口。
子项目登记卡字段
标准名
客户和技术团队共同确认的唯一项目名
代码中心
仓库、主分支、开发分支、评审人、发布脚本
开发版本
dev 环境、验收地址、测试数据、回滚方式
文档中心
项目说明、运行方式、数据归属、验证清单
术语表 / CDB
标准名、旧名、简称、业务词、客户口语
生产对应
生产入口、发布版本、审批人、健康检查
给子项目定一个标准名
每个子项目先确定一个标准名。这个名字会同时出现在代码中心、文档中心和术语表里，不能一边叫客户门户、一边叫 portal、一边叫老后台。
建立代码中心和开发版本
把子项目放进代码中心，固定主分支和开发分支，并为它准备一个可验收的 dev 版本。以后 AI 或人工改动先进入 dev，再决定是否发布生产。
建立对应文档中心入口
给这个标准名创建一页文档，写清楚项目用途、负责人、仓库位置、dev 版本、生产入口、数据归属、发布脚本和验收方式。
写入术语表并生成 CDB
把标准名、旧名、简称、业务叫法和容易误听的词写入术语表。CDB 生成后，客户说一个口语词，也能定位到同一个文档入口和代码事实源。
最小可落地规则
每个子项目必须有一个标准名，不能只靠口头叫法管理。
每个子项目必须有一个 dev 版本，用来验证 AI 或人工改动。
每个文档中心入口必须写明对应代码中心和 dev 版本。
每个 CDB 条目必须能查到标准名、文档入口、代码事实源和负责人。
客户迁移路径
Veda Harness 不是先卖一个 Agent，而是先把企业工程协作的地基补齐。 没有版本、文档和任务边界，AI 的改动就很难被验证。
第一阶段：三个中心
先建立文档中心、代码中心和术语表，让项目资料、代码事实源和业务词汇有统一入口。
第二阶段：任务与检索
把任务计划、数据入口和向量检索接进来，让人和 AI 都能找到上下文、历史案例和阻塞点。
第三阶段：Agent 协作
当事实源和权限边界清楚后，再让 AI 通过受控接口参与修改、发布、验证和审计。
密钥不下发给 Agent，只允许受控代调用或短期注入。
生产发布、调度修改、数据写入和权限变更进入审批链。
源代码、文档、任务、运行结果和 Agent 动作都能回到审计记录。
源码工作区和发布运行时分离，避免开发中的临时状态污染生产。