一句话理解 BP Claw：它是 FlinkSpec 上游的 “AI 数据 BP”，把产品经理的非标 PRD 自动转化为 AI Coding 可消费的高质量需求文档。在深入阅读之前，先用一张表告诉你 BP Claw 能带来什么。

如果你的团队也在被以下问题困扰，这篇文章值得读完：AI Coding 效果不稳定，同样的框架、不同的需求，结果天差地别；需求沟通来回反复，一个指标口径要确认三四轮；PRD 质量参差不齐，开发阶段频繁踩雷、返工延期。BP Claw 的答案是：问题的根源在输入，解法在源头。

在深入 BP Claw 之前，我们先来看一个更大的图景 ——FlinkSpec。FlinkSpec 是实时数仓团队打造的 AI 工程化开发框架，它以 “需求驱动、制品为锚” 的理念，将一条实时数据链路的生命周期拆解为四个阶段，每个阶段都有严格的门控评估，确保交付质量。

在 FlinkSpec 的四个阶段中，需求澄清阶段是一切的起点。而需求澄清阶段的质量，取决于一个关键输入 ——PRD 文档。如果 PRD 质量不达标，后续的一切都是空中楼阁：需求定义模糊 → Intake 门控反复打回 → Define 阶段耗时翻倍；技术口径缺失 → Flink-SQL Agent 无法编码 → 频繁触发阻塞协议（BLOCK-N）；验收标准不清 → Review 阶段发现问题 → 回退到 Define 重来。

商业化广告投放链路中，一次广告曝光往往由多个商家共同参与竞价。这种一对多的流量-主体映射关系，在指标聚合时会产生一个结构性的歧义：以"商家"为维度下钻时，同一次流量事件会被多个商家各自计入，导致商家侧明细加总后，与平台侧总量不等。这不是数据质量问题，而是两套在各自语义下都正确的口径共存在同一张宽表里，却没有被显式区分：impression_cnt（平台侧）去重到流量维度，一次曝光 = 1；impression_cnt（商家侧）展开到主体维度，N 个商家参与 = N。当下游消费方使用同一个字段名、却按不同语义聚合时，CTR、CVR、ROI 等衍生指标就会系统性失真。

实时数仓的指标开发通常以 FlinkSQL 为载体，开发侧看到的输入是 Kafka 事件流和维度表，字段语义的边界在建模时已经隐式确定。问题在于：FlinkSQL 层面的 GROUP BY 逻辑无法自动感知上游指标应该以哪个粒度聚合。如果流量事件里同时携带了 advertiser_id 列表，不同的展开方式对应完全不同的业务语义，而这一选择在代码里只是一行 UNNEST 或一个 JOIN 的差异。常规的 Code Review 能发现 SQL 逻辑错误，却很难发现"SQL 逻辑正确、但口径选择与业务预期不符"这类问题——因为两种写法都能跑通，数据差异在没有对比基准的情况下也不会报错。

BP Claw 作为需求到编码之间的中间层，其核心能力是在指标定义阶段做口径显式化，而不是在开发完成后做数据校验。

具体做法是结合 OpenViking 知识库（团队历史建模文档、字段定义、历史踩坑记录）做语义召回，识别当前需求涉及的指标是否存在多粒度歧义，并在进入 FlinkSpec 之前，将以下约束显式写入需求文档：

这套约束作为 FlinkSpec 的输入，让 AI Coding 在生成 DDL 和 INSERT 逻辑时，直接基于已经对齐的语义边界，而不是从模糊描述中自行推断。

通用 AI Coding 工具在给定输入后，会选择一种"看起来合理"的实现——对于多商家指标，它会倾向于展开商家维度（因为需求里写了"按商家查看"），但不会主动判断这是否会导致平台侧口径膨胀。

BP Claw 的差异在于知识来源：它使用的不是通用语言模型对业务逻辑的推断，而是团队在同类建模问题上积累的历史决策和约束条件。对于"多商家指标是否需要分口径建模"这个问题，OpenViking 里已经有过明确结论，BP Claw 将其召回并作为强约束注入当前需求，而不是重新推断一次。

BP Claw 正是为了解决这个"源头问题"而生。它站在 FlinkSpec 的上游，确保进入 Define 阶段的 PRD 文档质量足够支撑后续的 AI 自动化编码。

BP Claw 的设计遵循三条核心原则，原则一：嵌入现有场景——用户不需要打开新页面、学习新工具，直接在飞书群聊中 @ 机器人即可触发，和日常"拉群评审"的行为完全一致；原则二：产品经理零感知提效——产品经理只需要提交原始 PRD 文档，BP Claw 自动完成规范化转换，产品经理无需关心格式，产品经理收到的是结构化、高质量的评审群，而非一堆格式要求；原则三：不硬卡点，做参照系——PRD 评分是"参照"，不是"阻塞"，帮助团队建立质量意识，而非制造流程摩擦，逐步提升 PRD 质量基线，而非一刀切。

在深入技术实现之前，我们先回答一个根本性问题：实时数仓对 PRD 文档的要求是什么？一份好的实时数仓 PRD，需要覆盖七大模块：

然而，产品经理提交的文档往往只覆盖了其中的 2-3 个模块，而且格式五花八门。这正是 BP Claw 要解决的核心问题 —— 需求转化。

这是 BP Claw 最核心、最有技术含量的能力。它做的事情，本质上是 模拟一个经验丰富的数据 BP 的工作过程。

如何处理常见的业务需求类型？我们总结了实时数仓中最常见的几类需求模式：

原文有的信息进行结构化提取，按模板填充；原文没有的信息标记为待补充，绝不凭空捏造；原文有歧义的信息保留原始表述，同时标注歧义点；原文划删除线的标注为"本期不纳入，暂缓"。

在完成需求转化后，BP Claw 会对标准化文档进行多维度质量评估，生成诊断报告。

规则一：技术口径一票否决——如果技术口径得分 < 15 分（满分 25），即使总分 ≥ 90，也标注为不可执行。原因：没有技术口径，FlinkSpec 的 Flink-SQL Agent 完全无法启动编码。规则二：验收标准缺失扣分——验收标准完全缺失，总分直接扣除 20 分；严重不足（≤5 分），扣除 10 分。原因：没有验收标准的需求，上线即翻车。规则三：溢出得分机制——某维度特别优秀可超出该维度满分，但总分上限仍为 100 分。原因：鼓励在关键维度上做到极致。

需要强调的是：PRD 评分不是硬卡点，不是流程阻塞。它是一面镜子，帮助团队看到当前 PRD 的质量水位，逐步建立质量意识。

自动拉群看似简单，但它承载着一个重要的产品设计意图——降低落地阻碍。为什么做自动拉群？如果 BP Claw 只能生成文档，用户还需要手动拉群、手动 @ 人、手动转发文档，那使用体验就是割裂的。自动拉群让整个流程变成了"一步触发、全程自动"：用户只需要在飞书群里 @ 机器人、@ 评审人，附上文档链接。BP Claw 自动完成：读取文档 → 生成标准化文档 → 质量评估 → 创建评审群 → 邀请成员 → 发送文档和诊断报告。评审人在新群里直接看到结构化的文档和质量报告，开始评审。这就是"贴合现有工作流"的具体体现——用户的行为没有变，但背后的效率翻了20倍。

在 AI 应用中，Token 消耗直接关系到成本和响应速度。BP Claw 在这方面做了多项优化。

对于包含 10 个以上指标的大文档，我们不会一次性生成完整文档（这会导致上下文溢出），而是采用分段生成：先创建文档骨架（业务背景 + 角色-页面-指标矩阵），逐个追加指标定义模块，每追加 5 个指标发送一次进度反馈，最后追加验收标准和用数链路。本质是把"一次大事务"拆成"多次小提交"，即使中途失败也保留了已写入内容，不需要从头来。同时每段写入后向群聊发送进度消息（已生成 5/12 个指标），让用户有等待感知，不会误以为机器人卡死。收益：避免单次 API 调用超时，同时减少重复上下文传递的 Token 消耗。

BP Claw 采用编排者（动态调度，按需组合 Skill，职责清晰）模式，将核心逻辑拆分到三个独立 Skill 中：

每个 Skill 独立运行、独立管理上下文，避免了将所有逻辑放在同一个上下文中导致的 Token 膨胀。

标准化文档的七大模块，每个模块都有严格定义的模板结构。通过模板约束 AI 的输出格式，避免了冗余输出：明确指定输出字段，不多不少；使用 Markdown 表格约束结构；通过 Few-Shot 示例引导输出风格。

这是 BP Claw 最重要的技术挑战。AI 生成的文档如果出现"幻觉"（编造不存在的业务口径），后果比不生成还严重。

在 Skill 的核心 Prompt 中，我们设置了多层约束：

当 AI 遇到无法确定的信息时，不允许"猜测后继续"，而是必须：明确标记为待补充；说明缺失的具体内容；给出建议补充的方向。这样做的好处是：用户看到的文档中，每一条确定的信息都是可信的。

prd-quality-scorer 作为独立的评分 Skill，会对生成的文档进行"第二遍"审查。如果文档中存在明显的逻辑矛盾或不合理之处，评分报告中会直接指出。

难点一：如何让 AI 理解"实时数仓"的领域语义？普通的 LLM 并不理解"去重视图""Lookup Join""sink.properties.columns"这些领域概念。我们通过以下方式解决：领域知识注入（在 Skill 定义中嵌入实时数仓的核心概念解释）；模板驱动（通过模板结构限定输出范围，减少 AI 的"自由发挥空间"）；Few-Shot 示例（提供真实的标准化 PRD 样例作为参考）。

难点二：如何处理超长文档？有些 PRD 文档超过 10000 字符、包含 15+ 指标，直接处理会导致 API 超时（默认 60 秒不够用）、Token 超限、输出截断。解决方案：显式设置 timeoutSeconds=1200（20 分钟）；采用分段生成策略，每次只处理 3-5 个指标；实时进度反馈，让用户知道系统仍在工作。

难点三：如何协调多个 Skill 的执行顺序？BP Claw 作为"指挥家/编排者"，需要严格控制 4 个步骤的执行顺序和依赖关系：

为什么 STEP 3 失败不阻塞？因为质量评分是"参照"而非"卡点"。即使评分失败，标准化文档和评审群依然有价值。

场景一：技术口径完整的 PRD——BP Claw 评分 ≥ 90 分，FlinkSpec Define 阶段一次通过，无 BLOCK，Flink-SQL Agent 直接编码无需人工干预，整体交付周期为天级 ⏱️。场景二：技术口径缺失的 PRD——BP Claw 评分 < 60 分，触发技术口径一票否决，FlinkSpec Define 阶段频繁触发阻塞协议，Flink-SQL Agent 无法编码需反复沟通，整体交付周期为周级。结论： BP Claw 每提升 10 分的 PRD 质量，FlinkSpec 的编码阶段效率约提升 30%。

一个好的产品工具，如果没有运营手段的配合，是无法真正落地的。BP Claw 在落地过程中，我们采用了产品能力 + 运营能力双轮驱动的策略。

我们建立了 域级 PRD 成熟度评分 机制，通过持续追踪各业务域的 PRD 质量水位，推动整体提升：

通过持续收集每次 PRD 评分数据，建立质量趋势看板：按业务域维度追踪质量变化；识别高频缺失项，定向改进；月度质量复盘，表彰优秀案例。

