从提示词到工程化：FDE方法实战打造股票分析智能体-CSDN博客

最近一位从零开始做 AI 应用的朋友 上来就问了我一个很典型的问题 “我想做一个股票分析智能体 第一步是不是得先写一个很厉害的 prompt ”

我的回答可能不太符合他的预期 如果一件事需要靠“很厉害的 prompt”才能成立 那往往说明需求还没被拆透。

把“股票分析智能体”当成一个提示词工程来做 确实很快就能跑通演示 调用大模型接口 喂一段行情数据 让它输出“值得关注”或者“保持谨慎”的判断。但如果你想让它稳定地覆盖多个标的和周期 定期跑一遍 把结果沉淀成结构化表格 并且在数据源异常时能自动告诉你哪一步断了 那么它就从提示词技巧变成了一个部署问题。

这个转变 正好对应了 FDE——前沿部署工程师 Front Deployment Engineer 目前在做的事 也对应了 Agent 真正落地时最容易被低估的三个环节 需求拆解、文档先验、评测驱动。

这篇文章我会用“打造股票分析智能体”这个实战项目 把 FDE 的核心工作方式拆开讲一遍。它不是一篇只教你怎样发 API 请求的教程 而是想说明一个更底层的判断 Agent 开发真正的难点不在生成代码 而在把模糊需求变成可评估、可迭代、可交付的工作流。

1. 表面是“写智能体” 实际上是“把模糊想法变成链路”

很多人对 Agent 开发的第一个误解 是把它等同于提示词工程。前几年大家说“大模型的能力取决于 prompt” 这句话到现在还没完全过时 但它过度简化了工程问题。

1.1 一个典型误判 以为难度在模型能力

想做一个股票分析智能体 最常见的起步方式是这样的 找一个大模型 API 写一段“你是资深股票分析师”的提示词 把最近一个月的数据贴进去 让模型输出分析结论。第一次跑通之后 你觉得项目已经完成 80% 了。

但真实情况往往是这样

数据从哪来 天天手动下载 Excel 吗

行情数据如果有缺失 模型还接着分析怎么办

模型把“过去三年最大回撤”理解错 算出来的数字明显不合理 怎么发现

输出是一大段文字 后面要汇总几百只股票 没法用表格比较 怎么办

某个数据源突然改了字段格式 整个流程崩掉 怎么定位

这些问题没有一个是 prompt 能解决的。它们属于数据链路、边界条件、异常处理和输出契约。也就是说 难度根本不在模型能力 而在工程化。

1.2 项目真正复杂的三个区域

一个股票分析智能体 按 FDE 视角来看 至少要拆成三个不重叠的区域

区域

典型问题

主要依赖

输入工程

行情数据获取、清洗、缓存、字段校验

数据源 API、本地文件、异常处理

决策工程

技术指标计算、结论生成、风险提示

计算库、LLM 推理、提示词模板

输出工程

报告结构化、存储、审计、通知

JSON 约束、数据库、定时任务

这还只是最简版本。如果把数据源换成多市场、多周期、多资产类别 复杂度还会成倍上升。

1.3 分清“体验驱动”和“部署驱动”

我认为 “股票分析智能体”这个项目可以分成两种做法

体验驱动

目标是让模型输出一段看起来专业的话。适合验证大模型效果 适合作为学习 demo。

部署驱动

目标是让这个流程可以重复跑、可以监控、可以复盘、可以迭代。适合真正进入工作流。

FDE 的价值恰恰在第二种。前沿部署工程师不是“会用大模型的人” 而是“能判断哪些环节适合用模型、哪些环节应该用规则 并且能把整个流程稳定部署出来”的人。

所以在写第一行代码之前 我们先得把“想要什么”翻译成“每一环需要什么”。这就是需求拆解。

2. 需求拆解 先画链路 再写代码

我见过不少 Agent 项目做到一半卡住 原因都差不多 需求没有拆到底 等于是在给一个模糊目标写代码。代码生成得再快 也弥补不了目标的模糊。

2.1 从输入边界开始拆

股票分析智能体的第一件事 不是写模型调用 而是定义输入。

一个完整的输入边界至少包括

标的范围 是一支股票 还是一个指数 还是几十个股票的组合

时间周期 日线、周线、还是小时线

历史区间 最近一个月、三个月 还是一年

数据字段 需要开高低收、成交量、换手率 还是还要财务数据

更新频率 实时、每日收盘后、还是每周手动跑一次

