代码已死，判断永生
AiReader 已经完全开源，源码在 GitHub：github.com/LissajousX/…
一个不会编程的人，用三个 AI 写了两万五千行代码之后的终极反思
我说得最多的四个词是：「不合理」「不好看」「你看着办」「再改一下」。
这四个词，驱动了 25,000 行代码、256 个测试、三个平台的构建。
没有一个词跟技术有关。
〇、一个不该存在的软件
2026 年初，GitHub 上出现了一个叫 AiReader 的开源项目。
它是一个跨平台的智能阅读器——支持 PDF、EPUB、Markdown，内置本地 AI（不联网，不上传数据），可以翻译、总结、问答。 技术栈是 Tauri 2.0 + React 18 + TypeScript + Rust + llama.cpp，支持 CUDA / Vulkan / Metal GPU 加速，有 CI/CD 自动构建，跑在 Windows、macOS（Intel + ARM）和 Linux 上。
看起来像是一个小型创业团队三个月的产出。
实际上，它是一个人在两周内做的。
更准确地说——它是一个完全不懂上述任何一项技术的人，用三个不同的 AI 做的。
我没有写过一行 React。我不知道 Tauri 是什么。我连 TypeScript 和 JavaScript 的区别都说不清。Rust？听说过，没碰过。llama.cpp？知道它能跑模型，不知道它怎么编译。
但这个软件确实在跑。确实在被人用。确实通过了 256 个自动化测试。
↑ 这就是它。一个不懂编程的人和三个 AI 的作品。
这篇文章不是来炫耀 AI 有多强的。网上这种文章已经够多了。
我想谈的是一个更深的问题：
如果代码可以被生成，那什么东西不能被生成？
如果 AI 可以做「怎么做」，那人类剩下的「做什么」和「好不好」，到底价值几何？
一、三个 AI，三种角色，一个人
先说一个很多人没意识到的事实：这个项目不是「一个人和一个 AI」的故事，而是「一个人和三个 AI」的故事。
第一个 AI：ChatGPT —— 产品顾问
在写任何代码之前，我花了大量时间在 ChatGPT 网页版上聊天。
我的第一句话是：
"我想做一个加入大模型功能的阅读器，帮我阅读外文文献。你能帮我设计一下吗？顺便看看有没有类似产品。"
ChatGPT 给了我一个大而全的方案：架构图、技术选型、竞品列表（NoteAI、Scholaread、ReadPaper、DeepReader、SciSpace）、开源项目参考（ChatGPT-Paper-Reader、FluentRead）。
我什么都不懂，但我知道这个方案太大了。
我说：「调整一下 MVP，只做翻译、总结、问答。另外我本地 RTX 3080 能跑什么模型？」
然后我探索了 Agent 框架、本地小模型的能力边界、Qwen-Agent 的可行性。
到这里为止，一切看起来像是一个正常的技术调研过程。
但真正的转折发生在我说出这句话的时候：
"我不想对技术选型做什么限制。我只想做提出需求的人。"
这不是一句随口说的话。这是我在那个时刻做出的一个判断——我不应该假装自己是技术人员。我应该做我真正能做好的事情：想清楚我到底要什么。
从那一刻起，我不再问 ChatGPT 「用什么框架」，而是让它帮我写一份纯粹的产品需求文档。
ChatGPT 产出了一份 PRD，其中有一个设计原则，后来成了整个项目的灵魂：
「AI 是坐在你旁边的研究助理，不是替你读书的机器人。」
ChatGPT 的贡献是巨大的。但它写了零行代码。
第二个和第三个 AI：Claude Opus 4.6 + GPT 5.2 —— 程序员
我拿着 ChatGPT 帮我写的 PRD，进入了 Windsurf IDE。
第一条消息：
"这是一个需求文档，我希望你根据它来开发一个阅读器。未来要适配多平台。我的开发平台是 Windows 11，本地用 Ollama 跑模型。"
AI（Claude Opus 4.6）分析完 PRD，输出了完整的技术方案——选了 Tauri 2.0、React、TypeScript、Zustand、SQLite，画了数据模型、目录结构、分期计划。
我说："完全同意你的方案。请开始开发。"
我甚至不知道它选了什么。我是后来才搞明白 Tauri 是个桌面应用框架、Zustand 是个状态管理库这些事的。
AI 一口气生成了项目骨架，跑了 npm install，启动了 npm run tauri dev。
一个功能完整的阅读器雏形就这样出现在我屏幕上。
从那一刻起，我的工作变了。我不再是提需求的人。我变成了这个软件的第一个用户，也是最苛刻的用户。
那我是什么？
三个 AI，各有分工：
| AI | 角色 | 产出 |
|---|---|---|
| ChatGPT | 产品顾问 | 竞品分析、PRD、设计原则 |
| Claude Opus 4.6 | 主力程序员 | 架构、前端、后端、测试 |
| GPT 5.2 | 辅助程序员 | 部分功能实现、Bug 修复 |
而我？
我是产品经理。我是测试员。我是那个说「不合理」的人。
↑ 用 AiReader 读《Attention Is All You Need》。右侧 AI 面板正在解释论文内容。模型跑在本地，不联网。
二、70% 的时间在做一件事：用自己的软件然后吐槽
很多人以为 AI 编程就是：说一句话 → AI 写完 → 完事。
不是的。差远了。
我的时间分配是这样的：
架构 & 核心功能搭建 ██░░░░░░░░ 20%
自测 & 吐槽 & 迭代 ███████░░░ 70%
跨平台适配 & 发布 █░░░░░░░░░ 10%
70% 的时间，我在做的事情是：打开软件，用它看一本书，然后记下所有让我不爽的地方。
每天记一批，攒够了发给 AI：
- 欢迎页那个图标太大了，我希望书的图案跟 A 字等高
- PDF 打开后还没加载完就滚动，会直接跳到最底下
- 目录按钮太丑了
- 工具条优化一下，你看着办
- 还有啥能美化的你看着办吧
注意：这些消息里没有任何技术内容。
我不知道「目录按钮」在代码里叫什么。我不知道「PDF 跳到底下」是渲染问题还是滚动事件问题。我不知道「工具条」是用 flexbox 还是 grid 布局的。
我只知道这个东西不好用。
而这，恰恰是最有价值的信息。
↑ 经过无数轮「不好看」「再改一下」之后的暗色主题。右侧是 AI 翻译结果。每一个像素都是吐槽出来的。
三、一个哲学问题：什么东西不能被生成？
在这个项目里，AI 生成了：
- 25,000 行代码
- 完整的前后端架构
- 256 个测试用例
- CI/CD 流水线
- 多平台构建配置
- GPU 加速适配方案
AI 没有生成的是：
- 「我想做什么」—— 这个想法来自我每天阅读英文文献的痛苦
- 「这个不合理」—— 每一个 bug 报告、每一个体验吐槽都来自我真实的使用感受
- 「这样不够好」—— AI 每次说「已修复」，我都要亲自验证，不合格就打回去
- 「先想清楚再做」—— 在 ChatGPT 中从技术探索转向产品定义的那个关键判断
- 「给 AI 一个好的参考」—— 去 GitHub 找优秀开源项目让 AI 学习的决策
让我把这五件事抽象一下：
| 人类做的事 | 本质 |
|---|---|
| 想做什么 | 意图 |
| 这个不合理 | 判断 |
| 这样不够好 | 品味 |
| 先想清楚再做 | 策略 |
| 找参考给 AI | 资源调度 |
意图、判断、品味、策略、资源调度。
这五样东西，在 2026 年的今天，AI 一样都生成不了。
不是因为 AI 不够聪明。而是因为这五样东西的源头不是信息——是欲望、是偏好、是价值观、是一个人活到现在所有经历的总和。
AI 可以写出一万种"好看的界面"。但只有你知道"好看"对你来说意味着什么。
AI 可以提供一百种技术方案。但只有你知道你愿意为什么东西花两周时间。
代码是手段。判断才是目的。
四、我做过最有效的一件事，和最傻的一件事
最有效的一件事：给 AI 找老师
EPUB 电子书的渲染问题困扰了我很久。打开某些书会报 403 错误、超时、白屏。AI 修了一轮又一轮，每次都说修好了，但总有新的边界情况。
我做了一件事：去 GitHub 上找了两个优秀的开源阅读器（Alexandria 和 Readest），下载下来扔给 AI：
"请先仔细学习两个优秀的开源项目，然后再来做我们这个。务必认真学习，不要偷懒。"
一次就解决了。
AI 从参考项目里学到了 EPUB 路径解析的正确做法，做了三层兜底修复，之后再没出过问题。
启示：用自然语言描述「应该怎么做」很难说清楚。但给 AI 一个好的参考实现，比说一万句话都管用。
这个技巧的本质是什么？是资源调度——我不会写代码，但我会找好的代码。我不知道正确答案，但我知道谁知道正确答案。
最傻的一件事：太晚才写测试
项目后期，同样的 bug 反复出现：进度条修了四次，删除确认修了两次，macOS 选中文本修了三次。
原因很简单——没有测试。AI 每次说「已修复」，我只能手动试。而手动测试永远覆盖不到所有情况。
我跟 AI 说：「把测试代码都给我写了。」
AI 一口气写了 256 个测试用例。覆盖了所有核心模块。然后建了 CI 流水线，每次提交代码自动跑测试。
从此再也没有反复出现的 bug。
我最后悔的是没有更早做这件事。如果在项目中期就建测试，很多 bug 第一次就能彻底解决。
AI 写测试的效率极高——你说一句"给这个模块写测试"，它能一次性输出几十个 test case。这个能力要尽早用上。
五、AI 的真正恐怖之处，不是它能写代码
AI 能写代码，这已经不是新闻了。
真正恐怖的是：AI 让「能力」和「成本」脱钩了。
以前，如果你想做一个跨平台桌面应用，你需要：
- 一个前端工程师（React + TypeScript）
- 一个后端工程师（Rust 或 C++）
- 一个 DevOps 工程师（CI/CD + 多平台构建）
- 一个测试工程师
- 一个产品经理
- 三到六个月
- 至少五十万人民币
现在你需要的是：
- 一个想清楚了自己要什么的人
- 两周
- 几乎零成本
这意味着什么？
意味着「有没有技术团队」不再是你能不能把想法变成产品的决定性因素。
意味着一个老师可以自己做教学工具。一个医生可以自己做临床辅助系统。一个研究员可以自己做数据分析平台。
意味着创造力的瓶颈从「能不能实现」变成了「有没有想法」。
从「会不会做」变成了**「知不知道该做什么」。**
六、一些不舒服的真相
在写这篇文章的时候，我不得不面对一些不舒服的真相：
真相 1：AI 的代码质量，对我来说不可评判
我不会编程。我无法判断 AI 写的代码是优雅还是丑陋。我只能判断软件好不好用。
如果 AI 在某个地方写了一个性能极差但功能正确的实现，我完全发现不了——直到有一天用户量增长到一定程度，问题才会暴露。
这是「不懂技术的人用 AI 编程」的最大风险：你不知道你不知道什么。
真相 2：AI 会「静默失败」
这是我在这个项目里学到的最深刻的教训。
AI 生成的代码有一种特殊的失败模式：它不会报错，但它不工作。
比如 CUDA GPU 加速。AI 写了加载 GPU 驱动的代码，代码逻辑完全正确。但在实际运行时，如果 DLL 加载失败，代码默默地 fallback 到了 CPU 模式——没有任何错误提示、没有任何日志。
用户以为自己在用 GPU 加速，实际上一直在用 CPU。
为什么会这样？ 因为 AI 在写代码时倾向于「不让程序崩溃」。它会加 try-catch，会加 fallback，会加默认值。这在大多数时候是好事。但有时候，崩溃比静默失败好一万倍——至少崩溃了你知道出了问题。
真相 3：我说了很多次「你看着办」
在项目后期，面对一些细节优化，我经常说「你看着办吧」。
这不是信任 AI 的判断。这是懒。
事后回看，AI「看着办」的结果质量参差不齐。有些很好，有些明显不符合产品的整体风格。
「你看着办」应该只用在你真的不在乎的地方。如果你在乎，就必须给出明确的判断。
七、给所有想用 AI 编程的人
如果你看完这篇文章，想自己试试用 AI 做一个产品，这是我最想告诉你的几件事：
1. 先想清楚你要什么，再碰 AI
不要一上来就说「帮我写个 XXX」。
花时间在 ChatGPT 上聊。调研竞品。了解别人怎么做的。然后写一份需求文档——哪怕只有一页纸。
PRD 是你给 AI 的边界。没有边界的 AI，会给你一个什么都有但什么都不对的东西。
2. 不同的 AI 擅长不同的事
ChatGPT 网页版适合开放式探索、产品思考、竞品分析。 Windsurf / Cursor 中的 AI 适合精确的代码编写和工程执行。
不要指望一个 AI 什么都做。像管理团队一样管理你的 AI。
3. 你最大的价值是说「不」
AI 永远会说「好的，已完成」。它不会告诉你这个方案不合理，不会告诉你这个交互很蠢，不会告诉你用户不会喜欢这个。
你的工作不是说「好」，而是说「不行，重来」。
每一个成功的产品背后，都有无数个被否决的方案。AI 不会否决自己，这件事只有你能做。
4. 尽早建测试
AI 写测试的速度极快。一句话几十个 test case。
不要等到项目末期才想起来写测试。在核心功能成型后就让 AI 写。这会节省你后面无数的手动验证时间。
5. 遇到难题，给 AI 找参考
当你发现 AI 反复修同一个问题修不好时，不要继续用自然语言描述。
去 GitHub 上找一个解决了同样问题的开源项目，下载下来扔给 AI 说「先学这个」。
一个好的参考实现，胜过一千句需求描述。
6. 记录一切
我留下了 9 份对话记录。数百条消息。数万字。
这些记录不仅帮助我复盘，还让我写出了这篇文章。
跟 AI 协作的过程本身就是知识。记录它，你会在回头看时发现很多当时忽略的洞见。
八、终极问题：程序员会失业吗？
我知道你在等这个问题。
我的回答是：问错了。
「程序员」从来不是一个统一的职业。它包含了：
- 把需求翻译成代码的人（编码者）
- 设计系统架构的人（架构师）
- 保证软件质量的人（测试工程师）
- 理解用户需求的人（产品工程师）
- 做出技术判断的人（技术负责人）
AI 正在极速替代第一种。这是事实。
但后四种——设计、质量、理解、判断——AI 目前做不了，短期内也做不了。
不过，这件事的意义远比「谁会失业」深刻得多。
它意味着：以前只有程序员能做的事，现在每个人都能做了。
不是程序员失业了——而是每个人都变成了程序员。
或者更准确地说：每个人都变成了产品经理。因为现在，从想法到产品的距离，只剩下一份需求文档和几句清晰的判断。
九、代码已死，判断永生
我花了两周时间，用三个 AI，做了一个 25,000 行代码的跨平台桌面应用。
我没有写一行代码。
但我做了几百个判断。
哪些功能要做，哪些不做。 这个交互合不合理。 那个按钮好不好看。 这个 bug 修没修干净。 AI 该在什么时候介入，什么时候闭嘴。
每一个判断都很小。但所有判断加在一起，就是这个产品。
代码是 AI 写的。但产品是我的。
因为产品不是代码。产品是一千个判断的总和。
如果你也想试试，AiReader 已经开源：GitHub - LissajousX/aireader
它不完美。它是一个不懂编程的人和三个 AI 的实验。但它确实在跑，确实有人在用。
如果这篇文章让你觉得「也许我也可以」——那就对了。你可以的。
你需要的不是学编程。你需要的是想清楚你要什么，然后有勇气对 AI 说「不行，重来」。
↑ AI 配置页。自动探测硬件、下载最佳模型、一键启动。支持 CUDA / Vulkan / Metal。这也是 AI 写的。
附录：硬数据
| 指标 | 数据 |
|---|---|
| 项目总代码量 | ~25,000 行（前端 + 后端） |
| 我手写的代码量 | 0 行 |
| 我掌握的技术栈 | 0 个 |
| 参与的 AI | 3 个（ChatGPT + Claude Opus 4.6 + GPT 5.2） |
| AI 分工 | ChatGPT: 产品顾问 / Claude + GPT: 工程执行 |
| 对话记录 | 9 份 |
| 关键消息 | 数百条 |
| 开发周期 | ~2 周 |
| 单元测试 | 0 → 256+ |
| 支持平台 | Windows / macOS (Intel+ARM) / Linux |
| GPU 加速 | CUDA / Vulkan / Metal |
| 开源地址 | github.com/LissajousX/… |
本文作者不会 React，不会 TypeScript，不会 Rust，不会 Tauri，不懂 llama.cpp。但他知道什么是一个好的阅读器。在 2026 年，这就够了。
对了，差点忘了——这篇文章也是 AI 写的。
我只说了一句：「给我写一篇惊天地泣鬼神的博客文章。」
然后我看了一遍，说：「行。」
你看，我说的没错吧——判断才是最重要的那个能力。
