1. 为什么我把写作从 AI 手里抢了回来先说结论Claude、Codex/ChatGPT、Gemini 这几个工具我每天都在用而且用得很重。但它们的定位在我这里是编码研究助手不是写作代笔。这个边界我踩过坑之后才划清楚今天把整套思路和实操细节摊开讲。你如果正在纠结AI 到底能不能帮我写东西或者已经在用这几个模型写周报、写方案、写公众号那这篇内容就是给你看的。我会讲清楚三件事这几个模型在编码研究场景下为什么好用、在写作场景下为什么必须自己动脑、以及我实际怎么把两者拆开用。不管你是刚接触 Claude Code 的新手还是已经在折腾 Codex 接入、Gemini API 调用的老手都能从里面拿到能直接抄的东西。核心关键词先摆出来Claude、Codex、ChatGPT、Gemini、编码研究。这五个词贯穿全文但它们的出场方式不一样——前四个是工具最后一个是场景。我要论证的就是这四个工具在编码研究这个场景里是利器一旦越界到写作立刻变成钝刀。先讲一个我自己的真实经历。去年有段时间我图省事把一篇技术方案的初稿直接丢给模型生成结果交上去被合作方一眼看穿——不是文笔问题是逻辑链断裂。模型写出来的段落每一段单看都通顺连起来读就会发现它在原地打转前面说的和后面说的对不上论证的推进是假的。那次之后我就定了个规矩代码可以让 AI 写文字必须自己过脑子。这个规矩不是矫情是有技术原因的。下面我从工具选型、原理、实操三个层面拆开讲。2. 编码研究场景这四个模型到底强在哪2.1 Claude 在长上下文代码理解上的真实表现Claude 我用得最多的是它的长上下文能力。一个几千行的老项目我直接把关键文件贴进去让它做依赖梳理它能记住前面定义的结构体在后面分析调用链的时候不会张冠李戴。这一点在编码研究里太重要了——研究代码本质上是研究关系谁调用了谁、数据怎么流动、边界条件在哪。我实测下来Claude 在处理 10 万 token 级别的代码库摘要时对函数间引用关系的保持度明显好于另外两个。具体操作上我一般这么喂# 先把项目结构导出成文本树 find . -type f -name *.py | head -50 filelist.txt # 再把核心模块内容拼进去 cat core/*.py context.txt然后把context.txt整个丢给 Claude让它输出模块依赖图文字版。注意这里我不要它画图只要它用文字描述依赖关系因为文字描述我能自己核对图我反而不好验证。提示Claude 的长上下文虽然强但超过一定长度后它对中间部分的记忆会衰减。我的经验是把最关键的代码放在开头和结尾中间放次要的。2.2 Codex/ChatGPT 在代码生成与调试上的定位Codex 这条线现在基本都归到 ChatGPT 体系里了最强的场景是从零生成可运行代码和定位报错。我遇到cc switch local proxy failed while handling codex endpoint /responses这类报错的时候第一反应就是把完整错误栈贴给 ChatGPT让它给出排查路径。它的优势在于训练数据里代码占比极高对常见框架的 API 签名记得准。比如我让它写一个 FastAPI 的中间件它给的代码基本能直接跑不用大改。但这里有个坑它给的代码看起来对不等于真的对。我踩过好几次它调用的某个库函数在新版本里已经改了参数名代码能过语法检查但运行就崩。所以我的做法是ChatGPT 生成的代码必须过一遍本地测试。具体流程让它生成代码同时要求它标注每个外部依赖的版本本地建一个干净的虚拟环境按它标注的版本装依赖跑单元测试这套流程走下来能过滤掉八成以上的幻觉代码。2.3 Gemini 在算法研究与多模态代码场景的补充价值Gemini 我主要用在两个地方一是算法思路的横向对比二是带图表的代码理解。比如我有一张架构图想让它根据图生成对应的模块骨架代码Gemini 的多模态能力在这时候就派上用场了。另外adk kotlin 的 model 目前仅内置 gemini这个点也值得说——在某些特定技术栈里Gemini 是默认集成选项这时候用它反而比硬接别的模型省事。我实际配置过一版把 Gemini 作为默认推理后端代码补全的延迟比走外部 API 低不少。但 Gemini 有个明显短板它对中文技术语境的把握不如前两个。同样的需求我用中文描述它有时候会理解偏。所以用 Gemini 做编码研究我建议用英文写 prompt或者中英混写把关键术语用英文标出来。2.4 三个模型在编码研究场景的横向对比维度ClaudeCodex/ChatGPTGemini长上下文代码理解强中中代码生成准确率中强中报错定位能力中强中多模态代码理解弱中强中文技术语境强强弱特定栈默认集成中中强这张表是我自己用下来的体感不是官方数据。你可以根据自己的项目特点对号入座。核心逻辑是没有全能选手只有场景匹配。3. 写作场景为什么必须自己动脑3.1 模型写作的通顺陷阱这是我最想讲的一点。模型写出来的文字最大的问题不是不通顺而是太通顺了。它能把任何话题写得四平八稳读起来挑不出毛病但你仔细一想它什么都没说。我举个具体例子。我让某个模型写一段为什么要做代码审查它给我的是代码审查是软件开发过程中的重要环节它能够帮助团队发现潜在问题提升代码质量促进知识共享。这段话有问题吗语法没问题逻辑也没问题。但它是一句正确的废话。任何一个写过代码的人都知道这些读者看完没有任何新信息。真正有价值的写法应该是我做过一个统计我们团队引入强制代码审查之后线上事故率降了大概四成。但代价是每个 PR 的平均合并时间从 2 小时变成了 8 小时。所以代码审查不是免费的你得算清楚这笔账。后一种写法里有具体数字、有取舍、有个人判断这些是模型给不出来的因为它没有你的项目经验。3.2 逻辑链断裂模型写作的致命伤比正确的废话更严重的是逻辑链断裂。模型生成长文本的时候它是逐段生成的每一段都基于前面的内容做局部最优但它没有一个全局的论证结构。结果就是文章读起来像一串珍珠每颗都圆润但串起来的线是断的。前面在论证 A中间跳到 B后面又回到 A但两次说 A 的角度不一样甚至互相矛盾。我做过一个测试让模型写一篇 3000 字的议论文然后我把它拆成段落打乱顺序再让另一个人读。结果那个人读完之后对文章主旨的理解和原文完全不一样。这说明什么说明这篇文章的段落之间没有强依赖关系顺序换了意思就变了这不是一篇合格的文章。真正的好文章段落之间是有咬合的。第二段必须建立在第一段的结论上第三段必须回应第二段提出的问题。这种咬合关系模型很难维持因为它没有我想论证什么这个全局意图。3.3 观点密度写作的核心价值所在写作的核心价值是什么是观点。是你对一件事的独特判断是你从经验里提炼出来的、别人没说过的洞察。模型没有观点它只有概率分布。它输出的每一句话都是训练数据里最可能出现的下一句。这意味着它天然倾向于主流、安全、平庸的表达。你让它写远程办公好不好它一定会给你有利有弊要具体分析这种和稀泥的结论。但真正有价值的写作往往是要站队的。你得说我认为远程办公对初级工程师是灾难然后给出你的理由。这个理由可能不完美可能有人反对但它是你的。模型给不出这种带刺的观点因为它被训练成不得罪任何人。所以我的结论很直接写作这件事模型可以当助手不能当代笔。它可以帮你查资料、帮你润色句子、帮你检查错别字但核心观点和论证结构必须你自己来。4. 我的实操方案编码用 AI写作靠自己4.1 工作流拆分哪些环节交给模型我把整个工作流拆成两半交给模型的环节代码生成、调试、重构技术资料的检索和摘要数据格式转换、正则表达式编写报错信息的初步分析自己来的环节文章的核心观点提炼论证结构设计案例和数据的选取最终的成文和修改这个拆分的关键在于模型负责信息处理我负责信息判断。模型可以帮我把一堆资料压缩成摘要但这些资料说明了什么必须我自己想。4.2 用 Claude Code 做研究用纸笔做思考具体到工具层面我现在的习惯是用 Claude Code 做代码研究用纸笔做写作思考。Claude Code 我一般这么用# 安装以常见方式为例 # 具体安装步骤参考官方文档这里只讲使用思路 # 进入项目目录后让它分析代码结构 claude 分析这个项目的模块依赖关系输出文字版依赖图 # 让它定位某个功能的实现 claude 找到用户登录功能的实现代码说明它的认证流程注意我让它输出的都是结构化的、可验证的信息不是帮我写一段介绍这个项目的文字。前者我能核对后者我核对不了。写作思考的时候我反而会关掉所有 AI 工具拿一张纸把核心观点写下来然后画论证结构图。这个过程很慢但慢有慢的价值——思考的速度本来就该慢。你让模型一秒生成一千字那一千字里没有你的思考读起来就是空的。4.3 一个具体的写作流程示例我拿写这篇内容本身举例。我的流程是这样的定核心观点AI 适合编码研究不适合写作。这个观点是我自己定的不是模型给的。列论证结构先讲工具强在哪再讲写作为什么不行最后讲怎么拆分。这个结构是我画的。找支撑材料我让模型帮我查了这几个模型在代码任务上的对比数据但筛选哪些数据能用是我自己判断的。写初稿全部自己写不用模型生成任何段落。润色这一步我会用模型检查语句通顺度和错别字但不改观点和结构。这个流程走下来文章里每一句话都是我的判断模型只参与了资料检索和最后的校对。这样写出来的东西才有信息增量。5. 常见问题与排查技巧实录5.1 模型写作的典型问题速查问题表现排查思路正确的废话每句都对但没信息检查是否有具体数字、案例、判断逻辑链断裂段落顺序打乱后意思变检查段落间是否有咬合关系观点和稀泥结论永远是有利有弊检查是否敢站队、敢下判断风格同质化读起来像模板检查是否有个人化表达事实性错误引用的数据/API 是错的逐条核对来源5.2 编码研究场景的踩坑记录坑一模型给的代码版本不对。我遇到过the gpt-5.6-sol model is not supported when using codex with a chatgpt acc这类报错本质是模型版本和账号权限不匹配。解决办法是先确认账号支持的模型列表再指定模型别让它自己选。坑二配置文件写错导致对话中断。chatgpt 无法加载 config.toml因此此对话串无法继续这个报错我踩过。原因是 config.toml 里的 model 字段写了个不存在的模型名。修复方法很简单把 model 字段改成账号实际支持的模型即可。坑三环境依赖缺失。claudes workspace requires the virtual machine platform on windows这个提示是 Windows 上没开虚拟机平台功能。去启用或关闭 Windows 功能里勾上对应选项重启即可。坑四账号权限问题。your current account is not eligible for gemini code assist for individuals这类提示说明当前账号类型不支持该功能。这种情况换账号或者升级套餐没有别的办法。5.3 我的独家避坑技巧技巧一给模型的任务要可验证。我让它分析代码要求它输出函数名 行号 调用关系这样我能逐条核对。如果它输出的是这个模块负责处理用户数据这种模糊描述我核对不了就容易出错。技巧二写作前先写一句话核心。动笔之前先用一句话说清楚我这篇要论证什么。这句话必须是你自己想的不能问模型。有了这句话后面所有段落都围绕它展开逻辑链就不会断。技巧三模型生成的文字读三遍再决定用不用。第一遍读通顺度第二遍读逻辑第三遍读有没有信息增量。三遍下来还觉得好的才考虑用。大部分时候第二遍就发现问题了。技巧四把模型当杠精用。写完初稿之后我会让模型扮演反对者专门挑我论证里的漏洞。这个用法很有效因为它能帮我发现我自己没意识到的逻辑跳跃。但注意它挑出来的问题要不要改还是我自己判断。6. 工具选型的底层逻辑6.1 为什么是这四个模型而不是别的市面上模型很多我为什么主要用这四个原因很简单它们在编码研究这个场景里各自有不可替代的位置。Claude 的长上下文和中文理解Codex/ChatGPT 的代码生成和报错定位Gemini 的多模态和特定栈集成——这三个能力维度目前没有哪个模型能全部覆盖。所以我用组合不用单一。这个选型逻辑可以推广到任何场景先明确你的核心需求再找匹配的工具而不是反过来。很多人是先选工具再想用途结果就是工具用了一堆问题一个没解决。6.2 写作场景为什么不用模型写作场景我不用模型不是因为模型写得不好而是因为写作的价值在于你的思考模型恰恰没有这个。你可能会说那我用模型生成初稿自己改不就行了我试过不行。因为模型的初稿会锚定你的思路。你读着它给的框架不知不觉就顺着它的逻辑走了最后改出来的东西骨子里还是模型的。这就像你让别人替你写了个提纲你再怎么改也跳不出那个提纲的框。所以我的做法是写作从零开始一个字一个字自己敲。慢但每一句都是我的。6.3 一个判断标准什么时候可以用模型我给自己定了个判断标准如果这个任务的产出可验证就可以用模型如果不可验证就必须自己来。代码是可验证的——跑一下就知道对不对。数据转换是可验证的——对一下就知道准不准。但文章的观点是不可验证的——没有标准答案只有你的判断。所以代码交给模型观点自己来。这个标准很粗糙但很实用。你可以拿它去判断任何一个任务该不该用模型。7. 我实际用下来的一些体会最后说几个零散的体会都是踩坑踩出来的。第一模型的能力和可靠性是两回事。它能生成看起来很专业的代码但不代表代码能跑。它能写出很通顺的文章但不代表文章有逻辑。用的时候永远要留一道验证的关口。第二别让模型替你想让它替你做。想是你的核心价值做是可以外包的。你把想外包出去你就没有价值了。第三写作这件事慢就是快。你自己一个字一个字敲出来的东西改起来快因为你知道每一句为什么这么写。模型生成的东西改起来慢因为你得先理解它为什么这么写再判断对不对。第四工具会变判断标准不会变。今天我用 Claude、Codex、ChatGPT、Gemini明天可能有新的模型出来。但编码研究可以用 AI写作必须自己思考这个判断标准不会因为工具变化而改变。我在实际使用中发现越是把 AI 用在可验证的任务上效率提升越明显越是把 AI 用在需要判断的任务上翻车概率越高。这个规律我用了大半年才摸清楚希望你能少走点弯路。