有个朋友转给我一条评价，问我说得准不准。原话是这样的：“opencode确实可以实现简单的项目开发，从1分到50分可以做到，从50分到100分，每增加1分难度都是指数级的增加，因为细节会增加很多，并且每个细节都是整体的一部分。”

我盯着这段话看了很久——一个人要是没被AI写代码坑过，根本说不出“每个细节都是整体的一部分”这句话。先交代一下我自己的背景，免得大家不知道我的立场。我是做后端开发的，过去大半年把opencode这类终端型AI编程agent当成日常工具在用：从写运维脚本，到给公司老项目加新模块，再到拿它从零搭过两个完整Demo，拢共跑了三四十个大小任务。所以看到这个评价，我的第一反应是：方向对了，结论也接近，但“50分之前很轻松”这个说法，太乐观了。

这篇文章不打算做工具评测，也不想复述官方文档。我想做的，就是围绕这句话，用我实际跑过的项目、踩过的坑、改过的代码，把一个更接近真实情况的结论交给你。

1. 先给结论：这个评价抓到一半真相，“50分拐点”却说得太乐观

1.1 方向对在哪

这句评价里最值钱的部分，其实是最后那半句——“每个细节都是整体的一部分”。这不是写代码的人随口说说的感悟，这是所有AI编程工具在大型项目上失效的根源，后面我会用一次真实翻车来拆它。前半句“可以实现简单的项目开发”，也基本成立。opencode这种终端型AI agent，处理“需求明确、边界清晰、单模块、无历史包袱”的任务时，确实有碾压级的效率。我拿它写过一批脚本工具、接口脚手架、一次性数据处理程序，平均每个任务从描述到跑通不到半小时，这个效率放在以前不可想象。

“从1分到50分可以做到”这个判断，从能力上限来说没错，但它忽略了一个关键事实：它把“做到”理解成了“AI独立做到”。实际上从30分往上，就已经是“你扶着方向盘，AI帮你踩油门”的状态了。

1.2 偏差在哪

我实测下来，真实的难度曲线不是“前50分平缓、后50分陡增”，而是一个更早出现的拐点：

为什么会这样？因为项目复杂度这个东西，从来不是均匀增长的。一个项目从20分涨到30分，可能就是从“单文件脚本”变成“多文件工程”；从40分涨到50分，可能就是从“demo”变成“要处理边界情况的真实功能”。每跨过一个档次，AI需要同时盯住的变量数量就翻一倍，而它的“工作记忆”并不会跟着翻倍。所以严格来说，指数级增长的不是“难度”，而是“AI理解上下文的需求量”和“你验证它的成本”。

2. 三个实测项目：用真实代码把opencode的能力边界画出来

这一节我不讲理论，直接上项目。三个项目分别落在不同的复杂度区间，都是我这大半年真实跑过的，有代码有过程。

2.1 入门级：一个运维脚本，惊艳但埋了个雷

项目内容是写一个Python脚本，批量读取几十个Excel文件，按照公司内部的规则做数据清洗，最后汇总输出一份统计报表。需求非常明确，数据格式有模板，输出字段有固定要求。我把需求用日常大白话写给它，它大概花了10分钟一次性给出了完整脚本。

说实话，第一次拿到能直接跑通的脚本，我是有点被震到的。但你猜怎么着？我随手翻了一下统计口径，发现它把“按客户维度汇总”和“按产品维度汇总”两列的输出搞反了——它读懂了Excel，但没读懂业务报表里“列名”背后的含义。我改一行代码就修好了，不影响整体评价，但这件事给我提了个醒：它能写代码，但它不负责理解“业务隐规则”。

这是典型的0到20分区间任务。结论是：效率极高，小错误需要人工复核，整体可用度大概在90%以上。

2.2 进阶级：一个完整Web应用，骨架能跑，逻辑互相打架

第二个项目是我自己练手用的：一个带前后端的任务管理Web应用，后端用FastAPI，前端用Vue，数据库八张表，包含用户登录、任务分配、状态流转、简单的仪表盘统计。我心想，这种“教科书级”项目，opencode就算不全会，至少骨架应该能撑起来。

结果也确实是撑起来了。它一口气生成了项目结构、建表SQL、API路由、前端页面骨架，整个过程大概两个多小时，中间我让它改了三四轮需求。第一次跑起来的时候，应用能登录、能建任务、能改状态，我当时甚至觉得“评价里的人说得有点保守了”。

但这种“能跑”经不起推敲。我细测之后发现，列表页的筛选逻辑和详情的权限校验是矛盾的：列表页能看到所有人创建的任务，但点进去之后接口会报403。更麻烦的是，修改任务状态之后，仪表盘的统计数字不会刷新，因为它用了两套完全不同的查询逻辑，而opencode根本没意识到这两个模块之间的关联。我花了两晚修这些跨模块问题，越修越乱——它改好了权限，又把筛选条件弄丢了；我让它修仪表盘，它顺手改坏了另一个接口的返回结构。最后我把涉及关联的几个模块全部重写，才算踏实。

