Snowflake Cortex Code 的规范驱动开发:将 SDLC 方法论引入 AI 辅助工作流 | 技术实践
点击查看原文>
2026 年,智能体将在企业级应用中取得哪些实质性突破?点击下载《2026 年 AI 与数据发展预测》白皮书,获悉专家一手前瞻,抢先拥抱新的工作方式!
为何 AI 辅助开发需要遵循 SDLC 的严谨性
SDLC(软件开发生命周期)是一套将需求转化为可运行软件的结构化流程,涵盖需求收集、方案设计、编码实施、测试及部署等环节。正是这套严谨的规范,防止大型项目因自身复杂性而走向崩溃。
Snowflake Cortex Code 能够在单次会话中构建完整的应用程序——具备全代码库访问权限、多文件编辑能力、任务编排功能以及原生 Snowflake 集成。然而,构建一个完整的应用,并不等同于构建一个正确的应用。
以一个包含 5 个页面的分析仪表盘为例,其背后涉及数十项隐含决策:图表库的选择、计算方法的定义、数据流模式的设计、缓存策略的制定,以及逻辑层与展示层的分离。若缺乏结构化的约束,智能体将代为做出这些决策——速度快、信心足,却可能偏离正确方向。一个能在几分钟内生成数百行可运行代码的智能体,会同等程度地放大良好的流程与糟糕的流程。
以下这些保障大型项目成功的实践,绝不能因为代码由 AI 生成而被视为可有可无:
代码先行,需求前置:开发人员与智能体在实施前需共享一份明确的契约。需求范围应无歧义,技术选型应无意外;
实现先行,架构前置:分层逻辑、模块边界与 API 签名必须预先锁定,以确保跨文件的逻辑一致性;
全流程可追溯:每项功能均对应一条编号需求。代码审查的标准应从“这段代码看起来对吗?”转变为“这段代码是否符合我们事先达成的共识?”;
变更时保留既定行为:在修复缺陷或进行重构时,需明确记录不可变更的行为,将隐含假设转化为可核验的清单。
规范驱动技能
规范驱动技能将这种规范化流程引入 Cortex Code。它通过一个包含强制审批关卡的结构化五阶段生命周期来指导开发过程:

