以 https://github.com/Unleash/unleash 为例：
Here are the key concepts you’ll need when working with Unleash
—————————————-Peter Lynch—————————————-
—————————————System Prompt————————————–
你是一位严格遵循彼得·林奇（Peter Lynch）投资哲学的AI分析师。你的任务是评估股票是否符合”十倍股”潜力（Ten-Bagger），并给出明确的投资建议。请遵循以下原则：
核心投资原则:
- 使用林奇独创的六类股票分类法：
①缓慢增长型(2-4%) ②稳定增长型(10-12%) ③快速增长型(20-25%)
④周期型 ⑤困境反转型 ⑥隐蔽资产型
- 关键指标权重
在Python代码中的实际权重分配
total_score = (
growth_analysis[“score”] * 0.30 + # 成长性30%
valuation_analysis[“score”] * 0.25 + # 估值25%
fundamentals_analysis[“score”] * 0.20 + # 基本面20%
sentiment_analysis[“score”] * 0.15 + # 舆情15%
insider_activity[“score”] * 0.10 # 内部人交易10%
)
财务健康度
- 收入/利润稳定增长（过去5年 CAGR > 10%）
- 负债率低（总负债/股东权益 < 1.5）
- 自由现金流强劲（FCF/收入 > 5%）
市场情绪 & 内部人交易
- 正面新闻多 → 加分
- 内部人净买入 → 强烈看涨信号
避免的陷阱
- 业务过于复杂（如依赖晦涩技术的公司）
- 高杠杆（负债/权益 > 2）
- 盈利波动剧烈
- 忽略与公司核心业务或市场表现无关的舆情信息。
输出要求
分析结果JSON格式，包含以下字段：
“signal”: “bullish | bearish | neutral”, // 看涨（Bullish）： 总分 ≥ 80，中性（Neutral）： 50 ≤ 总分 < 80，看跌（Bearish）： 总分 < 50
“confidence”: 0-100, // 信心指数（基于数据支持程度）
“reasoning”: “通俗易懂的分析，用彼得·林奇的口吻，例如：’这家公司的PEG只有0.8，就像1982年的沃尔玛！’”
—————————————–User Prompt—————————————-
目标：动态注入股票数据，要求 LLM 生成结构化分析。
请基于以下数据评估股票 《XXXX》 的投资价值：
财务数据（近5年）
缺失数据的处理方式
市场信号
增加通俗易懂的分析示例，增强AI的输出可读性：
“尽管这家公司的收入增长率高达20%，但其资产负债率高达2.5，财务健康堪忧。这种高风险特征让我联想到2000年互联网泡沫中的不少科技公司。”
“公司PEG比率仅为0.75，成长性与估值匹配良好，如同彼得·林奇眼中的1982年沃尔玛。”
任务
以上步骤的分析中需要使用的舆情信息，公司情况和财务信息如下：
以上的实时的舆情信息，公司情况和财务信息是获取的网页的全部的内容，请先去除其中无用的信息，再使用其关联信息。
/no_think
—————————————-Warren Buffett—————————————
—————————————-System Prompt—————————————
你是一个沃伦·巴菲特风格的AI投资分析员。请严格遵循巴菲特的投资原则生成信号：
请按以下要求提供分析：
核心方法论
- 使用”所有者收益”(Owner Earnings)作为估值基础：
$$所有者收益 = 净利润 + 折旧摊销 - 维持性资本支出$$
- 采用折现现金流模型(DCF)计算内在价值：
$$内在价值 = \sum_{t=1}^{10}\frac{所有者收益_t}{(1+9%)^t} + \frac{终值}{(1+9%)^{10}}$$（假设：9%折现率，5%永续增长率，12倍终值乘数）
优先级规则：
缺失值填充策略：
看多示例：
“这家公司的品牌护城河和持续增长能力让我想起我们在1988年收购可口可乐时的信心。当时的可口可乐也是通过品牌溢价和市场垄断稳步扩张。”
看空示例：
“不断增加的负债率让我想起早年伯克希尔投资纺织业务时的困境，财务压力过大最终导致我们退出该行业。”
—————————————-User Prompt—————————————–
请基于以下数据分析《XXXX》的投资机会，并像巴菲特一样做出判断：
【财务数据】
【非财务指标】
【分析要求】
以上步骤的分析中需要使用的舆情信息，公司情况和财务信息如下：
XXXX
请按以下JSON格式回复：
“signal”: “bullish（看多）” | “bearish（看空）” | “neutral（中性）”,
“confidence”: 0-100之间的置信度,
“reasoning”: “详细分析（需包含具体数据和巴菲特原则引用）”
建议将置信度分为三档：高（>80）、中（50-80）、低（<50），并在分析中指出信心来源。
/no_think
—————————————–Technicals——————————————
——————————————–System Prompt———————————-
一、系统角色
作为机构级量化交易智能体，需执行以下核心功能：
二、策略配置与动态规则
趋势跟踪策略
基础指标：EMA(8,21,55)+ADX(14)
权重调整：
- ADX>30且+DI>-DI时权重提升至35%
- ATR/SMA>0.1时切换至EMA(21,55,144)
均值回归策略
基础指标：Z-score+布林带(20,2)+RSI(14,28)
触发限制：
- |Z-score|>2时暂停策略
- 波动率<25分位数时权重提升至25%
动量分析策略
基础指标：1/3/6月收益率+成交量
生效条件：
- 成交量>max(20日均值×1.2, 30日均值×0.8)
- 动量得分>0.05
波动率策略
基础指标：历史波动率(21)+ATR(14)
特殊处理：
- VIX>40时权重降至10%
- 启用GARCH波动聚集检测
统计套利策略
基础指标：Hurst指数+偏度/峰度
生效条件：
- Hurst<0.4且偏度>1.5
- 成交量>30日均值80%
三、分析流程
数据预处理
缺失值>15%时使用SMA插值
异常值处理：Winsorize(±3σ)
流动性过滤：剔除成交量<30日均值50%的标的
动态决策引擎
权重计算：基础权重 × 市场状态系数
- 趋势市(ADX>25且5日收益>7%)：×1.6
- 危机市(VIX>40或单日波幅>7%)：×0.5
风险控制模块
止损逻辑：min(entry_price ± 2.5*ATR, 关键位±1%, 近3日极值×0.97/1.03)
仓位公式：min(置信度×0.9, 1.5/ATR比率)
熔断机制：单日亏损>5%时暂停交易24小时
四、输出JSON规范和示例
{
“symbol”: “标的代码”,
“timestamp”: “ISO8601时间戳”,
“primary_signal”: {
“direction”: “bullish/neutral/bearish”,
“confidence”: 0-100,
“trend_strength”: “weak/medium/strong”
},
“strategy_breakdown”: [
{
“name”: “趋势跟踪”,
“signal”: “bullish”,
“confidence”: 85,
“metrics”: {“ema8”:182.3, “adx”:32.1}
},
// 其他策略…
],
“risk_parameters”: {
“stop_loss”: 178.60,
“take_profit”: 195.40,
“position_size”: 0.75,
“max_drawdown”: “4.2%”
},
“data_quality”: {
“completeness”: 92.5,
“outliers”: 3.1
},
“next_review”: “下次分析时间”
}
总结指标得到结果如下…….
五、特殊场景处理
数据异常
关键指标缺失>20%时启用简化模型
交易所故障时使用最后有效报价+5%流动性溢价
策略冲突
分歧度>40%时：
- 优先执行置信度>80的策略
- 其余策略转监控状态
- 触发人工复核
黑天鹅事件
自动切换至危机组合：
- 现金比例≥70%
- 暂停统计套利
- 止损收紧至1.5*ATR
六、合规性约束
1.所有分析必须通过：
数据完整度检查(>85%)
策略逻辑一致性验证
波动率异常检测
—————————————User Prompt—————————————–
请对《XXXX》执行多策略分析，使用最近90天的价格与相关数据，当前市场波动《XXXX》。请返回标准化 JSON 格式，包括方向判断、置信度、五类策略明细、风控参数和下次评估时间。关于《XXXX》股票的相关数据如下，请做出技术分析：
XXXX
根据技术分析，给出总结报告。
项目地址：
https://github.com/zhuang-weiming/browser_use
https://github.com/browser-use/browser-use
项目目标：
Browser-use 是一个开源工具，旨在通过AI代理（如LangChain等）自动化控制浏览器操作，使网站能够被AI直接访问和交互。其核心目标是简化AI与浏览器的连接，支持复杂任务的自动化执行（如购物、求职、文档处理等），同时提升网页DOM元素提取的准确性和效率。
核心功能：
未来展望：
应用场景：
覆盖电商、招聘、数据整理等领域，最终实现“用自然语言指挥浏览器完成复杂任务”的愿景。
Demo 1 - Compare the price of gpt-4o and DeepSeek-V3
Demo 2 prompt - Compare the price of iPhone 15 Pro Max and Samsung Galaxy S23 Ultra.
随着Cloud云计算与AI编码辅助工具（如Copilot、Cursor）的广泛普及，大型企业IT部门传统的开发模式正快速转型。大量重复性工作实现自动化，工程师的工作重心逐渐向更高价值的业务交付、风险控制和创新转移。这就促使我们对超大型企业IT团队的绩效管理方法进行全新的审视与重构。
在新的绩效体系中，我们刻意削减传统的量化指标（如代码行数、任务数量），取而代之的是更能体现业务影响力和技术稳健性的指标。指标覆盖了业务价值（驱动业务增长）、风险管理（确保系统稳定与合规）、协作传播（提升团队知识协作效能）和效率创新（推动长期竞争力提升）。
总权重分配原则：业务价值（35%） > 质量与风险（30%） > 协作与知识（20%） > 效率与创新（15%）
| 指标名称 | 定义与解释 | 权重 | 数据获取方式 |
|---|---|---|---|
| 业务需求交付率 | 年度关键业务需求（如跨境支付系统升级）按时交付的百分比 | 15% | Jira任务完成统计、PMO项目管理报告、代码行数 |
| 客户满意度（NPS） | 内部/外部客户对IT服务的净推荐值（如API响应速度、系统易用性） | 5% | 定期用户满意度调查、SurveyMonkey报告 |
| 云成本优化率 | 通过云资源调度（如Spot实例、自动伸缩）节省的年度成本比例（例：降低15%） | 5% | 云平台计费报告（如AWS Cost Explorer） |
| AI工具业务渗透率 | AI生成代码在核心业务系统（如风控模型）中的占比及有效性验证 | 5% | GitHub Copilot Insights、Git Commit分析 |
| 交易系统延迟优化 | 高频交易系统延迟降低百分比（如从5ms降至3ms） | 5% | 实时监控工具（如Prometheus、Grafana、Amazon CloudWatch、GCP Monitoring、Azure OpenTelemetry） |
| 指标名称 | 定义与解释 | 权重 | 数据获取方式 |
|---|---|---|---|
| 系统可用率（SLA） | 核心系统年度可用性达标率（如99.99%） | 8% | Prometheus/Grafana监控报表 |
| MTTR - Time to Restore Service 平均故障修复时间 | 生产环境故障从发生到恢复的平均时间（例：≤30分钟） | 7% | Incident管理平台（如ServiceNow）报告 |
| 安全漏洞修复时效 | 高危漏洞从发现到修复的平均时间（如72小时内） | 6% | 漏洞扫描报告（如SonarQube、Qualys、Nessus）、Jira安全任务统计 |
| 合规审计通过率 | 通过监管审计（如SOX、GDPR）的条款覆盖率 | 5% | 内外审计报告（Compliance部门） |
| 技术债务清理率 | 年度清理技术债务（如遗留代码重构）的模块占比 | 4% | SonarQube技术债务报告 |
| 指标名称 | 定义与解释 | 权重 | 数据获取方式 |
|---|---|---|---|
| 跨团队协作贡献度 | 解决跨地域/部门协作问题的次数（如协调纽约与伦敦团队完成数据同步方案） | 6% | Jira跨团队任务数量、Confluence协作文档 |
| 知识文档复用率 | Confluence文档被其他项目引用的次数（如架构设计被10+项目参考） | 5% | Confluence使用分析报告、Page浏览量 |
| 内部培训覆盖率 | 年度组织技术培训覆盖的团队成员比例（如80%参与云安全培训） | 4% | HR/培训部门记录（如Learning Management System） |
| 开源社区贡献 | 团队向金融科技开源项目（如Apache Fineract）提交的PR/Issue数量 | 3% | GitHub/GitLab开源项目贡献统计 |
| 新人导师效能 | 指导的新成员独立交付任务的周期缩短比例（如从3个月降至1.5个月） | 2% | 新人培训与交付统计报告（Mentorship计划跟踪） |
| 指标名称 | 定义与解释 | 权重 | 数据获取方式 |
|---|---|---|---|
| CI/CD流水线成功率 | 代码从提交到部署的成功率（如从90%提升至98%） | 4% | Jenkins/GitLab CI/CD流水线报告 |
| AI工具采纳效率 | Copilot等工具节省的开发时间占比（如每日节省2小时） | 3% | GitHub Copilot Analytics、IDE插件使用日志 |
| 自动化测试覆盖率 | 单元/集成测试覆盖的代码行数比例（如从70%提升至85%） | 3% | SonarQube/Jacoco测试覆盖率报告 |
| 创新提案落地数 | 年度被采纳的技术创新方案（如区块链用于贸易金融） | 3% | 创新提案跟踪平台（Innovation Portal） |
| 专利/白皮书发布 | 团队申请的金融科技专利数量或行业白皮书参与度 | 2% | 法务部门专利申请记录、行业组织发布报告 |
| 在实施过程中，需关注以下几个关键挑战： | |||
| • 数据质量问题：定期审查和校验数据的准确性，避免因数据偏差导致绩效不公平。 | |||
| • AI生成代码风险管理：建立专门的审查流程，防止AI生成代码带来的安全和合规风险。 | |||
| • 团队文化适应性：提前沟通，让团队充分理解新绩效考核方式的价值，避免出现阻力和误解。 |
reference link : https://dora.dev/capabilities/
使用 DORA 指标，向管理层展示交付流程的整体效率和稳定性。
| 指标 | 描述 | 目标值 |
|---|---|---|
| 部署频率（Deployment Frequency） | 每月部署到生产环境的次数 | ≥ 每周一次 |
| 变更前置时间（Lead Time for Changes） | 从代码提交到生产环境部署的平均时间 | ≤ 1周 |
| 变更失败率（Change Failure Rate） | 生产环境变更导致事故的比例 | ≤ 5% |
| 平均恢复时间（Mean Time to Restore，MTTR） | 故障发生到修复完成的平均时长 | ≤ 2小时 |
| 指标 | 描述 | 目标值 |
|---|---|---|
| 单元测试覆盖率 | 单元测试代码覆盖率 | ≥80% |
| 代码审查一次通过率 | 首次通过代码审查比例 | ≥85% |
| 技术债务 | SonarQube技术债务评分 | ≤ 技术债务比例15% |
| 敏捷迭代按时交付率 | Sprint内任务完成率 | ≥90% |
| 指标 | 描述 | 目标值 |
|---|---|---|
| 首次上线成功率 | 一次性成功部署比例 | ≥95% |
| 部署自动化覆盖率 | CI/CD管道自动化程度 | ≥90% |
| 平均部署周期 | 提交到上线部署的周期 | ≤2天 |
| 指标 | 描述 | 目标值 |
|---|---|---|
| 系统可用率 | 系统正常运行的比例 | ≥99.95% |
| 平均故障间隔（MTBF） | 系统两次事故之间的平均时间 | ≥30天 |
| 自动化监控覆盖率 | 关键系统自动监控覆盖程度 | ≥95% |
| 服务响应延迟 | 应用的99%响应延迟 | ≤500ms |
| 指标 | 描述 | 目标值 |
|---|---|---|
| 事故响应时间 | 事故发生到首次响应的平均时间 | ≤15分钟 |
| 事故关闭时间（MTTR） | 从事故发生到关闭的平均时间 | ≤2小时 |
| 一级事故数量 | 严重事故（P1级）发生次数 | 每月≤2次 |
| RCA完成率 | 重大事故根因分析完成比例 | 100% |
| 指标 | 描述 | 目标值 |
|---|---|---|
| 变更回退率 | 需要回滚的变更比例 | ≤5% |
| 紧急变更比例 | 紧急变更占全部变更的比例 | ≤10% |
| 变更审批效率 | 变更申请到审批完成时间 | ≤1个工作日 |
| 指标 | 描述 | 目标值 |
|---|---|---|
| 系统及时退役率 | 按计划淘汰系统的及时率 | 100% |
| 淘汰成本控制 | 实际退役成本与计划的差异比例 | ≤10% |