这个项目的复杂度大概在40到55分之间。结论：它能搭骨架，但骨架里的“骨头连接处”全是脆的，跨模块逻辑的一致性需要人大量介入。

2.3 复杂级：给老项目加模块，产出几乎全改

第三个项目是真实的商业项目：给一个运行中的订单系统加售后流程模块，涉及4个微服务，需要新增数据库表、改订单状态机、加消息队列消费逻辑，还要保证已有的报表服务不受影响。

这个项目我本来就没打算让opencode独立完成，只是想让它在局部帮帮忙。结果它交出来的代码，我几乎全部手工重写了一遍。最大的问题不是语法错误，而是它完全没有“存量系统约束”的概念。它在订单服务里新增了一个字段，改接口的时候根本没意识到，另一个服务里有个消费者还在解析旧的订单消息格式。字段一加，消息体变了，消费端直接解析失败，整个链路在测试环境就炸了。

这就是那句“细节是整体的一部分”——对于它来说，改动是局部的；对于系统来说，改动是全身的。我最后只留下它生成的数据库迁移脚本和几个工具函数，其余全部自己来。

2.4 一张表看清边界

三个项目测下来，我的感受可以浓缩成一张表：

所以回到那句话本身：如果“从1分到50分”指的是“AI能做出一堆能跑的东西”，那确实没错。但如果指的是“AI能做出让用户敢直接交付的东西”，那50分的门槛至少提前到35到40分，后面的指数级增长也来得比想象中更快。

3. 指数级难度的真正来源：四个比“细节变多”更本质的原因

很多人把指数级难度归结为“细节变多”，这话听着对，但太笼统了。细节变多是结果，不是原因。我做了这么多对比测试之后，认为背后真正推着难度往上翻的，是下面四件事。

3.1 上下文窗口是第一个天花板

AI agent和你聊天一样，工作记忆有限。opencode这类工具号称支持几十万token的上下文，但“支持”和“好用”是两回事。一个真实的中型项目，算上需求说明、建表脚本、接口定义、前后端代码、异常处理约定，动辄几十个文件，几千行代码。上下文一旦被塞满，它会开始“选择性遗忘”——最典型的症状是，它会在第40轮对话时重新定义一个第5轮已经定义过的函数名，或者把一个已经废弃的表结构当成最新版本来处理。

我后来做过一个测试：同一个中等规模项目，我一边开着完整上下文让它改，一边手动清空上下文只让它改单个文件。结果后者反而更少犯低级错误。这说明什么？说明它一旦被大量上下文“撑爆”，全局一致性和局部正确性就开始打架，而它压不住这种冲突。

3.2 跨文件依赖链：改一处、断三处

你改A文件里的一个函数签名，B文件里有个调用方会跟着崩，C文件里的测试用例需要同步更新，D文件里的文档示例可能也引用了老写法。这种依赖链在真实工程里无处不在，但它的传播路径往往藏在代码的“语义”里，而不是“语法”里——lint工具查不出来，搜索引擎搜不全，只能靠人对系统整体架构的理解去追踪。

AI agent天然缺这个“整体理解”。它修改一个文件时，能看到的是这个文件本身和它能联想到的相关引用；当文件数量超过某个规模，它内部的“关联检索”就开始失效。这不是模型推理能力不够，而是它没有一个驻留在脑子里的全局架构图，每次都要靠现场翻代码去猜，猜的效率必然随规模指数衰减。

3.3 验证成本膨胀：AI写一行，你验三行

这是最容易被忽略的一点，也是我觉得最要命的一点。项目复杂度越高，AI写的每一段代码，你需要花在“验证它写没写对”上的时间就越长。单人脚本，你扫一眼就能验证；跨服务改动的代码，你得看接口文档、跑起服务、造数据、走链路、查日志。我把这个成本记过一周的账：AI节省的编码时间，大约有60%被额外增加的验证时间吃掉了。

45分之后更夸张——很多时候你验证它的代码，比你直接自己写还慢。因为自己写的时候你脑子里带着完整的设计上下文，验收AI改动的代码时，你还得先花时间理解它为什么这么改。所以指数级增长的，严格说是“你的时间黑洞”，而不单纯是AI的“能力瓶颈”。

3.4 需求的隐性约束：AI擅长翻译，不擅长猜

简单项目之所以看起来简单，是因为你可以把需求描述清楚。真实世界的复杂项目，一大半需求细节根本没写进文档，它们活在产品经理的脑子里，活在老员工的习惯里，活在代码的历史包袱里。比如“这个字段不能直接删，因为下游有个报表依赖它”“这个接口不能改超时时间，因为调用方是第三方支付”。

