新未名空间

newguy 写了： 2025年 7月 26日 10:54 高手比较一下几个coding的工具？
我只会用ChatGPT直接问，感觉已经非常强大了。刚才我为一个新项目建docker build test 环境，预计干两个钟头，实际半个小时就完了。

目前那个最强，我准备挑个强的学。 devops方面，我对ChatGPT已经完全满意了。
coding方面还想选一选。

现在的AI coding不一样呀。他自带agent能自我校正了。比如我做个App，我给他底层库，告诉它做个Demo App，它读了API，自己把xcode project 配置写了，自己调Swift编译，不过就自己修改。
然后自己加View model 和View。
你一行代码不用写，已经有了个working的框架。然后你在告诉它你的偏好，view model放哪里，要有个独立的data层等等，都替你干了。

sdehc 写了： 2025年 7月 26日 12:09 现在的AI coding不一样呀。他自带agent能自我校正了。比如我做个App，我给他底层库，告诉它做个Demo App，它读了API，自己把xcode project 配置写了，自己调Swift编译，不过就自己修改。
然后自己加View model 和View。
你一行代码不用写，已经有了个working的框架。然后你在告诉它你的偏好，view model放哪里，要有个独立的data层等等，都替你干了。

问下这是哪个自带agent的AI coding啊？
还是Gemini Cli?
付费吗？

速度提高n倍。底层程序员基本被干掉了。

ai继续进化 各种标准化推进,更加适应ai。 早晚吃掉80%的马工的工作

dawangzi 写了： 2025年 7月 26日 12:15 问下这是哪个自带agent的AI coding啊？
还是Gemini Cli?
付费吗？

是Gemini CLI，我不出钱反正。

精辟

sdehc 写了： 2025年 7月 25日 17:29 每个公司，都是20%的工程师有大量产出，60%工程师的产出和替他擦屁股的付出相互抵消，剩下20%靠大声说话，偷别人credit 。
AI一出，我感觉头部20%应该不需要其他人了。就是测试，配置之类的杂活，自己喝杯茶就干了。不需要找个人，开三四个会，这个沟通成本就累人。

外包的好处是三哥擅长处理行政性事务，外包给三哥做测试等等，虽然不解决实际问题，但是最起码让人感觉配置齐全，每周一sync，各种slides，进度条，计划表，让人感觉很正式。

newguy 写了： 2025年 7月 26日 10:54 高手比较一下几个coding的工具？
我只会用ChatGPT直接问，感觉已经非常强大了。刚才我为一个新项目建docker build test 环境，预计干两个钟头，实际半个小时就完了。

目前那个最强，我准备挑个强的学。 devops方面，我对ChatGPT已经完全满意了。
coding方面还想选一选。

Claude Code (Anthropic的) 有超过Cursor AI的趋势，主要优点是context window 大的多(200K tokens).

mrmaja 写了： 2025年 7月 26日 13:54 Claude Code (Anthropic的) 有超过Cursor AI的趋势，主要优点是context window 大的多(200K tokens).

Claude Code早超过Cursor了，现在是所有公司的追赶目标。我们是公司不允许用。

sdehc 写了： 2025年 7月 26日 14:18 Claude Code早超过Cursor了，现在是所有公司的追赶目标。我们是公司不允许用。

为啥不让用

AI都读了design doc了，为啥还要你给他API？下次你让AI读完doc自己完成所有impl试试

再下次别给design doc (engineering spec)，给个RPD让AI试试

sdehc 写了： 2025年 7月 25日 03:31 一次让AI读design doc，我定义了public API，AI自己生成了所有代码。

GAGAMA 写了： 2025年 7月 26日 15:38 AI都读了design doc了，为啥还要你给他API？下次你让AI读完doc自己完成所有impl试试

再下次别给design doc (engineering spec)，给个RPD让AI试试

AI还没那么聪明，API实际体现你自己的设计目标，我是不会让它给我设计的。自己定义好了，加点documentation comments，AI基本上能理解你要干什么。要不你还得给他说一堆话，告诉它。

“比如我做个App” 这恰好是AI的强项，用成熟流程搭建一个新的framwork，属于knowledge密集型work，确实对不懂怎么搭建的人是神器。但大厂里你工作10年都不会有机会让你干这事，SDE是context和逻辑密集型work，再加上点儿experience

