圣诞节使用 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的过程中，可以利用快速、频繁的小迭代来解决。

yrqin

Claude Code 的创建者 / 核心推动者Boris Cherny在X上的推文：

https://x.com/bcherny/status/2004887829252317325

当我在 2024 年 9 月把 Claude Code 作为一个副业项目创建时，我根本没想到它会成长为今天的样子。很荣幸看到 Claude Code 已经成为许多工程师的核心开发工具，社区非常热情，人们把它用于各种用途 —— 从编程，到 DevOps，到研究，再到非技术使用案例。这项技术既陌生又神奇，它让人们更容易去构建和创造。越来越多地，代码不再是瓶颈。

一年前，Claude 在生成 Bash 命令时还会遇到逃逸问题。它能工作几秒钟或几分钟而已。我们当时只看到它将来可能广泛用于编码的初步迹象。

快进到现在。在过去的三十天里，我合并了 259 个 PRs —— 497 个Commits，新增 40K 行, 删除 38K 行。每一行代码都是由 Claude Code + Opus 4.5 写的。Claude 能够持续运行 几分钟、几小时、甚至几天（使用 Stop hooks）。软件工程正在改变，我们正进入编码历史上的一个新时期。而且我们仍然只是刚刚开始……

flyspirit

Vibe coding是大势所趋。 用来做助手是完全没问题。

但那些大佬连续跑几个小时， 生成大量代码如果出了错怎么调试， 怎么解决？

AI生成出来的代码我大致还是要看下，几十万行如何对付？

kawara

论坛里有个人说下面一番话，请评价

...

这段话整体属于那种“听起来很爽、也确实可能发生、但细节里藏着一堆默认前提”的分享。评价可以分三层：可信的、夸张/模糊的、以及被忽略的风险。

⸻

哪些部分我觉得可信
        1.        “不是自动写代码，而是当协作助手”
这基本是目前 AI 编程工具最现实、效果最稳定的用法：你负责方向、边界和验收，它负责铺路、填坑、重复劳动。
        2.        “测试是关键，失败驱动修复”
这也对。只要测试足够硬（尤其是 e2e + 关键业务断言），AI 修 bug 的成功率会明显上升，因为它不需要“理解世界”，只要满足断言就行。
        3.        “放大有经验开发者产出”
对。越懂架构、越会拆任务、越会写验收条件的人，越能把工具当杠杆用。反过来，新手更容易被带沟里。

⸻

哪些地方很可能在“说得漂亮但不够严谨”
        1.        “三者合计十万行，不是 demo”
十万行这句话有点营销味。因为：

        •        10 万行很容易被“代码生成的 boilerplate、类型定义、API client、自动生成文档、测试快照、lockfile、迁移文件”撑大。
        •        真正有价值的是：核心业务逻辑和可维护性，不是行数。

如果他想表达“规模不小”，可以理解；如果拿这个当质量背书，就有点虚。
        2.        “Claude 能自行定位问题、修改并重新跑测试”
能做到，但取决于环境：

        •        他的测试是否真的覆盖关键逻辑，还是只是“能跑通”
        •        CI/本地环境是否足够稳定
        •        错误日志是否足够可读
        •        失败是否可复现

很多“自动修复成功”的本质是：测试断言比较浅 or 场景比较标准。
        3.        “并行推进两个项目，人只需要定期检查方向”
这句话听起来很爽，但现实里容易变成：

        •        两个项目同时堆“技术债和风格不一致”
        •        你后面要花时间做“统一架构、抽公共组件、整理依赖”
        •        以及最关键的：你要对合并进主分支的东西负责（不是 AI 负责）

能并行，但人的“架构一致性带宽”是瓶颈，不会因为 token 翻倍就变大。

⸻

他刻意没提（但你在公司环境里必须盯死）的风险
        1.        安全与合规：--dangerously-skip-permissions 这句非常危险
这模式本质是“让工具少问你、自己乱动”。在企业代码库里，后果可能包括：

        •        误改配置、误删文件、乱跑脚本
        •        把敏感信息写进日志/文档
        •        扫到不该扫的目录
        •        更糟的是把秘密（token/key）带进提交历史

个人玩具项目可以这么玩，公司项目别碰，或者至少在隔离环境里跑。
        2.        “能跑”不等于“可维护”