这些“隐性约束”对人是常识，对AI是盲区。你费劲把它们逐条喂给AI之后，项目规模一大，它还记不住。于是它就会自由发挥，而每一次自由发挥，在复杂系统里都像抛一个回旋镖，最后总能飞回来砸到你脑袋上。所以我常说，AI agent的强项是“翻译明确”，弱项是“补充未说明”——而50分以后的项目，恰恰是“未说明的东西”占了大部分。

4. “每个细节都是整体的一部分”：用一次加字段的翻车把这句拆透

前面几节是宏观分析，这一节我来个微观解剖。评价里的那句话，我用一次真实翻车现场把它彻底拆开，你看完就知道它到底在说什么了。

4.1 为什么AI像拼乐高，而大项目是现浇混凝土

一个类比：简单项目像是拼乐高，模块和模块之间接口清晰，拆开拼上互不干扰，AI零件思维完全适用。但一个跑了几年的大型软件系统，更像现浇混凝土的框架结构——钢筋、管线、混凝土是浇铸在一起的，你看着只想动一根钢筋，实际上牵动着整面墙的受力。项目越大，“一个细节”牵连的“整体”就越大，这句话的字面意思就这么直白。

AI的问题是，它天生习惯“乐高思维”，因为它被训练时看到的代码是“文件级”的，一个文件一个文件分开生成。当文件之间埋着隐式约定时，它就看不到那面混凝土墙里的钢筋是怎么连通的。

4.2 一个字段引发的四连炸

具体经过是这样的。我让opencode给订单表加一个“优惠金额”字段。听起来是个小改动，对吧？它做得很完整：加了数据库字段，写了迁移脚本，改了订单服务的接口，在前端表单里加了输入框，还贴心地处理了空值兼容。从单个改动看，每件事都挑不出毛病。

但我接手检查时，发现了四连炸：

第一炸：报表服务里有一段历史计算逻辑，用的SQL是SUM(amount - discount_old)。新增“优惠金额”字段后，报表团队同事看到表结构变化，顺手把这段SQL改成了SUM(amount - discount_new)——但他没做线上数据回填，历史订单的discount_new全是NULL。这条线上的平均值直接算错。

第二炸：订单导出服务直接把ORM模型序列化后丢给前端。加字段不会崩，但导出Excel里凭空多了一列“优惠金额”，而这项业务根本没有审批流程，等于把未确认数据暴露给了客户。

第三炸：另一个订阅服务在订单状态变更后会消费消息。我把订单对象加了个字段，消息体格式变了，但消费端没同步升级。测试环境立刻出现反序列化异常，整个订单状态流转的链路被切断。

第四炸：数据分析定时任务跑的是原生SQL，引用旧字段名。我在opencode生成的迁移脚本里只改了新字段名，没处理旧字段的兼容逻辑，导致定时任务在凌晨两点准时失败，第二天早上我是在值班群里看到告警才知道的。

这四个“细节”，没有一个在opencode当初的视野里。它在改字段时看不到报表SQL，看不到导出服务，看不到消息消费端，看不到定时任务——但对整个订单系统来说，这些全部是“整体的一部分”。它不是能力不够，是视野不够，而这恰恰是“指数级难度”最真实的投影：你加一个字段，复杂度不是加1，而是加上“这个字段在这个系统里被多少个角落隐式消费”。

4.3 人为什么能管住细节：隐式全局图的差别

那你可能会问：为什么一个普通程序员反而能控制住这些细节？不是因为人记得住所有代码，而是因为人的脑子里有一张“隐式全局图”。我知道订单数据往哪里流，知道报表依赖哪张表，知道消息队列谁在消费，知道哪些代码“最好别乱动”。这张图不精确，但方向正确，它告诉我“改这个字段前，该去查哪几个文件”。

AI没有这张图。它的“图”只存在于当前上下文的文本里，项目一大，这张图就碎成一片一片。所以同样加一个字段，人花5分钟排查关联，AI花5分钟生成代码——然后你再花两小时排查它没看到的关联。这就是本文最开始那个评价里，所有论断成立的技术底层逻辑。

5. 把opencode用到70分的实战方法：配置、约束、验收

说完了问题，得给解法。我现在的态度不是“别用AI写代码”，而是“知道它几斤几两之后，学会怎么用”。下面这些方法是我踩了大量坑之后总结出来的，有效，且不复杂。

5.1 先做选型：什么项目才适合交给它

我先给自己设了一条简单粗暴的规则：

