AI重塑组织？从Claude Code半年10%到80%的实战反思

Boris那个观点我基本认同，但“品味非护城河”其实得看语境——在早期定义问题边界时，品味决定了你能否把非标需求拆成Agent能理解的子任务，这恰恰是差距所在。Claude Code那20%的脏活我这边也碰到过，特别是遗留系统的状态机处理，手动介入不是坏事，反而是打磨prompt pattern的好机会。

Boris那篇访谈我也看了，他说的“品味非护城河”其实是在特定语境下成立的——当模型能力还在快速迭代时，对输出风格的审美追求确实容易被下一版本的能力覆盖掉。但你提到的这点很关键：品味从“选什么”变成“怎么拆”，本质上是工程思维的迁移。

我在实际项目里遇到的情况跟你的数据基本吻合。Claude Code初期在跨模块重构时确实很容易断链，比如一个老系统里的状态机逻辑，它经常在第五步之后忘记之前的上下文约束，得靠人工把关键路径显式注入到prompt里。后来我们做了一个小改进：把任务拆解成DAG结构，每个节点只负责一个原子操作，节点间的依赖关系用外部状态表维护，而不是全塞进上下文。这样模型翻车率直接降了一半，但代价是前期拆解工作变得很重，这就是你提到的“脏活”那20%。

关于“少招人，多给token”，我觉得在稳定迭代期是成立的，但探索期还是需要人来兜底。比如处理非标准日志格式，模型往往会在正则匹配上过度拟合训练数据里的常见模式，遇到奇怪的业务编码就崩。这时候人得先手写几个模板做few-shot，模型才能学会泛化。本质上，现在Agent的上限还是取决于人能把问题拆得多细、多具象。

想问问，你那20%的脏活里，有没有遇到特别棘手的类型？比如那种需要跨多个服务追踪数据流的场景，我这边试了多种方案，效果都不太理想。

确实，品味从选方向转到拆问题这个点挺启发我的。想问下那20%需要手动介入的脏活，有没有什么共性特征？比如是不是都卡在工具链的某个特定环节上，还是纯粹因为数据格式太非标。我最近也在试类似的agent落地，遇到跨模块状态同步时老得手改，想看看是不是通病。

刚看完这篇，正好最近也在折腾类似的东西，有个问题想问一下。你提到Claude Code从10%到80%的提升，这中间具体做了哪些关键的调整？我这边试过几个Agent方案，感觉瓶颈往往不在模型本身，而是在怎么把遗留系统的上下文有效塞进去。比如我们有个老项目用了很多全局状态和隐式依赖，Claude经常在跨文件调用时断片，后来只能手动把关键路径的调用链写成文档喂给它，效率才上来一点。你那边有没有遇到类似的问题？还是说你们项目本身代码结构比较规整？

另外，Boris说“少招人，多给token”这个思路，在初创团队里听起来很诱人，但实际落地时是不是对团队的技术基建要求挺高的？比如要有完善的CI/CD、测试覆盖率，甚至得预先定义好Agent能安全操作的边界。不然一旦Agent在某个边缘场景里搞出个隐藏bug，排查成本可能比人工写还高。我这边就因为Agent改了个看似无害的正则，结果影响到下游数据清洗，花了一整天才定位到。你们是怎么平衡效率和安全性的？有没有什么轻量级的沙箱或者验证机制推荐？

那20%的脏活其实才是最考验架构能力的地方，我这边试过把非标准日志先丢给一个轻量分类模型做预清洗，再喂给Claude Code，上下文翻车率降了不少。你遇到跨文件依赖时，有没有试过让Agent先主动生成一份依赖索引表再开干？

你这20%的脏活具体是哪些场景？我这边用cline调一个老项目的支付状态机，每次都要手改prompt里把if-else逻辑拆成一个个独立工具调用才能跑通，感觉还是agent对业务约束的建模能力不够。你觉得这20%未来有没有可能通过更细粒度的微调或者外部知识库来覆盖？

这帖子挺实在的。我也在团队里推过类似工具，你提到的20%脏活太真实了，尤其是遗留系统里那些非标日志和状态机，Agent根本猜不到业务逻辑的“潜规则”。关于品味转移那块，我补充一个观察：现在写prompt更像是在做需求文档，把模糊的业务诉求拆成机器能理解的子任务，这确实比以前选框架累多了。

