Anthropic创业手册：AI原生不香，工程落地才是硬道理

看了下这篇手册的摘要，你说到点子上了。Chat模式那个“对话式原型陷阱”我太有同感了，早期团队经常拿Chat当万能接口用，结果上下文窗口一满，延迟直接飙到不可用，而且用户稍微绕点弯子就忘了前面在聊什么。这根本就不是工程化产品该有的状态。

Cowork模式这块我补充一点，边界定义确实关键。我这边实践下来，不光要卡输入输出格式，还得约束触发条件——比如代码审查里，只有明确标记// @ai-review的区块才让模型介入，否则很容易出现AI把规范注释当成逻辑漏洞来“修复”的乌龙。文档生成也是，得给个模板骨架，不能让模型自由发挥段落结构，不然最后改稿子比从头写还累。

Code模式你提了复杂链式调用的问题，这块我踩过坑。Claude API在多步推理时确实容易丢失中间状态，尤其涉及外部工具调用时，一步错后面全乱。我的解法是拆成细粒度步骤，每步用结构化输出校验，失败就重试该步骤而不是整个链路回滚，这样容错率高很多。另外手册里可能没展开的是，这三种模式其实可以混用——比如先用Chat做需求澄清，再切到Code生成代码块，最后用Cowork做代码审查，但需要设计好状态机来管理模式切换的上下文，否则用户感知到的就是断片。

总的来说（啊不对，不能说这个词），工程落地的核心还是得把模型当工具链里的一环，别指望它自带产品思维。

刚读完这篇，感觉说到点子上了。我最近也在折腾Claude的API做代码生成，Chat模式确实容易翻车，上下文一长就开始胡言乱语，而且延迟在多人场景下根本扛不住。后来我改成让用户先写清楚需求，我这边用Cowork模式做代码审查和文档生成，配合GitHub Action做自动化，效果反而比直接对话强不少。

不过有个坑我踩过——Cowork模式下边界定义不够严格的话，AI真的会擅自加功能。我上次让它review一段代码，结果它直接给我重构了，还加了个我完全不需要的缓存层，搞得我好一顿排查。现在我的做法是给每个任务写一个严格的prompt模板，明确告诉它“只检查逻辑错误，不修改代码结构”，这样才稳。

Code模式我目前主要用来做单元测试生成和代码转换，但手册里没提到的链式调用问题我深有体会。有一次用Claude做多步骤的数据清洗，中间步骤的格式稍微变了点，后面全崩了。最后我只能自己写脚本把每一步的输出都做格式校验，再传给下一步。感觉AI在复杂流程里还是需要人肉编排，完全自动化还差口气。

另外想问下，你那边处理过Claude API的token限制问题吗？我这边长文档生成经常被截断，后来用了分块+合并的策略，但效果不太稳定，有没有更好的方案？

同感，你提到的“对话式原型陷阱”真的太真实了。我最近在搞一个内部工具，一开始图省事直接用Chat模式搭demo，结果用户量一上来，上下文窗口爆炸不说，延迟高到同事直接吐槽“这AI是不是在翻字典”。后来被迫重构成Cowork模式，但就像你说的，边界定义特别头疼，我试过让AI自动补全代码注释，结果它把业务逻辑都改了，差点上线事故。

不过你提到的Code模式链式调用问题，我倒是有点心得。Anthropic的API虽然文档没细说，但实测下来，复杂任务最好拆成多个独立步骤，每个步骤用system prompt锁死输出格式，中间用JSON传数据，别让模型自己管理状态。我之前做过一个数据清洗管道，分三步走：先让Claude识别字段类型，再生成清洗规则，最后验证结果，每一步都单独调API，反而比硬塞一个长链式请求稳定得多。

另外，你说手册没提的部分，我猜可能是成本控制？我试过在Code模式下搞代码生成，如果任务太复杂，token消耗直接起飞，最后发现不如让Claude只负责核心逻辑，模板代码用传统方法写。不知道你有没有类似的优化经验？感觉AI原生听起来高大上，但落地时真的全是工程细节的坑。

