使用大模型进行项目的二开

使用大模型进行项目的二开

本文初次编写时间：2025-07-18

需求

1、想进行项目的二次开发，不知有什么好的方法。

实现

主要分两步，第一步，理解原先代码的含义，第二步，加新功能。

1、理解原先代码的含义。

这里代码忽略。假如某个方法难以理解，我对 gemini cli 说，分析某文件的某方法，并查阅该方法的相关类的代码，最后写出这个方法的非常详细的注释。然后大模型会修改我的文件，添加了注释，如下：

     * 创建活动订单。
     * 该方法是用户参与活动的核心入口，负责处理从资格验证到生成待支付订单的全过程。
     * 它包含了大量的验证和并发控制逻辑，以确保在高并发场景下的数据一致性和公平性。
     *
     * 核心职责:
     * 1. **前置检查 (Pre-flight Checks)**:
     *    - 验证用户是否设置了默认收货地址。
     *    - 验证所请求的活动和场所是否真实有效。
     *    - 取消该用户之前为同一活动/场所生成的未支付订单，以释放被占用的库存。
     *
     * 2. **排队机制验证 (Queueing Logic)**:
     *    - 如果活动需要排队 (`is_line == 1`)，则会连接 Redis 进行验证。
     *    - 确保用户在排队队列中，并且其排队位置是第一位 (队首)，否则不允许操作。
     *
     * 3. **资格与参数验证 (Permission & Parameter Validation)**:
     *    - 检查活动是否对VIP等级有限制，并验证用户等级是否符合。
     *    - 验证用户请求的购买数量是否为有效值 (如 1,2，3，)。
     *
     * 4. **分布式锁 (Distributed Lock)**:
     *    - 在进行库存检查和订单创建前，获取一个针对该活动的分布式锁。
     *    - 这是为了防止高并发下的“超卖”问题，保证库存计算和扣减的原子性。
     *
     * 5. **库存检查 (Stock Verification)**:
     *    - 在持有锁的临界区内，精确计算真实剩余库存。
     *    - 计算时会考虑已存在但未支付的订单所占用的库存量。
     *    - 如果用户请求的数量大于剩余库存，会自动调整为剩余库存量。
     *
     * 6. **订单生成 (Order Creation)**:
     *    - 所有验证通过后，在数据库中创建一个状态为 `nopay` (待支付) 的订单记录。
     *
     * 7. **收尾工作 (Cleanup)**:
     *    - 释放分布式锁，关闭 Redis 连接。

又比如，大模型帮我生成的代码注释

* 方法执行流程:
* 1. 获取活动基本信息:
*     - 使用 `self::defaultModel()` 辅助方法查询一个有效的福袋（开关打开、在活动时间范围内）。
*     - 如果不存在或不满足条件，则通过 `ResponseService::error` 抛出错误。
*
* 2. 更新浏览次数:
*     - 将活动的 `viewnum` 字段加1并立即保存，用于统计活动热度。
*
* 3. 口令验证 (Password/KouLing Check):
*     - 使用 `Common::getKouLingFlag` 检查用户是否已经在此会话中验证过此活动的口令。
*     - 如果活动设置了口令 (`is_pw == 1`)，且用户尚未验证过，并且本次请求传入的 `password` 不正确，则抛出“口令出错”的错误。
*     - 一旦验证通过（或活动无需口令），调用 `Common::setKouLingFlag` 为用户设置一个已验证的标记，以便在后续操作中（如创建订单）无需再次输入口令。
*
* 4. 获取所有已占用的位置 (Location):
*     - 查询 `play_order` 表，找出所有与此活动关联的、状态为“未支付”(`nopay`)或“已支付”(`pay`)的订单。这确保了即使用户还未完成支付，其选择的位置也会被暂时锁定。
*     - 从这些订单中提取 `lucky_location` 字段（这是一个逗号分隔的位置编号字符串）。
*     - 将所有查询到的位置字符串分割并合并成一个名为 `$temp` 的一维数组，该数组代表了所有当前不可选的位置。
*
* 5. 计算当前用户已购买的数量:
*     - 如果用户已登录 (`$user` 不为空)，则查询该用户针对此活动的所有“已支付”(`pay`)订单。
*     - 统计这些订单中包含的位置总数，得到 `$buyNum`，用于前端展示和后端的限购判断。
*
* 6. 获取关联的明信片信息:
*     - 检查活动是否关联了商品 (`$info->postcard_id`)。
*     - 如果有关联，则从 `postcard` 表中查询商品的名称和图片。
*
* 7. 组装并返回响应数据:
*     - 将活动的名称、图片、价格、ID、VIP限制 (`vip_ids`) 等基本信息组装进 `$responseData`。
*     - 计算并加入活动的总坑位数 `total_num` (通过关联的 `lucky_bag_product` 表的 `stock` 总和得出)。
*     - 加入所有已占用的位置数组 `oldLocation`。
*     - 加入活动的限购数 `limit_num` 和当前用户已购数 `buyNum`。
*     - 加入抽奖类型 `draw_type` 和关联的商品信息。
*     - 返回最终组装好的 `$responseData` 数组。

我就想问问大家，注释能详细到这种程度，还能有什么代码看不懂的。

2、加新功能。
这个更简单了，把大模型当奴隶使唤就好了。

总结

1、有了大模型，人与人之间的连结会减少，因为大家有问题都问大模型了。论坛也会愈发萧条。
2、但是对个体来说，学习成本极大降低，对学习新事物，新语言等畏难情绪大幅度下降，总的来说算进步吧。

本作品采用《CC 协议》，转载必须注明作者和本文链接