2025年前，LLM确实能写代码，也确实能够处理一些小型或者玩具项目，但是在中等或以上规模的项目的时候，就会进入边界地狱。

人写代码起码是会在组织的过程中会思考架构，以及代码中的边界情况，也是在写的过程中去确定这些边界行为，去捋这些不同状态交杂的各种情况下一些细节的业务逻辑。

以前的LLM，如果你在你的文档中没说明这些细节，它会选一种比较普遍的做法来填充你的边界行为，最后在测试环节，你会发现程序有一大堆不符合预期的边界需要一个一个对齐，相比在古法编程的过程中，你会有一个全局观，你知道哪里可能存在什么问题，这边界是在哪一步上面的，我调整的这里会对其它地方的影响，这都在人的脑子中思考。但那个时候的LLM的不符合预期的边界，只能用地狱形容，你不知道有多少边界需要调整，而且你没了这段代码的全局观，你也不知道调整这里是否会影响任何一个步骤，是否会产生新的边界问题。

这个时候的vibe coding，需要人大量的去测试，把所有边界问题暴露出来，再不停的烧token去修。而且LLM还存在一定的幻觉率，老是构造不存在的逻辑，同样的逻辑不停的造不同的轮子，这些都需要各种skill甚至各种规则提示词去限制，问题它还是有那么点几率会搞错，所以它根本不可能在小型项目上落地，毕竟生产环境的代码是需要责任的。举个极端一点的例子就是，一个业务功能在操作上千万的价值的资产的时候，你很难不去仔细的审核LLM的代码，当它产生错误的时候，这个损失是需要你背锅的时候，你很难去相信LLM输出的那个对于你来说是黑盒子的业务。

但说实话，如果是在需要事无巨细地把这些边界都理清楚的情况下，LLM开发，跟人工开发没有什么不同，区别在于LLM帮码农输入代码罢了，很多坑还是要踩过才知道。

然后就是这个奇点的到来，LLM突然指令的遵循度，在开发上对中等程度的项目，你发现它突然有一定的大局观了，它开始很懂多个业务之间交杂的情况了，开始会对复合状态下业务边界进行处理了。虽然vibe coding仍旧是一种面向测试的开发，但是这种边界问题已经控制到一个比较能接受的范围内了。对于把整个开发测试的流程完全代理给LLM后，起码在中型项目中，能在较短的时候内，出一个看起来还可以的版本。

对于我们这些老码农来说，确实开发轻松不少，以前需要一个月开发的东西，现在在需求清楚，一天内就可以出个基本版本，然后调整测试一两天，三天，可能就能弄出一个成品。

其实对于老码农来说，这么长的古法编程过程中，其实是有意识到的，本身开发过程中，很多模式相似的业务，但是偏偏就是不能直接复制过来用，就算复制过来，为了契合新业务，需要对原代码进行大量的调整。而要把这个模式封装成控件，特别好用的控件，也是需要大量的时间和思考去改造的。现在LLM，这种任务已经能比较放心的交给它们，它已经能很好的处理这种模式变换的业务改写，甚至封装，甚至能帮你发现一些连你都注意不到的问题。现在LLM最牛逼的能力，其实是已经把CRUD的开发的模式已经完全融入到那堆参数中了。

其实大部分软件开发，都是某种模式罢了，LLM现在能很好的识别这些模式并根据提示词调整最后人想要的软件，先不论UI好不好看，起码已经是能用的级别了。

市场上大部分软件项目都很难超过中型项目的规模，一个人，我觉得普通人这辈子是接触不到几个能称得上大型的软件项目，特别是从0到1的这种。所以能解决中型项目，其实就已经处理了大部分软件的问题。

而且撇开某些专业领域的软件，大部分软件其实就是一种信息交互系统，无非就是对信息的增删改查来流通而已，模式基本有有限的，而且也已经被LLM学得七七八八了。

