背景

"五高"系统带来的AI Coding挑战

营销系统是电商基础链路中的核心系统之一，通过全站的价格计算、优惠使用等核心能力，承载着网站价格力的核心使命。营销系统本身也承载着跨境电商中最复杂的业务逻辑之一，数十种营销工具，几十个业务方，以及上百种业务定制。同时在跨境场景下，因多时区、多币种、多国家、多商业模式等客观因素，营销系统进一步面临更多的挑战。

综合来看，营销系统具备典型“五高”系统特征：

1. 系统流量高 —— 网站页面价格均要溯源到营销平台，承载接近全站价格计算流量。
2. 业务复杂度高 —— 每次计算涉及上百个业务场景，数十种工具的交叉计算。
3. 稳定性要求高 —— 对线上问题零容错，一行逻辑错误就可能导致系统崩溃，甚至资损。
4. 性能敏感度高 —— 面向全站提供基础的算价服务，稍有性能劣化，就会极大影响用户体验。
5. 机器成本高 —— 流量高、优惠多、叠加逻辑重，注定了营销域是一个成本大户。

在大模型发展日新月异，AI Coding技术日益成熟的大背景下，如何在电商营销中高质量地落地AI Coding，并形成可持续、可验证的研发提效，是值得我们探索的核心命题。

在这类系统上做AI Coding，通用方案很难直接适用。业务复杂度高，隐藏约束多，代码结构庞杂——AI面对的不是"能不能写出来"的问题，而是"不知道该写什么、写在哪里"的问题。

SDD新范式

我们采用SDD（规约驱动开发）作为方法框架，整体流程基于Spec传递上下文，分步骤完成需求。

AAIC（AE AI Coding）是我们在 AE 技术部内部对 SDD 的工程化实现。它以 Spec 作为上下文载体，通过 Command 编排 explore、propose、apply、test 四个阶段，并在各阶段引入知识库、Skill 和 SubAgent，完成从需求理解到编码测试的闭环。

实践中我们认识到：AAIC 基于 SDD 提供了一套非常清晰的工程化流程，让 AI Coding 从一次性的对话式生成，升级为可编排、可复用、可验证的研发工作流。但要让这套流程在复杂业务系统中发挥更大的价值，关键还在于 AI 在每个阶段能够获得什么样的业务知识。

AI应用本质是「上下文的管理+领域知识的注入」，AI Coding 的产出质量不只取决于“模型本身有多聪明”，更取决于“它看到的世界+知识是什么样的”：

1. AAIC解决流程问题：如何组织研发流程，流程间各Agent信息如何互通。
2. 营销领域解决知识问题：知识决定以及判断出流程执行是否准确、产出是否可靠。

案例介绍

下文中，我们将采用营销域《品类新智能加投》作为例子，来说明我们构建业务知识体系的思考与探索。

需求例子描述如下：

在营销计算的流程中，在补贴优惠的补贴率的基础上，如果用户拥有加投资质，则给用户上浮补贴率（以资质中加投比例为最终优惠数据）。

需求改动范围：“动态 Ticket 加投”是该需求中的核心改动场景。

案例说明：比如原优惠的补贴率为10%，用户拥有一个上浮50%的买家资质，则最终优惠的补贴率为15%【计算公式：10% * (1+50%)】。

人工梳理后共涉及以下7个关键改动点：

1、识别出加投类型的用户资质数据。

2、识别出允许加投的活动实例信息。

3、识别活动和资质信息，将其进行匹配关联。

4、找到优先级最高的一个资质。

5、基于匹配到的资质数据，修改活动实例的折扣率信息。

6、对于未匹配到加投资质的活动，正常进行活动计算。

7、将原始折扣率、加投资质信息、加投比例等数据写入订单优惠快照，用于后续对账和统计。

演进概述

阶段1——基于「代码分层结构」构建知识库

核心思路：基于技术架构建立知识库

回到" 它看到的世界+知识是什么样的 "这个问题，我们的第一种尝试是从「 技术架构（架构分层） 」视角建立知识库。既然AI要开发我们的系统，AI需要知识，那么就把系统的代码结构梳理清楚，沉淀成知识库，让AI沿代码架构的分层，逐层定位改动点。

我们尝试按照技术架构构建分层知识树。AI拿到PRD之后，沿树逐级下探，不再进行全量扫描，每一层都在缩小范围：

实际验证：技术视角的局限性

使用《品类新智能加投》来尝试，发现存在如下问题：

1. AI共匹配出19个候选改动点，但是其中只有1个是实际需要修改的，另外18个都是错误匹配，精确率仅为 5.26% 。
2. 预期的7个改动点，仅仅成功匹配到了1个增加优惠快照的定制，召回率仅 14.28% 。

