本周工作思考
- AI编程中的稳定性和可靠性评估思考
- 在需求明确清晰，业务逻辑严谨的情况下AI生成的代码基本上是可用的，但是能不能用来商用，或者经过功能测试后直接提供给客户使用，这种方案是否可行呢？这个问题我断断续续有过有很长的一段思考，在使用ChatGPT和VSCode Copilot时，我认为是不可行的，因为这个时候基本业务功能的实现还存在着很多不准确的问题，随着大模型编程能力的提升，我任务这个问题的答案是可行的，随着对AI编程的使用和学习，我现在的看法是，分情况看。
- 情况一，如果是创新性的产品功能，产品目标和市场目标是抢占客户认知和市场趋势，在初期迭代是可以使用AI编程 + 功能测试的流程来发布的。如果市场反响良好，随着迭代的 必须加上 专家设计 + AI编程 + AI测试+专家测试。
- 情况二，如果是成熟类产品，在存量市场抢占市场份额，这时候产品质量和服务质量至关重要，所以必须要加上 专家设计 + AI编程 + AI测试+专家测试 + 工程能力，这里多了工程能力，工程能力包含很多方面，从咱们实际出发举例，如CI/CD，各类监控能力，技术升级换代的能力，极致性能优化能力，研发人员的团队协作能力，解决客户技术问题能力，快速迭代的能力等等。
- 情况三，现有产品+更新迭代的情况，这种情况是持续提高服务质量的同时，不断降低服务成本，增加ARR，这时候在均衡提高服务质量降低服务成本的两个双目标驱动时，AI不一定能发挥出最大价值，原有系统要接入AI的工程体系，这个在本质上是重构的过程，重构过程意味着在一个时间段内保持服务质量不变的情况下优化代码的实现结构，这个时候工程成本是上升的。但是从长期来看，这个付出非常值得，在度过过这个成本高峰之后，随着AI大模型能力的提升，服务成本开始显著降低。
- 情况四，随着AI编程能力在行业内所有工程团队的普及，大家在AI能力的配备上接近一致，对同类产品来说，AI提效的方向转换为谁用AI用的的最为彻底， AI降本的方向转换为谁用的AI产出的代码质量最高最可靠出错最小， 同时研发流程的全AI化将是研发团队的共同目标，对与小型研发团队来说，敏捷和灵活性依然是AI时代研发的优势所在，创新性和可靠的设计和实现依然产品取得市场成功的关键。
- 目前看AI编程的未来是无限光明的，但从务实的角度来说AI整个研发体系里的渗透还远远不足，最大的问题，我认为还是大模型能力的问题和人类工程师和大模型协作分工的信任问题，举个常见的例子，我在完善现有代码的异常处理时，我使用了Cursor为我添加应该需要的异常log但是实际却被遗漏的log，我再Review的过程中，发现AI有几处是冗余的，然后我调整Prompt，让AI重新处理，这时我发现有一处错误，引用了不该引用的变量，由此我急忙在检查其他的几十处修改，其实只有这一处有问题，其实这让我对AI在这个问题上产生了信任危机，理性告诉我AI值得信任，但是从工作交付过程上说，我是交付者，我需要交付负责，我不得不重新Review AI的产出，从这角度出发，还需要另外的人来Review我的交付，从这个流程上说，工程上为保证可靠性需要多层的AI Review和评估机制，用直白的话说，1个AI程序员编码，需要至少2个AI编程助理做Review和评估，还需要1个AI工程经理Review和评估这两个AI编程助理的工作，到这里就完了吗？不，但这取决你对AI工程经理的信任程度，如果你信任你的AI工程经理，这个工作到此为止，如果你不太信任你的AI工程经理，那就需要一个AI工程总监了。很显然，这不是我们很多人想象中AI编程中应该有样子，一个任务我们需要的AI编程的Agent太多了。但本质上就是随着AI的加入，我们对工作的要求提高了，我们对AI的要求也提高了，在此过程中，客户是最大的受益者。