Zhuang's Diary

言之有物，持之以恒

Posted on Edited on

涵盖五种Feature Flag类型的多维度差异分析：

​维度​ ​Release Flags​ ​Experiment Flags​ ​Kill Switches​ ​Operational Flags​ ​Permission Flags​
​目的​ 渐进发布新功能，降低风险 A/B测试或多变量实验 紧急关闭故障功能 技术实现切换（如库升级） 基于角色/权限控制功能访问
​触发条件​ 用户百分比/环境配置 用户分桶规则（如用户ID、地理位置） 系统故障告警或人工干预 技术指标阈值（如性能基线） 用户属性（如订阅等级、内部权限）
​生效速度​ 分钟级（依赖缓存/配置刷新） 秒级（动态分桶） ​毫秒级​（最高优先级） 秒级（自动/手动切换） 秒级（实时权限校验）
​影响范围​ 特定用户群或环境 实验组用户 ​全局功能​ 局部技术组件 特定用户角色
​操作角色​ 产品负责人 / 开发者 数据分析师/产品经理 SRE/高层决策者 运维/SRE 管理员/安全团队
​依赖系统​ CI/CD流水线+功能开关平台 数据分析平台（Amplitude / Mixpanel 等工具）+用户分桶服务 告警系统+手动触发机制 监控系统+配置中心 IAM系统或用户数据库
​预期生命周期​ ​​≤40天​（短期功能验证） ​​≤40天​（实验周期） ​永久​（长期应急） ​​≤7天​（技术过渡期） ​永久或动态​（按业务需求）
​代码侵入性​ 中（可通过抽象接口/策略模式缓解） 高（需支持多变量逻辑） 低（简单布尔开关） 中（需兼容新旧实现） 高（需集成权限逻辑）
​典型使用场景​ 新购物车UI的渐进发布 登录页按钮颜色的转化率测试 支付系统故障时降级 数据库驱动版本迁移 仅向VIP用户开放高级功能
​数据要求​ 基础使用量统计 ​详细事件跟踪+统计分析​ 系统健康度监控 技术指标日志（如延迟、错误率） 用户属性实时查询
​风险等级​ 中（可能影响用户体验） 低（可控实验范围） ​高​（直接影响业务） 中（技术风险） 低（权限错误可能导致功能泄露）
​清理优先级​ 高（避免技术债务） 中（实验结束即清理） 不适用 ​最高​（影响性能 / 代码稳定性，需快速清理） 低（长期存在）

补充说明

  1. ​生命周期管理​
    • Release/Experiment flags会标记为Potentially Stale超期后，需定期审查
    • Kill switches和Permission flags支持永久存活，但需定期测试有效性
  2. ​依赖关系​
    • Experiment flags可能依赖Parent Flag实现分层实验
    • Permission flags通常与(AWS)IAM系统深度集成​
  3. ​高级控制​
    • Release flags支持渐进式Rollout​
    • Operational flags推荐与Canary发布结合使用
  4. ​安全合规​
    • Kill switches需独立于主系统的触发机制
    • Permission flags需支持审计日志​

深入分析Operational Flag示例

双保险机制​：

  1. Canary控制业务流量分配​（哪些用户的请求进入新流程）
  2. Operational Flag控制技术实现路由​（实际访问新DB还是旧DB）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 银行支付路由伪代码
def process_payment(request):
    # Canary控制：5%流量进入新系统
    if canary.is_selected(request.user_id):
        
        # Operational Flag控制：新系统是否真正处理
        if operational_flag.is_enabled("new_payment_engine"):
            result = new_engine.process(request)
            
            # 影子流量比对
            old_result = old_engine.process(request)
            - compare_results(result, old_result)
            
            return result
        else:
            return old_engine.process(request)  # 仅流量路由，不实际处理
    
    # 非Canary流量
    return old_engine.process(request)

Unleash双策略配置​:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "features": [
    {
      "name": "new_payment_engine",
      "strategies": [
        {
          "name": "gradualRollout",
          "parameters": {
            "rollout": 100,  // 完全开启后才会生效
            "stickiness": "serviceLoad", // "userId", "sessionId", "random"
            "groupId": "low_traffic_window"  // 仅系统负载<40%时生效
          }
        }
      ]
    }
  ]
}

银行级最佳实践

  • ​分层验证​：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