sdehc 写了： 2025年 7月 26日 12:09 现在的AI coding不一样呀。他自带agent能自我校正了。比如我做个App，我给他底层库，告诉它做个Demo App，它读了API，自己把xcode project 配置写了，自己调Swift编译，不过就自己修改。
然后自己加View model 和View。
你一行代码不用写，已经有了个working的框架。然后你在告诉它你的偏好，view model放哪里，要有个独立的data层等等，都替你干了。

GAGAMA 写了： 2025年 7月 26日 16:01 “比如我做个App” 这恰好是AI的强项，用成熟流程搭建一个新的framwork，属于knowledge密集型work，确实对不懂怎么搭建的人是神器。但大厂里你工作10年都不会有机会让你干这事，SDE是context和逻辑密集型work，再加上点儿experience

我就在大厂。做了API当然要做App，一个是develop同时可以测试，另一个，做自动化测试的时候，code可以reuse。
大厂SDE当然要有domain knowledge。但是你自己的business logic总是可以细分，细分完了，都是general knowledge。general knowledge上，你就要被AI吊打了。我以为的非常specific的硬件知识AI不如我加Google，但是最近我发现AI对细节其实了解，反过来它给的solution倒是教了我新东西。
现在AI还是要靠experienced architect把大project细分，但是如果你真能做到low coupling high cohesion，剩下80%的工作完全可以AI填空。

sdehc 写了： 2025年 7月 26日 14:18 Claude Code早超过Cursor了，现在是所有公司的追赶目标。我们是公司不允许用。

cursor用Gemini，context不就长了？

Caravel 写了： 2025年 7月 26日 16:43 cursor用Gemini，context不就长了？

Claude的底模就是比其他在编程上强，不是它Agent做的好。

sdehc 写了： 2025年 7月 26日 17:37 Claude的底模就是比其他在编程上强，不是它Agent做的好。

侧重点不一样，丫数学就不行

sdehc 写了： 2025年 7月 26日 16:20 我就在大厂。做了API当然要做App，一个是develop同时可以测试，另一个，做自动化测试的时候，code可以reuse。
大厂SDE当然要有domain knowledge。但是你自己的business logic总是可以细分，细分完了，都是general knowledge。general knowledge上，你就要被AI吊打了。我以为的非常specific的硬件知识AI不如我加Google，但是最近我发现AI对细节其实了解，反过来它给的solution倒是教了我新东西。
现在AI还是要靠experienced architect把大project细分，但是如果你真能做到low coupling high cohesion，剩下80%的工作完全可以AI填空。

把一个大的project想要细分可不是容易的事。关键是软件的模块之间都是又联系的，而且在大部分情况下，即便代码调用上没有直接联系，运行的时候内存，带宽，硬件，数据库这些都是共用的，都会相互影响。AI不知道这些东西的复杂性，生成的东西性能上没有优化，bug还有不少，而且由于代码量太大，人还不好接手。

我自己的经验是，AI在生成<200行输入输出明确的代码时（说白了就是小工具），是很有用很快，而且基本不出错。>=200行，就会开始有bug，而且bug的数目不是随代码行数线形增加，而是二次方增加。超过1000行，想要一次生成，那就到处都是bug，得费很大的气力去debug。如果你对这些逻辑和语言很熟悉，这种情况下还不如自己编。

Whyisthis 写了： 2025年 7月 26日 22:15 把一个大的project想要细分可不是容易的事。关键是软件的模块之间都是又联系的，而且在大部分情况下，即便代码调用上没有直接联系，运行的时候内存，带宽，硬件，数据库这些都是共用的，都会相互影响。AI不知道这些东西的复杂性，生成的东西性能上没有优化，bug还有不少，而且由于代码量太大，人还不好接手。

我自己的经验是，AI在生成<200行输入输出明确的代码时（说白了就是小工具），是很有用很快，而且基本不出错。>=200行，就会开始有bug，而且bug的数目不是随代码行数线形增加，而是二次方增加。超过1000行，想要一次生成，那就到处都是bug，得费很大的气力去debug。如果你对这些逻辑和语言很熟悉，这种情况下还不如自己编。