将高分 PRD 案例沉淀为模板，形成可复用的知识资产：优秀案例库（≥ 90 分的 PRD 自动入库）；改进指南（针对常见扣分项提供标准化的补充模板）；新人培训（通过 BP Claw 评分报告快速上手 PRD 编写规范）。

只需一步：在飞书群聊中发送一条消息：

然后等待 1-5 分钟，你将在新的评审群中看到：标准化 PRD 文档、质量诊断报告、改进建议清单。

本文为 FlinkSpec 系列之开篇，亦是这场工程化变革的序章。BP Claw 所立之处，不过链路之源。FlinkSpec 所图，乃以 AI 之力，将实时数仓从需求落地至验收上线的全程工序，熔铸为一套精密自洽、生生不息的智能工程体系。宏图未竟，后续系列将逐章揭幕，敬请期待！

文 /子宸

关注得物技术，每周三更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

“给机会、给资源还给兜底？”

“‘开小灶’式的定制化学习路径？”

“知无不言的‘活字典’师兄师姐？”

这些在得物技术部不是段子。

我们抓来两位司龄1岁+的校招生——

算法工程师@乔伊

测试开发工程师@泽锐

“逼”他们交出最真实的成长答卷。

@乔伊：

成长快、创新性和高效率。

在过去的一年多里，TL和组内师兄按照项目难度循序渐进的分配工作，同时又得益于过去一年算法平台对大模型的大范围使用，让作为校招新人的我得以快速进步和成长，紧跟领域前沿技术。

@泽锐：

「加速度成长」：从校园到职场，对我来说挑战巨大。得益于部门系统性的培养、TL/师兄的倾囊相授以及快节奏的工作氛围，我在业务理解、技术深度（AI驱动测试）、跨团队协作等方面都经历了快速成长。感觉自己像被塞进了知识的高压锅，出来时竟然“熟”了，还挺香。

「被信任感爆棚」：虽然是新人，但团队和部门给了我极大的信任空间，不仅给机会，还给资源、给兜底（希望用不上），能够主导一些具有创新性和重要性的项目，这种信任即是压力，也是强大的驱动力，感觉随时充满“Passion”，促使我快速提升能力以匹配职责。

「创新与实践」：在部门内，围绕“质量”和“效率”目标，我被鼓励去探索和应用新技术、新工具来解决实际质量保障工作中的痛点。部门提供了探索的空间、必要的资源支持以及容错，只要想法靠谱、能解决实际问题，就有空间去尝试、去落地，让我能将想法付诸实践并获得实际的业务价值。

@乔伊：

在复杂任务早期，TL会帮助我分析并拆解任务，判断任务可行性同时提出修改建议。有带教师兄的培养机制我认为对我们新人的培养是最有效的。在早期工作过程中，可能有着许多文档无法提到的流程和操作细节，请求带教师兄可以省去大量不必要浪费的时间。

@泽锐：

刚进来面对具体的业务流程和专业术语，感觉像看天书，幸好组里有详细的SOP文档和业务流程图等知识沉淀，结合知无不言的师兄，在业务理解、工作方法、沟通协调上给予我细致指导，使得我能快速构建起业务全景图，并上手实际的质量保障工作。

新人的培养也不是一股脑乱塞资料，TL和师兄会根据我所负责的业务定向推荐业务沉淀文档、学习资源、内部技术分享，并分配一些边界清晰、较为简单的新手友好小任务，让我能精准打击知识盲区，在做中学，学中做，效率拉满，同时师兄会在关键节点review、指导，确保不跑偏。

毒家博客、技术夜校、分享会等都是快速获取知识的途径，包含了公司文化、协同流程、基础工具链、安全规范等必修课，避免了自己盲目摸索踩坑。浓厚的技术氛围也能让我了解其他团队在玩什么“黑科技”，说不定哪天就能借鉴到自己的工作中，感觉站在了“巨人”的肩膀上。同时也感谢技术部和质量平台的内部荣誉激励，是快速获取公司周边的好机会！

@乔伊：

因为我的工作是为算法训练的同学优化部署模型，所以一直都是跨团队的合作。合作的时候大家都很好沟通，刚开始有很多专业的指标和名词不懂，同事们也都很乐意解答。知道是新人，所以大家也会更宽容一些，总体来说，在同事的帮助和包容下，新人也可以顺利主导完成一个项目。

@泽锐：

在推进“AI生成功能用例”项目时，需要和研发效能平台等部门进行协调和对齐，同时也需要进行平台新功能内容、使用方法的推广，并提供使用教程和最佳使用姿势，帮助其他测试同学更好地理解和使用AI生成功能用例。

作为项目Owner，我需要首先梳理清楚项目目标、收益、具体方案、运营计划、项目排期、里程碑等内容。提前预约好项目各时间节点的会议，在会议前，需要准备清晰的会议议程，包括项目目标、当前进展、需要支持的具体事项以及预期时间节点。得益于前期准备充分，会议沟通都整体较为顺畅，虽然过程中也遇到了一些业务规则理解上的分歧，但都通过及时沟通的方式解决掉，最终项目成功落地，取得了较好的结果。

这期间，TL提前帮我明确了项目的目标和价值，指明了大方向，师兄也在项目启动前就帮我梳理了关键干系人和沟通策略，在遇到卡点时也会提供建议，必要时协助推动，始终让我站在前台主导，很好地锻炼了我的沟通协调能力。此外，公司也提供了成熟的项目管理流程和工具，极大地方便了信息透明、任务跟踪和文档沉淀，减少了沟通成本。

@乔伊：

在模型优化效果不佳的时候，TL并没有指责，而是帮助一起分析当前优化性能不佳的原因，并提供了很多业内其他公司的优化示例和论文帮助后续优化提供方向。在后续工作过程中，遇到卡点的时候会汲取之前的经验，广泛吸纳领域内其他的优秀方案，并本地化解决项目中的问题。

@泽锐：

有的。在负责AI生成功能用例项目的初期，大家对使用AI辅助生成功能用例的接受程度不高，前几个迭代的具体使用数据并未完全达到预期目标。我们团队专门组织了一次项目一期的复盘会，会议焦点集中在“问题是什么”、“什么原因导致的”、“如何改进”等内容上，并根据测试同学使用上的痛点和费力点具体分析，聚焦于功能使用流程与机制的优化方向，为项目后续的功能改进、运营计划提供了宝贵的经验。

在后续项目中，我们建立了反馈机制，收集来自测试同学的具体反馈，以便定期更新优化功能，提升AI生成用例的效果和易用性，同时提供使用教程和最佳使用姿势并实时更新，帮助用户更好地理解、接受和使用AI生成用例功能。我自己也清楚了团队是具备“容错”的，更关注于成长，重要的是从中学习并改进，这也增强了我在后续挑战性任务中的信心和韧性。

@乔伊：

DeepSeek R1 刚发布时，我参与并推动了该模型在公司业务中的从0到1落地。我的主要工作内容是deepseek的推理优化工作，说实话，deepseek作为当时参数最多的开源模型，且模型中包含多个新结构，优化难度很大。在优化过程中，将优化目标按照任务难度分为多个阶段，在内部研究同时紧盯业内优化手段，最终交付了三个以上的优化版本。经历了刚好满足业务RT需求到RT减半，吞吐翻倍等多个阶段。

@泽锐：

鼓励技术探索与选型：在推进全流程AI自动化测试项目时，部门并没有限制我必须使用某一特定的技术栈。我可以基于问题场景，调研业界方案，提出技术构想，并在充分POC后获得资源支持进行探索和实践，允许我在完成业务质量保障工作的同时，投入精力去“折腾”这些创新点。

容忍“创新试错”：对于引入AI这类前沿技术，部门理解其不确定性，在项目初期效果未达预期或遇到技术瓶颈时，团队更关注于是否从中获得了有价值的经验教训，以及能否进行迭代优化，而不是简单地否定，这种容错空间是创新的必要不充分条件。

提供展示与交流平台：部门让我负责一些创新性的项目，极大地锻炼了我的技术实践能力和项目管理能力。同时，部门内部的技术分享、甚至质量平台级别的分享会，都为我们展示项目成果、交流实践经验提供了平台，这种认可是也是我持续创新的动力。

@乔伊：

除了部门沉淀的文档之外，因为最近的工作技术栈比较新，所以公司内部的文档涉及比较少。对于新技术来说，我认为最重要的是不畏难以及沉下心。对于新技术来说，网上和公司内部的文档都比较少，碰到最新的问题需要不畏难，紧跟领域内最新的论文和技术手段，结合到现有优化系统中。另外，要沉下心打好基础，愿意花很长的时间和精力去啃源码和细节。

@泽锐：

第一站肯定是每个技术部校招得物er都会经历的入职培训，从技术部文化和安全、效率工程和项目管理、质量&研发效能相关内容和工具的课程培训，到校招项目实践的实战，帮助我们快速落地，完成校园到职场的身份转换。

前面也提到了，毒家博客和技术分享会的质量都非常高，我会经常搜有没有同事写过相关主题（例如AI实战、质量专项经验等），站在巨人的肩膀上，省时又省力；此外，不管是测试、后端、前端的分享，只要时间允许我都会去听，即使不是直接相关，也能开阔思路，了解技术趋势，认识大牛，很多灵感就是在这种跨域碰撞中产生的。

实践出真知，小步快跑，动手实践往往比单纯的学习理论知识来的要快，遇到不懂的大胆提问，能快速帮我们理清业务脉络、避开历史深坑，往往能get到很多容易被忽略到的细节。

关注高质量的公众号、技术社区、开源项目等，了解行业动态和最佳实践。对于需要系统构建知识的领域，也会抽时间学习技术部推荐的优质极客课程。

@乔伊：

对于主流的大模型推理框架，逐渐由使用者转变为开发者，目前在社区推理框架基础上，开发出多个功能适配版本和推理优化版本。

@泽锐：

质量视野的全局培养： 刚入职时，可能仅仅只关注单个功能点有没有Bug，质量保障的视角处于“低维”状态；现在，通过负责代码覆盖率、UI自动化、前端巡检等质量专项，深刻理解了 “全链路质量保障” 的概念。不仅要保证功能正确，还要关注性能、稳定性、变更影响范围、用户体验等，视角从“点”扩展到了“面”和“体”。

从手工点点点 -> 驾驭AI搞自动化：刚入职时，只具备基础的测试理论、自动化测试和编程能力，对AI在测试中的应用停留在概念层面；现在能探索并实践基于 AI Agent 的端到端自动化测试方案，并将想法进行落地，将其嵌入到现有测试流程中，打开了新世界的大门！

@乔伊：

我想说，不必焦虑，周围的同事和TL都很nice，未来比你想象得要精彩。

@泽锐：

“不懂就问，脸皮要厚” ：师兄和同事们比你想象中更愿意帮助你，憋着不问只会拖慢进度。大胆开口，无论是业务细节还是技术难点，问一句可能省你两天琢磨时间（当然，前提是先查过相关文档和博客）。

“主动点，再主动点” ：看见能优化的地方？有新奇的想法？不要局限于被分配的任务，主动去发现流程中的痛点、效率的瓶颈，大胆提出自己的想法和解决方案，甚至撸个MVP。 在得物，主动出击的人更容易获得机会和资源。