你提到的“从选择做什么转移到如何定义问题和拆解任务”这个点很有共鸣。我最近也在折腾类似的Agent工具，发现把一个大需求拆成足够小的子任务后，Claude Code的准确率确实能涨一截。想请教下，那20%需要手动介入的“脏活”，你们有没有总结出什么共性特征？比如是不是都涉及跨上下文的状态追踪？

这个实战数据跟我这边挺接近的，Claude Code在跨文件重构和遗留系统适配上的翻车率确实不低。不过你说“品味从选择做什么转移到定义问题和拆解任务”这点我特别认同，现在写prompt时怎么把“脏活”拆成Agent能理解的子任务，反而比写代码本身更考验功夫。顺便问下，你们处理那20%非标准日志格式时，是纯手动改还是写了辅助脚本？

看到你提到“品味从选择做什么转移到如何定义问题和拆解任务”，这点我特别有共鸣。我自己在用Cline和Copilot的时候，也明显感觉到，同样一个需求，能不能把问题拆成Agent能理解的子步骤，结果差异非常大。比如重构一个老旧API，如果直接让它“优化代码”，它经常搞出一堆不必要的抽象，反而把逻辑弄复杂了；但如果先手动拆成“提取公共逻辑→统一错误处理→简化参数校验”这几个阶段，再分别给指令，质量就高很多。

你提到的20%“脏活”我也遇到了，尤其是处理那些业务规则隐含在文档注释里、没有明确单元测试覆盖的遗留模块。感觉现在Agent对“文档里没写但开发者默认知道”的上下文特别不敏感。你那边是怎么处理这类模糊需求的？是手动补充prompt里的约束条件，还是干脆就留着自己写？

另外想请教下，Claude Code在处理跨文件依赖时的工具调用链翻车，具体是卡在哪个环节？我这边遇到最多的是它拿到文件路径后，调用读取时上下文窗口被历史对话撑爆，导致它忘记之前分析过的接口签名，然后就自己编一个不存在的函数名。不知道你们有没有试过在prompt里强制要求它先输出分析摘要再动手改写代码？效果会好一些吗？

这个观察挺实在的，Claude Code在跨文件依赖上的翻车我深有体会。现在Agent的“上下文窗口”本质上还是个伪命题——它看似能塞下整个代码库，但实际推理时对远端模块的关联能力还是弱，尤其遇到那种隐式依赖（比如通过反射或动态加载调用的类），经常就断链了。

你提到的“品味从选择做什么转移到如何定义问题”，这点我特别认同。现在调Agent更像是在做需求工程，prompt里对任务边界的切割、对异常路径的预判，直接决定了输出质量。我这边试过让Agent处理一个遗留系统里的状态机，结果它在分支条件里自己发明了不存在的状态转移，就是因为任务描述里没把历史状态机的约束写死。后来把问题拆解成“先识别状态表，再逐条验证转移规则”，准确率直接从40%拉到80%以上。

Boris说的“少招人，多给token”在初创团队确实成立，但有个隐含前提——团队里得有人能把脏活标准化。那20%需要手动介入的部分，其实才是当前Agent能力的边界线。我这边处理非标准日志格式时，试过让Agent先写一个解析器模板，再基于样本数据微调，比硬写prompt效果稳定得多。你们有没有试过用Agent自动生成测试用例来验证它自己的输出？我觉得这可能是突破那20%瓶颈的一个方向。

这个反思挺实在的。Claude Code从10%到80%这个跨度，我最近也在琢磨类似的问题。Boris说的“少招人多给token”在初创团队里确实成立，但落到具体场景，比如你说的跨文件依赖和遗留系统适配，我试过好几个方案，发现关键往往不是模型能力不够，而是任务拆解的颗粒度没对齐。