对于技术类改动，比如要对某个接口基于场景添加限流，基于系统分层架构的知识，AI能够很好地帮我们实现代码。但是在类似《品类新智能加投升级》等业务需求中，AI 定位呈现明显的过度召回问题，精确率和召回率均显著偏低，整体效果 不达预期 。

思考：技术视角与业务视角的不匹配

结论：技术视角的代码分层知识有其价值，但对于业务维度的需求改动，需要使用更贴近需求语言的知识（领域知识）。

经过对整个流程中AI思考决策过程的梳理，我们发现了一个问题： PRD用的是业务语言， 代码分层知识 用的是技术语言，两者之间存在明显的Gap 。这并非AI理解能力的问题，而是信息结构上的不对称： 也许单纯提升模型能力很难从根本上解决，如何让营销知识库包含足够详尽的业务知识是值得探索的 。

PRD不会关心改动的接口、流程、领域，而只会关心业务表现从什么变成什么，但代码分层结构体现的却是技术维度的接口、流程等信息。

在《品类新智能加投》的探索中，知识库从技术层面描述了我们的代码分层逻辑，让AI知道系统中存在算价接口，资产冻结接口，以及接口中有查询优惠，分组计算等流程。但是AI并不知道系统中有“动态Ticket”这种业务玩法，也不知道如果想增加一个动态Ticket的玩法定制，需要在哪里修改，如何修改等等，所以AI面对PRD中描述的这些改动逻辑会束手无策。

其实回过来想想，我们技术人员做的，不也是通过个体掌握的领域知识+架构知识，将产品的业务语言翻译成代码这件事吗？

营销平台是一个复杂多样的业务系统，其内部存在大量的业务逻辑。这些业务逻辑是如何相互作用的，不同的接口之间是如何协作的，这些业务逻辑，很难在代码分层结构层面描述清晰。

因此采用「技术视角下的知识库」去进行逐层探索定位，无法精准定位到改动位置，反而因为大量不相关知识，导致读取越多越容易产生偏差。

阶段2——基于「业务知识」构建知识库

核心思路：以业务能力为核心载体

我们开始寻找知识组织的新方式，天然就和PRD的语言对齐。既然 PRD 使用的是业务语言，那么知识库也应该从业务语言出发。通过「业务知识」来抽象总结离散在系统内的代码，站在业务视角，我们发现所有代码逻辑可以清晰地二分为两类：

• 平台类逻辑：即平台能力 。描述系统能支持做什么事情，相对稳定，可枚举。
• 业务定制逻辑：即业务差异化实现 。在平台逻辑的基础上，具体业务场景根据诉求，进行细节设计。

在《品类新智能加投》案例中：

1.平台类逻辑：动态Ticket优惠。

2.业务定制逻辑：品类新场景，动态Ticket优惠根据资质进行优惠力度加权。

关键设计：如何构建业务知识

谁来定义

业务能力不能由技术单方面定义，必须产品和技术共同确认。本质上这是双方建立统一语言的过程。一个好的业务能力定义准则：产品说出一个需求，技术能立刻匹配到具体的能力和实现边界。

怎么定义

业务能力本质是连接产品认识和代码实现的桥梁。比如在营销系统，我们定义了优惠资质、优惠面板、单品金营销工具等业务能力，整体上有两大特点：

1. 首先一定是产品可理解的，必须贴合业务语义，不能是纯技术的，这样才能让AI更好地和PRD匹配。
2. 其次能力的定义，一定是平台视角沉淀的，可被多个业务场景复用的，描述的是"支持什么"，这一点必须和描述"怎么实现"的具体的业务实现区分开。

知识的作用

我们构建的业务能力知识库，简单来说是PRD与系统代码之间的桥梁。通过业务能力知识库，能够让PRD更好地映射到代码。因此业务能力知识库，应当描述「核心概念」、「应用场景」、「定制逻辑的位置」、「定制逻辑的说明」等，这样AI才能通过PRD映射到业务能力的知识，进而找到对应的代码逻辑和改动位置。

如上图，业务知识中包括两个核心的要素：

• 业务能力描述：用于匹配PRD。
• 定制逻辑描述：用于引导AI在能力对应的代码中进行探索。

动态Ticket知识

基于这个方案，我们构建了《品类新智能加投升级》需求中所需要的动态Ticket能力的知识：

