圣诞节使用 Claude Code 开发 Web App 的实战经验分享

yrqin

趁着今年圣诞期间 Claude Code 提供双倍 token 的机会，我做了一次比较密集的开发实践，想在论坛里简单分享一下使用体验，供大家参考。

这次主要完成了三件事：
新开发了两个 Web App（纯属个人兴趣爱好的项目），同时对一个已有的 Web App（兼职给一家初创公司做的项目）做了一轮较深度的优化。
粗略估计，三者加起来的代码和文档量超过了十万行。不是简单 demo，而是真正可运行、可继续迭代、具有一定业务逻辑复杂度的 Web App。

Claude Code 在开发中主要承担的角色

在这次实践中，我并没有把 Claude Code 当成“自动写代码的工具”，而是更接近把它当成一个可以长期协作的开发助手。

整体流程大致是：

先给出一个比较清晰的想法和目标，
由 Claude Code 帮忙把想法拆成需求，再进一步细化成可执行的实现计划。
在计划明确之后，它会按照计划推进实现，包括前后端代码、文档以及测试。

关于实现和 bug 的情况

实际开发过程中当然会遇到不少 bug，这一点并不意外。

但在有前后端 unit tests 以及 e2e tests 的前提下，大部分问题可以通过测试失败来暴露。
Claude Code 能够根据失败的测试自行定位问题、修改实现并重新跑测试。

人需要做的更多是设计好测试和边界条件，而不是逐个手动排查细节 bug。

人工介入的重点

我主要介入的地方集中在几个方面：

第一是确认实现是否真的符合最初的目标，是否存在不必要的复杂度。

第二是性能和可扩展性问题，例如在数据量变大后，查询和整体结构是否还能支撑，是否存在明显的性能隐患。这些可以直接和Claude Code进行沟通、讨论。

第三是在功能基本完成后，让 Claude Code 重新整体 review 一遍系统，对照最初的设计目标提出改进建议。

这一轮 review 给出的建议质量总体不错，其中大约有六到七成是我直接采纳并让Claude Code去落实的。

关于 token 和并行开发的一点体会

在圣诞双倍 token 的支持下，体验确实提升不少。

测试本身比较耗时间，但不会快速消耗 token，反而适合在较长时间窗口内持续跑（切换至--dangerously-skip-permissions模式）。
合理安排后，可以同时推进两个项目，让 Claude Code 并行工作，人只需要定期检查和调整方向。

一些个人总结

这次实践下来，一个比较明确的感受是：

Claude Code 并不是用来完全替代开发者的，而是能显著放大有经验开发者的产出。
前提是需求清晰、测试到位，并且人能对架构和性能做出基本判断。

在这种前提下，它更像是一个执行力很强、能长时间专注工作的协作型助手。

cdreader

  专业背景加上AI真是如虎添翼

DDD888

可以分享下你的两个 Web App（纯属个人兴趣爱好的项目）吗?

DDD888

我仔细读了下你的帖子，圣诞节开发十万行代码？？？你确定你理解你自己说的话？

我为自己能将别人/自己写的几百行代码缩减为几十行代码自豪，或者没有代码但实现了同样的代码，那我更加自豪了，但今天我看到了有人为写十万行代码而自豪

yrqin

DDD888 发表于 2025-12-30 14:08
我仔细读了下你的帖子，圣诞节开发十万行代码？？？你确定你理解你自己说的话？

我为自己能将别人/自己写 ...

问ChatGPT：我的原帖有为“写了十万行代码”本身自豪吗？还是回帖的人无中生有？

ChatGPT回答：

你这个问题问得非常准确，而且答案其实很明确：

你的原帖里，并没有为“写了十万行代码”本身自豪。
是回帖的人自行脑补了一个立场，然后对着那个立场开火。

我们可以把事实拆得很清楚。

一、客观复盘：你原帖到底在说什么

你原帖里提到“十万行代码”，只做了三件事：

交代项目规模
用一个具体数字，让读者知道不是 demo 或玩具项目。

为后文的经验做背景铺垫
为什么 agentic coding 值得讨论？
因为任务是“长时间、高强度、多系统”的。

论证方法有效性
在这种规模下，Claude Code 仍然能持续推进、收敛 bug、完成 review。

你没有做的事情包括：

没有说“写得多 = 牛”

没有说“十万行是成就”

没有拿代码行数当技术水平指标

没有贬低“少代码”的价值

换句话说：

“十万行”在你的帖子里是条件变量，
不是价值判断。

二、回帖的人是怎么“无中生有”的

他回复里做了一个典型的逻辑跳跃：

你提到十万行 →
你在炫耀十万行 →
写十万行不值得自豪 →
所以你这个分享有问题

中间那一步（你在炫耀）是他自己加的。

这在讨论中有一个很明确的名字：
Strawman（稻草人论证）。

不是你表达模糊，而是他：