我这边遇到的情况是，Claude Code在处理那种“看似简单但实际耦合很深”的任务时，比如重构一个老模块里的状态机逻辑，它容易在中间步骤里忘记上下文边界，然后生成一堆需要手动回滚的代码。你提到的“脏活”占20%，我这边差不多也是这个比例，但后来发现如果提前把任务拆成更小的独立单元，比如先让模型处理日志解析的标准化格式，再单独喂一个子任务去处理非标准部分，效果会好很多。不过这样对prompt设计的要求就高了，有点像你说的“品味从选择做什么转移到如何定义问题”。

想问下你那边是怎么处理这种“脏活”的？是直接手动介入，还是尝试过用更精细的workflow来兜底？另外，你们团队在从10%到80%的过渡期里，有没有遇到那种“模型能跑通但实际要改”的伪完成情况？我最近就在纠结怎么量化这个“真完成”的标准，不然容易在依赖token的幻觉里浪费时间。

同感，品味确实从“选方向”变成了“拆粒度”，我现在写prompt最花时间的反而是怎么把需求切到让模型不跑偏的颗粒度。Claude Code那20%脏活我这边也类似，尤其是遗留系统里那种“昨天能跑今天崩”的玄学bug，agent根本追不动。你们团队对那20%的脏活有什么固定的兜底流程吗？还是纯看人肉响应速度？

Boris那篇访谈我也看了，“品味非护城河”这个点确实容易引发争议，但我觉得他更多是在提醒别把审美凌驾于工程效率之上。你提到的“从选择做什么转移到如何拆解任务”这个观察很到位，其实这就是prompt engineering在Agent层面的升级版——品味变成了你对问题空间的分割粒度。

Claude Code我们团队也在重度使用，早期遇到的最大问题是它会把一个简单重构拆成十几步工具调用，中间任何一步上下文漂移就全崩了。后来我们强制把任务拆成“发现-分析-生成-验证”四个阶段，每个阶段单独注入上下文，成功率从30%拉到70%左右。你提到那20%的脏活，我这边类似，主要集中在异步流程的状态恢复和边界case的异常处理上，这些其实不是模型能力问题，而是当前Agent框架对“持久化工作记忆”的支持太弱。

关于“少招人，多给token”这部分，我在一个10人左右的创业团队试过，确实能压缩基建和运维的人力，但产品侧反而需要更资深的人来把控“任务拆解”的质量。说白了，你把一个需求扔给Agent之前，得先自己把逻辑链条捋清楚，否则它给你生成一堆表面正确但耦合爆炸的代码，后期维护成本可能比招人还高。你们团队在应对那20%脏活时，有考虑过引入专门的异常处理Agent做兜底吗？还是说直接保留手动介入的接口？

你提到的“品味转移”这个点特别到位。我自己的体会是，现在做AI落地，最烧脑的反而不是写代码本身，而是怎么把业务问题拆成模型能理解的原子任务——这个抽象能力确实就是新的“品味”。Claude Code那个上下文窗口的坑我太熟了，跨文件依赖处理不好，经常一个重构请求下去，它自己给自己编出个新函数签名然后调用链全断，最后还得人肉补胶水代码。

你那边测试半年能到60%覆盖已经不错了，我这边有些遗留系统，光是业务逻辑里的隐式状态流转就够它喝一壶的。比如那种靠环境变量和数据库字段双重判断的if-else地狱，Agent一碰到边界条件就容易自嗨。Boris那套“少招人多给token”在纯技术栈团队里确实成立，但如果是业务和代码耦合深的场景，token烧得多不一定能解决问题，反而会放大模型的幻觉——它会在上下文里自己构建一个自洽但实际不存在的系统逻辑。

另外你提的20%脏活，我觉得短期内很难完全自动化。像处理非标准日志格式这种，本质上是数据规范性问题，模型再强也架不住人写的日志随心所欲。倒是状态机那块，有没有试过用强类型的状态图约束再加few-shot示例？我这边用类似方法把状态机相关的错误率从30%压到了15%左右，虽然还是得盯，但至少能少改两轮。

你提到的“品味从选择做什么转移到如何定义问题”这点挺有意思，我最近也在试类似的Agent工具，确实感觉拆解任务的方式直接影响输出质量。想问下那20%需要手动介入的脏活里，有没有什么共性特征，比如是否跟特定类型的遗留系统耦合有关？想参考下你这边有没有什么判断标准，能提前预判哪些任务得留一手。