“常复盘，常记录”：做完项目、解决完问题，花点时间复盘：哪里做得好？哪里能优化？学到了什么？把经验固化成自己的能力；学到的业务知识、踩过的坑、解决问题的思路、灵光一现的想法随时记下来，未来的你一定会感谢有个好习惯的“记己”。

@乔伊：

刚入职遇到问题不要着急，可以多搜搜公司的文档，也可以直接向师兄和TL请教，大家都很乐意解答。

@泽锐：

拒绝能力纬度单一，要做“T”型人才：只专注于某一方面的工作，只会干一件事，很容易导致自己“能见度太低”，最好是先扎根于某一能力，再围绕这个能力拓展开来，成为“一专多能”的“T”型人才。

大局观与影响力：要有“看齐”意识，紧跟重点业务方向，勇于“挑大梁”；找准自己的角色定位，找到自己想要持续深耕的方向，建立护城河；通过持续学习、总结和分享，快速提升自己的个人影响力。

平衡工作与生活，保持身心健康： 互联网节奏快，在投入工作的同时，也要注意身体和心理的健康。找到适合自己的调节方式，健身、跑步、羽毛球……身体才是革命的本钱，好的身体也是可持续高效工作的保障。

最后，引用一句TL给我的话作为结尾：“年轻人干工作，优势就是胆子大，加油！”。

当无数新人用代码书写出“第一年奇迹”，背后是我们精心搭建的成长加速器：

• 知识沉淀体系：SOP文档与业务流程图，新人也能迅速理解复杂系统；

• 浓厚技术氛围：毒家博客、技术夜校等内部分享文化，让前辈踩过的坑变成“捷径”；

• 师兄/师姐带教护航：关键问题即时响应，降低新人试错成本；

• 安全试错空间：更聚焦经验沉淀与认知升级，而非责任追究；

• 多元荣誉激励：内部激励不只是奖品和证书，更注重专业能力认可与长效发展支持。

我们相信，

技术之路，代代接力前行。

前辈的经验会化作路标，

新人的勇气也将开拓边界，

前路宽广，我们继续并肩！

技术达人养成记

⬇️下期将解锁⬇️

《技术达人养成记｜白银2年：组队挑战高难副本！》 

全栈 SDD 开发中，最常见也最致命的错误是：让 AI 从零开始写代码。AI 模型具备"通识能力"，给它一个需求描述，它确实能生成可运行的代码。但问题在于，这些代码往往是"外星代码"：风格不一致（命名规范、目录结构、分层方式与项目现有代码不同）、复用率低（没有利用项目已有的公共组件、工具函数、请求封装）、采纳率低（Code Review 时后端同学看到"外来风格"的代码，会产生大量修改意见）。结果就是：AI 生成了代码，但 Review 成本和返工成本反而更高了。

Harness（约束）思维的本质是：给 AI 一个已有的实现作为参照，让它照着复刻一份，而不是凭空创造。就像给一个新入职的工程师说"你照着这个模块的风格，写一个类似的"，而不是"你自由发挥"——前者往往能更快产出符合团队规范的代码。

原则	说明
找相似实现	在代码库中找到功能最相似的已有实现，作为参照
复用优先	能复用的组件、接口封装、数据结构，直接复用
模仿着复制	哪怕是"抄一份改一改"，也比用新方式写好
约束生成范围	在提示词中明确指定参考文件、参考接口

原则	举例
找相似实现	"结束语"功能参照"场景化欢迎语"的前后端完整实现
复用优先	复用 greetingExtendInfo 的数据结构，新建 closingExtendInfo
模仿着复制	Controller / Service / Repository 按已有接口模仿
约束生成范围	前端修改入口参考 @FeatureTable/index.tsx:53-58

不推荐（凭空创造）：

推荐（Harness 约束）：

两者的差距不在于 AI 是否"聪明"，而在于你给了 AI 多少约束和上下文。约束越精准，生成代码的可用性越高。

前后端代码通常分布在两个独立仓库。如果分开打开，AI 生成后端接口时看不到前端的调用方式，生成前端代码时看不到后端的返回结构，接口字段对不上是家常便饭。将前后端代码放在同一个工作区下，有三个核心价值，Codebase Indexing：Cursor 对工作区内所有代码进行向量化嵌入，建立语义索引。AI 能跨仓库理解代码关系，生成质量大幅提升。上下文完整：AI 同时能看到前后端代码，接口字段、命名风格自然对齐。SDD 文档集中管理：前后端 SDD 文档在同一工作区，便于接口契约对齐。

Cursor 的 Codebase Indexing 会对工作区内的代码进行向量化嵌入，建立语义索引。这意味着：当你问 AI "场景欢迎语是怎么实现的"，它不需要你手动指定文件，能通过语义检索自动找到相关的 Controller、Service、前端组件。当你让 AI "照着欢迎语写结束语"，它会检索到欢迎语的前后端完整实现链路，而不只是单个文件。

前后端放在同一个工作区，Codebase Indexing 覆盖两侧代码。AI 生成后端接口时能参考前端的调用方式，生成前端代码时能参考后端的返回结构。

Tips：Cursor 打开工作区后，首次索引可能需要几分钟。可以在 Cursor 设置查看索引进度。确保索引完成后再开始让 AI 生成代码，效果会明显更好。

在全栈 AI 开发场景下，两款工具各有侧重，下表是实测对比：

功能维度	Cursor	Claude Code
代码库语义索引	支持 grep + 代码段语义相似度检索 速度快，理解能力全面	仅支持 grep 准确度严重依赖模型能力
代码生成速度	极速 平均 1–3 分钟	中速 平均 3–30 分钟 5 分钟以上是常态
代码采纳率	两者相当	两者相当
文件/代码段引用	快捷键、拖拽即可引用	需手动 @文件路径 无法引用代码段
多 Agent	默认开启（多 Tab 并行）	需要手动注册子 Agent
费率模型	失败任务不收费	失败任务耗时长 容易浪费大量 Token
历史会话恢复	仅能查看当前项目会话记录 存在会话丢失	可查看全局会话记录
综合评价	快速迭代首选 推荐 Composer2 模式	长链路复杂任务可用 依赖卓越的基础模型

以上述需求为例，工作区结构如下，.claude 和 .cursor 中已对 SDD 能力进行初始化。

与纯前端/纯后端 SDD 不同，全栈 SDD 需要：生成两份 SDD 文档（前端一份、后端一份）；接口契约对齐，前端 SDD 中的接口调用与后端 SDD 中的接口定义必须严格对应；字段映射一致，前端 VO 中的字段名与后端返回的 JSON 字段名一一对应。

相关概念术语

以下是经过实践验证的全栈 SDD 生成提示词模板：

关键要素解读：

主要是新增一个后台管理页面的 tab，涉及到搜索、展示、配置新增、删除等；利用内部 SDD 文档工具（如下图）从 PRD 描述和文档图片中提炼出需求点。

内部 SDD 文档工具

左侧导航新增"结束语" Tab。 右侧新增结束语列表页。字段有：结束语内容、结束语描述、优先级、更新人、更新时间、操作列。

新增 / 编辑弹窗字段：结束语描述、生效日期、生效时段、生效时段、结束语话术（类型和规则这里不一一罗列）。

拖拽排序功能：点击"排序"按钮进入排序状态，拖拽调整顺序后点击"保存"生效。

后端功能由 AI 根据前端需求描述自主设计数据表和接口。以下是 AI 在生成 SDD 前需要明确的关键设计问题（这些问题应在提示词中列出，让 AI 先回答再生成）。

接口清单：列表接口（支持分页，回显数据直接嵌入列表响应，无需单独回显接口）、新增接口、编辑接口（复用新增逻辑，根据 id 更新）、删除接口（逻辑删除，修改删除状态字段）、排序接口（批量更新，需考虑高效实现方案）。

字段设计：结束语话术内容（数组类型）、结束语描述（文本）、优先级 / 序号（小整型）、更新人（字符串）、更新时间（时间戳）。

需要 AI 在 SDD 中明确回答的设计问题：

• 主键设计：如何设计主键字段？前端发起编辑、删除时需要传递该字段。

• 优先级自增逻辑：优先级应基于当前数据条数自增，无需前端传递，由后端自动处理。

• 排序如何高效更新：批量排序时如何设计接口，避免 N 次单条更新？

• 嵌套对象如何建表：参考已有的"场景欢迎语"接口，入参中存在嵌套子对象（如下方参考结构）。此类子对象应拆分到多张表，还是序列化为 JSON 字段存单张表？

• isNextDay 字段含义：次日逻辑的具体含义是什么？前端时段选择器中"次日"勾选状态如何映射到该字段？

• 列表回显设计：列表接口需要返回完整的回显数据（供编辑弹窗回填），无需单独提供详情接口。

这份清单做了两件重要的事：前端侧给 AI 完整的 UI 细节，让 AI 知道组件状态、字段约束、交互逻辑，避免它做"最简实现"。后端侧把模糊的设计问题提前暴露，让 AI 在写 SDD 之前先回答这些问题——这正是 Harness 思维的体现：让 AI 参照已有实现（如"欢迎语"）来解决"结束语"，而不是凭空设计。

一次完整的全栈 SDD 生成，会产出以下文档：

前端 SDD：

• proposal.md — 需求提案，描述前端要做什么。

• spec.md — 技术规格，组件设计、接口调用、状态管理。

• tasks.md — 任务拆分，每个 task 对应一个可执行的代码变更。

后端 SDD：

• proposal.md — 需求提案，描述后端要做什么。

• spec.md — 技术规格，接口设计、数据库设计、分层架构。

• design.md — 详细设计，类图、字段映射、SQL。

• tasks.md — 任务拆分。

入门引导：

1. openspec-onboard（首次，不熟悉才走，引导完整步骤）；

2. openspec-continue-change（提示你下一步要干嘛）；

3. openspec-ff-change（快进）。

场景 A：初次开发

1. openspec-explore（调研，脑暴）；

2. openspec-propose "..."（生成设计）；

3. openspec-apply-change（写代码）；

4. openspec-verify-change（自测，校验代码与 SDD 文档是否对应）；

5. openspec-archive-change（收尾，归档）。

场景 B：二次开发，修改迭代已有功能

1. openspec-explore（定位旧代码/旧 spec）；

2. openspec-propose "修改..."（生成变更 Spec）；

3. openspec-apply-change（应用修改）；

4. openspec-verify-change（验证回归）；

5. openspec-archive-change（归档）。

场景 C：二次修改，需求变更

1. openspec-explore（调研，脑暴）；

2. openspec-propose "..."（生成设计）；

3. openspec-apply-change（写代码）；

4. 发现有问题就用 openspec-explore 修改提案；

5. openspec-explore "需求变更：xxx"（二次脑暴）；

6. openspec-propose "根据探索结果修改提案"；

7. openspec-apply-change（执行提案中变更内容）；

8. 【可选】openspec-verify-change（验证是否有未完成任务）；

9. openspec-archive-change（归档）。

场景 D：季度大清理

1. openspec-bulk-archive-change --before 2023-12-31（批量归档）。

总的来说，上述相对来说还是比较繁琐，保持最简使用：想（openspec-propose）、做（openspec-apply-change）、收（openspec-archive-change）即可。

