The Challenges and Problems I Encountered

Order Settlement System

1. 如何分析、定位和解决duplicate billing item带来的问题
   1. 问题：在系统里发现了大量重复的bililng item id，有可能会导致打款资损问题。
2. 如何做出来一个safefile文件生成的系统
   1. 问题：过去的生成范式经常失败，下游多次反馈有打款issue，导致业务、产品和技术经常加班。
3. 如何短时间内解决payout生成时间过长的问题
   1. 问题：系统通过cronjob每周一需要生成千万级订单的结算payout实体，而运营需要STS系统在12个小时内完成所有的生成。
4. 如何解决upload file处理时间过长的问题
   1. 问题：在从TIDB迁移到MySQL后，运营发现系统上传离线billing item文件（百万级），kafka消息的处理速度远不如前，以前只需要几个小时，现在需要几天。
      1. 更糟糕的是，在系统设计中，这个kafka topic被多个任务共享，导致运营在文件处理期间无法做任何批处理操作（如生成report、更新user rule等）
      2. 而如果中间kafka消费者遇到失误，需要从头开始，运营等待几天却没有任何结果。

Duplicate Billing Item ID Problem caused by ID Generator

1. Situation
   1. Problem statement
      1. 我负责的系统是订单的结算系统，负责汇总所有region，每个卖家所有订单的结算金额，最后触发打款流程，公司把钱从银行划给卖家。
      2. 某天，我收到运营的issue report，说在系统里发现了大量重复的bililng item id，有可能会导致打款资损问题
   2. role
      1. 我作为这个项目的PIC，在收到Ops的报告后，
         1. 需要确保这个issue不会造成打款问题、资损，需要给运营和老板一个交代。
         2. 需要排查出root-cuase，避免同样问题再次发生。
         3. 我刚刚take over这个业务才一个多月，我们也正在进行从TIDB到MySQL的迁移，这加大了排查的困难性。
2. Challenge/complexity
   1. 主要遇到的难点如下，时间紧任务重
      1. 需要先了解这些重复id对系统的影响，会不会造成严重的打款问题、资损。
      2. 在了解了影响后，需要在短期内排查出root-cause，避免相同的issue再次出现造成payment出问题。
3. Actions
   1. how to resolve the problems metioned above
      1. 对于第一个问题
         1. 我先从头梳理了我们结算系统从触发结算到最后打款的全流程。
            1. 每个order是在什么情况下创建billing item
            2. 如何对每个卖家的billing item进行汇总、结算
            3. 系统主要有两种billing item。
               1. 一种是自动结算的订单，在计算每个卖家结算金额时会使用shop user id来进行汇总，由于我们数据对于shop_user_id和billing_item_id有做unique key，所以可以确保同一个shop不会存在重复的billing item id。所以可以确保这个情况不会发生问题。
               2. 一种是运营上传billing item id进行手动结算的订单，而运营一般倾向于只上传billing item id，如果只上传id，有可能导致系统操作错订单。
                  1. 而就在最近，我们支持了上传user id，所以我要求ops对于这一批biling item，操作时都需要同时上传shop user id避免系统误打款。
                  2. 同时我也紧急重新生成了这批billing item的id并更新到数据库中，避免运营操作失误没有上传shop user id。
            4. 通过与支付运营同事讨论了解他们何时触发打款操作，打款周期如何
               1. 明白自动结算的订单是每周一次，所以不是问题。
               2. 而手动结算的订单是一个月导出执行一次，所以只要在下一个月前修复即可。
      2. 对于第二个问题
         1. 我分析当前系统ID生成的范式，排查root-cause
            1. 我们系统的ID generator使用的是snowflake算法，有一位system id是instance index，如果只部署在一个data center是没有问题的。去年公司开始推动系统容灾方案，某天把我们系统在第二个data center也scale了几个服务，而新data center的instance index也是从零开始的，导致同一秒请求生成billing item时，有同样instance index的instance会生成一样的billing item id。
            2. 在得知root-cause后，当即停掉了新data center的instances。
         2. 需要了解是否与正在进行的DB migration有关
            1. 梳理现在DB migration的进度，已经从TIDB单写单读，变成了（TIDB、MYSQL）双写和MYSQL单读。所以推测重复id生成与DB migration无关。在数据中心对比两个DB近一个月数据，确保数据一致。同时修改两个DB避免数据出现遗漏。
