转寄人: ZabraZoe (ZabraZoe)
标 题: [心得][讨论]2个多月，AI 产出了21万行代码，这算多吗？
发信站: 水木社区 (Tue Sep 1 09:21:47 2026)
来 源: 124.65.78.222
【以下内容由 ZabraZoe 转寄于 Programming 版】
标 题: [心得][讨论]2个多月，AI 产出了21万行代码，这算多吗？
发信站: 水木社区 (Tue Sep 1 09:21:47 2026)
来 源: 124.65.78.222
【以下内容由 ZabraZoe 转寄于 Programming 版】
最近统计了一下手上的一个业余项目，有点意外：
开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/TSX 代码：
生产代码约 12.5 万行
测试代码约 9 万行
TS/TSX 文件约 1000 个
函数接近 2 万个
已排除依赖、构建产物和明显的生成文件
不过先说明一下：
这些代码基本都是 AI 生成的，不是我一行一行敲出来的。
我的主要工作是：
提出整体架构和模块划分建议
描述需求和功能目标
设计接口、数据流和约束
审查 AI 生成的代码
调试、验证和决定是否接受
发现架构问题后要求重构
必要时推倒重来
而且这 21 万行只是最后留下来的代码。开发过程中还有大量代码被删掉或重写过，累计让 AI 生成、修改、重构的代码量，估计是最终代码量的几倍。
有些阶段甚至没有明确的新功能可做，我就让 AI 对已有代码进行重构，比如：
拆分大模块
抽象重复逻辑
重新设计类型和接口
补齐测试
优化目录结构
统一错误处理
把早期“能跑”的实现改成更容易维护的版本
所以现在有点困惑：
两个月最终留下21万行代码，AI 实际生成量还要高几倍，这算开发效率高，还是说明项目已经膨胀得有点厉害？
我自己的感受是，AI 让“写代码”变得非常便宜，但也让“重写代码”变得非常便宜。以前一段代码只要能跑，可能就会先凑合着；现在发现架构不舒服，直接让 AI 重构甚至推倒重来，成本低了很多。
但问题也来了：代码量很大，并不一定代表工作量大，更不一定代表项目有价值。
行数里面包括很多：
UI 组件
类型和协议定义
测试代码
工具封装
胶水代码
配置和适配层
AI 生成后又被重构过的实现
真正需要人做判断的，可能不是“怎么把这段代码写出来”，而是：
这段代码应该不应该存在？
这个抽象是否合理？
这个模块边界会不会在三个月后变成灾难？
所以想请教一下各位：
两个月最终留下 21 万行代码，大家觉得这个规模算大吗？
AI 负责实现，人负责架构、取舍、审查和验收，这种工作应该怎么衡量？
AI 时代，代码行数还有参考价值吗？
大家觉得评价开发效率，更应该看代码量、功能数量、测试覆盖率，还是系统最终是否稳定可维护？
现在越来越觉得：
AI 让代码生产变得很快，但真正稀缺的不是打字速度，而是判断哪些代码值得留下。
21万行要看你的项目规模啊，外人哪能知道这是多还是少
你可以自己审查一下，然后让AI去优化
【 在 miromiro 的大作中提到: 】
: 最近统计了一下手上的一个业余项目，有点意外：
: 开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/TSX 代码：
: 生产代码约 12.5 万行
AI 很喜欢写重复的代码。上下文窗口太小。
你叫它减少到 1/10 再说吧。
【 在 miromiro 的大作中提到: 】
: 最近统计了一下手上的一个业余项目，有点意外：
: 开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/TSX 代码：
: 生产代码约 12.5 万行
要是 AI 写代码直接上线商用，那才牛
但比代码量，对生成式 AI 来说就没啥可吹的
【 在 miromiro 的大作中提到: 】
:最近统计了一下手上的一个业余项目，有点意外：:开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/
我总体的感觉是AI会过度设计，很多条件判断会重复，数据结构也会设计得比较复杂，这些代码可以进行大幅优化
【 在 miromiro 的大作中提到: 】
: 最近统计了一下手上的一个业余项目，有点意外：
: 开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/TSX 代码：
: 生产代码约 12.5 万行
: 测试代码约 9 万行
给公司带来的收益是啥？
【 在 miromiro 的大作中提到: 】
: 最近统计了一下手上的一个业余项目，有点意外：
: 开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/TSX 代码：
: 生产代码约 12.5 万行
这是我个人业余时间做的项目，不是公司项目。不过公司里已经有不少人使用我的软件作为日常开发工具，反馈还不错。
【 在 overcomeunic 的大作中提到: 】
: 给公司带来的收益是啥？
这个提醒很有价值。我也担心 AI 在上下文不足时会倾向于重复封装、增加保护性判断，导致代码膨胀。
【 在 sjsznh 的大作中提到: 】
: 我总体的感觉是AI会过度设计，很多条件判断会重复，数据结构也会设计得比较复杂，这些代码可以进行大幅优化
同意，单纯代码量确实没什么可吹的，我发帖主要是想讨论 AI 辅助开发下代码规模和效率应该怎么衡量。这个项目目前还在验证阶段，后面还是要看能否稳定运行、真正被使用，以及投入的时间和最终产出是否匹配。
【 在 hgoldfish 的大作中提到: 】
: AI 很喜欢写重复的代码。上下文窗口太小。
: 你叫它减少到 1/10 再说吧。
是的，脱离项目规模和功能范围单看 21 万行没有太大意义。我也不把这个数字当成成果，只是觉得在两个月内达到这个规模比较意外。下一步会重点审查架构、重复代码、测试有效性和实际运行效果，再用最终可维护、可交付的代码量来评价。
【 在 PaoloMaldini 的大作中提到: 】
: 21万行要看你的项目规模啊，外人哪能知道这是多还是少
: 你可以自己审查一下，然后让AI去优化
你可以跟ai聊聊代码质量，如果质量方面没啥问题，比如ai喜欢重复写相同功能的代码（其实人也一样，尤其是团队项目），比如ai不太喜欢用类型系统约束，喜欢用string代替enum等等比较常见的低质行为，那就OK了。你这是ai时代使用ai的正确姿势。不用去关心细节，你把你当director驱动方向定义规则就行。
下面有些人的回复不用看了，什么削减到1/10之类的。我比较喜欢往前看，去预测尚未发生的事情，已经发生的事情我都懒得聊了，比如这几天数学界频繁引爆核弹。有的人真就是非得核弹怼脸上了才愿意相信这一天真的到来了。
【 在 miromiro 的大作中提到: 】
: 最近统计了一下手上的一个业余项目，有点意外：
: 开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/TSX 代码：
: 生产代码约 12.5 万行
很厉害
现在AI CODER超级无敌厉害，但真不知道还能产出多少增量了
【 在 miromiro 的大作中提到: 】
: 这是我个人业余时间做的项目，不是公司项目。不过公司里已经有不少人使用我的软件作为日常开发工具，反馈还不错。
赞，完整的项目！
两个月最终留下 21 万行代码，大家觉得这个规模算大吗？ —— 大
AI 负责实现，人负责架构、取舍、审查和验收，这种工作应该怎么衡量？ —— 价值交付。一直都是这。
AI 时代，代码行数还有参考价值吗？ —— 以前也没有。
大家觉得评价开发效率，更应该看代码量、功能数量、测试覆盖率，还是系统最终是否稳定可维护？ —— 最终。但是用户反馈来了，怎么改
最后一条，是整个行业要验证的。
软件工程、开发方法论，类似 敏捷开发、DevOps这些，
以后大家提起软件开发，主流的组织形式和生产形式，是什么。
【 在 MrGoodGood 的大作中提到: 】
: 赞，完整的项目！
: 两个月最终留下 21 万行代码，大家觉得这个规模算大吗？ —— 大
: AI 负责实现，人负责架构、取舍、审查和验收，这种工作应该怎么衡量？ —— 价值交付。一直都是这。
哈哈，string 代替 enum 这个说得太准了，它就爱这么偷懒。
director 这个说法我认。这两个月最大的感受就是，你规则写得越死，它活儿越好；你要是含糊一句"看着办"，它真能给你堆出一座山。
【 在 lvsoft 的大作中提到: 】
: 你可以跟ai聊聊代码质量，如果质量方面没啥问题，比如ai喜欢重复写相同功能的代码（其实人也一样，尤其是团队项目），比如ai不太喜欢用类型系统约束，喜欢用string代替enum等等比较常见的低质行为，那就OK了。你这是ai时代使用ai的正确姿势。不用去关心细节，你把你当director驱动方向定义规则就行。
: 下面有些人的回复不用看了，什么削减到1/10之类的。我比较喜欢往前看，去预测尚未发生的事情，已经发生的事情我都懒得聊了，比如这几天数学界频繁引爆核弹。有的人真就是非得核弹怼脸上了才愿意相信这一天真的到来了。
谢谢。增量这个我也想过，感觉生成这块确实快摸到顶了，但验证这块还差得远。现在的瓶颈早不是它写多快了，是我验多快。哪天验证也能大幅提速，增量估计还能再翻一倍。
【 在 overcomeunic 的大作中提到: 】
: 很厉害
: 现在AI CODER超级无敌厉害，但真不知道还能产出多少增量了
谢谢。行数这玩意儿以前不算好指标，现在是彻底不能看了——以前写得多好歹还费钱，现在连钱都不费了。
用户反馈来了怎么改，这反而是这种模式最舒服的地方。公司同事提的小改动，基本当天就能改完发出去，搁以前的业余项目，这响应速度想都不敢想。
【 在 MrGoodGood 的大作中提到: 】
: 赞，完整的项目！
: 两个月最终留下 21 万行代码，大家觉得这个规模算大吗？ —— 大
: AI 负责实现，人负责架构、取舍、审查和验收，这种工作应该怎么衡量？ —— 价值交付。一直都是这。
如果能快速改，质量就没问题。
证明：
1 你参与了写的过程，知道问题在哪儿，指导AI
2 需求文档，技术文档，代码结构对应的不错，AI能很快获得bug所在的工作面（上下文），而且修改符合SOLID，不是屎山泼屎法。
当然也可能，你这项目简单，是个大型的CRUD系统。前端页面组件20万行。后端1万行。框架9000，业务1000。
【 在 miromiro 的大作中提到: 】
【 在 MrGoodGood 的大作中提到: 】
: 赞，完整的项目！
: 两个月最终留下 21 万行代码，大家觉得这...
我的经验，上生产的代码
没啥复杂逻辑的crud代码，哗哗写，很好
复杂业务逻辑的，特别是多特性混到一起的，ai写的更复杂，然后特别容易写错，读明白要很多时间，让它改还经常改不对，可能最后还是自己动手
对，这个感觉太明显了。
CRUD 这种活，AI 确实写得飞快，改起来也方便。
【 在 lioncat7 的大作中提到: 】
: 我的经验，上生产的代码
: 没啥复杂逻辑的crud代码，哗哗写，很好
: 复杂业务逻辑的，特别是多特性混到一起的，ai写的更复杂，然后特别容易写错，读明白要很多时间，让它改还经常改不对，可能最后还是自己动手
文档很重要，但是文档的维护也同等重要了。AI 写文档太方便了，不知不觉就积了一大堆，但改代码时有时会忘记同步更新。结果后面再让它干活，它不看代码，反而照着旧文档理解架构，最后就容易越走越偏。
所以我现在会隔一段时间让它重新梳理一遍文档，AI 做代码 review 的时候，也会要求它顺便检查相关文档有没有过期。
【 在 MrGoodGood 的大作中提到: 】
: 如果能快速改，质量就没问题。
: 证明：
: 1 你参与了写的过程，知道问题在哪儿，指导AI
我今年半年自己也做了个自研项目，全量AI写，功能是多服务rust+nodejs游戏后端+rust游戏客户端，开发过程自己只审核文档，不审核代码，测试流程方面单元测试不管，真机测试自己参与验证，对流程有疑惑的就看文档或者让AI讲解，目前代码量70万行多点，基本架构能跑起来，还缺大量美术优化，我目前感觉，确实可以替代程序员，能做出能用的实际产品
这一点我的经验是，开发功能我都是先要求他写开发清单并使用我的skill，我的skill会强制要求在清单验收的时候，必须同步文档。除了修bug，其他情况不会直接让AI写代码，必须走开发清单方式开发代码，更新文档和验收
【 在 miromiro 的大作中提到: 】
: 文档很重要，但是文档的维护也同等重要了。AI 写文档太方便了，不知不觉就积了一大堆，但改代码时有时会忘记同步更新。结果后面再让它干活，它不看代码，反而照着旧文档理解架构，最后就容易越走越偏。
: 所以我现在会隔一段时间让它重新梳理一遍文档，AI 做代码 review 的时候，也会要求它顺便检查相关文档有没有过期。
我自己给一个上生产的后端撸了一个方便管理查看和统计的前端
能跑起来很容易 但是你要是去看业务逻辑 就会发现很多问题
因为我不懂前端 所以每次前端有问题 调试都非常崩溃 哪怕后面有了可以直接访问前端页面的也很累
所以ai做demo很快 上生产你还是得能看懂代码
【 在 zerg136 的大作中提到: 】
: 我今年半年自己也做了个自研项目，全量AI写，功能是多服务rust+nodejs游戏后端+rust游戏客户端，开发过程自己只审核文档，不审核代码，测试流程方面单元测试不管，真机测试自己参与验证，对流程有疑惑的就看文档或者让AI讲解，目前代码量70万行多点，基本架构能跑起来，还缺大量美术优化，我目前感觉，确实可以替代程序员，能做出能用的实际产品
只是web页面调试还好吧。。指导AI打日志，然后console截日志+直接截屏，一般能搞定
【 在 lioncat7 的大作中提到: 】
: 我自己给一个上生产的后端撸了一个方便管理查看和统计的前端
: 能跑起来很容易 但是你要是去看业务逻辑 就会发现很多问题
: 因为我不懂前端 所以每次前端有问题 调试都非常崩溃 哪怕后面有了可以直接访问前端页面的也很累
赞！
70万行太厉害了，只检查文档，脑力劳动也很大。再考虑半年的时间。一定很辛苦。
能控制到这样的程度，编程达人，AI驾驭师，厉害的软件工程控制能力。游戏计划到哪里发布？
【 在 zerg136 的大作中提到: 】
: 我今年半年自己也做了个自研项目，全量AI写，功能是多服务rust+nodejs游戏后端+rust游戏客户端，开发过程自己只审核文档，不审核代码，测试流程方面单元测试不管，真机测试自己参与验证，对流程有疑惑的就看文档或者让AI讲解，目前代码量70万行多点，基本架构能跑起来，还缺大量美术优化，我目前感觉，确实可以替代程序员，能做出能用的实际产品
根据我的经验，可以认为全是没用的，立帖为证，2个月以后再来看
【 在 miromiro 的大作中提到: 】
: 最近统计了一下手上的一个业余项目，有点意外：
: 开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/TSX 代码：
: 生产代码约 12.5 万行
呵呵
【 在 jlynnc 的大作中提到: 】
: 根据我的经验，可以认为全是没用的，立帖为证，2个月以后再来看
你写的代码AI的可调试性非常重要，我花了不少精力解决这个问题，一旦你的AI可以自如的调试你的功能和业务后，你会很省事的。 遇到bug，或者业务逻辑，你可以让它模拟真实用户去操作，一方面可以验证所有流程，发现问题它可以自己解决。 另外一方面，它也可以去复现bug。 这些AI都能很好的处理。 目前主要问题是AI对于图形和UI是没有人类的感知的，它可能知道UI的对或者错，但是对于布局的很明显问题，它都不知道，比如一个UI，经常它做一个功能显示的部分明显偏了，或者放的位置不对，人一看就不明白，AI的话，截图给他他都不觉得异常，除非你告诉他这个布局有问题。
【 在 lioncat7 的大作中提到: 】
: 我自己给一个上生产的后端撸了一个方便管理查看和统计的前端
: 能跑起来很容易 但是你要是去看业务逻辑 就会发现很多问题
: 因为我不懂前端 所以每次前端有问题 调试都非常崩溃 哪怕后面有了可以直接访问前端页面的也很累
嗯嗯，这个方法不错。 按照人的开发模式。
【 在 zerg136 的大作中提到: 】
: 这一点我的经验是，开发功能我都是先要求他写开发清单并使用我的skill，我的skill会强制要求在清单验收的时候，必须同步文档。除了修bug，其他情况不会直接让AI写代码，必须走开发清单方式开发代码，更新文档和验收
很强！
但是美术方面我感觉确实还是AI的弱项。
它对代码布局描述很懂，但是它对真实UI感知不行，你要告诉它如何排版，这点很累，需要写一堆文字告诉它。
【 在 zerg136 的大作中提到: 】
: 我今年半年自己也做了个自研项目，全量AI写，功能是多服务rust+nodejs游戏后端+rust游戏客户端，开发过程自己只审核文档，不审核代码，测试流程方面单元测试不管，真机测试自己参与验证，对流程有疑惑的就看文档或者让AI讲解，目前代码量70万行多点，基本架构能跑起来，还缺大量美术优化，我目前感觉，确实可以替代程序员，能做出能用的实际产品
ui其实也是ai强，就看你调用什么工具了
你要是有什么具体要求，先丢一个样例给他很靠谱。
【 在 miromiro 的大作中提到: 】
: 标 题: Re: [心得][讨论]2个多月，AI 产出了21万行代码，这算多吗？
: 发信站: 水木社区 (Thu Aug 27 09:38:25 2026), 站内
: 【 在 zerg136 的大作中提到: 】
: : 我今年半年自己也做了个自研项目，全量AI写，功能是多服务rust+nodejs游戏后端+rust游戏客户端，开发过程自己只审核文档，不审核代码，测试流程方面单元测试不管，真机测试自己参与验证，对流程有疑惑的就看文档或者让AI讲解，目前代码量70万行多点，基本架构能跑起来，还
: 贝罅棵朗跤呕夷壳案芯酰肥悼梢蕴娲绦蛟保茏龀瞿苡玫氖导什
: 很强！
: 但是美术方面我感觉确实还是AI的弱项。
: 它对代码布局描述很懂，但是它对真实UI感知不行，你要告诉它如何排版，这点很累，需要写一堆文字告诉它。
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 99.255.254.*]
这方面我想自动化，但是目前效果不是很好
我的办法是，提示词直接生成图片，这个用豆包或者外部的其他ai，然后让gpt直接根据样板图和我的UI组件配置，自己去调整来生成样板图的UI
【 在 miromiro 的大作中提到: 】
: 很强！
: 但是美术方面我感觉确实还是AI的弱项。
你用的哪个AI编程模型，采用多agent开发吗
嗯嗯，自己调UI是目前感觉比较费时间的工作。
【 在 zerg136 的大作中提到: 】
: 这方面我想自动化，但是目前效果不是很好
: 我的办法是，提示词直接生成图片，这个用豆包或者外部的其他ai，然后让gpt直接根据样板图和我的UI组件配置，自己去调整来生成样板图的UI
主要用Claude Code的 Fable 和 Opus
偶尔用K3和千问，也用过deepSeek
多agent吧，让多个agent AI fork并行开发； 一个专用的Agent，它负责review和跑测试，通过后，它负责合并到main branch代码，这项工作只分配了一个Agent（多个同时合并的话，太多问题了）
【 在 IgotU 的大作中提到: 】
: 你用的哪个AI编程模型，采用多agent开发吗
re
一帮连价值二字都不知道的在这个版瞎哔哔，徒增笑尔~
【 在 jlynnc 的大作中提到: 】
: 根据我的经验，可以认为全是没用的，立帖为证，2个月以后再来看
赞！平地惊雷，气魄惊人。
天下英雄唯二位也。
【 在 ztysys 的大作中提到: 】
: re
: 一帮连价值二字都不知道的在这个版瞎哔哔，徒增笑尔~
一看就是没正经搞过的。。。
真正的坑都闭而不谈，底层坑完全不知道，也配谈价值。。。。
【 在 MrGoodGood 的大作中提到: 】
: 赞！平地惊雷，气魄惊人。
: 天下英雄唯二位也。
赞！经历丰富。
这里的底层，是大模型的底层，还是项目的底层？
为啥会有坑。
【 在 ztysys 的大作中提到: 】
: 一看就是没正经搞过的。。。
: 真正的坑都闭而不谈，底层坑完全不知道，也配谈价值。。。。
一般意义上的底层的再下一层/二层。。。
知道什么是价值吗？
【 在 MrGoodGood 的大作中提到: 】
: 赞！经历丰富。
: 这里的底层，是大模型的底层，还是项目的底层？
: 为啥会有坑。
赞！表达清晰，翔实有物。
赞！道不轻传，点到为止。
学到很多。
【 在 ztysys 的大作中提到: 】
: 一般意义上的底层的再下一层/二层。。。
: 知道什么是价值吗？
规则可以让 AI 自学习纪录起来。
目前 AI 还不太懂软件工程:
1. 代码质量相比手写的稍低。不过仅限人类自己非常熟悉的领域。
2. 大多数功能现实中没用户，可以砍掉。
3. 不懂得分配精力。核心模块应该多花时间优化。业务层相对可以随便。
【 在 miromiro 的大作中提到: 】
: 谢谢。增量这个我也想过，感觉生成这块确实快摸到顶了，但验证这块还差得远。现在的瓶颈早不是它写多快了，是我验多快。哪天验证也能大幅提速，增量估计还能再翻一倍。
AI 现在哗啦啦写经常是因为不懂得抽象。
【 在 lioncat7 的大作中提到: 】
: 我的经验，上生产的代码
: 没啥复杂逻辑的crud代码，哗哗写，很好
: 复杂业务逻辑的，特别是多特性混到一起的，ai写的更复杂，然后特别容易写错，读明白要很多时间，让它改还经常改不对，可能最后还是自己动手
卖钱了吗？
【 在 zerg136 的大作中提到: 】
: 我今年半年自己也做了个自研项目，全量AI写，功能是多服务rust+nodejs游戏后端+rust游戏客户端，开发过程自己只审核文档，不审核代码，测试流程方面单元测试不管，真机测试自己参与验证，对流程有疑惑的就看文档或者让AI讲解，目前代码量70万行多点，基本架构能跑起来，还缺
: 罅棵朗跤呕夷壳案芯酰肥悼梢蕴娲绦蛟保茏龀瞿苡玫氖导什
卖不了吧。光搭架子搞基础了，美工和完整的玩法剧情没搞出来多少。。
【 在 hgoldfish 的大作中提到: 】
: 卖钱了吗？
哈哈。
所以我建议砍掉 AI 写的 90% 代码。
反正没人用。有好多人让 AI 写出来的，连自己都不用。
我现在用 AI 写的一半代码至少还是些自己每天使用的小工具哈哈。
【 在 jlynnc 的大作中提到: 】
: 根据我的经验，可以认为全是没用的，立帖为证，2个月以后再来看
那啥不直接使用 unity 等等现成的引擎。;-)
【 在 zerg136 的大作中提到: 】
: 卖不了吧。光搭架子搞基础了，美工和完整的玩法剧情没搞出来多少。。
你看你，正儿八经的问题不敢正面回答，只会玩这种低级文字套路
臊不臊。。。
【 在 MrGoodGood 的大作中提到: 】
: 赞！表达清晰，翔实有物。
: 赞！道不轻传，点到为止。
: 学到很多。
赞！ 言之有物。
连环发问，振聋发聩。沟通大乘法，渡人功德无量。
【 在 ztysys 的大作中提到: 】
: 你看你，正儿八经的问题不敢正面回答，只会玩这种低级文字套路
: 臊不臊。。。
unity的ECS支持的不太好，代码写起来也怪，所以我试试rust的
反正也不是公司正式项目，就自己尝试了
【 在 hgoldfish 的大作中提到: 】
: 那啥不直接使用 unity 等等现成的引擎。;-)
尝试用AI清理重构粪山代码
效果特别好
AI可以理解不同时期不同生产者的思路
一些长期的困扰，不得不用硬编码解决的问题都给处理清楚了
关键是注释什么都很清晰
赘余代码明显减少
【 在 miromiro 的大作中提到: 】
: 最近统计了一下手上的一个业余项目，有点意外：
: 开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/TSX 代码：
: 生产代码约 12.5 万行
赞！妙用。
AI吃尸米可以细嚼，还能分出不同层次和味道。
打破了人类吃X不嚼的物理约束。
【 在 waterbox 的大作中提到: 】
: 尝试用AI清理重构粪山代码
: 效果特别好
: AI可以理解不同时期不同生产者的思路
AI时代，老注释也要升级：
Dear maintainer:
Once you are done trying to 'optimize' this routine,
and have realized what a terrible mistake thatwas,
please increment the following counter as a warning
to the next guy:
total_hours_wasted_here = 42
AI 时代也要升级：
increment the following counter ..... as a warning ...
total_TOKENs_wasted_here = ...
【 在 MrGoodGood 的大作中提到: 】
: 赞！妙用。
: AI吃尸米可以细嚼，还能分出不同层次和味道。
: 打破了人类吃X不嚼的物理约束。
很少了，还没当年解放女那个女军官手搓的多
【 在 miromiro 的大作中提到: 】
: 最近统计了一下手上的一个业余项目，有点意外：
: 开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/TSX 代码：
: 生产代码约 12.5 万行
: 测试代码约 9 万行
赞！军中之花李聪娜
解放军美女尖兵：90昼夜主持编写40万行代码
【 在 frankyang926 的大作中提到: 】
: 很少了，还没当年解放女那个女军官手搓的多
[upload=1][/upload]
claude code还是其他什么？
【 在 miromiro 的大作中提到: 】
: 标 题: [心得][讨论]2个多月，AI 产出了21万行代码，这算多吗？
: 发信站: 水木社区 (Sun Aug 23 22:49:51 2026), 站内
: 最近统计了一下手上的一个业余项目，有点意外：
: 开发了两个多月，仓库里最终留下了大约 21.5万行 TypeScript/TSX 代码：
: 生产代码约 12.5 万行
: 测试代码约 9 万行
: TS/TSX 文件约 1000 个
: 函数接近 2 万个
: 已排除依赖、构建产物和明显的生成文件
: 不过先说明一下：
: 这些代码基本都是 AI 生成的，不是我一行一行敲出来的。
: 我的主要工作是：
: 提出整体架构和模块划分建议
: 描述需求和功能目标
: 设计接口、数据流和约束
: 审查 AI 生成的代码
: 调试、验证和决定是否接受
: 发现架构问题后要求重构
: 必要时推倒重来
: 而且这 21 万行只是最后留下来的代码。开发过程中还有大量代码被删掉或重写过，累计让 AI 生成、修改、重构的代码量，估计是最终代码量的几倍。
: 有些阶段甚至没有明确的新功能可做，我就让 AI 对已有代码进行重构，比如：
: 拆分大模块
: 抽象重复逻辑
: 重新设计类型和接口
: 补齐测试
: 优化目录结构
: 统一错误处理
: 把早期“能跑”的实现改成更容易维护的版本
: 所以现在有点困惑：
: 两个月最终留下21万行代码，AI 实际生成量还要高几倍，这算开发效率高，还是说明项目已经膨胀得有点厉害？
: 我自己的感受是，AI 让“写代码”变得非常便宜，但也让“重写代码”变得非常便宜。以前一段代码只要能跑，可能就会先凑合着；现在发现架构不舒服，直接让 AI 重构甚至推倒重来，成本低了很多。
: 但问题也来了：代码量很大，并不一定代表工作量大，更不一定代表项目有价值。
: 行数里面包括很多：
: UI 组件
: 类型和协议定义
: 测试代码
: 工具封装
: 胶水代码
: 配置和适配层
: AI 生成后又被重构过的实现
: 真正需要人做判断的，可能不是“怎么把这段代码写出来”，而是：
: 这段代码应该不应该存在？
: 这个抽象是否合理？
: 这个模块边界会不会在三个月后变成灾难？
: 所以想请教一下各位：
: 两个月最终留下 21 万行代码，大家觉得这个规模算大吗？
: AI 负责实现，人负责架构、取舍、审查和验收，这种工作应该怎么衡量？
: AI 时代，代码行数还有参考价值吗？
: 大家觉得评价开发效率，更应该看代码量、功能数量、测试覆盖率，还是系统最终是否稳定可维护？
: 现在越来越觉得：
: AI 让代码生产变得很快，但真正稀缺的不是打字速度，而是判断哪些代码值得留下。
: 后续：
: 我发这个帖子的主要意思，是想讨论在 AI 时代应该如何开发和维护代码。
: 以前我们可能习惯于逐行审查代码，确保每一行都经过人工确认；但在 AI 辅助开发之后，代码产出量会明显增加，确实也更容易出现重复实现、冗余逻辑和过度设计等问题。
: 但另一方面，AI 带来的开发效率提升也是实际存在的。问题是：在这种情况下，我们是否还需要像过去一样逐行审查？逐行审查的成本，会不会抵消 AI 带来的效率收益？
: 我的想法是，人工把关的重点可能需要从“每一行代码是否正确”，转向架构设计、模块边界、核心逻辑、数据流、安全性、测试覆盖和最终运行效果。只要整体架构和关键路径经过严格审查，普通业务代码是否还需要逐行确认，可能值得重新讨论。
: 当然，这并不是说可以完全不审查代码，而是想讨论：在 AI 时代，代码审查的粒度和方式是否应该发生变化。
: ※ 修改:·miromiro 于 Aug 25 02:08:05 2026 修改本文·[FROM: 99.255.254.*]
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 99.255.254.*]
主要是Claude Code
【 在 serprathu 的大作中提到: 】
: claude code还是其他什么？