它读的是你的仓库，不是你对仓库的描述
在设置里连上 GitHub 并选一个仓库，它会被克隆进一个隔离的工作区。所以它回答的是你真实代码里的问题，包括那些你自己都忘了还在的部分。
它更像一个"先把代码读完了"的贡献者，而不是凭空生成文件的工具。
在设置里连上 GitHub 并选一个仓库，它会被克隆进一个隔离的工作区。所以它回答的是你真实代码里的问题，包括那些你自己都忘了还在的部分。
它会先确认你到底要什么，写一份一分钟能读完的计划，然后小步实现。如果计划是错的，你在代码出现之前就知道了，而不是之后。
成果以 Pull Request 的形式回到你的仓库——一份 diff、一段说明、以及背后的测试记录。你原有的分支保护和 reviewer 规则照常生效。
Token 和密钥锁在你自己的私有工作区里。它能用，但没法把它们打印回对话中——对你不行，对别人也不行。
从一句话，到一份可以 review 的 diff。
用大白话就行。"加个两步验证。""我们的 webhook 会漏掉重试。""把 auth 中间件拆成独立的包。"你不需要知道涉及哪些文件。
你它会把相关代码过一遍，然后带着"光看代码确实答不了"的问题回来。在这里回答两个问题，能省掉它照着错误理解干一小时。
它计划很短也很具体：改什么、按什么顺序、以及这次刻意不碰什么。
然后一步步实现，边写边跑你的测试。测试挂了它会去修代码，而不是把测试删掉。
它你收到的就是一个正常的 Pull Request。读 diff，在讨论里让它改，满意了再合并。它不会自己动你的主分支。
你从一行小修，到带规格的完整功能，都行。
在你把要紧的东西交给它之前，值得先读这几条。
所有改动都以 PR 的形式过来。这就是全部的安全机制——如果你不看就点同意，那它的危险程度，和任何一个你不看就放行的贡献者完全一样。
它跑的是你已有的测试。在覆盖率很薄的仓库里，"测试全绿"的含金量没那么高，review 的担子还是回到你身上。
它最擅长边界清楚的活儿：一个功能、一次重构、一个能复现的 bug。"把后端重写一遍"换来的是一份你应该去争论的计划，而不是一个可以撒手不管的周末。
免费试用可以连一个仓库。不限仓库数量和并行任务需要付费订阅。
每个团队成员一份订阅，各自带自己的每月积分。
含每月 1,500 积分、不限连接的仓库数量、以及并行任务。可以先免费试用，试用期限一个仓库。
团队成员需要在付费的 ClawBot 套餐之上雇佣。一份基础套餐覆盖你雇的所有团队成员。
不会。成果以 Pull Request 的形式回到你的仓库，你原有的分支保护和 review 规则完全照旧。
适合，但有一点必须说清楚。你确实可以只描述需求，就让一个能用的应用被推到你的 GitHub 上。
但"review PR"是这里的安全机制，而你将会批准一些自己读不全的 diff。建议先从小的、风险低的改动开始，用"应用是不是照你说的做了"来判断结果。
只有你主动连接的那些。每个仓库都克隆进属于你账号的工作区。
一线的编程模型，按"适合干这个活"选的，不是按便宜选的。这也是为什么它有自己的积分额度，而不是无限制地跑。