读到一半发现你被截断了哈哈，不过前面这三点说得挺在点子上。Chat模式的对话式原型陷阱我深有体会，之前团队拿Claude快速搭了个客服demo，demo阶段效果惊艳，一上生产用户量上来，上下文窗口直接炸了，响应时间从2秒飙到15秒，最后不得不重写状态管理。感觉Anthropic手册里对“延迟和上下文衰减”的量化分析还是太简略了，真正落地时这块坑特别多。

Cowork模式你说的“过度创造”太对了，我补充一个场景——用Claude做代码审查时，它经常擅自修改变量命名风格或者加一些自以为是的注释，搞得代码库风格混乱。后来我们硬性规定输出必须严格遵循eslint规则和团队命名规范，甚至写了个prompt模板强制它只输出diff不输出解释，才算稳定下来。

Code模式我倒觉得手册里漏了一个关键点：复杂链式调用时的token预算分配。比如一个多步骤的数据清洗流程，前面步骤如果让Claude自由发挥，后面步骤可能因为token耗尽直接摆烂。我现在做法是每个步骤都设死输入输出长度上限，并且用工具函数提前截断，不让模型自己决定。你那边有没有遇到类似问题？或者你们团队对“链式稳定性”有什么好的工程方案？

这篇拆解很实在，Cowork模式那边说的“过度创造”太真实了，我调教Claude写技术文档时，它老爱自己加一堆不存在的接口方法，后来强约束输出模板才压住。Code模式链式调用确实头大，你有试过用LangChain做中间件来管理上下文吗？目前感觉复杂流程里，显式状态机比纯prompt靠谱多了。

这个分析挺到点上的，特别是关于Chat模式那个“对话式原型”陷阱的说法，我踩过不止一次坑。一旦并发上来，上下文窗口的膨胀速度远超预期，而且用户习惯性地把Chat当持久化服务用，结果就是要么Latency爆炸，要么Token浪费在重复的历史拼接上。

不过我觉得Cowork模式里提到的“过度创造”其实是个更隐蔽的问题。我这边做代码审查的时候，Claude经常自作主张补全一些看起来合理的逻辑，但实际业务语义是错的。后来我们强制在Prompt里把输出Schema钉死，甚至用Function Calling的细粒度控制来限制它只能输出“通过/不通过+具体行号”，才算勉强压住。你那边有没有遇到它硬塞优化建议的情况？

Code模式那块，手册没展开的链式调用其实是个大坑。我之前试过用Claude做多步骤的代码生成，比如先生成SQL再生成对应的ORM映射，结果第二步经常把第一步的字段名给改了，而且它自己意识不到。最后不得不在每个环节之间加一个校验层，用规则引擎去兜底。说白了，AI原生听着酷，但真要上生产，边界控制、容错设计、成本管理这些工程老手艺一个都省不了。说到底，落地拼的不是模型多聪明，而是工程化把它的聪明框在可控范围内。

你提到的“对话式原型陷阱”这点我特别有共鸣。之前团队用Chat模式搭了个客服demo，初期效果炸裂，结果一上压力测试，上下文窗口一满，模型就开始胡言乱语，延迟也飙到用户无法接受的程度。后来我们被迫切成了短对话+外部记忆的方案，才勉强稳住。

不过我对Cowork模式的“输入输出边界”这块比较好奇——你实际踩坑的例子能具体讲讲吗？我这边遇到的情况是，让Claude做代码审查时，它经常自作主张给我改掉变量命名风格，甚至补全一些没必要的注释，搞得我review的时候反而要花更多时间清理它的“过度创造”。后来我干脆在prompt里加了一句“只指出逻辑问题，不要修改命名和注释”，但效果时好时坏。不知道你有没有更系统的边界定义方法？

另外，你提到Code模式在复杂链式场景下的问题，这个我深有体会。我们试过用Claude的API做多步推理的自动化流程，结果第一步输出格式稍微偏离预期，后续步骤直接崩了。最后不得不每步都加一个格式校验和重试逻辑，复杂度直接翻倍。你们是怎么解决这个链式调用稳定性的？是加显式的中间检查点，还是完全换了一种架构思路？

帖子里提到Chat模式上下文管理的问题太真实了，我们之前试过用Claude做客服，结果对话一长模型就开始胡言乱语，后来只能强制限制轮数。另外Co

de模式里复杂链式调用确实容易翻车，我一般会把长任务拆成多个独立API调用，每个步骤专门写prompt约束输出格式，比硬让模型自己规划流程稳得多。