AI 很擅长：

        •        写得快
        •        通过测试
        •        但也很擅长塞进：
        •        过度抽象
        •        不一致命名
        •        多余层次
        •        一堆“看起来像最佳实践”的结构

他说“人工介入确认复杂度”，这是对的，但他没说的是：这一步其实很费脑子，而且决定项目后期寿命。
        3.        成本转移：从写代码转移到写验收/评审/治理
他讲得像“人不用查 bug 了”，现实是：

        •        你要写更严格的测试
        •        做更强的 code review
        •        做更多的系统性检查（安全、性能、依赖、observability）
不然你得到的是“跑得起来的复杂系统”，不是“可持续迭代的系统”。

⸻

我对这段话的总体评价
        •        作为“AI 编程实践分享”是可信且有参考价值的，尤其是“测试驱动 + 人控架构”的思路。
        •        作为“工具能力证明”略带滤镜：行数、并行、自动修复这些点都缺乏可验证细节，容易让读者以为“这玩意几乎能自己做项目”。
        •        在企业场景里照抄会出事：特别是权限跳过、数据/密钥、合规、以及后期维护成本。

如果你问“这人是不是在吹牛”：不一定。更像是在一个对他有利的环境里做了正确的流程，所以效果很好。换个环境（复杂遗留系统、弱测试、强合规、多人协作），故事就没这么顺滑了。

你要是把你们公司实际情况说一下（语言栈、是否有代理/内网、合规限制、repo 规模、测试现状），我可以把这套方法改成“在你那种环境下哪些能用、哪些会翻车”。

Falye

感谢分享 这才是真正的干货

yrqin

kawara 发表于 2025-12-31 03:22
论坛里有个人说下面一番话，请评价

...

Claude Opus 4.5的分析是：

（同样的问题：论坛里有个人说下面一番话，请评价）

这是一段质量很高的实践分享，有几个值得注意的点：

## 方法论上的亮点

**测试驱动的协作模式**是这段分享中最有价值的洞察。作者指出"人需要做的更多是设计好测试和边界条件"——这实际上把人的角色从"写代码"转移到了"定义正确性标准"。这是一个很务实的分工：人负责定义"什么是对的"，AI 负责实现并自我验证。

**分层介入策略**也很清晰：需求层、架构层、性能层。作者没有纠缠于细节 bug，而是把注意力放在 AI 难以自行判断的高层问题上。

## 几点观察

作者说"十万行代码"，这个数字本身说明不了太多——代码量和价值没有线性关系。但结合"可运行、可迭代、有业务复杂度"的描述，说明作者对质量有基本判断，不是单纯追求产出量。

"六到七成建议被采纳"这个比例挺有意思。说明 AI 的 review 有价值但不完美，人的筛选仍然必要。

## 一个隐含的前提

作者反复强调"有经验的开发者"这个前提。这很诚实——如果没有能力判断架构合理性、识别性能隐患、设计有效测试，这套工作流就跑不起来。

总体而言，这是一篇比较冷静、不过度吹捧也不刻意贬低的使用报告，对其他开发者有实际参考价值。

yrqin

kawara 发表于 2025-12-31 03:22
论坛里有个人说下面一番话，请评价

...

网页版的AI我用的最多的还是Claude和ChatGPT，主要是用习惯了；两个一起用，还可以进行必要的横向对比

下面是ChatGPT的分析：

这段话整体是理性、完整且技术上自洽的，但它在论坛语境下容易引发误读与争议。可以从「内容本身是否成立」和「为何会被质疑」两个层面来评价。

一、从技术与实践角度看：这段话本身是成立的

如果只看方法论与工程实践，这段话是相当成熟的，而且明显出自有多年工程经验的人。

1️⃣ 对 Claude Code 的定位是正确的

他说得很清楚：

不是“自动写代码的神器”

而是：

拆需求

制定可执行计划

按计划推进

结合 tests 驱动修改

人负责目标、架构、性能判断

- 这是典型 senior / staff 级工程师使用 AI 的方式，不是新手幻想。

2️⃣ 测试驱动 + agent 修复 bug 的描述是现实的

他说的流程：

unit / e2e tests 先行

测试失败 → agent 定位 → 修复 → 重跑