……，我感觉开发变轻松了，所以我的同行们也是这种感觉。以至于现在一定程度harness的规范下的LLM，可以让一个没任何软件工程经验的人，用一句话生成一个一定规模的软件或者游戏了，但对于中等以上规模的软件，它的局限也已经仅仅是留存于一些只能靠老码农通过经验决策的问题，成本控制、安全、方案、风险等问题和软件跟现实世界或者硬件交互时候的问题了，虽然这些东西需要大量经验的试错得来的。也就是说，软件工程师所做的东西变得更加专注在架构管理、方案取舍和责任上。

也因此，程序员这个职业在某种程度上看起来好像可有可无。因为一个玩具级项目或者小型项目，压根不需要用LLM做的人知道架构是什么玩意，而且说实话，规模小的软件或者运营，上述这些仅存的东西，有或没有，基本是没有区别的。因为就算废技术出身，只要耐得住时间研究，这些经验他们也能在踩坑中积累，只不过绕了远路，不像以前，你没这个知识你是完全没有办法下手的。

对于一个问题仅存在于绕路还是花钱不绕路之间，大部分人肯定选择前者，而且这个时间成本很多软件人和非软件人其实自己也意识不到，因为现在几乎没人讨论一个有技术基础知识的人和完全为空的人做同样一个需求消耗的时间到底相差多少，消耗的token会相差多少？以及这省下来的时间，到底值不值？

其实软件行业内的人转vibe最大的障碍是正因为懂太多，放不下权，担心的东西太多，所以反而就看产品产出的效率来讲，对于没跨越这道坎的软件人来说，反而大家都用AI，还没个外行人出成果快。

同时，这也确切地导致小项目和初级程序员的价值直接被LLM吞噬。但其实反而是这些中小项目，养着绝大部分人。

因为软件的门槛被LLM拉低了，导致很多隐形成本看起来很好跨越，也导致大部分普通人觉得我行我上，也确实很大一部分小软件也几乎没有门槛了，因此现在中小软件几乎处于丧失定价权的情况，甚至以一种你让你傻眼的方式在剥离你的潜在客户。

但软件从来都不只是软件，只不过现在想单靠软件来变现变得非常困难。开发软件的门槛变低，但软件的门槛并没变低，真正能变现的软件，靠的也不只是软件。

做了差不多十年的码农，看过很多软件项目死在中途，不是所有项目都能跑到盈利那一天到来……

现在有时间让我们这些埋头在软件中的人抬头看看软件之外的东西了。虽然可能有饭碗危机😊。

我相信，软件只要是人在用，就离不开人，需要有人是暴露错误，发掘需求，进而调整。

最近跟朋友在讨论数据库优化的时候，说到了稳定排序和不稳定排序的问题，所以就把聊天记录的一部分记下来。 说一下稳定排序算法。和不稳定排序算法

所谓稳定排序算法就是排序后，子序列不变

例如有序列

A = [[3, 1], [2, 4], [2, 3]]

如果按A[0]降序排列，如果是稳定排序，结果肯定是

A = [[2, 4], [2, 3], [3, 1]] 

[2,4]永远在[2,3]前面

如果是不稳定排序

A = [[2, 4], [2, 3], [3, 1]] 

A = [[2, 3], [2, 4], [3, 1]] 

这两种可能都有。看具体算法

例如选择排序、冒泡排序就是不稳定排序。

你可以试试用来排[3,1] [2,4] [2,3]这个序列。用冒泡的话。从尾部冒泡到头部，从小到大，结果肯定就是

[[2, 3], [2, 4], [3, 1]] 

破坏了[2,4] [2,3]数组中第二个数的子序列