• 适合：单模块脚本、内部工具、Demo原型、代码生成类任务、重构辅助（让AI做纯机械的部分）、写测试用例、生成SQL和迁移脚本。
• 谨慎：中小型Web应用、跨模块功能，可以尝试但必须有人全程把关，且把关的人必须懂全链路。
• 不适合：老系统核心链路改造、涉及资金/安全/强一致性的业务逻辑、跨多团队协作的模块。这种任务让AI打底，后面返工成本会比你自己写高得多。

这条规则不复杂，但能过滤掉80%的坑。

5.2 像管实习生一样管理任务

我把和opencode协作的方式总结成“管实习生”模式，三句话就够了：

第一，拆任务。一次只让它做一件事，不要在一个对话里同时丢给它“改A、加B、顺便优化C”三个需求。多任务并发时，它的上下文和注意力会迅速发散，互相污染。

第二，立规矩。在项目说明里明确告诉它“禁止做的事”，比如“不得修改消息队列中已有的字段格式”“不得改动报表服务的历史SQL”等等。这个环节叫“约束注入”，虽然不完美，但能显著降低灾难概率。

第三，要计划。每次让它动手前，先让它输出一份15分钟的设计方案，包含三件事：将会修改哪些文件、为什么要修改、预估会影响哪些调用方。它写这个计划的过程，就是逼它建立全局心智的过程。我实测下来，花在这15分钟上的时间，至少能省下两小时的返工时间。

5.3 值得折腾的配置：skills、记忆、项目文档

opencode之所以在工具类里显得性价比高，很大程度上因为它是可配置的。具体配置我建议折腾三样。

一是项目规范沉淀。opencode有skills机制，本质上就是项目级/用户级的功能定义，可以把命名规范、错误处理约定、代码风格、数据库变更流程写成可复用的规则文件。这比我每次口头提醒它要靠谱得多。这个机制和Claude Code的skills本质是一类东西，网上有很全的案例，照着项目需要去写就行。

二是记忆组件。opencode支持mem0这类记忆系统，可以跨会话记住项目背景和偏好。我个人的体会是：记忆系统适合给AI积累“这个项目的隐性约定”，比如“这个系统里订单金额单位是分，不是元”“测试环境数据库不要跑迁移”。这类信息喂一次，之后它能少犯很多低级错误。它同样有局限性，记忆再多，也替代不了架构图。

三是项目文档投喂。opencode作为终端agent，可以直接让它读取项目里的README、架构说明、接口文档。我现在的习惯是，在项目根目录维护一份精简的ARCHITECTURE.md，把模块关系、数据流方向、关键依赖写清楚，让每次协作用的AI都有这份全局图可查。这一步对“50分以后的项目”几乎是救命级别的。

5.4 交付前的五步验收清单

不管AI说得多么言之凿凿，我交付前一定会跑完下面五步，缺一不可：

1. 全量跑测试，至少保证测试命令是绿的。没有测试的项目，这一条升级为手动走一遍核心链路。
2. 对改动做全量diff review。不只看单个文件，重点看文件的引入关系是否闭环，改动是否只影响了预期模块。
3. 用代码检索工具查关键词。比如改了订单字段，就全局搜一下这个字段在其他文件里的引用，这是对AI“视野缺失”的机械补偿。
4. 造边界数据验证。空值、超长、并发请求，至少设计三种异常输入，看它生成的代码是否能兜住。
5. 让AI自己评审自己的改动。直接问它“你对这次改动做一次code review，指出可能影响现有功能的地方”，很多问题能自己暴露出来。

这套流程不复杂，但能让你从“被AI带节奏”变成“掌控节奏”。

5.5 用量和成本控制

最后提醒一个很现实的问题：指数级增加的不只是难度，还有token消耗。复杂项目的来回修改，经常几十万token一顿烧，成本涨起来比代码进度快得多。我的做法是“先用小模型或免费额度跑通方案，确定方向后再用更高质量的模型重跑”，不要一上来满配。另外，如果遇到“上下文膨胀导致AI反复犯蠢”的迹象，果断开新会话、精简背景、分批推进，别恋战。开源工具的好处是模型可以换，成本可以控，但控制权始终要握在自己手里。

尾声：一句个人的真实体会

这套方法论用了大半年，我最大的转变是：不再指望AI替我“从1分干到100分”，而是把它当成一个强力的“外骨骼”——我自己承担架构判断、全局记忆和终验责任，它负责把想法变成代码、把机械劳动拉满。实践下来，50到70分这个区间，它是超级帮手；超过这个区间，守住边界，别把验收员的工作硬塞给一个“实习生”。

最后再分享一个小技巧：我给opencode预设过一个“虚拟同事”人设——每次动手前先写计划、列影响清单、主动标注风险点。表面上这只是多一步操作，实际等于强制它把碎片化的项目认知整合成一张可见的图。这个习惯帮我避掉了至少一半的“AI野路子改动”。照着试一次，你会回来谢我的。