人只管边界与方向

这在 Claude Code / Codex CLI / Aider / Continue 这类工具中，完全可行，而且是目前 agentic coding 的“最佳实践”。

3️⃣ “十万行代码”并不等于“我为写得多而自豪”

他用了几个关键限定词：

三 个 项 目

代码 + 文档

可运行、可迭代、非 demo

已有项目的深度优化

这更像是一个工程量描述，而不是炫耀。

本质是在说：
“这是一个长期、复杂工程场景，而不是 toy example”

4️⃣ 对 token、并行、时间窗口的理解是专业的

注意他提到的不是“token 用得多爽”，而是：

测试不耗 token

合理安排 agent 的空转时间

并行推进多个项目

人定期 review / 校准

- 这是把 AI 当作异步执行资源在调度，而不是聊天工具。

✅ 技术结论

如果这是发在工程博客 / 技术群 / Hacker News，几乎不会被质疑。

yrqin

kawara 发表于 2025-12-31 03:22
论坛里有个人说下面一番话，请评价

...

再用Claude Opus 4.5来分析你的这个分析

这份评价总体上是客观合理的，而且在几个关键点上比我之前的评价更深入。

## 确实有洞察力的地方

**"架构一致性带宽"这个概念**很精准。并行开发的瓶颈不是 token，而是人脑能同时维护多少套设计决策的一致性。这一点我没有展开。

**对 `--dangerously-skip-permissions` 的警示**是我完全遗漏的。原分享者轻描淡写地提了一句，但这在企业环境里确实是红线。这位评论者把风险具体化了：误改配置、密钥泄露、提交历史污染。

**"成本转移而非消除"的视角**也值得重视。AI 减少的是写代码的时间，但验收、review、治理的成本反而可能上升。这不是免费的生产力提升，是工作性质的转移。

## 稍微苛刻的地方

对"十万行"的质疑合理，但语气略重。原分享者用这个数字大概只是想说"规模不小"，未必是拿来当质量背书。论坛分享不是技术报告，要求"可验证细节"有点高。

"营销味"这个判断可能过了。个人分享带点兴奋感是正常的，不一定是刻意包装。

## 总体判断

这份评价的价值在于：把一个"听起来很顺"的分享拆解成"哪些条件下成立、哪些场景下会翻车"。这种思维方式对准备在自己环境里复制这套流程的人很有帮助。

如果说原分享是"最佳情况下的实践报告"，这份评价就是"把隐含前提和边界条件显式化"。两者结合看会更完整。

yrqin

kawara 发表于 2025-12-31 03:22
论坛里有个人说下面一番话，请评价

...

我个人认为，这份评价略微有些过度延伸了，比如总体评价这里

我对这段话的总体评价
        •        作为“AI 编程实践分享”是可信且有参考价值的，尤其是“测试驱动 + 人控架构”的思路。
        •        作为“工具能力证明”略带滤镜：行数、并行、自动修复这些点都缺乏可验证细节，容易让读者以为“这玩意几乎能自己做项目”。
        •        在企业场景里照抄会出事：特别是权限跳过、数据/密钥、合规、以及后期维护成本。

“这玩意几乎能自己做项目”： 这一点我个人不太认可。真的会有人从我的分享中，得到这样的认知吗？我自认为没有这样的表达意向

“在企业场景里照抄会出事”： 这一点，稍微有些“欲加之罪，何患无辞”的感觉 我也没有提到让大家在企业场景里照抄我的所有步骤、流程吧？

非要扣一些细节，然后给予一些过度延伸的评价，要求一份分享面面俱到，如此的话，Claude Code的创建者的推特分享，或者任何人的分享，都是存在很多类似的细节，可以去批判的


我的分享最终结论是这个：

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

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

yrqin

flyspirit 发表于 2025-12-31 02:26
Vibe coding是大势所趋。 用来做助手是完全没问题。

但那些大佬连续跑几个小时， 生成大量代码如果出了错 ...

深有同感，这也是分享当中没有涉及到的一些问题。
所以在分享的最后，结论仅仅是：在文中提到的前提下，AI Coding更像是一个执行力很强、能长时间专注工作的协作型助手。

至于怎么用好这个新新类型的编程助手，确实是非常值得探索的新领域，有很多的新问题需要去解决