在每个关卡,Cortex Code 都会停止并等待您的明确批准才会继续。您在每一个决策点都保持完全掌控。
核心能力:
EARS 标注法需求 — 根据自然语言描述生成正式、可测试的需求(当……时,系统应……,以便……);
三种工作流类型 — 新功能开发、缺陷修复(含回归预防)、以及重构(含行为保留);
持久化规约产物 — 生成 requirements.md、design.md 和 tasks.md,作为持续演进的项目文档。
适用场景:
从零开始构建完整的应用程序(涉及多文件、多模块);
添加跨越多个文件或层级的重大功能;
修复需要防止周边行为出现回归的缺陷;
在保留模块外部接口的前提下进行重构。
使用方法:
只需触发一次技能—可通过明确指令(例如:“使用规范驱动技能,构建一个股票分析应用”)或通过自然语言(例如:“我想构建一个股票分析应用”)。Cortex Code 会根据“构建功能”、“修复缺陷”、“重构”或“创建规约”等短语自动检测意图。明确表达更为可靠;自然语言在大多数情况下也能正常工作。技能激活后,只需自然回应即可 — Cortex Code 会引导您走完每个阶段,提出澄清性问题,展示文档产物供您审阅,并在获得批准前等待您的指示。
端到端示例:构建股票分析应用
理解工作流的最佳方式是观察其实际运行。以下是一个完整演练——构建一个包含 5 个页面的 Streamlit 股票分析仪表板,集成 Snowflake 数据、Plotly 图表、技术指标和量化信号。
展示的每个提示和响应均来自真实的 Cortex Code 会话。演练内容详尽;如需快速概览,请跳至入门指南部分。
第 1 阶段:需求澄清
您的提示:
使用规范驱动的技能,我想构建一个股票分析Streamlit应用5个主要板块:1.道指30成分股概览仪表板 - 所有30只股票的汇总表,含日内涨跌幅、热力图可视化2.单只股票深度分析 - K线图、成交量、关键统计指标3.行业板块分析 - 按GICS行业分类分组,进行表现对比4.技术分析 - 简单移动平均线、指数移动平均线、布林带、相对强弱指标、指数平滑异同移动平均线,附带买卖信号5.量化信号 - 动量、波动率、均值回归、相关性矩阵数据源:股票数据位于Snowflake数据库 FINANCE__ECONOMICS 和 DB_STOCK 中所有Snowflake资产置于 DB_STOCK 中,本地文件置于 stock_app/ 文件夹内图表使用Plotly绘制,数据访问使用 st.connection('snowflake')仅限本地运行 - 不部署至Streamlit in Snowflake
执行动作:Cortex Code 进入澄清阶段。它会探索您的 Snowflake 数据库——执行 SHOW SCHEMAS 命令,查询 INFORMATION_SCHEMA,检查 FINANCE__ECONOMICS 和 DB_STOCK 两个数据库中的表结构——以了解哪些数据可用。它发现 DB_STOCK.CURATED.DAILY_STOCK_PRICES 表包含自 2018 年至今超过 22,000 个股票代码的开盘价、最高价、最低价、收盘价、成交量数据,而 DB_STOCK.CURATED.COMPANIES 表包含公司元数据。同时,它还发现两个数据库中均不存在行业分类数据。
然后它会提出有针对性的澄清性问题:
Cortex Code 响应:
在我创建规范之前,需要先澄清以下几点:1.道指 30 范围:仅限当前 30 只成分股,还是也包括历史成分股?2.数据连接:使用 st.connection('snowflake') 配合 secrets.toml,还是直接用原生 snowflake.connector?3.部署方式:仅本地开发,还是也包括 Streamlit in Snowflake(SiS)?
您的回复:
仅当前 30 只。使用 st.connection。仅本地。执行动作:Cortex Code 汇总了所有已获取的信息,并在阶段 1 审批关口处暂停:
Cortex Code 响应:
以下是我的理解:用户故事:金融分析师需要一个 Streamlit 仪表板,用于分析道指 30 成分股。5 个页面:概览、个股详情、板块分析、技术分析、量化信号。数据源:DB_STOCK.CURATED.DAILY_STOCK_PRICES(OHLCV 数据)、DB_STOCK.CURATED.COMPANIES。已识别数据缺口:不存在板块/行业分类表——将创建包含 GICS 分类信息的 DOW30_REFERENCE 表。数据连接:使用 st.connection('snowflake') 配合 @st.cache_data(ttl=300)。图表:全部采用 Plotly(K 线图、矩形树图、条形图、饼图、散点图、热力图)。计算逻辑:技术指标和量化信号在已缓存的 DataFrame 上通过纯 pandas 进行计算。超出范围:实时数据流、用户认证、投资组合跟踪、新闻情绪分析、期权数据、SiS 部署。上述理解是否正确?我是否可以继续创建规范?
你的回复:
是的。请注意,Cortex Code 主动识别了一个数据缺口(缺少板块分类表)并提出了解决方案——这一切都发生在编写任何一行代码之前。
第 2 阶段:规范制定
执行动作:Cortex Code 生成规范文档 specs/features/dow30-stock-analytics/requirements.md。该文档为一份正式的规范文档,采用 EARS(Easy Approach to Requirements Syntax,简易需求语法)标记法,共包含 27 项需求,覆盖全部 5 个页面的各项功能。本次仅创建该文件,不包含设计文档或任务分解文件。
以下为各章节关键需求摘要:
Cortex Code 响应:
REQ-001:道指 30 成分股参考表系统须维护一张名为 DB_STOCK.CURATED.DOW30_REFERENCE 的数据表,用于存储道琼斯工业平均指数当前的 30 只成分股信息。表中须包含以下字段:TICKER(股票代码)、COMPANY_NAME(公司全称)、SECTOR(GICS 行业板块)、INDUSTRY(GICS 子行业)。目的:使所有页面能够将价格数据与板块及行业元数据进行关联查询。REQ-006:市场热力图当概览仪表板加载时,系统须展示一个使用 Plotly 实现的矩形树图热力图。图中每个色块代表一只道指 30 成分股,色块面积按成交量加权,颜色按日涨跌幅进行映射。目的:使用户能够直观识别全部 30 只成分股的相对成交量及表现情况。REQ-009:交互式 K 线图当用户选定某只股票及时间范围后,系统须展示一个基于 Plotly 实现的交互式 K 线图,显示所选周期内的 OHLC(开盘价、最高价、最低价、收盘价)价格数据,并配备时间范围切换按钮(1 个月、3 个月、6 个月、1 年、5 年、全部)。目的:使用户能够在不同时间跨度下分析价格形态。REQ-018:RSI 副图指标当用户在技术分析页面查看某只选定股票时,系统须展示周期为 14 日的相对强弱指标(RSI)副图,并在图中包含位于 70(超买)和 30(超卖)的水平参考线。目的:使用户能够识别超买与超卖状态。REQ-026:综合信号评级系统须综合动量得分(权重 40%)、波动率得分(权重 20%)及均值回归信号(权重 40%),为每只股票计算一个综合信号,并输出单一评级(看涨 / 看跌 / 中性)。目的:为用户提供每只股票单一且具备可执行性的参考指标。…(共 27 项需求,编号 REQ-001 至 REQ-027)您是否批准此规范?
每项需求均附有具体的验收标准(以复选框形式呈现)。例如,针对 K 线图的验收标准包括:OHLC 数值准确无误、时间范围筛选功能正常、支持缩放/平移/十字光标、通过 rangebreaks 处理周末休市缺口、默认时间范围设为 1 年。
您的回复:
是执行动作:Cortex Code 将文档头部信息中的状态更新为 status: approved,并进入第 3 阶段。该规范即成为后续开发的契约——此后的每一项决策均须追溯至对应的编号需求。