这一步看起来机械 但它决定后面所有环节的复杂度。比如 如果只分析日线 那数据量不大 单次请求就能处理 如果要分析分钟级数据 就必须考虑截断、采样和大模型上下文长度。

2.2 拆任务 找出哪些环节属于 LLM 哪些属于代码

很多 Agent 项目失败 不是因为 LLM 不够聪明 而是把不该交给 LLM 的事也丢给了 LLM。

在股票分析这个场景里 更适合用代码/规则完成的部分

拉取行情数据

检查数据完整性 是否有空值、停牌日、数据缺失

计算技术指标均线、RSI、MACD、波动率等

格式化数字 保留两位小数、百分比、时间格式

更适合用 LLM 完成的部分

把指标结果翻译成自然语言结论

给出多空逻辑的初步解读

综合多个信号后 生成风险提示和前因后果的解释

核心原则 凡是能用确定逻辑实现的 就不要让模型自由发挥。模型负责表达和判断演推 代码负责数据和规则。

2.3 拆输出 定义结果契约

输出没有契约 后续根本没法自动化。

一个可用的输出结构可以是 JSON

symbol : 000001 ,

trade_date : 2025-06-10 ,

indicators : {

ma5 : 10.25,

ma20 : 9.87,

rsi14 : 62.3,

macd_hist : 0.12

},

duration : 近一个月 ,

signal : 谨慎偏多 ,

risk_note : 股价处于上升通道 但成交量没有明显放大 注意回撤风险。 ,

confidence : 0.65

这份 JSON 就是“输出契约”。它至少带来三个好处

后续可以批量汇总成表格。

可以给每个字段写校验规则。

它可以作为评测清单的预期结构。

2.4 用一句主问题检验拆解结果

拆完需求后 用一句主问题来检验 如果现在项目中断一周 回来以后能不能凭文档继续推进

如果答案是不确定 说明需求没有拆到位。拆解的目标是让下一阶段的文档和开发不需要再去做大量判断 而是照着清单执行。

3. 文档先行 不是形式主义

FDE 方法论里有一个很容易被忽略的环节 写文档。

很多人觉得文档是水字数 是给甲方看的 写代码才是真章。但在 Agent 开发里 文档的作用不是“记录” 而是“定标”。文档是在给后面所有代码和评测行为划定边界。

3.1 没有文档 LLM 就只能猜

当你用 Vibe-Coding 方式让 AI 帮忙生成代码时 AI 最需要的不是一句“帮我写一个股票分析程序” 而是明确的目标、输入、输出和约束。这些信息如果没有写下来 模型就只能根据它的训练数据泛泛而写 然后你只能在错误道路上反复修改。

所以文档不是给读者看的 是给 AI 和未来的你同时看的。

3.2 一个最小文档集合

对股票分析智能体来说 建议至少有三份文档

文档

主要内容

作用

README.md

项目目标、运行前提、环境变量、快速开始

让任何人能跑起来

SPEC.md

输入边界、任务链路、输出契约、模块划分

让代码有结构依据

EVAL.md

评测用例、通过标准、失败处理方式

让迭代有方向

不用写得像正式技术方案那么重 但核心信息必须有。

3.3 SPEC.md 怎么写才不空

SPEC.md 不需要写“我们要打造一个”这类空话 它应该直接回答几个问题

每天跑还是每周跑

支持哪些标的

数据缺失时是跳过还是报错

结果存到本地 CSV 还是数据库

哪些字段是必须的 哪些是可选增强

LLM 超时或者返回非 JSON 时怎么处理

这些写清楚之后 代码结构其实已经出来了。文档先行的价值正在于此 结构先于代码出现 代码只是把结构落下来。

3.4 EVAL.md 怎么写才不虚

EVAL.md 是评测驱动开发的核心文件。它的作用是在写完整代码之前 先写出“怎么算通过”。

对股票分析智能体 可以预设这些评测点

输入合法股票代码 能返回结构化 JSON。

输入不存在的代码 返回可理解的错误说明。

行情接口返回空数据时 不产生“看起来正常”的错误结论。

RSI 等指标计算和通用库结果一致。

模型输出中不出现数据里没有的价格数字。

这些评测点不需要一开始就完整 但先写 10 个 比后期补 50 个要有效得多。

4. Vibe-Coding 让 AI 帮你写 Agent 的正确姿势

Vibe-Coding 这两年已经成为 Agent 开发讨论里的高频词。它描述的是“通过自然语言描述意图 由大模型生成代码 人类负责判断、修正和验证”的协作模式。