SDD 文档生成完毕后，前后端的代码生成工作是相互独立的——前端根据前端 SDD 生成组件和页面，后端根据后端 SDD 生成 Controller/Service/Repository。这天然适合并行执行。

Cursor 支持多个 AI 编程模式并行工作，这是其核心优势之一。全栈开发场景下Tab 1 负责前端代码生成，Tab 2 负责后端代码生成，两个 Agent 同时运行、互不阻塞。

Claude Code 内置了 Subagent（子代理）机制，适合命令行场景下的多任务并行。

Claude Code 提供了两种多 Agent 协作模式。（下个迭代再实践一下 Team 模式和普通 Subagent 的差别）

特性	Subagent	Team 模式
沟通方式	只向主 Agent 汇报	队友之间可以直接沟通
协调方式	主 Agent 管理一切	共享任务列表，自我协调
生命周期	任务完成即结束	队友保持空闲状态直到被关闭
信息可见性	主 Agent 只看到最终结果	主 Agent 和队友可随时交换信息

Subagent 的核心配置项：

全栈开发场景中的应用：

建议	说明
SDD 先行	确保 SDD 文档已经对齐接口契约后，再启动并行生成。
一个 Agent 一个职责	两个任务可以并行完成，调试时即可看到代码实际参数。
接口契约是桥梁	前端 Agent 依赖的接口定义 = 后端 Agent 实现的接口定义。
分阶段验证	阶段一：前端先用 Mock 验证通过后；阶段二：可直接用t1前端页面联调后端接口最后：仔细全面回归。

直接联调往往是效率最低的验证方式，推荐采用三阶段分离验证：

这样做的好处是：前后两端的问题可以提前发现、分别修复；避免在联调阶段才暴露；节省大量排查时间。

Mock 数据质量直接决定前端自测的有效性，有三个关键要求：字段名和字段类型必须与后端 SDD 中定义的完全一致；参考已有接口的真实返回数据作为模板，而不是随意构造；覆盖边界场景（空列表、单条数据、多条数据、各字段极值如空字符串、超长字符串、null 值等）。

后端代码不需要在本地完整启动整个 Java 服务，只需编译通过即可验证大部分代码问题。

编译通过意味着：语法正确、依赖关系正确、类型兼容，是部署前最快速的验证手段。

后端代码提交并部署到测试环境；前端本地开发服务通过代理配置，将 API 请求指向测试后端地址；前端请求携带功能路由标识，确保请求路由到对应的测试环境（而不是其他人的环境）；逐接口验证，重点关注字段映射、状态处理、错误场景。

这是 AI 全栈开发中最容易被忽视的问题。SDD 描述的是"技术上怎么实现"，而不是"业务上所有的行为"。AI 在模仿参考代码生成新代码时，会自动复刻很多隐性功能——这些功能在参考代码中存在，AI 认为是"理所当然"的，所以没有写进 SDD 文档，但实际上已经悄悄实现了。

示例 1：变量/表单清除（前端）

示例 2：数据格式转换（后端）

示例 3：默认值补齐（后端）

这些隐性功能可能正是需要的，也可能完全不符合当前需求。问题在于你不知道它们的存在。

阶段	测试关注点
SDD Review 阶段	关注接口契约是否完整，字段定义是否与需求对应。
代码 Review 阶段	重点：对照 SDD 文档和实际代码的差异，主动寻找隐性功能。
联调测试阶段	不要只测 SDD 中描述的 happy path，要覆盖边界场景和隐性行为。

给测试同学的实操建议：把 SDD 文档当作起点，而不是终点。重点 Review AI 生成的代码，问自己一个问题："参考功能有哪些隐性行为？这些行为在新功能中是否合适？"

通过本文介绍的"Harness + SDD + 多 Agent"全栈开发方法论，在实际项目中验证的效益如下：采纳率提升，相比传统前后端分离开发，工作区模式可以很好地把项目需求上下文放到一起，更便于 AI 理解需求，设计编码；尤其通过Cursor的索引能力，进一步提高采纳率以及功能实现的完整性。耗时降低，SDD 模式下，AI 分析需求后产生两套 SDD 文档，使得前后端开发完全可以并行；以本需求为例，原本前后端2+4人日需求，在这种模式下，算上环境准备、踩坑时间、联调自测时间，压缩至3人日，提效50%+。调试环节不依赖阻塞，前端功能在全栈开发的视野下，已知数据结构可mock数据自测；后端功能通过远程调试的方式，支持本地打点调试；最终一并上测试环境验证，能够明确知道问题来自于前端还是后端；AI 全栈学习成本骤降，只需掌握入门级别前后端知识，即可介入简单全栈需求开发；提高业务域需求吞吐率。

本文介绍的全栈 AI 开发方法论，核心可以用一张图概括：

文 /盖伦

关注得物技术，每周三更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

本项目构建了一个网关路由 AI 安全审计系统，采用"通用 Agent + 业务 Skill"分层设计，增量日检/存量月检。落地 Open 网关路由越权漏洞检测流程，通过 AI 批量筛查 + 人工深度验证的人机协同模式，为大规模 API 安全审计提供了可复用的智能化解决方案。充分发挥通用 Agent 能力，业务逻辑在 Skill 中快速迭代。

随着平台 API 规模持续扩张，安全审计面临新的规模化挑战：

主要挑战：

• 覆盖面不足：抽样审计约覆盖 ~20%。

• 时效性压力：新接口需要更快的安全评估。

• 规则一致性：标准化检测规则难以沉淀。

当前，以大型语言模型为基座的 AI Agent 在代码语义理解、逻辑推理与自动化执行等维度的能力已超预期成熟，工程落地准确率与稳定性得到大规模验证。这一技术跃迁使全量自动化安全审计从概念验证走向可靠实践。传统人工抽样模式在数万条 API、数百个微服务的规模下已难以为继，而基于 AI Agent 的方案可实现 100% 路由覆盖与分钟级检测响应。本文将围绕这一契机，阐述如何构建贯穿全链路调用链的智能审计体系，解决覆盖面、时效性与规则一致性三大核心挑战。

架构说明：常规代码负责任务调度与结果存储，所有 AI 分析工作由超级 Agent 完成。

具体项目分析告警时采用 AI批量筛查 + 人工深度验证 的人机协同模式：

场景化应用：

设计优势：

通用 Agent 能力最大化：充分利用 Claude Code/OpenCode 的代码理解、推理分析、上下文管理、会话恢复等标准能力，不重复造轮子。业务逻辑快速迭代：检测规则、分析流程、报告格式等业务逻辑全部沉淀在 Skill 中，可随时调整优化。任务可追溯可复现：通过 --resume 恢复会话现场，任何分析过程都可回溯、可验证。

基于公开漏洞案例库分析，细分越权：

检测分四步，前两步设有短路退出以降低成本。路由配置检查：检查 auth_config.public 和 required_scopes，配置无异常则跳过后续审计；登录态识别：遍历调用链查找认证节点，标准认证路由直接信任，跳过代码审计；代码审计（三维检测）：检查权限注解（@PreAuthorize）、用户 ID 来源（登录态 vs 请求参数）、所有权校验（DB 过滤 vs 代码显式校验）；精细化危害评估：区分越权读取（数据敏感性）和越权操作（利益流向），输出风险等级与修复建议。

依据《数据安全法》确立的数据分类分级保护制度及《网络安全法》关于网络运营者数据安全管理义务的相关要求，通过 AI Agent 对源代码文本分析（基于变量名、字段类型、接口定义等代码特征进行技术推断），对路由功能返回涉及的数据资产进行分级评估。

通过对多个会话日志的深入分析，识别出 Token 消耗的关键问题：

Token 消耗热点：

原理：将 MCP 工具暴露为 CLI 命令，避免每次会话加载 MCP 上下文。

效果：节省 61% Token 消耗。

问题：无参数调用返回完整文件（最大 1.47MB ≈ 500K tokens）。解决方案：为 gitlab_file 添加精准参数，实现按需提取。

效果：v2 vs v1 再节省 88%。

原理：标准认证路由直接信任，跳过冗余代码审计。

效果：标准认证场景节省 50-70%。

原理：YAML 天然比 JSON 的 Token 量更少，对 AI 阅读更友好，降低模型解析成本。

在路由安全审计场景下，模型选型需围绕准确率（Precision）与召回率（Recall）两大核心指标建立决策矩阵：

最终选型：满足 P0/P1/P2 三重约束的最优模型。选型理由：在召回率 100% 的候选模型中，qwen3.5-plus 以更低的单位成本实现可接受的准确率，是批量场景下的最优解。

局限性说明:

测试集局限性：上述结论基于独立手工标注测试集（100 + 样本），与生产告警数据相互隔离，仅可作为基线参考依据。模型迭代风险：大模型迭代更新速度极快，市场中或存在性能更优、成本更低的全新模型，暂未纳入本次评测范围。

AI不是替代人工，而是放大安全工程师的能力：AI处理重复性筛查，人工聚焦深度分析和复杂判断。

定制化漏洞分析能力沉淀：针对 API 越权漏洞场景，构建专属漏洞分析技能体系，持续沉淀检测规则与标准化分析流程，保障规则具备落地实战有效性。

精细化危害评估体系：严格区分越权读取与越权操作两类风险行为，引入利益流向分析维度，规避一刀切式风险评级，评估更贴合业务实际风险。

Token 成本系统化优化：通过 MCP→CLI 格式转换 + 代码精准按需提取 + Early-Exit 提前终止 三层优化方案，整体实现 Token 成本降幅 95%+。

场景化分层模型选型：批量例行场景采用高性价比模型，核心关键场景启用高精度模型，在检测效果与使用成本之间实现最优平衡。

基于已完成的复核告警深度分析，识别出以下主要误报原因及改进方案。

问题：AI 发现中间层没校验就停止，直接认为存在漏洞，未追踪到最终数据操作层。方案：在 Skill 中增加指导规则。

问题：下游方法参数有越权可能，但上游调用时未传入资源ID。方案：分析Controller层Request对象，确认是否包含资源ID字段。如果上游Request中无资源ID字段，判定为"仅操作当前用户数据"。实施：在Skill中增加规则："优先检查Controller层入参，无资源ID则跳过越权分析"。

问题：内部网关转 Dubbo 传参信息 AI 无法获取，导致认证判断错误。方案：引入 Open 网关 Dubbo 配置信息（通过内部管理平台获取），新增 MCP 工具 get_dubbo_config，获取路由的 Dubbo 调用配置。实施：

问题：AI 将无敏感信息的读操作误判为越权。方案：细化响应体敏感性判断规则。

不敏感（可忽略）：
 纯状态码返回（code/msg/status）
 通用配置信息（活动名称、时间、状态）
 流程节点信息（taskId、nodeName）

网关路由 AI 驱动审计是一个面向 API 安全场景的智能化交付范式，将规模化安全审计升级为 AI 自动化检测 + 精细化危害评估 + Token 成本优化的标准化机制。

它回答的问题：如何在网关路由规模快速扩张的背景下，实现安全漏洞的全量自动化检测，同时将成本控制在可接受范围。

它证明的事：多个高危外网漏洞的实际发现，验证了 AI 在代码审计场景的有效性。单条成本 ¥0.23，某大型业务集群全量扫描一轮不到 1 万元，成本完全可控。人机协同模式有效：AI 批量筛查 + 人工深度验证，既保证效率又确保准确性。