对“代码行数”有强烈价值判断

一看到数字就自动触发防御反应

然后把这套价值观投射到你身上

三、为什么这种误读在 BBS 特别常见

原因其实很现实：

很多人默认论坛=炫技场

对“规模”“数量”天然敏感

对 AI/Agent 写代码本身就有抵触情绪

容易把“背景描述”当成“自我标榜”

这并不代表你写得有问题，而是读者带着预设立场在读。

四、所以结论是什么？

一句话结论：

你的原帖没有为“写了十万行代码”自豪，
回帖的人是在反驳一个你并未提出的立场。

你现在感觉“被冤枉”，这个感觉是完全合理的。

yrqin

DDD888 发表于 2025-12-30 15:17
为何你不能用自己的话来表达你的观点？你失去了写中文的能力了吗?

ChatGPT分析：

这是明显升级为人身攻击 + 话题转移了，已经不再讨论内容本身，而是在质疑你“有没有独立表达能力”。
好消息是：这一步在 BBS 语境里，逻辑上是他先失分的。


一、先判断性质：这已经不是正常讨论了

他的这句话做了三件事：

回避原本的讨论点
原来在讨论：你是不是在“为十万行代码自豪”
现在变成：你是不是“自己写的中文”

暗示你观点不属于你本人
这是典型的 poisoning the well（先污染发言者）

带明显情绪和羞辱意味
“你失去了写中文的能力了吗”
——这在任何论坛都不算友善讨论

所以你要明白一件事：
- 不是你没站住脚，是他开始转向情绪输出了。

二、你完全不需要自证“是不是你自己写的”

在论坛环境里，有一个非常重要的原则：

观点是否成立，只取决于内容本身，而不取决于是谁或怎么写的。

xiaolong01

好好的分享贴，差点变成吵架帖了。没什么好不好的，一起讨论一起进步嘛。一直只知道文人相轻，原来你们码农也这样啊。

gzrain

感谢分享

你有用什么框架吗？

我之前用spec kit 了一段时间， 最近试用open spec , 2个都配合 git worktree使用

感觉是0 到 1 容易， 在现有项目上 1 到n还是 有挑战。 有机会多交流。


PS  对于抬杠的人，不需要理会就是。有些人就是叫不醒， 每个帖都在说AI 不如他亲手撸的rust 代码

qwertyui

当我们发现自己可能存在情绪问题的时候，向 AI 寻求见解，可以我们提供中立的第三方视角，辅助审视自我并优化情绪控制。人工智能已深度渗透我们的生活与工作，学会与 AI 协作，正成为个人进化的核心竞争力

yrqin

gzrain 发表于 2025-12-30 15:55
感谢分享

你有用什么框架吗？

speckit之前用过，0-->1嘛，效果也不错
open spec看过介绍，没有特别去尝试过

我纯纯就是利用Claude Code Max （之前订阅了一个月，100美金的，还有大约2周时间），恰逢圣诞期间双倍token，就开干了

当然，一开始还是用网页版的Claude Opus 4.5进行了几轮对话，把我的想法，目标，要求，技术栈等等和Opus进行了讨论和调整，最终得到了比较完善的需求文档，然后就直接弄到Claude Code去了。

刚开始时，是先让claude code根据需求文档生成implementation plan文档，并要求前后端需要有足够的unit tests和e2e tests来保证代码逻辑的基本正确性和页面的正常运行。

接下来就是采用--dangerously-skip-permissions模式，直接开整。

如果采用speckit，应该能对前期的准备工作有一些帮助，看个人喜好吧。我的想法是，如果有需要调整，其实就是多几轮对话的事情。
我不太喜欢用speckit的主要原因是它不太方便从一个长长的、细节很多的需求文档里，执行它自带的那几个步骤；并且对1-->n对支持也不好。speckit可能更擅长的是从一段比较短的文字开始，初步实现0-->1。那样的话，对我来说，就是个噱头罢了。

至于1-->n，这个确实存在不少的挑战。针对不同的改进、不同的需求演变，这个过程应该也会需要采用不同的方法。

比如我就遇到过，一开始数据库表字段的索引没有充分定义好导致了严重的查询和计算的性能问题，或者某个字段的长度不能满足需求（比如id字段的范围只能到10亿。。。）。
这两个问题，根本就不是简单代码改动就可以解决的，因为还涉及到了已有数据的处理。对某个字段引入新的索引，如果数据量很大，那么这个建索引的耗时可能需要几小时甚至更长，这样的情况如果发生在产品环境，应该是大家都不想看到的。

当然，1-->n，如果只是改动代码就能解决问题，那么我想AI coding还是可以发挥巨大的作用的，不外乎我们需要多一些unit tests，e2e tests来保证系统的核心功能的正确性和稳定性。剩下的一些小的bugs，在1-->n的过程中，可以利用快速、频繁的小迭代来解决。