kawara

yrqin 发表于 2025-12-31 07:04
我个人认为，这份评价略微有些过度延伸了，比如总体评价这里

自己玩怎么都无所谓的。每个人有每个人的爱好。我平时打游戏弄影视，自己开心最重要

yrqin

flyspirit 发表于 2025-12-31 02:26
Vibe coding是大势所趋。 用来做助手是完全没问题。

但那些大佬连续跑几个小时， 生成大量代码如果出了错 ...

关于这个

但那些大佬连续跑几个小时， 生成大量代码如果出了错怎么调试， 怎么解决？

我在之前的回帖中也分享了，想要减少vibe coding的bugs，测试驱动非常关键，并且AI Coding工具确实可以持续跑，根据测试结果来修复bugs，然后继续跑测试，这个过程人的参与可以很少。

对于自动化测试没有覆盖到的问题，（希望）一般都是局部小问题，调试+修复什么的，大部分的工作其实也可以直接交给AI Coding工具（比如Claude Code，Codex），我在实际工作中也是如此，效率得到了极大提升。定位错误，寻找root cause，数据校验，业务逻辑分析等等，我都交给AI Coding工具帮我做，而我要做的事情就是引导AI Coding工具去发现并解决问题，根据进展，调整prompts，最后就是审核AI Coding工具给出的解决方案。因为绝大部分都是局部的小问题，人工审核部分是非常简单的，可以说一目了然。

很多时候，AI Coding工具给出的解决方案比我自己能想到的还要更好更周全。当然也有的时候，AI Coding工具给出了过度复杂的解决方案，没有采用更简洁的方案，这个也需要我们人工来介入。

所以人工的code review确实是非常重要的，对于几十万行代码如何做code review，我目前的做法是：主要看关键的数据库设计、核心业务逻辑的实现这一块，其实量也不大；不能过于纠缠于细节，尤其非核心模块、非核心功能的细节。

后续的迭代时间依旧是漫长的，有很多机会去做重构和提升代码库的质量，staging测试的时候，肯定会有很多问题需要解决，production环境也会暴露更深藏的问题。

主要目标是：staging和production环境中出现的问题，希望都是局部的小问题，而不是架构上、系统设计上的大问题。

如何达成这样的目标？那么就需要一开始的时候，就考虑周全了，需要特别资深、特别有经验的程序员来把关，把握大方向。

这些更多是属于系统工程和架构的问题，不是编程问题。虽然不是编程问题，AI Coding/聊天 工具对系统工程和架构的问题也是可以给出很多启发的。多和AI工具聊聊天，也能学到很多东西，至少会更有方向感了

yrqin

关于--dangerously-skip-permissions模式的补充说明：

这个是我的实际使用，主要是为了省事，让claude code自主的持续跑起来，减少人工的干预。

如果觉得这个风险太大，可以尝试这个工具：

How to Keep Claude Code Continuously Running Non-Stop

zhaoxun2018

你把你的十万行ai生成的代码发出来看看。是不是吹牛逼板上高手一看便知。

yrqin

zhaoxun2018 发表于 2025-12-31 09:45
你把你的十万行ai生成的代码发出来看看。是不是吹牛逼板上高手一看便知。 ...

我是经验分享，不是代码分享

其实更重要的是：是否出活了，是否完成了我最初定的项目目标。
现在几个web app都能跑起来并能正常使用，那就可以了

我是开发工具来给自己用的，不是为了看ai写代码有多牛的，它就是一个编程助手；目的达到了即可
如果没有ai coding的辅助，起码要花费多好几倍的时间和精力，去完成同样的事情，我想，要挤业余时间去做的话，那基本上时间跨度就是以周或月计了，不是天。

这样一对比，代码是什么样的，其实是次要的了

cppbug

有没有出现AI写的code产生的的bug AI无法fix的？这种情况下所需要的human efforts会大幅升高

yrqin

zhaoxun2018 发表于 2025-12-31 09:45
你把你的十万行ai生成的代码发出来看看。是不是吹牛逼板上高手一看便知。 ...

或者你描述一个web app需求，稍微详细些的，我可以试着开发一个基本可用的版本，给你试着用用看

