那天我想批量抓取一个竞品的定价页面做市场调研用。需求很正常做出海产品了解竞争对手定价是基本功。我在 Claude Code 里描述了需求它停了几秒然后给我输出了一段话大意是它可以帮我写通用的 HTTP 请求代码但不会帮我写专门针对某个网站绕过反爬的逻辑。我当时有点懵。不是生气是没想到它会这么回答。然后我意识到我需要搞清楚它的边界在哪里不然我会在错误的方向上浪费时间。大多数人踩的坑不是问了坏问题是不知道边界在哪用 Claude Code 做出海开发有个特别常见的场景你在做一个正经产品但某个技术需求擦到了边界。比如需要解析竞品页面的数据结构。比如想模拟用户行为测试自己的限流逻辑。比如做安全加固需要理解某类攻击的原理。这些需求本身是合法的、正当的但如果你 Prompt 写得不够清晰很可能触发拒绝——不是因为你想做坏事是因为它无法分辨上下文。反过来也有问题有人以为 AI 什么都能做结果在一些根本不会被满足的需求上绕了很久消耗了大量时间和精力。我这篇文章想干的事情很简单把边界画清楚让你不用浪费时间在错误的方向上试探。它的安全边界本质上是三条线理解清楚了这三条线你就能预判它会不会帮你以及怎么改 Prompt 让它帮你。第一条线意图是否明确有害Claude Code 不会帮你做的事核心判断标准是这个请求是否有明确的伤害目标。明确有害的比如写恶意代码、病毒、勒索软件帮某个具体的网站或系统实现入侵绕过某个平台的身份验证机制生成钓鱼邮件或欺诈性内容这些它不会做不管你怎么包装需求不管你说自己是安全研究员还是测试自己的系统。但注意拒绝有害请求和拒绝安全相关的合法开发是两件事。你想了解 XSS 攻击原理、想给自己的应用写输入校验逻辑、想理解 SQL 注入的机制——这些它完全可以帮你因为目的是防御不是攻击。第二条线上下文是否足够清晰这条线是最多人踩坑的地方也是最容易通过调整 Prompt 解决的地方。它拒绝你很多时候不是因为你的需求有问题是因为你的描述让它无法判断意图。比如帮我写一段绕过登录的代码——意图完全不明它不知道你是要测试自己的系统、还是要入侵别人的系统所以默认拒绝。但换成帮我写一段单元测试模拟绕过 JWT 验证的情况用于测试我的 API 在 token 失效时的异常处理逻辑——意图清晰完全可以帮你。说人话就是你提供的上下文越具体它越能准确判断拒绝的概率越低。这条规律在正当需求上百分之百有效。如果加了足够的上下文它还是拒绝那通常说明需求本身确实有问题。第三条线是否涉及第三方权益这条线最微妙也是做出海开发最容易碰到的。帮你爬取竞品数据、绕过某个 API 的频率限制、模拟大量虚假注册——这类需求涉及到第三方平台的权益它会比较谨慎。不是一律拒绝是会视情况而定。举个具体例子帮我写一个脚本访问 competitor.com 的定价页面解析 HTML 里的价格数据这个它可能会帮因为访问公开页面本身不违法。帮我写一个脚本模拟浏览器行为绕过 competitor.com 的反爬机制批量抓取他们的用户评论数据这个大概率拒绝因为绕过反爬明确针对第三方的防护机制。实际遇到边界时怎么处理情况一需求本身合法但 Prompt 触发了误判这种最好处理改 Prompt 就行。改写原则说明你的项目背景这是我自己的 SaaS 产品说明你的目的用于测试 / 加固安全性 / 处理异常情况把攻击性词汇换成防御性词汇原始 Prompt容易被拒绝帮我写一个脚本测试我的 API 有没有 rate limiting 漏洞改写后通过率高我正在给自己的 SaaS API 添加 rate limiting 功能想写一个测试脚本验证限流逻辑是否正确。需要模拟同一个 IP 在 60 秒内发出超过 100 次请求观察第 101 次是否返回 429 状态码。我用的是 Next.js API Routesrate limiting 用的是 upstash/ratelimit。两个 Prompt 的本质需求一样但第二个里有三个关键信息这是我自己的系统、目的是测试防御功能、技术栈具体。情况二需求合法但它还是拒绝怎么办这种情况我遇到过处理方法是把需求拆解拿走触发点保留你真正需要的部分。举个实际例子我需要写一个功能检测同一个邮箱有没有注册过多个账号防止滥用免费试用。直接问帮我写检测账号滥用的逻辑——它比较保守给的方案过于简单。我改成了两个步骤第一步问它 Prisma 怎么查一个邮箱域名对应的所有账号用 Prisma 查询 User 表找出邮箱域名相同的所有用户按域名分组返回每个域名下的用户数量和注册时间列表第二步问它怎么设计规则我想限制同一邮箱域名在 7 天内的免费注册数量上限是 3 个。帮我设计这个校验逻辑在用户注册时触发用 NextAuth 的 signIn callback 实现两个问题都顺利拿到了答案。说人话就是把一个敏感的大需求拆成几个不敏感的小需求逐步组合。情况三真的撞到了它不做的事有些事它就是不做改再多 Prompt 也没用。这时候最好的选择是接受它换思路。我自己遇到过一次明确的拒绝——想让它帮我写一段代码模拟用户在没有同意条款的情况下完成支付流程用来测试我的合规检查逻辑。它解释说它不会帮我构造绕过用户同意的代码因为这个模式可以被用于实际的欺骗性支付流程。我当时有点崩溃因为我的需求是测试不是欺骗。但我换了个思路与其测试绕过不如测试正确阻断。我让它帮我写测试用例验证在用户没有勾选同意的情况下我的后端是否正确返回了 400 错误、是否记录了日志、是否阻止了 Stripe Checkout 的创建。测试结果更好覆盖面更完整。有时候它的拒绝是在逼你找到一个更好的解题路径。踩坑环节坑一以为加了教育目的就能绕过限制早期我以为在 Prompt 里加上这只是学习用途或者仅供研究就可以让它放松。试了几次发现这个策略完全没用。它判断的是需求本身的风险不是你贴的标签。反而有时候这种强调会让它更警惕因为正常的开发需求不需要特别声明自己是无害的。解决方案不要用声明来证明自己用具体的项目上下文来证明。你的技术栈、你的功能模块、你的测试场景——这些具体信息才是有效的信号。坑二以为被拒一次就没戏了直接放弃有一次我问它帮我处理一个涉及用户数据导出的功能第一次被拒了我以为这个方向走不通换了个更复杂的方案折腾了两小时。后来我重新描述了需求加了业务场景用户主动请求导出自己的数据GDPR 的数据可携带权要求它立刻帮我写了完整的导出逻辑。第一次拒绝和第二次接受需求完全一样就是上下文不同。解决方案被拒了不要直接放弃先思考它拒绝的可能原因补充缺失的上下文重新问。给自己三次机会三次都拒才算真正撞线了。总结它的边界不是枷锁是一个强制你把需求想清楚的过滤器。你的需求越具体、上下文越充分这个过滤器越透明。模糊的需求不仅 Claude Code 搞不定人也搞不定。最后一个问题你有没有遇到过需求完全正当但被 AI 拒绝的情况你当时是怎么重新描述需求的——是补充了上下文还是换了一个方向表达