企业官网建设流程全解析

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 生成的代码，必须过一遍本地测试。具体流程：

1. 让它生成代码，同时要求它标注每个外部依赖的版本
2. 本地建一个干净的虚拟环境
3. 按它标注的版本装依赖
4. 跑单元测试

这套流程走下来，能过滤掉八成以上的"幻觉代码"。

2.3 Gemini 在算法研究与多模态代码场景的补充价值

Gemini 我主要用在两个地方：一是算法思路的横向对比，二是带图表的代码理解。比如我有一张架构图，想让它根据图生成对应的模块骨架代码，Gemini 的多模态能力在这时候就派上用场了。

另外adk kotlin 的 model 目前仅内置 gemini这个点也值得说——在某些特定技术栈里，Gemini 是默认集成选项，这时候用它反而比硬接别的模型省事。我实际配置过一版，把 Gemini 作为默认推理后端，代码补全的延迟比走外部 API 低不少。

但 Gemini 有个明显短板：它对中文技术语境的把握不如前两个。同样的需求，我用中文描述，它有时候会理解偏。所以用 Gemini 做编码研究，我建议用英文写 prompt，或者中英混写，把关键术语用英文标出来。

2.4 三个模型在编码研究场景的横向对比

这张表是我自己用下来的体感，不是官方数据。你可以根据自己的项目特点对号入座。核心逻辑是：没有全能选手，只有场景匹配。

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 一个具体的写作流程示例

我拿写这篇内容本身举例。我的流程是这样的：

1. 定核心观点：AI 适合编码研究，不适合写作。这个观点是我自己定的，不是模型给的。
2. 列论证结构：先讲工具强在哪，再讲写作为什么不行，最后讲怎么拆分。这个结构是我画的。
3. 找支撑材料：我让模型帮我查了这几个模型在代码任务上的对比数据，但筛选哪些数据能用是我自己判断的。
4. 写初稿：全部自己写，不用模型生成任何段落。
5. 润色：这一步我会用模型检查语句通顺度和错别字，但不改观点和结构。

这个流程走下来，文章里每一句话都是我的判断，模型只参与了资料检索和最后的校对。这样写出来的东西，才有信息增量。

5. 常见问题与排查技巧实录

5.1 模型写作的典型问题速查

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 字段改成账号实际支持的模型即可。

坑三：环境依赖缺失。claude's 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 用在"需要判断"的任务上，翻车概率越高。这个规律，我用了大半年才摸清楚，希望你能少走点弯路。