# 项目管理标准（AI 协作开发 · 大型项目长期维护）

**取用与版本。** 标准正文、模板与检查器随 DeepSeek Harness 插件分发（装法与升级见 [tools/std/README](../tools/std/README.md)），版本由安装时钉的标签与 profile 的锁定文件承担，不再有“采用项目手写一份版本声明”这一步；裁剪登记记进 `governance/project.yaml` 的 `tailoring`。**本目录此后的修改不自动对已采用项目生效**，升不升级、升到哪一版由采用项目自己决定。本目录修订不改变研究正文的生效登记。

这套标准回答一件事：**一个由人和 AI 编程工具共同开发的大型软件项目，怎样在多年后仍然能被继续维护。** 它覆盖项目管理、架构描述、Agent 协作，以及上线后的可靠性、安全和恢复责任；不规定通用代码风格，不绑定某个工具。

## 标准与示例

| 文档 | 回答的问题 | 什么时候读 |
|---|---|---|
| [01 项目管理标准](01-项目管理标准.md) | 项目里要有哪些文档、它们之间什么关系、日常怎么管（任务、会话、变更、评审、发布、事故、周期维护）、开发约束是什么、长期衰减怎么对抗 | 采用时由人通读一次；agent 会话不通读，只读被引用的节 |
| [02 项目架构描述规范](02-项目架构描述规范.md) | 一个大型项目的整体架构怎么写下来才能被人和 agent 当导航与约束用：模块、依赖方向、契约、数据所有权、不变量、决策、漂移检测、演进 | 写或改架构文档、模块文档、契约、ADR 时 |
| [03 Agent 信息获取与上下文管理](03-Agent信息获取与上下文管理.md) | agent 怎么从项目文档里高效拿到当前判断需要的信息、怎么控制每次推理看见什么、压缩与交接怎么做、子执行者怎么委托、记忆怎么沉淀 | 配置工具入口、写工作项的上下文清单、排查"agent 读错了/读多了/读丢了"时 |
| [04 可靠性、安全与运行维护](04-可靠性安全与运行维护.md) | 两类运行责任：**产品的**——服务目标、错误预算、告警与事故、恢复演练、数据生命周期、漏洞与依赖追溯、渐进发布、容量；**AI 这条生产线自己的**——[一次 agent 运行失败凭什么查得出来](04-可靠性安全与运行维护.md#agent-run-observability)、AI 产出能否当证据、运行开销归谁、[人不在场时能推进到哪一步](04-可靠性安全与运行维护.md#unattended-operation)；以及[产品自身内含模型能力](04-可靠性安全与运行维护.md#model-capability-in-product)时多出来的那份责任 | 首次上线、重大变更、故障、依赖更新与周期维护时；把 AI 纳入常规研发或发布流程时 |
| [示例项目：连锁零售中台](示例项目-连锁零售中台/README.md) | 上述标准在虚构大型项目里的工件形态：[维护时间线](示例项目-连锁零售中台/维护时间线.md)、[一次高影响任务的完整走法](示例项目-连锁零售中台/一次任务的完整走法.md)、[运行维护计划](示例项目-连锁零售中台/docs/operations/README.md)与[反馈跨任务生效演练](示例项目-连锁零售中台/反馈跨任务生效演练.md) | 想看规则怎样落入任务、工件和验证时，按需读对应示例；不作真实效果证据 |

## 先记住的四句话

1. **项目的真相存在于仓库里可被机器和人重新读到的工件中**，不在任何人的记忆或任何工具的聊天记录里。
2. **每类事实只有一处权威位置**；第二处是副本，副本必然漂移。
3. **每个结论都是“结论 + 成立条件”**；按 [01 的三态判据](01-项目管理标准.md)区分确认失败、证据支持与无法判定，不把未知折算成通过。
4. **每条规则绑定已观察失败或可追溯的风险，以及复查/删除条件**；不必等发生事故才预防，也不能虚构事故证明规则必要。

## 采用顺序

1. 读 01 §3 明确入口、验收、状态的权威位置；地图和命令入口可合并，按职责建立，不按完整树一次铺满。
2. 按 02 写系统全景、模块清单与依赖规则；契约登记表先登已有的。**存量项目没有架构文档时，从 [02 §1.1 反向测绘](02-项目架构描述规范.md#reverse-mapping) 起步**——按被改动的模块增量补，条目标可信度，不先补全历史。
3. 按 03 配工具入口与默认加载合同；第一次真实运行只用这几份文件。
4. 有生产或持久数据时按 04 补运行责任与恢复、安全、发布前提；从一条关键旅程开始，不统一承诺采用时长。AI 已进入常规研发流程的，同时补 04 §6 的运行记录——**没有运行记录，后面所有关于 AI 的判断都只能记未定**。
5. 用真实失败或可验证风险完善知识与检查，按 01 的维护周期处理债务和规则减法。
6. 试点结束时按[试点通过条件](覆盖与采用检查.md#pilot-exit)走查六条并逐条给三态，不把"我们在用这套标准"当成结论。

## 逐篇研究怎样继续

[资料索引](参考资料/README.md)记录每篇原文、阅读边界、采用理由与修改落点；[覆盖与采用检查](覆盖与采用检查.md)指出已有内容、可走查工件和真实项目仍需补的证据。研究卡不进入项目默认上下文，查依据时再读。

一次只处理当前方向的一篇资料：**读正文 → 写卡 → 修改标准 → 检查落点 → 再下一篇**。不同方向可并行，写入文件应分开，入口与共享状态由一人收口。没有新增适用结论的文章可以明确“不采纳”，不为凑数量加规则。断点见[覆盖与采用检查·调研断点](覆盖与采用检查.md#research-breakpoints)；两轮与各专项的检查记录已归档为本轮完善记录（标准仓 `docs/审计记录/本轮完善记录.md`），归档区不承担更新义务。

第二轮的实际分布值得记住，它决定后续该找什么材料：**真实项目公开出来的规范与审计文档**（转述层数 0，其中记录的已定责缺陷是最强的一类依据）和厂商一手材料贡献了多数可检查条款；二手综述里有三篇整篇不采纳；观点评论零采纳；一篇论文回校的作用是**把已经写进标准的表述收紧**而不是新增。找一份真实项目的工程文档，胜过再读十篇讲方法论的文章。

## 与本仓库正文的关系

本目录是本仓库正文（四平面十四部件）的候选实现，补充真实产品维护所需的项目工件与流程。04 是实现专题，不新增研究架构的一等部件。研究正文的效力仍只查生效登记；本目录效力为零，不阻断或授权本仓库决策。采用项目应明确自己批准的范围、责任和例外；存在实质冲突应登记，不能借本目录文字绕过生效约束。

## 许可

本目录（`标准/`）与 `templates/` 的正文与模板按 **CC BY 4.0** 授权，`tools/std/` 及本仓库中的一切代码按 **MIT** 授权；文中引用的第三方材料版权归原作者，本目录只按各卡登记的边界引用，不改变其许可。

署名写法：`Alan-IFT, dsh-project-std`。许可全文见仓库根目录的 `LICENSE`（MIT）与 `LICENSE-DOCS`（CC BY 4.0）两个文件。