1. 增长实验为什么总是跑成一次性脚本增长团队最典型的日常是这样的周一早上拉一份上周的转化数据在 Jupyter 里改几行筛选条件跑出一个提升 3.2% 的结论发到群里然后这周结束。下周想复现这个结论发现 notebook 里的日期是硬编码的渠道口径改过一次分母用的是注册数还是激活数已经没人记得。这不是能力问题是流程问题——实验没有被当成代码资产管理。business-growth-skills这个技能集想解决的就是这件事。它是一组面向商业运营和增长策略的 Python 技能模块覆盖客户成功、销售工程、收入运营、合同与提案四大块所有分析脚本只用 Python 标准库不装 pandas、不装 numpypython3 xxx.py --help就能跑。它本身不绑定任何平台Claude Code、Codex CLI、OpenClaw 都能加载它的 SKILL.md。但光有技能模块还不够。真正让增长实验可复现的是把「指标定义 → 假设拆解 → A/B 分流 → 结果回收 → 显著性判定」这条链路写成有目录结构、有依赖清单、有配置片段的流水线。我试过把这套东西塞进一个 repo 里跑了几周之后最大的感受是可复现的关键不在于算法多高级而在于每个环节的输入输出都被固定下来谁跑都一样。这篇文章面向的是增长运营、数据分析、以及需要把增长策略沉淀成代码资产的工程同学。你会看到一套可以直接复制的目录结构、一份零第三方依赖的 requirements 说明、一段能跑通的配置片段以及一次从数据拉取到显著性判定的完整验证动作。核心检索词就是 business-growth-skills 与 Python 增长实验流水线适合想把手工跑数变成可版本化流程的人。先说清楚一个前提这里的「A/B 分流」指的是实验分组逻辑的代码化不是让你去搭一套线上分流网关。增长团队更多是在离线数据上做回溯验证和策略评估所以流水线的重点是可复现而不是高并发。2. 用 TaoToken 给增长流水线接上模型能力流水线本身是纯 Python 的为什么还要接模型因为增长实验里有一大块工作不是算数而是「把业务语言翻译成可执行假设」。比如运营说「我觉得新用户首日引导太长导致流失」这句话要变成H1: 首日引导步骤从 5 步降到 3 步7 日留存提升 ≥2%中间需要拆解、需要生成指标口径、需要写回收 SQL 的骨架。这部分交给模型做比人手写快得多也更一致。TaoToken 在这里的角色是提供统一的模型调用入口。它的 API 地址是https://taotoken.net/api兼容常见的对话补全格式你可以在 Python 里直接用标准库的urllib发请求不需要额外装 SDK——这一点和 business-growth-skills 的零依赖原则正好对上。官网在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content需要看模型列表和文档可以从这里进。如果你只是偶尔让模型帮忙拆假设用模型对话页面就够了https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite。但增长流水线是长期跑的每周都要生成假设、回收结论这种情况更适合用 Coding Plan 把额度固定下来https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite。Key 的创建在控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite具体到 API Keys 页面是https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite。这里要强调一个工程习惯不要把 Key 写进代码。增长流水线通常要进 gitKey 一旦提交就是事故。正确做法是读环境变量本地用.env记得加进.gitignoreCI 里用 secrets。下面这段是流水线里调用模型的封装只用标准库import json import os import urllib.request API_BASE os.environ.get(TAOTOKEN_BASE_URL, https://taotoken.net/api) API_KEY os.environ[TAOTOKEN_API_KEY] MODEL_ID os.environ.get(TAOTOKEN_MODEL, claude-sonnet-4-5) def chat(messages, temperature0.2): payload json.dumps({ model: MODEL_ID, messages: messages, temperature: temperature, }).encode(utf-8) req urllib.request.Request( f{API_BASE}/v1/chat/completions, datapayload, headers{ Content-Type: application/json, Authorization: fBearer {API_KEY}, }, methodPOST, ) with urllib.request.urlopen(req, timeout60) as resp: body json.loads(resp.read().decode(utf-8)) return body[choices][0][message][content]注意MODEL_ID一定要和你账号里实际可用的模型 ID 对齐写错了会直接报模型不存在。我一般把它也放进环境变量这样换模型不用改代码。temperature 设 0.2 是因为假设拆解要稳定不要每次生成的口径都不一样否则流水线又不可复现了。接入之后流水线里就有两个能力层一层是 business-growth-skills 的确定性计算健康分、管道分析、显著性判定一层是模型的语义生成假设拆解、口径描述、结论摘要。前者保证可复现后者提升效率分工清楚就不会乱。3. 可复制的目录结构与配置片段先说目录结构。增长流水线最容易失控的地方是「脚本散落一地」所以第一步是把结构固定下来。下面这套是我实际在用的你可以直接抄growth-pipeline/ ├── .env.example ├── .gitignore ├── requirements.txt ├── config/ │ ├── metrics.yaml │ └── experiments/ │ └── onboarding_v2.json ├── skills/ │ └── business-growth/ │ ├── customer-success-manager/SKILL.md │ ├── sales-engineer/SKILL.md │ ├── revenue-operations/SKILL.md │ └── contract-and-proposal-writer/SKILL.md ├── src/ │ ├── llm_client.py │ ├── hypothesis.py │ ├── ab_split.py │ ├── collect.py │ └── significance.py └── runs/ └── 2025-06-onboarding_v2/ ├── config.snapshot.json ├── assignments.csv └── result.jsonskills/目录放的是 business-growth-skills 的 SKILL.md按需加载不要一次性全读进上下文。runs/是每次实验的产物目录里面必须有config.snapshot.json——这是可复现的核心任何一次结论都能追溯到当时的配置。requirements.txt这里要特别说明business-growth-skills 的九个脚本全是标准库所以严格来说你不需要装任何第三方包。但流水线里如果要做 YAML 配置解析标准库没有 yaml我一般用 JSON 代替或者手写一个极简解析。为了保持零依赖我选 JSON# requirements.txt # business-growth-skills 全部脚本仅依赖 Python 标准库 # 本流水线同样保持零第三方依赖Python 3.9配置片段用 JSON路径和原文一致。实验配置长这样{ experiment_id: onboarding_v2, owner: growth-team, metric: { primary: d7_retention, numerator: users_active_on_day7, denominator: users_activated, guardrail: [crash_rate, support_ticket_rate] }, hypothesis: { statement: 首日引导从5步降到3步7日留存提升不低于2%, direction: increase, mde: 0.02 }, split: { unit: user_id, ratio: [0.5, 0.5], salt: onboarding_v2_202506, strata: [platform, country_tier] }, window: { start: 2025-06-01, end: 2025-06-14, min_sample_per_arm: 5000 } }几个参数值得展开。salt是分流哈希的盐值固定它才能保证同一用户每次分到同一组这是可复现的前提。strata是分层维度增长实验里平台和国家分层差异很大不分层直接随机容易在样本量不够时产生偏差。mde是最小可检测效应它决定了你需要多少样本写假设的时候就该定下来而不是跑完再看。分流逻辑用标准库的hashlib实现不依赖任何随机数生成器保证跨机器一致import hashlib def assign_arm(user_id: str, salt: str, ratio(0.5, 0.5)) - str: key f{salt}:{user_id}.encode(utf-8) digest hashlib.sha256(key).hexdigest() bucket int(digest[:8], 16) / 0xFFFFFFFF return control if bucket ratio[0] else treatment这段代码的好处是只要 salt 和 user_id 不变结果永远一样。你可以拿它去核对线上分流是否一致也可以离线重跑历史实验。4. 从数据拉取到显著性判定的完整验证配置齐了跑一次完整验证。假设你已经把实验期的用户行为数据导出成 CSV字段包括user_id, arm, activated, active_day7, platform, country_tier。第一步是回收数据并做基础校验import csv from collections import defaultdict def load_arm_stats(path): stats defaultdict(lambda: {n: 0, activated: 0, retained: 0}) with open(path, newline, encodingutf-8) as f: for row in csv.DictReader(f): arm row[arm] stats[arm][n] 1 stats[arm][activated] int(row[activated]) stats[arm][retained] int(row[active_day7]) return stats stats load_arm_stats(runs/2025-06-onboarding_v2/assignments.csv) for arm, s in stats.items(): rate s[retained] / s[activated] if s[activated] else 0 print(f{arm}: n{s[n]} activated{s[activated]} d7_rate{rate:.4f})跑出来大概是这样的输出control: n6120 activated5480 d7_rate0.3124 treatment: n6088 activated5512 d7_rate0.3341treatment 的 7 日留存率 33.41%control 是 31.24%绝对提升 2.17 个百分点刚好超过配置里定的 mde 2%。但先别急着下结论2.17% 是不是显著要做检验。这里用两比例 z 检验标准库就能算import math def two_proportion_z(x1, n1, x2, n2): p1, p2 x1 / n1, x2 / n2 p_pool (x1 x2) / (n1 n2) se math.sqrt(p_pool * (1 - p_pool) * (1 / n1 1 / n2)) if se 0: return 0.0, 1.0 z (p2 - p1) / se # 双尾 p 值用标准正态近似 p_value 2 * (1 - 0.5 * (1 math.erf(abs(z) / math.sqrt(2)))) return z, p_value z, p two_proportion_z(1712, 5480, 1842, 5512) print(fz{z:.3f} p{p:.5f})输出z2.481 p0.01310。p 值小于 0.05在 95% 置信水平下拒绝原假设结论是 treatment 显著优于 control。到这里一次完整的「数据拉取 → 分流核对 → 指标计算 → 显著性判定」就跑通了而且每一步的输入输出都落在runs/目录里任何人拿同样的配置和数据都能复现出同样的 z 和 p。把结果写回result.json同时把配置快照一起存下来import json import shutil result { experiment_id: onboarding_v2, control: {n: 5480, d7_rate: 0.3124}, treatment: {n: 5512, d7_rate: 0.3341}, lift_abs: 0.0217, z: 2.481, p_value: 0.0131, significant: True, } with open(runs/2025-06-onboarding_v2/result.json, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) shutil.copy(config/experiments/onboarding_v2.json, runs/2025-06-onboarding_v2/config.snapshot.json)这一步做完实验就从「一次跑数」变成了「一个可版本化的资产」。下次有人质疑结论你直接把runs/目录甩过去配置、数据、代码、结果全在里面。5. 常见报错与排查对照跑这套流水线报错基本集中在几个地方。下面按真实遇到的错误对照排查。401 Unauthorized。调用模型接口时最常见。原因通常是TAOTOKEN_API_KEY没设置或者 Key 前后带了空格。排查方式python3 -c import os; print(repr(os.environ.get(TAOTOKEN_API_KEY)))看输出是不是None或者带引号。注意 Key 只在创建时显示一次丢了就重新建一个别去猜。local proxy failed / connection refused。这个报错说明请求根本没发出去通常是环境里配了本地代理但代理没启动。检查HTTP_PROXY、HTTPS_PROXY环境变量如果不需要就清掉unset HTTP_PROXY HTTPS_PROXY。增长流水线跑在 CI 里时尤其容易踩这个坑因为 CI 环境变量是继承的。reading choices 报 KeyError。说明返回体里没有choices字段一般是模型 ID 写错了或者请求体格式不对。先把原始返回打出来看在chat()里加一行print(body)。如果返回的是{error: {...}}按 error 里的 message 处理。模型 ID 一定要用账号里实际可用的别照抄文档示例。OAuth 相关报错。如果你用的是 Claude Code 或 Codex CLI 这类工具它们有自己的登录态。报 OAuth 错误通常是 CLI 的凭证过期了重新登录一次即可。注意 CLI 的登录态和 API Key 是两套东西不要混用。如果你在 Claude Code 里加载 business-growth-skills配置要写全三件套Base URL 填https://taotoken.net/apiKey 填你的 API KeyModel ID 填实际模型名。Cline 的 MCP 配置同理settings.json里这三项缺一不可。Codex 的auth.json也是这三个字段路径通常在~/.codex/auth.json。分流结果对不上。如果离线分流和线上不一致先核对 salt 是否完全相同再看 user_id 是否做了类型转换int 和 str 哈希结果不同。这是最容易忽略的坑我踩过一次排查了两小时最后发现是 CSV 读进来 user_id 变成了字符串。样本量不足。如果min_sample_per_arm没达到p 值再小也别下结论。这时候应该延长实验窗口而不是硬跑。可以在result.json里加一个sample_sufficient: false标记让下游流程知道这个结论不可用。6. 把增长策略沉淀成代码资产回到最开始的问题为什么增长实验总是跑成一次性脚本因为大家把实验当成「一次分析」而不是「一个产品」。一旦你把它当成产品目录结构、配置快照、依赖清单、结果归档这些工程习惯就会自然长出来。business-growth-skills 提供的是确定性计算的那一半——健康分、管道分析、显著性判定纯标准库零配置。模型提供的是语义生成的那一半——假设拆解、口径描述、结论摘要。两者通过一套固定的目录结构和配置片段拼在一起就成了一条可复现的流水线。每次实验的产物都落在runs/下配置和数据一起归档谁跑都一样。如果你要长期跑这套东西建议把模型调用也纳入版本管理。Key 用环境变量模型 ID 用配置调用封装在llm_client.py里换模型只改一个环境变量。额度方面长期编码和 Agent 场景用 Coding Plan 更稳https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite。接入细节和参数说明看文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite。Key 在 API Keys 页面创建https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite。最后一个实用技巧把runs/目录按实验 ID 命名并在result.json里记录git_commit字段指向跑这次实验时的代码版本。这样半年后回头看你不仅知道结论是什么还知道是哪版代码跑出来的。增长策略沉淀到这一步才算真正变成了可版本化的代码资产。