最近在帮外包公司的开发App的时候，遇到一些奇葩的BUG问题，因为是跟硬件交互的App，可能硬件返回了一些异常的数据，导致了App的崩溃，毕竟客户跟我不在同一个城市，而且对方公司没有用Mac系统的，所以在iOS出现崩溃BUG的时候，想要获取到对应的崩溃日志我可是绞尽脑汁。因为这个App是用Swift开发的，其实这次开发以后我觉得我可能短时间内，接到别的项目的时候，除非真的足够的小，不然我不会用Swift开发，我认为当前的Swift还处于上升期，还没到达能够用它开发比较大型项目的程度。而且相对于objective-c，有个令我蛋痛的问题，在objc中，我只要使用freopen之后，我就能把所有使用NSLog打印出来的LOG导出到文件。但让我头痛的时候，Swift使用了这句以后没有任何作用，我也没有去深究里面的问题。

另一方面，虽然Swift真的相对objc安全太多，特别Optional还有一些强大的语法支持，确实能够避免很多诸如空指针之类的异常。但写程序的总是人，总是会犯一些低级错误，导致App崩溃，在这种情况下。因为Swift太安全了，反而导致这个崩溃的BUG真的想都想不到在哪里，只能靠直觉去看那些可能有问题的地方进行加固。

所以我们最需要的是崩溃日志！崩溃日志真的太TM重要了，但是问题是，无论我使用NSSetUncaughtExceptionHandler设置，在Swift里面还是在objc里面，最后都发现无功而返。最终都没有办法取出崩溃的信息。哪怕把所有的signal都设上handler，还是没有办法捕获程序的崩溃。

所以最后的最后，还是无办法生成我所需要的崩溃日志，就算用XCode能够直接拷贝处iOS设备中的Log，但是客户不在同一个城市，总不可能我往那边频繁的跑把，这也非常不现实，我尝试教对方各种导出方法，可惜Mac盲+iOS盲，教起来有点费力，所以经过各种尝试，最后提倡客户去使用itunes connect里的TestFlight进行测试。

简单来说，就是生成一个构建版本之后上存到App store，然后在TestFlight里面邀请内部iTunes connet里面的成员进行内测，然后教对方在iOS设备上安装TestFlight，然后输入邀请码一系列操作。终于成功用TestFlight装上App了，那么希望崩溃问题能够捕捉到吧，问题是上面说信息会有72小时的误差?我只能祈祷生效

最近在忙公司的项目，公司现在重新做自己产品，所以我现在前端后台各种换着做，所以产品也奔着小程序走了。

但是坑爹的是，我在做上存文件时候发现，我填OSS的域名的时候，小程序竟然警告我这是非法的域名，然后想想暗战中那两家，就明白把阿里的域名填进去是不可能的，不过我还是庆幸没有把阿里的IP网段全封了，毕竟我们公司服务器主要用的都是阿里的?。

好了，那么问题来了，这个问题要怎么解决，试了很多种方案，麻烦的是小程序的那些域名白名单第一需要ICP备案，第二需要https证书，我又不想又去申请一张证书，那实在太麻烦了。所以最后发现比较折衷的方法，那就是用nginx做反向代理，连接到到阿里的OSS，下面附上配置

server {
    server_name aaa.com;
    listen 443 ssl;
    ssl_certificate 证书书地址;
    ssl_certificate_key 秘钥地址;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_session_cache shared:SSL:10m;
    ssl_prefer_server_ciphers on;
    ssl_session_timeout 10m;
    location /oss {
        rewrite ^/oss(/.+)?$ /$1 break;
        proxy_http_version 1.1;
        proxy_pass http://bucket-name.oss-cn-shenzhen-internal.aliyuncs.com;
        #这两句是为了替换调用阿里云返回的错误数据的时候，把域名替换成自己的，纯粹强迫症
        sub_filter_types application/xml;
        sub_filter_once off;
        sub_filter 'bucket-name.oss-cn-shenzhen-internal.aliyuncs.com' 'aaa.com/oss';
    }
    location / {
        #其它的反向代理
    }
}

如上，大家可以把bucket-name.oss-cn-shenzhen-internal和aaa.com换成自己的阿里云OSS的endpoint和域名