它沉淀的方法：MCP→CLI 转换、精准代码提取、Early-Exit 优化，可复用于其他 AI 安全审计场景。

本项目输出标准化的漏洞分析报告，以下是模板结构：

## 漏洞分析报告


### 1. 路由信息
 路由ID: [必填：从 analyze_route 返回的 route_id]
 路径: [必填：分析的路由路径]
 目标服务: [必填：目标服务名称]
 描述: [必填：路由描述，如无则填"无"]


### 2. 接口功能分析
 接口用途: [必填：简要说明接口用途]
 业务场景: [必填：业务场景描述]
 调用方: [必填：H5前端/APP客户端/小程序/其他服务]
 数据敏感性评估:
  - 涉及数据类型: [必填：PII/金融数据/订单信息/配置信息等]
  - 敏感等级: [必填：critical/high/medium/low]
  - 影响用户范围: [必填：全平台用户/特定用户群/内部用户等]



### 3. 调用链分析
[必填：调用链树形展示，使用缩进表示层级关系，标记漏洞点]


示例格式：
[网关入口] (总耗时)
  └─ [认证服务]: [认证接口] (耗时) [认证节点]
  └─ [业务服务A]: [业务接口] (耗时) [漏洞点]
     └─ [业务服务B]: [数据库查询] (耗时)


关键中间件操作（只写与漏洞分析直接相关的部分）:
 SQL: [可选：列出执行的 SQL 操作类型，如 SELECT/INSERT/UPDATE/DELETE]
 Redis: [可选：如有 Redis 操作则填写]
 MQ: [可选：如有 MQ 操作则填写]


### 4. 漏洞详情


⚠️ 说明：
- 如果发现漏洞，必须填写此章节
- 如果未发现漏洞，填写"未发现漏洞"并跳过后续小节


#### 漏洞 1: [必填：漏洞标题]
- 严重等级: [必填：critical/high/medium/low]
- 类型: [必填：越权读取/越权操作/逻辑漏洞/竞争条件]
- 漏洞位置:
  - 服务: [必填：漏洞所在服务名称]
  - 方法: [必填：漏洞所在方法名]
  - 文件: [必填：文件路径:行号]
  - 仓库链接: [必填：GitLab 代码链接]
  - Trace ID: [必填：对应的 trace_id]
 问题描述: [必填：详细描述漏洞原因和利用机制]
 调用链位置: [必填：标注漏洞在调用链中的位置]
 问题代码:
  [必填：漏洞代码片段，包含行号]
 漏洞危害:
  1. [必填：直接危害]
  2. [必填：间接危害]
  3. 潜在连锁攻击: [必填：可能的连锁攻击场景]
  4. 合规风险: [必填：法律合规风险]
 修复建议:
  1. [必填：具体修复方案]
  2. [必填：具体修复方案]
  3. [可选：额外加固建议]


### 5. 分析置信度
- 置信度: [必填：高/中/低]
- 依据: [必填：说明置信度的判断依据]


### 6. 局限性
⚠️ 数据获取不全说明:
| 限制类型 | 说明 | 影响范围 | 建议操作 |
|----------|------|----------|----------|
| [限制类型] | [说明] | [影响范围] | [建议操作] |


### 7. 二方包依赖
- 涉及的二方包: [必填：group_id:artifact_id:version - 用途说明，如无则填"无"]
- 源码获取: [必填：已获取/未获取/不需要]


### 8. 涉及的微服务
⚠️ 重要：必须包含 commit_id 和 project_path


- [service_name1] (commit: [commit_id], project: [project_path])
- [service_name2] (commit: [commit_id], project: [project_path])

文 /炁源

关注得物技术，每周三更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

随着交易业务的快速增长，对质量保障工作提出了更高标准与全新要求。为提升研发体验和架构升级，大量后台页面经历从 Vue -> React -> 全栈的迁移过程。业务演进过程中，后台能力持续迭代与优化；团队在交付新能力的同时，同步保障存量链路的稳定与可预期行为。为进一步完善测试用例覆盖范围，高效支撑回归测试与重构验证工作，需通过技术手段升级质量保障模式，为业务与架构迭代提供更充分的质量支撑。

E2E 测试：即端到端测试，是一种从用户视角出发，模拟真实操作验证应用完整业务流程的自动化测试方法。自动化生成用例：用线上内部运营操作日志自动生成 E2E 测试用例，快速覆盖核心流程，解决用例缺失问题。智能元素定位：自动识别重构等场景 UI 变化并调整定位策略，实现维护流程的自动化。平台化管理：通过数据看板管理用例和执行结果，让 E2E 测试可追踪、可优化，提升测试效率。

基于以上分析，我们致力于构建一套自动化 + 智能化的 E2E 测试方案，该方案旨在支撑快速迭代开发模式，有效应对用例覆盖与重构验证等场景，从而在现有资源条件下，持续为业务快速迭代和技术架构升级提供可靠的质量保障。

提供基于线上真实运营行为的自动化 E2E 测试能力，能够实际发现页面线上/重构等场景的体验问题。在页面重构等迭代任务中，通过优化回归测试流程与资源分配，有效进一步提升测试支持效率。测试的页面代码覆盖率≥X%；无代码覆盖率场景步骤执行成功率≥X%。

页面代码覆盖率：页面用例在测试过程中 运行的代码行数 / 该页面关联的所有代码行数 * 100%。步骤执行成功率：页面用例在测试过程中 执行成功的步骤数 / 用例总步骤数 * 100%。

	名词解释	核心差异
传统 E2E	基于 DOM 的测试方案，主要通过操作和验证浏览器中的页面元素，来模拟用户行为的测试方案。	定位方式：依赖 XPath/CSS 选择器。 用例生成：手动编写或录制。 维护成本：高（DOM 变化需手动更新用例）。

	名词解释	核心差异
AI E2E	指利用人工智能技术，增强传统 E2E 测试的智能化、自适应性和效率的测试方案。	定位方式：视觉识别、语义化分析（如按钮文本、图标）。 用例生成：自动生成（基于用户行为日志或需求描述）。 维护成本：低（AI 自动适应 UI 变化）。

传统 E2E 优势：贴近真实用户操作：实际触发页面渲染和事件。跨页面流程验证：适合测试多步骤业务场景（如登录→下单）。传统 E2E 劣势：脆弱性：DOM 结构变化易导致用例失败（需频繁维护定位表达式）。执行速度慢：依赖浏览器渲染和网络请求。

AI E2E 优势：降低维护成本：减少因 UI 微调导致的用例失败。提升覆盖率：AI 可探索非预期路径（如异常输入）。AI E2E 劣势：黑盒性：AI 决策过程不透明，调试困难。高成本：需积累足够数据优化模型，复杂视觉处理需要更高性能。

基于上述对比分析，我们选用 AI 驱动的 E2E 测试方案，能够在支持重构场景的同时，显著提升用例生成的自动化水平，从而形成高效可持续的自动化测试解决方案。

	特征
Midscene	原生 JavaScript + WebExtensions API； 开源 AI 驱动 UI 自动化工具； 支持 Playwright、Puppeteer 定制行为逻辑； 支持 Dom 分析和视觉分析，如 Qwen-vl、Chain-vl。
browser-use	Python + 大语言模型（LLM）+ 浏览器驱动； 基于 Playwright； 同时支持视觉和非视觉模型； 同时支持 DOM 分析和视觉分析。

Midscene优点：基于 JS 技术栈，前端友好，开发成本较低；支持 Playwright、Puppeteer 定制行为逻辑；公开渠道反馈与迭代节奏相对清晰；支持 DOM 与视觉多模态分析。如上优点对工程化落地更友好。Midscene缺点：调用视觉/大模型时存在 Token 消耗与成本。

browser-use优点：支持 Playwright 定制行为逻辑；支持 DOM 与视觉分析，能力面较全。browser-use缺点：同样存在 Token 消耗与成本；基于 Python 技术栈，有开发语言熟悉成本。

综合评估后采用 Midscene，主要考量：与现有技术栈匹配：以 JavaScript 为主，便于与前端工程、现有工具链协同，降低接入与维护成本。能力与扩展方式符合需求：支持 DOM 与视觉等多路径信息输入，并可在需要时用 Puppeteer / Playwright 补充确定性、可编排的自动化逻辑，覆盖模型不稳定或不适用的环节。工程化与定制空间：定制与扩展路径清晰，便于按业务拆解控制流、做兜底与回归，贴合当前团队的交付方式。

核心流程图：

Midscene 测试过程详情：

核心流程可以概括为：将运营真实操作记录转化为可执行的测试用例，并通过智能化的方式在测试环境中回放验证。具体实现链路分为四个阶段：

这是整个流程的源头与起点，目标是实现测试用例的“自动化生产”。

核心输入	来自应用性能监控系统的会话级记录，反映内部运营在真实环境中的访问路径与关键交互脉络，是沉淀回归场景与边界用例的重要来源。
处理过程	数据接入：系统接收一个包含运营会话的链接。通过接口从监控系统拉取该会话的详细行为日志数据。
	行为解析：引擎解析原始日志，过滤无效操作（如快速连续点击、心跳事件），识别出有业务意义的原子操作序列。例如，将一次 “订单创建” 流程解析为：“访问某列表页”→“点击‘新建’按钮”→“在表单 A 输入‘X’”→“在表单 B 选择‘Y’”→“点击‘提交’按钮”。
	脚本转换：将解析后的行为序列，转换为 Midscene 可识别的结构化测试脚本。每个步骤包含：操作类型（click、input、select 等）、元素描述（如 “提交按钮”、“商品名称输入框”）、操作值，以及可选的上下文断言。
	用例入库：为生成的脚本分配唯一用例ID，并与源页面、业务域、来源会话等信息一同存入用例数据库，状态标记为“已生成”。
核心价值	基于真实业务流，用例生成更贴近线上高频、关键链路的典型走法，有助于缓解「回归范围难以收敛」的问题，并实现了测试用例从纯手工编排转为自动生成。

本阶段负责调度，将静态的测试用例转化为具体的执行任务。

触发方式	人工触发：测试或开发人员在平台用例列表页面，手动勾选一个或多个用例，点击“执行”。
	自动触发： 定时任务：针对核心场景用例，设置每日 / 每构建周期的定时回归。 事件驱动：与 CI/CD 流水线集成，在代码合并至特定分支，或生产环境发布后自动触发相关页面的用例集。
调度处理	触发后，系统将对应用例的状态更新为 “待执行”，并将其 push 到任务执行队列中。采用队列机制实现了任务的异步化与削峰填谷，支持高并发执行调度。

这是技术核心，由后台执行服务承载，让 AI 在浏览器中 “复现” 运营操作。

任务消费	常驻的后台执行服务监听任务队列，获取到一个待执行用例。
	服务启动一个无头浏览器实例，并注入 Midscene 智能驱动及 Qwen-VL 视觉模型。同时，代码覆盖率插桩工具被加载，用于后续数据采集。
