一个人就是一支队伍：从 Next.js 到显示器，聊聊我的“全栈续航”方案

之前写完那篇《Next.js 零成本全栈出海》的文章后，很多人问的不是技术细节，而是一个很现实的问题："你一个人搞全栈，又要写码又要运维又要搞 AI，身体和眼睛怎么顶得住？"

说实话，顶不住是常态。

独立开发最难的不是技术栈，而是续航。大厂有轮岗，我们没有。如果说 Next.js 是武器，那每天面对的工作环境就是后勤。最近为了适应 AI 辅助编程的节奏，我把软硬件环境做了一次大调整。

今天不聊虚的，分享一下我是怎么把这套"不仅费脑子，还巨费眼睛"的工作流理顺的。

当我不"写"代码之后

这一年，我从单纯的"敲代码"，被迫变成了一个"看代码"的人。这直接改变了我的软件选择，现在有一个新词挺贴切的：AI 善后工程师。

被 AI 倒逼的工作流

我现在的主力环境是 Next.js + Claude Code / TRAE SOLO。

以前写一个带鉴权的 API，我得手搓 40 分钟。现在用 Claude Code 或者 TRAE 的 SOLO 模式，也就是两三句话的事：

"基于 Prisma Schema 生成 API，带 Zod 校验和测试文件，写完之后生成 openAPI 格式的接口文档。"

AI 几秒钟就能把代码甩到我脸上。效率确实是 10 倍提升。

"信息过载"的痛点

以前写代码，屏幕上只有当前光标附近的几十行。

现在跟 AI 结对编程，屏幕上是爆发的信息流：

Prompt 很长：为了准确，上下文往往几百字。
AI 废话多：它会解释一堆逻辑（虽然后来我都跳过不看）。
代码量大：以前一行行写，现在是一屏屏出。

相信用过的都懂，这种刷屏速度，与其说是写代码，不如说是在做"代码阅读理解"。我发现最累的不是思考逻辑，而是疯狂划触摸板。要在 Prompt、AI 的解释、生成的代码、以及 Git Diff 之间来回反复横跳。为了不被 AI 的信息流淹没，我总结了三条"AI 善后"的生存法则：

1.让编译器当第一道"防波堤"

以前我写代码是"构思 -> 编码 -> 运行"。现在流程变了，变成了"Prompt -> 生成 -> 看报错 "。由于 AI 生成速度极快，我养成了一个习惯：绝对不先看代码逻辑，而是先看 TypeScript 报错。 如果是 Next.js 项目，我会在 Prompt 里强制要求："生成代码后，请确保通过 ESLint 和 TypeScript 严格模式检查，不要使用 any 。" 如果在 TRAE 或 Claude Code 里看到生成完有红线，直接甩回一句"Fix type errors"，看都不要看。让机器去对付机器，人的精力只留给用来审视业务逻辑，而不是帮 AI 查语法。

2.学会"静音"指令

Claude 和 GPT 最大的毛病就是"好为人师"。明明只改了一行配置，它非要给你写一篇 500 字的小作文解释原理。对于全栈开发者来说，屏幕空间寸土寸金。我现在常用的 Prompt 结尾都会带上一句：

"No verbal explanation, just code blocks. If explanation is needed, use comments in code." （不要废话，只给代码。如果有必要解释，写在注释里。 ）这样能把屏幕的有效信息密度提升 30%，大大减少滚轮滑动的距离。

3."增量式"的上下文投喂

很多时候 AI 开始胡言乱语，是因为我们把整个文件都丢给了它。 Claude Code 和 TRAE 的优势在于它们能读取本地文件，但我发现**"少即是多"**。在修改一个 API 时，我只把 schema.prisma 和当前的 route.ts 喂给它，坚决不让它读取无关的 Components。限制它的视野，不仅能减少 Token 消耗，更能防止它产生幻觉，改了不该改的地方------这在后期的 Code Review 简直是灾难。

但即使做好了这些软件层面的优化，物理层面的瓶颈依然存在。 这就回到了我前面说的问题：当我对 AI 进行了层层"调教"后，它吐出的代码依然是爆发式的。这时我发现，限制效率的不再是手速，而是屏幕的"显示行数"

新显示器的使用体验

为了解决"划触摸板划到手酸"和"看 Diff 看到眼瞎"的问题，我准备换个显示器，于是我把问题抛给了 Gemini，习惯了 AI 不离手之后，日常有问题第一个想到的就是他。

看他吹得这么神，我决定试试水：明基 BenQ RD280U。

用了一段时间，还是有点不一样的感受的。先说结论：它不是什么"完美神屏"，它就是专门给写代码的人做的一个偏科生。

3:2 比例：为了多看那十几行

拿到这块屏第一感觉是"方"。它不是常见的 16:9，而是 3:2。如果你拿它看电影，上下会有大黑边，体验一般。但如果你是写代码的，这个比例真的舒服。逻辑通常是纵向流动的。在自带的屏幕上，由于高度的问题，只能展示 256-290 区间的代码行数。

在 RD280U (3840x2560) 上，我能在同样的编辑器、同样的配置下，显示 256-307 区间的代码行数。

少滑动几次触摸板，对保持思路连贯性真的挺重要。多出来的这 18.5% 纵向空间，就是给"上下文"留的。看到这里，肯定有老哥会说："想要纵向空间，我直接把副屏竖起来不就行了？"我以前也是这么干的，但在 AI 时代，这招不好使了。

第一，竖屏是"颈椎杀手"。 27 寸的 16:9 竖起来像座塔。看头部代码要仰头，看底部终端要低头，这种高频的"点头运动"比看横屏累得多。3:2 是在不需要大幅度动脖子的情况下，人眼能覆盖的最佳纵向视野。

第二，也是更关键的：AI 需要"宽度"。 以前竖屏好用，是因为我们只写代码。现在用 TRAE SOLO，左边任务栏，中间偏左挂着一个 AI Chat ，中间偏右是代码区域，最右边是代码结构目录。现在是 Mac 自带显示器的展示效果，如果是 16:9 的竖屏，这是人类能看的？阅读体验极差。

3:2 的妙处就在于：它够高，能装下长逻辑；它也够宽，能在挂着 AI 侧边栏的同时，保证主代码区不折行。

终于能看清 Dark Mode 了

这是他的第二个优点。

程序员 90% 的时间都在用 Dark Mode。自带的显示器或者我之前在公司用的普通外置显示器，通病是黑得不纯，有点发灰。加上 IDE 里那些深蓝、深灰的语法高亮，混在一起非常累眼，尤其是在找 Bug 或者看 Diff 的时候。RD280U 有个 Coding Mode，专门调过对比度。简单说，就是把背景压得更黑，把变量名、关键字的亮度提上来。