# 动态Ticket
## 1. 定义
| 名称 | 说明 |
|------|------|
| 职责描述 | 处理用户持有的**动态优惠资质**（PRD 中常称 pt / promotion ticket / 模板维度 pt）的全流程业务定制能力。当需求涉及「用户需持有某种 ticket资质 才能命中优惠」，
或「基于 pt 上的属性（如加深系数、膨胀系数）影响优惠计算」时，均属本能力范畴。覆盖全链路营销、摇一摇、拿样、满件减、一品一券等所有需通过 ticket 驱动优惠命中的场景。 |
## 2. 职责
统一编排 ticket 优惠命中的全流程，各阶段存在严格的数据依赖与执行顺序：
```
准入校验 → 分类 → 认领 + 解析活动ID → 统一查询动态活动 → 排序 → 匹配增强 → 兜底校验 → 返回 promotions
```
- **准入校验**：分类前补充 staticTicketPromotions
- **分类**：BuyerResource → categoryBuyerResourceMap，产出后续遍历维度
- **认领 + 解析活动ID**：按分类遍历，产出 claimedPromotionMap + activityIds
- **排序**：按分类定制匹配顺序
- **匹配增强**：写入 ticketId、调整金额/权益
- **兜底校验**：对未命中 ticket 的优惠决定去留
## 3. 定制内容说明
| 阶段 | 处理环节 | 定制内容 |
|------|--------|----------|
| 准入 | 自定义准入校验 | 分类前补充 staticTicketPromotions |
| 分类 | 动态Ticket分类 | 按业务场景拆分 ticket 类型，产出分类维度 |
| 数据准备 | 实例认领 | 将静态活动归属到 ticket 上，产出 claimedPromotionMap |
| 数据准备 | 解析关联活动ID | 从 ticket 字段解析动态活动 ID |
| 排序 | 定制业务排序规则 | 决定匹配顺序（如多张 pt 取系数最大） |
| 匹配 | 匹配 Promotion 并增强 | 写入 ticketId、调整金额/权益 |
| 校验 | 未匹配Ticket处理策略 | 对未命中 ticket 的优惠做兜底 |
> **协作规则**：各处理环节之间强依赖，选点需按最小完整路径联动，避免数据流断裂
## 4. 对应代码位置
| 类型 | 位置 |
|------|------|
| 核心处理器 | `DynamicTicketPromotionProcessor` |
| Ticket类型枚举 | `DynamicTicketCategory` |

核心伪代码【动态Ticket】

FUNCTION execute(promotionContext):
    promotions   ← promotionContext 中待计算的优惠活动列表
    result       ← ∅
    // ① 查询用户当前持有的有效优惠资质（ticket）
    validTickets ← queryValidTickets(promotionContext)
    // ② 定制：分离出「需要资质才能生效」的活动（各业务补充自己的判定）
    ticketPromotions ← ∅
    IF 匹配业务A: ticketPromotions.add(parse(promotionContext))
    IF 匹配业务B: ticketPromotions.add(parse(promotionContext))
    // ③ 定制：从 ticket 携带信息解析其关联的动态活动 ID，去重后统一查询
    activityIds ← ∅
    IF 匹配业务A: activityIds.add(parseActId(promotionContext))
    IF 匹配业务B: activityIds.add(parseActId(promotionContext))
    dynamicPromotions ← queryDynamicPromotions(activityIds)
    // ④ 定制：按业务场景确定 ticket 排序策略
    IF   匹配业务A: sortedTickets ← sort(validTickets, 「最新发放」优先)
    ELIF 匹配业务B: sortedTickets ← sort(validTickets, 「最早过期」优先)
    ELIF 匹配业务C: sortedTickets ← sort(validTickets, 「最早发放」优先)
    ELSE:           sortedTickets ← sort(validTickets, 「最新发放」优先)
    // ⑤ 定制：将 ticket 与活动配对，按业务对命中的活动信息做增强
    FOR each (promotion, ticket) in match(sortedTickets, ticketPromotions ∪ dynamicPromotions):
        IF   匹配业务A: 覆盖折扣率
        ELIF 匹配业务B: 覆盖减钱金额
        ELIF 匹配业务C: 覆盖一口价
        promotion 写入 ticketId 及相关标记
    // ⑥ 汇总所有「需要 ticket」的活动，逐个裁定去留
    needTicketPromotions ← 上述所有场景的活动
    FOR each promotion in needTicketPromotions:
        IF promotion 已匹配到 ticket:
            result.add(promotion)          // 已命中 → 保留
            CONTINUE
        // 定制：未匹配 ticket 时的兜底策略
        IF   匹配业务A: result.add(promotion)    // 允许计算，但无法下单
        ELIF 匹配业务B: 丢弃 promotion            // 移除优惠
        ELIF 匹配业务C: result.add(promotion)    // 按原有优惠逻辑处理
        ELSE:           丢弃 promotion            // 移除
    // ⑦ 收尾：将处理后的活动合并回上下文
    promotions.addAll(result)

实际验证：效果有提升