这个词听起来很轻松 仿佛只要找到感觉 程序就能自动写出来。但在 FDE 实战里 Vibe-Coding 要落地 前提是前面两步完成得足够扎实。

4.1 写一份“项目背景说明”作为上下文

开始让 AI 写代码之前 先给它一份背景说明。它可以是 SPEC.md 的提炼版 也可以是随对话首次发送的提示词

我想开发一个股票分析智能体 目标是每天收盘后分析一组股票的技术指标 并生成结构化报告。项目使用 Python。

输入 股票代码列表 周期为日线。

数据来源 行情 API 需要处理空值和停牌日。

输出 JSON 文件 结构见 SPEC.md。

当前阶段 先写一个最小可运行版本 支持单只股票分析。

约束 不预测未来 不建议买卖 只做技术指标解读和风险提示。

这段描述不长 但它把最重要的事情都定死了 目标、输入、数据源、输出、当前阶段、约束。模型生成的代码会更贴合项目需要。

4.2 最小可跑流程 先打通一条线 再横向扩充

我建议的节奏是

先让 AI 生成一个单股票版本 只跑一只股票 输出一个 JSON 文件。

手动检查 JSON 字段是否符合契约。

加入指标计算 验证数字是否正确。

接入 LLM 把指标结果转成自然语言结论。

最后再扩展成多股票循环和定时任务。

不要一上来就让它“生成一个完整的支持美股 A 股港股、自动定时发送邮件的股票分析系统”。这类提示词生成的代码 表面功能很多 但每一处边界都没有认真处理 最后返工成本非常高。

4.3 一个适合初学的模块切分

推荐把项目切成五个模块 每个模块独立验证

stock_analyzer/

├── config.py # 配置项 标的列表、时间周期、输出路径

├── data_loader.py # 行情数据获取和清洗

├── indicators.py # 技术指标计算

├── llm_analyzer.py # 调用大模型生成自然语言结论

├── report_builder.py # 汇总结果 输出 JSON/CSV

└── main.py # 执行入口 串联流程

这个结构既不复杂 又足够把数据、计算、模型、输出隔离开来。用 Vibe-Coding 时 建议让 AI 一个模块一个模块地生成 每生成一个模块就运行一次 确认没有明显问题再继续。

4.4 Vibe-Coding 最常见的三个坑

坑一 一次性生成完整项目。

模型一次生成的代码量越多 出错的概率越高 而且出错后不好定位。

坑二 不检查数据源返回结构。

股票数据 API 的字段经常变化 如果你不先打印一次返回结果 指标计算就会在字段名上踩坑。建议让 AI 在数据加载后打一行日志 写明数据量、字段名、时间范围。

坑三 把真实行情和分析结论混在一起测。

第一次调试时 不要直接用几十只真实股票跑完全流程。应先准备一两条样例数据 确认逻辑调试完毕 再切换真实数据源。

记住 Vibe-Coding 的关键不在于“让 AI 写出完美代码” 而在于你有一个清晰的验收标准 让 AI 的代码能一次次靠近这个标准。

5. 评测驱动 从“感觉还行”到“可验收”

很多 Agent 项目停在“感觉还行”的阶段。所谓感觉还行 就是你手动跑了几次 觉得输出看起来合理 然后就说这块完成了。

但在 FDE 的视角里 这不算完成 只能算“未见明显异常”。真正可验收的标准 是有一组预先定义的评测用例 每次改动后都能跑一遍 并且依据结果决定是否通过。

5.1 为什么评测一定要前置

评测前置的意思是 在写完整代码之前 先把“怎么算通过”写下来。

否则会发生一个很经典的场面 代码写完了 你看着输出 觉得“这里好像不太对” 但又说不出标准是什么 于是开始凭感觉调整 prompt 调完继续看 继续凭感觉。

评测前置后 改动的目标会非常清晰 不是“让输出更专业” 而是“让 RSI 数值和基准库一致”“让 JSON 里包含 trade_date 字段”“让空数据时不产生结论”。

5.2 评测清单示例

对股票分析智能体 评测可以分成三个类型

类型

评测用例

通过标准

数据链路

输入不存在的股票代码

返回明确错误 不生成分析报告

数据链路

行情返回全空值

提示数据为空 不生成正常结论

指标计算

输入已知行情序列

ma5

等指标与标准结果误差小于 0.01

输出结构

单股分析结果

输出为合法 JSON 且包含

symbol

indicators

signal

模型判断