智能回放	步骤读取：从用例库中按序读取测试步骤。
	视觉感知：Midscene 控制浏览器导航至目标页面，并将当前屏幕截图与 DOM 状态发送给 Qwen-VL 模型进行分析。
	意图理解与执行：AI 模型结合“当前屏幕画面”和“步骤指令”（如“点击登录按钮”），理解运营意图，在屏幕上定位目标元素，并执行对应的原子操作（点击、输入、滚动等）。这个过程模拟了人类“看到-理解-操作”的决策链。
	自适应处理：内置智能等待、多轮定位、异常场景判断（如弹窗、网络错误）等策略。例如，若首次未找到元素，AI 会尝试滚动页面后重新查找，或在合理时间内等待元素出现。
	结果记录：每一步执行后，记录成功/失败状态、失败时的错误信息、当前页面截图以及单步代码覆盖率数据。
结果收集	合并覆盖率：将每一步收集的代码覆盖率数据进行合并，生成该次执行针对被测页面的整体覆盖率报告。
	数据入库：将用例执行状态（成功/失败）、总耗时、步骤详情（含每一步的截图和结果）、覆盖率报告等完整数据持久化存储。
	状态更新：将用例状态最终更新为“执行成功”或“执行失败”。

这是价值的放大器，将自动化执行产生的海量数据转化为可指导行动的洞察。

看板管理	页面维度看板：展示所有被测试页面的核心指标聚合视图，包括 PV/UV、用例数、历史成功率趋势、代码覆盖率等，用于快速识别 “高风险页面”（UV 高但成功率低）和 “覆盖薄弱页面”（UV 高但覆盖率低），指导测试资源倾斜。
	用例管理列表：支持按业务域、负责人、成功率、标签等多维度筛选用例。每条用例展示其监控系统来源、执行历史、最新结果，支持人工打标（如“稳定用例”、“偶发失败”、“需重构”）。
深度复盘	执行详情下钻：点击任一用例，可展开查看其完整的步骤回放。任何失败的步骤都会高亮显示，并附有错误堆栈、AI 操作时的屏幕截图，以及该步骤覆盖的代码块。这使 “黑盒” 失败变得 “白盒化”，极大简化了调试和问题定位过程。
	历史趋势分析：查看单个用例或单个页面的历史执行结果趋势图，识别稳定性退化或持续性问题。
资产优化	基于代码覆盖率数据，自动化评估用例的有效性，识别并提示那些“执行成功但覆盖代码极少”的低价值用例，供决策是否清理。
	将人工复核确认的稳定用例标记为“核心回归用例”，变成自动化巡检，建立起一道质量防线。

通过这四个阶段的闭环，系统实现了从真实运营行为到自动化测试用例的完整转化，并将执行结果转化为可运营的质量数据。

实现方式：	输入为监控系统中内部运营操作日志链接。 对输入中的场景级描述进行解析，识别页面/模块级访问路径与关键操作步骤序列。 将上述场景级行为描述映射并生成可执行的自动化测试脚本，用于回归与稳定性验证。
核心价值：	降低维护成本：减少因 UI 微调导致的用例失败。 提升覆盖率：AI 可探索非预期路径（如异常输入）。

核心能力：	视觉模型能力突出，实时读取页面元素与状态，匹配用户行为上下文。 根据解析的用户操作序列，自动定位按钮 / 输入框，模拟点击、滚动、输入等行为。 自动识别弹窗、加载状态、网络异常等场景，触发智能重试或记录错误上下文，提升测试稳定性。
执行情况：	高效执行速度，支持并行执行。 视觉元素定位准确率精度高。 元素变更后脚本维护成本低。

设计机制：	规则引擎保障基础交互稳定性。 专注解决 “点击 / 输入 / 选择” 等 UI 交互问题。 通过自适应等待 + 多定位策略处理边界场景。
技术实现：	动态元素智能匹配。 智能重试策略。 滚动查找能力。

采集方式：	在用例执行完成后自动采集代码覆盖率。 动态合并覆盖率数据，形成页面指标。
应用场景：	评估用例价值，筛选高价值回归用例。 识别无效用例（可执行但覆盖代码占比低）。

我们在页面上实现了以下可运营能力，将 E2E 测试从黑盒脚本转变为可管理、可追踪、可复盘的平台系统。

页面列表（入口）：

展示内容：按业务域 / 系统 / 负责人筛选、页面级 PV/UV、用例数量、步骤执行成功率、代码覆盖率等指标。系统能力：页面维度汇总视图，将访问热度（PV/UV）与自动化质量指标（成功率 / 覆盖率）结合，指导用例优先级（高 PV 页面优先铺用例、优先治理）。

用例列表（抽屉）：

展示内容：每条用例绑定监控系统信息、点击行为数量、执行结果、步骤成功率、打标及备注、执行/删除操作。系统能力：以线上运营行为列表为用例数据，将 可执行性评估/识别执行结果与预期偏差/可信度（打标）统一实现。

执行详情（弹窗）：

展示内容：按步骤展示 CLICK 结果、详细错误堆栈/描述、页面截图缩略图、单步覆盖率、页面地址与 监控系统链接。系统能力：将每一步的线上行为与 E2E 执行对照落库，让失败从黑盒变为可复盘的证据链。

点击明细（单页面的用例序列）：

展示内容：点击序号、点击描述（如点击某某预览弹窗/眼睛按钮）、点击行为数量等。系统能力：系统会为 Click Scope 生成更可读的描述，便于非开发同学理解与复盘，也是后续策略库/稳定性治理的输入。

面对交易业务快速增长、技术栈频繁迁移、测试资源紧张的多重挑战，我们成功实现了基于真实运营行为的 AI 驱动E2E 测试方案。通过 Midscene 的视觉 AI 能力结合 Puppeteer 的精准控制，实现了用例自动化生成、智能交互执行和质量数据闭环。

之后我们将持续优化 AI 模型的准确率和稳定性，逐步实现从「用例执行」到「质量预测」的升级。同时推动平台向标准化、智能化方向发展，让质量保障真正成为业务创新的加速器而非瓶颈。

文 /卓翎

关注得物技术，每周三更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

推荐系统在提升用户体验的同时，也面临着信息茧房、兴趣收敛和内容同质化的挑战。随着用户与系统交互的深入，"推荐→用户反馈→再推荐"的闭环会逐渐强化用户的少数主兴趣，导致推荐结果趋同，降低用户的新鲜感与满意度。

生成式AI技术的快速发展为推荐系统带来了新的机遇。与传统的判别式匹配范式不同，生成式召回通过预测用户下一个可能点击的内容，实现从"匹配已知"到"预测潜在"的范式转变。在得物社区这一潮流生活方式平台上，用户对内容多样性和新颖性的需求尤为突出，这为生成式召回的探索提供了天然的场景。

基于此背景，得物启动了生成式召回方向的一期探索，旨在为下一代智能推荐系统的构建积累经验，探索推荐系统的 scaling-law 规律。

得物生成式召回系统采用 Generative Model 与 Rerank Model 联合训练的端到端设计，实现了生成与排序的协同优化。

生成式模型基于 Transformer 架构实现 Next-Token 生成任务，主要特征包括：

• 主序列特征：使用用户图文和视频的有效点击序列，以及对应的一 / 二 / 三级类目序列，截断最近 100 个行为；

• 首位 User Token 生成策略：联合训练辅助双塔模型产出首位 user_token，通过梯度隔离机制，确保生成任务与双塔任务的独立优化；

• 模型参数配置：采用当前 DeepRec 框架可承受的最大参数规模，配置为 n_layers=3，n_heads=4，dim=64，并加入 position embedding，增强时序建模能力。

重排模型与生成式模型联合训练，通过多任务学习提升召回精度：

• 联合训练机制：通过召回目标同时训练 rerank 模型的 item 塔与 user 塔，与 Generative Model 共享底层特征表示；

• 多任务梯度平衡：设计合理的损失权重分配策略，确保生成任务与重排任务的梯度协同优化。

生成式召回在线上推理时遵循"生成→向量化→检索→重排"的四步流程，兼顾了生成式模型的预测能力与向量检索的效率。

推理过程首先通过生成式模块的 Decoder 生成 Top-K 一级类目。经过离线 recall@100 参数搜索对比，确定 K=4 为最优配置，在召回效果与计算成本间取得平衡。生成的一级类目作为后续步骤的 “硬条件” 向量，为多兴趣建模提供结构化引导。

基于生成的 K 个一级类目，通过条件双塔的 user_tower 分别得到图文和视频的 K 个用户兴趣向量。这一设计实现了兴趣解耦，每个兴趣向量专注于特定类目下的用户偏好，避免了传统单向量表示中的兴趣混淆问题。

各兴趣向量分别进行 ANN 向量检索，从候选池中召回相关 item。召回结果再由 Rerank 模型进行精细化打分排序，最终通过蛇形 Merge 策略将多个兴趣通道的结果融合，作为最终召回列表输出。

为验证生成式召回的实际效果，我们在得物社区进行了严格的AB测试。结果也带来了社区线上指标的显著提升。验证了生成式算法的在得物落地的可行性，并预示着更大的探索潜力。

得物生成式召回一期实践表明，通过 “生成预测 + 引导召回” 的技术路径，可以在可控成本下，同时实现用户消费深度与兴趣广度的双重提升，为下一代智能推荐系统的构建提供了重要参考。本次实践成功验证了生成式召回在工业级推荐场景的可行性与有效性。通过 Generative Model 与 Rerank Model 的联合训练架构，实现了从判别式匹配到生成式预测的成功范式迁移。技术方案在保持推荐相关性的同时，显著提升了兴趣探索能力，为打破信息茧房提供了新的技术路径。

当前方案以一级类目作为生成目标，这是考虑到类目体系的稳定性和可解释性。下一步将基于社区样本训练 Item Embedding，并将 Item Token 离散化与用户 Next-Token 生成任务联合训练。这一演进将实现从粗粒度到细粒度的兴趣预测，提升召回的精准度。

通过框架迁移大幅提升模型参数量，支持大规模稀疏特征，探索更强大的生成式模型架构。具体方向包括：

• 扩展上下文窗口：从当前的 100 行为扩展到更长序列，更好建模用户长期兴趣；

• 改进注意力机制：研究稀疏注意力、线性注意力等高效注意力变体，平衡效果与效率。

借鉴得物在基于大语言模型的新颖性推荐上的经验，生成式召回可与 LLM 知识增强结合。LLM 的世界知识可以帮助识别用户潜在但未明确表达的兴趣，而生成式模型则负责将这些兴趣转化为可执行的召回策略，形成知识增强的生成式召回新范式。

探索利用多模态信息生成更丰富的用户兴趣表示，并尝试跨业务域的生成式兴趣迁移。在得物的业务生态中，社区内容与电商商品之间存在天然关联，通过跨域生成式召回，可以实现从内容兴趣到商品需求的自然过渡，提升业务协同价值。

文 /流煜曦

关注得物技术，每周一、三更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

做这个 Skill 的初衷很直接，也很现实：功能开发时容易"顺手新建一个"，而不是先复用已有组件，造成组件库越来越臃肿。这件事对团队的伤害其实是复利型的：

• 重复组件越来越多；

• 维护成本越来越高；

• UI/交互一致性越来越差；

• AI 生成代码时也更容易继续复制混乱。

所以做这个 Skill 的目标不是"帮 AI 搜索一下"，而是：把"复用优先"的思考过程流程化，让 AI 在写代码前先走一遍"查索引 → 判断是否复用 → 命不中再新建"的路径。

一开始很容易把问题理解成："做个组件搜索工具给 AI 用就好了"。但实际落地后发现，真正的问题不是工具有没有，而是：