我们仍然拿之前的需求进行验证，发现有了业务能力知识引导，最终效果呈现正向趋势。主要体现在以下方面：

1. 精确率：AI识别出6个改动点，全部命中真实改动点，精确率 100% 。
2. 召回率：预期的7个改动点，成功匹配到了6个，仅有一个未匹配到，召回率达到 85.7% 。

但进一步分析生成结果后，我们发现这个方案仍然无法完整解决“最后一公里”的问题，主要体现在三类偏差：

1. 召回偏差：针对未匹配优惠的处理策略的改动点未匹配到，原因是AI通过代码读取的方式未明确识别到这个业务定制。
2. 定位偏差：基于Ticket数据修改折扣率的改动点匹配到，但是具体的代码改动位置定位错误，需要人工澄清。
3. 实现偏差：代码实现中有逻辑错误，比如折扣率的覆盖逻辑没有考虑多币种，未匹配优惠的定制逻辑实现和预期完全相反等，代码逻辑实现严重错误。

整体看下来，虽然改动点的匹配效果显著提升，但是到具体代码层面上在哪里修改，如何修改，从人工订正之后最终的代码行数来看，正确率只有 64% ，仍然有较大进步空间。

思考：最后一公里的代码噪音

结论：经过「技术分层知识」到「业务知识」的转变，AI有了正确方向，呈现正向提升。如果再能生产出「精确改动锚点」和「营销代码规约」两类知识，AI Coding的效果理论上能再上一个台阶！

业务能力知识解决了"改什么"的问题，但从能力定位到具体的改动点的过程中，AI仍然要读代码进行探索，来决定"怎么改"。此时，一个反直觉的事实是，让 AI 读更多代码，产出反而可能更差。因为对于一个真实复杂的业务系统，代码中往往沉淀了不同时期的业务背景、架构取舍和场景化实现。同一类问题在不同业务阶段可能有不同的实现路径，很多代码只有结合当时的业务背景才容易被准确理解。AI 如果缺少这些背景知识，就很难判断哪些是当前应该遵循的稳定范式，哪些只是特定场景下的局部实现，因此读取越多，反而越容易受到干扰。

最终阶段——系统架构升级助力构建业务知识库

核心思路

业务能力知识能够帮助 AI 判断“需要改哪些业务点”，但如果代码中相关逻辑分散、历史定制混杂，AI 仍然需要在大量代码噪音中定位具体实现，因此问题已经不只是“知识组织方式”的问题，而是“系统架构是否对 AI 可理解、可索引、可安全修改”的问题。在这个阶段，解决这个问题，光在纯知识维度的努力是不够的。 同时也需要代码有清晰的结构锚点。

NF架构升级建立扩展点

升级系统架构，将原先耦合的多个ifelse分支，抽取出扩展点。不同业务场景以SPI扩展实现的方式存在，以此实现AI清晰锚定扩展点。

每个扩展点都应具备稳定的 code、明确的职责、输入输出契约、执行顺序和实现位置。这样 AI 不再需要从大量流程代码中猜测“哪里可以改”，而是可以直接基于扩展点实体定位改动边界。

建立扩展点协作关系

建立业务知识，将多个扩展点进行汇聚，并定义其执行顺序、相互关系。不同扩展点相互影响、相互作用，以此实现AI分析逻辑交互。

沉淀生码最佳实践规约

沉淀系统中「细节方案的设计规约、领域模型信息的读写」等最佳实践知识，AI实际生码时优先依赖知识而非代码探索，让AI的代码是最纯粹的最佳实践，让AI完美地完成"最后一公里"的编码工作，实现代码符合领域内的最佳规约。

关键设计：基于架构升级构建完整的业务知识库

基于架构升级后的逻辑架构以及上述实体化改动点和显化协作关系两个思路，我们构建了整体的业务知识体系，核心的业务知识分三层：

1. 业务能力 ：仍沿用业务能力的知识载体，但内涵升级了——之前业务能力描述的是"在哪些代码类里定制"，现在描述的是"下面挂着哪些扩展点、它们如何协作"，并基于协作关系推导出隐藏定制逻辑的澄清，让能力的定制更加完整。
2. 扩展点 ：代码中的原子的、单一职责的定制逻辑，一个扩展点只承担一项不可再拆分的职责，比如决策某个场景下的执行策略、判断是否过滤某个优惠等。
3. 产品包定制 ：某个具体业务场景对一组扩展点的实现集合。架构升级后，不同业务定制被隔离到独立产品包中，同一业务场景下的扩展点实现也被聚合在一起，因此具体业务实现本身也可以作为知识实体被描述和索引。

动态Ticket知识

基于这个思路，我们重新整理了《品类新智能加投升级》需求中所需要的动态Ticket能力的知识。 相比之前，核心区别是扩展点的设计。