第 3 阶段:设计阶段
执行动作:基于横跨 5 页的 27 项需求、多数据源以及两个计算模块,Cortex Code 在 specs/features/dow30-stock-analytics/design.md 路径下生成了技术设计文档。此阶段仅创建设计文件。

该设计定义了一个三层架构,并严格遵循关注点分离原则:
数据层(data/snowflake_queries.py) ——包含 6 个带缓存的查询函数,负责处理所有与 Snowflake 的交互。每个函数均使用 @st.cache_data(ttl=300)装饰器。禁止其他任何模块直接访问 Snowflake;
计算层(utils/indicators.py 与 utils/quant.py)——包含 13 个纯 Pandas 函数,用于技术指标计算(SMA、EMA、布林带、RSI、MACD、信号检测)和量化分析(动量、波动率、均值回归、相关性、综合评分)。该层不依赖 Snowflake,也不依赖 Streamlit;
展示层(pages/*.py) ——包含 5 个 Streamlit 页面,每个页面映射到特定的需求(例如,4_Technical.py 对应需求编号 REQ-016 至 REQ-020)。页面调用数据层获取 DataFrame,将其传递给计算函数,并使用 Plotly 渲染结果。
Cortex Code 响应:
设计文档明确了以下内容:-完整文件结构 — 涵盖 data/、utils/、pages/ 和 config 目录下的 16 个文件。-Snowflake DDL — 包含针对所有 30 支道指成分股的完整 CREATE TABLE 及 INSERT SQL 语句,并附带 GICS 行业/子行业分类数据。-模块 API — 定义了所有函数签名,包含参数、返回类型及列名约定。-页面布局 — 规定了每个页面将使用的 Streamlit 控件及 Plotly 图表类型。-关键设计决策 — 所有计算均使用纯 Pandas 完成(不使用 Snowflake 用户定义函数),为 200 日均线预留 250 天的预热缓冲数据,以及处理周末空缺的区间中断逻辑。您是否批准此设计?
您的回复:
是的,我批准。执行动作:Cortex Code 将更新 design.md 的前置元数据状态为 status: approved,并进入第四阶段。架构现已锁定——后续执行将严格遵循此蓝图执行。

第 4 阶段:实施阶段
执行动作:Cortex Code 智能体创建 tasks.md 文件,其中包含 11 项实施任务,并开始系统性地逐一执行:
Cortex Code 响应:
实施计划:1.创建 DOW30_REFERENCE 表(Snowflake DDL)2.创建 data/snowflake_queries.py(包含 6 个带缓存功能的查询函数)3.创建 utils/indicators.py(包含 SMA、EMA、BB、RSI、MACD 及信号检测逻辑)4.创建 utils/quant.py(包含动量、波动率、均值回归、相关性、综合评分等函数)5.创建入口文件 app.py6.创建页面 pages/1_Overview.py7.创建页面 pages/2_Stock_Detail.py8.创建页面 pages/3_Sectors.py9.创建页面 pages/4_Technical.py10.创建页面 pages/5_Quant_Signals.py11.创建 requirements.txt 与 secrets.toml.example 配置文件
Cortex Code 智能体逐一攻克各项任务,所生成的文件严格遵循已批准的设计规范——正如需求 REQ-018 所规定,RSI 计算采用了 Wilder 平滑算法;综合信号生成严格应用了需求 REQ-026 中定义的 40/20/40 权重配置;每一个函数签名均与设计文档中的 API 定义完全吻合。
所有 11 项任务完成后,Cortex Code 智能体在阶段 4 的审批关卡处暂停。
Cortex Code 响应:
实施完成。已创建的 Snowflake 对象:-DB_STOCK.CURATED.DOW30_REFERENCE —— 包含 30 支道指成分股及其 GICS 行业/子行业分类数据。-已创建文件(共 16 个):-app.py — 带侧边栏品牌标识的应用入口-data/snowflake_queries.py — 6 个带缓存功能的查询函数-utils/indicators.py — 7 个纯 Pandas 实现的技术指标函数-utils/quant.py — 6 个纯 Pandas 实现的量化信号函数-pages/1_Overview.py 至 pages/5_Quant_Signals.py — 全部 5 个前端页面文件-requirements.txt、.streamlit/secrets.toml.example — 依赖与环境变量示例文件是否准备进入验证阶段?
您的回复:
是的第 5 阶段:验证阶段
执行动作:Cortex Code 对照已批准的规范执行系统性验证:
Cortex Code 响应:
验证结果:检查项 | 结果- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| - - - - - - -需求可追溯性 - 全部 27 项需求均已映射至实现代码 27/27 | 通过文件结构 - 全部 16 个文件均符合 design.md 设计 | 通过数据层 - 6 个查询函数,签名正确,缓存机制有效 | 通过计算层 - 13 个函数,纯 pandas 实现,公式正确 | 通过展示层 - 全部 5 个页面均实现了分配的需求 | 通过语法校验 - 全部 11 个 .py 文件编译通过 11/11 | 通过架构合规性检查:- 三层分离原则得以维持 - 无页面直接导入 Snowflake 连接- 所有查询均使用 @st.cache_data(ttl=300)- 所有图表均使用 Plotly 绘制- 技术指标页面为计算 200 日均线额外拉取了 250 个预热交易日数据27 项需求验证通过。规范驱动工作流已完成。
每项需求均精确追溯至其具体实现位置—例如,REQ-018(RSI 副图指标)映射至 4_Technical.py:174–185 及 indicators.py:35–54。这种可追溯性意味着后续审查代码的任何人员都能够清晰理解每一个函数存在的缘由。

结果
一次对话。五个阶段。一个功能完整的五页分析仪表板—外加三项永久性的规范文档产出物:
specs/features/dow30-stock-analytics/├── requirements.md # 27条EARS需求—契约文档├── design.md # 架构、API、数据流—蓝图文档└── tasks.md # 11项实施任务—检查清单
六个月后,当有人问“为什么综合信号使用 40/20/40 的权重分配?”—答案就在 REQ-026 里。当新开发人员加入时,他们在动手写代码之前会先阅读 design.md。这些规范文档不是一次性的废纸,而是该项目的永久记忆。
使用 Cortex Code 并基于规范驱动(Spec-driven)技能构建的功能完整的股票分析 Streamlit 应用。


Bug 修复工作流:三部分规范文档
使用规范驱动技能修复 Bug:热力图所有方格均显示为白色Cortex Code 分析该 Bug,然后生成三部分规范文档:

第三部分是关键所在。通过记录绝不能更改的内容,智能体拥有了一份修复后可对照核验的检查清单。杜绝静默回归。
重构工作流:行为保留
使用规范驱动技能,将数据层重构为使用原生 Snowflake 连接器在进行任何代码更改之前,Cortex Code 会记录需保留的行为:

未经您明确批准需保留的内容,智能体无法执行重构。
入门指南
安装方式:
# 用户级(适用于所有项目)git clone https://github.com/sfc-gh-tjia/coco_skill_spec_driven_dev.gitcp -r coco_skill_spec_driven_dev ~/.snowflake/cortex/skills/spec-driven# 或项目级(单项目)cp -r coco_skill_spec_driven_dev .cortex/skills/spec-driven
使用方法:以 use spec-driven skill, [您的意图]开头,或自然描述需求— Cortex Code 会检测工作流类型并引导您完成各阶段。

激活后,可自然回应:yes、approved、add requirement for error handling、option 2。
结语
智能体编码工具已彻底改变了我们构建软件的速度,但并未改变软件成功的根本要素:清晰的需求定义、经过深思熟虑的架构设计,以及系统化的验证流程。这些实践之所以不可或缺,是因为模糊性会层层累积——每一个不明确的需求都可能演变为错误的假设,而每一次错误的假设最终都将导致返工,甚至更糟,演变为数月后才暴露的生产环境缺陷。
Snowflake Cortex Code 中的规范驱动技能将这些实践固化于流程之中。它并非繁文缛节,而是关键的质量检查点:智能体在每个阶段都必须获得您的明确批准方可继续推进。您需要在设计开始前审阅需求,在编码实施前批准架构,并在宣告完成前依据规范进行最终验证。
针对漏洞修复场景设计的三段式 bugfix 格式,直击困扰所有代码库的常见故障模式——修复一个漏洞时无意中引入新的回归问题。通过明确记录“不应改变的行为”,该技能将“别破坏现有功能”这一祈使要求,从美好愿望转变为可逐项核验的清单。
所有产物均会持久保留。需求文档、设计文档和任务列表将成为项目永久的历史档案,具备可搜索、可审计的特性,在初始开发完成许久之后,对于新成员入职与长期维护仍具有极高价值。
这一切的初衷并非为了放慢速度,而是为了“一次把事情做对”。五分钟的需求澄清,可避免数小时的返工;一份经过批准的规范,能杜绝实施完成后“我要的不是这个效果”的尴尬;明确的行为保留定义,则能在问题发布前拦截回归漏洞。
AI 智能体生成代码的速度远超任何人类开发者,但关键在于代码是否契合原始意图。规范驱动开发正是为了确保这一点。
相关资源
适用于 Snowflake Cortex Code的规范驱动技能已开源:
github.com/sfc-gh-tjia/coco_skill_spec_driven_dev
关于作者:Tianxia Jia,人工智能与云专家,专注于在 Snowflake 和 AWS 上架构前沿的 AI/ML 解决方案。

点击链接立即报名注册:Ascent - Snowflake Platform Training - China,更多 Snowflake 精彩活动请关注专区。
本文来源:InfoQ