• AI 会不会主动用；

• AI 什么时候用；

• AI 用完之后是否还能回到项目上下文；

• AI 能不能稳定走同一条流程。

这和 Vercel 在他们的 agent 评测里观察到的现象很像：skills 本身不是没用，而是 agent 往往不会稳定触发；而把基础知识放进 AGENTS.md 这种"被动上下文"后，稳定性反而更高。Vercel 的实验里，默认 skill 触发并没有提升通过率，加入显式指令后才明显改善，而 AGENTS.md 文档索引方案表现更稳定。这给了我一个很关键的设计方向：先解决 AI 的"决策点"问题，再解决 AI 的"能力"问题。

最终采用的是三层结构：

把"组件复用优先"的规则、组件索引入口、扫描后需要做的事情，放进 AGENTS.md（或同类常驻上下文机制）里。目的不是塞满文档，而是让 AI 每轮都知道：

• 这个仓库有组件复用机制；

• 默认应该先查可复用组件；

• 查不到再考虑新建；

• 扫描后还有描述补全流程需要继续执行。

这层解决的是：AI 根本不知道你有这套机制。不写进去，AI 主动使用 skill 的概率确实会很低（这点我踩过坑）。

如果运行环境支持 hooks（例如 Claude Code 的 UserPromptSubmit 支持在用户 prompt 处理前注入额外上下文），就可以做一层"意图路由增强"：在用户提到"组件复用 / 是否有现成组件 / 封装组件 / 查组件"等语义时，给 AI 注入提示，让它优先走组件复用流程。Claude 的文档明确写了 UserPromptSubmit 会在处理前触发，并且可通过 additionalContext 注入上下文。这层解决的是：AI 知道有 skill，但不一定想起来用。

Skill 不是只写说明文档，而是要提供：

• 明确的调用入口；

• 稳定的输出格式；

• 可执行脚本；

• 失败时的兜底逻辑。

OpenAI 的 Codex Skills 文档里提到 skills 是"渐进披露"机制：运行时先看到 skill 的元信息（尤其是 description），只有决定使用时才加载完整 SKILL.md；而且隐式触发高度依赖 description。这也是为什么 skill 的触发边界和描述要写得非常清楚。这层解决的是：AI 想用了，但执行过程不稳定。

下面是我这次组件复用 Skill 的几个关键实现点：

我在 SKILL.md 里明确规定：Agent 必须调用统一入口find-component.js。这样做的原因很简单：

• 避免 AI 在多个脚本之间犹豫（scan-components、match-component、resolve-scope……）；

• 避免 AI 漏掉前置步骤（比如索引不存在时先扫描）；

• 避免 AI 调用路径不一致导致结果不稳定。

统一入口做了几件事（都在 find-component.js 里）：接收查询词（query）、仓库根路径（repoRoot）、当前聚焦路径（startDir）。

• 如果 components.csv 缺失，内部自动触发run-scan.js；

• 调用 resolve-scope 计算当前应用和允许搜索范围；

• 调用 match-component 做匹配排序；

• 命中时记录使用（用于后续加权）；

• 按固定 JSON 协议返回结果（成功/失败/无匹配/是否触发扫描等）。

这一步本质上是把分散逻辑聚合成"一个业务动作"："查一下有没有可复用组件"，而不是"先算 scope，再查 CSV，再排序，再补扫，再记 usage"。这对 AI 很关键。

在 monorepo 场景里，组件复用很容易踩两个坑：

• 只搜当前 app，漏掉根级共享组件；

• 全仓乱搜，结果太多太噪音。

所以我在 resolve-scope.js 里做了一个比较工程化的范围解析策略：

• 读取 pnpm-workspace.yaml 解析 workspace 包；

• 根据当前聚焦文件/目录反推 currentAppRoot；

• 再结合 root_scope_patterns（例如 apps/_share/、packages/ 等）构建允许范围；

• 最终形成一个搜索集合：当前应用 + 根作用域共享包。

如果没有聚焦子项目（比如 startDir 就是 repo root），则切换为全量 scope。这个设计很像人类工程师的查找策略：先看"我这个业务应用里有没有"，再看"全局共享有没有"，而不是直接在整个 monorepo 海里捞针。

组件匹配如果只做字符串包含，很快就会变成垃圾召回器。我在 match-component.js + fuzzy-match.js 里做了一个组合评分，核心包括：

• 名称精确/包含匹配；

• 模糊匹配（编辑距离）；

• Token 重叠；

• 首字母缩写匹配（例如 dlp 匹配 DateLinkPicker）；

• 当前应用加权（当前 app 的组件优先）；

• 使用频率加权（常用组件更靠前）；

• 来源质量加权（README 推断质量高于纯 inferred）；

• 存在性校验（文件不存在则降权/过滤）；

• 记录类型权重（组件优先于依赖）。

这一步的目标不是追求"算法先进"，而是让排序更符合团队真实使用习惯："更可能被复用的组件排在前面"。此外我还加了一个低分阈值（NO_MATCH_SCORE_THRESHOLD）：

• 如果最高分太低，就认为是噪音命中；

• 可以触发一次扫描后再查；

• 还是低分则按"无匹配"返回，不把噪音结果塞给 AI。

这个点很重要，因为 AI 一旦拿到一些低质量候选，很容易"将错就错"。

很多类似方案停在“扫一遍生成 CSV”，然后就过时了。我这次把扫描做成了 run-scan.js -> index-manager -> enrich 的流水线，核心考虑是持续维护：

• 读取 agent-enrich-prompts.json；

• 找出 summary 占位符项；

• 按 id 回到 components.csv；

• 读取源码/README；

• 生成 summary + keywords；

• 再通过 update-component-summary.js 写回。

更关键的是在配置里启用了：

• agent_mode_no_fallback = true。

也就是说，在 Agent 模式下不走规则引擎降级，而是要求 Agent 必须完成这一步。这其实就是"流程化思考"的精髓：不是建议，而是纳入主流程。

一个很容易被忽视的点是：查找命中后，我还记录了使用行为（usage-tracker）。这意味着系统不是静态的，它会逐步学习团队偏好：

• 哪些组件经常被复用；

• 哪些组件在某个 app 里更常出现；

• 哪些结果应该在排序中更靠前。

这是一种很轻量但非常实用的反馈机制——不需要搞复杂训练，也能提升 AI 下一次推荐质量。

这也是我最想分享的部分：

如果不这样做，AI 主动使用 skill 的概率很低。原因不是 AI 笨，而是 agent 的执行是有"决策成本"的：

• 它要先意识到有 skill；

• 再判断该不该用；

• 再决定什么时候用。

而把基础上下文放进 AGENTS.md 或通过 hook 提前注入，本质上是在减少决策点。Vercel 的评测结果说明了这种"被动上下文"在某些场景下会更稳定。

只写一堆说明文档不够。AI 在工程任务里最需要的是：

• 一个可以直接执行的入口；

• 明确的参数；

• 稳定的返回结构。

所以我把 find-component.js 做成统一入口，并定义了固定 JSON 输出（ok / matches / noMatch / scanTriggered / hint / error 等），这会明显提升 AI 的执行稳定性。

这是最容易被忽略、也是最影响稳定性的一点。如果给 AI 暴露一堆脚本：

• resolve-scope.js；

• match-component.js；

• run-scan.js；

• scan-components.js；

• index-manager.js。

它理论上能拼起来，但实践里很容易漏步骤、顺序错、参数错。所以我在 Skill 里显式规定：

• 查找时用 find-component.js；

• 构建时用 run-scan.js；

• 更新描述时用 update-component-summary.js。

把复杂系统收敛成几个明确入口，AI 才容易稳定执行。

我原来以为"写 skill"是在给 AI 增加能力。现在更像是在做：给 AI 增加"默认工作方式"。换句话说，skill 不只是能力包（capability bundle），也是流程控制器（workflow controller）。

• AGENTS.md 负责"告诉 AI 世界观"；

• Hook 负责"提醒 AI 现在该用哪套流程"；

• Skill 负责"把动作做完，并且做得稳定"；

• 日志/CSV/usage 负责"让系统可观测、可迭代"。

这套思路不只适用于组件复用，后面也可以迁移到：

• 任务优化闭环；

• 日志分析标准化；

• 策略诊断流程；

• 代码规范治理。

这次组件复用 Skill 的开发过程，对我最大的启发不是"AI 能帮我写多少代码"，而是：AI 其实非常适合被放进一套清晰流程里工作。只要把下面三件事做好：

• 基础上下文（AGENTS.md / hooks）；

• 可执行入口（工具函数）；

• 明确流程边界（统一入口 + 输出协议）。

AI 就不会只是"一个会说话的代码补全器"，而会更像一个遵守团队规范的工程协作者。而这，才是我做这个 Skill 真正想要的结果。

引用文档： https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals

文 /魏无涯

关注得物技术，每周一、三更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

在电商数仓体系中，财务域是复杂度最高、容错率最低的领域。不仅因为财务对于数据准确性的要求高，也因为财务是横向域，与几乎所有的域都有数据交叉，因此对业务 Sense 的要求很高。财务数仓工程师本质上在做三件事：

• 业务翻译：将交易、支付、资金、促销补贴、成本等数十个业务系统的数据，翻译成通用的财务语言；

• 资产架构：从 ODS 到 DWD、DWS、ADS 层层构建，确保财务 UE、财务管报等公司核心指标算得准、算得快；

• 质量兜底：GMV 口径是否统一，退款是否扣减，分摊是否跨周期对齐，任何一个字段的偏差都可能导致错误的经营决策。

财务域的独特挑战在于：字段间存在严格的数学公式关系（正向－冲销＝冲销之后），业务规则涉及跨周期分摊，对于质量的要求极高。如果单纯依靠人工兜底，要么容易出错，要么需要冗余大量人力做复核。尤其是在交付压力大的时候，质量问题就更容易被忽视。

从财务数仓的特殊性出发，我们可以总结财务数仓的痛点，大体可以分为如下几类：

基本上，在需求承接的每个环节，都可能因为"人"的问题，带来隐患。

为了有效解决"人"的问题，比如催得太急、看不过来、没看仔细、理解错误等问题，我们引入 AI 来做改变。核心思路是：大模型的介入不是替代数仓开发工程师，而是在「需求理解 → 代码编写 → 质量测试 → 文档沉淀」每个环节注入强推理能力。利用 AI 来代替人做大量的重复性工作，同时减少低级错误概率。

那么为什么 AI 能做到这一点？从技术发展的趋势看，有三个核心能力支撑了这一变革：

• 超大上下文打破知识孤岛：200k+ token 的上下文窗口，可以将表结构定义、词根字典、指标计算逻辑一次性注入模型的 “工作记忆”，实现基于全域元数据的推演，让大模型具有记忆；

• 业务语义的自动抽象与对齐：大模型能理解 “日活”“留存率”“归因窗口” 等业务术语，并映射为具体 SQL 实现，减少因需求理解偏差导致的返工；Claude 在编码领域显著优于其他模型，是因为它能 “懂” 业务逻辑，而不是简单的机械执行；

• 突破人类极限的规范执行力：人工在紧迫工期下规范遵守率通常明显下降，而大模型注入规范后，可稳定维持在高位。只要指令给得明确，大模型 “几乎” 不会出错。