# 动态Ticket
## 1. 定义
| 名称 | 说明 |
|------|------|
| 职责描述 | 处理用户持有的**动态优惠资质**（PRD 中常称 pt / promotion ticket / 模板维度 pt）的全流程业务定制能力。当需求涉及「用户需持有某种 pt/ticket 才能命中优惠」，或「基于 pt 上的属性（如加深系数、膨胀系数）影响优惠计算」时，均属本能力范畴。覆盖全链路营销、摇一摇、拿样、满件减、一品一券等所有需通过 ticket 驱动优惠命中的场景。| 
## 2. 职责
统一编排 ticket 优惠命中的全流程，各阶段存在严格的数据依赖与执行顺序：
```
准入校验 → 分类 → 认领 + 解析活动ID → 统一查询动态活动 → 排序 → 匹配增强 → 兜底校验 → 返回 promotions
```
- **准入校验**：分类前补充 staticTicketPromotions
- **分类**：BuyerResource → categoryBuyerResourceMap，产出后续遍历维度
- **认领 + 解析活动ID**：按分类遍历，产出 claimedPromotionMap + activityIds
- **排序**：按分类定制匹配顺序
- **匹配增强**：写入 ticketId、调整金额/权益
- **兜底校验**：对未命中 ticket 的优惠决定去留
## 3. 扩展点清单
各业务场景通过统一的扩展点接口实现定制，全部挂载在动态Ticket能力下（按执行顺序编号）：
| 序号 | 扩展点 code | 名称 | 职责 |
|------|-------------|------|------|
| 1 | `CUSTOM_STATIC_TICKET_VALIDATION` | 自定义准入校验 | 分类前补充需资质校验的活动 |
| 2 | `CLASSIFY_BUYER_RESOURCES` | 动态Ticket分类 | 按业务场景拆分 ticket 类型，产出分类维度 |
| 3 | `CLAIM_STATIC_PROMOTIONS` | 实例认领 | 将静态活动归属到 ticket 上 |
| 4 | `RESOLVE_ACTIVITY_IDS` | 解析Ticket关联活动ID | 从 ticket 字段解析其关联的动态活动 ID |
| 5 | `RESOLVE_SORT_STRATEGY` | 定制业务排序规则 | 决定 ticket 的匹配顺序 |
| 6 | `MATCH_PROMOTIONS_AND_ENRICH` | 匹配Promotion并增强 | 匹配后写入 ticketId、调整金额/权益 |
| 7 | `RESOLVE_UNMATCHED_TICKET_STRATEGY` | 未匹配Ticket处理策略 | 对未命中 ticket 的优惠决定去留 |
## 4. 扩展点编排协作关系
`DynamicTicketPromotionProcessor` 按以下顺序编排各扩展点，扩展点之间存在严格的数据依赖：
```
准入校验(1) → 分类(2) → 认领(3) + 解析活动ID(4) → 统一查询动态活动 → 排序(5) → 匹配增强(6) → 兜底校验(7)
```
关键数据流转：
| 上游 | 产出 | 下游消费 |
|------|------|----------|
| 扩展点1（准入） | 补充的 staticTicketPromotions | 扩展点2 作为分类输入 |
| 扩展点2（分类） | categoryBuyerResourceMap（分类维度） | 扩展点3/4/5/6 按分类遍历 |
| 扩展点3（认领） | claimedPromotionMap（认领的活动） | 扩展点5/6 排序与匹配 |
| 扩展点4（解析ID） | activityIds | 平台批量查询后合并进 claimedPromotionMap |
| 扩展点5（排序） | 排序后的 ticket 顺序 | 扩展点6 按序匹配 |
| 扩展点6（匹配增强） | 增强后的 Promotion（含 ticketId） | 扩展点7 判定未匹配去留 |
## 5. 对应代码位置
| 类型 | 位置 |
|------|------|
| 核心处理器 | `DynamicTicketPromotionProcessor` |
| Ticket类型枚举 | `DynamicTicketCategory` |

实际验证

使用《品类新智能加投升级》需求来尝试，最终效果有 显著的提升

• 7个扩展点定位全部正确， 精确率100%，召回率100% 。
• 技术方案基于最佳实践规约产出，符合营销系统的设计规范， 代码改动位置定位成功率100% 。
• 生成代码经人工 Review、规约检查和测试验证后，能够符合营销系统在性能、整洁度和扩展点使用上的要求。

基于这一套业务知识体系，AI 已经能够较好地完成需求分析、技术方案产出和代码生成，相关产物质量相比前两个阶段有了显著提升。

整体设计

全局架构

基于如上层层递进的思考过程，最终我们确定出整个AI研发体系升级的全景图。

