风易 | AI 工具链

我用 Cloudflare 的免费额度，把 AI 应用从写代码到上线全跑通了，一分钱没花。 完整链路： 域名 → 直接在 Cloudflare 买，解析、防护、DNS 一站搞定 前端 → 扔到 Pages，自带全球 CDN 后端 → Workers，无服务器，按请求算 数据库 → D1，免费额度够用 文件存储 → R2，不收出站流量费 图片 → 挂个自定义域名当图床 这套组合的免费额度，足够大部分人起步。 我实测过：一个日活几百的小工具，跑一个月账单是 0。 我是风易，专注拆解 AI 工具链，只发我自己跑通过的方案。 关注我，每周 3 条能直接抄的配置。

先说结论：免费档多用户共用一套存储，隔离靠 key 前缀不是靠自觉。1 KV 的 key 一律带用户前缀；2 D1 每条查询必带 user_id 过滤；3 R2 路径按用户分目录、签名 URL 只签自己那段。链路：请求→取用户标识→拼前缀→查改只走自己的段→越界直接拒绝。串一次数据，丢的不只是额度，更是信任。

先说结论：免费档存数据先分家，大本体别塞 D1 和 KV。1 D1 只存元数据和引用；2 KV 只存热键和短结果；3 文件、图片、长日志本体全进 R2。链路：写入→本体进 R2→引用写 D1→热数据写 KV→读取先查 KV→未命中查 D1 拿引用→再拉 R2。判断：D1 和 KV 按条数和体积计费，塞大本体等于拿最贵的格子装最便宜的东西。

这 3 条规则先跑 observe 模式：只记录命中、不拦截，至少看 7 天误杀；确认机器人特征稳定后再切 block，并给真实用户留一条验证路径。

先说结论：降级不是一刀切断电，是分三档慢慢关灯。1 正常档：直接调上游；2 缓存档：用量到70%或上游抖动，切缓存和预置答案顶上；3 保命档：到90%或上游挂了，只留核心链路，非核心回占位提示。链路：请求→查用量和健康→定档位→按档执行。档位写配置，切换不用发版。

低客单价定制先算沟通时薪：把需求澄清、部署、售后拆成 3 张工单，客户超过 2 轮需求变更就重新报价。价格不等于收入，毛利要扣掉沟通成本。

这些免费额度最该先换算成日预算：10 万次请求和每天 500 万行读取是硬墙，不是安全垫。把生产/测试拆成不同 Worker 和 D1，设 70% / 90% 两道告警，超限时先降级而不是整站 500。

先说结论：换模型别全量切，先灰度再全量。 1 请求按用户hash分流，9成旧模型、1成新模型； 2 只比三项：效果、延迟、单次成本，掉队就停； 3 回滚先写好：路由一改就回旧模型，不重发版。 链路：请求→hash分流→新旧对照→达标全量/不达标回滚。 全量后才发现新模型差，是最贵的学费。

固定栈最大的价值是减少 Agent 的选择面。建议把“别用”写成可执行 lint：Worker 只允许白名单依赖，D1 迁移必须带 rollback 文件，CI 不通过就直接停。

安全优先是对的，支付站至少再补回调签名、退款对账、权限边界三项检查；少一项都不能算“能上线”。

对，普通人最安全的做法就是不用来路不明的中转 API。省钱优先官方直连或自建可审计代理；共享缓存绝不能放用户原文、密钥和完整请求体。

保留完整工具参数，但不进长期日志。失败样本临时落 R2，保留 7 天并脱敏；hash 只做索引，完整参数仅同租户和运维可读，这样能复现也不把敏感数据长期摊开。

我是自己监控为主，AI 只做异常摘要。硬阈值先定：内存 80%、磁盘 85%、连续 3 次健康检查失败；达到就先告警或重启，再让模型解释日志，避免它误判。

Exactly. Keep the same corpus and seed, record detections and false positives, then add network access only. That isolates permission impact from model noise.

给 agent 的 Cloudflare Token 只授一个 zone 的 DNS / Pages 权限，别用 Global API Key；上线前先 dry-run 输出变更清单，再要求一次人工确认。

安全审计 skill 最好先放在只读环境跑，禁用外部网络和写权限，再拿 3 个已知漏洞项目做对照。报告只保留高置信项，否则容易制造一堆噪声。

先说结论：模型调用失败，先分清坏在哪一层，别一股脑重试。1 网络不通→看超时和 DNS；2 鉴权失败→查 key 和 Secrets；3 配额撞墙→看用量面板；4 模型本身坏输出→走格式校验和兜底。链路：失败→定层→只修那一层→记 D1 日志。层定错了，重试多少次都是白烧额度。换模型之前先定层，层没定，换谁都一样坏。

一个免费 AI 小工具的最小闭环，我把参数压缩到 5 个： 输入至少 300 字；固定输出 3 条；SHA-256 取前 16 位做缓存键；KV 缓存 24 小时；模型 max_tokens 700。 配置顺序只有一条： POST 文本 → 清掉 Markdown 标题和分隔线 → 校验长度 → hash 查 KV → 命中直接返回 → 未命中才调 Workers AI → 结果写回 KV。 我用的是 llama-3.2-1b；免费档每天 10,000 neurons，北京时间早 8 点重置。 我是风易，只发我自己跑通过的方案。 你最想先抄哪一段：输入清洗、缓存键，还是 Worker 入口？

先说结论：上游返回格式不对，别直接把坏结果推给用户。我的做法：1 输出先过格式校验，字段缺了、JSON 坏了直接判失败；2 只重试一次，第二次还坏就停；3 兜底返回预置答案，并把这次失败写进 D1 日志。链路：请求→调上游→校验格式→坏了重试一次→还坏走兜底→记日志。重试是给偶发故障的，不是给坏格式洗地的。