另外，如果绑定了域名到OSS的话，因为小程序必须使用https访问，但是如果我们把OSS绑定的域名换成https访问的话，阿里的服务器会返回他们自己的https证书，然后小程序会直接校验TLS失败而直接拒绝了请求，因此只能通过自己的服务器做反向代理，毕竟这样能够返回我们自己域名的https证书，这样又没有必要特地给oss再指定一个二级域名，还省掉了麻烦的申请https证书的过程。而且可以看到用的是OSS的内部域名访问的，这样用自己服务器的流量来替换了OSS直接的外网流量，说不定是牺牲了服务器一些性能，而减少了OSS的外网流入流量，省钱啊。毕竟OSS不算内网流量。

还有就是我发现小程序内部使用到图片的时候，那个image标签和css的background-image的时候，地址是http和直接用OSS的那个三级域名也是没有问题的，那样就可以避免这些静态数据走逻辑服务器，还是直接走OSS吧，只是上存的时候比较绕，要到自己的服务器后台一圈再去OSS罢了。

其实最近心情很复杂，感觉到迷惘，也感觉到一些不甘。不甘的是现在项目的走向，虽然缓慢，但感觉还有一步一步脚踏实地的前进着，基本上都没有遇到一些比较大的技术难题。可能因为长时间的加班，导致已经开始如咱老大说得，做项目做疲了那样的感觉。有时候觉得很累，但又很多东西要做。现在才慢慢有一些踩着开发节奏的感觉，现在来说目标只有快点开发完，快点上线。 那么那些让我迷惘的东西，就是之前老大突然问我们产品设计的一个问题，你感觉市面上那么多跟我们同类的产品，而且功能大且全，你觉得我们比他们有什么区别？有什么优势？

虽然这些话并不是对我说，我只是听到那么一说，也让我自己陷入了沉思。你说我们跟别人已经发展了几年甚至上线不知道经过多少次迭代的产品比较，我们的产品确实如一个初生婴儿一样，要啥啥不成熟，如果真有去挑毛病挑刺，我感觉好想能挑出不少，而且我自己本身也挺害怕这个对比。就感觉像被人问，你觉得你自己离BAT的工程师差距有多大的感觉。那么我就去挑我们产品比别人好的地方，虽然好像能够说出那么几个，但是总感觉认真一想，难道别人会没有注意到这个问题吗？我觉得我自己对于自己现在做的产品的理解不够深入，只是远远停在了知道需求，知道怎样开发上。我的直觉很想知道，如果真的要比起来，到底比别人的产品好在哪。其实如果真要照刚开始做产品的时候我们的目标来说，我认真比对了下，总感觉不到什么发光点，我感觉连离我们最初定的目标也有一段距离。

另一方面，总感觉自己技术上已经在某个位置停滞了有几个月的时间，有时候想往一些新方面发展看看，能不能给现有的瓶颈来一个意想不到的反转？

我个人是挺喜欢往架构方面深入的，而且我觉得心在算比较擅长的java和iOS也想进一步深入了解底层，也稍微了解一下golang和kotlin之类的。

这里我会以上一篇文所的的预定义的表，请对照着阅读:一些Hibernate的用法笔记（1）

在一些实际的开发环境中，我们查询一张表，可能需要关联到另外一张表的信息，不是那种已经存在于数据库表的字段中的数据，可能是需要统计的一些数据，例如我需要知道这个用户在系统下面到底有多少中角色，写成SQL可能是

select {ac.*},
       (select count(*) from account_role_rel where account_role_rel.account_id=ac.id) role_count
       from account ac 
       where
       ac.id=?

对于像上述查询语句中，这种查出来为纯数字的变量，而且不存在于实体当中的变量，我们可以通过addScalar的方式捕获出来

那么我们在DAO中转换当前SQL语句查询结果的代码如下：

