AI编程实践中的三个核心挑战：交付质量、团队协作与需求对齐

经过五个月的实践，我再次审视此前关于AI编程领域问题的思考，认知有了新的提升。目前我认为，AI编程（AI Coding）的核心挑战集中在以下三点：

1. 如何确保AI生成的代码符合预期需求？
2. 如何确保AI编程交付物的质量可信赖？
3. 如何构建高效的人与LLM混合团队？

我们首先探讨第二个问题：如何确保AI编程交付物的质量可信赖？

我的朋友胥克谦指出一个关键悖论：“连续工作的智能体，其问题在于每个环节的质量可能未经验证就进入了下一步。” 对同一段代码尝试不同的提示词、开启新的对话会话或进行多智能体交叉测试，结果往往各异。何时需要进一步测试、何时进行交叉验证、是修复代码缺陷还是调整原始设计——让智能体来判断这些，在现阶段仍不可靠。

这个观点是在实践中深刻体会到的。如果遇到宣称AI智能体可以连续工作数十小时而无需干预的说法，其可信度需要打上问号。

有人提出，通过“上下文工程”（Context Engineering）将所有背景信息喂给大语言模型（LLM）就能解决问题。实践证明，过长的上下文反而会导致LLM输出质量下降，这就像领导过度唠叨会降低员工效率一样。而精选上下文最有效的方式，目前仍是人类的直接提示（Prompt）。

还有人认为：采用多智能体进行检查验证，不就相当于引入了“人在循环”（Human-in-the-loop）吗？实践表明，交叉验证确实能带来一定提升，但由于LLM的常识与人类常识存在根本差异，多个LLM协同仍可能犯下相同的低级错误。

幸运的是，交付物质量不可靠并非LLM独有的问题，人类同样会犯错。软件工程领域已有较为成熟的应对方案。我目前在实践中采用了以下几种方法：

1. 任务拆分：避免给AI一个庞大而无法验收的单一任务，将其分解为可管理、可验证的小目标。
2. 平台工程主导：由人类工程师负责搭建核心框架与架构，让AI专注于实现繁琐但定义明确的业务逻辑。
3. 高密度测试：针对一个微服务，我们建立了五个层次的测试：单元测试、组件测试、API测试、集成测试和端到端（E2E）测试。
4. 与DevOps流程结合：代码开发完成后立即进入自动化部署流水线，并采用灰度发布策略。
5. 迭代开发：对于不明确的需求暂不实现，想清楚后则不惧怕重构重写。
6. 建立可观测性与预案：完善系统监控与日志，并预设故障处理手册（Runbook），避免AI在排查问题时盲目猜测。

可以看出，这些方法本身并无新意。但在传统纯人力团队中，全面推行这套流程往往成本高昂、耗时漫长，工程上几乎难以实现。AI的出现，使得严格执行这些最佳实践成为可能。

然而，正如胥克谦所言：“对同一个目标，只有在经过反复、多角度的交叉测试，包括多用户视角检验后，我才敢放行。每次变更都能检查出问题。因此，直接检测通过就进入下一轮，是非常不可靠的。” 我目前采用的这套方法效果仍然有限，尚在持续探索中。

如何构建高效的人与LLM混合团队？

这是一个价值被低估的问题。我看到许多大型企业的研发效能部门在推行各种工具和流程，但他们的核心指标往往是“工具覆盖率”，追求98%的采用率。这就产生了一个悖论：如果你的工具如此高效，能让一个人完成五个人的工作，为什么还需要每个人都使用它？如果公司业务没有显著增长，而工作量却增加了五倍，这难道不是个坏消息吗？

更奇特的一个指标是“AI生成代码采纳率”。这个指标的荒谬性与过去外包公司用代码行数（LoC）考核员工如出一辙。如今，即便最落后的外包公司也已摒弃了LoC指标，而一些AI编程团队却重拾这块“裹脚布”，并宣称是创新潮流。

从实践来看，人与人之间的沟通成本远高于人与AI的沟通成本，且信息失真度更高。一个更务实的策略或许是放弃“全员AI化”的目标，转而聚焦打造少数几个“人类-AI”混合的特种部队团队。

我与朋友王津银提出了一个“小笼包理论”：一个高效混合团队的规模，应控制在一份小笼包够吃的程度——直白地说，大约三人。我目前的团队结构是一个领衔工程师（Lead Engineer）、一个测试工程师（Test Engineer），并根据不同项目与相应的产品负责人（Product Owner）协作。这种模式下，项目进展迅速，损耗极低，取得了出乎意料的良好效果。

如何确保AI生成的代码符合预期需求？

这是一个极其困难，也最具价值的问题。我们将在后续的讨论中深入分析。