作者: yuting, lin

  • AI 写代码半年了,说点真话

    从去年开始,AI 辅助编程突然火起来了。各种消息铺天盖地:AI 要取代程序员了、以后不用学编程了、一个人加 AI 能顶一个团队。

    我在生产环境用 AI 写代码大概半年了,说点真实感受。

    先说好的一面。

    AI 确实能提高效率。以前写一个 CRUD 接口,从建表到写 API 到测试,怎么也要半天。现在把需求描述清楚,AI 生成骨架,我改改就能用。尤其是一些重复性高的代码——表单、列表、基础接口——AI 做得比我快。

    另外就是调试。遇到看不懂的错误信息,丢给 AI,大部分时候能得到有用的解释。特别是那些冷门的第三方库,文档写得不清楚的,AI 见过的坑比我多。

    还有写正则表达式、写 SQL、写 CSS 动画这些——不是不会,是懒得自己写。AI 一把梭,我改改参数就行。

    再说不好的一面。

    AI 生成的代码,看起来很合理,跑起来全是坑。

    上周让它帮忙写一个数据导出的功能,逻辑看起来完全没问题。结果导出来发现,日期格式不对、特殊字符没转义、大文件内存溢出——三个 bug,一个都没跑掉。

    问题是这些 bug 不是语法错误,是逻辑和边界条件的问题。编译器检查不出来,只有跑到真实数据才会暴露。

    所以我的结论是:AI 是很好的辅助工具,但不能信它。

    代码审查还是要做,测试还是要写,边界条件还是要自己想过一遍。AI 可以帮你省掉打字的时间,但决策的时间省不了。

    而且有一个很多人没提的问题:长期依赖 AI 写代码,自己的技术会退化。

    不是说学不到新东西——你描述需求的能力确实会变强。但调试能力、架构感、对系统整体理解——这些东西只有自己动手写才能积累。

    我们现在团队内部的用法是:

    AI 用来加速,不用来替代。

    复杂的逻辑还是自己写,简单的让 AI 代劳。写完之后有人 review,不信任任何 AI 生成的代码。遇到 AI 给的方案,多问一句「为什么这么写」,能解释清楚的再用,解释不清楚的宁愿自己写。

    这么用下来,效率大概提升了 30%-40%。没有外面吹的 10 倍那么夸张,但已经很有价值了。

    最后说一句:AI 不会取代程序员,会用 AI 的程序员可能会取代不会用的。前提是你得知道自己在干什么。

  • WordPress 还是静态站?帮客户选技术栈的一点想法

    做网站这些年,被问得最多的一个问题就是:用什么做?

    WordPress、静态站生成器、自己写前端后端——每个方案都有它的道理,也都有它的坑。我试着说说我的真实看法。

    先说 WordPress。

    很多人觉得 WordPress 过时了,这是误解。WordPress 的问题不在于技术,而在于用它的人。WordPress 本身是个非常好的 CMS,后台管理方便,插件生态丰富。客户自己更新内容、加页面、改文案,只要教一次基本就会。

    但 WordPress 的问题也很明显:

    第一,安全。插件装多了,总有一个会有漏洞。我们的做法是尽量少用插件,能用代码实现的功能就不要装插件。

    第二,性能。默认的 WordPress 确实不算快,但优化一下——用缓存、上 CDN、图片压缩——一般的企业站完全够用。

    第三,主题。市面上很多主题功能多得吓人,但你用到的可能不到 10%。我们一般基于一个基础主题做子主题,只加需要的功能,干净很多。

    什么时候用静态站?

    如果网站内容基本不变——比如品牌落地页、个人作品集、产品介绍——那静态站是更好的选择。

    静态站的好处:快,非常快。没有数据库查询,没有 PHP 执行,服务器只要扔 HTML 文件就行。安全也不用操心,没有后台可以黑。

    缺点?更新内容需要开发人员操作,或者配一个 CMS 后台(比如用 Netlify CMS)。如果客户需要频繁自己改内容,静态站就不太合适了。

    那自己写前后端呢?

    我见过不少团队,一个企业站也要用 React + Node.js + MongoDB 全套。有必要吗?说实话,大部分情况没必要。企业站的核心是内容展示和信息传递,不是交互复杂度。用 React 搭个展示型网站,就跟开卡车去买菜一样——能开,但不合适。

    当然,如果你的网站有很多动态交互、用户系统、实时数据,那确实需要前后端分离。但这种情况我建议直接考虑做 Web 应用,不叫网站了。

    我们的建议很简单:

    – 客户要自己更新内容的 → WordPress
    – 内容固定、追求速度和安全的 → 静态站
    – 有复杂业务逻辑的 → 定制开发

    技术选型没有银弹,适合的就是最好的。

    如果看完还是不确定,可以加微信聊聊,帮你分析一下。不收钱。

  • 小团队接项目这些年,踩过的坑和攒下的经验

    前几天一个老朋友找我聊天,说他公司找了个外包做管理系统,做了三个月,交付的东西完全不能用,钱付了一半,项目烂尾了。问我怎么避免这种事。

    说实话,这种故事我听过太多了。

    外包这个行业,门槛低,下限也低。几台电脑就能注册公司,网上招几个兼职就能接单。价格报得低,先把单拿下再说。后面做不出来怎么办?拖着,拖到客户没脾气,或者拖到客户主动说不做了。

    我们踩过哪些坑?

    第一个坑:需求没聊透就开工。

    早期接单,客户说「做个商城」,我们就开始设计了。结果做着做着发现,客户要的不是商城,是一个带商城功能的经销商管理系统。差了十万八千里。

    现在我们的流程是:先聊,聊透了出文档,文档给客户看,确认了再报价。这个过程可能要一周,但后面不会出大问题。

    第二个坑:答应了自己做不了的需求。

    有些项目,明知道技术上有风险,但当时想「先接下来再说,边做边学」。结果是边做边哭。熬夜搞出来了,质量也不行,自己难受,客户也不满意。

    现在老实了。做不了就是做不了,要么加时间,要么推荐别人。推掉一个项目比搞砸一个项目好得多。

    第三个坑:低估了沟通成本。

    开发最怕的不是技术难题,是「昨天说的和今天说的不一样」。今天说要 A,做完了说明天要 B,然后后天说其实 A 也要。

    我们现在每个项目都有一个共享文档,每次沟通的结果都写进去。不是用来追责,是用来对齐。双方都在上面写,谁改了什么、为什么改,清清楚楚。

    那怎么选一个靠谱的团队?

    说实话,没有标准答案。但我可以给几个参考:

    1. 看看他们之前做过的项目,不问能不能做,问是怎么做的。
    2. 看沟通方式。上来就报低价、催你签约的,谨慎。
    3. 愿意花时间听你讲需求、问很多问题的,大概率是真想帮你做好的。
    4. 小团队不一定比大公司差,关键是谁在写你的代码。

  • 从全栈到工作室:一个开发者的十年

    做开发这行,最开始其实没什么宏大规划。

    大学那会儿写前端,觉着页面能变成能动挺好玩的。后来发现光写页面不够,后台谁写?问了一圈,没人。那就自己学。PHP 写了两年,又觉着不行,得学 Python。然后是数据库、服务器、部署、域名、SSL……就这么一路滚下来,什么都会一点,什么都不精。

    直到做了几年外包,才发现「什么都会一点」其实是个优势。

    客户不需要你只会前端或者只会后端。他有个想法,想把它变成能用的东西。他不在乎你用的是 React 还是 Vue,MySQL 还是 PostgreSQL。他在乎的是:你能不能把这个东西做出来,能不能稳定跑,出问题了能不能找到人。

    2018 年拉了支小团队,到现在十来个人。

    没融过资,也没想过去融。团队扩张很慢,一方面是业务不需要那么多人,另一方面是——人多了管理成本上来,反而不一定能做得更好。现在这样挺好:每个人我都聊过,知道什么水平,能做什么。

    这些年最大的体会是:接项目不是写代码难,是沟通难。

    需求说不清楚、中途改方案、验收标准模糊——这些才是真正的坑。代码反而简单,需求定好了,写就是了。

    所以我们现在接项目,前期沟通花的时间比写代码还多。不是我们效率低,是吃过太多「写完了发现不是客户要的」的亏。

    另一个体会是:小团队没必要装大。

    我们就是十来个人,不是什么集团不是什么国际化公司。跟客户说实话,能做就做,做不了就直说。反而因为这个,合作起来比较顺畅,客户知道跟他沟通的就是真正做事的人。

    十年了,代码还在写。

    有时候想,什么叫资历?不是年数,是踩过的坑够不够多,下次遇到能不能绕过去。这个角度说,我们还算有点资历。