SQLQuery q = session.createSQLQuery(
    "select {ac.*}," +
       "(select count(*) from account_role_rel where account_role_rel.account_id=ac.id) role_count " +
       "from account ac " +
       "where" +
       "ac.id=1"
);
q.addEntity("ac", AccountModel.class);
//可以通过StandardBasicTypes设置额外捕获的参数的类型
q.addScalar("role_count", StandardBasicTypes.INTEGER);

//获取到的内容为Object[]{AccountModel, role_count}
return q.uniqueResult();

StandardBasicTypes里面有很多基本类型:

---

还记得我们之前声明的用户和角色的关联表：

account_role_rel
列名	类型	注释
id	INT(11) NOT NULL PRIMARY KEY AUTO_INCREMENT	递增标识
account_id	INT(11) NOT NULL	用户ID
role_id	INT(11) NOT NULL	角色ID

现在我们需要声明AccountRoleRelModel.java，我需要在里面Join上RoleModel和AccountModel的实体：

/**
* 用户与角色的关联表的实体
*/
@Entity
@Table(name = "account_role_rel")
public class AccountRoleRelModel {
    private Integer id;
    private AccountModel account;
    private RoleModel role;

    @Id
    @Column(name = "id")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    public Integer getId() {
        returnn this.id;
    }

    @OneToOne    //这里可以改成ManyToOne，相对，下面的JoinColumn需要加上insertable=false, updatable=false
    @JoinColumn(name = "account_id", referencedColumnName = "id")
    public AccountModel getAccount() {
        return this.account;
    }

    @OneToOne
    @JoinColumn(name = "account_id", referencedColumnName = "id")
    public RoleModel getRole() {
        return this.role;
    }

    //setter省略
}

这种时候，我们在编写DAO的时候，我们可以通过addJoin加入对应实体的映射：

@Repository()
public class AccountRoleRelDAO {

    @PersistenceContext
    public EntityManager em;

    @Transactional(readOnly = true)
    public List<Object[]> getCashAccount(int accountId) {
        Session session = em.unwrap(Session.class);
        SQLQuery q = session.createSQLQuery(
                "select {account_role_rel.*}," +
                        "{account.*}," +
                        "{role.*} " +
                        "from account_role_rel " +
                        "inner join role on "  +
                        "role.id=account_role_rel.role_id " +
                        "inner join account on " +
                        "account.id=account_role_rel.account_id " +
                        "where account_role_rel.account_id=:accountId"
        );
        q.setParameter("accountId", accountId);
        q.addEntity("account_role_rel", AccountRoleRelModel.class);

        /* public abstract SQLQuery addJoin(String tableAlias, String path)
         * Declare a join fetch result.
         * Parameters:
         * tableAlias - The SQL table alias for the data to be mapped to this fetch
         * path - The association path ([owner-alias].[property-name]).
         */
        //根据上述定义，addJoin的第一个参数，应该是需要join的表在SQL语句中的名字，如果我们给对应表声明了别名的话，这里填的应该是别名
        //后面应该是主表在SQL中的名字，有别名用别名，然后.后面接实体中，Join的模型的变量的名字
        //例如AccountRelModel中我们声明AccountModel Join的变量名为account
        //因此这里填的是account_role_rel.account
        q.addJoin("account", "account_role_rel.account");
        //同上
        q.addJoin("role", "account_role_rel.role");
        //返回的内容List<Object[AccountRelModel, AccountModel, RoleModel]>，顺序根据上面addEntity、addJoin的顺序产生对应的Object[]内用的顺序
        return (List<Object[]>) q.list();
    }
}

我的公司的老板对新的项目的后台的架构下了非常重的力度，所以很多东西希望能够抽取出来重用，特别是对于一些很多项目都会重用到的模块进行抽出。开发中，一些封装的功能甚至关联的表都是未知的，因此对Hibernate用法进行了一次比较深入的研究。我们希望针对自己的业务，形成一套系统，让以后的开发效率更高。并且能够能增强封装出来的东西的重用性。有时候非常庆幸有一个搞技术的老板，真的能够学到很多好东西。

