适用场景#

适合使用完整交付工作流的场景：

• 用户给了飞书需求、工单或一段较完整的需求说明。
• 需要分析目标系统和目标仓库。
• 需求可能涉及多个仓库、共享组件、公共业务页、打印或基座。
• 需要完成方案、实现、验证和交付说明。

如果只是一个明确的单点修改，应该优先选择更小的 playbook。

7 步流程#

1
1. 读取需求
2
2. 判断系统和仓库
3
3. 判断跨仓影响
4
4. 制定修改方案
5
5. 实现最小闭环
6
6. 验证
7
7. 输出交付说明

1. 读取需求#

如果用户提供飞书链接，先读取内容，再判断目标系统。

如果用户只给文字需求，就提取：

• 业务目标。
• 用户动作。
• 页面或路由关键词。
• 接口路径。
• 状态、角色、异常路径。
• 是否涉及 UI、i18n、RTL、打印，以及是否明确进入发布阶段。

这一步的产物不是代码，而是需求要落到哪里。

2. 判断系统和仓库#

先按系统地图判断大类：

• 基座。
• 业务子应用。
• 公共业务页。
• 共享组件库。
• 打印运行时。
• 装修平台。

如果目标可能是 *-vue-international，必须查仓库职责清单。

判断结果应包含：

• 目标系统。
• 目标仓库。
• 置信度。
• 证据。
• 需确认事项。

3. 判断跨仓影响#

这些情况要特别注意：

当前工作区不可见的仓库，不能猜路径，只能说明缺少上下文。

4. 制定修改方案#

动手前先说明：

• 修改目标。
• 影响范围。
• 涉及文件。
• 实现步骤。
• 验证方式。

多文件或多模块改动必须列出文件清单。

5. 实现最小闭环#

实现时遵守全局约束：

• 不做无关重构。
• 不引入新依赖。
• 不删除兼容逻辑。
• 可见文案走 i18n。
• 样式兼顾长文本和 RTL。
• 接口路径含 /sellers 时默认按 /assistant 映射。
• sellerId 默认不由前端重复传递。

一个阶段只做一个可验证闭环，不留下半成品路径。

6. 验证#

按改动范围选择验证方式：

验证不是附加动作，而是交付的一部分。

7. 输出交付说明#

完成后用中文说明：

• 改了什么。
• 为什么这么改。
• 如何验证。
• 还有哪些需确认事项。

未经用户明确要求，不执行 git commit、git push 或发布。

可选发布阶段提醒#

国际需求开发默认从目标仓最新 pre 切出 feature/*。

禁止直接在 pre 上改需求代码。

发布不是默认交付主流程。只有任务明确进入发布或部署阶段时，才应用下面的规则。

普通国际仓发布到 OPMS 平台时：

1
任务分支 -> merge 到 pre -> push origin/pre -> 部署 branch/pre

不能直接部署 feature 分支，不能触发 gray、staging、pro、prod、tag、master 或 main 发布。

一句话总结#

完整交付工作流不是让 AI “快点写”，而是让 AI 先判断边界、再最小修改、最后验证交付。