免费 AI 编程代理能不能进你的研发流程？三道上闸 + 7 天试用清单

先明确性质：这是一次「准入判断」，不是工具测评

Cloudy 在 Hacker News 上以「Free AI」为标题提交，提交时几乎没有讨论量【2】。打开官网会看到它把产品拆成两块：浏览器里的 AI 对话，以及终端里的编程代理 Cloudy Code；两者共用一个账号与同一份额度，不要求绑卡，也没有倒计时式的试用期【1】。

对中国企业来说，「又一个免费工具」本身不构成决策理由。真正需要回答的是三个问题：这份免费额度能不能覆盖真实工单、代理拿到文件读写和命令执行权限后能不能被限制住、源码与配置发到境外服务是否合规。下面按「事实—三道上闸—试点—止损」的顺序展开，你可以直接拿去当内部评估表用。

图：示意图（AI 生成，非原文截图；模型 nano-banana-2）。仅作阅读辅助，事实以正文与参考文献为准。

一、先把事实层摆清楚

厂商页面给出的关键设定如下，均属厂商自述，正式采用前建议自行复核【1】：

• 额度规则：每个账号每天 25 条消息与 70 个 agent credits，额度跟账号走，跨设备可用；一次编程回合消耗 2–16 个 credit【1】。
• 两个入口：浏览器端无需安装；终端端需要 Node 18+，通过 npm 全局安装 CLI，登录后与网页端共用同一份额度【1】。
• 代理权限：Cloudy Code 在你当前所在目录工作，只能读取和编辑你指定的那一个文件夹，执行命令之前会先向你确认【3】。
• 数据口径：厂商称对话不会被用于训练模型、也不会被出售，但会保存以便历史记录跟随账号【3】。
• 模型池：六个模型可在同一会话中切换而不丢上下文，页面标注了每个模型的单回合成本以及是否支持读图【1】。

这五条里，第一条和第三条决定了它能不能用，第四条决定了它敢不敢用。

二、第一道上闸：把积分换算成「任务预算」

同一个 70 credits，在不同模型下的可用回合数差别很大。下表右列为编辑侧换算（70 ÷ 单回合成本），不是厂商给出的数字【1】：

把这张表读成管理结论，只有一句话：最便宜的模型和最贵的模型，同一天能完成的任务数量相差接近 9 倍。所以「免费」并不等于「无成本」，它只是把成本从账单换成了额度消耗。

落地时建议做四件事：

1. 两套账分开记。对话额度和 agent credits 是两条独立的计量线【1】，探索性提问走对话，有明确验收标准的改动才动 credits。
2. 开工前先定价。任务描述里写清「预计几个回合内完成」，超预算就停手复盘，而不是让代理反复试错把额度烧完。
3. 便宜的活别用贵模型。补类型标注、改名、格式化这类确定性改动，用最低成本档位即可；读设计稿截图复现 UI 缺陷、跨文件重构才值得上高成本多模态模型。
4. 沉淀自己的成本基线。用三五个真实工单记录实际回合数，之后的排期才有依据，而不是凭感觉估算。

三、第二道上闸：把代理限制在授权范围内

终端代理的风险从来不在于「它会不会乱来」，而在于「人会不会习惯性按回车」。上线前请逐条核对以下七项：

• 独立克隆、独立分支：不要在主干工作目录里启动代理，另建一个干净克隆，让它只在这个沙箱里活动。
• 密钥人工排查：检查目录内是否存在 .env、云厂商凭证、生产数据库连接串。这一步只能靠人看，不要指望忽略规则兜底。
• 先打一个 baseline 提交：代理动手前必须有可回滚的干净状态，否则它删改了什么，你连 diff 都读不出来。
• 命令分两级：测试、lint 这类可自动放行；部署、数据库迁移、包发布、安装系统依赖必须人工执行。
• 任务颗粒度控制在「一个可描述的改动」：带上验收条件，比「帮我修一下」有效得多。
• 验收看测试输出，不看它的自述：页面演示的流程是读文件、改文件、跑测试、用例通过【1】，这个顺序本身就是验收模板——跑不过就当没做。
• 会话结束审 diff：不允许存在未经人工审阅就并入分支的改动。

四、第三道上闸：数据出境与账号归属

厂商承诺「不训练、不出售」只回答了「它怎么用你的数据」，没有回答「你的数据能不能出境」。三项前置判断：

• 合同层面：客户项目、外包项目的源码片段能否发往境外服务，先翻合同与保密条款。
• 仓库分级：涉及个人信息、生产配置、未公开财务数据的仓库，整体排除在试点范围之外。
• 账号主体：额度按账号发放【1】，用个人邮箱还是公司统一账号，直接决定人员离职后历史记录与额度归谁管。

还要冷静看一个信号：该条目在 Hacker News 上提交时仅 2 分、0 条评论【2】。这意味着它几乎还没经过开发者社区的实战检验，稳定性与长期运营能力都属未知。加上「不绑卡、靠对话区赞助横幅支撑」的模式【1】，基本可以推断短期内不会有 SLA、企业合同或赔付条款。它可以当效率工具，但不宜承载关键交付链路。

五、模型路由：把个人偏好变成团队规则

六个模型可以中途切换【1】，体验上是加分项，管理上却意味着路由决策权被交回给了每个使用者。不写规则，团队里一定有人永远选最贵的、有人永远选最便宜的。建议按任务类型给出默认档位：

需要提醒：模型名称、上下文长度与模态标注都来自厂商自述页面【1】，属于待验证信息。正式进流程前，请用你们自己的真实工单做一次同任务双模型对照，比较一次通过率与人工返工量，别把宣传页当结论。

六、7 天试点节奏与止损线

不要一开始就全组铺开。按下面的节奏，一周就能得出「继续 / 放弃」的结论：

• 第 1 天：搭沙箱、开分支、清密钥、写命令白名单；
• 第 2–3 天：只做低风险任务，如补测试、改文档、修 lint，记录每个任务的 credits 消耗；
• 第 4–5 天：放 2–3 个真实但非阻塞的工单，观察返工次数；
• 第 6 天：统计四项指标——一次通过率、返工率、单任务 credits 消耗、人工审阅耗时；
• 第 7 天：决策。止损线建议写成一句话：若「人工审阅耗时」接近你自己动手写的时间，说明它只是把键盘换成了对话框，没有真正省时间。

七、三件不要做的事

不要共享账号。 额度按账号而非设备计算【1】，多人共用一个号会互相挤占配额，也归因不了谁在消耗。

不要把「会先询问」当成安全网。 询问机制的价值取决于人是否真的在读那条命令【3】。团队规范里应明确写：代理提出的执行命令必须逐条确认，禁止连续放行。

不要把免费当长期方案。 赞助换免费的商业模式随时可能调整额度或停止服务。真要用于生产，请提前准备替代路径，并把「工具切换成本」计入评估。

判断

这类产品真正的价值不在「免费」，而在于把对话与终端代理打通成一个账号、一套额度，让「问」和「改」发生在同一个上下文里【1】。对中国团队最务实的用法是：用免费额度做小范围验证，用权限清单控制风险，用自建指标决定是否扩大。顺序反了，省下来的时间会以返工的形式还回去。

参考文献

【1】Free AI — https://cloudy.chat/