4. Result
   1. metrics
      1. 花了一天和运营、产品经理对业务进行了梳理，确保了系统没有任何资损。
      2. 修复了在五个region的数十万条重复billing item id。
      3. 确保正在进行的DB mirgation不受影响。
5. future (long-term plan)
   1. 为了避免同样的问题再次出现，与容灾项目PIC沟通让他们把我们系统的容灾feature toggle先关掉，等我们系统改造后再解决了。
   2. 我们后来部署了独立的id generator服务，使得我们的服务可以同时在多个data center部署而不会重复的id，解决了问题。

AI Code Review

在今年一月份想到这个idea，自下而上发起这个项目，就像在公司内的小型创业。

从开始到现在的这半年时间里，最大的问题就是让这个项目活下来。

metrics

截止25年7月15日

1. Online code review
   1. 30+ teams
   2. 1387 developers
   3. 1263 repos
   4. 10k+ review comments
2. MCP Code Review
   1. Number of Reviews: 181
   2. 80 developers
   3. 97 repos

主要features

1. Online Code Review
2. MCP Code Review
   1. Can be used in Cursor/Winsurf/Copilot/Claude/Gemini
3. AI Review Center
   1. review task display/search
   2. review stats
   3. review configs
4. IM integration
5. Config Review
6. Code review with TD requirement
7. Evaluation Pipeline

遇到的挑战和问题

1. 资源不足

   1. 人力紧缺
      1. 从一开始我自己一个人做，到了中期有其他6、7个同事parttime参与，再到回归到我自己一个人做。
   2. 时间紧张
      1. 老板需要看到效果，我们需要快速迭代需求、搭建平台、数据飞轮。
   3. llm资源紧缺
      1. 老板认为这个项目没有看到好的metric，没有澄清切实value（尽管我们已经可以看到线上有上千个好的review comment case）。所以只批准了每个月100刀的API budget。
         1. 为了解决这个问题，我们pivot到了mcp code review，因为公司给大家都买了cursor，所以每个reviewer都可以使用自己cursor的budget来

2. 公司内竞争

   1. 很多team都在做同样的事情，需要尽可能的做出原型
      1. 要快速迭代功能，确保基本功能有效
      2. 易用性，容易集成
   2. 需要做好marketing
      1. 写好User Guide，要让大家看得到。
      2. 让这个服务成为公司内的事实标准。

3. 说服老板采纳

   1. 要采集指标，要有好看的metrics，CTO才会同意在全公司推行。
   2. 要优化指标
      1. 允许用户自定义prompt
      2. 参考字节25年2月最新论文的实现，实现了checker和filter，BitsAI-CR: Automated Code Review via LLM in Practice
   3. 搭建了平台供用户
      1. 查询code review结果
      2. 自定义prompt
      3. 查看数据指标

4. 技术问题

   1. should we build it from scratch?
      1. 年初，在查阅了网上已有的开源项目后，我决定自己从头开始做，主要考虑到
         1. 内部gitlab版本legacy
         2. 从零开始，易于掌控，不需要受制于开源项目的框架。当时开源项目做的比较好的只有 PR Agent，是python codebase，项目已经很大，需要花很多时间去熟悉，去做调整。
   2. llm api
      1. local deployment
      2. API Provider
   3. prompt/context enginering
      1. biz domain knowlegde
      2. code context
         1. code diff的构造有多种方案
            1. 只传原始code diff
               1. pros：易于实现，token少
               2. cons：无上下文，review结果很差
            2. 带上full existing file content
               1. pros：易于实现，整个文件的内容包括了一个一个code diff绝大多数上下文，review相对好。
               2. cons：token消耗大，没有包含跨文件的context
            3. 只带上相关的代码上下文
               1. pros：token消耗相对于full existing file content少，review结果也相对好。
               2. cons：实现有难度，可以继承Tree-sitter
            4. codebase index

               1. pros：能够得到有所有的context，review结果最好。

               2. cons：需要考虑对每个repo构建codebase index，有code data security和计算资源问题。

               3. 实现：我们通过mcp code review，可以利用到cursor等Coding Assistant自带的codebase indexing。