今天是Claude Code双倍token的最后一天了，还有不少token余量可以用的 （过期不候了。。。）

yrqin

cppbug 发表于 2025-12-31 10:32
有没有出现AI写的code产生的的bug AI无法fix的？这种情况下所需要的human efforts会大幅升高 ...

目前我还没遇到过

但是AI确实可能会用过于复杂的解决方案，因为它比较难站在精准的业务需求的角度去解决问题，因而没有采用简洁的方案，这个是会发生的；这里需要人的干预

另外就是AI修复bugs也不总是一帆风顺的，有时候需要反复尝试，有时候需要人去提供更多的方向性引导才行

其实AI coding工具很强大，我们有什么问题直接问它就可以了，不管是之前人写的代码，还是AI coding自己写的代码，有什么疑问尽管去问去和它讨论，最终肯定都能整明白的；有任何疑问，都可以去提，去交互，AI Coding和程序员，是可以互相帮助，互相成就的。

你有不明白的地方，可以请教它；你对它有任何建议，也可以去提，去要求。

说明了就是一个任劳任怨、随叫随到、反应敏捷、知识储备丰富、自动化程度很高的编程助手

你多了一个这样的助手，其实是一件好事。

cppbug

yrqin 发表于 2025-12-31 10:39
目前我还没遇到过

但是AI确实可能会用过于复杂的解决方案，因为它比较难站在精准的业务需求的角度去解决 ...

对，我就是这个意思，让AI解决他自己产生的bug有时需要大量的交互和引导，如果只是少量code，其实不如我自己把code写了反而会节省时间。另外AI经常不会提供最优的solution，甚至会使用一些很old已经不被推荐的solution，尤其在比较新的正在快速更新的领域，这也是我不喜欢的地方

但我不是否定AI的作用，我现在写code以及各种task都高度依赖AI，整体来说对效率的提升是非常非常大的。我个人对未来程序员的工作前景比较悲观。

yrqin

cppbug 发表于 2025-12-31 11:25
对，我就是这个意思，让AI解决他自己产生的bug有时需要大量的交互和引导，如果只是少量code，其实不如我 ...

这里有两个地方值得讨论：

“如果只是少量code”： 通常来说，AI可以迅速帮忙定位到错误的代码位置，分析出bug产生的原因以及给出修复的建议；绝大部分情况下，我都能得到很好的解决方案。总之，比我自己来修复要更加简便快捷。极少数情况下，AI修复比我慢，比我差；更常见的是，AI能更加系统性分析解决方案的side effect，更全面考虑边界情况，对我来说，也是一种解放：我只需要关注解决方案是否合理即可。所以，我最近几个月，几乎不会自己修bugs了，因为确实没必要了。不管如何，当AI能把问题找出来了，接下来怎么解决都是可以的（采用AI的方案也好，自己再写一个也好 -- 甚至此时我也会跟AI说一下我的想法，这样AI也能循着我的想法去实现了，这样也是挺好的）

“AI经常不会提供最优的solution，甚至会使用一些很old已经不被推荐的solution”：这个我倒是很少遇到，我感受更多的是 -- AI更快定位到了出问题的地方，同时AI给出的解决方案更全面细致了；只有少数情况下，需要推翻AI的解决方案，重新给AI引导，采用我推荐的方案。也许是你用的工具的问题？目前Claude Opus 4.5 以及 Codex 最新模型 如gpt-5.2-codex high，gpt-5.1-codex max都是非常给力的；gemini 3.0 我也用过，效果还是差一些的，就没再继续用（一个月的免费试用，我只用了几分钟，就放弃了，差距还是有的）

哦，你提到了“尤其在比较新的正在快速更新的领域，这也是我不喜欢的地方”，这个确实也遇到过。。。是个实实在在的问题

另外，我有遇到好几次这种情况：claude code无法解决的问题，交给codex很轻松就解决了，尤其是后端的一些问题；codex无法解决的问题，交给claude code轻松就解决了，比如一些前端的问题，或者linting/typing的问题。

“个人对未来程序员的工作前景比较悲观。”： 有个说法，AI将会淘汰不会使用AI的程序员；不过我个人也是在做一些准备，未雨绸缪吧，万一真被淘汰了，该如何面对？我也是经常有思考这方面的问题的。