模型输出中的价格

不能出现输入数据中不存在的最高价/最低价

稳定性

连续运行 10 次

每次输出都是合法 JSON 且字段一致

这套评测不需要一次写全 但它必须优先覆盖最容易出错的环节 数据缺失、字段缺失、数字虚构。

5.3 评测驱动的迭代闭环

评测驱动开发的核心闭环是

写一个评测用例。

运行 Agent 记录失败表现。

分析是哪一层造成失败 数据层、计算层、还是模型层。

定向修复 改数据清洗、改指标计算、改提示词、改输出解析。

重新运行评测 直到通过。

添加新的评测用例 重复循环。

这个循环跑几次之后 你会明显感觉项目的边界在收紧。以前是“模型输出一堆话 我看着都挺对” 后来变成“每个字段都有验证 每条错误都有路径”。这就是 FDE 和普通演示脚本最大的区别。

5.4 边界 评测不等于金融分析准确率

这里需要特别说明 评测驱动的目标是“系统行为稳定可控” 不是“预测股票准确率高”。

股票分析智能体的核心价值是把数据、指标、模型判断组织成一份结构清晰、可审计、可复现的报告 而不是替你预测涨停 更不是给你必胜建议。因此 EVAL.md 里不应该写“预测准确率达到 80%” 而应该写“输出真实反映了输入数据”和“指标体系计算正确”。如果你的目标真的是预测股价走势 那已经不是 Agent 开发问题 而是一个严格的量化研究问题 需要的实验方法、数据质量和风控逻辑完全超出本文范围。

6. 从演示原型到长期可用的工作流 部署与边界

当前面五步走完 你手里应该有一个能在命令行里跑通的项目

python main.py --symbol 000001 --days 30

它能够在终端输出一份包含技术指标和大模型解读的 JSON。到这里 演示原型已经完成。

但“演示原型”和“长期可用”之间 还差几个工程能力。

6.1 日志、重试和缓存

首先 日志。Agent 项目里最怕的不是报错 而是“跑了一次 不知道中间发生了哪些调用”。建议每个关键环节都保留一条日志

数据获取成功 共拉取 26 条日线记录 时间范围从哪天到哪天。

指标计算完成 RSI 62.3 MACD 柱 0.12。

LLM 调用成功 耗时 3.2 秒 输出 token 数 420。

报告已写入指定路径。

其次 重试。行情 API 偶尔失败是正常的 可以在抓取函数里写一个简单的重试机制

def fetch_with_retry(fetch_func, retries 3, wait_seconds 2):

for attempt in range(retries):

try:

return fetch_func()

except Exception as e:

if attempt retries - 1:

raise

time.sleep(wait_seconds)

再次 缓存。如果每天收盘后运行一次 其实同一个标的同一天的数据只需要拉一次。缓存到本地目录 既能加快调试速度 也能减少对数据源的依赖。

6.2 定时运行和结果沉淀

确认单次运行没问题后 再考虑定时运行。最简单的方式是 cron

# 每个交易日 16:30 运行分析

30 16 * * 1-5 cd /path/to/stock_analyzer && python main.py --symbols config/symbols.txt

定时任务不是必须的 但它能帮你想清楚一个问题 当流程不需要人盯的时候 你是不是真的信任每一个异常都能被捕获 如果答案是否定的 说明还有一些边界情况没在评测里覆盖。

6.3 FDE 的长期价值 从“写脚本”到“沉淀流程”

到这里 我们就能回答文章开头那个问题了。

FDE 不是一门新的编程语言 也不是一个可考取的证书 它是一套面向 AI 应用落地的工作方式。它的核心动作是

把模糊需求拆成输入、处理、输出、验证四个环节。

把关键决策写成文档 让 AI 在约束范围内生成代码。

把验收标准前置成评测清单 让每次改动都有方向。

把单次脚本沉淀成可复用、可定时、可监控的流程。

当你用这套方式去做股票分析智能体的时候 你真正得到的不是一个“会输出股评”的玩具 而是一个“少有人盯着也能照常跑、出了问题你能快速定位”的工具。这个转变 才是 Agent 开发从兴趣走向工作的分水岭。

如果只看一个建议 我会说 从明天开始 不要先写提示词 也不要先从网上复制代码 而是先写下你的输入边界、输出契约、十条评测用例 让后面的代码和模型调用都围绕这些约束去生成和迭代。你会发现 真正让 Agent 变可靠的 不是“更聪明的模型” 而是你为它划定边界的方式。