整个体系分成两大块，由流程编排、业务知识、架构扩展点和测试验证共同组成的完整 AI 研发体系。

1. 以 AAIC 的研发与测试 Command 为主干流程；
2. 在营销域内沉淀本域技能、业务知识库和测试知识库。

架构升级：引入业务隔离和扩展点框架

改造方式

我们引入了NF框架（业务隔离和扩展点框架），完成两个关键改造：

1. 扩展点：将粗粒度的业务逻辑方法，拆解为可索引的原子化的扩展点。
2. 产品包：将散落各处的业务实现逻辑收敛到独立产品包，实现逻辑解耦。

改造效果

改造收益

1.精确定位：AI 不需要在大量流程代码中自行探索"哪里可以改"，而是可以基于业务能力知识，直接定位到需要定制的扩展点和对应实现位置。

2.知识结构化：当这些扩展点被具体业务实现后，相关实现逻辑会按照同类型业务定制聚合到对应的产品包中。这样一来，业务知识体系就形成了清晰的三层描述：

• 系统具备哪些业务能力。
• 每个业务能力下有哪些扩展点可以定制。
• 不同产品包分别实现了哪些扩展点定制。

代码结构

架构升级之后，我们的代码结构变化如下：

FUNCTION execute(promotionContext):
    promotions   ← promotionContext 中待计算的优惠活动列表
    result       ← ∅
    // ① 查询用户当前持有的有效优惠资质（ticket）
    validTickets ← queryValidTickets(promotionContext)
    // ② 定制：分离出「需要资质才能生效」的活动（各业务补充自己的判定）
    ticketPromotions ← ∅
    ticketPromotions.addAll(
        NF(CUSTOM_STATIC_TICKET_VALIDATION, promotions, validTickets)
          .reducer(flatCollect).default(∅))
    // ③ 定制：从 ticket 携带信息解析其关联的动态活动 ID，去重后统一查询
    activityIds ← ∅
    activityIds.addAll(
        NF(RESOLVE_ACTIVITY_IDS, validTickets)
          .reducer(flatCollect).default(∅))
    dynamicPromotions ← queryDynamicPromotions(activityIds)
    // ④ 定制：按业务场景确定 ticket 排序策略
    strategy ← NF(RESOLVE_SORT_STRATEGY, validTickets, ticketPromotions ∪ dynamicPromotions)
                 .reducer(firstNonEmpty).default(empty)
    sortedTickets ← sort(validTickets, strategy)
    // ⑤ 定制：将 ticket 与活动配对，按业务对命中的活动信息做增强
    FOR each (promotion, ticket) in match(sortedTickets, ticketPromotions ∪ dynamicPromotions):
        NF(MATCH_PROMOTIONS_AND_ENRICH, promotion, ticket).reducer(none)
        promotion 写入 ticketId 及相关标记
    // ⑥ 汇总所有「需要 ticket」的活动，逐个裁定去留
    needTicketPromotions ← 上述所有场景的活动
    FOR each promotion in needTicketPromotions:
        IF promotion 已匹配到 ticket:
            result.add(promotion)          // 已命中 → 保留
            CONTINUE
        // 定制：未匹配 ticket 时的兜底策略
        // 扩展点6：未匹配Ticket处理策略
        strategy ← NF(RESOLVE_UNMATCHED_TICKET_STRATEGY, promotion)
                     .reducer(firstNonNull).default(REMOVE)
        SWITCH strategy:
            SKIP_VALIDATION_NON_PURCHASABLE: result.add(promotion)    // 允许计算，但无法下单
            SKIP_VALIDATION_PURCHASABLE    : result.add(promotion)    // 按原有优惠逻辑处理
            REMOVE (default)               : 丢弃 promotion            // 移除
    // ⑦ 收尾：将处理后的活动合并回上下文
    promotions.addAll(result)
PRODUCT 业务A:
   CUSTOM_STATIC_TICKET_VALIDATION：补充业务A自己需纳入资质校验的活动（parse）
   RESOLVE_ACTIVITY_IDS：解析业务A ticket 上携带的关联活动 ID（parseActId）
   RESOLVE_SORT_STRATEGY：返回「最新发放」优先
   MATCH_PROMOTIONS_AND_ENRICH：命中后覆盖折扣率
   RESOLVE_UNMATCHED_TICKET_STRATEGY：返回 SKIP_VALIDATION_NON_PURCHASABLE（允许计算，但无法下单）
PRODUCT 业务B:
   CUSTOM_STATIC_TICKET_VALIDATION：补充业务B自己需纳入资质校验的活动（parse）
   RESOLVE_ACTIVITY_IDS：解析业务B ticket 上携带的关联活动 ID（parseActId）
   RESOLVE_SORT_STRATEGY：返回「最早过期」优先
   MATCH_PROMOTIONS_AND_ENRICH：命中后覆盖减钱金额
   RESOLVE_UNMATCHED_TICKET_STRATEGY：返回 REMOVE（移除优惠）