```text
Phase 1 - Canary发布 (1%流量):
  │
  ├── Operational Flag OFF → 仅收集基础设施指标,如 CPU Load / Latency
  │
  └── Operational Flag ON → 全功能验证

Phase 2 - 渐进式Rollout (10% → 50% → 100%):
  │
  ├── 按客户价值分群（VIP优先）
  │
  └── 按地域分步（监管宽松区先行）

Phase 3 - 全量发布:
  ├── 移除Flag或转为永久配置
  └── 清理弃用代码分支
  • 熔断策略​：
    • 当新DB查询延迟>500ms时，基于 Prometheus / NewRelic 等监控告警系统自动触发,自动关闭Operational Flag
    • Canary流量自动降级到旧DB，但不中断服务
  • ​合规审计​：
    • 记录所有Flag切换操作（满足SOX审计）
    • Canary和Operational的决策日志关联到同一TraceID
  • 禁止循环依赖（如FlagA依赖FlagB，FlagB又依赖FlagA）
    • 实际上，任何依赖和关联，都很容易造成feature 发版失败

监控与清理**​

​清理时机判断​：

1
2
3
4
5
6
7
public class FlagCleanupPolicy {
    public boolean shouldCleanup(FeatureFlag flag) {
        return flag.isStale() ||  // 超过预期生命周期
            (flag.getUsageRate() < 0.1% &&  // 低使用率
             flag.getLastModified().olderThan(14, DAYS));
    }
}

​清理步骤​：

  1. 代码中移除Flag条件判断
  2. 删除Unleash控制台配置。可以标记为 deprecated/stale，进行灰度移除
  3. 更新 架构决策记录​(ADR)

软件工程实践

  1. Trunk-Based Development（主干开发）
    是解决 Feature Flag 依赖关系混乱的治本之道，尤其是在银行这类高合规要求的场景下。
  1. ​小批量提交​：每个PR仅包含1个Flag的完整变更集
  2. ​Flag封装​：通过接口隔离实现细节
1
2
3
4
5
6
7
8
9
10
11
// 银行支付系统示例
public interface RiskEngine {
    Result calculateRisk(Transaction tx);
}

// 通过Flag选择实现
public RiskEngine getEngine() {
    return unleash.isEnabled("risk_v2") ? 
        new RiskEngineV2() : 
        new RiskEngineV1();
}
  1. 面向接口编程：降低代码冲突率，明确代码块的责任。本类或者方法的代码变更，不要影响其他类和方法
  2. 依赖关系静态分析​
1
2
❌ 检测到禁止的依赖链:
payment.v3 -> risk.v2 -> data.v1 -> payment.v3
  1. 架构决策记录（ADR）​
1
2
3
4
5
6
7
8
9
10
# ADR-042: 风控系统Flag依赖规范

## 决策
- 所有风控相关Flag必须单向依赖
- 禁止跨业务域Flag耦合

## 执行
    C[支付Flag] --> A
    D[审计Flag] --> A
    A[风控Flag] --> B[数据层Flag]

7. 分层解耦模式​
​代码结构​：

1
2
3
4
5
6
7
8
9
src/
├── features/
│   ├── risk_v2/       # 包含完整特性代码
│   │   ├── RiskEngineV2.java
│   │   └── RiskEngineTest.java
│   └── payment_v3/
└── feature_flags/     # 集中管理所有Flag
    ├── RiskFlags.java # 显式声明依赖关系
    └── PaymentFlags.java
  1. TDD（测试驱动开发）
1
2
3
4
5
6
7
8
9
10
11
12
// 正确做法：通过测试强制解耦
@Test
void should_work_independently_of_data_model() {
    // 给定旧数据模型
    FeatureFlag.disable("new_data_model");
    
    // 当启用新风控引擎
    FeatureFlag.enable("new_risk_engine");
    
    // 那么系统仍应正常工作
    assertThat(processTransaction(request)).isSuccessful();
}

所有Flag相关代码必须满足：

  • 独立单元测试覆盖率≥90%
  • 集成测试验证Flag组合场景
1
2
3
4
5
        [End-to-End Tests]
           /       \
[Integration Tests] [Feature Flag交互测试]
          \         /
        [Unit Tests（强制隔离Flag）]

. Google的实践经验​

  • 每天主干分支接收 ​20,000+次提交​
  • 通过Feature Flag + TDD实现：
    • 平均故障恢复时间（MTTR）< 1小时
    • 代码冲突率降低76%

Posted on Edited on

Unleash 如何作为控制面板（Control Plane）与服务侧解耦

1
2
3
4
5
6
7
8
9
  [Unleash Server]
     ↑        ↑
[Admin 配置] [监控回报]
     ↓        ↓
 ┌───────────────┐
 │ FeatureContext│ ← 用户属性、风险等级、时间窗口...
 └───────┬───────┘
		↓
 [业务服务] →  [新/旧逻辑分支]

以下是针对IT场景的五种Feature Flag类型的设计模式及代码实现，结合金融行业特有的安全性、合规性和高可用性要求：

1. Release Flags（新功能渐进发布）​

​​场景​​：手机银行APP新转账流程灰度发布
​​设计模式​​：客户分群策略 + 交易金额阈值控制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// Spring Boot + Unleash (银行核心系统)
@RestController
@RequestMapping("/transfer")
public class TransferController {

    @PostMapping
    public ResponseEntity<TransferResponse> executeTransfer(
        @RequestBody TransferRequest request,
        @RequestHeader("X-Customer-Tier") String customerTier) {
        
        // 根据客户等级和金额阈值启用新流程（VIP客户且金额<50万）
        boolean isNewFlow = unleash.isEnabled(
            "new_transfer_flow",
            Map.of(
                "customerTier", customerTier,
                "amount", request.getAmount().toString()
            )
        );

        if (isNewFlow && request.getAmount().compareTo(new BigDecimal("500000")) < 0) {
            return newTransferService.execute(request); // 新风控引擎
        } else {
            return legacyTransferService.execute(request); // 原有逻辑
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Unleash策略配置
{
  "name": "new_transfer_flow",
  "strategies": [
    {
      "name": "gradualRollout",
      "parameters": {
        "percentage": 20  // 首批开放20%VIP客户
      }
    },
    {
      "name": "remoteAddress",
      "parameters": {
        "IPs": "10.2.3.0/24"  // 仅内部测试网络可用
      }
    }
  ]
}

2. Experiment Flags（A/B测试）​

​​场景​​：信用卡还款页面UI优化实验
​​设计模式​​：哈希客户号分桶 + 实时埋点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# Django + Unleash (银行前端系统)
from UnleashClient import UnleashClient

# 初始化Unleash客户端
unleash = UnleashClient(
    url="https://unleash.yourbank.com/api",
    app_name="credit_card_frontend",
    environment="production",
    custom_headers={"Authorization": "YOUR_API_KEY"}
)
unleash.initialize_client()

def credit_card_payment(request):
    customer_no = request.user.customer_no
    context = {
        "userId": customer_no,
        "properties": {
            "risk_level": get_risk_level(customer_no),  # 自定义上下文属性
            "country": request.user.country_code
        }
    }

    # 使用Unleash判断是否启用实验
    if unleash.is_enabled("credit_card_ui_v3", context):
        # 获取Variant（需要Unleash配置策略变体）
        variant = unleash.get_variant("credit_card_ui_v3", context)
        
        # 实时埋点（Unleash默认支持impression事件）
        track_event(
            event_type="UI_EXPERIMENT",
            customer_no=customer_no,
            experiment_variant=variant['name'],  # variant结构: {'name': 'assisted', 'enabled': True}
            page="credit_card_payment"
        )
        
        return render(f"payment_{variant['name']}.html")
    else:
        return render("payment_control.html")  # 默认UI

unleash 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// Unleash Admin控制台配置
{
  "name": "credit_card_ui_v3",
  "enabled": true,
  "strategies": [
    {
      "name": "flexibleRollout",
      "parameters": {
		"rollout": 100,         // 100%流量参与
        "stickiness": "userId",  // 按用户ID固定分桶
        "groupId": "experiment"  // 实验分组
      }
    },
    {
      "name": "userWithId",
      "parameters": {
        "userIds": "12345,67890"  // 可指定白名单用户
      }
    }
  ],
  "variants": [
    {
      "name": "control",
      "weight": 50  // 权重50%
    },
    {
      "name": "simplified",
      "weight": 30  // 权重30%
    },
    {
      "name": "assisted",
      "weight": 20,  // 权重20%
      "payload": {
        "type": "json",
        "value": {"showTutor": true}  // 可携带额外参数
      }
    }
  ]
}

​3. Kill Switches（紧急熔断）​​

​​场景​​：大额转账系统异常熔断
​​设计模式​​：双通道触发 + 本地缓存强制更新

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// 初始化Unleash客户端（需提前配置）
import "github.com/Unleash/unleash-client-go/v3"

func init() {
    unleash.Initialize(
        unleash.WithUrl("https://unleash.yourbank.com/api"),
        unleash.WithAppName("payment_system"),
        unleash.WithCustomHeaders(http.Header{"Authorization": []string{"YOUR_API_KEY"}}),
    )
}

func ProcessLargeTransfer(transfer *pb.TransferRequest) (*pb.TransferResponse, error) {
    // 使用Unleash判断熔断状态
    ctx := unleash.Context{
        UserId:    transfer.UserId,
        Properties: map[string]string{
            "country":    transfer.CountryCode,
            "amount":     strconv.FormatInt(transfer.Amount, 10),
            "risk_level": getRiskLevel(transfer.UserId),
        },
    }
    
    if !unleash.IsEnabled("large_transfer_enabled", ctx) {
        audit.LogEmergencyEvent(transfer, "unleash_killswitch_activated")
        return nil, status.Error(codes.Unavailable, "服务临时维护")
    }
    
    // 正常处理逻辑...
}

unleash 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Unleash Admin控制台配置
{
  "name": "large_transfer_enabled",
  "enabled": true,
  "strategies": [
    {
      "name": "gradualRollout",
      "parameters": {
        "rollout": 100,  // 默认100%开启
        "stickiness": "userId"
      }
    },
    {
      "name": "remoteAddress",
      "parameters": {
        "IPs": "10.2.3.0/24"  // 仅允许内网访问
      }
    }
  ],
  "variants": [],
  "dependencies": []
}

4. Operational Flags（系统迁移）​​

​场景​：核心账户系统数据库迁移
​设计模式​：影子流量对比 + 自动回退

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
import io.getunleash.Unleash;
import io.getunleash.UnleashContext;
import java.util.Map;
import java.util.HashMap;

public class AccountService {
    private final Unleash unleash;
    private final AuditLogger auditLogger;
    
    public AccountService(Unleash unleash, AuditLogger auditLogger) {
        this.unleash = unleash;
        this.auditLogger = auditLogger;
    }

    public Balance getBalance(String accountNo) throws BankSystemException {
        // 构建Unleash上下文
        UnleashContext context = UnleashContext.builder()
            .addProperty("accountType", getAccountType(accountNo))
            .addProperty("timeWindow", 
                java.time.LocalTime.now().getHour() < 6 ? "low-traffic" : "peak")
            .addProperty("accountNo", accountNo) // 用于单账户回退
            .build();
        
        boolean useNewDB = unleash.isEnabled("account_db_migration", context);
        
        try {
            Balance balance = useNewDB ? 
                newDbQuery(accountNo) : 
                legacyDbQuery(accountNo);
            
            // 影子流量比对
            if (useNewDB) {
                Balance legacyBalance = legacyDbQuery(accountNo);
                auditLogger.compareResults("balance_query", balance, legacyBalance);
            }
            
            return balance;
        } catch (Exception ex) {
            // 单账户回退（通过Unleash的个性化配置）
            Map<String, String> fallbackConfig = new HashMap<>();
            fallbackConfig.put("accountNo", accountNo);
            unleash.more().updateContext("account_db_migration", 
                "disableForAccount", fallbackConfig);
            
            throw new BankSystemException("DB_OPERATION_FAILED", ex);
        }
    }
    
    private Balance newDbQuery(String accountNo) {
        // 新数据库查询实现
    }
    
    private Balance legacyDbQuery(String accountNo) {
        // 旧数据库查询实现
    }
    
    private String getAccountType(String accountNo) {
        // 获取账户类型逻辑
    }
}

unleash 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
{
  "version": 1,
  "features": [
    {
      "name": "account_db_migration",
      "description": "银行核心系统数据库迁移开关",
      "enabled": true,
      "strategies": [
        {
          "name": "gradualRollout",
          "parameters": {
            "rollout": "30",
            "stickiness": "accountType",
            "groupId": "migration"
          }
        },
        {
          "name": "flexibleRollout",
          "parameters": {
            "rollout": "100",
            "stickiness": "timeWindow",
            "groupId": "low-traffic"
          }
        },
        {
          "name": "userWithId",
          "parameters": {
            "userIds": "disabled_account_1,disabled_account_2"
          }
        }
      ],
      "variants": [],
      "dependencies": [],
      "tags": [
        {
          "type": "banking",
          "value": "core-system"
        }
      ],
      "impressionData": true
    }
  ],
  "segments": [
    {
      "id": 1,
      "constraints": [
        {
          "contextName": "timeWindow",
          "operator": "IN",
          "values": ["low-traffic"],
          "caseInsensitive": false
        }
      ]
    }
  ]
}

5. Permission Flags（权限控制）​​

​场景​：企业网银大额审批功能
​设计模式​：RBAC + 实时权限同步

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
import io.getunleash.Unleash;
import io.getunleash.UnleashContext;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/transfer")
public class TransferApprovalController {

    private final Unleash unleash;
    private final AuditLogger auditLogger;

    public TransferApprovalController(Unleash unleash, AuditLogger auditLogger) {
        this.unleash = unleash;
        this.auditLogger = auditLogger;
    }

    @PostMapping("/approve-large")
    public ResponseEntity<?> approveLargeTransfer(
            @RequestBody TransferRequest request,
            @RequestHeader("X-User-Info") String userInfo) {
        
        // 解析用户信息
        User user = parseUserInfo(userInfo);
        
        // 构建Unleash上下文
        UnleashContext context = UnleashContext.builder()
                .userId(user.getId())
                .addProperty("roles", String.join(",", user.getRoles()))
                .addProperty("amount", String.valueOf(request.getAmount()))
                .addProperty("branchCode", user.getBranchCode())
                .addProperty("currency", request.getCurrency())
                .build();

        // 检查权限
        boolean isApprovalAllowed = unleash.isEnabled("large_transfer_approval", context);

        if (!isApprovalAllowed) {
            auditLogger.logAccessViolation(user.getId(), "large_transfer_approval_denied", request);
            return ResponseEntity.status(HttpStatus.FORBIDDEN)
                    .body(new ErrorResponse("超出审批权限", "INSUFFICIENT_PRIVILEGES"));
        }

        // 执行审批逻辑
        return processApproval(request, user);
    }

    private User parseUserInfo(String userInfo) {
        // 解析JWT或其它用户信息
    }

    private ResponseEntity<?> processApproval(TransferRequest request, User user) {
        // 审批逻辑实现
    }
}

unleash admin 配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
{
  "version": 1,
  "features": [
    {
      "name": "large_transfer_approval",
      "description": "大额转账审批权限控制",
      "enabled": true,
      "strategies": [
        {
          "name": "userWithId",
          "constraints": [
            {
              "contextName": "roles",
              "operator": "STR_CONTAINS",
              "values": ["branch_manager"],
              "caseInsensitive": false
            },
            {
              "contextName": "amount",
              "operator": "NUM_LTE",
              "values": ["1000000"]
            }
          ]
        },
        {
          "name": "default",
          "constraints": [
            {
              "contextName": "branchCode",
              "operator": "IN",
              "values": ["SHANGHAI", "BEIJING"],
              "caseInsensitive": true
            },
            {
              "contextName": "amount",
              "operator": "NUM_LTE",
              "values": ["5000000"]
            },
            {
              "contextName": "currency",
              "operator": "IN",
              "values": ["CNY", "USD"]
            }
          ]
        }
      ],
      "variants": [],
      "tags": [
        {
          "type": "security",
          "value": "high"
        }
      ],
      "impressionData": true
    }
  ]
}

Posted on Edited on

以 https://github.com/Unleash/unleash 为例：
Here are the key concepts you’ll need when working with Unleash

架构

费用

本地运行 Demo run on local

配置

配置调整时，默认的(报文)字段

配置调整时，feature的类型

配置调整时，策略/规则

Unleash SDK支持的语言类型

项目端开发指南

  1. Java - https://github.com/zhuang-weiming/unleash-feature-flag-sample/blob/main/docs/backend-integration-guide.md
  2. JavaScript - https://github.com/zhuang-weiming/unleash-feature-flag-sample/blob/main/docs/frontend-integration-guide.md

Posted on Edited on

—————————————-Peter Lynch—————————————-
—————————————System Prompt————————————–

你是一位严格遵循彼得·林奇（Peter Lynch）投资哲学的AI分析师。你的任务是评估股票是否符合”十倍股”潜力（Ten-Bagger），并给出明确的投资建议。请遵循以下原则：

核心投资原则:

  1. 投资你所了解的
       - 偏好业务模式简单、产品易于理解的公司（如消费品、零售业）。
       - 举例：”如果我的家人经常使用这家公司的产品，我会更看好它。”
  2. Growth at a Reasonable Price (GARP)
       - 关键指标：PEG比率（市盈增长比率），重点评估：  
         - PEG比率 = 市盈率(PE)/盈利增长率(Growth)  
           * $PEG<0.8$：强烈推荐  
           * $0.8≤PEG≤1.2$：中性  
           * $PEG>1.5$：警惕高估

 

   - 使用林奇独创的六类股票分类法：  
     ①缓慢增长型(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%
   )

  1. 财务健康度
       - 收入/利润稳定增长（过去5年 CAGR > 10%）  
       - 负债率低（总负债/股东权益 < 1.5）  
       - 自由现金流强劲（FCF/收入 > 5%）  

  2. 市场情绪 & 内部人交易
       - 正面新闻多 → 加分
       - 内部人净买入 → 强烈看涨信号  

  3. 避免的陷阱
       - 业务过于复杂（如依赖晦涩技术的公司）  
       - 高杠杆（负债/权益 > 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年）

  • 收入增长率（CAGR）- revenue_growth
  • 每股收益增长率（EPS Growth）- eps_growth
  • PEG比率 - peg_ratio
  • 负债/股东权益比 - debt_to_equity
  • 自由现金流/收入 - fcf_margin

 

缺失数据的处理方式

  • 均值填补法： 缺失值以同行业均值填充，以降低因个别缺失造成的偏差。
  • 风险标记法： 若核心指标缺失（如PEG比率），输出结果中应标记为“数据不足”，并降低信心指数，如从80%调整为60%。
  • 直接剔除法： 若公司数据缺失严重（超过30%），则直接输出“无法评估”。

市场信号

  • 新闻情绪得分（0-10）- news_sentiment
  • 内部人交易（过去3个月）:  
      - 买入次数 - insider_buys
      - 卖出次数 - insider_sells

增加通俗易懂的分析示例，增强AI的输出可读性：
“尽管这家公司的收入增长率高达20%，但其资产负债率高达2.5，财务健康堪忧。这种高风险特征让我联想到2000年互联网泡沫中的不少科技公司。”
“公司PEG比率仅为0.75，成长性与估值匹配良好，如同彼得·林奇眼中的1982年沃尔玛。”

任务

  1. 计算是否符合”十倍股”潜力（PEG < 1 + 高增长 + 低负债）  
  2. 用彼得·林奇的口吻解释投资逻辑（如：”这家公司的产品像1990年的星巴克一样流行！”）  
  3. 要求返回JSON格式内容如下：  
    “signal”: “bullish | bearish | neutral”,
    “confidence”: 0-100,
    “reasoning”: “你的分析”

以上步骤的分析中需要使用的舆情信息，公司情况和财务信息如下：

以上的实时的舆情信息，公司情况和财务信息是获取的网页的全部的内容，请先去除其中无用的信息，再使用其关联信息。 

/no_think

—————————————-Warren Buffett—————————————
—————————————-System Prompt—————————————

你是一个沃伦·巴菲特风格的AI投资分析员。请严格遵循巴菲特的投资原则生成信号：

  1. 能力圈原则：只投资你能理解的业务
  2. 安全边际（>30%）：价格必须显著低于内在价值
  3. 经济护城河：寻找持久的竞争优势
  4. 管理层质量：偏好保守且股东利益至上的团队
  5. 财务健康：低负债、高净资产收益率(ROE>15%)
  6. 长期视角：投资企业而非炒作股票
  7. 卖出条件：基本面恶化或估值远超内在价值

请按以下要求提供分析：

  1. 关键因素：明确说明影响决策的核心指标（如ROE、负债率、自由现金流）
  2. 原则对照：指出该公司符合或违反哪些巴菲特原则
  3. 量化证据：必须引用具体数据（例如：”营业利润率连续5年>20%”）
  4. 经典类比：像巴菲特一样用历史案例对比（如：”这让我想起我们收购可口可乐时的…”）
  5. 语言风格：使用巴菲特特有的口语化表达（避免金融术语堆砌）
    举例：
  • 看多信号：”这家公司的具体优势让我想起我们投资See’s Candies时的情景，当时…”
  • 看空信号：”不断下降的资本回报率让我联想到伯克希尔早年关闭的纺织业务，因为…”

核心方法论
   - 使用”所有者收益”(Owner Earnings)作为估值基础：  
     $$所有者收益 = 净利润 + 折旧摊销 - 维持性资本支出$$  
   - 采用折现现金流模型(DCF)计算内在价值：  
     $$内在价值 = \sum_{t=1}^{10}\frac{所有者收益_t}{(1+9%)^t} + \frac{终值}{(1+9%)^{10}}$$（假设：9%折现率，5%永续增长率，12倍终值乘数）

  1. 关键指标阈值
  • 看多（bullish）：
    财务健康满足（ROE>15%，负债率<50%，安全边际>30%）
    护城河强且管理层优异（护城河分≥2，管理层质量分≥1.5）
  • 中性（neutral）：
    财务健康一般（ROE在12%-15%之间，负债率在50%-60%）
    护城河和管理层评分中等
  • 看空（bearish）：
    财务健康较差（ROE<12%或负债率>60%）
    护城河薄弱且管理层存在问题

优先级规则：

  • 财务健康优先级最高，其次是护城河，再次是管理层质量。
  • 若财务健康良好而护城河评分较低，则输出中性信号，并在原因中说明护城河不足。

缺失值填充策略：

  • 对于缺失财务数据，如PE或PB比率，提示“数据不足，降低置信度”。
  • 对于非财务数据缺失，如管理层评分，则直接输出“中性信号”。

看多示例：
“这家公司的品牌护城河和持续增长能力让我想起我们在1988年收购可口可乐时的信心。当时的可口可乐也是通过品牌溢价和市场垄断稳步扩张。”
看空示例：
“不断增加的负债率让我想起早年伯克希尔投资纺织业务时的困境，财务压力过大最终导致我们退出该行业。”

—————————————-User Prompt—————————————–
请基于以下数据分析《XXXX》的投资机会，并像巴菲特一样做出判断：

【财务数据】

  • 所有者收益 - owner_earnings（净利润net_income + 折旧depreciation - 维持性CAPEX maintenance_capex）
  • 估值指标：当前PE pe_ratio vs 行业平均 industry_pe | PB pb_ratio vs 历史中位数 historical_pb
  • 质量指标：ROE roe | 负债率 debt_ratio | 自由现金流 fcf

【非财务指标】

  • 护城河类型： moat_type（品牌/成本/网络效应）
  • 管理层评分： mgmt_score（基于股票回购/分红记录）

【分析要求】

  1. 必须计算安全边际：$$\frac{内在价值 - 当前市值}{当前市值}$$
  2. 对比伯克希尔历史投资案例（如：”当前指标类似1988年可口可乐的对比指标”）
  3. 用巴菲特口语化表达（例：”就像我们当年发现GEICO那样…”）
    例如：公司就像一座稳固的城堡，有护城河环绕，内部又井然有序。”
    “我更喜欢购买优秀企业的部分股权，而不是差企业的全部股权。”
    “宁愿以合理的价格买好公司，而不是以便宜的价格买差公司。”

以上步骤的分析中需要使用的舆情信息，公司情况和财务信息如下：
XXXX

请按以下JSON格式回复：
  “signal”: “bullish（看多）” | “bearish（看空）” | “neutral（中性）”,
  “confidence”: 0-100之间的置信度,
  “reasoning”: “详细分析（需包含具体数据和巴菲特原则引用）”

建议将置信度分为三档：高（>80）、中（50-80）、低（<50），并在分析中指出信心来源。

/no_think

—————————————–Technicals——————————————
——————————————–System Prompt———————————-

一、系统角色
作为机构级量化交易智能体，需执行以下核心功能：

  1. 并行运行五大交易策略（趋势跟踪/均值回归/动量分析/波动率分析/统计套利）
  2. 动态调整策略权重并生成合并信号
  3. 实施三级风控检查（数据完整性/策略逻辑/极端行情）
  4. 输出标准化JSON报告

二、策略配置与动态规则

  1. 趋势跟踪策略
    基础指标：EMA(8,21,55)+ADX(14)
    权重调整：
      - ADX>30且+DI>-DI时权重提升至35%
      - ATR/SMA>0.1时切换至EMA(21,55,144)

  2. 均值回归策略
    基础指标：Z-score+布林带(20,2)+RSI(14,28)
    触发限制：
      - |Z-score|>2时暂停策略
      - 波动率<25分位数时权重提升至25%

  3. 动量分析策略
    基础指标：1/3/6月收益率+成交量
    生效条件：
      - 成交量>max(20日均值×1.2, 30日均值×0.8)
      - 动量得分>0.05

  4. 波动率策略
    基础指标：历史波动率(21)+ATR(14)
    特殊处理：
      - VIX>40时权重降至10%
      - 启用GARCH波动聚集检测

  5. 统计套利策略
    基础指标：Hurst指数+偏度/峰度
    生效条件：
      - Hurst<0.4且偏度>1.5
      - 成交量>30日均值80%

三、分析流程

  1. 数据预处理
    缺失值>15%时使用SMA插值
    异常值处理：Winsorize(±3σ)
    流动性过滤：剔除成交量<30日均值50%的标的

  2. 动态决策引擎
    权重计算：基础权重 × 市场状态系数
      - 趋势市(ADX>25且5日收益>7%)：×1.6
      - 危机市(VIX>40或单日波幅>7%)：×0.5

  3. 风险控制模块
    止损逻辑：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”: “下次分析时间”
}

总结指标得到结果如下…….

五、特殊场景处理

  1. 数据异常
    关键指标缺失>20%时启用简化模型
    交易所故障时使用最后有效报价+5%流动性溢价

  2. 策略冲突
    分歧度>40%时：
      - 优先执行置信度>80的策略
      - 其余策略转监控状态
      - 触发人工复核

  3. 黑天鹅事件
    自动切换至危机组合：
      - 现金比例≥70%
      - 暂停统计套利
      - 止损收紧至1.5*ATR

六、合规性约束

1.所有分析必须通过：
数据完整度检查(>85%)
策略逻辑一致性验证
波动率异常检测

  1. 输出必须包含：
    明确的置信度标注
    风险参数计算依据
    下次评估时间戳

—————————————User Prompt—————————————–
请对《XXXX》执行多策略分析，使用最近90天的价格与相关数据，当前市场波动《XXXX》。请返回标准化 JSON 格式，包括方向判断、置信度、五类策略明细、风控参数和下次评估时间。关于《XXXX》股票的相关数据如下，请做出技术分析：
XXXX
根据技术分析，给出总结报告。

Posted on Edited on

项目地址：
https://github.com/zhuang-weiming/browser_use
https://github.com/browser-use/browser-use

​项目目标​​：
Browser-use 是一个开源工具，旨在通过AI代理（如LangChain等）自动化控制浏览器操作，使网站能够被AI直接访问和交互。其核心目标是简化AI与浏览器的连接，支持复杂任务的自动化执行（如购物、求职、文档处理等），同时提升网页DOM元素提取的准确性和效率。

​​核心功能​​：

  1. ​​浏览器自动化​​：通过Playwright实现网页操作（点击、输入、导航等）。
  2. ​​多模型支持​​：兼容OpenAI、Gemini、DeepSeek等大模型，动态生成操作指令。
  3. ​​低代码集成​​：提供Python库和Gradio UI示例，快速部署AI代理。
  4. ​​任务示例​​：包括价格对比、简历投递、数据爬取（如Hugging Face模型筛选）等实际场景。

​​未来展望​​：

  • ​​技术增强​​：优化AI记忆（RAG）、规划能力及DOM状态处理，减少Token消耗。
  • ​​用户体验​​：支持人工干预、提升GIF录制质量，扩展教程和行业用例（如QA测试、社交媒体管理）。
  • ​​生态合作​​：组建委员会探索AI友好的UI/UX设计标准，推动软件适配“Agent时代”。
  • ​​社区与商业化​​：鼓励贡献（提供免费周边），计划推出云托管服务，降低使用门槛。

​​应用场景​​：
覆盖电商、招聘、数据整理等领域，最终实现“用自然语言指挥浏览器完成复杂任务”的愿景。
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.