内部开发者平台演练
本文演示一个以开发者入口、自助模板、平台 API 和交付体验为核心的内部开发者平台仓库，如何从需求澄清到 handoff / release 收口完整跑通。
1. 场景
- 仓库当前主要维护开发者门户、服务模板和平台集成能力
- 团队准备新增一个自助交付入口，并同步补齐模板行为与发布说明
- 目标不是做单点业务功能，而是把入口体验和交付链治理成可验证、可交接、可发布的状态
2. 推荐链路
/team-intake/team-plan/tdd/team-execute/handoff/team-review/team-release
3. 第一步：/team-intake
输入示例
text
/team-intake
目标：为内部开发者平台新增自助交付入口并补齐模板、验证和发布说明
范围：门户入口、平台 API、模板行为、测试计划、release 说明
不做：无关业务系统改造
约束：必须说明失败兜底、人工介入路径、权限边界和发布前提4. 第二步：/team-plan
需要拆清的动作
- 门户入口与模板行为
- 平台 API 与权限边界
- 失败兜底与人工介入路径
- handoff、review、release 收口方式
5. 第三步：/tdd
重点是先锁：
- 开发者入口成功 / 失败路径
- 模板与 API 的边界
- 人工介入条件
- QA 和 DevOps 需要接到哪些信息
6. 第四步：/team-execute
执行阶段通常包含：
- 调整门户或模板入口
- 调整平台 API 或编排逻辑
- 更新交付说明和发布前提
7. 第五步：/handoff
handoff 需要明确：
- 入口行为与验证范围
- 失败兜底和人工介入方式
- 剩余风险和发布依赖
8. 第六步：/team-review 与 /team-release
Review 阶段要回答
- 当前开发者自助体验是否已经稳定
- 是否仍有阻塞交付的集成风险
Release 阶段要回答
- 发布前提是什么
- 出现故障时如何退回人工路径或旧入口
9. 常见错误
- 只写 happy path，不写失败兜底
- handoff 不写清验证范围，导致 QA 重新摸索
- release 不说明入口切换与回退方式