PRODUCT 业务C:
   RESOLVE_SORT_STRATEGY：返回「最早发放」优先
   MATCH_PROMOTIONS_AND_ENRICH：命中后覆盖一口价
   RESOLVE_UNMATCHED_TICKET_STRATEGY：返回 SKIP_VALIDATION_PURCHASABLE（按原有优惠逻辑处理，可正常下单）

升级之后的代码中，我们将每一处定制都显式地定义了对应的扩展点code，AI可以精准索引，而这些扩展点对应的业务实现，被收敛到了统一的位置，AI也可以更稳定地读取到这些实现逻辑

知识体系概览：业务知识+规约知识+领域术语知识

业务知识

在完整落地过程中，我们并不只沉淀了动态 Ticket 这一项能力。经历几次脑暴过程，目前营销域基于历史需求和现有代码，按照3类维度，整理出22个业务能力（不断建设中），形成了营销域的业务能力知识全景。前文使用的动态Ticket，只是其中“横向产品视角”下的一个代表性能力。

营销平台计算端能力体系（22 能力 · 3视角）
│
├── 优惠计算流程视角
│   │
│   ├── 优惠实例处理类
│   │   ├── 优惠信息增强
│   │   └── 优惠过滤与排他
│   │
│   ├── 优惠计算处理类
│   │   ├── 人群能力定制
│   │   ├── 营销风控定制
│   │   ├── 计算定制
│   │   └── 限购定制
│   │
│   ├── 优惠流程处理类
│   │   ├── 创单异步流程定制
│   │   └── 流程阶段增强定制
│   │
│   └── 优惠结果处理类
│       ├── PDP逻辑定制
│       └── 交易优惠面板定制
│
├── 工具视角
│   │
│   ├── 工具定制类
│   │   ├── PIS定制
│   │   ├── 一段金定制
│   │   ├── 支付优惠定制
│   │   ├── 平台跨店优惠定制
│   │   └── 店铺类优惠定制
│   │
│   └── 新增工具类
│       ├── 新增单品金工具
│       ├── 新增单品非金工具
│       ├── 新增跨店资产类优惠
│       └── 新增跨店非资产类优惠
│
└── 横向产品视角
    └── 横向产品类
        ├── 动态Ticket
        ├── 券后价定制
        └── 拼团定制

规约知识和领域术语知识

基于沉淀的代码生成规约，配合AI完成最后一公里的代码实现，我们同步沉淀了细粒度的规约知识：

• 数据指引 ——告诉AI业务数据从哪取、用什么方式获取，比如如何读写折扣率，如何读取活动信息，如何获取用户信息。
• 设计规约 ——灰度策略、AB实验、Diamond配置设计，业务领域对象设计，线程池、异常处理等场景的最佳实践。
• 编码风格 ——集合操作编码风格、常量注释标注四要素、日志格式统一模板。

这些规约不是建议，是 红线 ——AI生成代码后自动触发规约检查，不符合则打回重写。

此外，针对一些领域的核心概念，还有一套单独的领域术语知识，标注了领域概念的描述含义、维度等，用来在概要设计阶段让AI更好地理解PRD。

特别说明

营销产技团队基于过去两年的需求分布与梳理，并且通过NF架构升级，有效沉淀了22个营销业务能力。我们相信可以覆盖未来约90%的常见营销研发需求。但这套建立在业务能力知识库之上的体系也无法覆盖所有类型的需求，存在如下问题：

1. 针对「问题2：需求对应的扩展点不存在」，我们的思路是：

   a. 在SDD流程中，基于对应业务能力内已存在的扩展点，以及协作关系，尝试去推断出需新增的扩展点。这条路通过我们的努力，可以尽力做到最优。

1. 针对「问题3：需求对应的业务能力不存在」，我们的思路是：
1. 首先人工定义「平台逻辑」、「扩展点」，并形成业务知识。（可以借助VibeCoding）出发点：避免幻觉带来的副作用，我们对业务能力的定义非常严格。因为业务能力未来将服务于多个需求。因此其合理性，也将决定着未来多个需求的交付质量。
2. 其次AI结合PRD、业务知识，完成生码工作。

仍然以《品类新智能加投》举例，如果营销系统不存在「动态Ticket优惠」的能力，将按如下流程执行：