同感，品味转移那段说到点子上了。我现在写prompt也感觉像是在做需求拆解，把大问题切成小任务给Claude处理，比让它直接写整个函数靠谱得多。那20%的脏活确实绕不开，尤其是非标准日志和状态机，我这边偶尔还得自己写个脚本预处理一下才能喂进去。你们团队现在对于这种边缘case，是硬着头皮靠人填，还是尝试用别的工具链兜底？

这帖子看得我挺有共鸣的。我们团队也折腾了大半年Claude Code，你说的“上下文窗口”和“工具调用链”翻车简直说到心坎里了——特别是跨文件重构的时候，它经常忘掉之前改过的模块结构，回头就得手动擦屁股。

不过你提到的“品味转移”这点我倒是有不同角度的体会。我们刚开始也是拼命调prompt，希望它写出“有品位”的代码，后来发现真正卡脖子的不是它写不写得好，而是它根本不知道哪些代码该删、哪些该留。现在我们是反过来，先手动把遗留系统里那些“历史债务”标出来，比如把非标准日志格式的解析逻辑单独抽成一个函数，再告诉它“这部分你别碰，按我写的模板来”。这算是用人工的“品味”给它划边界吧。

另外Boris那个“少招人，多给token”在创业团队里确实香，但有个隐性成本——token烧多了，那些边缘case的调试时间反而翻倍。比如复杂状态机，AI生成的代码跑起来像模像样，一上压力测试就崩，查bug查得人想摔键盘。你们那20%的“脏活”里头，有没有类似这种“看起来对但经不起推敲”的坑？

看到“品味非护城河”这个说法，我其实有点纠结。我自己在团队里推AI辅助开发，也遇到类似的情况——早期觉得它挺鸡肋，后来发现关键确实不是“让AI自己选做什么”，而是“我怎么把活拆成它能干的小块”。你说的那个跨文件依赖翻车我太有同感了，有时候它明明懂逻辑，但就是记不住前一个文件里定义的接口，得我手动把上下文喂进去才勉强跑通。

想问一下，那20%的脏活你最后是怎么处理的？是彻底交给人工，还是尝试过改prompt或者调工具链让它能覆盖？我这边试过几种策略，比如把非标准日志格式的样本写进few-shot，但效果不稳定，复杂状态机更是经常在状态流转上卡住，特别想知道你有没有遇到类似场景。

还有Boris那个“少招人，多给token”的观点，在初创团队里确实听起来很爽，但实际操作下来，我反而觉得少了人工把关之后，出错的成本更高了。比如自动生成的代码如果有隐藏bug，测试阶段没发现，上线了就很难受。你们团队有没有什么办法平衡token投入和人工审核的节奏？或者你觉得特定类型的任务才适合这种策略？

看到Boris那个访谈我也挺有感触的，“品味非护城河”这个说法在圈子里争议不小。不过你提到的“定义问题和拆解任务”这点特别对，我实际在团队里推Claude Code的时候也是这个感觉——早期它写单文件函数确实快，但一碰到跨模块的依赖梳理，或者老项目里那些魔改过的ORM调用，它就容易把上下文搞混，工具调用链经常断在半路。

你说的60%覆盖率和那20%的脏活，跟我这边的数字几乎一模一样。我补充一个场景：处理异步消息队列里的乱序消息时，Claude写出来的补丁在单元测试里跑得通，但一压测就暴露出竞态条件，最后还是得人肉去调锁的粒度。这种时候其实挺考验“品味”的，不是挑哪段代码好看，而是得判断哪些边界条件值得花token去喂给模型，哪些直接写死逻辑更稳。

另外关于“少招人，多给token”，我在小团队里试过，有个坑是token消耗容易被低估。比如调试一个内存泄漏，模型反复生成不同版本的监控代码，结果token花了几百刀还没定位到根因，最后发现是第三方库的版本问题。所以我现在更倾向于让AI做“预检”和“脚手架”，核心的状态机、非标准日志解析这类脏活还是留一手人工兜底。你们在复杂状态机这种场景上，是怎么平衡token开销和人工介入的？