这个自然。AI做不了大project的architect。你得自己做。整个系统分解成多个子模块，每个模块定义几个interface，每个interface的实现小于一千行。然后你在每个实现里，自己分成多个function，然后每个function就可以让AI做了。

sdehc 写了： 2025年 7月 26日 16:20 我就在大厂。做了API当然要做App，一个是develop同时可以测试，另一个，做自动化测试的时候，code可以reuse。
大厂SDE当然要有domain knowledge。但是你自己的business logic总是可以细分，细分完了，都是general knowledge。general knowledge上，你就要被AI吊打了。我以为的非常specific的硬件知识AI不如我加Google，但是最近我发现AI对细节其实了解，反过来它给的solution倒是教了我新东西。
现在AI还是要靠experienced architect把大project细分，但是如果你真能做到low coupling high cohesion，剩下80%的工作完全可以AI填空。

是的
现在非常专门的domain knowledge AI已经比十几年的老码农强
这一点我老一开始也很惊奇
不信你问问Gemini 2.5 pro关于c++或者会计

sdehc 写了： 2025年 7月 26日 23:08 这个自然。AI做不了大project的architect。你得自己做。整个系统分解成多个子模块，每个模块定义几个interface，每个interface的实现小于一千行。然后你在每个实现里，自己分成多个function，然后每个function就可以让AI做了。

把一个大project decouple成为很多200行左右相互独立互相没有影响的函数，我有时间做这个，还不如自己去写。要把这些东西设计出来并把要求输入给AI，还要说清楚，讲明白，花的时间是我自己写代码的几倍。

AI现在只能做一些小工具，复杂一点的就做不了。就算是你说的那个Swift app的例子，你只用了一两个控件，调用一两个API，AI是可以，但如果一个view上面有10个甚至更多控件，相互之间都有联系，操作一个控件，其他的控件内容也会跟着变，而且还有谁先变，谁后变的时序问题，AI就傻眼了。甚至不是AI傻眼了，你自己就傻眼了，因为你把这些期待behaviors给AI说明白都需要很长时间。要想精确说明那更是要长篇大论。而你想把这种高度entangled的界面decouple成独立的小functions，我觉得基本上不可能：说都说不清楚，就算说清楚，AI也会抓瞎，因为AI没法测试看效果。

我以前有一个Android的APP，我想把它翻译成Swift，试过各种AI，直接把Android的JAVA代码丢进去，让AI翻译成Swift。代码应该是很精确的behavior的描述了，结果AI还是不行，翻译是可以翻译，但是运行起来错误一大堆，甚至不能编译，还得我自己调。当然我那时对Swift不熟悉，只能借用AI，否则有些东西google上根本搜不到。随着对Swift逐步熟悉，我现在就不怎么用AI了，最多把它当更好的google。所以我看你在这里吹AI怎么牛逼，估计是没有什么大项目的经验，只是在大厂做过一些小模块而已。

大项目design factors/blockers 很多都不是code level，有时候是产品限制，有时候是L&C，更多时候是Legacy 和backward compatibility. 这些context是没法从code里看到的，有的甚至连doc都没有。要不然TL每天不停开会难道是在补CS domain knowledge？

我的point是AI确实能帮你干活儿，但AI能帮的都是低级活儿，都是不需要考虑历史和其他dependency，建个standalone的独立service这种活儿。这些本来就没啥难度，无非就是有了AI开发时间由3天变1天而已，凡是code能解决的问题都不叫问题。真正复杂的，让人头疼的问题，我没看到AI能有啥大的帮助。你觉得帮助很大是因为你还是implementation focused

sdehc 写了： 2025年 7月 26日 16:20 我就在大厂。做了API当然要做App，一个是develop同时可以测试，另一个，做自动化测试的时候，code可以reuse。
大厂SDE当然要有domain knowledge。但是你自己的business logic总是可以细分，细分完了，都是general knowledge。general knowledge上，你就要被AI吊打了。我以为的非常specific的硬件知识AI不如我加Google，但是最近我发现AI对细节其实了解，反过来它给的solution倒是教了我新东西。
现在AI还是要靠experienced architect把大project细分，但是如果你真能做到low coupling high cohesion，剩下80%的工作完全可以AI填空。