参考：亚马逊 AWS 对于构建一个强大、具备自我纠错能力且能查询多种数据源的 Text-to-SQL 解决方案架构图。

基于上述观点，在财务领域，大模型可以在哪些具体的环节落地呢？以下是根据笔者近期实践经验，列出的可落地场景及提效预期。

如果借用自动驾驶的分级标准，当前数仓大模型应用正处于从 L2（辅助驾驶）向 L3（有条件自动驾驶）过渡的阶段，即在明确的 Prompt 约束与规范文档支撑下，AI 能接管绝大部分标准化的执行动作。

在财务域的实践中，我们也是按照这套自动驾驶分级的方法，将日常工作拆解成了三级：

这种分工背后的逻辑是：规范执行是人类的短板、AI 的长板；业务判断是 AI 的短板、人类的长板。 人工在紧迫工期下对命名规范、分区约束、注释要求的遵守率通常明显下降，且容易因疲劳产生遗漏；而 AI 一旦"学会"了团队规范，输出的规范遵守度可稳定维持在较高水平。反过来，AI 无法替代的是那些需要理解业务上下文、权衡取舍、处理分歧的工作。

学习 Andrej Karpathy 关于 ChatGPT 分享的内容时，最大的感受是：AI 最强的能力，是 "泛化"。 因此，如果我们可以把数仓研发的链路拆分清楚，那么 AI 必然能够对其中的每一个环节提效，最终带来研发效率的大幅度提升！

因为：仅第一轮模型设计，就涉及百张以上的表、多个子域、十余个业务过程、数百个指标。如果考虑到后续的二次/三次迭代，工作量势必大到无法想象。在当前以交付为主的阶段，很难花费如此多的时间做基建。以某次核算项目为例，各层表数量分布如下：

同时，财务域的核心特征是来源多（全公司系统）、指标多（单表字段数众多），但以可累加指标为主。财务严格意义上没有原子指标，全是基于业务指标加工出来的派生指标，且一个财务指标往往有多种口径：业务口径、资金口径、财管报口径。并且，项目涉及多个子域（核算域、技术成本域、促销补贴域、商业化域、分析域），覆盖从「计费 → 核算 → 结算 → 财务分析」的端到端业务过程体系。如果要彻底理解核算 OneData 的构建，不仅要懂数仓，还要懂财务，还要熟悉公司财务系统，这个要求非常难做到！主要难点集中在四个方面：

口径溯源极其复杂：大量逻辑在工程侧实现，绝大多数表缺失业务文档、技术文档、口径文档，口径逻辑需要基于代码猜测，存在错误可能性，溯源工作量巨大。

规范执行不一致：财务域涉及表命名规范（DIM/DWD/DWS/ADM 各有格式要求）、时间周期规范（1d/7d/30d/wtd/mtd/ytd 等多种）、生命周期规范、刷新周期规范、标准字段英文命名原则（{主体}{业务场景}{币种标识}{度量类型}{时间单位}）。规范越细，人工遵守率越低。

跨域依赖复杂：财务是横向域，与各业务域交叉。核算域依赖大量上游表，技术成本域需要从云服务、算法、产研人力、标注人力等多个来源接入数据。

文档输出繁琐：每个 ADM 表都必须包含 OnePage 文档（OneData 方案最重要内容），加上口径文档、模型使用说明、下游 mapping 文档，文档间大量重复但需各写一遍。

所以，我们更需要通过 AI 的能力，来做一套新时代的建模方法论，以适应 “低投入、大设计” 的智能建模场景。

第一个方法论：规范沉淀是前提

AI 的输出质量完全取决于输入的规范文档质量。财务核算项目中，我们沉淀了完整的规范体系作为 Prompt 的核心输入，包括：

• 模型设计规范：表命名、时间周期、生命周期、刷新周期；

• 标准字段英文命名原则：{主体 /fin}{业务场景 / 费用类型}{币种标识}{度量类型}{时间单位}；

• 财务业务全链路设计理念：计费层 → 核算层 → 结算层 → 财务分析层；

• 业务过程总线矩阵：多个业务过程与多个维度的交叉关系；

• 数据质量监控规范：完整性、准确性、一致性、合规性、业务规则等多个大类。

第二个方法论：迭代是常态

不要期望 AI 一次给出完美结果。验证的关键是选择复杂字段进行抽查 —— 在财务场景中，重点验证涉及条件取值的字段（如分摊逻辑、冲销逻辑、多口径指标），对照 SQL 代码验证溯源路径。每次迭代的产物不只是修正后的输出，更重要的是规范文档的完善。因此，针对每次迭代的结果，快速识别要改动的点并修改，这一点就很重要。也就是说，AI 可以显著提升我们的迭代速度！

第三个方法论：海量文件阅读

因为超大的 Context，所以不仅可以把历史上已有的文档一次性灌入进去，也可以把原有设计链路的表和代码交给大模型理解，省去大量阅读和理解的时间。同时，能够帮我们精准地画出业务架构图，辅助数仓工程师理解业务、构建模型。例如财务数仓架构图，很多子模块的逻辑，都是大模型读取代码后输出思路，再由数仓团队整理形成的。

将以上规范作为学习知识输入给模型，再把原始数据表给到模型，模型即可以产出建模建议。

Prompt 示例：

第一次生成的效果展示了初步建模建议，在经过不断的调优和知识输入后，最终版本要丰富很多，形成了完整的财务核算数据 OneData 方案。

经过一段时间的实施，第一版核算数据结构已经落地，效果如下：

• 效率提升显著：百张表的口径溯源、文档输出等标准化工作大幅压缩；

• 规范遵守率大幅提升：表命名、字段命名、时间周期等规范严格执行，遵守率较人工有明显改善；

• 可复用性强：规范文档、工具脚本、Prompt 模板、工作流程 SOP 均可跨子域复用（已在核算域、技术成本域验证）；

• 数据质量监控体系：基于口径逻辑自动推荐 DQC 规则（完整性、准确性、一致性、合规性、业务规则等多大类）。

以财务 UE 表某次迭代为代表的案例，主要成果有：

• 代码结构优化，可读性大幅提升：指标分段清晰、逻辑分层明确，维护成本明显降低；

• 代码开发速度提升：在规范与口径已对齐的前提下，从需求到可上线代码耗时缩短；

• 性能优化：整体基线提前完成，为下游留出更多缓冲时间。

那么，我们是如何实现这种成果的？主要靠两点，一是 PRD 快速阅读与理解，二是代码开发效率提升。

PRD 阅读与理解方面，AI 能够帮我们实现：

快速将 PRD 中的目标、指标、维度、过滤条件提炼为结构化要点；对「大促期间」、「小仓卖家」、「冲销」等未精确定义的表述，自动生成待确认问题清单；输出「指标口径」「统计周期」「主键与粒度」等需确认条目。

代码开发效率提升方面，AI 能够帮我们实现：

基于词根、分层、命名规范与建表模板，生成符合数仓规范的 DDL 与 SELECT 语句；多维度聚合、归因逻辑、窗口函数、多层嵌套等复杂逻辑，由模型生成初版 SQL，人工校验微调；对存量长 SQL 进行分段、抽取公共逻辑、统一风格与注释。

财务 UE 表迭代需求使用 AI 开发后，具体效果如下：

指标结构分段、编码规范性、注释清晰度：

• 新表：按数仓分层与命名规范生成 DDL 与 SQL，指标按业务域/统计口径分段组织，注释完整（字段含义、口径说明、KEY 标记等），既符合规范又便于阅读。

• 旧表改造：在保留业务逻辑正确性的前提下，对历史「屎山」代码进行结构化改写——统一别名、补全注释、拆分过长子查询、显式写出分区过滤等，使后续维护与排查成本明显下降。

• 代码展示对比：改动前 vs 改动后，可从「可读性、规范遵守度、注释覆盖」等维度做对比分析。

代码撰写速度大幅度提升：

• AI Coding 的主要步骤：Step 1：整理需求 → 技术文档 将 BI 需求文档中的字段信息整理进技术文档，明确字段范围。

• Step 2：大模型分析字段来源 提示大模型读取 DWD 源码，分析哪些字段已存在、哪些需要新增关联。

• Step 3：大模型编写 ETL 代码 由大模型自动在 DWD → DWS → ADM 三层添加字段代码，输出改动代码集合。

• Step 4：命名规范校准 引入指标字典和 Cursor Rules，让大模型按规范重命名字段（去掉不规范后缀）。

• Step 5：测试 SQL 生成与跑数验证 大模型生成自测 SQL，逐步验证各层数据一致性，不通过时追问原因并溯源。

性能优化及自动调参：

• 自动识别性能瓶颈：结合执行计划、大表扫描、数据倾斜等常见问题，由模型分析 SQL 与表结构，指出潜在慢点。

• 优化建议生成：在分区裁剪、谓词下推、JOIN 顺序、中间结果物化等方面给出具体改写建议。

• 参数调优方案：针对 Spark/ODPS 等引擎的资源配置、并行度、倾斜处理参数，给出可落地的调优建议，供运维或开发同学选用。

基线优化提升案例：

• 原链路：多张表串行/并行产出，整体耗时较长。

• 新链路：经模型辅助做表合并与逻辑下沉，收敛至更少的表，整体耗时明显缩短。

• 优化效果：在保证口径一致的前提下，表数量与运行时间双降，基线提前完成，资源占用与调度依赖均得到简化。

在数仓开发工作中，数据测试是保障数据质量的关键环节，但也是最复杂、最耗时的环节之一。特别是在财务类指标开发中，数据测试面临着多重挑战：

测试复杂度高，影响面广：

一个指标的改动往往不是孤立的，它会引发连锁反应，影响其他相关计算指标。在复杂的业务场景中，一个字段的修改可能需要同步验证数十个相关字段的正确性。这种复杂的依赖关系使得人工测试很难做到全面覆盖，容易出现遗漏。

业务逻辑复杂，公式验证困难：

财务指标通常有明确的数学公式关系：正向 - 冲销 = 冲销之后：需要验证每个字段的正向值、冲销值、冲销之后值之间的计算关系；子项相加 = 汇总项：需要验证各个子项字段相加是否等于汇总字段；

财务的分摊逻辑涉及跨周期问题，难以验证：某些业务场景下，订单时间与收入确认时间不匹配，需要进行跨周期分摊，测试逻辑极其复杂。这些公式关系看似简单，但在实际测试中，需要考虑各种边界情况、精度问题、空值处理等，验证工作量巨大。

测试用例设计困难：

一个需求往往衍生出大量测试点，单纯凭借个人经验和能力，很难做到全面覆盖，容易出现测试盲区，包括：

• 字段级别的计算逻辑验证；

• 汇总关系的验证；

• 冲销逻辑的验证；

• 边界场景的验证；

• 精度问题的验证；

• 业务规则转化的验证。

业务语言到数据语言的转化困难：

业务人员描述的需求往往是自然语言，而数据测试需要将其转化为精确的数据验证逻辑。例如："退小仓场景下，卖家邮费出资放在第一笔收入冲销，挂在最后一单"；"邮费返利抵减技术服务费"；"跨周期分摊，商业化订单时间与交易订单时间不匹配"。

那么，我们如何通过 AI，来解决这些复杂问题呢？以某次财务 UE 表邮费迭代项目为例，我们深度应用 AI 进行数据测试，取得了显著效果。