---
title: 07-agentic-coding-workflow
description: 文本抽取：AI研讨会/07-agentic-coding-workflow
updated: 2026-11-04
tags: [原始文档, 抽取, AI研讨会]
source: AI研讨会/07-agentic-coding-workflow
source_type: txt
source_hash: e0b6da04e526
extracted_at: 2026-11-04
quality: ok
---

---
source: AI研讨会/07-agentic-coding-workflow.html
type: html
size_kb: 71
category: AI研讨会
quality: ok
---

从客户需求到上线改动｜Agentic Coding｜ShopEx
ShopEx Agentic Coding 开发方法论
01 起点
02 十八步流程
03 人工闸门
04 客户复用
打印 / 导出 PDF
07 · AGENTIC CODING
一线提交需求，
机制推到上线
商派把需求、任务、代码、测试和上线接成一条固定流程。一线员工把客户的话说准，机制往下推进，负责人只在三处做判断。采购商派代码包的企业，可以在自己的仓库里建同一套流程，用自己的负责人把三道闸门。
01 / 起点
过去一件需求要过五道手，每道重讲一遍
每过一道手都要重讲一遍背景，讲不清的地方只能靠猜。需求在谁手上、卡在哪一步，客户和一线都问不出来。
图 01 · 过去与这套方法逐项对照
上为两条交接链，下为七行对照；每行右端标签写明这一项由谁承担
过去的做法
这套方法
每过一道手重讲一次
过去的做法与这套方法的七项对照
上半部两条交接链对照。左侧为过去：客服接诉求写工单、产品整理需求文档、研发拆任务改代码、测试再验一遍、上线进度说不清，五道手之间用红色虚线相连，表示每过一道就重讲一次背景。右侧为这套方法：客服提交需求卡、机制推进十六步、三处人工闸门、上线回流结果回需求卡，四段之间用蓝色实线相连。下半部七行对照，中间一列为对照维度，左列为过去的做法，右列为这套方法，每行右端有一枚小标签写明由谁承担。谁发起：过去客服写完工单转给产品，能不能做由产品判断，现在客服直接提交需求卡，机制判断怎么做；需求怎么传：过去口头、群聊、文档多道转手，每道手重讲一遍背景，现在需求卡进仓库，一处一份，谁看到的都是同一份；谁去找代码：过去研发自己翻模块、翻历史改动，现在机制读业务概念库与代码结构库，给出改动范围；谁写改动：过去研发逐行写，测试另开一轮，现在机制生成改动与测试，人审结果；进度在哪：过去靠问人，答不上来是常态，现在状态留在仓库里，随时可查；判断在哪：过去每一道手都要参与，判断分散在各处，现在三处判断：业务确认、技术审核、发布确认；经验去哪：过去留在当时的聊天和文档里，换人重来，现在沉淀为规则、模板与检查项，进资产库。底部收口条写明同一件事过去经五道手五次重讲，现在一处提交、机制走完、人在三处判断。
过去 · 五道手，每道手重讲一遍背景
这套方法 · 一处提交，机制走完，三处判断
客服
接诉求写工单
产品
整理需求文档
研发
拆任务改代码
测试
再验一遍
上线
进度说不清
客服提交
需求卡五项
机制推进
16 步自动走
三处闸门
人工确认
上线回流
结果回需求卡
过去的做法
五道手接力，每道手重讲一遍背景
对照维度
这套方法
一处提交，机制推进，人在三处判断
客服写完工单转给产品，能不能做由产品判断
产品定夺
谁发起
客服直接提交需求卡，机制判断怎么做
机制判断
口头、群聊、文档多道转手，每道手重讲一遍背景
各道手
需求怎么传
需求卡进仓库，一处一份，谁看到的都是同一份
需求仓库
研发自己翻模块、翻历史改动
研发
谁去找代码
机制读业务概念库与代码结构库，给出改动范围
机制定位
研发逐行写，测试另开一轮
研发＋测试
谁写改动
机制生成改动与测试，人审结果
机制生成
靠问人，答不上来是常态
靠问人
进度在哪
状态留在仓库里，随时可查
仓库状态
每一道手都要参与，判断分散在各处
各道手
判断在哪
三处判断：业务确认、技术审核、发布确认
三处人
留在当时的聊天和文档里，换人重来
留在个人
经验去哪
沉淀为规则、模板与检查项，进资产库
资产库
同一件事，过去经五道手、五次重讲；现在一处提交，机制走完，人在三处判断
读图说明
左边七项全靠人，右边六项由机制或仓库承担，人只留在「判断在哪」这一项。
解读边界
右侧成立的前提是业务概念库与代码结构库已建起来。资产没到位，「谁去找代码」仍要靠研发补位。
需求卡、任务、改动、检查结果、上线记录都在同一个仓库里。找人问进度这件事，交给系统状态去答。
02 / 十八步
一件需求拆成十八步，其中十六步自动走
一个需求从进门到上线拆成十八步。每步都有固定输入、固定产出和固定落点；步骤不跳、顺序不错，谁在哪一步、卡在什么地方，都留下记录。
图 02 · 十八步详细流程图
带内 S1—S18 即执行顺序；带左侧 01—06 是六个阶段；带间琥珀横条是三道闸门
一个需求从入门到上线的十八步详细流程图
六条横带自上而下依次为 01 需求说准、02 校验建档、03 拆解定位、04 改动检查、05 预发验证、06 上线回流。01 需求说准含两步，由一线员工完成：S1 接单留痕，S2 补全五项。02 校验建档含两步：S3 结构校验，S4 编号与版本。03 拆解定位含四步：S5 语义抽取，S6 概念对齐，S7 影响面定位，S8 任务草稿。04 改动检查含五步：S9 建工作区，S10 生成改动，S11 生成测试，S12 基础检查，S13 机制预审。05 预发验证含三步：S14 集成检查，S15 预发部署，S16 核心链路验证。06 上线回流含两步：S17 发布上线，S18 回写与沉淀。前三段与后三段之间、以及各段之间共有三条琥珀横条，分别是闸门一业务确认、闸门二技术审核、闸门三发布确认。带间另有两条白底说明条，写明需求卡进入校验、可以拆任务。底部收口条写明十八步里一线发起两次、回复一次，负责人出面三次，其余由机制走完。
交付与沉淀
人工闸门
机制自动推进
一线员工
01
需求说准
一线发起
S1
接单留痕
客户原话、渠道、时间、客户名一次记全，不留待补。
客户说得含糊的地方当场问清，不往后带。
产出：需求卡草稿，落在需求仓库
S2
补全五项
客户、场景、问题、期望结果、验收方式，五项填齐。
验收方式要写清怎么算通过，不能只写「更好用」。
产出：需求卡，五项齐全
02
校验建档
机制接手
S3
结构校验
校验五项是否填齐、验收方式能不能验，缺项直接打回上一步。
把写进需求卡的实现方案提示移出，需求卡只讲问题与验收。
产出：校验结果；缺项自动打回
S4
编号与版本
分配唯一编号，写下第一条版本记录。
此后每次改动都留痕，谁改的、改了什么都能查到。
产出：需求编号与版本记录
03
拆解定位
机制拆解
S5
语义抽取
抽出业务对象、动作、规则与验收点。
要动哪些单据、走什么口径、
按什么条件判定。
产出：需求要素清单
S6
概念对齐
拿业务名词比对业务概念库，
把客户口语对上系统术语。
对不上的标出来，退回一线确认。
产出：术语对照表
S7
影响面定位
拿术语去代码结构库定位
模块、文件与模块负责人，
列出要动的范围。
产出：改动范围清单
S8
任务草稿
拼成任务清单，每条带仓库、
文件、依赖、工作量预估、
对应功能点与建议测试场景。
产出：可审核的任务草稿
04
改动检查
机制生成
S9
建工作区
按任务开分支、建工作区，
把需求卡、任务清单与
模块规范一起带上。
产出：独立工作区
S10
生成改动
按任务生成代码改动，
每处标注出处：对应
哪条任务、哪条规则。
产出：一版改动
S11
生成测试
按建议场景生成单测与
接口测试，覆盖正常路径
与需求卡里的边界条件。
产出：测试用例
S12
基础检查
跑静态检查、编译与团队
硬规则：金额口径、SQL
访问、日志与权限。
不通过自动打回上一步
S13
机制预审
在真实改动上做一轮审查，
给出问题清单与风险点，
标出建议重点看的地方。
产出：预审建议，不阻断
05
预发验证
机制验证
S14
集成检查
合并到集成分支，跑完整构建与存量测试。
构建不通过，直接退回改动环节。
产出：构建结果
S15
预发部署
部署到预发环境，按需求卡里的场景准备数据，
不靠手工点。
产出：可验证的预发环境
S16
核心链路验证
按需求卡的验收方式逐条跑核心链路，归档产物。
初期只告警，不阻断发布。
产出：验证结果与产物
06
上线回流
交付沉淀
S17
发布上线
改动进入正式环境，发布记录与需求编号绑定。
出问题时顺着编号就能回到当初的需求卡。
产出：上线记录
S18
回写与沉淀
结果回写原需求卡，客户与一线看到同一份。
本次用到的规则、检查项、测试场景沉淀成资产。
产出：客户回复 + 资产入库
五项齐全的需求卡，进入校验
校正过的需求卡，可拆任务
闸门一 · 业务确认
客服与业务负责人　看：需求卡是否说出客户的真实意思，验收方式能不能验证
闸门二 · 技术审核
模块负责人　看：影响范围、业务逻辑，以及有没有改到不该改的地方
闸门三 · 发布确认
发布负责人　看：检查结果与预发验证是否达标
十八步里，一线发起两次、回复一次，负责人出面三次，其余由机制走完
读图说明
带内每个方块是一步，S1 到 S18 就是执行顺序；带间琥珀横条是三道闸门。每步下方的灰字写着产出与落点。
解读边界
步骤划分来自商派自身实践，客户侧可按自己的组织分工调整闸门人选。检查项与规则要先积累，机制才走得动。
十八步逐条
步骤谁做这一步具体做什么产出与落点
| 01 需求说准 · S1–S2
| S1 接单留痕 | 一线 | 记全客户原话、渠道、时间与客户名；含糊的地方当场问清 | 需求仓库里的需求卡草稿
| S2 补全五项 | 一线 | 把客户、场景、问题、期望结果、验收方式五项填齐 | 五项齐全的需求卡
| 02 校验建档 · S3–S4
| S3 结构校验 | 机制 | 校验五项是否填齐、验收方式能不能验；把实现方案从需求卡里移出 | 校验结果；缺项打回 S2
| S4 编号与版本 | 机制 | 分配唯一编号，写下第一条版本记录 | 需求编号与版本记录
| 03 拆解定位 · S5–S8
| S5 语义抽取 | 机制 | 抽出业务对象、动作、规则与验收点 | 需求要素清单
| S6 概念对齐 | 机制 | 拿业务名词比对业务概念库，把客户口语对上系统术语 | 术语对照表；对不上的退回一线确认
| S7 影响面定位 | 机制 | 拿术语去代码结构库定位模块、文件与模块负责人 | 改动范围清单
| S8 任务草稿 | 机制 | 拼成任务清单，带仓库、文件、依赖、工作量预估与建议测试场景 | 任务草稿
| 闸门一
业务确认 | 客服与业务负责人 | 只看一件事：需求卡是否说出了客户的真实意思，验收方式能不能验证 | 通过后进 S9；不通过退回 S2
| 04 改动检查 · S9–S13
| S9 建工作区 | 机制 | 按任务开分支、建工作区，把需求卡、任务清单与模块规范一起带上 | 独立工作区
| S10 生成改动 | 机制 | 按任务生成代码改动，每处标注对应哪条任务、哪条规则 | 一版代码改动
| S11 生成测试 | 机制 | 按建议场景生成单测与接口测试，覆盖正常路径与边界条件 | 测试用例
| S12 基础检查 | 机制 | 跑静态检查、编译与团队硬规则：金额口径、SQL 访问、日志与权限 | 检查报告；不通过打回 S10
| S13 机制预审 | 机制 | 在真实改动上做一轮审查，给出问题清单与风险点 | 预审建议，不阻断流程
| 闸门二
技术审核 | 模块负责人 | 只看一件事：影响范围与业务逻辑边界，有没有改到不该改的地方 | 通过后进 S14；不通过退回 S10
| 05 预发验证 · S14–S16
| S14 集成检查 | 机制 | 合并到集成分支，跑完整构建与存量测试 | 构建结果；不通过退回 S10
| S15 预发部署 | 机制 | 部署到预发环境，按需求卡里的场景准备数据 | 可验证的预发环境
| S16 核心链路验证 | 机制 | 按需求卡的验收方式逐条跑核心链路，归档产物 | 验证结果与产物；初期只告警
| 闸门三
发布确认 | 发布负责人 | 只看一件事：检查结果与预发验证是否达标 | 通过后进 S17；不通过退回 S14
| 06 上线回流 · S17–S18
| S17 发布上线 | 机制 | 改动进入正式环境，发布记录与需求编号绑定 | 上线记录
| S18 回写与沉淀 | 机制 | 结果回写原需求卡；用到的规则、检查项、测试场景沉淀成资产 | 客户回复 + 资产入库
机制卡住时往哪退
卡在哪一步谁决定退回退到哪一线要不要管
| 需求卡缺项，或验收方式说不清 | 机制自动打回 | 退回 S2 补卡 | 要，补齐即可
| 业务名词在概念库里对不上 | 机制标记待确认 | 退回一线确认术语 | 要，确认一句
| 影响面定位不到模块 | 机制标记人工确认 | 指定模块后继续 | 不用，机制找模块负责人
| 基础检查或构建不通过 | 机制自动打回 | 退回 S10 重新生成 | 不用
| 预发核心链路告警 | 机制归档并通知 | 退回 S10 或 S14 | 不用
客服实际要做的六件事
客服的动作要做的事不需要知道的事
| 听清 | 把客户原话、渠道、时间记进需求卡，含糊的地方当场问清 | 不用判断这个需求技术上做不做得到
| 补齐全五项 | 客户、场景、问题、期望结果、验收方式 | 不用写实现方案，也不用估工作量
| 提交 | 把需求卡提交到需求仓库 | 不用知道改哪个仓库、哪个模块
| 回应打回 | 校验缺项时补齐；术语对不上时确认一句 | 不用看懂代码与表结构
| 闸门一确认 | 确认需求卡说的是客户的真实意思 | 不用审技术方案
| 回复客户 | 结果回写原需求卡后，把处理结果告诉客户 | 不用解释改动是怎么做出来的
客服不需要会写代码，他负责把客户的话说准。剩下十六步由机制完成，客服只在上面六处出现，每次出现都是把客户的话说清。
图 03 · 谁在什么时候出场
横向是 S1 到 S18，纵向三条轨道共用同一条时间轴
一线员工
机制自动推进
人工闸门
十八步里一线员工、机制与负责人的出场分布
横向时间轴为 S1 到 S18 十八个步骤，上方按六个阶段分段标注：01 需求说准含 S1 至 S2，02 校验建档含 S3 至 S4，03 拆解定位含 S5 至 S8，04 改动检查含 S9 至 S13，05 预发验证含 S14 至 S16，06 上线回流含 S17 至 S18。纵向第一条轨道为一线员工，只在 S1 与 S2 以及 S18 出现，中间十六步不需要一线在场。第二条轨道为机制自动推进，从 S3 连续走到 S18，承担拆解任务、生成改动与测试、跑检查、上预发、验证、发布与回流。第三条轨道为人工闸门，在 S8 与 S9 之间、S13 与 S14 之间、S16 与 S17 之间各出现一次，分别是闸门一业务确认、闸门二技术审核、闸门三发布确认。底部说明条写明一线动手两次、回复一次，负责人出面三次，其余十六步由机制连续走完。
01 需求说准
02 校验建档
03 拆解定位
04 改动检查
05 预发验证
06 上线回流
S1
S2
S3
S4
S5
S6
S7
S8
S9
S10
S11
S12
S13
S14
S15
S16
S17
S18
一线员工
机制自动
人工闸门
发起需求
回复
中间十六步不需要一线在场
机制自动推进：拆解、改动、测试、检查、预发、验证、发布、回流
闸门一 业务确认
闸门二 技术审核
闸门三 发布确认
十八步里，一线动手两次、回复一次；负责人出面三次；其余十六步由机制连续走完
读图说明
紫色只出现在头两格和最后一格，中间十六格是蓝色，琥珀三点就是三道闸门。
解读边界
机制那条轨道能连续走满十六步，前提是底座资产已经建起来；资产没到时对应步骤要人工补位。
03 / 人工闸门
全流程人只出面三次，每次只看一件事
三道闸门之外，流程不需要人盯着。每道闸门只看一件事，判断标准提前写进需求卡与检查项，不靠临场印象。
闸门谁来把看什么不通过怎么办
| 闸门一
业务确认 | 客服与业务负责人 | 需求卡是否说出了客户的真实意思，验收方式是否能验证 | 退回重写，不进入任务拆解
| 闸门二
技术审核 | 模块负责人 | 影响范围、业务逻辑，以及有没有改到不该改的地方 | 打回改动，任务重新生成
| 闸门三
发布确认 | 发布负责人 | 检查结果与预发验证是否达标 | 不发布，记录原因，回到改动环节
负责人没确认，需求不会进入下一段；机制不替人做判断，也不会空转等人。
04 / 客户复用
商派自用的开发流程，也随产品交付客户
采用商派代码包的企业，在自己的仓库和知识库里建起同一套流程：需求模板、业务概念库、代码结构库、规则与检查资产都由客户自己维护。客户的一线员工同样可以发起需求，三道闸门由客户自己的负责人把。
图 04 · 商派自用与客户自用
商派用的流程与三道闸门不变，换成客户的仓库、客户的负责人
商派自用
共用机制
客户自用
商派自用与客户自用共用同一套开发机制的双形态总览图
顶部两个使用者卡：左侧为商派自己的产品团队，使用者是客服、售前、实施、产品与研发；右侧为采用商派代码包的客户团队，使用者是客户的业务人员与 IT。中部虚线形态层内并列三块：左臂商派自用，写明需求卡进 product-docs 仓库、机制按业务概念与代码结构拆任务、改动与上线记录可追溯；中央是两者共用的同一套机制，写明 Document as Code，需求任务代码测试上线一处一份、三道闸门不变、资产随每次需求增长；右臂客户自用，写明客户在自己的代码包里建仓库与模板、业务概念库与代码结构库按客户系统重建、三道闸门由客户自己的负责人把。左臂与右臂用短箭头连接中央。下方共用底座虚线框内六个胶囊：需求模板与校验、业务概念库、代码结构库、规则与 Skill 库、测试与检查资产、上线回流记录。底部深色收口条写明同一套机制换换成客户的系统和负责人照样跑得起来。
A
商派自己的产品团队
客服、售前、实施、产品、研发：同一份需求卡，同一套闸门
B
采用商派代码包的客户团队
客户的业务人员与 IT：在自己的仓库与知识库里建同一套流程
商派自用
在自己产品上跑
· 需求卡进 product-docs 仓库
· 机制按业务概念与代码结构拆任务
· 改动、检查与上线记录可追溯
需求模板
任务草稿
改动生成
检查与预发
同一套机制
Document as Code
需求、任务、代码、测试、上线
一处一份，可追溯到源头
三道闸门不变：业务确认、
技术审核、发布确认
资产随每次需求向前增长
客户自用
在客户环境里跑
· 客户在自己的代码包里建仓库
· 按客户系统重建概念库与结构库
· 三道闸门由客户的负责人把
客户需求模板
客户资产库
共用底座
两边的机制读同一类资产，只是资产内容各自维护
需求模板与校验
业务概念库
代码结构库
规则与 Skill 库
测试与检查资产
上线回流记录
商派自己用的流程，换成客户的系统和负责人，照样跑得起来
读图说明
左边是商派自己的产品团队，右边是采购了代码包的客户团队；中间灰块是两边共用的部分。
解读边界
客户侧落地前要先建业务概念库与代码结构库，通常从一条主链路开始。组织分工与闸门人选由客户确定。
商派自己用的这套流程，客户可以在自己的仓库里照着建一遍。流程与三道闸门不变，换成客户的仓库、客户的负责人。← 返回总览第 07 章
ShopEx 商派 · Agentic Coding 开发方法论
第 07 章独立页 · 十八步流程与三道闸门
配合阅读：第 08 章商派 AI 产品矩阵
返回总览：商派的 AI 进化之路