跳到主要内容

第 00 篇 · 接入模式（Adoption Patterns）

这是整个框架最重要的一篇。 先读这篇,决定你的项目属于哪种模式,再去看对应的细节。

为什么需要"接入模式"​

真实世界的项目处于不同阶段。同一套方法论，直接照搬绝对行不通：

  • 绿地项目：可以从零建，全套按规范
  • 开发中项目：已经有代码了,不可能把历史全部重写
  • 运行迭代项目：有成熟流程,强行替换会破坏现有节奏
  • 稳态运维项目：只做维护,不需要完整的业务/开发流程

如果框架不对这四种情况做区分,就会出现：

  • ❌ "这套框架我们用不了"（觉得门槛高）
  • ❌ "没必要这么折腾"（觉得仪式感过重）
  • ❌ "我们已经有自己的流程了"（觉得冲突）
  • ❌ "我们项目太小了不需要这些"（觉得过度设计）

本篇就是解决这些顾虑的"接入指南"。

4 种接入模式​

项目生命周期:  立项   开发中   上线后·迭代   稳态运维
                │      │        │            │
                ▼      ▼        ▼            ▼
             模式 A  模式 B   模式 C       模式 D
             绿地   进行中   运行迭代     稳态维护
             全套   追溯补   增量嵌入     运维聚焦
             上车   当下开始  每版一层    仅关键层
模式文档判定嵌入策略
A · 绿地mode-a-greenfield.md项目刚立项全套上车
B · 进行中mode-b-mid-dev.md代码已开始,未上线追溯关键点,从今天按规范
C · 迭代中mode-c-iterating.md已上线,定期迭代每版本加一层
D · 稳态mode-d-maintenance.md只做维护只用运维篇

5 分钟判定流程​

按顺序回答这 5 个问题：

Q1. 项目是否已经有代码仓库和已运行的代码?
    否 → 模式 A (绿地)
    是 → 继续

Q2. 项目是否已经上线给用户使用?
    否 → 模式 B (进行中,代码存在但未上线)
    是 → 继续

Q3. 项目是否还在定期迭代新功能?
    是 → 模式 C (运行迭代)
    否 → 模式 D (稳态运维)

如果你卡在边界（比如"刚上线 1 个月"）:

  • 按 C 处理（迭代中）一般没错
  • 不确定时选更保守的那个（B 比 A 保守、D 比 C 保守）

模式选择矩阵​

你是什么团队推荐 mode为什么
创业公司新启项目A从 0 建,完整规范不嫌重
外包公司接新单A 或 B看项目阶段
大厂已立项未开发A从源头规范
老项目重构分支B代码存在但新方向可以规范
2B SaaS 每双周发版C渐进改造,保留现有节奏
电商/直播稳定运营C版本快,但迭代中加规范
传统企业已运营 5 年D只需把运维流程规范化
即将下线的旧系统D维护期,聚焦事故响应

公共能力（所有模式都可用）​

无论选哪种模式,以下资产都共享：

类别路径说明
方法论章节docs/chapters/01-05可选择性阅读
模板库templates/按需取用
AI Promptskills/29 个 Prompt
跨平台脚本tools/cross-platform/链接校验等
工具集成tools/integrations/Jira/Confluence/Slack/IM/GitLab
示例项目examples/对照学习

核心原则：框架不会强迫你用所有东西。每种模式会告诉你"必须 / 推荐 / 可选"，你按需取。

跨模式升级路径​

模式不是一成不变的。项目演进时,模式会流转：

A (绿地)  ──开发完成──►  B (进行中)  ──上线──►  C (运行迭代)  ──稳定──►  D (稳态)
                                                                              │
                                                                              ▼
                                                                        （新项目 回到 A）

升级时机：

  • A → B：进入编码阶段,开始有代码
  • B → C：首次上线生产
  • C → D：停止新功能开发,只做维护

升级时框架需要做什么：

  • A → B：把"理想化"的规范降到"现实化"的强度
  • B → C：把"一次到位"改成"每版本一层"
  • C → D：精简规范,聚焦运维

各模式的"不适用"场景​

每种模式都有适用边界。不适用的情况,别强行套。

模式 A 不适合​

  • ❌ 团队不接受"从 0 用完整规范"（先试试 C 的渐进模式）
  • ❌ 项目规模 < 5 人天（杀鸡用牛刀）
  • ❌ 纯脚本 / 探索性项目（不需要这么多流程）

模式 B 不适合​

  • ❌ 代码已上线（用 C 而不是 B）
  • ❌ 团队想全面重来（用 A 从新分支开始）

模式 C 不适合​

  • ❌ 项目还未上线（用 B）
  • ❌ 项目已冻结开发（用 D）

模式 D 不适合​

  • ❌ 项目还在定期迭代（用 C）
  • ❌ 要做大版本重构（回到 A 从新分支）

常见问题​

Q: 我不确定属于哪种模式?​

先读 5 分钟判定流程。如果还不确定：

  • 选更保守的（B > A, D > C）
  • 先试一周,觉得不合适换另一个

Q: 能不能混用多种模式?​

可以。不同子系统处于不同阶段时：

  • 老子系统用 D（维护）
  • 新子系统用 A（绿地）
  • 这两部分独立管理

Q: 全公司多个项目,怎么统一?​

不要追求"所有项目用同一模式"。按项目实际阶段分类即可,框架会带来一致性。

Q: 框架会不会太重?​

每种模式都有"最小可用集"。能做到 20% 已经有价值,别一上来追求 100%。

实施检查清单（通用）​

无论选哪种模式,都建议：

  • 读完自己对应 mode 的完整文档
  • 用 epcode init --mode=<X> 初始化（或手动按 checklist 建目录）
  • 团队内部分享（30 分钟）解释为什么用
  • 先用 2 周试跑,不大改
  • 2 周后复盘,微调
  • 每月 review 一次 mode 是否还适用（项目可能已经升级阶段）

相关资源​