1. 产研讨论「动态Ticket」能力，定义出平台逻辑，扩展点，以及扩展点的协作关系。
2. 研发实现「动态Ticket」能力的平台逻辑，扩展点。（可借助VibeCoding）
3. 研发编写「动态Ticket」的业务能力知识库。
4. 研发基于AAIC流程完成《品类新智能加投》的需求实现。

基于 AI Test 的全流程质量保障方案

问题：如何保障代码逻辑真正跑起来后一定是符合预期的？

营销系统的复杂性不仅体现在代码实现上，也体现在优惠叠加、币种转换、国家差异等运行时组合逻辑中。在容错率极低的营销系统中，这些逻辑如果出现非预期的表现，是最致命的风险。因此必须引入贯穿 AI Coding 全流程的测试保障方案，保障AI 生成的代码在真实业务链路中的正确性。

核心思路

我们将质量保障拆成两个层次：

1. 函数级别正确性：确保 AI 生成的每个独立实现单元符合预期。
2. 链路级别正确性：确保多个函数组合后，在真实接口链路中的业务结果符合预期。

对应地，我们分别采用 TDD 和自动化集成测试来完成验证。

TDD——在生码阶段，保障函数级代码的正确性

面对模块级代码的正确性挑战，与测试工具团队讨论多次，回到传统软件工程中寻找答案：TDD（测试驱动开发）。我们的思路是，在技术方案阶段，AI 会基于方案生成对应的单测用例；在代码生成阶段，则按照“生成单测 → 运行验证 → 根据失败原因修改代码”的循环持续迭代，直到所有单测通过。

测试Skill+营销测试知识——测试阶段，保障链路级代码的正确性

1. 营销测试知识：为解决测试完整性、准确性的问题，需要构建接口维度和业务玩法维度的测试知识体系（解决如何构造有效入参，断言哪些字段，结果是否通过等核心问题）。
2. 测试Skill：代码开发完成后，测试Skill 会结合测试知识、技术方案、代码改动和单测结果，生成接口维度的链路级测试用例，并在测试环境中自动执行，从而验证链路级业务逻辑是否符合预期。

关键设计

NF架构升级实现业务定制原子化

如之前介绍，为建立完整的业务知识体系，进行NF架构升级实现逻辑原子化。隔离框架的初衷是让扩展点可索引，但因逻辑隔离后的高内聚也实现了测试的便捷性。

1. 系统架构升级之前，做TDD的门槛很高：逻辑耦合在大方法中，难以独立构造输入输出，写一个测试用例往往要mock大量依赖，投入产出比较低且过程繁杂。
2. 系统架构升级之后，原子化的扩展点实现高度内聚：有独立的输入输出契约，产品包逻辑独立封装，业务逻辑与框架完全解耦。每个扩展点实现都具备相对清晰的输入输出边界，因此更接近可独立测试的最小单元。

测试左移

传统TDD的痛点在于"先写测试"带来的负担：需要提前思考好单测用例，并且在开发过程中频繁在编码和测试之间切换。但在AI Coding场景下，测试用例本身就是"正确性规约"，它告诉AI什么样的输出是对的。

AI生成代码→运行测试→未通过→自动反思重写→再生成，形成自动化循环。TDD 将正确性判断从单纯依赖人工 Review，转化为可自动执行的验证闭环。在 AI Coding 场景下，这一价值被进一步放大。

营销测试知识

我们基于AAIC中的测试Skill模块，实现了接口维度的AI测试链路。具体做法是针对每一个接口，以及各个业务场景，都沉淀了对应的知识库：

• 接口维度知识
• 接口主规则：描述这个接口的出入参逻辑，背景，执行规则
• 入参构造规则：描述接口的入参如何构造出来的，提供样例模板
• 预期结果验证规则：描述分级别的出参结果的断言

• 业务场景维度知识
• 入参构造规则：描述当前业务场景下，如何构造入参可以命中
• 预期结果验证规则：描述当前业务场景下，如何断言出参的正确性

基于以上知识，结合测试Skill模块，完成整个集成测试流程。

后续计划

知识增长从“Skill生产+人工验收”到“自生长”

全链路闭环之上，真正的长期价值在于知识增量。每交付一个需求，会将新的能力、扩展点、产品包实现以及规约等，通过知识更新Skill等AI辅助的方式沉淀回知识库；下一个需求AI表现更好，更多交付产生更多知识沉淀。

这样，AI Coding 不再是一次性工具调用，而是逐步形成“交付 → 沉淀 → 验证 → 复用”的知识飞轮。需求交付越多，知识体系越完整；知识体系越完整，后续需求的 AI 产出质量越高。

AI从“解决编码”升级为“解决全链路”

目前营销的研发模式升级，主要是解决「生码+测试」的技术阶段。未来将解决「研发前的PRD生产阶段」，「发布后的风险追踪+安全生产阶段」等全链路流程。