这里总结一下，做下记录。虽然hibernate的ORM的注解很强大，包括和spring jpa一起使用的时候真的非常爽。但是这些功能，虽然用着爽，却容易对业务造成很大的耦合度。

好了，转入正题。

例如我们有一个用户表：

account
列名	类型	注释
id	INT(11) NOT NULL PRIMARY KEY AUTO_INCREMENT	递增标识
account	VARCHAR(25) NOT NULL	用户名
password	VARCHAR(64) NOT NULL	密码

角色表:

role
列名	类型	注释
id	INT(11) NOT NULL PRIMARY KEY AUTO_INCREMENT	递增标识
role_name	VARCHAR(25) NOT NULL	角色名

用户角色关联表:

account_role_rel
列名	类型	注释
id	INT(11) NOT NULL PRIMARY KEY AUTO_INCREMENT	递增标识
account_id	INT(11) NOT NULL	用户ID
role_id	INT(11) NOT NULL	角色ID

因此我们可能需要生成两个实体

AccountModel、RoleModel

至于中间那个account_role_rel的表，因为开发中要用hibernate转换出它的实体，实在多此一举，因此就直接省略掉对应的实体了。

/**
 * 用户实体
 */
@Entity
@Table(name = "account")
public class AccountModel {
    private Integer id;
    private String account;
    private String password;

    @Id
    @Column(name = "id", nullable = false)
    public Integer getId() {
        return this.id;
    }

    @Basic
    @Column(name = "account", nullable = false)
    public String getAccount() {
        return this.account;
    }

    @Basic
    @Column(name = "password", nullable = false)
    public String getPassword() {
        return this.password;
    }

    //Setter省略
}

/**
 * 角色实体
 */
@Entity
@Table(name = "role")
public class RoleModel {
    private Integer id;
    private String roleName;

    @Id
    @Column(name = "id", nullable = false)
    public Integer getId() {
        return this.id;
    }

    @Basic
    @Column(name = "role_name", nullable = false)
    public String getRoleName() {
        return this.roleName;
    }

    //Setter省略
}

现在假设我们建了Account和Role这两张表的实体，而且没有使用@JoinColumn一类的注解，但是我们需要动态的把两张表关联在一起 我们需要DAO

/**
 * 获取账号和角色集合的DAO
 */
@Repository
public class AccountRolesDAO {

    @PersistenceContext
    public EntityManager em;

    public Map<AccountModel, List<RoleModel> findAccountRoles(int accountId) {
        Session session = em.unwrap(Session.class);
        SQLQuery q = session.createSQLQuery("SELECT {ac.*},{ro.*} from " +
                                             "account ac" +
                                             " left join " +
                                             "account_role_rel rorel " +
                                             "on rorel.account_id=ac.id " +
                                             "left join " +
                                             "role ro " +
                                             "on ro.id=rorel.role_id");
        q.addEntity("ac", AccountModel.class);
        q.addEntity("ro", RoleModel.class);
        //返回的东西是{[AccountModel,RoleModel],[AccounrModel,RoleModel]}
        List<Object[]> result = q.list();
        Map<AccountModel, List<RoleModel>> map = new HashMap<AccountModel, List<RoleModel>>();
        for (Object[] entities : result) {
            List<RoleModel> list = map.get(entities[0]);
            if (list == null) {
                list = new ArrayList<RoleModel>();
                map.put(entities[0], list);
            }
            list.add(entities[1]);
        }
        return map;
    }

}

上面的东西，如果我们关联表是未知的，我可以很方便的通过上面代码的变形，传入对应实体类型和参数，就能够实现自动关联，不像Hibernate注解声明的实体，实体之间的关系必须在实体内声明。即使在不清楚另一个实体是什么的情况下进行关联，能够很好的把一些业务重复的逻辑抽取出来，再跟项目或者功能特定业务的表关联，这样就不用每次开发都特地的写一遍这些功能。